Because it leads to losses in programmer efficiency.

Studies have shown that programmers write approximately the same number of lines of code per unit time in whatever language they happen to be programming in. A language like Python is 5-10 times less verbose than C (i.e., it takes 5-10 time more lines of code to do a task in C instead of Python). Thus, programmers are less efficient programming in C.

There's a difference between a bad programmer and a perfect programmer, primarily that the latter doesn't exist. Memory handling issues are an entire class of problem that exists in C but not in the language(s) that I (we) espouse.

I know enough to know that it's both insignificant and easy enough to workaround when I reach the optimization stage of my project.

Have you ever noticed how you don't notice the speed of probably 90% of the applications on your computer? Unless you're writing code for scientific processing of bulk data, computational speed is almost always a less important consideration than development speed, and the languages I espouse are far superior at the latter.

Jeremy

Agreed, sometimes higher language take design to extremes.

The point of portability is that you don't need to recompile your source to fit the platform (which would be the case with C/C++, etc). With Java (or any .Net language) the idea (note this) is that you write your code once and you don't need to recompile, etc to make it run on another system (yes as long as they have a JVM, that's how java works so you need it. Just as i need the GTK+ runtime lib to run GAIM in Windows). Java has generally done a good job so far of making this possible. It's a matter of developer of course. If he/she decides to use more platform dependent calls, then they lose portability). I think this is another case of what you said above: "I just think it is an issue with the programmer not the language".

Most definatly, unfortunately in Java's case the developers NEVER intended on making it fast. It was always an after thought. it's hard to have both. The more 'userfriendly' a language is supposed to be, the more you lose in performance. .Net languages i hear have been performing fairly well (i never bothered much with comparing performance, it has never been an issue in what i've done).

Hell yeah! I actually HATED Java as a first language. I just didn't get all the OO stuff. After i covered a bit of C and C++, i started enjoying Java a lot more.

One of the reasons i stopped with Perl, it was just too hard to read other people's code, even my own.

Then all bugs are an issue with the programmer, not the language, and we should all be using INTERCAL.

It might reduce the number of lines of code you have to write by a factor of 2, perhaps, but it still doesn't bring C to the same level as Python.

There is very little that C is the best language for. Security-sensitive stuff being one of the most obvious things that C is markedly inferior at, due to its lack of runtime checking of bounds.

I would choose a different language too.

This is called "abstraction" and it's a benefit to programmers, especially to the new ones.

Jeremy

I misread this before and thought you had capitulated.

You're wrong, plain and simple.

First, "interpreted" is a poor term to use to apply to languages: most of the languages to which I imagine you wish this term to apply are actually compiled to bytecode and run in a VM.

Second, you must realize that "interpreted" (as in "compiled just-in-time") languages are not by nature required to be garbage collecting; the two language features are orthogonal. Numerous garbage collecting languages are compiled to native code, include Lisp, Haskell, O'Caml, SML, etc.

Thirdly, I don't think you have basis in fact for your statement: I believe the performance hit would most certainly be negligible, especially in a system where the VM for these languages remained resident in memory. But then again, neither of us can prove our statements. If you can think of a suitable benchmark, I'd certainly be happy to help prove either of our statements with you.

Jeremy

I am sorry, I will admit I had certain languages in mind that use both features and are notably slower. However, having dealt with trying to optimize Scheme at link-time when compiling it to native code, I would note that the most success is claimed from converting it to C. This is because the C compilers are quite simply superior at native code generation -- this is not because C is better for this I will admit, it is because they are more mature at doing so.

My basis for my statement is CPU time. I am admitting, even if I have previously contradicted this, that frequently CPU time is not noticeable to the user as it time waiting for the CPU time that you will spend most of your execution time in. However, when you everything on the whole server using extra CPU time the hit becomes noticeable -- hence, a shell server as the example, several hundred users all using programs that are slower. I think I should clarify that it is not an issue with languages that are interpreted or garbage collecting especially, it is an issue with slower languages. The way I phrased my statement was poor, I am sorry for that.

No, this is not what I am saying. I, personally, had very little issue with C's memory allocation when I was starting, and have not had any memory handling errors exposed in many years now ( and my projects are routinely run through heavy testing -- though, it is technically infeasible that I have tested every possible input, I test many different classes of input ).

I know that C is more verbose than some other languages, my point was that it is not as bad as the author of the previous post was making out.

Runtime bounds checking can be done by C, it is a reasonably straight-forward compiler patch. Alternatively, you can use tools like Valgrind during testing. I personally prefer checking the bounds myself for possible error cases, meaning I only need to perform testing when it is necessary -- versus every access.


This is, in many ways, a myth. A lot of programmers seem to think that abstraction is the `silver bullet', and abstract everything away. It can be good, but at the same time it can be very poor ( and I am not talking about poorly performed abstraction, more the data hiding is not always the best thing to do ).

Jemfinch: I am sorry if I have offended you, but you seem to be writing to me as though I am an idiot. I have, at least some, basis in everything I have said, although I have admitted sometimes my comments were phrased generally when they were specific cases. You most likely understand that a lot of things like OO, like abstraction, and so on are theories and should be taken only as possible solutions. There are too many people that look at a project and go ``OO, data hiding'' ( yes, I know OO can perform data hiding and has a strong relation to it, but it does not implicitly imply it ). They do not even consider alternatives. Maybe OO is the best design method we have, maybe it is not -- I do not think either of us is equipped to state either way.

May I note, I am not some C fanatic as I seem to end up being. I like C, but I use whatever language is applicable to my project at the time. The reason I defend C is that a lot of programmers look over all flaws in their language of choice and universally bash C.

Sorry to quote myself, but, well, I left out my point ;).

My point was that a lot of these languages perform better natively when converted to C and then compiled in a C compiler. The C code to perform the same task is likely ( and from my experience in Scheme ) to be better written C then that that is generated from another language.

I have tried to not generalise without reason, hence the reason I am only referring to a case with Scheme. This does not mean that lessons learned at not to some extent applicable in other languages.

Another thing I would like to bring into consideration, and would like to hear others' view on, is the development time on projects. Now, I am not referring to ( as the other of this post originally was ) hobby codes, as I know you do not tend to do this, I am referring to professional work. I tend to find that a very large proportion of my time is spent in the language orientation free design phase of the project. I would assume that this is likely to remain fairly constant no matter what language I use, therefore I do not consider C taking slightly longer ( though, I do not think that twice as long, as claimed by some, is correct -- though I do concede to programmers writing approximately the same amount of lines of code a day ( and this is why the projects we do in assembly take so damn long =) ) ) to be as significant as a hobby programmer may.

O'Caml is compiled directly to native code, GC'd and is comparable in speed to C/C++ (sometimes a little faster, sometimes a little slower). It has a much higher level of abstraction than C++, and is generally more pleasent to work with. It really isn't the case that all high level languages are slower than C. In fact, all the low level features of C just make it harder for C compiler to produce efficient code -- pointers are a real pain when optimising code. C is indeed close to the machine, but the machine it is close to is the PDP/11.

Garbage collection, when done properly, is usually faster than manual memory management. (It allows memory to be deallocated whenever the program is not using much CPU, and it can reduce memory fragmentation).

Your points about Scheme are quite valid, but Common Lisp is another story. There are some very good LISP compilers out there that produce native code that's in the same league as C/C++ in terms of speed.

Alex

Not to pick nits, but having the compiler implement something to do it for you isn't the same as having it in the language. Let's go ahead and assume we're talking about C99 here and ... whatever the latest C++ spec is, I have no clue :p And of course, Valgrind most definitely wouldn't count ;)

Seems like someone is trying to convert people to python. Oh wait the industry at the moment is nothing but C/C++ mixed with some java and unfortunatly some visual basic. You want to work you know those languages. You want a hobbie? Learn python.

C# is becoming somewhat unignorable as well.

Happens when MS tries to push something like it down the throat. Though i've played around with it a bit and it ain't that bad actually.

I use C# almost exclusively at work because we are working with SOAP WebServices for a number of things. However, even there, I find myself using C/C++ to right DLLs because there are times when we need to access a C or C++ API and trying to import all that into a C# app would be more effort than it is worth. As an example, we may soon be working with OpenSSL. It is going to be vastly easier to write what we need to do with OpenSSL in C/C++, then just provide a simplified interface that can be used from C#. In this case, I'm actually thinking we will probably create a Managed C++ assembly.

For my home projects, I generally use C/C++ exclusively, because most of my home projects involve graphics with OpenGL. I did do a project that used Managed C++ to provide a C# interface for OpenGL, but just as a way to familiarize myself with Managed C++. I still prefer to use C/C++ for OpenGL because then I can use most of the same code for both Windows and Linux. Plus, with graphics programming, performance is usually somewhat important. Especially if you are working with video cards with no 3d accelleration.

No. Now stop drawing attention away from the main point of the thread, which doesn't involve "which has more jobs available for it?"

You named your thread why use C/C++ so that is a valid response like it or not.