Eve is a programming language and IDE based on years of research into building a human-first programming platform. From code embedded in documents to a language without order, it presents an alternative take on what programming could be - one that focuses on us instead of the machine. This is Eve:
We've made tremendous advancements since the early days of programming, but the modern form still forces us into the role of bit shifting machines. Programming has always been for us - the humans tapping at keyboards. The computer doesn't care what syntax or semantics we use or how error messages are phrased. Those are for you and me. And this is how we treat ourselves...
Focusing on the machine and ignoring the human factors of software engineering have led us down a difficult road. From inscrutable error messages to semantics that require years of study to understand, we've landed on a version of programming that is actively antagonistic toward our goal of creating usable and robust software. To make matters worse, we're programming as if we still had the 1970's computer that our tools were developed for. Unsurprisingly, we are struggling. A lot.
There's no reason we have to stay on top of a sinking foundation though. What if we went back to first principles and put humans first? What would that look like?
Over the past several years, we've been exploring what an alternate future could look like and have distilled that research into a platform that we call Eve. To get a taste, let's take a look at a day in the life of someone programming in Eve:
The first difference you'll notice is that programs look more like word documents than code files. Eve is designed for "literate programming" - instead of comments embedded in code, code is embedded in a document.
This gives us the freedom to organize our programs based on how we actually think, not how the code will be compiled. We can group blocks based on functionality, similarity, owner, or anything else we can think of.
More importantly though, it gives us the ability to weave a narrative of not just what the program does, but why it does it. You can write a spec and then embed the blocks of code that make it work. Someone new to the project can look at the table of contents to get a sense of what's going on and then dig into a section to add something. Instead of constantly trying to piece the narrative back together every single time we fix a bug, we can make it an artifact of programming in the first place.
The environment we want in this context is more about narrative creation than class hierarchies. We want a *reading* and *writing* environment that allows us to meaningfully lay out and explore our program. The first step towards that is having a table of contents that provides both an outline and a convenient form of navigation.
But just because we have a linear representation of the program, that doesn't mean we can't view it in other ways just as easily. Instead of a slew of tabs and complex navigation features, we have a document that arranges itself in whatever shape we need. And as much as possible, everything is placed in context so that the narrative is kept front and center.
Eve is based on a single unifying principle: everything is a record - a set of attribute/value pairs associated to an ID. With this uniformity, Eve only needs a handful of operations that query and manipulate records. Want to send an email? You create an email record. Want to look at messages sent to slack? You query for message records in the slack database. Want to make a todo app? Query for todos and create div records in the browser database.
Blocks are reactive in Eve; they declaratively specify "when I see these patterns, do these things." You don't need to specify how they update, or how they're cached, or how they're stored, or... If you add new todos, new divs will automatically appear.
Just nine operations let us write everything from a flappy bird clone to Eve's code analyzer.
How about memory? Like anything else in Eve, we search for what we want and then use the full power of the language to react to it. Let's send ourselves a slack message if the free memory on this machine goes below 200mb.
But we can do even better. Let's visualize free memory over time:
Think about what this does for our ability to understand programs - we can trivially visualize and react to anything in our system. Want to see a real-time visualization of users signing up? Write a single block to do it:
Visualization is only one part of the story though, sometimes we need to just dig in and investigate what's going on. When something isn't working, you press the inspect button and Eve will help you figure out why.
The inspector is an example of something that just can't be done in traditional languages. It requires knowing where things came from and how your program fits together. The vast majority of our effort debugging is spent just trying to figure out where the error even is, but Eve can take us right to it. Even better, it points us toward why it's going sideways in the first place. This is like giving a car mechanic a device that holds up a giant red arrow saying "The alternator wire is loose right here!"
Given that we spend most of our time hunting down and fixing errors, the implication of having this button is clear: we've got a lot more free time.
As we've developed Eve, we've learned that these seemingly simple choices have remarkably broad consequences on what it means to program. Let's look at a few of them.
Code isn't an asset, it's a liability. Every line adds to the surface area of potential bugs and to the pile of things that must be understood and maintained. As long as we aren't obfuscating intent, our goal should be to have less code. Eve programs tend to be very small, but even more importantly, individual blocks remain short and single purpose. Because of the literate programming focus, blocks also fit into a narrative that helps provide context. Code is presented in small, digestible pieces, with built-in explanations and a place in the larger picture. The impact this has on maintenance, navigation, and collaboration can't be overstated.
The common interface of records means that Eve blocks compose by default and because there's no inherent ordering to blocks, we're free to organize them however we want. Instead of constantly re-architecting to deal with changes, or building complex infrastructure to deal with evolution, Eve programs grow organically. Features, fixes, even visualizations can all be added without changing existing code and the lack of order allows us to put them wherever it makes the most sense.
Instead of spreading null checks and asserts throughout our code, invariants can be enforced globally by producing error records. Doing this through normal Eve blocks gives us the full power of the language to express arbitrarily complex invariants.
The fact that constraints can be expressed globally through block composition has a couple of interesting implications. The first is that correctness is pay as you go. We don't have to lay out a bunch of types or schemas before we even really know what we're trying to build. We can work on our program and layer on invariants as it seems appropriate.
The second is that these integrity constraints will never allow our records to enter into a bad state. As such, it's safe for us to think just about the block we're working on. No need to check invariants every line or worry about adding code that gives everyone ten salaries. We have local reasoning with global enforcement.
The best part though is that just like everything else, errors are records. Error handling is just another block.
"Zoom and enhance" is a common trope in science fiction, but what prevents us from actually having it? In the case of images, we really are missing the data, but with software there's an incredible amount of information that we just throw away. What if we didn't?
The closest thing we have to this now is the web inspector in browsers, but it's still missing a lot of information. Eve captures everything it can, which allows us to connect the dots in very useful ways.
Our systems should be measured by our ability to understand them when they're falling apart. Why can't we ask "Computer, why is this malfunctioning?" like they do in Star Trek?
The inspector is like having another programmer right next to us 24/7. When we're stuck, we hit a button and Eve sets us on a path toward finding and fixing whatever's wrong - "Computer, why is this slow?"
One of the single greatest changes we can make to programming is giving ourselves the ability to ask questions. Not just why doesn't this work, or why is this slow, but what's the average number of times a user clicks this button or how many people did we pay this week? Eve's entire model is based around allowing us to ask any question we come up with. It liberates us from the "undefined of undefined" and let's us peer deep inside our systems.
Simple solutions are unfortunately much more difficult to find than complex ones. It requires being deliberate and questioning many of the things we hold as inherent truths. In the end, the design of Eve stems from a complete focus on simplicity. Instead of Eclipse, let's do our work in something more like pen and paper. Instead of complex semantics, let's have everything be a record. Instead of thousands of debugger options, let's have a magic tool where you click on the thing that's going wrong. Eve is about making things simpler for the people solving problems: us.
There's a lot more to dig into, from how we think Eve can shift the bell curve of programming to how we can make this crazy language fast. This is, however, just the first of three milestones on our roadmap:
The first step was to build a simple, human-centric form of programming. What we've shown here isn't just a demo, it's a real, albeit early, piece of software. You can play with it here.
The next step is to show how Eve allows us to get rid of the 1970's notion of a computer and embrace a distributed world. Along the way, maybe we could get something like Moore's law back without forcing people to understand Paxos.
The final step is to show how all of this lays the foundation for a more powerful version of end-user computing. While not everyone wants to write *software*, we all have something to get done and chances are the computer can help us do it.
Through all of our research, we've started to piece together a future of computation to aspire to - from humane tools and a different concept of the machine, to giving everyone on the planet a superpower. There's so much more to do and regardless of whether or not you believe Eve is it, it's up to all of us to make such a future a reality. Failing to do so doesn't just hold our industry back. It drags down all human endeavors waiting to be driven by better forms of computation. The computer is arguably the single most powerful tool ever developed. It's time for us to truly wield it.
The more interest we can show, the easier it will be for us to continue doing this work. The best way to help is to spread the word and engage with us. Unfortunately we aren't hiring right now, but we hope to change that in the not too distant future.
Below we've put together a few followup pages and over the next several weeks we'll be adding a set of deep dives. If you're interested in how Eve came to be, the research it's based on, or some of the deeper implications, check them out: