DEV Community

Discussion on: The Self Provisioning Runtime

Collapse
 
dougmoscrop profile image
Doug Moscrop

When I look ahead, where my ambition vastly exceeds my ability, I see something like a truly universal virtual machine who's design would make Alan Kay proud (or is that just what the cloud/web ultimately is, anyway?), I see Armstrong's Entropy Reverser, something that can push-pull self-provisioning (self-REPLICATING?) programs through the fog or to the data, where even persistence becomes an emergent property of intentionally naively written programs, where everything is either machine driven or at least machine assisted and constantly trying to optimize itself, rewriting millions of lines of code and using test cases and type information to find suspected compatible alternative implementations, it's system-level-JIT, and all kind of things my lack of a computer science education probably prevents me from naming properly.

The only thing I know to call it for sure, is a revolution. I can't even fathom how many hours of productivity are spent solving and re-solving the same classes of problems. Why should developers even be asking if they should pick X or Y database? Why should they have to decide of their data should be column oriented or not? Why can't the runtime reoptimize these things on the fly, after all, it's my experience that whatever was true when we made the decision soon became less true as usage and requirements start to migrate. Are all your indices and views not somewhere in your source code already, hidden in plain sight?

Anyway, keep up the awesome work, I look forward to seeing lambdragon's full potential!

Collapse
 
aldonline profile image
Aldo Bucchi

Hey @dougmoscrop ,

The only thing I know to call it for sure, is a revolution. I can't even fathom how many hours of productivity are spent solving and re-solving the same classes of problems

Absolutely!

All programming languages were designed with a set of requirements in mind. But, especially when it comes to popular languages like JS, there are notable omissions: Data, multi-runtime, long running processes, build targets.

These "missing requirements" have to be solved by adding scaffolding. And this is where most complexity comes from.

To solve this, we have 3 options:

  1. The aforementioned scaffolding, which is what we do today with libraries and frameworks
  2. Redesign the languages. This is tempting, and is actually what we did initially (we built a prototype language that had everything that was missing). But this is unrealistic since even in the best case scenario it would take a decade to penetrate. But, most likely, would end up adding to the long list of ambitious integrated languages that are somewhat dormant (like Dark Lang)
  3. With a combination of idiomatic patterns (that don't break or escape the host language) + some new kind of technology that can "infer" the missing aspects from our code

The other thing here is to understand that the mental model that people have when coding is local: One runtime, one machine, one heap, etc.
If we can "virtualize" this local thinking so it can be layered on top of a more complex cloud, then we can give developers the ability to stay within this simple world.