[asolove]

You seem to conflate "allowing ambiguity" with "not requiring specification of extraneous detail."

It is not a new mistake. Many people thought that programming with GC, or with high-level languages, or with generics, was just a kind of magic that couldn't lead to understandable programs. But these things succeed because, while they allow you to stop worrying about certain details, they do so while still remaining perfectly well-defined and unambiguous.

The fact that you no longer can know how the low-level details will be handled can be very uncomfortable. If there is most of what you have spent your programming career doing, it seems like it must produce ambiguity and inefficiency. But this isn't generally the case. Optimizing OCaml compilers can often produce code faster than C simply because the higher level of expression expected from the programmer leaves more room for the implementation to generate the right low-level code.

I won't say that I know Eve will be successful, but it certainly is possible. It produces unambiguous behavior which just happens to no longer specify lots of details most programming environments make you think about. When I think about the work I do, most of which involves providing live representations of data, and executing certain rules when it changes, I would guess that most of the details I worry about are extraneous and could be dealt with by a sufficiently-smart environment that encompassed both the database and the program.

[marshray]

I would say that GC, generics, and maybe even HLLs are useful because they are tools to constrain the set of possible states the program can possibly enter.

When your language and runtime provide good tooling for constraining the state space, then that allows you to elide specification of those extraneous details.

E.g., some form of GC is a basic runtime requirement for most of the HLLs today. They could almost not exist without it.

[asolove]

Absolutely agree. Similarly, I think we are finding that if you want to program reasonably on distributed hardware or over state spaces too large to hold in memory, you need a programming environment that constrains your ability to specify that things happen in sequential order, or to specify details about how you listen for events or get access to data directly.

Eve may not turn out to be the right abstraction away from details. But the parent comment complaining about the details it takes away from the programmer is probably on the wrong side of history.

[noonespecial]

I'd say that the details still exist but they've been handled with a very powerful idea which is sane defaults triumphing over endless required specification. In most cases you still can reach the minutia, you just usually don't need to.

There's a difference between producing unambiguous behavior given a specific input and making it easy to create that input in the first place.

I'm with you along the lines of embedding defaults to reduce the boilerplate code needed to get a minimum working app, but there comes a point where this may end up requiring advanced coders to learn how to go deeper in order to override those defaults to get novel results. This could result in a language thats easy for a beginner to get started in but difficult for the intermediate to progress any further.

[asolove]

That sounds like a good description of operating systems, programming languages, databases, or any of dozens of other abstractions that work great, enable people to use them as black boxes without worrying about the details, and also are rewarding to customize or hack on internally for the small subset so inclined.

If that's what this is, a new field outside "programming" that allows an order of magnitude more people to author behavior for simple systems, that'd be amazing.