I think you're right. Aaron Hsu's work in APL is inspiring and awesome. The source code to his data parallel compiler hosted on the GPU is 17 lines of APL! Read the abstract to his paper here:
The source code to his data parallel compiler hosted on the GPU is 17 lines of APL!
The co-dfns source I've seen[1] is much longer. Do you know if there's a write-up somewhere of the differences between that and Appendix B from the dissertation?
The 17 lines don't include the parser or the code generator, which most people would count as "part of a compiler" in a practical sense. They are usually the most mechanical parts of a compiler though, so there's relatively little to be excited about in them.
I think its important to distinguish between something that is a core piece vs all the other things that make the system usable. For example once you start adding error handling, and good error reporting, the complexity goes up by an order of magnitude. And in many cases the approach for the core does not necessarily scale out to the other contexts.
The right tool for the job. If you are building a huge website with input forms, videos, data collection, ML algorithms, yes then you wouldn't do the whole thing in APL or J even if you could. Python is big in ML because packages for working with data in array language ways were developed. Pandas by Wes McKinney is one example, and he studied J or q, and even tweeted: IMHO J is the best APL for data analysis because of its broad suite hash table-based functions.
I like APL and J as a scratchpad where arrays are the basic unit and not scalars. J is functional and it turned me on to that world before I touched Haskell or F#.
Aaron Hsu has a lot of great videos that speak to a lot of the usability and scaling out you mention:
I am able to grasp concepts or own them after coding them in APL or J even if the code isn't as fast such as how well APL applies to Convolutional Neural Networks [1,2]. I really understood the mechanics of CNNs better after working through this paper a lot more than books I had read on ANNs in general since the late 80s/early 90s. By contrast, I have coded ANNs in C and Python, and I get lost in the PL, not the concept, if that makes sense. Anyway, I am a polyglot and find people criticize J/APL/k etc. from a brief look without really trying to learn the language. I learned assembler and basic back in 1978 to 1982, and I felt the same way when I first looked at opcodes.
Bahaha. It's a small world fellow HN user. As soon as ACM opened their digital library, I started looking for interesting APL papers and found that one and thought it was beautifully done. My takeaway is that you can make purpose-built AI in APL with very little code versus calling out to a large library like Tensorflow and having no idea what's going on.
I think someone has translated this to J, but I am trying on my own to practice my J-fu by implementing it in my own way. Then I usually open it up to the J experts on the mailing list, and my learning takes off. There are some awesomely smart people there who are generous with their time.
Yes, the takeaway is that with APL or J is that you can see the mechanics in a paragraph of code, and it is not a very trivial example. If the libraries or verbs are created to deal with some of the speed or efficiency issues, it is promising as a way of understanding the concept better.
The dataframes of R and Python (Pandas) were always a thing in APL/J/k/q, so it is their lingua franca or basic unit of computation upon which the languages were built - arrays, not a library.
More importantly, almost along the lines of the emperor has no clothes, is a tack to get away from the black box, minimal domain knowledge, ML or DL that cannot be explained too easily - see newly proposed "Algorithmic Accountability Act" in US legislature. Differentiable Programming and AD (Automatic Differentiation)applied with domain knowledge to create a more easily explainable model, and try to avoid biases that may creep into a model and affect health care and criminal systems in a negative way [1][2].
And then there are those who use DL/ANNs for everything, even things that are easily applied and solved using standard optimization techniques. Forest from the trees kind of phenomenon. I have been guilty of getting swept up with them too. I started programming ANNs in the late 80s to teach myself about this new, cool-sounding thing called "neural networks" back then ;)
https://scholarworks.iu.edu/dspace/handle/2022/24749