Hacker News Reader

Comment by exDM69 | Hacker News Reader

My biggest problem with the new standard is the awkward naming of the threading functions. "mtx" over "mutex" saves a whole 2 bytes. Now what's up with that? Trying to avoid a namespace clash with some existing widely used library or something?

View on HN

I think because such naming is used in all standard C library.

That's usually something that bothers me about C and it's libraries. I don't see the point in saving those bytes when we aren't really typing them anymore (because of modern text editors and IDEs.) Abbreviation makes the code look uglier and more cryptic, I know that appeals to some coders, but not me.

If you don't like it use a typedef to make your code more "readable". Or a macro that will replace every occurrence of mutex in your code with mtx.

However if you want to share your code with other people, I would go with the standard names.

Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?

Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care.

Designing for people that don't know anything about what they do isn't a goal worth pursuing, the only thing you might succeed with is tricking someone into thinking they know something - in which case you've just made it worse.

Yes, it definitely matters I think. It's just an extra little bit of work to understand, which when you are debugging you needs as little mental clutter as possible. Why make something more work than it needs to be? Code is read more often then it is written therefore one ought to optimise for reading.

Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can never be "matrix"

Of course readability matters. But you must know language constructs anyway, no need for them to be overly explicit and be in the way of your code - therefor it could easily be argued that "mtx" is easier and more optimized for reading than "mutex".

The only reason an "if" or "while" statement makes sense to every programmer isn't because it is readable but because you must know the syntax and semantics of the language you program. And having a good shorthand is faster to read and since mtx isn't a word it isn't associated as anything that could be a word but you instantly see it as a language construct (kind of like syntax highlighting) and thus reduces the work of mentally parsing the code (one advantage of not writing your code in English is that you subconsciously see the language constructs differently than any of the code that you wrote yourself, not saying that I prefer to do this or recommend it (on the contrary)).

Again, this example alone isn't one I'd really care about - just questioning that "mutex" would be more readable than "mtx" (as a language construct).

I think I'm going to flip this around and say can you argue for why the keyword shouldn't be to use the "default position" of using the real word when its only two characters more?

The flaw in your argument is that what's "readable" changes dramatically over time. Once a programmer has used it enough times, "mtx" will be every bit as readable as "mutex". The brain readily tokenizes what it's seen before. Thus the case for plain-English-readability in code is limited to programmers who are not yet familiar with a notation – not a strong general case. We ought to have learned this from COBOL and every other attempt to make programming languages be like natural language.

Code is read more often than it is written, therefore one ought to optimise for reading

But by the same logic, code is read more often by people who know the language and most often by people who have been working on the program for a while, so they are the ones we should optimize for. The readability test that matters for maintaining a complex system over time is hardly "can someone unfamiliar with both the language and the program dive in to any random function and make out what it's doing". So why is that the standard always held up in discussion?

When I google search for just mtx, it's all car audio, whereas mutex gives a wikipedia result for mutual exclusion as the first link.

Not everybody will recognize mtx as mutex while reading code, and lots of people learn code by reading it, rather then from standards.

Hover mtx in your IDE once and bam, now you know.

To have a distinction between mutex and "mtx c" on google will probably be of value as well.

mutex: obviously refers to mutex

mtx: maybe mutex? maybe multi-transaction? maybe library prefix? vendor prefix? maybe, maybe...

2 characters

Back when C was first pioneer'd this was an issue. However this is the 21st century and yes we could have better full names but the standard from before is kept for consistency. I think deprecation and renaming of everything is out of the question at this point as companies and developers have invested considerable amounts of time in building applications using the good ole "fprintf" or "malloc".

I wonder what the ramifications would be if someone went through and properly named the functions.

You mean back when C was first creat'd.

I recently found myself reading Mason & Dixon and trying to figure out what the rule is for those apostrophes. Pynchon wrote that book in a hybrid of 18th and 20th century English (which is brilliant and possibly also annoying) and boy does he apostrophize. At first it seemed like all the past forms were apostrophiz'd but then I noticed many of them were elongated after all. It appears that the rule is to spell out the "e" in "ed" when it's articulated and use an apostrophe when it's unpronounc'd. I suppose this ought to have been obvious from first principles but I only hit on it by painstaking induction :)

To be fair, it should be "created." I was making a joke based on the fact that the original function name to create a file in C was in fact called "creat". If I added the (pronounced) "e", then the joke would be lost!

Ah, I missed that. Creatted? :)

This is annoying. This will conflict with the matrices in my code.

mtx_init and mtx_destroy might. The rest of the mtx_* keywords don't seem like they'd be used for a matrix library.

(Keep in mind: identifiers ending in _t are reserved by POSIX. http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh...)

Haven't read the document yet, so I don't know if there's a rationale for naming.

It might simply be racial memory, from the days of linkers with eight character symbols (and the initial underscore ate one of them). It's hard to believe we actually wrote software under those limitations.

http://bikeshed.com

The threads.h header comes directly from the Dinkumware Compleat C library. I would have preferred a stdthread.h with more pthread.h like struct/function naming.

Reply on news.ycombinator.com