Yeldar Kudaibergen

Learn programming through undestanding

Yeldar Kudaibergen — Sat, 09 May 2026 17:00:00 PDT

Sometimes I think about writing a blog post and then suddenly it feels like: “this is so banal”, “who would even care about this, let alone find it useful.” But still, let me try to explain what I’m experiencing right now in my programming journey.

It’s strange. I realized that even though I already built ProxyFeed (backend in TS), it feels like I’ve never actually programmed before. It turned out that, in my current understanding, programming is when you write code yourself and run the program to see whether it works or not. And a person becomes a programmer exactly at that moment. A professional programmer becomes one when somebody pays them for it — usually money, by agreement.

So yeah, I came up with something again. And I’m 100% going to build it. It’s one of those “projects” that simply deserves to exist, and my buddy confirmed it too. The funniest and most dramatic part is that I literally cannot not build it. So yes, in a more or less sane state of mind, I’m voluntarily getting myself into this story. Let’s see what happens.

Even though I had never written a single line of Go in my life, I decided that Go would become the main backend language for DirectFlow. I looked at the situation from many different angles and it seems that, at this moment, Go is the most suitable language for me. I even realized why. It’s strange to understand the difference between TypeScript and Go not only through syntax, but through the character, logic, explanations, and style of the language itself.

I was immediately surprised that := in Go means both creating and assigning a value. Previously, I had creation and assignment both through =, meaning one action represented two completely different things. Anyway, I liked Go because it feels like the language is built similarly to how I am as a person. I don’t fully understand it yet myself, but I like that it works.

My next realization is that we learn programming by doing it. By writing code, creating programs, and running them. Previously, it felt to me like first you learn, and only then you program. As if you cannot program until you’ve learned how. Sounds logical, right?

But here’s what I discovered: computers do not grow naturally like trees. Humans created computers, languages, and embedded their logic into them. Our job is simply to understand how things work — not memorize syntax. Then write code. Realize why it's wrong I mean error. Again and again. That’s it.

But here’s what I discovered: computers do not grow naturally like trees. Humans created computers, programming languages, and embedded their logic into them. Our job is simply to understand how things work, not memorize syntax. Then write code. See why it’s wrong, fix the error, understand it. Then write code again. Again and again. That’s what a developer’s job is, right? And apparently, this is how a person becomes a programmer. You simply write code, understand it, and when you run the program — you are a programmer.

I partially understand that the “writing code” part may sound old-fashioned now, especially when it feels like AI writes code for everyone. But this is my current understanding, and I’m sure it will evolve further. And I will definitely keep writing about it here.

Follow my blog directly on DirectFlow: https://directflow.app/follow?url=https://yeldar.org

Start a podcast before anyone listens

Yeldar Kudaibergen — Thu, 09 Apr 2026 17:00:00 PDT

When you study at university, most things pass through you. Classes, notes, exams - and in the end, you’re left with a diploma that doesn’t show how you think. Now imagine recording your journey from the first year every week, honestly: what you learn, what confuses you, what starts to make sense. You can talk to classmates, ask questions, reach out to people in the field. You’re creating content and thinking out loud.

At first, no one listens - and that’s the advantage. No pressure, no need to perform. You can be wrong, change your mind, and figure things out. Over time, your thinking becomes clearer, and you build a record of your growth. After a few years, you don’t just study a subject - you understand it.

People say “no one will listen.” I used to think that was a problem. Now I see it as freedom.

Following this idea, I’m starting my own podcast about my podcasting journey, this time in English, to document the process of figuring things out.

In this podcast, I’ll be talking about how I’m building it from zero, step by step. I’ll share the process of writing my book about podcasting, and also the ideas behind ProxyFeed - a tool I’m working on.

I know it might sound like I think too much about podcasting. Maybe I do. I just really care about freedom and independence - and podcasting, for me, is exactly about that.

Recently, I started sharing this idea while working on UberX, aka a "classic immigrant job", talking to students from USC and professionals. I realized these conversations shouldn’t just disappear, so I began offering my email if they ever wanted to start a podcast or continue the conversation. A couple of people wrote it down - that’s when it clicked: this idea resonates because it’s real.

Why does C have so many compilers?

Yeldar Kudaibergen — Tue, 16 Dec 2025 16:00:00 PST

When you first start learning C, you quickly find out that C is a compiled language. Compilation can feel like an extra step after writing the code, unlike, for example, JavaScript. In JS, you don’t need to compile anything manually - compilation happens under the hood, making the process feel automatic, so the language appears to simply interpret your code.

Compared to that, compilation in C can initially feel like an unnecessary and redundant step.

But recently, I accidentally went deeper into the topic of compilers, and it slightly shifted my understanding of C.

Have you ever noticed that the code written in C is the same, yet there are multiple compilers: gcc, clang, and so on? A natural question comes up - if the language is one, why does it need different compilers?

It turns out the key point is that a compiler translates code for specific hardware. This universality - a language built with portability across different architectures in mind - is exactly what made C so important in the first place. Since compilers are different, they can behave differently when compiling the same code:

they report errors differently
they produce warnings differently
they optimize code differently

...while the source code itself remains the same. And for the same reason, data types in C can have different sizes - depending on the architecture and the compiler.

If you think about it, it’s a brilliant solution: the same code can be compiled for different hardware. That’s why C has so many compilers.

A deep cleanup of ProxyFeed

Yeldar Kudaibergen — Fri, 14 Nov 2025 16:00:00 PST

I realized that while improving ProxyFeed I overloaded it so much that its original purpose began to suffer: providing a stable address for a feed. So I removed almost all feed modifications. Almost, because feeds have self-tags, and those must be rewritten so the feed reader has no doubts about the canonical source of the proxy feed.

There is something interesting here: the less you interfere with someone else’s feed, the cleaner the architecture becomes. You remove one piece of logic, and immediately you see that another one is unnecessary. Then another. And step by step the system returns to its natural form. Without trying to “improve” what should not be improved.

It turns out ProxyFeed should be a stable bridge between the original feed and the platforms. That is its only strength. Everything else is noise that gets in the way.

Once I removed almost all modifications, it became clear that the true value of ProxyFeed is its reliability. That it does not break the feed. That it does not disappear. That once a stable address is created, it lives and makes it possible to change the original feed URL or even the original feed type without pain.

And here is the fascinating part: the simpler the system becomes, the clearer the real work becomes. You need to correctly identify the feed type. You need to guarantee no duplicates. You need a cache system that does not fail. You need to ensure that self-tags always point to the proxy feed. You need proper support for JSON, Atom, and whatever comes next.

Here is what was actually done:

fully removed all feed content modifications, no element edits and no attempts to "improve" the original feed;
implemented feed type detection (RSS, Atom, JSON Feed) before parsing;
kept only the essential rewriting of self-tags (rss/atom/json) so feed readers treat the proxy feed as canonical;
added a strict check preventing the same original feed from being connected twice;
added validation ensuring publicUrl is unique and never conflicts;
added proper handling of JSON Feed without trying to mimic XML;
improved XML normalization: remove BOM, add declaration only when missing;
removed itunes:new-feed-url so no player can redirect subscribers back to the original;
rewritten caching logic: correct handling of hash, unchanged, partial and ok states;
added atomic guarantees for cache and backup creation;
moved the whole project closer to the “as-is” principle: minimal interference, maximum stability.

I’m self-taught dev, and I have to learn from my own experience from trying to improve things that, as it turns out, didn’t need to be touched. That’s okay. ProxyFeed grows together with me. And every time I simplify it, I understand the architecture, the responsibility, and the path itself a little better. I want this service to live a long life, and for the people who choose it to be able to rely on it with confidence.

Is it a podcast? But why?

Yeldar Kudaibergen — Tue, 11 Nov 2025 16:00:00 PST

For the past 10 years, I’ve been exploring podcasting — as a trend, as a business, and as something that has changed my life.

This post — grew out of a desire to understand and explain what a podcast is, and what podcasting is. To understand — for myself. To explain — for anyone who one day asks the same question. What I do here is simple: I think out loud and write it down. Because for me, words — text — are the foundation of understanding.

At the beginning, I just wanted to know what exactly I was doing. What does it mean when I say “I’m a podcaster”? I didn’t want to just repeat trendy words — I wanted to understand. And it didn’t happen right away. Like many others, I tried to understand podcasting through other people’s definitions: articles, conferences, videos, opinions. But they left me uneasy. Something didn’t fit, something was confusing, something just felt off. I kept feeling that the definitions weren’t getting to the core.

I met people who said, “Oh, a podcast is just a conversation on YouTube,” or others who insisted it’s simply an RSS feed — and that’s it. All of that is part of the journey.

And so, after years of practice, conversations, research, debates — and especially the need to be heard (for some reason, that really mattered to me at the time) — I came to my own clear and simple definitions. They’re built on logic, evidence, history, and hands-on experience. These definitions answer today’s key questions about podcasts and podcasting. They don’t try to make someone right or wrong — they just clarify what’s what, without the noise.

Most importantly, they finally gave me peace of mind. Now I know exactly what I do. And when I explain what a podcast is, I don’t hesitate, second-guess, or doubt. It’s clear. It’s simple. I’ve seen it many times — after I explain it, people feel free, light, clear.

I’ve worked with large commercial companies and industry experts, as well as students and school kids — and it’s always the same effect. These people go on to create unique, untemplated podcasts. It’s amazing: I explain it the same way to everyone, and the outcomes are always different.

I still don’t know exactly why I’m so passionate about podcasts and podcasting. It just happened. I have friends who obsessively photograph airplanes — I’ll probably never understand them. But I respect their passion and their attempts to explain it to me. Or like a chef who knows the subtle difference between one type of salt and another, and why this dish needs one and not the other. Thankfully, we don’t have to understand all that to enjoy a great meal. And you don’t have to dive as deep into podcasting as I have — you can simply enjoy the result.

What is podcasting?

Podcasting is the distribution of media files via an RSS feed with an <enclosure> element. These are usually audio or video files. In this context, an RSS feed using the <enclosure> element isn’t just a technical choice — it’s a foundation for freedom and independence.

It could have been built on any other mechanism, but right now, only RSS with <enclosure> gives us that level of openness, portability, and control. The key is that the RSS feed contains an <enclosure> element with a direct link to the file.

If we remove RSS — or the <enclosure> element — and everything falls apart. We lose the definition of everything. What is podcasting? How is podcasting different from streaming or radio? RSS with an <enclosure> element is the cornerstone of podcasting. It’s not just a technical detail — it’s the very thing that makes a podcasting a podcasting.

Without this distinction, it becomes impossible to tell podcasting apart from YouTube — or even Dropbox. Sure, those platforms might be more convenient, more intuitive, more centralized, with “smart” recommendations and polished interfaces. But they are also controlled: bound by laws, rules, algorithms, and corporate interests. You can call that many things — but if it doesn’t involve RSS with an <enclosure> element, it’s not podcasting.

When does a piece of audio become radio? When it’s broadcast over the airwaves. Before that, it’s just audio. Why does the same exact text get different names depending on how it’s sent? If sent over SMTP — it’s email. If sent over the SS7 signalling protocol — it’s an SMS. Even though the content is exactly the same.

Same with the podcasting. It becomes the podcasting only because it distributing files via RSS with an <enclosure> element. Not content production, feeling, or opinion — just the delivery method.

Oh, right — podcasting is not about content creation. Recording audio or video is production, with its own stages: pre-production, production, post-production. Podcasting only begins at the moment of publishing via RSS.

What is a podcast?

A podcast is a media files that is distributed through an RSS feed using the <enclosure> element. These are typically audio or video files — they become podcasts when they are distributed through podcasting.

The main confusion in defining a podcast stems from the tendency to conflate the media file with its content. Many people assume a podcast is a specific genre or format — for example, a casual conversation, an interview, a narrative, or an investigative series.

But this assumption quickly falls apart. If we define a podcast as a free-form conversation, what do we call solo podcasts — monologues recorded by a single person? And what about podcasts that feature no human voice at all, such as audio recordings of elevator sounds or birdsong in a forest?

Every time we try to shift the definition toward genre or format, we end up creating countless exceptions. Eventually, the definition becomes meaningless — it no longer defines anything clearly.

So why is it that people so often associate the word “podcast” with a conversation, or with the presence of a human voice, and so on? There are plenty of such labels. I’ve discovered something interesting: whatever kind of podcast someone first encountered — they tend to believe that is what a podcast is supposed to be. And often, they end up creating podcasts in the same format or genre. And this is absolutely normal.

If someone’s first exposure to podcasts was The Joe Rogan Experience, then that becomes their definition of what a podcast is — and whatever the host does becomes, for them, what podcasting means. Or if it was This American Life — then that’s what they think podcast is. It’s not a rule — it’s just an observation of mine.

Once, just for fun, I created a podcast that contains only a single episode, one second long — Бір. Another example: Elevator — a podcast where I post elevator sounds. And these are podcasts. Just as much as Serial or Podcasting 2.0 are. They have an RSS feed with an <enclosure> element, they can be subscribed to, they’re published on the same platforms as all other podcasts, and so on. And the fact that there’s no human voice in them… well, that’s just the kind of podcast it is.

I call this the absurd level of freedom. At first, it may seem ridiculous — but then you realize what kind of creative freedom you’ve gained.

When I say that “something is a podcast”, I mean one thing only: it's available via RSS — or distributed to platforms through an RSS feed. No RSS? Then it’s just file on the internet. Even with RSS, it’s still the same file — but now it becomes something more: part of a decentralized flow, powered by automation and driven by the principles of freedom and independence on both ends.

ProxyFeed devlog: funding tags, bug fixes

Yeldar Kudaibergen — Tue, 15 Jul 2025 17:00:00 PDT

Important update: ProxyFeed has undergone significant architectural changes. Much of the old behavior and many earlier features have been removed or redesigned. For the latest and accurate information, please read the new post describing all recent changes: A deep cleanup of ProxyFeed.

I submitted my application for the LinkedIn REACH Backend Apprenticeship and had to write three essays, so I didn’t have much time for coding. Fortunately, I got everything done and sent off — now I’m back to working on ProxyFeed.

Originally, ProxyFeed was built specifically for podcast feeds, and even now, I still find remnants of that original thinking when adding new features. But my approach has changed — I now support Podcasting 2.0 tags for any type of RSS feed, not just podcasts. That said, I’ve kept a flag in the database just in case we need to distinguish between podcast and non-podcast feeds.

One of the updates: I revised how the <podcast:funding> tag works. Now, users can only add one funding tag per feed, regardless of whether it’s a podcast. Technically, multiple tags were allowed, but there's really no point — podcast players usually display just one, and I assume RSS readers will do too. After a tag is added, the feed is immediately re-fetched so the change appears in the proxy without delay. Also, I finally implemented tag deletion, and if a feed already has a funding tag in the original source, we now inform the user on the settings page.

⚠️ This funding tag comes from the original feed and cannot be edited here. To change it, update your original RSS feed or remove the tag from the original feed — then you’ll be able to edit it here.

What happens if the original feed didn’t have a funding tag, but the user adds one through ProxyFeed — and then the original feed later adds its own funding tag? In that case, ProxyFeed keeps the original intact. The original feed always takes priority over proxy changes.

This work, even just adding a seemingly simple tag like <podcast:funding>, reminded me how complex this project really is.

Another step: replacing the atom:link with the URL of the generated proxy feed. This worked perfectly for new feeds, but didn’t apply to older ones — unless the user updated the domain or slug. So, I wrote a script that scanned all feeds and patched the outdated ones.

I also cleaned up the database — removed old unused tables. At some point, I had the idea to fully parse feeds into structured database tables and reassemble them later. But due to the huge variety in RSS formats (or maybe I just wasn’t ready for it), this approach turned out to be unrealistic. So I deleted all related tables. The database is now clean.

All of this is part of a gradual preparation for the next major step: adding Podping support.

Oh, and I fixed another bug: ProxyFeed supports both system and custom domains. When users picked a system domain, I wasn’t generating a slug for them, since system feeds used feed id. Now, regardless of domain type, every feed gets a slug.

Cross-social networks

Yeldar Kudaibergen — Sun, 15 Jun 2025 17:00:00 PDT

All modern social networks are basically the same. You can post text, photos, videos. Some even support audio. But they’re all closed off from each other.

Now imagine this: you can read TikTok from Mastodon. Or subscribe to a YouTube channel from Bluesky, like it’s just another account in your feed. Or read Substack posts inside Threads.

The answer already exists. Most platforms already have RSS feeds (some public, some hidden). And many RSS feeds already include rich media: text, images, video, audio — sometimes even files via <enclosure>.

This kind of future is already partially possible — especially in the Fediverse, where bots and parsers can deliver content across platforms. You can follow Bluesky feeds, Mastodon accounts, even podcasts, blogs, or YouTube channels. But right now it all feels like duct tape and magic — servers, APIs, proxies, and background scripts. It really feels like this should be much simpler.

To be fair, RSS isn’t strictly required — the real goal is for any social network to be able to followproxyfeed-BKTgdpmS any other. No need for cross-posting, duplicate accounts, or “check out my Instagram here” links. You should just be able to read what you want, where you want. That said, right now, RSS is still the most practical and universal tool for this.

Right now, it's still a bit of a mess to make it work. But the idea is simple: we just want to subscribe and read, without worrying about formats or protocols. Wherever you are, you follow what interests you — and it shows up in your feed.

A clearer vision for ProxyFeed

Yeldar Kudaibergen — Wed, 11 Jun 2025 17:00:00 PDT

Note: This post was originally written in Kazakh. This is an expanded English translation.

ProxyFeed.io is now powering live feeds — including my own audioblog — and everything is working as expected.

The biggest difference from the previous version is that I’ve now clearly defined the main entity of ProxyFeed: the new RSS feed we generate for the user. Every function in the system revolves around this feed. Previously, I don’t think that was entirely clear to me. But this realization helped structure the entire system’s architecture.

At first, I made a big decision: Users couldn’t register unless they provided a fully valid RSS feed with <enclosure> tags. But as I kept building, my thinking evolved. I realized there’s no real reason to limit ProxyFeed to podcast feeds only — we can accept any valid RSS feed. It doesn’t have to be audio-based. If the feed is valid, ProxyFeed can work with it. This shift helped me open up new use cases I hadn’t even considered before.

It’s important to be clear about one thing: ProxyFeed is, first and foremost, a stable feed URL. Your RSS feed never changes — even if you change hosts. Everything else — Podcasting 2.0 tags, caching, feed enhancements — is built on top of that foundation.

Another core principle: If your original feed already includes advanced tags, ProxyFeed doesn’t overwrite or interfere. We only add missing tags — nothing more. That’s intentional: it keeps things simple and shows respect for your existing setup.

P.S. One thought I’ve been toying with: what if we added some Podcasting 2.0 tags to regular blog feeds?

ProxyFeed — a permanent URL for any RSS feed

Yeldar Kudaibergen — Sun, 08 Jun 2025 17:00:00 PDT

TL;DR: I built ProxyFeed — a tool that gives your podcast (or any RSS feed) a permanent, stable URL, no matter how often your hosting changes. It enhances your feed with Podcasting 2.0 features, supports custom subdomains, and works for any type of RSS. I made it to solve my own problem — now it’s ready for others to use. Core features will stay free; premium options may come later.

Lately, this blog, podcast, and social channels have gone quiet — but behind the scenes, things have been moving fast. About a three months ago, I built a simple website for my podcast in Kazakh. As part of that, I had to change the RSS feed — a familiar problem in the podcasting world. If you switch podcast hosts, your feed URL changes. Sure, you can set up a 301 redirect, but even that isn’t guaranteed to work forever.

So I decided to solve this problem once and for all — at least for myself. I built a tool that takes the feed my podcast site generates and republishes it under a stable, fast, permanent link. Now, no matter how often I change hosting platforms, my public feed stays the same. On top of that, the tool can enhance the RSS feed — for example, by adding Podcasting 2.0 tags and other advanced features. I have big plans for the future.

This idea actually started years ago when I was still living in Kazakhstan. But back then, I didn’t have the knowledge, experience, or courage to follow through. It remained just a conversation. After moving to the U.S., I realized I had to make it real. I built the first version just for myself — then realized it could help other podcasters too. That’s when I gave it a name — ProxyFeed — and turned it into its own project.

Today, ProxyFeed is live and working. It’s currently powering the RSS feed for my audio blog, and everything is running smoothly. The core of the system is now clearly defined: the main product is the proxy RSS feed we create for the user. Everything else in the system — features, tools, domains — exists to support that one feed.

This architectural clarity led to one key decision: if a user doesn't provide a valid RSS feed with <enclosure> tags (a full podcast feed), they won’t be able to register. If you don’t already have a feed, ProxyFeed isn’t for you.

Having a clear definition of the system’s core made development much easier. For example, I used to treat the user’s custom subdomain and their original feed as equal. But now I see them both as secondary — just support elements for the main proxy feed we generate.

One more major update: ProxyFeed no longer works only with podcasts. Now it can handle any RSS feed. No restrictions. I initially built it from a podcasting perspective, but over time I realized users are much more diverse. For example, this blog now has its own ProxyFeed-powered RSS feed: https://feed.yeldar.org/blog

The old feed still works, for now. But if I ever move my blog to a new domain, only the ProxyFeed URL will remain stable. That’s the whole point — to ensure that your feed link never breaks, no matter what happens upstream.

One area of focus is Podcasting 2.0 support. I’ve started adding new tags, beginning with <podcast:funding>, and soon I’ll include <podcast:locked>. My initial goal is to implement the full Podcast Standards Project feature list.

Soon, I plan to share ProxyFeed with the podcasting community. If it solves your problem like it did mine — go ahead and use it. The core functionality will remain free. To be honest, I didn’t build this to make money. I built it to solve a problem I personally faced. Now I’m just sharing it with others.

Now AI is my Study buddy

Yeldar Kudaibergen — Sat, 12 Apr 2025 17:00:00 PDT

I'm still reading K&R. As I’ve said before, I like the book — it’s concise, clear, but sometimes a bit dry and requires a thoughtful approach. Without context, some things are hard to grasp, especially if you're learning C from scratch. Sometimes I just want to discuss certain parts with someone. After we moved to Los Angeles, my conversations with my mentor became rare — and to some extent, AI took his place.

The main drawback of AI, I think, is that it always tries to answer — even when it doesn’t know. It can "hallucinate" or make things up. So I always double-check its answers, test them, and look for confirmation elsewhere.

For example, why bother a mentor with a question like “Why is ++i better than i++?” I find even questions like that interesting, but for someone with decades of experience in commercial programming, it probably feels too basic. This way, if he finds it interesting, he can just read my post — and maybe later we’ll talk about it in person.

Overall, I’d say this: learning with AI is faster — and more importantly, deeper. This might be the first book I’ve ever read in conversation.

One shortcut for copy and paste

Yeldar Kudaibergen — Sun, 15 Sep 2024 17:00:00 PDT

When I’m writing posts in 11ty, I often need to create new posts by copying and pasting files into the same folder. While this isn't difficult, the repetitive nature of the task started to irritate me. I wanted to find a faster way.

I discovered that while ⌘ + D works for duplicating files in macOS, but it doesn't work in VSCode. Than I found a way to streamline the process using the "File Utils" extension.

Here’s how to set it up:

Install the "File Utils extension;
Open Keyboard Shortcuts settings: go to Code > Settings > Keyboard Shortcuts or just press ⌘ + K ⌘ + S;
Find the Duplicate File Command: in the Keyboard Shortcuts window, type "Duplicate file" in the search bar;
Assign a Keybinding for Duplication.

I wanted to create the shortest keyboard shortcut to duplicate a file: "D" key. However, that didn’t work, as I couldn’t finish any word containing the letter "D" 😁 Every time I pressed "D", the file duplication command triggered. As a result, I had to resort to using the key combination ⌘ + D ⌘ + D. Yes, twice. You just have to press ⌘ and press D twice.

Now, when you want to duplicate a file, just select the file in the file explorer, press your newly assigned keybinding, and the file will be duplicated in the same folder. You will only need to enter a new file name.

Pointers in C made simple

Yeldar Kudaibergen — Fri, 30 Aug 2024 17:00:00 PDT

When I first came across pointers in C, I thought it was a pretty tricky topic. Even when I was just doing simple pointer exercises, like working with arrays, I didn't really understand what was going on under the hood. Today, I finally took the plunge and dived into chapter 5 of the C book, which explains in detail what pointers are and how to work with them.

I found this example really helpful in understanding pointers better. It goes like this:

#include <stdio.h>

int main()
{
    int x = 1, y = 2, z[10];    // Don't worry about z[10] for now;
    int *ip;
    ip = &x;
    y = *ip;
    *ip = 0;
    ip = &z[0]; // I think this point was added to show that a pointer can also change its value; don't worry about z[10] for now;

    return 0;
}

Declaring variables and a pointer

Let's dive in and start declaring some variables! We'll go ahead and create variables: x, y. We also create an ip pointer that will point to a variable of type int, which we'll use to help us keep track of things.

int x = 1, y = 2;
int *ip;

I'd like to draw your attention to the way a pointer is declared: int *ip. This just means that ip is a pointer to a variable of the int type. The asterisk * here is super helpful because it shows us that ip is not just a regular variable, but a pointer! This means that it will store the address of a variable of the int type in memory.

It's really important to understand that the * is referring to ip and not int. I'm sure you'll find this example really helpful in understanding this point:

int *w; k = 1; // w – a pointer to a variable of `int` type; k is just a variable of `int` type;

Let's continue parsing the code from the book...

Assigning the address of a variable to a pointer

Next, we assign the address of the x variable to the ip pointer:

ip = &x;

The & operator before x means “address of the variable x”. Thus, now ip stores the address of the variable x. This is a key part of understanding pointers: a pointer itself does not store the value of a variable, it only stores its address in memory.

Pointer dereferencing

The next step is pointer dereferencing:

y = *ip;

Here, the asterisk * before ip means “the value at the address pointed to by the ip pointer”. Since ip points to x, *ip returns the value of x which is 1. It means *ip equal to x or vice versa.

Therefore, the variable y is assigned the value 1.

Changing the value of a variable through a pointer

Now we will change the value of the variable x through a pointer:

*ip = 0;

This line means “assign the value 0 to the variable pointed to by ip”. Since ip points to x, x becomes 0. That is, the * in *ip works both ways. With *ip you can take out a value, likewise with *ip you can write a value. In detail: *ip is x. Lines printf in C code work the same way:

int x = 1;
int *ip = &x;

printf("%d", x);      // 1
printf("%d", *ip);    // 1

Important points

The pointer itself stores only the address of the variable, not its value. This is an important distinction to understand. A pointer points to a memory location where the value of a variable is stored, but the pointer itself stores only the address of that location.
Pointer dereferencing, that is, when we write “asterisk variable pointer” - *ip, we are accessing the value of the variable pointed to by ip. This is called pointer dereferencing.
We can assign the value of the variable through the pointer. That is, dereferencing works both ways.
The asterisk - * is used to dereference a pointer and the ampersand - & is used to get the address of a variable.

At first glance, pointers in C may seem complicated, but when you begin to understand their essence, they become a powerful tool for memory management.

This example helped me to better understand how pointers work and how they can be used. I hope my experience will help you learn this topic faster.

I also suggest you to read the post The Asterisk * Operator in C.

Does every memory cell in a computer have its own address?

Yeldar Kudaibergen — Mon, 26 Aug 2024 17:00:00 PDT

By diving into the world of C, I have encountered the concept of memory addresses and how they relate to variables and data storage. This topic intrigued me, and I decided to explore the question: Does every memory cell in a computer have its own address? Here’s what I discovered.

In the simplest terms, a computer's memory is organized into a series of storage locations, known as memory cells. Each of these cells can hold a small amount of data, typically one byte. To access and manipulate this data effectively, every memory cell is assigned a unique identifier known as an address.

When I declared a variable in C, like int num;, I learned that the compiler allocates a memory address for num, where its value will be stored. This made me realize that every time I create a variable, I am essentially creating a link to a specific location in memory.

When a program is executed, the operating system allocates memory for it, dividing it into segments like code, data, and stack. Within these segments, individual variables and data structures are assigned specific addresses sequentially. For example, if a program starts execution at memory address 0x00400000, the first variable might be stored at that address, while subsequent variables get assigned addresses incrementally.

One surprising fact I came across is that modern computers use something called virtual memory, which creates an abstraction of memory. This means that the addresses used by a program may not correspond directly to physical memory addresses. The operating system manages these mappings, allowing programs to use a larger address space than what is physically available.

Another interesting tidbit is that the number of unique addresses is determined by the architecture of the CPU. For instance, a 32-bit system can address about 4 billion unique locations, while a 64-bit system can address a significantly larger space. This is why 64-bit systems are now the norm—they can handle much more memory, which is crucial for running modern applications.

In conclusion, I found that every memory cell in a computer does indeed have its own address, which plays a vital role in how we store and access data. Understanding these concepts is essential for anyone learning C programming, as it lays the groundwork for exploring more advanced topics like pointers and data structures.

This exploration has given me a deeper appreciation for how computers manage memory and how crucial these addresses are for efficient programming. I’m excited to continue my journey and see where this knowledge takes me!

About getchar() in C

Yeldar Kudaibergen — Tue, 13 Aug 2024 17:00:00 PDT

getchar() is a simple but powerful function from the C standard library that allows you to read characters from standard input.

It is defined in the header file <stdio.h> and has the following prototype:

int getchar(void);

The int return type is used because getchar() returns a character from the input stream as an integer. This allows it to handle all possible character values, as well as special values like EOF (end of file). Because in C, characters (char) are represented as integer values corresponding to their encoding in the ASCII table. For example, the letter 'A' has an ASCII code of 65, and 'a' has 97. And by returning the value as an int, getchar() can handle not only all ASCII characters but also special values like EOF.

EOF (end-of-file) is a special value indicating that the input stream has ended. It is usually represented as -1. If getchar() returned a char type, it would be impossible to distinguish EOF from valid characters, as char ranges from -128 to 127 or from 0 to 255 (depending on the implementation). Using int avoids this issue, as EOF typically has a value that is outside the range of ASCII characters.

Also, calling getchar() blocks the program's execution until a character is entered and the Enter key is pressed. This is convenient for interactive data input.

Here’s a straightforward example of using getchar() with two conditions for clarity:

#include <stdio.h>

int main() {
    int c;

    printf("Enter text (to finish, enter Ctrl+D or 'd'):\n");
    while ((c = getchar()) != 'd' && c != EOF) {
        putchar(c);
    }

    printf("\nProgram terminated.\n");
    return 0;
}

In this example, getchar() is used to read a character from standard input. This character is stored in the variable c. The while loop continues as long as the entered character is not 'd' and not EOF. This allows the program to terminate when the user inputs d or presses Ctrl+D on macOS. The entered character is output back to the screen using putchar(c).

To fully understand how getchar() works, try entering single characters as well as whole words and sentences. Input to getchar() is buffered until you press the Enter key. This means that getchar() does not receive a character immediately after it is pressed but only after the line of input is complete. So, if you enter kghdkeh, the program will output only kgh because it will stop at d according to the condition.

Understanding #define in C

Yeldar Kudaibergen — Sun, 11 Aug 2024 17:00:00 PDT

As I dive into the world of programming with C, one of the fundamental concepts I've encountered is the #define preprocessor directive. Learning about #define from the classic book "The C Programming Language" by Brian Kernighan and Dennis Ritchie has been quite enlightening. Here’s what I’ve understood about it and why it’s an essential tool for writing efficient and readable code.

#define is a preprocessor directive in C that allows us to create symbolic constants and macros. It essentially instructs the compiler to replace instances of a specific name in the code with a defined value before the actual compilation process begins. This happens during the preprocessing phase, which occurs before the compilation phase.

Using #define allows programmers to give meaningful names to values used in their code. Instead of scattering "magic numbers" throughout the code, which can make it difficult to understand, we can use #define to give these numbers descriptive names. This makes the code much easier to read and understand, both for myself and others who might read my code.

By defining constants at the beginning of the program with #define, it's easy to update these values in one place if they ever need to change. This single-point change capability greatly simplifies maintenance and reduces the risk of errors. If I need to change a constant value, I can do it by modifying the #define statement rather than searching through the entire codebase for every instance of that value.

Kernighan and Ritchie emphasize the dangers of hardcoding values directly in code. Using #define helps avoid this by abstracting the values into named constants. This abstraction layer is particularly useful in large codebases where the same value might be used in multiple places.

Another advantage mentioned in the book is that using #define can sometimes allow the compiler to optimize the code better. Since the compiler replaces the symbolic names with actual values during preprocessing, it can optimize the resulting code more effectively than if variables were used.

Besides defining constants, #define can also be used to create macros, which are like functions but are expanded inline. This can improve performance by avoiding the overhead of a function call, although it’s important to use them judiciously to maintain code clarity.

The power of #define lies in its simplicity and efficiency. By providing a way to name constants and create macros, it enhances the clarity, maintainability, and performance of C programs. Learning about #define from Kernighan and Ritchie's book has taught me to appreciate the importance of writing clean, understandable, and maintainable code—a skill that's essential for any budding programmer like myself.

While #define is a powerful tool, it’s important to use it wisely. Overusing it or using it incorrectly can lead to code that is hard to debug and maintain. As I continue to learn, I aim to apply these principles to write code that is not only functional but also elegant and efficient.

I want to work with C

Yeldar Kudaibergen — Fri, 09 Aug 2024 17:00:00 PDT

Reading the book by Kernighan and Ritchie on the C language, I am beginning to realize how powerful and flexible this language is. One of its main goals was to provide maximum control over memory and program execution efficiency. While I understand this from the text, I am starting to grasp the concept more deeply as I read on.

Today, I encountered an interesting point: it turns out that the assignment operation in C returns the value itself, not the assignment status, as I had assumed. At first, this seemed illogical to me. However, after researching online, I understood that this design makes sense in the context of low-level programming, where minimizing the number of operations and efficiently working with expressions is crucial.

The C language assumes that the programmer knows exactly what they are doing and does not attempt to guess their intentions. C requires a deep understanding of its features, and I believe no one can explain it better than the authors of the language themselves. I am glad I found Kernighan and Ritchie's book from 1992 in the library. The examples from the book still work exactly as intended — it's impressive.

Finding the Greatest Number in C

Yeldar Kudaibergen — Tue, 06 Aug 2024 17:00:00 PDT

When programming, a common task is to find the greatest of three numbers. There are several ways to achieve this in C. In this blog post, we will explore multiple methods to solve this problem, ranging from simple conditional statements to using standard library functions.

Basic Approach Using Nested `if` Statements

The most straightforward way to find the greatest number among three given numbers is to use nested if statements. Here's how you can do it:

#include <stdio.h>

int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int greatest_number(int a, int b, int c) {
    if (a > b) {
        if (a > c) {
            return a;
        } else {
            return c;
        }
    } else {
        if (b > c) {
            return b;
        } else {
            return c;
        }
    }
}

This method works well, but it can be made more concise.

Using Ternary Operator

A more compact way to write the function is by using the ternary operator:

#include <stdio.h>

int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int greatest_number(int a, int b, int c) {
    return (a > b) ? ((a > c) ? a : c) : ((b > c) ? b : c);
}

This approach reduces the number of lines and makes the code more readable.

Using Standard Library Functions

If you can use the standard library, leveraging fmax from math.h can simplify the function:

#include <stdio.h>
#include <math.h>

int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int greatest_number(int a, int b, int c) {
    return (int)fmax(fmax(a, b), c);
}

This method uses fmax to compare two numbers at a time, returning the greatest.

Using an Array and Loop

Another way is to put the numbers in an array and iterate through it to find the maximum value:

#include <stdio.h>

int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int greatest_number(int a, int b, int c) {
    int arr[] = {a, b, c};
    int max = arr[0];
    for (int i = 1; i < 3; i++) {
        if (arr[i] > max) {
            max = arr[i];
        }
    }
    return max;
}

This approach is useful if you need to handle a larger set of numbers dynamically.

Using Utility Functions

Creating a utility function to compare two numbers and then using it can also be effective:

#include <stdio.h>

int max(int x, int y);
int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int max(int x, int y) {
    return (x > y) ? x : y;
}

int greatest_number(int a, int b, int c) {
    return max(max(a, b), c);
}

This method promotes code reuse and can be extended easily.

Using Non-Nested Conditions

Finally, using non-nested conditions can make the function easier to read:

#include <stdio.h>

int greatest_number(int a, int b, int c);

int main() {
    printf("%d\n", greatest_number(32, 233, 3333));
    return 0;
}

int greatest_number(int a, int b, int c) {
    if (a > b && a > c) {
        return a;
    } else if (b > c) {
        return b;
    } else {
        return c;
    }
}

This approach avoids nested conditions, making the logic clearer.

Conclusion

Finding the greatest of three numbers in C can be accomplished in various ways. The choice of method depends on your specific needs and preferences. Whether you prefer the simplicity of nested if statements or the compactness of the ternary operator, understanding these different approaches can help you write more efficient and readable code.

Feel free to experiment with these methods and choose the one that best suits your style and requirements!

The Asterisk * Operator in C

Yeldar Kudaibergen — Thu, 23 May 2024 17:00:00 PDT

The asterisk * operator in the C programming language is a versatile symbol with multifaceted applications. Understanding its usage across different contexts is essential for proficient programming and efficient code development.

Pointers: Pointers are fundamental in C programming, allowing manipulation of memory addresses and data. The asterisk * symbol is employed to dereference pointers, enabling access to the value stored at a particular memory address. This dereferencing operation is crucial for tasks such as dynamic memory allocation, data traversal, and passing data by reference to functions.

Multiplication: In arithmetic operations, the asterisk * serves as the multiplication operator. It is used to perform multiplication between numerical operands, yielding the product of the two values. While seemingly straightforward, understanding operator precedence and the order of operations involving the asterisk * is essential for accurate mathematical computations.

Input-Output Operators: Within input-output operations, such as printf and scanf, the asterisk * is used as part of format specifiers to specify the formatting of input and output data. For instance, %\*d in printf allows formatting of an integer with a variable field width, providing flexibility in output formatting.

Function Pointers: Function pointers are pointers that point to functions rather than data. The asterisk * is crucial for dereferencing function pointers, allowing the invocation of the function they reference. This feature is particularly powerful in scenarios where functions need to be passed as arguments to other functions or stored in data structures.

Memory Allocation: Dynamic memory allocation functions like malloc, calloc, and realloc are essential for managing memory dynamically at runtime. The asterisk * is used in conjunction with these functions to specify the type of data for which memory is allocated. Proper memory management, including allocation and deallocation, is critical for preventing memory leaks and optimizing resource utilization.

Pointers to Pointers: Pointers to pointers, also known as double pointers, add another layer of indirection in memory management. The asterisk * is utilized for dereferencing double pointers to access the value or address pointed to by the pointer to a pointer. This concept is often encountered in scenarios where functions need to modify pointer variables or dynamically allocate multi-dimensional arrays.

Arrays and Pointers: In C, arrays and pointers exhibit close relationships, with arrays being essentially pointers to their first elements. The asterisk * can be used to access array elements through pointer arithmetic or dereferencing. Understanding the equivalence between arrays and pointers is crucial for efficient data manipulation and memory access in C programming.

Variadic Functions: Variadic functions, which accept a variable number of arguments, are prevalent in C programming. The asterisk * is utilized within these functions to access additional arguments through a pointer to the argument list. Proper handling of variadic functions requires understanding the structure of the argument list and ensuring that arguments are retrieved and processed correctly.

Mastering the asterisk * operator in C programming unlocks a wealth of capabilities, from efficient memory management and dynamic data structures to flexible function handling and precise arithmetic operations. By delving deep into its diverse applications and understanding its nuances, programmers can harness its power to write robust, efficient, and maintainable code.

The dilemma of first programming language to learn: resolved

Yeldar Kudaibergen — Thu, 23 May 2024 17:00:00 PDT

I would like to share my experience of overcoming the challenge of choosing a first programming language to learn. This is a hurdle that many of us face when embarking on our programming journey. I hope my experience can shed some light on this common dilemma. When I first started learning to program, I felt overwhelmed by the multitude of languages and paths to choose from.

My initial attempt at learning through a combination of paid and free courses did not yield the desired results. I experienced a degree of discouragement, but I was determined to identify the optimal path. I decided to pursue web development and enrolled in a comprehensive course covering HTML, CSS, and JavaScript. While it provided a solid foundation in web development, I yearned for a deeper understanding of the underlying principles of programming.

This pursuit of deeper knowledge led me to self-study, where I explored JavaScript, HTML, and CSS through various open courses. However, it wasn't until I ventured into Ruby that I began to grasp the intricacies of programming on a more profound level. Ruby's elegant syntax and powerful features sparked my curiosity and propelled me further into the world of programming.

After careful consideration, we have determined that Python, rather than Ruby, is the optimal choice for achieving my long-term goals. I have identified an online course on the fundamentals of programming in Python from the University of Helsinki that aligns with my needs. My mentor has approved this course and we have set a goal to complete part 12.

In the course of our discussion, an interesting development occurred: my mentor suggested that I work on exercises in both Python and C. He believes that learning both languages will offer a more comprehensive understanding of programming.

Thus, the proposed solution to the dilemma of choosing a first programming language is as follows: select a language and course that suits you. At this stage, it doesn’t matter whether the course is online or offline. Then, study this language in parallel with C. The learning process would look like this:

Read the theory on your chosen programming language (language 1).
Thoroughly review the course assignment.
Complete the assignment in C.
Complete the same assignment in language 1.

Here’s why I believe this parallel approach can be highly beneficial:

Studying two languages simultaneously allows you to see how different languages address the same problems, which can lead to a deeper understanding of programming concepts and principles.
Learning both Python and C in parallel can create a synergy where insights gained from one language enhance your understanding of the other. This can make complex concepts more accessible and intuitive.
Engaging with both high-level (Python) and low-level (C) languages can help you better grasp abstract concepts and practical details, making it easier to tackle challenging programming tasks.
The variety in tasks and approaches when learning two languages can keep the process dynamic and engaging, preventing monotony and maintaining motivation.
Real-world programming often requires familiarity with multiple languages and technologies. By learning them in parallel, you prepare yourself for this reality, making you more versatile and adaptable.

This approach will help you gain a deeper understanding of fundamental programming concepts and see how these concepts are implemented at different levels of abstraction. This method has truly helped me not only to better understand programming but also to increase my confidence in my skills.

Links:

Full Stack Open, University of Helsinki;
The Odin Project;
Ruby Is For Fun book;
Python Programming MOOC 2024 University of Helsinki.

Why does scanf require memory addresses while printf does not?

Yeldar Kudaibergen — Thu, 23 May 2024 17:00:00 PDT

In C programming, the functions scanf and printf serve different purposes when it comes to input and output operations. One thing that sets them apart is how they handle variable arguments, especially in regard to memory addresses.

The scanf function is mainly used for input, where it reads data from the user and stores it in variables. So, to achieve this, scanf requires the memory addresses (pointers) of the variables where the input values will be stored. This is because scanf needs to know where in memory to write the input values that it reads from the user. By passing the memory address of a variable to scanf, the function can directly write the user input to that memory location.

On the other hand, the printf function is used for outputting data to the console or to a file. Unlike scanf, printf doesn't need to modify the variables passed to it as arguments. It simply displays the values stored in those variables, so it doesn't require memory addresses as arguments because it doesn't need to write anything to those memory locations.

It's really important for C programmers to understand the difference between passing a variable and passing its address. This helps them work with data in memory more effectively. When you explicitly specify the address of a variable in scanf, it makes the code more reliable and secure. This prevents unintended data writes to memory.

It's also really important to handle errors when using scanf. If you don't, you might end up with issues like passing the wrong data type or the wrong variable address. It's really important for programmers to be aware of these potential pitfalls and to properly validate input to ensure the correctness and robustness of their code.

Zero in C

Yeldar Kudaibergen — Thu, 23 May 2024 17:00:00 PDT

In the C programming language, the value 0 holds special significance and is interpreted differently depending on the context:

In conditional statements (such as if, while, etc.), the value 0 is interpreted as "false," while any non-zero value is interpreted as "true." For example, if (0) will always evaluate to "false", and the code block inside this statement will not be executed.

C lacks a built-in boolean data type, as found in more modern programming languages. Instead, integer values are used, where 0 represents "false" and 1 (or any non-zero value) represents "true". The C99 standard introduced the _Bool type, along with the <stdbool.h> header file, which allows using bool as an alias for _Bool, and true and false as macros for 1 and 0, respectively.

The value 0 for pointers is interpreted as a "null pointer," indicating that the pointer does not point to any object in memory. The NULL macro is typically used for this purpose in standard C libraries.

In functions, the value 0 is often used as an indicator of successful completion. For instance, the main function usually returns 0 upon successful program termination. Standard C library functions also commonly return 0 on success and a non-zero value on error.

In an arithmetic context, 0 simply represents zero, a number without value. When added to any number, it does not change its value, and when multiplied by any number, it yields 0.

Understanding the context of zero usage helps avoid errors and improve code readability. It's important to be consistent and clearly define its value in each context to avoid misunderstandings and unexpected results.

About While loop in C.

Why does C have a while loop?

Yeldar Kudaibergen — Tue, 21 May 2024 17:00:00 PDT

The C programming language is renowned for its efficiency, flexibility and control. One of the key constructs that contributes to these characteristics is the while loop. But why does C have a while loop, and what makes it so important? In this article, we'll explore the various reasons and benefits of the while loop in C.

while (condition) {
    // code to execute
}

One of the main reasons why C includes the while loop is to simplify repetitive tasks. There are many situations in programming where a block of code needs to be executed several times. The while loop provides an easy way of repeating a set of instructions until a particular condition is met. This eliminates the need to manually copy and paste code, thereby reducing errors and making the code more maintainable.

The while loop improves code readability by clearly indicating the start and end of a repeating section of code. With a simple syntax, it makes it easier for developers to understand the flow of the program. For example, the condition within the while statement explicitly shows when the loop will continue, making it intuitive for others to follow the logic.

The while loop in C provides flexibility in specifying loop conditions. Unlike other loop constructs, the while loop allows for conditions that can be checked before entering the loop. This is particularly useful in situations where the number of iterations is not known in advance. The loop continues to execute as long as the condition remains true, providing dynamic control over the flow of execution.

Another reason C includes the while loop is for better control over program flow. The while loop allows for easy integration of control statements such as break and continue, enabling precise management of how and when the loop should terminate or skip iterations. This control is crucial for writing robust and efficient programs.

The while loop is resource-efficient, especially in scenarios where initialization and increment steps are not required. By focusing solely on the condition and the loop body, the while loop can be more efficient in terms of both memory and processing power. This efficiency is vital for systems programming and applications where performance is a key concern.

The versatility of the while loop makes it suitable for a wide range of applications. From simple scripts to complex system software, the while loop can be used to handle various tasks, such as waiting for user input, monitoring system states, and managing background processes. This versatility ensures that the while loop remains a fundamental tool in the C programmer's toolkit.

Finally, the while loop aids in debugging and testing by allowing specific sections of code to be executed repeatedly under controlled conditions. This repetitive execution helps in isolating and identifying bugs, as well as in testing the behavior of code under different scenarios. The simplicity and predictability of the while loop make it an ideal construct for these purposes.

Yeldar Kudaibergen

Learn programming through undestanding

Start a podcast before anyone listens

Why does C have so many compilers?

A deep cleanup of ProxyFeed

Is it a podcast? But why?

What is podcasting?

What is a podcast?

ProxyFeed devlog: funding tags, bug fixes

Cross-social networks

A clearer vision for ProxyFeed

ProxyFeed — a permanent URL for any RSS feed

Now AI is my Study buddy

One shortcut for copy and paste

Pointers in C made simple

Declaring variables and a pointer

Assigning the address of a variable to a pointer

Pointer dereferencing

Changing the value of a variable through a pointer

Important points

Does every memory cell in a computer have its own address?

About getchar() in C

Understanding #define in C

I want to work with C

Finding the Greatest Number in C

Basic Approach Using Nested if Statements

Using Ternary Operator

Using Standard Library Functions

Using an Array and Loop

Using Utility Functions

Using Non-Nested Conditions

Conclusion

The Asterisk * Operator in C

The dilemma of first programming language to learn: resolved

Why does scanf require memory addresses while printf does not?

Zero in C

Why does C have a while loop?

Basic Approach Using Nested `if` Statements