Live data from Hacker News

Discourse ditches CoffeeScript

meta.discourse.org

31–40 of 84 posts

Re: Discourse ditches CoffeeScript

#31
post #26

Am I the only one that has trouble parsing this CoffeeScript? I thought the syntax was suppose to be cleaner than plain javascript: MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName') How the hell am I suppose to read that?

Edit: previous example was incorrect as pointed out by klibertp below. Hopefully they're correct now... 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.cre…

You're wrong. The 'property' is a method on the Function prototype - take a closer look.

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.

Re: Discourse ditches CoffeeScript

#32
post #24
post #20

> CoffeeScript has significant whitespace. So instant no. It makes it a pain in the butt to parse. It's annoying. Most people (except for Python developers) don't like it. Due to being difficult to parse, you will have problems when you try to refactor. Not to mention the problems of re-indenting everything when you have really long and ugly blocks you want to clean up (happens). maybe people should stop writing unin…

No one is writing un-indented code. The issue is lack of metadata for automatic indentation. 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…

>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.

Re: Discourse ditches CoffeeScript

#33

If I've understood correctly, the most compelling argument (or at least the most seemingly objective one) is that CoffeeScript conflicts with planned features of ES6+, meaning that there is a risk that large CoffeeScript projects will be locked into the ES5 feature set. 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-bet…

Seems like a very narrow mindset. Why would they assume coffeescript won't adapt to ES6? CoffeeScript compiler can change quickly while maintaining backwards compatibility. ES6 standards move at a snails pace.

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.

Re: Discourse ditches CoffeeScript

#35

Earlier quoted context omitted.

Edit: previous example was incorrect as pointed out by klibertp below. Hopefully they're correct now... 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.cre…

You're wrong. The 'property' is a method on the Function prototype - take a closer look. 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(…

gah! you're right! I've attempted to update my comment with corrected code, but given my caffeine and sleep deprived state there's a good chance it's just as wrong as my original effort :/

Re: Discourse ditches CoffeeScript

#36

Earlier quoted context omitted.

I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken". Lots more discussion here: https://news.ycombinator.com/item?id=3379962

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.

Re: Discourse ditches CoffeeScript

#37

Earlier quoted context omitted.

I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken". Lots more discussion here: https://news.ycombinator.com/item?id=3379962

BTW, ClojureScript has proper lexical scope.

I'm not sure if you're telling me, or telling other folks in this thread, but for the record: I've fixed bugs in the ClojureScript compiler related to preserving the lexical scoping semantics :-) It's actually quite a tricky process and involves shadow tracking, symbol generation, self-calling function wrappers, and a bunch of other nonsense to deal with JavaScript's crummy semantics.

Re: Discourse ditches CoffeeScript

#38
post #26

Am I the only one that has trouble parsing this CoffeeScript? I thought the syntax was suppose to be cleaner than plain javascript: MyApp.president = Ember.Object.create fullName: (-> @get('firstName') + ' ' + @get('lastName') ).property('firstName', 'lastName') How the hell am I suppose to read that?

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.

Re: Discourse ditches CoffeeScript

#39

Earlier quoted context omitted.

You're wrong. The 'property' is a method on the Function prototype - take a closer look. 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(…

gah! you're right! I've attempted to update my comment with corrected code, but given my caffeine and sleep deprived state there's a good chance it's just as wrong as my original effort :/

If it takes that much effort to gin up example code I think the point has been made.

Re: Discourse ditches CoffeeScript

#40

Earlier quoted context omitted.

gah! you're right! I've attempted to update my comment with corrected code, but given my caffeine and sleep deprived state there's a good chance it's just as wrong as my original effort :/

If it takes that much effort to gin up example code I think the point has been made.

You're joking, right? If not, then you're trying to generalize one line of shitty code and one mistake of a tired programmer to the whole language - and I don't believe you'd want to do that!
Post reply on HN