Sam Ruby posts the slides from his FOSSSL keynote entitled, “The Case For Dynamic Languages”.
The slides make the case as well as slides can. I especially liked this bullet on Macro-performance vs Micro-performance:
Modest hardware running Perl can easily saturate your bandwidth
Similarly powerful arguments all the way through…
I’ve written previously on the trade-offs that microformats make in vocabulary design. I’m still not sure how I feel about the short-string issue, but it appears no one is waiting for me to make up my mind, so I figured I’d try it out.
So far I like it that microformats depend on well-understood technology, and that a lazy dev could point their HTML rendering component at the page if they didn’t feel like writing support. OTOH, parsing can be a bear. I think I may have cheated a little in that I insisted on XHTML, but even that had its own problems, since it’s tied to a DTD. Either you write your own entity resolver or the XML parser downloads three DTD files from w3.org. Rotten. I let my example client do just that in the interest of brevity.
On the lesscode side of things, the draft includes Python implementations of a client and server. With margins, the IETF txt format ends up allowing something less than the usual number of columns, so it cramped my Python style a little bit. I think they ended up pretty short, but one of the nice things about Python is that someone can always show you a way to do it that’s shorter and clearer. So, let’s have it! (no generators allowed, to keep things adaptable to those other languages :)
Stumbled upon this at InfoWorld (it’s the Alan Cooper interview) :
One of my assertions is that code is not an asset. A lot of companies say their job is to maximize the revenue from our code base. That reflects a kind of an Old World, industrial-age thinking. What’s interesting is the open-source movement is kind of our first proof that code in fact is not an asset. What is your company’s asset is the experience and knowledge that the people who have built your code have gathered during the construction of that code. But the code itself doesn’t have a lot of value. In fact, the code kind of anchors you down. In the traditional manufacturing business 30 years ago, if you had a warehouse full of spare parts and completed products, that was an asset that you put on your books. Today if you’ve got a warehouse full of manufactured goods, that’s a huge liability. In the world of software, it’s your relationships with your customers and vendors and the knowledge of your people that are valuable. This is part of the movement from a product-centered world to a service-centered world that we’re going to. I think the open-source movement is sort of like a moon mission. They went to the moon to see if we could go to the moon, not to set up a burger stand there. People who will come after will set up burger stands there. Linux may or may not be commercially viable. But I think that the people who follow in their footsteps will find that software is service. The software itself is not of value.
Sounds kind of extreme to me, but in actuality says a lot about the value of lesscode.
Now, I’ve been a Cooper-head since 1996. I’ve spent a lot of my brain cycles over the years honing my interaction design skills. And I firmly believe that Alan is absolutely right in his assertion that only desirable products and services make any sense.
As we already know (and agree), lesscode is all about agility. Since software code is not an asset, but rather a liability, the more we can reduce the deadwood, the better off we are. A side-by-side comparison of the code written in RoR with the code doing the same thing in Java or .NET reveals striking discrepancy in size. It is definitely possible to deliver high level of functionality, interactivity and sophistication by utilizing only a portion of code that would normally be used if we stick to the old school (morecode, or more LOC). And that’s a desirable thing.