quelltext

You are writing a GC in Java, yes but have access to low-level memory abstractions/interfaces, right?

Whereas I was initially wondering how to write a GC in "pure Java" that doesn't have access to low-level memory interfaces.

Does it make sense why I was asking, now? Or am I still not getting it?

To be clear, Java the language is Java, I'm not going to argue that it's not Java because of special primitives / interfaces available to write the GC here, but it is not what most people would think of when considering the limitations of the runtime everyone's using.

To be fair, I agree that seeing bad examples of its use shown by one of the other folks here, some could have been avoided by them being forced to inline, but funnily those examples still exist despite the desires of the function author.

Nothing was achieved here.

What documentation though? There's an internal comment but it's not documentation and it's not really arguing against the use of this type of comparison (just against use of the implemented function).

If the documentation for this function went on along the lines of "we discourage the use of 3 way compares as we consider it an antipattern, do X instead, there's literally no reason to ever use 3 way compares, we know it, here's why..." maybe, but it doesn't.

Now, maybe 3 way comparison is not common but it is a distinct operation with known optimization opportunities. I wouldn't readily claim that the operation is not needed by anyone.

...and thus very likely end up with buggy code.

The author seems to assume nobody needs a three way compare, which I feel is assuming a bit too much.

In particular because it is there because someone is using/needing it already.

Basically their comment actually says that everyone who does need a three way compare should just re-implement what they wrote there (and maybe they'll make sure everyone's code is optimized later). Sounds pretty bizarre to me to discourage code reuse. And if three way compares are a pattern they want to discourage in the first place it should be elaborated on in documentation.

Others have already talked about the performance aspect but I'm just baffled at the comment basically saying nobody should use this function anyway.

I expect the need for 3-way compares isn't that uncommon, why tell people not to use it?

It's great to have this idea that the compiler should optimize all comparison situations but a) it doesn't yet and b) people still want a 3-way compare function anyway.

Basically it's saying "don't use a function at all", or even "write your own copies of this function". Even if the compiler one day becomes smart enough to optimize you still end up with tons of code duplication if people followed the advice.

And for people who care about performance it means they'll use a 3rd party library or implement their own "optimizations" that might not be effective or even buggy.

Literally nobody is benefiting from this.

What's the point of providing this function but actually thinking nobody should use it, in a comment no less instead of documentation?

Now, there may be other reasons, e.g. the author thinking 3-way compare is a bad pattern in the first place. If argued well, maybe I could agree. But that argument isn't made here.

I'm also not saying they needed to optimize this off the bat. A comment saying "we don't think there is a big demand yet, will optimize when we see the demand" would've been acceptable.

Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?

Is there any evidence for this?

Is it a definition issue?

My grandparents and some people in my parents' circle of friends are not computer-literate. And by that I mean they don't know how to use double click, what a file or browser is, or even how to use a touch focused device. They are utterly unfamiliar with the abstractions and UIs computing devices afford.

Even in my generation many kids didn't have PCs or devices with interfaces more complex than an NES until later in high school.

That is different today from what I've observed. It's true that for many the first computer is not always a PC as I would have had, but a smartphone or a tablet. But does it matter? They are able to harness the power of computing devices to get things done.

Needing to know how computers work internally, or making use of traditional computers with mice, keyboards and monitors on a desk, these things were never really the definition of "computer-literate".

The one scene where a student appears to succeed (this clip is spliced in after the segment where the professor says "it's not the case [it's not a trick question]") is not with the light bulb they were given (they essentially say "here, I can show you, see, with a small bulb I would do this and it works", laughing which to me indicates they didn't get it done with the initially given large bulb).

But maybe not? Maybe they were given several bulbs to choose from. And yeah some people clearly didn't figure out the basics ("I need two wires"). The others, unclear, they showed short cuts of them fumbling around (possibly after failing a few times) but they might have already tried the right approach before that.

The core issue with the video is that it doesn't establish a base line. What is it they expected from the students? That they identified they cannot do it with just any bulb or any battery before saying yes? I don't think so, based on the professor interview that really seems to imply that the folks should know how to do it (and get it done).

If there was a way to do it they should have shown. They just go on to folks saying "see, we need to teach the basics better" and I still don't know how it connects to the "experiment".

The way it stands it really does seem to be designed to make the graduates fail the test without making clear (to the viewer at least) what the test really was.

I mean at this point I'm not even clear if the reporters were the stupid ones not realizing it cannot be done. Again, they didn't show it. It's more likely they did actually make it impossible / pose a trick question.

I am not doubting the professor as much. They probably conducted an actual experiment that showed a significant number of subjects (was it MIT grads though) weren't able to accomplish it despite feasibility. It's just that the adhoc on-video tests there seem to provide a false hook into the story, like all these types of on the street interviews.

Not only hiring. A coworker was blocked from organizing some technical community event because among the 5 speakers who applied to present only one was "x".

I get the sentiment behind such quotas but it's not always realistic. I think a fair way to look at it is, if the environment is such that "x" are discouraged from participation then it needs fixing. But it should be easy for the diversity team to go identify such an issue and tell the organizers to fix that rather than saying "meet quota or no event".

For hiring, it's fine to look at numbers and identify a skew pattern and to look into why it may exist and how to counter, but just asking for percentage alone is not helpful.

What does that mean? Last time I heard this it was in the context of firing, or rather preparing conditions to simplify the process.

Is it a euphemism for making their work life difficult so they are likely quit on their own (e.g. assign only difficult customers to her)?

Or is it more about establishing conditions that allow firing that are unrelated to the protected class aspect (e.g. assign all non cancellation tickets, than dismiss because they cannot keep up with the load)?

Whatever it is "managing out" just sounds shady.

It's still a footgun. It's pretty clear that this shouldn't be done, so why allow it this easily?

In prod it should emit a log message saying "you cannot do that. if you really, need to follow these steps: <something cumbersome like placing a file somewhere with some dedicated end date for debug mode, or scoping rules>"

> The environment configured on the live site was actually set to production, but the configuration also has APP_DEBUG=true set which is why a 500 server error response was giving such neat and useful output.

It should be easy to add additional safeguards / warnings to prevent this combination from being set.

It's not wrong. Someone used a leaked API key to do card testing. That explains why someone might be interested in the API key. However, the bigger part of the story is that Laravel or whatever framework they used has a dangerous footgun that can easily lead to exposing secrets.

Aside from that I agree, so far TRoP has been close to or better than expected. I'm not sure what people expected here but at any rate it's too early. You would't want to judge LotR based only on the initial chapter either.

Also: forking /= stealing

I don't quite get how a framework can be described as "it's a virtual DOM that's fast". I kind of get what they mean, but is there no better term? E.g. "virtual DOM engine", "virtual DOM runtime", "virtual DOM renderer", maybe?

How can metropolitan France be larger than the entirety of Germany?

Gumroad itself uses Stripe, it seems so if Stripe decides to hold funds it's likely Gumroad will just forward that experience to you.

For instance, if you need to deal with an external API and you need to avoid the same request going out twice and you have logic that could in theory lead to that, e.g. via concurrent retry mechanisms, at least once semantics, etc.

What's the solution for ensuring code execution under mutual exclusion in a distributed system?