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!
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/, 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.
It was important for us to treat Eve (at least initially) as the whole world, because part of our task was understanding the implications of building programs in this different fashion. Datalog applications have a rich design space for tooling, and after 3 years poking around in the space we barely scratched the surface. The interoperability between a datalog world and the current state of things is another great research question, and one we made some good progress on this front with v0.4, but there was still much left to do in the end.
Has there been any discussion about open-sourcing Eve? It's a shame to see the project abandoned without at least making it available for other people to try to maintain. It may not find the right set of maintainers, but if the project shuts down without putting the code out there, it will definitely die in darkness.
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.
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.
> 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?"
Basically it’s right nit to make everything a nail just because you‘ve got a hammer.
But also, if you only got a hammer and no/limited ways to get another tool, the question is very well „how can i build a table with just nails“ even though i know with screws it might be easier.
If you have a limited amount of developers with limited pre-existing knowledge in languages it’s not so unwise to look for solutions inside the language range of your team.
If only one person knows the language one of your components is made in, the risk of becoming unable to maintain that thing is pretty high.
Also, If you have only one developer, it’s pretty wise to try to limit the use of languages to those he is very proficient in - and that might be one or two, maybe three - and avoid context switching for syntax and core library functionality.
As a counterpoint, this "being interoperable with everything" mindset is predominant. Everyone has an interop story, some languages are all about interop (Lua, before Python).
The worse case scenario shows up in Verner Vinge's scifi as the programmer archeologist (see https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky), that all the code that could have been written has been written, and programmers of the future will be more like archeologists sniffing it out.
In that future, there is no room for green fields, which I find to be very depressing.
Shouldn't line of business software naturally trend from being a creative pursuit to a standard engineering or trade, where defined systems are applied to a semi-novel problem using known patterns and rules? Rediscovering the whole thing every time is certainly inefficient.
I think there will always be room for green fields, though. Even in very old fields scientists and inventors still discover new approaches and solve new problems on a daily basis. Yes, this will move to the fringes, but is that a bad thing? I'd rather spend 10% of my time on research and reimplementation and 90% on a Fun New Problem/Approach rather than 90% of my time reinventing the wheel and 10% of my time on new stuff.
I'm pretty sure ML eventually eats the programming cake, though it might not be in our lifetimes. Definitely by the time we have developed FTL travel.
We have reached a very pronounced local maxima with our current programming practices and ecosystems. Reinvention can get us out of that, though is more likely to fail than not.
Strongly agreed. I've had a fairly long career and worked in dozens of languages. Languages like Crystal (staticly typed, but with strong type inference that makes them feel like a dynamic language) feel like they're from 10 years in the future. Using languages from the ML-family (OCaml, F#, Haskell, Purescript, Elm, Idris, Agda) makes me feel like I've gone 25 years into the future and been set down in front of a computer. Especially watching Idris write my program for me just based on the type signatures. That blows my mind every time it works (which it often does).
Well, you can take it too far for sure, but I don't think we're even close. I disagree with most of what you wrote:
- There will still be green fields because there are new problems to solve. New languages (and new platforms) are justified for new problems. For example, you will have languages for machine learning, for quantum computing, for computing with security, etc. Microsoft has an interesting P state machine language which adds something new.
I would love to free up some of my brain real estate learn those new domains / languages, rather than doing the same thing over and over again in different languages.
Although as I understand Eve was a Datalog, and I think that adds something "new". Although making that Datalog interoperate may have been more successful than building a cohesive platform around it (but perhaps contrary to their goals).
- "the being interoperable mindset if predominant". I don't agree, e.g. every language has its own package ecosystem. They interoperate (poorly) with C, but not any other language really. The JVM ecosystem is more or less completely distinct than the Go one, although they cover a similar problem space. Likewise for say Rust and Go.
- Python's interop story is not great; it is littered with implementation details, There are 10+ wrappers like SWIG, CFFI, ctypes, CLIF, etc. on top of the Python/C API because it's so prickly. Alternative implementations like PyPy don't get much adoption; there is version lock-in with Python 2 vs. 3. Python 2 vs. 3 is a great example of where beginners get stuck in mind-numbing detail and complexity.
- Lua was designed with good C interop, but not that's about it too. If anything, it's the exception that proves the rule. It's not a very popular language either, at least 10x less popular than Python, Ruby, JS, etc.
So if you agree that much of programming is doing the same thing over and over again in different languages, then it follows that adding new languages doesn't help that. It might help beginners, but it doesn't make things better for working programmers, who write most of the code in the world.
I understand that for beginners, you want a coherent experience. Beginners can't learn two languages at once -- that's a very good argument. But I do think there is an economic problem with trying to make a single "cohesive platform" to solve all those problems. Beginners can imagine something that is logically 10 or 20 lines, that will take you 100K lines, 1M, or 10M lines of code to implement on the back end.
I think that is the problem Eve ran into -- it's simply too much work to try to interpret extremely high level programs at the level of the user's intention.
For example I just wrote a 20-line piece of JavaScript on Google App Scripts, embedded in a spreadsheet, that sends e-mails. It was a surprisingly good experience -- I had low expectations. But I bet there's at least 1M lines of code in the background to make this all work (probably more, having worked at Google), and there's a whole team of SREs, etc. Some of the code in there is 10-15 years old, etc. It's a huge job.
In other words, I think Eve was a full-fledged platform, and platforms have problems getting off the ground without a billion dollars. Even if your platform is backed by a big company, it might be hard to gain traction. Google App Engine provided a lot of value and a nice experience, enough that Snapchat was built on it, but I think it faltered in the limited availability of runtimes (it couldn't run PHP for a long time, etc.) In other words it didn't interoperate with the rest of the world enough, and I imagine Eve interoperated even less.
I'm curious what you folks think of things like Racket and it's ability to create DSLs for various problem spaces. This seems like it would let you stay in one language yet have the flexibility to still create the right tool for specific jobs.
The same goes with the abilities of its macros too. Does that give you the ability to define what you want and have the language create the code for you?
Caveat, I'm new to programming and just now learning Racket so it has me all excited but I barely know what I'm talking about. This thread has been very interesting to read so I'm curious what others think of languages which have the flexibility to adapt. Maybe it creates a maintenance or understanding other people's code nightmare or something. I'm just curious why Racket's approach or something like it hasn't taken off.
I don't have much experience with Racket, but I've read a lot of the papers. I think they're exploring exactly the right problems.
I'm not convinced Lisp is the best substrate for it. It makes more choices than you think (number representations, etc.) -- it's not completely neutral.
S-expressions turn out not to be the lowest common denominator -- strings are! "Everything is a file" in Unix means that everything is a big lump of bytes -- e.g. as opposed to the early Mac file systems which had metadata too.
The web is very much an extension of the Unix philosophy -- composing languages, ad hoc string manipulation, etc. with HTML/JS/CSS and dozens of other DSLs. Of course, this architecture has a lot of downsides, and that's what I'm working on in Oil.
-----
Other anecdotes:
There's a research shell called "Shill" built on top of Racket. I heard that they moved off of it for some reasons related to Racket's runtime.
Also, I heard that Racket is thinking of replacing their runtime with Chez Scheme (which is one of the more impressive Scheme runtimes as I understand, being in industrial use for 20+ years.)
So I think that Racket is good within its own world, its own runtime, but weaker when it has to interoperate with the rest of the world. Unix and the web are the rest of the world... and they don't speak s-expressions, so s-expressions really offer no advantage in that case.
-----
If you think about it, Unix already has the same architecture as Racket. It's a bunch of DSLs (shell, make, C, C preprocessor, linker scripts, etc.) on the same runtime (the kernel, which talks to the hardware). It's just that you are forced to parse everywhere and serialize. That is definitely annoying, and problematic. But empirically, that design seems to be more evolvable / viral / robust.
Anything you can do with macros, you can also do with a traditional lexer/parser/compiler. Macros make things easier, but conceptually the architecture is the same.
Parsing is difficult for sure, but I do think that most programmers have an unnecessary aversion to it. I hope to tackle this problem a bit with Oil, i.e. make it easier to write correct, fast, and secure parsers.
Anyway that's my take, hope it helped!
EDIT: I should also say to not take this as discouragement from learning Racket. My first college class was SICP and it had a huge and permanent effect on my thinking. (I learned from reading Racket papers that my TA went on to work on Racket itself.)
I just didn't use Lisp for any industrial job thereafter. But that doesn't mean the experience wasn't valuable. I would definitely learn it for the ideas.
I see all these efforts to recreate programming with a new way of doing it as foolishness; it's the "let's rewrite the system from the ground up" fallacy writ large. Want to see some really interesting "visual" functionality that you can actually use to write useful apps? Take a look at the things IntelliJ is doing with Scala: https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... . Today one programs in a way that makes extensive use of the GUI, to the point that the code is difficult to work with in a plain text editor, but everything's been put on as a progressive enhancement starting from thinks that were known working and addressing the concrete pain points.
I love some of the work Alan Kay and others are doing at http://vpri.org/. His work on STEPS is trying to produce a whole working environment in 20 KLOC through heavy use of DSLs.
I hate programming silos. I think the world would be a much better place with good platforms, where libraries can interop easily and everything feels so integrated. Emacs is a watered-down reminiscence of this approach.
I think one of the main problems is that we still describe too much of "How" we want to do something, rather than "What we want to do", ie too many implementation details are specified.
Programming languages over time have moved towards higher layers of abstraction, from punch cards, to assembler, to c, to c++, to java/c# etc etc.
We haven't done the next leap yet and come up with a mainstream descriptive language that allows us to abstract away things like threading, tasks and optimizations.
If programming was even more about declaring intent a lot of work could be simplified I think. We could also put more intelligence into the interpreters/compilers and even adapt execution for different scenarios
One of the biggest problems is the flat one-dimensional aspect of text files.
Overly-graphical solutions are clunky and not concise enough. However overly-flat environments like a plain text file also comes with huge problems.
What I have wanted forever is a smart environment that looks similar to a text editor but under the hood it's more of a structure editor (wayyy easier said than done).
Two main problems with text is,
1. parsing
2. inability to easily associate metadata with parts of the program without visual/syntax clutter
I'll expand on each point,
Parsing: parsing implies syntax and language structure and it causes inflexibility. the problem domain is infinite but we have only so many characters to work with. this creates some blessed first class concepts like "strings" and puts everything else at a disadvantage.
A smart structure editor can bypass the parsing problem. It comes at the cost of some fluidity in the authoring process because effectively you would have to say what you are about to place somewhere before placing it. So instead of typing "string" you would have to somehow say "here comes a string", then provide its value.
The problem with this is the fast text-based editing and typing that we are used to becomes difficult and clunky.
Metadata:
This is a big topic. But to give a summary, this gives us a way to have information present that doesn't get in the way.
For example consider an assignment 'name := "John"'. When we are stuck in a flat environment if you want to make that assignment a "const" now you have to turn that into 'const name := "John"'.
In many cases there are lots of attributes and extra information that you would like to attach to a piece of the program.
You don't necessarily want to invent words and keywords and language rules for them. You also don't necessarily want to always see all of them.
If we could easily attach metadata to the pieces of the program it would obviate the need for many language complexities as many things could be turned into metadata key values.
So if you wanted to make a name binding constant you could set "is mutable := no" on that part.
Once you have the ability to associate arbitrary and not arbitrary metadata to any piece of the program it opens up so many opportunities.
I honestly don’t feel this way most of the time when doing pure FP. There are a few tools I wish were better but my code reuse is astounding, the refactor-ability is high, and it is easy to jump into unfamiliar code bases. Just mho from the experiences I’ve had.
I think that's because FP does a number of things right, like immutability, which leads to better composability of programs. These two aspects were what gave Eve a lot of its nice properties.
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.
You wouldn't really know based on looking at the prototypes, but the underlying language Eve was very similar throughout (as the article states, based on Datalog). The interface to that language varied because we weren't sure what the best interface was, or even if there was the one true interface to rule them all, or a constellation of interfaces and tools depending on purpose and device.
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
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.
> 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. :)
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.
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.
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!
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.
> If you don't think you have the right thing yet, having other people try out what you know is the wrong thing isn't going to be very useful.
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 right, it might actually be right, but there is a high chance that you'll find out that it is wrong during user testing.
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.
In all three you manipulated your code directly (instead of indirectly through text or other interfaces).
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.
An optimist might look at all that and say, it just shows you how much fertile ground there is outside conventional programming languages. Maybe any or all of those could be significant.
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.
Hm, that's an interesting claim! That there may be an essential, unavoidable complexity to certain types of software creation. And maybe the Eve team was trying to create tools that avoided or simplified that complexity enough to allow more people to create that type of software.
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:
I think we can do a better job of teasing apart the essential from the incidental complexity.
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.
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 (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).
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.
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.
The mouse is useful for video demonstrations because you can see what operations are being selected. We actually were convinced Eve would be better than most languages for keyboard use because A) most programs were very short, so fewer keystrokes over all and B) most programs could be built with autocomplete. The implication here was that we could enable programming on a phone with very minimal keyboard input, and mostly touch. Madlibs Eve was an example of this, where building a program could be done over SMS or chat.
It's near impossible to create shortcuts for everything. A modern IDE may contain thousands of possible actions at any given time.
That said, however, modern IDEs:
- have shortcuts for many dozens (possibly in the hundreds) of most commonly used actions
- allow you to map any action to a shortcut of your choosing
- allow you to search for a particular action via a keyboard shortcut with fuzzy matching, which is often faster than trying to remember the shortcut for a rarely used action.
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?
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 You can think of it like baremetal Eve.
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?
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.
