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.
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.
> 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.
There is also much less stuff to disambiguate. The only names you ever refer to at the moment are tables. Most databases get by just fine with no namespacing at all.
As Jonathan Edwards says in his subtext work "names are too valuable to waste on talking to compilers." Making naming more of an interface concern rather than a part of the language is a great IDE and can greatly complement the way we use lots of search to write programs anyhow.
> Most databases get by just fine with no namespacing at all.
True, but most databases are very limited components of the program(s) that use them, which do use namespacing, not the complete platform for the program.
We also get to have arbitrary names rather than trying to stuff everything into single word. "People who disagree with me on the internet" is a valid name for an Eve table.
It's a valid name, albeit on that requires quoting, in pretty much any SQL based database, too. A lot of organizations have coding standards that prohibit names requiring quotes, and/or long names, but most databases support them just fine.
That said, I'm quite interested in getting a hold of eve.
> 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.