I can't get my mind off of Dave Thomas's keynote at Eclipse Summit Europe. His words made so many things crystallize in my mind. I've stated many times before in this blog and in my day job, I hate Java. It's an incredible irony that I do my day to day coding in Java to support developers who focus so much on efficiency and performance and use C mainly to accomplish that with a sprinkling of C++ for good measure. And then to hear their constant complaints that Eclipse is too slow. My good friends in Java VM land tell me not to blame Java for that, but you know, it's so tempting.
Dave mentioned that applications should be written in C++ and JavaScript. I dunno. C++ has it's difficulties, there is no doubt. It's hard to write good C++ programs. That's why the mix with JavaScript made me think. Does it make sense to build an application where your hard core performance focused code and code that interfaces with the underlying system is written in C++, but all the code that manages interactions with the user is done in JavaScript?
I've started to take a look at Google's V8 JavaScript engine. As they say in their videos, they're built for embedding in C++ applications and they have implemented some interesting tricks to get JavaScript to run fast, such as a JIT compiler and some heuristics to make class property access faster. As well, they have an efficient memory management system which includes being able to persist snapshots of the heap, including the JITed code, out to the file system for faster startup.
That got me thinking of Eclipse, of course, or really IDE's in general. What if you take a cross platform GUI toolkit like wxWidgets, add in a component model to allow for dynamic extensions, plus rewrite the CDT parsers in C++ for speed, plus ..., and throw in a JavaScript engine like V8 to make it easy for users to program, wouldn't that make for an interesting architecture? But we already have Eclipse so why would we do that all again? Just a question...
I think it's a great idea but it's not a new one. You might don't know that but mozilla firefox (any other xulrunner) apps are implemented that way :)
ReplyDeleteIf you are interested in the IDE take a look at http://www.openkomodo.com/
one more benefit of this kind of architecture is really simple extensibility. (much much simpler then with java :)
Qt already features Javascript with QtScript.
ReplyDeleteThere is not JIT (yet?) but it is already powerful and fully integrated with Qt's signals and slots etc
What prevents the CDT parsers to be rewritten in C++ right now.
ReplyDeleteYou might hate Java, but I'm sure there is more to hate with JavaScript. No namespaces, global variables by default, no concept of threading ... it would be a nightmare. That's not to say it doesn't make sense to have a hybrid environment but although Firefox is such an example, the majority of extensions actually do pretty little. What makes it work is the fact that there are a few key places where the engine will call back in the stack and these can be used to great effect.
ReplyDeleteNow compare the number of extension points in Eclipse to the number of points in Firefox.
By the way, Apple apps can be scripted with AppleScript to gain access to data and operations in a standard way.
Lastly, look at EclipseMonkey, which failed to gain traction. The main reason I think it did is because the Java tools were (and still are) more powerful than the corresponding JavaScript tools.
At the end of the day, it's a personal preference thing. But you might as well argue for any language X that you want to develop in, that being forced to use Y is worse than Z. And IMHO both are better than C ;-)
and if you tried D langage? C++ efficiency and Java simpleness...
ReplyDeletehttp://www.dsource.org/projects/descent
http://www.dsource.org/
@AlBlue
ReplyDeleteI think you don't know much about javascript cause:
No namespaces,
- Have to say you're right there so built in functionality, but it's really simple to simulate namespaceing..
global variables by default
- there is no concept like by default, you're there's two way to declare variable one for local one for global, if someone usese first way by default it's not a problem about language.
no concept of threading
- wrong again if you want to use threads (you can easyly avoid that with async ways of programing) there's a xpcom component for that
https://developer.mozilla.org/en/nsIThreadManager
If you want threads in browser I would advice to look at workers in Google Gears.
As I mention above there's tool openkomodo also written on top of xulrunner, which is my default environment by the way and in many cases acts better then eclipse :)
the majority of extensions actually do pretty little.
- actually that's result of simpleness, because most extensions are developed by the people who just spend few hours to make their web experience better. unlike eclipse there's no interest of enterprise to extend it.
regarding the javascript itself it's really rich and dynamic language, giving you ability to make thinks you've could not imagine in Java. biggest problem is that people usually try to write code like they do in other languages and that's when they get disappointed. and if yous some much in java you still can use all the java libraries there :)
just Google xpconnect, rhino :)
Don't lose sight of the fact that the context of his presentation was "Next Generation Embedded Software" and that Domain Specific Languages too were on his list of things that are needed to make embedded application development more agile; I suppose DSLs are not so relevant from the CDT perspective though perhaps they should be. In any case, it's not clear to me that his arguments were intended to apply to all applications in general though it's definitely clear that he would never argue that someone's grand daughter will be able to write a C++ program easily.
ReplyDeleteIn the end, I regard bigotry with regard to programming languages as only slightly above bigotry with regard to human languages. Certainly in the case of programming languages, there is an actual technical basis for justifying claims to supremacy, but in the end, the right tool for the right job is the key. Personally, I like pretty much all languages but there is always something in each that I don't like so much and naturally some languages have more of such things. I do have a particular fondness for C++, having worked on an IDE with it and for it, but in the end, all languages are capable of expressing profanity, and you can't blame the language for such abuse.
It's not so much about the language.
ReplyDeleteTo Dave's point, it's how well the language interacts with the underlying system. Java has purposefully made that difficult since it was created as a web language with security as a top priority. In the early days of Java, it was never take seriously as a desktop environment like we're doing today. Unfortunately SWT made it work too well in that environment.
However we're still shackled trying to get out to the OS and the hardware. That is indeed most important in embedded. But with all the hoops we're jumping through to integrate with external tools like were doing in the CDT, it's important to us too.
Looking at V8's API for integrating with C++ code, I see a much cleaner path than Java gives us with JNI. It's what's making me thing if there is a better way.
"has it's difficulties" --> "has its difficulties"
ReplyDelete>But we already have Eclipse so
ReplyDelete>why would we do that all again?
Because this industry is obsessed with doing it again. I hate/love Java as much as the next guy, but I couldn't imagine Eclipse built in C++. The memory leaks alone would kill us. However, Visual Studio is a C++ application and it works.
I'm trying to imagine Eclipse built in JavaScript, with performance critical or device dependent parts written in C++.
Could you imagine SWT written in JavaScript? ;)
ReplyDeleteBTW, the C++ world has solved memory leaks with some really good profilers. Rational Purify saved my bacon many a time.
An alternative as a binding language to Javascript may be Python. An advantage is the ease of preparing a C++ class to be used from Python. Most of the work is done through the Boost.Python library (http://www.boost.org/libs/python/doc/index.html). There are even ways to automate the whole process using Py++ (http://language-binding.net/pyplusplus/pyplusplus.html).
ReplyDelete>Could you imagine SWT written in >JavaScript? ;)
ReplyDeleteSure.
In any language that does not include a garbage collector, API becomes problematic. Who free's what and when? Of course there are many, many examples of C/C++ API's in the word that work (like win32 etc.). These statements are obviously generalizations.
The C++ and javascript plan sounds good in theory.
ReplyDeleteUnfortunately it won't work that way in practice. What will actually happen is that everyone will write all of their code in javascript and never rewrite the performance hungry bits in C++. Given the options of spending several weeks to rewrite a component in C++, fixing a dozen bugs, adding a cool new feature, or reaching a new set of users, the C++ optimization will be low on the priority list.
After several years of development the javascript will get so tangled up with itself that it will be difficult or impossible to extract components to be rewritten in C++. With superb foresight this problem may be avoided, but we all know how pathetic foresight can be in software development.
You'll end up with an IDE written in javascript slower than what it is today.
@Michael: can't argue with that. No one will spend the time to rewrite/rearchitect Javascript in C++. But that's why you need to decide before you start what areas require C++.
ReplyDeleteThe CDT parser story is an interesting one. After writing it in Java, we kicked ourselves for not writing in in C++. But then we worried about the performance of the JNI and whether that would kill any performance gains we would have made by going native.
It's a trade off that needed analysis at the beginning. If we had done that analysis early, we may have had the opportunity to architect it to account for the performance of the interface. Or maybe we ended up making the right decision. At least we would have known.