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
Hi, I’m the author of one of these “love poems”. I feel sorry for having contributed towards this “Here are ten reasons why your language sucks” or “hipster-code” mentality.
I am a Javascript programmer at heart. It is the main language I work with everyday. The reason I use CoffeeScript is the exact opposite of your second argument: I think it makes code easier to read, write and reason about. It’s still javascript in my mind, just a little higher level syntax. Comma-first and semi-colon free javascript would make me half as happy, since libraries like underscore provide most of the sugar, but for some reason people dislike that much more than coffeescript. I’m all for better looking code, you know what benefits come from that.
Things like auto-completion are mentioned as making the typing advantages moot, but you can’t deny that auto-complete, brace matching etc. are kludgy. It’s nice not having to even worry about stuff that doesn’t matter. The argument of increased productivity is often linked to the syntax, but in fact it’s more about the abstractions provided (comprehensions, ranges, operators, etc), that I believe end up bundled in “syntax” in most discussions.
This is one of the greatest achievements of Javascript: https://github.com/jquery/jquery/blob/master/src/deferred.js. Just look at it – it sucks.
Higher-level syntax. What the f*ck does that even mean?
Sentence punctuation marks?
Really?
You’re comparing the simple: !? to semicolons and curly braces?
Also, a semicolon is nothing like a period. A period is necessary in prose because each statement does not correspond to a line.
In code, or poetry it usually does.
Sorry bro im still brewing the rest of this post, as we speak :-) what you see is a work in progress that was a note to myself, dunno if it has much bearing with where im going with it.
Fully agree. I’ve tried out coffeescript and i really don’t see the productivity gain there. Plain old JS is great if you really understand how it works.
Could not agree anymore. Let the hipster backlash begin!
An equivalent argument:
Square brackets for array access is a mistake. That’s just adding syntax to the language to save a few characters of typing.
Let’s do everything through a function instead. This would clearly be a better way of accessing arrays:
someArray.index(12)
The argument isn’t that fewer characters saves typing; it saves time reading. Common operations shouldn’t have verbose syntax because that’s just introducing noise into the language.
Also: identifiers should be variables. “function” is not: it’s part of the language used to construct a in-line literal. We have curly braces for object literals. In most languages we have square brackets for array literals (and we should in Javascript). Similarly, we should have a concise syntax for a function literal. This is easier to read because you can scan the code and not have to parse the word to distinguish it from a variable.
You are not alone.
+1
CS doesn’t bother me, but is just a sideways move, I really can’t see the point. I mean, I’d understand if it was PHP, which is a mess and quite vast, but JS is a compact language. All you have is functions, objects, and the prototype chain.
What bothers me slightly is the fanboysm, CS fans are like the Hare Krishnas of the web development world. I fully expect because of it the ECMA Script committee will adopt some of CS’s features in an attempt to keep the ‘hipsters’ on board, that’s how these things usually work.
I am no JS developer and came across CS only recently so maybe me not getting your arguments is because of my lack of experience.
But tell me, isn’t var myfun = function(a,b){…function code..} just a lot of unnecessary syntax. You and I might be used to isnt the above code simply saying myfun(a,b)=..function code..
What is the reason to have “function” written out there or all those curly braces. And semicolons, well who needs them anyway. Most programmers anyway indent their code.
Another thing I liked with CS was that an array can be deconstructed while assignment.
And whats the deal with having () around if conditions? If an alternative allows me to remove that then I will surely give it a look.
And array slicing and splicing. How cool a feature is that to not have?
List comprehensions?
Of course, none of the things mentioned above are shiny new. They have been there in various languages for long.
I must say that though I am not a JS developer, I have great respect for the language and its design.
I may be wrong with some of my points above, correct me if I am wrong.
all valid points :-) if you’re writing a new language. When you’re making changes to the linga-franca of the web like changing function to -> I think its really hard to argue for those changes that are backed up by little more than “I like it.” You ask why do you have to type it (“function”) all out? I could equally ask whats the benefit of -> instead? Compression? Efficiency of coding? Nope and nope. It’s just a matter taste and possibly fad. “Shiny new” was in reference to new to the language itself. I have not actually lodged complaints about many of the other specific language features you mention. Moreover this post is a bit of a rant at the seeming unquestioned agressive language updates being pushed as a whole in the Harmony spec and beyond. For example there are discussions of -> for function and a variation of a function that is more strictly defined (frozen) using #. That along side function for reverse compatibility leads at least 4 ways to create a function (including traditional anonymous and named forms) individually they all seem logical additions but I wonder if there is point of diminishing returns. Also terseness does not always == more readable. I will get into this soon with my next update. Stay tuned :-)
Quoting SICP: “Syntactic sugar causes cancer of the semicolon”
Looking forward for your next installment.
I agree with Douglas much more than I do Brendan, which is quite sad as he’s the creator of the damn language haha. Noobs love syntax, I think that’s the main problem, does it help you, no not really, is it elegant? no, is it unique? no, is it tough to write? no
I have mixed feelings about CS. On the one hand I really do like the terse ruby-like syntax, and the fact that it compiles to satisfactory js in my opinion. I think the real danger in CS is people learning CS and not the js principles it’s based on. All that matters is that you can write correct code. If you’re depending on someone else’s code to do that, you’re in trouble.
I have the same feeling about jQuery. It’s awesome but if you can’t code js without it, you’ve got problems.
Some guys are worried because people learn CS and not the js’s principles it’s based on and the same goes for jquery. Well, if you are ditching any tool that makes your life easier, you could well be coding in assembler. That’s the real thing, dude!
The good thing about Coffeescript is that it’s not just a new language implemented in Javascript: It is an alternative syntax for javascript. A syntax that makes it more amenable to coders that cut their teeth in python or ruby, who are used to their powerful, suscinct and expressive syntax. Anyone who comes from python or ruby and has to work with plain javascript feels pain, not pleasure.
JS has way too many glitches and making things work is sometimes a pain in the neck. CS fixes these while providing a nice syntax.
What’s more, I feel CS’s syntax better reflects the true nature of the “good parts” in JS, whithout its shortcomings.
It’s not just an alternative syntax for JavaScript, though. It adds stuff in. The best example is how it does loops. It adds in all this cruft that does not need to be there.
I think you point here: “…CoffeeScript IS a thing of beauty. It works, its a whole new language and yet it compiles down to plain old JS…”.
Yes, CS is beauty, but it’s not “a whole new language”.
It doesn’t introduce any new data type, data structure or object model. When you code in CS, you use the same data types and structures you used in JS.
The only thing that changes is the syntax for manipulating these types and data structures. A more succinct and expressive one.
That’s why it translates to perfectly readable JS without glitches, and stays fully compatible with jQuery or any other JS libraries.
There are no shortcomings in using it. The end result is highly readable JS. This is the code that gets finally executed. No compatibility issues at all.
However, if you never tasted the sweetness of python or ruby, chances are that you will never understand why it is such a beautiful thing.
When all you have is a hammer, everything looks like a nail, and there’s little incentive to learn new tricks…
I have written plenty of code in many languages including, for example, objective-c, and python. In fact python its my favorite tool for parsing text files and generally whipping things up on the fly that need to have disk access. Its amazing. But I am not a fan of significant whitespace and never will be. Try to build a community on the web around a programming language where its a pain in the ass to copy past things and share things in forums and all the multitude of systems that all need to enforce those whitespace characters perfectly. It becomes a point of friction. All so you can save a measly two characters. If you have ever had to go through a large python snippet and figure out the indentations manually you know what i mean.
@CS not being a whole new language, fair enough but its basically a semantic detail. I think you get the point Im trying to praise it as a meaningful work in its own right. However I suppose with that argument you could even say javascript isn’t a whole new language either because it relies on c to exist. Its turtles all the way down I guess.
I agree with most what you state here.
The whole discussion reminds me of the Java vs. Scala discussions.
For anyone who does not care about what possibilities Scala provides to your coding style, it’s just Java with fancy syntax and some keywords replaced. You can use it wo write the same dull code as you could do in Java.
It’s the same with CoffeeScript vs. JavaScript.
You absolutely can use CS to write unreadable, incomprehensible, or simply sad bad code, but you can do as well in plain old JS.
But if people do not even try to adopt the new principles CS brings to your JS development then it is nothing but JS with fancy syntax and significant indentation.
I also agree, that the “function” becoming “->” is not one of the necessary parts of CS, even though I like it. But it just fits in the whole “this cleans up JavaScript” aspects.
I’m not convinced, that CS is the messiah for JS Coders, at all, but it definitely introduces some very nice possibilities to think about your code in a different way.
For example the “everything is an expression” paradigm:
JS functions always returned a thing (functions do that by definition) but it always could be undefined and ignored.
The implicite return for the latest statement in a function is just a way of bumping that into ones head, again.
Overall CS still is interesting and fun to write.
Hm, your argument that CoffeeScript divides the community is specious at best. Sure, on a superficial level it means people writing code for the browser are now using two different languages (well, plus ObjectiveJ, ClojureScript and a couple of others) but at the end of the day both crowds can use each other’s libraries and both crowds are knowledgeable about JavaScript. I dunno, maybe there’s something to this line of thinking, but then you really do need to do better than just spreading FUD around.
Your fear that CoffeeScript leads to line noise and is harder to scan utterly misunderstands the design goals of CoffeeScript. Sure, CS cuts out and shortens syntax here and there, but the ultimate goals are greater consistency and better readability. It’s about things like default arguments, list comprehensions, function binding, destructuring assignment and so on, which are obviously all things that are *possible* in JavaScript and, you might argue, things you can do in your sleep in plain JavaScript too… but they lead to an incredible amount of line noise, with temporary vars and brackets and parens all over the place.
Helping us express common patterns in as clean a way as possible is not at all about saving keystrokes, it’s about making a language that brings what you mean and what you write as close together as humanly possible, instead of forcing you to think about stupid implementation details and incidental complexity.
This is especially obvious if you’ve ever coded in Python or Ruby. You want to quickly loop through a hash, whip up a quick for … in loop, and notice that, err, this isn’t working at all. You want to see whether a string starts with a substring, look for something like str.startswith(substr) and realize that you’re going to have to make do with str.indexOf trickery, which is easy, but indexOf isn’t very descriptive now is it? You want to do something as simple as adding a few default arguments to a function or method, and realize that JavaScript simply has no syntax for such a common pattern. Now, I’m sure you’re thinking “well, but these things are super-easy in JavaScript, you just have to know how to do them” — but at that point you’d actually be arguing the inverse of your original claim, namely that the fact that JavaScript is harder to write and scan because it doesn’t abstract away these patterns doesn’t matter. Well, it does!
Ok, so I didn’t get through the whole rant, but I feel like arguing about Coffeescript vs Javscript straight up is a little silly. Coffeescript is clearly a much cleaner and more straightforward way to display the same code.
Dealing with complexity inherent in the language means that you have less brain cells to rub together for the complexity of your overall program, so Coffescript is clearly a winner in that department.
The added complexity with Coffeescript is that it is another layer of abstraction on top of Javascript. That is the main tradeoff when using Javascript. Which manifests itself in a number of ways including, having to potentially compile/build, debugging is more complex etc. etc.
To pose this another way, if Coffeescript came first and someone wrote Javscript to compile into it. You would think they were bat shit crazy.
I have a new client that uses CS in a project and I am baffled why such variation on JS even exists!
What is the point to write beautiful code that only CS developers can read that produces JS that more developers can read!
Saving a few keystrokes is stupid. You spend so much more time reading code. I heard the same arguments when I was coding in Pascal “begin” instead of “{”
If you can’t type you should be even be a programmer.
But my biggest issue is run-time debugging. So here you are being a clever dick writing CS, then you have to compile it to JS to run it in a browser. Then in the debugger you suddenly have to look at auto generated code you didn’t write. Try to figure out how the JS line number in the run-time debugger matches the line in your CS code.
I spend most of my career using high quality IDE’s with integrated debuggers producing windows applications. From a programmers point of view the disjointed development environment around a web-browser is bad enough. It doesn’t need another layer of abstraction.
Form before function is dumb. To me Coffee script is the same as TXT language on mobile phones. Hard to read.
This is hipster madness.
i was thinking to myself, “this guy has a point”, and then i realized i was reading coffeescript. every friend i’ve shared your example with preferred the coffeescript notation. i didn’t tell them which language was what, i just asked them which one they preferred…. and everyone of them are writing code professionally. this response probably means nothing, so i’ll leave it here.
literally several months late to the party.
In my opinion languages that compile down to a interpreted language are generally a fairly bad idea. (hello Dart, i’m looking at you) I’ve looked at them, and then moved on because they were like wanking with beautifully hand-crafted chopsticks.
HOWEVER if a browser vendor were to implement coffeescript syntax natively then we’d be talking about something very different. The SASS guys are trying to have requires pushed into the CSS spec, perhaps coffeescript should be pitched as a new scripting language rather than another JS preprocessor.
*clearly Sass isn’t a js preprocessor, i’m just shit at typing.
Hi! I think you have some interesting points, and I appreciate your humble approach to discussing what you think the weaknesses and strengths of various languages are.
I do feel the need to point something out though. All programming languages have a certain property that is independent of the language structure: syntax verbosity. Coffeescript is structurally equivalent (isomorphic) to Javascript, and thus its ONLY difference is its level of verbosity.
Now, this verbosity vary a lot.
Very verbose:
variable alpha = function (beta) {
gamma = add(beta, 10);
return function (delta) {
return add(gamma, delta);
};
};
Very terse:
alpha |beta|:
gamma = beta + 10
|delta| := gamma + delta
Javascript leans toward the verbose side; Coffeescript leans toward the terse side. If you take a large distribution of programmers, you will find that each enjoys and performs optimally at a different level of verbosity from each other. This optimal level is a function of many parameters like programmer experience in certain languages, genetics, etc.
Anyway, my point is that Coffeescript is gaining popularity because it is apparent that a LARGE portion of the distribution enjoys/performs best with the verbosity level of Coffeescript. It is a bit unfortunate for you, since you function better with the more verbose side (and for me, I function best with even less verbosity than Coffeescript). But neither of us get what we want because it is what MOST people like the best that gains traction.
I have totally ignored this blog for a long time but I want to thank everyone for their great comments! I’m perfectly happy to be wrong on this but more and more it seems this is very much a matter of taste and probably at what stage in your development as a programmer you learn a given language. Doug Crockford is soo right when he says languages have been adopted slowly because developers have an illogical affection for “their” language to the detriment of learning new languages. I think this proclivity is changing with greater awareness of the value of being a polyglot programmer. Having gone to school for design I KNOW that a trained eye sees things very differently. Much like when you learn about patterns and start seeing them everywhere. So much of my resistance to terseness, ala oneliners that do lots of things, could be chalked up to not having a well trained CS eye. That all is probably true of this programmer’s rejection of CoffeeScript. Yes I’m human. But in a much better critique than I could muster Ryan Florence gets to the guts of the matter that I was so verbosely poking at. Mainly I want to hilight his description of how we see and comprehend things, and as he says”Verbally Readable !== Quicker Comprehension” go check it out if you have not read it yet. http://ryanflorence.com/2011/case-against-coffeescript/
No argument from me. Just learn the damn language (JS) and be done with it.
How many typeof, function, prototype, apply keywords you have in your js code?
When you will have hell-o-lot-of them, you will love coffeescript.
just choose right tool for right job.
If you have a lot of typeof, function, prototype, and apply keywords… Maybe it’s time to refactor and not throw the baby out with the bathwater. You have the tools and capacity to create functions that solve all those problems. Instead, you choose to clutter up everyone else’s screen with extra noise because the “compiler” that takes CS can only be so smart about reusing methods to reduce the clutter.
Maybe this is hipster madness… Or maybe there’s something to it. Plenty of languages compile to something else, or they generate code in another language.
From my perspective, as someone who’s never used JS before, CoffeeScript is very nice. The syntax makes sense, I don’t have to learn a bunch of boilerplate or try beating an IDE into submission, and the output isn’t nearly as strange as other languages which compile into JS.
You don’t have to use or like CS, or Lisp, or OCaml, or other interesting languages that people use to generate code (like JS) and be productive, but plenty of people use technology like this to streamline their development process, especially if they’re more comfortable in a server-side language that they can use to generate JS…
I personally would rather use CS, Parenscript or JS_of_OCaml than write in actual JS, but maybe I’m just a hipster programmer (I also use Common Lisp and Emacs)…
CS to me is like adding an unnecessary step of complexity in the already clobbered web application layer. Eg: We are already using HTML, CSS, JS and atleast one supporting server side language which again has multiple levels of abstractions or frameworks.
Think this as an author writing a book learns Korean to write his book since its compact and then puts it through Google translate to get English version. Isn’t CS doing something similar even if not so extreme.
Instead the communities should better concentrate on improving the existing ecma script standards or find a direct replacement of java script altogether instead of trying to wrap it in a stylish costume. Otherwise it will become like windows OS where base of the OS is inefficient and flawed and microsoft brings out glossier GUI build on the same base with every new release. It may be improving on style and rich features but never solved the core issues of the OS and we are still hoping for it to get better, our fingers crossed.
Coffee is a brewed beverage with a distinct aroma and flavor, prepared from the roasted seeds of the Coffea plant. The seeds are found in coffee “berries”, which grow on trees cultivated in over 70 countries, primarily in equatorial Latin America, Southeast Asia, India and Africa. Green (unroasted) coffee is one of the most traded agricultural commodities in the world.`
Check out our blog site too
<http://www.caramoan.co
Coffee is a brewed beverage with a distinct aroma and flavor, prepared from the roasted seeds of the Coffea plant. The seeds are found in coffee “berries”, which grow on trees cultivated in over 70 countries, primarily in equatorial Latin America, Southeast Asia, India and Africa. Green (unroasted) coffee is one of the most traded agricultural commodities in the world.`
Most recent article on our blog
<http://www.caramoantourpackage.com