The arary languages have always struck me as the extreme end of this. The semantics are very dense: each operator does a lot. Intermediate results aren't granted names. The few people who can follow this find it pleasant as the "extraneous" information is removed. Most people find it hard to adapt to. And it doesn't readily suit a lot of business logic.
Possibly the one context where arrays-as-language-primitive has really taken off is the 3D processing world, first with OpenGL's matrix stack computation and later with shader programming. Note that shader programming is the other way round: you don't start with a screen object and apply functions to it mapped across all the pixels (fragments), you write a small program as if for one pixel. Even if the end result is executed in a highly parallel fashion.
I don't like that blog post on "semantic compression". He's rediscovered refactoring but doesn't think so:
> This is a very bottom-up programming methodology, a pseudo-variant of which has recently gained the monicker “refactoring”, even though that is a ridiculous term for a number of reasons that are not worth belaboring at the moment. I also think that the formal “refactoring” stuff missed the main point, but that’s also not worth belaboring. Point being, they are sort-of related, and hopefully you will understand the similarities and differences more over the course of this article series.
Um, what? Refactoring is called refactoring because that's what it is: You're pulling out a "factor" of the program and reifying it into a symbol which then replaces the factored code. "semantic compression" is a great name for it, but it's been the done thing in Forth, for example, for many decades.
It's just like factoring polynomials.
This is a textbook example of what I call "half-smart": He's smart enough to write this article, but not smart enough not to.
(Also that site disables reader mode. Boo! Why would you do that?)
I would argue that most programmers are fine with this. Unix pipes are a very similar point-free way to program that we're all comfortable with. If people came to APL thinking of it as something similar to pipes as opposed to something similar to C they might have an easier time with it.
It's funny to call this point free when OOP notation like ps().grep(pid).kill(9).or(halt); comes down to the same thing. Just rambling because I'm confused. lol.
You're right, method (OOP) notation lets you compose/pipeline functions. Pipes enable the same thing. So does F#'s pipeline (|>) operator, Haskell's composition (.) operator, Clojure's threading macro, concatenation in stack-based languages like Forth, etc... It's not a concept unique to OOP, which is why GP referred to 'point-free programming', which describes the general idea.
> Possibly the one context where arrays-as-language-primitive has really taken off is the 3D processing world, first with OpenGL's matrix stack computation and later with shader programming.
There are many more applications than 3D, most notably APL and all its descendants applications in analysis work, logistics, stats and so on.
The arary languages have always struck me as the extreme end of this. The semantics are very dense: each operator does a lot. Intermediate results aren't granted names. The few people who can follow this find it pleasant as the "extraneous" information is removed. Most people find it hard to adapt to. And it doesn't readily suit a lot of business logic.
Possibly the one context where arrays-as-language-primitive has really taken off is the 3D processing world, first with OpenGL's matrix stack computation and later with shader programming. Note that shader programming is the other way round: you don't start with a screen object and apply functions to it mapped across all the pixels (fragments), you write a small program as if for one pixel. Even if the end result is executed in a highly parallel fashion.