lesscode.org

I thought it unfortunate that the controversy kicked up by a few (now retracted) passages in Brian Fioca’s article about WASP detracted from a proper discussion of the article’s real flaw. I addressed the controversial, less interesting sentiments in comment over there, but wanted to take a few moments for a longer commentary. It took a while, but here we go.

The true failing in that article is a terminal case of corporate-management world view. Let me quote a little out of order to highlight this:

Sure, you can write spagetti code in PHP 5, but if you have a well designed framework that keeps PHP code outside of your HTML and in tightly structured classes, you’re more likely to end up with code that looks and works and feels like Java.

The implication appears to be that anyone in the real world, if only they’re using Java, writes well structured and maintainable code.

I think the real world has a few surprises in store for people who think that way. As the saying goes, real programmers can write Fortran in any language.

Deemed “hacker” languages, scripting languages can be quick to write, but since they do not have many of the advanced features of compiled languages like C++ and Java, they have been prone to lax design practices, leading to code that isn’t efficient, stable, or maintainable enough for large solutions. With the correct mindset and help from structured frameworks like WASP, this no longer has to be the case.

This claim is a crock. PHP has a very low barrier to entry; consequently, a lot of eye-wateringly bad programmers are writing code in it; hence, a lot of code written in PHP is awful. This is arguably a good thing: a lot of people who have small needs are empowered to meet them on their own despite having little skill, which would never happen if Java were the only option available.

To conclude that if these programmers did learn Java, they would suddenly turn out maintainable code, or that if a good programmer changed camps from Java to PHP, the quality of his code would suddenly degrade, is fallacious.

Again, you can write pretzel logic in any language.

Until recently, platforms like Java were more likely to provide a stable, proven foundation to design and build well designed code, however by their nature they introduce a level of complexity that takes extra time to overcome.

The entire “more likely” clause is a myth, perpetuated by a middle management population that has absolutely no clue whatsoever what makes code good.

Using scripting languages like PHP tended to produce code in a faster time frame, but it was often impossible to maintain the architectural integrity necessary for building maintainable, extendable applications.

This is true – in an extremely local sense.

The overall design of large Java systems will tend to be more convoluted than that of almost any system written in a dynamic language, simply because the contortions forced by Java require larger overall designs.

Java buries the intention of code under a thick layer of implementation details and typing bureaucracy. Programmers are drilled to execute the requisite gruntwork in repeatable, predictable ways. Moreover, doing so conditions them to design their own system to cater to these reflexes. A maintainance programmer who comes in later will therefore easily be able to make changes to the mortar of an application. Unfortunately, that does not ensure good high-level designs nor does it translate to easy refactoring of convoluted architecture.

Dynamic languages abstract away huge swathes of gruntwork and require less structure. This means small systems have small implementations, which directly translates to better maintainability. The price is a loss of exemplary structure and of conditioning, which requires better innate architectural skills and stronger discipline when building larger designs; neither are strong points of the average programmer. However, designs in such languages aren’t frequently large, because the language does not require large architecture for modestly sized systems – which the majority are.

I have seen as many examples of truly terrible designs in Java as I have seen examples of completely unreadable code in Perl. Maintenance problems may manifest in apparently different ways, but their cost does not degrade appreciably when they afflict a system written in a “more maintainable” language. The only objectively measurable difference is in the amount of required code.

Why would you want to stick with PHP even in situations when you can use Python, Ruby, or anything else?

Simple. Because it’s cheaper to hire programmers that can write code in PHP. And if you have a good technical lead and a well implemented framework, your cheap programmers are going to pick it up and run and write good (and maybe even less) code.

(Brian writes this in a response in the comments, not in the article.)

This is a fear-based middle-management hiring strategy. Good developers know that “cheap programmers” will never hit the high notes. You can hire 100,000 code monkeys and they will never produce the same quality as 5 stellar programmers.

All these quotations are pervaded by a disregard for the fact that programmers are craftsmen; for the fact that that the language, framework, and whatever else they use in the course of their work is a tool. Good tools matter, but the stated opinions read as if the programming language is the principal factor in the quality of the result, when the truth is that it’s the programmers who ultimately matter.

If you hire good programmers, maintainability won’t intrinsically be affected by whether your in-house software development has standardised on Java, PHP, Perl, Ruby, Lisp, Smalltalk, Haskell, or Self. Good programmers can appreciate and can create good design regardless of language, and they can absorb a new language easily enough. Or as Joel Spolsky says:

I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.

But whether your system is written in Java or an exotic programming language, every single programmer you hire will have to get acquainted with its architecture – which is hence the major factor in its maintainability. Comparatively, the chosen language is barely more than a neglibility, assuming it has a good impendance match with the type of application being written.

In thinking about this issue, I am in fact tempted to recommend that you hire programmers who are unfamiliar with the language your system is written in – because if they still struggle with the basics of a new language after a month, you might want to reconsider their future with your company. But that may be too bold a claim. Even if, in lesser form, it has been made before.

The bottom line is that you need people capable of producing a clean, flexible and only-as-complex-as-necessary architecture for the problem they were tasked with solving. And you won’t get that from an army of code monkeys, even if you hire 1,000,000 of them.

I’d like to offer several snippets collected from the recent discussion threads on programming languages (regarding conciseness and verbosity). One person wrote:

The important point about verbosity is not the time you spend typing: it’s about how difficult it is to read and understand the code.

To which the other fellow responded:

And verbosity makes code easier to read. I don’t have to know anything to understand the code. Everything I need to know is there in front of me.

Now, that’s an interesting way to look at the problem of understanding the code. Would you agree that the more verbose the source code is, the easier it gets to understand it?

Finally (and inevitably), the sacred cow of corporate computing (Java) is dragged in to demonstrate the benefits of verbosity as a feature that encourages reusability through increasing the level of abstraction:

The verbosity of Java code also encourages developers to implement more abstractions and reusable components. The ease of coding in some languages often results in more code, in my experience. It’s easier to just write more code than to stop and think about reusable solutions. In Java and other verbose languages, ‘coding for the moment’ is a losing strategy.

Interesting stuff, innit? Do any of you guys agree with this, or have comments to offer?

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).