On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote: > In article <52b328f7$0$6512$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > >> Correct. The *great deal of trouble* part is important. Things which >> are the responsibility of the language and compiler in (say) Java, D, >> Rust, Go, etc. are the responsibility of the programmer with C. > > Does anybody ever use D? I looked at it a few years ago. It seemed > like a very good concept. Sort of C++, with the worst of the crap torn > out. If nothing else, with the preprocessor torn out :-) > > Did it ever go anywhere?
There are still people using D. Like most niche languages, it's in a niche :-) >> Now, I wish to be absolutely clear. There are certain programming areas >> where squeezing out every last iota of performance is important, and to >> do so MAY REQUIRE MAKING SOME COMPROMISES ON CORRECTNESS OR SAFETY. I >> find the C standard's position on undefined behaviour to be >> irresponsible, but, hey, MAYBE IT IS JUSTIFIED on the basis that C is a >> systems language intended for use in writing performance-critical >> operating system kernels, device drivers and similar. It's fine for >> Python to promise that nothing you do will ever cause a segfault, but >> for a language used to write kernels and device drivers, you probably >> want something more powerful and less constrained. Emphasis added. > I disagree entirely (but respectfully). If you want to get down to the > hardware where you can fiddle bits, you want as little getting between > you and the silicon as possible. Every time you add a safety feature, > you put another layer of *stuff* between you and the machine. I think that if you re-read what I wrote, you actually agree with me. With the following two provisos: 1) There is a tendency among some programmers to premature optimization and coding machismo where correctness is a distant fourth place behind speed, memory use, and code size -- and security doesn't even place. For those programmers, "I want to get down to the hardware" often has nothing to do with *needing* to get down to the hardware. Screw 'em. 2) Even for kernel developers, I believe that systems languages should be safe by default. You ought to have to explicitly disable (say) bounds checking in critical sections of code, rather than explicitly enable it. Or worse, have to program your own bounds checking -- especially if the compiler is permitted to silently disregard it if you make one tiny mistake. > That's not to say it's the right language to be writing applications. I find it interesting to note that the utter failure of C programmers to deal with the consequences of buffer overflows has lead Intel to put pointer safety into hardware. http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions There is little reason to believe that a safer language would necessarily be slower in practice. C has had 40 years of development to get to where it is now. With a fraction of the development of C, Scala code gets to within a factor of 2-3 of the equivalent C++ code, Go to within a factor of 5-7, and even Java to within a factor of 3-4. Okay, so Java has had oodles of optimization development too, so that's probably about as good as it will get. Imagine if newer languages like Go and Rust had even a quarter of the development effort as C and C++. http://readwrite.com/2011/06/06/cpp-go-java-scala-performance-benchmark -- Steven -- https://mail.python.org/mailman/listinfo/python-list
