[HN Gopher] A Personal History of APL (1982)
       ___________________________________________________________________
        
       A Personal History of APL (1982)
        
       Author : lupin_sansei
       Score  : 109 points
       Date   : 2023-12-03 05:46 UTC (17 hours ago)
        
 (HTM) web link (ed-thelen.org)
 (TXT) w3m dump (ed-thelen.org)
        
       | pagekicker wrote:
       | We had APL on our Prime minicomputer at Swarthmore when I started
       | there in 1978.
        
         | jacquesm wrote:
         | Did you do anything with it?
        
         | Syzygies wrote:
         | My missive a few years ago about APL at Swarthmore in the
         | mid-1970s:
         | 
         | https://news.ycombinator.com/item?id=27460887
         | 
         | > In the mid-seventies at Swarthmore College, we were mired in
         | punched card Fortran programming on a single IBM 1130. ... Late
         | one Saturday night, I made a misguided visit to the computer
         | center while high, smelled sweat and fear, and spun to leave.
         | Too late, a woman's voice: "Dave! I told Professor Pryor he
         | needed you!" ... So busted! Then I heard this voice "See these
         | square brackets? See where you initialize this index?" He was
         | spectacularly grateful.
         | 
         | > One cannot overstate the rend in the universe that an APL
         | terminal presented, catapulting me decades into the future.
        
       | robomartin wrote:
       | I used APL professionally for about ten years. One of the most
       | interesting applications I worked on was the analysis of DNA
       | sequencing data during the Human Genome project.
        
       | 082349872349872 wrote:
       | It's at least reassuring to learn from the 1952-1954 section that
       | the phenomenon of doing things without having any clue about them
       | easily predates the microprocessor.
       | 
       | (btw I second the recommendation of the 1962 _A Programming
       | Language_ )
       | 
       | Edit:
       | 
       | > _The third page had an illustration that, in a few short lines,
       | described George Dantzig 's simplex algorithm simply and
       | precisely._
       | 
       | > _That was the overwhelming, crucial experience._
       | 
       | This is the crucial feature of the APL family for me: they permit
       | algorithm discussions via inline, not block, content.
       | 
       | eg: https://news.ycombinator.com/item?id=28970345
       | 
       | Edit 2: Upon reflection, it's probably also the Achilles' Heel of
       | the APL family: most people vastly prefer easy and DWIMy over
       | simple and precise.
       | 
       | Edit 3: found the paper containing the simplex algorithm:
       | https://www.jsoftware.com/papers/DFSP.htm Note that 1960 was
       | before "structured programming" so we now have (with the benefit
       | of hindsight) much better ways to express the control flow of
       | this calculation.
        
         | mkromberg wrote:
         | > most people vastly prefer easy and DWIM over simple and
         | precise
         | 
         | Most people also vastly prefer not having to work on difficult
         | problems. Iverson was clearly trying to provide a notation that
         | would help the (admittedly smaller) group of people who find
         | solving difficult problems interesting and valuable.
        
           | jacquesm wrote:
           | In the beginning of the computer age _all_ problems were
           | difficult. If not because of the problem itself then because
           | of the limitations of the machines. It 's amazing they did as
           | much as they did with so little, your average Arduino makes
           | the best hardware from those days look puny.
        
           | 082349872349872 wrote:
           | If you're _the_ M Kromberg, any chance you could ask J
           | Scholes to whip up a dfns version of Iverson 's 1960 Simplex
           | algo for us?
        
             | bobterryo wrote:
             | Sadly, John Scholes passed away in 2019.
             | https://aplwiki.com/wiki/John_Scholes
        
               | 082349872349872 wrote:
               | Sorry to hear that, but very glad to have run across
               | http://dfns.dyalog.com/downloads/howcomp.pdf as a
               | result...
        
       | spit2wind wrote:
       | I find it sad that APL nowadays means Dyalog. They appear to do
       | amazing work. Unfortunately, the license isn't open. Why would I
       | invest time learning it only to be locked in? I wonder how much
       | licensing plays in APL not being more popular and used in the
       | present day. There are open variants, like GNU APL2 and J.
       | However, GNU APL2 has none of the advancements made in the past
       | 40 years and J is J, not APL. The notation is simply different.
        
         | liveranga wrote:
         | There's also April APL: https://github.com/phantomics/april
         | 
         | Also the array language family seems to be stronger than ever
         | with foss: ngn/k, BQN, uiua, and of course J but as you
         | mentioned they're all different languages.
        
           | lbatista wrote:
           | I cant recommend enough this april video of Andrew Sengul:
           | 
           | https://www.youtube.com/watch?v=AUEIgfj9koc
        
           | eggy wrote:
           | April is amazing. I have used J for over a decade, and I am
           | currently being swept away by uiua, but my old Lispy love
           | teamed up with APL in April is a knockout combo: Do the
           | generic stuff with Lisp and the numerical magic with APL.
        
           | jacquesm wrote:
           | No mention of 'R'?
        
           | spit2wind wrote:
           | Thank you. I had seen April previously although it looks like
           | it's had a lot of updates since then. I appreciate you
           | bringing it back to my attention :)
           | 
           | It looks like it can load pure APL files.
           | 
           | All the examples I see use the Lisp repl and APL is called
           | within strings. Does it provide an APL repl, too?
        
           | unkeptbarista wrote:
           | I had not heard of uiua before, but I'm familiar with both
           | APL and stack languages, so it should fun to explore it its
           | capabilities.
        
         | abrudz wrote:
         | Anyone is of course free to fork GNU APL, or any other APLish
         | FOSS language, and modify it to include Dyalog APL's features.
         | However, Dyalog can only do so much amazing work because users
         | that make significant amounts of money with Dyalog APL pay
         | enough to support 25 full-time employees. Note that as long as
         | you make less than PS5000 per year from its usage, you can use
         | Dyalog APL without limitations.
        
         | 5- wrote:
         | genuinely curious -- do you not feel the burden of being locked
         | in with cpython, gcc/clang, rustc, ...?
         | 
         | or do you maintain forks of those?
        
           | panaeon wrote:
           | what do you mean by "locked in"? They all support external
           | libraries for extra functionality and this extension
           | mechanisms are very well thought over. The syntax can't be
           | easily extended which I believe could be a good thing,
           | because it encourages using common idioms instead of ad-hoc,
           | understandable only by its author inventions. Not to mention
           | that some form of syntax extension is present in all of your
           | examples.
        
             | 5- wrote:
             | > They all support external libraries for extra
             | functionality
             | 
             | this is, of course, also true for dyalog apl, just the same
             | as any practical programming system, be it open-source or
             | not.
        
           | spit2wind wrote:
           | I don't feel locked in by the license of those projects. They
           | have permissive licenses. Anyone can maintain them.
           | 
           | I don't need to personally maintain a fork in order for the
           | possibility to maintain one to exist.
        
             | 5- wrote:
             | what is your realistic estimate for the capability of any
             | non-corporate group to pick up maintenance of one of the
             | open-source projects?
             | 
             | proprietary programming systems typically come with escrow
             | agreements, providing access to the source code to customer
             | e.g. if the vendor stops supporting the product. that
             | wouldn't be materially different from another large
             | corporate picking up e.g. llvm/clang if apple/google stop
             | being interested.
        
       | __0x01 wrote:
       | Can APL can be used to implement Machine Learning algorithms? It
       | seems like a good fit.
        
         | abrudz wrote:
         | Yes, see e.g https://apl.wiki/nn
        
         | martinsmit wrote:
         | Yes, but no one's made a reverse-mode autodiff system for it
         | yet, so all of the linked examples have hand-written
         | derivatives.
        
           | abrudz wrote:
           | https://www.youtube.com/watch?v=ToQoJ1Bbpus&t=1165s
        
       | TheOtherHobbes wrote:
       | The language is interesting, but the management ideas in this are
       | very strange.
       | 
       | Example: tin flippers. Items are being checked manually and
       | miscounted. The numbers are inherently inaccurate. And he makes
       | the point that this applies in many other situations - some where
       | the inputs are mechanical, so "Use a machine" isn't a solution.
       | ("Use a better machine" might be. But how would you know without
       | being able to monitor output quality?)
       | 
       | How is a programming language supposed to fix any of this?
       | Finding gross inconsistenicies shouldn't be too hard, but
       | automating broken processes algorithmically means you have
       | automated broken processes.
       | 
       | This is not at all the same problem as formally specifying
       | software in ways that make it more reliable.
       | 
       | The other problem is that it sees software as strictly sequential
       | in->stuff happens->out.
       | 
       | This is basically batch mode, not real time. As soon as you need
       | real time I/O everything gets a lot more complicated. I don't see
       | anything in APL that solves that.
       | 
       | And that's even more true of business processes. To add: it's not
       | that analytics can't be useful. But APL won't somehow magically
       | guarantee that your analytics are any better or more useful than
       | output from some other language or system.
        
         | anotherjhacker wrote:
         | Real time processes are indeed critical in some contexts. And,
         | arguably, we should be putting more effort into some of those
         | contexts.
         | 
         | For the APL family, that's often a call for code which works
         | with external interfaces. In many potential APL environments a
         | handful of well designed custom primitives would get you where
         | you need to go.
         | 
         | But no programming language is adequate for all roles, and that
         | includes APL. (It can still be useful for modeling /
         | prototyping for real time work, but that's not always
         | necessary.)
        
           | jacquesm wrote:
           | Everything involving a user is a real time thing. But that's
           | now how the software industry views it, somewhere along the
           | line the user became a peripheral rather than the other way
           | around.
        
             | 082349872349872 wrote:
             | "Every system is fault-tolerant; unfortunately in most of
             | them the component tolerating the faults is the end user."
        
       | fxj wrote:
       | The inventor of APL, Ken Iverson, also made the language J which
       | is very much influenced by APL but does not use the special
       | characters of APL. Think of it as ASCII-APL. It is a very nice
       | language to program in and they have a decent user community. It
       | is open source and is incredibly fast and looks at the first
       | glance as cryptic as APL.
       | 
       | https://www.jsoftware.com
        
       | jacquesm wrote:
       | The easiest way for non-APL programmers to begin to understand
       | APL is to see what it hasn't got: boilerplate and loops. If you
       | discard those from any other programming text you're left with
       | the essence of what the code does. APL is only explicit about
       | that essence, the rest is inferred by the interpreter. That's why
       | it is so compact and that's why if you're used to step-by-step
       | instructions with a ton of air in between you will initially find
       | it hard to read. But that gets easier over time and before you
       | know it you'll think of other languages as hopelessly verbose.
        
       | usgroup wrote:
       | I tried J (Iverson's successor to APL) in earnest but struggled
       | to understand what I was supposed to do when I needed data
       | structures other than arrays. E.g. tries, trees, hash tables and
       | so on. The majority of the out-of-the-box vocabulary is centered
       | on arrays, so it seemed that either you convert your problem to
       | some kind of an array representation, or go somewhere else.
        
         | anotherjhacker wrote:
         | J has primitives (like I. and i. and e. and the primitives
         | which set up for their use) which serve some of those roles.
         | 
         | But, yes, approaches which use some kind of array
         | representation are highly favored by the language (and by other
         | languages, to varying degrees, once you understand the patterns
         | and issues).
        
         | pasquinelli wrote:
         | i've also tried learning J and can't really say i've managed it
         | yet, but i think the idea is that everything is an array. in J
         | an array can contain a box, and a box might contain an array,
         | so you have nested arrays, (different from multidimensional
         | arrays.)
         | 
         | lisp baffled me for a while because, in my mind, a list is
         | different from a tree, but in lisp a list element might be
         | itseld a list, and so a lisp list might be a tree. similar
         | situation with J arrays.
         | 
         | i'm not sure how APL does it. i /think/ it uses a flat array
         | model, but i'm not sure what that means exactly, or if it's
         | even applicable to modern APL, let alone what it might imply
         | about bending APL arrays into other data structures.
        
       | eggy wrote:
       | J influenced the creation of Pandas by Wes McKinney.
       | 
       | Ah, I sometimes have the wild thought that if he had just stuck
       | with J or APL, Python may not be where it is today in ML. Python
       | has become the Borg.
        
       | jodrellblank wrote:
       | Someone in the HN comments called out that J is the proof that
       | Iverson's "Notation as a Tool of Thought" is a failed idea. Even
       | Iverson himself, the inventor of "Iverson Notation" (proto-APL)
       | as a better math notation, the inventor of APL, who used it to
       | design the IBM 360's processor and then turned it into a
       | programming language, abandoned it for ugly ASCII scribble (J)
       | because that was more convenient.
       | 
       | I guess the ideas, not the notation, turned out to be the
       | important part after all.
       | 
       | " _I have only made this letter longer because I have not had the
       | time to make it shorter._ " - It's Advent of Code[1] (AoC) season
       | again; take a moment to look at the answers people put in the big
       | Reddit answers threads e.g.[2]. The comments are all a
       | beautiful/awful zoo of languages - wildly varying in programmer
       | experience level, familiarity with the language, choice of
       | approach and algorithm, runtime, focus on a tidy solution or a
       | quick answer. I wish we could see how much time people put into
       | their solutions - I suspect this famous quote applies and it
       | takes longer whether you polish a plain language or write
       | directly in a terse language. I think the hurried or
       | inexperienced answers tend to be long and garbled, the
       | experienced and polished answers tend to be clean and clear. The
       | racing leaderboard entries that I've seen - people seeing the
       | problem and getting an answer ASAP - tend to be Python, and tend
       | to be short and clear. They're almost never (APL, J, K, Q, R,
       | uiua, Haskell). Does that say anything of value about the ability
       | to quickly and clearly express ideas in a language?
       | 
       | I feel like there's enough of these answers now after years of
       | AoC for someone to analyse and compare the languages. My gut
       | feeling is that non-golfed Python still comes out the most easily
       | writable and easily readable, the nicest balance between density
       | and verbosity.
       | 
       | [1] https://adventofcode.com/ - daily puzzles through December,
       | solved with code using whatever language you like, however you
       | like, the site only checks your answer not your working.
       | 
       | [2]
       | https://old.reddit.com/r/adventofcode/comments/1883ibu/2023_...
        
         | abrudz wrote:
         | https://blog.vero.site/post/noulith seems to be familiar with
         | both APL and J, and draw some inspiration from them...
        
       | WalterBright wrote:
       | GPU programming looks like the modern incarnation of APL.
        
       ___________________________________________________________________
       (page generated 2023-12-03 23:01 UTC)