To me it sounds actually they perfectly understand what it means to be professional programmer and, most significantly, not everyone needs to be a professional programmer to provide added value through simple programs. A better Excel sounds just about right for a metric ton of practical applications for automating the work loads of professionals everywhere.
Working on Eve so far has been an incredible challenge that has taken us through everything from language design and query optimisation to high-dimensional geometry and cognitive science...how do you invite a billion people to program without them ever knowing about it? We're not sure yet, but we know finding out will certainly be fun.
I think what worries me about the hyperbole on this linked page is that it implies all problems software solves are fundamentally similar (they're not), or that all software shares certain fundamentals (it does of course, but at such a low level they are hard to abstract). The range of problems it says they want to tackle is huge:
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
They want to make a game programming language for kids
They want to make hypercard with modern programming languages backing it
They want to make a tool for professional programmers to focus on the hard problems
Any one of those is an admirable and difficult goal - trying to make all of those things at once is a good recipe for starting something and never finishing it.
That's not a reason not to try to improve programming practice with something radically better, but I think they'd be far better to pull a Buchheit here and focus on one small set of customers and make them very happy, instead of over-promising and under-delivering.
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.
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.
> 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
> 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.
> 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.
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.
