DEV Community: Manuel Mateo

Quick PSA: Programming is Difficult

Manuel Mateo — Sun, 22 Oct 2023 08:59:42 +0000

For some reason, I see a lot of beginners post something like this online: "I've been programming for a month now and it's still difficult. Is programming right for me?"

Newsflash: Programming is hard. Learning to program is hard. In fact, any skill is hard.

Let's take our statement from earlier and replace it with an instrument. Let's read it out together: "I've been [playing] the violin for a month now and it's still difficult. Is [playing] the violin right for me?"

To be frank, the statement now sounds kind of ridiculous. Unless you're a prodigy, of course the violin is still difficult, it's an instrument that requires years of practice.

Programming is no different. It's a skill. If you want to be good at programming, it requires years of hard work.

I think the reason why beginner programmers feel "stuck" is because the progress they make isn't immediately obvious. Let's go back to our violin example: our beginner violinist would have no difficulty in knowing what a good violinist sounds like, and there's a clear benchmark they can compare themselves to. It's not too difficult to hear when a violinist messes up a note, rushes a piece, or has a scratchy tone.

However, our beginner programmer has no clear benchmark. It's part of the reason why companies have a difficult time creating a good interview process: there's no clear, easy way to distinguish the quality between two programmers. To do so, you'd have to take a deep dive into their projects, methods, ability to break down problems, etc. Even then, it's still not easy, and there's a lot of nuances to consider.

That's not to say I don't empathize; every programmer has been there before. Every programmer has stared at a screen for hours and felt like they were deciphering a set of ancient texts. Every programmer has felt frustrated out of their mind, only to solve the problem days later. We've all been there, and it's okay to feel frustrated.

Yes, programming is hard, but it's not impossible. Stick with it, and good luck.

There's a wonderful article by Peter Norvig about how to teach yourself programming in ten years.

Formalizing C Patterns: The Case for C++

Manuel Mateo — Sun, 16 Apr 2023 17:34:56 +0000

Background

Online, I see a lot of discourse surrounding C and C++. It makes sense; both languages are related, and they fit very similar niches. C programmers typically describe C++ as bloated, overcomplicated, obtuse, and so on.

Here's one of the most famous examples of a C programmer arguing against C++, by one of the most famous programmers of all time: Linus Torvalds. As seen in Torvalds' rant, one key piece missing from these discussions are concrete, technical arguments. Although Torvalds is a far better programmer than I am, his argument features charged language with non-concrete examples.

This article serves as a way to document my own thoughts on the subject matter, explicitly states concrete arguments, and is a time capsule for future me to look back on.

My Take

C++ can do everything that C can, but the opposite is not true.

In online discussions, people tend to forget that C++ is the natural evolution of C. If C is bulbasaur, C++ is ivysaur. Because C++ did not come out of thin air, and because it does not aim to replace C, C++ borrows, formalizes, and improves plenty of common C techniques and paradigms.

Formalizing?

C++ wasn’t created in a vacuum. It was created after years of C programming, meaning C++ had a lot of experience in what patterns worked and what didn’t. It moved these design patterns into formal language features instead of letting the users hand roll them.

This means that good C code tends to be a more primitive version of good C++ code.

Generic Objects - C

Imagine I wanted to create a library to represent a two element vector. So, I create a struct containing two integer elements:

typedef struct vec2_t
{
    int x; 
    int y;
} Vec2;

Awesome, I can now represent a vector in my code.

But wait, wouldn’t it be useful to define some common operations?

For brevity, we’ll only implement addition, but you get the idea:

Vec2 add(Vec2 v1, Vec2 v2)
{
    Vec2 result = {0, 0};
    result.x = v1.x + v2.x;
    result.y = v1.y + v2.y;
    return result;
}

But wait, what if I want to support floats too? Or long ints? Or doubles?

I could do some void* voodoo, but macros would work here too.

#define DECL_VEC2(typename, type) \
typedef struct typename##_t { \
    type x, y;\
} typename; \
\
typename typename##_add(typename v1, typename v2) { \
    typename result;\
    result.x = v1.x + v2.x;\
    result.y = v1.y + v2.y;\
    return result;\
}

Sweet, we’ve created a generic data structure to represent a two element vector.

There's still an issue with this; what about BigInts? Or custom, fixed-point types? All of a sudden, I'd need to change my add operation function to accept a third add function parameter.

Let’s identify what makes this good C code:

We have a good interface to interact with our structure
Our structure is generic, meaning we can reuse our code without duplicating it for other types.

Generic Objects - C++

C++ looks at what went right and formalizes it though the language and type system.

The proper way of doing what we did in the C code would look something like this:

template <typename T>
struct Vec2
{
    T x, y;

    static Vec2<T> add(Vec2<T> v1, Vec2<T> v2)
    {
        Vec2<T> result;
        result.x = v1.x + v2.x;
        result.y = v1.y + v2.y;
        return result;
    }
};

In this example, we have the help of the compiler to enforce type safety, and we don't have to deal with macros. C++ formalizes the generic object pattern into a built-in language feature.

We also don't need to worry about passing in an add function to our code. Why? Because operator overloading exists, and the + operator should be defined for the type passed in. Using traits, we can even expand the code to check if T implements the operator and report errors at compile time. Sweet.

Cleanup - C

Contrary to common belief, in C, goto can actually be quite useful.

When we're dealing with lots of memory allocations, often times we need a way to bail out of a function that has reached an error state:

void some_func(const char* filename)
{
    FILE* file = fopen(filename, "r");
    if (!file)
        goto no_cleanup;

    fseek(file, 0L, SEEK_END);
    int file_size = ftell(file);

    char* buffer = malloc(file_size);
    if (!buffer)
        goto cleanup_file;
    FILE* out_file = fopen("outfile", "w");
    if (!out_file)
        goto cleanup_buffer;

    // no errors, free to continue with operations

cleanup_buffer:
    free(buffer);
cleanup_file:
    fclose(file);
no_cleanup:
    return;
}

Here, we've organized our code in a way where we bail out of normal execution into our cleanup code if we encounter any problems. Without goto, our code would be a mess of nested if statements, increasing depth every time we add a new resource.

Cleanup - C++

C++ once again formalizes a good C pattern. In this case, the formalized pattern is called RAII.

In C++, we can use RAII to cleanup objects at the end of their lifetimes.

void some_func(const std::string& filename)
{
    std::fstream file(filename);
    if (!file)
        return;

    std::string buffer;

    std::fstream out_file("outfile");
    if (!out_file)
        return;

    // do stuff
}

Notice how here we don't have any cleanup labels. This is because (well formed, memory owning) objects have destructors that automatically handle cleanup for us. If we have an error state in our do stuff area and need to bail out, we know our code will still cleanup our resources.

Data Hiding - C

When reading files, it's useful to have a dynamic array of strings, with each index representing a line of the file. Let's look at a simple C example:

typedef struct dynamic_string_array_t {
    int size;
    int capacity;
    char** arr;

} DynamicStringArray;

DynamicStringArray* DynamicStringArray_new(int capacity)
{
    DynamicStringArray* dyn_arr = malloc(sizeof(DynamicStringArray));

    dyn_arr->size = 0;
    dyn_arr->capacity = capacity;
    dyn_arr->arr = malloc(sizeof(char*) * capacity);

    return dyn_arr;
}

bool DynamicStringArray_push_back(DynamicStringArray* this, char* str)
{
    if (this->size == this->capacity)
    {
        int new_size = this->capacity * 2;
        this->arr = realloc(this->arr, new_size);
        this->capacity = new_size;

        if(!this->arr)
            return false;
    }
    this->arr[this->size] = str;
    this->size++;
    return true;
}

Of course, we'd need to define the other functions to operate on our dynamic array, but this works as a good example.

There is an issue: there's nothing stopping another programmer from going in and misusing our dynamic array by changing the fields. If they directly change any of the fields in our struct, we'd run into potential UB or an outright crash.

The most naive way to "hide" our data is to not hide it all. Instead, we could prefix our fields with a single underscore to indicate that the field should be considered private. However, that's not effective.

The "best" way to hide our data is to make our struct an opaque struct. An opaque struct is one that completely hides all fields by only being accessible through a pointer.

To accomplish this, we typedef the name of the struct in our header file, and keep the implementation of the struct in the source file.

DynamicStringArray.h:

typedef struct dynamic_string_array_t DynamicStringArray;

DynamicStringArray* DynamicStringArray_new(int);
boolean DynamicStringArray_push_back(DynamicStringArray*, char*);

DynamicStringArray.c:

typedef struct dynamic_string_array_t {
    int size;
    int capacity;
    char** arr;

} DynamicStringArray;

// rest of our function implementations

Data Hiding - C++

In C++, the default way is easy: just mark the fields as private, or in the case of a class, don't mark the fields public. This allows our code to be header only, which can be nice.

class DynamicStringArray
{
    int size;
    int capacity;
    char** arr;

public:
    // define methods here
};

Did you see the error?

In the section "Data Hiding - C" I purposefully left a bug. Instead of allocating space and copying the contents of the char* parameter, I directly stored the pointer into the array. This is a bug; there is no guarantee that the string is properly managed. If our dynamic array outlives the string, then the pointer would point to garbage memory. If the string is not null-terminated, that would also lead to potential bugs.

In C++, we usually don't need to worry about string handling issues like this. Non-reference object parameters automatically call their respective copy constructors, meaning we wouldn't need to worry about copying our string. On top of that, std::string manages the contents of our string, meaning we don't need to worry if the internal array is null-terminated or not (unless constructing from a char*).

Wrapping Up

The list goes on, seriously. I could've talked about:

Signals and errno, return codes vs Exceptions
Custom pointer and size structs vs Spans
Bit set macros vs std::bitset
Compile time facilities
char vs std::string
Etc, etc, etc.

But at that point, this article would turn into a short book.

I'd like to reiterate my earlier point: C++ can do everything that C can. If you take issue with any of these features, there's nothing forcing you to use them. C++ features are opt in; if you don't want to use them, there's no penalty. Even if you use only 1 C++ feature, then it's worth the switch.

Dev Log: Extremely Basic OpenGL Renderer

Manuel Mateo — Sun, 26 Feb 2023 22:57:36 +0000

Some Background

Since the beginning of my programming journey, I’ve always been drawn to the idea of creating projects from the ground up with minimal third party code.

One of those projects was to play around with graphics, and this time I actually stuck with it.

Starting the Project

I decided to follow along the Learn OpenGL tutorial. Although I found it useful for code, some of its explanations weren't clicking with me.

I was confused on how vertex array objects (VAOs) and vertex buffer objects (VBOs) fit together, and given that they're the fundamental building blocks of OpenGL, I was in a bad place. Eventually, afters tons of googling and youtube, it finally clicked.

I think the reason I was struggling so much was because I didn't understand that VAOs and VBOs are fundamentally linked. See, VAOs not only hold the specified layout of VBOs, they also hold the VBO data itself. It's kind of weird (thanks state machine!), and newer versions of OpenGL separate out the formatting of the data and the actual binding of the data (see direct state access (DSA)).

Building out abstractions

Once I understood that VAOs and VBOs can't be separated out (in OpenGL versions below 4.5), this made programming an abstraction around them fairly trivial.

I started out with the most basic data, the vertex. I don't care about textures or even lighting for this first run at OpenGL, so for now my vertices contain only position information and color information.

struct Vertex
{
    std::array<GLfloat, 3> position;
    std::array<GLfloat, 3> color;

    // constructor and std::ostream& operator<< defined here
};

Great! I had a way to represent a single vertex, but you can't do much with that.

So, I created a class to represent a group of vertices.

struct Mesh
{
    std::vector<Vertex> vertices;

    // constructors
};

There's something missing. See, in OpenGL, because everything is defined as a set of triangles, sometimes you'll get some overlap. Imagine the face of a cube:

1-----2
|     |
|     |
3-----4

The two triangles that make up the face are: 123, 324.

That's kind of a waste, right? We shouldn't have to define duplicate vertices.

Luckily, OpenGL solves that by introducing element buffer objects (EBOs). EBOs hold indices, meaning that we don't need to duplicate our vertices in memory.

So, the new Mesh struct looks like this:

struct Mesh
{
    std::vector<Vertex> vertices;
    std::vector<GLushort> indices;

    // constructors
};

Great! I can now represent the vertices and indices of a mesh.

But now I need a way to actually send these vertices and indices to OpenGL.

So, I created a Model class. This class represents a Mesh and its OpenGL data too, including VBOs, VAO, and EBO.

class Model
{
    Mesh m_mesh;
    GLuint m_vao;
    GLuint m_vbos[2];
    GLuint m_ebo;

    // constructors, convenience functions, destructor
};

Lastly, I needed a way to actually draw the Model to the screen and keep track of the models.

I decided to create a Renderer class to keep track of camera matrices and handle all of the drawing. That way, I could keep my Model separate from the drawing code.

class Renderer
{
public:
    std::list<std::unique_ptr<Model>> models; 
    int mode; // GL_POINTS, GL_TRIANGLES, or GL_LINES
    // other members excluded for brevity, but shader is included

    // constructor

    // function to add model to models

    void draw_models()
    {
        // clear the screen, color buffer, and depth buffer
        // use the shader
        // setup view matrices
        // setup shader uniforms
        for (const auto& model : models)
        {
            glBindVertexArray(model->m_vao);
            glDrawElements(mode, model-m_mesh.indices.size(), GL_UNSIGNED_SHORT, 0);
            glBindVertexArray(0);
        }
    }

};

Loading Models from Files

I had the foundation of a renderer, but it's quite boring if I was staring at an empty screen the entire time.

So, I decided to create a function to load a .obj file into a Model.

Luckily, the file format is fairly simple, it looks something like this:

v 0.5. 0.5 0.5
...
vt 1.0 1.0
...
vn 1.0 1.0 1.0
...
f 1 2 3

v denotes the vertex positions (x, y, z).
vt denotes texture coordinates, which I ignored to keep things simple.
vn denotes the surface normals, which I also ignored.
f denotes the indices of the triangles.

So, I created a function to loop through all of the lines and either add the vertices and indices to vectors.

However, I did run into two subtle bugs that were easy to fix:

The indices are 0 indexed, not 1 indexed, so when adding the indices to the the vector I had to subtract 1.
Some lines of the face actually define quads instead of triangles, so the line looks like:

f 1 2 3 4

After fixing the two bugs, I had a passable .obj loader I could use.

Finishing Touches

Once that was done, I decided to add some command line arguments, mainly to specify the .obj file to load, specify the mode to render with (GL_POINTS, GL_LINES, or GL_TRIANGLES), and the ability to change the camera's distance from the model.

Here's the classic Utah teapot rendered as a wireframe:

Here’s the link to the GitHub repo.

Final Thoughts and Next Steps

Overall, this was a fun project. It was nice to get something visual done, and I'm glad I finally understand how OpenGL work.

I'm not particularly happy with the code, mainly the argument parsing and the raw glfw calls I make in main(), but I'm glad it works.

Outside of main(), I do think the abstractions I made over the vertices and OpenGL itself isn't too bad, and in a future renderer I'll probably work off of this foundation.

There are two features I'd like to add to this renderer:

The ability to specify model color in the command line args
Basic lighting

Once (or if) I get those done, I think I'll leave the project as-is. It was a great learning experience, and it'll be interesting to see how any future renderers I make compare to this one.

In the future, I'll probably try to look into Vulkan, I'm interested in the fact that the API --although much more verbose-- looks a whole lot cleaner than OpenGL.

Tips for other OpenGL beginners

Don't attempt to learn OpenGL if you don't know memory management and how pointers work, you will have a bad time.
OpenGL 3.3 is a bad API due to its state machine. If possible, try to learn OpenGL 4.5+ (yes, I know tutorials are sparse, but it seems easier to learn)
VAOs and VBOs are linked due to the state machine architecture, there's no real way to separate them out.

The Key to C

Manuel Mateo — Thu, 01 Dec 2022 04:35:34 +0000

C for Beginners?

Let's be clear here: no matter the popularity, C is a difficult language for beginners. To truly understand C, beginners have to learn both about programming and hardware, two very deep and complex topics.

In this article, I'll attempt to bridge the two.

Some background: Types? What are they?

A type is simply a description of a variable. More precisely, a type describes what operations can be performed with the given data.

The Key to C: Types are an Illusion

To truly understand C, one must view an entire program in terms of operations on interpretations of raw data.

Operations on interpretations of raw data? What does that mean?

Let's break that down with an example:

A char isn't just a single character, it's an interpretation of the data one byte holds. For example, this block of code is perfectly valid:

char x = '2';
char y = '2';

char z = x + y;
printf("%d\n", (int)z); // Outputs '100'

Again, char is just an interpretation of the data. Sure, most of the time, a char refers to an actual character, but the only guarantee C gives us is that a char is exactly one byte.

In the example code, I performed an operation (addition) on raw data, even though the data is interpreted as characters. In ASCII, '2' is represented by the decimal number 50.

Viewing types as illusions simplifies all of the more difficult topics in C.

Sure, you can view an int is a number, but then what is an int*? It points to a number? What does that even mean?

Or, you can view an int is a (typically) 4 byte block of memory on the stack, and an int* holds a number that is usually the address of a (typically) 4 byte block.

Yes, it's a mouthful, but until this line of thinking becomes intuitive, it's important to break down components of a program in that manner to truly understand C.

If C hasn't clicked for you yet, try viewing your programs in the way I've described. You'll surprise yourself!

The Beginner's Axioms

Manuel Mateo — Mon, 27 Sep 2021 16:05:12 +0000

The Zen of Python

The Zen of Python is a collection of guidelines for writing software, primarily aims towards (you guessed it) Python. It's a short list, but its worth its weight in gold. The guidelines talk about issues like code structure and how a program should look.

The Beginner's Axioms

I thought it'd be fun to make my own list, which I dub The Beginner's Axioms. Its a short list of guidelines I wish I could've handed to myself when I first started learning how to program.

Learn slowly, forget slowly
Writing is better than reading.
When reading, official is better than unofficial.
Bad code is better than no code.
Mistakes are better than no mistakes.
The first step to fixing a problem is admission.
Community is better than solitude.
Comments, comments, comments.
Experiment, experiment, experiment.