Twisol

I can't even get past the captcha on that mirror.

Same story reported by Ars: https://arstechnica.com/tech-policy/2023/10/41-states-sue-me...

Not, apparently, to be confused with the identically named Unison language. (I was wondering what unison-lang had to do with the OP until I clicked through.)

Right, but then for commutativity I would expect them to use `merge(merge(a, b), c) = merge(merge(a, c), b)`, whereas what they actually have is the usual `merge(a, b) = merge(b, a)`. They're sort of mixing and matching from the axioms of monoids[^] and the axioms of actions (what you're referring to as "function composition").

[^] (well, properly, semilattices, because that's what state-based CRDTs are based on. But semilattices are "just" commutative idempontent monoids ^_^)

I'm still only halfway through the XC3 DLC >_< Thanks for the nudge, haha.

Is Alvis named after the character of the same name in Xenoblade Chronicles?

(Spoiler warning if you haven't played: the XC Alvis is also an AI.)

Nice article! The statement of idempotence is a little nonstandard, I think -- I'm used to it being stated as `merge(a, a) = a`. The form in the article makes more sense if you have set of operations acting on a state, so that `apply(apply(st, a), a) = apply(st, a)` -- but this follows from the more usual merge law above, since `apply(apply(st, a), a) = apply(st, merge(a, a)` by the laws of monoid actions, then `apply(st, merge(a, a)) = apply(st, a)` by (standard) idempotence.

You don't need to understand monads to do IO. From [0]:

> There is nothing that has to do with monads at all in printing a string. The idea that `putStrLn "hello world"` is monadic is as absurd as saying that `[1,2,3]` is monadic.

You haven't linked any exemplar tutorials, but I feel confident in saying the ones you're referring to teach the general concept of monads, and not how to do IO with monads.

Quite a number of JavaScript developers learned how to use `andThen` with Promises/A+ back in the day, and they didn't need to learn about monads either. (In fact, when it was raised that promises are really monads, there was serious drama and outrage [1] -- an existence proof if there ever was one, that you can use something productively without understanding it as a monad.)

Likewise, nobody would claim that you need to understand monoids before you can concatenate lists. Concatenating lists is as native to lists as sequencing commands is to IO; it's just part of how those types work. The monad interface abstracts over that idea, and learning that abstraction in its full generality is, typically, what people stumble on.

[0]: https://blog.jle.im/entry/io-monad-considered-harmful.html

[1]: https://github.com/promises-aplus/promises-spec/issues/94

(for those who can't read Japanese, and at risk of over-explaining, the parent called part of the program cute.)

> If consumers actually cared about their IoT devices receiving security updates, companies would be doing it.

I don't think this is true. Security issues don't matter until they do, and consumers -- by which I mean "people" -- are notoriously bad at estimating risk for sufficiently rare outcomes.

To take a common example, insecure internet-connected baby monitors can literally give strangers video access to your home (not to mention your child, although we don't need to resort to "think of the children"). I think most consumers make purchases with the reasonable expectation that the product isn't going to violate their personal security without them knowing.

As a concrete example to the contrary, even many laypeople I know consider home assistants like Alexa to be too risky -- they don't like the idea of being overheard and monitored by some unknown "other". And that's almost literally part of the product description! When consumers are aware of these issues, they do care. The idea that they currently purchase as though they don't is confounded by a lack of awareness on the one hand, and a reasonable expectation to the contrary on the other hand.

Yeah, the F* to B* already is a bit weird -- if anything; B* is the voiced version of P*, and they're both just hanging off of F* / H*.

Yes -- the dakuten and handakuten marks are very systematic modifiers of the readings of the underlying glyphs. The dakuten more or less voices the leading syllable (ka -> ga, ta -> da), and the handakuten only applies to H*-column kana and changes the sound to a P*. From my perspective, you only really need to learn the base kana and remember the rule for the modifying marks -- you're not learning entire new kana after that.

(There's also combinations like kyu = ki + small-yu, but that also just builds on the kana you already know, and behaves pretty logically.)

I learned hiragana and katakana by drilling RealKana [0], together with the Flash-based Drag-n-Drops [1] back when Flash was still a thing. It looks like the original author of [1] has non-Flash versions now [2].

RealKana is great for drilling recognition (kana -> pronunciation), and I learned the individual kana by loading one column at a time (e.g. ka/ki/ku/ke/ko). Drag-n-Drop is good for speed-testing recognition, but also for recall (pronunciation -> kana), since it's invertible: you can either choose a pronunciation and go find its kana, or choose a kana and find which pronunciation it goes to.

I'm not sure you can really "learn" these characters without drilling like this -- the symbols are arbitrary, so you have to memorize the association between glyph and reading by brute force.

[0] https://realkana.com/

[1] https://www.csus.edu/indiv/s/sheaa/projects/genki/hira_main....

[2] https://ohelo.github.io/usagi-chan/katakana/

They're probably hoping for a reaction like "Oh man, I gotta know the rest, let me pull out my credit card", but my reaction is just "Seriously? I wasn't giving you my money before, and I definitely won't now."

(On closer inspection, you're only "paying" by creating a "free" account with them -- but paywalls look like paywalls no matter what the price is...)

This is all true, although nothing about the reading "x has type t" implies that "x" can only have one type. It is a separate metatheorem about your system of inference rules that terms have unique types -- and not even one that is always true, e.g. in the presence of subtyping.

> for example, numeric literals in Haskell can have several types

Technically, numeric literals in Haskell have precisely one type: `(Num a) => a`. The literal `42` is actually interpreted as the expression `fromInteger (42 :: Integer)`, where `fromInteger` is a function on the `Num` typeclass. In turn, the `Num` typeclass constraint desugars to a function taking a dictionary of functions, `NumDict a -> a`. The typeclass machinery just means GHC will infer the appropriate instance whose dictionary should be provided.

(technically technically, GHC can be even cleverer if it knows statically which dictionary will be used, avoiding using the dictionary entirely; but this desugaring to dictionaries is ground truth, semantically.)

I read `A |- x : t` as "In context A, x has type t". An entire inference rule (i.e. the horizontal bar separating some premises from a conclusion) is read as as "if P, Q, ... hold, then R holds"; or, sometimes, "We obtain R if we have P, Q, ...".

That doesn't look contradictory. An expression is a (syntax) tree, and every variable use has a unique path from the root to that use. This path crosses some sequence of binders, which we can label with integers.

If you assign integers from the inside out, as DB indices do, then the `x` usage in `\x -> \y -> x` passes one binder (`\y`) before landing on the correct one (`\x`), yielding `\_ -> \_ -> 1`.

If you assign integers from the outside in, as DB levels do, then the `x` usage lands on `\x` instantly, yielding `\_ -> \_ -> 0`.

De Bruijn came up with both systems, and it can be confusing to keep track of which one is which; but they are different systems.

I interpreted `published` along the lines of blog posts, in which an article can be either a draft (visible only to the author) or published (visible to the world). This seems different from dev/prod venueing, where having separate databases altogether makes sense.

I understood the column-first approach more as an alternative to putting all columns for an entity in one table, especially when rows often don't populate every column. From that perspective, what's being described is a strong separation of concerns; applying this to dev/prod would be a weakening of this separation, and so probably not what is desired.

Ah, sure. Well, I've asked to "borrow a tissue" many times, and neither interlocutor expected the tissue to be returned. Maybe it's regional.

I've heard "bum a ride" here in America, although it's a rare word in a rare phrase.

The thing about a "database", relative to any other assembly of data, is that it typically has a universal query system whose particulars are not dependent on the schema of the data you're querying over. This is pretty much the focus of this article.

Horizons! https://ssd.jpl.nasa.gov/horizons/

IIRC, the Telnet interface is technically more fully-featured than the others, although that's probably simply because it would have come into existence first.

> Cat’s eye movements were coded using actions defined in CatFACS, an anatomically based system designed to objectively measure facial actions based on their underlying muscle movements.

Whoever named this system was clearly aware of the meme. I'd like to remain subscribed to CatFACS, please!

From the article:

> Yes, we have officially added an iOS version of Thunderbird to our future development roadmap. Expect more concrete news about this toward the end of 2023.

So it doesn't exist yet, but they're going to make it, and at least they've got a logo for it.

Whoa, I haven't thought about BYOND in ~20 years. I'm incredibly impressed it's still going (same website and everything)!

Yes, exactly -- the responsibility to keep up with Java versions does not, unfortunately, lie with Manifold alone. The deep magic they rely on also needs to remain accessible.

A team I was on decided against Manifold precisely because we wanted to keep up with Java's twice-yearly version updates, and we didn't want a bespoke compiler plugin to lock us to an older version.

I think Manifold is extremely cool, and it does look like they're keeping up with the latest -- but the deep compiler magic it relies on really makes me nervous.

> Rust's use of typeclasses (which it calls traits for some reason)

Scala and (apparently) PHP call them traits too, among many others [1] -- Rust wasn't the first here.

[1] https://en.wikipedia.org/wiki/Trait_(computer_programming)

PH really is underrated. It's one of the only Zeldas I've gone back to for repeat playthroughs, and it's fun every time. You're absolutely right that the Ocean Temple is an integrated speedrun experience -- and even then, they really make it fun to go back through old floors to make use of new routes and obtain locked-off treasure chests.

Also, Linebeck is one of my top-three sidekicks out of any Zelda game. He really grows on you over the course of the story.

This seems pretty revisionist. I loved Majora to bits as a child, and I don't recall this being a contrarian opinion whatsoever on the Zelda Universe forums at the time.

Maybe there's a difference between critical and popular reception at play here?

I think a fair number of people, including myself, consider MM > OoT. They are very different games, but MM excels in areas that OoT doesn't.

You're right that this inversion is rare though. I think Phantom Hourglass is a great sequel to Wind Waker, but I can't reasonably claim it's better. (And Spirit Tracks was not better than Phantom Hourglass.)