Hacker News Reader

Except there is a successful visual programming tool and it probably runs a large chunk of software in your car. It's called Matlab Simulink:

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.

That's actually very interesting. Never heard of that before.

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

Perhaps creating niche visual DSLs is a more viable approach to developing visual programming environments than to focus on creating a general purpose programming environment.

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

I have a background as a programmer and recently started using Matlab/simulink. It is good for some things like controllers etc. Can't really say I like it for things I would usually use when programming, like loops and if statements(I know simulink has these but they make no sense).

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.

I've worked on this and also did cross-compilers for it. It's industry standard. It's not only used in cars, it's used all over industry control automation, airplanes, power plants, ... It's reliable and creates almost bug free code. It allows real-time control loops. It creates highly optimized C code (I wrote a C++ backend). You wouldn't want to do that in C or C++ by hand. Before Simulink my prev. company used Occam, a powerful Smalltalk/Objective C like language with CSP, which ended up being succeeded by Go.

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'm developing driver assistance functions for vehicles and I have experience using simulink, although not anymore, fortunately. It's usage is converging slowly but steadily to zero in the company I work for, although we still use it for controllers, but mostly only legacy "code". Why is it?

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

My horse carriage is very useful. The horse just feeds itself, if you leave him in a grass field. It rarely gets sick and last many years. The wheels are easily replaced from the store.

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.

Except that there has been a lot of research.

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.

There are decades of research. It's not unreasonable to adjust expectations based on that.

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.

There is a huge difference between direct manipulation of concrete concepts, and graphical manipulation of abstract code. Visual programming works much better with the former than the latter.

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

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.

Some good points. But I think your view has become too negative, perhaps due to your experiences. Or at least I see more hope for visual programming. :)

> 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

Thanks for your feedback. I agree with your point that past failures, however many, does not guarantee future failure. Aviation is a good example from history.

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

As a believer myself, I think the problem is that visual programming suffers the same problem known as the curse of Artificial Intelligence:

"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