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

Announcing CoffeeScript 2

coffeescript.org

Post reply on HN
Print view View original

71–80 of 220 posts

Re: Announcing CoffeeScript 2

#71

Post by madeofpalk »

kbenson wrote: post #45
madeofpalk wrote: post #30

Earlier quoted context omitted.

Coffeescript's => binds this. Javascript's => also binds this (more or less) Seems to map fairly well conceptually.

> Javascript's => also binds this (more or less) Javascript's => doesn't bind this though, and function does, which was my point (and is what the reference I included was saying). That's a specific change in JS, and either coffeescript had code in place to emulate the current behavior in prior versions where they used function(), or they have code in place now to emulate function() now that they're using =>. I'm goin…

> Javascript's => doesn't bind this though

I think we're getting our wires crossed. Both Javascript and CoffeeScript have (more or less, for the common use cases) the same `this` behaviour for =>. It preserves the `this` value from the context.

Re: Announcing CoffeeScript 2

#72

Post by methyl »

ralmidani wrote: post #41

CoffeeScript is still very relevant for me. I have two medium-sized Ember projects written in CoffeeScript (and Emblem and Sass--the original, indented variety, thank you very much). I have been looking at React (will probably skip due to the patent license) and Vue, but cannot imagine going back to semicolons and (excessive) curly braces and parens. If you married CoffeeScript just out of convenience (being able to…

> cannot imagine going back to semicolons

Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

Re: Announcing CoffeeScript 2

#73

Post by fivesigma »

williamdclt wrote: post #37
melling wrote: post #20

Earlier quoted context omitted.

I was browsing the CoffeeScript docs and everything looks much more concise. It seems like your code would half the size. Have people done real world comparisons on large code bases? Rewrites?

We did. And had to "decaffeinate" everything a few months later because it is hell to work with implicit returns, objects without brackets, no spread operator, significant whitespace, no variable declaration keyword... It really is a matter of taste, but the large majority of us didn't like it. It is pretty, but I felt like fighting against the language all the time (implicitly returning an bracketless object is not…

This mirrors my experience as well. Try having a relatively simple piece of code exhaust all available memory because CS was kind enough to turn a simple loop into a clusterfuck of epic proportions all because you forgot to return null on a function that well, doesn't need to return anything. Then you go and decaffeinate the entire thing, actually look at the JS output and your jaw drops at the amount of useless crap that your "syntactic sugar" added. Is it really worth it?

This could easily be fixed by adding a -!> operator that disables implicit returns, but no, they are so opinionated that a change like that will ruin their perfect little universe. I know that there are forks that add this sort of functionality among fixing some of my other gripes with CS but my point still stands: I'm not going to invest my time into a cult.

Re: Announcing CoffeeScript 2

#74

Post by kbenson »

irishsultan wrote: post #65
kbenson wrote: post #45

Earlier quoted context omitted.

> Javascript's => also binds this (more or less) Javascript's => doesn't bind this though, and function does, which was my point (and is what the reference I included was saying). That's a specific change in JS, and either coffeescript had code in place to emulate the current behavior in prior versions where they used function(), or they have code in place now to emulate function() now that they're using =>. I'm goin…

Old Coffeescript behaviour for => was to use a function where this was bound to that of the environment. This seems subtly different from having this not being bound at all (in that you can't rebind it under the new translation), but that's unlikely to have been a common use case. The main other difference seems to be that there is no arguments object for the local function anymore, although once again that's unlikel…

> Old Coffeescript behaviour for => was to use a function where this was bound to that of the environment.

Okay, so it sounds like coffeescript 1.0 => was effectively doing what JS => does now, so it makes sense to move to the newer JS syntax Thanks for elaborating! (It's interesting how "binds this" can, and was interpreted in multiple ways, Perhaps there's a better, more specific wording I could have used to cut through those misunderstandings, whether they be with those that replied or me reading their replies).

Re: Announcing CoffeeScript 2

#75

Post by likeclockwork »

kbenson wrote: post #45
madeofpalk wrote: post #30

Earlier quoted context omitted.

Coffeescript's => binds this. Javascript's => also binds this (more or less) Seems to map fairly well conceptually.

> Javascript's => also binds this (more or less) Javascript's => doesn't bind this though, and function does, which was my point (and is what the reference I included was saying). That's a specific change in JS, and either coffeescript had code in place to emulate the current behavior in prior versions where they used function(), or they have code in place now to emulate function() now that they're using =>. I'm goin…

You have it backwards. => in JS binds this, and => in coffee used to bind this also but now just emits JS' =>. => in JS was pretty much taken from coffee, there was no prior version of => in JS.

Coffee also has -> which desugars to a regular function() {}

Re: Announcing CoffeeScript 2

#76

Post by twykke »

DiThi wrote: post #51
williamdclt wrote: post #37

Earlier quoted context omitted.

We did. And had to "decaffeinate" everything a few months later because it is hell to work with implicit returns, objects without brackets, no spread operator, significant whitespace, no variable declaration keyword... It really is a matter of taste, but the large majority of us didn't like it. It is pretty, but I felt like fighting against the language all the time (implicitly returning an bracketless object is not…

> implicit returns In my experience it has only been a problem when porting existing code bases. We only had to be a bit careful putting a return after a for loop at the end of a function so it doesn't build a list unnecessarily (otherwise implicit returns of unused random values don't hurt). For clarity, one of the few rules we have is to use return explicitly when a function is more than a single expression. > obje…

some colleagues of mine have complained about the significant whitespace being difficult to understand. i can't argue with something subjective like that.

however i like to point that our entire codebase, CS, JS, TS, Python, Java, Swift, 100% of it already has significant whitespace.

...it's just that the JS/TS/Java also have curly brackets.

Re: Announcing CoffeeScript 2

#77

Post by ralmidani »

twykke wrote: post #68
ralmidani wrote: post #41

CoffeeScript is still very relevant for me. I have two medium-sized Ember projects written in CoffeeScript (and Emblem and Sass--the original, indented variety, thank you very much). I have been looking at React (will probably skip due to the patent license) and Vue, but cannot imagine going back to semicolons and (excessive) curly braces and parens. If you married CoffeeScript just out of convenience (being able to…

i also don't use CoffeeScript because of any 'feature' it has over standard JS but instead because of its concise but expressive syntax. it's less about what it does have/do, and more about what it doesn't have/do. some small aspects of CS i forgo because they (in my opinion) are a little too concise such that they sacrifice readability, but all in all it has my favorite syntax of any language.

Exactly.

I personally think calling .map() on an array is more readable than an array comprehension. But since CS is "just JavaScript" you are free to use the native JS array methods (and even more elegantly, at that).

Re: Announcing CoffeeScript 2

#78

Post by kbenson »

madeofpalk wrote: post #71
kbenson wrote: post #45

Earlier quoted context omitted.

> Javascript's => also binds this (more or less) Javascript's => doesn't bind this though, and function does, which was my point (and is what the reference I included was saying). That's a specific change in JS, and either coffeescript had code in place to emulate the current behavior in prior versions where they used function(), or they have code in place now to emulate function() now that they're using =>. I'm goin…

> Javascript's => doesn't bind this though I think we're getting our wires crossed. Both Javascript and CoffeeScript have (more or less, for the common use cases) the same `this` behaviour for =>. It preserves the `this` value from the context.

Yes, that's what was explained in the sibling. There's a lot of confusion on what "binds this" can mean, and while I thought you might have been misinterpreting me, I may have been misinterpreting you. I was using the terminology that MDN uses in reference to the function arrow, but in the context of this question, some additional elaboration might have been useful to distinguish exactly what "this" is when it's bound (the calling environment, or the current subject being called on as is often the case).

Re: Announcing CoffeeScript 2

#79

Post by twykke »

ralmidani wrote: post #77
twykke wrote: post #68

Earlier quoted context omitted.

i also don't use CoffeeScript because of any 'feature' it has over standard JS but instead because of its concise but expressive syntax. it's less about what it does have/do, and more about what it doesn't have/do. some small aspects of CS i forgo because they (in my opinion) are a little too concise such that they sacrifice readability, but all in all it has my favorite syntax of any language.

Exactly. I personally think calling .map() on an array is more readable than an array comprehension. But since CS is "just JavaScript" you are free to use the native JS array methods (and even more elegantly, at that).

list comprehensions was exactly what i was talking about :) however i replace them with lodash and ramda, which benefit enormously from CS's lambda syntax

Re: Announcing CoffeeScript 2

#80

Post by ralmidani »

methyl wrote: post #72
ralmidani wrote: post #41

CoffeeScript is still very relevant for me. I have two medium-sized Ember projects written in CoffeeScript (and Emblem and Sass--the original, indented variety, thank you very much). I have been looking at React (will probably skip due to the patent license) and Vue, but cannot imagine going back to semicolons and (excessive) curly braces and parens. If you married CoffeeScript just out of convenience (being able to…

> cannot imagine going back to semicolons Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

I like consistency. And I am paranoid. When I write JS, I always include semicolons. When I write CS, it is a non-issue.
Post reply on HN