JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 2
- Posted: Oct 30, 2007 at 12:59 PM
- 15,720 Views
- 6 Comments
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.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
More posts in this blog
-
JAOO 2007: Joe Armstrong - On Erlang, OO,…
-
JAOO 2007: Joe Armstrong - On Erlang, OO,…
-
Chris Gray: Windows Home Server Extensibility…
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
FPGAs.. they sound alot like a 3d accelerator to me
so in that way, most of us already has them 
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
Erlang in telcom...
Watched it last night, definitely a must see.
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.
Thank you again Charles and Microsoft.
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?...
Remove this comment
Remove this thread
close