It's time to return to the roots, to the C programming language

  • To your submission title question:

    C is a root, sure, but it was a language designed for the PDP-11 and for single-threaded programs. The original C is unsuitable today for numerous reasons and saw major changes over the decades, not all sufficient, to make it more suitable for newer systems. The original developers of C moved on (to other languages or to move the needle on the C language), why can't the rest of us?

    > Why are we looking for new technologies?

    Several reasons: they solve a problem; we're curious; for some reason we "have" to use them so obviously we have to look at them.

    I'm trying to modernize an old system. To give you context the original version was 12 racks of largely analog equipment for signal processing. Those 12 racks, today, would be maybe 4U of digital equipment (just to provide the original features). If it was Rx only, it can almost be handled by a modest current generation workstation and an RTL-SDR and a couple other pieces of hardware, but it's also Tx and a bunch of other features so it needs a bit more than that. 25ish years ago it was modernized and reduced down to 5 racks with a lot of features added. To cover the newer version, it'll be about 2 racks of equipment. And we'll get more features.

    That's why we look at new technology.

    Is there value in the old? Absolutely. The lessons, though, are often more valuable than the technology itself.

    > Why do we go into software development with the enthusiasm to create something great, but end up in a situation where we are developing some other catalog or some other digital yo-yo to make money?

    Speak for yourself. I work on critical communication and safety systems. Go find better jobs and stop asking people to hire you as a catalog maker.

  • My cynical self sometimes believes the whole point of all these languages and frameworks is to drive clicks to blogging sites like Medium. It also provides new content for industry conferences.

    Yet, despite these new languages and frameworks, the same old problems persist. State management is difficult. Thread management and multitasking is difficult. Generalizing algorithms and applying them in different, but similar, circumstances is difficult. Dealing with currency is difficult. Dealing with dates and times is difficult. I could go on and on, but you get the idea.

    It feels like we go through lots and lots of gyrations while progress is being made very slowly.

  • 100% certain that you could find an identical version of this rant complaining about how the newfangled Algol-68 is making people lose sight of the power of assembly language.

  • If you're wanting to go back to the roots, go back 2 years sooner, to Pascal.

    Both languages have morphed over time, but I believe Pascal has much cleaner syntax, and is better suited to the modern programming environment in the form of Free Pascal.

    Unlike C, Strings in Pascal are almost magic. Need to stuff a gigabyte binary in a string? I've done it. They don't need to be allocated, or managed, the run time library does that. They're copy on write, reference counted, and you don't have to allocate/free them.

    Pointers are easier too... @X is the address of X, X^ is the thing that X points to

    Sets, Generics, Iterators, it's all there. And then there's units, everything compiles when you need it to, and ONLY when you need it to.

    Threads and multitasking seem easy to me, far easier than back in the 1988 when I wrote my own cooperative-threading library for Turbo Pascal. (Co-routines would likely be the correct name for it now)

    Compilation times that are unmatched.

    Yes, the time is now to return to our roots, Free Pascal. ;-)

  • 1. The people who say that C is unusable, because bad things happen when it is written by people who have only half learned it, are not going to shut up.

    2. The advantage of C++ is complexity management, but it does not happen by itself, it still requires painstaking craft. That is where your watering needs to go.

  • Get into microcontrollers. C still remains the best choice for tiny memory and program space. Often you need to tightly control memory allocation, and C++ creates too many unknowns. Most other languages are non starters. Use assembly if you want.

  • Some of us just can't return to the C programming language. We never left it.

    "If it works, don't fix it."

  • 1. New technologies provide features that older technologies lack and making things easier. Example: Java provides garbage collection so you don't need to care about managing memory like C. Kotlin provides null-safety so you don't need to care about NullPointerException like Java.

    2. Because those technologies exist. If learning a new language or framework is a problem, it's ok, there are people who are programming in C for decades. But if they want to write a backend for a web application, an app for Android and so on it would be more difficult than just learning those new technologies and using them.

    4. I don't know. I remember my first PC, running Windows 95 on an old Pentium CPU with only 16MB of memory, 8GB IDE hard drive. It booted as fast as my M1 Mac. And we could write documents, spreadsheets, listen to music, just like we do today.

    5. I never searched by any of them, but I know that people search, for example, jobs for "Java Programmer". And I think it's weird unless you are a specialist in that language.

    I remember when my former boss allocated me to work on a Kotlin microservice, I told him: "But... I don't know Kotlin". He answered: "It's only a programming language, you learn that". And he was wright, two weeks later I was sending my first PRs in Kotlin. I learned only what I needed, I don't see as a problem if I needed to switch to Go, Rust, Swift, Clojure or any other programming language that I don't know yet (unless if it's too different).

    And I think that learning a new framework is harder than a new language. Example: if you know Python you learn Ruby in few hours, but if you know Ruby you'll take more time to learn Rails. If I wanted to hire someone to work with Rails, I would prefer someone that already know Django but don't know Ruby instead of someone that know Ruby but never worked with Rails, Django or similar.

    6. It happens in any career that you choose. Think about a musician. Many people think that being a musician is only fun because it is fun to play an instrument. But if you work as a musician you'll have to play music that you don't like, in places that you don't like and for people that you don't like, because you need to earn money. Of course you can still play for fun, but it mostly won't be enough to survive.

    Same for software. You can still write what you want for fun (I do it a lot, e.g. I wrote my own Git in Haskell: https://github.com/lucasoshiro/oshit). But in order to survive we may need to write boring CRUDs