Beyond Java - Bruce Tate [91]
With the most basic Google skills, you can find dozens of papers that attempt to compare Java and PHP. You'll tend to find two types of comments. The PHP camp says that Java isn't productive enough, and the Java camp says that PHP isn't structured enough. I tend to agree with both of them. The primary danger with PHP for small applications is that they can grow into big PHP applications, and you're left without the structure that will let you easily maintain and extend your web applications.
Perl
Perl is a very popular language for programmers who look for raw first-cut efficiency. Perl was quite popular for shell scripts, before simpler alternatives were available. In terms of productivity, Perl has many of the characteristics of other highly productive languages. It's very expressive, terse, and dynamically typed. It gives you freedom to do what you want to do, and has a rapid feedback loop. Paul Graham calls it a great language for "hacking," or rapid experimental programming. Much of the Internet is powered by CGI Perl scripts.
Perl does have a downside. When you look at overall productivity of a language, you've also got to take things like maintenance and readability into account. Perl tends to rate very poorly among experts on a readability scale. As with Java, much of Perl's problem is cultural. Some Perl programmers would rather chop off their little finger than type four extra characters, whether the characters improve readability or not. After all, programs that were hard to write should be hard to read. Other Perl problems relate to the language itself. Perl's object orientation is obviously bolted on, and Perl has a secret handshake of sorts, in the form of many cryptic syntactic shortcuts that only the mother of Perl could love. A whole lot of us at one time or another have had some sort of love/hate relationship with Perl. It's interesting to talk about, but it's pretty much the antithesis of Java, and it's likely not going to make a dent.
Smalltalk
Smalltalk is a beautiful language invented way before its time. Smalltalk and Lisp are probably the two languages that share the most with Ruby. Smart developers used Smalltalk to build successful object-oriented applications long before Java was even a twinkle in Gossling's eye. And not-so-smart developers used Smalltalk to build some of the ugliest object-oriented code ever written. In truth, for the most part, in the mid- and late 1970s, we just didn't have the wisdom or the processing power for OOP yet, and we didn't have features like just-in-time compilers.
In Chapter 8, you saw the elegance of the Smalltalk language. It's object-oriented through and through, and the syntax is remarkably consistent. Smalltalk's syntax probably seemed strange to the masses of programmers who grew up coding COBOL, BASIC, Pascal, C, or C++. Most of the businesses I know of that actually tried Smalltalk were able to get their applications out in time, they just never were able to integrate those applications with the rest of the world.
Smalltalk never was able to lure C and C++ developers away, because it was too alien and had the perception of being too slow. As the small Smalltalk community waited for objects to emerge, Java's founders aggressively grabbed the C++ community by the throat, forced it to come along with C++ syntax and usage models, and offered solutions to solve the most pressing problems the C developers encountered. As we showed, Java was effectively a compromise between perfect OO and the C++ community. Later, IBM made a move to buy OTI, a maker of Smalltalk virtual machines. In one last push for Smalltalk, IBM built a common virtual machine into an IDE called Visual Age with the hopes that the common JVM could lend credibility to Smalltalk. It was too little, too late. We were too content in our newfound freedom, safely and freshly away from all things C++, in the arms of Java.
It's hard to