It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
> It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine.
Absolutely with you up to here, but...
> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".
I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.
Oh sorry, I don't at all intend to say you should write your own parser! Totally agree: "Don't roll your own XML implementation"
What I was addressing is, interfacing with an XML parser and converting that into whatever your internal representation is, can be a chore. LLMs are great at that stuff.
IM messages aren’t really documents. They are text with some very minimal formatting that could be expressed with markdown. Any media attached isn’t embedded in the document, it’s attached externally / rendered at the bottom.
The only example I can think that messages are expressed as documents is Microsoft Teams. And it’s as much an example of what not to do as anything.
I'd disagree with that for most messaging apps. If you think about Discord or Slack for example. You have a plain text message and then media attachments externally. This could be very well expressed with JSON.
Very few messaging apps let you go beyond plain text and let you start embedding media or complex layouts inside a message.
Eh, XML is a machine-readable generic markup language. Why would you prefer using a less powerful format like markdown in a context like message representation? XML with inline tags seems the perfect fit.
Less powerful also means less complex and less exploitable. You can very easily grab a markdown renderer rather than trying to decode a .docx for messages.
Pretty much no messaging apps let you create messages more complex than markdown anyway.
I keep trying to read Diaspora and struggle too much with the concepts presented early on. Very "hard sci-fi", just stick it out and it all gets explained?
The beginning describes the formation of an intelligence and it is indeed very dense. You can figure out what's going on but it takes some slow reading, and probably best to revisit it once you have some more context from later in the book.
The whole book isn't like that. Once you get past that part, as the other commenter said, it gets much easier.
I actually love the beginning of Diaspora, and have recommended just that section to people. I found it beautiful and moving. It's starting to learn that people have to "get past" that section...
Egan is always dense. It's some mind bending physics/comp sci, but all cooked up in his brain so doesn't really apply to anything productive. I struggled with his books and his writing but toughened it out because I liked the concepts, but he's divisive.
If you're looking to experience a "climate change" simulator, kind of, the game Oxygen Not Included is an interesting chemistry sandbox where you need to balance things like O2, heat, food, etc in a "terrarium" of sorts. The parallels to climate change are similar to real life--most of the game ending problems you encounter are from short sighted thinking earlier on/kicking the can down the road.
Now if only the Go gods would grant us in line ternaries to avoid all of the overly verbose nil checks, I'd be more likely to use pointer values in structs. Right now they're big foot guns that the compiler won't catch (and AFAIK no linter will check if you did a nil check before accessing).
I have a tech debt TODO on my backlog to rationalize null usage (waiting on encoding/jsonv2) where I'll go through structs and better determine which properties should be null (or even empty) both from a JSON and DB perspective, especially with custom types in the mix. Hopefully reducing the amount of possible values the TS frontend needs to handle...
That's only part of the problem really. The other thing is how many downstream things rely on GH being up. Things like Go packages, Helm charts, blah blah...
Do you try to pull the butter onto your knife periodically, or do you wait somehow until it pushes the butter onto your knife? When does it become less work to just go get the butter yourself?
I thought this was an unhinged parody of a design site, kinda surprised it's a real thing. Unfortunately the design isn't for me, things look off center and the overall "weight" of components feels off.
I hate to pile on since it's already getting some criticism, but I agree. It's kind of a good example why designers don't purely rely on mathematically consistent designs. Getting things to "look right" often means shifting pixels here and there ever so slightly, so that the math is a bit off but it feels better on the eyes.
Yeah I tried using a similar "golden rule" after reading a design article about it. I based my css variable sizes on it but I kept having to use manual px and rem values instead because stuff just never felt correct.
1.618 is complete nonsense that people hang on to because they want it to be true. It doesn't stack up, neither in ancient Greek times, nor in the renaissance, nor today. It's a dumb idea that needs to die.
reply