"I See What You Mean" by Peter Alvaro

Your language example, and the burger example seems flipped. I assume you prefer artisan burgers, which means you like no language restrictions. Badly chosen restrictions are not good, we can all agree. But what do good restrictions look like? Back in the day, programmers prided themselves on being able to do their own memory management, and bristled at the idea of a compiler or the runtime doing it for them. Now, that's the exception, as most of the time, we don't think about memory management in most languages we program in. As time marches on, we'll find more of these restrictions that we all eventually agree are good practices, and the next generation of programmers will take it as a given in programming. As a look beyond functional programming restrictions, I encourage you to check out Peter Alvaro's talk on Distributed Systems. Here, he talks about how queries over distributed systems is really hard to reason about, because time is now relative--there's no central clock to measure time. However, if we restrict ourselves to a language whose queries cannot express negation, a lot of the hard stuff about distributed systems go away. [this video]

Slava (coffeemug) is very brave to introspect publicly and whenever I interacted with him, behaved with greatest integrity and kindness. Unfortunately, his hypothesis here that devtools are a tough market does not ring true. Making a business is always tough, making one that does something new is even tougher. There are many tools and database companies doing extraordinarily well, from Atlassian to Cloudera to Docker to Elastic. The difficulties that RethinkDB faced, as it pivoted from closed source MySQL DB backend, to open source independent database with a very cool update mechanism, were in my analysis much more mundane. Simply, RethinkDB was not easy. Here is a flavor of their thinking, when they rejected a REST HTTP interface: "The RethinkDB query language is so simple, expressive, and pleasant, that trying to make it available over HTTP would be quite difficult and a disservice to users." Developers have a big advantage when making devtools in that they are their own target market. They are, but only at the start of the project before they become embroiled in it. Ironically this feeling of making it for oneself leads to a mistaken urge to thrust complexity onto the target. As an infra engineer myself, this is something I always try to keep in mind -- I worked on a modelling language at a large company and I credit its success to its absolutely straightforward and accessible syntax, lack of dependencies and straightforward integration into workflows. The temptation is a

One of the more interesting parts (to me) about Eve wasn't the interactive programming or the literate programming, but that it included a database inside of the programming language. Most programming languages think of a database as a thing separate to it (I think Smalltalk is an exception). Hence, they needed language constructs to make it easier to talk to databases. As a result, Eve was inspired by the Bloom language being researched at Berkeley, which was in turn inspired by an old language called Datalog. In it, they take constraints of a declarative language (like SQL) and use it to make distributed computing a lot easier. "Our main data-structure was now a tree of tables. Rather than one big top-level function, we switched to a pipeline of functions. Each function pulled data out of the global store using a datalog query, ran some computation and wrote data back. Having less nesting reduced the impact of lexical scope and cursor passing. Using datalog allowed normalising the data store, avoiding all the issues that came from hierarchical models. At this point we realised we weren't building a functional language anymore. Most of the programs were just datalog queries on normalised tables with a little scalar computation in the middle. We were familiar with Bloom and realised that it fit our needs much better than the functional pidgin we had built so far - no lexical scoping, no data-structures, no explicit ordering. In late March we began work on a Bloom interpreter.

Of note Bloom is an ancestor of Eve. Bloom is a descendant of Datalog via Dedalus. "Dedalus: Datalog in Time and Space" [link] Here is Peter Alvaro's Strange Loop talk - [this video] It was a shame that most people, seemingly the Eve devs as well, seemed to focus on making Eve a language for easy programming for the masses. Thats a huge wall of a problem with a limited funding slope. I think if there had been more upfront work and focus on the distributed programming/database possibilities, that Eve would have founded an actual community to push it along. Eve as a language for doing business logic against say Kubernetes? As a language to wire up ETL processes? I think it could have found a niche that would have made it grow in power before trying to take on the mass market. Just a thought.