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.
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.
"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."
Your comments read as if we as a community had the duty to engage with your ideas and tools. We don't. It's commendable, but not our duty.
It is perfectly okay and ethical for some software engineer to browse your blog post, understand nothing / get confused by your terminology, and say so.
IMHO the onus is on you to present your ideas in a way that makes them understandable for at least experts.
Granted, it's not easy and I don't know what I would have done in your place.
My suggestion to all in this thread who _feels_ there's something interesting here to record, using Loom or similar, your interactions with these ideas and tools.
I can then read your facial expressions and body language and understand much better how you are not understanding things and improve my explanations. Video is a highbandwidth form of communication. And it takes the exact same amount of time! Less time in fact, because you only need to record your interactions with the tool. You don't need to follow that up with written comments.
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.
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.
If he is serious, well, he's discovered a good idea already implemented in other languages. If he can pull it off better in some way, then he might invent a language that will be used.
But, I do hope he has tried a wide variety of languages, especially the terse ones. I hope he sees that a terse language with thousands of 1-line "things"--be they functions or "microprograms"--isn't necessarily easy to use and understandable.
Agree with many comments here that we have been programming this way all along and called that microprogram functions. Tangentially, I like the design of the blog https://breckyunits.com/ quite a lot. No wasted white spaces.
Have to confess reading this, and the linked page that claims to demonstrate the language but does no such thing, gave me a real "person struggling with mental illness" kind of vibe. Slight overtones of TempleOS type of thinking, a certain, uh, _grandiosity_. No surprise then that a large section of the blog is devoted to bipolar disorder.
nah, there is just a difference between engineers and teachers. It is why underfunding teachers so harshly has resulted in entire countries of dumbasses.
Engineers have trouble communicating the complex things in their heads. That being said the videos are actually a great example of whats happening here: hiding a world of complexity behind "single words". You need incredible esoteric arcane knowledge of "magic single words" in a sea of anything and everything, but once you know everything, you can simplify complexity into a stream of the proper words
The best I can surmise is that this system/language is about human readable data and processing in the same file. To him all the little weird characters in programming are dumb. To many other people "magic word" knowledge is dumb.
For this system to truly shine would require a complete runtime like Pharo where you can inspect where code is coming from, what its doing, documentation, placeholders and mocks all over the place etc
I would highly recommend anyone who has experienced any similar issues to check those out.
P.S. I have a microbiology background and this isn't just anecdotal data, but there's a very strong biological model of what's going on. Check out these researchers for more:
The author made a video explaining the concept, at around 8:20 he writes a new "microprogram". It looks to me like he's replaced the idea of writing functions with writing keywords that extend language grammar. So eventually you'll compose all of your new keywords and be able to reason at higher levels of abstraction.
It seems web-centric? He was using it as a kind of templating engine, and that would explain why it can execute JavaScript inside of a microprogram. If a microprogram can execute other languages or wrap native programs he might be on to something interesting.
I think I understand what the author is trying to get at here (The gardening metaphor clicked with me in particular). The question asked is, "Why are functions not like programs?". For example...
- Why do programs get their own processes, but not functions?[0]
- Why can't I load and use any function from any package in my program at any time? Or run it from my shell? Genera had this.
- Why are functions organized into files?[1] you can have multiple functions in a file, which implies that they are somehow related. This creates structure, which is often unnecessary or downright confusing. The structure can only be hierarchical (files of functions or directories with files of functions). If I change the definition of a function somewhere (e.g. a REPL), it's textual representation will grow out of sync with the actual implementation. Smalltalk didn't have this.
- Why do we only ship collections of functions (programs)?[2]
- Why should all the functions in my program be written in the same language? And why is doing otherwise a pain in the ass everywhere except for Lisps?
This, to me, sounds like a lot of invisible coupling. We don't question it because it's always been this way, but I strongly believe (without having much data to prove it), that this prevents interoperability, and makes programs more bloated by increasing redundancy. I like to think that rather than reinventing "functions and function calls" or "the UNIX command line" the author described what OOP was supposed to be when it was just being rolled out in the 70s at Xerox PARC.
The project in OP addresses none of these, except maybe the bit about languages, but it did bring up an interesting point. For me, anyway.
[0] This one's easy, the process overhead on UNIX systems is a few kilobytes so you can't have everything be a process. In e.g. Erlang you can spawn a bajillion processes at will, so it's not that big of a deal. Still, AFAIK Erlang makes a process per actor rather than function.
[1] During development, I mean. You'd obviously need to put them into text files at some point. Making a Github repo and dumping a new Smalltalk image into it every day is not the way to develop software. Unless... \s
[2] scrapscript.org has an interesting take on this, where every expression (a "scrap") is content-addressable and can be replaced with it hash. They then store these expressions in "scrapyards" over IPFS. You could pull the same expression from different timeframes with built-in syntax. I think it's quite interesting.
I just want to say there are like 3 or 4 awesome comments here, and then the rest are just low effort.
If you want to be helpful to this effort, please check out how we give feedback on BuilderNews (https://news.pub/).
I would love to see Looms of people attemptig to use some of the products here (and there are many! all free, no signup, all public domain), so that we can prioritize what we need to fix and document better to allow more people to benefit from this technology.
It's quite funny you use the term 'low effort' to describe comments here, when you've clearly not done enough research to realise that your idea is not at all novel. Not to mention the youtube video is just a longwinded advertisement, and the article you've written is very poorly articulated.
There are multiple sentences in it that make me think this is all a big joke:
Like: "Languages must be homoiconic", but then you immediately show a language that is NOT homoiconic.
And also "Microprogramming works incredibly well with LLMs. It is easy to mix and match microprograms written by humans with microprograms written by LLMs.", but then show nothing to actually demonstrate that; no demo or even example code. Did you fine tune a model yet? You don't even mention a possible LLM model by name.
And finally: "If the microprogramming trend becomes as big, if not bigger, than microservices, I would not be surprised." I'm sorry but this is hilarious, especially because the vast majority of software out there is not written as a set of microservices, because it's simply the wrong model for most apps, like mobile apps for instance.
If you want to prove to me you are arguing in good faith, you can download Loom (or one of the many open source alternatives) and do proper user test, and I will be happy to take the time to address your points. Many examples on BuilderNews (https://news.pub/) to learn from.
42 comments
[ 3.9 ms ] story [ 122 ms ] threadI 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.
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'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)
It is perfectly okay and ethical for some software engineer to browse your blog post, understand nothing / get confused by your terminology, and say so.
IMHO the onus is on you to present your ideas in a way that makes them understandable for at least experts.
Granted, it's not easy and I don't know what I would have done in your place.
Agreed. And that's why I've pushed 13 revisions since the initial publication (https://github.com/breck7/breckyunits.com/commits/main/micro...) 2 days ago. I'm learning how to better explain this. I think this video is the best attempt yet: https://www.youtube.com/watch?v=e4mJh7TgICE
My suggestion to all in this thread who _feels_ there's something interesting here to record, using Loom or similar, your interactions with these ideas and tools.
I can then read your facial expressions and body language and understand much better how you are not understanding things and improve my explanations. Video is a highbandwidth form of communication. And it takes the exact same amount of time! Less time in fact, because you only need to record your interactions with the tool. You don't need to follow that up with written comments.
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."
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.
But, I do hope he has tried a wide variety of languages, especially the terse ones. I hope he sees that a terse language with thousands of 1-line "things"--be they functions or "microprograms"--isn't necessarily easy to use and understandable.
The good thing is that you do not require a new language.
Engineers have trouble communicating the complex things in their heads. That being said the videos are actually a great example of whats happening here: hiding a world of complexity behind "single words". You need incredible esoteric arcane knowledge of "magic single words" in a sea of anything and everything, but once you know everything, you can simplify complexity into a stream of the proper words
The best I can surmise is that this system/language is about human readable data and processing in the same file. To him all the little weird characters in programming are dumb. To many other people "magic word" knowledge is dumb.
For this system to truly shine would require a complete runtime like Pharo where you can inspect where code is coming from, what its doing, documentation, placeholders and mocks all over the place etc
> Engineers have trouble communicating the complex things in their heads.
Yes!!!
And my first versions (like this), are always shit.
Eventually with a few git pushes I figure out how to teach to others what I can visualize in my head.
It turned out to be caused by wild blood glucose swings and lack of ketones.
A year ago I switched to a ketogenic diet and do finger prick ketone tests to ensure my ketone levels are high (aka, that my "liver is on").
Absolute life changer, and I have these people to thank: https://www.metabolicmind.org and https://www.youtube.com/@ketobipolar/videos
I would highly recommend anyone who has experienced any similar issues to check those out.
P.S. I have a microbiology background and this isn't just anecdotal data, but there's a very strong biological model of what's going on. Check out these researchers for more:
Dr. Chris Palmer at Harvard: https://www.chrispalmermd.com/
Dr. Shebani Sethi at Stanford: https://med.stanford.edu/profiles/shebani-sethi
Dr. Iain Campbell at University of Edinburgh https://www.ed.ac.uk/profile/dr-iain-campbell
Basically each line is a type of markup?
The author made a video explaining the concept, at around 8:20 he writes a new "microprogram". It looks to me like he's replaced the idea of writing functions with writing keywords that extend language grammar. So eventually you'll compose all of your new keywords and be able to reason at higher levels of abstraction.
It seems web-centric? He was using it as a kind of templating engine, and that would explain why it can execute JavaScript inside of a microprogram. If a microprogram can execute other languages or wrap native programs he might be on to something interesting.
If it’s not satire, I really do not want to read any code the author wrote before “inventing” microprogramming.
I also hate when established terms are reassigned to something completely different.
“No, this code takes no env variables or outside configs. All configs are hardcoded to only run on my machine. I’ve decided to call it… machine code.”
- Why do programs get their own processes, but not functions?[0]
- Why can't I load and use any function from any package in my program at any time? Or run it from my shell? Genera had this.
- Why are functions organized into files?[1] you can have multiple functions in a file, which implies that they are somehow related. This creates structure, which is often unnecessary or downright confusing. The structure can only be hierarchical (files of functions or directories with files of functions). If I change the definition of a function somewhere (e.g. a REPL), it's textual representation will grow out of sync with the actual implementation. Smalltalk didn't have this.
- Why do we only ship collections of functions (programs)?[2]
- Why should all the functions in my program be written in the same language? And why is doing otherwise a pain in the ass everywhere except for Lisps?
This, to me, sounds like a lot of invisible coupling. We don't question it because it's always been this way, but I strongly believe (without having much data to prove it), that this prevents interoperability, and makes programs more bloated by increasing redundancy. I like to think that rather than reinventing "functions and function calls" or "the UNIX command line" the author described what OOP was supposed to be when it was just being rolled out in the 70s at Xerox PARC.
The project in OP addresses none of these, except maybe the bit about languages, but it did bring up an interesting point. For me, anyway.
[0] This one's easy, the process overhead on UNIX systems is a few kilobytes so you can't have everything be a process. In e.g. Erlang you can spawn a bajillion processes at will, so it's not that big of a deal. Still, AFAIK Erlang makes a process per actor rather than function.
[1] During development, I mean. You'd obviously need to put them into text files at some point. Making a Github repo and dumping a new Smalltalk image into it every day is not the way to develop software. Unless... \s
[2] scrapscript.org has an interesting take on this, where every expression (a "scrap") is content-addressable and can be replaced with it hash. They then store these expressions in "scrapyards" over IPFS. You could pull the same expression from different timeframes with built-in syntax. I think it's quite interesting.
I don't think we're talking about the same thing, but I liked your thoughts!
Youtube response: https://www.youtube.com/watch?v=84Kq4N2-OEM
Because? Because we want to backup and archive. Because we want to share code with others.
If you want to be helpful to this effort, please check out how we give feedback on BuilderNews (https://news.pub/).
I would love to see Looms of people attemptig to use some of the products here (and there are many! all free, no signup, all public domain), so that we can prioritize what we need to fix and document better to allow more people to benefit from this technology.
Mahalo!
There are multiple sentences in it that make me think this is all a big joke:
Like: "Languages must be homoiconic", but then you immediately show a language that is NOT homoiconic.
And also "Microprogramming works incredibly well with LLMs. It is easy to mix and match microprograms written by humans with microprograms written by LLMs.", but then show nothing to actually demonstrate that; no demo or even example code. Did you fine tune a model yet? You don't even mention a possible LLM model by name.
And finally: "If the microprogramming trend becomes as big, if not bigger, than microservices, I would not be surprised." I'm sorry but this is hilarious, especially because the vast majority of software out there is not written as a set of microservices, because it's simply the wrong model for most apps, like mobile apps for instance.