4 ms·

I thought this was a great article when he posted it and it's always really exciting to see people engage with us about the research we've done. He links to it

by ibdknox 11y ago

I thought this was a great article when he posted it and it's always really exciting to see people engage with us about the research we've done. He links to it at the bottom, but here's a link to my followup [1]. We've learned a ton over the past couple of years and we've finally settled on a path forward. That means we're starting to move out of research mode and starting to execute on all of this knowledge gathering. To that end, we're going to be doing a public alpha release in the next few weeks for people to play with. :) It ought to be interesting to the folks here to see how crazily different our work could be - the latest version of Eve is better likened to Medium's content editor or Dropbox's paper than it is to Visual Studio. It's been a long road (with around 30 versions of Eve at this point), but there are some really exciting times ahead. Happy to answer any questions! Though I imagine there'll be plenty of discussion when we do the release :) [1]: https://gist.github.com/ibdknox/2b185fcb8e5d1de68796 https://gist.github.com/ibdknox/2b185fcb8e5d1de68796

david927 11y ago
Good luck, Chris! You're one of the few who understand the deep need to move forward, and in my humble opinion, you're on the right track.
ndarilek 11y ago
Here's a question for you, then. Has any thought been given to the accessibility story for Eve and tools like it? As a blind developer, I always get a bit nervous when the future of programming is discussed in terms I've read used to describe Eve. It seems like a very useful way of developing apps, but one that can easily exclude a subset of the population if a11y issues aren't thought through in advance. Also, part of me is tempted to dismiss Eve because I suspect we'll always have the current way of developing software to fall back on. But when I consider it more, I don't find that line of thinking productive for me. For instance, lots of folks might be tempted to dismiss GUIs for blind users because graphics, but there are actually huge advantages to representing UIs as trees of objects that can be introspected and interacted with. I can write code that scans the accessibility hierarchy for a specific element and reads it, for instance. In a command line interface, that code would need to either scan for a non-specific set of characters that a curses app might use to draw a thing that looks like a button and make a guess at its contents, and even then that logic would be very brittle. So even if Eve and whatever comes after derives lots of its power from rendering concepts visually, the underlying primitives needed to do so might have beneficial a11y implications and shouldn't be discounted because the end goal happens to look nicer than a wall of text. Anyway, would be nice to see that on the roadmap if it isn't already. Even if only 20% of programming is like this in 10 years, that's still a substantial subset that might exclude me by virtue of the accessibility story not being thought out first.
- ibdknox 11y ago
  Amusingly enough, I actually started thinking a bit about this just the other night after being told about a talk given at Dropbox about accessibility. To be up front, we know very little about it and the other night was the first time I'd ever tried to use a screen reader, so it's something we aren't likely to be good at right of the gate, but it is something we've been setting ourselves up for completely by accident. Many of the previous versions of Eve would be pretty completely inaccessible, so your dismissal would definitely be warranted. The version we've decided to run with though basically has three parts: a document editor, embedded spreadsheet cells, and a fancy plain english search. All three of which have a history of accessible solutions, so that makes me much more optimistic that we can provide something nice here. Along the way, another thing we've been very cognizant about is making sure no matter what form of input you prefer, Eve should be efficient and useful to you whether you're using a keyboard, a mouse, or touch. Many of the interaction issues we'd need to solve to better work with screen readers popup when trying to support complete keyboardability, but I have no delusion that there will be plenty more to solve there. Another interesting aspect of this version of Eve is it's really easy to imagine a voice interface to since virtually everything is done using plain english queries - it'd be kind of like having Jarvis in your google docs. Admittedly, we don't know what we're doing when it comes to accessibility, but it is something we've been thinking about indirectly and it's something I think we can at least do more naturally than the code editors of the world. Thanks for raising the issue and it's something I'd like to have a more concrete answer for in the future.
  - ndarilek 11y ago
    Cool, glad to know this is on the radar! Out of curiosity, what are you using to render the current GUI? Toolkit/framework choice unfortunately has pretty significant a11y ramifications.
    - ibdknox 11y ago
      It's all HTML at the moment.
taco_emoji 11y ago
(FYI you mention "Lotus Impromptu" but I think you mean "Lotus Improv")
- ibdknox 11y ago
  whoops, yes I did. Fixed in the gist. Thanks!
viperscape 11y ago
I haven't kept up on Eve development as closely as I would have liked, but I do try to read each blog post which are usually very interesting. After tinkering with something like unreal's blue print visual graph programming, I am inclined to build something similar for Rust lang and game development. Have you considered this approach, I know visual programming hasn't been very successful on a general level but I think it excels at domain specific tasks. Last I checked Eve didn't implement graph nodes and connection widgets, did it ever? Have you considered it? Watching unreal editor run the blue print live and seeing nodes fire off really made me rethink debugging, like the next proper way instead of basic print statements. It also is impressive to see quick results to complex behaviors through wiring up nodes.
- viperscape 11y ago
  oh I see you have moved to a graph representation, terrific!
  - cmontella 11y ago
    We used a graph editor for our last release in August, but since then we have taken a different direction.
- jononor 11y ago
  I don't think the graph part is the key thing: The ability to run a live program, question and explore it interactively is. Eve seems to be extremely strong in these aspects, especially the 'provenance' (knowing where data comes from) is beyond what existing systems provide. I say this as a developer of several graph/dataflow/visual programming tools (Flowhub/MicroFlo/Noflo and related).
isaiahg 11y ago
The presentation was very enlightening. If this was the future of business application programming I could see that or maybe even the future of programming websites. But as a game programmer I'm having trouble connecting it to my world. But it's titled as the future of programming, so I figure that would include me as well. What's interesting is the problems you want to address I deal with every day programming games. When you're making games you have to simulate physics in your head and the setup to just get a project ready is a gigantic pain. How could a game programmer use this type of system to make a game? It seems like the complexity would just get out of hand.
- joshuafcole 11y ago
  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.
tripzilch 11y ago
hey! you're the guy in the presentation video, correct? can I maybe give you an unsolicited but constructively-intended suggestion? (initially decided it was a bit too OT, but I happened onto this thread 6 days later and figure there's not much to derail now--if you'll even read this reply). anyway, suggestion is to try and keep your voice at a more constant volume? :) you tend to trail off into a lower level (though not as bad to become inaudible) and then "yeelp" all the way back up at the start of the next sentence, which was occasionally a bit startling :) I was listening to it late at night on medium-large speakers so finding the right level was a bit of a gamble to not wake anyone :-P either way just a suggestion, maybe there was a reason for that particular presentation. do with it what you will ;-) and thanks for the interesting ideas on a very interesting topic! :)

by ibdknox 11y ago

david927 11y ago

Good luck, Chris! You're one of the few who understand the deep need to move forward, and in my humble opinion, you're on the right track.

ndarilek 11y ago

Here's a question for you, then. Has any thought been given to the accessibility story for Eve and tools like it? As a blind developer, I always get a bit nervous when the future of programming is discussed in terms I've read used to describe Eve. It seems like a very useful way of developing apps, but one that can easily exclude a subset of the population if a11y issues aren't thought through in advance. Also, part of me is tempted to dismiss Eve because I suspect we'll always have the current way of developing software to fall back on. But when I consider it more, I don't find that line of thinking productive for me. For instance, lots of folks might be tempted to dismiss GUIs for blind users because graphics, but there are actually huge advantages to representing UIs as trees of objects that can be introspected and interacted with. I can write code that scans the accessibility hierarchy for a specific element and reads it, for instance. In a command line interface, that code would need to either scan for a non-specific set of characters that a curses app might use to draw a thing that looks like a button and make a guess at its contents, and even then that logic would be very brittle. So even if Eve and whatever comes after derives lots of its power from rendering concepts visually, the underlying primitives needed to do so might have beneficial a11y implications and shouldn't be discounted because the end goal happens to look nicer than a wall of text. Anyway, would be nice to see that on the roadmap if it isn't already. Even if only 20% of programming is like this in 10 years, that's still a substantial subset that might exclude me by virtue of the accessibility story not being thought out first.

ibdknox 11y ago
Amusingly enough, I actually started thinking a bit about this just the other night after being told about a talk given at Dropbox about accessibility. To be up front, we know very little about it and the other night was the first time I'd ever tried to use a screen reader, so it's something we aren't likely to be good at right of the gate, but it is something we've been setting ourselves up for completely by accident. Many of the previous versions of Eve would be pretty completely inaccessible, so your dismissal would definitely be warranted. The version we've decided to run with though basically has three parts: a document editor, embedded spreadsheet cells, and a fancy plain english search. All three of which have a history of accessible solutions, so that makes me much more optimistic that we can provide something nice here. Along the way, another thing we've been very cognizant about is making sure no matter what form of input you prefer, Eve should be efficient and useful to you whether you're using a keyboard, a mouse, or touch. Many of the interaction issues we'd need to solve to better work with screen readers popup when trying to support complete keyboardability, but I have no delusion that there will be plenty more to solve there. Another interesting aspect of this version of Eve is it's really easy to imagine a voice interface to since virtually everything is done using plain english queries - it'd be kind of like having Jarvis in your google docs. Admittedly, we don't know what we're doing when it comes to accessibility, but it is something we've been thinking about indirectly and it's something I think we can at least do more naturally than the code editors of the world. Thanks for raising the issue and it's something I'd like to have a more concrete answer for in the future.
- ndarilek 11y ago
  Cool, glad to know this is on the radar! Out of curiosity, what are you using to render the current GUI? Toolkit/framework choice unfortunately has pretty significant a11y ramifications.
  - ibdknox 11y ago
    It's all HTML at the moment.

taco_emoji 11y ago

(FYI you mention "Lotus Impromptu" but I think you mean "Lotus Improv")

ibdknox 11y ago
whoops, yes I did. Fixed in the gist. Thanks!

viperscape 11y ago

I haven't kept up on Eve development as closely as I would have liked, but I do try to read each blog post which are usually very interesting. After tinkering with something like unreal's blue print visual graph programming, I am inclined to build something similar for Rust lang and game development. Have you considered this approach, I know visual programming hasn't been very successful on a general level but I think it excels at domain specific tasks. Last I checked Eve didn't implement graph nodes and connection widgets, did it ever? Have you considered it? Watching unreal editor run the blue print live and seeing nodes fire off really made me rethink debugging, like the next proper way instead of basic print statements. It also is impressive to see quick results to complex behaviors through wiring up nodes.

viperscape 11y ago
oh I see you have moved to a graph representation, terrific!
- cmontella 11y ago
  We used a graph editor for our last release in August, but since then we have taken a different direction.
jononor 11y ago
I don't think the graph part is the key thing: The ability to run a live program, question and explore it interactively is. Eve seems to be extremely strong in these aspects, especially the 'provenance' (knowing where data comes from) is beyond what existing systems provide. I say this as a developer of several graph/dataflow/visual programming tools (Flowhub/MicroFlo/Noflo and related).

isaiahg 11y ago

The presentation was very enlightening. If this was the future of business application programming I could see that or maybe even the future of programming websites. But as a game programmer I'm having trouble connecting it to my world. But it's titled as the future of programming, so I figure that would include me as well. What's interesting is the problems you want to address I deal with every day programming games. When you're making games you have to simulate physics in your head and the setup to just get a project ready is a gigantic pain. How could a game programmer use this type of system to make a game? It seems like the complexity would just get out of hand.

joshuafcole 11y ago
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.

tripzilch 11y ago

hey! you're the guy in the presentation video, correct? can I maybe give you an unsolicited but constructively-intended suggestion? (initially decided it was a bit too OT, but I happened onto this thread 6 days later and figure there's not much to derail now--if you'll even read this reply). anyway, suggestion is to try and keep your voice at a more constant volume? :) you tend to trail off into a lower level (though not as bad to become inaudible) and then "yeelp" all the way back up at the start of the next sentence, which was occasionally a bit startling :) I was listening to it late at night on medium-large speakers so finding the right level was a bit of a gamble to not wake anyone :-P either way just a suggestion, maybe there was a reason for that particular presentation. do with it what you will ;-) and thanks for the interesting ideas on a very interesting topic! :)