What makes the languages (APL, J, K) impressive is that you can simplify what is sometimes pages of code into a single line of symbols (APL) or standard ASCII characters (J and K).
Keep in mind that these languages are the definition of line noise to most coders as having prior knowledge of things like C, Python...etc will do you zero good as the building blocks are completely different from a high level. They might have if-statements in the language, but they're hardly idiomatic. J emphasizes tacit programming which is kind of like a data flow model made up of function application. The languages are quite mathy in some ways, but still approachable.
I find them to be lots of fun, very interactive, thought provoking, and pretty cool. I've only written a little APL & J, but enjoyed how I built my command up from a few built-in primitives.
A problem to me involves reading other people's code which uses primitives I haven't learned yet, or common idioms (Ex: you can make your own average function with a few characters avg=.+/%# so no need to add it to the stdlib). The average function on the tryapl.org site looked a little funny to me...then I realized it worked for not only lists, but multi-dimemsional data structures of n dimensions like tables or lists of tables. I imagine it takes awhile to become proficient.
Surprisingly, both J and APL have some decent support for things such as graphics, but they are still small communities compared to languages we know and love like Python.
In short, give it a try. J has some built in documentation called "J labs" that is submitted by the community. Dyalog APL has a free version for non commercial use and the excellent tryapl.org. Try not to be turned off by the bizzare symbols in APL. They have a long history and are easy to enter with either the IDE or keyboard (especially if you buy one from Dyalog with the symbols on the keys). The inventor of APL got the Turing Award awhile back (later invented J). It was also a big IBM product back in the day and is still used by companies like Volvo.
I think this attributes to why people (not you I believe) find j/k write-only unless they are experienced. Most seem not to be able to imagine that because it is so terse, to compare reading an a4 sheet of k/j compares to reading 50 java files; if you think of it like that, and imagine those java files using some design patterns you did not know before, you can have at least some form of comparison. In that case I find k/j far easier and faster to read. I need to figure out what those few primitives do and how they work but that will take me less time than unravelling all the abstrzctions across all files to an extend I can start customizing code, while in k/j I am ready to jump in. ymmv ofcourse but I think too many people see the code and compare it to a lovely clean OO class in one file, or some a4 of Python and think wtf this is line noise!
Does anyone use J for anything aside from experimentation (and math)? I know the same question is asked of everything that deviates from the mainstream, but the APL (and by extension J) world seems really far out from my mental model of computers.
When is terseness a feature? It must make maintenance a nightmare.
By that I don't mean that APL/J are unilaterally better -- there are plenty of practical reasons to choose R/Matlab/numpy -- but they are unquestionably more beautiful and visionary. They hang together at a deep level in a way those languages do not. They are also much harder to learn, and much more fun.
On the readability of APL (terrific video): https://www.youtube.com/watch?v=v7Mt0GYHU9A
Alan Perlis on its beauty: https://www.jsoftware.com/papers/perlis78.htm
Terseness is a feature. It's also a good design in general, even though it breaks most people's brains.
And since it's so dense, you don't need a lot of lines of code to do most things.
I love programming languages that teach you new ways of thinking about programming and I'm very curious about the APL family--thinking of learning J or q/kdb+.
I do most of my work in query languages on column-store databases, then some visualization and hypothesis testing on top. So I'm wondering if I could find J more expressive than R/Python + some SQL-like language.
Now q/kdb+ might be expensive, but I can only dream of doing analysis using it. SQL is great, but having the full power of K And Q-SQL would be pretty awesome.
This is pretty much the same impression I got, though I came from the other direction. I was kind of surprised how many StackOverflow posts ask about adapting a fix_problem() method to fix some very_similar_problem.
Nowadays there is a great, free, and actively maintained implementation: GNU APL. That, combined with the widespread use of Unicode and the APL support in Linux/XOrg keyboard definitions, make it so much easier to get started than in the past.
I have used APL mostly for fun, that is, for learning the language itself, solving mathematical puzzles, and taking part in "code golf" games. I find the language exquisite, especially its programming model based on multi-dimensional arrays, its graphical symbols, and its grammar. But it is somewhat "impractical" to use nowadays.
J is a great successor (designed by the same mastermind behind APL) but I found it harder to learn (and to read) due to its ASCII "line-noise" look and to the prevalence of point-free or tacit function definitions, which I find inferior in readability.
I'm only now learning NumPy and TensorFlow, and I bet their authors were inspired by APL.
Does anybody have any benchmarks of J's performance against NumPy?
As for K, I wouldn't recommend picking it up. It's closed-source and documentation-less, meaning good look if you run into any trouble; its error messages are notoriously infuriating; it overloads its operators with a ton of meanings, depending on context, even more so than APL and J; and its fundamental programming paradigm is not based on multi-dimensional arrays.
On the other hand, writing an APL-like frontend for TensorFlow looks like a nice project!
GNU APL (1.7)
⍴+.×⌿?2 3000 3000⍴1e10
- size 3000: 65s, 9GiB RSS
(crash on bigger sizes)
J (8.07) $(+/ .*)/?2 3000 3000$1e10
- size 3000: 2s, 0.2GiB RSS
- size 10000: 60s, 3.7GiB RSS
(crash on bigger sizes)
NumPy (1.13.3, blas/lapack 3.7.1) import numpy
a=numpy.random.randint(0, 1e10, (2,3000,3000))
print((a[0,] @ a[1,]).shape)
- size 3000: 25s, 0.2GiB RSS
- size 10000: (>15m, I killed it) 2.3GiB RSS
Conclusions:J's implementation is surprisingly performant! Easily beating NumPy on speed alone by a factor of 10 or more! (And I thought blas/lapack were already heavily optimized libraries!) J's memory usage is comparable to that of NumPy. GNU APL had the worst memory and cpu profile of them all.
Dyalog APL/S-64 (17)
⍴+.×⌿?2 3000 3000⍴1e10
- size 3000: 6.6s, 0.5GiB RSS
- size 10000: 101s, 5.4GiB RSS
Conclusions:J's implementation is still the fastest at this particular task (matrix multiplication of huge matrices on a single CPU thread--granted, not the most significant of benchmarks.) Dyalog APL comes close behind. GNU APL and NumPy lag much more behind that.
As for the language itself, it is free to use in commercial projects I think (someone please correct me if I'm wrong), but the source code to the J language is either GPL3 or you can pay. I think that means if you wanted to use the J source as part of a commercial project, you can pay or make the source available under the GPL3 license. I'm honestly not sure though and would appreciate some clarification.
and it's apparently got a new in-app keyboard to make it easier, since last time I looked.