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

[Wolfgang]

... but if a hammer is the only tool you have then every problem starts looking like a nail .. )

[paulca]

... but if a hammer is the only tool you have then every problem starts looking like a nail .. )

Yup.  When it really starts to suck though is when they start seeing every nail as a problem as well.

[madires]

Therefore you should have a toolbox with different tools. Then you can choose the right tool for each job. Or if you have people with only one tool in their toolboxes, then you have to choose the person with the right tool.

[jfiresto]

... The terms high-level and low-level are inherently relative. Some decades ago, the C language, and similar languages, were most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level....

https://en.wikipedia.org/wiki/High-level_programming_language

That must be a more recent, retrospective narrative. I can not think of anyone who considered C to be high-level in the 1980s. Even Kernighan and Ritchie described C as a relatively low level language because of its (favorable) nearness to the hardware. I think everyone learned C from their book – it was so well written.

[Karel]

I think everyone learned C from their book – it was so well written.

I discovered that book after I did the course which came with Borland Turbo C compiler for DOS....
I still have it somewhere (the book, the compiler I throwed it away once I mastered Linux).

[Nominal Animal]

At the next level, you have low-level programming languages.  Nowadays (among actively-used programming languages), this includes C, Forth, and Fortran at least.

When I did my C programming course, it was considered a high-level programming language... 

That's the reason for the 'Nowadays' in there.    Things change, we adapt.  We learn from the past, but live in today, and prepare for tomorrow.

It takes a variety of problems and approaches to solving them to see and understand the value of having many tools.

In some ways, I think of C the same way I think of PVA glue (wood glue, plain "white" or "yellow" glue, available in just about every store).
It is cheap and simple.  Because of that, some think it is "poor".  Yet, for the task of gluing long-grain wood to long-grain wood (one of the most common cases, and problematic with many other glues in the long term), it is just about the best thing there is.  Not only can you easily make the seams invisible (just clamp them tight, but not so tight you squeeze all the glue out of the seam), but the joint is stronger than the surrounding wood.  And it won't fail due to wood movement, like epoxies and cyanoacrylates might, because the joint is slightly flexible.  And while PVA glue is over a hundred years old invention, we do have improved on it with various slight changes and additives, that make "variants" for example waterproof after curing.

Similarly, I think C has its use cases, and cannot be realistically replaced with something completely different.  We could make it better, though; a lot of the hardware we use C on has features that really didn't exist four decades ago.  Whether that should be a change to the language itself, or a "sibling language" (similar to Python 2 versus Python 3 being mostly the same but slightly different), I do not know.  In all cases, it would need to be as simple and with as few abstractions as C has now, because that is its niche.

[Wolfgang]

... just an academic question:

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

what language would *you* choose ?

[chriva]

C++...

[bd139]

... just an academic question:

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

what language would *you* choose ?

Steel Bank Common Lisp

Edit: fucking iOS autocomplete got me

[paulca]

... just an academic question:

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

what language would *you* choose ?

I'd leave.

But.  If it came to that, it would have to be C or C++.

[JPortici]

C++ hands down

[olkipukki]

... just an academic question:

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

what language would *you* choose ?

English 

If you know so much, that's enough 

[Nominal Animal]

If you want portability, use Python and Qt5.  Qt5 not only provides an uniform look across all operating systems (not exactly "native", but uniform), but also has uniform interfaces to things like network, and serial and usb ports.  A carefully written Python application can work as-is on most/all OSes.
Unfortunately, Python I/O is not very efficient.  If the application works on a lot of data, Python will be slow(er).  Also, you do not use Python if the source code is a trade secret.  You can license it however you wish, but the end users will be able to read the source code.
Finally, the current official Python interpreter, CPython, only runs Python code in one thread per process.  You can have multiple threads in the same process, and that is very useful for things like asynchronous I/O, but for heavy math, you need to use process parallelism to max out the performance.
 
If you need OS drivers, in Linux you do it in C.  (While technically it is nowadays possible to write an userspace "driver", those are fragile things that to an end user like me, are just turds.  I know many members here advocating doing that instead of trying to write a kernel driver, but in my experience, the userspace stuff just isn't worth the effort.  The only exception is "drivers" that use an userspace-exported bus, like USB, Ethernet, Infiniband, or similar.)

If you deal with lots of data, and want a graphical user interface, then your choices are basically C or C++.  There is only one pure C GUI toolkit, GTK+, that has been ported to all OSes, but it does not provide a "native" use ańd feel on Mac OS or Windows, and outside the POSIX/Unix/Linux world, GTK+ is not well known among programmers.  With C++, you have a lot more options available, including Qt; but also things like FLTK, that allows you to do portable GUIs that do look and feel native on different OSes.  Some OSes, like Windows, have much better C++ support for their OS and kernel-level interfaces.

If I was limited to a single programming language for whatever odd reasons, but still wanted to work on that project, the language I'd choose would depend on the particular requirements of said project, emphasizing the above points.

If I was to work on it alone, right now I'd probably go with C and GTK+, developing on Linux, just because in the last few years I've done a lot of POSIXyC, and not much C++, so it'd be less effort for myself personally.

If I was to work with other programmers, I think C++ (and Qt for the GUI) would be the best choice.

You see, even if limited to a single tool – and this really is similar to asking a builder which tool they would choose, if they had to build a house using just a single tool –, I would still pick the tool based on the problem at hand.

(For the house, it'd be a Finnish wood axe, because I could build (a horribly ugly, but livable) log cabin with that; for anything better, I'd need more tools.)

[IDEngineer]

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform... what language would *you* choose ?

C with a small smattering of C++, because I suspect it would yield the largest Venn diagram intersection of: 1) being available on a large number of diverse platforms, 2) known/supportable by a large number of personnel, 3) close-to-the-metal control and performance when you want it, 4) likely to have the library you're looking for when you don't necessarily need control and performance, 5) probably easiest to interface to some other language if needed/wanted.... the list goes on.

This isn't a religious issue for me, I'm just interested in getting the job done with the least hassle. If I had to choose "just one language" that covered everything you said/implied, to me the choice is obvious. YMMV.

[SiliconWizard]

Yes, more or less agree with the two above.

The "right tool for the job" is all nice, but if you are hypothetically restricted to only ONE language, while having to cover many different levels from low to high, one essential criterion, after making sure the language you choose *can* be used for all the tasks at hand, is that you have an excellent COMMAND of this language. You can't properly cover that many areas if you don't.

[radioactive]

C with a small smattering of C++,

So,  basically C with a small smattering of CS philosophy attached to it.

[Fredderic]

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

One that gets far too little mention…  D (dlang.org)…

Older than most of the new crop (no Google or Mozilla pushing it so little less known), but it's been put to use in a number of large projects…  Though it was built around a modern GC, there's ongoing (and already comprehensive) work to make that optional; and most of the standard library comes in at least both allocating and non-allocating forms.  If the runtime it drags along is too much for you, the -betterC option pares it back to, pretty much as the name suggests.  In general it has a huge emphasis on code safety even with (as opposed to, IMHO, C/C++'s tendency to pit features against each other) templating, introspection, compile time evaluation, contracts, and most of the other fancy modern dohickeys, wrapped up in a systems level language following the C/C++ train.  Most recently that I've heard, they've been adding borrower checking to let it drop many of it's runtime checks, and better support alternative allocators like reference counting.  It also strives to bind to other languages, notably being able to invoke C/C++ libraries (with caveats mostly around C++ memory management).  The developers are fanatics, even without backing from those huge companies, it's continued to move forward and pick up steam, and it's been fairly solid except for a split early on when they decided to redo the standard library.

And to answer the challenge more directly; D is being used for GUI (it has it's own, plus bindings several others), web back-end (vibe.d), math (right in the basic language, array/scalar math has SIMD in mind, and others quite readily), drivers (there's an ongoing project to reimplement the Linux kernel in D, starting with the drivers — to bring in D's safety guarantee's, and putting D's system-level claims to the test in the process), control (something in the locomotive industry), data storage (at least one significant product), and multiplatform too (Windows, Linux, Mac, ARM).

On a more personal note, and to swing the pendulum to the other extreme, while it's still a little heavy-handed for my favourite 8-bitters, it's move into AVR ųC (generally in betterC mode) looks to be coming along nicely, and on the desktop, I've often found it easier to throw together D code for some quick tasks, than a comparable bash or Python script (runs a heck of a lot quicker, too).

[radioactive]

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

One that gets far too little mention…  D (dlang.org)…

I really keep meaning to take a closer look at D.  Really does look interesting and worth investigating further (haven't seen a reference to it in some time).  Thanks for bringing that up.

[SiliconWizard]

D is an interesting beast - I've looked at it almost since the beginning - almost 20 years ago.
A lot of interesting ideas, including modules. Much closer to a decent "upgrade" of C than C++ ever was IMHO.

I've unfortunately always stayed away in practice. Not enough people using it, not enough tools supporting it on various targets.

These days, GCC includes a D compiler. I tried, but was not able to successfully build a D cross-compiler for ARM (cortex-M), or RISC-V targets, for instance. Still a significant way to go IMO.
If any of you manages to get a working D compiler for embedded targets though, please chime in.

[Fredderic]

I've unfortunately always stayed away in practice. Not enough people using it, not enough tools supporting it on various targets.

These days, GCC includes a D compiler. I tried, but was not able to successfully build a D cross-compiler for ARM (cortex-M), or RISC-V targets, for instance. Still a significant way to go IMO.  If any of you manages to get a working D compiler for embedded targets though, please chime in.

That seems to be a common statement.  It also seems like most people who've switched to D, haven't regretted it, but there are indeed comparatively few, and it's a bit of an uphill battle to get there — many of them, started by doing bits of tooling around their main project in D, and once they had a good handle on it, and a successful track record, started to bring that through into the main project.  On the upside, if you use the comparable features in C++, D will probably feel like a breath of fresh air.

Also of some amusement, watching a "Cpp Chat" episode last night from late last year, one of the guys on the panel mentioned C++'s "if constexpr" was in fact their answer to D's "static if".  Thought that was interesting timing that I'd come across that right after posting about D here.  That sense they've been chasing D's tail a bit so as not to be left behind…

I will say also, since getting to know D, I try to bring a lot more templating and constexpr into my ųC code, and though I have some success, compared to D it's always a fight to get it to work.  By the same token, Rust seems to have redoubled D's efforts towards memory safety.  It's always been one of their main goals, with @safe being a thing since forever, and the reason they went with a GC — solves a lot of memory-reuse issues right off the bat.  But their work on the borrower checker does seem to be on the heals of Rust potentially swooping in and usurping one of their main goals.  In turn, Rust's system brings flashbacks of doing GTK+ GUI in C, which what seems like weird for this day and age, considering D's push towards cleaner code…  All up, it's a bit like watching a very, very, slow motion 3-way competitive dining event.  And it's great!

As for D on ARM, LDC seems to be the more reliable compiler there.  I haven't done much in that regard myself, or tried cross-compiling D at all for that matter, but LDC's what worked for compiling D code on the Raspberry Pi I have running my home automation, and I've run across other people saying much the same in my searches on the topic prior…  It also seems to be the compiler used in the slow push towards smaller AVR's I've been watching…  Though I don't really hold out much hope it'll get there in a practical way…  As much as I hate to say it, smaller systems just plain aren't on their radar, as much as they need it.  It looks at this point, like that'll be a spot where Rust will make itself home, as gruesome and ungainly as it is.

Whatever way it plays out, I think the single biggest thing against C/C++, is memory safety.  That's an ongoing battle these days, and the main flag being carried by the newer languages.  If anything finally kills off C/C++, I think that'll be it.

[Wojciech Krolopp]

Using C is like driving a car with manual gearbox. It's great fun and about as simple as it can get (only engine, clutch, gearbox, transmission and finally wheels). Sure, you need some practice, you need to think what you're doing but millions of people do it every day safely.

Interpreted languages like Python or LISP are similar to modern cars with automatic gearboxes. They are electronic, full of nice features, automation and safety devices but they are also sluggish (because emission regulations!) and lack any fun of driving. And when they break they cost thousands of zlotys for parts like some stupid sensor.     I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?

For daily driving I have a 1997 VW Passat B3 that I will use as long as it keeps running and passes yearly inspections. Spare parts are cheap too! I also own ex-military FSR Honker with Polish-made Andoria 4C90 engine that I fixed myself (some rust needed to be welded-over). Honker has zero electronics and is very reliable when you know what to check periodically. It's great car to go camping in remote areas because it will drive almost through everything (like old Land Rovers).

Once I had a chance to drive car with automatic gearbox and it was a horror. You have no control over vehicle whatsoever.

[paulca]

I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?

Firstly.  I program Python quite a lot and I drive a manual car, always have.  I think your analogue is somewhat lacking in perspective.

Them: We are going to write it in python...
You: But it's slow!
Them:  Don't care.  Don't need speed.
You: But people don't need to understand how it does everything.
Them: Exactly.
You:  But you could write that in C in two weeks man!
Them:  LOL, You have 1 day.
You: ....  oh ....

[Berni]

I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?

I also occasionally program in python but still prefer a manual transmission car. At the same time i like C for when it is appropriate such as MCUs or low level stuff.

Python is not designed to do the same thing as C. For example do you rewrite your .sh shell scripts in C so that they would run faster and use less memory?

Yes Python commits some serious programming sins in the way code is written in it. But you can't deny its a really quick and easy way of getting stuff done. Go ahead try timing yourself writing a parser for some obscure ASCII file format in C and then time someone else who is used to Python program the same things. Even if the file is 1MB in size both C and Python will parse in the time it takes you to blink. If the file is 10GB in size and you have 1000 of them to parse trough on a daily basis then yeah you might want to go for C so that you don't sit around and wait for it each day. If you only need to run a few 1MB files trough it once, does it really matter if it takes 100ms longer and 2MB more RAM in exchange for the hours more work to program it?

[bd139]

Using C is like driving a car with manual gearbox. It's great fun and about as simple as it can get (only engine, clutch, gearbox, transmission and finally wheels). Sure, you need some practice, you need to think what you're doing but millions of people do it every day safely.

Interpreted languages like Python or LISP are similar to modern cars with automatic gearboxes. They are electronic, full of nice features, automation and safety devices but they are also sluggish (because emission regulations!) and lack any fun of driving. And when they break they cost thousands of zlotys for parts like some stupid sensor.     I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?

For daily driving I have a 1997 VW Passat B3 that I will use as long as it keeps running and passes yearly inspections. Spare parts are cheap too! I also own ex-military FSR Honker with Polish-made Andoria 4C90 engine that I fixed myself (some rust needed to be welded-over). Honker has zero electronics and is very reliable when you know what to check periodically. It's great car to go camping in remote areas because it will drive almost through everything (like old Land Rovers).

Once I had a chance to drive car with automatic gearbox and it was a horror. You have no control over vehicle whatsoever.

If you're in an accident in your 1997 Passat you are dead.

Most people drive like idiots.

QED.

[chriva]

90's cars are mostly fine. If you drive around in something from the 60's with a stiff window and no collapsable zones I'd agree tho...

Nothing wrong with python. The problem is the idiots using it for stuff it's not meant to be used for. Like micropython on microcontrollers. Utterly idiotic...