6 ms·

Couple of small issues. You probably want "when" instead of "if". The if applies to the whole loop, not to each element. Also, the braces around the comprehensi

by runeh 16y ago

Couple of small issues. You probably want "when" instead of "if". The if applies to the whole loop, not to each element. Also, the braces around the comprehension is a pythonism I guess? It means it puts the result into an array, so you get [[<stuff>]] instead of just [<stuff>]. I've made that same mistake a bunch of times. Nitpicking aside, I totally agree about the expressiveness. I find myself writing about half the number of lines in CS as compared to JS, and the syntax fits my brain better.

sjs 16y ago
Thanks, I was hoping someone would point out the mistakes. Since I can't edit my previous comment: frob = (obj, rest...) -> v for v of obj when blurgh(v, rest) edit: parens dropped for noise reduction
- grayrest 16y ago
  A minor style point, but you can drop the parentheses here. They're only needed when you're assigning the result of the comprehension since = has a higher precedence. I go back and forth on whether it's better to remember this or to just put parens all the time.
  - runeh 16y ago
    The parentheses thing is the one thing that bugs me a bit about the CS syntax, but mostly when dealing with calling functions. I wouldn't mind omitting the parentheses around function arguments if I could be consistent about it. Seems like there are some cases where parentheses are necessary to make sure args go with the right function. I'm wondering why I find this so annoying though. It's not like I complain about having to put parentheses in math to make sure stuff is evaluated with the precedence I want.
    - grayrest 16y ago
      The way I think of it is "is this function call (including arguments) the last item on the line". If the answer is yes, you can drop the parens otherwise you have to keep them. E.g. foo bar baz 2 # is foo(bar(baz(2))) foo bar baz(), 2 # is foo(bar(baz(),2)) foo bar().baz 2 # is foo(bar().baz(2)) In every case, the foo is the last item on the line. In the second there's an argument after the call to baz() so it's not the last thing on the line and needs parens. In the third, baz is being chained off bar so bar is not the last thing on the line and needs parens. In general I'd do all the parens except maybe the ones for foo in the second and third cases simply because it takes a minute to figure out where the calls get split when you re-read the code. I tend to drop the call parens in situations the following: # DSLish things task 'foo', depends: ['bar'] # Callback/lambda taking things xhr_get url, -> stop_animation() That actually covers a fairly wide set of use cases for me since I tend to write DSLish/callback code but for things like `add(2,2)` I write in the parens regardless of position.

by runeh 16y ago

sjs 16y ago

Thanks, I was hoping someone would point out the mistakes. Since I can't edit my previous comment: frob = (obj, rest...) -> v for v of obj when blurgh(v, rest) edit: parens dropped for noise reduction

grayrest 16y ago
A minor style point, but you can drop the parentheses here. They're only needed when you're assigning the result of the comprehension since = has a higher precedence. I go back and forth on whether it's better to remember this or to just put parens all the time.
- runeh 16y ago
  The parentheses thing is the one thing that bugs me a bit about the CS syntax, but mostly when dealing with calling functions. I wouldn't mind omitting the parentheses around function arguments if I could be consistent about it. Seems like there are some cases where parentheses are necessary to make sure args go with the right function. I'm wondering why I find this so annoying though. It's not like I complain about having to put parentheses in math to make sure stuff is evaluated with the precedence I want.
  - grayrest 16y ago
    The way I think of it is "is this function call (including arguments) the last item on the line". If the answer is yes, you can drop the parens otherwise you have to keep them. E.g. foo bar baz 2 # is foo(bar(baz(2))) foo bar baz(), 2 # is foo(bar(baz(),2)) foo bar().baz 2 # is foo(bar().baz(2)) In every case, the foo is the last item on the line. In the second there's an argument after the call to baz() so it's not the last thing on the line and needs parens. In the third, baz is being chained off bar so bar is not the last thing on the line and needs parens. In general I'd do all the parens except maybe the ones for foo in the second and third cases simply because it takes a minute to figure out where the calls get split when you re-read the code. I tend to drop the call parens in situations the following: # DSLish things task 'foo', depends: ['bar'] # Callback/lambda taking things xhr_get url, -> stop_animation() That actually covers a fairly wide set of use cases for me since I tend to write DSLish/callback code but for things like `add(2,2)` I write in the parens regardless of position.