Forem: Priyabrata Paul

Remembering Sir Tony Hoare: A Masterclass in Lifelong Learning

Priyabrata Paul — Wed, 11 Mar 2026 05:41:16 +0000

Sir Charles Antony Richard (Tony) Hoare (in 2011)
Photograph by Rama, Wikimedia Commons, Cc-by-sa-2.0-fr, CC BY-SA 2.0 FR, via Wikimedia Commons

The world of computer science has just lost one of its most brilliant and foundational gems with the passing of Sir Charles Antony Richard (Tony) Hoare (1934-2026). His visionary work shaped the very fabric of modern software, and the digital age as we know it is built upon his logic.

To anyone in the tech world, his name is legendary. He is best known as the inventor of Quicksort—an elegant algorithm created in 1959 that is still used globally today to sort data. He introduced Hoare Logic, giving engineers a way to mathematically prove that their code is correct and safe. He developed CSP (Communicating Sequential Processes), which forms the architectural basis for how modern systems do multiple things at once (powering languages like Go). And, with characteristic humility, he is also famous for inventing the "null reference," an innovation he later playfully apologized for as his "billion-dollar mistake." For his monumental impact, he was awarded the A.M. Turing Award in 1980.

However, behind these towering technical achievements is a story that goes far beyond algorithms. Sir Tony's life leaves behind a beautiful blueprint of what it means to possess an endlessly curious mind. He didn't just invent; he constantly evolved.

Here is a brief look at his journey, which serves as a true masterclass in lifelong learning:

Age 20s: Pivoting without fear. He didn't begin as a computer scientist; he studied Classics and Philosophy at Oxford. Driven by an insatiable desire to learn, he shifted to statistics and machine translation. At just 25 years old, while studying as an exchange student in Moscow, he invented Quicksort.
Age 30s: Embracing mistakes to grow. It was in his 30s that he introduced the "null reference." Decades later, he publicly and gracefully apologized for it, acknowledging the bugs it inadvertently caused. His willingness to admit failure showed that true learners are never too proud to critique their own work.
Age 35 to 44: Constantly pushing boundaries. Never content with the status quo, at 35, he created Hoare Logic, transforming programming from trial-and-error guesswork into a rigorous mathematical science. At 44, he tackled a completely new frontier by inventing CSP to solve the complexities of concurrent programming.
Age 46: Reaching the peak, but keeping the climb. At 46, he won the Turing Award (the "Nobel Prize of Computing"). For many, this would be the pinnacle and an excuse to rest on their laurels. For him, it was merely a milestone in a continuing journey of discovery.
Age 65 to 90: The ultimate "un-retirement." At 65, he reached the mandatory retirement age at Oxford University. Instead of stopping, he immediately joined Microsoft Research. He spent his 70s, 80s, and into his 90s continuing to research, publish, and solve complex software vulnerabilities alongside entirely new generations of engineers.

The Inspiring Takeaway:

Sir Tony Hoare’s remarkable life proves that intelligence and innovation are not tied to youth—they are tied to curiosity. Whether he was a 25-year-old philosophy student teaching himself algorithms, or a Turing Award-winning elder statesman still researching new ways to write code in his final years, his true superpower was his absolute refusal to stop learning.

We have lost a titan of technology, but his legacy challenges all of us: to stay humble, embrace the unknown, and remain forever curious.

References:

From Chaos to Clarity: My Journey Building JSON Query Pro

Priyabrata Paul — Sat, 14 Feb 2026 17:48:41 +0000

This is a submission for the GitHub Copilot CLI Challenge

Problem I choose to solve

As developers, there are occasions when we’ve spent countless hours staring at API responses in JSON format. Thousands of lines of nested brackets and quotes used to stare back, hiding that one single piece of data we actually needed.

The web has many JSON formatters, viewers, and query tools. They perform well, but often fall short for practical use. Most solutions struggle with large enterprise-scale files. Others don't offer an intuitive, interactive query system. I realized that for most of us, the solution was a frustrating cycle of copying, pasting into a formatter, and manually hunting for keys.

🚀 What I Built as Solution

I wanted a tool that combined fast visualization with a powerful query engine. So, I decided to build JSON Query Pro. It is a comprehensive data exploration environment. It isn't just a viewer; it's a high-performance workbench designed to help developers navigate and reshape massive JSON datasets.

At its core, the application features a virtualized tree explorer that remains fluid even with millions of rows, paired with a dual-tier query engine that supports both standard JavaScript paths and advanced JSONata transformations. It’s a local-first, privacy-conscious tool that brings professional-grade data manipulation directly to the browser.

Demo

PFB a short demo of the app.

PFB relevant links:
Code Repository: https://github.com/priyabratapaul/json-query-pro
Deployed App Link: https://json-query-pro.vercel.app

📋 The Blueprint: What I Set Out to Build

Before writing a single line of code, I mapped out exactly what a "pro" JSON tool should look like. I didn't want a passive viewer; I wanted a dynamic workspace. My primary goals were:

Virtualized Tree Engine: The UI had to remain fluid (60fps) regardless of whether the file was 1KB or 500MB. This meant only rendering what was visible in the viewport.
A "Point-and-Click" Selection Mode: I wanted to eliminate the need to manually count array indices or type out long, error-prone property paths. Clicking a node should instantly populate the query editor.
Dual-Tier Querying: A hybrid approach using native JS pathing for simple lookups and the industry-standard JSONata engine for complex filters, counts, and data reshaping.
Local-First Persistence: Data should be stored safely in the browser's IndexedDB, ensuring that accidentally closing a tab didn't mean losing hours of investigative work.

🧩 The Wall: Obstacles Faced During Implementation

However, moving from blueprint to browser revealed several harsh engineering realities. As I began implementing these features, I ran into several hurdles. A few of them are mentioned below:

1. The "Where Am I?" Problem

Even with a clean tree view, working with deeply nested objects (like large database exports) made it impossible to keep track of a field's context. A field named "status" might exist in five different parent objects at different levels.

How I solved it: I integrated the selection logic directly into the virtualization engine. Now, every node "knows" its exact absolute path from the root. When you click it, the app doesn't just show you the data; it calculates the precise breadcrumb path and writes the corresponding JSONata code for you.

2. The Performance Wall

Early on, the browser simply died when I loaded a 100MB file. The main thread would freeze for 10 seconds just parsing the JSON, and then another 5 seconds trying to calculate the tree structure.

How I solved it: I offloaded the entire data lifecycle to a Web Worker. The "brain" of the app now lives in a separate thread. While the worker parses, queries, and flattens the JSON, the main UI remains completely interactive. This was the only way to support professional-scale datasets.

3. The 1GB String Ceiling and V8 Buffer Limits

During implementation, I hit the hardest wall of all: the "allocation size overflow." I discovered that Chromium-based browsers (Chrome, Edge) have a hard internal limit on string length—roughly 512MB. Even if a machine has 64GB of RAM, the JavaScript engine cannot create a single string long enough to represent a massive JSON file.

How I solved it: I implemented a defensive loading strategy. Instead of relying on a single large string, the worker uses modern streaming APIs (Response.json()) to parse data in chunks. I also added explicit memory cleanup, nulling out large buffers the moment they are no longer needed to maximize the available heap.

Screenshots

Main page: https://json-query-pro.vercel.app/#/Main

Help page: https://json-query-pro.vercel.app/#/Help

Sample Queries

🚀 Sample Data

All examples below reference the default "Tech Innovations" dataset:

Company: Tech Innovations (San Francisco)
Structure: company → departments[] → employees[] → projects[]

🔍 Basic Retrieval (Simple Queries)

Goal	Standard PATH Syntax	JSONata Syntax
Get Company Name	`$.company.name`	`company.name`
First Department	`$.company.departments[0]`	`company.departments[0]`
All Dept Names	Not supported (requires index)	`company.departments.name`
First Employee Name	`$.company.departments[0].employees[0].name`	`company.departments[0].employees[0].name`

⚡ Advanced Selection (Complex Queries)

Filtering Data (JSONata Only)

Find specific items without knowing their index.

Engineering Dept: company.departments[name="Engineering"]
Software Engineers: company.departments.employees[position="Software Engineer"]
High Value Clients: company.departments.employees.clients[contract_value > 60000]

Deep Search (The Double Star)

Find data anywhere in the file regardless of depth.

Find "Alice": **[name="Alice"]
Find all Projects: **.projects

Reshaping Output

Create a custom report from the data.

company.departments.{
  "department": name,
  "headcount": $count(employees),
  "totalValue": $sum(employees.clients.contract_value)
}

💡 Lessons Learned

Performance IS the experience: Users don't care how many features you have if the app lags. Background processing is non-negotiable for pro tools.
The V8 Buffer Limit: I learned that the hard way: if your JSON file is 500MB+, standard JSON.parse is a gamble in Chromium-based browsers.
Ghost Truncation: I found that some streaming APIs don't always give you a nice error message when they fail under memory pressure; they often just stop reading.
Dynamic Engine Feedback: We implemented runtime browser detection in our Background Worker to explain memory restrictions specifically when they occur.

🚀 Future Plans

Breaking the 1GB Barrier: While JSON Query Pro is currently optimized for datasets up to 512MB (Chromium) and 1GB (Firefox), the next frontier is breaking through this browser-imposed ceiling.
Desktop app: Also I am planning to create desktop version of this app for different OS.

🤖 My Experience with GitHub Copilot CLI

Building a high-performance system like JSON Query Pro required more than just standard frontend knowledge—it required deep dives into browser internals, memory management, and concurrency. Throughout this process, I leveraged GitHub Copilot as a senior partner.

Whether it was brainstorming the communication protocol between the main thread and the Web Worker or debugging the subtle nuances of structured cloning limits, GitHub Copilot provided instant, high-context feedback that significantly accelerated the development cycle.

It acted as a force multiplier, allowing me to iterate on complex features like the virtualized tree rendering and IndexedDB persistence layer in a fraction of the time it would have taken to research these topics in isolation. The impact on my development experience was profound; it turned what could have been a month-long research project into a week-long implementation sprint, all while maintaining a focus on clean, scalable code.

Conclusion

I built JSON Query Pro to turn a large json text into a clear, searchable map. By combining background processing with powerful query languages, I've created a workspace where json data isn't just something you see—it's something you can easily query.

👉Link to app: https://json-query-pro.vercel.app

Happy Querying!

Story of The First Linked List

Priyabrata Paul — Sun, 18 Jan 2026 16:01:58 +0000

🙋‍♂️Hi

In this story, we will uncover how linked lists were first used to solve data structure challenges posed by simple arrays of data. Let’s begin.

Prologue: A Problem Without Order

It was the early 1950s, and computers were still massive rooms of vacuum tubes and punch cards. One of the most pressing challenges was dynamic memory management—how to store a collection of items when the size of that collection could change during execution. Early machines like the ENIAC and the Manchester Mark 1 used fixed‑size arrays; every element occupied a predetermined slot in memory. If a program needed more space than it had reserved, it either crashed or wasted precious memory.

Enter a young computer scientist named Allen Newell (later joined by Herbert A. Simon) at the RAND Corporation. They were working on a program to simulate human problem‑solving, a project that would eventually become the Logic Theory Machine. Their algorithm needed to keep track of an ever‑growing list of logical statements, but they could not predict how many statements would be generated at runtime.

Chapter 1: The Insight

While sketching ideas on a napkin, Newell imagined a chain of boxes, each holding a piece of data and a pointer to the next box. “If each box knows where the next one lives,” he mused, “we can add a new box anywhere without moving the existing ones.” The concept was simple: instead of a contiguous block of memory, the data structure would be a series of nodes linked together by addresses.

He showed the idea to his colleague Clifford Shaw, who was also wrestling with dynamic data in his own work on early artificial intelligence programs. Together they refined the notion: each node would contain two fields—data (the actual value) and link (the address of the next node). The first node would be called the head, and the last node would point to a special null value indicating the end of the chain.

Chapter 2: The First Implementation

In 1955, Newell, Shaw, and Simon wrote a program for the RAND “Logic Theory Machine” that used this chain of nodes to store theorems as they were derived. Because the number of theorems could not be known ahead of time, the linked list allowed the program to allocate a new node whenever a new theorem was proved, linking it to the previous one. Deleting a theorem was equally straightforward: adjust the link of the preceding node to skip over the unwanted node.

Their code, written in assembly for the IBM 704, looked roughly like this (simplified for illustration):

ALLOCATE NEW NODE
STORE THEOREM IN NODE.DATA
SET NODE.LINK = NULL
IF LIST IS EMPTY THEN
    HEAD = NODE
ELSE
    LAST.LINK = NODE
END IF
LAST = NODE

The elegance of the solution lay in its O(1) insertion at the tail and O(n) traversal when searching—exactly the trade‑off they needed.

Chapter 3: Publication and Spread

Newell and Simon published their findings in a 1956 paper titled “A Logic Theory Machine”. Although the primary focus was on automated theorem proving, reviewers noted the novel data structure. The term “linked list” did not appear yet; the authors referred to it as a “chain of records”.

Around the same time, Donald Knuth, then a graduate student, encountered the idea while working on his Ph.D. thesis on sorting algorithms. He formalized the terminology, coining the phrase “linked list” in his seminal 1968 book "The Art of Computer Programming". Knuth’s clear exposition helped spread the concept throughout the emerging computer science community.

Chapter 4: Why the Linked List Mattered

The linked list solved a fundamental limitation of early computers:

Dynamic Size: Nodes could be added or removed without reallocating a whole block of memory.
Efficient Insertions/Deletions: Changing the list required only updating a couple of pointers, not shifting large swaths of data.
Memory Utilization: Unused memory could be reclaimed by freeing individual nodes, a crucial advantage when memory was measured in kilobytes. These properties made linked lists the backbone of many early operating systems (process control blocks, file allocation tables) and later data structures such as stacks, queues, and even more complex trees.

Epilogue: The Chain Continues

From that modest chain of nodes in a 1950s logic‑theory program, linked lists have grown into a foundational concept taught to every first‑year computer science student. Modern languages hide the pointer arithmetic behind elegant abstractions, but the core idea remains unchanged: connect discrete pieces of data with references, forming a flexible, extensible chain.

So the next time you push an item onto a stack or traverse a singly‑linked list in Python, remember that you’re walking the same mental path that Allen Newell and his colleagues forged half a century ago—link by link, node by node, building ever‑larger structures from the simplest of connections.

Bye 🙋‍♂️

Congratulations! You finished reading this article.

See you then, in another story.

References

Story of The First Array

Priyabrata Paul — Mon, 12 Jan 2026 11:49:46 +0000

🙋‍♂️Hi

In this story, we will uncover how arrays were first employed to tackle data structure challenges at the hardware level. We will also follow their journey as they became crucial elements of programming languages. Let’s begin.

Prologue: A Need for Order

It was the spring of 1945 at the Moore School of Electrical Engineering in Philadelphia.

A handful of engineers huddled around a chalk‑filled blackboard, wrestling with a bold new idea: a computer that could store both its instructions and its data in the same memory. John von Neumann, fresh from his work on the Manhattan Project, was sketching a diagram of a long row of identical cells, each labeled with a number—0, 1, 2…—and a tiny arrow pointing to the next.

“The machine must be able to fetch any datum directly,” he said, tapping the first cell. “If we give each cell an address, the program can jump straight to it without scanning.”

That simple insight—contiguous, addressable memory—was the seed of the array.

Array in Hardware - The EDVAC Experiment

Later that year, the EDVAC (Electronic Discrete Variable Automatic Computer) began construction.

EDVAC was one of the first stored-program computers that utilized registers to hold temporary data and employed magnetic core memory for efficient storage and retrieval of information. Its designers needed a way to keep track of the intermediate results of a long numerical simulation of ballistic trajectories. For this, the values were stored in magnetic core memory. However, as they delved into this complex task, they encountered a significant challenge: the management of data.

Problem - Data was scattered

Initially, data was scattered across non-contiguous memory locations, resembling fragmented islands in a vast ocean. Programmers relied on individual variables to store each piece of data, which forced them into a daunting juggling act as they monitored memory addresses and sizes. This haphazard approach not only complicated coding but also increased the chances of error, rendering even simple operations cumbersome.

While magnetic core memory offered improvements in speed and reliability over earlier technologies, it did little to alleviate the fundamental issue of fragmented storage. The inefficiencies began to surface, especially when complex calculations required multiple variables. Amidst this chaos, the concept of arrays emerged as a revolutionary solution.

Solution - Data stored in arrays of memory

Arrays allowed for contiguous memory allocation, organizing related data into neat blocks. This structural change transformed how EDVAC handled information, making it easier for programmers to access entire datasets at once. No longer did they need to hop between scattered variables; data management became streamlined and intuitive.

This pivotal transition not only resolved the inefficiencies of the early design but also set the stage for future advancements in computing. With the advent of arrays, EDVAC embraced a new era of organized data handling, laying the groundwork for modern programming practices. The struggles of its early days faded into history, replaced by the promise of efficient and effective data management that continues to shape technology today.

The EDVAC’s successful use of a contiguous block of memory became the first real‑world demonstration that an array could serve as a general‑purpose data container.

From Hardware to Language – FORTRAN’s DIMENSION

A decade later, the IBM 704 was humming in a Boston lab. Scientists needed to solve massive systems of linear equations for nuclear physics research. The existing programming methods forced them to write repetitive code for each variable, a nightmare of bookkeeping.

Enter a small team led by John Backus. While drafting the language specification for what would become FORTRAN I, Backus remembered the EDVAC’s memory layout. He introduced the DIMENSION statement:

DIMENSION X(100), Y(100)

Now a programmer could declare a fixed‑size, one‑dimensional array of 100 elements with a single line of code. The compiler translated X(I) into base address of X + (I‑1) times the word size, exactly the addressing scheme pioneered on the EDVAC.

The first FORTRAN program to use DIMENSION solved a set of differential equations for a weather‑prediction model. It ran orders of magnitude faster than its predecessor because the array allowed the algorithm to iterate over data with simple, predictable memory accesses.

Zero‑Based Indexing – ALGOL 60

Across the Atlantic, a consortium of European and American computer scientists gathered in 1960 to design a language that could express algorithms clearly. Their meetings produced ALGOL 60, which introduced zero‑based indexing for arrays:

integer A[0:9];

The decision to start counting at zero mirrored the way hardware addressed memory—offset 0 from the base address. This subtle change made the mental model of array element = base + index × size exact, eliminating the off‑by‑one adjustments that had plagued earlier code.

ALGOL’s array syntax spread quickly to academic circles, influencing later languages such as Pascal, C, and ultimately the modern programming ecosystem.

Epilogue: The Legacy of a Simple Row

From a chalkboard sketch in 1945 to a language keyword in 1957 and a standardized indexing rule in 1960, the array traveled from hardware necessity to a universal programming abstraction. Its core idea—store a collection of homogeneous items in a contiguous block and address each by its position—remains unchanged in today’s GPUs, databases, and high‑performance scientific codes.

Every time a program accesses arr[i], it echoes the same principle that von Neumann first wrote on that blackboard:

… give each piece of data a number, and you can reach it instantly.

The story of the array is a reminder that some of the most powerful tools in computing begin with the simplest of insights.

Bye 🙋‍♂️

Congratulations! You finished reading this article.
See you then, in another story.

Forem: Priyabrata Paul

Remembering Sir Tony Hoare: A Masterclass in Lifelong Learning

The Inspiring Takeaway:

From Chaos to Clarity: My Journey Building JSON Query Pro

Problem I choose to solve

🚀 What I Built as Solution

Demo

📋 The Blueprint: What I Set Out to Build

🧩 The Wall: Obstacles Faced During Implementation

1. The "Where Am I?" Problem

2. The Performance Wall

3. The 1GB String Ceiling and V8 Buffer Limits

Screenshots

Sample Queries

🚀 Sample Data

🔍 Basic Retrieval (Simple Queries)

⚡ Advanced Selection (Complex Queries)

Filtering Data (JSONata Only)

Deep Search (The Double Star)

Reshaping Output

💡 Lessons Learned

🚀 Future Plans

🤖 My Experience with GitHub Copilot CLI

Conclusion

Story of The First Linked List

🙋‍♂️Hi

Prologue: A Problem Without Order

Chapter 1: The Insight

Chapter 2: The First Implementation

Chapter 3: Publication and Spread

Chapter 4: Why the Linked List Mattered

Epilogue: The Chain Continues

Bye 🙋‍♂️

References

Story of The First Array

🙋‍♂️Hi

Prologue: A Need for Order

Array in Hardware - The EDVAC Experiment

Problem - Data was scattered

Solution - Data stored in arrays of memory

From Hardware to Language – FORTRAN’s DIMENSION

Zero‑Based Indexing – ALGOL 60

Epilogue: The Legacy of a Simple Row

Bye 🙋‍♂️

References

Zero‑Based Indexing – ALGOL 60