Object Oriented Programming suck

Post Reply New Topic

I'd rather write machine code directly to a floppy diskette chaning the inodes by hand with magnets.

I kind of got the sense of OO hate too.

I've done a bit with a fair number of programming languages. I like Java, but I'll be the first admit that it's not the right thing for everything.

But my experience has been that for any project of significant complexity, Objected Oriented is the way to go.

Without the temptation to give you any links Java is a very low level language. To much coding to do very little and while it is better then C++ C for many tasks it is hardly any better then repulsive language VB.

Sometime I wonder why should a computer take so long to boot while a mobile boots quick.

Java? Low level? I believe that a simple assembly is the best first language. Or something similar like old BASIC.

Lau - I haven't seen Forth in a heck of a long time. I remember it being the hot thing. For pure power C++ is the way to go - it has all of the advantages of C, and two different ways to get polymorphism. C# is just a modernized java - give it a few years, and it will be just as replete with obsolete garbage; it's biggest advantage is the powerful IDE - but you're stuck in a windows (or mono) world. Python is the best of the scripting languages - it is nearly as efficient as C/C++ but allows a fast development cycle. Don't even think of comparing it to PERL, which is simply a mess.

Assembly language the best for beginners?

I'm comfortable with just plain C. It's pretty low-level, but you can do ANYTHING with it, including writing modular code which is nearly as good as OOP for groups of programmers. And I never code as part of a huge group anyway.

Something I realized about, oh, 20 years ago, when I was a newbie programmer, was that most languages are great for some things, but bad to totally worthless for others. I could learn FORTH for hardware, SQL for databases, Prolog or LISP for AI, COBOL for business apps, and on & on & on, and that would be one approach. The other was to pick one of the few languages that was useful for everything, and do most of my coding in it. I still use other languages from time to time, but my investment in C is something I've never had reason to regret.

Seems to me that high level languages are good for beginning programmers. And Java is definitely not Low Level.

Does anyone else here despise Javascript? It's sad that the language underlying "the future" of applications is an untyped, slow, archaic turd. Who would have guessed 20 years ago that major software would be based on a script language within a document paradigm?

What a strange concept -> "despising" a language. Javascript is an excellent language, in context and by evolutionary right. Until it is displaced by a fitter language, it rules (its little patch).

"Who would have guessed 20 years ago that major software would be based on a script language within a document paradigm?"
I guess that would have been me. While I was working at the Admiralty, designing a language that was essentially a document - yep, it fits.

Hi calandale. I've implemented Forth in various ways. First was on the Sinclair Spectrum - bootstrapped by a large Basic program that ran itself three times whilst generating the machine code in screen memory. Those were the days. Forth can easily result in code that is faster and more compact than assembler. I despise C++. Algol68 forever! (Then there was my version of Snobol, that never quite made it. Ah! The languages that have fallen by the wayside. How sad.)

Unless they have changed them in the last few years, you can still see Forth on any Sun Sparc workstation or server. Any time it can't boot off its hard drive, you get a prompt to execute commands in Forth. So it didn't end with Sinclairs.

I think Java is sucktacular.

Uh...how? Nothing can be faster than properly written native code. The only question is the penalty that you pay for your abstractions.

I knew I'd start argument with that one.

Firstly, have you ever looked at "properly written native code". Very often, you'll find that the code has actually got abysmal inefficiencies in it. What happens is that, up to a point, an assembler programmer's mind concentrates on the problem, but eventually, where the code gets a bit torturous, they'll code something that works, rather than something that is "perfect". With Forth, it is very easy to address the algorithms required, and drop occasionally into assembler for bits that need some speed. Call it cheating, if you like, but it's a fact.

Secondly, there's the cases where you are working with severe memory constraints (e.g. microprocessors). Attempting to produce pure assembler just doesn't cut it (unless you count re-inventing the wheel, by developing a customised interpretive language of your own! It might well look a bit like Forth. I've done precisely this, several times, where I wanted a subset of Forth functionality).

Thirdly, as Forth code can be so compact, you may get an edge by fitting everything into cache.

Fourthly, and this is more significant than most of the above, counting the "time to completion" of a non-repetitive task, Forth wins hands down. I.e. if it takes you five days to code and debug some assembler that then takes half and hour to solve "the problem", versus half an hour of Forth coding that takes a day to run, you've just wasted four days of your time.

Most of that could also be said of C. Some size penalty, once you #include <stdio.h>, but speed can rival good assembler, and beat bad assembler. Plus the program is SO much easier to modify. If your assembler code is running too slowly and you're going to have to move a frequently-used variable into a register, you'll be doing a lot of rewriting. In C, you can usually get a similar result by changing the declaration of that variable to 'register' and maybe tweaking your compilation options a little -- a 10 second job. I was taught that C was "putting a friendly face on assembly language," a description which I always found very fitting. And Forth is much the same.

Portability is another huge plus, of course.

Oh. And to get back "On Topic", Forth has it's OO side. C doesn't. C++ tries. C# succeeds.
(I use C more than anything else. I've never used OO Forth.).

C can be used as an OO language, people have been doing that (somewhat successfully) for a long time.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html for a recent example. C++ just built in what other people had been doing, with some enhancements, in a standardized way. Usually resulted in bigger, slower binaries, too (LISP/Java syndrome).

Myself, I've used C as a modular language, which offers the same major benefits (code reusability, project scalability), but I've never used it as an OO language, because I could never see any benefit to doing so. If I worked with 200 other programmers on the same gigantic coding project, sure, but 95% of mine involve 1-5 programmers, so I don't see what advantage there'd be.

If you worked for Microsoft or a game company or something, sure, OO all the way! That's just not me. *shrug*

No. It cannot, because it isn't. No aspect of OO is present in the C language.
As your example says, in its first sentence: "This paper presents some programming techniques that allow large projects based on ISO C89 to get the benefits of object oriented design."
The example at http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html is a painful attempt at making some of the worst aspects of C++ appear as conventions in C.

I've never understood this concept that OO is only significant for "large projects". I find it just as useful for small projects of one programmer/designer (me).

I regularly mess about with mathematical code. I like C#. Having my own "Complex" numbers is convenient. Strange derived classes are nice ("Polar", "Direction", "Line", "Vector"). Strong typing cuts down on mis-coding. Debugging becomes simpler. Controlled/purposeful error handling. Redefining operators. Coercions. UI design. Custom controls. Waffle, waffle. All from a consistent framework that (usually) makes sense. An environment where you don't have to re-invent the wheel every time.

Oooppss... I seem to be ranting (and raving?). It's just that I feel strongly that people miss the point of OO. It just helps in the direction of "Algorithms + data structures = programs" (Niklaus Wirth), my bible.

The ideal programming language would be one where it was possible to sketch out the algorithms you wish to employ, and define the data structures that are involved, and you then did nothing else. With C, the data structure side was handled a little loosely, the algorithms, hardly at all. C++ added verbiage, mainly. C# is getting closer to the ideal.