Given Rich’s apprehension about positional parameters, what’s the reason for not having keyword parameters first class with fn/`defn`? Is giving it a map + destructuring considered first class/good/obvious enough that we should be prioritizing it? Does it generate overhead? The standard library is more or less devoid of this pattern, why? (Re-watching Effective Programs, where positional parameters aren’t exactly praised)

user=> (defn foo [& {:keys [x y]}] [x y])
#'user/foo
user=> (foo :y 1 :x 2)
[2 1]

you can express keyword parameters this way, explicit maps are preferred because they compose

you can (merge default x) a map, not so much with kw args. also you need apply-kv etc

we've talked about expanding options in this area

@bronsa I’m not saying that there isn’t a way to express it, just that I don’t see it happening very much, and that the standard library (which I use as a personal reference for what a Good Function looks like, mostly doesn’t)

clojure.core does use kw args on macros, mostly

see for/`doseq`/`core.async`/`condp` etc

there used to be a doc on confluence about why maps were (generally) preferred over kw args

no idea where that's gone

I used to favor "keyword arguments" (and in an ideal world I still would), but their performance is inferior as some gist showed. It had to do with apply IIRC So an 'options' argument isn't tremendously different (in terms of PLOP-ness), but it's more performant. And in addition to the mentioned merge-ability, IDEs can vertically align options more easily than kwargs.

In general I find functions returning functions always makes things harder

Higher order functions overall add quite the cognitive load. I find humans aren't good at thinking in such higher orders. I think when designing functions that uses them, you must be sure that their use is either self-contained, or encapsulated behind another simpler interface.

But when people get real clever with them, it can be quite challenging

Someone should coin a pasta for that kind of code... maybe Cannelloni code, code that makes use of too much higher order functions.

There's already Spaghetti for code that's too interweaved, Lasagna for code that has too many useless layers, Ravioli for code that has too many small functions. So I think Cannelloni could work for code that gets too clever with higher order functions 😋

"flour code" -- code that doesn't produce pasta. It only eventually becomes pasta when combined with other code later.

who knew coding was so isomorphic with Italian food

functions returning functions seems bit of a trivial case (and a design that is necessary for e.g. the middleware pattern), but I see what you mean the usual suspect would be something like chaining juxt and comp... I think I would appreciate a detailed/nuanced essay on the topic. I have seen articles suggesting HOFs are outright wrong. Quite obviously that's not going to cut it among functional programmers :)

In this case its essentially a partial where one of the arguments is expensive to calculate

Middleware and Interceptor are both use of them that I consider "encapsulated behind an interface". Same for transducers etc.

Like they're very well contained use with rules of how to use them and do they don't leak anywhere else

And map, for, reduce are self-contained

But I've seen code that for example, should be using a multi-method or polymorphism, but instead it uses HOF.

Or say, something that takes an fn that takes an fn and returns an fn.

disagree

Mixed with some config file where you can put the fn name you want and some dynamic calls to resolve 😋

a lot stuff written as multimethods or protocols would be better off passing a function

Hum... interesting

Any reasoning?

I thought generally the Clojure community agreed about data > functions > macros

multimethods and protocols are all entangled in global systems

passing a function is an entirely local decision

if I want to run two copies of some code and have them behave differently, it is easy to pass in a different function to each copy, it is harder to get that working when it relies on global state

Hum... that's true. But why do you need two copies, that are both local only?

it happens a ton where you create something that does X, business requirements shift so now you need X and Y, and the thing that does X could also do Y if it was just run with different parameters

I find I prefer my functions to be global, have a name, a doc-string, have been tested, etc. And unlike state, they don't suffer from coordination issues.

they do

libraries clash over who extends what protocol to what type

what the behavior of a global multimethod should be for a given dispatch value

Hum... what about metadata extends?

who calls which protocols and is responsible for aot'ing what

metadata extends is an attempt

but nothing is as general as a function

lambda the ultimate: ...

I mean, passing in a function to another function is just creating your own custom dispatch

your own private non-global unshared

No, the function that takes the fn as an argument is the dispatch fn in that case. It takes an fn and choses when to call

But anyway, I do see your point

are you saying it wouldn't choose when to call protocol functions?

I've never had clashes with protocol extensions or multi-method extensions. But I can see how it could happen

anyway, I write protocols, I write multimethods, but nothing has given me the code reuse and interoperability that passing functions does

Why do you still use multi-methods though?

I think you probably just have the intuition to know when HOF are appropriate and when they would make things more complicated then they are worth.

generally I don't write them as external extension points, so they aren't like the "interface" for something, internally they do dispatch on input data to do whatever

Its definitely not a problem I had thought of before. That two things could extend the same protocol to a type for the same fn or the same multi-method for the same data

I'll need to think more about it

I think my issue with using fn instead is their loose definitions. Like if you wanted to know what are all the possible fns being passed in? Say you were reading a new code base, with HOF, that's a lot harder to figure and then understand the possible branches of logic.

But I guess with discipline, that problem could be eliminated. Like if the passed in HOF are all defined with defns in a common place, with doc and tests.

Passing around lambda function might be hard to debug though.