This would send me into peals of laughter if I weren't already crying. The time to make this argument was 30 years ago, when the web wasn't fragmenting into a billion different pieces. The browser can make exactly zero assumptions about any given site, so it could never be a place where user preferences about them could be actionable. Downvoters should get work as web developers sometime. You really want the browser making assumptions about your web design?

All it can do is pass a header and let the website do what it will with it.

A user's custom style-sheet might be good for one web-site, but not for every website.

The original web was much about self-expression of developer-users, but now the web is all about apps, which must not break because a user might want to use different colors.

And why should you need to customize colors? I can understand that different users need larger fonts which you can do by zooming in the browser. Colors should be good to go if the website is well-styled to begin with.

Maybe I could fund a startup for that…

Only if you've told it to. My Firefox settings have "Minimum Font Size" set to "None". Perhaps scaling up to 12px is a default? (Edit: Also, are you sure you're not thinking of 12pt? IIRC, points are DPI-independent units and (AIUI) the traditional way of specifying font sizes in computerized typography.)

Despite my age, I still have eyes that are good enough to easily read the font sizes you're complaining about. A hugely important part of a User Agent is that it provide overrides for site design choices that the Agent's user has decided will benefit them. It's a good thing that UAs let folks like you choose a minimum-possible font size. It's an equally good thing that UAs let folks like me choose to see the choices that designer made that others criticize.

Backend services in languages other than Hack do exist, of course. When I left Meta (then called Facebook) in 2019, they were almost exclusively in C++. Now I don’t know for sure but I think Rust is gaining a lot of popularity for non-Hack stuff.

https://dreamsongs.com/WorseIsBetter.html

> One day in Spring 1989, I was sitting out on the Lucid porch with some of the hackers, and someone asked me why I thought people believed C and Unix were better than Lisp. I jokingly answered, "because, well, worse is better." We laughed over it for a while as I tried to make up an argument for why something clearly lousy could be good.

He then wrote Lisp: Good News, Bad News, How to Win Big (https://www.dreamsongs.com/WIB.html) for his EuroPAL keynote speech

> JWZ excerpted the worse-is-better sections [from Lisp: Good News, Bad News, How to Win Big] and sent them to his friends at CMU, who sent them to their friends at Bell Labs, who sent them to their friends everywhere.

The excerpt: https://www.dreamsongs.com/RiseOfWorseIsBetter.html

The lisp path won, Lispus instead of Linux, and we had AGI in 1997 due to code elegance.

But yes, I remember that to see that stuff you had to expand the down-modded comments.

That stuff was also a product of its time. Slashdot had the strong free speech ethos of the early internet, so CmdrTaco had a policy of never deleting comments unless they broke the site somehow or there was a legal process requiring it. Sometimes that meant very new stories would get these comments and they'd be visible before they got modded, but if you browsed stories that had been active for a little while you wouldn't see them.

One downside of a sophisticated moderation system on a site designed for programmers is that some people take it as a challenge. The reason Slashdot trolling was a bunch of dumb memes rather than e.g. commercial ads is because a lot of bored teenagers found spamming it a good way to learn web programming. The systematic nature of the moderation meant that it was a system to beat, a game to conquer. Hence the brief influx of "page widening posts" and other technical hacks. But I don't know if you'd see the same stuff today. The culture has changed, there are much better ways to learn programming and way more opportunities now. And you don't have to be fully automated. CmdrTaco had a strongly systems-oriented streak, but the problem on HN is hardly ever the actions of dang and the other paid moderators, it's really abuse of the overly simple system by other users that's a problem. You could have both good paid moderators and stricter controls on user moderation.

https://news.ycombinator.com/newsfaq.html#yc

I'm not against memes and jokes, I like them. But I also like some actual intelligent discussion in between.

And that's why right now I visit Hacker News and it's been many years since I used Slashdot.

So there's still an element of who says it that matters

For users without an account you just stick to prefers-color-scheme. For users with an account you add a setting 'disable dark mode'

Dark Reader has autodetection so those users won't be a problem either.

And if you really wanna keep to the identity of the site, the top bar doesn't even really need a color swap.

It really is less of a conundrum than you think.

The Browser also has controls. Good Browsers let you set your browser-wide choice differently from your OS-wide choice. Great Browsers let you pick per-site overrides directly, as a standard user setting in a consistent location in browser controls. I realize a lot of UX designers have come to much prefer the "add more controls" approach over the "teach a person to fish" / understand how your OS and browser controls work as the user of the site approach. I realize why a lot of UX designers will always prefer that approach, because teaching people is hard and it is easier to cut complaints off at the pass than answer complaints with "use your browser's settings".

But seriously, it should be fine to release a dark mode in 2025 that only responds to `prefers-color-scheme: dark` and leaves it to users to understand their OS and Browser tools. It irks me a lot more when sites like Wikipedia and Bing and Google ignore `prefers-color-scheme: dark` by default and makes you dig for some dumb website-specific control (that's in a different place on every website) just to set it to whatever they call "System default" that means "trust the Browser's prefers-color-scheme, I know what I'm doing". UX designers have taken something that should be natural and automatic and made it more complex and more confusing just because a small handful of users complain that they don't understand their OS and Browser Settings tools.

The idea in Python is:

1. Statements are executed line by line in order (statement by statement).

2. One of the statements is "def", which executes a definition.

3. Whatever arguments you have are strictly evaluated. For example f(g(h([]))), it evaluates [] (yielding a new empty list), then evaluates h([]) (always, no matter whether g uses it), then evaluates g(...), then evaluates f(...).

So if you have

def foo(x = []): ...

that immediately defines

foo = (lambda x = []: ...)

For that, it has to immediately evaluate [] (like it always does anywhere!). So how is this not exactly what it should do?

Some people complain about the following:

    class A:
        x = 3
        y = x + 2

For example:

    a = A()
    assert a.__class__.x == 3
    assert a.x == 3
    a.__class__.x = 10
    b = A()
    assert b.x == 10

But it just evaluates each line in the class definition statement by statement when defining the class. Simple!

Complicating the Python evaluation model (that's in effect what you are implying) is not worth doing. And in any case, changing the evaluation model of the world's most used programming language (and in production in all countries of the world) in 2025 or any later date is a no go right there.

If you want a complicated (more featureful) evaluation model, just use C++ or Ruby. Sometimes they are the right choice.

Yes, the fact that most people learn very early the correct way to have a constant value of a mutable type used when an explicit argument is not given and that using a mutable value directly as a default argument value uses a mutable value shared between invocations (which is occasionally desirable) means that the way those two things are done in Python isn't a substantial problem.

(And, no, I don't think a constant mutable list is actually all that commonly needed as a default argument in most languages where mutable and immutable iterables share a common interface; if you are actually mutating the argument, it is probably not an optional argument, if you aren't mutating it, an immutable value -- like a python tuple -- works fine.)

The bigger problem is with dicts and sets because they don't have the equivalent concise representation for the immutable alternative.

Arguably the even bigger problem is that Python collection literals produce mutable collections by default. And orthogonal to that but contributing to the problem is that the taxonomy of collections is very disorganized. For example, an immutable equivalent of set is frozenset - well and good. But then you'd expect the immutable equivalent of list to be frozenlist, except it's tuple! And the immutable equivalent of dict isn't frozendict, it... doesn't actually exist at all in the Python stdlib (there's typing.MappingProxyType which provides a readonly wrapper around any mapping including dicts, but it will still reflect the changes done through the original dict instance, so to make an equivalent of frozenset you need to copy the dict first and then wrap it and discard all remaining references).

Most of this can be reasonably explained by piecemeal evolution of the language, but by now there's really no excuse to not have frozendict, nor to provide an equally concise syntax for all immutable collections, nor to provide better aliases and more uniform API (e.g. why do dicts have copy() but lists do not?).

If you want to mutate two parameters just pass them to a function like you normally would.

It's sloppy and a bad habit, I would not let it pass a PR in production code. Probably OK for a throwaway script.

I think HN leans towards deriding both MS and Musk (see any thread on MS and FOSS). In any case, I think that part of being well-spoken is that you speak out against severely bad actors often. It's never useful to reflexively criticize something, but people may contemplate and still decide they're right. Making a comment is the bare minimum of accountability for bad actors who should know better. It may not be to your taste that HN is such a platform, but that's not up to your decision any more than it is mine. There are many problems from a society that struggles to speak well or ill as a subject deserves, which is to say to speak the truth when it should be spoken, and not to speak mistruths except in exceptional circumstances. It would surely be best if one reasoned critique solved the problem and we never would hear of it again, but alas.

I don't really see it. /. had this basically every single thread and the criticism was very not substantive. Musk is unpopular here, but the criticism at least has a bit more meat to it and is not on every single post.

Interrupts? Interrupts? We don't need no stinking interrupts! https://docs.kernel.org/networking/napi.html#poll

It's really dumbfounding that most devs fell for it even as raw computing power has gotten drastically cheaper.