Hacker News Reader

And yet, people do get useful work done with spreadsheets. They build computer programs that solve problems for them. There are many programs that aren't feasible to write in a spreadsheet, but there are many useful ones that are.

I think success for this project looks more like a supercharged spreadsheet than a simplified programming language. There will be many programs that won't be feasible to write in it, but I think they could carve out an area wherein there are many useful programs that can be. If that area is large enough, that would be a big deal.

Doing powerful things with spreadsheets involves a similar amount of difficulty/learning as hacking some Python.

But doing simple things with spreadsheets is a hell of a lot easier than doing simple things with python. Learning curves are important because most people will never get to the powerful things if they get frustrated and give up on the simple things.

Actually, for me, doing simple things with Python is more intuitive than doing simple things with Excel.

You and I read hacker news. We are not normal. :)

Maybe, but try adding 2 numbers. In Python, I can just type 3 + 4 and hit Enter, in Excel, it's significantly less intuitive.

You type =3+4 instead. Surely an extra equal sign is not a big deal?

Programming languages tend to be geared toward coercing the user to abstract data into symbols. Spreadsheets are the other way around being more focused on keeping the data in front of your face as a table.

Data can be a complex thing to understand. By forcing data to be explicitly displayed in tables, users no longer need to "read source code" as just a casual glance at a chart or a table leads to significant comprehension about what's going on.

Maybe. But the key difference is that those who "program" spreadsheets can see all of the steps involved. The hardest part about programming is constructing and executing a model of the computation in your head. Spreadsheets help with exactly that, by making a 1-to-1 association between steps of the computation, and things in front of you.

> But the key difference is that those who "program" spreadsheets can see all of the steps involved.

I would say that that's almost precisely backwards: compared to typical plain-text code, spreadsheets make intermediate results more obvious, while obscuring the steps. (Things like, e.g., scala worksheets or ipython notebooks bridge this gap in a way which makes both the steps and the results clear.)

Yes, I'll agree with that. Users have to poke at the data cell to see what the formula is there - and it's easy to not do this, and be confused why the results are coming out wrong.

> There are many programs that aren't feasible to write in a spreadsheet

There are many programs that aren't feasible to write in a spreadsheet, and yet people have written them regardless.

In college, one course I took got groups of students to participate in a networked, multi-user business simulation that was written in Excel.

It was slow as hell, and Excel probably wasn't the best tool for the job, but it was probably just what the domain experts who created it were familiar with. Despite its lack of performance, it did its job admirably.

I think many people would be absolutely shocked at the size and scope of applications written in Excel using VBA. So in that respect, perhaps a supercharged spreadsheet would result in many more feasible applications than most of us, as developers, would first imagine.

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.

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.

> 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?

> 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.

> This seems to misunderstand fundamentally what it means to be a professional programmer. Knowing some programming language isn't it [...] learning languages and syntax is the trivial part of programming already

In order to get a job as a junior full stack web developer, you're going to need to know the following:

- HTML, CSS, Python/Ruby, Django/Rails, javascript, jQuery, SQL, Git, basic unix/linux

- Possibly Angular, design patterns, testing

Whereas in terms of CS questions you're likely to be asked, you're going to need to know:

- Basic data structures, algorithmic complexity, basic concurrency patterns

- Possibly some knowledge of common algorithms

Whereas all the programming stuff can easily take a year or more to learn, all the CS stuff you need to know to get a job as a professional developer is maybe a couple weekends worth of watching YouTube videos. I realize that CS knowledge sometimes becomes more important at higher levels depending on your career track, but I think you're underestimating the difficulty of learning the APIs versus learning the CS stuff as far as becoming a professional developer goes.

> its a mode of thinking and analysis

Right now, though, that thinking and analysis mostly comes with very little assistance from the computer. We are pleasantly surprised when a compiler manages to guess what we meant when we made a mistake.

I think there's a lot of room to help with the process of thinking rigorously. New models of programming could conceivably allow someone to start down the path of building, and then have an interaction with the programming environment in which it helps to find ambiguities or special cases.

I'm a terrible artist; I wouldn't try to make mockups if there weren't sites like Balsamiq. Even if I tried, they would be too rough to serve as any kind of spec. The right tools allow more (not all) people to succeed in trying their hand at design. Of course they will never be a "real designer", but hopefully they can accomplish more of their goals without help.

I think better programming tools and paradigms can have the same effect.

I'm a terrible artist; I wouldn't try to make mockups if there weren't sites like Balsamiq. Even if I tried, they would be too rough to serve as any kind of spec. The right tools allow more (not all) people to succeed in trying their hand at design. Of course they will never be a "real designer", but hopefully they can accomplish more of their goals without help.

This is a great analogy, but unfortunately I think it undermines your point somewhat.

Almost anyone can become a great artist or designer, but what it takes is practice, years of practice, and learning from others who have gone before and are working now. There are no short cuts and tools are really the least important element in any discipline, be that design or programming.

> Almost anyone can become a great artist or designer

I challenge this claim. I don't think just anyone can become a great artist or designer and if you think this I think you miss a great deal when it comes to evaluating these skills. Maybe anyone can become great at Photoshop and the other various tools, but if you don't find yourself enjoying designing, and you haven't had an artistic trait that others have recognized in you early on and you're not making much headway now, you probably want to find out what other talents you might have.

I think that if you enjoy designing you should pursue it. I think wanting to be good at something can lead to a high degree of skill because the motivation will drive you there. Not everyone has that motivation and so not everyone can be a great artist or designer. I think the same thing can be said of engineering. People who go into this field to get a 9-5 job and hate the work will struggle competing against people who love what they do and would do it even if they weren't paid for it.

I don't think just anyone can become a great artist or designer and if you think this I think you miss a great deal when it comes to evaluating these skills.

I'm a designer, trained as an artist ;) I do agree motivation is key though.

He is talking about "access to computation". No one is talking about making normal people into professional programmers.

Right, but I think he also has building websites in mind. So, both, I guess.

I'm fairly certainly that he has in mind the vision put forward in Prof. David Harel's late-career manifesto Can Programming be Liberated, Period? (2008)[1]

Five years earlier, Prof. Harel wrote a book, Come, Let's Play[2], in which he explored the role that temporal logic[3] could have in the building of reactive software systems (e.g. desktop GUI applications, among many others). If you visit Harel's full list of publications[4] and do an in-page search for the terms "LSC", "behavioral" and "scenario", you can follow the links to a number of papers published since the early 2000s, related to the application of temporal logic in the process of software design.

It's possible that my connection of Granger's "eve" to Harel's work is completely mistaken; and if so, I apologize for jumping the gun.

[1] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...

[2] http://www.wisdom.weizmann.ac.il/~playbook/

[3] http://en.wikipedia.org/wiki/Temporal_logic

[4] http://www.wisdom.weizmann.ac.il/~harel/papers.html

I'm not sure if it's an inspiration for Chris but it's definitely related since a key focus for Chris seems to be on building it on immutable data structures (and hence essentially temporal.)

We did read the manifesto and I'm fairly convinced that Harel's vision of interactive specification and refinement is the the long-term future of software. I'm not sure how to get there though, short of general AI. Eve aims to reduce the amount of specification required and can make sensible guesses about implementation, but it is not able to 'fill in the blanks' for partial specifications and we won't be focusing on that any time soon.

Thinking of programming as a dialogue with the computer is a really strong metaphor that I gladly recognize as something that inspired you [1][2].

Short: You provide the goals and the constraints, then through a back and forth dialogue with the computer you describe and clarify the problem (and also your understanding). You keep on negotiating and providing more constraints until it simply finds a possible solution (the problem domain is now computable) or the best fitting solution now satisfies your needs (in time).

The hardest parts are probably: 1. Collecting, developing the constraint solvers. Should we imagine that collection more as platform of user contributed (programmed/trained) packages? 2. Developing the dialouge that is not just textual but visual (in both ways) (notepad vs IDE vs Theater(?!) don't forget macros/acting out!)). Showing is always faster then writing and gives one better cues on the closures/framework of the actual discussion.

[1] http://scattered-thoughts.net/blog/2014/07/21/imperative-thi... [2] https://gist.github.com/jamii/8957881c8eaa4035f4ae

Seems very closely related to what I've been talking about / working on lately. Cool!

https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...

Prof. Rodney Brooks has always had a better more pragmatic take on this, coming from the robotics field no less:

http://en.m.wikipedia.org/wiki/Subsumption_architecture

http://en.m.wikipedia.org/wiki/Behavior-based_robotics

Kodu was based on this model, and it worked very well.

> No one is talking about making normal people into professional programmers.

Right, he's talking about replacing the need for professional programmers. And, in doing so, he focuses on not needing the guy that knows a particular language, rather than not needing the guy that can think through a structure a logical approach to solving the problem.

Its all pretty vague, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder (the supposed gap left by VB6 is specifically cited as the motivation) for the web, of which there are many existing now, all with similar pitches about letting "normal people" (or business experts) build line-of-business apps without hiring a professional programmer.

> And, in doing so, he focuses on not needing the guy that knows a particular language

That's a pretty narrow way of reading what I was saying. What I meant is the one guy who knows how to program and I just happened to pick Python because that's the common case in science. Do you really think a mathematician, biologist, or chemist can't think through a logical approach to solving a problem? I certainly believe they can, the problem is then in translating that to the computer. Right now, that would mean knowing (pick your programming language) and translating that logical solution. We want to make that way, way easier, to the point where it's like using the tools you already do to do this stuff (Excel).

> Its all pretty vaguem, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder

We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it. We're picking one domain to focus on because that's how you grow a product, but at the end of the day, if it doesn't suit my needs as well, I certainly can't call it a "better programming" in general.

> Do you really think a mathematician, biologist, or chemist can't think through a logical approach to solving a problem?

No, then again, I think that mathemeticians, biologists, and chemists now, with existing tools, often program computers to solve problems without being "professional programmers". (And not just with Excel and similar tools.)

> We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it.

I think all of that is significant, and I didn't intend to minimize that.

> We're picking one domain to focus on because that's how you grow a product

Insofar as I have concerns with the way the short-term focus is described, its that:

1) There isn't a clear description of what unique thing Eve intends to the table in that initial focal market, and

2) The initial focal market, as it has been described, seems quite crowded, rather than a gap that needs filled.

Perhaps an even more accurate approximation is "replacing the need for professional programmers for problems that shouldn't require professional programming"

A simple example of this is SQL. You shouldn't need to be a pro engineer to run some simple queries.

Another example is Mathematica. Scientists and engineers want to solve their domain problems, can learn a little bit of stuff, but shouldn't have to learn about build tools or d3 just to plot some data and solve some equations.

Whether Eve gets the balance right and is useful remains to be seen, but there is plenty of room at the bottom for empowering non-engineers.

>but learning languages and syntax is the trivial part of programming

I beg to differ. Some of the biggest frustrations are languages and syntax for people learning to program. For a professional programmer learning another language is like learning another car for a mechanic. They all look the same after a while. But trying to teach someone how an engine works is not trivial.

For someone to become a effective creator of programs today, they need to learn

- a style of analytical thinking and formal reasoning

- syntax and semantics of 1 or more programming languages

- interpreting the debug and error reporting capabilities of their environment

- version control

- text editing

- one or more build systems

- a mental model of computing machines and networks

Outside of academic environments you need to learn all of these thing simultaneously. If we can collapse away a few of these things with minimal loss of productivity we make programming much accessible.

> Knowing some programming language isn't it, its a mode of thinking and analysis.

You seem to be implying that we currently have tools that provide a suitably natural and frictionless medium for such thinking and analysis. But what if our current languages/tools are more like Roman numerals and there's still the computing version of Arabic numerals out there to be found?