|
The Importance of Unit Testing
BB: Do we have any assurance that people will do unit testing? If I drive over a bridge, it doesn't help me if the engineer who built the bridge was supposed to use unit testing and didn't.
Neal: It doesn't help you either if the engineer was supposed to follow all the rigors of civil engineering, and didn't. Type checking doesn't say anything about the validity of your code.
In some ways, the strong typing compiler gives you a false sense of safety. It doesn't say anything about the validity of your code. Strong typing is just getting graded on syntax by the compiler. But that doesn't say anything about what the code is supposed to be doing. Unit testing does address what the code is supposed to be doing.
Stuart: I want to undermine the pendulum analysis a little bit. I am going to unfairly paraphrase Paul Graham from his book Hackers and Painters. Paul lays out a different slant from the pendulum analogy on language evolution. He says we have God's own language—Lisp—and that there are nine things that make Lisp great. The software development community is absorbing these nine ideas, one by one, over time. So it's not actually a pendulum swinging back and forth. It's the community maturing and learning how to incorporate these nine ideas.
I don't remember the exact numbers, but Java has, maybe, four of the ideas baked into it. Ruby and Python have about seven. So in Paul Graham's view, five or ten years from now, we will all be using a language that has all nine of these features. In his case, he hopes it will be Arc, which he is developing as a child of Lisp and Scheme.
So the pendulum analogy may not be right. This may not be a fashion, where the pants get lower for a while then the pants get higher for a while. Rather, we don't yet have the maturity as an industry to absorb all nine of these practices.
Now, nine might not be the right number and Paul's list might not be the right list. But we are gradually developing the maturity to absorb the right practices over time. So we are not going see the pendulum swing back. What we'll see in a few years is that we absorb a few more new practices that have been out in the research community—practices that are already part of some less widely-used languages.
If there is an abstraction that addresses your problem, then trying to avoid that abstraction, or pretending it doesn't exist, or saying that the abstraction is too complex and trying to solve the problem without that abstraction isn't going to help you.
BB: This brings us back to the idea of using Java because Java has so many libraries. Weren't you saying that, for practical purposes, you may lean toward using what's available? On the other hand, if you migrate swiftly to Ruby on Rails, then you're helping advance the technology.
Stuart: There are always trade-offs. To be fair, these technology choices, while important, are not the drivers. To me, the technology platform choices factor about ten percent into a project's success. The other 90 percent is the discipline with which the platform choices are applied and—more importantly—the rigor and creativity that goes to learning the problem domain and learning what people actually need.
Over here, we have a team with no clue about the domain but the team will make the best possible language and library choices. And over here, we have a team that knows the domain very well and is very creative in thinking about the problem domain but has a backwards technology stack. I would rather work on the second team. (Actually I wouldn't mind having a lucrative consulting job helping them choose some of the technology stack from the first team.) That being said, we love debating these technology issues. Which stack is the best will always be a big topic of discussion in the engineering world.
Ruby in the Enterprise?
BB: I hear repeatedly that Ruby on Rails is great for small-to-medium projects, but for an enterprise project, you still want to use Java. Can you elaborate on this point?
Justin: Yes, it's security, security, security. The Java platform has the best baked-in, ground-up, well-integrated security model of any platform available today. Ruby has nothing, and a guy working on the Python platform has explicitly said: "Don't bother with our security platform. It's not up to snuff and it's not well documented and nobody has reviewed it." The flip side to that is that only eight percent of all Java products actually turn on the security manager. So even though it's got this great security stuff built right in, nobody actually uses it.
Secondly, you have things like transactions management. If you have to do cross database transactions (which about ten percent of all enterprise apps have to do) then you don't have a choice. You are either going to live inside a COM+ transaction management system or you are going to work with the JTA.
Those two things (security and transactions management) are the giant elephants sitting in the middle of the room that say "You can't approach." Other than that, the other frameworks—the Ruby on Rails and the cherry pies of the world—are going to catch up and people will stop saying they're "good only for small-to-medium projects." Instead, people will say that Ruby on Rails is "fine for all but the huge projects."
Stuart: One of the interesting questions when you look into dynamic language frameworks is "Why can't we have everything? Why can't we have a dynamic language that targets the Java VM, or even better, a dynamic language that targets both the Java VM and the .NET run time?" It appears that Python had the early lead in this regard because Jython was the first real example that got noticed in the Java world. Jim Hugunin, the father of Jython, is now at Microsoft where IronPython is targeting .NET. (Originally Jim Hugunin tried to prove that Python wouldn't work as well with .NET. Then he found Python working as well or better with .NET. Shortly after that, he went to Microsoft.)
Getting Ruby to target the JVM was very hot a year ago. But now, the Ruby community doesn't seem to be as concerned with the JVM.
Neal: Some of us doubt that you can actually implement the full blown Ruby on top of Java or .NET, because of continuations. Ruby supports continuations, but continuations are devilishly difficult to create on virtual machines. But we'll see. A lot of cleaver solutions to problems come along—solutions that, at one time, didn't seem possible.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
