APL is fundamentally cool and I'd like to think it will make a comeback. But it seems that most modern APL-derived languages focus on trying to squeeze everything into ASCII as concisely as possible.
The following is an example of quite readable ELI with only a handful of symbols:
c,[1.5]32+1.8*c<-$_10+5**!10
It's not bad, but when all you have is ASCII, dense notation will inevitably look like line noise.
APL's graphical notation was one of its original inventions, but custom keyboards weren't a viable solution in the PC era... But today the situation is different again. High-DPI displays and touch screens are becoming standard.
Would it be possible to reinvent APL notation to take advantage of high-res graphics and natural input methods? I'd love to see a tablet-only reinvention of APL that doesn't have a keyboard at all, just a number pad and painted gestures.
Not all APL-like languages do the conciseness thing. Numpy doesn't. Recently a colleague had some imperative code for computing a specific random variable (average revenue given a certain product selection process). Roughly speaking, the for-loop you expect. In code review I changed it to:
Net result - this draws NUM_SAMPLES dirichlet vectors, dots them with the rev_by_category vector, and generates a list of NUM_SAMPLES of the corresponding random variable.
From what I understand, this is definitely idiomatic J translated to Python. In general, idiomatic numpy code will always be array oriented since that's (until recently) the only way to shell out to C.
So from what I can tell, APL isn't dead. It's just spelled out in easy to read executable pseudocode.
Honestly, we need a programming language, any language, that is genuinely designed around the limitations of touch input while sticking to a textual style. I can find lots of interpreters for various languages on my phone, but all rely on stock text editing controls to make me peck away at whatever I want to write - even the MIPS assembler I downloaded made you edit a text file. If we just embraced denser notational style, we could do a lot better without being particularly more elaborate in how the code is displayed or parsed.
I dream of a programming language that would bring coding closer to Japanese brush painting. APL's terseness would make it a suitable foundation for that.
Imagine you're handed a tablet that shows such a program. At first glance it's a unique calligraphic image, but when you know the language you can also parse the data flow and manipulated types intuitively upon seeing the shapes. And since it's a dynamic digital document, you could zoom in, isolate parts, or even run "live coding" style experiments to see what the painting actually does.
Most text editors operate text substitutions (like "<-" turning to "←" automatically), so ASCII doesn't seem inevitable anymore (and I believe it's even truthier with virtual keyboards).
I worked in a company where APL used to be very strong (large french truck manufacturer) and they even had lots of programs written in Scheme for assembly-line optimisations in the late 90s. Most of those have been rewritten (should I say... painfully rewritten, and now buggy) in Java in 2005.
I feel like APL/CLisps/etc. were the right solutions but developers/managers were/are scared when they saw some of the mathematical/proof concepts they had to use, and were afraid of when they learned about them at the university.
We had an APL implementation and it was replaced 5 or so years ago.
It wasn't because of scared management. It was because they were paying for language knowledge not business knowledge. What replaced it, mostly C++ and Python, had better tooling and a wider pool of subject expertise to draw from.
Honest question: if I know J, what can I get from learning APL? When first looking at array based languages the symbols used by APL scared me off and I decided to go with J, now I wonder if the very same symbol set wouldn't be better than pure-ascii.
I did otherwise when interested in the APL/J/K world: the ASCII use of J scared me and I decided to learn some APL first and then, go through J's ASCIIness (I'm still early in the APL part, though.) I find APLs symbols nice and terse, for some of the basic things it's like learning a good editor's shortcuts (be it emacs or vi[m].) You no longer think about how to do X, but what you want to achieve and your hands do it. Of course, I guess with J it's exactly the same once you know enough of it, I just took the other route.
We have some pretty significant matrix processor apps made with APL at the company.
I'd really like to bring this functionality to our web apps, but it seems HTTP interface and external APIs are not available in these implementations. How can you use ELi, or any APL, with a web app?
ELI site is down at the moment, but I read couple of their docs through google cache. There is support of compiling into C, but what about support for C interface? Or HTTP out of the box?
There are lot of recommended books about a selection of languages regarded as more powerful/expressive/safer than the mainstream, but there's not so much good information about APL, I don't think. Every now and then, I hear different people give a hint about APL's power (not too noisily though... as if they did not want to completely give away the secret :).
I keep wondering what problems are good fit for it. From far it doesn't look like a general purpose PL. To my untrained eyes it looks like some sort of query language that you can somehow bend into doing other things (in the same vein you can use SQL to render the Mandelbrot set [1] :).
And then there's the whole clones/successors/spin offs situation. If I were to learn APL today, I wouldn't even know were to start. ELI looks like a good candidate.
There's GNU APL as a free APL implementation. As for learning APL... It's essentially learning what all its symbols do (there are some references for free online from the vendors of paid APLs, just avoid reading about their extensions,) even Wikipedia's page about APL works as a fast reference. I just use it to play around with numbers (yes, I also wrote a Mandelbrot set with it, a one liner that fits in a tweet,) and I'm trying to enhance a little its usability with a iPython-like in-browser "REPL" specially suited for my uses.
J is another APL variant using ASCII instead of special symbols. You can easily label or rename any function to make it more readable, but it goes against the idea of learning the symbols for conciseness ala mathematical symbols.
There is a recent blog entry about using J for spectral clustering in quantitative neuroscience [1]
I am now very comfortable with J, and I am checking out ELI for comparison. I like the idea of the compiler, however, in J the math routines are very fast, well-crafted c libraries, so the interpreter is very fast with results.
Check out Q from Kx Systems. It uses an SQL-like dialect but is still powerful and expressive. Here are some simple example programs: http://code.kx.com/wiki/Sample_Queries
Readit News
The following is an example of quite readable ELI with only a handful of symbols:
It's not bad, but when all you have is ASCII, dense notation will inevitably look like line noise.APL's graphical notation was one of its original inventions, but custom keyboards weren't a viable solution in the PC era... But today the situation is different again. High-DPI displays and touch screens are becoming standard.
Would it be possible to reinvent APL notation to take advantage of high-res graphics and natural input methods? I'd love to see a tablet-only reinvention of APL that doesn't have a keyboard at all, just a number pad and painted gestures.
Or:
From what I understand, this is definitely idiomatic J translated to Python. In general, idiomatic numpy code will always be array oriented since that's (until recently) the only way to shell out to C.So from what I can tell, APL isn't dead. It's just spelled out in easy to read executable pseudocode.
Imagine you're handed a tablet that shows such a program. At first glance it's a unique calligraphic image, but when you know the language you can also parse the data flow and manipulated types intuitively upon seeing the shapes. And since it's a dynamic digital document, you could zoom in, isolate parts, or even run "live coding" style experiments to see what the painting actually does.
Most text editors operate text substitutions (like "<-" turning to "←" automatically), so ASCII doesn't seem inevitable anymore (and I believe it's even truthier with virtual keyboards).
I worked in a company where APL used to be very strong (large french truck manufacturer) and they even had lots of programs written in Scheme for assembly-line optimisations in the late 90s. Most of those have been rewritten (should I say... painfully rewritten, and now buggy) in Java in 2005.
I feel like APL/CLisps/etc. were the right solutions but developers/managers were/are scared when they saw some of the mathematical/proof concepts they had to use, and were afraid of when they learned about them at the university.
It wasn't because of scared management. It was because they were paying for language knowledge not business knowledge. What replaced it, mostly C++ and Python, had better tooling and a wider pool of subject expertise to draw from.
I'd really like to bring this functionality to our web apps, but it seems HTTP interface and external APIs are not available in these implementations. How can you use ELi, or any APL, with a web app?
ELI site is down at the moment, but I read couple of their docs through google cache. There is support of compiling into C, but what about support for C interface? Or HTTP out of the box?
Hanfeng Chen
There are lot of recommended books about a selection of languages regarded as more powerful/expressive/safer than the mainstream, but there's not so much good information about APL, I don't think. Every now and then, I hear different people give a hint about APL's power (not too noisily though... as if they did not want to completely give away the secret :).
I keep wondering what problems are good fit for it. From far it doesn't look like a general purpose PL. To my untrained eyes it looks like some sort of query language that you can somehow bend into doing other things (in the same vein you can use SQL to render the Mandelbrot set [1] :).
And then there's the whole clones/successors/spin offs situation. If I were to learn APL today, I wouldn't even know were to start. ELI looks like a good candidate.
--
1: http://wiki.postgresql.org/wiki/Mandelbrot_set
Deleted Comment
I am now very comfortable with J, and I am checking out ELI for comparison. I like the idea of the compiler, however, in J the math routines are very fast, well-crafted c libraries, so the interpreter is very fast with results.
[1] http://procyonic.org/blog/?p=98
I hope to draw some idead from it (I'm triying to build a relational language)
Deleted Comment