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.
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.
> 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.
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.
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.
> 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.
> [...] 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.
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?
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.