31–40 of 142 posts
The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…
The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…
Except when there's a regression in the compiler, and then it doesn't.
https://github.com/jashkenas/coffee-script/issues/1842
It's all good though, because "Pull requests are always welcome." :P
The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…
> Which is exactly what the fat arrow does in Coffeescript. Except when there's a regression in the compiler, and then it doesn't. https://github.com/jashkenas/coffee-script/issues/1842 It's all good though, because "Pull requests are always welcome." :P
No parens or braces necessary? Don't just omit them everywhere! I was reading the source code for batman.js (written in CS, after having written quite a bit of CS myself), and some lines were absolutely baffling. It took way too much work to parse.
I've started building up a personal style guide. The most useful parts for maintaining readability are probably:
- Always keep the parens for function calls, possibly excepting oft-used functions that are only being called with one argument. (e.g. document.createElement 'div'; parseFloat '10.5')
- Always keep the braces for object literals when used in an expression (e.g. as an argument in a function call); omitting them in a simple assignment is OK.
I tend to avoid a lot of the one-line comprehensions for the reasons documented in this article (they get difficult to 'parse'). I also tend to write in a more of a Java style, mostly because of my background is in Java. I tend to put (parens) around a lot of function calls so that I can see it is still a function. Sure, CS can be abused to the point of being barely able to read, but that can be said of any language. Having standards and code-review with your co-workers kind of negates that issue.
Debugging can be a bit of a pain since you have to find the line number out of a big file. I think this will go away if/when browsers natively support CS. I've gotten good at naming things so that they are easy to search for in the developer tools. That makes finding the right line to put a breakpoint on a lot easier and faster. If need be, I'll throw a console.log('here') in there and search for that too. Context switching between CS and compiled JS takes a bit of getting used to, but it isn't really that big of a deal. I'm already context switching between Java, HTML, CSS, json, etc... what is one more?
The fat/thin arrow thing took a while to get used to, but now it makes perfect sense. The change they made (too quietly, imho) in 1.1.3 to not use __bind so much anymore really helped with comprehension. Now I can see the var _this = this in the compiled code and things make more sense to me now. It also helped performance and made me worry less about using it. In most cases, it is safe to just fat arrow things now so it really isn't that big of a deal.
In terms of workflow, I found it very important to integrate it in with my IDE so that every time I save a file, all of my CS is immediately compiled to JS. [1] As a result, I don't see any overhead with the compilation phase of things.
Being able to declare 'class'es and constructors has also been really great for compartmentalizing my code. Yes, it is possible to emulate all of this in JS, but I find that a lot more difficult to manage. I do wish there was an 'import' statement though. Right now, I hacked that together with the way I'm using LabJS.
In the end, is CS a significant improvement over JS? I think so. Just looking at the compiled output of CS, I couldn't imagine myself writing all of that JS code and not making a ton of mistakes (ie: === vs. ==, nesting of brackets, this binding, etc). People say there is a lot of boilerplate in Java... so, when I use CS, I feel that way when I look at the compiled JavaScript.
[1] http://stackoverflow.com/questions/6645640/integrating-coffe...
Other languages are designed to be easy for anyone: these languages use English as inspiration, using whitespace instead of brackets.
CoffeeScript has a place, but not in production. It belongs in the classroom, to help those wanting to learn an easy language to program in. Ruby, I believe, belongs there as well.
Languages like C, C++, PHP, JS, etc. are all designed for production. They may not be pretty to look at, but they're easy to comprehend at a glance.
It's all a question of what learning curve you're aiming for: the learners curve or the advanced curve.
TL;DR - tradeoffs: learn them.
Earlier quoted context omitted.
First-class functions have the `this` problem in every language, and the fat arrow is very nice syntactic sugar for what you have to do anyway Not true. JavaScript's `this` binding is absolutely not the only way to do it. In Ruby: class Foo def hello return proc { self } end end puts Foo.new.hello.call #=> # In Python: class Foo(object): def hello(self): def zoo(): return self return zoo zoo = Foo().hello() print(zoo…
You're right - but I'd argue that the difference is just in default behavior, as you touched on in your edit. Ruby procs are bound to their lexical scope, and implicitly include self as a part of that scope. The function still has to be aware of some scope to run, though. (I didn't know about assigning self in instance_eval, though - that makes me all kinds of happy!) What I meant to convey is that every language tha…
Earlier quoted context omitted.
I think part of the gist of the article was that abused CoffeeScript is more bad than abused JavaScript. So, yes, of course, you can do everything differently. But the point is, in the moment when writing it, it's not confusing, and doesn't stand out as a bad thing. Later, when you look at it, it IS confusing.
I dunno. I think that a lot of that is just a matter of developer maturity and code discipline. If you can't recognize a code smell when you're writing code, the problem is probably that you aren't mature enough as a developer, not that the language is bad for allowing it. I don't think that most seasoned developers would look at that 160-column list comprehension, say "okay, that works!" and move on to the next task…
nasty: https://github.com/jashkenas/coffee-script/blob/master/src/r...
nasty: https://github.com/jashkenas/coffee-script/blob/master/src/o...
nasty: https://github.com/jashkenas/coffee-script/blob/master/src/c...
sexy: https://github.com/jashkenas/coffee-script/blob/master/src/g...
Some languages are designed for professionals to comprehend easily at a glance: these languages use symbols instead of words, use brackets effectively and don't rely too much on whitespace. Other languages are designed to be easy for anyone: these languages use English as inspiration, using whitespace instead of brackets. CoffeeScript has a place, but not in production. It belongs in the classroom, to help those want…