Comment by lambda | Hacker News Reader

Comment by lambda | Hacker News Reader

Parent Full thread

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.

Parentheses highlighting is only a half-solution -- I don't know if there's a Vim equivalent, but you could check out Paredit for Emacs.

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.

There's a plugin for rainbow parens.

http://www.vim.org/scripts/script.php?script_id=1230

> Even in Lisp, some sacrifices have to be made.

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.

It isn't a huge leap forward conceptually, but the boxes to show scope are a whole lot faster for me to read than counting parentheses.

Can you elaborate?

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.

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.

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.

Bingo.

It makes you wonder why we store code in linear text files, when something more similar to a database seems a bit more apt.

Reply on news.ycombinator.com