BQN: Finally, an APL for your flying saucer
mlochbaum.github.io
mlochbaum.github.io
The author of BQN, I believe, is frequently on there and I think I remember it being discussed pretty in-depth in one episode.
https://www.arraycast.com/episodes/episode-07-marshall-lochb...
> "APL"+1
"BQM"
Overall looks interesting and definitely worth a play with!Also check out BQNPAD[1], the online BQN REPL built with codemirror (syntax highlighting, history).
The other (and main) implementation is in C, so I think between the two you shouldn't worry about BQN compatibility when choosing your saucer.
As I consider the glyph stuff to be a detraction, my question is: why insist on the glyphs? Is the ideal of writing functions on a single line worth stopping the wider public from using this?
I for one won't be trying this out, I'll scan the docs for just the ideas instead.
[1] https://mlochbaum.github.io/BQN/doc/syntax.html#special-glyp...
[Edit: https://bqnpad.mechanize.systems/ shows there are still a lot of symbols. The question remains, why not use keywords or compositions like =/= instead?]
As for why use glyphs - setting up the keyboard & learning the glyphs is largely a one-time cost, but reading & writing digraphs/trigraphs or words is an ongoing one.
Ligature fonts are an option, but then you're back at having to learn glyphs, now in addition to learning the raw ASCII to write (and also read in places that don't support custom fonts).
Names/identifiers have the problem of where you draw the line - addition/multiplication/comparison/etc should really have their own glyphs, but, given that BQN is an array language, many array operations are equally as much, or more, deserving of having glyphs too.
It's unfortunate that the slightly steeper learning slope can drive people away, but I believe the glyphs are enough of a benefit in the long run that going with them is a valid option even if that means reduced adoption.
As usual I don't know where to start, ideally open source. I'm stuck on whether it's J or BQN. J is ASCII, BQN has the traditional unicode glyphs. I do like the fact BQN is newer so can pick and choose the best of the array languages though.
J also has far better educational materials than the others.
Any reason you're not considering APL?
I've personally found it the nicest set of characters - BQN's too spacey for me :)
I don't really get why none of those languages beside K/Q have associative arrays though. There's a reason why even Go has them : they're used all the time. Even better with Q, it automatically transforms your dictionaries of arrays into arrays of dictionaries so you get good cache locality while being able to bundle related data into a dict as if it were a struct.
I think you have Q's transformation backwards (a table is a "flipped" dictionary of lists, that is, a list of dictionaries all with the same keys, represented as a dictionary of lists). Obviously it's good for databases, but I don't think every field benefits from this representation. With objects, users can implement such a thing for themselves.
Documentation for the array display at https://mlochbaum.github.io/BQN/doc/arrayrepr.html.
It’s hard enough to find curly braces on a German keyboard (that’s why I usually use US layout).
I think it’s similar to why Ruby was invented by a Japanese: you need to simplify the syntax of the language if your keyboard doesn’t show it. Vi was created on a keyboard without arrow keys, that’s why hjkl was chosen for cursor movement.
As for typing, there is usually a prefix key (like a leader in vim) followed by a single character to insert one of the symbols. It might actually be easier than hunting for the curly braces.
[0] https://mlochbaum.github.io/BQN/tutorial/list.html#and-modif...
Front page calls it the 'dreaded' compiler.
Jokes aside, this is really cool. Vscode support is much appreciated.
Languages like Haskell scratch that itch now.
We're at danger of losing the patient, extraordinary measures are welcome. I for one embrace any experiment at saving APL.