Privileging the standard library would be a pretty bad way of fixing the issue. It wouldn't prevent the same issue from affecting non-standard libraries, which are also subject to the same issue.
The correct way to avoid this issue would be to require local code to be imported in a distinct manner from installed libraries, with an explicitly defined relative path, which is how it works in the javascript ecosystem. If you want to import local code, you just `import foo from './foo';` (for a module in the same folder, `import foo from '../foo';` for module from parent folder, etc.), and if you want to import an installed library, `import foo from 'foo';`.
Yeah, I wasn't recommending it as a mitigation per se. python /does/ have relative imports but they're not required. C and C++ notionally have a similar thing with "include.h" vs <include.h> but the behavior is complex and not really designed for avoiding confusion about where the header is coming from.
For me, it's like a second sense of vision, which does not get hallucinated into the primary sense of vision and which cannot be confused with actual vision, yet nonetheless feels much like vision, with the exception of "not feeling real". By default it is "someplace else", but I can overlay it onto my primary vision if I want to (e.g. imagining an object on my real-life desk), but that doesn't affect my primary vision, merely gives me a sense that the imagined sight corresponds spatially with the actual reality in the intended manner.
Surely those aforementioned non-initial cases would sometimes find themselves in a piece of all-uppercase text? You'd have found such things in print media even before the advent of computers.
Not everything is upper/lower convertible like ß for example (as far as I know)
At least until 2017, I imagine there are others though.
> In 2017, the Council for German Orthography officially adopted a capital form ⟨ẞ⟩ as an acceptable variant, ending a long debate. https://en.wikipedia.org/wiki/%C3%9F
The models themselves are indeed glorified autocomplete in terms of what they actually do (with things like agentic coding harnesses being required as a wrapper around them to make that internal autocomplete something more useful). Many people use this fact to critique LLMs, but many other common instances of people pointing out LLMs' apparent lack of intelligence actually come from people not understanding that the model is a glorified autocomplete underneath whatever interface people access them through, and the interface isn't providing the underlying model all the information they assume it would, making it seem less intelligent than it actually is.
Not represented directly in memory in its raw form right where the value is placed, but rather stored somewhere else (usually the heap) / in an opaque manner and accessed via an indirection, such as a pointer / reference. Often involved in making things polymorphic, because different types usually have different representations in memory even if they implement the same interface, so they need to be boxed.
> We can't do that, however, because Prolog doesn't support unification of functors. We could patch that if we started referring to function application with more elaborate syntax by parsing "sin(exp(x))" as application(sin, application(exp, x)) so that we could unify on sin, but this quickly obscures the syntax tree and removes the delightfully direct nature of DCGs.
Would the =../2 predicate help? It allows for you to unify functors without wrapping them in something like your application(exp, x) example. Not sure how it would interact with DCGs, though - never took more than a superficial glance at them.
> 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?
The correct way to avoid this issue would be to require local code to be imported in a distinct manner from installed libraries, with an explicitly defined relative path, which is how it works in the javascript ecosystem. If you want to import local code, you just `import foo from './foo';` (for a module in the same folder, `import foo from '../foo';` for module from parent folder, etc.), and if you want to import an installed library, `import foo from 'foo';`.