Comment by jll29
2 days ago
Both Pascal and C (and their offspring) are wonderful gifts for us to receive from their designers, and I enjoy writing code in both.
> It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.
Here's Brian Kernighan's view on the shortcomings of Pascal resulting from a practical book project idea:
https://www.lysator.liu.se/c/bwk-on-pascal.html
Not sure to what extent the latest Oberon or Ada have addressed all of these, since I've not kept up with Ada news.
Isn't that interesting, I do vaguely recall this from many years ago. These complaints have mostly been addressed a long time ago, the solutions were mostly stolen from C where applicable, I refer to Delphi, but I think Lazarus is the same. These are the dot points from the summary:
- Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.
There's a TArray<T> type now, it uses generics and can be declared if you like, also lots of other structured types - lists, stacks etc, though the original array type is still available for backwards compatibility. There was also an array of without size to pass as a parameter but TArray is mostly used now.
- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.
Statics are now a thing
- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
This can be an issue still, though the one pass is why the compiler is fast.
- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
Not an issue any more, it has packages and libraries
- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
Not an issue any more it uses the C method
- The 'case' statement is emasculated because there is no default clause.
Does now, though a case with string alternatives still doesn't exist in Delphi, Lazarus has it.
- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
Many different sorts of file access - random, binary etc
- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
Not true any more, it has packages and include files (though limited), and the macro facility is very limited, nothing like C's but its not really needed, you can have inline functions for the performance boost macros would give you (stolen from C++)
- There is no escape.
This refers to the type system, you can use casts just like C now
Just as a counterpoint C still doesn't have a standard string type. Delphi has generics now like C++, and many of the things that are external libraries in C/C++ are just included. If you really need high performance then C is still better, but what I've done in the past is just rewrite bits in C, though the need for this is very infrequent. If you look at comparable things for Delphi in C++ like Qt's slots and signals for example, the Delphi solution is so much more elegant, and Qt is perhaps the only comparable commercial cross platform library to Delphi's Firemonkey. It's really worth a look, times have changed. There's a reason MS hired away Anders Hejlsberg to architect C# and then typescript.