11–17 of 17 posts
It's a pretty shallow article with hardly any substance that was written more in reaction to the fact that nobody is (was) paying attention to Erlang than an informed criticism of OOP.
"Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage." The conclusion doesn't follow. "In an OOPL data type definitions belong to objects. So I can't find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can't - the data type definiti…
In regards to the first quote, I find it helpful having both the data structures and algorithms in one "cage." I like having all relevant data in one easy to find location.
You can also shrink the scope using visibility, get inherent namespace benefits for what would otherwise be loose functions, etc. The benefits are primarily organizational but organization in programming is a big deal.
I may believe in many ways Erlang is an evolution to Smalltalk, a better way to program. But I read Kay and it feels like an educator talking, explaining the reasons for some decisions. I read this and it comes across as bitter rant about why my favorite language didn't get popular. Kay's Smalltalk was never popular either. This argument preferring Erlang might be right at its core, but it's hard to get past the bits of the argument presented that are petty or plain wrong.
Objection 1 - Data structure and functions are bound together Objection 2 - Everything is an object
Arguably OO is a shorthand for enabling two things: - message passing based on function signature - a given data structure as the first argument ("this")
The message passing thing, Erlang handled a different way through the actor model, one that took concurrency in mind which was not in Smalltalk's early objectives. Erlang is arguably a better way.
However I (just me; probably not alone) originally found it hard to understand some Erlang programs because it's a pile of functions - the patterns and protocols against the data structures are all subtext and one needs to read a lot of example code to grasp them. Whereas objects and interfaces make the message passing protocols pretty clear, only a couple examples and I get the message.
One of the major nuances of OO and Smalltalk was that the language was only half of the story, Smalltalk was also a runtime and IDE, that made browsing and modifying code a joy. The image based approach has a ton of drawbacks compared to text files, of course, but now there are plenty of Smalltalk-like IDEs or code-browsing friendly text editors for both OO languages and functional languages such that anyone should be able to "suck it up" and follow the call chains and interrelationships.
Objection 3 - Data type declarations are all over the place
This seems subjective depending on the language, and even just wrong. Inheritance isn't required to reuse a data structure, OO design prefers composition. Most classes are composed out of fundamental data structures that are located in a well defined package.
Objection 4 - Objects have private state
Alan Kay agreed that mutable state is the root of all evil, or as he says, "assignment is a metalevel change". This is why he made state private!
I'm not sure what his point is here, as when you need shared mutable state in Erlang, you build an Actor to maintain and HIDE the mutable state. Which looks a heck of a lot like an object.
FYI, this is Joe Armstrong (the creator of Erlang)'s rant on OO. It's a pretty shallow article with hardly any substance that was written more in reaction to the fact that nobody is (was) paying attention to Erlang than an informed criticism of OOP.
FYI, this is Joe Armstrong (the creator of Erlang)'s rant on OO. It's a pretty shallow article with hardly any substance that was written more in reaction to the fact that nobody is (was) paying attention to Erlang than an informed criticism of OOP.
How unfortunate then that this is the first negative feeling I have in relation to Erlang. I've actually had limited but good experience with ejabberd, and everything else I've encountered was positive.
And it was a long time ago, I've submitted this page purely on historical reasons. Don't treat it this way.
And yeah, give Erlang a try. It is the best thing since sliced bread.
Earlier quoted context omitted.
How unfortunate then that this is the first negative feeling I have in relation to Erlang. I've actually had limited but good experience with ejabberd, and everything else I've encountered was positive.
You can't be sure it is him, it could be someone else from the company he'd worked at. The page is just a mirror of their old company's website. And it was a long time ago, I've submitted this page purely on historical reasons. Don't treat it this way. And yeah, give Erlang a try. It is the best thing since sliced bread.