> Plus, some major XML libraries, like lxml in Python, are extremely unintuitive in their implementation of DOM structures and manipulation.
Lxml, or more specifically its inspiration ElementTree is specifically not a (W3C) DOM or dom-style API. It was designed for what it called “data-style” XML documents where elements would hold either text or sub-elements but not both, which is why mixed-content interactions are a chore (lxml augments the API by adding more traversal axis but elementtree does not even have that, it’s a literal tree of elements). effbot.org used to have a page explaining its simplified infoset before Fredrik passed and registration lapsed, it can be accessed through archive.org.
That means lxml is, by design, not the right tool to interact with mixed-content documents. But of course the issue is there isn’t really a right tool for that, as to my knowledge nobody has bothered building a fast DOM-style library for Python.
If you approach lxml as what ElementTree was designed as it’s very intuitive: an element is a sequence of sub-elements, with a mapping of attributes. It’s a very straightforward model and works great for data documents, as well as fits great within the langage. But of course that breaks down for mixed content documents as your text nodes get relegated to `tail` attributes (and ElementTree straight up discards comments and PIs, though lxml reverted that).
XSLT I see as a tragedy. The match / patch processing model is so elegant, but the programming langage built around it is such a disaster (the XML, various langage semantics e.g. the implicit context, the gimped semantics, and the development environment or lack thereof).
I think a simplified Haskell-ish script host (à la Elm) with a smattering of debugging capabilities would have been amazing.
Namespaces were fun! But mostly used for over engineering formats and interacted with by idiots who do not give a toss. Shout out to every service that would break as soon as elementtree got involved. And my idiot colleagues who work on EDI.
IIRC it’s not just laziness, there are things glibc explicitly doesn’t want to expose for various reasons, and since the two projects are essentially unrelated you get the intersection of what both sides are happy with.
Traditional unices develop the kernel and the libc together, as a system, so any kernel feature they want to expose they can just do so.
Checking whether `deleted_at is null` should be extremely cheap, and it avoids the duplication and desynchronisation of having both “deleted” and “deleted_at”.
That's the first solution (a function based index), however it has the drawback of fragility: a seemingly innocent change to the query can lead to not matching the index's expression anymore). Which is why the article moves on to generated columns.
They will require breathing but much less than an open fireplace and a lot more of the heat will be kept inside and not sent through the chimney. So overall they’re way on the positive side. If you can get a cold air inlet it’s better, but it’s far from necessary.
Is it an oled display? It’s likely that the subpixel rendering does not match the physical display, so the subcolors are in the wrong location making the text worse instead of better (in the case of macs Apple entirely removed subpixel rendering some years back so there is no solution whatsoever, Apple on standard density always looks like shit).
Sadly they're not super common which makes them expensive, and I don't think I've seen any that wasn't 16:9. The world has decided to go with refresh rates rather than resolution.
Which is the right choice because our eyes cannot resolve that kind of DPI at that distance.
Past 2880p on most desk monitor viewing distances or past 1080p on most TV viewing distances, you hit steeply diminishing returns. Please, please let's use our processing power and signal bandwidth for color and refresh rate, not resolution.
This is also why I think every console game should have a 720p handheld 'performance' and 1080p living room 'performance' mode. We don't need 1080p on handhelds or 2160p in the living room. Unless you're using relatively enormous screens for either purpose.
> Which is the right choice because our eyes cannot resolve that kind of DPI at that distance.
If you can’t resolve that kind of DPI at that distance you need to get an appointment because you require glasses. The low end of normal vision stops differentiating around 175 dpi at 50cm. The difference is very noticeable (and disturbing) on contrasted detailed features like text without subpixel rendering (or when the subpixel rendering does not match the physical structure of the display).
Everyone I know can immediately see a clear difference between 120 ppi and 200 ppi, but I've yet to encounter anyone who can reliably tell 120hz from 200hz. We have monitors that render lego-sized pixels at 500+ hz now, it's enough.
Gamers have been gaslit to believe they have the reflexes of spider-man and are a lost cause, but their preferences have been listened to by monitor makers for 30 years. Enough already!
Millions of office workers are working all day reading text on screens optimized for playing games at low resolutions. It's just sad.
Steve Jobs showed a decade ago that 4x resolution could be sold at great profit for normal prices. Text on screens can be as crisp as on paper.
Sadly it only became the standard on phones, not on productivity desktop monitors. It so easily could be, and it should be.
I've recently gone from 60hz to 240hz to 480hz. Refresh rate in games is not just about what it looks like. It completely changes game mechanics, like movement, recoil etc. It is such a big difference between 60hz and 240hz that you're not really playing the same game. There are things you can do at 240hz that are impossible at 60hz. At 480hz, there's also so much more time to react, so you really don't need fast reflexes to take advantage of it.
I'm guessing you play FPS competitively and are in your 20s, and for you it might be true, I won't argue that.
The issue for me is that even if your experience was true for all gamers in the world, that would still be a tiny minority compared to all people in the world who use monitors to read text, day in and day out.
A low-res monitor cannot show a high-res image, but a high-res monitor can show a low-res picture, so both sides can get what they want here.
I run 8k/60 but my screen can also do 4k/120. If it could also do 1440 at 240hz or 1080 at 480hz wouldn't bother me, but that the industry spends all effort on making 1080/480 and basically NO effort on 8k does.
The industry should throw everything below say 200ppi on the scrap-heap of history where it belongs. It would harm nobody and benefit everybody.
Right, that should be imperceptible. The 240hz monitor was also 15" while the 480hz monitor is 27". I'm sure that contributes as well. My subjective experience is that I now just have a lot of more time to react.
Lxml, or more specifically its inspiration ElementTree is specifically not a (W3C) DOM or dom-style API. It was designed for what it called “data-style” XML documents where elements would hold either text or sub-elements but not both, which is why mixed-content interactions are a chore (lxml augments the API by adding more traversal axis but elementtree does not even have that, it’s a literal tree of elements). effbot.org used to have a page explaining its simplified infoset before Fredrik passed and registration lapsed, it can be accessed through archive.org.
That means lxml is, by design, not the right tool to interact with mixed-content documents. But of course the issue is there isn’t really a right tool for that, as to my knowledge nobody has bothered building a fast DOM-style library for Python.
If you approach lxml as what ElementTree was designed as it’s very intuitive: an element is a sequence of sub-elements, with a mapping of attributes. It’s a very straightforward model and works great for data documents, as well as fits great within the langage. But of course that breaks down for mixed content documents as your text nodes get relegated to `tail` attributes (and ElementTree straight up discards comments and PIs, though lxml reverted that).
reply