Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty Lisp

pretty-lisp.org

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Pretty Lisp

#51

Post by spitfire »

Arelius wrote: post #21
spitfire wrote: post #15

Earlier quoted context omitted.

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.

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?

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.

Re: Pretty Lisp

#52

Post by timmy-turner »

ken wrote: post #34
spitfire wrote: post #2

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?

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 t…

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

Re: Pretty Lisp

#53

Post by taliesinb »

brlewis wrote: post #4

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

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

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

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

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

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

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

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

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

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

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

Re: Pretty Lisp

#54

Post by spitfire »

ken wrote: post #34
spitfire wrote: post #2

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?

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 t…

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.

Re: Pretty Lisp

#55

Post by spitfire »

taliesinb wrote: post #47
spitfire wrote: post #15

Earlier quoted context omitted.

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.

Are you talking wolfram workbench or eclipse? (I don't have workbench). If eclipse has mms support I'll be trying that out tonight.

Re: Pretty Lisp

#56

Post by sedachv »

calibraxis wrote: post #42
pavelludiq wrote: post #18

Earlier quoted context omitted.

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 Li…

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.

Re: Pretty Lisp

#57

Post by pavelludiq »

calibraxis wrote: post #42
pavelludiq wrote: post #18

Earlier quoted context omitted.

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 Li…

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

Re: Pretty Lisp

#58

Post by lambda »

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

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

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

Re: Pretty Lisp

#59

Post by taliesinb »

spitfire wrote: post #55
taliesinb wrote: post #47

Earlier quoted context omitted.

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.

Are you talking wolfram workbench or eclipse? (I don't have workbench). If eclipse has mms support I'll be trying that out tonight.

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!

Re: Pretty Lisp

#60

Post by taliesinb »

lambda wrote: post #58

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 lo…

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.
Post reply on HN