Live data from Hacker News

Why CoffeeScript Isn't the Answer

walkercoderanger.com

41–50 of 148 posts

Re: Why CoffeeScript Isn't the Answer

#41
This is a bit overly critical. The implicit parentheses are optional, so if it's confusing or ambiguous you should just use parentheses.

    func 5, {
       event: -> 45,
       val: 10}

Is reasonable but

    func 5, {
       event: (e) -> 
         if e.something
           36
         else
           45,
       val: 10}

Really ought to be split up for readability no matter what programming language you use. And besides, the only issue is the extra comma causes it not to compile.

To be fair, the `->` vs `=>` (which `this` is `this`?) for class members is confusing. I'd almost prefer class members didn't give you the option and defaulted to `=>`.

The "variable capture" section is overblown, though. You're a lot less likely to run into this issue than the classic JavaScript "I forgot `var` and now my variable is global.

My biggest complaint is actually the implicit returns. Sometimes I forget a return statement but it works anyway because of this feature. Then I come back later and modify the function slightly only to spend a bunch of time figuring out why it's returning `undefined`.

Re: Why CoffeeScript Isn't the Answer

#42
post #34

CLOJURESCRIPT IS THE ANSWER! no question about it

The problem I have with clojurescript is i couldnt find any closurescript tutorial that did not involve java.

Let's say i want to start using closurescript,like coffeescript.

i want to do npm install -g closurescript then

closurescript compile myscript or closurescript myscript.

How do I do that?

If closurescript folks want their language to be popular with javascripters i need to be able to do that.

Right now,searching on google,on npm, i did not find any tutorial that did not involve maven or java.You cant expect a nodejs developper to learn maven or install the JVM for the sake of using clojurescript.

coffeescript is popular because it's easy to get started with.You dont even need to install anything,just add the coffeescript compiler to a HTML page.

Re: Why CoffeeScript Isn't the Answer

#43
post #30

Then, for sure, Clojurescript is the answer.

Does it have a good interop? Does it require a big change in mindset? These are my questions. (Real questions, I've never used Clojure apart from some basic tutorials)

Yes and yes (it's probably arguable though: you need to export symbols to avoid getting them mangled by the google closure compiler)

But since the author dismissed Dart due to not being "true to javascript", I doubt that he'd be satisfied with it

Re: Why CoffeeScript Isn't the Answer

#44
I agree with some the things he writes, but others seem blatant absurdities:

> "the + operator is still both numeric addition and string concatenation. That is frequently listed as one of the bad parts of JavaScript. Why no provide separate operators for the two?"

The problem isn't operator overloading: the problem is implicit type coercion.

Having to use 2 separate operators/functions for separate types when writing code, is useful only if types are actually checked at compile time, and the compiler can do inference on them (see the + and +. operators in F#)

If you have a dinamically typed language, you can have sane semantics if you make it so that type conversions are explicit (e.g. Python, Ruby...)

See also: http://james-iry.blogspot.it/2009/03/operator-overloading-ad...

Re: Why CoffeeScript Isn't the Answer

#45
post #39

I do have some frustrations with CoffeeScript as outlined here - I find the unless keyword infuriating because it forces me to read backwards: a = 123 unless b == 2 "OK, so a is set to 123. Oh, unless b is 2. That's annoying" That said, my answer is to just not use the unless keyword. If you don't like CoffeeScript classes, you don't have to use them. IMO you could write CoffeeScript using only the kind of functional…

I don't know CoffeeScript, but this syntax is common in Perl.

Re: Why CoffeeScript Isn't the Answer

#46
Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules.

With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping.

I'm done, this isn't suitable for prime-time, time to go somewhere else.

I spent too many years in the 80s working with xBase. I've been shafted too many times by calling a (coworker's) routine that forgot to declare its variables "private", which stomped over one of my variables. (private in xBase is similar to local in Perl 4) To have a language which doesn't let you declare the intended scope of a variable - ugh.

Re: Why CoffeeScript Isn't the Answer

#47

This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just drop…

Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems?

He obviously knows a lot more than "day's experience".

If you make the argument that he needs to learn to write better CoffeeScript then you're lending help to his argument.

Re: Why CoffeeScript Isn't the Answer

#48
The only gripe I share is scoping, and that's fixed in LiveScript. I've started writing LiveScript in a fairly explicit style - for example I use parentheses where they improve readability and I always use curly braces for object literals. Qualitatively I think it's increased the readability of my code way beyond JavaScript. It's nice to have curly braces carry specific meaning instead of being littered all over the place.

Re: Why CoffeeScript Isn't the Answer

#49

This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just drop…

Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? He obviously knows a lot more than "day's experience". If you make the argument that he needs to learn to write better CoffeeScript then you're lending help to his argument.

I think that he should at least understand and know the CoffeeScript syntax to argue that it isn't great. If you don't know C, learnt half of it, then moaned that it didn't compile you'd look like a bit of a fool.

In this case, it's logical that a comma doesn't go there. A comma would go after the closing `}`, which is optional (and so are commas in objects). If you don't know the rules of a language, I feel like it's easier to criticise wrongly.

Re: Why CoffeeScript Isn't the Answer

#50

Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules. With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping. I'm done, this isn't suitable for prime-time, time to go somewhere else. I spent too many years in the 80s working wi…

LiveScript fixes scoping and adds a ton of other nice features including let and const variable declaration keywords.
Post reply on HN