icen

As soon as your eyes adjust to the density, I think this is actually quite legible. There are sensible names, and the formatting and arrangement serve to show the regularity of operations.

I think there are far worse codebases!

I’m greatly enjoying my Charybdis nano: the built in trackball makes using the mouse just as convenient as the keyboard

Numpy doesn’t quite get it. It covers the core verbs, but it opts for specialised names instead of using adverbs (you can apply your own, but it’s much more laborious).

Once you see +/, you understand ,/ or fn/ - whereas you have to remember that it’s written sum, concatenate, or np.ufunc.accumulate in numpy. The same goes for +\ vs cumsum etc (and you don’t get all of these pre defined).

The difference here means that whilst numpy gets the core array operations down, it’s much less convenient and less self explanatory than the apl system.

There's also the much less vector oriented spelling:

    (1 ∾˜ "  "⊸(¬∘⍷))⊸/

which removes the first space of each occurrence of double spacing

Do you remember what it was? This is how I would spell that in BQN, and you could write something very similar in APL (you don't have shift, so you'd have to write 1 drop 0 cat swap instead)

    ((«¬∘∧⊢)' '=⊢)⊸/

This works by building a boolean mask of spaces, and converting it to a mask of 'is a space, preceded by a space', negates that, and replicates out by that inverted mask (i.e. is not a space preceded by a space):

Here's stepping through it with some input.

       (' '=⊢)  "this  is a  sentence with       many   spaces"
    ⟨ 0 0 0 0 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 ⟩
       («' '=⊢)  "this  is a  sentence with       many   spaces"
    ⟨ 0 0 0 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 0 ⟩
       ((«∧⊢)' '=⊢)  "this  is a  sentence with       many   spaces"
    ⟨ 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 ⟩
       ((«¬∘∧⊢)' '=⊢)  "this  is a  sentence with       many   spaces"
    ⟨ 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 0 0 1 1 1 1 1 1 1 ⟩
       ((«¬∘∧⊢)' '=⊢)⊸/  "this  is a  sentence with       many   spaces"
    "this is a sentence with many spaces"

It's clear that the symbols want to have one meaning each, for monadic and dyadic use, but that might mean quite different execution and types.

For example, & is monadic 'where' and dyadic 'min' (a logical extension of it being AND on bit-booleans), but this means you get different semantics, even if they all capture the 'where'-ness:

    1 3 ~ &0 1 0 1 / when applied to a list, gives the indices of true elements
    `b`d ~ &`a`b`c`d!0 1 0 1 / when applied to a dict, gives their keys

In both cases, you get that `x@&x` works, as `&x` will yield appropriate indices for `x`, but what that actually does has changed. In other languages, these would be spelled very differently, and so do seem like an overload, but sometimes it is just a point of view.

As for why it's obvious- it's not, really, but it's no less obvious than the word `where`, and you have already learnt it, as it is (as it seems to me at least) to be punned on the C syntax (same as `*`, which gives `first`).

There’s nonguix for access to non free drivers and such. I think that system crafters have some installable images if you don’t have a current guix install to build one

It’s regrettable that this is necessary, but with so few Ethernet ports on laptops it’s harder to install these things without access to WiFi.

You might be interested in this then: https://mlajtos.mu/posts/new-kind-of-paper

I’ve not used it myself, but it appears to be the thing you’re wanting?

In helix that's %d (select-buffer, then delete). The selection-then-action design for helix is showing it's difference to vi, which is action-on-movement.

It is BQN, a descendant language

Yes; the CBQN interpreter has a number of specialised vectorised codepaths. It picks a good one for the arrays at runtime.

In K the arguments are named x y z by default, so you just write:

    { foo[x, bar] }

Looks like K to me!

> I didn't understand how this connects to the first paragraph at first, but I think you're saying this playthrough is an analog to someone making such documentation, thus saving DF from such a fate?

(Not OP) Possibly, but one of the repeated themes in Boatmurdered is a number of fortress defenses (some with considerable collateral damage) attached to a variety of scattered and unmarked levers.

Does pulling this lever lower the drawbridge, irrigate the fields, or douse the world in cleansing magma? Only one way to tell!

> For character-based movement, simply press 'z' to enter the column mode.

I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).

I am enjoying the editor (as a current helix user), and looking forward to trying it more.

In this respect, probably nothing, and they probably all mean Q.

Q is a different language to K, implemented in K. There are more versions of K than Q- kdb+ is the only Q implementation, but there are others like shakti, ngn/k, and kona that implement K.

Or indeed just results*:2

It returns it for 404 as well: https://http.cat/does/not/exist

I don't want to do the same things for boolean operations, or arithmetic, or pointer (de-)referencing in C like languages. Why would I want to do so when equally familiar with a larger range of symbolic operations?

Somehow the usual culprits of +-/*|^&% get a free pass on this, and are somehow less arcane than symbols like ⍋ or ⊃.

There's nothing inherent about this, it's about familiarity, and once familiar, everyone always prefers the symbols over spelling it out like plus, minus, divide, multiply...

I'm solving in BQN, and my workflow is repeatedly re-phrasing a line until it does what I want in the repl, and then naming it, and then moving on.

Most often I end up with some enormous one-liner that I then break down into functions again.

APL!

Another classic use case is that you can have expressions in the types of your function, for example this won't compile:

    stringOrInt : (x : boolean) -> int -> (if x then String else int)
    stringOrInt true x = toString x
    stringOrInt false x = x + 1

    1 + stringOrInt true 37 # this will error, because it knows you've not returned an int

The other example that you can do in depedently typed languages, but is too involved to write out here, is make a type-safe printf, where the format string produces the types for the other arguments.

Do you have any examples that come to mind of it being slow? My experience has been that I've been the slowest part of my code, by a long way.

Some optimisations aren't quite there (like under on higher rank arrays not being as fast as computing the indices on the flattened array), but everything else has been good.

All APL versions have had variable assignments, denoted by ←, e.g. `var ← 1 2 3`.

There is a concept of tacit, or point-free, programming, which avoids the variable names as parameters, for example the calculation of the mean `avg ← +⌿÷≢`. However this does become unwieldy pretty quickly, and it's easy to juggle too much. It is very useful for short snippets, where you avoid all of the ceremony and can just express the core thing you want to talk about (for the avg example, it's not improved by including a parameter: `{(+⌿ ⍵)÷≢⍵}` - the ⍵ parameter isn't informative at all, and nor would anything else, like `samples`). I think it is best to keep the tacit snippets short, and to assign good names to them.

I think if you're looking at learning an array language in order to learn an array language, because of the oft-discussed change in perspective and technique, then I think BQN meets that very handily.

BQN is, in my opinion, the most slick of the array languages; it consistently takes the best of the approaches to high-rank arrays and combinator (including tacit) programming from the others. Some things are unique, and amazing, like structural under.

It is small, it is new, so I would agree with your hesitation to start a business based on it, but to understand these languages or use it for the typical small calculations, it is more than capable.

You can download a copy of Dyalog for free, if availability is the issue.

If it's licensing/a desire to use open-source software, perhaps taking a look at its close relatives of J, or BQN, would be reasonable?

* Dyalog https://www.dyalog.com/download-zone.htm * J https://code.jsoftware.com/wiki/System/Installation/J903/Zip... * BQN https://mlochbaum.github.io/BQN/index.html

All of the languages and implementations have their differences, but they are all driving toward the same ultimate goals.

Here[0] is the episode covering BQN. Marshall has since joined the panel for the podcast.

https://www.arraycast.com/episodes/episode-07-marshall-lochb...

Since the reference implementation is in javascript, I think that the expectation is that it will run on all of the flying saucers.

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.

My reading of the piece is that it ascribes to the Copenhagen interpretation an anti-realist perspective - that is, the theory is nothing other than the ability to predict the results of experiments. In this view, there is no wave-function in reality: it is just a mathematical tool that appears to predict the dots on the screen well.

Scientific Realism holds that in some sense scientific theories approximate the world, not just in what the experiments observe, but also in the content of their explanations (precisely, you gain knowledge not just about observables, but also non-observables: things that the theory requires to be true, but can't show). The article ascribes this view to Einstein, who presumably thought that there was a such thing as space-time, and it does actually curve under the influence of mass - despite only seeing things that are explained by the curvature, and not the curvature, or the space-time, itself.

The article then goes on to say that the anti-realist approach (dominated by not-undeserving practical concerns and application) focuses on computation: the mathematics is good so long as it gets the right answers in the end, and the end justifies the means. Therefore, it doesn't matter what contrivances must be dealt with in-between: if you get a better prediction, or can do a new exciting thing, then that was always the aim.

Thus, I read the article as advocating a stepping back from this view: it blames this focus on sheer mathematical sophistication as the route to truth as the source of profound disinterest in philosophy by physicists (it is important to note that I think that aeon is a philosophy newsletter!). Earlier and contemporary physicists (prominently, Einstein) had an interest in not just what their theories produced, but what they explained the world to be, and the article decries the modern lack of this.

I recommend the SEP article on scientific realism, which is dense but on a brief reading gives enough of the context to recognise the article. https://plato.stanford.edu/entries/scientific-realism/ (Although it is even more philosophically focused).

NB. I'm not a physicist or philosopher either, so grains of salt! My only self-endorsement is that I spent the last year reading a bit of philosophy, so perhaps I can be at least a stepping-stone to better resource.

Linux has a built-in keyboard that's easy enough to configure in your DE or with an X keyboard toggle.

Dyalog has some introductory documentation on how to set up the mappings. https://www.dyalog.com/apl-font-keyboard.htm

If you want to type something very small, you could also go to tryapl.org and use the on-screen keyboard and copy and paste.