5.5. A Few Potential Suitors Now th at you've seen what the industry has to offer, let's take a quick review of some programming languages and identify some possible candidates. You'll see a more comprehensive treatment of the contenders in Chapter 9 . If you buy what I've been selling so far, you understand that for certain jobs, other languages may be better suited. I encourage you to try one of these languages every month or so. If you've not been exposed to languages outside of C++, Basic, and Java, I've got to warn you that the experience can be unsettling. You'll be surprised at how much of your knowledge commutes, and how quickly you can grasp the essence that makes a given language so productive. You'll also be surprised at the fury that you can generate around the office just by peeking at alternativesyou may want to leave the nice car in the driveway and take the old Family Truckster to work for a while. 5.5.1. Perl Perl is a scripting language, with a quirky syntax and a turbulent past. Here's a quick example that prints "Hi, Bruce": my $name = "Bruce"; print "Hi, ", $x, "\n"; 5.5.1.1. What I like If raw productivity is your goal, perhaps Perl is a possible answer. It's dynamically typed, is highly productive, and has a small community established. It also has a fanatical following. 5.5.1.2. What I don't like Perl does have a big downside. To this point, Perl's got a reputation of a write-only language: with its cryptic syntax, you can easily produce code that's very difficult to understand and maintain. Perl's OOP syntax, as with C++, is bolted on and awkward. As something more than a scripting language, Perl's reputation is probably a bit much to overcome. 5.5.2. Python As dynamic programming languages go, Python has been one of the most successful. It's very close to Ruby in syntax and power, and it supports the language features that you'd want. Here's a brief snippet of Python code that counts to 10: for x in xrange(10): print x 5.5.2.1. What I like It has many of the features you need in an application's language: dynamic typing, a quick feedback loop, and a concise syntax. It's pretty fast, and it has a version that runs in the JVM (albeit slowly). 5.5.2.2. What I don't like As much as I'd like it to be, I don't think Python is the ultimate answer. Ruby's inventor, Yukihiro Matsumoto (Matz), didn't use it because it's not object-oriented enough. [*] Python depends too much on whitespace, which most experts agree probably goes a bit too far. Others in the Python community aren't happy with the web development tools. [ ] The web tools seem to be based on the Java stack, so there's no radical invention or departure. The community doesn't feel right. At times, it's too academic and too defensive. [*] Dave Thomas, Programming Ruby (Dallas: Pragmatic Bookshelf, 2005). [ ] http://blog.ianbicking.org/why-web-programming-matters-most.html. The biggest hurdle for Python is its lack of compelling reasons to move away from Java. Python really needs a killer app. In the end, we've already formed our opinions. Python will be a moderately successful dynamic language, on the order of Smalltalk. 5.5.3. Ruby Ruby is an object-oriented language created in the mid-1990s in Japan. The Ruby community grew steadily, and the language is now emerging beyond Japan. It's gained popularity in the United States only in the last couple of years. 5.5.3.1. What I like Ruby has a beautiful syntax. It reads like English, and it miraculously stays out of your way. It's highly dynamic, and the educated core of the Ruby community works hard to produce clean, simple APIs. Ruby has strong web frameworks, and good support for XML and web services. Ruby has a couple of popular emerging frameworks, like Ruby on Rails. The web and XML frameworks are innovative and simple. The portable interpreter is fast, and it has the necessary plug- ins for the Apache web server. The standalone web interpreter, called Webrick, has several high-prof ile applications running on it. Most importantly, Ruby may have the killer app in Rails, which I'll discuss in detail in Chapter 7. This year will have four new Rails books and a strong publisher in the Pragmatic Bookshelf. Ruby doesn't have any political baggage that would turn away a potential commercial adopter. It's fairly mature. 5.5.3.2. What I don't like In Japan, Ruby has good commercial financial backing and support. Outside of Japan, Ruby has an embarrassing lack of commercial backing. Its relatively small community shows in the dearth of niche frameworks. The JVM support is immature (although it is admittedly improving rapidly). Early attempts to produce a version of Ruby running on the JVM had a few false starts. Still, the JRuby framework has seen a resurgence of sorts in early 2005, so it may well produce a credible Java alternative on the JVM. Ruby is on the radar; it just needs a tighter affinity with the JVM and the continued success of Ruby on Rails. 5.5.4. PHP PHP is a scripting language. With PHP, you effectively start with HTML, and mark it up with tags that can tie your application to a database, or other back-end systems. The tags get interpreted on the server, which returns pure HTML to the client. It's effectively a JSP. Here's a "Hello, World" app in PHP: <html> <head> <title>Hello, world</title> </head> <body> <?php echo '<p>Hello world</p>'; ?> </body> </html> 5.5.4.1. What I like PHP success seems to be ramping up sharply, mostly on the strength of converted Visual Basic programmers. It's very well suited for its "sweet spot," controlling database access from a web page. It's easy to understand and easy to learn. PHP, more than any other language, is taking advantage of the frustration in the Visual Basic community due to changes in .NET. 5.5.4.2. What I don't like PHP is theoretically awful. The model tightly couples the user interface and database together, and that's usually a bad idea, because changes in one can ripple through to the other. Since PHP grew rapidly and haphazardly with a heavy Perl influence, method names are often inconsistent, with some opting for underscores between words (stream_get_line) and some opting for concatenation (readline). PHP effectively has a reputation for productivity and rapid innovation at the expense of a consistent language that promotes sound architecture. As a Java programmer, you've probably already seen JSP pages that try to do too much. They're quick to write, but the solution bogs down in a hurry. 5.5.5. C# and Visual Basic C# is effectively a Java clone. It has many of the same benefits and drawbacks. Visual Basic on the .NET environment seems to be losing momentum, because the older Visual Basic developers don't seem to have the same fervor for VB.NET. Microsoft has other languages as well. In the end, Microsoft will always have a core set of developers. That's effectively a closed ecosystem, though. It's limited by the success of the Windows platform, which is adopted broadly on the client, but decidedly less so on the server side. I'm not predicting success or failure; I just think that Microsoft languages depend on the success or failure of Microsoft platforms as a whole, rather than on the strengths or weaknesses of any given language in it. 5.5.6. Smalltalk Invented in the early 1970s, Smalltalk is a well-established, hard-luck object- oriented language. Many see Smalltalk as the first object-oriented language, but it never really caught on commercially, despite some attempts as late as 1995 by IBM. It's hugely productive, slightly awkward, and quirky to the extreme. There is a vibrant, but small, Smalltalk community. Most of it is centered on a highly productive, continuation- based application development framework called Seaside, which we'll discuss in Chapter 8. 5.5.6.1. What I like Smalltalk has a clean object model, incredible expressive power, and an intelligent design and community. It's got some solid free implementations, and a potential catalyst in Seaside. Glenn Vanderburg is fond of saying that all things will probably return to Smalltalk, but they won't be called Smalltalk anymore. When you see the influence of Smalltalk on languages like Ruby, that idea makes sense. 5.5.6.2. What I don't like Smalltalk is not seen as a credible alternative. It just wasn't ever approachable enough. Smalltalk would have been a natural successor to C++ if Java hadn't come around first, but it was always too expensive, or too alien, or too obscure. 5.5.7. No Silver Bullet You may have noticed that no language has all the characteristics we're seeking. That's not surprising. If one did, we'd be using it by now. Still, you can see that these languages do establish real strength in important areas. In the chapters to come, I'll take a deeper look at Ruby. Since it's not enough just to have a better language, we'll then investigate some potential killer apps. . inconsistent, with some opting for underscores between words (stream_get_line) and some opting for concatenation (readline). PHP effectively has a reputation for productivity and rapid innovation. http://blog.ianbicking.org/why-web-programming-matters-most.html. The biggest hurdle for Python is its lack of compelling reasons to move away from Java. Python really needs a killer app. In the end, we've already formed our opinions. Python. I'll discuss in detail in Chapter 7. This year will have four new Rails books and a strong publisher in the Pragmatic Bookshelf. Ruby doesn't have any political baggage that would turn