[ even? ]
  [ even? not ]
  [ 4 > ]

  2∘|
  1-2∘|
  >∘4

Many other languages are pretty good for point-free programming. For instance this series goes into the benefits of using this approach in Swift: https://www.pointfree.co/

Point-free programming has always been a controversial subject. Some people passionately hate it (particularly people that haven't invested in learning to use it) and some passionately love it.

And for other people, such as myself, it depends on the particular case.

I think that point-free style can be clearer and more concise in certain cases (particularly when you're chaining a sequence of operations), but you can also really overdo it. I think when you start to use (in Haskell) "flip", "uncurry", etc., the question is whether it wouldn't be more readable to just name the arguments instead. But obviously, people are going to have varying levels of tolerance for such things.

This I think lines up with the general Forth advice to avoid stack juggling (swap, roll, over, dup etc).

The latter are often historical baggage, telling us what the code used to do, or was meant to do; whilst a point-free version shows us more directly what it actually does.

If the point-free version makes sense as-is, we can leave it; but that's rarely the case. Usually, we'll introduce a few abstractions and variables; but this time they'll be more appropriate for the current codebase.

You examples become:

  2 partial mod
  1 minus 2 partial mod
  > partial 4

Now your examples will look like this:

  [ 2 partial mod ]
  [ 1 minus 2 partial mod ]
  [ > partial 4 ]

One character operator is still an operator. If it does not require spaces around it most of the time, for sake of comparison between languages it should have them.

Some languages express the same thing with more or less concepts, and more or less explicit complexity, and that is a true difference in verbosity, but symbol-vs-word is just a superficial difference that can and should be ignored for a useful comparison.

[1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106...

APL/K and concatenative languages are not there, but Haskell is. What is fascinating is that Haskell wins by large margin because it uses implicit "apply" operation in place of space between expressions' parts. Something similar can be the case of APL and Joy/Forth as well.

It appears to me that APL/K construct operations using implicit operations' stack. In case of Haskell, there would be an (infix) operation to perform something like that, much like what is discussed with the "implicit apply" in the paper above. In case of Joy, there is a stack of stacks (or list of lists).

Also, those examples were very simple ones, and APL has a lot of handy composition features[1] that make function composition the best in any language I've tried, including Haskell. For example (+/÷≢) in APL is (liftM2 (/) (foldl1 (+)) (fromIntegral . length)) in Haskell.

[1] https://aplwiki.com/wiki/Tacit_programming#Trains

Why did you use (foldl1 (+)) instead of sum? Also, (fromIntegral . length) is (genericLength) - and that means you used implicit type conversion which may add terseness and also lead to errors. After all that, your example becomes (liftM2 (/) sum genericLength). Not much longer than APL's in terms of actual symbols used.

APL fails differently, I think. It may very well fail you if you try to express parsing combinators, especially when context sensitivity and/or non-determinism are important.

'Not much longer than APL's in terms of actual symbols used.' - well, there's liftM2, and for longer examples, chaining it is even worse - (f g h i j) in APL becomes liftM2 g f $ liftM2 i h j -> quickly becoming unwieldy and unclear.

A lot of people also seem to say 'oh well if each character was a word it would be the same', and while it seems like that might be true, in practice it isn't, and the use of symbols allows for pattern recognition that you just don't get with words.

[1] https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/

You used monadic interface, instead you may use applicative interface.

liftM2 then become liftA2 and what you exemplify above (if I understand that correctly) will render as (g <$> f <*> (i <$> h <*> j)). It is unusual, because "g" goes before "f", but not much unusual. Note the explicit pure function application in the use of <$> and explicit apply <*>. I would like you and other readers compare that to the implicit apply in the "Are ours smaller than theirs?" paper I provided link above.

That translation shows what APL hides in its implicits.

Let me repeat. APL will certainly help you with computations over arrays but will most probably fail you big time with parsing of something like Ada. Haskell won't fail you in both cases at the expense of slightly more verbose program text.

Tacit programming exposes the need to "normalize" programs, to express them with as less function argument rearragement as possible. In stack based languages this is guided by the dependence on the stack(s) (data, return, control, whatever you invented). In point-free programming in Haskell, this is guided by argument capture and propagation. In K (I mostly studied it), as I understand it, tacit programming is guided by the implicit operations upon the stack of actual operations.

These variants of tacit programming are mostly the same, just some cases are more easily expressible or some operations conveniently assumed to be implicit.

Yet if you look at the original code and you version, the difference is perfectly clear.

Programmers are not computers, so syntax is important.

When you use C, you can write "~ x" and you can also write "??- x" [1], a slightly more verbose version of the same thing.

[1] https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C

I did exactly the same - I changed lexical structure of language, mainitaining the syntax, most of it.

Programmers, just like most other people, read words as a whole entities, quite like hierogliphics [2]. If we talk about "people are not computers" we should recognize that and allow for longer (yet atomic) lexical structure of the same language.

[2] https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/

Now I’m not saying that APL isn’t interesting and that it’s choices aren’t useful, just that the comparison here shows the difference in many ways is a surface level, visual one.

Of course syntax does matter but we could argue all day about whether replacing everything with symbols as APL does is more or less readable, for non-trivial code, than what factor/joy/forth do (once familiar with either style).

For example (adapted from Wikipedia and untested):

  arrayaverage =: +/ % # 
  arrayaverage 1 2 3

[0] https://mlochbaum.github.io/BQN/doc/tacit.html

[1] https://aplwiki.com/wiki/Function-operator_overloading

Should I feel called out? (Yeah, I get that its down to familiarity, rather than actually being hard to read)

Interesting read though.

The controlled producer-consumer flow in pipes is a subset of the declarative combinatorics of values in a point-free function composition. Approaching it as an ongoing process that generates values and consumes them at the same pace can make it easier to understand.

> This is shorter than the equivalent in an applicative language, because we have to name the input argument, that is only used once.

It's also wrong in that the predicate (4 >) is equivalent to (\x -> 4 > x) and thus tests for numbers being less than 4.

It's strange to argue that concatenation is structurally simpler than application, when you then need to add a quoting operator to add back the needed structure, while introducing a subtle distinction between evaluated and unevaluated code.

"Linear-style" programming becomes obvious to implement in a point-free style, but obtuse when you have variables, adding arbitrary usage restrictions.

>> This is shorter than the equivalent in an applicative language, because we have to name the input argument, that is only used once.*

Are you saying that in your eyes the Common Lisp and Haskell snippets are equally terse? To me the Haskell snippet looks a lot shorter and easier to read. Counting tokens also supports that judgement.

(But I'm not sure if I prefer terseness to that level. Explicitness has value too.)

  (function evenp)

  #'evenp

  (complement #'evenp)

  (lambda (n) (not (evenp n)))

http://clhs.lisp.se/Body/f_comple.htm

> These two fundamental operations -- curry and compose -- have very simple and intuitive semantics.

Curry: f(x, y) = f(x)(y)

For cookies, whip butter with sugar. Curried version: whip /f/ the butter /x/, then whip the result while adding sugar /y/.

Composition: f ⭘ g = f(g(x))

To produce nicely shaped cookies, shape the cookies /x/ on a tray first /g/, then bake them /f/.

Normally you write composition like readFile().then(stripComments).then(sort).then(takeFirst), or compose using shell pipes.

Composition is so widespread and so trivial-looking that it's even easy to miss.

Unlike the imperative `;`, which sequences commands in an absolutely obvious way, right?

i doubt it. composition and currying are so fundamental.

This should be reversed. It is not defined this way in mathematics nor in Haskell.

> whip /f/ the butter /x/, then whip the result while adding sugar /y/

That's not a valid explanation, since curried functions don't "act" until they've got all their arguments; i.e. we do not whip any butter until the sugar has been added.

> shape the cookies /x/ on a tray first /g/, then bake them /f/

Whilst this is accurrate, I think introducing a notion of time ("then") makes things much harder than they need to be. (That's one reason I find imperative programs hard to understand)

[0] https://gist.github.com/siraben/03510d1bf4d73b6958655887bee6...

Common Lisp has function-lambda-expression for obtaining a function object's source code object, if available, which it may not be:

http://clhs.lisp.se/Body/f_fn_lam.htm

Retaining the source code inside a compiled function is a waste of space.

Lisps support traditional ahead-of-time compiling. Propagating source code to the compiled binary is not only a waste of storage, but something that some people who don't want, namely those who regard compiling not as only an optimization but as a way of protecting IP and getting paid.

One of them is to use the threading macros (-> value fun1 fun2), and another one is to use the comp function. Both will require you to name arguments for anonymous functions, but this is likely not an issue as you have even better ways to get a lambda like using partial, comp itself or other higher level functions.