Emacs unfortunately uses Emacs lisp, not common lisp or scheme.
Emacs unfortunately uses Emacs lisp, not common lisp or scheme.
That wall isn’t structural. There’s a much thicker wall behind it; this is just a thin internal layer for running electric and mounting drywall.
One important thing to realize is that different dialects of English have slightly different grammars.
One place where different dialects differ is around negation. Some dialects, like Appalachian English or West Texas English, exhibit ‘negative concord’, where parts of a sentence must agree in negation. For example, “Nobody ain’t doin’ nothing’ wrong”.
One of the most important thing to understanding a sentence is to figure out the dialect of its speaker. You’ll also notice that with sentences with ambiguous terminology like “he ate biscuits” - were they cookies, or something that looked like a scone? Rules are always contextual, based on the variety of the language being spoken.
English definitely has rules.
It’s why you can’t say something like “girl the will boy the paid” to mean “the boy is paying the girl” and have people understand you.
Less vs fewer, though, isn’t really a rule. It’s more an 18th century style guideline some people took too seriously.
No.
There’s two types of grammar rules. There’s the real grammar rules, which you intuitively learn as a kid and don’t have to be explicitly taught.
For example, any native English speaker can tell you that there’s something off about “the iron great purple old big ball” and that it should really be “the great big old purple iron ball”, even though many aren’t even aware that English has an adjective precedence rule.
Then there’s the fake rules like “ain’t ain’t a real word”, ‘don’t split infinitives’ or “no double negatives”. Those ones are trumped up preferences, often with a classist or racist origin.
Yeah, projects also exist in the real world and practical considerations matter.
The legacy C/C++ code base might slowly and strategically have components refactored into rust, or you might leave it.
The C/C++ team might be interested in trying Rust, but have to code urgent projects in C/C++.
In the same way that if you have a perfectly good felling axe and someone just invented the chain saw, you’re better off felling that tree with your axe than going into town, buying a chainsaw and figuring out how to use it. The axe isn’t really the right tool for the job anymore, but it still works.
C is not how a computer truly works.
If you want to know how computers work, learn assembly and circuit design. You can learn C without ever thinking about registers, register allocation, the program counter, etc.
Although you can learn assembly without ever learning about e.g. branch prediction. There’s tons of levels of abstraction in computers, and many of the lower level ones try to pretend you’ve still got a computer from the 80s even though CPUs are a lot more complex than they used to be.
As an aside, I’ve anecdotally heard of some schools teaching Rust instead of C as a systems language in courses. Rust has a different model than C, but will still teach you about static memory vs the stack vs the heap, pointers, etc.
Honestly, if I had to write some systems software, I’d be way more confident in any Rust code I wrote than C/C++ code. Nasal demons scare me.
Right tool for the job, sure, but that evolves over time.
Like, years back carpenters didn’t have access to table saws that didn’t have safety features that prevent you from cutting off your fingers by stopping the blade as soon as it touches them. Now we do. Are old table saws still the “right tool for the job”, or are they just a dangerous version of a modern tool that results in needless accidents?
Is C still the right tool for the job in places where Rust is a good option?
Homebrew is fairly different from pip, cargo or npm in that only python developers use pip, only rust developers use cargo, etc. And those are mostly used to manage libraries, rather than executables.
Meanwhile, essentially everyone who uses the console uses homebrew regardless of what programming languages they might or might not use. I was making a joke about how good, useful and basically required homebrew is.
Homebrew might as well be default.
Crappy default package management.
What’s wrong with homebrew?
MicroSD cards are better, here. They’re 250mg; a pigeon can transport 75g. That’s 300 microSD cards, ignoring the weight of the SD card enclosure.
It’s a real quote, from the 80s, published in a networking textbook.
It’s amusing, but it’s always been a serious and occasionally practical observation.
IPoAC is a joke about printing actual IP packets, sending them by pigeon, then scanning them.
You do the whole usual TCP ACK/SYN thing, but with pigeons.
It’s not the same as ‘sneakernet, but strapping microsd cards to a pigeon’. It’s way, way sillier.
Am I missing something? Ctrl-f on https://en.m.wikipedia.org/wiki/List_of_Futurama_episodes doesnt turn up an episode with that name, and googling “they don’t think it be like it is but it do Futurama” turns up nothing interesting.
As an aside, what Futurama episode did they quote him in?
“They don’t think it be like it is, but it do” is originally a quote from a Yankees player, Oscar Gamble, about Yankees management in 1975.
It’s a sensible, grammatical construction in his native dialect, but is well remembered mostly because it isn’t very sensible in SAE.
That’s different, in that its grammatical in a dialect but not in Standard American English.
In particular, it’s using the ‘habitual be’. It’s saying something like “people don’t think it always is like it currently is, but it’s always like this.”
I don’t really think it’s better. They’re fine for coding.
They’re basically the corporate default because they’re easier for companies to buy and remotely administer, they’ve got good VPN software, good resale value, etc.
Emacs is a bunch older than common lisp.
One of its more idiosyncratic design decisions was using dynamic scope, rather than lexical scope. They did add in per-file lexical scope, though.
It also just doesn’t implement a lot of common lisp’s standard library.