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

Discourse ditches CoffeeScript

meta.discourse.org

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Discourse ditches CoffeeScript

#71

Post by nahname »

TazeTSchnitzel wrote: post #64
nahname wrote: post #38

Earlier quoted context omitted.

If you were to read the equivalent javascript as a one liner it would be hard to read too. Probably more so. Really, all you are pointing out is that you can write shitty code in any language. No language protects you. 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.

Nonsense. The equivalent JavaScript is clearer, albeit more verbose.

Neither is very palatable.

MyApp.president = Ember.Object.create(({fullName: (function() {return this.get('firstName')+' '+this.get('lastName');}).property('firstName', 'lastName')}));

MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

Re: Discourse ditches CoffeeScript

#72

Post by dclowd9901 »

snprbob86 wrote: post #36
batgaijin wrote: post #25

Earlier quoted context omitted.

Um... I believe JS does have proper lexical scoping. Could you source any evidence to the contrary?

JavaScript's lexical scoping is function-level. There is no block level lexical scoping, so variables are "hoisted" to the containing scope. This is why people use the (function(foo){...})(bar) trick to create lexical scopes, such as when looping (CoffeeScript's `do` keyword embodies this pattern). In my opinion, "proper" lexical scope implies shadowing without hoisting.

If you understand hoisting as a characteristic of JavaScript, its behavior is very predictable, and thus, hardly broken -- merely tricky if you've yet to encounter a hoisting-related issue.

That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.

Re: Discourse ditches CoffeeScript

#73

Post by mistercow »

eurleif wrote: post #53
mistercow wrote: post #44

Earlier quoted context omitted.

Also, using really common identifier names (like "log") in outer scopes is a bad idea regardless of how your language's scoping works. Writing `{log} = Math` at the top of the file is just polluting your namespace for no good reason. You shouldn't do it, just like you shouldn't use `from math import *` in Python.

But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code). Enforcing best practices by throwing errors where other langu…

It's not a bug, but it is an unfortunate quirk of the language. But find me a useful language without any unfortunate quirks, and I'll give you some sort of medal.

My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.

Re: Discourse ditches CoffeeScript

#74

Post by TazeTSchnitzel »

nahname wrote: post #71
TazeTSchnitzel wrote: post #64

Earlier quoted context omitted.

Nonsense. The equivalent JavaScript is clearer, albeit more verbose.

Neither is very palatable. MyApp.president = Ember.Object.create(({fullName: (function() {return this.get('firstName')+' '+this.get('lastName');}).property('firstName', 'lastName')})); MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName')

At least I can look at the first one and it's more obvious to me what it does. The braces help.

Re: Discourse ditches CoffeeScript

#75

Post by cwp »

jacquesc wrote: post #65
cwp wrote: post #57

Earlier quoted context omitted.

What makes you think CoffeeScript can target ES6 while maintaining backwards compatibility? Did you read the discussion? Wycats makes a very good argument for the opposite position.

Yep, I did read the discussion. I think wycats brings up a perfectly good concern, but the key point which he misses is that there is time, and CoffeeScript can change to fix what I think is a very solvable issue. The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then. For me it's not hard to imagine a CoffeeScript 2.0 relea…

So, basically, CoffeeScript can't target ES6 while maintaining backwards compatibility, but it doesn't matter, because they have time to manage the transition. Ok, that may well be.

Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then; there's no reason it has to happen now.

Re: Discourse ditches CoffeeScript

#76

Post by rodw »

cwp wrote: post #75
jacquesc wrote: post #65

Earlier quoted context omitted.

Yep, I did read the discussion. I think wycats brings up a perfectly good concern, but the key point which he misses is that there is time, and CoffeeScript can change to fix what I think is a very solvable issue. The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then. For me it's not hard to imagine a CoffeeScript 2.0 relea…

So, basically, CoffeeScript can't target ES6 while maintaining backwards compatibility, but it doesn't matter, because they have time to manage the transition. Ok, that may well be. Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then ; there's no reason it has to happen now.

CoffeeScript can't target ES6 while maintaining backwards compatibility

Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

CoffeeScript is to JavaScript as Closure is to the JVM.

Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.

Re: Discourse ditches CoffeeScript

#77

Post by cwp »

rodw wrote: post #76
cwp wrote: post #75

Earlier quoted context omitted.

So, basically, CoffeeScript can't target ES6 while maintaining backwards compatibility, but it doesn't matter, because they have time to manage the transition. Ok, that may well be. Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then ; there's no reason it has to happen now.

CoffeeScript can't target ES6 while maintaining backwards compatibility Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1] It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need…

Because of the 1JS principle, ES6 will be a strict superset of ES5. CoffeeScript can maintain its existing semantics, produce the same JS output that it does now, and nothing will break. But then it's not really targeting ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does, from ES6's backward compatibility with ES5.

So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.

Re: Discourse ditches CoffeeScript

#78

Post by eurleif »

mistercow wrote: post #73
eurleif wrote: post #53

Earlier quoted context omitted.

But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code). Enforcing best practices by throwing errors where other langu…

It's not a bug , but it is an unfortunate quirk of the language. But find me a useful language without any unfortunate quirks, and I'll give you some sort of medal. My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.

And my point is that you can't watch out and protect yourself from it, because the quirk can be triggered by different code from the code you're actually writing. You can carefully write code that works just fine, and then, unbeknownst to you, someone else can modify a completely different part of the file, and break your code. How do you protect yourself from that? By making sure that every single person with commit access always follows best practices? Good luck.

Please don't say something along the lines of, 'If you hire bad coders, what do you expect to happen?' Bad coders are almost inevitable, and their harm should be confined to code they actually write. Their bad code shouldn't have spooky action at a distance on good code someone else wrote.

Re: Discourse ditches CoffeeScript

#79

Post by rodw »

cwp wrote: post #77
rodw wrote: post #76

Earlier quoted context omitted.

CoffeeScript can't target ES6 while maintaining backwards compatibility Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1] It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need…

Because of the 1JS principle, ES6 will be a strict superset of ES5. CoffeeScript can maintain its existing semantics, produce the same JS output that it does now, and nothing will break. But then it's not really targeting ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does, from ES6's backward compatibility with ES5. So sure, if we're not interested in the new features of ES6 in the first plac…

To be candid I don't know the details of what is changed in ES6. Is there a specific aspect of ES6 you're thinking of?

But the new features of ES6 aren't features of CoffeeScript. Why would we expect them to be?

It's like noting that Java 7 adds support for strings to switch statements and wondering how the syntax of Closure is going to change in response.

There is no strict requirement for the languages to be tied together at a syntax level, they just "compile" to something compatible.

There may be strong technical reasons for the CoffeeScript compiler to take advantage of the new features of ES6, but that doesn't force a change to CoffeeScript-the-language. (In other words, it can target ES6 while remaining backward compatible.)

I wouldn't be surprised to discover I'm missing something, but I'm genuinely confused why this is seen as a technical problem. It's not that CoffeeScript-the-language is "not interested in the new features of ES6", but that, technically speaking, CoffeeScript-the-language is not interested in ES-the-language at all.

Apples and oranges. (Or maybe lemons and limes.)

As an aside, I do see this as a potential social problem. CoffeeScript would probably like to remain conceptually-compatible with JavaScript, and that gets much harder if the two have different semantics for similar syntax-es, but I'm going to guess this isn't the only example of it.

Re: Discourse ditches CoffeeScript

#80

Post by mistercow »

eurleif wrote: post #78
mistercow wrote: post #73

Earlier quoted context omitted.

It's not a bug , but it is an unfortunate quirk of the language. But find me a useful language without any unfortunate quirks, and I'll give you some sort of medal. My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.

And my point is that you can't watch out and protect yourself from it, because the quirk can be triggered by different code from the code you're actually writing. You can carefully write code that works just fine, and then, unbeknownst to you, someone else can modify a completely different part of the file, and break your code. How do you protect yourself from that? By making sure that every single person with commit…

>And my point is that you can't watch out and protect yourself from it

Of course you can. You simply enclose the block in an immediate function (using "do") and declare your local variables as parameters to the function. Do that, and it is impossible for any outer scope to screw your code up.

If you're working on a project where lots of coders of questionable aptitude are going to have commit access, you make declaring local variables this way a required convention.

If you're working on a project where changes get approved by a small number of capable maintainers, then you:

1. Do not allow commits that create short or common names (i, x, arr, log, etc.) in high scope levels, and

2. Require that short or common names in inner scopes be declared using local scoping via "do".

Now, should CoffeeScript give some nicer sugar to encourage this kind of local variable use? Yes, probably. But it is incorrect to say that CS doesn't give you the tools to protect yourself from outer scope pollution.

Post reply on HN