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

31–40 of 115 posts

Re: Pretty Lisp

#31

Post by jrockway »

dfan wrote: post #22

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

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.

Re: Pretty Lisp

#32

Post by mark_l_watson »

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.

Re: Pretty Lisp

#33

Post by agumonkey »

Flip the keymap, I mean remove the prefix, especially in a browser where C-x becomes C 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 for new element insertion ( cons cell )

anyway, keep digging, it's the one true path ;)

/me going back to reading 'On Lisp'

Re: Pretty Lisp

#34

Post by ken »

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 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# " rel="nofollow">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.

Re: Pretty Lisp

#35

Post by gnosis »

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.

Re: Pretty Lisp

#36

Post by agumonkey »

gnosis wrote: post #35

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.

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.

Re: Pretty Lisp

#37

Post by Arelius »

DanI-S wrote: post #30
Arelius wrote: post #6

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.

Re: Pretty Lisp

#38

Post by webjprgm »

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

Re: Pretty Lisp

#39

Post by webjprgm »

Arelius wrote: post #37
DanI-S wrote: post #30

Earlier quoted context omitted.

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.

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

Re: Pretty Lisp

#40

Post by skeptical »

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?

Post reply on HN