3 ms·
CoffeeScript was obviously inspired by Ruby. While CS is great, I've never gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's "def" or "
by ChrisAntaki 13y ago
CoffeeScript was obviously inspired by Ruby. While CS is great, I've never gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's "def" or "do" reads so much better. Especially with "end", to signify a barrier, as opposed to whitespace. Have you considered porting Ruby directly to JavaScript?
By the way, thanks for your work on _ & Backbone!
- jashkenas 13y ago> Have you considered porting Ruby directly to JavaScript? No. It's been attempted before, and it doesn't turn out to be terribly useful in the end, because of the vast semantic mismatch between the two languages. See: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS#ruby https://github.com/jashkenas/coffee-script/wiki/List-of-lang... > I've never gotten over the usage of "->" or "=>" to signify a function. Give it a try, perhaps. It's critical not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables. It's for this reason that Ruby 1.9 has a new lambda syntax that looks a great deal similar to CoffeeScript's. For example: request(url, def callback(response) do ... end) ... that kinda thing is no good. The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output
- ChrisAntaki 13y ago>> it doesn't turn out to be terribly useful in the end True, I'd chose CoffeeScript over Opal. >> Give it a try, perhaps. Oh, I dig it, especially the fat arrow. >> It's critical not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables. Still, I find "def" to be more `readable` than arrow symbols. I'm not sure how JavaScript's first class status for functions would deter a keyword containing letters. Considering JavaScript itself uses function as its. >> The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output That definitely makes logical sense. Still, I feel the readability might be increased by using words, which the mind is more attuned to quickly applying meaning to. Edit: Great job, on CoffeeScript, regardless!
- WickyNilliams 13y agoAlso worth pointing out that the fat arrow lambda expression is coming in ES6 [1] so you will see it in vanilla JS soon! [1] http://www.nczonline.net/blog/2013/09/10/understanding-ecmascript-6-arrow-functions/ http://www.nczonline.net/blog/2013/09/10/understanding-ecmas...
- erokar 13y ago> Have you considered porting Ruby directly to JavaScript? It's been done. Check out Opal. I can't say I miss Ruby's ends in CS.
- ChrisAntaki 13y agoOpal is cool. I prefer CoffeeScripts approach to adding functionality though, without including an entire new standard library.
- ngcazz 13y agoThe arrow is standard mathematical notation for function definition
- ChrisAntaki 13y agoThat's a good point, it has historical significance.
- Mikeb85 13y agoPeople HAVE written Ruby -> Javascript compilers. Check out Opalrb, Redscript, Coldruby, Hotruby, Webruby... The -> comes from Haskell's lambda syntax (\x -> x+1). It's a nice solution. 'Def' doesn't really work for lambdas, do does, but curly-brace blocks are nicer in Ruby if you put them everwhere {|x| x+1}... Keep in mind that Javascript is alot like Scheme in that there isn't really a difference between named and anonymous functions. You can write Scheme and Javascript pretty much the same way...
- ChrisAntaki 13y agoGreat points! I really want to check out Scheme now.
- nailer 13y ago> Especially with "end", to signify a barrier, as opposed to whitespace. But in any programming language you're already indenting blocks for humans. Why repeat the same work? Especially when it allows for inconsistency between how a human and how a machine would read the code.
- ChrisAntaki 13y agoTo increase the clarity, for future collaborators.