lad

Because it’s a computer banana and the mascot is real? I don’t know, this makes no sense, but I can see how sometimes this kind of mix can work

MacOS does this, but on screen recording it never shows it. Feels good to see Linux records what user actually saw

Oh, that explains it. Well, I imagine a license that also forbids people to imagine it. Fuck you and your imagination

The screenshot seems to violate the licence it contains.

I meant ‘make sense’ to mean ‘could rewrite without garbage’. Maybe I was wrong, anyway

I’m afraid, LLMs are gone a bit further from the state when such ‘poisoning’ made sense.

I’m afraid that soon this may reach a point where it will be easier for LLM to make sense of the text, than for a human, if this idea gets further development.

but what else could be representative /s

once the tool no longer works, you

… try every trick to make it look like it works, blame everyone for not using it, blame everything for not working the way it should, break some things that are made with other tools that work for a good measure (it was their fault for being too arrogant, anyway)

Reminds me of one site that said I shouldn’t use ‘git secret’ because reasons. I’ve spent quite some time to find what do they propose to use instead (that wasn’t as straightforward as in this article), turns out they provide a ‘solution’ that includes their partners’ system to manage secrets. Another bullshit, in other words

You got me, I decided to read the article later (I hope to, at least). But your summary looks about right, I don’t really expect C++ to become much safer than it is now, which is not very much. Should take a look at profiles, I love a good laugh

Edit: looked up those ``profiles’', it looks like a vague and complicated proposal that will require an unrealistic amount of undertaking. But that might be seen as being in the spirit of C++

Later: short summary of the conclusion of what the committee does (read 307 minutes)

This is almost what I need for my ancient meme folder

Reasonable and viable ≠ RFC compliant

This quote summarises my views:

There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard.

This is the ideal rendition, I would say. On a related note, I just love it when there are backspaces in my filenames

There are many regexes that validate email, and they usually aren’t compliant with the RFC, there are some details in the very old answer on SO. So, better not validate and just send a confirmation, than restrict and lock people out, imo

and which of these two you are going to get paid more for

It looks like exactly 4 characters are missing, so public and static would fit, but I never saw static instead of public static, so I think you’re right. On the other hand, I don’t use Java anymore and couldn’t be bothered about such details

Depends on what was the course about. If it’s about computation, then sure. If it’s about OOP or architecture design (this one I wouldn’t expect, unfortunately, but would be nice if it was taught somewhere), then the point is not just to run something.

I mostly come to prefer composition, this approach apparently even has a wiki page. But that’s in part because I use Rust that forbids inheritance, and don’t have such bullshit (from delegation wiki page):

class A {
    void foo() {
        // "this" also known under the names "current", "me" and "self" in other languages
        this.bar();
    }

    void bar() {
        print("a.bar");
    }
}

class B {
    private delegate A a; // delegation link

    public B(A a) {
        this.a = a;
    }

    void foo() {
        a.foo(); // call foo() on the a-instance
    }

    void bar() {
        print("b.bar");
    }
}

a = new A();
b = new B(a); // establish delegation between two objects

Calling b.foo() will result in b.bar being printed, since this refers to the original receiver object, b, within the context of a. The resulting ambiguity of this is referred to as object schizophrenia

Translating the implicit this into an explicit parameter, the call (in B, with a a delegate) a.foo() translates to A.foo(b), using the type of a for method resolution, but the delegating object b for the this argument.

Why would one substitute b as this when called from b.a is beyond me, seriously.

Even if it is not their fault, what people see is that they provide bad quality service. Very low percentage ofthem will care to read details when Netflix publishes a post-mortem of an issue, assuming they even do.