Mid-Twentieth Century Languages

In the News:

Dell to buy Perot. Having trouble competing with HP? Here's an idea: go head-to-head with IBM.

Mid-Twentieth Century Languages

Ruby's powerful and full of Tim Toady. Python's powerful and pythonic. In one area, however, both are bad reminders of the 1960s.

I refer to the fact that both are strictly interpreted, according to the lamest definition of the term. They begin processing at the top of the file. Declarative code? Processed. Imperative statements? Processed.

The intelligent way, of course, is to read the file handling all the declarative code first. Functions, for example, are defined and ready for use when the imperative code is processed. Functions may be declared where they make sense. The structure of the source code is not dictated by the processor; it's decided by the programmer.

Ruby and Python? Nope. Don't place your imperative code at the top of the file; library functions at the bottom. You cannot call a function from statements above the function's definition; you cannot instantiate an object ... This is stupid.

JavaScript eats your source code's declarations first, then goes on to process your imperative code. JavaScript is not the world's most advanced language. That Ruby and Python are less advanced than JavaScript should be an embarassment to both.

If you remember Pascal from the early days of microcomputers you remember being forced to write your main program at the bottom of your file. This was, and is, a tragedy if you valued readability. This is how you must structure your Ruby and Python.

JavaScript gets this right. Java lets you put "main()" where you choose. This should be completely standard in this century.

Error Handling

Today is 9/11/09. John and I played an hour of tennis once a week from 7:30 to 8:30 in the morning. We played eight years ago on this day, quite happily ignorant of the events unfolding in Manhattan. By 9:00 we were a half-hour apart, at our respective offices, watching TV. We haven't played since. And so it goes.

Error Handling Overview

Some processes can generate errors despite the most skillful coding. Disk I/O is one example. (User enters name of a file that doesn't exist. Data cannot be written because the disk is full.) I first met try/catch logic in the mid '90s in Java as a way to handle these sorts of errors. This is now a feature of most mainstream languages.

The basic idea is to surround a block of code (such as disk I/O code) with a "try this" instruction. Following the block to try there is an "if an error occurred" block. Some languages, Java included have an optional "whether or not there was an error do this" block. Code in the "try this" block (including, importantly, subroutines called in that block) can "throw" an error, often an Error or Exception object for use in the "if an error occurred" block.

Error Handling in Java

This is the basic Java syntax:

 try {
 }
 catch (Type1ExceptionOrError var1) {
 }
 [catch (Type2ExceptionOrError var2) {
 }]...
 [finally {
 }]

Java has both XxxException and XxxError classes. The builtin classes can be extended by the programmers to create more Exceptions and Errors. Multiple catch clauses allow code to be written to handle particular Exception or Error types. Importantly, catch (Exception e ) {} will catch all exceptions, though it loses the ability to use any added information in extending classes. Errors can be handled similarly, but are generally not handled. A Java Error would be something like a hardware failure that the program probably cannot deal with successfully.

If I were redesigning the language I would eliminate the finally block entirely. The catch blocks should simply branch to the code that follows the last catch block.

I would then use only a single catch block. If needed, the programmer can put a switch inside that block which calls code appropriate to the exception type.

That said, let's look at the ways some other languages address the issue.

Error Handling in JavaScript

JavaScript follows Java's try catch finally lead, with two important differences. First, there is only a single catch block. Second, the thing caught may be anything: object, string, number, ...

In JavaScript: The Good Parts, Doug Crockford eliminates the finally block, leaving exactly what I recommend for Java.

Error Handling in Python

Very like Java, but the catch block is known as an except block.

Error Handling in Ruby

Similar to Java, but Ruby stubbornly goes its own way. You don't try, you begin. You don't catch, you rescue. You don't finally, you ensure.

Ruby also features a retry keyword that repeats execution of the try block.

"Martin, don't forget that stupid Tim Toady! You can use catch blocks, too."

"Thanks, Monty. I'll put that in."

Monty, my pet python, knows just enough Ruby to criticize it.

Error Handling in C++

Like Java you have try and catch blocks. Unlike Java there is no finally block. Also unlike Java, there is no restriction on the type of thing caught. Strings and integers, for examples, can be caught. There is also a generic "catch anything" variant, though there is no way to hand the thing caught to the code in this catch block, a disadvantage of strongly-typed languages.

Python on Python

Yesterday my python slithered off, mad because I was writing Ruby. I feared he'd swallow the kitten. Since Python lets you create attributes on the fly, I solved the problem:

python.diet = 'vegetarian'

Actually, Python has nothing to do with snakes. The name comes from the British comedy troupe, Monty Python. My python is named Monty. Ruby gets its name from lists, such as wedding anniversaries, where Ruby follows Pearl.

When Python and Ruby engineers debate the merits of their respective languages, the discussion is generally learned and respectful. Monty, on the other hand, can really get going.

"Hey, Monty! Want to talk about Tim Toady?" (He never passes this one!)

"There you are. Tell me what you think of Tim."

"Martin, Tim's a fraud. There's maybe sixteen different ways to loop through an array in Ruby. You got some hotshot coder who never does it the same way twice. OK, boss. Who's going to maintain that crap? Some junior coder who just learned Ruby? I don't think so. You're stuck with hotshot. Hope you like paying his six-figure salary."

"Let's show a little real code." Monty dictates a little Ruby and Python.
Python

ids=[...] # array, listing division's employee ids for id in ids     # code processing     # each id

Ruby

ids=[...] # array, listing division's employee ids ids.each { |id|     # code processing     # each id }

"You could write that loop other ways in Python, but no one would. That's the one, obvious way to do it. Ruby dudes will write every loop differently to show off their Tim Toadiness. And no, I did not forget curly braces in Python. You indent and you get code that looks like, and is, blocked."

"I could go on, Martin, but I just got this sudden urge for some broccoli. Broccoli? I never ate broccoli. What's going on?"

Monty slithers off. Actually, in Ruby looping by the "each" method is the preferred way, in most instances. The simplicity of the Python illustrates the quality that Pythonistas call "pythonicness."

Ruby, Python and Tim Toady

In the News:

Why Bing Is Gaining on Google

A triumph of creative headline writing. Bing soars from 7.2% to 8.2%. Google: 78%. Yo, Steve. When your competitor's name becomes a verb, they've solved the problem. If you don't want to take my word for it, google it.

Python v. Ruby:

Executive summary: two excellent modern, multi-paradigm languages with fiercely partisan fans who never tire of arguing for their personal choice. In the end, the one you prefer probably depends on where you stand on Tim Toady.

First, the basics. Both languages are interpreted, not compiled. Both are more than fast enough for business computing. Neither is strongly typed. Neither is more error prone than, for example, Java.

Both are object-oriented. Almost everything in Python is an object. Everything in Ruby is an object. (In Ruby, "2+2" is a notational convenience for "2.+(2)". That's an object "2" with a method "+" called with another "2" object as argument.)

Ruby's OO constructs are more Java-like. Python's object model struck me at first as chaos. You start with what in C++ or Java would be two instances of the "dog" class, "fido" and "rover" for example. If fido does tricks, you stick an array field to him: "fido.tricks = ["jump", "roll over", ...]. No need to extend any class, no problem that rover has no tricks.

Multi-paradigm means that unlike Java, you use OO coding when it works for you. You use other techniques and you don't force OO solutions on non-OO problems. For example, both support functional programming: the ability to pass code around and manipulate it as easily as other traditional languages handle strings.

Big difference: Rails. Ruby on Rails is the Ruby language with the Rails website framework. The Rails framework gets all the attention of the Ruby community. By contrast, Pythonistas are split among multiple frameworks, none enjoying the effort put into Rails. Rails JavaScript framework, Pythonistas argue, is based on Scriptaculous which is based on Prototype which has an enduring reputation for bad code.

Both languages work. Spectacular websites can be built successfully with either. Both will give you the same results as you could get with Java EE but with much less code, which will simplify maintenance. Would I recommend one or the other? For me, yes I would. For you? I would not. That's because I have a definite stand on Tim Toady.

Tim originated in Perl (which I recommend you avoid if at all possible). TMTOWTDI: There's More Than One Way To Do It. "Tim Toady" is the way it's pronounced. Ruby, which was designed as a better Perl, features Tim Toady. Pythonistas say, "There should be one, obvious way to do it."

I'd say more on this, but my Python just saw the Ruby code on my screen and slithered away looking very mad. I've got to find him before he swallows the kitten. (Why Ruby? SketchUp plugins can be written in the language of your choice, provided you choose Ruby. How can I explain that to my Python?)