Frame-Based Editing(greenfoot.org)
greenfoot.org
Frame-Based Editing
http://www.greenfoot.org/frames/
12 comments
Also Haskell Ligatures https://www.google.com.au/search?ie=UTF-8&client=ms-android-...
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).
Mathematica also probably deserves a shout-out. Not only does it allow you to incorporate graphics, pretty-printed equations with complex 2D layout, and interactive objects right in the language, but it transparently exposes their representations to code (it's a LISP descendant, after all).
The first time I heard about this approach was Boxer: http://edutechwiki.unige.ch/en/Boxer
Some more info here: http://lambda-the-ultimate.org/node/4695
Paper with some screenshots: http://www.soe.berkeley.edu/boxer/20reasons.pdf
And another more contemporary document: 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".
Some more info here: http://lambda-the-ultimate.org/node/4695
Paper with some screenshots: http://www.soe.berkeley.edu/boxer/20reasons.pdf
And another more contemporary document: 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".
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... has more on the philosophy and the experience with kids using it. The writing style's a bit of a slog.
diSessa's book http://www.amazon.com/Changing-Minds-Computers-Learning-Lite... has more on the philosophy and the experience with kids using it. The writing style's a bit of a slog.
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.
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.
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
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
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.
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?
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?
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?
> 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
This is exactly what I was suggesting
I've barely used paredit, but when I tried it it felt a bit rough---and that's not surprise since not all text is a valid s-expression.
Also, tree editors make implementing additional editor features. You don't get that benefit with emacs + paredit since the data structure is still a text string at the end of the day.
Also, tree editors make implementing additional editor features. You don't get that benefit with emacs + paredit since the data structure is still a text string at the end of the day.
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.
However, it is an extremely effective way to get students interested in Java, and that is often the most important objective.
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.
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.
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
It's an avenue I definitely want to explore.
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
It's an avenue I definitely want to explore.
It's an interesting idea. I wonder if something like this could be rigged up in Visual Studio, maybe using Rosyln?
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.
Not that I know of, but I personally use "Tiny Braces" coupled with "Editor Guidelines" to get the visual appearance, at least.
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.
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.
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.
See also the work of Dave Winer in using outline to edit code (e.g http://scripting.com/stories/2012/01/23/codeNodetypesInWorld... )
and http://leoeditor.com/ to edit python code as outline
and http://leoeditor.com/ 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.
• Experiments in Code Typography (McDirmid, Microsoft) http://research.microsoft.com/en-us/projects/liveprogramming...
• Typography of Code (MAX 2010): https://youtu.be/mG0lyGekGDs (alternate recording: https://youtu.be/r2JePjrDggE)
• 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..., Bret Victor's works, etc. But, I digress.