Slashdot Mirror
Is IoT a Reason To Learn C? (cio.com)
itwbennett writes: Whether or not beginning programmers should learn C is a question that has been roundly debated on Slashdot and elsewhere. The general consensus seems to be that learning it will make you a better programmer -- and it looks good on your resume. But now there might be another reason to learn C: the rapid growth of the internet of things (IoT) could cause a spike in demand for C skills, according to Gartner analyst Mark Driver. "For traditional workloads there is no need to be counting the bytes like there used to be. But when it comes to IoT applications there is that need once again..."
I heard this said before about phones, but eventually technology developed enough to allow mobile devices to have a strong enough processor. People are already too used to program higher-level and I see no reason why the same environments we have in our phones can't run on our fridges or boilers or ovens, therefore I do not think that people will use C.
Avantgarde Hebrew science fiction
If you're applying at a shop that does a lot of low level coding or coding on processor, memory and/or storage restricted platforms, if you're only experience is in Java or C#, I'd say your chances are pretty low. Walk in with a good practical grounding in C coding, I would imagine your chances go up. Not every shop is occupied by hipsters looking for keywords like "Python".
The world's burning. Moped Jesus spotted on I50. Details at 11.
Swift is a language well-suited to byte counting, if that is a need - at this point because of the tremendous pressure to increase security on iOT devices I really think Swift could have massive uptake.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
C was invented as portable assembly IIRC. If you cant sort out a buffer overflow then dont call yourself a programmer.
Real programmers see their job as making the computers job easy, not the other way around.
Career network security programmer here.
Absolutely of you're programming a device that connects to the internet, you should understand a bit about security and have a security mindset. If your device won't get regular updates, this is even more true.
Where does C fit in? It's unnecessary, if you just want to learn basic security best practices.
If you want to really understand how exploits work, and some advanced protections, you need to understand how your program and your data are arranged in memory, what actually happens in the hardware to when your asynchronous timer goes off, etc. For that, C is the language to learn. Java programmers know how to use Java. C programmers know how Java works, internally. The bad guys writing exploits are (typically) C programmers, they can defeat your PHP or Python program because they know how PHP and Python work internally.
You've always used languages with automatic garbage collection, so you mostly don't have to worry about freeing memory after you use it? Great. You don't know how and when memory is freed, and what happens when a hacker exploits a "use after free" to execute code that he's put into the variable you think no longer exists.
To be clear, I'm not saying that people need to *use* C to write secure software. I'm saying that if you *learn* C, you'll learn a lot that applies to advanced security knowledge in any language. Higher level languages are most commonly written in C; if you know how things are done in C you'll understand what your high-level language is doing behind the scenes. You'll understand your Ruby software much better if you understand how the same program works in C.
I do embedded C programming. With this said, I don't think that improvements to the tools are impossible - sure, I have to prevent buffer overflows myself at the present time - but it doesn't have to be this way. The key thing about embedded programming is that hardware designers are lazy. They want to do the least amount of work possible. So instead of making their hardware easy to program, they like to make it in a way that is easiest to them. So every data sheet contains all kinds of special exceptions to the rules that you the programmer have to take into account. And instead of supporting some fancy, easy to program in language, they do the minimum amount of work to make a C compiler work. (it's really minimal - you only need to map a few base instructions to opcodes on the hardware and you can bootstrap the C compiler).
One major issue is while every microcontroller or DSP generally has roughly the same stuff - various ports that do the same thing, the MAC instruction, usually a von Neuman architecture, usually interrupts and DMA - you basically have to scrape the datasheet for weeks to do something you've done before on a different microcontroller.
I work at a company that makes chips for IoT, though in this case the chips are targeted at things like routers, switches, network security appliances and highly intelligent network cards. While C++ is supported, all of the stuff I work on is C. Our SDK is C. All of the vendor SDKs I've come across for dealing with different devices are written in C. Interfacing to C is fairly simple and well understood compared to introducing C++ in an embedded environment. Now the environment I deal with is either the Linux kernel or lower, usually lower since I work with bare metal most of the time.
C is used for a number of reasons.
1. The generated code is quite fast and fairly compact. With my experience with MIPS the output of the compiler is pretty close to hand-tuned assembly in most cases.
2. It's easy to deal with hardware registers in C. Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
3. There is no unintended overhead or hidden behavior. With C it is very much what you see is what you get. It doesn't do stuff under the covers.
4. Memory mapping data structures and things like that are very easy in C.
5. One is not dependent on things like a certain standard library. The amount of code needed for basic C support is fairly minimal. All you really need is a stack. I have plenty of code that does not have a heap.
6. Things like interrupt handlers are fairly trivial to code in C.
7. One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts.
8. There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
9. Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
10. C seems to resist bloat better than other languages, in part because it does exactly what you tell it to and nothing more.
Much of this can apply to C++ as well, though C++ requires a lot more overhead in order to properly support it due to some of the language features and C++ can hide certain things if you aren't careful.
That's not to say that things can't be written in high-level languages. There is plenty of flexibility once you get to something like a Raspberry Pi user-space program.
Arduino uses a subset of C++ but it's such a small subset that it might as well be C.
I write this as someone who has been writing embedded C code and assembly (98% C) for the last 20 years, though I have also worked on a few C++ projects as well. Most of this was device drivers, Vx Works, bootloaders (U-Boot and custom), bare metal applications and SDKs (dealing with high speed networking, 1, 2.5, 5, 10, 25 and 40Gbps) and some Linux kernel work and Arduino. I've worked with a variety of different CPU architectures (Intel, MIPS, ARM, PowerPC and more) including one that ran a functional programming language natively in hardware (the processor was physically incapable of running C code).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
The trick to using C++ in embedded is to throw away stuff like the STL that depends on memory allocation, and the ivory-tower stunt crap like iostreams. Even templates are generally bad because they cause code size to explode by compiling a new version of each method for every class that uses them.
Basically, do what mbed does and use it as "C with classes". If you declare global objects for each I/O device, the class declaration then becomes an API for the device, and the object hides all the internal state. The operational details of it can be rewritten for a similar kind of device, without changing the code that uses it. If you do things right, you might even save some bytes. C++'s inlining of method calls when there is no ambiguity also contributes to the efficiency. It is also much easier to use virtual methods than to deal with the twisty function pointer syntax in C, plus you only get one set of virtual function pointers generated per class in the vtable, and can't use the wrong function pointers by accident.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }