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.
* 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
1. preprocessor/parser/semantic all at once
2. optimizer (optional)
3. code generator
Later on in the 80s these were merged into one executable.
When we say "Pascal" today we speak of a much more ergonomic language than the Pascal of 1981.
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.
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).
C0
C1
C2
AS
LD
And an optional AR
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.
