I had a lot of niggles with CoffeeScript as well, which is why my compiles-to-JS language of choice is LiveScript[1]. It fixes basically all the annoyances and adds a lot of nice things on top of that. For exmaple, you can write more paren-free code with it and there are more kinds of useful function declarations (hushed functions, curried functions, backcalls).
Why CoffeeScript Isn't the Answer
51–60 of 148 posts
Re: Why CoffeeScript Isn't the Answer
#52Answer to what? What's wrong with Javascript in the first place?
Nothing or everything. It depends what your expectation is from a modern programming language and the size of the project you're working on.
Re: Why CoffeeScript Isn't the Answer
#53Ok, so if CoffeeScript is just JavaScript, add the parenthesis. If you need brackets to make a section of code readable or compile to "certain" JavaScript, then add them. Even the programs I work on we add parenthesis, brackets, etc for readability. Use CoffeeScript to increase productivity. Nowhere does CoffeeScript say you must use white space instead of brackets and such. Keep it simple and easy, classes are also…
There are still two sides in programming, it seems. And interestingly enough it's not necessarily static vs. dynamic or procedural vs functional. One the one hand you have pragmatic, loosey goosey languages like perl, javascript, ruby, even scala and C#. An important defining characteristic being perl's maxim "there's more than one way to do it". On the other hand you have what I'd call the "bondage and discipline" l…
I agree there something to the timtowtdi axis.
However:
python's "B&D" principle is more accurately stated as TSBOAPOOOTDI" (There Should Be One And Preferably Only One Obvious Way To Do It) and that's not quite the same as oft quoted (over?) simplifications such as "there should only ever be one way".
Similarly the Perl community TIMTOWTDI's principle has a related variant TIMTOWTDIBSCINABTE (There Is More Than One Way To Do It But Sometimes Consistency Is Not A Bad Thing Either).
Re: Why CoffeeScript Isn't the Answer
#54This is a bit overly critical. The implicit parentheses are optional, so if it's confusing or ambiguous you should just use parentheses. func 5, { event: -> 45, val: 10} Is reasonable but func 5, { event: (e) -> if e.something 36 else 45, val: 10} Really ought to be split up for readability no matter what programming language you use. And besides, the only issue is the extra comma causes it not to compile. To be fair…
If you write JavaScript in strict mode the probability of incidentally declaring something as global is pretty much zero. Those mistakes can also be properly linted and warned against - which is not possible for CoffeeScript's implicit declarations. And at least I had real-life situations where CoffeeScript's scoping broke code in very subtly ways.
Re: Why CoffeeScript Isn't the Answer
#55>I ... couldn’t figure out how to write the CoffeeScript for the JavaScript I wanted.
Re: Why CoffeeScript Isn't the Answer
#56This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just drop…
Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? He obviously knows a lot more than "day's experience". If you make the argument that he needs to learn to write better CoffeeScript then you're lending help to his argument.
Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems?
I think the point is that CoffeeScript does fix some problems of JS, but introduces complications of its own. It's worth it for some, but not others.
Re: Why CoffeeScript Isn't the Answer
#57Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules. With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping. I'm done, this isn't suitable for prime-time, time to go somewhere else. I spent too many years in the 80s working wi…
I've used coffeescript extensively for years, and I have never had that be an issue. Not sure if it's because I rarely write a file longer than ~200 lines, or I'm careful about variable names and global scope.
More generally I've found that coffeescript mixes much better with a functional style than with an imperitive one.
Re: Why CoffeeScript Isn't the Answer
#58This article only proves that when doing it wrong, CoffeeScript causes problems.
No parenthesis make nested calls unreadable? Simple add parenthesis for the inner calls. Like in any other language with optional parenthesis (Ruby) too.
Too long statements are unreadable? Don't write them. Maintaining an 80 or 100 character line limit is good coding practice anyways.
Re: Why CoffeeScript Isn't the Answer
#59Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules. With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping. I'm done, this isn't suitable for prime-time, time to go somewhere else. I spent too many years in the 80s working wi…
> With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping.
> I'm done, this isn't suitable for prime-time, time to go somewhere else.
So does that mean Python and Ruby are out the window too? It's really never been an issue in either of the three languages.
Re: Why CoffeeScript Isn't the Answer
#60This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just drop…
"More than a day's experience" is not really fair.
It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day.
The rest of what you wrote I agree with.
But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally.
I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but thats another issue) whereas initially I thought that CoffeeScript was a joke.
Then I had to learn CoffeeScript because it was used in a library that I needed to understand.
It was only _after_ I had invested the time in learning CoffeeScript that I could see the advantages. In fact, up until that point that I had learned it, CoffeeScript _was not_ an advantage for me -- it was a liability, because I didn't know how to use it. When you aren't familiar with a language then whatever advantages it may have are more than offset by the fact that you don't know what you are doing.
I think this is a problem that pretty much every new paradigm shares to some degree. It is very difficult for the average person to emotionally get behind the effort to learn a new way of doing things, and psychologically we just aren't wired to make an accurate judgement about whether that will pay off.
Judgments and decisions are actually emotional/subconscious and the rationalization comes afterward.