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