Simulink isn't really a visual programming language? It's a block-diagram simulator for simulation and analysis. You link together simulation blocks, and Simulink runs a ODE solver to "solve" for the time-varying output.

Simulink can generate C code for productionization, but to write custom algorithms, you typically need to write S-functions, which are typically in C, C++ or Fortran.

Visual environments let you set up topologies quickly and reliably. It's not really programming as such though -- kinda more like scaffolding. Any kind of complex logic is still more efficiently achieved in code because many abstract ideas cannot be efficiently expressed graphically. Visual abstractions are more useful for ideas that can be concretized (typically data-flows type ideas).

Source: used and taught Simulink for many years for control systems engineering.

I think it really depends on how you define a programming language. Simulink can generate a variety of codes from models, the most common being C as you mentioned, but Simulink models can also be compiled into an executable using the Real-Time Workshop toolbox. This packages the simulation engine into the model. You're right about needing code scaffolding like S-functions to compile into C but those physical model simulations are often used directly in the control system program.

While not efficient, thanks to Turing completeness and it's analog relatives, anything you can implement in code you could implement in Simulink flow. It took me about an hour to gin up Pong for example. I think that if it is fair to consider Scratch a visual programming language, then Simulink fits the bill.

I'm not entirely sure about that. Simulink solves an ODE (more or less) system internally. How did you write Pong in it, with interactive controls?

I'm also not sure if Simulink (without S-functions, .m or any external programming language) is Turing complete, and even if it is, Turing-completeness is a very low bar for a programming system.

Not trying to be contrarian, but from my experience, despite its many logic subsystems, Simulink isn't really meant to be a general purpose programming system so much as a simulation system for time-varying outputs. It's difficult to impossible to write most normal programs in it.

I wrote pong by encoding the ball position as a continuous complex variable and used a star chart (I-Q) with minimal persistence as the output. The paddle inputs were just variable sliders bound to a limit threshold equation. Ball motion was implemented as a normal physical system of momentum and boundaries.

Simulink models are Turing complete. You can set a discrete clock simulation (very common with the DSP toolbox) and implement Flip-Flops/Boolean logic. They are also for lack of a better term, Shannon complete, that is they have all the analog components to satisfy general function computability. They also have flow control outside of those conditions and full memory storage. If you were infinitely bored and long lived, you could write Windows in Simulink flow logic and run the modeler to make a VM.

I agree with you here. Simulink absolutely isn't meant to be a general purpose programming language. It's an extremely domain specific programming language but one that in it's specific domain offers considerable advantages over textual programming. I don't want to advocate writing software in Simulink because it's a bad idea, and I only do it myself in very limited cases because I have a hobby of analog computing and Simulink is very good for that at a certain level of abstraction.

Mostly, I just take umbrage with the Article and the author's reasoning. Simulink is a counterpoint to some of his arguments but those counterpoints were made well elsewhere in the thread so I was just providing an example.

Sorry if I am starting to drone on or come across hostile.