Ed Merks already gave a summary of Dave Thomas' keynote yesterday morning here at Eclipse Summit Europe. It was the first time I saw Dave speak and I was warned he tended to say things that offended the audience. And to Dave's point, that is kind of what a keynote speaker should do. Spark thought. Break through the assumptions that we tend to fall into when we get comfortable in our skin. And I think he raised some serious points that are making me wonder about what's really happening in our industry.
I guess his main point is that Java for embedded has missed the boat. If you haven't gone through the pain of doing Java for embedded devices, don't worry, you didn't miss anything. I've been waiting to see when I need to care about Java in this space and I've talked to some of the people here at Eclipse Summit Europe about this. I think they quietly agree with Dave. Those that have figured out how to do Java on embedded are doing OK with it. But there are a lot of issues to face. The worst of them is the bloat that the Java VM continues to grow from release to release. The embedded VMs are horribly crippled, and if you want to use the Sun VM, you are crippled from paring down that bloat. The discussion is interesting, and we may still be proven wrong, but for now, I can ignore Java for embedded and I can sleep at night.
There were some other messages from Dave that hit home as well. Programming is horribly complicated. Normal people will never be able to figure it out. Which means if you have figured it out, you're not normal, and I guess that includes me. But it is true. I've blogged a lot about this in the past. We can barely get our programs to work as it is. Wait until you're trying to program 100 threads running through your mess all at the same time. We're doomed.
But there are some things we can do to give us a chance to survive. Dave talked a bit about how the lack of a software component model is making us look like fools in the eyes of the engineering community. Can you imagine if automakers had to custom build all the components that make up a car? Imagine now if we could go to a shop and pick up high quality software components and tie them together will few lines in a script.
Now Dave was be extreme in his position. There are a number of areas where component models are being used, OSGi is an obvious one, all these "Mash-ups" are doing things like this. But coming back to embedded, we can't rely on Java to provide the solution. Dave's answer was C++ with JavaScript. And I think that's a great idea. Build components in C++ and tie them together with a scripting engine. Dave picked JavaScript, which is OK but he did mention he's working with Google on their V8 JavaScript engine. Lua is another good choice. And actually Domain Specific Languages offer solutions as well (and I'm not just saying that because I'm sitting in Rich Gronback's DSL talk right now ;).
It was really interesting to spend time with Dave Thomas in his keynote and with a group of us at the hotel bar. I could learn a lot from him. This week it was to open up my mind and challenge the assumptions. If you read this blog regularly you find that I tend to do that anyway, but it's an important reminder to keep doing that and make sure we don't make the same mistakes over and over again.
C++ + Javascript. Yuck. Two of my worst enemies. Not because i can't write code in them, but because they are the nightmare of every person who works in the area of automated code analysis and improvement. C++, because its grammar is not a grammar, but a mess and Javascript, because static analysis (or automated refactoring) of dynamically typed languages is naturally next to impossible to do properly. I strongly vote against this combination ;-) Rather, i suggest that someone finally funds a qualified team of proper real experts on language design and implementation (you know, not those guys who write standards, but those who can solve the problems), lock them into a house for 6-10 years and see what they come up with. Most people don't realize that the problems start with the fact that we are using text editors to create programs. Why on earth would someone write a program in something that can have different character encodings, different formattings to obscure things, needs splitting because we couldn't read it otherwise in one piece and so on and so on. Programming developement environements like Eclipse are nice, but they exist only to mitigate the problems that exist due to the existing misconceptions (i.e., the programming languages that we currently use). The solution to our problems definately a little different than what we are currently used to.
ReplyDeleteDoug, you know I've blogged on this too. Look at the hardware industry, you just can't build a modern IC without discipline, components and tools.
ReplyDeleteA recent article I read said "moving away from Ada to more modern languages like C." I continually get the feeling we're going backwards in software not forwards.
C++ and Javascript... that is just madness.
ReplyDeleteC++ just does not cut it anymore as a general purpose programming language due to the level of abstraction not being high enough. 95% or more of the applications being developed don't need anything from C++ that they can't get already from Java, without the complexity inherent to a language that is just too close to the metal. Java's edge is not really the language anyways, it is the runtime (VM + class libraries).
Not that it would be bad to (fully or partially) develop components in C++ when it makes sense, it is just that that should be an implementation detail of the component itself, instead of adopted/imposed by a component framework/platform.
And Javascript... well, I really dislike it, and think that there are many dynamic languages out there that are better. My guess is that the buzz that Javascript gets is deeply rooted at the fact that it has been supported by browsers by a long time. But what the heck technical choices for a component platform have to do with Web???
Anyways, as far as glue languages go, people should be allowed to pick whatever (dynamic) language they want. No need to bind a component platform to some arbitrary dynamic language when it would be so easy to support many at the same time.
This was the microsoft model for programming web applications before ASP.NET. You wrote vbscript or javascript glue code that called your COM components written in C++. I'm talking server-side here. It sucked.
ReplyDeleteHey John! ;)
ReplyDeleteI'm still intrigued about this concept of wrapping C++ objects with Javascript interfaces and what you can do with that. I'm coming from the desktop and embedded side, though, and maybe things on the server are different.
I'll have to blog about that too. What would Eclipse look like if it was written in C++ with Javascript as a scripting language...
Actually, I'll answer that here. It'll look like Visual Studio ;)
ReplyDelete