Comment by youssefabdelm | Hacker News Reader

Comment by youssefabdelm | Hacker News Reader

I think APL is very beautiful as someone who has longed to learn it from afar and not yet had the time, would be very curious to get more insight into how it changes the way you approach problems in both APL and programming in general, and how it gets you to think differently.

If I recall correctly, the Dyalog branch of APL allows for variable names? I kind of like the idea of zero variable names and all strange symbols. The reasoning that after you learn those, you can read any program and understand what's going on at every step, without needing to check what each function actually does -- that sounded very intriguing to me.

And the reason that "checks out" (or may) I guess is that the language's primitives are very carefully chosen such that you have a kind of extreme economy of "words" - so your LOCs will be so low such that you may not need to abstract lines into mysterious function names to reduce the number of lines a person has to read to understand what a program does. Aka the economy of words more than compensates for the lack of abstraction.

As far as I know, every major dialect of APL has had support for variable names. Symbols are used to name primitive functions, but not user-defined terms; if you want to use any intermediate term more than once, you likely want to assign it a name. And even leaving this aside, you probably would not very much like to write an entire program as a single very long expression; intermediate variables are necessary to break lines up.

A few decades ago, j (an apl dialect) innovated a form of tacit programming—programming functions which do not refer to their arguments by name, and which do not need to name intermediate terms to share them—but you still must name your functions if you would like to compose them or if you would like to avoid the extremely-long-line problem.

Generally, I write J programs using a mix of small, tacit functions, and larger explicit functions. The latter primarily comprise a sequence of assignments, and generally use unnamed tacit functions heavily (alongside explicit applications and references to other defined functions) when constructing intermediate terms. Explicit control flow is rare, but usually accomplished using builtin combinators and recursion when necessary.

Thanks for the correction! I haven't looked as deeply into J but now also curious to learn more. So many new and interesting terms to look up, thank you!

I agree maybe a little bit of variable and function naming is fine in some cases.

See https://apl.wiki/tacit

Note that seems to describe apl-style tacit programming, which is a lot less expressive than j.

All APL versions have had variable assignments, denoted by ←, e.g. `var ← 1 2 3`.

There is a concept of tacit, or point-free, programming, which avoids the variable names as parameters, for example the calculation of the mean `avg ← +⌿÷≢`. However this does become unwieldy pretty quickly, and it's easy to juggle too much. It is very useful for short snippets, where you avoid all of the ceremony and can just express the core thing you want to talk about (for the avg example, it's not improved by including a parameter: `{(+⌿ ⍵)÷≢⍵}` - the ⍵ parameter isn't informative at all, and nor would anything else, like `samples`). I think it is best to keep the tacit snippets short, and to assign good names to them.

Oh! Thanks so much for the correction. I was sure my memory would fail me here. That's a great point too with naming. In cases like this it makes a lot of sense. There are many cases I'm thinking of where people sometimes have long function names that do lots of stuff so you're not quite sure what the implementation is like.

There are many styles of APL, not just due to its long history, but also because APL is somewhat agnostic to architecture paradigms. You can see heavily imperative code with explicit branching all over the place, strongly functional-style with lots of small functions, even object-oriented style.

However, given the aesthetic that you express, I think you might like https://github.com/Co-dfns/Co-dfns/. This is hands-down my favorite kind of APL, in which the data flow literally follows the linear code flow.

ngn/apl is mostly a subset of Dyalog, but allows assigning to glyphs: https://abrudz.github.io/ngn-apl

Reply on news.ycombinator.com