I take the previous point about missing MMX / Vector instructions. Presumably, that's a straightforward optimization, when code is vectorizable? That is, yes, it would be nice to have sections on vector instruction use to demonstrate some appropriate algorithms; point taken.
I think, tho, the fundamental reason is: he specs the machine. It does exactly what he says it does. No edge cases, no surprising behavior that LLVM IR or WASM might have; also, I'm sure he spec'd it to make the algorithms he implements elegant or at least more understandable.
I suspect part our views comes from the purity of Mathematics (Knuth) and the actuality of Computer Science. I'm even sympathetic to your view, because then we could verbatim copy Knuth's algos to WASM etc and run them, and we get a twofer: a deeper understanding of the algo AND a deeper understanding of the underlying V-ISA (PTX, BEAM, WASM, LLVM IR, etc).
I think the learning / understanding of the algos Knuth presents partially comes from us Playing Computer, and manually going through the code. It's that pedagogy comes first, I think.
Next time I run into Don, I'll ask him about this. 'cause you're also correct about L1...Ln caches affecting performance drastically.
(And, yes, I had wondered why Don did MMIX he didn't create a "RISC-V" before there was a RISC-V; that is, why didn't he create the Next Great RISC Machine? He said he talked with John Hennessy and Richard Sites. This was in 1990.)
MMIX uses register windows to make stack frame pointer offsets unnecessary when referring to PUSHed arguments. Don is trying to make the algorithms understandable and correct, and by hiding some details that are handled efficiently by compilers (keeping track of FP and offsets), it benefits the human reader.
This series of books is affectionately dedicated
to the Type 650 computer once installed at
Case Institute of Technology,
in remembrance of many pleasant evenings.
MMIX is for all you youngsters who think RISC is all the rage ;-) and I think he does an admirable job creating a fully-defined machine that does use more modern hardware techniques. The fact that he fully defines his underlying machine is exactly correct, because it lays the foundation for precisely expressing the algorithms, and for giving Time and Space (runtime) estimates.
I believe it's fundamentally incorrect to think of these abstract machines as 'assembly language' but rather, I think, they define a stable foundation onto which accurately described algorithms can be expressed. You're supposed to 'play computer' and follow along -- step by step -- to understand the deep details of the algorithms.
This is exactly correct. Low 10s of kHz is quite functional for machines moving in human space / speed.
If one is trying to do some assembly line (max # of operations per second), the power requirements alone get hard to manage. And then you're managing back EMF, eddy currents, heck, air resistance!
My rule: have dedicated low-level hw provide smooth PID response, mostly on the P term; and have a higher-level control produce the setpoint. Faster response means less need to rely on I or D terms as much (just because delta-T is so relatively small).
Wow, the Python folks do not want to entertain different goals for the language, it would seem. I still remain interested in whether it makes sense to add features to Python anymore, given that LLMs write all the code. Unless, as I said, such features enhance human comprehension (since we have to review the code the LLM produces).
Absolutely serious question: is anybody actually writing code anymore? (Reviewing it, architecting it, sure -- we do that). But writing code? If NOT, then seems to me, what we want in our LLM output is CODE THAT IS TRIVIAL TO UNDERSTAND (I apologize for shouting from the rooftops.)
I'm not sure adding 'features' to Python anymore makes sense - UNLESS those features help humans understand LLM code. Part of the problem is, of course, that LLMs haven't been trained on the latest-and-greatest, so they won't output any of it (even new training events won't capture the latest very much, since there is so little of it relative to what is already out there).
But again -- do new features help HUMANS understand what the LLMs produce? If not, seems to me ... new features merely add complexity for no apparent gain. (Or am I confused about this?) THANKS for any helpful opinions.
If we used it more than just "ok look it works, we'll standardize on this internally" we'd have been happy to buy it, as we all other open source that has a donation option. We were just getting our feet wet, tho, and that's where it seemed burdensome; heck, if it phoned home every time it was used, it would have noticed we only used it about 3 times!
I had heavily used PySimpleGUI in various work projects, and one day, when I had to run some older piece of code I had not run in a while, I get a notice that PySimpleGUI won't work, because was free, but nobody paid, and so, good luck! So I was piping mad, paid the 3-year or whatever the max license fee was, received a code, and THEN I was able to get my stuff to work, like it used to.
LESSON: N E V E R Use code that can "stop working" until you pay ransom. N E V E R.
At this point, it's irrelevant, because the LLMs can replace PySimpleGUI with PyQt etc so --- thanks but no thanks. I did like it because you could throw up something around a CLI and it looked at least presentable. Now, since 2025, nobody codes anymore, so ... seems to me, this PySimpleGUI 6 is just a bit of history.
Excuse my ignorance, but does this functionally mean we can treat this as a 'microkernel' a la minix? I always liked the 'tiny protected subsystem' in Ring 0, then a Ring 1 for Drivers (which are restartable, and dynamically loadable), then one or two rings for User processes (maybe Ring 2 for 'ls' etc and Ring 3 for typical user processes).
I am also curious: What hardware enhancements would benefit 'lightweight, kernel-enforced isolation' ? Do we need memory tags? HW Capability Lists? ?
( I believe we've concentrated far too much in making "damn fast pdp-11s" with our hardware advances, and far less on building Reliable Systems -- even if a few percent of peak possible performance is consumed by extra HW. )
It's possible. I don't know. My tone comes off as support Elon, and I do not, at all. I've seen first-hand almost all of these tactics while I was at <Elon Company>. I'm observing that some people seem to do OK at Elon's companies, and for many years, and never seem to get the boot or be abused in other ways. Therefore, Elon is probably not quite as bad a manager as he is made out to be. This is all I am saying. Since I have firsthand knowledge, I believe my opinion has value. Those that disagree? Show me your Source of Truth. Thank you.
I have always disliked the := as assignment operator convention. In these declarative languages, assignment is done frequently. There is little cognitive load to using '=' as assignment, although perhaps a bit jarring for math folk.
<- is somewhat better, but, again, for such a common operation, a single character is just more convenient. Sure, we could have editors that turn "=" into := or <- but now we're getting too fancy especially for something pedagogical.
I also don't mind the -> for C pointers; and certainly don't mind the <= >= or even == conventions (although at least today's compilers warn when they see "if (a=b) ...".
Ultimately, humans won't be writing code anymore anyway ( ;-) ?) so maybe the issue is entirely moot.
One other helpful frame: I consider LLMs simply to be very flexible high-level 'language' Compilers. We've moved up the Abstraction Chain ever since we invented FORTRAN and COBOL (and LISP) instead of using assembly language.
We're 'simply' moving up the abstraction hierarchy again. Good!
I want to be in your camp, and am trying hard. But the OP's blog entry should at least give us a moment to "respect the dead". That's all he's asking, I think.
I think, tho, the fundamental reason is: he specs the machine. It does exactly what he says it does. No edge cases, no surprising behavior that LLVM IR or WASM might have; also, I'm sure he spec'd it to make the algorithms he implements elegant or at least more understandable.
I suspect part our views comes from the purity of Mathematics (Knuth) and the actuality of Computer Science. I'm even sympathetic to your view, because then we could verbatim copy Knuth's algos to WASM etc and run them, and we get a twofer: a deeper understanding of the algo AND a deeper understanding of the underlying V-ISA (PTX, BEAM, WASM, LLVM IR, etc).
I think the learning / understanding of the algos Knuth presents partially comes from us Playing Computer, and manually going through the code. It's that pedagogy comes first, I think.
Next time I run into Don, I'll ask him about this. 'cause you're also correct about L1...Ln caches affecting performance drastically.
(And, yes, I had wondered why Don did MMIX he didn't create a "RISC-V" before there was a RISC-V; that is, why didn't he create the Next Great RISC Machine? He said he talked with John Hennessy and Richard Sites. This was in 1990.)
Here's HN on RISC-V vs MMIX: https://news.ycombinator.com/item?id=14635361