To use a simple analogy: you could argue that a modern Macbook is easier to maintain than an old Dell desktop, if the Macbook is owned by a certified Apple technician who knows how to microsolder, and the old Dell desktop is owned by someone who doesn't know how to use a screwdriver. But that doesn't change that, to change a hard drive, one needs much more skill and fancier tools than the other.

Explain how?

Code evolvability is one of the extrinsic quality markers ( https://www.pathsensitive.com/2023/07/the-11-aspects-of-good... ).

If it's easy to add new features without creating bugs, the code is evolvable. Else, it's not. Does not seem very subjective.

People who care about code quality are not artists who want to paint on the company's dime. They are people who care about shipping a product deeply enough to make sure that doing so is a pleasant experience both for themselves and their colleagues, and also have the maturity to do a little bit more thinking today, so that next week they can make better decisions without thinking, so that they don't get called at 4 AM the night after launch for some emergency debugging of an issue that that really should have been impossible if it was properly designed.

> No one has ever made a purchasing decision based on how good your code is.

Usually they don't get to see the internals of the product, but they can make inferences based on its externals. You've heard plenty of products called a "vibe-coded piece of crap" this year, even if they're not open source.

But also, this is just not true. Code quality is a factor in lots of purchasing decisions.

When buying open source products, having your own team check out the repo is incredibly common. If there are glaring signs in the first 5 minutes that it was hacked together, your chances of getting the sale have gone way down. In the largest deals, inspecting the source code

It was for an investment decision rather than for a purchase, but I've been personally hired to do some "emergency API design" so a company can show that it both has the thing being designed, and that their design is good.

Unfortunately, I concluded that Bombadil is a toy. Not as in "Does some very nice things, but missing the features for enterprise adoption." I mean that in a very strong sense, as in: I could not figure out how to do anything real with it.

The place where this is most obvious is in its action generator type. You give it a function that generates actions, where each action is drawn from a small menu of choices like "scroll up this many pixel" or "click on this pixel." You cannot add new types of actions. If you want to click on a button, you need it to generate a sequence of actions to first scroll down enough, and then look up a pixel that's on that button.

Except that it selects actions randomly from your list, so you somehow need the action generator, when run the first time, to generate only the scroll action, and then have it, when run the second time, generate only the click action. If you are silly enough as to have an action generator that, you know, actually gives a list of reasonable actions, you'll get a tester that spends all its time going in circles clicking on the nav bar.

(Something in the docs claimed that actions are weighted, but I found nothing about an actual affordance for doing that. Having weights would make this go from basically impossible to somewhat impossible.)

(Edit: Found the weighted thing.)

I am terrified to imagine how to get Bombadil to fill out a form. At least that seems possible -- you can inspect the state of the web page to figure out what's already been filled out. But if you want the state to be based on anything not on the current page, like the action that you took on the previous page, or gasp the state on disk (as for an Electron app), that seems completely impossible. Action generators are based on the current state, and the state must be a pure function of the web page.

Its temporal logic has a cool time-bounded construct, but it's missing the U (until) operator. One of their few examples is "If you show the user a notification, it disappears within 5 seconds." But I want to say "When you click the Generate button, it says 'Generating...' up until it's finished generating." And I can't.

(Note: everything above is according to the docs. Hopefully everything I said is a limitation of the docs, not an actual limitation of the framework.)

I shared my comments with the author yesterday on LinkedIn, but he hasn't responded yet. Maybe I'll hear from him here.

I have a pretty positive opinion of Antithesis as a company and they seem to be investing seriously in it, and generally see it as a strong positive sign when someone knows what temporal logic is, so I have hopes for this framework. I am nonetheless disappointed that I can't use it now, especially because I was supposed to finish an internal GUI testing tool this week and my god I'm behind.

But here you're asking to put the reader to put in more work than you did, to find an insight that may or may not be there.

What is your picture of the moment-by-moment thoughts of someone who would click this and upvote?

This article hits on a pet peeve of mine.

Many companies and individuals can benefit from better processes, communication skills, and training.

And also people who proclaim "Most technical problems are people problems" and "It's not what you know, it's who you know" are disproportionately those who are attempting to influence others that "My skillset is more valuable than your skillset." The people who believe the opposite are heads-down building.

The truth is that nearly all problems are multifactorial and involve long chains of causality. They can be patched at multiple points.

And so while there are standard stories about "If you do the 5 Why's and trace back causality, the issue becomes a deeper human problem," you can nearly always do something else and find an alternative technical solution.

The standard story goes: "This thing failed because this this other thing crashed, because this thing was misconfigured, because the deployment script was run incorrectly, because no-one trained Bob how to use it." See, the human problem is the deepest one, right?

But you can find an alternate technical fix: why was it possible to run the deployment script incorrectly?

Or you can ping-pong it back into a technical problem: he wasn't trained because everyone is stressed with no time because things keep breaking because of bad architecture and no CI. So actually the technical problem is deepest.

But no, because that only happened because the CEO hired the wrong CTO because he didn't know anyone who could evaluate it properly....

...which only happened because they didn't use (technical problem)

...which only happened because said startup didn't have good enough marketing (human problem)

...which only happened because they were too slow to build from their own tech debt and didn't have the money (technical problem...)

And so on. Ping, pong.

The article says: we had too much tech debt because humans weren't trained enough.

One can also say: we had too much tech debt because we didn't have good enough linters and clone detectors to keep out the common problems, and also we had made some poor technical choices that required hiring a much larger team to begin with.

If you have a pet problem, you can always convince yourself that it's responsible for all woes. That just keeps you from seeing the holistic view and finding the best solution.

So basically:

Generic function F is defined in file A, and has a method definition DEF in file B.

File C imports files A and B, and then calls function G that internally uses generic function F. Somewhere internally, it winds up running F with method definition DEF.

You move DEF to file D, but don't update the imports of file B.

When file B calls G, it calls F with some default implementation instead of DEF, and then you get an error from function G.

Some details here might be wrong over how exactly to imports need to be set up, as I haven't used Julia being traumatized by it 6 years ago, but that's basically it.

In Julia, the (+) function is commonly overloaded

The [] is as well. For things that have no shared interface. (E.g.: Int64[1][1] contains two calls to the [] generic function, which have no interface in common.)

Plenty of definitions of (+) are not commutative. E.g.: for strings.

There is some package which uses the (+) generic function internally, meant to be used on numbers. You call it instead with some kind of symbolic expression type. And it just works. Yay! This is the kind of stuff Julia afficcionados preach.

Then suddenly the package gets updated so that it uses (+) in a way which assumes commutativity.

Your code breaks.

In your world, how would you be notified of a change that some internal use of the (+) function now assumes commutativity?

Or when Julia afficionados preach the amazingness of being able to just throw a differential operator or matrix or symbolic whatever in a place, are they just overselling something and should stop?

There is only one language that I have an active hatred for, and that is Julia.

Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right?

In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's code.

The reason is that this causes modules that don't import the new file to have different implementations of the same generic function in scope. Julia features the ability to run libraries on data types they were never designed for. But unlike civilized languages such as C++, this is done by randomly overriding a bunch of functions to do things they were not designed to do, and then hoping the library uses them in a way that produces the result you want. There is no way to guarantee this without reading the library in detail. Also no kind of semantic versioning that can tell you when the library has a breaking change or not, as almost any kind of change becomes a potentially-breaking change when you code like this.

This is a problem unique to Julia.

I brought up to the Julia creators that methods of the same interface should share common properties. This is a very basic principle of generic programming.

One of them responded with personal insults.

I'm not the only one with such experiences. Dan Luu wrote this piece 10 years ago, but the appendix shows the concerns have not been addressed: https://danluu.com/julialang/