
A Visual History of Eve: 2014 - 2018 - stevekrouse
http://futureofcoding.org/essays/eve/
======
jng
My view of this is: all of us who have written a lot of code feel intuitively
there is something wrong with how coding is done. It feels like we are
repeating too much work every time, reinventing the wheel for the umpteenth
time. It feels like the tools and notations we have are missing something
fundamental and thus forcing extra menial work that is not essentially
necessary. Eve was one of the multiple attempts at converting that intuition
in actual knowledge and in an actual product. They weren't able to do it, same
as Intentional Software and others before them, but they explored uncharted
territory using that intuition, and that is an interesting exploration. Kudos
to them for trying. And hopefully someone will find the underlying core
concepts we're missing to make that leap into future programming!

~~~
chubot
FWIW I agree that something feels wrong and repetitive, but I don't think Eve
addressed my problem at all.

A big part of my pain, and the pain I've observed in 15 years of industry, is
programming language silos. Too much time is spent on "How do I do X in
language Y?" rather than just "How do I do X?"

For example, people want a web socket server, or a syntax highlighting
library, in pure Python, or Go, or JavaScript, etc. It's repetitive and
drastically increases the amount of code that has to be maintained, and
reduces the overall quality of each solution (e.g. think e-mail parsers, video
codecs, spam filters, information retrieval libraries, etc.).

There's this tendency of languages to want to be the be-all end-all, i.e. to
pretend that they are at the center of the universe. Instead, they should
focus on interoperating with other languages (as in the Unix philosophy).

Some languages want to be their own operating system, but empirically that
doesn't work. The JVM had this explicit goal of "making Windows irrelevant",
but instead it ended up as just another process on a Unix system!!!

(Something like Mirage in OCaml is an extreme example of this, although I
think it's a pretty interesting project.)

This only really comes up after you become at least an "intermediate
programmer". When I started, I wanted everything to be in my favorite language
so it would be easy for me to understand and modify. But now I realize that
it's more efficient to be able to reuse the best tool for the job PERIOD, not
the best tool for the job in language X.

Microsoft actually had some degree of success with this with COM. You can do a
surprising amount of automation from JavaScript or Visual BASIC in much the
same way. But IMO the "language cacophony" situation is worse on the server
side, even though to some extent the problem is easier because you have more
computing resources.

In this regard, Eve actually makes things worse! I say that every new language
makes things locally better, but globally worse. Because you never have a
system in just one language. If you think you do, then your view fo the system
is too narrow.

I'm chipping away at the edges of this problem with
[http://www.oilshell.org/](http://www.oilshell.org/), but honestly it's not
close... I chose to replicate the Unix shell first -- a big success story,
though one with many flaws -- and then maybe many years from now, extend it
with a form of integration tighter than bytes over pipes.

~~~
nickpsecurity
Definitely more interoperability to get best tool for the job and leverage
ecosystems. I'm with you on that. On this...

"they should focus on interoperating with other languages (as in the Unix
philosophy)."

Maybe instead follow the _OpenVMS philosophy_ where they standardized the
calling conventions to support multi-language development.

[http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#int...](http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#intro_32)

Microsoft's CLR followed that path in the VM space. Got similarly good
results. Tools like Racket and mbase do with DSL's where they share underlying
LISP-like language to avoid problems with DSL's own weaknesses.

~~~
pjmlp
Actually on Windows we have come full circle as those CLR ideas, which were
originally thought for COM Runtime, have been brought back into COM as UWP.

IBM mainframes also follow the multi-language environment philosophy.

------
munificent
Most successful languages were initially created for a very specific target. C
-> UNIX OS. C++ -> network simulations. PHP -> Rasmus's homepage. JS ->
interactive web pages. C# -> WinForms apps.

From scrolling through that list of prototypes, which are all over the place,
it looks like they couldn't decide what language to make because they didn't
know what they were making it for. I think there's a real lesson here in being
_specific_ with your product at first and then generalizing later. It's very
hard to be all things to all people from day one.

~~~
FPGAhacker
The whole thing was an exploration into the unknown. It was a discovery
process.

~~~
msangi
In such case having a specific use case in mind could be actually helpful.

It's much easier to explore the unknown if at least you know what you'd like
to find instead than just wandering without a clear destination and hope to
somehow stumble upon it

------
nnq
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.

~~~
cmontella
> 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.

This of course was never fully realized.

------
acobster
> _Thanks to the Eve team: Chris Granger, Corey Montella, Josh Cole, and Jamie
> Brandon. You were an inspiration._

And I hope they continue to be! The ideas that Eve made concrete are too good
not to carry forward in the design of future languages. It wasn't just the
literate/logical programming paradigms, atypical of popular languages in
production today, that made Even stand out: it was the idea (really, the sort
of moral imperative) that as you make changes to the code, you should be able
to see the effects of those changes _in real time._

It's worth pointing out that Light Table, sort of the precursor to Eve, was
pretty much directly inspired by Bret Victor's talk "Inventing on Principle."
[0] I'd encourage anyone who hasn't seen Bret's work to go check out that, and
all his talks really. :)

[0] [https://vimeo.com/36579366](https://vimeo.com/36579366)

~~~
ModernMech
I should note that Eric Hoffman also was part of the team for a year.

~~~
cmontella
Don't forget Rob Attorri! He wasn't an engineer, but he was there from day one
(cofounded with Chris)!

~~~
stevekrouse
Added, thanks!

------
barryp
I thought this was going to be some kind of April Fool's thing where it went
from spreadsheets and tables and eventually ended up with space combat.

That screenshot in the middle with the moon had me going for a second.

------
Glench
It's neat seeing all the prototypes in one place. It looks like the team was
trying to find what the product wanted to be. Is it a spreadsheet? Is it a
wiki? A database? A web application maker? A REPL? A literate IDE? Some
combination of all these things?

It seems like the team never was able to close the loop on the human outcomes
of what their product was supposed to enable.

~~~
cmontella
From an outside perspective this seems rather random, but we were really
methodically exploring a design space. We incorporated different ideas from
each IDE into the next. For a long time we were working on the IDE and
semantics of the language at the same time, which was really holding us back.
Eventually we separated those concerns, and refined the programming model in
v0.2. But in each iteration of the language, there was something missing,
causing us to try a new angle, or to throw out old assumptions.

> 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.

~~~
undecidabot
Are you planning write a postmortem on this project? I really hope you do. I'm
sure you have plenty of insights to share that would be super helpful for
other people exploring this space.

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!

~~~
cmontella
> Are you planning write a postmortem on this project?

Chris has a keynote at splashcon 2018 about this:
[https://2018.splashcon.org/event/splash-2018-keynotes-
agains...](https://2018.splashcon.org/event/splash-2018-keynotes-against-the-
current-what-we-learned-from-eve)

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.

------
smoyer
This progression is impressive and the examples are visually stunning but I'm
a bit concerned about how much the mouse is being used. When there's too many
panels, fields and values on the screen, how do you keep your hands on the
keyboard?

In the IDEs that I've tried, I find them impossible to use if there aren't
keyboard shortcuts for everything. As an extreme example, take a look at Eclim
which merges the functionality of the Eclipse code engine with the GUI of vi -
[http://eclim.org/index.html](http://eclim.org/index.html) (note that I don't
use this as my daily editor - I'm not proficient enough yet or perhaps it's
just a bit too extreme).

~~~
joshuafcole
Actually, several of those editors were explorations of what programming would
look like using _just_ the mouse. The mouse isn't really the issue with
programming performance, per se -- instead the problem is the constant context
switching back and forth.

Several version focused on _just_ the keyboard, but we found that most of the
things we built using Eve were inherently visual, and as such needed to be
tested and interacted with using the mouse. Since we can't eliminate that
context shift, we tried doubling down on it.

As a die hard Emacs user, I was shocked by just how competitive the mouse
could be in the smalltalk-esque environment we built.

~~~
joshuafcole
I noticed I had a video of the "calculator" interface we designed to try and
make mouse/touch-only interaction possible. I've made it public for anyone
interested.

[https://www.youtube.com/watch?v=BT8shMtBZsY](https://www.youtube.com/watch?v=BT8shMtBZsY)

EDIT: Fixed the link

~~~
seanmcdirmid
Your link is broken, I think you accidentally linked to the upload page.

~~~
joshuafcole
Ah, thanks for the tip. Fixed now.

------
gradys
Since a number of people who worked on Eve are watching the thread: what's
next for you? What do you feel like you learned about human-computer
interaction? What are you going to bring to your future work on these kinds of
ideas?

~~~
cmontella
I left a PhD program to join Eve, so I'm going to finish that and join
academia to continue this research. I'm working to bring some of the ideas I
learned from working on Eve into my own project called HiveMind, which in an
OS written in Rust and an Eve-like language I call Mech:
[https://gitlab.com/cmontella/hivemind](https://gitlab.com/cmontella/hivemind)
You can think of it like baremetal Eve.

------
VectorLock
I know a lot of people suggest there is a market for a programming language /
Excel hybrid and it looked like some of these prototypes at least partially
leaned in that direction.

What would be the most successful new development that Eve discovered? What is
the best part of this that we can take away?

------
superkuh
I'm probably not the only one that went in thinking this was going to be about
Eve (the game). When I saw the spreadsheets and visualizations it only further
confirmed this. It took me about half the page before I realized this was
something else entirely I'd never heard of.

~~~
ribs
Nope, not the only one ;-)

------
joshmarinacci
Oh, man. I was really hoping Eve would be successful.

