aka "How not to implement Fibonacci sequence"
Y U no cache the results?
CoffeeScript: The beautiful way to write JavaScript
81–88 of 88 posts
Re: CoffeeScript: The beautiful way to write JavaScript
#82Earlier quoted context omitted.
I don't agree with your opinion at all. Your claim that coffeescript is somehow 'better' than javascript is just false. You prefer one syntax, fine, but don't assume that it is somehow 'better'. I prefer Javascript. I do not prefer Coffeescript at all, and I get javascript, and have gotten it for 14 years.
When targeting Node, one runtime and ES5, vanilla JS isn't so bad. Writing JS for browsers is painful, and CS addresses a lot of those pains. A function that does nothing useful but illustrates some pain points: function frob(obj) { var rest = [].slice.call(arguments, 1) , results = [] for (var k in obj) if (obj.hasOwnProperty(k)) { v = obj[k] if (blurgh(v, rest)) { results.push(v) } } return results } This is roughl…
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 [[]] instead of just []. 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.
Re: CoffeeScript: The beautiful way to write JavaScript
#83Ugh, there is nothing wrong with JavaScript, please let's all just forget that CoffeeScript even exists. Thank you.
Re: CoffeeScript: The beautiful way to write JavaScript
#84Earlier quoted context omitted.
When targeting Node, one runtime and ES5, vanilla JS isn't so bad. Writing JS for browsers is painful, and CS addresses a lot of those pains. A function that does nothing useful but illustrates some pain points: function frob(obj) { var rest = [].slice.call(arguments, 1) , results = [] for (var k in obj) if (obj.hasOwnProperty(k)) { v = obj[k] if (blurgh(v, rest)) { results.push(v) } } return results } This is roughl…
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 [[ ]] instead of just [ ]. 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…
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)
Re: CoffeeScript: The beautiful way to write JavaScript
#85Earlier quoted context omitted.
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 [[ ]] instead of just [ ]. 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…
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
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.
Re: CoffeeScript: The beautiful way to write JavaScript
#86Earlier quoted context omitted.
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
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.
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.
Re: CoffeeScript: The beautiful way to write JavaScript
#87Earlier quoted context omitted.
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.
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…
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))
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()
Re: CoffeeScript: The beautiful way to write JavaScript
#88Earlier quoted context omitted.
Also, with a language like javascript, shouldn't we worry more about faster performance then beautiful syntax.
Absolutely, and CoffeeScript worries about your JS performance for you, when it can. In my personal experience, translating JS to Coffee tends to speed up the performance of the resulting script, due to the optimizations the CoffeeScript compiler adds. To be specific, the main speedup I tend to get is this: If I'm working with JS, I'll tend to use a "forEach" function frequently, for looping over lists: list.forEach(…
Does CoffeeScript include an optimizer/minifier? Google's "Closure" Compiler for JavaScript is able to inline functions and perform other interesting optimizations.