notes / thoughts

01.10.2025: changes i would make to freepascal
Even though it is probably my favourite implementation of my favourite language, there are many things which annoy me. This list in particular is just an outline of some smaller things (be it language, rtl or compiler side) which I would change.
  • Case sensitivity by default.
  • Scoped access by default.
    • i.e accessing functions, procedures, types, etc. from other units would require proper identifier resolution
  • Sane(r) defaults.
    • AnsiString as the standard string type.
    • UTF-8 as the standard codepage.
    • The "Integer" type should correspond to NativeInt.
      • If this is a problem, you should be using fixed-width integers anyways.
  • Make it possible to combine one unit per compiler invocation.
    • A single fpc invocation building an entire program is cool, but sometimes I want to control what gets recompiled and whatnot.
  • Add flexible array members
    • This is something that I mainly wish for when creating bindings to C libraries or when working on a lower level where this actually matters.
  • Allow for trailing commas in array initializations and enum definitions.
    • Potentially also applies to other places which i can't think of right now.
30.09.2025: horribly managed codebases
This is more of a rant. I’ve ranted about it before, and I don’t even work there anymore, but I don’t think I ever ranted to completion.

My first company during my apprenticeship built software for different parts of the wood industry; mainly production management and control software. Most of it was written in Delphi and versioned with SVN.

As usual, customers needed all kinds of customization for their production lines. This should have been the perfect chance to keep a clean central repo for the base product, fork it for new customers, and contribute back useful general additions.

This happened for exactly one product.


For every other product, the strategy was simple: each new customer got a fork of the
previous customer's fork . There was no way to sanely reuse work. When you needed a feature, bugfix or whatever else from another version, you were digging through 100k+ lines, sometimes spanning up to 15 years of changes; almost nothing was documented.

The work inside a project wasn't any better. Commits were usually gigantic. Everyone worked directly on trunk, battled merge conflicts for every commit, and test code was regularly overwritten. And every time someone suggested improvements (like using branches, making smaller commits, or adding testfiles to the ignore list), they were immediately shot down by the guys who'd been there for the last 20 years.

(I did not last long.)