Just to add to this discussion, some quasi-related links with regard to visual presentation of code:<p>• Experiments in Code Typography (McDirmid, Microsoft) <a href="http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx" rel="nofollow">http://research.microsoft.com/en-us/projects/liveprogramming...</a><p>• Typography of Code (MAX 2010): <a href="https://youtu.be/mG0lyGekGDs" rel="nofollow">https://youtu.be/mG0lyGekGDs</a> (alternate recording: <a href="https://youtu.be/r2JePjrDggE" rel="nofollow">https://youtu.be/r2JePjrDggE</a>)<p>• Elastic tabstops: <a href="http://nickgravgaard.com/elastic-tabstops/" rel="nofollow">http://nickgravgaard.com/elastic-tabstops/</a><p>Of course, there's also numerous projects with more significant visual representation, like Blockly, Scratch, flow programming, etc. And, of course, real-time feedback/simulation is another arena of usefulness e.g, <a href="http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx" rel="nofollow">http://research.microsoft.com/en-us/people/smcdirm/managedti...</a>, Bret Victor's works, etc. But, I digress.
The first time I heard about this approach was Boxer: <a href="http://edutechwiki.unige.ch/en/Boxer" rel="nofollow">http://edutechwiki.unige.ch/en/Boxer</a><p>Some more info here: <a href="http://lambda-the-ultimate.org/node/4695" rel="nofollow">http://lambda-the-ultimate.org/node/4695</a><p>Paper with some screenshots: <a href="http://www.soe.berkeley.edu/boxer/20reasons.pdf" rel="nofollow">http://www.soe.berkeley.edu/boxer/20reasons.pdf</a><p>And another more contemporary document: <a href="http://www.pyxisystems.com/file/BoxerStructures.pdf" rel="nofollow">http://www.pyxisystems.com/file/BoxerStructures.pdf</a><p>It goes beyond framing a bit, making things like variables concrete (they are actual boxes that contain a value). But it doesn't do full Scratch-style pluggable programming, the statements are still text, as in "Frame-Based Editing".
This goes back a long way, to, at least, a Cornell system circa 1980. It's usually been a teaching tool, for students having trouble with language syntax.<p>LISP used to have very structured editors. One of the features of INTERLISP was that you could select a subexpression and pull it out as a function. A call to the function, with the correct parameters, then replaced the function. Conversely, you could select a function call and have it expanded in line. These were safe operations; they would not change the program semantics.<p>That's the key. The editor understood the semantics of the language, not just the syntax, and only performed safe transformations. This sort of thing is useful in program maintenance; when faced with a large function, you can safely break it apart into smaller ones.<p>C++ could really use a tool like that. It would be very hard to write. The tool has to perform only valid transformations, so it needs to know the language.
I found writing in Lisp dialects enjoyable after having used mainly C and C++ for (too much) years partly because it was easier to reason about the syntax, of course also for the obvious paradigmatical reasons. Slurpage and barfage, splicing, enclosing and other functions that editors provide really mean you are no more editing code on a textual, but rather structural level, and what makes this effective is the beautifully simple way Lisp programs are expressed. Coupled with the concise recursive representation of algorithms, ordinary functional programming goodies (map, fold, etc.) and the powerful macros, it feels like it completely redefined 'coding' for me. I wouldn't go back if I had the luxury of having such a choice. So anyone who finds this frame-based concept attractive will probably like Lisp's s-expression syntax and paredit mode in your favorite editor.
I was thinking the other day, after reading the post about the Unison project, that graphical editing could be a really neat idea - "there is no syntax, you manipulate the AST directly" kind of thing. Then I started to try to flesh out how such a thing might actually work and I quickly realised that it offers zero benefit over editing standard Lisp syntax with paredit. They're equivalent.
I designed Java curriculum around Greenfoot for a few large summer camps and education programs in Silicon Valley, but have since turned away from the platform completely because of how it limits students from developing games independently on their own. When they realize how much more involved it is to write similar games in Java, they stick to the confines of Greenfoot, where flashy images and motion are easy to implement. Since then, I've realized it's more useful to have students implement a game like Flappy Bird with Java's native functions for drawing ovals and rectangles, rather than by explaining how to do it with Actors and Worlds.<p>However, it is an extremely effective way to get students <i>interested</i> in Java, and that is often the most important objective.
I'm having trouble seeing how this is different from Lisp's S-expressions. Is it basically paredit for blocks and logical constructs in a non-lisp context?
Interesting approach.<p>I agree with the premise (code is structured, and shouldn't be handled as flat files). I've played with the idea of using my own card-tree editor as a LISP editor before:
<a href="http://blog.gingkoapp.com/features/gingko-as-a-lisp-editor" rel="nofollow">http://blog.gingkoapp.com/features/gingko-as-a-lisp-editor</a><p>It's an avenue I definitely want to explore.
Looks neat. But I was bummed out by this: "Frames are useful for statements, but they get unwieldy if you were to use them for expressions." I'd love to see an approach to this that works for languages that don't have a statement / expression distinction.
See also the work of Dave Winer in using outline to edit code (e.g <a href="http://scripting.com/stories/2012/01/23/codeNodetypesInWorldOutlin.html" rel="nofollow">http://scripting.com/stories/2012/01/23/codeNodetypesInWorld...</a> )<p>and <a href="http://leoeditor.com/" rel="nofollow">http://leoeditor.com/</a> to edit python code as outline
In my first programming module we used a language called Sense, which was a visual drag-and-drop block editor. I sometimes imagined an editor that used plain text but showed what block you were in visually.