one of the biggest mistruths i've seen about the fediverse is that it is based on specifications. fedi followed a couple of specifications a long time ago. now it is unregulated, based on whatever behavior mastodon happens to have. the specifications themselves don't provide an entire social media network, which is why there are so many extensions just to make it usable. the spec is the mastodon codebase
and even then, activitystreams borrows it's extension system from json-ld, an overcomplicated serialization format for RDF, which is just worse XML. this means that, in order to make activitystreams usable, you have to implement an overcomplicated schema system that nothing else uses
the fediverse is unstandardized and entirely based on whatever happens to end up being used in practice. it is violated as implementations please and extensions end up based on throwing shit at the wall waiting for something to stick
+bonifartius 𒂼𒄄
@mia
> [...] activitystreams borrows it's extension system from json-ld, an overcomplicated serialization format for RDF, which is just worse XML
i never understood all the hate for xml, if used correctly and with sane tools it's very nice to use. doesn't happen often though. all attempts of inventing similar things for json seem to only have replicated the bad parts.
IMO the main problem with XML is that it required a little more thought and conceptual understanding than so many programmers were used to, so it was misused, and between the effort and misuse due to the effort, the result was the hate for XML.
Take the core question of tag vs attribute. It takes a little conceptual thought to think about which to use when.
And then you see badly implemented XML where some developer decided the "wrong" way. And your eyes bleed to see it :)
It's like seeing a badly designed SQL table with garbage crammed into fields that obviously should have been different columns in the table.
The difference is that at least the SQL would be internal, but XML tended to inflict itself on others.
@volkris @bonifartius @mia there's no #json equivalent to #xquery
Yeah, I was always a huge fan of xquery, xslt, etc, and I've always been disappointed that they didn't catch on more broadly and weren't more developed.
But then, I like the functional paradigm of programming, and that is similarly unpopular.
I think the two go hand and hand, and because they require different ways of thinking that humans weren't interested in exploring.
I probably mentioned above that I'm a fan of functional programming, though I know that's a rarity. One reason is because functional programming is inherently positive for programs running on multiple processors/cores.
And oh look, we're now in an era where computers are running lots of cores :)
Same with xquery. It's a different tool with different plusses and minuses, but it just so happens that one plus is amenability to parallel programming.
I've never looked deeply into nosql so I'm not sure whether it has the same benefits, but maybe it does.
They're all different tools in the toolbox, but interestingly these less popular tools might be better suited to the tasks of today.
@volkris @bonifartius @mia well, I'm just lumping #xquery under the broader "not only SQL" understanding of #nosql .
Nothing can be more efficient than 4NF... depending, of course, on your definition efficiency.
I'm more of a Java guy, and have always been more than glad to leave some optimizations to the VM.
I liked learning OOP, never really saw the advantages of functional. Unless you're calculating Fibonacci or dealing with REST.
Maybe it's over my head a bit.
They're both tools that have their places.
Think of functional as the software equivalent of MMX/SIMD on processors, where you have a large amount of data that you can process in parallel instead of one at a time.
MMX/SIMD had been really successful, right? A ton of problems lend themselves to such coprocessing?
I do mostly program in OOP, but when I see a problem requiring the churning through of a large dataset I'm excited to slam down a functional solution :)
@volkris @bonifartius @mia
Particularly when read in the context of #sql and its early design and optimizations, then #xquery suddenly seems far more sane.
There are so many reasons to really take an even fresher look at #nosql from the ground up.
End rant.
I've literally forgotten what was being discussed! The awesomeness of #json or something?