terminatortwo

Thanks for linking this. I hope ars makes it more visible. I’ll have to take Benj’s word.

That’s the thing with trust, hard to build, easy to burn.

S[ai] be[lie]ve[d]

They already posted their response: https://arstechnica.com/staff/2026/02/editors-note-retraction-of-article-containing-fabricated-quotations/

EDIT: it’s the lack of acknowledgement that they didn’t discover it but the contributor had to go in and correct it, how they locked and deleted the article, etc. I was expecting a bit more tbh

but what if the car lied though.

Same. It’s what I use, I love that you can also BUY music though. Hard to recommend because their user experience needs a lot of work. (Eg. Can’t even change the language. Since I’m in Germany I have no choice but to use German for the ui)

What a shame. I’ve subscribed to ars for years. Their response was disappointing, it doesn’t talk about what happened and what they’re doing to make sure it doesn’t happen again.

Nothing about how they handled them makes me trust that they won’t do it again.

I’m pretty sure it lies

Teenagers are one of the most underserved demographics in cities. There’s very few if any third places designed for teenagers. Children and adults both have recreational areas designed for them, but teenagers are considered a nuisance almost anywhere.

This is a failure of urban design.

In this case I think they mean iPhone 9, which I’m still saving my money for

In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.

Sure, I agree it can be. But it doesn’t make it less true that “it depends” is often the answer. As I see it, my job is often to think “what applies in this case”. Including thinking about things like:

• what matches the mental model the company has about this
• what’s the shape of the problem
• what type of abstractions do we already use
• what aspect do I want to make available, how is this expected to change?
• etc

Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.

Sure. I lean towards object oriented design when things represent a simple well known object with a stable set of “nouns and verbs” that are unlikely to change. In my case this tends to be around UI elements or the data layer very basic things, where I don’t care too much about “data transformation”, but want to encapsulate an action (eg. I think being toggleable is intrinsic to a switch, so switch.toggle feels like a stable api and I can design an object like this that others can understand without having to care about the internals)

Some design patterns that come from the oop tradition (not exclusive to oop, but very much part of the toolkit) that I find exceptionally useful. For example, the strategy pattern is something I’ve used often when building things like data exporter and importer tools. I can structure my logic in this way, move all the specific logic to the leaves.

I can’t be exhaustive, but for me oop is all about encapsulation, and so I use it when it calls for that. I think it also makes APIs easy to test.

——

Functional programming I absolutely love. Whenever I’m transforming data, i think in functional terms. Composable functions, immutable data. It’s just a lot easier, and for me it makes it easier to test processes and operations. I tend to lean to this this in a business logic layer. If I can describe operations in a way that we talk about them in the company, and make those units of transformation testable, then bigger processes become safer and auditable.

Another thing from functional programming languages that I love is things like algebraic data types. It just pains me to use a language without sum types now.

——

A while back I used “aspect oriented programming”. That didn’t catch on, but moving some things like logging, event tracking, etc. to aspects makes sense to me. If a language supports function annotations, I /will/ try to move those sorts of aspects to a function annotation.

——

I spent a while doing prolog, and that language is just something else. I wish I had an easy to embed prolog that I could use for constraints on data. This one I don’t “get to mix and match” because multi purpose languages don’t include aspects of it. But thinking in terms of reversing operations (eg. Given this result, what set of constraints produce it) is still a tool that helps me understand how to shape a problem.

——

There’s a lot of nuance to this, more than can fit in a comment, and definitely nuance that doesn’t apply to imaginary problems or problems/sotuations that we don’t share. Also, you and others will probably think about it differently. to me that’s kind of the point, both thinking in terms of a diverse toolkit, and having a team with diversity of thought.

I always find it funny to see calls to “unlearn oop”. It’s a tool, useful in some contexts and not useful in others. At some point industry treated it like a silver bullet, and now people are reacting to it by checks notes treating the hot new paradigm as a silver bullet.

learn oop, learn fp, learn logic programming, learn whatever you want. Also, learn when not to use them.

I mean, you can see it if you want, there’s MPL code and nightly builds. It’s the best shot at ending the browser monoculture and it’s progressing steadily!

Scaleway is a good alternative. It’s not as comprehensive as the other clouds (yet) but it has improved a lot and has good customer service.

For most services, their serverless functions, containers, NATS, RDS stuff is enough. They also provide a hosted grafana (they call it cockpit)

Their IAM needs to get more granular, I found that to be the biggest sore point.

the one thing that made my life better in this regard is: draw/write as you think.

The “poof” still happens, but you have a save state.

Seriously: my notebook is my best tool.