Steve Yegge posts an article about this that, the other thing, and statically typed functional programming languages. In it, he compares Haskell to something you can:

"build beautiful, lithe marionettes with"

Unfortunately, I haven’t had the time or inclination to learn Haskell (yet), but I have used Erlang professionally, so I do have a bit of experience using a functional programming language. What comes to my mind isn’t marionettes, but clockwork. That’s a purposefully neutral word, in case you were wondering. An enthusiast might say “a finely crafted swiss watch”, and a detractor might grumble “a windup toy”. In my mind’s eye, the concept is that in functional languages you get this succession of things happening one after the other that happen precisely the same way, if the program is wound up just the same each time. To paraphrase:

Do this with the result of this with what this produces when given  
this input that is derived from this function which takes the  
result of this other thing after calculating the result of 
something that is derived from the output of a function that ...

And so on and so forth…tick, tock, tick, tock.

While I can appreciate that in some ways, this is likely to produce clean programming, in other ways I am less convinced of its practicality. If you’ll bear with a poor comparison, sometimes programming is like a song. You do the tricky section, then you go back to an easier section and catch your breath for a bit. That seems to work out in a language like Ruby or Java fairly well, depending on how densely you like your code. You get sections with DoThisAndThisAndThatWithTheResultsOfSelectThisFromTableXYZ that you have to slow down to think through. And then:

• You assign the result to a variable.

• Which gives you a few lines to

  • slow down
  • consider where the program is

• And then

GoToTheNextTrickyBit where ManyThingsHappen.

All in all, you wind up with a sort of ebb and flow that works out pretty well if you’re in tune with the code being written, going from intense calculations, to a line or two where you do no more than store things in a variable, take a breather, and prepare for the next important stanza.

In my limited experience, I have to say that I didn’t always get that sensation from Erlang (which in some ways is apparently less “hair shirt” oriented than Haskell). You always had to be writing something with an eye to where it was coming from, and where it was going.

Without a doubt, this produces code that is more compact in terms of meaning and functionality, but at times it leaves a guy like me, who grew up with Basic, C, Python, and so on with the desire to say “woah there, nelly”, let’s take a breather and sort things out a bit in a few variables before moving on to the next bit of fancy code gymnastics.

What I’m curious about is what will catch on from academically oriented programming languages like Haskell. The people working on them are without doubt very smart, and there are some interesting concepts being bandied about (pattern matching is pretty cool, just to cite one). But academia doesn’t always produce things that catch on with the average Joe programmer, either, and while the more elitist out there may attribute this to simplistic reasoning such as ‘well then Joe is just stupid’, I think that the more thoughtful language crafters will attempt to ascertain what works, and what doesn’t, and perhaps we will see the Ruby of functional languages emerge from Haskell, the Smalltalk of functional languages.

What do you think?

I generally try and keep this journal focused on technology issues, but this is one bit of frivolity I couldn’t pass up:

Andrew Savory and Steve Loughran mention the idea of an Apache Bike Team.

I’m in! I’m always happy to take people for a ride through the nearby Colli Euganei and/or Colli Berici if they happen to come through my section of northern Italy, which really is a wonderful place to ride a bike. Spring, Summer and Fall are best, but even in winter it’s often nice (about 10C and sunny today, although I’ve been stuck inside with the flu this week…argh).

(I’ll also take a minute and plug my friend’s bike racing/training/touring camp business too: raceitalia.com/)

Now if only I had more time to be out riding myself…

I’ve been using Rails for about a year, and I am, in general, quite satisfied. It really is a big step forward in terms of web programming, and I’ve found the whole experience very enjoyable. In a year I’ve managed to crank out a number of sites in my spare time (in between various other activities such as the occasional bike ride and Hecl hacking):

• linuxsi.com – a site in Italian helping people to locate Linux-friendly computer retailers.

• builder.hecl.org – lets you create Hecl mobile phone applications from your web browser.

• libreriaminerva.it – a small bookstore in the center of Padova, specializing in rare and antique books and prints.

• stufftodo.dedasys.com – my own vision of an ajaxy todo list that plays nicely in a business environment, where it’s important to be able to share tasks.

As promised, one of my goals is to shift a bit towards producing open source software as a side effect of revenue generating work. The first small result of that is the on_idle plugin I packaged up for Rails. It’s the code that Stuff To Do uses to tell whether people are active or not. Installing it should be as simple as:

./script/plugin install http://svn.dedasys.com/public/on_idle

It’s just a few lines of Javascript code that are wrapped up in a way that makes it trivial to use from Rails views:

def on_idle(timeout, options, wakeoptions)

<%= on_idle(600, {:url => { :action => 'notify_idle' }},
                 {:url => { :action => 'notify_wake' }}) %>

• timeout: the number of seconds before the user is considered ‘timed
  out’.

• options: the action to perform when the user goes idle.

• wakeoptions: what to do when the user ‘wakes up’.

Let me know if there is anything I should fix/change/improve. If this plugin works out, I will post, in short order, a plugin that improves the default Rails drag and drop functionality.

Regarding my previous posting, the first thing that I wanted to release is called “Stuff To Do“, and is a simple, elegant priority queue for getting things done. It lets you reprioritize, track time spent on tasks, generate reports on time spent, and most importantly, share with other users. You can create groups of people who can view one another’s tasks, and give tasks to other users, all via a very intuitive interface (javascript is, however, required). It’s all meant to stay out of your way as much as possible, even the time tracking requires only that you visit the browser window every so often to let it know you’re there, rather than fiddling with (and sooner or later forgetting about) start and stop buttons. Perhaps it’s not accurate down to the second, but the idea is to give you a general idea of what you’ve been up to, rather than something you have to slavishly click on all the time.

The group interface is also meant to be easy to use to get a quick idea of what other people are working on, or share tasks with other people. For instance, if you’re a project manager, you could create a bunch of tasks, and then just drag and drop them to other people in the system. You can’t change other people’s priorities (yet), because I think it’s better if you simply ask them yourself – technology isn’t a substitute for communication!

While I work on the paypal interface (I looked into Google Checkout, but it’s still got some limitations), I’m going to let people sign up for the group-enabled version with six months for free. It won’t cost too much per user when I roll it out in any case, probably somewhere south of $20. The basic version is likely to remain free as long as I can cover hosting costs.

I’ve been using it myself at work and home for the past month or so, along with a few of my colleagues, and it seems to fill a nice niche in between more heavyweight issue tracking tools like JIRA, and the index cards/bulletin board we’d been using.

Check it out – I hope you like it! In any case, let me know what you think.

As of this writing, the DNS/infrastructure hasn’t quite caught up, but ofbiz.apache.org ought to be live soon. “Apache Open For Business”, aka OFBiz, has been promoted out of the incubator (the term the ASF uses for projects hoping to become full-fledged ASF projects) to its own top level project.

As J Aaron Farr mentions, they managed most everything on their own, and were a project that wouldn’t have looked out of place as part of the ASF even from the beginning of the incubation period, which made my job as a “mentor” pretty easy.

What will be interesting is to track the project going forward. It has tremendous potential, because it focuses very much on providing not only the low level tools (which is still where most open source is), but also on creating good business models and processes, which is relatively newer terrain in the open source world.

I think they face a couple of important challenges. First and foremost, a way to lower the barrier to entry. OFBiz is a big collection of code that in some ways tends to stand alone compared to the “mainstream” in that it uses its own tools in terms of the framework. Also, since it encompasses so much, it’s a lot to come to terms with when you get started. This means that the initial step of the “learning curve” is pretty high, and I imagine that a lot of people stumble. Clearly, it’s not a simple application, but I think efforts to make it more approachable will pay off in terms of attracting more users (and eventually, developers).

The broader challenge is simply the fact that in some ways, this is uncharted territory for free software, so it remains to be seen what sort of “ecosystem” (if you’ll pardon the buzzword) grows up around it. For instance, at this point in time, no one, least of all the core developers, sees it as a program that you simply download and run, but rather as a place to start from for integrators and developers who mould the code to fit the needs of the particular firm adopting it. That’s working right now, but perhaps at some point it will be more of an out of the box system. Or maybe not – attempting to make it work well for a vague ‘everyone’ might just be chasing taillights and prove ultimately fruitless.

Unfortunately, I still haven’t had the opportunity to use it “in anger”, as they say, so I don’t have much to say about it technically, but from a business point of view, I really like their data model, and the system of processes they’ve put together, which allows you to capture a great deal of use cases in a very flexible way, which is no mean feat.

In any case, a big round of congratulations to the core developers, and best wishes for the future!

In a few days, I hope to launch a little project that I’ve been working on, that was inspired by some concrete needs at work. That’s nothing new, as I’ve often undertaken new projects after seeing needs out there in the ‘real world’. What’s going to be different this time, though, is that I’m not going to release it as open source software. Instead, I’m going to make the basic version available for free on the web, and charge money for more advanced versions, in various ways.

That’s a pretty big change for me, as I’m very dedicated to the idea of open source software. It’s simply more fun than the proprietary sort, and I love cooperating with other people on things, and all in all, it’s just easier to release stuff that way.

However, I want to try something new… I want to see if I can make some money on a few ideas and projects that I have in mind. I’ve thought about it a lot, and the shortest, most direct feedback loop in the types of end-user applications I have in mind is going the ‘commercial’ route. If I can make a bit of money on the applications, I can spend a bit more time either improving them or developing new ones. If they were open source, the most I would get is other people contributing a little bit back, but that doesn’t matter much, as none of these ideas are all that complex.

I’m not giving up on free software… I couldn’t. My hope is that by providing myself some extra income, that I will be able to produce some free software as a ‘side effect’, ala 37 signals or google, or any number of other groups that contribute a lot of ‘side dishes’ to open source, while saving the main course to make their money with.

Hopefully you will see more in this space in the next few days.

Apples and Oranges

A number of people wrote irate comments after my article about Ruby’s eBay API beating PHP hands down. They complained that I was comparing apples to oranges, because the Ruby library I was using was nicely crafted, whereas the PHP one was some crufty crud that just happened to be one of the first things you find when you go to developer.ebay.com.

First things first, let’s look at some better PHP code:

require_once 'EbatNs/EbatNs_ServiceProxy.php';
require_once 'EbatNs/EbatNs_Logger.php';
require_once 'EbatNs/GetItemRequestType.php';
require_once 'EbatNs/ItemType.php';

$session = new EbatNs_Session('config/amd.ebay.config.php');

$cs = new EbatNs_ServiceProxy($session);
$cs->setHandler('ItemType', 'handleItem');

$req = new GetItemRequestType();
$req->setItemID(5652664344);
$req->setDetailLevel($Facet_DetailLevelCodeType->ReturnAll);

$res = $cs->GetItem($req);
echo "<pre>";
if ($res->getAck() != $Facet_AckCodeType->Success) {
echo "we got a failure<br>";
foreach ($res->getErrors() as $error)
{
    echo "#" . $error->getErrorCode() . " " .
    htmlentities($error->getShortMessage()) . "/" .
    htmlentities($error->getLongMessage()) . "<br>";
}
} else {
//#type $item ItemType
$item = $res->getItem();
echo "ShippingTerms : " . $item->getShippingTerms() . "<br>";

print_r($item);
}

versus our Ruby code:

require 'rubygems'
require 'ebay'

include Ebay
include Ebay::Types

require 'localconfig'

ebay = Ebay::Api.new

begin
  response = ebay.get_item(:item_id => '110011765264')
  puts "ShippingTerms : #{response.items.shipping_terms}"
rescue Ebay::RequestError => e
  e.errors.each do |error|
    puts error.long_message
  end
end

So, they get closer with that, but the Ruby code is still clearer and more concise. If you look around at some PHP5 based examples, they start to be decent as well. As one tutorial writes:

These components combine to create a kick-ass tool that PHP 4 can’t replicate without lots of work, if at all.

Leaving aside the fact that a lot of people are still more or less stuck on 4, I think there is something more important to be learned.

Culture

There are a lot of really smart people who work with, and on PHP. As much as anyone grumbles about any language, it’s not easy to create one, let alone create one and make it as popular as PHP. However, as I’ve said elsewhere, one of the things that made PHP so successful was its ability to “scale down”. Part of its value is that it made it much easier for more people with less advanced skills to create things. That is, without doubt, a very fine accomplishment, but it does bring some baggage with it. Namely, that there are a great deal of PHP programmers who do not write very nice looking code. Going back to the eBay example, the code featured on their site is not very tasteful, if you ask me. My bet is that in Ruby-land, that sort of code would not be displayed very prominently. Why? It’s not the computer, it’s the culture that has grown up around the different languages.

Computers do not care one bit about programming languages. They interpret bits and bytes, whatever language is used, so it’s really all the same to them. Programming languages matter only to people, because they are the tool we use to comunicate our instructions to machines. This means that they are a very human thing in some ways, and that human aspects of them matter a great deal.

What this means is that it’s important not only to design a cool language, but to create a good culture around it. To take aim at something nearer and dearer to me than PHP, one of the major failings of the Tk toolkit was that there was little to no attempt to create a good design culture around it. Anyone who was using Linux 10 years ago will surely remember some of the truly horrible things that were created with Tk. Why? Tcl and Tk made creating a GUI an order of magnitude easier than with C and Motif (or whatever windows used at the time), and turned them loose with no instructions or idea whatsoever of how to go about creating a good, intuitive user friendly one – the Tk docs themselves make little to no mention of usability, and even the best Tcl/Tk books pay almost no attention, even in the form of recommended reading, to what to make with this beautiful tool whose hows are explained very well. The unixy community also wasn’t exactly a wellspring of creativity and critique in terms of good guis, either.

So, yes, I know that it’s possible to write good, clever, readable PHP (or Perl, or FORTRAN) code, and bad Ruby (or Tcl, or Python, or whatever) code. However, I’m also convinced that culture counts. People who value clean, beautiful code gravitate to cultures, and, where possible, workplaces where they find other like-minded people. Others, not having as many options, find themselves staring at 13000-line PHP files that grow malignantly by dint of cut and paste, wondering how to tame that which others have wrought!

At work, we’re doing some coding to integrate our system with Ebay’s system, which is kind of big and complex. Here’s some PHP code to get a listed item, from eBay’s developer site:

$verb = 'GetItem';
//Regulates versioning of the XML interface for the API
$compatabilityLevel = 433;

//get an array of strings containing the required headers
$headers = buildEbayHeaders($devID, $appID, $certID, $compatabilityLevel, $siteID, $verb);

///Build the request Xml string
$requestXmlBody = '<?xml version="1.0" encoding="utf-8" ?>';
$requestXmlBody .= '<GetItemRequest xmlns="urn:ebay:apis:eBLBaseComponents">';
$requestXmlBody .= "<RequesterCredentials><eBayAuthToken>$userToken</eBayAuthToken></RequesterCredentials>";
$requestXmlBody .= "<ItemID>$id</ItemID>";
$requestXmlBody .= '</GetItemRequest>';

$responseXml = sendHttpRequest($requestXmlBody, $serverUrl, $headers);
if(stristr($responseXml, 'HTTP 404') || $responseXml == '') {
    die('<P>Error sending request');
}

//Xml string is parsed and creates a DOM Document object
$responseDoc = domxml_open_mem($responseXml);

//get any error nodes
$errors = $responseDoc->get_elements_by_tagname('Errors');

//if there are rrror nodes
if(count($errors) > 0)

… and so on and so forth (it just gets more painful)…

Compare with Cody Fauser’s Ruby eBay API

ebay = Ebay::Api.new

begin
  response = ebay.get_item(:item_id => '110011765264')
rescue Ebay::RequestError => e
  e.errors.each do |error|
    puts error.long_message
  end
end

It’s not even a contest. Best of all, most of the code that turns the XML interface into Ruby code is auto-generated. Very nice work!

OFBiz passed its vote to exit the “incubator” at the Apache Software Foundation. For those not up on the inner workings and jargon, this means that it should soon (as of the next board meeting) become a regular project at the ASF, like httpd, Tomcat, and so on

Si Chen, one of the core team, sums up the whole process here, which is an interesting read for those considering approaching the ASF.

Having helped set things in motion via an out of the blue question on their mailing list, I’m pleased to see that things are working out well, and continue to be impressed with the progress they are making, as well as the dedication with which they pursued integration with the ASF (and the bureaucracy that entailed). It would have been nice to use OFBiz where I’m working, but unfortunately that was not to be. In any case, I do glance at the code and data models from time to time, because they encapsulate a lot of good ideas.

Hecl is a weakly typed programming language, which, for a scripting language is often an advantage. Instead of cluttering your code with lots of (casts) or performing.to_s all the time, things “just work” depending on the context (and assuming that you’ve verified your data or have error handling for when things go wrong).

I’ve been pondering a weakness of this model that Tcl doesn’t adequately solve, discussed here:

http://sourceforge.net/mailarchive/message.php?msg_id=37354848

The summary is that if anything can and will be converted to a string at some point in its lifetime, GC’ing “complex objects” (things that can’t be represented by a string) gets difficult. In order to be able to go back to an object from a string, you have to maintain a hash table with string handles that point at the actual objects in whatever language you are using, and that in turn requires that you somehow keep track of the lifetime of those objects. Doing GC in Hecl itself is something I’d hoped to avoid – up until now, we have managed to get by ok with Java’s GC.

The ‘best’ solution seems to be Salvatore’s, discussed here:

http://wiki.tcl.tk/13847

But even that is relatively complex, and at least initially, involves a couple of tours through the entire string-space of the running program.

Unfortunately, I don’t think there’s really a clever way around the problem, though… what the weak typing giveth, the weak typing taketh away (or something along those lines).

I am not sure what this means for Hecl at this point, whether we simply say “clean up after your own objects”, introduce some sort of string typing, or something else entirely…