APL Since 1978 (2020) [pdf] | Hacker News Reader

APL Since 1978 (2020) [pdf]

dl.acm.org

87 pointsnequo23 comments

APL made a lot more sense in an era of 110 baud teletypes when brevity of a programming language was vastly more important than it is today.

The human mind is one of the few things whose bandwidth hasn't increased since then. APL still makes sense.

As someone who actually used APL professionally for ten years, I’ll say APL does not make sense today outside of being a valuable academic tool.

A next generation APL might make sense. No, it isn’t J. That’s an abomination. I have written about this on HN in the past.

Apparently many finance institutions are of another opinion, given how many array languages happen to survive on that space.

Additionally these kind of languages are much more ergonomic for GPPGU, and I expect them to eventually get more adoption into that space.

Financial institutions have codebases going back decades. In some cases they are stuck with decisions made long ago. That’s just about the only place you might find APL these days.

Go to a job site and search for APL jobs to get a sense of what reality looks like in the APL world.

There is more to array languages that only APL, besides if one wants to find a job in a niche domain, job boards aren't the way to find them, rather user groups and conferences.

https://www.arraycast.com/

https://aplwiki.com/wiki/Conferences_and_activities

Many people are more than happy working on a niche field, not everything has to be career scale.

FAANG bias here on HN, but financial tech is orders of magnitude leaner in general.

K's are often used as a sort of efficiency language. Often allows you to get the same work done in 1/1000th the code managed by 1/10th the staff running on 1/10th the hardware.

Anyway, these things are cyclical.

Lots of financial institutions at https://github.com/interregna/arraylanguage-companies but plenty of others too. (And that's a hobbyist-created list; not at all exhaustive.)

As someone who has spent quite some time developing a new APL dialect (with plenty of features that are not normally found in APL dialects), I'd love to hear more about what you'd like to see improved.

Notation is important and incredibly valuable. If you are abandoning notation, as J did, that’s a mistake.

If you search for APL and my username in HN you should be able to find opinions on this going back several years.

Is this the thread? https://news.ycombinator.com/item?id=27461338

That is an interesting read, although everyone seemed to be slightly hostile instead of openly discussing. I don't prefer J, even over APL; I find it not very well designed as a tool of thought. I do like some k's though; they more naturally feel like an ascii version of k. I think Arthur has a better feel for the ergonomics of verbose languages. I like BQN so far, but need to do something large-ish with it. I also like Klong, especially because Nils wrote a nice and easy to follow book about it. But it's not really a language with a community.

I think anyone interested in this kind of thing should just intern one of them ; you basically need so see every compute problem as an array problem and immediately see patterns for how to solve them. The 'gibberish' (as programmers not used to these kind of languages see it) is typically not written char for char, but the experienced programmer has idioms; when they encounter a problem seen before, an entire 'function' plops out, often shorter than a function performing the same task in another programming language would be name. Once there, the other ones are kind of more of the same. It's not very different from the first encounter with haskell or lisp or something; if you are not proficient, you won't see the advantage (or even think people using it are not totally sane).

You are right on many points. When I was using APL professionally I did not think of the symbols at all. They were part of my language. That’s what Iverson meant when he called it a tool for thought. No different from using musical or mathematical notation. In all cases one does not reach that level of “flow” with notation through casual contact. Most people who complain about APL’s notation have only had casual contact with it. That isn’t a valid frame of reference at all.

To be honest, this notational tool of thought feeling I really don't have with any of the popular languages. It is indeed like a natural language you are learning or one you are fluent in; when you are learning you have to translate to your native language all the time; when you are fluent, it just flows. That's the difference. I used to have it with Basic, C and Pascal, but never as much as with apl/k. Even those are recent for me. I had it with Prolog in university doing a major tract in symbolic NLP (my natural speech and dreams sometimes where in Prolog; that when talking with someone, I would actually just for clauses automatically). I find, personally, that joy of programming is vastly less using libraries than it is just having a fixed amount of functions and stdlib you know by hard and get fluent at.

But did you see / try BQN? I think it's an interesting attempt. And well built.

As an outsider, I am now wondering about how cool would an APL variant be, where you composed new words based in a set of out of the box syllables! Haha

> you basically need so see every compute problem as an array problem and immediately see patterns for how to solve them.

I was briefly a commercial APL programmer, after APL blew my mind in college. (An IBM 1130 running Fortran punched cards was the competition.) How much mileage one can get from "Every problem as an array problem" was APL's singular lesson for me, to this day.

In the same idea box for me: Monadic parsers in Haskell can be mind-blowing, but every problem isn't a string problem. Every problem is a algebraic data structure problem. They can be parsed and transformed as a natural generalization of strings. And, I love Lisps but they are as stuck in the past as APL, I truly believe that in 1,000 runs of the simulation our world would come out bottom 10% on how naturally we manipulate macros. Macros look strapped on; we're living in a first draft.

The goal of any advanced programming language should be to expose the thought process as a form of algebra, so we can learn to fly. APL did this well for its time. This is the appeal of languages like Haskell. We have barely scratched the surface of the algebra of parsing combinators, as a potential backbone for programming.

My imagined successor to APL is in spirit only: It is so agile at implementing macros as monadic parsing of algebraic data types that all other problems become easy.

Exactly right. APL was great at the time. As much as I love what it taught me, that was 40 years ago. It isn’t relevant today.

That’s one of them. Sorry I can’t be more helpful. I’m on a plane as I write this and have limited connectivity for about 18 hours.

Did you check BQN?

My notation is based on APL2, and includes some extensions from Dyalog. On top of that is new syntax to support first class functions and some other things.

The syntax for defining functions is also a bit different, but better in my opinion.

You can find some information here: https://kapdemo.dhsdevelopments.com/

I’m going to plug KlongPy, my Numpy based port of Klong (derivative of k which is derivative of APL) here:

https://github.com/briangu/klongpy

Amazing, thanks for sharing.

Let me take this opportunity to plug Nils his book [0] for people who don't know what Klong is.

[0] https://www.t3x.org/klong/book.html

Edit: Klongpy looks excellent; nice work!!

Reply on news.ycombinator.com