Hacker News new | ask | show | jobs
by briandear 4152 days ago
I sure hope you're wrong. The unnecessary clutter of plain JS is just painful to look at. I can't remember how many times I've looked over a 40 line block of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is just downright frustrating to be be wasting any time on what is effectively irrelevant syntax. With CS, it's indent and be done with it. It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less. To take Haml as an example:

.my-div %h1 Some Text - some_ruby_code

vs the ERB of

<div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>

2 comments

> "With CS, it's indent and be done with it"

As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-)

I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that.

"It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less."

Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not.

A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc).

Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.

...two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces

Commit hooks will help you:

http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

The bigger your team, the more you need them.

For open source projects, that's less of an option, but regardless, an individual's opinions about tabs and spaces are moot when working on a multi-dev project. You follow the project's conventions, or your changes don't get merged.
Yes it is frustrating that git doesn't automatically transfer hooks to cloned repos. I guess I understand the standard explanation of "git clone" never running arbitrary code on one's machine (although in a sense that is git's purpose), but it does reduce the use of client-side hooks in open projects.
I see no reason why anyone should care that CSS is valid SCSS and HTML is valid ERb.
Ditching all the useless lines of closing brackets and parenthesis is my favorite part of using coffeescript. Matching up brackets is a pain. The less I have to do that, the better.
My editors have had bracket/parenthesis matching for 30+ years, and automated indentation support as well. I don't get why anyone would do that manually.
Also if it works good, you can give them the same color as whitespace, which I always show, but with almost the same color as the background. This reduces the cognitive overhead a bit.