Object Pascal is not a scripting language or "memory safe" at all, FYI about basic-computer-games

[veelo]

I'm not suggesting SPARK or Ada to be included.

I think, because BASIC was easy to learn and hard to make dangerous mistakes in, and the book was influential to beginning programmers, that you want those same traits in the selected modern languages. What we are trying to say is that "memory safe scripting languages" is not a very good description then. So why not make the requirement "a language that is easy to learn and hard to make dangerous mistakes in"? Then all currently selected languages can stay including Pascal, and C/C++ stay out.

OTAH, I might be misunderstanding the objective of the project completely...

[coding-horror]

Oh my bad, I assumed it was! Are there version of Pascal which are memory safe?

[Akira13641]

I mean, in what sense? It's hard to explain, but basically both Delphi and Free Pascal (as I was using in that link) are like:

• Classes are pure "reference" heap-based types sort of similar to say D or Swift classes (minus any kind of implicit reference counting or garbage collection)
• Objects are roughly equivalent to C++ classes in their support for inheritance (though it's just single inheritance) and ability to be either stack or heap allocated
• Records are basically just like C++ structs or classes, except with no support for inheritance

There's various things about the overall language that make it generally more safe than something like C or C++ in most cases in practice, contextually, but also nothing stopping you from doing dangerous things with raw pointers / inline assembly / etc whenever you want, if that makes sense.

[coding-horror]

Wikipedia says

Pointers in Pascal are type safe; i.e. a pointer to one data type can only be assigned to a pointer of the same data type. Also pointers can never be assigned to non-pointer variables. Pointer arithmetic (a common source of programming errors in C, especially when combined with endianness issues and platform-independent type sizes) is not permitted in Pascal. All of these restrictions reduce the possibility of pointer-related errors in Pascal compared to C, but do not prevent invalid pointer references in Pascal altogether. For example, a runtime error will occur if a pointer is referenced before it has been initialized or after it has been disposed.

If we really can't define Pascal as a memory safe language, I'm fine dropping it and replacing it with one that is truly memory safe..

[Akira13641]

Again, it depends on what you mean. Pascal as described in that article lacks many features added later in various different implementations, though generally yes, is type-safer than C. Note that there's no "Pascal standard" that anyone cares about currently, different parties just extend it however they see fit.

At the broadest level though (in current "Object" Pascal implementations, specifically) there is no garbage collection or automatic memory management of any kind other than in a couple of specific cases for specific types, such as the "magic" compiler-implemented strings and dynamic arrays that it has (which are atomically reference counted in a way that requires nothing on the programmer's side).

That's basically what I was mostly getting at here, originally.

[coding-horror]

Hmm. Looks like we need to drop Pascal in favor of a different language.. since we agreed to include Kotlin, maybe Kotlin replaces it? Google gave Kotlin a big boost:

https://developer.android.com/kotlin

[veelo]

Looks like we need to drop Pascal in favor of a different language.

Might I suggest D? (Tongue in cheek) Seriously though, I am professionally involved in porting half a million lines of Pascal code to D. D is a fitting successor to Pascal (as well as to C++, Python; Basic...)

I just pushed changes to #365 that should guarantee memory-safety.

[coding-horror]

There’s been a bigger push for Kotlin IMO and D is not really memory safe either …

…

On Mon, Jan 3, 2022 at 8:14 AM Bastiaan Veelo ***@***.***> wrote: Looks like we need to drop Pascal in favor of a different language. Might I suggest D? (Tongue in cheek) Seriously though, I am professionally involved in porting half a million lines of Pascal code to D. D is a fitting successor to Pascal (as well as to C++, Python; Basic...) I just pushed changes to #365 <#365> that should guarantee memory-safety. — Reply to this email directly, view it on GitHub <#343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALTWVIPYXDHALUAYXCDGLTUUHDO7ANCNFSM5LDNT7WA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[veelo]

D is not really memory safe

Neither is Kotlin. D already has the features that are proposed in that post, nota bene.

[baka0815]

@Akira13641

At the broadest level though (in current "Object" Pascal implementations, specifically) there is no garbage collection or automatic memory management of any kind other than in a couple of specific cases for specific types, such as the "magic" compiler-implemented strings and dynamic arrays that it has (which are atomically reference counted in a way that requires nothing on the programmer's side).

I don't know if you count Interfaces as "couple of specific cases", but they are reference counted.

[coding-horror]

We'll have to go back to the TIOBE top languages list and decide which one we want to replace with. Them's the rules..

[veelo]

That's fine if that is the rule you want to have. The value of that index is frequently questioned though (see Wikipedia and plenty other places) and especially once you get into the promille range, noise gets more prominent in the ranking.

But since it's you who is setting the rules, you can also just say Pascal stays in because I like the language (and because all the work has been done). Is there any downside to including other languages, and expand the opportunities for learning?

[coding-horror]

Well, I do believe very strongly in the languages being FULLY memory safe, so I want to stick with that..

[Akira13641]

@baka0815

I don't know if you count Interfaces as "couple of specific cases", but they are reference counted.

That's true I guess yeah, although Free Pascal at least has a compiler directive that makes them not (which is quite useful in some cases, though generally I don't use interfaces that much, or even classes that don't implement any interfaces these days for that matter, preferring "extended records" most of the time).

Can't remember if a similar directive is available in Delphi.

[coding-horror]

I'm still torn on what to do here and could use advice. I feel VERY STRONGLY we want only absolutely safe languages (in the official list of languages, I mean), no exceptions.

For people who want to contribute C or C++ versions (or any other memory unsafe language) that is also fine, but those must be linked from the readme.md.

[Akira13641]

I'm still torn on what to do here and could use advice. I feel VERY STRONGLY we want only absolutely safe languages (in the official list of languages, I mean), no exceptions.

For people who want to contribute C or C++ versions (or any other memory unsafe language) that is also fine, but those must be linked from the readme.md.

Frankly, I think a larger oddity with your original list is moreso that you included languages that are fully memory safe, but still are absolutely not "scripting languages" by any metric I'm aware of (notably C#, VB.NET, and Java, for example).

[veelo]

I am afraid there is a need for nuance when talking about safety.

• Java has an unsafe escape hatch.
• C# has an unsafe escape hatch.
• Python is not "absolutely memory-safe".
• Ruby and Perl have had vulnerabilities.

It appears to me that the linked-to unsafe Delphi code requires the {$PointerMath On} pragma, from which one might conclude that code that does not include that pragma cannot do unsafe sings that require pointer arithmetic. Given that Pascal can do array bounds checking, I think the way in which Pascal is used to port these BASIC examples is very safe.

[veelo]

Also, from your Pascal Wikipedia quote:

... but do not prevent invalid pointer references in Pascal altogether. For example, a runtime error will occur if a pointer is referenced before it has been initialized or after it has been disposed.

A runtime error does not mean the program is memory-unsafe. An error due to memory-unsafety causes undefined behaviour, including the program continuing with wrong results, or affecting other parts of the system. That's not the case here. If the program is terminated due to a memory error then that is considered a safe outcome!

[Akira13641]

@veelo

Also, from your Pascal Wikipedia quote

TBH, you really can't define "Pascal" by what Wikipedia has to say in reference to what sounds like an implementation from around 35 - 40 years ago. The closest you can get to accurate nowadays is "literally whatever the developers of Delphi and / or Free Pascal happen to decide to implement at any given time".

Given that Pascal can do array bounds checking, I think the way in which Pascal is used to port these BASIC examples is very safe.

Yeah, I could 100% write "safe" Pascal implementations of pretty much anything, sure. I wasn't saying I couldn't, just pointing out that it was actually a language that isn't strictly safe by nature and in fact simultaneously provides both high-level and low-level features in a sort of uncommonly blunt way.

[veelo]

"literally whatever the developers of Delphi and / or Free Pascal happen to decide to implement at any given time"

True.

I get your point and I agree.

@coding-horror: Drawing a clear line at languages that are absolutely safe is problematic because safety is not a clear cut concept. Even Ada is not completely safe, otherwise SPARK would not need to exist. [Edit: And even SPARK comes at different levels of rigour.] What do you actually mean with "memory-safe scripting languages"? I think you actually want languages that are suitable for beginners, that are quick to get going with and that help you from making programming mistakes to a reasonable degree. Because even though SPARK may be the safest language in existence, nobody would ever recommend SPARK to a beginning programmer because [s]he would not get things done (let alone afford the license fees).

[coding-horror]

Well SPARK isn't in the top 20 TIOBE languages, is it? That's another inclusion criteria we care about.. this isn't an exercise in speaking forgotten languages, or languages nobody (statistically speaking) uses..

https://www.tiobe.com/tiobe-index/

[coding-horror]

a language that is easy to learn and hard to make dangerous mistakes in

That seems fine!

[coding-horror]

I've updated the official languages to 10:

1. C#
2. Java
3. JavaScript
4. Kotlin
5. Lua
6. Perl
7. Python
8. Ruby
9. Rust
10. VB.NET

Rationale is here https://discourse.codinghorror.com/t/updating-101-basic-computer-games-for-2022-and-beyond/7927/116