Structured programming is not an absolute truth; it's only a valuable thing in a given context (let's call one of those contexts the "mainstream programming philosophy from the 80s to the 90s"). Change the context and it may not be interesting anymore: e.g. if you decide to (really) focus on the core of a problem instead of building a "software product", you can eliminate a lot of waste (or overhead): heavy structure and abstractions, complicated configuration, etc. and keep only what really matters: computations.
You can read the story of how, by redefining the rules of the game, Chuck Moore wrote his own EDA tools in 500 lines of his own, ultra-minimalist programming language (colorForth). Yes, it's extreme, but it works: he designed many working chips using it.
http://www.colorforth.com/vlsi.html
If Chuck Moore wrote his own ultra-minimalist language, then the language had some form of structure. Using structure when you program => Structured Programming?
Structured programming is not an absolute truth; it's only a valuable thing in a given context (let's call one of those contexts the "mainstream programming philosophy from the 80s to the 90s"). Change the context and it may not be interesting anymore: e.g. if you decide to (really) focus on the core of a problem instead of building a "software product", you can eliminate a lot of waste (or overhead): heavy structure and abstractions, complicated configuration, etc. and keep only what really matters: computations.
You can read the story of how, by redefining the rules of the game, Chuck Moore wrote his own EDA tools in 500 lines of his own, ultra-minimalist programming language (colorForth). Yes, it's extreme, but it works: he designed many working chips using it. http://www.colorforth.com/vlsi.html