Live data from Hacker News

Object Oriented Programming is an expensive disaster which must end

smashcompany.com

41–50 of 123 posts

Re: Object Oriented Programming is an expensive disaster which must end

#41

Another 'the sky is falling' article ;) Can someone provide a TL;DR who worked through the entire write-up? When I hear 'OOP must die' I can't help but think that we're throwing away the good bits too and will reinvent the wheel in a few years. It would be good to define the absolute essence of OOP first, because in 30 years it has been overloaded so much with different meaning that it means everything today. For ins…

> To me the pragmatic essence of OOP is that it groups the data and the code which works on that data. If there's a pure C library which has a function to create some sort of 'context' and then has functions which take a context pointer as argument, then this is object-oriented to me. Most other features, like classes, inheritance, runtime polymorphism is just sugar-topping; useful in some cases, but not the essence.

You nailed it.It's just more elegant to group things as a class than having fopen,fread,fclose where you pass a resource as a first argument. Polymorphism then is the consequence of that design since you could have the same interface for a file,a socket,an archive or whatever. When in use,you can ignore the nature of the resource and just remember it can be opened,read or closed,which allows to write abstract logic on top of it.

Re: Object Oriented Programming is an expensive disaster which must end

#42
Procedural programming for the win. One can write in an object-oriented style or functional style in C, but the language has enough of a barrier to entry to writing code of these varieties that most people write KISS procedural code unless the particular situation really benefits from doing otherwise.

Re: Object Oriented Programming is an expensive disaster which must end

#43
post #39

Earlier quoted context omitted.

One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…

The article pulls a Fallacy fallacy, otherwise known as an "argument from fallacy". Basically what he says is "none of the arguments against me are correct, because fallacy X". I simply ignore such statements, because they make discussion impossible.

Oh, so what happens if all the arguments against him are actually fallacious? You realise that you would have ignored him based on the fallacy of the Fallacy fallacy?

Re: Object Oriented Programming is an expensive disaster which must end

#44

What I would love to see monthly or quarteryearly "competition" between functional and object oriented programmers. For each competition a jury selects a problem and then everybody can try to solve this problem as nice and clean as possible for his preferred programming language / paradigm. The best solutions are then judged / commented on by experts and put on a website. By this you would have perfect examples how e…

Functional has not much to do with object oriented. Scala for example is both functional and OO. I think you mean the competition between imperative and functional languages.

It's not clear where the line is to me.I mean,it's obvious fr Erlang or Haskell.But isnt clojure imperative to some extent?

While I understand the notion of pure FP.Shouldnt we say that FP is more of a toolbox that can be used in many languages,some making it easier than others. I mean FP in Java 7 is a pipe-dream while any language that has lambdas can be considered as functional? or should lazy evaluation be another precondition?

that's a question.

Re: Object Oriented Programming is an expensive disaster which must end

#45

Another 'the sky is falling' article ;) Can someone provide a TL;DR who worked through the entire write-up? When I hear 'OOP must die' I can't help but think that we're throwing away the good bits too and will reinvent the wheel in a few years. It would be good to define the absolute essence of OOP first, because in 30 years it has been overloaded so much with different meaning that it means everything today. For ins…

Basic tl;dr: Some HN users where mean to the writer so he went on a big rant on how they were all wrong while spouting wild irrelevant technical reasons why tools that are designed to model certain classes of real world systems are completely false and everyone in the world is too dumb to acknoledge his genius.

Re: Object Oriented Programming is an expensive disaster which must end

#46
This is a truly fantastic post. It isn't a rant. It's a story of enlightenment that I encourage all HN'ers to read and absorb.

Disregard or play down the contents of this fantastic post at your peril. Understanding it and groking it could save you 5 years, 10 years or even a lifetime of writing software in the wrong way.

Re: Object Oriented Programming is an expensive disaster which must end

#47

But tell us how you really feel! I had to bail out about 1/3rd of the way through. Wow, what a rant. I don't mind the invective, and I'm becoming more skeptical of OOP the more I see larger-scale FP apps work. Mutable state and hidden dependencies are killing us. But I do not like the way this essay is arguing its case. Please do not trot out famous people, tell me their ideas, and then show me how things did not wor…

You really should care more about Kay has to say. There are few truly brilliant people out there, and Kay is one of them.

Re: Object Oriented Programming is an expensive disaster which must end

#48
post #31

Mediocre and bad code tends to multiply entities. On a small scale it's usually redundant global and local variables, or just plain stupid code like this: if (NULL == lpDataPointer) { /* Return FALSE */ return FALSE; } else { /* Return TRUE */ return TRUE; } Now give the same programmer an OOP language and see what happens. Even a bigger disaster masqueraded as an OOP system. I know I kind of repeat the author's True…

Whats wrong about the above code? Does it not do what it means to do? Is your personal feeling for how this construct should be written syntactically any measure of intelligence?

Re: Object Oriented Programming is an expensive disaster which must end

#49
post #20

Mate, you should learn Scala before writing about it... scala> def hasUppercase(s: String) = s.exists(_.isUpper) hasUppercase: (s: String)Boolean scala> hasUppercase("Charlie Brown") res2: Boolean = true scala> hasUppercase("schmuck") res3: Boolean = false

From TFA: Please note that, below, when I refer to a multi-paradigm language, such as Scala, as an OOP language, I am specifically referring to the OOP qualities in that language. And I would like you to ask yourself, if you use a multi-paradigm language to write in the “functional” paradigm, are you actually gaining anything from the OOP qualities of that language? Could you perhaps achieve the same thing, more easi…

Yes, isUpper is a method on Char, _.isUpper is a lambda that is given to exists, which is a method on the trait TraversableOnce, which String happens to implement, along with many other things, such as Option and Future. Where's the OO and where's the functional? In the Clojure example in the OP does the author realise that all of those things are in effect Java objects? Does any of this make the code better or worse?

But that's not the point, the Scala code provided there is beyond ignorant, whoever wrote that has no right to be judgemental of the language or its founding paradigms.

Re: Object Oriented Programming is an expensive disaster which must end

#50
What OO brought to The table (and what many advocates of FP are forgetting) is context sensitivity, that is, functions/methods are brought in scope by the owning object rather. Typing dog.bark() is a thousand times more powerful in terms of tooling than bark(dog) or SomeDogPackage::bark(dog). I prefer the FP style of coding but I can't see average devs giving up on Java/C# style tools.

Sure OO brought a lot of little code smells too, and we often end up making bad code, but it's not like we have to. Polyglot programmers that use e.g. Java+Scala or C#+F# probably make their OO code much better than others. I have almost completely stopped using mutable objects, long inheritance chains and nulls in C#, as an influence from F#.

For some scenarios having mutable objects is a near perfect fit (scene graphs for games or UI:s are good examples of code where both FP and non-object imperative usually looks worse).

Post reply on HN