Still hoping for someone to design a font for J with ligatures so it can match APL's beauty for reading without making it more difficult to type, i.e. automatically rendering /: as ⍋, |: as ⍉, |. as ⌽, etc.
Keyboards are awfully similar to how they were in the 90s, is I think the salient point. Representing the symbols in the source isn't now an issue really, but typing them still would be.
Typing symbols is not really an issue. First off, you can configure your text editing environment to automatically replace digraphs with their associated symbols (e.g. when you type i. replace it with ⍳ automatically). But second of all, memorizing an alternate keyboard layout isn't that big of a deal. Is it really harder to remember that grade up is super+shift+4 (⍋) than that it's slash+shift+; (/:)?
I would argue that difficulty in reading code and knowing what symbols represent what operations is a much more pertinent consideration. And though neither is especially mnemonic (can you really have a mnemonic for something as abstract as 'sort'?), it's much clearer that single-character grade down (⍒) is the reverse of single-character grade up (⍋), than for digraphs (/: and \:). (It's also easier to parse symbols when they're only one character.) Not least because unqualified / and \ represent very different operations—the first is reduce, and the second is either scan or prefix—as do /. and \.; so there's no precedent for it.
And so, assuming you accept the obvious superiority of graphical/unicode representation of symbols, the digraph method for typing them becomes superfluous. You now have to associate the mental concept of grade with two completely separate representations: the graphical representation of the completed character (⍋) and the ascii representation which you type (/:). You can't escape the latter, because every time you type a grade, you'll see the '/' on screen for a moment before you type the ':' and the character gets digraphed.
I mentioned in the beginning that you can configure your editor (and repl) to automatically replace digraphs with their associated symbols (so /: automatically gets replaced with ⍋). On face, this seems functionally equivalent to the ligature suggestion, but it's not. Mainly, it affords flexibility. If you want to type digraphs in your environment, you can, all my criticisms aside. But I can configure my environment to use an alternate keyboard layout, avoid complicating my editor environment by introducing ligatures, and we can work together seamlessly. Doing it that way also adds flexibility to the language; if ⍋ is the single canonical representation of 'grade up', and / and : are separate symbols with their own unique semantics, then they can be freely juxtaposed. It'd also be somewhat of a pointless indirection, to have ascii digraphs underlying what are essentially unicode-pictorial representations.
(Note: I said only 'digraphs', for clarity, but everything I said applies also to trigraphs, of which j has a couple.)
It looks to me like you see no difference between "I need to configure my environment" and "my environment is already configured by default". But, from my point of view, the difference is very important.
I like being able to type some J (or, most times, some K) in an email, in a note I take in my phone, in a comment of a C program, ... Yes, I could configure my environment(s) to do all this with a custom input method, but being able to do it with anything I find without any configuration is a huge advantage.
I don't know J, but an APL keyboard layout is not a problem for any major current OS, nor is a layout with ISO Layer 3 (Mac Option, Windows AltGraph) mnemonically allocated to useful symbols.
Though modern "emoji pickers" have extended the range of IME and soft keyboard tools that regular users use (often daily). I've been joking that the next APL is probably made from emoji, but it's not entirely a joke: the Windows emoji keyboard (Win+. or Win+;) has a pretty full Unicode math symbol section (click the Omega top-level tab and then flip through the bottom level tabs), and while it is missing some of the nice search features of the more colorful emoji, gives relatively quick access to a lot of options.
Is it more demanding than asking them to memorize a collection of (mostly arbitrary) ascii symbols and digraphs? If you learn apl, you have to remember that grade up is ⍋ (s-S-4); if you learn j, you have to remember that grade up is /:. The primary barrier to entry is remembering what operations you can do and how you can do them, not how to type them.
> Requiring users to memorize a second keyboard layout is very demanding
Not really. It's a natural learning process as you learn the language. Very easy. If you are truly learning the language (rather than just messing around) you can get to the point where you are comfortable typing most common symbols in a week or two.
I used to touch-type APL back in the day. Even though I don't use APL at all these days, every so often, when I do, I am amazed by how quickly I remember where the various symbols are on the keyboard. Some of it just make sense, for example "iota" is shift-i, "rho" is shift-r, etc.
I have been working on a "modern" language based on APL.
It implements features such as macro-like custom syntax, first-class functions and closures.
It's developed in Kotlin and can be compiled to the JVM as well as natively using the new Kotlin multiplatform feature. Javascript will also be possible once Kotlin multiplatform supports reflection. The project is still nowhere near finished, but it can at least run Conway's Game of Life:
Not only does it have it, it has it in (what I feel) is a really accessible way. Seen a symbol and you don't know what it is or how to reproduce it? Enter "?" and paste them symbol into the repl and it'll tell you what's it's called, the shortcut to make it, what it does, and the equivalent non-symbol function name.
And while not exactly what the parent asked for, the recently released "JuliaMono" font has ligatures for several common combos - including the right arrow - which amounts to practically the same thing:
I've been using Dhall ( https://dhall-lang.org ) and it does this. But it goes a step further: because `dhall format` defines the canonical form of any dhall code, it does the unicode substitution for you. So you get convenient entry with a normal keyboard, plus nice unicode symbols in code.