DEV Community: zenoguy

The GPU Delusion: Why AI Is Getting Lazy

zenoguy — Sun, 22 Feb 2026 15:41:10 +0000

Everyone thinks AI progress is just a bigger GPU every year.

More VRAM. More cores. More watts. More "just scale it."

NVIDIA drops a new card and the entire ecosystem nods in reverence like it's a firmware update from God.

And listen — NVIDIA isn't going anywhere.

It's the cockroach of compute. Gaming winter? It survives. Crypto collapse? It pivots. AI boom? It dominates. Data center wars? It adapts.

You don't bet against NVIDIA.

But here's the thing:

The ecosystem's heavy reliance on giant GPUs might not survive unchanged.

And that's not anti-GPU. It's anti-laziness.

Abundance Makes Systems Lazy

We've seen this before, and the pattern is always the same.

Android spent a decade solving software problems by adding RAM. Apps bloated. Frameworks layered abstraction on abstraction. Memory usage exploded. Performance didn't collapse — because hardware kept increasing, so nobody cared. By 2018, a simple messaging app was consuming north of 500MB of RAM. Nobody optimized. Nobody had to.

AI is doing the same thing right now, just at a grander scale and with better PR.

Instead of asking "how do we make this smarter?", the industry asks "how many GPUs can we throw at it?" GPT-4 reportedly ran on tens of thousands of A100s. The answer to every benchmark that underperformed was another rack of compute. That works — until the economics catch up with the ambition.

The Scaling Mirage

Right now, scaling laws still hold. More parameters, more tokens, more compute, more GPUs — the curve bends upward and everyone cheers.

But here's what the benchmarks don't show: a single training run for a frontier model now costs north of $100 million. Microsoft signed a $10 billion deal with OpenAI and the models still hallucinate basic facts. The marginal return on each additional GPU is shrinking, even if the absolute numbers keep climbing. Power grids are straining — Virginia data center demand alone has triggered capacity warnings from Dominion Energy. Cooling is becoming a geopolitical problem. The energy cost per token is starting to show up in earnings calls.

Abundance isn't infinite. It's subsidized by venture capital and electricity infrastructure that was never designed for this. And subsidies expire.

GPUs Won by Convenience, Not Destiny

This is the part nobody wants to say out loud.

GPUs were the right answer for the last decade not because they were architecturally superior for AI — but because they already existed. CUDA already existed. Matrix multiplications happened to map reasonably well onto graphics pipelines. The ecosystem matured around them through sheer momentum, not design.

TPUs told a different story early on. Compiler-first thinking. Dataflow architecture. Hardware-software co-design from the ground up. Google's internal benchmarks showed TPUs delivering 15-30x better performance per watt on inference workloads compared to GPUs as far back as 2017. That paper sat quietly in the industry for years while everyone kept buying A100s.

Specialization matters. It always has. The GPU won the last era by accident of timing. That doesn't make it the permanent answer.

CPUs Aren't Dead. They're Mutating.

Here's the thing nobody wants to admit — CPUs didn't lose the AI race. They never entered it. The industry declared them obsolete before the competition started, because CUDA existed and inertia is powerful and nobody wanted to rewrite the stack.

But quietly, without a press release, CPUs mutated.

AVX-512. AMX matrix units. Sapphire Rapids shipping with dedicated AI acceleration baked directly onto the die. AWS Graviton running serious inference workloads at a fraction of the energy bill. ARM servers going from punchline to legitimate infrastructure in five years.

That's not a dead architecture. That's an architecture that got told to sit in the corner and used the time to do pushups.

The more interesting shift is structural. The GPU model assumes centralization — one massive chip doing everything, all memory local, all compute colocated. CPUs evolved toward something different. Disaggregated memory. Shared compute fabrics. Many modest nodes cooperating across a network instead of one behemoth doing it alone.

That changes what good algorithms look like. An algorithm written to saturate a single H100 is a liability the moment compute gets distributed. An algorithm written for coordination across modest nodes — that ages differently.

CPUs aren't coming back to dominate training. That ship sailed.

But inference is a different question. And inference is where AI actually lives, at scale, in production, in the real economy.

That's where the CPU's mutation starts mattering. And most people aren't watching it.

The Android Moment Nobody Is Talking About

Here's the concrete example that should make you uncomfortable if you're deep in the GPU monoculture.

In 2012, Android was bloated, slow, and RAM-hungry. Then the Moto G launched at $179 with modest specs, sold 10 million units in a year, and forced the entire Android ecosystem to actually optimize its software stack. Constraints created by a cheaper, lower-power device did more for Android performance than three generations of premium hardware had.

AI hasn't had its Moto G moment yet. But it's coming. It might look like edge inference on devices with 4GB of RAM. It might look like on-device LLMs that have to run without a data center behind them. It might look like a jurisdiction that bans cloud AI processing and forces local computation. Whatever the trigger, the optimization pressure will arrive — and the systems built entirely around abundance will not be ready for it.

Performance Smart vs. Performance Big

There is a real difference between performance because you have more, and performance because you waste less.

When compute was constrained in the early days of deep learning, researchers were forced to be clever. Dropout was born from resource scarcity. Batch normalization emerged from the need to train faster with less. Attention mechanisms were partly an efficiency innovation before they became the architecture that ate the world. Scarcity made people think. The researchers working under those constraints were doing the harder intellectual work.

Right now, the dominant research strategy is: scale it and see what happens. That's not a criticism of the researchers — it's a rational response to the incentives abundance creates. But it means whole categories of algorithmic innovation are being skipped because brute force is cheaper than cleverness, for now.

When compute is constrained, allocation matters. Early stopping matters. Uncertainty modeling matters. Every forward pass has to justify itself. That's when systems sweat — and sweating is when you find out what the architecture is actually made of.

The Real Future Question

The future of AI might not be decided by who owns the biggest GPU cluster. It might be decided by who extracts the most intelligence per joule. Per watt. Per millisecond. Per dollar of inference cost.

If hardware scaling slows — even slightly — algorithms that depend purely on brute force will plateau hard. Algorithms that exploit structure, that are hardware-aware by design, that treat energy as a first-class constraint — those will compound. The efficiency gap will start to look like an intelligence gap, because in deployment terms, it is one.

This Isn't Anti-GPU

NVIDIA will survive. GPUs will evolve. AI will still run on them for a long time.

This is not "GPUs die." This is: monoculture reliance creates fragility. If everything depends on scaling compute, then everything depends on infinite abundance — infinite cheap electricity, infinite cooling capacity, infinite capital willing to fund $100M training runs with negative unit economics.

Infinite abundance has historically been a bad bet. The companies that thrived through the PC transition weren't the ones with the most hardware. They were the ones that understood what happened when the hardware became ordinary.

The Real Arms Race

It's not a GPU arms race. It's a laziness arms race — and right now we're winning by being louder and bigger.

The next decade will likely reward efficiency, architectural structure, allocation intelligence, and hardware-aware design. Not raw scaling. The researchers and companies building systems that work under constraint — that sweat — are doing the work that will matter when the subsidy ends.

And honestly, I'm more interested in building systems that sweat than systems that just scale. Because sweating means you understand the problem. Scaling just means you can afford to avoid understanding it, for now.

Here are some papers worth reading :

[1] Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., ... & Amodei, D. (2020). Scaling Laws for Neural Language Models. arXiv:2001.08361. https://arxiv.org/abs/2001.08361
[2] Hoffmann, J., Borgeaud, S., Mensch, A., Buchatskaya, E., Cai, T., Rutherford, E., ... & Sifre, L. (2022). Training Compute-Optimal Large Language Models. arXiv:2203.15556. https://arxiv.org/abs/2203.15556
[3] Jouppi, N. P., Young, C., Patil, N., Patterson, D., Agrawal, G., Bajwa, R., ... & Yoon, D. H. (2017). In-Datacenter Performance Analysis of a Tensor Processing Unit. arXiv:1704.04760. https://arxiv.org/abs/1704.04760
[4] Hernandez, D., & Brown, T. B. (2020). Measuring the Algorithmic Efficiency of Neural Networks. OpenAI. https://cdn.openai.com/papers/ai_and_efficiency.pdf
[5] Shen, H., Chang, H., Dong, B., Luo, Y., & Meng, H. (2023). Efficient LLM Inference on CPUs. NeurIPS 2023. arXiv:2311.00502. https://arxiv.org/abs/2311.00502

When Time Became a Variable — Notes From My Journey With Numba ⚡

zenoguy — Wed, 24 Dec 2025 22:30:04 +0000

I wasn’t chasing performance at first.

I was deep inside some heavy computation — image processing, remote sensing, NumPy-heavy workflows — and things were taking too long.

While everyone’s sleeping, I’m out here crunching heat maps and chasing anomalies at 3 AM on christmas. Santa didn’t bring gifts this year — he brought publication-worthy datas. 🎅🔥

That’s when I stumbled upon Numba.

What began as a normal experimentation loop slowly turned into a waiting game. Iterations stretched. Feedback slowed curiosity down. And Numba didn’t enter my workflow as a “speed hack” — it entered as a way to bring thinking and computation back into sync.

And that changed how I work with performance entirely.

🧠 Why Numba Feels Different To Use

NumPy is already powerful, but some workloads naturally gravitate toward loops:

pixel / cell-level transformations
iterative grid passes
rolling & stencil-style operations
custom kernels that don’t exist in libraries

These are mathematically honest — but painfully slow in Python.

Numba compiles those functions to optimized machine code through LLVM (via @njit), which means:

Python syntax stays
compiled execution takes over
the bottleneck disappears

To make it happy, I had to:

keep data shapes predictable
avoid Python objects in hot paths
think about memory as something physical

That discipline didn’t just make things faster.

It made the code clearer.

⚡ What The Numbers Look Like (From Numba Benchmarks)

From Numba’s documentation and example workloads, parallel compilation can deliver dramatic CPU-scale gains:

Variant	Time	Notes
NumPy implementation	~5.8s	Interpreter overhead + limited parallelism
`@njit` single-threaded	~700ms	Big win already
`@njit(parallel=True)`	~112ms	Multithreaded + vectorized

That’s ~5× faster than NumPy, and significantly faster than non-parallel JIT on CPU-bound loops.

But I wanted to see what this looked like in my own environment.

So I benchmarked it.

🧪 My Local Benchmark (20,000,000-element loop)

Same logic. Same data. Three execution models:

Variant	Median Runtime	Min Runtime	Speedup vs Python
Python + NumPy loop (GIL-bound)	2.5418 s	2.5327 s	1×
Numba (`@njit`, single-threaded)	0.0150 s	0.0147 s	~170×
Numba Parallel (`@njit(parallel=True)`)	0.0057 s	0.0054 s	~445×

I stared at that table for a second and just laughed — the difference is wild.

The pattern was impossible to ignore:

Python loop = fine for logic, terrible for math
Numba JIT = removes interpreter overhead
Parallel Numba = unleashes full CPU cores

And the biggest effect wasn’t just speed.

It was shortened feedback cycles.

🧵 Why Numba Beats Normal Python For CPU Workloads

Pure Python is limited by the GIL.

Even if you create threads, only one runs Python bytecode at a time. Multiprocessing helps, but adds IPC + serialization overhead.

Inside a compiled Numba function:

the GIL is released
operations run as native machine code
loops scale across CPU cores (when safe to parallelize)

Conceptually:

Approach	Threads	Behavior
Pure Python loop	🚫 GIL-bound	Slow
NumPy ufuncs	✅ Multithreaded internally	Fast enough
`@njit`	❗ Single-thread machine code	Much faster
`@njit(parallel=True)`	✅ Multithreaded + SIMD	Fastest

When your workload lives inside numeric loops, parallel=True feels like adding oxygen.

🧩 “Interactive” Comparison Block

🔍 Before: Pure Python Loop

Slow. Interpreter overhead. GIL-bound.

Best used for logic, not computation.

⚙️ After: Numba JIT-Compiled Loop

compiled via LLVM
CPU-native execution
predictable performance

Feels like Python, behaves like C.

🚀 Parallel Numba (prange + parallel=True)

spreads work across CPU cores
releases the GIL inside hot loops
ideal for pixel / grid workloads

Where Numba truly shines on CPUs.

🎁 Underrated Numba Features I Learned To Appreciate

cache=True
Reuse compiled code across runs.

nopython=True
Forces discipline. Reveals hidden Python objects.

parallel=True + prange
Turns heavy loops into multithreaded kernels.

fastmath=True
Lets the compiler vectorize aggressively (when numerics allow).

But the biggest gift wasn’t raw performance.

It was momentum.

Research cycles shifted from:

write → run → wait → context-switch

into:

write → run → iterate

And curiosity stayed in motion.

⚖️ Real-World Caveats That Matter

Numba isn’t a silver bullet.

first call includes compile warm-up
debugging inside JIT code can sting
sometimes NumPy is already optimal
chaotic control-flow doesn’t JIT well

It works best when:

logic is numeric
loops are intentional
computation is meaningful

It isn’t glitter.

It’s a performance contract.

🧭 What Numba Changed In How I Write Code

It nudged me to:

separate meaningful loops from accidental ones
design transformations with purpose
treat performance as part of expression

Somewhere between algorithms and hardware, Numba didn’t just make my code faster.

It made exploration lighter.

⚡

I Saw an Instagram Reel Last Night. Now I Built a Bionic Reading Extension.

zenoguy — Sun, 21 Dec 2025 17:24:17 +0000

This whole thing started at 2am, doom-scrolling Instagram like a responsible adult.

Some reel pops up explaining “bionic reading” — bolding the first few letters of words to help your brain lock onto text faster.
Apparently it helps with focus, speed, and fatigue. Neurodivergent friendly. Science-adjacent. Looked cool.

My first thought wasn’t

“Wow, I should download that.”

It was

“Yeah… I can build that.”

So I closed Instagram, opened VS Code, and accidentally built BoldFlow.

What Even Is Bionic Reading?

If you haven’t seen it yet:

Only the first part of each word is bolded
Your brain auto-completes the rest
Less eye travel, less fatigue
You don’t read every letter — you recognize patterns

Example:

Reading becomes faster with less effort

Simple idea.
Shockingly effective.

Also… most existing tools kinda suck.

The Problem With Existing Bionic Readers

Before writing a single line of code, I tried a few extensions.

Here’s what I found:

Works on Wikipedia ✔️
Breaks on Medium ❌
Needs refresh every toggle ❌
Dies on SPAs ❌
Breaks code blocks ❌
Randomly bolds stuff it shouldn’t ❌

Basically:

Cool demo. Terrible daily driver.

So I Built BoldFlow

Not as a gimmick.
Not as a CSS hack.
But as a proper DOM-aware, SPA-safe, state-synced extension.

BoldFlow:

Works on real websites, not just static pages
Supports SPAs (Medium, Dev.to, GitHub Docs, ChatGPT, etc.)
Applies bionic reading without page refresh
Syncs popup toggle + keyboard shortcut + tabs
Doesn’t touch code blocks, editors, inputs, or scripts
Reverts cleanly when turned off

Most importantly:
It feels invisible when it’s on.
Which is exactly what a reading tool should do.

How It Actually Works (The Interesting Part)

I’ll skip the “here’s a regex” nonsense and explain the parts that actually matter.

1. Tokenization (Words Aren’t Just `\w+`)

The engine doesn’t blindly bold text.

Each text node is tokenized into:

words
whitespace
punctuation

This lets BoldFlow:

preserve spacing perfectly
avoid breaking sentences
support accented characters and Unicode text

Nothing gets reflowed. Nothing gets corrupted.

2. The Bionic Engine

For each word:

boldCount = ceil(word.length * intensity)

So:

“reading” → reading
“understanding” → understanding

Intensity is configurable, deterministic, and predictable.

No randomness. No magic numbers.

3. DOM Walker (Where Most Extensions Fail)

Instead of rewriting chunks of HTML, BoldFlow uses a TreeWalker:

Walks only TEXT_NODEs
Skips:
- SCRIPT
- STYLE
- CODE
- PRE
- inputs
- contenteditable regions
Wraps processed words in minimal spans

This preserves:

event listeners
framework bindings
page structure
selection behavior

No React tantrums. No editor breakage.

4. SPA Support via MutationObserver

Modern websites don’t reload.
They mutate.

BoldFlow watches for new nodes being added, and when that happens:

schedules processing
debounces aggressively
runs during idle time

Meaning:

no jank
no infinite loops
no performance hits

Infinite scroll?
Route changes?
Lazy-loaded articles?

Handled.

5. State Is Global, Not Tab-Local

Popup toggle.
Keyboard shortcut (Ctrl + Shift + Y).
Multiple tabs.

All synced via chrome.storage.sync.

One source of truth.
Every tab reacts instantly.
No refresh needed.

This is the part that finally made it feel real.

Why I’m Keeping It Minimal

I deliberately did not add:

dark mode gimmicks
flashy animations
AI buzzwords
“reader mode” clones

BoldFlow does one thing:
make reading easier without getting in your way.

If a feature doesn’t improve focus, it doesn’t ship.

What I Learned (The Real Takeaways)

Text manipulation is harder than it looks
DOM safety > visual tricks
MutationObserver without debouncing is a footgun
Storage-first state management saves your sanity
Accessibility tools should be invisible, not flashy

And also:

Instagram reels are dangerous.
They lead to projects.

Final Thoughts

BoldFlow wasn’t planned.
It wasn’t scoped.
It wasn’t even supposed to exist.

It started as

“Huh, that’s interesting.”

And turned into a fully-engineered Chrome extension that I now actually use.

If you read a lot, try bionic reading.
If you hate half-working tools, try building your own.

Sometimes the best projects start with
a reel, a thought, and way too much curiosity.

Github : https://github.com/Zenoguy/bionic-reader
P.S. I will apply for listing in webstore soon and it edit the link here :D

Why I Ditched Terminal UIs for Recruiters

zenoguy — Sat, 20 Dec 2025 21:17:53 +0000

Why I Ditched Terminal UIs for Recruiters

I built a terminal-style portfolio.

Black screen. Commands. ASCII vibes.
It felt clever. It felt personal. It felt very me.

And almost everyone said the same thing:

“This is cool… but recruiters won’t get it.”

They were right.

The terminal UI problem 🧠

Terminal portfolios are fun for developers.
They signal:

You’re technical
You’re confident
You like bending conventions

But recruiters don’t explore. They skim.

They want:

Who are you?
What do you build?
Can I understand this in 10 seconds?

A blinking cursor asking them to type help already lost half the room.

The uncomfortable realization ⚠️

My terminal UI wasn’t failing because it was bad.

It was failing because it required participation.

Recruiters don’t want to interact.
They want to recognize.

That’s when it clicked:
A portfolio isn’t a playground. It’s a signal amplifier.

The pivot 🎯

I rebuilt my portfolio as:

UI-first
Motion-driven
Immediately readable

Big typography.
Clear sections.
Subtle animation instead of clever commands.

Same personality. Different delivery.

The irony?
More people noticed my work after I made it simpler.

What I learned ✅

Cool ideas still need clear entry points
A portfolio is not for you, it’s for your audience
You can still be creative without being cryptic

I didn’t kill the terminal UI idea.
I just stopped forcing it on people who didn’t ask for it.

Curious how it turned out?

I rebuilt my portfolio to be UI-first, motion-heavy, and recruiter-readable
without killing the personality.

If you want to see what that pivot looks like in practice:

👉 https://zeno-guy-portfolio.vercel.app/

Fair warning:
I still overengineered it. Just more responsibly this time.

My First Hackathon – 24 Hours, 1 Fintech App, 0 Sleep (Spoiler: We won a Special Mention too 🏆)

zenoguy — Wed, 23 Jul 2025 00:16:51 +0000

So yeah — I finally did it.

Attended my first ever hackathon. Not virtually, not as a ghost registrant. I actually showed up, with real humans, real deadlines, and real panic. It was Business Hackathon 2.0, and we had 24 hours to build something, pitch it, maybe cry a little, and call it innovation.

We built a fintech app called SpendSight — more on that in a sec — and ended up winning a Special Mention Award. Which, let me tell you, felt like getting the "most likely to accidentally build a startup" badge.

But let's rewind.

📅 Day 1 — Chaos Enters the Chat

The idea was simple: Take those horrendous PDF bank statements, feed them into our app, and magically get back clean, categorized, human-readable insights in csv — without ever touching Excel.
Because to be honest, those bank statements pdfs are generated by banks for banks and not for us average joe

We had:

No backend yet
A half-baked frontend skeleton
2 people who definitely Googled "how to parse PDFs in Python" at some point

So naturally we said:

"Let's go regex → BERT → LLM fallback, just for fun."

Because sleep is for cowards.

💡 Enter SpendSight

Here's what we shipped:

📄 Upload bank statements (yes, A mock one for now)
🧠 Parse them using Regex first, BERT if that fails, and DeepSeek R1 if we really needed backup
📊 Output a clean, searchable table
📁 Export as CSV
🏷️ Auto-categorize expenses (food, rent, subscriptions, etc.)
🚀 React + TypeScript frontend, Python + Supabase backend
💬 Bonus - Chat with your statements using AI At 3 AM, it actually worked. And by "worked" I mean: didn't crash on first upload. A victory.

Pro tip: If you finish coding at 3 AM at a hackathon, all the sleeping mats are already claimed by the smart people who went to bed at midnight. So what do you do? You clump six tables together under the AC, declare it "premium real estate," and sleep like kings. Was it comfortable? Absolutely not. Did we feel like hackathon legends? 100%.

🛠️ Bonus Side Quest: AdHacks

At midnight, we were invited to this mini side event called AdHacks. They said "Make a compelling ad for your product."

We said, "It's 12 am but sure, what's the worst that could happen?"

So we scripted, shot (with Gemini Veo), and pitched an ad — half asleep, full throttle. Weirdly, it turned out great. Probably because none of us had the energy to overthink. - Finished at 2:30 am , ofc didn't win the mini event.

(Fun fact: Our "creative brainstorming session" happened while one teammate was brushing his teeth and another was doing skincare. Peak innovation right there.)

🎤 Final Pitch – Please Clap

The next day, running on cold chai and adrenaline, we gave our final pitch:

🖥️ Live website demo
📑 Pitch deck with actual numbers [yeah, we did the RESEARCH]
💬 Business use case and monetisation model

Was it perfect? Nah. Was it scrappy, ambitious, and kinda awesome? Absolutely.

(Also, shoutout to whoever invented dry shampoo — the real MVP of hackathons. And to the person who brought deodorant. You know who you are[ME].)

The judges saw potential. We walked out with a Special Mention Award and one hell of a story.

🧠 What I Learned

You can do a lot in 24 hours if no one sleeps
Ideas > perfection
PDFs are evil. Regex is therapy
Teamwork is everything
Always keep a pitch deck AND a backup charger
Six tables + one AC = acceptable sleeping arrangements (your back will disagree)
3 AM is when the best (worst?) coding decisions happen
Cold chai tastes like liquid motivation when you haven't slept

📍 Try SpendSight (Frontend MVP)

🔗 Live Demo: https://tinyurl.com/spendsight

🧠 GitHub: Zenoguy/SpendSight-

🫡 TL;DR

First hackathon = scary. Building something in 24 hours = madness. Winning a Special Mention = chef's kiss.

What was your first hackathon experience like? Drop a comment below — I'd love to hear your stories! 👇

I Made a Java Chat App in One Night (Because I Had No Projects)

zenoguy — Thu, 26 Jun 2025 14:08:24 +0000

So here’s the thing: I wanted to apply for a Java internship.

But I had a problem.

👉 I had literally zero Java projects.

So like any rational dev in a crunch, I built a full 1-on-1 chat app in Java — in a single night — using:

Raw sockets 🧵
MySQL via JDBC 💾
A UI built with... Swing (yes, I suffered)

💬 How It Works

It’s a basic 1-on-1 chat system:

One client sends a message
Server catches it
Stores it in MySQL
Relays it to the other client
Repeat until one of them rage quits

I tested it with two terminals pretending to be people. Worked fine.

(Wasn't weird. You’re weird.)

🧠 What Broke My Brain

Two things:

Swing UI – now I understand why no one uses it in 2025
Message storing – I had the DB, I had the connection, but somehow chat history just would not cooperate

🧪 What I’d Improve (If I Had Time or Sanity)

Add a homepage to select/chat with users
Group chat support (so it feels more like WhatsApp and less like Notepad wars)
Possibly deploy it — but lol

🧱 Tech Stack

Java
MySQL
JDBC
Java Sockets (multithreaded)
Java Swing (regrettably)

🔗 github.com/Zenoguy/ChatApp-Java

Forked from a tutorial by Code for Interview, but heavily modified — I added:

Message persistence
UI wiring
DB syncing
Tons of tweaks, logs, and near-tears

🧃 Final Thoughts

Was it a mess? Yes.

Did I learn Java networking, JDBC, and that Swing is cursed? Also yes.

Would I do it again?

Probably. But next time, with JavaFX. Or better yet... not Java.

If you're building something similar, feel free to use the repo — or just laugh at my struggle.

And if you’ve got tips for improving the UI or DB layer, drop them below 👇

So I Decided to Learn Vim… and I Kinda Get the Hype Now?

zenoguy — Wed, 18 Jun 2025 10:33:48 +0000

Alright, let me be honest right out the gate: I always thought Vim was just some arcane flex tool for terminal nerds.

You know — the kind ThePrimeagen uses at lightspeed while yelling "LET'S GO!" on stream. It looked cool. It sounded fast. But it also looked like a keyboard-induced migraine.

Still… I was curious. So I decided to see what the hype was all about.

First Impressions: What Even Is This?

Day 1 with Vim felt like:

"How do I quit?" "Why can't I type?" "Oh cool, I deleted the entire line again."

It was confusing. It was rigid. It felt like Vim was a gatekeeper, not a helper.

I legit thought,

"This is just a thing YouTubers use to feel cool."

And maybe it is — a little. But I kept going.

What Shifted for Me

Somewhere around day 3 or 4, I stopped trying to fight Vim.

I started noticing that:

The modal editing wasn't stupid — it was intentional
The weird keyboard shortcuts were actually muscle memory training
I didn't need to reach for the mouse — at all
I was slowly becoming… faster?

That's when I made a cheat sheet — because tabs, splits, buffers, visual modes, and motions were still bouncing around in my brain like uncompiled code.

My Cheat Sheet (Still Growing)

This helped me survive the learning curve.

📎 https://github.com/Zenoguy/Vim---For-Normal-PPL/blob/main/VimCheatSheet.pdf

A little example:

MODES
-----
Normal Mode     : Esc       -> Navigate & issue commands
Insert Mode     : i, a      -> Enter text
Visual Mode     : v, V      -> Select text (char/line/block)
Command-line    : :         -> Run commands like save, quit

It's a mix of:

Navigation basics
Buffer/tab/split management
Yank/paste/undo/redo rituals
My most-used search + replace tricks

Feel free to steal or remix it.

Where I'm At Now

I'm not a Vim god yet. I'm still figuring things out. I still reach for VSCode when i have some real work to get done.

But here's the thing:

I finally get why people stick with Vim.

It's about intentional motion
It's about speed you earn (not speed handed to you)
It's about building habits that scale across editors and environments

What's Next?

I want to try some cool Vim plugins. Stuff that'll make the workflow a little more modern, a little more fun.

If you've got any: 👉 Drop them in the comments.

Also, if you've just started with Vim too — let me know how your journey's going. We can swap cheat sheets and pain points.

TL;DR

I thought Vim was dumb
It is — until you start understanding it
Then it becomes surprisingly powerful
And maybe… worth the hype?

Apple Just Buffed Dev Tools

zenoguy — Mon, 16 Jun 2025 05:19:08 +0000

Hello internet.

WWDC 2025 happened.
Everyone's talking about AI this, visionOS that.
But buried under all the marketing fluff?

Apple quietly fixed a bunch of stuff that actually matters to developers.

No dramatic keynote moments. No "magical experience" speeches.
Just... useful improvements.

And honestly? I'm kinda here for it.

Xcode Got Smart (Finally)

Look, Xcode's always been that tool you love to hate.
Powerful? Yes.
Occasionally crashes and makes you question your life choices? Also yes.

But now they added AI code completion.

What's different?

Redesigned navigation experience
Better localization catalog
Voice Control support for Swift (you can literally dictate code now)
Coding Tools that work inline with your actual workflow

Not revolutionary. But the kind of polish that makes daily dev work less annoying.
Like a good Mac app should.

Linux Containers on Mac (Wait, What?)

This is the plot twist nobody saw coming.

Apple — the same company that once made Docker Desktop feel like dark magic — has released its own open-source CLI tool named container to run native Linux containers on macOS

What it actually does:

Written in Swift, optimized for Apple Silicon
Supports industry-standard OCI images — yes, your Docker images work out of the box
Spins up each container inside its own lightweight Linux VM, providing isolated networking, CPU/memory allocation, and sub‑second startup times

* Uses a custom Swift-based init system, vminitd, to boot Linux VMs securely and efficiently

The catch

Required for macOS 26 “Tahoe” (beta only); it does run on macOS 15 but with limited features — most notably no container-to-container networking ([omgubuntu.co.uk][1])
Not a Docker Desktop replacement yet — early-stage and missing some features, though native caching and integration may win people over ([linkedin.com][5])

Why it’s a bold move

Finally, Apple is saying, “Yes, backend developers on Macs exist.”
They’re not just porting solutions — they’re building them openly, optimized for Apple hardware, and leaning into developer workflows ([chamodshehanka.medium.com][6]).

The Experimental Stuff Got Better Too

If you're building AI features or AR apps:
Foundation Models framework:

Access to on-device Apple Intelligence with 3 lines of code
Works offline and protects privacy
Free AI inference (no API costs)

CoreML and RealityKit updates:

Still getting improvements but no major overhauls
Better Swift integration for ML models

App Intents:

Now supports visual intelligence
Your app can show up in visual search results

Not earth-shattering. But solid improvements if you're working in this space.

The Boring Stuff That Actually Matters

They didn't forget about CI/CD and deployment hell either.

TestFlight crash logs are more useful now
App Store Connect has proper CLI support
Xcode Cloud integration doesn't make you want to quit

Less clicking through web portals.
More automating the stuff that should be automated.

The kind of improvements you only appreciate after you've survived a Friday deployment.

That LiquidGlass Thing

Yeah, I saw it too.
The mysterious framework(yh never saw that before) with the fancy animations.

Whatever it is — UI kit, shader playground, or fever dream — we're not talking about it today.

Because honestly? eh.

Why This Actually Matters

This isn't revolutionary.
It's not going to change how we build apps overnight.

But it's evolution that makes building stuff less painful.

Apple seems to be saying:

"We know build times suck. We know Docker on Mac is weird. We know Xcode can be frustrating. Let us fix that."

And weirdly... they might have actually done it.

What I'm Curios abour

The Linux container stuff.
Because if Apple can actually replace Docker Desktop and make terminal workflows smooth, that’s a total game-changer.

Also curious about the Xcode AI features.
Will they actually help or just get in the way?

What about you?

Excited about faster build times?
Want to try the AI autocomplete?
Still waiting for Apple to fix [insert your pet peeve here]?

Drop a comment. Let's see if 2025 is actually the year Apple becomes developer-friendly.

Because that would be a plot twist I didn't see coming.

🛸 I tried Pygame (Build Space Shooters in a DAY)

zenoguy — Mon, 09 Jun 2025 14:44:34 +0000

🛸 I Made a Space Shooter in Python (And it works.. Kinda)

Hello internet.
I made a game.

Yeah. Another space shooter.
Because clearly, what the universe needed most right now… was this.
Built in Python. Using pygame.
Fueled by caffeine, chaos, and way too much Stack Overflow.

It started simple — thanks to Tech With Tim's space shooter tutorial.
Then I went full military-grade modder on it.

Because why reinvent the wheel…
when you can just slap armor on it, duct tape it to a rocket, and send it into orbit?

github : https://github.com/Zenoguy/Space_Shooters

Download ->
Windows : https://zenoguy.itch.io/space-shooters-concept-game

linux -> https://drive.google.com/file/d/1glHPw6BS_xvznkOcH-lrjffHMVsdtlQ9/view?usp=sharing

(works for Arch distros{yh I use Arch}, lemme know if its giving error on other distros)

🎞️ The Origin Story (feat. Tim)

I googled "how to make a game in Python".
Tech With Tim popped up, obviously.
I followed his space shooter guide. Learned the ropes. Got the basics working.

Then I looked at my code…
and said: "Cool. Now let's break everything and make it mine."

🧠 The Big Brain Stack

Python 3 (I'm chaotic, not primitive)
pygame (aka "Please Save Frequently")
Sprites? Mostly of Tim and made one myself B)
Music? Scavenged from the depths of royalty-free Google searches
Folders:
- assets/ — ships, lasers, vibes
- bgm/ — background music that fights back

🔫 So What Makes My Game Different?

You know how tutorials give you a good starting point?
I didn't stop there.
I duct-taped a bunch of my own mechanics to it until it turned into a legitimate game.

☠️ Kamikaze Enemies That Actually Hunt You

Yeah. These boys don't shoot lasers like regular enemies.
They just dive straight at you like they've got something to prove.
And they're smart about it.

def move(self, vel, player):
    if not self.is_diving:
        self.y += vel + 1  # Faster than regular enemies
        # Start diving when close to player
        if self.y > player.y - 200 and self.y < player.y and random.random() < 0.01:
            self.set_target(player.x + player.get_width()//2, player.y + player.get_height()//2)
    else:
        # Calculate direction to target and dive at high speed
        dx = self.target_x - (self.x + self.get_width()//2)
        dy = self.target_y - (self.y + self.get_height()//2)
        distance = (dx**2 + dy**2)**0.5
        if distance > 0:
            self.x += (dx / distance) * self.dive_speed
            self.y += (dy / distance) * self.dive_speed

That's not just enemy logic — that's targeted harassment with visual warnings.

⚠️ Visual Warning System for Kamikaze Attacks

When a kamikaze decides you're the target, it flashes red to give you a split second to panic.

def draw(self, window):
    window.blit(self.ship_img, (self.x, self.y))

    # Flashing red warning when diving
    if self.is_diving and self.warning_timer > 0:
        if self.warning_timer % 10 < 5:  # Flash every 10 frames
            warning_surface = pygame.Surface((self.get_width() + 20, self.get_height() + 20))
            warning_surface.set_alpha(100)
            warning_surface.fill(RED)
            window.blit(warning_surface, (self.x - 10, self.y - 10))

👾 Smart Enemy Spawning — Why It Matters

At first, I just spawned enemies at random x and y positions. Worked fine… until level 3 hit and suddenly six ships spawned inside each other like cursed nesting dolls. Pure chaos. Not the fun kind.

So I added minimum distance checks using math.hypot to ensure enemies never spawned too close to each other. It gave me controlled chaos — where the challenge scales, but doesn’t feel unfair. Each wave feels intentional, not random junk thrown at the screen.

This was my first time implementing spatial logic, and it was surprisingly fun — kinda like managing party invites to make sure nobody stands too close at awkward small talk range.

🎮 Full-Featured Pause Menu System

Not just "Press P and hope" — this is a proper menu with navigation and settings.

def pause_menu():
    options = [
        "RESUME",
        "NEW GAME", 
        "QUIT",
        f"SFX: {'ON' if SOUND_ENABLED else 'OFF'}",
        f"MUSIC: {'ON' if MUSIC_ENABLED else 'OFF'}"
    ]
    selected_option = 0

    # Arrow key navigation with Enter to select
    # Can toggle sound/music settings mid-game

You can navigate with arrow keys, toggle SFX and music on/off, start a new game, or rage quit. It even pauses the music and switches to pause screen music.

🔊 Dynamic Sound System That Actually Works

Every laser blast, explosion, and menu transition has its own sound.
Plus dynamic music switching between menu, game, and pause states.

def play_sfx(sound):
    if SOUND_ENABLED:
        sound.play()

def play_music(music_file, loops=-1, volume=0.7):
    if MUSIC_ENABLED:
        pygame.mixer.music.load(music_file)
        pygame.mixer.music.set_volume(volume)
        pygame.mixer.music.play(loops)

The music system remembers where you were when you paused and can resume properly. When i was trying to figure it out the music were just overlapping LOL.

🎯 Laser vs Laser Combat System

Player lasers can actually collide with enemy lasers and destroy each other.
This wasn't in the tutorial — pure custom chaos.

# Laser collision detection between player and enemy projectiles
for enemy in enemies:
    for enemy_laser in enemy.lasers[:]:
        for player_laser in player.lasers[:]:
            if enemy_laser.collision(player_laser):
                if enemy_laser in enemy.lasers:
                    enemy.lasers.remove(enemy_laser)
                if player_laser in player.lasers:
                    player.lasers.remove(player_laser)
                break

That's ✨ tactical projectile warfare ✨. Not in the tutorial. That's all me.

📊 Proper Scoring System with High Score Persistence

Regular enemies are worth 10 points, kamikaze enemies are worth 20 (because they're more dangerous).
High scores save to a file and persist between sessions.

def save_high_score(score):
    with open(HIGH_SCORE_FILE, "w") as file:
        file.write(str(score))

# In the collision detection:
self.score += 10  # Regular enemies
self.score += 20  # Kamikaze enemies

🕹️ Smooth Movement with WASD + Arrow Key Support

The movement system supports both WASD and arrow keys, with proper boundary checking.

keys = pygame.key.get_pressed()

if (keys[pygame.K_a] or keys[pygame.K_LEFT]) and player.x - player_vel > 0:
    player.x -= player_vel
if (keys[pygame.K_d] or keys[pygame.K_RIGHT]) and player.x + player_vel + player.get_width() < WIDTH:
    player.x += player_vel

No stutter. No teleporting through walls. Just smooth, responsive controls.

💥 Game Over Screen That Doesn't Suck

Game ends? You get options.
R to restart, M to return to main menu, Q to rage quit.
Shows your final score and current high score.

if lost:
    for event in pygame.event.get():
        if event.type == pygame.KEYDOWN:
            if event.key == pygame.K_r:
                stop_music()
                main()  # Restart
                return
            elif event.key == pygame.K_m:
                stop_music() 
                main_menu()  # Back to menu
                return

No more infinite nested function calls. Clean exits and restarts.

🎧 Music and Audio That Actually Cooperates

You think you understand pain? Try getting pygame.mixer to behave at 3 AM.

But I figured it out:

Main menu music
In-game music
Pause screen music
Proper music stopping/starting
SFX that can be toggled independently

# Music files loaded as paths, not objects
MAIN_MENU_MUSIC = os.path.join("bgm", "MainScreen.mp3")
PAUSE_MUSIC = os.path.join("bgm", "Loading_Screen.mp3") 
GAME_MUSIC = os.path.join("bgm", "8bit-spaceshooter.mp3")

# Sounds loaded as objects for instant playback
LASER_SOUND = pygame.mixer.Sound(os.path.join("bgm", "laser.mp3"))
EXPLOSION_SOUND = pygame.mixer.Sound(os.path.join("bgm", "explosion.mp3"))

When it works — it slaps.

💀 Man did I squash bugs

✅ Music that wouldn't stop on game over
✅ Enemies spawning inside each other like nesting dolls
✅ Kamikaze enemies spawning off-screen and becoming invisible
✅ Pause menu not actually pausing the game logic
✅ Sound effects playing even when SFX was disabled
✅ Memory leaks from not properly removing lasers
✅ Game over screen not showing final score vs high score

We debug properly around here.

🐍 Turning It Into a Real .exe

Of course I packaged it with pyinstaller.

pyinstaller --onefile --add-data "assets;assets" --add-data "bgm;bgm" main.py

Out pops main.exe in /dist/.
Ship it to your friends. Watch Windows Defender question your life choices.
(It's legitimate. Mostly.)

⚖️ Game Balance That Makes Sense

Player: 100 HP, fast shooting (20 frame cooldown)
Regular enemies: 10 HP, slow shooting (40 frame cooldown), 10 points
Kamikaze enemies: no shooting, aggressive diving, 20 points
Enemy collision damage: 10 HP
Kamikaze collision damage: 40 HP (they mean business)
Player laser damage: 10 HP per hit

The math actually works. Kamikaze enemies are high-risk, high-reward targets.

GitHub and the Great Sound File Situation

70MB of sound files don't play nice with GitHub's size limits.
Solution: I converted my .wav files to .mp3 and they were 8 times lighter now.

Now you can ask why not - .gitignore the bgm/ folder, upload to Google Drive and link it in the README like a civilized developer.

I didn't do it because this is my game. I'm the BOSS.

🎯 Mask-Based Collision — The Big Brain Move

The biggest “ah-ha” in this whole project?

Pixel-perfect collision using masks.

Most beginner games use bounding boxes (rect.colliderect()), which is fine for rectangles. But when your spaceship has curved wings and empty space? Rects lie.

Enter pygame.mask. With this, you create a bitmask from your sprite, and check actual pixel overlap:

offset_x = obj2.x - obj1.x
offset_y = obj2.y - obj1.y
collision = obj1.mask.overlap(obj2.mask, (offset_x, offset_y)) != None

It’s a little mathy. But once you get it, it feels like you’ve unlocked true hit detection. No more “I didn’t touch that!” moments — just accurate, satisfying gameplay.

This was hands-down the most powerful thing I learned in this whole project.

💡 What I Actually Learned

pygame is simple until you want it to do anything cool
Tech With Tim teaches the foundation — your chaos makes it unique
Proper asset management prevents 3 AM debugging sessions
Visual feedback (like kamikaze warnings) makes gameplay feel responsive
File I/O for high scores is easier than you think
Sound mixing is hard but worth it when it works

This Is an OOP Goldmine

This game is basically one hell of a project if you want to learn object-oriented programming.

You’ve got:

Player, Enemy, and KamikazeEnemy — each a subclass of a common Ship base
Encapsulation of behavior (movement, shooting, health, drawing)
Polymorphism in full effect (kamikaze ships override movement logic)

You’re not just writing loops — you’re designing systems. Every class has a job. You’re learning how to organize code that grows — and that’s the real skill behind game dev, web dev, or honestly any dev.

Building this gave me a genuine “ohhhh that’s what OOP is for” moment.

🛸 So Should You Make One Too?

YES.
Watch the tutorial.
Then make it yours.
Add the weird features that make sense to you.
Break things. Fix them. Break them again.

Then write about it.
Because apparently, that's what we do now.

Intro Functional Programming- 4: Real world Example

zenoguy — Fri, 06 Jun 2025 17:05:00 +0000

From WhatsApp to Your Next Project: Making Functional Programming Work in the Real World

Part 4 of 4: From Code Chaos to Mathematical Zen

We've taken quite a journey together. We started with the frustrations of Object-Oriented Programming's complexity, discovered the mathematical elegance of pure functions, explored the power of higher-order functions, and marveled at the recursive beauty of pattern matching and lazy evaluation.

But there's an elephant in the room: Real-world software isn't a math puzzle.

Users click buttons. Data gets stored in databases. APIs fail and need retry logic. Logs must be written. Even the simplest CRUD application is built on side effects—Create, Read, Update, Destroy. Things change, state mutates, and the world is inherently messy.

So how do we reconcile functional programming's mathematical purity with the need to build actual applications that work in the real world?

The answer isn't to throw out everything functional programming taught us. It's to introduce mutability and side effects in a controlled, principled way that preserves the benefits of safety, predictability, and composability.

Today, we'll see how this works in practice, using real systems that serve billions of users.

The Billion-User Proof: WhatsApp and Discord

Let's start with some mind-blowing numbers:

WhatsApp: Handles over 100 billion messages per day, built on Erlang
Discord: Serves millions of concurrent users in real-time, powered by Elixir
Financial systems: Process trillions of dollars using functional languages
Telecom infrastructure: Achieves 99.9999% uptime (about 30 seconds of downtime per year) with Erlang

These aren't toy examples or academic exercises. These are production systems handling scale that would break most traditional architectures.

So what makes functional programming work so well for these demanding applications?

The Actor Model: Functional Programming Meets the Real World

Erlang and Elixir use something called the Actor Model of concurrency. Here's how it works:

Every "actor" (or process) is lightweight and isolated
Each process has its own private state
Processes communicate only through message passing
If one process crashes, it doesn't affect others
The system can run millions of processes simultaneously

But here's the key insight: Because functional programming ensures immutability, there's no risk of data corruption from concurrent processes modifying shared data.

Example: Real-Time Chat System

# Each chat room is its own process
defmodule ChatRoom do
  use GenServer

  # Initial state - immutable data structure
  def start_link(room_name) do
    GenServer.start_link(__MODULE__, %{
      name: room_name,
      users: [],
      messages: []
    })
  end

  # Handle new user joining
  def handle_call({:join, user}, _from, state) do
    new_state = %{state | users: [user | state.users]}
    {:reply, :ok, new_state}
  end

  # Handle new message
  def handle_cast({:message, user, text}, state) do
    message = %{user: user, text: text, timestamp: DateTime.utc_now()}
    new_state = %{state | messages: [message | state.messages]}

    # Notify all users (side effect, but controlled)
    Enum.each(state.users, fn user ->
      send(user, {:new_message, message})
    end)

    {:noreply, new_state}
  end
end

Notice what's happening:

State is immutable—we create new state rather than mutating existing state
Side effects (sending messages to users) are explicit and controlled
Each chat room is isolated—if one crashes, others continue working
The system can handle thousands of chat rooms simultaneously

Controlled Mutation: The Best of Both Worlds

Functional programming doesn't reject mutable state outright—it refuses to let it run wild.

Instead of thinking "how can I mutate this value?", functional languages encourage you to think "how can I manage and isolate change so it's controlled and safe?"

Example: Website Visit Counter

Let's say we want to count page views—a classic case of shared mutable state.

In a traditional imperative language, you might use a global variable:

// Dangerous: global mutable state
let visitCount = 0;

function recordVisit() {
  visitCount++; // What if two requests hit this simultaneously?
}

In Elixir (a functional language), we use an Agent—an abstraction for managed, stateful processes:

# Safe: controlled state management
{:ok, pid} = Agent.start_link(fn -> 0 end, name: :visit_counter)

# Increment the counter
Agent.update(:visit_counter, fn count -> count + 1 end)

# Read the counter
Agent.get(:visit_counter, fn count -> count end)

Here's what makes this safer:

The counter value lives inside the Agent process
You can't touch it directly—you send it a function
That function gets applied to the state in isolation
Every update is serialized—no race conditions
Multiple processes can safely interact with the counter

This gives us mutable state under functional discipline:

Controlled access: No direct mutation
No side effects leaking out: Changes are contained
Safe concurrency: Updates are automatically serialized

The "Let It Crash" Philosophy

One of the most counterintuitive aspects of Erlang/Elixir systems is the "let it crash" philosophy.

Instead of trying to handle every possible error condition, you design your system to fail fast and recover gracefully.

Here's how it works:

When a chat room process encounters an error:

It crashes immediately (no trying to "handle" the error)
The supervisor detects the crash

# Supervisor that manages chat rooms
defmodule ChatSupervisor do
  use Supervisor

  def start_link do
    Supervisor.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  def init(:ok) do
    children = [
      # If a chat room crashes, restart it
      {ChatRoom, "general"},
      {ChatRoom, "random"},
      {ChatRoom, "tech-talk"}
    ]

    # Strategy: if one child crashes, restart just that child
    Supervisor.init(children, strategy: :one_for_one)
  end
end

The supervisor restarts just that chat room
Other chat rooms continue working normally
Users might see a brief disconnect, then everything works again

This approach makes systems incredibly resilient. Instead of one bug bringing down the entire application, errors are isolated and automatically recovered.

Bridging Pure and Practical: Multi-Paradigm Reality

Here's the truth that academic functional programming courses often skip: Real systems aren't purely functional.

Even the most functional languages provide escape hatches for the messy real world:

Haskell has the IO monad and STM (Software Transactional Memory)
Clojure runs on the JVM and interoperates seamlessly with Java
Elixir provides GenServers, Agents, and ETS for stateful operations
F# integrates naturally with the .NET ecosystem

The key insight is that functional programming gives you a default of safety with controlled escape valves when you need them.

Example: Database Operations in Elixir

defmodule UserService do
  # Pure function - easy to test and reason about
  def validate_user(user_data) do
    case user_data do
      %{email: email, age: age} when is_binary(email) and age >= 18 ->
        {:ok, user_data}
      _ ->
        {:error, "Invalid user data"}
    end
  end

  # Controlled side effect - database interaction
  def create_user(user_data) do
    with {:ok, validated_user} <- validate_user(user_data),
         {:ok, user} <- Repo.insert(%User{}, validated_user) do
      {:ok, user}
    else
      error -> error
    end
  end

  # Pure function - business logic
  def calculate_subscription_price(user, plan) do
    base_price = plan.price
    discount = if user.is_student, do: 0.5, else: 1.0
    base_price * discount
  end
end

Notice the pattern:

Pure functions handle business logic and validation
Controlled side effects manage database operations
Clear boundaries between pure and impure code
Composable design allows easy testing and modification

The Functional Programming Spectrum

Rather than thinking "functional vs. imperative," think of a spectrum:

Pure Functional Core: Business logic, calculations, transformations
Controlled State Management: Agents, GenServers, STM
System Boundaries: Database I/O, HTTP requests, file operations
Integration Layer: Interfacing with imperative systems

The magic happens when you push as much logic as possible toward the pure end of the spectrum, using controlled mechanisms for the parts that genuinely need state or side effects.

Why This Approach Wins

This hybrid approach gives you the best of both worlds:

From Functional Programming:

Predictable code: Pure functions always return the same output for the same input
Easy testing: No mocking required for pure functions
Safe concurrency: Immutability eliminates race conditions
Composability: Small functions combine into larger systems naturally

From Controlled Mutation:

Real-world compatibility: Handle databases, APIs, user interfaces
Performance optimization: Avoid unnecessary copying when appropriate
Ecosystem integration: Work with existing libraries and systems
Pragmatic solutions: Use the right tool for each specific problem

Your Next Steps

Ready to bring functional programming to your next project? Here's how to start:

Start Small

Don't rewrite your entire codebase. Begin with:

Utility functions that transform data
Business logic that doesn't require state
Data processing pipelines
Validation and formatting functions

Choose Your Language

Elixir: Excellent for web applications, real-time systems, IoT
Clojure: Perfect for data processing, web services on the JVM
F#: Great for .NET environments, financial systems
JavaScript/TypeScript: Start using functional patterns with existing tools

Apply the Principles

Even in non-functional languages, you can:

Prefer immutable data structures
Write pure functions when possible
Use higher-order functions (map, filter, reduce)
Separate pure logic from side effects

Learn the Patterns

Master these functional patterns:

Pipeline operations: Transform data through a series of functions
Error handling: Use Result/Maybe types instead of exceptions
State management: Isolate mutable state behind clean boundaries
Composition: Build complex behaviors from simple functions

The Future is Functional

We're living through a shift in how software is built. The challenges of modern development—massive scale, real-time requirements, distributed systems, concurrent users—all favor functional approaches.

Companies like WhatsApp didn't choose Erlang because it was trendy. They chose it because it could handle 50 engineers supporting 900 million users. Discord didn't pick Elixir for academic reasons—they needed a system that could handle millions of concurrent connections without breaking a sweat.

The mathematics that seemed so abstract in computer science class? It turns out to be the most practical approach for building robust, scalable systems.

From Chaos to Zen

We started this series talking about the chaos of complex object-oriented systems—the tangled webs of dependencies, the debugging nightmares, the fear of changing one thing and breaking another.

Functional programming offers a path to something different: code that's predictable, systems that scale gracefully, and the zen-like peace of knowing that your functions do exactly what they say they do, every time.

It's not about rejecting the real world. It's about bringing mathematical precision to the messy business of building software that matters.

The journey from code chaos to mathematical zen isn't always easy, but it's always worth it. And with the right tools, patterns, and mindset, you can start that journey today.

Your users—and your future self—will thank you.

Intro to Functional Programming- 3 : Lazy Evaluation

zenoguy — Thu, 05 Jun 2025 18:30:00 +0000

Handling Infinity and Recursive Elegance

Part 3 of 4: From Code Chaos to Mathematical Zen

In our last post, we discovered how higher-order functions serve as the "glue" that makes functional programming powerful and composable. We saw how functions like reduce let us build complex operations from simple, reusable pieces.

But we only explored half of functional programming's secret weapons. Today, we'll dive into the other half: lazy evaluation and pattern matching—the tools that let you handle infinite possibilities and write code that flows naturally from the shape of your data.

Prepare to have your mind blown by what becomes possible when you stop thinking about "how to do something" and start thinking about "what something is."

Lazy Evaluation: Computing the Impossible

Imagine you're building a game engine. Your game generates events—player movements, enemy actions, environmental changes. In a traditional system, you might pre-generate a fixed number of events or process them in batches.

But what if you could define an infinite stream of potential events, and your system would only compute the ones it actually needs?

Here's what that looks like in Haskell:

-- Generate an infinite stream of game events
gameEvents :: [GameEvent]
gameEvents = [MoveUp, MoveDown, Attack, Jump, Heal, ...] -- infinite sequence

-- Process events lazily - only compute what's needed
processGameEvents :: [GameEvent] -> GameState -> GameState
processGameEvents (event:events) state = 
  processGameEvents events (applyEvent state event)

-- Get just the first N events when needed
handleFirstNEvents :: Int -> GameState -> GameState
handleFirstNEvents n state = 
  processGameEvents (take n gameEvents) state

Here's the magic: Even though gameEvents is defined as infinite, Haskell's lazy evaluation means only the events you actually use get computed. Need the first 10 events? Only those 10 are generated. Need 1000? Only those 1000 are computed.

How Lazy Evaluation Works

At its core, lazy evaluation connects programs in a remarkably efficient way. When you compose two functions f and g to form (g . f), here's what happens:

Program f starts executing only when g requests its input
f runs just long enough to produce the output that g is waiting for
Once f produces that piece of output, it pauses and g resumes
If g finishes before consuming all of f's output, f is terminated—even if it was designed to generate infinite data

This creates incredible modularity. You can split any program into two parts:

The generator: Produces many possible answers (even infinitely many)
The selector: Picks the right one

This is fundamentally different from traditional programming, where you have to carefully manage when and how much data to process.

Pattern Matching: Let Data Tell the Story

Now let's explore the other game-changer: pattern matching. Most of us first encounter this in languages like Rust with match statements or Haskell with case expressions:

handleResult :: Either String Int -> IO ()
handleResult result = case result of
  Left err -> putStrLn $ "Error occurred: " ++ err
  Right x  -> putStrLn $ "Successful result: " ++ show x

But there's something subtle and powerful happening here that's easy to miss. Pattern matching doesn't just check what shape a value takes (Left or Right)—it also binds the inner value (err or x) right there in the pattern.

We're not writing "if this is a Left value, then extract the left value and do something." We're saying: "if it's this shape, pull out this variable and use it directly."

This leads to code that flows naturally from the data itself, without complex extraction logic.

Recursive Elegance in Action

Once you get comfortable with pattern matching, you realize you don't need loops, counters, or complex control flow. You just let the data tell the story. Here are some examples that demonstrate this elegance:

Sum a List (Recursively)

sumList :: [Int] -> Int
sumList []     = 0           -- Empty list sums to 0
sumList (x:xs) = x + sumList xs  -- First element + sum of rest

This reads almost like a mathematical definition. No loops, no counters—just the essence of what "sum" means.

Fibonacci, the Declarative Way

fib :: Int -> Int
fib 0 = 0      -- Base case: fib(0) = 0
fib 1 = 1      -- Base case: fib(1) = 1  
fib n = fib (n-1) + fib (n-2)  -- Definition: fib(n) = fib(n-1) + fib(n-2)

We're not giving instructions—we're stating mathematical facts about what Fibonacci numbers are.

Tree Depth

data Tree a = Leaf | Node a (Tree a) (Tree a)

depth :: Tree a -> Int
depth Leaf = 0                    -- A leaf has depth 0
depth (Node _ left right) = 1 + max (depth left) (depth right)

This tells us the depth of a tree by expressing what depth means for each possible tree shape.

File Extension Matcher

fileType :: String -> String
fileType filename = case reverse (splitOn "." filename) of
  ("hs":_)  -> "Haskell source file"
  ("txt":_) -> "Text file"  
  ("md":_)  -> "Markdown file"
  _         -> "Unknown format"

Clean, readable pattern matching that's almost like a natural language description.

Custom Map Function

myMap :: (a -> b) -> [a] -> [b]
myMap _ []     = []              -- Mapping over empty list gives empty list
myMap f (x:xs) = f x : myMap f xs   -- Apply f to first, then map over rest

This transforms every element in a list using a given function. No loops, no mutation—just recursive structure that mirrors the problem definition.

The Mindset Shift

These examples illustrate a fundamental shift in thinking. Instead of focusing on how to manipulate data (loops, indices, mutations), we focus on what the data represents and express our logic in terms of data shapes and transformations.

From imperative: "Iterate through each element and accumulate a sum"
To declarative: "The sum of a list is either 0 (for empty) or the first element plus the sum of the rest"

The code becomes about data and transformation—not control flow. It's clean, expressive, and surprisingly satisfying once it clicks.

The Concurrency Sweet Spot

Here's where it gets really interesting for real-world applications. Remember our key insight from earlier posts: no mutable state means no race conditions.

When you combine:

Immutable data structures
Pure functions
Pattern matching for control flow
Lazy evaluation for efficiency

You get something remarkable: safe concurrency by default.

Functions don't step on each other's toes because they work with their own copies of data. No shared memory means no locking, no deadlocks, no mysterious threading bugs.

This makes it dramatically safer to:

Spin up multiple threads
Process data in parallel
Build asynchronous systems
Scale across multiple cores or machines

Languages like Erlang and Elixir take this even further with the Actor Model, where each process is lightweight, isolated, and communicates via message passing. It's like having microservices inside your application—concurrent, resilient, and easy to scale.

Real-World Impact

This isn't just academic theory. These principles power some of the world's most demanding systems:

WhatsApp: Built on Erlang, handling billions of messages with incredible reliability
Discord: Uses Elixir to manage millions of concurrent users
Financial systems: Rely on functional languages for correctness and performance
Telecom infrastructure: Erlang powers systems that require 99.9999% uptime

The elegance we've been exploring translates directly into systems that are more reliable, more scalable, and easier to reason about.

What's Next?

We've journeyed from the mathematical foundations of functional programming through higher-order functions and now to lazy evaluation and pattern matching. We've seen how these concepts create code that's both elegant and powerful.

But there's one crucial question remaining: How do you bridge the gap between this mathematical purity and the messy, stateful, side-effect-heavy real world?

In our final post, we'll explore how functional languages like Elixir handle real-world concerns—databases, user interfaces, network calls, and all the inherently stateful aspects of building actual applications.

We'll see how the principles we've learned scale from elegant code examples to production systems serving millions of users.

Coming up in Part 4: "From WhatsApp to Your Next Project: Making Functional Programming Work in the Real World"

Ready to see how these elegant principles power billion-user applications? We'll explore how functional programming bridges the gap between mathematical purity and real-world complexity—and how you can start applying these ideas in your own projects.

About This Series: This is Part 3 of a 4-part introduction to functional programming. We've journeyed from OOP's limitations through FP's foundations and tools. Next, we'll see how it all comes together in real-world applications and what it means for your next project.

Intro Functional Programming - 2: Higher-order Function

zenoguy — Thu, 05 Jun 2025 00:30:00 +0000

Higher-Order Functions Are Your New Superpower

Part 2 of 4: From Code Chaos to Mathematical Zen

In our last post, we explored why Object-Oriented Programming often leads to tangled, unpredictable systems, and how functional programming's mathematical foundations promise a better way. But there's a common criticism that functional programmers face, beautifully captured by John Hughes in his influential paper "Why Functional Programming Matters":

"The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these 'advantages' are not very convincing."

It's a sharp, almost sardonic observation. Functional programming often defines itself by what it isn't—no mutable state, no assignment, no explicit control flow. But just as denying oneself indulgence only makes sense if the reward is greater, functional programming's "sacrifices" offer tremendous power in return.

Today, we'll discover that power through the concept of higher-order functions—the secret weapon that makes functional programming not just viable, but incredibly elegant and powerful.

The Glue That Holds Everything Together

Imagine trying to build a chair by carving it from a single block of wood. Every curve, every joint, every surface has to be carefully sculpted from that one piece. It's possible, but incredibly difficult and inflexible.

Now imagine building that same chair by making individual parts—seat, legs, back—and assembling them with good joints and strong wood glue. Much easier, much more flexible, and if one part breaks, you can replace just that piece.

John Hughes uses this exact analogy to explain why functional programming works:

"A chair can be made quite easily by making the parts—seat, legs, back etc.—and sticking them together in the right way. But this depends on an ability to make joints and wood glue. Lacking that ability, the only way to make a chair is to carve it in one piece out of a solid block of wood, a much harder task."

In the context of functional programming, that "glue"—the magic that allows us to build complex systems from small, simple parts—is provided by higher-order functions and lazy evaluation.

Higher-Order Functions: The Universal Glue

A higher-order function is a function that either:

Takes other functions as input, or
Returns a function as output, or
Both

This might sound abstract, but it's incredibly powerful once you see it in action.

Let's start with a simple problem: computing the sum of a list. Here's a typical recursive definition:

sum nil = 0
sum (cons num list) = num + sum list

This works, but let's analyze what's happening. In this definition, only two things are specific to the idea of "summing":

The operation: +
The starting value: 0

Everything else is just a recursive pattern that could apply to many other operations. This is where higher-order functions shine.

We can extract the recursive behavior into a general function called reduce:

sum = reduce add 0

where:
add x y = x + y

and reduce is defined as:
(reduce f x) nil = x
(reduce f x) (cons a l) = f a (reduce f x l)

Here's the magic: reduce is a higher-order function because it takes another function (add) as an argument and uses it to combine elements of the list.

The Power of Abstraction

Now that we have reduce, we can reuse this same pattern for completely different operations:

Product of a list:

multiply x y = x * y
product = reduce multiply 1

Check if any element is true:

or x y = x || y
anyTrue = reduce or false

Check if all elements are true:

and x y = x && y
allTrue = reduce and true

Concatenate lists:

append x y = x ++ y
concat = reduce append []

What Makes This So Powerful?

By using higher-order functions like reduce, we've achieved something remarkable:

Separation of Concerns: We separate the what (summing, multiplying) from the how (recursively traversing the list)
Code Reuse: Instead of writing the recursion pattern over and over, we write it once and adapt it to different operations
Composability: These functions become building blocks that can be combined in countless ways
Readability: The intent of each function becomes crystal clear—product is obviously about multiplication, concat is obviously about concatenation

It's like creating your own "glue" that can connect different kinds of logic in a clean and elegant way. These higher-order functions become the joints between the different parts of your system.

Real-World Example: Data Processing Pipeline

Let's see how this applies to a more realistic scenario. Imagine processing a list of user records:

const users = [
  { name: "Alice", age: 30, active: true },
  { name: "Bob", age: 25, active: false },
  { name: "Charlie", age: 35, active: true }
];

// Traditional imperative approach
function processUsers(users) {
  const result = [];
  for (let i = 0; i < users.length; i++) {
    if (users[i].active && users[i].age >= 30) {
      result.push(users[i].name.toUpperCase());
    }
  }
  return result;
}

// Functional approach with higher-order functions
const processUsers = users =>
  users
    .filter(user => user.active)
    .filter(user => user.age >= 30)
    .map(user => user.name.toUpperCase());

The functional version is:

More readable (each step describes what it does)
More composable (you can easily add or remove steps)
More testable (each function can be tested in isolation)
Less error-prone (no manual loop management)

From Functions to Architecture

This principle scales beyond individual functions. The same composability applies to:

Utility packages: Libraries like NumPy or Pandas in Python
Microservices: A PaymentService and NotificationService communicating over HTTP
System components: Different modules that can be plugged together without tight coupling

Higher-order functions teach us to think in terms of composable, reusable pieces rather than monolithic blocks of code.

The Preview of Power

We've just scratched the surface. Higher-order functions are one half of functional programming's "glue." The other half is lazy evaluation—a concept that lets you handle infinite data streams and write programs that only compute what they actually need.

Imagine writing a game engine that can theoretically handle infinite sequences of events, but only processes the ones that actually matter. Or building data processing pipelines that can work with datasets too large to fit in memory, processing them piece by piece as needed.

What's Next?

In our next post, we'll explore lazy evaluation and pattern matching—the tools that let functional programs handle infinity elegantly and make logic flow naturally from the shape of your data.

We'll see how you can:

Process infinite streams of data without running out of memory
Write recursive functions that read like mathematical definitions
Make decisions based on data structure rather than complex if-else chains
Build systems that are both elegant and incredibly efficient

The medieval monk comparison falls apart when you realize that functional programming doesn't deny you power—it gives you superpowers.

Coming up in Part 3: "Handling Infinity and Recursive Elegance (Or: How to Think Like Data)"

Ready to discover how functional programming handles infinite possibilities and makes your code read like poetry? We'll explore lazy evaluation and pattern matching—the tools that make impossible things possible.

About This Series: This is Part 2 of a 4-part introduction to functional programming. We're journeying from the problems of traditional programming to the elegant solutions of functional approaches, building toward real-world applications that power systems like WhatsApp and Discord.

DEV Community: zenoguy

The GPU Delusion: Why AI Is Getting Lazy

Abundance Makes Systems Lazy

The Scaling Mirage

GPUs Won by Convenience, Not Destiny

CPUs Aren't Dead. They're Mutating.

The Android Moment Nobody Is Talking About

Performance Smart vs. Performance Big

The Real Future Question

This Isn't Anti-GPU

The Real Arms Race

When Time Became a Variable — Notes From My Journey With Numba ⚡

🧠 Why Numba Feels Different To Use

⚡ What The Numbers Look Like (From Numba Benchmarks)

🧪 My Local Benchmark (20,000,000-element loop)

🧵 Why Numba Beats Normal Python For CPU Workloads

🧩 “Interactive” Comparison Block

🎁 Underrated Numba Features I Learned To Appreciate

⚖️ Real-World Caveats That Matter

🧭 What Numba Changed In How I Write Code

I Saw an Instagram Reel Last Night. Now I Built a Bionic Reading Extension.

What Even Is Bionic Reading?

The Problem With Existing Bionic Readers

Cool demo. Terrible daily driver.

So I Built BoldFlow

How It Actually Works (The Interesting Part)

1. Tokenization (Words Aren’t Just \w+)

2. The Bionic Engine

3. DOM Walker (Where Most Extensions Fail)

4. SPA Support via MutationObserver

5. State Is Global, Not Tab-Local

Why I’m Keeping It Minimal

What I Learned (The Real Takeaways)

Final Thoughts

Why I Ditched Terminal UIs for Recruiters

Why I Ditched Terminal UIs for Recruiters

The terminal UI problem 🧠

The uncomfortable realization ⚠️

The pivot 🎯

What I learned ✅

Curious how it turned out?

My First Hackathon – 24 Hours, 1 Fintech App, 0 Sleep (Spoiler: We won a Special Mention too 🏆)

📅 Day 1 — Chaos Enters the Chat

💡 Enter SpendSight

🛠️ Bonus Side Quest: AdHacks

🎤 Final Pitch – Please Clap

🧠 What I Learned

📍 Try SpendSight (Frontend MVP)

🫡 TL;DR

I Made a Java Chat App in One Night (Because I Had No Projects)

💬 How It Works

🧠 What Broke My Brain

🧪 What I’d Improve (If I Had Time or Sanity)

🧱 Tech Stack

🧃 Final Thoughts

So I Decided to Learn Vim… and I Kinda Get the Hype Now?

First Impressions: What Even Is This?

What Shifted for Me

My Cheat Sheet (Still Growing)

Where I'm At Now

What's Next?

TL;DR

Apple Just Buffed Dev Tools

Xcode Got Smart (Finally)

What's different?

Linux Containers on Mac (Wait, What?)

* Uses a custom Swift-based init system, vminitd, to boot Linux VMs securely and efficiently

The Experimental Stuff Got Better Too

Not earth-shattering. But solid improvements if you're working in this space.

The Boring Stuff That Actually Matters

That LiquidGlass Thing

Why This Actually Matters

What I'm Curios abour

🛸 I tried Pygame (Build Space Shooters in a DAY)

(works for Arch distros{yh I use Arch}, lemme know if its giving error on other distros)

🎞️ The Origin Story (feat. Tim)

🧠 The Big Brain Stack

🔫 So What Makes My Game Different?

☠️ Kamikaze Enemies That Actually Hunt You

⚠️ Visual Warning System for Kamikaze Attacks

1. Tokenization (Words Aren’t Just `\w+`)