[lukaslalinsky]

When I was teen moving into adulthood, I couldn't understand why Pascal is being abandoned and people are moving into C and C++. I often think how would the software world look like if that did not happen. It's such a shame that we lost such a simple, yet productive language, in the commercial settings. And now we have Rust as the next winning choice, language even more complex than C++.

[cjfd]

Don't forget that, at least in the pascal that was used in my university programming course, all data structures have a fixed size. If you want variable size, you need to allocate them on the heap and free them manually, so it is not clear that this is going to be that much easier than C or C++ in practice. Actually attending the lecture about this I was a bit shocked that it was necessary to free memory manually and I thought to myself 'isn't this going to lead to a lot of trouble'. Turns out my 19-year-old self was right about that.

[p0w3n3d]

Why would you say that Pascal was (is?) a simple and productive? I wrote some software in Turbo Pascal and Delphi at that time, and was usually envying the C++ freedom. All the headers had to be translated to Pascal first. Pointer arithmetic was kludgy. I really wonder how could I do more complicated things, like large byte buffer with variant structures, parsing in Pascal.

[willvarfar]

Whereas if K&R had adopted Pascal (and tweaked the language to support whatever limitations they ran into when making the OS) instead of inventing C to make Unix, your experience would have been flipped; should C++ have come along, it would be the one with the header translation costs etc?

Wirth went on to create Modula2 and Oberon and make operating systems in them. It is fun to imagine a world where that was the way chosen forward instead of C to C++.

[p0w3n3d]

I believe C is closer to what happens in the computer, than the Pascal is. I am not advocating for C as I dreadfully fear of this language (though I have experience in it, it always fills me with respect when I'm getting to close). What I'm saying is that for example, LPS String implementation in Pascal is Pascal-specific, not ubiquitous in systems, and handling PChar in Pascal gives a headache. Simple task: call a Windows function with your own string from Pascal. (Maybe my experience is too old and I don't know that this has been solved already, but back when I tried it, it was a nightmare)

[badsectoracula]

FWIW that string bit has been solved since Delphi 2 introduced "huge strings", which are basically reference counted, copy-on-write null terminated strings. A variable of type "string" or "ansistring" (the former is an alias for the latter when huge strings are enabled, which are by default in Delphi 2 projects) is actually a pointer to the first character of the null terminated string, making it memory compatible with C calls (the "header" that contains reference count, etc is placed at a negative offset from the pointer).

With modern Delphi and Free Pascal (another object pascal dialect) you rarely have to worry about the differences between ansistrings and C strings.

(the name "ansistring" is kinda odd but blame Borland for that - though the odd name most likely helped avoid conflicts with existing Turbo Pascal and Delphi 1 code)

That said, i wouldn't call modern Pascal a simple language at all. Free Pascal for example has three different object oriented types that are all incompatible with each other and none cover all usage scenarios - and hidden "gotcha"s exist in the language ever since the early Delphi days like the implicit "Result" variable in functions treated as a "var" (passed by reference) parameter, meaning that a call like "Foo:=Bar" where "Foo" is a variable and "Bar" is a function and you'd expect "Bar" to be called and its result assigned to "Foo" actually has "Result" inside "Bar" be whatever "Foo" was because the statement is basically as if "Bar" had a single argument where "Foo" was passed by reference.

[pjmlp]

If we move beyond the original ISO Pascal from 1976, there is hardly any ISO C feature that isn't available in dialects like Object Pascal.

Even in C you cannot just give a char * to an Windows function, unless you are stuck using ANSI version of the APIs.

[t43562]

Headers are the huge achilles heel of the C-based languages. Pascals modules were MUCH better. Pascal always built code faster in my experience, because it wasn't parsing megabytes of headers just to compile a hello world program. This also probably makes a pascal compile much simpler to implement as it's not 2 languages layered together.

Macros in C are an utter disaster imo. If you want to get an AST for any piece of code you have to know what's defined so you must know exactly what the build system is going to do to the code i.e. the code isn't self-contained. If you use one build system to build for production and another in your IDE for development then you might get totally different results.

C,C++ have a lot of ways to do one thing and Pascal tends to have one. The more you have to work on other people's code the more attractive Pascals' "one way" seems.

[p0w3n3d]

what I mean is that once you want to access some API, the standard is C, so the headers you will get are in C. For example: windows.h. To do anything, either you have translated windows.pas, or you need to manually rewrite the function definitions. Another example: if you would like to access HongKong Exchange, you will receive a .so object and omni_api.h file, which is damn hard to understand, easier to use.

That's why I said about freedom.

[lukaslalinsky]

That was the point of my wondering, what if the standard was not C, but some modern Pascal. What if the APIs didn't involve any C headers.

[rjsw]

The standard was Pascal for the Macintosh, people still preferred to write in C.

[t43562]

Pascal had a different calling convention so you can "just" write all your libraries in pascal.

As you say, calling out to other libraries would need a translation but ..... it's the same for python or many other languages. It would be a bump in the road but not a disaster.

[lukaslalinsky]

I mostly meant the DOS era, when you accessed hardware directly, there were pretty much no libraries. Further on, if people did not start using C++, Pascal would have to evolve to allow writing the things that were previously done in assembly, and libraries would be done in that language as well. That did not happpen, so C++ won and writing Pascal code was even more complex because you had to brindge the C APIs.

[ikari_pl]

What things that were previously done in assembly do you mean?

I remember Delphi nicely allowed including C++ files and assembly in the project too, so there's that. It is a very wordy language, but apart from the need to separate declarations and implementation, was pretty nice to use, and powerful.

[lukaslalinsky]

Many kinds of byte or bit-level operations. I don't have access to much Turbo Pascal code, but it was always Pascal with a lot of inline assembly for specific things. Just found this using google, for example, https://github.com/nickelsworth/swag/blob/7c21c0da2291fc249b...

This kind of code was pretty typical.

[pjmlp]

H2Pas was a common tool back in the day.

You would use exactly that, a byte buffer with variant records.

The difference is that Wirth languages place correctness and safety before performance, apparently a common discussion subject across many goverment agencies nowadays.