Welcome to Part I of my VI-part series about , an exciting and fascinating new programming language. Eve How Eve unifies your entire programming stack I. When logic programming meets CQRS II. Throwing off our scope chains III. Smalltalk and protein programming IV. The rock-solid foundation for Eve’s big vision V. Why Eve will be perfect for realtime apps VI. Eve is the culmination of years of research and development by the visionary team who previously founded . Version 0.2 of Eve launched last month and made a big splash on , which is how I first heard about it. Light Table Hacker News This latest version of Eve makes for some very cool live demos, such as “ ”: Flappy Eve Scrolling through the demo for the first time, a few striking features jump out: flappy.eve The IDE looks like a WYSIWYG blog editor. Eve code is designed to be embedded within Markdown-formatted prose; it’s to the max. literate programming The syntax is unfamiliar, but still looks clean and approachable — mostly it just looks . Part of me can’t help thinking, “I see all these bracketed parts, but where’s the actual code?” sparse The code is ridiculously compact — about 100 lines. Similarly, their weighs in at only 63 lines. For comparison, has 300+ lines of JavaScript. todomvc.eve React’s TodoMVC So that was my first impression. Here’s my impression after spending hours browsing the examples, pondering over the docs, and watching tech talk videos: Wow! Eve is a cornucopia of solutions to problems I hadn’t even realized we had. It’s like I’ve been raised in a society of bicyclists, and after seeing a motorized vehicle for the first time, I’m suddenly understanding the limitations of a pedal-based architecture. After having been exposed to Eve, I can retroactively diagnose various problems in the architecture of mainstream programming stacks. In this series, I’ll try to explain what all these problems are and how Eve solves them. Problem: Layers doing the same thing differently Your software stack has many layers. The following three layers are usually the “core system” doing the heavy lifting: Database layer Remote API layer Application layer But there are also plenty of other layers that the core system talks to: Rendering layers I/O event layers Configuration layers Logging layers At a high level, these layers all do the same thing: they process data. They read input values, they compute other values, they mutate internal state, and they output values to pass to other layers. But, when you zoom into each layer, you see countless differences that obscure the fact that they’re all fundamentally about data processing. Different data models You have one or more online database systems. Their data models look like SQL tables, document collections, key-value maps and/or graphs. You have a remote API that models data as chunks of JSON or XML, or maybe as a GraphQL graph. You have a running application that models in-memory data structures and variables in a scope chain. Different operations To operate on the database layer, you can send various kinds of SQL or NoSQL queries. To operate on the API layer, you can query for data via HTTP GET and update data via HTTP POST and friends. If it’s a GraphQL API, you operate with GQL queries and mutations. To operate on the application layer, you can look up variables from the scope chain, and you can traverse or mutate in-memory data structures. For each layer of your stack, there are different data models and operations: Since each layer is different, it creates friction and room for error. You have to reason separately about each one’s properties and guarantees, and use separate programming patterns for each. And you have to write a lot of “glue code”. Solution: A uniform data-processing language Eve has a single low-level data model and a single set of operations which you can use across every layer of your stack. Uniform data model In Eve, data (a.k.a. state) lives in a set of . Different layers of your stack might correspond to different databases, e.g.: databases In-memory application data lives in the database @session The browser’s DOM tree lives in the database @browser User I/O events live in the database @event Each database contains . A record is a key-value mapping that can store primitive values as well as references to other records. Records have a simple bracketed syntax: records There are no tables or collections for holding records within a database, just databases containing linked structures of records. Eve’s universal data model of linked records is reminiscent of “semantic web” technologies like and . But Eve is more than a uniform data model… RDF JSON-LD Uniform set of operations It’s also a uniform set of operations. The three operations , and make up the entire functionality of Eve: search commit bind queries for data, similar to SQL’s search SELECT mutates the state of your data, similar to SQL’s / / commit INSERT UPDATE DELETE writes special “deduced values”, which are like SQL’s or MobX’s . I’ll say lots more about the awesomeness of later in this series. bind materialized views computed values bind It’s amazing that we can control different layers of the stack by using this uniform set of operations on Eve’s uniform data model. For example, here’s how we render a into the DOM: <div> Since the DOM tree lives in the database, rendering a just means ing a record with . @browser <div> commit tag: "div" Now, for each layer of your stack, there’s only one data model and set of operations: Since each layer is the same, there’s less friction and room for error. You can reason more easily about properties and guarantees, and use similar programming patterns for each. And you don’t need to “glue” anything together, because everything’s already connected. Higher abstractions The Eve team invented a uniform data model and uniform set of operations that can operate across your entire application stack. To accomplish that feat, they had to identify a higher abstraction that the rest of us didn’t realize was possible. To wrap your head around this achievement, it helps if you’ve already put in the effort to understand another abstraction leap that debuted this year: . GraphQL It takes people a while to understand that GraphQL isn’t a database or a server, but rather a graph query language (or “GraphQL” if you will). The point of GraphQL is to change the client’s view of an API from a small rigid set of REST endpoints to a unified linked-data structure that accepts arbitrary graph queries. Like GraphQL, Eve also isn’t a database backend or a server; it’s a language at a higher level of abstraction than we’re used to. Consider the example code from a section of Eve’s titled “A simple model: the world as data”: home page When you run that block, you’re communicating with the third-party Slack application, which of course has its own internal database. But you get to that everything is part of the Eve data universe — just like GraphQL lets you pretend that arbitrary API calls are part of a big graph universe. search @slack pretend So if you like what GraphQL is doing for the API layer, but just wish someone would do the same thing for all the other layers in one fell swoop… say hello to Eve. **Next post:** When logic programming meets CQRS II.
