Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into APL

curtisautery.appspot.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: A deep dive into APL

#31

Post by nickpeterson »

michaelfeathers wrote: post #23
rebootthesystem wrote: post #12

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…

> 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…

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?

Re: A deep dive into APL

#32

Post by lokedhs »

adrianratnapala wrote: post #22
lokedhs wrote: post #7

Earlier quoted context omitted.

I tend to think about APL as an alternative to R. When working with array-based datasets it's a very nice tool to use. APL has a small number of very flexible operations, and the key to using APL efficiently lies in understanding these primitives to achieve your goal. Once you learn them, it's more comfortable to use than learning all the intricacies of the R language. I wouldn't recommend anyone writing a full appli…

Hmm, I don't know APL or R, but I suspect I could have substituted "Numerical Python" for "MATLAB" for "R" in your post and have left the meaning almost unchanged. Is my suspicion correct? BTW: A mere 20 lines for format conversion is very good. Although by APL standards, it might be terrible.

Very likely. I used R as an example since it conceptually is very similar to R in the way it treats arrays, and also since it's not something you'd use to build full applications.

Re: A deep dive into APL

#33

Post by alfalfasprout »

evincarofautumn wrote: post #5
ColanR wrote: post #4

Is APL still used for anything now? It seems like it could be a useful language for _something_.

I dunno how widely used it is, but there is Kdb+[1], “a column-based relational time-series database” built on the K[2] language, a descendant of APL. I mainly see J[3] used for code golf, but at least that means a decent number of people know it. [1]: https://en.wikipedia.org/wiki/Kdb%2B [2]: https://en.wikipedia.org/wiki/K_(programming_language) [3]: https://en.wikipedia.org/wiki/J_(programming_language)

Kdb+ is incredible. It blows away any of the current attempts at time series data stores out there (eg; InfluxDB, OpenTSDB). Unfortunately, Kx Systems failed to allow it to reach mass popularity by keeping licenses extremely expensive. Startups simply can't afford to outlay $100k+/year for a tiny cluster.

Re: A deep dive into APL

#34

Post by avmich »

alfalfasprout wrote: post #33
evincarofautumn wrote: post #5

Earlier quoted context omitted.

I dunno how widely used it is, but there is Kdb+[1], “a column-based relational time-series database” built on the K[2] language, a descendant of APL. I mainly see J[3] used for code golf, but at least that means a decent number of people know it. [1]: https://en.wikipedia.org/wiki/Kdb%2B [2]: https://en.wikipedia.org/wiki/K_(programming_language) [3]: https://en.wikipedia.org/wiki/J_(programming_language)

Kdb+ is incredible. It blows away any of the current attempts at time series data stores out there (eg; InfluxDB, OpenTSDB). Unfortunately, Kx Systems failed to allow it to reach mass popularity by keeping licenses extremely expensive. Startups simply can't afford to outlay $100k+/year for a tiny cluster.

I wonder if anybody compared Kdb+ with Jdb, a J DB system.

Re: A deep dive into APL

#35

Post by mmcclellan »

I really liked the way that Iverson built up concepts in his [Arithmetic (PDF)](http://www.jsoftware.com/books/pdf/arithmetic.pdf) manual for J. I found it very intuitive and useful even if you never plan to use the language. There are others at the site like his manual for Exploring Math and one for Calculus as well.

Re: A deep dive into APL

#37

Post by jtraffic »

leoc wrote: post #20

I'm just going to leave this here: http://www.ccs.neu.edu/home/shivers/papers/rank-polymorphism...

"APL, and its successor J [...] provide a notational interface to an interesting model of computation: loop-free, recursion-free array processing." How is APL loop-free, exactly?

Later they say: "Under this implicit lifting, the iteration space is the argument frame rather than a sequence of loop indices." So if I understand correctly, we have iteration, but no loop. But that doesn't seem like a really important distinction...what am I missing?

Re: A deep dive into APL

#38

Post by michaelfeathers »

nickpeterson wrote: post #31
michaelfeathers wrote: post #23

Earlier quoted context omitted.

> 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…

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…

Nick, I think that the primary win is referential transparency. APL idioms raise the level on that base. The tradeoff, though, is the same as we have for functional but further along the road: if you develop a codebase that doesn't use common idioms it's harder to hire people to work in it.

I think array languages, or at least their operation set and idioms, will move into the mainstream in the same way that functional is, but it will take time. Sustainability for your business would be more an issue of hiring and retaining talent.

Reach out if you want to talk about this more: @mfeathers

Re: A deep dive into APL

#40

Post by RodgerTheGreat »

jtraffic wrote: post #37
leoc wrote: post #20

I'm just going to leave this here: http://www.ccs.neu.edu/home/shivers/papers/rank-polymorphism...

"APL, and its successor J [...] provide a notational interface to an interesting model of computation: loop-free, recursion-free array processing." How is APL loop-free, exactly? Later they say: "Under this implicit lifting, the iteration space is the argument frame rather than a sequence of loop indices." So if I understand correctly, we have iteration, but no loop. But that doesn't seem like a really important dist…

The key feature is abstract iteration, like functional maps, filters and folds, and implicit iteration, where operations "penetrate" to the items of a vector or matrix automatically, rather than explicit iteration like a "for" loop.

Abstract iteration is useful because it results in programs with fewer "moving parts"- no loop induction variables to misplace or mutate in the middle of a loop body. Programs are necessarily expressed in a more rigid manner and some irregular algorithms can be difficult to express.

Summing a vector with an explicit loop in K (very non-idiomatic!):

    r:0;i:0; do[#v;r+:v@i;i+:1]; r
The equivalent using the "over" adverb:

    +/v
Both examples perform the same calculation. The latter is more concise and easier to reason about.
Post reply on HN