foerbert

I disagree. It is relevant, and not lowering level of discourse. Animal models are both very useful and very limited. There is no way to 'adjust' them into such a perfect proxy that the model is irrelevant. You can do better, but at the end of the day the most important adjustment to make is to keep in mind that it is in fact... in mice.

While "... in mice!" can get a little jokey at times, the alternative is often a discussion that more or less assumes that the smallest of effects in any model are directly actionable information for the readers. It's not. Even with human studies, a single study is rarely enough to come to strong conclusions.

In an ideal world, sure, it's just a repetition of facts everybody knows because everybody read and understood the article before engaging in the discussion at all (even just reading). But that's unrealistic on multiple fronts.

Until that's a reasonable assumption, I'm more than happy to see some reminders of important facts in the comments. Even if it spawns the occasional joke.

A sufficiently interested public will push the legislators. Part of interesting the public is informing them that there is a problem, and that there is even a relatively simple solution.

The public interest route seems both far simpler and more realistic than... I don't even know, what's the alternative here? Some kind of non-profit for public domain advocacy that somehow has a budget to rival Disney, never mind the rest of the interested industries?

I'm not sure why you think writing about the balance of interests isn't part of building counter power.

Amusingly, I'd bet the tone you're getting from that comment is probably the same tone the commenter got from the "You" thing in the first place.

To me, the capital You reads kind of aggressively. It adds an unusual amount of emphasis to the word which only/mainly happens when an upset person is making an accusation.

I feel like Arch used to be simpler to install, right? Not that it was done for you or anything, but I recall being really impressed back when with how straightforward it was using the wiki.

I moved from Arch to Gentoo and then back again, and strangely Arch seems harder for it. Not just the install, but including it. My impression is that the wiki is noticeably less useful now, though of course it's still extremely useful. But it increasingly reminds me of digging for hints on Gentoo, when I recall it feeling like the authors were almost prescient at times.

Though I suppose I feel similarly about internet search in general, so maybe I should be a little slower in blaming the wiki...

Really? I don't think that's why Arch is well known. If you gave me just that description I'd be very confident you meant Gentoo.

In my mind, Arch's reputation is not that of a challenge, but more of an ongoing projects that you can soak up as over much time you'd like to dump into it. Basically the OS equivalent of a daily-drivable project car.

Though to be fair, I think one of the pillars of that reputation is the quality of the wiki. And I've been increasingly finding the wiki not living up to my expectations over the last however many years. But (somewhat concerningly) the Arch wiki seems to be as strong as ever relative to other sources, so I'm not sure how that balances out.

Maybe it doesn't, and I'm just behind the times.

This is not actually necessarily true at all, at least not in a useful way. Even if it happens to be true, "with enough data" is a hell of a qualifier for many things, never mind one that involves practicing medicine on real patients.

I can't help but suspect that the brilliant success of machine learning in some tasks with a ludicrous amount of data available has blinded us a bit. "Just use more data" is a seductively easy answer to all questions if we ignore any and all factors beyond what is theoretically possible in the 'true Turing machine on a perfectly flat friction-less plane...' sense.

Mammograms are used for preliminary screening. They are cheap, relatively easy to perform, and close to as (physically) noninvasive as you can get for something reasonably called a test.

So immediately most data is simply unavailable without obviating the entire point of doing better preliminary screening. Any data we can consider without making the entire endeavor pointless will be extraordinarily challenging to work with. Even if you use the magic hand-wave to move few 'little' fields like probably most all of NLP into the realm of the trivial, this is an extremely challenging problem. Even if you can magically encode the entire medical history, you'd have what, a massively sparse set of massively sparse time series? And lots of information is going to be in the relationships of different time series, but also you have to deal with doctors not being a single immutable entity... and doctors can only see so many patients in a day, and they only work so many years, and and andandand...

So many difficulties, so many confounding problems, and so little data to brute force the solution.

And if we somehow rally the world to our cause and somehow throw enough resources at it to amazingly solve all the problems... what do we do for the world? Let's use the best imaginable case. The new test is perfectly accurate, specific, and sensitive. It is instant, risk-free, and otherwise just free in all ways you can imagine, to the point that all breast cancer is now detected at the literal possible earliest moment. Not only that, we can do way better. We can even determine if it should be treated or not.

Almost 13% of women in the US will get invasive breast cancer in their lifetime, but only 2.6% die of it [0]. We can spare that 10% or so of dreadful side effects from chemo, radiation, major surgery, and all that. Just to put the icing on the impossibly-large cake, we can even suggest optimal treatments, so that none of those 2.6% die from treatment. We have effectively eradicated death by breast cancer in any way.

Of course, this would (very seriously) be extraordinarily great. I don't even have the words, so I'll just leave it.

This is best case scenario. Everything is impossibly perfect. We're probably at least a couple dozen plausible-actual-miracles deep. So how does this stack up? Well... 2.6% probably clued you in. Breast cancer is not a particularly huge cause of death. From [1] (if you forgive the year gap), we're looking at something on the scale of diabetes (2.7%). We're well below death by unintentional injury (4.4%). Heart attack (21.8%) and all cancer (20.7%) are the two major ones. But breast cancer, well, isn't the only cancer.

But the other side of the coin is that we expanded preliminary screening to young folks. So maybe if we save a lot of them, we've added more human-years-lived than it seems from total death rates.

Well... no. Mammograms are used later in life for a reason. Younger folks aren't very likely at all to have invasive breast cancer. At 20, 0.1% of women get it, and 0.055% die of it. At 40 (the age suggested in [0] to start offering mammograms) it's 1.5%/0.2%. You get the idea.

Maybe for some age it's at least a significant cause of death? Nope. [1] has a breakdown by age.

So frankly... absolute impossible best-case we mostly prolong the lives of a few percent of the oldest women. Large numbers obviously means there's more than a just a few younger women too, but the distribution of possible beneficiaries is rather skewed towards the oldest.

Still. It'd be unfathomably awesome to see for many reasons - both technical and humanitarian. But the degree of difficulty is extreme and the far, far upper bound isn't quite proportional. There's easier targets with better rewards. My random speculation from thinking about this for way too long to write this is that solving many of those huge challenges along the way would probably be the bigger boon for humanity in the end.

TL;DR (yes it's still long, but relative, okay?) * Preliminary screens need to be simple and non-invasive means way little data, means just throwing machine learning at it very hard * Many very hard problems means maybe tons of data is needed to push through with sheer weight of data, but human interactions can only generate so much data so fast * Not that many people of any age get breast cancer, and far fewer actually die of it * And the age distribution of those who get it skews substantially older... hence the entire reason for mammograms not being used on young folk in the first place... and hence this entirely way too long response to a rather short and probably not-much-thought-of comment

[0] https://www.cancer.org/content/dam/cancer-org/research/cance... [1] https://www.cdc.gov/women/lcod/2017/all-races-origins/index....

I've always loved the concept, and yet was always the student that would scoff when lecturers mentioned reviewing. The problem is "active learning" doesn't work outside of small groups at a similar "level" so to speak (as in background knowledge, dedication, and interest).

Very few college classes meet these requirements. When they did, they were amazing. But otherwise, reviewing just makes it nearly impossible to pay attention as the lecturer slowly speaks the material you already know. And then any questions you may have require too much detail to actually answer in the lecture. It's really quite miserable. Why would you do that to yourself?

I assume the author thinks that would be a good proxy for some hard-to-measure quality, and is not actually aiming to hire the best typists because of their typing skills.

As for what that quality is, I don't see any hints there. It could be anything from general tech-mindedness to even basic diligence or who knows what.

It's not Reuters, but the submitter.

Current Reuter's headline: Long COVID risk no lower with breakthrough infection; COVID-19 survival improves for European cancer patients

Current url: Current submitted url: https://www.reuters.com/business/healthcare-pharmaceuticals/...

The agreement between the submitted url and current headline make me believe the HN submitter intentionally edited the submission title.

(It's not entirely impossible the submitter is innocent in this, but it would require a rather specific sequence of events and some seriously unfortunate timing.)

You've been taken in by the submitter's editing of the article's real title. This applies specifically to breakthrough infections. Vaccines do a great job of preventing COVID in the first place, which naturally includes long COVID.

Specifically, the HN submitted headline. The article headline is "Long COVID risk no lower with breakthrough infection; COVID-19 survival improves for European cancer patients." I don't believe it was a later change given the submitted url matches.

So this is one is fully on the submitter here. How brazen.

Public criticism does not change things only via boycott. I agree with you about boycotts and their at-best questionable usefulness.

The more meaningful aspects are the fact it creates a negative reputation, and that reputation impacts all interactions with the company. A bad reputation adds an additional cost to interacting with you (be it customers, workers, or business partners), and that needs to be constantly paid for somehow.

Additionally, there's some level of 'acceptableness' for the individuals of a company to do unethical things, which also plays a role. You addressed this in your 99% hypothetical, which I would agree with if it was done in a vacuum. However it's not. In practice if 1% of businesses were behaving in some way the rest refused on ethical grounds, lawmakers would be be falling over themselves to address it. Obviously such an example is unlikely to appear, but I hope you get my point. Moving the needle on acceptable behavior also moves the needle on what acceptable regulations of behavior.

I also largely agree on many of these factors being a dynamic balance. It's just that public criticism is already a factor in the current balance. Some level of criticism is required to maintain it, lest we move towards a balance that sees even more bad behavior.

I think it's both reasonable and important to criticize companies for behaving unethically even when it's not illegal. At the end of the day the "company" itself is incapable of doing anything. Humans are the ones actually making these decisions and then actually carrying them out.

Unfortunately we don't and likely won't ever know who exactly did what. The best we can do is point at the company as a whole and say that some people over there decided to do bad things, nobody else in that group stopped them, and then some of those people went and did the bad thing. I don't see why that's not a reasonable critique when we cannot be more specific.

I think that it is also important to do so. The more we perpetuate the idea that companies can't be blamed for bad-but-not-illegal behavior the more we help enable people to make those sorts of decisions as part of a company. They can't be blamed personally - it was the best decision for the company and that's what companies do, you know?

We also help reduce negative feelings towards the companies when they do behave unethically. You can't actually blame them - they're a company after all, right? But this actually helps enable companies to get away with it. Negative public perceptions can impact the ability of a company to make money. I don't see why we should be trying to reduce this kind of influence.

They were obviously just using an analogy with real names to say Amazon does not have a similar-size competitor or three.

I use it for pretty much everything (personal projects), unless it's a one-day/one-run script kind of deal. And even for those little throwaway things... I'm real tempted to use Ada anyway.

It's just so damn comfortable to use that I often have a hard time using other languages now. I think writing down what things mean in the type system helps catch any issues in my approach before I get too far with it. Being able to easily but powerfully write down what things mean in my programs is amazing. I don't need to worry about unloading some part of the program from my head, because everything I need to remember is written down - and enforced by the compiler.

Once I got over feeling paranoid when my programs just worked after they compiled, I found I could actually relax quite a lot while programming. There's just so much stuff I no longer need to be constantly watching out for. It's great.

The approach might work but I don't think in general it actually solves the same problem. While I used integer-like things in the example, it wasn't actually important.

It could be strings (think Apple_Description and Orange_Description) or even more complex type from a library (maybe something like Apple_Throw_Plot and Orange_Throw_Plot).

I don't actually do much OO. I typically stick with Ada. It does have OO, but I rarely reach for it if I don't need it. Most of my typing interests are actually from the non-OO side.

Too much detail is around in a far too large response to another commenter, though I can't actually suggest it... But at least a bit of the start should provide a little more detail on what I'm looking for with types.

I spent far too many hours of my life writing a far too long response to another comment. Some... portion of it touches on some of this. I can't in good faith suggest reading it, but you could.

But the more specific and quicker version - I don't find Java is typed the way I want either. It seems to somehow find a way to be too much and not enough. I also don't do a lot of Java, so YMMV. Specifically I'm thinking of Ada when I start comparing type systems, if that helps.

I'd need more brainpower and probably Julia chops to give those a real shot. However I started to get a 'build your own type system' vibe from some of what I was seeing while nearing the end of that gargantuan post. This feels like some initial level of confirmation, so yay?

I'll give it a look later. I'm curious how far you can integrate it with external code, what sort of guarantees you get in practice, and how much it requires doing 'the right thing.'

Maybe in practice the way dispatch works ends up taking care of more problems than I'd expect, but also seeing the fairly widespread use of implicit conversions makes me a bit concerned. Again, maybe a thing sidestepped by other factors.

Ah, that would explain it. I was using Firefox. That probably should have occurred to me too.

Yes, I intended both to be integers - but in general they could be anything and the overall idea applies.

The overall idea is to be able to tell the language that an Apple_Count type represents an integer value and some extra meaning that is unique to the Apple_Count type. Additionally we specify that Apple_Counts interact with other Apple_Counts in the same way integers interact with integers, and that the 'unique meaning' of the type always passes through the operation unchanged (I'm sure there's some cool math term for this?).

Meanwhile we don't say how to mix together the 'extra unique meanings' that come with the _Count types, so any attempts to do so lets the compiler know to yell at us, because that's just nonsense according to the rules we provided.

This kind of perspective applies to every single variable in our programs - they all mean something* beyond their basest value to us, even if it's a string for a joke you haven't cleaned up yet. So my desire is to specify all the general kinds of meanings in my programs, and then be able to describe how all of those types of things can and cannot meaningfully interact when transforming the input into the output.

I've been awake and writing this for far too long and am just going off on wild and grandiose tangents, so I'll try to actually be brief. I've been totally convinced by this sort of approach. The problems uncovered are all very 'real' problems. All of them result from some basic incompatibility between the fundamental 'what' and 'how' of your program.

If you want more detail at how this all can (not must by any means, but can) work, I encourage you to look at how Ada handles type derivations (aka derived types). Do be aware Ada also uses the term 'subtype' but in a very different way. An Ada subtype, more or less, specifies a subset of values from a base type.

---

As far as Julia goes, it's been awhile since I looked into it all that much aside from a bit of a refresher this evening. The I believe the overall point is roughly correct, but I don't stand by the details, and neither should you.

Julia has at least a few issues that mean the kind of type safety I really desire is not trivially easy as the language currently exists - at least as far as I know. Unfortunately the ease-of-use of this kind of thing seems to be rather binary - it's either easy or it's hard. Partly I think that's because of how pervasive the concept is. Even a small amount of boiler plate balloons quite severely even for very simple programs.

However some of the problematic aspects of Julia seem like they might have existing solutions. For example the multiple dispatch mechanism is happy to mix and match any and all types, but type parameters provide a high degree of control over what methods are available to match in the first place. These features seem - to me anyway - to be powerful enough to have some serious potential* for making Julia one of the nicest languages to try to bolt all this typing onto after the fact. (Or maybe there's a little too much complexity to allow very nice solutions, and then the sheer number of type interactions drags Julia down to be one of the worst. Who knows!)

But subtypes of concrete types - or rather their lack - seems different. However I'm increasingly reluctant to say much more about this in any kind of useful detail. (Yes, the irony burns.) What was supposed to be a short look to confirm a few things has led me down a massive hole. The size of this hole seems to be increasing the deeper I go, and I think the expansion is accelerating. I've also passed by a few other, possibly equally sized holes along the way... I don't think I'm even that deep, and it's already pretty scary. Although I'm well past the point of firing on all cylinders, I don't think it matters down here, in the dark.

But anyway. My basic thoughts, some or all of which are probably irrelevant to varying degrees depending on how far down the hole/s you've gone.

The very general issue with the lack of concrete subtyping - at least assuming you can get at least something out of it - is that the main alternative appears to probably largely be struct wrapping. That's the closest thing to a concrete statement I have for this section. It's a big, big hole.

Struct wrapping sucks. It really, really sucks. Julia seems to do thing that both make it better and worse than it could be. In terms of making it worse - the lack of abstract composite types (though they seem to have gotten some recent attention!). This seems like it could rule out at least _simple_ methods of making the wrapping process that much nicer. Even if you did make an abstract type to grab all the behavior from the composite type of interest, you'll still need to copy the whole damn struct every single time you want to make a subtype. It might save you from all the forwarding for them all though? Maybe? Maybe not?

Even for non-composite types, any time behavior isn't implemented on an abstract type you may be looking at doing more struct wrapping. A brief glance around the standard library does not show a tendency to restrict the implementation of behavior to abstract types. I don't know if that's a common trend, but I didn't see anything in the main documentation even suggesting you might want to adopt such a practice either. So, probably means quite a fair bit of struct wrapping maybe, I think, unless you want to venture down one of the bigger holes.

Open questions. What the heck does a Union over one type actually do, and is it useful for wrapping things like this? Seems like maybe? But I can't find any mention of anything about it, and after venturing this deep I'm no longer willing to hope I can even begin to actually judge it just by poking at it. Can you shoehorn in parametric types somehow? At some point it feels like you're just going to have to write your own type system though. Primitive parametric types seems promising in principle, but I have a feeling going that route means you might just end up giving up on any code you didn't write yourself. Does "solve" the wrapping problem though...

And then macros. I.. yeah. Macros. Good, evil, both, I don't know anymore. It seems like some aspects of struct wrapping have been made easier to by them to various degrees. In some cases it appears to be better but still probably a bit of work, in others... I don't even know. And how wise is it to even dive this particular hole? I don't know. It's a thing. It might help, some. But something makes me feel only wizards are going to end up saving time this way.

I dunno. I give.

[The below was written earlier, before I had first glimpsed the Holes. Now, well. The pure naivety may be worth a laugh.] *Wild and rampant speculation warning. I can imagine it may be possible to create a stricter version of the existing type hierarchy that adds subtype equality checks to their methods. Maybe it would even be trivial to convert existing code simply by defining those methods without the subtype checks. Nothing that sounds so good is ever so easy, but hey. This does sound similar to how convert (which itself might be a whole other thing you'd need to tame...) is handled though, so maybe?

Every time Julia pops up I can't help but get disappointed all over again. I was so intrigued by multiple aspects of the language, and even the type system seemed promising at first. However the inability to subtype concrete types is a total dealbreaker for me.

Everything else - even much of the type system - is extremely interesting. However the inability to subtype concrete types means you are essentially stuck with the unfortunately common inability to trivially specify how the heck your program is modeling your problem.

I just want the ability to specify an Apple_Count is not an Orange_Count without having to define my own damn operators. Why do so many languages make this so hard?

And Julia was so close, until one little sentence moved it so far away.

Edit: I now believe the website was, in fact, changed.

Original comment below, most individual bits still relevant aside from the overall conclusion that the pieces added up to accidental confusion. Apparently concluding HN folk were bad at understanding even poorly displayed tech was not wise. Who knew? I probably should have realized that was not a good bet.

At this point I consider the apparent lack of understanding from the OP willful ignorance at best. All this seems like kind of a waste now. Oh well.

---

Unless the website was recently changed (final edit: yeah... unless...), I think the problem here is a combination of the link that was submitted and uh... excessively effective design, if I want to put it nicely. You're doing too good a job of directing attention to the extension, and people are missing the actual means of using your website.

Right now the link is https://you.com/search?q=you.com&fromSearchBar=true. That page currently has a little search bar in the top UI bar which is prefilled with a search term, and the contrast that identifies it as a text input is pretty minimal. Dark Reader further hides that fact with some elements like the 'x' in the input not getting adjusted to be more visible. These aspects make it extremely easy to overlook as a text input. My first instinct is to ignore it as part of the wasted space in the top bar, and it does a poor job of standing out as anything else.

Furthermore the banner for the extension is pretty freaking huge and draws all the attention. The copy on it also pretty strongly implies you need it to use the website.

The multiple comments from other HN folk that have clearly been mislead about the importance of the extension further feeds that perception. I'm sure some people haven't even actually checked for themselves - I know I almost didn't. It also wasn't immediately obvious to me what was going on once I did visit the submitted page, and I nearly fell into the same trap.

Meanwhile https://you.com/ offers a much more familiar design that does not contain so many opportunities for confusion. I think you may have been better off submitting that.

While I'm at it, I have few other thoughts. I continually find myself expecting many of the non-ads to be ads. I keep ignoring them or even getting annoyed with them, until I remind myself I should look again. This happens on both the submitted page with the various blurbs/links down at the bottom and the search results page. My very first response to attempting a search was essentially a dismissive and annoyed eyeroll as I thought you'd tried to load up an entire screen full of ads.

I'm not entirely sure what the whole problem is. I'd guess it's partly being conditioned by other search providers about the very top 'results' and partly the overall style. Maybe grids of little boxes with so-perfectly-rounded corners and strong titles just seem like ads to me. On the submitted page, I'm sure having a bunch of company names there in the Media section doesn't help.

Again, this is just my immediate impression of the UI elements. I don't believe them to actually be ads, but I'm constantly having to fight my instincts to treat them otherwise.

I'd guess it's due to the fact the culprit is a 67 year old woman, and her fraud resulted in increased maintenance costs and not the loss of any subs or sailors. For better or worse the end result has always played a huge role in how these types of situations play out.

On top of that, it seems incredible to me that something so important could/would have such a single point of failure and that there was no redundancy or other safeguards.

I can see why somebody might decide keeping the number lower is better for everybody directly involved.

> I believe it is good default, as 90%+ of their users (would) care more about accidental data loss than privacy.

I think you're right about the numbers, but I don't understand why that justifies the default. Why even have a default? Why not just ask users what they want? It's not a hard question, and it even has the benefit of helping inform users about the feature.

> Yes, that's a very controversial move. But they made it client-side because it's more private than server-side.

So? Either it respects privacy or it doesn't in this kind of discussion. Lauding them for violating your privacy but not as much as they could otherwise is like lauding a mugger for only taking half of the cash in your wallet. Yeah it could have been worse, but that doesn't change the nature of their actions.

I don't think the argument here was to provide a single path with maximal dopamine-per-action.

The original statement was to make sure repetitive and boring paths weren't highly effective.

Your own characterization of grinding in WoW fits that description. It may be repetitive and boring, but it's not highly rewarding so those who engage with it do so because they are enjoying it for it's own sake. This is fine, the players can do it if they enjoy it and won't make themselves suffer through it if they don't.

(My own experience with WoW and the term 'grinding' in general does not make me inclined to use it as an example of an unrewarding activity that players don't force themselves to engage in entirely for the sake of the in-game results, but maybe things have changed... it has been awhile.)

Not necessarily. It's not immediately intuitive is all.

For example, maybe krill do a poor job recovering nutrients from dead krill, while they do great job of it with whale waste. In this case, whales would keep the overall amount of nutrients available to krill high while also consuming them.

Who knows what's actually going on here, but it's really not difficult for these sorts of highly interrelated systems to end up with counterintuitive dynamics.

I don't understand why that would be important.

The only value in responsible disclosure is protection of users. If you figure out there's a way to harm a boatload of people, it's nice to do what you can to ensure it can't happen before telling everybody how. It makes sense. But there's a very good reason it comes with a not-too-distant deadline before you give up on it.

But this? We're talking about finding ways that people are being actively harmed. How does "responsible disclosure" come into play here?

The only thing it would seem to do is to protect companies and their bad decisions. That's not the point. At best they've screwed up, and at worst they're actively malicious. How do users not deserve to know that they are being harmed as soon as possible? How do potential users not deserve to know that they will be harmed by using the product, and that the company is either doing a poor job of protecting them or actively trying to exploit them?

There's no reason to try to attach any ideas of "responsible disclosure" here unless you're explicitly trying to protect the vendor.

This is a hell of a comparison to try to make. How many people do you think regularly run into this kind of issue in Postgres? How many people do you think regularly run into the Python GIL?

Even if we assume your premise that vacuum is at least as bad as the GIL is correct, this would easily explain it.

Add in the sheer difference in expectations between a programming language and a database... and well, I don't think there's any mystery here at all. There's easily multiple great explanations, even if your premise is correct.

> you can't just say "complex interaction" and still call this a consequence of climate change when the causation is absolutely unclear beyond "less water = warm = bad".

I went out of my way - several times - to mention I was not presenting an opinion on the actual cause here. I don't know if global warming caused this. Hopefully the third time will be the charm.

I was arguing that the dismissal of global warming being a possible cause on the basis of it changing too fast was unreasonable.

> The grandparent explicitly asked whether climate change is the reason in this specific instance

No, they very specifically said they found it hard to believe climate change could be a cause because just a year or two ago it wasn't a problem. They did not ask if climate change could be a reason, but said that due to the timing they thought it made climate change significantly unlikely to be a possible cause.

> It might possibly be, yes, but the fact that 2019 had a lot of water (when climate change was arguably worse since there was no dent in emissions by lockdowns) needs some explanation.

In fact, you continued with the same mistake they made, so I apparently did not make a clear argument the first time. Hopefully I can rectify that.

Let's start with a much simpler example. A bowl of ice sitting out at room temperature. Now graph the temperature over time. You'll see it rise for a bit, then stop at 0 C for a fair while, and then start to rise again.

You can't look at just the temperature to determine the total energy the bowl is gaining. Just because the temperature rise stopped at 0 C doesn't mean the temperature won't continue to rise in the future. The fact the temperature stopped at 0 C is just a result of the physical nature of the system. Similarly, the nature of the ice changes suddenly. It's solid until it's not.

These effects aren't nice and linear, or even particularly smooth. You can't just take two arbitrary points in time and come to any great conclusions about the system.

It's also important to realize that this is a single very simple hypothetical. In reality there are many changes that weren't relevant due to the simplicity. Take the change from solid to liquid. In a bowl, not a big deal. But what if it's a permanent glacier on a mountain? As ice it'll basically sit there. As water, it leaves. Now the mountain is in a very different state, and won't behave the same as it did in the past. The area around the mountain also gained a bunch of water, which will change the systems there too, and then that just spirals outward. Classic butterfly situation, except instead of a butterfly flapping it's wings we just melted and moved however many millions or billions of metric tons of water.

And water can get involved in all sorts of fun stuff. Ice looks positively boring in comparison.

There's a reason I can't find a better way to sum this up than "complex interaction." I agree that's not a reason to blame climate change for anything in particular, but it's absolutely a good reason not to dismiss it as a possible cause out of hand just because some simple correlation didn't happen the way you thought.

It's not simple, so you can't expect it to behave simply. Coming up with a simple correlation and demanding it be true is just not reasonable.

> (when climate change was arguably worse since there was no dent in emissions by lockdowns)

This is just not true. Emissions are not directly causing heating, but causing more heat from the sun to be trapped. Think of it like putting on blankets. If you've thrown on three blankets already and then take a few minutes to decide to grab a fourth, you aren't suddenly colder. You're still just as warm as before, and warming up just as fast. You're just slightly cooler than you'd be if you'd grabbed the fourth blanket faster.

So even if there was a simple and direct relationship between temperature and river level, you really would not expect any kind of year-to-year response to emissions levels. No explanations are required.

> And if your observation doesn't match your thesis, simply saying "complex interaction" is not sufficient

I hope by now what I was trying to say is clear. You can't assume your thesis is correct, even if it seems nice and simple. It's not a safe assumption when you're dealing with such a complex and chaotic system.

We don't know what kind of variable the water level is, or how to expect it to behave. Does it have jumps and halts in it, like the temperature of water/ice? Is there some threshold effect and it'll appear to just suddenly change nature like ice turning to water?

And something like the water level of a river is not going to be as simple as an ice cube melting. It's going to be a combination of other systems that also influence each other. But the root causes - if you trace them back far enough - will be things like how ice melts. So you expect to - and do - see effects like you see there. Sometimes things don't change much until they change suddenly. Sometimes something seems to stop changing, even though the cause of the change is still happening.

But without knowing those details, what kind of thesis can you come up with that even has a shot of being halfway decent?

You can't. That's my point. The thesis is no good, and shouldn't be used. The thesis is assuming the ice changes temperature smoothly, and is doing so a hundred or thousand times over. It's so oversimplified that it has no power. When the observation doesn't match expectations, it tells you nothing. There was never a good reason to expect the observation to match in the first place.