1) Could be simpler for a start if 2) ensures that no web sites that send a special "over 18" server header are displayed. The header could be more detailed and the parent could select what things are allowed, but for a start make it simple.

Yes, that's even better. Make apps and websites provide an API that broadcasts the age rating of its content, then let the OS attest the apps and websites, not the other way around.

edit: on second thought, there is a trap here. If hardware manufacturers lock down the bootloader, then we're basically still handing over parental authority to governments and companies in the long run. So I think for a start, we just implement a app-install password lock like sudo. It will be easier to implement than the API. The convenience API can come later when hardware manufacturers are banned from locking bootloaders.

How would you make a website that can be over 18 or not, such as a social media feed? Would it become over 18 as soon as your following list contains a porn star (who may not have been one at the time you followed them), and then if you're under 18 you can't unfollow them because you can't load the page?

Isn't rpython doing that, allowing changes on startup and then it's basically statically typed? Does it still exist? Was it ever production ready? I only once read a paper about it decades ago.

It exists in the sense that PyPy exists.

As far as I can tell, it only ever existed to make PyPy possible, and was only defined/specified in terms of PyPy's needs.

RPython is great, but it changes semantics in all sorts of ways. No sets for example. WTF? The native Set type is one of the best features of Python. Tuples also get mangled in RPython.

XML (and those prolog and KDL expressions) have one big advantage over JSON: The type (in XML the tag name) comes before the rest of the object. In JSON it's usually a type field. That means in JSON it could come at any point and thus you have to load the whole sub-structure as a dynamic hash map before you can evaluate the type field and instantiate the correct type in your programming language. With XML using a SaX parser you are guaranteed to get the type first and thus can immediately instantiate the correct type and load the properties into that, skipping any dynamic hash map. Depending on your application this can mean a big performance difference.

That's the biggest problem with DSLs: debugging!

Without namespaces it would be just ML, and that already has another meaning.

The "extendable" part is about accepting unknown tags. The namespaces expansion is responsible for destroying this, not for creating it.

I mean I guess one can look at it like that. One could also say that namespaces make it clear what extension it is and resolve name conflicts.

Yeah, no thanks. I switched to dbeaver already anyway, because pgadmin was annoying about to which postgres versions it could connect. Too much of a hassle to setup a new version from source back when I tried. With dbeaver I just run ./dbeaver from the extracted .tag.gz. dbeaver is also not a web interface, but a real desktop application (Java, though).

I run pgAdmin with docker and there's almost nothing to it.

When a new version comes out, I just update the image version on the stack yml.

The fact that you need Docker to make it easy is already a mayor failure. What happened to single binary programs that you can just run? I don't want a whole virtualized OS installation just to get a desktop application to work.

Is there an implementation that does that?

With std::nullptr_t on MSVC, it's always there without any includes.

Exactly. Except this way you can't build a complete biometric database if all citizen! Since it's so obvious how to do it correctly without creating such a database one could make the assumption the creation of such a database is the actual goal.

Definitely worth a look!

Register the mousemove event handler on window, then you will still get the events when the mouse moves out of the window/frame while dragging and it won't be that buggy.

Come on, HN, you can't let this information stay under the front page for 13 hours and everyone's like "ah yes of course". Please don't register the mousemove event handler on window, that old school hack never really worked and was obsoleted 10 years ago when the pointer API became standard.

Things are much nicer now and the problem is entirely avoided by using pointer events: https://developer.mozilla.org/en-US/docs/Web/API/Element/set...

Was about to comment the same. It's a common mistake/gotcha.

Possibly dumb question, but does that still hold inside p5js?

p5 is just a wrapper that adds the setup() and draw() functions, so yes