
Frame-Based Editing - gnocchi
http://www.greenfoot.org/frames/
======
glitch
Just to add to this discussion, some quasi-related links with regard to visual
presentation of code:

• Experiments in Code Typography (McDirmid, Microsoft)
[http://research.microsoft.com/en-
us/projects/liveprogramming...](http://research.microsoft.com/en-
us/projects/liveprogramming/typography.aspx)

• Typography of Code (MAX 2010):
[https://youtu.be/mG0lyGekGDs](https://youtu.be/mG0lyGekGDs) (alternate
recording: [https://youtu.be/r2JePjrDggE](https://youtu.be/r2JePjrDggE))

• Elastic tabstops: [http://nickgravgaard.com/elastic-
tabstops/](http://nickgravgaard.com/elastic-tabstops/)

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,
[http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx), Bret Victor's works, etc.  But, I digress. 

~~~
CMCDragonkai
Also Haskell Ligatures [https://www.google.com.au/search?ie=UTF-8&client=ms-
android-...](https://www.google.com.au/search?ie=UTF-8&client=ms-android-hms-
vf-au&source=android-
browser&q=haskell+ligatures&gfe_rd=cr&ei=mqxSVbn_FqTu8we5roHoBw)

~~~
seanmcdirmid
Ooo, nice!  I've hacked unicode to do my own ligatures in a custom editor, but
I dream of doing a custom font like this (but in a San Serif proportional
way). 

------
ianbicking
The first time I heard about this approach was Boxer:
[http://edutechwiki.unige.ch/en/Boxer](http://edutechwiki.unige.ch/en/Boxer)

Some more info here: [http://lambda-the-ultimate.org/node/4695](http://lambda-
the-ultimate.org/node/4695)

Paper with some screenshots:
[http://www.soe.berkeley.edu/boxer/20reasons.pdf](http://www.soe.berkeley.edu/boxer/20reasons.pdf)

And another more contemporary document:
[http://www.pyxisystems.com/file/BoxerStructures.pdf](http://www.pyxisystems.com/file/BoxerStructures.pdf)

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

~~~
abecedarius
Yes, and the remark at the post's bottom, "Structured editing wasn't actually
a bad idea, it was just poorly executed."  seems oblivious to Boxer -- I found
it usable enough (and inspiring). 

diSessa's book [http://www.amazon.com/Changing-Minds-Computers-Learning-
Lite...](http://www.amazon.com/Changing-Minds-Computers-Learning-
Literacy/dp/0262541327) has more on the philosophy and the experience with
kids using it.  The writing style's a bit of a slog. 

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

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. 

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. 

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. 

~~~
sitkack
This is the next phase of revision control, where tree transforms are stored
in an edit list in the log. 

We will start to tag actions like we label commits.  Transforms will be
parameterized so we can pull them into our tree, merging them with our own
transformations. 

If you use an IntelliJ product, you can put the carat inside an expression and
iteratively expand the properly bounded selection with alt-up-arrow

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

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

~~~
melloclello
Keep fleshing it out - indeed use your experience with paredit to guide you -
the benefit would be that people who don't necessarily know emacs etc can
suddenly write lisp the way it was supposed to be written.  Imagine if you were
new to programming and something like that was the tool you were given? 

~~~
lorddoig
New to programming?  I've been coding since I was 12 and only recently have I
become confident in the procedure to exit emacs. 

I shouldn't have said paredit - I thought it had become a general term (is
there one?)  Most of my experience is with Cursive's 'Structural Editing'
(sounds general, but is it?)  features, and that's what I had in mind. 

I wouldn't give a newcomer emacs (or vi) but I would give them the concept of
paredit.  The problem with that is fundamentally the keyboard, and it's a
problem for the more seasoned of us too.  I would kill for a programmable
numpad-sized keyboard with removable caps that can be labelled _by design_ so
I can have a physical button for the operations I perform most often.  I know
similar things can be achieved with midi pads, but they're far from perfect. 
Programmable, configurable keyboards were a thing when I was at school (around
the tail of the BBC Micro era) - where did they go? 

~~~
melloclello
> I wouldn't give a newcomer emacs (or vi) but I would give them the concept
> of paredit. 

This is exactly what I was suggesting

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

However, it is an extremely effective way to get students _interested_ in
Java, and that is often the most important objective. 

~~~
wtallis
I've helped teach a few camps myself and have similar opinions.  Alice allowed
for impressive graphics but not a lot depth to the programming (at least the
early version we had at the time).  Building Pong level stuff from more
primitive capabilities in real Java was just as rewarding and develops skills
that are a lot more directly applicable elsewhere.  Learning Java by making
Minecraft mods was really interesting: the initial learning curve is a bit
steep due to the messy working environment, but it very quickly leads to more
advanced topics as the students want to enhance the behaviors of existing
creatures, add new graphical effects, or do something that requires extending
the protocol for communication between the client and server.  If Minecraft
were open-source and the codebase was cleaned up a bit, it would be an
_awesome_ teaching tool. 

------
gknoy
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? 

------
adriano_f
Interesting approach. 

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: [http://blog.gingkoapp.com/features/gingko-as-a-lisp-
editor](http://blog.gingkoapp.com/features/gingko-as-a-lisp-editor)

It's an avenue I definitely want to explore. 

------
douche
It's an interesting idea.  I wonder if something like this could be rigged up
in Visual Studio, maybe using Rosyln? 

~~~
mistermann
That's what I wanted to ask, is there anything like this for Visual Studio?  It
gives very subtle hints, but I would love something like this. 

~~~
seanmcdirmid
Not that I know of, but I personally use "Tiny Braces" coupled with "Editor
Guidelines" to get the visual appearance, at least. 

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

~~~
Ericson2314
Yeah, it sounds like what they really mean is "we want our frames to be
course-grained, because they are still a bit awkward to work with". 

You can reflect the entire AST in your structure editor, so all text is parsed
(just identifiers, or perhaps keywords).  But then since basically all editor
actions involve manipulating frames/ast nodes, you need to make the UX
extremely smooth -- shortcut keys for high-level actions alone won't cut it. 

------
escap
See also the work of Dave Winer in using outline to edit code (e.g
[http://scripting.com/stories/2012/01/23/codeNodetypesInWorld...](http://scripting.com/stories/2012/01/23/codeNodetypesInWorldOutlin.html)
)

and [http://leoeditor.com/](http://leoeditor.com/) to edit python code as
outline

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