Closer To The Ideal

I sent this email to some programming friends of mine:

Some real surprises (for me at least) in this year’s December usage stats for languages:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

PHP is now the 4th most popular language in the world. It has edged out Visual Basic. I think this means that a lot of data entry forms and corporate intranets (the mainstays of Visual Basic) are now being done over the web, so PHP and HTML are being used for more and more of those projects. Visual Basic still has a huge advantage in terms of form widgets, and the level of interaction that can be achieved with forms. Maybe HTML 5 will narrow the gap somewhat? The use case for Visual Basic would fade a great deal, at that point.

It is a little odd, maybe, that PHP is the top ranking script language. It is universally regarded as less professional than Ruby or Python, but it is way more popular. Facebook is built almost wholly in PHP. Yahoo has used PHP for several recent projects, such as Yahoo Bookmarks (a competitor to del.icio.us, I think).

Very surprising (to me) to see Ruby moving down. It has been synonymous with “Web 2.0″ phenomena.

Java remains the most popular language. Have to admit, when I studied it, Java itself bored me to death, but I have become fascinated with JavaFX, since its release a few weeks ago. It is very light weight and simple (compared to Java). None of the freaking double declared typing and “narrow casting” and “wide casting” that I hated about Java. In my spare time, I’ve been working on a spaceship shooter game, mostly as a way to learn JavaFX.

One of my friends wrote back:

Somehow I’ve managed to never write a single line of Java code in my career. I count myself lucky. :)

I responded:

Yeah, I agree. It is kind of amazing to me how many smart people have worked on Java, and how awful it is. Stuff like “If you want your object to be serializable, then it must implement the Serial interface, even though the Serial interface does not have an implementation.” Hate that!

And the double declaration of a variable’s type, usually declared with a widening cast:

Integer automobiles = new LotInventory(94);

Who really wants to waste neurons in their brain keeping track of stuff like that?

Most of Java seems overly complicated and overly abstract – theoretically correct in an academic computer science kind of way, but not actually useful.

Even the die-hard defenders of Java are less willing to defend the language. I think this is the influence of Ruby. Since the emergence of Ruby, there has been an explosion of script languages that run on the JVM: Jython, JRuby, Groovy, Scala, and now JavaFX. And, of course, some of the best known writers who built their careers around Java (Bruce Tate, Bruce Eckel, etc) have become big fans of Ruby.

I read Bruce Eckel’s book back in 2003. That was when I started trying to learn Java. My only serious attempt at a Java project was in 2005, when I was trying to build a client side file uploader, a modified version of the software they discuss in Matthew Robinson and Pavel Vorobiev’s book about Swing. I decided I hated the language and gave up trying to learn it. Little did I know that the Java platform was about to get interesting. The big change in the Java community happened a little before Bruce Eckel wrote his essay “The departure of the hyper-enthusiasts“:

The Java hyper-enthusiasts have left the building, leaving a significant contingent of Java programmers behind, blinking in the bright lights without the constant drumbeat of boosterism.

But the majority of programmers, who have been relatively quiet all this time, always knew that Java is a combination of strengths and weaknesses. These folks are not left with any feelings of surprise, but instead they welcome the silence, because it’s easier to think and work.

Where did the hyper-enthusiasts go? To Ruby, apparently. This is chronicled in Bruce Tate’s book “Beyond Java,” which should probably be titled “Why Ruby is Better than Java.” The book is roughly edited; you’ll find yourself thinking “haven’t I read this paragraph before?” in any number of places, but that’s a disappointing experience I’ve had with several O’Reilly books of late. In many places he plays fast and loose, and almost at the end of the book he declares that he doesn’t have time to learn these other languages in any depth — although he has no trouble condemning the same languages in his rush to Ruby. Such a statement should be in the first paragraph of the book: “I’ve decided that I love Ruby, so I will condemn other languages without fully understanding them” (in one sentence repeated in a number of places in the book, for example, he declares that C# is no more than a clone of Java). I’ve been on the rollercoaster of language-love myself in the past and have made similar mistakes; one error in particular was dismissing Python’s scoping-by-indentation when I first saw it (months later realizing that we always indicate scoping by indentation anyway, even when we have curly braces available). Now I try to investigate and support my ideas about these things more thoroughly. It takes a lot more time and effort to do so, but it also leaves a more lasting impression.

Eckel correctly points out that the wonders of scripting languages are purchased with loss of efficiency, and some of the ugliness of Java or C or C++ are due to the compromises they make to gain efficiency:

Martin’s argument is that Java’s List interface requires you to say aList.get(aList.size -1) to get the last element, and this seemed silly to him. Which it is, if you have unified all sequence containers (that is, list containers) into a single type, as Ruby and Python do. Java, however, follows the C++ STL approach of providing different types based on the efficiency of various operations. The Java libraries do not unify to a single list type because of efficiency issues, so you have to decide if you are going to be fetching the last element from a list a lot, and if you are you use a LinkedList, which does have a getLast() method — a fact which was completely left out of Martin’s original discussion, and the ensuing firefight (other than some ignored comments).

Elliotte Rusty Harold (who took over the management of the Java track at the SD conference from me; I actually lived in the building next to his in Brooklyn for two months once) observed that Ruby’s library design didn’t seem so simple and clear to him, and he went into detail about many of the methods in the list class, pointing out that they often seemed to make no sense and wondering whether anyone was actually using some of them. Elliotte has spent a lot of time on library design recently, producing the XOM XML library which, I think, represents some very clear thinking. Look at what he writes; I think he makes a good case.

…Understanding the constraints under which Josh Bloch designed the Java libraries might make you understand that design a little better. Personally, I prefer the simplicity of Python’s single list class to Java or C++’s multiple implementations, but a single list implementation must make efficiency compromises. Library design involves compromise, and if such a compromise disagrees with you you’re likely to feel it was a bad choice.

Eckel is writing in 2005, but already it is clear what a revolution Rails represents:

And of course, who can ignore Rails? The backlash from heavyweight web frameworks has been significant. We now know that EJB 1 & 2 were based on an entirely flawed set of use cases. Because of the damage this (still slowly dawning) realization has wrought to Sun’s reputation, it’s hard to know whether EJB3, which probably should have been called something else to disassociate it with the failures of its predecessors, will succeed, despite the fact that EJB3 is like a breath of fresh air. You look at the code and it makes sense; no bizzarre and obscure interfaces and concepts to puzzle over while thinking, “I wonder why I have to do this? Well, these guys are clearly smarter than I am.” (I tried to understand EJB1, but when I first heard that entity beans didn’t actually work, my brain refused to let me invest any more time, which turned out to be the right choice). As a result of all this, someone said “hey, all I want to do is create a database and use it from the web. Why should I do all that work?” As it turns out, such activities seem to be about 90% of all we ever do in “Enterprise” programming, and EJB 1/2 were solving an entirely different problem, and making the 90% incredibly difficult in the process. Thus, the Rails approach of “just connect the database to the web.”

In retrospect, he makes only mistake in his whole essay:

However, I can’t see Ruby, or anything other than C#, impacting the direction of the Java language, because of the way things have always happened in the Java world. And I think the direction that C# 3.0 may be too forward-thinking for Java to catch up to.

But, as I said before, there has been an explosion of light-weight scripting languages that run on the JVM, and I think part of that is the influence of Ruby. And part of that, too, is simply that programmers want programming to be joyful and joyfulness of programming is something that only the scripting languages can deliver.

(Weiqi Gao offers a counter argument: “I classify myself as one of those developers who don’t get Ruby, just like I don’t get Perl. Both are too hard for me. And there seems to be something in my brain that prevents me from learning both. It’s strange I never had the problem with C or C++ or Python or Lisp or awk.“.)

Java code tends to be more verbose (and also more academically correct) then anything I want to work with. Consider this simple example:

Socket socket = new Socket(”time.nist.gov”, 13);
InputStream is = socket.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
Buffered reader = new BufferedReader(isr);
reader.readLine(); // skip blank line
String message = reader.readLine();

So, socket returns an InputStream object. I’ve no problem with that. But inside of the InputStream object is a string of information that I want, and I can not get at it directly. Instead I have to give the InputStream to an InputStreamReader. And then I have to give that reader to another reader? Are you kidding? In PHP this would be:

$handle = @fopen(”http://time.nist.gov:13″, “r”);
$emptyLine = fgets($handle, 4096); // skip blank line
$buffer = fgets($handle, 4096);
fclose($handle);

Personally, my feeling is that life is short, so I don’t want to waste time with low level programming languages. I want to move fast, and the scripting languages allow me to move fast. Back in the 90s I got my first taste of programming with HyperCard and then later Applescript and then PHP. I studied how to use C to program System 7 projects on a Mac, but C was slow going. I’ve realized, over the years, for the things that I want to do with my life, I prefer the speed with which I can program in script languages. And that is why I am excited that script languages like JavaFX have arrived on the JVM. Amy Fowler sums up the aspects of the language that make life easier for the programmer:

But longer term, how many applications won’t be rich internet applications? Increasing graphics hardware acceleration is enabling the trend towards more beautiful and fluid interfaces. Ben Galbraith highlighted this point in his excellent User Experience JavaOne talk when he pointed out that user expectations have now been raised beyond just usability — they now expect to be wowed (recall Maslow’s Hierarchy of Needs from Psych 101). It may be that consumer applications are leading this charge, but in the end we’re all human beings and there is no reason why we shouldn’t feel as pleased with the applications we use at work as with those we use at home. And note that “beauty” encompasses both aesthetics and purpose.

So how do you get a beautiful application? You have it designed by people who understand visual design and usability. Period. Karsten Lentzsch once made a great point that “finding the design” is really the hardest part of building a GUI. And up to this point, the Java platform has been aimed at developers, most of whom couldn’t “find” a design if it landed on their MacBook Pro. So we have to provide a paradigm in Java which enables designers and developers to work more seamlessly in constructing beautiful applications. We believe that JavaFX script, in conjunction with existing designer tools (Photoshop, Illustrator, etc) and development tools tailored for building GUIs, is how we’ll get there.

It’s really different from Java and THIS IS A GOOD THING. For defining visually rich user interfaces, it has some major advantages over Java:

• declarative syntax (without XML; no offense to the XML community, as XML has its place, but its verbosity is simply noise in a hierarchical GUI description)
• first-class functions for callbacks (no more writing of anonymous inner classes — the JFX compiler handles those gory details)
• expression-based binding (this is the power drill for GUI development; once you use it, going back to the hand drill is painful)

I’ll confess that I didn’t want to like it at first (felt a little like I was cheating on Java), but after I got over the hump of learning to declare what I wanted, rather than coding procedurally, it became quite addictive, especially binding. But don’t take my word for it; try it out yourself before you render an opinion.

The argument against the scripting languages is that they are slow (meaning, their run time on the computer is slow), but I think Matz (I mean Yukihiro Matsumoto) summed up my feelings on that subject when he said:

In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don’t care about runtime efficiency. The computer goes faster and faster every year, so I don’t really care about performance. Actually, I care about performance when I’m implementing the Ruby interpreter, but not when I’m designing Ruby. The implementer should care about performance, but the designer shouldn’t. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn’t focus on performance in design.