You're thinking of CPython. PyPy can routinely compete with C and C++, particularly in allocation-heavy or pointer-heavy scenarios.

You may be pleased to know that PyPy's Python 2.7 branch will be maintained indefinitely, since PyPy is also written in Python 2.7. Also, if you can't leave CPython yet, ActivePython's team is publishing CPython 2.7 security patches.

Other way around, actually; C was one of several languages proposed to model UNIX without having to write assembly on every line, and has steadily increased in abstraction. Today, C is specified relative to a high-level abstract machine and doesn't really resemble any modern processing units' capabilities.

Incidentally, coming to understand this is precisely what the OP meme is about.

Direct rendering infrastructure in Linux predates widespread use of "digital rights management" as a term of art by about two or three years. "We were here first," as the saying goes. That said, the specific concept of direct rendering managers is a little newer, and probably was a mistake on its own merits, regardless of the name.

[HTML and Markdown] are not grammatically Type 2 (Chomsky-wise, Context-Free); rather, they are Type 3 (Chomsky-wise, Regular).

This is at least half-wrong, in that HTML is clearly not regular. The proof is simple: HTML structurally embeds a language of balanced parentheses (a Dyck language), and such languages are context-free and not regular. I don't know Markdown well and there are several flavors; it's quite possible that some flavors are regular. However, traditional Markdown embeds HTML, so if HTML is not regular than neither is Markdown.

I once did a syntax-directed translation of Markdown to HTML in AWK!

Sure. The original Markdown implementation was in Perl and operated similarly. However, note that this doesn't imply that either language is regular, only that a translation is possible assuming the input is valid Markdown. Punting on recognition means that invalid parse trees have undefined translations, presumably at least sometimes generating invalid HTML.

I've only skimmed the paper, so let me know if I've missed something, ideally with a page number. Also, it's late and I'm tired, so I'm not hyperlinking anything; sorry.

I'm not sure what a "full semantic analysis" entails, but always keep Rice's theorem in mind: there aren't any interesting semantic analyses available for Turing-complete systems.

Python is a descendant of Smalltalk. Like several of its cousins, particularly the famous ECMAScript, Python doesn't have types or classes in the Smalltalk sense, but prototypes which form a class-like hierarchy. From the static-analysis point of view, whether a type is created or instantiated is a matter of Rice's theorem.

The ability to invoke type() at runtime is not lazy. Python is eager and strict; even generators are eager and strict, although they can cause stack frames to become "stale"; whether a stale stack frame is cleaned up is also a matter of Rice's theorem.

None of this prevents compilation of Python. The RPython toolchain first imports an application, evaluating all calls to type() and pre-building all classes; then, it statically analyzes all of the Python objects in memory and decompiles their bytecode to determine their behaviors. The resulting executable behaves as if it were started from a snapshot of the Python heap.

Yes, CPython sucks. Use PyPy instead; also, use cffi to wrap C libraries.

It's because most of the hard questions and theorems can be phrased over the Booleans. Lawvere's fixed-point theorem, which has Turing's theorem and Rice's theorem as special cases (see also Yanofsky 2003), applies to Boolean values just as well as to natural numbers.

That said, you're right to feel like there should be more explanation. Far too many parser papers are written with only recognition in mind, and the actual execution of parsing rules can be a serious engineering challenge. It would be nice if parser formalisms were described in terms of AST constructors and not mere verifiers.

Nailed it. I think about this a lot: a sysadmin is basically a manager of dozens, hundreds, or even thousands of computers. But management is a poor way of orchestrating human labor; small teams usually operate better without management. So, is there a better way to administer computer systems as well?

Don't use OpenAI's outdated tools. Also, don't rely on prompt engineering to force the output to conform. Instead, use a local LLM and something like jsonformer or parserllm which can provably output well-formed/parseable text.

As a society and as individual computer scientists, none of us actually know what a computer is or how to use them. All programming languages are guesses, mere attempts to encode our natural-language reasoning and philosophy in the purely syntactic and formal fashion required by computers. Don't let yourself become biased in favor of specific languages; instead, understand that all languages are bad in different ways.

Most consumer-grade NICs have a default MAC address which is retrievable with device drivers, but delegate (Ethernet) packet assembly to the OS. If the OS asks the NIC to emit a packet, then the NIC often receives the packet as a blob, DMA'd from main memory, and emits the bytes as octets. Other NICs do manage packet assembly, but allow overwriting the default MAC address. By the time I was learning Linux, we had GNU MAC Changer available in userland with the macchanger command, and many distros have configuration for randomizing or hardcoding MAC addresses upon boot.

I want to say that this is all because olden corporate network management policies could require a technician to replace a NIC without changing the MAC address, but more likely it is because framing and packet assembly was not traditionally handed to a second controller, and was instead bit-banged or MMIO'd by the CPU.

Hi! Please don't link anything from this subdomain again. It was considered a plague back on Reddit, and this sort of content-free post shouldn't be encouraged here either.