4 ms·

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,

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 something that's easily readable)

DiThi 9y ago
> 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. > objects without brackets The language allows it but it doesn't mean you must use them. We have a loose style guide where we forbid a few confusing uses (like bracket-less one liners or returned objects). So loose it's shorter than this comment. > no spread operator It always had a spread operator (except for the first month of life). It's just called splat instead of spread, like in Python. Now it also allows ES6 syntax which is very similar (...foo vs. foo...). > significant whitespace That's not a bug, it's a feature ;) > no variable declaration keyword In the last year or two, that only bite us once. If it's more frequent than that your functions are way too long. But as you say, it's a matter of taste.
- jashkenas 9y ago
  From the perspective of how it was intended to be used, you've got it exactly right. Just because you can implicitly return a braceless object, doesn't mean you should.
  - twykke 9y ago
    i tend to use an explicit return except in one-line functions; there are plenty of CS features you can forgo if you don't think they benefit you.
- twykke 9y ago
  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.
  - pmontra 9y ago
    I'm not sure I understood. I don't know about Swift but do JS and Java have significant whitespace?
    - jonnytran 9y ago
      No, twykke is saying that in almost every language, even ones that don't technically have significant whitespace, people still use coding conventions and style guides that restrict whitespace to match the curly braces. Some people even use automated commit hooks to reject commits that don't follow the guide. The end result (or arguably, driving force) is that even in languages where whitespace isn't significant, people read the whitespace, not the curly braces. So the curly braces are basically redundant noise.
      - pmontra 9y ago
        Ok, thanks. I agree about { } being mostly noise but I think they are the lesser evil. I'm making most of my money with Python and I still believe significant whitespace is a very bad idea. The Ruby alternative of using end is better even if not super elegant (and Ruby is my language of choice). It's on par with curly braces. After 30+ years of programming I still have to find a satisfying solution to the problem.
fivesigma 9y ago
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.
cookiecaper 9y ago
Yes, CoffeeScript is chaos. I've found that CS's biggest proponents can be heard to say "Let's just replace it with a custom thing I'll build this weekend" much more frequently than normal. Surely this is coincidental. ;) The old joke was that Perl is a write-only language, and CoffeeScript et al are essentially thought experiments for how deep into the write-only abyss people are willing to plunge as a non-joke. It's no mystery that CS primarily attracts people who heavily discount the importance of long-term maintainability. The core issue seems to be that some people have conflated prescience with elegance. We must stop deluding ourselves into pretending there are languages that can read our minds. Put your intent in the code, avoid ambiguity. If the answer is not obvious and consistent, do not rely on either the computer or the human to extract your intent from the ether.
- cos_ 9y ago
  Speak for yourself! :)

DiThi 9y ago

> 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. > objects without brackets The language allows it but it doesn't mean you must use them. We have a loose style guide where we forbid a few confusing uses (like bracket-less one liners or returned objects). So loose it's shorter than this comment. > no spread operator It always had a spread operator (except for the first month of life). It's just called splat instead of spread, like in Python. Now it also allows ES6 syntax which is very similar (...foo vs. foo...). > significant whitespace That's not a bug, it's a feature ;) > no variable declaration keyword In the last year or two, that only bite us once. If it's more frequent than that your functions are way too long. But as you say, it's a matter of taste.

jashkenas 9y ago
From the perspective of how it was intended to be used, you've got it exactly right. Just because you can implicitly return a braceless object, doesn't mean you should.
- twykke 9y ago
  i tend to use an explicit return except in one-line functions; there are plenty of CS features you can forgo if you don't think they benefit you.
twykke 9y ago
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.
- pmontra 9y ago
  I'm not sure I understood. I don't know about Swift but do JS and Java have significant whitespace?
  - jonnytran 9y ago
    No, twykke is saying that in almost every language, even ones that don't technically have significant whitespace, people still use coding conventions and style guides that restrict whitespace to match the curly braces. Some people even use automated commit hooks to reject commits that don't follow the guide. The end result (or arguably, driving force) is that even in languages where whitespace isn't significant, people read the whitespace, not the curly braces. So the curly braces are basically redundant noise.
    - pmontra 9y ago
      Ok, thanks. I agree about { } being mostly noise but I think they are the lesser evil. I'm making most of my money with Python and I still believe significant whitespace is a very bad idea. The Ruby alternative of using end is better even if not super elegant (and Ruby is my language of choice). It's on par with curly braces. After 30+ years of programming I still have to find a satisfying solution to the problem.

fivesigma 9y ago

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.

cookiecaper 9y ago

Yes, CoffeeScript is chaos. I've found that CS's biggest proponents can be heard to say "Let's just replace it with a custom thing I'll build this weekend" much more frequently than normal. Surely this is coincidental. ;) The old joke was that Perl is a write-only language, and CoffeeScript et al are essentially thought experiments for how deep into the write-only abyss people are willing to plunge as a non-joke. It's no mystery that CS primarily attracts people who heavily discount the importance of long-term maintainability. The core issue seems to be that some people have conflated prescience with elegance. We must stop deluding ourselves into pretending there are languages that can read our minds. Put your intent in the code, avoid ambiguity. If the answer is not obvious and consistent, do not rely on either the computer or the human to extract your intent from the ether.

cos_ 9y ago
Speak for yourself! :)