mekoka

> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.

Is it? How long do you expect to keep your momentum after "taking over the market"?

Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.

Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.

It's the same thing as the "oh no, we need to figure something out for our youth on the verge of obsolescence" narrative. It's all about giving an impression of unfathomable power. They don't care that in actuality, the tech will end up as just an augment, not a replacement for said youth.

> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.

I'd be prudent to use a clear faux-pas by a BDFL as an argument to push for an alternative, seemingly more consensual, leadership style. I'd also be careful to fall for the apparent lack of overt aggression in the latter type of structures, as a necessarily positive signal. I've seen people in various such communities (including the two cited languages) that have chosen not to interact with their steering committees, because of perceived toxicity.

This can and does happen with any kind of structure and can take many shapes, some of whom are too subtle or passive to even accurately pinpoint, in the way you would for example directly index a BDFL. In The Tyranny of Structurelessness Jo Freeman made the case that the lack of a clear structure in the make up of a movement presents with opportunities for very fuzzy power dynamics and related abuses that are also much more challenging to deal with.

As entertaining as that article was when it came out, I think its apparent wisdom should have been reevaluated for at least the past two decades. Even back when it was written, its pertinence was questionable, since it hinged on the perception that written code has particular value, to justify much of the failures at Netscape and Borland, neglecting many of the other -- probably more relevant -- business and human factors that were at play within the two organizations and their surrounding ecosystems. But lessons learned from watching startups fail in trove in the following two decades have mooted many of Joel's arguments. With the vantage of hindsight, if you read JWZ's account of what went on at Netscape, some of the dysfunctions become glaring.

Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.

Short publication intervals. That's the heuristic you're going with? I have dozens of such unpublished long form articles on fundamental topics, just waiting for me to carve some time to polish. I expect that on a sabbatical I could finish and post them in quick succession. It's an unreliable indicator to determine AI-writing.

Being dismissive is one way to think yourself "better" than others. But on HN hastier reactions tend to be outright negative or out of context with long articles, as eyeballs actually evaluating the content will take some time before providing constructive criticism.

How were you able to pick this up? Not challenging your assertion. Just really curious. Can you point to some clues? I read it (with my own eyes). I can't see actual evidence the text itself is artificial or at least, that it is not human-curated.

Ignorance will always be a better starting point for discovery than wrong assumptions. If you leave comments, they must reflect what the code is actually doing. If during edit it's no longer the case, at least mark them as stale. The next best thing is indeed to remove them.

The article had great advice on this actually. When asked how to get into C, or whether it was more advisable to learn Zig instead, Mitchell suggested that

It’s more important to learn how computers work and make the language just a means to understanding how they work. [...] even in this age of higher level abstractions and web development, it’s still important to understand the basics of CPU scheduling, memory, cache hierarchies, file systems, disc and file access. When you work directly above the syscall layer, whether in C, Zig or Rust, it really helps you understand what’s happening[...]

> If this is the ideal model, why don't authors skip the middleman themselves and just put the .pdf/.epub on their website directly in exchange for donations?

> On the same note, why do game devs need to give Steam 30% of their money and not just sell to the public directly and pocket the 30%?

We're needlessly making this into a general problem. Why hastily discuss ideal models? The current model is fine and the issue isn't generalized. We're talking about having the option to skip asshole middlemen, or to be more specific, Amazon. A company so big that solving this special case on its own leaps us a huge portion of the way into solving the problem at large.

Is the general sentiment that Steam is also an asshole?

Using an ORM should not exempt you from designing your schema around the domain. If anyone thinks it's the case they're either using the ORM wrong, or using the wrong ORM, or perhaps creating the wrong ORM.

Similarly, designing your schema to match the domain does not necessarily grant you the productivity boons of an ORM.

Having (ab)used Postgres with and without ORM, I've never had a situation where the latter imposed any kind of design decisions on the schema. They're orthogonal concerns. Itself, the choice of using an ORM tends to be motivated by experience with certain requirements in the business logic. I love SQL, but when having to deal with API resources and their various representations, marshaling, validation, options, etc, it's difficult -- and to say the least, impractical -- to stay principled to the "no-ORM" and "raw-SQL" mottos.

You stopped right before the best part. When they decide to create their own ill designed, badly tested, and undocumented mapper.

> you give up so much in performance.

Not really. ORMs (memory) and databases (disk) are distant by multiple orders of magnitude performance wise. Skipping the ORM to shave off some cycles is akin to haggling over a few pennies on your thousand dollars bill.

> It’s doing more harm than good.

For context

Can we PUHLEASE stop this AI Confidence Theater, people? It’s doing more harm than good.

The word "entertain" quickly came to mind in that sentence because attracting the audience as a primary concern is typical of the entertainment industry, regardless of the content being educational, news, or otherwise. If we get stuck on that choice of a word, it's admittedly a bit narrow for the point I was making, but I think the rest of my post successfully got things across.