Hacker News Reader

Comment by pseud0r | Hacker News Reader

Visual programming is really superset of textual programming. Is basically GUIs vs command lines. These day most people use a GUI such as Windows, Mac OS X or X Windows rather than using DOS or a pure Linux command line. The issue is that current visual languages in general try to force everything into a node based language. It need to be able to describe different data structures in different ways, some maybe as text, some as tables, others as networks.

There is a reason people write books with illustrations, not pure text books, especially for advanced topics.

View on HN

The only thing that visual programming solves is the syntax element. At the end of the day that is actually one of the easiest parts of programming. Understanding your data structures and relationships can't be solved any more easily through GUI interfaces.

Guis work well for interactive stuff, but not for scripting things.

There's a reason why people draw in photoshop instead of typing the values of pixels in an array.

I think the biggest problem with textual programming isn't the text per se, but that text is used as the underlying format. I'd rather have projections of an abstract syntax tree that I could manipulate as text with different types of syntax or as various visual objects when that would be more useful.

Frankly, I never understood this objection; what's the problem with using text as the stored format? You can still parse it to an AST, render it in a visual way and then serialize the AST back to text.

I think the main issue is that code syntax is too flexible, so code generation tools create large diffs when updating manually written code. A simple solution to that is having a formatting tool like "go fmt" to adjust the latter before committing.

At the end of the day, text is just an intermediate format that we understand. Its all stored in a binary representation.

Yes, I agree. Text is too flexible (allowing you to do clever things you couldn't do in a drop down menu). A drop down menu won't allow you to make the same mistakes that a text option will, but is way less flexible.

Flow and rhythm are a thing in progrsmming, which is why structured editing continues to feel "stilted" to many people. Heck, many people don't even like static typing for similar reasons...without heavy doses of inference, it forces you to write your code in a certain order or suffer from a bunch of distracting spurious tyoe errors.

Visual programming vs textual programming is like video vs transcript. You can read the transcript of a video a lot faster than watching a video. You can not say that video is superior because it simplifies orthography and grammar issues.

I think this is the wrong way to think about visual vs. textual programming.

Textual programming exceeds at plugging into your mind, you can associate words with ideas, imagine what the program will do very efficiently.

Visual programming done poorly is just textual programming with lines and boxes, the visual queues sometimes help but often just get in the way of our mental simulation of the program in our head. However, if done with much more direct manipulation of the executing program, it can bring much of the simulation we are doing in our head into the computer, boosting our ability to think, reason about, and solve problems.

Most of our examples of visual programming are done poorly (e.g. diagram-based languages), but there are also some good examples that show off its real potential (Forms/3, AgentSheets, Pygmalion, ARK).

Yeah, direct manipulation of the program in real time.

The issue with programming is often that programs tend not do work exactly how we think they work, so we have to reverse engineer/debug them to find out how they work and then change that into how we want them to work. Especially as programs grow larger. I think visualizing the program and the state of the program can help with this, especially if the visualization can be directly manipulated.

> Textual programming exceeds at plugging into your mind, you can associate words with ideas, imagine what the program will do very efficiently.

Unless you mean something else than current day programming with "textual programming" i don't buy that for a second.

Current languages are too hung up on minutia for that to be the case.

We spend most of our time thinking about what the code does, textual representations are very efficient at that. All of the ceremony is definitely annoying, but we expend a small part of our mental effort on it. Choose even PHP, and eventually you begin imagining how the computer will execute your abstractions and stop paying attention to the cruft.

Visual programming works for DSLs ( yahoo pipes , sound synthesis , gui ... ) . It doesn't really work for general purpose programming.

That's just because you lack the tools to efficiently create new DSLs

No its because programming involves more than just piping a few command together. Otherwise everything would be written in bash with a few pipes (or a visual equivalent).

What about mathworks/simulink?

Reply on news.ycombinator.com