
Pretty Lisp - fogus
http://pretty-lisp.org/
======
lambda
Huh. I wouldn't call this pretty. Why do you need a box around everything? One
of the arguments about Lisp is how visually distracting the parentheses are
(and yes, experience Lisp hackers learn to tune them out; that doesn't change
the fact that they are visually distracting); the boxes are even more visually
distracting. To use Tufte's terminology, this is decreasing the data-ink
ratio, not increasing it.

Take a look at Slashdot comments, and compare them to Hacker News comments.
Slashdot has a whole lot of extra chrome that doesn't increase the information
density. Hacker News has very little on the screen beyond the actual content;
it simply uses indentation to indicate nesting of threads.

Why do you need all of the boxes? Why not just use indentation, perhaps
highlighting only the currently focused expression? Python has already shown
that indentation is sufficient for readably delimiting nested blocks of code.
Using indentation to delimit code blocks in plain text has some problems when
moving code to a different nesting level, but if you have a structure editor
like this in which the indentation is only for display, that's not a problem.

~~~
taliesinb
I elaborate a bit on this point in my comment below about Scratch. My claim is
that this 'pretty lisp' is still stuck in the flat-text mindset, doing
something pretty much identical to indenting. Whereas what we really want are
graphical (in the sense of network) editors.

~~~
shaunxcode
One of my "if I didn't have 30 other projects" projects is a minecraft type
environment meets scratch event model/"build your own block" style system. Let
kids interactively script their 3d world (and not just w/ redstone hah, not
that there isn't something awesome about kids rediscovering logic gates from
first principals!)

~~~
__david__
That's very funny you should mention it--that's been on my list lately as
well. I have a nephew that I'd love to teach programming to--he's 9 and loves
Minecraft beyond all rationality. I think a simple python/ruby/javascript
meets minecraft where you can do simple apple-2 style graphics
(material=green_wool; place_block_at 10,10,10) would turn him into a
programmer for life.

~~~
shaunxcode
You may want to look into "computercraft"
[http://www.minecraftforum.net/topic/892282-11-computercraft-...](http://www.minecraftforum.net/topic/892282-11-computercraft-13/)
which you can add right now! But I agree it needs to be more than just a
terminal - it needs to have the feeling of crafting/building structures. Even
if you could "zoom in" with a crafted microscope or something and then create
circuits which you can then connect to larger sensors/peripherals.

------
dfan
It is odd that in the third screenshot there is no visual differentiation
between the true and false blocks of an if statement. That's one place where I
still kind of regret the genericness of Lisp syntax.

Perhaps place a green outline around the true block, a red outline around the
false block (if any), and indent them both slightly or otherwise connect them
to the predicate block so that the connections are clear.

Of course one issue with treating constructs like if specially is that in Lisp
you can create your own macros that act just like if but then don't get the
special visual treatment.

~~~
jrockway
Emacs indents the true and false forms differently:

    
    
        (if (foo-condition-p)
            bar  ;; then
          baz    ;; else
          quux)  ;; else
    

You can also declare the indentation style of arbitrary macros, ensuring that
"if" is not just some special case.

~~~
simonb
This is an emacs lisp-only convention, most likely stemming from the fact that
elisp allows multiple else forms (most other lisps don't, which at least for
me also solves the problem of visually parsing ifs).

------
webjprgm
Yuck. The parenthesis are much easier to read than the boxes with lots of
padding. Only useful for beginning programmers. Anyone using lisp-based
languages will quickly be able to read parens easier.

(Plus some IDEs have coloring based on matching parens and depth, like
Racket's IDE, which keeps the same lisp code structure but adds subtle visual
enhancements.)

~~~
lurker17
the ovals are far too deeply colored. If they were closer to invisible
(especially the horizontal segments) it wouldn't be so bad.

and the linebreak between "defun" and "hello" is just wrong. "hello" should be
colored, and "defun" should be desaturated.

------
spitfire
I've been wanting this sort of thing for ages. Considering how sophisticated
we think we are, how the hell are we still using tools like emacs, or even VS
on a daily basis?

We should be indistinguishable from magic by now. This is a (small) step in
the right direction.

Can we please live in the future already?

~~~
ken
I've given this a lot of thought, because I'm working on a couple of vaguely
similar projects. My conclusion so far is that pretty-printing is great, but
enforcing structural constraints in the editor (beyond perhaps something like
ParEdit) tends to cause more trouble than it's worth.

Consider the transformations you might do on a piece of source code while
you're playing around. A lot of these (for me, anyway) are things which change
not just position or name, but the part-of-speech of words, or temporarily
make a nonsensical expression. (I do it in my shell a lot, too.) Rigid
structure-enforcing editors hinder this.

So for Lisp, either you end up with something that's less useful than Emacs,
or something that's just a thin display layer on s-exps (which is fine, but
not game-changing) and then users have to understand s-exp editing anyway. The
fact that the names of special forms, functions, and variables are all symbols
in Lisp is not mere coincidence.

This highlights one of the big frustrations I have with most programming
languages: they optimize for making a section of code look good and concise,
but as a programmer I want a language that also optimizes for my _changes_
being concise. For example, C# can look pretty decent in many cases, but
changes which are conceptually simple can be huge diffs. Quoting an expression
in Lisp is literally one character, but it takes 5 lines to quote a print
statement in C# <[http://msdn.microsoft.com/en-
us/library/y2k85ax6.aspx>](http://msdn.microsoft.com/en-
us/library/y2k85ax6.aspx>), and anything nontrivial grows painfully fast. This
is why it's impossible for me to truly assess something by looking at sample
code, or a screenshot -- so don't take this as a criticism of Pretty Lisp!

It could be that as we move higher up the abstraction scale this becomes less
important. After all, Mel wouldn't be happy at such a high level as
"characters". But I think there's something fundamental about the concept of
quoting symbols -- 'using something as something else' -- whether those
symbols are bits or characters or round-rects. The #' in the screenshot here
looks out of place, as if the author didn't know quite what to do with it.

I look forward to see what the author can make of this (new ideas and
experimentation are great!) but I don't see anything here yet that jumps out
at me as revolutionary, or must-have functionality.

~~~
timmy-turner
> Consider the transformations you might do on a piece of source code while
> you're playing around. A lot of these (for me, anyway) are things which
> change not just position or name, but the part-of-speech of words, or
> temporarily make a nonsensical expression. (I do it in my shell a lot, too.)
> Rigid structure-enforcing editors hinder this.

I hope that this can be mitigated by using an incremental parser (pretty easy
to write for a lisp), which gracefully switches to a plaintext representation
if the underlying code cannot be parsed anymore. The advantages of an editor
which understands the code (both, syntax and simple semantics) you are writing
or reading are just too promising.

~~~
doty
I worked on a language once (now dead) which even had a syntactically valid
form for parse errors, which allowed a structured editor to record a valid AST
at all times. The "parse error" expression just raised a "parse error"
exception at runtime, so you could even execute ill-formed expressions.

It turns out to be fantastically empowering.

~~~
spitfire
Which language?

~~~
doty
<http://en.wikipedia.org/wiki/M_(programming_language)>

------
gnosis
Am I just being a grumbly old man by preferring a decent editor like vim (or
even emacs) over this?

I don't begrudge anyone who likes that kind of "web 2.0" bubbly aesthetic. But
it's just not for me.

~~~
agumonkey
More than the css theme-ing (which is suboptimal IMNSHO), I think it the
reification of lists that is interesting. You're not manipulating a caret in a
stream of characters, you're pointing at ~objects.

------
Arelius
This is real neat, but expecting programmers to make such a large jump so
quickly is a bit unrealistic.

My best suggestion is to integrate this well with programers existing editors,
open a socket from an Emacs instance and use this as visualization. You will
get much better traction that way.

~~~
DanI-S
This is probably the most significant comment in the thread. Most people are
pretty entrenched; they will be much more willing to try a new tool if it can
fit it in with their existing workflow.

This applies to pretty much every problem out there, really.

~~~
Arelius
Point in case: See Google Wave. Wave was, in most every way better than email
(To some level of debate) except for the fact that it wasn't email, and
refused to have any sort of cooperation with email.

~~~
webjprgm
[off topic]

Wave was too complicated and did not integrate into everyone's existing mail
clients.

I had a professor that tried to use if for class lecture notes. That only
lasted a couple weeks.

A lunch group at work used it successfully for deciding where to go, until it
was shut down last month.

~~~
Arelius
> Wave was too complicated and did not integrate into everyone's existing mail
> clients.

This is exactly the point, people were to entrenched with email, Wave was
trying to kill email simply by being better than it.

------
gt384u
Something I'd be curious to hear from the pretty lisp designers: what
advantages do you feel this offers over an Emacs which just highlights the
symbol of interest or region between the matched parens for a particular code
block?

By way of context, I was a test subject for a perhaps related project called
Code Bubbles <http://www.andrewbragdon.com/codebubbles_site.asp> a while ago.
Since it was for Java, a language which is comparatively verbose and I often
have difficulty getting decent code density with, this new IDE interaction was
truly novel and I found often useful.

I test drove the Pretty Lisp Demo and felt myself wanting for code density in
a language where I don't typically have those issues. It was just too hard to
fit a useful quantity of code in a screen.

~~~
tincholio
> what advantages do you feel this offers over an Emacs which just highlights
> the symbol of interest or region between the matched parens for a particular
> code block?

This already exists: <http://www.foldr.org/~michaelw/emacs/mwe-color-box.el>

(you can see a screenie in <http://www.foldr.org/~michaelw/emacs/color-
box.png>)

~~~
gt384u
Thank you. I knew that it was an editor feature I'd seen before for lisp code,
but didn't recall the name of any one in particular.

~~~
tincholio
You're welcome! I don't know how useful it is in practice. I myself don't mind
the parens as long as I can see them match.

------
mark_l_watson
Nuno did a nice job implementing this, but as an old(er) Lisp'er I like
normally indented Lisp code (in Emacs, IntelliJ with Clojure plugin, etc.)
After looking at parenthesis for over 30 years, I am used to them :-)

Still, a neat idea.

------
fractallyte
Here's an interesting discussion of a s-expression editor:
[http://alan.dipert.org/post/445462664/the-s-expression-
edito...](http://alan.dipert.org/post/445462664/the-s-expression-editor) (and
a follow-up post: [http://alan.dipert.org/post/17375691572/structural-
editing-r...](http://alan.dipert.org/post/17375691572/structural-editing-
redux)).

The above article refers to Interlisp (also mentioned elsewhere in this
discussion), which still(?) survives in the form of Medley (<http://www.venue-
medley.com/>). (I emailed Jill Sybalsky a few months back, but following the
death of her husband, the product's future is rather uncertain...)

I came to Lisp from Smalltalk, so I'm already spoiled, having used the best
IDE ever (hey, it's not just me: <http://onsmalltalk.com/aha-moments-in-
lisp>); adapting to Emacs/SLIME was quite an interesting contrast.

OpenGenera was a step in the right direction: a LispVM + LispOS which together
created a very Smalltalk-like IDE. (The notion of 'synergy' has real meaning
here!) Developing a modern version of this further with ideas for structural
editing of s-expressions would be _quite_ interesting...

But, of course, talk is cheap ;-)

------
mtraven
Been done and a long time ago: see Boxer:
<http://www.mathedpage.org/t-and-m/turtle-and-mouse.html>

Not to mention the BioBike VPL:
<http://nar.oxfordjournals.org/content/37/suppl_2/W28>

Not that there's anything wrong with reinventing the recursively nested
rectangular wheel.

------
brlewis
This graphical representation of code structure seems reminiscent of
<http://scratch.mit.edu/>

~~~
taliesinb
The problem with scratch is that code visualization kinda dies on the vine for
procedural programs.

For pure functional languages, each chunk of code is a world unto itself, and
one can exploit this to make "visual proximity" correlate with "causal
proximity". This is good for our eyes and brains because we don't have to look
far to understand what is going in a certain part of a program.

The underlying reason this can work is that functional languages tightly
couple syntactical proximity and causal proximity _by design_.

Because of hidden state, procedural languages can't. Instead, they have a
tight mapping between syntactical proximity and _temporal_ proximity (think
back to BASIC and its line-numbers, which almost look like time-stamps).

Now, flat text source files aren't _bad_ at preserving causal locality for
functional languages. But because an intervening sub-expression can cause two
parts of the same s-expression to be really far apart in a source file, they
aren't great either.

We use indenting and code folding as a cue to mitigate this problem, but these
techniques are really just telling us that flat text is the wrong medium to
represent ASTs. Serializing a syntax tree to a string of characters will
always spoil the party.

In theory, graphical code presentations can do better because they have an
extra dimension to play with, so they can achieve the mapping from syntactical
proximity to visual proximity more faithfully.

However, this 'pretty lisp' project doesn't do that. It's just another form of
indenting. In a sense it is still stuck in the flat-text mindset.

I should mention I've done a bit of playing around of my own, though I haven't
seriously tried to solve the graphical-AST challenge yet:

<http://taliesinb.net/the-structure-of-a-mathematica-package>
<http://taliesinb.net/quicksort-in-61-characters>

------
pshc
Looking sweet. The future is in structural editors. The client-server
separation is a nice bonus.

Unfortunately this is running up against the UI problem. How do you make this
intuitive and powerful? A lot of hard work on usability is needed to get up to
par with text editors. Very glad to see it being tackled.

~~~
pavelludiq
In the lisp universe the future was in the 80's, thats when we tried the whole
"structural editors" idea and concluded that they didn't work out as nicely as
we hoped. I believe the sgml people tried them too, with poor results as well.

~~~
calibraxis
Sounds unlikely. May I ask what experience you had with 1980's structure
editors (presumably Interlisp)? My reading of history is that it wasn't
rejected by users, but rather killed off by MacLisp implementors teaming up to
create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to
consolidate Lisp).
([https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...](https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2SYUk/EoSmODsX7WgJ))

Paredit, a favorite among modern Lisp users, was directly inspired by
Interlisp's structure editing. Paredit's own author calls it a "cheesy
imitation" of Interlisp. (<http://mumble.net/~campbell/emacs/paredit.credits>)

Personally, I think Lisp is ripe for many different visual/kinesthetic
interpretations, and this one certainly is pretty.

~~~
sedachv
Paredit is nice, but barely works for stock Lisp syntax. One of the best
things about Common Lisp is reader macros, and in order to integrate them with
structured editing, you'd need to change the reader macro mechanism to be
based around a composable context-free grammar description that can be shared
between the reader and the structure editor. I'm pretty sure that's still an
open research problem.

Personally I think structured editing is an idea that seems great until you
actually try it.

~~~
calibraxis
At least among the Emacs-using Common Lisp users I've known (and discussed the
topic with), Paredit is considered a clear win. Same in my experience. What do
you use? If there's something better, I'd be happy to use it.

(When I last observed someone editing Common Lisp code without turning on
Paredit, it was rather depressing, how much time he spent closing parens and
re-indenting everything. But maybe you use something else which avoids this
problem?)

Reader macros (in the worst-case scenario you describe) are a very rare use-
case, and therefore probably not worth optimizing an IDE for. Perhaps for you
they're common, but I'm virtually certain that most Common Lisp users have
never written even one. If macros are already uncommon to write, reader macros
have a far higher bar of justification.

~~~
sedachv
I started using Paredit in 2010, and wrote Lisp in Emacs for 7 years before
that. Paredit make some things very convenient, but I can't say it has sped up
my programming significantly. It has made it a lot more convenient for me to
use the REPL, which has changed my programming style.

Two things that save time when indenting code and work in all Emacs
programming modes:

1\. (global-set-key (kbd "RET") 'newline-and-indent) in .emacs to
automatically indent every newline (also points out problems in your syntax
right away)

2\. C-Space to start region selection, C-M-b or C-M-f to jump back/forward a
code block (s-exp), then C-M-\ to reindent region.

The other thing I use is my <https://github.com/vsedach/mouse-copy> mode for
"structured" copy and paste. It's convenient sometimes.

I use reader macros a lot more than Common Lisp programmers do now, and I
encourage people to use them and think that reader macro usage will become
more widespread, in particular due to Tobias Rittweiler's named-readtables
library (<http://common-lisp.net/project/named-readtables/>).

In particular, I use cl-interpol (<http://weitz.de/cl-interpol/>) both for
string interpolation and to do HTML templating
(<http://paste.lisp.org/display/118522>). I also wrote a uri-temple library
for Common Lisp (<http://common-lisp.net/project/uri-template/>). When I used
CL-SQL, I used its reader macro syntax, and I thought it was worthwhile, but
could have been better designed.

------
abecedarius
Boxer looked like this, though less on the ugly side, to my taste.
Unfortunately it's so dead now I couldn't even find screenshots off the first
couple of search results.

<http://edutechwiki.unige.ch/en/Boxer>

------
eta_carinae
There are much less distracting ways than thick rounded boxes to indicate
indentations, starting with simple spaces.

A lot of Lisp programs look a lot better if you apply Python's space
indentation for sexprs, for example.

------
madhadron
The boxes seem to be an unstable medium between the stable points of
S-expressions and indentation as nesting. If there are lots of nested
expressions, you either push them to multiple lines and it becomes
indentation, or you keep them on one line and the top and bottom boundaries of
the boxes run together until you effectively have parentheses.

Have you looked at Chuck Moore's ColorForth, though? It might be a neat
direction to take this in.

------
trengof
I love this idea. My knowledge of lisp is very basic but I wonder if optional
declarations could be added to functions: e.g. f(Number) -> (Number,Number)
(sort of similar to haskell) and then these could be used in the pretty
printing / presentation layer. This would help lisp from missing those
implicit clues that are present in other languages without compromising its
flexibility.

------
agumonkey
Flip the keymap, I mean remove the prefix, especially in a browser where C-x
becomes C <pause> x .. it negates the benefits of structural edition.

So intercept all keys, and make it vim like (i know i know, don't bite me), it
will make it even more (touchtypist)DSL-like. btw , why not use <tab> for new
element insertion ( cons cell )

anyway, keep digging, it's the one true path ;)

/me going back to reading 'On Lisp'

------
strags
What you gain in "readability" here (debatable), you lose in terms of screen
real-estate efficiency. The last screenshot has a function filling the entire
screen that would, under ordinary circumstances, occupy about ten lines of
code.

You're going to get frustrated having to page up and down continually in order
to understand any remotely complex function.

------
ufo
The demo only works on chrome :(

------
dwyer
Interesting. I've often read discussions about how S-expressions could be made
more readable. I never contribute much to such discussions because I've never
had a problem with S-expressions. This is a neat idea though.

------
HarrietTubgirl
Neat idea, although to be fair the examples are straw men. I think most people
would indent their LISP much more readably.

------
bsmith
Great idea.

I've thought of doing something similar for an HTML editor, because—like with
Lisp—the nesting can become a nuisance.

------
CoffeeDregs
Nice. Gotta admit that I was slightly disappointed that the client-side JS
didn't appear to be ClojureScript or some lispy-script generated...

The application seems like a very good place to do Lisp-everywhere. In
particular and because of the ability to modify the interpreter, it would be
awesome to be able to use pretty-lisp client to edit the server-side code and
see immediate changes.

------
jorgem
PrettyLisp.com is available.

------
leeoniya
why only chrome?

------
helveticaman
Sacrilege!

------
vinodkd
every time I see such a project show up I'm both happy and sad: happy to see
one more soul arrive at the "there must be something better than text" thought
and doing something about it; sad because they invariably create a
visual/structural editor.

... and not a really good one, at that. Not to pick on this specific one, but
if you're creating a UI for code editing that's not text, please design your
interaction well. And yes, I know that this is probably version 0.1 and you
plan to smoothen the rough edges, which is why i'll not pick on the fact that
the editor for each structural element is not even in-place, for example.
</end snarkiness>

but that's not my point. writing code as text conflates two things (or 4,
depending on how you think of duals):

1\. source text has both syntax and meaning.

2\. source text is both the display and storage format (this is the killer
feature/bug).

my point is that every attempt to "solve" the "problem of coding using text"
(on in this case the subset of lisp's umpteen parens getting in the way of
understanding) focuses on the first half of #1 above.

as others have mentioned, there have been structural editors since the 80s.
from the research i did (admittedly with limited acm access) they seemed to
have died down due to two problems:

1\. the scale problem: text packs the largest amount of information into the
smallest amount of space. any visual/structural system better have a good way
of dealing with large codebases.

2\. the fluid use problem: it looks good, but is it easy to use when editing
anything but a small enough piece of code this way? typically the amount of
interaction "work" you have to do to jump between elements and so forth makes
it very inefficient compared to text. the commonly cited example was "How do
you change a for loop to a while?". in any text editor, you can take the
characters apart easily to reform them into some other construct, but in a
structural editor, you have to actually delete all or most of the old
structure and re-form the new one. i did find research that refuted this
specific claim (ask if interested), but that didn't help the adoption.

i have been thinking of "better ways to code" and structural editors in
particular for about 3 years now and here're some of my conclusions to date:

1\. text is king because of its universality - think cypher from the matrix
saying "I don't even see the code. All I see is blonde, brunette, red-head"

2\. We already have good structural editors. They're called vim and emacs. vim
has the better interaction model, imo, while emacs has better support for
creating new language modes (again, imho, no flame war intended). then there's
the smalltalk ides that inspired the Visual Age products that inspired
eclipse.

3\. The additional overload of "chrome" in text the {}'s, ()'s and begin/ends
are much less a hassle than that caused by a visual editor's chrome.

4\. There is much more value in pursuing better ways of coding than just
flogging the "text sucks" meme. Think Non-textual language workbenches, for
example.

Finally, one specific commment about playing around with lisp's syntax. I've
tried it (<https://github.com/vinodkd/lispdown>) and the one thing that stands
out is: Lisp has no syntax, so it can _become_ any syntax. I dont know how any
structural editor can handle that in a meaningful way.

