Registered: Feb, 2004
Re: Cedric Beust on Programming Erlang
Posted: Oct 4, 2007 7:43 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.
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
> 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
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...