Pretending to be very in-demand seems a common way to game most interview processes. But I would think that presenting yourself as being very in-demand, while not having any particular answer to "why us", could come off as having no particular reason to be loyal and work against you.
With regards to the Pokemon example given, I can think of two good ways to encode it:
First, simply a bunch of single-bit flags, one per move per competitor. Each turn, for move tracking, we update at most one bit in one of these arrays by copying the array and updating a pointer. We can track 1000+ moves, and only need to copy 128 bytes. You can do thousands of comparable things and still be done in a single frame.
Second, a list of turn information. A move could ask arbitrary questions about the history of the current fight by walking the list. An append-only list trivially has an immutable sublist, and you only need to "pass" a single pointer. Walking the list should be trivially possible well inside a single frame, provided you don't have many thousands of turns in a single fight.
All that leaves aside the fact that you don't actually need to fit your world updates in a single frame render - you can interpolate/extrapolate. This is especially easy in a turn-based game like Pokemon, where it mostly consists of "smoothly progress through the same animation".
What I was trying to say is that I think there is some virtue in being able to add effects to your program without having to change the syntax you use. Its nice to only have to use List.map and not have two incompatible map and mapM functions.
This is not to say that I don't value extra static safety. I think there is definitely room for languages that track effects without the syntactic weight of monads and monad transformers.
Ah, that's the bit I understood, and about which I said we could agree to disagree. To me, that reads like "I want to add new side effects and not document them," but I think coding style comes into play in complicated ways and it's not something I am eager to dig into right here, right now.
What I did not understand was your response of "the article wasn't talking about actually printing" to the suggestion of using Writer, despite your knowing that Writer is not about actually printing, Writer being in fact a good fit for what was described in the article, and the poster having quoted "printing" in the first place.
Right. It's not like programmers invented the term variable and it can only reasonably refer to a mutable memory cell... we adopted it from math, where x is quite clearly a variable despite having only a single value in "x + 1 = 7".
I couldn't agree more. Especially when you're under pressure, bite off smaller pieces. Not only is it possibly better practice in general, but in a time of diminished cognitive capacity (such as when much of your bandwidth is being eaten up wondering how you're coming off) they will be easier to get right, and small successes will help ease your stress as much as they help solve the problem.
Nitpick, but ran into this again today: I wish "Ord k => Monoid (Map k v)" was "(Ord k, Semigroup v) => Monoid (Map k v)", and would combine values (on key collision) using whatever semigroup instance was available for v rather than an implicit Last.
Given that the person you were replying to said, "I apply category theory and type theory all the time, and I'm sure the time I've put into studying algebraic topology and abstract algebra has shaped how I think about problems[,]" I don't think it's clear at all that they meant to express "web engineer, therefore not mathematician."
It's impossible for a compiler to know the size of a matrix whose size is determined at runtime, but it's not impossible for a compiler to prove that whatever the size your logic is still correct (or at least doesn't break any of the invariants you've established). Depending on the nature of those invariants and the complexity of your logic, you may need dependent types.