> That’s not to say that there is no microplastics pollution, the U-M researchers are quick to say. > > “We may be overestimating microplastics, but there should be none. There’s still a lot out there, and that’s the problem,”

The article actually goes into that in quite a bit of detail about that.

Right now, we are dealing with effective monopolies and duopolies. You can't just exit the App Store if you have an iPhone, and Amazon has cornered the market so hard that switching isn't really an option for most people. When competition is dead, the market can't self-correct because consumers have nowhere else to go.

Also, "monetizing their own property" is doing a lot of heavy lifting in your take. These platforms already charge: transaction fees, commissions, listing fees, higher product prices baked in, and in many cases consumers are paying directly (Prime, app purchases, ride fares). Injecting ads is basically double charging. On top of that it shifts the platform from "help me find the best match" to "whoever pays the platform wins".

Honestly, unless you are in a C-suite role, I'm not sure why you would defend a model that actively works against you as a consumer.

So much so that it effectively has become the main focus of some companies who we as consumers still perceive as online stores/marketplaces. Specifically sponsored search results apparently can become a bigger income stream than the one from actual sales themselves.

Which is great for these companies, terrible for us consumers.

To be fair, that might have changed in recent years. But after having to deal with that a few times for a few hobby projects I simply stopped trying. Can't imagine how it is for companies making use of these APIs. I guess it provides work for teams on otherwise stable applications...

In recent years, you can argue that android has no longer been open. In the early years of Android that argument would be much harder to make. To be clear, I am not talking hardcore FOSS libre open. But meaningfully open for the end user to do what they want on their device without much restriction. Early android didn't have sandboxing, had no permission system, was easy to root, etc.

Certainly with Nexus devices you had pretty much the freedom to what you wanted.

Could it have been more open? Sure, but I feel like it is almost disingenuous to say it was never if we are comparing it to the real world situation we find ourselves in today.

That's the thing though, LLMs really can't. At least not to a degree that they are able to act on it at a same level as when trained on everything else including tutorials and such.

Languages and technologies that LLMs excel at are those that are widely spread with numerous examples.

Just plain documentation with just the api calls isn't enough to train a LLM on. They effectively learn from example.

So with just #1 and no longer #1 aimed at humans you will never get to a point where you can ask an LLM about the technology.

This is what prompted me to remark that I feel you haven't thought this through. Which you might have, but that makes me think you have a overly optimistic view of what data is enough to reliably train LLMs on.

Again, to stress the point, just documentation isn't enough. So you really do need humans adapting the technology first, widening the base of examples to train on.

I mean this with no hostile intend, but have you honestly stopped and thought about what you did type down here?

What I mean by that is, have you looked at the complete picture to see if what you are saying makes sense in relation to what you initially said.

You questioned the need for documentation. Now you are saying there needs to be good documentation for LLMs to train on. Good documentation for LLMs to train on is actually much more extensive than than the documentation written for humans to begin with. So, you are effectively saying there needs to be more documentation.

Secondly, how can developers ask about something when they don't have decent documentation to start with.

It is actually a fairly well known phenomenon, certainly in educational circles. Being aware of it when you are writing any form of documentation is a first step. But even then, it is very difficult to properly assess the knowledge entry level of your audience.

Having others read through your documentation and importantly work with your documentation is a good strategy.

One thing I can also highly recommend is simply start out with a list of assumed prerequisite knowledge in your intro. Specifically things like certain environments, frameworks, etc. Bonus points for not only listing those but also linking to the documentation for those.

In fact, that entire aspect of LLMs is something that is not talked about as often. But is worth a whole discussion in itself. If I remember correctly, the availability of training material for a technology already has slightly impacted more niche corners of the tech world.

That might just be the bubble you are in. Java is still one of the biggest languages used in corporations across the globes for anything backend related. If it is because it is a modern COBOL or because it actually is a stable language with a solid ecosystem might be a matter of some debate.

In the circles I navigate it is still heavily featured in various bootcamps.

Really depends on the context and where the code is being used. As others have pointed out most js packages will use semantic versioning. For the patch releases (the last of the three numbers), for code that is exposed to the outside world you generally want to apply those rather quickly. As those will contain hotfixes including those fixing CVEs.

For the major and minor releases it really depends on what sort of dependencies you are using and how stable they are.

The issue isn't really unique to the JavaScript eco system either. A bigger java project (certainly with a lot of spring related dependencies) will also see a lot of movement.

That isn't to say that some tropes about the JavaScript ecosystem being extremely volatile aren't entirely true. But in this case I do think the context is the bigger difference.

> then again, we make client side applications with essentially no networking, so security isn’t as critical for us, stability is much more important)

By its nature, most JavaScript will be network connected in some fashion in environments with plenty of bad actors.

You still don't know then of course. When in doubt you shouldn't do the action that is asked through clicking on links in the mail. Instead go to the domain you know to be legit and execute the action there.

Having said all that, even the most aware people are only human. So it is always possible to overlook a detail like that.