Slashdot Mirror
How Relevant is C in 2014?
Nerval's Lobster writes: Many programming languages have come and gone since Dennis Ritchie devised C in 1972, and yet C has not only survived three major revisions, but continues to thrive. But aside from this incredible legacy, what keeps C atop the Tiobe Index? The number of jobs available for C programmers is not huge, and many of those also include C++ and Objective-C. On Reddit, the C community, while one of the ten most popular programming communities, is half the size of the C++ group. In a new column, David Bolton argues that C remains extremely relevant due to a number of factors including newer C compiler support, the Internet ("basically driven by C applications"), an immense amount of active software written in C that's still used, and its ease in learning. "Knowing C provides a handy insight into higher-level languages — C++, Objective-C, Perl, Python, Java, PHP, C#, D and Go all have block syntax that's derived from C." Do you agree?
Si.
Because not too much in C++ makes a whole lot of sense if you don't know where it's coming from. Every programmer should know how C++ features are/were/and can be mapped to plain C and what implications this might have for run time behavior and errors.
Relevant C
2B || !2B
Either learn what you're doing
Or stick to the Wii
Burma Shave
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
It is the equivalent of creation narratives for human cultures.
It is a bridge between the bare metal of the system (biology, assembly language) and culture/high-order functioning (culture, modern languages).
There is no better way to simultaneously understand (not to mention use) both system hardware and everything that has been erected atop system hardware than C.
There are few (any?) other languages that occupy this middle, connective ground so well.
With C you can be OO, but you can also be nearly ML. And you can do them at the same time.
Those widgets the clueless newspaper reporters and marketers call 'the internet of things', otherwise known as embedded systems, depends on Linux and C. So therefore C is 'the next big thing'.
Because it's extremely dangerous and a lot of people are still using it. The 'standard' standard library is so full of security holes it's not even funny, and attempts to 'improve' it over the years have mostly been unsuccessful because the bad coding patterns still exist.
C is a great language, it's just that most humans are incapable of using it safely and securely. It's like a .45 with a downward-pointing barrel. It's all too easy to shoot yourself in the foot.
For full disclosure, I used to be an avid C programmer, until I realized the harm I was causing myself and others. It's like when you drunk drive and think you're just fine. It takes an external perspective to realize how reckless your behaviors are.
A fool and his hard drive are soon parted.
C is the high-level language there. If you want actual control over your target, you'll need to use assembly.
Is there another OS/system programming language that is universally accepted as a reference, rather simple to learn, available on virtually any OS, real fast? I mean, go is nice and multi platform and powerful, but it is not even close to C popularity.
C++ should have been C successor, but it is too complex to be.
Do you agree?
I agree that with a summary like that, this is a trollish article designed to get a lot of posts and bring out people's emotions.
C is used for embedded devices. No other languages are competing for it at that level.
Most C developers are probably a bit older, and as such don't waste their time on social media.
As C is a simpler language, there's less need for online help. C++ is a cluster fuck of a language, so it *requires* a huge online support community. Social media popularity is an extremely poor metric. That's more based on fads and marketing than usefulness.
Languages don't just go away and vanish. Almost everything you use is built on top of it, even if you never have to see it yourself.
You can have a good career without ever touching C, but you need to know it is there. The only way to make it irrelevant is to replace all the existing infrastructure code with something else, and it is far too late for that to be feasible.
Like COBOL and FORTRAN, it will probably be with us forever.
Modern, best-practice C can be compiled with a C++ compiler. (There are a few gotchas moving in either direction - http://www.cprogramming.com/tu... - but it's not hard to avoid them.) For all its object-oriented impurity and spec-bloat, the one thing I love about C++ is that you can write relatively high-level code when that makes sense, but you always have the option to grapple with all the fine detail when that's useful.
Virtually serving coffee
Too many C++ programmers who learnt C++ without learning C first jumped straight into the OO and/or generics including the STL. Which is fine up to a point. But they tend to get completely lost when someone asks them to do any low level coding such as writing a bespoke B+ tree from scratch or something similar. Also when presented with multi level pointers they tend to get confused and don't really seem to understand the difference between pointers and C arrays.
A lot of problems want to have a solution that is very close to the hardware. C is an excellent macro assembler, but you need to remember to treat it as such.
It seems like very many programmers don't know, or don't want to think over the lower level implications of everything you do in C.
C is relevant because as long as we use computers, we need to tell them what to do, and C (and fuzzy bloated C like C++) does that for us.
Most people and most programmers don't need to touch computers on that level, and then other programming languages should be used. Those languages are often written at least partly in C.
As usual, use the right programming language for the problem.
I would even go as far as saying that you shouldn't do C++ if you can't do C, and you should probably not do C if you don't know how assembler (and machine code) works. Then you should stick to all the protective layers that you can, like in Python.
(Any good programmer should be able to program on any level from assembler to C and C++ to Python and shell-scripts and up.)
If you write a good useful library in C, it can be used from almost any other language, with little effort. If you write your library in any other language, you limit its use to a handful of related languages. Also, properly written C can be very portable to a wide variety of systems.
In Murphy We Turst
As to why there are more threads related to C++ on the Internet, easy, it's because C++ is a lot more complicated and complex to grok. I need as much help as I can with some of its tortured constructs and seldom used idioms. C is more straightforward (even if there are plenty of tricky things in it, which the seasoned programmers will either know how to use or steer well clear of).
Non-Linux Penguins ?
Lots of old traps in there, I stopped about 5 years ago with this book, needs a lot more work, but covers the basic "ooops" events. Thankfully at least with things like Valgrind / CLANG|gcc a lot of the older dramatic mistakes can be picked out quickly.
"C of Peril" - the book (pdf, free) at http://www.pldaniels.com/c-of-...
I always tell people who want to learn to code to go for modern C++ (preferably C++11 or newer) first, and then if necessary learn some C afterwards.
It is crazy how much more C code is needed to get the same level of performance and security that equivalent C++ has, and C coders know it. Just look at all the extensions that C compilers, and even the C11 Standard, borrow from C++ (generics, RAII) - but in a convoluted ugly way to preserve the precious ABI for 50 years.
And for all those who will say that C++ can't fit in the tight spaces that C can...well, you're wrong. Just disable the parts of C++ that you don't want (usually exceptions), and you can still get most of the benefits of clean code and RAII, with the same or better performance.
I hope than C will evolve to add a clean simple and single inheritance object model without all the over-complex crap from C++.
A even more advance would be that C get an optional standard library comparable to boost and the like that make consensus in the developer community.
Finally a JIT would make it competitive to the increasing markets areas with high diversity of silicon processors architectures.
Case in point, GCC recently switched from being compiled with GCC to being compiled with G++.
(Although I think it's a tad too absolute to say that "best-practice C can be compiled with a C++ compiler", but nearly.)
Help build the anti-software-patent wiki
The C language has a stable ABI, and it is the only mainstream language that can make such a claim.
C is very much still relevant - most of the deeply embedded computer firmware is written in either assembler or C, where the bit twiddling capabilities, compactness of the language and efficient generated code are of high importance. All those ATMegas, PICs, 80x51, Z80, Renesas, small ARM Cortex cores - chips that are too small in terms of available memory to use higher level languages and OSes effectively. Essentially, if you are writing "to the metal", you are most likely going to use C, assembler and (rarely) C++. Those chips costs peanuts and are pretty much everywhere, controlling everything from your toaster to brakes in your car ...
Programming is not only about the desktop and web, you know.
Even on more "grown up" platforms you will find C in the network code, most of system programming is done in C, C with its standardized ABI is an interface language (e.g. you can load a C-interfaced DLL into Python or Java, for example) and many many other applications. I would say that knowing at least the basics of C is as much a must for any programmer as knowing basics of English - unless all that you do are web apps in Javascript.
C++ is C
I used to believe in this until I had to work on both. Although one can compile best-practice C with a C++ compiler (sans the gotchas), that glosses over the idiosyncrasies of each language. C does not have initializers as in C++.
More importantly, it does not have references, type-safe casting operators and its template language is not turing complete as in C++. These differences will never go away, and these differences alter completely the type of design and implementation of your code and your abstractions.
Not to mention the C++ rules of PODs versus everything else which affect how we link C code with C++ code (and viceversa.) And modern C++ heavily uses templates in manner that makes the language resemble something else entirely. Whether that is a good thing is highly subjective, but whatever.
So from a practical point of view, it is sane to treat both languages as fundamentally different.
When we program in a language (be it Ruby, Java, C or C++ or whatever), we ought to do so in the idiomatic way that naturally exploits the best capabilities of the language. So with that in mind, we cannot treat C and C++ as the same language (and it is not quite accurate to compare modern C++ as a superset of the former, regardless of historical evolution.)
I do believe, however, that is very important, if not fundamental, to understand C semantics to use C++ effectively. The fundamental semantics behind the primitive types and control structures remain more or less the same. And I've always found that C++ programmers without a good background in C tend to make certain mistakes when they need to operate with pointers (since they are so used to work with references.)
Furthermore, integration of C with C++ is not an uncommon task, and development of C++ code with that in mind is paramount. It is very hard to do that without a good understanding of C.
To clarify: "Small target" means memory (RAM/Flash) is measured in kB, sometimes even in bytes.
You still have Python-capable processors for embedded systems if you can't afford to learn C.
As far as target size goes, that thing does not qualify as "small target".
FWIW, I've been struggling with LPC4300 series processors.
Those chips look like they're on the large end of "small target". Cortex-M4s are already pretty beefy CPUs.
The open source toolchain is just so bad that your CPU hard faults on first attempted function call (most likely due to incorrect memory maps).
You can usually get pretty detailed reasons for a hard fault if you dig into the appropriate CPU registers (HFSR, etc).
I'd check the linker command file. Setting up a basic memory map isn't that hard - it's the not-so-basic stuff where things get interesting (copying functions to RAM for execution, etc).
It's as if engineers could skip calculus because there are automated systems that will do it for them. Even if they never work directly with calculus, the experience is critical to being a competent engineer.
Yes, C has features/bugs that can be really ugly. But as a professional you can make a system like C and it's runtime libraries work then you are much better equipped to do other complex tasks. The experience can result in careful habits that will help your entire career.
Why is Snark Required?
The most important reason-feature to learn and use C is that it's the LOWEST COMMON DENOMINATOR in many other languages' attempts for interoperability. These APIs are many times written in C in order for the libraries to operate seamlessly between them. Another good reason is to improve what you can do with Lua. With C and Lua you can literally tact almost any problem, from drivers to databases. It might not be the most efficient way, but definitely you will get more bang for your time and money.
"Sum Ergo Cogito"
To mobile application market? Irrelevant.
To online web services? Not so relevant.
To online web server? Very relevant!
To high efficiency applications? It's almost the standard.
To operating systems? There's almost nothing other than C (in terms of market share).
Please, elaborate more on your stupid question, you insensitive mobile clod!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
A lot of HW related companies use mostly just C. Any sort of small device development or most appliances (switches, storage, etc.) have software written in C. Any driver development, etc. It is still the language anyone can pretty much agree on.
If programs would be read like poetry, most programmers would be Vogons.
C is great for low level stuff since it is capable of generating machine code that has zero dependencies. K&R even explicitly mentions "non hosted mode" with no libc and implementation defined entrypoint semantics. In fact, it is the only language in mainstream use today that has this feature (aside from assembly.)
For kernel, drivers, firmware, embedded, and RTOS its pretty much the only choice unless you want to code everything in straight assembly. Since my current job is firmware programming, I've actually like the C language now that I've been forced to do a lot of heavy coding in it instead of Python.
The only real place C is used any more is embedded systems. I never had any experience with that. I used to be a C expert. Understood pointers and C quirks. But the work dried up. Everything went to Java and C# as far as applications programming goes, and I went with it.
C started out with high level "constructs" that were basically the operators of the PDP-11 and VAX processors from DEC. While those constructs have mapped well to other processors, virtually every statement in C originally compiled to one instruction on those processors.
To this day, C still gives you the power and flexibility of any low-level language worth it's salt, and ample opportunity to hang yourself and your code. Don't forget -- C++ originally targetted C as it's output, not machine code. C has similarly provided the "back end" for no small number of special-purpose compilers.
Then there are the operating systems and device drivers that have been written with it, and all the embedded systems logic for devices all and sundry.
C will never die any more than assembly or COBOL and FORTRAN will. There will always be those special-purpose high-performance tasks where it is worthwhile to use C instead of a higher level language. Just as there are times where it still makes sense to drop even lower and into assembly.
You go ahead and try to bootstrap an entire C++ implementation so you can write a kernel in it. Good luck with that. Getting a C library framework running on a bootstrapped kernel is hard enough. C++ would be orders of magnitude harder.
I do not fail; I succeed at finding out what does not work.
If you need to be efficient, you write in C, end of story. That's why.
C++ and all the other languages there simply have too much overhead and give you not enough control over what's actually happening.
Assembler isn't worth the major hassle for the tiny improvement you get over C.
C, however, is at this unique point between the bare metal and the high-level abstractions where the trade-offs are perfect. You get just enough abstraction to be a) hardware-independent and b) can use a high-level programming language while remaining close enough to the machine that you can be really, really efficient, fast, short, the whole nine yards.
Assorted stuff I do sometimes: Lemuria.org
If you want to write something highly performant C is still the preferred option. Not because C produces faster code, languages with advanced run time environments like Java are in a better position to optimize your code, but because you know exactly what is going on. In my experience, the two things you should avoid in a highly performance application are system calls and locks.
In a high level language you can never be sure when a lock is taken or when a system call is fired off. In C, well, you'll have to be pretty explicit about both.
We're talking about C. You want the zeroeth post.
At least he made the first post.
I have written embedded Pascal. Never ask me to do it again.
Once. Gave me a real appreciation for high level languages like C.
And, yes, it was an embedded application. No user interface, the controller talked to the device, the device ran some very precise valves. It was actually a fun month getting all that working.
Best Slashdot Co
Yes - C is still useful, and very relevant as a touchpoint for its descendants.
But no, those other languages do not "have block syntax that's derived from C." They all, including C, have a block syntax that's derived from Algol-68.
Mudge
In theory, theory and practice are the same.
In practice, they're not.
C++ is not the only way to do object programming. If fact this is probably the most complex and crappy way to do it. A lot of others language have proven that object programming can be more simple. C is late in the object programming game and can take this as an opportunity to do it the right way.
I think there's a disadvantage with having languages designed solely by language design experts, and that is a tendency to over complicate things. They all understand it, and appreciate it's elegance, so it must be the best way.
To draw an analogy, consider the musical excesses of prog rock / jazz fusion. The musicians themselves may appreciate a Locrian scale played against an AbSus13th arpeggio , but the audience can easily end up excluded. Then a musically simple but catchy band like the Sex Pistols comes along and steals their audience.
I reckon languages need to be really really simple to understand, in order to become popular. For most people they're a tool, not an end in themselves.
> Do you agree?
Yes
You are correct about that, Linux is actually a huge driver for the need of C experts these days.
"C is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use C itself a lot."
Now, nobody in their right mind would call C a "good" language with regard to syntax. It is however unsurpassed if you want a portable language that gives you almost as much control and speed as assembler. While simpler things can often optimized by compilers for other languages to be reasonably efficient, some things cannot or there are huge other costs, for example inflated memory footprint or crippled system interfaces. So when you do understand the machine model and need fine-grained control, C is the way to go. That is one reason why C is relevant today and will stay relevant for the foreseeable future.
Another thing is that anybody that can program C well does understand how CPUs execute code. That provides a number of advantages when writing things in other languages and it allows the implementation of performance-critical sub-modules in C. For example, I have made excellent experiences with algorithm cores in C and glue- and control-code in Python. My personal take is that those that call C outdated or even demand its retirement do not understand how code is actually executed and just want to remove the advantage those that do have. In other words, a programmer that cannot (also) program well in C is limited in understanding and capabilities and hence I expect that many jobs requiring C do not actually entail work that is mostly or completely done in C, but people that do understand how computers actually work in the lower levels.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
We know that problem in and out: People mixing up C, C++ and Objective-C. Especially non-experts. That's no surprise. Then saying, despite requireing "C/C++" in the confidential: "Oh, you only have 20 years of C - I thought you knew at least a little C++ - OK then, sorry, you're the wrong guy." ...
Me: *pictures Vincent and Jules pulling out their 9mm parabellums and pumping the HR guy full of bullets"
Non-trivial JavaScript only caught on on a large scale when the term Ajax was coined and with it we finally had a better word for JavaScript - until then most decision makers would mix up Java and JavaScript. Sometimes without anybody noticing that. ... In hindsight, I really can't blame them all that much.
I think of all the C stuff as the "C" family of languages.
As far as I can tell, coaxing C into some OOP thing is a little tricky, but doable. C++ is different, yea, but if you turn on your brain and are willing to ditch the habit of writing your own stacks, any C dev worth his money should be up to pro-level C++ development in a few weeks. Same for Objective-C. It's not that C people write everything from scratch these days. Where to you think those bazillion libs in Linux come from?
As for the C-Family of languages: Of course there still relevant. What kind of stupid question is that? What's Linux built with? C. What's Windows built with? C++. What's Mac OS X built with? Objective-C. What is any non-trivial system critical component built with? C, C++ or Objective-C (in the case of OS X / iOS).
And that's not changing any time soon, trust me on that one.
We suffer more in our imagination than in reality. - Seneca
That is something I have often observed with customers. Another problem is non-understanding of what UNIX already gives you. For example, some people wrote a huge document-transformation and transportation engine in Java, when all they needed was a cron-job using ssh to move files, transfig and ghostscript. Unix-expert: 2-3 days for the implementation (plus 4 Weeks test, deployment, etc.). Java people: more than 1 person-year and they are still fixing things in there.
I have long since believed that making complex things easy in a language is a mistake (except for special-purpose languages, such as R), as many programmers do not have the expertise and experience that is required to write software as simple as possible. If you make complex things easy to use, they will just throw everything and the kitchen sink at the problem and end up with a complex monster that nobody understands anymore. Complexity can be hidden to a degree, but it is still there and there will always be instances when it surfaces and the only way to debug problems then is to understand the complexity. Languages that try to hide complexity make it far too easy to violate KISS.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
C is not intended to be a beautiful language. C is intended to give you as much control over the raw machine as possible, without going to assembler level and with (these days) reasonable portability. If you compare C and Pascal, then you have failed to understand the purpose of C.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It seems C++11 was just finalized yesterday, but already we now have C++14 finalized and C++17 in the works....
This is hardly the same language from a few years ago - the power and ease of use that has been added, both for library and application developers is amazing.
Anyone programming in C++ who isn't thoroughly familiar with all the new stuff in C++11 is missing out tremendously...
It's very relevant for producing more slashdot page loads. But since the summary includes the answer to the question ("But aside from this incredible legacy, what keeps C atop the Tiobe Index?") this is a non-story.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Apache as well, and if you want a fast apache module, you better code it in C.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Here's one of countless reasons why you should learn C++.
std::thread([&](){ do_something(local_arg1, local_arg2); }).detach();
Write me the equivalent in C.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
We're talking about C. You want the zeroeth post.
You have to remember, there are two kinds of people in the world:
1) Those who begin their indexes at 1.
-and-
1) Those who begin their indexes at 0.
If people think that C is not relevant in 2014, I'd hate to think what they thought about the ladder logic type languages in PLCs that pretty well run every manufacturing plant in the world.
I am Slashdot. Are you Slashdot as well?
When you look at the output code from a C compiler, it tends to be small and fast, and relatively light on resources. In many cases, with modern compiler optimizations, the resulting code can actually be smaller and faster than all but assembly code written by someone who really knows how to optimize for a specific machine. Almost all embedded development work is done in either C or assembly, and C tends to be faster to write, and portable - so you can move the code to the next project if necessary.
Using any 'modern' object oriented language immediately adds a level of bloat which is generally not acceptable in places where C still shines. These modern programming languages are written for environments where a few extra bytes or a few extra cycles isn't going to cause a problem. When working on a resource-limited platform (aka where you'd kill for a few hundred KB of code space, and more than a few thousand bytes of ram) you're just not going to be able to use a modern language because of the overhead of an object oriented language.
I'd actually predict C is going to grow in the near term, just because of the growth of internet-connected low-resource devices. I actually develop products on a platform which has a complete TCP/IP stack (including web server and SNMP) running in less than 128KB (yes K not M) of memory. These and other similar small platforms are going to be the basis of the 'things' half of the internet of things, all of which are going to have C code at their base.
90+% of programmers claiming to be working in C++ are really writing straight up C code with the occasional object. because they occasionally use an object and want to be lazy and declare their local variables at any random moment, they end up having to use the C++ compiler and so claim to be writing C++.
what they are really doing is writing bad C.
so, saying C++ is twice as popular as C is incredibly misleading.
The difference between Theory and Practice is greater in Practice than in Theory.
Tue 12/09/2014 8:48 am. I assume a lot of people write supposedly C++ programs that are actually mostly C; I know I do....
I agree that Java and C# have a cleaner and simpler object programming model than C++, but there are not popular (if even suitable) to write low level code. C is very successful because it usability span from the smallest microcontroller to very big projects. Support for almost all silicon is almost exclusively done in C and it's very unlikely to change quickly. I think that adding a pragmatic simple object model to C will make a lot of sense.
It may also be that 90% of C++ projects are ones that should have just been C to begin with. The code will naturally try to fit the problem domain.
"C++, Objective-C, Perl, Python, Java, PHP, C#, D and Go all have block syntax that's derived from C"
And C got the block syntax from B which got it from BCPL which was a simplified version of CPL which was influnced by the first block structured language, ALGOL.
I was taugh ALGOL at University, though I had already been "mentally mutilated beyond hope of regeneration" by BASIC before that...
I started digging around in the Gnu flex source code for fun recently. Even though it's pretty moldy and old and uses global variables all over the place while it's generating your scanner, I'd still rather use flex than anything else if I'm going to be parsing a complex file format. I'm looking at sprucing up its C++ classes a little bit. I know there are projects out there to do that already, but this is really more of an excuse to go digging around in its guts than anything else.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
What you're saying then is that there is nothing more popular than code written in a bad, mongrel version of C.
quiquid id est, timeo puellas et oscula dantes.
How many times more this year (only 22 days left!) are we going to see these types of "articles"? Give it a rest. C, COBOL and Fortran will be around long after all of you are dead.
That's a great sig...
There are two types of people in the world: Those who crave closure
C is a great language, it's just that most humans are incapable of using it safely and securely
That sentence is self-contradicting. To my mind C cannot simultaneously be a "great language" and be impossible for most people to use safely. I would posit that to be considered a great language, the ability to use the language safely and securely by someone of ordinary skill in programming is a necessary condition.
Since we are so fond of automotive analogies here... While the power and utility of C is undeniable, it's kind of like a car with too much horsepower and not enough traction. Really talented people can handle it but most should drive something else. It might be amazing in the right hands but that doesn't make it great.
There's also OpenCL which is far closer to C than the rest of them, and that is a language that is still up and coming.
That is, very much so because of huge established code base, but watch out for your future career. C would not be the best choice for any new code base. For low level programming, it can not achieve the best performance because it enshrines how CPUs and compilers worked in the 60s instead of being amenable to extensive optimization, non-trivial vectorization, running on GPUs or automatic use of multiple cores. On high level, it's not suitable for large teams, as one developer's bug can affect others' code in unpredictable ways.
So anyone with long term career plans should at least be familiar with Java, .Net, Swift, Go and so on to be prepared when progress happens.
wow... someone does not know anything about coding. Go ahead and try to write a kernel extension in python... wow. there are different languages for different tasks. C will be around for a very long time.
So long as programmers feel the need to write C to show off what studly coders they are we'll be stuck with C. We'd all be better off if we could spend less time fixing C-related bugs and concentrate on making sure safer languages were just as fast and functional. I'd suggest C# as a better alternative but recently I've been discovering how stupid its handling of byte order is. It's not a bad language except the amount of idiot Microsoftisms it has. C++ is just as bad as C. Objective-C is a mix of genius and insanity. Java is its own set of kludges. Python is nice but slow. Go isn't enough of an improvement. ... Not sure we're ready to replace C yet but we should get ready.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
First off I'd consider C++ and Objective-C to both be variants of C. And you can make a fairly good case that Java is also a variant of C.
That being said there is a good use case for C by itself. Lots of algorithms execution times are of forms like R*n^2 + S*n + T. For N large, A is all that matters. For N small T can often be the dominant factor. The C language, like assembly excels at getting the execution times for T down. However for most business processing execution time isn't really all that important since n isn't large nor is T particularly big. In which case programmer efficiency matters a great deal.
Well to go off topic for a second. What is the news with Rust? I know Samsung was backing it, but I haven't heard anything in well over a year. Anything happening exciting on the Rust from?
Yes. There is an entire world beyond the sphere of web programmers. Go into the automotive sector and ask about using python, java or any other higher level language in a engine controller.... LInux? I don't want my car to take 2 minutes to boot and go into a kernel panic because a guy in his basement wrote a driver for something. Python? We can put 1 GB of ram so a lazy programmer can have his pristine language environment. In the world where things have to work reliably and there is no room for esoteric languages, C rules the roost
Who cares about how popular code is now? How popular was it? How much stuff is coded in C that is vital to people willing to pay people to fix it and maintain it and perhaps even improve it. Fer craps sake, Cobol is still alive and kicking. Just because some computer science wiz farts out some new language every three years doesn't mean that all the previously built code goes up in flames. The old code has more lives than a zombie apocalypse and some poor sap gets to make a living off of it. This is supposed to be a serious profession not a gaggle of high school sophomores giggling over who got asked to the senior prom.
Creative Spelling Copyright (2002). May use without Persimmons
It looks like your cat fell on the keyboard. What does the code do ?
... the relevance of C is more than it should be.
C was obviously invented to fill a niche - SkyNet will need a language to develop their self-aware minions.
Otherwise, don't try this at home, kids.
Since we actually have a widely accepted portable assembly language now, I have been pondering this very question. LLVM assembly holds a lot of potential, similar to how the TAOS operating system promised back in the early 90's with its virtual processor assembly: https://sites.google.com/site/...
The guy who inspired me to want to program used to write assembly on a 386 with a slightly hacked copy of the 8086-oriented freeware assembler CHASM. He read compiled binaries in hex like code. I asked him, "Doesn't it take a lot more time to write in assembler?" "Not that much", he replied, "You break things down into functions and build libraries of code you don't have to reinvent, just like in C." The guy was freaking brilliant.
We've so frequently created new languages around new ideas in programming, and that's great, but eventually the number of abstractions becomes quite an issue. People are willing to write operating systems like MenuetOS in assembly in x86_64 asm. That's great. I'd love to see a compiler there to do validation of code, uphold Ada-like programming by contract, that sort of thing, but I'd love to see assembly programming make a comeback.
i feel that the answer lies in the sentence "the internet is driven by c". if you want direct performance, executable compactness as well as operational efficiency (that is also massive step up from assembly language), you have *one* option available to you: c. that means that apache, wine, postgresql, openldap, cups, samba, libc6, the python interpreter itself, the linux kernel, the windows NT kernel and many more OSes: they're written in c.
only when some of those constraints - performance, compactness and operational efficiency - may be relaxed in favour of, for example, a higher bang-per-buck ratio in the expressive power behind the lines of code written (python dict), or where code-resuse is critical without too much inconvenience (templates and objects of c++), *then* you begin to choose alternative programming languages.
but as a general rule, if ever you see the word "system" or "service" in a sentence (operating "system", web "service"), automatically that implies "high performance" which automatically implies "high efficiency needed" and that means "c".
so i feel it is therefore much more interesting to note the situations in businesses where c is *not* used despite there being circumstances where performance is critical. when people choose java for web services, for example.
First off, in what freaking style guide is it acceptable to declare a function and a three-command main function all on one line? Inline lambdas are perfectly fine style, that's pretty much what they're there for, but what you did isn't even close to acceptable style.
Secondly, that's not what I asked of you. I did not say "create the simplest pthread example you possibly could". I'll repeat what I asked of you:
std::thread([&](){ do_something(local_arg1, local_arg2); }).detach();
That is, I asked you to create:
1) a thread, that
2) runs a function called do_something, that
3) takes two arguments, that
4) are varialbes local to the function that spawns the thread, with
5) no restrictions that the thread may only have one instance at a time, and
6) runs detached
Go.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
I have worked in process control and high energy physics for the last 30 years. When the PAW (physics analysis workstations) were converted from Fortran to C++ it was a total disaster, a bloated piece of crapware emerged that took more resources, ran at half speed if it didnt crash with a memory leak first. I have stood on the bank of the river and watched the corpses floating by, the latest fads in languages back then, remember Pascal, Modula, Algol68 .... During that time Linux hackers were perfectly happy to write their C code with vi and make, perhaps with cscope and get reliable binaries that are maintanable.
The point about C is its a SIL (Systems Implementation Language), no one in their right mind would think about writing a kernel in C++, its an abomination. For those of us who need OO then C# and Java are great, look at Android.
The old languages that have survived the test of time have done so because they work for the niche they were intended for. C is brilliant at describing and using hardware interfaces and writing beautiful fast kernel code, and yes macros are great "ContainerOf" and "WaitEvent" are two that come to mind.
So cheers to C, Fortran (making a strong comeback), Lisp and Python. May C++ rot in hell as soon as possible with the rest of the crap, if I want OO I will use Java.
Oh, and just to let you know, even your minimal example that doesn't come close to meeting the specs cheats on not declaring the pthread_t (you can't declare it inline) and has a bug in the declaration of func (should return void*). (we'll just take it for granted that that thread_1_stuff, thread_2_stuff, arg, and #include <pthread.h> exist, since the equivalents are assumed in my example)
I'll go ahead and help you out on meeting the specs provided by giving you a realistic sample program (I'll skip file error checking for simplicity; all of the other code is plain C). Replace the C++11 code with the C equivalent.
Surely that's a trivial task, right? You just need to replace one line, after all. Go for it.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
It's simple. C is self hosting and extremely portable, and the amount of extra stuff needed to run C can be none (in the case of kernels, everything can come with the binary), little (shared libraries) or lots (a whole OS). There aren't many other languages which can self-host and can create binaries which can run on bare metal.
Other supposedly portable languages like Java, Perl and PHP require an OS and environment to do anything, which makes them unsuitable for running on small embedded systems, for high performance applications, or for talking intimately to hardware.
The languages also change too much over time. You can't just take old code and run it in a new interpreter. If Java wasn't in the hands of a megacompany, it MIGHT be more portable and less bug-ridden, but right now it's write once, run only in certain places, deal with a zillion security issues. Many companies I support have to keep around a VM or an older machine to run an older JVM because new Java is not compatible with old Java.
C has changed, but not so much that K&R C is unrecognizable to someone learning C now. A program written in the 1970s can be compiled by a CS student today without much more than, perhaps, changing a few #includes. This is what makes it lasting and worth learning.
I would write it something like this: start_do_something( arg1, arg2 ) ; But with a better name, of course.
C is not intended to be a beautiful language.
And yet, it is.
"First they came for the slanderers and i said nothing."
Line 4 of your code fails to compile... Sigh...
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
The largest program I build each day is the Linux kernel.
When I ask the question "How relevant is the Linux kernel in 2014?", the relevance of C becomes hard to question considering its 15 million lines or so. ;)
There's some descriptions and sample code above, but I'll break it down.
std::thread(): This declares a std::thread object, which is a c++11 thread-launching object. Its constructor here takes an argument of a function.
[&](){ ... code here ... }: This declares a lambda, which is basically an inline function. We could of course declare a function further up, then pass that to the std::thread, but that'd take more code, and more importantly, the declaration would be far from where it's actually being used, which is bad coding style. So we use a lambda to declare it right where we use it. The first part between the brackets declares what variables will be "captured", aka, made usable inside the lambda. So you could say [a,b,c] for variables [a,b,c]. & means "everything". The () is just like for any function - there's no arguments, so it's just (). The brackets are, again, just like with any other function - they enclose code. .detach(): We're telling our newly created thread to detach.
gcc actually just wraps the c++11 code into pthreads, so it works exactly the same way - you even still have to link in -lpthread. But it's far easier in C++11, especially once you get away from trivial cases. And this is actually just the beginning of what you can do - there's also futures, for example, that let you do stuff like:
auto a = std::async(std::launch::async, [](){ return waste_time(1.0); });
auto b = std::async(std::launch::async, [](){ return waste_time(2.0); });
printf("Result: %f\n", a.get() + b.get());
The printf won't evaluate until both the first and second waste_time functions are done evaluating and have returned a value, but it doesn't make them evaluate in a particular order. If you wanted you could take std:async a step further and wrap it into an object that overloads common operators with an automatic call to get(), and thus you could have something like:
auto a = my_async([](){ return waste_time(1.0); });
auto b = my_async([](){ return waste_time(2.0); });
printf("Result: %f\n", a + b);
Usually, though (IMHO) futures are overkill.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
It doesn't matter if you are building a house, a supermarket, a factory or a major civil engineering project you will needs some bricks.
Building Software is the same
And you would call it how? If you would simply call it "start_do_something(local_arg1, local_arg2)", then it's not threaded and doesn't even come close to meeting the spec.
This is a really basic use case here. You've got a single line of code with a couple arguments and want to run it in the background. How much more basic can you get than that? In C++11 it's a single simple line of code. In C it's anything but.
I'm still waiting for someone to *actually* implement the spec in C. We're talking about implementing a single line of C++11, a line involving a commonly desirable task, in C. How hard could this be if C is any sort of half-decent language at all? I even gave you a sample program to put it in (see below).
The problem is that threading isn't trivial in C like it is in C++11, and thus most programmers avoid it unless they absolutely have to deal with it. Which leads to underperforming and hang-prone programs, a problem that's only going to get worse with time.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
I am not implying that is what the C stands for.
But C programs are best for what I consider to be Core Level software.
Operating Systems, Compilers, Database engines, Web Servers...
In general C is good for programs that needs to take the most out of your computer.
However higher level langues should be used for those application where faster development time is more important then the products overall speed.
Being that most business apps are just a form where people fill out and query a db. Those can be done in the PHP/Python/C++/Javas of the world. While the stuff handling the IO Calls should be done in C.
Now back in the Mid 90's C was to be the the main programming language for any program. Due to the decline of Business Languages (Cobol, FoxPro, Delphi...) and the move to the PC which needed the extra speed to run on the slower Desktops.
However now with most stuff being server based. It is cheaper to use a quicker to code, language with the cost of performance due to cheaper hardware prices vs expensive labor costs.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
C-x M-c M-butterfly
http://xkcd.com/378/
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
C is still my second-favorite language.
It was my favorite from... around 1983 to 1989, at which time Objective-C became my favorite.
(Apple is working towards destroying Objective-C, so my favorite may very well go back to C in a couple of years.)
Unix was proclaimed dead in 1990 by Byte Magazine. Windows is broken, Apple is rotten, Solaris has set, IBM AIX with age, HP-UX was fed to ducks, Excel has left Word that it is out of the Office, the Oracle is learning Delphi, but still there's quite a byte of C code running for president every day.
Here's the thing about c. If you're good enough to use it well (rare, I admit), the results can be made to be faster, more efficient, and more *clear*, meaning, you can actually see what's happening, while still remaining reasonably portable, than any other language. Even in the largest applications. Perhaps especially in the largest applications.
Until someone comes with something faster, c is *the* goto language for high performance coding.
As soon as you start sticking generalized objects in generalized boxes, as soon as you decide you can't manage your own memory, as soon as you decide you must have generalized abstraction (as opposed to specific, high-efficiency custom abstraction, boxes and objects), you're sacrificing performance, and you're probably sacrificing size and efficiency at the same time.
If what you're writing is a word processor, well, so what. But if you're writing real time goodness, or something truly CPU bound (like almost any AI undertaking, or SDR, or speech recognition, or object recognition, etc.), not using c is a mistake. Not to mention a waste of the eventual end user's resources. Just because there are CPU cycles available doesn't mean that it's OK to chew them all up, likewise available RAM. Operating systems can do more than one thing -- if they're not choked to death by some lumbering, clumsily implemented hunk of crap.
c is awesome. c is simple. But c is difficult, because you really have to know what you are doing. All that power at your fingertips means its 1000x easier to drive straight into a tree. You have to truly understand, on an intuitive level: stacks, memory management, objects, abstraction, how c statements likely map to CPU activity and instructions, and how to write clear code and documentation and a bunch of other stuff -- because it's up to you to manage all that stuff, and a failure in any of those areas is very likely to negate all the other advantages, or worse.
The only thing better is assembler, where you can *really* be efficient and produce ultra-fast code. But assembler isn't portable, and that, sadly, is usually the end of that.
I've fallen off your lawn, and I can't get up.
Yep. c++ = larger executables; slower executables; less comprehensible code; less clear code (what is the CPU likely to be doing here? No bloody idea.)
c is the bomb. c++ is just a bomb. A crutch. Anything you want to do in c++, you could have done in c, the primary difference being that as a c programmer, you would have -- had to have, in fact -- actually understood what it was you were doing.
c++ is building kits from nasty little pre-molded pieces. c is carving your own pieces, where, if you like, every one can be a work of art and YOU control how they all fit together. You even get to make your own glue. :)
Of course, if you can't carve, have an irrational phobia re glue, and can't design the pieces you need... well, time to drag the crutches out.
I've fallen off your lawn, and I can't get up.
C is an abstraction of hardware concepts, and newer languages (even C++) tend to be abstraction of concepts from Comp Sci (object, function curries, comprehensions, templates etc etc). Someone has to bridge the two concepts. C++ succeeds as a language that supports both, but never been that big because most people either use it as C (and not use any features), use it poorly (because they don't understand how the various constructs work) on the hardware end. C has lesser concepts to worry about, but gives more rope to shoot you on the foot.
E.g. simple statement like "if (string == "hello")" in C++ could mean that == is overloaded and if it accepts an object string, "hello" invokes the copy constructor for string object and passes it to the string object's == operator, which might do a char by char comparison, and then the unnamed object "hello" is destructed.
You generally don't care about this for business logic or if your website is getting one hit every few seconds, but if you are getting a million hits per second, you need to start optimizing the way you do things, you'd need to know which of L1/L2/L3 caches you'll miss, what'll be the real impact of your code. C, without the fluff, gives you lesser things to worry about.
C will be relevant because no other new language is trying to replace it.
I agree.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
...relevant... as in:
"nearly each pixel of your screen while reading this is rendered via either C, C++ or something that is written or compiled in C and derivatives".
That makes it sufficiently relevant, doesn't it?
are advertised seeking specifically 'C' is that a large portion of people who routinely program in C are not employed as programmers per se. It is the language (as many others here have pointed out) used to code for embedded systems and real-time control devices but these are generally programmed by Electrical Engineers or techs who are not listed on the company rolls as "programmer". In the math, physics and chemistry academic environments, guess how simulations and models are coded? Yep, in C (and yes, physicists and mathematicians programming on the CUDA platform largely use C too). FORTRAN is hardly ever used these days. Aside from my own experience, I have numerous friends who work as engineers, physicists, mathematicians - and even biologists - who regularly code in C. However, that's not their job function and most of them are, frankly, not great coders if you're looking at clarity and standardization of code. The EE's working on embedded sys stuff are probably the best of this lot because they realize that other people WILL have to read and work with their code.
Note: 8 hours later, and not a single person has replaced the single line of C++11 doing a commonly desirable task (running a line of code with a couple arguments in the background any number of times) with C code. How pathetic is your language of choice that such a challenge isn't just a gimme?
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
I'm not trolling here, I've spent way too many years using C++ to earn a crust and am an unpreposessing Scheme junkie too. The purpose of a language is to provide an automatic mapping from our "headspace" into something the computer understands. Complex semantics make this process more prone to overt errors and much more vulnerable to subtle errors that seem to work. Simple languages lay everything on the table, there is very little buried deeply in libraries. Really good code is usually "bespoke" code which someone has thought carefully about, not the result of putting a bunch of popular object classes into a code-supercollider. Good programmers can use C as safely as they can use C++, Java, Python or any of the other rising/risen stars; arguing that C provides little protection (using whatever metaphor you like) is just trolling: C isn't a language that you *expect* to protect you -- you take extra care with it. Pick the tools for the jobs -- there are a lot of jobs that need to be explicit, clear and easily checked: C beats the other popular imperative languages hands down here. Bet Ron Swanson codes in C (or assembler if he wants that "hand-tooled" feel).
Here's one of countless reasons why you should learn C++.
std::thread([&](){ do_something(local_arg1, local_arg2); }).detach();
Write me the equivalent in C.
Wow! You should mention this on the Linux Kernel Mailing List. The Linux kernel is LOADED with threads, all written in C. You will certainly save the kernel developers lots of time when they switch. Please write back and tell me how it goes.
I totally agree with you. Please report the same on the Linux Kernel Mailing List. It's a shame the Linux kernel is written in C and does not benefit from this.
That, of course, does not even remotely meet the spec I presented above. And it's not even standard.
This isn't a challenge to write a replacement to Xorg or anything. It's one damned line of code, people, with your test case given to you, representing a common scenario. How freaking hard can that be? The fact that nobody on a slashdot thread full of pure-C fanboys can't manage this simple task just speaks volumes as to how terrible threading is in C.
Well said, Programmer From 1983. Single core processors are the future! GUI hangings are just part of the business! Trivial background tasks should be spawned with exec* and communicated with via IPC!
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
So your argument is "because there exists a piece of software, the language of which it was developed in being chosen 23 years ago, then all pieces of software should choose its language too"? Impeccable logic. Who can argue with that?
Let's take a look at how a typical part of the Linux kernel deals with threading, shall we? Here's the first random example I came across in a quick grep of a source tree - drivers/mtd/ubi/build.c
First, we have to declare a struct (in a different file, ubi.h) to hold the data we want accessible in the thread:
Now we need a struct to manage all of our threads' arguments:
UBI_MAX_DEVICES having already been defined in the .h. Now, of course, to be able to access the device, we need lots of helper functions. Among the half dozen or so:
When they want to insert, they have to do stuff like:
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
It's a kernel, not a userland program. It's never going to be as simple as a userland program, so it's a bad example. Kernels can't have the C standard library or pthreads or the STL. Well, technically they could, but that'd make the kernel code massive for marginal benefit and any kind of library bug would become a kernel crash waiting to happen.
It seems that threading isn't nearly so simple in C++ either; at least, not if you want to get it right. From https://akrzemi1.wordpress.com... and http://www.open-std.org/jtc1/s... it would seem that while initiating a thread as you've discussed within a C++ program is easy, the nuances of C++ threading are uglier than C pthreads threading. Quotes like these make C++11 threading seem a lot less trivial than your initially impressive example suggests:
"If a thread is cancelled no destructors of automatic objects are called; or at least, it is up to the implementation if they are called or not. This would cause too much resource leaks. Therefore, it is not possible to cancel a thread in C++. There is a similar mechanism though: thread interruption. Interruption is coöperative: to-be-cancelled thread must acknowledge the interruption. If interrupted, a special exception is thrown that unwinds child thread’s stack until it reaches the outermost scope. However, interruption mechanism is not available in C++11 either."
"But all those threads computing fib1 are still running! And as they finish, they will write to all those instances of fib1. Which are no longer there, since the stack has been unwound. In its place will be the stack corresponding to the continuing computation that was initiated when the exception was caught. Thus we now have a large number of threads writing to various locations on the user's stack. By the time the user tries to debug the resulting mess, there is a good chance they will all be gone, leaving him/her with nothing but a stack with mysteriously smashed values. Or those might no longer be visible either because a return address may have been overwritten, causing the main program to take a wild branch."
As I am not well-versed in C++, I'm interested in knowing about these things. Perhaps it will give me a reason to seriously look at the language.
And if you mean for start_do_something(arg1, arg2) to be a function that creates a thread, then you're just passing the buck. What's the code for that function?
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
No it's an index not an offset. Unless you're talking about byte arrays.
I've been paid well to write tens or even hundreds of thousands of lines of code in C++ and Java. I've had reason to mess with Python and JavaScript and I enjoyed it. I keep wanting to get into languages like Haskell and Scala because they remind me of the research I did in graduate school thirty years ago on languages and operating systems for Fifth Generation architectures (yes, I _am_ that old). But you know what language has been the most profitable for me by far over my forty year career? C. Most of the work I do is either down close to bare metal (device drivers, kernel hacking, embedded systems), or else deep in software stacks in multimillion line code bases, and it's all in C, for better or worse. C is the structured assembly language we all wanted back when the microprocessor was first invented. There's this huge world of embedded systems, digital control, real-time, that is growing by leaps and bounds as everything we manufacturer has some kind of microcontroller or microprocessor in it, and the vast vast bulk of software built for those products is in C. I really, strongly, loudly encourage people to work as high on the abstraction ladder as they can, for two reasons: [1] it's a cost issue for the product development organization, and [2] the less other developers understand the low level stuff, the more money I'll make. I appreciate that the Eloi working on big servers, laptops, and even mobile devices, need to use as high a level language as possible. But down here among the Morlocks, it's a different world.
Your boasting about your ignorance is well taken.
Yes, I did. All I left out was the #include and the defining of local_var1, local_var2, and do_something() (because the whole point is that they're whatever the programmer wants them to be). Everything else is included. I even included "std::" rather than assuming "using namespace std;".
First off, there's nothing "compressed" about that, if by compressed you mean obfuscated. Any person who knows even rudimentary C++11 will understand that code right away. Secondly, all it means is "Run do_something with two local arguments in a thread and detach it". What fundamentally different approach are you envisioning for C++ that makes it no longer desirable to run functions in threads?
Says the person who doesn't even understand simple C++11 code yet feels compelled to rant about how horrible C++11 is compared to C.
Saying "Use C++ without STL" is like saying "use C without the standard C libraries". It's an idiotic request. Secondly, "bloated"? Go benchmark qsort vs. std::sort and then come back here and tell me about how "slow" C++ is (hint: as is true in most cases, the STL version is faster; templates allow the compiler to do optimizations impossible on C generics)
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
It's *their* example. And you can build a kernel with whatever language, compiler and libraries you want - all that matters is what assembled machine code comes out of it. And the whole point of standardized libraries is to prevent bugs. Having everyone reinvent the wheel is asking for bugs. When a few tens of millions of people use, say, std::vector for a couple decades, you kind of expect the bugs to be worked out.
"We consider that six courts and an asylum claim are a rather odd way of returning to Sweden within a month."
We're talking about C. You want the zeroeth post.
You have to remember, there are two kinds of people in the world: 1) Those who begin their indexes at 1. -and- 1) Those who begin their indexes at 0.
I programmed in APL, a most wonderful language. For each function, you could specify the index origin to be used. ([]IO was set to 1 or 0, as you wished). You could be in the same function with index origin 0 and later with it set to one.
it isn't PL1
Go to Heaven for the climate, Hell for the company -- Mark Twain
Teach your kids to drive manual transmissions, this will give them a better understanding of what is going on in their engine. Then they can drive nearly any car on the market and they will have more respect for their machines. Teach a programmer a compiled language like C, a scripting language like Perl and something with objects, C++ or Java come to mind. Then they can handle most languages except the really low ones, Assembly language. All they need to do is learn the syntax and apply what they have learned. C is still relevant and so is Perl even though I have been hearing for years that Perl is dying. The programmers graduating now lack much of the fundamental knowledge. They rely on their environment to do most of the syntax for them. They are not as good at debugging unless it is obvious and their tools spoon feed it to them. Many have never used a command line.
Karma, We don't need no stinkin' karma!