3 ms·

Does anyone here program APL? I've tried to look into it occasionally because the idea of powerful, concise syntax appeals to me, but the unfamiliar syntax was

Does anyone here program APL? I've tried to look into it occasionally because the idea of powerful, concise syntax appeals to me, but the unfamiliar syntax was always too much to get my head around within a reasonable amount of time. I'm curious to know whether it really does become second nature after a while, in the same way that some of us might read a printf format string or regular expression quite fluently after many years of working with them.

RodgerTheGreat 10y ago
I program in K, a close relative, and I have done some tinkering with APL. The symbols actually don't take long to memorize- perhaps a few days of practice. It's a bit like learning to read prose. At first you have to sound out words letter by letter, but eventually you're able to "see" words and phrases built out of common patterns of symbols. I see ,/f' and think flatmap, ~~': and think heads of uniform runs, {x@<x} and think sort up, etc. A dense expression can still take a while to puzzle out sometimes, but certainly no longer than the equivalent logic spelled out in a more verbose language across many lines.
- willhslade 10y ago
  What's it like looking for a K job?
  - RodgerTheGreat 10y ago
    In my experience, if you do enough open source stuff with K, jobs find you.
- 35bge57dtjku 10y ago
  I've looked at some of the ascii APL relatives, and my impression was that they are probably great for working with numbers, but seem like they'd be bad for working with text and other things. Am I missing something here?
  - RodgerTheGreat 10y ago
    K relaxes the traditional APL constraints on "rectangular data", which makes it comparatively quite good at dealing with text manipulation. I frequently use K for working with text and it works nicely. Anything you can represent as a list structure can have all the traditional APL-ish tools brought to bear on it. As for "other things", here are a few K sketches I've written recently: - generate random island shorelines: http://johnearnest.github.io/ok/ike/ike.html?gist=629a86c2577401b385abb3a72beb108c http://johnearnest.github.io/ok/ike/ike.html?gist=629a86c257... - animated holiday card: http://johnearnest.github.io/ok/ike/ike.html?gist=e5fdbb8724a0d3a4c69dd08d335a6feb http://johnearnest.github.io/ok/ike/ike.html?gist=e5fdbb8724... - an implementation of the arcade game "Snake": http://johnearnest.github.io/ok/ike/ike.html?gist=ead275c52940fd601763df2dbf6c01cf http://johnearnest.github.io/ok/ike/ike.html?gist=ead275c529... And that's just me! There are many interesting examples and essays here: http://www.nsl.com http://www.nsl.com
kbob 10y ago
I programmed in APL circa 1980-83. It's not a normal programming language in that you don't use it to solve the same kinds of problems as you'd solve in Pascal or Fortran (then) or Python or C (now). Lisp and Smalltalk are a little like that. If you pick a problem they're good at, they're very good indeed, but if you're writing something they don't do, they're just Pascal/Python with funny syntax and nonstandard libraries. APL really encourages code golfing. It's barely readable in the best of circumstances, so there's a lot of temptation to compress code. Er, it's readable, but it's like reading a regular expression. You read it character by character, not line by line. The other thing APL encourages is writing dimensionality independent code. Just as a good C programmer will write a function to concatenate two strings that works independent of the strings' sizes, a good APL programmer will write a function to accept arrays of arbitrary dimensionality where that can make sense. That's because it was not uncommon to have intermediate results of 3, 4 or 5 dimensions. Also, most of the built-in operators do something useful with higher-dimensioned inputs. So yes, it becomes second nature, more or less. But at the same time, it restricts the kinds of problems you think about solving with it. Today I would not recommend APL for any purpose except studying its place in computing history.
- arcfide 10y ago
  Respectfully, the APL of today is not the APL of the 80's. APL is tremendously well suited to many of the problems that face other programming languages, such as the parallel programming usability problem. Modern dfns based APL has incorporated lessons learned from languages liked Scheme (Lisp) to make function syntax and control flow more functional. And APL has been and continues to be used to solve problems from web programming to graph processing and everything in between. While it finds immediately obvious advantage in numerically dense calculation heavy code, my research is specifically interested in demonstrating and scaling APL beyond the "status quo" of what people think APL is good for. The Co-dfns compiler mentioned in these threads is precisely such a counterpoint, demonstrating how to leverage APL in a domain space traditionally dominated by OOP and Lisp style languages, and more recently by certainly highly typed languages such as Agda or maybe Haskell. The difference is that good APL is often more or less "parallel ready" out of the box. Good code in other languages is often anything but. I am working through making the case that "parallel first" languages such as APL are actually pedagogically and programmatically better than "serial first" languages. To this end I have conducted at least one exploratory pilot study on the matter: http://video.dyalog.com/Dyalog13/?v=kIItfQJEVdM http://video.dyalog.com/Dyalog13/?v=kIItfQJEVdM

RodgerTheGreat 10y ago

I program in K, a close relative, and I have done some tinkering with APL. The symbols actually don't take long to memorize- perhaps a few days of practice. It's a bit like learning to read prose. At first you have to sound out words letter by letter, but eventually you're able to "see" words and phrases built out of common patterns of symbols. I see ,/f' and think flatmap, ~~': and think heads of uniform runs, {x@<x} and think sort up, etc. A dense expression can still take a while to puzzle out sometimes, but certainly no longer than the equivalent logic spelled out in a more verbose language across many lines.

willhslade 10y ago
What's it like looking for a K job?
- RodgerTheGreat 10y ago
  In my experience, if you do enough open source stuff with K, jobs find you.
35bge57dtjku 10y ago
I've looked at some of the ascii APL relatives, and my impression was that they are probably great for working with numbers, but seem like they'd be bad for working with text and other things. Am I missing something here?
- RodgerTheGreat 10y ago
  K relaxes the traditional APL constraints on "rectangular data", which makes it comparatively quite good at dealing with text manipulation. I frequently use K for working with text and it works nicely. Anything you can represent as a list structure can have all the traditional APL-ish tools brought to bear on it. As for "other things", here are a few K sketches I've written recently: - generate random island shorelines: http://johnearnest.github.io/ok/ike/ike.html?gist=629a86c2577401b385abb3a72beb108c http://johnearnest.github.io/ok/ike/ike.html?gist=629a86c257... - animated holiday card: http://johnearnest.github.io/ok/ike/ike.html?gist=e5fdbb8724a0d3a4c69dd08d335a6feb http://johnearnest.github.io/ok/ike/ike.html?gist=e5fdbb8724... - an implementation of the arcade game "Snake": http://johnearnest.github.io/ok/ike/ike.html?gist=ead275c52940fd601763df2dbf6c01cf http://johnearnest.github.io/ok/ike/ike.html?gist=ead275c529... And that's just me! There are many interesting examples and essays here: http://www.nsl.com http://www.nsl.com

kbob 10y ago

I programmed in APL circa 1980-83. It's not a normal programming language in that you don't use it to solve the same kinds of problems as you'd solve in Pascal or Fortran (then) or Python or C (now). Lisp and Smalltalk are a little like that. If you pick a problem they're good at, they're very good indeed, but if you're writing something they don't do, they're just Pascal/Python with funny syntax and nonstandard libraries. APL really encourages code golfing. It's barely readable in the best of circumstances, so there's a lot of temptation to compress code. Er, it's readable, but it's like reading a regular expression. You read it character by character, not line by line. The other thing APL encourages is writing dimensionality independent code. Just as a good C programmer will write a function to concatenate two strings that works independent of the strings' sizes, a good APL programmer will write a function to accept arrays of arbitrary dimensionality where that can make sense. That's because it was not uncommon to have intermediate results of 3, 4 or 5 dimensions. Also, most of the built-in operators do something useful with higher-dimensioned inputs. So yes, it becomes second nature, more or less. But at the same time, it restricts the kinds of problems you think about solving with it. Today I would not recommend APL for any purpose except studying its place in computing history.

arcfide 10y ago
Respectfully, the APL of today is not the APL of the 80's. APL is tremendously well suited to many of the problems that face other programming languages, such as the parallel programming usability problem. Modern dfns based APL has incorporated lessons learned from languages liked Scheme (Lisp) to make function syntax and control flow more functional. And APL has been and continues to be used to solve problems from web programming to graph processing and everything in between. While it finds immediately obvious advantage in numerically dense calculation heavy code, my research is specifically interested in demonstrating and scaling APL beyond the "status quo" of what people think APL is good for. The Co-dfns compiler mentioned in these threads is precisely such a counterpoint, demonstrating how to leverage APL in a domain space traditionally dominated by OOP and Lisp style languages, and more recently by certainly highly typed languages such as Agda or maybe Haskell. The difference is that good APL is often more or less "parallel ready" out of the box. Good code in other languages is often anything but. I am working through making the case that "parallel first" languages such as APL are actually pedagogically and programmatically better than "serial first" languages. To this end I have conducted at least one exploratory pilot study on the matter: http://video.dyalog.com/Dyalog13/?v=kIItfQJEVdM http://video.dyalog.com/Dyalog13/?v=kIItfQJEVdM