I don't have a strong opinion on the article itself (it seems well-reasoned to me, but I don't use CoffeeScript personally so who knows)... but the comments attached to it are hilarious.
I think CoffeeScript has great readability, because I’ve taken the time to learn how it works.
If you have to take the time to learn how to read something, it's not easily readable.
CoffeeScript is only hard to read if you try to read it with a JavaScript mindset.
Yes, why would anyone approach a tool pitched explicitly at JavaScript developers, whose "golden rule" is "it's just JavaScript" (see the top of http://coffeescript.org/), with a "JavaScript mindset"? Truly, it is a mystery.
So is mathematical notation not readable? On the one hand, it takes quite a while to learn how to read it. On the other hand, it can condense literally pages of text into a few equations which somebody experienced can understand almost at a glance.
The same is true for programming languages. Sure, anybody can read Python. But it's fairly verbose and attempts to mirror English. On the other hand, Haskell is somewhat terse and attempts to mirror mathematical notation. I've found that, after about the same amount of time with either language (about a year of off-and-on use for both), Haskell becomes far easier to read than Python.
So just because something is easier immediately does not mean it is any more readable. It could, in fact, be less readable and merely more familiar!
Mathematical notation is not readable, no. It requires extensive training to be able to understand it, and even experts will take quite a while to comprehend a document they are not already mostly familiar with. It is not like you cross some threshold and immediately become able to understand all mathematical notation with equal ease. There's plenty of evidence for this; recently we had this quote about the ABC theorem: "It can require a huge investment of time to understand a long and sophisticated proof, so the willingness by others to do this rests not only on the importance of the announcement but also on the track record of the authors" (http://www.nature.com/news/proof-claimed-for-deep-connection...)
> even experts will take quite a while to comprehend a document they are not already mostly familiar with
Experts don't take time to read notations. They take time to understand the full scope of consequences embedded in a line composed of such a condensed and readable notation, within the frame of an otherwise complex proof.
> Mathematical notation is not readable, no.
I beg to differ. You mention the recent possible proof of the ABC conjecture, and I happened to browse through various materials on the subject. While I am far from being able to understand the crux of the proof, I can perfectly read the various components of it. In fact the notation system is so readable it actually helps tremendously in grasping concepts previously unknown to me.
Mathematical notation is much harder to read than prose. It does a very good job of serving as a mnemonic for something you already understand, and a very poor job of explaining novel (to the reader) concepts.
It's also as bad as natural language for ambiguity and informality.
I don't think either English text or mathematical notation is a magic wand for readable programming language; It's more about reducing accidental ambiguity and the amount of mental context needed for parsing 'natural' constructs in the language.
Personally, most of the benefit I see from mathematical notation is down to pattern matching -- "Oh, this looks like a Fourier transform". The idea seems to be supported by the fact that there is a unwritten convention for which symbols to use for which concept (alpha over beta for example) and the way in which the equations are laid out.
> If you have to take the time to learn how to read something, it's not easily readable.
I don't think that's completely true. If you're used to algol or C-style, Lisps tend to be hard to read. Concatenative languages even more so. Not necessarily because they're hard to read in and of themselves, but because the "shape" of the code is "all wrong" compared what you're used to, and your usual anchors (keywords, binary operators, infix assingment, ...) are nowhere to be found.
I mean Arabic or Korean are not necessarily harder to read than English, but you've got to know them and how they work before you even recognize patterns in the squiggly lines and little squares.
Not really; Lisp is hard to read because the syntax is unusual, but it's not hard to understand because it's complicated. On the contrary, it has the most consistent syntax of any language.
They author's point is that Coffeescript is hard to read because it has too many edge cases which are not easily understood under a smalla and consistent set of rules. I have not programmed with CS, but it sounds like a convincing argument.
Or, to restate this and amplify it a bit, Lisp syntax is hard to read because most people are unfamiliar with it. This isn't -- or should not be -- a problem if you need to learn to read a language in order to use it. (This is orthogonal to whether you want to learn it in the first place, or whether you "ought" to.) It is a problem if learning how to read and write the language isn't enough.
The point TFA raises is that people who're familiar with CoffeeScript syntax may still make mistakes resulting in completely erroneous but valid code. Yikes. And the inherent nature of whitespace or indentation makes the problem harder to detect by cursory inspection.
I have no strong opinions about CoffeeScript, myself. I just thought this was an interesting distinction, and a rare case where syntax makes a significant difference.
Mere consistency is not enough. List is hard to read because humans do not have a natural feel for how deep a set of nested brackets are, and you have to be able to spot the matching open-bracket to understand the code.
Again, it's hard to read if you are not familiar with it. Even as someone relatively new to Lisp, indentation and formatting makes a world of difference for readability.
This isn't specific to Lisp, either. I posit that if you took your average C-like and removed indentation from any reasonably sized function or method (one or more loops, one or more if/else), you would have a hard time counting brackets.
I agree that consistency is necessary but not sufficient, though, which is what I think you're getting at. Most of the time, though, consistency is clearly better than inconsistency. There's less to remember or, if you prefer, less to screw up. :)
Please note that I was not replying to TFA, I was replying to smacktoward's assertion that if you need to learn how to read a language it's not easily readable.
i'll stick to javascript. coffeescript doesn't add a whole lot to the table, javascript is the standard and that's a good thing, re-writing the language is not the answer in my opinion.
i'd have to imagine that saving a few keystroke might sound sexy to lesser experienced developers, but that really is all it adds to the table.
being able to code on any project immediately off the bat with a standardized language is a huge plus, in terms of flexibility and scalability. you don't want to limit your company to exotic language, only to later find out few months later another new language called "frapscript" is now the new cool thing to do.
i recall the days when i was thrown into a project where the requirement was to use mootools, rather than jquery.
even though they are both "javascript" in nature, it severely limited my productivity. i can see the same thing happening to companies trying out coffeescript, it may seem like you are doing the better thing long-term wise, but in reality, it is not so much. it's better to just stick to standards and you'll be more productive down the line, i can almost guarantee it.
I'm not sure that this will ever be a fair statistic because coffeescript should never really be used for shared / module code IMO. I love CS for my application code but would never release a package on github in CS, only JS.
Once you are releasing things outside of your controlled/team environment using anything but JS is just a loop for others to jump through.
I imagine a lot of projects have both CS source for development, with compiled JS for deployment. That might skew the stats between JS+CS, but it's a good indicator of CS' popularity compared to other languages.
Considering that, releases would be in JS, as they should be.
So you had jQuery experience and were inhibited by working on a MooTools project. I get that, makes total sense.
But then you say that switching to CoffeeScript may seem like a better long term choice but "in reality it is not so much."
Surely MooTools would've been fine for you as a long term choice.
Yes, there is a penalty to switching. Whether it's jQuery to MooTools, JS to CS, whatever. But that doesn't make it a bad long term choice.
Also, CoffeeScript is more than just saving keystrokes. That makes it seem like it's all about initial up-front cost savings. Instead, it's about having shorter, more expressive code. That pays dividends for the life of a project.
"Instead, it's about having shorter, more expressive code."
yes, but at the expense of a lot of other negative baggages that comes along with it. by having it's own compiler rather than leaving that to the browser seems like it's opening a can of worms.
and just reading from the comments, i can see how we could soon see a birth of "another language", that's supposed to be solve all problems coffeescript'ers face.
for one, i guess readability seems to be the common problem, which isn't good for productivity.
There's a bit of a contradiction in your statement. MooTools is much more idiomatic than jQuery in it's use of javascript inheritance, object creation, etc, so it's "more javascript". jQuery is so efficient to work with because it created it's own nice DSL, not because it is standard. The standard could be C, would that make you more productive too?
it was a point that even if you are merely switching a js framework where both are written in javascript, productivity can drop.
if you now switch to coffeescript, something not remotely close to javascript or any other languages fwiw, you'll experience un-productivity. it's akin to having your top developers walking in eggshells and doing nearly nothing close to what he is capable of.
i think coffeescript is great in the sense that we are trying to create a better language. but i also sense how much damage it can bring to budding startups who can't find talented coffeescript'ers to fill the void when their lead developer moves on to other things.
a one off go project, i'd say it's fine. but anything more complex, i think you'll see programmers wishing they had gone back to what they were familiar with.
What damage? You can drop it at any minute and start working on the compiled javascript. I've done this a couple times.
That's true for any tool/language/platform/whatever, everything has a learning curve (and coffeescript's is quite short). Going by your words we shouldn't ever learn anything.
And you shouldn't switch to a language if your developers are not comfortable with it. Do some experiments, try it out on a smaller project, then you might switch if you see good results.
If you're used to one C-style language, it's generally not hard to read code written in another. This is not to say that you'll grok it 100% accurately on your first go, but another C-style language will be more readable to you than, say, a Lisp-flavored one would be.
Of course that "readability" leads to devs writing C in Java, or what have you, and naking subtle mistakes, instead of learning the new language. See Dijkstra's "On the cruelty of really teaching computer science"
I think CoffeeScript has great readability, because I’ve taken the time to learn how it works.
If you have to take the time to learn how to read something, it's not easily readable.
CoffeeScript is only hard to read if you try to read it with a JavaScript mindset.
Yes, why would anyone approach a tool pitched explicitly at JavaScript developers, whose "golden rule" is "it's just JavaScript" (see the top of http://coffeescript.org/), with a "JavaScript mindset"? Truly, it is a mystery.