Monthly Archives: May 2006

GWT, Another Turning Point?

I still remember the first time I found out that I could drag the map in Google Maps to pan around the point I had searched for. The funny thing is that someone had to point out to me that you could do that. It wasn’t at all obvious to me at first and I really wondered how the hell they did that. Was it some scary voodoo magic?

Of course, now I know. It all has to do with sending requests off to the server using JavaScript and updating the HTML on the page on the fly in what we now know as AJAX. It works in pretty much any browser that supports JavaScript and it lets you create some pretty complex front ends without having to learn MFC or Swing (and, no, this isn’t a plug for people to read my page, I hate Swing for all the reasons Phillip does and won’t mention it again, much) or RCP for that matter. And, being in the embedded software industry, I think this is still a great way for embedded devices to get quick remote GUI interfaces.

So, when Mike pointed out the new Google Web Toolkit, GWT, I was intrigued. Taking a look at their pages, it was reminiscent of what Microsoft has done with Visual Studio and MFC as a toolkit for Windows and what we’re doing with QNX Momentics. Build a nice IDE and a good framework and developers will come. GWT turns out to be something similar for AJAX applications and uses Eclipse for the IDE.

The real question I have is, why is Google doing this? Sure they got a ton of money with their IPO, but surely this isn’t charity work for us interested in building web apps that don’t have anything to do with Google. But they are making a change in the industry where developers working on client software need to care more about which browser your users are going to use rather than the operating system. I think this will open the door for others to jump in and take some of the client OS share away from Microsoft. But that still leaves the question, why does Google want to do that? hmmmm….

I Hate Typing!

Those who have worked with me in the past know I have a favorite mantra that drives a lot of what I do: “I hate typing!” Now, after 20+ years working on computers, I can type pretty fast. But I can still think faster than I can type and that frustrates me at times. Mind you sometimes the extra sober thought between keystrokes has saved me from implementing the odd bad idea.

But this is the main driver for me when building tools. I find that the best tools are those that allow me to express my ideas by the fastest means possible. I have spent a lot of my tooling career building code generators for visual modeling tools, especially state machines. I’ve generated a lot of code relative to the number of user gestures. Customers loved it and I think it is still the best example of getting ideas into your software faster than you can type in the code. Hopefully as the Eclipse modeling tools grow, we’ll see more of this.

In the meantime, we are still pretty much left to probably the most imporant tools that we have in our tool chest, the programming languages. People who work with me also know that “I hate Java”. Yes, it’s an evil irony that I have spent the last 5 years being a Java programmer. As the JDT adds more accelerators, like more complicated content assists and refactoring, I hate Java less. But there are just some concepts that I find hard to express in Java, like complicated memory mapped binary files like I have with the PDOM, the CDT’s new index, and I just find I have to do a lot of typing to do what I need to do.

As I learn more about C#, the more I realize that it comes the closest to the way I want to work. It has the best of Java such as garbage collection and anonymous functions (anonymous classes in Java). Plus, it gives you the best of C++, such as stack allocated structs and operator overloading. And, if you don’t feel like playing it “safe” you can actually do pointers and take more control over your memory. I have no immediate need to use C# for my work time, so learning it has to be relegated to hobby time, which I have precious little of these days. But it would be interesting to see how fast I can get my ideas into code without typing so much.

Tracking Language Trends

After reading Ian’s post on Eclipse language support, I had to check out where he got the ranking information. It is provided by TIOBE Software’s Programming Community Index. I’m sure you can debate the merits of this index and the fact it is based on hits from the top three internet search engines, but as with all polls, it is pretty interesting to look at.

I’m pleased to see that, despite continuous predictions of C and C++’s demise, they still still #2 and #3 in this index, “eclipsed” only by Java. It is also interesting to note that C is still way ahead of C++. This is something we are seeing in the embedded space, where C++ is still seen as too expensive in size and performance for devices. For very small footprints, this is actually true, but the amount of memory and CPU power available in embedded devices continues to grow and this is becoming more a cultural issue than a technical one.

I was surprised to see PHP listed so highly, at #4. I guess I’m still suffering from my brainwashing that James Gosling did on me that Java was the only language for internet applications. The rise of PHP is probably killing Perl, which isn’t surprising as I consider Perl one of those “write-only” languages. I was somewhat disappointed to see the .Net languages so low, but then I’d bet that their query on Basic is picking up VB.Net unintentionally, which if true puts it on par with PHP.

I’ve been a huge fan of programming languages and paradigms since my university days many moons ago, which is probably why I’m so passionate about the CDT and why I keep pushing the CDT to make sure the it can handle multiple languages. To a large extent, we treat C and C++ as separate languages, so adding a new one shouldn’t be that hard. We have Photran team exercising that with Fortran (which failed to make the top 20 but sits at #21, stay tuned for it’s renewed meteoric rise!). I also have a hook on a student in Google’s Summer of Code that is interested in doing C# and VB.Net for Mono.

Being compiled languages, they benefit mainly in the build and debug side of things, but I’m hoping to extend it to the editor and indexing side with CDT’s code models. IDE generation is one thing, but to be fully functional environments for complex industrial strength languages with all the wizbang features of the JDT, you need a solid extensible framework that we are hoping to provide with the CDT. It’s all really cool stuff, well for me anyway, and, of course, helps build the CDT community by expanding it’s horizons.

ANTLR v3, Everyone’s Parser Generator

And now for something, completely different…

I’ve been toying with the idea of expanding my desires to better support Windows development to better supporting .Net development. There’s lot of interesting things happening there not just on the Windows side, but with Linux as well with Mono. Not to mention, there is a Java VM implementation that runs on the Command Language Runtime (CLR) called IKVM. The IKVM is interesting because I just tried running Eclipse 3.2RC3 on it and, aside from a few ClassNotFound and IllegalArgument exceptions, things ran fine albeit a little slow at times. That raises the specter of writing Eclipse plug-ins in C#, but more on that some other time.

So, of course, looking for a break from the mad dash to finishing CDT 3.1, I started writing a parser for C#. I’ve been dying to try out the new version of ANTLR v3, which is in early access mode of the famous open source parser generator written by Terence Parr. The biggest plus is that it promises to support LL(*) grammars, i.e. almost any grammar that isn’t left recursive or ambiguous. I’ve spent plenty of time trying to get ANTLR to accept modern complicated grammars such as C++ and Ada, but gave up after a little while because of all the effort needed to refactoring the grammar to meet LL(K) restrictions. (For the curious, LL pretty much means top-down parser which is generally how you’d hand write one, like we did with the CDT’s C/C++ parsers, and the thing in the parens is the amount of lookahead used to make decisions on which path to take. ANTLR v3 supports infinite lookahead, previously thought of as too expensive but Terence is proving us all wrong).

Well, I’ve just started and my initial report is “Wow!”. Every time I enter a rule that used to give previous versions of ANTLR as well as LALR parser generators such as yacc and bison fits, I get no errors. And looking at the code that gets generated, it looks decently efficient, using a special algorithm to make the lookahead efficient. Hell, at this rate, all I have to do is type the grammar as it’s given in the C# language spec and I’m done. Well, not really because the grammar as it is found there has left recursion and has ambiguities, but all these can be fixed with fairly simple refactoring.

I can’t wait for Terence’s beta in the summer, when hopefully he’ll have some documentation so I don’t have to guess at the syntax based on the examples. Also, he is changing the licensing of ANTLR and has rewritten the code so that he owns the copyright, which all means that ANTLR should be acceptable for inclusion with Eclipse projects (hopefully, cross my fingers). All of which should mean that it’ll be easier to write parsers for new languages that we want to support with the CDT’s code model, DOM, and indexing framework. Kudo’s to Terence! Now back to CDT 3.1…

Sounds familiar

We’ve had some good discussions lately in the Planet Eclipse blogosphere about whether Eclipse project should be focusing on the concerns of users or building a platform for ISVs to add their value. In the end, I conclude that you need to balance both for the sake of growth in your community. Unfortunately, though, or fortunately as the case may be, Eclipse projects are staffed almost exclusively by Eclipse members who fit more in the ISV camp. These guys need to justify their investment in the Eclipse on the bottom line. It’s the nature of the business, and there’s nothing wrong with that, since without it we wouldn’t have the great Eclipse that we have today.

Of course, this isn’t just an Eclipse thing. A lot of high quality open source projects are staffed by ISVs and the concerns are the same. Recently, chief Linux maintainer Andrew Morton has been frustrated by the focus of his development community as well. Most of these developers are employed by OEM-types who support Linux running on their platform. But a lot of users who are using “unsupported” platforms are raising bugs that these platforms aren’t working anymore. How do you get your developers to focus on something their real bosses don’t care about?

Well, this is a big challenge for all open source project leads. Developers contributing to open source aren’t under contractual obligation to do anything. What they do work on is generally based on the needs of their employers. Yes, that’s a pessimistic view because everyone I that I work with in open source is very concerned about all users of their stuff, no just the users that their bosses care about. But when tough decisions need to be made, you can be sure that the general user loses out.

So is that all there is too it. I don’t think so. One thing that I think ISVs contributing to open source often don’t think of is that, you’re “open”. Everyone can see what you’re doing. Everyone can find out that your contributing to it. And if the general community starts making a fuss, especially in the media, that the open source software that they are freely downloading doesn’t work for them, that can reflect badly on the open source project. That could lead to negative publicity that your customers get to see, who may in turn start questioning the quality of the product your are trying to sell them.

As I said, the ISV’s need to focus on their bottom line when they consider how to invest in open source. But they need to take everything into consideration, not just the direct needs of their product, but to make sure that the integrity of the project they are building their house of cards on stays on the good side.

Lego Open Source

Back when I was working at ObjecTime, a real-time object oriented modeling tool vendor, we tried to convince our boss that we need to port our code generation tools to support the then new Lego Mindstorms. He thought it was a great idea but couldn’t come up with the business case for it. C’est la vie. That was almost ten years ago and I had almost forgotten about it.

If you’re a regular Slashdot reader you’d have seen the note about Lego open sourcing the firmware for their new Mindstorms NXT brick. Well that hooked my attention. Investigating further, I found out that this little box was a pretty powerful little unit with a 32-bit ARM7 processor with 256K Flash, 64K RAM, a second 8-bit microcontroller which I assume drives the sensors and motor controls. It has a USB for connecting the brick to a computer for downloading new firmware and programs. It also has a Bluetooth interface so you can hook up to other devices, or even cooler, have multiple bricks talking to each other.

So do you get the sense this is on my Christmas list? You betcha. Can I justify it. Well not really. But it would be very cool to have Eclipse support for this target: CDT to work on the firmware and programs in C and DSDP components for target management. Maybe I can convince Ian and Mike that they need a cool demo for next year’s Eclipse booth at ESC. hmmm.

CDT in Action on Big Projects

It’s pretty common knowledge now that I use the Mozilla, and lately Firefox in particular, as my main test bed for scalability testing. It’s a pretty big project and I have often found issues with the CDT in this environment and we are trying to address them as we can.

I was pleasently suprised the other day when by friend John Camelon (Mr. CDT Parser) brought the following article to my attention. It was written by Robert O’Callahan who blogged last summer about the promise of using the CDT for Mozilla development. At the bottom of this new article is a list of issues with using the CDT on Mozilla, a lot of which we are still working on and will feed into our CDT 4.0 requirements for next year.

I was also pleasently surprised when I went to take a look at the install instructions for ACE & TAO, a pretty big communications framework written in C++ that users have reported problems with in the past. In those instructions are instructions on how to use the CDT to develop ACE applications. Very cool.

It’s hard to see how widespread the use of the CDT is out there, at least from where I sit in here. These two examples certainly have certainly opened my eyes a little. Now back to addressing their scalability problems…