If you think it's silly because it's not a restaurant you go to, imagine if Coca-Cola replaced their script logo with some generic sans-serif one. Don't you think the outrage would be real?
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.
I definitely saw some. It came from people who were in that culture war space where they interpret every trend as being part of a big left-wing plot to impose their values on everybody else.
So why not just think in terms of lists, which can be nested, rather than cons-cells, which are only rarely used for anything other than to construct lists?
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.
You'll have an equivalent of a cons cell in any linked list implementation, but you won't necessarily interact with it as a user. Look at the standard library implementation of a linked list in C# for example (https://learn.microsoft.com/en-us/dotnet/api/system.collecti...). You see methods for looping over a list, for accessing elements, for insertions and removals, but not much for directly accessing a list's nodes and manually constructing a list out of those nodes. That part is abstracted away.
I think that the author's complaint is that cons cells are too low level a construct to be exposed so prominently to the user. I think he would prefer that it was abstracted over with some higher level interface the way a lot of other language do it. He mentions Clojure as a Lisp that gets it right in his opinion and that's exactly what Clojure does. Cons cells are still available as a construct, but the default method for interacting with lists is a set of higher level functions that also work on arrays and other sequences and don't require that you think as much about the implementation of the lists.
Xah's complaint appears to be that cons cells are too low level a construct to expose to the user. He seems fine with lists in general but just dislikes how they are implemented in Lisp. If I were to implement a list in a non-Lisp language (like C or whatever,) it would likely internally include a struct called "Node" that filled the same purpose as cons cells do in Lisp. However, users of this hypothetical 'list' usually wouldn't directly interact with these "Nodes"; they would mostly be an implementation detail, as appears to be the case for most list implementations other than Lisp's. I think that Xah is wishing that was the case for Lisp as well.
Right. Presumably a car idling for ten minutes produces less pollution than a car being driven for ten minutes, but a car that is driven for ten minutes and idled for an additional ten produces more pollution than either of them. Any pollution produced by cars idling in bad traffic is superadded to the pollution produced in transit so improving the flow of traffic should reduce pollution even if the total number of cars remains steady.
Correlation may not imply causation, but where there is causation there usually is correlation. So, if there is a rise in homelessness there is likely some factor contributing to that and if a factor is correlated there is a good chance that it's causal. Homelessness may caused by multiple factors but if it's increasing and those factors are mostly remaining static then looking for the one that is also increasing seems like a good bet.
a camp fire gets plenty hot for blacksmithing - just wait for the coals and then blow on them
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.
> I also think the gruellingly slow death of legacy media and rise of bluesky and X (and mastodon) is a net positive for society, if only for the reason that ~tweets can be immediately and transparently rebutted, whereas brainwashing ‘news’ programs can’t.
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.
Presumably because he owns the site. You would think this would be the one place that PG didn't get much pushback on his opinions. I'm not too surprised though; he hasn't been very involved here for years so the culture has shifted.
Salespeople are typically compensated based on commissions. At least the well compensated ones are. Automation can make things easier and streamline the sales process, but because the sales rep is paid a percentage of the GP of a sale, automation doesn't really their take.
Because then you wouldn't be doing unit testing; you'd be doing integration testing. You'd also probably not be testing the database in a realistic configuration and thereby missing the whole point.
Testing against a real database is an example of integration testing. Using mocks is for unit testing. Ideally, you want to do both. Unit testing entails isolating particular components for testing which is important because it let's you be more precise in what exactly you're testing. Using mocks also makes it easier to run automated tests because it means you don't need to have a database or credentials handy during the build process.
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.
Yes, that's true, but the problem is that these past four years have been bad for everybody, so they remember the Trump years as being better than they actually were.
This is probably one of the most dickish comments I've read in a while. I have tourettes too. I would never use it as a weapon to diminish other people's difficulties. Just because my problems are manageable doesn't mean other people's are.
I would like to see his sources because that contradicts the most well known studies. There are still a lot of paleoanthropologists who don't think that interbreeding was possible at all and the apparent Neanderthal admixture in modern humans is due to contamination.
The dinosaur to birds comparison isn't a particularly good one. Birds are cladistally dinosaurs, that is, the common ancestor of all birds was a dinosaur. In that sense, there are no birds that are not also dinosaurs.
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 agree. Robots.txt is a suitable means of preventing crawlers from accidentally DOSing your site, but it doesn't really give you any protections as to how your content is used by automated services. The current anything-goes approach is just too exploitable.
I think that prioritizing fixing bugs, especially security related bugs, over new features makes sense for most software projects. The problem comes from defining bugs. Is a bit of unexpected behavior a bug if it doesn't impact users? The article defines bugs as unmet product requirements but if that's the case I don't think the difference between a bug-fix and a new-feature is that clear because new features also help meet product requirements. Perhaps what they mean is that a bug is any regression from what they currently believe the system to be doing.
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.
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.