31–40 of 132 posts
I still believe that people love or hate CoffeeScript mainly because of the differences in syntax: http://franklinchen.com/blog/2011/11/06/the-real-reason-for-...
That doesn't mean that it's not OK to prefer it over JavaScript (or vice versa) if you find those differences make you happier about coding in it.
I will say that just like you should know HTML before using haml, you should know JavaScript before using CoffeeScript.
I feel bad saying this, because I respect raganwald greatly and I usually enjoy his writing, but this post is somewhere on the border between facile and false. For example: > CoffeeScript has lots of more subtle transformations up its sleeve, like comprehensions, destructuring assignment, splats, or the "fat arrow" some rail against. Here's the secret to understand: None of these things are "language features" that c…
Not always. There are a number of language features that have non-local implications, such as pattern matching, lazy evaluation, continuations, or exceptions. If you implement such a feature on top of a language that doesn’t have it, you will have decidedly complex transformations.
I agree that it’s overly simplistic to suggest that it isn’t a full language if it only involves local/simple transformations, but the question of local vs. non-local transformations at least hints at the idea that a new paradigm or way of thinking about programming is involved.
Hmm they say the same thing about haml, however haml makes my life so much easier when writing views. I will say that just like you should know HTML before using haml, you should know JavaScript before using CoffeeScript.
Objective-C -> MacRuby; Slim/HAML/Jade -> HTML; SASS/LESS -> CSS and so on...
what's wrong w/ javascript? fill me in, because i for one totally love js the way it is.
I'm not particularly sold on CoffeeScript, however this article seems to imply we'll someday have to maintain the generated files? As long as you keep the source near the generated files (which should be easy with version control -- you shouldn't even be checking in the generated source, in my opinion), I don't see the problem.
I'm trying coffee on a relatively small project with only a few developers. So far I'm happy with the tradeoff. I keep my Coffeescript simple so the Javascript is almost exactly what I would write by hand.
"CoffeeScript is a program that takes some text you write using a special set of rules and transforms it into some other text, which happens to be a JavaScript program"
> You don't "Think in CoffeeScript," you "Think in JavaScript." Only you think in well-crafted JavaScript. Not true, if only because CoffeeScript includes classes as a language feature. In JavaScript it is a hack. This might change with EmcaScript.next, but for now that creates a significantly different way to design your code. Try writing a Batman.js app in JavaScript and you'll see what I mean. With await/defer pos…
You missed the rest of the essay, wherein Raganwald described how CoffeeScript “features” are a shorthand for common JavaScript design patterns, forcing everyone to use the same patterns in the same way. [In other words, he answered your specific comment at great length, rendering your criticism of one out-of-context quotation a bit weak, eh?] Specifically, most major JavaScript projects have some kind of class imple…
The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged.
Like I said, as other ideas like await/defer become more mature (and are merged into mainline), we're going to see the design patterns diverge futher.
Quite honestly the premise is rubbish. "CoffeeScript isn't a language worth learning because it isn't a language. It doesn't make you think about programming in a new way" How is that a definition of a language? It compiles down to another language sure - but what doesn't?
In spoken languages, there is a difference between a language, a dialect, and a specialized vocabulary. My premise is that CoffeeScript is a jargon of JavaScript. Maybe you could say it’s a dialect of JavaScript. But my premise is that notation alone does not make it a distinct language.
I consider it a different language if for no other reason than, if a programmer familiar only with Javascript looked at code written in Coffeescript, they would not understand it at all. And it can't be converted to Javascript without either considerable hand work, or via an automated tool.
This is inane. Haskell used to compile to C. Were they not "language features"?