5 ms·

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

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)

snapdangle 6y ago
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.
- codesections 6y ago
  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.
lhjn 6y ago
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 :-/
agumonkey 6y ago
So after lisp and smalltalk, we can add yet another blissful silo to the list :)
- imglorp 6y ago
  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 http://www.arclanguage.org
  - agumonkey 6y ago
    historically lisp was known to be a silo, maybe nowadays not so much (I'm not up to date to be honest).
    - bitwize 6y ago
      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.
shrubble 6y ago
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.
gandercrews 6y ago
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
- tluyben2 6y ago
  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.
- kick 6y ago
  GNU APL is pretty slow and makes some controversial design decisions. Fun to play with, though, and remarkably polished.
  - snapdangle 6y ago
    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).
userbinator 6y ago
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) https://en.wikipedia.org/wiki/Scratch_(programming_language)

snapdangle 6y ago

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.

codesections 6y ago
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.

lhjn 6y ago

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 :-/

agumonkey 6y ago

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

imglorp 6y ago
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 http://www.arclanguage.org
- agumonkey 6y ago
  historically lisp was known to be a silo, maybe nowadays not so much (I'm not up to date to be honest).
  - bitwize 6y ago
    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.

shrubble 6y ago

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.

gandercrews 6y ago

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

tluyben2 6y ago
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.
kick 6y ago
GNU APL is pretty slow and makes some controversial design decisions. Fun to play with, though, and remarkably polished.
- snapdangle 6y ago
  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).

userbinator 6y ago

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) https://en.wikipedia.org/wiki/Scratch_(programming_language)