OOP is a dead end (for all your C++ and Java programmers)

[netytan]

I've noticed there are a [relatively] large number of C++ programmers here, honestly I can't fathom why but I know you have your reasons. For one it's easier to get a job in C++ or Java than in say ASM or even better Lisp – they won't be good jobs but any job is better than none right?

I beg to differ on this statement of course, having a good job is much more valuable to me (and should be to any good programmer). It's not my attempt to start anything here I'd just like to hear your reasons for using such truly indignant languages.

There are other excuses for using C++/Java etc, I've heard them all no doubt but most of them hang around one main concern: money


Ignoring this, because I really can't say anything you don't already know. I was most disturbed (and more than a little amused) to read that some people here believe that C++ and more generally OOP makes better programmers.

This could NOT be further from the truth, C++/Java makes sloppy programmers as evident by the average quality of software in them today. This is because both languages encourage ridged inelegant thinking.

Let me explain:

programming languages are not equal, simply because most [all] languages today are turing compliant doesn't mean that each language is as powerful as the next. If it where then it wouldn't matter which was used.

(A note on power here: power in the sense of programming languages is measured in abstraction and not speed as may be expected.)

Contrary to common belief programming languages are not just tools, they are a medium for expression. Our expression. In order to program in any language well you have to think in that language, when a language imposes limits on the programmers thinking (as do most mainstream languages to varying degrees) the only result can be a bad program which teaches you nothing.

Like a natural language student; how can a programmer express for example, the color of table in a language that doesn't have any concept of what color is or how to describe it, or any way of expressing a new concepts within it's design.

This is rare but there are languages this flexible, which I would urge you all to look at for the obvious reason that, without doubt they will make you better programmers even if you never use them!

An interesting response to this problem in language design is to make languages stricter?! OOP is one such abstraction. In order to program in OOP we make everything an object conceptually (or as much as possible depending on the design of the language/extension) rather than generalizing.

This is done in OOP without any regard for the fact that not everything is in reality an object. Or for that matter represented as an object making the abstraction synonymous with a shackle.

A common reason used to justify OOP as a medium is that it helps prevent errors while protecting data and improving modularity of the code in question, and hence allowing more programmers to work on the same task simultaneously.

Sounds good but in practice it doesn't seem to work very well at all, some of the worst examples of large-scale programming are written in this way. Maybe we should take advice from institutions like MIT here as to what the languages are best? It would make sense.

We should also take into account that the best software is written by small groups of people using more powerful languages, not huge teams using C++ or Java.

OOP does help make C++ and Java programs more modular but only because of flaws present in the initial design of the language – lack of flexibility/polymorphism (see Haskell).

C++ for example was designed to provide a way to work around C's ridged type-system

In more flexible languages the prevention of bugs is done via improvements in the way programmers can express their ideas, not by limiting this as we have shown. We now have a case where the measures put in place to prevent such errors are actually causing them, and self propagated though industry propaganda, usually by people who know no better.

Weather you agree or not OOP as a model for programming is a dead end that will eventually be bread out of us, to be replaced by other more elegant ideas such as meta-programming (programs that write programs) and functional programming to name just two.


That any of you can say that C++ makes better programmers is in a broader sense  a testament to the fact that average programmers program without being exposed to good paradigms because of market influences or god forbid personal choice.

The only way to become a good programmer, or a great programmer if you consider the majority of programmers to be good programmers already is to expose yourself to these ideas. Not hide behind the industries "standard" idea which crawls along literally 50 years behind (see Lisp).

Try thinking for yourself?

Looking forward to meeting you all, Take care,

Mark.

[Yegg]

I completely agree. 

[MyndFyre]

I've noticed there are a [relatively] large number of C++ programmers here, honestly I can't fathom why but I know you have your reasons. For one it's easier to get a job in C++ or Java than in say ASM or even better Lisp – they won't be good jobs but any job is better than none right?

It is interesting that you raise this point.  Are you trying to say that it is better to program in ASM or Lisp than C++ or Java?  Perhaps for small-scale jobs or drivers.  But ASM is unwieldy and will quickly grow too large to manage effectively.

Ignoring this, because I really can't say anything you don't already know. I was most disturbed (and more than a little amused) to read that some people here believe that C++ and more generally OOP makes better programmers.

I think OOP *can* make better *programs*.  If the programmer is broken, though, no technology is going to fix him (or her).

This could NOT be further from the truth, C++/Java makes sloppy programmers as evident my the average quality of software in them today. This is because both languages encourage ridged inelegant thinking.

I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.  

(A note on power here: power in the sense of programming languages is measured in abstraction and not speed as may be expected.)

If I am correct in interpreting your above statement about assembly and Lisp, I think you just contradicted yourself.  C++/Java are far better than ASM at abstraction.

Contrary to common belief programming languages are not just tools, they are a medium for expression. Our expression.

I think that depends on whom you ask.  That's true for hobbyist programmers.  But even for us, I sometimes make a tool program just for something really quick.  When I do so it's just a tool.

In order to program in any language well you have to think in that language, when a language imposes limits on the programmers thinking (as do most mainstream languages to varying degrees) the only result can be a bad program which teaches you nothing.

I disagree again.  I don't think you have to think *in that language*, but it is necessary to be able to deconstruct an algorithm in your mind from the starting point and end point.

Like a natural language student; how can a programmer express for example, the color of table in a language that doesn't have any concept of what color is or how to describe it, or any way of expressing a new concepts within it's design.

Are you suggesting that C++ is limiting in this fashion?  There is no natural construct for color in C++; however, it is usually typified in code:

Code Select Expand


typedef unsigned long int COLOR;

This works for us because the device we use to emit this abstract idea (color) in the physical world is a bitmapped projection tube.  It just so happens that there are 256 levels at which this tube can emit each of three colors.  When you combine a fourth color channel, Alpha, you come up with a nice structure that fits beautifully into a 32-bit numeric value like we have.

This is rare but there are languages this flexible, which I would urge you all to look at for the obvious reason that, without doubt they will make you better programmers even if you never use them!

So, since C++ and Java are this flexible, we *should* use them?

Sounds good but in practice it doesn't seem to work very well at all, some of the worst examples of large-scale programming are written in this way. Maybe we should take advice from institutions like MIT here as to what the languages are best? It would make sense.

Define "worst."  What OOP aims to accomplish, you said yourself:
* Easier maintenance.
* Faster development.
* Presents easier-to-understand abstract objects to us
All of these work in tandem.  You can really screw up an OOP program by, for example, making a class 10 layers deep without meaningful functionality added at each layer.  But I don't think I've ever seen an object more than 4 or 5 layers deep that didn't make sense to have at that place.

It doesn't take a good programmer to make an overbloated windbag of a program.  That's why design is a crucial step prior to the actual coding of a project.

We should also take into account that the best software is written by small groups of people using more powerful languages, not huge teams using C++ or Java.

Hrm....  That's an EXTREMELY bold statement with nothing to back it up.

OOP does help make C++ and Java programs more modular but only because of flaws present in the initial design of the language – lack of flexibility/polimorphism (see Haskell).

Uhh....  Java not being directly descendent of anything doesn't make up for any flaws present in the initial design of the language, because it was initially designed with polymorphism and "flexibility."

C++ for example was designed to provide a way to work around C's ridged type-system

C does NOT have a rigid type system.  C's type system is incredibly weak, in fact; C++ added many more type restrictions.

In more flexible languages the prevention of bugs is done via improvements in the way programmers can express their ideas, not by limiting this as we have shown. We now have a case where the measures put in place to prevent such errors are actually causing them, and self propagated though industry propaganda, usually by people who know no better.

You're starting to sound like a conspiracy theorist, and you're not backing up your claims with any reliable sources or even examples (such as a "more flexible programming language").

Weather you agree or not OOP as a model for programming is a dead end that will eventually be bread out of us, to be replaced by other more elegant ideas such as meta-programming (programs that write programs) and functional programming to name just two.

I don't believe it's a dead-end, although I do agree that it may eventually be replaced by a more sophisticated programming paradigm.  It would not surprise me in the least if we shifted to an object-functional hybrid, as there are simply some times when you want to explicitly define what you're expressing.

That any of you can say that C++ makes better programmers is in a broader sense  a testament to the fact that average programmers program without being exposed to good paradigms because of market influences or god forbid personal choice.

As I said before, I don't think that any particular language or technology can make someone a better programmer.  Some people simply cannot program; they can instruct a computer what to do, but they can't dialogue with the computer.

The only way to become a good programmer, or a great programmer if you consider the majority of programmers to be good programmers already is to expose yourself to these ideas. Not hide behind the industries "standard" idea which crawls along literally 50 years behind (see Lisp).

Try thinking for yourself?

All told, this was a fairly forward, possibly rude first post.  I hopefully have gotten past that in my replies, which absolutely reflect my opinions about what you've said.  Still, a lot of what you said sounds analogous to "We shouldn't use Windows because it's made by Microsoft, and they are a big company driving the most of the industry, so whatever they say must be bad."

Going against the grain for the sake of going against the grain is stupid.  It's why I don't respect Eminem, for example -- he works to be controversial for the sake of being controversial, not because he has anything relevant to say in his lyrics.

[Yegg]

I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.

You've missed the point in more than one aspect. However, this one was the biggest. Sure, C++ (just using this as an example) makes you thick more elegantly. But if we had more stable languages, this wouldn't be necessary in the first place.

[Warrior]

So until someone writes a "Stable" language ...OOP is necessary..

[Yegg]

So until someone writes a "Stable" language ...OOP is necessary..

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?

[MyndFyre]

I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.

You've missed the point in more than one aspect. However, this one was the biggest. Sure, C++ (just using this as an example) makes you thick more elegantly. But if we had more stable languages, this wouldn't be necessary in the first place.

I didn't miss any point.  I addressed precisely what he'd said in the first place: that it isn't the language itself that promotes rigid thinking, but the environment in which it is used.

Nor did I say in that quote that C++ makes you thick (or even think) more elegantly.  I'm sorry if that quote wasn't what you were addressing, but I took the time to delineate what I was responding to of the original post, and I think it's only polite for you to do the same.

What is a "more stable" language, by the way?

I would also like to point out that it would be nice if we were on the Starship Enterprise and could say "Computer, run a multispectral compositional analysis on the sample we just retrieved with the tractor beam."  However, at some point, someone had to program the computer how to understand that language, tell it what an analysis is, AND what a specialized multispectral compositional analysis is.  Some things you can't just meta-program without first programming the core.  Like assembly provides a necessary layer between object-oriented programming and hardware, so will OOP provide a necessary layer between meta-programming and lower-level access.  But that is some time off, yet.

[Warrior]

So until someone writes a "Stable" language ...OOP is necessary..

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..

[Yegg]

So until someone writes a "Stable" language ...OOP is necessary..

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..

IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).

[Warrior]

Well the opinion of the person making the accusations, not the one supporting him should be t he most relevant. Also what is a "Stable" language and what makes the current languages "Unstable" ?

[Yegg]

Well the opinion of the person making the accusations, not the one supporting him should be t he most relevant. Also what is a "Stable" language and what makes the current languages "Unstable" ?

I never said anything about any language's being "unstable". However I believe some languages are more "stable" than others. What I mean by "stable":
  1) A dynamicly typed language (personal opinion).
  2) A language that uses macros to their fullest capability.
  3) A language where recursion can be taken advantage of more efficiently.
  4) A language without the forceful use of pointers. (more of an opinion, again).
  5) A non-platform-dependant language where code can run, unchanged, from platform to platform.
  6) A language that is fast (not that speed is our most important concern).

That's most of what I consider "stable". I should have mentioned this before, rather than just using "stable" with really didn't make sense. Sorry.

[dxoigmn]

IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).

Define efficient, then I'll take up argument against list manipulation being the most "efficient" way of storing data.

LISP and Scheme are nice languages with some very neat constructs, but I am a believer of using the most appropriate tool (language) for the task at hand. Sometimes that is Java, sometimes that is C, sometimes that is Scheme, sometimes that is assembly.

[netytan]

Hi MyndFyre,

Thanks for the reply my intent wasn't to be controversial for the sake of being controversial, merely to express what I've learned though my experiences with languages not considered to be industry standard . And the paradigms used in those languages, the good bits of which I recognize have followed over into how I use more standard languages.

It is interesting that you raise this point.  Are you trying to say that it is better to program in ASM or Lisp than C++ or Java?  Perhaps for small-scale jobs or drivers.  But ASM is unwieldy and will quickly grow too large to manage effectively.

I was saying here that writing programs in ASM is preferable to C++ because of the control that you are given over the system, the flexibility, however this IMO should only be used when you want this control.

An ideal application for ASM would be for building domain specific languages.

Lisp is obviously preferable to C++ or Java because of the flexibility it's design allows, flexible languages allow flexible thought and new abstractions to be added to Lisp in moments which are indistinguishable to built-in concepts, while remaining comparable in speed to C for most (none number intensive) applications.

I think OOP *can* make better *programs*.  If the programmer is broken, though, no technology is going to fix him (or her).

I don't think this is true for the most part due to the fact that in order for a program to be good it's design should be as elegant as possible while maintaining efficiency and clarity of purpose.

I think it is possible to become a better programmer, however it takes a lot of work and exposure to appropriate way of thinking, this is what I proposed in this thread. There is a certain amount of talent involved but surely this could be overcome.

I disagree again.  I think many environments in which these languages are used is what encourages rigid and inelegant thinking.  I sit back right now and work on my projects when I can, asking myself, "is this the best way I can do this?  Is there something more I can add for my end-user here?"  These kinds of questions are difficult if not impossible to ask in the commercial world; businesses depend on timetables to stay competitive.  

Not to second guess you but you are not thinking "is this the best way I can do this?". What you're thinking is and I don't think you could deny it is: "is this the best way I can do this in this language?".

By definition the best solution to a problem would be the first, because in a well abstracted language the solution should run [fairly] parallel to the way you think, rather than You conforming to the mindset of the language you're being made to think in.

This is the difference here and in my experience it's a valuable one.

What you think is an elegant solution in one language is likely a very poor solution in another i.e. classes for instance are a less generalized and so less flexible closures.

If I am correct in interpreting your above statement about assembly and Lisp, I think you just contradicted yourself.  C++/Java are far better than ASM at abstraction.

You weren't, I was talking above about the quality of jobs available in the languages.

I think that depends on whom you ask.  That's true for hobbyist programmers.  But even for us, I sometimes make a tool program just for something really quick.  When I do so it's just a tool.

By that thinking a hobbits programmer must also be a bad programmer (at least this is how it sounds to my mind) and this simply isn't true, there are many fine hobbyist's out there. Many better than me .

You can't use any language without thinking in it, at least not well enough to accomplish anything real or good so I have to insist on this point because it's very important.

Learning your first language wasn't just about memorizing in keywords as you may be able to do now, it was about learning the languages concepts – learning to think in it.

I disagree again.  I don't think you have to think *in that language*, but it is necessary to be able to deconstruct an algorithm in your mind from the starting point and end point.

I'm taking this to mean that you need to understand the algorithm in a general sense, which I agree with entirely. But you need both to think in the language and to understand what you're trying to accomplish, in this case the algorithm.

Are you suggesting that C++ is limiting in this fashion?  There is no natural construct for color in C++; however, it is usually typified in code:

Code Select Expand


typedef unsigned long int COLOR;

This works for us because the device we use to emit this abstract idea (color) in the physical world is a bitmapped projection tube.  It just so happens that there are 256 levels at which this tube can emit each of three colors.  When you combine a fourth color channel, Alpha, you come up with a nice structure that fits beautifully into a 32-bit numeric value like we have.

This isn't expressing a new idea though, you're taking the color example to literally. When I speak of adding new concepts to the language I was talking more along the lines of say adding OOP to a language that didn't support it already using that language, as can be done in Lua.

defining a related type in this way doesn't do anything of value it's merely syntactic sugar. Haskell provides a much richer type system that you may be interested in looking at .

So, since C++ and Java are this flexible, we *should* use them?

I thought it was clear I wasn't referring to C++ and or Java here which are at the low end of what I consider flexibility, will be more explicit .

Define "worst."  What OOP aims to accomplish, you said yourself:
* Easier maintenance.
* Faster development.
* Presents easier-to-understand abstract objects to us
All of these work in tandem.  You can really screw up an OOP program by, for example, making a class 10 layers deep without meaningful functionality added at each layer.  But I don't think I've ever seen an object more than 4 or 5 layers deep that didn't make sense to have at that place.

It doesn't take a good programmer to make an overbloated windbag of a program.  That's why design is a crucial step prior to the actual coding of a project.

I agree that design is important however industry doesn't take into account that this design is done by people, who are liable to make just as many mistakes doing this as they are while implementing the design.

OOP may help to a small extent however it's a feeble hack over anything truly useful against such a large task. A way of limiting damage control and proving without a doubt that your programmers are working... hence all the bloat .

Uhh....  Java not being directly descendent of anything doesn't make up for any flaws present in the initial design of the language, because it was initially designed with polymorphism and "flexibility."

Java while not a direct decedent of anything was obviously influenced by languages before it, to assume it wasn't is just wrong. It's primary goal as expressed by sun was to fix the problems inherent in C++, targeting C++ programmers it made sense to include a C like syntax.

However you can't fix a bad concept by re-implementing it.

C does NOT have a rigid type system.  C's type system is incredibly weak, in fact; C++ added many more type restrictions.

When taken on its own C's type system doesn't get in the way, you get used to it and when you naturally use what it gives you. When compared to more flexible type systems C doesn't look do loose or so attractive.

I think you may have pegged me wrong on another point, I don't hate M$. Good on them for making a good run of a lucky break however I wont say that they write good software when they obviously don't.

Their personal philosophy is of only a passing interest but they're a bad model to base a company on. Sadly many do.

Hopefully not too offense ,

Mark.

[Yegg]

IMO, which does not matter at all, because no opinion matters, list manipulation is the most efficient technique for storing data. And I also beliebe that LISP, and languages based off of it (Scheme), use it to its full potential, far more elegantly than any other language. But remember, this is opinion and it does not matter (except to me).

Define efficient, then I'll take up argument against list manipulation being the most "efficient" way of storing data.

LISP and Scheme are nice languages with some very neat constructs, but I am a believer of using the most appropriate tool (language) for the task at hand. Sometimes that is Java, sometimes that is C, sometimes that is Scheme, sometimes that is assembly.

I don't find the need to define efficient, look it up. I'm also not about to start an argument with you. Notice how I said "I believe", and that it was *my opinion*. You also said that you are "a believe of using the most appropriate tool". We both have our own opinions. But I also agree with you, I use the appropriate tool, whatever it may be, as well.

[netytan]

So until someone writes a "Stable" language ...OOP is necessary..

And we have "stable" languages. Take a look at Common LISP and Scheme.
Why should OOP be necessary if there are better solutions?

Stable by what standards? Not by what you think I hope. Not a List programming language or something based of it..cmon..

Why not a Lisp? For over 50 years programming languages have steadily been progressing towards including Lisps feature set. Take modern "scripting" languages (and many other programming languages) for instance, of some 9 features that made Lisp unique only about half have managed to find their way into modern languages as of yet. Why?

Because including these in a language would make it a Lisp, and to paraphrase paul graham: the language designer could no longer claim to have invented a new language, just a Lisp dialect.

Lisp, designed 50 years ago is still ahead of the game in pretty much every way. With a good implementation Lisp code can run as fast as C code and yet has all the advantages of a so called scripting language (which it is not).

It supports multiple paradigms; functional programming seamlessly (as I'll describe in my next reply) and unrivaled extensibility.

Other languages of note being other functional languages such as Haskell and ML, Lua is also interesting in that it's also fairly extensible.

Mark.