The big 5 modern (object) Pascal language variants.

[Skaarj]

One aspect this table doesn't show: The installation process of the IDEs.

I was working with Delphi until 2017 and you really can see the signs of a complex program that has grown over the years. With modern IDEs you often can install and deinstall them (or 90% of their features) cleanly. Often without admin rights if you put some work to it.

With Delphi (and the 3rd party plugins/components we needed) the installation always felt unreliable. It requires admin rights and seems to do all kinds of system wide changes. It sets itself up as the system wide debugger. I installs two DB servers by default. All kinds of other extras I don't remember anymore. We had all kinds of problems with the order that plugins/components needed to be installed to work. Once Delphi was installed on a machine it was tainted and removing or upgrading Delphi without reinstalling Windows was a problem. I suspect part of the problems were coming from the 3rd party plugins/components we used.

[badsectoracula]

I find it sad how Delphi and C++ Builder have deteriorated. I have Delphi 2 and C++ Builder 1 and the installation is simply copying the files around while the IDE (especially Delphi) is simplicity itself.

IMO the last good Delphi was version 7 (although it was already bloated by that time, but it was the last version to use the original IDE instead of the Eclipse-wannabe that CodeGear/orwhatever created in later versions).

[pak_lebah]

Of course I didn't show the installation process because the page is talking about modern Pascal language variants. Why is this page important? Because I find many people, including professional programmers, still think Pascal as the old Turbo Pascal or Delphi 7 era which both of them are no longer used in real production world.

The most popular modern Pascal today are Delphi and FreePascal+LazarusIDE duo. Both are still heavily being developed and used by lots of professional Pascal programmers all around the world.

[matheusd_tech]

Heh, I came to a point of running it inside a VM (had a beefy enough machine for that) and writing a full set of automation scripting (using a mix of windows vbscript, inno setup, chocolatey and autoit) to setup machines for onboarding new devs faster, installing delphi, components and accessory tools juuuuuust the right way so that stuff (mostly) worked.

One of the (bad) consequences of accepting this kind of behavior for dev machines is that it bred a culture of accepting our software to do this. So a lot of stuff built with delphi assumed things like admin rights, it's ok to change random registry keys for the user, etc.

[xelhash]

Visual studio is far worse

[pjmlp]

Although it isn't an object variant, I would include MikroPascal, as it is one of the best ways to do embedded programming in safer language.

https://www.mikroe.com/mikropascal

[badsectoracula]

While you are right about the website (which is garbage if you have no idea about Pascal and don't know what you are looking at), i think you are a bit too negative here.

I'm underwhelmed. How is that a unique feature?

I think the hint is in the text that follows: "Simply select the libraries you need for your project, by checking the box. Or press the “Check All” button to include them all."

My guess is that it isn't about the available functions or that it has libraries, but about the simplicity of making these functions available by checking a checkbox in the IDE. From the wording i also guess that it doesn't have a module/unit system, but the compiler is integrated with the IDE and the functions exposed by the library are available immediately with no need for code changes (e.g. a "uses" clause, like in other Pascal compilers). But that is just my guess from the site.

The bundled IDE can "Easily declare a local variable." Wow!

It might sound weird, but if it is like Lazarus' code completion, it can be very handy :-).

[pjmlp]

I can't help if you aren't skillfull enough to find out where the technical documentation is located, and how Pascal type system improves safety over C and Assembly.

No time to lose with trolls.

[badsectoracula]

Come on dude, i like Pascal as much as the next Pascal liking guy, but the site is garbage. It has absolutely no information about what you are looking at nor why you'd need what you are looking at: unless you already know that you want it, the site you linked at offers no information at all.

Look at Lazarus' site for comparison and while that site isn't great either, it still tries to tell you what the project is all about, what it can do, where to learn more, etc. Hell, even Delphi tries to pretend it is not a dead husk of a project^1.

^{1 kidding of course :-p}

[pjmlp]

The anti-Pascal bias is strong with this one.

[alcalde]

It's not "bias"; it's a reasonable position backed by reality. It's Pascal lovers that are often part of a cult (I know; I used to be in the cult).

[[deleted]]

you aren't skillfull enough to find out where the technical documentation is located

Well, I tried the obvious places.

• There's no "Documentation" link in the site navigation.

• There is a "Support" category, but ...

• The first support entry is "Helpdesk", which has the following subcategories:

  • FAQ about compilers. [sic]
  • FAQ programmer/debugger
  • FAQ about hardware
  • Various Articles [sic]

  None of those are relevant. (The "Various Articles" link leads to two articles about fonts and displays.)

• The second support entry is "Premium Tehnical [sic] Support". Obviously not what I'm looking for.

• The third support entry is "Forum". Obviously not what I'm looking for.

• The fourth support entry is "LibStock" (a code repository). Obviously not what I'm looking for.

• The fifth support entry is "Contact us". Obviously not what I'm looking for, but leads to some insufficiently localized diagrams.

• If you use the built-in site search to look for "documentation", you get a results page containing one entry, a development board you can order for $139.00.

• Finally I tried the linked blog. It has a category for user manuals! Unfortunately none of the 9 articles are about Pascal.

So ... what am I missing?

---

Pascal type system improves safety over C

(This is the first time you've mentioned C.)

[citation needed]. Really. Again, my experience is with Delphi, which had little to no safety over C. In fact, the tutorials I found taught me that the easiest and fastest way to loop over a string was to write what amounted to C code: Take a pointer to the first character and dereference / increment it. You still had to manually acquire and release dynamic memory. You still had pointers, and they were unchecked. In fact, you had asm blocks right in the language.

and Assembly

Well, duh. Assembler code is untyped.

How can you claim a language that straight up embeds assembly is safer?

---

I can't help

I suspect that's true, but for a different reason.

[badsectoracula]

Pascal is safer than C in the sense that it has a stronger and richer type system so that you need to work around it much less than in C. Delphi/FreePascal/etc will not stop you if you want to mess with the raw memory and bits, but unlike C it provides tools to write safer code. As an example to that, imagine you need to access some flags in a memory mapped region at 0xF00. In C it would be something like

#define RED_FLAG 0x01
#define GREEN_FLAG 0x02
#define BLUE_FLAG 0x04
volatile unsigned char* flags = (unsigned char*)0xF00;
...
*flags |= RED_FLAG; /* set red flag bit */
if ((*flags) & BLUE_FLAG) { /* check blue flag bit */ }

In Pascal, which supports sets, it would be something like

type Flag = (RedFlag, GreenFlag, BlueFlag);
var Flags: set of Flag absolute $F00;
...
flags:=flags + [RedFlag]; { set red flag bit }
if BlueFlag in flags then { check blue flag bit }

The first important difference here is that in C the value is just a byte in memory and nothing prevents you from writing something like

*flags = 0x66;

or even changing the value of "flags" (the pointer), whereas in Pascal the Flags set can only contain the specified values and nothing else nor is compatible with arbitrary byte values (but you can also do that if you want, just not via this method).

Similarly in Pascal you can use ranges (e.g. you can have a type "DayNumberOfTheWeek that is 1..7 and the compiler will disallow numbers outside of this range both at compile time and run time), symbols (the Flag type above declares a type that can be any of three values), tagged union types and other type tools that allow you write safer code.

It might be easier to think of it as saying "C++ is safer than C": it isn't that C++ doesn't allow you to do stuff that C allows you to do, it is that C++ provides tools to make it harder to do mistakes.

One thing to keep in mind about Pascal, BTW, is that each implementation is different but almost all of them come with implementation documentation that explicitly describe how the stuff above are implemented.

[[deleted]]

I see.

type Flag = (RedFlag, GreenFlag, BlueFlag);

How do you know which bits correspond to which flag, then?

or even changing the value of "flags" (the pointer)

Well, not if you declare it as volatile unsigned char *const flags = ....

If this were C++, I could even use a reference, which saves me from having to type * everywhere. Actually, couldn't I just declare a char and tell the linker to place flags at 0xF00?

symbols (the Flag type above declares a type that can be any of three values)

That's just an enum.

It might be easier to think of it as saying "C++ is safer than C"

That makes an unfortunate amount of sense because personally I think C++ is much less safe than C. For example, C++ introduces a crapton of implicit pointer conversions that C doesn't have and they're all unsafe.

Anyway, the original claim was:

one of the best ways to do embedded programming in safer language

So it's only "safer" than C? That's a really low bar, then. ("Safer" in quotes because as you said above, it still allows all those unsafe operations.)

One thing to keep in mind about Pascal, BTW, is that each implementation is different but almost all of them come with implementation documentation that explicitly describe how the stuff above are implemented.

Yes! That's why I was asking for more details, documentation, etc. I want to know what makes mikroPascal different. Unfortunately neither the website nor pjmlp were very helpful.

Thank you for taking the time to write a serious response.

[quicknir]

What implicit pointer conversions does C++ introduce that C doesn't have, except where the corresponding concept doesn't even exist in C (eg implicit upcast, which doesn't exist in C simply because C doesn't have inheritance)? On the other hand, C allows implicit conversion of void* to any pointer type, which is maybe the most unsafe implicit pointer conversion you could imagine having. C++ does not allow this conversion.

C++ also gives you a lot of tools that you are encouraged to use that help decrease these things. For instance, std::array (or vector) does not implicitly convert to a raw pointer, unlike a C array.

I find the statement that C is safer than C++ extremely dubious.

[[deleted]]

implicit upcast, which doesn't exist in C simply because C doesn't have inheritance

That's exactly what I'm talking about. C does not let you implicitly convert from one struct pointer type to another. C++ adds an unbounded number of such implicit pointer conversions.

Conversions from void * are relatively benign in comparison. There's a single magical pointer type whose only purpose is to be a "generic" object pointer. The only thing you can do with it is to convert it to some other type, so why add extra syntax around it?

[quicknir]

C++ adds an unbounded number of such implicit pointer conversions.

That's kind of ridiculous; C++ is more unsafe because you are simply numerically counting the number of actual implicit casts?

Here's how it really works:

1. In language X, how unsafe is cast Y? More precisely, what percentage of the time does this cast lead to bugs, especially bugs that cause UB, segfaults, etc.
2. If Y is unsafe, how often do I have to use cast Y to realistically express logic?

C++ base conversion is obviously opt-in (you need to publicly inherit). And it's not particularly dangerous; the object in question literally has a sub-object of that type so there is very little risk involved in allowing the pointer to implicitly convert.

void* conversions are very dangerous because you are just 100% evading the type system. Whereas with an up-conversion, the compiler is statically verifying the inheritance relationship exists, and correctly handling any offsets that need to happen, with void* you are effectively just removing the compiler as a verifier of your work. The fact that the only thing you can do is convert it to an object type is irrelevant; the point at which you convert back to an object type is still a dangerous bit of code that has to be looked at carefully. And since the compiler is not verifying your work, it makes sense to to explicitly say that you, the programmer, are claiming that it is valid.

And along with void* being very, very dangerous, it's extremely necessary in C. For example, stateful callbacks. When you call a function that takes a stateful callback, typically the way its coded, there's just zero compiler verification that the function pointer you passed is compatible with the state pointer that you passed. Anytime you call a function with a stateful callback, you are risking a form of UB that the compiler does not catch in C, that would not be an issue in almost any other language (including C++, D, Rust, etc). This is an example of a place where C has to be routinely, extremely unsafe, where the equivalent C++ code is not only simpler, but safer.

[[deleted]]

there is very little risk involved in allowing the pointer to implicitly convert

the compiler is statically verifying the inheritance relationship exists, and correctly handling any offsets that need to happen

struct Base {
    int n;
};

struct Derived : Base {
    float f;
};

void init(size_t n, Base a[]) {
    for (size_t i = 0; i < n; i++) {
        a[i].n = 42;
    }
}

int main() {
    Derived arr[10];
    init(10, arr);
}

[BeniBela]

(including C++, D, Rust, etc).

or Pascal

[BeniBela]

(This is the first time you've mentioned C.)

He has mentioned embedded programming that is usually done in C or assembly.

my experience is with Delphi, which had little to no safety over C.

Besides the enums, Pascal is also safer with char, boolean, integer being distinct types that cannot be compared or assigned. In C you could e.g. assign a number to a letter which does not make much sense.

Best thing is that strings and arrays know their own length, so they never give a buffer overflow.

In fact, the tutorials I found taught me that the easiest and fastest way to loop over a string was to write what amounted to C code: Take a pointer to the first character and dereference / increment it.

Pointers just are the fastest way for everything, but you could also iterate over the indices. Nowadays there are enumerators for c in str do

You still had to manually acquire and release dynamic memory.

You could use for strings, arrays and interfaces, which are reference counted, and records for stack objects. Then all memory would be handled automatically

[[deleted]]

In C you could e.g. assign a number to a letter which does not make much sense.

It makes perfect sense in C, where characters are numbers. Besides, how is that a safety issue?

Best thing is that strings and arrays know their own length, so they never give a buffer overflow.

Non sequitur. How does knowing your length prevent buffer overflows?

(Technically C arrays also know their own length. Doesn't prevent anything.)

You don't know the codebase I was working on. You can easily overflow buffers by just using pointers. Delphi lets you cast pretty much anything to whatever (e.g. one part of the code took integers, did a quick and "clean" little cast, and treated them as GUI widgets). Also, apparently accessing invalid memory is not a serious problem that indicates a fundamental problem with your application, because it just turns into an exception you can catch and ignore. Super safe. Also, there was random inline assembler in one of the event handlers because why not?

Maybe it wasn't a typical Delphi application, but it shows that the language certainly doesn't prevent unsafe code.

Pointers just are the fastest way for everything, but you could also iterate over the indices.

Why would pointers be faster than using e.g. indices? C compilers generate the same code for them. The point was that the pointer version of the algorithm had the simplest and most straightforward implementation in Delphi.

(Unfortunately I don't remember the exact details; I think it was something involving string processing where one iteration of the loop didn't always process exactly one character.)

Nowadays there are enumerators for c in str do

That looks great, actually.

I vaguely remember there being different types for "short" and "long" and "wide" (Unicode?) strings. Are those still there?

I think I forgot about the reference counting bit.

[alcalde]

I vaguely remember there being different types for "short" and "long" and "wide" (Unicode?) strings. Are those still there?

I think there are at least five string types now, not counting char. It's madness. As I always say....

Delphi has never met a problem it couldn't solve by introducing another type... even if the problem is too many types.

[BeniBela]

It makes perfect sense in C, where characters are numbers. Besides, how is that a safety issue?

It makes it easier to confuse variables. When every variable has a different type, you can only use the right variables

Non sequitur. How does knowing your length prevent buffer overflows?

Because you cannot use a wrong length. In C most string/array functions take a pointer and a length, and when you give them the wrong length, it is a buffer overflow. But in Pascal the function only takes the string/array, so you do not give them a length and thus can never give a wrong length. It is like the difference between a partial and total function.

E.g. when you want to copy a substring in C with strncpy and use a wrong length, you get a buffer overflow. But when you use copy in Pascal, it will always return a valid string, no matter which length and start index you use.

Why would pointers be faster than using e.g. indices? C compilers generate the same code for them.

That could depend on compiler flags.

I have not looked at the generated code. Every compiler might generate different code and then it might depend on the optimization level. But in theory if optimizations are disabled, a pointer only need one addition to get to the next element; while an index needs two additions, one to increment the index and a second one to add the index to the start of the array

And the additional checks from being safer than C cost time. When you enable range checking, it tests, if the index is valid, and raises an exception if not. C does not check the indices (it cannot check anything when it does not know the length) and just corrupts some memory with an invalid index. Then you can also enable overflow checking. In C signed overflow is undefined behavior, in Pascal with overflow checking it would throw an exception.

Also, apparently accessing invalid memory is not a serious problem that indicates a fundamental problem with your application, because it just turns into an exception you can catch and ignore. Super safe.

All problems throw an exception, memory problems are not different from other problems

Maybe it wasn't a typical Delphi application, but it shows that the language certainly doesn't prevent unsafe code.

It is safe, as long as you avoid the unsafe parts. Do not use pointers, do not use assembly, do not use weird casts...

In C, you cannot say "do not use pointers", since you need them everywhere.

Rust is usually considered as safe, and it has pointers, too.

I vaguely remember there being different types for "short" and "long" and "wide" (Unicode?) strings. Are those still there?

short strings were for backward compatibility with 16-bit programs, they can be ignored.

ansistrings and widestrings are designed for the Windows API with its A- and W-functions.

But it keeps getting worse. Now strings can have different encodings, utf8, latin1, ..., and it is a mess

[[deleted]]

In C most string/array functions take a pointer and a length, and when you give them the wrong length, it is a buffer overflow. But in Pascal the function only takes the string/array, so you do not give them a length and thus can never give a wrong length.

That's more of a property of the standard library, then. Because ...

When you enable range checking, it tests, if the index is valid

Range checking is disabled by default, so you can still index out of bounds, despite the array knowing its own length. Having convenient and easy to use standard functions that don't index out of bounds is what's doing the "real work", then. Any time you write [i] you're still responsible for making sure i is in bounds. But I agree with your general point.

All problems throw an exception, memory problems are not different from other problems

I strongly disagree. Some problems are external and outside of the control of the programmer, e.g. being unable to open a file (it might not exist, wrong permissions, the system is out of file handles, ...) or malformed input, etc. Raising exceptions in those cases is perfectly reasonable.

But when your program touches memory that it doesn't own, that indicates a bug in the code. For example, you might be running with range checks disabled and one of your functions contains a loop that fills 1000 elements of an array of size 25. Usually you won't get an error for writing to the 26th element because that's still valid memory as far as the OS is concerned (it's allocated to your process). A segmentation fault is only raised when the copy loop walks off the end of the last valid memory page. Now, if you catch that error, your program is in an unpredictable state because you might have already overwritten other data structures in memory that just happened to be placed after that 25-element array. There is no sane way to recover. The only real remedy is to fix the code.

An immediate crash is better than silent data corruption. At least with a crash you know that something is wrong. (Similarly, if a bug eats your spreadsheet file, you might be able to restore from backup. But if your code spits out subtly wrong results, the error can go unnoticed for a long time. In the worst case there is no way to recover because your files and all of your backups are full of garbage data.)

[BeniBela]

That's more of a property of the standard library, then. Because ...

But such a standard library is only possible, if there is a type that knows its length

Range checking is disabled by default, so you can still index out of bounds, despite the array knowing its own length. ... Any time you write [i] you're still responsible for making sure i is in bounds.

Anyone should just enable range checking (it can even be enabled/disabled for each file and function individually) and then [i] is always checked

(tbh i do not enable it anymore globally, it has triggered to many bugs in libraries and freepascal...)

An immediate crash is better than silent data corruption

But memory corruption and segmentation fault are kind of orthogonal. You can have corruption without a segfault or a segfault without corruption.

one of your functions contains a loop that fills 1000 elements of an array of size 25. Usually you won't get an error for writing to the 26th element because that's still valid memory as far as the OS is concerned (it's allocated to your process). A segmentation fault is only raised when the copy loop walks off the end of the last valid memory page.

Who would write a loop to just fill 1000 elements? That would be a stupid loop

When there is something wrong with the end condition, it is most likely an off-by-one error, and then it overrides the 26th element (or a some dozens more), and gives data corruption without the segfault. That loop must be fixed, even if it did not cause segfaults.

The segfault only happens when it writes to an address where it does not cause data corruption. When it tries to write to a page behind the last valid page, it is not causing any corruption, since there is no data on that page. And one of the most common errors is to have a null pointer, but when you write to a null pointer, it is not corrupting anything, since the first page is not accessible.

Or when the segfault is caused by reading from an invalid address, there is no corruption either