Well, it *is* the Answer to Life, the Universe, and Everything...
-
So we currently have something logging transactions in a central database, and one of the columns currently being saved is a status with values like this:
“Success”, “Invalid”, “Undeliverable”, ...
These are digested from a continuum of various conditions, exceptions, and the like.
In one certain circumstance, there’s a piece of data that’s coming back when it otherwise looks like a “Success” whereby the endpoint we’re talking with is actually indicating that something was unavailable. From the the developers' perspective, this should cause that status to be “Unavailable” instead. Problem solved!
Except that our newish database expert doesn’t work that way. He’s been arguing for a couple weeks that he must, must, MUST have the exact code that we’re receiving, as we should never be doing that kind of translation above in code!
After lots of arguing at various levels, I hear we’re now going to be populating that database with the following:
“Success”, “Invalid”, “Undeliverable”, …, “42”
Problem solved!
-
Had a similar conversation with a database expert who had written some java code. He had made the "toString" method of a fairly complicated object return the codes (e.g. 1: Raw, 2: Processed; 1: Monthly, 2: Year To Date Cumulative; 1: Actual, 2: Budget: etc.) as a string of numbers: 1121132 or whatever. I took the opportunity at one point of converting these to understandable strings, so the object would be rendered in the log as "Raw, Monthly, Budget, ..." etc. You should have heard him create a fuss. "But nobody will be able to understand it! Everyone knows that 1 means Raw and 2 means Processed, and if they don't they need to learn it!"
I don't work there any more. He's been busted back down to javanaut, inheriting back all the code that I originally inherited from him in the first place. He can go and change it all back again now to whatever he wants and I will never ever have to care about it again. Life is sweet.
-
You would be surprised how many people love their acronyms and codes forced on them in the era of mainframe programming. Now that the memory and space limitations are negligible we have to explain to them that it actually can be better to use real words and phrases since they don't have to be looked up every time.
-
@jpolonsk said:
it actually can be better to use real words and phrases since they don't have to be looked up every time.
Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); or b) you are sending a humungous DB across a network or by FTP to a remote site, which in some cases can add several GB of data, thus quite a bit of extra time. Horses for courses, and all that. :)
-
@Cad Delworth said:
@jpolonsk said:
it actually can be better to use real words and phrases since they don't have to be looked up every time.
Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); or b) you are sending a humungous DB across a network or by FTP to a remote site, which in some cases can add several GB of data, thus quite a bit of extra time. Horses for courses, and all that. :)More importantly, it allows for easy internationalisation.
-
@RogerWilco said:
@Cad Delworth said:
Are you saying it's easier to internationalize "23" than it is "Foo"?@jpolonsk said:
More importantly, it allows for easy internationalisation.it actually can be better to use real words and phrases since they don't have to be looked up every time.
Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.
-
@Thuktun said:
The problem with translating short strings is the double meaning of some words. An extreme case: How do you translate "Bin Oct Hex Dec"? That's easy, but what if "bin" stands for "binary" in one case and "trash" in another?@RogerWilco said:
@Cad Delworth said:
Are you saying it's easier to internationalize "23" than it is "Foo"?@jpolonsk said:
More importantly, it allows for easy internationalisation.it actually can be better to use real words and phrases since they don't have to be looked up every time.
Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.
-
@Kiss me I'm Polish said:
How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?@Thuktun said:
@RogerWilco said:
@Cad Delworth said:
Are you saying it's easier to internationalize "23" than it is "Foo"?@jpolonsk said:
More importantly, it allows for easy internationalisation.it actually can be better to use real words and phrases since they don't have to be looked up every time.
Well, yes and no. Sometimes it can still be better to use codes and lookups, especially if a) they change their minds about WHICH words to use every 2 minutes (so, just change one lookup table); [...]A mapping from code to description doesn't care if the codes are symbolic or numeric, and supporting internationalization doesn't imply that an internal protocol or identifier has to be numeric instead of symbolic.
-
@Jaime said:
How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?
Because you then have 23=bin and 24=bin
-
@XIU said:
@Jaime said:
How is that different than translating "23 24 25 26" if "23" stands for "binary" in one case and "trash" in another?
Because you then have 23=bin and 24=bin
Reminds me of a Barenaked Ladies song: Crazy ABCs. (Apologies for crappy lyrics site.)
-
@XIU said:
Because you then have 23=bin and 24=bin
But you can also do that with alphanumeric identifiers e.g. BinAsInBinary=bin and BinAsInTrash=bin.
I think
translate("BinAsInBinary") + translate("OctAsInOctal") + translate("DecAsInDecimal") + translate("HexAsInHexadecimal")
is a little more easily understandable thantranslate(23) + translate(24) + translate(25) + translate(26)
-
@blakeyrat said:
Reminds me of a Barenaked Ladies song: Crazy ABCs. (Apologies for crappy lyrics site.)
Going even further off topic: The Phonetic AlphabetThere are common phonetic alphabets, e.g.: Alpha, Bravo, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliet, Kilo, Lima, Mike, November, Oscar, Papa, Quebec, Romeo, Sierra, Tango, Uniform, Victor, Whiskey, X-ray, Yankee and Zulu. But lately I have encountered many telephone service agents who gave me confirmation codes, but evidently did not want to use a standard phonetic alphabets. I don't know why they did not want to use common alphabets, but for them, I offer this alternative.
[...]
C cue
D duh
E ewe
[...]
Q queue