Hacker News Reader

> They want to make a better excel > They want to make a powerful, intuitive, database UI > They want to make a tool scientists can use to crunch and visualise data

These are basically all the same thing. Excel is generally used as a database / data cruncher. A relational DB with a similarly accessible learning curve could prevent many of the errors that riddle most spreadsheets. We add incrementally updated views to handle the data manipulation / crunching side (relatational aggregates are sufficiently expressive to handle most statistics / ML problems - http://db.cs.berkeley.edu/cs286/papers/bismarck-sigmod2012.p...).

> They want to make hypercard with modern programming languages backing it

Papers like https://github.com/papers-we-love/papers-we-love/blob/master... and http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf show how you can handle interactivity in a relational model. We have enough of this working that we bootstrapped the IDE.

> They want to make a tool for professional programmers to focus on the hard problems

Most of what I do as a professional programmer is not building abstractions or designing systems, but wrestling with incidental low-level detail, lack of visibility and tools that don't talk to each other. I've had enough experience with Eve to be convinced that I would be more productive.

> ... over-promising and under-delivering.

Obviously we are suffering from http://lesswrong.com/lw/kg/expecting_short_inferential_dista... since we have been thinking about this and working with it for months and all you have to go on is a few blog posts. I don't expect to convince you that we are right, but hopefully I can convince you that we have at least thought it through. We aren't trying to boil the ocean here - we are building a small set of tools that are applicable to lots of different problems. We've picked one problem to focus on for the first assault

Concerning the inferential distance... Wouldn't describing Eve as Smalltalk but based on immutable data structures with built in derivation (so that intermediate results don't consume space) get you much closer (for the programming crowd) than building on the spreadsheet analogy?

Eve has changed a great deal since Chris' original demo. It's much closer now to a spreadsheet or a relational database than to Smalltalk. All data lives in tables. Views are built using relational queries and update incrementally when data changes. IO is done by watchers that react to data arriving in certain tables. The only link to Smalltalk is the idea of running the program inside the development environment so the tools can all access live data.

OK. Good to know. But is the database itself still immutable then?

FWIW, I've mentioned in a few comments below that our first in-road here is just building websites. You can think of it as a replacement for VB6: something a normal person could use to draw out your application and then describe what happens when you interact with it.

The rest comes later, though we do believe it all flows out of a common model for programming in the same way that all of those things could come from any general purpose language.

So more like a better web-based hypercard then?

Will be great to see what you come up with, but I think the sales pitch here is overstating what you can reasonably achieve. Everyone has had dreams of revolutionising their discipline by inventing new tools, but it's very rare for tools alone to lead to a new paradigm.

Yeah, I think that's a fair way of thinking about it, especially since we drew a lot of inspiration from Hypercard itself.

> but it's very rare for tools alone to lead to a new paradigm

I think the distinction is that a tool helps you do something more efficiently while still generally thinking about the problem in the same way. What we're proposing is a very different way of thinking about the problem, which is what I think starts to define a paradigm. That being said, this is largely semantics and not a very valuable thing to argue about: paradigms come to be by the accident of use, so we'll find out when we launch and build a community around Eve.

> The range of problems it says they want to tackle is huge:

If they incorporate all that into one program, it will be (an unusable mess OR so damn complex that a small percentage of users will ever tackle it) AND it will quickly fall behind whatever bleeding edge they're wanting to stick to.

For evidence, I give you: Eclipse, the ultimate do-everything IDE. It's awesome until you realize how much unmaintained cruft there is in there. Which doesn't mean you can't get things done with it, but don't expect bleeding edge on a lot of things that started out that way.

What they're building is much closer to Smalltalk than to Eclipse though....

That seems likely to be true if the approach is to build separate features to achieve all of those goals. Looking at the research papers they've cited in this thread, however, I don't think that's where this is heading -- I'd say it looks more like Excel (which is already the current [figuratively, not specifically quantitatively] 80% solution for the first second and third items, and explicitly the thing addressed by the first) built on a better foundation that unites the existing strengths of the dataflow paradigm implicit in spreadsheets with a strong theoretical basis that unites it with relational + temporal data in a way which also greatly reduces the need to escape out to alternative programming models (e.g., in existing Excel, VBA etc.)

Its still a challenge -- getting the UI right especially -- but its not particularly hard to see from the cited research how a tool built on that foundation that could do what they are saying, with the only specialization to the separate goals being UI affordances rather than separate basic functionality.