Reminds me of Steven Reiss's "PECAN" system he developed at Brown University in 1984, which he gave a talk about and gave us a copy of the Sun version to play around with at the UMD Human Computer Interaction Lab around 1985 or so.
It seemed like an interesting idea, possibly useful for teaching programming to students who had never coded before (especially the data structure visualization and algorithm animation system BALSA), but essentially pretty frustrating and klunkey in practice.
Of course we have a hell of a lot more computing power to piss away at the problem now, but it's still fundamentally at odds with how professional programmers code and how programming languages are designed (except for Lisp of course), and isn't a widely used approach for many practical reasons.
>Graphical Program Development with PECAN Program Development Systems (1984)
>Steven P. Reiss,
Department of Computer Science,
Brown University,
Providence, RI 02912.
>Abstract:
>This paper describes the user's view of the
PECAN family of program development systems.
PECAN is a program development system generator
for algebraic programming languages. The
program development systems it produces support
multiple views of the user's program, its semantics,
and its execution. The program views
include a syntax-directed editor, a declaration
editor, and a structured flow graph editor. The
semantic views include expression trees, data type
diagrams, flow graphs, and the symbol table.
Execution views show the program in action and
the stack contents as the program executes.
PECAN is designed to make effective use of
powerful personal machines with high-resolution
graphics displays and is currently implemented on
APOLLO workstations.
ChatGPT opines:
>Subsequent research into syntax-directed editors has revealed that they are less effective than initially anticipated. These editors have been thoroughly examined over the past decade, leading to insights about their limitations and practical challenges. Studies have shown that while syntax-directed editors can be useful in certain contexts, such as language definitions and programming environment development, they haven't gained widespread popularity due to various factors. These include issues related to usability, integration with other development tools, and accommodating diverse programming styles. Additionally, the complexity of implementing efficient and robust syntax-directed editors that smoothly integrate into existing development environments has also contributed to their limited adoption.
>Check out these search results to keep exploring.
>On the Usefulness of Syntax Directed Editors. (1986)
>Bernard Lang, INRIA, B.P. 105, 78153, Le Chesnay, France.
>Abstract
>The intent of this position statement is to relate our experience with the actual use of a syntax
directed editor (Mentor [5]) in different contexts: teaching, real software production, software
maintenance and associated tasks, language design and development, development of programming tools and new programming structures.
>1. Introduction
>Originally the subject of this presentation was motivated by discussions to be found in the
technical literature [1,2,3], and by the open questioning in less technical publications (as well as in
private discussions) of the real usefulness of the syntax directed approach, its practicality and its
high cost for allegedly low returns [4]. While the author does not dispute many of the points
raised in the technical literature, he believes they emphasize too much the role of syntax directed
tools for program creation, and thus lead to a biased assessment of their real usefulness. This is
currently resulting in the marketing of sophisticated syntax directed editors, restricted to program
creation, whose cost effectiveness may indeed be questionable.
>The ideas expressed here reflect only the point of view of this author, and are intended as a
basis for discussion on the role of syntax directed editors. The personal judgements on various
aspects of syntax directed environments are not meant as an assessment of the usefulness of
research in those areas, but only as a tentative evaluation of the relative importance of these
aspects for users, given the current state of the art and the author's own experience.
>This experience is based almost solely on the use of the Mentor system [5].
Though comparison of several systems would be desirable, the youth of this technology makes it rather difficult
to acquire extensive practical experience with more than one of them.
[...]
I think Brett Victor's work on Learnable Programming, program visualization and live programming is a more modern and fruitful approach.
>As you can see, live coding, on its own, is not especially useful. The programmer still must type at least a full line of code before seeing any effect. This means that she must already understand what line of code she needs to write. The programmer is still doing the creative work entirely in her head -- imagining the next addition to the program and then translating it into code.
[...]
>Here's an example. In many styles of programming today, when an application launches, it creates a large set of interconnected stateful objects. To see the effect of a code change, the application must be "relaunched" -- that is, its entire world is destroyed, and rebuilt again from scratch. How can we "create by reacting", continuously changing the code and seeing continuous effects in the flow and data, when there is no continuity between the application's state before and after the change?
>We can't. That's the wrong question. A better question is: How do we design a new programming model that does allow for continuous change? We already have clear hints.*
>Another example. Most programs today manipulate abstract data structures and opaque objects, not pictures. How can we visualize the state of these programs?
>Again, wrong question. A better attitude is to assert that we have to be able to understand the state of our programs. We can then ask: How do we design data structures that can be visualized? Can we invent data structures that are intended to be visualized? How do we move towards a culture where only visually-understandable data is considered sound? Where opaque data is regarded in the same way that "goto" is today?* Forward reference: Some work that I've done in automatic visualization of ad-hoc data structures will be published later this year, in collaboration with Viewpoints Research.
>In his influential essay No Silver Bullet, Fred Brooks makes the case that software is inherently "invisible and unvisualizable", and points out the universal failure of so-called "visual programming" environments. I don't fault Fred Brooks for his mistake -- the visual programming that he's thinking of indeed has little to offer. But that's because it visualizes the wrong thing.
>Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.
>Visualize data, not code. Dynamic behavior, not static structure.
>Maybe we don't need a silver bullet. We just need to take off our blindfolds to see where we're firing.
and after a while, any moderately complex task gets broken down into modules and you end up with the "wall of text" which ostensibly one is trying to avoid, or one has the visual version of spaghetti code:
It seemed like an interesting idea, possibly useful for teaching programming to students who had never coded before (especially the data structure visualization and algorithm animation system BALSA), but essentially pretty frustrating and klunkey in practice.
Of course we have a hell of a lot more computing power to piss away at the problem now, but it's still fundamentally at odds with how professional programmers code and how programming languages are designed (except for Lisp of course), and isn't a widely used approach for many practical reasons.
https://cs.brown.edu/~spr/papers/pecanpaper.pdf
>Graphical Program Development with PECAN Program Development Systems (1984)
>Steven P. Reiss, Department of Computer Science, Brown University, Providence, RI 02912.
>Abstract:
>This paper describes the user's view of the PECAN family of program development systems. PECAN is a program development system generator for algebraic programming languages. The program development systems it produces support multiple views of the user's program, its semantics, and its execution. The program views include a syntax-directed editor, a declaration editor, and a structured flow graph editor. The semantic views include expression trees, data type diagrams, flow graphs, and the symbol table. Execution views show the program in action and the stack contents as the program executes. PECAN is designed to make effective use of powerful personal machines with high-resolution graphics displays and is currently implemented on APOLLO workstations.
ChatGPT opines:
>Subsequent research into syntax-directed editors has revealed that they are less effective than initially anticipated. These editors have been thoroughly examined over the past decade, leading to insights about their limitations and practical challenges. Studies have shown that while syntax-directed editors can be useful in certain contexts, such as language definitions and programming environment development, they haven't gained widespread popularity due to various factors. These include issues related to usability, integration with other development tools, and accommodating diverse programming styles. Additionally, the complexity of implementing efficient and robust syntax-directed editors that smoothly integrate into existing development environments has also contributed to their limited adoption.
>Check out these search results to keep exploring.
https://link.springer.com/chapter/10.1007/3-540-17189-4_87
https://www.researchgate.net/publication/221330960_On_the_Us...
>On the Usefulness of Syntax Directed Editors. (1986)
>Bernard Lang, INRIA, B.P. 105, 78153, Le Chesnay, France.
>Abstract
>The intent of this position statement is to relate our experience with the actual use of a syntax directed editor (Mentor [5]) in different contexts: teaching, real software production, software maintenance and associated tasks, language design and development, development of programming tools and new programming structures.
>1. Introduction
>Originally the subject of this presentation was motivated by discussions to be found in the technical literature [1,2,3], and by the open questioning in less technical publications (as well as in private discussions) of the real usefulness of the syntax directed approach, its practicality and its high cost for allegedly low returns [4]. While the author does not dispute many of the points raised in the technical literature, he believes they emphasize too much the role of syntax directed tools for program creation, and thus lead to a biased assessment of their real usefulness. This is currently resulting in the marketing of sophisticated syntax directed editors, restricted to program creation, whose cost effectiveness may indeed be questionable.
>The ideas expressed here reflect only the point of view of this author, and are intended as a basis for discussion on the role of syntax directed editors. The personal judgements on various aspects of syntax directed environments are not meant as an assessment of the usefulness of research in those areas, but only as a tentative evaluation of the relative importance of these aspects for users, given the current state of the art and the author's own experience.
>This experience is based almost solely on the use of the Mentor system [5]. Though comparison of several systems would be desirable, the youth of this technology makes it rather difficult to acquire extensive practical experience with more than one of them.
[...]
I think Brett Victor's work on Learnable Programming, program visualization and live programming is a more modern and fruitful approach.
http://worrydream.com/LearnableProgramming/
>As you can see, live coding, on its own, is not especially useful. The programmer still must type at least a full line of code before seeing any effect. This means that she must already understand what line of code she needs to write. The programmer is still doing the creative work entirely in her head -- imagining the next addition to the program and then translating it into code.
[...]
>Here's an example. In many styles of programming today, when an application launches, it creates a large set of interconnected stateful objects. To see the effect of a code change, the application must be "relaunched" -- that is, its entire world is destroyed, and rebuilt again from scratch. How can we "create by reacting", continuously changing the code and seeing continuous effects in the flow and data, when there is no continuity between the application's state before and after the change?
>We can't. That's the wrong question. A better question is: How do we design a new programming model that does allow for continuous change? We already have clear hints.*
>Another example. Most programs today manipulate abstract data structures and opaque objects, not pictures. How can we visualize the state of these programs?
>Again, wrong question. A better attitude is to assert that we have to be able to understand the state of our programs. We can then ask: How do we design data structures that can be visualized? Can we invent data structures that are intended to be visualized? How do we move towards a culture where only visually-understandable data is considered sound? Where opaque data is regarded in the same way that "goto" is today?* Forward reference: Some work that I've done in automatic visualization of ad-hoc data structures will be published later this year, in collaboration with Viewpoints Research.
>In his influential essay No Silver Bullet, Fred Brooks makes the case that software is inherently "invisible and unvisualizable", and points out the universal failure of so-called "visual programming" environments. I don't fault Fred Brooks for his mistake -- the visual programming that he's thinking of indeed has little to offer. But that's because it visualizes the wrong thing.
>Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.
>Visualize data, not code. Dynamic behavior, not static structure.
>Maybe we don't need a silver bullet. We just need to take off our blindfolds to see where we're firing.