• woohoo (unregistered) in reply to BillyBob
    BillyBob:
    EvanED:
    Then why didn't they use 'bool'?

    Wikipedia gives the earliest version of Java, 1.0, released Jan 23, 1996.

    Addendum (2007-07-02 18:12): bool had been accepted by the standards committee by November 1994, and (2) reviews of D&E were out as early as August 1994.

    In other words, there was really no excuse for Java to not follow in C++'s footsteps if they wanted to. I can't imagine that the inertia behind "boolean" would have been too great to overcome by that point.

    No excuse? There was 14 months between Java's release and the acceptance of bool into the C++ standard (by your figures). Do you think that Sun rolled out Java the day after it was built? I doubt it, and the amount of time, effort and money required to make such a subtle and inconsequential change would make it prohibitive anyway.

    Right on. It was in fact dumb in the first place to name it "bool" in C++. Saving some characters in source code (after all, "int" is one of the most frequently used types) stems from the 1970's when memory was counted in kilobytes and mass storage in megabytes (if at all...) As this is no issue any more, readability (as someone already stated above) is the main concern (and it certainly couldn't have been an issue any more in 1994 when the C++ standard was accepted!) Note that the wrapper classes for "int" and "char" (both legacy types from C/C++) are named "Integer" and "Character" in Java, not without good reason. I prefer verbosity versus "character saving" in source code any time...

  • OcPa (unregistered) in reply to Jon Skeet

    .NET is good, but in a different way: it has Regular Expressions native support ;)

    But so does Java - the language used to write the code that is commented here :D

    So WTF didn't they use Regex ?? Just imagine the amount of time being saved when writing the code and also in program execution, if using Regex libraries instead of string manipulation routines. Example (a little bit over sized but very likely to occur in some places) ...

    Suppose you want to do an insensitive search-and-replace for "MAIL" with "PHONE" in an 1,000,000 characters string, and the target string would appear from 0 to thousands of times. What to do ?? Find first all occurrences then iterate thousands of times to replace them all ? (note that the string changes after doing a replacement so the occurences positions might become invalid ;))

    Don't think that the string manipulation is a real solution in this case ... Regex does this much cleaner and faster :)

  • Mom (unregistered) in reply to woohoo
    woohoo:
    I prefer verbosity versus "character saving" in source code any time...

    It's actually a myth that using full sentences for variables names makes code more readable.

  • Zygo (unregistered) in reply to sibtrag
    sibtrag:
    Domo:
    I prefer ToLower(). It saves space!

    Could you possibly be a veteran of the PLATO system? The native word length on the CDC host was 60 bits, so this held 10 six-bit characters. Capital letters were represented with a shift code followed by a letter...so capital letters took up twice as much storage as lower case.

    With more special codes to give a diacritic to the previous letter, half-spaces, backspaces, etc...centering the contents of a string on the screen could be tricky. (In our projects, we determined display length by printing the string in "mode erase" (black-on-black) and then noting the location of the cursor)

    My experience with CDC machines was different. NOS on those machines used 6-bit characters for uppercase, and lowercase required two-byte (12-bit) shift codes. At 10 uppercase or 5 lowercase characters per machine word, words really were words. But then the CDC machines had no implementation of a character type in hardware, so all string manipulation was done with bit shifting operations.

    It was about as hard to do case-insensitivity on those machines then as it is to do case-insensitivity with UTF-8 now.

  • (cs) in reply to woohoo
    VGR:
    Because abbreviations suck. Especially an abbreviation that only saves three characters. Readability is far more important, because roughly 90% of a developer's time is spent doing maintenance. (Or as Sun VP Graham Hamilton put it: "It's more important that Java programs be easy to read than to write.")

    The only reason "int" was not expanded to "integer" was to be C/C++ compatible. I wouldn't be surprised if even that was debated at length.

    and

    woohoo:
    Right on. It was in fact dumb in the first place to name it "bool" in C++. Saving some characters in source code (after all, "int" is one of the most frequently used types) stems from the 1970's when memory was counted in kilobytes and mass storage in megabytes (if at all...) As this is no issue any more, *readability* (as someone already stated above) is the main concern (and it certainly couldn't have been an issue any more in 1994 when the C++ standard was accepted!) Note that the wrapper classes for "int" and "char" (both legacy types from C/C++) are named "Integer" and "Character" in Java, not without good reason. I prefer verbosity versus "character saving" in source code any time...

    I'm all for readability, but I don't think that saying "integer x;" instead of "int x;" would help one bit, in the same way that "boolean b;" wouldn't help at all over "bool b;". How long did it take you to learn those abbreviations and internalize them? A day?

    Would you recommend removing the "float" type and renaming it "floating_point"? Or even better, rename "double" to "double_precision_floating_point_number"?

    You're already essentially abbreviating things. You can't type out everything anyway, so it doesn't hurt to abbreviate things as long as the abbreviations are either standard or completely intuitive. In fact, at some point abbreviations start to help readability IMO, and they at least help save my wrists a tiny bit.

    If you want to pick syntax gripes with C++, I can point you to plenty of places that make the difference between "bool" and "boolean", even if you DO still think it wasn't a good idea, look like having to choose between cookies and cream ice cream and chocolate chip cookie dough. Heck, I can point to plenty of places in straight C like that.

    Addendum (2007-07-03 15:38): I just came up with another great idea. Let's petition the USPS to drop state abbreviations. After all, it's too confusing. "MO" is a much better abbreviation for "Montana" than "Missouri", "MI" seems to fit "Mississippi" better than "Michigan" (maybe "MG" for the latter would have been better), and I could make other changes.

    It's best to leave that confusion behind us.

  • MacDaffy (unregistered) in reply to steve

    I've been writing Pascal for almost thirty years now (currently using GNU and Free Pascal in Mac OS X), am a stickler for formatting and style conventions, and have never heard of "Pascal Case."

    Most Pascal coders I know name their variables "toLower" or "toUpper" or "PROCEDURE handMadeParser ( parseString );"

    After looking it up, I find numerous references to it, but I've observed it--at least, in any codebase I've ever seen. Too restrictive. Too clunky.

  • (cs) in reply to CodingForPretend
    CodingForPretend:
    OmnipotentEntity:
    http://www.lolcode.com

    You'd better get your shivs ready.

    That's just too scary for words...

    There's worse. Check out Brainf*ck....

    http://www.muppetlabs.com/~breadbox/bf/

    Given the choice of writing in that or x86 machine code interfacing with the WinAPI... I'd never write code again.

  • Ancient Hacker (unregistered) in reply to sibtrag

    You forgot to mention embed codes, which did something even weirder, they were doubly overstruck matching pairs of angle brackets and parentheses..

    And the host system that PLATO ran on used the OPPOSITE character set convention, upper case letters were 6-bits, lower case ones were 12. Except for end-of-lines and colons, the rules for which are to horrible to repeat. Unless the file was 8-in-12 in which case all characters were 12 bits.

    And what terminal did you have that had a cursor? PLATO terminals generally did not have cursors, as that was too hard to do on a plasma screen.

Leave a comment on “Extra Sensitive Case Insensitivity”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article