An anecdote about my first and only brush with an APL programmer:
Towards the end of the nineties I was a young computer science student standing on an almost deserted suburban above-ground underground station waiting for the next train into the centre of London.
A very old but brisk and snappy gentleman in traditional gentleman's clothes came onto the platform, and for some reason we nodded genially as you do when you pass strangers on country lanes; in London you ignore absolutely everyone, so it was strange we did this.
And there we stood, waiting for the train. He offered me a peppermint from a small metal tin. Of course my parents taught me to never take sweets from strangers, so I instinctively declined even though I'd now left home and thought of my self as a grown-up.
Anyway, we got talking. At first it was 'what are you studying?' kind of polite interest. He was intrigued that I was a computer science student.
I've gotta underline again how unusual this was, for anyone in London to ever talk to another stranger, but this really happened. I don't think I ever acknowledged there was anyone else in London, ever. It wasn't even normal to know the names of your neighbours.
And so we sat beside each other on an underground train and he told me about his early years as a programmer. Did I know APL, he asked? I had never heard of it! His veiled references suggested he worked with but not for Cheltenham.
And he delighted in telling me programmer war stories from when he did commercial stuff like how a vendor had encrypted their APL programs and he had reverse engineered it and waved the decrypted source-code in front of the firm's rep and complained about shoddy code and bugs! At the time I was tackling Simon Singh's Code Book contest so that kind of story caught my imagination and I begun to wish I'd have that kind of chance in my programming future.
Now, in his old age, he went from his home in the north of England down to London once a week for a charity meeting he chaired. That's the kind of thing respectable old gentleman do to give their life meaning, I guess.
Anyway, afterwards I searched the web for APL (this was before google) and was, of course, gobsmacked.
A few years ago, discovering J and playing a bit with it, I went through phases : "this looks square and clean, a nice exercise in language design" -> "those guys take it way too seriously" -> "people seem to be using it for serious stuff, they are simply insane".
Coming back to it every now and then for kicks slowly showed me a few strengths. First, with the short verb names and clear semantics, J is the only thing I've found that brings, for me, the comfort of a specialised handheld calculator to the PC. That realization, very independently from its array capabilities, is what got me really going with it, on a gentle learning curve. And you get it on your smartphone too ; I eventually sold my good old HP48 friend.
From there I started using it for small things. When I was building a lift for my brother's Warré beehives, J let me scribble a few beam-resistance equations in it and using its solver and plotter to easily get good results. So I started using it for things that were too big for spreadsheets, but that I was too lazy to deal with in a "proper" language.
That needs a change of mind regarding how you write and maintain programs. When I want J to do something in a program, I fiddle with it until I get the "sentence" right, and that's it. That sentence will never be modified again. If I need it to work differenty, I'll rewrite that sentence from scratch. Then find a good name for your sentence so that you can combine it with others, and suddently you discover that you can write J like a nice DSL that can very satisfyingly sound like plain spoken language.
I wouldn't stretch it though. I'm not passionate enough about it to invest what's needed for mastery. 80 lines of thin J is my largest. Beyond that, switch to something that helps with maintainability, but beware of the sudden and amazing code-size inflation !
> When I want J to do something in a program, I fiddle with it until I get the "sentence" right, and that's it. That sentence will never be modified again. If I need it to work differenty, I'll rewrite that sentence from scratch. Then find a good name for your sentence so that you can combine it with others, and suddently you discover that you can write J like a nice DSL that can very satisfyingly sound like plain spoken language.
I had exactly the same experience with Forth. It is very cool when you define a word as an almost English sentence and all the data flow effortlessly through the stack but I have to admit it can take a lot of time to get it right. I got to the conclusion that Forth is a contemplative language where you spend a lot more time thinking than typing.
I once got talking with an anesthesiologist who was taking care of a family member. Upon hearing I was a developer, he told me he was an APL programmer who spent most of his computer time developing Bible software. He regaled me with a few APL war stories, about how he could get so much more done with so much less code...
I was intrigued, and still am. But one thing I didn't catch -- how do you write all those non-ASCII symbols using a standard OS and text editor? Or does it require special tools?
I'm reminded that it's possible to be quietly weird and brilliant, in the world that moves on in ignorance of the latest JavaScript shit, kubernetes shit, database shit, ... Thanks for sharing!
Most of the vendors (Ex: Dyalog) sell keyboards with the markings on them. It isn't necessary though as you'll actually pick them up decently fast. There is so much less typing that you can also just pick them out of the IDE's toolbar kind of like you do on the tryapl.org website.
APL and Prolog/Datalog are local optimums in programming languages. When you enter their domains, you are limping in every other language. It's almost better not to know about them because you can avoid constant "there is a better way" in the back of your head.
I think we should just bite the bullet and make them into standard domain specific languages available in every language and environment.
What domains are they used in? I've learned a little bit of J but got put off because most people involved with J seem more interested in using J for the sake of using it rather than actually doing anything substantive with it. My impression is that APL is similar (at least currently) but I'd love to be wrong.
When I was in engineering school an APL programmer friend came over to where I was working and looked at my MATLAB homework. She eventually stated that MATLAB was a very bad APL. She then proceeded to solve my homework in a single line of MATLAB.
In old computer magazines from the 80's and before, it was a trope to have an article about some technique or algorithm, and then show it implemented in one line of APL.
> She then proceeded to solve my homework in a single line of MATLAB
To be fair, though, was that single line as long as a normal screen of code? I have not decided whether it's a good thing or bad thing, but apl/j/k programmers have some very interesting ideas about how much is acceptable to put on a single line;)
For anyone interested in apl, take a look at k which is essentially apl restricted to the ascii character set.
There's also q (aka kdb) which adds some additional database-like functionality (among other things) however it's proprietary and "free".
I knew the text felt familiar, the same author wrote the above linked book. The intro covers the same material. If you're interested in APL (NB: Not a professional, just liked playing with it), that book was really useful to me last year.
“This example shows clearly that there are ways of reasoning other than those which have dominated information processing for 40 years but they are, alas, still extremely rare. This difference and originality, introduced by APL, are major features. They typify the open and welcoming intellectual spirit of the people who practise it.” — FWIW, this example (+/ Salaries × Rates[Categories]) can be rewritten nearly word for word in R (Sum(Salaries*Rates[Categories])), so at least some of the ideas still have some currency.
This actually looks like Excel / 1-2-3, which is an array-based programming language that people look down on because it enables non-experts to build programs and therefore the programs are bad.
The example you gave was overly simplistic for a comparison. It's like doing one test for a benchmark comparison. Go look at Aaron Hsu's Co-Dfns parallel APL compiler and his discussions on HN and YouTube. I don't think you could easily do an R translation that isn't 10x longer.
I would say that pandas and R can pretty much express everything that APL/J/Q can. They are a lot slower though (than Q atleast, I haven’t used J or APL)
When I was a graduate dev I worked for a company whose primary product was a APL interpreter. So it was an interpreted language, but it may well be possible that it can be compiled or JIT these days. The interpreter was written in 68K assembler and was pretty fast I suppose, but then I'm not aware any benchmarks to compare it with, since APL is not like anything else (except, as someone pointed out, maybe MatLab).
It seems to me APL and family are mostly useful for numerical work on data that is possibly queried (efficiently at that) from a database. A very naïve way would be to say it's a glorified Excel. Is there something I'm missing ? Are there other domains one could use it for ?
Although the "glorified Excel" statement makes me cringe, I would agree that APL's strong point is numerical work on data. I wouldn't use APL to write, for example, an operating system.
When Ken Iverson wrote APL in the sixties, numerical work was one of the big uses of computers (after the typical finance applications such as billing, inventory, accounts payable/receivable, general ledger), and APL filled that niche quite well. When I was working at IBM in the nineties investment banks were still using APL for some of their modeling.
APL also took a different evolutionary path than many of today's languages, operator precedence for example. APL's rule was simple: evaluate left-to-right. I didn't need to remember that exponentiation has a higher precedence than multiplication which in turn has a higher precedence than addition (those were the easy ones to remember; the hard ones were bit operations, logical operations — some languages had both high-precedence logical operations ("&&" and "||") as well as low-precedence ("and" and "or"), which further muddied the waters). I found Reverse Polish Notation (RPN) the most elegant when determining operator precedence, with APL's a close second.
Another difference was the way that the code was maintained. For example, my father, who was also an APL developer, often said, "APL is write-only code". Rarely would one modify someone else's code; instead, you'd re-write the function entirely. Thus the most important aspect of writing APL code was documenting what the function took as input and what it spat out.
But I'm glossing over one of the most important aspects of APL: it made you think about the problem space differently: instead of nested for-loops, you'd think of vectors and matrices. The manner in which you thought about the problem was incredibly succinct, similar to APL's vocabulary.
There was an extremely impressive video a year or two back of someone who had built a compiler in APL. While I don't code in it, it changed my view of APL and its power.
HN was fairly caught up with it for a month or so, and a flood of APL posts.
Historically it was spreadsheets that killed (financier) interest in APL (which was going gangbusters at the time). They were much easier for this crowd. APL does actually work for non numerical stuff. There is the famous example of OS360 being written in a couple pages of APL code. The model was actually used at IBM and at the time was heavily used there. Iverson went on to shepherd J, a much sophisticated language. K, another much modern offshoot, in the mean time has taken over the financial (trader) world.
In terms of semantics, sure. However a real part of the charm of APL (and J, and K) are in the syntax, and how notating your program causes you to think about it differently. Something like or/and outer product in the game-of-life oneliner is very straightforward APL, but is much clunkier to write in numpy.
As someone who actually used APL prifessionally for a decade I am always surprised by how often the language surfaces on HN. I used it in a wide range of domains, from business and engineering applications to DNA sequencing.
The main comment I want to make is that anything that abandons notation is an abomination. The power of APL comes from the use if notation as a tool for thought and the expression if ideas. Notation is crucially important in this regard. Language transliterations like J were huge mistakes in APL’s historical timeline.
Every time APL comes up, I — as a non-APL programmer — am compelled to post this fun video about implementing Conway's Game of Life in APL: https://www.youtube.com/watch?v=a9xAKttWgP4
I still see two things missing from currently available APL dialects: being able to compile programs, and being able to create a control loop (which is required for continuous access to data input).
I wonder how much effort would be required to use, say, GNU APL for compiling the language?
In college I learned APL. Most of my colleagues complained that we were learning it instead of something with more practical use or market value.
APL taught me it was possible (and remarkably easy) to write "write-only" code and how delicate legibility can be. Most of my APL code had 4 lines of comments for each line of code.
>> To get a similar result by means of a traditional computer language requires many instructions, which hides the object of the calculation behind arcane programming. Here, for example, is what one would write in PASCAL
It seems that the article emphasises on how APL can get a lot done with little code. I know of a programming language that can help you do that: Rust.
Rust has two powerful features:
1- Traits: You basically declare a "struct" type that has your data. Implement the Mul/Add Traits to it; and then "boom" you can multiply these seemingly complicated objects with *.
2- Macros: You can abstract repetitive code with macros. For example your code displays a table on the terminal. You have to do that repetitively. You can either create a function to display your data or have a macro do it.
[+] [-] willvarfar|7 years ago|reply
Towards the end of the nineties I was a young computer science student standing on an almost deserted suburban above-ground underground station waiting for the next train into the centre of London.
A very old but brisk and snappy gentleman in traditional gentleman's clothes came onto the platform, and for some reason we nodded genially as you do when you pass strangers on country lanes; in London you ignore absolutely everyone, so it was strange we did this.
And there we stood, waiting for the train. He offered me a peppermint from a small metal tin. Of course my parents taught me to never take sweets from strangers, so I instinctively declined even though I'd now left home and thought of my self as a grown-up.
Anyway, we got talking. At first it was 'what are you studying?' kind of polite interest. He was intrigued that I was a computer science student.
I've gotta underline again how unusual this was, for anyone in London to ever talk to another stranger, but this really happened. I don't think I ever acknowledged there was anyone else in London, ever. It wasn't even normal to know the names of your neighbours.
And so we sat beside each other on an underground train and he told me about his early years as a programmer. Did I know APL, he asked? I had never heard of it! His veiled references suggested he worked with but not for Cheltenham.
And he delighted in telling me programmer war stories from when he did commercial stuff like how a vendor had encrypted their APL programs and he had reverse engineered it and waved the decrypted source-code in front of the firm's rep and complained about shoddy code and bugs! At the time I was tackling Simon Singh's Code Book contest so that kind of story caught my imagination and I begun to wish I'd have that kind of chance in my programming future.
Now, in his old age, he went from his home in the north of England down to London once a week for a charity meeting he chaired. That's the kind of thing respectable old gentleman do to give their life meaning, I guess.
Anyway, afterwards I searched the web for APL (this was before google) and was, of course, gobsmacked.
[+] [-] smcl|7 years ago|reply
[+] [-] excitom|7 years ago|reply
[+] [-] agumonkey|7 years ago|reply
[+] [-] theoh|7 years ago|reply
[+] [-] Karto|7 years ago|reply
Coming back to it every now and then for kicks slowly showed me a few strengths. First, with the short verb names and clear semantics, J is the only thing I've found that brings, for me, the comfort of a specialised handheld calculator to the PC. That realization, very independently from its array capabilities, is what got me really going with it, on a gentle learning curve. And you get it on your smartphone too ; I eventually sold my good old HP48 friend.
From there I started using it for small things. When I was building a lift for my brother's Warré beehives, J let me scribble a few beam-resistance equations in it and using its solver and plotter to easily get good results. So I started using it for things that were too big for spreadsheets, but that I was too lazy to deal with in a "proper" language.
That needs a change of mind regarding how you write and maintain programs. When I want J to do something in a program, I fiddle with it until I get the "sentence" right, and that's it. That sentence will never be modified again. If I need it to work differenty, I'll rewrite that sentence from scratch. Then find a good name for your sentence so that you can combine it with others, and suddently you discover that you can write J like a nice DSL that can very satisfyingly sound like plain spoken language.
I wouldn't stretch it though. I'm not passionate enough about it to invest what's needed for mastery. 80 lines of thin J is my largest. Beyond that, switch to something that helps with maintainability, but beware of the sudden and amazing code-size inflation !
[+] [-] pmarin|7 years ago|reply
I had exactly the same experience with Forth. It is very cool when you define a word as an almost English sentence and all the data flow effortlessly through the stack but I have to admit it can take a lot of time to get it right. I got to the conclusion that Forth is a contemplative language where you spend a lot more time thinking than typing.
[+] [-] TimTheTinker|7 years ago|reply
I was intrigued, and still am. But one thing I didn't catch -- how do you write all those non-ASCII symbols using a standard OS and text editor? Or does it require special tools?
[+] [-] lelf|7 years ago|reply
> how do you write all those non-ASCII symbols using a standard OS and text editor?
Modifier+KEY or PrefixKey KEY
All symbols are in Unicode. No special tools required.
[+] [-] coleifer|7 years ago|reply
[+] [-] mhd|7 years ago|reply
[+] [-] 4thaccount|7 years ago|reply
[+] [-] michaelcampbell|7 years ago|reply
[+] [-] dmos62|7 years ago|reply
[+] [-] patrickg_zill|7 years ago|reply
[+] [-] nabla9|7 years ago|reply
I think we should just bite the bullet and make them into standard domain specific languages available in every language and environment.
[+] [-] jeffreyrogers|7 years ago|reply
[+] [-] upofadown|7 years ago|reply
[+] [-] GlenTheMachine|7 years ago|reply
[+] [-] JoeDaDude|7 years ago|reply
[+] [-] yjftsjthsd-h|7 years ago|reply
To be fair, though, was that single line as long as a normal screen of code? I have not decided whether it's a good thing or bad thing, but apl/j/k programmers have some very interesting ideas about how much is acceptable to put on a single line;)
[+] [-] breenhead|7 years ago|reply
[+] [-] macintux|7 years ago|reply
http://www.jsoftware.com/
[+] [-] stevesimmons|7 years ago|reply
- 64 bit/16 core, sends "I'm alive" packets back to Kdb: https://ondemand.kx.com/
- older 32-bit, standalone, very small executable: https://kx.com/download/
Wkimpedia page has history and links to various docs: https://en.m.wikipedia.org/wiki/K_(programming_language)
[+] [-] curiousgal|7 years ago|reply
[+] [-] Jtsummers|7 years ago|reply
I knew the text felt familiar, the same author wrote the above linked book. The intro covers the same material. If you're interested in APL (NB: Not a professional, just liked playing with it), that book was really useful to me last year.
[+] [-] macleginn|7 years ago|reply
[+] [-] pjc50|7 years ago|reply
This actually looks like Excel / 1-2-3, which is an array-based programming language that people look down on because it enables non-experts to build programs and therefore the programs are bad.
[+] [-] 4thaccount|7 years ago|reply
[+] [-] mruts|7 years ago|reply
[+] [-] michaelbuckbee|7 years ago|reply
[+] [-] 3chelon|7 years ago|reply
[+] [-] rakoo|7 years ago|reply
[+] [-] brian_cunnie|7 years ago|reply
When Ken Iverson wrote APL in the sixties, numerical work was one of the big uses of computers (after the typical finance applications such as billing, inventory, accounts payable/receivable, general ledger), and APL filled that niche quite well. When I was working at IBM in the nineties investment banks were still using APL for some of their modeling.
APL also took a different evolutionary path than many of today's languages, operator precedence for example. APL's rule was simple: evaluate left-to-right. I didn't need to remember that exponentiation has a higher precedence than multiplication which in turn has a higher precedence than addition (those were the easy ones to remember; the hard ones were bit operations, logical operations — some languages had both high-precedence logical operations ("&&" and "||") as well as low-precedence ("and" and "or"), which further muddied the waters). I found Reverse Polish Notation (RPN) the most elegant when determining operator precedence, with APL's a close second.
Another difference was the way that the code was maintained. For example, my father, who was also an APL developer, often said, "APL is write-only code". Rarely would one modify someone else's code; instead, you'd re-write the function entirely. Thus the most important aspect of writing APL code was documenting what the function took as input and what it spat out.
But I'm glossing over one of the most important aspects of APL: it made you think about the problem space differently: instead of nested for-loops, you'd think of vectors and matrices. The manner in which you thought about the problem was incredibly succinct, similar to APL's vocabulary.
[+] [-] BoiledCabbage|7 years ago|reply
HN was fairly caught up with it for a month or so, and a flood of APL posts.
Someone may have a link to it.
[+] [-] emanuensis|7 years ago|reply
[+] [-] paperwork|7 years ago|reply
If Python allowed a reduce operator “/“, numpy will be able to get even closer to APL, correct?
[+] [-] icen|7 years ago|reply
[+] [-] robomartin|7 years ago|reply
The main comment I want to make is that anything that abandons notation is an abomination. The power of APL comes from the use if notation as a tool for thought and the expression if ideas. Notation is crucially important in this regard. Language transliterations like J were huge mistakes in APL’s historical timeline.
[+] [-] benji-york|7 years ago|reply
[+] [-] ColanR|7 years ago|reply
I wonder how much effort would be required to use, say, GNU APL for compiling the language?
[+] [-] dang|7 years ago|reply
[+] [-] rbanffy|7 years ago|reply
APL taught me it was possible (and remarkably easy) to write "write-only" code and how delicate legibility can be. Most of my APL code had 4 lines of comments for each line of code.
[+] [-] csomar|7 years ago|reply
>> To get a similar result by means of a traditional computer language requires many instructions, which hides the object of the calculation behind arcane programming. Here, for example, is what one would write in PASCAL
It seems that the article emphasises on how APL can get a lot done with little code. I know of a programming language that can help you do that: Rust.
Rust has two powerful features:
1- Traits: You basically declare a "struct" type that has your data. Implement the Mul/Add Traits to it; and then "boom" you can multiply these seemingly complicated objects with *.
2- Macros: You can abstract repetitive code with macros. For example your code displays a table on the terminal. You have to do that repetitively. You can either create a function to display your data or have a macro do it.
[+] [-] joelthelion|7 years ago|reply
[+] [-] icen|7 years ago|reply
There are open source implementations of some K versions - Kona, which is K3, and oK, which is ~K5.
J is available under GPL3.
[+] [-] tempodox|7 years ago|reply