3 ms·

Out of interest, how does coffeescript scale, and can it start to get unreadable? I worry the compression, while cute, could start to get a little extreme afte

Out of interest, how does coffeescript scale, and can it start to get unreadable? I worry the compression, while cute, could start to get a little extreme after a while, for example: class Shape constructor: (@x, @y) -> centre: -> [ @x, @y ] area: -> 0 is starting to look close to unreadable and overcompressed (in particular, the constructor implicitly declaring member variables). Also having a quick look through the bug reports, there seems to be some interesting inconsistencies, such as: x for x in [1,2,3] # x == 3 x for x in [1..3] # x == 4 I also see a complaint that: foo bar: 'baz', quux('onoz') Won't parse. I understand this should parse as: foo({bar:'baz'}, quux('onoz')) Both of these, and other little things I've seen, make me think coffeescript is more of a giant bag of good ideas, rather than a well-thought out language. In particular, is there a clear unambiguous grammar for it anywhere? I can't find one.

guywithabike 15y ago
Just like most other languages, you can abuse its features and make unreadable code. CoffeeScript is not unique in this regard.
grayrest 15y ago
> Out of interest, how does coffeescript scale, and can it start to get unreadable? It works well enough if your API design fits the language's expectations. This generally means your function calls take arguments in the order: normal args, onlyOneObject, callback. How well it scales is sort of a taste question. I like that getters/setters and some event handlers tend to be one line. Here's a pair of functions I actually wrote today (I'm building a proprietary wysiwyg text editor that isn't using contentEditable) getBlocks: -> @_breakText(block.get('value'), block.getLineBreaks()) for block in @blocks getSelection: -> try start: @input.selectionStart, end: @input.selectionEnd Here's a random longer function: _getWords: -> if @words.length @words else @_doWrap() words = [] pos = 0 size = 0 Y.all(@wrapSelector).each (el) -> size = el.get('text').length pos += size r = el.get 'region' words.push el: el size: size pos: pos top: r.top left: r.left right: r.right bottom: r.bottom @words = words You'll either think these are neat or that they're horrible. Note that the first is a comprehension and the second is a try/catch block returning an object (it can fail in some older gecko browsers if the page is still loading). > in particular, the constructor implicitly declaring member variables I think this is excessively cute as well and don't use it. Nor do I use the `x = {a, b}` producing `x = {a:a, b:b}` trick, which causes problems with implicit object parsing when the object isn't the last argument to the function. > In particular, is there a clear unambiguous grammar for it anywhere? I can't find one. There is not and there probably won't ever be. Doing one would be complicated quite a bit by the rewriting pass that happens before the compiler starts working on the code. A grammar for the resulting, unambiguous code wouldn't be too hard but that comes from the rewriter handling most of the hard corner cases.
- bergie 15y ago
  I've started preferring returning early instead of if-else. So: _getWords: -> return @words if @words.length # the other case of the method this approach makes the code read almost like English.
TrevorBurnham 15y ago
> I worry the compression, while cute, could start to get a little extreme after a while Not my experience. I love how short my code is. http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html > there seems to be some interesting inconsistencies Yeah, there are. These bug me less now than they did initially. Like any language, you have to know it well to use it well. But there's much less that you need to know about CoffeeScript than about, say, Ruby or Python. CoffeeScript's feature set is small enough that you can master it very quickly. > is there a clear unambiguous grammar for it anywhere? https://github.com/jashkenas/coffee-script/blob/master/src/grammar.coffee https://github.com/jashkenas/coffee-script/blob/master/src/g...
arckiearc 15y ago
I'm curious, would you prefer to write code like this over the explicit version? foo bar: 'baz', quux('onoz') Or are you just concerned about inconsistencies? I like not having to specify parentheses, but only do so when it's immediately obvious to a reader of the code what the result of the statement will be.
- CJefferson 15y ago
  My concern (as something thinking about trying coffeescript) is that it takes me quite a lot of mental effort to parse that, and at the moment the compiler seem to have trouble with it. I'm wondering if it practice it becomes more natural as time progresses.
  - grayrest 15y ago
    Much of your difficulty/effort is due to lack of familiarity. The rule is basically if you see an identifier followed by a space, it's a function call that ends with the line, outdent, or postfix control flow statement. An identifier followed by a colon means an object literal. I have no more trouble recognizing these patterns than distinguishing between function calls and parens being used for grouping. Part of that is due to my own enthusiastic syntax highlighting for vim [1] that leaves identifiers as pretty much the only piece of text not highlighted. If you take a look at that file, the syntax in it is very old and comes from when : was the assignment operator which was dropped when implicit object literals were introduced. [1] http://gr.ayre.st/s/vim/coffeescript_example.html http://gr.ayre.st/s/vim/coffeescript_example.html
tjholowaychuk 15y ago
I agree, other than a few operators there's nothing new here, it's just bits of ruby/py etc combined basically (the object stuff looks like yaml :) haha, kinda fun), and as you mention it looks great in small snippets, but gets really unwieldy in practice from what I've seen.
- secoif 15y ago
  I will never understand how you dislike coffeescript so much. Even if you only use it to stop having to type }); and the word function, it's worth it. Everything else is a bonus. Tried it on a real project?
perfunctory 15y ago
> make me think coffeescript is more of a giant bag of good ideas Just a giant bag, period.

guywithabike 15y ago

Just like most other languages, you can abuse its features and make unreadable code. CoffeeScript is not unique in this regard.

grayrest 15y ago

> Out of interest, how does coffeescript scale, and can it start to get unreadable? It works well enough if your API design fits the language's expectations. This generally means your function calls take arguments in the order: normal args, onlyOneObject, callback. How well it scales is sort of a taste question. I like that getters/setters and some event handlers tend to be one line. Here's a pair of functions I actually wrote today (I'm building a proprietary wysiwyg text editor that isn't using contentEditable) getBlocks: -> @_breakText(block.get('value'), block.getLineBreaks()) for block in @blocks getSelection: -> try start: @input.selectionStart, end: @input.selectionEnd Here's a random longer function: _getWords: -> if @words.length @words else @_doWrap() words = [] pos = 0 size = 0 Y.all(@wrapSelector).each (el) -> size = el.get('text').length pos += size r = el.get 'region' words.push el: el size: size pos: pos top: r.top left: r.left right: r.right bottom: r.bottom @words = words You'll either think these are neat or that they're horrible. Note that the first is a comprehension and the second is a try/catch block returning an object (it can fail in some older gecko browsers if the page is still loading). > in particular, the constructor implicitly declaring member variables I think this is excessively cute as well and don't use it. Nor do I use the `x = {a, b}` producing `x = {a:a, b:b}` trick, which causes problems with implicit object parsing when the object isn't the last argument to the function. > In particular, is there a clear unambiguous grammar for it anywhere? I can't find one. There is not and there probably won't ever be. Doing one would be complicated quite a bit by the rewriting pass that happens before the compiler starts working on the code. A grammar for the resulting, unambiguous code wouldn't be too hard but that comes from the rewriter handling most of the hard corner cases.

bergie 15y ago
I've started preferring returning early instead of if-else. So: _getWords: -> return @words if @words.length # the other case of the method this approach makes the code read almost like English.

TrevorBurnham 15y ago

> I worry the compression, while cute, could start to get a little extreme after a while Not my experience. I love how short my code is. http://www.paulgraham.com/power.html http://www.paulgraham.com/power.html > there seems to be some interesting inconsistencies Yeah, there are. These bug me less now than they did initially. Like any language, you have to know it well to use it well. But there's much less that you need to know about CoffeeScript than about, say, Ruby or Python. CoffeeScript's feature set is small enough that you can master it very quickly. > is there a clear unambiguous grammar for it anywhere? https://github.com/jashkenas/coffee-script/blob/master/src/grammar.coffee https://github.com/jashkenas/coffee-script/blob/master/src/g...

arckiearc 15y ago

I'm curious, would you prefer to write code like this over the explicit version? foo bar: 'baz', quux('onoz') Or are you just concerned about inconsistencies? I like not having to specify parentheses, but only do so when it's immediately obvious to a reader of the code what the result of the statement will be.

CJefferson 15y ago
My concern (as something thinking about trying coffeescript) is that it takes me quite a lot of mental effort to parse that, and at the moment the compiler seem to have trouble with it. I'm wondering if it practice it becomes more natural as time progresses.
- grayrest 15y ago
  Much of your difficulty/effort is due to lack of familiarity. The rule is basically if you see an identifier followed by a space, it's a function call that ends with the line, outdent, or postfix control flow statement. An identifier followed by a colon means an object literal. I have no more trouble recognizing these patterns than distinguishing between function calls and parens being used for grouping. Part of that is due to my own enthusiastic syntax highlighting for vim [1] that leaves identifiers as pretty much the only piece of text not highlighted. If you take a look at that file, the syntax in it is very old and comes from when : was the assignment operator which was dropped when implicit object literals were introduced. [1] http://gr.ayre.st/s/vim/coffeescript_example.html http://gr.ayre.st/s/vim/coffeescript_example.html

tjholowaychuk 15y ago

I agree, other than a few operators there's nothing new here, it's just bits of ruby/py etc combined basically (the object stuff looks like yaml :) haha, kinda fun), and as you mention it looks great in small snippets, but gets really unwieldy in practice from what I've seen.

secoif 15y ago
I will never understand how you dislike coffeescript so much. Even if you only use it to stop having to type }); and the word function, it's worth it. Everything else is a bonus. Tried it on a real project?

perfunctory 15y ago

> make me think coffeescript is more of a giant bag of good ideas Just a giant bag, period.