Eve: Programming designed for humans

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.

I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not rely blindly on either the implementation or the specification being correct, but instead check them both.

People have to call a function, using its name. The function name is the mental-model handle you have on the function. If the name is a bad representation of what the function does, then the function probably just won't ever get called, because nobody will be able to build a mental model of it.

Indeed, someone else will probably end up duplicating the effort of writing the same function over again—but with an accurate name this time—because they aren't aware that the functionality they want exists in the codebase already.

And this is all an implicit consideration made by every programmer, every time they define—or later modify—a function. We all know that we'll "lose track of" functions if we don't call them something memorable for their purpose. So we put thought into naming functions, and put effort into renaming functions when they change. (Or, with library code, to copy-pasting functions to create new names for the new variant of the functionality; and then factoring out the commonalities into even more functions. We go to that effort because the alternative—a misnamed function—is almost effectively beyond contemplation.)

I think what they mean by "human" is non-professional.

All programming tools are for humans. But they're also almost exclusively designed with the expectation that the user will be able to devote afternoons, weeks, months, years to learning the tool. That's a fair expectation if your target audience is programming professionals... If it's your job, you can amortize those learning costs over some months of paychecks.

But that a) creates a high barrier to entry for people to get into the biz. And b) mostly locks out people who want to do just a little programming. I.e. the Excel crowd.

The field Eve is in, so called "end-user programming" is still trying to advance beyond spreadsheets, which were the last big win for non-(professional programmers). Well, HTML was probably in there too. WordPress templates, etc. But spreadsheets were probably the last quantum leap in the field.

We're overdue for another.

I think there's one kind of "specification language" that works completely unlike programming itself—and that's the interactive form of specification known as requirements-gathering that occurs in the conversation between a contract programmer and their client.

I could see potential in a function-level spec in the form of an append-only transcript, where only one line can be added at a time. So you (with your requirements-specifier hat on) write a line of spec; and then you (as the programmer) write a function that only does what the spec says, in the stupidest way possible; and then you put on the other hat and add another line to the spec to constrain yourself from doing things so stupidly; and on and on. The same sort of granularity as happens when doing TDD by creating unit tests that fail; but these "tests" don't need to execute, human eyes just need to check the function against them.

---

On another tangent: I've never seen anyone just "bite the bullet" on this, acknowledge that what they want is redundant effort, and explicitly design a programming language that forces you to program everything twice in two separate ways. It seems to me that it'd actually be a useful thing to have around, especially if it enforced two very different programming paradigms for the two formalisms—one functional and one procedural, say; or one dataflow-oriented ala APL or J, and the other actor-modelled ala Erlang.

Seems like something NASA would want to use for high-assurance systems, come to think of it. They get part-way there by making several teams write several isolated implementations of their high-assurance code—but it will likely end up having the same flaws in the same places, given that there's nothing forcing them to use separate abstractions.