How many people code in C these days, and if so, why?

[tszaboo]

C is great and it is worth learning. They absolutely should start all programmer courses with it. And C++ with all it's fault, extends on it. Even if you dont use a language all features, you can use the underlying ideas when you write code. For example, you can take the OO aspects, and write better C code for microcontrollers.
That being said, I'm not a programmer. I'm an EE, who uses programming as a tool to get another job done. I learned python a few years back, and it was a game changer for me. I never want to write C code ever, which would run on a PC. If any of my colleague does it, then my typical question is " whats wrong with you, you could've written that code in python, probably 2 lines". And it is.
I occasionally still write C code. Bringing up a MCU or something like that. Or honestly, spending a few days on setting up compilers, linker files, debuggers, licenses for all these, just to write a bitbanging SPI in a few minutes, or something trivial like that. Constantly repeating in myself " this would be 5 minutes on a PC with some REPL".
I am wondering when is it all going to change. I mean, I used to write ASM code for PIC16 and AVR8. And most kids are learning some bastardized C++ as Arduino. We've come a long way, but not far enough.

[bd139]

We went all the way a while ago and everyone misunderstood it (FORTH)

[nctnico]

I am wondering when is it all going to change. I mean, I used to write ASM code for PIC16 and AVR8. And most kids are learning some bastardized C++ as Arduino. We've come a long way, but not far enough.

A few years ago I wanted to give embedded Lua a try to run on a microcontroller (AFAIK there is also micro-Python nowadays). Lack of time and the Lua environment needing more work than I cared for at the moment prevented me from going further. A lot of code doesn't need to run at lightning speed but does stuff which is complicated enough. A high level language certainly helps to make implementing high level functionality easier. Recently I finished a project which involves an embedded Linux platform. The customer can change the functionality using a Lua script (which talks to a device specific API written in C).

IMHO there is certainly a future for using languages like Lua and Python on microcontrollers. C and C++ are not very effective to write complicated control algorithms; C and C++ get in the way quickly. But this will probably end up in another 'assembler versus C' like debate which lasted for over a decade.

[coppice]

IMHO there is certainly a future for using languages like Lua and Python on microcontrollers.

Python is a bit of a resource hog, but I've seen people using Lua on quite small devices.

[IDEngineer]

Answering the subject line: Probably 95% of my freshly authored code is in C99. The other 5% is Assembly on whatever platform, to hand-optimize specific sections of code.

I learned C++ when it was released, figuring it was the natural evolution of C. C++ taught me how to recognize when a language is too cumbersome: When you have to think more about how to express something in the language rather than actually doing it. That's what I always liked about C... it just feels so natural. Like a good oscilloscope, the tool disappears. It just becomes an extension of my brain, like my own fingers are probing the circuit (scope) or my own fingers are moving bits around (language). If you have to keep the scope manual handy, or the language docs open in another window, your tools are getting in your way.

I did a HUGE (and very successful) project in Java a few years back. Essentially C with a layer of OO on top. So, like C++ and just as useless. Haven't had a need to touch it since.

I recently learned Python to help teach a university course. OMFG. The bad features of many languages, with very few of their advantages. Could I get better at it? Sure... but why? Its major "advantage" is "it has so many canned libraries available". But that's true of C and many other languages. I'm glad I learned Python because now I can honestly steer students AWAY from it.

On most platforms, C is the first compiler that is offered. Other languages then (sometimes) follow, using C to build their environment. Which means that whatever platform you're considering, C is probably available. That's a darned strong recommendation for any language.

I'm open minded enough to learn new languages (hence Java, and Python). But the real world where actual work gets done and projects get shipped keeps bringing me back to C and Assembly. Maybe I'd feel differently if I worked on mainframes or something where you're widely abstracted from the hardware. But for the work I do down here in the trenches, where the line between hardware and firmware/software gets blurry in a hurry, it just keeps being C.

YMMV, not trying to start an(other) argument, just my $0.02, standard disclaimers, etc.

[SiliconWizard]

IMHO there is certainly a future for using languages like Lua and Python on microcontrollers.

Python is a bit of a resource hog, but I've seen people using Lua on quite small devices.

Lua is great, and the interpreter is quite small in size (although still not that small for very small devices, but I think there are very stripped down Lua interpreters for those.)

Thing to consider though is that, to do anything really useful with Lua, the basic object you have at your disposal is a dynamic table. Dynamic tables ARE Lua (if you wanted to sum it up very shortly.) And so they are not that great a fit for devices with a very small amount of RAM.

Now of course you can still do stuff in Lua without using tables, but from my experience, you'd be pretty limited. Just a small thought.

[bd139]

Lua. Hmm.

https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

[amyk]

I still use C becase it's simple and it works. Both embedded and desktop (Win32). "Modern C++" seems to have developed a disgusting fetish for abstraction and while the source may seem smaller, it creates a hugely bloated binary.

[spudboy488]

I develop PCB test equipment in a one man shop. I have 2 preferred CPUs (PIC16F689 and PIC18F46K22) that I use depending on the project. I initially coded in assembly on the 689 but switched to Hi-Tech C when I started using the 46K22.

For me, using C allowed, basically, the same code can be used on both CPUs. There are obviously differences but the low level stuff is handled in the libraries I wrote. This hides the CPU differences from the high level test functions. I have base software that will set up each CPU depending on various #define statements and all I have to add is the custom test routines for the project.

[Picuino]

In an electronics blog like this there will be many examples of microcontroller programmers who prefer to program in c because it is the best or the only high-level language option.
But in the world of computer programming, the c language is also the best option for many projects. Operating systems such as Linux, Windows or OSX, drivers, languages ​​interpreted as Python or PHP and even compilers of other languages ​​are all programmed in c.

According to the TIOBE index, the C language is the most widely used of all, much more than C++
https://www.tiobe.com/tiobe-index/

Although C++ is like C with improvements, it seems that the greater complexity of the language is precisely an argument against it.

One more reason to program in C is that it is very portable. You can port C libraries between different systems, but C++ libraries cannot. There is not always a C++ compiler available.

[engrguy42]

I wouldn't dismiss the benefits of an object-oriented language like C++, or especially C#. As an engineer, it is an incredibly logical and somewhat obvious approach to designing software. A bit like functional programming (eg, FORTRAN functions) on steroids.

You treat stuff as objects, with user inputs/interfaces/controls, internal processes, and outputs. Especially if you're modelling/simulating real world stuff it's extremely logical and efficient, IMO.

For example, if you're going to simulate a car, it has user interfaces (steering wheel, brakes, gas pedal), internal functions, and outputs. And if you build a model of the car engine and its controls, it's a fully functional block of code you can reuse the next time you simulate a car. Just tweak the object's parameters and you have a different engine.

Yeah, some seem to prefer functional, rather than object oriented, and they may have a point in some applications. But if you're simulating real world stuff it's wonderful, IMO.

Of course if you're not simulating real world stuff, and doing more abstract stuff, then maybe it's overkill. I've used it to simulate/model control systems, it's great. You end up with a block of code that defines the hardware, maybe even comprised of sub-objects you connect together, and tweak the parameters and you're ready to go. Wonderful. 

Personally, I couldn't care less what others use, and what's more popular. Different tools for different jobs. And it seems the higher level languages (C++, C#, etc.) are better for more abstract uses, and the lower levels (C, ASM, etc.) for more direct hardware-based stuff.

[SiliconWizard]

Note that you can write (as some of us have already pointed out) code in an object-oriented manner in C. Whether it's more clunky than using C++ is all a question of perspective. As long as you know how to do it, and don't want to implement fancy OO features (which are often highly debatable anyway), doing that in C is not really that much clunky. I'm used to it. I've done that both in C and C++, and quite frankly, if done right, it doesn't even take more lines of code in C, or not significantly so. I'll admit that if you do that, you'll get less "verification" from the compiler, so in that respect, you need to be extra careful.

The same goes for functional programming -  you can pretty much program in a pure functional way in C. But to be frank, contrary to OO, where it doesn't really add any overhead compared to C++ (again if done right, and again as along as you don't try super fancy paradigms), pure functional programming in C WILL add overhead (sometimes considerable) compared to true functional programming languages that natively optimize a lot of internal data structures and data passing.

You can of  course also use a mix of approaches.

[radioactive]

For me,  it is C99 unless I have to write a user interface that will run on Windows.  In that case,  Java.

If you need some embedded scripting capabilities, why not use 'C' for that too?.  https://github.com/jpoirier/picoc

[tom66]

Most of the software I write is C or Python. 

If it's embedded, it's 99% C (and about 1% assembler, processor dependent.)

I've been wondering if I should move to C++ for a certain recent project, but I'm half way in and that's a long curve to get up to speed in a new-ish language.

[engrguy42]

Note that you can write (as some of us have already pointed out) code in an object-oriented manner in C. Whether it's more clunky than using C++ is all a question of perspective. As long as you know how to do it, and don't want to implement fancy OO features (which are often highly debatable anyway), doing that in C is not really that much clunky. I'm used to it. I've done that both in C and C++, and quite frankly, if done right, it doesn't even take more lines of code in C, or not significantly so. I'll admit that if you do that, you'll get less "verification" from the compiler, so in that respect, you need to be extra careful.

The same goes for functional programming -  you can pretty much program in a pure functional way in C. But to be frank, contrary to OO, where it doesn't really add any overhead compared to C++ (again if done right, and again as along as you don't try super fancy paradigms), pure functional programming in C WILL add overhead (sometimes considerable) compared to true functional programming languages that natively optimize a lot of internal data structures and data passing.

You can of  course also use a mix of approaches.

Absolutely true. You CAN do just about anything with any software, just like you can probably build a house using only a screwdriver 

IMO, what's important is that folks are familiar with each of the tools enough to know what's best for each task, and not restricted by a vague bias based on minimal experience.

[ace1903]

C is easier to learn by doing. Many of my colleagues started as electrical engineers with no background in computer science.
When they were newbies, we used to give them small tasks to do in project that was 100k+ sloc. All of them completed successfully in a week by looking at the rest of the code and a couple of books.
After 3 months they were capable of doing tasks of any order of complexity. Of course, there was support from system architect and obligatory and regular code reviews.

The same approach doesn't work for projects in C++. To be good software developer in C++ need some background in computer science.
Learning by studying books and doing exercises instead of regular tasks. Code review in C takes an hour or two (incremental patch). Good C++ review is more hours and is much more difficult.

Newbies tend to finish tasks fast in C++ but at the expense of resource leaks and random crashes.
When I say C++ I think all the features of C++, not C way of programming in C++
The ratio of good C  developers vs good C developers is something like 1 to 50.
C++ makes a better product but it will be expensive.

[engrguy42]

C is easier to learn by doing. Many of my colleagues started as electrical engineers with no background in computer science.
When they were newbies, we used to give them small tasks to do in project that was 100k+ sloc. All of them completed successfully in a week by looking at the rest of the code and a couple of books.
After 3 months they were capable of doing tasks of any order of complexity. Of course, there was support from system architect and obligatory and regular code reviews.

The same approach doesn't work for projects in C++. To be good software developer in C++ need some background in computer science.
Learning by studying books and doing exercises instead of regular tasks. Code review in C takes an hour or two (incremental patch). Good C++ review is more hours and is much more difficult.

Newbies tend to finish tasks fast in C++ but at the expense of resource leaks and random crashes.
When I say C++ I think all the features of C++, not C way of programming in C++
The ratio of good C  developers vs good C developers is something like 1 to 50.
C++ makes a better product but it will be expensive.

Again, isn't the important question "What problem do I need to solve?", rather than what's "easier"?

I'm surprised nobody has mentioned C#. I think if you want to very quickly and efficiently develop GUI's on Windows that's probably at the top of the list.

And if you're doing math-intensive stuff you probably want a language that happens to have some excellent math libraries available so you don't waste time coding them from scratch.

And if you're doing graphics-type stuff (ray tracing, etc.) you want a language that fits more closely with what graphics hardware manufacturers' API's develop and support.

And if you're coding at a lower hardware level you want an language that is light and efficient for that.

And on and on and on...

As with most things in the universe, it depends. There's no right answer for everyone. Just be sure to evaluate the problem and look for the best tool that's available. Unfortunately a lot of people take the approach "Oh, I like this, therefore everyone has to like it and think it's the best". 

[Wolfgang]

I've worked in the software industry for 30years+.
I've worked in C/C++/COBOL/Pascal/FORTRAN/Assemblers/LUA/Python/PL1/Java/...
I've written several languages myself for specialized purposes.

My view on (sometimes religious) language debates:
- With a clean mind you can solve a problem in (almost) all languages, sometimes more elegant, sometimes harder.
- Even the best language cannot keep idiots from coding garbage.
- Every good code has this ratio: 10% solution of the problem, 90% defense against idiots.

Now (retired) I use:
- Plain C for hard numerics (math, speed) and on microcontrollers (Arduino)
- Python on the desktop. Reason: Elegant, efficient, lot of useful libraries.

[ace1903]

In an ideal world, there will be 50+ C++ developers equally good in math for signal processing and a little bit of hardware (to know to use logic analyzer scope...).
But in real-world if you try to find them, either half of them would hate math or will be from some distant country with cultural differences.
There was an interesting story from Dropbox I think. They know that C++ is best for them, the product has already a stable code base and benefits from C++.
But the available workforce forces them to migrate whole product towards some javascript framework..
They have great ideas for new features and improvements but sadly C++ developers don't want to learn their proprietary code base and find it uninteresting and not challenging enough. 
Couple of days ago I asked project developed in Matlab\python to be ported in C++ for the production environment. Got hundreds of views because description contained neural networks and machine learning.
Sadly only one C++ developer applied for the job.
 

[Wolfgang]

IMHO, C++ has been expanded to death. The language has become completely unwieldy due to featuritis,
is hard to read and its so easy to shoot yourself in the foot.
If you use all features to the fullest (multi inheritance, ...) its so easy to write code even the inventor will
not understand anymore after two weeks. C++ tries to do too much, has too many side effects, is hard to debug,
not very suited for realtime or small hardware stuff due to memory issues, not extremely fast either, so ...
If your problem just calls for a reasonable object-oriented language and performance is not critical -
Python. You do the same in a fraction of the code. If its close to hardware or raw speed - pure C.

[profdc9]

I use C++ somewhat for embedded programming but sparingly.  Mostly I have used C.  I have tried C++ from nearly the beginning in the early 90s.

At first, the compilers were flaky and produced code that didn't work.  This was eventually fixed.

But the C++ added every "kitchen sink" feature that every other language had.  Writing a compiler for C++ must be horrendous.

The problem with C++ for embedded programming, as I see it, is that it is difficult to audit what code is produced (in size and complexity) when using some of C++ more advanced features.  Templates will bloat code enormously.  Virtual functions and methods are ok and are probably my favorite feature of the language, but you must be careful casting pointers to make sure that the correct vtables are referenced.  However, other languages do polymorphism better (e.g. Objective C).  Exception handling is a hot mess.  It introduces so many potential code paths that it is very difficult to know how your code will unwind.  gotos are better in my opinion because at least you know where the code is jumping to and where its jumping from.  Overloaded functions and operators may look nice but also add the possibility of calling the wrong function, especially if the overloaded function has nearly identical functionality (for example, a reference counted version of a regular function).  Add to that weird rules for constructors, destructors, when they are called, etc., and you got something deeply confusing and waiting for human error.

C may be the manual transmission of coding languages, but it's going to get you there, and you're going to know how much the engine revs when it does.

[SiliconWizard]

Note that you can write (as some of us have already pointed out) code in an object-oriented manner in C. Whether it's more clunky than using C++ is all a question of perspective. As long as you know how to do it, and don't want to implement fancy OO features (which are often highly debatable anyway), doing that in C is not really that much clunky. I'm used to it. I've done that both in C and C++, and quite frankly, if done right, it doesn't even take more lines of code in C, or not significantly so. I'll admit that if you do that, you'll get less "verification" from the compiler, so in that respect, you need to be extra careful.

The same goes for functional programming -  you can pretty much program in a pure functional way in C. But to be frank, contrary to OO, where it doesn't really add any overhead compared to C++ (again if done right, and again as along as you don't try super fancy paradigms), pure functional programming in C WILL add overhead (sometimes considerable) compared to true functional programming languages that natively optimize a lot of internal data structures and data passing.

You can of  course also use a mix of approaches.

Absolutely true. You CAN do just about anything with any software, just like you can probably build a house using only a screwdriver 

IMO, what's important is that folks are familiar with each of the tools enough to know what's best for each task, and not restricted by a vague bias based on minimal experience.

I think we managed to all be reasonable in this thread, and avoid flame (and language) wars. Let's try and keep it that way.

Your comment was of course overly caricatural. My point was mainly to express 1/ what *I* do and why (which was the OP's question) and 2/ just correct the frequent misconception (especially for people exclusively using "higher-level" languages) that C code necessarily has to be a poorly structured mess of functions, global variables and loose data structures, and that you necessarily have to use some higher-level language to write "cleaner" code.

And of course, if you read my post,  your comment is a bit off: I just pointed out cases where using a reasonable OO paradigm in C would NOT necessarily be much more clunky than in C++ or other. Surely "clunky" is a somewhat subjective appreciation, so not everyone can agree on what it exactly means for them.

You won't do that without a generous amount of experience anyway, so your second sentence holds, but I vaguely feel like it was meant to defeat my point. It doesn't. If anything, using C++ because you're convinced it's way better than C for OO programming in general could fall into the category of "vague bias based on minimal experience."

Corollary of all this is, sure "the right tool for the job" - a common and general quote, but not always as clear cut as it looks. Whatever is right for a given task depends on a number of factors including the engineer's experience. Someone's right tool maye be someone else's worst nightmare - for the exact same project.

[IDEngineer]

Overloaded functions and operators may look nice but also add the possibility of calling the wrong function

Overloading is my most hated aspect of C++ (or any language that employs it). Honestly, it feels like it is intentionally designed to cause errors. Sure I get the theoretical convenience of it, but ultimately code has to be 1) written, 2) debugged, 3) tested, and 4) work in real life. Overloading "feels" like it helps with #1 but it makes #2 and #3 much less deterministic which risks the reliability of #4. That's a Faustian Bargain.

The danger of overloading was proven to me most forcefully when I was debugging a function that was one of an overloaded family. As I stepped through the code, nothing made sense. Variables weren't changing the way they should, the debugger would skip lines of code when I single stepped, etc. I finally dropped into the disassembly listing and, looking at the program counter, realized the debugger was displaying the wrong source code... it matched the name (of course) but was the wrong overloaded function! It's bad enough that overloading can fool a human, but when the native debugger can be tricked - nope, no thank you. Once again you're working too hard to accommodate your choice of tool. Tools (whether T&M equipment or software) are supposed to make the job easier, not get in the way.

[nctnico]

Note that you can write (as some of us have already pointed out) code in an object-oriented manner in C. Whether it's more clunky than using C++ is all a question of perspective. As long as you know how to do it, and don't want to implement fancy OO features (which are often highly debatable anyway), doing that in C is not really that much clunky. I'm used to it. I've done that both in C and C++, and quite frankly, if done right, it doesn't even take more lines of code in C, or not significantly so. I'll admit that if you do that, you'll get less "verification" from the compiler, so in that respect, you need to be extra careful.

The same goes for functional programming -  you can pretty much program in a pure functional way in C. But to be frank, contrary to OO, where it doesn't really add any overhead compared to C++ (again if done right, and again as along as you don't try super fancy paradigms), pure functional programming in C WILL add overhead (sometimes considerable) compared to true functional programming languages that natively optimize a lot of internal data structures and data passing.

You can of  course also use a mix of approaches.

Absolutely true. You CAN do just about anything with any software, just like you can probably build a house using only a screwdriver 

IMO, what's important is that folks are familiar with each of the tools enough to know what's best for each task, and not restricted by a vague bias based on minimal experience.

I think we managed to all be reasonable in this thread, and avoid flame (and language) wars. Let's try and keep it that way.

Your comment was of course overly caricatural. My point was mainly to express 1/ what *I* do and why (which was the OP's question) and 2/ just correct the frequent misconception (especially for people exclusively using "higher-level" languages) that C code necessarily has to be a poorly structured mess of functions, global variables and loose data structures, and that you necessarily have to use some higher-level language to write "cleaner" code.

And of course, if you read my post,  your comment is a bit off: I just pointed out cases where using a reasonable OO paradigm in C would NOT necessarily be much more clunky than in C++ or other. Surely "clunky" is a somewhat subjective appreciation, so not everyone can agree on what it exactly means for them.

You won't do that without a generous amount of experience anyway, so your second sentence holds, but I vaguely feel like it was meant to defeat my point. It doesn't. If anything, using C++ because you're convinced it's way better than C for OO programming in general could fall into the category of "vague bias based on minimal experience."

Corollary of all this is, sure "the right tool for the job" - a common and general quote, but not always as clear cut as it looks. Whatever is right for a given task depends on a number of factors including the engineer's experience. Someone's right tool maye be someone else's worst nightmare - for the exact same project.

Well, there is also something like the 'right person for the job' who can handle the right tool for the job. Personally I'm not a fan of doing OO in plain C. C++ makes life a lot easier by hiding all the nasty stuff which results in much easier to read code. The Linux kernel is a particular poor example of doing OO in C. It is a huge convoluted mess.

[Wolfgang]

Its generally not smart to mingle OO and real time. Reason: OO resource management is somehow unpredictable and might add uncalculatable runtime when you cant afford it.
No usable OS kernel I know is written in an OO language. Not even Windows