Zach_the_Lizard

Teachers can weaponize CPS reports and absolutely cause legal problems. I know someone who dealt with that. Their kid's doctor put the kid on an ADHD medicine, he had a bad reaction to it, and then the doctor told the mother to immediately discontinue it.

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 agree with this. I've been writing a new internal framework at work and migrating consumers of the old framework to the new one.

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

Some of them rocket scientists double down on the accent in Hunts-vuhl.

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

As one of those supposedly higher level ICs, I agree entirely with the assessment.

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 had a Southern accent and had to train it out because my northern colleagues kept making fun of it. I noticed that I was perceived as "smarter" without it. My story is not exactly uncommon and there are a bunch of famous people (e.g. Stephen Colbert) who did the same thing.

Pulling weeds by hand works for a lot of weeds and is the most environmentally friendly solution where possible. It's what I've done, for the most part.

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.

Can't do that in cracks in a sidewalk, between pavers, on a wall, etc. where plant growth can damage them.

Some weeds are quite unpleasant, such as sticker burrs. I'd rather not have a dog and children covered in those.

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.

The problem with that "decipherment", from what I've been told by others who are far more educated than I am, is that it does the equivalent of deciphering Anglo-Saxon runnic texts by using modern slang like "yo" in order for it to work out.

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.

There have been attempts to recreate (vulgar) Latin from modern day Romance languages, as well as using older forms of these languages to reconstrct what's known as Proto-Romance.

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.

>...farming those risks out to institutions seems to be the current way most societies have decided to mitigate those risks

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.

On the other hand, avoiding peanut exposure can cause an increase in allergies, so there's a feedback loop at play.

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

It's a bunch of small things: command line flags, whether a command line tool is even present at all, compiler built-ins / differences in behavior, headers possibly being in different places, compiler support for various language standards and more.

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.

MacOS is only licensed for use in Apple branded hardware, as I understand it. Even running it in a VM could be problematic if that host isn't running MacOS.

I'm guessing "the edge" is doing inference work in the browser, etc. as opposed to somewhere in the backend of the web app.

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.

We used to, until they canceled that trust

The story of humanity can be summed up as: "what if we changed our environment without understanding it?" with both wonderful and wretched consequences.

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?

Considering that Houston is significantly bigger than Austin--metro area of 6.6 million vs 2.2 million--one could argue it _is_ handling a significant influx of people better than Austin.

Part of the issue is that Go has a variety of design choices / limitations that conspire to produce different design patterns in this area than what you might see with e.g. Java.

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<T, U> that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator<T>.

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

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

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.

I strongly agree. Map / filter isn't included, but a fair number of the various utilities are included in the standard library in the `slices` and `maps` packages.

`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.

It's difficult to explain, but having children triggers something deep--primitive, even--inside of you that unlocks another level of fulfillment. And self growth, for that matter.

I too have had a rewarding career that has afforded me all kinds of comfort. I've traveled extensively, even living in a foreign country. I've met interesting people and done interesting things.

But there's something special about hearing your child say "dada" or "mama" for the first time.

Notice, though, I said "fulfillment" and not "happiness"; I find the lows are lower and the highs are higher.

I wouldn't call you "selfish" or "materialistic."

I would say that parenting requires sacrifices--time, most of all--and can cultivate a kind of de facto anti-materialism depending on the parenting style.

There's a reflection on the past where you think of yourself as less selfish now, since you are now locked into doing more for others. Never before did you have to suck snot out of the nose of a completely helpless being, clean human waste, or endure having your beard roughly tugged on because it got a giggle.

The childless thus can _feel_ "selfish" to parents since they typically don't do as much for others as parents do for their children / wives / husbands / etc.

But that doesn't make it so.

Feelings are part of what makes us human. We love our parents, enjoy the company of our friends, like listening to music and so much more.

Not everything in life is logical.

From an outsider's perspective, it seems "move fast and break things" worked well enough for SpaceX.

Boeing et al seem to be following the "move slow and hide problems so we don't fix anything" mantra.

To this American, "half six" sounds like a roundabout way to describe the number three and not a way to says it's 6:30 (or 5:30 for that matter).

I've never heard anyone say that

Algebra, from Arabic

Sum types with pattern matching would likely take the place of (foo, error) in a lot of codebases.

This is especially true in cases where a function returns a collection of results where each result is independent from other results and a result can succeed or fail.

For instance, a batch report generator that is called every $INTERVAL might return a ([]Report metadata, error) today, but each report could have succeeded or failed without impacting the others.

The output is emailed to $SOMEONE to let them know the reports ran and information about each.

In today's world, the "error" could be a special error type that capture failures on a per report basis. The ReportMetadata type could also have an Error field, but one is not forced to check either.

Sum types could force checking for error on a per report basis, increasing the odds something is done with the error.

This is relatively common with naive int / string to enum type conversions, especially if the int or string are given as input from an RPC mechanism of some sort.

This type of pattern can be used to force other developers to check if the value is garbage before calling $BUSINESS_LOGIC that uses the enum

Here in Texas, it's been 80 degrees by about 8 or 9am for most of the summer. Sometimes earlier or for days. Apparently it currently feels like 110 degrees (air temperature is 101).

I'm guessing New York farmers don't have as much power as their Montana cousins.

Rural and low population _states_ have a fair amount of power due to having a fixed number of senators per state, but rural areas in an otherwise non-rural state may find themselves outvoted and thus mostly irrelevant.

The opposite situation, city slickers outvoted by country bumpkins, is of course possible in rural states.

As a military brat who doesn't really have a hometown, or even a clear regional identity, I like that this system lets you choose a town to donate to without forcing it to be connected to your birthplace or life history.

It'd be nice to be able to earmark it to particular government functions, maybe even charities in the area, etc.