Twisol

It's the same "sympathy" as in "sympathetic resonance" [0]. It has nothing to do with pity or the like.

[0]: https://en.wikipedia.org/wiki/Sympathetic_resonance

I also always look for the IRE MUDs :) I played Achaea about 15 years ago; the community of players really makes the game what it is. (If anybody remembers Soludra, that's me!)

I can't speak to "most", but the incredible CrossCode displays the HTML5 shield on startup, so indie games on the web stack do exist and can be amazing.

I think "a week" is slightly optimistic, but I also think "a month" is slightly pessimistic. When I learned hiragana, I spent my free time drilling on RealKana [0]. I'd focus on a new column of the kana table, then bring in columns I'd already practiced, until eventually I could flash reliably on cards drawn from the entire table. This legitimately didn't take much longer than a week, because learning a single column in isolation is very quick, and the real difficulty comes in distinguishing similar kana (as you say). But I was able to drill similar kana by selecting two or three kana that would force me to see them often. (I still struggle slightly with wa, re, and ne, but I definitely know them.)

I also drilled on a drag-n-drop kana table [1] in a few ways -- sometimes I'd start from the kana and try to figure out where they should go in the table, and sometimes I'd go along rows or columns in the table and try to find the kana that belong there. These two directions drill both recognition and recollection.

Proper pronunciation is a cross-cutting concern. As a whole, it's not something you can reasonably learn solely from kana, but the aspects that are relevant are not difficult to pick up. Every kana breaks into one (vowels and N) or two (the rest) phonemes, and for the most part, the way you pronounce those phonemes is consistent across rows and columns of the table (admitting exceptions like "shi" and "tsu"). If you are taught those basics, learning how to pronounce kana is not hard. Training your ear to "hear" distinctions among English allophones, and to distinguish pitch accent from the more familiar stress accent, is much harder, and really has to come from experience, not just kana.

[0]: https://realkana.com/hiragana, wow it's improved since I last used it

[1]: https://ohelo.github.io/usagi-chan/hiragana/

As you say, projections and rotations are easily accounted for in linear algebra. The issue is that translations are not a linear transformation. For instance, consider f(x) = 2 + x. It's certainly not the case that f is linear -- that is, that f(cx + y) = c f(x) + f(y) -- because on the one hand we'd expect 2 + cx + y, and on the other we'd expect (2 + cx) + (2 + y), which is 4 + cx + y.

However, translation is an affine transformation, which is a particular case of a projective transformation [0]. It turns out that we can represent 3D affine (and general projective) transformations using a 4x4 matrix -- that is, as linear transformations in one dimension up, in a similar sense as how we can represent complex numbers as particular 2x2 matrices [1]. So yes, projective geometry is the right theoretical lens, even if we're usually able to forget about it (somewhat) when we use matrix representations.

[0]: https://en.wikipedia.org/wiki/Affine_transformation#Represen...

[1]: https://en.wikipedia.org/wiki/Complex_number#Matrix_represen...

> It feels like software developers are scientists who study their customers' knowledge domains.

I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.

> I've recently been curious about the abstract machines implied by this process for other kinds of programs.

Olivier Danvy's "Rational Reconstruction of the SECD Machine" [0] explores the idea of this transformation as well, but frames it as a relationship between operational and denotational semantics:

> This deconstruction–reconstruction is actually interesting in itself because it provides a bridge between small-step operational semantics (in the form of an abstract machine) and denotational semantics (in the form of a compositional evaluation function)

His work on (de/re)functionalization is super interesting.

[0]: https://link.springer.com/chapter/10.1007/11431664_4

An eDSL is an (e)mbedded (D)omain-(S)pecific (L)anguage. In other words, it's a language for describing domain-specific entities and operations, that happens to be embedded into an existing (host) language rather than being given its own standalone parser, interpreter, compiler, etc. An eDSL gets to piggy-back off of the syntax and semantics of the host language, but extends it with domain-specific concepts in (hopefully) a way that integrates well with the host language.

Lots of things that are "just" libraries could also reasonably be thought of as eDSLs.

I saw signs of both human and LLM authorship, so it's probably at least not slop. It did take me out of it a bit though, yes.

Yes, this is missing the "pressure" part of "backpressure", where the recipient is able to signal to the producer that they should slow down or stop producing messages. Observability is useful, sure, but it's not the same as backpressure.

HTML is actually a dialect of SGML. XHTML was an attempt to move to an XML-based foundation, but XML's strictness in parsing worked against it, and eventually folks just standardized how HTML parsers should interpret ill-formed HTML instead.

Wait, how is Rocket League affected by AI? I play infrequently these days, but I hadn't noticed anything :(

I have a friend who named their custom-built languages "Monica" and "Joe". It's surprisingly common for homegrown languages, I think.

> room designated was meadows and you could find herbs which would replenish over time

I'm sure several MUDs did this, but, this sounds an awful lot like my home MUD of Achaea, which started in ~1997, still exists (healthily!), and has this exact system :)

I agree in principle, but actually, according to the netcat website [0]:

> If netcat is compiled with -DTELNET, the -t argument enables it to respond to telnet option negotiation [always in the negative, i.e. DONT or WONT]. This allows it to connect to a telnetd and get past the initial negotiation far enough to get a login prompt from the server. Since this feature has the potential to modify the data stream, it is not enabled by default. You have to understand why you might need this and turn on the #define yourself.

[0]: https://nc110.sourceforge.io/

> [...] no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.

Then this is at the heart of our disconnect, because the post of mine that you originally replied to --- as well as, unless I drastically misread, the original article under discussion --- was concerned with traffic on port 23, the Telnet protocol port, and not with any particular implementation communicating on that port. The concern of my original comment was that this might affect MUDs that operate on port 23. Perhaps you can understand my confusion when you reply stating categorically that most MUDs do not use "Telnet" (meaning the program), when that wasn't really what was at concern (and therefore implied that my question had no basis).

It is a true fact that many MUDs operate on port 23. Many do not, but you can skim a MUD aggregator like MudConnect [0] to see that it is quite common. Aardwolf, Discworld MUD, and the IRE games --- which consistently topped TopMudSites (when that aggregator was still running, anyway) all operate on 23, potentially in addition to an unreserved port.

> what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!

All telopts are disabled by default, per Telnet RFC; the only things you must absolutely parse under the RFC are the standard complement of NVT commands (such as IAC GA "Go Ahead"), even if they are otherwise implemented as no-ops.

Any input stream with the high bit clear is treated as pure data -- with the incidental exception of bare `\r`, which must always be followed either by `\n` or by `\0`; but Postel's Law has turned that into more of a guideline. So as long as the standard NVT encoding is assumed (which is just 7-bit ASCII) and the NVT core escape sequences are avoided, a modern Telnet-based MUD client can interoperate with a plaintext MUD server without issue. (As you know, this is also why people get away with using `telnet` (the program) to access HTTP and SMTP services instead of using something like netcat.)

Some MUD clients will eagerly send IAC DO / IAC WILL subnegotiations, but general practice is to let the server offer first -- probably precisely to ensure compatibility with MUDs that don't implement Telnet subnegotiations.

> Now as for the Diku, LP, and other “combat” type games, I’ve no idea

Diku-family MUDs are certainly the ones I have the most experience with. I understand LP MUDs also generally have Telnet support; or at least, I recall seeing a patch for them that MUD owners often sought to apply to their games.

[0]: https://www.mudconnect.com/cgi-bin/search.cgi?mode=tmc_bigli...

As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?

Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.

> You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.

I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.

The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think.

A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two protocols that if you're just using it to transfer plaintext it will probably work out fine, but they are distinct protocols.

> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.

Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?

Top 0.44% here. Hrm...

I'd just like to invoke the principle to "not judge a book by its cover".

The article here is very well written and does a great job of conveying the perspectives and opinions of many parties. I would recommend reading the article in spite of its headline.

> I don't understand this urge to demonize the parents, who on top of having lost a child, have to stand these witchtrials.

Neither the article nor the commenter you replied to has demonized the parents. Yes, both the evidence discussed in the article and the opinions of those interviewed indicate direct administration of a pharmaceutical; it is appropriate to discuss this. Nobody has pointed the finger at anyone; it would indeed be quite inappropriate for such a discussion to be held in this forum.

Also relevant to the quote selected by 'steelbrain:

> Recently, Parvaz Madadi has undergone a painful process of revisiting her past work and memories. [...] She added that she had no confidence in the measurement of Rani’s breast-milk sample, because it had been handled by Koren’s lab.

There is a lot to process in this long article. The quote selected by 'steelbrain, concerning Koren's measurement occurs very, very early on, and much of the rest of the article is about contrasting Koren's early presentations of the material against others' testimony. It's worth reading the whole thing

To 'steelbrain: cherry-picking one single quote out of a nuanced article does the journalism here a dire disservice. It's okay for different people to have different beliefs and takeaways from the article. However, your own defense of the biological mechanism here is directly argued against in the "same article" you are admonishing others over reading. That is not conducive to a discussion in good faith.

I am young, but not so young as that. I do have a credit card, I just don't use it for anything except the monthly cost of server hosting (to keep it in use). Despite its disuse, I have an "exceptional" credit rating, probably mostly due to the age of the account. So I appreciate the point about credit history, but my habit of preferentially using debit doesn't seem to have been to my detriment on that front.

As to fraud protection, I agree, but as noted in another reply, I wish I understood why the protections afforded to credit don't also apply to debit. There must be some systemic reason for it that I'm unaware of. As it stands, my best guess is simply that "it's a perk to entice people to use credit".

I had this thought as well. I didn't want to raise it myself, because I don't have any personal evidence that this is the case, but of course the "cash back" has to come from somewhere.

I've heard this, too, and it's a good reason to use a credit card at least for significant purchases. But I'd rather see those same protections extended to debit cards. I wish I understood why they aren't.

I have heard this, and it is probably a flaw in my approach to purchases. But is that really justification to ask "who in the world uses debit cards"? I still feel more comfortable not being on the hook to somebody, and the organizations that extend lines of credit don't do so as a prosocial program, certainly. (Just because some people can safely make use of credit doesn't mean everyone can. I know someone who has unfortunately made poor use of their credit card, and I don't necessarily trust myself to avoid a similar fate.)

Setting your incredulity aside, I'm curious why you think using a debit card would be so shocking. I effectively don't use a credit card at all: I use a debit card (or an equivalent Apple Pay representation thereof) exclusively. From my perspective, if I want something and I have the money, I'll pay for it. If I want something and I don't have the money, I won't pay for it. I don't often want things outside my budget (and I am not well-off, as a grad student), so I don't often feel any pressure to amortize the purchase over time with a credit card. And I prefer that state of affairs, because I don't want to get in the habit of using someone else's money if I can't afford to pay them back.

This isn't a value judgment on people who do use credit cards. There are plenty of reasons why using a credit card by default would be appropriate, and I'm not shocked to hear of someone who does so. But I am curious where your shock comes from, so I shared my story as a data point.

I have a Shokz brand two-piece headset (the OpenFit 2+ i think?) that just wraps around the outside of the ear, with the actual speaker part held just outside the ear canal. I can't do in-ear buds either, but these just work for me. Doesn't even feel like anything's there.

I did try their bone-conduction headphones, but the quality was slightly worse and they didn't feel as nonexistent to wear.

I need to take a heaping spoonful of my own advice here, but: yeah, kind of yes. You don't have to think of them as the people you've been searching all your life for, but to meet people, you need a source of people to draw from. Those two people you talk to on a semi-regular basis are entry nodes into the social network.