I liked this part: "the student is treated in no way differently from the faculty or staff in the nature of...contact with the processing capacity of the computer." Says a lot about the hierarchy of the period (as does the use of "his contact" in the original...)
This is ironic to me because I have seen that the other way from usual: in 1984 I was a TA at Stanford for a class whose students were grad students and faculty in the philosophy department (I was part of a team at PARC developing a new programming language relevant to the work at the newly formed CSLI). Most of them had never touched a computer before. Some of the faculty didn't enjoy being "students" again, and many didn't do the homework.
And a couple of years before I was taking a humanities class at MIT. A special section of 6.001 (introduction to programming, taught in Scheme) was being offered to the faculty. He asked me for help with the homework.
This was at a time when I think the majority of MIT undergraduates arrived without having used a computer more powerful than a pocket calculator.
Flow charts are not a programming language, largely because they are two dimensional and pictorial, and there is no convenient way of reading them into the computer. This situation will almost certainly change, since graphical input devices using large cathode ray tubes are now being developed for computers; but for the present, flow charts are limited to expressing algorithms.
I'm pretty sure that Fred Brooks addressed the topic of visual programming in either The Mythical Man Month (1975) or in No Silver Bullet (1986). I can't remember his exact wording but I think the gist of it was that it was an idea which would never ever fly, but which management would none keep pursuing because of its inherent appeal.
Having implemented, as part of my master's thesis, a program which would turn charts into code, and having since had the pleasure of working with several other ill conceived software products along the same line, I can only agree with Brooks. It hardly scales beyond the "Hello World" example which sold the idea to management. The only way to salvage anything from such a project is to commit any generated code of value and clean it up until it's maintainable.
what do you think of the visual programming in unreal engine similar for unity? have never used it, but supposedly you can go back and forth between c++ and the drag-and-drop interface
i really like scratch, have started using this tool called pibakery that has a similar block-based interface:
http://www.pibakery.org/
If nothing else, visual programming is of educational value
etc:
Seymour Papert's Logo maybe fits in somewhere here (source of turtle graphics)
I have never worked with Unity so I wouldn't know.
That being said, I think there may be a niche for visual programming tools when developing visual stuff. I'm old enough to remember Delphi, and also I made a few games in Flash back in the day. In both cases you would arrange visual elements, and you would attach stuff like event handlers written in a "real" programming language. I think the reason that it worked was that the visual part would be describing structure, not algorithms. In the same way that HTML is pretty good for describing UI elements without pretending to be a full fledged programming language. I'm not sure this division of labor would apply to Unity as well but I would presume so since it makes a lot of sense.
As for Scratch, I see it more as a real programming language but with a visual editor that makes it easy for beginners to compose programs by dragging and dropping. I think the tradeoff is great for beginners: makes the constructs visible and avoids syntax errors. I don't think it would scale to large projects, but that was never the point.
BTW, remember Logo from my school in the 1980s. I even seem to remember that we had the real, physical turtle at some point, able to draw lines on a sheet of paper. Or maybe my memory is deceiving me.
It seems the only "visual programming" environments are either domain-specific, esoteric, intended for children, or some combination of the above. And I think that's a damn shame. I'm a data scientist, not a computer scientist: give me a suitable abstraction layer on top of code, and I will use it. I think flowchart-based programming is one way, maybe the only way, to make this possible.
I don't know about this. At my last job, one of the very first problems dropped in my lap was to fix a debugging tool that had been mostly written in Workflow Foundation, a flowchart-based programming environment for .NET that isn't domain-specific, esoteric, or intended for children. It was the tenth circle of Hell and almost drove me to a nervous breakdown in my first month on the job. Despite how often I quote Joel Spolsky's "never rewrite the project from scratch" essay, I threw the whole thing out and wrote it again, and was much better off for doing so.
Now, certainly the specific failings of WF, and the bast^H^H^H^H person who wrote the tool were partially to blame here, but even with all that in mind, the experience has permanently soured me on visual programming. It has all kinds of flaws-- it's harder to reason about, harder to debug, harder to comment, and harder to quickly modify that plain old source code. If there was some trade-off, an upside for all that trouble, maybe it would be worth it, but I can't see one.
I used to be in the camp thinking that we should be using way more visual programming tools. I even worked at a startup company building a "software factory" (essentially a tool for generating a DB and an accompanying front-end which can load a metamodel for that DB and builds an interface for it).
Nowadays I do think that visual programming is better for domain-specific purposes. I also think that for many purposes code is a suitable abstraction layer on top of machine instructions. Meanwhile abstraction means removing nonessential detail, however for a general purpose programming language one cannot predict which features are essential in a specific application. That's why visual programming is working in domain-specific areas, because in that case you can often decide which details are nonessential.
Have you taken a look at LabVIEW? I used it pretty heavily back in grad school.
It's a graphical programming language, you connect wires between modules and operators.
Its weird to get used to at first, especially if youre proficient in text-based programming languages, but when you get a feel for letting the program flow drive the logic, you can do some pretty powerful things.
The general idea is that you have a "front panel" that controls user input, and then the back-end programming. Eg, Boolean inputs can be a variety of switches, outputs can be lights and LED's. Floating inputs can be knobs and sliders, outputs can be displays, meters, bar graphs. Very easy to add plots that update in real time.
It's popular with lab research and data acquisition users, since you can easily whip up nice UI's, and many producers of laboratory hardware provide LabVIEW drivers.
You can also easily create advanced techniques or data structures too. Eg, wrap a state machine inside a queue widget, for a "Queued State Machine".
Some drawbacks are that it's proprietary commercial software, and the 'code' can easily become a tangled mess of wires.
In a way APL is 'flowchart based programming', the flow is so simple it can be used to express what otherwise would be a program with multiple constructs on a single line. Each APL character then becomes a 'box' in your flowchart. Sort of a minimalist graphical representation of what the program does.
A unix command line gives me a similar feeling with processes feeding their output into other processes each doing some kind of transformation on their input with the | character functioning as the lines in a flowchart.
Now obviously that has some differences with an actual flowchart (such as 'if' statements) but the effect is close enough that there are some parallels.
I am not sure I see much advantage in visual programming on the small scale, ie little boxes for control flow.
But I badly want it for bigger, architectural concerns. Why do our IDEs just display lists of files in a pane? I've often day dreamed about an IDE where the system is visually modeled as a network of modules/objects, with edges representing dependencies, and you'd double click on a module/object to edit its source code.
Visual or graphical programming environments have useful applications, but I think they're always going to be niche. My kids had a lot of fun with Scratch for example, it's a lovely way to learn programming.
The big problem I see with visual programming tools though is that they prescribe the tools you can use to work on the system. I can work on the same Python scripts on Windows, Unix and iOS, in a windowing environment or a console. I can use Submlime Text, Vi, EMACS, Notepad++, whatever I want and configure them however I like. Syntax highlighting even visually distinguishes different aspects of the code in useful ways that even parallels some of the features of graphical coding environments. I can even generate code from other code, or use refactoring tools.
If your graphical tool generates text or something like XML then ok, you can do processing on that, but which is authoritative? The graphical representation or the underlying document? Now all you have is a fancy editor for what's really a text format anyway.
So I think in a lot of ways visual tools complicate things in some ways as much or more than they simplify them in others. I suspect that the domains in which these trade offs prove to be worthwhile are fairly limited.
I'd love to get an MVP for this kind of product up and running and actually do user speed testing. My money would be on comparable speed in first-time users, and higher productivity in practiced users.
Of course, a GUI's performance would highly depend on its user experience. I wonder how an existing graph manipulation program like Gephi might fare, versus something specifically optimized for this task.
I use the odd simple flowchart for documentation, but it's not a concise notation. It has no agreed method for abstraction and composition, and generally does not scale.
This is fantastic. So much has not changed in the programming curriculum at universities in 50 years - just the language and few more complementary classes.
This is ironic to me because I have seen that the other way from usual: in 1984 I was a TA at Stanford for a class whose students were grad students and faculty in the philosophy department (I was part of a team at PARC developing a new programming language relevant to the work at the newly formed CSLI). Most of them had never touched a computer before. Some of the faculty didn't enjoy being "students" again, and many didn't do the homework.
And a couple of years before I was taking a humanities class at MIT. A special section of 6.001 (introduction to programming, taught in Scheme) was being offered to the faculty. He asked me for help with the homework.
This was at a time when I think the majority of MIT undergraduates arrived without having used a computer more powerful than a pocket calculator.