DEV Community: Farhad Rahimi Klie

Why Git Was Created

Farhad Rahimi Klie — Mon, 11 May 2026 05:56:32 +0000

Before Git, the Linux kernel developers used a version control system called BitKeeper.

BitKeeper was proprietary software, but Linux developers could use it for free for kernel development.

Then in 2005:

Licensing conflicts happened
Access to BitKeeper was removed for Linux developers
The Linux kernel team suddenly lost the tool managing one of the world’s biggest software projects

This was a disaster.

The Linux kernel already had:

thousands of files
many developers
patches arriving constantly
changes from all over the world

Linus Torvalds needed a replacement immediately.

He did not like existing systems because they were:

slow
centralized
hard to merge
bad at handling large distributed development

So he decided to build his own system.

2. How Fast Git Was Built

This is one of the most famous parts of Git history.

The first version of Git was built in only a few days.

Core development timeline:

Day 1–2: Basic object storage and hashing concepts
Around Day 4: Could track file snapshots
Around Day 10: Basic branching and commits worked
Within about 2 weeks: Git became usable for Linux kernel development

That speed sounds impossible today, but several things made it possible:

Linus already understood:

operating systems
filesystems
performance engineering
distributed collaboration
kernel development workflows
low-level data structures

He was not experimenting randomly.

He already had a very clear mental model before writing code.

3. What Language Git Was Written In

Git was primarily written in:

Why C?

Because:

extremely fast
direct filesystem access
portable
already used heavily in Linux
minimal overhead
efficient memory control

Git also used:

shell scripting initially
some Perl scripts in older tooling

But the core engine was C.

Today Git includes:

C
shell
Perl
Python
Tcl/Tk
some platform-specific code

But its heart is still mostly C.

4. The Mentality Behind Git

This is the most important part.

Git was not designed like a normal “application.”

Linus designed Git like a filesystem + cryptographic database.

His mentality was:

“Store everything as immutable content objects.”

That single idea shaped all Git architecture.

5. The Core Philosophy of Git

Most old version control systems stored:

file differences
centralized history
sequential changes

Git instead stores:

complete snapshots
content-addressed objects
immutable history

This was revolutionary.

Git thinks like this:

Project State → Hash → Stored Object

Not:

Edit A → Edit B → Edit C

That difference is enormous.

6. Git’s Most Important Idea: Hashing

Git uses cryptographic hashes.

Originally:

SHA-1

Every file and object gets a unique hash.

Example:

e83c5163316f89bfbde7d9ab23ca2e25604af290

That hash identifies content.

Meaning:

if content changes
hash changes

So Git can detect:

modifications
corruption
exact history relationships

This made Git:

reliable
fast
distributed

7. Git Was Designed Backwards From Performance

Linus cared deeply about performance.

His priorities were:

Speed
Data integrity
Distributed workflow
Branching efficiency
Merge capability

Not:

pretty UI
beginner friendliness
enterprise features

That is why Git commands can feel difficult.

It was originally designed for kernel developers.

8. The Architecture of Git

Git internally stores objects:

Blob

Stores file contents.

Tree

Stores directory structures.

Commit

Stores:

author
timestamp
parent commits
snapshot reference

Tag

Named references.

Everything becomes objects.

9. Why Git Branching Is So Fast

In many older systems:

branches copied files

In Git:

branches are basically lightweight pointers.

A branch is almost just:

branch_name → commit_hash

That means:

branch creation is nearly instant
switching branches is fast
merging is easier

This was a huge innovation.

10. Git Was Built for Distributed Development

Older systems often relied on a central server.

Git changed this.

Every developer gets:

full history
full commits
full branches
complete repository

Meaning:

work offline
no single point of failure
easier collaboration

This was revolutionary in 2005.

11. How Linus Actually Built It

Linus usually builds software with this mentality:

Step 1 — Solve only the core problem

No unnecessary abstractions.

Step 2 — Make data structures efficient

Performance first.

Step 3 — Use small composable tools

Git originally had many tiny commands.

Step 4 — Trust powerful primitives

Instead of giant frameworks.

Step 5 — Optimize around real workflows

Not theoretical design.

This is very Unix-like thinking.

12. Early Git Was Extremely Rough

The first Git versions were:

ugly
command-line heavy
poorly documented
hard to use

Linus himself said he was not trying to make it pretty.

He only wanted:

speed
correctness
distributed functionality

Later developers improved usability.

One major contributor was:

Junio Hamano

He became the long-term maintainer and helped Git mature into a polished tool.

13. Why Git Became Dominant

Git became dominant because it solved real engineering pain better than competitors.

Major advantages:

fast branching
powerful merging
offline development
integrity checking
scalability
distributed collaboration

This made it perfect for:

open source
large engineering teams
internet-scale collaboration

Then platforms like:

GitHub
GitLab
Bitbucket

accelerated adoption massively.

14. The Most Important Technical Insight

Git is not really “a source control app.”

Internally, it is closer to:

a content-addressable object database
plus graph relationships
plus filesystem snapshots

That architectural decision is why Git still scales today.

15. Why Git Feels Complicated

Because Git exposes internal concepts directly:

HEAD
refs
index
detached HEAD
rebasing
object store

Linus optimized for:

power
flexibility
speed

not beginner simplicity.

That tradeoff is still visible today.

16. The Deep Engineering Lesson From Git

Git teaches a major software engineering principle:

Great systems are often built from a few powerful primitives.

Git’s primitives:

hashes
immutable objects
pointers
graphs
snapshots

From those few concepts, an entire ecosystem emerged.

17. Final Summary

Git was:

created in 2005
mainly built by Linus Torvalds
written mostly in C
initially usable within about 10–14 days
designed under extreme pressure
optimized for speed and distributed collaboration

The mentality behind Git was:

Simple primitives
+ immutable data
+ hashing
+ distributed architecture
+ performance-first engineering

That combination changed software development forever.

Ken Thompson — The Quiet Genius Who Helped Build Modern Computing

Farhad Rahimi Klie — Sun, 10 May 2026 03:17:37 +0000

When people talk about the history of computers, names like Bill Gates, Steve Jobs, or Linus Torvalds usually appear first. But behind many of the technologies those people used or improved, there was another engineer whose influence runs deeper than most people realize:

Ken Thompson.

If modern computing were a giant city, Ken Thompson helped design the roads, plumbing, and electricity before anyone else even started building houses.

He was not loud.
He was not a businessman.
He rarely chased fame.

But he helped create some of the most important technologies in computer history:

UNIX
The C programming ecosystem
The B programming language
UTF-8
Early operating system concepts
Modern software tools
Influential ideas behind Linux, macOS, Android, and much more

Almost every programmer today uses systems that were directly or indirectly shaped by his work.

This article explores who Ken Thompson is, how he thought, what he built, why his ideas mattered, and why computer science students should study him carefully.

Who Is Ken Thompson?

Ken Thompson was born on February 4, 1943, in New Orleans.

He became one of the most influential computer scientists in history and is best known for co-creating:

UNIX operating system
B programming language
Early UNIX tools
UTF-8 encoding

He worked mainly at Bell Labs, one of the greatest research laboratories ever created.

Bell Labs was not an ordinary company office. It was a place where scientists invented technologies that changed the world:

Transistors
Information theory
UNIX
C language
Laser technology
Satellite communication innovations

Many legendary computer scientists worked there, including:

Dennis Ritchie
Brian Kernighan
Claude Shannon

Ken Thompson became one of the brightest minds among them.

Early Interest in Computers

Ken Thompson studied electrical engineering and computer science at the:

University of California, Berkeley

During the 1960s, computers were massive, expensive machines. Programming was difficult, slow, and painful.

Most systems were:

Complicated
Hard to use
Hard to modify
Tightly controlled by companies

Thompson had a different mindset.

He believed software should be:

Simple
Elegant
Modular
Practical
Easy to combine

That philosophy later became the foundation of UNIX.

The World Before UNIX

To understand Ken Thompson’s importance, you must understand the computing world before UNIX.

In the 1960s:

Operating systems were huge and messy
Software was often tied to specific hardware
Portability barely existed
Developers wasted enormous time managing system complexity

One major project at the time was:

Multics

Multics was a collaborative project involving:

General Electric
MIT
Bell Labs

The goal was ambitious:

Build the ultimate operating system.

But there was a problem.

The project became extremely complicated.

Ken Thompson and Dennis Ritchie started feeling frustrated with its complexity.

This frustration eventually led to one of the greatest breakthroughs in computing history.

The Birth of UNIX

In 1969, after Bell Labs left the Multics project, Ken Thompson began building a simpler operating system.

Initially, he wanted a system where he could run a game called:

Space Travel

That small experiment became something much bigger.

He worked on an old machine:

PDP-7 computer

And started building tools and system components from scratch.

Soon, Dennis Ritchie joined him.

Together they created:

UNIX

The name UNIX was actually a joke inspired by “Multics.”

Multics was complicated and massive.

UNIX was supposed to be simpler and cleaner.

Why UNIX Was Revolutionary

UNIX changed computing forever because it introduced ideas that were radically different.

1. Everything Should Be Simple

Instead of giant programs doing everything, UNIX encouraged:

Small tools
Small commands
Single-purpose utilities

Each program should do one thing well.

This idea sounds normal today.

Back then, it was revolutionary.

2. Programs Should Work Together

UNIX introduced pipelines.

Example:

cat file.txt | grep hello | sort

This allowed programs to communicate easily.

Small tools could be connected together like LEGO blocks.

This philosophy deeply influenced modern software engineering.

3. Everything Is a File

In UNIX:

Devices
Processes
Hardware communication

could often be treated like files.

This simplified system design dramatically.

Even today, Linux and macOS still follow this idea.

4. Portability

UNIX became portable across different hardware.

That was an enormous breakthrough.

Before UNIX, operating systems were usually trapped on one machine type.

This portability later inspired:

Linux
BSD
macOS
Android internals

The Creation of the B Language

Before C language existed, Ken Thompson created:

B programming language

B was influenced by another language called:

BCPL

B was simple and powerful for system programming.

But computers evolved quickly, and B had limitations.

Then Dennis Ritchie improved those ideas and created:

C programming language

Without Ken Thompson’s B language, C might never have existed in the form we know today.

And without C:

Linux may not exist
Modern operating systems may look very different
Embedded systems would evolve differently
Modern compilers would change dramatically

UNIX and C Changed the Entire Industry

UNIX and C together became one of the most important combinations in computer history.

Why?

Because UNIX was rewritten in C.

That was groundbreaking.

Before this, operating systems were mostly written in assembly language.

Assembly is:

Hardware-specific
Hard to maintain
Difficult to port

C allowed UNIX to move between different computers much more easily.

This single decision transformed software engineering forever.

Influence on Linux and Modern Systems

Many people think Linux appeared from nowhere.

It did not.

Linus Torvalds created Linux heavily inspired by UNIX.

Modern systems influenced by UNIX include:

Linux
Android
macOS
BSD systems
iOS internals
Server infrastructure
Cloud computing systems

Even command-line tools today still reflect UNIX philosophy.

When developers use commands like:

ls
grep
cat
awk
sed

they are using ideas that came from Thompson’s era.

Ken Thompson and UTF-8

One of Ken Thompson’s lesser-known but extremely important contributions was:

UTF-8

He worked with:

Rob Pike

to help develop UTF-8.

UTF-8 became the dominant text encoding standard for the internet.

Without UTF-8, handling global languages would be much harder.

Today UTF-8 powers:

Websites
Databases
APIs
Operating systems
Programming languages

Almost every developer uses UTF-8 daily, often without realizing it.

The UNIX Philosophy

The “UNIX Philosophy” became one of the most influential engineering mindsets ever created.

Core principles include:

Build Small Tools

Avoid giant complicated systems when possible.

Make Programs Composable

Programs should connect together easily.

Prefer Simplicity

Simple systems survive longer.

Write Clear Code

Readable systems are maintainable systems.

Avoid Unnecessary Complexity

Complexity is expensive.

This philosophy strongly influenced:

Open-source culture
Linux development
DevOps tools
Modern backend engineering
Cloud infrastructure

Even modern container systems like:

Docker

inherit UNIX-style thinking.

Ken Thompson’s Programming Style

Many legendary programmers admired Thompson because of his coding style.

His code was often described as:

Minimal
Elegant
Efficient
Clever without being messy

He avoided unnecessary abstraction.

He focused on practical engineering.

This is important because modern software sometimes becomes overly complicated.

Thompson believed good engineering often means removing complexity, not adding more features.

The Famous “Trusting Trust” Lecture

One of Ken Thompson’s most famous contributions to computer security was his lecture:

“Reflections on Trusting Trust.”

This lecture explained a terrifying idea.

A compiler could secretly inject malicious code into software automatically.

Even if developers inspect the source code, the malicious behavior could remain hidden.

This concept became one of the foundational ideas in software supply chain security.

Today, discussions about:

Compiler trust
Build security
Supply chain attacks

still reference Thompson’s ideas.

Modern cybersecurity experts continue studying this work.

Awards and Recognition

Ken Thompson received many major awards, including:

Turing Award

Often called:

“The Nobel Prize of Computing.”

He received it together with:

Dennis Ritchie

for UNIX development.

National Medal of Technology

Awarded by the United States government.

Japan Prize

Another major international scientific award.

Despite all these achievements, Thompson remained relatively humble and quiet.

Working at Google

Later in his career, Ken Thompson worked at:

Google

He contributed to various systems and engineering projects.

Even in modern computing eras, his expertise remained extremely valuable.

Why Ken Thompson Matters to Programmers

Many beginner programmers focus only on modern frameworks.

But understanding pioneers like Ken Thompson teaches deeper lessons.

He teaches us:

1. Simplicity Is Powerful

Complexity is not intelligence.

Clear systems often outperform complicated ones.

2. Good Tools Matter

Developer productivity depends heavily on tools.

UNIX tools changed how programmers work.

3. Software Design Matters

Architecture decisions can influence decades of technology.

UNIX ideas survived for over 50 years.

That is extraordinary.

4. Elegant Thinking Beats Hype

Ken Thompson was not known for marketing.

He was known for solving problems well.

Ken Thompson’s Lasting Legacy

Today, millions of developers unknowingly use his ideas every day.

When you:

Open a Linux terminal
Use macOS
Run cloud servers
Write UTF-8 text
Use command-line pipelines
Study operating systems

you are interacting with Thompson’s legacy.

Very few individuals have shaped computing this deeply.

His influence exists beneath the surface of modern technology.

Invisible. Foundational. Permanent.

Final Thoughts

Ken Thompson is one of the true architects of modern computing.

He helped create systems and philosophies that transformed software engineering forever.

What makes his story especially important is this:

He did not chase complexity.
He chased clarity.

He did not build technology just to impress people.
He built systems that worked beautifully.

And that mindset is something every programmer should learn.

Because in the end, the best engineering is often not about adding more.

It is about understanding what can be removed while keeping the system powerful.

That was Ken Thompson’s genius.

GDB Debugger for C and C++ – Complete Guide

Farhad Rahimi Klie — Mon, 04 May 2026 01:52:31 +0000

Introduction

Debugging is a critical skill for any systems programmer working with C or C++. Unlike higher-level languages, C and C++ give you direct access to memory and low-level operations, which makes debugging both powerful and complex. The GNU Debugger (GDB) is one of the most widely used tools for debugging C and C++ programs.

What is GDB?

GDB (GNU Debugger) is a command-line debugging tool used to inspect and control the execution of programs. It allows developers to:

Pause execution (breakpoints)
Step through code line-by-line
Inspect variables and memory
Modify program state at runtime
Analyze crashes and core dumps

GDB works by interfacing with compiled binaries that include debugging symbols.

Installing GDB

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install gdb

macOS (with Homebrew)

brew install gdb

Windows

Use MinGW or WSL:

Install WSL and Ubuntu
Then install GDB inside WSL

Compiling with Debug Symbols

To use GDB effectively, you must compile your program with debug information using the -g flag:

gcc -g program.c -o program
g++ -g program.cpp -o program

Optional flags:

-O0 → disable optimization (recommended for debugging)
-Wall → show warnings

Example:

gcc -g -O0 -Wall main.c -o main

Starting GDB

gdb ./program

Once inside GDB:

(gdb)

Running the Program

run

With arguments:

run arg1 arg2

Breakpoints

Set breakpoint at function

break main

Set breakpoint at line

break 10

Set breakpoint in file

break file.c:25

List breakpoints

info breakpoints

Delete breakpoint

delete 1

Stepping Through Code

Step into (enter functions)

step

Step over (skip function internals)

next

Continue execution

continue

Finish current function

finish

Inspecting Variables

Print variable

print x

Print pointer value

print *ptr

Display automatically

display x

Show all local variables

info locals

Working with Memory

Examine memory

x/4x ptr

Format explanation:

4 → number of units
x → hexadecimal format

Examples:

x/10d ptr   # decimal
x/5c ptr    # characters

Call Stack (Backtrace)

When a crash occurs:

backtrace

This shows the function call chain.

Navigate stack:

frame 0
frame 1

Watchpoints

Watchpoints track variable changes.

watch x

Breaks when x changes.

Conditional Breakpoints

break 20 if x == 5

Modifying Variables

set variable x = 10

Debugging Segmentation Faults

Compile with -g, then run:

gdb ./program
run

When it crashes:

backtrace

Check variables:

print ptr

Common causes:

Null pointer dereference
Out-of-bounds array access
Use-after-free

Core Dumps

Enable core dumps:

ulimit -c unlimited

Run program → crash generates core file.

Analyze:

gdb program core

Debugging Multi-file Projects

Compile all files with -g:

gcc -g main.c utils.c -o app

Then debug normally.

Working with C++ in GDB

GDB supports:

Classes
Objects
Templates
STL containers (with limitations)

Print object:

print obj

Pretty printing (for STL):

set print pretty on

Advanced Features

1. TUI Mode (Text UI)

gdb -tui ./program

2. Layout Commands

layout src
layout asm

3. Disassembly

disassemble main

4. Reverse Debugging (if supported)

reverse-continue

Useful GDB Shortcuts

Command	Description
r	run
c	continue
n	next
s	step
bt	backtrace
p	print

Example Debugging Session

Code (buggy)

#include <stdio.h>

int main() {
    int *ptr = NULL;
    printf("%d\n", *ptr);
    return 0;
}

Steps

gcc -g main.c -o main
gdb ./main
break main
run
next
print ptr

You will see ptr = 0x0 → null pointer → crash.

Best Practices

Always compile with -g
Disable optimization (-O0) while debugging
Use meaningful variable names
Reproduce bugs consistently
Use watchpoints for tricky bugs
Learn keyboard shortcuts

Conclusion

GDB is an essential tool for any C/C++ developer. Mastering it allows you to deeply understand program execution, memory behavior, and runtime issues. While it may feel complex initially, consistent practice will make debugging faster and more efficient.

If you are serious about systems programming, learning GDB is not optional—it is fundamental.

How We Built Our Own Database Engine 🚀

Farhad Rahimi Klie — Sat, 25 Apr 2026 02:28:50 +0000

Building a database engine from scratch might sound intimidating—but it’s one of the most rewarding ways to truly understand how data systems work under the hood. In this article, I’ll walk you through the journey of creating a simple custom database engine, the challenges we faced, and what we learned along the way.

🧠 Why Build a Database Engine?

At first, it might seem unnecessary—after all, we already have powerful databases like MySQL, PostgreSQL, and MongoDB. But building your own gives you:

A deep understanding of data storage and retrieval
Insight into performance optimization
Hands-on experience with memory management
Better problem-solving skills as a developer

This project isn’t about replacing existing databases—it’s about learning how they work.

⚙️ Core Concepts We Needed

Before writing any code, we had to understand the fundamentals:

1. Storage Engine

This is how data is physically stored. We chose a simple file-based system where records are written directly to disk.

2. Data Serialization

We needed a way to convert structured data into a format that can be stored and retrieved efficiently.

3. Indexing

Without indexing, searching would be painfully slow. We implemented a basic indexing mechanism to speed up lookups.

4. Query Processing

Even a minimal database needs to interpret commands like:

INSERT
SELECT
DELETE

🏗️ Architecture Overview

Our database engine consists of several key components:

+---------------------+
|   Query Interface   |
+---------------------+
           |
+---------------------+
|   Query Parser      |
+---------------------+
           |
+---------------------+
| Execution Engine    |
+---------------------+
           |
+---------------------+
| Storage Manager     |
+---------------------+
           |
+---------------------+
| File System         |
+---------------------+

Each layer has a specific responsibility, making the system modular and easier to debug.

💾 Step 1: Designing the Storage Layer

We started by implementing a simple storage mechanism:

Data is stored in binary files
Each record has a fixed size
File offsets are used for quick access

Example idea in C:

typedef struct {
    int id;
    char name[50];
} Record;

We used file operations like fopen, fwrite, and fread to manage data.

🔍 Step 2: Implementing Indexing

To avoid scanning the entire file every time, we added a basic index:

Key → File offset mapping
Stored in memory for fast lookup

This allowed us to jump directly to the record location instead of reading everything.

🧾 Step 3: Query Parser

We created a simple parser that understands commands like:

INSERT 1 Farhad
SELECT 1
DELETE 1

The parser splits input into tokens and maps them to operations.

⚡ Step 4: Execution Engine

The execution engine is the brain of the system:

Receives parsed queries
Calls appropriate functions
Interacts with storage and index

For example:

if (command == INSERT) {
    insert_record(...);
}

🧹 Step 5: Memory Management

Since we were working in C, memory handling was critical:

Manual allocation (malloc)
Deallocation (free)
Avoiding leaks and fragmentation

We also implemented simple block management to reuse freed space.

🚧 Challenges We Faced

1. Data Corruption

A small mistake in file handling could corrupt the entire database.

2. Synchronization

Ensuring data consistency between memory and disk was tricky.

3. Performance

Naive implementations were slow—indexing made a huge difference.

📈 What We Learned

How databases manage data internally
Importance of abstraction and modular design
Low-level memory and file system operations
Trade-offs between simplicity and performance

🚀 Future Improvements

If we were to take this further:

Add B-Tree indexing
Support complex queries (WHERE, JOIN)
Implement transactions (ACID properties)
Add concurrency control

🎯 Final Thoughts

Building your own database engine isn’t just a project—it’s an experience that transforms how you think about data systems. Even a simple implementation teaches concepts that are used in real-world databases at scale.

If you're a developer who enjoys digging deep into systems, this is one of the best projects you can take on.

💡 Bonus Tip

If you’re planning to share your project on GitHub, include:

Clear documentation
Example commands
Screenshots or demos

It makes your project much more attractive and understandable.

Happy coding! 🔥

Binary and Hexadecimal Number Systems — A Complete Guide for Low-Level Programming

Farhad Rahimi Klie — Tue, 21 Apr 2026 09:57:31 +0000

When you work close to hardware—whether in C, C++, embedded systems, operating systems, or reverse engineering—you must think like the machine. And machines do not understand decimal numbers. They operate using binary (base-2). To make binary manageable for humans, we use hexadecimal (base-16).

This article gives you a complete, step-by-step understanding of both systems, with practical insight for real programming scenarios.

1. Why Number Systems Matter in Low-Level Programming

At the hardware level:

Memory stores bits (0 and 1)
CPU processes binary instructions
Registers, pointers, addresses → all binary

But binary is long and hard to read. That’s where hexadecimal comes in—it’s a compact human-friendly representation of binary.

2. Binary Number System (Base 2)

2.1 Definition

Binary uses only two digits:

0 and 1

Each position represents a power of 2.

2.2 Positional Value

Example:

1011₂

Break it down:

1×2³ + 0×2² + 1×2¹ + 1×2⁰
= 8 + 0 + 2 + 1
= 11₁₀

2.3 Binary Table (Important to Memorize)

Power	Value
2⁰	1
2¹	2
2²	4
2³	8
2⁴	16
2⁵	32
2⁶	64
2⁷	128

These are critical for bit manipulation.

2.4 Binary in Memory

A bit = 0 or 1
A byte = 8 bits

Example:

00001010 → 10 in decimal

2.5 Binary Representation of Numbers

Positive Numbers

Stored directly:

5 → 00000101

Negative Numbers (Two’s Complement)

Steps:

Convert to binary
Invert bits
Add 1

Example: -5 (8-bit)

5      = 00000101
Invert = 11111010
+1     = 11111011

2.6 Binary Operations

AND (&)

1 & 1 = 1
1 & 0 = 0

OR (|)

1 | 0 = 1

XOR (^)

1 ^ 1 = 0
1 ^ 0 = 1

NOT (~)

~00000101 = 11111010

2.7 Example in C

#include <stdio.h>

int main() {
    int a = 5;   // 00000101
    int b = 3;   // 00000011

    printf("AND: %d\n", a & b); // 1
    printf("OR : %d\n", a | b); // 7
    printf("XOR: %d\n", a ^ b); // 6

    return 0;
}

3. Hexadecimal Number System (Base 16)

3.1 Definition

Hexadecimal uses:

0–9 and A–F

Hex	Decimal
A	10
B	11
C	12
D	13
E	14
F	15

3.2 Why Hexadecimal?

Binary is long:

11111111

Hex makes it short:

FF

So:

1 byte = 8 bits = 2 hex digits

3.3 Positional Value

Example:

2F₁₆

2×16¹ + 15×16⁰
= 32 + 15
= 47₁₀

3.4 Binary ↔ Hex Conversion (CRITICAL SKILL)

Rule:

Group binary into 4 bits

Example 1: Binary → Hex

10101111

Group:

1010 1111

Convert:

1010 = A
1111 = F

Result:

AF₁₆

Example 2: Hex → Binary

3C

Convert each:

3 = 0011
C = 1100

Result:

00111100

3.5 Hex in Programming

C Example:

int x = 0xFF;  // 255
int y = 0x1A;  // 26

Memory Address:

0x7ffeefbff5c8

4. Binary vs Hexadecimal (Comparison)

Feature	Binary	Hexadecimal
Base	2	16
Digits	0,1	0–9, A–F
Length	Long	Short
Usage	Machine level	Human-friendly

5. Real Use Cases in Low-Level Programming

5.1 Memory Inspection

Debugger output:

0x7fff → address

5.2 Bit Masking

int flags = 0x0F; // 00001111

5.3 Embedded Systems

Registers:

0xFF00 → hardware control

5.4 Networking

IP (hex view):

C0 A8 01 01 → 192.168.1.1

5.5 Assembly Language

MOV AX, 0x1F

6. Conversion Methods (Step-by-Step)

6.1 Decimal → Binary

Divide by 2 repeatedly:

13 ÷ 2 = 6 r1
6 ÷ 2  = 3 r0
3 ÷ 2  = 1 r1
1 ÷ 2  = 0 r1

Result: 1101

6.2 Decimal → Hex

Divide by 16:

47 ÷ 16 = 2 r15 (F)
2 ÷ 16  = 0 r2

Result: 2F

6.3 Binary → Decimal

Multiply powers of 2.

6.4 Hex → Decimal

Multiply powers of 16.

7. Important Patterns to Master

7.1 Hex ↔ Binary Table (Must Memorize)

Hex	Binary
0	0000
1	0001
2	0010
3	0011
4	0100
5	0101
6	0110
7	0111
8	1000
9	1001
A	1010
B	1011
C	1100
D	1101
E	1110
F	1111

8. Common Mistakes

Mixing base systems (e.g., treating hex as decimal)
Forgetting grouping in binary → hex
Ignoring leading zeros
Confusing ASCII vs numeric values

9. How to Master This (Practical Strategy)

Memorize powers of 2
Memorize hex ↔ binary table
Practice conversions daily
Use C programs to verify results
Read memory using debuggers (gdb)

10. Final Insight

Binary is the language of machines.
Hexadecimal is the language of programmers working close to machines.

If you master both:

Bit manipulation becomes easy
Debugging becomes powerful
System programming becomes natural

Mental Models for Programmers: Thinking Beyond Code

Farhad Rahimi Klie — Thu, 16 Apr 2026 03:29:17 +0000

Programming is not just about syntax, frameworks, or algorithms. At its core, it’s about how you think. The difference between an average developer and a great one often lies in the mental models they use to understand problems, design systems, and debug issues.

What is a Mental Model?

A mental model is a simplified way of understanding how something works in the real world. In programming, mental models help you:

Break down complex systems
Predict behavior before running code
Debug efficiently
Design scalable architectures

Think of mental models as your internal “toolkit for thinking.”

1. Divide and Conquer

Core Idea: Break complex problems into smaller, manageable parts.

When you face a large problem, don’t try to solve it all at once. Instead:

Split it into subproblems
Solve each independently
Combine results

Example:
Building a web app:

UI (Frontend)
API (Backend)
Database (Storage)

Each layer can be developed and tested separately.

Why it matters:
Reduces cognitive load and improves maintainability.

2. Abstraction

Core Idea: Hide complexity, expose only what’s necessary.

Good programmers don’t deal with every detail all the time. They create layers.

Examples:

Functions hide implementation details
APIs hide system complexity
Classes encapsulate behavior

int result = add(5, 3);

You don’t care how add works internally — that’s abstraction.

Why it matters:
Makes systems easier to use, understand, and scale.

3. First Principles Thinking

Core Idea: Break problems down to fundamental truths and build from there.

Instead of relying on assumptions:

Ask: What do I know for sure?
Rebuild the solution from basics

Example:
Instead of memorizing how a database index works, understand:

Data storage
Searching cost (O(n) vs O(log n))
Tree structures

Why it matters:
Helps you solve new problems, not just repeat known solutions.

4. Trade-offs (There is No Perfect Solution)

Core Idea: Every decision has a cost.

In programming, you constantly balance:

Speed vs Memory
Readability vs Performance
Simplicity vs Flexibility

Example:

Array → fast access, slow insert
Linked list → slow access, fast insert

Why it matters:
Prevents overengineering and helps you choose the right solution, not the perfect one.

5. DRY (Don’t Repeat Yourself)

Core Idea: Avoid duplication.

If you write the same logic multiple times, it becomes:

Hard to maintain
Error-prone

Instead:

Extract reusable functions
Use shared modules

Bad:

if (user.isAdmin) { ... }
if (user.isAdmin) { ... }

Good:

bool isAdmin(User u) { return u.role == "admin"; }

Why it matters:
Reduces bugs and improves maintainability.

6. KISS (Keep It Simple, Stupid)

Core Idea: Simpler solutions are better.

Avoid unnecessary complexity.

Bad mindset:

“Let’s use microservices, AI, and blockchain for this small app.”

Good mindset:

“What is the simplest solution that works?”

Why it matters:
Simple systems are easier to debug, extend, and scale.

7. YAGNI (You Aren’t Gonna Need It)

Core Idea: Don’t build for the future unnecessarily.

Programmers often over-engineer:

Adding features “just in case”
Designing systems for scale they don’t have

Reality:
Most of those features are never used.

Why it matters:
Saves time and keeps code clean.

8. Feedback Loops

Core Idea: Shorten the cycle between action and result.

Fast feedback improves learning and debugging.

Examples:

Unit tests
Logging
REPL environments

Why it matters:
The faster you see results, the faster you improve.

9. Systems Thinking

Core Idea: Everything is connected.

A bug in one part of the system can affect another.

Example:

Slow database → slow API → bad user experience

Instead of thinking in isolation, think in flows:

Input → Processing → Output

Why it matters:
Helps in designing scalable and reliable systems.

10. Inversion (Think Backwards)

Core Idea: Start from failure and work backward.

Ask:

“How can this system fail?”
“What could go wrong?”

Example:
Instead of only designing login:

What if password is wrong?
What if server is down?
What if user is hacked?

Why it matters:
Leads to more robust and secure systems.

11. Constraints Drive Creativity

Core Idea: Limitations improve solutions.

Constraints like:

Low memory
Slow network
Limited CPU

Force you to think smarter.

Why it matters:
Real-world systems always have constraints.

12. Readability > Cleverness

Core Idea: Code is read more than it is written.

Bad:

int x=!!a<<2|b^c;

Good:

int result = (a ? 1 : 0) * 4 | (b ^ c);

Why it matters:
Your future self (and team) will thank you.

Final Thoughts

Learning programming languages and frameworks is important — but they change constantly.

Mental models, however, are timeless.

If you master how to think:

You learn faster
Solve problems better
Build systems that last

Key Takeaway

Great programmers don’t just write code — they think in systems, trade-offs, and abstractions.

Git Stash — The Complete Guide Every Developer Should Know

Farhad Rahimi Klie — Mon, 13 Apr 2026 02:19:49 +0000

When you're working on a project, it’s very common to start coding something and suddenly realize you need to switch branches, fix a bug, or pull new changes. But your current work is incomplete and not ready to commit.

This is exactly where Git Stash becomes one of the most powerful tools in your workflow.

In this article, we will explore Git Stash in depth — from basics to advanced usage — with real-world scenarios and clear explanations.

🚀 What is Git Stash?

Git Stash temporarily saves your uncommitted changes (both staged and unstaged) so you can work on something else and come back later.

Think of it as a temporary storage (clipboard) for your code changes.

🧠 Why Use Git Stash?

Here are common scenarios:

You are in the middle of work but need to switch branches
You need to quickly fix a bug in production
You want to pull latest changes but your working directory is dirty
You want a clean working tree without committing incomplete work

📦 Basic Usage

1. Save Changes

git stash

This command:

Saves your modified tracked files
Reverts your working directory to the last commit

2. View Stashes

git stash list

Example output:

stash@{0}: WIP on main: 123abc Fix login bug
stash@{1}: WIP on feature: 456def Add new API

3. Apply Stash

git stash apply

This restores the latest stash but keeps it in the stash list.

4. Apply and Remove (Pop)

git stash pop

This:

Applies the stash
Removes it from the stash list

5. Drop a Stash

git stash drop stash@{0}

Deletes a specific stash.

6. Clear All Stashes

git stash clear

⚠️ Warning: This deletes all stashes permanently.

🔍 Stashing Specific Changes

Stash Only Staged Changes

git stash --staged

Stash Including Untracked Files

git stash -u

git stash --include-untracked

Stash Everything (Including Ignored Files)

git stash -a

🏷️ Naming Your Stash

Instead of default messages, you can name your stash:

git stash push -m "WIP: payment integration"

This helps a lot when managing multiple stashes.

🔄 Applying Specific Stash

git stash apply stash@{1}

🔀 Create Branch from Stash

One of the most useful features:

git stash branch new-branch-name

This:

Creates a new branch
Applies the stash
Removes it from stash list

Perfect when your temporary work becomes important.

⚠️ Handling Conflicts

When applying a stash, conflicts may occur if:

The same lines were changed
The codebase has evolved

Git will mark conflicts just like a merge:

<<<<<<< HEAD
Your current code
=======
Stashed code
>>>>>>> stash

You must resolve these manually.

🧩 Internal Working (Advanced)

When you run:

git stash

Git actually creates:

A commit for your working directory
A commit for your index (staged changes)

These are stored in a special reference:

refs/stash

So stash is not magic — it's structured commits behind the scenes.

🔥 Real-World Workflow Example

Scenario:

You're working on a feature:

git checkout feature-auth

You modify files but suddenly:

👉 You must fix a bug in main

Solution:

git stash
git checkout main
# fix bug
git commit -m "hotfix: login issue"
git checkout feature-auth
git stash pop

You’re back exactly where you left off.

💡 Best Practices

Use descriptive stash messages
Avoid keeping too many stashes
Prefer branches for long-term work
Use git stash pop carefully (it deletes stash)

❌ Common Mistakes

Forgetting stash exists → losing track of work
Using stash instead of proper commits
Not naming stashes → confusion later
Clearing stash accidentally

🧠 Pro Tips

Use git stash show -p to see full diff:

git stash show -p stash@{0}

Stash only part of changes (interactive):

git stash -p

Combine with rebase or pull for cleaner workflow

🎯 Conclusion

Git Stash is a powerful, flexible tool that helps you:

Switch context quickly
Keep your work safe
Maintain a clean workflow

But remember:

👉 It’s a temporary solution, not a replacement for commits or branches.

Mastering Git Stash will significantly improve your productivity and confidence when working with Git.

Git Merge vs Rebase — A Complete Guide for Developers

Farhad Rahimi Klie — Thu, 09 Apr 2026 04:07:43 +0000

When working with version control using Git, one of the most important concepts you must master is how to integrate changes from one branch into another. Two primary strategies exist for this: merge and rebase.

Although both achieve the same goal—combining changes—they do so in fundamentally different ways. Understanding these differences is critical for maintaining a clean, understandable project history.

🔹 What is Git Merge?

Concept

Git merge combines two branches by creating a new merge commit. It preserves the complete history of both branches.

How it Works

Imagine this:

A---B---C (main)
     \
      D---E (feature)

When you run:

git checkout main
git merge feature

Git creates a new commit:

A---B---C-------M (main)
     \         /
      D---E--- (feature)

👉 M is the merge commit.

Key Characteristics

Preserves full history
Non-destructive operation
Creates extra commit (merge commit)
Shows exact branching structure

Advantages

Safe and simple
Keeps context of how features were developed
Ideal for team collaboration

Disadvantages

History becomes messy with many branches
Harder to read in large projects

🔹 What is Git Rebase?

Concept

Git rebase moves (or “replays”) commits from one branch on top of another, creating a linear history.

How it Works

Starting from:

A---B---C (main)
     \
      D---E (feature)

Run:

git checkout feature
git rebase main

Result:

A---B---C---D'---E' (feature)

👉 D' and E' are new commits (rewritten history).

Key Characteristics

Rewrites commit history
No merge commit
Creates a linear timeline

Advantages

Clean, linear history
Easier to understand logs
Better for debugging and tracking changes

Disadvantages

Can be dangerous if misused
Rewrites history (problematic for shared branches)
Requires more understanding

🔥 Merge vs Rebase — Side-by-Side

Feature	Merge	Rebase
History	Preserved (non-linear)	Rewritten (linear)
Commit creation	Creates merge commit	No merge commit
Safety	Very safe	Risky if shared
Readability	Can be messy	Clean and linear
Use case	Team collaboration	Clean history before merge

⚠️ When to Use Merge

Use merge when:

Working on shared/public branches
Collaborating with a team
You want to preserve full history
You want a safe operation

Example:

git checkout main
git merge feature

⚠️ When to Use Rebase

Use rebase when:

Cleaning up your local commits
Preparing a feature branch before merging
You want a linear history

Example:

git checkout feature
git rebase main

🚨 Golden Rule of Rebase

Never rebase a shared branch

Why?

Because rebase rewrites history. If others are working on the same branch, rebasing will cause conflicts and confusion.

🔧 Interactive Rebase (Advanced)

One of the most powerful features of rebase is interactive mode:

git rebase -i HEAD~3

This allows you to:

Squash commits
Rename commit messages
Reorder commits
Remove unnecessary commits

Example:

pick 1st commit
squash 2nd commit
reword 3rd commit

🧠 Real-World Workflow

Typical Professional Workflow:

Create feature branch
Work and commit changes
Rebase onto latest main
Merge into main

git checkout feature
git rebase main
git checkout main
git merge feature

🔄 Visual Comparison

Merge History (Non-linear)

A---B---C-------M
     \         /
      D---E---

Rebase History (Linear)

A---B---C---D'---E'

🏁 Conclusion

Both merge and rebase are essential tools in Git, and neither is “better” universally—it depends on your workflow.

Use merge for safety and collaboration
Use rebase for clean, readable history

👉 The best developers know when to use each, not just how.

💬 Final Tip

If you're working in a team, always follow your team's Git strategy. Consistency matters more than preference.

Why Git Rebase Will Change How You Use Git Forever

Farhad Rahimi Klie — Tue, 07 Apr 2026 02:35:30 +0000

Introduction

When working with Git, managing commit history is just as important as writing clean code. One of the most powerful — and sometimes misunderstood — tools for this purpose is git rebase.

What is Git Rebase?

At a high level, git rebase is used to move or “replay” commits from one branch onto another.

Instead of merging branches together (like git merge), rebase rewrites commit history to make it look like your work was built on top of another branch from the beginning.

The Core Idea

Let’s say you have:

main:     A --- B --- C
feature:             D --- E

Now, new commits are added to main:

main:     A --- B --- C --- F --- G
feature:             D --- E

If you run:

git rebase main

Git will:

Temporarily remove commits D and E
Move your branch to G
Replay D and E on top of G

Result:

main:     A --- B --- C --- F --- G
feature:                         D' --- E'

Note: D' and E' are new commits (rewritten versions)

Why Use Rebase?

1. Clean History

Rebase creates a linear commit history, making it easier to read and understand.

Instead of this:

      /--- D --- E
A --- B --- C --- M

You get:

A --- B --- C --- D --- E

2. Better for Code Reviews

Reviewing a clean, linear history is much easier than dealing with merge commits.

3. Avoids Unnecessary Merge Commits

Rebase prevents clutter like:

Merge branch 'main' into feature

Rebase vs Merge

Feature	git merge	git rebase
History	Non-linear	Linear
New commits	Adds merge commit	Rewrites commits
Safety	Safe (no rewrite)	Risky if misused
Collaboration	Preferred	Careful usage needed

Basic Commands

Rebase current branch onto another

git rebase main

Interactive Rebase

git rebase -i HEAD~3

This allows you to:

Edit commits
Squash commits
Reorder commits
Remove commits

Example:

pick 123abc Add login
pick 456def Fix bug
pick 789ghi Improve UI

You can change to:

pick 123abc Add login
squash 456def Fix bug
pick 789ghi Improve UI

What Happens Internally?

When you run rebase:

Git finds the common ancestor
Extracts your commits as patches
Resets your branch pointer
Applies patches one by one

This is why commit hashes change — they are new commits.

Handling Conflicts

During rebase, conflicts may occur.

Git will pause and show:

CONFLICT (content): Merge conflict in file.c

Steps to resolve:

Fix the conflict manually
Stage the file:

   git add file.c

Continue:

   git rebase --continue

If needed:

git rebase --abort

Golden Rule of Rebase

❗ Never rebase public/shared branches

Why?

Because rebase rewrites history, and this can break other developers’ work.

When Should You Use Rebase?

Use rebase when:

Working on local feature branches
Cleaning up commits before pushing
Keeping history linear

Avoid rebase when:

Working on shared branches
The branch is already pushed and used by others

Advanced Example: Squashing Commits

Before:

Add feature
Fix typo
Fix bug
Improve code

After squash:

Add feature (clean version)

Command:

git rebase -i HEAD~4

Common Mistakes

1. Rebasing Shared Branches

This can cause major confusion and broken history.

2. Forgetting Force Push

After rebase, you must push with:

git push --force

(or safer:)

git push --force-with-lease

3. Losing Commits

If something goes wrong:

git reflog

You can recover lost commits.

Mental Model

Think of rebase as:

“Take my changes and pretend I wrote them after the latest version of the branch.”

Conclusion

Git Rebase is a powerful tool that:

Keeps history clean
Improves collaboration (when used correctly)
Helps maintain a professional commit structure

But it must be used with discipline and understanding.

If you master rebase, you move from just “using Git” to truly controlling your project history.

Final Tip

Start using rebase in your local workflow first, then gradually introduce it into team practices with clear guidelines.

Happy coding 🚀

Zig Programming Language — Complete Guide

Farhad Rahimi Klie — Sat, 04 Apr 2026 02:57:47 +0000

If you're a systems programmer—or want to become one—Zig is a language you cannot ignore. It is designed as a modern alternative to C, focusing on simplicity, performance, and control without hidden behavior.

1. What is Zig?

Zig is a low-level, general-purpose programming language designed for:

Systems programming
Embedded development
Performance-critical applications

👉 Created by Andrew Kelley
👉 First released in 2015

2. Design Philosophy

Zig is built on a few strong principles:

1. No Hidden Control Flow

Unlike many languages:

No hidden allocations
No exceptions
No implicit behavior

👉 Everything is explicit.

2. Manual Memory Management

Like C:

You control memory
No garbage collector

But safer and clearer.

3. Simplicity Over Abstraction

Zig avoids:

Complex OOP systems
Heavy abstractions

👉 Focus = clarity + control

4. Compile-Time Execution

Zig has powerful compile-time evaluation:

Code can run at compile time
Enables metaprogramming

3. Installing Zig

Download from:

👉 https://ziglang.org

Check version:

zig version

4. Your First Zig Program

const std = @import("std");

pub fn main() void {
    std.debug.print("Hello, Zig!\n", .{});
}

Run:

zig run main.zig

5. Basic Syntax

Variables

var x: i32 = 10;     // mutable
const y: i32 = 20;   // immutable

Type inference:

const a = 5;

Primitive Types

Integers: i32, u64
Float: f32, f64
Boolean: bool
Void: void

Control Flow

If

if (x > 10) {
    // do something
} else {
    // do something else
}

While

while (x < 100) {
    x += 1;
}

For

for (items) |item| {
    std.debug.print("{}\n", .{item});
}

6. Functions

fn add(a: i32, b: i32) i32 {
    return a + b;
}

Multiple Return (Error Union)

fn divide(a: i32, b: i32) !i32 {
    if (b == 0) return error.DivisionByZero;
    return a / b;
}

7. Error Handling (Very Important)

Zig does not use exceptions.

Instead:

Error Union

const result = divide(10, 2) catch 0;

Try Keyword

const result = try divide(10, 2);

👉 If error → return immediately

Error Sets

error{OutOfMemory, InvalidInput}

8. Pointers

Zig uses pointers like C, but safer.

var x: i32 = 10;
var ptr = &x;

Dereference:

ptr.* = 20;

Nullable Pointer

var ptr: ?*i32 = null;

9. Arrays and Slices

Array

var arr = [5]i32{1,2,3,4,5};

Slice (View into array)

var slice = arr[0..3];

👉 Slices are widely used in Zig

10. Structs

const Person = struct {
    name: []const u8,
    age: u8,
};

Usage:

var p = Person{ .name = "Ali", .age = 20 };

11. Enums

const Color = enum {
    Red,
    Green,
    Blue,
};

12. Memory Management

Zig uses allocators explicitly.

Example

const allocator = std.heap.page_allocator;

var memory = try allocator.alloc(i32, 10);
defer allocator.free(memory);

Key Idea

👉 You always know:

Where memory comes from
Who frees it

13. Defer Keyword

Runs code when scope ends:

defer std.debug.print("Done\n", .{});

14. Compile-Time Programming (Zig Superpower)

comptime

fn square(comptime x: i32) i32 {
    return x * x;
}

Example: Generate Code

inline for (0..5) |i| {
    std.debug.print("{}\n", .{i});
}

👉 Executed at compile time

15. No Preprocessor (Unlike C)

Zig replaces macros with:

Functions
comptime

👉 Cleaner and safer

16. Interoperability with C

Zig can directly use C code.

Import C

const c = @cImport({
    @cInclude("stdio.h");
});

👉 You can:

Call C functions
Use C libraries

17. Build System (Built-in)

Zig includes its own build system.

Example:

const std = @import("std");

pub fn build(b: *std.Build) void {
    const exe = b.addExecutable("app", "main.zig");
    exe.install();
}

Run:

zig build

18. Cross Compilation (Very Powerful)

Zig can compile for different platforms easily:

zig build-exe main.zig -target x86_64-linux

👉 No external toolchains needed

19. Testing in Zig

Built-in testing:

test "addition works" {
    try std.testing.expect(add(2,3) == 5);
}

Run:

zig test main.zig

20. Performance

Zig is:

Comparable to C
No runtime overhead
Zero-cost abstractions

21. Zig vs C

Feature	C	Zig
Memory control	Yes	Yes
Safety	Low	Higher
Build system	External	Built-in
Error handling	Manual	Structured
Compile-time	Limited	Powerful

22. Zig vs Rust

Feature	Zig	Rust
Complexity	Low	High
Safety model	Manual	Ownership
Learning curve	Easier	Harder
Control	High	Medium

23. When to Use Zig

Use Zig for:

OS development
Game engines
Embedded systems
Custom databases
High-performance tools

24. When NOT to Use Zig

Avoid if:

You need large ecosystem
You want rapid prototyping
You prefer high-level abstractions

25. Real-World Use Cases

Zig is used in:

Game development
Compilers
CLI tools
Replacing C in systems

26. Roadmap to Master Zig

If you're serious:

Step 1: Basics

Syntax
Types
Control flow

Step 2: Core Systems Concepts

Memory management
Pointers
Allocators

Step 3: Advanced Zig

comptime
Error handling
Build system

Step 4: Real Projects

File parser
HTTP server
Database engine (perfect for you)

27. Final Thoughts

Zig is not trying to replace everything.

👉 It’s trying to fix what’s broken in C
👉 Without adding unnecessary complexity

Core Philosophy:

"No hidden control flow. No hidden memory allocations. No surprises."

If you're a C programmer building systems (like databases):

👉 Zig is one of the best next steps.

Mastering B-Trees and B+Trees in C: A Complete Guide from Scratch

Farhad Rahimi Klie — Wed, 01 Apr 2026 05:33:06 +0000

When it comes to efficient data storage and retrieval, B-Trees and B+Trees are the backbone of databases, file systems, and indexing engines. In this article, we will explore these tree structures in full detail, including all functionalities, C implementation, and practical usage. No shortcuts, no skipped steps—everything explained from the ground up.

📌 What is a B-Tree?

A B-Tree is a self-balancing search tree in which nodes can have multiple keys and children. It maintains sorted data and allows logarithmic time search, insertion, and deletion.

Key properties of a B-Tree of minimum degree T:

Every node contains at most 2*T - 1 keys.
Every non-leaf node has at most 2*T children.
Every node (except root) has at least T - 1 keys.
All leaves appear at the same level.
Keys in a node are always sorted in ascending order.

B-Trees are widely used in databases like MySQL, PostgreSQL, and filesystems like NTFS and FAT.

📌 What is a B+Tree?

A B+Tree is an enhanced variant of a B-Tree. The main differences are:

Internal nodes store only keys, not actual data (pointers to children only).
Leaf nodes contain all data and are linked as a linked list for sequential access.
Search is faster for range queries because leaves are linked.

Key properties:

Maintains sorted order of keys.
Efficient for both point lookups and range queries.
Widely used in database indexing and key-value storage systems.

🛠️ B-Tree Implementation in C

Here’s a step-by-step C implementation of a B-Tree with all functionalities.

1️⃣ Node Structure

#include <stdio.h>
#include <stdlib.h>

#define T 2  // Minimum degree

typedef struct BTreeNode {
    int keys[2*T - 1];            // Max keys = 2*T - 1
    struct BTreeNode *children[2*T]; // Max children = 2*T
    int n;                        // Number of keys
    int leaf;                     // 1 if leaf, 0 otherwise
} BTreeNode;

2️⃣ Creating a Node

BTreeNode* createNode(int leaf) {
    BTreeNode* node = (BTreeNode*)malloc(sizeof(BTreeNode));
    node->leaf = leaf;
    node->n = 0;
    for(int i = 0; i < 2*T; i++)
        node->children[i] = NULL;
    return node;
}

3️⃣ Traversal (In-Order)

void traverse(BTreeNode* root) {
    if (root != NULL) {
        for (int i = 0; i < root->n; i++) {
            if (!root->leaf)
                traverse(root->children[i]);
            printf("%d ", root->keys[i]);
        }
        if (!root->leaf)
            traverse(root->children[root->n]);
    }
}

4️⃣ Searching for a Key

BTreeNode* search(BTreeNode* root, int key) {
    int i = 0;
    while (i < root->n && key > root->keys[i])
        i++;

    if (i < root->n && key == root->keys[i])
        return root;

    if (root->leaf)
        return NULL;

    return search(root->children[i], key);
}

5️⃣ Insertion

Step 1: Split a full child node

void splitChild(BTreeNode* parent, int i, BTreeNode* fullChild) {
    BTreeNode* newChild = createNode(fullChild->leaf);
    newChild->n = T - 1;

    // Copy last T-1 keys to newChild
    for (int j = 0; j < T-1; j++)
        newChild->keys[j] = fullChild->keys[j + T];

    // Copy child pointers if not leaf
    if (!fullChild->leaf)
        for (int j = 0; j < T; j++)
            newChild->children[j] = fullChild->children[j + T];

    fullChild->n = T - 1;

    // Shift parent's children
    for (int j = parent->n; j >= i+1; j--)
        parent->children[j+1] = parent->children[j];

    parent->children[i+1] = newChild;

    // Shift parent's keys
    for (int j = parent->n-1; j >= i; j--)
        parent->keys[j+1] = parent->keys[j];

    parent->keys[i] = fullChild->keys[T-1];
    parent->n++;
}

Step 2: Insert non-full

void insertNonFull(BTreeNode* node, int key) {
    int i = node->n - 1;

    if (node->leaf) {
        while (i >= 0 && node->keys[i] > key) {
            node->keys[i+1] = node->keys[i];
            i--;
        }
        node->keys[i+1] = key;
        node->n++;
    } else {
        while (i >= 0 && node->keys[i] > key)
            i--;

        if (node->children[i+1]->n == 2*T - 1) {
            splitChild(node, i+1, node->children[i+1]);
            if (key > node->keys[i+1])
                i++;
        }
        insertNonFull(node->children[i+1], key);
    }
}

Step 3: Insert wrapper

BTreeNode* insert(BTreeNode* root, int key) {
    if (root->n == 2*T - 1) {
        BTreeNode* newRoot = createNode(0);
        newRoot->children[0] = root;
        splitChild(newRoot, 0, root);
        insertNonFull(newRoot, key);
        return newRoot;
    } else {
        insertNonFull(root, key);
        return root;
    }
}

6️⃣ B+Tree Differences

To implement a B+Tree in C:

Internal nodes store only keys, not actual data.
Leaf nodes store actual data and point to the next leaf.
Traversal of leaves allows fast sequential access.

Leaf Node Structure Example:

typedef struct BPlusNode {
    int keys[2*T - 1];
    int data[2*T - 1];      // store actual values
    struct BPlusNode *children[2*T];
    struct BPlusNode *next; // link to next leaf
    int n;
    int leaf;
} BPlusNode;

The insertion, split, and search logic are similar, but all data moves to leaves, and internal nodes serve only as guides.

⚡ Practical Applications

Database Indexing: MySQL, PostgreSQL, Oracle.
File Systems: NTFS, FAT, and ext4.
Key-Value Stores: RocksDB, LevelDB.
Range Queries: B+Trees are preferred for fast sequential access.

🔑 Key Takeaways

B-Trees: Balanced multi-way search trees; internal and leaf nodes store data.
B+Trees: Leaf-linked trees; all data stored in leaves; ideal for sequential access.
Time Complexity: Search, Insert, Delete = O(log n).
C Implementation: Stepwise insertion, split, search, and traversal explained.
Real-World Impact: Foundation of modern database and filesystem performance.

💻 Next Steps

Implement deletion in B-Trees and B+Trees.
Add range query support for B+Trees.
Optimize memory usage for large-scale datasets.

With this, you now have a complete understanding and code reference for B-Trees and B+Trees in C. Whether you are building a database, file system, or an indexing engine, this knowledge is foundational.

Dennis Ritchie: The Architect Behind C and UNIX

Farhad Rahimi Klie — Tue, 31 Mar 2026 03:23:17 +0000

Introduction

Modern computing runs on layers of abstraction—but at the foundation of those layers lies a language and a philosophy that shaped everything above it.

That foundation was built by Dennis Ritchie.

If you have ever written C, C++, Java, or even worked with operating systems like Linux or macOS, you are indirectly building on Ritchie’s work. He didn’t just create tools—he defined how software interfaces with hardware in a practical, portable, and efficient way.

Early Life and Background

Birth and Education

Dennis Ritchie was born on September 9, 1941, in Bronxville.

He grew up in an intellectually stimulating environment. His father, Alistair Ritchie, was a Bell Labs scientist who worked on early switching systems—an influence that subtly introduced Dennis to the world of computing.

Ritchie later attended Harvard University, where he earned degrees in:

Physics (Bachelor’s)
Applied Mathematics (Ph.D.)

Although his formal education wasn’t strictly in computer science, his mathematical training gave him a strong foundation in logical thinking and system design.

Career Journey

Bell Labs: Where It All Began

Ritchie joined Bell Labs in the late 1960s—a place that would become the epicenter of some of the most important innovations in computing history.

At Bell Labs, he collaborated with legendary engineers like Ken Thompson.

The UNIX Project

Initially, Ritchie worked on the Multics project, a complex operating system that ultimately failed to meet expectations. However, this failure became a turning point.

Ken Thompson began developing a simpler operating system, which would later become UNIX. Ritchie joined him, and together they transformed it into something revolutionary.

Turning Point: From Assembly to C

Early versions of UNIX were written in assembly language, making them:

Hard to maintain
Difficult to port across machines

Ritchie recognized a critical problem: software needed a higher-level language that was still close to hardware.

This insight led to the creation of the C programming language.

Major Contributions

1. The C Programming Language

Ritchie’s most influential contribution is the C programming language.

Why C Was Revolutionary

Before C:

High-level languages were inefficient for system programming
Assembly language was powerful but not portable

C introduced a balance:

Low-level control (pointers, memory access)
High-level structure (functions, control flow)

Key Features

Direct memory manipulation via pointers
Lightweight runtime
Portable compilation across architectures
Structured programming constructs

Real-World Impact

C became:

The foundation of modern operating systems
The base for languages like C++, Java, and C#
The backbone of embedded systems and performance-critical software

2. UNIX Operating System

Ritchie co-developed the UNIX alongside Ken Thompson.

What Made UNIX Different

UNIX introduced several foundational ideas:

Everything is treated as a file
Small, composable tools
Strong use of text streams
Process-based multitasking

Rewriting UNIX in C

One of Ritchie’s most important technical decisions was rewriting UNIX in C instead of assembly.

This made UNIX:

Portable across hardware platforms
Easier to maintain and extend
Widely adoptable in academia and industry

This single decision changed how operating systems are built forever.

Famous Works / Projects

The C Programming Language (Book)

Ritchie co-authored The C Programming Language with Brian Kernighan.

Often referred to as “K&R C,” this book:

Defined the standard for C syntax and usage
Provided practical examples
Became one of the most influential programming books ever

UNIX System

The UNIX ecosystem led to:

BSD (Berkeley Software Distribution)
Linux (inspired by UNIX design)
macOS (built on UNIX-based Darwin kernel)

Technical highlights:

Hierarchical file system
Shell scripting environment
Inter-process communication via pipes

Impact on the Tech Industry

Foundation of Modern Programming

Ritchie’s work fundamentally changed software engineering:

C became the “portable assembly language”
UNIX defined OS design patterns
Developers gained tools to build scalable systems

Influence on Modern Technologies

His influence is everywhere:

Linux kernel (written in C)
Embedded systems (IoT devices)
Compilers and interpreters
Networking infrastructure

Even modern languages inherit C’s syntax:

if (condition) {
    // do something
}

This structure appears in:

Java
JavaScript
C++
Go

Philosophy and Thinking

Ritchie’s philosophy was grounded in simplicity and practicality.

Core Ideas

Build tools that do one thing well
Favor clarity over complexity
Stay close to the hardware when necessary

Notable Quote

“UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.”

This reflects his belief that simplicity is powerful—but not always easy to design.

Awards and Recognition

Dennis Ritchie received numerous prestigious honors:

Turing Award (1983) – with Ken Thompson
National Medal of Technology (1999) – awarded by U.S. President Bill Clinton
Japan Prize (2011)

These awards recognized contributions that shaped the entire computing landscape.

Legacy

Lessons for Developers

Ritchie’s work teaches:

Simplicity scales better than complexity
Abstractions should not hide reality completely
Performance and control matter

Enduring Relevance

His contributions remain critical:

C is still widely used in systems programming
UNIX principles define modern OS architecture
Software tools still follow his design philosophy

Nearly every modern system—directly or indirectly—runs on ideas Ritchie helped create.

Conclusion

Dennis Ritchie didn’t chase trends or build flashy products. Instead, he focused on solving fundamental problems in computing.

The result was transformative:

A language that bridges hardware and software
An operating system that defined modern computing

For developers, his story is a reminder:

The most impactful work isn’t always visible to users—but it becomes the foundation everything else depends on.

Write clean code. Understand the machine. Build systems that last.