Yes, way in the heart of a functional program there's some code sorting lists of ints or something. But by that time, it's all labeled to the point where the functions just tell you what happens. As someone browsing the source, the nouns disappear.
list.stream().filter().mapToInt().sum() just reads better to me than sum( mapToInt( filter(list) ) )
list |> map (1+) |> filter odd |> sum list map filter odd sumI haven't seen an autocomplete that works on pipes. But with a good type system, it is technically possible to list all compatible functions that take "noun" as first parameter.
Sometimes you supply partially applied functions (also with pipes in noun->verb order) and that's not so easy to match:
noun |> verb1 |> (otherNoun >> verb2) |> etc
But perhaps even functions that take "noun" as nth parameter could be suggested.
English reads left to right overall, but writing instructions in English does not flow smoothly either way. e.g. "shuffle a deck of playing cards then deal four" reads more naturally than either "a deck of playing cards shuffle then four cards deal" or "deal four cards after shuffling a deck of playing cards".
shuffle(cards).deal(4) is a mix of both approaches.
Usually the languages either encourage cards.shuffle().deal(4) or deal(shuffle(cards),4).
In the 'noun-verb'/OOP version the sequence of modifications follows the english reading order where basically I only have to keep information about the last result in my head. The functional verb-noun version I have to pop in and out of layers: 'ok we're dealing what?, something shuffled, what are we shuffling?, the cards object/variable, ok we're dealing shuffled cards how many are we dealing? 4.'
In general the noun-verb follows the sequence of operations applied by the computer so it's easier to read.
But simply turning it around to cards.shuffle().deal(4) isn't a good answer, it's still the case that you can only put a small number of things together in a chain because it stops making sense. If the next move was to start the game, "cards.shuffle().deal(4).startgame('some-card-game')" does not make sense because starting the game is not something the cards do, but "start(deal(shuffle(cards), 4), 'some-card-game')" can make sense because start is a function which takes a board state and a game to start. It describes the world state, not the cards and their abilities.
That is, neither style is right, but a mixed style where both approaches are available and you can mix and match to be more expressive, works much better, IMO. Chunking a small number of things with prefix into one operation, or with postfix into one operation, but combining those chunks flexibly at a larger scale.
“Say that” “He said”
def do(x, fs):
for f in fs:
x = f(x)
return x
Which allows left-to-right style programming do(list, filter, partial(map, int), sum)
I haven't put this into production code yet, but love pipelining scripts with do CompletableFuture<Member> asyncProjectMembers =
Async.pipeline(Accounts.where("id >= ?", 1000);,
(accounts) -> accounts.loadProjects("updated_at >= ?", Instant.now().minusDays(30)),
(projects) -> projects.loadMembers());
If you assign the intermediates to variables, each instance will have associated with it the related collection that's queried while avoiding N+1's.They differentiate thread first/last for Fns with arity > 1, just like Clojure.
const people = list.stream();
const peopleOlderThan50 = people.filter(??);
const average = peopleOlderThan50.mapToInt().sum() / peopleOlderThan50.length;
Or some such thing. The more complex the chain the harder it is for me to read. Does anyone else have that experience?Also, for non-toy examples, there are real benefits to composing transformations, so that you don't pay the memory and performance costs of assigning intermediate sequences.