|
|
Posted by Tony Marston on 07/30/06 08:19
"Shelly" <sheldonlg.news@asap-consult.com> wrote in message
news:xhHyg.4516$gF6.2036@newsread2.news.pas.earthlink.net...
>
> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message
> news:eaf8ft$8si$1$830fa17d@news.demon.co.uk...
>>
>> "Shelly" <sheldonlg.news@asap-consult.com> wrote in message
>> news:Lsvyg.4249$gF6.1672@newsread2.news.pas.earthlink.net...
>>>
>>> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message
>>> news:ead9b9$nf2$1$830fa79d@news.demon.co.uk...
>>>> 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?
>>>
>>> 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.
>>
>> 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.
>
> 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".
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.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
Navigation:
[Reply to this message]
|