[chief1983]

The PS3's Cell processors.

[blackhole]

Case sensitivity is a tool of the devil.
Frankly, we'll never agree on the rest - languages are supposed to be tools meant for optimal ease of use and efficiency, not flaming crucibles to test some kind of programmer iron.

Case sensitivity is awesome. As long as you don't name variables something like foOpIE, its quite useful in many regards, such as having things like FooClass fooclass = new FooClass(moreFoo); As long as you keep to capitalizing classes and keeping variables mostly lowercase, there's rarely any problems.

languages are supposed to be tools meant for optimal ease of use and efficiency

Programming language are supposed to do whatever they're supposed to do. If you want to make a program in 5 seconds that takes 5 days to figure out that its not connected to the internet, use visual basic. If you want to spend 5 hours coding a program that takes 5 seconds to figure out that its not connected to the internet, plus a slight chance of making your computer explode, use C++.

Graphics, by their very nature, require every last ounce of processing power a computer is capable of, and therefore, C++ will forever and always reign supreme in that area, unless of course an unmanaged language like D takes over. Can you make tetris using VB? Sure. Can you make Crysis using VB? Uh, no.

[chief1983]

Yeah, without case sensitivity we wouldn't have much use for CamelCase.

[Scooby_Doo]

Case-insenstive... icky about as bad as weakly typed languages.

[phatosealpha]

FooClass fooclass?

Please dear god tell me you're kidding me. 

If your class is of such limited use that a single instance makes sense, then why aren't you just making the thing a static class?
If it's NOT so limited that you're using a single instance, then give the instances a properly descriptive name.


Frankly, if graphics REALLY required every last ounce of processing power, you'd be programming in assembly.  But you're not, are you?  You've already decided that yes, it's acceptable to trade off processing power for ease of development.  We're just quibbling about how much to trade.

[Scooby_Doo]

Well if I'm thinking what blackhole is thinking, then if you make it static you can't do something like this:

FooClass fooClass = new FooClass (morefoo) ;
fooClass.FooAmount = amountofFoo ;

[phatosealpha]

So why not just set morefoo in the type initializer, since there is only going to be one FooClass anyway?

Or name the variable something useful, like FooClassSingleton, or GlobalFooClass?  At least then someone looking at you code can pretty much figure out from the variable name what the variable is for.
I mean, naming it FooClass only manages to tell us that it's a FooClass, which really isn't especially useful information, since presumably, if we're calling the variable by name, we have a pretty
good idea what it is.  I'm failing to see how naming them the exact same thing except for a capitalization if providing any useful information to the poor bastard who's going to have to maintain the code.

[Scooby_Doo]

There's more than one FooClass: fooClass and morefoo

Course who would name their class "FooClass"? ok don't answer that one 

[blackhole]

Frankly, if graphics REALLY required every last ounce of processing power, you'd be programming in assembly.  But you're not, are you?  You've already decided that yes, it's acceptable to trade off processing power for ease of development.  We're just quibbling about how much to trade.

Oh I love this argument! It seems to be everyone's favorite "lets bash C++!" argument this year. Well, guess what, you can't do object-oriented programming in assembly. You can't do modular engines in assembly. You can, however, do all that in C++. In order to make a graphics engine, it is a requirement that the language you are programming in is capable of these kinds of things. Therefore, C++ is the lowest-level programming language you could feasibly program a graphics engine in while still getting it run as fast as possible. Saying I'm trading processing power off for ease of development is misleading, because to do the things you need to do with a graphics engine, you cannot do it in assembly, or C. I'm willing to trade nothing - I am building my graphics engine in the lowest possible programming language I can.

Another thing that everyone seems to conveniently forget is that to use DirectX, you've got to use C++. There is no way around that. You. Have. To. Use. C++. It doesn't matter if I wanted to code everything in assembly; you still have to use C++ to use DirectX, unless you want to forego the use of DirectX’s libraries, which is 1. stupid beyond all understandable belief and 2. a completely different argument altogether. Its the same for most of the advanced openGL functions as well.

I'm failing to see how naming them the exact same thing except for a capitalization if providing any useful information to the poor bastard who's going to have to maintain the code.

Classes are used to declare variables. That is where their scope-sharing stops. The use of FooClass fooClass = new FooClass(); is exactly 1 line of potentially confusing code. Throughout the entire rest of the function, fooClass is the only thing thats ever going to be used, and FooClass isn't going to be anywhere near it. If you think its so abhorrently difficult to maintain such code, please explain to me why such practices exist and are widespread throughout the entire programming industry?

Irrlicht does it.
Ogre does it.
Freespace 2 does it.
Every single program written at Microsoft does it.
Every single C++ and C# program I've ever downloaded does it.

Seriously, its everywhere. Saying its stupid is like telling the universe that stars are a bad idea.

[Scooby_Doo]

Actually I don't think you need to use C++ to use Direct, you just need to have the translated interfaces.  I remember seeing an old DirectX ported for Delphi quite some time ago.

[Spicious]

And case insensitivity would be better because...?

[Scooby_Doo]

How about difference between DataResult (property) and dataresult(value)?  If I call Dataresult = somevalue, which one does it use?

[blackhole]

Actually I don't think you need to use C++ to use Direct, you just need to have the translated interfaces.  I remember seeing an old DirectX ported for Delphi quite some time ago.

Thats not what i was talking about. Yes, you can use translated interfaces, but there isn't one available for a non-object oriented language, because directX itself is object-oriented.

[Ghostavo]

How about difference between DataResult (property) and dataresult(value)?  If I call Dataresult = somevalue, which one does it use?

Neither of them, it would complain that the variable Dataresult wasn't declared.

[Scooby_Doo]

How about difference between DataResult (property) and dataresult(value)?  If I call Dataresult = somevalue, which one does it use?

Neither of them, it would complain that the variable Dataresult wasn't declared.

In case sensitive languages, yes.

[Ghostavo]

So what was your point on that one?

Quoting Spicious...

And case insensitivity would be better because...?

[Flipside]

From my own point of view, people shouldn't be naming variables and classes with the same name anyway, but in vast, multi-person projects, that is going to be extremely difficult to maintain. It's like the need to slap someone round the head when I see them using the Java 'This' command.

I actually like cased languages, it gives a lot more flexibility on variable names (and yet, for some reason, I have a habit of defining Booleans as all caps), and makes the language more 'readable' from a purely aesthetic position.

I've always defined variables thusly:

thisIsAVariable - therefore, the first letter is always a lower case, all further words lineated with Caps.

whereas:

ThisIsAClass - using this, it means I can tell whether the program is dealing with an array, an object or a field at a glance.

For example, you see a line of code the reads:

if CheckList(14) then XXXX

now, without casing, you might be looking at a value being passed to a test method, or the 15th object in a variable array, by using the naming convention, you know that what you are dealing with in this case is a Method, whereas checklist(14) is the 15th item in the array checklist.

[phatosealpha]

Like telling the universe that stars are a bad idea.  Or perhaps like telling Americans that Drunk Driving is a bad idea, based on how widespread it is.  One of the reasons C++ is what it is, is because people resist change.  A common bad idea is still a bad idea - I'm amazed you'd even try to argue something like that.

And yes, what appears to be an infinitesimal amount of power for usability is still a trade, whether you like it or not.  Hell, you could even go in, write everything in C++, then go hand optimize the machine language you're putting out.  But you're not going to do that either, are you?  Because it's too goddamned much trouble for too little gain.



Flipside - Case insensitive isn't equal to case-less.  The VB.net approach is very simple - define it in any form of capitalization you'd like, and when you use it again, no matter what the case you type in was, it's going to know which variable that is.  And it's even going to nicely change whatever casing you type to match whatever you'd declare it to be.  Since the advantages there are all wholly dependent on your team following the regulations of naming conventions, they can exist just as well in a case insensitive language.

And that's the plus side of well done case insensitivity.  Declare once, in any casing you'd like, then just type and let the dev environment worry about capitalization.  Are you guys seriously going to tell me you write entire blocks of code without any casing errors?  Why sign up for more typos?  What are you seriously gaining by having the ability to have a variable named Foo and a variable named foo?




Dataresult(property) and dataresult(value) are going to be determined by context.  Ideally, what it should do is throw an error that you're writing ambigious code, because you are.  Qualify it with the namespace if you're going to do that, or better yet, refuse to name the variable the same thing as a class.

[blackhole]

One of the reasons C++ is what it is, is because people resist change.  A common bad idea is still a bad idea - I'm amazed you'd even try to argue something like that.

So me resisting change is why I use C# 50% of the time, or is that just because I like to use the best language for the job? Have you completely forgotten that I used to program in Visual Basic? Case-insensitivity, in my experience, is a handicap. I like case-sensitive languages. When I moved to C#, suddenly everything was case-sensitive and I was like "Oh wow thats going to make everything so much harder - oh wait, this is awesome." This is not me saying "WE HAVE ALWAYS DONE IT THIS WAY AND WE ALWAYS WILL BECAUSE WE ARE DUMB TRADITIONALISTS," this is me saying that after having sampled both methods, I find that case-sensitivity is the one I prefer.

Because it's too goddamned much trouble for too little gain.

My listview control in my .net app takes up 11% of a quad-core CPU just by me holding the mouse down and scrolling up and down the list very fast. What the **** is that? Its not any of my code, because I have no code associated with that event (I've checked). I have no control over it. It just sucks up that CPU and flips me off. In C++, it wouldn't bump up the CPU by a single percentage point.

C++ is all about control. Its a heck of a lot easier to write really fast code that does exactly what you want and nothing more in a C++ app then in a managed application, where you get a crapload of overhead because of all the baggage that comes with it. You can, with a painful amount of work, get rid of some of that overhead, but 1. you still won't be as fast as C++ would be and 2. You could have programmed the whole thing in C++ by now!

My point is, in preformance critical applications, the amount of time you'll spend optimizing your managed code offsets whatever ease-of-production gains you get from using it.

[Ghostavo]

My main problem with case insensivity would be the lack of uniform reserved words. Sure it's an aesthetic problem, but so is having 5 variables whose only difference is casing (although I would cry at the sight of it).

I assume most people would find case sensitive with case preventive to be the most natural.