Specifically, I'm not a "designer", but I regularly end up making/changing UIs (mobile apps, web apps/pages, etc). When it comes to design, it really matters who the target audience is.

If you're creating a UI for "mass market", you have to design to a lowest-common-denominator that balances what your average user expects, generally, from UI/UX, and the more you ask them to "invest", the worse you're going to do. On the other hand, if you're making a tool for a B2B (business-to-business) product, you have more freedom to set baseline expectations of what the end user needs to be able to do and understand. You can also expose more powerful options, etc. You can sometimes end up going in very different directions. Even error handling and logging can sometimes be handled differently, depending on the context.

There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable state in a given context makes it easier to reason about.

So, if you're inside a function scope and you aren't launching any concurrent operations from inside that function, you don't have to worry about benefit #1. If you're inside a function (and you're not reaching out for global mutable state), then the context you need to keep in your working memory is likely fairly small, so a few local mutable variables doesn't significantly harm "understandability" of the implementation (in most cases). So, you really don't have to worry about #2, either. Make your functions black boxes with solid "APIs" (type signatures), and let the inside do whatever it needs to make it work the best.

Just because premature optimization is the root of all evil, it doesn't mean we need to jump right to premature pessimization...

I'm still skeptical that this is the case with Postel's Law, but I do see that it's possible to read it that way. I guess I could always go do some research to prove it one way or the other, but... nah.

And yes, "Parse, don't validate." is one of my absolute favorite maxims (good word choice, by the way; I would've struggled on choosing a word for it here).

Hyrum's Law is pointing out that sometimes the new field is a breaking change in the liberal scenario as well, because if you used to just ignore the field before and now you don't, your client that was including it before will see a change in behavior now. At least by being strict, (not accepting empty arrays, extra fields, empty strings, incorrect types that can be coerced, etc), you know that expanding the domain of valid inputs won't conflict with some unexpected-but-previously-papered-over stuff that current clients are sending.

So, I think not crashing because of invalid input is probably too obvious to be a "law" bearing someone's name. IMO, it must be asserting that we should try our best to do what the user/client means so that they aren't frustrated by having to be perfect.

But, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP all the time and it's still a terrible language even in 2026)

It used to frustrate me that people didn't care about their own privacy, because I genuinely didn't want evil people to hurt them. But, it's even more angering that people don't have the common decency to consider whether their friends and family would want them sharing their phone numbers, email addresses, photos of them, etc.

Why would someone try to force me off of my browser (that has ad-blocking and tracker-blocking mitigations) and on to a locked-down app that may want permission to run in the background, display notifications, access my files or camera, etc?

Maybe it really is to "improve my experience"... yeah, right.

The idea that making things immutable somehow fixes concurrency issues always made me chuckle.

I remember reading and watching Rich Hickey talking about Clojure's persistent objects and thinking: Okay, that's great- another thread can't change the data that my thread has because I'll just be using the old copy and they'll have a new, different copy. But now my two threads are working with different versions of reality... that's STILL a logic bug in many cases.

That's not to say it doesn't help at all, but it's EXTREMELY far from "share xor mutate" solving all concurrency issues/complexity. Sometimes data needs to be synchronized between different actors. There's no avoiding that. Sometimes devs don't notice it because they use a SQL database as the centralized synchronizer, but the complexity is still there once you start seeing the effect of your DB's transaction level (e.g., repeatable_read vs read_committed, etc).

I disagree. Not every single article or essay needs to start from kindergarten and walk us up through quantum theory. It's okay to set a minimum required background and write to that.

As a seasoned dev, every time I have to dive into a new language or framework, I'll often want to read about styles and best practices that the community is coalescing around. I promise there is no shortage at all of articles about Swift concurrency aimed at junior devs for whom their iOS app is the very first real programming project they've ever done.

I'm not saying that level of article/essay shouldn't exist. I'm just saying there's more than enough. I almost NEVER find articles that are targeting the "I'm a newbie to this language/framework, but not to programming" audience.

I didn't look up this syntax or its rules, so I'm just reading the code totally naively. Am I to understand that the `user` variable in the final return statement is not really being treated as a value, but as a reference? Because the second part of the return (json.NewDecoder(resp.Body).Decode(&user)) sure looks like it's going to change the value of `user`. My brain wants to think it's "too late" to set `user` to anything by then, because the value was already read out (because I'm assuming the tuple is being constructed by evaluating its arguments left-to-right, like I thought Go's spec enforced for function arg evaluation). I would think that the returned value would be: `(nil, return-value-of-Decode-call)`.

I'm obviously wrong, of course, but whereas I always found Go code to at least be fairly simple--albeit tedious--to read, I find this to be very unintuitive and fairly "magical" for Go's typical design sensibilities.

No real point, here. Just felt so surprised that I couldn't resist saying so...

That's when and why I decided to point out that there are different kinds of software projects, and they have different goals and priorities. It's like the old "library vs. application" code: libraries are generic and reusable, and should be written as such, whereas applications are specific and focused.

I brought up GTK simply as an example of a "library project", for which critique of its reusability is warranted, as a counter-example to Mutter, which is an application. Complaining about Mutter's effect on "the ecosystem" is silly. It wouldn't make any less sense to complain about XTerm's effect on the ecosystem by it not supporting Wayland. Anybody in their right mind would just say "So, use one of the other 10,000 terminal emulators in Wayland instead of XTerm"--and rightly so. But, because Mutter is a GNOME project, and GTK is also a GNOME project, I think that people lose focus on what they're talking about.

I did engage with you about GTK because it's interesting, but my point in bringing up GTK was specifically to say "Yeah, those complaints might make sense if we were talking about GTK, but since we're talking about Mutter, they do not." to the comment I replied to.

At the risk of sounding snarky and/or unhelpful, in my experience, the answer is that you don't try to optimize Python code beyond fixing your algorithm to have better big-O properties, followed by calling out to external code that isn't written in Python (e.g., NumPy, etc).

But, I'm a hater. I spent several years working with Python and hated almost every minute of it for various reasons. Very few languages repulse me the way Python does: I hate the syntax, the semantics, the difficulty of distribution, and the performance (memory and CPU, and is GIL disabled by default yet?!)...

But, otherwise, I'd agree that strings probably win, globally.

This Xfce dev says that GTK4 is less capable than GTK3, and they feel that GTK5 will continue in that direction. They also acknowledge certain things in the first comment:

> [0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me.

>

> [1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.

If the GNOME guys took out stuff from GTK4 or 5 for bad reasons, then I don't like that, either. Which is basically exactly what I said. However, it sounds like some of these changes would be hard to do and maintain well, such as cross-process embedding. Perhaps the GNOME devs made a decision to focus their surely limited resources toward things they think will be long-lasting. And, perhaps, by their estimation, trying to support Wayland and X11 by adding (and maintaining) tens of thousands of lines of code would be a big burden--especially if they believe that X11 is not going to be super-relevant in the near future. I don't agree with that estimation, and I assume that it'll be a very long time before X11 isn't necessary anymore, but so be it.

All that said, it still has nothing to do with Mutter, which is why I replied to the comment that I did. Because GTK, and Mutter, and GNOME Shell, and GNOME apps, and non-GNOME GTK apps, are all different things, and this post was about Mutter.