Re: Larkin, Power BASIC cannot be THAT good:

On a sunny day (Sat, 23 May 2009 09:22:09 +0100) it happened Nobody
<nobody@xxxxxxxxxxx> wrote in <pan.2009.05.23.08.22.05.828000@xxxxxxxxxxx>:

I mentioned linked lists, and people should know those.
Guess what Lisp is based on?
http://en.wikipedia.org/wiki/Lisp_programming_language

Before any of that OO crap, one should first learn the basics of programming.

I learned Lisp long before any OO languages (my first was Smalltalk), and
it is one of the few languages that I use regularly. But even Lisp has
CLOS, which suggests that even Lisp programmers have a use for OO.

Then you likely do not want OO.
What we need is programming power, to solve problems in the fastest simplest way,
not code castles in the sky.

OO doesn't really help if you're only solving small problems. But it can
be extremely useful when you're dealing with code which needs to be
readily extensible, or is so large that "global" knowledge isn't feasible,
or which naturally fits the OO paradigm (e.g. component-based systems and
simulations).

OK, so to each his own perhaps.
'Language wars', 'editor wars' I have seen it all happening on Usenet.
Before we start throwing the pies, maybe we can agree on some statement...
like they do after those failed political meetings of our leaders...
"That although not a single POV is the same, we have agreed that
the weather will likely change frequently and there is still hope
for future progress, and a new meeting will be arranged to discuss the issues further."
That said, in a final statement, I declare what they call C++ and you refer to that C++ as OO,
sucks.

Now, well, OK, now that I started to write anyways... what the big mistake is,
is in my view that Strouskop (or whatever his name is), and maybe others too,
seem to think 'big problems' are things that need to be solved by 'one big program'.
If you think that, and would actually try that, then you get huge sources that need to
somehow be compiled together, and the thing becomes more and more difficult, and likely impossible,
for mere humans, to maintain.

This is _not_ how 'big problems' are solved.

As I mentioned before, the architect who does not know about stones and concrete, and dreams up a castle.
will be in big trouble once building starts.
*If* it ever starts, because he may have requested the impossible.
I do not know exactly where the limit for a 'big' or a 'small' project is for you,
but somebody here mentioned 70k lines of code, maybe 100k, maybe less.

In reality something of what _could_ be conceived as a big project, as an example I have here:
I want to say 'show ARD' (Ard is a German public broadcaster) and then I want that satellite station
to appear on my desktop monitor in full screen, de-interlaced.
Now in a way that involves: 1) voice recognition, 2) satellite dish positioning, 3) satellite
reception, 4) mpeg2 decoding. 5) mp2 decoding, 5) display, 6) Ceefax (teletext) decoding and display,
etc. etc.
That would, if you wrote it from scratch, take lot more then say 500k lines of code.
But we do not DO it that way, we are smart, and use PROGRAMS to do those essential parts,
and Unix (Linux) allows you to chain things together nicely.

Also here departs *my* view from what you commonly see in Linux, 'video for Linux' (v4l).....
v4l tries to do all thing by itself, and is therefore always one step behind, as it never
supports anything new, as that has not been integrated yet, also an ever changing API, now we are at v4l2,
and of course not compatible.
I decided to use pipes, and pipe the video stream from one application to the other...
A much simpler way, and if you wrote some application, say a filter, or some processing, then you just pipe
the stream through it....
So what that boils down to is that you do NOT have one big application, but a whole lot of universally applicable small
ones, that are each easy to maintain, and can easily interface with other things in the world, other applications,
and hell if you are so inclined you can call these small applications 'objects', buy of course they are not objects,
they are different programs, possibly written in different languages, working together to get the job done.
In the example I gave you speak into the microphone, that is monitored by 'perlbox voice' (written in you guessed it "perl"),
perlbox voice calls the voice recognition suite 'Sphinx2' and the Festival speech synthesiser, both rather large university related projects,
Once perlbox recognises the 'show ARD' command, it executes a bash script I wrote called 'show'.
The bash script will execute a C program I wrote called 'xdipo' that positions the disk, and then tunes the
sat card in the PC to the station ARD (frequency and parameters found in the script), by calling
the sat card driver, this driver output the transport stream (.ts that holds all the audio, video, text, etc.. stuff) on
/dev/dvb/adapter0/demux0 after tuning it via /dev/dvb/adapter0/frontend0 ...
this is then piped to a C program called 'jpinfo' that I wrote that extracts the required streams, that is then piped
to the 'xvtx' C program I wrote to display Ceefax (teletext) on screen text if required, that is then piped to xine, a media
player written in C++ (I think).... or mplayer (written in C), and those then use the Xwindows system to display it
on my screen, and the Alsa sound system to play the sound via the sound card, calling the needed decoders for video and sound.
those are written in C and partly asm, and all that runs on top of Linux which is written in C.
A million lines of code perhaps (if not more) to 'show ARD'.
problems?
What problems?
Modularity? Right there.
Object oriented, not if you use mplayer and not xine...
So 'syntactic sugar' is a very polite way to refer to the object oriented paradigm, it comes from wanting
to do too much at one time perhaps... maybe, and this is my view, from wanting to do all of the above in one program...
Not possible, not in the least because you never have all that knowhow.....
Nobody does >?> Nobody ;-)






.

Relevant Pages