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

81–90 of 115 posts

Re: Pretty Lisp

#81

Post by rsl7 »

CoffeeDregs wrote: post #14
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.

> The future is in structural editors. I liked CodeBubbles, but do you have any other examples of structural editors for generic programming? Obviously, UI-centric editors and LabView are structural editors, but for very specific domains.

I used one called Genie Pascal in 1988, out of CMU, on the Mac Plus. They did lots of work on supporting various languages. http://www.cs.cmu.edu/~pane/ile.html

Re: Pretty Lisp

#82

Post by spitfire »

Arelius wrote: post #74
spitfire wrote: post #51

Earlier quoted context omitted.

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

This sounds like the kind of work that most people I know would choose matlab for (image segmentation). I personally have never used either for such, but do you have any thoughts on the matter? Is Mathematica getting better at the things matlab used to be best at?

It sort of comes down to what you're comfortable with. In this case, the strict image analysis parts were more minor compared to the real work. Also, Matlab seems to be stagnating, while Mathematica has been growing by leaps and bounds. Also, matlab doesn't have built in functionality for gui building, afaik.

A lot of my other work is much less suited to matlab. Mathematica is certainly much better for multi-domain work, which matlab barely supports.

Re: Pretty Lisp

#83

Post by jerf »

spitfire wrote: post #54
ken wrote: post #34

Earlier quoted context omitted.

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.

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 is not that they don't understand the disadvantages of the format... it is that they don't understand the advantages. Consequently, proposals for replacement tend to throw away huge swathes of functionality without realizing it, then start from a functionality deficit nearly impossible to recover from. It's actually hard to beat text. There's a reason we're communicating in text right now, and it isn't a lack of creativity or lack of attempts at other solutions to the problem or any of the other memes trotted out every time this topic comes up.

Re: Pretty Lisp

#84

Post by shaunxcode »

taliesinb wrote: post #60
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.

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

Re: Pretty Lisp

#85

Post by __david__ »

shaunxcode wrote: post #84
taliesinb wrote: post #60

Earlier quoted context omitted.

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.

Re: Pretty Lisp

#86

Post by ori_b »

aristus wrote: post #79
gringomorcego wrote: post #70

Earlier quoted context omitted.

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.

Re: Pretty Lisp

#88

Post by aristus »

ori_b wrote: post #86
aristus wrote: post #79

Earlier quoted context omitted.

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.

Re: Pretty Lisp

#89

Post by Detrus »

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…

We have the systems we have now because we used the same medium for thousands of years. To create new expressive mediums that take advantage of computers will take careful design and iteration, just as alphabetic text went through various handscripts like cursive, torturous to read German blackletter http://en.wikipedia.org/wiki/Blackletter and settled on http://en.wikipedia.org/wiki/Roman_type

Then we went to san serifs (like here on HN) and then to monospaced code fonts. It's a long line and a lot of work by designers.

Adding to this medium will also take a lot of work. An essay can be more expressive when various ideas in it are turned into visualizations. Writers of long novels use special writer software to keep track of which characters interact with what others, to create family charts, friend charts, event timelines, etc.

These don't replace text, they augment it. And it would be interesting to have a macro view of the book through such tools for readers someday.

Not every attempt reduced the expressiveness of code. Syntax highlighting is graphical. Labview is graphical. Short compile cycles so the programmer can see what he's doing is graphical. Great demo of that here https://vimeo.com/36579366

Just because this particular attempt at pretty lisp leaves much to be desired doesn't mean we should stop attempting. Simple programmer tasks like naming can be improved if we move away from plain text as the medium, more detail here http://news.ycombinator.com/item?id=3633740 and http://news.ycombinator.com/item?id=3651257

Re: Pretty Lisp

#90

Post by idlephilosopher »

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…

What would you list as the advantages of text-based editing that replacements miss?
Post reply on HN