Would have liked to see an APL on the Python VM ala Hylang. Still waiting for Hy to become stable enough to switch to for Python work but that’s the ticket right there.
Trouble is that APL/J gain their magical abilities by specialising the semantics to things that fit array processing. It doesn’t work for general programming.
What does the integration ecosystem look like for array-based languages? e.g. writing and consuming network services, database interoperability, C FFI, text encodings, etc.
Given this release of APL introduces support for shebang scripts I'm thinking the ecosystem of integration isn't great but I'm happy to be wrong.
That gives you access to most things C# can access, presumably System.Data.DataTable and database access, or P/Invoke to C libraries? It also supports the other way around, writing :Class-es and using File -> Export to make .Net DLLs for other .Net languages to import and use (with Dyalog APL installed and licensed to run the code inside, mind you).
Web services: From https://www.dyalog.com/tools/web-applications.htm it can be an ASP.Net language, or with "MiServer, A development platform for web applications written in APL" or several others.
There's the classic ⎕CMD and ⎕SH which run a string in the Windows command interpreter, or Linux shell, and get the text result:
⎕cmd 'echo hello'
hello
Seems to have various support for ActiveX and COM integration, too. I've never used any of this in anger or in production, but it surprised me how much integration it has.
> "Given this release of APL introduces support for shebang scripts I'm thinking the ecosystem of integration isn't great but I'm happy to be wrong."
This, specifically writing like a Python script, has been a sticking point for Dyalog APL for a while, I understand. APL the language and way of using it predates filesystems and was traditionally more like a self-enclosed virtual machine; you power it up, run your code inside it, and then save its running state to disk in a proprietary binary workspace blob that only it can read back again. And when filesystems came along, ⍴↑⍨⍥⊤⍎ weren't very convenient to write and save in scripts for a long time either.
Dyalog is historically Windows-based and .Net is the preferred solution for a lot of things. But it has reasonable support for most of what you mention. There's a solid FFI, and text is UTF-32 internally with support for I/O with other encodings. See the list of system functions at [0]. Conga is the http library but I don't have any idea how well it works.
This is an area where array languages are entirely different from one another. J and K have been using shebangs for a long time (although J does this by assuming a shebang will be valid but no-op code, and fails if the path contains a space… sigh). Support for interop just depends on what other applications are considered important by the developers of that particular language.
J has support for being integrated into other projects[1], e.g. the link below has C# and Excel links at the end. You can use it as a COM server if you run 'jreg.cmd' first to register it.
Some things have libraries, like HttpCommand and the lower level Conga for network services. C FFI is done via the ⎕NA (Name Association) system function. Various Unicode encodings are available via ⎕UCS, etc.
I think the emphasis on "in production" doesn't make sense for a lot of languages. Not everything has to be part of a highly engineered, user facing system to be useful.
For example, I would never use R "in production", however I have used R to make many important internal decisions, and generate recurring reports, etc. Very few people use Excel "in production" but there are plenty of very important companies using Excel.
Likewise I can imagine there are a few people out there using APL for something meaningful and important, even if that code is never truly "in production".
There are plenty of useful, wonderful programs written in the world that were never destined to be part of a production system. The code I've enjoyed writing the most and learned the most about the world from writing typically falls into this category.
My first employer used Excel "in production": A C# app would read numbers from a shared network drive, feed them into a timeseries database, and the real-time part of the system would be reloaded. Eventually a web-interface was put in place instead of the Excel sheet that provided for faster input validation.
I think the emphasis on “in production” is because it’s assumed that the only people really using APL are folks maintaining legacy codebases. I picture APL like COBOL: there’s no(?) reason someone would even toy around with it these days unless there was some intrinsic property of APL that makes it uniquely suited to some problem domain, and to such a degree that people can overlook its major shortcomings. _Is_ there something APL is actually useful for these days?
We have a lot of APL in SimCorp and are one of Dyalog’s main customers. 1.6 million lines in 2014 I’ve heard, but I don’t know how much we have right now.
The biggest single issue with using APL in production is developer hiring and training.
Aaron's been an academic for most of his career and was working for Dyalog as of 2020 (edit: still there, per [0]). I wouldn't describe his work as "production", since it mainly relates to APL itself rather than some external problem to be solved with it.
True, maybe he isn't considered a member of "team Dyalog" while still being legally an employee or contractor? He was hired in early 2020 a few months before I left, and partly funded by Dyalog before that. And he's told me he prefers to be seen as independent, but that was when he was working on his PhD and Indiana University was his primary affiliation.
https://www.youtube.com/watch?v=DmT80OseAGs