Hacker News Reader

Comment by VyseofArcadia | Hacker News Reader

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.

View on HN

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.

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.

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.

> people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them

Lol there are a few things that I am highly intolerant of and this is one of them. The only place where I'm generally ok with that approach is at the input connectors, the microcontroller, and the output connectors. Same philosophy as I said before though: "if it brings clarity draw it as a wired up schematic; if it turns into a ratsnest use net labels to jump somewhere else". Having every component in a separate box with net labels will generally obscure what's going on and just turns it into an easter egg hunt.

Also, part of the style seems to be to contort any actual schematic to fit in the box. I like to ask "if you wouldn't put it on its own page so you could draw it clearly, why did you draw a box around it?".

I don't really get this point of view. Take an I2C bus, for example. Isn't it easier to read the schematic if all the components on the bus have two pins connected to wires labeled 'SDA' and 'SCL'?

Yeah, there’s a balance here. There are common nets like SDA, SCL, GND, VCC that make sense to have as global nets. And then there’s actual circuits where it makes more sense (for understandability) to not do it like that.

Here’s an example that I think takes it too far: https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-...

- The audio jack (line level) could have just sat to the right of the codec and been directly connected to it to make it clear that it’s just a direct output

- the speaker amplifier could be directly connected to the audio jack as well. I spent a lot of time looking around to figure out where it actually connects to; I figured it would have its input connected to the MP3 codec and didn’t realize that it would be connected through the micro switches inside the headphone jack (which makes sense now that I see it)

- the SD card slot could either be connected directly to the codec or could have better names on the nets. When I see MOSI, MISO, and SCK I assume that they’re connected to the main MCU. Even more confusing, there’s an SD-CS that is connected to the MCU but not the rest of the SPI pins

Overall I’d probably give this one a B. It’s by no means the most egregious I’ve seen but it also obscures the signal flow pretty badly.

Other things I would probably consider doing:

- better clustering of pins on the MCU by function. The switch inputs and LED outputs that connect to the rotary encoder are all over the place. Most tools allow you to move the pins on microcontrollers around at will

- the FTDI block could move onto the first page. The DTR pin could use a bit of explanation that it’s tied to the reset circuit. Not their fault in this one but the naming inconsistency between FTDI-RXI and TRIG4/TXO is confusing until you figure out that the pin is meant to be either a GPIO or a UART pin. The name doesn’t make it clear that it goes to the FTDI chip because it’s inconsistent with the rest of the FTDI-xxx names but that’s because most ECAD programs handle net names poorly anyway

Edit: one more thing that really bugs me about this schematic: the Vbatt net leaving J1. It’s labelled but not with any kind of flag or loose/unterminated line that would indicate that it’s connected to the net leaving U2. And further with that, the fact that VIN on U2 comes only from the FTDI connector on the second page (I think…)

All good points. By the way, yes, if you have one peripheral device on an i2c bus, and your design is small enough that you're drawing the device on the same page as your microcontroller, you should make the connection explicit. My two cents:

- Making the power routing completely implicit is another hallmark of the style and it drives me crazy too. The power, charging, and maybe FTDI boxes should all be together on one page. Now, I might change my mind about this in six months, but I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one. The power tree style in the Arduino documentation is pretty nice

- In the same vein, even modest designs usually benefit from a block diagram up front. You don't need to use hierarchical design functions - just boxes and arrows and text done with the drawing tools of the CAD program

- I like that they actually did put most of the "bookkeeping" connections on the left side of the micro. I'd move the UART pins over to that side too, and the programming port. The programming port belongs with the micro and nowhere else, would you put it on its own page?

- Audio signals flow right to left to down for no particularly good reason except to get all the other boxes to fit on the second page. All the audio could be on its own page

- Similarly, LED signals come in to the rotary encoder on the right and encoder signals come out on the left. Really?

- I like that they grouped the bypass capacitors with the ICs but for these modest numbers of bypass caps I prefer to see them shown connected to the pin pairs they'll be placed by

- OK, not a schematic point and not critical for a hobbyist product but powering the battery charger from USB is a potential issue. Low line by spec on USB is 4V at the connector, and you won't get 4.2V out of that with a linear charge controller. They might also be exceeding maximum effective capacitance on the USB power bus. Again, not critical for a low-volume "maker" product - it will always work except when it doesn't

- No off-page connectors for off-page connections. I like to see the pages called out that an off-page connector connects to, but I admit that's a pain to do by hand

- The pull-ups and pull-downs in the top right hand corner of the second page are typical of the style. Who ever heard of connecting these directly to the pin that needs them? Again, it looks like this was done to fit the subcircuit in the box

> I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one

I'm laughing/crying right now because of a board I had to deal with last week at $JOB. Pretty beefy power distribution board with some... quirks related to load shedding etc. Details don't matter there. I ended up drawing the whole power graph (it's not a tree, there are two independent inputs that go through ideal diode controllers for some of the rails for redundancy). By carefully rearranging the nodes of the graph I managed to get it completely planar (no overlapping edges) except for one spot where a poorly-thought-out connector did require one edge overlap.

Laying that out as a planar graph dramatically simplified routing. It's a technique I hadn't explicitly used before and it sure worked out nicely.

The other technique that comes in handy in that kind of situation, if you have multiple power/voltage/current domains that require spacing or other isolation from each other, or multiple ground references, is an isolation or insulation diagram. I don't have a great example; if you search you'll find a style that will meet medical device requirements and can be adapted for other use.

I guess I would see a schematic like this in the context of an EDA tool which would make most of these issues moot. E.g. it is easy to find out what other nodes a specific node connects to. If for some reason you have to work from a paper or PDF schematic then I can see why these things would matter - but hopefully you don’t!

I’m not a very visual thinker, though. If it were up to me schematics would just be written out in some kind of textual representation, but EDA tooling tends to make fiddling around with schematic diagrams the blessed path.

100% I am working with paper schematics. I do a fair bit of field work in dirty environments (agriculture). When something isn’t working I want to be able to trace from the power input to the fuses to the regulators to the control signals to the output connectors. It’s much much easier when that all fits on a sheet of paper or two (or a screen or two) and it clearly flows from left to right.

Ok, fair enough, but you don't have to use a paper schematic for the LilyPad-MP3 thing. The Eagle sch file is here: https://github.com/sparkfun/LilyPad_MP3_Player/blob/master/h... It seems fine to me for schematics to adapt to new media. We don't worry about how easy it is to navigate our source code when it's printed on a teletype.

That's fine if you're the only person that will ever use the schematic. As the kids say, "you do you". But a schematic for a product has a life beyond your desk - it will be used by technicians, test engineers, firmware engineers, sustaining engineers, purchasing, quality, manufacturing (including fab houses and CMs), legal, compliance, the list goes on. Many of those people will not have a schematic capture tool installed on their computer and limited time to learn one - or in some cases, several. You will absolutely have to provide them PDF schematics and you should care if they are clear and follow common conventions. If you're thinking of a schematic as source code, maybe as data entry for layout, you're already making a category error. They are different in kind.

There are in fact ways that electronic media have changed schematic practice - it is extremely unlikely in 2024 that you will have a draftsman or CAD designer drawing your schematic from a sketch, though in some environments you might have a documentation team putting your work into a very strictly defined format, and it is pretty unlikely you will have a large-format plotter readily available. So the norm has shifted to multiple smaller pages, and there's little pain involved in adding another schematic page if you need one for clarity.

Note that sparkfun schematic was drawn for 8.5x11 paper even though the more natural size for full-size monitors is 11x17.

To me it seems like a process failure if people are reading paper (or PDF) schematics in 2024. EDA in general seems to be behind the times compared to software engineering in terms of tooling culture. If you saw a software engineering process that involved people reading print outs of source code you’d just say: “That’s insane! Stop doing that.” You wouldn’t bother to critique the formatting of the print outs.

> Note that sparkfun schematic was drawn for 8.5x11 paper even though the more natural size for full-size monitors is 11x17.

Again a cultural issue. The tools assume by default that you want to produce a sheet of paper.

A schematic is a drawing, not source code. Of course you're going to want to print it out and mark up the paper. You're making a severe category error. There is a visual language for communicating design intent in schematics that is not just formatting, or making things pretty (you can make a "pretty" but unclear schematic) or entering wiring connections into a computer. If you follow it, other engineers will be able to understand your work more quickly and with fewer questions for you. If you don't care, you will look like someone who doesn't care. It is the difference, say, between writing individual words or short declarative sentences as opposed to building complex sentences, paragraphs, a short report, etc.

As documentation, in a production environment, your schematic will have a life beyond your EDA package. I've done sustaining work on designs that have outlasted the design packages they were done with. Without having to open them up, because there were schematics available in standard documentation formats. Eagle - as used in that lilypad design from 2013 - already has a sunset date. It's also a reality that EDA packages have poor backwards compatibility and even worse, their "import" functions rarely work at all well on non-trivial designs. That would be a fair criticism of the industry but for the most part redrawing a schematic and checking it against a netlist is not the end of the world. If you have one.

As an aside, it wouldn't shock me if lawyers print out source code, either. They print out everything else and store it on paper.

Of course a schematic is a drawing, but there is particular need these days for it to be a non-interactive drawing laid out for printing on a sheet of paper. Equally, source code is text, but that doesn’t mean that in 2024 we have to worry about how well suited our source code is for printing on a teletype. I am not saying that no care should be taken when creating schematics, only that the conventions that made sense when schematics were static printed documents will not necessarily make sense now that a schematic is created, viewed and manipulated via an EDA tool. In a similar way, version control, interactive editors and IDE tooling have given rise to rather different coding conventions than the ones that predominated when people entered numbered lines of BASIC, or assembled machine code by hand on sheets of paper.

A move to open EDA formats is indeed long overdue. KiCad is a step in the right direction.

Sometimes, and it depends what you're trying to convey.

Take a system with multiple I2C devices - with each device on a different sheet, it becomes difficult to tell that you might have bus contention issues.

Is it? You can just count the number of devices connected to the I2C bus. That seems easier than if you had to follow a bunch of tangled lines.

> You can just count the number of devices connected to the I2C bus

If everyone working on it has the software, they can count easily and accurately.

When I started and still sometimes today "just counting the number of devices" requires visiting each sheet of the schematic, then hoping you didn't miss one.

> That seems easier than if you had to follow a bunch of tangled lines.

Today's software will let you draw a single bus connection between all bus devices.

> That seems easier than if you had to follow a bunch of tangled lines.

The problem is generally that if you choose to put some things near each other, you're choosing to put other things further away. In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. This may or may not be appropriate for the design.

>If everyone working on it has the software, they can count easily and accurately.

Any IC on the I2C bus will have pins labeled SCL and SDA, so you can easily just go through all the ICs and count how many have those pins. It might be slightly tedious with a paper schematic, but it's hardly impossible. It still strikes me as easier than doing the same thing with unlabeled pins that are connected directly in the schematic to the UC's I2C pins.

>In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show.

I don't quite understand what you're saying here. Labelling a pin with SDA or SCL makes it clear that it's connected to the I2C bus. What I'm saying is that I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines. That's completely independent of how you lay the schematic out or split it into functional blocks.

> It might be slightly tedious with a paper schematic, but it's hardly impossible.

What may only be slightly tedious for you will often be error-prone for someone else.

>I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines.

The value is that the entire bus is visible at a glance. All conflicts are visible, and contention sources understandable. Though, you can also put this information in a note/table.

>That's completely independent of how you lay the schematic out or split it into functional blocks.

What I mean is that it's often also valuable to split a schematic out along functions rather than busses. If you have an I2C ADC with a bunch of analog stuff connected to it, that might fit its own sheet better. But if your weather station I2C bus has several simple devices like Flash, ALS, humidity sensor, RTC, barometer, and thermometer, placing them together on one sheet may make sense. I just mean tidyness varies with the contents of the room.

I am not really understanding the "at a glance" part. If there are no labels then you have to follow the wires. That seems more difficult, not easier.

You can split out all the components on the I2C bus onto a separate sheet (or not) regardless of whether you label or SDA and SCL lines or connect them with wires.

If the complexity of the attached subsystem is low enough, the wires can be used as a feature not a bug, like a map.

Imagine a home network diagram with a router, switches, and computers. You could draw each on their own sheet with names for each cable, but the purpose of each cable is clear from what it connects.

I think using the drawing it out process to understand initially is ... not how my brain would do it, but seems like a perfectly valid approach.

But once you -do- understand it's time to stick that in a reference file out of the way and write it again properly for actual use.

Where can I read about your project or hear your tangent?

I'm hoping at a minimum get my thoughts written out while I'm flying this weekend!

The quick gist is that Jupyter is frustrating for me because it's so easy to end up in a situation where you inadvertently end up with a cell higher up in your document that is using a value computed in a cell further down. It's all just one global namespace.

In the Julia world with Pluto they get around this by restricting what can go into cells a little bit (e.g. you have to do some gymnastics if you're going to try to assign more than one variable in a single cell); by doing it this way they can do much better dependency analysis and determine a valid ordering of your cells. It's just fine to move a bunch of calculation code to the end/appendix of your document and use the values higher up.

The idea I've been chewing on comes somewhat from using Obsidian and their whole infinite canvas idea. It seems like using ideas from Pluto around dependency analysis and being able to also determine whether the contents of a given cell are pure or not (i.e. whether they do IO or other syscalls, or will provide outputs that are solely a function of their inputs) should be able to make it easier to do something... notebook-like that benefits from cached computations while also having arbitrary computation graphs and kind of an infinite canvas of data analysis. Thinking like a circuit simulator, it should be possible to connect a "scope" onto the lines between cells to easily make plots on the fly to visualize what's happening.

Anyway, that's the quick brain dump. It's not well-formed at all yet. And honestly I would be delighted if someone reads this and steals the idea and builds it themselves so that I can just an off-the-shelf tool that doesn't frustrate me as much as Jupyter does :)

it sounds like the ideal solution would be something functional (so you have a computation graph), pure (so you can cache results) and lazy (so order of expressions doesn't matter.) why not Haskell? or even a pure/lazy subset/variant of Julia, if you want to ditch the baggage of Haskell's type bondage?

you could ditch explicit cells entirely, and implement your "scope" by selecting a (sub)expression and spying on the inputs/outputs.

I've thought about that and have written some fun Haskell code in the past but... the other goal is to actually have users :D. I've also considered Lisp, Scheme, and friends to have really easily parseable ASTs.

I jest a bit, but there's a very rich ecosystem of really useful data analysis libraries with Python that do somewhat exist in other ecosystems (R, Julia, etc) but aren't nearly as... I would use the word polish, but a lot of the Python libraries have sharp edges as well. Well trodden might be a better word. My experience with doing heavy data analysis with Python and Julia is that both of them are often going to require some Googling to understand a weird pattern to accomplish something effectively but there's a much higher probability that you're going to find the answer quickly with Python.

I also don't really want to reinvent the universe on the first go.

It has occurred to me that it might be possible to do this in a style similar to org-mode though where it actually doesn't care what the underlying language is and you could just weave a bunch of languages together. Rust code interfacing with some hardware, C++ doing the Kalman filter, Python (via geopandas) doing geospatial computation, and R (via ggplot2) rendering the output. There's a data marshalling issue there of course, which I've also not spent too many cycles thinking about yet :)

Edit: I did copy and paste your comment into my notebook for chewing on while I'm travelling this weekend. Thanks for riffing with me!

Elixir livebook does this

Interesting! I do love Elixir! Thanks for the recommendation, I'll take a look!

This is all making me think... this could be a good use case for propagators: https://dthompson.us/posts/functional-reactive-user-interfac...

Yeah, definitely inspiration coming out of the FRP world as well here. Great link, thanks!

One cool thing about, for instance, density altitude calculations or runway length calculations, is that you can break the parts of the algorithm down graphically do pilots can trace through datapoints to get an answer without even having a calculator. See many pilot operating handbooks for examples.

Also works for power/moment data on marine freight, in fact I used to have a job at a shipyard drawing those.

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.

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.

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

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

text is bad with cross reference and impact.. every time your problem grows too many of them you end up charting a diagram

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.

Printf debugging will exist for as long as access to logs is easier than direct access to memory.

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.

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.

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.

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)

Printf debugging is actually a very primitive case of predicate reasoning. Hopefully in the not too distant future instead of using prints to check our assumptions about the code we will instead statically check them as SMT solvable assertions.

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.

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

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.

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

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.

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

this is awfully manual, does autocad have parametric topology tools ?

programs like houdini are more reactive and mathematical (no need to create width/volume by hand and trim intersections by hand), i think mech engineering tools (memory fail here) have options like this

No idea, I mostly use freecad and I've been told autocad has more tools.

In freecard there are parametric tools which are very much like what was shown in the demo but in 3d.

I tend to use script which render to openscad for the parts that I want to be parametric.

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

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

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.

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

Where statechart design is appropriate, it is a very powerful tool.

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

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.

> A lot of the diagrams in the article are higher-level, not sub-charts.

I must have failed to understand even more things than I thought I did. I'll have to read through again when more awake if I want to fix that, I suspect.

I think if faced with that class of problem (am not automative developer, just spitballing) I would probably try using some sort of (no, not YAML) config format to express the various things.

But that's a 'how my brain works' and I am aware of that - for database designs, I've both ensured there was a reasonable diagram generated when the point of truth was a .sql file, and happily accepted an ERD as the point of truth once I figured out how to get a .sql file out of it to review myself.

I haven't worked in automotive. And I'm not a strong advocate of exhaustive model-driven design like what's shown at that link. But it's worth looking at.

Generally if you have a state machine or state chart with more than a few states, it's worth implementing as a table. The "config format" is then an array in a source file. There is a standard interchange format, scxml, for statechart tooling and libraries, but if you're implementing your state machine directly from a whiteboard drawing, you might not bother with it.

What they didn't tell you is that these state-machines are differential equations as well. Again, the math is more important than the code. If you want to look more into it, just search for state variable control.

> 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

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

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.

Yes it is very similar and as you say the notation lets you define really complex concurrent logic.

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.

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

Any Ladder logic editor would have two views: the block view and the text view. I used to work on Siemens PLCs. I started using only the block view, but over time migrated to only using the text view. Now, I understand that the text view is basically a kind of Assembler. I liked it because I was able to think and visualize things in my head much better using text. But for simple flows, and people not versed in programming, the only option, really, is the block view.

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.

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com