What domains are they used in? I've learned a little bit of J but got put off because most people involved with J seem more interested in using J for the sake of using it rather than actually doing anything substantive with it. My impression is that APL is similar (at least currently) but I'd love to be wrong.

I got into J in the '00s, it was interesting. The community was making substantive stuff, but they were making it for themselves more than for anyone else. I noticed a lot of teachers in the mailing lists. They were making tools that helped them track grades and attendance. They were generating quizes and worksheets from question banks that they produced over the years. They were creating puzzles for their students. All of this was substantive, but it was focused on their ability.

J (and APL) really seemed to be an extension of what computing could've been. As a computer scientist and programmer, any language and OS work for me. I want something, I make it. I can write an app in C or C++ or Java or Lisp or Erlang or... because I have the background for all of that. For most other users, they have to find a program that accomplishes their need, or maybe they do it in Excel or Google Sheets. But in the past we had an idea of interactive languages that were the main interface for the user. The user could then produce the things they needed to meet their needs. They didn't need me, the CS guy, they could produce at least a functional prototype that met the need for the day. Then over the years they'd tweak it, add more, grow it into something comprehensive, or it reached a natural limit (due to complexity or meeting requirements).

J and APL are from that branch of computing. We've hidden it in our OSes (to varying degrees), encouraging people to buy programs that accomplish X rather than providing them an environment to produce their own programs to do X. The APL family of languages makes it front-and-center about the user accomplishing their needed computations and activities.

I think that we actually already have something much like the alternate world you describe - linux distros.

The posix shell language is amazing at what it does. There is no language in existence in which it is as easy to fork and exec two programs with different collections of arguments and connect their standard streams together. In fact, it's so easy to do those things that these languages have been universally adopted, bare and raw, as both the first and last user interface that experts reach for when operating a computer. I log in to a posix shell, I use it to find files and launch programs and deploy software and talk to people, and I depend on it when civilization has fallen and I need to re-establish operation using only what I can scavenge in the howling emptiness of my bootloader's recovery console.

At the same time, these shell languages are in many ways objectively terrible. They're practically made of subtle unexpected behaviors, their provisions for modularity are terrifying, and they're so deeply baked into so many things that they're past ossified and well on their way to fossilization. Google's style guide for bash [1] draws the line at 100 lines of code - if you have that much logic you need to switch to a better-suited language now.

But there are situations where people couldn't follow that rule. As pointed out by the Oil Shell project [2], most linux distros are almost entirely sh codebases. And I think that these give us a good view into the kind of alternate world you're looking at. They grew that way because they are the result of hundreds or thousands of people over the course of decades using the language as their main interface, building functional prototypes interactively and then tweaking and packaging and adding functionality until they became comprehensive or capped out. And then people adopted those tools and they became part of the operating system. I guarantee you that /etc/rc can trace its origins back to some angry sysadmin deciding that this whole "booting the operating system" thing was too much work and needed to be automated.

Personally, I think that there's a reason we went the direction we did. In some ways, languages like APL and sh are neat. I can, in fact, use bash as a core interface for sysadmin tasks. But at the same time, I've seen some pretty horrifying code in my time as a programmer, and I find shell scripts in /etc/ that near the top of the list. These hyper-expressive interactive languages are fantastic for their purposes at the cost of their performance in other domains. It might take me an hour to get twenty lines of bash working safely and reliably, and every moment of it I'm thinking to myself, "there's a better way to do this, I should just use $other_lang".

1: https://google.github.io/styleguide/shell.xml?showone=When_t... 2: http://www.oilshell.org/blog/2018/01/15.html

APL is for numerical programming with vectors, matrices and so on.

Prolog or Datalog is best when you deal with logic, complex rules, deduction, configurations, graph manipulation, or search. For example, Microsoft used to have embedded Prolog that chose the right combination of libraries and drivers when you installed their OS.

Yep, Prolog is pretty great for that kind of thing. I'm working on a project right now where I'm using Prolog (via tau-prolog) in the browser to determine permissible input options based on the user's existing selections. I'm also using it (via https://github.com/mndrix/golog) to apply those restrictions on the server, and to calculate the pricing for a configuration. In most cases I'm generating Prolog code from a collection of tick boxes, but for complex campaigns I can dig in and write a specific implementation of the required rules. Very flexible.