Are Embedded Control Programmers Up to Code?

Excellent!...I can only give a GA as there isn't an EA!
Not to mention the requirement to write great chunks in assembler.
Del

Quite agree. Time was, I did a lot of work with Z80s, programming mostly in C, and dipping into assembler for time-critical functions.

A decent compiler & a bit of crafty coding can produce compact & efficient target code. It's a bonus if the compiler produces assembler that you can tweak if things really need to fly.

What survey? Can we get more information please?

http://www.rako.com/Software/Software_Humor/The_Software_Toaster_Parable.html

This neatly explains the many benefits of using a language like C++ in an embedded project.

Aw I'm a softy old cat...I do wub a happy ending.
Del

Exactly what I thought of when I read this!

What high-level languages other than C/C++ (hereinafter shortened to "C" though Mr. Stroustrup among others would object) are even practical for embedded code? Seems to me you've got C and assembly language, and anyone with any brains avoids trying to accomplish significant things in assembly. Sufficient knowledge of C provides precisely the same capability, though sometimes vendor support lacks when it comes to direct register manipulation.

In order to accomplish most things in C one must have an understanding of processor internals. In order to accomplish certain things with C one must have a deep understanding of the language. With fewer software curricula including C or other low-level (or low-level capable) languages, many programmers are being minted without a deep understanding of pointers or memory management. Sure, most of them can learn it on the job, but what's the language most likely being used to impart that knowledge? C.

But not every developer requires such knowledge. As long as the developer organization has ready access to a C guru(s) we're okay. Ready! access.

BTW, Moore's Law does NOT apply to software. Hardware capability has advanced and is advancing far more quickly than software productivity. In my experience, brevity is less important than ever, and this trend will continue. One of the "problems" the world is facing now is the difficulty embedded programmers have in using all the horsepower available - other than to mask inefficiencies in their code... I find myself continually tempted to port DOOM to the system I'm working on at the time just to give the coprocessor something to do.

If you carefully read your own post you seem to have pointed out precisely why some some cats with furry brains still accomplish 'significant' things without C on some applications.
In a small company one is often constrained to use what is available without significant investment.
Del

Very much agreed Del. - Larry