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

Play JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 2
Sign in to queue


Often, after the camera is turned off, the conversation continues and, on occasion is truly interesting. Of course, as you could image, Joe, Erik and I continued to chat about concurrent programming, functional languages, the future of hardware-software interaction, etc, when I turned the camera off after part 1 of this interview with the creator of Erlang, Joe Armstrong.

Rather than let the conversation evaporate into the ether of time and space, I decided to turn the camera back on and record a second part. I am sure glad I did!

This time around, Erik Meijer sits down in the other hot seat and we embark on a fascinating conversation about the future of programming in an increasingly, from a modern hardware + software perspective, concurrent world.

Joe is outspoken on the topic of objects and mutable shared state, as you know from part 1 of this interview (and if you understand Erlang, obviously). He's also got some really interesting ideas on programmable hardware...

In this interview, you will also learn what got the great Erik Meijer interested in programming and languages. It's a really interesting story.

Tune in. This is another compelling conversation with some of the industry's most innovative thinkers. Enjoy!

Joe Armstrong is the principle inventor of the Erlang programming Language and coined the term "Concurrency Oriented Programming". He has worked for Ericsson where he developed Erlang and was chief architect of the Erlang/OTP system.

In 1998 he left Ericsson to form Bluetail, a company which developed all its products in Erlang. In 2003 he obtain his PhD from the Royal Institute of Technology, Stockholm. The title of his thesis was "Making reliable distributed systems in the presence of software errors." Today he works for Ericsson.

He is author of the book Software for a concurrent world: (Pragmatic Bookshelf - July 15, 2007). He is married with 2 children, 2 cats and 4 motorcycles and would very much like to sell his Royal Enfield Bullet and replace it with a Norton Commando.



Right click to download this episode

The Discussion

  • User profile image

    FPGAs.. they sound alot like a  3d accelerator to me Smiley so in that way, most of us already has them Smiley
    id just like to point that out..

    perhaps thats the way things will be.. i doubt strongly that we'll be writing everything in erlang/ml/f#, after all not everything can be parallelized to 20 tasks, but perheps we'll use functional constructs in a library to witch be pass a task (aka ccr /plinq)
    thats what i think anyway Tongue Out

  • User profile image
  • User profile image
    mpcm wrote:

    Watched it last night, definitely a must see. Smiley
  • User profile image
    aL_ wrote:

    FPGAs.. they sound alot like a  3d accelerator to me so in that way, most of us already has them

    Not really. A 3d accelerator still just interprets instructions from a fixed instruction set. An  FPGA is basically a grid of gates, and you litterally change how they're wired together (not physically obviously). It HAS NO instruction set, it's just a bunch of hardware gates that you can rewire to do whatever you want.

    That said, I'm skeptical that it's the way forward. I mean they've been around for a very long time, but mostly you just use them for prototyping, and then when you're done you build it "for real" and it goes a lot faster.
  • User profile image
    A great series of Videos. Smiley

    Thank you again Charles and Microsoft.

  • User profile image
    sorry for the silly question. When Joe was talking about fault tolerance, he said something that you could copy one machine on to the other, or whatever one machine does can be replicated on the other machine. 
    How would you create another copy in a secure fashion? How to make sure that only a certain entity/function/whatever can create a copy, especially when there is nothing to copy from when everything is crashed, wouldn't there be a need for a static state which can be replicated? What if that third entity crashes, wouldn't there be a need for every machine to be able to create another machine and exchange messages to see whether there is at least one machine running, somebody also needs to hold a security policy, that is static... right? no?...

Add Your 2 Cents