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

101–110 of 142 posts

Re: A Case Against Using CoffeeScript

#101

Post by masklinn »

jashkenas wrote: post #61
wycats wrote: post #13

Earlier quoted context omitted.

First-class functions have the `this` problem in every language, and the fat arrow is very nice syntactic sugar for what you have to do anyway Not true. JavaScript's `this` binding is absolutely not the only way to do it. In Ruby: class Foo def hello return proc { self } end end puts Foo.new.hello.call #=> # In Python: class Foo(object): def hello(self): def zoo(): return self return zoo zoo = Foo().hello() print(zoo…

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…

> JavaScript is forced to make the pessimal choice of only ever having dynamic-bound "this", because of that favorite whipping boy ... prototypal inheritance.

I don't think that's true: functions accessed via objects could very well be bound to the object (that's what Python does, accessing a method via an object instance returns a "bound method" which is curried with the instance, whereas accessing the same method via the class returns an "unbound method" which requires a class instance as its first argument).

Re: A Case Against Using CoffeeScript

#102

Post by kristopolous »

what about these reasons:

1. It's trendy. Snooty programmers use them. 2. It's hyped. Annoying masters of hyperbole won't shutup about it. 3. javascript is already easy to write, easy to read, easy to use, and well understood.

But really it's because I despise hype at such a deep and fundamental level; it leads people to being impulsive and emotional; making decisions based on personal reasons rather than finding the right tool fo the job.

countless times i've seen people work significantly longer and harder with the hype technology then if they had just been solid project managers and made good decisions regardless of what is being currently blogged about.

other times i've had legacy systems that were built in the super-trendy tech of yesteryear that was a fly-by-night and nobody uses any more ...

sometimes you will have managers for instance, that wlil request something like perl code to be rewritten in ruby or some other rearranging of the deck chairs kind of activity. It's a complete and utter waste of time. I'd rather go home and click on all those nsfw tags ...

so yeah, no freakin' way; unless there is native support, it's been around for a few years, and there is actual real solid evidence that it doesn't suck (extra time that is) for a similar goal.

Re: A Case Against Using CoffeeScript

#103

Post by jashkenas »

masklinn wrote: post #101
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…

> JavaScript is forced to make the pessimal choice of only ever having dynamic-bound "this", because of that favorite whipping boy ... prototypal inheritance. I don't think that's true: functions accessed via objects could very well be bound to the object (that's what Python does, accessing a method via an object instance returns a "bound method" which is curried with the instance, whereas accessing the same method v…

That works in Python, because Python has a distinction between an "instance" object, and, say, a Dict. In JavaScript an object is an object is an object -- under your proposed change, what would be the value of "this, in this:

    Klass.prototype.method = options.method;

Re: A Case Against Using CoffeeScript

#104

Post by jashkenas »

judofyr wrote: post #89
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…

This isn't really about prototypal inheritance. If you wrote methods like this in Ruby, you would have the same issue: Klass.method := lambda { p self } Also, if JavaScript looked like this, you wouldn't need the fat arrow: // Let's call this a "prototype function" Klass.prototype.function method() { … } Together with these rules: * A function always captures its outer `this` * The getter of a prototype function (`th…

Absolutely. I don't mean that dynamic "this" is required by prototypal inheritance in general -- I mean that it's required because of JavaScript's particular implementation of prototypes, where they're exposed to you as a value, but there's no syntax where the language can tell that you're in the process of building one out.

Re: A Case Against Using CoffeeScript

#105

Post by masklinn »

jashkenas wrote: post #103
masklinn wrote: post #101

Earlier quoted context omitted.

> JavaScript is forced to make the pessimal choice of only ever having dynamic-bound "this", because of that favorite whipping boy ... prototypal inheritance. I don't think that's true: functions accessed via objects could very well be bound to the object (that's what Python does, accessing a method via an object instance returns a "bound method" which is curried with the instance, whereas accessing the same method v…

That works in Python, because Python has a distinction between an "instance" object, and, say, a Dict. In JavaScript an object is an object is an object -- under your proposed change, what would be the value of "this, in this: Klass.prototype.method = options.method;

> That works in Python, because Python has a distinction between an "instance" object, and, say, a Dict.

Not really, it's trivial to create a dict-like object which allows access to keys as properties, just override `__getattr__`.

> In JavaScript an object is an object is an object

No, objects can have a non-null [[prototype]] indicating it was created from using `new` on a constructor.

> Klass.prototype.method = options.method;

Depends what `options` is.

Re: A Case Against Using CoffeeScript

#106

Post by MatthewPhillips »

My biggest problem is that because it lacks firm rules in a lot of area, CoffeeScript is a language that is not always intuitive. With JavaScript it's pretty simple to know the rules; they are completely uniform. Not so with CoffeeScript. Here's my biggest gripe:

  greet = (greeting, person) ->
    "#{greeting} #{person}!"

  greet "Hello", "world"
That's simple. A function that takes 2 parameters, separated by a comma. But wait, here's another:

  longRunning = (onsuccess, onerror) ->
    dosomething (e) ->
      if not e.error? onsuccess() else onerror()
And the implementation:

  longRunning
    () -> "Yippee!"
    () -> "Oh noes"
A function with 2 parameters, this time separated by a carriage return, not commas. How would one know that intuitively? That some times functions parameters are separated by commas and some times by carriage returns? Or that some times function calls have to include the () (when they have no parameters) and some times they don't (when they do have parameters)?

I'm sure these things become second nature over time, but learning them will result in a lot of trips to StackOverflow as you wonder why your code doesn't behave as expected.

Re: A Case Against Using CoffeeScript

#107

Post by jashkenas »

MatthewPhillips wrote: post #106

My biggest problem is that because it lacks firm rules in a lot of area, CoffeeScript is a language that is not always intuitive. With JavaScript it's pretty simple to know the rules; they are completely uniform. Not so with CoffeeScript. Here's my biggest gripe: greet = (greeting, person) -> "#{greeting} #{person}!" greet "Hello", "world" That's simple. A function that takes 2 parameters, separated by a comma. But w…

One wouldn't know that intuitively, because what you wrote:

    longRunning
      () -> "Yippee!"
      () -> "Oh noes"
... is not valid CoffeeScript. I'm not sure where you got that from.

Ideally, you'd write it:

    longRunning onSuccess, onError
Or, if you really wanted to use two inline functions instead of local variables:

    longRunning (-> "Yippee!"), (-> "Oh noes")

Re: A Case Against Using CoffeeScript

#108

Post by dextorious »

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…

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.

Re: A Case Against Using CoffeeScript

#109

Post by roestava »

kristopolous wrote: post #102

what about these reasons: 1. It's trendy. Snooty programmers use them. 2. It's hyped. Annoying masters of hyperbole won't shutup about it. 3. javascript is already easy to write, easy to read, easy to use, and well understood. But really it's because I despise hype at such a deep and fundamental level; it leads people to being impulsive and emotional; making decisions based on personal reasons rather than finding the…

In other words, you find it more advantageous to be a late adopter, which is fine as well.

Letting the market to select the tools you'll be using seems like a standard approach to most people.

Early adopters can be such trouble makers. All tools bring tradeoffs with them and many times early adopters don't anticipate them all.

Re: A Case Against Using CoffeeScript

#110

Post by jashkenas »

There 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 when you run CoffeeScript in production should be no surprise -- that's the point. But it's also quite a large hurdle to jump.

What's interesting about CoffeeScript is that despite there being a strong case against using it -- and I try to make the same case in my workplace -- people still find it useful enough, and transparent enough, to use it regardless.

As of this morning, CoffeeScript is the 13th most popular language on GitHub, and the second most popular module in npm, after Underscore. All of the top ten languages on GitHub date from the mid-1990s or earlier.

https://github.com/languages/ http://search.npmjs.org/

The better question is not "What is the case against using CoffeeScript?" ... but instead: How is it that despite all of the obvious hurdles stacked against a new source-to-source language, people are actually using CoffeeScript?

That's the question I'd like to know the answer to.

Post reply on HN