C Programming Language 'Has Completed a Comeback' (infoworld.com)

InfoWorld reports that "the once-declining C language" has "completed a comeback" -- citing its rise to second place in the Tiobe Index of language popularity, the biggest rise of any language in 2017. An anonymous reader quotes their report: Although the language only grew 1.69 percentage points in its rating year over year in the January index, that was enough beat out runners-up Python (1.21 percent gain) and Erlang (0.98 percent gain). Just five months ago, C was at its lowest-ever rating, at 6.477 percent; this month, its rating is 11.07 percent, once again putting it in second place behind Java (14.215 percent) -- although Java dropped 3.05 percent compared to January 2017. C's revival is possibly being fueled by its popularity in manufacturing and industry, including the automotive market, Tiobe believes...

But promising languages such as Julia, Hack, Rust, and Kotlin were not able to reach the top 20 or even the top 30, Tiobe pointed out. "Becoming part of the top 10 or even the top 20 requires a large ecosystem of communities and evangelists including conferences," said Paul Jansen, Tiobe managing director and compiler of the index. "This is not something that can be developed in one year's time."
For 2017 Tiobe also reports that after Java and C, the most popular programming languages were C++, Python, C#, JavaScript, Visual Basic .Net, R, PHP, and Perl.

The rival Pypl Popularity of Programming Language index calculates that the most popular languages are Java, Python, PHP, JavaScript, C#, C++, C, R, Objective-C, and Swift.

Comments

Don't call it a comeback, it's been here for years

[JoeyRox]

C never went anywhere. Its mindshare was just continually eclipsed by whatever bullshit venture-captial-seeking-paradigm-of-the-month was en vogue for that month.

Re:Don't call it a comeback, it's been here for ye

[RightwingNutjob]

What changed? Did someone let slip that bitcoin mining can be done in C faster than with remote calls to jquery?

Re:pointers

[Anonymous Coward]

Apostrophe plurals are for rubes.

More Popular?

[Neuronwelder]

Maybe they are trying to say it's more popular now? Either way I'm glad!

Re:More Popular?

[Anonymous Coward]

In reality nothing changed, just more of a revelation on how large the sampling error is.

Re:pointers

[Anonymous Coward]

Whoever modded this up needs to have their mod privileges permanently revoked.

C programs are too dangerous for net-connected

[presidenteloco]

computers.

No bounds checking, no type checking. In 2018. Get serious.

My guess is C programs are the underlying reason for a good majority of ways of hacking into systems.

I mean a buffer exploit? Seriously? In 2018? Why in the hell would that be remotely acceptable?

Re:C programs are too dangerous for net-connected

[iggymanz]

Nah, I'm guessing browser tech such as javascript and flash, mobile apps with embedded malware, and on the server side PHP the cause for entry.

And now we're seeing our hardware itself is deeply flawed...from mobile chips to desktop to server to mainframe.

Re:C programs are too dangerous for net-connected

[Travelsonic]

At some point, don't know where that is myself, one needs to look at programming practices as well, and not just the languages being used.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

It's hard to make things idiot-proof these days because idiots are so ingenious. Actually I think SQL injection probably accounts for a larger share than overflows. Also, there's only no bounds checking or type checking if you're too lazy to do/include it, so also remember that it's a poor workman that blames his tools for what he produces.

Re:C programs are too dangerous for net-connected

[Excelcia]

Oh Lord, seriously? This again? C is more dangerous than Java the way that a KA-Bar is more dangerous than a butter knife. If you take a real programming language, hamstring it, put a bib on it, and pull its teeth so it can process nothing more than strained baby food, sure, it won't be dangerous but then again it won't do much useful either.

Write a device driver in Java or Python. Or a kernel. C will always have a place in net-connected computers. You just don't hand a loaded gun to a child and expect he'll produce something useful without blowing his foot off. C is for grown-ups and when you get big and strong and if you eat all your spinach maybe when you grow up you'll do system programming too. Until then, feel free to play around with interpreted languages that pen you in a coral so you don't do anything stupid and feel free to pretend that JIT really does mean it's compiled and just as fast as native code.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

I disagree. Too much of the modern economy now depends upon code to leave safety to the whims, skills or vanity of the programmer. Frankly, the "trust me, I'm good" argument isn't good enough and neither are you. Type safety, bounds checking, protected memory and access control are no longer optional in 2018. You either begin accepting these things or the product liability lawyers are going to win out in court eventually and you will be held financially liable for every bug in your C code. Software has long enjoyed a special immunity to liability lawsuits, but that protection is eroding and rightly so. The days of "trust me, I'm the Jedi Master of C code" are numbered. Better to participate in the transition to safer programming languages and practices than be bankrupted by lawyers, lawsuits and politicians looking for a villain to blame.

Re:C programs are too dangerous for net-connected

[arth1]

No bounds checking, no type checking. In 2018. Get serious.

A halfway good programmer doesn't need to trust the language to do that for him and is capable of ensuring boundaries. The problem is that halfway good programmers have become scarce, and today's coders are content to leave critical parts to a compiler they don't understand and black box libraries they don't know what do behind the scenes. So they need the handholding.

Re: C programs are too dangerous for net-connected

[Anonymous Coward]

So who are these super human's who will write and maintain these perfect sandboxes?

Re: C programs are too dangerous for net-connected

[lucasnate1]

It is easier to write a compiler in C for a safer language than to write everything in C.

Re: C programs are too dangerous for net-connected

[AHuxley]

The people who work with Ada.

Re: C programs are too dangerous for net-connected

[Anonymous Coward]

What do you mean halfway good programmers are scarce?

I outsource everything to India on the cheap who then re-sub it to Vietnam. Everyone wins!

Re:C programs are too dangerous for net-connected

[DCFusor]

No checking? That's what we have programmers for. Now, a lot of people have that title who aren't even coders, frankly....and buffer overflows are usually trivial to prevent, and even actively search for possibilities of (like text search for strcpy instead of strncpy for the simplest imaginable example).
Maybe expecting and getting a programming job that requires experience to do well without that experience (so the employer doesn't have to pay you as much) is more the issue, or could it be that languages that take no skill to program in result in programs written by the unskilled?
Maybe it's like those other things where people want more laws on my freedom because since they have no discipline or self-control, they fear I can't possibly have those things?
Oh, yeah - that side-channel attack on speculative processing - obviously Intel should have written the chip in Rust instead of Sand....Works for hardware too, right?

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

I have a 4096-byte chunk of memory. I use it as a buffer. Every string I will copy into this buffer has already been checked by another function for length and is guaranteed to be shorter than 4096 bytes. If I fire off an "if (strlen(string) >= 4096) return -1;" before the string is copied into this buffer, I've got strlen() walking the entire string looking for a NULL for every single string that is passed to the function, significantly decreasing performance for no valid reason. This is part of why C is faster than other languages: you get a set of insanely sharp precision blades but nothing stops you from precision slicing off the tip of your finger as you cut the problem into pieces.

Re:C programs are too dangerous for net-connected

[phantomfive]

The most common exploit today is the SQL Injection exploit. If you think your language makes your code safe, then you almost certainly have security flaws, huge ones.

Re:C programs are too dangerous for net-connected

[goose-incarnated]

computers.

No bounds checking, no type checking. In 2018. Get serious.

My guess is C programs are the underlying reason for a good majority of ways of hacking into systems.

I mean a buffer exploit? Seriously? In 2018? Why in the hell would that be remotely acceptable?

No, sloppy programmers are the major reason for a good majority of ways of hacking into systems (Meltdown/Spectre notwithstanding).

Exclusively teaching and using bounds-checked, garbage-collected languages are a great way to produce more sloppy programmers.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

And what exactly did you want to say?

Do you even know how a device driver works? There is no fucking difference if I write a device driver in Python or Java, with the small pitfall that Java can not access memory directly (unless it uses unstable features or is on an embedded VM) so one would write a small JNI stub to do that, if one really wanted.

There are kernels written in Java or Modula 2, or Oberon or Eiffel.

The language has absolutely nothing to do with device drivers or kernels.

If you can not program, you shoot yourself into the foot with any language. Just because some people program in C does not make them smarter. IMHO most C programmers are actually not very smart, or they would go for a more interesting, better payed job where thy can put their smartness on the problem domain and not on the programming language.

Have you actually ever seen a "coding style" guideline for a majour C project? It consists to 95% out of "what not to do" and how to "do it instead". For that you usually have a compiler or Lint like tool, not a guidline and a code review about if the braces are put correctly or the constants in an "if (const == value) ..." is always on the left side of the ==.

I have met idiots coming from C who demanded we do the same in Java ... idiots, because it is brain dead to stick to habit without taking your brain and _think_

Anyway, if you love C so much and hate C++/Java/C# come to Germany ... demand on stupid C embedded developers is big here.

But be prepared to get silly questions asked like: "how big is a char, short, int, long in C?"
You would be surprised how many decade old C programmers can not answer this correctly.

Re:C programs are too dangerous for net-connected

[Interfacer]

Actually there are plenty of highly interesting and good paying projects for which C is the only real option. A decade ago I was a C and C++ programmer, and pretty good if I say so myself. I cared to write bullet proof and well documented C code, and companies paid me a lot of money to do just that. I wrote firmware for the 2000 series Texas Instruments DSP to control the semiconductor for a telecom laser. That was all C without even standard libraries because the DSP only had a couple K of RAM and ROM.

I wrote software for a set of kernel level linux deamons that did IO via optical interfaces with GPS sattelites or a spy camera that was going inn space. My inter process communication was basically all 'C with classes' and the communication with the interface was all straight C because when delaing with PCI boards and ISA interfaces, you're dealing with mapped memory that you have to write to at specific addresses following certain protocols

All those projects were in C, and among the most interesting and rewarding projects I've done.

Re:C programs are too dangerous for net-connected

[serviscope_minor]

A halfway good programmer doesn't need to trust the language to do that for him and is capable of ensuring boundaries. The problem is that halfway good programmers have become scarce,

Halfway good programmers have ALWAYS been scarse.

Even if I was a great programmer in general, I sure wasn't last week when I was sleep deprived and my head felt stuffed with wool because of having a cold.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

Hypocrite much?

and black box libraries they don't know what do behind the scenes.

That is exactly the point about a black box library. You should not need to know what is going on in it.

No, they don't need hand holding. If they needed to know what is going on in the black box: then they would need hand holding.

Unless you have read the most basic C manuals, you usually don't need to know how strlen() and strcpy() is implemented. Fortunately or unfortunately however they make good examples about the strength (the weakness is never mentioned) of C idioms.

Strlen and strcpy are (should be) just black boxes. And the relevant C++ str library functions are for me black boxes, I never looked at them. Why the funk should I?

(Funny: strlen and strcpy are in my dictionary, they are not red underlined ... when did I do that?)

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

Discipline and self control needs to be taught, or acquired by experience. Experience means making mistakes and learning from it, which bottom line means: you have to realize you made a mistake, or worse, someone has to point it out to you!
No one wakes up in the morning after he had read "programming language X" manual and suddenly knows what kind of discipline and self control he needs to use to work in that language (with its libraries).

Knowing what a buffer overflow is and knowing how to program so that you avoid it, are two different things. Actually avoiding it is then again another matter, because you have to wake up in that situation and tell your self: "oh, this is actually a situation where a buffer overflow could occur!" (Or insert any other simple weakness)

It is much simpler and sane to delegate that problem to a library developer. Sometimes however you are the library and application developer in the same person.

Anyway, I rather use a language that "works" instead of C were you need "discipline" and "self control" and get blamed by others that you lack those character properties because yo made a simple bug which never had happened in a different language.

You know: most people would feel rather insulted if you tell them: "you lack discipline", "you lack self control" (even if it is true, lol, but we are not about to visit the anonymous alcoholics, or are we?)

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

and buffer overflows are usually trivial to prevent, and even actively search for possibilities
Says the one who never programmed one?

If you only program in your small world then avoiding them is relatively simple. As you are AWARE that there could be a buffer overflow.

As soon as you have to treat data coming from the outside, that is a different matter. Most people are NOT AWARE that this here:
/*
  * Doc:
  * buffer will be \0 terminated when read from disk
  * buffer will be \rs terminated when read from network
  * size will always be below 255 (max size 254)
  */
struct Data {
int size;
char* buffer;
};

is a candidate for a buffer overflow (or other "corruptions") if you read said Data from a network or a file.

What kind of for loop are you writing after you read the "size" info and allocated "buffer = malloc(size)"?

Do you read "size" bytes, risking to not read enough and continue reading later at the wrong spot in the stream? Or do you read till "end of stream" (either \0 or \rs) hence reading to much and running over the buffer? Obviously you you have to check for both ...

So first question in a CS course would be: "erm! why would I have to check for length/size and terminator? Why would they be different?"

You would wonder how many raised eyebrows it causes if you simply answer: "because the data you read was not written by you(your program)".

You see: people write the "write function" and the "read function" ... and have tests for both. And they never come to the idea (by themselves) that they also have to be able to read data someone else has written to disk (with a different program).

So no: buffer overflows are not a simple thing to avoid. Because you have to jump out of the box of your mind.

Re:C programs are too dangerous for net-connected

[dunkelfalke]

demand on stupid C embedded developers is big here.

I am one. But I agree, C sucks. I am glad that my Pascal days have taught me not to try to be clever when developing software.

Re:C programs are too dangerous for net-connected

[TheRaven64]

Actually I think SQL injection probably accounts for a larger share than overflows

I don't have a more recent statistic, but an MSR study from 2012 found that around 70% of all exploited security vulnerabilities are buffer overflows.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

In my opinion Pascal is still the best language to teach programming.
And it does not lack anything to do serious developments in it.

Re: C programs are too dangerous for net-connected

[TheRaven64]

A very small subset of programmers, working with formal verification tools. It's not that we don't know how to write correct code, it's that we don't know how to write correct code cheaply. The seL4 team estimates their development cost at around 30 times that of a state-of-the-art conventional software engineering team with full test coverage that isn't using formal methods. That's not a cost that people are willing to pay for all software, but it is a cost that's easily amortised when it's just for a relatively small set of things in the trusted computing base.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

Well, those jobs likely will always exist.
But I doubt they need "special skills", you only need to know the hardware and its limitations you are on.
Would not matter if you address the same problems on said hardware in assembler or pascal or Java.
You would not have a JVM, though, but would need a java to nativ e compiler ... and then you simply would ask yourself: why not using C?
Anyway, I was more complaining about the idiots here on /. who think to be a "magician" amoungst "mere programmers" you need to know C.

Re:C programs are too dangerous for net-connected

[TheRaven64]

The basic job of a programmer is to automate things: to make a computer do things, rather than a human. That is the entire point of all programming. What kind of programmer, when faced with a problem for which there is an existing generic solution with adequate performance prefers to write an ad-hoc solution? A poor one. Yet that's exactly what you're advocating: your notion of a 'halfway good programmer' is one that doesn't make use of the results of programming.

There are places where manual memory management, deterministic performance, and pointer arithmetic are absolutely essential requirements. In these situations, C or C++ are about the only options (Rust might be, but most of these projects require long-term maintenance and Rust is far too young to consider for that kind of project). For everything else, your choice is either reinvent the wheel in an ad-hoc way, or use one that's been well tested and optimised.

Re:C programs are too dangerous for net-connected

[TheRaven64]

And even with all of the checks that you describe, you're only looking at the most trivial part of the problem: single-threaded execution. In the C memory model, if there's an update to either size or buffer from one thread, without explicitly synchronisation establishing a happens-before relationship with another thread, then the other thread may see mismatched versions of these and see a length that corresponded to a longer buffer. Unless you make your objects immutable (which C doesn't enforce, but at least a custom static analyser can check, in the absence of any use-after-free errors), this kind of bug can be incredibly subtle, but exploitable.

Re:C programs are too dangerous for net-connected

[TheRaven64]

Except, in this example, in pretty much any other language the string representation would be a pair of a pointer to a buffer and a length and the length would be guaranteed by the language runtime to be trusted, so you'd never have to do the equivalent of strlen.

Re:C programs are too dangerous for net-connected

[Interfacer]

C is a fairly easy language to learn and understand. I basically had only 2 'special' skills that were very much appreciated by the senior engineers in the companies where I worked. the first one was that I have a masters degree in electronics and had theoretical physics as a hobby when I was in college. So aside from being a good programmer, I had the knowledge to understand the physics and instruments I was dealing with, which was a real benefit.

And my second 'special' skill was the fact that I wanted all my code to be bullet proof, and deal with every type of malformed data packet, data mismatches, incorrect use cases, etc. And I applied that same constraint not only to my code, but also to the logic it implemented. I knew how the instruments worked and what they were made to do. So my logic also set boundaries to the things that were allowed.

I hear you thinking 'that is not all that special' and I agree. But you'd be amazed how many programmers, even in those sectors, are satisfied with code that works. I always take it as a given that code should work. You should try to make it fail, once it is implemented. Ever night, every weekend, I ran more and more unit tests non stop, and injected bad commands and bad data at random intervals in order to see if I missed something.

Again, in itself not special, but the majority of C programmers in the companies I worked at did not have that mentality.

Re:C programs are too dangerous for net-connected

[luis_a_espinal]

computers.

No bounds checking, no type checking. In 2018. Get serious.

My guess is C programs are the underlying reason for a good majority of ways of hacking into systems.

I mean a buffer exploit? Seriously? In 2018? Why in the hell would that be remotely acceptable?

^^^ Another internet person that doesn't know what the fuck he/she's talking about.

News at 11.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

Well,
it is very special: as many programmers don't do this, or as there are many cases were this is not that important.
Example: I designed or help designing a simple finite state machine based on 3 sensors in a tank and two pumps that should either automatic or semi manual pump content out of the tank.
(Yes, super simple, nut the devil is in the details)
So, there are two kinds of sensors, floating on/off switches giving a digital signal and analog sensors (based on a floating ball in a tube, giving a signal in mili amperes), you could configure the system to use either of them.
So as I did not know on which levle I should help modelling this in UML (yes, UML for C), I asked the chief programmer: how would you approach this without me? The main use case was: if the tank is full, it should start pumping until it is empty or manually switched off/resetted.
So he started to define states:
FULL :- Floater is ON, Floater 2 is ON, Floater 3 is ON. (floater 3 the highest floater in the tank)
EMPTY :- Floater is OFF, Floater 2 is OFF, Floater 3 is OFF.

Then actions, eg.
FULL -> start pump(s).
EMPTY -> sto pump(s).

Then I asked, yeah, all fine, but what if the State is:
Floater 1 ON, floater 2 OFF, Floater 3 ON?

He said: "oh, good idea! We need a state: PUMPS_OFF, Floater 3 Error".

We found several such states. Before people ask, why they needed me to do UML ... that was a product family of various pump controll units with a fancy UI - fancy in the sense that you had a 4 line screen with 20 or so chars, multiple languages UI, and 4 arrows and a select and cancel key. You could have one or more pumps, as mentioned above variouos measuring systems that should be calibrated. Options to optimze pump running hours (1 always a few hundret hours ahead of the other one, or both used alternating, trying to keep them close in running hours, watching for overheatin (an indication that the level sensors are faulty), random time contiue pumping after the relevant floater said stop (to prevent collectin a ring of drying foam/shit or whatever around the level of the floater etc. pp)

Anyway, a simple C program, becomming complex by the relatively huge amount of configuration options.

But ... all this above, and your C experience regarding scientific instruments, is completely unrelated to programming languages. Parameter checking and in the example above, figuring that certain on/off conditions of the sensors indicate a fault has nothing to do with C etc.

Re:C programs are too dangerous for net-connected

[arth1]

Unless you have read the most basic C manuals, you usually don't need to know how strlen() and strcpy() is implemented.

Oh, I'd say that yes, you do.
- How they can runaway.
- I don't think I could count the times I've seen an overflow because programmers fail to realize that strcpy() also copies the trailing \0.
- Why using strlen/strcpy on a string converted from Unicode with a library routine is perilous because the result might have \0 embedded, and thus not be just one string.
- When you need a mutex to prevent the rug from being pulled from under you.
- How strcpy/strlen deal with byte vs word vs longword alignment, and whether that makes the speed predictable or not.

For complex functions, I do not expect developers to understand the intrinsics, but for basic functions like these, yes, they should know and understand all caveats completely.

Re:C programs are too dangerous for net-connected

[Wootery]

feel free to play around with interpreted languages that pen you in a coral so you don't do anything stupid and feel free to pretend that JIT really does mean it's compiled and just as fast as native code.

You were doing so well, then you confused build-model with abstraction-level.

You're right that compiled Java is reliably slower than compiled C. You're completely mistaken to imply that a JIT compiler doesn't count as a real compiler.

They are developed by compiler engineers. They use ordinary compilation and optimisation techniques (SSA form, for example) because, you know, it's a compiler.

Microsoft have implemented offline compilation for C#. Did that magically make it as fast as C? No, of course not. Similarly, Oracle are apparently working on some sort of offline compilation for Oracle Java. Will that magically make Java as fast as C? Of course not. Neither do the existing ahead-of-time Java compilers (Excelsior JET and the long-dead GCJ). It makes little difference when the compilation takes place.

Compiling C at runtime doesn't magically nullify the advantages of C, either. JIT-compiling C is standard fare with graphics shaders and OpenCL, and it's an option with CUDA. Needless to say, all three are extremely high-performance.

Re:C programs are too dangerous for net-connected

[arth1]

I agree, but I think my definition of "programmer" may differ from yours.

Much like I don't consider a guy with a table saw and staple gun who cuts and assembles pieces of wood a "cabinet maker" if he doesn't know how to make dovetails or french polish, I don't consider someone who assembles pieces of code a "programmer" if he can't handle manual memory management, deterministic performance and pointer arithmetic.

There's a need for both people with staple guns and black box libraries, but there is also a need for those who can dive a bit deeper, and I don't think the former deserve six figure salaries.

Re: C programs are too dangerous for net-connected

[Anonymous Coward]

Disco. I come to every thread about either C or Rust looking for the pro-Ada comment and add one if its not there. I work in security of embedded systems (you could argue I'm a bona fide expert, having spoken on an experts' panel at SAE and published a paper on embedded systems security at the USENIX WOOT workshop, and I started my career as a C programmer. I love C, but it's the wrong language for safety-critical cyber-physical systems. Ada, however, (definitely not Rust) is mature and proven. I do not want to hear anything about Rust. If automotive is going to get off of C (and automated and autonomous vehicles could be the final justification to do that), we need to embrace Ada.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

Anyway, if you love C so much and hate C++/Java/C# come to Germany ... demand on stupid C embedded developers is big here.

How is the demand for smart C embedded developers?

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

The approach to any potentially unbounded stream is to pick a reasonable size (1024, or 1500, a billion - doesn't matter) and read data into that fixed-length buffer. This allows you to scan for terminators, validate length, sanitize, etc, etc, etc.

It's simple: if you don't have a size you can trust - YOU chose a size and trust that. Adapt size dynamically for more efficiency/throughput if necessary. Coalesce periodically or when finished. Calling for some fruity "new" language with padded saftey helmets and training wheels is defiintely not the solution.

Bloated, "enforced safety" languages are why everything runs dogshit slow and still has show-stopping problems.

Re:C programs are too dangerous for net-connected

[erapert]

JIT generally is just as fast as native code. It's things like automatic garbage collection, on-the-fly object generation, dynamic typing, bounds-checking, and other language inefficiencies which slow down the languages which are commonly JITed (i.e. C#, Dart, JS, Java, etc.).

Code written in C is so fast because the people who write with it don't screw around and the language allows them to fully utilize their expertise.
This is probably fairly obvious to anyone who is a programmer though.
The reason C is making a sort of comeback is that more people are catching on and there was a serious lack of alternatives for a long time.

Now there are alternatives which are actually very good and can actually deliver exactly the same things that C delivers but with improvements to productivity and safety. Namely: the new C++ and Rust.

Older versions of C++ have left a bad taste in people's mouths. There's some good reasons for that, but I think it's unfair to paint the new C++ with the same old brush and assume it hasn't changed and improved. On top of that, there's decades of experience with it (for those who have braved the rough edges these many years) and a consequent glut of extremely nice tools for C++ that have all been blooded and well used. I like modern C++ and I want it to improve, but there's some real issues that need to be addressed. Lack of standard cross-platform batteries-included libraries is an embarrassment. npm, pip, and even cargo have been around for years; it should have been C++ that came out with this stuff first. On a related note, module support needs to be implemented and landed now.

The new kid, Rust, shows some very impressive promise. But it's still new and is still earning its stripes and there's a serious lack of good tools for it. Until Rust gets its own IDE with full auto-complete and visual debugging support you can expect Rust to remain the domain of hipsters and iconoclasts while C and C++ continue on. It's still early, though. I have great hopes for Rust.

Re: C programs are too dangerous for net-connected

[AHuxley]

AC C was great for fast fun computer games for the post Basic generation.

Re:C programs are too dangerous for net-connected

[erapert]

1. Nobody can be an expert in everything.
2. Software now reaches domains that were previously unimagined, so there's now more domains than ever to be an expert in.
3. Specialization is the inevitable, essential, and indispensable result of an expanding software industry.

How many people that work in an Adidas factory could make a shoe from scratch? And yet our shoes are so much better than they were two hundred years ago and so plentiful and so cheap that we buy new ones every couple years instead of repairing the ones we have.

The same could be said of cars: an assembly line probably doesn't even know what kind of metal the engine block is made of much less how to actually produce the engine block or how it works.

I understand your point. And yes, it would be better if everyone knew and understood everything about everything.

But here in the real world we're trying to pay bills, keep food on the table, and send the kids off to college. It's not my job, nor yours, nor should it be, to wax egotistical about how much I know about this library or that language or such-and-such complex system-- it's impossible anyway.

Re:C programs are too dangerous for net-connected

[arth1]

How many people that work in an Adidas factory could make a shoe from scratch? And yet our shoes are so much better than they were two hundred years ago and so plentiful and so cheap that we buy new ones every couple years instead of repairing the ones we have.

Adidas factory workers don't claim to be cordwainers.
Code monkeys claim to be programmers.

Re:C programs are too dangerous for net-connected

[TheRaven64]

Much like I don't consider a guy with a table saw and staple gun who cuts and assembles pieces of wood a "cabinet maker" if he doesn't know how to make dovetails or french polish, I don't consider someone who assembles pieces of code a "programmer" if he can't handle manual memory management, deterministic performance and pointer arithmetic.

You're conflating 'knows how to' and 'thinks it's a good idea to.' Just because someone can make dovetails and french polish doesn't mean that they won't buy Ikea furniture when there's something that suits their requirements, because it's a waste of their skills to manually build something when a mass-produced off-the-shelf alternative is adequate. Similarly, just because someone can handle manual memory management and pointer arithmetic doesn't mean that it's the best use of their skills to pick a language where they need to: in most cases, it's better for them to pick a language that handles these and for them to focus on data structure and algorithm design.

Re:C programs are too dangerous for net-connected

[iampiti]

Cool story. Also, in your case there weren't probably many people who apart from being a good programmer knew the problem domain.
I'd like to work on projects that allowed me that kind of precise work

Re:C programs are too dangerous for net-connected

[erapert]

I don't think that straight up elitism is a good argument for anything.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

Your comment honestly scares me, but I expect it's a fairly common view, which probably explains so much shit software out there. I use libraries all the time so I don't reinvent the wheel. But I always look at it to see how it works to ensure that it actually does what I think it does, rather than just assume it works the way I need it to. I have trouble of thinking when it's acceptable to use a library without understanding its internal workings.

Re:C programs are too dangerous for net-connected

[No Longer an AC]

This is an abbreviated version. The whole thing can be found here:

http://www.menlo.com/folks/ada...

Programming Languages for Shooting Yourself in the Foot

C
You shoot yourself in the foot.

Algol
You shoot yourself in the foot with a musket. The musket is esthetically fascinating, and the wound baffles the adolescent medic in the emergency room.

FORTRAN
You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception-processing ability. ...

lisp
You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds . . .

Assembly
You crash the OS and overwrite the root disk. The system administrator arrives and shoots you in the foot. After a moment of contemplation, the administrator shoots himself in the foot and then hops around the room rabidly shooting at everyone in sight.

C++
You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "that's me, over there."

Ada
If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad, and tell the soldiers, "Shoot at his feet."

Modula/2
After realizing that you can't actually accomplish anything in the language, you shoot yourself in the head.

csh, etc.
You can't remember the syntax for anything, so you spend five hours reading man pages before giving up. You then shoot the computer and switch to C.

Pascal
The compiler won't let you shoot yourself in the foot.

Unix
% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o: No such file or directory
% ls
%

Re:C programs are too dangerous for net-connected

[iMadeGhostzilla]

I also agree, but I think my definition of "adequate solution" may be different from yours. A generic solution by definition supports the lowest common denominator across the many use cases. Almost each new use is different from others, and if frequent enough calls for nuancing. Take almost anything -- from planes to credit card chip readers to abstract things like containers and at some point economy and business and just human nature will demand for such nuancing to take place, or they'll take their money elsewhere.

This is where language in which the original generic solution comes to play -- often it's just the most time effective to extend the solution in its original language than to use a new language. And an awful lot of generic solutions are written in C and C++ (as are in Java and PHP and so on in other domains). I think this is why they persist.

Re:C programs are too dangerous for net-connected

[minstrelmike]

But it's really, really, really fast. So fast we can even process data sooner than we check for privilege. It's awesome.

Re:C programs are too dangerous for net-connected

[TheRaven64]

A generic solution by definition supports the lowest common denominator across the many use cases

It's not quite that clear-cut. A well-optimised generic solution is often better than a quickly written specific solution. Sometimes, the domain knowledge is useful. For example, if you're sorting a load of integers and you know that they're always going to be in the range 1-10, then a custom bucket sort will always be better than pretty much any generic sorting algorithm (a well-optimised radix sort may happen to give better performance, but it's unlikely).

With memory management, this is rarely the case. Any ad-hoc use of malloc and free (or new and delete) is likely to be no better than using an optimised garbage collector (especially in an environment with concurrency) and must be 100% correct in every case to avoid security-critical bugs. Good C/C++ code that actually needs manual memory management typically uses custom allocators. For example, dovecot provides a separate stack allocator that is not tied to the call stack, so you can cheaply allocate memory that will be returned up the stack. You may only pop things from the stack when you have finished processing return values. This can be a lot faster than a generic garbage collector because it is taking advantage of the fact that some things have statically known lifetimes and are known not to escape. In theory, a compiler could do this automatically (and a few research implementations do), but unless you have a language with a type system that makes this kind of ownership explicit then it's very hard. Similarly, LLVM uses a bunch of bump-the-pointer allocators that release all of their memory at once (and don't bother running destructors) or simply don't release memory when used in a short-lived tool such as clang (the memory allocated by them is almost all live right up until you finish emitting code, and then you exit the process so there's no point in bothering to clean up before then). This is very fast to allocate, and for the typical use case of a compiler is free to deallocate.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

The last time I checkt strcpy() was implemented like this:

char* strcpy(char* dst, char* src) {
      while (*dst++ = *src++)
              ;
      return dst;
}

So obviously it does not work for UTF-x or wide characters.

I guess you picked a bad example.

P.S. just for the other idiots (not you), no: I did not to need to google for it facepalm

Re:C programs are too dangerous for net-connected

[arth1]

Reading comprehensibility, yours; lacking, it is.

If you look up again, I was talking about strings having been converted from Unicode. Unless understanding how strcpy works, a programmer may very well attempt to run strcpy on the result of a conversion from Unicode to an 8-bit character set, and expect it to work. Which it may, once, twice or a hundred times. But one day it will not, when the conversion decoding leaves a \0 inside the 8-bit result.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

Unless understanding how strcpy works, a programmer may very well attempt to run strcpy on the result of a conversion from Unicode to an 8-bit character set, and expect it to work.

Exactly. This is why C is not for beginners, and a foot gun.

The designers of C expected you to know that strings are arrays of ASCII bytes that terminate with null, and that you would NOT feed bad data into the function and expect it to work.

Re:C programs are too dangerous for net-connected

[angel'o'sphere]

I never worked with unicode in C, so I did not get what you meant.
Nevertheless this is stuff which should be written in the documentation, and should not need to make it necessary to know implementation details.

Re:C programs are too dangerous for net-connected

[Anonymous Coward]

I don't think I could count the times I've seen an overflow because programmers fail to realize that strcpy() also copies the trailing \0

It's even on the man page, fer Pete's sake!

both indexes are search popularity rankings

[iggymanz]

These aren't measures of how much languages are used, they're useless bullshit as asking which languages generate the most Twitter Tweets? Facebook posts? News articles?

Number of jobs held would be interesting.

So would number of unique jobs openings for each language.

Re: both indexes are search popularity rankings

[sg_oneill]

Job adverts are certainly an interesting method but never the whole story. I've been checking job listings since the 90s for python and up till about 3-4 years ago where rarer than hens teeth (there's a tonne now since the management types finally discovered it). But all that time there was a huge amount of local devs using python for personal projects , glueing things together with it in server racks, holding conferences and meets and so on. Hell one of the founding devs of Django even lives near me. But goddamn it was hard to find work with it , until recently

Driven by Raspberry Pi?

[smist08]

With all the low cost ARM computers, perhap people appreciate the speed of C. Generally you get smaller faster programs. Or perhaps more people are working on the Linux kernel?

Re:Driven by Raspberry Pi?

[sourcerror]

You can use more advanced programming languages on the Pi that have decent execution speed too, like Java or C#. I think C's popularity is more driven by Arduino, where other alternatives don't exist.

Re:Driven by Raspberry Pi?

[TypoNAM]

Except the fact that Arduino IDE uses C++ not C.

Re:Driven by Raspberry Pi?

[DCFusor]

I kind of like arduino's slightly relaxed version of C++ myself, and use perl or C/C++ in pies to do the linux type stuff - databases and web servers - for my arduino based automation devices (often ESP based). Works for me - use C(++) where you are super time-dependent and need utter control and some higher level language for the glue that saves programmer time and effort and catches some of the errors. I personally missed the Java and PHP trains, but I hear I didn't miss much...something about fractals of bad design springs to mind? I'm sure you can write good code in them if you understand them down to the metal, but if you do, why use one of them? Use something you have real control over.

Re:Driven by Raspberry Pi?

[TheRaven64]

The slowest Raspberry Pi has 512MB of RAM and a 700MHz 32-bit processor. The original Smalltalk-80 implementation ran on a 2MHz 16-bit processor with 512KB of RAM and contained a full graphical user interface and applications written entirely in Smalltalk, a pure object-oriented language that didn't even have concessions to implementation ease like primitive types or intraprocedural flow control[1]. It did use some clever microcode tricks to make things like screen updates faster, but even without these Smalltalk was quite performant on a 20MHz processor.

The idea that a RPi is too slow for a high-level language to be fast enough is astonishing.

[1] In Smalltalk, integers are immutable instances of the SmallInt class, which is typically implemented as a tagged pointer. If integer arithmetic overflows, the result is an immutable instance of the BigInt class, which is stored as a pointer to an arbitrary-precision integer object. It's depressing how later dynamic languages, particularly scripting languages, haven't managed to have as useful integers. Smalltalk also had a variety of floating point types. It did not have things like if statements in the language. True and False were singleton subclasses of the Boolean class, which implemented methods like ifTrue: and ifFalse:. These took a block (closure) as an argument and either executed it or didn't execute it, depending whether they were True or False.

Re:Driven by Raspberry Pi?

[Anonymous Coward]

It uses a minimal C++.
I do use arduino-C++ for ESP32 microcontrollers for real-time applications but I've never used C++ containers nor even used the heap.
So it's C with some C++ touches more than latest C++

Actually I really enjoy this minimal C++ as it's really fast and there is way less undefined behaviour

Re:Driven by Raspberry Pi?

[Kielistic]

Just because you aren't writing anything that requires runtime performance does not mean that no one else is. It sure is a good thing that someone had the knowledge and ability to write those microcode tricks to make that system usable.

Would you turn to a C programmer or a Python programmer if you needed someone to do that?

Re:Driven by Raspberry Pi?

[K. S. Kyosuke]

It's depressing how later dynamic languages, particularly scripting languages, haven't managed to have as useful integers.

Well, I don't know...I seem to be pretty happy with modern Scheme. Hell, you even get complex numbers in the base package, including Gaussian rationals and all standard functions defined in the complex domain.

Re:Driven by Raspberry Pi?

[TheRaven64]

Scheme is technically a later language, but it's a dialect of Lisp, which was one of the inspirations for Smalltalk (and, in particular, where Smalltalk copied this feature from), so I'm not sure it really counts in this regard.

Re:Driven by Raspberry Pi?

[sourcerror]

That's correct, however most of the example code you'll find is written in C style C++.

Re:Driven by Raspberry Pi?

[sourcerror]

Java and PHP are very different beasts. The fractal of bad design refers to PHP.

Java has minor design oversights like type erasure in generics, but otherwise a decent language with decent tools and libraries.

Re:pointers

[Anonymous Coward]

Bill O'Reilly once attempted Matlab after finishing C and *totally raged* on the professor.

In other news

[Anonymous Coward]

The slotted screwdriver is making a comeback, according to a brand new survey of home improvement tools.

Needs updating

[Ichijo]

In Standard C, how do you find the least significant set bit of an integer type? Most CPUs these days support a clz instruction, but Standard C doesn't.

Re:Needs updating

[Anonymous Coward]

How do you do it any other language?

Do they have an operator for that operation or use a function syntax or what?

Examples please.

In C I can easily inline whatever assembler instruction does that.

There are a lot of functionalities that all kind of processors have that are not supported directly in high level language syntaxes.

Re:Needs updating

[chrism238]

Why do you believe that a programming language Standard needs to provide a standard for a specific CPU-level instruction? Can you name another standardised language that does so as part of the language?

Re:Needs updating

[Anonymous Coward]

Best solution: Use autoconf or cmake to figure out if your compiler defines __builtin_clz. If your compiler has a different name for the built-in, just add a #define __builtin_clz whatever_your_compiler_calls_it. Otherwise, add a #define __builtin_clz slow_clz so the source code doesn't have to change.

To define slow_clz(), start here, and then pick your favorite implementation under "Finding integer log base 2 of an integer (aka the position of the highest bit set)." It really doesn't matter which one you use. You could even use the while loop.

You're welcome. (Yeah, I know that's more work than the hypothetical C20 #include <builtins.h>, but this works today.)

Re:Needs updating

[Darinbob]

A good compiler will convert a loop for finding the bit into the single instruction.

Re:Needs updating

[Anonymous Coward]

gcc has __builtin_clz().[1] So does clang.

Why do you think that's something that should be part of the Standard [sic] C?

[1] https://gcc.gnu.org/onlinedocs...

Re:Needs updating

[Anonymous Coward]

I'm guessing that would have to be a darn good compiler to do that trick reliably..

Re:Needs updating

[Pseudonym]

If your C standard library doesn't have ffs(), then... sorry, Windows user. I guess there's always _BitScanForward or __lzcnt.

Oh, and if your CPU uses clz to count trailing zeroes, you should report that as a bug.

Re:Needs updating

[arth1]

In Standard C, how do you find the least significant set bit of an integer type?

Is this a trick question? Something like this in a #define, I suppose?
for (i=0;iwhy you would need to do that - chances are that you're complicating things when you don't need to, and just need an & operation. If you stumbled upon this when trying to do netmasks, be assured that the problem is already solved, and quite efficiently too.
C is helpful in making you think and find simpler algorithms, which execute far more efficiently than bloated libraries and language intrinsics that have to deal with cases that can't occur.

Re:Needs updating

[arth1]

Oops, forgot about slashdot parsing <

for (i=0;i<sizeof(var)<<8 && var % (1<<i); i++);

Re:Needs updating

[AmiMoJo]

I think you meant & instead of %.

In any case, there are better ways to do this: http://graphics.stanford.edu/~...

My favourite is the second example using only AND operations with constants. It's faster and has more predictable execution time, although it's not constant.

I seem to recall that some systems (BSD?) have a prototype function for this in their standard library too, which on some CPUs complies to a single instruction.

Re:Needs updating

[Anonymous Coward]

Part of the problem is that the average coder these days wants to run "npm install clz" or similar instead of implementing the one missing thing they needed, which can then lead to problems such as the npm left pad debacle. Posting anon because I used mod points here.

Re:Needs updating

[Ichijo]

It isn't specific to a single CPU, this category of instructions are also found in ARM and PowerPC, even the PDP-10 provides hardware support for counting trailing zeros in an integer. Counting leading/trailing ones or zeros is common in many problems such as compression algorithms. And on platforms without FPUs, the compiler would emulate floating point instructions in software, so there's precedent for providing C language support for instructions that aren't available on every CPU.

Re:Needs updating

[Anonymous Coward]

so there's precedent for providing C language support for instructions that aren't available on every CPU.

Oh for FFS. You want speed? Fine. Make a 256-entry table, break the int into bytes, lookup. 32-bit int, four lookups and a few branches. byte, one lookup. Use a union to do the breaking for you; Etc.

Got lots of memory? Fine. Make a 64k table. Break the scalar into 16 bit chunks. Etc.

Not a speed issue? Shift and count. Done.

Both approaches are architecture independent.

The level of incompetence here is stunning. It's no wonder you twerps think c "isn't good" - you have no idea how to accomplish the most basic of challenges.

Re:Needs updating

[Anne Thwacks]

The OP is probably planning to write a TCP/IP stack in Javascript, but they will use Agile, so pay no attention.

Re:Needs updating

[K. S. Kyosuke]

That would probably have to be a strong-AI-equipped compiler to be able to prove that a random piece code is equivalent to your instruction. Hell, that sounds like formal verification of a function, actually.

Re:Needs updating

[Darinbob]

Ok, it won't do all relevant pieces of code, but you can search the gcc source code to find similar things. You can experiment and notice that the compiler may be more efficient if you write your for loop one way than with a different style. That's because it will do pattern matching on the intermediate code, a type of peephole optimization. Change the code slightly and the pattern doesn't match anymore.

Re:Don't call it a comeback, it's been here for ye

[Hognoxious]

whatever bullshit venture-captial-seeking-paradigm-of-the-month was en vogue for that month.

These days, whatevers-of-the month barely last a week.

Correction

[Anonymous Coward]

promising languages such as Julia, Hack and Kotlin

This really only indicates where jobs are now...

[StevenMaurer]

No one is seriously going to try to use C for front end web development, just as no one is seriously going to try to use Javascript in an embedded microprocessor. So what this study is doing is just pointing out where the current jobs are.

Trying to compare languages, is like asking "which is better? a band saw or a screw driver?". They're entirely different. And anyone who doesn't understand that, simply doesn't have enough experience with other programming tools yet.

WebAssembly

[Anonymous Coward]

BAM!!

Re:programming practices

[presidenteloco]

Programming practices. Yeah ok.
But people are people, programmers are programmers, and there are bell curves of skill, care and attention, schedule reasonableness under which programs are created.

So let's not assume every programmer writing a potentially security-relevant piece of code is a really good, well educated in best practices, really safe designer and coder with enough time for testing and iteration. Assuming that would be naive.

So why not protect against common errors using the programming language constraints and checks? Most of these protections can be done with very little cost, performance wise or in loss of program expressive power.

We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.

The language stack is sorted out

[drolli]

I consider this the transition to a more stable period. For some time it was unclear how functions would be split between programming languages. All kind of ideas were in the room, with interesting new contenders. Still the programming community decided that the areas covered by Java, Javascript, C, Python are well distributed in the way in which they are and that "good enough is still good".

C# (competitor to C++ and Java in my eyes) seems to be dying. Swift doenst take over from objective C as fast as that one is going down. So for low-level languages nothing else is left. OOP and Data Architectures are firmly in the hand of Java, which has a very small overlap and a very good synergy with C. Python coesists in other areas, and hurts neither of he two languages.

So in some sense: the war is over and java, (C+C++), python, Javascript have won for now.

Re:The language stack is sorted out

[Anonymous Coward]

But what about Rust language?

Oh lord, that again?

[presidenteloco]

Someone who thinks that C is the only performant programming language today?
Someone who's never heard of Go or rust, apparently.

Someone who thinks that more than, say, 10% of programs require "C-like" performance, with today's processors which are about 600,000 times faster than an Apple II, and thinks that both safety and maintenance cost are less important than having C-like performance on programs that don't need it.

Re:Oh lord, that again?

[Travelsonic]

You're not suggesting that we make programs less efficient than possible because we have more resources, are you? IMO, while going nuts is not helpful, we shouldn't use resources inefficiently, or the like, "just because" we have the room - not only that, but not every programming project, career, involves software that has that sort of safety - embedded systems, for instance.

Re:Oh lord, that again?

[Excelcia]

Attitudes like this are why people need a computer 600,000 times faster with 262144 times the memory in order to load something just to check their e-mail. I don't use Rust. I use Go when I must. It's not a bad language as new languages go - Syncthing, a project I've contributed to, uses Go and it's not terrible.

In a way you're correct. I'd agree that only about 10% of software really needs the performance and versatility of C. Most others can get away with C++, for better organization, or some other natively compiled code. Go if you like. Or Pascal if you want something old school but still strongly type checked. I actually use Pascal quite a bit myself, simply because of the free Lazarus environment. Even interpreted stuff has its place, but far less than it is used for. Just as only about 10% of software needs the power and versatility of C, only about 10% of software is appropriate for an interpreted environment. The problem is, kids coming out of school high on what some unfortunate profs (who often don't have to work in the real world) have been feeding them then start all these projects in Python and Java that have no place being written in an interpreted language. Python is good for small front ends. But then someone will want to get fancy and use PyGTK or some other frankenlibrary or else what started as a little front end simply grows beyond what is really appropriate and it becomes non-portable and a nightmare fast.

I actually have nothing against any language. I have serious problems when they are used inappropriately, though, and I have even more serious problems when what has been the best swiss army knife programmers have ever had for the better part of half a century is slagged in favour of some du jour. C never lost its place, and won't for the foreseeable future. For system programming it's not just unparalleled, it's often just simply indispensable. Computers are not people, they are electrical devices with bits and bytes, and sometimes you just need a language that embraces that rather than tries to hide it like its some dirty secret.

Re:Oh lord, that again?

[lucasnate1]

Golang with its ad hoc interfaces, ever changing specs, missing apis, and dynamic typing when generics are needed, may end up introducing just as many security holes as c if it becomes popular.

Re:Oh lord, that again?

[Tough Love]

Someone who thinks that C is the only performant programming language today? Someone who's never heard of Go or rust...

C and c++ (same code generator) kick the tails of go and rust, the former more so.

Re: Oh lord, that again?

[Anonymous Coward]

Golang is not systems programming language, if is more high level, requires elaborate runtime and has GC. You can not write an OS kernel in Golang.

Rust is probably an attempt at better C++ with all this OOP nonsense, it solves a nonissue and old one at that. While it is an OK language probably, it has no chance because or SJW nest that develops it. Ideolology is not compatible with honest intellectual effort. And the sort of incremental improvement overl the old stuff Rust doing is not crazy enough to be of interest.

Re: Oh lord, that again?

[Anonymous Coward]

Well it depends on how do you define and measure efficiency for the society. C is a miracle, it changed the World and it was and us super efficient to achieve engineering results. It was developed by a most talented researchers, in an engineering environment.

If you want to feed the millions of halfliterate coders and their managers and give all the busywork with Object Oriented Java and the likes, Enterprise Technologies like Csharp or VisualBasc then yes, this kind of IT bubble is more efficient for society giving lot of useless work fixing broken technologies all the time.

Re:Oh lord, that again?

[Anonymous Coward]

Seriously, why is pascal not used much anymore? I've started my career on it back in the 90s and I have great memories of it.

It's as simple as python, but better in many ways. Of course I assume it lacks something like pandas/numpy, but still... huge potential lost there IMHO.

Re:Oh lord, that again?

[Anne Thwacks]

Seriously, why is pascal not used much anymore?

Because it is not American.

Re:Oh lord, that again?

[K. S. Kyosuke]

You're not suggesting that we make programs less efficient than possible because we have more resources, are you? ... we shouldn't use resources inefficiently, or the like, "just because" we have the room ...

Funnily enough, that's what many large C++ projects have been doing for the past two decades. At this point, a Lisp reimplementation of Word 1.0 (or pick some other low-enough version number that still has adequate features) is going to be way faster than Word 2017 in C++.

Re:Oh lord, that again?

[angel'o'sphere]

Using more memory or more disk space is not inefficient.
A la contrair: it is nearly always more speed efficient than using less.

The historic reason why people tried to use less memory and less disk space is simple: there was not more available. Bottom line it does not matter at all if you squeeze your smartness to put a data structure and the relevant algorithms into the smallest amount as possible (of memory and disk space) or if you rather use your smartness to develop a maintainable, extendable, scaling, multi threaded/multi session distributed algorithm. If you are smart enough you can do both, but most people for some odd reason believe that programmers focusing on the former are smarter than the ones focusing on the later.

I disagree.

Hint: load a small C program on various *nix systems. Then check how much swap space the tiny program occupies, then ponder why that varies from *nix system to system and then ponder more, why some *nix systems allocate a huge "process space" in the swap space while the program only needs a few megabytes (a few as in significantly below 10MB)

Re:Oh lord, that again?

[serviscope_minor]

C and c++ (same code generator) kick the tails of go and rust, the former more so.

That's not true in the case of Rust.

The Rust code front end is less mature than the C and C++ ones but Rust has almost the exact same set of advantages and disadvantages for optimizaton as C and C++. This is intentional: they all mave more or less the same machine model.

Re:Oh lord, that again?

[angel'o'sphere]

Attitudes like this are why people need a computer 600,000 times faster with 262144 times the memory in order to load something just to check their e-mail. I don't use Rust. I use Go
Uh! You are hardcore!
I use a Mail.app

start all these projects in Python and Java that have no place being written in an interpreted language.
Care to point one out?
For most people doing programming at home Python e.g. is an excellent language.
And as you seem to live under a rock: Java is no longer interpreted, since u .. o ... 1995 or so?

C never lost its place, and won't for the foreseeable future. For system programming it's not just unparalleled, it's often just simply indispensable.
I guess you have a different idea what "system progaming" is than most people. System programming is not done in C since decades. You probably mean the remains of embedded programming where people are forced to use extremely small micro controllers for extremely simple tasks. The biggest "system programming" project that still is mostly done in C (instead of C++) is probably the linux kernel.

Computers are not people, they are electrical devices with bits and bytes, and sometimes you just need a language that embraces that rather than tries to hide it like its some dirty secret.
True. But exaggerated. So I allowed myself to emphasize "sometimes" by making it bold.
The last time I needed some bit fizzling in "Java" was when I wrote a SWEET16 emulator in Groovy. In other words: I work with Java since 1995 ... and more or less exclusively with Java (and other JVM languages) since roughly 2000. In that time I never was part of a commercial project where any line of code I wrote or glanced over needed a bit operation. With Java only having signed types, they are a pain in the ass anyway.

Re:Oh lord, that again?

[Anonymous Coward]

Everything is resource constrained, you just get to pick the resource.
It turns out, for a while now, the most expensive resource on a lot of projects are people. Given the choice of one new programmer who's OK and 10 extra cores, or 1 extra programmer who's good enough to lower run-time (or maintain a lower run-time app), the choice favours the first option in a lot of cases.

As for embedded applications, remember Java was released the same year as the Pentium Pro (1995). How big a difference in performance is there between a cortex a-35 and a PPro 200?

Re:Oh lord, that again?

[TheRaven64]

Add to that, a memory model where data races have undefined behaviour combined with a type system that makes it impossible to check for that aliased-xor-mutable property. Complex Go programs are going to end up with far more subtle and difficult to debug problems than C ones.

Re:Oh lord, that again?

[Bert64]

Why intentionally sacrifice performance? Todays processors may be many thousands of times faster than the early ones, but it doesn't make sense to then slow them down with overweight inefficient code.

Performance and efficiency is still very important, slow code costs money in extra execution time, increased power consumption, increased hardware requirements, especially at large scale. Code which is 10% slower running on a single user's desktop might not make much of a difference, but run that code across thousands of systems or run thousands of instances of it and you've got huge wastage.

Re: Oh lord, that again?

[Anonymous Coward]

First of all, languages are not "written in" other programming languages, but compilers and interpreters are.

Second, GCC and Clang are written in C++, not C. Javac is written in Java.

Re:Oh lord, that again?

[Anonymous Coward]

Interfaces allow interfaces decoupling behaviour and data. Nothing about it is ad hoc per se, but depends on the usage.
Golang spec is a simple webpage, not an unreadable and ever-changing bible like Java. Go1 spec with library and tooling is fixed and Go2 is planned to be backwards compatible.
Who needs APIs when you ned streaming? Your APIs are bloated and overkill for the most part.
Golang is 100% statically typed, even with the functions as first class citizens. Const is "dynamic" at compile-time, but converted to static typing in the executable.
Generics adds complexity where the "Go Way" embraces simple and explicit declarations. They might be added later, but are often a sign of bad design and lack of concern how the code runs.
Golang has bounds-checking, no pointer aritmetic and GC. Nothing is 100% secure, but it's designed to fail predictably (panic) and encourages to handle errors in code (err := return_value()).

Golang is by far the most progressed language for its niche (systems language) and is lightweight and performant while minimalistic and simple to learn. It's worth learning and it's fun!

Re: Oh lord, that again?

[Anonymous Coward]

Looks like you are confusing C with Java. Nothing much extra is allocated for C codes one any OS.

Re:Oh lord, that again?

[Pseudonym]

Seriously, why is pascal not used much anymore?

It kind of is. If you take Modula-3 and give it a curly braces syntax, you essentially get Java 1.0.

Programmers seem to like curly braces because they are visually lighter than Wirth keywords like begin and end; it's the same reason why we seem to prefer Haskell to ML given the choice.

If someone wants to re-engineer Object Pascal with a modern syntax, I would definitely appreciate it.

Re: Oh lord, that again?

[Anonymous Coward]

GCC is written in C. It is compiled in C++ mode these days, but it isn't written in C++ as such.

Re:Oh lord, that again?

[Anonymous Coward]

Neither are PHP, Python and many other popular languages.

Re: Oh lord, that again?

[Anonymous Coward]

People like to argue whether "C/C++" is one language, or they really are two separate languages. You can certainly write a program using both at one time.

For me, it comes down to which features you use. If GCC uses any C++ features (it does) you can't really say it's written in C. You need to be able to understand C++ to make sense of the code.

Re:Oh lord, that again?

[Anonymous Coward]

Maybe because it is? Go look at the Great Computer Language Benchmark game. C absolutely *dominates* all but the closest 2-3 other languages. So, where are you coming from?

Re:Oh lord, that again?

[Excelcia]

Care to point one out?

PyCAM and PiTiVi are two off the top of my head. PyCAM is CPU bound and Python doesn't do its calculations any favours. It's sluggish at the best of times and almost impossible to produce versions that work cross platform. PiTiVi isn't terrible as basically it's just a front end for GStreamer, and as that it's a good use of Python. But it's not cross platform, which defeats half the purpose.

Interestingly, looking at the PiTiVi web site, on the contributing page:

GStreamer Editing Services, the C library on which Pitivi depends to do all the serious work. If you want to work on the backend, this is the way to go.

Which just about sums up Python. Great for quick and dirty little tools, good for a front end, but bad in that most serious front ends require a widget kit that will be problematic for cross-platform, and if you want to do serious work, go to C.

And as you seem to live under a rock: Java is no longer interpreted, since u .. o ... 1995 or so?

Not sure what native compiler you're thinking of. Maybe I do live under a rock. GCJ is gone - GNU is trying to sweep it under the carpet as the bad idea it was, since it never really worked well (read at all). Ok, doing some research I see that there is some product called Escelsior Jet that claims to be a compiler. However, from its web site:

First, the AOT compiler turns your jar and class files into a conventional binary executable. That executable is fully interoperable with our JVM, which includes a JIT compiler to handle any classes that were not precompiled.

So it's not clear if any general purpose Java app can be rendered into 100% native code. It looks like it will do all the pure Java, but how many normally used Java classes this includes is another question. I have never ever heard of Excelsior Jet before, and neither has Wikipedia. It's mentioned in a couple Stack Exchange questions, likely posts from employees at Excelsior Jet in my assessment.

If it is JIT you are speaking of, JIT is not native. JIT is a marketing term for various usually caching optimizations intended to make interpreting bytecode less slow. JIT means different things to different interpreters, but it always involves run-time conversion of bytecode to machine code, which is what interpreting is, and despite what marketing people say, is universally slower than AOT conversion to purely native code.

I guess you have a different idea what "system progaming" is than most people. System programming is not done in C since decades. You probably mean the remains of embedded programming where people are forced to use extremely small micro controllers for extremely simple tasks. The biggest "system programming" project that still is mostly done in C (instead of C++) is probably the linux kernel.

This is just wrong. Windows kernel, plus many device drivers. BSD kernel plus most device drivers (except in MacOS which uses a subset of C++ for device drivers). Linux kernel, as you mention, plus almost all device drivers. Every other Unix kernel and all their device drivers. Virtually the whole OS for most real time OSes. That right there is 99.99% of computing devices on the planet. C is very large on the military scene right now. Most Western navy's combat management systems are more or less entirely C, or use such a stripped down subset of C++ that you might as well call it C anyway (see below). Some colleagues of mine on the aircraft side of things played around with realtime java a bit for avionics, but it didn't really go anywhere.

Some will use C++ for drivers, though in many operating systems that's problematic because of the runtime, so they use it stripped down again. Mayb

Re: Oh lord, that again?

[Wootery]

Are you under the impression this somehow undermines the other programming languages?

C is a pretty good choice of language to write an interpreter in. It's in no way hypocritical that, say, CPython is written in C.

Re: Oh lord, that again?

[K. S. Kyosuke]

They're not, actually. Most decent languages are written in themselves. Occasionally, they throw in a C runtime for convenience, but even that is technically optional.

Re:Oh lord, that again?

[Eluan]

Using more memory or more disk space is not inefficient. A la contrair: it is nearly always more speed efficient than using less.

Cache misses? -Os frequently gives better speed than -O2

Re:Oh lord, that again?

[Luthair]

Not sure what native compiler you're thinking of. Maybe I do live under a rock. GCJ is gone - GNU is trying to sweep it under the carpet as the bad idea it was, since it never really worked well (read at all). Ok, doing some research I see that there is some product called Escelsior Jet that claims to be a compiler. However, from its web site [excelsiorjet.com]:

You're either being obtuse or disingenuous to role Java's bytecode into the same bucket as Python and other interpreted languages. Ditto when you start talking about Java and performance.

Re:Oh lord, that again?

[angel'o'sphere]

Cache misses for what?
Data or code?

Yes, compiler optimizations might have different impacts, I was more thinking in terms of data structures (I believe the parent, too).

Re:Oh lord, that again?

[angel'o'sphere]

Basically all Java JIT compilers compile byte code to native code.
Your idea about C (and not C++) used in kernels, especially the ones you mention, is plain wrong.

Re:pointers

[Anonymous Coward]

Just a headsup. You have a misconfigured browser that is leaking your ip address info.

Re:programming practices

[Anonymous Coward]

> people are people

Maybe if you aimed higher than that, you would be a better C programmer.

Just saying.

C is the king of the progr.languages of systems.

[Anonymous Coward]

After reading the ISO Standard C, I knew their weaknesses and i will try to invent my own programming language as if it was Pascal, Modula-2, Oberon, etc.

As if it is an exercise of building compilers or interpreters.

not go

[nten]

Go is less performant than java. Rust is on par with c++. They have nearly opposite design goals. Use go for server back end services, not kernels or drivers. The rest of your post is spot on. Citation is the benchmark game.

Re: not go

[Anonymous Coward]

what do you mean performant?
makes you think..

Re:not go

[lucasnate1]

How come go is slower than java? It compiles to native code and is more low level (except for channels and goroutines). Do you have any idea how java is faster?

Re:not go

[RightwingNutjob]

Safety checks and transparent abstractions cost cycles and memory accesses.

try{
for(i=0; i<10; i++){ if(i<0 || > a->length){
throw(zOMGEXception);
}
a->data[i] = i; }
catch(){
//The programmer has to state this explicitly or it's a silent runtime error.
//The language feature doesn't relieve you of any responsibility
}

will always be marginally slower than

for(i=0; i<10; i++){
data[i] = i;
}

Re: not go

[Anne Thwacks]

what do you mean performant? makes you sqirm

FTFY

Re:not go

[K. S. Kyosuke]

How come go is slower than java?

It isn't...at least asymptotically. Java doesn't have packed structs so it's going to be perpetually disadvantaged compared to Go in this area as Go's compiler improves.. And memory is way important these days when it comes to performance.

Re:not go

[angel'o'sphere]

There is no reason a driver written in Go is slower than one written in C/C++, and the same is true for kernels.

Re:not go

[angel'o'sphere]

You do know that java byte code is only an interims representation and that the VM compiles the byte code to native code?

Bottom line I would expect Go and Java be equally fast ... however benchmarks are always only measuring niche parts of a language.

Remember when people arguing against C++ claimed that virtual (member) functions where only half as fast as non virtual ones? They did their benchmarks with empty function bodies and and no function arguments. It turned out that the vtable dispatch and call of a virtual function costs about 1.7 the time of a direct call. As soon as you add a few parameters and have a function with a few lines of code, that speed difference drops down to an arbitrary low value close to 1.0.

Re:not go

[K. S. Kyosuke]

Bottom line I would expect Go and Java be equally fast

As I mentioned above, I'd expect Go to be ultimately faster due to more compact storage of stuff. (But on the other hand, pointer-heavy structures could be costlier since fat pointers replace object headers in Go. But on the third hand, a pointer-heavy module such as a graph library is likely to do its own bookkeeping and use integer indices, for example.)

Re:not go

[TheRaven64]

How come go is slower than java? It compiles to native code and is more low level

Compiling to native code isn't always an advantage. For a trivial example, consider a Java and a Go code fragment that calls the same method on objects of the same type in a loop. In the Go version, because of the AOT compilation model, this will always be a function call unless the compiler can statically prove that the object type is always the same for every possible invocation of the program. The Java version will collect profiling information as it runs, determine that the same method is called every time, and inline it with a cheap check. The JIT'd Java version will be faster.

This even happens within the same language. On Android, Java is first JIT'd and then AOT compiled over night. Most of the time, the AOT version is faster because the compiler can spent several minutes of time (and not worry about power consumption because it only does this when the device is plugged in). In some cases, it's slower because the JIT can optimise for what happens most of the time, wheres the AOT compiler most optimise for what can possibly happen.

I'd also dispute the idea that Go is more low-level than Java. Both are garbage collected, both have dynamic dispatch, both have roughly the same set of primitive types and of intraprocedural flow control constructs.

Re:not go

[K. S. Kyosuke]

In the Go version, because of the AOT compilation model, this will always be a function call unless the compiler can statically prove that the object type is always the same for every possible invocation of the program.

On the other hand, my understanding is that Go's methods are (intentionally) sufficiently dumb that they can be called with an indirect jump that can be reasonably predicted by current breed of CPUs (with yet other millions of transistors besides branch predictors helping with parameter passing and faster return stack management - yet another symptom of current post-modern systems wasting transistors on things not actually contributing to computation). Having said that, if some of the method call parameters are constant, a JITting VM can perform partial evaluation after inlining, so that can help sometimes.

Re:not go

[TheRaven64]

On the other hand, my understanding is that Go's methods are (intentionally) sufficiently dumb that they can be called with an indirect jump that can be reasonably predicted by current breed of CPUs

That depends on whether you use an interface or not. If you don't, then it's equivalent to calling a final Java method (you can tell statically what the destination will be). If you do, then (as with Java) it's an indirect jump via a vtable. The problem with method calling is not so much the cost of the jump, it's the cost of call frame setup and of missed optimisation opportunities. For a small method, you may end up doing 2-3 instructions of real work, but 10-15 instructions of setup. Even if the jump is free, you're still paying a big penalty for invoking it at all. You're also missing out on later optimisation opportunities and the ability to do things like interleaving two dependent memory accesses from the method with in-regsiter operations from later or earlier on to help keep pipelines full. These days, the main reason that compilers do inlining is to expose more optimisation opportunities. The same is true of loop unrolling, where modern branch predictors have mostly eliminated the costs of repeated loop iterations (though rename register pressure can still be a problem).

Re:not go

[lucasnate1]

This kind of check is done in both go and java, it still does not explain why go is slower than java.

Re: not go

[Anonymous Coward]

There is no possibility to write drivers in Go at all, because of its threaded , non thread safe , GC based runtime . In this respect Go is more like Java or Python, a high level language. That's why drivers are being written in C, you can do bare metal not depending on any runtime software.

Re:not go

[K. S. Kyosuke]

Well, hence my mention of the extra circuitry in contemporary CPUs to make programs perform closer to the way you're suggesting how hard compilers should work as opposed how the actually do. I'm aware of the optimization-enabling properties of inlining.

Re: not go

[K. S. Kyosuke]

There is no possibility to write drivers in Go at all, because of its threaded , non thread safe , GC based runtime . In this respect Go is more like Java or Python, a high level language.

Actually, in this respect, Go is more like Oberon, and Oberon makes it possible to write both drivers and the GC based runtime in itself. All you need is an "UNSAFE" module with functions provided for low-level manipulation.

Re:not go

[RightwingNutjob]

My memory's fuzzy on the subject, but I believe a large class of array objects in java have their sizes fixed at instantiation allowing the virtual machine to optimize around some of these checks at runtime. Don't really know enough about Go to say anything, but my default guess is that restrictiveness in the language helps performance in these cases.

C is still king, thank Engineering Schools

[Proudrooster]

Everything on planet freaking earth has firmware in it now and guess what compiler makes the smallest binaries that can talk to hardware?

Yes, that's right C.

Python can talk to C, but you aren't going to write firmware or low level interrupt handling code (like reading IR pulses) or monitoring an I2C bus.

Java is C's fat lazy son that lives in the basement and consumes all available resources can do things eventually, if you give him enough resources, time, and be able to tolerate the odor.

As long as computer architecture remains constant, C will be king. It's fast, small, and get's sh*t done now. Plus once you write it in C, you can call it from any other modern programming language like Python, Java, Objective-C, Swift, etc ...

I went to a graduation party of a graduating Aerospace engineer last weekend and his advice was learn C, learn simulation and solving software like Mathematica, learn how to work in teams, and be multidiscipline in career focus for great success. He graduated from Perdue.

Re: C is still king, thank Engineering Schools

[Anonymous Coward]

This only means C is king for that niche.

If you use C to write webapps that access a relational database, you're an idiot. Horses for courses.

Re: C is still king, thank Engineering Schools

[Anonymous Coward]

And Java is still the Queen.

She will help you to write less KLOCs of code in the expense of eating the resources of the machine.

C has not precise garbage collector and Java has it.

Both,C &Java are just married.

Re: C is still king, thank Engineering Schools

[prefec2]

You cannot write device drivers in Java or Python as both languages require either an interpreter alias virtual machine or a just in time compiler. Also they are not the right tool for that particular job. However, they are well suited for other tasks.

Re:C is still king, thank Engineering Schools

[angel'o'sphere]

If you learn Java or C++ you automatically have learned C. Besides the preprocessor and the linker.
And ... cough cough cough. C is not much used in the air space industries, besides what your "Aerospace engineer" thinks.

Re:C is still king, thank Engineering Schools

[Anonymous Coward]

If you learn Java or C++ you automatically have learned C

I knew some of those Java guys and saw their C. Their initial contracts generally expired without renewal and their projects were scheduled for a complete rewrite. There are worlds of difference between these languages and anyone going at C as if they were writing Java or Java as if they were writing C is going to cause a lot of pain.

Re:C is still king, thank Engineering Schools

[Anonymous Coward]

You almost had me fooled until the "Perdue" part. Chickens don't go into (aero)space, silly. And you can't "focus" on "multidiscipline" because they inherently contradict each other. Besides, Purdue University's school of "engineering education" is now waging war on rigorous engineering (because it "demonstrat[es] white male heterosexual privilege", they think we must "relinquish" it), which suggests a degree from there is about as useful as toilet paper.

Re:C is still king, thank Engineering Schools

[Doctor Memory]

If you learn Java or C++ you automatically have learned C.

I can tell that you know nothing about C, and probably not much about Java or C++ as well.

Re:C is still king, thank Engineering Schools

[angel'o'sphere]

And I can tell you: you are an idiot.
Feel free to ask random questions about C, C++ before C++14 and Java. Preferable some you can not google or stackoverflow :P

Hint: I wrote an STL library before there where cross compiler/platform libraries available around 1993-1995 ... if that does not count, you are a moron.

Re:C is still king, thank Engineering Schools

[Kielistic]

You can read C but I would not say you have learned it. Likewise I can usually get the gist of reading Italian because of my knowledge of other Romance languages but I sure as hell do not speak Italian.

Re:C is still king, thank Engineering Schools

[PmanAce]

So you are taking career advice from someone just graduating and starting his career?

Re:C is still king, thank Engineering Schools

[Anonymous Coward]

Exactly, it's about paradigms.

If you start out with the OOP paradigm (or god forbid, functional) you may have difficulty figuring out how to write procedural C well. You'll be vexed left and right by things you can't easily do. It's all about functions and call chains.

OTOH if you learn procedural programming first, adding OOP and functional paradigms is usually not that hard. You learn the "extra" features of C++ and have an "aha!" moment when you realize you can implement an algorithm more cleanly without messing around with pointers and callbacks.

Re:C is still king, thank Engineering Schools

[angel'o'sphere]

I can write C very easily as I have written about 700k lines C++ myself.
Next try?

Sorry, where does that obsession about 'C is so hard' come from? It is a portable assembler, much easier than most languages, there is nothing particular tricky about it.

If you can speak spanish (or sometimes even portuguese) you simply can talk to an italian in spanish and let him talk italian, works most of the time.

Re:C is still king, thank Engineering Schools

[lars_stefan_axelsson]

He graduated from Perdue.

Not sure I would take the word of an aerospace engineer that graduated from Perdue....

how much is it used is almost KLOCs

[superwiz]

The fact that it is searched-for a lot can just as easily indicate that the projects in other languages get completed quicker. That would make it a less useful (and **therefore** more used) language. The fact that more C gets used is about as telling as how many KLOCs of one language (vs another language) gets written. It just substitutes how much time is spent on one language over another for how KLOCs are written. Measuring output of work by the effort put in is always bad measure. It elevates effort over accomplishment.

Don't call Tiobe a reliable metric

[Tough Love]

I'm not saying C did or did not come back, or did or did not go away. I am saying, you won't know from Tiobe, it way too random. They count language questions, not language usage, and don't make the slightest attempt to correct for predictable skew like selection bias due to who hangs out there as opposed to, say, stackoverflow.

My totally on reliable take on it? C dev population stays about the same: very few, very skilled, and very highly paid. Because of the latter, the number of C wannabes spikes from time to time, but don't worry, they will go away after they ask a few questions and still can't code.

Re:Don't call Tiobe a reliable metric

[OrangeTide]

C dev population stays about the same:

Some of us are getting quite old and have been dying off.

Re: Don't call Tiobe a reliable metric

[Anonymous Coward]

Have you been dying off much? I know my beard has gone grey.

Re:Don't call Tiobe a reliable metric

[angel'o'sphere]

C programmers are not highly payed.
Depending on region Java and C# developers are payed highest.
E.g. in London area C# developers with banking/finance experience earn about $1000 per day.
C developers in Europe not even make half of that.
OTOH C# is not very popular in Germany, we mostly do Java here. So you also can earn good money with C# skills in Germany, about $750 a day. (Not popular means: traditionally not many projects were done in C# ... now as those projects exist, the market has a serious demand for C# developers but they are not there)

(And honestly: why would anyone pay a C developer a premium price? C is a super simple language. It does not require particular skills)

Re: Don't call Tiobe a reliable metric

[OrangeTide]

Bits of me have.

Re:Don't call Tiobe a reliable metric

[Tough Love]

C programmers are not highly payed.

They are if they can hack the kernel. And can spell.

Re:Don't call it a comeback, it's been here for ye

[Tough Love]

Back to school.

Re:programming practices

[Pinky's Brain]

So that's where all those C programmers who can avoid buffer overflows went, they ascended.

Shame we are stuck with the rest.

Source for C's comeback

[Anonymous Coward]

#include <stdio.h>
void main()
{
printf( "Infoworld p. lang poll is <em>FAKE NEWS!</em> C still rules!!!\n" );
}

Re:This really only indicates where jobs are now..

[4wdloop]

You are right in general...but wrong here.
This report is not a beauty context or any other comparison of tools but rather statistics of web searches. As such it got reported and misinterpreted as "popularity" as if it was a preference.

Re:This really only indicates where jobs are now..

[DCFusor]

Mod parent up - I posted so I can't use my points. This is correct.

Re: programming practices

[Anonymous Coward]

C buffer overflow aren't really a problem for application programmers. The security issue comes from two distinct things:
1) Poor OS design and isolation of non "admin" processes
2) Lazy/underfunded IT that allow running apps as root.

If your app is messing with mine, the OS/IT level is the problem.

Turbo Pascal

[ka9dgx]

So when is Turbo Pascal coming back? ;-)

Re:Turbo Pascal

[OrangeTide]

Lazarus gets you the Object Pascal derived syntax from Turbo Pascal and Delphi, and provides an IDE available on multiple platforms. I've had zero problems installing it on several systems, mostly for quick and dirty projects where I didn't necessarily want to use C.

Re:Turbo Pascal

[angel'o'sphere]

Well,
joking aside there is a quite complete and portable Pascal: https://www.freepascal.org/

Re:Turbo Pascal

[K. S. Kyosuke]

Wouldn't you prefer, say, the BlackBox Component Builder instead? Way more modern...

Re:Seriously, why name a language "Rust"

[Anonymous Coward]

If you're going to try to market your SJW language to devs who are comfortable working with what's out there now, why in the world would you pick a name that reminds people of grief and decaying cars?

At least Rust never sleeps...

Search index = popularity?

[nitehawk214]

Or maybe it's a reflection that nearly every developer out there knows C to some degree and doesn't have to search for help as much?

Maybe it means there are more older C devs that are more likely to go to a book than Stack overflow?

Either way, it's a garbage metric designed to generate lazy clickbait articles, like this one.

Re: Don't call it a comeback, it's been here for y

[Anonymous Coward]

Mama said knock you out ;)

Re:programming practices

[WaffleMonster]

But people are people, programmers are programmers, and there are bell curves of skill, care and attention, schedule reasonableness under which programs are created.

So let's not assume every programmer writing a potentially security-relevant piece of code is a really good, well educated in best practices, really safe designer and coder with enough time for testing and iteration. Assuming that would be naive.

It would be naive to assume general purpose language selection makes a meaningful difference with regards to security outcomes.

It's up to the architect to manage risk by selecting appropriate tools and methodologies to best address specific problem domain. Placing programmers in an environment that ensures failure by giving them the wrong tool for the job before them or where they are required to always be extra careful in order to avert disaster is extremely counterproductive.

So why not protect against common errors using the programming language constraints and checks? Most of these protections can be done with very little cost, performance wise or in loss of program expressive power.

It is not clear to me specifically what you believe is not being done that can be.

Compile time checks, static analysis, profilers, fuzzers and runtime bounds check code inserted automatically by compilers by default are generally available to programmers at little to no cost. Quite a lot of the old standard C library has over the years been marked as hazardous to your health by modern compilers.

We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.

Obvious solutions to obvious problems already exist. Yet it does not follow obvious problems necessarily have tractable solutions. For example designing a car incapable of ever running anyone over is reasonably beyond current technology even though instances of reasonable measures to mitigate the problem exist.

One thing that has always fascinated me over the years is the lack of sufficient advances in outcomes commensurate with development and selection of new languages. Most instances of productivity gains and capabilities can be traced back to hard won incremental development of complex domain specific systems and hardware improvements rather than advancement of underlying general purpose language.

The fact virtually all system programming is still some flavor of C in my view speaks for the difference between hype, wishful thinking and reality. We've had decades and so far very little of substance to show for it.

Decade ago when processors that could execute java byte code natively were taped out I actually believed this would change. I assumed we would all be running java everything by now and this is from someone who personally never cared for the language.

Re:This really only indicates where jobs are now..

[Anonymous Coward]

I seriously used C for web development (an old intranet system that was written when CGI was a new thing) It wasn't as hard as it may sound, nor did it take much more time to do than if I were to use a javascript framework of the week. it actually it took less effort than when having to deal with js / npm / webpack etc. These days I would use python on the back end if starting a new web project, with just enough front end scripting libs (jquery, bootstrap) to get on with the job, but I'd still prefer to code in C instead of the clusterfuck that is modern javascript

(s & (s - 1)) ^ s

[tepples]

In C or Python, running an unsigned integer through (s & (s - 1)) ^ s will give you only the least significant 1 bit (1, 2, 4, 8, 16, 32, etc.). For 60 (0x3C), it gives 4; for 1280 (0x500), it gives 256 (0x100).

Synthesizing ctz from clz

[tepples]

if your CPU uses clz to count trailing zeroes, you should report that as a bug.

Not necessarily. Use s = (s & (s - 1)) ^ s to clear all 1 bits other than the least significant, giving a "one-hot" integer. Then you can count leading zeroes and use that to infer trailing zeroes. It might look like the following (in a generic pseudo-assembly language):

mov B, A
sub A, 1 // A differs from B in the lowest 1 bit and all bits below it
and A, B // A is B with the lowest 1 bit cleared
xor A, B // A is the lowest 1 bit of B
clz A // A is the number of leading 0 bits
rsb A, 31 // A is the number of trailing 0 bits

Yep...you also forgot bash.

[hackus]

Really you can accomplish everything in C, Java and BASH.

Build and deploy thousands of machines, and you don't have to throw 30 plus years of systems engineering under the bus because some idiot out of college wants to use python.

Re:Yep...you also forgot bash.

[OrangeTide]

bash is some made-up incompatible GNU-ism. You should stick with POSIX standard shell (sh). There are several POSIX compliant implementations and using correct Sh syntax insures your scripts can work in more than a single environment.

Re: Yep...you also forgot bash.

[Anonymous Coward]

That particular "standards" argument doesn't hold weight at this time. The other Unixes are dead, and Linux *is* the de facto Unix now and has been for a number of years. You will have no problem finding bash installed on whatever Unix machine you choose. POSIX hasn't mattered for about 15 years, so why tie yourself to a very crummy and feature devoid language like Bourne Shell? Just on principle?

Re:Yep...you also forgot bash.

[Anonymous Coward]

> Really you can accomplish everything in C, Java and BASH.

Whatnearth do you need Java for..?

Re: Yep...you also forgot bash.

[OrangeTide]

The problem with a de facto standard is that the implementers can break or change it on a whim. A standard like POSIX sh is implemented and supported in bash, zsh, and several other shells. Don't come crying to me if you write a bunch of scripts for your customer's site only to have them break in an upgrade 2 years from now.

Can we kill off Java yet?

[Anonymous Coward]

Can we kill off Java yet?
And Rust?

Please.

Re: This really only indicates where jobs are now.

[Anonymous Coward]

Funny, thatâ(TM)s *exactly* what the GoAhead web server does â" front end is in C and server-side JavaScript!

(GoAhead is one of the most popular embedded web servers, and is in EVERYTHING)

Re:programming practices

[Aighearach]

Maybe we just need better automated testing?

C is easy if you don't try to do anything clever. Let the compiler be clever.

But often there is no testing at all. Maybe in the future everything you compile gets fuzzed.

There is absolutely no reason at all to think it is better to package this into the language, when it can be placed anywhere in the build process.

Re: Seriously, why name a language "Rust"

[Anonymous Coward]

Decaying cars are good for the environment that's why! As long as they are not decaying electric cars butthese cannot be decaying by construction.

Seriously, even another unsafe language like Lua is making more headway into systems programming and embedding than all this Rust .
.

Re:This really only indicates where jobs are now..

[Anonymous Coward]

I can undo a lot of fasteners with a portable band saw, but I can't do all that much cutting with the screwdriver. The former is more fun anyhow.

Re:programming practices

[angel'o'sphere]

In most C projects 80% of the code is for testing.
No idea in what world you live.

Re:programming practices

[angel'o'sphere]

My C career was relatively short.
Programming around 1986/1987 on Apple 2's in Aztec C (which was K&R C, with manuals only in english and I was not that good in english at that time, considering that the vocabulary was centered around computer terms, which we never had in school).
Took me nearly 2 month, probably longer, to realize that the C compiler does no real type checking at all and just compiled down what ever bollocks I had written. (It did not even have "prototypes", you annotated the types after the closing ")" of the function arguments and before the opening '{' of the function body, I have no idea (don't remember) if that was completely ignored or partly taken as a hint)
Then again I started to study CS in 1987 and got immediately a job at the university as half Unix Admin and half C programmer. I basically only wrote one majour C program at that time. A GUI in SUN's OpenView for a Prolog program.
Luckily that was a more advanced but still not ANSI C compiler (the sun compiler obviously, took still 4 or 5 years until most of the institutes switched to GNU C/C++).
Anyway, in school I learned Pascal, at the university I convinced my Tutor that I already can Pascal and that I want to do my assignments in Modula 2 (on Macs).
In private I switched immediately to C++ around 1989, realizing that C always only would be a "portable assembler" I avoided it where ever I could. Unfortunately again (besides Apple's C++ under MPW, the unix shell on Mac OS) I had to used a crippled version of C++ (no MI e.g.) called Think C, later bought by Symantec. Job wise I had shifted from "C programer" to unix admin, meanwhile.
Funnily I rarely ever met a C programmer that was significantly better in C than I was (I am) with my mediocre experience.

If we only had a C++ compiler compiling to the JVM, I probably would still only use C++. So I'm now stuck in the Java/Scala/Groovy corner :D
However the "programming model" in terms of H and Cpp files and linking etc. is quite archaic, and I prefer the concepts of Java, aka everything is a DLL, classpath, class loader real reflection over RTT ... but I miss true MI and true templates and true operator overloading.

Re: C programs are too dangerous for net-connecte

[dunkelfalke]

This reminds me of a joke I heard once about a proctologist who had painted a room through the keyhole.
Many things are possible, but most of them are not practical and frankly shouldn't be done.

Re: C programs are too dangerous for net-connecte

[Dutch Gun]

There are C macros and your can write all you want with them; OOP for example, can be emulated with just structs and pointers.

Except for destructors, which is necessary for RAII, provides a lot of the safety OOP in C++ provides.

Type safety is more or less a fallacy.

Type safety allows your compiler to perform a bunch of error-checking that dynamic types have to catch at runtime. I'm not saying one or the other is better in general, but for mission critical code, I know which one I'd rather have.

Re:This really only indicates where jobs are now..

[TheRaven64]

just as no one is seriously going to try to use Javascript in an embedded microprocessor

I draw your attention to JerryScript, developed by Samsung as a lightweight JavaScript interpreter specifically designed for running in embedded microprocessors.

In a generation used BASIC and 4GLs.. just, no.

[Anonymous Coward]

C will always do the dirty work (like assembly).

It's not easy or human language oriented. Often you must pick, choose and cobble together even the IDE.

It never died. Never came back. It is what it is. Meanwhile my generation got used to RAD tools and visual IDEs. Complete programming solutions with a syntax that works for you - not the other way around.

Re:This really only indicates where jobs are now..

[Anonymous Coward]

No one is seriously going to try to use C for front end web development.

Maybe not C, but how about C++?

C++ for the win

[Anonymous Coward]

C++ does everything C does and has a better compiler. Why embedded devs still go with c is beyond me. I've been working on embedded systems for 20 years and left C in the dust long ago. C is more popular only because of ignorance and myth.

Re: C programs are too dangerous for net-connecte

[Anonymous Coward]

Except for destructors, which is necessary for RAII, provides a lot of the safety OOP in C++

Exactly, the only two features I miss when working in C are destructors being called when a local variable leaves scope and method overloading. I could live without method overloading if there was some way to be strict about data conversions between primitive types (i.e. don't let a method expecting a float take an int) but I do miss the destructors.

That's why I end up using a C++ compiler as a "C with classes" environment.

It never went away you know!

[Anonymous Coward]

Been using C for over 30 years, I program in just about every language that is useful and I find myself using C more so than any other to this very day!
 

Old classic that never leaves top 20

[Anonymous Coward]

See subject & https://www.tiobe.com/tiobe-index/delphi-object-pascal/ & does all majors https://www.embarcadero.com/products/delphi/

Used for APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ - why?

Deals in strings & made sense for performance advantage (Object Pascal's string function library = excellent).

* Delphi SMOKED MSVC++ (former personal fav by DOUBLE++ in math & strings which every program does) in 4/6 tests @ a competing trade journal (VB Programmer's Journal) in 1997 Sept/Oct issue "Inside the VB5 Compiler"

BASIC = 1st language in 82, COBOL 85, & C in 92 (buffer overflows in null-term'ed strings) so I did Delphi (stringlength = 'built-in').

APK

P.S.=> "Old classics" NEVER die - C gains now due to industrial automation & automotive work imo

Typical bloody InfoWorld.

[CRConrad]

Story about new results elsewhere on the Web. Link? Heeeck no! Sheesh... Absolutely nothing has changed in twenty years. (For an example, google "Sandy Reed OS/2")

So Sad

[Anonymous Coward]

Oh god, it in the list of the most popular languages, you have two professional ones, C and C++. All the rest are toys popularized by sub-par, wannabee programmers.

Re: C programs are too dangerous for net-connecte

[Pseudonym]

We see a lot of dynamic languages like Python or Lua and they are ok.

If time-to-market is your most important concern, then dynamic languages seem to do the job. My observation is that one reason why is that in a dynamic language, that fewer bugs have to be fixed before deploying. This is why languages like Python feel more productive than they are.

Languages with lots of static checking won't let you compile, let alone deploy, certain classes of bug, particularly if you wrote your code to use the static analysis rather than to circumvent it.

APK is too retarded to work in C

[Anonymous Coward]

So what you are saying is that Alexander Peter Kowalski is too retarded to work in a language like C.
Also if your work is so great why have you had to write it 10 times now.
It isn't like a file aggregator is hard to create.
If you are claiming that your work is a classic then you are just fooling yourself.
If not then you really need to stop spamming your garbage, proven to be ineffective work.
Actually you just need to stop spamming your garbage work all together.
Finally you really need to learn how to properly express your thoughts in a manner that doesn't look like a dog vomited up a box of Alpha-Bits and then crapped out some punctuation on it.

Old Article?

[Anonymous Coward]

Not sure where they are getting their data, but according to the link to the PYPL, C is only #7 with 6.3%.

Re:programming practices

[rgbatduke]

We can teach drivers not to start the car engine with the car in "drive" because they might run someone over, or we can just design the car not to start except in park.

We can also design cars to be incapable of driving faster than 30 miles per hour, because that is determined (by a committee of "experts", of course) to be the maximum "safe" speed that embraces 99% of all drivers on the road.

We'd all just pay for this safety. Pay in time. Pay in convenience. Pay in no longer having any possibility of "racing" a car or pushing the performance envelope for cars. Pay in no longer permitting anybody, anywhere, to design a car that does NOT have the speed governor built right in, and use all of the other crap that the CoE decided was necessary for even a raging drunk to be safe behind the wheel, including the car-surround baby bumpers and reinforced passenger compartment and feature that won't let the car start without all passengers wearing a kevlar vest and safety helmet.

This is an argument that is as old as time. If you like working with a fascist language that only permits you do allocate memory through an opaque interface that cheerfully trades off speed for an illusion of security, there are many to choose from. C, it is absolutely true, has comparatively few safety nets, although there are tools and techniques for making it as safe as you like. It is also true that it is difficult to write more efficient code than one can write in C short of coding in assembler, and C allows one to inline assembler for those cases where only assembler will let you access certain systems features (instead of waiting until the CoE decide that they are "safe"). Similarly, even good old Fortran has its place if you are doing massive linear algebra and want to optimize it for bleeding edge CPU features.

Could one modify C a lot more minimally, to make it safer than it is by nature while still not enforcing the OO kool-ade and outright prohibiting the use of malloc and pointers? Sure, probably -- some of the tools out there basically do that. But there are times when one can write code with malloc and pointers that is just plain magic compared to what one can get with OO opaque memory management.

Re:programming practices

[rgbatduke]

Enormously well said, sir.

Re:Don't call it a comeback, it's been here for ye

[Anonymous Coward]

What changed?

Presumably the measuring method.

You = classic illiterate retard w/ proof

[Anonymous Coward]

See subject & I note it's 3rd language I learned ~25++ yrs. ago I used professionally too. I have to update false positives filters & TLD/gTLD changes too stupid! If it's "not too hard to create"? Why don't YOU DO BETTER? You can't = why, lol! I said Delphi & Object Pascal = classics (learn to READ moron). Hosts are too & quoted /.ers PROVE IT vs. your bs again, here https://linux.slashdot.org/comments.pl?sid=11578773&cid=55884901/ dumbass & my work = VERY effective + RELEVANT (not your non-existent hot-air, blowhard). You need to quit being an UNIDENTIFIABLE anonymous "jealous jowie" mere "ne'er-do-well" TROLL, fool & YOU NEED TO LEARN TO READ vs. the proof above.

*... & after the above? Your usual vs. me - EAT YOUR WORDS!

APK

P.S.=> U LOSE as you stalk me constantly - & IF you saw my basecode (only Steve Gibson's ASM windows = faster)? I began my program based off Bruce Krell's "HighSpeed Windows Applications" C model (porting it to Pascal FROM C), registering timers w/ the OS manually, hWnd proc & CreateWindowX control creation via API + msg pass receive/dispatch loop to hWnd's in my code? You'd say diff. (if you even understood any of that - doubt it)... apk

Re:programming practices

[Wootery]

C is easy if you don't try to do anything clever.

Not really. It's easy to slip and blow your leg off.

MISRA C (and, I suppose, even Ada) exist precisely because aphorisms like this don't work in practice.

Maybe in the future everything you compile gets fuzzed.

Looking for what? UB? Fuzzing is a testing technique, not a silver bullet.

So APK admits he is a retard

[Anonymous Coward]

So Alexander Peter Kowalski now admits he is a retard.
Your software must be shit if you have to rewrite it to handle TLD/gTLD changes.
Why would I waste my time creating an ineffective security solution that is easily circumvented?
If you used C extensively then writing code that doesn't wander off the end of strings or arrays, and doesn't leak memory should be easy yet you whine and bitch about it like it is hard.
When you bring up quotes from /. users you do realize that a lot of them have been taken out of context, disclaimed, or retracted and people state that so no support there.
You don't have to take my word for it as I have seen you claim someone's quote as valid and they respond back saying they were mistaken, it was taken out of context, or that they were just wrong, and then you go full retard on them.
I also now see that you weren't even smart enough to create your hosts file garbage all on your own but instead copied some other's work, so maybe the Chinese copied Bruce Krell instead of your retard efforts, or even more likely they came up the those obvious simple ideas on their own.
But please continue providing more evidence that you truly are a retard for everyone see.

You = a retard I proved can't read

[Anonymous Coward]

See subject & https://developers.slashdot.org/comments.pl?sid=11578625&cid=55885471/ when I said C = 3rd language I knew as far back as 1992 stupid.

Dimwit gTLD's are continuously being added & when that happens I update my code (I check for that during filtration w/ TONS of other validations for PERFECT hosts interior stupid).

As far as HAVING to handle C strlen functions?

I know how to write it MYSELF (or in array length as strings = character arrays) & I PROVE IT LONG AGO (when Microsoft came to ME, not I to they, for an interview) http://developers.slashdot.org/comments.pl?sid=155172&cid=13007974/ in a +3 UPMODDED POST of mine from what? A decade++ ago or more??

Abpve all else - you STALK me constantly behind UNIDENTIFIABLE anonymous posts - I must have REALLY CRUSHED YOU @ some point that you've gone "PsYcHo" like this, lmao!

(Must kill you I do well in commercially sold code of mine to this day, numerous books/magazines/cd rom distros/newspapers feature me over time, trade contest placement of HIGH ESTEEM etc. for me - & you NEVER can or will - hahahaha!)

APK

P.S.=> Lastly - spout ALL THE BS LIES you want - but anyone can verify people I quote saying what I say they did (praising my work in /.ers OR security/web pros praising hosts as good security) - & anyone disagrees? I can easily shoot their points down (as I do you easily all the time - some 'samples' are just above dimwit loser that you are, lol)... apk

C++ is pretty much a waste - why not use C or Java

[Anonymous Coward]

And I wish javascript had never been invented. Talk about a horrible language, security problem, and number one privacy invader.

Re:This really only indicates where jobs are now..

[CustomSolvers2]

I draw your attention to JerryScript

Curious. Thanks for sharing! In any case, note that this is a C library able to deal with JavaScript code rather than a pure JavaScript autonomous alternative. Although they use C in all the code samples, I guess that there shouldn't be problems with any other C-library-compatible language; but you would have to support the corresponding language environment + the library. By bearing in mind that resource minimisation is a quite important aspect in embedded systems, doing all that doesn't seem like the most optimal alternative.

C-average student

[minstrelmike]

I always thought C was the perfectly average programming language.

Re:This really only indicates where jobs are now..

[TheRaven64]

The C integration is intended to allow you to expose things like device I/O registers to JavaScript, so that you can then give your customers a generic bit of firmware into which they can load their own JavaScript. You need some C for initial setup, but a bunch of their demos spend most of their time in JavaScript. And, honestly, with cheap M-class ARM cores running at 30-100MHz, JavaScript is probably perfectly adequate for performance (I'm a bit sceptical of a language that doesn't have 64-bit integers, but that's a different issue). These processors are over an order of magnitude faster than the Alto on which bytecode-interpreted Smalltalk ran a full GUI and suite of applications and they're doing far simpler tasks. The only real issue is when you need to do something with realtime guarantees (for example, the LED strip outside my office that we use for Christmas lights is needs to have one of the pins set low and high at specific timings to toggle each LED in the strip), but even then there's only a little bit of code that actually has those timings. For the example of that LED strip, I have a single function that writes an array of colour values to the strip (it felt wasteful to allocate almost half a KB to storing the state of the strip, but I was lazy on a device with 32KB of RAM). If I wanted to use JerryScript instead of the existing C++ code that handles all of the transforms on the lights, then I'd just expose a JavaScript object that wrapped the LED strip and had an update() method to write it out to the strip. Nothing else is timing critical (well, except that the script has to finish update roughly every 100ms to manage the colour changes, but 100ms is a lot of cycles).

Re:programming practices

[Aighearach]

C is easy if you don't try to do anything clever.

Not really. It's easy to slip and blow your leg off.

MISRA C (and, I suppose, even Ada) exist precisely because aphorisms like this don't work in practice.

As a firmware programmer using C on a daily basis, I can say that of course you're wrong, because all you did is contradict me and you offered no reason at all to believe what you said, instead of what I said.

Presumably you just don't know.

MISRA C exists for reasons, but it also not a term that embedded C programmers use on a daily basis the way "C99" is. It exists, so what? It is like saying that Agile programming exists; so what? Existing doesn't tell you anything. MISRA C exists, obviously C programmers like extra standards. It is as stupid as saying that C++ exists, so C must have [whatever].

Maybe in the future everything you compile gets fuzzed.

Looking for what? UB? Fuzzing is a testing technique, not a silver bullet.

You're the one who claims you thought somebody was talking about a silver bullet, but only you were. So lets just agree, you were wrong about there being a silver bullet in the discussion.

Re:programming practices

[Anonymous Coward]

Heh. Reminds me of back in the day when I was learning to program the Mac in Pascal. I had a program that drew triangles on the screen.

A co-worker told me if I used C, I could draw directly into the screen buffer and it would be a lot faster.

So I wrote a C version that got the window bounds and translated the pixel coordinates to memory addresses and wrote the pixels directly to memory. Worked like a charm.

Then I got the clever idea to rotate the triangles, so I added a rotation calculation for the 2D points and compiled it. In my haste I forgot to translate the rotation axis to the center of the triangle and rotated some points right out of the screen buffer.

Hit "run"... BLAM! Smoking foot stub. :)

Re:programming practices

[Anonymous Coward]

I was not that good in english at that time

Hate to break it to you, but you aren't exactly Bob Dylan now.

comeback

[NikeHerc]

I'm a C programmer since about 1986. I contend C has been here all along and is still far better than whatever is in second place (or third or whatever).