What is Big Question Notation? Also, which flying saucers does this support? I haven't bought one yet and I want to make sure the one I buy is compatible.
I wonder if apl family languages would be particularly suited for structured editing. You need anyways some editor magic to input the symbols, so it's not that big of a stretch. And from the little I've seen, the syntax tends to be relatively simple and regular.
There is sufficiently little structure as to make such a project much less interesting than the analogue for another language might be. Not to discourage anyone from structural-anything, of course—text is tyranny.
I welcome new APL-class languages. BQN seems promising as, apparently, only a few glyphs remain, see [1]. For example there is a special minus sign for use in numbers (why can't this be inferred?) and there are symbols for infinity and Pi, which are identifiers in other languages. On the other hand, characters like / and \ don't seem to be used.
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.
[Edit: https://bqnpad.mechanize.systems/ shows there are still a lot of symbols. The question remains, why not use keywords or compositions like =/= instead?]
The syntax/"Special glyphs" page shows glyphs that specifically aren't builtins (i.e. functions & modifiers, which include your regular +-÷×, among many others).
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.
I think they were asking about using terse symbols in general, as opposed to words in English (or some other language) like most other programming languages.
I'm intending to learn an array language at some point. Im an avid listener to the Array Cast podcast.
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.
Glad to see this has some vscode support now. I wonder how well it displays arrays though. I used the TimeStore Q editor last year while doing advent of code and the ability to display nicely at least 2d arrays was a game changer when playing around with it.
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.
There are some consistency issues with multidimensional arrays versus dictionaries, so BQN will eventually support these as system functionality. See https://news.ycombinator.com/item?id=31367355.
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.
Obviously this has a prestigious pedigree, considering the author, but I am having trouble understanding what differentiates it from, say J. I see that the operators are written out and it is built in Go, but other than that what is the benefit? Just the fact that the operators/verbs are written out in words?
For me it’s definitely about writing out the operators names. I’m German, I often use a German keyboard layout. I have never been good with Greek math symbols other than pi and SUM and PRODUCT. How am I supposed to write the APL or BQN symbols and understand what they mean ?
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.
I assure you that you will pick up the meaning of the symbols more quickly than you imagine.
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.
Wow, the tutorial seems a breeze in its initial parts, written in a really approachable tone. Also, the amount of new weird characters to learn does not feel overwhelming - at least with how they're introduced. That said, I stumbled upon somewhere around the Each modifier (IIRC); I'll maybe try to consider asking the author if they wouldn't mind editing this part to slow it down a bit and explain in simpler steps.
I'm here! I can see that this section[0] goes pretty quickly over the two-argument form of Each, and the pace for Fold looks better to me. Is that right? The example section after could be pretty hard; the idea is that you should be spending a while thinking about it and working through the code in a REPL.
Its architecture is super interesting, though. It's built along the principles of Dr Aaron Hsu's thesis, encoding trees as vectors of pointers to nodes.
When I gained access to an APL terminal in 1975 I was coming from FORTRAN punched cards on an IBM 1130 (think Apple ][ but dumber and half a room, shared by my entire college). APL blew my mind. I worked one summer as a commercial APL programmer, and we ran circles around our client's in-house FORTRAN shop.
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.
The author of BQN, I believe, is frequently on there and I think I remember it being discussed pretty in-depth in one episode.
[0]https://www.arraycast.com