> It would be interesting to hear how much of EVE code has it taken to implement compiler or editor.
The current iteration of the editor is 350 lines of our text-based Eve dsl plus 450 lines of helper js which will eventually become our UI and IO libraries.
Stratification is about 30 lines. There used to be more going on in the compiler but now that we use a constraint solver for all the query plans there isn't much left for it to do. http://p2.berkeley.intel-research.net/papers/EvitaRacedVLDB2... has some interesting ideas that we will be exploring later.
> And is there any interesting bottlenecks you would need to optimize out before release?
We've managed to get pretty surprisingly far with really dumb code. We are halfway through a big rewrite so the current build of the editor is using a runtime that is missing half of it's features. Each table is stored in a big array, we do sequential scans for constraint propagation, the incremental evaluation has not been ported yet and we don't have any Edelweiss gc. It can still recalculate and rerender in 20-40ms. That's too slow for fluid animation but plenty fast enough button clicks etc.
The lesson here is that computers are really fast and we squander most of that speed on unnecessary runtime abstraction. I'm pretty excited to see how fast it will get when we have real indexes and incremental evaluation.
> And how was the experience of writing a lot of EVE code? Do you feel yourself a lot more productive? Have you become accustomed to a new way of writing software very fast and does it feel natural to you now?
There are ups and downs.
The main upside I've noticed is how much time I normally have to spend worrying about where to put data, how to access data, how to keep data consistent and what order to do things in. In Eve you just put it in a table and let the runtime worry about the rest. I feel like I now spend a lot more time thinking about the actual problem instead of shepherding data around.
The main problem we're wrestling with at the moment is identity. Since the editor is built in the Edelweiss style as a pure function of the input events, we have to be able to generate stable, unique ids for anything that has a continuous identity. In the Bloom model we could just generate a random UUID and store it. At the moment we build ids by mashing together strings but I feel like the language should be helping us out here.
There are also a whole bunch of problems that come down to immaturity. We don't have a debugger yet so we rely on console dumps a lot. The compiler doesn't have much error checking so bugs in the editor tend to percolate a long way before surfacing symptoms. Implementing integrity constraints is pretty high up on my todo list right now.
> I'm interested in how would you use Edelweiss in non-distributed settings (I assume Eve is not targeted at that kind of applications right now).
There is a section in Out Of The Tarpit where the author argues that the ideal way to specify an application is as a purely functional view over all the inputs it has ever received. He then concedes that in practice you are forced to throw things away to avoid running out of memory. Reading the Edelweiss paper convinced me that we could program as if we were living in Mosely's ideal world and then separately specify a garbage collection strategy. It's just another instance of separating specification from optimisation which I believe is key to managing complexity.
This is probably the most risky part of our plan but we can always fall back to the Bloom model instead. The actual language implementation doesn't really vary between them.