16 ms·

Pretty Lisp

170 points by fogus 15y ago

spitfire 15y ago
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?
- jsmcgd 15y ago
  Seconded. I made some designs for a graphical IDE like this years ago, but only on paper. I'm very happy to see someone else has done the hard work for me! I hope they'll support other languages too.
  - spitfire 15y ago
    It's funny, more and more I'm moving my work to Mathematica because it works sort of like this already. That, and it's as far along the power curve from python/ruby as python/ruby is from C.
    - Arelius 15y ago
      What kind of work do you do? Moving the work from what language? Do you not worry about having to pay huge licensing fees to run your code elsewhere?
      - spitfire 15y ago
        Executive brief - Go high end, where the money is. Where results are valued. 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.
        Arelius 15y ago
        This sounds like the kind of work that most people I know would choose matlab for (image segmentation). I personally have never used either for such, but do you have any thoughts on the matter? Is Mathematica getting better at the things matlab used to be best at?
        spitfire 15y ago
        It sort of comes down to what you're comfortable with. In this case, the strict image analysis parts were more minor compared to the real work. Also, Matlab seems to be stagnating, while Mathematica has been growing by leaps and bounds. Also, matlab doesn't have built in functionality for gui building, afaik. 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.
        taliesinb 15y ago
        I think most people you are know are just ignorant of how much better Mathematica is. It's okay. People like to stick to what they know.
        Arelius 15y ago
        Being more of a software engineer than a mathematician, and having no MatLab experience, and more basic Mathematica experience. That is, in fact, the the impression that I get. But I still see people using MatLab what seems like more often, and have no weight to backup my claim. I suppose I could learn both and do research, but in general, that seems so less important than getting actual work done. 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.
    - taliesinb 15y ago
      One neat thing about working with Mathematica in Eclipse is that successive clicking expands your selection 'outwards' up the syntax tree. It's an quite astoundingly useful feature for refactoring. I'm sure some LISP editors have this too, but in a m-expression language like Mathematica it seems like magic.
      - spitfire 15y ago
        Are you talking wolfram workbench or eclipse? (I don't have workbench). If eclipse has mms support I'll be trying that out tonight.
        taliesinb 15y ago
        Ah, my bad. You can install it as an Eclipse plugin, but that seems to require access to an internal server. So guess you're stuck with the Workbench, our branded version of Eclipse, which requires "premier service". Sorry!
        spitfire 15y ago
        Yeah. I don't have premier service. (When it says "call for quote" I leave) I'm guessing you work for wolfram? Is there a demo available somewhere?
      - gsg 15y ago
        When I was first learning elisp, one of the utilities I wrote was a flood-selection feature that sounds very similar to what you describe. Interestingly, it turned out to be quite useful in C code despite only being aware of string and paren (and brace and bracket) boundaries.
    - rwallace 15y ago
      I've heard Mathematica praised before, but not in precisely those terms - I was under the impression it was more a DSL for mathematics. Can you give a few examples of things it can do that put it that far along the power curve relative to Python/Ruby?
      - taliesinb 15y ago
        Well, Wolfram|Alpha. I switch from computer vision to parsing to machine learning on a daily basis. But I haven't used the workhorse mathematics functions like Solve or Integrate in 3 years. Perhaps it would be better to call it a 'Domain General Language' for everything.
  - zokier 15y ago
    Have you seen Code Bubbles? http://www.andrewbragdon.com/codebubbles_site.asp http://www.andrewbragdon.com/codebubbles_site.asp
- tikhonj 15y ago
  Emacs is already indistinguishable from magic :). 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.
  - Arelius 15y ago
    Yes, not having that feature is a bit perplexing, I already have emacs do something similar with font-lock. Among others, lambda gets replaced with λ.
  - Vivtek 15y ago
    Oh, that's a nice idea. I have to admit that the boxes don't do much for me, but symbols would make it easier to see what's where.
- tincholio 15y ago
  Because Emacs (and Vim, but when talking LISP, especially Emacs) is already magic. The visualization proposed is nifty, but it's hard to beat Emacs for any code editing, let alone for LISP. Also, check this out: http://www.foldr.org/~michaelw/emacs/mwe-color-box.el 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.foldr.org/~michaelw/emacs/color-box.png)
  - colonel_panic 15y ago
    Now I'm disturbed by the lack of parens. What about situations where I have one pair of parens exactly contained in another, like in a one-argument defmethod? 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.
    - simonb 15y ago
      (setq mwe:color-box-hide-parens nil)
- pnathan 15y ago
  I have written some amount of Lisp - at this point in the 5-10KLoC range, and I don't think this tool is a great editor. However, it's one of the more useful code/program visualizations I've come across.
- ken 15y ago
  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.
  - ken 15y ago
    I guess that sounds like kind of a downer (even though I said I liked experimentation and didn't want to make it sound like criticism of this particular implementation). I think there are definitely paths forward here, and my hunch (which you shouldn't listen to, because I don't know anything) is that the most promising one would be some combination of some/all of: - 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.
- jimbokun 15y ago
  When you want to write an essay, do you use something that draws your essay as some complex graphical representation, or do you use something like Word or a text editor, that for the most part shows your essay as just a bunch of boring characters on the screen? 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.
  - Detrus 15y ago
    We have the systems we have now because we used the same medium for thousands of years. To create new expressive mediums that take advantage of computers will take careful design and iteration, just as alphabetic text went through various handscripts like cursive, torturous to read German blackletter http://en.wikipedia.org/wiki/Blackletter http://en.wikipedia.org/wiki/Blackletter and settled on http://en.wikipedia.org/wiki/Roman_type http://en.wikipedia.org/wiki/Roman_type 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 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 http://news.ycombinator.com/item?id=3633740 and http://news.ycombinator.com/item?id=3651257 http://news.ycombinator.com/item?id=3651257
    - jimbokun 15y ago
      Yes, to be more clear, I should have said all the attempts to replace code with some kind of a graphical representation, ends up reducing expressiveness. Augmenting the text with graphical representations is a wonderful idea, that IDEs already perform in many ways, with many more yet to be discovered.
- el_presidente 15y ago
  We switched from graphics to text a couple of thousand years ago and it's helped us a lot. People have been killing the command line for decades, yet anyone who uses a search engine is working with a cli.
brlewis 15y ago
This graphical representation of code structure seems reminiscent of http://scratch.mit.edu/ http://scratch.mit.edu/
- taliesinb 15y ago
  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/the-structure-of-a-mathematica-package http://taliesinb.net/quicksort-in-61-characters http://taliesinb.net/quicksort-in-61-characters
  - deleted 15y ago
    [deleted]
Arelius 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      [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 15y ago
        > 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 15y ago
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 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 15y ago
  > 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 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.foldr.org/~michaelw/emacs/color-box.png)
  - jamesgeck0 15y ago
    That is extremely shiny. Can I get that in Vim?
    - gnosis 15y ago
      Well, this is not quite the same, but you can get indent-level highlighting in vim via these sorts of plugins: http://www.vim.org/scripts/script.php?script_id=3361 http://www.vim.org/scripts/script.php?script_id=3361 http://www.vim.org/scripts/script.php?script_id=1800 http://www.vim.org/scripts/script.php?script_id=1800 Some screenshots: http://nathanaelkane.imgur.com/indent_guides http://nathanaelkane.imgur.com/indent_guides http://viming.blogspot.com/2007/02/indent-level-highlighting.html 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 There should also be some way to get background highlights based on sexpr's instead of just indent level, but I haven't personally seen it. 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. [1] - http://www.vim.org/scripts/script.php?script_id=2531 http://www.vim.org/scripts/script.php?script_id=2531
pshc 15y ago
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.
- CoffeeDregs 15y ago
  > The future is in structural editors. 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.
  - pshc 15y ago
    EastWest is one that comes to mind. I aim to write one, but that's a long time coming.
  - rsl7 15y ago
    I used one called Genie Pascal in 1988, out of CMU, on the Mac Plus. They did lots of work on supporting various languages. http://www.cs.cmu.edu/~pane/ile.html http://www.cs.cmu.edu/~pane/ile.html
- pavelludiq 15y ago
  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 15y ago
    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/Llmnxk2SYUk/EoSmODsX7WgJ https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...) 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 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.
CoffeeDregs 15y ago
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.
ufo 15y ago
The demo only works on chrome :(
dfan 15y ago
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.
- dfan 15y ago
  (Following on from the last paragraph) I guess the thing to do is to have a little DSL declaring how to prettyize any sort of block (which I assume already exists for this project to work at all), and then allow the user to customize it to add his/her own.
- jrockway 15y ago
  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 15y ago
    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).
dwyer 15y ago
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.
bsmith 15y ago
Great idea. I've thought of doing something similar for an HTML editor, because—like with Lisp—the nesting can become a nuisance.
mark_l_watson 15y ago
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.
agumonkey 15y ago
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'
gnosis 15y ago
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 15y ago
  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.
webjprgm 15y ago
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 15y ago
  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.
skeptical 15y ago
Looking good. I wouldn't want it as an editor, bt hey, what's with all the negative comments. This would be very to have a quick peek at a portion of code. It should be easy to integrate this with emacs so it can be displayed in an extra window while your active buffer runs your favorite mode. No? I have a vague memory of seeing something like this a fiew years ago, without the bubbly rounded corners look, but I recall a similar thing. Anyone?
leeoniya 15y ago
why only chrome?
abecedarius 15y ago
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 http://edutechwiki.unige.ch/en/Boxer
trengof 15y ago
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.
lambda 15y ago
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 15y ago
  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.
  - gringomorcego 15y ago
    Can you elaborate?
    - aristus 15y ago
      Not the gp, but I believe the idea is to stop displaying long columns of code like so much wallpaper and instead treat it like the directed multigraph it actually is.
      - ori_b 15y ago
        What does that mean? I can't think of any graph-editing GUI that I'd want to use to write code. There's a reason I still do my graphs in dot, and not in some WYSIWYG editor -- it's much easier to manipulate them.
strags 15y ago
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.
madhadron 15y ago
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.
HarrietTubgirl 15y ago
Neat idea, although to be fair the examples are straw men. I think most people would indent their LISP much more readably.
eta_carinae 15y ago
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.
jorgem 15y ago
PrettyLisp.com is available.
mtraven 15y ago
Been done and a long time ago: see Boxer: http://www.mathedpage.org/t-and-m/turtle-and-mouse.html 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 http://nar.oxfordjournals.org/content/37/suppl_2/W28 Not that there's anything wrong with reinventing the recursively nested rectangular wheel.
fractallyte 15y ago
Here's an interesting discussion of a s-expression editor: http://alan.dipert.org/post/445462664/the-s-expression-editor http://alan.dipert.org/post/445462664/the-s-expression-edito... (and a follow-up post: http://alan.dipert.org/post/17375691572/structural-editing-redux http://alan.dipert.org/post/17375691572/structural-editing-r...). 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/ 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 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 ;-)
vinodkd 15y ago
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 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.
helveticaman 15y ago
Sacrilege!

170 points by fogus 15y ago

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?

jsmcgd 15y ago
Seconded. I made some designs for a graphical IDE like this years ago, but only on paper. I'm very happy to see someone else has done the hard work for me! I hope they'll support other languages too.
- spitfire 15y ago
  It's funny, more and more I'm moving my work to Mathematica because it works sort of like this already. That, and it's as far along the power curve from python/ruby as python/ruby is from C.
  - Arelius 15y ago
    What kind of work do you do? Moving the work from what language? Do you not worry about having to pay huge licensing fees to run your code elsewhere?
    - spitfire 15y ago
      Executive brief - Go high end, where the money is. Where results are valued. 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.
      - Arelius 15y ago
        This sounds like the kind of work that most people I know would choose matlab for (image segmentation). I personally have never used either for such, but do you have any thoughts on the matter? Is Mathematica getting better at the things matlab used to be best at?
        spitfire 15y ago
        It sort of comes down to what you're comfortable with. In this case, the strict image analysis parts were more minor compared to the real work. Also, Matlab seems to be stagnating, while Mathematica has been growing by leaps and bounds. Also, matlab doesn't have built in functionality for gui building, afaik. 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.
        taliesinb 15y ago
        I think most people you are know are just ignorant of how much better Mathematica is. It's okay. People like to stick to what they know.
        Arelius 15y ago
        Being more of a software engineer than a mathematician, and having no MatLab experience, and more basic Mathematica experience. That is, in fact, the the impression that I get. But I still see people using MatLab what seems like more often, and have no weight to backup my claim. I suppose I could learn both and do research, but in general, that seems so less important than getting actual work done. 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.
  - taliesinb 15y ago
    One neat thing about working with Mathematica in Eclipse is that successive clicking expands your selection 'outwards' up the syntax tree. It's an quite astoundingly useful feature for refactoring. I'm sure some LISP editors have this too, but in a m-expression language like Mathematica it seems like magic.
    - spitfire 15y ago
      Are you talking wolfram workbench or eclipse? (I don't have workbench). If eclipse has mms support I'll be trying that out tonight.
      - taliesinb 15y ago
        Ah, my bad. You can install it as an Eclipse plugin, but that seems to require access to an internal server. So guess you're stuck with the Workbench, our branded version of Eclipse, which requires "premier service". Sorry!
        spitfire 15y ago
        Yeah. I don't have premier service. (When it says "call for quote" I leave) I'm guessing you work for wolfram? Is there a demo available somewhere?
    - gsg 15y ago
      When I was first learning elisp, one of the utilities I wrote was a flood-selection feature that sounds very similar to what you describe. Interestingly, it turned out to be quite useful in C code despite only being aware of string and paren (and brace and bracket) boundaries.
  - rwallace 15y ago
    I've heard Mathematica praised before, but not in precisely those terms - I was under the impression it was more a DSL for mathematics. Can you give a few examples of things it can do that put it that far along the power curve relative to Python/Ruby?
    - taliesinb 15y ago
      Well, Wolfram|Alpha. I switch from computer vision to parsing to machine learning on a daily basis. But I haven't used the workhorse mathematics functions like Solve or Integrate in 3 years. Perhaps it would be better to call it a 'Domain General Language' for everything.
- zokier 15y ago
  Have you seen Code Bubbles? http://www.andrewbragdon.com/codebubbles_site.asp http://www.andrewbragdon.com/codebubbles_site.asp
tikhonj 15y ago
Emacs is already indistinguishable from magic :). 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.
- Arelius 15y ago
  Yes, not having that feature is a bit perplexing, I already have emacs do something similar with font-lock. Among others, lambda gets replaced with λ.
- Vivtek 15y ago
  Oh, that's a nice idea. I have to admit that the boxes don't do much for me, but symbols would make it easier to see what's where.
tincholio 15y ago
Because Emacs (and Vim, but when talking LISP, especially Emacs) is already magic. The visualization proposed is nifty, but it's hard to beat Emacs for any code editing, let alone for LISP. Also, check this out: http://www.foldr.org/~michaelw/emacs/mwe-color-box.el 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.foldr.org/~michaelw/emacs/color-box.png)
- colonel_panic 15y ago
  Now I'm disturbed by the lack of parens. What about situations where I have one pair of parens exactly contained in another, like in a one-argument defmethod? 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.
  - simonb 15y ago
    (setq mwe:color-box-hide-parens nil)
pnathan 15y ago
I have written some amount of Lisp - at this point in the 5-10KLoC range, and I don't think this tool is a great editor. However, it's one of the more useful code/program visualizations I've come across.
ken 15y ago
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.
- ken 15y ago
  I guess that sounds like kind of a downer (even though I said I liked experimentation and didn't want to make it sound like criticism of this particular implementation). I think there are definitely paths forward here, and my hunch (which you shouldn't listen to, because I don't know anything) is that the most promising one would be some combination of some/all of: - 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.
jimbokun 15y ago
When you want to write an essay, do you use something that draws your essay as some complex graphical representation, or do you use something like Word or a text editor, that for the most part shows your essay as just a bunch of boring characters on the screen? 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.
- Detrus 15y ago
  We have the systems we have now because we used the same medium for thousands of years. To create new expressive mediums that take advantage of computers will take careful design and iteration, just as alphabetic text went through various handscripts like cursive, torturous to read German blackletter http://en.wikipedia.org/wiki/Blackletter http://en.wikipedia.org/wiki/Blackletter and settled on http://en.wikipedia.org/wiki/Roman_type http://en.wikipedia.org/wiki/Roman_type 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 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 http://news.ycombinator.com/item?id=3633740 and http://news.ycombinator.com/item?id=3651257 http://news.ycombinator.com/item?id=3651257
  - jimbokun 15y ago
    Yes, to be more clear, I should have said all the attempts to replace code with some kind of a graphical representation, ends up reducing expressiveness. Augmenting the text with graphical representations is a wonderful idea, that IDEs already perform in many ways, with many more yet to be discovered.
el_presidente 15y ago
We switched from graphics to text a couple of thousand years ago and it's helped us a lot. People have been killing the command line for decades, yet anyone who uses a search engine is working with a cli.

brlewis 15y ago

This graphical representation of code structure seems reminiscent of http://scratch.mit.edu/ http://scratch.mit.edu/

taliesinb 15y ago
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/the-structure-of-a-mathematica-package http://taliesinb.net/quicksort-in-61-characters http://taliesinb.net/quicksort-in-61-characters
- deleted 15y ago
  [deleted]

Arelius 15y ago

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 15y ago
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 15y ago
  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 15y ago
    [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 15y ago
      > 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 15y ago

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 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 15y ago
> 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 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.foldr.org/~michaelw/emacs/color-box.png)
- jamesgeck0 15y ago
  That is extremely shiny. Can I get that in Vim?
  - gnosis 15y ago
    Well, this is not quite the same, but you can get indent-level highlighting in vim via these sorts of plugins: http://www.vim.org/scripts/script.php?script_id=3361 http://www.vim.org/scripts/script.php?script_id=3361 http://www.vim.org/scripts/script.php?script_id=1800 http://www.vim.org/scripts/script.php?script_id=1800 Some screenshots: http://nathanaelkane.imgur.com/indent_guides http://nathanaelkane.imgur.com/indent_guides http://viming.blogspot.com/2007/02/indent-level-highlighting.html 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 There should also be some way to get background highlights based on sexpr's instead of just indent level, but I haven't personally seen it. 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. [1] - http://www.vim.org/scripts/script.php?script_id=2531 http://www.vim.org/scripts/script.php?script_id=2531

pshc 15y ago

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.

CoffeeDregs 15y ago
> The future is in structural editors. 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.
- pshc 15y ago
  EastWest is one that comes to mind. I aim to write one, but that's a long time coming.
- rsl7 15y ago
  I used one called Genie Pascal in 1988, out of CMU, on the Mac Plus. They did lots of work on supporting various languages. http://www.cs.cmu.edu/~pane/ile.html http://www.cs.cmu.edu/~pane/ile.html
pavelludiq 15y ago
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 15y ago
  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/Llmnxk2SYUk/EoSmODsX7WgJ https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...) 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 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.

CoffeeDregs 15y ago

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.

ufo 15y ago

The demo only works on chrome :(

dfan 15y ago

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.

dfan 15y ago
(Following on from the last paragraph) I guess the thing to do is to have a little DSL declaring how to prettyize any sort of block (which I assume already exists for this project to work at all), and then allow the user to customize it to add his/her own.
jrockway 15y ago
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 15y ago
  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).

dwyer 15y ago

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.

bsmith 15y ago

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

mark_l_watson 15y ago

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.

agumonkey 15y ago

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'

gnosis 15y ago

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 15y ago
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.

webjprgm 15y ago

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 15y ago
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.

skeptical 15y ago

Looking good. I wouldn't want it as an editor, bt hey, what's with all the negative comments. This would be very to have a quick peek at a portion of code. It should be easy to integrate this with emacs so it can be displayed in an extra window while your active buffer runs your favorite mode. No? I have a vague memory of seeing something like this a fiew years ago, without the bubbly rounded corners look, but I recall a similar thing. Anyone?

leeoniya 15y ago

why only chrome?

abecedarius 15y ago

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 http://edutechwiki.unige.ch/en/Boxer

trengof 15y ago

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.

lambda 15y ago

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 15y ago
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.
- gringomorcego 15y ago
  Can you elaborate?
  - aristus 15y ago
    Not the gp, but I believe the idea is to stop displaying long columns of code like so much wallpaper and instead treat it like the directed multigraph it actually is.
    - ori_b 15y ago
      What does that mean? I can't think of any graph-editing GUI that I'd want to use to write code. There's a reason I still do my graphs in dot, and not in some WYSIWYG editor -- it's much easier to manipulate them.

strags 15y ago

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.

madhadron 15y ago

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.

HarrietTubgirl 15y ago

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

eta_carinae 15y ago

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.

jorgem 15y ago

PrettyLisp.com is available.

mtraven 15y ago

Been done and a long time ago: see Boxer: http://www.mathedpage.org/t-and-m/turtle-and-mouse.html 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 http://nar.oxfordjournals.org/content/37/suppl_2/W28 Not that there's anything wrong with reinventing the recursively nested rectangular wheel.

fractallyte 15y ago

Here's an interesting discussion of a s-expression editor: http://alan.dipert.org/post/445462664/the-s-expression-editor http://alan.dipert.org/post/445462664/the-s-expression-edito... (and a follow-up post: http://alan.dipert.org/post/17375691572/structural-editing-redux http://alan.dipert.org/post/17375691572/structural-editing-r...). 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/ 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 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 ;-)

vinodkd 15y ago

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 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.

helveticaman 15y ago

Sacrilege!