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.
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.
[1] http://incidentalcomplexity.com/2016/06/10/jan-feb/