The ideal structure of a programming language seems to depend on the user. I mean, if someone thinks in machine code and can't understand anything else, then machine code's optimal for them, regardless of how impractical it might be for just about everyone else.
What we really need is intentional programming: we specify what we want, in whatever manner is most natural to the user, and the computer figures out how to make that happen. The computational expense of transforming intent into machine code is unavoidable; it has to be paid through some combination of human and machine effort, so there's no additional cost incurred by having a machine do it.
The really cool part about all of this is that, once you have a system that can transform intent into code, it's trivially meta-circular, causing it to become self-optimizing. And once you integrate machine learning into its optimization logic, it becomes intelligent, using machine learning to optimize its own logic, including the machine learning, continuously reemitting further optimized variants of itself to whatever computational resources it has available; getting it to utilize various CPU's, GPU's, distributed architectures, etc., becomes a matter of specifying their operation, such that it's like writing drivers (except the system merely needs to know what the computational resources _can_ do; the problem of how to make best use of those abilities remains a problem for the intentional logic itself).
Anyway, that's the premise of my startup, Intentional Systems. I've been working on this for a good while, and ended up applying to YCombinator's W2019 round. Regardless of how that goes, this is what's happening; intentional operation's the future. And it's awesome!
With respect to this blog post, my point's that we don't really need a "language" for the 21st century, but rather a system that allows users to specify what they want in whatever terms make sense to them -- whether that's machine code, C, Lisp, JavaScript, engineering flowsheets with equations, English, or pig-Elvish -- so long as that language has a definition that provides mappings to machine code, the problem of how to map that language to machine code is a logical problem that a machine can address.
The example in the blog is a special case:
1. > FILE * test_file = fopen(“/tmp/test.txt”, “w+”);
2. > create file /tmp/test.txt for input and output as test_file
Here, the two languages have the same logic, varying only superficially. This allows an IDE to save that logic as an AST, then display it to a user according to their personal display preferences. There's no reason anyone opening that code in their IDE has to see it in Format 1 vs. Format 2 any more than they have to see it in Font 12 vs. Font 14. I think the folks behind Roslyn tried to capture the source code's features that were extraneous to the AST as ["syntax trivia"](https://github.com/dotnet/roslyn/wiki/Roslyn-Overview#syntax...).
It's a less trivial issue when the code isn't so transparently bijective. For example, programmers collaborating on the same project would have more trouble interacting if some prefer to program in [Rule 110](https://en.wikipedia.org/wiki/Rule_110) while others prefer idiomatic JavaScript. I mean, that's an addressable scenario, but it's more complicated.
What we really need is intentional programming: we specify what we want, in whatever manner is most natural to the user, and the computer figures out how to make that happen. The computational expense of transforming intent into machine code is unavoidable; it has to be paid through some combination of human and machine effort, so there's no additional cost incurred by having a machine do it.
The really cool part about all of this is that, once you have a system that can transform intent into code, it's trivially meta-circular, causing it to become self-optimizing. And once you integrate machine learning into its optimization logic, it becomes intelligent, using machine learning to optimize its own logic, including the machine learning, continuously reemitting further optimized variants of itself to whatever computational resources it has available; getting it to utilize various CPU's, GPU's, distributed architectures, etc., becomes a matter of specifying their operation, such that it's like writing drivers (except the system merely needs to know what the computational resources _can_ do; the problem of how to make best use of those abilities remains a problem for the intentional logic itself).
Anyway, that's the premise of my startup, Intentional Systems. I've been working on this for a good while, and ended up applying to YCombinator's W2019 round. Regardless of how that goes, this is what's happening; intentional operation's the future. And it's awesome!
With respect to this blog post, my point's that we don't really need a "language" for the 21st century, but rather a system that allows users to specify what they want in whatever terms make sense to them -- whether that's machine code, C, Lisp, JavaScript, engineering flowsheets with equations, English, or pig-Elvish -- so long as that language has a definition that provides mappings to machine code, the problem of how to map that language to machine code is a logical problem that a machine can address.
The example in the blog is a special case: 1. > FILE * test_file = fopen(“/tmp/test.txt”, “w+”); 2. > create file /tmp/test.txt for input and output as test_file Here, the two languages have the same logic, varying only superficially. This allows an IDE to save that logic as an AST, then display it to a user according to their personal display preferences. There's no reason anyone opening that code in their IDE has to see it in Format 1 vs. Format 2 any more than they have to see it in Font 12 vs. Font 14. I think the folks behind Roslyn tried to capture the source code's features that were extraneous to the AST as ["syntax trivia"](https://github.com/dotnet/roslyn/wiki/Roslyn-Overview#syntax...).
It's a less trivial issue when the code isn't so transparently bijective. For example, programmers collaborating on the same project would have more trouble interacting if some prefer to program in [Rule 110](https://en.wikipedia.org/wiki/Rule_110) while others prefer idiomatic JavaScript. I mean, that's an addressable scenario, but it's more complicated.