It's more concise, which has value. In particular, think about how maths really consists of packing more and more concepts into higher level definitions. This is similar: higher level concepts become primitives and allow you to think faster and build more complex objects.

I can see that, though it really depends on what these abstractions are, how complete they are in solving in a variety of problems, or I suppose, how frequent the problems it makes easier in relation to ones it makes harder.

I’d have to know a lot more and spend a lot of time before judging.

But I am not impressed seeing a single example. I could hypothetically write a language where mergesort is the operator * and reversing an array is the operator + and showcase how in my language 30 lines of code becomes 1. That would be insanely nice if you’re doing something which just requires thinking about sorting and reversing arrays but all together, very poor thing to build a standard language on.

That's what people do on codegolf.stackexchange.com with the dedicated golfing languages. What's interesting about APL is that it started out as linear algebra and became array programming, and the primitives are more "things which are useful transforms to do on arrays" rather than "thing people wanted to do in one problem turned into a symbol", and that's enough to be useful in many tasks.

> "That would be insanely nice if you’re doing something which just requires thinking about sorting and reversing arrays but all together, very poor thing to build a standard language on."

Prolog has linked lists as its main data structure, which means prepend is more performant than append. In the SWI Prolog documentation for foldl[1] it says "No implementation for a corresponding foldr is given. A foldr implementation would consist in first calling reverse/2 on each of the m input lists, then applying the appropriate foldl. This is actually more efficient than using a properly programmed-out recursive algorithm that cannot be tail-call optimized". i.e. you don't have to have a problem which involves reversing arrays, for reverse to be a useful part of a solution.

In APL reverse is one character ⌽. In C# to find the first comma in a string you use IndexOf(',') and to get the last one you use LastIndexOf(','). In APL you would use the equivalent of indexOf(Reverse(string)) and then you wouldn't need the specialised LastIndexOf - and wouldn't every other function which works from the left of a string or array to have an equivalent which works from the right. https://aplcart.info/ is a database of idioms and samples of useful APL and it has 168 pieces of code using ⌽.

[1] https://www.swi-prolog.org/pldoc/man?predicate=foldl/4

It _can_ be more performant because computers are exceedingly fast at cranking through arrays, especially if you can leverage SIMD, but its not just that.

It's useful to play around with an array language until the paradigm clicks. Often, imperative code can be better handled in an array style. Sometimes long, fiddly functions can be greatly simplified if you use array operations instead or in conjunction with other styles.

If you believe that verbosity has a cost and that only the most complex functions should have the privilege if being verbose, it's easy to see a point.

Here's a Haskell example:

    (+) <$> Just 1 <*> Just 2

Versus:

    do x <- Just 1
       y <- Just 2
       Just (x + y)

I would always prefer the first for something of this complexity because the latter example implies something more complex is happening to me because it takes more space.

If I had something more complex, I'd prefer to factor that operation into functions small enough that the first variation makes sense over using the second.

This does trade "beginner+ can read this quickly" for "some beginners can read this".

I'm of the opinion you shouldn't optimize for "some beginners can read this" because of very diminishing returns.

Instead I aim for "beginner+ can read this" or in some cases "intermediate+ can read this".