Pretty Lisp
pretty-lisp.org
pretty-lisp.org
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.
There's a reason I still do my graphs in dot, and not in some WYSIWYG editor -- it's much easier to manipulate them.
I wouldn't call myself an experienced Lisp hacker, but I don't think the parentheses are visually distracting, any more than I think that the curly braces in C are distracting.
The only problem that I can really see with the parentheses-based S-expression syntax is the fact that it's not always immediately clear where a given S-expression begins and ends. This is a that's-a-feature-not-a-bug situation, though, because that visual ambiguity is a byproduct of the list-code symmetry that makes Lisp so powerful. This comes at the cost of some initial visual ambiguity. Even in Lisp, some sacrifices have to be made. The one thing that's a huge help, though, is Vim's auto-highlighting feature, which lets me know easily where the other half of a parentheses/brackets/etc. pair is. (This isn't unique to Lisp - it will do that for any open-close token pairs in any language).
Pretty Lisp seems to be an attempt to correct that more than it is an attempt to 'correct' the parentheses, which I view as a strength rather than a shortcoming of Lisp. A much simpler way to achieve that end goal would be to write a short Vim keybinding/plugin that would either automatically or manually (toggle on/off) highlight the entire function/list that the cursor is on, instead of just the opening and closing parentheses.
To me, that would be the best of both worlds, and it would probably be a very simple task for someone familiar with Vim configuration.
This makes me smile. It points out the concept that while Lisp, is in fact a programming language in that way that most are. After spending lots of time in it, it really can feel infinite in a way.
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.
(if (foo-condition-p)
bar ;; then
baz ;; else
quux) ;; else
(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.)
and the linebreak between "defun" and "hello" is just wrong. "hello" should be colored, and "defun" should be desaturated.
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?
Licensing isn't an issue - $3K/year+libraries for development. A runtime player for Mathematica costs $300. You just have to pick your projects carefully - No rails todo apps.
One recent project I worked on was auto segmentation and labelling of MRI images. Auto-segmentation was the easy part. Labelling however took several different approaches before I got something that works reliably.
A lot of my other work is much less suited to matlab. Mathematica is certainly much better for multi-domain work, which matlab barely supports.
One aspect that seems to be brought up about MatLab often is the community, it's often claimed, especially in the co punter vision world, that if an algorithm exists, it has an available implementation in MatLab source. Which seems significant.
I'm sure some LISP editors have this too, but in a m-expression language like Mathematica it seems like magic.
Sorry!
Is there a demo available somewhere?
Perhaps it would be better to call it a 'Domain General Language' for everything.
Seriously though, I actually prefer working with text, even here.
Also, I think this could be improved by making "meta" symbols like defun into different shapes rather than just including them as words. So a definition would look like a different box than a normal statement. Probably the same for &optional. Of course, this wouldn't work for user-defined macros or functions, but it would be nice if just for the standard ones.
Also, check this out: 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)
Edit: Now I see that I didn't notice that this situation happens in the "let maxcol 0" line in that image. I need to compare the colors on the line below to make sure I'm mentally parsing that line correctly.
However, it's one of the more useful code/program visualizations I've come across.
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>, 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.
- Not use Common Lisp as a base. Lisp is great, but reader macros and visualizations are a really tough combination.
- Come up with a good visualization for quoting. If your fundamental units of computation are "symbol/word" and "box" (a neat concept to build a language around), then incorporate quoting into those things somehow. I don't have a good answer for you here, but I think this is the key to unlocking the whole thing.
- Integrate with other tools (or upgrade them to this visual symbol/box world) that make good use of text today, like version control, sed/grep, or editor extensions (as in Emacs).
If there was a programming environment that offered the same level of flexibility and power that I have today, but which was visual (and beautiful), I could see that being a very compelling upgrade. I'm fascinated by visual languages, and I find it unfortunate that they all seem to acquire visuals by sacrificing power.
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.
It turns out to be fantastically empowering.
My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.
The problem with people who seek to replace our glorified text editors that we use for source code editing is not that they don't understand the disadvantages of the format... it is that they don't understand the advantages. Consequently, proposals for replacement tend to throw away huge swathes of functionality without realizing it, then start from a functionality deficit nearly impossible to recover from. It's actually hard to beat text. There's a reason we're communicating in text right now, and it isn't a lack of creativity or lack of attempts at other solutions to the problem or any of the other memes trotted out every time this topic comes up.
Take the simple case of naming. In plain text, the name of a function is its unique ID, more or less. Some language cultures love long descriptive names like BattleResourceMediator.getMediatorInstance(). Well such names can be broken up into tags. [Battle Resource] [Mediator].[get][Mediator][Instance]. Then when you don't need to know it's a mediator instance you'll see [Battle Resource].[get]. If you need to see what's a mediator and what's a factory, turn on some deeper editing mode and swim in verbose boilerplate.
You're not going far from text, just augmenting it with simple ideas we use in bookmarking. You can go further, add tags to sections of code to rate and label it as readable, hand optimized, quick & dirty, reviewed, etc. Simply a better UI for documentation, so in a zoomed out view of a project you can see at a glance how much is hand optimized.
Also watch this video https://vimeo.com/36579366 and notice the sorting code walkthrough. A simple case of refinement where you put output side by side next to the code and format it properly. We'll need a lot more refinements like this, which means more attempts, more creativity.
Agreed. I think this has something to do with the fact that programming is not about the objects on screen themselves, it's about the interaction that occurs between those objects and the mind of the person looking at them. The objects are not real, but mere representations.
Therefore, the interaction I have with a block of code is defined by my experience wrestling with the problem at hand in the language of that block, during which my brain has "mapped" from the text to a sort of abstract visualization of its value (or "serialized", as you put it).
I don't think a tool that makes a "picture-block" for me will ever help. My brain has to do the work of understanding those blocks by compressing each text block into a form (block? graph node? neither?) that I can hold in my head.
Strangely enough, if the above is correct, that means that there is more value in implementing a tool like this (for the implementor) in $LANGUAGE than there is for a potential user. Perhaps this is why programmers keep writing them, and users keep on not using them.
As the user, I need to learn something either way, and learning is usually hard/expensive. Therefore, why learn the (imperfectly-mapped) "picture-block" abstraction at all?
It'd be interesting to see if programmers feel the need to keep using these sorts of tools them once they've written them. My guess is no.
Sure, there may be some fonts and indentation and colors. (Eclipse and VS use those, too.) But the text is the point.
It's the same with code. Code is a means of expression, best treated as text. Every attempt at turning it into something graphical always reduces the expressiveness.
Then we went to san serifs (like here on HN) and then to monospaced code fonts. It's a long line and a lot of work by designers.
Adding to this medium will also take a lot of work. An essay can be more expressive when various ideas in it are turned into visualizations. Writers of long novels use special writer software to keep track of which characters interact with what others, to create family charts, friend charts, event timelines, etc.
These don't replace text, they augment it. And it would be interesting to have a macro view of the book through such tools for readers someday.
Not every attempt reduced the expressiveness of code. Syntax highlighting is graphical. Labview is graphical. Short compile cycles so the programmer can see what he's doing is graphical. Great demo of that here https://vimeo.com/36579366
Just because this particular attempt at pretty lisp leaves much to be desired doesn't mean we should stop attempting. Simple programmer tasks like naming can be improved if we move away from plain text as the medium, more detail here http://news.ycombinator.com/item?id=3633740 and http://news.ycombinator.com/item?id=3651257
Augmenting the text with graphical representations is a wonderful idea, that IDEs already perform in many ways, with many more yet to be discovered.
I don't begrudge anyone who likes that kind of "web 2.0" bubbly aesthetic. But it's just not for me.
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.
This applies to pretty much every problem out there, really.
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.
This is exactly the point, people were to entrenched with email, Wave was trying to kill email simply by being better than it.
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.
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)
http://www.vim.org/scripts/script.php?script_id=3361
http://www.vim.org/scripts/script.php?script_id=1800
Some screenshots:
http://nathanaelkane.imgur.com/indent_guides
http://viming.blogspot.com/2007/02/indent-level-highlighting...
Of course, you can also get rainbow parenthesis in vim via:
:let g:lisp_rainbow = 1
Edit: actually, come to think of it, I seem to recall hearing that the slimv[1] plugin can do this. But I haven't really played with it myself.
Seriously though, I wish that emacs put effort into a more modern rendering architecture. So that you could implement this sort of visualization in a more flexible way.
Pretty list still doesn't look very appealing to me. It doesn't help organize the code, all it does is replace parenthesis with visual boxes.
Still, a neat idea.
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 ;-)
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.
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
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.
I liked CodeBubbles, but do you have any other examples of structural editors for generic programming? Obviously, UI-centric editors and LabView are structural editors, but for very specific domains.
I aim to write one, but that's a long time coming.
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.
Personally I think structured editing is an idea that seems great until you actually try 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.
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.
As for your last sentence, Erik Naggum who had a bad opinion on structure editors in general, seems to have liked the idea of a structure inspector, as in using such tools to inspect code, ratter than create it: http://www.xach.com/naggum/articles/3064225496493947@naggum....
There's a lot of usability failure in Lisp's history but I know that a great structure editor is possible.
A lot of Lisp programs look a lot better if you apply Python's space indentation for sexprs, for example.
Have you looked at Chuck Moore's ColorForth, though? It might be a neat direction to take this in.
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'
You're going to get frustrated having to page up and down continually in order to understand any remotely complex function.
I've thought of doing something similar for an HTML editor, because—like with Lisp—the nesting can become a nuisance.
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.
... 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.