5 ms·

> Is it planned that users of Eve will routinely construct new or modify existing domain-specific editors to the task at hand? Not sure at this point. For now

by jamii 12y ago

> Is it planned that users of Eve will routinely construct new or modify existing domain-specific editors to the task at hand? Not sure at this point. For now we are focusing on the core interactions and we'll build out the rest once we've put tools in peoples hands and seen how they work. > What domain-specific editors are you planning to include in public release? Something for UI construction on the web? The table, rule and function editors for managing data and logic. A UI editor, hopefully with some constraint-based layout model. Various debugging/tracing/understanding tools. > Since first focus of Eve is on web apps (and it's hosted on javascript, correct?), will it cover both client and server applications? It will have to. Not sure yet how that will work. We can do websocket-style stuff at the moment but we will want to provide something simpler on top of that. > Will there be an FFI? Yes. You will be able to add new functions / datatypes (like http://www.postgresql.org/docs/9.1/static/xtypes.html http://www.postgresql.org/docs/9.1/static/xtypes.html), new table/index data-structures (like http://www.postgresql.org/docs/9.1/static/gist-intro.html http://www.postgresql.org/docs/9.1/static/gist-intro.html) and new query-plan/data-flow nodes. The editor and compiler are mostly written in Eve. The core language is tiny but very extensible - since execution order is not specified explicitly but determined from data-flow you can drop new logic in anywhere to add new compiler optimisations or new editor commands. The language is also very data-centric - this week I was playing with programs that modify their own code by writing to the ast tables, triggering the incremental compiler to update the dataflow plan. > If I remember correctly, you're planning to use datalog+time+constraints and plan to use materialized views extensively, is it so? Will ability to work with changes as a stream and aggregate over them in more interesting ways than "the last always wins" be builtin in Eve? We're still trying out different models of time. The ideal semantic model is append-only, never forget. Implementing that on a real machine needs some restrictions to prevent exploding. Dedalus (http://db.cs.berkeley.edu/papers/datalog2011-dedalus.pdf http://db.cs.berkeley.edu/papers/datalog2011-dedalus.pdf) attaches epochs to each facts and only allows rules to query the current or last epoch. Edelweiss (http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf) allows querying any epoch but uses static analysis to figure out when data can be safely deleted without changing the results. > Have you tried to show a prototype to children and how do they respond in learning such system if so? What was the reaction of academic friends who were not too familiar with standard forms of programming (like you did with the first prototype of Aurora)? No children yet. We test things on adult non-programmers regularly. That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out). > If I'll ask more questions will it be all right and not too much trouble? :) Keep 'em coming.

dragonwriter 12y ago
I find the details you are giving here interesting, and quite promising. > That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out). I worry about that -- I can see where its probably a huge gain for initial usability but my concern with it is that it shows signs of one of the big problems with spreadsheets in that they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it, but calling in a professional programmer doesn't make it maintainable either, and you essentially need to do a ground-up reanalysis and rewrite to get it into a state where it is maintainable with the complexity it has grown to.
- jamii 12y ago
  Scoping is basically a way of mapping human-readable names to uniquely addressed code objects. When I say "foo" the compiler walks up the lexical scope until it finds a declaration for a variable called "foo" and replaces the human-readable name with the corresponding unique id. Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean. This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST. > ...they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it... Like most things, the problem can't be solved with technology alone. We can improve the tools to make it easier to organise code and to make it easier to understand other peoples code but we will also have to find ways to scale up the teaching aspect. It's the 'pit of success' - we have to design the experience so that people naturally end up doing the right thing. That includes building a community where people learn from each other and are exposed to better ways of structuring their thoughts.
  - dragonwriter 12y ago
    > Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean. > This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST. I suppose I'll have to see how it works when there is something available to poke on, but that description doesn't allay my concern about it making a programming environment that makes writing easy, but reviewing, understanding, and maintaining previously-written programs hard in much the way that spreadsheets do. If the information needed to disambiguate references is buried behind the scenes and not readily apparent in the primary interfaced used for editing, that seems problematic.

by jamii 12y ago

dragonwriter 12y ago

I find the details you are giving here interesting, and quite promising. > That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out). I worry about that -- I can see where its probably a huge gain for initial usability but my concern with it is that it shows signs of one of the big problems with spreadsheets in that they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it, but calling in a professional programmer doesn't make it maintainable either, and you essentially need to do a ground-up reanalysis and rewrite to get it into a state where it is maintainable with the complexity it has grown to.

jamii 12y ago
Scoping is basically a way of mapping human-readable names to uniquely addressed code objects. When I say "foo" the compiler walks up the lexical scope until it finds a declaration for a variable called "foo" and replaces the human-readable name with the corresponding unique id. Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean. This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST. > ...they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it... Like most things, the problem can't be solved with technology alone. We can improve the tools to make it easier to organise code and to make it easier to understand other peoples code but we will also have to find ways to scale up the teaching aspect. It's the 'pit of success' - we have to design the experience so that people naturally end up doing the right thing. That includes building a community where people learn from each other and are exposed to better ways of structuring their thoughts.
- dragonwriter 12y ago
  > Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean. > This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST. I suppose I'll have to see how it works when there is something available to poke on, but that description doesn't allay my concern about it making a programming environment that makes writing easy, but reviewing, understanding, and maintaining previously-written programs hard in much the way that spreadsheets do. If the information needed to disambiguate references is buried behind the scenes and not readily apparent in the primary interfaced used for editing, that seems problematic.