joshuafcole

I think the lines between "available library of existing code", language, and IDE are much murkier than they might appear. If one programmer is given raw assembly and the other Python, you're probably going to see at _least_ a 10x productivity bump to the python user _even if they use no additional libraries_. Language and IDE choices impact the vocabulary available to express solutions in the same way.

I won't speak for the rest of the team, but walking away from Eve is unquestionably the hardest thing I have ever had to do. We were given a once in a lifetime chance to reinvent the way we build software, with the only constraints being our imagination and the clock imposed by our runway. I think by the end we were tantalizingly close to success too. Many of the tools we made were significantly more productive for certain domains of work. Unfortunately, close doesn't cut it in a startup, and despite many, many sleepless nights pushing we weren't able to tie a single cohesive product together that was both better enough and general enough.

You might argue that we should have settled on one of our iterations that was close rather than continuing the search for something better. I can't really disagree with that except to say that each of the latest prototypes was such a large improvement over the last that it felt irresponsible to stop short.

Unfortunately, we've had to find work that would keep a roof over our heads, but that doesn't mean we've buried the work we've done. We've open sourced Light Table and every iteration of Eve that was remotely useful, and we've worked hard to share the most important things we learned on the journey with those who might continue it through essays, speaking, and thorough commenting in the most interesting sections of our code. Nothing would make me happier than having someone take inspiration from our attempt and build the future of programming before I have the financial freedom to return to working on it.

Like everyone at Kodowa, I just want to live in the world where those tools exist. I am sad that we weren't able to complete them in the short time that we had, but I am not sad that we tried.

Ah, thanks for the tip. Fixed now.

Actually, several of those editors were explorations of what programming would look like using just the mouse. The mouse isn't really the issue with programming performance, per se -- instead the problem is the constant context switching back and forth.

Several version focused on just the keyboard, but we found that most of the things we built using Eve were inherently visual, and as such needed to be tested and interacted with using the mouse. Since we can't eliminate that context shift, we tried doubling down on it.

As a die hard Emacs user, I was shocked by just how competitive the mouse could be in the smalltalk-esque environment we built.

The application renderer and editor are wholly separate, though for this release we don't yet provide an end-user way to access the former separately. With respect to distribution (in the rolling out to users sense), we plan to start working on that story over the next few months. To get there, we need to finalize our policy system (which lets you secure your program against malicious users), improve performance, and get the basis of our horizontal scaling story in place. If you're interested, keep an eye out for posts about the world scale computer milestone on our blog!

It certainly isn't off-topic. There's a lot of UX work to do now that we've gotten a solid foundation out of the way. Finding a good way to pack a solid Eve editing experience into smaller screens is high on that list.

Hey Taneq, The fear of over-simplification is totally reasonable. Programs like Game Maker certainly gain their shallow learning curves at the expense of overall power, precision, and depth. We don’t think that tradeoff is acceptable either. Luckily, there is a difference between architectural simplicity and “kid-friendliness”. That’s a big part of why we had to start from scratch and build a new language -- we needed something that was simple from its core if we wanted to make it simple to use without losing expressibility. Rather than rehash the specifics of our architectural decisions (though I encourage you to check out the blog and the upcoming deep dives if you’re interested!) let me describe briefly some problems I don’t have to deal with anymore when I use Eve.

- Asynchrony is pain-free (no imposed cost, no alternative syntaxes, no callback hell).

- Programs are live by default -- there’s no need manually listen for changes all over the place, and no falling out of sync.

- Programs are easily extensible -- because of the above, anything that conforms to the pattern for a block will get picked up by that block.

- Mocks, shims, and other injection patterns are free -- making testing and experimenting very easy.

- Refactoring is trivial -- If a block changes, I only ever need to change its immediate downstream users to get back to a working state. Eve can find those for me.

- Everything is data, so state sharing is trivial. When a coworker finds a bug in my code they can save their exact state and send it to me with a single command.

- The number of classes of bug are drastically reduced. This doesn’t mean they aren’t occasionally perplexing, but because there are so few ways for a program to fail, I can literally run through a checklist of possibilities while debugging. This is the premise that powers the inspector.

This certainly isn’t a complete list, but it’s a few of my favorite quality of life improvements that I think sets this project apart. If you do get the chance to use it, I’d love to hear your thoughts on what works and what doesn’t for you.

Graphics and game programming is a big interest of mine at a hobbyist level, so I definitely feel your pain. It's difficult to excel at all things, and in general each design decision brings with it a set of trade-offs. There are really two aspects to this question that merit addressing separately.

The first is whether a bloom-like language such as Eve is semantically well-suited for game design [1]. Unfortunately, there's not a lot of precedent here yet (it feels like there hasn't been a lot of overlap in interest in game design, datalog, and free time yet). Having used various datalog implementations over the past year though, and I'm convinced that it lends itself very naturally to building a Component Entity System style game engine. datalog's twin benefits of provenance-based debuggability [2] and strong decoupling [3] really help in building and maintaining advanced logic systems. I'm concerned it will have a bit of a learning curve, since we are as a rule not very used to thinking about systems programming this way, but it's certainly felt more intuitive than any other technique I've used in the past once I picked up the mindset for it.

The second is whether a language that lives in a persistent (potentially remote) relational DB is fast enough to run a game in. This is the bigger question for me. We've been doing a lot of research in this field and I'm convinced that for Eve's specific needs we can architect a much faster DB than the general purpose alternatives [4]. That said, even with all of the clever tricks in the book, there's still going to be some amount of overhead compared to working in purpose-built data structures with raw assembly. In cases where we're just not fast enough (either because the optimizations and query planning aren't all there yet or because we've come up against a fundamental design bottleneck) we do have an escape hatch. Through a system called watchers (which enable Eve to I/O with the outside world), it's possible to wire in compute programs written in other languages to do the heavy lifting with a very low latency. The watcher system is probably best conceptualized as a very simple FFI. I think we can get Eve to the point where it handles typical 2D games with aplomb, and for the rest I plan to put a lot of love into the watcher interface with the hopes that it will be fast enough to keep the game logic in Eve and just delegate physics and potentially rendering work to external components.

Anyway, this is still a fair ways off, we're beginning with an MVP and iterating from there. Game development is certainly on my radar though, and I look forward to publishing news about it when Eve is ready to do so. :)

[1] In the current experimental version of Eve, the only exposed query language is our high level search language, which makes very expressive searches like `dishes with eggs and sugar that are savory` trivial, but someone limits the power and scope of a single query. This is built on (and indeed compiles to) a Turing complete sub-language that will look much more familiar to datalog users. We tentatively intend to expose this in the near future.

[2] Given that the underlying graph structure of the program is stored relationally as data (exactly like user data) in Eve, it's very simple to see which sources a view depends on or feeds into, and even to ask complex questions like "when did this value become 10?".

[3] One of my favorite benefits of Eve is that it strongly encourages data composition over functional composition. In effect, If I have a view `active users` over the list of all users `users` and a set of other views dependent on that, they depend only on the data `active users` produces, and not it's implementation whatsoever. `active users` could be replaced in any way that still provides data isomorphically without any of its dependents being aware of the change. Further, even if the data changes non-isomorphically, only it's direct dependents will need to change, rather than having to propagate these changes all the way to the leaves of the system.

[4] To be clear, I don't claim that ours would hold a candle against the 20+ years of experience that GP DBs bring to the table across their whole domain of use cases, just over the small handful that we require.

Eve is served as remotely as a webapp, and it'll run in all modern browsers. Presently it's supporting Chrome first; but support for FF, IE Edge and others is on the map. Along the way, we're looking forward to gathering feedback on how we can improve user experience across the board, so please drop us a few issues on how we can make things better if you get the chance to try it out.