I don’t think this video is about hurting anybody. It’s about making sure that large companies can be held liable if they hurt somebody. This is about protecting people.
4,738 karma · joined September 8, 2009
Out in the real world, the thing that all programming languages are actually built on top of looks much more like a Turing machine than a collection of composed anonymous functions. But of course if you want to make your programs go really fast, you can’t treat them like Turing machines either. You need to acknowledge that all of this theory goes out the window in the face of how important optimizing around memory access is.
Which isn’t to say one perspective is right and one is wrong. These perspective all exist and have spread because they can all be useful. But acting like one of them is “reality” isn’t all that helpful.
Ps. Not that the parent actually said the formal perspective was reality. I just wanted to articulate this thought I had bouncing around in my head for a while.
Calling it a “gift” somehow manages to add an extra level of ick in my mind.
This pbs aeons video has a great explanation: https://youtu.be/scAp-fncp64?si=hjeWKGBI7riyjE1M
I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I think if you need to change things in lots of places that’s a sign of a bad abstraction. If there is some tricky bit of complexity with changing requirements, you might find yourself “peeking under the hood” a lot. How could it be otherwise? But if you find yourself only debugging the one piece of code that handles the trickiness, and building up an isolated test for that bit of code, well, that sounds like you built a wonderful abstraction despite it being peaked at quite a bit.
The “has always” is in quotes because it’s a useful lie. You kind of need to really understand the double slit experiment to get quantum fields, superpositions, and how that related to entanglement. Took me years and years of occasional YouTube physics videos before it finally clicked. But if entanglement still doesn’t make sense, I’d start by trying to understand the double slit experiment. It sounds way less awesome than entanglement, but it isn’t really. Double slit is in fact awesome and just as weird. Entanglement is way less cool than it sounds, and no, not actually a way of cheating the speed of light limit for information transmission.
Getting in the habit of automating stuff in your editor and environment can also have a real snowballing effect. Yes, you end up “wasting” some time with yak shaves that don’t work out. But it doesn’t take long before the scope of what you can tackle in a day grows. It’s really profound how much friction you can remove, and how much friction there is in fresh environments.
Also, and ymmv, but a lot of repetitive tasks can be pretty soul crushing. Too much toil and you can come to dread your job. Automating something away almost always feels rewarding to me. Keeping yourself happy and motivated in your work should also count for something.
Glad they aren’t shy about their escape velocity roots. I swear, the ship in their logo looks just like a kestrel.
I’ve always been taught the two rooks are better and who can argue with 5 + 5 > 9? But also, I’ve also lost almost every game where I’ve had the rooks. I always thought that I just needed to be a better player to take advantage of it. Glad to know it wasn’t just me.
Just goes to show that these shortcuts, like the point system, are only heuristics, and pretty shallow ones at that. Knowing that being up a bishop gives you slightly more of an advantage than a knight is better than nothing. But learning in which sorts of positions a knight is actually better than a bishop will give you a much deeper understanding (and correspondingly more wins).
[1] I’d, of course be happy to have a discussion about whether the refactor would make the code better or be worth the effort.
[1] Sedgwick’s algorithms class (useful and clear, but dry as hell), Martin Odersky’s scala course (solid, but probably a little dated by now), several others not worth mentioning.
It’s out there, so whether you finish it, someone forks it, or it just serves as inspiration for another project, you’ve contributed.
It could be the right decision to not fix an architectural bug. But it is a gamble, with a very long tail of cost for getting it wrong.
> One of the sneakier pitfalls of an efficiency-based attitude to time is that we start to feel pressured to use our leisure time “productively”, too – an attitude which implies that enjoying leisure for its own sake, which you might have assumed was the whole point of leisure, is somehow not quite enough.
Trying to brand this as a "new" hacker ethos is just abusing the recognition of the original to push your own (completely different) ideas and agenda.
I'm not going to call it entirely disingenuous, but it does come off with a bad smell of politics.
One may prefer the original to this new ethos, but anyone claiming to speak for a large group of people is engaging in politics. To borrow an idea from the essay, you are forgetting the diversity of that group's opinions when you claim it can be boiled down into short pithy statements.
i've never seen "RESPECT ME!" ever not backfire, on any scale and for any group.
[1] clearly not meant to be an exhaustive list
Which is not to say that there isn't value in asking them. Sometimes their solutions that don't work can be modified into something that does; or their crazy non-solutions can spark some inspiration on my end.
My theory as to what's going on here is that when you are responsible for the solution, you spend a lot of time thinking about what could go wrong, so your thinking gets constrained. When you are solving a problem for someone else, you're thinking is much freer, because frankly you don't give a damn. You are much more likely to come up with a unique, novel solution. You are also much more likely to deliver a solution that is actually disastrous.
My point being: I think there's room for both associated and disassociated thinking. This article seems to think because there was one series of studies showing some benefits of disassociated thinking that disassociated thinking is just straight up better.
Ruby has a beautiful and consistent object / module system, a beautiful integration of functional and object oriented programming paradigms, and extreme powerful metaprogramming. All of those things are pretty wrapped up in its design philosophy which contains a whole bunch more than developer happiness.
Yes, Ruby has warts. So do all the other languages you listed. It is helpful to be able to see both the good and bad in languages and not get hung up battling them against each other.
Fwiw, I work for trading firm, which trades 10+ billion dollars daily and mistakes can be incredibly costly. I would argue the lack of shame associated with admitting mistakes is vital to our level of code quality.
I have yet to meet the developer who does not make mistakes. I have met a few arrogant enough that they'd never admit to them.