I have a vivid memory of watching the David Lynch movie Eraserhead where towards the end I finally turned to the person next to me and we both slowly voiced the phrase “what was that?”

I had déjà vu recently when I waded through the announcement on Google’s Closure compiler and library for JavaScript. Had I just walked into a David Lynch movie set on planet Google? Had somebody just pulled a Gordian knot tight around me? If so, with what razor could I cut it apart?

Some smart people have chimed in on the side of Google and spoken poorly of a number of common coding techniques for JavaScript programmers with Crockford’s module pattern being one example. Their complaint? That modern techniques employed by JavaScript coders were inefficient…

Dmitry then had a look at some of the Closure source code and pointed out that compilers aside, some of the coding techniques used in Closure are inefficient for JavaScript.. and that some others are just plain silly. Borrowing a phrase from Dmitry… I don’t know what they call that in Java, but I call it irony.

For the record, and to clear up any potential ambiguity caused by my often circuitous writing style. I agree with Dmitry. Other libraries such as jquery may have their issues but the design of the part that people interact with (you know, the API) is overall something other libraries would, for the most part, do good to emulate.

I had a look through the source for closure myself and whilst there’s some useful stuff in there it feels a bit like a bag of nails and is about as inspiring as one. Slider examples that use 44 different individual scripts (I’m sure the compiler fixes that right?), a unit testing framework apparently from 2009 shoehorned into code apparently written in 2004 (better late than never) and a bunch of things that really don’t seem like they belong in a decent general purpose library such as pretend constants like the one for the default size of a popup window and finally some stuff that really shouldn’t be in any JavaScript code anywhere, such as != 0. Now, there may be good reasons for these and I’m not questioning the coding ability of the people who wrote it. Instead, I’m questioning the extent to which they might still (if they ever did) consider themselves JavaScript natives. Most people coding in JavaScript stopped writing code the way suggested by the proponents of the closure compiler years ago because we were sick of fighting the language. Dmitry is one of those people and library authors should pay attention.

What bothered me about Closure more than anything though was the (apparent) accompanying mentality that they know the right way to do things and that other JavaScript programmers are living in the dark ages banging rocks together. Still, I shouldn’t be that offended that somebody has a different idea about how to write good code… and yet, there I was…

What was it that bothered me so much?

The real thing that pissed me off is a suggestion that I should write worse code to optimise for their compiler. Last I checked it was 2009 and I gladly wrote my last malloc more than ten years ago. If the interpreter or compiler wants to run better then somebody ought to fix the compiler. I’ve had enough IE6 for the last eight years to know that having to tailor my development approach to a computer, instead of to a human is nothing but pain from start to finish and that worse… spending all my time looking inwards to the computer instead of outwards invariably results in a crap user experience for the people that really matter - my users - whether that’s coders I work with or who inherit my code or users of the UI that I’m writing.

Some of us who work in JavaScript every day are trying to improve JavaScript and the coding environment to make it better. We all want to make JavaScript suck less… these other guys (yes, I’m deliberately phrasing this divisively), they’re trying to make the language suck more by making JavaScript developers kowtow to their compiler. Or worse, by making people write Java that compiles to JavaScript… but that’s a story for another day.

Pseudo-classical inheritance simply doesn’t make sense in JavaScript. JavaScript works better with object cloning, mixins, shallow (think wading pool) hierarchies, literal notation, and closures. Trying to do elaborate inheritance in JavaScript generally ends up in dog shit. I know because I’ve stepped in it.

It would be nice to get some more of Self into JavaScript… in other words, it would be nice to have a better prototypal system with dynamic inheritance and traits. I would need to see the associated complexity tax tested first though as I’m not sure if the language can float those but perhaps… and perhaps multi-methods, perhaps macros… I’m not sure, I’ll leave that to the language designers.

Anyway, it would not be better to get more of C++ into JavaScript. People absolutely need to remember that. The world has moved on.

Yes, personal preference but… Friends of Closure, please stop telling people they’re doing things wrong because based on your development style and using your compiler your way works better for you.

Finally… just to really nitpick, the name really blows. Both because the library doesn’t feel especially functional and because it sounds too much like the completely awesome Clojure language…

String.prototype.split with a regular expression has for a long time generally been stuffed across the major browsers. This has been documented before, Steven Levithan even has a nice replacement available.

Whilst there are issues in several browsers, the biggest pain-in-the-butt award though has to go to… wait for it… IE.

Why does "...".split(/\./) not produce the same result as "...".split(".")?

I know the old ES3 spec had some issues but really… aneurysm inducing stuff.

Anyway…

The recent release of the source code for the Lunar Lander had me thinking about the relative value of code and whether programming has really advanced much in the last fifty years in terms of what people are actually achieving with software. How far have we come?

I’m probably like most “modern” programmers - when I looked at the source code for the Lunar Lander I was simultaneously astonished, horrified and embarrassed. My single adventure into the land of assembly programming left me with painful memories of hours spent writing and testing hundreds of lines of machine code for the Motorola Z80 in order to get a speaker to beep. Writing assembly code is painful. How on earth did programmers manage to write assembly code to send man to the moon?

Reading this interview from Allan Kump managed to shed some light on it for me. The Lunar Lander module code was designed by about 300 people over a 7 year period for 46 million dollars in 1967. This puts the apparent pyramid building feat of the LM into some perspective. They succeeded because they had to. It took a great deal of time, money and people to succeed.

Even then, I might question how they managed to achieve what they did without modern development techniques and engineering practices… or a drawn out beta period. How did they avoid bugs? How did they manage this task without a higher level language.

I don’t know much about their development process. I don’t think I need to and, really, I don’t find it that interesting to ponder. How about the question of bugs and no higher level language? Well….

Firstly, they did write it in a higher level language which they hand-compiled to the machine code and secondly the code was never bug free and at least one of those bugs could have been catastrophic.

However, it still disturbs me that in fifty years, we haven’t really come all that far. 1967, what else happened in 1967?

A fully mechanical ABS was in the Ferguson P99 (Mercedes had the first electronic version in their 1978 S-class).

Not that interesting. What is interesting though is this: Lisp was first specified in 1958.

You know what McCarty said about Lisp?

“Lisp will become obsolete when someone makes a more comprehensive language that dominates Lisp practically and also gives a clear mathematical semantics to a more comprehensive set of features.”

Note that it says obsolete, not untrendy.

I don’t want to get into debates around the why of Lisp not particularly been a popular success but it was first specified before work commenced on the lunar module. Would it have been a good idea to design the lunar module in Lisp?

The answer, I think, is no.

Why? The designers needed to keep touch with the input, output and with the system that they were interfacing. I don’t know how this would be achieved in Lisp at the time. I have no backing evidence for this but (this is the web and I’m writing on a blog so hey, I don’t need any) I’d say Lisp would not have been very close to the problem domain the developers were working in given that they ultimately had to hand compile it down to machine code.

What if it was 2009 instead of 1967 though? What about finding 300 developers in 2009 to write the Lunar Lander control module? What language?

For 300 developers today, chances are that Lisp still wouldn’t be chosen, or any functional language for that matter. Parentheses aside, cultural issues aside, accidents and convenience aside - the thing is that really, most developers simply do not grok the concepts at all…

I’ve been looking at some legacy code recently and the same old pattern has emerged there as I see everywhere else. The list of things that many developers seem to understand sufficiently to be comfortable using is about four things: SQL, procedures, global variables, XML.

For front-end developers just replace SQL with CSS.

Either most developers only know those things or most developers simply feel they can solve any problem with that magical quartet. Well yeah, they probably can solve all their problems with that - in a completely non-flexible, non-extensible and generally kludgy manner. Nobody cares though right? It’s all abandonware anyway, somebody will come back in ten years with an even bigger budget and redo the whole thing again exactly the same in a different system but this time use thirty times the CPU as last time.

Lisp (or another functional language) is simply too hard because it’s almost impossible to write the kind of really ugly, shit code that I know - because I’ve seen it - exists in too many code bases for legacy and modern systems written, in many cases, by decent programmers. Sure, it’s possible to write another sort of rubbish code but in my experience people who are going to write rubbish code aren’t bothered to learn clever ways to do so… The most basic features of the most accessible language will do just fine.

The solution to the nobody gets it problem, according to some pundits, was going to be Object Oriented programming. I’m actually quite confident that to a large extent that was a massive success. Why? Because, despite a bit of initial confusion it seems that a greater percentage of developers than are able to grasp other composing techniques are able to grasp the concept that instead of having lots of procedures they can partition their code into… ummm… things and attach procedures (methods) to those things/objects. Not making great use of OO but it’s a start.

Even given that, too many developers will still code by creating a bunch of procedures, initiate them from a starting point and pass any shared state they need to via whatever global mechanism the language allows. Why? Because it’s easier and they don’t need to know much of the language to do it. This is a curse that has struck many languages. JavaScript, meet the curse. Curse, meet JavaScript.

Going back to the legacy system I mentioned earlier… What is the dirty, horrible barbarian language it was written in? I’d rather not say, but… it has lambda (hand-waving version at least) among some other nice language features that help to compose software. Sure it’s got some oddities but… It has lambdas!

Perhaps this is the same tired old story paraded around but really; this legacy system might as well have been written in any language if… and only if, that language was used for nothing but lots of (basically) global procedures and variables. The developers (or most of them) had a language with some expressive power and they used none of it. Again, reminds me of JavaScript. At least JavaScript stopped short of letting people ram most of their code into SQL or XML… No wait, somebody figured out how to do that in JavaScript too.

So the new, non-legacy, replacement system is written in a modern Object Oriented language. I haven’t looked at the code base but my bet is that really it’s only Object Oriented as far the developers were forced to code in a (kinda) Object Oriented language. The attention in the code to actually doing Object Oriented is probably only as much as the developers are baptised members of the church of Object Orientation and they’re really scared of being excommunicated. Oh sure, there’s probably a bit of a perverse bastardisation of MVC shoved in there somewhere and they might map objects to the db and they probably have lots and lots of middleware and instead of a custom configuration script conjured up by a developer there’s probably nine hundred XML files instead but… you get the idea.

Of course, what the new system has is libraries and API’s ready to go that reduce the amount of actual code that any developer on the current system has to write. Now, instead of learning a language and how to program effectively in that language there’s a tendency for people to learn the language basics and then refer everything to an API that serves as a tourist dictionary. Of course, there’s more than one API and these language tourists are walking around with a bag full of dictionaries trying to communicate. This has nothing to do with the merit of one language versus another or the incredible usefulness of well designed API’s… It has everything to do with tools being applied where they should or being used as a crutch for an unrelated deficiency.

How far have we really come? I wonder.

Ever noticed how C presents with some immediacy those language features that are the first to be learned? Hello World. My Name is… Count to ten.

There are many powerful mechanisms in C and many more powerful language constructs but fundamentally the simplest of programmers really only groks just enough of a programming language to get around as a tourist. Oddly enough, the popularity of most programming languages is independent of their actual merits and most closely tied to how easily a tourist is able to find the nearest public toilet.

Perhaps because of this shortcoming the general approach over time seems to have been removing the language aspect of programming as much as possible. Given that developers are not capable storytellers in the programming language they have to use a whole heap of effort goes into IDE’s and tools by which developers are able to avoid writing programs. So great was the extent of this that the era of GUI programming came about in many arenas from WYSIWYG to a misguided hope that one day developers could create UML diagrams and have a large proportion of their code written for them.

That was the dream. People would go to the nth degree to model everything and design everything up front and the handle got cranked and out popped a UML diagram. The model would be run through a model checker and then the handle would get another crank and out popped all the code nicely done. Application finished.

Then what?

Then it’s discovered that nobody can use it because the “developers” were too busy navel gazing to check at any point if the original specification provided something that anybody could use… assuming anybody even wanted anything like it in the first place.

I think it is a mistake for anybody to think that programming is purely an exercise in symbol manipulation with developers sitting in their Searle Chinese Room translating symbols from one representation to another.

Actually, I don’t think it’s just a mistake. I think it is exactly the wrong idea. The removal of emphasis from language is wrong. Humans are good at language, exceptional at language, but instead of applying that linguistic ability the trend was towards making people push coloured blocks around a page as if the extent of their creative ability was on par with a parrot such as Alex.

Alex can’t tell stories. Programming is about telling a story.

Good programmers have a concept in their head about the software they’ve written, a narrative through a story told by the code they have written. Code smell? It’s a result of a poorly constructed story, a bad plot, wooden dialogue.

Programming should be a linguistic activity, it should be a craft and it should have a design component. A good program should read well and be entertaining all by itself. It makes absolutely no sense to me that anybody would want to remove the language component for programmers unless we really want to start using parrots to do software architecture… pushing those coloured blocks around and churning out software.

As for that Lunar Lander… I bet every single person working on that project was excited to be working on a system that was involved in sending humans to the moon. That’s a pretty good incentive for making sure it works regardless of what it was coded in.

Anyway, apparently they built the pyramids without any computers at all. I sure bet they had language though.

Instead, I decided to write something that’s barely related to JavaScript because, well, if I don’t write I quickly forget how to write - to point where I’ll spend ten minutes composing a two sentence email only to delete and never send it because it didn’t make sense. Anyway, here goes. I’m breaking a few rules in the following text so I can only hope the reason won’t be lost in the reflection.

In order to pay the “bills” during my years at university I used to tutor high school Maths, Physics and English. At first the syllabus for each subject was fairly close to what I’d been through myself but as each year passed I noticed bizarre things happening to each subject as they were morphed into things I barely remembered until eventually every last equation had been removed from Physics and HSC English students started telling me they were studying Blade Runner.

Truth be told, I don’t really like maths all that much (many years since leaving uni it’s still possible to give me a mild panic attack by asking me to calculate an autocorrelation coefficient) so I could probably have done without tutoring HSC Maths. I did generally enjoy tutoring English though.

The first lesson with a new student was always interesting. Generally it would begin with a fifteen minute chat with the parents - a chat that would tell me nothing about the student except that their parent had absolutely no idea what their children were doing at school. I’m not much for making light conversation but the preamble seemed important in making the parents feel comfortable and involved and they always liked it when I told them their child was talented and capable of doing well in English but had never been taught how. (I also had to teach some of the kids to spell despite the parent assuring me it wasn’t necessary because, you know, computers meant nobody needed to spell anymore.)

The student would be ready with the texts they had been assigned for the year and a stack of notes given to them by their teacher. That stack of notes would invariably contain a few sheets containing quotes that the teacher thought students were supposed to learn. For every student that I tutored though, there were only really ever two problems that needed work.

The first was that all-too-often they hadn’t actually read the text, or if they had read it they hadn’t taken the time to understand it. The solution to that was fairly easy. Tell them to read it and come back the following week promising to do nothing but sit there for an hour whilst they explained the text to you. It’s amazing what most people will do to avoid an hour of awkward silence.†

The second problem was the important one. Every single person that I tutored HSC English to had absolutely no idea how to approach composition. It might have been tempting to think that they had no idea how to write effectively because they had missed that day in school but that wasn’t the case. I don’t know if it’s been different in other times or other parts of the world but most of what these kids learnt at school was about turning up in the morning and sitting at a desk all day.‡

These kids, or teenagers, had no idea what they were supposed to write except that somebody had told them that they needed to produce something called an essay with an introduction, body and conclusion and that they should litter it with the quotes supplied in the relief package. These essays were terrible, starting with “In this essay I will talk about” and rapidly declining from there.

So, I would spend one hour telling these kids how I approached composition (not sure if that part helped) and then assigned them a truck load of writing exercises which we’d look at the following week.

The writing exercises worked.

I don’t know if any of those former students still write anything longer than an SMS but the impact of seeing smart kids with valuable ideas completely unable to put them across on paper has always stuck with me.

I think writing matters. More importantly I think good writing matters. I also think that like most of the things I grew up with it will eventually be put through the photocopier enough times that only a surgeon’s photo will remain. I think that’s a shame.

I think writing matters and that’s one of the motivations for spending the time to write (and rewrite) the posts on this site. I also think it helps me extract my mind from programming flatland… though I have little supporting evidence for that one.

Anyway, finally to the point. One of the great things about the web for me has always been that it gave more people an opportunity to explore and express the ideas they had to an engaged community.

I may be subscribing to the wrong sites but watching the declining quality of posts in my feed reader doesn’t seem encouraging. The number of link blogs, top ten lists, twitter summaries, spam, trolling and product whoring seems to be steadily increasing. I know some of these things have traditionally been considered synonymous with The Internet but for a while there it actually seemed like there was a lot of effort going to producing quality writing. Am I still looking at originals or is it all photocopies? Do people still write or is it all just out takes, bloopers and greatest hits? Does anybody care?

—

* There is actually at least one built on Helma used on reasonably high traffic production sites such as blogger.de but I am conveniently choosing to ignore them for the moment. ↑

† In hindsight there may have been some motivation in not wanting to pay me to sit there for an hour and do nothing. Hard to say. ↑

‡ I don’t mean to criticise the education system for teaching kids these two things as they are as essential for keeping a job as brushing and flossing are essential for keeping teeth. ↑

Anyway, I’ve written a fair amount of CSS in my time. At least, I’ve written enough CSS that there’s a chance that I’m partly responsible for the great wad of legacy CSS that you hate working on every day.

If I might quote Toad from the claymation movie version of Wind in the Willows…

I’m not sorry so it’s no good saying I am.

At one point in time a front-end developer working on legacy code would be staring at a vast sea of nested tables created by a tool such as FrontPage - trying to figure out where in that sea they needed to add their code such that it won’t cause the layout to barf table everywhere.

These days it’s just as likely that a front-end developer will be working on legacy code and be starting at a vast sea of my CSS trying to figure out what last-minute 2am bug report had prompted the use of so much “!important”.

Actually, it’s worse than that. These days it’s just as likely that as a front-end developer you will be working on a vast sea of your own legacy CSS… written only three months ago. The thing with CSS is that most of it is legacy as soon as it’s written. This is not a criticism of people writing CSS, I’ve seen people with good ideas put a lot of thought into the best way to maintain CSS with good results. I just don’t think CSS is really helping those people solve their problems.

Let’s say that you decide to write new CSS to replace somelegacy code. What’s the usual approach?

Start with a blank file, insert standard browser reset code and off you go.

I can’t think of another coding discipline where even proficient, thoughtful coders achieve so little reuse from project to project.

Now, in the time since I last wrote any large amount of CSS that somebody else has had to work on, I’ve seen a lot of promises about the latest trend in writing or organising CSS. Indent it this way, indent it that way. Put these comments in. Group by specicifity. Group by function. Break it down this way. Break it down that way. Make it Object Oriented!

Yup… I heard that news about using component based architecture for CSS. Component based architecture makes a lot of sense. I still bet the next time you work on a completely new project you start with an empty file and CSS every single line from go to woe without reusing more than half a dozen classes from the last project you worked on.

It’d be nice if a component based approach actually resulted in front-end developers being able to compose a new site from an existing set of components. It’d be nice if there was, I dunno, meta-CSS.

Unfortunately, I can’t see that happening. Instead, it seems that some front-end developers love writing CSS selectors so much that the only thing they wish to change about that particular 4GL is the lack of variable spaghetti to add to their CSS minestone. I don’t think variables would help.

It looks like developers love those selectors so much that they’ve transported them and the development technique wholesale to other places such as JavaScript where instead of ever writing an abstraction or component themselves they start with a blank file, a selector engine and… well, you know… potato programming all the way. It looks like that because it is like that. The reason? CSS encourages it.

Just like SQL… Just like XML. CSS - and the attached mindset - seems to be one of those things that’s frequently over-applied and relied on too heavily in places where it either doesn’t belong at all or should only be a small component. There’s nothing wrong with supporting XML in a programming language but there’s definitely something wrong when XML becomes the programming language. Similarly, there’s nothing wrong with supporting CSS selectors in Javascript but there’s definitely something wrong when CSS selectors become the programming language.

Some may disagree, but I think that as a developer, I shouldn’t be trying to make everything else look like what I’m familiar with… instead I should be trying to make what I’m familiar with better. I think CSS could be better and I don’t think much more ground can be gained whilst the language remains as it is.