My first part time dev job as a student featured me walking in on our CEO who showed me he was recompiling his kernel to enable some features. I'm quite sure he was just doing that to impress the students, but at least he knew how to!

Perhaps his secretary showed him?

It's at 1.16, that's fairly typical I believe, a bit low even?

Why did you repeat this comment all over this post?

Their "AI agent" did it.

> It can easily become a pinball of calls around the hierarchy.

This is why hierarchies should have limited depth. I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent but to overwrite some logic.

But if the lineage goes too deep, it becomes hard to follow.

> every time you modify a class, you must review the inner implementation of all other classes in the hierarchy, and call paths to ensure your change is safe.

I'd say this is a fact of life for all pieces of code which are reused more than once. This is another reason why low coupling high cohesion is so important: if the parent method does one thing and does it well, when it needs to be changed, it probably needs to be changed for all child classes. If not, then the question arises why they're all using that same piece of code, and if this refactor shouldn't include breaking that apart into separate methods.

This problem also becomes less pressing if the test pyramid is followed properly, because that parent method should be tested in the integration tests too.

> I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent

That's the point: You can reuse code without paying that price of inheritance. You DON'T have to expect co-recursion or shared state just for "code-reuse".

And, I think, is the key point: Behavior inheritance is NOT a good technique for code-reuse... Type-inheritance, however, IS good for abstraction, for defining boundaries, to enable polymorphism.

> I'd say this is a fact of life for all pieces of code which are reused more than once

But you want to minimize that complexity. If you call a pure function, you know it only depends on its arguments... done. If you can a method on a mutable object, you have to read its implementation line-by-line, you have to navigate a web of possibly polymorphic calls which may even modify shared state.

> This is another reason why low coupling high cohesion is so important

exactly. Now, I would phrase it the other way around though: "... low coupling high cohesion is so important..." that's the reason why using inheritance of implementation for code-reuse is often a bad idea.

Great points, especially on state management.

I actually can't imagine for the life of me why I'm defending OOP implementation hierarchies here- I guess I got so used to them at work, I've changed my strategy from opposing them to "it's okay as long as you use them sparingly". I have found that argument to do a lot better with my colleagues...

> You can reuse code without paying that price of inheritance.

The same pinball of method calls happens at almost exactly the same way with composition.

You save some idiosyncrasies around the meaning of the object pointer, and that's all.

That's not true. If Outer has a member Inner, Outer always has to invoke `my_inner.foo()` to use Inner::foo, and `foo()` always refers to Outer::foo (and some languages will force you to write `self.foo()`, which is even better).

If Outer extends Inner, though, you can't tell whether `foo()` refers to Inner::foo or Outer::foo without checking to see whether Outer overrides foo or not. And the number of places you have to check scales linearly with the depth of the inheritance hierarchy.

How so? Not sure what you mean.

If object A calls a method of object B (composition), then B cannot call back on B, and neither A nor B can override any behavior of the other (And this is the original core tenet of OO: being all about "message-passing").

Of course they can accept and pass other objects/functions are arguments, but that would be explicit and specific, without having to expose the whole state/impl to each other.

> or some other incredibly specific-to-you ability youve added?

You're saying this with derision, but the ability to quickly add "incredibly specific-to-you" features is precisely what is so cool about it!

That was an impressive result, but AIUI not an example of "coming up with and proving (preferably numerous) significant new theorems without human guidance".

For one thing, the output was an algorithm, not a theorem (except in the Curry-Howard sense). More importantly though, AlphaEvolve has to be given an objective function to evaluate the algorithms it generates, so it can't be considered to be working "without human guidance". It only uses LLMs for the mutation step, generating new candidate algorithms. Its outer loop is a an optimisation process capable only of evaluating candidates according to the objective function. It's not going to spontaneously decide to tackle the Langlands program.

Correct me if I'm wrong about any of the above. I'm not an expert on it, but that's my understanding of what was done.

I'll concede to all your points here, but I was nevertheless extremely impressed by this result.

You're right of course that this was not without human guidance but to me even successfully using LLMs just for the mutation step was in and of itself surprising enough that it revised my own certainty that llms absolutely cannot think.

I see this more like a step in the direction of what you're looking for, not as a counter example.

Yes, it's a very technical and circumscribed result, not requiring a deep insight into the nature of various mathematical models.

"Fear not the bugs citizen! For in my utility belt, I have REGEX and VIM!"

If I had to audit security services for exposing homelab to the internet, I wouldn't use those services in the first place. I'm fine trying things out, but this is a very important security boundary, and it's a solved problem. Why risk it with an auditor who does it for a hobby (me)?

> Imagine if every time you got into your car, you had to manually approve the engine's use of oil, the tires' use of air, and the radio's use of electricity. It’s absurd, right? You’d set your preferences once, and the car would just work.

A funny comparison to me. Actually, I have to manually disable some EU regulated features every time I get into my car. The alerts every time I go 1kmph over the speed limit aren't very relevant for me, and the lane keep alert buzzes as soon as I'm slightly over halfway to the left, but lets me drive along fine if I'm even over the line on the right.

I'd actually like to use both of these, but only if I could calibrate them to my needs.

...

Just like cookie banners.

Search on forums/etc for your particular car brand about which compatible scan tool to get (you want the manufacturer-specific one to be able to change settings, not the generic OBD2 which only lets you read engine & emissions data), get one and then disable the setting. Those are typically controlled via settings so that the same car can be sold in different regions.