On Wed, 27 Apr 2016, Toby Thain wrote: While I follow your thesis here, I would also point out that the reason that a lot of C programmers roll their eyes when folks start talking about abstraction is that generally increases code size and overhead. Those two mandates (get out of my way, but don't let me make mistakes) are tough to achieve at the same time. People want the features they find in scripting languages (no memory management, no hassling with pointers) but they don't want to pay for them. It's a matter of debate among experts as to how much fat abstraction adds, or the value of the abstraction itself but it's the primary reason why many C coders are dubious of too much abstraction. C, in my opinion balances the two in one of the least-ugly ways (not that it's all that glamorous, it just works). Those on the "maximum abstraction" bus have already arrived at their stop in C++ land or have moved on to RubyTown etc... (not slamming them, just saying - I do C++ too). I stick with C because I don't want (much) more abstraction than it offers for the applications I write or maintain. Well, I definitely agree with this in general. The question again is how much are you willing to spend to get them done? There is always the guy who will say "Oh gawd we have 6Ghz machines with 4TB of RAM now. Who cares." That will always be followed by the person who says "Wait, I still do embedded code on a Z80 with 4k of RAM!" One thing that I'd point out about C is that once you learn it, you can do both (some would say poorly, but not me). True. However, when I look at http://benchmarksgame.alioth.debian.org/ and other such comparisons, and compare those languages doing real work I can see what the cost is to do so. Maybe some would assert that all this safety can come for free. My response to that would be "Excellent. Please write us all a new compiler, then." For the record, I do know about things like gcc-ssp, propolice, stackguard, etc.. I've used most of those where needed. I write quite a bit of C. I don't claim for a second to be "good" ('cause I've met people who are *really* good). In my experience there are several things that you can bring to bear which will result in you hardly every chasing pointers or malloc() issues. Here's what I do to help myself (BTW, I'm sure you are all better coders. I'm just sharing my experience): 1. Early on I wrote myself a reference counter. There are all kinds of easy ways to do this. Then you can catch yourself when you use a null reference or let a loop run off the edge of a cliff. Once you feel comfy, remove the #include'd wrappers. I've done the same thing using LD_PRELOAD mechanisms to preempt things like malloc(). 2. When in doubt I've used tools like ElectricFence and Valgrind to also aid greatly in finding problems that might lead to buffer overflows or string format exploits. I also use tools like "rats" to hunt down bugs. 3. I started getting burned enough that I simply figured out what kind of design patterns I was using that got me into trouble. Once I applied myself to stopping that behavior, the issues I was having with memory shell games basically went away. 4. Kind of along with the philosophy you are talking about (perhaps) I do check the livin' snot out of everything I get back from non-deterministic operations. Some of these are just using my knowledge of the code's actual logic path to do the checks at the *exact* spot they are needed without some compiler trying to out-guess me or check absolutely everything. YMMV, but that's how I live with my dirty C programming self. :-) That's what I hear from folks who love Haskell and Erlang. As I'm sure you know, those languages have some really interesting properties similar to the kind of philosophy. You guys are going to be the type of people who move the whole industry forward as you push innovative (or maybe old & innovative) ideas. Guys like me just try to get the code done as fast as possible before our jobs get offshored to India. :-/ -Swift

Probably not Ada either, but among languages that are in current use that one is probably the best by this measure. BTW, it's not so much "modern" as "well designed". How to design languages that facilitate correct programs was well understood by around 1970. There have been some additions since then, but a lot of the right answers can be found in ALGOL (and a lot of wrong answers can be found in the work of those who ignored ALGOL). paul