default-kramer

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.

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.

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.

> 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.

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.

> 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.

Interval training will help https://www.musictheory.net/exercises/ear-interval

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.

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.

You're right, but for EDM this was pretty much already the case. The scene survives in large part thanks to DJs who wade through countless mediocre tracks looking for the few hidden gems to deploy at the right moment. I think AI means that DJs will become much more important in all genres.

> But for the time being there remain a few things that humans can do very easily which computers find difficult. Along with counting traffic lights and crosswalks, one of those things is finding the exact BPM of a song. Not an estimate like most software does, but the exact value with extreme precision across the entire song.

I thought BPM detection has been extremely precise for some time now (for electronic music anyway). Does this mean when software like Mixxx reports (for example) 125 BPM the raw output of the algorithm might have been 124.99, but some higher logic replaces it with an even 125?

I formerly worked for a travel company. It was the best codebase I've ever inherited, but even so there were select N+1's everywhere and page loads of 2+ seconds were common. I gradually migrated most of the customer-facing pages to use hand-written SQL and Dapper; getting most page loads below 0.5 seconds.

The resulting codebase was about 50kloc of C# and 10kloc of SQL, plus some cshtml and javascript of course. Sounds small, but it did a lot -- it contained a small CMS, a small CRM, a booking management system that paid commissions to travel agents and payments to tour operators in their local currencies, plus all sorts of other business logic that accumulates in 15+ years of operation. But because it was a monolith, it was simple and a pleasure to maintain.

That said, SQL is an objectively terrible language. It just so happens that it's typically the least of all the available evils.

Every time I've worked on a project that used AutoMapper, I've hated it. But I'll admit that when you read why it was created, it actually makes sense: https://www.jimmybogard.com/automappers-design-philosophy/

It was meant to enforce a convention. Not to avoid the tedium of writing mapping code by hand (although that is another result).

> But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change

You are describing the "microservice architecture" that I currently loathe at my day job. Fans of microservices would accurately say "well that's not proper microservices; that's a distributed monolith" but my point is that choosing microservices does not enforce any kind of architectural quality at all. It just means that all of your mistakes are now eternally enshrined thanks to Hyrum's Law, rather than being private/unpublished functions that are easy to refactor using "Find All References" and unit tests.

I think you're underestimating the huge variety of productive apps in existence. For every system that handles >1M requests per second, there are probably at least 10 systems that won't even see 1M requests per hour. For example: Twice I've worked on apps for configuring motor control centers. I think you would consider these "productive" apps, but even if we had 100% market share there just aren't that many people in the world who need to configure a motor control center on any given day. The world is full of such apps.

> most productive applications work at similar scale

What do you mean by "productive" here? The overwhelming majority (probably >99%) of billed/salaried software development hours are not spent working on FAANG-scale software. Does none of that count as "productive"?

It's not insane. The best codebase I ever inherited was about 50kloc of C# that ran pretty much everything in the entire company. One web server and one DB server easily handled the ~1000 requests/minute. And the code was way more maintainable than any other nontrivial app I've worked on professionally.

I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.

Hmm, maybe, but somehow Marvin Gaye's estate still pulled it off. Yes it was a copyright case, not a patent case, but Robin Thicke and Pharell Williams had a well-funded defense. Seems like Nintendo could easily bully an indie game out of existence if they wanted to.

I've done something like that too. I also noticed that enums are even lower-friction (or were, back in 2014) if your IDs are integers, but I never put this pattern into real code because I figured it might be too confusing: https://softwareengineering.stackexchange.com/questions/3090...

I think checked exceptions were maligned because they were overused. I like that Java supports both checked and unchecked exceptions. But IMO checked exceptions should only be used for what Eric Lippert calls "exogenous" exceptions [1]; and even then most of them should probably be converted to an unchecked exception once they leave the library code that throws them. For example, it's always possible that your DB could go offline at any time, but you probably don't want "throws SQLException" polluting the type signature all the way up the call stack. You'd rather have code assuming all SQL statements are going to succeed, and if they don't your top-level catch-all can log it and return HTTP 500.

[1] https://ericlippert.com/2008/09/10/vexing-exceptions/

To be fair, Persona 5 is my least favorite out of 3/4/5. Most fans of the series agree it's embarrassingly easy. Persona 3 (Portable is best, or FES if you're a masochist, but not Reloaded) offers a perfect challenge on the hardest difficulty, and Persona 4 was pretty well-tuned also. It wouldn't surprise me if P6 was closer to P4 or P3 than P5.

Not so much with video games. The industry is so young that most of those "classics" are actually much less fun than I remember them. (Super Mario World does hold up very well though.) But since you mention Persona, consider how much better Persona 3 Portable is than Persona 3 FES. Game design has come a long way, and I believe it still has a long way to go. Not to mention the technical improvements that allow a game like Uncharted to exist, which cannot be compared to any 16-bit or earlier game.

I strongly prefer FP over OOP, but... Is there any desktop GUI library that isn't built on subclassing? Winforms, WPF, Swing, Qt, Godot all do. This doesn't prove that subclassing is necessary, but it sure seems like the best approach we've found so far.

How many people actually write exhaustive tests for everything that could possibly be null? No one I've ever met in my mostly-C# career.

I can confirm that at least 30% of the prod alerts I've seen come from NullReferenceExceptions. I insist on writing new C# code with null-checking enabled which mostly solves the problem, but there's still plenty of code in the wild crashing on null bugs all the time.

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

And it's not obvious thanks to the logarithmic scale... There must have been a better way to present this information.