Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Case Against Using CoffeeScript

ryanflorence.com

Post reply on HN
Print view View original

91–100 of 142 posts

Re: A Case Against Using CoffeeScript

#91

Post by chc »

antirez wrote: post #88

I 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…

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 coercive equality, you coerce the object yourself.

* Loops that are used to generate functions close over their index variables, so that all inner functions don't share the final value of the index. This is the same problem that ECMAScript Harmony introduces "let" to solve.

* Splats largely replace use of the "arguments" object, so you don't get bit by "arguments" only being a faux-array.

* Comparisons can be chained, as in Python -- so you can write: "100 > x > 25", and have the answer be correct.

* Multiline strings are valid without having to escape the newline.

* And the big one: everything in CoffeeScript is an expression. Without having to use temporary variables, you can return the result of an if/else from a function, pass a comprehension (loop) directly into a function call, assign the result of a try/catch, and so on.

(http://news.ycombinator.com/item?id=1697586)

Re: A Case Against Using CoffeeScript

#92

Post by extension »

jballanc wrote: post #75
jashkenas wrote: post #61

Earlier quoted context omitted.

So, this is really interesting... JavaScript is forced to make the pessimal choice of only ever having dynamic-bound "this", because of that favorite whipping boy ... prototypal inheritance. If JavaScript had a notion of a class (even as a constructor function + prototype) definition, then it would be possible to tag methods with the correct instance reference, as in Ruby and in Python. Unfortunately, because the sta…

You should look at Lua. Yes, if you want a notion of "self" or "this" with prototypal inheritance, then it must be dynamically bound. However, this does not have to be a burden on, or even be noticeable by, the programmer. Good language design can avoid most of the pitfalls in JavaScript...

To elaborate, Lua has special syntax for defining and calling methods vs unbound functions. In Lua,

    function woot:donk() ... end
    woot:donk()
is equivalent to

    woot.donk = function(self) ... end
    woot.donk(woot)
and when you define a function normally e.g.

    function() ... end
there is no self parameter, thus the one from the parent scope is captured. The flaw with JS, really, is that it forces every function to be a method, and doesn't let you express whether you are defining one or the other.

(think I got this right, my Lua is a bit rusty)

Re: A Case Against Using CoffeeScript

#93

Post by zackattack »

samgro wrote: post #77

I just spent my entire day tracking down a missing "var" that caused a bug only in Internet Explorer. I haven't written any assembly code since college, and I hope to reach a day when I never have to write or maintain native Javascript again.

You can set up your IDE to automatically run your code through JSLint or JSHint, which will detect such errors.

Re: A Case Against Using CoffeeScript

#94

Post by ms123 »

Am 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 mean to express unambiguous statements. So does CS. So does the other languages. The resulting program will do exactly what your code asked to.

Do we check compiled code when we code in C? Do we look at the Bytecode when we write Java?

The fact that CS compiles to JS is an "implementation detail". That's the CS compiler's job. If you don't trust it, don't use it.

Re: A Case Against Using CoffeeScript

#95

Post by ricardobeat »

As a year-long CoffeeScript user, I have a few points to rebut:

debugging workflow: he makes a long list of bullet points, when in practice you can find the error directly in your coffeescript code 90% of the time, since you have a clear image of what it's compiling to and errors tend to happen on the piece you're working on. Hopefully source-mapping in Firebug/Inspector will be ready in a few months and end this discussion.

"We Process Images and Symbols Faster than Words": It has been demonstrated that the understanding of text is based on the same principle, we don't "read" words, we identify them. and and or are as much a symbol as == and && (which you still can use if you think they are more visible).

"ugly syntax": the examples are ugly. Don't use a trailing if for long conditions, don't create huge one-line comprehensions. You can do worse in javascript.

    if five and six and seven
      doSomething()
"bad parts": every language has bad parts, but the example is just bad practice. Just because you can omit return and start an object literal without indentation doesn't mean you should.

    getUser = (id) ->

      dfd = $.ajax
        url: "users/#{id}"
        format: 'json'
        method: 'get'

      return {
        url: url
        promise: dfd.promise()
      }
"Significant White-space Means CoffeeScript Will Always Be Compiled": what? No it doesn't. You can compress coffeescript, you can't minify it.

Readability is not a strength of most javascript code out there.

Re: A Case Against Using CoffeeScript

#96

Post by antirez »

chc wrote: post #91
antirez wrote: post #88

I 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…

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

#97

Post by iambot »

That was a brilliant article, the most complete honesty about coffeescript that actually makes sense. After reading it I really felt like coffeescript is cool. but you know what he's got something there. he really does => I'm going to stick to JavaScript ("See what I did there"). thanks;

Re: A Case Against Using CoffeeScript

#98

Post by premchai21 »

cheald wrote: post #81
premchai21 wrote: post #74

Earlier quoted context omitted.

What do you mean “isn't actually bound”? The function being defined using colon syntax doesn't close over self, since it's a parameter—but functions defined within that function will close over the self parameter, since it's a local from an enclosing scope: foo = { x = 3 } function foo:bar(baz) return function(thud) return thud + baz + self.x end end womble = foo:bar(4) womble(7) --> 14 Python I believe also closes o…

Ah, okay, I see what you mean. Yeah, you're absolutely right there. Point conceded. Mentally, I was separating Javascript and Lua from Ruby because while the caller is explicitly passed in Javascript and Lua (either via call/apply, or as a parameter), Ruby methods are implicitly aware of their scope (and can't really be referentially passed around like Javascript or Lua methods). Lua "methods" aren't aware of their s…

Ruby methods bound to their objects can be passed around; it's just a bit more cumbersome, in the form of « m = obj.method(:foo) » followed by « m.call(…) ». You can even do « m = :foo.to_proc » in recent Ruby and be able to « m.call(obj, …) »; this is quite useful for things like « [1, 2, 3].inject(&:+) ».

So we have that Python's dot always binds, Ruby's dot always calls, and Lua's dot is always a table lookup, with Lua's colon being a separate syntax for (always) the compound operation with injected self-argument.

And then JavaScript is the schizophrenic one: « obj.foo(bar) » is not the same as « var y = obj.foo; y(bar) ». Property lookup and function call insert a hidden step between them when and only when directly composed, and a function call without an immediately adjacent property lookup in a way injects the opposite step of making « this » in the callee be the global object (I think). “Politicians lie in cast iron sinks.”

Re: A Case Against Using CoffeeScript

#99

Post by LeafStorm »

extension wrote: post #92
jballanc wrote: post #75

Earlier quoted context omitted.

You should look at Lua. Yes, if you want a notion of "self" or "this" with prototypal inheritance, then it must be dynamically bound. However, this does not have to be a burden on, or even be noticeable by, the programmer. Good language design can avoid most of the pitfalls in JavaScript...

To elaborate, Lua has special syntax for defining and calling methods vs unbound functions. In Lua, function woot:donk() ... end woot:donk() is equivalent to woot.donk = function(self) ... end woot.donk(woot) and when you define a function normally e.g. function() ... end there is no self parameter, thus the one from the parent scope is captured. The flaw with JS, really, is that it forces every function to be a meth…

Yep, that's pretty much it. And the woot:donk() notation will only evaluate what's left of the colon once, which is nice.

Re: A Case Against Using CoffeeScript

#100

Post by skeptical »

ms123 wrote: post #94

Am 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…

It's the only implementation almost everybody knows of. I've never heard of any other, don't know if there is other.

In defense of the author, he does explain why it will most likely always be a language that will be implemented in a compile-to-js fashion.

Do we check compiled code when we code in C? Do we look at the Bytecode when we write Java? This is exactly what he is complaining about.

Also, he does makes a few points about CS syntax, that can't be the implementation's fault.

Post reply on HN