JAOO 2007: Erik Meijer and Dave Thomas - Objects, Functions, Virtual Machines, IDEs and Other Fun St

Posted By: Charles | Oct 19th, 2007 @ 11:05 AM

I recently got the chance to attend JAOO in Aarhus, Denmark. Besids learning a great amount about various approaches to solving hard problems that we all face as programmers (regardless of the stack we spend most of our time developing on), I got to meet so many interesting people from all walks of programmer life. What a great conference! For one thing, JAOO not about specifc products. It's not about one company's view of the world. It's not about one class of technologies or developer. It's not just about Java and LAMP or .NET and Windows.

Dave Thomas is well known for his work in object oriented programming language design, dynamic language development (SmallTalk), virtual machines and in the development of the Eclipse IDE.

I was lucky enough to grab Dave and Channel 9 celebrity, co-creator of LINQ and programming language scientist Erik Meijer to about objects, OO, functional programming, the future of programming languages in the age of parallelism and concurrency (multi/many-core hardware "revolution"). We also talk about virtual machines in the context of language runtimes. Dave provides some feedback on Microsoft's approach to "managed" runtimes (aka CLR). He has an "interesting" perspectives in this area, though I don't agree with him fully Smiley

This is a fantastic conversation with two of the computing industry's best and brightest. It was a real honor to meet Dave Thomas. He's incredibly nice and really humble given his myriad of technical accomplishments.

Enjoy!

Tags: CLR, CSharp, JAOO2007, Java, Programming, VB.NET, Virtualization

Rating:

Views (14,071)

Comments (20)

Downloads

Balclutha

"I mean I think the .Net library is great. It is wide, but does not really feel fat to me. I mean how does a functional language help you call something like Dns.GetHostEntry() any better?"

You’re right. If you need a library function like Dns.GetHostEntry() who gives a damn if it’s being called from IronPython or C#. It’s there because people need it, not because of static or dynamic typing.

I thought his objection to fat libraries was that developers should think about the problem more, and that given appropriate languages they can build precisely what they need for their app. themselves without necessarily modelling every aspect in OO and/or automatically falling back on a large stack of OO frameworks.

Having said that, I've never really worked with frameworks like Spring or Hibernate so I don't know how bad the problem is. What are other people's experiences with these kind of frameworks? Good for technical-publishers or good for developers?

In .Net’s case I’d agree that the library weight is muscle, not fat; it’s there to do work for people – though with time it's naturally going to become more convoluted.

berni

very interessting interview (i really like erik). but i have to say some words to charles.

I think charles is in a mindset that functional programming is the way to go and all problems just fade away as soon as you write your code in ruby or F# and so on. I don't know what kind of programms charles is writing, but my experience as a professional developer is that "the old style" of programming is very appropriate for real world problems.

even in the world of multicore CPUs it's not that hard to use all those core for your programm. especially for web and database related software it's very easy. libraries like ParallelFX will help to write nice code. so i don't see that functional programming is the way how programms will be written in the future. (Of course there are some perfect exceptions but please don't nail me on that).

Charles

berni wrote:

very interessting interview (i really like erik). but i have to say some words to charles.

I think charles is in a mindset that functional programming is the way to go and all problems just fade away as soon as you write your code in ruby or F# and so on. I don't know what kind of programms charles is writing, but my experience as a professional developer is that "the old style" of programming is very appropriate for real world problems.

Hi berni,

Actually, that's not my mindset at all. Functional languages are, by design, perfectly suited to writing concurrent programs. This doesn't mean that we all have to become users of functional languages to write programs that scale to multicore. In reality, you will most likely see more of what Erik and Anders are up in terms of LINQ, PLINQ and ParallelFX (which relies on the existence of lamda expressions, among other constructs borrowed from the functional world, to work) showing up in imperative languages like C#, VB.NET, Java, etc...

From an educational point of view, I agree 100% with Erik and Dave regarding the need for functional programming courses as a requirement in the CS discipline.

The future may not be functional or imperative, but rather both. For sure, the future is many core and we need to have tooling support for it.

C

berni

Thank you charles for your reply. I agree that all those nice features like lambda expressions in c# can help to write better code (and of course everyone should use it). But unfortunately a lambda expression alone does not solve the concurrency problem. Take a look at your interview with Anders Hejlsberg and Joe Duffy, even with ParallelFX a lambda expression is just a nice way to express what the programm should do. In fact it's just a delegate and the code that is executed is still the same as before (with all the concurreny problems).

Don't get me worng, i don't blame lambda expressions that they can't solve the concurreny problem - because they are not designed for it. Anders Hejlsberg said in his interview: "You still have to think" and that's the truth.

Chadk

This was a really interesting discussion that came far around. Very good job.

Im very much looking forward to the second part!

raymond

I could listen to Dave Thomas for several hours.

He really nailed it about what is going on at colleges in the USA with Java.

More interviews like this Charles! Smiley

Cool

John Melville-- MD

berni wrote:

But unfortunately a lambda expression alone does not solve the concurrency problem.

Actually, to be more correct a lambda does NOTHING to solve the concurrency problem. Functional languages solve concurrency by disallowing mutable state. Lambdas are just one of many techniques that you need to get real work done in the presence of that draconian restriction.

I see a looming disaster if programmers misunderstand the implications of "functional elements" in imperative programming languages. Functional programming is as much about what you don't do as what you do. If you use typical functional constructs in a imperative language, you might accidentally take an implicit dependency on the implementation of everything you call -- nothing you call can mutate any state. This introduces versioning and subtle edge case bugs, as the author is probably unaware and cannot discover that you have taken that dependency.

This brings us to the second looming disaster. It simply doesn't work to have two classes of code, one of which cannot call the other. Several of the C# team members have discussed on channel 9 that this is why the C++ const modifier was not carried over into C#. It has proven frustratingly difficult to predict how other programmers will want to compose code. When one class of code cannot call another (ie "functional code" with no mutation and "imperative" code that can) one eventually sees parallel frameworks developing as common operations are eventually needed in both classes.

Don't get me wrong, local variable type inference and lambdas in C# are hot features. Linq has been my biggest boost in productivity since, well C#. But these features do not make the language functional, and you're setting yourself up for pain if you think they do.

JChung2006

Can you give an example of what you're talking about, John?

berni

John Melville, MD wrote:

Actually, to be more correct a lambda does NOTHING to solve the concurrency problem. Functional languages solve concurrency by disallowing mutable state. Lambdas are just one of many techniques that you need to get real work done in the presence of that draconian restriction.

I see a looming disaster if programmers misunderstand the implications of "functional elements" in imperative programming languages.

That's exactly what i tried to say to charles (my english is not so good), thank you john. He missed this discussion in his last interviews when he was talking to Erik, Anders or Joe Duffy. Actually Joe Duffy was pointing at this problem when he wrote his "a(i)" function to the whiteboard - but it was only one short sentence.