DEV Community: Kyle

The Power of OOP

Kyle — Thu, 04 Sep 2025 19:19:59 +0000

I personally know somebody that has broken production, which cost their company hundreds of thousands of dollars in a matter of hours. Definitely not a good look, but this didn't happen because of them, it happened because that person's IT Director and senior engineer were completely fine without unit or component tests in the front end. As developers, we're really only as good as the systems we find ourselves in. Regardless, I know that person felt terrible about what happened. Still, however horrible they must have felt, it couldn't have been any worse than the Lockheed Martin engineer that introduced a $500 million dollar bug in 1998.

$500 Million Down the Drain

On December 11, 1998, the Mars Climate Orbiter took off for space from the launch pad in Cape Canaveral near Orlando, Florida. A year later, the Orbiter dove into Mars' atmosphere at a top speed of 12,000 mph and the orbiter was likely ripped apart in seconds. All communication with the orbiter was lost and $500 million dollars was flushed down the drain. The work of 200+ engineers, many of whom considered this their life's work, was gone. While tragic at the time, this story provides a lesson that highlights one area of software engineering where I think the magnitude of its importance goes overlooked.

The Origins of C++ Object Orientation

If you're a developer, you know what object-oriented programming is and you know about the four pillars and how they can be used to keep our applications modular and flexible. Up until recently, I didn't truly understand what this "modularity" and "flexibility" provides for our applications. At its core, object-oriented principles give us a safety net, both literally and figuratively. If you know anything about the relation between C and C++, you know that C++ is basically C with object orientation. If you know that, you probably also know that the creator of C++ was none other than Bjarne Stroustrup, who was very intentional with what he wanted to achieve with his creation of an "object-oriented version" of C.

I recently completed Dr. Chuck's C Programming for Everybody course and ran into fascinating insights regarding the true impact of OOP within our software. In the last section, I learned about how, in theory, you could replicate object orientation in C and how languages like Python replicate object-oriented patterns and implementations for their data structures. In this last section of the course, there was a video where Bjarne was asked, "Why did you create C++ and what were you trying to achieve?" and he basically said he wanted to deliver true reliability for applications that need it the most. By "the most," Bjarne was referring to things that, if the software were to fail, could be the result of life or death for human beings or result in catastrophic events such as the collapse of the Mars Climate Orbiter.

Bjarne, in addition to using the Mars Climate Orbiter example, mentioned the systems that our phones and cars run on. What if the software running our cell phones goes out? People might not be able to reach 911. And the brakes in our cars? We wouldn't want those to go out. These are just a couple of the scenarios that Bjarne built C++ for, which I think create a palpable feeling of their importance to us. If you're a programmer, this makes you appreciate the reason behind object-oriented principles (including interfaces) beyond just memorizing them for a job interview.

The Mars Climate Orbiter

The two main companies involved in the launch and management of the Mars Climate Orbiter were none other than Lockheed Martin (located in Denver, Colorado) and NASA's Jet Propulsion Laboratory (JPL) (located in Pasadena, California). In typical space-exploration scenarios, everything is measured in metric units. In this scenario, the specifications for the project called for metric units, but Lockheed Martin wrote code that would send imperial units to NASA at which point NASA would insert these units into their model (which expected metric units). When NASA thought the orbiter was in Mars' orbit, it was actually in the atmosphere, which was irrecoverable.

Throughout the process, it was Lockheed Martin's job to control the "attitude" of the orbiter, which is basically just the direction it's facing. For example, you are looking at a computer screen right now. You would change the attitude of your head by keeping it in the same spot but just twisting your neck to the left or right. In space, when Lockheed Martin adjusted the attitude, that would affect the momentum of the orbiter, which was measured as an "impulse". Lockheed would store information about the "impulse" in a file, send it to NASA over their internal networks, and then NASA would process that data into their "orbital dynamics model."

In the postmortem of the incident, it would have been easy to point a finger at Lockheed considering that the specs called for metric units. However, software development is a two-way street, so both parties correctly took ownership.

The Fix

In Bjarne's own words, "This could have been avoided by an ever so slight improvement in the interfaces between the parts of that program." So, what might this have looked like in practice? Since C# is my go-to, we'll roll with that here. If you're not interested in the code, skip past this section for a high-level overview.

In physics terms, Impulse (J) = Force (F) × Time (Δt).

The following is a BAD example from the vantage point of Lockheed Martin where they would have passed a naked double into the impulse generator and then sent that information to NASA's model—no way of checking the unit of measurement for the incoming value:

public static class LockheedBad
{
    public static double GetThrusterForce() => 55.0;   // lbf, but type says nothing
    public static double GetBurnDuration() => 2.0;     // s
    public static double ComputeImpulse() => GetThrusterForce() * GetBurnDuration(); // 110 (lb*s)
    public static void WriteImpulseForNasa()
        => System.IO.File.WriteAllText("impulse.txt", ComputeImpulse().ToString());  // "110" with no unit
}

On the flip side, the following would be a GOOD example of what Lockheed could and should have done. If you plan on looking at the below code, just focus on the IQuantity interface, the enums, and the Force and Impulse structs, as these were the main areas of concern in this example and show how type safety might have been implemented.

In theory, there are 3 main steps that would have been taken in this process (in actuality, this is not what happened):

Lockheed would verify the units of measurement in their own system using the IQuantity interface to set the value of force and to SI units, no matter which unit of measurement was being used as the generic type. Then, that Force, which would be certain to be in SI units, would be used to calculate the impulse.
Lockheed would pass the impulse data to NASA. In the below code, the unit of measure is included with the value in whatever data transfer method they used (JSON, XML, a file, a message, Protobuf, etc.).
NASA would receive this information (value of impulse and unit of measurement) and they would implement a similar type-checking interface. If both Lockheed and NASA were using the same language, they could have used the same library to do this.

using System;
using System.Text.Json;
using System.Text.Json.Serialization;

// Shared contract: "every quantity must expose its SI value"
public interface IQuantity<TUnit>
{
    double ValueInBaseUnit { get; }   // stored in SI (base unit)
}

public enum ForceUnit { Newton, PoundForce }
public enum TimeUnit { Second }
public enum ImpulseUnit { NewtonSecond, PoundForceSecond }

public readonly struct Force : IQuantity<ForceUnit>
{
    public double ValueInBaseUnit { get; }   // Newtons

    private Force(double newtons) => ValueInBaseUnit = newtons;

    // Caller must declare the unit; constructor converts to SI (Newtons).
    public static Force From(double value, ForceUnit unit) => unit switch
    {
        ForceUnit.Newton     => new Force(value),
        ForceUnit.PoundForce => new Force(value * 4.4482216152605),
        _ => throw new ArgumentOutOfRangeException(nameof(unit))
    };
}

public readonly struct Duration : IQuantity<TimeUnit>
{
    public double ValueInBaseUnit { get; }   // Seconds

    private Duration(double seconds) => ValueInBaseUnit = seconds;

    public static Duration From(double value, TimeUnit unit) => unit switch
    {
        TimeUnit.Second => new Duration(value),
        _ => throw new ArgumentOutOfRangeException(nameof(unit))
    };
}

public readonly struct Impulse : IQuantity<ImpulseUnit>
{
    public double ValueInBaseUnit { get; }   // Newton-seconds

    private Impulse(double newtonSeconds) => ValueInBaseUnit = newtonSeconds;

    public static Impulse From(double value, ImpulseUnit unit) => unit switch
    {
        ImpulseUnit.NewtonSecond     => new Impulse(value),
        ImpulseUnit.PoundForceSecond => new Impulse(value * 4.4482216152605),
        _ => throw new ArgumentOutOfRangeException(nameof(unit))
    };

    // Safe composition from Force × Duration (already SI inside those)
    public static Impulse From(Force force, Duration time) =>
        new Impulse(force.ValueInBaseUnit * time.ValueInBaseUnit);
}

At this point, Lockheed would have been able to use the structs (and methods within) that implemented the IQuantity interface. They would have then sent the correct data over to NASA, much like the below code:

// ================= Lockheed ground software =================
public static class LockheedGood
{
    // Hardware gives Lockheed lbf and seconds. Factories convert to SI on entry.
    public static Force ReadThrusterForce() => Force.From(55.0, ForceUnit.PoundForce); // 55 lbf
    public static Duration ReadBurnDuration() => Duration.From(2.0, TimeUnit.Second); // 2 s

    public static Impulse ComputeImpulse()
    {
        var F = ReadThrusterForce(); // internally stored in N
        var t = ReadBurnDuration();  // stored in s
        return Impulse.From(F, t);   // internally stored in N*s
    }

    // Handoff to NASA in canonical SI (N*s)
    public static void WriteImpulseForNasa()
    {
        var J = ComputeImpulse();
        var payload = new ImpulsePayload
        {
            value = J.ValueInBaseUnit,  // always N*s
            unit = "N*s"
        };

        string json = JsonSerializer.Serialize(payload);
        System.IO.File.WriteAllText("impulse.json", json);
    }

    public record ImpulsePayload
    {
        [JsonPropertyName("value")] public double value { get; init; }
        [JsonPropertyName("unit")]  public string unit  { get; init; } = "N*s";
    }
}

Conclusion

In hindsight, vision is 20/20, but this is a great example that shows how a simple interface, or lack thereof, could have completely changed the course of an entire project. At the end of the day, both NASA and Lockheed were at fault. If just one of the programs checked for the unit of measurement, this would have never happened. Again, hindsight is 20/20, but I think this is a really cool example that highlights the importance of object-oriented programming.

When building programs that humans rely on for survival, object orientation becomes a much more serious topic. This, at its core, is what Bjarne was trying to achieve back in the 1980s, and I think it's necessary to step back and appreciate the "why" behind much of what we're taught to know as developers, including OOP.

It's Pointers All The Way Down

Kyle — Wed, 09 Jul 2025 01:31:17 +0000

If you’re a Sturgill Simpson fan, you’ll get the reference. If not, you gotta' fix that.

I just wrapped up Part 3 of Dr. Chuck’s C Programming For Everybody, and while I had a basic grasp of pointers from working with linked lists, this section of the course really helped solidify my understanding of what’s happening under the hood. Coming from high-level languages, I had several “aha” moments, and I’ve distilled the most valuable takeaways. No fluff, just the essentials for anyone making the jump to low-level programming. If you're interested in such things, here we go:

Why I Think Pointers Could Seem Hard to Understand

From what I've heard and read, many people struggle with pointers. I don't think this is because pointers are confusing in and of themselves, but because pointers in everyday life aren't recognized as they should be. I feel this is because of the fact that we allow other things (besides non-computerlike pointers) in our physical world to represent two things having a connection.

For example, we humans write "1 2 3" and instantly think “oh, that's a list of numbers.” But under the hood, whether in computer memory or human thought, there’s some connection medium that is required to go from one thing (in this case a number) to the next. That "connection medium" is a pointer.

Put another way, let's say you have four dots: orange, blue, red, and green. They’re stuck to a wall - you can picture them in the room that you're in right now. Someone walks in and says, “that’s a list.” But nothing is connecting them, so to you, it's not. With the list of numbers, it's pretty commonly understood that those three numbers are connected to each other sequentially. With the four dots, there's no real "agreed upon" connector. Memory addresses are the same way, which is why you need pointers. You need something to say, “after this, go here. Then after that, go there. And then after that, go there." That, in essence, is any data structure you can imagine.

At the end of the day, I don't think this is an oversimplification. This is actually just how computers work.

Building a complex data structure is a completely different ballgame, but the core pointer idea stays the same. More on pointers and memory in a bit.

Freedom, Baby

C gives you the most freedom, but it also comes with the strongest probability of shooting yourself in the foot. Some of the deadliest bugs in history have come from the C programming language, mostly due to the deadly trap known as "buffer overflow".

CPU Architecture Demystified

While working with memory, I learned, or rather cemented the fact that when we see "x86" or "x64" architecture for a computer, that literally just refers to the size of the individual memory addresses.

"x86" = 32-bit addresses

"x64" = 64-bit addresses

In hindsight, this may seem obvious (and maybe a little boring) to some, but it's cool to officially cement this distinction in your brain after working directly with the CPU and memory.

More on Memory

You can think of memory as a giant array of addresses. It helped for me to visualize memory as a street of homes as far as you can see, except for the fact that there aren't any houses facing each other, it's just houses back to back to back to back, for as far as you can see (not infinity, unless you're Google Cloud or Azure or something). I stole that "street" analogy from Reddit, which is where the light bulb clicked for me. I think once the actual structure of computer memory is realized, understanding a computer and programming becomes so much more fun (and interesting).

Understanding Pointers = Baller Status

Pointers aren’t just a theoretical flex. I recall people, even mentors of mine, talking about pointers like they were some elite-level concept. That's one of the reasons I took this C course. Pointers were supposed to be the final infinity stone in my chamber. I was planning on taking over the world after learning C and the pointers that came with them. I would become the supreme ruler of the world! Truth is, I'm a little disappointed. I thought they would be harder to learn, even including the use of them when it comes to connecting structs together for things like linked lists and hashmaps (dictionaries if you're coming from C#). To my surprise, it all kind of quickly came together (relative to the majority of headaches I've faced while learning to program), which is weird because pointers are actually very powerful and I feel like knowledge of them unlocks so many possibilities for what you can do with a computer. At the end of the day, pointers are just memory address of variables that are used to mainly to tie things like lists, dictionaries, and other data structures that represent our world, together.

In addition to pointers being the foundation of all data structures, another reason understanding pointers is beneficial is because programs/functions/methods/routines (whatever you want to call them) become extremely dynamic. You can modify many variables or members in one function. Put another way, you can return more than one thing from a function.

More on the CPU

At some point, you’ll probably ask: Why not just pass everything by value? Wouldn’t that be simpler?

Turns out, copying large structs by value can waste both CPU cycles and stack memory. That’s where pointers come in as they let you work directly with memory addresses, avoiding expensive copies and enabling more memory-efficient code.

The trade-off? Pointer-based code gives you control and efficiency but comes with more complexity and room for bugs. And in embedded systems, finding that balance is half the game. That’s the kind of challenge I’m starting to really enjoy.

Wrapping up

Pointers aren’t magic—they’re just how computers connect the dots, literally. Once you see memory as one long street of addresses and pointers as the signposts, everything starts making sense. From linked lists to hashmaps, it’s all just clever memory navigation. C lays it bare: no safety nets, full control. And yeah, that means the power to build elegant systems—or blow your foot off with a buffer overflow. But that’s the thrill. Understanding pointers doesn’t just level you up—it unlocks the map to the machine.

C Programming from a High-Level Mindset

Kyle — Sun, 01 Jun 2025 16:40:39 +0000

Just finished up with Part 2 from Dr. Chuck's "C Learning For Everybody" and wanted to take a second to reflect. If you're interested about going to a low level language from a high level one, this article will give you some insight into some of things you might expect to learn. At the bare minimum, you'll come away with some great good for thought that'll continue to fuel your programming journey. Here are 8 insights I had throughout the past month and a half:

Base conversions in C

C, or at least some of the programming problems introduced in this course, will make you think about math (and really our entire world) differently. Writing a program that converts numbers between different bases (decimal, hex, octal, and binary) might very well throw your mind for a twist (it did mine). Converting between different bases manually is pretty straightforward, but writing a logical program get's a little tricky! When beginning to work with base 8 and 16, I honestly felt like I was working with an alien language. In a parallel hex-based universe, there's a $64 bill with Benjamin Franklin on the cover of it.

Using the -S flag

When compiling C code, you can add the -S flag to generate the assembly code. The output will vary depending on the CPU architecture you're targeting.

Understanding interpreters

I’ve heard it a million times, the difference between a compiled and interpreted language, but like anything in programming, you don’t really understand until you actually do it. You probably understand it conceptually: compiled languages do all the heavy lifting up front, while interpreted ones figure it out as they go, reading line by line. The lightbulb moment for me came when I wrote a function in C (not a real interpreter, but close enough) that read from stdin using fgets(), parsed each line with sscanf(), and executed operations based on that input. I essentially created a mini fake language and for the first time I could visualize how a language like C might go about reading and processing text input the same way an interpreter might handle JavaScript. If you understand compilation and interpretation at a high level, creating a pseudo-interpreter will give you a great low-level understanding of what's actually going on!

ASCII awareness

C really makes you understand ASCII. If you're a programmer, you've heard of it, but once you start writing C code, it becomes something you actually think about. You start to think like a computer. Letters aren’t just letters anymore - they’re numbers. For example, in C, the character 'W' isn’t just “W," it’s actually the number 87 in memory (its ASCII value). In C#, Java, Python, JavaScript, and other high level languages, you mostly think about characters by what they represent, not by how they’re stored. But in C, knowing what that 'W' really is under the hood becomes part of the way you write and reason about code. It’s definitely a shift in mindset when coming from a higher-level language.

No classes in C

No classes in C. If you're coming from C# or Python, this is going to be a bit of a system shock. If you want to group related data in C, you’ve got to use a struct. In C, data and behavior live in separate worlds: functions go in libraries, structs hold your data, and you manually keep it all wired together. In a typically OOP language, both the data and methods would be stored inside a class. I'll be learning more about this in the upcoming sections, so I'll keep you updated and hopefully provide some insight that will allow you to better differentiate and work between classes and structs.

Good documentation

This isn't really about C, but more about the documentation in the files of the C code written for the ESP-IDF that I came across. Maybe it's out there and I just haven't encountered it, but I really haven't seen anything as detailed. This isn't documentation on the logic but rather documentation on what different variables mean in plain English. I've been in many codebases where I look at the fields of data and have to jump through hoops to figure out what the hell their purpose is. Even in Microsoft .NET base libraries, the documentation of what the data fields represent isn't all that great. Regardless, the ESP-IDF in-code documentation was so good that I had to give it a shoutout. More codebase field declarations should be like this:

What a virtual machine really is

This might sound obvious, but a virtual machine isn't a machine at all. I feel like that needs to be said because computer science loves giving things names that sound way more physical than they actually are. A virtual machine is just a program, usually written in something like C, that simulates an entire computer. It's a fake computer running real programs on a real computer. Languages like C#, Java, and JavaScript all run on these virtual setups. C# uses the CLR. Java uses the JVM. JavaScript depends on the browser. Chrome uses V8. Firefox has SpiderMonkey. All of these are written in C and just sit there executing code under the hood. It’s easy to get caught up in all the “oohs” and “ahhs” of how clever everything sounds, but at the end of the day, it’s all just files and programs turning into processes. Nothing magical. Just code pretending to be a machine, running on an actual one. C is the backbone of it all.

Wrote a recursive function

Last but not least, I wrote my first recursive C function without any help from ChatGPT. While cool and all, recursion should rarely be used and, as stated by Dr. Chuck. It's really only necessary when dealing with problems that require some sort of tree.

Above are some highlights and realizations I made and hopefully they give you some insight into Dr. Chuck's course or just some of the revelations that you might encounter if you're coming from a high level language down to C. So far, I've completed up to chapter 4 (out of 8) in the original book. However, as stated by Dr. Chuck, things start to get powerful (and painful) at Chapter 5. I asked ChatGPT how much of C's power I've already gained to which it said that I've harnessed about 30-40% of C's power, but 60-70% of the "juicy" stuff is still left ahead. "The party is just getting started," ChatGPT said, "and you're at the front door. Chapter 5 is when the lights go down and the DJ shows up."