I tend to think about APL as an alternative to R. When working with array-based datasets it's a very nice tool to use.

APL has a small number of very flexible operations, and the key to using APL efficiently lies in understanding these primitives to achieve your goal. Once you learn them, it's more comfortable to use than learning all the intricacies of the R language.

I wouldn't recommend anyone writing a full application in it though. But then again, I don't think anyone uses R for that purpose either.

As an example (which I believe I mentioned last time APL came up on HN) is that one of my solutions to last year's Google Code Jam was a single short line of APL, but then there was about 20 lines of supporting code just to load the dataset and format the output so that is exactly matched the correct format for the submission.

Hmm, I don't know APL or R, but I suspect I could have substituted "Numerical Python" for "MATLAB" for "R" in your post and have left the meaning almost unchanged.

Is my suspicion correct?

BTW: A mere 20 lines for format conversion is very good. Although by APL standards, it might be terrible.

Very likely. I used R as an example since it conceptually is very similar to R in the way it treats arrays, and also since it's not something you'd use to build full applications.

I dunno how widely used it is, but there is Kdb+[1], “a column-based relational time-series database” built on the K[2] language, a descendant of APL. I mainly see J[3] used for code golf, but at least that means a decent number of people know it.

[1]: https://en.wikipedia.org/wiki/Kdb%2B

[2]: https://en.wikipedia.org/wiki/K_(programming_language)

[3]: https://en.wikipedia.org/wiki/J_(programming_language)

kdb is great, basically it combines an APL like language and a database, which is very cool as you can easily push your calculations to where your data lives:

http://www.timestored.com/kdb-guides/kdb-database-intro

If you want to dive in and try it, I've also made a video tutorial here:

http://www.timestored.com/kdb-guides/getting-started-kdb

Even if you don't use it, it's an interesting language to study as it's significantly different to the common java/python etc. The one drawback is that for commercial use it's very expensive. Other "modern" APL like languages that are available free include J and kona (open source K).

Kdb+ is incredible. It blows away any of the current attempts at time series data stores out there (eg; InfluxDB, OpenTSDB). Unfortunately, Kx Systems failed to allow it to reach mass popularity by keeping licenses extremely expensive. Startups simply can't afford to outlay $100k+/year for a tiny cluster.

I wonder if anybody compared Kdb+ with Jdb, a J DB system.

I tried googling this awhile back. I assume kdb+ is closed source?

I used to work at a large insurance company as an actuary, and although it's dying out, there's still APL code modeling insurance products in use. One of my jobs was to add the new years' assumptions into arrays.

Isn't the inventor of K+/Q currently writing his own operating system? Haven't heard any progress about that in a long time, hope it actually gets some use. Sure, won't be the next Linux, but maybe more than the next ColorForth.

ColorForth is not an OS. For C. Moore, an Operating System is a non-thing.

That's splitting hairs a bit. If I boot into an programming system that lets me operate the computer, I'd call that an operating system. I don't see a significant difference between ColorForth (or other native forths) and e.g. home computer Basics, Oberon or even Lisp Machines.

And more to the point, I wouldn't assume that kOS would be closer to Unix/Windows than Forth/SmallTalk/Mesa etc.

Your definition is simply not usable. By this definition, a bootloader is an OS, the BIOS is an OS, etc. All it needs is to force a little bit the interpretation of "lets me operate the computer". Just because "it" doesn't need an OS to run, it doesn't have to be itself an OS.

I think the issue is that there's no name for that kind of software which are just programs that run on bare metal. So everyone just call it an "OS" - including embedded system software vendors even though what is being sold is really just a library.

But often you have no kernel, no drivers, no resource management, no filesystem, no processes... All features one would expect from an operating system.

Furthermore, operating systems in the generally accepted definition are not supposed to include an interpreter or a compiler. They are not supposed to be interpreters or compilers.

So that's not hair-splitting at all. Those systems are really distinct from operating systems.

Chuck Moore writes one for every project.

That's a deep misunderstanding of what he does. When you run a single process on a single hardware, you don't need an OS.

Slight sarcasm, but he has written several before I'm pretty sure and does deserve his rather mythic status.