d-us-vb

I'm not assuming anything. I'm explaining that they can be, because the original comment made it sound like autistic people can't understand social behavior at any level.

I didn't say it wasn't sociopathy; it most certainly was. Autism and sociopathy are not mutually exclusive. And as they were executing their plan, I do not see any point where their "autism was turned off".

Autistic people can be highly sociable by explicitly learning social skills. They can also learn social skills in order to manipulate others, as is the case here.

Lastly, explaining how a medical condition whose stereotypes seem to make others think those with it would not be capable of committing a crime were in fact capable of committing that crime in no ways is the same as excusing the crime.

Autistic people are unusually good at studying patterns objectively. While each individual person is... an individual, studying a sample from a population yields patterns, and thus the justification for the "social sciences". While autistic people may struggle with in person communication and upholding norms of human interaction, they do not generally struggle with understanding game theory, motives, and other aspects of rational decision making. So they can indeed make brilliant (and ruthless) social engineers if only when hiding behind a computer keyboard.

You’re confusing the difference between understanding and comprehending. The former is partial but useful within a context, the latter is total and is the result of mastery. One may understand an abstracted interface and how it works from the perspective of what it does in relation to solving a domain problem, but that doesn’t require them to know how it works at the level of any function/procedure’s mechanism.

While it may be true that formal verification doesn’t yield comprehensive understanding of code in certain forms, in a way it does by ensuring the code is only able to perform up to isomorphism with what the domain requires. Further understanding of how it accomplishes that is meaningless due to abstraction. But there are a number of techniques of formal methods that do require comprehensive understanding to be taken as valid, such as the structured proofs Dijkstra was famous for promoting. Also the classic example of Temporal Logic specs don’t compose, so the specifier must design the spec from scratch basically every time. Even using Hoare logic would require one to verify every line and all functions that are called for the purpose of solving a particular problem because of the difficulty of formally describing a function’s behavior in total.

So while I understand where you’re coming from, I do think that for any meaningful understanding regarding code, formal verification will provide it to the verifier. That is, as much as may reasonably be understood from the code is learned during any formal verification process.

Personally, I would tell you that whatever understanding you gain may still have bugs. Unless your understanding is as complete as a formal treatment of the code, then there may still be bugs in the code due to shared misunderstandings between author and reviewer. The biggest one is both having an incomplete understanding of what a library function does.

So while there may be some overlap, particularly if each person has full understanding of the code's dependencies, in the general case, understanding code and finding bugs are quite different aims.

User names match... are you the original author? Why commenting in the third person?

I don't think video in a text window is a silly toy. Sounds like another useful tool in the toolbox.

This organization is going out of the way to avoid spraying insecticides. It seems far more effective than increasing predators because ecosystems tend to adapt to predation.

Remarkable 2 is pretty good, though last time I used it the search feature for large pdfs was pretty janky. The BOOX eink devices are also perfectly fine; they're really just android tablets with a special build of android for eink devices. Those are the ones I've used personally.

Pocket Book still makes eink ereaders, though. Is there something wrong with their offerings if you stuck with one of their products for 15 years?

PineNote isn't really a consumer device. PINE64 has made it abundantly clear that the PineNote is a developer playground device; they're waiting on the community to refine the software support and flesh out the ecosystem for it.

Oh, yeah that does make sense now that I think about it.

“Pontifications by email” makes it clear enough. Email is an automated message delivery system, and the pope delivers messages from above, soooo…

Such are many of the names coined by creative minds using the early internet.

Even Terry Davis wasn't that bold.

Dotcl sounds like a lisp macro that interprets TCL. :D

I feel like that isn’t exactly a very useful definition of plaintext. If you mean “ASCII” say ASCII.

Plain text is text intended to be interpreted as bytes that map simply to characters. Complexity is irrelevant.

Forth is at this point more of a culture than a language. It's a culture about keeping designs simple so that they're understandable. Without this, Forth is only powerful for programmers who can keep a lot in their heads, but lots of Forth programs end up being write-once. Moore's view, as well as most other high-level Forthers preach simplicity above all; a code cleanliness that would make Uncle Bob blush.

Lean and most type theoretic-based languages don't merely preach simplicity, they demand it. A function or type with a handful of terms or constructors might be provably inhabited/total, whereas one with 2 handfuls of terms or constructors might not be in a reasonable amount of time due to the exponential growth of the proof space. Factoring code optimally for provability yields the simplicity that Forth programmers are striving for.

The credit goes to Luhmann. Ahrens wrote a book about Luhmann's system, but Ahrens' book was more about the practical side of study habits and the nature of knowledge as much as it was about the practical side of actually using a zettelkasten.

That wasn't the issue. The problem was that most of Windows system utilities are not managed, but the WPF move was trying to make a patchwork quilt of managed vs. unmanaged utilities, making the entire system very difficult to reason about and introducing regressions constantly. From the Windows Team's perspective, the .NET people just made a mess out of everything they touched.

Perhaps if WPF really did stay at the presentation level, or used VMs or something to keep it away from the Windows core, it would have panned out better. But is it goes with "paradigm shifts", when a company thinks it has a great idea, it wants to suddenly do that great idea everywhere.

No, the issue, as outlined in the post, is real problematic behavior of real people on the internet who are inclined to tell anyone who is skeptical regarding the data (whatever it may be) that they should more or less discount their personal observations, reasoning, and experience when it goes counter to the data.

The post is about the author, not crime. The critique of Scott. A's posts is an example of the kind of online content that led the author to become "apostate to the Church of Graphs".

Worked for me.

A direct conclusion. The insight I'll draw from that is that academia gives voice to the results the current zeitgeist finds interesting and believable without properly verifying the evidence.

See also the replication crisis.

The purpose stated in the article in the mind of Birren was to reduce eye strain. I don't think it's so much that humans "prefer" it as such, more that we're very well adapted to work in environments with lots of it.

This reminds me a bit of the Vannevar Bush's Memex; what he'd really hoped it would become.

A costly gamble for tech they really wanted that wasn't mature yet.

Instructions unclear: my website is now advertising the logic of spaghetti for an Italian restaurant.

While I agree with the sentiment for the effect its adherents want to have, but...

Why not just

"Communicate clearly"?

- Don't add fluff

- write as plainly as possible

- write as precisely as is reasonable

- Only make reasonable assumptions about the reader

- Do your best to anticipate ambiguity and proactively disambiguate. (Because your readers may assume that if they don't understand you, what you wrote isn't for them.)

- Don't be selfish or self-centered; pay attention to the other humans because a significant amount of communication happens in nuance no matter how hard we try to minimize it.

The blog post is an open letter: the author wants everyone reading to follow the those rules.

erase the context, perhaps? Deny access to Gemini associated with that google account? These kinds of pathological AI interactions are the buildup of weeks to months of chats usually. At the very least, AI companies the moment the chatbot issues a suicide prevention response should trigger an erasure of the stored context across all chat history.

The deadpan irony is on point. Something it seems the Norwegians have perfected.

Another one of my favorite examples of this (an ad for Oslo tourism): https://www.youtube.com/watch?v=8vhD59ac7nw

My breakfast recipe this morning, thanks to this article:

- 1/4 c. milk

- 1/2 c. flour

- 4 eggs

- 1/3 c. sugar

- some salt

- cinnamon

- cloves

- nutmeg

- poppyseeds

Did the first two cakes without baking powder, turned into something between a crepe and a tortilla. Did the last two cakes with baking powder and they were just a very squishy pancake.