Hi everyone, Corey here from Eve. We've been in the trenches for a while, so I've been working to document a backlog of progress.
A lot has changed even in the ~3 months since the work in this post occurred, so it's not reflective of where we are now. But I'll stick around here to answer any questions relevant to this post or Eve in general.
Eve is only as useful as the data in it, so we really want to make it easy to import data from a variety of sources. You bring up a really good point though, that if our interface is grid-based, then there should be a simple mapping from Excel -> Eve. We support a superset of Excel functionality, so theoretically it should be possible, but as always the devil is in the details.
I would guess his/her skepticism comes from the fact that Excel has about a billion + 1 features. Even Google and Open Office have trouble supporting everything. In that sense, I was too loose with my comment of supporting a superset. There's the old adage that everyone uses 20% of the features in Office, but it's a different 20% for every person.
Instead of "superset of Excel functionality" I should have said "superset of Excel semantics".
At first I thought they were talking about the game, EVE Online. And then the example on the page reference "moons per planet", which confirmed to me they were talking about that space game.
Read the comments first. I assumed they had finally just given EvE a full excel interface and allowed imports/exports until about halfway through the comments.
Yeah, there is no context to this post, so I appreciate your confusion. Eve is a programming platform we are designing to bring the power of programming to non-programmers. You can read a little more about our mission here: http://witheve.com/
Incidental Complexity is our dev blog, which we've been using to update people about our work. We are developing in the open, so you can see what we're up to on our GitHub: https://github.com/witheve/lueve
Its great to see the regular updates om Eve now. I hope these posts get enough exposure as they used to get when Chris Granger posted them to hacker news himself
I was a little confused with the two posts when read together...I get that the GUI isn't yet complete, so I don't think I'm meant to understand what the grid demo is showing or how it connects to the backend...but in the second section, a lot of attention is given to the REPL...is one of the foreseen use cases that users will be entering data via REPL?
I wrote a little about this is a previous dev diary [1]. The short answer is we wanted to decouple our GUI from the programming platform. We had a syntax for the language at one point in 2014. But we also believed in dogfooding; if we are creating a programming language for non-programmers, we should be using it as they would i.e. without a syntax.
Unfortunately, this led to the situation where our platform couldn't progress past our GUI. This might have been okay, except we didn't know what the GUI should look like. We've tried grids, graphs, wikis, madlibs, and everything else. The GUI was kept in a constant state of flux, so our entire platform was.
So we wised up and made a protocol and a text syntax to interface with the Eve server. By loosely coupling the platform and the GUI, we can now progress them at different rates.
To be clear, we don't intend that the language will be exposed to non-programmers through the REPL. However we've always expected that developers will be our first users, and we want to have some tools they're familiar with. At the same time, we are still developing UI concepts for non-programmers, trying to hone in on what works.
So it is always to be a client/server thing, right? Cloudy?
Is this a strict requirement? Like users to work cooperatively on the same document (a.k.a. Google Wave, sic transit gloria mundi).
An Eve server can run locally in its own instance, separate and isolated from anything else. It would be no different than Java requiring the JVM.
But one of the nice things about Eve is that it effortlessly distributes to multiple nodes/users. So yes, we support the case where users are working cooperatively on the same document.
For example, that's the way the REPL works. Let's say my team is making a website about dinosaurs. On my machine, I add a stegosaurus entity to the database with several attributes: discovered, average length, average height, etc.
Now my colleagues have immediate access to this information. If one of them had a query open asking "What dinosaurs are in the system?" then their view would update with stegosaurus immediately.
In turn, I could use her list in another way e.g. to render it in a browser with links to each dinosaur's Wikipedia page.
As of collaboration ... it could be clients/single-server or fleet of apps synchronizing with each other. Gut feeling: later one has greater potential. Can work in standalone and team modes, no?
In this case, the REPL is just a client like any other. Its behavior is what makes it a REPL (i.e. you type, press enter, get a result, rinse, repeat). It conforms to the same protocol as any other interface we plan on making. This REPL goes a step beyond typical REPLs because the backend is networked, thus its state is shared with other clients. These other clients don't even have to be another REPL. In this way, a developer using a syntax interface could work directly with Steve from accounting, who is using some visual programming interface.
Imagine a developer and a designer working together on an app. The developer is writing the backend code for the app in the syntax he is comfortable with, and the designer is making the UI in something like Sketch. With Eve, this workflow will blend together seamlessly.
"... you type ..." am I correct in my understanding that this will cause each character press to be sent to the server? And the same for the counter() function that you have there, right? Actually where will such timers run? On server or client? I am trying to mentally visualize computational graph and data model...
The REPL as it stands submits the query on enter, just like sending a text message. But I have written it in a way where each keystroke is sent.
The counter() function you're referring to was implemented in GridEve, which was an experiment on the UI. It was written in C# and used a different (and abandoned) backend. It was a local-only app, so the timer ran on the local machine.
Time in the client/server architecture is something we have to give a little more thought to, since we're still trying to get things working in a timeless world.
But actually, while it's completely useless on a PC, a usable graphical environment is clearly needed for the tablet market, so I don't understand why they are so insistent on pushing the 4GL / application builder approach from the early 90ies.
Actually not much about Access in that. Their stated goal, OTOH, is to make an Excel like tool.
>But actually, while it's completely useless on a PC
Huh? If done right, it will be extremely useful on a PC, the same way Excel is, but as an avenue for far more programmability than Excel.
>so I don't understand why they are so insistent on pushing the 4GL / application builder approach from the early 90ies.
Because that approach is also of the 21st century and onwards.
It's rather us, programmers, who insist on dragging the conventional approach (not to mention crude text-based tools like Emacs and Vim) against the times. Besides the 4GL/application builder space left unexplored, Lisp Machines and Smalltalk environment were more advanced than what we use today in a lot of ways.
> Huh? If done right, it will be extremely useful on a PC, the same way Excel is, but as an avenue for far more programmability than Excel.
You cannot be more programmable than Excel, because VBA is deeply integrated and it already is fully programmable. The question is: how will Eve solve the GUI vs. scripting dichotomy that, in my opinion, is pervasive throughout all "innovative" programming environments.
> Besides the 4GL/application builder space left unexplored, Lisp Machines and Smalltalk environment were more advanced than what we use today in a lot of ways.
For those confused like myself, this is about Eve, an excel-like development environment from the person who brought you LightTable. This is not about Eve Online.
Someone made a parody web game once that was basically a database view of user and game state. You could insert rows and get points and things, it was a hilarious jab at the whole class of games where the gameplay feels like you're just updating cells in a database. I searched for it but couldn't find it just now, anybody know what I mean?
I detect confusion. It's Excel that excels at simulating Eve Online. It sounds like Eve would make an even better simulator of Eve Online than Excel, however.
Some are technical, some are not. But the ones around the time of major tech changes are the most interesting. For instance, when they implemented "time dilation" a few years back.
Time dilation is, and remains, the single most beautifully elegant piece of problem solving I think I've seen applied to spaghetti legacy codebase like Eve's, and saved the game from a slow descent into unplayability.
Not played for a year or two, but that's coming off the back of a 10 year eve-habit. It always makes me smile when I see it randomly mentioned on HN and suchlike.
What is also quite interesting about their platform is that they use Stackless Python for the game logic (https://community.eveonline.com/news/dev-blogs/stackless-pyt...). Their whole architecture is quite amazing for how old their tech is and what they have managed to achieve.
A lot has changed even in the ~3 months since the work in this post occurred, so it's not reflective of where we are now. But I'll stick around here to answer any questions relevant to this post or Eve in general.
Edit: I wasn't anticipating this would be on HN today, but it is, so here is part 2 with the rest of the story: http://incidentalcomplexity.com/2016/06/22/mar2/