6 ms·

Is this essentially wrapping each scoped segment of code into a "frame" for manupulation using a mouse? I must be misunderstanding, how can this be more useful

by brad0 9y ago

Is this essentially wrapping each scoped segment of code into a "frame" for manupulation using a mouse? I must be misunderstanding, how can this be more useful than plain text? Eliminating syntax errors?

cycomachead 9y ago
Syntax errors can be a large impediment to learning to program, so that's one big advantage. Frame-based editing has some other advantages, some of which you'd see in more complex IDEs like being context aware of what the user is truing to do.
Jtsummers 9y ago
Not just with a mouse. The frames can be detected automatically. Imagine a typical IDE where: while (...) { Automatically inserted the next `}` and moved the cursor between it. But in the frame based editor, the `{` and `}` are elided from the presentation, replaced with a colored block or frame around the inner kernel of the while loop. +++ while (condition) + --- if (condition) + - *** actions + ------------------ ++++++++++++++++++++++ Scratch (the example in Figure 1) is definitely a mouse driven interface, but beyond that and its visual presentation, it's more a cousin to the frame based model than a precise representation. It gives you a better (arguable?), structural way to view code, and to edit it with both text input and mouse.
- a3n 9y ago
  Yes, it's arguable. :) (curmudgeon)A well-formed program is "defined" as what the compiler expects. Like literate programming, this hides from me what's being presented to the compiler, and sets me adrift from what the program actually is.(/curmudgeon) It also reminds me vaguely of writing with Framemaker.
  - edmccard 9y ago
    >this hides from me what's being presented to the compiler Isn't that the whole point of abstractions? Like, when you write a function call, you see "foo()" but the compiler sees all the individual instructions in the function. The same with macros, templates, etc. And on a purely visual level, the example 'jtsummers gave just seems to be an extension of code folding and other tools that let you focus on one part of the code while ignoring another.
    - geocar 9y ago
      > Isn't that the whole point of abstractions? Abstractions are the wrong thing to chase. Just because an abstraction will put you further away from a technical problem, doesn't mean will get you closer to solving your business problem.
    - TeMPOraL 9y ago
      The essence of programming is being capable of constantly walking up and down the abstraction ladder. Trying to hide behind a perfect abstraction is as problematic as the belief that abstractions are evil because they're too complicated. Abstractions are transient. You want to use them when they help you, but it's good to be able to step down and verify what's going on.
      - edmccard 9y ago
        >The essence of programming is being capable of constantly walking up and down the abstraction ladder ... it's good to be able to step down and verify what's going on. Good, yes, desirable, often, but I wouldn't call it "essential" to the art of programming. I once worked for a company whose data was managed by a COBOL application on a mainframe a couple hundred miles away; there was no walking down that abstraction ladder (without shelling out a five-figure support fee), so our in-house IT department had to take advantage of the fact that the 3270 terminal emulator we used to access the mainframe, could be driven through a COM interface. I'm sure there are lots of other examples of jobs that don't have the luxury of being able to step down and verify lower-level code, and I wouldn't characterize them as missing out on some "essential" aspect of programming.
  - justinpombrio 9y ago
    > (curmudgeon)A well-formed program is "defined" as what the compiler expects. Like literate programming, this hides from me what's being presented to the compiler, and sets me adrift from what the program actually is.(/curmudgeon) (idealist)Well, there's no reason the compiler has to accept programs only as plain text. It's actually a pretty poor representation of your program: the language has to go out of its way to parse it. Internally, your program is an AST; this editor works over frames, which are closer to the AST than they are to plain text; perhaps they could both use the same non-textual file format.(/idealist)
    - TeMPOraL 9y ago
      > (idealist)Well, there's no reason the compiler has to accept programs only as plain text. It's actually a pretty poor representation of your program: the language has to go out of its way to parse it. Internally, your program is an AST; this editor works over frames, which are closer to the AST than they are to plain text; perhaps they could both use the same non-textual file format.(/idealist) For that you have Lisps, which hit the sweet spot by being human-writable ASTs that are trivial to parse (at least if you don't play with reader macros too much).
  - Jtsummers 9y ago
    It doesn't necessarily hide anything. Imagine Python augmented by this display. With C or Java you can show the curly braces but fade them into the background a bit and highlight the overall structure. I've seen similar things done for Lisp in the past, all the parens were there but deemphasised in favor of structural highlighting like this frame based editing concept.
- samstave 9y ago
  Nehack triggers... An Imp is attacking my Feline Familiar - and my fireball wand grazing by a shit-ton of monsters and items and four long-bows..
  - yvdriess 9y ago
    This joke might be going to the core of the chief argument agains visual programming. After a while, you just don't see the matrix anymore.
relyks 9y ago
This appears to be very similar to scope highlighting like what's used in BlueJ [1] and EditBox [2], but manipulable [1]: https://www.bluej.org/about.html https://www.bluej.org/about.html [2]: http://editbox.sourceforge.net/ http://editbox.sourceforge.net/
- omaranto 9y ago
  In the case of BlueJ this is not surprising: it's made by the same people and in fact this frame-based editor has been incorporated into BlueJ (this is mentioned briefly in the paper).

by brad0 9y ago

cycomachead 9y ago

Syntax errors can be a large impediment to learning to program, so that's one big advantage. Frame-based editing has some other advantages, some of which you'd see in more complex IDEs like being context aware of what the user is truing to do.

Jtsummers 9y ago

Not just with a mouse. The frames can be detected automatically. Imagine a typical IDE where: while (...) { Automatically inserted the next `}` and moved the cursor between it. But in the frame based editor, the `{` and `}` are elided from the presentation, replaced with a colored block or frame around the inner kernel of the while loop. +++ while (condition) + --- if (condition) + - *** actions + ------------------ ++++++++++++++++++++++ Scratch (the example in Figure 1) is definitely a mouse driven interface, but beyond that and its visual presentation, it's more a cousin to the frame based model than a precise representation. It gives you a better (arguable?), structural way to view code, and to edit it with both text input and mouse.

a3n 9y ago
Yes, it's arguable. :) (curmudgeon)A well-formed program is "defined" as what the compiler expects. Like literate programming, this hides from me what's being presented to the compiler, and sets me adrift from what the program actually is.(/curmudgeon) It also reminds me vaguely of writing with Framemaker.
- edmccard 9y ago
  >this hides from me what's being presented to the compiler Isn't that the whole point of abstractions? Like, when you write a function call, you see "foo()" but the compiler sees all the individual instructions in the function. The same with macros, templates, etc. And on a purely visual level, the example 'jtsummers gave just seems to be an extension of code folding and other tools that let you focus on one part of the code while ignoring another.
  - geocar 9y ago
    > Isn't that the whole point of abstractions? Abstractions are the wrong thing to chase. Just because an abstraction will put you further away from a technical problem, doesn't mean will get you closer to solving your business problem.
  - TeMPOraL 9y ago
    The essence of programming is being capable of constantly walking up and down the abstraction ladder. Trying to hide behind a perfect abstraction is as problematic as the belief that abstractions are evil because they're too complicated. Abstractions are transient. You want to use them when they help you, but it's good to be able to step down and verify what's going on.
    - edmccard 9y ago
      >The essence of programming is being capable of constantly walking up and down the abstraction ladder ... it's good to be able to step down and verify what's going on. Good, yes, desirable, often, but I wouldn't call it "essential" to the art of programming. I once worked for a company whose data was managed by a COBOL application on a mainframe a couple hundred miles away; there was no walking down that abstraction ladder (without shelling out a five-figure support fee), so our in-house IT department had to take advantage of the fact that the 3270 terminal emulator we used to access the mainframe, could be driven through a COM interface. I'm sure there are lots of other examples of jobs that don't have the luxury of being able to step down and verify lower-level code, and I wouldn't characterize them as missing out on some "essential" aspect of programming.
- justinpombrio 9y ago
  > (curmudgeon)A well-formed program is "defined" as what the compiler expects. Like literate programming, this hides from me what's being presented to the compiler, and sets me adrift from what the program actually is.(/curmudgeon) (idealist)Well, there's no reason the compiler has to accept programs only as plain text. It's actually a pretty poor representation of your program: the language has to go out of its way to parse it. Internally, your program is an AST; this editor works over frames, which are closer to the AST than they are to plain text; perhaps they could both use the same non-textual file format.(/idealist)
  - TeMPOraL 9y ago
    > (idealist)Well, there's no reason the compiler has to accept programs only as plain text. It's actually a pretty poor representation of your program: the language has to go out of its way to parse it. Internally, your program is an AST; this editor works over frames, which are closer to the AST than they are to plain text; perhaps they could both use the same non-textual file format.(/idealist) For that you have Lisps, which hit the sweet spot by being human-writable ASTs that are trivial to parse (at least if you don't play with reader macros too much).
- Jtsummers 9y ago
  It doesn't necessarily hide anything. Imagine Python augmented by this display. With C or Java you can show the curly braces but fade them into the background a bit and highlight the overall structure. I've seen similar things done for Lisp in the past, all the parens were there but deemphasised in favor of structural highlighting like this frame based editing concept.
samstave 9y ago
Nehack triggers... An Imp is attacking my Feline Familiar - and my fireball wand grazing by a shit-ton of monsters and items and four long-bows..
- yvdriess 9y ago
  This joke might be going to the core of the chief argument agains visual programming. After a while, you just don't see the matrix anymore.

relyks 9y ago

This appears to be very similar to scope highlighting like what's used in BlueJ [1] and EditBox [2], but manipulable [1]: https://www.bluej.org/about.html https://www.bluej.org/about.html [2]: http://editbox.sourceforge.net/ http://editbox.sourceforge.net/

omaranto 9y ago
In the case of BlueJ this is not surprising: it's made by the same people and in fact this frame-based editor has been incorporated into BlueJ (this is mentioned briefly in the paper).