> David was successfully treated in this way: his motivation levels went back up after taking a drug that stimulates dopamine receptors in the brain. Because of this, he was able to get a new job, become independent and even find a partner
I've always wanted to hear the stories of patients like David. What happens when you can tell your family and friends - I'm not a screwup, this has a physical cause? How do people interact with you who've previously only seen you in your decline?
A long time ago I read an account by a financial journalist who'd had some kind of brain injury and temporary lost his faculties. It damaged his professional relationships and the implication was, most of his former colleagues remained unduly sceptical - even after years of normal functioning.
You are right. An observation, even before the rise of LLMs, was that computers were becoming more human-like and humans were acting more like machines
The sculpting force of algorithms is bite sized zingers, hot takes, ragebait, and playing to the analytics
But I could screw it up in Go, if I made the same assumptions
fvs, err := features.AppendWithNames(..)
if err != nil {
// this will NEVER break
panic(err)
}
Ultimately I don't think language design can be the sole line of defence against system failures; it can only guide developers to think about error cases
Right, but the point isn't to make errors impossible; the point is to have them be 1) less likely to write, and 2) easier to spot on review.
People's biggest complaints about golang's errors:
1. You have to _TYPE_OUT_ what to do on EVERY.SINGLE.ERROR. SOO BOORING!
2. They clutter up the code and make it look ugly.
Rust is so much cleaner and more convenient (they say)! Just add ?, or .unwrap()!
Well, with ".unwrap()", you can type it fast enough that you're on to the next problem before it occurs to your brain to think about what to do if there is an error. Whereas, in golang, by the time you type in, "if err != nil {", you've broken the flow enough that now you're much more likely to be thinking, "Hmm, could this ever fail? What should we do if it does?" That break in flow is annoying, but necessary.
And ".unwrap()" looks so unassuming, it's easy to overlook on review; that "panic()" looks a lot more dangerous, and again, would be more likely to trigger a reviewer into thinking, "Wait, is it OK if this thing panics? Is this really so unlikely to happen?"
Renaming it `.unwrap_or_panic()` would probably help with both.
Unfortunately none of the meanings Wikipedia knows [1] seems to fit this usage. Did you perhaps mean "taboo"?
I disagree that "unwrap()" seems as scary as "panic()", but I will certainly agree to sibling commenters have a point when they say that "bar, _ := foo()" is a lot less scary than "unwrap()".
Essentially, you add a preprocessing stage to the compiler that can either enforce rules or alter the code
It could quietly transform all object like types into having read-only semantics. This would then make any mutation error out, with a message like you were attempting to violate field properties.
You would need to decide what to do about Proxies though. Maybe you just tolerate that as an escape hatch (like eval or calling plain JS)
One "solution" is to use Object.freeze(), although I think this just makes any mutations fail silently, whereas the objective with this is to make it explicit and a type error.
I thought Object.freeze threw an exception on mutation. Digging a little more, it looks like we're both right. Per MDN, it throws if it is in "use strict" mode and silently ignores the mutation otherwise.
That's opting into immutability, the point of the experiment is having it by default. Plus, that's just the type system preventing you from adding a property. It won't stop you from trying to change the `immutable` field.
I'm genuinely curious, was this AI generated, or just a lack of understanding?
No, you're the one that's incorrect, typescript blocks mutations when you use Object.freeze too: "Cannot assign to 'immutable' because it is a read-only property. (2540)"
You can also use "as const" to get the same behavior without any runtime calls:
const exploring = { immutable: true } as const
exploring.immutable = false
^ Cannot assign to 'immutable' because it is a read-only property.(2540)
But yes, OP wasn't referring to the article, they were just pointing out the narrower fact that Typescript does in fact have compile-time errors for mutating Object.freeze's return values.
It's better to have diverse, imperfect infrastructure, than one form of infra that goes down with devastating results.
I'm being semi-flippant but people do need to cope with an internet that is less than 100% reliable. As the youth like to say, you need to touch grass
Being less flippant: an economy that is completely reliant on the internet is one vulnerable to cyberattacks, malware, catastrophic hardware loss
It also protects us from the malfeasance or incompetence of actors like Google (who are great stewards of internet infrastructure... until it's no longer in their interests)
For a long time, yt-dlp worked completely with Python. They implemented a lightweight JavaScript interpreter that could run basic scripts. But as the runtime requirements became more sophisticated it struggled to scale
I'm nowhere near as senior as you (12 years). But I've reflected on this a lot recently. I love the technology and feeling like I'm building things, but staying hands on will always limit your scope. Taking the management path improves your scope but the work is - well - just less fun than programming.
My answer right now is to try and build more things myself. Small apps, CLIs, retro games. Not libraries or much OSS stuff so much as actual "products" that give me creative control and concrete outputs. It's hard to make the time though.
Outside of my career I'm also trying to cultivate other works, like my YouTube channel and my writing. Creating a video that 250k people enjoy is at least as meaningful to me as crushing my OKRs
We are all mortal beings: there will inevitably be more things to do than time to do it, and it's easier to ruminate on options than commit to something that feels "suboptimal".
To give an example of that. I spent a lot of time wondering if I should have gone into academia / literary criticism rather than tech, because of a vague sense that because I was very good at something, that's where I should put my efforts. Is that sound reasoning though? I probably achieved more "value" for society working as a programmer, than writing about Chaucer.
So to summarise it may be a choice of making peace with the lower scope / autonomy of hands on work, and finding that satisfaction outside work. If that suggestion makes your soul revolt, though, it may be you have to compromise and take the managerial path
Thank you. That is mostly what I have been leaning toward recently, and why I'm interested in freelancing. I want more time for my own projects, and freelancing seems to be the only way that I can find a better balance between money and free time.
I've always wanted to hear the stories of patients like David. What happens when you can tell your family and friends - I'm not a screwup, this has a physical cause? How do people interact with you who've previously only seen you in your decline?
A long time ago I read an account by a financial journalist who'd had some kind of brain injury and temporary lost his faculties. It damaged his professional relationships and the implication was, most of his former colleagues remained unduly sceptical - even after years of normal functioning.
reply