Java Community News - Cedric Beust on Programming Erlang

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

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 4, 2007 7:53 AM

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

I'm not familiar with any OO language where objects have no type and I know of none where the type of an Object is not related directly to it's class.

"Smalltalk implements all data types as Smalltalk classes"

http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/chap4.html

To me Armstrong's statement demonstrates an ignorance of the conceptual underpinnings of OO.

And this pedantic quibbling over terms is (as I have already mentioned) is completely pointless in examining his statement. I acknowledge that my statement is not precise but from a conceptual level, the difference is very subtle. Armstrong writes:

"Consider "time". 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. For example, in Erlang there are lots of different varieties of time, these can be clearly and unambiguously specified using type declarations, as follows:"

And this is followed by a list of type declarations. The implication being that this is something that is hard or impossible to do in OO. Which anyone who knows anything about OO knows that you can declare as many time 'types' as you like by creating new classes. For example, I have a custom date type in Java that I use for communication with procedural systems because those systems allow for invalid dates (I've seen 02/29/2000 in them) so I have to bastardize the OO version to prevent inconsistencies.

Aside from that his example is actually a pretty good demonstration of the weakness of his argument as day goes from 1-31 regardless of the month. The logic for that must go somewhere and it must be communicated clearly or you end up with redundancies or worse. I'd like a clear unambiguous explanation of why tying this logic to the data is not the correct thing to do? Why should I have to look for (or write) the logic of how to add two times together instead of just adding them?

> 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 ;)

primitive vs. reference types in Java isn't really relevant. Both are types in Java, they just have different semantics. primitives are corner cases in Java's type system. The overwhelming majority of types are defined by classes.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang

Posted: Oct 4, 2007 8:11 AM

> > Difficult, yes, often. Impossible? No, not really.
>
> Sometimes it is so difficult it is impossible.

The key word here is sometimes but I don't disagree with you entirely. I just think the proper qualification are required.

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

I'm not sure what you mean here but what I mean is that the above situation can be modeled in a number of clean ways in OO. One is by defining the Customer as a pure virtual class (or interface in Java) and making both the Company and Person class implement this interface. If Companies and Persons are not always Customers, you can easily create a Customer composed from a Company or a Person:

class Person
{
  Customer asCustomer()
  {
    return new Customer() {
       /* 
        * Implement customer methods using Person object
        */
    };
}

> Multiple inheritance? a great pain.

I agree. And one of the things that has occurred to me is that OO (especially C++ style) is far to concerned with inheritance. Composition is much better. Maybe it's not OO I don't really care if it is. If loving composition is wrong, I don't want to be right. However, I will note that a lot of prominent OO authorities say things like "prefer composition to inheritance."

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

But this has proven to be extremely problematic in my experience. It creates the same kinds of issues that global modifiable state cause. How does it not cause issues in FP? This isn't a rhetorical question. I seek to understand.

Antti Tuomi

Posts: 4
Nickname: hrnt
Registered: Dec, 2006

Re: Cedric Beust on Programming Erlang

Posted: Oct 4, 2007 8:36 AM

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

You use namespaces in C++ to group non-member functions
with related types.

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

Structural subtyping is possible in both C++ and Ruby.
I can see your argument against static typing,
but not against OO here.

And you can still do that with Java-style OO - just implement Customer interface. Refactoring is possible in OO too!

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

Java is hardly the poster child of OO languages.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Cedric Beust on Programming Erlang

Posted: Oct 4, 2007 8:48 AM

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

I'm not sure I understand fully what you mean here, so my answer might be off-base, but it's perfectly possible to use composition and still have the composed objects be of the desired type: you use interfaces for that.

For example, instead of

public class MyCustomer extends Customer {
}

Create an interface ICustomer that contains the important part of the Customer contract, and use:

public class MyCustomer implements ICustomer {
// optionally, have a Customer object field here
}

--
Cedric

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Cedric Beust on Programming Erlang

Posted: Oct 4, 2007 9:17 AM

Achilleas, you are correct that some OO code is boated by inappropriate Factories, Patterns, etc. Sometimes I want to write a book on when NOT to use patterns.

But its not an OO problem. Its the way different people think. A coworker, whom I generally respect, writes Factory patterns of half a dozen classes and a few more interfaces for the simplest of tasks. I just roll my eyes and figure out how to use them. And I imagine he looks at my style and says "gee, why doesn't Morgan write more classes to be Factories?" In contrast, I do write a lot of wrapper/adapter style classes to mix and match, while he tends towards a more strict class inheritance hierarchy.

Anyway, if millions of programmers had been using Erlang for 10+ years there'd be a lot of Functional Patterns, many of them potentially overblown and inappropriate.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang

Posted: Oct 5, 2007 6:20 AM

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

In a statically compiled language like C++, the compiler will tell you that template type T does not have method M, so you can go and change it to N.

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

We don't solve more complex problems, we introduce more complex solutions to impress the market.

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

These are not today's challenges. They are challenges for at least 30 years.

For example, Microsoft made their own source control system in 1987 to manage their NT code base.

By the way, the design patterns, testing tools, IDEs, profilers and debuggers have nothing to do with OOP.

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

But in order to understand it, you have to spend many hours in reading and testing.

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

Yeah, real success. Once you make your own API, that is. So much for reuse and sanity.

There are other APIs in Java and in other languages which are much saner.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang

Posted: Oct 5, 2007 6:24 AM

> I'm not sure what you mean here but what I mean is that
> the above situation can be modeled in a number of clean
> ways in OO. One is by defining the Customer as a pure
> virtual class (or interface in Java) and making both the
> Company and Person class implement this interface.

I.e. do multiple inheritance manually? no thanks.

> I agree. And one of the things that has occurred to me is
> that OO (especially C++ style) is far to concerned with
> inheritance. Composition is much better. Maybe it's not
> OO I don't really care if it is. If loving composition is
> wrong, I don't want to be right. However, I will note
> that a lot of prominent OO authorities say things like
> "prefer composition to inheritance."

Multiple inheritance's purpose is composition.

Without multiple inheritance, it is a pain to compose all the classes.

Structural subtyping has the same effect as composition, but it is done automatically.

> But this has proven to be extremely problematic in my
> experience. It creates the same kinds of issues that
> global modifiable state cause. How does it not cause
> issues in FP? This isn't a rhetorical question. I seek
> to understand.

In pure FP, state is not modifiable, so no problem is caused by exposing it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Cedric Beust on Programming Erlang

Posted: Oct 5, 2007 6:28 AM

> Structural subtyping is possible in both C++ and Ruby.
> I can see your argument against static typing,
> but not against OO here.

No, I am not talking about for or against static typing. I am talking against OO as it is implemented in C++ and Java.

Suppose you have the classes A and B and a collection which takes class C, but neither A nor B inherit from/extend C.

What do you do?

There are 3 options:

1) have the source code of A and B, and modify them. If you don't have the source code, go to other options.

2) compose C-A and C-B manually.

3) use structural subtyping, i.e. automatically wrap A/B into a C.

I know which option is best... ;)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Cedric Beust on Programming Erlang

Posted: Oct 5, 2007 6:34 AM

> I.e. do multiple inheritance manually? no thanks.
>
> Multiple inheritance's purpose is composition.
>
> Without multiple inheritance, it is a pain to compose all
> the classes.

The above shine like a laser on where I think OO is sub-optimal: 1. Inheritance is a degenerate form of composition. 2. OO jumps through all kinds of hoops to make it easy to use inheritance but does very little to support composition.

> Structural subtyping has the same effect as composition,
> but it is done automatically.

I'll have to look into that, thanks.

> > But this has proven to be extremely problematic in my
> > experience. It creates the same kinds of issues that
> > global modifiable state cause. How does it not cause
> > issues in FP? This isn't a rhetorical question. I
> seek
> > to understand.
>
> In pure FP, state is not modifiable, so no problem is
> caused by exposing it.

Just to be clear, I'm talking about when an FP program uses Monads or other ways of interacting with state. Modifiable state cannot be avoided in most non-trivial applications, at least the kind that I tend to work on.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

categorically true or untrue ?

Posted: Oct 8, 2007 4:52 PM

Cedric Beust wrote

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

Do you know that those categorical statements are true or are just making stuff up?

It was really really easy to Google these:

no documented design patterns ?
"Behaviours are formalizations of these common patterns. The idea is to divide the code for a process in a generic part (a behaviour module) and a specific part (a callback module)."
http://www.erlang.org/doc/design_principles/des_princ.html

no IDE's ?
Erlide - the Erlang IDE.
http://erlide.sourceforge.net/

And what exactly do you mean by very little support for large distributed teams to work on huge code bases - GIT?

On the obvious example large project to minimize administrative overhead, all 200 project members were put under one roof - "Four-fold Increase in Productivity and Quality"
http://www.erlang.se/publications/Ulf_Wiger.pdf

In your review of "Programming Erlang" you wrote Most of the examples and listings are run from Erlang's shell and it doesn't seem that there is even a decent editor to help you - perhaps you skipped the beginning -

Chapter 1 "As a beginner, you’ll: ... 4. See how to create and modify programs using your favorite text editor."

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

QuickCheck in Erlang - a testing tool

Posted: Oct 8, 2007 5:29 PM

Cedric Beust wrote
> There are ... no testing tools ...

Can we trust what you write?

QuickCheck in Erlang
http://video.google.com/videoplay?docid=4655369445141008672

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: QuickCheck in Erlang - a testing tool

Posted: Oct 8, 2007 6:14 PM

And from last year

"Testing Telecoms Software with Quviq QuickCheck" pdf
http://www.ituniv.se/program/sem_research/Publications/2006/AHJW06/erlang001-arts.pdf

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Cedric Beust on Programming Erlang

Posted: Oct 9, 2007 9:02 AM

> 2. OO jumps through all kinds of hoops to
> make it easy to use inheritance but does very little to
> support composition.

Agreed. IDE will help type all the code, but it's still icky. How about an annotation something like:

public class Foo implements ICustomer {

@Delegate(ICustomer)
Customer customer; // make sure this gets initialized!

which means that all ICustomer methods (which are not explicitly defined in the class or subclasses) are automagically delegated to customer.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Cedric Beust on Programming Erlang

Posted: Oct 9, 2007 9:26 AM

> Agreed. IDE will help type all the code, but it's still
> icky. How about an annotation something like:
>
> public class Foo implements ICustomer {
>
> @Delegate(ICustomer)
> Customer customer; // make sure this gets initialized!
>
>
> which means that all ICustomer methods (which are not
> explicitly defined in the class or subclasses) are
> automagically delegated to customer.

Funny, I made a very similar proposal without the annotations back in... 1998:

http://beust.com/java-delegation.html

In hindsight, it's probably a bit overkill, although it might be interesting to explore such a syntax when combined with static imports and mix-ins.

--
Cedric
Author "Next Generation Testing in Java"

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Cedric please correct your misstatements

Posted: Oct 9, 2007 11:30 AM

I don't have a problem with you mocking Joe Armstrong for his "Why OO sucks" rant.

I do have a problem with you making up stories and publishing them as though they were a true programming language history. At best, you didn't bother finding out if Erlang really was created after Joe Armstrong's "Why OO sucks" rant - you didn't care if it was true or not.

Oct 1, 2007 11:08 AM, the date of your post, in this discussion, Kay Schluehr stated the "Why OO sucks" rant was from 2001.

The "Why OO sucks" page first shows up in the Internet Archive on July 23, 2002.

The "Why OO sucks" page was written while Joe Armstrong was at Bluetail and Bluetail wasn't founded until 1998.

You emphasised that Erlang is "actually much more ancient than" 1998 - back to 1987.

Joe Armstrong did not create Erlang after writing the "Why OO sucks" rant - he created Erlang 14 years before writing the the "Why OO sucks" rant.

Incidentally, in contrast to your faked story, that Joe Armstrong did not follow a "take what's best in all languages" approach while designing his new language, Joe Armstrong wrote that "We programmed POTS in as many programming languages as we could lay our hands on. The main conclusion was that declarative language programs for POTS were a lot shorter and easier to understand than imperative language programs."

Quote from "The development of Erlang", www.erlang.org says "This paper describes the development of Erlang during the period 1985-1997"
http://www.erlang.org/doc.html

Please correct your misstatements.

Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 ]

Previous Topic

Next Topic