Eve: Programming designed for humans

It seems like you are aiming for two main things at once, 1) to create a "literate programming" environment (document structure, real-time visualization, etc) and (in service of that?) to use this "world as data" model. As a non-expert programmer, I have to say I don't quite understand the implications of the search/bind/commit approach, specifically whether it was necessary in order to implement the features of the environment that make it human-friendly, or whether you consider it to be, in itself, a human-friendly approach.

My feeling is that the language itself is not really any more human-friendly than any other. You say in the "what Eve isn't" section that it's not for non-programmers-- but if the environment and language were both truly human-friendly, one benchmark of that would likely be a lower barrier to entry for non-programmers.

That said, again as a non-expert programmer, I see massive value particularly in the "document" approach-- though I see it less as human-friendly, and more as human(s)-friendly. Most of my programming experience has been as a graduate student, either scientific programming or (small) app and website development, and it is often the case that code is passed down in time from person to person. Each time you get someone else's project you initially have to rely on code organization conventions, file names and comments to figure out how the program really fits together, before you can even start working with it (and the tendency, for small-ish projects, is to want to avoid this work and just rewrite it yourself). The code-as-document approach seems wildly better for these particular use cases. I want to echo king_magic's comment, that if a wiki-like overlay could be used on top of an arbitrary codebase, it would go a long way toward human(s)-friendly programming, and I'd use the heck out of it.

So my immediate thoughts are this looks very nice for designing websites with. It does look like the ideas all rely on a static webpage though (not many moving parts). As I understand it, your page is built with a set of tagged content in a DB, and then further queries can access data via those tags. You've fit together a DB + real time feedback + visualisations in an appealing way that actual makes creating webpages look fun. Something that is otherwise a terribly monotonous task in the current JavaScript climate.

I wonder how well these ideas work as you ramp up to complex algorithms though. For example 5 nested for loops with 10 000 records of data would likely choke your visualisation to death. Also often the decision of choosing your data structures (list vs hash table vs concurrent queue vs ...) are paramount to the performance of the application. A single DB I can't imagine always being the best approach, but one idea could be to measure the data frequency passing though and optimise for the best structure perhaps? Similar to how SQL operates at the moment.

The idea of splitting functionality up into blocks is interesting, though I think you are focusing too much on the literate side of things. I think I would just keep the English text to a minimum, only explaining the 'why' and let the code explain the 'what/how'. But forgetting that, the block separation idea is nice enough on it's own, especially with the table of contents.

I've not looked very in-depth at the language, but what you did in the video did seem a bit like magic at times, and the simplicity seemed to hint at a lot of code hidden away behind simple looking APIs. Meaning doing anything out of the norm would find yourself having to roll a lot of your own code, but I could be assuming wrongly here so won't dwell on it.

I did notice that there was no autocomplete popups in the video. Does this mean you've forgone a type system of any sort? I would hope not as TypeScript has shown the productivity hike adding a few simple type annotations can give. Fully 'dynamic' code bases tend to be nightmares after a certain LOC threshold.

All in all congrats for giving a new outlook on programming by combining a set of old ideas in a new streamlined way, and giving HN something else to grumble about for a while!

"designed for humans"

what

We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.