lesscode.org

There seems to be a big disconnect between the bureaucratic-minded developers and the so-called hackers (’hackers’ in Paul Graham’s sense of the word). This disconnect is getting exacerbated lately by the explosive success of the hackers’ business model (witness the juggernaut that is Ruby on Rails, 37signals, etc.)

Bureaucrats obviously dislike languages that require thinking. Bureaucrats prefer to migrate expertise from the individuals and into the prescribed ’system’ (by prescribed ’system’ we mean faceless, nameless policies and procedures). This is precisely why bureaucrats insist that only languages such as Java and C# are worthy of their attention. They despise any languages that cannot easily be offloaded onto some mechanical device, such as Eclipse’s Modeling Framework, or onto some overseas organization.

Hackers on the other hand tend to despise any mechanization, or industrialization of the process of creating software. Hackers are not buying into the possibility of drawing a picture that could be used to generate the machine executable code. Real hackers know that programming is like higher mathematics — it’s too abstract to be ever faithfully expressed visually.

What’s interesting is how bureaucrats use FUD to push forward their agendas. First they insist that all programming languages were created equal. After all, it’s all ones and zeros, so what’s the big fuss?

But then they turn around and claim how all languages were actually not created equal, because in Java we have the pinnacle of simplicity — in Java, you can do something in one, and only one proper way (so, the simplicity in Java turns out to actually be rigidity). The FUD bureaucrats are spreading is so lame, so desperate, that it would be hilarious if it wasn’t so bloody damaging to our industry.

It’s definitely going to be an uphill battle for the hackers. I firmly believe that creativity will, in the end, win. But lots of people are going to try and kill creativity, no matter what the price.

I predict that it’s going to get very ugly. Much uglier than it already is. The time is slowly coming for us to make the decision — are we going to support the creative way of doing it, or the bureaucratic way?

I’m not a programming language designer, but I know what love is.

Bruce Eckel:

I think we’ve mostly been hearing from people who have come from Perl and found Ruby to be a ‘better Perl, with objects that work,’ or people who are finally convinced that dynamic languages have merit, and so mix the enthusiasm of the first time dynamic language user (quite a rush, as I remember from my 2-month experience with Perl many years ago) with their experience of Ruby. So far, I’ve heard from the hyper-enthusiasts about Ruby being cool, or that it has begin-end blocks and they don’t like indentation to delineate scope. That kind of thing: ‘I like this, I don’t like that,’ which is fine but not compelling.

David Heinemeier Hansson:

I’m losing track of the ill-conceived comparisons, but I do know what’s astoundingly clear: Bruce Eckel doesn’t like Ruby, he doesn’t like the attention its getting, and he doesn’t like people such as Bruce Tate fueling that attention. No beef, that’s cool. But why not just say it like that? You could even have presented yourself as the polar opposite to the so-called hyper-enthusiasts: A hyper-detractor! The label comes complete with a cape, an evil smirk, and long tirades about how the other side is no match for your master plan.

Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can’t represent the information that the users need, the application doesn’t do what what the users need it to do, and instead of writing code, the “engineers” are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they’d leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet.

Programmers would rather squabble about minituae - it seems this transcends community or language choice. Yet a Python programmer can become functional in Ruby in short order, and vice versa. That’s an important message for anyone that worries about how a software system is going to be supported a few years out - it suggests that with respect to the job market, the languages are interchangeable. They are platform neutral, both run on the JVM or interoperate with .NET. That’s an important message for anyone who requires back-end systems integration. They complement mainstream enterprise development by providing a disciplined approach to scripting when scripting is what’s required. That’s an important message for anyone who ever got saddled with a now-critical, yet spaghetti-like webapp that grew out of a quick scripting hack. They are highly suited for those who need to write software but do not have a systems programming or pure CS background. That’s an important message for anyone who just wants to get something down without going to market for engineers. They’re productive, and while we can’t tell you what productivity is, we know it when we see it. What’s my point? That there are plenty of interesting messages to be sending out, as opposed to the one that suggests programmers will always, every time, without fail, quibble. Is it really that inconceivable that the growing interest in particular frameworks (Rails) and languages (PHP) by enterprise types floats all dynamic boats?

Ruby’s a great language. Ditto Python. About the best anyone can do in terms of differentiating the core languages is mumble something about elegance, or how good closures^[1] are. Yet for about 98.6% of what you do as a working stiff, the core language differences are irrelevant^[2]. You might get hung up on whitespace or the end keyword, but that’s a bit like getting hung up on driving on the “wrong side of the road” when you go on holidays. You’ll get used to it, unless you intent to expend a lot of energy refusing to get used to it.

Still, from all the blog noise this gem of quote is worth pulling out:

But Ruby has only emerged in the last 5 years or so, and only gotten the catalyst in the last 2. Right now, I’m looking for a dynamic language that I can sell into conservative accounts, because I can be more productive with them for certain problems. I actually like Python, Lisp and Smalltalk, though of the three, I’ve only used Smalltalk in anger, and only on very limited apps. Iwould be happy with any of the 3 as an alternative. Smalltalk’s the most pure, Python the most approachable, and Lisp the most powerful. It’s jsut that as a consultant at conservative Java accounts, I need to also consider market penetration. Java has already popped. In Ruby, I see a possible catalyst in Rails. In Smalltalk and Python, I don’t. But since Beyond Java, I’ve used Rails, Spring and Plone on various applications, and been peased with each.

That’s from Bruce Tate, commenting on Bruce Eckel’s entry. That kind of realism coming from a developer is refreshing.

1. Anyone who really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.
2. Python is further along in terms of library support. Libraries do matter, but in terms of core langauge design, they are a contingent diffentiator.

Couple of months ago I’ve posted links to my presentation on Ruby on Rails. Finally, after some deliberation, they posted the audio (about one hour in length).

Norman Walsh’s post on XMLK reminded of a post I had been meaning to write. I think microformats are a non-backwards compatible, but very practical, variation on XMLK. In this XML subset, HTML named character entities (e.g.  ) can be resolved without a DTD, having been grandfathered in.

Here’s a slightly elided log line from a system I work with:

WARN 2005-09-28 14:38:38 StandardContext[/pmr]  {”mid”:”123″, “type”:”XYZ”, “msg”:”foo”, “T”:”2005-09-28 14:38″, “L”:”warn”}

It identifies an XML document passing through the system using some keys from the envelope. It may seem a strange looking way to log an event, but between the angle brackets lies a useful side effect - it’s a Python dictionary. Hence this (vastly oversimplified) example log processing code, that runs eval() on each log line to load the dictionaries into memory:

Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
>>> dicts =[]
>>> import re
>>> p = re.compile(”.*({.*?}).*”)
>>> file = open(”log.txt”).readlines()
>>> for line in file:
…     m = p.match(line)
…     if m:
…             d = eval(m.group(1))
…             dicts.append(d)
…
>>> for d in dicts:
…    print d
…
{’L': ‘warn’, ‘mid’: ‘123′, ‘type’: ‘XYZ’, ‘T’: ‘2005-09-28 14:38′, ‘msg’: ‘frobnizer  found’}
{’L': ‘warn’, ‘mid’: ‘124′, ‘type’: ‘XYZ’, ‘T’: ‘2005-09-28 14:38′, ‘msg’: ‘frobnizer  found’}
{’L': ‘warn’, ‘mid’: ‘125′, ‘type’: ‘XYZ’, ‘T’: ‘2005-09-28 14:38′, ‘msg’: ‘frobnizer  found’}
{’L': ‘warn’, ‘mid’: ‘126′, ‘type’: ‘XYZ’, ‘T’: ‘2005-09-28 14:38′, ‘msg’: ‘frobnizer  found’}
>>>

What’s nice about doing this is that it’s cheap to write the log line in a way that maximises usefulness later on - logs are often an afterthought, but good logging is critical to operating production systems. And it’s one example where creating metadata is cheap.

As well as programming data structures (changing the above to a Ruby hash is straightforward), you can get log lines to output something like Turtle, which is a greppable RDF format. What’s good about Turtle in particular is that you can dump or stream a log file straight into an RDF query engine, such as ARQ without any transform step and start writing queries against the data. Or how about writing down inferencing rules that help indicate the business consequences of a software error? The log lines themselves don’t carry enough information, but combined with rules and some context as to where the log event came from you can do interesting and useful things - the biggest issue with any monitoring software is gathering up all those machine level events and contextualising them so that data (noise) can be turned it into information (signal). Think of a machine readable data stucture inside logfiles as just another microformat.