It should be right-aligned so that the timestamp and status is visible against a light background. But it’s left-aligned due to a bug.

No, the US isn’t a democracy either

deleted by creator

Of course it would be wrong. And not hypocritical.

But I guess a Trump voter like you would never understand the difference.

You are still missing the point, judging by the “to justify it”, since I never said anything is trying to justify anything. I just recognize the difference between “bad” and “hypocritical”. You can do a bad thing and not be a hypocrite, you can do a good thing and be a hypocrite.

If you use a car. You are okay using cars.

Correct. Which doesn’t conflict with my point at all. The person in that example is okay using cars. Where they are legal. And wants to make them legal in less places. Nothing hypocritical about it.

I agree. And I think that not in all of such situations you would be misaligned with your values.

For example you may argue for making cars illegal, while you yourself own a car. You are not being a hypocrite, you are hoping that if cars were illegal, society would become more bike-friendly which is your ultimate goal, enabling you to stop needing a car.

Key point being that you are not telling others not to own car, or not to buy investment properties while you yourself do. That would be hypocritical. Arguing for these things being illegal is not hypocritical, because it would affect you all the same.

What does that have to do with my comment? Again, the question is not whether it’s bad. It is bad, but it’s totally besides the point. Housing was just an example anyway.

OP is asking if it’s hypocritical to argue against a bad thing being commonplace, while doing the bad thing yourself. Another example could be campaigning for stricter car emission laws while owning a car that wouldn’t meet them.

It being unnecessary is what it makes it bad, but it doesn’t make it hypocritical.

It would be hypocritical to own investment properties while telling other people not to.

It wouldn’t be hypocritical to campaign for making it illegal to have them (which would affect you all the same).

In both scenarios your are contributing to the problem, but you aren’t a hypocrite in both.

Your comment only argues it’s bad, which is not the question. The question is if it’s hypocritical.

I agree with you that it’s bad, and also think it’s not hypocritical to e.g. campaign for making owning investment properties illegal while owning an investment property. You are still the bad guy here but it’s not hypocritical to want a world where the bad thing you are doing is is no longer a thing, if for example the person in question thinks it would be unfair for them to miss out on the investment “while everyone else is doing it”.

Your are the bad guy but no, you are not a hypocrite.

It would be hypocritical to tell others not to own investment properties while you do.

You are assuming they were against it at the time they bought it, if they even bought it and not for example inherited it.

I don’t think it’s hypocritical to do something and at the same time want a world where it’s no longer a thing.

If you argue against capitalism, is it necessarily hypocritical if you also shop for groceries at a store?

If you argue that we should live in a moneyless utopia and yet you charge money for your services, is it hypocritical?

If you argue for climate change action and yet you drive a car, is it hypocritical?

Of course, owning investment properties contributes to the problem and there is no excuse for that, but I don’t think it’s hypocritical to see the problem and want to stop it.

I think “20 minutes ago” is a lot more useful than seeing the full date on every comment and having to do mental math. It does make it harder to see the precise date, but that’s a far less common use case, so the tradeoff goes towards making it more usable for the more common scenario. So I see that as the reason: it’s usually better. The full date is still available on hover, which seems reasonable to me.

I disagree with your premise that web developers “want to make it hard”, as that isn’t the motivation. The motivation is to make it easy to see when a comment was posted, which is far more useful as relative time. That it makes it harder to copy the full date is not the goal, but an unfortunate side-effect of the tooltip disappearing when you stop hovering over the relative time. Which I’m sure you could submit as an issue to the lemmy devs, because likely it just never came up, and isn’t some evil plot to “make it hard on purpose”.

Looking into git commits, the unselectable property was added by @[email protected], so maybe we can get an answer right from the source instead of guessing?

It’s interesting you say they “obscure it”, where in your example they went out of their way to make it possible to see the precise date and time when you hover over the relative time. They could easily not add the tooltip and yet they did.

Why is it not selectable? My guess is that most people would want to select the content of the comment but accidentally also select the time since it’s very close to it, so to make it easier to select just the content, they made the time unselectable. It’s a tradeoff but helps in more cases than it harms. Just a guess though.

You’re violently agreeing again!

Yes, that’s the joke! : )

It was a joke. One would think a project with such scale wouldn’t have to use “low fidelity” music, and could use “hi-fi” music.

HR, after they say you can confide in them: insidious smile

This is such a common misconception

No it’s not, the meme is 100% right, and I’m not even going to read your attempt at defending them!

what if somewhere else in the code

Then you’d need to do something else.

the semantical and resourcewise equivalent would be a third variable

So you are advocating for:

data class Filters(
    val isAdmin: Boolean = false,
    val filterByAdmin: Boolean = false,
    val isConfirmed: Boolean = false,
    val filterByConfirmed: Boolean = false,
)

fun filterUsers(users: List<User>, filters: Filters): List<User> {
    return users
        .filter { !filters.filterByAdmin || it.isAdmin == filters.isAdmin }
        .filter { !filters.filterByConfirmed || it.isConfirmed == filters.isConfirmed }
}

fun getAdmins() {
    val users = getUsers()
    val filters = Filters(isAdmin = true, filterByAdmin = true)
    val admins = filterUsers(users, filters)
    println("Admins: $admins")
}

Over:

data class Filters(
    val isAdmin: Boolean? = null,
    val isConfirmed: Boolean? = null,
)

fun filterUsers(users: List<User>, filters: Filters): List<User> {
    return users
        .filter { filters.isAdmin == null || it.isAdmin == filters.isAdmin }
        .filter { filters.isConfirmed == null || it.isConfirmed == filters.isConfirmed }
}

fun getAdmins() {
    val users = getUsers()
    val filters = Filters(isAdmin = true)
    val admins = filterUsers(users, filters)
    println("Admins: $admins")
}

To me, Filters(isAdmin = true) is a very easy to use API, where Filters(isAdmin = true, filterByAdmin = true), with the additional variable to avoid nullable booleans, is more verbose, for not much benefit and brings ambiguity. What if someone writes Filters(isAdmin = true), but forgets they need to set filterByAdmin = true for it to actually work? Easy mistake to make. We can prevent these mistakes by removing default values so they have to be specified on the call site, but then you need Filters(isAdmin = true, filterByAdmin = true, isConfirmed = false, filterByConfirmed = false), which is very verbose. Having two variables also allows your systems to get into invalid states:

isAdmin = true, adminRightsHaveBeenValidated = false isAdmin = true, filterByAdmin = false

What do these mean? It’s better for invalid states to be unrepresentable. Since these states are mutually exclusive, we should have only 3 states, not 4 which you get with 2 booleans. Which you could achieve with an enum True, False, None, but then you are just reinventing the wheel of nulls. You also get the issue that now you have to remember to always update both variables together.

It all comes back to your point:

it’d be idiomatic and reasonable to assume it to be false if we have no data

You want to have ambiguous states, where a single value represents both “we have no data” and “we have the data, the answer is no”.

It is not more accurate nor less wasteful. If you default it to false and you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflating false to mean two things: “the user is not an admin” and “we don’t know if the user is an admin”. Where if you set it to true or false the first time we need the information, then subsequent requests don’t need to check anymore.

does not have to worry about nulls

I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it’s impossible to forget about the null case. Maybe it’s why I don’t see any issue with using them.

Let’s say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests isAdmin will be null. We don’t know if the user is an admin and we don’t need to know.