Hacker News new | past | comments | ask | show | jobs | submit login

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:


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.

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.

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

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact