Eve's whole focus on "observability" of code and data seems kind of overwhelming imo...
I mean, the 2 most successful paradigms for "full-strength" interaction with computers are (1) code in general purpose programming languages and (2) spreadsheets. And they both have one thing in common: only code or only data is visible most of the time (or by default)! I think this is for one simple reason: that's all our monkey brains can take, we only want a small narrow window into one of these 2 domains, and we can barely handle that. We don't really want to "see the data flow" or "the code behind the cells", we want things hidden away 99% of the time, and we want to be spared from the paralyzing effect of endless choice that allowing us to interact with everything would cause.
I think the problems people would most appreciate solving are instead:
(1) how to switch between code-first and data-first mode in the same tool
(2) how to build a successful repository/marketplace of good enough "components" usable in your tool (and "NPM of Excell plugins" but for your tool)
I think people mostly fall clearly into two camps: either completely overwhelmed by their current tools already, anything even slightly more complex and their "brain would explode", or they just want full power for their technical task (so they'll use something semi-domain-specific like Jupyter notebook). I think "designing for humans" should be based or deisngning for limitations, for neuroticism and for somewhat illogical/irrational behavior ...that's what best describes human users and that's what Excell got brilliantly right. You can be resentfully angry, lazy, overwhelmed and ADHDed, all at the same time, in one of the worse days of your life, and you'll still get something done with Excell.
> And they both have one thing in common: only code or only data is visible most of the time (or by default)!
This is true, but one of the the biggest source of errors in spreadsheets arises from the inability to see code, and one of the biggest source of errors in regular code is the inability to see and record the data flow.
In Eve, technically you still could only interact with data, because code was treated as data too. We still had a lot of work to do in figuring out an interface for working with programs built in this manner.
> we want things hidden away 99% of the time, and we want to be spared from the paralyzing effect of endless choice that allowing us to interact with everything would cause.
I agree with you here, and this is one of the things we kept in mind when designing and building Eve. We likened it to having lego parts bucket on the floor. Sure, everything you need is right there, but the vast design space available to you limits your ability to work. But what if we could show you only the parts that were applicable at the current time. Or show you only the parts that would fit a certain spot. We could do this with Eve, because we kept information the compilers throw away and made it available (and added to it) during program execution.
I mean, the 2 most successful paradigms for "full-strength" interaction with computers are (1) code in general purpose programming languages and (2) spreadsheets. And they both have one thing in common: only code or only data is visible most of the time (or by default)! I think this is for one simple reason: that's all our monkey brains can take, we only want a small narrow window into one of these 2 domains, and we can barely handle that. We don't really want to "see the data flow" or "the code behind the cells", we want things hidden away 99% of the time, and we want to be spared from the paralyzing effect of endless choice that allowing us to interact with everything would cause.
I think the problems people would most appreciate solving are instead:
(1) how to switch between code-first and data-first mode in the same tool
(2) how to build a successful repository/marketplace of good enough "components" usable in your tool (and "NPM of Excell plugins" but for your tool)
I think people mostly fall clearly into two camps: either completely overwhelmed by their current tools already, anything even slightly more complex and their "brain would explode", or they just want full power for their technical task (so they'll use something semi-domain-specific like Jupyter notebook). I think "designing for humans" should be based or deisngning for limitations, for neuroticism and for somewhat illogical/irrational behavior ...that's what best describes human users and that's what Excell got brilliantly right. You can be resentfully angry, lazy, overwhelmed and ADHDed, all at the same time, in one of the worse days of your life, and you'll still get something done with Excell.