Live data from Hacker News

In Which I Tell You to Stop Whining About CoffeeScript

singy.posterous.com

51–55 of 55 posts

Re: In Which I Tell You to Stop Whining About CoffeeScript

#51
post #13

Earlier quoted context omitted.

s/professionals/Ruby fans/

CoffeeScript is far more like Python than Ruby. The irony..!

I can see how it would give that impression due to taking a high-visibility feature in significant whitespace from Python, but other than list comprehensions, much of the rest is taken from Ruby:

Implicit returns, new conditional keywords (which don't use a Python-style : to signal the end of the conditions) and postfix conditionals, the @ operator, the ? suffix analogous to nil?, #{} for string interpolation, Ruby-style switch and (sometimes) optional parentheses can all result in very Ruby-like code, with the introduction of so many inconsistent ways to express the same statements.

Re: In Which I Tell You to Stop Whining About CoffeeScript

#52
post #24

I wonder where the blow-back is generated from. Personally, and only anecdotal of course, I feel that I have seen a far greater amount of articles extolling the virtues of CoffeeScript than I have seen condemning it. To be honest, that is the only primary source of whatever trace of resentment I feel towards CoffeeScript: I'm just almost bored of hearing about it. ( tongue in cheek ) I don't use CoffeeScript, because…

The top articles about coffeescript posted in r/javascript are anti-coffeescript articles. There are many reasons not to use Coffeescript. Some may claim that 'coffeescript is javascript', it really is not. They say it with a straight face too. People that say this don't really understand the difference between DOM and Javascript, and it is very telling. Just because you can access DOM methods and properties using co…

Some may claim that 'coffeescript is javascript'... . People that say this don't really understand the difference between DOM [sic] and Javascript, and it is very telling.

I say this, and I believe I know the difference between the DOM and JavaScript, and have since before I've said that CoffeeScript "is" JavaScript. The DOM is a representation of HTML and XML document specified by the W3C, with an API for manipulation by scripts typically written in JavaScript. JavaScript is a trademark owned by the Oracle Corporation and licensed by the Mozilla Foundation, used to refer to a programming language standardized as ECMAScript, implemented by a whole bunch of vendors in a largely cross-compatible, ECMAScript Standard-compliant fashion, but often with many proprietary extensions. Would you very much mind explaining to me what I don't know about the difference between the DOM and JavaScript?

Do you agree that ECMAScript "is" JavaScript? Would you say ECMAScript Harmony "is" JavaScript? What if some future version of ECMAScript breaks backwards compatibility with ECMAScript 4, let's say, by vastly simplifying ==, but everything else stayed the same? Would you say this ECMAScript Imaginary wasn't JavaScript? It might be incompatible, but you'd still call it JavaScript, right? The point being, there is some backwards-compatibility-breaking change you would accept as not making a language "not JavaScript". So now our difference in opinion is to whether CoffeeScript's differences are enough to make it "not JavaScript".

I argue for my humble opinion that the semantics of CoffeeScript are so similar to that of ECMAScript 4 that just like ECMAScript Imaginary, you just have to take 5 minutes to read about what's different, and you'll be able to understand it just as easily.

There is a wealth of experience and all the 'gotchas' are well documented and there aren't really that many of them if you don't count anything to do with the DOM.

I agree with this. In fact, I have also been frustrated with people who don't know the difference between the DOM and JavaScript. I have never experienced this with CoffeeScript fanatics, however.

If you think changing the rules of the language regularly is a good way to develop software, then we don't have anything further to talk about.

If you think no one should ever attempt to improve an existing programming language, we also don't have anything further to talk about.

They are both straw men. Using an experimental tool is always associated with problems with the ground changing underneath you, that doesn't mean it is always not worth it. It's a tradeoff, and with "good practices", it can be worth it if you develop faster and rarely write forwards-incompatible code.

You can't have the same variable name used twice in the same source file.

The problem you are attempting to describe is the reason I currently use exclusively JavaScript in all my projects, however your description is inaccurate and misleading. You totally can have the same variable name twice in the same file. However, if one of them is in a inner scope than the other, the only way for the inner scope to shadow the outer scope to avoid munging a variable in an outer scope is for it to be a parameter to the function.

It is more difficult to read coffeescript because of ambiguity that you don't get with C style syntax.

I'm not sure what you mean by ambiguity, but I am quite certain that CoffeeScript has a provably unambiguous grammar.

Re: In Which I Tell You to Stop Whining About CoffeeScript

#53
post #41

I just finished a contract at a company of very smart engineers who decided to use Coffeescript way before I got there. The guys that I was working with were way more brilliant than I am. Guys that have machine learning books on their desks for lunchtime and are doing some amazing work that is going to benefit hundreds of millions of people around the world. To reference this quote from the article: "Any respectable…

> I'm used to Python. Indentation there is natural. Its idiomatic to what Python is. But its not in javascript. Granted, indentation should always be used in js for readability, but brackets really are needed to denote code blocks.

Why are brackets needed? Eliminating braces makes code easier to write and read (IMO) and I'd appreciate almost any indented language to follow suit where possible.

> I'm probably old school, but when I write code I need to know explicitly what it will do.

I've found this is mitigated by experience with CS. Just takes a small amount of time getting to know the language. Nowadays I have a pretty good idea of exactly what JS will be output when I'm writing CS.

> Lots of times, my original code was just as concise as the coffeescript version, and a hell of a lot more concise than what CS rendered out.

Concision in this case might be in the eye of the beholder. I find the outputted JS to be quite readable (the most important aspect) and I know what to look for and how to map it to my source code.

Would I recommend porting all of your existing JS to CS? Hell no! But I'd give CS another try for a new project and see if you like it. I think it would click if you used it to actually program toward an end rather than port existing JS. I can see the latter being frustrating, seeing how many different patterns there are for JS development.

Re: In Which I Tell You to Stop Whining About CoffeeScript

#54
post #44

I love the great interaction between backbone.js and coffeescript. It's not often that you get two pieces of software that work so well together.

How in particular do they work well together? Backbone is something I've been meaning to try out.

They work together about the same as CS does with any JS module/app.

Backbone apps tend to have a lot of references to this and use a lot of object literals, so there are some saved keystrokes I guess.

Re: In Which I Tell You to Stop Whining About CoffeeScript

#55
post #21

It's a matter of taste. If you like Ruby, check out CoffeeScript. If you don't now there's Google Dart. The IDE is pretty nice. None of the above? Closure Compiler, jshint etc. are your friends. Edit: a good article about "verbal vs visual" programming languages: http://ryanflorence.com/2011/2012/case-against-coffeescript/

It's not just Ruby fans that like CS - it shares a lot of syntax design choices, but I think those should be taken on their own merits and not just "Durr hurrr JS for Ruby devs!!"

That article is good, and I prefer the standard operators (&&,||,!==,===) to their english counterparts. The good news is you can still use them in CS.

The other problems in that article aren't from CS itself, but rather how people write code with it. After a certain point, nested anon callbacks are terrible in JS (fat arrow complaint). Same thing with complex one-liners. You can wreak the same havok with pure JS.

Post reply on HN