I helped my dad replace his roof a year ago and we had one of those really cool power-nailers. Over the course of the project it probably saved us about two-hundred-thousand hours of back breaking work. When you used the power-nailer you could have one person lay out the shingles on the chalk line while another walked behind nailing them down. As a bonus it made this great THUMP, THUMP, THUMP sound that just reeked of masculinity. At one point I realized I accidentally left my regular hammer at the bottom of the ladder. I needed it because one of the nails hadn´t gone in all the way and I wanted to tap it down. Being the extremely bright and creative guy I am I thought, "no problem, I can use the power-nailer to knock that puppy in." In retrospect I´m pretty darn glad someone invented safety-goggles.
Writing code is just like roofing a house: sometimes you need a power-nailer and sometimes you need a hammer. If you´re smart you won´t try to use the power-nailer when the hammer is a better choice. I´ve been doing a lot of Java programming lately and Java seems to have left out a number of hammers, saws and screwdrivers. It annoys me no end. Let´s take this little one for example: the "eval" statement.
For those of you who have only programmed in languages like C++ and Java (that lack any kind of "eval" capability), eval is a way of having the system run code that was not parse-able at compile time. In Java, for example, a theoretical eval call might look something like this:
Public void callNamedMethod(String methodName)
{
eval("this." + methodName + "();");
}
This simple example would just call the method whose name matches that in the passed string. Now, of course, there are ways to do exactly this in Java using reflection. But, frankly, those aren´t nearly as easy or elegant as just supporting an eval notion. I´ve argued this one with Java fans before and they usually tell me that "anything that can be done with an eval can be done without it." In some very purist sense this is true, but many things that can be done in ten lines using an eval type syntax take literally thousands of lines without it (I´m not kidding). I´ve seen people go to the extreme of creating a BSF component to use to call back in to Java to do some of the things that would have been trivial if Java supported an eval.
The other argument I get a lot on this topic is that eval is "dangerous." The "dangerousness" of language features seems to be an almost religious notion with people who can only write Java code. Given the otherwise libertarian tendencies of software engineers (at least in the pre-outsourcing days) you would have thought people would have supported giving programmers the freedom of choice to use such dangerous features. Actually, this is really an argument about the dangerousness of abstraction in general. If you give it a little thought almost any feature that is powerful is also dangerous. To turn the analogy around, it´s like arguing that a roofer should go back to using hammers since power-nailers are too dangerous. Templates are dangerous (oh wait, Java picked those back up with generics), multiple inheritance is dangerous, pass by value is dangerous, aspects are dangerous, variable embedding in strings is dangerous. In my early years I remember hearing a similar argument about high-level-languages in general: "if the compiler writes it you don´t control it; the debugging will be a nightmare." Objects were viewed with similar suspicion.
Of course Java is clearly in the majority when it comes to eval. None of the major "hard-core" languages have it. Only so-called "scripting" languages (like Perl and Python and TCL) and fringe languages like Lisp and Smalltalk (which don't have it but don't need it) support that kind of a thing. I suppose that's part of being a "real" language. You have to go with whatever the mainstream thinking says is needed. Technically at least C++ has the excuse that an eval would be a pretty hard feature to implement, but java has no real excuse. I bet you can actually write eval yourself in about 20,000 lines of code (plus a pretty heavy additional set of jars) if you care to. Actually, now that I think about it, maybe there already is an open-source eval function we can add to the Jakarta commons. Let me know if you have one.
Don´t get me wrong, I like Java and C++ well enough. I´ve written more code in either of them than I have in any other language. I just think it´s time to stop philosophizing about what is good for a language and what´s not and start opening up a Home Depot of language features. We don´t have to be as postmodern as Perl, but at least make sure the language has all the truly handy and simple tools that they scouted out in the 1960s.
Wow, this has turned in to a bit of a rant, perhaps a rant rating of 7. I guess that´s what happens when you talk about power tools; it gets the testosterone going.
| 
