Hacker News Reader

Comment by JaumeGreen | Hacker News Reader

I'd love to learn APL, all the symbols give it some mystic aura that make you feel as if you were reading a magic scroll, rather than mundane source code.

OTOH J is great because it's easier to dive into, no strange keyboards needed. Also it might be one of the best language to use in a phone. With their own keyboard and a nice app, it's the first time I found that while working on advent of code problems during commute the interface was not the problem.

But that language has a big big problem, it is not search friendly. Not on internet, not even on a page with solutions on different languages.

View on HN

I'd love to have a language that combines the notation of APL with the ergonomics of J (ie. hooks and forks enabling functional-ish programming, a de facto open source implementation and a working Android "IDE").

I just use APL for learning, but Dyalog APL provides hooks, forks, and various other operators (like @) for supporting functional programming. Their RIDE effort supports a linux IDE, but not an Android one AFAIK.

I personally find the APL notation substantially easier to start with over J because each symbol is more mnemonic for what it does and because each operator uses a single symbol which helps a lot with mentally tokenizing.

There's the fully open source GNU APL which compiles on Arm Linux in addition to Linux, OpenBSD, MacOS.

I don't know what is needed to get from Arm Linux to Android.

dzaima/APL (https://github.com/dzaima/apl) has an Android version. I would recommend that over GNU APL which makes a number of questionable language choices.

Many modern APLs—Dyalog APL, NARS2000, ngn/apl, and dzaima/APL—include support for forks. They're usually called function trains in APL.

Seeing as I am not an APL guru, I would appreciate your comments on the language choices that you don't agree with.

The one that should stand out to programmers in other languages is using dynamic scope instead of lexical scope for its anonymous functions, even though they were based on Dyalog's dfns which are lexically scoped. There are other more APL-centric issues such as even more questionable use of square brackets than the typical APL.

I work for Dyalog which is a "competitor" (in practice, the APL market share is small enough that any APL doing well helps us all). We have a lot of respect for other APL implementations and frequently use their choices as reference points for our own decisions. GNU is the only exception.

Thanks for the tip and for telling me about function trains.

Also great work on Dyalog, which I had a personal license to back when I experimented a couple of years ago. I can't recall what my problem with GNU APL was but I quickly found it too painful to try and learn with.

Put the following into your search engine of choice and it will probably be a lot easier to search for:

site:code.jsoftware.com/wiki

For what it's worth, your standard Xorg installation includs an APL layout (with several variants, actually). Something like this is pretty workable:

    $ setxkbmap -layout us,apl -variant ,dyalog -option grp:lswitch

You just need to spend a little time learning the layout though.

I wonder if using font ligatures would be the best of both worlds, but in this case this font would have to be very specific to J.

You could probably get a long way with the APL character set. Many (not all) J verbs correspond pretty closely with APL verbs, at least in one of their modes: ⍋ = /: , ∊ = e. , etc.

Thats an interesting thought. I wonder if we could do visual representations similar to "skin color + thumbs up" == colored emoji to essentially convert operator + verb combos into ligature type single characters. Would help with visual parsing/reading as well.

On a separate note, I think APL is well suited to both drawing based and voice based creation of programs on ipad like devices. I'm playing with this a little bit right now but will take a while to have something useful to others.