In the stone age days, keyboards did not have lowercase. So everything
was typed in uppercase. No one bitched about it. Now with upper and
lower case keyboards people bitch and curse. Including myself. But I
live with it.
The main reason why we have case sensitivity in programming languages
goes back to the start of cave man days of language development:
Compilation and interpretation performance. A compiler does not have to
convert symbols to upper case or lower case or whatever. Also, only one
way to have a symbol table in memory. This reasoning goes back to the
days of slow CPU's and low memory. Today, one could argue otherwise.
Same thing for many of the OSes of the world.
So, they didn't force case sensitivity on us out of concern of the
English language (Only Smalltalk cares about this in a serious manner).
After all look at the crappy function names in maney languages
including C and PHP.
There are many things that we are stuck with for historical reasons
that dont make sense today. But these days with autocompletion it
shouldn't be much of an issue. Provided you are not using NoTePaD.
Although I dislike VB for other reasons it does it it best. If you
declare a variable, it will go through and fix it everywhere the same
way. No questions asked.
Ok, sorry about my rant.
This has a simple solution:
Keep the caps lock always on, or never touch the shift key. Enjoy and
have fun!
I disagree. Look at Java. There is a definite set of conventions there
that readily identifies what kind of thing a name represents. For example,
theName is the name of a variable
TheName is the name of a class
THENAME is the name of a constant
I think that (a) the case sensitivity is useful and (b) it makes the code
easier to read (when doen properly).
Shelly
This has been hashed and rehashed ad nauseum in this group. If you want
to read about it, check Google Groups.
Please let it drop. It's not going to change anything - or anyone's mind.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
That's necessary, of course, only because a special character isn't
employee. I think PHP/Perl got it right in this regard. $var is
unambiguous and stands out.
To bring something new to this tired debate: In my PHP fork I
implemented what I call flex-case. The interpreter will spot word
boundaries per CamelCase rule in identifiers and insert underscores
into them. So $theName is the same as $the_name, and FileGetContents()
is the same as file_get_contents(). Might seem kind of weird but it
works quite nicely in practice.
Personally I am against it, as documented in
http://www.tonymarston.net/php-mysql/case-sensitive-software-is-evil.html
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
"ImOk" <jon.ma...@gmail.com> wrote in message
news:1153865032.0...@h48g2000cwc.googlegroups.com...
With PHP (and most other languages I've used in my 30-year career) you do
not have to use different case for variables and methods as they use other
methods. The fact that it has become the convention in a small number of
languages is no reason to force that convention on everybody.
This is a typical instance of a small number of small minded coders trying
to enforce their idea of what is "pure" on everybody. The whole idea sucks
big time.
Agreed. You are trying to enforce your ideas on everybody.
And your position does suck.
No I'm not. It is the other way around. All computer languages and operating
systems were orginally case-insensitive. Windows is still case-nsensitive,
as are all the Windows products. Then a few lame-brains thought that case
sensitivity would be really "kewl" and they are now trying to enforce their
pathetic ideas on everybody else.
> And your position does suck.
That's just your opinion, and I have no respect for your opinion.
I started on mainframe COBOL in the70s, and due to the limited character set
there was no lower case. When I moved to mini-computers (Data General,
Hewlett Packard) in the 80s they allowed both upper and lower case but NEVER
introduced case-sensitivity. It was possible to write COBOL and JCL in
either case and the computer didn't care. This proves that case-sensitivity
was not introduced on grounds of "efficiency" as the computer could
automatically convert everything to the same case with no loss in
performance.
Having case-sensitive software causes more problems that it solves,
therefore it is EVIL!
That's an excellent objective analysis of the historical issues
involved. I think we can safely close this case now; your talents are
needed elsewhere.
miguel
--
Photos from 40 countries on 5 continents: http://travel.u.nu
Latest photos: Malaysia; Thailand; Singapore; Spain; Morocco
Airports of the world: http://airport.u.nu
How do you propose to deal with different alphabets and languages? It's
not uncommon for programming languages to allow variable names to be in
something other than US-ASCII -- indeed, this code (if saved as UTF-8, at
least; I can't vouch for other encodings) works in PHP, since it allows
variable names to include high-bit characters:
<?php
$ουσ = 'foo';
printf("%s\n", $ουσ);
?>
The way I see it, there's four options:
1. Handle all alphabets with a concept of case in a case-insensitive
manner -- this requires a large database of knowledge within the
interpreter/compiler on how to normalise the case of each alphabet *and*
is going to have an impact on execution time in a non-compiled language,
since it's no longer just the Latin case of two comparisons and a
subtraction of 32 to normalise case.
2. Handle the Latin alphabet as a special case and do everything else on a
byte-by-byte (ie case-sensitive) basis, which provides inconsistency for
bilingual programmers coming from non-Latin alphabets.
3. Handle everything in a case-sensitive way, thereby avoiding all the
problems and also saving cycles that would have to be used to normalise
the identifier's case.
4. Just don't allow identifiers to use anything other than [a-zA-Z0-9_].
Bad for a lot of programmers in non-English speaking countries.
In an exclusively ASCII (or EBCDIC, or any other character set that only
provides the basic Latin alphabet) environment, case-insensitivity *may*
be a win for programmers (and being used to the
variableName/ClassName/CONSTANT convention myself, I'm not so sure about
that), but the moment programming languages leave the cocoon of Western
European languages, I don't see how variable names can be sanely handled
in a case-insensitive way.
Adam
--
Adam Harvey
To e-mail: don't make an example out of me!
Then the feeling is mutual.
Give it up, stoopid. You aren't going to change PHP. If you hate it
enough, go back to your beloved COBOL.
You've already made a complete ass of yourself multiple times in this group.
Objective? ROFLMAO! Tony's about as "objective" as Ted Kennedy.
And yea, I'm sure there are some toilets for Tony to clean.
Especially the one between your ears.
Only in YOUR eyes because I dare to challenge your opinions.
Naw, others also. And you aren't challenging MY opinions - you're
challenging the opinions of the PHP developers and most of the members
of this group.
But you're just too stoopid to understand how big of an ass you show
yourself to be. Troll.
Oh, and look back. I didn't respond to you. YOU responded to ME. Just
like the troll you are.
>
> No I'm not. It is the other way around. All computer languages and
> operating systems were orginally case-insensitive. Windows is still
> case-nsensitive, as are all the Windows products. Then a few lame-brains
^^^^^^^^^^^^^
Do you mean Kernighan, Ritchie, and Thompson?
> thought that case sensitivity would be really "kewl" and they are now
> trying to enforce their pathetic ideas on everybody else.
>
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Sorry to jump in the middle of this but... no they weren't.
C, the language that Windows was written in, is and has always been case
sensitive.
--
The USA Patriot Act is the most unpatriotic act in American history.
Feingold-Obama '08 - Because the Constitution isn't history,
It's the law.
Languages and systems are case sensitive for one simple reason: Things
that are different aren't the same.
The answer is: that's not a can of worms you want to open. If you say
that it's desirable to support some non-Latin scripts, then you're
commiting yourselves to supporting all non-Latin scripts. Suddenly you
have to consider things like directionality: How does language behave
when the code is written in Arabic? Something like
";5 =+ nulaam<-aklit$"? Before you know it you'll have programmers
declaring jihads in newsgroups over vowel marks.
Talib: I've studied the Quran for 30 years. Vowels should be marked
like in the Holy Book!
Jarir: Shut up you fundamentalist troll!
Talib: Infidel!
> have to consider things like directionality: How does language behave
> when the code is written in Arabic? Something like
> ";5 =+ nulaam<-aklit$"? Before you know it you'll have programmers
> declaring jihads in newsgroups over vowel marks.
>
> Talib: I've studied the Quran for 30 years. Vowels should be marked
> like in the Holy Book!
> Jarir: Shut up you fundamentalist troll!
> Talib: Infidel!
hahahahahahahahahaha.
Best. Jihad. Ever.
> Sorry to jump in the middle of this but... no they weren't.
>
> C, the language that Windows was written in, is and has always been case
> sensitive.
Exactly.
> --
> The USA Patriot Act is the most unpatriotic act in American history.
ABSOLUTELY!!!! Our "leader" has no regard for the constitution as he
proceeds to trample on the 4th (illegal search and seizure) and the 1st
(free speech) amendments and doesn't give a damn about habeus corpus.
Shelly
The constitution uses capital letters.
I don't know if the Supreme Court cares, though.
Therefore case sensitivity is evil. Or not. Or something.
The Windows OS is, and has always been, case-insensitive. So have all the
tools such as Word, Notepad, etc.
All the operating systems and languages which I used before Personal
Computers and Windows existed, such as mainframes and mini-computers, were
all case-insensitive. Just because one particular language enforced
case-sensitivity should not mean that it now has to be enforced on every
language and every operating system.
It is only your opinion that most of the members of this newsgroup share
your opinion.
> But you're just too stoopid to understand how big of an ass you show
> yourself to be. Troll.
And the same to you. With bells on.
Do what has been done in various computer software for years - only allow
variable or objects names to use a restricted character set. I am used to
seeing such restrictions as
- first character must not be a number
- can only use characters A-Z, 0-9 and '_' (underscore)
If it is necessary to use UTF-8 characters then only allow those which are
the same in upper and lower case. Problem solved.
ROFLMAO! But you're too stoopid to realize that.
What an asshole.
>
>>But you're just too stoopid to understand how big of an ass you show
>>yourself to be. Troll.
>
>
> And the same to you. With bells on.
>
Gee, you can't even get more original than that? Guess you're too
stoopid there, also.
Get a life, troll. Oh, I forgot. Making an ass of yourself IS your life.
Yea, and Tony expects the rest of the world to remain in the "computer
dark ages" with antiquated tools and techniques - just because HE
doesn't like them.
ROFLMAO!
Original thought is wasted on you. All you can do is echo the same old dogma
just like a trained parrot.
> Get a life, troll. Oh, I forgot. Making an ass of yourself IS your life.
So I'm an ass just because I hold an opinion which is different to yours?
I have been in the IT business for over 30 years and I have seen and adapted
to many changes. Some changes have been for the better, but some have been
not so good. If there is a good reason for a change, something which has
logic and proven benefits, then I have no problem with it.
My point is that for the best part of those 30 years all the operating
systems, languages and tools that I have encountered have been
case-insensitive, yet some lame-brain decided to change this and now wants
to enforce that decision on everyone else. Can you explain to me the
justification for this switch? What on earth was the problem that has
case-sensitivity as the solution?
All I hear on this newsgroup is along the lines of "I have only been
programming for 5 minutes and have only ever used one OS (unix) and one
language (C or C++) and that is case-sensitive, so that's the way it is".
Not much of an argument, is it?
As far as I am concerned switching from case-insensitive to case-sensitive
languages creates more problems than it solves, therefore it is a bad
solution and should be dropped.
That is my opinion and I'm sticking to it.
There are not too many worms involved here.
See "Unicode Standard Annex #31: Identifier and Pattern Syntax" at
http://www.unicode.org/reports/tr31 . See also the proposed revision at
http://www.unicode.org/reports/tr31/tr31-6.html .
Jallan
Don't give the administration any new ideas, my friend. I can see Mr.
Gonzales arguing now, "It's true the 4th amendment prohibits
'unreasonable searches and seizures,' but it doesn't say anything about
'unreasonable Searches and Seizures.'
All hail EBCDIC!
It wouldn't be if you ever came up with an original thought.
>
>>Get a life, troll. Oh, I forgot. Making an ass of yourself IS your life.
>
>
> So I'm an ass just because I hold an opinion which is different to yours?
>
No, because you try to force the rest of the world to abide by your
"standards".
You don't like case sensitivity? Go back to your beloved COBOL.
I've got you by about 9 years. 39 going on 40 here.
> My point is that for the best part of those 30 years all the operating
> systems, languages and tools that I have encountered have been
> case-insensitive, yet some lame-brain decided to change this and now wants
> to enforce that decision on everyone else. Can you explain to me the
> justification for this switch? What on earth was the problem that has
> case-sensitivity as the solution?
>
Guess you didn't get involved with Unix then, which first came out
around 30 years go. Or C, about the same time. C++ in 1986 (20 years
ago). Java in mid-1990's.
Oh, I forgot. You were using COBOL most of those years, weren't you?
As for explaining - I am not going to do it again. I've tried to
explain, as have others. But you're too dense to understand.
> All I hear on this newsgroup is along the lines of "I have only been
> programming for 5 minutes and have only ever used one OS (unix) and one
> language (C or C++) and that is case-sensitive, so that's the way it is".
> Not much of an argument, is it?
>
Nope. I've been programming for 39 years. I stared out with punched
cards and even did a little paper tape and teletype machines. The first
mainframe I worked on was an IBM 1401 with 4,000 bytes of core memory
(yes, the real donuts).
Sure, things were not case sensitive in the 60's. But it started
changing in the 70's. Where were you? Oh, I forgot. You were using COBOL.
And "I don't like it so it must not be any good" isn't much of an
argument, is it? Neither is "That's the way it has always been and I
don't see any reason to change it". All you've given for arguments.
> As far as I am concerned switching from case-insensitive to case-sensitive
> languages creates more problems than it solves, therefore it is a bad
> solution and should be dropped.
>
> That is my opinion and I'm sticking to it.
>
Fine. Go back to your COBOL where case sensitivity isn't important.
The rest of us will enjoy the 21st century where case sensitivity can be
helpful.
C, Pascal, ADA, PL/1, C++, Java, etc. In other words, ALL the dyamic
allocation languages.
Shelly
Well, I have been coding for 43 years, starting with spaghetti-code Fortran.
I like case sensitivity -- especially in Java where the casing tells you
what kind of thingee it is.
Shelly
ROTFLMAO :-) :-) :-)
Shelly
Yep, same here. And I use the same style in my C++ and PHP code.
Here is an example of a book that shows you style programming and how
case sensitive is important:
Agreed. Smalltalk has some excellent standards. Programmers in other
languages would benefit by adopting many of the Smalltalk standards.
Some do, but not enough.
P.S. Please don't top post. This group uses bottom posting as a standard.
I'm not familar with Small talk (though i always hear great things
about it), but how does the case of identifiers affect things?
In my time I have worked on mainframes, minis and micros, punch cards, paper
tape and teletypes, the languages I've used have been Assembler, COBOL, SPL,
INSIGHT, TRANSACT, POWERHOUSE (which consisted of QUIZ, QUICK and QTP),
UNIFACE, SQL and HTML. None of these were case-sensitive.
I have never worked on a unix box, or with C, C++ or Java.
> And "I don't like it so it must not be any good" isn't much of an
> argument, is it? Neither is "That's the way it has always been and I
> don't see any reason to change it". All you've given for arguments.
>
>> As far as I am concerned switching from case-insensitive to
>> case-sensitive languages creates more problems than it solves, therefore
>> it is a bad solution and should be dropped.
>>
>> That is my opinion and I'm sticking to it.
>>
>
> Fine. Go back to your COBOL where case sensitivity isn't important. The
> rest of us will enjoy the 21st century where case sensitivity can be
> helpful.
How can case-sensitivity be helpful? Name one problem where case-sensitivity
is the answer. AFAIAC case-sensitivity introduces more problems than it
solves, therefore it is a bad solution.
That is only to cover up a deficiency in that language. In "proper"
languages it is easy to distinguish between a variable and a function:
- FOO is a variable whereas FOO() is a function.
- or in PHP, $foo is a variable and foo() is a function.
In neither of those examples does the language have any difficulty telling
the difference between a variable and a function of the same name,nor does
it insist that a particular case is used. Where programmers use different
case it is purely a *programmer* convention and not a *language* convention.
[case sensitivity]
> Personally I am against it, as documented in
> http://www.tonymarston.net/php-mysql/case-sensitive-software-is-evil.html
I find your article emotionally-laden: it is pathos-driven to the
neglect of reason. If I winnowed out the appeals to emotion, what
would be left? For example, the time you spend calling case
sensitivity stupid is out of proportion with the time you spend
explaining why you think so.
(I think in arguments in general it's helpful to sum up the other
side's position to their satisfaction, and likewise for them to sum up
your position to your satisfaction. This not only shows that you have
each understood the other's position, but also helps everyone clarify
and refine their own ideas and serves as a gesture of goodwill when
you're not seeing eye to eye.)
--
Jock
In another post you listed the languages that you have used. Some of those
are not "general purpose" languages like Fortran, Cobol, C, Java, etc. It
seems that you have not worked in the modern languages so I believe that
your objection is part of the "you can't teach an old dog new tricks"
syndrome. IOW, "if it ain't broke, don't fix it".
The problem is that is "broke". What you say about FOO is correct.
However, when you get into more advanced concepts, such as in Java, please
tell me how I am to IMMEDIATELY differentiate between a method (function to
non-OO types) and a class, In Java it is:
thisString() --- a method
and
ThisString() --- a class
There is also the modifier "final" in Java that indicates that a named item
doesn't ever change. So, we can have declarations such as
int thisThing = 15;
and
final int THISTHING = 15;
The first defines a variable and initializes it to 15. The second declares
a constant as equal to 15. The person reading the code immediately knows
that THISTHING is a constant, even if he has not found yet where it was
declared.
I have learned over these 43 years with Fortran, Cobol, C, Java, DCL, html,
PHP, and many others that you should always write code that is very easy for
someone else to immediately understand and pick up to expand or debug. I
learned this through 11 years as a six-figure income consultant. I found
that as a byproduct I was the greatest beneficiary because I didn't have to
waste time months later trying to figure out why I did something a
particular way. It was clear and obvious. That is why I hated programmers
who fell into that "name that tune" syndrome and coded what should have been
in 5 lines in one line just to show off.
I see here a resistance to change which reminds me of a time around 1980. I
had written Fortran a particular way using Fortran 4. There was no
if-then-else construct. There were go tos -- hence spaghetti code. However,
people think in if-ten-else and not in goto. When I first encountered an
if-then-else I said to myself "wow! This is how I think, It makes for much
more readable code". Could I accomplish the same thing without that
construct? Yes! Did I say, why add this complication of a new way when the
"language doesn't require it"? No. It had advantages so I IMMEDIATELY
adopted it and virtually totally banished the goto from my vocabulary. Do
you see the parallel here? If Java were not case sensitive would it still
work? Yes. Is it essential to the language? No. Does it bring benefits?
Absolutely. Are there drawbacks? Yes. It forces "old dogs" to change
their warm and fuzzy habits.
Shelly
[Snip a lot of comments I don't disagree with]
>If Java were not case sensitive would it still
>work? Yes. Is it essential to the language? No. Does it bring benefits?
>Absolutely.
No, it does not. What you have described are conventions used in the
case of symbols to make their "type" (constant, variable, function,
whatever) clear. These conventions are useful for languages that have no
other means to distinguish between these types. I've seen nobody
disputing their usefulness. (Note that you can make a THISTHING that is
not a constant, and a thisThing that is not a variable. The only meaning
of the case used is in the programmer's mind.)
The problem with case sensitive languages is that thisThing and
THISTHING are entirely different. That means they can both exist at the
same time. This can lead to problems in the hands of sloppy or c00l
programmers. I see no benefit in having two "things" with the exact same
name, differing only in case, meaning two entirely different things.
Gertjan.
--
Gertjan Klein <gkl...@xs4all.nl>
Again, you've been told time and time again. You're just too stoopid to
understand.
I **KNOW** they are only conventions, and they can be used by sloppy
programmers in the wrong manner, but they are conventions that are
universally followed by all professional programmers. Therein lies its
usefulness.
>
> The problem with case sensitive languages is that thisThing and
> THISTHING are entirely different. That means they can both exist at the
> same time. This can lead to problems in the hands of sloppy or c00l
> programmers. I see no benefit in having two "things" with the exact same
> name, differing only in case, meaning two entirely different things.
As I said "sloppy propgrammers". What is "c001"? I guess we will simply
have to agree to disagree. I see great value in this.
Shelly
"ImOk" <jon.ma...@gmail.com> wrote in message
news:1154187123.5...@s13g2000cwa.googlegroups.com...
> Please explain what you mean top post vs bottom post? I thought I just
> click reply to whom ever and type my message.
This is an example of in-line (sometimes called a bottom) posting. You
address the point immediately above where you write.
>
> Jerry Stuckle wrote:
>> ImOk wrote:
>> > Smalltalk is the only language I know that was designed around case
>> > sensitivity being used correctly and with a purpose. If you study their
>> > system (and it's not complicated) you can write better code in all the
>> > other languages.
>> >
>> > Here is an example of a book that shows you style programming and how
>> > case sensitive is important:
This is a true bottom post.
In-line posts are the best and easiest to read -- except, ofr example, for a
final post saying thank you or something like that,
Shelly
You guys and your fancy schmancy keyboards! Octal-coded binary switches!
--
Mark A. Boyd
Keep-On-Learnin' :)
It's 'Smalltalk' one word and lower case t :)
The idea is that if you write the code in proper English you achieve a
couple of things:
1) The only necessary comments are the description at the top of a
method. Your English is self documenting the code.
2) Very short methods. If a method is longer than 1/2 of a screen this
means you cannot visually see your logicall without jumping up and
down. The language doesnt even have a case statement and the
ifTrue:ifFalse: is actually a method similar to inline ifs we have in
PHP.
3) You can write what could take you 5 lines of code on one line. You
just read left to right including the math (there is no operator
precedence).
So it was necessary to have standards including case sensitivity to
make the coding concise.
(Top posting fixed)
Top posting is posting before the message you're quoting (at the top),
as you did. Bottom posting is posting after the message (at the bottom)
as this reply.
This newsgroup uses bottom posting as a standard.
A. You see the answer before the question
Q. Why is it bad?
A. Top posting.
Q. What's the most annoying thing on usenet?
Gee, a and b can exist at the same time, as can x and y.
thisThing and THISTHING are two different variable names - and can exist
at the same time.
And yes, it's a problem to sloppy programmers.
And there are definite benefits. For instance, "Customer" can be a
class, while "customer" an object of that class. And CUSTOMER is a
defined value. Three different identifiers meaning three different things.
But if you're never worked on a multi-programmer project in a case
sensitive language you may not understand the benefits.
Not sure if that answers my question.
>From your original post i got the impression that, depending on the
case of identifiers, Smalltalk would enforce that convention.
ie:
MYCONST => a global or constant value
MyClass => required to be a class declaration
myIdentifier => required to be a variable or method
Which could potentially be a nice feature in a language. Or it could
be really annoying.
You may be disheartened to know that XHTML is case sensitive, so your
days of <B>hello</b> are numbered.
Also, in MySQL table names are case-sensitive on unix boxes (since they
are used as file names).
miguel
--
Photos from 40 countries on 5 continents: http://travel.u.nu
Latest photos: Malaysia; Thailand; Singapore; Spain; Morocco
Airports of the world: http://airport.u.nu
Jerry, I think you caught the real reason here. I'm disappointed at myself
that I didn't think of it. It is the MULTI-programmer aspect that brings in
the real need for enforcing conventions.
Shelly
It does enforce some things. A class and globals must start with an
uppercase letter.
All methods and local variables start with lower case letters.
Here is a class definition for the class File (by the way most of
Smalltalk is written in itself. So you actually see source code when
you click on a method or class in the browser)
Object subclass: #File
instanceVariableNames: 'handle spec flags shareFlags'
classVariableNames: 'CheckModes NoCheckModes OpenFlagsMask ShareModes'
poolDictionaries: 'CRTConstants Win32Constants Win32Errors'
classInstanceVariableNames: ''.
Object is the top class. Every class is a subclass of it. As soon as
you type the above command and click accept, the class becomes active
in the image. Here is an example of how you would use a method to open
a file
fileHandle:=File new.
fileHandle open: 'test.txt' mode: #create check: true: share:
#readWrite.
This would be similar to:
fileHandle= new File();
fileHandle->open('test.txt','create',true,,'rw');
In general, I am trying to point out that they have a very precise
standard with definitions. Part of it is enforcable, and part of it is
a discipline. You can look at code from another Smalltalker and
immediately recognize what is going on.
If clients didnt care what I used for development, I would be using
Smalltalk for everything. Unfortunately, it got buried under the Java
hype and mega corporations and FUD.
Imagine the amount of blood on the streets if suddenly the Hungarian
notation is enforced in C :-)
Exactly. Introducing case sensitivity creates more problems than it solves,
therefore it should be scrapped. Or at the bare minimum not introduced in
languages were it DOES cause problems.
> The problem is that is "broke". What you say about FOO is correct.
> However, when you get into more advanced concepts, such as in Java, please
> tell me how I am to IMMEDIATELY differentiate between a method (function
> to non-OO types) and a class, In Java it is:
>
> thisString() --- a method
> and
> ThisString() --- a class
>
> There is also the modifier "final" in Java that indicates that a named
> item doesn't ever change. So, we can have declarations such as
>
> int thisThing = 15;
> and
> final int THISTHING = 15;
>
> The first defines a variable and initializes it to 15. The second
> declares a constant as equal to 15. The person reading the code
> immediately knows that THISTHING is a constant, even if he has not found
> yet where it was declared.
That just tells me that a language that cannot disinguish the difference
between variables, constants, functions and methods was built by amateurs
and should be confined to the rubbish bin. The fact that some prgrammers use
case to help in this identifcation is a *programmer convention* and not a
*language requirement*. Yet you and all your kind seem intent on making this
programmer convention the standard across all languages for no good reason
than "this is what I do, so everybody must do the same".
> I have learned over these 43 years with Fortran, Cobol, C, Java, DCL,
> html, PHP, and many others that you should always write code that is very
> easy for someone else to immediately understand and pick up to expand or
> debug. I learned this through 11 years as a six-figure income consultant.
> I found that as a byproduct I was the greatest beneficiary because I
> didn't have to waste time months later trying to figure out why I did
> something a particular way. It was clear and obvious. That is why I
> hated programmers who fell into that "name that tune" syndrome and coded
> what should have been in 5 lines in one line just to show off.
I agree Trying to reduce 5 lines of simple code into 1 line of complex code
is counter productive.
> I see here a resistance to change which reminds me of a time around 1980.
I will resist any change that is bad, and this falls into that category. It
does not solve any problems, it causes them.
> I had written Fortran a particular way using Fortran 4. There was no
> if-then-else construct. There were go tos -- hence spaghetti code.
> However, people think in if-ten-else and not in goto. When I first
> encountered an if-then-else I said to myself "wow! This is how I think,
> It makes for much more readable code". Could I accomplish the same thing
> without that construct? Yes! Did I say, why add this complication of a
> new way when the "language doesn't require it"? No. It had advantages so
> I IMMEDIATELY adopted it and virtually totally banished the goto from my
> vocabulary. Do you see the parallel here? If Java were not case
> sensitive would it still work? Yes. Is it essential to the language?
> No. Does it bring benefits? Absolutely. Are there drawbacks? Yes. It
> forces "old dogs" to change their warm and fuzzy habits.
I remember when I started using COBOL 85 which introduced the ENDxxx
statement for all control structures. Did I complain? Not likely. It solved
a big problem so I embraced the change with both hands. Conversely the
introduction of case-sensitivity into languages does not solve any problem
that I have ever come across. Quite the opposite, in fact, it can actually
cause problems.
My point entirely!
Wrong! Those conventions are only used in those languages whch do not have
any other means to differentiate beween variables, constants, functions and
methods. Proper languages do not need such primtive conventions.
I have worked for 25+ years with case INsensiive languages, and I cannot see
any advantages, only problems.
It does not matter how many programmers work on a project, the introduction
of case-sensitivity into languages causes more problems than it solves,
therefore it is a Bad Thing (tm).
I have explained why the introduction of case-sensitivity into languages
solves NO PROBLEMS whatsoever, but in fact has the opposite effect of
actually introducing potential problems. If you call this an emotional
reaction then you are blind to the logic of my arguments.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
"Jerry Stuckle" <jstu...@attglobal.net> wrote in message
news:r5ednSVqf5t2DlbZ...@comcast.com...
I see. Just because I hold an opinion which is contrary to yours I am
automatically stupid.
So again you are saying that it is a *programmer convention* and not a
*language requirement*. So who started this movement to enforce there
personal conventions on the rest of the community?
I've already encountered that, and it pissed me off no end.
> Also, in MySQL table names are case-sensitive on unix boxes (since they
> are used as file names).
Yes, but there's an option to make table names case-INsensitive. Take a look
at http://dev.mysql.com/doc/refman/4.1/en/name-case-sensitivity.html
Annoying is right. The problems that this could potentially cause seriously
outweighs any benefits (what benefits?)
I have spoken English for 25+ years, and I cannot see any advantages to
anyone speaking German. German is inferior. QED.
Has nothing to do whether your opinions are contrary to mine or not.
Lots of people I admire have differing opinions, and I respect them.
However, I don't respect you. You're just a troll. And a stoopid one
at that.
And it again points out what a stoopid troll you are.
BTW - you don't bother me. I've built a collection of your posts I show
to friends and other usenet people. We get a big laugh about them.
Shelly,
Yes, it is much more important in multi-programmer projects.
For instance, when looking at someone else's code, I can tell that
'Employee' is a class object, while 'anEmployee' is an object of the
Employee class, and employee[] is an array of Employee objects. And
when everyone uses the same conventions, you have less chance of
conflicts between different programmers.
And sure, I know you can add comments to explain the code. And I'm not
at all against comments - I encourage their use. But at the same time
I'm a big promoter of having the code document itself as much as
possible, and conventions like these help.
Case sensitivity can really help with code clarity, if it's used
properly and conventions are followed.
And I have worked almost 40 years in case INsensitive languages, and
almost 25 years in case SEnsitive languages. I see a definite
advantage, and fewer problems.
Of course, if you would have spent 25+ years in Assembler you wouldn't
see an advantage to COBOL or FORTRAN, either - much less C or C++.
You remind me of a guy I knew when working for IBM back in 1990. He
couldn't see any advantage to C++ or OO in general. He'd never used
them so they must not be any good. Guess that's why they didn't take off.
And I guess that's why case sensitive languages never took off.
ROFLMAO!
Another one for my "Tony Marston Chronicles - An Example of Extreme
Stoopidity"
[re
http://www.tonymarston.net/php-mysql/case-sensitive-software-is-evil.html
]
> I have explained why the introduction of case-sensitivity into languages
> solves NO PROBLEMS whatsoever,
Sorry, I don't think you have. I'm not even sure that's doable.
> but in fact has the opposite effect of actually introducing potential problems.
What problems do you discuss in any detail?
> If you call this an emotional reaction then you are blind to the logic of my arguments.
What I was trying to say, Tony, was that I have trouble seeing your
arguments through all your emotionally-charged language (e.g., 'stupid'
occurs five times!).
--
Jock
Benefits such as a standard meta-syntax, so we don't have to rely on
intelli-sense, constantly refer back to the declaration and
documentation, or some smart ass who LiKEs To ALTerN4t3 c4ps and
condense everything into as few lines as possible.
After all, we should strive for code that is as self-documenting as
possible.
--Andrew DeFaria
Did you write all this or did I? It could have been from either of us.
Shelly
As we all know, thisThing is on first, THISTHING is on second, and
ThisThing is on third. Obviously thisThing can't play first and second
at the same time, so THISTHING has to be on second as we need ThisThing
on third and whatThing only know how to play short.
I don't know why you said thisThing and THISTHING are entirely
different things. thisThing is on first. THISTHING is on second.
entirely different things is in center and we only got one of him.
So its settled.
The Three Stooges agree: Case Sensitivity is a Good Thing (tm) ha!
>"Gertjan Klein" <gkl...@xs4all.nl> wrote in message
>news:5anmc2d5a53bmlll7...@4ax.com...
>>
>> No, it does not. What you have described are conventions used in the
>> case of symbols to make their "type" (constant, variable, function,
>> whatever) clear. These conventions are useful for languages that have no
>> other means to distinguish between these types. [...]
>
>I **KNOW** they are only conventions, and they can be used by sloppy
>programmers in the wrong manner, but they are conventions that are
>universally followed by all professional programmers. Therein lies its
>usefulness.
Again, you seem to confuse programming conventions with case
sensitivity. They are not the same thing. As I stated above, I have no
issues with conventions that assign meaning to the case used (in
languages that need them -- not all do). I would not mind following
those conventions if working on a project where they are used.
I don't have big issues with case sensitive languages, either -- I've
worked with both case-sensitive and case-insensitive languages, and I
rarely find case-sensitivity the biggest problem with a language. I do,
however, agree with Tony (albeit without his emotions on the subject)
that the benefits of case-sensitivity are small, if they exist at all,
and don't outweigh the potential disadvantages.
Many posters in this thread seem to forget that all this is a matter of
personal preference. The arguments used in this thread as to why someone
arrives at a certain preference are often attacked with an emotional
ferociousness [1] that is unbecoming of a professional programmer.
Gertjan.
[1] This is not directed at you, personally.
--
Gertjan Klein <gkl...@xs4all.nl>
"Andrew DeFaria" <And...@DeFaria.com> wrote in message news:44cd08ad$0$96238$742e...@news.sonic.net...
Tony Marston wrote:"Gertjan Klein" <gkl...@xs4all.nl> wrote in message
news:5anmc2d5a53bmlll7...@4ax.com...
Shelly wrote:
[Snip a lot of comments I don't disagree with]
If Java were not case sensitive would it still work? Yes. Is it essential to the language? No. Does it bring benefits? Absolutely.No, it does not. What you have described are conventions used in the case of symbols to make their "type" (constant, variable, function, whatever) clear. These conventions are useful for languages that have no other means to distinguish between these types. I've seen nobody disputing their usefulness. (Note that you can make a THISTHING that is not a constant, and a thisThing that is not a variable. The only meaning of the case used is in the programmer's mind.)
The problem with case sensitive languages is that thisThing and THISTHING are entirely different. That means they can both exist at the same time. This can lead to problems in the hands of sloppy or c00l programmers. I see no benefit in having two "things" with the exact same name, differing only in case, meaning two entirely different things.
My point entirely!thisThing and THISTHING are two entirely different things!
Only in systems which are sensitive to case. In case-insensitive systems they are the same.
Only in the minds of a few. Case sensitivity was introduced as a programmer
convention to get around the problem caused by some languages which cannot
identify the difference between a variable, a constant, a function and a
method. These small minded individuals are now making this programmer
convention into a language requirement despite the fact that
a) They cannot identify a problem where case sensitivity is the solution.
b) Case sensitivity causes more problems than it solves.
Can you identify any problem where case sensitivity is the only solution?
Are you not aware of the problems which case sensitivty can cause?
> Of course, if you would have spent 25+ years in Assembler you wouldn't see
> an advantage to COBOL or FORTRAN, either - much less C or C++.
>
> You remind me of a guy I knew when working for IBM back in 1990. He
> couldn't see any advantage to C++ or OO in general. He'd never used them
> so they must not be any good. Guess that's why they didn't take off.
I never used C or C++ because one of my employers used them. I started using
OO when I switched to a language that supported it.
> And I guess that's why case sensitive languages never took off.
>
> ROFLMAO!
>
> Another one for my "Tony Marston Chronicles - An Example of Extreme
> Stoopidity"
So I guess I'm not on your Christmas List then?
<snip>
>>>>
>>>>How can case-sensitivity be helpful? Name one problem where
>>>>case-sensitivity is the answer. AFAIAC case-sensitivity introduces more
>>>>problems than it solves, therefore it is a bad solution.
>>>>
>>>
>>>Again, you've been told time and time again. You're just too stoopid to
>>>understand.
>>
>>
>> I see. Just because I hold an opinion which is contrary to yours I am
>> automatically stupid.
>>
>
> Has nothing to do whether your opinions are contrary to mine or not. Lots
> of people I admire have differing opinions, and I respect them.
>
> However, I don't respect you. You're just a troll. And a stoopid one at
> that.
I do not fit the definition of a troll as provided by
http://en.wikipedia.org/wiki/Internet_troll
By your action of insulting me instead of providing counter-arguments you
are simply identifying that you have run out of arguments.
Little things please little minds.
Big britches fit fat behinds.
What is meta-syntax, what benefits do standards bring, and who set those
standards?
> so we don't have to rely on intelli-sense,
What's wrong with intellisense? If it is built into an IDE which detects
what you have keyed in and automatically adjusts the case to match the
previous declaration then surely by not using it you are exposing youself to
the problems brought about by using a case-sensitive system. Surely this
simply demonstrates that case-sensitivity is a problem and not a solution.
> constantly refer back to the declaration and documentation,
If the system is not case-sensitive then he possibility of having multiple
declarations of the same thing in different case would not be a problem.
> or some smart ass who LiKEs To ALTerN4t3 c4ps and
> condense everything into as few lines as possible.
Any moron who deliberately uses mixed case to cause confusion deserves
nothing more than a poke in the eye with a pointed stick. But if the
language was not sensitive to case then it would not be a problem in the
first place, now would it?
> After all, we should strive for code that is as self-documenting as
> possible.
What has case-sensitivity got to do with self-documenting code? I have been
writing self-documenting code for 25+ years using case-insensitive languages
without any problems.
All you are doing, yet again, is identifying that the use of different case
was only introduced as a programmer convention in those languages which make
it difficult to differentiate between variables, constants, functions and
methods. Decent languages do not have such a problem, yet you insist on
making a programmer convention in one particular language a requirement in
all other languages for no good reason.
> And sure, I know you can add comments to explain the code. And I'm not at
> all against comments - I encourage their use. But at the same time I'm a
> big promoter of having the code document itself as much as possible, and
> conventions like these help.
>
> Case sensitivity can really help with code clarity, if it's used properly
> and conventions are followed.
Case sensitivity is not the only method of introducing code clarity, unless
of course you are using a language which makes it difficult to differentiate
between code and comments. Decent languages do not have such a problem,
therefore the introduction of case sensitivity does not provide any
benefits.
That is my point entirely. Case sensitivity was introduced as a programmer
convention and not a language requirement, and a certain group of people are
trying to enforce their conventions into all languages just because it is
what they are used to therefore it must be *the standard*. They fail to
recognise the fact that the potential problems that case sensitivity could
cause outweigh the non-existent benefits.
Considering that I didn't attack anyone, emotionally or not, I don't take
this comment as directed at me at all.
Shelly
Frankly, I find it a pain in the ass to have to prepend a blankety-blank "$"
in fron of my variables. Why couldn't this language (PHP) be smart enough
to know that what is on the left hand side is a variable? However, I
accepted is a being part of the language and moved on -- rather than rant
about it. If I want a constant, I can write it all in caps. (so much for
languages that can "differentiate between a variable, etc.").
Sorry to barge in like this in the middle of the conversation, but I'm
really curious about the issue. I read more or less the entire thread,
and didn't find the answer to a question that seems quite obvious to
me.
You said (over and over again) that you dislike case sensitivity. OK,
fine. You said (over and over again) that case sensitivity has no
benefits. OK. Now, could you please be so kind to tell me what are all
the benefits of case insensitivity in programming?
Furthermore, I would *really* like to hear more on the potential
problems of case sensitive language.
Vladislav
Nor do I. I haven't attacked any one in this thread.
"What benefits do standards bring"...? I'm sorry, but is this a
serious question? In addition to being anti-case-sensitive, are you
also anti-standards?
> > so we don't have to rely on intelli-sense,
>
> What's wrong with intellisense? If it is built into an IDE which detects
> what you have keyed in and automatically adjusts the case to match the
> previous declaration then surely by not using it you are exposing youself to
> the problems brought about by using a case-sensitive system. Surely this
> simply demonstrates that case-sensitivity is a problem and not a solution.
>
I didn't say there was anything wrong with it. With untyped languages,
though, intellisense loses some of its value. Not every IDE has
intellisense, either, and quality varies between them.
> > constantly refer back to the declaration and documentation,
>
> If the system is not case-sensitive then he possibility of having multiple
> declarations of the same thing in different case would not be a problem.
>
> > or some smart ass who LiKEs To ALTerN4t3 c4ps and
> > condense everything into as few lines as possible.
>
> Any moron who deliberately uses mixed case to cause confusion deserves
> nothing more than a poke in the eye with a pointed stick. But if the
> language was not sensitive to case then it would not be a problem in the
> first place, now would it?
>
Yes, it would still be a problem. That same moron can still do a
plethora of other things to make the code harder to read and
understand. If they're going to write obscufucated code, then whether
or not the language is case sensitive or not is irrelevent. In fact, I
would say it works to their advantage because now they can write it
differently everytime. Is it really that hard to distinguish
hiTh3RetWoU from hiTh3reTwoU? Not particularly, but its extra work I
shouldn't have to worry about and can be easily eliminated.
> > After all, we should strive for code that is as self-documenting as
> > possible.
>
> What has case-sensitivity got to do with self-documenting code? I have been
> writing self-documenting code for 25+ years using case-insensitive languages
> without any problems.
>
Because, as one of the benefits of case-insensitivity, you say that
thisTHING and thisThing are the same, so one doesn't need to worry
about how one writes it, implying and supporting that one *should*
alternate how it is written, which is not conductive towards readable
and self documenting code.