Thought-provoking essay. I can see how responsibility and ownership are important to help identify, motivate and reward the high achievers (and conversely, identify and get rid of the "dead wood"). But I can also see how collaboration and the dilution of responsibility and ownership helps better integrate junior members who might otherwise stay on the sidelines for longer than they should. There's also the issue of personnel turnover: what happens if the one person who is responsible for a major piece of a project leaves the company? A collaborative setting is more resilient to churn. There are trade-offs, and possibly a middle ground to be found.
This looks nice! Wish they had a no-credit-card-required version for educational purposes. For the course I teach we use Spring Boot, and life was good with Heroku till they discontinued the no-credit-card version, and then the only choice we had (with support for Spring Boot) was to move over to Azure, which works but is a bit overkill and complicated for our purposes. I guess we could just use Docker and then many more platform would become available, but I'd rather not add one more step to the pipeline if possible.
Yeah, it's a case of "don't let the perfect be the enemy of good". The conservative stance is happy with the status quo. The progressive stance isn't. We probably need a bit of both. Finding the right balance being key.
Maybe the difference between the eval of the best move vs the next one(s)? An "only move" situation would be more risky than when you have a choice between many good moves.
The right book for the right problem. SICP isn't meant to teach you how to tackle fault-tolerance in a complex distributed system. Here is a textbook that talks about distributed systems (van Steen and Tannenbaum):
Not the OP but I have tried to reduce my sugar intake, I'm walking more than before, and I still basically gain half a pound every year. I'd lose some weight for a few days, and gain it all back on the one day I'm a bad boy. It seems like there's an internal dial that decides what my weight is supposed to be, no matter how much I fight it. And the dial adds half a pound every year. I guess the dial is my metabolism as I age.
"To ascribe beliefs, free will, intentions, consciousness, abilities, or
wants to a machine is legitimate when such an ascription expresses
the same information about the machine that it expresses about a
person. It is useful when the ascription helps us understand the
structure of the machine, its past or future behaviour, or how to repair
or improve it. It is perhaps never logically required even for humans,
but expressing reasonably briefly what is actually known about the
state of the machine in a particular situation may require mental
qualities or qualities isomorphic to them. Theories of belief, knowledge
and wanting can be constructed for machines in a simpler setting than
for humans, and later applied to humans. Ascription of mental qualities
is most straightforward for machines of known structure such as
thermostats and computer operating systems, but is most useful when
applied to entities whose structure is incompletely known.” (John McCarthy, 1979) https://www-formal.stanford.edu/jmc/ascribing.pdf
Python was created in 1991; I imagine the "yield" keyword appeared either right then or not much later!
Also, the refinement at the end of the article: "We arrange an extra function parameter, which is a pointer to a context structure; we declare all our local state, and our coroutine state variable, as elements of that structure." sounds like implementing a closure to me. You make the callee a lambda which would use an outside var/context/state to determine what to do or with what value. Am I understanding this correctly?
The article says: "In many modern operating systems, you could do this using pipes between two processes or two threads. emit() in the decompressor writes to a pipe, and getchar() in the parser reads from the other end of the same pipe. Simple and robust, but also heavyweight and not portable. Typically you don't want to have to divide your program into threads for a task this simple."
I haven't done a re-install, but deleting the cache folder alone doesn't make it go away. Starting Firefox re-creates the folder obviously, and Defender gets triggered again.
Windows Defender flags things in the Firefox cache as a Trojan. It probably isn't, and it could also have something to do with uBlock Origin, but until that is resolved (I'm keeping an eye on the above link) I can't risk it.
Maybe, but the surreal atmosphere when the sun rises, you are surrounded by blue everywhere, you are jetlagged from just having landed half hour ago, and you have a drink in hand is indescribable. I went to other Icelandic baths during my stay but nothing matched that experience.
Yeah, mobile agents were a hot topic back then (mid 90s), and Telescript was one of the early programming languages that enabled this idea of agents roaming around doing stuff on the web. Java coming along around the same time with dynamic loading of code (used in applets for example) gave the idea another boost. Ultimately, I don't think the security issues (agent could attack the host, host could attack the agent, agents could attack each other, etc.) were worth the trouble and the research seemed to fizzle.
I always wondered if message passing between static agents wasn't a functionally equivalent yet safer and simpler alternative to mobile agents.