The year is 2025. The C programming language is something like 50 years old now - a dinosaur within the fast-moving environment of software development. Dozens of new languages have cropped up through the years, with languages like Rust and Go as prime contenders for systems-level programming. Bootstrapping a project in C these days will often raise eyebrows or encourage people to dismiss you out of hand. Personally, I've barely touched the language since I graduated.

Now, with all that said: I still consider learning and understanding C to be key for having an integrated, in-depth understanding of how computers and programming really works. When I am getting a project up and running, I frequently end up running commands like "sudo apt install libopenssl-dev" without really giving it much thought about what's going on there. I know that it pulls some libraries onto my computer so that another program can use them, but without the requisite experience of building and compiliing a library then it's kind of difficult to understand what it's all about. I know that other languages will introduce this concept, but realistically everything is built to bind to C libraries.

System libraries are only one instance of my argument though. To take a more general view, I would say that learning C helps you better understand computers and programming. It might be a pain to consider stuff like memory allocation and pointers on a regular basis, but I also think that not understanding these subjects can open up avenues for a poorly formed understanding about how computers work. Adding new layers of abstraction does not make the foundation less relevant, and I think that learning C is the best avenue toward an in-depth understanding of how computers actually work. This sort of baseline understanding, even if the language isn't used on a regular basis, goes a long way to improving one's skills as a developer. It also gives people the skills to apply their skills in a wide variety of contexts.

I'm no expert, though: most of the programming I do is very high-level and abstracted from the machine (Python, Haskell, BASH). I'm sure there are plenty of folks here who are better qualified to chime in, so what do you think?

What was your first programming language, what other languages (if any) do you know now, and what tips do you have for those trying to learn any of those? Whether those tips are for beginners or even advanced, to do with APIs, or if you've got a good library to share.

It's been a long time since I've done any "serious" programming, but I have long held a desire to recreate an app that's been out of development for a decade, and I reckon I'd do fine if given the right direction.

Googling for this gives me either "no code" platforms, which is zero of the fun and basically what I do at work, or documentation that has skipped the first ten steps because it assumes you know the prerequisites already. Help?

I've got a notion to put some of my extra energy into learning to code. I'm familiar with EXTREME basics - I did some coding in BASIC and Python when I was younger ("Hello world" type stuff, and some futzing around with my Ti calculators programming capabilities) and while I had a pretty good knack for it I never developed it further.

I'd like to use this as a chance to create something useful for me - a discord bot for my server. We have a handful of bots doing a few odds and ends, and I'd like to try and work something out to consolidate things. That's getting a bit ahead of myself though - initial scope would be simple: have the bot do a simple task like counting +rep points, or something silly like telling a joke.

I don't really have any idea of where to start - what resources I need, what language to use, or really anything about how this all works. Any assistance at all would be welcome!

To be clear - I want to learn to code, and specifically I want to learn in a way where it is immediately applicable and useful in a context I care about.

I asked Claude for references to some ideas the ai had output earlier about a 16th century cardinal (Sadoleto). It's response was, Let me analyze the letter, and then this:

async function searchForSadoletoLetter() {
  try {
    const files = ['sadoleto_letter.txt', 'sadoleto.txt', 'sadoleto_to_geneva.txt', 'letter_to_geneva.txt'];
    
    for (const filename of files) {
      try {
        const content = await window.fs.readFile(filename, { encoding: 'utf8' });
        console.log(`Found file: ${filename}`);
        console.log("First 500 characters:");
        console.log(content.substring(0, 500));
        return content;
      } catch (err) {
        // File not found, try the next one
      }
    }
    console.log("Could not find any files containing Sadoleto's letter");
    return null;
  } catch (err) {
    console.error("Error searching for files:", err);
    return null;
  }
}

const content = await searchForSadoletoLetter();

// Since we don't have the letter available as a file, let's search for published versions online
console.log("The letter isn't available as a file. We would need to rely on scholarly knowledge about Sadoleto's letter to Geneva (1539).");
console.log("Sadoleto's letter was published in 'A Reformation Debate: Sadoleto's Letter to the Genevans and Calvin's Reply' (ed. John C. Olin).");

This strikes me as odd? Did Claude write a script to generate its own response? Have coders put something like this in as a gaurdrail?

edit: details about earlier convo

Okay, so this is getting really long, I'll put the ask up front: I have a strategy, I think it is reasonable. Now is a point where I can easily change things, and it won't be so easily later. So I'm looking to see if anyone has trod this road before and can recommend any of:

1. a different build system that will be easier to manage for this use case
2. a different strategy for using cmake that will be easier to manage
3. any gotchas I should be aware of, even if you don't have better solutions.

Background

I have a project I'm working on where the ultimate deliverable will be a hardware device with 3-4 different microcontrollers coordinating with each other and interacting with a PC-ish platform. This is a clean rewrite of a C++ codebase. Due to the microcontroller (and some of the PC APIs) being C++, the language of choice for most of it is likely to remain C/C++.

I'm succeeded in setting up a build system for embedded code. The old code was arduino, so it relies a lot on those libraries, but I've managed to set up enough custom cmake to get off of the ardunio tools altogether, even if I am borrowing their libraries and some of the "smarts" built into the system about setting build flags, etc. So far, I have a dockerized toolchain (cmake + make + gcc-arm-none-eabi) that can successfully build ARM binaries for the target platform.

The thing that I'm up against now is that I'd like to have a robust off-target unit testing infrastructure. My ideal case is that everything in the embedded system will be broken down into libraries that have clear interfaces, then to use unit tests with mocks to get high coverage of test cases. I'll still need some HIL tests, but because those are harder to set up and run, I want to use those for integration and validation.

In terms of OSes available, we're mostly working on Windows systems using WSL for linux. I'd like things to be as linux-based as possible to support CI on github, etc.

Goals and Cmake limitations

I started out using cmake because I hate it least of the tools I've used, and I am at least pretty far up the learning curve with it. But a limitation I'm hitting is that you can't do a mixed compile with two different toolchains in one build. The reasons why cmake has this limitation seem reasonable to me, even if it is annoying. You can easily change the toolchain that your code is built with, but that seems to be largely targeted at cross-compiling the same binaries for different systems. What I want to do is:

• build my code libraries with embedded settings for linking to the embedded binaries and build those embedded binaries (the end product)
• build my code libraries with linux-ish tools and link them against unit tests to have a nice CI test process
• (eventually) also be able to build windows binaries for the PC components -- when I get to that point, I'd like to get away from the MSVC compilers, but will use them if I have to

Current strategy

My current plan is to configure a library build like this (pseudocode):

add_library(mylib sources)
if (BUILD_TYPE STREQUAL BUILD_TYPE_EMBEDDED)
<embedded config>
elseif (BUILD_TYPE STREQUAL BUILD_TYPE_LINUX)
<linux config, if any>
endif()

#unit tests are built for each library
if (BUILD_TYPE STREQUAL BUILD_TYPE_LINUX)
add_executable(mylib_test sources test_sources)
target_link_libraries(mylib gtest etc.)
endif()

For the rollup binaries, I make the whole target conditional

if (BUILD_TYPE STREQUAL BUILD_TYPE_EMBEDDED)
add_executable(myembedap sources)
target_link_libraries(mylib)
endif()

Then the build script (outside cmake) is something like

cd build/embedded
cmake <path to src> <set embedded toolchain> -DBUILD_TYPE=embedded
make
cd ../../build/linux
cmake <path to src> -DBUILD_TYPE=linux
make

Things I like about this strategy:

• It's relatively simple to do all the builds or just one of the builds (that control would go in the shell script)
• I have one source tree for the whole build
• It lets configuration be near code
• It lets tests be near code.
• I think it's extensible to cover the PC component builds in the future

Things that worry me:

• It feels like a hack
• Support for off-target tests feels like it should be solved problem and I'm worried I'm missing something

Thanks for reading. If you made it this far, you have my gratitude. Here's a video with funny out of office messages that I enjoyed.