APL's are a special beast. A very interesting article that got me hooked "Ruins of forgotten empires: APL languages"
https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgo...
In Praise of APL: A Language for Lyrical Programming (1977)
31–40 of 60 posts
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#32Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and more attracted by the idea of a language taking 1/10th the typing compared to what's typical today. However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding. Even though the set of short symbols has to be limited, don't we currently have a few dozen often-r…
I personally question the utility of such terseness, and much prefer the verbosity of the Lisp family of languages, where cultural norms make for function names like "number-to-string" and "expand-file-name", rather than the norms I've seen in languages like APL, K, J, Q, OCaml, and Haskell, which seem to love more mathematically-inspired single-letter names like "n" or "k", and various operators in a similar vein. T…
I think you're just bad at reading pointfree notation, tbh, which is not a particularly interesting commentary on OCaml or Haskell.
Lots of things lend themselves well to pointfree style, and if you do not see them it is because of your own horizons.
You can write OCaml/Haskell with names like doesFileExist when you need to.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#33Earlier quoted context omitted.
I personally question the utility of such terseness, and much prefer the verbosity of the Lisp family of languages, where cultural norms make for function names like "number-to-string" and "expand-file-name", rather than the norms I've seen in languages like APL, K, J, Q, OCaml, and Haskell, which seem to love more mathematically-inspired single-letter names like "n" or "k", and various operators in a similar vein. T…
I think you're just bad at reading pointfree notation, tbh, which is not a particularly interesting commentary on OCaml or Haskell. Lots of things lend themselves well to pointfree style, and if you do not see them it is because of your own horizons. You can write OCaml/Haskell with names like doesFileExist when you need to.
"You can write OCaml/Haskell with names like doesFileExist when you need to."
You can, but it's rarely done in practice. This is a cultural issue more than a language issue. OCaml/Haskell programmers just seem to prefer much shorter, more math-like names than Lisp programmers do.
For me this makes a huge difference when reading through code written by the community. Lisp is just much more immediately understandable than OCaml/Haskell and related languages.
Yes, this is probably my own limitation, and I'd probably be a lot better at it given enough practice. But I just don't need that much practice to understand Lisp, and I can go away from it and come back to it much later without needing a significant refresher in the language either.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#34Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and more attracted by the idea of a language taking 1/10th the typing compared to what's typical today. However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding. Even though the set of short symbols has to be limited, don't we currently have a few dozen often-r…
APL is actually kind of bad at math, or well the kind of math people tend to think of when they talk about matlab or Fortran being good at math. What APL does well is filter/select/transform more spreadsheet style work than linear algebra stuff. It's a language to describe computation as meant by the sort of computer scientists that were born when computer was a job description.
Still, from what I gathered, APL is primarily suited for chewing through a bunch of numbers lumped into arrays, in the manner of shaders or DSP, while I haven't seen examples with traditional control flow (and Perlis notes that loops and branches aren't APL's thing)―though I didn't look for long.
Come to think of it, that's similar to what's often done to lists in Lisp, outside of the more traditional control flow of 'business logic.' Precisely the filter-select-transform.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#35In college, we had a class about high-level languages and the teacher decided to go with APL. Many of my colleagues complained they'd never use APL professionally and that some other language, with more ready practical use (we already had FORTRAN and everyone was fluent in BASIC) would be a better choice. They were right, of course, in that they'd never use APL professionally. They were stupendously wrong in that it was a profoundly enlightening experience.
Once you learn APL, you gain a super-compact mathematical notation in which to express computation.
You also learn the value of extensive comments and of avoiding being clever - if you try to be clever, you won't understand your program 5 seconds after having written it.
And, if you are really lucky, you'd have learned what a beam-spring keyboard feels like. :-)
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#36Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and more attracted by the idea of a language taking 1/10th the typing compared to what's typical today. However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding. Even though the set of short symbols has to be limited, don't we currently have a few dozen often-r…
I hear of APL being used in high-frequency trading and other financial spaces. It's not only because of the language's expressive power, but because the whole runtime fits well within the CPU's instruction cache and, therefore, your program will be ridiculously fast.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#37Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and more attracted by the idea of a language taking 1/10th the typing compared to what's typical today. However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding. Even though the set of short symbols has to be limited, don't we currently have a few dozen often-r…
> However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding.
I use k/q regularly, and I'm not using it for "math".
The compact notation creates value in helping you make correct programs. See [1] and [2] specifically.
[1]: https://news.ycombinator.com/item?id=8476294
[2]: https://news.ycombinator.com/item?id=8476702
You can write C in a dense style as well. And I do. When I do this, I can see opportunities for reuse that I cannot see if I spread my C program across multiple pages and multiple files. Here is the bulk of my webserver[3] that will beat the pants off of any other webserver -- substantially faster than nodejs or kdb's own webserver[4], and probably nginx or anything else you've got. (PS: If you think you know of a faster one, I'd like to know about it).
I am telling you I can only do this because the code is small.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#38Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and more attracted by the idea of a language taking 1/10th the typing compared to what's typical today. However, afaict languages following APL's suit specialize in math, so I wonder if the approach could be adapted to more general kind of coding. Even though the set of short symbols has to be limited, don't we currently have a few dozen often-r…
I personally question the utility of such terseness, and much prefer the verbosity of the Lisp family of languages, where cultural norms make for function names like "number-to-string" and "expand-file-name", rather than the norms I've seen in languages like APL, K, J, Q, OCaml, and Haskell, which seem to love more mathematically-inspired single-letter names like "n" or "k", and various operators in a similar vein. T…
For me, terseness is necessary for correctness.
I don't just do this with APLish languages; I do this with C (and lisp, and PHP, and others...)
I've only ever written short programs correctly: If they can fit on a page, I can just look and see whatever bug I might be experiencing.
If someone wants to change my software, it's because they want it to do something that I don't want it to do. They will find value in the fact it is short: That there isn't very much to read. Admittedly, a programmer unexperienced in this method may have some anxieties about it, but given how valuable correctness is, I'd prefer to cause a bit of anxiety in beginners than make programs that need beginners to fix them.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#39> I am firmly convinced that APL and LISP are related to each other along an important axis of language design and that acquiring simultaneous expertise in both languages is possible and desirable for the beginning student. Were they unified, the set of tasks that succumb to terse, flexible and expressive descriptions will enlarge enormously without overly increasing the intellectual burden on the student over his in…
APL is a read syntax for point-free function chaining in which the operators have one-character names, and may be juxtaposed without intervening whitespace.
Relative to APL, the interesting matters in Lisp tend to lie on the other side of the AST hill.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#40Earlier quoted context omitted.
APL is actually kind of bad at math, or well the kind of math people tend to think of when they talk about matlab or Fortran being good at math. What APL does well is filter/select/transform more spreadsheet style work than linear algebra stuff. It's a language to describe computation as meant by the sort of computer scientists that were born when computer was a job description.
FORTRAN is a great language, but it's not really good at math either. It's used with floats, which are a peculiar and volatile beast, though certainly useful. When I think of "good at math" I think of something like Egison.
Most high performance computing was done with Fortran back in the day (and still used today) because working with arrays and matrices is done at a higher level than C/C++ or Assembly, but it is still a fast language and has easy access to BLAS/LAPACK. When I think of scientific computing, I think of Fortran, Matlab, Mathematica, C, C++, Python + Numpy, and recently Julia. APL could've been great here if the vendors had included low level code to do all the numeric work and used APL as the glue language, but it didn't happen that way and became popular in the finance world instead. It's a shame.