5 ms·

I'm torn. Syntax-wise, I find that many programming languages are similar enough that moving from one to another is pretty straightforward. Even Objective-C mak

I'm torn. Syntax-wise, I find that many programming languages are similar enough that moving from one to another is pretty straightforward. Even Objective-C makes some kind of sense to a Java/PHP/Python/etc programmer. But CoffeeScript doesn't feel this way to me, which makes me want to stay far away. Yet so many smart people are building cool things with it, which makes me wonder if I just need to suck it up and get familiar with this new syntax.

raganwald 13y ago
I don't know if this is true for CoffeeScript, but sometimes an unfamiliar syntax enables something new and very useful. You won't experience that unless you embrace something very different. eS6 will have fat arrows, but comparing CS today to JS today, I find the -> and => constructs are more than just an abbreviation, they make it radically easier to write AND READ code that makes heavy use of functions. YMMV, of course!
smrtinsert 13y ago
It's inspired by a family of languages you probably aren't familiar with. My suggestion is to make simple projects with it, and start small using the features you clearly understand. Overtime you'll get more curious and want to learn the rest of the cool stuff and when you do you'll see ways to slash lines and lines of code from your old js or even cs. There are better ways to learn new languages but cs is familiar enough to js that once you start coding you'll see it comes more naturally than you think.
elwell 13y ago
If you learned Objective-C, CoffeeScript is a walk in the park. A peaceful, elegant, enjoyable walk in the park.
- erokar 13y ago
  Very true.
deleted 13y ago
[deleted]
unoti 13y ago
The syntax we're talking about above is probably more confusing and less intuitive than 99% of the Coffeescript out there. Don't be alarmed. If you know Javascript, it's pretty approachable. The syntax is small, but all makes sense. You do need to give it a chance (read about it) and actually try it to really like it-- but that's true of any language. What's so amazing about coffeescript is such a small investment of time can payoff so strongly in terms of shrinking your code down it its purest, clearest form.
emn13 13y ago
I write and maintain a large program written in coffeescript every day, and you're right to be worried. Coffeescript is has a much trickier syntax than javascript, and if you use it all the time, then the brevity and reduced line noise is a slight win, but you never lose the downsides of the complex syntax. If you're wondering what's wrong with coffeescript, it basically boils down to the fact that the syntax is chock full of unexpected exceptions. I notice that I and everyone I know sometimes get's surprised by what a piece of syntax actually compiles to (not a good sign). Some examples: f a: 1 b: 2 compiles to f({ a: 1, b: 2 }); but f o fails to compile (so whether you can break an argument onto the next line depends on whether it's an object literal) Comma's to delimit multi-line arguments are usually redundant, but not on the first line, so... f 1, 2 3 compiles to f(1, 2, 3) but f 1 2 3 doesn't compile at all. Curly braces aren't entirely optional, so o = [ { a: 1 b } ] compiles to o = [ { a: 1, b: b } ] but o = [ a: 1 b ] compiles to o = [ {a:1}, b] Note that this is particularly tricky if you have functions with complexly nested arguments, which is what the original artical is proposing to use for React. In JS that would be messy but unsurprising, but in coffeescript you will run into the occasional miscompilation, especially since it's indent sensitive but very flexible with those indents. For example you may start out with: a href: uri span className: "x" "content" ...then decide to remove the class, and end up with... a href: uri span "content" But the second example actually nests the content inside the <a>, not the <span> (and it'll crash at runtime since span is passed rather than called). You can even have code that compiles & runs and just returns the wrong value: div id: "foo" span null "content" vs. div id: "foo" span null, "content" Both result in valid JS that would run and display a valid DOM using React, but that comma changes the generated DOM. No warnings, no errors. All in all, I'd stay away from coffeescript if I didn't already have a large codebase to maintain. There are a bunch of other, better, compile-to-JS alternatives to make JS syntax less onerous - so you can get coffeescript's advantages without the nasty pitfalls.

raganwald 13y ago

I don't know if this is true for CoffeeScript, but sometimes an unfamiliar syntax enables something new and very useful. You won't experience that unless you embrace something very different. eS6 will have fat arrows, but comparing CS today to JS today, I find the -> and => constructs are more than just an abbreviation, they make it radically easier to write AND READ code that makes heavy use of functions. YMMV, of course!

smrtinsert 13y ago

It's inspired by a family of languages you probably aren't familiar with. My suggestion is to make simple projects with it, and start small using the features you clearly understand. Overtime you'll get more curious and want to learn the rest of the cool stuff and when you do you'll see ways to slash lines and lines of code from your old js or even cs. There are better ways to learn new languages but cs is familiar enough to js that once you start coding you'll see it comes more naturally than you think.

elwell 13y ago

If you learned Objective-C, CoffeeScript is a walk in the park. A peaceful, elegant, enjoyable walk in the park.

erokar 13y ago
Very true.

deleted 13y ago

[deleted]

unoti 13y ago

The syntax we're talking about above is probably more confusing and less intuitive than 99% of the Coffeescript out there. Don't be alarmed. If you know Javascript, it's pretty approachable. The syntax is small, but all makes sense. You do need to give it a chance (read about it) and actually try it to really like it-- but that's true of any language. What's so amazing about coffeescript is such a small investment of time can payoff so strongly in terms of shrinking your code down it its purest, clearest form.

emn13 13y ago

I write and maintain a large program written in coffeescript every day, and you're right to be worried. Coffeescript is has a much trickier syntax than javascript, and if you use it all the time, then the brevity and reduced line noise is a slight win, but you never lose the downsides of the complex syntax. If you're wondering what's wrong with coffeescript, it basically boils down to the fact that the syntax is chock full of unexpected exceptions. I notice that I and everyone I know sometimes get's surprised by what a piece of syntax actually compiles to (not a good sign). Some examples: f a: 1 b: 2 compiles to f({ a: 1, b: 2 }); but f o fails to compile (so whether you can break an argument onto the next line depends on whether it's an object literal) Comma's to delimit multi-line arguments are usually redundant, but not on the first line, so... f 1, 2 3 compiles to f(1, 2, 3) but f 1 2 3 doesn't compile at all. Curly braces aren't entirely optional, so o = [ { a: 1 b } ] compiles to o = [ { a: 1, b: b } ] but o = [ a: 1 b ] compiles to o = [ {a:1}, b] Note that this is particularly tricky if you have functions with complexly nested arguments, which is what the original artical is proposing to use for React. In JS that would be messy but unsurprising, but in coffeescript you will run into the occasional miscompilation, especially since it's indent sensitive but very flexible with those indents. For example you may start out with: a href: uri span className: "x" "content" ...then decide to remove the class, and end up with... a href: uri span "content" But the second example actually nests the content inside the <a>, not the <span> (and it'll crash at runtime since span is passed rather than called). You can even have code that compiles & runs and just returns the wrong value: div id: "foo" span null "content" vs. div id: "foo" span null, "content" Both result in valid JS that would run and display a valid DOM using React, but that comma changes the generated DOM. No warnings, no errors. All in all, I'd stay away from coffeescript if I didn't already have a large codebase to maintain. There are a bunch of other, better, compile-to-JS alternatives to make JS syntax less onerous - so you can get coffeescript's advantages without the nasty pitfalls.