"Microprogramming" is the standard term for internal microcode within a CPU. It transforms machine code instructions into sequences of operations the hardware can directly execute.
The article in this post gives a totally different meaning to this already existing and established term.
You bring up great information for anyone who is familiar with Microcode and might get confused by my use of the term Microprogramming here.
I'm not talking about Microcode at all here, I'm repurposing the Microprogramming term for another use.
In addition to software, I have a background in Microbiology.
This new approach to programming is far more inspired by microbiology than by traditional programming langs (I've just updated the post with a bit more to clarify that, as I realize now that this connection was completely missed and my fault for ommitting it).
Final 2 points:
1. Wikipedia actually redirects "Microprogramming" to "Microcoding". The latter is a better term for writing microcode.
You conveniently leave out that same Wikipedia article on Microcode says: "The act of writing microcode is often referred to as microprogramming, and the microcode in a specific processor implementation is sometimes termed a microprogram."
I was sure this was a parody of microservices, but reading the comments, I'm starting to think maybe it isn't?
As other's have said, this is just a bunch of small functions.
Write some Haskell, every function is just another another function with parameters. If you look at the definition of a function, you will find the function is defined as a single call to another function with some parameters. Most functions are 1 line, which is actually quite hard to wrap your head around at times.
Or learn some APL where every "microprogram" is a single letter.
I feel like the author would appreciate FORTH. FORTH words are basically little programs that can be tested interactively and composed the way the author likes. A lot of the philosophy is similar.
I also recommend the extremely out of print book Threaded Interpretive Languages to understand how an OS can be built up out of a simple building block words one step at a time.
Beat me to it. Yes, this sounds exactly like Forth, where you write a gazillion small, composable “words” that each do exactly one thing correctly.
I also dug out the HP-50g calculator I bought a long time ago but never got around to playing with. I’ve been writing tiny little programs in RPL and it sounds like a math-centric version of the same idea. You put some values on a stack then execute a program to consume them and put new values on the stack. Then repeat with the next step of your processing pipeline.
One issue I have is that all of 3 examples are by the same author and have to do with programming languages themselves.
I don't see anything on the scale of GIMP, FreeCAD, or even SyncThing (Probably one of the most famously simplicity focused tools I use regularly) doing this stuff, although it may be useful for "Language people" who frequently deal with ideas outside the "Standard vocabulary" of most languages.
It seems to be fairly elegant and perhaps nice for people who like to develop interactively in small, hand-testable pieces, but.... I don't understand why I wouldn't just use Python+Jinja2 or Svelte or Vue, unless this has better linting somehow(Since that's my biggest complaint about web tech, the way so much isn't lintable).
From what I've seen I get the impression he's almost as much of a philosopher as a coder, and there's probably aspects to this whole thing that don't make sense the less mathematical-minded.
The left-pad issue isn't related, it was more related to having a lot of dependencies from untrusted or unverified sources. There's nothing stopping you from following what the author is calling a "microprogramming" paradigm and pulling in a single dependency that has a lot of smaller programs in it from a single trusted source, such as core-utils, or a trusted dependency that aggregates a curated and audited set of tools
I don't think this is the case with your comments and a lot of other comments, I think there's genuine confusion and misunderstanding, but I definitely also feel like at this point a decent number of people are intentionally trolling and acting as thought they don't understand what's being said when people make the case for lots of small composable programs, and why that might be provide additional benefits over just having a bunch of small composable pure functions.
Readit News
I'm not talking about Microcode at all here, I'm repurposing the Microprogramming term for another use.
In addition to software, I have a background in Microbiology.
This new approach to programming is far more inspired by microbiology than by traditional programming langs (I've just updated the post with a bit more to clarify that, as I realize now that this connection was completely missed and my fault for ommitting it).
Final 2 points:
1. Wikipedia actually redirects "Microprogramming" to "Microcoding". The latter is a better term for writing microcode.
2. "Computer" once meant something else too: https://en.wikipedia.org/wiki/Computer_(occupation)
As other's have said, this is just a bunch of small functions.
Write some Haskell, every function is just another another function with parameters. If you look at the definition of a function, you will find the function is defined as a single call to another function with some parameters. Most functions are 1 line, which is actually quite hard to wrap your head around at times.
Or learn some APL where every "microprogram" is a single letter.
I also recommend the extremely out of print book Threaded Interpretive Languages to understand how an OS can be built up out of a simple building block words one step at a time.
I also dug out the HP-50g calculator I bought a long time ago but never got around to playing with. I’ve been writing tiny little programs in RPL and it sounds like a math-centric version of the same idea. You put some values on a stack then execute a program to consume them and put new values on the stack. Then repeat with the next step of your processing pipeline.
I glue them together with "function calls".
It's quite amazing.
"It is accurate to model them as functions that take zero or more parameters."
I don't see anything on the scale of GIMP, FreeCAD, or even SyncThing (Probably one of the most famously simplicity focused tools I use regularly) doing this stuff, although it may be useful for "Language people" who frequently deal with ideas outside the "Standard vocabulary" of most languages.
It seems to be fairly elegant and perhaps nice for people who like to develop interactively in small, hand-testable pieces, but.... I don't understand why I wouldn't just use Python+Jinja2 or Svelte or Vue, unless this has better linting somehow(Since that's my biggest complaint about web tech, the way so much isn't lintable).
From what I've seen I get the impression he's almost as much of a philosopher as a coder, and there's probably aspects to this whole thing that don't make sense the less mathematical-minded.
I don't think this is the case with your comments and a lot of other comments, I think there's genuine confusion and misunderstanding, but I definitely also feel like at this point a decent number of people are intentionally trolling and acting as thought they don't understand what's being said when people make the case for lots of small composable programs, and why that might be provide additional benefits over just having a bunch of small composable pure functions.
The good thing is that you do not require a new language.