Cool site, thanks for the link, I've been looking for something like this.

The other links are also interesting, thanks.

I don't quite get this tho:

The nice thing about C is that it can be made as readable as the author wants it to be. It is possible to write some truly impenetrable C code, but it is also possible to write code that can be easily understood. Mostly, you use descriptive variable names, create macros with obvious names to do obvious things, and use comments.

All that said, I do understand the basic point about readability, and I don't think there is any language that satisfies the requirements set forth. If there is, I don't know what it is. The closest you will come is perhaps visual basic on Windows.

I converted a very ugly C unit in one of my projects using a ridiculous amount of macros and now it resembles something friendly, and it's also very fast code. This used to be 3 functions and 50+ lines of ugly C (lots of strsep, strdup, and free):Of course the macros are a separate issue, but I stacked them up to generalize the ugliness required across about 50 segments like the one above.
ta0kira

Interesting, well that certainly proves that it can be done, but it also proves that you have to force C to be friendly. Now the problem comes in when you have fix a bug in such code, you'll have to unravel those 50 ugly segments.

Either way, I'm not saying C is a bad language, compared to many languages it is far superior in many ways, I just have to work harder at learning it. And really, eventually I'll just have to learn it, even if I do use and try other languages, let's say something like freebasic or freepascal, I know that these languages are more restrictive than C and more often than not just get in your way. C doesn't get in your way, which I really like, but it also isn't there to stop you from stepping into a pothole ... which I hate. I guess the only way to learn is to know it well enough to avoid potholes.

If you feel that way about C, then I strongly recommend C++. Keep in mind that you never *have to* use the object-oriented parts of C++. In fact, anything which is valid C code is also valid C++ code (as long as you don't name any variables 'class', etc).

C++ provides you with a fair amount more pothole-prevention than C. For example, take the string class. You don't really have to understand object orientation to use it. However, it saves you from doing lots of funky string things which will probably segfault. C++ gives you references, which are awesome at avoiding the use of pointers. The syntax for them is really simple, if you use them in their most basic sense.

Even though C++ provides these conveniences, it's always possible to go around them if they are getting in your way. Still just need to copy a large region of memory? memcpy didn't go anywhere, it's still available. Need to precisely pack the bits in a struct? Go right ahead, structs are still there. Want to recklessly use pointer arithmetic for oddly sized objects? Just cast the pointer and go ahead.

For me, C++ is much easier than C. I learned C first, and I really appreciate the new keyword, the string class, the vector class, the list class.

I actually learned C++ as my first language, but unfortunately they forced me to use OOP, which I didn't find useful especially for the length programs I was making (small). Basically just to test how ridiculous this was, I wrote the same program using OOP (the one they forced me to write) and without OOP (I declared no classes of any kind), the code without OOP was about 4 times smaller (and easier to follow, IMO) than the one with OOP and it did the same damn thing, and I can't say that the one written with OOP was any more readable or reusable than the one without.

But you do have a very good point, I didn't realize that C++ actually does have more 'pothole-prevention' than C. Then really, the solution might be just to use C++ instead of C, even when I don't use classes. I haven't specifically used C++ in a long time so this somehow slipped my mind that it is actually easier to use than C.

Oh, and thanks again for the suggestions, they are helpful in helping me decide what to do.

Here is a chunk of kernel driver code I recently wrote. Basically, this chunk of code sets up DMA data transfers between a digital signal processor on the PCI bus and the Linux host system, and it sets some flags on the DSP to provide appropriate status information for a program that runs on it (the other half of the interface driver, which actually executes the DMA transfer). With that much background, figuring this routine out should not be hard:

Even C code that is doing low-level, hardware oriented things can be made perfectly readable.

On the contrary: Although macros spread the same bug to many places, a bug fix one place will fix it many places. I had a hell of a time fixing bugs before I made the conversion I did because I'd to repeated the same pattern 100 or so times. Before it was cut-and-paste of redundant code and if I found an error in one I had to find all of the other places I copied that code to. I noticed an immediate improvement in execution and reliability once I reduced all of the redundant parts of my code using macros. It's especially helpful because I use some of the same patterns across 5+ libraries in the same project.

The 50 lines weren't directly placed into a single macro. I created small macros from simple tasks that were reused constantly, then put duplicated loops into macros using the smaller ones, then put entire procedures together using combinations of all of them, and finally the sets of functions themselves.
ta0kira

Actually, Perl has a lot of 'pothole prevention' built-in eg all vars are automatically dynamically sized, so going off the end of the buffer.
Also has references which are easier than C ptrs.
Fundamental var 'types' are

1. scalar (any single value)
2. array (zero based as per C)
3. hashes (very useful for rec structures and self-documenting if you use sensible key names)

Incidentally, you can easily create multi-level structures eg Hash-of-array-of ... etc
Easy lang to pick up if you know C, just easier to write. Does allow access to low-level stuff if you need it. Huge library of pre-written modules at search.cpan.org.
Here's the online manual with examples: http://perldoc.perl.org/

Python. It satisfy your 2nd and 3rd criteria easily. As for efficiency, it depends on how well you understand the language to use it properly. If you know C, you can extend Python to get the "efficiency" you want.

Indeed, it seems most entry-level C++ courses are *not* truly courses to teach you C++, they are courses to teach you OOP. Whenever a program reaches a certain length/level of complexity, the object orientation will be nice, but for very small problems it's just unnecessary.

But if performance is important than C++ is almost surely your best choice. Interpreted languages will always take a performance hit over compiled languages. This hit can be minimized by clever design in the interpreter, but interpreted code will never surpass the equivalent compiled code. However, interpreted code can run faster than compiled code if it is just better code. Remember, your algorithm is almost always more important than the language.

Incidentally, for "Three pounds of VAX!", it's a play on words, specifically a Zen koan (http://en.wikipedia.org/wiki/Koan) 'Three pounds of flax!'

Re PatrickNew's comment; effectively you have 3 levels of speed:
1. truly intepreted langs eg bash (any unix shell), which re-'translates' each cmd as it is used, even in a loop (and calls a lot of external progs to do non-trivial stuff),
2. langs that 'compile on the fly to an op-tree of sorts' eg Perl (see http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html for explanation),
3. truly compiled+linked eg C.

IME of C & Perl, the latter is almost as quick eg 80-90% of C.
As he said, it usually comes down to your algorithm & data structures, rather than the lang.

Hi.
What he said about built-ins, plus some external aids for better code -- I attended a short perl conference this last weekend: see some slides from state of the art and perl-novice presentations http://www.frozen-perl.org/mpw2008/wiki?node=Downloads -- back your way out of the URL to see other aspects of this conference and others that are coming up ... cheers, makyo

Indeed, and in fact, these days it's getting even blurrier. We would mostly agree that Java qualifies as a #2, since it recompiles to native code. However, I've seen ads for embedded chips where the manufacturer went through the work of making java bytecode into the instruction format of the processor, so that java was compiled! Anyhow, it's increasingly a continuum these days, and for most standard tasks, interpreted languages of some flavor or another are very good options. "Interpreted" does not necessarily mean slow.

Always a good read: Linus' comments on coding style.