Posted by susam 4/13/2025
I wonder how the non-programmers succeed to write commas correctly, because those follow the same logic: e.g. "red, green, blue". In author's opinion, I guess it should be "red, green, blue," instead.
Usually they don't.
'This is a '' character'
However, an empty string and nil are also the same in Pascal, there is no distinction between an empty string and the absence of a string. This is because in early computing, strings weren’t separate objects that you pointed to (and hence could be a null pointer), but more like (usually fixed-size) arrays allocated as part of a larger contiguous memory structure. The array could be empty (based on some length variable), but it couldn’t not be there as part of the fixed memory layout.
Actually, in certain systems strings couldn’t even be empty, in the sense that there was no stored size in addition to the fixed-length array. Instead you padded the rest of the array with spaces. The CHAR type in SQL (as opposed to VARCHAR) is a remnant of that practice.
What made standard Pascal problematic wrt string handling is that it did not have array NEW nor pointer arithmetic. So if you wanted to heap-allocate ARRAY[1..100] OF CHAR, that was fine; but there was no way to get a pointer to N bytes on the heap where N is determined at runtime; and even if you could do that, somehow, you still wouldn't be able to use that pointer as an array by indexing through it.
Interestingly enough standard Pascal did support allocating variable-length data structures, but only in form of variant records (roughly analogous to discriminated unions in ML or enums in Rust, but with multi-level nesting and the ability to define a common sequence of fields shared by all variants at any level).
When they hit C, they wrote code around fgets that processes the last line twice:
while (!feof(instream)) {
fgets(linebuf, sizeof linebuf, instream);
process_line(linebuf);
}
while (!feof(instream)) {
char ch = getc(instream);
switch (ch) ...
}Yes, most Pascal dialects, namely UCSD Pascal and Object Pascal also got around fixing them, as did ISO Extended Pascal, the follow up revision that was largely ignored, because by then it was all about Object Pascal.
This was an update to the earlier “Software Tools” book, which was written using RATFOR.
If you read the book, it has a very “C in Pascal” coding style, and you can see how uncomfortable it is by doing so.
* Components have a support for customizable UI interfaces for setting the property of components called property sheets and these property sheets are applicable on a component level or at the level of individual property fields in the component. These property sheets show up when you are trying configure a component in the design mode within the IDE. We are not talking about simple text entry type of fields - you can actually do very sophisticated property sheets with tabs, multiple forms etc and what not. It is EXTREMELY configurable and also relatively easy to develop.
* Delphi uses a binary "form" file into which each GUI form persists its interface. So everytime you place a component on a form in the GUI IDE or set its properties, the form and its components have a way of persisting their values into this "form" file. The reverse also happens - so when a form is loaded into the IDE or during runtime, the form fields are read off the "form" file by the form and its components. So the actual .pas file where you are adding code for the events etc is not filled up with a lot of UI related property setting code and so the code looks really clean with clear separation of design and code.
* Components can be installed into the IDE during development very easily
In Free Pascal (and Delphi) all classes have a "metaclass" (a class that describes the class) and can be used in conjunction with the RTTI to obtain information about an object at runtime - including its actual class, exposed properties and any optional metadata (like attributes in FP).
This functionality is used by Delphi/Lazarus to serialize and deserialize objects on disk (the form files you mention are such serialized objects but you can serialize other types of objects and in Lazarus -perhaps Delphi too- you can use several file formats) as well as implement the object inspector.
In a way Delphi/Lazarus work kinda like how game engines like Unreal work in that you are working with "live" instances of objects, using generic object inspectors and saving them on disk is done by serializing them (though obviously it is the opposite since Delphi predates most game engines using this approach :-P).
The important aspect with all the above isn't so much the form/component serialization but the language features that make it possible in the first place: metaclasses and RTTI that provides enough information to instantiate and describe objects and classes at runtime.
My own game engine[0] is written in Free Pascal and Lazarus and uses the exact same language features to provide object serialization, property editing and some other stuff (like object diffing that is used for many undo/redo operations). Instead of TComponent/TPersistent (the types Delphi/FCL provide for serialization), it has its own base types that use a more compact file format, optional compressed streams (e.g. for texture data) and external references (for shared assets stored in separate files), but still relies on the same base functionality provided by the language/compiler.
FWIW a retro engine[1] i made for an MSDOS game jam a few years ago uses the same functionality, though it relies more on the existing functionality for the editor side instead of Little Immersive Engine which uses its own property editing controls and "root" object for serialization. Actually Little Immersive Engine is based on the retro engine's code (with a bunch of enhancements of course) but the serialization code is very similar (though without the ability to have external assets)[2].
[0] https://www.youtube.com/watch?v=cQEDAtmGRII
[1] https://codeberg.org/badsector/PetraEngine
[2] https://codeberg.org/badsector/PetraEngine/src/commit/14ca16...
That's not necessarily binary. I don't recall if perhaps it was in Delphi 1 (the 16-bit version for Windows 3.x and Windows 95), but from Delphi 2 or 3 or so (released around the turn of the century), it could also save form definitions as plain text. oh, and of course since the height of the XML craze (shortly after the turn of the century?), in that format too.
When we say "Pascal" today we speak of a much more ergonomic language than the Pascal of 1981.
One thing that very clearly distinguished (extended dialects of) Pascal from C in the era where the two were competing was that Pascal's units were self-describing. That is, when you compiled a unit, you got a single file with all the metadata for that unit as well as binary object code for linking. Then, when another unit or program did a USES declaration, that would locate the file by name and use the metadata as needed. Conversely, in C you had to deal with header files, and while on the surface it looks kinda sorta like the INTERFACE section of the Pascal unit, it's not quite that because e.g. it needs to #include things it depends on - and that is textual inclusion, not just a metadata reference.
This all meant that working with dynamically loaded type information was much easier in Pascal tooling - it just needed to parse the metadata embedded in the compiled unit files, and each file would only contain metadata for its own types and functions, without contamination from other units that it relies on. This is great for things like code completion and visual UI designers.
There were free intro libraries (no code), shareware component libraries, and usually a developer version available that came with source code. Plus a culture of open source libraries.
This community was a key strength of Delphi compared to some other choices. I suspect if Borland had really leaned into a combination of open source, plus better support for commercial proprietary solutions, that would have kept the ecosystem alive.
Also of note is that Delphi came with some source code for library components (often useful when understanding usage or debugging or extending).
Imagine this - if those had not exists, would anyone say Pascal was a good RAD language.
I suppose what I might be missing is why Pascal was chosen as the language for Delphi.
1. preprocessor/parser/semantic all at once
2. optimizer (optional)
3. code generator
Later on in the 80s these were merged into one executable.
C0
C1
C2
AS
LD
And an optional AR
I played with Lazarus recently and the whole process of creating a simple GUI was so painless.
Thing is, people complain about Borland/Embarcadero extensions, but love their GCC and clang ones.
Pascal implementations typically support index and range checking, while Ada provides even more extensive memory and concurrency safety.
Fortunately for C, clang's -fbounds-safety seems to be making progress. It's implemented in Apple's LLVM fork, so this now works on macOS:
clang -Xclang -fbounds-safety program.c
type
apple = integer;
orange = integer;
Same in Kotlin sadly. The whole point of giving a different names to a type is to make them incompatible.