That seems like a problem easily solved with a tether.

Cleaning surfaces between floors may be an issue.

I am not so sure a game AI would be a good task for a highly parallel processor which mostly handles floating point numbers.

How would you even put an AI together without a ton of branching? It would seem to me that the entire problem is check this condition, do this if true, if not check this, etc.

Hmm, I think it is fairly relevant.

It is more difficult to write a C++ compiler than C, it is also easier to be sure an optimization is safe with C code.

http://benchmarksgame.alioth.debian.org/u32/cpp.php shows C as faster and smaller than C++ in most of the benchmarks too, and that one is GCC on Linux.

In theory they should be the same, but the reality is that they are not (although it is very close.)

Really? C is quite possibly the most portable language which currently exists if you care to write it that way.

I nearly always use C for programs which must be portable due to the ease with which it can be made to run on a variety of platforms. I have quite a few which run on more than a few entirely different platforms with a simple recompile.

You can write C code which is tied to a specific operating system of course, but for any task where you have language options other than C you can generally write a portable C program which does that. The tasks which absolutely cannot be portable also tend to be the type of program where you have little to no choice of language anyway.

I also tend to pair it with another language for the UI unless I need something specific (although that really has more to do with my desire to hand projects off to someone else for minor UI tweaks, color changes, etc.) If you want portable UI code there are C libraries which can do that, although you end up with the same problems other languages with a portable UI library have (mainly lack of consistency with the rest of the UI, as you are not using the native API.)

If the project is the kind of thing where a web based UI is desirable, you can even make the UI language HTML. It is easy to have a C program bind to port 80 and respond to HTTP requests, or use CGI and a web server.

I have a program using MSVC which is about 10% faster when compiled as C (with a long enough run time that this is a several minute difference just by changing the compiler option for the language).

Maybe some features could be disabled to make it match, or maybe it is an optimization the compiler only feels comfortable using if the language is C. In any case it does seem like programs in pure C tend to be ever so slightly faster than C++. It is not really enough to matter in the vast majority of cases, other design decisions will usually matter much more.

I can see the point of wanting to keep the language as C for the Linux kernel. While they could probably define which subsets of C++ are allowed and where, it is generally a lot easier on everyone to say that the subset is C for the entire thing.

The phrase "close enough for government work" comes to mind.

Lies, base64 encoding (as in e-mail) only bumps it up to 4/3. Even when you add TCP, ATM, and all the rest you are likely to run into, it will only be about 1.5x.

A worst case there and back is more like ever so slightly above 30 than 60. To get 60 on an e-mail you would need to bounce it between a totally stupid number of mail servers to get the mail headers to become 30MB.

TFA states that they are considering it.

It also states that we were supposed to set up our own production line quite some time ago, but never did so as it was cheaper to continue buying them directly.

I am not arguing the advantages of C for some tasks, it is my favorite to this day. I really only use other languages when I want to be able to hand maintenance off to someone else (if I think I will end up maintaining something anyway, I nearly always use C.)

While I have a fair amount of code running on Linux at work, none of my servers have the X window system installed. UI stuff is usually win32 or web based (if it can be.)

I still think the answer to the "I want to use C, but also want built in objects." problem is "Use C++."

They have no reason to do so, that project fails a risk / reward analysis hard.

Old does not mean bad, there are many more recent but much worse languages which have not stood the test of time. COBOL works well for what they do, the existing code is written in it, and it is well tested.

Designing a new language requires that you have staff who can design, implement, and test that compiler / interpreter. You then need to task that staff with doing so instead of something else which could make the company money, and retrain the programmers who would be using it.

If you try to pitch a project to an insurance or banking VP which involves a lot of risk, a lot of cost, and has no real benefit... you will at a minimum get a polite no as an answer.

C is pretty old as well (40 years compared to COBOLs 55), but most really important modern code is still written in it. I would not be surprised if it was still a popular language at the century mark.

The syntax for general mathematics is about 400 years old, and still going strong.

We should just open immigration up again with some minor basic criteria (learn english, no communicable diseases, job offer or enough cash to live for a year, etc.)

I have no problem with someone who comes here to make a new life. I do have a problem with the way we run the visa program right now.

Down with all the barriers!

I should be able to choose which country I pay personal taxes in too, it is only fair that I also get to shop around for the best rates available. The US wants an over 65% effective tax when all is said and done? Screw that, Bahrain says I owe nothing.

The local pharmacy wants big money for a prescription? Some importing can fix that problem.

Cigarette prices in NYC getting you down? Time for some arbitrage.

Problem with my order of a 5 megawatt magnetron and 50,000 smoke detectors? A vacation to central Africa sounds about right, I doubt they have a problem with it.

COBOL also happens to be very good at what it is mostly used for (insurance / banking.)

There are very few languages with fixed point and binary coded decimal support. You want this for financial applications.

Most other languages are C derived, and do not support these. The C solution is usually to use a scaled int, or two ints. This works, but is not obvious to a new programmer. New programmers tend to use floating point numbers, which is slightly wrong... banks hate being wrong, and hate having to staff a ton of very expensive programmers in order to get what should be simple tasks right.

There is always C, if you can hack it.

It has a near monopoly in systems programming, is common in serious applications across a large range of industries, and the standard sees minor changes every decade or so. The combined usage is enough to make it the single most popular language, and it has been for a very long time.

Most operating systems, compilers, virtual machines, and scripting interpreters are also written in C, which makes it easy to learn these when you have a reason to do so.

It is not for everyone though, and the learning curve to become competent is longer than most languages.

I still end up hand optimizing a lot of code. There are many tasks which are at the limits of current computational capacity, and require a lot of optimization in order to achieve a run time which is acceptable.

That mindset, and the newbies who have no idea how to do it, lead to few people who can do so competently these days, and therefore make it a very valuable skill.