D - First impressions
- John English (26/26) May 02 2002 I've only read the first few sections of the manual, but I noticed a
- Walter (7/27) May 02 2002 Thanks, I'll go back through the documentation.
- Pavel Minayev (6/11) May 02 2002 Nope. It's just like asm - if it starts with a letter, it's an identifie...
- John English (11/21) May 03 2002 Yes, I assumed that was what it would mean -- it's just that it isn't
- anderson (9/36) May 20 2002 You probably won't read this (stuck in the middle of this old email), bu...
- Pavel Minayev (7/14) May 20 2002 my
- anderson (6/22) May 20 2002 What about the extreme cases where there are 2 or more declarations of
- Pavel Minayev (5/7) May 20 2002 The compiler (MSVC) doesn't. The IDE just don't do any automatic fixes
- anderson (6/13) May 20 2002 Sorry, I was talking about the IDE Visual Assist , and it wasn't a propo...
- Richard Krehbiel (16/29) May 02 2002 Seconded (though I suspect the D implementation and underway are advance...
- Stephen Fuld (27/53) May 03 2002 to
- Richard Krehbiel (18/48) May 03 2002 advanced
- Stephen Fuld (17/67) May 03 2002 to
- C.R.Chafer (34/48) May 02 2002 1 and 3 I think these are typographical errors in the manual.
- John English (16/34) May 03 2002 ??? All you do is get the lexical analyser to flatten everything to
- Pavel Minayev (7/12) May 03 2002 Not so fast! Don't forget about imported functions... there
- Sean L. Palmer (4/9) May 03 2002 I like that idea best out of all I've heard so far.
- Karl Bochert (3/8) May 03 2002 Actually they probably are different people. The first is the poet and
- Nic Tiger (13/21) May 03 2002 You say that names with different case have the same semantic?
- Matthew Wilson (12/38) May 05 2002 Sorry, but this string String STRING stuff sounds like a guy I once work...
- OddesE (24/34) May 05 2002 LOL!
- Pavel Minayev (5/10) May 05 2002 Oh yeah... and then Integer, and tRect and IF in that same
- Walter (5/8) May 15 2002 I've used both case sensitive and insensitive languages. I much prefer t...
I've only read the first few sections of the manual, but I noticed a few things in the lexical grammar already: 1) the grammar for hex constants contains a misprint (0b instead of 0x) 2) the grammar for HexadecimalH constants looks ambiguous as is: it implies that the word "each" could be interpreted as a valid hexadecimal contant (same as 0xEAC) 3) the grammar shows h or H as valid suffixes for HexadecimalH, but not prefixes 0B or 0X... is this intentional? 4) A nice addition to the list of escape characters would be \e for ESC. Also, re (3) above, can I make a plea for case insensitivity throughout? Students that I teach Java to waste an awful lot of their time dealing with spelling mistakes: they write RunTimeException instead of RuntimeException, or HashTable instead of Hashtable, or Hashmap (by analogy with Hashtable) instead of HashMap... What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word... ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------
May 02 2002
"John English" <je brighton.ac.uk> wrote in message news:3CD1479A.91A6CBDC brighton.ac.uk...I've only read the first few sections of the manual, but I noticed a few things in the lexical grammar already: 1) the grammar for hex constants contains a misprint (0b instead of 0x) 2) the grammar for HexadecimalH constants looks ambiguous as is: it implies that the word "each" could be interpreted as a valid hexadecimal contant (same as 0xEAC) 3) the grammar shows h or H as valid suffixes for HexadecimalH, but not prefixes 0B or 0X... is this intentional? 4) A nice addition to the list of escape characters would be \e for ESC.Thanks, I'll go back through the documentation.Also, re (3) above, can I make a plea for case insensitivity throughout? Students that I teach Java to waste an awful lot of their time dealing with spelling mistakes: they write RunTimeException instead of RuntimeException, or HashTable instead of Hashtable, or Hashmap (by analogy with Hashtable) instead of HashMap... What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word...D is case sensitive because C is <g>. But seriously, this is one of those no-win topics like brace indenting styles. If D was a pascal successor, it would be case insensitive, but since it is in the tradition of C like languages (and can interface directly to C), it is case sensitive.
May 02 2002
"Walter" <walter digitalmars.com> wrote in message news:aarmn9$1eip$4 digitaldaemon.com...Nope. It's just like asm - if it starts with a letter, it's an identifier (so "each" is an identifier). Only if it starts with a digit, it is a number (so "0each" is a hex number 0xEAC).2) the grammar for HexadecimalH constants looks ambiguous as is: it implies that the word "each" could be interpreted as a valid hexadecimal contant (same as 0xEAC)Yep, a nice one for those guys working directly with UNIX terminals...4) A nice addition to the list of escape characters would be \e for ESC.
May 02 2002
John English <je brighton.ac.uk> Pavel Minayev wrote:"Walter" <walter digitalmars.com> wrote in message news:aarmn9$1eip$4 digitaldaemon.com...Actually, it was me...Yes, I assumed that was what it would mean -- it's just that it isn't what it says at the moment, and I was just trying to point out an ambiguity... ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------Nope. It's just like asm - if it starts with a letter, it's an identifier (so "each" is an identifier). Only if it starts with a digit, it is a number (so "0each" is a hex number 0xEAC).2) the grammar for HexadecimalH constants looks ambiguous as is: it implies that the word "each" could be interpreted as a valid hexadecimal contant (same as 0xEAC)
May 03 2002
You probably won't read this (stuck in the middle of this old email), but my suggestion would be to put case-senstivity in the error message as some ada versions did. When a variable/functions definion is not found, suggest an alternative in the error message. ie "Variable not found. Did you mean ...." I found that quite helpful, and a smart IDE could take this further. "Walter" <walter digitalmars.com> wrote in message news:aarmn9$1eip$4 digitaldaemon.com..."John English" <je brighton.ac.uk> wrote in message news:3CD1479A.91A6CBDC brighton.ac.uk...I've only read the first few sections of the manual, but I noticed a few things in the lexical grammar already: 1) the grammar for hex constants contains a misprint (0b instead of 0x) 2) the grammar for HexadecimalH constants looks ambiguous as is: it implies that the word "each" could be interpreted as a valid hexadecimal contant (same as 0xEAC) 3) the grammar shows h or H as valid suffixes for HexadecimalH, but not prefixes 0B or 0X... is this intentional? 4) A nice addition to the list of escape characters would be \e for ESC.Thanks, I'll go back through the documentation.Also, re (3) above, can I make a plea for case insensitivity throughout? Students that I teach Java to waste an awful lot of their time dealing with spelling mistakes: they write RunTimeException instead of RuntimeException, or HashTable instead of Hashtable, or Hashmap (by analogy with Hashtable) instead of HashMap... What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word...D is case sensitive because C is <g>. But seriously, this is one of those no-win topics like brace indenting styles. If D was a pascal successor, it would be case insensitive, but since it is in the tradition of C like languages (and can interface directly to C), it is case sensitive.
May 20 2002
"anderson" <anderson firestar.com.au> wrote in message news:acaui6$f8v$1 digitaldaemon.com...You probably won't read this (stuck in the middle of this old email), butmysuggestion would be to put case-senstivity in the error message as someadaversions did. When a variable/functions definion is not found, suggest an alternative in the error message. ie "Variable not found. Did you mean ...." I found that quite helpful, and a smart IDE could take this further.A good idea, it is. As for the IDE, well, Visual Assist successfully fixes such errors on the fly, as you type identifiers in the editor. So cwindow becomes CWindow, etc
May 20 2002
What about the extreme cases where there are 2 or more declarations of differn't case for the same name? Does it give you an option or warning? "Pavel Minayev" <evilone omen.ru> wrote in message news:acb3pj$kf2$1 digitaldaemon.com..."anderson" <anderson firestar.com.au> wrote in message news:acaui6$f8v$1 digitaldaemon.com...butYou probably won't read this (stuck in the middle of this old email),myansuggestion would be to put case-senstivity in the error message as someadaversions did. When a variable/functions definion is not found, suggestalternative in the error message. ie "Variable not found. Did you mean ...." I found that quite helpful, and a smart IDE could take this further.A good idea, it is. As for the IDE, well, Visual Assist successfully fixes such errors on the fly, as you type identifiers in the editor. So cwindow becomes CWindow, etc
May 20 2002
"anderson" <anderson firestar.com.au> wrote in message news:accfii$1rme$1 digitaldaemon.com...What about the extreme cases where there are 2 or more declarations of differn't case for the same name? Does it give you an option or warning?The compiler (MSVC) doesn't. The IDE just don't do any automatic fixes in such a case. Also, you really shouldn't propose Walter to add warnings - he hates 'em. =)
May 20 2002
Sorry, I was talking about the IDE Visual Assist , and it wasn't a proposal, it was a question. I know VB does something simular, but it's case-insentitive to start with. "Pavel Minayev" <evilone omen.ru> wrote in message news:accfsn$1rq9$1 digitaldaemon.com..."anderson" <anderson firestar.com.au> wrote in message news:accfii$1rme$1 digitaldaemon.com...=)What about the extreme cases where there are 2 or more declarations of differn't case for the same name? Does it give you an option or warning?The compiler (MSVC) doesn't. The IDE just don't do any automatic fixes in such a case. Also, you really shouldn't propose Walter to add warnings - he hates 'em.
May 20 2002
"John English" <je brighton.ac.uk> wrote in message
news:3CD1479A.91A6CBDC brighton.ac.uk...
[...]
3) the grammar shows h or H as valid suffixes for HexadecimalH, but
not prefixes 0B or 0X... is this intentional?
[...]
Also, re (3) above, can I make a plea for case insensitivity throughout?
Students that I teach Java to waste an awful lot of their time dealing
with spelling mistakes: they write RunTimeException instead of
RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
analogy with Hashtable) instead of HashMap... What possible benefit
do you get from case sensitivity? Why do you want to be able to
distinguish between String and string and STRING, which any native
English speaker would regard as different representations of the
same word...
Seconded (though I suspect the D implementation and underway are advanced to
the point of no return).
I can think of no reason for D to remain case-sensitive save the need to be
link-compatible with C. Although the ANSI/ISO standard states that external
identifiers need not be case sensitive, it's possible that some arbitrary C
library might contain the same name with only a letter-case distinction, in
which case D needs case-sensitivity to be able to resolve these. I suspect
this is rare enough that it might be reasonable to require stubbly little C
functions be written to resolve the difference, but even if not, D could
make the rule that extern(C) identifiers are case-sensitive but D
identifiers are not.
--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net (personal)
May 02 2002
"Richard Krehbiel" <rich kastle.com> wrote in message news:aarn3p$1fp5$1 digitaldaemon.com..."John English" <je brighton.ac.uk> wrote in message news:3CD1479A.91A6CBDC brighton.ac.uk...to[...] 3) the grammar shows h or H as valid suffixes for HexadecimalH, but not prefixes 0B or 0X... is this intentional? [...] Also, re (3) above, can I make a plea for case insensitivity throughout? Students that I teach Java to waste an awful lot of their time dealing with spelling mistakes: they write RunTimeException instead of RuntimeException, or HashTable instead of Hashtable, or Hashmap (by analogy with Hashtable) instead of HashMap... What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word...Seconded (though I suspect the D implementation and underway are advancedthe point of no return). I can think of no reason for D to remain case-sensitive save the need tobelink-compatible with C. Although the ANSI/ISO standard states thatexternalidentifiers need not be case sensitive, it's possible that some arbitraryClibrary might contain the same name with only a letter-case distinction,inwhich case D needs case-sensitivity to be able to resolve these. Isuspectthis is rare enough that it might be reasonable to require stubbly littleCfunctions be written to resolve the difference, but even if not, D could make the rule that extern(C) identifiers are case-sensitive but D identifiers are not.I am far from a language guru (though by reading here, I am learning about some of the issues - thanks to everyone), but I have some, perhaps dumb, questions. Some time ago, someone here suggested a scheme (I'm sorry, I can't remember the name) where identifiers were once you defined an identifier, any attempt to use an identifier that was the same letters but different cases was an error. Doesn't this solve the huge screw-up potential of case sensitivity (multiple different identifiers that should really be the same) while fixing the arbitraryness of allowing full case insensitivityness? It seems like a good compromise. It seems another possibility is to make case sensitivity or not for all internal names something like a compile time pragma. That is, a user could use whichever he wanted, as long as it was clearly specified in the source code. Of course, organizations could set easily enforced standards for their programmers. The overhead in the compiler should be minimal What am I missing? -- - Stephen Fuld e-mail address disguised to prevent spam
May 03 2002
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message news:aaube8$2b3e$1 digitaldaemon.com..."Richard Krehbiel" <rich kastle.com> wrote in message news:aarn3p$1fp5$1 digitaldaemon.com...advancedSeconded (though I suspect the D implementation and underway arearbitraryto the point of no return).I can think of no reason for D to remain case-sensitive save the need to be link-compatible with C. Although the ANSI/ISO standard states that external identifiers need not be case sensitive, it's possible that somelittleC library might contain the same name with only a letter-case distinction, in which case D needs case-sensitivity to be able to resolve these. I suspect this is rare enough that it might be reasonable to require stubblyI remember that one; the suggestion would have these effects: int MixedCaseName; MixedcaseName = MixedcaseName + 1; ***ERROR: no such identifier 'MixedupName' So far, it looks case-sensitive. int MixedUpName; int mixedupName; ***ERROR: differs from 'MixedCaseName' in letter case only. ...but this is remarkable. It's case-sensitive because you can't use an identifier except by exact match. It's case-insensitive because it rejects the declaration of a variable spelled the same but with different letter case. I personally would rather not have a schizoid compiler.C functions be written to resolve the difference, but even if not, D could make the rule that extern(C) identifiers are case-sensitive but D identifiers are not.I am far from a language guru (though by reading here, I am learning about some of the issues - thanks to everyone), but I have some, perhaps dumb, questions. Some time ago, someone here suggested a scheme (I'm sorry, I can't remember the name) where identifiers were once you defined an identifier, any attempt to use an identifier that was the same letters but different cases was an error. Doesn't this solve the huge screw-up potential of case sensitivity (multiple different identifiers that should really be the same) while fixing the arbitraryness of allowing full case insensitivityness? It seems like a good compromise.
May 03 2002
"Richard Krehbiel" <rich kastle.com> wrote in message news:aaucs7$2cdl$1 digitaldaemon.com..."Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message news:aaube8$2b3e$1 digitaldaemon.com...to"Richard Krehbiel" <rich kastle.com> wrote in message news:aarn3p$1fp5$1 digitaldaemon.com...advancedSeconded (though I suspect the D implementation and underway areto the point of no return).I can think of no reason for D to remain case-sensitive save the needdistinction,arbitrarybe link-compatible with C. Although the ANSI/ISO standard states that external identifiers need not be case sensitive, it's possible that someC library might contain the same name with only a letter-casecouldlittlein which case D needs case-sensitivity to be able to resolve these. I suspect this is rare enough that it might be reasonable to require stubblyC functions be written to resolve the difference, but even if not, Daboutmake the rule that extern(C) identifiers are case-sensitive but D identifiers are not.I am far from a language guru (though by reading here, I am learningbutsome of the issues - thanks to everyone), but I have some, perhaps dumb, questions. Some time ago, someone here suggested a scheme (I'm sorry, I can't remember the name) where identifiers were once you defined an identifier, any attempt to use an identifier that was the same lettersshoulddifferent cases was an error. Doesn't this solve the huge screw-up potential of case sensitivity (multiple different identifiers thatI presume you mean 'MixedcaseName' in the error message. Even so, why can't the error message take note that there is an identically spelled, but differently cased identifier and note that exactly as in the example you give below? It is still an error and the message is more informative.really be the same) while fixing the arbitraryness of allowing full case insensitivityness? It seems like a good compromise.I remember that one; the suggestion would have these effects: int MixedCaseName; MixedcaseName = MixedcaseName + 1; ***ERROR: no such identifier 'MixedupName'So far, it looks case-sensitive. int MixedUpName; int mixedupName; ***ERROR: differs from 'MixedCaseName' in letter case only. ...but this is remarkable. It's case-sensitive because you can't use an identifier except by exact match. It's case-insensitive because itrejectsthe declaration of a variable spelled the same but with different letter case. I personally would rather not have a schizoid compiler.Agreed, but I don't see why it has to be so. -- - Stephen Fuld e-mail address disguised to prevent spam
May 03 2002
John English wrote:I've only read the first few sections of the manual, but I noticed a few things in the lexical grammar already:1 and 3 I think these are typographical errors in the manual. 2 the manual may be unclear on... [a-zA-Z]+ -> label [0-9][0-9a-fA-F][hH] -> hex number therefore each -> label 0each -> hex number4) A nice addition to the list of escape characters would be \e for ESC.Maybe useful, and I do not '\e' is currently used. Personally I would prefer \[ like in bash.Also, re (3) above, can I make a plea for case insensitivity throughout? Students that I teach Java to waste an awful lot of their time dealing with spelling mistakes: they write RunTimeException instead of RuntimeException, or HashTable instead of Hashtable, or Hashmap (by analogy with Hashtable) instead of HashMap...I think you are blaming case sensitivity for what are errors in the Java library. If the naming convention commonly used in Java had been used throughout this would not be a problem - there is a difference between bad design and bad implementation, however this fault is little more than the annoying and incessant mispelling of colour in may programming languages. I personally prefer case sensitivity - but it is one of those topics where there is no right answer. When teaching others case insensitive languages are slightly easier, but writing language lexagraphical analisers it becomes an more difficult problem - especially when you consider the mess that is Unicode (id est. where one letter may be represented by multiple combinations and there is no simple algorithm to convert lower to upper case efficiently as exists with ASCII)What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word...Then why do we differentiate between them in English? - maybe we should all start writing like e.e.cummings :-). My guess is it is convention, C is case sensitive and, as D is based on C, D is case sensitive too. Now is probably to late to vote for a change, however the proposed scripting language based on D (see D-- thread) may be a candidate for case insensitivity. I find the difference useful a it allows me to differentate between classes, structures and unions by using a capital first letter effectively creating a separate name space from the remainder of the variables which are instances of these objects.University of BrightonBring us all some Brighton Rock :-) C 2002/5/2
May 02 2002
"C.R.Chafer" wrote:I personally prefer case sensitivity - but it is one of those topics where there is no right answer. When teaching others case insensitive languages are slightly easier, but writing language lexagraphical analisers it becomes an more difficult problem - especially when you consider the mess that is Unicode (id est. where one letter may be represented by multiple combinations and there is no simple algorithm to convert lower to upper case efficiently as exists with ASCII)??? All you do is get the lexical analyser to flatten everything to a single case (e.g. lowercase) when constructing tokens; it's a more difficult matter with Unicode (can't just build a 256-byte mapping table anymore) but it's hardly insuperable... and then the lexer churns out tokens which are always in a single case. End of problem.Well, at least I can tell that e.e.cummings is the same guy as E.E.Cummings. In a case sensitive language they'd be two completely separate people. Still, I guessed this would be a lost cause...What possible benefit do you get from case sensitivity? Why do you want to be able to distinguish between String and string and STRING, which any native English speaker would regard as different representations of the same word...Then why do we differentiate between them in English? - maybe we should all start writing like e.e.cummings :-).> University of Brighton Bring us all some Brighton Rock :-):-) ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------
May 03 2002
"John English" <je brighton.ac.uk> wrote in message news:3CD276CE.E34BE7EB brighton.ac.uk...??? All you do is get the lexical analyser to flatten everything to a single case (e.g. lowercase) when constructing tokens; it's a more difficult matter with Unicode (can't just build a 256-byte mapping table anymore) but it's hardly insuperable... and then the lexer churns out tokens which are always in a single case. End of problem.Not so fast! Don't forget about imported functions... there should definitely be some way to preserve case. Or, use the "proper case" convention: identifier is defined once, and definition is case-sensitive. Further references are converted to this proper case.
May 03 2002
"Pavel Minayev" <evilone omen.ru> wrote in message news:aau5lf$25kg$1 digitaldaemon.com...Not so fast! Don't forget about imported functions... there should definitely be some way to preserve case. Or, use the "proper case" convention: identifier is defined once, and definition is case-sensitive. Further references are converted to this proper case.I like that idea best out of all I've heard so far. Sean
May 03 2002
Well, at least I can tell that e.e.cummings is the same guy as E.E.Cummings. In a case sensitive language they'd be two completely separate people. Still, I guessed this would be a lost cause...Actually they probably are different people. The first is the poet and the second is somebody else. Case does provide semantic meaning. Karl Bochert
May 03 2002
You say that names with different case have the same semantic? Remember mathematics! There we used very often the same letters written in different case to denote not only different things, but even different types. Then I don't think it's good idea that 'X' and 'x' are the same. In programming also there are many places where we can somehow select (highlight) some var with changing case. Thus, I think the only problem that case-sensitivity makes concerns "MySpecialVar"-type of names. But this could be easily resolved by programmer (not compiler) when good notation system is used. Nic Tiger. "Karl Bochert" <kbochert ix.netcom.com> wrote in message news:1103_1020441383 bose...Well, at least I can tell that e.e.cummings is the same guy as E.E.Cummings. In a case sensitive language they'd be two completely separate people. Still, I guessed this would be a lost cause...Actually they probably are different people. The first is the poet and the second is somebody else. Case does provide semantic meaning. Karl Bochert
May 03 2002
Sorry, but this string String STRING stuff sounds like a guy I once worked
with who took the egregious
#define retrun return
with him wherever he went because he couldn't type well.
It's surely not the "case" that case insensitivity makes things easier to
teach, rather that it is easier to teach to people who want to be sloppy?
One only has to do a single days Windows programming to come across the M$
violation of the global namespace (both preprocessor and C/C++) to realise
that it is more, not less, discipline that is required to produce competent
software engineers, and that we are lacking them in large numbers.
"John English" <je brighton.ac.uk> wrote in message
news:3CD1479A.91A6CBDC brighton.ac.uk...
I've only read the first few sections of the manual, but I noticed a
few things in the lexical grammar already:
1) the grammar for hex constants contains a misprint (0b instead of
0x)
2) the grammar for HexadecimalH constants looks ambiguous as is:
it implies that the word "each" could be interpreted as a valid
hexadecimal contant (same as 0xEAC)
3) the grammar shows h or H as valid suffixes for HexadecimalH, but
not prefixes 0B or 0X... is this intentional?
4) A nice addition to the list of escape characters would be \e for
ESC.
Also, re (3) above, can I make a plea for case insensitivity throughout?
Students that I teach Java to waste an awful lot of their time dealing
with spelling mistakes: they write RunTimeException instead of
RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
analogy with Hashtable) instead of HashMap... What possible benefit
do you get from case sensitivity? Why do you want to be able to
distinguish between String and string and STRING, which any native
English speaker would regard as different representations of the
same word...
-----------------------------------------------------------------
John English | mailto:je brighton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
May 05 2002
"Matthew Wilson" <matthewatd hotmail.com> wrote in message news:ab2or3$1teu$1 digitaldaemon.com...Sorry, but this string String STRING stuff sounds like a guy I once worked with who took the egregious #define retrun return with him wherever he went because he couldn't type well.LOL!It's surely not the "case" that case insensitivity makes things easier to teach, rather that it is easier to teach to people who want to be sloppy? One only has to do a single days Windows programming to come across the M$ violation of the global namespace (both preprocessor and C/C++) to realise that it is more, not less, discipline that is required to producecompetentsoftware engineers, and that we are lacking them in large numbers.But isn't this one of the problems? No matter if you use HungarianNotation like Microsoft does or lower_case like the C standard library, with case sensitivity you are forced to use other peoples conventions, even if they conflict with each others or with yours! Then again in pascal I see code that contains the same symbol spelled in many different ways: begin Begin BEGIN Even in the same source file! I think that this makes me want to lean towards case sensitivity. But I am not 'sensitive' on the issue. :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 05 2002
"OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ab3u9t$2tna$1 digitaldaemon.com...Then again in pascal I see code that contains the same symbol spelled in many different ways: begin Begin BEGINOh yeah... and then Integer, and tRect and IF in that same file. =) I do remember these things. That's why I'm for case sensitivity
May 05 2002
"Pavel Minayev" <evilone omen.ru> wrote in message news:ab3v4b$2uap$1 digitaldaemon.com...Oh yeah... and then Integer, and tRect and IF in that same file. =) I do remember these things. That's why I'm for case sensitivityI've used both case sensitive and insensitive languages. I much prefer the sensitive ones, though I can't give a good reason why. Perhaps it's because I get better results from grep when I'm looking through files <g>.
May 15 2002