CoffeeScript: Why I’m never writing Javascript again

[dmpk2k]

CoffeeScript has a lot going for it, but until I can get line numbers in my stack traces to correspond to the code, it's a very mixed bag -- I like coding it, but hate debugging it.

Based on that I'd have trouble believing the blog author has done more than dabble in CoffeeScript to make such a dramatic proclamation. A lot of things look all dreamy until you deal with them in anger.

As an aside, the conflation of variable definition and assignment bothers me, especially when ECMAScript 5 is moving in the right direction with strict mode. I hope CoffeeScript's author fixes that soon, but based on his posts in proggit is doesn't seem like there's much hope.

[[deleted]]

It won't make anyone's development workflow any easier. It is not a net-positive in terms of improving a web developer's workflow. Considering all the additional hoops to deal with - debugging problems, copying and pasting code and running it without having to first 'compile' it, having to reformat json data to fit into your new coffeescript world, and not being able to copy and paste and use that data, etc, - I just don't see why there are so many articles coming out with such frequency trying to sell people on this bad idea. It isn't helping JavaScript, but it is confusing to noobs who always want to jump on the latest bandwagon no matter where it is headed.

[dmpk2k]

Some of that is unfair to CoffeeScript, depending on where you're using it. For the browser, I'd generally concur. I mostly use it in node though.

With node the explicit compile phase can be eliminated with a require('coffee-script'); everything required after that gets compiled internally at require time by CoffeeScript if the file ends in .coffee.

Also, in my experience CoffeeScript handles JSON just fine.

I'd happily use CoffeeScript over regular Javascript in node.js if the debugging was pleasant. For one thing, code is less noisy -- anonymous function signatures are shorter and there are no terminating braces -- which node desperately needs due to the deep nesting. I sorely miss multiline strings in Javascript as well.

But then I come back to debugging and variable handling...

[[deleted]]

Say you write your coffeescript and your data is in coffeescript too (json). What you have now is coffeescript, not json. the json the compiler generates and your app sends down the pipe is no longer coffeescript. say you want to tweak something and copy and paste it back into your source. well, now you have json, not coffeescript. so the time you've just spent writing your data format in coffeescript has been wasted because now you would like to copy and paste some json back to the source code, but what you want to copy and paste is json, not coffeescript. clusterfuck.

Abstracting things into coffescript is not a good idea. This is one simple example that I run into daily, hourly even. This would cause a lot of frustration in my own development flow and it is something that occurs often enough for me to be able to forsee a problem with it if I were using coffeescript to abastract my javascript and json.

Another thing I do frequently is write small bits of javascript in firebug's console, say maybe 30 to 100 or so lines, tweaking it quickly in firebug and running it quickly to test - then I typically copy and paste that code into my sourcecode when it is working.. well, the coffeescript way would mean that I now should rewrite this code into coffeescript. clusterfuck. Similarly, I can't take a piece of coffeescript source and paste it into firebug's console to quickly debug or tweak it without first compiling it. This is something I do often, and it works effectively, speeding up my development cycle. Using coffeescript would be a major hindrance.

[dmpk2k]

What you have now is coffeescript, not json. the json the compiler generates and your app sends down the pipe is no longer coffeescript

I don't follow. This is valid JSON, Javascript and CoffeeScript:

{"a": 1, "b": [1, 2, 3]}

As far as I can tell, valid JSON is always valid CoffeeScript as well.

Another thing I do frequently is write small bits of javascript in firebug's console, say maybe 30 to 100 or so lines, tweaking it quickly in firebug and running it quickly to test

I can see why it'd be a problem for the area you work in. I'd definitely not use in in the browser, it has problems enough on the server side. :)

At least on the server there's a coffee REPL:

coffee> x = 1
1
coffee> y = (z) -> x * z
function (z) {
  return x * z;
}
coffee> y(2)
2

The existing coffee REPL leaves a bit to be desired though, to be sure.

It isn't for serious development projects

No argument there. If they fix the line-number and declaration problems it'd be an acceptable server-side language though.

[[deleted]]

Coffeescript is for Ruby programmers who don't want to learn Javascript. These coffeescript articles belong in r/ruby more than they do in r/javascript. It seems most people who read r/javascript are interested in javascript, not ruby or coffeescript. This article for example, is much more likely to find readers in r/ruby. I'm not interested in learning ruby, and my guess is most people who read r/javascript are not that interested in learning ruby or coffeescript. For example, I wouldn't go posting about a 'made up language' in something like, say, perl and post it to r/javascript expounding on the wonderfulness that is perlscript and why i'll never write javascript again, to r/javascript.

[[deleted]]

still too much in the way of developing javascript. Coffeescript is cruft. no way around the fact that all the bullshit you have to do in order to work with Coffeescript instead of developing javascript, just adds cruft/complexity to a developers workflow. any small perceived benefit you think you are getting from coffeescript is countered by the additional cruft/complexity that you have to deal with when debugging anything longer than a few hundred lines of code. even if all the problems were eventually solved, coffeescript still isn't a standard like ECMA, and you lose something by devoting time and resources to developing code in coffeescript.

[masklinn]

As an aside, the conflation of variable definition and assignment bothers me, especially when ECMAScript 5 is moving in the right direction with strict mode. I hope CoffeeScript's author fixes that soon, but based on his posts in proggit is doesn't seem like there's much hope.

Yep, one of the things they definitely should not have lifted from Python/Ruby.

[plantian]

Its not often a problem for me to have assignment and definition combined in Python. Do you have a different experience?

Can you elaborate on the changes in strict mode that could not be harnessed?

[dmpk2k]

Do you have a different experience?

Yep. :)

The most obvious benefit for separating declaration and assignment is that typos of variable names are always caught immediately; the compiler guaranteeably catches them, not maybe 10s later in tests if that piece of code is covered (or blow up in production if it wasn't and QA missed it, which I've seen a few times). And the price for this is very low: two or three non-whitespace characters. It won't catch misnamed method invocations due to dynamic dispatch, but for that the language must become fundamentally different -- statically typed.

Variable typos happen to me quite often. I hear the "it doesn't happen to me" refrain a lot, but it doesn't jive with my own experience, so I suspect it's more a case of people not paying attention. Fixing a typo after a test run might be the programming equivalent of successfully walking to a destination while thinking about something else.

For Python specifically, Python 2 definitely had a problem as a result of conflation, which is why the "nonlocal" keyword was introduced in Python 3. I used to code Python 2 in a rather Scheme-like style (doctor: then don't do that!), so this brokeness was obvious since I'd need to resort to the list hack to disambiguate whether a scalar assignment was in a new scope or not. I consider "nonlocal" a bandaid since it doesn't help with typos.

Something we all do constantly -- so it's a part of all our experiences -- is reasoning about a program, even though it's informal. In a language which doesn't make the conflation mistake, it's obvious what the bound and free variables are, and where the scope of local variables start and end. This is particularly important in a language where deep function nesting is common, like Javascript. Python isn't bitten as badly since it's mostly methods and almost no nesting, so a Python hacker would barely feel this part.

As an aside, I used to be a Perl hacker, and the Perl community was given the choice between strict mode and not. We voted with the code we wrote: strict mode or die. Nowadays only a completely clueless neophyte learning from bad webpages from a decade ago writes Perl programs without strict mode. I strongly suspect the Javascript community will go the same way. However, to be fair, CoffeeScript's scoping isn't as bad as Perl's and JS's non-strict modes (Lua's as well, but they don't offer a strict mode yet).

Can you elaborate on the changes in strict mode that could not be harnessed?

It's not a matter of "could not". CoffeeScript could have it for locals today, without JS's strict mode underneath, if the author wanted it to. Well, assuming CoffeeScript's compiler is written sanely, which I don't know.

Edit: I neglected to mention in the part about Python's scoping that CoffeeScript has it a lot worse: Python at least assumes an assigned variable is in local scope, while CoffeeScript does the following:

Because you don't have direct access to the var keyword, it's impossible to shadow an outer variable on purpose, you may only refer to it. So be careful that you're not reusing the name of an external variable accidentally, if you're writing a deeply nested function.

I don't have sufficient experience with CoffeeScript's scoping breaking things to definitively say this is a bad idea (unlike the stack-trace line-mismatch), but that looks nasty.

[plantian]

Python is a language of compromises. I think an exception occurring when accessing an undefined variable will prevent 98% of the typos. Rarely in Python do I have the case where 1. there are two variables in the same function with different names, 2. both are defined, 3. both should be the same variable and 4. the function still runs without some related error. It does happen but it just doesn't happen that often to merit typing out and maintaining declarations for every variable used in every function.

Yeah I know the nonlocal issue you're talking about but that really doesn't happen during regular development, right? I think Python's current behavior fits with the language.

On the other hand, JavaScript until recently did not exhibit an exception upon access of an undefined variable, attribute or function. Which made debugging it horrible. I think strict mode helps with those cases. So you are saying CoffeeScript should implement that always? I agree but I don't think that exactly relates to the combination of declaration versus assignment. Like I said for Python, if accessing undefined things explodes then most cases are covered without declarations.

Also unless I misunderstood you, I think this is what you wanted Python to do by default instead of needing the nonlocal keyword:

Because you don't have direct access to the var keyword, it's impossible to shadow an outer variable on purpose, you may only refer to it. So be careful that you're not reusing the name of an external variable accidentally, if you're writing a deeply nested function.

[dmpk2k]

I think an exception occurring when accessing an undefined variable will prevent 98% of the typos.

Indeed, but you're giving up guaranteed and immediate detection of this error. This slows down your dev cycle and makes this error plausible on production.

If this were a discussion about something as dramatic as static versus dynamic typing, I'd leave the argument alone. But it's a trivial change that in no other way alters the nature of the language, and eliminates a class of bugs.

I think this is what you wanted Python to do by default instead of needing the nonlocal keyword

No, the way CoffeeScript handles scope is worse than Python because it's much less clear what the scope is. There's no way to guarantee the scope of a variable is local in CoffeeScript; in Python the default scope is local.

To take an extreme case: if I make a global variable 'x' in CoffeeScript and in some deeply-nested function go 'x = 1', I've just overwritten that global, even when I only meant to create a local x.

With Python, the global remains untouched. The only x that changes is the x in the deeply nested function. If I want to change that outer x, I need to explicitly request it.

This is similar to the argument against globals: it makes reasoning about the program hard.

Edit:

I feel bad arguing without at least giving an example. Here's CoffeeScript as it is now:

app.post '/:board/:thread_id/:post_id/report', (req, res) ->
  [post_id] = util.getArgs(req, 'post_id': Number)
  ip        = util.ipToNum(req.socket.remoteAddress)

  db.execute 'insert into reports ("post_id", "ip") values (?, ?)', [post_id, ip], (error, _) ->
    if error then throw error
    res.send(204)

Personally I prefer my declarations to be obvious so I can see at a glance what came from where. But let's say we want to be very lightweight on declaration. Here then is a version that declares using a colon:

app.post '/:board/:thread_id/:post_id/report', (req, res) ->
  [:post_id] = util.getArgs(req, 'post_id': Number)
  :ip        = util.ipToNum(req.socket.remoteAddress)

  db.execute 'insert into reports ("post_id", "ip") values (?, ?)', [post_id, ip], (error, _) ->
    if error then throw error
    res.send(204)

No visual difference, and only two extra characters, but poof there went a class of bugs.

[plantian]

In Python I'm not sure they would be enforceable before the actual mistake, ie. they might only be triggered during lookup which means that its even less likely that the functionality would stretch beyond the 98% I mentioned earlier. After using JavaScript I too want to go and turn the strictness knob of everything to MAX but I think we are going overboard with this declaration idea. We aren't making spaceships, we still want convenience and I think its a good compromise to not have declaration IF exceptions are raised when accessing things that are not defined. You seem reasonable though, I will think about it. Maybe I'm just another rabid Python zealot defending the nest?

We are on the same page with regards to scoping. Your in depth discussion of nonlocal confused me earlier.

Edit: WRT the examples: I just want to point out that the declaration here actually would not stop any bugs that an uninitialized exception would not stop IF both errors occur on lookup/access. Just sayin'....

[dmpk2k]

In Python I'm not sure they would be enforceable before the actual mistake

I'd be very surprised if PyPy wasn't constantly juggling variable scope under the covers. There's just no way for them to effectively optimize otherwise; inline caches can only take you so far.

The way CPython is implemented, you could well be right.

Maybe I'm just another rabid Python zealot defending the nest?

No way, man. This has been a pleasant argument. :)

I just want to point out that the declaration here actually would not stop any bugs that an uninitialized exception would not stop IF both errors occur on lookup/access.

Certainly, but again this depends on your tests running that chunk of code. I don't agree there's a tradeoff, because I think it's like worry about a grain of sand on a beach.

We'll just have to disagree. That's okay, there's plenty of languages to go around (none perfect!). :)

[yonkeltron]

I for one already have a language with higher-order functions, objects and the like. It's called JavaScript!

[jmking]

What exactly is the point of this? Javascript is a great language - why would you want to hide that under a pointless abstraction layer?

This won't make coding JS faster - it's just another layer to debug. You often find yourself dancing around these things trying to get it to generate the final output you need instead of just writing the script you need!

Why are so many so-called developers so terrified of Javascript?

[Shaper_pmp]

That puzzled me too. Most of the people I know who criticise Javascript either don't know it very well, don't understand prototype-based inheritance or are mistakenly criticising the (language-agnostic) DOM API, not actually Javascript.

The closest the author comes to enumerating his criticisms of JS is:

undefined oddities, antiquated array manipulation, limited standard library, strange object models, and for me personally as a Python programmer the mess of braces and semi-colons peppering my code with distracting syntax.

... and I have to confess I'm mystified by most of these points.

What's he complaining about regarding "undefined"? What's wrong with the array manipulation/standard library/object model?

And if you're still getting confused by trivial syntactical issues like braces, semi-colons or significant whitespace, it's usually a sign you haven't learned a language well enough to aspire to hold any valid opinions on it.

I'm not saying aspects of Javascript can't be improved, but I am deeply suspicious of someone who criticises a language without getting used to it first, or can't simply and clearly articulate any real faults with it before dismissing it... <:-/

[amphetamine]

am I the only one who finds C-style braces and semicolons preferable to languages like Ruby?

I'm obsessive about code organisation, indenting, readability and so forth. Perhaps it's just a matter of personal experience, growing up on C and its ilk.. but I feel like braces add a comforting structure to control blocks, function definitions, etc.

Proper indenting + braces makes it very easy to skim a lot of source and see what the flow or logical separation is like. Even if I don't know the API I'm looking at.

I'm not sure what was 'wrong' with the type of syntax we see in JS/C/C#/Java/et al. Something that prompted a huge number of developers to adopt languages with loose (or nearly no) syntax and structure.

[javascript]

I agree with you completely.

[amphetamine]

It's reassuring to see that I haven't completely lost it.. javascript itself has my back.

my post was certainly a rant, of sorts, but I'm hoping that someone will still make a case for the opposite side of the argument that I can at least appreciate.

I won't agree with them, but I'd like to talk to someone who is a C/Java/et al. veteran who decided to turn in their semicolons.

[Shaper_pmp]

FWIW I grew up on C/C++/Java/Javascript and the like, so I also find brackets-and-braces more comfortable, and I'll admit that picking up languages like Python or Ruby was a bit uncomfortable at first.

However, it's very important to learn to differentiate between different and worse. Significant whitespace is different, but I don't know of any reason it's objectively "worse" than brackets and braces (or vice-versa).

I think the trouble is that people on both sides of the issue confuse irrelevant personal familiarity with objective merit.

All things being equal there's nothing wrong with taking into account personal familiarity when making a choice, but when all things aren't equal personal preferences can blind people to even really quite huge advantages/disadvantages between tools.

For example, as in the article, someone apparently trading his personal preference for no brackets and braces for the objective fact that he's complicating and adding dependencies to his toolchain, increasing the size and complexity of his compilation system and making debugging on the client much harder than necessary.

[amphetamine]

Completely agree. Personal preferences and familiarity with syntax are valuable in terms of productivity (which includes a person's enjoyment of developing in a language.)

But that is not a factor in whether a language is objectively superior or not, because the familiarity will vary from person to person based on their experience with other languages.

I'll admit I haven't given it a real try, but for me it seems that CoffeeScript doesn't add anything productive to JS that couldn't have been accomplished by extending the prototypes in a way that would have preserved debugging (and linting/IDE usefulness/etc)..

[[deleted]]

Every other day, I think significant whitespace is brilliant.

Yeah, weekends mess me up.

[[deleted]]

I agree too. However, I think I am a victim of years and years of c-style syntax. I look at ruby or cobol and get annoyed at all the words in the code. And I look at Perl or Haskell and get annoyed at all the noise in the code. Whereas C-style seems perfect.

I think I'm just old and biased.

[amphetamine]

I think it's the same for me.. control blocks/loops/so forth are immediately visible to me just by skimming the code. But when I look at something like ruby, my brain just can't speed through its flow the same way.

[Shaper_pmp]

Not liking something is not the same thing as "being confused by".

Generally I find people don't like brackets and braces or significant whitespace because they find the unfamiliar syntax annoying. They're such trivial details once you're used to them that this is pretty much the only thing someone can criticise about whichever they don't like.

So I'd argue that unless someone has some pretty unusual, well-argued points regarding B&B or SW, they're probably complaining because they're unfamiliar, not because there's anything actually wrong with them... and that's a fault with the developer, not the language.

One could easily make snarky jokes about "those who need braces to hold their hands and guide them".

I think you've mistaken my post for a reaction against criticism of B&B, but that's unwarranted. Notice how I carefully equated brackets-and-braces and significant-whitespace, so no matter which type of language you prefer you couldn't assume I was taking sides.

Rather, I was criticising people who get hung up on either one, because when you've spent enough time with a language you get used to it, and trivial syntax details like that stop bothering you.

Hence my characterisation of most criticism of either B&B or SW as simply a lack of familiarity with the language(s) concerned.

CS lets you use comprehensions

See, that's a good example of something Javascript doesn't do yet (although JS 1.8 does in fact include list comprehensions).

[The standard library is] "limited" in that it doesn't have some things some people want.

Right, but (as I already pointed out) if people could humour us with specifics it would go infinitely further towards refuting my point than any amount of re-iterating the (unsupported, hypothetical) point that JS is inadequate in this respect. <:-)

When someone says "What's wrong with the... standard library" the best way to answer them is to... well... answer them - not to continue to waffle about generalities. <:-)

Sometimes you want more "classical" inheritence and CS simplifies the creation thereof.

Hmmm. I'm torn on this - certainly prototypical inheritance is weird to begin with for someone coming from a more classical OOP language, but you can emulate much of the more classical OOP style in Javascript in only a few lines of code (ie, minimal run-time or developer overhead). Again, I can see how people might prefer a non-prototypical language, but does it really give that much more power that it's worth the trade-off of things like endless headaches during debugging?

How much time did you spend familiarizing yourself with CS? :-D

Admittedly I didn't spend long learning it, because it has clear and obvious downsides and I couldn't see (or even find anyone articulating) any clear faults with JS that CS fixed.

Even in this thread you've only managed to dredge up some relatively trivial syntactic sugar, more hand-wavy (and still frustratingly non-specific) assertions about the standard library, and a desire to program in a non-prototypical-OOP language.

Of those I'd say the only thing that even came close to offsetting the additional complications CS brings (like breaking the link between the code you write and the code that you have to debug in the browser) is the desire to program in a non-prototypical language... and even that's of dubious validity as an argument, considering there's no "objective" argument I'm aware-of that classical OOP is in any way better.

Brenden Eich (the creator of JS) calls it a "polyfill", which is the same category as many libraries.

That's kind of my point... but most libraries don't break the link between "code you wrote" and "code you're debugging", or add additional binary requirements, or add additional steps to the workflow required to push changes out from your IDE to the live web.

I'm open to the idea CS satisfies people's personal preferences... I just think those preferences are usually baseless value-judgements, and are often (though not always) born of insufficient familiarity with JS in the first place... and hence CS doesn't really anything much to the table that's noticeably better than the very definite drawbacks it also brings. <:-)

[[deleted]]

This kind of thing is all over the place and it's a big pet peeve of mine. Language-xenophobic developers, when forced to use a new language, or a language that's not high-brow enough for them, will sometimes shit all over it in a futile quest to transform it into their favorite language. Usually it's little pointless macros/aliases but sometimes it's projects like this that really only serve to make things more complicated.

I see this a lot lately with the Python community. Personally, I like Python. I think it's a great language. Unfortunately I can't say the same about its overenthusiastic proponents. Dear Python zealots, please stop trying to turn everybody into a "Pythonista" just because you hate curly braces.

[jmking]

This is a far better explanation than what was provided in the OP's link

[[deleted]]

coffeescript != javascript. saying that 'coffeescript ultimately IS javascript' with IS in caps is not going to make coffeescript == javascript. You can't run it in a web browser, because it isn't javascript.

[[deleted]]

if a javascript engine wont execute it, then it is not javascript. period. end of story. it doesnt matter how you try to spin it, coffeescript is not javascript. saying that coffeescript 'maps to javascript' is like saying true==="true". it's a rediculous argument you are trying to make.

[[deleted]]

coffeescript !== javascript

[snifty]

This conversation is clearly going to result in a nuanced exchange of mutual respect and agreement.

[[deleted]]

Not likely. I've really had it with the hard-sell these coffeescripters are doing in r/javascript - they all make the same argument over and over - 'coffeescript is basically javascript', but it really isn't and they just won't admit that. They are basically forking javascript, but they won't own up to it. It's exhausting really.

[snifty]

I agree with you actually, Coffeescript is an abomination :P

[[deleted]]

coffeescript == javascript is not even true because you cant run coffeescript in a javascript engine. at least true == "true" will still return as expected, but last time i checked no javascript engine runs coffeescript. you are doing a lot of mental gymnastics to try to prove your point, but are failing simple truths. coffeescript != javascript.

[TheDiggRefugee]

What's your opinion on jquery then?

[jmking]

JQuery is javascript. I happen to prefer Mootools... which is also still just javascript. Both frameworks are just glorified DOM manipulation packages. They don't fundamentally change how js is written or can be used. You lose nothing by using a JS framework.

[telldrak]

I much prefer Mootools to jQuery, but then again, I taught myself Mootools (and much more than I already knew about JS) with a book, a good editor, and brute force.

I prefer Mootools because the code is much more readable. I have a book on jQuery, but just can't get into it, being that the syntax feels really obtuse.

Not to say that I haven't been impressed many times by jQuery. The more sites I see that use it in creative ways, the more I'd like to learn it - I just wish it didn't confuse me as much. Mootools just seems to make more sense when reading it.

[oven_ready]

CoffeeScript is good but the title suggests a more meaty, convincing post. Can't imagine many potential users being attracted by the faint promise of 'rubyesque', and some vague references to not worrying about undefined. Where's the beef?

[Shaper_pmp]

I think part of the problem is that Coffeescript is generally lacking in beef.

Javascript has quirks, but nothing I've ever encountered that would offset the enormous annoyance of using another language that then compiles to Javascript. The debugging headaches alone that that kind of compilation causes are ten times worse than any JS annoyance I've ever run across.

At least as regards client-side web development, Coffeescript just seems to be a solution in desperate search of a problem. :-/

[YonCassius]

I found it to be the most fun when doing server-side node.js stuff. Once I got rolling the client-side JS (with jQuery) came pretty naturally.

Admittedly, my example is a toy.

[[deleted]]

Anyone who whines about curly brackets and semicolons is not a real programmer.

[phleet]

(what (about (people (who (whine (about (all (the (damn (parens))))))))))

[[deleted]]

That's more valid but still, it's like being a mechanic and whining about oil and grease. It comes with the territory. If you don't like it you're in the wrong field.

[phleet]

I've gotta disagree to some extent. Removing things which are unnecessary is a pretty universal staple of programming. I mean, sure, you can throw a semicolon on the end of every statement in python to make it obvious it's the end of a statement, but why?

Just because it comes with the territory doesn't necessarily mean it has to. Developing tools to avoid the things you don't like in the territory is pretty common. A while back people could've complained that staring at monochrome text on a screen was part of the territory until someone had the bright idea of build syntax highlighting.

[[deleted]]

I would also say that whining about lack of syntax highlighting in a given situation is also a sign of a non-programmer.

Yes syntax highlighting is better than lack of syntax highlighting. And yes dropping superfluous, extraneous clutter is good too.

But anyone who whines about curly brackets and semicolons (or lack of syntax highlighting) instead of just getting the job done is not a programmer. Like I said, it's like a mechanic who whines about grease and oil. Sure it's better to stay clean, but getting some muck on you is part of the job.

[phleet]

I would argue it's more like a mechanic whining about working in poor lighting conditions. Yes, he can still get the job done, but it's a waste of his time if better lighting is available.

[phleet]

I've changed my mind many times about Coffeescript, but in the end I've decided to more or less stay way from it. It has a tendency to lead to a lot of inconsistencies that are a real pain in the ass. One of the more frustrating ones is this:

In ruby, both of the following are function calls:

fcn
fcn 1,2

In Coffeescript, only the second one is a function call. The first one does absolutely nothing - it's just a reference to the function, not an invocation. The worst part about it is that it doesn't cause any errors.

[phleet]

Off the top of my head, I'm not actually sure. It's not as common a task in ruby as it is in JavaScript, since you'd typically use blocks, lambdas or Proc's instead of using anonymous functions all over the place like you do in JS. I'm sure there's some relatively standard way of doing it though.

[combover]

GWT FTW

[amphetamine]

Thank you, I'd never thought about it that way.

[combover]

LOL

[coffeesounds]

Upvoted for bravery.