6 ms·

Unless you want a C++ with a different syntax and less features then there's no reason to learn Pascal in 2023. And the syntax is much worse, you can't even de

Unless you want a C++ with a different syntax and less features then there's no reason to learn Pascal in 2023. And the syntax is much worse, you can't even declare variables in the middle of a function it has to go before the function. This slows you down from real work (art code comes later). It also makes worse code as declaring near the usage point makes code more clear.

whobre 3y ago
Can’t speak about Object Pascal, but the old Pascal was objectively better than C. You can like or dislike the differences in syntax, but Pascal’s type system was pretty solid which can’t be said about C
- bigbillheck 3y ago
  The way I remember the pascal type system is arrays of different lengths were different types.
  - filmor 3y ago
    They are pretty much everywhere when statically allocated.
    - zabzonk 3y ago
      well, not in c.
      - Kamq 3y ago
        I believe they are in C, but arrays degrade to pointers when you look at them wrong, and _those_ don't have length as part of their type. At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.
        zabzonk 3y ago
        > when you look at them wrong no, almost whenever you look at them. it is very hard to carry around the size of an array in C. > At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing. post some code that illustrates what you are talking about
        Kamq 3y ago
        I was trying to get clang to throw an error that included type information to double check what it thought the type was. Quickest thing I could think of was trying to assign to an array. The exact error in question was: error: array type 'int[3]' is not assignable Which seems to imply that clang is considering the length to be part of the type. edit: You asked for code (my apologies that it's rather trivial). int x[3] = {1, 2, 3}; int y[3]; y = x;
      - filmor 3y ago
        Even in C, citing the standard (6.2.4, 20): > Array types are characterized by their element type and by the number of elements in the array.
  - fuzztester 3y ago
    There's more to it than that. You could (from early Pascal days) and can have arrays where the array index range is a previously defined subrange of integers, or maybe even of an enumerated type. Then you have sets as a built-in type, which is big. Some more.
  - AnimalMuppet 3y ago
    In the original Pascal, that was true. The standard (and, I think, Jensen & Wirth) were that way. And it was a fatal flaw. I had a program that I took over that did a numerical simulation on a 2D grid with user-specified size. The original author simulated that 2D grid with a 1D doubly-linked list. As you might expect, this was both slow and error-prone. But he did it because there was no possible type that you could give to a user-sized array. There was literally no way to talk about such a thing. We eventually "fixed" it by allocating the largest 2D array possible within our memory limitations, and using only the user-specified part of it. Most "real" Pascals (Turbo Pascal, but others that were intended to be used in the real world, not just in the classroom) developed some way to give a type to a variable-length array (and also to do a C-ish cast). Unfortunately they all did it in different ways, so there was no code portability between compilers if your code needed such things. So, yeah, "objectively better than C" is quite a stretch, even just in the type system.
- pmelendez 3y ago
  > but Pascal’s type system was pretty solid To be honest, this is a matter of styles, coming from a dynamic type background I don’t appreciate strongly typed systems as an advantage.
  - Jtsummers 3y ago
    Strongly typed is orthogonal to dynamic and static typing. Python and Common Lisp are both "strongly" typed and dynamically typed. There's no reason to shun strong typing if you also like dynamic typing.
    - pmelendez 3y ago
      I would be curious to see references that claims that dynamic and static typing are orthogonal with strongly typed systems, as “strongly type” is rather ambiguous and the only reason I used the term was because that was how Pascal was promoted back in the day (or at least how was taught to me) From Wikipedia: In 1974, Liskov and S. Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function." Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages.
      - Jtsummers 3y ago
        You already found the wikipedia page, try reading it. See where it puts a lot of dynamically typed languages under the category of "strongly typed". You've decided it's a good enough source apparently. But really, I used "strongly" in quotes deliberately. It's a terrible phrase since it means nothing in practice because it can mean too many things (as that same page notes) that often are at odds with each other. > Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages. Even this definition would potentially exclude SML and OCaml where types are inferred, not declared. So according to you those two languages are weakly typed? I think a lot of people would be surprised to learn that.
- drpixie 3y ago
  Strong agree. I used the old Turbo Pascal for many years. It was quite routine to produce substantial programs where the compiler (and type system) had caught ALL the bugs. Meaning: you used sensible types (and had sensible libraries) and once the obvious compile-time errors were fixed, there would be zero bugs found in testing or in live! I like the flexibility of python, but I know that every substantial program has untested pathways that will fail when they come to be exercised :(
nopepon 3y ago
I've been playing around with Lazarus the last couple of weeks, and I can say there is at least one reason to learn pascal in 2023: it's fun!
musicale 3y ago
Delphi/Lazarus seems like a fairly productive environment. Also if I recall correctly some Pascal compilers (similarly to Ada) could actually generate somewhat memory safe code with array bounds checking, which is something that C/C++ usually lacks.
hulitu 3y ago
> you can't even declare variables in the middle of a function losing time with "static declaration follows non static" in C programs doesn't help either.
unnouinceput 3y ago
I never understood why is declaring variables in the middle of the code a "pro" for some. In my experience that's a "con" especially because of maintainability. Same way you do a comment before declaring a function to explain its purpose, you do a comment for each variable to declare its goal within said function. That's proper maintainability for a project. Also Delphi, for past 2 years, has this "middle" variable declaration style, and I hate it, never used it. So your comment missed the mark. If you want to advocate "don't learn Pascal in 2023" please do more research and come up with better argument.
- tnecniv 3y ago
  Like dynamic typing and other things, declaring things in the middle of your code block seemed like a great idea to young me, but as I’ve gotten older, things like organizing variable definitions, strict use of types (or the kind of sucky type hints in Python), and other kinds of self-documenting declarations have become much more appealing to me. It might save “real work” from happening if you measure by lines of code, but you pay that price later when debugging or reading code you haven’t touched in a long time.
- Al-Khwarizmi 3y ago
  A clear example of why it is a pro is the index of a for loop. Why would it be more maintainable to declare all for loop indexes at the beginning of a function? They are basically bound variables that are only meaningful within their loop, and they are usually not even worth commenting.
  - unnouinceput 3y ago
    More often than not, when maintenance really matter and juniors really choke, the algorithms that powers core functionality usually have nested loops and conditionals. So if you start using inline variable declaration you really have a hard time "where did this was declared". Combine that with compiler switches and you have a recipe for disaster when declaring inline variables vs. a clear section of variables right after function header, where you put all comments to specify what those variables do. Remember, initial phase of a project is only 10% of it, the maintenance and expanding its functionality is the rest of 90%. Inline variable declarations are a real PITA for that phase.
janoc 3y ago
That's completely missing the point. While Pascal can be used for serious work, it is first and foremost a teaching language friendly to beginners meant for introducing people (who back in the day) likely started with something like BASIC to concepts of structured and objects oriented programming. The syntax is easy to learn, fairly clean and the language has very fast compilation (C++ really can't compete here). Which is important when teaching - permits rapid iteration. Concerning archaic/rigid syntax - there are some good reasons why the syntax is like it is. E.g. the concept of declaring a variable in the middle of a block didn't exist in Pascal for a reason - you had to actually allocate memory before you used it, the compiler didn't hide this from you. That's why variables are declared at the start of the block. When Pascal has been designed it was running on various 8bit and 16bit machines and was originally compiled into bytecode (p-code), so optimizations like statement reordering common today (which permits to declare the variables in the middle of blocks) didn't exist/weren't possible/common. These days you have a ton of abstractions between you and the "metal" running your code, Pascal is a language designed for much simpler time and hardware.
- OnlyMortal 3y ago
  Much of the original Mac was Pascal based with 68k for performance pinch points. Of note it was faster to compile than C with MPW Shell.
- sigg3 3y ago
  I seem to recall Golang being inspired by it too, but I could be misremembering.
  - Kamq 3y ago
    I believe you're right. iirc, that's where the := notation comes from
- Al-Khwarizmi 3y ago
  I was teaching programming with Pascal until three years ago, and I think the pedagogical argument might have made sense in the past, but not in 2023 (or 10 years ago for that matter). The syntax is rigid in all the wrong places. For example, not being able to declare variables anywhere doesn't really help students, this isn't something that typically leads them to errors. What does lead to lots of errors? Dereferencing uninitialized pointers or going out of bounds in arrays, for example. And the language and compiler won't help you one bit there. Same opaque segmentation faults as with C, same unpredictable behavior as with C, but with worse tooling for debugging. Compilation time is not an issue in 2023 - well, maybe it is if you compare with C++, but C++ is about the worst non-joke language I can think of for learning (and it was my first language!). C, Java, Python, etc. are fast enough. Pascal had its time but I don't think there is much reason to use it now, outside of pure curiosity or wanting to try a historical language.
brokenkebaby 3y ago
Just a few days ago I found a bug in someone's code where a variable was introduced twice with slightly different name, like "var jobno", and then "var jobn". Made me think that Pascal's approach to keep vars declarations at one place is not a bad thing. As for slowing down - probably yes, but I doubt that speedtyping is really a big virtue for a software developer. Also, in a decent IDE it should be possible to make binding/macro to insert declaration after the current function header without jumping away from the current position (though I don't know what Pascal devs use nowadays for IDE)
gmiller123456 3y ago
C used to be that way too, but Pascal stopped evolving when it fell out of popularity.
chinabot 3y ago
recently did a conversion of a Delphi program to Java with some C++ and this is a strange argument to use. pressing F9 at any point in Delphi and having your program run a second later is incredible, that plus catching the vast majority of errors compile time certainly does not slow you down. Speed wise on this last conversion project with the same first level optimizations GCC is a good 50% faster, the Java parts feel about the same or a bit slower though, Disclaimer I never go to extreme optimization settings on compilers, was bitten several years back and happy to not go cutting edge. Also Pascal is much less toxic community for noobs I got to the point about ten years back I would rather not ask the question on-line for GCC due to the fact I would be branded stupid for not knowing some obscure linker setting or such like. end of my career now, happy Pascal was part of it, especially in the early Turbo Pascal DOS days, I doubt I would have carried on at the time if I was forced to use C (I later did and it wasnt that bad but I had to scratch my head at the time how people thought it better)
lelanthran 3y ago
> Unless you want a C++ with a different syntax and less features then there's no reason to learn Pascal in 2023. For me, personally, there there is a good reason to learn Pascal in 2023; the quick and almost painless ability to produce fast GUI applications. The alternatives are not nearly as polished or as nice.
delphi4711 3y ago
> you can't even declare variables in the middle of a function You can since Delphi 10.3. https://en.m.wikipedia.org/wiki/History_of_Delphi_(software) https://en.m.wikipedia.org/wiki/History_of_Delphi_(software)
clouddrover 3y ago
> you can't even declare variables in the middle of a function Yes you can: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Inline_Variable_Declaration https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Inli...
FpUser 3y ago
>"And the syntax is much worse, you can't even declare variables in the middle of a function it has to go before the function." I wish people would bother to check the facts before posting. It's been available for quite a while along with many more modern features.
Tozen 3y ago
Seems like you haven't been using the Object Pascal dialects of Delphi or PascalABC, which let you declare variables everywhere. In the case of Delphi, Embarcadero has been making it as easy as possible to switch between their Delphi and C++Builder products lines. For Free Pascal, the developers and many users voted against that, because it appears the opinion was it leads to sloppy code and unnecessary errors. The other point, is that Object Pascal has for a very long time allowed nested functions, so it wasn't arguably that much of an issue for those on that side. It seems more like C/C++ users wanted to force their habits on Pascal, which Embarcadero sold out to, for a few extra dollars. PascalABC, copied what Delphi was doing, who they use as a quasi-standard.

whobre 3y ago

Can’t speak about Object Pascal, but the old Pascal was objectively better than C. You can like or dislike the differences in syntax, but Pascal’s type system was pretty solid which can’t be said about C

bigbillheck 3y ago
The way I remember the pascal type system is arrays of different lengths were different types.
- filmor 3y ago
  They are pretty much everywhere when statically allocated.
  - zabzonk 3y ago
    well, not in c.
    - Kamq 3y ago
      I believe they are in C, but arrays degrade to pointers when you look at them wrong, and _those_ don't have length as part of their type. At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.
      - zabzonk 3y ago
        > when you look at them wrong no, almost whenever you look at them. it is very hard to carry around the size of an array in C. > At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing. post some code that illustrates what you are talking about
        Kamq 3y ago
        I was trying to get clang to throw an error that included type information to double check what it thought the type was. Quickest thing I could think of was trying to assign to an array. The exact error in question was: error: array type 'int[3]' is not assignable Which seems to imply that clang is considering the length to be part of the type. edit: You asked for code (my apologies that it's rather trivial). int x[3] = {1, 2, 3}; int y[3]; y = x;
    - filmor 3y ago
      Even in C, citing the standard (6.2.4, 20): > Array types are characterized by their element type and by the number of elements in the array.
- fuzztester 3y ago
  There's more to it than that. You could (from early Pascal days) and can have arrays where the array index range is a previously defined subrange of integers, or maybe even of an enumerated type. Then you have sets as a built-in type, which is big. Some more.
- AnimalMuppet 3y ago
  In the original Pascal, that was true. The standard (and, I think, Jensen & Wirth) were that way. And it was a fatal flaw. I had a program that I took over that did a numerical simulation on a 2D grid with user-specified size. The original author simulated that 2D grid with a 1D doubly-linked list. As you might expect, this was both slow and error-prone. But he did it because there was no possible type that you could give to a user-sized array. There was literally no way to talk about such a thing. We eventually "fixed" it by allocating the largest 2D array possible within our memory limitations, and using only the user-specified part of it. Most "real" Pascals (Turbo Pascal, but others that were intended to be used in the real world, not just in the classroom) developed some way to give a type to a variable-length array (and also to do a C-ish cast). Unfortunately they all did it in different ways, so there was no code portability between compilers if your code needed such things. So, yeah, "objectively better than C" is quite a stretch, even just in the type system.
pmelendez 3y ago
> but Pascal’s type system was pretty solid To be honest, this is a matter of styles, coming from a dynamic type background I don’t appreciate strongly typed systems as an advantage.
- Jtsummers 3y ago
  Strongly typed is orthogonal to dynamic and static typing. Python and Common Lisp are both "strongly" typed and dynamically typed. There's no reason to shun strong typing if you also like dynamic typing.
  - pmelendez 3y ago
    I would be curious to see references that claims that dynamic and static typing are orthogonal with strongly typed systems, as “strongly type” is rather ambiguous and the only reason I used the term was because that was how Pascal was promoted back in the day (or at least how was taught to me) From Wikipedia: In 1974, Liskov and S. Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function." Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages.
    - Jtsummers 3y ago
      You already found the wikipedia page, try reading it. See where it puts a lot of dynamically typed languages under the category of "strongly typed". You've decided it's a good enough source apparently. But really, I used "strongly" in quotes deliberately. It's a terrible phrase since it means nothing in practice because it can mean too many things (as that same page notes) that often are at odds with each other. > Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages. Even this definition would potentially exclude SML and OCaml where types are inferred, not declared. So according to you those two languages are weakly typed? I think a lot of people would be surprised to learn that.
drpixie 3y ago
Strong agree. I used the old Turbo Pascal for many years. It was quite routine to produce substantial programs where the compiler (and type system) had caught ALL the bugs. Meaning: you used sensible types (and had sensible libraries) and once the obvious compile-time errors were fixed, there would be zero bugs found in testing or in live! I like the flexibility of python, but I know that every substantial program has untested pathways that will fail when they come to be exercised :(

nopepon 3y ago

I've been playing around with Lazarus the last couple of weeks, and I can say there is at least one reason to learn pascal in 2023: it's fun!

musicale 3y ago

Delphi/Lazarus seems like a fairly productive environment. Also if I recall correctly some Pascal compilers (similarly to Ada) could actually generate somewhat memory safe code with array bounds checking, which is something that C/C++ usually lacks.

hulitu 3y ago

> you can't even declare variables in the middle of a function losing time with "static declaration follows non static" in C programs doesn't help either.

unnouinceput 3y ago

I never understood why is declaring variables in the middle of the code a "pro" for some. In my experience that's a "con" especially because of maintainability. Same way you do a comment before declaring a function to explain its purpose, you do a comment for each variable to declare its goal within said function. That's proper maintainability for a project. Also Delphi, for past 2 years, has this "middle" variable declaration style, and I hate it, never used it. So your comment missed the mark. If you want to advocate "don't learn Pascal in 2023" please do more research and come up with better argument.

tnecniv 3y ago
Like dynamic typing and other things, declaring things in the middle of your code block seemed like a great idea to young me, but as I’ve gotten older, things like organizing variable definitions, strict use of types (or the kind of sucky type hints in Python), and other kinds of self-documenting declarations have become much more appealing to me. It might save “real work” from happening if you measure by lines of code, but you pay that price later when debugging or reading code you haven’t touched in a long time.
Al-Khwarizmi 3y ago
A clear example of why it is a pro is the index of a for loop. Why would it be more maintainable to declare all for loop indexes at the beginning of a function? They are basically bound variables that are only meaningful within their loop, and they are usually not even worth commenting.
- unnouinceput 3y ago
  More often than not, when maintenance really matter and juniors really choke, the algorithms that powers core functionality usually have nested loops and conditionals. So if you start using inline variable declaration you really have a hard time "where did this was declared". Combine that with compiler switches and you have a recipe for disaster when declaring inline variables vs. a clear section of variables right after function header, where you put all comments to specify what those variables do. Remember, initial phase of a project is only 10% of it, the maintenance and expanding its functionality is the rest of 90%. Inline variable declarations are a real PITA for that phase.

janoc 3y ago

That's completely missing the point. While Pascal can be used for serious work, it is first and foremost a teaching language friendly to beginners meant for introducing people (who back in the day) likely started with something like BASIC to concepts of structured and objects oriented programming. The syntax is easy to learn, fairly clean and the language has very fast compilation (C++ really can't compete here). Which is important when teaching - permits rapid iteration. Concerning archaic/rigid syntax - there are some good reasons why the syntax is like it is. E.g. the concept of declaring a variable in the middle of a block didn't exist in Pascal for a reason - you had to actually allocate memory before you used it, the compiler didn't hide this from you. That's why variables are declared at the start of the block. When Pascal has been designed it was running on various 8bit and 16bit machines and was originally compiled into bytecode (p-code), so optimizations like statement reordering common today (which permits to declare the variables in the middle of blocks) didn't exist/weren't possible/common. These days you have a ton of abstractions between you and the "metal" running your code, Pascal is a language designed for much simpler time and hardware.

OnlyMortal 3y ago
Much of the original Mac was Pascal based with 68k for performance pinch points. Of note it was faster to compile than C with MPW Shell.
sigg3 3y ago
I seem to recall Golang being inspired by it too, but I could be misremembering.
- Kamq 3y ago
  I believe you're right. iirc, that's where the := notation comes from
Al-Khwarizmi 3y ago
I was teaching programming with Pascal until three years ago, and I think the pedagogical argument might have made sense in the past, but not in 2023 (or 10 years ago for that matter). The syntax is rigid in all the wrong places. For example, not being able to declare variables anywhere doesn't really help students, this isn't something that typically leads them to errors. What does lead to lots of errors? Dereferencing uninitialized pointers or going out of bounds in arrays, for example. And the language and compiler won't help you one bit there. Same opaque segmentation faults as with C, same unpredictable behavior as with C, but with worse tooling for debugging. Compilation time is not an issue in 2023 - well, maybe it is if you compare with C++, but C++ is about the worst non-joke language I can think of for learning (and it was my first language!). C, Java, Python, etc. are fast enough. Pascal had its time but I don't think there is much reason to use it now, outside of pure curiosity or wanting to try a historical language.

brokenkebaby 3y ago

Just a few days ago I found a bug in someone's code where a variable was introduced twice with slightly different name, like "var jobno", and then "var jobn". Made me think that Pascal's approach to keep vars declarations at one place is not a bad thing. As for slowing down - probably yes, but I doubt that speedtyping is really a big virtue for a software developer. Also, in a decent IDE it should be possible to make binding/macro to insert declaration after the current function header without jumping away from the current position (though I don't know what Pascal devs use nowadays for IDE)

gmiller123456 3y ago

C used to be that way too, but Pascal stopped evolving when it fell out of popularity.

chinabot 3y ago

recently did a conversion of a Delphi program to Java with some C++ and this is a strange argument to use. pressing F9 at any point in Delphi and having your program run a second later is incredible, that plus catching the vast majority of errors compile time certainly does not slow you down. Speed wise on this last conversion project with the same first level optimizations GCC is a good 50% faster, the Java parts feel about the same or a bit slower though, Disclaimer I never go to extreme optimization settings on compilers, was bitten several years back and happy to not go cutting edge. Also Pascal is much less toxic community for noobs I got to the point about ten years back I would rather not ask the question on-line for GCC due to the fact I would be branded stupid for not knowing some obscure linker setting or such like. end of my career now, happy Pascal was part of it, especially in the early Turbo Pascal DOS days, I doubt I would have carried on at the time if I was forced to use C (I later did and it wasnt that bad but I had to scratch my head at the time how people thought it better)

lelanthran 3y ago

> Unless you want a C++ with a different syntax and less features then there's no reason to learn Pascal in 2023. For me, personally, there there is a good reason to learn Pascal in 2023; the quick and almost painless ability to produce fast GUI applications. The alternatives are not nearly as polished or as nice.

delphi4711 3y ago

> you can't even declare variables in the middle of a function You can since Delphi 10.3. https://en.m.wikipedia.org/wiki/History_of_Delphi_(software) https://en.m.wikipedia.org/wiki/History_of_Delphi_(software)

clouddrover 3y ago

> you can't even declare variables in the middle of a function Yes you can: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Inline_Variable_Declaration https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Inli...

FpUser 3y ago

>"And the syntax is much worse, you can't even declare variables in the middle of a function it has to go before the function." I wish people would bother to check the facts before posting. It's been available for quite a while along with many more modern features.

Tozen 3y ago

Seems like you haven't been using the Object Pascal dialects of Delphi or PascalABC, which let you declare variables everywhere. In the case of Delphi, Embarcadero has been making it as easy as possible to switch between their Delphi and C++Builder products lines. For Free Pascal, the developers and many users voted against that, because it appears the opinion was it leads to sloppy code and unnecessary errors. The other point, is that Object Pascal has for a very long time allowed nested functions, so it wasn't arguably that much of an issue for those on that side. It seems more like C/C++ users wanted to force their habits on Pascal, which Embarcadero sold out to, for a few extra dollars. PascalABC, copied what Delphi was doing, who they use as a quasi-standard.