Hacker News Reader

#1 I agree, making stuff optional was a bad design decision. It encourages people to write code in different ways and makes for unreadable messes if coworkers aren't religious about how they format things or they do things differently than you do.

#2 has definitely bitten me, but I see that less of a failure of CS and more of a failure of the design of $.each(). The case is pretty well documented in CS though... the last code line is 'return'ed... if your code unexpectedly returns false, then really you are just bitten by the design of $.each().

Your only other options for early termination of $.each are pretty cumbersome. On the one hand you can bend over backwards to pass in the "should continue" flag "by reference". In C you might pass in bool * should_continue, then do *should_continue = false. In JavaScript you'd have to wrap that in another variable, like flags.should_continue = false, which is less elegant in my opinion. Alternatively, I've seen libraries abuse throw to achieve this, which I also don't like (and I believe has pretty bad performance characteristics, but I can't remember for sure).

... or you can write it in CS with a for loop which cleans up the syntax quite a bit... or it might be possible to reduce your input first so that you are only iterating over the things you actually want to iterate over...

"...or you can write it in CS with a for loop which cleans up the syntax quite a bit"

For each loops are great, but there is certainly value in having $.each be a function as well as a statement. For example, if you want to pass it to another function in more functional style programming: do_something($.each);

"or it might be possible to reduce your input first so that you are only iterating over the things you actually want to iterate over..."

It seems you don't understand the point of returning false from $.each, it is not to filter, it is to stop early. For example, if you are doing a linear search for something, it is reasonable to want to stop after you find it. There is no way to "iterate over the things you actually want to iterate over".

I think you're stretching here. Passing $.each to a function makes no sense when it is effectively a global anyway. Please give me a real world example of why you would do something like that (not in the functional aspect, that I understand... I am talking specifically about $.each).

I also wouldn't use something called $.each to do a linear search. I'd use underscore.js _.find(), which has a sane api, you return true when you want to stop. This thing I'm looking for has been found.

Array.forEach and _.each() chose not to support returning false. I can only assume that is @jashkenas being wise.

CoffeeScript can't really claim that "it's just javascript" either. I'd have to figure out how to hook up the CoffeeScript compiler into every single one of my workflows where I use javascript.

For example, I use swank (https://github.com/swank-js/swank-js) to send javascript to the current page in my browser from Emacs. I couldn't live without it. I'd have to figure out how to dynamically compile it, and I'm not sure if there's any restrictions with piece-meal compilation.

It's definitely a separate community and I'd lose out on lots of good tools if I had to use it. I'm glad nobody wants to use it where I work.

"It's just javascript" !== "You don't have to change your workflow at all"

Piecemeal compilation:

    // beginning of file
    Coffeescript = require('coffee-script');
   
    // compilation    
    Coffeescript.compile(line, {bare: true});

e.g.

    var f = eval(Coffeescript.compile("(x) -> x + 1", {bare: true}));
    f(1) // ==> true

Pardon? The coffeescript site has pretty comprehensive info that describes the syntax. If you don't find a specific example on the site, "it's just Javascript" has rung true for me in almost every case.

Yes, there is a learning curve and it does things slightly differently. The implicit return value is just something you read once and then integrate. True, function hoisting is lost in cs, but that has never been a problem for me.

Just three completely undocumented syntax examples...

Mapping values in an object:

    {a, b} = c

Backslash to continue lines:

    a = long_variable_name \
      + other_long variable name

Switch statements without a parameter:

    switch
      when function_that_needs_to_return_true
        stuff

But the bigger problem is just having no idea how things will parse. For example, this works:

    a = b +
      c

But this doesn't:

    a = b
      + c

And then this works:

    switch a
      when b, c, d
        e()

But this doesn't (a multi-line form you might want to use if the variable names were really long):

    switch a
      when b, 
          c,
          d
        e()

And this doesn't:

    switch a
      when b
      when c
      when d
        e()

After trial-and-error, you discover it has to be this, with a seemingly random backslashes:

    switch a
      when b, \
          c, \
          d
        e()

I could go on and on -- but you get the point. The whole language is only discoverable via trial and error. None of this is documented. (Apologies for taking up so much vertical space of the comments!!)

1) Destructuring assignment: http://coffeescript.org/#destructuring (although they lack an object example).

2) This has to do with the unary plus operator more than just cs - since +varname is an expression, it treats it as such. Fair complaint - I've never run into that. Also, this works just fine if you put the plus on the end of the first line:

    a = long_var_name + 
        hey_another_var

3) When would you use those?

4+5) Are cases of the unary operator in 2)

6-10) Sure, this is limiting if you want to write switch statements like that.

I feel that your coding style is different, or that you're listing edge cases to be contrarian. Coffeescript has a much smaller range of syntax deviations but that's part of what allows it to be so brief and clean.

His 1-3 were complaining about undocumented syntax, and the rest about the actual syntax itself. Not that your response is wrong, just that might help you understand what he was saying.

Mapping values in an object:

http://coffeescript.org/#destructuring

On backslashes:

https://github.com/jashkenas/coffee-script/issues/2457

Basically, if statements are that long, the code should be refactored. This makes it easier to read and reduces the opportunity for bugs. That pattern is one of the main reasons I like CoffeeScript.

    switch a
      when b, c, d
        e()

Is clearly explained here:

http://coffeescript.org/#switch

I think parent's point is that s/he wants b,c,d on different lines if they were long variable names.

That's addressed in the second link. The code should be refactored.

    condition = (a) -> a in [
      b,
      c,
      d
    ]

    switch
      when condition(a)
        e()

This is a technique which is already possible in JavaScript, an example (not mine) from 2007: http://saintjohnshawn.com/2007/05/24/javascript-example-swit...

Sorry, but that's completely bizarre. The whole point of a switch statement is to be able to test a single value against a list of single values, or groups of single values.

The supposed "correct way" you support moves the values outside of the switch statement, which completely destroys reading comprehension of the code. It explodes the number of lines of code necessary. This isn't refactoring, it's complete code obfuscation.

It also makes the switch statement itself completely superfluous, since you might as well just do a series of if / else if's, and save an extra line of code. I mean, the whole point of switch is to pass a parameter and compare it against values.

Sorry, what's completely bizarre is having variable names which push the 80 character limit. That doesn't help reading comprehension at all.

For instance, look at the recently posted Matches.js [1] -- there are many reasons to factor out the test case when the test case is unusual. 80 character test cases are unusual.

[1] http://news.ycombinator.com/item?id=4516576

EDIT:

80 character test cases (variables or otherwise) should be factored out. The readability and purpose of the method is compromised if you have 5 groups of 30 constants. Factor the groups out into individual maintainable functions. Then there is one function per case, and an overview of the entire switch can be seen in a few rows rather than several pages.

What are you talking about? My particular use case that led to all this was just translating a simple, clean, elegant JavaScript switch like the following. It's ideal, really, in terms of readability:

    switch (operation_code) {
    case SUGGEST_ACTION:
       ...
       break;
    case PERFORM_ACTION_PREAUTHORIZE:
    case PERFORM_ACTION_AUTHORIZE:
    case PERFORM_ACTION_POSTAUTHORIZE:
       ...
       break;
    case DELETE_ACTION_REVERSIBLE:
    case DELETE_ACTION_IRREVERSIBLE:
    case DELETE_ACTION_NOT_PREAUTHORIZED:
    case DELETE_ACTION_PREAUTHORIZED:
       ...
       break;
    case UNDO_ACTION:
       ...
       break;
    (5 more groups of 30 more constants...)
    }

It's not variable names that push an 80 character limit. It's about translating groups of shorter constants, that taken together go over 80 lines, and which have similar prefixes, so they look very nice listed vertically, and make it very clear where their differences and similarities are.

I stand by my point: telling people that, in CoffeeScript, it's proper to "refactor" this into a switch statement with no parameter and creating entire new functions, is bizarre.

Hey, that's a really good use case for multi-line cases. Not exactly the fallthrough behavior of the JavaScript example you posted ... but a good reason to want linebreaks in your list of values to match. You should open a ticket suggesting a syntax improvement for it.

Parent's point is that he wants better documentation, and possibly better consistency, on things like breaking lines; breaking lines was just an example to illustrate the larger point.

I'm not so sure the addition one isn't actually also applicable to javascript automatic semicolon insertion. The google js style guide (publicly available) says that all lines must end in an infix operator, opening bracket or semicolon to always avoid accidental semicolon insertion.

Though the switch one seems surprising (read: a flaw) since it is usually safe to end a line with a comma in vanilla js.

You might want to check out this great article on semicolon insertion:

http://inimino.org/~inimino/blog/javascript_semicolons

Basically, you can almost always remove the semicolons without trouble and more often then not problems occur from semicolons not being inserted then from them being inserted in unexpected positions. The "returning an object literal" case is the only common case where a semicolon is mischeviously inserted.

I wasn't trying to express a strong stance on the issue, just pointing out what the Google's js style guide says, the + on the next line wouldn't be allowed there (nor .)

http://google-styleguide.googlecode.com/svn/trunk/javascript...

    a = b
       + c

Line-breaks end statements in CoffeeScript, this is the same as

    a = b; +c

That should be pretty apparent. Your other examples are mostly abuses, and you'll not find "documentation on forbidden syntax" for any other language either.

Javascript or Coffeescript shouldn't ever have lines ending with a backslash.

Try:

    switch a
      when b
         , c
         , d
        e()

Why and how could function hoisting be useful?

(Genuine question, not an snarky comment)

Edit: Huh! I thought you meant "variable hoisting", which is the most evil language feature that's ever bitten me!

This is an introduction to "function hoisting": http://elegantcode.com/2011/03/24/basic-javascript-part-12-f... - Very very interesting.

I always felt that function hoisting is harming code readability. I prefer reading the code from top to bottom, I don't want to stuble upon functions that were not declared before.

If I recall correctly the main reason why this feature is not supported by CoffeeScript is because of some awkward IE bug though.

The main reason is what you say -- it harms readability. Much better to have functions behave like any other value, like any other variable -- and only be usable after they've been created.

I agree, although I also see some usefulness:

If your inner function names are sufficiently descriptive, you can write the high-level behaviour of the outer function at the top, first to be read, to get a quick overview of what it does. Then declare the inner functions below that (this also requires that the inner functions must not have surprising side-effects).

I've never seen or tried out code like that in practice, but it seems like it could work.

This is exactly my position. I have used CoffeeScript in 3-projects and moved back to JavaScript. The biggest problem for me is the readability. JavaScript has braces and good readability, IMHO. YMMV.