4 ms·

Strange. I know Ruby and Python and switch between them quite frequently, but generally prefer Ruby. I loathe CoffeeScript. My problem with CoffeeScript is it

Strange. I know Ruby and Python and switch between them quite frequently, but generally prefer Ruby. I loathe CoffeeScript. My problem with CoffeeScript is it imposes extra burden—to learn the syntax, and to learn how the build tools and process works (which, once you factor into account the various different web frameworks like Rails, Django, Flask and whatever brand of crazy syrup the Node people are currently drinking can be quite substantial)—but the benefit isn't there. CoffeeScript is just JavaScript but prettier. That's not a worthwhile tradeoff for me. When Rails started doing CoffeeScript, I just opened up ~/.railsrc and popped --no-coffee in there, and my life has been a lot less painful. CoffeeScript fixes the things about JavaScript that are least significant to me in terms of developer pain (semi-colons, curly braces and so on) but does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing). If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :)

lloeki 13y ago
> does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing It can't because it's actually JS, by design. Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Maybe you'd rather be interested in ClojureScript or Dart, which use JS merely as a VM instead of their systemic core. > If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :) If a back-ender[0] were to come to me-as-a-front-ender (since I'm equally both), and tell me what language to use, I'd tell him to, well, mind his own server-side business and let front-enders use whatever language they deem able to make them go from A to B in the most clean, reliable, and efficient way possible to them, or else I'll make them rewrite their stuff in NodeJS under cover of both ends being able share and reuse code, just to make them suffer ;-) [0]: which I don't know if you are or not, but given the substance of your comment, I'd venture mostly the former.
- masswerk 13y ago
  > Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Now we're effectively losing the "==" operator, which is behaving like in most other traditional scripting languages (e.g. Perl). What did we win by losing an operator? Why obfuscate that this is not the JS "==" operator but most likely the "===" operator?
  - lloeki 13y ago
    Either one wants weak typing or strong typing, but one cannot have both. "most other traditional scripting languages" consists of Perl and PHP (not even (ba)sh/test, to which == is string comparison whereas -eq is integer comparison), while languages typically used on the backend together with JS/CS include Python, Ruby, Java, C#, and whatnot, none of which have such an error-prone feature. > What did we win by losing an operator? Why obfuscate? Type safety, and resistance against both bona fide errors and clueless developers. Sane defaults matter.
gfodor 13y ago
> If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :) I know this was just a hypothetical, but this is a bad idea. You've lost the original source code and replaced it with something that is, I think everyone can agree CS-advocates or not, hard-to-read Javascript code.
scotth 13y ago
I use Coffee everyday, and I think the features most worth looking at are that every statement is an expression, list comprehensions and the "do" statement (for closing over variables in loops). And I'm a seasoned JavaScripter. Not a hater either. I just truly believe the benefit is there, and I urge you to take a second look. The syntax won't take you long if you put your mind to it.
masswerk 13y ago
I second that. I wouldn't hire any developer delivering just CS, because it shows a "just wanting getting stuff done" attitude, as opposed to some commitment to the language used and its inner workings. Example: Maybe the most beloved feature: anonymous functions CS: (x) -> x + x It's like "yeah, I want to get this block done here", and it obfuscates the workings of the language (e.g.: this is a function with all its inheritance and a shared scope, it returns a reference, which can be used as any reference and is interchangeable with a reference to a named function, etc – the construct essentially obfuscates that the expression is returning an object of type "Function"). I don't think that anyone would get away with it in a C-development position, who would be delivering a source for a precompiler using a construct like, say loop(i <- 0 .. 9): as a replacement for for (i = 0; i < 10; i++) {} IMHO, this is a very JS-specific phenomenon. And it's a bit strange, having something like a lingua franca nobody seems to care about. (Edit: Sticking to the lingua franca issue: It's a bit like having Latin as a lingua franca in the middle ages and some community using "Habs papa" for "Habemus papam". Even if "habs" compiles to "habemus" and the forth case of "papa" is easily inferred by the context, it fails the whole issue of using a lingua franca.)

lloeki 13y ago

> does nothing to address the things that I hate about writing JavaScript (oh, the weakly-typed type system for one thing It can't because it's actually JS, by design. Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Maybe you'd rather be interested in ClojureScript or Dart, which use JS merely as a VM instead of their systemic core. > If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :) If a back-ender[0] were to come to me-as-a-front-ender (since I'm equally both), and tell me what language to use, I'd tell him to, well, mind his own server-side business and let front-enders use whatever language they deem able to make them go from A to B in the most clean, reliable, and efficient way possible to them, or else I'll make them rewrite their stuff in NodeJS under cover of both ends being able share and reuse code, just to make them suffer ;-) [0]: which I don't know if you are or not, but given the substance of your comment, I'd venture mostly the former.

masswerk 13y ago
> Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===. Now we're effectively losing the "==" operator, which is behaving like in most other traditional scripting languages (e.g. Perl). What did we win by losing an operator? Why obfuscate that this is not the JS "==" operator but most likely the "===" operator?
- lloeki 13y ago
  Either one wants weak typing or strong typing, but one cannot have both. "most other traditional scripting languages" consists of Perl and PHP (not even (ba)sh/test, to which == is string comparison whereas -eq is integer comparison), while languages typically used on the backend together with JS/CS include Python, Ruby, Java, C#, and whatnot, none of which have such an error-prone feature. > What did we win by losing an operator? Why obfuscate? Type safety, and resistance against both bona fide errors and clueless developers. Sane defaults matter.

gfodor 13y ago

> If a front-ender on my team started using CoffeeScript on a project I work on, I'd take him to one side and say "it's fine to practice weird kinks in private, but compile it into JavaScript before you check it in". :) I know this was just a hypothetical, but this is a bad idea. You've lost the original source code and replaced it with something that is, I think everyone can agree CS-advocates or not, hard-to-read Javascript code.

scotth 13y ago

I use Coffee everyday, and I think the features most worth looking at are that every statement is an expression, list comprehensions and the "do" statement (for closing over variables in loops). And I'm a seasoned JavaScripter. Not a hater either. I just truly believe the benefit is there, and I urge you to take a second look. The syntax won't take you long if you put your mind to it.

masswerk 13y ago

I second that. I wouldn't hire any developer delivering just CS, because it shows a "just wanting getting stuff done" attitude, as opposed to some commitment to the language used and its inner workings. Example: Maybe the most beloved feature: anonymous functions CS: (x) -> x + x It's like "yeah, I want to get this block done here", and it obfuscates the workings of the language (e.g.: this is a function with all its inheritance and a shared scope, it returns a reference, which can be used as any reference and is interchangeable with a reference to a named function, etc – the construct essentially obfuscates that the expression is returning an object of type "Function"). I don't think that anyone would get away with it in a C-development position, who would be delivering a source for a precompiler using a construct like, say loop(i <- 0 .. 9): as a replacement for for (i = 0; i < 10; i++) {} IMHO, this is a very JS-specific phenomenon. And it's a bit strange, having something like a lingua franca nobody seems to care about. (Edit: Sticking to the lingua franca issue: It's a bit like having Latin as a lingua franca in the middle ages and some community using "Habs papa" for "Habemus papam". Even if "habs" compiles to "habemus" and the forth case of "papa" is easily inferred by the context, it fails the whole issue of using a lingua franca.)