As you probably already know, WG14 recently finalized work on C23 and began the cycle for a new revision of the C standard, for now called C2y. Traditionally, that means updating the charter, but this time around we decided to do things a little bit differently and instead of simple update to C23 charter [1], we tried a more substantial rewrite.
Initial version was uploaded on the website as document N3223 [2] and a "live" preview also is available [3].
The plan is to no longer keep charter tied to specific revision, but to have it apply to current and future standardizing efforts as a whole.
What do you think? Do you like it?
Is something not clear enough? Did we miss something?
We would like to hear your opinions and suggestions!
>The author says that the 3rd gen of consoles really begins with the NES, and so these early 1980s consoles can't belong to the 3rd generation.
Rather than the author, I would say that it's everybody else - a general consensus - making that claim.
>So I think it makes more sense to say that the 3rd generation begins in 1982/1983 with the Colecovision and Atari 5200.
I think is precisely the premise of this article - to show that those systems, had it not been for a crash of 1983, would have been categorized as early 3rd gens instead of late 2nd gens and to give a way to somewhat correct the mistake by calling them "generation 2.5"
> Rather than the author, I would say that it's everybody else - a general consensus - making that claim.
Sure, I guess I'm just disappointed that the author didn't take his argument to the logical conclusion and say that actually the 3rd generation of consoles began earlier, but that it was distorted in the US due to the 1983 video game crash (which was really only a thing in the US).
I think it comes down to online discussions of video game history often being very US and Nintendo centric, and the concept of a "generation" being quite flawed (the author does mention that).
> Six years after the start of the Second Generation, a new generation of consoles appeared (...) For reasons that are not entirely clear, they are considered part of the Second Generation.
As well as in last paragraph:
> (...) ‘What to call this so-called “Lost Generation?’” Should it be renamed to the Third Generation, and the Third to the Fourth and so forth? That would be confusing. While I like the term “Lost Generation,” and it lends well to how these machines were (...) doomed by the console market crash, (...) I suggest calling it the 2.5 Generation; this avoids any renaming and places it in the correct chronological order.
The “natural” background for text is light though. Hard to find books, newspapers, or magazines that put a dark background behind text of any significant length.
Accordingly, the Xerox Alto had a light background too, back in the 1970s. Demonstrated here with Smalltalk:
What little actual research exists suggests dark on light is more readable for people with normal vision. People with cataracts benefit from light on dark, and people with astigmatism benefit from dark on light.
Light background for books IMHO is no more natural than dark background for old CRT displays - both are what works best for a given medium: while making dark paper is not harder than light one, it is hard to make a pencil or ink which would be clearly visible on black paper (white markers do exists but they are a recent invention). Blackboard and chalk where natural until we got plastic whiteboards and easy to erase markers.
Modern screens are more or less unique in not limiting background colors so we can use any and and argue which one is better.
Actually there is at least one more common media where we can freely choose between dark and light (at least in the last 100+ years) - guide signs on roads. Both options are common (e. g. white on green/blue and black on white). But even if there are studies showing which background is better for signs it is not necessary the same for a computer screen: road sign should be legible from a maximum distance under variety of conditions - from a sunny day to LED lighting at nigh or heavy rain. Legibility is the main design goal. Computers on other hand are usually used in an environment where we can control lighting to some degree and a distance is fixed. Legibility is important but comfort is important as well (choose of colors should minimize eye strain / fatigue in case if it can affect this).
Annoyance #1: External symbols are expected to be unique within 31 characters according to the standard, so you're limited to a few namespace "levels", at most.
curl_easy_option_by_name() is already up to 24 characters and there's only two "levels" in curl_easy_*.
Annoyance #2: There's no formal registrar for LIBNAME. This isn't a big deal for popular libraries, but it's a pain having to keep a locally-modified copy of a less popular dependency just because it shares its name with another less popular dependency.
Annoyance #3: LIBNAME_actual_function_name() is a pain to read and using either the preprocessor or static inlines to locally alias function names for the sake of readability is silly.
@1: The limits are considered obsolete since C89 and implementations are encouraged to avoid them whenever possible. I think the same way we disregard non ASCII character sets, non two's complement encodings and similar, we are safe in assuming sane implementation being able to handle longer names. And being honest, if given implementation isn't capable of more than 31 significant characters, then it would have problems with namespaces too.
@2: Agree, although I don't recall this ever happening to me.
@3: Is it? How is libname::actual_function_name() much better?
I actually like to use libname__actual_function_name(), as it further separates "namespace" from function name (unless we need compatibility with C++, as IIRC it reserves all double underscores, not only at the beginning).
> @1: The limits are considered obsolete since C89 and implementations are encouraged to avoid them whenever possible.
This is still the case in C11, Section 5.2.4.1. Did this change in the most recent standard?
> @2: Agree, although I don't recall this ever happening to me.
It happened to me once. I ran across a library from 1994 and another from the 2010s which shared a simple name like "libamc". I'll comb through my records later to figure out the actual name.
> @3: Is it? How is libname::actual_function_name() much better?
It's not, but I wasn't thinking of C++ specifically. (I don't know C++. I've somehow managed to avoid it in many years of writing C.)
I was thinking more like the file-local namespace clobbering offered by Python e.g., from LIBNAME import actual_function_name.
> This is still the case in C11, Section 5.2.4.1. Did this change in the most recent standard?
Well, no, it's still marked "just" obsolete. For it to be deprecated or removed there would need to be anybody caring about it enough to put some work. But since it doesn't affect vendors at all (they can just ignore) and users don't complain, it's just a forgotten "law" - still law, but a dead one.
> I was thinking more like the file-local namespace clobbering offered by Python e.g., from LIBNAME import actual_function_name.
Oh, that's... way more than just namespaces. Way more. That would require more fundamental changes and additions. C++ just added modules in C++20 (not sure how well those will catch on), but I don't think something like that is to be expected in C for feasible future.
Yeah, GOTO or global variables are usually a not so good idea... except in cases where those are actually the best tools for the job and any alternative makes code actually worse.
If everybody became a robot and there's no need for chairs, then to whom is the technical debt supposed to be paid?
If there are still fleshbags who need chair, the one created 20 years ago, if properly cared for, works just fine.
Now, if I used a piece of rotten wood for one leg, because I couldn't bet bothered to go fetch a new plank, this is debt that will need to be paid in the form of putting additional work to fix said leg later.
People just like excuses to rewrite stuff with new fancy toys I guess.
We have code running for 10+ years in our CM. It's not technical debt. It's well tested asset that continually produces value without much problems or maintenance, coz most of them were already rooted out.
Sure if it was 10 years old blob in language nobody writes in in company it would have been potential liability but assuming every piece of software is that because it is old is a problem.
But I think it can be weaseled into that principle. Thanks!