> Why is an extra element required, and why is it <font> of all things?
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.
I doubt that's the only case. We have multiple languages that have applied their own solutions to digital representation and the attempt to maintain backwards compatibility inevitably sets up trouble.
The presented trichotomy between no moderation, moderation, and federated moderation is false.
Moderation can also be accomplished via a user-level web-of-trust system, where each user can choose who to trust as a moderator, and this trust can propagate recursively to the people trusted by the people you trust, and at each level (even when manually choosing people to trust) this trust can be fuzzy (not full trust vs no trust, but potentially something in between those two), and rapidly decreasing the more distant you get from those you've manually chosen to trust. To solve the issues of spam, censorship, and convenience simultaneously, you simply assign to users some moderators on the trust list by default and allow users to opt out of that trust.
This approach is also applicable in the same manner to the similar problem of curation (i.e. choosing what to highlight instead of what to hide), where the same four approaches are also applicable with largely the same pros and cons.
I tried building a reddit style baord using that. The main issue became that calculating weights was more expensive than everything else combined. At one extreme you have the trust matrix which you just multiply with itself to get the nth hop scores, at the other you had the linked list graph traversal. Neither were good solutions.
With how much matrix multiplication were doing for machine learning using the matrix approach now might be feasible.
For this to work you'd need both a high coverage of users providing feedback signal (not happening in real cases), a low penalty of initial no-moderation to allow the system to find equilibrium, and relatively high time-invariance of system to ensure the penalty doesn't recur.
The point of the vehicle in the park game is that complexity isn't always reducible to a tractable problem. Which is fine, and we should learn to engineer systems that embrace the fuzziness, rather than assuming the problem is tractable and solvable.
I'd say it works quite well here. The author is assuming disagreement on HN is some kind of failure. I don't see it that way at all, and sometimes even make comments on opposite sides of an issue within the same issue just because I recognize compelling points in a controversial topic. It's the topics that get monopolar responses that are the least useful and interesting to me.
Huh? There are only two moderators here and they aren't chosen by users, nor do users have to make any choice about "trusting" them. The HN moderation system bears no resemblance at all that I can see to what the post I responded to was describing.
> Techies just love to build and configure things to their liking.
I don't, and I don't believe I'm even in the minority in that regard. What you are referencing is a stereotype that may reflect a minority of so called "techies", but even those are almost certainly only interested in building and configuring things within some specific field of interest, but still want everything outside of that to "just work".
> The rest of us have things to do, and would just rather buy the functionality they need in a ready-to-go and easy-to-use form.
A false dichotomy that is often repeated, but incorrect nevertheless, for it is the proprietary ecosystem that keeps breaking things over and over again, changing UIs, features, and even very basic settings you've set, dropping support for various things (apps, devices, etc.) you might still use and that still work fine.
My linux installations have made everything work directly out of the box (unlike some properietary systems where you have to install things and fiddle with settings to make things work) and have stayed almost identical in terms of their UI and already-existing features for a decade now (and could have for quite a bit longer if I had adopted linux earlier). No properietary system could come even close to this level of "just works"-ness (though apple probably gets far closer than the others).
Developer-users are real users. A tool (such as a piece of software) is not just a toy just because it's targeted towards users that actually have the skillset to make proper use of it. In fact, quite the opposite; the most useful tools (in any domain, not just software) are often quite inaccessible to those without the prerequisite expertise. Commercial products may be heavily incentivized to make themselves appeal to even the most inexperienced users, and obtain a much wider userbase as a result, but how many of those users actually do something useful with that, and is the proportion of such users high enough that it would make sense for FOSS developers to target them, instead of their existing more reliably competent userbase?
You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
> You don't, because JSX is not required for react.
And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?
I don't find it more difficult to use or remember commands for than remembering how to accomplish similar tasks in some GUI (especially if that GUI is emacs). And unlike most GUIs (emacs may be an exception), I can trust that my knowledge of the git CLI won't become out of date when my GUI tool inevitably undergoes a UI redesign of some sort.
But more importantly, the CLI allows my typical workflow where I chain together a bunch of git (and other) commands in a row, allowing me to just type in, for instance, several different commits, their messages, and what files should go into each in one go without having to break my concentration by having to move around in some GUI between commits. Sprinkle in some stash manipulation and interactive rebases, compilation, and unit testing, and you'll really start to see how the CLI allows you to offload some of your working memory to your invocation in a way that a GUI just can't.
With commit messages, there is a very clear starting point: the commit message for the commit that last touched the line of code you're looking at with git blame, which is my standard solution for finding out the reasoning behind any piece of code I don't quite understand. Only works for projects that don't destroy their history with squashes or otherwise write uninsightful commit messages (e.g. "fix bug").
It's also what I, as a user, want. I don't want some middle-man corporate "platform" (of which there are very few to actually select from to suit your personal tastes) inserting their vision of what UIs should look like into interactions between me and the service I'm connecting to. I want my platform to be as invisible as possible and interchangeable with other platforms. The more things stay the same when switching between platforms, the better.
It's also a lot easier to learn the 2-4 dominant UX paradigms of the dominant platforms than the hundreds we have now with everyone doing their own thing. Doing remote tech support for elderly relatives is hell when you can't even rely on a menu bar being present/useful.
Non-discreteness does not imply linearity. Seems like a nitpicky point to make, but in fact the difference between linearity and other types of continuous growth can easily be the difference between a non-issue and an unprecedented catastrophe.
I actually have, but with the caveat that you have to know how to place the dishes in the thing such that they don't block the flow of water. Not a burden once you know how to do it, but might initially take some time to figure it out, if just looking at the thing doesn't make it obvious.
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.