Going above 5%, OTOH, I would be shocked to ever see happen, for two reasons.
1) Mass-market adoption requires working well on an enormous long tail, which is difficult without a large team.
2) The primary driver of playing at that size is mass marketing/distribution, which requires $$$. Engineering a great product is necessary, but not sufficient.
My perspective on this is informed by being on Google Chrome from inception to 2025. Chrome from near the beginning was well-engineered and had three compelling-according-to-user-research advantages over the IE of 2008 (speed, security, and not being made by Microsoft), but mass adoption depended on a large number of non-engineering factors, of which marketing/distribution was (to a then-mid-20s software engineer) the most surprising one. I didn't believe that was what made the difference in which browser most people used; I was very wrong. Techies are not the leading-edge trendsetters for the masses we sometimes believe we are.
IMO, taking mass market share in the future will require either a compelling-to-users product coupled with at least a couple hundred million dollars in marketing and distribution budget, or else something that is completely unlike web browsers of the past (maybe there's something that replaces the web entirely). No one has done the former since Chrome launched; the closest people have come to the latter thus far is things like Dia/Atlas that try to reimagine workflows in an AI context, and I think the market has not found those to be sufficiently different+compelling.
Yeah basically everybody I know who's non-technical switched to Chrome when Google started advertising it on google.com (This was back when nontechnical users would start every search query by going to google.com). "Oh this says it's better and faster, let me download it". Google also paid shareware/freeware developers to bundle Chrome with their installers if you didn't uncheck some option in the "expert install" mode. Chrome would then launch and prompt the user to set it as the default browser. This is somewhat questionable, but this sort of developer usually pushes some sort of malware in their installers so I suppose Chrome was an improvement on that.
The distribution opt-outs really bugged me at the time, and I went and talked to the marketing team. Surprisingly, users who got Chrome via one of those opt-out deals used it at rates/in ways statistically indistinguishable from "organic" users (i.e. users who manually downloaded Chrome and installed it). This was a pretty strong counterargument to the idea that we were pushing something unhelpful on people who didn't want it -- they seemed to "want it" as much as the people who'd bothered to go find it manually.
I still didn't (and don't) love the practice, but it called in to question a lot of my assumptions about what people knew about software, why they used what they did, how they found it, etc.
Part of me wonders in a world with evergreen browsers if that long tail won’t simply shrink as time goes on.
I have yet to run into Java applets or Internet Explorer required situations in years. As far back as 2016 I’d occasionally find myself having to deal with both of these things. Still rare in 2016 but it was there.
Eventually I never saw it again.
That said, I’m not sure what gaps exist that I don’t perceive either, so I could be wrong and not know it
I agree, 1% is reasonable. That's still a huge number of people. And, not all users are created equal. If that 1% of everyone is skewed towards the more educated, IE if 5% of millionaires switch, that's 5% fewer eyeballs looking at a sports car ad.
I don't think this is really about GCC extensions (or obsolete language modes) rather than using the flexibility of the syntax to write things in a confusing way.
The first is simply K&R definitions + strange formatting.
Only the first one is fully standards-compliant C; the others all invoke some non-standard (but widely-accepted) features. (I believe empty unions - and their interpretation as being 0-sized - are non-standard in C, but I am not 100% sure.)
My point was not that those are standards-compliant, but that the use of the GCC extensions is not the primary cause of those examples being unreadable. (which seemed to be the point the person I replied to was making - and I disagree with GCC extensions being bad).
I always forget K&R syntax is still in there. I taught myself C in 1988, during the K&R -> ANSI transition. All my early Amiga C programs were K&R style.
Ray Bradbury is the best horror writer to have worked in a sci-fi milieu.
This story is one of only a couple sci-fi short stories to creep me out enough that I still remember them vividly decades later. (John Varley's "PRESS ENTER ■" is another.)
> A man is twice the age his wife was when he was the age she is now. When she reaches his present age, their combined years will be 100. Find the age of each.
This seemed initially like something amenable to guessing and checking a few ratios. <narrator voice>It was not.</narrator voice>
My answer: The man is 44 4/9 years old, the wife 33 1/3 years.
The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar.
About the recent track record, is there some technical problem or just drama with Unreal Engine that I'm not aware of? (I already have the same opinion about using AI-coded VCS.)
XHTML was never all the rage. Your premise is false.
Hard errors up front are great when you control the full content pipeline. It's very rare that that's the case, and was rare even in 2004. As soon as including someone else's broken content in your page prevents users from seeing your content, and that someone else can break the content at any time and you can't control it... few people will want hard errors.
On the contrary, image decoders all run complex processes that try and guess what to do in erroneous cases. I used to maintain Chrome's image decoders, and every single image format has "what the spec says" and then "what people actually do in practice"; you must handle the latter, and it is often very difficult to figure out how to do so. For BMPs, for example, determining whether the author intended 24-bit RGB or 32-bit RGBA sometimes requires decoding the full image and scanning to see whether any pixels' alpha bytes differ from the others, since "all 00" and "all FF" might both be "no alpha".
I also used to work on a production C compiler. Compilers can and do "guess what you meant" in various cases, notably for producing actual human-readable errors or proceeding past various warnings, but if I recall correctly even in more obscure non-error cases.
> For BMPs, for example, determining whether the author intended 24-bit RGB or 32-bit RGBA sometimes requires decoding the full image and scanning to see whether any pixels' alpha bytes differ from the others, since "all 00" and "all FF" might both be "no alpha".
This causes a situation in which a page that renders the image in Chrome doesn't work in Firefox or other browsers that don't implement the same non-standard correcting algorithm. Worse, the user doesn't have a way to know from Chrome that the image is broken and it will likely continue to be broken forever.
Generalizing this approach, you end up having to test your site in every major browser to see if you didn't made a mistake that is only revealed in the browser which lacks that recovery mechanism.
> I also used to work on a production C compiler. Compilers can and do "guess what you meant" in various cases, notably for producing actual human-readable errors or proceeding past various warnings, but if I recall correctly even in more obscure non-error cases.
I don't think this is addressing my point. When you write a C program, you expect the compiler to either recognize the program from the C grammar, or reject it because it is not correct (hence the concept of "error"). Then run whatever guessing algorithm to report to you what may be wrong.
The programmer expectation is that the program must strictly conform to the C grammar, and errors are corrected. It is not silently producing a half-reconstructed program assuming what you meant to say.
Crowing over omitting Arabic numerals in the name of avoiding any kind of cultural influence or bias seems silly when everything is still going to be expressed in decimal.
And in hours, minutes and seconds. Yes, those are near universal (I guess there may still be a few tribes in the Amazon or Indonesia that don’t use them), but still are cultural.
Also, having each hour have the same duration is cultural. The Romans, for example, at some time, used a clock where “the period of the natural day from sunrise to sunset was divided into twelve hours” (https://en.wikipedia.org/wiki/Roman_timekeeping). That means hours were shorter in winter than in summer.
<quote>The answer turned out to be geometry.</quote>
The answer turned out to be creating a cool piece of digital art that's essentially unusable as a timepiece. Don't get me wrong, it's a cool art project, but it's not a practical timepiece.
The author wanted it to retain some practical value, hence the discussion of the four “layers” of time—departing from the 12-hour system completely, even if there is a better way to represent time outside of it, would make the clock difficult to use.
Going above 5%, OTOH, I would be shocked to ever see happen, for two reasons. 1) Mass-market adoption requires working well on an enormous long tail, which is difficult without a large team. 2) The primary driver of playing at that size is mass marketing/distribution, which requires $$$. Engineering a great product is necessary, but not sufficient.
My perspective on this is informed by being on Google Chrome from inception to 2025. Chrome from near the beginning was well-engineered and had three compelling-according-to-user-research advantages over the IE of 2008 (speed, security, and not being made by Microsoft), but mass adoption depended on a large number of non-engineering factors, of which marketing/distribution was (to a then-mid-20s software engineer) the most surprising one. I didn't believe that was what made the difference in which browser most people used; I was very wrong. Techies are not the leading-edge trendsetters for the masses we sometimes believe we are.
IMO, taking mass market share in the future will require either a compelling-to-users product coupled with at least a couple hundred million dollars in marketing and distribution budget, or else something that is completely unlike web browsers of the past (maybe there's something that replaces the web entirely). No one has done the former since Chrome launched; the closest people have come to the latter thus far is things like Dia/Atlas that try to reimagine workflows in an AI context, and I think the market has not found those to be sufficiently different+compelling.
reply