Fristly speaking: " Imagine some Java app on Safari under some version of Mac OS needing to talk to some version of .NET under some version of Windows needing to talk to some EBCIDIC-speaking version of COBOL running on some mainframe."
This is reality, not something to imagine.
The article really seems to be saying: Complex data has complex API's Live with it.
All you have to do is convert every data format into one inspectable data structure format and pattern match on it. No need to put everything in object slots. Use a data API for a data-driven application. You know, like S-expressions.
Health care data has this interchange format called HL7. It was a bit kludgy, but it wasn't hard to parse, until the early 2000s genuises decided it needed to be translated to XML. Fortunately, those days have come and gone.
HL7 happens to have pretty strong definitions of stuff like escape-character encodings. When you come at it thinking, "oh noes, i can haz CSV?" you will overcomplicate it. This works BECAUSE of the various systems that have to read it, not in spite of them.
The problem with HL7 is its semantics. There's no such thing as a state-setting element, like "Jane Doe is in Room 463B." It's more like" Jane Doe moved out of Admissions." "Jane Doe moved into Room 463B" "Jane Doe moved to Radiology" "Jane Doe is parked in the hall near Radiology on a gurney."
Answering a visitor's question "where can I visit Jane Doe?" requires a complex state model that requires a byzantine amount of training for the volunteer at the reception desk.
Yes, as a part of a healthcare programming course at uni last year I had to work with said library. We had to parse out data and submit data to a fictional medical device.
We knew what the input was and the what the output was supposed to be. I remember hours trying to iterate trough structures and methods and reading trough the doc s to find out how to parse out one particular dataset. I started out by writing an xpath query which did what I wanted in about ten minutes...
Never seen such a overcomplicated mess, not to mention that I have been told that most devices produce non conformant output and take input which is close to the hapi specification... Which means that you still have to write custom parsers for any device anyway. /rant
I̶ ̶s̶t̶a̶r̶t̶e̶d̶ ̶o̶u̶t̶ ̶b̶y̶ ̶w̶r̶i̶t̶i̶n̶g̶ ̶a̶n̶ ̶x̶p̶a̶t̶h̶ ̶q̶u̶e̶r̶y̶ ̶w̶h̶i̶c̶h̶ ̶d̶i̶d̶ ̶w̶h̶a̶t̶ ̶I̶ ̶w̶a̶n̶t̶e̶d̶ ̶i̶n̶ ̶a̶b̶o̶u̶t̶ ̶t̶e̶n̶ ̶m̶i̶n̶u̶t̶e̶s̶.̶.̶.̶
Actually, no. Scratch that. Just checked the code and it was a hl7line.split(separator); and than an array selection. Funny what I forget in a year...
Wouldn't surprise me. A HIPAA compliance busybody once harassed me over a damned keyboard. Oh, we can use the Chinese Dells from who knows where with who knows what in the firmware. But an old Model M? Why, that's heresy!
Yeah XML doesn't sound like such a failure after reading this does it? The apps I work on currently use XML to communicate between disparate systems (at least they might be disparate, I have no reason to know anything about the system on the other end, which is kind of the point), and guess what? It works just fine.
With the exception of cases where an apostrophe can clear up ambiguity, dropping the apostrophe after a number is almost always recommended (e.g. "the 1990s" or "I have a pair of 10s" are correct). As an example of when using an apostrophe makes sense, "my wife loves iPhone 6s" ambiguously refers to either many iPhone 6 devices or a single iPhone 6s device, whereas "my wife loves iPhone 6's" is unambiguously (though awkwardly) referring to multiple devices. When faced with situations of that sort, it's generally better to reformulate the sentence to avoid the pluralization altogether (e.g. "my wife loves the iPhone 6 line").
(Aside: Apple never refers to the device as "the iPhone", so we can't count on the presence of "the" to resolve the ambiguity.)
When it comes to programming matters, avoiding ambiguity is one of our greatest concerns, even more so than in common correspondence. If we can't reformulate the sentence to clear up the confusion (e.g. "...with some usage of split, substring, parseDate and parseInt...", or else use different fonts to indicate where the function name ends and the pluralization begins), it's generally better to take a non-standard approach that avoids ambiguity. Going back to your "3's" example, I'd suggest using "find all the '3's in the scheme" instead of "find all the 3's in the scheme", since it makes it clear that "3" is a specific value, rather than a type of object named 3. It's already common for particular domains to have grammatical styles that buck the mainstream styles, so I suspect most grammarians would give us a little leeway in the name of avoiding ambiguity, so long as we consistently apply our rules.
As for "do's and don'ts", that's a classic phrase that's left up to the individual style guides to define. The two most common ways of punctuating it are "dos and don'ts" and "do's and don'ts", so it can be used to argue either side.
Just because some grammarian's say using apostrophe's is a bad idea doesn't mean anything (yes, my apostrophes are intentional). There's no such thing as 'correct grammar', similar to how there's not a 'best accent' or a 'more evolved creature'.
It may be common practice, but it's better practice to avoid doing so if possible, even when the usage is considered grammatically correct. If you ask how I solved something and I write back with "I used String's", you may be able to gather from later context what I meant, but from that initial statement alone it isn't possible to tell whether I was pluralizing "String" or referring to something that belongs to a String object. You can't be sure either way.
As I suggested, rewriting the sentence to avoid the pluralization in the first place is nearly always the better choice (e.g. "I used some String objects"). Barring that, at least stylize the name (e.g. wrap the name itself in a code tag and configure the tag in CSS to use a different style from normal text), that way the name is clearly delineated from additional characters.
That said, I'll agree with Doesnt Speak-Good about "correctness" not being the most important thing. Correctness is useful, inasmuch as it helps us to be easily understood. That's why I put so much effort in my initial post about avoiding ambiguity, rather than being correct. Going back to "I used String's", even though it may be a grammatically correct way of indicating that I used something belonging to String, I still wouldn't use it. Though it may be "correct", it's still ambiguous and should be avoided.
The apostrophe helps in some cases, to be sure, but in most of these cases it hurts and shouldn't be used.
The HAPI library accesses a data format known as HL7. Delimiting the file is relatively simple, and HAPI actually has a Terser class which allows you to simply access any field so long as you understand the format well enough to describe it, if you don't have that knowledge you sure won't be able to parse it properly by yourself either.
The complex API which this article is complaining about is used to access not just the raw data, but the semantic meaning of the data structure, which is unsurprisingly incredibly complex. Beyond that, the format has 8 different supported versions all of which are required to be both forward and backward compatible and which have different semantic meanings. Think about an order for pathology which will get a result back. The results come in asynchronously and each order may have multiple tests which may have multiple results any or all of which may have notes associated with them as well as information about what the result was, and what that result means.
HAPI isn't actually particularly difficult if you have any idea of the semantics of the messages you're dealing with, and if you don't have any understanding of the semantics of the messages you're dealing with you probably shouldn't be parsing the messages because you'll get the wrong data.
TLDR; The Real WTF is when people think they're clever because they used a delimiter parser to rip data out of a format with semantic meaning they don't understand and they work in the health care field. You feel safe now?
Although this article was submitted, I have worked in the healthcare industry and with this data. While what you say is true, it's also true that, depending upon what you are trying to accomplish, you may/not need to know the semantics of most of the data; more often than not, you just pick it apart and store/retrieve it. To that end in that context, HAPI is way more complicated than what is needed to accomplish that task, which is what the submitter was railing about.
Yeah, HL7 is like CSV on carcinogenic green-gamma-ray steroids. There are multiple levels of delimiters, which have encodings for when the delim chars show up as actual data-text. Technically, the first few characters of the file/message define what the delimiters will be (they can be replaced, but seldom are in practice, I suppose).
The cherry on top, which broke HAPI when I tried to use it, is that later HL7 versions have an extra 2 more levels, each with a new delimiter chars (which breaks the file header line). All I wanted was a parser that could turn the the text into a multi-dimensional array, possibly grouped by record type - whatever the HL7-ese for rec-type is -- e.g. - OBX records are called "observations", but what they really use them for is "entity custom attributes", AKA, "I'll put whatever I damn well please in these".
Time to cough up $N-K for an "interface engine", which I'm sure will have its own joys to attend to :-)
The sooner this stuff gets replaced with the JSON version, the better.
The sooner this stuff gets replaced with the JSON version, the better.
They'll find ways to make that suck a lot too, I bet. The real problem is that there's an occasional genuine need for great complexity, so every damn program has to deal with all of the complexity that might ever exist…
Nice. In the second case (possessive) the 's is sometimes referred to as the Saxon genitive because it is apparently a remnant of the genitive case in old English. I've been of the opinion for quite some time that we should just drop the apostrophe for the possessive because the average person gets it wrong as much as they get it right even in simple grammar. Generally possession or plural is clear from the context without the apostrophe.
This is the most interesting thing about this article.
Yes healthcare software is bad and can only attract bad programmers (MUMPS anyone).
And if you just need the field. There's a Terser class which just allows you to specify the field you want and it'll pull it right out. I've personally only used the nHAPI version, but HAPI has it too. You can pull out any field you want in a single line (it's a couple lines if you need a specific repeat. There's no real need to use any of the semantic access methods if you know what you're looking for. Personally I use the Terser almost exclusively.
The issue is that to use the Terser you need to know what you're looking at and how to access it, especially once you start dealing with the more complex message types other than ADT. That's not actually a huge problem though because if you're trying to naively pull data from an HL7 message by tokenising the string without understanding what you're parsing I guarantee at the very best you've fallen into the trap of "every sample I have does it that way so it must always do it that way" and at worst you've actually created code that doesn't work.