I saw Ruby the Rival via an article on Lambda the Ultimate, and of course it tickled my interest in the diffusion, rise, and decline of programming languages. The guys they picked to interview have pretty good commentary – I found it thoughtful and insightful.

Robert Cooper’s comments to the effect that you should do the easy things first and make the complex stuff available are spot on. Simple stuff has got to be simple in order for the language and its libraries and applications to scale down, and without scaling down, you leave yourself vulnerable to someone who is willing and able to get people started with something easier than what you’re offering.

Bill Venners points out that the Rails folks have done a very good job of marketing what they’ve done. Agreed. It’s been hard to see the opposite effect in the Tcl community, which has some really good technology that has been sold very poorly.

Speaking of which, James Duncan Davidson says Ruby doesn’t have a “compelling” gui toolkit. It has Tk though, and if they do their homework, will soon have Tile. And that’s not bad… maybe it’s not the glitziest thing out there, so I could see why it might not appeal to a Mac guy, but on the other hand, there are countless very compelling desktop apps waiting to be written that are interesting to people for what they do, not just because they are slick looking. And frankly, it’s not like Java is that hot in the gui space in any case…

Mini-Language

Only tangentially related to the above, I found this while looking at ofbiz, which looks to be a pretty good system for what it does. However, the “scripting language” doesn’t really make sense to my way of doing things. Look at the example towards the end:

http://www.ofbiz.org/docs/minilang.html

That seems like an awful lot of verbosity for something that doesn’t absolutely need to be edited by a computer.

Idle thought of the day:

How does licensing interact with standards – how does the presence of a standard affect which license you should choose for an open source project?

We know how the GPL and BSD licenses work, and how the differ… how each can work in different situations with different community and business goals.

But… let’s throw another factor in – an open specification/standard that is well defined and doesn’t have a lot of “wiggle room” for real innovation. Should you choose the maximum amount of openness (BSD) because a proprietary implementation doesn’t have that much room between you and the “ceiling” (100% spec compliance), so there is no real reason to make a proprietary fork? Or is the whole thing a moot point because most specs are usually big things that leave a lot of room underneath for innovation. It would be ridiculous to reduce Linux or FreeBSD to “just an implementation of POSIX and a few other Unixy specs”, for example.

The uptake of the standard probably weighs on the equation too. If it’s something you just want to see as widely used as possible (say, TCP and IP), the BSD license is a good one to get the code into a lot of people’s hands.

An already adopted standard in wide use with no free implementation might have other implications, depending on what your goals are – if you did a nice implementation, perhaps you could corner some licensing fees by dual-licensing the code as GPL/proprietary.

Perhaps it’s not that important a factor in the mix… what are your thoughts?

Hecl is for the moment mostly a fun project, but I wanted to see if I could build something real with it, as that’s always a good way of working out the kinks.

The result is a web + j2me shopping list application. You create the shopping list online, then enter the generated code in the phone’s java app. It fetches the list via http and creates a checklist. Simple stuff, but it seems to work ok, although of course there is room for improvement:

http://shoplist.dedasys.com

Something I’m really curious about is why the Java folks suddenly stood up and took notice of Ruby. Is it just Rails? Did Rails arrive in the right place at the right time? It’s not a rhetorical question – I don’t have a lot of insight into the Java world, so I’m genuinely curious as to what sparked this interest in “beyond Java”.

Python’s been around for a long time, and isn’t that different from Ruby. Tcl with Tk runs circles around Java for cross platform GUI development. PHP, even if it’s not the cleanest or most glamorous thing out there, makes whipping up small web tools easy. (I’ll concede that Perl has a culture that is too far removed from a lot of the things Java tries to do). And all those have been under everyone’s noses for years.

So why all of a sudden is Ruby the “hot new thing” that is to be embraced, rather “defended against”, as we often see in such programming language “willy waving contests”. Was this something that was just waiting to happen, and all it took was something to coalesce around? Were people in that world starting to get wrist injuries from typing out so much stuff, and on the lookout for “something else”?

Joking aside, I really am curious, because over the years, I’ve developed an interest in how these things work. I talk about it some in The Economics of Programming Languages, but that’s clearly not the whole story.

Java and its human resources requirements

Another thing I’ve been idly wondering about is whether perhaps Java got pushed a lot (perhaps unconsciously) by big companies, because 1) it is a good solution for big teams 2) some aspects of it are so big and unweildy that only companies that can muster the manpower to throw at it are going to do well with it, meaning that smaller shops would either have to not compete in that market, or compete poorly.

Obviously, it’s not strictly necessary to use Java – more often than not, you could accomplish the same thing in less time with some other system, however, the “other pincer” is the marketing out there that Java is the “serious, corporate, enterprise” solution, and that anything “less” just won’t do. This gives firms an incentive to use Java even when it might not be the best solution, and helps create a market where it’s a given that the solution is some Java system, and the bigger company, being able to bring more people to bear, may have an edge.

Anyway, just some idle speculation – what do you think?

I recently signed up for the local Java Users’s Group, as a way to poke my nose in something new, and maybe get a few locals interested in Hecl.

They just announced their upcoming meeting, at 9 AM on Saturday the 19th. When I read that, the first thing that went through my head is “Paul Graham is right, these guys are not hackers!”.

I don’t think I’ve ever been to any kind of Linux event that wasn’t an evening affair, perhaps with a meal and/or beer involved. Conferences occasionally start at that time of day, but that’s because people are paying to be there, want to fit as much stuff in as possible, and they last all day in any case. But choosing to meet at 9 AM on a Saturday is I think one of the clearest signs that this community is a bit different from others in which I take part. Not to put these guys down – a couple of them seem to be quite bright, but… perhaps they just aren’t hackers.

A couple of random considerations on web applications versus the more traditional sort:

• No one seems to get quite so uptight about closed-source web applications, like google. The same people (this includes me too, to some degree:-) who get uptight about basing any of their infrastructure on closed source stuff like Java have no qualms about google and gmail. Maybe it doesn’t feel as intrusive because it’s not installed on your computer. This is sort of a strange phenomenon, because I think most of the ‘purists’ realize perfectly well that Google et al. are not free software, but don’t seem very vocal about it.

• In the form of google adsense, you have a ready-made revenue stream. It might not be the optimal way of making money off of your application, but you can get started very easily without having to dedicate much thought to it. Later, if you have clever, better ideas, you can always implement them, but in the meantime, at least you’ve got something to work with.

• They’re easier to upgrade, but that’s pretty obvious.

I had a look at this:

http://www.jadetower.org/muses/archives/000416.html

and thought to myself… hey, I could do that in Tcl in half the code. And it could also handle more than one connection:

proc DoLine {channel} {
    gets $channel line
    puts $channel $line
    flush $channel
}

proc Server {channel clientaddr clientport} {
    fileevent $channel readable [list DoLine $channel]
}

set sk [socket -server Server 6200]
fconfigure $sk -buffering line
fconfigure $sk -blocking 0
vwait forever

I find it more readable as well.

Ruby may well have some good stuff – Rails is very impressive, for instance, and I’m sure Ruby has got lots of other things going for it (like libraries, as the article mentions), but Tcl at its best does things very much the way I like them – simply and elegantly, but without taking away the possibility of doing fancier things should the need arise. Kind of like Rails:-)

lcdui is the ‘GUI’ that is provided with j2me for environments like cell phones. The second version of the API, MIDP2.0, has been cleaned up some with respect to MIDP1.0, but since I want to target as wide a range of devices as possible, I need to make Hecl work as well as possible within the limitations of MIDP1.0.

The latest problem I have encountered is the differences between the List and ChoiceGroup widgets. These are supposed to provide radio buttons or checkboxes, depending on which attributes you specify, with List being the “full screen” version, and ChoiceGroup being an Item that can be included as one component of a form. Form items can register for callbacks via itemStateListener, which is called when the form item’s state changes. Lists do not have this capability though, so you have no way to register callbacks when a List item is selected or deselected.

To remedy this, I decided that I’d just make my own ‘full screen list’ by creating a form with one ChoiceGroup, which works something like this:

public class ListBox extends Form {
    public ChoiceGroup cg = null;

    public ListBox(String title, int choicetype, String []choices) {
        super(title);
        cg = new ChoiceGroup("", choicetype, choices, null);
        this.append(cg);
    }

    public int append(String item) {
        return cg.append(item, null);
    }
}

some details ommitted, but that’s the idea. So far, it seems to be working exactly as I needed – I was able to define a callback that performs an action when all checkboxes were checked.

The only thing I can think of that I’d need an actual List for is to define some sort of menu that performs some action when an entry is selected, via the IMPLICIT Choice type.

Apparently, this problem with List’s has been fixed in MIDP2.0, but… there are a lot of phones on sale that still ship 1.0, so it’s going to be with us for a while yet.

Rivet has been seeing some increased visibility these days, but it seems that people are encountering a great deal of difficulty installing it due to problems with autotools.

This is extremely frustrating to me, because the code itself works fine. It’s all the installation crap that always seems to have problems, on all major platforms. I built and tested the latest version on Ubuntu, and everything was working fine. But there have been problem reports for Fedora, MacOS X (although that’s not an autotools error – Karl Lehenbauer wasn’t even able to make autotools work for MacOSX, so we switched back to the Tcl based build system) and Windows.

I really want this stuff to work, and people aren’t going to use it if they can’t build and install it. On the other hand, people need to help out on the platforms they are knowledgeable with because I’m limited in what I can do on certain platforms.

On the whole, it’s all quite frustrating and leaves me even more unhappy with autotools than I was before. The Rivet code is good, and we’re happy with it, but we find ourselves with something that feels like a …barrier…between us and our users.

Update

Problems are getting cleared up, but it’s still frustrating. As everyone who’s worked with auto* knows, debugging these things is sometimes a black art.

I just upgraded to the latest stable Ubuntu release, and I continue to be impressed by this distribution. It has all the positive aspects of Debian, it’s free software, and it has a very high “just works” factor. If you plotted the Desktop Linux “just works” factor over the last five years, I think you could safely predict that Linux is going places based on the slope of that curve – its rate of improvement is dramatic.

One of the things that makes Ubuntu “better” than Debian is that they have made choices. Where Debian has gone to a lot of work to make it possible to use alternate software packages, Ubuntu in many cases has selected one (while not eliminating the ability to choose another one if you’re really set on it) that they feel is the best.

I like this as a design philosophy: give people the obvious choice without making them select between all the choices, but let them chose if they need to.

Tcl’s sockets work that way for instance:

set sk [socket www.foo.bar 80]

nice and simple – let the computer worry about looking up host names and such, and give people a line-buffered blocking socket that they can configure to be buffered differently or non-blocking, or any number of other options.

See Scaling Down