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

91–100 of 115 posts

Re: Pretty Lisp

#91

Post by shaunxcode »

__david__ wrote: post #85
shaunxcode wrote: post #84

Earlier quoted context omitted.

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.

Re: Pretty Lisp

#92

Post by Detrus »

jerf wrote: post #83
spitfire wrote: post #54

Earlier quoted context omitted.

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…

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.

Re: Pretty Lisp

#93

Post by zokier »

jimbokun wrote: post #67
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?

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…

Except that in LISP, code is not fundamentally textual. It's S-expressions, which are nested lists, ie trees.

Re: Pretty Lisp

#94

Post by zokier »

jsmcgd wrote: post #3
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?

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.

Have you seen Code Bubbles? http://www.andrewbragdon.com/codebubbles_site.asp

Re: Pretty Lisp

#96

Post by colonel_panic »

sedachv wrote: post #56
calibraxis wrote: post #42

Earlier quoted context omitted.

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

Maybe it would work if you designed a language with structured editing in mind from the start.

Re: Pretty Lisp

#97

Post by xyzzyz »

chimeracoder wrote: post #73
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…

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

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.

Re: Pretty Lisp

#98

Post by graywh »

xyzzyz wrote: post #97
chimeracoder wrote: post #73

Earlier quoted context omitted.

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

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.

There's a plugin for rainbow parens.

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

Re: Pretty Lisp

#99

Post by simonb »

jrockway wrote: post #31
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.

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

Re: Pretty Lisp

#100

Post by simonb »

colonel_panic wrote: post #50
tincholio wrote: post #10

Earlier quoted context omitted.

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.

(setq mwe:color-box-hide-parens nil)
Post reply on HN