• (cs) in reply to n_slash_a
    n_slash_a:
    chron3:
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    An RPG? Cool...

    Customer> claim 10 Widgets Inventory Orc scowls, ready to attack. Customer> swing "AMEX of Purchasing" Inventory Orc parries with "Buckler of Security Code" Customer> swing "Dagger of Codes" You hit the Inventory Orc for (1d3): 3 points of damage! Inventory Orc is dead! Shipping Troll scowls, ready to attack...

    Oh, sorry, you meant programmed IN RPG...

    +1

    Old Coder>I am wielding my +1 programming language from hell.

    Newer Coder> I counter by implicitly casting a C++ spell

  • Bobbo (unregistered) in reply to WhiskeyJack
    WhiskeyJack:
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display.

    Genius.

    That's not a WTF. How else are you supposed to represent decimal numbers in a fixed-point representation?

    My point was more about the language not having that decimal-point representation.

    For example, in some more modern cutting-edge languages I have a 'currency/money' or even just 'decimal' type, into which I can store 123.45 and it stays like that. I don't care how it's handled internally, I just want it to be 123.45 and play happily with all the other numbers.

  • (cs) in reply to Silfax
    Silfax:
    boog:
    TRWTF is feeling a wave of pride after correcting someone's mistaken claim about a dead language.

    Not a dead language, it is still probably the most important language around (it is what generates my paychecks, and probably yours also).

    You may be right. Too bad I wasn't kidding.
  • Bruce (unregistered) in reply to null
    null:
    CICS is the same age as Unix.
    Yes, but wine improves with age, and milk doesn't.
  • (cs) in reply to Bruce

    I don't see the problem -- that's how Oracle works today.

  • wtf (unregistered)
    The Article:
    uncommented, undocumented spaghetti logic
    What, exactly, is spagetti "logic?"
  • frits (unregistered)
    TFA:
    --> "F" - represents False --> "N" - represents Not False
    Who hasn't done something like this before?
  • inglorion (unregistered) in reply to Anonymous

    In addition to T and F, I propose W.

    Then we can have W for true, T for false, and F for file not found.

  • saepius (unregistered)

    The set of True values (T, Y, 1, N) The set of False values (F, N, 0) The intersection of True and False values (N)

    So far, none of the suggested solutions will handle the value N being used vor both True and False.

  • Someone Who Couldn't be Bothered to Log On from Work (unregistered)

    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

  • jugis (unregistered) in reply to Bruce
    Bruce:
    null:
    CICS is the same age as Unix.
    Yes, but wine improves with age, and milk doesn't.
    Wine turns to vinegar.
  • someone (unregistered) in reply to Silfax
    Silfax:
    n_slash_a:
    chron3:
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    An RPG? Cool...

    Customer> claim 10 Widgets Inventory Orc scowls, ready to attack. Customer> swing "AMEX of Purchasing" Inventory Orc parries with "Buckler of Security Code" Customer> swing "Dagger of Codes" You hit the Inventory Orc for (1d3): 3 points of damage! Inventory Orc is dead! Shipping Troll scowls, ready to attack...

    Oh, sorry, you meant programmed IN RPG...

    +1

    Old Coder>I am wielding my +1 programming language from hell.

    Newer Coder> I counter by implicitly casting a C++ spell

    C++ Coder> I curse you for not using an explicit spell_cast<>.
  • Rottweiler (unregistered) in reply to Kevin
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    I was once moved into a position where I had to work with an AS/400 - nothing newer than RPG3 - 6 character variables max, all caps, "Databases" were files, and use of the newfangled SQL was forbidden. Green Screen was holy, and I hightailed it out of there faster than you could mouth WTF!

  • Fizzle (unregistered) in reply to Someone Who Couldn't be Bothered to Log On from Work

    What's a SOC4?

  • Fred (unregistered) in reply to Bobbo
    Bobbo:
    I once worked with an in-house language which didn't have the ability to represent decimal points. So all such numbers were multiplied up by 100 or 10000 to retain the .00 or .0000 precision, then passed around/stored as needed, then divided back down for display.
    And, so you don't lose track of which numbers are multiplied by 100 and which are 10000, you need to pass around a second variable that tracks the precision of the first one. Let's call it "E". So you could have values like NUM=123; E=5.

    Similar strategies will work for the true/false problem. FLAG='N'; FALSE='T' means that FLAG is to be evaluated on the T/N spectrum, with T meaning false so obviously N is true! Or at least Not False.

  • Steve (unregistered) in reply to jugis
    jugis:
    Bruce:
    null:
    CICS is the same age as Unix.
    Yes, but wine improves with age, and milk doesn't.
    Wine turns to vinegar.
    And my Apple smells like cider.
  • (cs) in reply to wtf
    wtf:
    The Article:
    uncommented, undocumented spaghetti logic
    What, exactly, is spagetti "logic?"

    I don't know, but there was once a circuit called the spaghetti logic parallel processor (SLOPP).

    http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=140738&tag=1.

  • Oh THAT Brian! (unregistered) in reply to null

    Excuse me? CICS does not equal Unix! I know that for a fact. I used to work as an operator on a mainframe IBM system for a large metro bank.

    We had CICS - "Customer Information Control System" running on a flavor of IBM OS (pre MVS). The tellers would call a phone number that was answered by the mainframe. They would punch in a query, and the system would read back the results using a series of looping tapes, each one with a word or word part.

    If you look CICS up now, you find that it runs on z/OS, which I imagine is where the confusion comes in, but CICS is NOT UNIX, nor an Operating System!

  • trwtf (unregistered) in reply to Oh THAT Brian!
    Oh THAT Brian!:
    Excuse me? CICS does not equal Unix! I know that for a fact. ... but CICS is NOT UNIX, nor an Operating System!

    Comprehension fail.

    CICS is the same age as Unix.
  • John Muller (unregistered)

    When I was in high school, I took a night class in COBOL for fun.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    I have to share the "saysTrue" and "saysFalse" methods we wrote, which translated the multifarious ways of expressing affirmation and negation that had evolved in our various assorted "boolean valued" system environment properties as defined in our database schemas.

    They effectively boil down to:

    saysTrue: if uppercase of the first character is T or Y, return True, otherwise (which includes null or empty string) return False.

    saysFalse: if uppercase of the first character is F or N, return True, otherwise (which includes null or empty string) return False.

    Yes, the latter method gives the expected answer to "Does this string represent False or No?"

    Well it works for us, and saves a lot of repetitive mucking about.

    So the empty string represents Not a Boolean then. Makes sense.

  • (cs)

    If that were me, I would resist the compelling urge to slit my wrist and instead slit everyone else's.

  • Crash Magnet (unregistered)

    Run Forest, Run!

  • (cs) in reply to John Muller
    John Muller:
    When I was in high school, I took a night class in COBOL for fun.

    We all did stupid things in high school...some of us don't turn around and brag about them. /s

    :D

  • (cs) in reply to Someone Who Couldn't be Bothered to Log On from Work
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

  • (cs) in reply to Fizzle
    Fizzle :
    What's a SOC4?
    putting on your feet before your shoes.
  • (cs) in reply to Silfax
    Silfax:
    Fizzle :
    What's a SOC4?
    putting on your feet before your shoes.
    Smartass!
  • (cs) in reply to jpers36
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

  • Knuckle Dragging Neanderthal (unregistered) in reply to John Muller
    John Muller:
    When I was in high school, I took a night class in COBOL for fun.

    When I was in high school, I banged chicks for fun.

  • (cs) in reply to hoodaticus
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    I googled for an example of a language which uses a bit boolean, and c came up in an IBM MAC OS X c/c++ compiler guide. So I may be wrong in my specific example, or I may be right but only for a highly specific flavor of c. I haven't actually touched c since college, so please forgive me for this.

    The points still stand.

  • Zero (unregistered) in reply to Knuckle Dragging Neanderthal
    Knuckle Dragging Neanderthal:
    John Muller:
    When I was in high school, I took a night class in COBOL for fun.

    When I was in high school, I banged chicks for fun.

    I did that too.... just for CICS.

  • trwtf (unregistered) in reply to hoodaticus
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    jpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it. The only thing I can think of would be to collect all of the booleans in a given program and store them in a "boolean pool" which would be as many bytes as needed, which would allow you to address them by grabbing that byte (or two bytes, or whatever your machine grabs) and looking for the correct bit. So your first boolean would require as much space as before, but your next seven would fit in the same byte as the first. Sounds like a bit of a nuisance to me. Sorry, no, a lot of a nuisance.

    But of course we're all aware that booleans aren't used to save space, they're used to constrain the possible values a boolean variable can take. That is, they exist to clarify the code, not to minimize the memory used.

  • Anachronda (unregistered) in reply to trwtf

    [quote user="trwtfjpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it.[/quote] Easy peasy. Just use an 8051 and put them in the bit-addressable space.

  • (cs) in reply to trwtf
    trwtf:
    jpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it. The only thing I can think of would be to collect all of the booleans in a given program and store them in a "boolean pool" which would be as many bytes as needed, which would allow you to address them by grabbing that byte (or two bytes, or whatever your machine grabs) and looking for the correct bit. So your first boolean would require as much space as before, but your next seven would fit in the same byte as the first. Sounds like a bit of a nuisance to me. Sorry, no, a lot of a nuisance.

    According to MSDN, SQL Server 2008 does it this way.

    http://msdn.microsoft.com/en-us/library/ms177603.aspx

  • (cs) in reply to trwtf
    trwtf:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    jpers' comment made me wonder if I could come up with a way to store booleans in less than a byte without making a really wtf-rific mess of it. The only thing I can think of would be to collect all of the booleans in a given program and store them in a "boolean pool" which would be as many bytes as needed, which would allow you to address them by grabbing that byte (or two bytes, or whatever your machine grabs) and looking for the correct bit. So your first boolean would require as much space as before, but your next seven would fit in the same byte as the first. Sounds like a bit of a nuisance to me. Sorry, no, a lot of a nuisance.

    But of course we're all aware that booleans aren't used to save space, they're used to constrain the possible values a boolean variable can take. That is, they exist to clarify the code, not to minimize the memory used.

    You mean like the BitVector type that's in a bunch of modern languages. MSSQL also packs eight bit columns into a byte for storage.

  • Dave (unregistered)

    I came across something like this once too. It was because they used a string column in a database instead of a boolean one (which existed). And they too were not consistent so I had to check for "JA" (Dutch Yes), "J", "Y" and "YES".

  • Erica (unregistered)

    VSAM is mainly used to retrieve records given one or more keys. A type of indexed-sequential file access. Datasets (IBMese for "file") are limited in size to 128 terabytes.

    An 0C4 is a memory access error -- if a program tries to execute outside of the memory assigned to it.

    CICS is a TP (transaction processor) monitor -- think (using a loose analogy) of a web server. What runs under CICS is application programs (think most of the banking in the world, for example).

    That answer preceding questions?

  • meh (unregistered) in reply to trwtf

    Yeah, but then how much code would you need to manage that pool? That's TRWTF!

    captcha: "tego" - Polish word for "that".

  • Jeff (unregistered)

    Gotta correct everyone.

    CICS and VSAM DOESN'T run on the AS/400 (iSeries, System i5, System i, whatever IBM is calling it these days.)

    It has it's own operating system and database. So if he was running into CICS and VSAM, it's a Z/OS mainframe.

    And the AS/400 when it was first released was called a mini-computer. Don't ask why the distinction.

  • x-sol (unregistered)

    I wonder if the insane asylum needs any programmers

  • (cs) in reply to Sgeo
    Sgeo:
    JT JF N

    I trust someone else will provide the expansions.

    Just True Just False Nothing

    (It didn't seem right to betray his trust.)

  • Ibi-Wan Kentobi (unregistered) in reply to Silfax
    Silfax:
    n_slash_a:
    chron3:
    Kevin:
    AS/400s are actually kind of nice. They are pretty stable, we have a custom POS written in RPG.

    An RPG? Cool...

    Customer> claim 10 Widgets Inventory Orc scowls, ready to attack. Customer> swing "AMEX of Purchasing" Inventory Orc parries with "Buckler of Security Code" Customer> swing "Dagger of Codes" You hit the Inventory Orc for (1d3): 3 points of damage! Inventory Orc is dead! Shipping Troll scowls, ready to attack...

    Oh, sorry, you meant programmed IN RPG...

    +1

    Old Coder>I am wielding my +1 programming language from hell.

    Newer Coder> I counter by implicitly casting a C++ spell

    Aaaand fail -- as soon as you told us you were doing it, it wasn't implicit any more!

  • Englebart (unregistered) in reply to Matt Westwood
    Matt Westwood:
    I have to share the "saysTrue" and "saysFalse" methods we wrote, which translated the multifarious ways of expressing affirmation and negation that had evolved in our various assorted "boolean valued" system environment properties as defined in our database schemas.

    They effectively boil down to:

    saysTrue: if uppercase of the first character is T or Y, return True, otherwise (which includes null or empty string) return False.

    saysFalse: if uppercase of the first character is F or N, return True, otherwise (which includes null or empty string) return False.

    Yes, the latter method gives the expected answer to "Does this string represent False or No?"

    Well it works for us, and saves a lot of repetitive mucking about.

    Seems very Smalltalk-ish...

    I guess in Smalltalk, you would just create new sub classes of False and True. If you are ever stuck with N/F, Y/N where sometimes N means true and sometimes N means false, just send/throw subclassResponsibility FNF and let the on-call support person figure it out.

  • Ditto (unregistered) in reply to anon

    Also AS/400, with POS in RPG. And no, it't not Point Of Sale...

  • Someone Who Couldn't be Bothered to Log On from Work (unregistered) in reply to jpers36
    jpers36:
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    I googled for an example of a language which uses a bit boolean, and c came up in an IBM MAC OS X c/c++ compiler guide. So I may be wrong in my specific example, or I may be right but only for a highly specific flavor of c. I haven't actually touched c since college, so please forgive me for this.

    The points still stand.

    The only point that stands is the one on the top of your head, dumbass. You obviously have no clue how compilers work (which is probably why you had to google to see what c was).

    1. It is impossible to store a boolean in anything less than a byte because COMPUTERS are incapable of addressing a smaller portion of memory than that. Point destroyed.

    2. Why would boolean comparisons take any longer than character comparisons? Either one is an AND instruction at the machine level and a check if a register is set afterwards. Point destroyed.

    3. I am not talking about strings, I am talking about CHARACTERS. In case you haven't noticed, there's a difference between the two in all languages. Having a) the flexibility to introduce new values, and b) the specificity of using "Y/N" vs. "T/F" vs. "1/0" vs. "M/F" when appropriate is an enormous advantage.

    How could you manage to get all three points wrong? I'm guessing it's you who's the troll.

  • Pyrexkidd (unregistered) in reply to hoodaticus
    hoodaticus:
    jpers36:
    Someone Who Couldn't be Bothered to Log On from Work:
    I don't see the problem here. Are you aware that a boolean takes just as much space as a character? Having boolean datatypes is stupid, especially when the need for a "maybe" comes up and you have to go retrofit your code. Now, having boolean logic is another story.

    TRWTF in the article is that so many different string representations were used to represent boolean values.

    TRWTFs in your comment are (1) boolean datatypes don't HAVE to take as much space as a character -- see c, for example; (2) even in those languages in which a boolean datatype does take up a full byte, boolean comparisons will take up less time than character comparisons; and (3) failing even THAT, using strings to represent boolean values leads you right into the article's TRWTF.

    Of course, TRWTF with my comment is that odds are you're a troll.

    In C, there is no boolean data type. That's why everyone uses int.

    In perl there are no boolean data types. You can however, TEST for boolean values. All values other than "" or "0" are true (strings, int, float, etc (although perl doesn't have these data types either)).
    Conversely the only false values are "" or "0".

    so in perl "N", "Y", "FnF", "1", "ReallyFalse", "ExtraFalse", "Maybe" all test true.

    Any way, that's my $.02.

  • (cs)

    One thing I've learned from this site and other similar stories: In a job description filled with buzzword technologies that sound good but slightly vague, when you see an acronym you don't recognize hiding somewhere inconspicuously, run.

    It's a decade-old technology and the only thing they actually want you to work on after they have lured you in by mentioning modern languages you actually like and are familiar with.

  • (cs)
    about 70% of the code was never used, but no one took it out since couldn't be sure

    Listed in the job description as: "cutting-edge genetic algorithms".

  • Correcterer (unregistered) in reply to Jeff
    Jeff:
    Gotta correct everyone.

    CICS and VSAM DOESN'T run on the AS/400 (iSeries, System i5, System i, whatever IBM is calling it these days.)

    It has it's own operating system and database. So if he was running into CICS and VSAM, it's a Z/OS mainframe.

    And the AS/400 when it was first released was called a mini-computer. Don't ask why the distinction.

    Bob would like to have a word with you.

  • trwtf (unregistered) in reply to Arancaytar
    Arancaytar:
    about 70% of the code was never used, but no one took it out since couldn't be sure

    Listed in the job description as: "cutting-edge genetic algorithms".

    Nice.

Leave a comment on “Boolean Truths”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article