8 ms·

I was a bit baffled the first time I was introduced to Simulink Coder. I get the value proposition: simulate your model so that you have confidence it's doing t

I was a bit baffled the first time I was introduced to Simulink Coder. I get the value proposition: simulate your model so that you have confidence it's doing the right thing, and then essentially just run that model as code instead of implementing it yourself and possibly introducing mistakes. What I didn't understand, as a software guy, not an engineering guy, was why on earth you'd want a graphical programming language to do that. Surely it would be easier to just write your model in a traditional text-based language. Hell, the same company even makes their own language (MATLAB) that would be perfect for the task. I did a little digging, and it turns out I had it backwards. It's not that Simulink invented a new graphical programming language to do this stuff. Control systems engineers have been studying and documenting systems using Simulink-style block diagrams since at least the 1960s. Simulink just took something that used to be a paper and chalkboard modeling tool and made it executable on a computer.

jocaal 2y ago
The people using matlab are typically experts in things other than programming. Matlab is for people designing antennas or control systems, where the math is more important than the code.
- VyseofArcadia 2y ago
  Most definitely, but my point was to my programmer-brain, nearly any text-based modeling language would be better than some sort of awkward graphical diagram. And since the same company makes MATLAB, why not? It turns out non-programmers actually like graphical tools. Go figure.
  - molteanu 2y ago
    I've linked this thread from HN in the article about visual programming, if you find it useful or insightful, https://news.ycombinator.com/item?id=14484244 https://news.ycombinator.com/item?id=14484244
  - jocaal 2y ago
    > It turns out non-programmers actually like graphical tools. Go figure. I'd rather say that visual tools are better abstractions than what text based tools can provide for those specific scenarios. Some problems are easier solved with diagrams.
    - agumonkey 2y ago
      text is bad with cross reference and impact.. every time your problem grows too many of them you end up charting a diagram
  - buescher 2y ago
    Programmers just don't like switching between representations - it's the same reason that "printf debugging" will still be widespread after all of us are gone.
    - archgoon 2y ago
      Printf debugging will exist for as long as access to logs is easier than direct access to memory.
      - buescher 2y ago
        Sure, that's just one use case. And logs can be useful for history as well as current state. But I think it's the mode shift to "do I set a breakpoint here, and then inspect the program state" as opposed to just continuing to sling code to print the state out.
        chowells 2y ago
        What's funny is that I learned to debug with breakpoints, stepping, and inspectors. I use printf debugging now because the more experience you get, the easier and faster it becomes. There's a point where it's just a faster tool to validate your mental model than watching values churn in memory.
      - dfox 2y ago
        Another thing is the ability to actually have a breakpoint in the program. There is a lot of distributed systems (especially embedded ones) where just stoping the program and inspecting the state will cause the rest of the system to enter some kind of failure state.
      - mst 2y ago
        I use printf debugging locally as well. Interactive debuggers and I just don't get on, and my test cases are built to start fast enough that it works out for me. Usually I have a 'debug_stderr' function of some sort that serialises + writes its argument and then returns it so I can stick it in the middle of expressions. (I do make sure that anybody learning from me understands that debuggers are not evil, they're just not my thing, and that shouldn't stop everybody else at least trying to learn to use them)
  - FredPret 2y ago
    I once wrote a linear programming optimal solver for a business problem. But because it was all equations and logical reasoning, it was hard to understand, and boring to non-enthusiasts. So my manager had me make a visual simulation instead, which we could then present to his managers. This isn't as stupid as it sounds - we humans have huge visual processing networks. It makes sense to tap into that when interfacing with other humans. I think to learn programming or math, you actually end up learning to use this visual wiring to think about written symbols. But this process of rewiring - while valuable - is very hard and slow, and only a tiny fraction of humans have gone through it.
    - crdrost 2y ago
      Related to the visual simulations, one of Alan Kay's favorite demos over the years has been to show folks Sketchpad, https://www.youtube.com/watch?v=495nCzxM9PI https://www.youtube.com/watch?v=495nCzxM9PI partly as a "this is what we were doing in 1962, you are now as far removed from that demo as that demo was removed from the year 1900 -- do you really feel like you've made the analogous/concomitant progress in programming?" ... and one of his points there was that a lot of programming acts as a "pop music" where you are trying to replicate the latest new sounds and marginally iterate on those, rather than study the classics and the greats and the legacy of awesome things that had been done in the past.
      - llm_trw 2y ago
        I'm not sure what you're trying to say here. That specialist interfaces make you productive? Sketchpad was just a cad tool, one of the first ones to be sure, but still a design tool. We have substantially better ones today: https://www.youtube.com/watch?v=CIa4LpqI2EI https://www.youtube.com/watch?v=CIa4LpqI2EI So in 62 years have we improved the state of the art in design by as much as between 1900 to 1962? Yes. I'd say we have and more.
        zogrodea 2y ago
        I'm just putting this Alan Kay question (from Stack Overflow) here because of relevance. In that question, he's considered not with implementation or how good the execution of an idea is (which is certainly one type of progress), but in genuinely new ideas. I don't think I personally am qualified to say yes or no. There are new data structures since then for example, but those tend to be improvements over existing ideas rather than "fundamental new ideas" which I understand him (perhaps wrongly) to be asking for. https://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980 https://stackoverflow.com/questions/432922/significant-new-i...
  - rtpg 2y ago
    One thing that I think diagrams are better at than common text-base PLs is that with diagrams (when the blocks are placed nicely) you can _very quickly_ tell what is going into something (both directly and indirectly). Of course you can abstract away a bit with functions or intermediate values in programming, but at one point if you do that too much you now have a bunch of indirection that harms overall readability. All a balance of course, but "what takes part in this calculation" often feels more valuable than "what is the calculation itself".
- molteanu 2y ago
  Well, software developers in the embedded field of automotive use Matlab and Simulink quite extensively. I haven't worked with it myself but the "excuse" for using it was that "we have complicated state machines that would be difficult to write directly in C".
  - pantsforbirds 2y ago
    Matlab also solves a ton of common engineering problems with efficient BLAS wrappers. And it is (or at least used to be) pretty trivial to drop in a CUDA kernel for hotter code paths. It's still great for simulation work imo.
  - buescher 2y ago
    You would think about a lot of the things that they do, "how hard can it be?". Take a look at the simplified example statechart here (scroll down) for a power window control and ponder all the ways an embedded programmer could struggle to get the behavior right in plain procedural C code as well as how difficult it would be to get a typical team to document their design intent. https://www.mathworks.com/help/simulink/ug/power-window-example-case-study.html https://www.mathworks.com/help/simulink/ug/power-window-exam... Where statechart design is appropriate, it is a very powerful tool.
    - mst 2y ago
      Those do strike me as elucidating the power in suitable contexts very nicely. For those following along at home, click https://uk.mathworks.com/help/simulink/ug/powerwindow_02.png https://uk.mathworks.com/help/simulink/ug/powerwindow_02.png first and then realise that's a top level chart with per-case sub charts (and then follow buescher's link if you want to see those) ... and that at the very least this is probably the Correct approach to developing and documenting a design for something like that. Thank you kindly for the Informative Example.
      - buescher 2y ago
        You're welcome, and yeah, that is the statechart. It's actually at the low zoomed-in level. That's the controller at the heart of the example. A lot of the diagrams in the article are higher-level, not sub-charts. I am not a 100% advocate for the BDUF-flavored model-driven-design approach in the whole document at that link, though I can understand why some industries would take it. Remember, too, this is undoubtedly a simplified example. Just off the cuff I'd expect a real-world window motor controller in 2024 to have at least open-loop ramp-up and ramp-down in speed, if not closed-loop speed control. I also would expect there'd be more to their safety requirements.
buescher 2y ago
Bingo. Additionally, control theory block diagrams are pretty rigorous, with algebraic rules for manipulating them you'll find in a controls textbook. You can pretty much enter a block diagram from Apollo documentation into Simulink and "run" it, in much the same way you could run a spice simulation on a schematic from that era.
- tonyarkles 2y ago
  Yeah, there's a really interesting phenomenon that I've observed that goes with that. If what you're describing was the main way people used it, I'd be very satisfied with that and have actually been chewing on ways to potentially bring those kinds of concepts into the more "mainstream" programming world (I'm not going to go way off on that tangent right now) What I've seen many times though in my career that awkwardly spans EE and CS is that people forget that you can still... write equations instead of doing everything in Simulink. As an example I was looking at a simplified model of an aircraft a couple months ago. One of the things it needed to compute was the density of air at a given altitude. This is a somewhat complicated equation that is a function of altitude, temperature (which can be modelled as a function of altitude), and some other stuff. These are, despite being a bit complicated, straightforward equations. The person who had made this model didn't write the equations, though, they instead made a Simulink sub-model for it with a bunch of addition, multiplication, and division blocks in a ratsnest. I think the Simulink approach should be used when it brings clarity to the problem, and should be abandoned when it obscures the problem. In this case it took a ton of mental energy to reassemble all of the blocks back into a simple closed-form equation and then further re-arranging to verify that it matched the textbook equation.
  - buescher 2y ago
    I had an intern do something similar with an electromechanical machine. I'd all but written the equations out for him but he found drawing it out in Simulink in the most fundamental, primitive blocks to help him understand what was going on . I don't get it either. A related phenomenon seems to be people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them.
dugmartin 2y ago
I used to work on GE's programmable logic controller product on the realtime OS side. PLCs are primarily programmed in ladder logic (https://en.wikipedia.org/wiki/Ladder_logic https://en.wikipedia.org/wiki/Ladder_logic) and we had a full graphical UI to do that. IIRC (its been nearly 30 years) we also had a parser that parsed text based ladder logic diagrams to drive the OS tests.
- buescher 2y ago
  Ladder logic is sort of a similar case right? Supposedly it derives from notation for documenting relay racks in factory automation that could very well date to the 1800s. And it's a pretty brilliant implementation - you don't need a degreed engineer or C programmer to set up fairly sophisticated concurrent system with it.
  - dugmartin 2y ago
    Yes it is very similar and as you say the notation lets you define really complex concurrent logic.
  - dfox 2y ago
    The idea behind that is neat. And well, the conversion from the ladder diagram to PLC bytecode is intentionally so trivial that it can be done by hand if the ladder diagram is drawn in certain way (which is the way the first PLCs were programmed). Then there is the reality: every single one of Simatic projects I have seen was done by “PLC programmers” and had this peculiar feature of using the abstractions the wrong way around. Straightforward logic written as Instruction Lists (ie. assembly that produces the bytecode) and things that were straightforward sequential programming built from ridiculously complex schematic diagrams.
    - buescher 2y ago
      Heh. It figures. Sometimes when I see things like that I wonder if it's featherbedding and gatekeeping. If it looks too straightforward, people might not think what you do is very hard. See the schematic discussion elsewhere in this thread for another example
taeric 2y ago
This gets to a fairly stark difference in how people model things. It is very common to model things in ways that are close to what is physically being described. Is why circuit simulators often let you show where and how the circuits are connected. Knowing what all can run at the same time is now very clear and knowing what can and cannot be reduced to each other is the same. If they are separate things in the model, then they remain separate. Contrast this with symbolic code. Especially with the advent of optimizing compilers, you get very little to no reliable intuition on the order things operate. Or, even, how they operate. Now, this is even crazier when you consider how people used to model things mathematically. It really drives home why people used to be far more interested in polynomials and such. Those were the bread and butter of mathematical modelling for a long time. Nowadays, we have moved far more strongly into a different form of metaphor for our modeling.
rightbyte 2y ago
Simulink is a really nice way to do some control problems in. Like, the 'flow' is really clear. Adding a feedback, saturation or integral or whatever is clear to the eye. Stateflow charts are also a really nice way to do statemachines, which are used alot in automotive. Simulink is terrible in many ways too, but in some perverted way I like it for the specific usecase.
- phkahler 2y ago
  >> Simulink is a really nice way to do some control problems in. Agreed. But it needs to stop there. BTW I never understood why the tool needs to know what processor the code is for. I asked them to provide a C99 target so they don't need to define their own data types in generated code. Does that exist yet? Or do they still define their own UINT_16 types depending on the target?
  - rightbyte 2y ago
    Dunno and I haven't worked with Simulink since 2019. There is this "type replacement" setting such that you can make Coder spit out "uint16_t" instead, but if I remember correctly, there was bugs such that you still needed to have the manual translation header. Like, some module of Simulink didn't follow the setting. God I don't miss working with Mathworks products. > Agreed. But it needs to stop there. Heh. Ye ... about that.
GabeIsko 2y ago
This is kind of the mixed feeling I have about this blog post. There is a recognition that we need universal tools that are designed with honest intentions to be effective in general problem domains. But determining the boundaries of those domains is ultimately a political exercise and not a technical one. It becomes presumptive to assume that Lisp is the be all, end all of car networking woes. Even if you accept that a tool to manage and organize computational tasks using a more functional paradigm would be helpful, that doesn't mean that a somewhat archaic, syntactically maligned language is the answer. ROS tackles this somewhat yeah? But it's still very much a research project, despite its use in some parts of industry. The most significant development for computation in vehicles in recent times is still the automotive Linux efforts, so we are not really even in the ballpark to discuss specific languages.
bmitc 2y ago
Thanks for the anecdotal perspective. That's interesting! As someone who cut their teeth on a graphical language and is a big diagramming person, it's always been curious to me as to why people want to write out stuff in text. It often feels extremely primitive. I've done large codebases in a graphical language before, and it felt so easy to orient myself as to where I was at in the system. In text-based languages, I feel lost in a sea of text that has almost zero differentiating factors.
- kamaal 2y ago
  There are lots of reason for why text is preferable though. I did some work on an drag-and-drop sort of a programming language for a ETL pipeline a while back. The absence of unit test cases makes it very hard to deploy changes without being sure you are not introducing breaking changes. There are other things as well. People tend to make big flow in one canvas. Which makes it very hard to understand. There are few more things, like wherever a GUI component relevant to a case was missing, the tool provided a way to add a javascript snippet, eventually on some canvases all you see is JS components talking to each other. At that point you are better off writing plain JS code.
duped 2y ago
> Control systems engineers have been studying and documenting systems using Simulink-style block diagrams since at least the 1960s. It dates to at least the 1940s with signal flow graphs (1) but from what I've heard, Shannon was working on fire control systems for the Navy and his work was classified. Some of that was famously published in A Mathematical Theory of Communication (2) where there are block diagrams for information systems, and Mason worked out Mason's Gain Rule/Formula in the early 1950s. I would not be surprised if graphical representations date back to the 1920s/30s when abstracting electrical systems into things like circuit diagrams that ignore grounding were pretty common, or even earlier. (1) https://en.wikipedia.org/wiki/Signal-flow_graph https://en.wikipedia.org/wiki/Signal-flow_graph

jocaal 2y ago

The people using matlab are typically experts in things other than programming. Matlab is for people designing antennas or control systems, where the math is more important than the code.

VyseofArcadia 2y ago
Most definitely, but my point was to my programmer-brain, nearly any text-based modeling language would be better than some sort of awkward graphical diagram. And since the same company makes MATLAB, why not? It turns out non-programmers actually like graphical tools. Go figure.
- molteanu 2y ago
  I've linked this thread from HN in the article about visual programming, if you find it useful or insightful, https://news.ycombinator.com/item?id=14484244 https://news.ycombinator.com/item?id=14484244
- jocaal 2y ago
  > It turns out non-programmers actually like graphical tools. Go figure. I'd rather say that visual tools are better abstractions than what text based tools can provide for those specific scenarios. Some problems are easier solved with diagrams.
  - agumonkey 2y ago
    text is bad with cross reference and impact.. every time your problem grows too many of them you end up charting a diagram
- buescher 2y ago
  Programmers just don't like switching between representations - it's the same reason that "printf debugging" will still be widespread after all of us are gone.
  - archgoon 2y ago
    Printf debugging will exist for as long as access to logs is easier than direct access to memory.
    - buescher 2y ago
      Sure, that's just one use case. And logs can be useful for history as well as current state. But I think it's the mode shift to "do I set a breakpoint here, and then inspect the program state" as opposed to just continuing to sling code to print the state out.
      - chowells 2y ago
        What's funny is that I learned to debug with breakpoints, stepping, and inspectors. I use printf debugging now because the more experience you get, the easier and faster it becomes. There's a point where it's just a faster tool to validate your mental model than watching values churn in memory.
    - dfox 2y ago
      Another thing is the ability to actually have a breakpoint in the program. There is a lot of distributed systems (especially embedded ones) where just stoping the program and inspecting the state will cause the rest of the system to enter some kind of failure state.
    - mst 2y ago
      I use printf debugging locally as well. Interactive debuggers and I just don't get on, and my test cases are built to start fast enough that it works out for me. Usually I have a 'debug_stderr' function of some sort that serialises + writes its argument and then returns it so I can stick it in the middle of expressions. (I do make sure that anybody learning from me understands that debuggers are not evil, they're just not my thing, and that shouldn't stop everybody else at least trying to learn to use them)
- FredPret 2y ago
  I once wrote a linear programming optimal solver for a business problem. But because it was all equations and logical reasoning, it was hard to understand, and boring to non-enthusiasts. So my manager had me make a visual simulation instead, which we could then present to his managers. This isn't as stupid as it sounds - we humans have huge visual processing networks. It makes sense to tap into that when interfacing with other humans. I think to learn programming or math, you actually end up learning to use this visual wiring to think about written symbols. But this process of rewiring - while valuable - is very hard and slow, and only a tiny fraction of humans have gone through it.
  - crdrost 2y ago
    Related to the visual simulations, one of Alan Kay's favorite demos over the years has been to show folks Sketchpad, https://www.youtube.com/watch?v=495nCzxM9PI https://www.youtube.com/watch?v=495nCzxM9PI partly as a "this is what we were doing in 1962, you are now as far removed from that demo as that demo was removed from the year 1900 -- do you really feel like you've made the analogous/concomitant progress in programming?" ... and one of his points there was that a lot of programming acts as a "pop music" where you are trying to replicate the latest new sounds and marginally iterate on those, rather than study the classics and the greats and the legacy of awesome things that had been done in the past.
    - llm_trw 2y ago
      I'm not sure what you're trying to say here. That specialist interfaces make you productive? Sketchpad was just a cad tool, one of the first ones to be sure, but still a design tool. We have substantially better ones today: https://www.youtube.com/watch?v=CIa4LpqI2EI https://www.youtube.com/watch?v=CIa4LpqI2EI So in 62 years have we improved the state of the art in design by as much as between 1900 to 1962? Yes. I'd say we have and more.
      - zogrodea 2y ago
        I'm just putting this Alan Kay question (from Stack Overflow) here because of relevance. In that question, he's considered not with implementation or how good the execution of an idea is (which is certainly one type of progress), but in genuinely new ideas. I don't think I personally am qualified to say yes or no. There are new data structures since then for example, but those tend to be improvements over existing ideas rather than "fundamental new ideas" which I understand him (perhaps wrongly) to be asking for. https://stackoverflow.com/questions/432922/significant-new-inventions-in-computing-since-1980 https://stackoverflow.com/questions/432922/significant-new-i...
- rtpg 2y ago
  One thing that I think diagrams are better at than common text-base PLs is that with diagrams (when the blocks are placed nicely) you can _very quickly_ tell what is going into something (both directly and indirectly). Of course you can abstract away a bit with functions or intermediate values in programming, but at one point if you do that too much you now have a bunch of indirection that harms overall readability. All a balance of course, but "what takes part in this calculation" often feels more valuable than "what is the calculation itself".
molteanu 2y ago
Well, software developers in the embedded field of automotive use Matlab and Simulink quite extensively. I haven't worked with it myself but the "excuse" for using it was that "we have complicated state machines that would be difficult to write directly in C".
- pantsforbirds 2y ago
  Matlab also solves a ton of common engineering problems with efficient BLAS wrappers. And it is (or at least used to be) pretty trivial to drop in a CUDA kernel for hotter code paths. It's still great for simulation work imo.
- buescher 2y ago
  You would think about a lot of the things that they do, "how hard can it be?". Take a look at the simplified example statechart here (scroll down) for a power window control and ponder all the ways an embedded programmer could struggle to get the behavior right in plain procedural C code as well as how difficult it would be to get a typical team to document their design intent. https://www.mathworks.com/help/simulink/ug/power-window-example-case-study.html https://www.mathworks.com/help/simulink/ug/power-window-exam... Where statechart design is appropriate, it is a very powerful tool.
  - mst 2y ago
    Those do strike me as elucidating the power in suitable contexts very nicely. For those following along at home, click https://uk.mathworks.com/help/simulink/ug/powerwindow_02.png https://uk.mathworks.com/help/simulink/ug/powerwindow_02.png first and then realise that's a top level chart with per-case sub charts (and then follow buescher's link if you want to see those) ... and that at the very least this is probably the Correct approach to developing and documenting a design for something like that. Thank you kindly for the Informative Example.
    - buescher 2y ago
      You're welcome, and yeah, that is the statechart. It's actually at the low zoomed-in level. That's the controller at the heart of the example. A lot of the diagrams in the article are higher-level, not sub-charts. I am not a 100% advocate for the BDUF-flavored model-driven-design approach in the whole document at that link, though I can understand why some industries would take it. Remember, too, this is undoubtedly a simplified example. Just off the cuff I'd expect a real-world window motor controller in 2024 to have at least open-loop ramp-up and ramp-down in speed, if not closed-loop speed control. I also would expect there'd be more to their safety requirements.

buescher 2y ago

Bingo. Additionally, control theory block diagrams are pretty rigorous, with algebraic rules for manipulating them you'll find in a controls textbook. You can pretty much enter a block diagram from Apollo documentation into Simulink and "run" it, in much the same way you could run a spice simulation on a schematic from that era.

tonyarkles 2y ago
Yeah, there's a really interesting phenomenon that I've observed that goes with that. If what you're describing was the main way people used it, I'd be very satisfied with that and have actually been chewing on ways to potentially bring those kinds of concepts into the more "mainstream" programming world (I'm not going to go way off on that tangent right now) What I've seen many times though in my career that awkwardly spans EE and CS is that people forget that you can still... write equations instead of doing everything in Simulink. As an example I was looking at a simplified model of an aircraft a couple months ago. One of the things it needed to compute was the density of air at a given altitude. This is a somewhat complicated equation that is a function of altitude, temperature (which can be modelled as a function of altitude), and some other stuff. These are, despite being a bit complicated, straightforward equations. The person who had made this model didn't write the equations, though, they instead made a Simulink sub-model for it with a bunch of addition, multiplication, and division blocks in a ratsnest. I think the Simulink approach should be used when it brings clarity to the problem, and should be abandoned when it obscures the problem. In this case it took a ton of mental energy to reassemble all of the blocks back into a simple closed-form equation and then further re-arranging to verify that it matched the textbook equation.
- buescher 2y ago
  I had an intern do something similar with an electromechanical machine. I'd all but written the equations out for him but he found drawing it out in Simulink in the most fundamental, primitive blocks to help him understand what was going on . I don't get it either. A related phenomenon seems to be people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them.

dugmartin 2y ago

I used to work on GE's programmable logic controller product on the realtime OS side. PLCs are primarily programmed in ladder logic (https://en.wikipedia.org/wiki/Ladder_logic https://en.wikipedia.org/wiki/Ladder_logic) and we had a full graphical UI to do that. IIRC (its been nearly 30 years) we also had a parser that parsed text based ladder logic diagrams to drive the OS tests.

buescher 2y ago
Ladder logic is sort of a similar case right? Supposedly it derives from notation for documenting relay racks in factory automation that could very well date to the 1800s. And it's a pretty brilliant implementation - you don't need a degreed engineer or C programmer to set up fairly sophisticated concurrent system with it.
- dugmartin 2y ago
  Yes it is very similar and as you say the notation lets you define really complex concurrent logic.
- dfox 2y ago
  The idea behind that is neat. And well, the conversion from the ladder diagram to PLC bytecode is intentionally so trivial that it can be done by hand if the ladder diagram is drawn in certain way (which is the way the first PLCs were programmed). Then there is the reality: every single one of Simatic projects I have seen was done by “PLC programmers” and had this peculiar feature of using the abstractions the wrong way around. Straightforward logic written as Instruction Lists (ie. assembly that produces the bytecode) and things that were straightforward sequential programming built from ridiculously complex schematic diagrams.
  - buescher 2y ago
    Heh. It figures. Sometimes when I see things like that I wonder if it's featherbedding and gatekeeping. If it looks too straightforward, people might not think what you do is very hard. See the schematic discussion elsewhere in this thread for another example

taeric 2y ago

This gets to a fairly stark difference in how people model things. It is very common to model things in ways that are close to what is physically being described. Is why circuit simulators often let you show where and how the circuits are connected. Knowing what all can run at the same time is now very clear and knowing what can and cannot be reduced to each other is the same. If they are separate things in the model, then they remain separate. Contrast this with symbolic code. Especially with the advent of optimizing compilers, you get very little to no reliable intuition on the order things operate. Or, even, how they operate. Now, this is even crazier when you consider how people used to model things mathematically. It really drives home why people used to be far more interested in polynomials and such. Those were the bread and butter of mathematical modelling for a long time. Nowadays, we have moved far more strongly into a different form of metaphor for our modeling.

rightbyte 2y ago

Simulink is a really nice way to do some control problems in. Like, the 'flow' is really clear. Adding a feedback, saturation or integral or whatever is clear to the eye. Stateflow charts are also a really nice way to do statemachines, which are used alot in automotive. Simulink is terrible in many ways too, but in some perverted way I like it for the specific usecase.

phkahler 2y ago
>> Simulink is a really nice way to do some control problems in. Agreed. But it needs to stop there. BTW I never understood why the tool needs to know what processor the code is for. I asked them to provide a C99 target so they don't need to define their own data types in generated code. Does that exist yet? Or do they still define their own UINT_16 types depending on the target?
- rightbyte 2y ago
  Dunno and I haven't worked with Simulink since 2019. There is this "type replacement" setting such that you can make Coder spit out "uint16_t" instead, but if I remember correctly, there was bugs such that you still needed to have the manual translation header. Like, some module of Simulink didn't follow the setting. God I don't miss working with Mathworks products. > Agreed. But it needs to stop there. Heh. Ye ... about that.

GabeIsko 2y ago

This is kind of the mixed feeling I have about this blog post. There is a recognition that we need universal tools that are designed with honest intentions to be effective in general problem domains. But determining the boundaries of those domains is ultimately a political exercise and not a technical one. It becomes presumptive to assume that Lisp is the be all, end all of car networking woes. Even if you accept that a tool to manage and organize computational tasks using a more functional paradigm would be helpful, that doesn't mean that a somewhat archaic, syntactically maligned language is the answer. ROS tackles this somewhat yeah? But it's still very much a research project, despite its use in some parts of industry. The most significant development for computation in vehicles in recent times is still the automotive Linux efforts, so we are not really even in the ballpark to discuss specific languages.

bmitc 2y ago

Thanks for the anecdotal perspective. That's interesting! As someone who cut their teeth on a graphical language and is a big diagramming person, it's always been curious to me as to why people want to write out stuff in text. It often feels extremely primitive. I've done large codebases in a graphical language before, and it felt so easy to orient myself as to where I was at in the system. In text-based languages, I feel lost in a sea of text that has almost zero differentiating factors.

kamaal 2y ago
There are lots of reason for why text is preferable though. I did some work on an drag-and-drop sort of a programming language for a ETL pipeline a while back. The absence of unit test cases makes it very hard to deploy changes without being sure you are not introducing breaking changes. There are other things as well. People tend to make big flow in one canvas. Which makes it very hard to understand. There are few more things, like wherever a GUI component relevant to a case was missing, the tool provided a way to add a javascript snippet, eventually on some canvases all you see is JS components talking to each other. At that point you are better off writing plain JS code.

duped 2y ago

> Control systems engineers have been studying and documenting systems using Simulink-style block diagrams since at least the 1960s. It dates to at least the 1940s with signal flow graphs (1) but from what I've heard, Shannon was working on fire control systems for the Navy and his work was classified. Some of that was famously published in A Mathematical Theory of Communication (2) where there are block diagrams for information systems, and Mason worked out Mason's Gain Rule/Formula in the early 1950s. I would not be surprised if graphical representations date back to the 1920s/30s when abstracting electrical systems into things like circuit diagrams that ignore grounding were pretty common, or even earlier. (1) https://en.wikipedia.org/wiki/Signal-flow_graph https://en.wikipedia.org/wiki/Signal-flow_graph