DEV Community: Zelen Gungor

Sorting Algorithms, Served Fresh

Zelen Gungor — Wed, 28 May 2025 05:24:02 +0000

The dining hall salad bar was my accidental CS professor. Those layered towers of wilted lettuce, rubbery cucumbers, and suspiciously orange carrot shreds? Turns out they were the perfect analogy for understanding stacks and recursion. Late one night during finals week, as I constructed my fourth meal-of-the-day salad, I had an epiphany: building a salad is just like managing a call stack.

🥗 Why Salad Makes Stacks Click

Stacks are often described in textbook terms like this: "A linear data structure that follows the Last-In, First-Out principle with constant-time push and pop operations..."

Cue the glazed-over eyes.

But frame it as salad construction? Suddenly it's deliciously clear:

Stack Operations and their Salad Equivalent

push() -> Adding a new ingredient layer
pop() -> Eating from the top down
peek() -> Admiring (but not eating) the top layer
Stack overflow -> Overfilled bowl disaster

Salad Bowl with Layers Visualization

Let's create our SaladStack class with these ingredients:

Lettuce 🥬
Cucumbers 🥒
Tomatoes 🍅
Onions 🧅
Carrots 🥕

🧠 Picture this: Every push() places a new layer onto your call stack, mirroring how you're constructing this salad.

salad = SaladStack()
salad.push("Lettuce")    # Base frame
salad.push("Cucumber")   # New stack frame
salad.push("Tomatoes")   # Another frame
salad.push("Onions")     # Growing the stack
salad.push("Carrots")    # Current top frame

class SaladStack:
    def __init__(self):
        self.layers = []

    def push(self, ingredient):
        print(f"→ Adding {ingredient} layer")
        self.layers.append(ingredient)

    def pop(self):
        if not self.layers:
            return "✗ Bowl empty!"
        return self.layers.pop()

    def peek(self):
        return f"Top layer: {self.layers[-1]}" if self.layers else "Bowl empty"

This code defines a SaladStack class that mimics a real-world salad tower. We use five common ingredients—lettuce, cucumbers, tomatoes, onions, and carrots—as our stack "elements." The class holds these ingredients in a layers list. When you call push(), you're virtually adding a new salad layer to the top of your bowl. Just like a real stack, the last item added is the first to be removed. So, a pop() operation takes off the topmost layer—say, those carrots, if they were the last ones added. If you try to pop() from an empty bowl, you'll get a helpful message.Need to check what's on top without removing it? The peek() method lets you inspect the current top layer of your salad. This clear metaphor and code structure make understanding stack operations like push, pop, and peek incredibly straightforward.

🍅 Now let’s see what happens when we start removing ingredients from our salad stack

Hand picking the top ingredient, with the bowl visually shrinking

💡 Here's the key: Each pop() operation removes a layer of the salad, precisely like a recursive call stack unwinds, processing one frame (or ingredient) at a time, always starting with the most recently added.

# Popping off ingredients (last in, first out)
salad.pop()  # Carrots
salad.pop()  # Onions
salad.pop()  # Tomatoes
salad.pop()  # Cucumber
salad.pop()  # Lettuce

As it can be seen from the code above, we're reversing the process: we're popping off each ingredient from our salad tower. The carrots go first because we added them last. Next are the onions, then the tomatoes, followed by the cucumbers, and finally, the lettuce at the very bottom. This sequence demonstrates the Last-In, First-Out rule, which is the fundamental concept of stacks. It's precisely how recursion unwinds, finishing the most recent task before returning to earlier ones. Witnessing your salad shrink like this offers a clear, practical illustration of how stacks work and also, how recursive calls operate behind the scenes.

💥 Uh-oh! Our salad bowl is overflowing

Consider this scene: Just as with recursion, endlessly adding layers without a way to stop will quickly spiral into chaos.

def infinite_salad(stack):
    # WARNING: No base case here
    stack.push("More Salad!")
    infinite_salad(stack)

# Uncommenting this causes a stack overflow
# infinite_salad(salad)

Imagine a salad bowl with no bottom, endlessly filled—that's precisely what happens when recursion runs wild. Our infinite_salad() function illustrates this: it keeps calling itself, continuously pushing more and more "salad" onto the stack. But because there's no base case to tell it when to stop, this recursive process never ends. What would the result be? A dreaded stack overflow, where your program runs out of memory from trying to manage an infinitely growing pile of function calls. Please remember that, just like our physical salad bowl, your computer's memory stack has its limits. So, do not forget to define a clear base case for your recursive functions to avoid this chaotic mess.

🥬 Finally, the salad bowl with a base case

This is the base case recursion strives for: the exact moment the process gracefully concludes and all tasks are resolved.

def base_case_example(ingredients):
    if not ingredients:
        print("Base case reached. No more ingredients.")
        return
    print(f"Processing {ingredients[0]}")
    base_case_example(ingredients[1:])

base_case_example(["Lettuce"])

This example illustrates the critical function of a base case in recursion. The base_case_example function works by processing ingredients one at a time, recursively removing the first item in each step. The base case activates when the list of ingredients is empty or contains only a small piece of lettuce. At this point, it prints a confirmation message and stops further recursive calls. Imagine trying to build a salad endlessly; that's what unchecked recursion does. The base case prevents this, ensuring that the recursion terminates, avoiding common pitfalls like stack overflow, and keeping our salad bowl — and your program's memory — perfectly managed.

🥗 The Last Scoop: Learning Beyond the Textbook

Honestly, I don't think I'll ever look at a salad bar the same way again. That late-night stacking of soggy greens wasn't just a snack; it was my "aha!" moment where stacks, recursion, and base cases finally clicked. That's the real secret to mastering computer science: sometimes the clearest insights don't come from a textbook, but from your dinner tray. Understanding truly deepens when you stop memorizing and start connecting ideas to your own experiences.

So, if you hit a wall with a challenging CS topic, don't hesitate to look beyond the usual sources. Maybe a sandwich, socks in a drawer, or that full salad bowl will give you the answer. When you think about it, it indeed is a great reminder: just as recursion needs a solid foundation to stop, you're building your knowledge one purposeful layer at a time.

Test out ideas. And remember to rest. The most rewarding code is usually the one you discover yourself.

What’s your favorite way to get tricky programming ideas to click? 🤔

Connecting them to everyday things (like building a salad!)
Visual aids (pictures, diagrams)
Relating them to real-world examples
Learning through stories or case studies
Hands-on coding and experimentation
Something else entirely? Share your secret!

Feel free to grab the complete set of examples and run them yourself on GitHub:

👉 View the full salad_stack.py code on GitHub

OOP Cookies: Baking Object-Oriented Programming Concepts

Zelen Gungor — Sun, 25 May 2025 16:51:51 +0000

The dining hall cookies were my first coding inspiration. You know the ones - suspiciously perfect circles that somehow tasted both overbaked and doughy at the same time. Late one night during finals week, I had an epiphany between bites: these sad cookies were just like my first attempts at object-oriented programming. The ingredients were there (flour = classes, chocolate chips = methods) but something wasn't quite right.

That's when I started seeing OOP concepts in my student life:

My laundry pile was basically a singleton pattern - only one instance allowed before overflow errors
My class schedule was polymorphism in action (same 8am time slot, completely different energy for "English Writing" vs "OOD")

This post is for every CS student who's ever:

Stared at a class definition like it was a cryptic dining hall menu
Accidentally created a memory leak worse than the dorm microwave after ramen night
Wished programming concepts came with the clarity of a good cookie recipe

We'll use real cookie examples to make OOP as satisfying as that perfect midnight snack. Because learning OOP shouldn't be more confusing than trying to follow your professor's 8am lecture after pulling an all-nighter.

🧁 OOP as Baking Styles: Why Cookies?

Picture yourself as a baker crafting three cookie types: Chocolate Chip, Raisin, and Heart-Sprinkle Sugar. Instead of rewriting mixing and baking steps for each, you design a Cookie base class to handle shared logic. Each subclass inherits these basics while adding unique touches—like extra ingredients or adjusted bake times.

This tasty metaphor shines a light on core OOP concepts:

Inheritance: Reusing core functionality (like dough prep) across subclasses
Encapsulation: Packaging related data (ingredients) and actions (bake()) together
Polymorphism: Letting each cookie type execute bake() in its own way

🥣 Base Cookie Dough — The Cookie Class

The bowl of unbaked dough mirrors the Cookie base class—a blank slate with essential properties (bake_time, ingredients) and a default bake() method. Just as all cookies begin with this neutral base, subclasses build atop shared code without redundancy. The simplicity of the image underscores how complexity emerges through later customization, much like OOP hierarchies.

class Cookie:  
    def __init__(self, bake_time, ingredients):  
        self.bake_time = bake_time  
        self.ingredients = ingredients  

    def bake(self):  
        print(f"Baking for {self.bake_time} minutes with: {', '.join(self.ingredients)}")

🥄 Adding Mix-Ins — Subclasses

The three topping bowls represent how subclasses customize the base Cookie class. Just as bakers fold in chocolate chips, raisins, or sprinkles to create distinct flavors, each subclass injects its own ingredients and behavior while preserving the core recipe. This mirrors OOP's inheritance (via super()) and polymorphism (via overridden bake() methods).

class ChocolateChip(Cookie):
    def __init__(self):
        super().__init__(bake_time=12, ingredients=["flour", "sugar", "butter", "chocolate chips"])
    def bake(self):
        print("Baking a gooey chocolate chip cookie… 🍫")

class Raisin(Cookie):
    def __init__(self):
        super().__init__(bake_time=15, ingredients=["flour", "sugar", "raisins", "butter"])
    def bake(self):
        print("Baking a hearty raisin cookie… 🥣")

class HeartSprinkle(Cookie):
    def __init__(self):
        super().__init__(bake_time=10, ingredients=["flour", "sugar", "butter", "heart sprinkles"])
    def bake(self):
        print("Baking a sweet heart-sprinkle cookie… ❤️")

🍪 Cookie Assembly Line — Inheritance in Action

The assembly line shows plain dough balls transforming into three distinct cookies - chocolate chip, raisin, and heart-sprinkle. This progression mirrors how inheritance builds specialized subclasses from a common base. Each stage represents:

The original Cookie class (plain dough)
Subclass initialization via super() (adding mix-ins)
Final preparation (method overrides)

def bake_all(cookies):
    for cookie in cookies:
        cookie.bake()  # Single interface, multiple behaviors

🔥 Finished Cookies in the Oven — Polymorphism Result

The oven reveals polymorphism in its tastiest form: identical heat transforms each cookie type differently—chocolate chips melt into golden pools, raisins caramelize, and sprinkles hold their vibrant color. Like Python’s method dispatch, the shared bake() call adapts to each object’s class. The oven acts as the interpreter, executing one instruction (bake()) that produces context-specific results, proving that interface consistency (the baking process) doesn’t mean uniform behavior. This is polymorphism crystallized: one method signature, multiple delicious implementations.

cookies = [ChocolateChip(), Raisin(), HeartSprinkle()]  # All subclasses
bake_all(cookies)  # Outputs:
# "Baking a gooey chocolate chip cookie... 🍫"
# "Baking a hearty raisin cookie... 🥣"
# "Baking a sweet heart-sprinkle cookie... ❤️"

I still remember the first time OOP truly clicked for me. It was 2 AM, my third attempt at a class hierarchy, when suddenly the pieces fell into place like ingredients in a perfect cookie recipe. That quiet moment of understanding - no grades, no applause, just me and the code - taught me what really matters in programming:

🍪 The messy drafts nobody sees are where the real learning happens
🍳 Trusting your own problem-solving beats chasing perfection
💻 Code tastes sweeter when you make it your own

These cookie examples aren't about right answers - they're about giving yourself permission to experiment. Take them, break them, rebuild them better.

Feel free to grab the complete set of examples and run them yourself on GitHub:
👉 View the full oop_cookies.py code on GitHub

RECURSION: WHERE EVERY CALL IS ANOTHER BITE OF BOWL

Zelen Gungor — Sun, 25 May 2025 14:04:25 +0000

There's something magical about recursion - the way a function can call itself, breaking down problems into smaller, more manageable pieces. But if we're being honest, it can also feel as confusing as trying to gracefully eat a bowl of tangled ramen noodles with chopsticks.

In this post, we'll explore recursion through the lens of everyone's favorite noodle soup. Why? Because much like recursion:

The tangled noodle knot represents the complex call stack, where each recursive call dives deeper into the problem
Pulling a single strand mirrors unwinding one recursive step from the stack
Layered noodles in broth show how each invocation stacks variables and return addresses
An overflowing bowl becomes Python's dreaded RecursionError when we forget our base case

Recursion is like slurping ramen: each mindful sip calls the next... until you either conquer the bowl or end up in a noodle disaster

We'll explore this tasty comparison by looking at:

Factorial functions (tracking recursion levels like counting stacked noodles)
Folder navigation (tracing winding noodle paths through directory structures)
Recursion dangers (when your function chain overflows like a boiling pot)

Whether you're a computer science student struggling with your first recursive function or a seasoned developer looking for a fresh perspective, this post will help you digest recursion properly.

import sys
print(f"Your system's recursion limit: {sys.getrecursionlimit()}")
# This is your 'bowl size' - try not to overfill it!

The beauty of recursion lies in its elegant simplicity - a function that calls itself to solve smaller instances of the same problem. But like eating ramen, the technique requires patience, practice, and knowing when to stop before you make a mess. Let's dig in!

🍥 Conceptual Noodles: Unpacking the Metaphor

Recursion is a function that calls itself, diving deeper into the problem space until it hits a base case—the condition that stops further recursion and begins the return phase. We can visualize this with our ramen bowl:

The bowl is the call stack.
Each noodle curl is a recursive call.
Pulling one noodle is executing the next level of recursion.
Reaching the end of the noodle is hitting the base case.
Overflowing the bowl is a stack overflow error.

By mapping these ideas to tangible ramen imagery, we make recursion less intimidating and far more memorable.

🍜 A Ramen-Fueled Journey Through Recursion

This intricate noodle knot perfectly represents the call stack - seemingly chaotic, yet following precise patterns when examined closely.

def untangle_noodles(noodle_bowl):
    # Base case: empty bowl
    if not noodle_bowl:
        return "Bowl empty!"

    # Recursive case: pull one noodle strand
    current_noodle = noodle_bowl.pop()
    print(f"Untangling noodle: {current_noodle}")
    return untangle_noodles(noodle_bowl)

# Try it with your ramen order!
ramen_order = ["shiitake", "chashu", "menma", "nori"]
untangle_noodles(ramen_order.copy())  # Always copy lists to preserve original

This function illustrates recursion's processing of nested data structures. The noodle_bowl list acts as our call stack, with each ingredient representing a pending operation. A recursive call occurs after processing each current_noodle, systematically shrinking the problem until the base case (an empty list) is reached. We use .copy() to safeguard the original list—a vital technique when handling mutable data structures in recursion, much like a chef separately preps ingredients before combining them

🥢 Following the Noodle Strand: Single Recursive Call

Each recursive call pulls one problem strand from the larger tangle.

def follow_noodle_strand(strand_length):
    # Base case: end of noodle reached
    if strand_length <= 0:
        print("Reached noodle end!")
        return

    # Recursive case: take one bite
    print(f"Slurping... {strand_length}cm remaining")
    follow_noodle_strand(strand_length - 5)  # 5cm per bite

follow_noodle_strand(30)  # A 30cm noodle strand

This example demonstrates linear recursion, where each call addresses a consistent segment (5cm) of the overall problem. The strand_length parameter functions as our recursion counter, decreasing by 5cm with every call until it reaches the termination condition. This approach mirrors how many recursive algorithms operate, breaking down problems into smaller, manageable chunks—think of binary search or various mathematical operations. The print statements visually trace the recursion's progress, which is helpful for debugging the call sequence.

🍜 Layered Noodles: Growing the Call Stack

Each recursive call adds another layer to your call stack.

def count_noodle_layers(bowl_depth, current_layer=1):
    # Base case: reached bowl bottom
    if current_layer > bowl_depth:
        print("Reached bowl base!")
        return

    # Recursive case: add another layer
    print(f"Layer {current_layer}: Adding more noodles")
    count_noodle_layers(bowl_depth, current_layer + 1)

count_noodle_layers(5)  # 5-layer ramen bowl

This example demonstrates recursion functioning as a counter, where current_layer increments until it matches bowl_depth. This pattern is frequently seen in tree traversals or any situation demanding controlled exploration of depth. The default parameter (current_layer=1) illustrates how to initialize recursive state, while the increasing number signifies stack frames accumulating in memory. Each layer's printout corresponds to a new stack frame being pushed, revealing how recursion constructs context before unwinding

🥢 Overflow Warning: Stack Limits

Too many recursive calls leads to disaster.

def infinite_slurp(bite_count=1):
    # WARNING: No base case!
    print(f"Slurp #{bite_count}")
    infinite_slurp(bite_count + 1)

# infinite_slurp()

This dangerous example highlights the absolute necessity of a base case. Without a way to stop, the function creates infinite stack frames until Python's recursion limit (typically ~1000) is hit, causing a crash. The bite_count shows how deep the recursion went. In real applications, this can happen when recursive algorithms process unpredictable data or complex math without proper safeguards. Always double-check your base case logic!

🥢 Balanced Recursion: Proper Base Case

def perfect_bite(noodles_left, broth_level):
    # Base case: meal finished
    if noodles_left <= 0 or broth_level <= 0:
        print("Bowl empty—delicious!")
        return

    # Recursive case: proportional bites
    noodles_taken = min(5, noodles_left)
    broth_taken = noodles_taken * 2

    print(f"Eating {noodles_taken} noodles with {broth_taken}ml broth")
    perfect_bite(noodles_left - noodles_taken, broth_level - broth_taken)

perfect_bite(20, 100)  # 20 noodles, 100ml broth

This solid example teaches us about recursion that juggles more than one thing at once. Our function manages both noodles and broth, and it knows to stop when either one is gone. The min(5, noodles_left) part is a clever way to avoid a classic recursion slip-up: trying to use something you don't have, which can cause big headaches. You'll also see how we make sure the broth usage (2ml per noodle) stays in sync with the noodles, keeping everything balanced. This kind of setup is perfect for any problem where you've got several limits or resources to keep an eye on.

🍜 Wrapping Up Ramen Recursion Feast

Recursion doesn’t have to be mystifying—in fact, when you think of each call as another mindful bite from a bowl of ramen, the process becomes clear and even a bit fun. Whether you’re untangling noodles one by one, slurping through a long strand, stacking layers in your bowl, or taking the perfect bite that balances noodles and broth, each example showcases how recursive logic operates in real code.

Feel free to grab the complete set of examples and run them yourself on GitHub:
👉 https://github.com/zelengungor/Web-2.0-Project/blob/main/ramen_recursion.py

🍥 Your Turn!

Of the four ramen recursion examples we explored today, which one made the most sense to you? Let me know in the comments:

Untangle Noodles
Slurp Strand
Count Layers
Perfect Bite

I'm excited to hear which bite of recursion helped you finally conquer the bowl! What other noodle metaphors can you come up with?