> you trusted 22-year-old coffee junkies copying and pasting from stack overflow 10 years ago
Absolutely. There is a limit to how much code can be shared on stack overflow and, in the pre-AI days, code snippets had to be understood well enough to integrate into a larger hand crafted work.
Furthermore, stack overflow code is shared by consenting users and is licensed per the terms of service, unlike AI generated code which is trained on non-consenting users and is both ethically and legally dubious.
Can we also flag AI generated projects posted on Show HN?
I used to love reading HN for the handwritten articles and handmade projects, but in the LLM era the quality has deteriorated significantly. I find myself flocking to other message boards where LLM content is flagged, discouraged, or banned.
Not necessarily. In many (most?) areas of tech the rate of advancement follows a logarithmic curve. That is to say, the first 90% is achieved quickly but the last 10% takes significantly more time.
I blocked AI overview because it starves websites of their own traffic and revenue.
Websites accepted Google scraping their content because it gave them a prominent blue link plus excerpt to drive traffic. Now everyone’s content is blended together and maybe, if they’re lucky, their site is chosen amongst the blend to get a tiny citation link.
Not sure if you're aware, but defer is proposed for C2Y [1]. It's already available in Clang behind a compiler flag. It is interesting how the languages continue to diverge.
> the culture that... despite easy proof that isn't the case
> devs wrongly assume
> self inflicted complexity
> considered an advantage when argued by C folks
> when the same crowd points
> as the C crowd pretends it to be
You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.
Caring for the actual assembler output in selected critical pieces of code is not the same as ignoring the abstract machine model. What you claim is simply not the case if you check actual proficient systems programmers. Of which there are an astonishingly high share C and C++-but-mostly-C programmers.
Any user of compiled languages cares about Assembly, which is why regardless of the compiled language, an Assembler was always shipped alongside.
Also it isn't a C invention to have the compiler dump the Assembly output instead of object code.
Now the culture that C language constructs in 2026 are still 1:1 to Assembly instructions, that pretty much prevails, despite easy proof that isn't the case at various compiler optimization levels.
Proficient devs, well many still don't know to distinguish what is their compiler, and what ISO says.
It is the case that you can more easily know what happens when you don't use the wrong abstractions but stay in control. Highly-abstracted C++ code basically makes allocations and syscalls in the whitespace between the source code tokens.
You can't do systems software like that, you have to roll back the abstractions and roll back the use of pre-canned containers and libraries that you don't understand.
So it's all about understanding and control, not about some idea that C was defined in terms of assembly instructions, which it obviously is not. That's a total strawman.
There is not much real evidence for "devs wrongly assume" and as someone writing numerical code (clusters, NUMA, SIMD, etc.) I think C is still the ideal tool for this.
Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.
such a strawman again... You don't want to be writing explicit platform specific SIMD most of the time. You just want to write a dumb function that doesn't do any non-obvious calls, doesn't cause thread contention, doesn't hide complexity, isn't going to be a nightmare to change later, no surprises.
I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and you're pretty good already. Only drop down to concrete hardware arch level where it makes sense. But largely, the C machine model is still very much suited as a model for actual hardware. Writing straightforward obvious code allows you to stay in control of memory layout and the data transformation paths. It easily gets you within <<2x of what you could achieve with hand coded assembler for the >90% of the code that are pretty boring and straightforward. And obviously you couldn't get the work done in time when coding everything in assembler.
I have seen plenty of self inflicted complexity in C, starting in the golden age of Yourdon Structured Method, and all those libraries that replicate C++ basic features with preprocessor macros.
That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and generics in C, now C++ feels like Vietnam flashbacks.
If C would be so hardwired to the PDP-11 architecture it would have died with it. In reality C works just fine on all sorts of hardware (like GPUs) with only minor extensions.
I am also tired that language extensions in C to work around ISO defencies is considered an advantage when argued by C folks, while at the same time it is considered a language design fault when the same crowd points to other programming languages.
The "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?
Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.
So when is WG14 standardising modern hardware into the C standard?
Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?
Why does the language standard need to prescribe everything. It is a standardization of between existing compilers, they are allowed and intended to invent things. If anything the experience from C++ has shown, that writing too much behaviour into the standard accidentally has consequences on the possible performance. The C standard is descriptive, not prescriptive.
> something that any programming language can offer in similar capacity?
By your measure a lot of other languages don't offer anything to begin with, because they do not have a standard at all, only a reference implementation.
I think there is one major difference that separates the two eras: in ye olden days you bought software for a fixed price and while it's understood you might only receive updates for a limited time, you could continue using it so long as you had the ability to run it. For example, you didn't have to upgrade to Windows XP if you were satisfied with Windows 98. With subscriptions, it's a recurring fee to continue accessing the software at all.
Windows sells more copies of its software the OEM route. Also, they sell specific versions that eventually end support. Today you might consider Windows almost a loss leader since Microsoft is diversified with many services on top of windows.
It ignores the point. If I've bought BBEdit 13 for 60 USD three years ago and I'm still happy with it, I can keep using it for the rest of my life without paying more. If I want the new features, then I can pay 40 USD to get the latest version.
This is a sane AND a sustainable model for companies, and actually creates MORE incentives for the developers to align with the user's interest: if the new update sucks and has features no one asked for, then nobody will pay for the new version and keep the old one.
There is no reason why previous versions of the software you paid a license for should effectively "disappear".
I’m a fan of the subscription model where if you stop paying, you continue to have a license for the last version you got during the subscription.
I’ve appreciated that in a few apps where my need for them on a daily basis evaporated but I still need to briefly touch that system once every few months.
How about forcing businesses to be owned by their employees [1]? Instead of taxing the owning class and being paid UBI peanuts, you become the owning class and reap the rewards directly.
How about requiring AI companies to pay creators for training rights? Alternatively, models trained on the commons must be owned by the commons. Right now these AI companies are trying to have it both ways: it’s The People’s Data for training on comrade but ownership is privatized.
Practically speaking, who is going to enforce such a regime? Do you really want to give Chinese companies such a huge competitive advantage, that they aren't subject to the same costs as western companies? How do you even sort out which "creators" are owed, and how much? It's next to impossible, and would drown the legal system in litigation; it would likely cause more problems than it solves. On top of which you can find open weights for most, if not all, of the scraped material already. If you make those illegal to use, or prohibitively expensive, you just destroyed local LLM legality, and put the technology firmly in the hands of only the monopolists.
If models are trained on the collective whole, they must be owned by the collective whole. If you believe funding creators for the training of private models is too slow, inconvenient, or creates a global disadvantage, then embrace collective ownership.
Sure, I wish everything was perfectly fair too. But how do you practically and REALISTICALLY proceed, and ensure you don't end up doing more damage than benefit? The road to hell is paved with good intentions. Everyone seems much more focused on complaining, and talking about "what's fair", than actually proposing concrete steps that would lead to a better world, without a significant risk of creating a worse one.
Start by legally compelling companies that trained on unlicensed data to either (1) license the data, (2) publish their model, or (3) destroy their model.
> Start by legally compelling companies that trained on unlicensed data to either (1) license the data, (2) publish their model, or (3) destroy their model.
You are lost in an imaginary world where everything is simple and has no negative consequences. First off, there is NOBODY who has that power over all the companies in the world. So immediately you are creating an imbalance between companies and potentially destroying your domestic industry; with long term negative consequences for the people you're supposed to be protecting. Secondly, you might be creating a situation where it's impossible to ever create a competitor to those companies who are already entrenched monopolists, potentially even making it impossible to ever run self-trained or local LLM's. Also, you just unilaterally made it legal to publish all copyrighted work (since that's what you believe their model to be) to the general public, presumably in a way that can be used by everyone; further eroding copyright law in one fell swoop. You've completely disregarded the legal issues around what constitutes "unlicensed data", and how much is required before triggering your new law, and what that would mean for the legal system potentially being inundated. You're reacting way too emotionally and flippantly, with no apparent thought about what harm you are doing and how you might actually be making things worse, not better.
Data is being licensed by AI companies, but negotiations are limited to those with the capital [1][2][3]. You write about "imbalance" but ignore that large firms can cut deals while small creators languish.
You seem to believe advancement only happens in the private sector while ignoring academic institutions and publicly funded research. You've dismissed the possibility of public models entirely.
You fail to consider that when you financially disincentivize individual creators from publicly distributing their work, you starve future models resulting in a world were data is licensed only to those who can afford it anyway.
> In my opinion, for open-source projects, scoring the project's AI sloppiness based on the timeline of commits would be a good indicator.
You can’t necessarily judge by timeline. I’ve always developed my projects privately and then squashed to one initial public commit. I’ve got a private repo now with thousands of commits developed over years and I still intend to squash.
Absolutely. There is a limit to how much code can be shared on stack overflow and, in the pre-AI days, code snippets had to be understood well enough to integrate into a larger hand crafted work.
Furthermore, stack overflow code is shared by consenting users and is licensed per the terms of service, unlike AI generated code which is trained on non-consenting users and is both ethically and legally dubious.