6 ms·

I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have t

I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have to say one of the issues with APL is that it was way ahead of it's time. Because of that it struggled to run on computers of that era. I was introduced to the language in 1982~ish. Like I said, I used it extensively, attended and presented at APL conferences and even have a picture of my younger and dorkier self with Ken Iverson (creator of APL). This struggle to run on hardware that could not handle the huge expansions and contractions of memory utilization inherent in the way APL works multidimensional data sets like putty meant it could not compete where other languages had no issues at all. On PC's you were limited to 640K of RAM. It would be years before you could have enough memory to almost not care about utilization. As the language didn't really catch the attention of the CS masses it failed to evolve as it could have over the years. And this is the reason I would suggest today it is not much more than a curiosity. I'm sure there are some out there using it professionally. If I were to guess i'd say it must be mostly companies with a significant installed based of APL software they don't dare try to rewrite. I firmly believe that the future of computing has to be in an APL-like language. By this I mean that we need to evolve to a notation for computing, rather than text for computing. Iverson himself wrote an excellent paper titled "Notation as a Tool for Thought". The issue is that in order to evolve APL one has to have a deep understanding of APL. And, frankly, there are but a few of us around who have that understanding. Not sure how many of this group would embark on the mission to create a true next-generation APL worthy of it's lineage. I read and I smile every time I see the language come up on HN. I taught my kids some APL and they are always blown away by it. Not sure where to go from here.

n17 10y ago
This is really interesting! What are your thoughts on the J language as an evolution of APL?
- rebootthesystem 10y ago
  J and other variants were bad ideas and continue to be bad ideas. They abandon one of the more powerful aspects of APL: Notation. Here's a paper by Ken Iverson about the power of APL notation: http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd... Why does J exist? Back in the mid 80's (I don't remember exactly) dealing with APL on IBM PC's was not easy. You really had to want to run APL. For example, we had to hack the equivalent of today's graphics card to replace the character ROM with one programmed to display APL characters. The more advanced modification allowed you to throw a mechanical switch and go between APL and non-APL characters. Printing APL characters required using very specific printers and changing the print wheel or ball (IBM printers) with versions having APL characters. Again, you really had to want to run APL to endure this. And, that, of course, affected adoption. You couldn't run APL on any random IBM PC or clone on a desk. So, Iverson, despite identifying notation as one of the more powerful features of APL, ends-up "going commercial" by transliterating APL symbols into combinations of ASCII characters. Now you could run something that behaved like APL on any computer. And, of course, it was a complete abomination. Terrible thing. I think I can say the APL community rejected J almost universally. Doing this was a terrible idea. And a short-sighted one at that. It wasn't long til all computers had the ability to display expanded character sets and eventually full graphical canvases where anything was possible. J was a commercial reaction to a hardware problem that evaporated very quickly. J was not a commercial success for reasons obvious to those of us who used APL professionally every day for years: It was a hot mess and almost diametrically opposed to what made APL so incredible to use in solving problems through computing. I would stay far away from J. As brilliant as Iverson had to be to create APL when he did, J, as far as I am concerned, was an almost unforgivable mistake.
  - muraiki 10y ago
    You mentioned in another comment that if APL is to go anywhere, that it needs to be open sourced. Unfortunately, the cost of Dyalog and the fact that it is closed source are the main reasons why I've ended up using J. I appreciate that Dyalog is free for non-commercial use, but I think that part of what makes a programming language successful is if people can start using it in small ways to make their work better. For instance, at my previous job we started using Go for small things and it eventually took on a larger role once we saw how well it worked out in practice. Had we needed to pay to use Go for those small things, we never would have even tried it in the first place. I realize that the Dyalog company needs to actually make money somehow, but I wonder if they are aware of this problem. I did email Dyalog to see if using Dyalog for my work at a non-profit constituted commercial use, but they said that it did. :( Edit: The reason why I haven't used GNU APL is because it seems like getting it to work under Windows will be difficult, and my work is unfortunately a Windows environment. Maybe I should give it a shot anyway.
    - rebootthesystem 10y ago
      Try NARS2000. It's APL with sensible extensions written by someone who knows APL very well. http://www.nars2000.org/ http://www.nars2000.org/
throwaway7645 10y ago
You ever try the modern Dyalog offering with .NET, SQL, and R interop? Pretty cool stuff although I don't really use the language. There is a guy here writing a compiler for Dyalog APL that runs on a GPU, but is only a few pages of APL. If that isn't the future, I don't know what is.
- FractalNerve 10y ago
  I also think it's the future, the problem is that I don't believe that Dyalog APL is the future, even though it's really nice. It just should be opensource to succeed imho., why still be so greedy and take money for a language. Also the IDE is really weird. I love APL and J, but I think there is a lot of space for improvement. And I want that improvement to happen in the open. They can still charge for Consulting, Hosting whatnot.
  - throwaway7645 10y ago
    I'm curious if it would be so nice as a non-commercial project. I suppose some companies would still pay for support and development.
    - FractalNerve 10y ago
      You mean a funding model similar to FreeBSD, right? With the right partnerships this could indeed work very well. At a time where even Microsoft opensources their compilers, Dyalog keeping theirs from the ~70s closed is mind bending to me. And I agree, I would pay, even if it's not that much. The commercial license comes with a too steep price tag. I'd rather opensource my code or contribute where I can.
- rebootthesystem 10y ago
  No, I haven't sorry. I agree with the other comment in that APL, if it is to go anywhere, needs to be open sourced. I'll go beyond that and say that what we need is a new iteration of APL that addresses all the issues with a language that is now at least 30 years away from its most active and innovative period. That's a tall order. I can see getting into something like that as a retirement project. Way too much other good stuff to do now.
michaelfeathers 10y ago
> Not sure where to go from here. For the past few years I've been telling people about the APL family of languages. The clincher for me was seeing the video of an APL version of Conway's Life mentioned in the submission. The impressive part wasn't its brevity, it was how they approached the problem. In APL you have a 'rotate' operator that shifts data in a particular direction. If you have a vector and you rotate it once, every element moves to the next position and the last element then becomes the first. The nice thing about APL is that most operations work on data regardless of its dimensionality. So, to do Conway's Life, you take your 2D matrix of cells and produce rotations of it in eight directions (N,NE,E,SE,S,SW,W,NW). You then take those rotated versions of the matrix along with the original and conceptually stack them. Then, for each grid point, you sum downward, producing a new matrix that contains the neighborhood count of the original matrix. From that you can create the next Life generation. This sort of problem doesn't come up everyday, but the thing that I think is profound is that the existence of these operations allows us to think about problems in different, possibly simpler ways. They are untapped potential and they could be as well known as map and fold. APL and its derived languages are hard to approach but there isn't much that keeps us from importing the data structures and operations in more approachable languages.
- nickpeterson 10y ago
  Hey Michael, been a fan since reading 'Legacy Code'. Do you believe that refactoring a large APL codebase would be inherently easier than something like, a large legacy C++ codebase? What is the relative complexity of comparing, say 1000 lines of APL to 10K lines of C++? I remember reading an interview between Arthur Whitney and Bryan Cantrill where they mentioned something about recognizing idioms in the dense code much more easily in K than in something like C because it took so many less characters. Do you see any sort of refactoring advantage to that? I've also recently seen work on the Co-dfns compiler in APL where the author mentioned that APL allowed him to easily refactor compared to traditional codebase, and looking at the github library, there is something like 3 million edited lines over the span of several years in a codebase this is a few thousand lines of code. I find this fascinating because my hope is to eventually start a small software business and I think reducing complexity in the number one priority in order to make it sustainable in the small (the goal isn't to have a team of 50 developers). Thoughts?
COMPUTERLOSER 10y ago
Matlab and numpy serve that market today.
pmoriarty 10y ago
Lisp was also far ahead of its time, but many Lisp features like garbage collection and lambdas have made it in to mainstream programming languages. Has anything similar happened with APL?
- baldfat 10y ago
  I just think of Lisp as its own world. They had to build Lisp machines to work on machines in years past. Today we still see growth in Lisp and seeing how Racket is developing and Clojure shows that Lisp has room to continue to innovate.
- muraiki 10y ago
  An article[1] claims Wes McKinney was inspired by APL while working on pandas; some of the pandas verbs such as "ravel" come from APL. Also, the <- instead of = in R comes from APL, although that's relatively minor. :) [1] https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-empires-apl-languages/ https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgo...
- rebootthesystem 10y ago
  Interestingly enough, I was working with APL, Lisp, Forth and C pretty much simultaneously during my ten year or so sting using APL professionally. This was an amazing combination of languages to have in my toolbox simultaneously. The mental calisthenics alone were truly enjoyable to me.
deleted 10y ago
[deleted]

n17 10y ago

This is really interesting! What are your thoughts on the J language as an evolution of APL?

rebootthesystem 10y ago
J and other variants were bad ideas and continue to be bad ideas. They abandon one of the more powerful aspects of APL: Notation. Here's a paper by Ken Iverson about the power of APL notation: http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd... Why does J exist? Back in the mid 80's (I don't remember exactly) dealing with APL on IBM PC's was not easy. You really had to want to run APL. For example, we had to hack the equivalent of today's graphics card to replace the character ROM with one programmed to display APL characters. The more advanced modification allowed you to throw a mechanical switch and go between APL and non-APL characters. Printing APL characters required using very specific printers and changing the print wheel or ball (IBM printers) with versions having APL characters. Again, you really had to want to run APL to endure this. And, that, of course, affected adoption. You couldn't run APL on any random IBM PC or clone on a desk. So, Iverson, despite identifying notation as one of the more powerful features of APL, ends-up "going commercial" by transliterating APL symbols into combinations of ASCII characters. Now you could run something that behaved like APL on any computer. And, of course, it was a complete abomination. Terrible thing. I think I can say the APL community rejected J almost universally. Doing this was a terrible idea. And a short-sighted one at that. It wasn't long til all computers had the ability to display expanded character sets and eventually full graphical canvases where anything was possible. J was a commercial reaction to a hardware problem that evaporated very quickly. J was not a commercial success for reasons obvious to those of us who used APL professionally every day for years: It was a hot mess and almost diametrically opposed to what made APL so incredible to use in solving problems through computing. I would stay far away from J. As brilliant as Iverson had to be to create APL when he did, J, as far as I am concerned, was an almost unforgivable mistake.
- muraiki 10y ago
  You mentioned in another comment that if APL is to go anywhere, that it needs to be open sourced. Unfortunately, the cost of Dyalog and the fact that it is closed source are the main reasons why I've ended up using J. I appreciate that Dyalog is free for non-commercial use, but I think that part of what makes a programming language successful is if people can start using it in small ways to make their work better. For instance, at my previous job we started using Go for small things and it eventually took on a larger role once we saw how well it worked out in practice. Had we needed to pay to use Go for those small things, we never would have even tried it in the first place. I realize that the Dyalog company needs to actually make money somehow, but I wonder if they are aware of this problem. I did email Dyalog to see if using Dyalog for my work at a non-profit constituted commercial use, but they said that it did. :( Edit: The reason why I haven't used GNU APL is because it seems like getting it to work under Windows will be difficult, and my work is unfortunately a Windows environment. Maybe I should give it a shot anyway.
  - rebootthesystem 10y ago
    Try NARS2000. It's APL with sensible extensions written by someone who knows APL very well. http://www.nars2000.org/ http://www.nars2000.org/

throwaway7645 10y ago

You ever try the modern Dyalog offering with .NET, SQL, and R interop? Pretty cool stuff although I don't really use the language. There is a guy here writing a compiler for Dyalog APL that runs on a GPU, but is only a few pages of APL. If that isn't the future, I don't know what is.

FractalNerve 10y ago
I also think it's the future, the problem is that I don't believe that Dyalog APL is the future, even though it's really nice. It just should be opensource to succeed imho., why still be so greedy and take money for a language. Also the IDE is really weird. I love APL and J, but I think there is a lot of space for improvement. And I want that improvement to happen in the open. They can still charge for Consulting, Hosting whatnot.
- throwaway7645 10y ago
  I'm curious if it would be so nice as a non-commercial project. I suppose some companies would still pay for support and development.
  - FractalNerve 10y ago
    You mean a funding model similar to FreeBSD, right? With the right partnerships this could indeed work very well. At a time where even Microsoft opensources their compilers, Dyalog keeping theirs from the ~70s closed is mind bending to me. And I agree, I would pay, even if it's not that much. The commercial license comes with a too steep price tag. I'd rather opensource my code or contribute where I can.
rebootthesystem 10y ago
No, I haven't sorry. I agree with the other comment in that APL, if it is to go anywhere, needs to be open sourced. I'll go beyond that and say that what we need is a new iteration of APL that addresses all the issues with a language that is now at least 30 years away from its most active and innovative period. That's a tall order. I can see getting into something like that as a retirement project. Way too much other good stuff to do now.

michaelfeathers 10y ago

> Not sure where to go from here. For the past few years I've been telling people about the APL family of languages. The clincher for me was seeing the video of an APL version of Conway's Life mentioned in the submission. The impressive part wasn't its brevity, it was how they approached the problem. In APL you have a 'rotate' operator that shifts data in a particular direction. If you have a vector and you rotate it once, every element moves to the next position and the last element then becomes the first. The nice thing about APL is that most operations work on data regardless of its dimensionality. So, to do Conway's Life, you take your 2D matrix of cells and produce rotations of it in eight directions (N,NE,E,SE,S,SW,W,NW). You then take those rotated versions of the matrix along with the original and conceptually stack them. Then, for each grid point, you sum downward, producing a new matrix that contains the neighborhood count of the original matrix. From that you can create the next Life generation. This sort of problem doesn't come up everyday, but the thing that I think is profound is that the existence of these operations allows us to think about problems in different, possibly simpler ways. They are untapped potential and they could be as well known as map and fold. APL and its derived languages are hard to approach but there isn't much that keeps us from importing the data structures and operations in more approachable languages.

nickpeterson 10y ago
Hey Michael, been a fan since reading 'Legacy Code'. Do you believe that refactoring a large APL codebase would be inherently easier than something like, a large legacy C++ codebase? What is the relative complexity of comparing, say 1000 lines of APL to 10K lines of C++? I remember reading an interview between Arthur Whitney and Bryan Cantrill where they mentioned something about recognizing idioms in the dense code much more easily in K than in something like C because it took so many less characters. Do you see any sort of refactoring advantage to that? I've also recently seen work on the Co-dfns compiler in APL where the author mentioned that APL allowed him to easily refactor compared to traditional codebase, and looking at the github library, there is something like 3 million edited lines over the span of several years in a codebase this is a few thousand lines of code. I find this fascinating because my hope is to eventually start a small software business and I think reducing complexity in the number one priority in order to make it sustainable in the small (the goal isn't to have a team of 50 developers). Thoughts?

COMPUTERLOSER 10y ago

Matlab and numpy serve that market today.

pmoriarty 10y ago

Lisp was also far ahead of its time, but many Lisp features like garbage collection and lambdas have made it in to mainstream programming languages. Has anything similar happened with APL?

baldfat 10y ago
I just think of Lisp as its own world. They had to build Lisp machines to work on machines in years past. Today we still see growth in Lisp and seeing how Racket is developing and Clojure shows that Lisp has room to continue to innovate.
muraiki 10y ago
An article[1] claims Wes McKinney was inspired by APL while working on pandas; some of the pandas verbs such as "ravel" come from APL. Also, the <- instead of = in R comes from APL, although that's relatively minor. :) [1] https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-empires-apl-languages/ https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgo...
rebootthesystem 10y ago
Interestingly enough, I was working with APL, Lisp, Forth and C pretty much simultaneously during my ten year or so sting using APL professionally. This was an amazing combination of languages to have in my toolbox simultaneously. The mental calisthenics alone were truly enjoyable to me.

deleted 10y ago

[deleted]