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

[bd139]

https://documen.tician.de/pycuda/ 

[nctnico]

https://documen.tician.de/pycuda/ 

You kind of beat me to it...

Ray tracer in Python:
https://excamera.com/sphinx/article-ray.html

[engrguy42]

https://documen.tician.de/pycuda/ 

Hmmm...if I didn't know better I'd think that maybe the only goal of some folks here is to prove me wrong, and they'll go Google crazy to find exceptions to what I say....

Nah, can't be. 

BTW, at the time I was starting to get into raytracing I was using C#, and wanted to stick with it for the GUI aspects. I wanted to do a raytracer, but have user control (buttons, windows, user controls, etc.).

Unfortunately, integrating the CUDA-related stuff for my NVIDIA GPU's was, as far as I could tell, a HUGE PITA. So I relented and did it in C++. When I saw all the support stuff available if I did it in C++ (including NIVIDA resources), it seemed clear that C++ was the way to go. For me.

Now I'm sure others were willing to use other languages, but I wasn't. Again, I apologize for not going the extra mile.

Bad boy.

[Karel]

BTW, who gives a F*** what Linus Torvalds thinks?

I do. I learned a lot from Linus and the Linux kernel development in general.

[SiliconWizard]

You can obviously write raytracers without using CUDA, and that's probably what most people were thinking about here when you made that first statement.

But if I were using CUDA, I would personally indeed NOT bother (although it's certainly possible) using any other language than C or C++.

[Berni]

Yes, you can use C# for raytracing. I was merely basing it on my experience whereby CUDA (NIVDIA's GPU API) is pretty much reliant on C/C++, and that's what I was using.

Not a problem. C# will import regular machine code DLL files made with C++ in a similar way it imports its own native .net CLR DLLs. Its just not quite as streamlined.

VisualStudio even lets you create split projects that combine C# and C++ code. The C++ part compiles into a DLL and the C# app imports it. Tho its not really all that great of an experience since some boilerplate code is involved to explain to .net exactly how it should use the functions inside the DLL. But it does work fine.

Most modern languages support these because it is required due to how prevalent these compiled machine code libraries are. Tho i will admit that doing something like raytracing in software using python would likely be ridiculously slow (But this is not what python is made for). Yet even things like JavaScript are rather performant these days (JIT compining and such) and run under the hood of a lot of things. Can't say i particularly like JS personally but it can do some impressive things regardless.

[engrguy42]

You can obviously write raytracers without using CUDA, and that's probably what most people were thinking about here when you made that first statement.

But if I were using CUDA, I would personally indeed NOT bother (although it's certainly possible) using any other language than C or C++.

I suspect that those who have much experience with ACTUALLY writing raytracers would probably say "yeah, you can use other languages, but since NIVDIA rules the GPU world and they have so freakin' many C/C++ resources for CUDA, etc., it's more of a hobby/science project to use other languages".

And they probably wouldn't turn purple searching Google for exceptions as fast as they could. 

Out of curiosity, has anyone here written a raytracer? Perhaps you can show some of your results?

[bd139]

https://documen.tician.de/pycuda/ 

Hmmm...if I didn't know better I'd think that maybe the only goal of some folks here is to prove me wrong, and they'll go Google crazy to find exceptions to what I say....

Nah, can't be. 

BTW, at the time I was starting to get into raytracing I was using C#, and wanted to stick with it for the GUI aspects. I wanted to do a raytracer, but have user control (buttons, windows, user controls, etc.).

Unfortunately, integrating the CUDA-related stuff for my NVIDIA GPU's was, as far as I could tell, a HUGE PITA. So I relented and did it in C++. When I saw all the support stuff available if I did it in C++ (including NIVIDA resources), it seemed clear that C++ was the way to go. For me.

Now I'm sure others were willing to use other languages, but I wasn't. Again, I apologize for not going the extra mile.

Bad boy.

Actually wasn't Google. I did some experiments with that and eventually settled on cuDF for what I was working on. However shite old rules engine based on 1988 tech written in C# won on price vs matching performance vs staff availability to maintain it

GPUs have other uses...

The point is mostly making broad assumptions is not a good idea.

[engrguy42]

The point is mostly making broad assumptions is not a good idea.

Huh? Are you new here?  This place is all about broad assumptions and generalizations and unsupported opinion

[bd139]

I think the average standards are higher than yours personally.

[intmpe]

And yeah, I have lots of fond memories of Fortran 

Are there still compilers available for that?? Hmm.......

Yes, there is a Linux compiler for it and a couple of commercial ones. It is still the preferred language in much of naval architecture (or was) due to the availability of libraries like lapack (IIRC). A lot of finite element stuff was written in it as well for structural engineers. A few years back I was asked to work on some old military code using Fortran 66 - they needed to extend the code as it modeled a particular process. The military usually works on the principal if it works dont mess with it. I hadn't done Fortran 66 but had done Fortran 77. It's a hard language to port due to the spaghetti code nature of it - so its probably going to last a while. It's a lot easier to extend existing code than to port it to C etc.

[IDEngineer]

The military usually works on the principal if it works dont mess with it. I hadn't done Fortran 66 but had done Fortran 77. It's a hard language to port due to the spaghetti code nature of it - so its probably going to last a while.

This is exactly why there's still a lot of COBOL code running government infrastructure too. Nobody dares to be the politician or bureaucrat who bets their job/career on "updating" some long-working COBOL application to a more modern language. Let's be honest, more votes can be bought for less money doing other things.

[IDEngineer]

Since folks like to quote it: "TIOBE Index for May 2020: C passes Java and becomes number 1 programming language".

https://jaxenter.com/c-programming-may-2020-171598.html

[engrguy42]

For a bit more C# perspective, and how it can help with workbench stuff, I'm pretty much done with my data acquisition app. For now. Maybe 75% of it I wrote today, and that's after not touching C# for a while. Nice and quick to get user interface stuff done.

Basically it reads a data acquisition device (Labjack) via USB. I'm also using an excellent C# math library called Mathnet. You can do FFT, for example, in just a single line or so.

You first connect to the Labjack data acquisition device, and it has 8 analog inputs (plus some digitals and other I/O stuff). So I've set it up to let the user enter how many seconds to scan, and it plots that on the top chart. You can then do an FFT on the waveform.

Or you can log data from 4 other inputs, and you can also select via checkbox to do realtime graphing of any of those. The FFT and logging charts are on top of each other, so whatever you select will be enabled and displayed. And you can stop the plotting whenever you want.

In the screenshot below I've grabbed 0.5 seconds of a 60Hz triangle wave, and simultaneously done realtime plots of a couple analog inputs (I varied some power supply dials). I've hard-coded it to sample the bottom inputs every 0.5 seconds, and the chart automatically updates and re-scales the X and Y times and magnitudes. Very slick. And this is just default behavior of Windows forms. 

Yes, you can do something like this in 12 other languages. No question. Though I'm sure I'll be corrected that "it's not 12, it's 13". 

I'm just giving one example of something that can be done real quick, with drag-n-drop charts and buttons and a few hundred lines of code, in case anyone might be interested in setting up something for their workbench.   

[nctnico]

Since folks like to quote it: "TIOBE Index for May 2020: C passes Java and becomes number 1 programming language".

https://jaxenter.com/c-programming-may-2020-171598.html

Interesting. That just made one of my eyebrows move upwards. I did not expect that. Also the decline of C# is impressive. About a decade ago people where convinced C# would kill Java. Some actually called C# 'A Java which works'.

[bd139]

See my earlier rant. It’s dying on its arse. Even the stalwart C# guys are disenchanted. Not because of the platform but the complete mismanagement of it for 20 years.  Honestly wish I hadn’t wasted a chunk of my brain on it.

[engrguy42]

Interesting. Looks like that survey of most popular is based on search engine results. C is the most searched for.

I don't suppose it's because the other languages are easier and more intuitive and don't require a lot of "WTF IS THIS C STUFF??" searches.   

[floobydust]

Computing Science has failed to make a decent programming language.
Every language is intellectually orgasmic and the academics circle jerk off to them, but all fizzle out after many years, and then yet another language is born and the cycle repeats.

C is just a high-level assembly language, extremely dangerous because it really checks for nothing. Think of the all PC Trojans, viruses exe'd due to buffer overflows.
My CompSci Uni prof spent two weeks in class pissing around with pointers in C, seeing what would happen with "funky" de-referencing. It's worse than the Wild West.
Unfortunately C has made it to cars, airplances and other safety-critical applications for embedded systems. It's just too dangerous IMHO.

Just the other day I stumbled onto this:

Code: [Select]

boolean myFlag;

myFlag = 2;
myFlag = "A";
myFlag = 3.14159;

All of which of course compiles and runs in C. Absolute GARBAGE I hate dealing with this language, it needs to have some fixes that don't go all nutbar into C++ polymorphism, operator overloading etc. but people have given up and now it's Python as the latest fad language. Sigh.

[coppice]

See my earlier rant. It’s dying on its arse. Even the stalwart C# guys are disenchanted. Not because of the platform but the complete mismanagement of it for 20 years.  Honestly wish I hadn’t wasted a chunk of my brain on it.

I haven't touched C# for some time. It wouldn't surprise me to find its being mismanaged. It was mostly created for political purposes, so its continued funding would depend on the success of that political ploy. What kind of mismanagement has there been? Poor compiler? Poor libraries?

[bd139]

See my earlier rant. It’s dying on its arse. Even the stalwart C# guys are disenchanted. Not because of the platform but the complete mismanagement of it for 20 years.  Honestly wish I hadn’t wasted a chunk of my brain on it.

I haven't touched C# for some time. It wouldn't surprise me to find its being mismanaged. It was mostly created for political purposes, so its continued funding would depend on the success of that political ploy. What kind of mismanagement has there been? Poor compiler? Poor libraries?

Best bet is hit my previous rant on it https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/msg3053124/#msg3053124

[engrguy42]

For some reason people are compelled to label stuff either GOOD or BAD. And it's never the case.

C is wonderful, it's served millions well for many years. It has pro's, and it has con's.

C++ is wonderful, it's served millions well for many years. It has pro's, and it has con's.

Python is wonderful, it's served millions well for many years. It has pro's, it has con's.

C# is wonderful, it's served millions well for many years. It has pro's, it has con's.

And so on.

Nothing in this universe has ever been perfect. 

And the fact that every tool you've ever used has pro's and con's means that anyone can always point to a con if they want to discredit the tool. But for those who have used the tool successfully for many years, those cons are likely irrelevant.

[coppice]

See my earlier rant. It’s dying on its arse. Even the stalwart C# guys are disenchanted. Not because of the platform but the complete mismanagement of it for 20 years.  Honestly wish I hadn’t wasted a chunk of my brain on it.

I haven't touched C# for some time. It wouldn't surprise me to find its being mismanaged. It was mostly created for political purposes, so its continued funding would depend on the success of that political ploy. What kind of mismanagement has there been? Poor compiler? Poor libraries?

Best bet is hit my previous rant on it https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/msg3053124/#msg3053124

So your main issues are with .net? That has been a disaster for everyone using MS products, not just C# developers. The original versions were a complete joke.

[maginnovision]

My first experience with .net was porting a game written in visual basic 6.0 over to C#. They had a tool to sort of auto port the thing. After it did that it only took 8 hours to fix everything that was broken and double the size of the executable. I haven't really touched it since but I know devs who have and don't have any problems with it. It's all about what you're used to.

[IDEngineer]

C is just a high-level assembly language

...which is both its strength and its weakness, like all good and powerful tools. An idiot can do stupid things and hurt themselves with any tool, and the "less safe" the tool the more likely this becomes. But in the hands of someone competent, few language tools are more powerful or flexible and truly competent craftsmen do not want a bunch of protective features getting in the way.

The better the craftsman, the fewer restrictions he wants (and needs) on his tools. A screwdriver with PlastiDip on its tip may seem "safer", but its usefulness is severely hampered. A soldering iron that "doesn't get too hot" might seem "safer" but might also have very few applications. Both of these might be suitable for neophytes, but not for most people on this site.

Before someone says "But look at all the bugs in [your favorite example] from [your least favorite large software company]" as a supposed example of how C can have bugs even when written by "the best", remember that sheer company size does not guarantee that they hire only competent software people. I've met some surprisingly ignorant software folk who sported business cards with names like "Microsoft" and "Adobe".

As noted herein by others, this is another example of "The right tool for the job". To which I would add, "...while also considering the person DOING the job". C is an excellent choice when the author is competent. The less competent the user, the more hand-holding and safety nets and babysitting they need. Thankfully, there are languages which provide such things when the author is someone who needs such protection.

[rsjsouza]

Another one that does almost exclusively assembly and C due to small memory footprint on the platforms I work. A tiny fraction is done with what I call an alkost naked C++. Right tool for the job.

I do a lot of batch and shell scripting, as well as javascript and some python on the bigger systems.