I always had the idea in mind to one day code something in #C for the #C64. There's #cc65 offering a decent compiler. I always ended up with using #assembler again. That's because on that platform, it is the only way to have "full control": The OS only offers a machine code ABI (jump to routines, pass stuff in registers) and misses lots of things, so you need to program the hardware directly. Of course, I still use an assembler instead of hacking the bytes of the machine code directly.

Any Unix and similar OS comes with a C compiler, and even other systems offer a C API, so for a "modern" environment, that's the natural language to use for that "full control". And remember, C is your "portable assembler". 😏

In a nutshell, if you take "from scratch" literally, it would mean to somehow hack bytes into the machine's memory. That doesn't make much sense. I understand it as "use a simple programming language and avoid these huge frameworks and similar doing deep magical stuff for you".

CC: @modev@snac.bsd.cafe

Now is the time for really hot take! :ablobcool:

I'd say if you're happy with #C, there's no need to choose any second language. 🤷

Before even looking at any alternatives, the question should be "why not C". Some of the typical complaints are:

• memory safety – or, more generally, the fact that C is only partially defined, leaving a lot to the dangerous area of undefined behavior. There's no way to reliably detect undefined behavior by static code analysis, and it will often hide well at runtime. Especially errors regarding memory management often directly expose security vulnerabilities. In my experience, the risk can be reduced a lot by some good coding and design practices. Examples are avoiding magic numbers, using sizeof everywhere possible, preferably on expressions instead of type names, defining clear ownership of allocated objects (and, where not possible, add manual reference counting), making ownership explicit by using const where appropriate and naming your functions well, and so on. Given also there's no guarantee alternative languages will safeguard you from all the possible issues and there are also a lot of other ways to create security vulnerabilities, my take on this would be: partially valid.
• programming paradigm – you can only program in classic procedural style. Well, that's simply not true. First of all, you can program whatever you want in any turing-complete language, so what we talk about shouldn't be what's directly supported by the constructs of the language, but what's practically usable. In C, using some simple OOP is commonplace. Well, you can apply OOP to assembler programming without too much hassle, so, it's not surprising you can do it in C, as it's a pretty thin abstraction on top of machine code. C helps further with its linkage rules, where everything in a compilation unit is by default inaccessible to other units, and its incomplete types, where only a type name is known, but neither its size nor inner structure, giving you almost perfect information hiding for free. If you want/need polymorphism, it gets a bit more complicated (you have to think about how you identify types and manage virtual tables for them), but still perfectly doable. You'll hit the practical limits of the language when you want to go functional. The very basics are possible through function pointers, but most concepts of functional programming can't be applied to C in a somewhat sane way. Unless that's what you need, my take would be: invalid.
• limited standard lib. Indeed, the C standard library misses lots of things that are often needed, for example generic containers like lists, hashtables, queues, etc. It's straight-forward to build them yourself, but then, there are many ways to do that (with pros and cons). You'll find tons of different implementations, many non-trivial libraries bring their own, of course this also increases the risk to run into buggy ones ... I wouldn't consider it a showstopper, but I'd mark this complaint as: valid.

Side note, it's not so much React, Angular, Vue or whatever that sucks, it's the concept behind: #SPA. Or, more precisely, that concept used not in a niche where it belongs, but for every damn web site, or classic form-based web app. I remember getting into some very weird arguments with "frontend devs" over a simple demo class I wrote in vanilla JS to "enhance" a standard browser control (so, it still worked without a script). This class was pretty short and clean. Still they insisted it would be "hard" to program like that. It seems they can't do the simplest things any more without the help of their massive shitloads of "frameworks". And then, everything is a stupid SPA in the end, completely breaking the logical design of the web.

Ok, back to admiring the pure elegance of #C, sorry 😂

CC: @programming@programming.dev @technology@lemmy.world

This is a fun computer project: apparently there was a DOS program called Edna's Cook Book where you had to type in & save your own recipes. This program reads that old data file to recover your family recipes.

https://github.com/dangarbri/save-edna