3 ms·

Why do you want to reinforce that idea? To me arrow functions mostly just decrease readability and makes them blend in too much, when it should be important di

Why do you want to reinforce that idea? To me arrow functions mostly just decrease readability and makes them blend in too much, when it should be important distinction what is a function and what is not.

nsonha 2y ago
> should be important distinction what is a function and what is not code is to express logic clearly to the reader. We should assess it for that purpose, before assess for any derivative, secondary concern such as whether categories of things in code (function etc) visually pops out when you use some specific tool like vim, or grep. There are syntax highlighters for a reason. And maybe if grep sucks with code then build the proper tool for code searching, instead of writing code after the tool.
turboponyy 2y ago
Not to be dismissive, but because I like it - it just sits right with me.
benrutter 2y ago
I'm not a javascript programmer, but I really like the arrow pattern from a distance exactly because it enforces that idea. My experience is that newcomers are often thrown off and confused by higher order functions. I think partly because, well let's be honest they just are more confusing than normal functions, but I think it's also because languages often bind functions differently from everything else. `const cool = () => 5` Makes it obvious and transparent, that `cool' is just a variable where as: `function cool() {return 5}` looks very different from other variable bindings.
- throwitaway1123 2y ago
  Since we're on the topic of higher order functions, arrow functions allow you to express function currying very succinctly (which some people prefer). This is a contrived example to illustrate the syntactical differences: const arrow = (a) => (b) => `${a}-${b}` function verbose(a) { return function (b) { return `${a}-${b}` } } function uncurried(a, b) { return `${a}-${b}` } const values = ['foo', 'bar', 'baz'] values.map(arrow('qux')) values.map(verbose('qux')) values.map(uncurried.bind(null, 'qux')) values.map((b) => uncurried('qux', b))

nsonha 2y ago

> should be important distinction what is a function and what is not code is to express logic clearly to the reader. We should assess it for that purpose, before assess for any derivative, secondary concern such as whether categories of things in code (function etc) visually pops out when you use some specific tool like vim, or grep. There are syntax highlighters for a reason. And maybe if grep sucks with code then build the proper tool for code searching, instead of writing code after the tool.

turboponyy 2y ago

Not to be dismissive, but because I like it - it just sits right with me.

benrutter 2y ago

I'm not a javascript programmer, but I really like the arrow pattern from a distance exactly because it enforces that idea. My experience is that newcomers are often thrown off and confused by higher order functions. I think partly because, well let's be honest they just are more confusing than normal functions, but I think it's also because languages often bind functions differently from everything else. `const cool = () => 5` Makes it obvious and transparent, that `cool' is just a variable where as: `function cool() {return 5}` looks very different from other variable bindings.

throwitaway1123 2y ago
Since we're on the topic of higher order functions, arrow functions allow you to express function currying very succinctly (which some people prefer). This is a contrived example to illustrate the syntactical differences: const arrow = (a) => (b) => `${a}-${b}` function verbose(a) { return function (b) { return `${a}-${b}` } } function uncurried(a, b) { return `${a}-${b}` } const values = ['foo', 'bar', 'baz'] values.map(arrow('qux')) values.map(verbose('qux')) values.map(uncurried.bind(null, 'qux')) values.map((b) => uncurried('qux', b))