> 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.
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.
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.
What does that even mean? Not everything published has to be with the purpose of entertaining. This is a more recent mindset that came with the advent of the "Content Creator" (think Mr.Beast). But it needs not be this engineered. Historically, some of the more interesting channels on YouTube have been people organically sharing something that was genuinely dear to them. Offered with little concern as to whether it's "what people want to watch". They make you want to watch it, because it's a passion that they manage to convey. By contrast, people who are particularly concerned about eyeballs seem to publish with the purpose of meeting the audience's interest as a main guiding factor. And yes, maybe for those, YouTube is a better fit. But I also know many for whom moving to a reliable alternative (tech wise) would be a step up.
If for instance your goal is to share educational content for free, provided that the hosting platform is sound, your main concern as far as your audience finding your content should be that of discoverability. Which is an easy enough kink to iron with current search technology.
This isn't a specifically American phenomenon. Humans have fear buttons. If you press the right ones, a sizable portion of any population would trade in significant amount of freedom to feel safer. Those for whom it's almost pathological spend considerable effort trying to pass on their worries to others, or chasing opportunities to exert some satisfactory control. If they succeed in either goals, you get less freedom.
It's not really about going back. Evolution happens within a pattern of ebb and flow, back and forth. We never get anything perfectly right. We overdo, then course correct, rinse and repeat. Right now, we're embracing AI, but we're also noticing atrophy of skill as an effect. These may be the last generations of such craftspeople that can notice, compare, and inform as to whether there's actual loss. That future you're seeing for yourself is still being written. Stay tuned.
It depends how you store and look things up. There are so many optimization opportunities and strategies to make the lookups fast that this is pretty much a non-issue in practice (e.g. deny list implemented as any combination of runtime or in-memory index, trie, or bloom filter). At the first invalid bit the lookup fails and the token is allowed to proceed to subsequent auth checks. Which should happen quickly for the vast majority. No need to head straight for the worst possible implementations, like whitelist disk lookups.
Every once in a while an article with a sensational title against JWTs pops up in here and I have to wonder if something new was discovered. But nope. It always boils down to the same "can't invalidate it" complaint, which can be addressed with a viable deny list structure (simple in-memory or runtime index, bloom filter, trie). Then there are the vague "it's insecure" claims which when looked at closely, come down to "some people use it wrong".
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.