OOP is an expensive disaster which must end

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Bardur Arantsson
On 2014-12-02 21:17, Russ P. wrote:

> 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.
>

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,


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Rüdiger Klaehn-2
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;
}

On Tue, Dec 2, 2014 at 9:45 PM, Raoul Duke <[hidden email]> 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Martin Odersky
In reply to this post by Russ P.


On Tue, Dec 2, 2014 at 9:17 PM, Russ P. <[hidden email]> wrote:
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 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Martin Odersky
In reply to this post by Rüdiger Klaehn-2


On Tue, Dec 2, 2014 at 9:50 PM, Rüdiger Klaehn <[hidden email]> 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 <[hidden email]> 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Russ P.
In reply to this post by Rüdiger Klaehn-2
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.

On Tue, Dec 2, 2014 at 12:50 PM, Rüdiger Klaehn <[hidden email]> 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;
}

On Tue, Dec 2, 2014 at 9:45 PM, Raoul Duke <[hidden email]> 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 [hidden email].
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Russ P.
In reply to this post by Bardur Arantsson
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.

On Tue, Dec 2, 2014 at 12:42 PM, Bardur Arantsson <[hidden email]> wrote:
On 2014-12-02 21:17, Russ P. wrote:
> 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.
>

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,


--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Rüdiger Klaehn-2
In reply to this post by Martin Odersky
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 :-/

On Tue, Dec 2, 2014 at 9:57 PM, martin odersky <[hidden email]> wrote:

>
>
> On Tue, Dec 2, 2014 at 9:50 PM, Rüdiger Klaehn <[hidden email]> 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 <[hidden email]> 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 [hidden email].
>> > 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 [hidden email].
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Martin Odersky
> EPFL
>

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Russ P.
In reply to this post by Martin Odersky
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.

On Tue, Dec 2, 2014 at 12:55 PM, martin odersky <[hidden email]> wrote:


On Tue, Dec 2, 2014 at 9:17 PM, Russ P. <[hidden email]> wrote:
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 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL




--

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Alan Burlison
In reply to this post by Bardur Arantsson
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
--

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Simon Ochsenreither-3
In reply to this post by Russ P.
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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Matthew Pocock-3
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

On 3 December 2014 at 15:58, Simon Ochsenreither <[hidden email]> wrote:
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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Jesper Nordenberg-2
In reply to this post by Simon Ochsenreither-3
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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Simon Ochsenreither-3

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".

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

som-snytt
In reply to this post by Jesper Nordenberg-2
[Insert ad for scala-debate.]

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


On Wed, Dec 3, 2014 at 8:53 AM, Jesper Nordenberg <[hidden email]> wrote:
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

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Jesper Nordenberg-2
In reply to this post by Simon Ochsenreither-3
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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Rich Oliver
In reply to this post by Russ P.
"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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Haddock
In reply to this post by Russ P.

"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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: OOP is an expensive disaster which must end

Bardur Arantsson
In reply to this post by Rich Oliver
On 2014-12-04 12:15, Rich Oliver wrote:

> "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.
>

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,

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
12