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

41–50 of 115 posts

Re: Pretty Lisp

#41

Post by Arelius »

webjprgm wrote: post #39
Arelius wrote: post #37

Earlier quoted context omitted.

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.

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

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

Re: Pretty Lisp

#42

Post by calibraxis »

pavelludiq wrote: post #18
pshc wrote: post #9

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.

Re: Pretty Lisp

#43

Post by webjprgm »

gt384u wrote: post #8

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

Hmm, code bubbles actually looks interesting. I might actually try something like that.

Pretty list still doesn't look very appealing to me. It doesn't help organize the code, all it does is replace parenthesis with visual boxes.

Re: Pretty Lisp

#44

Post by lurker17 »

webjprgm wrote: post #38

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

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.

Re: Pretty Lisp

#45

Post by ken »

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…

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.

Re: Pretty Lisp

#47

Post by taliesinb »

spitfire wrote: post #15
jsmcgd wrote: post #3

Earlier quoted context omitted.

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.

Re: Pretty Lisp

#49

Post by trengof »

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.

Re: Pretty Lisp

#50

Post by colonel_panic »

tincholio wrote: post #10
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?

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 (you can see a screenie in http://www.foldr.org/~michaelw/emacs/color-box.png )

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.

Post reply on HN