Someone seems to have complained that code is looping. In all my years of programming, since 1965, I have NEVER seen programs, including main-frame operating systems that did not LOOP.
My comment was not just about looping, it had more to do with constant polling vs using interrupt or event driven scheduling but there was even more to it than that.
It is possible to have a system that never uses a main continuous constantly running loop polling things to get everything done but instead processes what needs to be done, as it happens, and eventually does some kind of halt/sleep when there is nothing to be serviced.
But my comment was really driven by my concern that I'm starting to see lots of code and coding practices where there is not much system architecture planning up front and EVERYTHING constantly runs through a main loop, including in some cases where there are very real-time requirements vs using interrupts or using events in the case of using an OS or task scheduler.
A constant polling type of design also tends to fall apart when it comes to power management since, if you need to constantly poll, you can't put the processor to sleep to save power.
I get why it is done, it is often easier, sometimes it is because the code was not fully planned out but rather was done on the fly or slowly evolved to include more and more things in a main loop, until everything breaks because the overall system was never truly designed.
Don't get me wrong, rigid timing requirements for a system using a main loop that polls everything has it place and I've done things that way many times for certain situations but that kind of system can sometimes be difficult to extend and can have issues when trying to interface or use other s/w components that cannot guarantee latencies or that can have variable timing.
What concerns me most in the s/w industry at large is that I see it moving away from what I would call "Computer Science" and a traditional product life cycle, where up front time is allocated to plan a project and define its architecture to meet the project/product requirements to trying to emphasize moving as fast as possible to get to some kind of a deliverable.
Once the delivery schedule is the priority and is in control, important steps start to get short circuited or even skipped.
I think some of this has been driven by how quickly code can be compiled/built and how easy it is to push out updates for little to no cost.
The mindset seems to be shifting to that it is ok to push out something even it isn't quite ready or hasn't been tested very much since it can be updated in the field quickly and fairly easily at a low cost to fix issues.
i.e. is more important to show progress by pushing a release, than taking more time to push out something that is better designed and more stable.
I believe that this creates a reactionary development process rather than proactive development model.
and IMO, causes products in the field to have more issues and be of a lower overall quality.
With respect to Arduino, Arduino actually promotes some things that bother me.
The whole concept of "tinkering" and "trial and error" "programming" goes all the way back to the Arduino founders.
While I get it for certain situations and for less technical or even non technical people that have limited programming skills, that are trying to just get something/anything working; however, it does make me quiver to watch it and see it actually promoted as a development style.
I am just not a "trial and error" person.
For my projects I go by a more traditional process:
define requirements, plan, design, code, then test.