4 ms·

To a great detriment to the expressive power of the language. How do you do anything non-trivial without heap and function pointers?

by hoseja 7y ago

enriquto 7y ago
That's the whole idea. The code must be and look trivial.
- ngvrnd 7y ago
  I have seen some terrifyingly complicated things implemented in structured text.
gmueckl 7y ago
These rules are made for a context where you need to avoid fanciness. You want to do the bare minimum that gets the task done and gets it done with extraordinary reliability and robustness. Fancy language constructs and complex algorithms are generally not helping. Keeping the program simple helps verification using automatic tooling and manual code reviews because the risk of hidden side effects or undiscovered defective code paths is minimized.
sacado2 7y ago
You can fly rockets without heap and function pointers, and that is definitely non-trivial. More precisely, however, heap allocation is usually accepted during the initialization phase (the moment when you can still abort the process with no consequence if needed, i.e in the case of a rocket, before it takes off).
- lonelappde 7y ago
  In the realm of software, flying rockets is pretty simple. The hard parts of flying rockets is not the software.
alxlaz 7y ago
It's certainly useful for the code to be expressive. But sometimes it's more important for the code to be easy to analyze and easy to verify than for it to be expressive and/or concise. I know that the mantra goes that "concise code is easier to analyze" but that's not always the case. It's true that "concise" code is usually easier to "match against" an algorithm -- i.e. it's easier to read the code and figure out if it does what it has to do. But you also have to reason about whether what the runtime does behind the scenes is correct or not, and your reasoning has to exhaust every scenario. If the runtime offers no such (or very few) guarantees, "expressive" code is very hard to deal with. These guidelines aren't meant to be applied for "general-purpose" code, which may be used by a human operator in a million possible ways. It's usually very special-purpose code that does only a handful of things (and if it doesn't, that's meant to be treated more like a design problem than anything else). Consequently, it's not that hard to figure out how much memory you need from the very beginning, and not allocate any of it on the fly. Allocating memory on the heap complicates analysis a lot. It introduces potential timing issues. You have to make sure that no matter how your program runs, it'll always be able to allocate the memory it needs -- or to design it so that it runs correctly (i.e. predictably and in the right manner) even when an attempt to allocate memory fails. You have to bring in pretty complicated third-party code, or spend a lot of time and money writing your own (writing a memory allocator is trivial, but writing a good, safe one isn't exactly a walk in the park). As for function pointers... that's more or less the same story. You don't need them that often for this sort of code, and when you do, the trade-off is usually worth it. (In very rare situations it's not, but IMHO coding standards do the right thing here. Judgement calls about these things are very much subject to ego and organization politics. It's always better to err on the side of having to do extra work under some circumstances). These guidelines don't produce the most good-looking code but they do make it harder to shoot yourself in the foot. Obviously, there is an argument to be made about alternative solutions, such as code that you cannot physically point at your foot, but that's a discussion for another time (and also way more complicated than that...)
taneq 7y ago
"Expressive power" is a two-edged sword, usually coming with some significant side effects in terms of your ability to reason about your code under varying circumstances. In the embedded world it's often more important to know strict bounds on processing time and memory usage. And when you're dealing with safety critical systems, it's critical to be able to reason explicitly about every aspect of your code. In the PLC / industrial automation world there's the added consideration that your code will probably need to be maintained (or at least navigated and understood) by people with limited software skills. And given that systems tend to be "wide, not deep" (as in, hundreds or thousands of mostly-independent inputs that only interact via very simple logic), usually ladder logic or function block diagrams are the preferred way to implement these sorts of systems. Even Structured Text is considered a bit too technical by most people.

To a great detriment to the expressive power of the language. How do you do anything non-trivial without heap and function pointers?

by hoseja 7y ago

To a great detriment to the expressive power of the language. How do you do anything non-trivial without heap and function pointers?

enriquto 7y ago

That's the whole idea. The code must be and look trivial.

ngvrnd 7y ago
I have seen some terrifyingly complicated things implemented in structured text.

gmueckl 7y ago

These rules are made for a context where you need to avoid fanciness. You want to do the bare minimum that gets the task done and gets it done with extraordinary reliability and robustness. Fancy language constructs and complex algorithms are generally not helping. Keeping the program simple helps verification using automatic tooling and manual code reviews because the risk of hidden side effects or undiscovered defective code paths is minimized.

sacado2 7y ago

You can fly rockets without heap and function pointers, and that is definitely non-trivial. More precisely, however, heap allocation is usually accepted during the initialization phase (the moment when you can still abort the process with no consequence if needed, i.e in the case of a rocket, before it takes off).

lonelappde 7y ago
In the realm of software, flying rockets is pretty simple. The hard parts of flying rockets is not the software.

alxlaz 7y ago

It's certainly useful for the code to be expressive. But sometimes it's more important for the code to be easy to analyze and easy to verify than for it to be expressive and/or concise. I know that the mantra goes that "concise code is easier to analyze" but that's not always the case. It's true that "concise" code is usually easier to "match against" an algorithm -- i.e. it's easier to read the code and figure out if it does what it has to do. But you also have to reason about whether what the runtime does behind the scenes is correct or not, and your reasoning has to exhaust every scenario. If the runtime offers no such (or very few) guarantees, "expressive" code is very hard to deal with. These guidelines aren't meant to be applied for "general-purpose" code, which may be used by a human operator in a million possible ways. It's usually very special-purpose code that does only a handful of things (and if it doesn't, that's meant to be treated more like a design problem than anything else). Consequently, it's not that hard to figure out how much memory you need from the very beginning, and not allocate any of it on the fly. Allocating memory on the heap complicates analysis a lot. It introduces potential timing issues. You have to make sure that no matter how your program runs, it'll always be able to allocate the memory it needs -- or to design it so that it runs correctly (i.e. predictably and in the right manner) even when an attempt to allocate memory fails. You have to bring in pretty complicated third-party code, or spend a lot of time and money writing your own (writing a memory allocator is trivial, but writing a good, safe one isn't exactly a walk in the park). As for function pointers... that's more or less the same story. You don't need them that often for this sort of code, and when you do, the trade-off is usually worth it. (In very rare situations it's not, but IMHO coding standards do the right thing here. Judgement calls about these things are very much subject to ego and organization politics. It's always better to err on the side of having to do extra work under some circumstances). These guidelines don't produce the most good-looking code but they do make it harder to shoot yourself in the foot. Obviously, there is an argument to be made about alternative solutions, such as code that you cannot physically point at your foot, but that's a discussion for another time (and also way more complicated than that...)

taneq 7y ago

"Expressive power" is a two-edged sword, usually coming with some significant side effects in terms of your ability to reason about your code under varying circumstances. In the embedded world it's often more important to know strict bounds on processing time and memory usage. And when you're dealing with safety critical systems, it's critical to be able to reason explicitly about every aspect of your code. In the PLC / industrial automation world there's the added consideration that your code will probably need to be maintained (or at least navigated and understood) by people with limited software skills. And given that systems tend to be "wide, not deep" (as in, hundreds or thousands of mostly-independent inputs that only interact via very simple logic), usually ladder logic or function block diagrams are the preferred way to implement these sorts of systems. Even Structured Text is considered a bit too technical by most people.