Visual Programming Language

from http://www.macrovu.com/VLBkAboutTheBook.html

(Thanks to LionKimbro, below.)

Marketroid's Dream:

Build Complex Applications without having to Think

I think the distinction between "visual" and "thinking" is perhaps a false dichotomy. Images can pack a lot of information into them and make patterns apparent that text may not. "Visual" is indeed easy to hype because code scares some people and PointyHairedBosses like pretty pictures. But that does not mean that there is not merit to the idea. After all, would you want to do CADD only using textual code?

Although not a visual language, TogetherSoft's ControlCenter? is much like what I imagine an ideal tool being, while at the same time much lighter than RationalRose, and allowing for much nicer refactoring practices.

Well that's not possible yet, but imagine blending ArgoUml with AliceBot. Then you've got some active intelligence supervising. -- DennisDaniels

VisualProgrammingLanguages of some sort or another have been tried since the 1970s without success and as anyone who has ever assessed programming tools can tell you the hype is thick and fast in this space.

"Build n-tier Database enabled web applications in a Completely Visual Environment "

The above quote was from a vendor who shall remain nameless, but whose boxes are yellow in color, mention visual and coffee in the same word, and are unfortunately representative of the "Enterprise Edition" end of the tools market.

Does this prove that a useful VisualProgrammingLanguage is impossible? If not, what is the value of the above complaint to this discussion? -- BrentNewhall

So why do so many of these "CompletelyVisualEnvironment?s" suck so hard?

Because they cannot succeed until components are constructed with one language and specified + integrated with another. It is this latter medium that can be completely visual but its visual metaphor cannot be the User Interface. Instead, it must be the states, transitions, roles, interactions of the fully specified components. As long as one has to write algorithms in order to create systems, there will be no useful, fully visually, development environment. Furthermore, even with this, it still wont succeed if the visual metaphor for modeling is the UI. After all, does a blueprint look like a picture of a house or does it look like the underlying structures of the house? -- RobertDiFalco

Neither. A Blueprint is a visual expression of how to "Build" the house. If we are talking about VisualProgrammingLanguage as the language which builds the Visual Objects which represent something we use to build the real thing, it may well be that the user of the tool does not need to "program" at all. What is required is to develop the craftmanship in using the visual tools to create modules, components and representations which may be used, reused, scaled, modified, extended, inserted, dragged, deleted, and other such visual methods which are much more the work of visualization than that of programming. A cad system without a comprehensive library of pre-built modules or components is of some use, but yields far less in production if in fact it perpetuates the "re-invention of the wheel" and requires the "same thing" to be done over and over again. It can be said of Visual Tools, that some people use programming to create the tools, while others craft using the tools. There are definitely two activities involved in the creation and use Visual tools. One is the activity of creating the tools, the second is that of using the tools. This can be said to be true for other Visual Environments besides those involved in "House Building". For example "Document Building", "Web Page Design" and many more activities using the computer for other purposes than "programming".

I'll use VisualBasic to illustrate RobertDiFalco's point: There are actually two parts to any VisualBasic project. One part is the UI construction, which is completely visual, and the other part is the BASIC code. Yes, one can slap together the UI easily. However, to specify functionality, you still have to dive into textual code and understand "For" loops, data types, and "Case" statements. A "real" VisualProgrammingLanguage would let you specify these things visually. -- BrentNewhall

Why does it have to be all-or-nothing? I find that different presentation approaches each have their merits for different things. Some things are easier to manage in code, others in tables/grids, and yet others as diagrams and/or drag-n-drop widgets or icons.

Why? Because "visual ProgrammingLanguage" (a term coined well before VisualBasic even existed) means one where the programming is done via graphical elements rather than traditional textual forms, so the "all or nothing" part is just whether it meets that definition. VisualBasic does not.

The rest of what you raise is about whether it is appropriate for everything to be graphical rather than textual, which is a good question, but a different topic than the one you were responding to.

[Comments about LabView and HP-VEE moved to GraphicalProgrammingLanguage.]

Just to note, though, LabView proved that a VisualProgrammingLanguage can be a great way to express functional/stateless programming without loosing your brain. Unfortunately for functional programmers, purely functional languages make it hard to keep a specific calculation around for use in other calculations, resulting in a break of OnceAndOnlyOnce, or ugly code, or both. Having two dimensions to work with fixes that.

Lombardi's (http://www.lombardisoftware.com) Business Process Management tool is an excellent visual programming environment.

A colleague has just pointed me at BlueJ, developed as a visual teaching tool for Java - see http://www.bluej.org/about/what.html. They have started their own wiki: http://wiki.bluej.org/.

Looks like they're putting the ++ back into SmalltalkMinusMinus. :)

Comments below are rather out of context now because of the refactoring of GraphicalProgrammingLanguage.

I think VisualAgeJava is badly named (by IBM's marketing department) [...]. It got its name because of its stupid and totally unusable user interface builder, a tool that nobody (including internal IBM developers) uses. The VisualAgeJava development environment, like the VisualAgeSmalltalk environment, is a text- and browser-based IDE in the spirit of Smalltalk80.

VisualAgeJava (and VisualAgeSmalltalk) are NOT VisualProgrammingLanguages "environments where the constructs for specifying programs are made up of visual elements (e.g. pictorial, iconic, line drawings, graphs)".

Simple RegularExpression searches have always been possible in VisualAge.

I'm not aware of *any* programmer toolset in which it is possible to search for a pattern, in the GangOfFour sense - but if I were to write such a tool, I would certainly start with something more like VisualAge and less like emacs and a shell.

Jeff's question of "how those interconnected webs of links can be reliably archived let alone communicated to someone through printed documentation" is certainly not answered by "conventional" emacs/makefile environments. My own experience has been that environments like VisualAge significantly advance my ability to accomplish this feat, precisely because they allow me to represent those webs and links in persistent ways that are under transaction control.

I want to say again, however, that this has NOTHING to do with being visual. The links are implied by the information, not its representation. I therefore invite someone to refactor this exchange into a more appropriate page.

-- TomStambaugh

Granted, VisualAge is at heart a very powerful Smalltalk80-like IDE. But my impression of the GUI-builder based on using VisualAgeSmalltalk a few years ago is that it was used and useful, especially for rapid development. My concerns were that, despite its advantages, such representations are difficult to document and review. For example, what traversal order should one take in review, to be sure not to miss anything? I still think it belongs with this page (other views welcome...)

-- JeffMantei

It would be great if IBM would separate the UI builder from the rest of the environment. I agree with Jeff that the GUI-builder of VisualAge attempts to be a VisualLanguage. Jeff's concerns about traversal order and such pertain only to the GUI-builder, however. The bulk of the environment does not suffer from these drawbacks. -- TomStambaugh

Namespace conflict. VisualLanguage is more general than VisualProgrammingLanguage. Check out Robert Horn's research, and you'll see what I mean. http://www.macrovu.com/VLBkAboutTheBook.html

Ah. Here's what I wanted: http://www.macrovu.com/image/VLBkimg/vlbkwhtisvlpict.gif

Let's just stick that sucker there right at the top of the page. ;)

-- LionKimbro

Has no one here looked at Marten? http://andescotia.com

Marten is a child of the Prograph language which is now in the public domain. I have been using the language since about 1988 when it first came out and have been actively involved with it for years. Marten is a completly visual programming IDE, the visual elements are the code. Although currently only avaiable on MacOSX we are currently working on porting it to Haiku and developing cross-platform tools. One of the more recent applications built with Marten is KeyJack? http://KeyJack.com which is written entirely in Marten.

Would like to hear any comments from anyone who has used this.

-- Dave Carlton

I am wondering why SubtextLanguage isn't mentioned here. For me it shows that it is possible to fully represent a ProgrammingLanguage graphically - without loosing any semantic details. Quite the opposite: Implicit dependencies of expressions are made visible. It may not yet be a fully usable language but the only working approach I have seen yet. See the demo at http://subtextual.org/demo1.html

-- GunnarZarncke

I think some graphic/visual languages are missing from this wiki:

Limnor Studio: A visual ProgrammingLanguage for .NET currently free (April 2011) http://limnor.com/

Tersus: Commercial and open source versions (MS Windows, Linux) development of Windows, Linux, web, Android and Iphone applications http://www.tersus.com

Illumination Software Creator http://radicalbreeze.com/

Google App Inventor: Open source development tool for Android OS, http://appinventor.googlelabs.com/about/

-- Mahmoud Fayed

Programming Without Coding Technology (PWCT) Free-Open Source General-Purpose Visual Programming Languages Framework http://doublesvsoop.sourceforge.net