This is for any of you who’ve been part of a dysfunctional organization, and had to deal with someone who has whole-heartedly absorbed the marketing bullet points of ${something}.
In the course of my career I had variations of this conversation, regarding C-versus-C++, Windows NT-versus-BSD, Agile software development-versus-timelines, etc. The basic paradigm of the conversation is always the same: the advocate of ${something} knows enough about system design to be dangerous, but only just – so they focus on the wrong things and jump to weird conclusions. Experienced (and usually older) hands understand the problem domain better, and know where and how the cost/benefit analysis applies, and come to different conclusions.
I remember one discussion in which someone kept insisting that data should be stored in XML. I observed that data portability was not a requirement for the application, nor was it desirable for the data files to be semi-editable. Instead of forklifting in megs of XML parser code (and all the bugs) we could get by fine using a pair of simple pickle/unpickle routines (about 200 lines of code) that stored things in newline-delimited attribute=value pairs. The XML lobby’s response made my head explode: “XML is really fast” and “everyone is doing XML.” First off, performance in writing file data was not a bottleneck so who cares if XML is fast or slow (never mind the question of how a multi-megabyte parser is going to be ‘faster’ than a 200 loc-loop writing buffered file streams at a pre-computed offset) but only very strange people worry about keeping up with the Joneses when storing data to a file: most customers don’t base buying decisions on file formats.
I used to have an employee, back at NFR, who got so spun up during one such discussion, that he told another engineer that he wanted to kill him. Word of that got back to me, so I wandered by the fellow’s cube later that day and asked him if it was true. What I was expecting was “oh, shit, yeah, that was dumb” and that I’d send him to go apologize and then see if the other guy felt the matter was resolved, but instead, he began replaying the entire discussion to me, getting more and more emotional. I put him on pause and said, “you know, this is just a software design issue, it’s certainly not life and death and best of all it can be modularized so if we needed to we could swap that component out later if we did some performance analysis and discovered it was a problem?” He didn’t say he wanted to kill me, because generally CEOs are “final boss” level at most start-ups, but I’ve never seen someone so upset and angry over something so completely unimportant. He lasted at the company another couple of months but then he had another yelling-match with a different co-worker, and I terminated him. What a trip.
The Xtra-Normal app that was used to generate the characters and animation was very ground-breaking for its time. You created the characters and a script and it would render them and do the voices and expressions. It’s cheap and easy, and for the next couple years after I first saw that, I did a few help manuals using weird inserts from the application. In fact, there was recently some discussion about doing an ad for Freethoughtblogs and I proposed (not realizing it was to be a video ad) that we do one of Jordan Peterson saying absurdist things about how great Freethoughtblogs is. But, then, it turned out we needed video. Now I’m wondering if the xtranormal character set have something that resembles Peterson…
That Xtra-Normal video is a gem and a favourite of some of the members of our team of computational physicists. We reference it roughly once-per-year, generally after a particularly frustrating conversation with IT.
I once found a line of code in a script that redirected the output of one of our simulations to /dev/null – there was much hilarity when I reported this to the rest of the team.
Maybe Xtranormal has a lobster you can use?
I’ve spent most of my programming career in “business data processing”. My frustrations usually involve Management making technical decisions for non-technical reasons, and young folks who go all batty about stuff like XML because COOL!
I wish I had a nickel for every time some salesman (they were all male) with a techie-sounding title wrote some toy program lickety-split, and the boss thought, “Wow, I can get rid of all my programmers.” That never works, of course, because the complexity is in the business rules. Tricky frameworks only make code more complicated because they almost never scale up.
There’s Avatarify…
Lol… I’ve rather enjoyed watching all the JSON kids slowly re-invent the entire XML processing stack from first principles, as they’ve gradually realised that you do actually need shit like schemas sometimes. Maybe one day they’ll even manage to re-invent a reliable, universally-agreed date / time format specification.
However, I don’t think they’ve come up with anything as baroquely wonderful / insane* as XSLT… Yet.
*(delete as appropriate)
Dunc @5
LOL!
I actually think that JSON is OK. Yeah, you parse it pretty much exactly like to parse XML, but there’s less syntactic sugar that has to travel through the Intertubes. And there are open-source parsers out there so you don’t have to write your own.
You need Mongo DB. Mongo scales right up. Mongo DB is web scale.
Oh, I agree JSON is mostly just fine – I just found it really funny that it started out with “we don’t need all this stinking baggage that XML has!”, followed by a long, slow realisation that we actually do need quite a lot of it in at least some circumstances…
The lack of a proper date / time standard bugs me though. Seems like the sort of thing you’d want to have…
Your IT department should behave like a jellyfish, says Gartner
Drift with the current, sting your customers to death?
Time/date standard formats? Who would need that?
Scientists rename genes because Microsoft Excel reads them as dates
As a security guy I have to instinctively loathe JSON; it’s like opening your sock drawer and discovering a baby shoggoth. Here’s the thing: it was obviously originally a hack intended to just be fed into an interpreter! “Here execute this blob of text!” Hide a shell escape in there and now you have a surprise remote procedure call. “Look here is some data that does ‘newfs’! Very convenient.” “Oh, foo!” Say the JSON types, and they start writing parsers and checking parameters and all the things that you need to do a decent external data representation. As Dunc said, you need a schema implemented on either end of your pickle/unpickle or you ingest bogus/mis specified data. Or security exploits. And, as I used to scream at XML weenies, the schema parse/unparse is the hard part and your fucking crapbag XML parser is just a bloated piece of shit that does an OK job of doing the EASY PART.
Here is a funny story that you can probably tell about every large project that used XML, ever: the coders start defining data schemas and writing pickle/unpickle routines and everything is great until there’s a bug! One setting is not getting updated reliably! How can this be? Well, CoderBob wrote a pickle routine and made a typo on the name of an attribute: FOOZUM so it pickled the structure correctly, mostly, except it stored FOOZUN which got pickled (naturally) as NULL. CoderAlice’s unpickle routine correctly ingests FOOZUN as NULL and now there is garbage in the data structure, but maybe Alice even checks the schema to see if FOOZUM is set (its not) and defaults it to NULL. Now there is a mis-typed value that never gets pickled/unpickled correctly. It’s such an obvious mistake but it gets made all the time. The only right way to do this is to have schemas that include type specifications (maybe value ranges and string lengths too) and attribute counts (for fixed format data structures) that are fully checked on pickle and unpickle and any software engineer who does not do that gets keel-hauled to serve as an example pour encourager les autres.
There are already two perfectly cromulent ways to express dates: As the number of seconds that have elapsed, excluding leap seconds, since midnight in London on 1 Jan 1970; or as year-month-day hour:minute:second (counting the hours VCR-wise so midnight is 0 and seven o’clock in the evening is 19).
What is “fun” with spreadsheets is that they invariably strip the leading zero from a telephone number; and then sometimes they lose some precision when exporting to CSV, meaning a “telephone number” ends up as something like 7.77843E+9. I suppose I should just be grateful that they don’t assume any number that starts with a leading 0 and contains no eights or nines must be octal …..
Indeed, and if the JSON spec (such as it is) actually picked one of them, I’d have less to complain about. As it is, a JSON date/time might be a UNIX timestamp, it might be an ISO 8601 date/time, or it might be any other goddamn thing you can possibly imagine (OK, and represent as text) – and if you’re consuming somebody else’s service, you have no way of knowing what it expects or produces unless they’ve documented it. And then not changed it without telling anybody. Can you hear my bitter, cynical laughter from here?
Waaaaaaah! But defining schemas is hard! It means you have to think about what you’re doing ahead of time, rather than just making it up as you go! This is exactly why we got rid of XML in the first place! YOU’RE NO FUN!
Never knew where exactly the video came from, but I remember the format vividly from my World of Warcraft days, where the discussion in question was ‘what is the best pet’. This was after the game normalised all the pets to be mechanically identical.
Must have been fifteen years ago now, or more. That takes me back.
All I want for christmas is a spreadsheet that
is not “smart”/s> allows me to truly disable any auto”correction” and just accepts the things I type.“XML is like violence – if it doesn’t solve your problems, you are not using enough of it.”
I don’t know who wrote that one, but while searching for “XML” in my misfortunes file, I came across two references to it, the second in one of my favourite bits of writing of all time (and oddly apropos to this conversation). This is by Peter Gutmann:
Curt Sampson@#16:
That is hysterical.
I don’t know if it’s an open list or not, but Peter maintains a list called “when the fat ladies sing” which is mostly questions received by email regarding PKI and PKCS options. Some of them are really, really funny. Others make me glad I got a vasectomy and did my bit to help humans go extinct.
@16 Is that an HST or a Blues Brothers reference?
The list doesn’t seem to be public or publicly known, but I’d love to see a bit of it and maybe subscribe, if you want to e-mail me further info on it.
Looking back on the comments, I agree that better type specifications are pretty darn helpful, and that’s one of the reasons I like ASN.1 to some degree, despite the libraries and tools for it all being some bad combination of rare, expensive and awful. But asking people to precisely define types is just asking for trouble in my experience, no matter how much easier it makes producing reliable code, because almost nobody wants to spend the effort to think too carefully about what they’re doing.