mtabini

You are not. I am in agreement with you :-)

My thought is that perhaps there is some utility to using AI to help in routine scenarios, such as for example when a language barrier prevents someone from explaining themselves well, or when they are struggling to find the right words to express themselves.

Primarily, I was trying to stay away from an absolutist view of the problem to see if there are circumstances in which AI can be useful even considering all its shortcomings. There seems to be a lot of “all or nothing” perspective on its use right now, and I was simply wondering whether it might be a better idea to take a more pragmatic approach.

We do this with a lot of tech in real life: You don't need to be an MD to decide to take an aspirin, or an F1 driver to take the car to the grocery store (well, maybe in some cities, but that's beside the point). The problem is not with using technology, but with abandoning your judgment to it.

I think it's good to be pragmatic about these things. To me, it's similar to wondering whether we insist that doctors learn to write well, or we just give them a computer so that the pharmacist doesn't have to play philologist with their scripts. The vast majority of communication is routine, and can probably be improved with automated tools.

Now, I also see the counterargument that, in the doctor example, the computer is simply a tool that improves a process rather than a crutch that replaces the underlying knowledge, but I suspect that, in a lot of cases, that's probably OK.

I published a magazine for ten years, and this was by far the hardest editing challenge we had; our authors were from all over the world, and some of them had to be pretty heavily edited because English was very much not their first language. Thankfully, we had really good editors who did a fantastic job of it… nothing would have killed us faster than a heavy-handed attempt at “normalizing” the content to a house style.

That said, context is also important. The vast majority of content of social media is of both low quality and marginal importance; style and character are important to make an impact, and AI is clearly not going to improve either.

On the other hand, functional communication, when the goal of the content is to simply pass information across and style is not as important, can, in my opinion, benefit from an AI polish, because so many people struggle with writing clearly. In those cases, I'd rather read slop I can understand than original content that is hard to parse, much like I'd rather read naïve code that you can easily follow than cleverly optimized code that is incomprehensible.

Not only that, but EPR contracts must be actively maintained in order to remain in effect. The sink needs to send a ping to the source every ~500ms, or the source pops out of EPR mode and forces a renegotiation. This ensures that, if the sink crashes, the source doesn't keep pumping power into a device that can't take it anymore.

Can I offer a counterpoint? Much like OG USB put a 5V supply within everyone's reach, USB-PD has made programmable, higher power supplies available to everyone. That's a big deal, because PSUs are an expensive portion of a product, especially for small manufacturers and hobbyists. Having a dedicated standard that supports multiple voltages and currents allows small players to take advantage of the same economies of scale as the largest electronics manufacturers.

Case in point, IKEA will happily sell you a very well built 20W power supply that provides 5, 9, 12, or 15V for less than $5 here in Canada, and you can get a similar price from legitimate Asian distributors, even when buying in limited quantities. If you're working on a small-batch electronic product, that's a boon to your BOM; if you had to go out and source a dedicated barrel-jack PSU with the same capabilities, it'd cost much more, and you don't know what kind of quality you'd be getting.

Where the standard really falls on its face, IMO, is in its opacity. You can get a chip that does the PD negotiation for pennies, but there is no way to inspect the protocol without shelling out thousands for a dedicated analyzer, so when things don't work, it's really hard to troubleshoot the reason.

(Disclaimer: I'm working on an open-source protocol analyzer, so this probably colours my view on the matter a little.)

I did, you're absolutely right. Thanks for the correction!