We live in a digital world where we take infinite computation for granted. Today’s programmers can compile millions of lines of code in fractions of a second on a device that fits inside a coat pocket. But if you step back into the late 1970s and 1980s, computer science wasn't an intangible cloud utility—it was a deeply physical craft that required immense patience, mental discipline, and a bit of absolute faith.
My own trajectory across three countries—from Sri Lanka to the United Kingdom—offered me a front-row seat to the engine room of the digital age. This is the story of how I watched computing shrink in physical size, while expanding exponentially in personal freedom.
1: The Mainframe Monoliths of Colombo
My journey into the world of software began in a tiny, 12x10-foot room in Sri Lanka. In that room sat a single, heavy piece of machinery that defined my early engineering life: an IBM Model 29 Card Punch machine.
 |
| IBM Model 29 Card Punch Machine |
In the late 1970s, coding in FORTRAN IV meant dealing with brutal physical realities. Every single line of logic, every loop, and every variable declaration had to be meticulously pressed onto a rectangular piece of cardboard. A single card represented a single line of code. If you had a dataset, that meant thousands more cards. The room was constantly filled with the rhythmic, mechanical clack-clack-clack of the punch machine.
Once your code deck and data deck were complete, the real suspense began. We didn’t have a terminal to run the code. Instead, the precious decks were bundled up and sent across town to the IBM 360/25 mainframe available at the Department of Census and Statistics.
The turnaround time was agonising. It regularly took more than two days just to get a printout back. If you made a typo—a missing comma, a misplaced statement number, or a dropped card—the mainframe would reject the job, print a single syntax error, and you would have to wait another forty-eight hours just to try again. This era taught me absolute precision; you had to mentally simulate the entire machine inside your head and "desk-check" your logic perfectly before ever handing your deck away.
2: Breaking the Barrier
The first massive breakthrough in my programming life came in 1980. We received a Data General NOVA/4 minicomputer on loan for a single year.
 |
| Using a Data General NOVA/4 minicomputer on loan for a single year |
For someone used to waiting days for a mainframe queue, the NOVA/4 completely broke the barrier of the two-day delay. For the first time, the feedback loop was shortened. We could catch compilation errors and reports in hours rather than days, completely transforming how we learned. Soon after, we stepped up to an in-house Data General Eclipse S/140 computer. Having an in-house machine changed the psychological dynamic of programming entirely. We were no longer just passive creators handing decks away; we were actively working with the machine in real time.
3: The 32KB Dynamic Engine – Developing INSTAT
This foundational discipline of absolute code efficiency served me perfectly when I moved to the United Kingdom to join the University of Reading. There, under the vision of Dr Roger Stern, Professor of Applied Statistics, we set out to develop a comprehensive package that seemed structurally impossible at the time: the INSTAT Statistical Package for the iconic BBC Microcomputer.
 |
| Developing INSTAT on BBC computer at the University of Reading |
The challenge was daunting. We had to fit a massive, multi-featured statistical toolkit into a machine with a mere 32KB of RAM. Under normal development paradigms, loading a program of that scale would instantly exhaust the memory before any data could even be processed.
To break this constraint, Dr Kevin Seneviratne and I came up with a brilliant, highly novel architectural idea that was years ahead of its time: The Overlay Concept. Long before modern operating systems popularised Dynamic Link Libraries (DLLs), we built a system that functioned on the exact same dynamic principle.
My specific responsibility was to design and program the Central CORE Module. This core was the heart and brain of INSTAT; it sat permanently in memory, carefully keeping track of the processed data structures and global variables. When a user executed a specific command, the Central Core would dynamically look up, load, and swap the relevant sub-module into the remaining RAM footprint on request, executing the task seamlessly without corrupting the underlying dataset.
This architecture was a masterpiece of cooperative engineering. Because the Central Core smoothly managed the system's stability, the other module writers were given complete freedom to write their specific statistical tools without worrying about breaking the machine's memory boundary. To rigorously test the muscle and fluidity of my Central Core, I even programmed the software's Graphical Module myself.
By the time INSTAT was ready for commercial launch across the UK and internationally, our lightweight, dynamic architecture successfully managed 22 different distinct modules inside that tiny 32KB footprint. It was a thrilling, pioneering moment—we were actively developing a software structure that almost no other developers at the time had even conceptualised.
4: The Green Phosphor Room of Essex
The culmination of my journey took place between 1984 and 1985 during my postgraduate computer science studies at the University of Essex.
 |
| The PDP-11 lab terminal at the University of Essex |
Walking into the Essex laboratory meant stepping into the architecture that forged the modern world. We were working on PDP-11 minicomputers, bathed in the distinct, glowing green aura of VT100 video terminals. The mechanical clatter of printing teletypes was gone, replaced by the quiet, instant scroll of text on a screen.My very first programming assignment at Essex was a true trial by fire: to write a C-like interpreter language using the C programming language. Clutching the classic white-and-blue "K&R" textbook—The C Programming Language by Brian Kernighan and Dennis Ritchie—I set to work. The task was beautifully poetic. A decade earlier at Bell Labs, computer science pioneers like Ken Thompson and Dennis Ritchie had evolved the interpreted B language into the compiled C language to build Unix. By writing a custom interpreter in C on a PDP-11 terminal, I was walking right backward through the evolutionary line of the operating system itself.
It was a masterclass in pointer manipulation and manual memory management. A single un-freed pointer in your symbol table or abstract syntax tree would instantly crash the terminal with a ruthless "Segmentation fault - core dumped." But the feedback loop was instant, and the hours dissolved as I chased logic bugs across that glowing green screen.
Conclusion: The Craft of the Code
When I watch interviews with the creators of these languages today—like the extensive oral history of Kenneth Lane Thompson, 1983 ACM Turing Award Recipient—I realize how incredibly fortunate I was to live through that exact transition. I didn’t just study computer science; I lived through the pivots that defined it.
To the modern developer sitting in front of a high-resolution display with infinite gigabytes of memory and automated AI helpers, my journey might sound like an ancient history lesson. But the craftsmanship, the patience, and the profound thrill of making a machine speak remain exactly the same. We built the digital world line by line—and sometimes, card by card.
