9 ms·

A Visual History of Eve: 2014 - 2018

165 points by stevekrouse 9y ago

acobster 9y ago
> 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 9y ago
  I should note that Eric Hoffman also was part of the team for a year.
  - cmontella 9y ago
    Don't forget Rob Attorri! He wasn't an engineer, but he was there from day one (cofounded with Chris)!
    - stevekrouse 9y ago
      Added, thanks!
  - stevekrouse 9y ago
    Added, thanks!
barryp 9y ago
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.
smoyer 9y ago
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).
- solarkraft 9y ago
  It's still very possible to put shortcuts on traditional mouse interactions. I don't find that this should be a significant hurdle.
- cmontella 9y ago
  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.
- joshuafcole 9y ago
  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.
Glench 9y ago
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.
- fusiongyro 9y ago
  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.
  - Glench 9y ago
    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: http://worrydream.com/ClimateChange/#tools-technical http://worrydream.com/ClimateChange/#tools-technical
  - repsilat 9y ago
    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.
munificent 9y ago
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 9y ago
  The whole thing was an exploration into the unknown. It was a discovery process.
  - msangi 9y ago
    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
- cmontella 9y ago
  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.
- michaelcampbell 9y ago
  Yes, it should be noted that most successful tech is successful because it ultimately solves some human problem; not simply because it is cool. Not sure what this is solving, thought it is very cool.
- pjmlp 9y ago
  Yes, people forget that a language gets chosen to solve a problem or as means to integrate a tool, and not the other way around.
joshmarinacci 9y ago
Oh, man. I was really hoping Eve would be successful.
jng 9y ago
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 9y ago
  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.
superkuh 9y ago
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 9y ago
  Nope, not the only one ;-)
gradys 9y ago
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 9y ago
  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 9y ago
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?
nnq 9y ago
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 9y ago
  > 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.

165 points by stevekrouse 9y ago

> 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 9y ago
I should note that Eric Hoffman also was part of the team for a year.
- cmontella 9y ago
  Don't forget Rob Attorri! He wasn't an engineer, but he was there from day one (cofounded with Chris)!
  - stevekrouse 9y ago
    Added, thanks!
- stevekrouse 9y ago
  Added, thanks!

barryp 9y ago

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.

smoyer 9y ago

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

solarkraft 9y ago
It's still very possible to put shortcuts on traditional mouse interactions. I don't find that this should be a significant hurdle.
cmontella 9y ago
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.
joshuafcole 9y ago
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.

Glench 9y ago

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.

fusiongyro 9y ago
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.
- Glench 9y ago
  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: http://worrydream.com/ClimateChange/#tools-technical http://worrydream.com/ClimateChange/#tools-technical
- repsilat 9y ago
  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.

munificent 9y ago

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 9y ago
The whole thing was an exploration into the unknown. It was a discovery process.
- msangi 9y ago
  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
cmontella 9y ago
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.
michaelcampbell 9y ago
Yes, it should be noted that most successful tech is successful because it ultimately solves some human problem; not simply because it is cool. Not sure what this is solving, thought it is very cool.
pjmlp 9y ago
Yes, people forget that a language gets chosen to solve a problem or as means to integrate a tool, and not the other way around.

joshmarinacci 9y ago

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

jng 9y ago

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 9y ago
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.

superkuh 9y ago

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 9y ago
Nope, not the only one ;-)

gradys 9y ago

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 9y ago
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 9y ago

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?

nnq 9y ago

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 9y ago
> 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.