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

[Toby Thain]

On 03/12/14 9:45 PM, Johnny Billquist wrote:
> This argument is so old, and so tiring.
>
> Can't we just bury it?
>
> Yes, some bugs will be caught by stronger types and more type checking.
> The same stronger type system will cause people to swear and be upset
> and try to work around it from time to time.

I don't see this happen. It certainly doesn't happen to me.

However, dynamic langs waste hours and days of my time debugging.


>
> Some people are better at not making silly errors than others, but all
> people sometimes do create errors.
>
> People who are more prone to create errors will obviously gain more from
> type checking.

We *all* make errors.

 > However, I've found that this same group of people are
> also very creative in writing logical bugs in programs, which no type
> system ever will catch.
>
> Essentially - stupid programmers will create bugs in any language.
>

*All* programmers. "A sufficiently smart programmer" does not exist.

> Unfortunately, as education moves more and more into just teaching stuff
> like Java and Scheme, people understand computers in a more and more
> abstract way, and start doing more and more weird broken things that
> people 40 years ago would never dream of doing since they would be
> thinking of how this translates into machine code much more.

Abstraction is your friend. It is there to help you make fewer errors. 
Most bugs can be traced to working at the wrong level of abstraction. 
(And also a lot of wasted effort.)

>
> So in the end, with people getting less proper education, a stricter
> language is our only hope. But for people who are good at programming,
> the obstacles of stricter languages becomes annoying and reduces
> productivity, for much less gain.

Education isn't the answer. Better tools have always been the answer. 
This business is culturally unable to admit that some tools are just bad.

I see the costs every day. :-)

--Toby

>
> In the end, no one size fits all.
>
> There. Can we agree to disagree on what is the best now?
> (And yes, I've actually done professional work in Ada, which is really
> fascist on a level most who have not used it can't imagine, and I've
> written really big projects in assembler language.)
>
>      Johnny
>
> On 2014-12-04 01:02, Sean Caron wrote:
>> 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.
>>>>>
>>>>
>>>
>
>