Typesafety versus Worse is Better - was Re: Fwd: is there any word processing software for the pdp11?

I suppose not. Perhaps more that using a language that Isn't C and offers (1) and (2) will ameliorate 99.99% of the problems that follow from using C incorrectly. Certainly that's true. Can't shoot yourself in the foot if you don't own a gun. But that's not much to talk about :) I have a habit of using hyperbole and I guess I really shouldn't because 99.99% of the population of Earth apparently finds it simply discrediting, rather than a come-on for a debate!! I have a lot of hang-ups from my experience in school and in the new-millennium job market... there are so few opportunities these days; the people that get the chance to take them; who get to be real programmers and real engineers; they had better be good. Otherwise you can just play on nights and weekends like I do. To me, part of being a professional and doing the job right is not making mistakes. Certainly that's the standard I hold myself to as a Systems Administrator. People who nail up their shingle as a professional and subsequently ship buggy garbage don't need a new language to save them from themselves; they need a new line of work (whoa, polarizing!) Best, Sean On Wed, Dec 3, 2014 at 6:38 PM, Josh Dersch <derschjo at gmail.com> wrote: > On Wed, Dec 3, 2014 at 3:09 PM, Sean Caron <scaron at umich.edu> wrote: > >> Clearly you're on a religious crusade here.. I just don't buy the line > that >> were it not for everyone using this pesky C language, we could live in > this >> mythical world where exploits don't exist... > > > That's not the line that was given. No one here is claiming there is a > language that prevents all exploits. > > > >> You must be a professional >> programmer? Certainly you have strong ideas of what's right and what's >> wrong in programming practice... but I feel like you are faulting the >> language here while giving what are essentially (sorry, strong >> language) >> hack programmers a pass... Why should it be the responsibility of the >> language to save programmers from themselves? > > > The reality is that we're all "hack programmers." Everyone makes > mistakes. Sometimes these mistakes get caught by others, sometimes they > don't. Some programming languages can help catch more of these mistakes > sooner, or to make some of these mistakes impossible. > > In a perfect world, we wouldn't need languages to take responsibility to > "save programmers from themselves," but we don't live in that world and > it's pretty evident that deficiencies in C have resulted in many > exploits, > even in the hands of experts. > > - Josh > > > >> Not necessarily the best >> metaphor because I totally appreciate languages like Smalltalk, >> LISP, et > al >> but I'm too old to be restricted to safety scissors! >> >> Best, >> >> Sean >> >> >> On Wed, Dec 3, 2014 at 3:25 PM, Eric Smith <spacewar at gmail.com> wrote: >> >>> On Wed, Dec 3, 2014 at 9:21 AM, Sean Caron <scaron at umich.edu> wrote: >>>> But is there necessarily a win in turning a crack C programmer into a >>>> novice {Smalltalk, LISP, insert your favorite language here...} >>>> programmers? >>> >>> Of what use is a newborn baby? Of *course* it's of no value if you > stop >>> at turning them into a novice. But if they're actually a *good* >> programmer, >>> they'll become proficient in another language. I would go so far as to >> say >>> that if they don't become proficient in another language, given a >>> reasonable >>> chance to do so, they aren't actually a good programmer, any C >> programming >>> ability notwithstanding. >>> >>>> Given a short time frame, perhaps it's more effective to spend >>>> those hours writing code in a language with which you're already >>> familiar, >>>> rather than spending them picking up a new language... >>> >>> And continue writing software that has vulnerabilities. When the tools >>> don't >>> provide support for writing reliable software, reliable software >>> mostly >>> doesn't >>> get written. For every CERT advisory of a vulnerability, there are >> still a >>> huge number that have gone undetected so far. >>> >>> C advocates always claim that a good programmer will write reliable > code >>> in C, and in a vanishingly small number of cases that's true, but the >>> reality is that 99.9999% of C code has bugs that either: >>> >>> 1) could have been caught by static analysis in a language with even >>> slightly better semantics (including strong typing) >>> >>> 2) could have been caught at runtime if the language semantics could >>> reasonably support bounds checking. In this case the software >>> would >>> still have a bug, but at worst it would result in denial of >>> service >>> rather >>> than privilege escalation and information leakage. (Then there's > the >>> problem of people that use runtime checking during software >>> testing >>> to protect their valuable test data, but turn runtime checking >>> off >> for >>> production, but that's an argument for another day.) >>> >>> There has been a huge amount of research into how to solve those >>> problems in C, with only partial results. It's a difficult and perhaps >>> intractable problem because C is a portable assembly language, with >>> correspondingly low level semantics The "easy" way to solve the >>> problem >>> is not coming up with bandaids for C, or trying to better train C >>> programmers; it is to abandon C for a reasonable language. >>> >>> This doesn't happen at least in part due to managers seeing a huge >>> glut of C programmers on the market. When all you've got is a >>> hammer... >>> >>> Note that the same arguments apply to C++. While C++ is no longer >>> a proper superset of C, it still is close to being one. C++ advocates >> will >>> point >>> out that a lot of the new stuff in C++ is safer than the old C stuff, > but >>> unfortunately as long as the old C stuff is in there, it gets used and >>> causes the same old problems. Rather than C++ being a better language >>> than C, it's a worse language, because it has *all* of the C defects, >> plus >>> additional new ones. >>> >> >