Case Study 2: From Python to Pascal — A Developer's First Day

Case Study 2: From Python to Pascal — A Developer's First Day

Background

Yara Oduya is a mid-level software developer at a data analytics startup in Toronto. She writes Python every day — Django web applications, pandas data pipelines, NumPy number crunching. She is comfortable with pip, virtual environments, Jupyter notebooks, and VS Code. She has never used a compiled language.

Yara's company has just acquired a small manufacturing firm whose production-line monitoring software is written in Lazarus/Free Pascal. The application — a real-time dashboard that reads sensor data, performs calculations, and displays results — has been running reliably for twelve years. Yara has been asked to learn enough Pascal to maintain and extend this application. Her manager has given her a week to get up to speed.

This case study follows Yara's first day: installing Free Pascal, writing her first programs, and noting the differences from her Python experience.

Hour 1: Installation and First Impressions

Yara opens her browser and navigates to freepascal.org. Her first surprise: the website looks like it was designed in 2005. No sleek landing page. No animated diagrams. Just a straightforward, information-dense site with download links.

"Okay," she thinks, "different community, different aesthetic."

She downloads the Windows installer (50 MB). Her second surprise: 50 MB for a compiler? Her Python installation is 300 MB, and that is before she installs any packages. With NumPy, pandas, Django, and her other dependencies, her Python environment is over 2 GB.

Installation takes thirty seconds. She opens PowerShell and types fpc -v:

Free Pascal Compiler version 3.2.2 [2021/05/15] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others

"That was... easy," she admits. No virtual environment. No dependency resolution. No pip install anything. Just a compiler.

She downloads Lazarus next. 250 MB for a full IDE with a visual form designer, debugger, and component library. She thinks about VS Code with its extensions: 500 MB minimum, and it still cannot design GUI forms.

Hour 2: Hello World, Two Ways

Yara creates a file called hello.py:

print("Hello from Python!")

She runs it: python hello.py. Output appears instantly. She knows this dance.

Now she creates hello.pas:

program Hello;
begin
  WriteLn('Hello from Pascal!');
end.

She compiles it: fpc hello.pas. The compiler produces several lines of output, including "Linking hello.exe." Then she runs .\hello.exe:

Hello from Pascal!

Same result, different process. She opens her file explorer and looks at the directory:

hello.py — 34 bytes
hello.pas — 62 bytes
hello.exe — 221,184 bytes (216 KB)
hello.o — 1,576 bytes

"216 KB for Hello World?" She checks hello.py — 34 bytes of source, but running it requires the Python interpreter (100+ MB). The Pascal executable is self-contained.

She copies hello.exe to a USB drive, plugs it into a colleague's machine (which has no development tools installed), and double-clicks. It runs. She tries the same with hello.py — "Python is not recognized as an internal or external command."

"Okay," she says. "I get it."

Hour 3: Noticing the Differences

Yara writes a slightly more complex program to feel out the language:

Python version:

name = "Yara"
age = 28
print(f"My name is {name} and I am {age} years old.")
print(f"Next year I will be {age + 1}.")

Pascal version (first attempt):

program AboutMe;
begin
  name := 'Yara';
  age := 28;
  WriteLn('My name is ', name, ' and I am ', age, ' years old.');
  WriteLn('Next year I will be ', age + 1, '.');
end.

She compiles. The compiler reports:

aboutme.pas(3,3) Error: Identifier not found "name"

Right. She remembers from the documentation: declare before use. In Python, name = "Yara" creates a variable and assigns it simultaneously. Pascal requires a separate declaration.

Pascal version (second attempt):

program AboutMe;
var
  name: String;
  age: Integer;
begin
  name := 'Yara';
  age := 28;
  WriteLn('My name is ', name, ' and I am ', age, ' years old.');
  WriteLn('Next year I will be ', age + 1, '.');
end.

This compiles and runs correctly. She stares at the var section. "I had to tell the compiler that name is a string and age is an integer. In Python, it just... figures it out."

She pauses. Then she tries something in Python:

age = 28
age = "twenty-eight"  # No error — Python allows this
print(age + 1)  # Runtime error: can't add string and int

And in Pascal:

program TypeTest;
var
  age: Integer;
begin
  age := 28;
  age := 'twenty-eight';  { Compiler error! }
end.

The Pascal compiler refuses to compile: Error: Incompatible types: got "Constant String" expected "LongInt". The error is caught before the program runs.

Yara adds this to her notes: "Pascal catches type errors at compile time. Python catches them at runtime (if you're lucky — sometimes they hide for months)."

Hour 4: The Compilation Cycle

Yara's Python workflow: edit → save → run. No compilation step. The interpreter reads the source file directly.

Her Pascal workflow: edit → save → compile → run. The extra step feels cumbersome at first. But she notices something: when the compiler reports errors, it reports all of them at once. She introduces three deliberate bugs:

program Buggy;
var
  x: Integer;
begin
  x := 'hello';        { Bug 1: wrong type }
  WriteLn(y);           { Bug 2: undeclared variable }
  WriteLn('Missing')    { Bug 3: missing semicolon }
end.

The compiler reports all three errors in one pass:

buggy.pas(5,8) Error: Incompatible types: got "Constant String" expected "LongInt"
buggy.pas(6,12) Error: Identifier not found "y"
buggy.pas(7,26) Error: Illegal expression

Line numbers, column numbers, specific error descriptions. She fixes all three, recompiles, and it works. She compares this to Python, where she would discover each bug one at a time as the interpreter reached each line.

"The compilation step isn't overhead," she writes. "It's a batch error-checker that runs in under a second."

Hour 5: Exploring the Executable

Curiosity gets the better of Yara. She writes a slightly more substantial program — one that calculates and displays a multiplication table. She compiles it and examines the executable:

Source code: 847 bytes
Executable: 228 KB

She runs a quick benchmark: the executable starts and completes in under 10 milliseconds. She writes the equivalent in Python and times it: 45 milliseconds just for the Python interpreter to start, then negligible time for the actual computation.

"For a multiplication table, who cares?" she writes. "But the production-line monitoring application reads sensor data every 50 milliseconds. If the interpreter takes 45 ms just to start..."

She realizes why the manufacturing firm wrote their monitoring software in Pascal: predictable performance, small memory footprint, no runtime dependency, instant startup. The twelve-year-old application runs on machines with 2 GB of RAM and no internet connection. A Python equivalent would need Python installed, would use more memory, and would have slower startup — factors that matter in industrial environments.

End of Day 1: Reflections

Yara's notes at the end of her first day:

Things I miss from Python: - Interactive REPL (no need to create a file for quick experiments) - Dynamic typing (less ceremony for quick scripts) - f-strings (string formatting is less convenient in Pascal) - pip / package ecosystem (Python has a library for everything)

Things I like about Pascal so far: - The compiler catches errors before I run the program - Executables are standalone — no deployment headaches - Fast compilation (under a second for small programs) - The code is very readable — begin/end is clearer than Python's indentation-is-syntax - No "works on my machine" problem — the .exe runs anywhere with the same OS

Key insight: Python and Pascal are designed for different things. Python optimizes for developer speed (write fast, iterate fast, ship fast). Pascal optimizes for correctness and reliability (declare explicitly, catch errors early, deploy a single file). The manufacturing monitoring application needs correctness and reliability. Python is the wrong tool for that job. Pascal is the right one.

Tomorrow's plan: Learn about Pascal's type system (Chapter 3 in the textbook), write programs with proper variables and expressions, and start reading the monitoring application's source code.

Discussion Questions

Yara found that the Pascal executable was 216 KB while the source code was only 62 bytes. Where does the extra 215+ KB come from? Is this a problem?
Yara noticed that Python catches errors one at a time during execution, while the Pascal compiler reports all errors at once before execution begins. What are the practical implications of this difference for debugging a large program?
The manufacturing monitoring application has been running reliably for twelve years. What properties of Pascal and its compilation model contribute to this kind of long-term reliability?
Yara's "Things I miss from Python" list includes the interactive REPL. Is there an equivalent in the Pascal world? How might you quickly test small Pascal expressions without creating a full program file? (Hint: Lazarus has an "Evaluate/Modify" feature in its debugger.)
Consider a scenario where Yara needs to deploy a new feature to the monitoring application on 50 factory machines, none of which have internet access. How does Pascal's compilation model make this easier compared to deploying a Python application?
Yara mentions that Python "works on my machine" problems do not occur with Pascal executables. What does she mean? Can you think of scenarios where a Pascal executable might not work on a different machine with the same operating system? (Hint: think about 32-bit vs. 64-bit, or linked dynamic libraries.)
Should Yara's company eventually rewrite the monitoring application in Python "because everyone knows Python"? Argue both sides, then give your recommendation.