Rationale for html5 repl

[kovasb]

My 2 cents..

The REPL plays an integral role in development with dynamic languages.
But apart from a handful of exceptions (Factor, DrRacket, Mathematica,
IPython's "HTML Notebook"), today's typical REPL is little different
from the text-based REPLs of 30, 40 years ago.

There are 2 related problems with text-based REPLs:
- Text-based REPLs can not faithfully reflect the modern-day
programmer's creation.
- Text-based REPLs are difficult to improve. They are essentially a
dead end.

However, text-based REPLs have dominated because:
- Terminal works on every machine of interest; someone's experimental
GUI repl doesn't.
- Developers versed in both the dynamic language and GUI framework X
are rare.

What if we had a UI framework that worked essentially everywhere, and
that tens of millions of developers were familiar with? This is the
modern web.

What I'm calling "html5 repl" consists of the following:
- A pure clojure/script web app that provides structured interaction
to evaluating forms on the backend, and where the returned structure
can be rendered according to browser capabilities.
- The rules for rendering (aka the views) are user-programmable, and
just compile down to html and javascript.
- The interface itself consists of these rendering rules, so there is
little difference between what you create interactively, and the html5
repl app you are using.

The advantage of the last point should be emphasized. You can
interactively create a widget, call it "html5 top" that nicely
displays system usage. There is no friction to adding it to the
working environment. And because the working environment is the web,
it is a single click from browsing someone's widget to having it
available to play it.

Finally I'd like to mention 2 use cases that are particularly
relevant.

1. Data / systems analysis
I do a lot of this. One is always making pictures, formatting tables,
wanting little progress bars, or multiple simultaneous views of
distributed processes.

There is no standard way to do any of this. Different data analysis
tools do it differently, and libraries that should be algorithmic are
compelled to offer their own limited solutions. Interactive
explorations are separated from the content they generate. And putting
their results on the web, for others to see, is another set of
problems.

A web-based platform would allow widely-used visualization libraries
to emerge. If the user wants to make their own, the time investment
will reap greater reward than learning Swing or some other limited
platform. Sharing your creation with others is a matter of deployment,
rather than reimplementation in a web context, figuring out a custom
web app structure, etc.

2. Web apps

The situation here is more extreme. With data, you can at least save
the picture you generated, or save a table of numbers. But in web
development, the results of your interactive experiments totally
vanish. The only way to save them is to roll them into a much heavier-
weight webapp, or count on memory.

A web-based platform would allow true incremental development,
allowing a continuous series of steps from small experiments to a
fully functional program. It can provide a scaffold as you improve and
extend the webapp being developed, until the webapp is the whole
screen.

And again, being able to develop your own UI extensions to the working
environment is boon to debugging and developing the app in question.
From monitoring backend errors, to inspecting the state of databases,
to profiling the frontend, publishing to production, just tons of
stuff can be done and packaged for use by the community.

Ok, thats all for now :) I have a ton of notes about all the issues
involved, crucifictions of what the last guy did, possible solutions
etc, but want to put this out there as I organize the other material.

[hoeck]

Hi,

I totally agree with your statements about REPLs and the problems the
text-based ones currently have:

> There are 2 related problems with text-based REPLs:
> - Text-based REPLs can not faithfully reflect the modern-day
> programmer's creation.
> - Text-based REPLs are difficult to improve. They are essentially a
> dead end.

> However, text-based REPLs have dominated because:
> - Terminal works on every machine of interest; someone's experimental
> GUI repl doesn't.

But there are some more things text-based REPLs are good at. You only
recognize (miss) them when trying a GUI based repl in practice:
- simple: additional dependencies are minimal (only the repl itself
and a terminal emulator)
- useful: basic editing and highlighting capabilities (terminal color
escapecodes, libreadline ...); they can be used transparently over the
network (by using ssh)
- robust: a terminal emulator does not crash if you print a large
dataset by accident

> - Developers versed in both the dynamic language and GUI framework X
> are rare.

From own experiences with GUI frameworks (Swing, Pivot, GTK, Win32),
I've come to believe that REPLs are way too dynamic for them. Also,
most of the non-java GUI frameworks are typically written in C or C++,
so you get into all kinds of problems (garbage collection, too many
callbacks/elements in a single container) beyond simple image-here/
button-there repl interactions.

> What if we had a UI framework that worked essentially everywhere, and
> that tens of millions of developers were familiar with? This is the
> modern web.

Exactly!!! There are also a ton of other advantages:
- the main scripting language is dynamic, so the friction between a
dynamic REPL and a browser engine rendering its output is much lower
as opposed to common GUI frameworks
- browsers (their rendering engines) will happily render anything
which remotely resembles HTML, even plain text
- we have nice libs to render data (http://mbostock.github.com/d3/),
edit text (https://github.com/ajaxorg/ace/) ...
- browser engines are available on all platforms

At this point though, I went into a different direction. Instead of
moving the repl from the terminal to the browser, I tried moving the
browser into the terminal.
The result of this experiment is an HTML capable terminal emulator. It
runs all your existing terminal applications (Bash, Clojure REPL,
IPython, Midnight-Commander) but additionally is also able to render
html documents, execute javascript and communicate with the running
application.

Using that, you can incrementally enhance existing commandline
applications to include html output or write new applications from
scratch which are entirely html+javascript(clojurescript) based. Using
the latter approach, it should be relatively easy to develop some
application prototype on the commandline and later evolve it into a
real webapp.

I coded up some simple demos: a program to show the contents of a
directory as a circular tree (uses d3.js), a inline-editor demo (using
Ace) and a mysql client demo which renders database results as styled
html tables. Those few demos barely scratch the surface of what I do
have in mind. For example, you could combine them to a Clojure REPL
where:
- Ace is used to edit forms inline (with syntax highlighting and emacs
keybindings)
- data could be rendered using d3.js
- editors to edit the contents of a hashmap as a table
- exceptions/stacktraces are nicely formatted and presented
interactively (click-to-expand, show-definition ...)
- sliders are used to change variables

The project is not complete yet but usable. The terminal emulation
works quite nicely, the API (escape codes) is not stable yet and there
are bugs with resizing the terminal window. Currently, I'm working on
extending the SQL-Shell prototype. After finishing that I plan to
built a Clojure REPL incorporating the ideas from above.

Screenshots: http://imgur.com/a/N84aw
Code: https://bitbucket.org/hoeck/schirm or https://github.com/hoeck/schirm

Cheers,
Erik

[Sung Pae]

> On 29 Feb 2012, at 4:00 AM, hoeck wrote:

> At this point though, I went into a different direction. Instead of
> moving the repl from the terminal to the browser, I tried moving the
> browser into the terminal.

How interesting! I just had the reverse thought today: embedding
rxvt-unicode inside of a Webkit application. This is less work than
embedding an html rendering engine in a terminal [1], at the risk of not
being substantially different from glueing a browser and terminal window
together.

Combining a terminal and browser (in whatever form) unfortunately has
two drawbacks:

1. You'll never get the current generation of programmers to drop
their favorite terminal setups or Windows-based IDE workflows.

2. Interaction with the program remains primarily through the
keyboard via the terminal.

The first point may not matter much in 30 years, as I imagine the
allure of xterm-esque terminals will have faded substantially. But for
today, this is a strong argument for decoupling the HTML5 REPL from the
terminal / editor.

I won't say, however, that I would never give up my urxvt / tmux / vim
setup, because that's exactly the kind of myopia that Bret Victor (the
spiritual progenitor of this mailing list) is attacking. What _is_
necessary to break away is a compelling interaction experience that
trumps the keyboard nirvana that many of us have extracted from our
tools.

It's not clear to me how to create general tools that have this property
[2], but in the meantime I can imagine exploring data structures and
visualizing functions in a rich REPL on the iPad next to me without
having to give up the years of investment I have in my current tools.

That said, I applaud your effort to drag us into the future. Schirm
looks quite impressive.

Cheers,
guns

[1]: You may be burned at the stake as a sorcerer if you manage to
figure out how to get curses-based apps to display html.

[2]: The solution implied by "Inventing on Principle" is to create new
editors that expose new interactive APIs.

[kovas boguta]

That is pretty impressive. I'm in favor of this intersection explored
from all possible angles.

I completely agree that dependencies should be minimal. In my proposal
the client is just the plain-old-browser, which is a given. The server
would be a lein plugin or dev dependency, so getting that running
would be as easy as is possible.

Once you require the installation of new software on the client,
adoption becomes harder.

The terminal, and the various linux programs, aren't going away any
time soon, so I was thinking of the clojure html5 repl as something
just dealing with the clojure side, supplementing the existing tool
chain. Though if system-level interaction can increasingly be brought
into the browser as well, that is a plus.

An issue I didn't elaborate that much on before is the opportunity to
fix how state is handled. "State: you're doing it wrong" very much
applies to the text-based repl, and terminal interaction generally.
Given a terminal session, it's hard to reproduce the state of the
system. This seems like an impossible problem to solve generally for
terminal-based interaction with the low level system. But in the case
of clojure, there is a lot more to work with.

[kovas boguta]

Here is another interesting take:
http://pretty-lisp.org/

(i believe this was submitted by fogus on hacker news)

[hoeck]

On 29 Feb., 18:12, Sung Pae <sung...@gmail.com> wrote:
> How interesting! I just had the reverse thought today: embedding
> rxvt-unicode inside of a Webkit application. This is less work than
> embedding an html rendering engine in a terminal [1], at the risk of not
> being substantially different from glueing a browser and terminal window
> together.

At first, I went with this approach too, but my expectations wrt.
terminal emulation are quite high (history, dynamically resizable,
must be able to run at least mc and kismet). The only browser-terminal
implementation worth hacking was Shellinabox (https://code.google.com/
p/shellinabox/). Unfortunatly, while being a great program, its
internals (the client side terminal emulation) are too tied to
rendering an array of character blocks and I failed to modify its code
to my needs. I gave up and implemented my own emulator instead.
Writing a basic terminal emulator is not that hard, a couple of
character-drawing commands acting on a canvas of character blocks,
which easily translates to a single html <pre> element (web-shell does
this: https://code.google.com/p/web-shell/).

> Combining a terminal and browser (in whatever form) unfortunately has
> two drawbacks:
>
>     1. You'll never get the current generation of programmers to drop
>        their favorite terminal setups or Windows-based IDE workflows.

True, even I for myself am using gnome-terminal instead of schirm
because schirm is just too slow and currently does not even allow
customizing colors. However, the adoption problem is the reason I went
with VT100 compatibility in the first place. Ideally, this allows
someone to use all his shell-fu and existing programs and to
incrementally switch to html5 alternatives.

>     2. Interaction with the program remains primarily through the
>        keyboard via the terminal.
>
> The first point may not matter much in 30 years, as I imagine the
> allure of xterm-esque terminals will have faded substantially. But for
> today, this is a strong argument for decoupling the HTML5 REPL from the
> terminal / editor.

Or try to build the killer REPL so that everyone wants to use it,
ignoring the downsides of installing additional programs :).
A more realistic perspective (for me) would be to provide a browser
fallback if one runs the REPL from a non-html capable terminal. Though
that is not a priority for me right now, as I'd like to explore the
general usefulness of code-as-html5 first.

> I won't say, however, that I would never give up my urxvt / tmux / vim
> setup, because that's exactly the kind of myopia that Bret Victor (the
> spiritual progenitor of this mailing list) is attacking. What _is_
> necessary to break away is a compelling interaction experience that
> trumps the keyboard nirvana that many of us have extracted from our
> tools.

The way schirm is designed completely hides its internals from the
client application. Its basically a runtime providing a single browser
iframe, authentication and a webserver setup on localhost. Running a
schirm client application in fullscreen is indistiguishable from
running the same thing as a webapp in lightweight webkit browser like
uzbl or surf.
If you replace you default shell, e.g. bash with an imaginary HTML5
shell showing icons of all accessible programs, you could run programs
without typing or knowing their name.

You are maybe aware of TermKit (https://github.com/unconed/TermKit/).
Schirm is basically a ripoff, except with VT100 compatibility, less
API-chrome and raw access to the underlying webkit instance.

> It's not clear to me how to create general tools that have this property
> [2], but in the meantime I can imagine exploring data structures and
> visualizing functions in a rich REPL on the iPad next to me without
> having to give up the years of investment I have in my current tools.

Never did any iOS or Andriod programming, but as long as it is
possible to embed webkit (with some low level access to the rendered
website) into those applications, writing a tablet version of schirm
should be doable (and sounds like a promising idea to me).

> That said, I applaud your effort to drag us into the future. Schirm
> looks quite impressive.

Thanks :)

Cheers,
Erik