Dyalog APL 18.2

Dyalog APL lets you call to the .Net Framework almost directly, e.g.

          ⎕using←'System.Diagnostics,System.dll'
          st←⎕new Stopwatch
          st.Start
    <pause>
          st.Stop
          st.Elapsed
    00:00:03.5493601

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).

e.g. text encoding:

          ⎕using,←⊂'System.Text'
          Encoding.Unicode.GetBytes (⊂'hello')
    104 0 101 0 108 0 108 0 111 0

(.Net calls UTF-16 "Unicode").

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.

[0] https://help.dyalog.com/18.2/#Language/System%20Functions/Su...

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.

As an administrator:

    PS C:\Program Files\j64-807> .\jreg.cmd

e.g. awkwardly, from PowerShell:

    $J = new-object -ComObject JExeServer

    PS C:\> $J.Set('numbers', [int[]](1,2,3))
    0
    PS C:\> $J.Do('answer =: numbers * 2')
    0

    PS C:\> $Result = $null
    PS C:\> $J.get('answer', [ref]$Result)
    0
    PS C:\> $Result
    2
    4
    6

or

    PS C:\> $J.Do("oops")
    21

    PS C:\> $Text = $null
    PS C:\> $J.ErrorText(21, [ref]$Text)
    0
    PS C:\> [system.text.encoding]::ASCII.GetString($Text)
    value error

[1] https://code.jsoftware.com/wiki/Guides/OLE_Automation

J FFI lib call: https://code.jsoftware.com/wiki/Scripts/CallJ and https://code.jsoftware.com/wiki/Guides/DLLs/Calling_the_J_DL... database: odbc, jd, sqlite, mysql, [arrow bindings] network services: sockets, websockets, zmq, & http 1.1 text: unicode support, names limited to asci https://wiki.jsoftware.com/wiki/Guides/UnicodeGettingStarted

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.

A list of companies using array languages is maintained here: https://github.com/interregna/arraylanguage-companies

https://www.dyalog.com/reference-customers/simcorp.htm This reference profile is really old though, numbers are way off. Anyway, APL is used in production.

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.

Isn't Formula 1 using kx/q for their extreme realtime data processing?

https://kx.com/

APL is a great language for any kind of engineer who isn't a software engineer.

check out Aaron Hsu on youtube, he works with it (finance sector IIRC)