lesscode.org

I’m indebted to Ryan for bringing Clay Shirky’s online catalog of articles to my attention. While reading Clay’s “Semantic Web, Syllogism, and Worldview” article (a totally smashing, almost to the point of being devastating piece of writing, by the way!), I almost jumped out of my chair when I ran into the “this will work because it will be good if it did” fallacy. Yes, the field of software is littered with these kinds of fallacies.

Take the myth of the code reuse, for example. It is clearly one such fallacy – “it would be nice if we didn’t have to expend any effort in creating software code, and so reusing existing code will work.” And because everybody nowadays seems to adhere to the code reuse fallacy, the state of the software industry is nothing short of dismal.

Now, me being the most rabid, foaming at the mouth less-code evangelist, you would expect me to automatically be a huge reuse champion. However, I’m not. How can that be?

The explanation is very simple: I’m not sure I understand what reuse is. You see, instead of glossing over the meaning of the word and simply riffing on it like most other software people seem to be doing, I have this nasty habit of looking deeply into the meaning of the word, before I hang up a shingle with that word proudly displayed on it (like, a hypothetical “Alex’s Reuse Shop”, for example).

So, I always tend to go for the easiest angle, and look into the real world, common-sense examples first. What is the meaning of reuse in my everyday affairs? OK, the first thing that comes to mind is my chair. I was using this chair yesterday, then I left it at the office and went home. Today, I came back into the office and started reusing this chair.

But wait. In common parlance, this is not how we speak. I’m not reusing this chair, I am merely using it. And I’m doing it over and over again. But notice how despite the repeatability and the predictability, it still doesn’t qualify as being reused.

Am I today reusing my kidneys and my lungs, or merely using them? I know this may sound overly pedantic at a first glance, but it is very important to make this distinction.

Similarly, if I drop a calendar control into my app, am I reusing that piece of code, or using it?

I was using Microsoft Word application to produce a document yesterday. I liked the experience, so today I’m again at it, typing up this document. Am I at this point reusing Microsoft Word?

My intuition is telling me that in all those cases, I am merely using objects and concepts that become available in my daily existence. I’ve never been, so far, in the situation where I was reusing anything.

So the question is: why should my activity of software development all of a sudden be completely centered on some phantom, piss-poorly articulated concept of wishy-washy reuse? Why should I force myself to think that the code I’m writing right now must be able to be reused later on? Is there a real justification for such a taxing burden that’s been thrown upon our meager shoulders?

Why not, instead, simply focus on the task at hand? Try and solve this concrete task that is before me the best I can, without worrying about whether my design will be a good candidate for some whimsical concept of reuse.

As I’ve explained in my previous article, when I’m developing my PowerPoint presentation, I never think of reuse. Never do I stop and think “hey, but what if later on I, or someone I don’t even know, whish to reuse this slide, or this portion of the slide, or this group or cluster of slides?” I could never get bothered by such concerns, and so my mind is free to fully concentrate on delivering the highest possible quality of presentation.

Same is with any other activity. If I engage in explaining to the customer how will our approach benefit them better than IBM’s WebSphere portal approach, I never stop and think whether all or some parts of my present activity will be reusable in the future. I just concentrate on doing the best possible job, and then move on.

Software development should be the same. Shed off any extra taxing burden of worrying about the future that never comes, stop asking yourself “what would ‘…’ (enter the name of your software guru de jour here) do”, and simply do the thing that you’re good at doing.

I guarantee you that you will produce much higher quality code that way.

Excellent press over at news.com today featuring many a friend of lesscode.org. Martin LaMonica’s From Web page to Web platform barely scratches the surface of potential we’re uncovering with the web but it’s enough.

There’s the mandatory O’Grady quote:

Instead of treating the Web just as a handy way to publish information, businesses need to start acting like software companies and encourage programmers to build services on top of their platforms, analysts say.

“The conclusion that many savvy Web presences had is very similar to what software companies have realized with open source: As creative as your organization may be, the community at large will always be more creative,” RedMonk analyst Stephen O’Grady said.

Adrian Holovaty’s chicagocrime gets a mention as well:

Allowing individuals to play with their Web site data has resulted in programs that the companies might never have thought of. For example, Adrian Holovaty, a 24-year-old programmer, built a Web site called Chicagocrime.org that taps into Google Maps to display where crimes occur in Chicago.

I picked up the link from Mark Baker, who comments:

As I’ve said before; Web services? You’re soaking in them!

Indeed.

I’d also like to mention that this article was posted to the Enterprise Software >> Web Services section of news.com, which is exactly where it should be.

I’ve nothing to bitch about today people, sorry.

This chart showing the number of requests for different languages on O’Reilly’s Code Zoo is interesting:

Yesterday we added two new languages to CodeZoo: Python and Ruby. You can see from the language requests graph, above, the languages for which we got more than a few requests (I’ve left off Cobol and the others that only were requested a couple of times). From this, the choice of Python is completely obvious — it was the winner in the request race, beating out C++ and many other languages that might be considered “larger” by other metrics. In addition to the clear demand for it, Python is a natural fit for O’Reilly, since we publish a great deal of treeware and online material about Python, and cover Python extensively at our conferences (especially at the Open Source Convention taking place this week).

Ruby, however, is tied for fifth on the list, and in raw component counts on our site, it is the smallest of the languages we support. As we’ve discussed on Radar over the past few months, we see Ruby as an emerging force in the open source world, driven by interest in Ruby on Rails, and by the excellent books on Ruby written by the Pragmatic Programmers…

I was actually really surprised at how strongly dynamic languages showed up on this chart. I’m eye-balling it as there aren’t any numbers but Python, PHP, Ruby, and Perl seem to have taken down almost 50% of the requests with C{,#,++} taking down a large majority of the rest. Is this a fair sampling of the general development population? Developers with a web/UNIXy background seem to be over-represented at O’Reilly so its probably a bit skewed, no? Still, the amount of acceptance dynamic languages are gaining is pretty staggering at this point.

Lots of people talking about this Meijer / Drayton paper (warning: PDF, sane HTML version here) coming out of Microsoft Corporation. The paper is titled, Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages.

We are interesting in building data-intensive three-tiered enterprise applications. Perhaps surprisingly, dynamism is probably more important for data intensive programming than for any other area where people traditionally position dynamic languages and scripting.

That’s the first part of one of many paragraphs I found intriguing and, IMO, is dead on. Unfortunately, that leads us to the sentences that are meant to support that claim:

Currently, the vast majority of digital data is not fully structured, a common rule of thumb is less then 5 percent. In many cases, the structure of data is only statically known up to some point, for example, a comma separated file, a spreadsheet, an XML document, but lacks a schema that completely describes the instances that a program is working on. Even when the structure of data is statically known, people often generate queries dynamically based on runtime information, and thus the structure of the query results is statically unknown.

I’m not sure I follow the logic here. Dynamic languages like Python, Ruby, and Perl have a more powerful set of data manipulation facilities that require less code and read easier than their statically typed analogs in Java, C#, and C++ but they’re no more aware of the data’s underlying type system. I have a bad feeling they really wanted to go down the same old SOAP/RPC and XML Schema (see: gHorribleKludge) data binding path here and figure out how we can just abstract away the entire concept of data and make everything look like nice little objects. If it didn’t work with our current languages, it must be a problem with the language, right?

Anyway, the paper received a pretty thorough beat-down over at Lambda, which is always a bad sign when you’re talking at the type/language theory level. I personally have mixed feelings on the paper - while I think anything that puts dynamic languages on equal ground with the more accepted statically typed languages is a good thing, I’m not sure that inventing a new peacefully integrated language and discarding the ones we’ve actually observed working for so long is the best way forward.

How about you guys just drop your types for now and we’ll add them back in later. :)

I’m just now getting around to reading John Anthony Hartman’s inspiring lockergnome article: LAMP -Shine On, You Crazy Diamond:

Linux, Apache, MySQL, and PHP, Python, and Perl - a mixture that seems to have moved beyond the fossilized carbon stage. With heat and pressure, it has molded this stack into a beautiful diamond. Linux has grown from a group of tinkering hobbyists to a multibillion dollar industry. Apache dominates the Web server market with an almost three times margin over its closest competitor, IIS. MySQL has over six million installs, and if you include PostgreSQL, its Berkeley DB growth in open source databases is growing like wildfire. This brings us to PHP, Python, and Perl. If you add up the click statistics based on Google searches, these components of the lamp stack make up the largest percentage, supplanting C as the language(s) with the most hits. This also holds true for the most programming jobs that have openings.

There’s no denying it folks, we’re movin’ on up.