A Personal History of APL (1982)(ed-thelen.org) |
A Personal History of APL (1982)(ed-thelen.org) |
https://en.m.wikipedia.org/wiki/APL_syntax_and_symbols#Monad...
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.
For the APL family, that's often a call for code which works with external interfaces. In many potential APL environments a handful of well designed custom primitives would get you where you need to go.
But no programming language is adequate for all roles, and that includes APL. (It can still be useful for modeling / prototyping for real time work, but that's not always necessary.)
(btw I second the recommendation of the 1962 A Programming Language)
Edit:
> The third page had an illustration that, in a few short lines, described George Dantzig's simplex algorithm simply and precisely.
> That was the overwhelming, crucial experience.
This is the crucial feature of the APL family for me: they permit algorithm discussions via inline, not block, content.
eg: https://news.ycombinator.com/item?id=28970345
Edit 2: Upon reflection, it's probably also the Achilles' Heel of the APL family: most people vastly prefer easy and DWIMy over simple and precise.
Edit 3: found the paper containing the simplex algorithm: https://www.jsoftware.com/papers/DFSP.htm Note that 1960 was before "structured programming" so we now have (with the benefit of hindsight) much better ways to express the control flow of this calculation.
Most people also vastly prefer not having to work on difficult problems. Iverson was clearly trying to provide a notation that would help the (admittedly smaller) group of people who find solving difficult problems interesting and valuable.
lisp baffled me for a while because, in my mind, a list is different from a tree, but in lisp a list element might be itseld a list, and so a lisp list might be a tree. similar situation with J arrays.
i'm not sure how APL does it. i /think/ it uses a flat array model, but i'm not sure what that means exactly, or if it's even applicable to modern APL, let alone what it might imply about bending APL arrays into other data structures.
But, yes, approaches which use some kind of array representation are highly favored by the language (and by other languages, to varying degrees, once you understand the patterns and issues).
https://news.ycombinator.com/item?id=27460887
> In the mid-seventies at Swarthmore College, we were mired in punched card Fortran programming on a single IBM 1130. ... Late one Saturday night, I made a misguided visit to the computer center while high, smelled sweat and fear, and spun to leave. Too late, a woman's voice: "Dave! I told Professor Pryor he needed you!" ... So busted! Then I heard this voice “See these square brackets? See where you initialize this index?” He was spectacularly grateful.
> One cannot overstate the rend in the universe that an APL terminal presented, catapulting me decades into the future.
Ah, I sometimes have the wild thought that if he had just stuck with J or APL, Python may not be where it is today in ML. Python has become the Borg.
I guess the ideas, not the notation, turned out to be the important part after all.
"I have only made this letter longer because I have not had the time to make it shorter." - It's Advent of Code[1] (AoC) season again; take a moment to look at the answers people put in the big Reddit answers threads e.g.[2]. The comments are all a beautiful/awful zoo of languages - wildly varying in programmer experience level, familiarity with the language, choice of approach and algorithm, runtime, focus on a tidy solution or a quick answer. I wish we could see how much time people put into their solutions - I suspect this famous quote applies and it takes longer whether you polish a plain language or write directly in a terse language. I think the hurried or inexperienced answers tend to be long and garbled, the experienced and polished answers tend to be clean and clear. The racing leaderboard entries that I've seen - people seeing the problem and getting an answer ASAP - tend to be Python, and tend to be short and clear. They're almost never (APL, J, K, Q, R, uiua, Haskell). Does that say anything of value about the ability to quickly and clearly express ideas in a language?
I feel like there's enough of these answers now after years of AoC for someone to analyse and compare the languages. My gut feeling is that non-golfed Python still comes out the most easily writable and easily readable, the nicest balance between density and verbosity.
[1] https://adventofcode.com/ - daily puzzles through December, solved with code using whatever language you like, however you like, the site only checks your answer not your working.
[2] https://old.reddit.com/r/adventofcode/comments/1883ibu/2023_...
Does it? If you saw a bike racer riding an old steel commuter bike with mudguards and pannier rack, because lots of people ride those, wouldn't that be weird? Bike racers ride lightweight carbon fibre bikes and they do so because other bike racers ride them and they could not be competitive with something much heavier and less aerodynamic. They use every advantage they can get.
If there was a programming language which was unusually good for rapid data crunching, over several years of AoC wouldn't you expect it to become the dominant language on the leaderboard?
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.
It looks like it can load pure APL files.
All the examples I see use the Lisp repl and APL is called within strings. Does it provide an APL repl, too?
or do you maintain forks of those?
I don't need to personally maintain a fork in order for the possibility to maintain one to exist.
Each year probably only a single digit number of people using an array language actively try for leaderboard spots, so if anything it's impressive any of them manage compared to the 100x or 1000x number of python/etc programmers also competing.
this is, of course, also true for dyalog apl, just the same as any practical programming system, be it open-source or not.
John once did a live demo where a negative number (like ¯17.01) suddenly appeared in his APL session log. He looked puzzled for a moment, continued with his demo script for a little while, and arrived at the statement ⎕DL ¯17 (delay negative 17 seconds, and return the actual amount of time waited). He exclaimed "Oh, THAT's what that was!" and continued with his demo.
John had a fantastic sense of humour, if you have not seen them I recommend taking a little time off to watch some of the recordings at https://johnscholes.rip/video/
proprietary programming systems typically come with escrow agreements, providing access to the source code to customer e.g. if the vendor stops supporting the product. that wouldn't be materially different from another large corporate picking up e.g. llvm/clang if apple/google stop being interested.
I appreciate you mentioning escrow agreements. That's a valid point. However, "typically" is not "guaranteed". It looks like MicroAPL, a company so involved with APL that they put it in their company name, no longer sells or develops their APLX product (even though the company appears to still exist). They stopped selling and developing it in 2011. Was it guaranteed that Dyalog would take the project over and host the binaries and documentation in 2016? I don't think so. Good on Dyalog for doing it. The fact that nothing was guaranteed is what makes their actions meritable.
Yet, as far as I can tell, it's only the binaries that are hosted. It appears to receive no further development, no support for new architectures, etc. The thing which is materially different is that the source code is not available, there is no guarantee that it ever will be, and no one, outside of maybe one of two people, have legal authority to use the source. Your point about escrow stands and is valid. It's also fundamentally different than a project having an open license.
PS: sorry, I didn't directly answer your question. You asked for an estimate of a non-company continuing development of one of the current freely licensed projects you listed. For something like LLVM, I think pretty high. A lot of people are involved in it, a lot of people prefer it to GCC, and it has been worked on by many people for many years. But knows. Maybe the companies pull out support and it dies. Maybe not.
That's also a separate question: what's the chance of an open project getting continued support. My lament is that many APLs aren't open to begin with and are not guaranteed the chance to get support.