Sorry for off-topic, but: Is the SSL certificate actually bad, or is Spectrum screwing with me somehow? And if so, how? I'm using Cloudflare DNS, so how can Spectrum even do anything about it? Unless they are MITM-ing my DNS queries, which I suppose is possible but it's a level of chicanery I've not seen yet.
> What would it even look like for the top-most function to have to know “everything” that all the child functions end up ever needing? For every function parameter change in the entire program to somehow force a change all the way up the entire call stack? Clearly this does not happen. It so thoroughly does not happen that you may be having difficulty even imagining what it is I am talking about.
Really? In my experience, it certainly does happen and I'm generally happy (but not thrilled) when it does. It means the type system is doing its job, forcing me to provide all the dependencies that a function needs. If 38 layers deep something now needs a connection string that it didn't have before, that had better bubble up to the top-most function. Unless of course the top-most function has already provided it to an intermediate layer which can break the chain, but that is very different than the context.Background() example.
Yeah, in my experience it absolutely can happen, and the way it generally looks is that the dependencies get roughly grouped into larger structs which are then being passed down the call stack mostly as-is, until they hit a certain abstraction level/barrier where the parts of those structs start being passed down.
It's somewhat tedious, that's why modularity becomes even more important: with correctly chosen borders, the grouping of dependencies becomes very clean and self-evident, the whole data flow just flows. Chose them wrong, and you spend most of your time adding and removing those pesky extra arguments.
Yes, when considering software design it's great when you can "smuggle in" a new dependency by adding a new property or method on some already-established payload. I would describe this as "The change requires someone way up the stack to change, but all the intermediate layers require no source changes" which is notably absent from the author's list of "three basic cases that can emerge." I assume the author is well-aware of this technique but considers it equivalent (for the purpose of function coloring) to "The change may require a change to all functions in the stack" since technically the signature of all those intermediate layers did change.
Your configuration structs are not "everything". You probably have dozens of things in them. You have hundreds to thousands of different parameters to different functions. By the time your configuration structs have hundreds of things in them you have thousands to tens of thousands of parameters to functions. Only a fairly small fraction of things make it all the way up to main.
This is exactly what I was talking about with this being a "cognitively available" operation. You notice when you have to propagate something all the way up to the top precisely because it is not something you do very often and it stands out as an exception when you do. If you are literally propagating everything up to main, all the time, every time you change any function anywhere in your program, you are doing something very, very wrong.
I'm not talking about configuration structs, I'm talking about actual, constructed dependencies being passed around in large sacks, sorry, structs.
And you don't have to propagate every parameter up to main because a) not all things are made in it, b) things that are being made in it are already being made in it and so, are already being passed down. This passing down stops down somewhere, which is where you reinstate it, not all the way up in main.
I chose a connection string as an example of something that obviously cannot be originated in the middle of the call stack. The difference between passing a raw connection string or passing a connection factory is important for good software design, but I considered them equivalent in the context of this discussion of coloring.
I value writing style and pacing way more than any volta. Pride and Prejudice is hardly my genre, yet I remembered it grabbing me immediately. So just now I checked to see if I remembered it correctly, and within the first minute I laughed and I'm hooked again.
Life's too short for novels that might get good halfway through, especially when there's plenty Austen I haven't read yet.
Yes! The opening line of Pride and Prejudice alone is already immediately captivating. And then makes you re-read it again, after you finish the book and it suddenly shines differently.
I feel enormously fortunate for being fluent in Russian, reading Bulgakov and Tolstoy in original is pure joy, any translation removes subtleties - it's like listening to Bach through the car stereo, you still can enjoy it, but it won't make you want to cry, like listening in symphony hall might. If I had no other reason for learning English but to understand the prose of Austen, it'd still be worth it. And I'm just discovering the simple elegance of G.G. Márquez in Spanish. He does a similar trick in the first line of Cien años. "Había de recordar" is a future seen from the past, and Spanish carries it without strain. English has to choose between "was to remember" and "would remember", and both just miss it. The sentence sets up the whole book's time scheme in five words, and the beauty of it has to be contemplated.
Sometimes, reading a single passage from a book, I mean truly, deeply, honestly letting it sink into your subconsciousness makes up for all the insufficiencies in the story.
>it's like listening to Bach through the car stereo
Bach sounds great even as chiptunes. The artistic value is mostly in the harmonic development, not the timbre, so sound quality isn't so important. The organ works will suffer a bit without a big subwoofer, but you can get that in a car. Bach composed a lot of his works on a clavichord.
I'm not a musician, I suppose I should have picked a better analogy. Now I'm listening to Mahler and trying to find enlightenment. Thankfully, my desk audio setup is better than my car's.
>I feel enormously fortunate for being fluent in Russian, reading Bulgakov and Tolstoy in original is pure joy, any translation removes subtleties
As a native Russian speaker, I find it easier to experience their writings in English (and I don't feel anything of importance has been lost). And I've also heard other russian speakers claim that English prose (i.e. Shakespeare) is too dry, so I'm assuming this all comes entirely from people's subjective perceptions and is not an objective fact.
I suppose, it may feel easier, because English can be dense, it can feel more compact. Of course, it has this chameleonic ability to implode into scholarly dry, sophisticated and complex language, but yes, when I need more informational throughput, English usually outshines other alternatives - it delivers the point from the page directly into your brain. Although with prose, often it's not the sheer throughput but small subtleties that matter - we read not just for the sake of the fast comprehension of the story. How would you paint the difference between 'сухарь' and 'сухарик' in Russian text, especially if the words are used metaphorically? Of course it is all very subjective - I can only imagine what emotions evoke the arrangement of words I choose to put in this text - they could make you angry or sad, or bring smile or utter indifference. I've read Bulgakov in four different languages, and yet translations never matched pictures the original elicits in my head. "В белом плаще с кровавым подбоем, шаркающей кавалерийской походкой, ранним утром четырнадцатого числа весеннего месяца нисана ..." simply can't be done in another language for me - it just never feels the same.
Shakespeare is dry in English and feels easier in Russian translation because there's such a thing as "archaic English". The Russian language, in comparison, has changed little over the past few hundred years.
For me there are novels with such big pay-offs that they are worth 100s of pages of setup to me. I usually only start them when I read online that they are worth it. I had this with Atlas Shrugged (500-600 pages of setup?).
Some are simply such a nice world (and indeed writing style) that they don’t even really need a Volta. I had that with the Commonwealth Saga by Hamilton. I just wanted it to go on and on (and it does for >2400 pages). (I was sadly disappointed by the follow-ups which are much less "sci"). Same with the Bobiverse books, eagerly awaiting part 6, although I still want to be in that world, it also feels like it should come to some beautiful end before dragging on too long...
> the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done
Perfectly said. It was true before LLMs too.
As I've been reviewing more and more LLM code, I've noticed that while good developers can use LLMs to produce good code maybe 1x-5x faster (depending on circumstances), bad developers can use LLMs to produce bad code 1000x faster. And if you are collecting metrics that only capture that 1000x number, I bet you feel great about what you're doing.
I understand how the Same Origin Policy protects browsers from executing malicious scripts. I also understand how the Access-Control-Allow-Origin header can be used by servers to declare additional origins as trustworthy, relaxing the SOP.
What I still don't understand is what purpose the Access-Control-Allow-Headers header serves. It doesn't seem like it improves security for the browser (and definitely not for the server). Was it included "just for completeness" by the protocol designers? See also https://stackoverflow.com/questions/17992042
> I probably spent over 20 hours debugging, scanning the emu-dev Discord, creating tests, and even throwing the issue at earlier AI models. Nothing worked. But then after a few weeks away from the emulator I tried Claude Opus, and it found the issue in just a few minutes.
Even if you want to write all the code yourself (which is a fine decision), the only reason in 2026 to bang your head against a problem like this for 20 hours is if you really enjoy doing so.
(I'm surprised that "earlier AI models" didn't work for the author. For me, free-tier Gemini gets stuff like this correct all the time.)
I think it's another case of the whole industry being driven by the needs of the very small number of systems that need to handle >10k concurrent requests.
Or biases inherited from deploying on single or dual core 32-bit systems from 20 years ago.
Honestly, it's a mostly obsolete approach. OS threads are fast. We have lots of cores. The cost of bouncing around on the same core and losing L1 cache coherence is higher than the cost of firing up a new OS thread that could land on a new core.
The kernel scheduler gets tuned. Language specific async runtimes are unlikely to see so many eyeballs.
Also very useful for applications that have heavily animated graphical user interfaces, where you don't want I/O to interfere with UI animations on the UI thread. (e.g. ALL android apps. Or any UI framework that has a message pump (all of them?).
Each interval has a unique "flavor" and once you can hear them you should be able to hear multiple intervals at the same time, which effectively identifies the chord. (Admittedly for complex jazz chords it can get very difficult and you probably need more powerful tools, I can't say.)
What's strange is that many people who believe in a Mature Creation (as I've heard it; "Last Thursdayism" is new to me) will readily accept it as the explanation for ancient starlight but then deny evolution and claim that the fossil record is actually evidence of the biblical flood. Which is an unnecessarily weak position to take when you have already accepted a perfectly unfalsifiable cop-out! The truth is that most of them don't want to think too hard about it.
Of course. It's not about being reasonable, it's chasing some emotional need that's unrelated to the truthfulness of the belief. But keep alert for the faith-based beliefs you yourself might find yourself defending with flimsy logic too. It's easy to get sucked into the belief that since all the authorities you respect tell you something is true, then it must be, and you don't have to bother much with how valid your justification is because you already believe the conclusion.
A good self-test is asking yourself how you know the Earth isn't flat. Don't do any research, just try to work it out from what you've already observed and think what makes you believe that conclusion.
I'm not really concerned about the availability of SW dev jobs, but I am concerned about the quality of them. For many companies the velocity (and quality, much to my chagrin) of the code you can produce doesn't really matter. What matters more is whether or not you're building the right thing, and too often you're not. These companies also tend to keep more headcount than seems justified, I think because they are gambling that a few employees are going to do something awesome but they don't know which ones. As AI gets better what will these companies do? I don't think they will fire a bunch of SW devs. I think instead they will embrace the slop and just take more shots, and crazier shots. It doesn't just give us something to do, it also gives a bunch of PHBs something to do.
