JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 1

Finally. The interview i have looked forward to.

I had the pleasure to talk to mr. Armstrong. Hes really darn cool.

Hey Charles, Thanks again for this in-depth video! This is really the stuff I always love to see on Channel 9! Btw I like Erik Meijer. I saw him at the Microsoft Devdays in Amsterdam once. You can see he's really passionate about his work! (as are most people in the industry, I'm sure) ~Laurens

I just want to emphasize one of the key points here that I strongly agree with: The hardware change is NOT incremental, it's a massive paradigm shift, so it's a bit bonkers to think that we can just keep using the same old tools with slight changes.

The download link is currently broken.

Concurrency programming enthusiasts would do well to remember Amdahl's Law.

I'm really enjoying the notion of Java, C++, and C# programs being viewed as "legacy code" in the same manner that COBOL programs are viewed today.  This video was worth the sheer delight from realizing how true this will become!

Great video; Joe's a lively chap.

I wanted to let those who are interested know that they can watch a video of Joe’s Erlang presentation from the 2002 Lightweight Languages Workshop at http://ll2.ai.mit.edu/.

The JAOO 2007 series of Channel 9 interviews has been I think one of the most consistently interesting video sets I can remember on Channel 9. Ever. It's really wonderful to hear these alternative views and deep thoughts by folks not involved with The Mothership (tm).

Channel 9 is the example I always hold up whenever I want to point out to anti-MS zealots that Microsoft is not the company they used to be - I won't call them the bad old days, but certainly Microsoft today is far more open than when I started programming professionally 14 years ago.

Please continue to cover things like JAOO. Personally speaking I select my computing platform based on programming tools and with regard to that nothing touchs Windows. If we do transition into a virtualized / cloud centric OS world then I shall continue to apply my "follow the best dev tools" rule - and will look to Channel 9 to help me make that decision. Thank you Charles (and supporting team) for bringing these videos to us!

dot_tom wrote:



The JAOO 2007 series of Channel 9 interviews has been I think one of the most consistently interesting video sets I can remember on Channel 9. Ever. It's really wonderful to hear these alternative views and deep thoughts by folks not involved with The Mothership (tm).

Channel 9 is the example I always hold up whenever I want to point out to anti-MS zealots that Microsoft is not the company they used to be - I won't call them the bad old days, but certainly Microsoft today is far more open than when I started programming professionally 14 years ago.

Please continue to cover things like JAOO. Personally speaking I select my computing platform based on programming tools and with regard to that nothing touchs Windows. If we do transition into a virtualized / cloud centric OS world then I shall continue to apply my "follow the best dev tools" rule - and will look to Channel 9 to help me make that decision. Thank you Charles (and supporting team) for bringing these videos to us!

Unfortunately, JAOO is one of its kind. But its a bloody great event.

I, for one, want to go back to JAOO next year. The amount of different views is just awesome. And i think that the interviews so far have shown that people who do other things than microsoft, arent just zealots who try to flame microsoft at any point in time. And i think this is very important.

I hope that C9 will be on JAOO next year, its just makes very good interviews to have different views on things, from people who arent internet trolls.

cool interview its really fun to hear all the opposing views even though i disagree with them from time to time.

i find it odd that everyone is knocking "traditional" programming so much.. the main reason for that is that c++ java and c# are not traditional really.. all these functional languages and dynamic languages existed Before c++ java and c# ever did..

one agrument (almost)that always seems to be dodges is that if these languages really were so superior and "traditional" object oriented programing was such a design failiue/mistake whatever, why are they so popular? why have they been popular so long?

i find it slightly arrogant when alot of these interviewees claim that everyone else is wrong and they have known the "true" path all along.. they state with pride that their perticular language have existed for 20 years.. but still they havent really caught on.. isnt that a bad thing? id feel kind of bad if i created something and still after 20 years, very few people whould use it..

im all for innovation and change when it well founded but for me, loftely claiming that the world is not made of objects or the world is not based on inheiritance, even thogh there are many arguments to the contrary; i think any geneologist whould think the world is pretty heirarchial; and saying that all current software is legacy and have to be wreritten in paradigm x, doesnt do it for me..


personally i think the success of "general purpose" languages are just that, they are general purpose.. it may not be optimal for everything but atleast you can solve most problems in a pretty good way

anther jaoo interview springs to mind were a proponent for functional programming said something like "so the you just grab it from the data base and put it on the screen and youre done, no state there.."

you just put it on the screen.. that easy huh? but consider a ui without state.. a textbox were you enter a query that does not have state.. or ui components without heirarchy.. not that easy is it..

sure, it might be good from a concurrency prospective to write code in a functional language. all you have to do is ensure that your code has no side affects and your good right? because thats real easy right? well.. no..

in another (great)interview on c9 the point was brought forth that the programmer usually does not know for sure if his or her code really has no side effects. thats and excelent point i think.

and at the end of this interview there seem to be some consensus that some side effects are infact good. so then is it truly wise to write all your code in a language that does not allow sideeffects?

its not that trivial..

this post is starting to be a bit rambeling but i guess my main point is this:

i dont think a language that is just functional or just static just dynamic or just imperative will succeed..

also, we should not forget what anders said when talking about plinq. its something that really really applies here with this talk of languages to solve this and that:

"you still need to think"

i think that is really significant. switchig to erlang or ruby or c# or any other language wont solve your problems for you. we still need good design, good architecture. i actually think thats far more important then the language paradigm.

I took a look at Erlang after the vid.  I really like the model and idea of user message passing and send/receive symantics, however not currently a fan of the erlang syntax and not sure I could ever get used to it over something like c#.  The model did kinda remind me of the CCR library with messages and closures.  So I think most of these pros can be delivered in a library such as ccr.  In ccr, you also have the option to use just local state or shared state - so you decide how much rope to hang yourself with.  The library could be changed to use threads, fibers, a combo, or something else, but the port abstration remains the same to the dev. 

This was a great video, thanks!!! While people are going to have to start giving up the shared state model, it does not mean OO will go away completely -- "objects" will be more like independent, encapsulated processes than one giant intertwined memory structure in a single process. This is a different way of programming but closer to the original idea of object oriented programming.

Frank Hileman wrote:

This was a great video, thanks!!! While people are going to have to start giving up the shared state model, it does not mean OO will go away completely -- "objects" will be more like independent, encapsulated processes than one giant intertwined memory structure in a single process. This is a different way of programming but closer to the original idea of object oriented programming.

We can actually do this pretty easy with OO today.  You can derive all objects from a class that has an in and out queue and a worker thread.  Then send messages to it and it processes all messages in local scope if it wants.  However, not sure this is better then some library (i.e. ccr, pfx) that takes lambdas and does the work inside a closure.  With the ability to have nobs on the library for thread min/max, wait times, throttles, perf mon, etc. The former could be a good design for a pipeline server (i.e. sql), but I think the later is better for general work and things like joins, choice, futures, etc.  Room for both I think.

staceyw wrote:

 We can actually do this pretty easy with OO today.  You can derive all objects from a class that has an in and out queue and a worker thread.  Then send messages to it and it processes all messages in local scope if it wants.  However, not sure this is better then some library (i.e. ccr, pfx) that takes lambdas and does the work inside a closure.  With the ability to have nobs on the library for thread min/max, wait times, throttles, perf mon, etc. The former could be a good design for a pipeline server (i.e. sql), but I think the later is better for general work and things like joins, choice, futures, etc.  Room for both I think.

I would qualify this:

1. A "process" in something like Erlang is more lightweight and transparent than a Thread in a traditional OO language/library such as C# -- you can create millions, and distribute them across networks easily. Libraries can do similar things but the distribution might be difficult without integrated support as in Erlang. 
2. There is nothing in C# or the CLR to prevent modifying encapsulated state in an object, in the sense that every value returned from a function, and every property getter, needs to return something with value semantics, not reference semantics.
3. In Erlang at least, the flow of control is generally turned inside out with the "objects" waiting for a message to arrive, rather than sending a message and waiting for an object to return. The .net framework libraries are generally not designed around this model.

duplicate post deleted

aL_ wrote:



one agrument (almost)that always seems to be dodges is that if these languages really were so superior and "traditional" object oriented programing was such a design failiue/mistake whatever, why are they so popular? why have they been popular so long?

I think it's fairly well known why C style languages are popular. Even Stroustrup and other prominent "C++ people" acknowledge that it's largely accidental when asked.

It started off as a medium term solution to do Unix, then Unix caught on and we're stuck with it, like it or not. Then better languages have come along but legacy code and legacy programmers have meant that only parts of them can be tacked on to the existing language See for example the horribly fragmented C++ (which isn't bad for an extension to C; but having to be compatible with C is the reason for most of the well-documented flaws of the system - read stroustrups Design and Evolution book). Even C# suffers quite a bit from a "must be familiar to existing programmers" desire, which means they have a messy legacy to carry along.

aL_ wrote:



loftely claiming that the world is not made of objects or the world is not based on inheiritance, even thogh there are many arguments to the contrary; i think any geneologist whould think the world is pretty heirarchial; and saying that all current software is legacy and have to be wreritten in paradigm x, doesnt do it for me..

I agree. In general I think it's pointless to try to create a language that best represents the real world intuitively. What we need is a language that can abstract the real world, not that directly maps to it.

Counting on your fingers is wonderfully intuitive, but if you want to solve more difficult problems I'm afraid you'll need tools that aren't at all intuitive at first (like calculus, imaginary or hell even negative numbers), because they give you more expressive power, even though they don't map nicely to real-world concepts.

aL_ wrote:


sure, it might be good from a concurrency prospective to write code in a functional language. all you have to do is ensure that your code has no side affects and your good right? because thats real easy right? well.. no..

in another (great)interview on c9 the point was brought forth that the programmer usually does not know for sure if his or her code really has no side effects. thats and excelent point i think.

It is easy, but just like algebra it takes time to learn, and there may not be a good real-world analogy for everything.

The language should ensure the lack of side effects, since (as you point out) having the programmer keep track of that would be asking a bit too much.

aL_ wrote:



and at the end of this interview there seem to be some consensus that some side effects are infact good. so then is it truly wise to write all your code in a language that does not allow sideeffects?

No language disallows side effects. Haskell is full of them!

The difference is that in Haskell the side effects are contained within a pure type system. So even if you have small component somewhere that uses mutable state internally (e.g. some algorithms require mutable state!), the type system can keep track of that for you, and will refuse to let any of that mutable state "leak" out to the pure code. You can use side effects, but the compiler will force you to keep them separate from the bulk of the code (which doesn't have side effects).

sylvan wrote:


No language disallows side effects. Haskell is full of them!

The difference is that in Haskell the side effects are contained within a pure type system. So even if you have small component somewhere that uses mutable state internally (e.g. some algorithms require mutable state!), the type system can keep track of that for you, and will refuse to let any of that mutable state "leak" out to the pure code. You can use side effects, but the compiler will force you to keep them separate from the bulk of the code (which doesn't have side effects).

This is a great point! As I mentioned, this is closer to the original idea of object oriented programming, whereby an object's state is purely encapsulated. The original motivation behind OO was to view each object as a small computer in and of itself.

Amdahl's law is based on demonstrably false assumptions in many cases:




http://www.scl.ameslab.gov/Publications/Gus/AmdahlsLaw/Amdahls.html