4 min read
Next in trending

A Real, New Language

The Next Killer Programming Language

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?

Hmm.

Coffeescript will transpile to JavaScript and give you the use of comprehensions (like python) along with some other syntax more familiar to ruby programmers.

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.

Hmm.

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?

It was in this moment I found myself now fully understanding and loving “Crockford’s Javascript”—me, the guy that was really looking forward to having better primitives in JavaScript because PERFORMANCE— instead of just Number. Ugh.

A Real, New Language

To me, it does not seem unattainable for us to have both performance and “Crockford’s Javascript.” Here are my thoughts on how to attain it:

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.

“Coach” Examples

function(name){
if(name==="micah")
return "smith";
if(name==="lefty")
return "ranz"
}

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.

function(name){
return sql.getPersonByName(name);
}

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.


function(){
var temp = 0;
for(var i=0;i<100;i++){
temp+=100;
}
return temp;
}

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.

function setId(people){
for(var i=0;i<100;i++){
people[i].id = i;
}
}
function savePeople(people){
for(var i=0;i<100;i++){
sql.savePerson(people[i]);
}
}
setId(people);
savePeople(people);

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

We could achieve performance and implement “Crockford’s Javascript”— we could keep the language simple enough that it decreases giving users the ability to make bad decisions— and at the same time we could still churn out performance increases. Beyond that, we could help lower-level programmers level-up their understanding and their code.

What do you think?