Case for case-sensitivity (Was: Three simple questions)

[Frank Christiny <fchris@pdq.net>]

Larry Kilgallen wrote:
> By the way, your original question at the top of this page struck me
> as quite odd.  While C/C++ uses case sensitivity, I always understood
> that to be part of the Topsy-like development history of the Unix
> operating system.  To me, it is case-sensitivity that should be
> (but cannot be) rationalized, as there is never a good reason for
> allowing TheItem and theItem to be separate variables.

      Unix topsy-turvy?  Man, now you got me going   ;-)
      As opposed to the Microsoft world, Unix is the doldrums!

      You ask me for the case for case-sensitivity and John English
   says that:

>Since humans consider 'D' and 'd' to be variant representations of the
>same letter, why shouldn't programming languages?

      I can address both those questions in this post.

      Not being a partisan of case-sensitivity I can nevertheless
   assert that, first of all, Humans DO care for case sensitivity,
   otherwise why have case-sensitivity in the grammar to begin with?
   Consider the following "overloaded" sentences:

   In the Company of my friend.       In the company of my friend.
   Ada presentation today.            ADA presentation today.
   Standing by the Bank.              Standing by the bank.

      As for the computer languages, consider this:

1. Case sensitivity allows for a greater array of variable naming
   and semantics.  In case-insensitive languages you cannot reuse a
   chunk of the english vocabulary because it has already been
   "privatized".  Not only can you not use "while", but "While", or
   "WHILE", etc.  Once you define "My_List", the type, you cannot
   declare "my_List", the object.

   (Weak point.  Of course it's weak.  I told you, I am not out
   to convince anyone about case-sensitivity).

2. Case sensitivity standardizes the coding practice of the
   internals.  Some Ada samples of the different practices I have
   been able to observe just two months into my introduction to the
   language:

   WITH Ada.Text_IO               with Ada.Text_IO
   PROCEDURE Some_Procedure       procedure Some_Procedure
   my_int : INTEGER;              My_Int : integer;
   BEGIN                          begin
      NULL:                          null;
   END Some_Procedure;            end Some_Procedure;

   With Ada.Text_IO
   procedure Some_Procedure
   my_int : INTEGER;
   begin
      NULL;
   end Some_Procedure;

      The first two versions are at least self-consistent.  The
   galling part is that the code I have to actually maintain at work
   is the of the latter flavor!  Maybe because it was the result of
   many tinkerers prior to me.  So, what do I do in this case?
   Follow the manglers or establish my own personal touch, just to
   be contrary, ah?  The language manual and rationale do not have
   any suggestions on this regard, as far as I know.

      Dis I convince you?  Of course not.  You are OK though.

-- 
Frank Christiny                       fchris@pdq.net
Sr. Software Engineer                 Lockheed Martin Space Operations
Houston, Texas, USA                   http://freeweb.pdq.net/fchris/