M4 always was horrible, and I say that as the original author of GNU M4
mastodon.social
mastodon.social
That covers pretty much all of unix. Some people treat unix as if it had some grand design behind it, but really most of it is just a pile ad-hoc hacks stretched way beyond their original intent and later immortalized by backwards compat and inertia.
I think Unix critics completely miss the point. Contrary to your claim, Unix's basic architecture principles were proven to be key to it's success. Contrary to your claim, this does not mean each tool and interface defines the gold standard for operating systems. Since then we have half a century of advances in ergonomics, developer experience, and software engineering, which Unix developers didn't had back then.
More importantly, what you are missing is the myriad of alternatives to Unix that were developed since Unix was specified in POSIX, and how each and every single one of them is an utter and complete failure in representing a better alternative to Unix. A lot of them claim to do things in a better way, but in practice none of them ever delivered anything remotely capable.
Unix is the poster child of "x is the worst, except for every single other alternative".
"Kernighan and Ritchie then joined forces to develop the original m4, described in “The M4 Macro Processor”
Those nobodies. What were they thinking?
> for no other greater purpose than to scratch a personally itch
"The Brian Kernighan and P.J. Plauger book Software Tools, Addison-Wesley (1976), describes and implements a Unix macro-processor language, which inspired Dennis Ritchie to write m3"[1]
"Originally, the Kernighan and Plauger macro-processor, and then m3, formed the engine for the Rational FORTRAN preprocessor, that is, the Ratfor equivalent of cpp. Later, m4 was used as a front-end for Ratfor, C and Cobol."[1]
If the m3/m4 folks wrote a whole "Software Tools" book and then used m4 as a front-end for multiple languages, it sounds like it served a useful purpose.
[1] GNU M4 manual section 1.2, "Historical References"
It is essentially a lisp but hidden behind `' rather than ().
A big weirdness is that argument separators are identified after macros in the argument list have been expanded, which makes it difficult to understand a macro invocation by itself.
The POSIX specification seems to erroneously say that arguments are not subject to macro expansion https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m... whereas the 7th edition manual clearly says they are https://man.cat-v.org/unix_7th/1/m4
> GNU M4 only exists because RMS wanted GNU to have what Unix had, and while I wanted to do something different and better, RMS convinced me to do M4 first.
This remark sounds awfully ignorant and clueless, and with accusatory tones with w whiff of a personal attack.
Unix is specified in a set of international standards which specify exactly what interfaces must exist. This also includes key tools such as M4.
https://en.wikipedia.org/wiki/POSIX
If your goal is to implement an operating system that is focused on interoperability, and in the process reuse the whole ecosystem developed around it, you implement the whole set of interfaces. M4 is a part of those interfaces. There is no personal opinion or whim or capricious sadism. You could not have that if ignorant opinions on the optional nature of key components were taken seriously.
And the person who was there says "Stallman wanted X because Y". That there may be other good reasons for X is besides the point, but recollecting the argument at the time doesn't make one " ignorant and clueless". What a ridiculous comment. Furthermore, in a quick search it seems that m4 wasn't added to POSIX until the early 90s. So that makes it doubly besides the point and doubly ridiculous.
Quite often I face problem of making solution consistent across multiple domains. E.g. Having logic in X, updating docs in Y through markdown, specs in Z, specs consuming in Q etc. in isolated systems that don’t share anything more than a conceptual logic.
Doing anything that oraz feels like XKCD problem as in th risk of building S+1 standard solution.
Researching, I’ve seen configuration languages, in-house hacks and more. I also looked at M4 at some point and it felt dated and hard to integrate. But I think world is ripe for general purpose, typed, macro solution. Seems that typescript fills that gap but TBH I’d expect something like nix get there first.