[HN Gopher] The APL Source Code (2012)
       ___________________________________________________________________
        
       The APL Source Code (2012)
        
       Author : pncnmnp
       Score  : 97 points
       Date   : 2022-12-20 11:31 UTC (11 hours ago)
        
 (HTM) web link (computerhistory.org)
 (TXT) w3m dump (computerhistory.org)
        
       | mountain_peak wrote:
       | I used APL in university and later on during Y2K conversions (fun
       | stuff), but found out much later on that APL was the de-facto
       | language and interface to of one of the first microcomputers -
       | the MCM/70 [0]
       | 
       | [0] https://www.historyofinformation.com/detail.php?id=4340
        
       | abrudz wrote:
       | https://apl.wiki/APL\360
        
       | coldcode wrote:
       | I always loved APL when I was a student around 1980, I had access
       | to the little IBM "transportable" that supported APL and Basic, I
       | think it was the 5100 or 5110. I remember writing a little table
       | tennis game in APL, which was likely unreadable to me a day
       | later.
        
         | pncnmnp wrote:
         | Sounds silly, but do you have the source code for your table
         | tennis game? If not, do you remember the logic you used? Was it
         | using Graphpak? I am curious as to how one would write a table
         | tennis game without any conditionals.
        
       | xedrac wrote:
       | > But APL programs are often cryptic and hard to decode. Some
       | have joked that it is a "write-only language" because even the
       | author of a program might have trouble understanding it later.
       | 
       | So the original Perl?
        
         | eggy wrote:
         | I actually find it way easier and shorter to review code I've
         | written in J and APL, because it is so succinct and the symbols
         | are well defined. Having to review something that is a
         | paragraph or one page of code is much easier than following
         | pages of other programming languages code. You can comment APL
         | as you can in most PLs, and with the REPL-like dev environment,
         | you can test pieces of code for verification quite immediately
         | and easily. I love APL and J. I am currently using April [1].
         | APL in Lisp for the best of both worlds - the expressivity of
         | APL (and Lisp), and the CL ecosystem for batteries included.
         | The mix is always surprising.                 [1]
         | https://github.com/phantomics/april
        
           | alaaalawi wrote:
           | we need just the correct expectations. APL is like
           | mathematics for me. i need to read it several time to
           | understand dense unfamiliar terms and formulas. same goes for
           | APL. it is not the typical language which i assume can be
           | read while driving
        
           | trenchgun wrote:
           | What are you using April for?
        
         | renox wrote:
         | Way harder to read than Perl..
         | 
         | You can create obscure Perl as you can create obfuscated C as
         | in any language, but if you think about the reader you can
         | create 'easy to read' program in Perl, even by a beginner.
         | 
         | But creating 'not obfuscated' APL? That's really hard!
        
         | melling wrote:
         | Nope, not even close. I've written/read lots of Perl.
         | 
         | APL is a completely different paradigm.
         | 
         | Every now and then I get the urge to take a deep dive into APL
         | or J but I really need a use case.
         | 
         | Since they are array languages they seem like they might be
         | good for machine learning?
        
           | maximus-decimus wrote:
           | The use case is use J or K is to do advent of code or the
           | Euler project :p
           | 
           | APL is a tool for thought more than a real programming
           | language so in my opinion it's best suited to boost your
           | puzzle solving ability.
        
           | eggy wrote:
           | Here's one paper on CNN's in APL:
           | https://dl.acm.org/doi/10.1145/3315454.3329960
        
           | phantomics wrote:
           | Image processing is a fun use case. For example, here's a bit
           | of Common Lisp using April and the Opticl library to create a
           | mirrored meme image:                 (opticl:write-png-file
           | "~/out.png" (april-c "2 0[?]{(x s)-[?]-2 0 [?] ([?][x],[x][?]
           | )[?][x][?]s[?][?]|[x][?](1-2xs)x[?]2/[?]x[?][?][?]}"
           | (opticl:read-png-file "~/in.png")))
           | 
           | The 2 0 at the start of the APL line above controls the
           | mirroring behavior. The second number can be set to 0 or 1 to
           | choose which side of the image to mirror, while the 2 sets
           | the axis along which to mirror. This will be 1 or 2 for a
           | raster image but this function can mirror any rank of array
           | on any axis.
           | 
           | April was used to teach image filtering in a programming
           | class for middle-schoolers, you can see a summary in this
           | video: https://vimeo.com/504928819
           | 
           | For more APL-driven graphics, April's repo includes an
           | ncurses demo featuring a convolution kernel powered by [?],
           | the stencil operator: https://github.com/phantomics/april/tre
           | e/master/demos/ncurse...
        
       | sxcurry wrote:
       | My very first programming experience was with APL\360, using a
       | time share IBM terminal with the APL type ball. We wrote code in
       | a Geodetic Sciences class to compute Least Squares solutions to
       | survey networks. I really liked APL...
        
       | leephillips wrote:
       | I believe Einstein's only notational innovation was the summation
       | convention, which remains very popular. Am I wrong?
       | 
       | By the way, APL was the first language I learned, on the APL/360
       | system described here, using paper terminals.
        
       | mncharity wrote:
       | "ChatGPT explains Arthur Whitney's J Incunabulum"[1] was linked
       | in a recent comment[2].
       | 
       | Reading APL code, at least for a novice me, includes puzzling out
       | "ok, now what's going on there?". Being able to highlight a bit
       | of code, and get an explanation, as if sitting with the author,
       | or reading annotated code, might usefully lower the barrier to
       | reading APL?
       | 
       | I've seen several "here is an APLish program, and I'll go through
       | and explain it" posts over the years, though I'm failing to find
       | one now. If that could be somewhat automated...
       | 
       | [1] https://medium.com/@solarbreeze69/chatgpt-explains-arthur-
       | wh... [2] In "J one-page interpreter fragment (1992)"
       | https://news.ycombinator.com/item?id=34050715 , the brief comment
       | https://news.ycombinator.com/item?id=34053932 .
        
         | calherries wrote:
         | Interesting observation. In general this would allow writing
         | code in formats designed for writing (concise shorthand like
         | APL), and then separately expanded to a format optimized for
         | readers that are less familiar.
        
       | marcodiego wrote:
       | > To access this material, you must agree to the terms of the
       | license displayed here, which permits only non-commercial use and
       | does not give you the right to license it to third parties by
       | posting copies elsewhere on the web.
       | 
       | We have to agree to these kinds of terms about something that is
       | more than half a century old and has zero commercial value.
       | Something in the copyright system is deeply broken.
        
         | bragr wrote:
         | The current IBM zSeries is still backwards compatible with
         | System/360 (and latter) models, so there could still be
         | important APL\360 running in the wild.
        
         | nordsieck wrote:
         | > We have to agree to these kinds of terms about something that
         | is more than half a century old and has zero commercial value.
         | Something in the copyright system is deeply broken.
         | 
         | I don't disagree.
         | 
         | The trouble is that, while almost everything 50 years old has
         | almost no commercial value, a few things that old have
         | tremendous commercial value.
         | 
         | My preferred solution is to have a very short automatic
         | copyright period combined with a fee for registered works that
         | increases exponentially based on the date of registration. Not
         | that it really matters - I'm sure such a solution would never
         | be enacted into law.
        
       | abraae wrote:
       | APL prevented me from getting into software for many years.
       | 
       | Back in the 80s I was an mainframe engineer at IBM. One of our
       | customers (a bank?) was heavily into APL, and occasionally I
       | would fix one of their keyboards.
       | 
       | (Sidenote: these were beautiful keyboards, and their keys were
       | individually repairable. Also pleased to share my first mastodon
       | link! https://mastodon.social/@hanshuebner/109412183054578487)
       | 
       | Watching people programming on these looked so intense and
       | intimidating that I decided software wasn't for me, and it took
       | years to find out today actually it was.
        
       | tluyben2 wrote:
       | I like APL (and k/j). Problem is, outside trading (and even there
       | it's a niche), it is just not popular enough. This also because
       | most people dismiss it as line noise / write only programming
       | language; that's usually only people who never used it or used it
       | briefly saying that. But it's hard to promote anything that has a
       | reputation like that.
       | 
       | What is a fairly interesting observation (more people have made
       | it, including Arthur Whitney); being able to reason about a
       | program for which you can see all the code on one A4 without
       | having to clickthrough into functions, search, browse through
       | files, classes or even having to _scroll_ is incredibly powerful.
       | All you need is the cheatsheet (provided in your article) (which
       | you know by heart in no time flat) and the program, which, often
       | fits on 1 A4 or less. Modern example of that would be Aaron Hsu
       | his 17 LoC parallel APL compiler[0] (from his thesis).
       | 
       | [0] https://www.bonfire.com/co-dfns-thesis-edition/
        
         | baruchel wrote:
         | The reason you give (write only programming language) is indeed
         | ONE of the reasons people may give when discussing about array-
         | languages, and it is actually a serious reason to consider.
         | Having spent much time on it as well as on J, I hope not being
         | part of those "only people who never used it or used it
         | briefly" because I would also add another reason, more
         | important to me.
         | 
         | APL emphasizes some "formal external beauty" (of code) over the
         | true beauty of an algorithm. Of course you can do such or such
         | thing in 21/2 characters of APL code rather than 60 boring
         | lines of whatever language you want but it is generally full of
         | unneeded hidden loops (or looping uselessly on whole parts of
         | arrays when only a small part is required). Actual complexity
         | of these "elegant" APL solutions is generaly insane.
         | 
         | On the other hand, the J language has a set of some "optimized"
         | idioms -if I remember correctly. Not sure the thing is really
         | better: "write it that way by pretending you are following the
         | array-way-of-life; of course it would be insane to actually do
         | it that way, but my engine will detect the very specific thing
         | you want to do and will use a state-of-the-art algorithm for
         | that purpose". Not sure it is a good thing because the task
         | becomes over complicated: knowing the true (boring) algorithm,
         | knowing the specific array-syntax encoding that algorithm,
         | which falls back to looking in some "list" of what is optimized
         | or not.
         | 
         | While I agree these languages are fascinating to think about
         | computing, learn new things, etc. I finally went to more or
         | less agree with Dijkstra (not the worst reference?) about these
         | languages being "a mistake, carried through to perfection".
         | 
         | What is wrong about writing well commented, well indented, 30
         | lines of code if I can implement the exact algorithm that way?
        
           | tluyben2 wrote:
           | > What is wrong about writing well commented, well indented,
           | 30 lines of code if I can implement the exact algorithm that
           | way?
           | 
           | Nothing, it's just interesting and I wish I could do a larger
           | project with one of them outside just playing around.
        
         | mncharity wrote:
         | > All you need is the cheatsheet [...] and the program
         | 
         | Or an interactive cheatsheet website[1], where you can paste
         | APL code, and mousing over symbols gives their definitions?
         | 
         | [1] http://I-wish-this-existed-but ...
        
           | yiyus wrote:
           | https://tryapl.org/
        
         | WalterBright wrote:
         | Ironically, APL has won as a programming language. Look at the
         | SIMD instruction set - it's APL!
        
           | trenchgun wrote:
           | Can you elaborate on that?
        
             | WalterBright wrote:
             | They're both array operations, even comparisons. No
             | branching.
        
         | MrBuddyCasino wrote:
         | Lots of programming isn't math or logic, its shovelling data
         | and manipulating strings. Is APL good at that?
        
           | [deleted]
        
           | [deleted]
        
           | geocar wrote:
           | If a string (or a file or whatever) is "just" an array (of
           | bytes; characters, again: whatever), then yes.
        
             | MrBuddyCasino wrote:
             | If that means "you don't get much more than what C offers",
             | then I'll take that as a no. I18N, Unicode, Regex, built-in
             | string manipulation functions, character set conversions
             | and efficient data structures are table stakes at this
             | point.
        
               | rscho wrote:
               | APL is very decent at string manipulation. I could try to
               | explain why, but I am afraid that you'll have to see for
               | yourself to understand why what you wrote is both true
               | and not very applicable to APL.
        
         | robomartin wrote:
         | > This also because most people dismiss it as line noise /
         | write only programming language
         | 
         | Not so. Anyone who says these things simply does not know APL.
         | It's like saying musical notation is write-only. Sure, if you
         | don't know it reading the darn thing is excruciating. Yet, if
         | you do, you can see music on the page.
         | 
         | What APL is not is a low-skill, low-knowledge language. A
         | casual glance at the language isn't enough to know it. Just as
         | you can't internalize musical notation without dedication, work
         | and experience.
         | 
         | Back in the '80's I used APL professionally for about a decade.
         | From that context, it reads like music. To this day I can read
         | it just fine (though not as quickly). Interestingly enough the
         | same is the case musical notation, which I could read without
         | thinking twenty years ago, when I was studying and playing
         | classical guitar and piano with great regularity.
         | 
         | That said, I would not recommend anyone get serious about APL
         | today. Study with some degree of dedication? Yes, I think that
         | would be of value. Real projects? No. Definitely not.
        
       | pxeger1 wrote:
       | The a programming language programming language
        
         | bmacho wrote:
         | T a programming language PLSC
        
       | skruger wrote:
       | If you're interested in learning modern APL, check out
       | https://xpqz.github.io/learnapl
       | 
       | Disclaimer: author
        
       | WalterBright wrote:
       | > Expressions in APL are evaluated right-to-left
       | 
       | I find it more natural to evaluate left-to-right, because that's
       | the order we read things in. For example, to read a file and sort
       | its lines (in D):                   auto sortedLines =
       | File("file.txt").byLineCopy.array.sort;
        
         | recuter wrote:
         | I think it would be roughly like this:                 | nget
         | "file.txt"
         | 
         | Anyway I wouldn't want to munge strings in it, but that is not
         | really its niche. Right-to-left can be nicer in different
         | contexts, one is not really better or worse than the other.
        
         | wewtyflakes wrote:
         | Isn't the assignment operator evaluated last, though? I don't
         | know of any language that would support "true" left to right
         | evaluation, though it would be neat! I suppose it would look
         | like:
         | 
         | File("file.txt").byLineCopy.array.sort = sortedLines;
         | 
         | ...which by first blush, seems bananas, but if you were to read
         | it as English, would make sense: "Load the file 'file.txt' into
         | an array of lines, sort them, then assign it to sortedLines"
        
           | renox wrote:
           | It's the symmetry of the '=' symbol which creates the
           | difficulty. Replace it by an arrow in the direction of the
           | assignment and it doesn't look strange anymore.
           | File("file.txt").byLineCopy.array.sort -> sortedLines;
           | 
           | Especially if you add the |> operator (from Erlang I believe)
           | to 'pipe' the data.
           | 
           | File("file.txt") |> readlines |> sort -> sortedLines;
        
           | WalterBright wrote:
           | > Isn't the assignment operator evaluated last, though?
           | 
           | Yes. Though one could use the . operator and a sink to make
           | it completely left-to-right.
        
       | curiousgal wrote:
       | Mandatory APL demonstration from 1975
       | 
       | https://youtu.be/_DTpQ4Kk2wA
        
       ___________________________________________________________________
       (page generated 2022-12-20 23:01 UTC)