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

51–60 of 84 posts

Re: Discourse ditches CoffeeScript

#51

Post by goblin89 »

chime wrote: post #28
ansman wrote: post #5

If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no difficulty learning CS if you know JS. 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.

I've made some pretty large apps in CS, by myself and in teams. So many good things in CS that I can no longer live without when writing front-end code: 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 condition 5. jsondata?[2]?.hierarchy?.url 6. Optional brackets allow very terse/clean code: setTime…

CS offers a lot of nice syntax sugar, indeed. It helps with many common mistakes made in JS code (missing `var`s and use of '==' operator come to mind).

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.

Re: Discourse ditches CoffeeScript

#52

Post by nestlequ1k »

idle_processor wrote: post #48
jacquesc wrote: post #33

Earlier quoted context omitted.

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.

Name a couple of said valid reasons?

1) Open source projects like this would tend to want as many possible contributors as possible. There's more people out there who are comfortable with plain JS than with CoffeeScript.

2) One may prefer a more explicit language, filled with semicolons, curly braces, and "function" functions.

That said, I personally would have greatly preferred it as CoffeeScript, which I use regularly on projects where the people I work with have the same preference.

Re: Discourse ditches CoffeeScript

#53

Post by eurleif »

mistercow wrote: post #44
notb wrote: post #12

Earlier quoted context omitted.

Lexical scoping is a term to classify languages. The 'point' is to make it easier to understand how a language behaves. If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE. Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/...

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 languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.

Re: Discourse ditches CoffeeScript

#54

Post by bawllz »

raganwald wrote: post #43

I find this a curious debate to have so early in Discourse's life. There doesn't appear to be a pain point, so it's mostly speculation. If this happens, then that consequence, but if this happens, then that other consequence... 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…

There is a distinct possibility that the conversation was a chosen topic to try to get at the top of HN, so that we could all go and be consumed by the awesomeness that is Discourse without realizing we just got marketowned.

Re: Discourse ditches CoffeeScript

#55

Post by msutherl »

elliotanderson wrote: post #16
msutherl wrote: post #14

Earlier quoted context omitted.

Indeed, the claim that JavaScript developers can't read CoffeeScript seems odd to me. As a novice JS developer, I could read CoffeeScript the first time I saw it and it took me a day to be fluent. 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.

There's not doubt it is readable (I'm quite a fan of the language too) - the problem is with writing it as a novice. This post highlights some of the issues with magic and whitespace: http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

I don't know, you would just never write "foo = bar->". It looks bad and it's wrong.

White-space sensitive languages are great because they reward you for writing with style, plus you don't have to worry about matching and aligning braces all the time.

Re: Discourse ditches CoffeeScript

#56

Post by calibraxis »

raganwald wrote: post #43

I find this a curious debate to have so early in Discourse's life. There doesn't appear to be a pain point, so it's mostly speculation. If this happens, then that consequence, but if this happens, then that other consequence... 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…

Disclaimer: I don't know Discourse's situation in detail, and I use CoffeeScript on node.js, not the client.

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?

Re: Discourse ditches CoffeeScript

#57

Post by cwp »

jacquesc wrote: post #33
adamesque wrote: post #30

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.

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.

Re: Discourse ditches CoffeeScript

#58

Post by jashkenas »

eurleif wrote: post #7
ansman wrote: post #5

If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no difficulty learning CS if you know JS. 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.

CoffeeScript's scoping is broken. http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffe...

Nope. CoffeeScript's scoping is working the way it's supposed to be ;)

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.

Re: Discourse ditches CoffeeScript

#59

Post by wereHamster »

chime wrote: post #28
ansman wrote: post #5

If you understand programming (there is a difference between knowing how to program and understanding, a lot of people lack the latter) there is absolutely no difficulty learning CS if you know JS. 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.

I've made some pretty large apps in CS, by myself and in teams. So many good things in CS that I can no longer live without when writing front-end code: 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 condition 5. jsondata?[2]?.hierarchy?.url 6. Optional brackets allow very terse/clean code: setTime…

> 8. Automatic return on last line

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.

Post reply on HN