suckitude classifications [was Re: Keeping python code and database in sync]

[Chris Angelico]

On Sat, Aug 30, 2014 at 9:19 AM, Roy Smith <roy at panix.com> wrote:
> In article <mailman.13623.1409351910.18130.python-list at python.org>,
>  Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Sat, Aug 30, 2014 at 5:02 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> > Speaking of suckitude, we could classify technologies that way:
>> >
>> > xml: major suckitude
>> >
>> > rpc: no suckitude
>> >
>> > python: negative suckitude
>>
>> I disagree with your last two qualifications. RPC still sucks, just
>> not as much as some things do.
>
> Are we talking the generic concept of Remote Procedure Calls, or the
> specific implementation of Sun RPC?

I was thinking of XML-RPC, a particular protocol. Although the generic
concept of remotely calling something isn't entirely free of suckitude
- it's all very well in its way, but like everything else, it has its
flaws. In systems that completely hide the details and make it look
identical to local procedure calls, you have the same problem as
creating a Python property that does a lot of work ("wait, that call
actually goes out over the network??"), and in systems that make it
more clear that this is a network transaction, it's not really a
remote procedure call any more, it's a network action like any other.
But these are small nitpicks. Enough that I'd say "minor suckitude" or
"slight suckitude", but not "no suckitude".

> I'm surprised at the reaction to the word, as if it were something new.
> I thought the term has been in common parlance for many years.  Contrast
> with winitude.

It has. It's just that Skip's Polly has never heard the word before,
so we're teaching her.

> Anyway, I think it is unfair to describe xml as major suckitude.  True,
> it is somewhat outdated, with more modern alternatives such as JSON,
> YAML, protobuffers, etc.  In its day, however, it was a breakthrough
> technology, even if only an incremental outgrowth of SGML.

I've never used XML for anything that wasn't mandated by some other
end, and in every single one of those cases, JSON would have been a
much better fit for the data structure. XML is frequently shoehorned
into carrying array data like this:

<root>
<entry><heading>foo</heading><subentry>text</subentry><subentry>more
text</subentry><subentry>blah</subentry></entry>
<entry><heading>bar</heading><subentry>only one element</subentry></entry>
</root>

In JSON, this would be:

{"entry":[
    {"heading":"foo","subentry":["text","more text","blah"]},
    {"heading":"bar","subentry":["only one element"]}
]}

But in XML, there's no way to represent lists/arrays at all, and the
usual way of fitting them in doesn't allow you to distinguish
one-element lists from text strings (compare the heading entry).

So what's the value of XML for information storage? What's it being
compared against that makes it look good? And above all, why do people
still use it when JSON and other formats are available and well known?

ChrisA