The Artima Developer Community
Sponsored Link

Java Community News
Cedric Beust on Programming Erlang

44 replies on 3 pages. Most recent reply: Oct 9, 2007 11:30 AM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 2, 2007 6:11 AM
Reply to this message Reply
Advertisement
> Actually, his comments may be translated in various ways.
> I certainly agree with him, as I have not witnessed large
> improvements from OOP. Here is another approach:
>
> #1 - some times I want to have one more function for a
> data type I don't have the source code; impossible with
> OOP, easy with the 'classic' approach.

Difficult, yes, often. Impossible? No, not really.

> #2 - the strict classification of data types into classes
> creates many problems in many real world problems.
> Entities may be customers, customers may be persons, but
> later customers can be companies, for example. Trying to
> model that with classes asks for trouble.

Not really. Composition is the key here.

> #3 - very true regarding inheritance. Why should I inherit
> from when all I want is to use something?

You shouldn't. You can use something without inheriting from it in OO and in most cases you should not inherit. The suggestion that you must always inherit is absurd.

> #4 - the problem is not private state but not recognizing
> what are the side effects of encapsulation. And hiding
> state is certainly a problem when you want to modify
> software.

OO code isn't automatically easy to modify. That I'll agree with. What makes the hiding of state in FP better?

> As I have written many thousands of lines of
> object-oriented code, I have started to ask myself why I
> bother with all the class diagrams, patterns,
> encapsulations etc where simple datatypes and functions
> would make the code 10 times smaller and easier to
> comprehend...

What answer do you come up with?

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Cedric Beust on Programming Erlang Posted: Oct 2, 2007 6:36 AM
Reply to this message Reply
> #1 - some times I want to have one more function for a
> data type I don't have the source code; impossible with
> OOP, easy with the 'classic' approach.

That does not make OO 'suck'. It just makes it not suitable for every purpose and in every circumstance. C++, for example, allows you to extend the class interface with a non-member function.

> #2 - the strict classification of data types into classes
> creates many problems in many real world problems.
> Entities may be customers, customers may be persons, but
> later customers can be companies, for example. Trying to
> model that with classes asks for trouble.

How do you model that, trouble-free, with functions?

> #3 - very true regarding inheritance. Why should I inherit
> from when all I want is to use something? Non OOP does not
> have the problem of distinction of 'is a' from 'use a'.

Why do you have to inherit? Putting stuff in a class does not necessarily mean you have to inherit from it. You may benefit from a class in more ways than inheriting from it (e.g. encapsulation, state invariant, RAII if you use C++).

> #4 - the problem is not private state but not recognizing
> what are the side effects of encapsulation. And hiding
> state is certainly a problem when you want to modify
> software.

Not if you provide a good interface. Exposing state, on the other side, also has many downsides - that's one of the reasons people invented OO, remember?

> As I have written many thousands of lines of
> object-oriented code, I have started to ask myself why I
> bother with all the class diagrams, patterns,
> encapsulations etc where simple datatypes and functions
> would make the code 10 times smaller and easier to
> comprehend...

Well, that is for you to answer. Maybe in your case OO is not the right approach. OO is not perfect nor does it solve all problems best and with equal success. But it has its merits and to blatantly declare it as something that 'sucks' is not wise.

Decades ago, Brooks wrote about the non existence of the silver bullet. Whoever has not read that by now, should. Also, Stroustrup is a proponent of multi-paradigm programming. Given the amount of discussion going on about the 'one-right-way' it seems like a reasonable compromise:

http://www.research.att.com/~bs/glossary.html#Gmulti-paradigm-programming

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Cedric Beust on Programming Erlang Posted: Oct 2, 2007 6:45 AM
Reply to this message Reply
> #2 - the strict classification of data types into classes
> creates many problems in many real world problems.
> Entities may be customers, customers may be persons, but
> later customers can be companies, for example. Trying to
> model that with classes asks for trouble.

What's clearly amiss in the "Why OO sucks" article is the failure to recognize that most OO languages let you do OO *and* "regular" (C-like) programming.

Unfortunately, Erlang and C-like languages don't let you do OO, which makes their maintenance problematic (actually, C does let you emulate OO constructs with pointers, Erlang doesn't even give you that option).

It's hard for me to agree with an article that says "OO sucks, X is better" when any OO language will happily let you do X if you choose to.

I posted a follow-up to my Erlang review that clarifies these points and which also explains why I believe that a lot of claims made about Erlang are questionable:

http://beust.com/weblog/archives/000464.html

--
Cedric

Carsten Saager

Posts: 17
Nickname: csar
Registered: Apr, 2006

Re: Cedric Beust on Programming Erlang Posted: Oct 2, 2007 4:14 PM
Reply to this message Reply
> > #2 - the strict classification of data types into
> classes
> > creates many problems in many real world problems.
> > Entities may be customers, customers may be persons,
> but
> > later customers can be companies, for example. Trying
> to
> > model that with classes asks for trouble.
Couldn't agree more
>
> What's clearly amiss in the "Why OO sucks" article is the
> failure to recognize that most OO languages let you do OO
> *and* "regular" (C-like) programming.
>
Couldn't agree more
> Unfortunately, Erlang and C-like languages don't let you
> do OO, which makes their maintenance problematic
> (actually, C does let you emulate OO constructs with
> pointers, Erlang doesn't even give you that option).
>
Couldn't agree more
> It's hard for me to agree with an article that says "OO
> sucks, X is better" when any OO language will happily let
> you do X if you choose to.

I found after more than 10 years OO that on the level of "business objects" OO is hogwash, but on the 5% of the code that is consuming 90% of the CPU it is indispensable to have the reusabilty given by OO concepts. And inside this code I have usually some pretty procedural stuff that is well tested for correctness and performance. Outside these 5% of the core code you can do whatever you want, it simply doesn't really matter, but it helps that you have a language at hand that supports you instead of getting into your way. That's why - I can't resist - I cannot help but recommending Scala, because it is the only language I know that brings together a usable support for Actors (from Erlang), OO-strictness (a type system that reaches beyond my comprehension), functional elements (higher order functions , list comprehensions) and the simple procedural "get it done without writing a paper first"

(The 5% I am talking about are >200kloc not 200 lines)

Juancarlo Añez

Posts: 12
Nickname: juanco
Registered: Aug, 2003

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 5:03 AM
Reply to this message Reply
One can achieve the same terseness of Erlang's inter-process messages in languages like Java through proxies that implement the same interfaces as the target object but queue the requests instead of executing them right away. Return values can be handled through futures. The Voyager library (http://www.recursionsw.com/Products/voyager.html) has had these issues resolved since very long ago.

Queuing proxies may also be the solution that Eckel is seeking for Python, more so when in Python futures could be implemented transparently given the lack of static typing (clients can be suspended only when they access a future that is not yet available).

Steven Shaw

Posts: 15
Nickname: sshaw
Registered: Apr, 2003

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 6:49 AM
Reply to this message Reply
> Classes are types...

This is not true. Classes are _not_ types.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 7:39 AM
Reply to this message Reply
> > Classes are types...
>
> This is not true. Classes are _not_ types.

In Java, for example, a class or interface declaration is also a type declaration. When you create a new class, you create a new type.

I think this is a pretty useless observation with respect to the current conversation.

Steven Shaw

Posts: 15
Nickname: sshaw
Registered: Apr, 2003

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 7:46 AM
Reply to this message Reply
> In Java, for example, a class or interface declaration is
> also a type declaration. When you create a new class, you
> create a new type.
>
> I think this is a pretty useless observation with respect
> to the current conversation.

Hi James. In Java classes are not equivalent to types. Check the JLS.

The point was that even OO programmers have misunderstands about there own programming language. These kinds of language wars threads of full of misunderstandings and ignorance.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 7:50 AM
Reply to this message Reply
> Hi James. In Java classes are not equivalent to types.
> Check the JLS.

I get it and it's still useless information in this discussion.

> The point was that even OO programmers have misunderstands
> about there own programming language.

And people have problems with their use of English.

> These kinds of language wars threads of full of
> misunderstandings and ignorance.

I think someone already made that point. Actually, it was me, a couple days ago.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 8:01 AM
Reply to this message Reply
> Hi James. In Java classes are not equivalent to types.
> Check the JLS.

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#15372

"A class declaration specifies a new named reference type."

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#228205

"Class declarations define new reference types and describe how they are implemented"

Mike O'Keefe

Posts: 16
Nickname: kupci2
Registered: Mar, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 8:25 PM
Reply to this message Reply
> Basically, I'd like to see some concrete evidence of the
> various claims that are usually heard about Erlang, such
> as "makes multiprocess programming easy",
> "fault-tolerant", etc...
>

Are you not impressed by the YAWS vs. Apache example, or the fact that it is used in several Ericsson products such as AXD301, their ATM switch, and also by Nortel and T-Mobile, now that it is open-source?


http://www.sics.se/~joe/apachevsyaws.html
http://www.erlang.se/productinfo/index.shtml


Granted, there is always the Pink Floyd argument, i.e. that no matter how great the technology is, you still need someone talented to work the magic. I'm taking this from their "Live at Pompeii" video, in which Roger Waters discusses the fact that while any musician could use some the advanced equipment they have, not just anybody could turn that in to great music.

So I think it's some combination, just as anything. TrollTech's Qt library doesn't magically make apps better than the apps built with the tools available for Gnome - but, doesn't hurt that it's a nice, easy to use GUI toolkit.

Look at the wondrous things Google is achieving with Javascript - what would all those brilliant folks achieve with Erlang ;)

Mike O'Keefe

Posts: 16
Nickname: kupci2
Registered: Mar, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 3, 2007 9:40 PM
Reply to this message Reply
> Objection 2 - Everything has to be an object.
>
> "In an OO language "time" has to be an object. But in a
> non OO language a "time" is a instance of a data type."
>
> Classes are types in OO and Objects are instances of those
> types.
>

But the point here is that a Class, nor instance, is not the same as datatype, and here Joe would find good company with the Java designers, who made such a compromise. A good example is the idea of the "primitive" data type in Java vs. an object. You have int (primitive) and Integer (Class).

The Java design reasoning here was performance I believe, not sure I see Armstrong's issue however, nor his other points, I certainly wouldn't be trying to understand OO concepts reading his book ;)

Interestingly, And in fact this is one of the key points that Ruby fans will expound on, and other "pure" OO languages (vs., say, Java), is that "everything is an object". This is a good thing, Joe ;)

So one man's trash is another's treasure.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 4, 2007 2:53 AM
Reply to this message Reply
> > Actually, his comments may be translated in various
> ways.
> > I certainly agree with him, as I have not witnessed
> large
> > improvements from OOP. Here is another approach:
> >
> > #1 - some times I want to have one more function for a
> > data type I don't have the source code; impossible with
> > OOP, easy with the 'classic' approach.
>
> Difficult, yes, often. Impossible? No, not really.

Sometimes it is so difficult it is impossible.

>
> > #2 - the strict classification of data types into
> classes
> > creates many problems in many real world problems.
> > Entities may be customers, customers may be persons,
> but
> > later customers can be companies, for example. Trying
> to
> > model that with classes asks for trouble.
>
> Not really. Composition is the key here.

'Composition' as in making aggregates? but that is not object-oriented programming: the aggregate can not pose as one of its members.

Multiple inheritance? a great pain.

>
> > #3 - very true regarding inheritance. Why should I
> inherit
> > from when all I want is to use something?
>
> You shouldn't. You can use something without inheriting
> from it in OO and in most cases you should not inherit.
> The suggestion that you must always inherit is absurd.

I agree. But look at the literature: it's inheritance everywhere.

>
> > #4 - the problem is not private state but not
> recognizing
> > what are the side effects of encapsulation. And hiding
> > state is certainly a problem when you want to modify
> > software.
>
> OO code isn't automatically easy to modify. That I'll
> agree with. What makes the hiding of state in FP better?

If you don't hide state, then you can make functions which modify it outside of the module it as meant to be hidden in.

>
> > As I have written many thousands of lines of
> > object-oriented code, I have started to ask myself why
> I
> > bother with all the class diagrams, patterns,
> > encapsulations etc where simple datatypes and functions
> > would make the code 10 times smaller and easier to
> > comprehend...
>
> What answer do you come up with?

Procedural programming all the way, but with one "minor" change: selection of function to call based on the type of arguments (a.k.a. multimethods).

Or, to put it in another way, functional programming with assignments.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang Posted: Oct 4, 2007 3:10 AM
Reply to this message Reply
> > #1 - some times I want to have one more function for a
> > data type I don't have the source code; impossible with
> > OOP, easy with the 'classic' approach.
>
> That does not make OO 'suck'. It just makes it not
> suitable for every purpose and in every circumstance. C++,
> for example, allows you to extend the class interface with
> a non-member function.

Which defeats the whole concept of "methods together with data".

>
> > #2 - the strict classification of data types into
> classes
> > creates many problems in many real world problems.
> > Entities may be customers, customers may be persons,
> but
> > later customers can be companies, for example. Trying
> to
> > model that with classes asks for trouble.
>
> How do you model that, trouble-free, with functions?

A type is defined by its role. If I have an item which quacks, and a list of duckies, I don't care if item is a duck, because it quacks.

So there are two solutions:

1) structural subtyping
2) multimethods

In both cases, I can use a type for whatever purpose I want without a strict classification.

> solve all problems best and with equal success. But it
> has its merits and to blatantly declare it as something
> that 'sucks' is not wise.

Well, if it takes too much OO code to write even the simplest apps, OO has failed with me.

>
> Decades ago, Brooks wrote about the non existence of the
> silver bullet. Whoever has not read that by now, should.
> Also, Stroustrup is a proponent of multi-paradigm
> programming. Given the amount of discussion going on about
> the 'one-right-way' it seems like a reasonable
> compromise:
>
> http://www.research.att.com/~bs/glossary.html#Gmulti-paradi
> gm-programming

OOP is not another paradigm of programming, because in an OOP program, we still have procedures and variables. OOP is procedural programming with a different organization of code.

The original idea of OOP was to simulate our world by converting our reality to objects. For example, if you wanted to make a drawing app, you would have a paper object, a pen, a pencil, colors etc.

But today's OOP is nothing like that: it's full of factories, interfaces, concepts, abstractions, patterns, etc. A nice and small idea has turned into a nightmare.

Look at every Java library out there: incredibly complex. Even the simplest of tasks, like reading a few bytes from a file, requires lots of complicated steps to achieve.

A few moons ago I downloaded a Java library for a very simple task: FTP management (connection, disconnection, downloading, uploading etc). I was expecting a simple and basic interface, but the library had over 100 types and classes to learn!!! shock and awe.

And it's not the first example of that happening. In my company, we have abandoned the whole J2EE stack (JSPs, servlets, struts, xml, hibernate, whatever) and made a few simple data-aware widgets for ULC (www.canoo.com) where with a few lines of code many types of data driven applications can be easily built. And it works like a dream.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Cedric Beust on Programming Erlang Posted: Oct 4, 2007 7:43 AM
Reply to this message Reply
> A type is defined by its role. If I have an item which
> quacks, and a list of duckies, I don't care if item is a
> duck, because it quacks.

This analogy (like many others) breaks very easily since it completely ignores the problems introduced by duck typing, such as the impossibility to apply automatic refactoring on duck-typed programs.

Besides, I prefer real crab meat to fake one, myself.

> OOP is not another paradigm of programming, because in an
> OOP program, we still have procedures and variables. OOP
> is procedural programming with a different organization of
> code.

Fair enough.

> The original idea of OOP was to simulate our world by
> converting our reality to objects. For example, if you
> wanted to make a drawing app, you would have a paper
> object, a pen, a pencil, colors etc.
>
> But today's OOP is nothing like that: it's full of
> factories, interfaces, concepts, abstractions, patterns,
> etc. A nice and small idea has turned into a nightmare.

That's a possible interpretation. The way I see it, we have simply refined the idea of OOP to adapt it to the modern world of software engineering. We solve more complex problems these days, and our languages and tools need to adapt.

OOP has evolved spectacularly well to meet today's challenges, and one of the premises of my original post was to point out that Erlang (like most marginal languages) have not. There are no documented design patterns, no testing tools, no IDE's, very primitive profilers and debuggers, very little support for large distributed teams to work on huge code bases, poor tools to automatically publish documentation and code metrics, etc...

> A few moons ago I downloaded a Java library for a very
> simple task: FTP management (connection, disconnection,
> downloading, uploading etc). I was expecting a simple and
> basic interface, but the library had over 100 types and
> classes to learn!!! shock and awe.

How long was the code to download a file? I'm guessing a few lines of code, regardless of the other hundred functions in the API that are there for you if you need them (most likely, you won't). And even if indeed this library is bad, this observation has nothing to do with the alleged failure of OOP.

> And it's not the first example of that happening. In my
> company, we have abandoned the whole J2EE stack (JSPs,
> servlets, struts, xml, hibernate, whatever) and made a few
> simple data-aware widgets for ULC (www.canoo.com) where
> with a few lines of code many types of data driven
> applications can be easily built. And it works like a
> dream.

This is yet another proof of the success of Java and OOP in general: you have choices. Go compare this with what is available to write applications accessing distributed databases while offering web flow API's for your web site in more marginal languages...

--
Cedric

Flat View: This topic has 44 replies on 3 pages [ « | 1  2  3 | » ]
Topic: 2007 JCP Elections Under Way Previous Topic   Next Topic Topic: John O'Conner Explains JavaFX Functions and Operations

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use