It wasn't a prisoner's dilemma. Cooperating gets you almost nothing while defecting gives you benefit. It was nearly the opposite of the prisoner's dilemma.
Couldn't another school of thought "blame" those who didn't participate loudly?
“Cooperating gets you almost nothing while defecting gives you benefit”
That is the prisoners dilemma. What you have offered here is in fact an accurate statement of the payoff matrix for the prisoners dilemma in the case where the other prisoner cooperates.
In prisoner's dilemma cooperating gives both parties the most benefit in aggregate, while defecting gives on party additional benefit at the expense of a steep disadvantage for the other party. Also note that if all parties defect they all end up in a rather undesirable state.
For the SVB bank run, the main loser is the bank, who isn't party to this game (of whether to keep deposits or not). Even if everyone defected, the early defectors don't lose anything. And arguably, it can be foreseen that even late defectors don't lose anything either due to SVB marginally in the "too big to fail" category, or at least, the startup ecosystem being "too important to fail".
My university had Dijkstra's quote "Computer science is no more about computers than astronomy is about telescopes". They made us aware of tools and we were free to use them as little or as much as possible to do the science. I always assumed that software engineering degrees focused on tools more than computer science degrees (among other differences).
The following isn't aimed at you in particular, but in HN threads about the Missing Semester there will always be someone who earnestly repeats this stinking turd of a Dijkstra quote, so I'll put my rant here:
Dijkstra was full of it. He wanted CS to be just a branch of abstract mathematics but that's never been the case. That's a retconning of history by people with math envy. Before Alan Turing had ever heard of the Entscheidungsproblem, he had already built simple mechanical computers with his bare hands.
It's cousin to a stupid mindset you see in software engineering, that you can somehow be a good engineer while not knowing what your hardware is actually doing. That's how you get complicated architecture-astronaut systems with good theoretical big-O characteristics, that get crushed by a simple for loop written by the guy who ran a profiler and knows what a cache line is. We live in a world made of atoms, not lemmas.
Research fields go rotten when they don't come into contact with reality enough: quantum computing, string theory, etc.
And as for astronomy: knowing how telescopes are constructed, how they work, their optical characteristics, limitations, failure modes, all of that is essential to observational astronomy. And if you study astronomy, you sure as fuck are taught how to use a telescope!!!
Astronomy as we know it didn't exist until we had good telescopes. Cosmological theories have risen and fallen on the advances in optical theory and engineering. Astronomy is very much about telescopes.
What other field is so ashamed of its own tools? Like, art isn't about pencils, but art students are taught how to hold a pencil! Stop repeating this thought-terminating cliche.
I estimate that astronomers need to know about tradeoffs on a telescopes' settings for the data they are looking at. But I'm unconvinced that they necessarily need to know how to operate it (would depend on the workplace) and I certainly disagree that how they are constructed is absolutely necessary for all astronomers.
More knowledge is always good, so of course learn what you want. But it's not being "ashamed of tools" to say that a CS degree should "do one thing and do it well".
Additionally, we can simultaneously say that a university should encourage tool mastery while also saying that they don't need to teach entire courses on it.
Completely agree. Things like shell scripting, debugging tools, IDE usage can all be naturally picked up on the job given whatever tools that they recommend you use at their company.
You know what you're not going to be able to pick up at your first software engineering position? Discrete mathematics or linear algebra.
Not trying to dismiss the importance of knowing discrete math etc. in general, but I would posit that vast majority of entry level swe positions require no knowledge of it.
However, knowing the tools of the trade is something that is invaluable. And yes, it can be picked up on the job, but deliberate learning and practice is more effective and less stressful.
> Not trying to dismiss the importance of knowing discrete math etc. in general, but I would posit that vast majority of entry level swe positions require no knowledge of it.
Directly, sure. I do think there is something about the rigor of the math thought process that lends itself to writing software. Thinking through algorithms and proofs is really not much different than writing code or debugging.
Even with tools I think learning concepts are better. I've used so many IDEs through my career, but they are all roughly the same conceptually. One thing that has helped though is embracing vim keystrokes and using them everywhere.
This was my first thought too. The tools talked about in the link are useful but they aren’t really computer science. This was also hit home in my CS courses. I was being taught the science behind computers, not necessarily the practical application of them.
-Meet Markus at a con
-Markus best friend now
-Play Minecraft for days
-Write poem
-Markus says "I ain't reading all that, ship it! We have a deadline!"
-Take the money and run
-Enjoy cold hard cash instead of speculating on royalties
-Trip on shrooms on squatted land
-Try to squat poem
-"Dear Microsoft I don't care about laws. Love love love."
-Love love love
-Money money money plz
-Love love love
Was the documentation a failure? Or did the US save untold amounts of money because of the mothballing->documentation? The failure of the 20M attempt doesn't mean the overall strategy was bad nor that the documentation was net negative.
Very interesting. I noticed that too, in part because I always remove it from the Twitter links I copy; even though I'm not entirely sure what/how it tracks, I know enough to know it's not needed to load the tweet in question.
I was confused for a few sentences when the giver/taker terms were used without explicit definition. I assumed they were used to denote information givers/takers but the definition is more like spotlight giver/takers
One time I made a "Hitler finds out"* meme and uploaded it to youtube. My video immediately got 2 copyright claims on it. One was for the video and was probably by the film rights holders. The other was for the audio and it was this song! https://www.youtube.com/watch?v=RSlbcRumfwk I assumed that this was some kind of scheme. The audio claim has since been removed (not by me and I don't know when).
The author is correct about centralized NFTs not being what you expect them to be. They are wrong that NFTs are debunked. A true web3 game will never have the servers shut down. Everyone collectively pays for the server costs. Every time you do something in the game, you pay for your little slice of server time.
