There’s been a meme going around the open source community for a while now. That programming in C is somehow dirty, distasteful and worst-of-all inefficient compared to programming in a high-level language such as C# or Python.
Its detractors will tell you how it takes much longer it takes to program anything in C. They’ll point at how much C code it takes to do something as simple as create a GObject sub-class compared to the equivalent in Python or C#. They’ll also probably complain that everything in C has to be compiled first, which takes even more time up.
No argument would be complete without them pointing out that C has no standard types for strings, let alone linked lists, binary trees, associative arrays, etc. and that you have to spend all that time implementing your own. They’ll probably make a point about how C’s static type system means that even if you have a array type, you need to know in advance what types you’re going to put into it and can’t just mix and match.
Don’t feel tempted at this point to counter with a discussion about how great and flexible pointers are. You’ll receive a lashing about how they’re even more evil than people who talk in the theatre. The rant about the C problems of uninitialised memory, out of bounds pointer errors and segmentation faults is a timeless classic. Especially when they get to the bit about how much time was lost debugging them.
And do you know what?
I simply do not agree with them.
I cannot think of a single project where the majority of time was wasted writing GObject header files compared to the single line of Python I needed. I can think of lots where I’ve sat for hours trying to figure out which class I needed to derive from, or reworking the code after I realised I derived from the wrong class to begin with. The high-level language doesn’t make this any easier.
As to the number of projects where I’ve needed to write a linked list or hash table implementation because C lacked a convenient dynamic array or associative array type like Python? If it takes you any time to write that kind of code, you’re doing it wrong. I’ve spent far more time realising that the structure is a performance bottleneck, and planning on the whiteboard a faster alternative. Neither language helps with this whiteboard time.
And all those pointer issues? This comes down to the tools that you’re using. If you’re writing in a language and not using its development environment properly, then it’s little surprise that you’re not being as efficient in it. gdb, valgrind, gprof and gcov are your friends. Use them well. I’ve spent just as much time dealing with other language-specific issues to make me believe that pointers aren’t any more evil as (for example) monkey patching.
The vast majority of my time on any new project is first of all spent thinking, and on a more mature project its figuring out what I did wrong and how I need to rework it.
Yes, the next biggest use of my time is working out what the best way is to express that. If I’m writing in C, that means I’m deciding whether it needs a linked list, or a hash table, or some other fancy structure. But if I’m writing in Python, believe me I spend just as much time normalising my class structure and coming up with all sorts of insane Pythonic ways of doing things.
If you’ve ever written in Perl and not lost a day or two to optimising your regular expressions, or eliminating code to arrive at the shortest possible expression, you’ve never written in Perl.
Refactoring takes you just as long in Python as it does in C. Just because when you do it to C code you end up setting segfaults doesn’t mean that when you do it to Python code, suddenly your class structures don’t match anymore.
Proponents of test-driven-development, AGILE, LEAN and ANEMIC programming methodologies will probably argue that it’s easier to practice their religion with a high-level language. I’m not buying that either, I’ve managed to write several large software projects in C that have a comprehensive test suite – including testing for allocation failures.
Ah, Rapid Application Development I hear you say? Well, the only people I’ve ever heard say how great RAD is are people who’ve never had to support the software that was written rapidly, or debug issues with it years later. RAD is great when v2 is going to be a complete rewrite, and v3 a complete rewrite again. Very few websites have upgrades without announcing a completely new codebase.
It’s certainly true that it’s faster to mash up some code in a high-level language. I use shell scripts and bits of Perl for this kind of thing all the time, and I frequently even do basic mock-ups or essays in Python. But ultimately it all tends to be throw-away code, that I don’t really ever intend to take seriously or attempt to support later on.
For larger projects, I just don’t see any difference in the time it takes to write.
I’d like to cite an example. The GIT and Bzr revision control systems are about the same age, one of them is written in C and one of them is written in Python. It hasn’t taken them any less time to write the one in Python than it’s taken the others to write the other in C. The one in Python doesn’t have extraordinary features that the one in C lacks.
C# fans would point out how much faster it is to UI code. Really? Then why isn’t Banshee that much dazzingly better than Rhythmbox? Sure they’re different, but there’s nothing there that suggests one language is better than the other.
And do you know what? I trust code written in C far more than I do any higher level language. No, that’s probably not fair. I trust C programmers far more than I do programmers of other languages. If you tell me I have the option of choosing a program or library written in C over one written in Python or C#, I’ll take the C one every time.
The fallacy of your fallacy:
git was written in C only in the core, perl and bash has been used to create tools faster, and only now they are taking the time to port that to C, slowly.
For that matter, Mercurial is also as old as git, and it’s be much easier to focus on things like CLI consistency, portability and good documentation than git even with a smaller community.
On the other hand, you are missing another point, which is, how much effort, experience and knowledge does it gets to get into speed to write plain GObject and to write PyGtk.
Most people using C avoid GObject inheritance when they write their code, this is not the case for higher level languages.
So yeah, once you got all the knowledge and experience and feel comfortable with the language/apip, the language becomes irrelevant, but that’s exactly the point, is how steep the learning curve to generate good quality code and be able to focus on the problem you are solving what makes the difference here.
According to wikipedia Rhythmbox initial release was in 2001, while Banshee’s in 2005. How come they’re fair ? (well, in my view Banshee is ahead)
C has advantages, but also has Python.
The bigger problem with C is the high barrier entry, and that’s not something solveable by claiming which kind programmers you trust more.
I don’t know why I’m responding to this, but…
1) Your arguments are mostly against Python, so it’s funny that you toss in C#.
2) I’m not entirely sure why you think C#’s chief advantage is in UI coding. The only syntactic advantage C# gives you for UI coding is the event stuff, which is of course great, but unless you’re a Winforms developer in Visual Studio, I don’t think C# makes you a UI-creating speed demon. This seems like a kind of odd straw man for you to have set up, especially because…
3) Banshee’s UI is insanely better than Rhythmbox’s, mostly in subtle ways that you may not pick up from screen shots. There are beautiful animations all over the place that add a great tactile feel to it. I’d recommend playing more with it.
That being said, I trust developers over languages. Banshee’s UI is as impressive as it is because of the attention of Aaron, Gabriel, and others. You’d have to ask them if C# enabled them to achieve this, but looking at the Banshee codebase I would guess that the chief wins provided by C# are at lower levels in the Banshee stack.
I guess I’m just left wondering what the point of your post is. You dislike Python and C# programmers for their claims of superiority…that makes sense. Then you turn around and do the same thing? You defend C well, and I don’t disagree that C is still a fine language to use, but you have no defense at all of your bias against higher-level languages.
Cheers.
This is pretty classic good programmer vs bad programmer stuff. There’s way more software to be written than there are good programmers to write it, so you’ll have to put up with higher level things existing.
Some of us bad programmers actually quite like the high level experience. Sure I enjoyed the day when I finally figured out pointers in C, but I’m never going to be good enough to use them in any significant way, so I’ll stick to a language that’s much harder to make explode, and be as useful as I can. You’re entirely welcome to stick to gcc and writing your crazy magic
maybe you should have a look at vala, I don’t write C code anymore purely because its not fun anymore. especially the GObject header stuff. vala tends to solve that (and many more issues that C brings up) and compiles down into native C.
Its not about using python because you can magically make better programs with it, its about using python/somethingelse because its more enjoyable to code in, and thus less of a pain, at least for me anyway.
So in summary, you like C. So what?
I think the problem is you’re forgetting your business requirements. In the modern world, where people use high level languages like C# and such, the business requirements differ from the open source or hobbies world. Your business requirements, as you see them, is to develop a perfectly maintainable, perfectly designed peice of code that can survive the trials of time without requiring any rearchetectures.
In the business world, arguably the world that drives out these high level languages, the requirement is to get it done so you can move onto the next business requirement. Get it with the PROPER balance of quick and well archetectured so that it survives as long as you need it to, but no longer. The goal is to maximize profit, not technological perfection.
If you see anything WRONG with different parties having different goals, then you’re never going to be happy with this.
You also forgot to mention: structured exception handling, reflection, runtime dynamic code generation. These are tools which Do Not Exist in C, and, at the expense of CPU cycles, CAN speed up your development. And it’s worth it. People cost more than CPUs.
Too add onto the point about people costing more than CPUs. People who can develop C code securely, quickly, and properly are FAR more expensive than those who can develop C# code. There is a reason for this. The barrier of entry *is* lower. The amount of knowledge required about the domain in order to produce a useful product *is* lower. If it wasn’t lower, the economics would not be as they are.
I agree to some part… To me, C++ code just appear more “robust” than some flimsy Python code. In the first case, somebody has spent much time lovingly carving his thoughts into stone, chipping a bit here and there, examining the whole thing and its parts many times; while in the latter case someone has taken some clay and thrown it into shape, quickly and hurriedly – nothing I’d trust to hold for long.
But for trying some idea or getting some task done quickly, I still prefer Python. In those cases, I really don’t want to bother with the tools, but want to implement my ideas in the quickest, most flexible way. No time to write some container class first, maybe not even time to ponder about the performance differences between hash and list. If the idea is good but the clay too weak, I can still go and replace some parts with solid stone; but in most cases, that’s not even necessary.
The other point where Python really shines for me is the readability. I have looked into many existing Python projects so far and successfully made changes (hence, understood the code at least partially), and it’s just fun. With C++, not so much; and with C even less… Jump into the code, fiddle with some promising part, and be rewarded when starting the app: much faster in non-compiled languages, and much faster if the actual logic is not buried within lots of boilerplate code.
oliver pretty much summed everything I wanted to say. I will admit Python can be more fun that C++ at times because, yeah, it is quicker, but there is something about C++ that really makes me enjoy it. Is it the pointers? could be. Maybe the const…ya, that could be it
const int*const Method3(const int*const&)const;
I agree with you for the most part. I enjoy programming in C but it’s not perfect, just like every other language isn’t perfect. I think different languages all have their places. But when I stop and think about the number of times that linked lists, hash tables, etc. must have been reimplemented in C it boggles my brain. I think if there were simple, efficient, standard versions of these data structures available across the board (i.e. standard everywhere C might be used, not just in GNOME, for example, and not hindered by restrictive licensing), then it would be easier to write the cement code between libs.
On the upside, I like where projects like Rusty Russell’s CCAN project (http://ccan.ozlabs.org/ ) are going. I’ve started looking in that direction for snippets to use instead of reimplementing them and I think the project has the potential to make C coders lives a little bit easier. It’s still young yet, though.
C programmers have more respect for CPU & memory constraints. I’m basing that on it being a nice, lean language, and the others being um..ginormous. So it took *you* less time to write, but it’s going to make my not-even-1-year-old laptop run like dog? Well that’s great! For you. For me, it sucks.
You mentioned git v. bzr. Do a commit on the kernel, which is huge, in gt. How long does it take? 20 seconds? Now do a commit on something small, like seahorse-plugins, in bzr. How long did that take? Dunno, I’m still waiting for it to finish…
This argument is like saying saws are bad because they are sharp; hammers are better. Use the tools you need to do the job. This is basically a religious argument.
I think I shall stand on the side of the higher level languages here. Specifically, the scripting languages. C# and Java don’t really count.
I love Perl for the flexibility of the language, and CPAN.
Ruby works because of the flexibility of the language.
I have dealt with C++ projects which were clean, and others which were terribly ugly.
Object orientation is far more than being able to create new types/classes and inherit from them (or compose instead). OOP to me has it’s primary benefits in encapsulation. Encapsulate a concept, and then use that encapsulated representation. Design Patterns are encapsulation too.
C is good for when I either need the raw performance, or when no other language will do for the problem.
I know my data structures well enough to be able to implement them if I need to, but I would rather use a library of well tested implementations of those (and the algorithms used when dealing with them).
I don’t spend days in tuning regular expressions, I make sure that my code is correct, and then move on to more important things until there is an actual performance problem and the profiler indicates it’s in that bit of code.
Agile development makes sense as a fast-feedback-loop mechanism. So does TDD. Use them when appropriate.
I don’t hate C. I just have very little need to use it directly.
I don’t trust programmers of any sort, including myself. I might trust you if you have earned a reputation for writing good code over the years. And in that case, your language of choice does not matter.
“The one in Python doesn’t have extraordinary features that the one in C lacks.”
It’s true you can accomplish the same task in a low level language as you can in a higher level language. I think the major difference is the expressive power of one language over the other. I don’t think you would argue that assembly is more powerful ( expressive ) than C. You could in fact write git or Bzr in assembly and have the exact feature set. The difference in a higher level language ( Which C is, in comparison to assembly ) is the ability to imprint more meaning into your code, aka making your code more expressive to it’s function. For instance you can use high order functions in C to express the visitor pattern thus making some complex abstractions work well together. This is just not the case for assembly. In the same way other High level languages ( take your pick ) might have support for closures. This language feature allows for even *more* complex abstractions to occur that helps encode even more expressive intent into your code.
Without righting an entire book on the subject. I guess my summarized point is this. A truly high level language should allow you to imprint more of the software intent into the program and should allow you to do this very simply there by simplifying a complex program. This is probably more useful in non GUI applications where the majority of computations are non-simplistic. ( such as in enterprise processing software ) A great read on the benefits of high level languages ( and lisp ) is from Paul Graham http://www.paulgraham.com/avg.html
Nicely written piece.
I am not sure what your point is, though. It seems to be “C is good for something, high-level language have no intrinsic superiority, you can write crap in any language, and I prefer libraries written in C”.
“C is good for something”, is hard to disagree with.
“High-level languages have no intrinsic superiority” is kind of a flamebait. They are intrinsically more expressive. The question is whether this expressiveness is worth the trade-offs for a given project.
“You can write crap in any language” is universal wisdom.
“I prefer libraries in C” is thought-provoking. In my opinion, C makes it painful to manage complexity, so it pushes the programmer towards simplicity. This design pressure tends to produce good libraries.
I’d rather spend two years writing a version control system/music player than spend two years writing a version control system/music player AND also writing lots of tedious memory-management crap, copying around GObject boilerplate, etc. Maybe the end result of the *program* is going to be the same, but the end result for the *programmer* won’t be.
Funny that you compare Banshee and Rhythmbox.
I guess given that Banshee is years younger, you have to give the guys some credit here.
The UI is superior already, there is better support for various devices and (very important) wanted features get added in a timely manner.
So, it seems to be far easier to pick up C# and then the Banshee code-base, than it is to pick up C and Rhythmbox.
While I personally would love to see more “native” programs, I think C is getting old.
Maybe at this point GNOME should start to focus on D as a low-level language.
Well, there are multiple parts to all this. Saying “C is better than high level” is like saying “Hammers better tools than paintbrushes”. They sure are, until you have to paint that bikeshed. Python regularly gives me the pain of running into funny implementation limitations, but I am less than sure that it is anything but the way higher-level languages are currently implemented that is at fault.
One thing is implementation of certain idioms (good old “the-program-with-the-least-for-loops-is-the-fastest”-Matlab days). Another thing is that the modules in the standard libraries are all half-baken quickly-implemented hacks for a specific problem that wrongfully claim to be generic. Want to send a quick mail from some python app? Sure, all those email modules are for you. Want to do something with mail in particular? Better stay far, far away from them.
I disagree. Most of the problems you identify with higher-level languages are ones of program design, which apply equally to all languages, C included. That doesn’t deal to the fact that while C’s low-level nature makes it suitable for a lot of problems where Java/C#/Python would be unsuited, it also requires the coder to keep track of things that are unnecessary in those languages. Yes, tools like valgrind are extremely useful for C coding, but they’re also unnecessary when application code isn’t responsible for managing memory.
Not meaning to criticise C as a language, just pointing out that like any language, it has strengths and weaknesses. It’s probably the perfect language for infrastructure coding – for kernels, system libraries and utilities. But the cost of that is that it makes the coder deal with stuff that has little do do with what they’re trying to achieve. For writing large applications, I’d much rather be working in C# or Java. Or Python, but I tend to prefer that for smaller, simpler projects.
KDE developer here; vala actually looks good to me.
If you realize it or not, you Gnome hackers are in a pretty good position to be the first big project to mainly use D. You have all the “high-level” libraries in C (to which D is compatible) and overall there seems to be hardly anything which D doesn’t do better than C++ (which I would still choose over C…).
Also, in my experience, there is a lot of good software out there written in Python. You just need to test the hell out of it if it’s supposed to be a stable product for others to use.
The majority of advantages you arise in favor of C against Python, are not valid against C#. And the majority of disadvantages you arise about Python, are not valid in C# either. So I think you should learn a bit more about static languages like C# (or other ones that Mono supports) before putting them in the same box as Python.
The bottom line is that I agree with you in some arguments, but not in others. In my opinion you should try C#, as it’s the best of both worlds between Python and C (especially now that C# 3.0 has “var” and is less verbose, in order not to disappoint devs that come from the dynamic world).
I agree 100%. Not to mention that C does _everything_, down to good integration with assembly.
+1 for C++ from me.
Every language has its advantages and disadvantages (except for Perl, which has only disadvantages
), and choosing a language is only part of software engineering. It’s all about just using the language that you feels comfortable with.
Banshee First Release – 02/17/2005
Rhythmbox First Release – 07/18/2001
The fact that Banshee is already on par with Rhythmbox at all is quite evidence enough to suggest that what you are saying does not always ring true. Also, be fair to the mono guys, none of them are idiots, especially the Banshee team. That idiot who wrote Docky however… moron…
I am inclined to agree. I am always interested in the language a program is written in, and whenever I install and run a new program I attempt to guess what language the program is written in based on how well the program is designed and if there are any problems with it.
To my surprise, much of the time, I find programs written in python to be the biggest culprits when it comes to causing random problems and poorly designed interfaces, and ones written in C to be solid applications that provide very useful interfaces.
I haven’t done any scientifically rigorous tests, but as a conservative estimate I would say I am now correct in my guess of the language used in at least 70% of cases (guessing out of C, C++, and python), just by judging the quality of the program. I hear people’s arguments that the quality of the program should have nothing to do with the language, but in my experience there is a statistically significant correlation between the language used and the quality of a program.
My hunch is that because C takes longer to write in the initial phase of development, people are forced to spend a little more time thinking about how their program is written. I think this extra time pays off in the long run.
Git wasn’t originally written in C. It was written in C, perl, and shell scripting.
So you might as well get it right. Over time as the design stabilized and improved then they replaced much of it with C.
If you look at complex projects like Samba4 well over half of the code is automatically generated. Either as language bindings for Python or as C code automatically generated from protocol description files.
The C-for-everything attitude yeilds crap like Evolution.. which is virtually unmaintained and long-standing bugs like #336076, which has exist for 3 years now and counting and makes evolution virtually unusable by anybody with moderately large IMAP folders and is going to cause probably unholy hell when people try to use it with their Exchange accounts thanks with the MAPI plugins. Its a bad design solidified in a low-level language and thus far nobody has even attempted to fix it.
The lesson here is that you use C when it is appropriate and you use other languages when they are appropriate. Not everybody is interesting in application programming libraries.
You make it seem like C is the perfect language for all things, and that people are arguing with you that C# or Python is the perfect language for all things. I would say that both you and those people are trying to use a hammer to screw in a screw. Different languages are useful in different situations.
I think the real value of C in our platform stack is the ability to bind it to other languages. I wouldn’t develop a platform library in Python or C#. But if I was starting a new application the size of Evolution, I sure as hell wouldn’t choose to write it in C either.
I’ve written gtk app code in C, and I know how to do it. I’ve also written a lot of it in C#, and for me it was quite a bit faster. Not so much the design and writing of the code itself.. that’s a little faster, sure, but typing the code in is not the biggest bottleneck in the development. It’s because what I worked on was a collaborative project with other people and we were all constantly reading one another’s code. As the design gets more complicated, the more expressive your language is the more obvious your code will be to other people reading it (assuming they’re familiar with the language, of course.. I’m learning Haskell right now but I would still be terribly inefficient at reading a large complicated piece of Haskell code and understanding it at this point). In something like C# or Ruby or Python you’re probably going to have to do a lot less scrolling around in your editor just because the language is a little more concise. You can just parse it much more quickly. You can spot design errors more quickly when you’re reviewing other people’s code. You can spot more serious errors more quickly. When you’re reviewing C code you have to watch for the same stuff, but you also have to watch for memory leaks and pointer errors and other stuff.
Maybe you write flawless C code the first time, but I’m learning that most people don’t. For my new job I’ve been recently looking through C code in a lot of open source Gnome projects other than gtk+ (which is what I’m most familiar with), and I’m seeing memory leaks all over the place. Sometimes they’re in apps that you probably only open for a few minutes, and sometimes they’re in apps that usually stay open for your entire desktop session.
I guess my point after all this is that I’m not as trusting of C developers as you are.
You had this discussion when machine code was being replaced by assemblers, when assemblers were being replaced by C and when C was being replaced by C++. Every time you heard things like “those newfangled compilers hide away all the important stuff” and “those new languages can’t do anything i can’t do in {insert old technology here}”
I believe you when you say you’re more productive in C, getting productive in a language takes time and investment learning that language. I used to do C and C++ and now I use Python and C#, I made the investment and I’m far more productive in those “newfangled” languages.
I’ve had many of the same thoughts in my head for a while, and I’m the maintainer of one of the projects you mention. I figured maybe I was just rationalising, so it’s good to see someone else with the same ideas.
One difference I’ve noticed is that patches I get from inexperienced programmers tend to need more review and refinement when they’re in C compared to Python.
Use the right tool for the right job.
I often write Python scripts for parsing files, strings, manipulating network objects, etc. Claiming that I could do the same in C just as easily is simply wrong. C just lacks a lot of concepts which make system integration, string parsing, or working with complex data structures a pain, such as OO, exception handling, and automatic memory management. And unlike you seem to claim, more abstract data types than char[] and int are not a luxury, but an incredibly important concept if you want to think about real algorithms instead of nudging bits and bytes around.
I don’t say that everything should be written in a scripting language. Things which talk to the hardware, need to be super-fast, don’t need to be robust, or don’t need to work with a lot of data structures on their own (such as cobbling together some glib/gtk calls for a small GUI app) are just fine to write in C. I just object to generalizing “Higher level languages don’t work for your project” to “Higher level languages are useless”.
So what you’re basically saying is that you suck at writing software in dynamic languages. So – by all means – please don’t.
If you intentionally write mockup code to be throwaway-ware, you better throw it away.
If you don’t put the same care and attention that you invest into C-Code to writing python/perl/ruby/c#/java-Code, I’m not surprised you’re unpleased with the results.
But the real fallacy in place seems to be: “I like my C-Code better than my Python-Code => therefor Python must stink.”
Google just started a project to make Python more usable over C. Especially in the question of Performance.
http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
But for what you wrote about C#, I must strongly disagree. And as Mike already said. Isn’t banshee a great proof of actually the opposite you said? I mean the software is much younger and already in a impressive state. And doesn’t make you wonder that so many cool apps (MonoDevelop, Gnome Do, F-Spot, just to name some) are written in C#? Are all those devs just not smart enough to see the elegance and beauty of plain C?
You made me smile.
You could not have said it better.
There is a reason why the core of any UNIX-like system is still written in, and only in, C.
Thank you for this. Made my day.
Just to clarify in reply to a couple of people’s comments:
I’m not saying that I think C is better than your choice-of-language, I’m simply disagreeing with those people who argue that their choice-of-language is better than C, or somehow makes them a better or more efficient programmer.
I think you should program in whatever language you enjoy the most, and find yourself most productive in. As I say in the post, I tend to write scratch code in things like Shell and Python; do occasional mock-ups in Python; and full versions in C later.
And I do adore C#, I sadly just don’t get enough chance to write things in it
Yes… it’s a fallacy that people develop awesome apps for Windows in C#, for OS X in ObjC, for KDE in C++… developing in C for Gnome is so productive, just look how many awesome apps we have for it.
When I need a program to do something, I usually look up what’s available on Freshmeat. The first thing I check is in what language the program was written. If it’s written in any language that’s does not pre-compile to native machine code it goes swiftly from my mind to /dev/null. Simple as that. Desktop apps written in interpreted languages (or even worse bytecode languages) are totally unacceptable. Second I check if it requires bindings of any kind, if it does -> /dev/null. If it uses WxWidgets or any other kind of other portability crap -> /dev/null.
Good day,
Pingback: High-level vs Low-level programming « Balau
Compare GIT and Mercurial, GIT has many more LOC and doesn’t support windows well, even though they have a ton more programers than Mercurial. Now compare Rythmbox and Listen, Listen was made by 2 or 3 people in python and had all features rythmbox had and many more, I think the project is dead now, but still. I think you could do a better job of selecting your cases and actually choose a c program that was better than a high level language one, but it still doesn’t prove anything. The fact that gnome has this braindead idea that it should only use C official is what is making the project go so slowly, it was able to stay one of the best desktop systems on linux just because its competition is also made in C and C++.
So essentially you are saying C is the most efficient language in the world or you are arguing there is no difference whatsoever between the efficiency of different (mainstream) languages when it comes to typing out production code?
I’m sorry but I strongly disagree without expressing preference for any one language but surely there must be an entirely objective difference between languages. Now I do think that your own expertise in one language over another will make you more effecient there for that reason alone however.
You can claim whatever you want, but the numbers are clear: people are more productive in high level languages. A nice starting point: http://barnesc.blogspot.com/2006/05/programming-language-productivity.html
Absolutely, unequivocably agree with everything in this post. Nothing to add.
If you haven’t written anything over 1kloc in SML, OCaml, or Haskell, don’t come to me and claim that high-level languages are baloney.
C is fast, I grant you that, but OCaml can be fast too, but usually not as fast. Haskell can sometimes be fast but idiomatically it won’t be. That said, code written in OCaml or Haskell that actually compiles and is written in an idiomatic style will have way less shallow bugs than code written in C,C++,C#,Java,Perl,Python,PHP,Ruby.
Why? Because the static type checker did a heck of a lot of work to ensure that your program checks out. Even if your program does fail it will probably fail in a way where you can at least figure out why without sifting through a core dump.
* Static Type Checking done right (not wrong like C and C++ which allow random coercions, casts and void pointers) reduces shallow bugs
* No language can prevent you from screwing up and failing to describe your problem appropriately, at least some languages can at least check if your description at least makes sense to the compiler.
Awesome article! One thing I also like about C and C++ are segmentation faults. I’m dead serious. When there is a problem, I fix it. Core dumps, or simply having your debugger halt is priceless. In other languages, these things don’t happen. The same errors are still there. But the software keeps running. Until it becomes unresponsive. Or the exceptions just get too numerous. But the software is unusable because the data is corrupted by this point.
I’ll take a seg fault any day over interpreted languages.
Those other languages are becomming popular because the noob programmer doesn’t get frustrated that their software suddenly crashes. The suits at Sun made sure that Java did not do this. Now it’s the default behaviour in all new languages.
@j not really, the xnu kernel contains C++.
We already decided to go with the slower, more productive language (asm -> C). We’ve now increased our personal computing capacity way, way in excess of when that decision was made… what is the reason we now don’t give a crap about productivity (development time, portability, maintainability, higher order reasoning) and only care about miniscule speed improvements?
How much time has been wasted on memory issues? Why does the compiler allow incorrect code? I think we may also start hearing “but does it scale?” asked of C as well, given how painful shared state multithreading has proven to be.
http://www.panix.com/~mbac/safety.html
Pingback: Pinderkent: Higher-level languages aren't about making experts more productive. They're about allowing average programmers to do the otherwise impossible.
so true … especially the part about trusting C programmers
still though if you -> use perl;
you get the best of all three worlds:
- trust (olde tyme hackers and smart people wrote perl and it’s been battle tested))
- respect (perl requires as much dedication as C to write well … unlike ruby and python which are too easy)
- high level-ishness plus c (you can convert perl to c easily if you need)
You seem to be addressing two issues here:
1) C as a language is as good as any other language
2) The lack of available standard libraries in C is not a barrier to entry, because it’s easy to write your own.
C is a fine language. Pointers are awesome. Dealing with your own memory allocation is the job of any responsible programmer, anyone who disagrees simply hasn’t tried to run a 8GB Java VM and then cried when their VM spends 90% of CPU cycles doing garbage collection. If you can’t hack pointers, please for the sake of humanity, stop programming and become an artist. I have come across so much code written by idiots that didn’t understand memory allocation it makes we want to change careers regularly. It’s like being a graphic designer and coming into a job where the CEO’s five year old did the corporate branding, and they ask you to ‘just work with it’. It’s just impossible and horrible. Debugging C is no slower than debugging anything else, in fact I would argue that it is FASTER. Static typing is your friend, not your enemy. The compiler catches things that are stupid before you even run them. If the compiler can catch them, then so can your IDE, which means they are pointed out to you the second after you wrote them, not six months later when someone finally runs that code because QA didn’t catch it.
Compilers are slow? really? Ever worked in Java that isn’t crippled by make and other stupid OSS build tools (can anyone really argue that automake/autotools aren’t the uggliest thing ever) that compile every file in a separate process? I think my 20,000 line Java project compiles in less than five seconds. Last time I compile C++, it was about the same size and took around 20 minutes (though that was awhile ago).
let’s face it though, Object Oriented is a useful paradigm, and C just can’t do it. For goodness sake, if you are going to pick a language like C, pick C++ or Objective C. It might have flaws, but you do at least get inheritance which is a very useful concept.
Debugging someone else’s Perl is a living nightmare. Ever try to find memory leaks in mod_perl? *shiver*
As for libraries. I can’t believe you actually have a job working for a business. It has taken years to come up with the optimal implementations we have in modern libraries today. You can’t just sit down on the weekend and recode these things in five minutes. Ever tried to implement a library to read a PDF? It takes a week just to read and understand the spec. Why bother installing somebody else’s operating system, after all, it’s just a bunch of libraries, surely you could hack together your own in a weekend? Seriously? Have you thought about that for more than two seconds?
I work in Java. For ONE single reason. Libraries. I have access to a massive collection of high quality object oriented libraries that make developing new web based applications a piece of cake and have largely been standardized around. It means my employer doesn’t have to pay me a year’s salary to re-implement the wheel.
Java has one major problem, the garbage collector (We’ll just ignore the fact that Sun spent the first 10 years making a hash of it, and coming up with embarrassing UI implementations). Syntactically it’s pretty similar to C++. It’s statically typed, and better yet it avoids the pain of multiple inheritance. The Java world seems to have a good number of mature programmers, who understand that dependency injection is a useful thing, and that testing is good, and that you need an ORM tool that doesn’t suck if you are going to be successful building Enterprise software. Perl doesn’t have a good ORM tool, Python doesn’t have one (a bunch of smart people implemented Zope DB, which is a great idea, but horribly impractical, and the implementation is so lacking in basic tools, it’s embarrassing), and neither does PHP (DBO is a joke), and I don’t remember reading much about database access tools in C lately – though that maybe because I’m just not in that community. The people who work in languages like Python and Perl are really far behind the curve, and frankly, too busy implementing mostly pointless libraries to catch up. PHP comes out of the box with zero connection pooling for MySQL that works. I mean can anyone argue that that ISN’T stupid?
If you are a typical Canonical employee, we can see why Linux is so far behind OS X, and will probably never catch up.
If I were the people who wrote most of the libraries underpinning what Canonical do, I would be calling for your head on a platter based on your comments. You are calling these peoples work trivial.
I have to say its funny to see this appear again. As someone mentioned it comes up everytime theres a “new” language on the horizon. I remember well the ASM vs C argument, and back then when it all kicked off, ASM was still better, the code generation of C was terrible and you could write much “better” code in ASM then “C” anyday. These days “C” is pretty close to ASM, so much so you’re sometimes hard pressed to beat it (particually with CPUs being so damn complex now).
C# (my language of choice these days) has the same issues C had in the old days, its quite a bit slower than C, and actually takes a long time to learn properly. I’ve spent 2 or 3 years coding in C# now and I’m pretty good at knowing whats good and bad about it, but I still get surprised sometimes at just how bad the JIT can be in places. I think new programers are more productive in C# because a lot of grunt work is done for them, but you need some experiance with the langauge to get the best out of it, and even then I’ll spend just as long trying to optimise it that I did C or even ASM in some respects. I realise the JIT is still evolving but it sucks in some important places. However, the bit I really like about it is that long after my program has finished and shipped, it’ll still be getting optimised and faster as M$ or the Mono guys keep updating the JIT – and I’ll never have to lift a finger.
That said, I do still get dirty with pointers in C# for real speed ups, but that doesn’t effect the JIT just memory management, and managed memory is great for the little things, but sucks when you need to manage important data. Although again this will improve.
I guess what I’m trying to say is that we’ve seen this all before. A new language comes along as we don’t want to have. Its slower than what we’re used to, we can’t find the functions we need in the librarys so we’re more productive “the way we were”. However eventually the compilers (and JIT) will improve and speed will be comparable, and we’ll get enough experiance with it that we’ll finally make the switch. I’m not a bit python fan, but I love C#. The lack of header files along is a godsend, not to mention the rapid build times. Sure theres times where I still want to drop down into assembler and even the C# guys recognise this by allowing you to plug in native DLL’s so you don’t lose out completely.
Give it time… new languages are always hard swap over to, you have to be convinced that they work as well as your current choice, but it’ll happen eventually.
I often hear an argument that “higher-level” languages and massive standard libraries / frameworks keep you from reinventing the wheel or waisting time repeating your code. Typically, its from people who implement software that has a well-known solution with mechanisms that can be reused from implementation to implementation. Programmers who write this kind of software see the same problems over and over and don’t want to solve the same problem twice. They let other people create faster databases, better data structures, and more useful platforms for them to build on top of. This saves a lot of time and effort and allows everyone who needs a solution to share in developing it and debugging it.
For those of us implementing novel solutions that have not been explored before, choosing the best cookie-cutter library is not a very important part of the job. Most of our time is spent drawing up solutions on white-boards and writing algorithms and data structures that have just the right performance and memory characteristic. When there is a library that does what I need, I usually end up plugging it in as a prototype to get my system functioning and then throw it out and replace it with my own after I pair down which features I actually use from it and which ones are causing it to be overcomplicated.
In response to the comment about libraries, C has the most comprehensive set of libraries available to it, hands-down. Sure, the standard libraries on a system are very minimal but a C compiler can link with libraries spanning across 30+ years from FORTRAN, C, and C++, or anything else that compiles to your system’s library format. Venerable libraries such as ARPACK and LINPACK are common examples.
I concur that run-time systems like Microsoft’s CLI and more expressive languages such as python make the task of programming easier. But when the simple task of writing out the program is not your greatest challenge, you just don’t care about those extra convenient features provided by more complicated systems. They may only give you the extra complication and none of the advantages.
I decided to put in my 2 cents because I see a lot of web developers and application developers who think that’s all anyone ever writes. Contrarily, there are a lot of developers working on custom embedded systems, new hardware, scientific simulation, development tools, and high-performance libraries who would see things very differently.
the fundamental flaw i have with this post is that the author appears to conclude choice of language is a valid way to judge or infer programmer capability. there are many flaws with this logic i could point to. but i’ll keep it brief. i’d put language choice as one of the lesser, near useless indicators of capability. near the top would be testing habits (rigorous unit test experience and peer-reviewed unit test condition/results walk-throughs); ability/experience in getting to clear requirements and functional designs; and naturally also standard measures of logical capability and symbolic transformations.
the most valuable part of the post was laying out the various pros and cons for when any given project might lean toward one language versus the other. and this was largely evident via the comments. the conclusion of the op to me is utterly useless.
I happen to have written a very similar essay (click through my name, I think).
The key element is the fact that most of the time that you spend on your project is not spent churning out repetitive code that benefits from a bunch of language features. Most of the code that you write is not this sort of repetitive code either. The important decisions influence the structure of your program and are language-neutral. If you make these decisions well, your program will flourish in any language if you have the competent programs. If you make them poorly, it will flounder in any language. But the little gains that you get by having a language that does fancy type magic, pointer checking, built-in objects, yada yada…they simply don’t matter compared to all of the other factors. Unless, of course, you just absolutely must release constantly. But you _do_ get a performance penalty.
@glok twen:
I don’t think the OP was saying that writing code in C causes it to be better, but rather that there appears to be a correlation between good programming/programmers and programs written in C.
As you say, important factors are things like testing habits and experience, but at least in my experience the projects with the best unit tests and code reviews are often written in C. It’s a correlation, not necessarily a causation though.
On fluency in C and programmer competence:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
From an implementor of novel solutions:
http://archive.gamespy.com/legacy/articles/devweek_c.shtm
Use the right tool for the job, and keep an open mind. That’s my 2 cents. Quick and dirty 10 dialog recipe app? VB. PC game? C++. Solid state micro chip for specific embedded need, like a sensor? Assembler. If every experienced programmer would simply embrace the real world and use the right tool for the job, they wouldn’t treat programming choices like religion. Just get real, and be real.
Use the right tool for the job, and keep an open mind. That’s my 2 cents. Quick and dirty 10 dialog recipe app? VB. PC game? C++. Solid state micro chip for specific embedded need, like a sensor? Assembler. If every experienced programmer would simply embrace the real world and use the right tool for the job, they wouldn’t treat programming language/compiler choices like religion. Just get real, and be real.
@Kieran – agree i was commenting on an implication of the last paragraph. also agree on the difference between causation and correlation which the world often confuses.
in that case, then, i’ll say that in the OP’s opinion, evidence seen indicates a correlation between c programmers and “trust”-worthiness. the evidence i have seen is that there is no reliable correlation between language coded in and “trust”. instead, the factors more highly correlated with trust that i’ve observed are the ones listed.
C is great. Python is great. Ruby is great. Heck, Java is great (I feel dirty saying that) … assuming you have good programmers. I agree that bad programmers can hide in higher level languages much easier than in lower level ones and it’s important to have good engineers working on a code base no matter what language it is in.
I do have a hard time agreeing that higher level languages don’t give you any productivity improvement. If that is really the case there is a lot of wasted time and effort writing and updating higher level languages … and by higher level languages I mean anything above assembly. If your using the right tools assembly should be just as fast and easy to write as Ruby! If it isn’t that easy, you must be doing it wrong … right?
Actually, using pointers is much easier to understand in assembler than it is in C, so you’re right that higher level languages are the wrong way to develop software…
PS: of course that’s because the C syntax for using pointers is probably the worst and most inconsistent of any language in common use…
I haven’t read the comments, but I agree with this post. It seems that new fads are driving people to forget how powerful our old languages are. School teaches industry standard languages. CEO’s decide the industry standard language, CEO’s decide what language their coders use. CEO’s have no business making this type of decision. Now because n00bs all learn Java as their first language (in schools), and learn that it is “right”, they will accept nothing else.
I need to start a blog, maybe I can meet more people like the original poster! =D
As for as the programmer is concern, language is only the tool, it depends how we utilize it. so in this regard assembly is the best giving us the full capability to handle pc’s power.
This is certainly interesting, though I have to disagree. With any programming language comes a learning curve, and I’m not convinced that the learning curve is any greater for a language like C# than C (in fact, I would argue in the opposite direction). The closer we come to representing common spoken language and real life within our programming languages, the easier and faster programming will be. Clearly, C is a lot farther away from this than many modern programming languages.
To say that it is just as quick or quicker to develop in C as it is to develop in C# is to throw away much of the progress that has been made in recent years. It is painfully obvious that developing a straightforward Windows (or any other GUI-based) application is much, much quicker using a modern, truly object-oriented programming language than using C, for many reasons. Some of them include fewer lines of code, better representations of real world objects, easier to read code, better designer tools (IDE GUI tools), and event-based development. C was not designed for these approaches.
Straight up it is quite odd and misplaced to argue that C is just as fast or faster for development than modern languages. We all struggle with finding our comfortable favorite languages and approaches and sticking to them, but in this industry we do not have the luxury of sitting back and relaxing where we are at. I’m afraid that’s what you’re encouraging and fighting for here. It seems pretty silly to me.
But isn’t the C# language owned by Microsoft?
I have written C professionally for over 25 years. A few years ago, I rewrote about 30k lines of C code that I wrote in Python. I found a problem in my unit testing. I was sure it was something that I had done wrong in Python. It turns out that the bug wasn’t in my Python code, but in my C code. I was processing characters in a string. I didn’t properly process the last character in the string. In Python I did, and so the results of my unit tests differed.
If speed is the issue, C is always faster. If time to develop the code is an issue, or time to maintain, or security issues is a concern, I think Python is better overall.
I just looked at some bug reports in different linux distributiuons at lwn.net. About half of them related to buffer overflows or heap overflows. This is for deployed, tested, somewhat mature code.
I haven’t seen these kind of bug reports for code written in languages that have memory management, such as Python or Java.
Spot on (the author is).
Niklas, I don’t know the exact legalities behind the C# language, but I do know that everyone is free to use the language on Microsoft platforms or off (see Mono for Linux and Mac). Microsoft’s compilers are free, and there are free versions of Visual Studio too, if you’re interested. I know that Microsoft had a lot to do with C#’s creation, but I’m not sure that they actually own the language (though they may).
Regardless, C# basically ripped off Java in every way, shape, and form. C# took Java and tweaked it heavily for Windows event driven development. I believe C# has become a much better language than Java, but Java still allows for much, much faster development than C.
As anyone who recognizes my name will know, I have an obvious bias here, but perhaps we can cut through some of the posturing here and offer up some metrics.
The only one I have is pretty old (2003) and not particularly scientific, since the feature-sets of these three bits of software aren’t exactly the same, but consider this:
http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/lefkowitz/lefkowitz_html/index.html#sec:conch
While there aren’t a lot of numbers there (in particular, “development time” is conspicuously missing, but since none of these projects are ever truly finished it’s somewhat difficult to pick a line in the sand for that), they do follow the general curve that the “higher level” the language is, the less code and the fewer developers you need to get roughly the same amount of work done.
What are the metrics like on the community size and development time for other largely functionally-similar projects: for example, the ones mentioned in the article: Banshee vs. Rhythmbox? Git, Bazaar, and Mercurial? It’s important to remember that even if the end results are largely similar (and I don’t entirely agree that they are; see arguments above about security and reliability), it *does* matter if one tool lets you achieve that result with proportionally less effort.
I’m sorry but programming languages aside, Banshee is dazzlingly better in its interface, and generally ease of use.