Well glp1 doesn't make you want to eat broccoli. Just less in general

Actually there is a very real effect on which foods you find appealing and which ones are kind of gross. It’s a thing the food companies have been studying, and their own studies show that people on GLP1s tend to skip the junk food aisle and head towards the produce section instead.

Oddly enough semaglutide is making me crave sugar more. It might be the frequent sensation of having low blood sugar. Idk.

It does make me choose more dense meals though since I know I can't eat that much due to delayed gastric emptying. But I have to budget some room for prunes to counteract the constipation. It definitely makes you think about what you eat.

Tirzepatide somehow gave me a craving for apples. I used to occasionally eat them, now I eat them every day.

I can confirm that. On GLP-1s (when they worked for me, anyway), I'd routinely think "pizza? Bleh, so fatty, I'd really like some chicken breast with roast potatoes instead right now".

You can confirm that GLP1s make "carbs specifically disgusting" and an example of this reaction is that you would have a desire to eat potatoes?

Oh no, you have torn through the flaws in my argument like bullets through paper, however will I live this down? Unless I clearly meant "it makes previously-desirable food undesirable", anyway.

I was not trying to tear your argument down. The comment you replied to was about carbs being specifically disgusting and in my head potatoes are the runner up to bread for classic examples of carbs. I was simply asking about what seemed like a contradiction. I have been looking into GLP1s and have not seen/heard people mention that GLP1 make carbs gross.

I think it varies per person. For me, it didn't specifically make carbs gross, but it did make unhealthy food less palatable. I think that's what the GP was talking about as well, they were just a bit more specific.

It really depends on the person, though. They worked for me for a while and don't work now, but I'm a small minority, from what I've heard from people. When they worked, they were great.

Funnily enough, not an article on grokipedia

To anyone wondering, I believe it's cursed because the finally continue blocks hijacks the try return, so the for loop never returns

So the function returns, and then during its tidyup, the 'continue' basically comefrom()s the VM back into the loop? That is, indeed, cursed.

I would not call this snippet particularly "cursed". There is no "aktshchually this happens, therefore this is activated" hidden magic going on. The try-catch-finally construct is doing exactly what it is designed and documented to do: finally block is executed regardless of the outcome within try. The purpose of finally block is to fire regardless of exceptionality in control flow.

Surprising at first? Maybe. Cursed? Wouldn't say so. It is merely unconventional use of the construct.

It messes with the semantics of "return" statement. The conventional intuition is that right after a "return" statement completes, the current method's invocation ends and the control returns to the caller. Unfortunately, the actual semantics has to be that is "attempts to return control":

    The preceding descriptions say "attempts to transfer control" rather than just "transfers control" because if there are any try statements (§14.20) within the method or constructor whose try blocks or catch clauses contain the return statement, then any finally clauses of those try statements will be executed, in order, innermost to outermost, before control is transferred to the invoker of the method or constructor. Abrupt completion of a finally clause can disrupt the transfer of control initiated by a return statement.

This, I believe, is the only way for "return E", after the evaluation of E completes normally, to not return the E's value to the caller. Thanks for a needless corner-case complication, I guess.

> It messes with the semantics of "return" statement.

Yes, that's what exceptions and their handling handling does - it messes with control flow.

> The conventional intuition is that right after a "return" statement completes, the current method's invocation ends and the control returns to the caller.

It is part of similar conventional thinking that "a method call must return back to the caller on termination", which is not even applicable to Java and other languages with conventional exceptions.

> Thanks for a needless corner-case complication, I guess.

But what is the alternative otherwise? Not execute finally block if try block exits normally? Execute finally block, but ignore control flow statements? What if code in finally block throws? I maintain that execution of finally block, including control flow statements within, normally is the only sane behavior.

> It is part of similar conventional thinking that "a method call must return back to the caller on termination".

No, it's a part of a conventional thinking that "if a return statement executes without any exceptions thrown in the process, then the control will return from the current invocation". It's an extension of a conventional thinking "if an e.g. assignment statement executes without any exceptions thrown in the process, the control will go to the next statement". Really helps with reasoning about the program behaviour without spending an undue amount of brainpower.

> But what is the alternative otherwise?

Disallow "return", "break", "continue", and "goto" statements inside "finally" blocks, like C# does. Nobody sane misses this functionality anyway.

finally stuff is executed prior to the 'return'; effectively it's placed before the 'return' statement. So it's quite obvious.

No, it's not executed before the return, it's executed in the middle of it, so to speak:

    class Main {
        static int f() { System.out.println("f()"); return 1; }
        static int g() { System.out.println("g()"); return 2; }

        static int h() {
            try {
                return f();
            } finally {
                return g();
            }
        }

        public static void main(String[] args) {
            System.out.println(h());
        }
    }

will print

    f()
    g()
    2

If "finally" block was executed before the "return" in the "try", the call to f() would not have been made.

Yes, very much is... return is not a single statement or a single opcode. the call to f() is returned on the stack, that's assigned to some local variable via istore, there is no 'ireturn', yet. Then the g() method is called along with whatever is printed, and the next instruction can be ireturn. which would return '2' indeed.

> return is not a single statement.

It is a single statement. It's just that executing it contains of two parts: evaluating the expression, and the non-local transfer of control ― and the weird part is that this control transfer can be hijacked. And it is weird, you can't do this with e.g. "if": if the test condition is evaluated successfully, then the control will go into one of the branches, and you can't mess with that... but with "return", you can abort this transfer of control. Which is, again, weird: all other expression-evaluating statements can go haywire only if the evaluation of the expression inside them throws an exception — but if that doesn't happen, the control transfer is completely trivial, with no special rules about try-catch blocks.

> control transfer can be hijacked.

But useful. Similar to Go's "defer".

Go's "defer" can't prevent return from actually returning from the function. Most of the time, it can't change the computed return value either, unless you go out of your way and use named return values. Go's "defer" also can't do crimes with "break" and "continue".

So Go's "defer" has more "and also do some things on the way out" semantics than "you suddenly forget why you were going to leave the kitchen, so you don't".

you cut the statement in the middle, it's very obviously in terms of bytecode as we talk about bytecode generation.

Mo, we were talking about what would be reasonable semantics for the interaction of two features in a high-level programming language Java; the semantics of bytecode doesn't really matter in this case. The precedent for that would be that "finally"m in fact, really doesn't mesh all that well with what is available for bytecode, so javac has to resort to code duplication.

Sufficiently unexpected (surprising) is cursed. If anything, that’s the way most people use that term for programming language constructs (weird coercions in JavaScript, conflicting naming conventions in PHP, overflow checks that get erased by the compiler due to UB in c/c++, etc.)

> Sufficiently unexpected (surprising) is cursed.

I think there three distinct classes of surprising that fall under this umbrella: 1. a behavior overrides another behavior due to some precedence rules 2. behavior of a construct in language x is different than behavior of similar construct in most mainstream languages 3. who in their right mind would design the thing to behave like this.

Examples could be: string "arithmetic" in most dynamically typed languages, PHP's ternary operator order of precedence and Python's handling of default function arguments. In all of these cases when you sit down, think about it and ask yourself "what's the alternative?", there's always a very reasonable answer to it, therefore, I think it is reasonable to call these behaviors cursed.

In this case the surprise factor comes in, because we are used to equating finally block with cleanup and I concur that many would trip on this the first time. But if you gave this exercise some time and asked "what should happen if finally block contains control flow statements?" the reasonable answer should be "take precedence", because the behavior would be surprising/cursed otherwise.

That's my reasoning.

> In this case the surprise factor comes in, because we are used to equating finally block with cleanup and I concur that many would trip on this the first time. But if you gave this exercise some time and asked "what should happen if finally block contains control flow statements?" the reasonable answer should be "take precedence", because the behavior would be surprising/cursed otherwise.

Wouldn't the reasonable behaviour be "throw a compiler error"?

Can the compiler perform sufficiently deep static analysis to cover all possible cases? At least in Java it is by definition impossible.

If it's that hard to figure out what the code should do by looking at, then it's probably not a great thing to allow in the language.

I don't see why not. If it's in a finally block, disallow control flow. Or am I missing something?

> But if you gave this exercise some time and asked "what should happen...

This applies to any cursed JavaScript code too (see https://jswtf.com). The increased cognitive load required to figure out unintuitive/counterintuitive code is what makes it cursed.

It's been many, many moons since I touched Java but I would have expected this to run the finally { } clause and then return from the function (similar to how in C++, objects on the stack will run their destructors after a return call before the function ends. I certainly wouldn't expect it to cancel the return.

see, if you only had GOTO's, this would be obvious what is going on!

You can't break encryption "only sometimes"

If you don't record every conversation that happens in a private home, you can't retroactively wiretap them "only sometimes". If you don't open and scan everyone's mail, you can't go back and read the ones they've already received "only sometimes".

Why is that a problem? Then you just don't do it at all. Society can survive two people being able to have a private conversation.

It's extremely common in graphic design because it's so easy for everyone to have an opinion.

> Honestly, a simple data-driven heatmap showing which parts of the code change most often or correlate with past bugs would probably give reviewers more trustworthy signals.

At first I thought this to but now I doubt that's a good heuristic. That's probably where people would be careful and/or look anyway. If I were to guess, regressions are less likely to occur in "hotspots".

But this is just a hunch. There are tons of well reviewed and bug reported open source projects, would be interesting if someone tested it.

> If it’s on the web, it’s digital, there was never a period when blogs were hand written.

This is just pedantic nonsense

It needs MIR

You can go yell in the others people ear

No. RAID 5/6 is still fundamentally broken and probably won't get fixed

This is incorrect, quoting Linux 6.7 release (Jan 2024):

"This release introduces the [Btrfs] RAID stripe tree, a new tree for logical file extent mapping where the physical mapping may not match on multiple devices. This is now used in zoned mode to implement RAID0/RAID1* profiles, but can be used in non-zoned mode as well. The support for RAID56 is in development and will eventually fix the problems with the current implementation."

I've not kept with more recent releases but there has been progress on the issue

Fixing btrfs RAID6 is becoming the Duke Nukem Forever of file systems