3 ms·

Sure, I’ve read Iverson’s paper. I think the notation is perhaps what enabled him to come up with what I feel is the important thing: the semantics. I care a lo

Sure, I’ve read Iverson’s paper. I think the notation is perhaps what enabled him to come up with what I feel is the important thing: the semantics. I care a lot about function-level programming, tacit programming, implicit iteration, and dimension-agnostic code; I don’t really care for APL/J notation specifically, and not because of the funny character set or terseness, but because it’s not compositional. Changing the symbols out for words wouldn’t help much with that; I just think it would make it more popular.

Aardappel 8y ago
Could you elaborate what is not compositional about it? I always thought one of the biggest attractions of anything point-free is its compositionality (from which follows easy refactorability).
- evincarofautumn 8y ago
  Composition lends itself to point-free code, but not all point-free code is built from composition. By “it’s not compositional” I mean a few things: 1. Tacit programming in APL-family languages is very much about application of functions to arguments, not function composition; it’s just that the arguments can be made implicit in various ways, e.g., forks & hooks in J. 2. You can’t always extract a subexpression verbatim into a definition and have it work the same way, for example because you need to disambiguate whether a verb is being used monadically or dyadically. 3. Conversely, you can’t always do evaluation by just substituting the definition of a word into an expression where that word is used. How an expression is parsed depends on the types (well, parts of speech—noun, verb, adverb) of intermediate results and the context of the sentence. Part of the reason for all this complexity is just that the language tries to be purely function-level (à la Backus’s “Can Programming Be Liberated from the Von Neumann Style?”), but not all terms denote functions. That’s why I prefer concatenative programming languages—they’re much simpler in structure because all terms do denote functions and your program is just a flattened dataflow graph (typically a post-order traversal).
  - tluyben2 8y ago
    > I prefer concatenative programming languages I can see that point. Concatenative languages are languages people also (like APL/k/j) cry about when they see code in it; they are usually terse as well (words are usually kept short) which is indeed why I like it. When I encounter a new board, I first port a Forth.
tluyben2 8y ago
> but because it’s not compositional. Isn't it? What do you mean by it because it is but maybe you mean something else? Edit: answered below, let us read. > I just think it would make it more popular. I think many languages are not looking for 'more popular' per se, especially if they have to sacrifice the basic principles of the language that users/fans like about it. Like Arthur/k I hate scrolling and I already ache seeing the masses of (for me unnecessary) code you produce out of the beauty that is APL. I work most of my time in languages far more verbose, so please do not take the nice languages that do not have that away from me. It wouldn't be very hard to write a language on top of k/apl to do that though if you wanted to; like q on k, as long as you can translate back to and inspect the original, like q on k, then it's not too bad I guess.

Aardappel 8y ago

Could you elaborate what is not compositional about it? I always thought one of the biggest attractions of anything point-free is its compositionality (from which follows easy refactorability).

evincarofautumn 8y ago
Composition lends itself to point-free code, but not all point-free code is built from composition. By “it’s not compositional” I mean a few things: 1. Tacit programming in APL-family languages is very much about application of functions to arguments, not function composition; it’s just that the arguments can be made implicit in various ways, e.g., forks & hooks in J. 2. You can’t always extract a subexpression verbatim into a definition and have it work the same way, for example because you need to disambiguate whether a verb is being used monadically or dyadically. 3. Conversely, you can’t always do evaluation by just substituting the definition of a word into an expression where that word is used. How an expression is parsed depends on the types (well, parts of speech—noun, verb, adverb) of intermediate results and the context of the sentence. Part of the reason for all this complexity is just that the language tries to be purely function-level (à la Backus’s “Can Programming Be Liberated from the Von Neumann Style?”), but not all terms denote functions. That’s why I prefer concatenative programming languages—they’re much simpler in structure because all terms do denote functions and your program is just a flattened dataflow graph (typically a post-order traversal).
- tluyben2 8y ago
  > I prefer concatenative programming languages I can see that point. Concatenative languages are languages people also (like APL/k/j) cry about when they see code in it; they are usually terse as well (words are usually kept short) which is indeed why I like it. When I encounter a new board, I first port a Forth.

tluyben2 8y ago

> but because it’s not compositional. Isn't it? What do you mean by it because it is but maybe you mean something else? Edit: answered below, let us read. > I just think it would make it more popular. I think many languages are not looking for 'more popular' per se, especially if they have to sacrifice the basic principles of the language that users/fans like about it. Like Arthur/k I hate scrolling and I already ache seeing the masses of (for me unnecessary) code you produce out of the beauty that is APL. I work most of my time in languages far more verbose, so please do not take the nice languages that do not have that away from me. It wouldn't be very hard to write a language on top of k/apl to do that though if you wanted to; like q on k, as long as you can translate back to and inspect the original, like q on k, then it's not too bad I guess.