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.

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

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

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 :)

> 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/

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...

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.

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.

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?

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.

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.

> 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.

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".