A Real, New Language
The Next Killer Programming Language
Can you name a new programming language (or language feature) that isn’t the synthesis of a group of other languages, or directly stolen from another language?
If you had moved to F# a few years ago you would’ve had async workflows way before C# did. C# eventually got something similar.
Idris’s dependent type system will give you more confidence in your system via its type system, which is similar to Agda.
And So Goes the Language Game
None of this is new. Even when you read about the features coming out in ES6 (or better yet, listen to Brandon Eich tell you first-hand) the majority of what you hear about is plans to steal features of other languages.
And so goes the language game.
Here’s the thing— I’m not trying to argue that learning from yours or other’s mistakes isn’t a worthwhile process. What I’m trying to argue is that you won’t discover new frontiers while that is your only improvement process.
A New Perspective on Languages
In Douglas’ Crockford’s interview with Scott Hansleman he told a story about a Java library he wrote for JSON parsing that for lack of better words, made me rethink everything about programming languages.
In the story he recounted how he had designed his JSON parsing library with primitives that had a bounds of lets say, 1GB. He did this because the programming language made him choose what size he wanted up front, and with the ability to make that choice he made a wrong one. He found out that it was the wrong choice when someone submitted a bug report akin to “I can’t parse a 2GB JSON file.”
Hmm. Why do languages make us choose the sizes of primitives up front? Why can’t the program figure out the size we’re going to need and optimize for us?
A Real, New Language
Code → Compile → Deploy → Coach
The “coach” is the new step up there, if you didnt notice. Its something managers have been doing for years; let your employees work and every so often or in the case of emergencies, step in and let them know how to work a little better.
In my mind, the “coaching” procedure would be implemented by the VM/runtime monitoring what is happening in code branches in a way that enables 1) reporting to a user and 2) self-improvement(meaning recompilation/deployment).
Another translation of “coaching”— code that self-refactors (or suggests refactors) via self-monitoring.
The “coaching” mechanism could observe that this function repeatedly maps surjectively/bijectively and might ask if its ok to convert the function to a map data object.
The “coaching” mechanism could observe that this function frequently takes 300ms to complete, and that for periods of days the function is surjective. It might ask the user if its ok to cache the result based upon the name in order to decrease the hit w/ looking it up.
var temp = 0;
The “coaching” mechanism could observe that the value of i is always 0<i<100 and might ask if its ok to use a byte for it. It might also always observe that temp never gets large enough to need a 64 bit integer, and might auto decrease the variable size to conserve memory.
people[i].id = i;
The “coaching” mechanism might recommend that you create a function that sets the id and saves the person within the same for loop, so as to convert the total cost from O(n^2) to O(n).
This Would Actually Be New
What do you think?