Since I started listening to Alan Kay’s ideas I’ve kept hearing him use the phrase “air guitar” to describe what he sees as shallow ideas, both in terms of educational and industry practice, which are promoted by a pop culture. Kay is a musician, among other things, so I can see where he’d come up with this term. My impression is he’s referring to an almost exclusive focus on technique, perhaps even using a tool, looking confident and stylish while doing it, and an almost total lack of focus on what is being worked with.

I watched video recently of another one of his presentations on Squeak, this time in front of an audience of educators. He brought up the issues of math and science education, and said that in many environments they teach kids to calculate, to do “math”, not mathemetics. Students are essentially trained to “appreciate” math, but not in how to be real mathematicians.

He’s also used the term “gestures” to characterize this shallowness. In the field of software development he alluded to this idea in his 1997 keynote speech at OOPSLA, titled, “The Computer Revolution Hasn’t Happened Yet”:

I think the main thing about doing OOP work, or any kind of programming work, is that there has to be some exquisite blend between beauty and practicality. There’s no reason to sacrifice either one of those, and people who are willing to sacrifice either one of those I don’t think really get what computing is all about. It’s like saying I have really great ideas for paintings, but I’m just going to use a brush, but no paint. You know, so my ideas will be represented by the gestures I make over the paper; and don’t tell any 20th century artists that, or they might decide to make a videotape of them doing that and put it in a museum.

I’ve been surprised when I’ve seen some piece of media come along that comes pretty darn close to illustrating one of Kay’s ideas. A while back I found a video clip of a Norwegian comedy show taking the learning curve of today’s novice computer users and making a media analogy to the “introduction of the book” after Gutenburg brought the printing press to Europe in the Middle Ages. Kay had always said that personal computers are a new form of media, and I thought this skit got the message across in a way that most people could understand, at least from having experienced the version of “personal computer media” that you can buy at a retail outlet or through mail order.

South Park is a show that’s been a favorite of mine for many years. It’s an odd mix of “pop culture with a message”. Despite the fact that it’s low brow and often offensive, on a few occasions it has been surprisingly poetic about real issues in our society. The show is about a group of kids going through life, misunderstanding things, playing pranks on each other, and getting in trouble. It also shows them trying to be powerful, trying to help, and trying to learn. Maybe that’s what interests me about it. It’s unclear what “grade level” the kids are at. There was one season where they were in “4th grade”. So I guess that gives you an idea.

I’ve included some clips of an episode I’ll talk about. The clips are from Comedy Central’s site. Fair warning: If you are easily offended, I would not encourage you to watch. There is some language in the video that could offend.

Season 11, episode 13 is one where the kids buy a console video game system and play a game on it called “Guitar Hero”. The game is played by taking game controllers that look like small electric guitars, and manipulating switches and buttons on them in the right sequence and timing, to real music played by the game console.

What I’m going to say about it is my own interpretation, based on my own life experience.

What’s interesting to me is a parent of one of the kids tries to engage the group in learning how to play real music on a real instrument, but the kids are not interested. The dad wonders what’s so special about the game, and that night sneaks down and tries it himself, showing what a bad fit a real musician is in this “air guitar” culture (or showing what a piece of crap it is).

Clip 1:

I have the feeling this episode is based on a movie, though I don’t know which one. There are other parts not shown in these clips that dramatize betrayal between two friends, and reconciliation. Kind of your typical “buddy movie” plot line. This next clip shows the “wider world” discovering the talent of these kids playing the game.

Clip 2:

This gets to what I think the pop culture promotes. Even though it’s pretty empty, it makes you feel like you are accomplishing something, and getting something out of it. You are rewarded for “going through the motions”, “making the right gestures”. I like that the show deliberately tries to make the importance placed around the game look silly.

If this next clip doesn’t scream “air guitar”, I don’t know what does.

Clip 3:

I won’t show the ending (you can watch the full episode on Comedy Central’s web site, if you like), but it shows how utterly empty and worthless the whole “air guitar” exercise is–It’s not real!

I think the reason this episode had some meaning for me is what plays out feels kind of like my past experience as a software developer. Not that software development is an “air guitar” exercise in and of itself. Far from it. What I’m getting at is the wider computing culture with respect to software development is like this. Those of us who care about our craft are trying to play “good music”, often with bad instruments. In my case, I’m still learning what “good music” is. We may be with a good “band”, but most “bands” have “band managers” who don’t know a thing about “good music”. That’s why it seems like such a struggle.

“Real music” with good instruments in computing is available for those who seek it. You won’t find it in most programming languages, programming web sites, symposia, or tools. The idea of “good music” with “good instruments” doesn’t get much support, so it’s hard to find. Unfortunately the reality is in order to really be educated you have to seek out a real education. Just “going along for the ride” of school systems will usually leave you thinking the pop culture is the real thing. Seeking a real education, being your own learner, is much more rewarding.

Paul Murphy saw fit to give me another guest spot on his blog, called “The tattered history of OOP”, talking about the history of OOP practice, where the idea came from, and how industry has implemented it. If you’ve been reading my blog this will probably be review. I’m just spreading the message a little wider.

Paul has an interesting take on the subject. He thinks OOP is a failure in practice because with the way it’s been implemented it’s just another way to make procedure calls. I agree with him for the most part. He’s informed me that he’s going to put up another post soon that gets further into why he thinks OOP is a failure. I’ll update this post when that’s available.

In short, where I’m coming from is that OOP, in the original vision that was created at Xerox PARC, still has promise. The current implementation that most developers use has architectural problems that the PARC version did not, and it still promotes a mode of thinking that’s compatible with procedural programming.

Update 6/3/08: Paul Murphy’s response to my article is now up, called “Oddball thinking about OOP”. He argues that OOP is a failure because it’s an idea that was incompatible with digital computing to begin with, and is better suited to analog computing. I disagree that this is the reason for its failure, but to each their own.

I know this is going to be old news to some people. I first heard of this through PBS in 2006. I just got inspired to write about it now.

Sting, with Edin Karamazov, created a wonderful collaboration, bringing back to life the 400 year-old music of John Dowland. Sting and Edin, both playing lutes, and Sting with his smooth vocals, created an album from Dowland’s pieces, which were made widely available to people in his day. The music has a richness that is wonderful to listen to. The DVD is even better. The locales they play in bring a greater fullness to the whole thing. In addition there are some vignettes where Sting, Edin, and a couple of experts on Dowland discuss the music and his life. Through this you get a small taste of the culture he lived in.

What’s really gratifying is seeing the growth of an artist. Sting is best known for the pop music he created with The Police, and then in his own solo career. The CD contains none of that. Instead what you hear is Sting and Edin really making an effort to bring life back to these old songs, respecting the tradition they came from. The DVD has a little of Sting’s pop music thrown in as well. A few of the selections they put on the DVD are Sting “unplugged” with the lute.

I should add that if you saw the PBS program on this you’ve already seen most of what’s on the DVD. It contains some extras not seen on TV, like the full length concert that Sting and Edin put on, and a rehearsal session.

Overall it’s a wonderful collection if you enjoy quality music with rich themes. I highly recommend it.

A while back I wrote my “Reminiscing” series of posts talking about the history of the machines I used growing up, as I remembered it. I came upon a few materials on reddit over a period of about a month that gave more authoritative histories of the Atari ST and Amiga. They’re really neat to look at. Atari and Commodore were fierce competitors since they both got into the computer market in the late 1970s, up until they both stopped computer production in 1993/94. There were the same flamewars during those years about which computer was better between devoted camps as there are now about which operating system, or system of software development (open source vs. closed source) is better. That competitive, beat your opponent to a pulp spirit still lives on.

The Atari ST 

The Atari ST, from Wikipedia.org

Landon Dyer has a blog called DadHacker. He’s written a two-part series on the building of the Atari ST, as an on-the-ground engineer. He gives a kind of blow-by-blow of what he could recall of the events of the time, and the issues they dealt with in developing it in a very short time period. Here are part 1 and part 2.

When I was getting my undergraduate CS degree at Colorado State University one of my dormmates, Darryl May, had worked at Atari under the Tramiel “regime” before coming to school. As I recall he had done customer support, among other things. He was not high up on the totem pole, and so was not privy to a lot of the stuff that was going on, but he told me a few stories.

The higher-ups in the company hierarchy were not entirely sealed off from everyone else. He said there were a few times where he just happened to bump into Jack Tramiel in the men’s bathroom.

Another story was that there were framed pictures put in odd places on some of the walls. He said they were where Jack Tramiel had caused a ”dent” by punching them with his fist–just releasing stress…

I used to really like Atari computers, 8-bit and ST, and one of the aspirations I had was to maybe work at Atari one day. After hearing this, and maybe a few other tales I can’t remember, I lost interest. I didn’t conflate this with the machines themselves. I still liked them, and I have fond memories of them to this day. It’s just that the company culture didn’t sound so hot, and I began to see why there was such a love/hate relationship with Atari back then among the devoted.

In 1993 I had the opportunity to attend a Falcon 030 presentation given by David Small, the inventor of the Magic Sac and Spectre GCR/128 Macintosh emulators for the ST. The Falcon had started to ship a short while before. As I recall, and my memory’s fuzzy on this, he told a tale of how the Falcon development team was treated. One of the things I remember him saying is after promising to pay the engineers for their efforts, rather than paying them in cash, they were given company stock…which at the time was probably trading as a penny stock. I remember it hovered around $1 a share, often going under that amount, with really no hope of it getting any better. Small winced as he delivered the punch line, and drew audible sounds of disgust from the audience. We all knew what the situation was with Atari.

The impression I’ve gotten from listening to first hand accounts is that Jack Tramiel was a “penny wise, pound foolish” hard ass. I don’t get a sense that he had a creative spirit. His strategy, as it was when he was at the helm at Commodore, was to sell machines to a mass market. For whatever reason, it worked out for several years in Europe, where Atari was one of the dominant sellers of computers. In the U.S. it didn’t work out. I remember asking Darryl about this, and in his view Atari was just a tax write-off for the Tramiels. Jack Tramiel was set to retire, and just didn’t have the motivation to really make Atari do well. That was his theory anyway.

Giving credit where it’s due, in an interview I saw on a British computer TV show from the 1980s, Jack Tramiel revealed that one of his goals when he ran Commodore was to keep the Japanese out of the U.S. PC market. He did this by undercutting them on price. Maybe he succeeded, since I remember there was talk in the 80s about the Japanese working on low-end MSX machines to sell to the U.S. market. Somehow that never got off the ground. Incidentally, MSX was Microsoft’s attempt to do for low-end 8-bit computers what it did for IBM PCs and clones: create a standard OS. Apparently he was someone who fought to keep computer production in the U.S. We can thank him for that, though in hindsight he just delayed the inevitable. From what I remember, Atari shifted computer production to Asia, even under Tramiel’s management. Today a lot of the PC production lines are in Asia, though I’m sure there are still some here.

As I’ve mentioned before, Atari stopped producing computers in late 1993. The company continued on, trying to compete in the video game market, but dying a slow death, until it was finally “retired” in the sale to JTS, in 1996.

The Amiga

The Commodore Amiga, from Wikipedia.org

I found a couple videos that cover the history of the Amiga. What’s intriguing to me is there are some juicy tidbits about what went down between Amiga Corp. and Atari. This was something I had read about, but never completely understood.

Amiga started out as its own company developing video game peripherals. As I recall, and parts of this may be wrong, at some point Atari started giving funding to Amiga, back when Atari was owned by Warner Communications (now called Time Warner), and expected to get first dibs on some technology that was being developed (maybe the chips). There came a point where Amiga was running low on cash, and put itself up for sale. Amiga wasn’t satisfied with the way they were being treated by Atari. Commodore appeared to be interested. Amiga pursued a deal with Commodore, and eventually reached an amicable price per share with them. I’m not clear if the Tramiels were in on the negotiations with Amiga. From what I read it sounded like the deal with Commodore was either near completion when Jack Tramiel bought Atari, or it was already overwith. They tell the story in the video so I’ll leave the details to them, though they don’t talk about who was in charge at Atari.

Commodore bought Amiga, and Atari’s working relationship with them went out the window. Atari sued, citing their agreement, but ultimately lost. The Amiga computer went to Commodore. As I recall the Tramiels already had some ideas about a 16-bit machine they wanted to develop by the time they bought Atari, but they had to work fast to get it out in time to compete with the Amiga.

From what I read one of the main players at Amiga was Jay Miner, though according to the video below he was the head guy. He used to work at Atari, and developed the graphics chips for their 8-bit computers in the late ’70s. Maybe he did more than that, but I don’t recall. He brought the same know-how to the Amiga computer project, creating the famous graphics (and sound?) co-processors that gave the Amiga real pizzaz.

The video below is the story of the founding of Amiga Corp., and the purchase of Amiga by Commodore, as told by the original guys and gals who made it all happen.

Another neat thing about this video is they show the CES mock up of the Amiga Lorraine (its code name) that I remember reading about in Compute! Magazine back in 1984. I remember they told the story of the Amiga’s appearance at CES with a great sense of foreboding that the machine looked revolutionary, and if it became anything more than vaporware it would represent a next generation leap in computing. This is interesting in retrospect, because Compute! did not greet the Apple Macintosh, which was a final product ready for sale at the time, with the same sense of excitement. They covered the unveiling of the first Mac, but then they were like “on to the next subject…”.

You have to remember that back then what was considered “standard” was a computer that when you booted it up would greet you with a command line interface, and the only machines most people knew about that had high resolution graphics combined with a “large” color palette were the IBM PC and the Apple II.

I would say that all three, the Apple Mac, Atari ST, and the Commodore Amiga represented the next generation of popular computing at the time. Each came at it from a different angle, and none of them turned out the way their visionary creators anticipated. All three pursued the business computing market, thinking it would help establish the machines with a healthy customer base, but none of them made large inroads in it. Instead each found a following in creative businesses. The Mac was adopted for professional (paper) publishing. The Atari ST was adopted by musicians for its MIDI hardware and software. The Amiga was adopted by video production studios since its hardware capabilities fit in well with what they needed. Video production software followed suit.

A show I heard about during my last year in college (’92-’93) that used Amigas with Video Toaster cards for the special effects shots was Babylon 5. It’s the reason why I got interested in it in the first place. But wow, the storywriting in the series held my attention. It told a tale of epic proportions. They only used Amigas for the first season though. Here’s some video of the intro’s for the show for the 5 seasons, where you can see glimpses of the Amiga/Video Toasters strutting their stuff. The last part is the closing credits of the series finale. What a great series it was.

I heard that Amiga/Video Toasters were used for the effects shots in the SeaQuest DSV series as well.

I can’t help it…Diversion into trivia: Two actors in the Babylon 5 TV series also starred in the movie Tron. What were the actors’ names, and what characters did they play in the movie? They’re both in this fan video. See if you can find them. One of them is pretty easy to pick out.

Here’s a video of an Amiga production plant being shut down in 1994, when Commodore shut its doors for good. Not much to see here. Pretty boring, but it gives you that sense that things are coming to an end. 

Update 5/30/08: I found this video of a 25th anniversary commemoration of the Commodore 64, presented by the Computer History Museum. Finally the C-64 gets its due. It was really kind of a get together of some people who defined personal computing in the 1980s. At first was just a one-on-one chat with Jack Tramiel. Later they brought up Steve Wozniak (representing Apple), a guy who used to work for IBM during the IBM PC days, and another guy who worked for Commodore. They reflect a bit on what happened at Apple and IBM at the time as well. Interesting discussion.

On a lighter note, a reminder (video link) of how far we’ve come since then.

I’m now back home after a long trip (though my busy-ness has not ended), and I noticed that my local CompUSA store, as far as I can tell, is still here.

This is old news, but I happened to look for information on the fate of CompUSA, and I found an article saying that the store chain was bought in January by TigerDirect, a subsidiary of Systemax. Only 16 of the existing stores were to remain open. TigerDirect also decided to change the name of its stores to CompUSA.

I signed up to get ad e-mailings from CompUSA several years ago. I’ve been using them to kind of keep an eye on them. Lately I’ve been getting ad mailings from them labeled “The new CompUSA.com”. So something’s changed there, though I haven’t had time to see what that is. So its declared demise on my part is premature. It’s just been significantly scaled back.

CompUSA may end up like Egghead Software. Remember that store chain? I really liked the store, but Egghead closed its retail outlets in the late 1990s, and decided to just run an e-commerce site to sell wares. I’m not sure what brought them down. For a long time I thought it was CompUSA since Egghead closed its outlet in town close to the time when CompUSA arrived.

Anyway, I’m glad it’s not going away for good. I still have store credit with them, and I’d hate to lose it.

I’ve been extremely busy lately and so haven’t had time to post as much as I’d like. I saw this video a little while back, and I thought, “Okay, cute.” Over time it’s grown on me, so I thought I’d share it with you all.

“An Engineer’s Guide to Cats”

There’s something about this video that when I watch it I have to say, “Hmm. This sounds like me,” except I haven’t been a cat owner in years. My apartment doesn’t allow pets. But I love cats. So this is an easy video to love. One part in it says, “Like most engineers, cats are pretty much willing to eat the same thing day, after day, after day,” and then follow it up with a little part where they’re making toast. This is so me. I eat a fairly restricted diet in the sense that I don’t mind eating the same selection of stuff for quite a while before I get bored with it and move on to something else.

I loved the “feline art” section of this video. The “post-modern cardboard deconstruction” bit is hilarious! The “corporal cuddling” part was precious. Awww, so cute! Makes me feel all warm and fuzzy inside.

The part about the “I’m-not-paying-any-attention-to-you game” was interesting, because I’ve “played” that game with women (but gosh, I didn’t know it had a name…). From my experience it doesn’t work out like in the video. If you play this game, the gal wins by default, because you’re just too uninteresting.

BTW, I found this video shortly after “An Engineer’s Guide”, and it’s pretty cool too. For an amateur he’s quite a performer and songwriter I’d say.

“The Mean Kitty Song”

I found this through The Weekly Squeak. Randal Schwartz demo’d the current Squeakland version of Squeak/EToys on Leo Laporte’s show, “The Lab” (video link). I just think it’s neat it’s getting some mainstream recognition.

Schwartz and Laporte gave a quick history of Smalltalk at the start, and they told it pretty accurately. For the uninitiated it may go by too quickly. Squeak’s heritage goes back to the Xerox PARC days of the 1970s, back when they were developing Smalltalk. Smalltalk was the system they developed to create an interactive computing environment for children. It was the first implementation of Alan Kay’s vision of a “computer as medium”. This is the system Steve Jobs saw that inspired Apple to create the Macintosh. Smalltalk is still used today in large firms, particularly major banks. Interesting how a system developed for kids would be put to such a serious use, eh? Well, that was the idea, though as Kay has said with a little regret about Smalltalk’s history, the kids were shoved to the side, and the “professionals” took it as their own. Schwartz said Smalltalk is used wherever you need to rapidly create or change “products or screens”. I take that to mean “software”, but who knows. If so, isn’t that what a lot of businesses need? I mean, what’s RAD all about if not this?

Just a quick note. Laporte said something that’s untrue. He said that the mouse was invented at PARC. It wasn’t. Douglas Engelbart invented the mouse before PARC was created. The Xerox team used it with the Alto computer and Smalltalk. Laporte was basically right when he said that the graphical user interface as we now know it, with mouse interaction, was invented in the Smalltalk system at PARC. More than that, the language used in it, also called Smalltalk, was the first well designed OO language. Other teams at PARC worked on such things as networking machines together using ethernet, exchanging e-mail, creating WYSIWYG displays, and laser printing, bringing it all together with what the Smalltalk team created. They really did create the future.

Schwartz and Laporte briefly talked about commercial Smalltalk environments, and how they’re still sold. Laporte added that it’s “expensive”. Somehow I wonder if that’s more perception than reality. What they don’t say is that Squeak at its heart is the same thing, and it’s free. They leave that for the audience to figure out.

What Schwartz shows is the version of Squeak that’s shipped on the XO Laptop. This version is the current one available from Squeakland. You can get it for Windows, Mac OS (7.6 or higher, and OS X), and Linux.

There are two editions of Squeak. There’s what I think is commonly called the “Squeakland version”, and then there’s the “Squeak.org version”. Squeakland is the one typically used for educational purposes. The Squeak.org version is the one typically used by professional developers, like those using the Seaside web framework. The main difference I think is in how they’re configured, what APIs are included, and how the main visual environment is set up.

What Schwartz shows is a typical EToys demo: “driving the car”. The first time most people see this demo they’re amazed, because they’ve never seen software run like this before. That was my reaction when I first saw Alan Kay do it at ETech 2003 (video link). Without running an app., Schwartz starts a project, grabs a brush from a “paint” panel, and selects a color. He draws a red car (top view) on the screen, just freehand. He then shows how it can be manipulated, and how it can be made to move by itself, just by a few mouse actions. Then, for the coup de grace, he draws a “steering wheel”, and links it to the car’s motion instructions, again using mouse actions, without stopping the car or any running program. It all happens in real time. He rotates the wheel and now he’s steering the car as it moves, all within the span of about a minute!

Smalltalk programmers have known this way of programming for years. It’s interactive. You’re able to change your code while it’s running. What’s cool about this is that through this model children can learn about programming with objects without it getting too hard, and it’s similar to the experience Smalltalkers get with the underlying environment.

With EToys it’s very easy to create objects. You just draw them on the screen. Each object also has a standard set of properties and behaviors that can be manipulated. More can be added by writing scripts, which involves writing a little Smalltalk code. There are some differences between programming in EToys and the underlying Smalltalk environment, which I won’t go into, but it’s okay. The way EToys does things reduces the complexity. The idea was to invite kids in, not to scare them away by making it too complicated. It introduces the idea that programs are simulations of models. The model is the interaction of objects–their relationships to each other. Each object is designed by the programmer to carry out certain behaviors in response to messages. What I think makes people excited when they see this is they realize that they can take what’s in their imagination and see it play out before them on the screen. That was always a joy for me as a teenager, though getting to that point, using the technologies I had available to me was sometimes a tough road.

EToys brings Smalltalk back to the vision that Alan Kay wanted for it all along, a computing environment that can be used by ”kids of all ages”. EToys provides an easy to use and program simulation environment. It’s fun for adults, too, though I don’t think it’s complete enough for all the things adults would want to do with a computer. For that, there’s the underlying Smalltalk system, which provides a powerful environment in which they can create their own programs/systems. Together it comes pretty close to Kay’s original Dynabook vision.

—Mark Miller, http://tekkie.wordpress.com

The 2nd edition of Squeak by Example is out now (h/t to The Weekly Squeak for this). Like the first edition, it’s a book released as a PDF under the Creative Commons Share-Alike license. You can also get a hardcopy edition of it for $20.10 USD. They also welcome donations. Another tidbit of news is that the first edition was downloaded 20,000 times. Cool!

I wrote about the first edition here, along with links to tutorials that I thought readers would find useful after perusing it and learning some basics.

Hi guys. Just FYI, a little more than a week ago I wrote a comment on one of Paul Murphy’s blog postings, called “The worst PC myth of all”. Murphy is a blogger on ZDNet. He liked my comment a lot, and he and I agreed to have it as a guest post on his blog, called “Managing L’Unix”. I changed it a bit for posting, but the message is the same. It showed up today, titled “The PC vision was lost from the get-go”.

Paul Murphy sees himself as an “agent of change” in IT systems, so he tends to talk mostly about his philosophy of infrastructure, and his own attempts at reforming it in businesses. I read his blog often, because I have gotten insights from him in the past, especially when he talks occasionally about software development/programming issues. In fact, one of his posts from a couple years ago inspired me to search for material on the internet related to something he talked about. This led to a feast of information, knowledge, and wisdom, which I have continued to explore and enjoy to this day.

—Mark Miller, http://tekkie.wordpress.com

Joshua Bloch, Chief Java Architect at Google, gave a talk entitled “The Closures Controversy” at Javapolis in December 2007. I found it online through reddit, and it intrigued me, because I think it illustrates a disconnect between what we as an industry are doing and the goals we have. Bloch also makes what I think is a reasonable argument for limiting Java.

Those of you who’ve read what I’ve written for a while might be surprised by that statement. I have been critical of the IT industry for not thinking in more powerful terms about programming/computing. I am not endorsing Java. After watching his talk I was prepared to lay into Bloch for not having higher ambitions for the language, but as I thought about it I realized that it’s unreasonable to expect a computing environment to be more than what it was designed for. It helps me see that Java has a shelf life. To expect more would mean trying to change it into something it’s not.

The appeal of Java

Bloch began his talk using Gosling’s ideas from his article The Feel of Java, published in IEEE Computer in 1997, as a touchstone for what Java ought to be like in the future:

It is a language for a job. Doing language research was an anti-goal [in the development of Java] . . . It is practical, not theoretical. It’s driven by what people need. Theory provides rigour, cleanliness, and cohesiveness. [Java had] no new ideas. It took ideas from existing languages and put them together. It maybe added a few new things, but that wasn’t the goal. And this is perhaps the most important slide in the whole talk. He said, ‘Don’t fix it until it chafes’, to keep it simple. Don’t put anything in the language just because it’s nice. Require several real instances before including any feature. In other words, ‘Just Say No, until threatened with bodily harm.’ He said Java feels hyped, playful, flexible, deterministic, non-threatening, and rich, and like I can just code.

Bloch continued from the article:

Java is a blue collar language. It’s not a PhD thesis. It’s a language for a job. Java feels familiar to many different programmers, because we preferred tried and tested things.

When Gosling said Java is “not theoretical”, he was comparing it to languages/VMs that are based on computer science theory, like Lisp, which is based on lambda calculus. By “practical” he meant the instrumentalist approach to design, which is that the feature set and the architecture the language/VM supports should handle current problems. Nothing more, nothing less. In my view this is short-sighted. It means that after acquiring and using the language to solve current problems you will run into problems the language wasn’t designed to handle, because new challenges arise. You will have to improvize within a structure that is ill-suited to the task, until whoever is in charge of the language adds new structures that handle the problem effectively. Wash, rinse, repeat. I have a feeling that this approach is a defense against languages whose designers add features willy-nilly without consideration for how it fits into the overall goal of the platform. Bloch points out that “theoretical” languages don’t have this problem, but he passes by it quickly.

Java was a swing in the other direction from languages like C/C++ that were said to “give you more than enough rope to hang yourself with”. I guess programmers “hung themselves” more often than not. C and C++ are powerful in the sense of allowing you to access the hardware directly inside of a language that gives you high-level structures. If you’re interested in doing anything more than building kernels, device drivers, or VMs/compilers, they’re pretty weak. Java rode a wave that was happening at the time it was introduced. C and C++ were the dominant languages. All sorts of projects were done in them, including applications. Java provided a productivity boost to project groups with this orientation by getting rid of many of the pitfalls of using C/C++ (buffer overruns, memory leaks, null or uninitialized pointer references, etc.), but in terms of building more abstract software like applications/environments with the power the language and the VM gave you, it wasn’t that different from C/C++. So in essence it played to the tastes of programmers of the time. It went for familiarity, but without having a particularly good technical reason for it. Java doesn’t allow direct access to the hardware. So why did the language designers feel it necessary to play “follow the leader” with C/C++ in terms of conventions and power? It was an easier sell to programmers. They like familiarity.

Java meets the programming culture where it is. As long as the culture is ignorant of the fact that the architecture it’s using is ill-suited to the task at hand, then technologists can convince themselves and others that problems which arise from using a limited architecture for large projects just go with the territory, and there’s nothing anyone can do about it. It’s about time we became more enlightened, but it’s going to take us admitting that despite our masterful technical skills we don’t know very much about why it is we do the things we do with computers, beyond the joy of solving puzzles. According to Alan Kay, and I think he’s right about this, it will take learning about and exposing ourselves to other things besides computers.

Quoting Kay, from The Early History of Smalltalk:

Should we even try to teach programming? I have met hundreds of programmers in the last 30 years and can see no discernible influence of programming on their general ability to think well or to take an enlightened stance on human knowledge. If anything, the opposite is true. Expert knowledge often remains rooted in the environments in which it was first learned–and most metaphorical extensions result in misleading analogies. A remarkable number of artists, scientists, philosophers are quite dull outside of their specialty (and one suspects within it as well). The first siren’s song we need to be wary of is the one that promises a connection between an interesting pursuit and interesting thoughts. The music is not in the piano, and it is possible to graduate Julliard without finding or feeling it.

I have also met a few people for whom computing provides an important new mataphor for thinking about human knowledge and reach. But something else was needed besides computing for enlightenment to happen.

Tools provide a path, a context, and almost an excuse for developing enlightenment, but no tool ever contained it or can dispense it.

The state of Java today

Bloch’s introduction felt like cheerleading for Gosling’s vision for Java, but then he got into what’s painful about it now. He talked about the Java community’s involvement in the design of Java, and the wisdom of its actions. “How are we doing today?”, Bloch asked the audience. He showed several examples of messy Java generics. It didn’t look that different from C++. The audience laughed. He said, “Not so well, unfortunately. This is how Java looks now.”

The way he described things made it sound like Sun “jumped the shark” with generics. He was more polite than to say this. He said generics per se were not a bad addition to the language, but their implementation allowed so much freedom that Java code is becoming incomprehensible even to people who have been working with the language for years.

Generics: An escape hatch

In my view generics are just an attempt to get out from under the limitations of Java’s strict type system. The same goes for generics in .Net.

Generics are the “managed code” world’s version of C++ templates. They are also called “parameterized types”. They give you some of the programming flexibility of a dynamic language. Statically typed versions of generic code get generated depending on what types are called for in statically typed code. What they don’t give you is the “get to the point” feel of programming in a powerful dynamic language, because you have to tell the compiler about how many types the generic code will accept, and in what form it will accept them, where type information needs to go in the generic code, and what form type information will take when data is returned from the routines you write. In other words, you have to give some metadata for your code so that the static type system can deal with it. I call it “overhead”, but that’s just me. What static type systems force you to do is talk about the data flow of your code. This isn’t so that humans can understand it (though with some discipline it’s possible to create readable code this way), but so that the compiler and runtime don’t have to figure out what the data flow will be when your code is executed. It’s really a form of optimization.

Bloch explored where the complexity that now bedevils Java comes from. He got into talking about feature creep. It’s not the number of features, it’s the permutations of feature interactions. “When you add a feature to an already rich language, you vastly increase its complexity,” he said.

The “quagmire” of closures

First, let me get a definition out of the way. A closure can be thought of as an anonymous function. It is not officially a method in any class. You can spontaneously create closures inline in your code and use them, in dynamic languages. You can pass them around from method to method, and they never lose their integrity. In the context of OOP it’s more aptly defined as an anonymous class that contains a single anonymous function, because in OOP languages closures are objects with methods of their own.

Bloch gave a brief explanation, which I think is correct: closures “enclose their environment”. They create references to whatever variables are used within them that are in scope range, at the time they are created. This is called “lexical scoping”. They also automatically return the value of whatever is the last expression evaluated within them. Bloch gives two reasons why closures are being considered for Java:

• They facilitate fine-grained concurrency in fork-join frameworks. You can use anonymous classes with these frameworks, but they’re a pain right now. He said it’s important that programmers use fork-join frameworks because, “we have these multi-core machines, and in order to actually make use of these cores, we’re going to have to start using these parallel programming frameworks.”
• Resource management - Always using try-finally blocks for resource management is painful and causes resource leaks, because programmers misapply the construct. Closures would help with this.

Even though he conceded these points, he clearly has disdain for closures. He used BGGA closures as his example. With the way they’ve been implemented, I’d have disdain for them, too. The hoops you have to jump through to make them work makes me glad I’m not using this implementation.

He said closures encourage an “exotic form of programming”, which is the use of higher-order functions: functions that take functions as parameters, and/or return functions. He jabs, “If you give someone a new toy, then they’ll play with it.” Ah, so higher-order functions are a “toy”. Mm-hmm… I’m tempted to say something impolite, but I won’t.

Bloch talked about closure semantics next, and how they’re different from normal Java semantics. He expressed concern throughout the rest of his talk that this would confuse Java programmers, and thereby create bugs. He has a point. Still, I don’t mind the idea of mixing computing models in a single environment (VM). I think there are advantages to this approach.

Some history: Where modern computing comes from

Code blocks (closures) in Squeak/Smalltalk work differently than normal Smalltalk code as well.

I’d venture to say that the reason closures have been put in Ruby, and are now being considered for Java, is that Smalltalk was the first OO language to use them. Even though I’m sure it’s largely forgotten now, there are some significant artifacts of computing that have come into common use because of the Smalltalk-80 system. The GUI you’re using now, “hibernation” on your PC, bit-blitting, and the MVC design pattern are a few other examples. Language and system designers have been mining Smalltalk features for years, and incorporating them into modern, though less powerful technologies.

In retrospect people within the Smalltalk community have pointed to some design flaws in it. They didn’t ruin it by any means, but it’s recognized that there’s room for improvement. In a conversation I was in on between Alan Kay and Bill Kerr, a blogger I’ve mentioned previously, Kay expressed muted regret about the inclusion of closures in Smalltalk, saying they broke the semantic simplicity of the language. I can see where he’s coming from. Closures introduce an element of functional programming into OOP. He desired a system that was purely OO, mainly for consistency so the language would be easier for beginners to learn. I haven’t gotten far enough along in my research to see what Kay would’ve suggested instead of closures. My understanding is he was heavily involved with the development of Smalltalk up until Smalltalk-76. Due to a schism that developed in the Smalltalk team, he gave up most of his involvement in it by the time Smalltalk-80 was in development. This is the version that ultimately was released to the public. “The professionals”, as Kay put it, took over and so some of the vision was lost. They turned the Smalltalk language into something that was friendly to them, not beginners.

Closures are something that anyone new to a dynamic OO language has had to learn about. They’re pretty painless to use in Smalltalk, in my opinion. They’re easy to create. Contrast this with closures in Java. Bloch referenced a post written by blogger Mark Mahieu, where he got some of the examples. Here are a couple of them, with equivalents in Smalltalk for clarity.

Java example #1:                          

static <A1, A2, R> {A1 => {A2 => R}} curry({A1, A2 => R} fn) {
   return {A1 a1 => {A2 a2 => fn.invoke(a1, a2)}};
}                          

Smalltalk equivalent:                          

curry := [:fn | [:a1 | [:a2 | fn value: a1 value: a2]]]
                           

Java example #2:                          

static <A1, A2, A3, R> {A2, A3 => R}
      partial({A1, A2, A3 => R} fn, A1 a1) {
   return {A2 a2, A3 a3 => fn.invoke(a1, a2, a3)};
}                          

Smalltalk equivalent:                          

partial := [:fn :a1 |
            [:a2 :a3 |
             fn value: a1 value: a2 value: a3]]

This is what I meant about “hoops”. The type information you have to supply for the Java closures detracts from the clarity of the code. It’s clunky. That’s for sure.

I’m not going to say anything about these structures (”curry” and “partial”) right now. If readers would like, I can write a post just on them, explaining how they work, and how they can be useful.

Bloch’s proposal

Bloch put forward a proposal, that rather than adding closures to the language, at least in the near future, that Java designers instead focus on creating concise structures (ie. add features) that implicitly create anonymous classes, to eliminate the verbosity (I guess this was his answer to the challenge of concurrency), handle resource allocation, and critical sections for threading. Basically it sounded like he favored the stylistic approaches that Microsoft has taken with .Net, with some differences.

He rejected out of hand the idea of adding library-defined control structures to the language, something made possible by closures, because it will encourage dialects. Squeak has a lot of library-defined control structures. I think they work quite well. They don’t change the fundamental rules of the language. Instead they expand its “vocabulary”. That is, they expand upon what you can do using the language’s existing structures. I understand this is hard to imagine in the context of Java, because most programmers are used to the idea that control structures are invariants in the language. Bloch would probably feel uncomfortable with this concept, but ask yourself which language is getting more cumbersome and complicated as time passes?

I think there is a fundamental contradiction in goals between what Bloch says he prefers about Java, and the growing problems of computing. He says that adding features to a language increases its complexity, and he makes a good case for that. Yet, how is Java going to solve new problems in the future? His answer is to add more features to the language. Granted they’re focused, and not open-ended to allow further expansion, but they’re still feature additions all the same. As is illustrated by Squeak, library-defined structures would actually help reduce the number of features in the language. Even though Squeak can do more things concisely than Java can, the feature set of the language is very small. As a point of comparison, Lisp’s language feature set is even smaller, yet it’s more capable of handling complex problems than Java. They accomplish this by taking what Java does as a built-in feature, and use message-passing (Squeak), closures (Squeak, Lisp, others), an extensive meta system (Squeak, Lisp, others), named functions (Lisp, Scheme), and macros (Lisp) instead.

Where Java sits

I agree with Bloch that if the intention of Java was to be a language that is “practical” (ie. is designed from the standpoint of instrumental reasoning), easy enough to use so “you can just code”, and doesn’t strain the ability of Java programmers to understand their code, then generics should’ve been scaled back, closures shouldn’t be added, and his suggestions for expansion should be considered. Unfortunately this also means that it’s going to get harder and harder to work with Java as time passes, because the demands placed on it will exceed its ability to deal with them. Maybe at that point people will pursue another “escape hatch”.

Struggling to transcend Java

I compliment the Java community on its efforts to build something better out of a limited platform. What some are trying out is the idea of a VM of VMs. That is, building a VM on top of the JVM. This creates a common computing environment that enables some interoperability between different computing models, while at the same time transcending some of the limitations of the JVM. From what I hear, it sounds like it’s been a struggle. Personally I think it would be wiser for the industry to start with something better–a “theoretical” language/VM–and then try to build on top of that. Our computing culture has a lot of resistance to this idea. Even the efforts of groups to build better language/VM architectures on top of the JVM seem to be regarded as curiosities by most practitioners. They get talked about, and get used by a relative few who recognize their power for real projects, but they’re ultimately dismissed by most developers as “impractical” for one reason or another.

It’s funny. Several years ago I talked with a friend about how slow Java was. His solution was to “throw more hardware at it” then. Some months back I told him about Groovy. He read up on it and dismissed it as too slow. Why not just “throw more hardware at it”? I didn’t hear that recommendation from him. I didn’t press the case for it, because I didn’t have a dog in the fight. I’m not part of the Java community. I figured if he didn’t want to pursue it, he either had a good reason for it, or it was just his loss. My inclination is to believe the latter. I guess by and large there’s not enough pain yet to motivate people to reach for something better.

—Mark Miller, http://tekkie.wordpress.com