Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Update README.md
  • Loading branch information
bolerio committed Oct 28, 2015
1 parent 3d38014 commit 420e263
Showing 1 changed file with 10 additions and 3 deletions.
13 changes: 10 additions & 3 deletions README.md
Expand Up @@ -16,8 +16,15 @@ With Seco you write notebooks which are structured files mixing code, documentat

A collaborative live development environment for building large-scale systems based on the evolution, sharing and reuse of fine-grained software artifacts. A detailed exposition of the long term vision can be read in the [Rapid Software Evolution paper] (http://kobrix.com/documents/rse.pdf).

## History and Comparison with Beaker/IPython/Jupyter
## Brief History

Seco is more than a decade old. Initially called _Scriba_, it was funded and developed by [Kobrix Software, Inc.](http://www.kobrix.com) with the double goal of being a practical programming tool for daily use, initially complementing standard IDEs, and working towards achieving a new vision for knowledge-driven programming as outlined in the above mentioned paper. While it matured quickly, as funds dried out, development staled. Currenly the project is being maintained sporadically.
Seco is more than a decade old. Initially called _Scriba_, it was funded and developed by [Kobrix Software, Inc.](http://www.kobrix.com) with the double goal of being a practical programming tool for daily use, initially complementing standard IDEs, and working towards achieving a new vision for knowledge-driven programming as outlined in the above mentioned paper. While it matured quickly, as funds dried out, development staled. Currenly the project is being maintained sporadically. Most of the code was written by Konstantin Vandev. It is currently maintained by Borislav Iordanov (@bolerio). Actively seeking help!

In recent years, a few comparable tools have emerged around the IPython web based notebook interface. Those look great and they undoubtedly share some overlap with what Seco has to offer. The crucial difference is that those tools are web-based while Seco is a plain desktop Java application. An advantage of IPython is that it looks prettier at the moment because Seco is written in Swing. A rewritten of Seco in JavaFX would be a major step forward. But the crucial difference is in the architecture: IPython based tools are client-server, which implies that the environment where the computation takes places is *separate* from the environment where user interaction happens. This leads to rather different possibility spaces. And it is no accident. The itching both to support other runtime environment in a client-server mode and to redo the UI in the browser has been there for a while. But that would be a departure from the fundamental goal of taking at a shot at an alternative P2P, crowd-sourced programming model. With the new WebAssembly effort, maybe major languages will be compiled to it so a browser-based environment would make sense. But that's an even longer shot. Another advantage of Seco is its foundation: HyperGraphDB. This is not immediately apparent, but everything you do is automatically persisted, sort of like in Smalltalk. Except, instead of saving a binary image and trying to work hand in hand with the JVM to bring it back alive, Seco's model is one of maintaining dependencies between inputs and outputs where initial input cells bootstrap the evaluation until the full interactice environment is recreated. And as I said, the ultimate goal has always been a knowledge-driven P2P programming (with an evolutionary process on top). The JVM is a problem, but there is practically no other choice if one wants something immediately useful.
## Comparison with Beaker/IPython/Jupyter

In recent years, a few comparable tools have emerged around the IPython web based notebook interface. Those look great and they undoubtedly share some overlap with what Seco has to offer. But here is how they differ and why you should care about Seco (i.e. give it a try, give feedback, help out with development and ideas):

* Seco's foundation is HyperGraphDB. This is not immediately apparent, but everything you do is automatically persisted, sort of like in Smalltalk. Except, instead of saving a binary image and trying to work hand in hand with the JVM to bring it back alive, Seco's model is one of maintaining dependencies between inputs and outputs where initial input cells bootstrap the evaluation until the full interactice environment is recreated. The ultimate goal has always been a knowledge-driven P2P programming (with an evolutionary process on top). The JVM is a problem, but there is practically no other choice if one wants something immediately useful.
* This point is worth understanding well: the very GUI of Seco is represented and stored in an embedded HyperGraphDB instance. The notebooks, the various types of cells are HyperGraphDB atoms so that they can be shared and modified at a fine grained level. A true live environment is hard to pull off within the JVM, but one can get close enough because one doesn't have to represent objects in a JVM serialized form, on can re-evaluate and re-create things at runtime.
* From a more practical perspective, those newer tools are web-based while Seco is a plain desktop Java application. An advantage of IPython for example is that it looks prettier at the moment because Seco is written in Swing. A rewritten of Seco in JavaFX would bring the graphics on par.
* Also notably, a crucial difference is in the evaluation architecture: IPython based tools are client-server, which implies that the environment where the computation takes places is *separate* from the environment where user interaction happens. This leads to rather different possibility spaces. And it is no accident. It is a conscious decision for Seco to be part of the computation. Client-server, cloud based computational resources can always be plugged as evaluation engines for Seco, of course. But I'd rather embed a browser or a web rendering engine inside the enviorment instead of running within a browser. That's because the ultimate long term dream remains taking a shot at an alternative P2P, crowd-sourced programming model.

0 comments on commit 420e263

Please sign in to comment.