But don't think that necessarily means we are in a Many-Worlds. I rather think that we don't have enough knowledge in this area. Assuming we live in a simulation, an alternative explanation would be, that unlikely branches are not further simulated to save energy. And in this case, superposition is just branch prediction :-)

I assume the following happens: while a (small) subsystem is in "pure state" (in quantum coherence), no information flows out of this subsystem. Then, when measuring, information flows out and other information flows in, which disturbs the pure state. This collapses of the wave function (quantum decoherence). For all practical purposes, it looks like quantum decoherence is irreversible, but technically this could still be reversible; it's just that the subsystem (that is in coherence) got much, much larger. Sure, for all practical purposes it's then irreversible, but for us most of physics anyway looks irreversible (eg. black holes).

[1] https://topps.diku.dk/pirc/?id=janusP

Maybe you meant sorting. You can implement sorting algorithms, as long as you store the information which entries were swapped. (To "unsort" the entries when running in reverse). So, an array that is already sorted doesn't need much additional information; one that is unsorted will require a lot of "undo" space. I think this is the easiest example to see the relation between reversible computing and thermodynamics: in thermodynamics, to bring "order" to a system requires "unorder" (heat) somewhere else.

There are also examples for encryption / decryption, but I find compression and sorting more interesting.

[1] https://topps.diku.dk/pirc/?id=janusP

[1] https://en.wikipedia.org/wiki/Janus_(time-reversible_computi...

I think simplicity is better. That's why Json is used nowadays, and XML is not.

[1] https://www.w3.org/TR/xpath-31/ [2] https://jackrabbit.apache.org/oak/docs/query/grammar-xpath.h...

I have the same feeling. The root of K is APL, but to avoid special characters (I assume), the same symbol has multiple meanings (overloaded), depending on eg. the position, the data type, and the context. The idea is that "programs should be short enough to fit in your head." The challenge is, similar to Perl and Regex syntax, it's very hard and often cryptic to read.

I do think a concise syntax is useful, for a programming language. But at the same time, the syntax should be readable, and that probably means that each symbol or operator must only have one meaning, and that meaning should be (more or less) obvious.

K is an array language. Even an integer is actually an array of one element. I think that makes sense for a tiny language: This is the simplest possible type system. You can even support strings, when using eg. metadata or using a heuristic like "a string is always zero terminated" (which is what I used for my tiny language).

I'm arguing for integer / and %, there is no need for an explicit "non-zero integer" type: the divisor is just an integer, and the compiler need to have a prove that the value is not zero. For places where panic is fine, there could be a method that explicitly panics in case of zero.

I agree an annotation / effect system would be useful, where you can mark sections of the code "panic-free" or "safe" in some sense. But "safe" has many flavors: array-out-of-bounds, division by zero, stack overflow, out-of-memory, endless loop. Ada SPARK allows to prove absence of runtime errors using "pragma annotate". Also Dafny, Lean have similar features (in Lean you can give a prove).

> I think it's fine for division to be exposed as a panicking operation by default

That might be true. I think division (by non-constants) is not very common, but it would be good to analyze this in more detail, maybe by analyzing a large codebase... Division by zero does cause issues sometimes, and so the question is, how much of a problem is it if you disallow unchecked division, versus the problems if you don't check.

To that, I completely agree! Scala is one of the most complex languages, similar to C++. In terms of complexity (roughly the number of features) / hardness to onboard, I would have the following list (hardest to easiest): C++, Scala, Rust, Zig, Swift, Nim, Kotlin, JavaScript, Go, Python.

That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.

I don't think it's very cumbersome if the compiler checks if the divisor could be zero. Some programming languages (Kotlin, Swift, Rust, Typescript...) already do something similar for possible null pointer access: they require that you add a check "if s == null" before the access. The same can be done for division (and remainder / modulo). In my own programming language, this is what I do: you can not have a division by zero at runtime, because the compiler does not allow it [1]. In my experience, integer division by a variable is not all that common in reality. (And floating point division does not panic, and integer division by a non-zero constant doesn't panic either). If needed, one could use a static function that returns 0 or panics or whatever is best.

[1] https://github.com/thomasmueller/bau-lang/blob/main/README.m...

[1] https://github.com/thomasmueller/bau-lang#types [2] https://github.com/thomasmueller/bau-lang#traits

[1] https://github.com/thomasmueller/bau-lang

In my view, the article is not about optimizing, but about understanding how things work under the hood. Which is interesting for some.

Then I want to convert this to my own programming language (which traspiles to C). I like those tiny projects very much!