Unpopular opinion: something being unusual does not necessarily mean it is bad. Yes, it will look foreign to random people looking at it, but if someone wants to seriously work with it, it will only take a few days to get familiarised with it. The justification of "cognitive overhead" is, from what I have seen, a shibboleth for rejecting "outsider" code written by someone not conforming to the language standards by claiming it is harder to understand. Personally, I would say that says more about the person's inflexibility and/or OCD, not the writer's style.

I am not saying every style is good (some simply obfuscate things and/or make things overly verbose or unreadable) but rejecting a style solely based on it being "non-idiomatic" is not a good thing.

I don't even think that's a controversial opinion. Breaking convention isn't inherently bad; it has costs, some of which you described. In this case specifically, the novelty is not justified by any significant benefit.

Well said. This is also something that I don't buy from the criticism towards Lisp. Something along the lines of: "Lisp did not become mainstream because everyone writes their own little language for their project, and so no one can understand other project's code."

pg wrote excellent arguments against this criticism in "On Lisp" § 4.8 Density, which apply just as well to the discussion above:

    “If your code uses a lot of new utilities, some readers may complain that it is hard to understand. People who are not yet very fluent in Lisp will only be used to reading raw Lisp. In fact, they may not be used to the idea of an extensible language at all. When they look at a program which depends heavily on utilities, it may seem to them that the author has, out of pure eccentricity, decided to write the program in some sort of private language.

    [...]

    If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn’t do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay.”

I want to both be polite to the OP but also agree.

Writing correct C is hard, so I’m not going to knock anyone who found stuff that helps them.

But pound defining shit to things you know via your Hungarian notion? Write some elisp. My Haskell programs don’t actually have Unicode lambda in them.

Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses got it right already?

Too many geniuses spoil the soup. We all see many of thousands of recipes and techniques over the course of our careers and it makes sense that each of us are continuously curating the small subset that we reach for in every project. I enjoy seeing the workbenches of other craftsmen, and nothing here looks unfamiliar.

Arthur Whitney however is nuts.

>Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses got it right already?

I'll be diving into C fairly heavy for the first time ever next year. I intend to skip right past pascal strings and implement/use free pascal's AnsiString or UnicodeString, both of which are reference counted, have a length (with no limit) and are guaranteed null terminated. I've stored a gigabyte in them in a few milliseconds. There's no need to allocate or free memory either... it's like freaking magic.

Haven't seen that many refcounted string libraries for C in recent times, most common one is probably still the one from glib.

I guess you're going to implement your from scratch, or is there some prior art you're likely to use?

If at all possible, I'll just lift the one from Free Pascal. Otherwise, it's yet another chore in the process of bringing MStoical (a modern port of the STOIC language) to life

You'll find by looking at their older posts that the author has actually written quite a lot of elisp.

To be fair they did say that when contributing to a shared project they follow the prevailing standard.

I don’t see the harm in following this for your own passion projects. You aren’t doing it for the world, you’re doing it for yourself.

I mean to each their own, but in my own experience, I value being able to easily and reliably copy-and-paste code snippets across projects (and I have a million of them, across several evolutions of my own personal coding styles and conventions) or files without worrying about whether the typedefs are in scope, polluting a namespace with possibly conflicting names or macros, etc.

I also have often found myself publishing “for my own use only” code as open source later and like to keep things understandable to maybe help teach someone something someday.

> I might just be a grumpy old dev [...] Everyone knows what a uint32_t is when they see it.

You might not be old enough then :-P many codebases typedef their own int types. See glib (gint, gshort, gint32, etc), SDL (Sint32, Uint32, etc) off the top of my head and there are many that define types like "int32" or "i32" like the linked article.

I cut my teeth on DWORD, PHALF_PTR, and friends, so my issue is not so much “don’t know how to grok this” as it is “we finally have sane, universal type names and you’re throwing them away.”

Sure, the _t suffix may be an eyesore but I’ll take size_t over “size” any day.

I like Rust's approach of "isize", as in "size" is in the place of the bit width. "size" sounds stupid.

The u32, i8, etc type aliases are the least offensive parts of this to me, even though I rarely see them in C code. I think those are pretty clear.

b32, size (ptrdiff_t), usize (size_t), nothing for ssize_t... what? Those are unidiomatic and also kind of weird. The macros... some are fine, some are weird.

If this makes the author more productive in C, it might behoove them to see if a higher level language like Rust would meet their needs.