What I didn’t like about this series of books was choosing “garbage collection” as umbrella term for both tracing GC and reference counting, without verifying if programming community would agree with that, which turned out they didn’t.
I’ve seen a lot of threads here and on reddit where people were arguing about terminology purely because of this book alone.
By that definition, C++ code has garbage collection if it uses std::shared_ptr, going against widespread common usage of the term “garbage collected programming language” which specifically contrasts manual languages like C++ or Rust against garbage collected ones.
“Automatic Memory Management” is a lot more suitable description to what programmers have to do to manage memory; it is now in the title but still hasn’t become the primary term.
> What I didn’t like about this series of books was choosing “garbage collection” as umbrella term for both tracing GC and reference counting, without verifying if programming community would agree with that, which turned out they didn’t.
This has been the standard terminology in memory management research for many decades. The only programmers who don't like it are those who don't understand the principles of memory management.
> By that definition, C++ code has garbage collection if it uses std::shared_ptr
That's right.
> going against widespread common usage of the term “garbage collected programming language” which specifically contrasts manual languages like C++ or Rust against garbage collected ones.
Since this contrast mostly exists in the minds of people who don't understand memory management, going against this common misconception is good. That's not to say that there aren't some interesting tradeoffs that often align with the colloquial perception, "garbage collection" isn't the interesting part. As you said, both C++ and Rust use GC; in fact, they use a GC somewhat similar to the one used by CPython.
This reminds me a bit of the way academics in programming language theory internalized the type-theoretic definition of the word “type” over and against the traditional programming definition. You sometimes see people who try to correct the term “dynamically typed language,” which makes perfect sense when types are data types, to “untyped” or “unityped,” which makes sense when types are mathematical constructs equivalent to proofs.
The colloquial term is clear in context, and it draws its boundaries in useful places. If academia prefers other boundaries to simplify its formal definitions, that’s understandable. But the rest of us shouldn’t restrict our language in that way.
It's not about restricting the language. It's that practising programmers often don't know a subject well enough, so they use different words to make distinctions that don't matter as much as they think (see "transpile"). "Dynamically typed" is actually not that big of an offence (because the distinction is real, it's just that the terminology is a bit muddled), and the people in PL theory who are bothered by this (most notably one person) are considered pedants even among their colleagues.
E.g. many practising programmers don't know that tracing moving collectors are used to avoid some of the high overheads associated with memory allocators (malloc/free), which are themselves big and complex beasts that make up substantial "runtimes" (another misused and misleading word).
I think GC's definition is pretty clear cut. How is counting references to determine when a lifetime ends materially different from another way of doing the same thing? Like there is even a paper that shows that one is tracking liveness, while the other tracks "deadness" and they are literally going at the same thing from different ends.
If anything, I often see a bias against tracing GCs from the people misusing the term, to "hype up" their choice of language that it must be better for not having (tracing) GC, when it usually just has ref counting which in many metrics is actually worse, given equal usage -- rust/cpp gets away from that because they only use it on a handful of objects, other lifetimes being driven by RAII, which is pretty much just compile-time decidable ref counting?
Right, and there are differences within tracing GCs that are just as big as between refcounting (and even manual malloc/free) and tracing. For example, Go uses tracing to determine when an object lifetime ends. But the moving collectors in Java, .NET, and V8 don't know and don't care when objects die, and they have no "free" operation at all. In many ways, the performance profile (of favouring smaller footprint or higher throughput) of memory management in C++, Rust, Python, and Go share more similarities among themselves than Java, .NET, V8, and Zig, which also share a more similar profile (arenas, like moving collectors, don't need or want to know when an object's lifetime ends).
Another distinction without a difference that is really just giving a name to a misconception is the notion of "a runtime". When I learnt C in the late 80s or early 90s, the book said something like, "C is not just the language, but a rich runtime". Indeed, modern malloc/free implementations mean that a C program ends up needing a larger and more elaborate runtime than a program in some educational language that uses a trivial implementation of a mark-and-sweep collector. Modern malloc/free allocators also sometimes come with an impressive set of tuning knobs. It's just that people who haven't had a lot of experience writing large programs in low-level languages don't know about them (or they just work to avoid allocations as much as possible, because that's what they've been told to do).
> Like there is even a paper that shows that one is tracking liveness, while the other tracks "deadness" and they are literally going at the same thing from different ends.
I think a lot of people just want to be able to discuss different areas of the automatic memory management design space separately, and maintaining the distinction between reference counting and garbage collection (meaning tracing GCs) lets them do that.
As for me personally, I consider refcounting and GC overlapping categories. I am perfectly willing to call CPython’s reference counting plus cycle collector a form of garbage collection, because it is transparent to the programmer. Every memory management technique has tradeoffs and pathological edge cases, but since you don’t have to consider them in the ordinary course of programming I’d say it counts. If you had to break cycles manually, or to annotate which references should be counted, I’d call that refcounting but not GC – as in the C++ stdlib.
> I think a lot of people just want to be able to discuss different areas of the automatic memory management design space separately, and maintaining the distinction between reference counting and garbage collection (meaning tracing GCs) lets them do that.
The problem is that there are many differences in memory management techniques that offer different tradeoffs, and the difference between refcounting and tracing is not necessarily the biggest of them.
For example, one of the most important distinctions in memory management is whether it optimises for footprint or speed (or some compromise), and the line isn't where people who don't understand memory management think it is. It can matter (often a great deal) whether you determine that an object is dead dynamically (say, by counting references) or statically (by manually writing free or by having the language track lifetimes), but it doesn't matter as much as whether or not the mechanism needs to know when objects are dead in the first place. So reference counting, manual free, static lifetimes, and even non-moving mark-and-sweep tracing collectors (like Go's) generally optimise for footprint at the expense of speed (although different allocators can have some control over that tradeoff), while arenas and tracing moving collectors optimise for speed at the expense of footprint (although here, too, they have some control over the tradeoff). So the line for this super-important tradeoff is between [manual, static, refcoutning] and [arenas, moving tracing]; non-moving tracing collectors are somewhere in between but may be closer to the first group.
People who don't understand memory management and may not have a lot of experience in low-level programming sometimes think that manual or statically-determined freeing must be fast because low-level languages, which inexperienced people think are fast, use them. In fact, low-level languages have some concerns that are much more important than speed and that preclude them from optimisations such as moving pointers. To get around that performance handicap, these languages try to avoid using their heap memory management as much as possible because they're using a rather slow technique because of their constraints.
"Speed" is also ambiguous between latency and throughput. You seem to be using "speed" here as a synonym for throughput. Because of Little's Law, the memory consumed by deallocated objects is directly proportional to deallocation latency, so "low footprint" also generally means "low latency", while increasing throughput by amortizing deallocation overhead at the expense of latency increases memory usage for the same reason.
> so "low footprint" also generally means "low latency"
Not anymore.
You're absolutely right that one of the reasons moving collectors were not used more widely was that, while their throughput was always very impressive, their latency wasn't that great, but that changed a few years ago.
E.g. Generational ZGC in OpenJDK (released in September '23) introduces hiccups or "pauses" that are not dependent on the size of the liveset and are no larger than latency hiccups introduced by the OS (assuming no realtime kernel), i.e. <1ms (and typically <<1ms) up to heaps of 16TB. In fact, the latency can be smoother than approaches that have an explicit free operation and require maintaining a free list, as freeing a large object graph can be quite slow and occur in surprising places.
So modern moving GCs no longer have a latency penalty, but this is newer than even ChatGPT.
Note that this is a pretty new technology. The first production-quality "pauseless" moving collector for commodity hardware was released in 2010 by Azul, but it was proprietary. The first open source implementation (that was also generational) was in JDK 21 (https://openjdk.org/jeps/439), i.e. it's less than three years old. The book I linked to is by one of the primary designers of that GC (and one of the world's foremost experts on memory management).
ZGC does no work in stop-the-world pauses; no marking, no compacting, not even root scanning.
Of course, if your language targets the JVM, it will automatically get to enjoy that amazing GC.
I don't really disagree much with what you said. My favored PLang Nim (https://nim-lang.org/ -- it has both `ref` and `ptr` styles of pointer, one auto-managed, one manually managed) even changed a while back it's `nim c --gc=x` command-line language to `nim c --mm=x`, and I was in favor of said change.
However, it does inspire me to write.. The kernel of all this terminology confusion is under-exposure of industrial programmers to not just academic terminology, but also the very design space you mention (which has always been nicely covered by Jones' outstanding book). Just to take an example from the root of this thread:
>widespread common usage of the term “garbage collected programming language” which specifically contrasts manual languages like C++ or Rust against garbage collected ones
Boehm-Wiser conservative collection for C, among the most manual languages of all, pre-dates its very first ANSI 1989 standard.
This underexposure itself is downstream of the kinds of oversimplifications/lies of marketing and in this particular case came from Java. The evolution I witnessed was roughly 1) linking Boehm with -lgc and deleting (or #define'ing away) all your `free()` calls is conservative - to be precise you need compiler aid and a lot of programmers are "not perfect==awful" personality types, 2) Sun Microsystems wants to leverage a lot of reliability issues with C code and become The Platform and spends gobs of money to win hearts & minds, partly succeeding, 3) part of its ad-warfare against the then WIntel hegemony and/or tutorials/introductory material for Junior Programmers (often the target of "be more reliable" material) plays fast & loose with GC terminology because marketing plays fast & loose structurally for fun but mostly profit, 4) because human language really does == language usage a la Quine, everyone in the industry re-defines what "GC" means to bind it to a programming language instead of to a specific run-time, 5) industry & academics use different language, confusion ensues and so here we are.
This is not even the 100th time that either explicit or implicit forces of marketing have achieved confusion analogously to this. If you believe most people don't need much of what they spend on then confusion is arguably intrinsic to marketing of ideas/products. The highly misleading but suggestive metaphorical language used all over "AI" in both research and in product-lines is a more current case of this, leading anyone who knows much to have to qualify "not AGI" or other such junk just to have a conversation.
So, what is my point? Basically just that the larger problem here will persist as long as there is money to be made/attention to be garnered by sowing confusion/having people talk past each other/think some product is more than it really is. I have no meta-strategy in my back pocket to block these successful confusions, but it does seem worth being aware of it.
By that definition even C has garbage collection. Automatic storage duration types have compiler-determined lifetime and automatic deallocation.
If the definition of a word/concept does not match how the word is used in real life, the definition is wrong. After all, semantics is about common understanding of concepts. If your definition of a word doesn't match how it's used, using that definition is not beneficial to use.
Well yeah, stack variables are automatically reclaimed. What's your issue?
It's just that this is not the predominant way C programs are written and for everything else you do need to somehow manage the memory, malloced objects would otherwise just leak. What exactly is the issue, the real life use of C requires manually adding free calls, is it not? So it doesn't do automatic memory management for you.
The term "garbage collection" does not mean that the language has some mechanism of automatically reclaiming some memory. If it did, C would be a garbage-collected language. The term is not used in such way.
Now, of course reference counting can be used as a part of a garbage collector. But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.
We are in agreement here, C++ is not a GCd language. What I (we) claim is that reference counting is a GC, that's it. A language that uses RC 100% would be a GCd language, like python (okay, it does have a tracing GC to collect cycles as well). C++/rust has the necessary language primitives to express reference counting as a library, but that's an optional thing, usually applied only to select few objects. That's a bit like Java can also just allocate a byte buffer and do manual memory management, neither makes a language GCd/manual in and of itself.
> But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.
The concept of "a garbage-collected language" is not well-defined. There are languages, like Java, Rust, and Python that depend on a garbage collection mechanism, and languages like C, C++ and Zig, which don't. C++ happens to offer a GC in its standard library, however.
That "working developers" use some other terminology is not what matters. What matters is whether the terminology they're using expresses important distinctions or not (and may, in fact, express misconceptions about distinctions). In the case of memory management (as in the case of "transpiles", although there the damage isn't as high), the colloquial terminology is misleading as it is used to hint at distinctions (such as about performance) which are simply not there. E.g. moving GCs are used to avoid the performance overheads of malloc/free, especially in large and/or concurrent programs. This performance overhead that C and C++ suffer from is well known to experienced low-level developers (which is partly why large programs that benefit from moving collectors are relatively rarely written in such languages anymore), but now the terminology is used as a cargo cult, which leads to conclusions that are sometimes the very opposite of what's really going on.
> The concept of "a garbage-collected language" is not well-defined. There are languages, like Java, Rust, and Python that depend on a garbage collection mechanism, and languages like C, C++ and Zig, which don't. C++ happens to offer a GC in its standard library, however.
How does Rust differ from C++ in this regard?
As far as I know, both use RAII, and offer something RC-like in their stdlib that is optional to use.
If we view Rust (including unsafe) as a memory-unsafe language, then it's the same as C++, since we can then view Rc/Arc as optional. But if we want to look at Rust as a memory-safe language, then it mandates the use of GC when an object may have multiple owners. In other words, Rust depends on GC to ensure the memory safety of common functionality. It is true that Java depends on GC for even more operations, but the fact remains that it's very hard to write many large Rust programs without the use of the GC in its runtime (unless you go unsafe, in which case it's like C++, where the GC is optional).
I think many people, especially those with insufficient experience with both low-level languages and modern garbage collectors incorrectly assume that the presence or reliance on GC necessarily implies some performance overhead. In actuality, some GCs (moving GCs in particular) were invented, among other reasons, to reduce the overhead imposed by malloc/free that causes significant performance problems in large programs written in low-level languages. Of course, refcounting GCs, as well as some tracing GCs (non-moving ones) also rely on malloc/free, so they may still suffer from the same issues.
Another misconception is that "a GC" is some necessarily large and sophisticated runtime mechanism compared to "no GC". The problem with that view is that modern malloc/free are also large and elaborate runtime mechanisms (in the range of 10KLOC), and they're elaborate because clever sophistication, as well as CPU/footprint tradeoffs, are required to get decent performance from such allocators (another fact that experienced low-level programmers know). Modern malloc/free allocators may be larger and more complex than simple moving collectors (although it is true that modern moving collectors are larger and more complex than modern malloc/free allocators, but they both require non-trivial runtimes).
I think it would be a salutary experience for every C/C++ programmer to write a decently-performing allocator so they could appreciate the complexity and overhead required to avoid excessive fragmentation (especially in long-running programs with long-lived allocations and irregular deallocations), given the constraint of address stability.
I'll go further. Linux heavily uses a form of garbage collection that cannot be implemented in typical userspace (without awkward & slower additions to the consistency algorithm).
Instead of "garbage collection", you can say "dynamic lifetime determination". If code does work at runtime to answer the question "is it safe to free this piece of memory?", that's dynamic lifetime determination, and is a property shared by both reference-counting and more sophisticated GC schemes.
I've always considered shared_ptr to be semi-garbage collection. Allows me to code C++ almost as if it were Java so long as circular references are avoided. I'm perfectly fine with it being considered a type of garbage collection.
And there's always weak_ptr if a cycle makes sense for some reason but you still want it to clean up correctly. Like having a child node point up to a parent or the root in a tree structure.
Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it.
An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to another is based on this belief. And because this belief is wrong, the attempt to communicate expertise never fully succeeds.
Factual knowledge can be transferred via words well, that's why there is always at least partial success at communicating expertise. But solidified interconnected world model of what all your knowledge adds up to, cannot. AI can blow you out of the water at knowing more facts, but it doesn't yet utilize it in a way that allows surprisingly often having surprisingly correct insights into what more knowledge probably is. That mysterious ability to be right more often is coming out of "world model", that is what "expertise" is. That part cannot be communicated, one can only help others acquire the same expertise.
Communicating expertise is a hint where to go and what to learn, the reader still needs to put effort to internalize it and they need to have the right project that provides the opportunity to learn what needs to be learnt. It is not an act of transfer.
A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps.
It's especially noticeable when teaching functional programming to people trained in OO: Some people's model just breaks, while others quickly see the similarities, and how one can translate from a world of vars to a world of monads with relative ease. The bones of how computation works aren't changing, just how one puts together the pieces.
I was even as a junior the kind, who tried to understand the nature of the steps. I failed many times, but I learned from them all the time. I remember my mutable public static variables, and terrible small JavaScript apps. But every time when I did something like that, I tried to understand it. I knew that I failed. Sometimes it took me a year or more (like when I first encountered React about a decade ago, I immediately knew why some of my apps failed with architecture previously).
However, I've seen developers who were in this field for decades, and they still followed just recipes without understanding them.
So, I'm not entirely sure, that the distinction is this clear. But of course, it depends how we define "senior". Senior can be developers who try to understand the underlying reasons and code for a while. But companies seem to disagree.
Btw regarding functional programming. When I first coded in Haskell, I remember that I coded in it like in a standard imperative languages. Funnily, nowadays it's the opposite: when I code in imperative languages, it looks like functional programming. I don't know when my mental model switched. But one for sure, when I refactor something, my first todo is to make the data flow as "functional" as possible, then the real refactoring. It helps a lot to prevent bugs.
What really broke my mind was Prolog. It took me a lot to be able to do anything more than simple Hello World level things, at least compared to Haskell for example.
I had to learn Prolog for a university paper and I have to agree; out of the dozen-ish languages I've had to learn, something just didn't "click" with Prolog.
No real value is this comment, I'm just happy to share a moment over the brain-fuck that is Prolog (ironically Brainfuck made a whole lot more sense).
I wouldn't really try to equate arbitrary job titles awarded based on tenure with actual expertise; titles aren't consistently applied across the industry, or awarded on conditions other than actual merit.
There are a lot of very young developers who have less years of experience than me who have tons more expertise than me.
The problem is, as is evident by this article and thread, it's difficult to measure (and thus communicate) expertise, but it's really easy to measure years of experience.
I vividly remember the moment this clicked for me. I had spent the better part of a decade being interested in programming and essentially learning recipes. It wasn't until I was a couple years into a CS degree and starting to work professionally as a web developer, that I finally had an epiphany of what software actually was, and the degrees of freedom that it actually has. It's very hard to put into words because it was an internal phenomenon, but I can describe at a more visceral understanding of what is meant by "the map is not the territory", and "all models are wrong but some are useful". It's like, you can build anything in software, it's up to you to decide how to do it and make it relevant for a real world use case.
Of course I was still super junior and had so much to learn, but from that point I could at least interrogate any pattern or best practice to understand why it existed and where it should or should not be applied.
I've had conversations with people who wanted to learn how to code. I found that teaching someone how to code is tedious experience. It's just a bunch of memorization and bafflement at how quickly someone else can do things at the keyboard. I've since come to realize that wanting to learn to code is NOT a good starting place. It's best to have a vision. What's the problem you are wanting to solve? If writing software is a way to solve that problem...well NOW we have something to learn around. We have a vision. We have a goal. And learning the syntax and cs concepts is no longer an end of itself, it's just an obstacle to get through to accomplish the vision. You bring enough of these visions to completion, you'll find you've cleared a LOT of obstacles and wow, you've gained a lot of software knowledge.
I've always had excellent model building functionality for abstractions and got the "physics" of a subject rather quickly, be it economics, biology, certain mathematical subjects and more.
Then, I met software and computer science abstractions, they all seemed so arbitrary to me, I often didn't even understand what the recipe was supposed to cook. And though I have gotten better over time (and can now write good solutions in certain domains), to this day I did not develop a "physics" level understanding of software or computer science.
It feels really strange and messes with your sense of intelligence. Wondering if anyone here has a similar experience and was able to resolve it.
I have the opposite experience. Goes to show the difference between people.
I've always had trouble internalizing the "physics" of physics or chemistry, as if it were all super arbitrary and there was no order to it.
Computation and maths on the other hand just click with me. Philosophy as well btw.
I guess I deal better with handling completely abstract information and processes and when they clash with the real world I have a harder time reconciling.
Chemistry in particular is just taught very poorly in USA middle/high school. If anything, it perfectly hinders building that internal understanding.
"Chemical bonds fill the electron shells, which is why we have CO2. But don't worry about why carbon monoxide exists."
"Here's a formula to figure out the angle between atoms in a molecule. But it doesn't apply to H2O, because handwavy reasons. Just memorize this number instead."
Students don't gain an understanding of the subject, because the curriculum doesn't even try to teach it.
This was kind of infuriating about high school chemistry. We were taught so much simply is and that's that. Gold and Mercury differ by one proton, so why is one a dense, yellowish metal and the other one liquid at room temperature? Carbon and Nitrogen sit right next to each other on the periodic table, so why are their chemical properties so different? Why are there so few elements that are ferromagnetic? We dove relatively deep into chemical bonds and isotopes, but glossed over fundamental things like why compounds with similar structures had seemingly random, unrelated properties.
your "physics" grounding is exactly why it feels so odd - software is by its nature anti-physicalist
math and logic are closer to a basis for software abstraction - but they were scary to business people so a "fake language" was invented atop them - you have "objects" that don't actually exist as objects, they are just "type based dispatch/selection mechanism for functions", "classes" that are firstly "producers of things and holders of common implementation" and only secondarily also work to "group together classes of objects"
I feel that is a bit of a false history. OOP was invented by people trying to simulate physical systems, e.g. Stroustup, the Simula people and their contemporaries not business people. Arguably it was popularized later by business people and enterprise Java developers. But that happened way later.
I do not think OOP ever really worked out well as can be evidenced by it no longer being as popular and people having almost entirely abandoned "Cat > Animal > Object" inheritance hierarchies.
This is also a bit of a false history. OOP was squarely invented with Smalltalk. The term was literally conceived for Smalltalk to describe its unique (at the time) programming model. While objects most certainly predate Smalltalk, it was Smalltalk that first started exploring how objects could be oriented.
OOP didn't really take off either, but mostly because it is hard to optimize and impossible to type.
This happened at an old employer of mine. We started to go down the FP road, veering off the standard OOP of the day. About 25% of the people picked it up immediately. About 50% got it well enough. And 25% just thought it was arcane wizardry.
Between that latter group and the bottom portion of the middle it sparked a big culture war. Eventually leading to leadership declaring that FP was arcane wizardry, and should be eradicated.
>teaching functional programming to people trained in OO: Some people's model just breaks, while others quickly see the similarities, and how one can translate from a world of vars to a world of monads with relative ease.
Besides OO -> Functional this applies everywhere else in Computer Science. If you understood the fundamentals no new framework, language or paradigm can shock you. The similarities are clear once you have a fitting world model.
Fail, and try to understand why. Don't be quick with the answer. Sometimes it takes years. But it's crucial to want to improve, and recognize when the answer is in front of you.
Read why programming languages have the structures what they have. Challenge them. They are full with mistakes. One infamous example is the "final" keyword in Java. Or for example, Python's list comprehension. There are better solutions to these. Be annoyed by them, and search for solutions. Read also about why these mistakes were made. Figure out your own version which doesn't have any of the known mistakes and problems.
The same with "principles" or rule of thumbs. Read about the reasons, and break them when the reasons cannot be applied.
And use a ton of programming languages and frameworks. And not just Hello World levels, but really dig deep them for months. Reach their limits, and ask the question, why those limits are there. As you encounter more and more, you will be able to reach those limits quicker and quicker.
One very good language for this, I think, is TypeScript. Compared to most other languages its type inference is magic. Ask why. The good thing of it is that its documentation contains why other languages cannot do the same. Its inference routinely breaks with edge cases, and they are well documented.
Also Effective C++ and Effective Modern C++ were my eye openers more than a decade ago for me. I can recommend them for these purposes. They definitely helped me to loose my "junior" flavor. They explain quite well the reasons as far as I remember.
So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense:
`[state_dict.values() for mat to mat2 for row for p to p/2]`
Or similar, where data flow is 1->2->f(2)->3->4->f(4). Where right now it is this lovely mess with one more repeating term:
`[p / 2 for mat in state_dict.values() for row in (mat 2) for p in row]`
Where the flow is f(4)->2->1->3->f(2)->4->3
This is not just a Python list comprehension problem obviously. The simple for… in… has a similar problem. It’s only better, because the first term `p/2` is at the end.
I'm struggling to even understand what you have in mind, because HN doesn't do Markdown formatting and asterisks are interpreted for emphasis across lines. But I've never really thought there was a problem with the syntax. To me it reads naturally, left to right: "A list ([) of the results from calculating whatever, (for) each of the (name) values that are (in) the (names) container". With multiple clauses, they're in the same order as the corresponding imperative code, which also makes sense. (Perhaps if "for" were spelled "where", it might not...)
You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves.
List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").
You have no clue what type of data ends up in `items`, or that something should end up in `items` at all. This is obvious.
items =
You have no clue what type of data ends up in `items`. You just know now, that something will end up there.
items = [
You only know that a list will be in `items`. Not what will be in the list.
items = [ this
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.
items = [ this for
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.
items = [ this for iterator
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`. You cannot have, or you break the right to left propagation with nested cases, against what you have with this simple example of yours.
items = [ this for iterator ]
This is the only time when you know what type is `items` or `this`.
Also `this` is a useless identifier, if you cannot transform or filter in your list comprehension. I don't like mine either that it contains pointless words...
Don't get me wrong, your example is clearly a right to left data flow. Which is not inherently bad, because `items` and `this` are new identifiers, which won't figure out by IDEs, so it doesn't matter.
Also, in my example of Python code (not my version of it, but the valid Python code), there is no need to have `if` at all to break intellisense, or break either left to right or right to left data flow several times inside the list comprehension.
If you named your variables properly and your editor supported type hints, you'd have none of these issues: I used generic names for demonstration.
Compare it to
family_adults = [ person for person in family_members if person.age >= 18 ]
Code should be as readable as possible by default: I'd argue you do not even need types in code with good naming, though they do prove their worth in codebases being evolved for a long time and many people.
No who you replied to, but practice. Deliberate practice; not just writing the same apps over and over, but instead challenging yourself with new projects. Build things from scratch, from documentation or standards alone. Force yourself to understand all the little details for one specific problem.
there's actually a really good book that bridged it well for me when I was doing my bachelors, A Little Java, A Few Patterns. this is from the famous lisp books for groking FP.
By complete coincidence, yesterday I came across this link to an article Peter Naur wrote in 1985 (https://pages.cs.wisc.edu/~remzi/Naur.pdf) which I haven't been able to stop thinking about.
I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing or another. Often I can tell immediately from the question that the root of the problem is that their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem. Often they will complain that documentation is inadequate or missing, or that we don't do it the way everyone else does, or whatever, and there's almost always some truth to that.
The challenge then is to find a way to represent your own theory of whatever the thing is into some kind of symbolic representation, usually some combination of text and diagrams which, shown to a person of reasonable experience and intelligence, would conjure up a mental model in the reader which is similar to your own. In other words you want to install your theory into the mind of another person.
A theory of the type Naur describes can't be transplanted directly, but I think my job as a senior developer is to draw upon my experience, whether it was in the lecture hall or on the job, to figure out a way of reproducing those theories. That's one of the reasons why communication skills are so critical, but its not just that; a person also needs to experience this process of receiving a theory of operation from another person many times over to develop instincts about how to do it effectively. Then we have to refine those intuitions into repeatable processes, whether its writing documents, holding classes, etc.
This has become the most rewarding part of my work, and a large part of why I'm not eager to retire yet as long as I feel I'm performing this function in a meaningful way. I still have a great deal to learn about it, but I think that Naur's conception of what is actually going on here makes it a lot more clear the role that senior engineers can play in the long term function of software companies if its something they enjoy doing.
Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders of a software developer. Other people can write specifications and requirements all day long, but until a software developer has tackled the problem, the theory probably hasn't been explored well enough yet to express clearly in computer code. It feels like software developers are scientists who study their customers' knowledge domains.
> It feels like software developers are scientists who study their customers' knowledge domains.
I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.
Another facet of this is my annoyance at other developers when they persistently incurious about the domain. (Thankfully, this has not been too common.)
I don't just mean when there are tight deadlines, or there's a customer-from-heck who insists they always know best, but as their default mode of operation. I imagine it's like a gardener who cares only about the catalogue of tools, and just wants the bare-minimum knowledge to deal with any particular set of green thingies in the dirt.
This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
This might be an indicator that PM isn't doing their job; PM should be able to answer you questions regarding what the business wants (= people who you're trying to serve). Developers, by the nature of interacting with domain, do become experts in the domain, but really it should be up to PM what the domain should be doing business-wise.
If that is what a PM needs then there aren't enough good PM to warrant a PM role for most products, so just make software engineers do that in most cases.
Edit: The main role of PM is to decide which features to build, not how those features should be built or how they should work. Someone has to decide what to build, that is the PM, but most PM are not very good at figuring out the best way for those features to work so its better if the programmers can talk to users directly there. Of course a PM could do that work if they are skilled at it, but most PM wont be.
So that we're on the same page, what I think should be PM responsibilities:
If I have a user story: "As a customer I want to purchase a product so that I can receive it at my address" - PM defines this user story as they have insight to decide if such feature is needed.
PM should then define acceptance criteria: "Given customer is logged in When they view Product page Then 'Add product to basket' button should appear", "Given 'Add product to basket' button When customers click on it Then Product information modal should appear" etc - PM should know what users actually want, ie whether modals should appears, or not; whether this feature should be available for logged users only, or not.
How this will work shouldn't matter to PM; these are AC they've defined.
Of course the process of defining AC should involve developers (and QA), because AC should be exhaustive to delivering given feature
The problem, in my experience, is that most PMs don't add anything when it comes to drawing up the acceptance criteria.
In your example of an order placement - the PM has no special knowledge of what is a good customer order flow. Developers are usually way better at coming up with those by the dint of experience and technical knowledge of the current codebase and make the appropriate speed/polish trade-off.
PMs acts as an imperfect proxy for what the customer wants, making judgements off nothing more than their own taste. And though there are many great PMs, the taste of a PM is usually worse than that of developers and designers on average.
IMO the main business reason they exist is for organization accountability and ownership, despite the often negative value they bring.
Even the most verbose specifications too often have glaring ambiguities that are only found during implementation (or worse, interoperability testing!)
Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass
Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on.
Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.
I agree so much with the both of you, to the point it's difficult to avoid cognitive dissonance one way or the other.
Software people do what they do better than anyone else. I mean obviously! Just listening to a non-software person discuss software is embarrassing. As it should be.
There's something close to mathematics that SWEs do, and yet it's so much more useful and economically relevant than mathematics, and I believe that's the bulk of how the "center of the universe" mindset develops. But they don't care that they're outclassed by mathematicians in matters of abstract reasoning, because they're doers and builders, and they don't care that they're outclassed by people in effective but less intellectual careers, because they're decoding the fundamental invariants of the universe.
I don't know. I guess I care so much because I can feel myself infected by the same arrogance when I finally succeed in getting my silicon golems to carry out my whims. It's exhilarating.
We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user.
If the programmer gets to intimately understand the user's experience software would be easier to use. That's why I support the idea of engineers taking support calls on rotation to understand the user.
Both can be true at the same time, a product manager who retains the big picture of the business and product, and engineers who understand tiny but important details of how the product is being used.
If there were indeed perfect product managers, there would no need for product support.
>We keep seeing things like cryptic error messages shown to end users simply because of the disconnect between the programmer and the end user.
A lot of the error messages I'd write were for me, especially those errors I never expected to see.
The typical feedback I'd get from end users is "your software doesn't work". If they can send me a screenshot of the error I'm halfway to solving the problem.
I actually agree with this. Product designers and product managers are often essential and sometimes they do up to 99% of the work of figuring out how something should work. To accomplish that, they often do things well outside the role of a software developer. On the other hand, in my experience, only someone with a software development mindset seems to be able to complete the last 1% (or 10%, or whatever) that reveals and resolves certain kinds of logic issues.
You seem to be assuming a certain org structure with very clear, specialized roles. Many teams do not have this, and engineers are already Product Engineers. It sometimes even makes sense (whenever engineers dogfood their product, startups, or if it is a product targeting other engineers) and is not just a budget/capacity issue.
Similarly, by siloing the world model in one or two heads, you disable the team dynamics from contributing to building a better solution: eg. a product manager/designer might think the right solution is an "offline mode" for a privacy need without communicating the need, the engineering might decide to build it with an eventual consistency model — sync-when-reconnected — as that might be easier in the incumbent architecture, and the whole privacy angle goes out the window. As with everything, assuming non-perfection from anyone leads to better outcomes.
Finally, many of the software engineers are the creative type who like solving customer problems in innovative ways, and taking it away in a very specialized org actually demotivates them. Many have worked in environments where this was not just accepted, but appreciated, and I've it seen it lead to better products built _faster_.
It's interesting that the way you describe it, the world model itself is _not_ just a collection of words in our minds, and I have a small theory of my own that "thoughts" in our brains aren't actually words at all (otherwise animals which don't talk wouldn't be able to make complex decisions?), and the words that we "hear" in our heads and which we perceive as our thoughts are just a rough translation of these thoughts into words, they aren't thoughts themselves. It is also why it's sometimes really hard to put complex (but correct) thoughts into words, and especially hard to adequately compare complex ideas during a regular conversation: on the surface a lot of ideas (especially in software engineering) "sound" good, but they're actually terrible. And there's no better way to communicate ideas than to put them into words, which is probably what makes good software engineering extremely difficult.
Regarding the tension between symbolic representation and Naur "theory", I'd actually say they come from two different traditions, each providing two different theses. When writing them out I think it becomes a bit clearer how they interact and that they're not actually contradictory.
Thesis A is something like: the value of the programmer comes from their practical ability to keep developing the codebase. This ability is specific to the codebase. It can only be obtained through practice with that codebase, and can't be transferred through artefacts, for the same reason you can't learn to play tennis by reading about it (a "Mary's Room" argument).
This ability is what Naur calls "theory". I think the term is a bit confusing (to me, the word is associated with "theoretical" and therefore to things that can be written down). I feel like in modern discourse we would usually refer to this as a "mental model", a "capability", or "tacit knowledge".
Then there's Thesis B, which comes more from a DDD lineage, and which is something like: the development of a codebase requires accumulation of specific insights, specific clarifying perspectives about problem-domain knowledge. The ability for programmers to build understanding is tied to how well these insights are expressed as artefacts (codebase structure, documentation, communication documents).
I feel like some disagreements in SWE discourse come from not balancing these two perspectives. They're actually not contradictory at all and the result of them is pretty common-sensical. Thesis A explains the actual mechanism for Thesis B, which is that providing scaffolding for someone learning the codebase obviously helps, and vice-versa, because the learned mental model is an internally structured representation that can, with work, be externalised (this work is what "communication skills" are).
>their world model (Naur would call it their Theory) is incomplete or distorted in some way that makes it difficult for them to reason about fixing the problem
Of course the model is incomplete compared to reality. That's in the definition of a model, isn't it? And what is deemed a problem in one perspective might be conceived as a non problem in an other, and be unrepresentable in an other.
Everyone should subscribe to the Future of Coding (recently renamed to the Feeling of Computing) podcast if you haven't already: https://feelingof.com/
I keep saying this is the single most important article to consider when talking about AI assisted software building. Everyone should read it. The question should always be: is a human building a theory of the software, or is does only AI understand it? If it's the latter, it is certainly slop.
(Second, albeit more theoretical, would be A Critique of Cybernetics by Jonas)
I think that this is actually a good thing. If everyone had the same internal world model, we would have very little innovation.
I try to train and mentor those that are junior to me. I try to show them what is possible, and patterns that result in failure. This training is often piecemeal and incomplete. As much as I can, I communicate why I do the things I do, but there are very few things I tell them not to do.
I am often surprised at the way people I have trained solve problems, and frequently I learn things myself.
Training is less successful for those who aren’t interested in their own contributions, and who view the job only as a means to get paid. I am not saying those people are wrong to think that way, but building a world view of work based on disinterest isn’t going to let people internalize training.
I agree. It's pretty easy to train based on facts, and even experiences. And learners can often take things in unexpected directions.
I think it becomes difficult to train the next layer up though, which is a sum-total of life experience. And I think this is what the parent poster was referring to.
For example, I read a lot of Agatha Christie growing up. At school I participated in problem-solving groups, focusing on ways to "think" about problems. And I read Mark Clifton's "Eight keys to Eden".
All of that means I approach bug-fixing in a specific mental way. I approach it less as "where is the bug" and more like "how would I get this effect if I was wanting to do it". It's part detective novel, part change in perspective, part logical progression.
So yes, training is good, and I agree that needs to be one. But I can not really teach "the way I think". That's the product of a misspent youth, life experience, and ingrained mental patterns.
> An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities.
"Transmissionism" is a term I've seen to describe this
Yeah, you can't get it out in "one session of conversation", but you definitely can under a different... context.
"Seeing the work reveals what matters. Even if the master were a good teacher, apprenticeship in the context of on-going work is the most effective way to learn. People are not aware of everything they do. Each step of doing a task reminds them of the next step; each action taken reminds them of the last time they had to take such an action and what happened then. Some actions are the result of years of experience and have subtle reasons; other actions are habit and no longer have a good justification. Nobody can talk better about what they do and why they do it than they can while in the middle of doing it."
So cool. One reading is “complexity is not what you believe it is”. Another is “complexity is”… “not what you believe it is”. Seems similar but the difference is subtle. Even the “please try listening” line changes in both versions. One is confrontational, the other is empathetic.
Long before the discussion of the morality of AI went mainstream, I ran into a problem with making what appeared to be ethical choices in automation, and then went on a journey of trying to figure this all ethics thing out (took courses in university, read some books...)
I made an unexpected discovery reading Jonathan Haid's... either Righteous Mind or the Happiness Hypothesis. He claimed that practicing ethics, as is common in religious societies is an integral and important part of being a good person. This is while secular societies often disregard this aspect and imagine ethics to be something you learn exclusively by reading books or engaging in similar activity that has exclusively the descriptive side, but no practice whatsoever.
I believe this is the same with expertise. Part of it is gained through practice, and that is an unskippable part. Practice will also usually require more time than the meta-discussion of the subject.
To oversimplify it, a novice programmer who listened to every story told by a senior, memorized and internalized them, but sill can't touch-type will be worse at everyday tasks pertaining to their occupation. It's not enough to know touch-typing exists, one must practice it and become good at it in order to benefit from it. There are, of course, more, but less obvious skills that need practice, where meta-knowledge simply can't be used as a substitute. There are cues we learn to pick up by reading product documentation which will tell us if the product will work as advertised, whether the product manufacturer will be honest or fair with us, will the company making the product go out of business soon or will they try to bait-and-switch etc.
When children learn to do addition, it's not enough to describe to them the method (start counting with first summand, count the number of times of the second summand, the last count is the result), they actually must go through dozens of examples before they can reliably put the method to use. And this same property carries over to a lot of other activities, even though we like to think about ourselves as being able to perform a task as soon as we understand the mechanism.
The way I usually frame this is: if all expertise could be eventually distilled into verbal form, then years of experience will cease to matter as it all could be replaced with a series of textbooks. Which we obviously know is not possible.
> AI can blow you out of the water at knowing more facts
Yea, but, I have a search engine that contains all the original uncompressed training data, so I'm back on top. How we collectively forgot this is amazing to me.
> and they need to have the right project that provides the opportunity to learn what needs to be learnt.
It takes _time_. I solve problems the way I do because I've had my fair share of 2am emergency calls, unexpected cost blowups, and rewrite failures in my career. The weariness is in my bones at this point.
Great points. Words allow one to communicate an approximation of part of what one knows.
Agree about expertise being inseparable from the 'world model'. When someone tells us something, they're assuming that we know a certain amount of background knowledge but, in reality, we never have exactly the missing pieces that the speaker is assuming we have because our world model is different. It can lead to distortions and misunderstandings.
Even if someone repeats back to us variants of what we've told them at a later time, it doesn't mean that they've internalized the exact same knowledge. The interpretation can be different in subtle and surprising ways. You only figure out discrepancies once you have a thorough debate. But unfortunately, a lot of our society is built around avoiding confrontation, there is a lot of self-censorship, so actually people tend to maintain very different world models even though the surface-level ideas which they communicate appear to be similar.
Individuals in modern society have almost complete consensus over certain ideas which we communicate and highly divergent views concerning just about everything else which we don't talk about... And as our views diverge more, it narrows down the set of topics which can be discussed openly.
I don't think I can agree with you here because a lot of these things that people know but that is supposedly hard to dress in words, is very often just positions that someone holds arbitrarily, so is difficult to impossible to explain. The positions do not have explanations because they are not held for good reason.
I say this as someone with 3 decades of professional experience. That does not make me right, please do tell me that I am in fact wrong! It does mean that I might be one of these guys with positions that should be challenged, however.
You know what? I welcome this. Explain to me why I am wrong, let's do it your way, dear youngin!
I'd say, on averaged, it's 50% what you say and 50% communication issues.
Most smart juniors have no problem with learning. Perceptual exposure and deliberate practice works almost mechanically. However, if someone can't tell you what examples you should be exposed to, you'll learn crap.
This is surprisingly close to a personal theory I've been working on. I've been describing how to use AI to people as engaging the world model in their head, organization, or software.
I'd love to talk more live. I think I have some ideas you'd be interested in. Find me in my profile.
Correct. One just has to realize that the cost of communication (and the context/memory lost along the way to train that understanding) is often just far higher than anyone has patience for. To fully understand the expert, they must become the expert. (or at least a hell of a lot closer than they were)
This is also why average people with little time to commit find it hard to realize the importance and depth of AI. It's a full on university education exploring those.
yep, as I was exploring in https://danieltan.weblog.lol/2026/05/dunning-kruger-and-the-... , the expert pays the "communication tax" to dumb down concepts that the listener can understand. There is a gap between domain understanding and what is being conveyed that is similar for human-llm interactions as well.
This sounds like a whole lot of copium from devs who don't want to bother with the effort of just writing stuff down, ie good documentation practices...
Actually, maybe even worse (not directed at parent) - I think some "seniors" have a stick so far up their err keyboard, and think they are so wise beyond words that they refuse to share their "all knowing expertise" with anyone else as a form of gatekeeping or perhaps fear of being "found out" (that they are not actually keyboard "Gods").
Really though, just wright shit down even if the first draft isn't great. Write it down, check it into the codebase.
I believe you are responding to a concern you are facing in your career with bad documentation (I would guess bad code too), but projecting that onto an unrelated topic: I believe both could be independently true or not.
I'll bite: is education not about starting with theoretical summary of the knowledge in the domain, and then applying it in practice and really feeling it work, be challenging, or not work?
The best educators I had had exactly that approach: you sometimes start with theory, but other times with challenges which make you feel the difficulty, and understand the value of the theory you are co-developing with the educator (they just have the benefit of knowing exactly where we'll end up, but when time allows, they do let you take a wrong turn too). Even if you start with theory, diving into a challenge where you are allowed not to apply the learnings should quickly tell you why the theoretical side makes sense.
As with everything in life, great educators are few but once you have them, you can apply the same approach yourself even if the educator is unable to steer you the right way.
If you never received this type of education, then what you received could arguably be called a waste of time.
Some people manage to go through the whole education system without learning much, others go through exactly the same program and learn a ton, way more than required.
Guess which of those people say education is a waste of time.
Basic Education is about bringing the average up, make sure everyone can read and do basic math etc. Beyond that it's the same thing just at a higher level. Most people who graduate with a bachelors of computer science or similar won't be great programmers. That's why we call them great, they're better than the rest. Most people don't have greatness in them. No amount of education can change that. Those who do have what it takes will naturally succeed because that's who they are. They will study and do the required material and when they're done with that they will spend their free time learning even more because they want it. Some will do so even without a formal education but I don't think that's the case for most.
If you manage to go through 3-5+ years where your only job is to learn stuff, without learning stuff, then you have no one to blame but yourself.
And if you can do it without going to university, go ahead. I'm pretty sure the failure rate for that path is a lot higher but it's certainly an option.
macOS and Windows both used to allow running arbitrary binaries from a web page. Linux GUI users get away purely because it’s unpopular target for as scammers, once naive grandmas and 12-year olds start using it, I’m sure there will be comparable amount of hurdle to just give another person a binary.
What they think they see is actually a short snapshot of North Korean life with a red circle, a red arrow and a red caption text that says "North Korean propaganda here!!! -->", carefully drawn by their local propaganda.
Sanity check: I present you a country X, whose language you don't speak, and whose news you don't read day to day. I show you their politician saying something. Can you tell if that was propaganda? Substitute X from "North Korea" to a country you know nothing about and see how the answer changes.
People don't believe native speakers of their own language when they're told things that conflict with their political world view. Why would they trust someone who says "that's not an accurate translation" if that collides with their political opinions?
For any outsider telling me about North Korea, including South Koreans, I can't tell if I've been pranked with e.g. the South Korean version of The Onion, let alone something milder like I'm being told about this by someone who takes their version Breitbart more seriously than their version of The Wall Street Journal.
This is indeed interesting because rotating 2D screen is not necessarily the same type of brain processing as experiencing things fly around you. Even VR is not necessarily the same, because knowing you're safe may be different from taking the situation seriously. Could be same, could be completely different.
But the first massively popular 3D games started end of 90s which means Alzheimer cases for them will pop up only around 2060 or later (average onset year 75 minus being 15 years kid during 90s).
Besides safety, there is also the cognitive complexity angle.
Plus, digital environments are explicitly designed to be engaging: authors are putting intentional thought into making the virtual space easy to navigate so that the player doesn't get frustrated and go do something else.
Meanwhile, the physical world is something we're pretty much stuck in, and material spaces tend to be optimized not so much to be engaging to navigate and explore - more to be comfortable to inhabit, etc.
Besides, physical spaces - e.g. cities - tend to be iteratively developed over generations, bearing the hallmarks of many different thinking minds, and not optimized for any one particular user flow.
Normally I cringe at doomsday preppers but given how many dictators out there love the idea to cut their country off Internet whenever anything starts going not in their favor, I imagine a lot of people may find this useful.
I wouldn’t want to lose access to knowledge how to fix a sink or which medication is better, just because the local kingface currently feels that free exchange of opinions about him threatens his kingship.
The doomsday preppers with a scarcity mindset and a bunker full of tin cans and military surplus make for good TV, but plenty of "preppers" don't look like that.
They also have a well-stocked pantry but focus more on strengthening the community to absorb shocks. Things like mutual aid networks, skill sharing, tool libraries, noodling with GMRS/HAM/LoRa comms, going on camping trips, helping each other out with kitchen gardens, and general community resilience. This approach doesn't cover every disaster scenario but it seems like a more pleasant (and realistic) option for the ones it does cover. And if nothing truly bad happens then at least they got to spend time doing things like gardening with their neighbors.
Being able to have offline Wikipedia, maps, and educational tools would be useful in either case but potentially even more so as a community resource because there are only so many skills each individual can learn.
I am not a prepper, but I always found immediate dismissal of their stance odd. If you see clouds on the horizon, reasonable people start preparing. Some preparations take longer than others so longer than others. And this does not account for the fact that one the steady lull ( in US and most of Europe ) of the past 70 or so years is not the norm in our world.
Well usually when people refer to someone as a prepper its the specific type of person that is buying hundreds of guns, tons of dehydrated meals but still living on city water - like they're preparing for a disaster movie but not anything real. Specifically the idea that you would be able to stay in place, with all your hoarded disaster crap, during the end of the world is kind of funny.
I don’t think we have a term for people who quietly keep a well stocked pantry, have a water setup, garden, have hobbies like canning, etc. That’s just being a bit rustic/prudent I guess. So then, the “prepper” derogatory label is only applied to the people who do it in the action movie/silly way. But, the question of how prevalent they are is a good one…
Mormons have a widespread cultural practice of prepping, which I understand is mostly the sensible kind where you keep stocks of food and water onhand in case of a natural disaster (rather than the generally-less-sensible rifle militia LARPing). This is something that the institutional Church of Latter-Day Saints encourages among its members, and it strikes me as a pretty good thing to do. Nonetheless, there's no reason why you need to accept the other religious tenets of the LDS church in order to do sensible emergency preparedness, and I'm not sure that not every Mormon community or household is equally diligent about preparedness.
Well, we did have a term for it until it got dragged and sensationalized in the media. I'd tell you that's a standard "psyop" that the propaganda arm of the government often uses against communities and subcultures that they want to discredit and suppress for one reason or another but then you'd probably call me a conspiracy theorist[1].
[1] another example of a successful smear campaign
the specific type of person that is buying hundreds of guns, tons of dehydrated meals
Both of which are available at Wal-Mart.
I always knew about the guns, but only recently discovered that Wal-Mart stores (at least in Louisiana) carry huge buckets with weeks worth of dehydrated survival food.
This is a reductionist view of even the suburban United States IMO. There are plenty of locales in what I'd call 'middle suburbia', which I'd define as less than an hour from whatever their geographical city center is. Even in these areas, multiple day power outages, or other localized or regional disasters have been endemic in the last 25 years; often due to utility or local resource mismanagement.
Take, for example, the 2018 California Camp Fire, the various southern winter flash power outages, or the endemic hurricane season pretty much everywhere exposed to the middle or southern pacific.
"For hurricanes" is a cute way to minimize it, but in much of the country it's rather little that separates you from being left to your own devices, at least for a little while, even when you're just suburban and haven't even looked out to the rural U.S.
There is a real deferred maintenance and resource mismanagement issue in this country. The increasing evidence of "preppers" and items like ration buckets becoming prevalent at bulk store operations like Walmart & Costco are early indications of the increasing prevalence of these issues.
Take a survey of the items that are always available at most Costos or Sam's Clubs across the country and you'll see similar results. They essentially market decentralized infrastructure for those that can afford it (or those who can't afford not to have it).
Say what you will about Mormons, but they take the idea of local stockpiles amazingly seriously. It rises to the point where they subsidize stores selling bulk food product direct to customers, at a scale that otherwise you'd need a Sysco or commercial restaurant license in most places to get access to.
Not required. It's recommended by the church leadership though to have a garden and to have a years supply of food storage if you can. I'm not a Mormon but appreciate it as a good idea.
If you're thinking about a period without power after a disaster, you're supposed to have a gallon of clean water per person per day, along with food that can be prepared in that environment. At least according to https://www.ready.gov/kit.
For me, it made a ton of sense to buy a couple of boxes of MREs and some Mountain House meals for this. They last decades, and they double as camping food.
Certainly some people probably emulate the Hollywood version, but I think that’s about it.
Most “peppers” are fathers that have had the good sense to pause and think “so, what would I be able to do to serve my family if something disastrous happened? What might that look like?”
Usually, a disaster go-bag of some kind with enough basic supplies to weather a day or two of displacement suspension of normal services. Sometimes, if they live in a place where it’s reasonable to imagine staying put is a good option, they might also have a generator and fuel, a week or two worth of long shelf life food, and some water storage. That ensures the wellbeing of their family will not be contingent on outside help, at least during most common disasters. Many of these people may also have a gun or two, for defense or for hunting if they are rural.
Some people go beyond that, and sometimes with a military focus, other times with months of rations, a bunker, or other unusual preparations. Mostly, those are not based on realistic scenarios. In almost any protracted disruption, having a lot of supplies , armaments, or resources will be as much a liability as an asset. People that buy guns -for prepping- are just living out some kind of hero fantasy. If you own guns, and use guns as part of your normal life, it would make sense to have a solid reserve of ammunition. If guns are your disaster scenario, you’re going to have a bad day.
As an individual or nuclear family, to weather an extended problem, you’d need to have a literal secret underground lair that was either so hard to get to or so well hidden that no one would know, and you’d have to be completely self contained. That’s simply not practical for all but actual billionaires, but people cosplay this to varying degrees. Even billionaires might find ymmv.
A much more practical and wholesome approach is to be part of a community that includes farming, independent sources of power and water, and generally sustainable independence from less robust centralized systems. This provides for basic necessities as well as a common defense. Humans lived in tribes for a reason, and 30 people with well aligned incentives and sustainable infrastructure for food, water, and energy is probably the absolute minimum viable structure for security during a disruption of more than a couple of months. Otherwise you would be dependant on total stealth or extreme isolation. Some neighbourhoods would probably coalesce into something resembling this, but organisation ad-hoc under pressure would probably end up with tensions if not violence.
Projects like this one can be real resources for well organized communities. I’ll probably look at running this on our servers as an additional resource, along with our library.
I agree with you on actual preparedness and getting to know your neighbors.
However, I think the derogatory prepper must exist in some number because you see so many products clearly targeting them. All the tacticool stuff, the buckets of dehydrated food, etc etc
Why is a bucket of dehydrated food specifically targeting the stereotype/strawman you are constructing? Costco sells buckets of dehydrated food, and Costco is what comes to mind when I think middle of the road middle-class America. Do you think it's unreasonable to have a bucket of dehydrated food and enough water to last a week?
As someone who lived through the "Snowpocalypse" in Texas in 2021, had no power for 11 days and no water service for 6 days, I was very thankful that I had a backup source of indoor heating, a couple of boxes of MREs, and clean water for a week as just part of having good disaster preparedness, as well as the mylar emergency blankets I hung by fishing line from my ceiling fans so to help create a warm space for my family. All that stuff is just part of a prudent approach to disaster preparedness that anyone who grew up in the middle of the country and has a house would do.
I know quite a few people who you'd write off as "preppers" that are not consumed with fantasies of a zombie apocalypse, but are instead wanting to ensure that their family is taken care of with basic necessities, vital medication, and a set of viable contingency plans when you lose power, water, etc for days or weeks.
Also, nobody but the very wealthy have "hundreds of guns". Guns are expensive. Guns hold their value. Guns are an asset in some communities. But they are expensive, and therefore even rather serious gun people have tens, but not hundreds. I'm probably more of a gun nut than the average, and I definitely do not have "hundreds of guns". To even store "hundreds of guns" safely (e.g. safe from theft, if not for other reasons) I'd need enough money to build a dedicated room in my house just to hold them. "hundreds of guns" is an armory, not a collection. I'm in the top 1% of wealth in my community in Texas and used to shoot competitively, so I'm more of "gun nut" than average, and I can't even imagine owning "hundreds of guns". That's such an outlandish fantasy strawman you have in your mind, it's nothing close to realistic.
You're really just smearing people with stereotypes in this thread that have no basis in reality, and it's clear you're completely unprepared for the reality of what life is like anywhere in the middle of America, much less in much of the rest of the world.
Well for one thing - you'd get by a lot better with beans and rice and a functioning garden than overpriced dehydrated meals. And what I'm referring to by buckets (that is a lot/years supplies) of dehydrated food and who is being targeted are companies like this https://www.mypatriotsupply.com/pages/about-us
"We’re taking steps for survival for what we all know is coming. Today." I mean, come on.
Maybe I'm just beating around the bush too much - what I'm making fun of are people that are "prepping" for the end of the world. It is a silly (and strictly American, I imagine) fantasy to think that you're going to ride out the end of days sitting on a pile of guns and MREs. That is who I'm making fun of, and yes those people exist.
Well, even though I am in general sympathetic to and even a proponent of disaster preparedness, there are undoubtedly people preparing to “ride out the end of days sitting on a pile of guns and MREs.” I have brushed against a few in my life. I count them as useful idiots, because now I know where there’s a pile of dehydrated food, if push comes to shove.
That said, I am convinced enough of the decay of western civilisation in general that I moved to a remote island nation and built a self contained off grid community, so I guess I am actually the extreme case of prepping. That’s certainly true, in a way, except it’s where my daily food, water, and power come from, and I am surrounded by a thriving community of family members and good friends. I honestly never thought I would see a cataclysm within my lifetime, so this was a legacy project for me, but it seems I may have been optimistic lol.
But I do agree with you that there are some nutty fruitcakes out there that are actually hoping for something bad to happen so that they can have their moment of glory, I suppose? It’s actually kinda sad.
I would say though it is uncharitable and even foolish to portray everyone who doesn’t have complete faith in the continuity of our Jenga Castle, especially in the context of recent events.
One of the principles of HN is to take the strongest meaning of an argument, instead of the weakest. I am not casting everyone who prepares for a disaster into the same bucket - I have specifically said I think that people who are attempting to prepare for the literal end of the world by stockpiling supplies are silly.
There are IMO a very small set of circumstances, out of many likely full collapse scenarios, where your average American (and make no mistake - I am specifically referring to Americans here) stockpiling junk is going to actually survive for very long.
This has nothing to do with faith in our society or institutions just that is uniquely American to think that you can buy your way out of any circumstance you can imagine.
> Well for one thing - you'd get by a lot better with beans and rice and a functioning garden than overpriced dehydrated meals.
The lived reality of the "Snowpocalypse" says otherwise. "A functioning garden" doesn't produce food when it's 2F (-16C) outside and there is a foot and a half of snow on the ground. Beans and rice require soaking/washing and cooking at high temperature to be edible, dehydrated food does not.
I have beans and rice on hand always as well because they're staples in my diet, but it's ridiculous to consider them comparable in the situation where you don't have power (e.g. no way to heat food easily) and the weather makes the outside dangerous and not conducive to gardening/food production.
You're just doubling-down on a strawman, and it's frankly utter bullshit. Be better.
I live in a country with a functional government with an unlimited creditcard. The prepping is their business not mine.
I remember when Russia invaded we were all supposed to freeze to death- in reality 2.5% of GDP was diverted and it was Bangladesh that didn't get their LNG tankers.
I mean preppers are mostly cosplayers and I don't criticize people who go to comicon either. If you're not hurting anyone there's nothing wrong with having an unrealistic hobby or one without a lot of practical utility (even if the premise of the hobby is having practical utility).
But the western Roman empire fell and cities depopulated and folks switched back to subsistence farming for hundreds of years.
And plenty of places have been at war and had much of civilization's usefulness diminished from days to decades. Not to mention straightforward natural disasters.
My prepping is limited to buying toilet paper at costco and having bags of beans and rice and such in my pantry and just... knowing how to do things in general.
> But the western Roman empire fell and cities depopulated and folks switched back to subsistence farming for hundreds of years.
> And plenty of places have been at war and had much of civilization's usefulness diminished from days to decades. Not to mention straightforward natural disasters.
The only one of those things someone survived by being an individual prepper is the natural disaster, because in the other cases the government didn't just go away, it was replaced by other groups who could kill any given individual and take their stuff. The only way to survive is to leave and become a refugee or to band together in an even bigger group that can kill all individuals and smaller groups and take all their stuff. This is how you get the Carolingian Empire, Los Zetas, MS-13, the Soviet Union, and the Khmer Rouge.
Individual preppers are living in a fantasy land to the extent they think they can wait out political collapse. They might well be competent enough to wait out a terrible natural disaster, but at that point they aren't "preppers" so much as people who listen to what FEMA and NOAA and other disaster-focused government agencies recommend for their regions.
Many places around the world will have gone through five or six vastly different governments seated in very different locations over the last century or two and during the transition 1) most of the people stayed 2) most of the people had no part in whatever new group held power and 3) there usually wasn't mass slaughter of the people living there during the transition.
You overestimate the importance of government and underestimate how it very much can just go away... and how distant it can be even when it exists, particularly historically. And how the local warlord equivalent isn't going around to everybody's house and murdering them.
And yeah in those times having food and a means of defense and whatever else is useful as often times very very many people had no option but to stay wherever they were. Famine and revolution are much more common and more mundane than you expect.
The groups and communities that weathered the collapse of the Roman Empire the best were those with some degree of self-sufficiency and military protection.
Prepper has become an umbrella term that is applied to a huge variety of people and mostly as a pejorative based on the sensationalization in media.
Many people that would be dismissed as preppers are perfectly normal people who approach the problem rationally. They take a layered approach which involves preparing for a range of timespans and events from the most basic like an extended power outage of 1 to 2 days or an unusually heavy snowstorm or minor flooding that may temporarily make roads impassible. Then escalating to natural disasters with week or monthlong power outage, gas and food shortages and damage to infrastructure. Personal disasters such as a housefire, flood or even financial difficulty from loss of job or health crisis. Then larger natural disasters like hurricanes, tornadoes, earthquakes and forest fires. Only after those are sufficiently covered would they consider more speculative events such as extended nationwide financial crisis, large regional disasters like a volcanic eruption, extreme earthquake, tsunami, major civil disruption, war, economic collapse, government coup, pandemic, etc.
What they do to prepare would include basic individual preparedness like having a generator and electrical hookup to power their home, extra water and food, essential everyday medications, alternate heat source, emergency radio, enough gasoline on hand for both the generator and vehicles and equipment like a chainsaw for clearing downed trees. Also vehicle packages or "go bags" with what you would need should you have to leave your house immediately during an evacuation or fire, if these are kept in the vehicle then they also help should you become stranded in your vehicle during a snowstorm or breakdown. They also prepare in their community often by simply having good relations with their neighbors and helping them when they're in need but may also volunteer with local emergency services or be involved in charitable groups or with likeminded people.
A lot of this has a long history in rural communities that required some level of self-sufficiency due to a lack of services, more precarious roads/powerlines and being low priority for aid during disasters.
FEMA's recommendations only address short term problems and evacuation. They're not sufficient for disruptions lasting longer than a week and the difficulties that people face in more rural areas during disasters.
I've personally been through events that have cut off grid power and transportation for my area for a few days as well as large widespread power outages lasting more than a week. When that happens you find out very quickly how important it is to prepare ahead of time.
Disasters are rare but not rare enough that you can be certain you'll never experience one first hand. "Collapse" events are very low probability, low enough that most people in the world won't likely experience one in their lifetimes but they do happen, you can probably name several countries that have recently been through such events due to war and many more that have been through them in the last 100 years. Many of us are lucky to live in very stable nations so you don't need to make those scenarios your number one priority but it's at least worth the effort to consider what you should do now to help yourself and your community to continue to thrive over the long term.
>A lot of this has a long history in rural communities that required some level of self-sufficiency due to a lack of services, more precarious roads/powerlines and being low priority for aid during disasters.
My grandmother and particularly great grandmothers prepared for winter... because it's a cold climate and grocery stores with the varieties they have are pretty new. So shelves in the basement full of canned goods they canned themselves, I remember making soap with my grandmother when I was a child... things like that.
For everyone it's this huge unreasonable hobby for me it's like well this is a bit of a return to a practice that was dying because of modern conveniences... but having a gun, a supply of water, a generator, and a full pantry in the rural midwest isn't exactly a radical concept.
calling someone a prepper is an adhom, just like calling a greenie a tree hugger. just another way to dismiss something that is emotionally confronting so one can continue to feel some comfort in their own bubble.
Well yes and no. You will always have some have actually prepared; people, and you will have people who cosplay people who are prepared. The latter see buying things that help survival more as a hobby than a thing that needs to get done in order to survive. It is the difference between a hunter who needs a gun as a tool and a gun nut that collects guns because he likes theorizing over minor differences between them online and nerd out about them.
That doesn't mean anybody who does a lot of research online or buys a lot of things is a obsessive hobbyist of course. The difference can at times be hard to tell from the outside, but someone whose first thought when an apocalypse brews on the horizon is to get weapons and turn their home into a bunker, instead of e.g. relying on a strong neighbourhood network and helping others is certainly a specific type of person. The problems that will arise are of the type that will be hard to solve alone. E.g. prep all you can, but what if your family member needs a doctor? Or something is fucked with your electrical system and you need someone.
This is why people make fun of preppers. Not because being prepared is a bad thing (it is not!), but because you get the feeling some of them can hardly wait for the end times to come around so they can test drive their gear.
I feel like fallacies can always be applied to anything because unless you're doing pure math (and even then, tons of caveats - one major one being that you already bought into the framework), you can always question deeper assumptions and yes, structurally it might even fit a fallacy. I mean, is-ought is one of the famous unresolved ones.
Yet we still have arguably correct beliefs in spite of fallacies. That suggests that merely pattern matching isn't a good solution to detect what "truth" is...
The kind of prepping in "prepper" culture though is bullshit. People living and having actual experience in such dangerous places don't prep like that.
I have lived in places like that, and absolutely prep like that when the environment calls for it. I'd expect a non zero proportion of the HN readership has as well. See: Burning Man, the fanciest refugee camp on Earth, where you need to schedule, plan, haul in, and haul back out again everything you need to survive.
(I've also spent time living in legit BFE where the closest store for something can be more than an hour away, YMMV)
If you think the Burning Man is in any way representative to what people do in places like that (think war torn African states, the Middle East, etc) then...
The most important aspect of Burning Man and why it works is the thing most preppers/American Libertarians ignore: the community.
Burning Man isn't interesting because a bunch of individuals pitch tents in the desert, it's interesting because a society is built in the middle of the desert, spontaneously.
The "preppers" I encounter are on ham radio, and I'd say they are more community conscious then the average person. Many of them work in public services (EMTs and the like) or are retired and formerly did. Most have stocked pantries, gardens are common. Most are willing to help out when there's a power outage or a fire. The anti-social picture that popular culture paints of preparedness-minded people is entirely not true in my experience.
Right, I agree, basically my experience with preppers and libertarians is, the ones disgusted when you ask them if they're "leftist" are the ones with too many guns and not enough neighbors, and vice versa for those who embrace the label or don't care.
So you go around asking people if they're "Leftist"? Why? Either you get a non-answer or you start a fight with somebody for no reason -- what a strange thing to do
Discussing philosophy and politics is very normal in the prepper community.
I'm not just waking up to strangers and doing it. This is at meetups, dinners, that sort of thing. "Oh you're a libertarian? Is that more Kropotkin or Rothbard?"
At the gun range I'm just as likely to see a thin blue lives flag, punisher skull, or "don't tread on me" emblem on a gun or gun case as I am to see a hammer and sickle or trans flag. It's just part of the territory.
> I am not a prepper, but I always found immediate dismissal of their stance odd.
I always just assumed that the all-around "prepper" framing was just the market gravitating towards people with cash!
In my conversations with neighbors, people understand preparedness for specific situations well. For example, disaster preparedness – "if the internet goes off, I'd like an LLM to tell me what the best way to stablize X medical emergency". Given the complete long-term erasure of Gaza's educational system, a lot of people also empathize with how useful educational resources would be for children.
In that context, I've assumed people just react against commercialism and the kitchen-sink paradigm of preparedness. (I certainly react against the first, but not the second... but then again I love playing the handyman even in times when things are going well.)
In a doomsday scenario one wouldn't need a "rebuild all of civilization" book, but more a "basics like building a fire, filtering water, repairing a car engine, basic wound treatment" and such book. Nobody is going to be building cathedrals, and factories and computers for a good while...
> Nobody is going to be building cathedrals, and factories and computers for a good while...
Interesting mental exercise. It was explored in A Canticle for Leibowitz[0], novel in 3 parts (Fiat homo, fiat lux, fiat voluntas tua), the first set in the immediate post nuclear-war world, second 600 years after towards the end of the new middle ages, and the third 600 later in a typical futuristic scenario. The first part covers the religious efforts to preserve knowledge (even if said knowledge was not understood), and the second in the new renaissance from wielding such knowledge.
I wonder how LLMs, with their mistakes and all, would play a role in rebuilding civilization. Most media these days is not prepared for staying stable for 20 years, not sure how much and for how long it could be preserved. Perhaps mechanical hard drives in certain isolated environments?
We did it in a pristine world the first time. The next time we do it in a world stripped of natural resources and easy energy with a collapsing biosphere soaked in poison and radioactive waste.
Not impossible but I doubt we get another Industrial Revolution.
>We did it in a pristine world the first time. The next time we do it in a world stripped of natural resources and easy energy with a collapsing biosphere soaked in poison and radioactive waste.
I mean, there's still quite a number of resources on the surface, plenty just sit there because the ratio of setup cost / profit isn't there
The demand a smaller civilization would have should be quite less significant than what we currently have, so it stands to reason it would make sense for them to use those
Even knowing the broad concepts of Crop Rotation, Germ theory, or Computation, means that you shouldn't take that long to get back to an advanced stage, you probably won't actually get to whatever SOTA you had on those fields for a long time, but knowing where to look is quite significant in cutting wasted time
I've thought about this. I imagined stuff like "Chapter 1: Sanitation. Things called germs will make you very sick. They live in human and animal poop. That's why you need to built a latrine far away from your water source. Here's how to do it." You don't need to worry about how to mine for ore when you routinely lose neighbors to cholera.
It is telling that in one of the seminal works about accessibility and rural public health, "Where There Is No Doctor", by David Werner, roughly 10% of the book needs to be devoted to wound and general sanitation and exhortations to keep anything sanitation sensitive the hell away from dirt and nightsoil.
"I don't like people who prepare for the worst, but I now realise I should have prepared for the worst."
Why cringe at something people do privately in their own time that doesn't affect you? Why cringe at people who want to be prepared, even if you think their preparations are misplaced or nonsense? People deserve to be incorrect without being judged.
Often because they keep intruding into hobbies I enjoy with a clear misunderstanding of the space or even a hostility to playing within the rules. Examples include people coming into Meshtastic chats and wondering if a 50W amp will help them talk to their buddy on the other wide of the mountain when civil war breaks out ("no, you'll just be ruining the airwaves for everyone else in the mean time, you still won't have line of sight to your friend, and your radio will look like a spotlight in the dark when the National Guard goes fox hunting"), or which ham radio they buy without a license ("no government's gonna tell me what I can say on the air").
If they'd be doing this in private, I couldn't care less. But in these cases, their actions would actively make my hobby less enjoyable, and I'll judge them for that.
Because I want the people around me to be actually prepared. The whole prepper thing is a market targeting a specific kind of man with the fantasy that they are in control when shit hits the fan to the loint some of these men want shit to hit the fan.
In reality far more important than most gear will be a good neighborhood network for example. But that means working on your own character.
I’ll tell you why.. because the whole thing is commercialized, drives fear and doom into people minds then profits off people’s fears by selling media, merch and so on or spreads misinformation. They’ve been around for a while
Yes though watching that crowd is worthwhile. They often think about things different from mainstream and notice different things so good additional signal even if you ignore it
I can speak for myself: when I ask if the shiny side reflects the heat better, I don't mean to also ask if the difference is significant. It's really just curiosity, whether my school physics intuition holds up or lies to me, that's all.
So, "technically yes" is good enough answer for me.
I personally reported that around time when Mac OS X 10.9 (first non-cat) came out and immediately saw it marked as duplicate. So at least 13 years and counting.
Imagine being a person like me who has always been expressing himself like that. Using em dash, too.
LLMs didn’t randomly invent their own unique style, they learned it from books. This is just how people write when they get slightly more literate than nowadays texting-era kids.
And these suspicions are in vain even if happen to be right this one time. LLMs are champions of copying styles, there is no problem asking one to slap Gen Z slang all over and finish the post with the phrase “I literally can’t! <sad-smiley>”. “Detecting LLMs” doesn’t get you ahead of LLMs, it only gets you ahead of the person using them. Why not appreciate example of concise and on-point self-expression and focus on usefulness of content?
My comment was not really meant as a criticism (of AI) but more of an agreement that I am also confident in the fact that the post is AI-generated (while the parent comment does not seem to be so confident).
But to add a personal comment or criticism, I don't like this style of writing. If you like prompt your AI to write in a better style which is easier on the eyes (and it works) then please, go ahead.
The most jarring point that they mentioned, having sudden one-off boldfaced sentences in their own paragraphs, is not something I had ever seen before LLMs. It's possible that this could be a habit humans have picked up from them and started adding it the middle of other text that similarly evokes all of the other LLM tropes, but it doesn't seem particularly likely.
Your point about being able to prompt LLMs to sound different is valid, but I'd argue that it somewhat misses the point (although largely because the point isn't being made precisely). If an LLM-generated blog post was actually crafted with care and intent, it would certainly be possible to make less obvious, but what people are likely actually criticizing is content that's produced in I'll call "default ChatGPT" style that overuses the stylistic elements that get brought up. The extreme density of certain patterns is a signal that the content might have been generated and published without much attention to detail. There's was already a huge amount of content out there even before generating it with LLMs became mainstream, so people will necessarily use heuristics to figure out if something is worth their time. The heuristic "heavy use of default ChatGPT style" is useful if it correlates with the more fundamental issues that the top-level comment of this thread points out, and it's clear that there's a sizable contingent of people who have experienced that this is the case.
> although largely because the point isn't being made precisely
I agree. I wasn't really trying to make a point. But yes, what I am implying is that posts that you can immediately recognize as AI are low effort posts, which are not worth my time.
reply