Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You should try to be open to it, OP tries to make a point and not just rant. Typical OO structures don't fit the way some (small majority?) of programmers think. Is becoming proficient at OOP an exercise in brain rewiring? Or should we reject it, since it doesn't come naturally? Worthy of discussion and not just outright dismissal IMO.


The problem is that he really doesn't have a point - only a straw man. He doesn't like inheritance, but he likes message passing. Well, guess what - Alan Kay, the founder of the OO paradigm, also consider message passing to be the most important part.

This is at most a rant against the misguided implementation in certain mainstream languages. Not against OO in general.


True. But in reality, when you hear term "OO" people mean Java and C++, not the orginal Alan Kay's concept. Sad but true.


When you look at books that introduce OO, and languages that incorporate it, it's usually presented as is-a and extends and inheritance.

The fact that Alan Kay meant something different is irrelevant.

While you can build messaging and composition into most languages, they're usually considered application models in their own right, not core features. (Objective C is an exception, among a handful of others.)

So I think it's a valid question - why do mainstream languages still present this model as a core feature when other models are less rigid, more expressive, easier to work with, and better candidates for language fundamentals?


That's irrelevant for all practical purposes till the one true Scotsman shows up. I have noticed that none of the other programming paradigms need as much of a defense via the true scotsman falacy, inspite of those languages being far from their theoretic ideal.


He says that the majority of problems, not the minority of programmers, are unfit for OO.

On the contrary, we see OOP being used in the majority of programming projects.

I have been waiting for a proof that functional programming is easier for a very long time now. It doesn't seem to be the case, and I'm getting sick of fanboyism that insists that it is.


No way. Majority of a so-called OOP code is nowhere close to an adequate representation of the problems it is supposed to solve. Most of the code out there is either not very OOP, breaking the purity for the sake of common sense, or a pile of convoluted overbloated crap.


Speaking of inheritance and adequate representation of reality, it's extremely hard to come up with something real that looks like a class hierarchy. The two things I was able to come up with are the tree of life and some military or bureaucratic hierarchies.


More unsubstantiated claims. But even if you could prove all of them to be true, the superiority of alternatives is a different matter entirely.


Superiority is obvious. An alternative is to represent the real world problem domains as is, without hammering them into any stupid, inadequate "models" like OO, functional, whatever else.


I've been open to it. I went on a journey of SICP, Common Lisp, Haskell and F# over three years.

I went back to my OO roots and c#/c++ and carried on mostly as I did before. Why?

Simply that its easier to rationalise a large system in terms of objects and actions. Even atypical OO languages like Go use this model.

What I did take away was limited mutability (not total immutability) and some functional paradigms such as map/filter and a well founded opinion that one shouldn't listen to programming religious wars and use what works for you.


> Simply that its easier to rationalise a large system in terms of objects and actions.

I'm currently of the opinion that OO is basically a form of module system: useful for carving up large problems into more manageable ones, but not necessarily a good model for writing algorithms.


Good points. I, personally, would say that the most of the wiring is defined by natural languages we use. If programming language cuts against the grain of those, it is bound be hard to learn and use.


OO does not fit most of the real world problems, not just a particular way of thinking.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: