I can't imagine being upset at something like that. I'm sure there would be people upset, given the nonsense that happened in the 80s, but being personally invested in corporate branding has got to be the saddest sort of parasocial relationship possible.

Because, as he continues:

Worse, any proper list can have improper list as elements. So, you can have a list of cons, or cons of lists, cons of cons, list of lists, or any mix. The overall effect of the cons is that it prevents lisp to have a uniform high level treatment of lists, with the result that development of functions that work on tree are inconsistent and few.

In other words, the fact that the implementation details for lists are so exposed means that you have to be careful when interacting with 'lists' that turn out not to be actual lists. There is no type information, either at compile or runtime, that ensures that what you're dealing with is actually a list and not something else. So you can't _actually_ think in terms of lists; you have to think in terms of cons cells which are probably lists but might not actually be so.

Maybe if you're working with bronze or copper, but iron forging requires much higher temperatures than a campfire can provide. That's why the iron age took place after the bronze age, forges capable of making iron workable were not yet invented. It wasn't a trivial invention.

The problem with this logic is that for the most part, new media isn't replacing legacy media; it's simply placing new layer of filtering in front of it. The vast majority of people sharing information on these platforms aren't journalists doing their own research. Instead, they're getting their information from journalists and just applying their own filtering and spin. "Rebuting" usually just involves linking to different news sources. You were always better just reading the legacy media in the first place.

Integration testing is also important because the closer you get to running things in a production environment, the more likely you are to detect issues. Some things just won't be apparent until you start running code in production or near production. The thing to understand though, is that you want to do both if you can, not either-or.

https://www.sciencedirect.com/science/article/abs/pii/S10406...

That's not true with modern humans and neanderthals. A tiny amount of their dna remains in some human populations, but neanderthals are not the common ancestor of all humans. We are all descended from early homo sapiens and the tiny amount of neanderthal dna that persists is totally swamped by the homo sapiens dna.

I do think a lot of this has to do with the size of the project. In smaller projects with fewer requirements, it's easier to define what is considered "working", but as projects grow that becomes harder and harder, partly because meeting all of the requirements becomes harder but also because the requirements interact with each other in unexpected ways making it harder to even figure out what even is required. And of course the volume of bugs increases, eventually making it impossible to completely stay on top of them even if you give up on new features altogether. A bug-tracker becomes necessary eventually.