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

81–90 of 148 posts

Re: Why CoffeeScript Isn't the Answer

#81

Post by bernardom »

couchand wrote: post #20

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…

Rather than downvote, I'm going to comment.

I think you could have made your points just as strongly without attacking the author.

Re: Why CoffeeScript Isn't the Answer

#82

Post by __david__ »

camus2 wrote: post #42
h1karu wrote: 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,search…

There's even a button at the top of the main coffeescript page. It's so very convenient.

http://coffeescript.org/#try:console.log%20%22hello%20world%...

Re: Why CoffeeScript Isn't the Answer

#83

Post by Dylan16807 »

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.

Re: Why CoffeeScript Isn't the Answer

#84

Post by implicit »

joev_ wrote: post #75
implicit wrote: post #61

Earlier quoted context omitted.

The argument that "you just don't understand" can excuse any flaw in anything. If someone can reasonably choose to formulate something, and for that formulation to pass static verification but do something totally unexpected, the language is at fault, not the author.

The point is it doesn't pass static verification. It doesn't compile. It's a rather silly thing for the author to argue imho.

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.

Re: Why CoffeeScript Isn't the Answer

#85

Post by andrewvc »

aclimatt wrote: post #77

My problem with CoffeeScript has always been the syntax vs. semantics issue. CoffeeScript saw a big opportunity to improve JavaScript semantics and help programmers more easily avoid the JavaScript minefield ("var" and "===" for example), but in doing so decided "while we're at it, let's overhaul the general syntax too". Gratuitously changing "function" to "->" for no reason other than removing characters seems to in…

I totally disagree regarding 'function'. Good javascript tends to be more functional than imperative. That means using 'function' a lot. Most functional languages use either fun, fn, or lambda, all relatively short words for this because it's used ALL THE TIME.

Shortening it to two chars made sense IMHO. The long form of the word function directly impacts code quality and readability.

Re: Why CoffeeScript Isn't the Answer

#86

Post by couchand »

bernardom wrote: post #81
couchand wrote: post #20

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…

Rather than downvote, I'm going to comment. I think you could have made your points just as strongly without attacking the author.

That's a fair point. In my haste to reply I made too much of a personal attack. The phrasing I should have used is more like what ilaksh said [0], which really gets to the heart of the matter.

[0]: https://news.ycombinator.com/item?id=7497354

Re: Why CoffeeScript Isn't the Answer

#87

Post by couchand »

ilaksh wrote: post #60
couchand wrote: post #20

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…

"More than a day's experience" is not really fair. It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day. The rest of what you wrote I agree with. But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally. I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but…

Thanks for clarifying my point, since I was a bit brash.

The argument you make regarding learning a new language is solid, and I think it can also be applied to new libraries, design patterns or even just coding standards. Now that I think about it, the backwards judgement -> rationalization strategy is one of the more pressing problems facing society, and I was guilty of it just as much by judging the OP first and rationalizing second.

Re: Why CoffeeScript Isn't the Answer

#88

Post by fat0wl »

ilaksh wrote: post #60
couchand wrote: post #20

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…

"More than a day's experience" is not really fair. It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day. The rest of what you wrote I agree with. But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally. I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but…

the minutia of most efficiently optimizing your syntactic sugar to communicate DEEEEP meanings is the most annoying part of the open-source/language community & one of the biggest factors in why i've actually come to like corporate java.

i've been on so many RoR interviews where i am dismissed essentially for not knowing enough of cutesy syntax tricks and yet in the Java + plain ol' javascript projects i've worked on I've been exposed to a muuuuuch wider variety of programming design patterns than i ever was in Ruby-land, to the point where i could care less about the tiny semantics these hipsters spout on about

one of the few new languages i'm interested in working with now is Clojure simply because they cleanly define libs & then don't have all of this obsessive "syntactic sugar" nitpicking. to make a language / code library usable it shouldn't depend on developers going down a rabbit hole of brackets etc. I understand this is difficult to avoid in the "compile to js"/language pre-processor community but it's why I prefer Dart as a solution. It is an attempt at a clean, robust, simple language rather than a repeat of the annoying language evolution process where devs in the know just talk down to those who don't care to commune with punctuation all day

Re: Why CoffeeScript Isn't the Answer

#89

Post by couchand »

ulisesrmzroche wrote: post #68
couchand wrote: post #20

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…

All you did was remove the curly braces and take out a comma that probably didn't compile in the first place though. I don't get what's far better about it. Technically, Coffeescript should know better than to balk at the braces that is abstracting out when they're explicitly declared. And any compiler is going to groan when it gets to that dangling comma.

I'm well aware of how little I changed. If I were coding this in my style I'd also move the shorter key/value pair up above the function definition, or more likely simply define the function as a local variable elsewhere. It's very rare that I declare function literals within an object literal.

You're right that the comma was the real tragedy. I removed the braces to help illustrate how taking full advantage of the features of the language makes the code stronger. Strictly speaking removing the comma was all that was necessary.

Re: Why CoffeeScript Isn't the Answer

#90

Post by crazygringo »

I used CoffeeScript full-time for a year, both client-side and server-side (node.js). I completely agree with everything here -- it's a great summary, and it describes exactly while I never, ever want to use it again.

In CoffeeScript, ambiguous code is the rule, not the exception. On top of that, things like variable capture and everything-returns-a-value introduce new kinds of bugs. The author says "realistically, the issues I have raised with CoffeeScript don’t come up every day," but in my experience they pretty much did.

But the real kicker on top of it all is that none of the stuff is documented. When you're trying to guess if you should use parentheses or a comma or an indent or a newline or a backslash or what, there are no reference documents to help you. The CoffeeScript home page just has a bunch of tutorial examples which give you an overall idea, but there's nothing rigorous, and the devil is in the details when you start combining aspects of the syntax.

In the end, I'm much more productive programming in JavaScript because I know exactly how the language works, no surprises. JavaScript has its fair share of warts, but you take a day or two to learn them, and then you never need to worry about them again. CoffeeScript, on the other hand, is just endless surprises. And I still felt that way after a whole year of using it at work. It's basically unlearnable -- no matter how much experience you have, you constantly find yourself pasting different versions of a line into the "try" tab of http://coffeescript.org/ until you get one which, through trial and error, turns into the JavaScript code you want.

Post reply on HN