Hacker News Reader

Comment by codesections | Hacker News Reader

I investigated APL pretty seriously at the end of 2019, after a very inspiring conversation with Aaron. I discovered that everything in this post is true, and (dyalog) APL is a pretty great language.

However, I also decided that it is still a bit too dead, at least for me. Specifically, it does not work well with other programs, at least on *nix. This is reflected not only in the lack of external libraries, but even in some basic areas – both FFI and even reading/writing to standard input and output are surprisingly challenging. Summing all this up, writing a basic Linux CLI app (read from stdin, take and parse arguments, print to stdout) is still a pretty large challenge.

As great as APL is, for me, it's hard to overcome the ability to work with the whole existing Linux/FOSS ecosystem. (I might feel differently if I did any Windows development, which does feel like much more of a first-class citizen for Dyalog APL)

View on HN

gnu apl is an often overlooked but extremely solid APL implementation that plays nice w/ unix.

slightly verbose example but heres gnu apl as a pipe-like interface. Often this would be abstracted to a library that gets included when you call it:

  printf "1,2,3,4\n5,6,7,8" | apl --eval "f←{4⎕CR ⍵}◊s←{⍺~⍨¨⍵⊂⍨1++\⍺⋸⍵}◊f ⊃{⍎⎕UCS ⍵}¨¨44 s¨10 s⊣⎕FIO[41] 0"
  ┏→━━━━━━┓
  ↓1 2 3 4┃
  ┃5 6 7 8┃
  ┗━━━━━━━┛

DESCRIPTION:

    --eval ≡ evaluate the text

    f ≡ formatting function for printing nested values

    s ≡ partition a line of text and remove the partition character

    ⎕FIO ≡ read stdin as byte stream (see FILE_IO.apl)

    ⎕UCS ≡ convert bytes to characters

    ⍎ ≡ execute an expression (convert characters to numbers)

SUMMARY:

  read stdin as a bytestream

  partition at newlines and commas

  convert to characters

  interpret characters as numbers

  disclose into a rank-2 array

  format to stdout

That is indeed often overlooked, I thought it was not ready for primetime and that somehow stuck in my head all these years. I hear no-one mentioning it either usually when these conversations come up.

GNU APL is pretty slow and makes some controversial design decisions. Fun to play with, though, and remarkably polished.

I'd be very interested in reading more about the differentiating features of GNU APL. There is a great big announcement at the beginning of the GNU APL docs that talks of a decision needing to be made around a gap in the ISO specification. Is that the primary source of controversy or is there more discussion I could read somewhere else?

I've been looking for a good "diff" of the language differences between Dyalog APL and GNU APL, as much as to understand the extent of the progress since 'APL2' (or whatever the ISO standard name is considered equivalent to it) as any for any specific list of what GNU APL can't do relative to it's modern commercial compatriots.

(EDIT: Fixed final sentence to be a complete thought/sentence).

dyalog has a few more operators. for example @ & ⍠. It lets you use statement separators in lambdas. In gnu apl you can simulate that with '⊣'. It allows multiline lambdas. Dyalog uses ⍺⍺ & ⍵⍵ for operators vs ⍶ & ⍹. Dyalog lets you use ∘ as a composition operator. Dyalog generally has better performance, which becomes noticeable with large arrays. It has a lot more libraries available. Gnu APL behaves more like a traditional unix based interpreter. Gnu APL has erlang, python, lua, and C interfaces.

I admit, GNU APL gets sluggish when dealing with values with more than ~100k elements. For most ad-hoc work it is satisfactory and can let you sketch out ideas before attempting to push the performance characteristics.

from article "In some cases, users and developers pair program together, and the source is their common language."

from example: f←{4⎕CR ⍵}◊s←{⍺~⍨¨⍵⊂⍨1++\⍺⋸⍵}◊f ⊃{⍎⎕UCS ⍵}¨¨44 s¨10 s⊣⎕FIO[41] 0

Mmmm... I code in C, Java, PHP, CaML, Prolog... for a long time... so I guess that I'm quite used to programming. But really: I can't make any sense of these hieroglyphs !!!! And NO user I ever worked with would either...

So I guess that I'll need a lot more sugar to taste APL...

its a golfed example to show that its possible to use APL as a cli tool. I would not put any code into production that looks like this. Generally it would go into a library.

APL has an initially steep learning curve, because it is so distinct historically from other languages. But it is a quite simple language once you learn it.

1. Every statement is executed right-to-left. Statements are executed top to bottom (or left to right with ◊ as a separator).

2. The only precedence rule is parentheses

3. Functions can be called with one operand (monadic) or two (dyadic)

4. Values in APL have a shape (dimensional size), a rank (number of dimensions), and a ravel (a list of elements). Values can contain other values (nesting)

  {} define lambdas
  ⍺ is the left operand
  ⍵ is the right operand
  ⍶/⍹ are the left/right operators (higher-order functions)
  ← assignment
  ◊ statement separators
  ¨/\⌿⍀⍣⍤⍨ builtin higher order functions

After some familiarity it becomes as easy (or easier) to read as any other language. You can encode a remarkable conciseness of expression into each lambda, that you plumb together (similar to unix pipes in a way) in higher order patterns.

Do you also expect to know Russian after learning German and Chinese?

Thank you for taking the time to break this down!

Your description and summary blocks have started me wondering... has there been much work done on converting APL statements to more verbose explanations?

The sigil-to-meaning mapping is likely automatic for seasoned APL programmers but it might make such one liners more effective for evangelist purposes by making them somewhat more self-documenting.

it indeed becomes much easier to understand after ~ a year. this thread included some discussion about making APL-family languages easier to read for novices: https://news.ycombinator.com/item?id=20728715

I'm of the opinion that code should be documented. Short description, arguments, return, purpose etc. However rebinding primitives kindve defeats the purpose after a little familiarity. For example:

commute ← {⍵ ⍶ ⍺} ⍝ or commute ← { ⍺ ⍶⍨ ⍵ }

will get tedious quickly. Its better to lean into the terseness of the language, rather than attempt to transform it into something it isn't. There has been work done for easing the learning curve, for example https://aplcart.info/ . Keep in mind aplcart generally targets dyalog, however many of the idioms should work for alternate implementations with possibly some tweaking.

Indeed, I was playing with Dyalog some months ago, and the most painful point was I/O. I have implemented the MAL (make a lisp) interpreter in APL but I cannot seem to make the tests for the self hosting interpreter run correctly because of the way standard error and standard output are treated :-/

According the recent 18.0 release presentation, it sounds like they are aware of how different an experience this is relative to other interpreted "scripting" languages. To that end, they have added support for a Run function that will execute with access to to the invocation arguments.

EDIT: They also discuss how the upcoming convergence of .Net Framework and .Net Core is going to have a major impact on their cross-platform capabilities.

That is great to hear; perhaps some of the issues I have will be addressed when version 18.0 is released (which, despite the present tense in your comment, hasn't happened yet). I really hope so – as I said, there's a lot to like in APL.

Although Dyalog APL is a fantastic APL, if you want to do Unix scripting you should know about GNU APL.

The scripting ability is quite good IMHO.

Summing all this up, writing a basic Linux CLI app (read from stdin, take and parse arguments, print to stdout) is still a pretty large challenge.

I suspect that's because it isn't the primary use-case of APL, much like trying to use MIT Scratch[1] to write one. Sure, they're all Turing-complete, but I/O and other interfacing varies greatly between different environments.

[1] https://en.wikipedia.org/wiki/Scratch_(programming_language)

So after lisp and smalltalk, we can add yet another blissful silo to the list :)

Smalltalk, yeah blissful silo, but I'd argue most lisps are heavy on pragmatism which means streams, I/O, FFI, signals, etc. For example, I believe this forum is running on Arc :)

http://www.arclanguage.org

historically lisp was known to be a silo, maybe nowadays not so much (I'm not up to date to be honest).

Scheme is interesting because you can carry a Lisp around in your brain's pocket, implement it anywhere, and integrate it with anything. Accordingly there are Schemes (like guile and scsh) which work well with Unix, Schemes (like tinyscheme, s7, and guile again) which work well as embedded languages, Schemes (like Kawa) which work well with the JVM, etc.

Common Lisp can do the same, but it's a much bigger language so you see less of this effort and more standalone CL implementations like SBCL.

Reply on news.ycombinator.com