Yeah, fair enough. I was thinking in terms of the more general-purpose text formats. I have heard good things about QML, too...
- Posts
- 5
- Comments
- 1329
- Joined
- 6 yr. ago
- Posts
- 5
- Comments
- 1329
- Joined
- 6 yr. ago
Eh, I don't think it's the be-all and end-all of describing user interfaces, but it deals well with the deep nesting that UIs generally have, and the attributes allow throwing in metadata for certain elements, which is also something you frequently need in UIs.
At the very least, JSON, YAML, INI and TOML would be a lot worse.
- JumpDeleted
Permanently Deleted
Damn, so that's what it feels like to be left-handed...
Okay, dude, glad to have talked.
Link for those wanting to subscribe from other instances: !Silksong@indie-ver.se
Having to make a decision isn't my primary issue here (even though it can also be problematic, when you need to serialize domain-specific data for which you're no expert). My issue is rather in that you have to write this decision down, so that it can be used for deserializing again. This just makes XML serialization code significantly more complex than JSON serialization code. Both in terms of the code becoming harder to understand, but also just lines of code needed.I've somewhat come to expect less than a handful lines of code for serializing an object from memory into a file. If you do that with XML, it will just slap everything into child nodes, which may be fine, but might also not be.
Ah, well, as far as XML is concerned, yeah, these are very different things, but that's where the problem stems from. In your programming language, you don't have two variants. You just have
(person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether "name" and "age" are one or the other.And the point I wanted to make, which perhaps didn't come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.
Granted, Rust kind of lends itself to being serialized as JSON, but well, I'm just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I'm aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.htmlBut even in Scala, you don't use a
case classfor XML, which is what you normally use for data records in the language, but rather you would take the values out of yourcase classand stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it's still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.htmlAlright, I haven't really looked into XML specifications so far. But I also have to say that needing a specification to consistently serialize and deserialize data isn't great either.
And yes, JSON not having attributes is what I'm saying is a good thing, at least for most data serialization use-cases, since programming languages do not typically have such attributes on their data type fields either.
IMHO one of the fundamental problems with XML for data serialization is illustrated in the article:
(person (name "Alice") (age 30))[is serialized as]xml
<person> <name>Alice</name> <age>30</age> </person>Or with attributes:
<person name="Alice" age="30" />The same data can be portrayed in two different ways. Whenever you serialize or deserialize data, you need to decide whether to read/write values from/to child nodes or attributes.
That's because XML is a markup language. It's great for typing up documents, e.g. to describe a user interface. It was not designed for taking programmatic data and serializing that out.
There is JSONPath, at least: https://en.wikipedia.org/wiki/JSONPath
Right, yeah, I guess on Lemmy, the categorization is already mostly there. I was thinking more generally... 😅
The fish even makes sense as a toy for a cat!
There should be an open-source recommendation algorithm, though; I’m sure of it.
Problem is that the kind of algorithm you envision is technologically a black-box, not just by choice. It's a machine learning model. At best, you could make the training data and instructions public, but it would still be hard to reason why it makes certain decisions. Corporations traditionally try to eliminate biases by throwing as much data at it as possible, but that makes it even harder to reason about it.
I guess, maybe you could try to split the tasks. So, set up a list of e.g. 50 topics, such as sports, IT, politics etc.. Then use a small language model to decide into which categories each post fits. And then you could let the user decide the weights for the topics + weights for recency and vote count.Or I guess, automatically decide the weights based on what the user upvotes and then make the weights transparent to each user.
But yeah, I don't think there's prior art in this respect, so would probably need lots of experimenting still.
Terraform is proprietary. You want to the use the OpenTofu fork instead: https://opentofu.org/
Yeah, to be honest, I've given up on that one. "Language Server Protocol" is a classic case of Microsoft naming things.The two differentiating words are "language" and "server". It does not specify what kind of language is being served or what it even means to serve a language. And "server" is entirely redundant with it being a protocol. Not to mention, that "server" is the most overused word in IT and therefore virtually meaningless.For all we know, it could be a protocol for butlers carrying French dictionaries.
So yeah, I use the acronym as its name, because it is similarly meaningful while being actually recognizable. And when I need to specify whether I'm talking about the "protocol named Language Server Protocol" or a "Language Server Protocol server" or even a "Language Server Protocol client", I will just slap that behind the acronym and be done with it.
🫠
Yeah, expected this to happen sooner or later. If it takes close to 0 effort to generate something that people believe might earn them some money, then of course, they're going to do it in droves.
Lots of simpler editors gained tab completion support over the last few years, thanks to the LSP protocol. I have it in Kate, for example.
- JumpDeleted
Permanently Deleted
The devs keep updating it with cool stuff. In the next update, there's gonna be an orb, which you can hold in place of a shield and which auto-flashbangs your enemies when you get hit.There's also gonna be an orb which sets off explosions around you when you kill an enemy without attacking them...? Have not worked that one out yet, but it sounds rad as hell.
On the Linux side of things, I use KDE's "Activities", which are basically OS-level workspaces on steroids.I set a differently colored wallpaper for each Activity and I have a translucent panel to make this wallpaper color visible even when windows are covering the screen and KDE can also set the application theme to use the wallpaper color as the highlight color.
So, long story short, I can group whole sets of applications windows into different colors, which is pretty cool. Although I can certainly also see the merit of using colors at a more detailed level.
Yeah, I did not expect them to do that title justice, because how in the hell could anyone try 200 music players, but how did they get down to 7 and somehow skip some of the most popular players...? Did all of those somehow look broken on their setup? 🫠