This it the end of an era. Although most people will have never seen it, APL was a pretty influential programming language. It is the main reason that Kenneth Iverson received the Turing award.
It uses its own character set, which makes it possible to write very programs that performed quite complicated calculations. The down-side is that programs are generally hard to understand by outsiders (like yourself next year). All people that complain that Perl is difficult to read, should certainly try APL.
When IBM stops supporting some technology, you can be certain that it is absolutely commercially dead. RIP.
I would agree that APL fits into the category of a "write-only" language, but it's amazingly powerful.
My first project many years ago was working on the IBM 5100 "portable" computer (a 50 lb suitcase sized thing). It had a toggle switch in front that could boot it into a Basic interpreter or an APL interpreter.
I had one in my bedroom as a kid, complete with the enormous (100 lb?) dual 8" disk drive. My stepdad inherited it after his father passed. It was brand new and they hadn't turned it on. I had a great time with it and later become a mainframe developer at IBM!
When IBM stops supporting some technology, you can be certain that it is absolutely commercially dead. RIP.
IBM got out of the laptop business almost 20 years ago.
The down-side is that programs are generally hard to understand by outsiders
I think there are a lot of people who believe they understand Python because it kindof looks like Java. I wonder if they leave their shoes tied overnight or if they check a tutorial on YouTube every morning.
It is the main reason that Kenneth Iverson received the Turing award.
Array programming is probably the most interesting piece of technology I have seen in over thirty years of programming.
If you can’t read it, it’s like saying you can’t lift. No of course you can’t lift unless pull you lift. That’s how it works. The good news is it’s easier than you think.
I think there are a lot of people who believe they understand Python because it kindof looks like Java.
Have you actually met anyone who's asserted that Python "kind of looks like Java", let alone that its resemblance to Java makes it easier for them to understand? I've written both Java and Python, and out of all the things I could imagine saying about Python, "Boy, this is sure kind of like Java" would be very, very far down on the list.
> I think there are a lot of people who believe they understand Python because it kindof looks like Java.
Have you actually met anyone who's asserted that Python "kind of looks like Java"
That's unfair.
let alone that its resemblance to Java makes it easier for them to understand?
Yes, but maybe not in the way you're expecting.
Guido himself remarked on many of their similarities back in 1997[1]; They definitely have a very similar execution model, the syntax can be directly translated almost like a cheat-sheet[2], and yeah, I think people can easily convince themselves into thinking the knowledge -- even superficial knowledge like the aesthetics of one language can help them "comprehend" the other. If you haven't observed this, I think you either haven't been programming that long or you're just trying to look at what I'm saying too narrowly in an effort to troll for a fight. And it's not just Python: Norvig even (reportedly) almost convinced himself (in this way) that Python is the same as Lisp[3], and that's just bananas!
Now, if you still don't know what I'm talking about, this next thing isn't going to make any sense at all either, but I'm hopeful you can try to understand after some reflection, and if not you, someone else who reads this with an open mind: If you are using one language to understand another, you're not actually understanding that language.
That has a very significant implication that turns out to make Array programming really hard for experienced programmers: Because you already know Java when you learn Python (for example) you think you're learning Python faster than you actually are. It still takes a few years to get really good at Python, but in the meantime, you can lean so heavily on your Java-think you don't even realise it. You've benchmarked the rate at which you "learn", and you just can't get APL, so you might just say something impossibly stupid like "APL is hard to understand" when Iverson won a freakin' Turing award for how understandable it was[4]!
Maybe that helps you understand what I mean, but if not, maybe this[5] will.
Thank you for these explanations. I reflected on my experience. My intuitive reaction to APL is that all these special symbols aren’t necessary and APL would be more approachable with some speaking identifiers instead. Then I remembered my experience with Perl. People used to say that all these special characters make Perl hard to learn. And I couldn’t understand what the problem was. Now I see my hypocrisy!
APL was special among the early languages in that it had memory management, implicit types, highly optimized support for multidimensional array operations, and composable functions. It was the language for anything mathematical. The characterset was actually a plus: it allowed the experienced user to read it as one reads math, which in turn made experimentation and algorithm optimization extremely fast. The downsides of course being the technical debt at all levels of the stack: from the files filled with code which one is wise to not touch, to the characters which date back to the days of pressing backspace on a typewriter to combine multiple symbols, to the machinations necessary to roll out interpreted code to someone else's system...
Well, since the rise of Matlab (and now Numpy) there are alternatives which fill APL's niche, but I do miss the elegance of everything being an array.
This might not mean what you'd expect at a glance. The agreement here seems to be that IBM has sold all relevant IP for APL2[0] to Log-On Software[1], which will now be offering essentially the same product and some level of support.
For some time now APL2 has only barely been under active development, so it's not clear whether this will lead to more or less effort to develop the product. First released in 1984, APL2 is now far from the leading edge of APL development. For example, APLs began adding control structures to free programmers from using Branch (Goto) for control flow in the mid-1990s (late, I know!). APL2 still doesn't have them. Dyalog (my former employer) is pretty clearly the front-runner for commercial APL at this point; APL+Win also sees some level of development and NARS2000 and April are some non-commercial efforts to check out.
Eh, this is the typical way that IBM leaves markets. Yes, you can still buy OS/2 from eComStation, but the end of organizational support and selling what remains to a small entity is how IBM avoids having to deal with it anymore.
Good to know. I'm definitely not denying that this is IBM washing its hands of APL officially, just pointing out that unofficially it's been this way for a decade or two at least. Despite hosting the creation of APL, IBM has a distinguished history of neglecting it. In the early years there was some pressure to use PL/I instead of APL. For timesharing (when it was profitable, before microcomputers), APL*PLUS and SHARP APL took over a lot of market share from IBM by being faster to implement features customers wanted. APL2 was a reversal of this trend, but it didn't last long.
The same happened to VisualAge for Smalltalk where in 2005 Instantiations, Inc. took over "worldwide rights for this product" - and is still offering it...
I kind of wish that VisualAge for Java was still a thing but in reality it is unlikely that I would do anything more with it than I ever did with v1.0 and v2.0 which still sit on a shelf.
The main problem with VisualAge for Java was that you couldn't integrate external libraries easily... it was not file-system-based, like IDEA/Eclipse are today...
Yes, as I tried to imply, I never really used it enough to feel the pain of it's idiosyncratic implementation. Before I even posted the earlier comment I checked Wikipedia about VisualAge (to ensure I hadn't missed later releases) and learned, I think for the first time, that VisualAge Java was apparently implemented by extending a Smalltalk VM and presumably used the standard Smalltalk image model. I have been a Smalltalk aficionado and see some value in the image based model and think I might not feel the pain as much as the average user.
IBM should have taken an altruistic path on APL2. They have made tons of money with APL over the years. They should have released it as FOSS. As someone who started with APL in the early 80's, APL2 showed a lot of promise at the time.
The APL ecosystem is dead enough that having a company like IBM go FOSS with the language could --not likely, but it could-- spike interest and perhaps lead to the development of "APL3" or whatever the next evolutionary step of the language might be named.
From my perspective core APL is now a few decades behind the times. A non-trivial effort would be required to bring it into what it could become. And this could only be done through FOSS and people willing to invest time and smarts into driving this evolutionary step.
A curious question (from a long-time open source contributor)...
From the perspective of IBM's customers of APL2 (not from the perspective of some other group of humanity), would it best suit their interests to have APL2 spun off to a company, or for APL2 to be released as FOSS?
I'm wondering whether, whatever the needs of those APL2 customers, perhaps the company would be more likely to satisfy those needs, compared to waiting for whatever emerges from FOSS?
(Of course, with FOSS, multiple companies could emerge, and also be motivated to compete. But they'd be competing with each other, and with free FOSS undercutting them, for possibly a small pool of customers that might not grow much. And I don't know whether it'd be viable to invest in that slice of customers, or to even be in that business at all?)
From my perspective as someone who's seen this happen before:
"Released as FOSS" means "We have withdrawn life support and it will now die a slow lingering death. Have fun with that." Unless you can spare the resources to maintain it yourself, this marks the point when it's officially time to migrate away immediately.
"Spun off to a small company" means "Someone has now been personally incentivized to take care of it." It's certainly not guaranteed to survive long-term, but it's at least been given a chance at revitalization. It's probably worth sticking around for a while to see what happens.
Someone who wants APL2 but not to pay anyone for it uses GNU APL: they just aren’t that far away from each other.
Maybe it’s worth closing the gap, but who pays for that? APL2 has already been paid for, so it’s hard for a company to pay for it again.
On the other hand, they continue to pay for support, and if there were more APL2 users then that could surely save them money, and it seems plausible that a FOSS APL2 would make more APL2 users, but the existing APL2 users would suffer because they would be able to command less money for the support they already offer.
I know the cultural understanding among developers is that FOSS is "altruistic", but that's often wrong.
It's all about incentives. If there's no incentive behind an OSS community working on this project, it'll just burn out a few naive souls, and kill off the project for the rest.
Giving the project to a company which has commercial interest in maintaining it and supporting it through commercial licensing could mean a better future for APL2.
This aftermath is very typical when a project is "interesting" from commercial perspective, but it's quite "boring" from technical/enthusiast perspective.
I'm not saying it's ALWAYS one way or another. But it depends on the APL2 audience.
We gotta start seeing FOSS as a tool, not as charity or as some sort of "giving to the world". We're engineers, or at least we should think as engineers. Engineers know no solution is just "best" at everything. Everything has pros and cons, and you need to consider things in context. That also applies to IP management with regards to what's best for a project's continued existence.
Another effort worth mentioning is BQN, which is a really nice solution for anyone that wants to gets started on an APL-like language. It's very much APL, but designed without a lot of the historical limitations. The documentation is really good, so please give it a try: https://mlochbaum.github.io/BQN/
Then there is GNU APL, which is a pretty close APL2 clone. Because of this, it lacks some of the new stuff in implementations such as Dyalog, but as a replacement for APL2 is does a very good job (please give the Emacs mode for it a try, just a shameless plug since I implemented that one). https://www.gnu.org/software/apl/
Of course, I have to get a second plug in, and tell people about KAP which is my array language. It's pretty close to regular APL, and comes with a graphical client to help out with the input. It has several features that to my knowledge hasn't been done in an array language, but it's still something that can only be described as experimental. But I would of course find it fun if someone wanted to spend time with it. https://github.com/lokedhs/array
This it the end of an era. Although most people will have never seen it, APL was a pretty influential programming language. It is the main reason that Kenneth Iverson received the Turing award.
It uses its own character set, which makes it possible to write very programs that performed quite complicated calculations. The down-side is that programs are generally hard to understand by outsiders (like yourself next year). All people that complain that Perl is difficult to read, should certainly try APL.
When IBM stops supporting some technology, you can be certain that it is absolutely commercially dead. RIP.
I would agree that APL fits into the category of a "write-only" language, but it's amazingly powerful.
My first project many years ago was working on the IBM 5100 "portable" computer (a 50 lb suitcase sized thing). It had a toggle switch in front that could boot it into a Basic interpreter or an APL interpreter.
I had one in my bedroom as a kid, complete with the enormous (100 lb?) dual 8" disk drive. My stepdad inherited it after his father passed. It was brand new and they hadn't turned it on. I had a great time with it and later become a mainframe developer at IBM!
IBM got out of the laptop business almost 20 years ago.
I think there are a lot of people who believe they understand Python because it kindof looks like Java. I wonder if they leave their shoes tied overnight or if they check a tutorial on YouTube every morning.
Array programming is probably the most interesting piece of technology I have seen in over thirty years of programming.
If you can’t read it, it’s like saying you can’t lift. No of course you can’t lift unless pull you lift. That’s how it works. The good news is it’s easier than you think.
Have you actually met anyone who's asserted that Python "kind of looks like Java", let alone that its resemblance to Java makes it easier for them to understand? I've written both Java and Python, and out of all the things I could imagine saying about Python, "Boy, this is sure kind of like Java" would be very, very far down on the list.
That's unfair.
Yes, but maybe not in the way you're expecting.
Guido himself remarked on many of their similarities back in 1997[1]; They definitely have a very similar execution model, the syntax can be directly translated almost like a cheat-sheet[2], and yeah, I think people can easily convince themselves into thinking the knowledge -- even superficial knowledge like the aesthetics of one language can help them "comprehend" the other. If you haven't observed this, I think you either haven't been programming that long or you're just trying to look at what I'm saying too narrowly in an effort to troll for a fight. And it's not just Python: Norvig even (reportedly) almost convinced himself (in this way) that Python is the same as Lisp[3], and that's just bananas!
Now, if you still don't know what I'm talking about, this next thing isn't going to make any sense at all either, but I'm hopeful you can try to understand after some reflection, and if not you, someone else who reads this with an open mind: If you are using one language to understand another, you're not actually understanding that language.
That has a very significant implication that turns out to make Array programming really hard for experienced programmers: Because you already know Java when you learn Python (for example) you think you're learning Python faster than you actually are. It still takes a few years to get really good at Python, but in the meantime, you can lean so heavily on your Java-think you don't even realise it. You've benchmarked the rate at which you "learn", and you just can't get APL, so you might just say something impossibly stupid like "APL is hard to understand" when Iverson won a freakin' Turing award for how understandable it was[4]!
Maybe that helps you understand what I mean, but if not, maybe this[5] will.
[1]: https://www.python.org/doc/essays/comparisons/
[2]: http://math-cs.gordon.edu/courses/cps122/handouts-2014/From%...
[3]: http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-wh....
[4]: https://www.jsoftware.com/papers/tot.htm
[5]: https://www.youtube.com/watch?v=6cBtqhq5P28
Thank you for these explanations. I reflected on my experience. My intuitive reaction to APL is that all these special symbols aren’t necessary and APL would be more approachable with some speaking identifiers instead. Then I remembered my experience with Perl. People used to say that all these special characters make Perl hard to learn. And I couldn’t understand what the problem was. Now I see my hypocrisy!
I have certainly met people who have done their level best to write Python that /looked/ like Java...
But even they were disappointed at how un-Java Python was. I'm sure Guido is relieved.
APL was special among the early languages in that it had memory management, implicit types, highly optimized support for multidimensional array operations, and composable functions. It was the language for anything mathematical. The characterset was actually a plus: it allowed the experienced user to read it as one reads math, which in turn made experimentation and algorithm optimization extremely fast. The downsides of course being the technical debt at all levels of the stack: from the files filled with code which one is wise to not touch, to the characters which date back to the days of pressing backspace on a typewriter to combine multiple symbols, to the machinations necessary to roll out interpreted code to someone else's system...
Well, since the rise of Matlab (and now Numpy) there are alternatives which fill APL's niche, but I do miss the elegance of everything being an array.
IBM exited the desktop/laptop PC market in 2005.
“Absolutely commercially dead” is not quite how I would describe it.
Yeah, it's more like "when IBM stops supporting some technology, you can be certain that they can't make any more dosh off of it."
Maybe the IBM of old but the current IBM is more of a financial engineering company that happens to have some technical divisions.
I'm not sure that the fact that IBM is developing a next-gen server offering supports your view.
This might not mean what you'd expect at a glance. The agreement here seems to be that IBM has sold all relevant IP for APL2[0] to Log-On Software[1], which will now be offering essentially the same product and some level of support.
For some time now APL2 has only barely been under active development, so it's not clear whether this will lead to more or less effort to develop the product. First released in 1984, APL2 is now far from the leading edge of APL development. For example, APLs began adding control structures to free programmers from using Branch (Goto) for control flow in the mid-1990s (late, I know!). APL2 still doesn't have them. Dyalog (my former employer) is pretty clearly the front-runner for commercial APL at this point; APL+Win also sees some level of development and NARS2000 and April are some non-commercial efforts to check out.
[0] https://aplwiki.com/wiki/APL2
[1] https://log-on.com/2021/01/26/log-on-software-announces-log-...
Eh, this is the typical way that IBM leaves markets. Yes, you can still buy OS/2 from eComStation, but the end of organizational support and selling what remains to a small entity is how IBM avoids having to deal with it anymore.
Good to know. I'm definitely not denying that this is IBM washing its hands of APL officially, just pointing out that unofficially it's been this way for a decade or two at least. Despite hosting the creation of APL, IBM has a distinguished history of neglecting it. In the early years there was some pressure to use PL/I instead of APL. For timesharing (when it was profitable, before microcomputers), APL*PLUS and SHARP APL took over a lot of market share from IBM by being faster to implement features customers wanted. APL2 was a reversal of this trend, but it didn't last long.
The same happened to VisualAge for Smalltalk where in 2005 Instantiations, Inc. took over "worldwide rights for this product" - and is still offering it...
I kind of wish that VisualAge for Java was still a thing but in reality it is unlikely that I would do anything more with it than I ever did with v1.0 and v2.0 which still sit on a shelf.
The main problem with VisualAge for Java was that you couldn't integrate external libraries easily... it was not file-system-based, like IDEA/Eclipse are today...
Yes, as I tried to imply, I never really used it enough to feel the pain of it's idiosyncratic implementation. Before I even posted the earlier comment I checked Wikipedia about VisualAge (to ensure I hadn't missed later releases) and learned, I think for the first time, that VisualAge Java was apparently implemented by extending a Smalltalk VM and presumably used the standard Smalltalk image model. I have been a Smalltalk aficionado and see some value in the image based model and think I might not feel the pain as much as the average user.
IBM should have taken an altruistic path on APL2. They have made tons of money with APL over the years. They should have released it as FOSS. As someone who started with APL in the early 80's, APL2 showed a lot of promise at the time.
The APL ecosystem is dead enough that having a company like IBM go FOSS with the language could --not likely, but it could-- spike interest and perhaps lead to the development of "APL3" or whatever the next evolutionary step of the language might be named.
From my perspective core APL is now a few decades behind the times. A non-trivial effort would be required to bring it into what it could become. And this could only be done through FOSS and people willing to invest time and smarts into driving this evolutionary step.
A curious question (from a long-time open source contributor)...
From the perspective of IBM's customers of APL2 (not from the perspective of some other group of humanity), would it best suit their interests to have APL2 spun off to a company, or for APL2 to be released as FOSS?
I'm wondering whether, whatever the needs of those APL2 customers, perhaps the company would be more likely to satisfy those needs, compared to waiting for whatever emerges from FOSS?
(Of course, with FOSS, multiple companies could emerge, and also be motivated to compete. But they'd be competing with each other, and with free FOSS undercutting them, for possibly a small pool of customers that might not grow much. And I don't know whether it'd be viable to invest in that slice of customers, or to even be in that business at all?)
FOSS is almost certainly better all else being equal. But what IBM's customers probably care far more about is the availability of support.
From my perspective as someone who's seen this happen before:
"Released as FOSS" means "We have withdrawn life support and it will now die a slow lingering death. Have fun with that." Unless you can spare the resources to maintain it yourself, this marks the point when it's officially time to migrate away immediately.
"Spun off to a small company" means "Someone has now been personally incentivized to take care of it." It's certainly not guaranteed to survive long-term, but it's at least been given a chance at revitalization. It's probably worth sticking around for a while to see what happens.
Someone who wants APL2 but not to pay anyone for it uses GNU APL: they just aren’t that far away from each other.
Maybe it’s worth closing the gap, but who pays for that? APL2 has already been paid for, so it’s hard for a company to pay for it again.
On the other hand, they continue to pay for support, and if there were more APL2 users then that could surely save them money, and it seems plausible that a FOSS APL2 would make more APL2 users, but the existing APL2 users would suffer because they would be able to command less money for the support they already offer.
I know the cultural understanding among developers is that FOSS is "altruistic", but that's often wrong.
It's all about incentives. If there's no incentive behind an OSS community working on this project, it'll just burn out a few naive souls, and kill off the project for the rest.
Giving the project to a company which has commercial interest in maintaining it and supporting it through commercial licensing could mean a better future for APL2.
This aftermath is very typical when a project is "interesting" from commercial perspective, but it's quite "boring" from technical/enthusiast perspective.
I'm not saying it's ALWAYS one way or another. But it depends on the APL2 audience.
We gotta start seeing FOSS as a tool, not as charity or as some sort of "giving to the world". We're engineers, or at least we should think as engineers. Engineers know no solution is just "best" at everything. Everything has pros and cons, and you need to consider things in context. That also applies to IP management with regards to what's best for a project's continued existence.
Another effort worth mentioning is BQN, which is a really nice solution for anyone that wants to gets started on an APL-like language. It's very much APL, but designed without a lot of the historical limitations. The documentation is really good, so please give it a try: https://mlochbaum.github.io/BQN/
Then there is GNU APL, which is a pretty close APL2 clone. Because of this, it lacks some of the new stuff in implementations such as Dyalog, but as a replacement for APL2 is does a very good job (please give the Emacs mode for it a try, just a shameless plug since I implemented that one). https://www.gnu.org/software/apl/
Of course, I have to get a second plug in, and tell people about KAP which is my array language. It's pretty close to regular APL, and comes with a graphical client to help out with the input. It has several features that to my knowledge hasn't been done in an array language, but it's still something that can only be described as experimental. But I would of course find it fun if someone wanted to spend time with it. https://github.com/lokedhs/array