Readit News logoReadit News
moth-fuzz commented on Some C habits I employ for the modern day   unix.dog/~yosh/blog/c-hab... · Posted by u/signa11
moth-fuzz · 22 days ago
I'm a huge fan of the 'parse, don't validate' idiom, but it feels like a bit of a hurdle to use it in C - in order to really encapsulate and avoid errors, you'd need to use opaque pointers to hidden types, which requires the use of malloc (or an object pool per-type or some other scaffolding, that would get quite repetitive after a while, but I digress).

You basically have to trade performance for correctness, whereas in a language like C++, that's the whole purpose of the constructor, which works for all kinds of memory: auto, static, dynamic, whatever.

In C, to initialize a struct without dynamic memory, you could always do the following:

    struct Name {
        const char *name;
    };

    int parse_name(const char *name, struct Name *ret) {
        if(name) {
            ret->name = name;
            return 1;
        } else {
            return 0;
        }
    }

    //in user code, *hopefully*...
    struct Name myname;
    parse_name("mothfuzz", &myname);
But then anyone could just instantiate an invalid Name without calling the parse_name function and pass it around wherever. This is very close to 'validation' type behaviour. So to get real 'parsing' behaviour, dynamic memory is required, which is off-limits for many of the kinds of projects one would use C for in the first place.

I'm very curious as to how the author resolves this, given that they say they don't use dynamic memory often. Maybe there's something I missed while reading.

moth-fuzz commented on The compiler is your best friend   blog.daniel-beskin.com/20... · Posted by u/based2
moth-fuzz · a month ago
I'm not a fan of the recent trend in software development, started by the OOP craze but in the modern day largely driven by Rust advocates, of noun-based programming, where type hierarchies are the primary interface between the programmer and the code, rather than the data or the instructions. It's just so... dogmatic. Inexpressive. It ultimately feels to me like a barrier between intention and reality, another abstraction. The type system is the program, rather than the program being the program. But speaking of dogma, the author's insistence that not abiding by this noun-based programming model is a form of 'lying' is quite the accusatory stretch of language... but I digress at the notion that I might just be a hit dog hollering.
moth-fuzz commented on Mruby: Ruby for Embedded Systems   github.com/mruby/mruby... · Posted by u/nateb2022
moth-fuzz · 2 months ago
I love Ruby and have tried to use mruby several times, but the one thing that always becomes an issue is that it uses Ruby’s own native-extension build system for compilation, which is configured in Ruby itself. It makes it a total pain to include in other build systems, or when compiling to other targets (i.e. WASM)

Frankly, I love Ruby as a language, but if it were as easy to embed as Lua I would have no reason to use Lua.

moth-fuzz commented on Dark Mode Sucks   tomechangosubanana.com/20... · Posted by u/4dm1r4lg3n3r4l
moth-fuzz · 3 months ago
I agree with the author - I'm sick of hearing the cliches from people who prefer 'dark mode'. But I remember long before there was 'light mode' and 'dark mode' there were themes based on a spectrum of hues and values - actual colors. Why not bring that back? "Light mode" can be way more bearable if it's not pure #ffffff. I dislike the invented dichotomy of light and dark anyway, there's an entire spectrum that designers can use, and I think apps in general would look way better if they took advantage of that.
moth-fuzz commented on CSS's problems are Tailwind's problems   colton.dev/blog/tailwind-... · Posted by u/coltonv
hbn · 7 months ago
Been using Tailwind since starting my job 5 years ago where we have a ton of webapps standardized on Angular+Tailwind, and you may have to hop into a webapp you've never heard of before to fix a bug. Couldn't be happier with how much easier it is to build and maintain compared to traditional CSS.

Many many words I've read trying to convince me why I shouldn't be having a good time using it, yet here I am more productive than ever thanks to it. Less experienced devs are by default funnelled into writing code that's easy to understand, only looking at one file, as opposed to people trying to do cute tricks where styles could be coming from anywhere in the project. It's SO much easier when the styles are on the component I'm looking at and I don't have to cross-reference between files. Plus people sticking to increments of 0.25rem instead of everyone using their own preferred units is huge.

When you work at a big company you can't expect everyone will write nice CSS. But Tailwind plays a huge part in making sure everyone writes something that's much more easier for the next person who has to read it.

moth-fuzz · 7 months ago
You'd also be more productive and have less unknowns and potentially less decision paralysis if, say, everyone started using excel hooked up to a database instead of writing their own bespoke CRUD app, but alas, those aren't the reasons one asks programmers to program.
moth-fuzz commented on Crystal 1.16.0   crystal-lang.org/2025/04/... · Posted by u/ksec
moth-fuzz · 10 months ago
I love Crystal but I’m surprised at how nothing the WASM story is this late in the game. I’d love to run Crystal directly in the browser, especially given how web-focused they seem to be.

Also, windows support has been more or less “done” for a couple of years now, is the “preview” tag still necessary?

moth-fuzz commented on Some programming language ideas   jerf.org/iri/post/2025/pr... · Posted by u/todsacerdoti
moth-fuzz · a year ago
Regarding the 'Modular Monoliths' bit, I wholeheartedly agree. I always found it kind of disappointing that while we're told in our OOP classes that using interfaces increases modularity and cohesion and decreases coupling, in reality in most programming languages you're relying on the nominal type of said interface regardless. All libraries have to use a common interface at the source code level, which is obscenely rare. For interfaces to truly live up to what they're describing, they merely ought to be structural (or whatever the equivalent to functions is that structural typing is to data).

Edit, since I remembered Go has this behaviour: I think Go's auto-interfaces I think are easily one of its biggest selling points.

moth-fuzz commented on C++ is an absolute blast   learncodethehardway.com/b... · Posted by u/ok123456
moth-fuzz · a year ago
I'm of two minds when I see comments complaining about header files. Practically speaking, I think "have the preprocessor copy & paste source files together" is a bit of a hackjob, but, conceptually speaking, having your interface and implementation separate is ultimately a good thing.

The problem of course lies not with header files, but C++ the language, as all public fields and private fields must be specified in the class declaration so that the compiler knows the memory layout. It's kind of useless in that sense. You can move private methods out to a separate source file, but, you don't gain much in doing so, at least in terms of strict encapsulation. And of course, if you use templates at all, you can no longer even do that. Which is its own can of worms.

Unfortunately, none of these problems are problems that modules solve. Implementations very much disagree on interfaces vs implementations, precompiled vs simply included, etc etc. In my own usage of modules I've just found it to be header files with different syntax. Any API implemented via modules is still very leaky - it's hard to just import a module and know what's truly fair for application usage or not. You still ultimately have to rely on documentation for usage details.

At the end of the day I don't really care how the implementation puts together a particular feature, I care about how it affects the semantics and usability of the language. And modules do not really differ in proper usage from headers, even though the whole backend had to be changed, the frontend ends up being the same. So it's net nothing.

All said and done, when it comes to defining library APIs, I prefer C. No public/private, you just have some data laid out a particular way, and some functions to operate on it. The header file is essentially just a symbol table for the binary code - and said code can be a .c file or a .o file or even a .a or .lib or .dll or whatever - C doesn't care. Raw functionality, raw usability. No hoops.

moth-fuzz commented on Enum of Arrays   tigerbeetle.com/blog/2024... · Posted by u/signa11
moth-fuzz · a year ago
The idea that arrays of structs are inherently more cache friendly and thus data-oriented-er is a bit reductive of the whole practice of data-oriented code. The point is to optimize data layout for access patterns. Putting fields of a struct into their own arrays is only actually an optimization if you're only accessing that field in-bulk. And if so, why is it even in a struct in the first place? If you use all fields of a struct in your algorithm, then an array of structs is the optimal way.

All the same is true for enums.

moth-fuzz commented on Procrastination and the fear of not being good enough   swapnilchauhan.com/blog/p... · Posted by u/swapxstar
moth-fuzz · a year ago
I have a problem with how procrastination and perfectionism, this sense of being 'not good enough', is almost universally phrased as not being good enough for others. For caring too much about others' opinions. And that the solution is to just Do Art For Yourself :tm:.

I've tried that. I've tried shunting out everyone else's opinions. But then of course, if you lock me in a room with me, myself, and I, you now have 3 of my biggest critics all in the same room.

I don't really care what others think, never really did, and none of these anti-procrastination or anti-perfectionism pieces help when it's my own standards that I'm not meeting.

u/moth-fuzz

KarmaCake day468January 24, 2020View Original