C Programming Language Hits a 15-Year Low On The TIOBE Index (businessinsider.com)

Gamoid writes: The venerable C programming language hit a 15-year low on the TIOBE Index, perhaps because more mobile- and web-friendly languages like Swift and Go are starting to eat its lunch. "The C programming language has a score of 11.303%, which is its lowest score ever since we started the TIOBE index back in 2001," writes Paul Jansen, manager of TIOBE Index. With that said, C is still the second most popular programming language in the world, behind only Java. Also worth noting as mentioned by Matt Weinberger via Business Insider, "C doesn't currently have a major corporate sponsor; Oracle makes a lot of money from Java; Apple pushes both Swift and Objective-C for building iPhone apps. But no big tech company is getting on stage and pushing C as the future of development. So C's problems could be marketing as much as anything."

Comments

Rust will replace them all

[Anonymous Coward]

Rust will be the new language everyone uses in 2020.

Re:Rust will replace them all

[Anonymous Coward]

Nah.. It'll be jython servlets running inside a lua hypervisor that is written in javascript.

Re:Rust will replace them all

[Dunbal]

with 20 lines of assembly code that a) know one knows how they got there b) no one knows what they do and c) cause the program to crash if they're removed or modified in any way.

Re:Rust will replace them all

[Buchenskjoll]

Yeah, 'cause Rust never sleeps...

Re:Rust will replace them all

[Shortguy881]

And the commit says "improving code coverage"

It's not a popularity contest

[Anonymous Coward]

I don't need a corporate sponsor or a sexy advertising campaign to figure out that if I want something to run on most Linux distributions, as well as the BSDs with minor modifications, C is the obvious choice. Most of the languages being heavily promoted are garbage, that's why companies have to spend money to get anyone to use them. Robust languages don't need a marketing team.

Re:It's not a popularity contest

[Anonymous Coward]

Most of the languages being heavily promoted will be dead 10 years from now. Anything serious and written to stand the test of time is done in C. Everything else is transient.

Re:It's not a popularity contest

[demonlapin]

FORTRAN, COBOL, and Lisp are older than C, and all still around. I'm not a programmer, so take what potshots you will. But they are still there...

Re:It's not a popularity contest

[Dutch Gun]

if I want something to run on most Linux distributions, as well as the BSDs with minor modifications, C is the obvious choice

Well, C++ could make that same claim, as well as many other languages. In fact, some are arguably much *better* at cross-platform functionality.

I think where C shines is that it's sort of a "common denominator" language. Just about every language (C++ included) can make use of a C library, or with minimal effort can create hooks into it, like with C#, Objective-C, Lua, or dozens of other languages that rely on low-level code for lots of their functionality. It's also a reasonably simple language, rather easy to wrap your head around (if written well), and is straightforward to learn, with power enough to get close to the metal when needed. So, if you write some code in C, just about anyone else can use it, even if they have to write a bit of "glue" first.

That makes it a hell of a pragmatic choice for many projects, even considering C's more problematic aspects.

Re:It's not a popularity contest

[K. S. Kyosuke]

Anything serious and written to stand the test of time is done in C.

Such as my Maxima from 1968...oh, wait...

Re:It's not a popularity contest

[Anonymous Coward]

FORTRAN is about the same, only with even fewer pieces of code out there.

LOL. Let me guess: you don't work in high-performance computing, do you?

Re:It's not a popularity contest

[Darinbob]

You mean Macsyma?

Re:It's not a popularity contest

[Dog-Cow]

New code is written in Fortran all the time. I guess you don't work in any place doing numerical analysis more complex than Excel. Talk to a Ford engineer some time. I am sure you'd find the same any large auto manufacturer.

Re:It's not a popularity contest

[TheRaven64]

That's a good reason for providing a C interface, but there's no reason not to use C++ (or Objective-C) inside your library. That said, if you provide a C++ interface that uses smart pointers and conveys explicit ownership semantics, then it's much easier to machine generate interfaces for other languages (even for C) that care about memory management.

Re:It's not a popularity contest

[K. S. Kyosuke]

They fixed the spelling since the 1980s. ;)

Re:It's not a popularity contest

[david_thornley]

That's partly a matter of naming. Modern Fortran, COBOL, and Lisp are not the same as their 1950s equivalents. You're missing ALGOL, among the four 1950s languages that stuck around.

C is an ALGOL derivative in the same way Common Lisp is a Lisp 1.5 derivative, except that C is probably closer to ALGOL than Common Lisp is to Lisp 1.5. What happened is that ALGOL did not become a popular name for a family of languages, and that family flourished.

Re:It's not a popularity contest

[mrchaotica]

The structure you are currently in, if it was large/complicated enough, was probably designed using structural analysis software written in Fortran (at least the BLAS calls in the solver, if not the UI). Even a Matlab, Python or R program is really Fortran once you get to the inner loops.

Re:It's not a popularity contest

[demonlapin]

A fair point. Like I said, I'm not a programmer.

problems, lol

[Anonymous Coward]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems. Such as their code is slow, overweight, wasteful of resources, and uses only a fraction of the potential available at the low level.

But you keep holding that warm, safe hand. Momma will lead you right to the rubber room. :)

Or, you know. You could actually learn how to write good code at the most powerful level. That's a radical thought.

Re:problems, lol

[Pseudonym]

c doesn't have "problems"

Sure it does. As TFS notes, C doesn't have a corporate sponsor. That's why (to pick one example) there is no native compliant C compiler for Windows.

(Yes, you can build Clang if you want to. You know what I meant.)

Re:problems, lol

[ShanghaiBill]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems.

That is actually what TIOBE measures. It counts Google searches. C programmers are smart enough that they don't need to search for answers on Google, or they use a better website, such as Stackoverflow. A high TIOBE index can mean a language is popular, or it can mean that language has dumb programmers.

Re:problems, lol

[ShanghaiBill]

C doesn't have a corporate sponsor.

Why is that a bad thing? Is Java better because Oracle owns it?

Re:problems, lol

[Anonymous Coward]

Programmers use what their boss tells them to use and/or whatever is available/supported for their target platform. Based purely on personal preferences I'm sure we'd all make radically different choices, but that's not how the world works.

Re:problems, lol

[roca]

The reality is that programmers make lots of mistakes, no matter how smart they are, how educated they are, or how hard they try.

Another reality is that even if the really brilliant programmers never made mistakes, there aren't enough of them to create all the software that the world needs.

Fortunately, in the 44 years since C was created, we've learned how to design languages that are easier to use and prevent or detect many of the worst kinds of mistakes. Recently we've even learned how to do that without giving up the power C programmers need.

Re:problems, lol

[rtb61]

All current programming languages have major problems. They are not direct extrapolation of normal language or maths or physics languages. They use sounds like or it'll do based upon the idiosyncrasies of their programmers and they are all quite logically awful beyond their own idiosyncratic internal logic.

We need a new programming language from scratch, properly extrapolated from English, maths and physics and likely a few new custom programming specific characters which should be added to keyboards (much like English, maths and physics all have specific custom characters, not all of them on keyboards, just a few of the most used, sort of). OH yeah ma QWERTY should die in the fires of hell, rather than lazy stupid adults forcing children in the most counter intuitive fashion imaginable to learn it, why force children to pointlessesly learn their QWEs instead of ABCs or change alphabetical order and be done with it, fucking hell, why, just why.

Re:problems, lol

[Just Some Guy]

Or, you know. You could actually learn how to write good code at the most powerful level. That's a radical thought.

I did, and that's why I'm using Python. I'm capable of writing web services in C, but who the hell's got time for that craziness? Also consider Amdahl's Law: in most of stuff I write, the "running code to process data" bit is a teensy portion of wall clock time. Much more is spent in socket handshaking or waiting for database queries to finish. Out of a 50ms request lifecycle, perhaps 1ms is spent inside a box that I have complete control of. Even if I rewrote it in assembler (C is for high-level pansies) to be 1000x faster, the request would still take 49.001ms. An assload of work porting security-sensitive code into an untyped languages so that the end result can be 2% faster? Yeah, no. My boss would fire me with a quickness if I proposed that.

I'd be much more likely to rewrite performance-critical code in Go or Rust. They're as fast as C but without the death of a thousand cuts like gotofail waiting to ruin your careful planning. Life's too short to waste it hacking in languages that hate you and make you want to look incompetent.

Re:problems, lol

[Actually, I do RTFA]

The most valuable resource is my time. I wouldn't use most languages for heavy number crunching (C, or well-written C++), but I wouldn't use C for something that needs to run every night and generate a report. Who cares if it takes 2 seconds as opposed to 1?

Heck, I remember when hand-optimizing the generated asm from a c compiler was a required profession. Of course, optimizing writing code is going to happen really freuently - those who can fix the problem have a strong incentive to do so.

Re:problems, lol

[Pseudonym]

Why is that a bad thing?

You may have missed this, but I gave one example in the very next sentence.

Re:problems, lol

[MightyMartian]

Because no one has ever tried a natural language programming language or alternative keyboard layouts before...

Re: problems, lol

[Anonymous Coward]

Of course Windows has more than one native compliant C compiler. Microsoft doesn't make one but why should anyone care?

Re:problems, lol

[Anonymous Coward]

If your request takes 50ms to process, you're screwed. That's the PYTHON and Perl world that some people live in.

I spent lots of time working on software where 50 us (1/1000th of 50 ms) was considered too long. Think trading protocols. Even real time audio needs to have full processing in less than 20 ms to prevent lip flap. Gaming has similar requirements (FPS gaming, RTS is admittedly a bit more tolerate of latency.)

50 msec is a scalability concern. If it takes you 50 msec to service a request, that means you can only service a maximum of 20 requests per second! (Maybe you can parallelize per core -- but do you want to burn an entire core to get to just 200 ops/sec? Modern transaction systems can process 1 *million* or more transactions per second. Guess what... those are *NOT* written in Python.

Another example -- the entire reason that SSDs are so hot (well almost the entire reason) is that hard disk seek times are too damned slow at about 4ms. (In other words, hard disks peak at around 250 random ops / sec *max theroetical*.) That is *SLOW*. We need to build systems that are faster, that can process data in microseconds, or even hundreds of nanoseconds. (This is what SSDs do.) And the painful seek times of HDDs are still about an order of magnitude faster than the time that you propose is "good enough".

Guess what -- all those systems -- whether your hard disk firmware (or SSD firmware), your device drivers, your kernel, or your filesystem, are all written in a "low level language" (usually C, sometimes, to great misfortune, C++) -- using *SOFTWARE*. Nobody writes that stuff in Python. They'd be fired if they tried!

Tools like Python and Node exist to serve a need to support programmer efficiency over all other considerations. Typically this is for administrative operations where the parallelism is very low, and the performance requirements are almost non-existent. (Is it any wonder that the admin interfaces for the vast majority of products are all steaming piles of crap?)

Python is great for building stuff quickly, and for facilitating "development" by people coming from an IT administration background. Its far less great at building production worthy products -- those ease of use futures like monkey patching, dynamic typing, and an untyped, interpreted language, ultimately cause serious problems for large scale projects. (I've built products in Python. Sadly, I'm pretty sure I have shipped code with Python syntax errors in error handling paths. My C or Go might have been buggy, but at least it friggin' compiled!)

You kids and your fancy damned languages have no idea how the stuff you depend on is really built. But you keep going writing this crappy web sites in NodeJS and Python. Eventually maybe Moore's Law will make your stuff seem to suck a little less. In the meantime, go back to your playgrounds, and let the rest of us get back to building the systems that the rest of the world relies upon.

Re:problems, lol

[Dog-Cow]

That may be bad for Windows (I don't really think so), but how is it bad for C?

Re:problems, lol

[CrashNBrn]

No. We use our books by Dennis Ritchie and Ken Thompson.

Re: problems, lol

[Anonymous Coward]

"Better sites like stackoverflow" - stop, you're killing me! Someone mod parent funny.

Re:problems, lol

[Xest]

TIOBEs index is fundamentally flawed, I've posted here analysing why on numerous occasions and in great detail, and whilst my posts on the topic have always been modded to +5 Slashdot still regularly posts drivel based upon it, and people still seem to debate those stories even though they have exactly no merit whatsoever due to the fact the data behind the story is fundamentally broken.

I still have literally no idea why Slashdot posts stories based on TIOBE, and why anyone bothers to debate those stories as if the premise they're dragging from the index has any merit whatsoever. I can only assume TIOBE pays Slashdot for Slashvertisments at this point.

I'll give TIOBE credit, it has in the last year or so updated it's methodology to be slightly less than worthless rather than just completely worthless, but it's still ultimately just a shade of worthless in it's methodology. It looks like they're now using someone who passed high school statistics, rather than someone that failed it. They really need at absolute minimum a statistics graduate though if their index is to be of any value.

I've long said that if they want to drastically increase the value and worth of their index, then rather than counting how many results they get for "C Language" on YouTube, Amazon, Baidu, and Wikipedia which tells us pretty much nothing about it's usage, that they at least switch to using results from Jobsites, and open source project sites. That way they can start to measure what's actually being used, rather than what a bunch of unrelated search engines are confusing their search for.

Consider this, C++ is a (relatively) old language, but one that has been updated, by searching Amazon for "C++ Language" you may therefore get more books on it than any other language, but that tells us absolutely nothing about how much it's being used, as many people who read the early books may have long retired and the books may be entirely irrelevant now, but Amazon still lists them whilst newer C++ developers are buying the newer books it's possible that usage has stayed relatively static for example - the increase in books does not necessarily correlate to an increase in developers. The same problem rings true in other ways for all their other search results.

By using job sites it may still not tell us anything about retirement, but it does at least tell us the trend. Using open source repositorites can be a good indicator of actual usage, though it misses out the entirety of the corporate closed source world which may or may not use a completely different set of technologies.

So whilst TIOBE currently tells us nothing of value, it could be changed to tell us what companies are hiring for and hence using or intending to use, which is helpful, or it could tell us what open source projects are using, which is useful information as it gives you an idea of what open source developers are choosnig to use even if it's not necessarily representative of the whole market.

Short version: TIOBE needs to change it's methology to be meaningful, or Slashdot needs to stop posting stories based on it that are almost certanily incorrect, or at least aren't verifiable by anything from TIOBE.

Re:problems, lol

[Pseudonym]

Flawed logic. C++ doesn't have a corporate sponsor either, and yet it has a native compiler on Windows.

Multiple vendors pay good money to develop compliant C++ compilers for many of the platforms that we use.

The two main challenges I see for C are the competition with C++ and faster hardware.

Most "C compilers" are actually C++ compilers running in a "C mode". The trouble is that most of the corporate sponsors care more about being compliant with the latest C++ standard than being compliant with the latest C standard.

And because C++ is slightly more typesafe (strict aliasing), those optimizers can do more for C++ code than for C. So despite the more complex language, C++ can be marginally faster (~1%).

Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.

Which gets us to the faster hardware: how often is that performance even needed?

For the vast majority of "embedded" devices that I own, the main performance impact isn't CPU speed, it's battery life. A program which gets its job done as quickly as possible and then puts the CPU into an idle state is far more desirable than one which is perceptually just as responsive but wears down the battery faster.

Re:problems, lol

[lastman71]

Ah! C is for kids, real man program in assembler, becouse optimizer is for lazy people, that waste precious cpu clock cycle.

Obligatory xkcd is obligatory: https://xkcd.com/378/

Re: problems, lol

[loufoque]

Smart people choose their employer based on the project they'd be assigned and the technology they'd work with.

Re:problems, lol

[serviscope_minor]

Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.

Actually...

Aliasing information does help. Modern compilers do auto parallelization at both the fine level (SIMD) and the coarser thread level in some cases. Take, for example the following code:

void foo(A* a, B* b)
{
        for(i=0;i

A and B are the same types, there is nothing that stops the base where a=b+1. If A and B are different types, strict aliasing tells us those arrays never overlap, and so the compiler can use wide SIMD instructions in that loop.

If A and B are the same type, in C (and in practice C++ compilers with a nonstandard extension), you can specify "restrict", which informs the compilers that the arrays don't alias and so it can use the wide SIMD instructions. In that case C is a bit better than standard C++, since C++ has no restrict keyword.

Also, when it comes to exceptions, these days it's basically zero cost (I think it is actually zero cost), provided you don't throw. The compilers make throwing expensive to do that. I believe there's some sort of big look up table plus bisection somewhere so it can figure out the throw-position from the program counter, which is quite expensive. Then it jumps from there to the correct bit of unwind code. The practical effect is that there's nothing exception related in the main code except for a throw.

Re:problems, lol

[donaldm]

Ah! C is for kids, real man program in assembler, becouse optimizer is for lazy people, that waste precious cpu clock cycle.

Obligatory xkcd is obligatory: https://xkcd.com/378/

What do you mean assembler? That's for wimps. Now coding in binary using dip switches that's real programming. :-)

Re:problems, lol

[jandersen]

C doesn't have a corporate sponsor.

Why is that a bad thing? Is Java better because Oracle owns it?

It probably isn't, come to that. C has many obvious advantages - it is easy to learn, it is low-level, so programs tend to be fast, the system calls of most OSes are directly accessible from C. The downside is that because it is so easy to learn, it also invites the inexperienced programmer to commit dangerous errors, that can sometimes be hard to pin down. Many of the better class of new languages try to address these problems, although I am not convinced that the solutions are always worth the cost. The best, new feature, in my view, is the introduction of exception handling in Java, C++, Python and other languages.

It is hard to compare C to Java, I think; although they are syntactically similar, they address different classes of problems. Where C is a free-styling sort of "assembler++" (I mean that in a good way), Java has moved to the other end of the spectrum: the compiled byte-code run in a VM on any platform for which a JVM has been implemented, and Java probably has more industrial standards associated with it than any other language; this makes it rather hard to learn to work with, but it also means that there is well-designed, standard way of doing almost every important thing you might want to do with software, and it makes it much likely that your programs are going to be compatible with other Java programs.

Re:problems, lol

[TheRaven64]

The real problem with C is that WG14 sat on its fingers between 1999 and 2011. C11 gave us:

_Generic - Useful for a few things (mostly tgmath.h, which I've rarely seen used in real code because C's type promotion rules make it very dangerous, but it was quite embarrassing that, for 12 years, the C standard mandated a header that could not be implemented in standard C). Existing compilers have all provided a mechanism for doing the same thing (they had to, or they couldn't implement tgmath.h), but it was rarely used in real code. Oh, and the lack of type promotion in _Generic makes it annoyingly verbose: int won't be silently cast to const int, for example, so if you want to handle both then you need to provide int and const int cases, even though it's always safe to use const int where an int is given as the argument.

_Static_assert - useful, but most people had already implemented a similar macro along the lines of:

#define _Static_assert(x) static int _assert_failed_ ## __COUNTER__ [x ? 1 : -1];

This gives a 1 or -1 element array, depending on whether x is true. If x is true, the array is optimised away, if x is false then you get a compile-time failure. _Static_assert in the compiler gives better error diagnostic, but doesn't actually increase the power of the language.

And then we get on to the big contributions: threads and atomics. The threading APIs were bogged down in politics. Microsoft wanted a thin wrapper over what win32 provided, everyone else a thin wrapper over what pthreads provided. Instead, we got an API based on a small company that no one had ever heard of's library, which contains a clusterfuck of bad design. For example, the timeouts assume that the real-time clock is monotonic. Other threading libraries fixed this in the '90s and provide timeouts expressed relative to a monotonic clock.

The atomics were lifted from a draft version of the C++11 spec (and, amusingly, meant that C11 had to issue errata for things that were fixed in the final version of C++11). They were also not very well thought through. For example, it's completely permitted in C11 to write _Atomic(struct foo) x, for any size of struct foo, but the performance characteristics will be wildly different depending on that size. It's also possible to write _Atomic(double) x, and any operation on x must save and restore the floating point environment (something that no compiler actually does, because hardly anyone fully implements the Fortran-envy parts of even C99).

In contrast, let's look at what WG21 gave us in the same time:

Lambdas. C with the blocks extension (from Apple, supported by clang on all platforms that clang supports now) actually gives us more powerful closures, and even that part of blocks that doesn't require a runtime library (purely downward funargs) would have been a useful addition to C. Closures are really just a little bit of syntactic sugar on a struct with a function pointer as a field, if you ignore the memory management issues (which C++ did, requiring you to use smart pointers if you want them to persist longer than the function in which they're created). C++14 made them even nicer, by allowing auto as a parameter type, so you can use a generic lambda called from within the function to replace small copied and pasted fragments.

Atomics, which were provided by the library and not the language in C++11. Efficient implementations use compiler builtins, but it's entirely possible to implement them with inline assembly (or out-of-line assembly) and they can be implemented entirely in terms of a one-bit lock primitive if required for microcontroller applications, all within the library. They scale down to small targets a lot better than the C versions (which require invasive changes to the compiler if you want to do anything different to conventional implementations).

Threads: Unlike the C11 mess, C++11 threads provide useful high-level abstractions. Threads that can be started fro

Re:problems, lol

[Feral Nerd]

C doesn't have a corporate sponsor.

Why is that a bad thing? Is Java better because Oracle owns it?

It probably isn't, come to that. C has many obvious advantages - it is easy to learn, it is low-level, so programs tend to be fast, the system calls of most OSes are directly accessible from C. The downside is that because it is so easy to learn, it also invites the inexperienced programmer to commit dangerous errors, that can sometimes be hard to pin down. Many of the better class of new languages try to address these problems, although I am not convinced that the solutions are always worth the cost. The best, new feature, in my view, is the introduction of exception handling in Java, C++, Python and other languages.

Exceptions or something like them would be nice to have in C (I'm sure that's not possible for some extremely good technical reason but a guy can dream). However, the thing about C that annoys me the most is the fact that I have two re-invent the wheel all the time, that, introduce libraries to the project or write my own utility libraries. The thing I think C is missing the most is a major extension of it's standard library. C++ for example is full of utility libraries with functions to do small mundane tasks like check strings. Things that can be finished off by one call to a utility function that is part of the standard library in C++ can only be solved in C by either writing several lines of code or including an external dependency that may or may not compile when you move to some other platform and even if it does the behaviour may not be the same. Headaches with different Lex/Yacc implementations spring to mind and even with the same Lex/Yacc implementation behaving differently on, say Linux and AIX or Solaris, the list of headaches connected to external dependencies is long. Also there is a lot of things that can be solved in a single assignment in C++ that can only be done in a much more clunky way in C.

Re:problems, lol

[AmiMoJo]

C is a very compact language, you can learn and remember all of it without a reference guide. Hence there is less need to google stuff.

Re:problems, lol

[tomhath]

Sadly, I'm pretty sure I have shipped code with Python syntax errors in error handling paths. My C or Go might have been buggy, but at least it friggin' compiled!

Your Python program compiled too. If you didn't test every path through the program written in C or python you probably did miss some bugs. Don't blame the language.

Studies consistently show that the number of bugs per thousand lines of code is roughly the same across different languages. For the same functionality, a verbose language like Java will have more bugs than a concise language like Python. Go ahead and write websites in C if you want.

Re:problems, lol

[jrbrtsn]

Exceptions are possible in C. See the documentation for setjmp() and longjmp().

That said, exceptions are just "kicking the can down the road" for error handling. If a function call can fail, then you should check the return code. If you don't want to write with proper error reporting/recovery code immediately, there is always the assert() macro, e.g.:

if(func_which_might_fail() == ERROR_OCCURRED) assert(0);

If assert(0) gets called the program will stop immediately, and you can inspect the problem in detail with a debugger. Easy peasy.

Re: problems, lol

[garethjrowlands]

We have learned a lot since C was invented. Everything has weaknesses including C. Technical problems with C include but are not limited to:

* lack of memory safety and the resulting security issues
* null pointers, Tony Hoare's billion dollar mistake
* lack of import mechanism, and the resultant mess of includes

The main strengths of C are its maturity and ubiquity.

The most obvious competitor to C is Rust. That's currently less mature and less ubiquitous, of course. No tool is perfect.

Re:problems, lol

[mwvdlee]

Pointer math is a problem.
And if pointer math isn't a problem for you; you have a problem.

Seriously though; pretty much any language is nicer to work with than c. c is still here because none of those language can do everything that c can do nor do it quite as well. It's no good having a language that can do 99% of the work better and 1% of the work not at all.

Re:problems, lol

[mwvdlee]

Because WASD would be a bitch to use on alphabetic keyboards.

Re: problems, lol

[Anonymous Coward]

There have been no big changes, other than the introduction of these newer languages. The idea of corporate backing is a red herring. Java is backed by Oracle, but just barely.

(Oracle's plan to make money from Java mostly centers around suing Google. Otherwise, it's clear they have no intention of doing anything interesting with Java. I'm kind of hoping Oracle "OpenOffices" Java and just gives it to some organization like the ASF.)

What you are seeing is entirely natural and should surprise nobody. The dominating cost of producing and maintaining software is in the human programmers who produce and maintain that software.

It's not about low-level versus high-level, bare-metal versus elegant abstractions. It's about that magical word that C-suites love to consider: productivity.

Languages (and environments... that's the real kicker. C would be fine if it has e.g. the rich ecosystem of easily-available libraries that Java does) that allow programmers to solve problems faster are the ones that will get used the most. Write a single-threaded web server? Java: 5 minutes. C: more. There is just more code to write. Yes, you could cheat and use a library (just like Java does!) in C but most people have no clue how to locate that library, build that library, deploy that library, etc. In Java, you just look at the java doc for the standard libra and you are off to the races.

GUIs? Same. Accessing a database? Same.

I'm not saying it can't be done: it certainly can. But it takes more time. And it takes more expensive programmers. Why would most companies pay for that when they can get more bang for their buck elsewhere? The answer is that they won't.

When does C get used? When it has to be used. Operating systems. Real-time devices. Embedded devices (though this is becoming less and less necessary as the difference between what most of us would classify as "embedded" blurs significantly... Raspberry Pis have giga of RAM now... Sheesh). Exotic hardware where talking to the bare metal without any interstitial layers fouling everything up.

Oh, and it also gets used at shops where the existing programmers are C experts and insist that C is the best language for everything. Those companies are probably wasting their money, in general.

C will always have a place, and a good one at that. But it's never going to be dominant again. There are just far more projects out there where another language/environment choice are going to yield faster results, and thus cost less money.

Re: problems, lol

[Tyler Durden]

In many situations (the interesting ones, in my opinion) there is more to the strengths of C than just maturity and ubiquity.

Re:problems, lol

[DrXym]

C/C++ has plenty of problems - buffer overflows, stack overflows, leaks, dangling pointers, etc. etc. It turns out that for many if not most real world applications, stability, development ease, time to market and a bunch of other considerations are far more important than raw speed. This is why higher level languages are so popular. Languages like Java, C#, Ruby, Python and newcomers like Go & Swift.

C/C++ is finding itself relegated to systems programming and certain niches like games where speed is still critical. Even from a systems / performance point of view languages like Rust are increasingly seen as ways to attain greater stability without compromising speed.

Re:problems, lol

[Christian Smith]

Exceptions are possible in C. See the documentation for setjmp() and longjmp().

That said, exceptions are just "kicking the can down the road" for error handling. If a function call can fail, then you should check the return code. If you don't want to write with proper error reporting/recovery code immediately, there is always the assert() macro, e.g.:

if(func_which_might_fail() == ERROR_OCCURRED) assert(0);

If assert(0) gets called the program will stop immediately, and you can inspect the problem in detail with a debugger. Easy peasy.

Urgh, no. Never, ever do this. assert() usually becomes a no-op when compiling stuff without debug flags, so binaries shipped to the field will mysteriously ignore errors in ways that can't be reproduced in a debugger.

One thing that shouldn't change between debug and production code is error detection and handling. In this sense, exceptions are ideal, as handling only needs to happen as and when errors occur, and the common case of no errors incurs little (setjmp/longjmp) to no (exception tables) overhead.

Plus exceptions are less laborious to handle. You can have a single try/catch for a whole block of code, instead of testing and handling each and every function that could fail. If you write exception safe code, then that's all you need to do, and you can clean up failed operations in the exception handlers.

Re:problems, lol

[Christian Smith]

And because C++ is slightly more typesafe (strict aliasing), those optimizers can do more for C++ code than for C. So despite the more complex language, C++ can be marginally faster (~1%).

Probably not even that. In the tiny number of cases where strict aliasing buys you anything at all (which on modern out-of-order hardware it almost never does), it's around the same order of magnitude as the performance that you lose in C++ due to maintaining exception handling information. There's really nothing between C and C++ given the same code these days. In practice, most of the performance gains in C++ come from metaprogramming.

Exception handling in modern C++ compilers incurs no overhead other than a small amount of memory that isn't referenced until the exception is thrown. Search for table driven exception handling.

In fact, exception handling should improve performance in the common case, as you'll be reducing the constant "if (failed) {recover()}" operations employed by regular return code error handling. The non-error code path will be much more linear, with fewer pipeline busting branches.

Re:problems, lol

[jeremyp]

Exceptions are not possible in C for the same reason that they are not possible in Objective-C even though they exist. There is a vast quantity of code in the C world that is not written to be exception safe. So if you throw an exception in your callback that you passed to library, the unwinding of the call stack may cause all kinds of resource leaks and other issues.

Re:problems, lol

[david_thornley]

Anyone who knows C should be able to rattle off some problems.

The operator precedence is screwy. Switch statement case fallthrough is a pitfall. The fact that = is an operator, not part of a statement, makes errors easier. There's a lot of undefined behavior for which no diagnostics are required, and which doesn't look dodgy. The string library is awkward and somewhat inconsistent (check out what strncpy() actually does). Memory management and pointer arithmetic are necessary in far too many contexts. The confusion of byte and character worked only as long as everybody using C used ASCII, and makes things messy with Unicode. Arrays and pointers are sorta the same thing. It doesn't compile well with modern tools.

C is a good language, but anyone who thinks it doesn't have problems is fooling themselves.

Another issue is that C++ is better at everything. It's almost a superset of C, and does a lot more. You can use C++ in a limited fashion to get around most of the problems of C without causing more problems. It's easier to write a C compiler, of course, but there are platforms without good and readily accessible C compilers that use C++ just fine.

Re:problems, lol

[Just Some Guy]

I write web services for remote clients to send information to. 50 msec includes the time to establish a TCP connection to the nginx frontend (written in C!), then to run a little bit of Python code to massage the request and either store it in a database (probably written in C, or maybe Java) or fetch data from one, then to return the results to the remote client. At a previous employer, my code did that about 80,000 times per second, averaged 24/7. At the shop before that, we load tested to 500,000 requests per second but it was only for a few minutes sustained at a time.

When was the last time you personally wrote code to handle 500Kops? Did you know that those durn whippersnappers at Google runs a big chunk of their stack on Python and that they'd laugh at our tiny it doesn't matter to the end user. If we could have reduced a 50ms transaction to 10ms by altering the speed of the light signals carrying our requests, we probably would have. But since we live in a universe with physics, the best we could possible hope for was to reduce the time spent in application code to 0.000ms and thereby drop the entire transaction time to 49ms.

Re:problems, lol

[david_thornley]

C++ makes it easy to avoid buffer overflows, and makes it a lot easier to avoid memory leaks and dangling pointers. I don't know what you mean by "stack overflow" here other than recursive functions, which are present in all modern languages.

C and C++ are two distinct languages, even though C is very close to being a subset of C++. Well-written C and well-written C++ look a lot different.

Re:problems, lol

[DrXym]

I explicitly said C/C+ since both suffer from the same issues. C++ could be argued to offer a superset of the same issues since it increases the number of ways of screwing things up.

Re:problems, lol

[ShanghaiBill]

Urgh, no. Never, ever do this. assert() usually becomes a no-op when compiling stuff without debug flags, so binaries shipped to the field will mysteriously ignore errors in ways that can't be reproduced in a debugger.

Urgh, no. Never do this. Binaries shipped to the field should almost always have assertions left enabled. End users will find ways to trigger errors that you never thought of, and assertions will give you a clear message, usually very close to the cause, with file name and line number. The run time performance hit is usually negligible, and if it isn't then maybe, maybe, remove a few asserts from inner loop hotspots.

When I ship a product, the only thing I change is that in addition to printing to the console, an assertion failure also emails me the error log and stack trace (with the customer's consent). That is enormously valuable in nailing bugs.

Re:problems, lol

[goose-incarnated]

Anyone who knows C should be able to rattle off some problems.

[long list of problems]

You left out "Took the 'const' keyword from C++ and then proceeded to break it." Another niggle of mine with latest standard - stuff that is optional in a compliant compiler.

Re:problems, lol

[flargleblarg]

Binaries shipped to the field should almost always have assertions left enabled.

With assertions enabled, my most speed-critical code runs 2x or 3x slower. No thanks. I'll stick to proper error handling.

(That said, I love assertions and use them liberally in my code.)

Re:problems, lol

[flargleblarg]

for(i=0;i

Slashdot does have a Preview button, you know.

Re:problems, lol

[slickwillie]

In C++ you can overload spaces to . . . well, just about anything you want.

Re:problems, lol

[DrXym]

Yes C and C++ are "distinct" in principle but in practice C++ is basically a superset. There are minor differences in syntax, headers and issues around linkage to but they're so close that one can be considered the superset of the other. Most OSS libraries written in C are directly consumed by C++, their headers and so forth. Most C++ compilers also compile C.

C++ certainly provides various STL classes & templates that reduce the risk of some errors happening but it still requires code to use them correctly. But it's a Catch-22 since if people wrote code correctly then there wouldn't be a risk of errors in the first place... Yet we see how even supposedly mature libraries fall victim to exploits like overflows, not to mention the far more mundane and common issues like I mentioned. Even the most skilled programmers can't avoid errors and in many instances they're errors that another language wouldn't have allowed in the first place.

Re:problems, lol

[Aighearach]

Because no one has ever tried a natural language programming language

They don't know about Perl because it is write-only, just like most natural languages. "That isn't what I said!" "Yes it is, I recorded it." "Well... it isn't what I meant!"

Re:problems, lol

[Aighearach]

Maybe nobody cares about "compliance" with an artificial formal standard, they care about compliance with the standard code that needs compiling.

C++ requires compliance because it introduces a lot of complexity, and most users don't use the whole thing. Different combinations of these complicated features bring about different types of compilation bugs. There is an increased need for standardization.

With plain C, there is a lot more convention, and also things are simply more straightforwards due to dearth of features.

Maybe the people who care about C compiler compliance only care about real-world compliance because there is no corporate sponsor to worry about marketing the language? There could be just as much effort put into making actual use cases work well, just without the formalization.

Re:problems, lol

[serviscope_minor]

Yeah but who has the time to

Re:problems, lol

[Aighearach]

He co-wrote "Roycroft's 5-man chess endgame series," and various non-book things that he wrote are heavily utilized by chess programmers who use C.

Re:problems, lol

[Aighearach]

Exactly. We google libraries, and we don't have to say that it is the C version.

The language isn't the hard part. That the language isn't the hard part also helps create the hard part.

Re:problems, lol

[Aighearach]

The real problem with C is that...

People keep trying to push that, forgetting that people who agreed already switched to C++, or at least are using GCC extensions.

While I don't doubt that there are people who avoided C99 who will love C11, most of the people using C are using C99 and won't be willing to consider adopting whatever was added in `11 until 2020 or later.

I think it is safe to say that the vast majority of people still using C do not want language innovation, they want feature stability.

Re:problems, lol

[ShanghaiBill]

With assertions enabled, my most speed-critical code runs 2x or 3x slower.

That is odd. An assertion should just be the evaluation of a boolean expression. You should use a profiler to identify your hotspots and then figure out a way to move the assertion out of the loop. If you have 1000 assertions in your code, it is silly to disable 998 of them because the other 2 are causing performance issues. I have rarely seen assertions cause more than a 10% performance penalty, and typically even less than that.

I'll stick to proper error handling.

Assertions and exception handling are two completely different things. Exceptions are to identify and handle things like read errors that are expected to happen occasionally, and should be handled gracefully. Assertions are to detect things that should never happen, such as flaws in your program's logic.

Re:problems, lol

[Pseudonym]

Exception handling in modern C++ compilers incurs no overhead other than a small amount of memory that isn't referenced until the exception is thrown.

It also impacts instruction scheduling.

One thing I did originally write (but deleted before posting) was that the performance impact of C's aliasing rules and C++ exception handling is essentially sampling error in practice. I'd go so far as to say that if C's aliasing rules are causing a measurable impact on some part of your code, you may be better off rewriting that code to use assembler intrinsics (or even writing it in assembler), because that will likely win you more than peppering your code with "restrict".

Re:problems, lol

[flargleblarg]

An assertion should just be the evaluation of a boolean expression.

Assertions can be anything you want them to be. There is no (nor should there be) requirement that they be a boolean expression.

Sometimes it is sensible to say assert(foo_is_valid(foo)); on some object foo, and the foo_is_valid() call might need to do a lot of work.

Or... In an arbitrary precision integer arithmetic library, if you compute the quotient and remainder q and r of a divided by b, it is sensible right before returning to assert that b times q plus r equals a, which obviously incurs a significant speed penalty and should not be part of the production code if the math library needs to be as performant as possible.

I write assertions to document state and to help catch errors. I don't care how fast or slow they run. They are meant to be compiled out.

Re:problems, lol

[rtb61]

Problem is, it needs to be an open multi-national research project, free of patent or copyright encumbrances and then continue to be developed upon that basis, greed means it won't happen for decades of chaos of multiple language, growing dying, growing dying, but hey, greed. It will happen eventually but only after the current run of greed obsessed freaks are gone.

Re:problems, lol

[TheRaven64]

That's fine, if the goal for the language is to whither. 10 years ago, I'd have recommended learning C and giving C++ a wide berth. I started new projects written in C. Now I'd recommend avoiding C for anything where there is another option. If a project is already written in C, I'd consider using C++ for new code and gradually migrating rest.

If the goal is to provide a good portable systems programming language then C is no longer succeeding.

Re:problems, lol

[david_thornley]

There's at least two definitions of well-written code. One is code written that is clear and error-free, and we REALLY can't count on this. Another is code that is written according to a coding standard that can be easily verified in a code review.

To give an example, consider array overflow. In C++, we can have a standard that forbids C-type arrays and strings in favor of safer C++ template container classes. Checking to see if array overflow can occur in C is a equivalent to the halting problem, but checking to see that C-type arrays and strings are not used except to initialize std::vector etc. and in external API calls is easy. Similarly, a requirement that object ownership be handled with C++ smart pointers, and that raw pointers never own anything, is easy to enforce and avoids most memory management issues. This isn't as good as standard garbage collection for handling memory, but is better for other resource management. These classes are not typically more onerous than the C equivalents, although std::weak_ptr does require extra handling.

It's still possible to effectively leak memory in garbage-collected languages, by leaving an obscure and unknown but theoretically reachable reference. It's certainly possible to leak database connections and other resources that tend to be more critical than memory. C++ has advantages and disadvantages in safety here.

Re:problems, lol

[david_thornley]

When you're shipping, you want to have messages friendly to the user, which unmodified assert() tends not to be. Lots of these programs don't use stdin/stdout for user I/O.

Re:problems, lol

[lsatenstein]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems. Such as their code is slow, overweight, wasteful of resources, and uses only a fraction of the potential available at the low level.

But you keep holding that warm, safe hand. Momma will lead you right to the rubber room. :)

Or, you know. You could actually learn how to write good code at the most powerful level. That's a radical thought.

I'm a C programmer, and frankly, not every problem requires C as a solution. Programs that are one-shots, or used infrequently do not have to be developed in C. But when you want to minimize program size, or the code requires performance, C is way to go. I also enjoy what performance (in size and speed) that I can produce with C. I do occasionally use C++. C++ compiler developers have recognized this fact, and include some C language functions to allow C++ to become used more often, when the alternative is C.

Re:problems, lol

[david_thornley]

A program that can be compiled with a C compiler is usually lousy C++. Ensuring that a C program is valid C++ is typically pointless and can introduce some infelicities. (The one that's coming to mind: double * double_array = malloc(30 * sizeof(double)); is valid C, but C++ requires the cast to double *. This adds verbiage, doesn't help the program, is another thing to potentially get wrong, and masks problems if the appropriate system header file isn't included.)

Decide which language you're going to write in, and write your program. I'd recommend C++ for most things, but C isn't a bad language itself.

Re:problems, lol

[david_thornley]

These issues are the same in C++ only if you have crappy and/or ancient C++ code. Only a bad programmer would find C++ merely a source of new ways to screw up bad code.

Tell me, if a car had a switch selecting front-wheel drive and all-wheel drive, would you consider that a safety problem because it's something I might get wrong?

Re:problems, lol

[DrXym]

No, C++ offers new and exciting ways to totally screw things up, e.g. calling delete instead of delete[] on array, or calling delete on a base class where the destructor isn't virtual, or overloading new but not delete. Or calling a dangling pointer to a base class yields mysterious unimplemented method errors in some compilers. Since C++ barely ever deprecates anything of note (trigraphs and other minor stuff being the sum total), it means the issues compound with each release. C++ has all the ways to screw up found in C, the C API and adds plenty of its own.

And it's no use to say "only a bad programmer", because the reality is that programmers run the spectrum of skills and even the "good" programmers only become so from learning from mistakes. Mistakes that can be very costly to discover. That's reality. And even if a programmer is "good", it does not mean perfect.

Other languages from Java, Ruby, Swift, Go, Rust are all gaining popularity precisely because they stop all kinds of dumb errors that C or C++ blissfully allow through. The later a bug is found the more costly it is to fix. Stopping bugs from happening in the first place is the cheapest remedy of them all.

Re:problems, lol

[david_thornley]

Get yourself a halfway reasonable C++ coding standard that can be enforced easily, and you eliminate most or all of the problems you're talking about. I haven't found a language I can't write screwed-up code in if I want to, so I'm not real interested when you talk about deliberately abusing languages. I've written bugs in every language I've tried seriously, so the question is not whether I can write bugs but how likely I am to write bugs. With modern C++, the likelihood is no greater than in other languages.

I've been working in this place for nearly nine years now, and we haven't done any of the things you suggest as ways to screw up. It's been much longer since I've written a delete statement, because there are easy ways to avoid the necessity now.

Re:problems, lol

[david_thornley]

Of course C++ is a close descendant of C (and Simula 67, for that matter). However, it is a distinct language, and I will advise very different things for writing in C++ than I will for writing in C.

Re:problems, lol

[Aighearach]

It already exists as a useful tool, why does it even need to have a "goal?"

Re:problems, lol

[TheRaven64]

If a language doesn't intend to change, then that's fine: disband WG14, declare C11 the final version, and let the language die a slow death. If WG14 is going to keep refining the language, then it must do so with a goal in mind (it is doing, by the way).

Computers change and applications change and therefore so do the changes in requirements for programming languages. C was a fine systems programming language (well, okay, it was a not-terrible one) when you wanted an abstract machine that was basically a PDP-11. Even modern microcontrollers don't really look like a PDP-11 anymore though, so the utility of C is diminishing.

Re:problems, lol

[TheRaven64]

Speaking as someone who maintains a C compiler for a slightly less conventional architecture, that's far from all that it does. For example:

It assumes that pointers are strongly ordered, which implies that either pointers do not carry bounds information or that the bounds information never changes (for example, during a realloc).

There's no requirement that your computer have registers, but you're write about the assumption that instructions are executed in sequence. Until C11, there was no notion of parallel execution in C (yes, it was decades after SMP existed and years after multicore became mainstream that C even provided a way of implementing a mutex without relying on assembly). Volatile only gave ordering guarantees (and not liveness guarantees - there's no guarantee that a write to a volatile variable in one thread will ever be seen by a read in another thread) for a single address.

The language as defined by the standard doesn't assume that pointers can be manipulated as integers. It makes intptr_t optional and if it's present the only guarantee that's required is that storing a void* in an intptr_t and then casting it back to a void* gives you the original value. An implementation that only supports this will break all real-world C code, however, and the de-facto standard requires that you support arbitrary pointer arithmetic on pointers stored as integers.

Similarly, the C standard doesn't permit ordered pointer comparisons between pointers to different objects, but almost all real-world code depends on it (all of the common implementations of trees and hash tables do pointer compares between different objects). This strongly implies a flat linear address space and maps very poorly to modern NUMA systems or even to protection domains on a typical embedded core's MCU.

If you want to understand more, read our recent PLDI paper Into the Depths of C: Elaborating the De Facto Standards. C is neither a good fit for modern architectures, not a good fit for modern program requirements (for example, it assumes that an address space contains a single security domain).

But more importantly...

[Anonymous Coward]

... C is running a hell of a lot more important applications, is the driving force behind nearly every operating system, and is undeniably the most used programming language in the history of life as we know it.

But, y'know, numbers, I suppose.

The fewer C programmers there are

[Anonymous Coward]

The more I can charge.

So what!

[no-body]

C is great - love it and if somebody shits on it, even more so!

Moronic Subject for an Article

[hoofie]

This really is a moronic article. Programming language choice is not about "popular" or "cool" - it's whatever tool gets the job done. The article also takes a whack at COBOL and Fortran. They might be old but they have been around a long time and are still in heavy use in many areas. The article also ignores things like microcontrollers, arduinos etc whose development tooling invariably uses C. The whole thing reads like it was written by a newly minted graduate.

Re:Moronic Subject for an Article

[David Greene]

Yep. Most people don't know about the semantic advantages Fortran has over C or that its syntax allows for compact expression of complex calculations. C is no more a Fortran replacement than Fortran is a C replacement.

Re:Moronic Subject for an Article

[lgw]

This really is a moronic article. Programming language choice is not about "popular" or "cool" - it's whatever tool gets the job done.

For a hobby? Sure. Otherwise it's about whatever tool gets the paycheck done. Java sucks today and isn't the best tool for any job, yet it dominates the job market. It was a bad tool 15 years ago, and it will be a bad tool 15 years from now, when it will still dominate the job market. And by then, sadly, $10 computers will run Java easily.

C will always be the kernel guy's tool, and those jobs pay nicely, but there will never be very many of them. C++ has faded (despite being a darn good language with the latest standard, too many burned bridges). C# will go down with the Microsoft ship. Will one of the new fad languages have staying power? Maybe. Likely 1 of them will, if not a current one. But fucking Java just refuses to die.

Re:Moronic Subject for an Article

[roca]

Java is the new COBOL. Given we need a language for that role, I actually think Java's pretty good.

Re:Moronic Subject for an Article

[techno-vampire]

As far as I know, JPL is still using a program written in the late '70s or early '80s by Dan Alderson in FORTRAN for spacecraft navigation and maneuvering. The language it was written in may not be popular now, but the program Just Works, so there's no reason to re-invent that particular wheel.

Re:Moronic Subject for an Article

[0100010001010011]

BLAS and LINPACK are used everywhere in Engineering tools. Numpy, Scipy, Matlab, Mathematica, et al are all just pretty wrappers on top of the FORTRAN that does the heavy lifting. It's why compiling from source also requires a Fortran compiler.

They've been vetted, tested, vetted more, and been running Engineering applications since the 70s.

Re:Moronic Subject for an Article

[lgw]

FortyCharacterCobolNamesLikeThisForExample and all.

Re:Moronic Subject for an Article

[WaffleMonster]

2 decades and continued growth demonstrate languages like Java and Javascript do indeed have that. What precisely is it about Java that you're having so much difficulty with?

What I have difficulty with is understanding what software of any significance in my life is actually written in Java. The last time I installed from scratch didn't even bother installing a java runtime. Didn't see the point.

People keep talking about how these languages are so great and so much better yet the one thing that has always been missing was the translation of that fanboyism into anything useful.

Where are the operating systems and non-trivial games and browsers and codecs and network stacks and relational databases and shit written in these languages? Where are the outcomes commensurate with the claims? Isn't "two decades of continued growth" ... long enough?

Re:Moronic Subject for an Article

[Anonymous Coward]

A lot of indispensable mobile apps. Or did you miss that particular change in usage from general purpose PC's to mostly mobile devices?

Re:Moronic Subject for an Article

[Darinbob]

If C doesn't have it's own Facebook page, then how can Kanye give it his blessing?

Re:Moronic Subject for an Article

[Darinbob]

Smart cards with JCOP running Java on top of an 8051, existing today. Slow as hell though.

Re:Moronic Subject for an Article

[Anne Thwacks]

Java is the new COBOL

So your CFO and auditor can read it?

I don't think you understand the point of COBOL, which is "while it is very long-winded and a struggle to write, it is possible for lay people to read, and (at least the evidence suggests) maintain 50 year old code after the original author has died".

If you write COBOL, you probably spend two days reading the background info and requirements docs for every ten minutes you spend writing code anyway.

Good luck getting an accountant to understand 50 year old Java.

Re:Moronic Subject for an Article

[roca]

I believe a significant number of server-side components at Google and Facebook, among others, use Java. That probably is significant to your life.

Re:Moronic Subject for an Article

[TheRaven64]

Java isn't a bad language. It's a constrained language, but in general it's constrained in a good way. It may make it difficult to write the best solution, but it makes it impossible to write the ten worst solutions and easiest to write a not-too-bad solution to any given problem. It also strongly encourages modularity and provides tools for reducing privilege for parts of a program so that you don't need to trust all programmers in your address space equally. It's certainly not the best tool for all jobs, but if you have a complex business application that you want to support for a long time with relatively high programmer turnover, it's far from the worst tool.

Re:Moronic Subject for an Article

[c10]

I haven't seen much COBOL with mixed-case variable names. Funnier with all uppercase and hyphens.

Re:Moronic Subject for an Article

[Xest]

"What I have difficulty with is understanding what software of any significance in my life is actually written in Java."

Well if you've never used Amazon, eBay, Google, most Android apps, Minecraft, or used just about any bank, made any transaction via Visa/Mastercard, been served in a shop at a till point, or made an appointment and had your records tracked at a hospital or doctors, then I can understand why you'd think Java is irrelevant. I suspect most people have used those things, and as such, have used Java, even if indirectly.

Java is everywhere running so many key systems, you just don't see it, and that's because it's great at doing what it's supposed to do on large back end systems.

If you use Windows and just use desktop software, then yes, you're probably unlikely to see much other than C, C++, and .NET stuff (i.e. usually C#).

Re:Moronic Subject for an Article

[Lawrence_Bird]

And people forget what COBOL means - common business oriented language. COBOL is all about data in and data/reports out. It is not about pretty, new shiny.

Re:Moronic Subject for an Article

[Cro Magnon]

Java is the new COBOL

So your CFO and auditor can read it?

I don't think you understand the point of COBOL, which is "while it is very long-winded and a struggle to write, it is possible for lay people to read, and (at least the evidence suggests) maintain 50 year old code after the original author has died".

If you write COBOL, you probably spend two days reading the background info and requirements docs for every ten minutes you spend writing code anyway.

Good luck getting an accountant to understand 50 year old Java.

That's true, in theory. I've also seen COBOL code that's nearly as unreadable as the worst Perl crap I've seen, and I'm pretty sure the reason the original author died is suicide after the boss wanted him to make changes to the damn thing.

Re:Moronic Subject for an Article

[david_thornley]

The idea behind COBOL was code that even a manager could read, comprehend, and change. It didn't work. The CFO and auditor, unless they've studied programming, will not understand the COBOL code sufficiently to audit it.

Re:Moronic Subject for an Article

[lgw]

CONSTANTS_IN_JAVA_STILL_LOOK_LIKE_THIS in many shops. C'mon, if there's one thing Java can do better than Cobol, it's end the shouting.

Re:Moronic Subject for an Article

[lgw]

I wouldn't hold my breath on MS going away, but it really seems to be on the "Novell arc" now. It could go for a decade or more on its existing customer base (many of which will move to Azure, so revenue will keep going up), but that's different from getting new customers.

Startups tend to do everything in the cloud these days, and not with expensive MS products. Mac is taking over the end-user workplace where it's not already entrenched MS. I'm not sure what could drive new MS enterprise customer acquisition in the years to come.

Re:Moronic Subject for an Article

[david_thornley]

IBM has a pretty solid lock on the mainframe market nowadays, so in a sense they're in better shape than when they had Amdahl and Itel as competitors. Microsoft is going to keep a similar grip on the desktop/laptop market for a long time to come. Microsoft is showing no signs of being able to compete in the general phone/tablet market, despite screwing their main customer base over in order to try. Microsoft isn't going to go away in my lifetime, but it will become increasingly irrelevant for most people.

C's problem?

[ugen]

C has what problem? Lack of social media popularity with hipster morons? It's a programming language, not a popularity contest. This kind of shit lately on slashdot really starts getting old. Who runs this place?

Re:C's problem?

[Anonymous Coward]

To some extent it IS a popularity contest. C is no longer taught in many universities so the next gen of programmers won't have any experience with it, which means they'll avoid it for doing projects in their careers. Languages CAN die. Well, not 100% - there are weird things still in use - but in practice they can, if their user base becomes too small. C isn't close to that point at the current time. But if the vector is the wrong way, that isn't a good sign at all.

Re:C's problem?

[someone1234]

Actually, there is some connection. These computers generate lots of heat :D

Re: C's problem?

[garethjrowlands]

C does have technical problems including lack of memory safety and null pointers. The state of the art has moved on.

Not that TIOBE has anything to do with that. But if you think C's only problems are PR, think again.

End of coding

[OrangeTide]

Us C programmers have already written everything there is to write.

Feel free to reinvent the wheel in various toy languages if that is what makes you happy, I soon will retire and won't care.

Consider the methodology

[GrumpySteen]

Basically the calculation comes down to counting hits for the search query "language programming"

It doesn't matter if those results are positive or negative. All that matters is the number. If you make a language and get ten billion people to post on indexed sites about how badly your language sucks, your language would take the top spot on the TIOBE Index.

So... yeah. This is about as lame of an index as you could possibly come up with.

Re:Consider the methodology

[locopuyo]

And I doubt it is very accurate. When people talk about frameworks they often don't even mention the language. Javascript are dominated by frameworks and probably extremely underrepresented using that methodology. At the last conference nearly half the sessions had to do with javascript and there were only a couple C sessions.

Re:Consider the methodology

[TechnoJoe]

To expand on your point, there's no measure of the quality of the project for which the language is being used. For example, I would give far more weight to languages used by projects like Apache, nginx, Sendmail, procmail, postgresql, operating systems and device drivers.

How many people would be impacted if the project went away? If a lot, then give the project and its language more weight.

Given that, I would think one or two dozen C and C++ projects could squash 1,000 Java, Python, PHP, and Javascript projects combined.

Re:Rust is going to eat C's lunch

[OrangeTide]

Why will Rust succeed where D has failed? Why not Go, Nim(rod), Scala, or Haxe?
(I think I already know why not Erlang, Haskell, or OCaml)

PS - omitting of python, ruby, js, and groovy is intentional

Yeah, it sucks, but, then, C not an easy language

[kriston]

Yeah, it sucks, but, then, C not an easy programming environment.

Pointer arithmetic aside, I remember the days when you had to run a preprocessor to be able have a C program to query a database. As bad as the code we wrote had looked for consumption by the preprocessor, the code coming out the other end of it was barely readable and nearly impossible to debug and profile.

So we had to write stubs that return baked database data structures during development to keep our sanity and be able to even debug the thing. We'd defer the embedded SQL part until later in the implementation phase, and that mess introduces problems of its own, like stack overflows, buffer overruns, and mutual exclusion deadlocks (along with other multi-threaded problems which are another can of worms).

It was a cold, wet, hairy ball of pain and panic that I'm glad to see has gone away.

C++ is kind of better, Java and C# are simply amazing, and the newest scripting languages (am I still allowed to call them that?) are just phenomenal.

C is useful

[hcs_$reboot]

Not everything needs to be written in C, of course. But being fluent in C before starting other projects in less demanding languages (memory management, pointers, ....) like Java offers some guarantees regarding the developer competences.

We have K&R on PDF

[perpenso]

From TFS, "c's problems": c doesn't have "problems"; programmers who don't use c have problems.

That is actually what TIOBE measures. It counts Google searches. C programmers are smart enough that they don't need to search for answers on Google, or they use a better website, such as Stackoverflow.

We use neither google nor stack overflow, we have K&R on PDF.

Re:We have K&R on PDF

[MightyMartian]

Even if you did, it strikes me that this is an absurd metric. Since a lot of C development goes on within communities; either closed source shops, or open source projects, where it's likely only a portion of the mailing list archives, if any of them at all, are archived. The majority of the BSD and Linux kernels are written in C, along with a significant percentage of the toolsets, so clearly there's one helluva lot of C coding going on. Whether search engines index that activity or not is irrelevant.

A better metric, though not perfect, would be to look at the activity in places like Git, to see how many lines of code roughly are in any given language.

Re:We have K&R on PDF

[Anonymous Coward]

You know there is an ANSI edition of K&R, right?

Its really the library not the language

[perpenso]

Java is the new COBOL. Given we need a language for that role, I actually think Java's pretty good.

As one of my professors once argued, its usually the accompanying libraries that make or break a language in more recent years. Java's advantage is simply a "more capable" "standard library".

Also we went recently through a phase in computer science education where people were really only taught java. Its the only tool in their toolbox.

Re:Its really the library not the language

[ShakaUVM]

> Also we went recently through a phase in computer science education where people were really only taught java. Its the only tool in their toolbox.

Yep. I went through the curriculum of the top 10 computer science universities in the country, and all of them teach either Java or Python in their introductory programming classes.

Only a single one (Stanford) even offered C++ as an alternative.

Which is why I'm working on a tool that will hopefully make C++ more appealing to educators, by replacing the traditionally horrendous error messages with an easy to read paragraph targeted at newbie programmers. I'll be presenting it at CppCon next month.

Re:Its really the library not the language

[Darinbob]

Just make your own library. If the language won't let you make a suitable run time library from scratch then it's deficient.

Re:Its really the library not the language

[Anne Thwacks]

In the days before Cray started his own company, CDC computers used to run one Fortran compiler for debugging (cos you could understand the error messages) and another to produce the working code (cos it ran massive faster).

Re:Its really the library not the language

[mrchaotica]

Yep. I went through the curriculum of the top 10 computer science universities in the country, and all of them teach either Java or Python in their introductory programming classes. Only a single one (Stanford) even offered C++ as an alternative.

That's not a problem. The problem is with shitty schools that don't have a non-garbage-collected language required for a class anywhere in their mandatory curriculum. At my alma mater (which is one of the top-10), the required C-based class is sophomore-level and that's fine.

Re:Its really the library not the language

[dcollins]

Today's winner of the "missed the whole point" award.

Re:Its really the library not the language

[david_thornley]

My son did his college CS coursework mostly in Java and C, which strikes me as a reasonable mix. I really don't want someone graduating with a CS degree who hasn't been shown to be able to handle a relatively low-level language like C.

A C dialog box and a FORTRAN computation ...

[perpenso]

Old FORTRAN code lives on behind the GUI or web interface. I once ported some old mainframe computational chemistry code for a very large international corporation. They wanted their legacy code moved from mainframes to MS Windows. At startup their legacy FORTAN code interactively queried for six parameters. I created a Windows front end in C that had a dialog box with six entry fields. After the user pressed the OK button and the six parameters passed verification in the C code they were plugged into the expected input variables in the legacy FORTRAN code and the computation went on its merry way.

Except for the interactive queries the FORTRAN code needed zero modifications. The port needed a few days, most of that testing before handing it off to the chemists. From their perspective it was just a native windows app.

Yeah, if it just works why re-invent.

Re:A C dialog box and a FORTRAN computation ...

[Lawrence_Bird]

Having something that 'just works' is not really the prime consideration. Any rewrite has the potential to introduce unknown errors - whether from language constructs, compilation or hitting some odd use case not reached before. Older Fortran (it like that now) and COBOL are extremely well understood programs. The risk/reward of replacement in the new shiny is just not there.

Also, most people (read those not using it) don't know that Fortran has progressed from FOTRAN IV or 77. The current Fortran has just about all the modern language features (if not more) that you could want.

So I guess I should bump my rates up?

[shess]

It's not like C is going away anytime soon, but if there are fewer new C programmers coming online, maybe I don't have to worry about being put out to pasture?

TIOBE

[l3v1]

"The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system."

While I think TIOBE is interesting, I'd never advise anyone to either take it too seriously, or base any of the above quoted decisions on it. Deciding on used languages based on search engine results - if you do that, I'd bet you don't advertise it during your interviews.

Re:TIOBE

[OrangeTide]

No, you're wrong. We should base all of our business decisions on the whims of the Internet.

Re:Yeah, it sucks, but, then, C not an easy langua

[Anonymous Coward]

The problem is not C's fault.

Some macro packages are indeed horrid. That's not C's fault. Its absolutely possible to beautiful APIs in C. The UNIX file descriptor API is probably one of the first examples of object oriented programming and polymorphism, yet nobody ever gives it credit.

You do have to be able to manage pointers and memory in C, and if you use threads you have to be able to deal with currency. This is not rocket science, but it requires diligence.

I am particularly fond of Golang's C "flavor", while freeing the programmer from worrying about those things. If you have to solve a problem that Python or Perl would be your tool of choice for, I'd reach for Go instead.

If you have to be in a kernel, or performance critical code, then C is your choice.

And if you think your code isn't performance critical, you should double check your assumptions. Outside of administrative UIs, almost all code (IMO) is performance sensitive and critical. Programmer inability to understand this is responsible for a lot of the carelessness and bloat that has resulted in UIs that struggle to run in gigabytes of memory, when we had perfectly functional programs in the past that ran in tiny fractions of that. (Yes, there is a cost to features, but I still see a *lot* of pointless bloat and programmer carelessness...)

Re:Rust is going to eat C's lunch

[roca]

Rust allows programming "closer to the metal" than those languages. For example, Go, Nim, Scala and Haxe all require a garbage collector in practice for significantly complex programs. This makes it difficult (or at least heavyweight) to embed components in those languages into other languages and makes memory usage more difficult to reason about. This makes it easier to use Rust as a drop-in replacement for C or C++.

(Rust has other advantages over each of those other languages too.)

Re:Rust is going to eat C's lunch

[Anne Thwacks]

2017 will be the year of Snobol!

Re:I think Java is a well designed language

[Anne Thwacks]

less widely bused software.

I think you will find Java software is widely abused - usually with a wide variety of unprintable expletives.

"Some people swear by Java - the rest of us swear at it."

Overall I prefer the IEEE stats more

[Ambassador Kosh]

The IEEE seems to have a much better methodology and ways to look at the data based on web, mobile, enterprise and embedded markets.

http://spectrum.ieee.org/stati...

It just seems that the TIOBE results are much easier to bias by things like universities using a language as a teaching language. There are far more online courses on things like java and languages commonly used for web work but that does not make them more commonly used just more common to have webpages written about them.

I wonder what Richie thought way back when

[John Allsup]

If you asked Richie back in the early 70s whether he thought it would be a major language in 40 years time, I wonder what he'd say?

Re:Rust is going to eat C's lunch

[serviscope_minor]

I don't know if rust will succeed. It's the only one capable, really.

Rust basically has the same machine model as C and C++, but with a different syntax. There's nothing you can do in a more efficient and economical (e.g. memory, cycles) way in C compared to Rust.

The rest have garbage collection which basically rules them out and in addition do not have proper zero cost abstractions. They're prepared to burn cycles to make the programmer's life easier.

The exception to that is D. D can sort of run perfectly fine without the garbage collector and basically has the same machine model as C too. D's biggest win is it's unparalleled metaprogramming ability in this space. The problem with D is how the whole thing is run. There are two incompatible language versions (D1 and D2), which is something which will never happen with C++ or C, and I strongly suspect not Rust either. Also, they built the standard library to rely on garbage collection, so you can't escape the collector without doing a lot of work. Do you need to? Maybe, maybe not, but it means you won't get the standard library printf on a tiny MCU. Also stack allocation in D is a bit discouraged because it's unsafe (like C and C++), but it's really important for efficient or embedded code. That makes D less nice to use there. Also it's garbage collector is not that great speed wise.

New to programming and C is my first choice

[scrambled_binary]

Not worth much since I'm new to programming but when I began researching which language to start with it seems almost every language refers back to C or a variant of C. It just made sense to me to start with C and that it would be a valuable skill.

Re:Rust is going to eat C's lunch

[Lawrence_Bird]

Snobol 4 forevers!

In other exciting news

[LichtSpektren]

The hammer just passed the screwdriver again on the Household Tools Popularity List. Is it because the hammer has the venerable backing of large companies like Lowe's and Home Depot while the lowly screwdriver is still seen to be a hobbyist's tool unfit for enterprise adoption?

Stay tuned for next month's exciting random statistical variations and the inane commentary from bloggers desperate for clicks!

C programmers don't need to consult the web

[KeithH]

This TIOBE index relies on web queries for each programming language. Frankly, C programmers don't need to ask questions about the language itself since it is so simple.

I'm not questioning the popularity of the various languages but it seems to me that this metric favours the more complex languages.

Finally, in the embedded real-time space, there is still no real substitute for C.

actually not all software is only mobile/web.

[JustNiz]

>> more mobile- and web-friendly languages like Swift and Go are starting to eat its lunch.

Clearly you have no clue about how much embedded/realtime software programming is also going on out there, where using any garbage-collected language is simply not an option.

Re:Rust is going to eat C's lunch

[DrXym]

Rust stands a pretty good chance of being used for low level things where fast, reliable and performant software is required. Languages that use garbage collection would suffer runtime penalties and their memory consumption goes up and down like a yoyo. They could also suffer more from long-running issues like heap fragmentation.

Whether Rust will succeed remains to be seen however it's already built up a substantial number of libraries and support on crates.io and has proven itself popular with developers. I think it will find its way into a lot of IoT devices, drones, server farms etc. I doubt it will ever become a popular high-level programming language though because the compiler is brutally strict and will kick a dev's ass if there are any problems with lifetimes, borrowing, thread sync etc. Things that are trivial in other language can be quite hard to do in Rust to the satisfaction of the compiler.

Ok, it's down, but those are weird reasons

[HeckRuler]

It's still #2. And twice the index score of #3.

mobile app development. ... The constraint that C object code should remain small and fast doesn't help here.

Huh? That seems like exactly the sort of area where small and fast would help immensely.

I still find it infuriating when I want to have half a second for this clunky program on my phone to do it's thing.

Moreover the C programming language doesn't evolve like the other big languages such as Java, C++ and C#. There is a "new" C11 standard available but this contains only minor changes.

The language being stable is a good thing. A shining feature. Unless you enjoy all your skills turning to dust as you have to adapt to an ever changing platform. Who likes to build a house on shifting sand?

Yet another reason why C is getting into trouble is that there is no big company promoting the language. Oracle supports Java, Microsoft supports C++, C# and TypeScript, Google supports Java, Python, Go, Dart and JavaScript, Apple promotes Swift and Objective-C, etc. but none of them supports C publicly.

Also kind of a good thing. Because it's "Oracle, where tech goes to die". And Microsoft, where they keep bloody changing everything because some minor boss somewhere gets a bonus if he can convince 9% of the MS developer base to register with SilverLight tools, or how Sharepoint is "the next big thing". And frankly, I was surprised that every Go project wasn't mandated to direct their users to go sign up for google+.

C is punk. Fuck corporate.

It's portable as all fucking get-out. Low enough that you can make it smokin' fast. And it doesn't play any games with magical crap you can't see. The code is truth in advertising (unless you fuck around with macros like an idiot), and that makes it easier to debug. And everything as C APIs, so if there's a library out there you want you can typically go hook into it. Every bloody language has weird quirks and nuances you just have to be aware of. The tools that help you use the language are where it's at. MVS, while run by Satan, is actually pretty decent. But the classic C tools of makefiles, gcc or clang, and vim are powerhouses of usability that have been refined for decades. It's not the best if you want to talk to browsers. Javascript is the defacto standard there. And it's not the best if you just want to make yet another GUI button clicker for clueless suit. And Bash or whatever script of choice glues together the solutions of yesterday. But C is what you whip out for the hard cases for real meaningful programming. And certainly for anything critical like life support, satellites, weapon platforms, or kernels.

Re:Yeah, it sucks, but, then, C not an easy langua

[david_thornley]

Most performance-critical code should be written in C++, not C. It allows a programmer to be more productive, and reduces or eliminates several major causes of bugs in C programs.

It's turtle's all the way down

[slapout]

C is the first turtle. Most languages today have their implementations written in C.

Re:Rust is going to eat C's lunch

[OrangeTide]

That's a fair answer, although it makes me wonder why Modula-2 or Oberon didn't take off if that's some desirable core feature.

Re:Rust is going to eat C's lunch

[OrangeTide]

To me having a system that can be proven is more important than if it uses cycles for garbage collection or bounds checking or whatever. Minimizing software faults will contribute greater to your average performance on a cluster than a few percentage points performance improvement. Recovering from faults is very expensive in terms of system time and human resources. ex: if you can encode 1 movie in T time, then encoding 100 movies should take 100*T, but if you have a fault 5% of the time, then it's more like 100*T+k, and k can be significantly close to T. so now you're more like 105*T, you effectively lost some performance. It gets worse in situations where faults are require a job to start from the beginning (so a little more than 110*T if encoding must always start from the beginning)

I predict that formal verification (like SPIN model checker) will become more important to languages in the future than their ability to access the low-level raw potential. (I'm a professional linux kernel developer for a cpu vendor, so I do realize there is some need for low-level access)

Re:Rust is going to eat C's lunch

[serviscope_minor]

Depends on the platform, but regardless, that's kind of the point of Rust, to have the best of both worlds. Same machine model of C, whole classes of errors are impossible in non unsafe blocks. You never have to worry about use-after-free since the type checker proves you didn't do it for example.

In terms of correctness proofs vs performance, it's a tradeoff as always.