On a sunny day (Sat, 23 May 2009 09:22:09 +0100) it happened Nobody wrote in :
way,
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 ;-)