Can APL can be used to implement Machine Learning algorithms? It seems like a good fit.
Yes, see e.g https://apl.wiki/nn
A Personal History of APL (1982)
11–20 of 50 posts
Re: A Personal History of APL (1982)
#12Can APL can be used to implement Machine Learning algorithms? It seems like a good fit.
Yes, but no one's made a reverse-mode autodiff system for it yet, so all of the linked examples have hand-written derivatives.
Re: A Personal History of APL (1982)
#13The language is interesting, but the management ideas in this are very strange.
Example: tin flippers. Items are being checked manually and miscounted. The numbers are inherently inaccurate. And he makes the point that this applies in many other situations - some where the inputs are mechanical, so "Use a machine" isn't a solution. ("Use a better machine" might be. But how would you know without being able to monitor output quality?)
How is a programming language supposed to fix any of this? Finding gross inconsistenicies shouldn't be too hard, but automating broken processes algorithmically means you have automated broken processes.
This is not at all the same problem as formally specifying software in ways that make it more reliable.
The other problem is that it sees software as strictly sequential in->stuff happens->out.
This is basically batch mode, not real time. As soon as you need real time I/O everything gets a lot more complicated. I don't see anything in APL that solves that.
And that's even more true of business processes. To add: it's not that analytics can't be useful. But APL won't somehow magically guarantee that your analytics are any better or more useful than output from some other language or system.
Re: A Personal History of APL (1982)
#14I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
genuinely curious -- do you not feel the burden of being locked in with cpython, gcc/clang, rustc, ...?
or do you maintain forks of those?
Re: A Personal History of APL (1982)
#15The inventor of APL, Ken Iverson, also made the language J which is very much influenced by APL but does not use the special characters of APL. Think of it as ASCII-APL. It is a very nice language to program in and they have a decent user community. It is open source and is incredibly fast and looks at the first glance as cryptic as APL.
Re: A Personal History of APL (1982)
#16I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
There's also April APL: https://github.com/phantomics/april Also the array language family seems to be stronger than ever with foss: ngn/k, BQN, uiua, and of course J but as you mentioned they're all different languages.
April is amazing. I have used J for over a decade, and I am currently being swept away by uiua, but my old Lispy love teamed up with APL in April is a knockout combo: Do the generic stuff with Lisp and the numerical magic with APL.
Re: A Personal History of APL (1982)
#17We had APL on our Prime minicomputer at Swarthmore when I started there in 1978.
Did you do anything with it?
Re: A Personal History of APL (1982)
#18I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
There's also April APL: https://github.com/phantomics/april Also the array language family seems to be stronger than ever with foss: ngn/k, BQN, uiua, and of course J but as you mentioned they're all different languages.
No mention of 'R'?
Re: A Personal History of APL (1982)
#19The easiest way for non-APL programmers to begin to understand APL is to see what it hasn't got: boilerplate and loops. If you discard those from any other programming text you're left with the essence of what the code does. APL is only explicit about that essence, the rest is inferred by the interpreter. That's why it is so compact and that's why if you're used to step-by-step instructions with a ton of air in between you will initially find it hard to read. But that gets easier over time and before you know it you'll think of other languages as hopelessly verbose.
Re: A Personal History of APL (1982)
#20I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…
genuinely curious -- do you not feel the burden of being locked in with cpython, gcc/clang, rustc, ...? or do you maintain forks of those?
what do you mean by "locked in"? They all support external libraries for extra functionality and this extension mechanisms are very well thought over.
The syntax can't be easily extended which I believe could be a good thing, because it encourages using common idioms instead of ad-hoc, understandable only by its author inventions.
Not to mention that some form of syntax extension is present in all of your examples.