当然，我在扯淡 (Dāngrán, wǒ zài chědàn — "Surely I Am Joking"), by 王垠 (Wáng Yín, Wang Yin) · 129 posts currently public · 18 May 2012 to 15 July 2026, still running · output wildly uneven: 30 posts in 2013 alone, 4 posts across 2023–2025 combined · one clear turn: after "Why I No Longer Do PL" in March 2016 the subject drifts from programming languages toward teaching, health and daily life · tags skew to philosophy (32), education (26), programming languages (24), AI (18) · everything is free; a voluntary payment note sits at the foot of each post · this page is built on 16 posts read in full, spanning July 2012 to February 2022, six of them inside the earliest 20% of the current site's lifespan, with samples on both sides of the 2016 turn
Pull all 129 posts off Wang Yin's current website, then count how often they link to each other, and you get an absurd result: the two posts he cites most often are no longer on the site. Six posts point to "The Wisdom of Programming"; five point to "How to Write an Interpreter." The links are still sitting there in the prose. They open onto nothing. A man who spent twenty years telling you to go read the primary sources rather than someone's retelling has deleted his own primary sources.
This isn't gossip. It lands exactly on the question he has been chasing his whole life: when an idea leaves the hands of the person who had it, and travels through textbooks, terminology, prizes, biographies and lineages of students, what is left of it when it reaches you?
There is a specific moment when he ran into that question. He went and read the founding paper of modern logic — Frege's Begriffsschrift, 1879 — and found that it contains no formulas at all. Twenty-odd pages, entirely diagrams that look like circuits, one line joined to another, and easy to read. The eye-watering logical notation in today's programming-language papers is a transcription later people invented to flatten those diagrams onto a single line.
其实他的目的是用符号来表示那些电路图，结果到后来徒孙们以为那些符号就是祖传秘籍的精髓，忘记了那些符号背后的电路图，所以导致了今天的混乱局面。His purpose was to use symbols to represent those circuit diagrams. But by the time it reached the disciples' disciples, they thought the symbols were the essence of the ancestral secret, and forgot the circuit diagrams behind them — which is what produced today's mess."My Story with Authority," 4 January 2014
A notation invented for convenience, mistaken by later generations for the thing itself. That is the key to the whole blog, and almost everything he wrote afterwards is a variation on it. The most original variation is this: text is only an encoding; structure is the thing. He puts it flatly —
代码的本质根本就不是字符串，它本来就是一个具有复杂拓扑的数据结构，就像电路一样。Code is not, in its essence, a string at all. It is a data structure with a complex topology — like a circuit."Misconceptions About Parsers," 19 September 2015
Take that seriously and things start collapsing. Decades of parsing technology turn out to be decoders for needlessly complicated encodings — he calls parsing "step zero of the Long March." Unix's habit of piping unstructured strings between processes put the same mistake into the foundations. Run it in reverse, though, and it is a superb tool: the universal Turing machine is, he says, just an interpreter; so is a CPU. Interning at Google in 2011, he saw that a cross-language code-index system was "nothing but an abstract interpreter" — prototype over a weekend, and in three months he finished what others thought would take years.
And his one criterion for judgment is: can a human hold it in their head without jumping somewhere else? His best demonstration takes a knife to Haskell's currying. (f 2) is shorter than \y -> f 2 y, but the short one doesn't tell you how many arguments f takes; you have to go look up the definition and come back. Push to three arguments and the "clever" version becomes flip (f 1) 2 while the "dumb" one is unchanged. Then he writes the line that could go on his headstone:
有时候，好的程序其实不在于显示你有多「聪明」，而在于显示你有多「笨」。Sometimes a good program isn't about showing how clever you are. It's about showing how dumb you are."The Limits of Currying," 2 April 2013
The same ruler, applied to test-driven development: tests are the tyre barriers at the edge of a racetrack, and "barriers won't make you a good driver, and they won't win you the championship." Applied to his own profession, it yields his harshest demand on himself — "a real genius must be able to make things simple."
Put together, he is always doing one thing: pressing a much-retold object back into its original shape, and reporting the difference. He used it to recount Turing — Church published a year before Turing even submitted, with a simpler model. He used it to audit Design Patterns — he mapped the twenty-odd patterns onto concepts he used daily, and the mapping came out many-to-one. He used it to puncture "super-human machine vision" — that benchmark gives the machine five guesses per image, where a person needs one.
Finally he turned the knife on the word "genius" itself. In 2017 he publicly retracted his own earlier essay "How to Become a Genius": "Let me tell you a secret: I lied." There is, he says, no such thing as a genius, and the concept was never defined in the first place. The argument is as plain as ever — you say Einstein, Feynman and Turing were geniuses; have you ever spoken to them? No. So where did everything in your head about them come from? All of it came out of other people's mouths. Second-hand knowledge again; the same chain, distorted in transmission.
A knife that sharp also cuts what it shouldn't. In 2017 he wrote that "automatically generating programs is simply impossible"; nine years on, the absolute form of that sentence no longer stands. He also took the same "I have reasoned it out and the mainstream is wrong" method into myopia — a field where other people's randomised controlled trials point the opposite way.
But he had already written the reader's disclaimer, and it may be the most honest sentence he ever published: "I hope you all think critically, and do not blindly accept what I say."
Wang Yin's site is now a front-end application that fetches articles from an API. That has a side effect: you can pull all 129 posts down at once and do something he probably never did — count the internal citations.
The result is clean. The most-linked post is his voluntary-payment note, eleven times; that's the tip jar at the foot of each article, so it doesn't count. Second is "The Wisdom of Programming," cited by six posts. Third is "How to Write an Interpreter," cited by five. These two are the load-bearing walls of his entire body of work: on testing he sends you to the first, on Turing machines to the second; discussing Java's visitor pattern, Kotlin, Swift, he points back to these two.
Then you click, and there is nothing there. Neither address returns an article today. Also gone: his post about Dan Friedman, and his post about the Chez Scheme compiler course.
A man who spent twenty years telling readers to "learn from the real masters, not from their disciples" has deleted the primary sources he himself cited most. To read them today you have to read someone's reposted copy of unknown provenance — exactly the kind of thing he spent a career attacking. This is not something to laugh at him for. It lands in the dead centre of the question he was chasing his whole life.
Wang Yin was a PhD student in computer science at Tsinghua University, and left without finishing. On his way out he wrote to Donald Knuth saying the research climate at home was too shallow; Knuth replied by paper letter, "Computer science is not something everyone can do. If you have tried this long and it still isn't working, that means you were not cut out for this line of work.". He then went to the United States: two years of a PhD at Cornell, ended by a letter from the department chair dropped into a pigeonhole he never checked — he found it at the start of the next semester; then a transfer to Indiana University, to study programming languages with Dan Friedman and Kent Dybvig. He interned twice at Google, where he built PySonar, and later wrote code at Coverity and Shape Security. He now teaches computer science courses in China.
One detail says more than any CV. To understand Knuth he read the TeXbook cover to cover twice and did every exercise; he found a few trivial errors, emailed Knuth, and got back two of the legendary "Knuth checks." Like everyone who receives one, he never cashed them; they stayed in their original envelope. Years later, in America, he went to cash them and found they had expired.
The blog is alive but has changed species. In 2013 he published 30 posts; across 2023 to 2025 he published 4, three of which were course enrolment notices, athlete's foot, and myopia. The two most recent, from July 2026, are "How to Completely Eliminate Mosquitoes at Home" and "My Story with Dust Mites." He still keeps a "Featured Articles" list on his own front page: four of the nine are health and household.
f(2,3) becomes "f(2) returns a new function; feed it 3." Haskell and ML do this by default.Read only his most famous pieces and it is easy to think the subject is abuse: of Unix, of Go, of Turing, of TDD, of elite universities. Abuse is his register, not his subject.
The root question he has not let go of for well over a decade is: when an idea leaves the hands of the person who had it, and passes through textbooks, terminology, prizes, biographies and lineages of students, what is left of it by the time it reaches you?
Papers in programming languages have an iron convention: somewhere in the body there must be a page of winding logical symbols. People in the field generally regard logicians as a cut above, and find the notation possessed of "mathematical beauty." Wang Yin soaked in this for years himself.
Then one day he went to the source: the founding paper of modern logic, Gottlob Frege's Begriffsschrift of 1879. He found that it contains not a single such formula. Twenty-odd pages, entirely pictures that look like circuit diagrams, one wire joined to another — and, as he takes care to note, very easy to read. The forbidding symbols of today were invented by later hands (Gentzen among them) to write those diagrams out on one line.
不知道是哪一个后辈把电路图改成了一些稀奇古怪的符号。其实他的目的是用符号来表示那些电路图，结果到后来徒孙们以为那些符号就是祖传秘籍的精髓，忘记了那些符号背后的电路图，所以导致了今天的混乱局面。Some later figure — I don't know who — turned the circuit diagrams into a set of peculiar symbols. His purpose was to use symbols to represent those diagrams; but by the time it reached the disciples' disciples, they thought the symbols were the essence of the ancestral secret, and forgot the diagrams behind them. Which is what produced today's mess."My Story with Authority," 4 January 2014
An encoding invented for ease of writing, taken three generations later for the thing itself — while the original, which anyone could read directly, is the part nobody remembers.
He kept meeting the same shape afterwards: somewhere along the chain, one link performs a lossy re-encoding, and everyone downstream mistakes the copy for the original. Asked why he is so sensitive to this, he gives an immodest but probably honest answer: "I have a very simple mind. I can't follow complicated formulas; I can't follow lofty jargon. And precisely because of that, I escaped being trapped by existing theories." Authority is the amplifier on this chain — and the metaphor he reaches for is the best one in the blog:
权威就像广告，它埋伏在你的潜意识里。听一遍不信，听两遍不信，……，直到一千遍的时候，它忽然开始起作用了，而且这作用越来越强。Authority is like advertising. It lies in ambush in your subconscious. You hear it once and don't believe it, twice and don't believe it … and then on the thousandth time it suddenly starts working, and works harder and harder."My Story with Authority," 4 January 2014
The three ideas below all grow out of this one root question.
In April 2013 he wrote a short and seemingly frivolous post titled "A Few Fabulous Pieces of Jargon" — a set of English in-jokes he had picked up from a colleague's blog, with pictures. "Yoda notation" (writing the constant on the left of the equals sign, because C's = and == look too alike). "Sins of our Forefathers" (legacy design that seemed reasonable then and looks idiotic now). "Heisenbug" (the bug that vanishes the moment you observe it).
One item he then used for the rest of his life:
由于早期的挠人的设计错误，用户不得不采用一些「变通方案」（workaround）或者「附加过程」，这些就像珍珠质一样。久而久之，这些变通方案凝结起来，变成了「软件珍珠」，不了解它们来源的人都视之为宝贝。虽然产生于同样的原理，「软件珍珠」远远没有真正的珍珠那么好看。Because of an early irritating design error, users are forced into workarounds or extra procedures, and these act like nacre. Over time the workarounds congeal into a "software pearl," and people who don't know where it came from treat it as treasure. Produced by the same mechanism as a real pearl — and nowhere near as pretty."A Few Fabulous Pieces of Jargon," 15 April 2013
That joke post became the second most-cited serious article on his site, because the "pearl" is not a metaphor — it is a diagnostic. Faced with a widely taught, proudly displayed technique, ask one question: what design error does this technique exist to compensate for?
He ran the diagnostic on the largest possible target. A decade earlier he had written "Working Entirely in Linux," wildly popular in China's Linux scene; later he turned the whole thing over. In the Unix world people take pride in knowing clever tricks — to him they are all pearls:
公司里，学校里，充满了因为知道一些 Unix 的「巧妙用法」而引以为豪的人，殊不知他们知道的只是回避一些蹩脚设计的小计俩。程序员有太多的特例和细节需要记忆，不但不抱怨，还引以为豪。Companies and universities are full of people proud of knowing some "clever Unix usage," never realising that what they know is a petty trick for dodging a lousy design. Programmers have far too many special cases and details to memorise — and not only do they not complain, they are proud of it."My Story with Authority," 4 January 2014
There is a mechanism here that is easy to miss, and it is where the idea gets sharp: pearls defend themselves. Once a set of workarounds has hardened into a shared language, mastering it becomes an identity and questioning it becomes a sign of incompetence. His example is exact — Dennis Ritchie's line that "Unix is simple, but it takes a genius to understand the simplicity." Once that is said, you dare not call Unix complicated, because saying so concedes you are not a genius. He sets it beside the weavers in The Emperor's New Clothes: only the stupid or unfit cannot see the cloth.
The same diagnostic on Design Patterns is brisk. He was at Cornell, curious why the book was so famous, and borrowed a copy from the library:
当时我就拿起一张纸，把所有的 20 来个设计模式跟我常用的编程概念做了一个映射。这个映射居然是「多对一」（many-to-one）的。I took a sheet of paper and mapped all twenty-odd design patterns onto the programming concepts I used every day. The mapping turned out to be many-to-one."Decoding Design Patterns," 7 March 2013
Notice what he did: he did not argue, he drew a mapping and counted. Many-to-one means the names carve out nothing new; they are one concept forced to unfold into several spellings inside a language not expressive enough to say it once. The authors' own defence was that their contribution was to name these practices, so that programmers at large would have a shared vocabulary — to which his reply is a specimen of the blog's register: if that counts as a contribution, he could write a book giving new names to air, water and pork. And this is not only his opinion: Peter Norvig gave a talk in 1998 showing that most of the twenty-odd patterns become "invisible" in dynamic languages. The names vanish because the pothole vanishes.
This is his most original move, and the only one of the three that builds rather than demolishes.
It starts from a question every programmer thinks they understand: what is a parser? He sat down to write about it in 2015 because he felt the misconception ran so deep that it was about to be written into a distorted textbook history.
His explanation is standard: a parser turns the string "1+2" into an object. The next sentence is not standard. It is a hammer blow:
实际上，代码的本质根本就不是字符串，它本来就是一个具有复杂拓扑的数据结构，就像电路一样。「1+2」这个字符串只是对这种数据结构的一种「编码」，就像 ZIP 或者 JPEG 只是对它们压缩的数据的编码一样。In fact code is not, in its essence, a string at all. It is a data structure with a complex topology, like a circuit. The string "1+2" is merely an encoding of that structure — exactly as ZIP or JPEG are encodings of the data they compress."Misconceptions About Parsers," 19 September 2015
Take that literally and a series of things fall down.
First, an entire research direction. LL, LR, GLR, LEX, YACC, ANTLR, PEG — decades of accumulated technique are, from here, decoder technology, and technology that keeps escalating to undo encodings people made complicated for themselves. His nickname for parsing is "step zero of the Long March," because the real compilation begins once you have the tree. His verdict is merciless: parser research is largely solving problems that either don't exist or were manufactured.
Next, Unix. The core of the Unix philosophy — passing unstructured strings between processes — is, in this framing, mistaking the encoding for the thing and then pouring it into the foundations; so for decades everything has been patching: AWK, sed, Perl, XML, CORBA, JSON. Lisp's design principles have long had a rule called Do not encode: don't bury useful data inside strings.
But the idea earns its keep when you run it backwards. If the thing is a structure, then "understanding something" acquires an operational definition: can you write its interpreter?
He poured this solvent over everything. The universal Turing machine, named by countless people as the source of the modern computer, he dispatches with "put plainly, a UTM is just an interpreter, like Python's or JavaScript's." A CPU is an interpreter for machine instructions. Knuth's MMIX simulator, which he once couldn't follow, he later understood — it is an interpreter for machine code, buried under clever tricks. Martin-Löf type theory, revered across the PL world, he read in the 1980 lecture notes and concluded that "the whole thing is essentially about how to write a partial evaluator."
This is not just talk. Interning at Google in 2011, his manager Steve Yegge wanted a code-index system that could jump precisely to a definition across languages, and told him to find an open-source Python IDE and rip out its semantic analysis. He looked at about ten and found none of them could jump correctly, because they were all doing regular-expression matching. So:
可是我很清楚的看到，这样一个语义检索，不过是一个抽象解释器 (abstract interpreter)。写解释器是我最在行的，所以我告诉他这是我可以完成的，而且由于设计上的简洁，我的代码的维护代价会比使用一个开源项目小很多。But I could see clearly that a semantic index like this is nothing but an abstract interpreter. Writing interpreters is what I am best at, so I told him I could do it — and that because of the simplicity of the design, my code would cost far less to maintain than adopting an open-source project."My Story with Google (2012 original)," 12 July 2012
His manager didn't believe him and said a team of senior engineers couldn't do it in three months; a teammate opened JSCompiler, where the symbol-table file alone ran to over nine thousand lines. That weekend he took Jython's parser, designed a simpler tree structure, wrote an abstract interpreter on top, and had a prototype by Monday.
The idea eventually became his teaching. "Decoding Computer Science" starts with a four-year-old counting 4+3 on their fingers: you hold up fingers because the symbols "4" and "3" cannot themselves be operated on — you must first turn them into a model you can manipulate. Encoding and thing again. He follows the thread all the way to a definition of computation:
因为计算就是处理信息，信息有它诞生的位置（输入设备，固定数值），它传输的方式（赋值，函数调用，返回值），它被查看的地方（分支）。你想不出对于信息还有什么其它的操作，所以你就很安心的相信了，这就是计算机科学这种「棋类游戏」的全部规则。Computation is the processing of information. Information has places where it is born (input devices, literal values), ways it travels (assignment, function call, return value), and places where it is inspected (branching). You cannot think of any other operation on information — so you can rest easy and believe that these are the complete rules of the board game called computer science."Decoding Computer Science," 13 April 2018
His judgements of a piece of code, a language feature, an engineering method all converge on a single ruler — and he ground that ruler on a very small example.
April 2013, currying. Haskell and ML split multi-argument functions into chains of single-argument ones, so "add 2 to every element" can be written map (f 2) [1,2,3] — shorter than map (\y -> f 2 y) [1,2,3]. Everyone prefers the short one.
He asks you to switch standpoints:
注意，我们现在的「重点」在于你，一个人，而不在于计算机。你仔细想，不要让思维的定势来影响你的判断。Note that our focus right now is you, a human being, not the computer. Think carefully, and don't let habits of mind decide this for you."The Limits of Currying," 2 April 2013
From \y -> f 2 y you see at a glance that f takes two arguments, the first is already 2, the second is waiting for elements of the list. From (f 2) you see none of that. f might take two arguments, or three, or four; if three, map (f 2) [1,2,3] returns not a list of numbers but a list of functions each still missing an argument. You have to go elsewhere to look up f, and come back.
Then he raises it to three arguments and asks you to map the middle one. The clever version becomes map (flip (f 1) 2) [1,2,3]; the dumb version is still map (\y -> f 1 y 2) [1,2,3].
能想出这段代码说明你挺聪明，可是如果你这样写代码，那就是缺乏一些「智慧」。有时候，好的程序其实不在于显示你有多「聪明」，而在于显示你有多「笨」。Being able to come up with that code shows you are clever; writing code that way shows you lack a certain wisdom. Sometimes a good program isn't about showing how clever you are — it's about showing how dumb you are."The Limits of Currying," 2 April 2013
He names the hidden criterion himself: the dumb form looks the same for every argument position; the clever form looks different for each one. The one invariant under change is the good one. And the transferable part of the reasoning is a phrase — "one more bend". Currying, he says, imposes an "intuitive overhead": if you cannot see all the information at once, your mind has to take another bend.
Nearly all his engineering judgements afterwards are an accounting of those bends.
Testing. He is not against tests; he is against tests as faith. His metaphor is the tyre barrier at a racetrack: barriers sometimes save your life, but a competent driver is thinking about reaching the finish, not about barriers. The third-rate driver, who keeps going off the track, gives barriers supreme importance in his heart — and ends up placing them in the middle of the track to make sure his own cornering is correct.
护栏并不能让你成为好的车手，不能让你取得冠军。绝大多数时候，你的安全只有靠自己的技术，而不是护栏，你永远有办法可以撞死自己。Barriers won't make you a good driver and they won't win you the championship. Almost all the time, your safety rests on your own skill, not on the barrier — you can always find a way to kill yourself."On Testing," 14 September 2016
The hardest of his twelve rules are all bend-accounting. Giving every class an interface so it can be mocked costs you the ability to press F12 and land on the implementation; you jump to the interface first and hunt for the implementation from there — "this loss of convenience greatly reduces the chance of your mind forming a whole understanding." Testing implementation details rather than properties amounts to "writing the code twice," so "every time you change the code you have to change it twice." And to the corporate rule that every bug fix must come with a test, he puts the right question back: how likely is this bug to recur in the same place? A dumb slip, once seen, usually next appears somewhere else — where there is no test.
DSLs. Same ruler, new object. You see foo(x, y + z) and, without knowing foo, you know what happens, because you already have a mental model of function calls; inside a freshly invented little language foo might be a loop and + might concatenate lists, your model is void, and you must go read the documentation. So he holds that most so-called DSLs should have been library code, not new languages, and turns it into a commandment: "Never create a language until there is truly no other option." This, he notes, runs directly against a PL person's special skill — which is why "how could a principled PL person's life not be bitter?"
That piece is "Why I No Longer Do PL," March 2016, and it is the blog's watershed. In it he takes apart the field he had lived in for a decade: the problems were either solved twenty years ago or are unsolvable like the halting problem, yet a PhD requires "novel" publications, so all that's left is reheating cold rice. The logical formulas in the papers, once you see through them, are interpreter code written in an obscure language with no debugger — so "logicians spend their days agonising over their own design mistakes and bugs, while PL experts think they possess mathematical beauty." He closes the section with a line that is at once his demand on himself and his verdict on the field:
这些所谓天才，看不到简单直观的解决方案，为了显示自己的聪明而采用繁复的抽象，其实是一种愚蠢。真正的天才，必须能够让事情变得简单。These so-called geniuses, who cannot see the simple and intuitive solution and reach for elaborate abstraction to display their cleverness, are in fact being stupid. A real genius must be able to make things simple."Why I No Longer Do PL," 31 March 2016
With a long-running writer, what transfers is usually not the conclusions but the moves. He has four, all concrete, all usable. Their shared trait: count where you can, don't argue — a number doesn't guarantee he's right, but it lets other people find his errors.
One: treat "I don't understand this" as the other side's problem, and go check the source. Most people who can't get through TAOCP, or a computability textbook, or the formulas in a PL paper, conclude "I'm not smart enough." His conclusion is "let me go see what this thing looked like originally." Which is how he ended up reading Frege's paper, Church's two-page note of 1936, Martin-Löf's 1980 lecture, and Neil Jones's book redoing all of computability theory in an ordinary programming language. He has a name for the move: "learn from the real masters, not from their disciples."
Two: use "can you implement it?" as the acceptance test for understanding. He quotes a mathematician: to really understand something deeply, write it as a program. This is both his method and his weapon against academia — logical languages "run only inside logicians' heads," what you write in them has bugs like anything else, and there is no debugger.
Three: use the smallest concrete example as a crowbar. He almost never opens with abstract argument. To show that "super-human machine vision" is fake he doesn't discuss benchmark methodology; he tells you the benchmark is called Top-5 — the machine names five things per image and counts as correct if any one matches.
这就像设计一个考试，每道选择题本来只有一个正确答案，但却给了 5 次机会做对。这样就没法分清优等生和差等生了，甚至差等生有时候表现比优等生还好，因为不确切知道答案，瞎蒙都能做对。It's like designing an exam where each multiple-choice question has one right answer but you get five attempts at it. You can no longer tell the good students from the bad ones — sometimes the bad ones even score higher, because not knowing the answer they just guess wildly and still get it."There Is No Such Thing as Super-Human Machine Vision," 29 July 2021
Then he names names: the human "control group" in that comparison was a single person, and not an independent outside experimenter but a student on the project. And he lands the abstract complaint on the ground — mistaking a truck for a white billboard on the road kills people, and in the real world nobody gets five tries.
Four: distrust names, and distrust them all the way down. In his framework, a new name usually signals that another re-encoding has occurred along the chain. On AI he offers a cutting but memorable regularity:
人工智能的研究者们似乎很喜欢制造吓人的名词，当人们对一个名词失去信心，他们就会提出一个不大一样的，新的名词，免得人们把对这个名词的失望，转移到新的研究上面。然而这些名词之间，终究是换汤不换药。AI researchers seem very fond of manufacturing intimidating terms. When people lose confidence in one term they put forward a slightly different, new one, so that disappointment doesn't carry over to the new work. But between these terms it's the same medicine in a different broth."The Limits of Artificial Intelligence," 23 April 2017
Follow that road to its end and you arrive at "There Is No Such Thing as a Genius" (2017). Biographers make a living from the word; colleagues get reflected glory from it — "one tells ten, ten tell a hundred, and by the time everyone thinks he's a genius, you're the genius's classmate" — and rivals use it to get inside your head. His conclusion: genius comes from hard work, and genius comes from politics.
These four moves share a shape, and a cost: they are all solo work — one person reads the source, one person implements, one person counts, one person judges. He acknowledged the cost in "My Story with Authority," in an unusually quiet register: "creativity and solitude are practically twins."
His method has a structural gap: it has only one observer. Go to the source, implement it yourself, count it yourself — all of it closes the loop inside one head. Against an object like programming languages, where you can write it and run it, that loop is formidably strong. Change the object and it has no brakes.
First, the prediction time simply refuted. In "The Limits of Artificial Intelligence" (2017) he wrote:
任何一个负责的程序语言专家都会告诉你，自动生成程序是根本不可能的事情。……因为「读心术」是不可能实现的，所以要机器做事，人必须至少告诉机器自己「想要什么」，然而表达这个「想要什么」的难度，其实跟编程几乎是一样的。Any responsible programming-language expert will tell you that automatically generating programs is simply impossible. … Since mind-reading cannot be implemented, to make a machine do something you must at least tell it what you want — and the difficulty of expressing what you want is very nearly the difficulty of programming itself."The Limits of Artificial Intelligence," 23 April 2017
The two layers of that passage have had opposite fates. The lower one is alive and well: stating a requirement precisely really is close in difficulty to programming — which is roughly the daily experience of everyone now pair-programming with a model. The upper one is wrong, and wrong in his favourite absolute register. The systems he was judging were toys like Microsoft's RobustFill, inducing programs from a handful of examples; inferring "simply impossible" from that sample is mistaking the technical ceiling of the moment for a ceiling of principle.
Second, the same knife used on medicine gives a different result. This is not digging up his past — it is on his own front page, in his "Featured Articles" list: four of the nine are health and daily life, and one is "Natural Vision Recovery" (2022), which recommends wearing glasses about 1.00 D weaker than your actual prescription, repeating the cycle until vision returns to 20/20. His references are two: W. H. Bates's Perfect Sight Without Glasses (1920), and a YouTube lecture. But this field has randomised controlled trials, and they point the other way: Chung, Mohidin and O'Leary, in Vision Research (2002), randomised 94 myopic children aged 9–14 into an undercorrected (~+0.75 D blur) and a fully corrected group and followed them for two years; the paper's title is the finding — "Undercorrection of myopia enhances rather than inhibits myopia progression." The World Society of Paediatric Ophthalmology and Strabismus consensus statement of 2023 likewise no longer recommends undercorrection.
What matters is where the failure sits. He is using the same moves: reason out the principle, go to the source, distrust the mainstream. But in programming languages, "go to the source" means going back to Frege and Church — those are principles, and writing them down verifies them. In myopia it means going back to one doctor from a century ago, while the thing accumulated over that century which could actually settle the question is exactly the kind of evidence he never uses: many subjects, randomised, controlled, repeatable. His method has no step for "other people ran an experiment," because in his original field it didn't need one.
Third, he writes motive as fact. In "Turing's Halo," the timeline and the citations are solid; but he also tells you that Turing was "arrogant, and probably never regarded Church as a teacher, feeling instead that Church had got there first and wrecked his chance at immortality." That is psychological portraiture, not evidence. He criticises Turing's biographer for one-sidedly using evidence favourable to Turing — and on Turing, on Knuth, on the designers of Go, he uses the mirror image of the same technique.
Fourth, and most practical: his work cannot be checked. He does no peer review, cites little, and deletes posts. Back to the count at the top — to verify today what "The Wisdom of Programming" or "How to Write an Interpreter" actually said, you can only read someone's repost of unknown provenance. He has built, for his own readers, exactly the kind of chain he spent his life attacking.
As for the arguments about him inside the Chinese-language tech world, they are scattered across Zhihu, CSDN and forum reposts. I did not find a single substantial, citable technical rebuttal in the original, so I will not paraphrase any argument I have not read.
And the harshest criticism was written by him. At the end of "My Story with Authority," having knocked Knuth, Unix, the Ivy League and the Turing Award off their pedestals one by one, he adds:
我深深地知道接受错误想法的危害性，所以我也希望大家都具有批判的思维，不要盲目的接受我说的话。我不喜欢「大神」或者「牛人」这种称呼，我也反感那种自称膜拜我的人，因为正是这种人让权威主义现在横行于世。I know deeply how harmful it is to accept wrong ideas, so I hope all of you think critically and do not blindly accept what I say. I dislike being called a "god" or a "guru," and I am repelled by people who declare they worship me — because it is exactly those people who let authoritarianism run rampant today."My Story with Authority," 4 January 2014
That is the only correct way to read this blog, and it is a prescription he wrote himself.