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.
> 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
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.
After spending time with Paredit, all other code editing always seems so woefully limited. Transpose, for instance becomes very powerful when we are talking about blocks of code rather than simple syntactical elements.
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.
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.
One of my "if I didn't have 30 other projects" projects is a minecraft type environment meets scratch event model/"build your own block" style system. Let kids interactively script their 3d world (and not just w/ redstone hah, not that there isn't something awesome about kids rediscovering logic gates from first principals!)
That's very funny you should mention it--that's been on my list lately as well. I have a nephew that I'd love to teach programming to--he's 9 and loves Minecraft beyond all rationality. I think a simple python/ruby/javascript meets minecraft where you can do simple apple-2 style graphics (material=green_wool; place_block_at 10,10,10) would turn him into a programmer for life.
You may want to look into "computercraft" http://www.minecraftforum.net/topic/892282-11-computercraft-... which you can add right now! But I agree it needs to be more than just a terminal - it needs to have the feeling of crafting/building structures. Even if you could "zoom in" with a crafted microscope or something and then create circuits which you can then connect to larger sensors/peripherals.
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.
I don't know. I don't think it exists yet. But have you ever seen an expert using etags/search/debugger/etc to bounce around a large codebase? The location of the functions in the file hierarchy doesn't matter at all. The important graph --the important graphs-- are latent in the code itself.
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.
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).
(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.
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.)
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.
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.
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.
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.
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>, 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.
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.
> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this.
I hope that this can be mitigated by using an incremental parser (pretty easy to write for a lisp), which gracefully switches to a plaintext representation if the underlying code cannot be parsed anymore. The advantages of an editor which understands the code (both, syntax and simple semantics) you are writing or reading are just too promising.
I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions.
You're absolutely correct. Right now we focus on moving text around. Where the magic will come in, as these sorts of things progress is developing interactions to move the ideas around. Moving further up the power curve is always a good thing.
My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.
We've done a lot of moving up the curve. Generally, when you move up the curve, there's a way to serialize it as text. Then, you might as well actually do so, and use all the advantages of a textual representation to use the abstraction. Compare a concise Haskell specification of something with the C equivalent.
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.
I think it is a lack of creativity. Also a lack of serious attempts and minimal refinement in successful attempts like labview.
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.
> Generally, when you move up the curve, there's a way to serialize it as text.
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.
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.
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 and settled on 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
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.
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.
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.
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.
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.
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.
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".
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
Something I'd be curious to hear from the pretty lisp designers: what advantages do you feel this offers over an Emacs which just highlights the symbol of interest or region between the matched parens for a particular code block?
By way of context, I was a test subject for a perhaps related project called Code Bubbles http://www.andrewbragdon.com/codebubbles_site.asp a while ago. Since it was for Java, a language which is comparatively verbose and I often have difficulty getting decent code density with, this new IDE interaction was truly novel and I found often useful.
I test drove the Pretty Lisp Demo and felt myself wanting for code density in a language where I don't typically have those issues. It was just too hard to fit a useful quantity of code in a screen.
> 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?
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.
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 :-)
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...
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:
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.
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.
Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). (https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...)
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.
I'm a lisp history nut, but I wasn't around at that time. Paredid doesn't really turn emacs into a structure editor, its more like a "standard editor with some of the better ideas of structure editors miked in" kind of mode. Structure editors introduce a lot of complexity in general. Maybe Interlisp was able to work well in practice despite the added complexity, I don't know, I really would like to know more about such systems.
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....
You might be interested in the debates between Stallman and Sandewall. It's in _Interactive Programming Environments_; Stallman took the side of text editing, and Sandewall took the side of structure editing. The book is maybe a good gift for Lisp history nuts, and it's only $3 used on amazon.com.
Paredit is nice, but barely works for stock Lisp syntax. One of the best things about Common Lisp is reader macros, and in order to integrate them with structured editing, you'd need to change the reader macro mechanism to be based around a composable context-free grammar description that can be shared between the reader and the structure editor. I'm pretty sure that's still an open research problem.
Personally I think structured editing is an idea that seems great until you actually try it.
At least among the Emacs-using Common Lisp users I've known (and discussed the topic with), Paredit is considered a clear win. Same in my experience. What do you use? If there's something better, I'd be happy to use it.
(When I last observed someone editing Common Lisp code without turning on Paredit, it was rather depressing, how much time he spent closing parens and re-indenting everything. But maybe you use something else which avoids this problem?)
Reader macros (in the worst-case scenario you describe) are a very rare use-case, and therefore probably not worth optimizing an IDE for. Perhaps for you they're common, but I'm virtually certain that most Common Lisp users have never written even one. If macros are already uncommon to write, reader macros have a far higher bar of justification.
I started using Paredit in 2010, and wrote Lisp in Emacs for 7 years before that. Paredit make some things very convenient, but I can't say it has sped up my programming significantly. It has made it a lot more convenient for me to use the REPL, which has changed my programming style.
Two things that save time when indenting code and work in all Emacs programming modes:
1. (global-set-key (kbd "RET") 'newline-and-indent) in .emacs to automatically indent every newline (also points out problems in your syntax right away)
2. C-Space to start region selection, C-M-b or C-M-f to jump back/forward a code block (s-exp), then C-M-\ to reindent region.
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/).
It is a huge UI problem. For example, it's tempting to start adding flashy chrome to a structure editor just because you can. Pretty Lisp's rounded rectangles are obviously not going to scale to real programs; they generate a lot of noise. Visually, an ideal structure editor looks a lot like the text-format code we have today for its readability.
There's a lot of usability failure in Lisp's history but I know that a great structure editor is possible.
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 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
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.
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.
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.
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 )
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.
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.
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.
every time I see such a project show up I'm both happy and sad: happy to see one more soul arrive at the "there must be something better than text" thought and doing something about it; sad because they invariably create a visual/structural editor.
... and not a really good one, at that. Not to pick on this specific one, but if you're creating a UI for code editing that's not text, please design your interaction well. And yes, I know that this is probably version 0.1 and you plan to smoothen the rough edges, which is why i'll not pick on the fact that the editor for each structural element is not even in-place, for example. </end snarkiness>
but that's not my point. writing code as text conflates two things (or 4, depending on how you think of duals):
1. source text has both syntax and meaning.
2. source text is both the display and storage format (this is the killer feature/bug).
my point is that every attempt to "solve" the "problem of coding using text" (on in this case the subset of lisp's umpteen parens getting in the way of understanding) focuses on the first half of #1 above.
as others have mentioned, there have been structural editors since the 80s. from the research i did (admittedly with limited acm access) they seemed to have died down due to two problems:
1. the scale problem: text packs the largest amount of information into the smallest amount of space. any visual/structural system better have a good way of dealing with large codebases.
2. the fluid use problem: it looks good, but is it easy to use when editing anything but a small enough piece of code this way? typically the amount of interaction "work" you have to do to jump between elements and so forth makes it very inefficient compared to text. the commonly cited example was "How do you change a for loop to a while?". in any text editor, you can take the characters apart easily to reform them into some other construct, but in a structural editor, you have to actually delete all or most of the old structure and re-form the new one. i did find research that refuted this specific claim (ask if interested), but that didn't help the adoption.
i have been thinking of "better ways to code" and structural editors in particular for about 3 years now and here're some of my conclusions to date:
1. text is king because of its universality - think cypher from the matrix saying "I don't even see the code. All I see is blonde, brunette, red-head"
2. We already have good structural editors. They're called vim and emacs. vim has the better interaction model, imo, while emacs has better support for creating new language modes (again, imho, no flame war intended). then there's the smalltalk ides that inspired the Visual Age products that inspired eclipse.
3. The additional overload of "chrome" in text the {}'s, ()'s and begin/ends are much less a hassle than that caused by a visual editor's chrome.
4. There is much more value in pursuing better ways of coding than just flogging the "text sucks" meme. Think Non-textual language workbenches, for example.
Finally, one specific commment about playing around with lisp's syntax. I've tried it (https://github.com/vinodkd/lispdown) and the one thing that stands out is: Lisp has no syntax, so it can become any syntax. I dont know how any structural editor can handle that in a meaningful way.
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.