It seems like the team never was able to close the loop on the human outcomes of what their product was supposed to enable.
> It seems like the team never was able to close the loop on the human outcomes of what their product was supposed to enable.
What we really wanted from Eve was to define programming in a way that didn't feel like programming. We got close to this feeling in FiveSquare Eve and WikiEve. Smalltalk Eve (that's not what we called it, but what the article calls it) was probably the closest we got to this ideal, but unfortunately we didn't have enough runway to flesh it out.
I disagree, because think ≠ know. Now, usually that's an issue we talk about when the creator thinks what they have is right, but it's just as true and relevant when they think it's wrong. You can both be wrong about it being wrong and, perhaps more often, be wrong about how it's wrong. Without some interaction with the target market, you lose feedback and course correction.
If you think X is wrong, there is just a super high probability that X is wrong without going through users.
Yes, you should interact with the target market, but good designers must have great crap filters. The crap you filter out is not going to somehow magically come up smelling roses with users.
Maybe you are suggesting design by focus group?
In five square you worked with tables, and programming felt like exploring a database. You just created different tables of data and then filtered and joined them in a graphical way, then bound the result to an interface. In the end, we had a working fivesquare clone without writing a line of code, that could be built in a day or two from scratch.
In Wikieve, data was presented as card, or wiki pages that you could edit. With some clever tweaks, you could ge a working program out of this, but it felt more like managing a wiki.
Smalltalk Eve was more geared toward graphical applications, so a lot of neat things could be accomplished just by adding simple actions to objects on the screen. I had built a kinect application that allowed you to steer the wheels of a robot car using your hands, again without coding anything.
So direct manipulation of code and the ability to see your results immediately, and to progressively change them are the properties that made these versions good.
Many of us here would really love to read up on the ideas behind each iteration, the specifics on what went well, what didn't go as expected, the target market and their feedback. It doesn't need to be a fancy paper, even a short but detailed bullet list for each iteration would be fine.
From my outsider perspective, it seems like you were trying to build a "silver bullet". For example, both FiveSquare Eve and WikiEve look promising. FiveSquare could be a great WYSIWYG website/app builder. WikiEve could be a great note taking tool. Just because they aren't the future of programming, doesn't mean they aren't useful!
Chris has a keynote at splashcon 2018 about this: https://2018.splashcon.org/event/splash-2018-keynotes-agains...
I'm trying to pen some of my thoughts as well, but it's taken a long time to try and distill some of these things into something comprehensible. Sometimes I don't even understand why we did some things :P
> From my outsider perspective, it seems like you were trying to build a "silver bullet". For example, both FiveSquare Eve and WikiEve look promising. FiveSquare could be a great WYSIWYG website/app builder. WikiEve could be a great note taking tool. Just because they aren't the future of programming, doesn't mean they aren't useful!
I think you're right about that. I think several times we could have taken a prototype Eve and made it a product people would have paid money to use. Many people said "Why don't you just make relational excel, that would go a long way to being a good useful product" and we basically did that in Grid Eve.
But every time we were tempted to monetize some artifact of Eve and call it a business, we had to remind ourselves that what we had didn't really address the original problem: programming needs to be easier. And this was the right move, because if we had stopped at WikiEve or Grid Eve or whatever version and iterated on it until it was a product, then we would have missed out on learning a lot more.
It seems more likely to me that once you get far enough down any of those roads, the complexity of programming reappears. Now you have to decide whether you chose the wrong road or whether complexity is an unavoidable feature of programming. It looks to me like the Eve folks kept thinking they might find a twist that would avoid it.
I'm impressed at how many ideas they tried. But I can't help but feel that they were never in one place long enough to really build something lasting. Every time I looked at Eve, it was totally different (and looked promising) but when things change that much, that quickly, it's hard to lay down roots.
From my own research, I have a sense there's promise in domain-specific modeling with hooks into more general purpose languages. Bret Victor talks about making languages for people other than software developers or "end users" here:
There is a great deal of essential complexity. Programmers deal with corner-cases more often than most other people, and having an eye for a "good" solution to a problem in a programming language or in a spreadsheet or whatever is a specific skill that takes some learning.
On the other hand, programming is just not very approachable, and I don't think that's because of essential complexity. A "good" Excel user -- someone who can use the string functions, vlookup and maybe those "array formulas" -- is basically a programmer, and every step between that and your cousin who uses Excel to write shopping lists is just "Oh, let me show you this one trick."
Get your cousin to write a CRUD shopping list site or app in any programming environment, though? Not a chance.
Maybe AirTable counts as a relational model. There's a useful gradient there. You can start with shopping lists and end with foreign keys, maybe. Not a huge scope for logic, but you can do some pretty cool things in SQL with "this one trick". I wouldn't want to stop at tricking people into learning SQL, though. I think a nice easy ramp up to a Turing complete language is possible.
You don't have to make programming easy, though. Most people will not be programmers. Making "just a bit more programming" easy is a huge win, though.