At first i wondered if the authors even know what they're making.. then in the first blog post i found a mention of Light Table. It was the concept IDE with a live preview or visualization about what parts of code output.
It appears the Eve the language evolved from that, and still is. And it seems this DVCS (what this article is about) is meant to compliment Eve.
It made me ask the question "but what is wrong with Git? What IS the problem Yet-Another is solving?"
I liked the fact that the Eve guys are thinking about how git and darcs work differently and how it affects the version history in the case of collaborative editing.
Recording changes as they happen is easier than
inferring them after the fact
That's all very well if you're trying to develop something like Google Docs, where you can define change semantics the merge process understands, then constrain the editors to only allow changes that follow those semantics.
But the moment a user wants to take the code out of your editor to process it with some other tool - perhaps they want to sort that text file, or minify that javascript, or just edit in emacs because they like the keybindings - you're back to inferring the changes after the fact.
You'd have to build a lot of tools if you want to stop your users ever wanting to use a tool outside your editor :)
It seems to me that the Eve folks have already decided to make that tradeoff though: a richer environment that is necessarily walled off at least a bit from the traditional "it's all text" approaches.
Smalltalk didn't take over the world with that approach, but it's certainly interesting to explore.
In Cloud9IDE they've done a very amazing job of integrating collaborative editor with bring your own server. From what I've been able to tell, both the built-in editor and filesystem watches will trigger change operations and the two are used together to produce a very seamless user experience.
Collaborative live programming is a pretty bad idea in the first place. There is one thing that's very important that you're missing in your analysis of "the past". All DVCS system allow the programmer to group a set of changes by commits, which constitute a consistent block of changes.
Remove that ability by constantly recording changes, and you can no longer control your code: no code review, no feature merging. Everything just becomes a giant mess. A mess that's auditable, but a mess nontheless
Audit trail bread crumbs are currency, for research, expression, and development at log scale.
Right now I am lost with git and mercurial, Gist has better visual diffing than standard repos, yet standard repos have better granular linking.
Gitchain/Mercurialchain would help the world if there was a log-long-term where every bit was actually accountable, versus our current war text processing by taking logological leads from heads without tails — depth psychology and science at logy cannot scale without being able to read granulate better.
Without finite and granular social logging currency, breakthrough commits recreate old patterns of hidden language between growths.
Without finite and granular social logging currency, breakthrough commits recreate old (forma trauma terma) patterns of hidden (problem solving without showing work hurts?) language between growths.
Judging text minus emotion is basically why Bit451 is meaningful as Gitchain for stable social currency, between revision history edits at war.
"Communication does not depend on syntax, or eloquence, or rhetoric, or articulation but on the emotional context in which the message is being heard. People can only hear you when they are moving toward you, and they are not likely to when your words are pursuing them. Even the choicest words lose their power when they are used to overpower. Attitudes are the real figures of speech.” —Edwin H. Friedman
Farenheit 451 is now socialized by grammar before words hit the books.
In the Qbix Platform (http://platform.qbix.com) the default type of data is a Stream. A Stream is published by a User and one or more Users can be Invited and Participate. Streams are supposed be of different "types" and support posting Messages of different types. The multicasting of messages to participants who are online via sockets is handled by the pltform. Participants who are offline can maintain Subcriptions and receive offline Notifications to their native app on a device (iOS, Android, Mac) or email or sms or facebook. In addition there is Access control which specifies access to the Public as well as individual users and by Labels (like roles, but labels on contacts of the publishng User). Users can be either people or organizations.
The whole thing is supposed to "just work" and, at version 0.8, it pretty much does, stably. But we still have a lot to do.
The reason we chose this is because it supports everything from updating your status / location / whatever to chatrooms and collaborative documents. A chess game is just a stream of type "Chess/game" which supports messages like "Chess/move" and "Chess/resign".
All the developer has to do is implement their stream type, or "tools" (components) to interact with the stream or "preview" it in listings. We provide typical tools such as "Streams/related" which automatically handles showing streams related to some given stream, and can update in realtime, allow creation of more streams, etc. The developer would jst handle incoming messages and process their effects. Also sometimes a stream might Refresh because the user, say, came back to a mobile app after it was suspended in the background. In this case the stream player or preview gets the latest state instead of "replaying" what would potentially be 100s of messages. And the whole page doesnt need to be reloaded. It all works already.
Now we are working on Offline streams. For example, a stream that has been created offline isn't shared with anyone so no one else can write to it. This means we ca handle all the persistence on the client and sync it later, when the client connects.
We do not attempt to solve issues via "heuristic" diff based sync algorithms. Instead, the source of truth is the Publishing User's server and it is also the source of chronological order of the messages. The developer never has to worry about messages arriving out of order, or something else, just use the JS API. In addition, we handle the CAP theorem by requiring consistency only per stream. If one message contains (hashed) info from another message on some other strean, we know it was posted later (like bitcoin).
In the end we plan to make this platform completely distributed and power social layer for the web like wordpress powers blogs.
Shout out to "Out of the tarpit" [1] that's referenced in the "functional-relational" link in the article. This is a great paper that's well worth 20 minutes of your time to read!
31 comments
[ 0.17 ms ] story [ 69.2 ms ] threadIt appears the Eve the language evolved from that, and still is. And it seems this DVCS (what this article is about) is meant to compliment Eve.
It made me ask the question "but what is wrong with Git? What IS the problem Yet-Another is solving?"
From http://incidentalcomplexity.com/hiring/ and http://www.chris-granger.com/2014/10/01/beyond-light-table/ it sounds like the people behind Light Table are now working on an Excel-like collaborative programming environment called Eve.
Reminds me a little of the Feynman algorithm. 1) Write your question into google. 2) Open the first three results. 3) Copy what you find.
Does it already have a name?
http://programmers.stackexchange.com/questions/129543/what-i...
http://git-scm.com/book/en/v2/Getting-Started-About-Version-...
http://git-scm.com/
..not bad
1. Write down the problem.
2. Think real hard.
3. Write down the solution.
[1] http://c2.com/cgi/wiki?FeynmanAlgorithm
Origin: https://xkcd.com/1185/
Implementation: http://gkoberger.github.io/stacksort/
But the moment a user wants to take the code out of your editor to process it with some other tool - perhaps they want to sort that text file, or minify that javascript, or just edit in emacs because they like the keybindings - you're back to inferring the changes after the fact.
You'd have to build a lot of tools if you want to stop your users ever wanting to use a tool outside your editor :)
Smalltalk didn't take over the world with that approach, but it's certainly interesting to explore.
Remove that ability by constantly recording changes, and you can no longer control your code: no code review, no feature merging. Everything just becomes a giant mess. A mess that's auditable, but a mess nontheless
Right now I am lost with git and mercurial, Gist has better visual diffing than standard repos, yet standard repos have better granular linking.
Gitchain/Mercurialchain would help the world if there was a log-long-term where every bit was actually accountable, versus our current war text processing by taking logological leads from heads without tails — depth psychology and science at logy cannot scale without being able to read granulate better.
Without finite and granular social logging currency, breakthrough commits recreate old patterns of hidden language between growths.
Without finite and granular social logging currency, breakthrough commits recreate old (forma trauma terma) patterns of hidden (problem solving without showing work hurts?) language between growths.
If/when legal codes and power codes are apaths and robo swears, it might reflect realities of serialities?
If/when legal codes and power codes are apath-grammar-determination by robo swears syntaxic sugar wars, it might reflect a realities of serialities?
Audit trail bread crumbs are currency with a cost to remember better than just repress to perform.
"Communication does not depend on syntax, or eloquence, or rhetoric, or articulation but on the emotional context in which the message is being heard. People can only hear you when they are moving toward you, and they are not likely to when your words are pursuing them. Even the choicest words lose their power when they are used to overpower. Attitudes are the real figures of speech.” —Edwin H. Friedman
Farenheit 451 is now socialized by grammar before words hit the books.
The whole thing is supposed to "just work" and, at version 0.8, it pretty much does, stably. But we still have a lot to do.
The reason we chose this is because it supports everything from updating your status / location / whatever to chatrooms and collaborative documents. A chess game is just a stream of type "Chess/game" which supports messages like "Chess/move" and "Chess/resign".
All the developer has to do is implement their stream type, or "tools" (components) to interact with the stream or "preview" it in listings. We provide typical tools such as "Streams/related" which automatically handles showing streams related to some given stream, and can update in realtime, allow creation of more streams, etc. The developer would jst handle incoming messages and process their effects. Also sometimes a stream might Refresh because the user, say, came back to a mobile app after it was suspended in the background. In this case the stream player or preview gets the latest state instead of "replaying" what would potentially be 100s of messages. And the whole page doesnt need to be reloaded. It all works already.
Now we are working on Offline streams. For example, a stream that has been created offline isn't shared with anyone so no one else can write to it. This means we ca handle all the persistence on the client and sync it later, when the client connects.
We do not attempt to solve issues via "heuristic" diff based sync algorithms. Instead, the source of truth is the Publishing User's server and it is also the source of chronological order of the messages. The developer never has to worry about messages arriving out of order, or something else, just use the JS API. In addition, we handle the CAP theorem by requiring consistency only per stream. If one message contains (hashed) info from another message on some other strean, we know it was posted later (like bitcoin).
In the end we plan to make this platform completely distributed and power social layer for the web like wordpress powers blogs.
So that's how wedo it!
[1] http://shaffner.us/cs/papers/tarpit.pdf
Actually I read it a while ago - it must have resonated because I remember it being shorter :-)
https://neil.fraser.name/writing/sync/
I wrote this to help me understand the algorithm:
http://dougmart.in/dssimulation/