"I See What You Mean" by Peter Alvaro

For an introduction to Dedalus with less reading, Peter Alvaro's 2015 Strange Loop talk was fantastic. [VIDEO] --- Edit: Actually Chris Granger gave an Eve talk at the same conference. It's interesting to see how Eve has evolved since. [LINK]

Not anything I’d want to use. The closest is prolog. But at a higher level this is what Eve attempted to do. Eve was built using the semantics of Dedalus which is built from datalog. I highly recommend watching Peter Alvaro’s Strangeloop talk about creating Dedalus - it’s exactly the same train of thought you’re onto. [VIDEO]

This Strangeloop talk by Peter Alvaro is a good introduction to the thinking behind some of these systems: [VIDEO]

Also: I see what you mean: [VIDEO] and Applying Failure Testing Research @Netflix: [LINK] both by Peter Alvaro (second also includes Kolton Andrus) are thought-provoking looks at failure modeling in distributed systems.

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. [VIDEO]

If model-theoretic semantics and the various ways to slice, dice, and extend Datalog are interesting to you, then almost any talk by Peter Alvaro might be as well. In particular: [VIDEO]

I'd be more interested by pointers for Javascript front-end principles, because I feel like I'm lacking some background to understand much of what I'm encountering, whereas there's quite a bit about machine learning (which I haven't checked, still I have good hope it covers the fundamentals). Deduction systems: see [VIDEO] for instance.

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