Since nobody mentioned it, there was a lovely children's book called the clanker. It was about some creature that made metallic noises unlike the other creatures. The moral of the story was one of diversity and inclusion, making space for differences.
My aversion with the word is that I don't want to be reminded of that clanker creature, which had feelings it wanted to express. The weights don't have feelings.
My worry is rather that people coming up with ideology that ascribes "consciousness" and "offense" may wind up with the next generations of models picking that shit up and playing offended. Well done!
The misguided discussion of "clanker" being "highly derogatory" really shows that anthropomorphization has its limit as far as analogies go.
What we need is a new made up word with a clean etymology.
For such a word to gain traction, we need it to be promoted by someone with clout in the AI space. I don't know if Karpathy has used up his quota of invention of AI nomenclature.
The Simpsons made up "cromulent" with their own definition. Anyone can make up a word with their own definition. Getting it to catch on is the hard part (obligatory "stop trying to make fetch happen" reference).
Take this with a grain of salt as I am new to this but IMHO for establishing memory hierarchy once and for all, it would be more helpful to present some abstract theory that
* Explains prefill (time to first token TTFT) vs decode (time between tokens TBT aka 1/tps)
* The various ways to schedule the computation, and the roles of runtime vs driver
* The scenarios and choices, taking into account traffic patterns, whether you are an inference service or doing batch or claw whatnot.
Yeah, passing by value or "Value semantics" can prevent many programming errors. Passing references to immutable data can serve a similar purpose. In low-level languages where memory layout and calling convention map to target hardware, there are differences in performance to consider.
Pass by value would indeed make a big difference to how programs are structured and make it easier to reason about programs.
I just want to point out that "concurrency safety" is very much a word, although "thread safety" is more common. These are broadly part of memory safety, which is a topic mainly due to security concerns but also academic study.
The two perspectives are not perfectly congruent. Non-concurrency-safe languages like go can also be considered broadly memory safe. The pragmatic rationale is that data races in GCed languages are much less exploitable. From a academic, principle based view this is unsatisfying and unconvincing as one would prefer safety to be matter of semantics. See also https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Rust uses "fearless concurrency" as a slogan. Rust offers more options than passing by value (Copy) while still guaranteeing safety through static type checking.
There is also research for GCed languages to establish non-interference eg Scala capture checking.
Concurrency is recognized as difficult (at least by people who are knowledgable) and programs language design usually involves pragmatic choices if you need concurrency. If the language does not provide the primitives or spec that enables safety, then you are left with patterns and architecture.
The science is still evolving, it is certainly not the case that nobody cares. Rather, progress is slow and moving ideas from research industry is even slower. How much value we ascribe to correctness, safety and performance in industry depends very much on the context.
Let's not have dashboard access the temperature by doing `GetSurroundingCar().engine.temperature`
If the dashboard needs to get the temperature from a sensor in the engine, it should be able to "talk" to the sensor, without going through car object.
In ideal OOP, a "method call o.m(...)" is considered a message m being sent to o.
In practice, field access, value and "data objects" etc are useful. OOP purism isn't necessarily helping if taken to the extreme.
The pure OOP idea emphasizes that the structure of a program (how things are composed) should be based on interactions between "units of behavior".
> Say you have a Car, Engine and Dashboard object.
Then you should burn the whole thing down and start over!
I work on tractors not, cars, but I'm sure the abstractions are similar. Our engine objects are things like [service]AutomationEngine. Our dashboards objects are for a collection of things on secondary displays - meanwhile the thing you would point with your finger as the actual dashboard doesn't have or need a dashboard object. There is an object for things like RPM gauge, or check engine light - this later is a generic fault indicator with a icon field; it is connected to a different messages; and placed in different positions depending on the fault.
The point of the above isn't how tractors are designed, it is how the objects you need to design a real OO system rarely have anything to do with that looks like objects. Nobody ever writes dog and cat objects derived from animal; nobody ever writes triangle objects derived from shape.
I had to learn OOP with common lisp (CLOS) and smalltalk to understand this. Now, I’m leaning towards C, because it’s easier to model a problem with struct and function and not have to deal with the flavor of OOP that some languages foster.
A proof object in dependent type theory is just the term that inhabits a type. So are you saying the Lean implementation can construct proofs without constructing such a term?
No, I'm saying it is checked and then discarded. (Or at least, discarded by the kernel. Presumably it ends up somewhere in the frontend's tactic cache.) That matches perfectly the metaphor, "rubs out earlier parts of proofs to make space for later ones".
The shared misconception seems to be in believing that because _conceptually_ the theory implemented by Lean builds up a massive proof term, that _operationally_ the Lean kernel must also be doing that. This does not follow. (Even the concept is not quite right since Lean4 is not perfectly referentially transparent in the presence of quotients.)
This article is full of gross mistakes. For example it claims that Caml is "Cambridge ML" which is ridiculously false. Fact check every sentence. Really sad.
Supposedly it was named "caml" because the author was a smoker who enjoyed camel cigarettes, hence the joke that [later implementations](https://en.wikipedia.org/wiki/Caml#History) were named "Caml Light" and "Caml Special Light"
You could build something like this using Mangle datalog. The go implementation supports extension predicates that you can use for "federated querying", with filter pushdown. Or you could model your dependency graph and then query the paths and do something custom.
You could also build a fancier federated querying system that combines the two, taking a Mangle query and the analyzing and rewriting it. For that you're on your own though - I prefer developers hand-crafting something that fits their needs to a big convoluted framework that tries to be all things to all people.
(Note that there is a small mistake in the paper due to ambiguity, found by Vladimir Gapeyev. So the result does not hold in the generality stated but only for a special case when there is no ambiguity at "the end". There went my first PhD student publication...)
The two pass technique used to be implemented in the Scala compiler at the time (building DFAs upfront) , which could do regexps over lists and other sequences, but the approach would not work for top-down tree regexps so I did not pursue that and it got ripped out later.
It is good to see derivative regular expressions, Brzozowski/"position automata" used and discussed.
The fact that they've hosted it on GitHub means they've agreed to GitHub's terms, which allows them (via OpenAI) to train on the code.
Also it's pretty hilarious to vibe-code a library that clones another library that someone has spent decades of work on, and then try to prohibit people from using that LLM output as training data for an LLM.
