I've been coding CS for over a year now and I like it, I've never found it hard to debug and it's just easier to read.
1. @ = this
2. -> to => solves almost every context problem
3. Object notation by simply using colons ':'
$('body').css
color: 'red'
background: 'blue'
4. statement if condition5. jsondata?[2]?.hierarchy?.url
6. Optional brackets allow very terse/clean code:
setTimeout ->
statement
, 1000
7. (function_argument = 'default_value') ->8. Automatic return on last line
9. I also like how CS handles scoping, even though others might not. My very few globals are ALLCAPS and everything else is local scoped. I don't do things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere.
Add jQuery/Backbone/Underscore/Bootstrap to the mix and you can develop some very large, complex apps with CS in a very clean way. Of course, people may not like some of the above syntax but I love not having to write/parse 2x as much code.
However, it also provides a few new ways to shoot yourself in the foot. Automatic return may be one example. Generally, thanks to terser syntax, the code may become illegible very quickly—especially in an environment with many contributors and little care about coding style.
IMO successful CoffeeScript usage in larger projects requires strict coding guidelines. Maybe the language would even benefit from more ‘centralized’ and opinionated approach, like Python's PEPs.
This is all good and fine until you realize that this will bite your ass when you need to write performance-sensitive code. So you end up with lots of explicit 'return' statements at the end of your functions.
> 9. things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere.
It's not only for saving keystrokes, but may also be improving performance. Some reason people add `local _G = _G` to the top of Lua source files to speed up access to _G.
For me there's a noticeable productivity and enjoyment boost from the more terse syntax and that makes it more than worth it for me.
http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
Lots more discussion here: https://news.ycombinator.com/item?id=3379962
Really the problem is implicit declarations of any sort; they're great for one-liners, but they really suck when you're writing real software.
[But if you've gotta have 'em, please, at least don't copy Python...]
It's actually a funny thing -- out of all of the folks who actually have tried playing around with CoffeeScript in earnest (participated in issues or the mailing list), I can count on the fingers of one hand the number who have actually disliked working with the scoping semantics. There's a far larger number of folks who like to worry about the scope semantics without ever having tried it.
you can get it to work on mobile safari in portrait if you zoom in / out ... but that just too hacky
You might want to try providing it in HTML format.
I would stick with CoffeeScript until it becomes painful. There is relatively little downside risk. If and when you have great people refusing to contribute code because they hate CoffeeScript, well, that'll be a pain point. On the other hand, what if you get a bunch of other people who like contributing code because they can do it in CoffeeScript?
Are there meaningful statistics collected? Until there are, or at least a weighty collection of anecdotes, I'm sure there's something more important to worry about.
The sheer mass of anti-CoffeeScript FUD ironically makes it more likely that they'll get more contributions if they go back to JavaScript. ;) YOU might know people who seriously consider Erlang and Clojure, but most people respond badly to superficial syntactical differences.
Of course, is "contributions" really the best metric? What about productivity or quality? And can they make it so that people can easily contribute JavaScript?
(Even among people I know, I've heard such irrational FUD against CoffeeScript. And I know it's FUD because none of their boogiemen came true after I aggressively introduced it into their codebase. They now use it every day without concern. Most people hate innovation, including programmers.)
In particular, the ES6 argument sounds like FUD. Did they link to timelines and CoffeeScript developers' opinions? And where's the tradeoff analysis comparing the immediate productivity benefits of CoffeeScript vs some future ES6 event?
Also it looks like one of the core dev doesn't like CS much, which might have precipitated things a bit [1].
[1] http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')
How the hell am I suppose to read that?
Someone said that CoffeeScript is designed to be more writable than readable, and I'd tend to agree with that. But frankly, after having worked with it for the better part of a year, I prefer reading it than JS for just about everything. It's an acquired taste, but don't knock it till you try it :)
If you write beautiful javascript, you will write beautiful coffeescript and it will be 20-60% smaller. Reading less lines is less reading, this helps me.
it's not exactly a shining example of good coffeescript, but I think this is equivalent js
MyApp.president = Ember.Object.create({
fullName: function(){
return this.get('firstName') + ' ' + this.get('lastName');
}.property('firstName', 'lastName')
})
I'd probably write it in cs as MyApp.president = Ember.Object.create
fullName: (
-> "#{@get 'firstName'} #{@get 'lastName'}"
).property('firstName', 'lastName')
(ie multi line rather than a single line) but that's very much just stylistic choice. It's also a lousy example of the benefits of cs as the cs version doesn't add any benefit over the plain js one.Anyway, style does matter and were this line written with readability in mind you wouldn't make this mistake.
Also, I would definitely abstract over @get and property:
makeProperty = (attrs...) ->
func = () -> (@get(x) for x in attrs).join(" ")
func.property(attrs...)
MyApp.president = Ember.Object.create(
fullName: makeProperty("firstName", "lastName")
)
The parens after create are not needed, the next indented line should tell us that this is a function with arguments, but I don't mind them here.Since Discourse is planning on being around long after ES6 becomes widely available, it was a winning argument.
http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
Also, one of the big reasons the Discourse devs liked CoffeeScript is because it makes it hard to commit common JS errors. Building JSHint into their workflow can help bring this protection back.
There's other perfectly valid reasons to use pure-JS on a large open source project, but the ES6 thing is a red herring IMHO.
maybe people should stop writing unindented ugly blocks in their non-indent-significant language then?
In C if I shift a block of code a quick gg=G will reformat and reindent. Possible because blocks are explicit and whitespace is separate from scope. By the same token autogeneration of {}'s is impossible in C. This is obvious but obfuscated in Python from whitespaces' overloading.
The issue is autogeneration of blocks. In any language blocks are a fundamental aspect of programming. Blocks affect the function of a program. Since we lack self-programming computers we also lack autogeneration of blocks. Python's issue is that a non-fundamental aspect of programming has been paired with a fundamental aspect of programming.
Python's "issue" is that it considers readability as a fundamental aspect of programming and that whitespace is critical to that end. Whether that suits a particular programmer is a matter of personal preference.
Oh I beg to differ. I've seen lots of terrible unindented or patchily-indented code. Especially in Wordpress plugins.
That said, the annoying ones for me are links to Google+ things, the URL says "google.com" but the content is various.
"First, Dvorak is very good at keeping fingers on home row - 71% of keystrokes land there (compare this with 34% for QWERTY). This alone is worth the price of admission. Dvorak bottom row usage is very low at 9% (15% for QWERTY). Dvorak favours the right hand by 14% (QWERTY favours left by 15%). Dvorak has more uniform finger usage and makes greater use of the pinky (18% vs QWERTY's 10%). The cumulative run statistics illustrate Dvorak's strength in alternating hands. 62% of successive keystrokes on Dvorak do not use the same hand (rh(0)) and 88% of adjacent keystrokes use the same hand at most once (rh(1)). In contrast, with QWERTY only 51% of successive keystrokes do not use the same hand and only 76% use the same hand at most once. QWERTY forces the typist to use the same hand repeatedly, which limits the amount of rest and increases effort. Dvorak's preference for the use of the right-hand give it longer right hand runs with only 47% of keystrokes that use the right hand being followed by use of the left hand (61% for QWERTY). The corresponding statistic for the left hand is reversed, with Dvorak at 76% and QWERTY at 42%."[1]
The authors of the Reason Magazine article from 1996 that you linked to stated that "Ergonomic studies also confirm that the advantages of Dvorak are either small or nonexistent." But the authors cited only one nameless, undated study. This promotion of QWERTY isn't surprising seeing as how Reason Magazine is written by ideologues whose goals include the promotion of the idea that the invisible hand of the market is never wrong.
You should consider getting your information from specialists who are active researchers rather than the writings of non-specialists from previous decades.
Now, this only affects the first official client. I imagine that there will be a CS port of the JS client as soon as the switch is made. That's the great thing about using a client to a REST API - you can have several different front-ends. If this was to be the only client, I'm not sure if I would support using JS over CS.
(btw, I'm @benaiah on meta.discourse.org - I'm in the referenced thread)
One can write readable code with Coffeescript , i use parenthesis in big scripts because it is more readable , and i dont use classes where not appropriate.
CS helped me write better javascript without the badparts so i dont need to be a human compilator and fix javascript each time i write it. I should not have to.
http://mparaiso.github.com/Coordinates.js/
It is not for everyone , but significant white spaces are not a problem if one is used to indent his code properly. I tried typescript too , which is good, but i found coffeescript more expressive. The truth is , i enjoy writing CS , i dont writing JS.