Blue Sky On Mars

Bruce Eckel is recommending that the Java language should be declared “stable” and left as is, rather than grafting on features that don’t fit well (particularly in the face of maintaining backwards compatibility). See: Java: Evolutionary Dead End. I agree with Bruce. As long as a high-degree of backwards compatibility is required, adding language features to Java will be clumsy at best. ECMAScript has the same backwards compatibility with forward movement challenges, but the language is much more flexible at its base, so I think ES4 can be a more successful evolution than Java 5 was.

Something interesting in this discussion is a comment from Vincent O’Sullivan that echoes the Scala Will Do cartoon from a couple days back. The implication there is that people in software development are always just chasing after the next shiny thing to help them with their projects… and, since it’s a joke, the implication is that people shouldn’t do that.

Software is the stuff of thoughts. It’s very malleable and new ideas can be tested out fairly cheaply. With the internet, new ideas and code can spread far and wide quickly. This is all a good thing. For me, creating software today is tremendously better than it was 5, 10, 15, 20 years ago. I watch many of the shiny things go flying by, but I don’t actually use them. But I consider the shiny things to be very important. There are all kinds of ideas wrapped up in there that can be applied in different contexts and with different tools. Some of the implementations that come out of those ideas will make it into the mainstream.

Generally speaking, people don’t switch to all of the shiny things that fly by. Some people will give them an honest try and will either be rewarded for being a successful early adopter or will suffer some pain and head back to other solutions. If enough people like the idea and follow through, it will become mainstream. Rails was the shiny new thing in 2004. There were undoubtedly people who felt the pain of being early adopters, but many more were far more productive than people using other tools that were common back in those days. Regardless of how many people ultimately adopt Rails, the fact is that many of the ideas presented there have had a significant influence on work that has happened since.

Scala is a cool language. There are many other cool languages, but the reason Scala is getting talked about is because it is more than a toy and it’s something that people can apply today. Until Scala has the kind of IDE support that Java users are used to, I’d consider the people using it to be early adopters. Regardless of whether Scala enters the mainstream, it contains interesting ideas and it’s worth looking at. I actually rather doubt that Scala will become mainstream, because the gap between its syntax and what mainstream programmers find “familiar” is too large. Steve Yegge made a similar comment about Scheme.

My point in all of this is that the way we write software is always changing and is generally evolving for the better. Look back on how you’ve created software in the past, and I’m sure you’ll find that it’s better today. If not, you probably haven’t been looking at enough of the shiny things that have flown by.

Steve Yegge attracts some attention with Code’s Worst Enemy, in which he uses many, many words to say that “big, bloated software sucks to maintain”. He talks about a 500,000 line Java-based game that he wrote that is unmanageable. Though he’s railing against code bloat in general, he does rant a bit about Java in particular. I’ll come back to Java…

First off, I agree with the basic idea that having too much code to manage in a single conceptual unit (a program) makes life very difficult.

The first defense against this is good product management. Only add features if they’re good for the product as a whole. If you strip out a lot of fringe features, you can end up with a much leaner product that is both easier for you to maintain and easier for users to get into using. Scribbles brings this to mind. The app is focused on creating drawings and provides a UI that is completely streamlined to the task. I would guess that the code for Scribbles is not out of control, because it would be similarly focused.

The next thing to consider is that we all routinely write 1 million+ LOC programs. Consider this case:

#!/usr/bin/python

print "Hello, world"

Conceptually, programs don’t get much easier than that. But, running that program and seeing its output in a Terminal.app window on my Leopard-based Mac running Python 2.5 undoubtedly touches at least 100,000 lines of code. The trick is that I have faith that Python, Terminal and Leopard are all going to do their jobs (and those big guys have faith in the libraries they use), so that I can effectively ignore 99,999+ lines of code and just focus on the one.

There were a couple of commenters on Steve’s blog post that suggested that maybe rather than having a 500,000 line program what he really should have is a 10,000 line program and a bunch of libraries. In one sense, this is the compartmentalization that Steve complains about in his post. Libraries are one effective way of compartmentalizing code that has proven to be very successful over the years.

And language features are another way to segment code. That’s part of what the recent hubbub over domain specific languages is all about. Libraries can reduce how much you have to think about as you solve a problem, and DSLs can further reduce this.

Which brings me back to Java and Steve’s original point. We can focus on reducing the amount of code we manage by using libraries, and there is certainly plenty of that going on in Javaland. We can also add higher-level features to our languages. Doing so reduces the total lines of code required to solve a problem and the cognitive load required to maintain a program. Here’s an example:

import time

class Foo(object):
    @property
    def foo(self):
        return time.time()

Python’s attribute and property handling means that you don’t need to define random setters and getters all over the place. You just define them where you need them. Think about how many lines of code in Java are wasted on getters and setters that do nothing beyond the standard behavior, and how many times you have to type bar.getFoo() rather than just bar.foo. Yes, I know that Eclipse generates the getters and setters for you, but you still have to read through all of that muck when you’re trying to figure out what a program does.

In a nutshell:

• I agree that code bloat is a huge problem
• I’m sure that part of the blame for having 500,000 lines of code to manage single handedly rests with Steve… in choices he made about features to include, and in how he decided to decompose the problem.
• But I also agree that Java carries dramatically higher cognitive load than many other popular languages and one should really think about alternatives.

There’s now a multi-author Scala Blog that provides info about this very cool language. It sounds like there is a draft of a Scala book about ready, and the lift web framework hits 0.3. Scala and lift are tools to watch, because there is a lot of interesting background going into them. Anyone who has been eyeing Erlang’s concurrency features should check out Scala, because it gives you the same concurrency features but on top of the JVM with access to Java libraries when you need them.

The complete CodeMash Conference Session List is up now, and it looks like both of my talk proposals were accepted! I mentioned earlier that I’ll be giving an overview of the Dojo JavaScript Toolkit there. It turns out that I’ll also be giving a talk on Dojo Offline + Google Gears for taking your web applications on the road.

I’m an early riser, usually starting work around 7AM Eastern. Today is no exception, despite the fact that this is my first day at my new job. I was surprised to find Alex Russell online when I started up this morning, but this explains it all: Dojo 1.0 has been released. Dojo 1.0 is huge (and yet compact… 23K core!) and powerful. Congrats to everyone who worked on this release!

I’ll be speaking at CodeMash for the second year in a row. At CodeMash ‘07, I did an introduction to TurboGears.

At CodeMash ‘08, I’ll be doing an overview of the Dojo JavaScript toolkit. Dojo is a comprehensive and powerful package, so I’m going to do what I can to highlight nifty things the package can do. I’m going to work under the assumption that people who attend this talk understand JavaScript, but that’s really the only pre-req.

CodeMash ‘07 was a remarkably well run conference, given that this was the first year. It’s a great conference to show off technology like Dojo, because there is a very diverse audience. (That’s the whole point after all: bring people from different areas together… .NET, Java, Python, Ruby and JavaScript all in one conference!)

As I mentioned previously, the August meeting of the Michigan Python Users Group is a joint meeting with the Ann Arbor Computer Society at the Google office in Ann Arbor. I have just found out what our meeting topic is…

Russell Whitaker, a Google software engineer, will be talking about Test Driven Development in Python. I was test infected a long time ago and I’ll certainly be interested to see if Russell has some tricks I haven’t seen yet

If you’re new to TDD, this is sure to be a good meeting.

Update: Registration has closed… we’ve got a full house.

Google has just open sourced a new project; Google Gears. (Hmm… sounds like a good companion to another open source project…) Google Gears lets you design webapps that can be taken offline and provides an SQLite-based data store. The data store even includes the full text search engine that Google helped fund. They also add a worker thread pool for performing background tasks (notably, their threads do not share state… so it’s more like multiprocess programming than multithreaded programming).

Neat stuff, and one can certainly imagine how Google themselves might plan to put this to use.

In other news, Adobe Apollo will include SQLite, which is a move that I would have been shocked if they didn’t do. If people are serious about making applications that run on standalone desktops, having a real database for storage is a necessity, and SQLite is as small and nice as they come.

Update: Google has already enabled Google Reader to work offline. I’m not sure if Gmail is offline-capable or not, because I think Google went for the “modeless” route, where the user (me) has no idea if the app is running online or off…

David Pollack quotes Sandra Boynton in the title of this more-interesting-for-grownups post: Prance with the Horses, Skittr with the Mice. David has provided a more complete example of his lift web framework for Scala. This example shows why I’m paying attention to what’s going on with Scala and lift.

The generally accepted way to do scaling in the LAMP world is to go for “shared nothing” as much as possible and throw more boxes at the problem. But what if you could have a reasonable (and extensible) syntax that performs really well and neatly supports event-driven applications that handle enormous numbers of simultaneous users getting Comet-style updates?

David claims that a single dual-core machine could handle 1M simultaneous users in his little Skittr application. I would be surprised if there wasn’t something unexpected that falls over before then, but the real point is that a single box can handle many users because of the speed of Scala and the Actor-based concurrency.

Don’t get me wrong: premature optimization remains the root of all evil. But, this doesn’t look like a bad way to put together apps, which means that the zippy performance is just a bonus, not a premature optimization.

Nik Cubrilovic at TechCrunch has one of the best writeups I’ve seen about Microsoft’s Silverlight (formerly WPF/E): Silverlight: The Web Just Got Richer. Silverlight is gunning for Flash/Flex. Flash and Flex have some huge advantages: they’re fast, tiny and installed. The “installed” part is actually not that important, as far as end-user installation goes. Installing a plugin, especially on IE on Windows, is pretty easy. “Installed” is important, though, because there are many developers who are used to the Flash/Flex systems.

Flex is being open sourced, which will only help its adoption. Flash also runs on Linux, which Silverlight does not. Seriously, though, that may not matter yet. Linux desktop penetration is still quite small.

The big, new announcement about Silverlight is that it’s got a “mini-CLR”. A 4MB download gives Windows and Mac users the ability to run programs written in C#, Python, JavaScript and Ruby in their browsers. Granted 4MB is quite a bit larger than Flash, but if people start producing Silverlight apps/video sites, will that 4MB deter users? Unlikely, I’d say.

I’m still a fan of Flex, and I’m definitely a fan of the increasingly open approach that Adobe is taking. The competition here looks like it’s going to be pretty fierce, and that can only be a good thing for the users.

Update: I forgot to mention an important other point (sorry… this post is kind of rushed…) Something that I think is seriously in favor of Flash/Flex is that the development tools are cross platform. Macs have been big in design shops for a long time, and still are. And, many of the Mac OS X “switchers” over the past few years have been software developers (go to an open source development conference like PyCon and you’ll see what I mean). The fact that I can develop Flex applications on my Mac is a big deal. And I don’t have to settle for text editors and command line compilers. The Flex Builder IDE and the full Flash environment are both available for the Mac. This is not the case with Microsoft’s tools for Silverlight.