I agree, but it's important to note that pictures and symbols are only felt because the relationships have been so well defined in the past. I'm not a JS or CoffeeScript developer (I use python and C mostly), so "!==" is much less clear than "isn't".
A Case Against Using CoffeeScript
131–140 of 142 posts
Re: A Case Against Using CoffeeScript
#132Pythonista and Haskell hacker here. Everything he hates about Coffeescript is what I love about it, minus debugging. My debugging workflow looks entirely different (and more efficient) than his, however. While I can't say for sure, it reminds me of the days where Java programmers would try Python and complain that it was harder to write Java code in Python than it was in Java (esp. with getters and setters).
Re: A Case Against Using CoffeeScript
#133There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
It's a ton of fun to write. That's why. I absolutely love writing it. That alone is why I didn't pull the plug on it at work.
I have great feelings of guilt for posting that article w/o talking more about the things I really enjoy about the language. I'm having blast with my SnackJS CoffeeScript branch. https://github.com/rpflorence/snack/tree/amd-coffee
I think every JS developer should give CoffeeScript a spin in a side-project.
Re: A Case Against Using CoffeeScript
#134I agree with the author of this post. What is interesting for me is how people are happy to use an intermediate layer in front of javascript just to gain some syntax and not real semantics. CoffeeScript does not really change the complexity of your program. I agree that in modern languages it is a good idea to avoid all this parens and useless syntax that we have in Javascript, ObjectiveC, and so forth, and I hope ne…
Re: A Case Against Using CoffeeScript
#135Earlier quoted context omitted.
With JavaScript ordinary developers hit a wall at some point and can't make further progress. Like Java has shown, how good the language is seems secondary to how good the implementation, the runtime, is. JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code. With careful engineering, developers can get even further with just JavaScript the langua…
Just to clarify one thing, it's very unlikely that you'll take a 50% performance hit when moving from JS to CoffeeScript. That may be true for Dart as well--I don't know. Also, since CoffeeScript transcompiles to JS, it will generally reap the benefits of future improvements to JS runtimes, packaging tools, etc.
Re: A Case Against Using CoffeeScript
#136The debugging complexity is more than just a fair point. It is what kills the language for me. I spend way more time debugging code than writing it. I suspect most coders do. Programming has taught me that I am far from perfect. Give me a language where I can jump right to the problem and my debugger will tell me how I goofed up, and I can look at it as a potential language I will use. Give me something where you dou…
Of course, though, it comes down to personal preference. Don't want to use CS? Fine! Great! Go hog wild! No one's forcing you to. Me, though? I'll never go back.
Re: A Case Against Using CoffeeScript
#137Earlier quoted context omitted.
There are real semantic differences in CoffeeScript. As listed by jashkenas himself more than a year ago in response to the same accusation: Leaving features off the table and just talking about semantic cleanups, here's a few: * Switch statement doesn't fall-through by default. * Variables don't need to be declared with "var", and can't ever become global accidentally. * Equality is strict, using `===`, if you want…
That's definitely more semantics that I thought it contained, thanks for the clarification. However for the same reasons the debugging problems are probably more severe than I realized before.
Re: A Case Against Using CoffeeScript
#138Re: A Case Against Using CoffeeScript
#139Earlier quoted context omitted.
I've seen terrible JS, but I've seen much worse CS. Most programmers have relatively no sense of organization, and when unleashed with CS create things far more nasty than their JS counterparts. 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:…
I've seen terrible assembly but I've seen much worse C. Most programmers have relatively no sense of organization, and when unleashed with C create things far more nasty than their assembly counterparts. nasty: https://github.com/mirrors/gcc/blob/master/gcc/c-family/c-co... nasty: https://github.com/mirrors/gcc/blob/master/gcc/c-family/c-le... But you get the idea. I'm merely pointing out that compilers are tricky an…
Re: A Case Against Using CoffeeScript
#140Am I the only one to completely disagree with the author? It's important not to mix everything. CoffeeScript is a language . There just happen to have an implementation for it. This invalidates the "debug" workflow problem. Let me restate the CS debugging workflow: Start discovering the problem in the code I wrote. Fix it in the CS Problem fixed, move on, otherwise start over. A computer language is by definition a m…
You take the "useless pedantic comment of the year" award. Yeah, "it's a language". In bloody THEORY. In reality it's also ONE, and only ONE, specific implementation widely used. In reality the language IS the compiler. And that implementation compiles to JS, not as an implementation detail but as it's sole reason to exist.
Yup, there's only one implementation. But doesn't in change? What will the compiled code be like in 3 years from now?
The compiled code's prupose is to be optimised, not consistent. This is my point.
By restricting yourself to think Javascript when you're coding in CoffeeScript, you're producing a code that sucks in JS and in CS.