I do, however, think programming languages could benefit from more visual augmentation. A program, over time, takes on more complexity than a programmer can hold in his mind, and eventually, the program's design will elude him. A disconnect appears between the text he types in the moment and the original design of the program. The sum total of the program's code no longer resembles the problems at hand.

Here, I think, visual tools are underutilized. Not as code crafting tools, but as tools for reflection. Reflection on dependency trees, deviation in style, orphaned code, the ability to visualize how and where data might flow in unexpected ways, etc. Webpack's stats.json comes to mind for dependency tracing. Statically typed languages obviously have a leg up here.

I do understand the implication that lowering the need for always faster hardware for end users will slow down the pace of development of new hardware. But with the end of Moore's law upon us, that's inevitable anyway.

Our computers are plenty fast today, beyond what we could imagine when each of us started programming. Let's cut down on abstractions. Let's profile, optimize.

Though I wish more time was spent on some tools to make them more memory efficient(I'm looking at you, scala and friends), that's just not how it is today. I just bought a new laptop with 32 gigs of ram, and hopefully that is future-proof for the next few years.

The other guy that replied to your comment is basically right. My old laptop had a measly 4GB of RAM, and opening multiple tabs in Chrome for documentation, running an editor, some development tools like REPLs etc, and I'd basically be out of RAM. I would literally listen to music on my phone because spotify consumed too much of my precious RAM, and I had to kill off tabs that I hadn't used for a while like it was Survivor, in order to keep my laptop from start swapping(which means everything grinds to a halt).

I even run a very minimalistic window manager and don't use IDEs like IntelliJ or anything.

A better solution would be for testing, particularly UAT, to be done inside resource-constrained VM's, instead.

I fear cheating would be too easy, though —just lift the restrictions.

Humans are really good at remembering spaces. ("Describe for me your childhood bedroom." or "What did your third grade teacher look like?")

There's already the idea of "memory palaces" [1] suggesting you can take advantage of spatial memory for other purposes.

I wonder, what would it be like to learn or search a codebase by walking through it and looking around?

[1] https://en.wikipedia.org/wiki/Method_of_loci

Some humans. I honestly can't answer you those two questions. I'm much better in remembering what I just read than what space I just saw, and I absolutely suck at remembering (not to mention describing) faces. If you mugged me I probably wouldn't be able to describe you to police beyond the basics like gender and height (I probably won't be remembering what you were wearing).

I say this because being good at remembering spaces is like "everyone sketch a picture when trying to convey an idea" elsewhere in the thread - both are examples of what some people do, and it may be surprising to discover that not all humans are good at it.

No reason for concern, but there is supposedly an incredibly low occurrence of either.

Making these visualizations central to the IDE would be exciting.

All the IDEs I use are more like:

    Yet which IDEs aren't simply really _horrible_ text editors with some refactoring help built in?

Not my favourite but absolutely not horrifying to a student.

Now that I think about it though I wonder what huge merges look like.

For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs. The UI looked a bit like UML, and it worked nicely for anything resembling "Hello world" complexity (anything more complex literally became hairy to look at). Since then I've twice found myself on projects where we had to work with visual programming tools (caused by skilled salesmen and inept managers). In both cases the only sensible action was to pound the "eject" button until we were catapulted away from the monster. All in all I consider myself vaccinated at this point.

As for my reply to the question of the OP, I'm not sure that it differs much from everyone else. The main reason that it will never catch on, IMHO, is that the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it. Also, every serious text based programming languages offers plenty of ways to hide complexity away, allowing you to focus your thinking at the desired level of abstraction. Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things.

That being said, I think visual tools can be a good fit for tasks whose output is UI. There are applications and frameworks that allow you to drag'n'drop to compose the UI, but the code is still written in a text editor. This can work reasonably well.

https://mathworks.com/help/simulink/examples/anti-windup-con...

Obvious lectures from this:

1) Don't be silly and copy a text based language into visual blocks. Nobody wants to drag&drop the components of a while loop or click a box to enter a variable name. If you have variable names, you probably failed this one already.

2) It's about the data, stupid. There is very very little explicit control flow in Simulink diagrams. Instead it's all about the flow of data.

3) Seriously, nobody wants to click together while loops. Simulink works because it has a very large and very powerful library of blocks that you need just a few of at a time to build very complex functionality.

- First is the most serious, debugging: this is a deal breaker alone. Once your code will go into production, and once, bugs will be found in it. How do you debug it? A typical variable in simulink looks like this: `Simulink_Sum_Node_4521` (something similar, I don't remember exactly). Yes, that is a variable in the c code generated from simulink graphs. It's index start from 0, but you have quite a lot of it - just count the operations in your normal code, and don't forget that (a+b)/c already contains 2 operations! Not sure if the original programmer was lazy to name them all, but not sure if it is possible to meaningfully name them either. If you want to get (a+b)/c^5, (a+b) might not have a meaning on it's own. So you stuck debugging a 10k+ lines long file containing variables like this.

- Reading is natural: we read from early childhood, we write from early childhood. Did you draw computational graphs as a kid? In school maybe? Yeah, me neither. When I want to tell my colleague a formula, I'm not going to draw him/her a computational graph, I'm going to write it down. Hell, you are reading right now, and not looking at a graph consisting words and arrows that represent relations! Imagine how that would look like...

- Graphs take up much more space on the screen than text. Grab a pen and draw a computational graph of a Fourier transformation! It takes up a whole screen. As a formula, it takes up a tiny fraction of it. Our state machine used to take up about 2m x 2m on the wall behind us.

- Also the other reasons already written in this thread...

Working with simulink convinced me entirely that graphical programming has no future whatsoever.

A few remarks off the the top off my head:

1) Visually, it reminds me of electrical diagrams, perhaps taking it one or two steps up the ladder of abstraction. I can see how it might be an appealing notation for someone trained in electrical engineering, which may explain its usage in cars. It's really interesting how different "cultures" find different solutions to similar problems.

2) Still, and this may be unfair since I only glanced over it for a few minutes, it strikes me as more of a niche thing than as something that I'd describe as a general purpose language. It seems fixed at a certain level of abstraction. Probably just the right level of abstraction for configuring your car firmware, but impractical for authoring a complex piece of desktop software.

Maybe the future will prove me wrong :)

It'd be interesting to see if there are any existing solutions in other domains.

But there are also many more such successful tools being used industrially, esp. from Siemens.

The biggest problem with it are diff tools. There exists a graphical diff in the toolbox, but I haven't seen it being integrated in its workflow yet.

I also believe simulink has been used mostly for simulation therefore it's name and not programming. However now you can generate code from your model.

The other day I saw a crazy guy with a mechanical contraption that, according to the guy, moved by burning wood! The guy was demoing it at the town. He filled it with wood, and then had to start the fire. The crazy machine got so hot that nobody could get near it. The thing barely moved a few meters and then Kabooooom!! it exploded in a black cloud. What sane person may ever believe that one of these contraptions could be useful?

Am I right? Are you right? we don't know. Research is the only way to know.

The first visual programming language I can find is from 1966. They have always been tiny, niche things over a period where we've had waves of text-based languages rise and fall.

One of the striking things for me when I talk with visual programming enthusiasts is that they very rarely have looked at the decades of research. And if you try to talk with them about the history, they seem actively averse.

There's a joke that some people have ten years of experience, and some people just have one year of experience ten times over. My experience has been that visual programming is more like the latter, but for 50 years.

Honestly, I feel part of the problem is that this seems to attract people who think that text is bad and more visual = better, while the truth probably is that you need to be really, really careful to arrive at something that doesn't explode in complexity when confronted with all the little details of ordinary programs.

Even there some people claim it works better for micro scale: widgets are ok but larger scale composition (storyboards, composing dynamic views from re-usable sub-views) are better done in code.

> I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers.

Perhaps the intutition is right, but the problem is too general and thus very hard to solve. And I think that, looking at the general trend, it does seem to evolve towards something better with every new generation.

Not the first and not the last idea like that.

We're just not there yet.

> For my master's thesis, some 15 years ago, I programmed a system for visually composing and executing Java programs.

Similar experience here [0]. :) But for me it was a year ago, so I guess I represent a newer generation.

> Since then I've twice found myself on projects where we had to work with visual programming tools

I worked with some too, mostly Unreal Engine 4. Fortunately all for education, not for work. ;)

And your experience is probably a good picture of the state of the art in this area, if it comes to complex and more general-purpose application development.

> The main reason that it will never catch on, IMHO

I'm still a believer. But probably not in my generation either. ;)

> the text editor is far better for managing complexity. It's easy to search for stuff, and it's easy to move or copy it.

True. Compared to a visual editor of today.

For this and other reasons, text coding can't and will not be replaced with visual coding. Visual programming, I think, should be thought of as an extension of text programming.

So I think that visual editors will only start becoming successful and more wide-spread among regular developers when they stop being visual-only. Or, in other words, when they stop eschewing all the good parts of text-based environments. Visual programming should complement text-based programming. Not replace it.

> Visual programming tools -- or at least those that I have met -- instead force you to deal with stuff that doesn't matter (such as aligning boxes and arrows), and views very quickly become cluttered when you start connecting things.

It's almost like coding in text without the editor helping you with indentation and structuring of text. You have to arrange boxes and connections yourself.

This is one thing that illustrates that some visual languages are really a few steps back in evolution compared to text languages.

But there are visual environments (e.g. Scratch and the like), which do help you with structure.

Anyway, I'm tired and it's very late, so I'll end here. Cheers!

[0] (copy-pasted from my previous comment):

(a screenshot from my project) http://djedr.github.io/gfx/masters-thesis/ide-prototype.png

(link to my thesis) http://djedr.github.io/masters_thesis.pdf

"As soon as a problem in AI is solved, it is no longer considered AI because we know how it works." [1]

Similarly, as soon as a successful visual interactive feature (be it syntax highlighting, trace inspectors for step-by-step debugging, "intellisense" code completion...) gets adopted by IDEs and become mainstream, it is no longer considered "visual" but an integral and inevitable part of classic "textual programming".

[1] http://www.artificial-intelligence.com/comic/7

And we should definitely keep researching stuff, even things which seem like a long shot. We'll almost always learn something useful in the process.

The future will tell I guess.. :)

"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.

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.

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.

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
    ...

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.

One thing that's rapidly improving on the command line side is Search. On my modern Windows computers (8 and 10), I don't search for things by hand in the dialogs any more. I press the Start button and start typing text.

For instance, Start plus "device manager" brings up the device manager, whereas I have no idea how to find it in the menus.

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.

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.

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.

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.

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?

That said, some people just can't picture how things look unless you show them how it looks, and in the past I've worked with clients that would think it's literally a joke (and probably fire me when they found out it wasn't) if I come to them with a sharpie drawing.

I think the only times I've gone to a more high-fidelity version up front is when the client/stakeholders had no idea what they really wanted. A "finalized" mockup can start the discussion (even if it turns out to be entirely wrong) and then be used to get into the low-fidelity whiteboard/sharpie mockups. The important thing is to keep the discussion focused on the right thing, and don't stray into fonts/images/icons if you want to talk about the overall structure and what pages even should exist.

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.

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.

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

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.)

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

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

very well Said ..

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.

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.

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

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.

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!)

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?

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).

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

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

LabView is more of a data flow graph than a control flow graph, aside from the boxes that represent deviations from the usual rules (For loops, conditionals, sequences, etc.)

This isn't as much pedantry as it might seem... this is one of the big differences between LV and 'traditional' programming... LabView evaluates its data flow graphs in data-dependency order, which can also mean evaluations are done in parallel. (IIRC, for linear execution speed, wires in LV all have a fixed type and blocks can be compiled to machine code with an LLVM back end.)

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.

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

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".

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

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.

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?

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

Most of us don't do that. Most of us make due with off the rack suits with some tailoring for 1/10th the price.

With programming we have an expectation of bespoke design, so anything less, even if it's much easier, seems lame.

A potentially useful reframing of the question is, "What are all the common use cases that could be solved sufficiently with significantly less effort using visual programming?"

the big examples i have in mind are: * spreadsheets -- very visual, everything's in a grid. the relationships are spatial. * electronic music -- people lay out their various effects in a flowchart format and chain them from one to another * video games -- consider a game like RimWorld. you're clicking on all kinds of things and specifying what you want done with them. the behavior of the actors in the environment are modified by your specifications.

So, it's all in various optimized subdomains. As it should be!

Most of the things you do are achieved through a visual programming environment specialised for that particular task. Maybe text-based source files in complex directory trees, managed through a structured text editor with UI composition helpers represents one kind of specialised visual programming environment as well.

[0] https://www.theverge.com/2012/5/21/3032765/minecraft-emulate...

Visual programming efforts have tried to visualize code and operate at the wrong abstraction. Programming is just the act of creating programs. In a visual programming environment, the author / programmer should use visual interactions to "write the program". This means a few things needs to be considered:

- the representation - how is a computer program represented? how is state represented? - direct manipulation - imagine using a tool like Photoshop having to compile / build to see your changes between every edit. - input devices - mouse / keyboard works for writing lines of code. Touchscreen is a better input device / interface for visual programming but still lacking (no tactile response).

In my opinion, not enough is reinvented when visual programming efforts are tried. I think the entire stack (human input --> program state) needs to be reinvented and reconsidered. Bret Victor has a great section on visual program in his FAQ for one of his talks - http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...

xoL is a graphic based programming language. It represents programming concepts with graphics instead of text. It is product of a long, painstaking design effort, to get an optimal graphical presentation of programs. A good description of it is available in this blog post: http://lignixz.github.io/blog/posts/17/xoL_graphics_based_pr...

A partially working prototype from a previous version is available online. The newer current design has fundamental improvements over that previous prototype. The way some program elements work was redesigned. The control method was also redesigned. It is now aimed primarily at touch based controls. Here is the prototype for the previous version: https://github.com/lignixz/xra9 . The prototype is not optimized for performance so excuse that. It is functional to some extent, if you can figure how to use it. You can add and modify programming elements.

Would welcome any opinions/feedback. Also interested in finding partners/investors/sponsors that may be interested in this project.

I thought about using something like a prototype called Hydra (1) as a sort of runtime for evaluating graphs. Anyway, I really want to get back to it at some point but other cool things that are slightly more low hanging tends to get in the way. :)

Another nice inspiration for these things is Ecolanguage (2), not really programming related but a diagram language for visualizing economic transactions.

(1) - https://github.com/giorgidze/Hydra (2) - https://www.youtube.com/watch?v=-QI1iuAvTKE

Let me start with a quote from Brian Kernighan "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

When you make a graphic based programming language the debugging better be twice as good as the programming and this includes when things get really difficult with lots of threads, or when the over arching abstraction breaks at some low level and you are exposed to the underbelly of the CPU. At least C++ lets you gracefully traverse from the very high to the very low which is why it is favored in the end, you are never stuck you can always go lower.

Also, for anyone interested it looks like he just posted on HN for the first time under user 'worrydream'.

Watch his 2 talks that highlight the thinking and inspiration behind the RealTalk project:

https://www.youtube.com/watch?v=klTjiXjqHrQ https://www.youtube.com/watch?v=agOdP2Bmieg

VP also hides away a lot of implementation details from you, and assumes the computer will be able to figure out something better than the programmer. For example, when would the dropdown run the SQL query? on page load? on drop down open? As you scale the app bigger, you may want to run a single SQL query and then chop up the results and hand them out to several dropdowns. If your VP interface doesn't support this then your done for, but with code there is always a way.

There is always Clojure of course, which lets you edit your GUI while the app is running, and upload code changes without having to rebuild, allowing you to tweak stuff as you go. REPL driven development is great as it gives you both the flexibility of written code, as well having close to the interactivity that VP offers.

You seem to be dancing around what I came to comment on, and that is event driven programming. It's OK for simple UIs but it tends to break down as complexity increases.

For example what I did was to code a server part in golang and use vue.js on the frontend and for the app builder. Using the web-based app builder (also 100% vue) the user can design forms. The forms are stored as serialized JSON in the database and the server renders dynamically vue.js components. It's super fast. And there's a complete freedom to design any form with a 16-column responsive grids and a lot of widgets and styling options. Forms are also nestable (thanks vue!) and completely extendable with custom JS code so it's possible to create a custom widget and then simply import it in other parts of the app.

As I said I think the shadow DOM and frameworks like vue really made the difference. I started without using such frameworks and it was not only tedious, but the resulting app wasn't very interactive and felt like a customized Excel spreadsheet attached on top of a PostgreSQL database. Now it's a completely different story - it's easy to build fully reactive apps that feel like a "normal" cloud app and are actually pleasant to use. Of course instead of spending few months designing and building it, it was created in a few hours.

So yeah... I think that drag-n-drop builders are definitely coming and will probably eliminate the need to write such apps in coming years.

For anybody interested -- email is in profile. Happy to give you a sneak peek!

That's why I don't target primarily developers, but the end-users of such apps. Of course knowing Javascript wouldn't hurt, because it opens a lot of more possibilities to further extend the entire app, but my idea was to make it possible even for non-developers to create apps for CRM, invoicing, accounting or inventory management for their needs. So in my case it's not really visual programming, but a drag-n-drop builder, which also has an integrated code editor in case the user needs it: if they know SQL, awesome - write a custom SQL and it is automatically mapped and available in the forms.

This sweet spot that you talk about between ease of use & flexibility is definitely key.

I'm honestly more concerned with maintenance costs more than building costs. In my experience the cost of the alpha release goes down with visual editing, but the cost of subsequent releases ramps up over time.

https://news.ycombinator.com/item?id=12092527

People were saying that 10 years ago, they were saying it 20 years ago, the general attitude was even the inspiration for COBOL (that business people could write their own apps). Every single time it ends up being a disaster when it comes to slightly non-trivial use cases.

It's been tried and failed by companies large and small for decades. So what do you know or do differently that they didn't?

A big difference that I've noticed is that in a visual scripting language, the "nodes" in the graph can change their shape/color/layout/etc based on what type of node they are. I love this. With blueprints, if I'm putting together a material and I put in a color node, a color picker shows up. If I put in a TextureSample node, a little picture of the texture shows up. In a text-based language, every variable is just a string of characters - if you want to be able to tell at a glance what type of object a variable contains, you need to adopt some kind of a naming convention (or use an IDE that highlights them).

Debugging in unreal is also really cool. The "code paths" light up when activated, so it's really easy to see exactly which branches of code are and aren't being run - and that's without actually using a debugger. Side note - it would be awesome if the lines of text in my IDE lit up as they were run. Also, debugging games is just incredibly fun and sometimes leads to new mechanics.

I initially thought that organization would be a problem, but it turns out that you can make functions just like any other programming language, and encapsulate blueprints inside of them.

There are also some things that I don't like about Blueprints. Typecasting usually involves an extra node which feels verbose. If/thens are handled with a "Branch" node, which again feels verbose.

Alan Kay's mistake is that a lot of his original work was with Papert on educating children. For early learning, having a visual/physical analog adds value. For professional work, when you already have the concepts down, it just gets in the way.

- Humans are centered around linear communication. Spoken language is essentially linear, with good use of a stack of concepts. This story-telling mode maps better on a linear, textual representation than on a graphical representation. When provided with a graph, it is difficult to find the start and end. Humans think in graphs, but communicate linearly.

- Graphs are rather hard to manipulate. You invariably need a mouse, which is a rather slow instrument. Using keyboard combo's is certainly possible, but is difficult to make intuitive.

- A textual representation can be left in a syntactical incoherent position while editing. For example, I can have non-matching braces. This proves very helpful in quickly editing code. Visual programming paradigms generally require a coherent structure, in order to keep them editable.

- UI builders are extremely valuable, but this is technically not visual programming. UI builders have problems as well. Complex UIs are often parameterised (the fields themselves are variable). By offering a visual context and a textual context, the coding experience can become incoherent and more difficult to learn.

- Programming is very context dependant. A programmer focusses on a specific part, mentally forming a high-dimensional representation of the algorithm at hand and the larger context. Using a visual representation possibly competes with the mental map. Also, it forces upon the reader a scoping.

In other words, VP itself is a red herring. The leap that needs to first to be made is that from text to data.

*https://www.emaze.com/@AWOCZQLL/Text-is-for-Novels

In reality, programming has been stuck in the text approach for many years. Perhaps some people take that as evidence that there is no more progress to be made. Another factor that may be undermining research in programming, is the AI boom. Perhaps some think that AI will displace programmers in a not too distant time.

I agree with you that programs are data. And would benefit from a more specialized representation. I have been researching the aspect of program logic. For example, one thing that I think is terrible in programming, is deep nesting levels. That makes it complex to follow programs. I have been exploring ways to improve that. In my opinion graphical visualizations can provide ways to improve that.

If your data structures are more complex and require more convoluted logic, which is more often the case than not, then the benefits of visual programming diminish and the downsides are much more apparent.

But I agree that's an intrinsically different problem than what OP is describing, which is essentially a WYSIWYG editor.

Also high-mean IQ dev outfits are likely to produce tools for people like themselves. "Cognitive empathy" is not going to be a strong point for the framework creators at Google or Facebook. Microsoft seems to have quietly abandoned Lightswitch, which was their last high-profile attempt in this space.

Finally market forces mean that working developers have no incentive to adopt simpler technologies, so there is no pressure on vendors to simplify things either.

UI creation is best handled by a WYSIWYG editor, animations are nice to visualize on a timeline, and math formulas are clearest when written as is.

Picking the wrong model creates a mess. Try to express a sorting algorithm as a flowchart. It would be too difficult to follow. Yet a business process is great to model as a flowchart. A picture is only sometimes worth a thousand words.

Take a look at the papers published from VPRI, the research org founded by Alan Kay. They have built languages for graphics, parsing, stream processing--each optimized for its particular domain. They could have used a general purpose language but it would have resulted in much more code than necessary.

So the question everyone should be asking is: why hasn't a multi-paradigm programming environment taken off?

I disagree with those two. UI creation has generally evolved away from WYSIWYG, composing a UI with code is a much better approach and is now nearly the universal way of doing it. For the business process, the flow chart only works as an extremely high level overview, the implementation is always done in something like code.

Why is it a better approach? Universal does not always mean better. Javascript was built in 10 days and it's now universal.

> the flow chart only works as an extremely high level overview, the implementation is always done in something like code

I agree here. The core point I am trying to make is that one size doesn't fit all and we have to mix and match approaches based on the problem.

Easier to diff, easier to copy paste, easier to upgrade and easier to extend. In the 90's we had both approaches and it was the code based (Qt, GTK) and declarative (html, xaml) systems that (mostly) won.

If I'm working with win32 or winforms then I love the UI designer, but that's because they come with an awful API, for anything else I'll take the code approach.

Graphical programming also walks away from a huge body of work dedicated to managing, searching, and manipulating text. As good as the graphical tools can be, there's nothing like all the work that's gone into text editors, diff tools, query languages, etc. These are all things that are central parts of my programming workflow, and they are all missing or considerably weaker in a graphical language. (This is not to mention the fact that graphical programming gives up two hands and ten fingers as input devices in favor of one hand pointing and clicking with a mouse.)

I think as appealing as the idea is, whatever benefits there are don't outweigh the considerable costs.

Progress in programming is in removing the accidental complexity to get to the essential.

In the vast majority of domains, visual programming injects huge amounts of accidental complexity utterly irrelevant to the domain. So it isn't really surprising that despite it's superficially appealing elevator pitch and uniquely pretty demos, it doesn't appeal over the long term.

The domains where it works are those where the complexity is limited, or where the usually-accidental complexity is actually fundamental... for instance, in circuit layout the usually-accidental issues involved with layout actually correspond to something.

Visual programming is firmly established in some nights, and I expect it to stay in them indefinitely.

  static string defaultFamily = "Sans";

  bool
  foo(string s, Alignment a, int height)
  {
    Par_

  bool
  foo(string s, Alignment a, int height)
  {
    Font f(defaultFamily, height);
    if (!f.isValid()) return false;

    Paragraph p;

    p.setAlignment(a);
    p.setText(s);
    p.setFont(f);

    <#rest#>_

    return true;
  }

Even better, you could just throw items together and get the result:

  // this->points is double[20];

  {
    frame inset 0.5 red stroke;
    add points black stroke;
  ---
  {
    Rect r = this.frame();
    r.inset(0.5, 0.5);

    Painter p;
    p.setColor(Color::red());
    p.addPath(rect);
    p.stroke();

    p.clearPath();
    for (point in points) {
      p.addPoint(point);
    }
    p.setColor(Color::black());
    p.stroke();

  int
  foo(string s, Alignment a, int height)
  {
    ParadoxDatabaseProvider_
    ParadoxDatabase...
    ...
    Paragraph
    ParamsManager

If the class needs at least all those arguments it shouldn't have an empty constructor. It should have those as arguments to the constructor and then most good ide today would be able to help you at least a bit better. Have you tried intellij? Boolean return values without context is also an antipattern, how am I supposed to know whether true means success or fail or something else? There is no way any AI would be able to infer that either without annoyingly amount of false positives.

  foo(string s, string p)
  {
    fin
  ---
    int i = s.find(p);
    if (i < 0) <#?#>;
    _

>There is no way

Really? I clearly see how to do this without any sort of AI. That's graph path weighting problem based on key words. If it gives you a false positive, just add words (or put more useful hints and >>use case snippets<< if you're library writer).

But I got your point, let's walk on the same rakes for life. There was a time when I was amazed by programming, now after two decades I'm tired of it to death (and yes, it seems that I'm "10x" from the feedback around). Programmers create and solve problems that mere mortal cannot even understand and this cool process is far from "cheap". Everyone talks about no-brain easy programming, but no real steps are done in this way. You know, when you're doing something often and for years, you just get used to it, know it all, and see no need for a change, forgetting the learning curve. You can write all of above snippets with closed eyes. The same happens to the entire profession -- you are professional and that's your value. We doomed to raise professionals again and again. In what areas? C++, SQL, etc... But wait, these are no areas! Areas are: medicine, building, etc. I don't want "cee pulse" programmer, I want a guy who understands my area.

I'm attributing these "no need for this" attitudes to the simple fact that such a system would be first step to programming without paying a programmer who solves non-existing problems. You simply put words and the system analyzes best practices and use cases from selected github projects or templates to produce a result, and you only need 0.1 of your development forces. Professional experience is bound to a programmer, but this thing would allow to change that. The same friction we seen when computers appeared. People hated them simply because their professions ceased to exist.

Lyrics off, software libraries are graphs. And graph is a thing that can be processed, if not in generic, then in specific way. There is algorithm that produces the most wanted result for known specific case.

I believe the solution lies in coming up with a way to compose pre-built components into complete applications...I think the existing efforts involving Angular,React,VueJS,Vaadin..etc are all pointing in the right direction....I have been working on Solvent (www.crudzilla.com) for sometime now and solving the UI building (drag-drop) is something that I am still actively thinking about...one of these days someone will crack the problem :)

True. That's why a proper visual programming environment should build on existing text-based environments and offer the same capabilities while adding power. Not disregard all progress, conventions, and achievements and start form scratch offering some unique features, but at the same time taking away stuff that's already been figured out.

The downside is perhaps that this very same instant gratification makes you very prone to add business logic in the UI, and it the application sticks around, you eventually want to refactor the whole thing.

one of the main issues with labview is that people simply don't take it seriously as a programming language. if people watched how i work everyday, i work just the same as, if not more efficient than, a good text-based programmer.

Yup. It's not unlike the -insert whatever language here (C++ being a good choice)-haters ranting but not actually having used it a lot, or at all.

Moreover: depending on the type of UI, I don't think there is any language out there which can get me the results I need as fast, when I need something 'process control'-like, i.e. lot of display of e.g. electrical signals and a bunch of control buttons/textboxes/comboboxes. Then there is just no match for Labview. And I have quite some experience with writing UIs in WinForms/WPF/Qt... (typical example: good luck writing a pannable, zoomable, cursor-able live multisignal 2D graph in any of those - with labview you just feed data into the premade component and you're done) It even goes so far that even though the backend is in C++ or Python, I might take the overhead of writing IPC between backend and Labview frontend over doing the UI in the backend language.

view-source:https//www.google.com/

The simpler way to say this is: "Complex ideas can only really precisely be expressed in text. To the degree you can express them visually is to the degree that there are expressed as complex text underneath."

This is a good introduction and discussion about whether this is a fad or it's here to stay: https://medium.com/softwareimprovementgroup/low-code-wave-of...

[0] http://low-code.com

Anyway, i gave a link above, with good info, including names of leading companies. Here's one:

https://www.mendix.com/

https://www.allaboutcircuits.com/worksheets/ac-motor-control... is the link I quickly found.

It's typical to see a handful of symbols handle what would take a hundred of lines of code for the level of user interface usability, validation, and core functionality.

For physical systems it is pretty true.

It's the same difference between writing mathematical proofs as systems of equations vs. proof by drawing a diagram, or making a visualization.

Proofs can be written using both methods, but if you have a strong command of the written/symbolic vocabulary, it is faster and more succinct.

Put another way: I can describe the landscape of a lush, green Tuscan Countryside--with rolling hills, morning dew, and and crisp feeling of the first rays of sun cutting through the mist--in just a few lines. You get a picture in your head, and it is likely very similar to what was in mine.

Imagine now, that we can't use words. We have to draw pictures. It will take much longer to get the same point across. Language--for certain purposes--is more efficient, and more information dense.

That's my hypothesis/feeling.

I spent a few months using LabVIEW, more than 20 years ago, and it was physically debilitating. I also have a hard time doing CAD. When I'm typing code, I'm not really focused on the screen unless I need to be. Sometimes I close my eyes and type, or look away from the screen.

Another thought about text based languages is that they make it much easier to create and explore new languages, because you don't need to program a full blown graphical editor every time, make it work on every platform, etc. Especially for languages that are supported by volunteers, maintaining graphical tools might not be the best allocation of effort.

https://forums.unrealengine.com/attachment.php?attachmentid=...

Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.

Totally agree. I think the major reason visual programming sucks is exactly because some things which are simple to do using text-based programming become way harder when all you can do is drag graphs around.

On the other hand, some things are easier and more intuitive when represented and manipulated visually using graphs or trees.

I think that a visual programming environment which would be an extension of a text-based programming environment, in that you could do everything that you can do in IDEs everybody is already used to PLUS the cool stuff you can do with visual programming, would have high chances of not sucking.

> Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.

I made a hybrid visual and text programming language and prototype development environment for it as a project for my master's thesis [0].

The main idea was very similar to what you are imagining. Textual code on the left side and visual representation on the right [1]. You can edit one and have the changes reflected dynamically in the other.

Actually my idea was even more general and could be extended to parallel-editing multiple representation of the same syntax tree.

I would love have the time to explore this stuff some more.

[0] http://djedr.github.io/masters_thesis.pdf

[1] http://djedr.github.io/gfx/masters-thesis/ide-prototype.png

Also it will help explore/understand what is required to write and effective base/methods/approaches for visual programming.

Visual programming still may make sense in some narrow niche tasks though.

Check out https://anvil.works - it's like VB, only for this century (the web) and using a sensible language (Python, both client and server).

We just took it to PyCon, and the reaction was pretty gratifying :)

At the same time there are very successful niche cases for visual programming with Excel as the most prominent. Yes, there are no data flows in Excel (although it can display dependencies with arrows), but you typically can easily identify visual blocks (chains) of calculations on a sheet. I've designed a visual programming tool for data transformation (http://easymorph.com) which can be viewed as a visual programming language[1] because typically the task of data transformation is high-level and non-linear, and visual programming works very well in this case.

[1] http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-fun...

First step is to think about IDE assisted programming as a proto visual programming. Second step is to have a real DSL, not just some general purpose programming language with some extra words sprinkled that sort of look like a DSL, but you can easily escape. Visual programming tools that aims to do the job of general purpose programming language is kinda doomed from the start in my opinion.

Here's a snag - how many DSL languages do you know that have intelligent IDE support? Designing a good DSL language is kinda hard in the first place. I know of many, but they are called XML languages, deal-breaker for many. XProc can work as an underlying language for such a visual programming tool, with a good XML schema enabled IDE or editor such as OxygenXML you won't even work with XML as most see it, it's not really text anymore. Dropdown menus in a representation of a tree, that's what it becomes.

There were at least two attempts to create an actual visual programming tool on the base of XProc, most advanced was this one https://community.emc.com/docs/DOC-4382

The main challenge in this particular domain is describing what is supposed to happen to the layout when the size of the window changes, or if there are dependencies among visual elements (e.g. some element only appears when a check box is checked). When laying things out visually you can only ever design one particular instance of a layout. If all your elements are static, this works just fine. But if the layout is in any way dynamic (with window resizing being the most common case) you now have to either describe what you want to have happen when things change, or have the system guess. And there are a lot of options: scaling, cropping, letterboxing, overflowing, "smart" reflow... The possibilities are endless, so describing all of that complexity in general requires a full programming language. This is one the reasons that even CSS can be very frustrating, and people often resort to Javascript to get their UI to do the Right Thing.

I want an hide-overflow behavior to this component, then I just wrap it with a hide-overflow component. Doing that drag-and-drop should work. Then again you would need to design such components in a way that makes them intuitive to use, but that's always the case.

Text might be good for programming because, most of the programming are sequential, text is sequential, and text processing is highly optimized in the brain because language. But in fact, we also use a bit of visual programming (indentation, paragraphs) in text to reflect part of the program structure that are not sequential.

If the program is completely non-sequential, visual tools which reflects the structure of the program are going to be much better than text. For example, if you are designing a electronic circuit, you draw a circuit diagram. Describing a electronic circuit purely in text is not going to be very helpful.

- Visual programming tools usually only work at one abstraction level (your first point)

- Often centered around a gimmick and cannot encode "normal" detail-oriented imperative code efficiently

- Only a fraction of a given program is amenable to flow charts, Visual Basic-style forms, etc. Unfortunately, most visual programming environments are all-encompassing.

- So VPs tend to become blunt, awkward tools that lack power of expression, ergonomic editors, scalability to real usecases, etc.

FWIW, I do believe that a better code editor is possible through non-plaintext programming. (Serialize token trees and ASTs, instead of plaintext.) But such an editor would likely be used in text-editor-mode >50% of the time, just due to the high information content and sheer readability of text.

Funnily enough, this is itself another of those mirages, like visual programming, that have been chased for years and failed to gain traction (outside specialised applications).

For my money, the reason for this is that a human editing code needs to write something invalid - on your way from Valid Program A to Valid Program B, you will temporarily write Invalid Jumble Of Bytes X. If your editor tries to prevent you writing invalid jumbles of bytes, you will be fighting it constantly.

The only languages with widely-used AST-based editing is the Lisp family (with paredit). They get away with this because:

1. Lisp 'syntax' is so low-level that it doesn't constrain your (invalid) intermediate states much. (ie you can still write a (let) or (cond) with the wrong number of arguments while you're thinking).

2. Paredit modes always have an "escape hatch" for editing text directly (eg you can usually highlight and delete an unbalanced parenthesis). You don't need it often (see #1) - but when you need it, you really need it.

Bags of characters <-> Unstructured trees of tokens <-> ASTs

(BTW paredit is super cool and I'd like to see more of its kind!)

This is a well-trodden road. It starts with "wouldn't it be awesome if we could manipulate everything as ASTs", then usability intervenes and we fall back to "well, we need to be able to selectively edit as text", which means you need to be able to convert everything to bags of characters and back. And now you've built that conversion, you might as well represent the "source of truth" as bags of characters like everyone else does.

(And heaven forbid you should want to make a checkpoint commit that doesn't parse...)

- Using Merkle trees, we can assign every node a hash-based ID. So now we can refer to other nodes by ID. This lets us store a graph whose vertices are all the tree nodes.

- With the graph, we can now reference bindings not by string literal, but by ID. This eliminates shadowing problems and missing imports.

- There is now one source of truth for the names of variables and functions. As a result, in source control, a commit that renames something is a one-line change.

For example:

1) How do I view diff between old and new version?

2) How do I search for an element in my visual code?

3) How do I email example of visual code to my colleague?

4) How do I message an example of visual code?

5) How do I blog about visual code?

These language workbench tools make it easy to switch between graphical and textual representations. Also you get intelligent IDE support and typechecking for free.

The primary alternatives to MPS are Xtext and Microsoft's language workbench (formerly known as Intentional Software, Microsoft just bought them).

Much of this can probably be improved in the IDE, and it is possible that there were issues simply because we may have been abusing it (there other platforms/languages that were being used beyond their original design).

What little I've seen of LabVIEW at my current job suggests that it has a more usable interface, however having written DLLs to be used by LabVIEW, it still appears to be quite restrictive at a language design level which I expect would still limit its usefulness (I hear regular talk of the use of singletons, users appear to be required to translate a C API to LabVIEW manually, useful C language features like structs and function pointers don't appear to have any support, the ability to maintain a reference to a context pointer gives rise to groaning developers).

https://en.wikipedia.org/wiki/WebMethods_Flow

In the same way that a movie script is best represented by text, my belief is that text is superior to images for representing programming logic, and images are superior to text for representing UI elements. I think most people at least feel the same about representing UI elements, which is why visual programming tools are appealing.

This leads to the conclusion that the best tools for building UIs would represent programming logic in text, and represent UI elements using images. In my experience, this is true; tools like Unity and Flash are, in my opinion, better for UI development than HTML/CSS (text). This also leads to the conclusion that unless someone invents a better way of representing programming logic than using text - like the equivalent of inventing a calendar to display a schedule, if we had never invented a calendar before - visual-only programming is inherently limited.

Tools that keep UI in visual-land and programming logic in text-land - and don't try to mix the two - work great.

Interface Builder was great for me at first, when learning iOS-specific controls and how everything worked, but as I've gotten better I've found it's always more of a hindrance. Things really start to break down when you need to move fully laid-out controls to a new container, for example, whereas Android's XML layouts let me do that by deleting/changing a few lines of text.

Perhaps this will change in the future with other input devices, touch devices like tables could provide for a different environment - currently programming with a tablet feels slugggish but this is because everything about programming revolves around typing. Touch is different. But it needs to be designed from the ground up for the interface you work with.

Whatever that is, i don't think text is the only way to go. I believe our keyboards have shaped the way we think about programming - and interacting with computers in general - and if we are to explore other ways to program, we need to also explore other ways to communicate with the computer.

As to text, a colleague once described the best feature of a text specification of code was "visual rhyme". You know, when you can look at a block of code and feel how it ebbs and flows. That's from the old days, I don't know if functional code rhymes like Fortean did.

That said, as necessary, you can do pretty much anything in that environment as code if you want. The best thing about the language, though, is that /if/ you go down the path of coding something out instead of using a common pattern, it forces you to ask "Why am I doing something out of the norm here?" Sometimes you have a valid reason. Sometimes you don't and that question course corrects you back into a maintainable architecture. It's a very niche language (even mostly vendor locked down), but I think it's a great example of a visual programming environment that's mostly great to work in.

[1] https://www.youtube.com/watch?v=f5o4tIz2Zzc

- Programming errors most of the time break everything. You probably know how bitchy Word can be. Errors will be frequent und finding them when you don't really know what happens under the hood will be very difficult.

- WYSIWYG does not abstract very well. The big power of programming however is, that you can build your own tools from a minimal set of building blocks. Visual representation for self-build tools and routines will not be pretty out of the box.

---

Those visual languages that do have a big userbase do the following:

- no WYSIWYG, just "nodes". The visual parts of the nodes:

- - inputs and outputs are often connected with "wires"

- - simple control UI like a knob or a button can be shown directly

- they allow wrapping a bunch of wired mess in to a box with simple in- and outputs again

- some allow to jump back in to code where necessary

- in general nice for small art-projects

- difficult or at least in-flexible for complex stuff

- often a lot more copy+pasting

---

This is very similar to Xcode Cocoa/CoreData bindings, but these are too restricted to create anything nontrivial. IME I always had to fallback to delegate and data source methods in source code.

It doesn't? Shameless plug, I build a visual programming tool for UI design (https://www.ux-app.com/static/learn-actions-and-events.html).

It's great for a huge subset of people for whom coding is tangential to their job. Product managers, designers etc.

It's not ideal for a programmer because it's not as dense as the textual representation and once you've developed that muscle memory, typing your code is a lot quicker, but increasingly, there are a lot more people coding now who are not career programmers. For these people visual programming is great since it's less intimidating and reduces the possibility of syntax errors.

All of our programming is visual.

We rely on a set of visual units of some manageable size (an alphabet of characters), and then we compose them sequentially into strings (visual units of a more general alphabet)

Stringing units together makes sense based on the way we experience a limited bandwidth of signal over time.

While listening, signal is presented one unit of the sequence at a time. When reading, we are presented with a whole page of characters at a time. The surrounding area is displayed, and we can move the focus around at will.

This leads to the development of the visualization models/techniques that we progress from simple features like spaces between words; parentheses/curly braces to group words; indentation of blocks to group/subordinate them, forming trees.

The idea of the unit/object/thing, composed of unit/object/things is thematic.

Files are units of text that are read/written one at a time. Eventually you stop directly typing, and you enter a different level of abstraction, where the units are displayed and manipulated with a different set of controls.

I think this is the point where the flowchart (directed graph) model fits in with the text focused model.

In Sublime, I like having the directory outline view and the zoomed-out scrollbar view with whatever single page of text I'm viewing. I think it'd be cool if these three were integrated, so that I open and close the files in a flowchart in the plane, where edges/arrows represent organization and dependencies. I'd like to import a module by dragging an arrow from one node to another

I never desired visual programming until recently. I never had the need for it. Plus, I always found the existing visual languages and tools to be clunky.

But, lately, I often find myself with just my tablet and stylist. And, during these times, I want to 'sketch' out programs. I have some ideas on how this would work in practice. There would have to be detection of gestures, and instant feedback that provides visualization of the changes.

Building a good visual programming environment I'd imagine would require either having a way to visualize and move around in higher dimensions, or dumbing down and limiting what can be done to fit neatly in two dimensions.

I like Reaktor Blocks a lot, by native instruments. They took the second tactic, and the result is beautiful (but limited). For what you use it for, it works great.

It seems to me (and I have by no means done an extensive survey of the field, so YMMV) that efforts in visual programming suffers from mis-diagnosing that the difficult part of programming is the act of writing the code (indeed, the empty editor is intimidating and code in any language looks impenetrable to outsiders), rather than understanding what code to write in the first place.

1. It's hard to make a scheme in editor without spaghettifying it. (Partially mitigated by blocks incapsulating parts of scheme in themself, some discipline is required)

2. Usually VP makes it hard to work with complex data structures. The only solution is to basically write the same code as text losing all VP in the process.

http://hiasm.com/ : Very usable constructor for small programs, the only problem with it is that website is in russian.

If you are a good enough programmer you want the power of ex regular expressions and you can solve almost any problem out there.

If you aren't you aren't much better off as you still need to learn how to program.

As a scripting language however it can be great because you can be much more opinionated about what should be prioritized.

What would be much more interesting and useful IMO was if normal languages created a visual environment akin to the visual programming languages we see sometimes.

Visual programming to me becomes very scattered and fragmented. Bits and pieces of logic seem to end up all over the place and become hard to keep a cohesive functionality together.

You still have to type to name things.

Density of stuff on the screen is lower.

Not sure about readability (you can find readability advantages for any format if you ask the right person). I would bet math expressions with many terms are clearer in a visual format like tex.

Visual elides the connection between functions and files/modules, potentially making it hard to scale projects.

Then one day someone published an article explaining that we need words to represent variables, doing it visually runs out of abstractions too quickly to do anything useful.

There were no journal publications after.

It's been about 14 years since I last looked at these publications and my memory is foggy. The point is that any useful program is too complicated to represent with pictures.

But I'd be interested in reading the study you refer, do you know how to find it?