[Changu]

I think the reason is that text is already a highly optimized visual way to represent information. It started with cave paintings and evolved to what it is now.

"Please go to the supermarket and get two bottles of beer. If you see Joe, tell him we are having a party in my house at 6 tomorrow."

It took me a few seconds to write that. Imagine I had to paint it.

[nikofeyn]

then why does everyone sketch a picture when trying to convey an idea? text is obviously useful but so is visual information. the complete dismissal of visual programming by text-based programmers is often infuriating. visual programming can provide an immediate indication of structure and dataflow, something that text-based languages struggle with.

in my mind, the best case scenario is some sort of hybrid, where visual and text representations take over on what they're best at, yielding to the other when it makes sense. the way people work on mathematics is a great example of this. drawings, diagrams, graphs, shapes, etc. are used to convey structural information where text and symbols are used to convey more detailed, descriptive information.

[baddox]

> then why does everyone sketch a picture when trying to convey an idea?

Does everyone do that? I think I very rarely do. When I need to convey an idea on a whiteboard, it's still almost completely text, with a few extra symbols like directional arrows that I think are still effectively just symbolic written language.

Literally the only time I can remember sketching a picture to convey an idea is while playing Pictionary. The entire premise of that game is that it is much more difficult to get someone to say a specific word by drawing a picture than by simply writing down the word.

[analog31]

Sometimes they do. In my view the most prominent example is documentation for installing computer hardware and software on Windows computers. The instructions will be a series of pictures, with circles and arrows, and a paragraph on the back of each one (sic). This goes on for page after page. And when the OS is updated and the dialogs all change a bit, the documentation becomes confusing or even obsolete.

In contrast, the instructions for the Linux version of the same thing will be something like:

    sudo apt-get install this
    sudo bing bam boom
    ...

[PhasmaFelis]

I also hate that, but I always felt it was more a failure of the documentation writer than the GUI. "Click File -> Settings -> Whatever, open the Something tab, and click the "Do It" button under the Stuff subheading" can easily replace half a dozen unnecessary images.

[Too]

GUI is documentation. If you have to document how to use your GUI you are doing it wrong.

[PhasmaFelis]

It's not practical in a modern operating system to put every possible function at your fingertips and intuitively discoverable. There are better and worse ways to organize things, but there's just too much stuff to put all off it front and center.

GUIs are still much better than a command line in this respect, since with a GUI it's actually possible to find what you're looking for by randomly exploring, even if it's not always quick or practical.

[gregmac]

I quite often use UI mockups to show an example of the end result (or ask others to do the same). It doesn't even matter if it's correct, but it's a useful way to start a discussion. I've tried to do this in words but often different people have different interpretations and it simply doesn't work without a picture.

I've also found it very useful when people are asking for things that don't entirely make sense, such as a chart/report that would require 3+ dimensions. By asking them to draw an example, they realize the challenge and we can make progress.

[nextlevelwizard]

"Picture is worth thousand words", but if you just need ten words, maybe it's not worth the effort to make a picture?

It depends on context. If you want to show how and UI looks, then it's probably faster and better to just draw it, but if you want to show how function transforms a string, then it's unnecessary to draw bunch of stuff.

[killin_dan]

I consider UI mockups the perfect usage for visual programming environments. Obviously a visual product compliments a visual development interface. However, it's a very narrow realm compared to the rest of the programming universe.

It's the same as saying that drawing a picture is easier for most people than programming a picture, and it doesn't really have to do with the topic of visual programming, but rather visual design.

[gregmac]

> I consider UI mockups the perfect usage for visual programming environments.

It can be, though the type of mockup I find more useful for discussion is much lower fidelity than that.

The feedback and discussion around a mockup is related to the fidelity.

Low fidelity, such as whiteboard or large sharpie drawings, will garner feedback that discusses whether this UI even makes sense at all, if there's a different approach, or how feasible it is to present everything this way.

Mid-fidelity, such as digital mockups, will often focus more on the actual layout, text labels and contents.

High-fidelity, such as a working prototype or something done in the actual environment (visual programming environment, or even as working HTML+Javascript+CSS), will often get into a discussion about font sizes and icon choice.

If you build a high-fidelity mockup when you really want to have the low-fidelity discussion you're doing everyone a disservice. Even if your team can see past it and still has the appropriate discussion, it's a waste of time.

For that reason, even when my mockup is basically a small modification to something that exists already, I'll often screenshot it, and then freehand draw (MS Paint style) overtop of it with my modifications, using ugly 2-4px wide lines. I've tried both, but consistently found the feedback is better that way -- even when the target audience is a bunch of developers that should be able to see past it.

[killin_dan]

Ah, I see what you're saying.

Seems like you've done quite a bit of this type of work, I've the exact opposite. I guess it makes sense that the fewer data points the clients are given, the more they focus on the broader picture.

Would you often start with a napkin drawing-esque mockup, and add detail to it while cooperating with the client, or would you sometimes start with a finished HTML+JS+CSS prototype and change things up as they request?

[fsloth]

Pictures are a mission critical for my thinking and my communication in software engineering.

I would be hard pressed to discus the operation of any sort of datastructure beyond a linked list without sketching. For example a binary tree and it's traversal routines are (at least to me) much easier to understand with a picture along side the exact state.

[PhasmaFelis]

It depends on what kind of idea you're conveying. For many things, yes, text-heavy diagrams are the best way to go. If you're trying to, say, explain what a claw hammer is shaped like, that is much easier to do with a simple picture.

[ekimekim]

I find it's useful for sketching out high level designs, particularly showing how different components interact, or the flow of data through a system. Visual information in this context trades off specifics for a birds-eye view.

[killin_dan]

Godel, Escher, Bach covers this in great detail. Symbols are a weird idea in the human brain, and there are multiple pseudo languages throughout the book that when you really sit down and think about it, aren't any less ridiculous than the notation we use for mathematics outside of that book.

My idea-book (is that a crazy person thing?) is probably a lot like what you're talking about. I use words for my main data, different arrows going in between each sub-idea, and then sometimes more words attached to each arrow ("pub/subs", "queries", "happens once/happens always", etc)

I think that people who think visual programming could be a thing ought to sit down with APL for a few weekends, until they have the epiphany of "oh, the code is the same as the notation for what I'm actually doing" and suddenly they realize that notation and code are interlinked, and each are basically useless without the other, in the same sort of way that x--p--p---- is exactly as valid as 2 + 2 = 4, without context.

I get the allure of NOT having to write code, but it shouldn't be so difficult for people to realize that it's a ridiculous fantasy.

Write fibonacci(N) in ANY visual language, and tell me you couldn't have done it easier, faster, and more coherently in python or whatever. It's obvious.

[TuringTest]

> Write fibonacci(N) in ANY visual language, and tell me you couldn't have done it easier, faster, and more coherently in python or whatever. It's obvious.

  [0]   [1]    [x]
   |_____|(+)___↑ ...

[mannykannot]

> Then why does everyone sketch a picture when trying to convey an idea?

Because pictures are helpful, but neither necessary, nor, in most cases, sufficient. Just look at the use of pictures in science and technology generally (e.g. circuit schematics, Feynman diagrams), and try to imagine understanding what is being presented without reading the words.

I have seen examples where pictures can help a lot (I am thinking of a pictorial demonstration of the Pythagorean theorem, for example), but I am not aware of a constrained pictorial formalism that is both general and expressive enough to do the job of a programming language (directed graphs may be general enough, but are not expressive enough; when extended to fix this, they lose the generality.)

>The complete dismissal of visual programming by text-based programmers is often infuriating.

I, for one, would be thrilled to see an example that actually works. Arguments that it should work don't count for much, otherwise.

There are some hybrids that are pretty useful in their areas of applicability, such as state transition networks, dataflow models and Petri nets (note that these three examples are all annotated directed graphs.)

[pvinis]

Check out this video. He has a nice explanation. https://www.youtube.com/watch?v=4_SvuUYQ5Fo

Basically, painting/diagram is good for more abstract overview, and text/code is for more specific instructions.

[LrnByTeach]

> Check out this video. He has a nice explanation. https://www.youtube.com/watch?v=4_SvuUYQ5Fo

>Basically, painting/diagram is good for more abstract overview, and text/code is for more specific instructions.

very well Said ..

[abeyer]

Sketching a picture can help for certain classes of problems, but I think that is far from universal: it often tends to be of less use for logical concepts than structural ones, for example.

Beyond that, though, even when a sketch is a useful tool, I find I seldom use the computer to create it. A whiteboard, notebook, or back of an envelope all seem easier than working with typical graphical input mechanisms that are commonly available. Good touchscreens are a step in the right direction, but still far from perfect and far from universally available, especially on desktops. Aside from any innate problems with graphical programming in general, I think this input problem makes the approach generally unappealing at the moment. It's not an insurmountable issue, but until there are good input mechanisms that are as common as keyboards, I think you will just find that it is hard to reach the critical mass a new representation needs.

I know that input speed is not really a limiting factor in most programming, and maybe shouldn't be the deciding factor, but given how attached to their text editors programmers already are, and how disruptive and frustrating it can be to have to switch, I think it's clear that it is an issue.

[real-hacker]

A picture is better than 1000 words. But, which words? or for programming, which code?

Most visual programming efforts focus on representing algorithm logic with diagrams. But I think the difficulty to understand most complex programs (from my own experience) lies in the complexity of data structures, not the code logic. Reasoning about the algorithm is like reading a story, it is kinda intuitive; but for a large data structure (say a big struct with more than 20 fields), it's very hard to keep all those in your memory, you always have to go to its definition to refresh your memory, very frustrating. One of my tricks for reading a large open source project is to first find all the key data structures, draw them and the relationships on paper, then reading the code becomes easier and more pleasant. So maybe if a visual programming UI displays data structures with a visual format always on screen, it can help boost coding productivity.

[LoSboccacc]

Because that way you can abstract away lot of fine complexity and communicate higher order ideas faster

That still means you need writing to express all the intricacies of programming the details.

Alas hybrid languages where you can link developed blocks visually exists and works (bpel, webratio), but no pure visual language could let you describe the intricacies of taxation in a sane way

[hbt]

The problem with having 2 representations of the same piece of information is maintaining them in sync.

If we use text for specific and visual for abstraction, we still need to maintain both and there are no effective tools to do that without creating additional work.

[jononor]

There are solutions to this. A) Let one representation be derived from the other. Easiest by making the derived representation read/view-only. B) Encapsulate the specific/low-level details into a generic black-box, which can then be composed.

[c_shu]

Because each method has its pros and cons. It's a difference of generality and specificity.

Consider this list as a ranking: 0 and 1 >> alphabet >> Chinese >> picture.

All 4 methods can be useful in some cases. Chinese has tens of thousands of characters, some people consider the language close to pictures, but real pictures have more than that （infinite variants).

Chinese is harder to parse than alphabet, and picture is harder than Chinese. (Imagine a compiler than can understand arbitrary picture!)

[gt_]

They do that when the idea is visual/geometrical or when they use an imaginative visual model to process it, which is one of the things we actually do with text. Text evolved specifically to assist with ideas images(glyphs) could not.

[b0rsuk]

If you're referring to icons, good and clear icons take a lot of time to design.

[zepolen]

They are adding words in the form of thoughts or speech to describe the drawing.

[nikofeyn]

that's not always true. the visual representation of an idea that can also be conveyed in text can oftentimes provide additional information not easily gleaned from the text-based representation. the easiest example of this is the visual representation of the graph of a function. a more advanced one is feynman diagrams. also think of symbology that is so ubiquitous in mathematics. it's much easier to write x_n->x absolutely rather than detail out the text-based definition of absolute convergence. obviously this latter idea is close to writing a function or procedure in code that consolidates an idea to a smaller textual representation, but symbology in mathematics far outpaces that of symbology in text-based programming languages.

[wybiral]

There are hybrid languages, like Python... Visual whitespace denotes blocks while visual symbols like "if", "for", and "def" denote the meaning of those blocks.

(and sane programmers use visual layout to convey structure in every language)

[baddox]

I don't think that meaningful whitespace counts as "visual programming." That just means that a whitespace character has meaning, just like a word character or a punctuation character. It's still purely text-based. I think that "visual programming" means that the editing environment to some extent visually represents the intended outcome of the program. WYSIWYG web editing is the obvious extreme example of this. Whitespace in a Python program has no visual correlation to the output of the program.

[wybiral]

Ah, I see. But other than WYSIWYG editing I'm having trouble imagining how a language could be general purpose and could still be visually representative of the output of the program rather than the behavior of the program (much like the visual layout and syntax coloration of modern text languages conveys).

Are there other examples of those cases?

Edit: maybe I was presumptive to assume that they had to be "general purpose". Are we talking about more narrow domain-specific languages here?

[baddox]

Now that I Google it a bit, it seems you're right that my definition of "visual programming" is too strict, although I do still think that most people wouldn't consider Python's whitespace to qualify. It looks like most so-called visual programming environments are effectively visual diagrams of standard control flow mechanisms like loops and conditionals.

[wybiral]

The point I was trying to make is that the text in a programming language like Python is like a visual diagram of standard control flow mechanisms. I can see the for loop, what it iterates, and what the body of the iterator is. The language has visual clues. And with syntax highlighting it's even more visual.

But, I get that there is a class of visual languages, often dealing more with interconnected nodes like a directed graph, for which graphics might be better at communicating. But they seem more domain-specific rather than general purpose programming (like most text languages).

[azhenley]

I think the "visually representative of the output" isn't a suitable way to describe it.

The visual language I always think of is LabVIEW. It is very different than a textual language.

[posterboy]

No it's not. A for loop is a block with inputs, a space for sub-blocks, and outputs. To add an iteration limit, a box with a literal number can be attached. This is visually represented of the program's flow graph. Which does make sense when actual signals are concerned, to extend the wire metaphor of analogue equipment. Reason did that too, where instruments had a back pane to connect them to effect panels via actually visualized wire plug-in. Buzz or unreal blueed apply the same idea, as does model-sim. Block diagrams are just a very popular abstraction in signal theoretic topics. So Algol syntax, the languages like C being close to the hardware, uses the same visual metaphor.

Erlang (Prolog) for example doesn't so much. Sure you have parameters, but matching blocks aren't strictly evaluated in sequence.

[david927]

So do you use text files for storage or a database? Is your company's accounting system in Word or Oracle?

Are programs text, like a novel, or is it data? And to find out, would you query Moby Dick? Not really -- at least that's not how it's meant to be consumed. You read it from beginning to end.

Would you read your program from beginning to end or would you query it? You query it, exclusively. I submit that programs are data, not text, and visual programming then becomes like data visualization. Text is holding us back.

[yjftsjthsd-h]

> Is your company's accounting system in Word or Oracle?

Accounting uses numbers, which in this context is text. If you replace a spreadsheet with a graph, your accountants will murder you.

[david927]

which in this context is text

Ha! Nice try. You program in a text file. You don't get to somehow call that a spreadsheet just to make your argument sound better.

My whole point is that we need to turn that free text into a spreadsheet (from which graphs can be produced) and "your accountants will thank you".

[michaelmrose]

Why is it that only very simple programs can we written effectively with spreadsheets and that setups where complex arrangements of linked spreadsheets and databases are described as horrible to work with by the people that have to work with them.

Is it possible that nearly every professional is right and you are wrong and text is an effective means to represent computation.

[david927]

Why is it that only very simple programs can we written effectively with spreadsheets and that setups where complex arrangements of linked spreadsheets and databases are described as horrible to work with by the people that have to work with them?

I completely understand where you're coming from. I'm saying, "try to imagine how it should be," not, "how it is." Those experiences are horrible because current spreadsheets are for simple functions and nothing more.

Is it possible that nearly every professional is right and you are wrong and text is an effective means to represent computation?

I guess this is where we disagree. I see the software industry as a mess and every professional as a person who was given one part of a Rube Goldberg contraption to be an expert on. The contraption works, to be sure, but it boils an egg in a hundred arcane steps. Given the state of our art, we have no leg to stand on to say what is and is not an effective means to represent computation. Normally a billion professionals would lend clout to your argument, but in the case of our industry, we know that they just staff a million abstruse contraptions. It just means we lack imagination and ownership: we're professionals, yes, but on whatever junk we're handed.

It wasn't always like that. We have seen that Computer Science doesn't really advance, but what is fascinating is that maybe 90% of those pushing for it to advance are of the original, older, generation that brought us that innovation in the first place. Max Planck once said something to the effect of, "Science advances one funeral at a time." I worry that Computer Science retreats one funeral at a time. Slowly we're losing those from the time when our thinking wasn't constrained with current tools; failed efforts were taken as learning points, not barriers; and no one viewed current technology as something the gods handed down to them but as something they created (maybe the day before), so they were constantly evaluating it.

Yes, the future of software development has to be away from free text toward data, and it follows as a logical syllogism. I was about to add that that is my opinion, but it's not so much of an opinion as a conclusion. While it's absolutely fair to wonder what that means, we can't brush it away because we already have the best Rube Goldberg contraption we could ever have.

[alephr]

So, to be clear, you're saying a spreadsheet is the same thing as Word or vim?

[afarrell]

Right, code is data. But the interface to write and modify that data is text.

Consider, how long does it take you to draw an infographic representing the percentage of the United States that has a college education? How long does it take to modify it when you realise it is a mistake

Now how long does it take you to represent/change that data with text?

[david927]

Your example is strange. Changing the text and changing the data would require the same amount of time. And a graph would, in fact, instantly put that change into context.

Right, code is data.

Not now, though. Currently, code is text -- it's not data. That's the problem. And, yes, currently, drawing it instead of typing out the text is a horrible idea. We agree.

But remember, currently, we're failing. Software is a disgrace of an industry, in all honestly. It's mired in undue complexity. It's a Rube Goldberg contraption that we all, somehow, take seriously.

Imagine a better future. Imagine visualizing a complex set of rules and seeing all the places where a change would cause knock-on effects. Imagine being able to manage your code base in a way that doesn't require you to download it all into your head. Hell, imagine a decent IDE. The first step for all of that is to move it from text to data.

[kpil]

I think you are chasing something that does not exist.

While i submit to the idea that programs are "data", and could be represented not just like text, the expressiveness when using a visual representation is small, but the exactness is as high as normal languages.

I've seen large visual-programming programs, and they explode into complexity, and I think there is a reason for that, the expressiveness of a symbolic language using text is so much higher.

Could we increase the expressiveness even further? English have high expressiveness but is inexact.

I don't think it's possible to increase the expressiveness and keep the precision - at least without some sort of intelligent agent that can reject interpretations that makes no sense.

So - when general AI is invented, we can probably soon write programs that are very inexact, highly expressive, but still work.

Until then, we will have to continue wrestle down the computer to obey our if-statements, one by one.

[joshmarinacci]

Visual programming does not have to mean 100% not text.

https://joshondesign.com/2014/08/22/typopl

[yorwba]

You talk about the compiler having to be sufficiently smart, but I think you actually just need good IDE support, then you can store the code as text but display a nicer rendering.

E.g. the image literal could actually be Image.loadFromPath("../.../image.png"), but you don't see the code unless you want to; and if you drag and drop a file into your program, the IDE automatically inserts the corresponding code.

[rsl7]

Yes, there are probably lots of useful interaction methods to be found in between text files and the "boxes and arrows" visual programming (circuit design) model.

[afarrell]

> Changing the text and changing the data would require the same amount of time.

Really? really?

Open up powerpoint, openoffice, or whatever you use to make infographics. Also open up vim, atom, or whatever you use to edit text.

Time yourself clicking and dragging to make a graph in one and then typing to write a number in the other.

> Imagine a decent IDE

I'm imagining something where you are able to select visual elements without either clicking and dragging or doing an O(n) walk by hitting alt-tab. But I can't imagine how you acheive that, much less efficiently specify how you connect things up and how you write automated tests.

Some of this is my failure of imagination, but its still on you to provide the sketch of a proposal if you want to convince.

[alephr]

How do you navigate code now? Do you walk through code line by line or do you search or use some kind of navigation that relies on the structure of code?

I agree that a concrete product is probably going to be required to convince people who aren't good at thinking outside of what already exists, but these kinds of comparisons just feel absurd. Maybe a better way to think about this sort of thing is "how can the structure of code be used to simplify and improve working with it"; the term visual programming is just too loaded in negative ways.

Edit: I don't mean to sound insulting when I talk about thinking outside of what exists. It's not always an easy thing to do. But it becomes an issue when you it causes you to let previous attempts narrow your views on what something is.

Visual programming doesn't have to be, say, exactly what's scratch is today. It doesn't even have to be close. The two keys IMO are utilizing the structure of code as well as the inherent visual processing power humans have.

This doesn't mean no text, it means expanding how we think about operating on and viewing code in a way that makes it easier (and thus more productive) to do.

[afarrell]

Okay. I'm on board with you there. I suspect that SQL or data-model rendering would be the easiest place to start there--allowing you to auto-generate a visualisation from SQL. If that got widespread enough, then it would become a standard way of representing the data that is currently represented by text. That means you can build interactions on top of that understanding.

[c3534l]

> It started with cave paintings and evolved to what it is now.

Actually, our writing system evolved from accounting tokens. Eventually we learned we could save on little figurines by pressing the one into clay a bunch. And at any rate, writing encodes speech and is severely limited to the limitations spoken speech has. Rather than be well-optimized, writing is severely limited by tradition, by the physical limitation of auditory communication, and by the physical limitations of encoding it into paper.

[mekkkkkk]

"Painting" it in this case would be a flow chart thingie with an action leading to a decision tree with two outputs. Not extremely complex, and with a bit of practice and a good environment, it probably takes about the same amount of time as writing.

There might be other cases where this is not true, but I think the major gains with a proper visual environment would be on a higher abstraction level. Visualizing the architecture of a project, tracking dependencies, etc.. Basically tasks where your "takes longer to draw" argument is nullified by the fact that it is the computer that does the drawing.

[wwarner]

I think this is exactly right, but I would add that when we start using computers to analyze and help write programs, faster, more intuitive ways of programming will emerge.

[humanrebar]

Even harder with pictures, searching and, sharing, and refactoring:

"Joe has been way too busy yesterday. What did you ask him to do in the last week?"

"Yeah, that's too much. Just ask Jessica to do the emails going out next week."

[badminton1]

Well, it depends. If we had to describe the situation in very graphic detail, then images can be more succinct.

[hasenj]

Exactly! I'm actually bewildered why some people think visual programming is a good idea at all.

[crazygringo]

I suspect it has to do entirely with affordances.

Programming in text, you have to learn, in advance, what the commands are that you're allowed to type, and remember them. That's a heavy up-front investment.

Visual programming generally makes it much clearer exactly what your range of options are -- the goal is for the learning curve to be far easier.

[Too]

Good autocompletion with intuitively named standard library comes close to this. When coding c# in visual studio I very rarely have to look at documentation, you just guess what the class or function might be called and get the options presented for you.

[hasenj]

Could be an interesting feature for IDEs to start studying certain control structures, not just function calls and parameters.

[pier25]

I know a guy who does all his projects using Max MSP and loves it.

It's obvious that visual programming is much less expressive than writing code, but it's attractive to people that are afraid of code or are too lazy to learn a new language.

[eon1]

I know a few people who do this, too. They're almost invariably awful about it and completely convinced they're on the "right track" over people actually writing code, too..

[sidlls]

It's one avenue of exploration to (further) commoditize programming.

[yjftsjthsd-h]

Zero syntax errors.

[Too]

This is also one of the beauties of text programming. It allows temporary syntax errors while restructuring things.

I've used many visual tools where every block you laid out had to be properly connected, so in order to refactor it you had to make dummy blocks as input and output and all other kinds of crap. Adding or removing arguments and return values of functions/blocks is guaranteed to give you rsi from excessive mousing.

[erk__]

Have you tried using Drakon[0], I really like to use it to visualiase algorithms. It also supports "syntax erros".

[0]http://drakon-editor.sourceforge.net/

[GuiA]

请你到超市去买两瓶酒。如果你见Joe，告诉他我们明天六点钟参加派对在我的家。

Here, that was quite fast to paint. Would have been even faster with a proper brush instead of a keyboard :p

[ghurtado]

If that was a painting then surely I would have some remote idea of what it represents. As it is, I (and many others) don't.

[threatofrain]

Maybe he's making a joke about how Chinese characters evolved from more pictorial-like elements, and are in a sense abstractions over pictures.

[BenjiWiebe]

Unless it was modern art, of course.