One of the reasons I enjoy embedded programming is that I feel at one with the machine. After decades of working the system professionally mostly with enterprise software, I find it a breath of fresh air to be able to work with deterministic systems that I can understand an entore system all the way from the electrons in the LAN wire to the pixel on the TFT.
Some time around the mid 90s after the introduction of multi-tiered distributed systems and the siloing of jobs (segregation of responsibility they call it) it became impossible for an individual to be able to reasonably understand an entire stack in intricate detail from the UI through the token ring, network infrastructure and into the assorted servers. My job became as much about ego massaging the right "it ain't my problem" techies into the right room to talk to each other as it was a technical role.
Luckily the entire real time embedded world below Linux is still accessible to single individuals without needing multiple experts, but I am not sure how long that will last. The recent introduction of some platform specific frameworks makes the bar higher for entry for example, and people will inevitably specialise more, despite still being based on C.
More concerning is the fragmentation of the software industry in terms of the number of languages and frameworks, and the average lifetime of them. Perl for example was the king of backend scripting and then suddenly over the period of only three or four years has been left in the dust. This flavour of the month attitude is expensive. When I see things like Node.js, Lua and Python being bandied around as embedded languages it makes me shudder, not just because they are necessarily inherently wrong on low to mid end low power real time embedded systems, but because they will probably be on their way out in a few short years for Next Big Thing.
The biggest thing that's changed in embedded programming in the past fifteen years is that even on the very lowest end MCUs, complete assembly solutions have almost completely disappeared, with most of it being done in C. Now whether that morphs into C++ lite over the next decade remains to be seen, but I could accept that as a likely event particularly as embedded project code becomes larger. What I don't see happening is any fly by night language coming along and taking over the crown of C or C++ in the real time area. If you want real time, none of these Lua, Python or Node.js languages will help you, and your coin cell battery will probably be flat before your system boots anyway.
Just my current thoughts, I'm willing to be encouraged to think otherwise.
case 1:
if (monkey==engineer)
stage = color between lines;
else
{stage = look for human spices origin;}
break;
This thread went "ape" but in evolutionary interessting way, i'd like to thank you all monkeys for your
insights and sharing of experience. I will try to incorporate the wisdom into my monkey brain while
sitting here trying to comprehend my own C code!
It's said by quantum physicists that if 1 million monkeys was to type letters at random that
at one fraction of a second the entire The Hitchhiker's Guide to the Galaxy would emerge.
Not sure about the Hitchhiker's Guide to the Galaxy but without an improbability drive the library of babel online claims that it has all the words ever devised or that will be devised ever (I guess they mean in English). But maybe you can find full books readable books.
https://libraryofbabel.info/Alas, no monkeys. But if you do search "the hitchhikers guide to the galaxy" it doesn't allow apostrophes, it would find at least the title in the book that is in Volume 21 on Shelf 3 of Wall 4 of Hexagon, page 196 of 410 around the middle.
Actually i'm impressed, did a random search for a short story:
https://americanliterature.com/author/kate-chopin/short-story/the-story-of-an-hourBut the search is limited to just 3200 characters
And it found those on page 171 in Volume 10 on Shelf 1 of Wall 2 of Hexagon: (too long to paste, it's 3256 characters for the hexagon name).
I guess they use some kind of algorithm that produces a hash that reversed contains the book? not sure since I didn't research it much.
In skimming this thread, it strikes me that the real language problem here isn't with C, or C++, or which variant thereof, or Python, or ..., it is with human communication.
As is often the case, everyone has differing understandings of the terminology being used, starting with "programming," "software development," "embedded development," and what people mean when they talk about C, C++ and variants thereof in that context. People are more likely to have a high-degree of overlap in their understanding of well established terminology.
As has been noted, a decade or two ago, the idea of relying on C for embedded development was relatively new and not well accepted, now, it is. Why was there so much skepticism? Why have things changed? In part, the early skepticism was due to some real shortcomings in libraries, and compilers, and linkers, and in time, those problems were ironed out. I think though, that even if everything worked perfectly skepticism would still have prevailed, in part because it was new an unfamiliar. People were justifiably skeptical that it might be a flash in the pan. Also ,being new and unfamiliar, people heard about or had direct experience with C projects going badly, and it was inevitable that they would, because C gives one plenty of rope with which to hang oneself.
Overtime though, the craft of embedded programming in C became well understood enough that people could start to take for granted that they were talking about substantially the same thing. Which isn't to say that there isn't considerable room for misinterpretation. For some, the assumption is making use of a particular vendors ecosystem of libraries and compilers. For others, its writing or adapting ones own libraries. But even these differences have become better and more widely understood, and people are better at clarifying.
In time, I would expect greater shared understanding about the use of C++ in embedded development.
I think though, that there is going to be increased confusion about what constitutes embedded development. For this, we can thank/blame the semiconductor process engineers and chip designers. Their steady progress over the past half-century have enabled plenty of confusion, chaos, and dysfunction at every level of software development. Embedded development is no different.
The way I see it, the envelope of fixed costs, unit costs, and power consumption have shifted. Some situations that previously required embedded development specialists who fretted about every cent of unit cost, every coulomb, every byte of code, every clock cycle, every I/Opin and every bug, are now open to a wider range of practitioners. People who, ~15 years ago, might have been Visual Basic 6 developers, integrating various Microsoft and third party components to make in-house apps, might now be buying a few modules and using the vendor provided dev environment to make an embedded device for in-house use. When bugs are discovered, they'll use a vendor provided solution to push updated software to the field.
I'm sure this sounds like a perfect nightmare to most anyone who considers themselves embedded engineers, but for someone who can't quite find anything that is quite right for their need, and who can't afford to do "proper" embedded development its going to be a godsend. It remains to be seen what this does to traditional embedded development. Will opportunities for such work shrink? Hold steady? Expand? It's hard for me to guess. I think there will always be a need for the skills and mindset. But how many will they be employed developing for deployed products, vs tools used by higher-level developers?
In this new world, I think small low powered devices programmed using Lua, Python, Javascript, and similar are going to become more numerous. As for fear of them being flashes in the pan, I don't know if it will reassure Howardlong to hear that his perspective may be a little skewed. Perl's time in the sun as king of the backend languages was quite short. Coldfusion and ASP were strong challengers by 1998, and by the dotcom crash, PHP had a strong and rapidly expanding foothold on the UNIX servers Perl CGI apps called home. It wasn't too much longer before Ruby + Rails was stealing a lot of PHPs thunder. Python was slower catching on on Web servers than Ruby + Rails, but before Ruby found a niche in web development, Python was already being used as an integration language in a variety of areas (google used it a lot internally, YouTube was built with it, and it has a strong foothold in bioinformatics). Lua, its had a great foothold in computer game scripting for over a decade. Javascript has been the lingua franca of client-side web development since before anyone even really developed client-side web apps. Its presence as a serverside language is just about as old, though it didn't get any traction on the server until someone took Chrome's fast javascript engine and made Node.js.
To wrap all of this up:
Computer languages are really human languages. Even with the economic and cultural force of the combined British and American empires over multiple centuries, there are plenty of people who rarely use English, and plenty more who never use English. Even among english speakers, there are significant differences in accent, pronunciation, spelling, dialect, vocabulary and idiom. Even among english speakers talking about the same technical subject, there is ample room for misunderstanding.
Therefore, there are apt to be a variety of computer languages, and variants of individual computer languages and their applications to given problem domains. Moreover, now that computing is almost ubiquitous, the forces of proliferation and variation are likely to grow.
There may be large areas of common adoption and practice, but there will always be fractal edges. Todays tiny fractal edge of computing/programming could conceivably include more practitioners and users than all of computing did in the days that some of you started your careers. Or looking at it another way, there have been ~10x as many Rasberry Pi's sold as there were DEC PDP-11s.
Luckily the entire real time embedded world below Linux is still accessible to single individuals without needing multiple experts, but I am not sure how long that will last. The recent introduction of some platform specific frameworks makes the bar higher for entry for example, and people will inevitably specialise more, despite still being based on C.
Which frameworks?
Microchip Harmony in my own experience, and I believe STMCube is of a similarly derided genre.
Put simply: design patterns keep you safe from being murdered by other developers 
Unfortunately only low hanging fruit relevant to large GUI/web applications are really tackled. Domain specific books of patterns and infinitely more important anti-patterns are lacking, but the people with the ability to write them unfortunately have better things to do. So all we get is anecdotes and lots of reinventions of wheels and failure modes.
The recent introduction of some platform specific frameworks makes the bar higher for entry
The New TI MSP432 Launchpad (
http://www.ti.com/tool/msp-exp432p401r ) supports multitasking in Energia. Only. Using TI-RTOS. (ie, no MSP432 support in Energia without using TI-RTOS.) I find myself relatively unwilling to invest much time in learning about TI-RTOS. Because: TI-only... Sigh.
Put simply: design patterns keep you safe from being murdered by other developers
And design patterns done wrong just adds more twisted metal to the problem, layers of shit, to perform simple things with gross levels of over engineering overhead...
Put simply: design patterns keep you safe from being murdered by other developers
And design patterns done wrong just adds more twisted metal to the problem, layers of shit, to perform simple things with gross levels of over engineering overhead...
Everything can be misapplied, and will be. Your argument is equivalent to saying for loops add more layers of shit, with the implication that goto is all that is necessary and is all that should be used.
It is notable that the GoF book correctly followed best practice by clearly indicating examples where each pattern should not be used.
Design patterns represent a higher level of abstraction than individual statements/functions/modules, and succinctly communicate aspects of an architecture or design. For example, if I am working with distributed messaging systems, it is very useful to know that a component implements the "half-sync half-async" design pattern rather than "sync RPC", because then I have a good idea of its behaviour.
Put simply: design patterns keep you safe from being murdered by other developers
And design patterns done wrong just adds more twisted metal to the problem, layers of shit, to perform simple things with gross levels of over engineering overhead...
Everything can be misapplied, and will be. Your argument is equivalent to saying for loops add more layers of shit.
Rubbish. that's what you are assuming. please don't lecture me about design patterns, I am old enough to understand what their benefits are (
when applied correctly) you really NOT teaching me or anyone here anything that we already don't know.
Put simply: design patterns keep you safe from being murdered by other developers
And design patterns done wrong just adds more twisted metal to the problem, layers of shit, to perform simple things with gross levels of over engineering overhead...
Everything can be misapplied, and will be. Your argument is equivalent to saying for loops add more layers of shit.
Rubbish. that's what you are assuming. please don't lecture me about design patterns, I am old enough to understand what their benefits are (when applied correctly) you really NOT teaching me or anyone here anything that we already don't know.
I responded to what you wrote; not being a mind-reader I couldn't divine your other thoughts. No could anybody else reading your comment.
If you had mentioned that vital caveat, then there would have been no need to ensure that
inexperienced readers weren't mislead by your partial statement of your position.
The way I see it, the envelope of fixed costs, unit costs, and power consumption have shifted. Some situations that previously required embedded development specialists who fretted about every cent of unit cost, every coulomb, every byte of code, every clock cycle, every I/Opin and every bug, are now open to a wider range of practitioners. People who, ~15 years ago, might have been Visual Basic 6 developers, integrating various Microsoft and third party components to make in-house apps, might now be buying a few modules and using the vendor provided dev environment to make an embedded device for in-house use. When bugs are discovered, they'll use a vendor provided solution to push updated software to the field.
I'm sure this sounds like a perfect nightmare to most anyone who considers themselves embedded engineers, but for someone who can't quite find anything that is quite right for their need, and who can't afford to do "proper" embedded development its going to be a godsend. It remains to be seen what this does to traditional embedded development. Will opportunities for such work shrink? Hold steady? Expand? It's hard for me to guess. I think there will always be a need for the skills and mindset. But how many will they be employed developing for deployed products, vs tools used by higher-level developers?
In this new world, I think small low powered devices programmed using Lua, Python, Javascript, and similar are going to become more numerous. As for fear of them being flashes in the pan, I don't know if it will reassure Howardlong to hear that his perspective may be a little skewed. Perl's time in the sun as king of the backend languages was quite short. Coldfusion and ASP were strong challengers by 1998, and by the dotcom crash, PHP had a strong and rapidly expanding foothold on the UNIX servers Perl CGI apps called home. It wasn't too much longer before Ruby + Rails was stealing a lot of PHPs thunder. Python was slower catching on on Web servers than Ruby + Rails, but before Ruby found a niche in web development, Python was already being used as an integration language in a variety of areas (google used it a lot internally, YouTube was built with it, and it has a strong foothold in bioinformatics). Lua, its had a great foothold in computer game scripting for over a decade. Javascript has been the lingua franca of client-side web development since before anyone even really developed client-side web apps. Its presence as a serverside language is just about as old, though it didn't get any traction on the server until someone took Chrome's fast javascript engine and made Node.js.
Some very good points.
While I can certainly see the likes of garage door openers easily being targets for higher level script languages where the overhead of abstraction is of no practical consequence and devices supporting them become commodity parts, my original comments were to do with the low to middle end real time embedded area which is where I specialise. When you need deterministic responses measured in microseconds, for example for signal processing, these high level scripting languages just aren't the right solution. While you can do a bit of orchestration with them, typically embedding a scripting language interpreter is often going to be an additional unnecessary overhead and complication. The Lua implementation on a PIC32 that I'm aware of, for example, needs at least 128KB of RAM to run something reasonable on a PIC32, an enormous amount in low to middle end microcontroller terms.
For a system which is capable and for which you've already accepted that you're going to implement a high level OS like Linux, of course these scripting languages makes an awful lot of sense, but there is inevitably a cost in this in terms of memory, processing power and energy. It's still a long way off before we'll see a CR2032 powered Linux device available that has a practical use.
I should have been clearer in defining terms I guess, "embedded" covers a multitude of sins. If I were a betting man, I'd still be betting C and C++ as the language of choice in 10 years in the real time low to middle end market (eg, PICs and Cortex-M).
why don't we focus on fixing troubles with C99 instead?
why don't we write tools like "inter modules dependencies"?
why don't we improve the C language to support try exception?
and something more comfortable, thing we can do to stop the (ab)use of "goto" ?
Which problems with C99? I've not found any.
C99 comes from the legacy of C89, so it is not exactly compatible with C89, while it is keeping old troubles, with
break,
continue,
goto, (plus goto *xxxx introduced by gcc) { all of these are banned by MISRA },
complex type might fail (and there is a specific #pragma for that), it still misses
fixed point type, still inadequate opaque type, still missing try-exception (which forces people to use goto), and problems in defining abstract interfaces (and how to define if a parameter is IN/OUT/INOUT ?), etc etc and let me say new features like the "
restrict" which was introduced with the motivation of protecting pointers is an useless bullshit, and more and more problems with concurrency, in where every C revision is still a pain in the head
so the point is:
too many bullshit around,
no real progress with the C language, while C++ is simply too bloated
Interestingly
this recent study found that "
developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared", thus suggesting that goto does not appear to be harmful in practice
Interesting
developers use goto in C files for error handling and cleaning up resources at the end of a procedure a proposition that follows from (and is often appended to) one already proved.: the C language is inadequate for that
There's absolutely nothing wrong with
break and
continue, that's just silly. Whoever came up with that MISRA rule is full of shit. I likewise don't think anything is wrong with
goto when used properly - never jump
into a block, and absolutely, positively never jump
backwards. It's
fine for simple error handling.
I wasn't aware of the problems with the complex type, though I've yet to see anybody use it. Exceptions are just not something that is done in C. If you want exceptions, use C++. Same with abstract interfaces - C isn't meant for OOP. As for defining whether a parameter is in or out - well, if it's a pointer and it isn't
const, it's probably either an outparam or the programmer doesn't understand const (in which case he needs a good thwack with the cluestick).
C is weakly typed by nature, defining in- and out-params is not something I'd expect from it. If you don't like that, don't use a weakly typed language. Ada supports those...
There's absolutely nothing wrong with break and continue, that's just silly. Whoever came up with that MISRA rule is full of shit. I likewise don't think anything is wrong with goto when used properly - never jump into a block, and absolutely, positively never jump backwards. It's fine for simple error handling.
yeah, absolutely nothing wrong with them, and people always uses goto in the properly way, while MISRA always tells you bullshits
There's If you want exceptions, use C++
oh, really?
Same with abstract interfaces - C isn't meant for OOP
oh, really?
C is weakly typed by nature, defining in- and out-params is not something I'd expect from it. If you don't like that, don't use a weakly typed language. Ada supports those...
oh, really? And can I feed the monkey? with nuts or with bananas ?
good motivations, man
(to stay in the cave-office
)
and can your monkey port ADA to MPU/8bit?
and can your monkey execute ADA on DSP?
Code Complete: A Practical Handbook of Software Construction
Second Edition 2nd Edition, Microsoft PressI guess that book is a good point, it contains a lot of "
horror-code", including examples of bad (ab)use of the C language
I had a read when I was a student, since then in my job experience I have realized that book has never told lies
I actually believe that c++ will be the language of the future, and as the arduino have shown us, with a limited enough subset of the language , even less experienced people can contribute.
That, the safety/simplicity improvements offered by C++14 and the fact we're starting ot see a lot of c++ mcu libraries(for example the new mbedOS), and the fact that it's close to impossible to create good interoperability tools for c++ from other languages, means c++ will rule.
As for the future in general - think it will be much more abstracted(and that's where most of the simplification will come from, not the language. BTW this is also true for python, i believe) .
We're already seen a lot of work done on abstracting the hardware , and we'll see more, ARM, in the mbedOS is doing good work in abstracting mcu power management behind nice interfaces, and nobody in his right mind could write a secure connected device without really abstracting it (and most devices would be connected, if just for updates when bugs appear, or a nice phone UI).
And from the hardware standpoint, we'll see more cost reduction(unless too many mergers kill it) ,more lower power ,so it'll be easy to abstract in many cases.