Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)E
Posts
56
Comments
3483
Joined
6 yr. ago

  • Well, HTTP + HTML+JS+CSS. The "World Wide Web", if you will.

  • Da hat man ihn doch direkt wieder in der Nase, diesen unverkennbaren Geruch: Neuland

  • Apparently, it's

    a reference to a recent Semi-Ramblomatic video by Yahtzee.

    ...

  • Damn, so that's what it feels like to be left-handed...

  • Okay, dude, glad to have talked.

  • It's pretty much just a hook into infodumping about medieval cities...

  • Yeah, that's a new one, to just cut off the whole timezone...

  • 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 class for XML, which is what you normally use for data records in the language, but rather you would take the values out of your case class and 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.html

  • Alright, 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.

  • 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.

  • 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.

    🫠

  • Anti Meme @sopuli.xyz

    When I'm hungry...

  • KDE @lemmy.kde.social

    This Week in Plasma: dark mode switch and global push-to-talk

    blogs.kde.org /2026/01/17/this-week-in-plasma-dark-mode-switch-and-global-push-to-talk/
  • ich_iel @feddit.org

    ich🌷iel

  • ich_iel @feddit.org

    ich🎄🪄💻iel

  • Science Memes @mander.xyz

    How I imagine mathematicians...

  • Firefox @lemmy.ml

    Copy RSS Button (Extension)

  • Programmer Humor @lemmy.ml

    Me, when doing error handling

  • Linux @lemmy.ml

    Underappreciated top

    friendo.monster /posts/underappreciated-top.html
  • Rust Programming @lemmy.ml

    Everybody's so Creative! (about library abstraction design)

    daymare.net /blogs/everbody-so-creative/
  • Memes @lemmy.ml

    When the webpage doesn't want you opening new tabs

  • Open Source @lemmy.ml

    What's up with FUTO?

    drewdevault.com /2025/10/22/2025-10-22-Whats-up-with-FUTO.html
  • Programmer Humor @lemmy.ml

    Escaping a string when passing through multiple tools

  • Dad Jokes @lemmy.world

    When your Dad gives birth to you

  • General Programming Discussion @lemmy.ml

    Fighting human trafficking with self-contained applications

    lwn.net /Articles/1036916/
  • General Programming Discussion @lemmy.ml

    Thunderbird Accessibility Study

    tilvids.com /w/3ymZQj1ikB9hdtpMmaP836
  • Programmer Humor @lemmy.ml

    Wish granted

  • ich_iel @feddit.org

    ich🦭🔄🐒iel

  • ich_iel @feddit.org

    ich🕜🫑🫙iel

  • Firefox @lemmy.ml

    Blasphemy! 😤

  • ich_iel @feddit.org

    ich💪iel