Object Pascal, Memory Safety, the US Whitehouse and future programming

[AlexK]

I find comments like that to be very deceitful.  Every class in Object Pascal is a pointer.  The fact that it's a pointer is hidden from the programmer which makes its being a pointer worse because some programmers don't realize what they are dealing with.

There's a modern way to enhance language safety, "sound null safety"(Dart language). It can be retrofitted into a language.

• All variables are non-nullable by default
• To specify that a variable type can have a nil value, add a ? after the type annotation -> e.g. Parent: TCustomForm?;

Sound null safety changes potential runtime errors into edit-time analysis errors.
If you have to compute a value for a non-nullable variable, there's a modifier "late" -> Parent: TCustomForm; late;
Compiler checks that a "late" variable is initialized before use in function body. It can never be nil.
In dot expressions like

Code: Pascal  [Select][+][-]

1. Parent.SomeNullableVar?.SomeNonNullableVar;

, question mark is mandatory(required by compiler) if that variable was declared in a class as a nullable type(with ? after typename).

From compiler's point of view it's like an automatic attribute for a type. Nil can be assigned only to a variable that is declared with a typename ending with ? mark.
For a routine parameter declared as non-nullable(typename without "?"), compiler won't accept as argument a nullable variable.

Exclamation mark ! is an operator that checks for nil value and throws an exception if nullable var is nil.

Code: Pascal  [Select][+][-]

1. // if `site` var was not declared as nullable(with ?), then compiler notifies that "!" is redundant,
2. // non-nullable vars can never be nil.
3. if (site!) then
4.     // do something with site var
5.  

[AlexK]

A short review how sound null safety looks in Dart.
It was a historical milestone for the language. Filip Hráček doesn't work at Google anymore, but writes games, participates in Flutter conferences.

https://www.youtube.com/watch?v=iYhOU9AuaFs

I was thinking what could possibly prevent Object Pascal from implementing sound null safety.
Currently "sound null safety" languages are Rust(no null at all), Swift and Dart.

[440bx]

@440bx
just a flame war between Pascal and C/C++ ...

It certainly isn't my intention to start a flame war between Pascal and C++ particularly when I very strongly dislike C++.  I would not enjoy defending that language but, credit has to be given where it is due, even in cases like that.


@AlexK

Personally, I believe that programming languages shouldn't manage memory.  They should not even attempt to manage memory.   That's what the programmer is for.

All the "facilities" (honestly, I consider them _gimmicks_) languages have added to manage memory to be highly counter productive because they promote programmer ignorance. 

Managing memory isn't hard when it's done right.   When it's not done right, all the "facilities" languages provide still don't compensate for all the problems poor memory management causes.


I don't have anything against making a language more capable, that is, enable the language to catch programming errors but, the thing that bugs me about this thread is that C, C++, FPC, Delphi are nowhere near anything that can be remotely considered memory safe.

I am close to convinced that it is not possible to create a totally memory safe language for any language that allows dynamic memory allocation.    Once memory can be allocated then, pointers exist, pointer arithmetic may exist (quite convenient to have it), pointers may point to a block that _used_ to exist, a nill pointer may be inadvertently de-referenced.  I don't believe it is possible for a language to guard against all those problems in a way that does not create an unacceptable number of hassles as a result.

Supposedly, C# and Java are memory safe.  I looked into C# and it didn't take long before I decided there was _no way_ I was going to put up with all the language's and environment idiosyncrasies to "gain" a slower program, dependency on a monstrous library and limitation of how I can use O/S facilities because some APIs may "offend" poor C#'s sensibilities.   Great language to get a listbox with checkboxes, for something useful, I find it very unconvincing. (VS Studio is reportedly partly coded with C# and it is a performance dog and a memory hog.)

The story with Java is similar.  Anything that resembles a capable program is slow and clunky.

They are nice Darmouth BASIC descendants.


I'll check out that sound null safety.

Thank you for the link Alex.

[marcov]

A short review how sound null safety looks in Dart.

I was thinking what could possibly prevent Object Pascal from implementing sound null safety.

For nullable types. If you generally don't use nullable types in object pascal, I don't see the point ?

[Khrys]

Personally, I believe that programming languages shouldn't manage memory.  They should not even attempt to manage memory.   That's what the programmer is for.

All the "facilities" (honestly, I consider them _gimmicks_) languages have added to manage memory to be highly counter productive because they promote programmer ignorance. 

Do you think that  AnsiString  with its automatic reference counting (dependent on language support) is counterproductive and that we should go back to  PChar  like God intended?

[440bx]

Do you think that  AnsiString  with its automatic reference counting (dependent on language support) is counterproductive and that we should go back to  PChar  like God intended?

I have to say yes.  I never use "string" or "ansistring" much less a longstring.

I only use pchar, pwidechar and null terminated arrays of char or widechar just as it is done in C.

The only time I will use a managed type is when I am _forced_ to do so.  That's usually when using COM. 

Memory safety comes from good programming.  Not memory management gimmicks that don't work anyway.

[AlexK]

For nullable types. If you generally don't use nullable types in object pascal, I don't see the point ?

Tony Hoare, implementor of Algol admits that nullable references was a "billion dollar mistake".
He states that a programmer should have an option to specify that a declared variable can't have a null value.
Language developers gradually fix that "billion dollar mistake".

"Sound null safety" is supposed to avoid many runtime errors.

Though there are skeptics.

[Thaddy]

Not here: Tony Hoare co-wrote some important Pascal literature together with Niklaus Wirth.
(Just to give an anti-skeptic)

I think it is more the case that a clean language - which Pascal once was - is not easy to keep clean, whereas the new exotics have not lived long enough to be polluted.
Who introduced pointers in Pascal? There is your culprit... (    )
Sadly there are too many nitwits that assume pointer based code to be faster, which is a false assumption.
It merely shows inadequacy.
"An Axiomatic Definition of the Programming Language Pascal" I had to look it up, 1972.

[440bx]

Who introduced pointers in Pascal? There is your culprit... (    )

N. Wirth included pointers in Pascal (see the original J&W user manual and report.)  Are you going to get mad at him ? <chuckle>

[Thaddy]

Added reference, posts crossed, interesting read.
But, yes, NW mutilated his language himself.

[440bx]

But, yes, NW mutilated his language himself.

"mutilated" ??? ... that's greatly exaggerated considering that programming languages that do not support pointers suffer from severe memory management limitations which makes them unsuitable for solving any problem that requires dynamic allocation of memory.

[Thaddy]

Ok, incapable, is that a better wording?

I know you like untyped pointers (chuckle)

[ad1mt]

IMO, C is the worst serious programming language ever. (By "serious", I mean not joke languages that are designed to be "bad").[minor edit for clarity]

Nearly all the security bugs of the last 40 years in operating systems and applications can be traced back to poor design of either the C libraries or language itself.

This is why, in the early 1980's, the U.S. gov created a new language ("Ada"), and mandated its use in security/defense contracts.

The designers of C admit that they "got the operator precedence wrong", but by the time they realised, there was too much code to fix the language.

In the C standard library, there is a function named "signal", which allows a calling program to capture & handle various signals/interrupts (e.g. capturing the CTRL-C command-line interrupt).

This is the definition of the signal function...

     void (*signal(int sig, void (*func)(int)))(int)

My only response to that piece of gibberish is... WTF!

I've only written one big C program, and I hope I never have to use it again.

[Thaddy]

     void (*signal(int sig, void (*func)(int)))(int)

Marcov made sense of that ION's ago...

[AlexK]

Tony Hoare apologized for nullability of pointers, "billion dollar mistake". Not for pointers themselves.
All reference types are nullable pointers.

"Sound null safety" makes nullability of variables optional. When it's needed by a programmer.
Non-nullable variables don't need to be tested by IF statement for nil - they can never be nil, they can't be assigned nil.

FreeAndNil would be rejected by a compiler for non-nullable variables.
In VAR section of a routine, variables(non-null by default) must be either initialized or with a directive "late"(initialized later in routine's body).
Routines that return non-nullable type can't return nil.
Routine's non-null parameters can't receive nullable arguments.

Nullable variables are annotated by ? in a typename.

Code: Pascal  [Select][+][-]

1. var
2.   Parent: TCustomForm?;
3.