WCSTombs

This was a long rant that I pretty much agree with, except at the conclusion I still don't know what the author is trying to propose. What is this supposed new "WYGIWYM" paradigm?

Anyway, every recent time I've had to use a word processor, what I wished I could have done instead is write the whole thing simply in HTML or Markdown, and have a separate style sheet to choose all the fonts, font sizes, layout, etc. I pretty strongly feel this type of workflow should completely replace document editing, and should have done long ago. I know a lot of people prefer a more WYSIWYG style for writing, but that's fine: you can provide a word-processor-like interface, but instead of manually styling the text piece by piece, you assign from predefined styles, which of course you also have control over, but separately from the content. I think Libreoffice allows you work somewhat like this if you know what you're doing, but it's pretty clunky and certainly not obvious, and I haven't used it enough to say for sure.

By the way, IMO there's nothing wrong with obsessing over the minutiae of how content looks. However, I would never want to prevent a reader from changing literally anything about my site's styling to suit their own needs or desires. My carefully chosen styling is meant for the 99% of cases where people just load the site in a stock browser, and for the other 1% who choose to override the styles, it should also "just work."

That Lean Rada article is really fun!

I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.

Yeah, XSLT 1.0 has some really obvious missteps, so much so that to my knowledge basically nobody just implements XSLT 1.0. What they actually support is (most of) XSLT 1.0 plus a handful of EXSLT extensions (which are completely unofficial and not part of any XSLT spec, by the way). In my opinion the EXSLT stuff is the bare minimum needed to make XSLT 1.0 at least a passable language. Meanwhile, the XSLT spec evolved into 2.0 and 3.0, which as far as I'm aware, even to this day, has no complete open-source implementation.

I've read a few articles by Chris Lee, and I normally like them quite a bit. However, IMO there's something missing from this one, like how does this experiment push the frontier of quantum entanglement research? Is this the most complex entangled state ever created in a lab, or something like that?

Pretty poor reporting here, but let me see if I can get this straight: Georgia ballots weren't truly anonymous, but contained enough identifying information (through these ID numbers) to be correlated to individual voters.

Here's the most important thing:

> Georgia’s outgoing secretary of state, Brad Raffensperger, locked down the tabulation data that someone might use to identify a voter, ordering any public release to redact the ID numbers after an election, which “substantially address[es] this flaw”, said Ben Adida, an MIT-trained cryptographer and the founder of the election technology non-profit VotingWorks, as he addressed the board on Thursday.

But if the unredacted data still exists anywhere, it's still a massive liability. It can still be leaked by unscrupulous people who have access to it, or disclosed to other unscrupulous actors via coercion. The flaw hasn't been fully addressed until the data is expunged and the system is updated to avoid creating it in the first place.

By the way, if I'm reading between the lines correctly...it appears the flaw has nothing to do with "AI," which is why I've called this "poor reporting." The academic who discovered the exploit either used an LLM in their research, or simply demonstrated that AI models have enough knowledge to give out the steps to do the exploit. If the LLM is somehow integral here, that is very poorly explained. My guess is either the author or editor decided to make the story about AI, to ride the current wave of "dangerous AI" hysteria, and then stuck it into the story everywhere they could.

This is a cool concept and something I was looking into recently!

IMHO, XML as a concept is a bit underrated and misunderstood nowadays. Unfortunately the way the culture of XML has evolved over the past decades probably has a lot to do with that, but that shouldn't mean we have to throw out the baby and the bathwater.

For one small example of what I mean, Jupyter notebooks are JSON, while it certainly seems to me that XML would be a better fit, minus any concerns about tooling. A cell's content is represented in the file as an array of strings, while in XML it would just be a text node with the literal contents. But more generally, I increasingly feel that XML should have become the lingua franca for abstract syntax trees of all types. Hopefully it can still become that, and Invisible XML seems like a good step in that direction.

By the way, I should point out that the CommonMark AST has an official XML representation, but as far as I know that's the only Markdown dialect that does, and I also don't know of an ixml grammar. Wouldn't it be great if every Markdown dialect had an ixml grammar though? If Invisible XML has any limitations that prevent this from happening, then IMHO those really should be addressed, since if it can't represent Markdown, then it's probably just not very useful after all.

Yes, and I think that's more likely to be the issue with nytimes.com (from my completely unscientific investigation).

The difference between big-company and FLOSS UX design, including profit-motivated behaviors (a bit indirectly, but it's definitely there), is specifically addressed in the article, so I don't think that's a very fair characterization.

I actually agree about customization, but that's only part of it, and seems to be pretty orthogonal to what the article is talking about. You can only customize to features that are actually implemented by the system, and coming up with those seems like the harder problem.

> The final, particularly strong, objection from the tech community is "don't touch my stuff". People get angry when they have worked hard to get their desktop environment just as they like it and something changes to disrupt that.

Yeah, this can be a little extreme, and I feel we can benefit from being a little more open to trying new things.

The part about designing specifically for large displays and widescreen monitors was interesting. We can also reverse it, though: right now I'm away from home, and I only have this old laptop which is mostly great but has a shitty touchpad as the mouse, and I have to think this must be really common. However, this situation seems to be completely ignored by all desktop UX design. We seem to be pretty good at coming up with ways to use the mouse in our programs, but when the mouse is hard to control and unreliable, it causes pain. I guess I can use ratpoison or something, but that seems to be giving up too much.

Regarding the AI going deep into the filesystem and organizing my data...I'm extremely skeptical of inserting any kind of inherent unpredictability into how I interact with the computer. Giving a command or input should produce a well-defined and predictable (in principle) action. Getting rid of that paradigm fundamentally changes the relationship between the user and the computer in a way that, in my opinion at least, greatly diminishes its usefulness as a tool.

> Capable people with decades of experience can successfully automate away a lot of tedious work, and still end up with a final product identical to what they would have done by hand.

Come on, I don't think the last part is remotely true. It's certainly an extraordinary claim that would need to be backed by research. If it were really true that the final product was identical to what the developer would have written by hand, that alone would solve most of the deeply problematic ethical issues that seem inherent to LLMs, but I think it's bullshit, and moreover there's no way to accomplish what's claimed (except for simple autocompletion, which is a very special case).

There's also this:

> The license of source code they produce is legally unclear.

If you really think that, how is it not an immediate blocker for LLM-generated contributions? Aren't you putting the whole project in legal jeopardy?

I completely agree. When the docs are in the same repository as the source code, at least you can keep the documentation atomically synced to the code. No other method allows this (not counting setups with Git submodules, which is the same thing with more steps), and that should be an immediate dealbreaker.

Docs being updated to reflect the code can then (and must, IMO) be a blocking constraint on all pull requests.

> Or is it because they then publish those docs somewhere else?

Exactly, I use Sphinx to make a nice website from the markdown sources (although it doesn't have to be markdown). That includes generating a full API reference page from all the docstrings.

There was another article submitted today lamenting the slowness of the modern internet, using nytimes.com as an example. Comparing that to this site gives, IMHO, a big part of the answer: don't try to fix what isn't broken. (I also disagree about the UI being horrible.)

> U.S. download speeds increased 174% from 2020 to 2024. 5 Gbps is almost 90,000x the bandwidth I had in 1996. So why are we’re still dealing with slow, bloated websites?

Yes, because the web is more bloated now than it ever was, but also because you're conflating latency and throughput. If the server takes multiple seconds to send the first bit of data, no amount of bandwidth will ever get you within the 0.1-second deadline.

Conflating latency and throughput is a surprisingly common error, and at my last job processing sensor data in real time, I had to make a huge effort to convince other people that latency was the performance metric that mattered, much more than throughput.