OOP is an expensive disaster which must end

[Russ P.]

That's the title of this article:

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

The article seems to be getting a lot of traction. I joined in a discussion about it on LinkedIn and pointed out some pretty basic errors, such as this:

"In fact, OOP gives us a vast graph of mutable objects, all of which can mutate each other, with a change in any one object possibly setting off a cascade of mutations that propagate out through the graph in ways that are often too complicated for the human mind to comprehend."

So the author seems to be unaware that OOP can be done with immutable objects. Does that discredit the entire article? I think so, but apparently not everyone agrees. In fact, there seems to be a lot of outright hostility to OOP out there. The article claims that everything that can be done with OOP can be done in a simpler and better way with pure FP. I've seen this claim before.

I realize that Martin O. and others have discussed the integration of OOP and FP many times, but what I have yet to see is a clear explanation of what OOP adds that cannot be done as well with pure FP. Can anyone explain that or provide a link to an explanation that is already out there? Thanks.

--Russ P.

[Bardur Arantsson]

Not that I necessarily agree that OOP (well, subtyping, really) can
meaningfully be unified with FP, but...

I think in this case the phrase "don't feed the troll" may apply.

Regards,

[Raoul Duke]

>> I realize that Martin O. and others have discussed the integration of OOP
>> and FP many times, but what I have yet to see is a clear explanation of
>> what OOP adds that cannot be done as well with pure FP. Can anyone explain
>> that or provide a link to an explanation that is already out there? Thanks.

http://lambda-the-ultimate.org/node/2410

[Rüdiger Klaehn]

Here is a scala example from the pamphlet. This is probably the most
non-idiomatic piece of scala code I have ever seen. I think this does
not even deserve discussion.

public boolean hasUpperCase(String word) {
if (null != word)
return any(charactersOf(word), new Predicate() {
public boolean apply(Character c) {
return isUpperCase(c);
}
})
else
return false;

> --
> You received this message because you are subscribed to the Google Groups "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[martin odersky]

I realize that Martin O. and others have discussed the integration of OOP and FP many times, but what I have yet to see is a clear explanation of what OOP adds that cannot be done as well with pure FP. Can anyone explain that or provide aa link to an explanation that is already out there? Thanks.

Objects done well provide a lightweight module system (in the sense of ML). The requirement for a good module system is something that's often overlooked when all you do is a simple application, but its lack becomes painfully apparent for large systems and systems that are maintained over time.

You can go the SML route and provide a module system and a functional core language. But then there's the pressure that you want to generalize your modules to be more flexible, which means you want them to become recursive and first-class. If you do that, you end up with a de-facto object system in addition to your core language of algebraic data types and functions.

Scala's approach of unifying modules and objects is more parsimonious: The same constructs define the core language and the module language. So Scala is simpler, in the sense that fewer concepts are needed to describe the total feature set.

Does this explanation help?

Best,

 - Martin

 

--Russ P.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Martin Odersky
EPFL

[martin odersky]

On Tue, Dec 2, 2014 at 9:50 PM, Rüdiger Klaehn <rkl...@gmail.com> wrote:

Here is a scala example from the pamphlet. This is probably the most
non-idiomatic piece of scala code I have ever seen. I think this does
not even deserve discussion.

public boolean hasUpperCase(String word) {
if (null != word)
return any(charactersOf(word), new Predicate() {
public boolean apply(Character c) {
return isUpperCase(c);
}
})
else
return false;

}

It's not Scala code at all. This is Java. - Martin

 

On Tue, Dec 2, 2014 at 9:45 PM, Raoul Duke <rao...@gmail.com> wrote:
>>> I realize that Martin O. and others have discussed the integration of OOP
>>> and FP many times, but what I have yet to see is a clear explanation of
>>> what OOP adds that cannot be done as well with pure FP. Can anyone explain
>>> that or provide a link to an explanation that is already out there? Thanks.
>
> http://lambda-the-ultimate.org/node/2410
>
> --
> You received this message because you are subscribed to the Google Groups "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Martin Odersky
EPFL

[Russ Paielli]

Yes, I pointed out in the LinkedIn discussion that this is Java code mislabeled as Scala. I also showed a trivial one-line solution to the example problem.

You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/EJcyNz9s8I8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Russ Paielli]

I'm pretty sure this article is not a troll. These guys really believe it, and although they may be wrong they are not stupid.

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/EJcyNz9s8I8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Rüdiger Klaehn]

I noticed that too. Quite embarrassing. I guess I should not post with
a toddler-induced sleep deficit... But in the pamphlet it is given as
scala code :-/

[Russ Paielli]

Yes Martin, that certainly helps, and thanks for taking the time to reply. If you can find time, I suggest you expand that into an article/essay and post it somewhere that is easy to find. Then whenever these anti-OOP articles pop up we can just post a link to it.

--Russ P.

--

http://RussP.us

[Alan Burlison]

On 02/12/2014 20:42, Bardur Arantsson wrote:

> I think in this case the phrase "don't feed the troll" may apply.

http://www.smashcompany.com/mission-statement

----------
Not Found: 404 error

Apologies, but the page you requested could not be found.
Perhaps try a search in the top right corner.
----------

Seems rather fitting....

--
Alan Burlison
--

[Simon Ochsenreither]

On the "sub-module" level, I'd say that where OO really shines is dynamic dispatch (in fact, I'd say it's the only thing that really matters about OO below modules).

One of the classical examples is the "Set problem", where you want to abstract over Sets with different implementations (and therefore different constraints).
In most functional languages you don't really have a nice way to hide the differences (e. g. one Set needs Eq, another one needs Ord, and a third one needs Hash) from the user which causes the constraints to leak into all the code.

In Scala, this is usually solved by combining the constraint with the data structure at construction, but this only works because typeclass instances are first class values. In e. g. Haskell this approach is kind of horrible, because typeclass instances can be incoherent, with no reasonable way for the developer to check for coherence (typeclass instances are second-class) and disallowing orphans is like burning down your neighborhood because of an overgrown garden.

[Matthew Pocock]

Hi Simon,

I agree. The part of common OO languages that is the difference that makes a difference (from a language theoretic point of view) is the dynamic dispatch. To get any kind of scalability, you need to be able to say the same thing and get the running app to do different things. This requires some form of dispatch resolution. The two choices I know of are to decide upon the dispatching at compilation, or at runtime. OO is a nice (and potentially clean) model for run-time dispatch. Typeclasses are a nice (and potentially clean) model for compile-time dispatch. IMHO, neither one of these is right for every situation. I like how they can be convinced to co-exist within scala.

Matthew

--

You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Dr Matthew Pocock

Turing ate my hamster LTD

mailto: turingate...@gmail.com

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: matthew...@ncl.ac.uk

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Jesper Nordenberg]

Den onsdagen den 3:e december 2014 kl. 16:58:58 UTC+1 skrev Simon Ochsenreither:

In Scala, this is usually solved by combining the constraint with the data structure at construction, but this only works because typeclass instances are first class values. In e. g. Haskell this approach is kind of horrible, because typeclass instances can be incoherent, with no reasonable way for the developer to check for coherence (typeclass instances are second-class) and disallowing orphans is like burning down your neighborhood because of an overgrown garden.

This doesn't have much to do with OO though as you can have first class instances (basically records) and implicit parameters in functional languages as well (Agda has this for example). It all comes down to the definition of OO and the key concepts there IMHO is the implicit this parameter and subtyping which leads to interesting combinations. Basically all other concepts available in common OO languages can be easily emulated in an FPL using records and functions/closures.

/Jesper Nordenberg

[Simon Ochsenreither]

This doesn't have much to do with OO though as you can have first class instances (basically records) and implicit parameters in functional languages as well (Agda has this for example).

Yes, I agree. It was an elaboration how the lack of non-painful dynamic dispatch forces some languages to come up with less-than-great (for use-cases of dynamic dispatch) workarounds, and not directly related to OO.
 

It all comes down to the definition of OO and the key concepts there IMHO is the implicit this parameter and subtyping which leads to interesting combinations. Basically all other concepts available in common OO languages can be easily emulated in an FPL using records and functions/closures.

While everything can be emulated, I have yet to see a functional language where "emulating" dynamic dispatch crossed the line from "hey, have a look at this crazy hack" to "this is sufficiently clean implementation of the concept which I'd recommend using in real projects".

[Som Snytt]

[Insert ad for scala-debate.]

I realize the train has left the station and it would be closing the barn door post-equum.

[Jesper Nordenberg]

On Wednesday, 3 December 2014 18:22:07 UTC+1, Simon Ochsenreither wrote:

While everything can be emulated, I have yet to see a functional language where "emulating" dynamic dispatch crossed the line from "hey, have a look at this crazy hack" to "this is sufficiently clean implementation of the concept which I'd recommend using in real projects".

Well, function values are used for dynamic dispatch all the time in FP, and records containing functions is a clean emulation of stand-alone interfaces and objects. It's when subtyping and the this type is introduced things gets ugly (or even impossible) to emulate in an FPL.

/Jesper Nordenberg

[Rich Oliver]

"OOP is an expensive disaster which must end"

Articles like this are useful because they weed out the stupid and the gullible. Lets just parse that claim for a few seconds. In the those few seconds three words come to mind for me: facebook, Twitter, iPhone. All relied heavily on object orientated languages. And then of ocurse there's GTA V another object orientated finacial catastrophe. That game took hours to reclaim its development costs. No doubt our anti-OO geniuses could have reclaimed their development cost in minutes.

[Haddock]

"OOP is an expensive disaster which must end"

I have read similar blog articles and posts to various forums of programming languages during the last months. I think the idea that OO is over-hyped is also incurred by languages like Go, which deliberately does not have inheritance. Rust does not have it so far (but they say they will add it when they know how). Then FP has moved more into the limelight compared to earlier, which may give reason for the idea that other things should move in place now. Maybe there is also some kind of fatigue with one paradigm being so long in place. There seems to be some human want for new things to appear after a while. 

On the "sub-module" level, I'd say that where OO really shines is dynamic dispatch (in fact, I'd say it's the only thing that really matters about OO below modules).

This is a more seen from technical point of view. Dynamic dispatch is for inheritance and interfaces (that's why also Go has dynamic dispatch, although it does not have inheritance). As I understand it on a design-level OO is mostly about information hiding. To me this is the essence of the book by Grady Booch (Object Oriented Analysis and Design with Applications). Information hiding is about removing complexity: split it up in small manageable parts and have the "what" on the surface and the "how" in lower layers. This is to me still a very good design principle, inheritance or not.

Cheers, H.

[Bardur Arantsson]

I think you may have missed the word "expensive". The title is probably
just clickbait, but I would contend that any of the things you mentioned
could have been written in C or even assembler, if we ignore obvious
platform limitations like JS-for-browsers. However, would it have taken
as much effort (i.e. developer salaries) in C++, Java, Scala, or what
have you?

Your mentioned projects are just an existence proof that "X can be done
in paradigm/language Y" is true, they don't say anything about the
effort required... and *that's* what's being argued about.

Regards,

[Russ Paielli]

Yes, I agree. The fact that successful, large projects were implemented in OOP is certainly evidence of its effectiveness, but it is not proof that it was the best approach even for those projects. The problem is that there is never a controlled study to implement the same functionality in a non-OO language. That would obviously be impractical, which why it is difficult at best to objectively compare the effectiveness and efficiency of different languages and programming styles.

The only controlled language-comparison study that I am aware of was a comparison of C++ with Ada. Taking into account the total lifecycle of the software, the result IIRC was that Ada takes roughly half the man-hours as C++. That's of course why everyone switched from C++ to Ada back in the 90s!

But seriously though, I did not give the original article much credence once I found the glaring errors, but if you look at the LinkedIn discussion you will see something like 60 comments, and all but a few of them (mostly mine) praise the article.

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/EJcyNz9s8I8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Simon Ochsenreither]

Clojure and Elixit don't have types, so I'm not sure they qualify for "real projects".

On Thu, Dec 4, 2014 at 12:18 AM, gvim <gvi...@gmail.com> wrote:

On 03/12/2014 17:22, Simon Ochsenreither wrote:

While everything can be emulated, I have yet to see a functional
language where "emulating" dynamic dispatch crossed the line from "hey,
have a look at this crazy hack" to "this is sufficiently clean
implementation of the concept which I'd recommend using in real projects".

Clojure's multi methods and Elixir's equivalent are more than adequate for real projects.

gvim