[Info-vax] VAX Macro to C conversion

[Arne Vajhøj]

On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>> On 7/9/2019 8:20 PM, Bill Gunshannon wrote:
>>> On 7/9/19 9:04 AM, Dave Froble wrote:
>>>> One might also argue that C is rather prone to errors.
>>>
>>> C is not prone to any more errors than any other language. See
>>> previous statement.
>>
>> Languages are not equal when it comes to prevent errors.
>>
>> And C is probably one of the worst in this regard among widely
>> used languages.
>>
>> Characteristics like:
>> * no check on array indexes
> 
> Programmer should know that going in.
> 
> By the way, same applies to COBOL.
> 
>> * very flexible pointer arithmetic
> 
> Programmer should know that going in.
> 
> What's wrong with that?  All assemblers have pointer arithmetic.
> 
>> * very flexible type casting
> 
> Programmer should know that going in.
> 
> What's wrong with that?  A very useful function.  And easily done
> in every assembler I have ever used.
> 
>> * allowing use of uninitialized variables
> 
> Programmer should know that going in.  You mean  like someone
> here's beloved BASIC?  :-)
> So does Fortran.
> 
>> * no string type
> 
> So what?  What's so great about a string type?  Fortran
> didn't have it until 77.  Pascal didn't have it until UCSD.

Neither Fortran 77 nor UCSD Pascal are recent.

:-)

>> * non type safe enum
>> * lots of old and bad design in standard RTL
>> * lots of undefined and implementation specific behavior
> 
> Even Ada has that.
> 
>> makes it much easier to write code that result in bad runtime
>> error than most other common languages of today.
> 
> Do I really need to go on?  Stop blaming a language for the
> incompetence of the programmer.

I think you are missing one of the most fundamental
aspects of programming.

Programmers are humans. Humans make mistakes.

It does not work like:

you tell programmers how the language works => they write error free code

It works like:

you tell programmers how the language works many times => they still 
code with an average of 1 bug per N lines of code

N varies - the better programmer the higher N - the more complex
language the lower N.

But N is less than infinite for all programmers.

Some languages detect a lot of these bugs at compile
time (or at least ensure that they give a consistent exception
at runtime).

These languages result in fewer bugs coming out of development.

Other languages just allow the programmer to do anything. And
the result is exceptions (sometimes inconsistent exceptions) at runtime.

These languages result in more bugs coming out of development.

Most (probably all) languages have some unsafe characteristics.

But C/C++ got more than other common languages of today. Of the
languages mentioned in this thread then Macro-32 is probably the
only language more unsafe.

Unless you really need these unsafe characteristics (which may
indeed be the case for OS kernel code), then languages with
those should be avoided.

>> Some of these characteristics may be very useful in certain
>> contexts. But that does not make them less likely to
>> result in errors.
> 
> If you ever worked with students you would have seen a lot of
> errors in every language.  As they become more qualified the
> errors decrease.  Yes, even in C.

True.

But the absolute level would still be higher in C than
is more safe aka more checking languages.

Arne