Comment by cookiecaper | Hacker News Reader

Comment by cookiecaper | Hacker News Reader

Parent Full thread

100%. I think CoffeeScript put the cart before the horse by promising some nearly-magical block detection and then they were stuck trying to implement it. I find that CS code is very temperamental and difficult to maintain over the long term.

"No brackets, it's so pretty!" is fine, but other languages don't make what feel like random guesses as to where your delimiters are, they use a different syntax to mark the blocks.

Personally I prefer to just mark the blocks myself rather than hope that the compiler infers it correctly, whether that's done with indentation as in Python, keywords like "begin" and "end", or with C-style bracketing. I even find comparatively mild things like Ruby's inferred parentheses grating.

There's no reason not to put an opening and closing mark. You're already thinking in delimited terms when you're writing the code, there is no real extra cost to throwing in the indicators, and it makes it so much easier to figure out what's going on when you go back to debug, when you try to read the code after months, or when your text editor is trying to help you out with folding and the like.

Whether or not bracket free code is more readible might be a personal opinion. I think for people who understand Coffeesctipt well, its easier because theres less visual noise. There are many languages with optional parens, and whether or not you want to stretch the ability of the parser is up to you. Coffeescript proves that they are not necessary in order to write javascript.

> I even find comparatively mild things like Ruby's inferred parentheses grating.

I agree with everything you've written and I'd like to note that even Ruby has degenerate cases where you're forced to use parenthesis around things because the parser can't figure out what you mean.

I have an instant dislike for any language that tries hard to make code 'pretty' by removing such indicators.

And to be clear, there's a difference between a concise version of a syntax, such as C#'s lambda syntax, and creating inconsistencies in your language by trying to remove syntax that cannot be universally removed without creating ambiguities.

The former is welcome, the latter is not. Even Ruby has such degenerate cases.

And I like Ruby, but I dislike that design decision.

> I have an instant dislike for any language that tries hard to make code 'pretty' by removing such indicators.

Ah, you see, I don't, or didn't :)

I thought bracketless code would be magical, until I had to wander through nested callbacks with implicit returns.

Yeah, I think that people jump on that bandwagon just assuming that it will work magically. It is better to explicit about it if the cost is minimal. Python also strove to eliminate unsightly bracketing, but it did so by replacing the characters with a more readable delimiter, not removing them entirely.

To be fair to Ruby, most of the time when I've come across a situation where the call became ambiguous due to lack of parenthesis, the failure was obvious and easy to fix. I still think introducing that type of ambiguity into the language is an antifeature, but compared to CoffeeScript, where the automatic delimiting is non-intuitive enough that you often have to compile it down to JS to check that it's rolling everything into the right place, it's no contest.

On our CoffeeScript project, the compiled blocks would change layout even with very minor changes to spacing or code arrangement. It would've been much easier just to throw in a () and tell it what we meant!

I'm not saying it's insurmountable, but the gain just isn't worth the cost imo.

So, what you are saying is that you don't like language that have operator precedence rules so that you can omit some uses of grouping parentheses in expressions? Because that's the same level of inconsistency due to non-universal removing of markers as Ruby's permitting function-call parens to be removed when unambiguous.

What I'm saying is that anyone who's judgement is so poor as to try and argue operator precedence in this discussion isn't worth bothering with.

Reply on news.ycombinator.com