note: this is a work in progress only 2/3 done. More to come soon!
It is good! We are saved!
Since 2009 when the world was introduced to CoffeeScript it has steadily gained momentum and in recent months its starting to seem like its become the inevitable progression from current day JavaScript to “the future is here” language of the Gods. By the title of my post you can probably guess I’m, shall we say, dubious of all the sappy love poems that are being written about CoffeeScript. I had been at first interested, then trepidatious and now at times almost seething about all the hype and yes rampant fanboyism growing around CoffeeScript.
But why? Why must I be the lone grump at the party?
That’s what this whole epic post is about so let me first say I’m not trying to be a troll here. I actually have some serious points to make and the first one is we should rightly give huge recognition to Jeremy Ashkenas, CoffeeScript IS a thing of beauty. It works, its a whole new language and yet it compiles down to plain old JS and it lets us try out some cool new language features and syntax, awesome right? And most importantly it is helping many programers love what they do and yes be productive. Even the royalty of JavaScript have nothing but praise: the God/Creator of JavaScript Brendan Eich had this to say when sharing the stage with Jeremy at this years JS Conf in Portland.
“It helps to have things like CoffeeScript out there it isn’t overriding, it doesn’t tell us what we must do but its suggestive, and if we want to pave that cow path we can, and I’m in favor.”
Or how about my personal idol, Doug Crockford when asked about CoffeeScript after his excellent talk on code style at this years TXJS conference in Austin.
“I think CoffeeScript is clearly good stuff. CoffeeScript is elegant it sort of takes the good parts, removes all of the stupid awful syntax that were inherited from the wrong languages, replaces it with something that is small and elegant and expressive. CoffeeScript is really great. And CoffeeScript is having a big influence on the ECMA Script committee….. CoffeeScript is definitely in the right direction and I would like to see future languages looking more like CoffeeScript than like C.”
So what do I really think? I think CoffeeScript’s big selling point of increased productivity is completely bogus because it optimizes for typing fewer characters vs readability when it should do the opposite.
Don’t be that guy
Clearly I had better be careful, I’m treading on very thin ice here… but I can’t hold it back any longer to be totally honest. I hate this designer language bullshit. Ahhh that feels better. Damn I thought this wasn’t about hating, but there I said it. It really is nothing personal against all the people that love CoffeeScript, but I get the feeling that CoffeeScript is just some hipster code for people that like the idea of being great programmers and super efficient at what they do but really don’t have the need for it. But that’s just one jerk’s opinion so go on loving it and using it for all I care.
OK now that I’ve purged the demons lets discuss the actual arguments I have. You may be surprised to note that, in fact, there are many common criticisms of CS that I’m going to skip right over. I have no intention of retreading the old complaints of the “leaky abstraction” argument, or the “compile step is a pain” argument, or the “debugging is a pain” argument, or the “output JS is less than perfect” argument. These complaints, weather valid or not, do not concern me. Moreover this post really isn’t about CoffeeScript at all, it goes way deeper than that. Its about the influence of CoffeeScript on the JS community and the direction of the ECMA Script standard itself. So here are my three arguments.
If you didn’t catch that, what I’m saying is that the following is not attempting to be a CoffeeScript hit-piece its about the direction of JavaScript.
- Stripping characters from the syntax is a false solution to increased productivity
- Overly terse syntax can make code harder to scan and understand.
- JavaScript as a compile target weakens and fragments the community
Ultimately I think the ongoing pursuit of a more perfect programming language is a noble one. Despite the good intentions there are some very disheartening tendencies I see coming out of the ECMA Script standards body and I don’t want to see the language spec itself turned into a dumping ground for “whats hot now in language design.” Broad assumptions about productivity and what the JS community need and want are being made in ECMA Script discussions for the next JS veriosn after ES5. This is where I start to get seriously concerned. So lets address this head on.
What really matters here anyway?
Ultimately the best thing about JavaScript is its amazing community but I’m concerned its getting distracted trying to fix things that are not broken with shiny new syntax and cute language features. (yeah I know you’ll mention all the bad parts of JS now) It feels like all so much newness for newness sake. Rather than diddle with our keywords and curly braces I’d rather see the JS community focus on solving real world problems through the power of our code and our collaborative energies. Lets quickly peek at an example of what I’m talking about, shall we. Take a look at the Github profiles of LearnBoost and its employees. If you know anything about the node.js community then you’ll agree these guys are titans. In particular check out visionmedia (TJ Holowaychuk) a new idol of mine. TJ is a machine! Ask yourself if your organization has been as productive as LearnBoost or if you’ve created 1% of the value that TJ has for the js community and his company. I guarantee whatever the percentage you come up with is, futzing around with the language is not going to make it go up. Note: as far as I can tell TJ is a pretty big CoffeeScript skeptic as well.
Lets unpack our assumptions that are propping up the strong emotions we have around some feature or syntax. Ultimately all this is about being more productive so lets find the best way forward for this conversation that puts the focus where it needs to be. Helping developers ship good code often. (Just a preview: Surprise, surprise, the language and its syntax are not key factors here.)
But Maybe I’m Wrong
Perhaps in a few short years, or months at this rate, someone will come by this blog post (yeah right Ive had all of 5 visitors) and think “ohh how quaint, there once was a day when lesser programmers thought so highly of their decrepit old ways as to question the perfection that is CoffeeScript which has freed humanity from toil and is clearly right and good. Praise be to Eich, Amen.”
Well I guess I’ll just have to be that guy then. I just hope I don’t sound like I’m trying to sell and old outmoded technology like this dude.
Check yo self
Before I get to the three arguments lets first do a little meta-cognition just to check ourselves. We should always be the first ones to point out our own foibles. By always reminding ourselves how we commonly stray from sound reasoning we can hopefully, more often than not, catch ourselves in the act. This is also for those who would suggest that I’m being ignorant or biased in some way that in fact I’m actually trying really hard not to be. Here are three points I have seriously considered over the past week while I’ve been writing this.
First Head Check: - This study found people have a bias to truly creative ideas. The studies’ findings include:
- Creative ideas are by definition novel, and novelty can trigger feelings of uncertainty that make most people uncomfortable.
- People dismiss creative ideas in favor of ideas that are purely practical — tried and true.
- Objective evidence shoring up the validity of a creative proposal does not motivate people to accept it.
- Anti-creativity bias is so subtle that people are unaware of it, which can interfere with their ability to recognize a creative idea.
Second Head Check - Programmers love the language they know and everything else sucks.
- Moore’s Law means doubling in performance every 2 years or so.
- Software is not ruled by Moore’s Law, its ruled by Murphy’s Law.
- We see leaps in software performance in roughly 20 year increments.
- Part of this is due to the generational nature of language preference.
- Programmers (and everyone else) are biased to what they know and love and reject new ideas (see first head check).
- So it takes a whole new generation of programmers to legitimize a new language. A generation that is not encumbered by prejudice and preference of an old inferior language.
Third Head Check- We all want to feel like we are in control and know what is best.
Have you ever worked with that manager or colleague or fellow student that just had to take ownership of everything? You show them something great and new and they have to start hating it right away and put their little fingerprint on it before its good enough. And by fingerprint I mean repeated blows from a sledge hammer. People like this are roadblocks to innovation and getting good work done efficiently. They must feel threatened, disrespected for not being consulted, and from their perspective their valuable knowledge and skills are needed. Ultimately they get their way, preventing change for a multitude of off the wall reasons. They get their way or else there’s high drama and who has time for that? So now innovation has been stifled (or in their minds a fire has been put out) and hey they feel better and “now we can ship!”
Could that be me? God I hope not, those people are really annoying. But resistance to change is natural. If things changed all the time we would just be stuck in perpetual adjustment to the new conditions. And sometimes lack of change is a very good thing. (some people call it stability) One of the best things to happen to JavaScript was the dominance of Microsoft in the browser-wars and the following half decade of nearly zero innovation from them. It left the stage ripe for a dusty and ignored technology, XML HTTP requests, to herald in a new age of software on the web. But we should be farther ahead by now and yet we’re still futzing around with essentially the same web 2.0 widgets. Take a close look. The drastic changes in syntax CoffeeScript brings to the table looks like mere chipping at the edges when you think about what really needs to change to give us the next 20 year cycle of software innovation. Douglas Crockford argues its about distributed computing with the Actor Model and a stronger security framework. I totally agree about the need for better security and better distributed computing. I don’t care how terse your syntax is, its not going to have an effect on these problems.
So head checks complete, lets (finally) get right into the arguments
First Argument: Stripping characters from the syntax is a false solution to increased productivity.
In fact my second argument below is that removing the characters makes the code harder to scan and quickly understand, thus making you less efficient. But lets look at this whole myth of “terse code is more productive because you have to type less.” When did this motive arise in the JS community? I have noticed in a few older videos Douglas Crockford and Brendan Eich asking the audience what they would like to replace the function keyword with. “how about the florin?” Doug asks for people to raise hands. He gets few bites on his various ideas and then relents and asks “no change?” This elicits a big response. What the hell? Where did this crap come from. When did anyone ever have a problem with typing the word function? And now they want to use -> instead because its soo much shorter. Well haaang on there. It jsut so happens that typing “function” is not very hard to do. In fact most IDEs will auto-complete it for you. And yet this is a big deal in the new Harmony discussions? Heres Brendan talking again from the JSConf video I liked to above.
“On more thing that I think I have to talk about because I talk about it at every talk I give which is function syntax. Im still paying for usings 8 letter key words in 1995 I think I took it from awk and ahh heh I shoudnt have done that, I should have used fn and we would have been past this becasue probably two letters is short enough. Um and were using fn in rust at mozilla. But its hard to change and the idea that you would use of a greek lamda which is an actual unicode identifier allowed in ES3 and ES5 or the florin which Doug Crockford suggested but didnt really champion, those don’t really ring true. Then there was a proposal to use hash but I think we want hash for something else and I have kind of come to realize, to be very frank, that CoffeScript has already done the right thing, C# has done this. So I am proposing for the next ECMA Script meeting, and wish me luck becasue it is not a sure thing, that we just standardize this. That what people really want is very sweet short function syntax without that leading key-word and the arrow form in CoffeScript gives us that…”
And then theres this gem.
“It matters becasue keystrokes matter and you see this over time you see people gravitating to lighter syntax you see productivity mattering in the long run even if it is a small win.”
I have a question for every single group of product developers that have a great idea about “what people really want.”
Hey Brendan Eich, I’M TALKING TO YOU
My question is can you prove it? I have a very strong suspicion that of course you can’t prove it. You have two crappy languages that use it and thats enough of an excuse? All to do what? Scratch an itch youve had for a long time to make the language more terse to save on 6 keystrokes? There are actually valuable scanability and readability benefits to having the whole word there my friend and the fact that a vocal minority and a few language dictators such as yourself on the ECMA TC39 panel have a Jones to shorten the function keyword into an obtuse abstraction is a hairs breath away from changing the dot operator to do concat like in php or something stupid like that. THERE IS NO FREAKING REASON TO DO IT. You have given no real reason, just the off hand remark implying (and I paraphrase) “of course its obvious that EVERYONE wants this because it will make us all SOOO much more PRODUCTIVE.” Admit it Brendan you can never give a good reason for switching function to -> let alone one that would warrant changing the worlds most popular and widely used programming language to be less readable. This is because there is no good reason. Its just your language-designer tastes that are waaaay too, well, designer. You’re picking out the European orange leather couches and all we want is the damn roof to stop leaking and the foundation shored up.
In your own blog you call for dialogue intend to listen to the JavaScript community and its “natural leaders”
“JS developers and implementors on TC39 must learn from one another and “meet in the middle”. The Harmony goals are good. But developers may do only what can be done in library code, or reach for CoffeeScript or another language on top of JS. And TC39 may over-invent.
The better way is a dialog between JS developers, especially natural leaders among them such as @jashkenas, and TC39 members.”
How convenient, it must simply by a wonderful coincidence that you happen to be promoting CoffeScript style syntax and Jeremy Ashkenas makes your short list of “natural leaders” in the JavaScript community. I wonder what the jQuery team thinks about all your proposals, or what the node.js committers think about your proposals or what other (I would argue) greater leaders in the js community think about changing the function key word or paren-less syntax. Well have you asked them? I think you already know and are only hilighting the person that agrees with you the most.
OK im done ranting at invisible Brendan Eich now (as if hes going to read this) :-)
Edit: the “invisible” comment was not trying to make Brendan out to be an absente landlord of the language, in fact he is extremely open and available and should be commended for being so.
I am not the only one that is concerned about the direction of JS with all the new Harmoy proposals and the things that are being pushing beyond that. I think I have some bakckup on this in the form of Ryan Dahl. If there is anything like a natural leader in the JS community he is certainly one of the most influential right now. And he counts one of the most vital portions of the JS community as his army. So i was very heartened when Ryan Dahl ripped into the ECMA Scipt committee at node conf.
“I wish ECMA Script woudnt be so ahhh “fancy pants” about adding all these features. We need 64 bit integers, please do that first. Then think about proxies in like ten years or like after we’re all dead. (applause) JavaScript does not need more features it just needs a couple of small things fixed.”
Thankfully Brendan was sitting in the audience for this very panel discussion and eventually got up on stage himself to address the matter.
“Everey tool has edges you need to smooth out so theres more work to do on JavaScript usability. When you look at how its used in Node its a bit different than how its used in the browser. Theres some overloap but looking at Node makes me think more about binary data and even 64 bit ints. It makes me think more about um.. getting rid of the spaghetti monster. The client has solved that a long time ago and it doesnt nest as deep I think, the logic doesnt chain as deep.”
Ok it sounds like Brendan Eich can come around to logic and reason. Cool. We’ve established why they seem so hard up to change syntax, they assert with no evidence that everyone wants it and that it makes us more productive to type less. You’ve got my feelings on the whole everyone wants this BS. Lets address the really important thing here. EVEN IF everyone wanted it, it would still be the wrong thing to do. That is because it will do nothing positive in the way of productivity if anything it will certainly reduce readability and thus lower productivity.
“So what is it that productivity stems from if not typing less?” I’m so glad you asked we can finally get to something actually important. (I told you we’d get here)
This is a very well studied subject matter. But we needn’t go far for good insight, Douglas Crockford has a absolutely fantastic talk on code quality that really hammers it home.
“Programmers don’t understand how they spend their time. They think its mostly typing programs. Mostly they are having technical conversations with collegues or in meetings or staring at the screen puzzeling over the code and problems they have to deal with.
Programmers tend to be skeptical of process improvements that might require more keystrokes.
I turns out that programmers really arent spending much time typing their software. But thats where we look for stuff, “I want an IDE with autocomple so I don’t have to type so much, I’ll go so much faster that’ll really improve my productivity.” I think those particular improvement in productivity are negligible. That’s not where the time is being spent. Programming is now a social activity.
The simplest thing we can do to enhance the value of our codebase is to make our programs more readable. Our ability to read our programs is the thing what gives the codebase value.”
Amen to that!
Updates:
On Harmony syntax changes: I had a short twitter conversation with Brendan Eich and he made it clear that although he wants -> function syntax it is not making its way into Harmony.
On feedback: So at this point in the process I thought I’d air out what I had so far by posting on the node.js mailing list. Interestingly enough Jeremy Ashkenas caught wind of this article and posted my rant on Hacker News. From the comments I’ve been getting most people disagree with me, several making good arguments. This was by far the funniest comment on HN by TrevorBurnham “…made me wonder momentarily if the essay was a work of post-modern art, subversively advertising the benefits of CoffeeScript through an implausible flourish of logorrhoea. If so: Well done, sir.” Ouch! Well what can I say it’s a hasty rant that became a big blog post. I don’t claim to be a language designer or a professional tech blogger. Im just one opinionated jerk that is apparently woefully wrongheadded about this subject. Well lets get this over with shall we.
Second Argument: Overly terse syntax can make code harder to scan and understand.
“What?” You are probably crying out in wild eyed disbelief. “How can it be harder to read if it has fewer characters.” I know what you’re thinking. “It conveys the same data in a cleaner package so we can scan more code, see more of whats going on with less scrolling and fewer eye catching distractions like semicolons and curly braces. Its the epitome of readability!”
Well, some people call curly braces and parens “noise”, but I call them punctuation. I suppose you could consider punctuation marks in a book noise as well. I also think that the word “function” is a better signifier of a function than the more abstract tokens such as -> or #. Is all of this just a matter of subjevtive opinions, individualistic esthetic tastes? I think a large ammount of it is but there has to be something concrete that makes us wince at java or objective-c when compared to JavaScript. I think it is a matter of how easy or hard it is to quickly comprehend the problem and solution embodied in the code. Reading and understanding source code is one of the most important and time consuming activites that programmers perform. So we should optimize for readability.
The basic fact is that we can argue this until we are all blue in the face becasue we have no objective way to grade one language or another. Hence we have what seems to be a resonable if automatic, positive response to reductions in syntax. The assumption is that if one language is easier on the eyes as it strips away boilerplate and verbose syntax then it follows that another must be better as even more things get stripped away. Now, to be clear, I am speaking purely in terms of the visual effect of the language on our ability to comprehend the code as written. There is an unquestioned assumption that less syntax is, esentially, always better, with apparently no point of diminishing returns. This view implies that the visual nature of code is that it gets more readable as it gets more terse. Well, I’d like to question those assumptions. Because they imply the point of code is to take up as littel space as possible but thats bogus. I think the point of code is to enable people to clearly express and understand a range of complex computational processes. Hopefully that computational process is solving an actual problem and so it should help you understand the nature of the problem and the nature of the solution employed. Thats a lot of responsibility and I think the visual/spatial nature of code is essential to fully succeeding at that task.
I think some code will help express the point.
// #6 Filter list of numbers into two categories.
// from http://ricardo.cc/2011/06/02/10-CoffeeScript-One-Liners-to-Impress-Your-Friends.html
passed = []
failed = []
(if score > 60 then passed else failed).push score for score in [49, 58, 76, 82, 88, 90]
// roughly equivalent in js
var passed = [],
failed = [];
[49, 58, 76, 82, 88, 90].forEach(function(score) {(score > 60 ? passed : failed).push(score)});
// or more verbose js with more visual/spatial structure
var passed = [],
failed = [],
score,
scores = [49, 58, 76, 82, 88, 90],
cutoff = 60,
i = scores.length;
while (i--) {
score = scores[i];
if (score > cutoff) {
passed.unshift(score);
} else {
failed.unshift(score);
}
}
Of couse anyone can pick a piece of code to make a point about one language or another. So the above code is purely to express the concept that there can be meaningful spatial information present in code.
This is a murky subject but there is some research in the area. In my short research I did find some interesting papers that address the spatial nature of learning to program[1], code navigation[2], spatial cognition[3], code scanning patterns[4], and An Eye Tracking Study on camelCase and under_score Identifier Styles[5]. There is good evidence to correlate cognitive spatial capability with ability to learn programming. There are common explanations of how programmers comprehend code. All of the papers refer to various concepts of building mental models that are spatial in nature.
There are also notions of Beacons which are…
“sets of key features that typically indicate the presence of a particular data structure or operation in source code… Meaningful variable and procedure names have been described as Beacons. The swap operation has been shown to be a Beacon and to be beneficial in comprehension as well. ” [4]
I have to concede that this is a purely academic discussion at this point. But it need not be. Language developers should seek methods of validating their theories and motivations as they develop the spec. The studies I cite point to some interesting avenues like gaze-tracking to get deeper insight into the process of reading code and building a mental model of it. This technique is really hot right now and I think it can have some value to language designers.
However much of this scientific approach to things sounds good but the results may be very context specific. It’s clear language design is very much and art and a science.
None-the-less I believe we need to improve our understanding of the visual effect of a language and its syntax on our ability to efficiently build a working, mental model of the program as we read the code. I’m self-trained in programming, my education is in, of all things, fine art and design. The design background serves me well in the world of web design. But part of it beacons to point out that the visual effect of code, indented, with its various syntax hilighted tokens exists every bit as much as a visual entity as a textual one. I think this aspect of code is well worth discussing and researching more. I have a colleague that meticulously picks the colors for his light on dark theme for intelliJ. Its a thing of beauty. I don’t think there is a developer out there that would argue the value of syntax hilighting. The colors obviously help us to see the structure of the code more clearly and thus build that mental model of what we’re dealing with. I argue that so too the effects of syntax and key-words by their very shape, and the visual patterns that emerge in a page of code, plays a similar role. It can help us to build an understanding of the code purely by means of visual cues.
A great way to test this theory for yourself is to spend some time reviewing code samples over at Rosetta Code.
The site exhibits solutions to specific problems in as many languages as possible. This is a fantastic resource to get a feel for the relative visual qualities of various languages. Look at the code as a visual structure, gaze at it and try to see the meaning of the code first with an eye toward the spatial relationships then by reading it intently. As you read it think of that mental model you’re trying to build of how the code works. Is the visual structure of the code doing you any favors or is it adding a layer of complexity to things. If the two reinforce each other I think that is a sign of a better piece of code. It will probably be easier to understand and maintain long after it is initially written. Now remember this is not purely about syntax, its about the visual quality of a piece of colorful, very structured text. Take a look at the csv to html translation problem on rosetta code.
This is a very strait-forward problem with a very simple solution. Go ahead and compare your favorite languages, the JavaScript example was submitted by yours truly :-) Its based it on the CoffeScript example with some modifications. Lets look at two samples.
So what criteria makes one solution more comprehendible, in less time, than another? Obviously familiarity with the language plays a huge role. You can clearly argue that lines of code and clean syntax have a fairly profound impact. But once you get beyond that I think other aspects become important as well. I think the visual/spatial characteristic of the code as it is written can make a meaningful impact our ability to chunk up a program’s logic and constituent parts into a working mental model of the software. Code is written for people not machines. If it were then we’d all be typing out binary or assembly. But as Doug Crockford says “we’re not trying to be E.E. Cummings here.”
Argument 3: JavaScript as a compile target weakens and fragments the community
