And woe betide you if you happened to violate the preconditions of one of those annotations. That kind of programming is no better than C with "Segmentation fault. Core dumped."
The problem is that "system programming" or "embedded programming" isn't one thing.
There are people who want to throw around a zillion polygons at 144FPS. There are people who want max performance on x86-64 shoveling around millions of network connections. There are people who need guaranteed real time response or someone dies. There are people who need to stay asleep all the time to conserve battery and only wake up once every 5 minutes to chirp some RF.
These people do not have the same needs in a language yet they almost all wind up shoveled into C.
Umm, this is MACLISP we're talking about -- you know the types at runtime and can pass the unspecialized argument to an ordinary function. A kind of generic function I suppose, though we didn't use that vocabulary back then.
Just because this was 50 years ago doesn't mean that programmers were morons.
Consequently, whatever you sent in was assumed to be what the annotation was. There was no "compilation phase" to ensure that the type at the call point actually matched the type in the annotation. If those differed, then your program would just go boom.
Now, it could be that I'm remembering something other than MACLISP. It's been a lot of years.
I tried to be clear by using the modern terminology “generic function”.
If you compile a function with those annotations you’d end up with two functions: one that could be called if you knew the types at compile time and one that did not.
Why is that tho? There are better languages for each of those applications. What do you think, is it business requirements? Hardware? Regulation? Legacy code?
C is a great choice because I can hire people who know C and get good results. A domain specific language will not be much better than C for any of the above. It turns out that all the hard problems listed above are similar enough that someone good in one will be good in them all and so I can hire C experts from any field and get going fast without having to teach them my domain specific language that isn't really much better.
I do not know the best way for any modern language to take to any other modern language - but 1972 C is a big negative to them all.
On other systems we have XPC, COM, AIDL, TIMI, MSIL.
That said I fully accept your correction. (even though it doesn't apply in my world)
The funny thing is that MACLISP could do this back in the early 70s. While Lisp is a dynamically typed, GCed language, MACLISP let you annotate variables to promise that they would only be called on certain primitive types, thus supporting compile-time optimizations for numeric code and not necessarily allocate memory, follow a pointer, unbox data etc. This was critical to make packages like MACSYMA run on machines with performance in the KIPS range.
Although languages like Python support similar declarations or annotations, they aren't used in the same way -- if you want performance you write the module in C++ and give it a python interface.