3 ms·
OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system contai
by TickleSteve 10y ago
OK, I'm biased as I've got over 20 years in embedded/real-time systems primarily written in C (and C++) and am currently architect for an embedded system containing ~million lines of code and rolling out to tens of millions of units....
(But I'm educated enough to also use Python, Clojure, C# and a variety of other systems).
...and C is currently the best choice for systems like this because of reasons not primarily to do with the language.
Currently, if you suggest to use a language other than C you will be laughed out because the only available embedded guys are C based. Yes, momentum counts and C has massive momentum.
There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge.
Basically, C is 'good enough'. (although Rust is interesting and on the horizon, its a long way off yet).
Although technically a better language, C's shortcomings are greatly exaggerated, for example memory management. In general this is not an issue in bare metal embedded systems as you don't have a heap, everything is statically allocated by design.
There are many flaws in the C language (as in every language), but in day-to-day use, they are very easy to manage.
So... don't believe the (bad) hype.
- nickpsecurity 10y ago"There are also issues such as toolchains and tooling, familiarity, community, and of course the massive existing set of libraries, codebases and knowledge." Social and economic factors that we C opponents say are why it remains and is often the pragmatic choice. These in no way show C language itself was well-designed, superior, etc. Just show how going mainstream can make things more practical. They did a great job on that part.
- TickleSteve 10y agoCompletely agree. TBH, my ideal language for this job would probably be Rust, but that is just not a mature enough ecosystem currently. Don't get me wrong, I would consider myself a C proponent currently, but I would love to see change in a Rust-like direction. Despite you classing yourself as a C-opponent, I suspect we agree more than disagree.
- nickpsecurity 10y agoProbably. I think you're a pragmatist rather than a true believer. ;) Btw, what do you think of a reboot of Modula-2, Modula-3, or just Ada/SPARK? Your opinion on them would be interesting given your background. Closest thing to Modula's that's actively developed is Astrobe Oberon for embedded. https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 http://www.astrobe.com/Oberon.htm http://www.astrobe.com/Oberon.htm
- TickleSteve 10y ago(Certainly a pragmatist) I started off with Turbo Pascal before graduating to Turbo C, so I do have a fondness for the Pascal family of languages. I also love type-safety.... TBH, I would prefer a hypothetical "fix" for the C language that improved type strictness/safety over "fixes" for resource/memory management issues which I consider should be bread and butter for any software engineer. So in that, I do not like large runtimes or garbage collection, more visibility to what the machine is really doing is needed. GC systems are also not predictable enough, deterministic runtime is absolutely essential to making reliable software. I have poked my nose around Modula-2 in the past, but C took over for me personally. ADA I consider to be far to heavyweight for anything serious (and thats after being in a company that used it extensively in the defence world, tho I never had to touch it myself) Currently Rust is my best hope for the future.... but C has survived well IMO.
- nickpsecurity 10y agoInteresting response. Thanks.
- pjmlp 10y agoAlso a pragmatist, as although I tend to bash on C on every occasion and would rather not use it, if a customer does require it, I will use it. For me a kind of escape path from C, back when I was into Turbo Pascal, was to move to Turbo C++. I only got to use Turbo C around one year before getting to learn about this new cool language called C++. It allowed me to keep some of the Turbo Pascal safety around. What are your approaches when using plain C, coming from "so I do have a fondness for the Pascal family of languages. I also love type-safety" ? My solutions were: - Use translation units as TP units, only exposing functions and struct accessors (macros if function calls were too expensive) - Always make use of debug functions to validate pointers in debug builds (e.g. _malloc_dbg, _CrtIsValidPointer on Windows) - make use of const as much as possible - write my own wrappers around strncpy and friends - compile warnings as errors - if given the option, just use C++ instead and prefer library types to inherited C ones (string, array, references, RAII).
- pcwalton 10y agoI agree with you that C is a lot better if you don't have a heap. But dangling pointers, undefined behavior, etc. are still issues. We know how to fix these problems in 2016 with better language design, via techniques we didn't know in 1978. I'll be the first to admit that compatibility with an ecosystem, even if flawed, is important. (I work on web browsers, after all!) We can't change overnight, or even in two or three years. But we'll never get to a better future if we don't take the steps to start now.