10 ms·

Having had to work in a large pascal codebase, I don't ever want to use this language again. No metaprogramming in the language meant we had some parts of the

Having had to work in a large pascal codebase, I don't ever want to use this language again. No metaprogramming in the language meant we had some parts of the code that were written in pascal to generate pascal code before compilation of the main project. The code was so verbose, and to get the same thing done in alternative languages would have easily been twice as shorter. Refactoring always took twice as long as I thought it would. Just moving semicolons around was enough to break my concentration when I was in the flow. I think the kicker was identifiers being case insensitive. That alone would have been enough to drive me crazy. People complain about Nim's case insensitive features a lot, but Nim's implementation is actually good and orders of magnitude better than Pascal's. Also hiring a good pascal programmer was next to impossible for us at the time. I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc.

freilanzer 3y ago
Go also lacks metaprogramming, right?
- tgv 3y ago
  Yes, but there is decent support for code generation. E.g., you can easily get the syntax tree of a go program.
  - speed_spread 3y ago
    Maybe the tools aren't there but there's no reason you couldn't parse Pascal the same way. It's not a complicated language.
    - badsectoracula 3y ago
      FWIW Free Pascal's FCL has the fcl-passrc package that provides units for scanning FPC code, building syntax trees, resolving identifier references and writing/formatting source code. Free Pascal comes with pas2js which "transpiles" Free Pascal code to Java Script and is written using fcl-passrc so it should have enough functionality to parse most FPC code.
    - tgv 3y ago
      Go neither, but parsing and AST are in the standard library, and code generation is in the standard build process. All it requires is an (ugly) comment line in your source code. So you've got decent and standard tooling. No make magic required.
DeathArrow 3y ago
> Having had to work in a large pascal codebase, I don't ever want to use this language again. Maybe Pascal isn't good for large code bases, but the same is true for Python, too. And nobody hates Python.
- pavlov 3y ago
  I hate Python, and I've met others who feel the same. It's a language which had a reason to exist 25 years ago, but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax. So a lot like Pascal actually. (To be fair to Pascal, its syntax wasn't anything as inconsistent and frustrating as Python's.)
  - bluetomcat 3y ago
    Python has become the lowest common denominator. It's a practical "no-frills" language that can be picked quickly by a sysadmin, a web developer, a scientist doing number-crunching or a kid automating their homework.
    - pavlov 3y ago
      The problem with the “no-frills” proposition is that it’s loaded with frills, complexities, and decades of tech debt. Just installing dependencies for a Python project can feel insurmountable. IMO JavaScript should be the default for any Python use case. It has the same deceptive veneer of beginner-friendly dynamic behavior, same kinds of footguns; but at least JS has a single package manager, much faster optimized engines, and you’d have to learn it for front-end work anyway so it has long-term dividends.
      - alex_suzuki 3y ago
        One of things I really like about Python is the huge standard library. Contrary to JavaScript (which I think is a really weird recommendation), where you need to npm install half the world.
dom96 3y ago
> People complain about Nim's case insensitive features a lot, but Nim's implementation is actually good and orders of magnitude better than Pascal's. Can you elaborate on this? In what ways specifically is it better?
signaru 3y ago
Lazarus is a compelling reason to pick Pascal. But I share your pain and had been looking for alternatives for machine-code-compiled RAD GUIs. To add, only modern Delphi supports var declarations that can be placed elsewhere other than the top of the function.
- Tozen 3y ago
  Actually, the PascalABC dialect[1][2] supports using variables in that way too. However, I've seen arguments that allowing variable declarations anywhere tends to lead to sloppier coding and unnecessary errors, so Free Pascal/Lazarus has not followed that trend. It also appears that Delphi/Embarcadero may have went in that direction to synchronize their C++Builder and Delphi products, to make it easier to jump between them. 1. https://pascalabc.net/en/ https://pascalabc.net/en/ (PascalABC) 2. https://github.com/pascalabcnet/pascalabcnet https://github.com/pascalabcnet/pascalabcnet (PascalABC GitHub)
  - signaru 3y ago
    PascalABC seems to only target dot NET though.
stefanos82 3y ago
> No metaprogramming in the language meant we had some parts of the code that were written in pascal to generate pascal code before compilation of the main project. Weird...if you are talking about Generics, FreePascal has them and work just fine, plus it compiles instantly! Here's a demo: program UseGenerics; {$mode objfpc}{$H+} type generic TFakeClass<_GT> = class class function gmax(a,b: _GT): _GT; end; TFakeClassInt = specialize TFakeClass<integer>; TFakeClassDouble = specialize TFakeClass<double>; class function TFakeClass.gmax(a,b: _GT): _GT; begin if a > b then result := a else result := b; end; begin { show max of two integers } writeln('Integer GMax: ', TFakeClassInt.gmax(23, 56)); { show max of two doubles } writeln('Double GMax: ', TFakeClassDouble.gmax(23.89, 56.5)); end.
- dannymi 3y ago
  Yes, but this example of matrix multiplication does weird stuff: {$MODE DELPHI} {$modeswitch advancedrecords} type TMatrix<T, R, C> = record fCoordinates: array[R, C] of Double; end; function mul<T, R, X, C>(A: TMatrix<T, R, X>; B: TMatrix<T, X, C>): TMatrix<T, R, C>; var i: R; j: X; k: C; begin Writeln('yep'); Writeln(High(R)); // 3 Writeln(High(X)); // 4 Writeln(High(C)); // 3 for i := Low(R) to High(R) do for k := Low(C) to High(C) do begin Result.fCoordinates[i, k] := 0; for j := Low(X) to High(X) do Result.fCoordinates[i, k] += A.fCoordinates[i, j] * B.fCoordinates[j, k] end end; type R1 = 1..3; R2 = 1..4; var A: TMatrix<Double, R1, R2>; B: TMatrix<Double, R1, R1>; C: TMatrix<Double, R2, R1>; begin mul<Double, R1, R2, R1>(A,B); // should fail because B would have to have as many rows as A has columns--and it doesn't. mul(A,C) // does not work even with a right-size C--even though it should end.
  - badsectoracula 3y ago
    The second bit is because you lack the explicit specialization - you must always tell the compiler how to specialize a generic. Personally i prefer to use generics in objfpc mode as you are more explicit that way. However FPC trunk can allow implicit function specialization if you request it with {$modeswitch implicitfunctionspecialization}. Your code compiles with that. The first bit is an interesting case and i wonder why it happens. It seems the root cause is that it considers the two type specializations equivalent as even ignoring the generic functions something like "A:=B" is allowed. I trimmed the code down to this: {$MODE DELPHI} type TMatrix<R, C> = record X: array[R, C] of Double; end; type R1 = 1..3; R2 = 1..4; var A: TMatrix<R1, R2>; B: TMatrix<R1, R1>; begin A:=B; end. This is clearly a bug and not intentional behavior as doing the specialization by hand shows an error as expected. Also it seems related to multidimensional arrays as with a single element it also shows an error. Note that the other way (B:=A) doesn't work, so my guess is that at some point the type compatibility comparison only checks if assigning one array would fit memory-wise into the other. I'll check against latest trunk later and if it happens i'll file a bug report.
nurettin 3y ago
From the point of view of someone who has worked on MLOC delphi projects for seven years: * The language has evolved. Delphi's pascal compiler has generics, lambda expressions for both proc and function, it has containers, map and filter functions. * Design-time: You know how your code will behave without running it, as you are dragging and dropping components. It will draw data from your database and show it in dropdowns and grids. You have fine-tuned control ober widget alignment and anchoring . * Data modules: Having your orm and data layer as composable components enforce separation of ui and db operations. * Devexpress: They make the best grid components by far. I use their web products as well. For the cases Delphi is a great choice, I'd steer clear as far as possible from julia, zig, go and nim. Maybe C# comes close.
- adgjlsfhk1 3y ago
  Why stay clear from julia, zig, go and nim?
  - nurettin 3y ago
    Because I think Delphi is a better choice if you want to program a desktop application with design time support and a decent nested grid.
baq 3y ago
Go is basically Pascal with a sprinkle of first class concurrency anyway…
- anta40 3y ago
  One of Go's designer, Rob Griesemer, was a Phd student Niklaus Wirth. Hmm...
  - pjmlp 3y ago
    Go's method syntax is taken from Oberon-2, just like unsafe package is pretty much the same purpose as SYSTEM.
    - AnimalMuppet 3y ago
      And, if I understand correctly, Go stole its object file format (or at least large-scale design) from Modula-2.
      - pjmlp 3y ago
        That I doubt it, given Modula-2 package design, how symbols are made public and type system differences. If you mean packages as modules, other languages predate Modula-2 in that matter.
        AnimalMuppet 3y ago
        No, I mean the object file defines the public symbols at the start of the file. Go very deliberately stole that feature. Rob Pike said that using that idea let Go do something faster when compiling, though I don't remember the details.
- Tozen 3y ago
  There is some embellishment in that statement, but people coming from Pascal/Oberon would likely feel much more comfortable using Go, than other C family languages. This would also include Vlang, and to an extent, Odin as well. These two have both been heavily influenced by Go and Pascal.
anta40 3y ago
I don't write desktop apps these days... but if I have to, my #1 choice is easily Pascal + Lazarus. For non-GUI apps, sure probably Nim, Rust or Go.
- Pet_Ant 3y ago
  If I had to do a desktop app I’d with Java Swing because of the Java backend libraries and developers. Were I yo ignore those factors I’d go with Gambas for the drag & drop gui.
  - anta40 3y ago
    I still write Java codes... for Android, though. When were the last time I code in Swing/JavaFX? 4 or 5 years ago, perhaps. The 3rd party libs available for Delphi/FPC are more than enough for my needs.
lelanthran 3y ago
Because none of those alternatives have anything close to Lazarus.
augustk 3y ago
> I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc. Pascal evolved into Modula-2 and then Oberon which is both smaller and more powerful. https://miasap.se/obnc/oberon-report.html https://miasap.se/obnc/oberon-report.html
squarefoot 3y ago
> I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc. When writing desktop apps probably the familiarity with well known IDEs such as Delphi or Lazarus makes the difference. Unfortunately decades passed, still nothing comes even close to them for rapid GUI development. Should one day Lazarus support different languages such as the ones you mentioned, we'll probably hear a rumble around the world. However things in certain fields progress much quicker, and I wouldn't be surprised at all if in some time we could use AI to analyze a drawing then create the corresponding desktop interface description to be linked with non GUI code.

freilanzer 3y ago

Go also lacks metaprogramming, right?

tgv 3y ago
Yes, but there is decent support for code generation. E.g., you can easily get the syntax tree of a go program.
- speed_spread 3y ago
  Maybe the tools aren't there but there's no reason you couldn't parse Pascal the same way. It's not a complicated language.
  - badsectoracula 3y ago
    FWIW Free Pascal's FCL has the fcl-passrc package that provides units for scanning FPC code, building syntax trees, resolving identifier references and writing/formatting source code. Free Pascal comes with pas2js which "transpiles" Free Pascal code to Java Script and is written using fcl-passrc so it should have enough functionality to parse most FPC code.
  - tgv 3y ago
    Go neither, but parsing and AST are in the standard library, and code generation is in the standard build process. All it requires is an (ugly) comment line in your source code. So you've got decent and standard tooling. No make magic required.

DeathArrow 3y ago

> Having had to work in a large pascal codebase, I don't ever want to use this language again. Maybe Pascal isn't good for large code bases, but the same is true for Python, too. And nobody hates Python.

pavlov 3y ago
I hate Python, and I've met others who feel the same. It's a language which had a reason to exist 25 years ago, but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax. So a lot like Pascal actually. (To be fair to Pascal, its syntax wasn't anything as inconsistent and frustrating as Python's.)
- bluetomcat 3y ago
  Python has become the lowest common denominator. It's a practical "no-frills" language that can be picked quickly by a sysadmin, a web developer, a scientist doing number-crunching or a kid automating their homework.
  - pavlov 3y ago
    The problem with the “no-frills” proposition is that it’s loaded with frills, complexities, and decades of tech debt. Just installing dependencies for a Python project can feel insurmountable. IMO JavaScript should be the default for any Python use case. It has the same deceptive veneer of beginner-friendly dynamic behavior, same kinds of footguns; but at least JS has a single package manager, much faster optimized engines, and you’d have to learn it for front-end work anyway so it has long-term dividends.
    - alex_suzuki 3y ago
      One of things I really like about Python is the huge standard library. Contrary to JavaScript (which I think is a really weird recommendation), where you need to npm install half the world.

dom96 3y ago

> People complain about Nim's case insensitive features a lot, but Nim's implementation is actually good and orders of magnitude better than Pascal's. Can you elaborate on this? In what ways specifically is it better?

signaru 3y ago

Lazarus is a compelling reason to pick Pascal. But I share your pain and had been looking for alternatives for machine-code-compiled RAD GUIs. To add, only modern Delphi supports var declarations that can be placed elsewhere other than the top of the function.

Tozen 3y ago
Actually, the PascalABC dialect[1][2] supports using variables in that way too. However, I've seen arguments that allowing variable declarations anywhere tends to lead to sloppier coding and unnecessary errors, so Free Pascal/Lazarus has not followed that trend. It also appears that Delphi/Embarcadero may have went in that direction to synchronize their C++Builder and Delphi products, to make it easier to jump between them. 1. https://pascalabc.net/en/ https://pascalabc.net/en/ (PascalABC) 2. https://github.com/pascalabcnet/pascalabcnet https://github.com/pascalabcnet/pascalabcnet (PascalABC GitHub)
- signaru 3y ago
  PascalABC seems to only target dot NET though.

stefanos82 3y ago

> No metaprogramming in the language meant we had some parts of the code that were written in pascal to generate pascal code before compilation of the main project. Weird...if you are talking about Generics, FreePascal has them and work just fine, plus it compiles instantly! Here's a demo: program UseGenerics; {$mode objfpc}{$H+} type generic TFakeClass<_GT> = class class function gmax(a,b: _GT): _GT; end; TFakeClassInt = specialize TFakeClass<integer>; TFakeClassDouble = specialize TFakeClass<double>; class function TFakeClass.gmax(a,b: _GT): _GT; begin if a > b then result := a else result := b; end; begin { show max of two integers } writeln('Integer GMax: ', TFakeClassInt.gmax(23, 56)); { show max of two doubles } writeln('Double GMax: ', TFakeClassDouble.gmax(23.89, 56.5)); end.

dannymi 3y ago
Yes, but this example of matrix multiplication does weird stuff: {$MODE DELPHI} {$modeswitch advancedrecords} type TMatrix<T, R, C> = record fCoordinates: array[R, C] of Double; end; function mul<T, R, X, C>(A: TMatrix<T, R, X>; B: TMatrix<T, X, C>): TMatrix<T, R, C>; var i: R; j: X; k: C; begin Writeln('yep'); Writeln(High(R)); // 3 Writeln(High(X)); // 4 Writeln(High(C)); // 3 for i := Low(R) to High(R) do for k := Low(C) to High(C) do begin Result.fCoordinates[i, k] := 0; for j := Low(X) to High(X) do Result.fCoordinates[i, k] += A.fCoordinates[i, j] * B.fCoordinates[j, k] end end; type R1 = 1..3; R2 = 1..4; var A: TMatrix<Double, R1, R2>; B: TMatrix<Double, R1, R1>; C: TMatrix<Double, R2, R1>; begin mul<Double, R1, R2, R1>(A,B); // should fail because B would have to have as many rows as A has columns--and it doesn't. mul(A,C) // does not work even with a right-size C--even though it should end.
- badsectoracula 3y ago
  The second bit is because you lack the explicit specialization - you must always tell the compiler how to specialize a generic. Personally i prefer to use generics in objfpc mode as you are more explicit that way. However FPC trunk can allow implicit function specialization if you request it with {$modeswitch implicitfunctionspecialization}. Your code compiles with that. The first bit is an interesting case and i wonder why it happens. It seems the root cause is that it considers the two type specializations equivalent as even ignoring the generic functions something like "A:=B" is allowed. I trimmed the code down to this: {$MODE DELPHI} type TMatrix<R, C> = record X: array[R, C] of Double; end; type R1 = 1..3; R2 = 1..4; var A: TMatrix<R1, R2>; B: TMatrix<R1, R1>; begin A:=B; end. This is clearly a bug and not intentional behavior as doing the specialization by hand shows an error as expected. Also it seems related to multidimensional arrays as with a single element it also shows an error. Note that the other way (B:=A) doesn't work, so my guess is that at some point the type compatibility comparison only checks if assigning one array would fit memory-wise into the other. I'll check against latest trunk later and if it happens i'll file a bug report.

nurettin 3y ago

From the point of view of someone who has worked on MLOC delphi projects for seven years: * The language has evolved. Delphi's pascal compiler has generics, lambda expressions for both proc and function, it has containers, map and filter functions. * Design-time: You know how your code will behave without running it, as you are dragging and dropping components. It will draw data from your database and show it in dropdowns and grids. You have fine-tuned control ober widget alignment and anchoring . * Data modules: Having your orm and data layer as composable components enforce separation of ui and db operations. * Devexpress: They make the best grid components by far. I use their web products as well. For the cases Delphi is a great choice, I'd steer clear as far as possible from julia, zig, go and nim. Maybe C# comes close.

adgjlsfhk1 3y ago
Why stay clear from julia, zig, go and nim?
- nurettin 3y ago
  Because I think Delphi is a better choice if you want to program a desktop application with design time support and a decent nested grid.

baq 3y ago

Go is basically Pascal with a sprinkle of first class concurrency anyway…

anta40 3y ago
One of Go's designer, Rob Griesemer, was a Phd student Niklaus Wirth. Hmm...
- pjmlp 3y ago
  Go's method syntax is taken from Oberon-2, just like unsafe package is pretty much the same purpose as SYSTEM.
  - AnimalMuppet 3y ago
    And, if I understand correctly, Go stole its object file format (or at least large-scale design) from Modula-2.
    - pjmlp 3y ago
      That I doubt it, given Modula-2 package design, how symbols are made public and type system differences. If you mean packages as modules, other languages predate Modula-2 in that matter.
      - AnimalMuppet 3y ago
        No, I mean the object file defines the public symbols at the start of the file. Go very deliberately stole that feature. Rob Pike said that using that idea let Go do something faster when compiling, though I don't remember the details.
Tozen 3y ago
There is some embellishment in that statement, but people coming from Pascal/Oberon would likely feel much more comfortable using Go, than other C family languages. This would also include Vlang, and to an extent, Odin as well. These two have both been heavily influenced by Go and Pascal.

anta40 3y ago

I don't write desktop apps these days... but if I have to, my #1 choice is easily Pascal + Lazarus. For non-GUI apps, sure probably Nim, Rust or Go.

Pet_Ant 3y ago
If I had to do a desktop app I’d with Java Swing because of the Java backend libraries and developers. Were I yo ignore those factors I’d go with Gambas for the drag & drop gui.
- anta40 3y ago
  I still write Java codes... for Android, though. When were the last time I code in Swing/JavaFX? 4 or 5 years ago, perhaps. The 3rd party libs available for Delphi/FPC are more than enough for my needs.

lelanthran 3y ago

Because none of those alternatives have anything close to Lazarus.

augustk 3y ago

> I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc. Pascal evolved into Modula-2 and then Oberon which is both smaller and more powerful. https://miasap.se/obnc/oberon-report.html https://miasap.se/obnc/oberon-report.html

squarefoot 3y ago

> I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc. When writing desktop apps probably the familiarity with well known IDEs such as Delphi or Lazarus makes the difference. Unfortunately decades passed, still nothing comes even close to them for rapid GUI development. Should one day Lazarus support different languages such as the ones you mentioned, we'll probably hear a rumble around the world. However things in certain fields progress much quicker, and I wouldn't be surprised at all if in some time we could use AI to analyze a drawing then create the corresponding desktop interface description to be linked with non GUI code.