For some time now, I've been thinking about the concept of interactively manipulating mathematical expressions and equations via software. Like doing some quick algebra in Notepad or similar, except there's no potential for arithmetic/algebra errors, typos, etc. ruining any results.

At the same time, I also wanted to experiment a bit with zippers from functional programming. You need some way of specifying what (sub)expression to perform operations on, and it seemed like this kind of data structure could help with that.

And so, I made AlgeZip, a small proof-of-concept of the whole general idea. Although this polished Python version was completed only a few days ago, there were various other versions before this one in different languages and with worse-quality code. Instructions for things are on GitHub; requires Python 3.12 to run.

For simplicity, I decided to use boolean expressions instead of generic numeric algebraic expressions/equations, and only decided to include the minimum in terms of commands and functionality. From my understanding, it should be possible to transform any boolean expression into any other boolean expression in AlgeZip (without using the r! command except to set things up), though I could be wrong.

Thoughts, comments, and criticism on the idea as a whole, the program, or the source code are welcome, though I'm not sure if I'll be making any changes at this time.

[This was originally one of my posts on r/javascript from 2 months ago. Aside from the first few sentences, no edits have been made to the contents of the post.]

I'm playing around with concepts for a Javascript-inspired programming language, and I was met with a design decision:

When destructuring an object, should we pull from the object's entire prototype chain, or only the own properties (not inherited from the prototype chain) of the object?

In other words, in the equivalent to this line of code:

let {a, c, ...rest} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}

Should [a, c, rest] be [0, 2, {b: 1, d: 3}], or should it be [0, <not assigned>, {b: 1}]?

On one hand, we probably don't want to pull from the object's entire prototype chain. Imagine if, after executing let {a, ...rest} = {a: 0, b: 1}, Object.hasOwn(rest, x) returned true for x = isPrototypeOf, toString, valueOf, etc and all of those properties were just the same functions as the ones on Object.prototype. And imagine how inefficient destructuring would be when we have long prototype chains with many properties on each prototype.

On the other hand, in something like let {a, b, c, d} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}, we probably want c to be 2 and d to be 3, the same way <rhs object>.c would be 2 and <rhs object>.d would be 3. So we would want to pull from the entire prototype chain after all.

I decided to look at how Javascript itself dealt with this stuff (not what I actually put into the console, but it gets the general idea across):

>>> let {a, c, ...rest} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}; [a, c, rest.b, rest.d]
[0, 2, 1, undefined]

It turns out that Javascript uses a hybrid approach: for ordinary properties like a and c, it searches the entire prototype chain. But for rest properties like ...rest, it only uses the object's own properties.

I wasn't expecting this inconsistency between the two types of properties, but it makes sense: each individual type of behaviour is probably what you want for the corresponding type of property. You would want to search the entire prototype chain when it comes to ordinary properties, but at the same time you would want to only look at the object's own properties when it comes to rest properties.

What do you guys think? Does Javascript handle this the right way, or should it have chosen a different approach? Maybe there's another, better option than all three of the approaches that I outlined here?

[This is a rewritten version of a post I made on r/Kirby 8 months ago.]

One day, I came across the following passages in Elfilin's character entry on TV Tropes (final entry under "Other Heroes"):

Cosmic Motifs: According to the official guidebook, Elfilin's ears were designed to resemble the waxing and waning of the moon. This was meant to represent "having lost the quality of a single existence", that is, having separated from Fecto Forgo.

The Fog of Ages: According to the official guidebook, he barely has any memory of his time as a test subject in Lab Discovera anymore.

At the time, I wasn't able to find anything else that talked about this information. At some point, I checked out this official(? It's official enough for WiKirby.) guidebook myself. This is the relevant page (it's also the final page in the preview).

My attempt at a transcription of the relevant passages (I can't read Japanese):

ともに旅をしながらアドバイスをくれるカービイのパートナー。本人の記憶にはほとんど残っていないが、ID-F86の中に残されていた小さな博愛の心が分離して生まれた存在で、かつて研究者たちには"ID-F87"と呼ばれていた。再び融合することを目論むID-F86によって、とらわれの身となってしまう。

月の満ち欠けをイメージしてデザインされたという耳。1つの存在だったものが欠けたことが表現されている。

Based on machine translations, the TV Tropes descriptions seem pretty accurate. And according to a commenter on the original Reddit post, in the Kirby light novels (separate continuity from the games, so take the implications with respect to game canon with a grain of salt), Elfilin also doesn't remember Lab Discovera. So that's some not-so-new-at-this-point-but-still-not-widely-talked-about Elfilin lore for you.

I haven't actually played Deltarune in quite a long time, but this community needs some more posts, and I'd like to do my part for that.

For Deltarune's teacup rides, the left key makes you go clockwise and the right key makes you go counterclockwise. This way, when you press left/right from the starting position (bottom), you go in that direction.

But I was more used to pressing left to go counterclockwise and pressing right to go clockwise, the same as the controls for Super Hexagon (and its predecessor Hexagon, which is how I got used to those controls). This way, you go left/right when you press left/right from the top instead of the bottom.

So in my latest playthrough, I swapped the left and right controls in the settings whenever there was a teacup section. Actually made those sections quite a bit easier for me.