So, in universities, you have either students who don't see the point, because they'll do java or PHP or JS at their daily jobs, or students who get a little too excited by it, almost specialize in it, and can hardly find a job that fulfills their excitment.
Consider that every electronic device you have has multiple microcontrollers inside running C code.
I would argue that if you want to get your code in the most peoples hands, you have to know C. Just looking around the (engineering) office I'm in at the devices using C:
- My PC.
- The router(s)
- The printer(s)
- the USB hubs.
- the mobiles and tablets
- the lights (yes).
- the A/C.
- The door entry system
- the microwave
- the desk phones.
- the monitors on my desk.
- The dishwasher
- The coffee machine
- The clock
The C world is much larger than most web people realise.
(the list goes on and on...)
Web stuff is maintenance heavy, so even a small webapp requires a lot of human work to keep working in the long run. Add this to the fact that, although most companies, even small ones, need a website that is more than a static single webpage, and/or a way to manage their customer / provider databases, there are rather few companies producing electronic appliances, and unless you live in the right place, most programming jobs you'll find are in high-level stuff.
Most Metal programming (for shaders, at least) is done in C++, which it itself is written in.
Game consoles use mostly C++.
All of those do contain some C, but the ratio of it to all the js/java/python/swift etc. on top of that (because this router has web, ui, mobile app and so on) is growing.
> The C world is much larger than most web people realise.
Perhaps. But it was a lot larger 10 or 20 years go, and C was wiped out as "the language" from many domains it used to occupy.
The question was whether job opportunities for C was scarce. I would not agree that it is.
But as somebody who mostly writes C for a living and specializes in embedded programming I can assure you that there's no shortage of employment offers.
Maybe I'm wrong, though.
There's also the fact that there's comparatively little innovation and hype in the C sphere of influence. C rarely makes the headlines these days while every other week you have a fancy new JS framework.
Everywhere else, not so much.
C is not fully COBOLized yet.
This seems true in any software engineering job - but at the same time, open source or personal projects are experience too. I would be very surprised to find a junior developer CV that didn't mention any projects like that.
I could guess that these jobs are not as "sexy" as using Java, Python etc?
- C, which is, well, pure, raw C,
- C++, which tends to gravitate toward modern C++ (C++11 and later), and focuses on avoiding C constructs (except when needed, eg for legacy reasons),
- the so-called C/C++, which is C with a small subset of C++98 constructs, mainly classes, the public/private distinction, the string type, references, and not much more
For a purist (either a C purist or a C++ purist), the third category feels like losing most advantages of the original language (simplicity and orthogonality of C, relative safety and expressiveness of C++) and getting drawbacks of both (name mangling and dangling pointers, both at the same time, yay!)
For me, it would not be a red flag, but definitely a yellow one.
The confusion was widespread. It may have changed, but I wouldn't really expect that to be the case.
You're looking forward to development tools that have neither refactoring nor auto completion.
I have yet to see an embedded micro controller with an API documentation and working examples.
On the contrary, I have found C and C++ to have the best refactoring and autocompletion tools of most of the languages I have tried, since usually the compiler is involved at some point and you can make non-trivial guarantees about identifiers based on types.
Regarding development tools that's a bit orthogonal, you can code for your 8bit AVR controller with Visual Studio if you really want to. Personally I don't care much for full blown IDEs and automatic refactoring so I use Emacs with dumb completion and cscope/ctags and I'm good to go but to each their own.
If you like quick prototyping and are used to develop iteratively through heavy use of the debugger I can see how it could be incredibly frustrating though. It's a different mindset and a different approach. Still, as far as I'm concerned I wouldn't trade it for all the JS jobs in the world.
For some microcontollers and FPGA I had to work with, there is hardly any API documentation. It could take a whole week just to figure out how to blink a LED. It's frustrating. There is zero help available on the internet because nobody uses that. It comes with its own tool chain and there isn't the option to use something else, like CLion or Visual Studio.
I'm supposed to make some home automation devices, or an inertial navigation system, or god knows that. It's enough work on its own, I don't have time or energy to fight broken tools.
By comparison, android development is a wonder. Development tools that work, long form documentation of every single API and guides and examples. Just plug the USB port and the program loads and it shows debugging output and you can debug line by line and use breakpoints.
Having used better development tools, I just have higher standard. I can't tolerate embedded anymore. I hope there are some working tools for some chips of some manufacturers nowadays, but wouldn't know.
ARM does provide debugging tool that can get to very low level (you can even step through bootloader code if you want) but they generally require specific hardware support and the license is pretty expensive.
I agree that documentation is often terrible though, although obviously that's pretty vendor-dependent. For instance regarding FPGA development Xilinx tends to have pretty decent docs while Altera (or IntelFPGA as it's now called) is pretty bad at it. Same goes for SoC vendors, Ti is pretty good but I've been a lot less lucky with other vendors.
Of course there is a difference in capacity between a 8 bit MCU and a Xilinx SoC, they may not be able to cover everything the same, but that doesn't explain why neither have a working example to use an interrupt handler with a push button.
What there is depends on where you live. In London/NYC, it's either web or finance. In the silicon valley, it's all web. In Washington it's government contracting. Do what needs doing.
I think it's important to use the language that best applies to the course material. For example we looked at UNIX in the OS course and it really made sense to use C there. But when we did Algorithms and data structures we used Java for that. Using C really takes away from the point and bogs you down in language specifics in this case.
But obviously the industries/domains which require C are not the same as those which require Java/PHP/JS.
In embedded software no-one is going to use Java or PHP, like in mobile/web apps software no-one is going to use C. That being said, Objective C is a pure superset of C (which C++ isn't).
Actually they will.
https://www.ptc.com/en/products/developer-tools/perc
https://www.aicas.com/cms/en/JamaicaVM
https://developer.android.com/things/
Just a small overview, as I don't feel like posting all links from everyone active in commercial Java compilers for embedded deployments.
Embedded isn't unaffected by Wirth's law.
In any case, those systems are far from having the physical and technical constraints of the actual system on a missile, plane or satellite; simply put, a 50ms delay to know the speed of a remote object is acceptable, a 50ms delay to know the speed within said object isn't.
To this day, and to the best of my knowledge, 95% of hard realtime logic is C, C++ and Ada or a combination of them, when not custom ASICs and FPGAs for low latency and high throughput tasks.
If we're talking about other systems, I'd like to know about them.
Apparently embedded now means PICs with 8 KB, while anything else more powerful than a late 80's Cray is not embedded anymore.
https://www.techbriefs.com/component/content/article/adt/fea...
Your link specifically calls out general purpose computers, not embedded systems. Java is probably not the worst language to use in that particular application, but it's certainly very close to the bottom of the list.
I'm surprised to hear they're using Java though, I figured they would go to C or C++.
For most embedded devices, this is not true.
When you're paying for every device the code runs on... and that code wastes 80% of your cycles in abstractions and indirections then forces you to have 200% more RAM than the equivalent C code, that changes your mind.
Saving a tiny amount on a processor adds up when the multiplier is (say) 1 million units.
Otherwise anything of ARM Cortex M class does have Java compilers available.
Garmin devices use Monkey, which is their own Java like language.
Ricoh and Xerox copiers use Java on OS stack for third party integration.
Likewise Cisco conference call systems have their own Java flavour.
Blu Ray players, Gemalto intelligent electricity meters, and plenty more of other examples are available.
"Monkey C" (name apparently chosen only for the pun) didn't strike me as especially Java-like when I used it, and given the memory constraints placing such a low limit on the practical max size of Garmin watch applications, that it was OO at all seemed more a hindrance than an aid. I kept wishing it was just C, and I'm not even that good at C.
Less overhead will allow a cheaper device.
Its worth noting that the java support on Cortex-Ms (Jazelle) is deprecated. If you're using a cortex-m class device, chance are you don't want to be running java on it.
Note that I'm talking in general terms, there are always exceptions to the rule (such as for the rare sandboxed application).
There is this little feature of all commercial Java toolchains for embedded development called AOT compilation to native code.
The point being that the choice of language is strongly influenced by the domain the software is developed for.
I graduated 16 years ago and I have always got jobs which were pure C, on state-of-the-art products as well. That's still the way it is, plenty of jobs available.
Not everyone is targeting PICs with 8KB Flash memory.