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

Why CoffeeScript Isn't the Answer

walkercoderanger.com

Post reply on HN
Print view View original

101–110 of 148 posts

Re: Why CoffeeScript Isn't the Answer

#101

Post by ilaksh »

solox3 wrote: post #15

delayed: () -> -> this.model # isn't the class Well, that isn't really fair now, is it? You could have used the fat arrow (`=>`) for binding `this` to the class. With that in mind, I agree with the author in that CoffeeScript isn't the answer, at least not exactly. With syntax this incredibly similar, how far are we from compiling python (with generators, with statements, imports, ...) to JavaScript?

CoffeeScript is more readable than Python.

If you really get familiar with CoffeeScript then you will see that the benefits add up over JavaScript.

If you want a nice Python-like language with import statements and many interesting features that compiles to JavaScript, take a look at Nimrod.

Re: Why CoffeeScript Isn't the Answer

#102

Post by rubyn00bie »

ilaksh wrote: post #97
freyr wrote: post #92

>> Why CoffeeScript Isn't the Answer What is the question for which CoffeeScript is a compelling answer? "I needed to speak to Germans, so I learned French and spoke through a French-German interpreter. Things were occasionally lost in translation and somteimes I couldn't get my point across, but French is prettier. Can I recreate this experience in code?" "My team can't learn to write `var` or `===`. Can we just lea…

http://en.wikipedia.org/wiki/Status_quo_bias CoffeeScript obviously solves problems. Its not compelling to you because of status quo bias, and because you don't want to invest the effort to learn it. The issue with equality is a real issue. CoffeeScript solves that issue. Braces and parenthesis _do_ become awkward in JavaScript with callbacks. CoffeeScript solves that problem. You have been able to debug CoffeeScript…

Its cute you link to status quo bias, then immediately state, like a fact from god that "braces and parenthesis _do_ become awkward (...) Coffeescript solves that problem."

It's your opinion that coffeescript solves the callback and parentheses issue. I'd also call your argument a bit of red herring.

... FWIW? I think futures do a mighty fine job of solving callback issues; no coffeescript needed. Design around them, don't make a whole new "dialect" for it..

Re: Why CoffeeScript Isn't the Answer

#103

Post by aidenn0 »

z3phyr wrote: post #30

Then, for sure, Clojurescript is the answer.

Clojure is really hard for me to use, coming from a lisp background. The various special forms seem to sometimes want a list and sometimes want a vector and sometimes don't care. I've yet to find a way to keep track of that.

Anyone have a link to something from Rich mentioning why vectors are used in basic syntactic constructs? It's the one departure from its lisp roots that I couldn't figure out any motivation for.

Re: Why CoffeeScript Isn't the Answer

#104

Post by rubiquity »

Phew. I was beginning to worry that a whole month would go by without a blog post about CoffeeScript's deficiencies. I hate it when I write unidiomatic code in a language and then get punished by said language.

Now that I got my sarcasm out of the way, whenever somebody bashes CoffeeScripts variable shadowing they openly show the world that they don't understand how variable scoping should work. CoffeeScript covers up JavaScript's warts. One of those warts is JavaScript's broken implementation of closures. CoffeeScript is trying to help you, don't let your lack of understanding of lexical scope get in its way.

Re: Why CoffeeScript Isn't the Answer

#105

Post by ceronman »

This is not the first article talking about CoffeeScript's ambiguity and readability issues.

It's interesting how CoffeeScript fans almost always decide to blame the programmers for these problems. They said good developers should use common sense and use best practices to make code readable, for example by always using parentheses when calling functions. I hear exactly the same argument in the Perl community.

But reality is that if a language allows you to write bad code easily, people will write bad code, and you will have to read bad code. This is very easy to verify: most CS project on GitHub, starting with the CS code itself (http://github.com/jashkenas/coffee-script) contain a lot of bad ambuigous uses of the language. A very similar thing happens with Perl code.

Programming language design is not only about making it easy to write good code, but also about making it hard to write bad one.

Re: Why CoffeeScript Isn't the Answer

#107

Post by berdario »

Dylan16807 wrote: post #83
berdario wrote: post #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…

The problem is the combination of the two. You can have operator overloading if conversion is explicit. You can have a converting operator if the action is explicit. But you can't have loose overloading and automatic conversion at the same time without silly defects. Edit: And you didn't just disagree but call it a 'blatant absurdity' to blame the half of the problem that you happen to like better? Jeez.

I agree, "blatant absurdity" is quite a strong wording. I should've wrote "quite dubious" or the like.

In my defense, I didn't even think of having a language with type coercion and 0 operator overloading (even on builtin types). I never saw such a language, and I'm skeptical that it could work. But it's an interesting take on the problem.

I cannot say why I think that the no-coercion+overloading is the better solution... maybe that's because operators are dyadic, and thus type coercion can be executed on both sides of the operator, and multiple times. While function application is (can be?) sort of monadic (in the APL sense) since coercion/overloading for an argument doesn't depend on the type of the other arguments supplied to the function

(But while writing this, I'm not so sure anymore... at the very least, it could depend on the order in which arguments are evaluated...)

Re: Why CoffeeScript Isn't the Answer

#108

Post by kin »

Mm, most of the issues the article discusses are part of the learning curve of Coffeescript IMO. The real problem I've had (and I still love it for some reason) is dealing w/ JS frameworks. Like, try using Coffeescript w/ Angular or something. It's quite difficult.

Re: Why CoffeeScript Isn't the Answer

#109

Post by implicit »

couchand wrote: post #94
implicit wrote: post #84

Earlier quoted context omitted.

Agreed. I was responding more to the assertion that CoffeeScript doesn't have a problem with variable scoping rules. It does and the consequences are scary.

You're right that the scoping rules in CoffeeScript are unintuitive for someone coming from a statically-typed, declare-everything paradigm. But I'd hesitate to call it a problem. It's a feature not a bug that the same symbol in nested scopes always refers to the same variable. As I said previously, I believe code that relies on variable shadowing to work correctly is broken. I've been hit by the scoping rules many t…

I agree that shadowing is bad.

Implicitly scoping variables to their lexically-outermost point of use is a terrible solution, though: changing anything in any outer scope can completely change the meaning of code in all nested scopes. That's really really bad.

A much better syntax would is to require the 'var' keyword to denote the scope of every variable, but reject shadowed symbols at compile time.

Re: Why CoffeeScript Isn't the Answer

#110

Post by shittyanalogy »

It's a tool, that is all.

Ambiguous code is a poorly thought out contrived example with a simple solution.

To me, this:

    eat food for food in foods when food isnt 'chocolate'
Is kind of beautiful and much more readable than:

    for (var i = 0, var len = foods.length; i
How is this even an argument?: "One wouldn’t realize it was conditional until reading the end." How do you expect to understand any code without reading it? How do you understand people when they talk without listening? And the whole paragraph is moot with syntax highlighting.

Variable clobbering is javascript's problem not coffescript's.

ECMAScript 6 introduces a syntactic sugar for classes as well as like every single JS framework.

Knowing plain old JS is important, especially for understanding CS. CS is just a tool that some people find useful, I don't really understand the passion or frustration.

Post reply on HN