enabling persistent state for the REPL?

[Russel Winder via Digitalmars-d]

On Tue, 2015-03-17 at 00:55 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[…]
> What do you/others think about having the REPL serialize any 
> variables (optionally only those that are declared in a certain 
> way, or part of a particular struct) to RAM disk or SSD and 
> reload them at each stage rather than calculating them (ie 
> compiling the generating statements) from scratch each time.  The 
> overhead would be modest in the trivial case, but it would allow 
> you to use the REPL to explore larger data sets that take time to 
> generate.
> 
> Simple example here:
> http://nbviewer.ipython.org/gist/twiecki/3962843
> 
> (This data doesn't take long to generate, but larger data sets 
> might).

I believe too many people over-rate REPLs, they are 1960s solutions to
interactive computing when there were no better solution. Editor + fast
compilation, is a far better solution for most of the situations that
people think REPLs are great for. These days systems like Jupyter show
that you can create documents with executable fragments, a much better
solution generally.

For me the problem with REPLs for most people's use of them revolves
around all the hidden persistent mutable state: it's a batch processing
solution to an interactive computing problem. Your case though is one
that exactly fits this situation. So this is a case where REPLs may well
be the right way forward. The question is I guess how to render
visualizations of the data.

Jupyter is trying but it is also trying, there should be better, I do
not have a vision for what it might be though :-(

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150317/e7da6abd/attachment.sig>