I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it?
My gut says something simple is missing that makes all of the difference.
One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.32 and bar 4.5.2 then returning baz 42.0 The register will then tell you all the things you can make from baz 42.0 and the other data you have. A comment(?) above the function has a checksum that prevents anyone from changing it.
But perhaps the solution is something entirely different. Maybe we just need a good set of opcodes and have abstractions represent small groups of instructions that can be combined into larger groups until you have decent higher languages. With the only difference being that one can read what the abstraction actually does. The compiler can figure lots of things out but it wont do architecture.
There's more to a function than just types. It's not sufficient to know that the function outputs a baz 42.0. You have to understand which one. The oldest? The latest? The one that matches the foo and bar input parameters?
I think that's the part where it remains difficult. Someone has to convey clearly what the semantics and side effects of the function are. Consumers have to read and understand it. Failing that, you get breakage.
If there is anything to know about the type register sub types for each.
Like the way we say something is an mp3. Why would it be good to have one unifying concept where we pretend a car crash and Beethoven are the same thing? It can be a WAV too!
walking away from the keyboard I thought I did a pretty poor job describing that one.
Ill try an example, those always have the potential to describe things even worse.
Imagine a type that is an outdoor datetimetemperature in utcc or a first name form value or a solitaire terms of service checkbox value. Have both the chewing gum balls in dispenser and a total weight of chewing gum balls in dispenser as well as a min-max weight per chewing gum ball in dispenser.
Make it just as ridiculous as it sounds. If you can quantify it a type must be registered. If there is a pair of quantifications to be had register that too.
The vision just expanded! Make for everything an xml implementation then do a ram drive and make all variables into files.
The idea sounds so ridiculous it might actually work. Think of the employment opportunities!
My gut says something simple is missing that makes all of the difference.
One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.32 and bar 4.5.2 then returning baz 42.0 The register will then tell you all the things you can make from baz 42.0 and the other data you have. A comment(?) above the function has a checksum that prevents anyone from changing it.
But perhaps the solution is something entirely different. Maybe we just need a good set of opcodes and have abstractions represent small groups of instructions that can be combined into larger groups until you have decent higher languages. With the only difference being that one can read what the abstraction actually does. The compiler can figure lots of things out but it wont do architecture.