The teacher was annoyed the kid was kind of disruptive and so filed a report that the mom had committed "medical neglect" for not giving her son the meds.

She had to take off work and deal with random CPS visits until they were satisfied.

This is a kid with good grades who can read multiple grade levels higher and who is most likely bored in class. I think he was in the first grade at the time

I don't know what the consequences of that are or could have been but it raised my eyebrows

I had strong principles at the outset of the project and migrated a few consumers by hand, which gave me confidence that it would work. The overall migration is large and expensive enough that it has been deferred for nearly a decade. Bringing down the cost of that migration made me turn to AI to accelerate it.

I found that it was OK at the more mechanical and straightforward cases, which are 80% of the use cases, to be fair. The remaining 20% need changes to the framework. Most of them need very small changes, such as an extra field in an API, but one or two require a partial conceptual redesign.

To over simplify the problem, the backend for one system can generate certain data in 99% of cases. In a few critical cases, it logically cannot, and that data must be reported to it. Some important optimizations were made with the assumption that this would be impossible.

The AI tooling didn't (yet) detect this scenario and happily added migration logic assuming it would work properly.

Now, because of how this is being rolled out, this wasn't a production bug or anything (yet). However, asking the right questions to partner teams revealed it and unearthed that some others were going to need it as well.

Ultimately, it isn't a big problem to solve in a way that will mostly satisfy everyone, but it would have been a big problem without a human deeper in the weeds.

Over time, this may change. Validation tooling I built may make a future migration of this kind easier to vibe code even if AI functionality doesn't continue to improve. Smarter models with more context will eventually learn these problems in more and more cases.

The code it generates still oscilates between beautiful and broken (or both!) so for now my artistic sensibilities make me keep a close eye on it. I think of the depressed robot from the Hitchhiker's Guide to the Galaxy as the intelligence behind it. Maybe one day it'll be trustworthy

Sadly, the You Must Be Ignorant lot is as ignorant of that conclave of cosmic capsule constructors as it is of the proper pronunciation of y'all

A decade or so ago, the high level ICs I interacted with were much more technical.

They were the kind who would perhaps not invent truly novel things--but plenty did in the right companies--but they had mastered their domains and genuinely solved thorny problems that others struggled with.

Nowadays, they are more political and less involved. I have met many that do not code or barely code. I've been in months of meetings to decide to do something fairly obvious just to ensure "alignment" even though no parties actually disagreed, just wanted to nitpick minor details that could just be a comment on a PR.

I will say for some weed species that can be ineffective or counterproductive, unfortunately, and for those a chemical (or other) solution may be in order.

Weeds can also be a sign of a potential problem, such as poor drainage, a leak, etc.

Nutsedge is an example of that. As I recall, pulling it out results in it sending more shoots up if you don't get the nut (which can be feet underground).

At that point, you have to continuously pull weeds on a daily (or multiple times daily) basis in order for it to use up more energy growing than it generates.

It likes water, so if it's there, it might be because there's standing water from rain.

I dug up a raised flower bed to get rid of it once. Nuts were absolutely everywhere because of poor drainage. I had to go down 2 feet I think to get them all, I replaced the bottom layers of impermeable clay soil with something that drained, along with a drain pipe or two.

Now the sedge is gone, the risk of foundation damage from being too wet is gone, and no chemicals were required.

Some weeds can be damaging to property, trees, sidewalks, etc. or are poisonous.

It's not always about being annoyed by dandelions in an otherwise overly fussed over sterile lawn environment.

As a non-linguist, non-Sankrit speaker I can't evaluate those claims, but considering that this script declines as the Indus Valley Civilization fades away, along with the arrival of Indo-European speakers who would be more likely to speak the ancestor language of Sanskrit, I'd be highly skeptical of these claims.

If the script is a full writing system, and I were forced to guess what a future decipherment might find, it wouldn't surprise me to see that the language is related to the Dravidian languages.

Hopefully more examples of the writing will be found so that we may one day know for sure.

My recollection is that the complexity went the other way; Latin was more complex than the reconstructed languages, especially if the reconstruction didn't include Romanian, because the modern Romance languages became simpler over time in similar ways.

It's clear that the result is useful for understanding features of the ancestral language, but it's not perfect, and never will be.

On the other hand, comparative linguistics came long before genetics, and it is this field that first noticed a connection between the Indo-European languages.

Archaeological and especially genetic evidence now show the peoples of this language family (mostly) have shared (though distant and diluted) ancestry, so the field was broadly correct in noticing a connection.

Unfortunately, those institutions --be they governments, insurance companies, UL Labs, banks, venture capitalists, etc.--also need to be vetted.

Even when staffed with impeccably well credentialed and otherwise highly capable people, their conclusions may be drawn using a different risk framework than your own.

The risk that they mitigate may even be the risk that you won't vote for them, give them money, etc.

There is also the risk of having too little risk, a catastrophe no worse than too much risk. The balloon may not pop, but it may never be filled.

The children who now have allergies, but wouldn't with past exposure levels, are more inconvenienced than the kid who can't eat a peanut butter sandwich at school.

Attempting to make life better for all has unexpected twists and turns

Even to this day, it's not uncommon to find libraries that won't compile with one of GCC, clang, etc. or even the same compiler but Linux vs MacOS.

It was even worse in ye olde times before package managers, I'm assuming.

EDIT: I forgot to mention that System V and BSD are two of the major families.

Both influenced Unix-like OSes far and wide, such as SysV style init scripts in certain Linux distros, MacOS being derived partly from BSD, Solaris being a continuation of SysV IIRC, and more.

There was a rough standardization in where certain things could be found, command line flags, etc.

Maybe your local machine can run, I don't know, a model to make suggestions as you're editing a Google Doc, which frees up the Big Machine in the Sky to do other things.

As this becomes more technically feasible, it reduces the effective cost of inference for a new service provider, since you, the client, are now running their code.

The Jevons paradox might kick in, causing more and more uses of LLMs for use cases that were too expensive before.

The same fires that poison the air we breathe also power life saving medical equipment so that we can keep breathing.

Micro plastics, endocrine disrupters and more have been unleashed. I am sure their effects will prove to be less than positive on both humans and wildlife.

But in trying to snuff out the next great environmental crisis, will we account for the benefits we've derived from the use of these materials when we do our cost-benefit analysis? The effects on innovation?

Did curiosity kill the cat, but save cats?

For example: let's say we want to implement something akin to Java's Comparator interface.

Java allows interfaces to be extended with default implementations. It also allows methods to specify their own generics separate from the entire interface / class.

Thus the "comparing()" method can take in a Function that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator.

(Generics simplified a bit, there are other overloads, etc.)

There's also thenComparing(), which allows chaining Comparator instances and / or chaining Function.

As a consequence, one can use .thenComparing() to build up a Comparator from the fields on a class pretty quickly. Especially with lambda syntax.

Go doesn't support methods having different type parameters than the overall interface / struct.

Go also doesn't have default implementations. It doesn't allow function or method overloading.

Go does have first class functions, however.

To build the equivalent capability, you'd most likely build everything around a comparison function (func[T any](a, b T) int) and write a bunch of functions to glue them together / handle useful operations.

That impacts the readability of a long chain of calls, especially since Go doesn't have a lambda syntax to make things a bit tighter.

Getting rid of the limitation on method-level generics would make this _significantly_ more ergonomic.

`context` also helps solve a bunch of the channel related use cases in a more elegant (IMO) way.

There are only a handful of things in that package I wish were included, such as "Keys()" on a map.