June 27, 2004
ANTLR vs. JavaCC
I have recently had the need for a parser. The grammar I have to parse is reasonably simple but I have studied and written enough compilers in these past fifteen years to know better than hand-coding a parser myself (actually, the lexer is usually what turns out to be the trickiest part). I used to use lex, yacc, bison, etc... in the past so it was only natural to take a look at ANTLR and JavaCC.
Since I am fairly familiar with this family of tools, what I am looking for is pretty simple: a tutorial that will quickly fill me in on the syntax used to describe the lexer and the parser and how to invoke the tool.
ANTLR provided me just that. The home page leads you to a Getting Started guide that tells me exactly what I want to know. After ten minutes of research and reading, I feel qualified to start writing my first ANTLR grammar.
The experience with JavaCC was... quite different.
First of all, JavaCC's home page doesn't make the documentation link very obvious. Scroll to the bottom to find a few links, but even this doesn't turn out very useful pointers: FAQ, repository of grammars, installation and getting started (which actually only tells you how to install the software but not how to use it) and finally the complete documentation.
I am not looking for the complete documentation but I am running out of options, so that's what I end up clicking. The page itself is still not the "complete documentation" but yet another collection of links that I have to wade through in order to find what I am looking for. Needless to say my patience is running thin at this point and I am about to give up, especially when I see that the only tutorials on this page are about how the "lookahead processing" is performed and how the token manager works.
At this point, I just give up and I know I'll be using ANTLR.
Here is a quick advice to everyone who wants to make their software appealing: I know how tempting it is to expose the technical brilliance of the internals of your software, but just don't give in to it. Think carefully about your users, ask yourself why they would want to use your software and make sure that you design your documentation and your Web site with that in mind.
June 24, 2004
JavaOne's scheduling is broken
There is a lot going on at JavaOne this year. A LOT. So I was quite happy to see that Sun's web site was going to help me with my planning. Hopefully, better than last year.
So I log in and start reading the abstracts of the sessions. There are two hundred technical sessions and two hundred BOF'a. That's a lot of information. And since the web site only display ten of them each time, that's a lot of useless clicks. So here is a first lesson in web usability: let users configure how many items they want displayed per page. I know for sure I would have picked "200".
Anyway. Clickety-click, here I go, painfully adding some sessions while ignoring others. Finally, I'm done, so I go to the "My Schedule" page and I only find one session, the AOP panel I am attending. I panic for a few seconds until I realize that when I clicked on all these sessions, I wasn't saying I was going to attend them, I was simply registering my interest in them. Grrr... Okay, fine.
So I go to the Interest List page, where I find all my sessions. Good. I can also set the importance of each (High, Medium, Low) which, I read, helps the auto-scheduler do its job. Whatever. I just click on the auto-scheduler, I need to print it and leave soon.
Error message: "You have 53 sessions on your interest list. You can only have 30 maximum and the scheduler will only let you plan 24 of them. Please remove sessions from your Interest List and try again".
What?!?
What's the point of a scheduler if it won't let me plan sessions that conflict?
So I have gone through all this pain to carefully select what sessions I am interested in, and now I must delete most of them?!? What are they thinking?!?
Here is what a "real" auto-scheduler would let me do: select all the sessions I am interested in, all 400 of them if I so desire. Then print my schedule with their description, ignoring all the potential conflicts. You know what? I am a big boy and I can resolve conflicts myself as they occur. Besides, I might want to actually attend several sessions in a particular time slot. How? Well, simply by going to a session, finding it boring and then deciding to go to a different one at the same time.
Here is another good one: once you print your schedule, it will only show the technical name of the session (e.g. TS-1988, BUS-2042). How useful is that, seriously?
Bottom line: I'll schedule my conference all by myself this year.
Like all previous years.
And somebody at Sun: please hire a usability expert. Hell, even a usability novice will probably do better than what they have now.
EJB 3.0 at JavaOne
Here is a quick summary of various EJB 3.0 presentations you will find during JavaOne:
- Tuesday, 1:30pm: "EJB 3.0 Overview", by Linda de Michiel
- Wednesday, 7:30pm: EJB 3.0 BOF, by the EJB 3.0 Experts Group
If you have questions about EJB 3.0 or you want to provide feedback, the BOF Wednesday night is the place to be.
June 23, 2004
Assembly language today
As a former assembly language addict who used to live and breathe hexadecimal on a daily basis (okay, that was twenty years ago, until I saw the light with C), I was quite intrigued by this article called "Why learning assembly language is a good idea". Unfortunately, the author's obsession with performance spoiled what otherwise sounded like a promising piece of advice.
However, as new programmers worked their way into the system, without the benefits of having written several applications in assembly, the efficiency of software applications began to decline.
This is the first questionable assertion and while all of us can come up with examples of applications that are too slow to our taste, I don't believe this to be the case in a general manner.
it is clear today that the demise of assembly language's popularity has had a big impact on the efficiency of modern software.
This is not that clear to me. There are many skills you can leverage to make an application go faster, among which:
- Consummate use of a profiler.
- Knowing when your code is I/O / network / CPU / memory - bound.
- Understanding the documentation of the external API (the one you don't own) that you are using.
- Having some basic knowledge of algorithm complexity (O(n) versus O(log(n)).
I would argue that in modern software, the knowledge of assembly language will come in handy much less frequently than any of the above.
their ability to read disassembled high-level language code and detect heinous bugs in a system, and their understanding of how the whole system operates elevates them to near legendary status among their peers.
This might have been true twenty years ago. Nowadays, it's just cute :-)
The first milestone I achieved was the release in the mid-1990s of the electronic edition of The Art of Assembly Language. This book, along with the use of the accompanying UCR Standard Library for 80x86 Language Programmers, reduced the effort needed to learn assembly language programming.
I'm sure this is a great book, but what if I want to write assembly language on a Mac? Oops.
Maybe, just maybe, this might be a reason why assembly language is not as necessary as it used to be? Because it ties you to an architecture. Or worse, to a specific version at a certain point in time of a certain architecture. Until the next revision comes up, with its own set of operands, registers (or disappearance thereof) and quirks.
Since the author of the article teaches assembly language, I can understand his disappointment on the state of software, but what worries me is that his bitter attitude and partisan advice is part of the problem.
The best way to gain respect from your students is by not insulting their intelligence and just be honest with them. I've had math teachers open their class with "I know most of you don't care about mathematics and you will probably never use much of what is being taught here, so just take this opportunity to listen to some unusual things that will challenge your mind, and after that, you can just decide for yourself how useful it should be for you". Now that got my interest.
I encourage developers to learn as many new languages as they can, and the more esoteric the better. Assembly language is no exception, so if you've never had a chance to study it, grab a book one day and go ahead and I'm sure you will become a better programmer, somehow. But to me, the definition of a good programmer is not someone who is an expert on a specific language, but one who knows a lot of them and uses his good judgment to pick whichever is best for the job.
RTS.
June 21, 2004
AOP panel at JavaOne
As Adrian found out, I will be sitting on an AOP panel at JavaOne with James Gosling, Graham Hamilton and Gregor Kiczales. The panel is provokingly called "Aspect Oriented Programming: Great New Thing or Great Leap Backwards?" and Adrian was a little bit upset at Sun's apparent hostility toward AOP.
I am not that pessimistic.
First of all, think of the calibers of the people sitting on this panel and you will realize that if anything, Sun is trying to draw attention on AOP, not derail it. While Graham confesses to being an AOP skeptic, I am not sure where James stands but we will find out soon.
Regardless of the position of each of the participants, keep in mind that the point of a panel is not to convince any of the panelists but rather to expose all the pros and cons of a certain topic to the audience. And this is the biggest challenge when sitting on a panel: getting your message through to the audience, and resist the temptation to engage in technical discussions with the person sitting next to you, which will only lead to further the audience's confusion about the topic.
Discussing the in and outs of a certain technology with your peers is a very rewarding exercise, but it is better left to early evening chats around a beer, not to public panels such as this one.
As for myself, I would qualify as "healthily skeptical". I have used AOP, thought about it a lot and while I see the diamond in the rough, I think it needs a giant leap forward to become more mainstream. If you want to hear more, don't miss the panel!
June 17, 2004
Reusing tabs in FireFox
I just installed the new FireFox and by doing so, I lost a little trick that I have been enjoying greatly so far: whenever I click on a link from outside FireFox, I want it to be loaded in a separate tab in an existing window and not in a new browser.
The instructions to enable this feature are in the FAQ but a bit scattered, so here they are in a more concise fashion:
- Add the following to your user.js:
// Stop reusing active windows: user_pref("advanced.system.supportDDEExec", false); - This file doesn't exist by default, so you must create it. On
Windows XP, it can be found at:
c:/Documents and Settings/[user name]/ApplicationData/ Mozilla/Profiles/default/[random chars].slt/user.js
- Download and install
TabBrowser extensions
- Select Tools > Extensions, select Tabbrowser Extensions and click the
small Options icon.
- Expand the General node.
- In the Window Mode panel, select Use multiple browsers only for my request.
Note that the "small Option icon" in the Extensions window is not only minuscule but doesn't look like a button at all (no push affordance). It's the label with a check mark on it. I find this inconsistency in the FireFox GUI annoying: why should options for extensions be in a different menu than the regular preferences?
Anyway, FireFox is a cool browser, and even if the progress in terms of features is pretty slow, it is still light-years ahead of Internet Explorer, which has been stagnating for years now.
Update, 2004/08/23: I updated these instructions for the latest Firebox build since the path of user.js and the Settings option panel of the TabbedBrowsing extensions have slightly changed
June 16, 2004
New version of Doclipse
I just uploaded a new version of Doclipse, which now contains a definition file for Hibernate tags (thanks Ryan!) and also an improved preference page that allows you deselect files individually:
You should delete the previous directory of the plug-in before installing this one (the directory inside the zip no longer contains the version number, which makes things simpler for now).
June 15, 2004
Announcing Doclipse
Once you have installed Doclipse, you can add your own definition files for JavaDoc tags and they become available immediately in the editor.
Check out the Doclipse home page for more details.
June 14, 2004
Wipeout days
The theme for this past weekend was "reinstallations" (and also squash, volleyball and sun burns, but that's not nearly as interesting).
Overall, I have been extremely satisfied with Windows XP on all my machines, and I have even got used to my wireless connections dropping the signal mysteriously and reconnecting shortly thereafter. My living room is about sixty feet away from the base station, so it was no surprise that the signal was low. However, a few articles I read these past weeks made me wonder if I couldn't improve things by upgrading my current version of XP. I read that Windows XP SP2 improved significantly the wireless connectivity, so when I had a couple of hours Sunday, I decided to upgrade my laptop to this service pack.
Big mistake.
First of all, because I realized only too late that not only is this Service Pack only a tech preview (it's not officially out yet), but that it can't be uninstalled either. Since I didn't know that, I didn't bother setting a recovery point just before the installation (shouldn't any service pack install wizard do that for me automatically?), so by the time I booted my new XP SP2 laptop and was done marveling at the cute new wireless icons they added, I realized that not only was my wireless access completely hosed, but even my connected access was no longer able to reach even my gateway.
Annoying, but well... I'll just reinstall the original XP on that laptop and move on. Except that... the repair disk of that laptop doesn't come with a certificate of authenticity, so I'm unable to give the installation program a serial number. Alright, I'm gonna go old school on that one and install my own version of XP.
This part works, but suddenly the display of my laptop seems to crawl. A quick look at the drivers informs me that XP didn't recognize the video adapter on this laptop (a GeForce 4200) and is therefore using the generic SVGA. Mrmph. And it doesn't stop there: none of the other drivers (wireless, network, sound, etc...) have been detected by XP.
I decided I had wasted enough time with this and that my laptop was overdue for a brand new re-imaging. <sigh>
Later that day, I wanted to be able to synchronize my iPod on another machine than the one I currently use. I install the software, connect the iPod, make sure I uncheck "Let iPod manage my music", so that the new installation doesn't wipe out the existing songs on my iPod, and I let the program happily proceed.
Then I open my iPod icon and... nothing. It's been entirely wiped. ARGHHHH!
Apple is usually good in all things usability, but this overlook is just unbelievable. And the worst is that even though I am aware of this bug, I still got caught by it... again. This stupid software always assumes that if you install it, you have nothing on your iPod and when it tries to synchronize both parties... well, blam.
Great way to start the week.
June 10, 2004
Commenting is part of coding
This entry explains why it's better not to comment code so that junior programmers and newcomers to the code base really try to understand how it works:
If people are given an explanation that covers what they see in front of them, they won't go off and learn for themselves. If they won't learn for themselves, they won't be able to grow and develop. If they don't grow and develop, they'll never cease being junior people.I found this article quite amusing until I realized that robertwd, the author of this entry, was actually serious. He really seems to think that the more obscure your code is, the better it is for your readers.
I can't even begin to describe how wrong and arrogant this kind of attitude is.
It reminds me of an acquaintance of mine who was also teaching computer science classes. During a lunch, he explained to me that each of his classes was architected so that it would be a little obscure and would fail to explain a few things, in order to "keep a healthy distance between the knowledge of students and that of the teacher". "This way, you keep their respect, you see?". He was dead serious.
As seems to be the author of the above entry.
The simple truth is: you don't make junior people become senior by forcing them to understand the intricacies of your coding style. I am hoping that when robertdw gets to read the uncommented code written by these junior people and he tries to make sense of it, he will start realizing the importance of thoughtful, well-written comments.
Which leads me to my next point: I can tell the maturity (a term I prefer over "seniority") of a programmer by the comments they write. Not just by the fact that they write comments, but also by the way they phrase them and where they put them.
But this will be the topic of another blog entry. Until then, please comment your code.
June 07, 2004
Belize trip report
I have posted the report on my recent trip to Belize. Underwater pictures will be available in a few days...
June 03, 2004
Getter-based injection
Alright, I'm just back from vacation (report will be posted soon) and I have been following the reactions to my classification of getter injections with a lot of interest. Just for memory, here it is again:
- Force the dependency to be passed to the constructor (not always possible and very invasive).
- Have the container invoke a setter, or set a field on your class (mildly intrusive since it forces you to specify a setter or a field you will never use yourself).
- Have the container provide the getter (not intrusive at all, except that now, you need the container for your application, which makes out-of-container testing problematic).
It looked like we had reached a stalemate: option 3 looks like the best of both worlds except that it mandates the presence of the container, which is bad news for testability and brings us back to square one.
And then, Bob Lee came up to me and said "Why does the getter need to be abstract again?". And he proceeded to put together a quick proof of concept, which has been discussed on TheServerSide since then.
It was one of these "doh!" moments. Of course, the getter doesn't need to be abstract, but I guess my EJB bias made me overlook this fact. Bob is right, there is absolutely no need for this getter to be abstract, and now we have an answer for all these Test-Driven Development weeni^H^H^H^H^H (sorry, had a Hani moment) advocates: not only does getter injection work well with TDD, it makes TDD a first class citizen.
In the absence of a container, your class is testable right out of the box. All you need to do is provide a default implementation for your getter that will work in your testing environment. And if you run your code in a container, the getter will be overridden with a different value for production or staging.
How is that for the best of both worlds?