As I remember, brevity was one of PG's goals in creating Arc. That thought came to mind as I was reading this article.
I haven't engaged in APL programming but I have done some in other array languages (Klong, J and Q'Nial) and the practice has been enjoyable, not only in getting the answer but also in learning a new way to think/twist one's mind.
Wow, perhaps I should become an APL programmer. (My links below are probably familiar to everyone here, so forgive the shameless replugs. I'm mostly just working through commonalities for my own self.)
"[There is] a sharp contrast between Subordination of Detail and Abstraction as the term is commonly used in Computer Science. Iverson’s notion of subordination is the elimination of notational obligations through the use of generalization, systematic extension, and implicit guarantees. The usual notion of abstraction is the means by which 'API' barriers may be introduced to implement conceptual frameworks that suppress underlying implementation considerations in order to allow a black box reasoning at a different, non-native abstraction level."
I'm very partial to this point, but confusingly I've been calling Iverson's notion of subordination of detail "abstraction", and Iverson's notion of abstraction "service" [1] or "division of labor" [2]. Though lately I try to avoid the term "abstraction" entirely. That seems on the right track.
Regardless of terminology, this is a critical distinction.
"Common practice encourages decomposing a problem into very small components, and most programming languages emphasize a clear picture of a small piece of code in isolation. APL emphasizes finding ways of expressing solutions around the macro-view of the problem."
Quoting Knuth: *"I also must confess to a strong bias against the fashion for reusable code. To me, re-editable code is much, much better than an untouchable black box or toolkit."
Compare me: "Watch out for the warm fuzzies triggered by the word 'reuse'. A world of reuse is a world of promiscuity, with pieces of code connecting up wantonly with each other. Division of labor is a relationship not to be gotten into lightly. It requires knowing what guarantees you need, and what guarantees the counterparty provides. And you can't know what guarantees you need from a subsystem you don't understand."
---
OMG, he's talking about "big picture" and "optimizing for the rewrite" I call the latter rewrite-friendliness at http://akkartik.name/about. And "big picture" is in the navbar on the right of my side.
---
Ok, that's enough replugging. The most tantalizing idea for me here is to try to get structure to do some of the heavy lifting that names do in more conventional languages.
