[spit2wind]

I 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 is simply different.

[abrudz]

Anyone is of course free to fork GNU APL, or any other APLish FOSS language, and modify it to include Dyalog APL's features. However, Dyalog can only do so much amazing work because users that make significant amounts of money with Dyalog APL pay enough to support 25 full-time employees. Note that as long as you make less than £5000 per year from its usage, you can use Dyalog APL without limitations.

[liveranga]

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.

[lbatista]

I cant recommend enough this april video of Andrew Sengul:

https://www.youtube.com/watch?v=AUEIgfj9koc

[spit2wind]

Thank you. I had seen April previously although it looks like it's had a lot of updates since then. I appreciate you bringing it back to my attention :)

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?

[eggy]

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.

[unkeptbarista]

I had not heard of uiua before, but I'm familiar with both APL and stack languages, so it should fun to explore it its capabilities.

[jacquesm]

No mention of 'R'?

[5-]

genuinely curious -- do you not feel the burden of being locked in with cpython, gcc/clang, rustc, ...?

or do you maintain forks of those?

[spit2wind]

I don't feel locked in by the license of those projects. They have permissive licenses. Anyone can maintain them.

I don't need to personally maintain a fork in order for the possibility to maintain one to exist.

[5-]

what is your realistic estimate for the capability of any non-corporate group to pick up maintenance of one of the open-source projects?

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.

[spit2wind]

At what time, for which project, over which period? If we're talking circa 1982 for APL between then and now, the number would be greater. From last week to this moment, less. Yet, small odds are always better than no odds, in terms of a thing happening. It really only takes one to get started.

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.

[panaeon]

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.

[5-]

> They all support external libraries for extra functionality

this is, of course, also true for dyalog apl, just the same as any practical programming system, be it open-source or not.