5 ms·

Does Pascal allow a programmer to shoot themselves in the foot the way that C does? Does it have safer memory handling?

narag 8y ago
What some younger programmers don't get is that allowing to do things is good, the real question is what style a language encourages.
- seba_dos1 8y ago
  Younger programmers usually believe that the best thing is the one that allows you to effortlessly do anything you want. Only later they start to see that some limitations and hurdles might actually be beneficial.
  - narag 8y ago
    I was careful to qualify "some" programmers and avoid generalization. Some younger programmers like this, some others like that. The difference is in ancient times I don't remember so many people liking discipline languages. Funny thing is Pascal was seen as the constraints language at that time, while C was more liberal. Different times. In Pascal evolution (Delphi and Lazarus), a lot of automatic memory management, including proper gc but most often simple referemce count, has been incorporated over the years. Also the memory for a lot of standard library resources is managed hierarchically. In short: You still need to know how to deal with memory manually, but most of the time you don't.
fetbaffe 8y ago
It is harder to shoot yourself in the foot with Pascal because you rarely use raw pointers.
pjmlp 8y ago
The original Pascal not, but the ISO Extended Pascal and all dialects compatible with Apple and Borland ones, yes. The big difference with C is that you need to be explicit that you are going to do something that might go wrong. For example, arrays and strings have bound checking. If you want disable it, you can, either via compiler switch, or a pragma like {$R-} and {$R+} around a code section. Likewise you don't need pointers for out parameters, because references are supported as well. Pointer arithmetic is possible, but first you need to convert the address into a pointer type, then you can manipulate it like on C. Enumerations are their own type, instead of being implicit numbers, without any check if they can be converted back.
lukaslalinsky 8y ago
Pretty much all non-trivial Pascal code from that era included inline assembly. Either for performance or for accessing some low level functionality. That's the ultimately gun for shooting yourself.
masklinn 8y ago
Safer yes (pointers were less ubiquitous and much safer) and it had other type-safety features like subranges (~refinement types), sets, type-safe enums (though not proper sum types), … It had a raft of issues though, chiefly a lack of dynamically sized arrays and strings ("pascal strings" combine a static maximum size of no more than 255 with a single-byte actual-length prefix, IIRC all on the stack) or rudimentary dependent typing making generic processing of these extremely difficult[0], no ability to break (out of loops) or early-return, undefined order of evaluation of boolean expressions (and/or), … Kernighan actually wrote an entire "Why Pascal is Not My Favorite Programming Language" essay in '81 More modern evolution have related/fixed some of these since, not necessarily in great ways (freepascal's "String" can use one of 3 different string implementations depending on compiler settings & active pragmas[1], and that's a small subsets of the actual stable of string implementation available) [0] outside of builtins (which weren't limited to the language's "user" semantics much like Go today) you'd need an implementation for each static length of array/string [1] http://wiki.freepascal.org/Character_and_string_types#String http://wiki.freepascal.org/Character_and_string_types#String

What some younger programmers don't get is that allowing to do things is good, the real question is what style a language encourages.

seba_dos1 8y ago
Younger programmers usually believe that the best thing is the one that allows you to effortlessly do anything you want. Only later they start to see that some limitations and hurdles might actually be beneficial.
- narag 8y ago
  I was careful to qualify "some" programmers and avoid generalization. Some younger programmers like this, some others like that. The difference is in ancient times I don't remember so many people liking discipline languages. Funny thing is Pascal was seen as the constraints language at that time, while C was more liberal. Different times. In Pascal evolution (Delphi and Lazarus), a lot of automatic memory management, including proper gc but most often simple referemce count, has been incorporated over the years. Also the memory for a lot of standard library resources is managed hierarchically. In short: You still need to know how to deal with memory manually, but most of the time you don't.

fetbaffe 8y ago

It is harder to shoot yourself in the foot with Pascal because you rarely use raw pointers.

pjmlp 8y ago

The original Pascal not, but the ISO Extended Pascal and all dialects compatible with Apple and Borland ones, yes. The big difference with C is that you need to be explicit that you are going to do something that might go wrong. For example, arrays and strings have bound checking. If you want disable it, you can, either via compiler switch, or a pragma like {$R-} and {$R+} around a code section. Likewise you don't need pointers for out parameters, because references are supported as well. Pointer arithmetic is possible, but first you need to convert the address into a pointer type, then you can manipulate it like on C. Enumerations are their own type, instead of being implicit numbers, without any check if they can be converted back.

lukaslalinsky 8y ago

Pretty much all non-trivial Pascal code from that era included inline assembly. Either for performance or for accessing some low level functionality. That's the ultimately gun for shooting yourself.

masklinn 8y ago

Safer yes (pointers were less ubiquitous and much safer) and it had other type-safety features like subranges (~refinement types), sets, type-safe enums (though not proper sum types), … It had a raft of issues though, chiefly a lack of dynamically sized arrays and strings ("pascal strings" combine a static maximum size of no more than 255 with a single-byte actual-length prefix, IIRC all on the stack) or rudimentary dependent typing making generic processing of these extremely difficult[0], no ability to break (out of loops) or early-return, undefined order of evaluation of boolean expressions (and/or), … Kernighan actually wrote an entire "Why Pascal is Not My Favorite Programming Language" essay in '81 More modern evolution have related/fixed some of these since, not necessarily in great ways (freepascal's "String" can use one of 3 different string implementations depending on compiler settings & active pragmas[1], and that's a small subsets of the actual stable of string implementation available) [0] outside of builtins (which weren't limited to the language's "user" semantics much like Go today) you'd need an implementation for each static length of array/string [1] http://wiki.freepascal.org/Character_and_string_types#String http://wiki.freepascal.org/Character_and_string_types#String