Inside MultiTouch: Team, Demo, Lab Tour

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.
Mads Torgersen is a Senior Program Manager in the C# group and has been working on the design of LINQ and other new C# language features. Before joining Microsoft, Mads worked as an associate
professor in computer science at the university of Aarhus, where he was part of the group that developed wildcards for Java generics.
Here, in part one of a two part interview, Joe and Mads discuss the pros and cons of object oriented programming, the new spotlight on concurrency and the future of languages (it should come as no surprise, for those of you who understand Erlang, that Joe is
not a big time proponent of OO...). Erik Meijer, who is listening into the conversation will appear at random intervals to add his usual brilliant perspective.
This is a fantastic discussion. Listen in and learn from some of programming's masters. This was a real treat for me and one of the highlights of my time at JAOO.
TimP wrote:The download link is currently broken.
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!
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.
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.
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.
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).