I agree that Haskell is a good comparison. I think matrices and math are too closely focused on in array languages (and dismissals of array languages), though.
For fun I'm writing a "spreadsheet programming language" that borrows a little from array languages, and I think there's useful stuff to take away from them.
They make you focus on the data, and the transformations you want to effect on the data.
They make you think, "where there's one, there's probably many."
The implicit mapping over arrays for most functions and operators is a massive ergonomic win over "a formula for each row" in the spreadsheet model. (Excel "array formulas" but not shit.)
Some of the simple little abstractions are beautiful. Seriously, as someone who didn't know anything about array languages three weeks ago, I say go spend a day reading the first two parts of the J book (http://www.jsoftware.com/help/learning/contents.htm) up to "Rank". It's this humble little operator that makes the whole language sing and fit together masterfully, and I'm heartbroken my language's data model (and programming style) isn't a good fit for it.
Really, though, for me being able to have my (still hypothetical) non-programmer users type
organisations[users.orgId]
instead of
users.map(({ orgId }) => organisations[orgId])
is a no-brainer. Ditto just about any place I might want to use an anonymous function in JS, really:
sort(people, by: people.age)
vs
sort(people, ({ age }) => age)
So simple. Pass an array of things to use as the sort key, not "a function to call on each item-to-sort".
Forget the cryptic syntax, "operator ambivalence" and math/matrix-focus, there's a lot of useful stuff in there that should be better known in language circles.
As for the grandparent's complaint of being "nearly-pure functional", that's the zeitgeist now -- functional transformation of data, with big ugly explicit data-replacement as the mutation story. That's not an impediment to use, it's an encouragement to use responsibly while not being too much of an encumbrance if you want to walk off the beaten track.
I'm not massively keen on the former (IMO having to write .map etc helps you get a better "feel" for what parts will have the biggest impact on performance), but the latter looks an awful lot like lenses, which are pretty great.
Of course, a lens is really just a pair of functions in disguise, so it wouldn't prevent you from sorting my more complex functions if needed.
Not a bad solution. Having a top-level `by` function isn't a bad tradeoff if it's easily understood. For me there are two problems, though. Most importantly:
1. It doesn't generalise past lookups. Say I want to sort a list of numbers by their absolute value. In my spreadsheet language:
sort(numbers, by: abs(numbers))
or filtering by some threshold:
filter(numbers, by: numbers > threshold)
Both are "repetitive" -- we might prefer something with first-class functions to get closer to a point-free style, but my users won't care. And the repetition isn't actually useless, there are times you might really want that flexibility:
filter(users.id, by: users.age > 21)
2. My language isn't big on first-class functions. One day it might get support for them for some use-cases where you just need that flexibility[1], but in the meantime they don't provide a lot of value, and they're not a good fit for my hypothetical future users.
If I told my hypothetical users that `by` returns a function, their response would probably be, "What is a function?" The unit of logic abstraction in my spreadsheet language is... slightly weird from a traditional programming perspective.
Thanks again for commenting constructively, though -- seeing a new ergonomic way to approach this sort of problem (or even just "tricks that could become idioms") is really useful.
[1]: If you needed to provide a 2-arg comparator to `sort` then a lambda would be much better -- my scheme would require you to evaluate the cross-product of comparisons, so sorting would have to take time O(n^2), which is no good. Thankfully single-item key functions seem sufficient for most purposes.
For fun I'm writing a "spreadsheet programming language" that borrows a little from array languages, and I think there's useful stuff to take away from them.
They make you focus on the data, and the transformations you want to effect on the data.
They make you think, "where there's one, there's probably many."
The implicit mapping over arrays for most functions and operators is a massive ergonomic win over "a formula for each row" in the spreadsheet model. (Excel "array formulas" but not shit.)
Some of the simple little abstractions are beautiful. Seriously, as someone who didn't know anything about array languages three weeks ago, I say go spend a day reading the first two parts of the J book (http://www.jsoftware.com/help/learning/contents.htm) up to "Rank". It's this humble little operator that makes the whole language sing and fit together masterfully, and I'm heartbroken my language's data model (and programming style) isn't a good fit for it.
Really, though, for me being able to have my (still hypothetical) non-programmer users type
instead of is a no-brainer. Ditto just about any place I might want to use an anonymous function in JS, really: vs So simple. Pass an array of things to use as the sort key, not "a function to call on each item-to-sort".Forget the cryptic syntax, "operator ambivalence" and math/matrix-focus, there's a lot of useful stuff in there that should be better known in language circles.
As for the grandparent's complaint of being "nearly-pure functional", that's the zeitgeist now -- functional transformation of data, with big ugly explicit data-replacement as the mutation story. That's not an impediment to use, it's an encouragement to use responsibly while not being too much of an encumbrance if you want to walk off the beaten track.