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.
Yeah the browser is sadly underused, especially for indie games. Js is plenty fast for most indie games, there are a ton of libraries, dev tooling is good, and all the APIs you could ever need are wired in. There's also an 'escape hatch' with WebAssembly for better performance when you need it.
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.
Ah, interesting. I see "homogeneous coordinates" are covered later in the book I've just started reading (Projective Geometry, Coxeter) as a way of representing projective space. I think that's the link I couldn't see.
> 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.
Another facet of this is my annoyance at other developers when they persistently incurious about the domain. (Thankfully, this has not been too common.)
I don't just mean when there are tight deadlines, or there's a customer-from-heck who insists they always know best, but as their default mode of operation. I imagine it's like a gardener who cares only about the catalogue of tools, and just wants the bare-minimum knowledge to deal with any particular set of green thingies in the dirt.
This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
This might be an indicator that PM isn't doing their job; PM should be able to answer you questions regarding what the business wants (= people who you're trying to serve). Developers, by the nature of interacting with domain, do become experts in the domain, but really it should be up to PM what the domain should be doing business-wise.
If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases.
Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to work so its better if the programmers can talk to users directly there. Of course a PM could do that work if they are skilled at it, but most PM wont be.
So that we're on the same page, what I think should be PM responsibilities:
If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed.
PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add product to basket' button should appear", "Given 'Add product to basket' button When customers click on it Then Product information modal should appear" etc - PM should know what users actually want, ie whether modals should appears, or not; whether this feature should be available for logged users only, or not.
How this will work shouldn't matter to PM; these are AC they've defined.
Of course the process of defining AC should involve developers (and QA), because AC should be exhaustive to delivering given feature
The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria.
In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off.
PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average.
IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.
> 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.
Sending message to a process has a cost (for purposes of preemption) relative to the current size of receiver's mailbox, so the sender will get preempted earlier. This isn't perfect, but it is something.
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.
Ah good to know. It’s interesting (to me) how similar they look to each other but you and other commentators below mention how they’re more like distant cousins
