Completely unrelated to the issue at hand... I had no idea Atom was written in CoffeeScript. I thought it was written in Javascript, which made me positive at the thought of hacking into it.
But this code? Definitely giving me a headache, and my interest went down to zero. There seems to be a meme and unchallenged claim in hacker circles that CoffeeScript is somehow more "readable" and easier to understand.
Allow me to disagree, and I suspect there's quite a few like me. This code is harder to read. I think I understand what the code does, but I can no longer be certain about the language semantics. That introduces needless uncertainty.
And it just broke all my pre-configured and pre-setup JS-tooling. Can't use any of that for this codebase. Just great.
So what's up with people writing applications and projects in NodeJS, a prime JS-environment which supports "all" modern Ecmascript-features, classes included, and then decide to go use a non-standard language for their app?
And for what gains? How did Coffeescript make this code more readable or easier to debug? It didn't. And now you need to debug code compiled from the actual code you wrote. How does that do anything except make everything harder?
TLDR: CoffeeScript seems like a bad choice for just about everything and I can't see why any big project with a desire for contributors would even consider using it.
First, good news: The Atom teams is (slowly) moving away from Coffeescript towards modern JS, and I think they'd agree (unofficially) that the choice proved to be a mistake.
Beyond that...
1. The JS world moves stupidly fast, and Coffeescript is a relic of a now-vanished age. It was born, it evolved, and it died. Back in those long ago days of, um, 5 year years ago, there was no ES6, and Coffeescript looked a lot more attractive. So much so, in fact, that ES6 stole a bunch of Coffeescripts better features.
2. If you're familiar with Coffeescript, it's terse and expressive and very readable. If you're not, it looks like gibberish. But that's true of any language. The proper critique of Coffeescript should be "hey, not a lot of potential collaborators know it, so it'll see unreadable to them", not "hey, Coffeescript is generally unreadable". JS is pretty confusing and unreadable if you don't know it too.
Mind you, Atom was released 2 years ago, when Coffeescript was already starting to look dated. And it was an open source project looking for contributors so...yeah. Bad, bad choice. :)
In fairness, I built a fairly large app using CoffeeScript and it still took a lot of brainpower to read it compared to JS. All the typical complaints about ambiguous-looking syntax match my experiences exactly.
I ended up with a general workflow of having my Coffeescript source and the generated JavaScript sitting side-by-side so I could check that the output was what I was expecting. I've only had the urge to do that with ES6 and Babel a couple of times.
I built a pretty large app using Coffeescript, and I was about to say that I disagreed, and never felt like I needed at the generated output, but...
...now that you say that, I did end up going to the Coffeescript REPL on their website to test a bit of syntax a fair number times. I feel like a got used to it pretty fast, but I agree, a big chunk of Coffeescript's learning curve is getting past it's ambiguity, and there were some features I expressly avoided just because they were too confusing. Eg, I could never remember the difference between 'in' and 'of' in CS, so I just used underscore's equivalents. And then there were the comprehensions, and the weird scoping rules, and...yeah.
I'll be honest, switching from CS to a modern Babel/ES6+ configuration, I thought I'd really miss CS, but I really haven't. I maintain that if you know CS, good CS code is easy to understand, but good CS code takes way too much work to write. :)
Interesting. Comprehensions are probably the main thing I miss. I liked the automatic returns and the @ shorthand, but whenever I find myself using Python for whatever odd reason, having comprehensions again is like encountering a long lost friend.
I wrote a couple of (simple) apps in LiveScript, which is similar to CoffeeScript, but is still way ahead of ES6 in terms of features[1]. I had to look at the generated source only once: when I was debugging and ultimately fixing a bug in the compiler. That's expected: had my C compiler had a bug, I'd have to look at asm output, too.
Normally, pre-source maps, I'd also look at generated JS when debugging in the browser, but this is no longer the case. Other than the mentioned compiler bug I didn't have to look at the generated JS even once in my 2-3 years of using LiveScript.
I think a good question to ask would be why did you have to look at the generated source. What did that give you, and what could replace it? Is looking at the generated source the most efficient way to achieve your goals?
[1] The "killer feature" of LiveScript, for me, is its support for functional programming on par with support for OO. It reminds me of Scala or F# in that regard.
> If you're not, it looks like gibberish. But that's true of any language.
That's not true though. I'm not familiar with C++, for example, but it doesn't look like gibberish when I look at it. Nor does Go, as another example, even though I've never written a line of it.
CoffeeScript, on the other hand, still is hard for me to parse—even as someone who has written thousands of lines for it.
There are very real differences in readability between languages.
CoffeeScript is supposed to be this nice Ruby/Python-esque sugar for JS. It does resemble those languages, but it's not nice, it's very... stabby. Indentation is unintuitive and makes code do completely different things (whereas in Python it just delimits blocks, and if you get it wrong the compiler will moan at you). Functions implicitly return the last value they produce. You can omit brackets in function calls - but only if there's arguments, otherwise you've accidentally made a NOP.
It's horrible. It's a nice idea, but the implementation leaves so much to be desired. It's bitten me before and so I avoid it now.
Coffeescript is not perfect, however, nowadays people went crazy for ES6/ES2015, and suddenly nobody complains readability of babel output.
I've worked with both, ES6 is definitely a big progress on Coffeescript, but it takes like 80% of the things from coffee IMO, except the indentation syntax and list comprehension, added an `import` keyword.
My point is: don't complain about coffeescript while cheer at ES6, they are mostly the same.
Throughout its life, CoffeeScript has been by disparaged by those who just seem to really hate it's existence for some reason. At first it was "you can't debug generated code!", now that everybody is using generated code it's "coffeescript is the past, you don't want to live in the past do you?"
Except... CoffeeScript does all sorts of nice things that Babel does not. List comprehensions. Lack of == operator. Correct modulo operator. Block regexes. Triple-quoted strings. The @ syntax.
There is a strong cult-like vibe to the JS community, and I really find it off-putting. They have taken a technical limitation "Browsers only support JS" and turned it into a socially enforced rule "You may only use JS". Fuck 'em.
> My point is: don't complain about coffeescript while cheer at ES6, they are mostly the same.
No, they are really not.
ES6 does not change the semantics of the language. It adds a couple of new useful features, but it still maintains the basic readability of JS.
I've written production apps in both. With Coffeescript, I regularly encounter problems where the generated output is not what I expected given the input and the only way I discovered that was examining the output JS.
With ES6/Babel, I have literally never inspected the generated output. It's never produced code contrary to what I expect.
The semantics are the same (with a couple of minor exceptions) as Javascript so it's just sugar really. I found it very easy to reason about, it often comes down to whether or not you are comfortable with reading significant whitespace.
I liked CoffeeScript but haven't used it in years. IMO CoffeeScript is probably a bad choice for a modern dev environment.
>TLDR: CoffeeScript seems like a bad choice for just about everything and I can't see why any big project with a desire for contributors would even consider using it.
you're not familiar with coffeescript and used to the many javascript warts, so your perspective is biased.
But Coffeescript makes many things easier and has good tooling (just another loader in webpack). While not perfect, It is a reasonnably efficient tool for front-end dev.
If you can't read CoffeeScript then just compile it to JS. Result is more readable than most people produce in JS by hand.
For me CoffeeScript is just shorthand syntax for well structured, fast JS although I agree that ES6 is good CoffeeScript replacement (destructuring FTW) if you can suffer through braces, colons and `function` keyword.
But this code? Definitely giving me a headache, and my interest went down to zero. There seems to be a meme and unchallenged claim in hacker circles that CoffeeScript is somehow more "readable" and easier to understand.
Allow me to disagree, and I suspect there's quite a few like me. This code is harder to read. I think I understand what the code does, but I can no longer be certain about the language semantics. That introduces needless uncertainty.
And it just broke all my pre-configured and pre-setup JS-tooling. Can't use any of that for this codebase. Just great.
So what's up with people writing applications and projects in NodeJS, a prime JS-environment which supports "all" modern Ecmascript-features, classes included, and then decide to go use a non-standard language for their app?
And for what gains? How did Coffeescript make this code more readable or easier to debug? It didn't. And now you need to debug code compiled from the actual code you wrote. How does that do anything except make everything harder?
TLDR: CoffeeScript seems like a bad choice for just about everything and I can't see why any big project with a desire for contributors would even consider using it.