mgunyho

Yep, I think in Taka the most confusing case is lists - writing

    list [
     1
     2
     3
    ]

creates the list [3 2 1]. (When indexing, the first item of the list is the one on top of the stack.) This has tripped me up several times.

PN makes it appear more like a traditional programming language on the surface, even if it's still read in a kind of strange way. So it might help spread the joy of stack languages by seeming more easily approachable. For me personally, RPN is still unfamiliar enough that this kind of PN feels more comfortable.

For Torch, I have come across Named Tensors, which should work in a similar way: https://docs.pytorch.org/docs/stable/named_tensor.html

The docs say that it's a prototype feature, and I think it has been that way for a few years now, so no idea how production-ready it is.

Seconded. Xarray has mostly replaced bare NumPy for me and it makes me so much more productive.

I want to second the idea of broadcasting based on named axes/dimensions. I think it's a logical next step in the evolution of the array programming paradigm.

I particularly recommend checking out xarray. It has made my numpy-ish code like 90% shorter and it makes it trivial to juggle six+ dimensional arrays. If your data is on a grid (not shaped like a table/dataframe), I see no downsides to using xarray instead of bare numpy.

The pro version of Overleaf supports offline work with a simple trick: every Overleaf document can be accessed as a git repo. It's a bit limited (there's no branches or tags, and it breaks the "track changes" feature) and trying to convince the average researcher to learn git is a challenge, but if you know git it works quite well.

Looks very similar to my tool, tere: https://github.com/mgunyho/tere. The main difference seems to be that I don't do any file manipulation, while walk has the option to delete files/folders. In my implementation, you don't need to type '/' for fuzzy search, just typing searches and jumps by default.

I also have a list of similar projects at the end of the README, I'll add this as well! edit: Oh I already had it in my list, the project has just been renamed from llama to walk.

Hmm, this indeed seems to be the case! I think I was confused by ln(1), since 1 is a real number, but the multi-valued complex logarithm of 1 is indeed k 2pi (and now I see the appropriate notation should be "log" instead of "ln"). Perhaps the whole thing could indeed be reduced to "1^x" with an asterisk that 1^x means complex exponentiation. I'll have to update this section in the post.

But note how right above this span there is the <span class="katex-mathml">, which is not aria-hidden, and which contains the MathML representation of the equations. I would have assumed that a screen reader would look at that, since it contains the semantical information.

Yes, I manually put 2π in the html <title>, while the <h1> has the KaTeX rendered math in it :)

Not a coincidence :)

> sin(x) is the sinus function with the angle implicitly divided by 1 radian

This to me sounds like the most natural explanation. For example, in a sibling comment someone mentioned that "you can calculate e^(-t)", but I disagree: in physics it's always e^(-t / T), where T is some time constant, so that the argument of the exponential is dimensionless. Same applies to sin(x): usually we write something like sin(2pi f t), where the units of f and t cancel out, and the 2pi is there to cancel out the invisible implicit 1 radian. sin(ft) would be wrong, at t = 1 / f you wouldn't have advanced by a full cycle.

I think parent is referring here to the fact that math used to be written without symbols (other than numbers) up to the 1300s according to Wikipedia: https://en.wikipedia.org/wiki/History_of_mathematical_notati... (very interesting article!) However, I would say that there is a reason why notation tends towards terse symbols: it's much more efficient and unambiguous.

From what I can tell it's the opposite (on Firefox): the math is in the source HTML twice, once in <span class="katex-mathml">, which is hidden using CSS in the non-reader mode but is rendered in the reader mode, and <span class="katex-html" aria-hidden="true">, which is what FF displays normally, and it's missing from the source when I inspect it in reader mode. Having two spans like this comes directly from KaTeX, whose authors I'm sure have thought about accessibility. I imagined that MathML would be somewhat standard and screen readers would understand it.

> You can also eliminate the constant in some of the integral formulas by using đx instead of dx. I'm surprised the author does not propose this.

In the post I propose doing that for Gauss' theorem and Cauchy's formula, because there it's convenient, heh. But to me it feels better to use Θ^ix than a scale factor in front, since the 2pi is always present in the exponential, while the prefactor can be avoided in Fourier transforms if you keep the 2pi in the exponential (or hide it inside Θ). Does this not apply also to the elementary formulas you mention?

Author here, I'm sorry to hear that it doesn't work well with a screen reader. I tested it with the reader mode of Firefox, which renders MathML perfectly, although I don't know how that would translate to a screen reader. Safari reader mode renders the math inline, like this:

   I just define a new derivative operator, like so: dxđ f(x)≡2π1 ⋅dxd f(x). That’s all.

while Chrome's reader mode just fails to recognize the content entirely, even though it's the most basic <body><div id="content"><p> ... structure possible. I have basically zero web dev experience so I don't know how to fix this, maybe I need to tweak the KaTeX settings.

I think it's quite sad that math is so difficult on the web. While setting up the blog, I looked around and it seemed like FF is the only browser with proper MathML support, but I think that was also being phased out because it's apparently buggy and hard to maintain. IMO, the screen reader version should just basically be the LaTeX source, which is probably kind of awful when read out loud, but at least it would be unambiguous.

That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule.

I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

Also, aho-corasick comes from the name of this algorithm that is named after its inventors https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm

Not really. The main reason for choosing Rust was to try it out, because it's the new cool thing. And I do find it really enjoyable. Rust is also trying very hard to keep dependency-related breakage to a minimum, and I think the Cargo ecosystem is doing a great job at that.

> one extra keystroke is hardly cumbersome

To me, there really is a significant difference in friction when navigating in vim vs tere. Maybe it's because I need to use shift to type '/' on my keyboard layout. But I also have to press enter twice to cd after searching.

The point about opening the files within vim is valid, and I have been considering adding the option to call xdg-open on highlighted files, like many such tools do. I haven't decided yet if that's within the scope of tere.

> It's just a common problem so you'll probably find a lot of people have already solved this with other tools

I agree, and indeed there are a lot of existing alternatives as mentioned in the README. The main motivation for me was to make something that works just the way I want, and secondarily, to write something fun in Rust.

Nice! Looks like xplr can indeed "integrate them all", as you say in the readme.

As mentioned in another comment, vim doesn't provide exactly the same experience: navigation is more cumbersome because you need extra keystrokes for type-to-search and to cd a folder. It also requires some extra tinkering for vim to print out the cwd when you exit.

You need to configure a shell function to actually do the cd (see the snippets in the README). It has to be done this way because a subprocess cannot change the pwd of the parent.

Indeed, this looks very similar! I added it to the list in the README.

To compile it, I had to sudo apt-get install libacl1-dev, which was not mentioned in the instructions.

I was well prepared mentally for the HN cynicism, and I did spend quite a bit of mental energy to justify the existence of tere to myself. Luckily I have a good rebuttal: I already use vim! :)

Nice, looks like this is indeed very similar to tere! I guess the biggest difference is that the current search is not as "sticky", looks like it's cleared automatically after a while, which is similar to the behavior of the windows file explorer. I added it to the list of similar programs in the README (it's in the develop branch for now).

I would say that terminal explorer is what I had in mind initially (and incidentally, I also speak Finnish, heh). But a misspelling of tree is certainly a valid interpretation as well :)

Thanks for the kind words! :)

While digging up alternatives (of course after I had already written most of the functionality), I briefly tried out fzf. I think at that time I couldn't find an example snippet like yours to do the cding, so I didn't look into it much more. With some basic settings, it was also not easy (or even possible?) to go up in the folder tree, but I see that your example handles that.

If you're unfamiliar with a big folder tree, fzf (or another very similar tool that is designed for this purpose, broot) can be more efficient. But it might take a while for it to scan all subfolders.

I'm a fast typer, and I understand where you're coming from! But note how there's a small (200ms by default but can be configured) delay when the auto-cd happens. This is actually pretty important, because otherwise it's impossible to see where you cd'd to. Importantly, during this delay, the keystrokes are eaten (so they are not fed down to the next level), and from my experience this is enough to basically never accidentally cd in the lower level.

The auto-cd can also be turned off with a CLI option.