Live data from Hacker News

A Case Against Using CoffeeScript

ryanflorence.com

81–90 of 142 posts

Re: A Case Against Using CoffeeScript

#81
post #71

Earlier quoted context omitted.

Nah; regular old Lua 5.1. The colon syntax is just syntactic sugar -- self isn't actually bound. function Foo:Bar(baz) is the same as Foo.Bar = function(self, baz); invoking Foo:Bar("rebar") is sugar for Foo.Bar(Foo, "rebar"). self is never bound - it's just passed in (explicitly, via . syntax, or implicitly, vs : syntax). In all cases, the caller is always specified. You can pass Foo.Bar around (as it's a function r…

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 scope (though closures are.

Re: A Case Against Using CoffeeScript

#82

Earlier quoted context omitted.

Thanks Ryan. I've looked at the RequireJS/AMD import stuff and it seems really over engineered for what I need. I feel like there is too much declaration going on. For now I think I'll wait to see what else people come up with along these lines.

Well, AMD is essentially a CommonJS format, so this is what "people have come up with" for the browsers until real modules show up :) http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition

Thanks for the pointer, I made sure to read it. What I don't like about it is having to 'define' all the modules that I'm going to use. That is just too error prone.

I'd rather just create a CS class in a file and include the entire file when I need to. More similar to the way that an import statement works in Java.

For now, as I already mentioned, I'm simulating import style functionality with LabJS, which works great. While not perfect, it allows me to async load everything I need as well as minimize the amount of data on the wire. Here is a description of what I've done...

http://lookfirst.com/2011/12/optimizing-your-javascript-deli...

Re: A Case Against Using CoffeeScript

#83
post #24

Earlier quoted context omitted.

> Go ahead and [do this horrible thing], it's not _that_ bad. Sure. Let me insert a few things that can have really bad side effects that I still think you should do: • Leave your house every day (car crashes ROFLstomp homicide as a cause of death) • Eat food (most foods have some ill effect on your body) • Write some code in C (it's a very unsafe language, but sometimes necessary) • Use a computer (hurts your eyes a…

Source maps will be helpful, but I still can't put a break point in my coffee script from the browser.

Assuming the coffee script files are accessible over a url, wouldn't that be possible with a Firebug extension? Which basically maps the break point to JS.

Re: A Case Against Using CoffeeScript

#84
post #41
post #36

Some languages are designed for professionals to comprehend easily at a glance: these languages use symbols instead of words, use brackets effectively and don't rely too much on whitespace. Other languages are designed to be easy for anyone: these languages use English as inspiration, using whitespace instead of brackets. CoffeeScript has a place, but not in production. It belongs in the classroom, to help those want…

Taking this argument to its logical conclusion, Perl would be the ultimate language for 'professionals' to use, since it's full of shorthand symbols. And it's true -- if you wrote the code, Perl is very easy to scan. If you didn't write the code, however, Perl is not always so easy to scan. Which is exactly the point of Ruby, Python, Coffeescript, and other similar languages. I´ve heard it said that on average, only…

There's this thing, it's called "balance"

Re: A Case Against Using CoffeeScript

#85
post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

At no point ever this:

    getUser = (id) ->
      url = "users/#{id}"
      dfd = $.ajax
        url: url
        format: 'json'
        method: 'get'
      url: url
      promise: dfd.promise()
was unreadable to me. $.ajax+'\n'+indent instantly triggers nesting, hence call, in my head. The way I instinctively parse this code makes the added parentheses just distractive noise to me. Actually I would have written it this way, which makes things tick even more:

    getUser = (id) ->
      url = "users/#{id}"
      dfd = $.ajax
        url: url
        format: 'json'
        method: 'get'

      url: url
      promise: dfd.promise()
A single newline makes the whole thing absolutely obvious to me, including the possibly ambiguous meaning around the implicit return.

> It's not a case against using Coffeescript - it's a case against writing terrible code.

Actually it looked like a case of change refusal and confirmation bias. The author seems to be well-versed in JavaScript, trying hard - consciously or not - to write JavaScript in CoffeeScript, which in turn produces terrible code. Every itch gets scratched, producing terrible irritation.

> you can’t compress [whitespace]

gzip. rake assets:precompile generates .gz for you so it doesn't even incur a performance hit on your servers.

> The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem

Me neither. In fact the mapping is most of the times fairly obvious. Besides, editor enhancements[0], though not essential, helps a bit to not have to pull stuff in the browser every single time. Anyway SMAP support (or something close) is on the way[1] but in the meantime it doesn't bother me the least with CoffeeScript, thanks to it being so close to JavaScript.

[0] http://esa-matti.suuronen.org/blog/2011/11/28/how-to-write-c...

[1] http://www.infoq.com/news/2011/08/debug-languages-on-javascr...

Re: A Case Against Using CoffeeScript

#86
The debugging problem is definitely the biggest strike against CS, so it's weird that most of the article focuses on stylistic options (all those parens, brackets, and ampersands are optional!).

I'm still feeling CS out in terms of what style works best for me (for instance: should I always wrap arguments in parens so that all function calls have parens following them?) but it's nice to have that flexibility and be able to find what I think is readable and clean. For instance, I prefer '==' because it parses better at a glance, but I find that 'is' is much faster for me to type. :/

Also the white-space argument meaning it will always be compiled is not necessarily true. CS's brevity over JS would probably make up for the significant whitespace difference.

Re: A Case Against Using CoffeeScript

#87

My code is more readable for me than yours. That’s just how it is. While the JavaScript CoffeeScript compiles looks decent, it’s still not mine. That would change if you practiced reading other peoples' code. When I see my code, I often think, "yeah, I wrote this" because I know how I name things, but other than that, my code looks like everyone else's code. I know this because I based my style on what other people d…

> That would change if you practiced reading other peoples' code. I'm really active on github, and actually read the source code of a lot of projects instead of reading books, and contribute to a bunch of them too. Quite assuming of you to assume I don't. My code, since I wrote it, will always be easier to understand because I dealt with every problem--not because of the style.

I totally agree with you there. There is something totally different about reviewing someone else's code versus reading your own. Because even if you wrote it a long time ago, it's still easy to reverse-engineer the purpose of everything you did.

Re: A Case Against Using CoffeeScript

#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 next versions of Javascript could even change syntax at some point, but to use an intermediate layer/compiler/translation stuff just for that... is strange.

Re: A Case Against Using CoffeeScript

#89
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…

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 (`thing.method`) always returns a binded function (where `this` == `thing`).

Post reply on HN