Viv
Here's a simple example

this.oCommand.CommandType = CommandType.Text

Why can't I just say
this.oCommand.CommandType = "Text"?
or
this.oCommand.CommandType = "StoredProcedure"?

I understand the theoretical basis of their syntax, but practically, "Text" is pretty clear.

And all this casing crap. I agree with casing for names of properties, methods ,etc, but for boilerplate?
if I write this.oCommand.commandtype = etc can't they figure that out?



>Out of curiosity - what do you find annoying about C# ?
>
>>I agree with Craig.
>>
>>I started programming with op codes and addresses.
>>It took almost an hour to compile assembler on the IBM 705, so we skipped that step and wrote op codes and addresses ourselves.
>>When you only have 10K of memory, it's not a big deal to keep track of memory addresses. In fact, it's essential that you do.
>>If you want real flexibility at a level that operates very close to the CPU, memory, etc. you can't beat op codes.
>>However I won't be doing op codes and addresses again (I hate hex!) any time soon.
>>
>>As computers became more powerful it became obvious that if computers were going to be of any use to anyone, they first had to be useful to programmers by taking as many mechanical tasks out of programming as possible.
>>
>>I gave up on C and C++. They are Neanderthals. I don't care what they can do.
>>The first thing any modern language has to do is simplify things for the first user.. the programmer.
>>
>>VFP does that quite well.
>>
>>Another language that I think is underrated is SQL. It's simple, powerful and it does what is designed for very well.
>>
>>C# is a good language, but it could be better. There are still too many petty annoyances in it.
>>
>>
>>
>>
>>
>>>There are fundamental mechanisms at work at the CPU level, which are still present today.
>>>
>>>C/C++ expose those mechanisms in a way that is assembly-language / machine code (opcode) neutral while providing a powerful mechanism to express complex ideas in human readable terms, yet at a level that operates very close to the physical capabilities of the CPU, memory, and device subsystem (ports).
>>>
>>>C/C++ allow complex, reusable, extensible code to be written for many platforms without regard to their CPU's machine code requirements. The C/C++ standards provide for that ability without the need for a virtual machine and all its inherent slowdowns (Java, .NET).
>>>
>>>C/C++ are still the domain of the most general purpose, fastest code, even today. Only hand-coded assembly beats it (but at the expense of about 15x as many labor hours to produce the same product, and the speedups are typically only a few percentage points).
>>>
>>>For most apps the level of performance C/C++ provides doesn't matter. Yet, for several it is absolutely essential. There would be no Java without C/C++. There would be no .NET without C/C++. There would be no [insert other high level language here] without C/C++ at somewhere fundamental to the tool chain.
>>>
>>>C/C++ have their place. The entire Linux kernel was written in C even (no C++ at all) and it still is today. Linux is used in every Android device, as is C/C++. And that's billions of computers worldwide. C/C++ is the true, fundamental backbone of Java VMs, as well as .NET. It remains a wholly integrated, absolutely essential, first tier player in every operating system toolkit. And GCC has created a FLOSS framework that allows the C/C++ standard to be ported to new CPUs in about a week's worth of work (modifying the templates used to produce machine code, yet without changing anything in the GCC compiler itself). This allows truly amazing ports where the GCC toolchain will continue to operate correctly, even on brand new CPUs.
>>>
>>>Certain developers have reasons to go into C/C++. Others do not. For some projects it makes no sense to go through the rigors of the lower-level abilities to attain what could be done in a higher level language with a much easier syntax. Other projects could not be done in any other way.
>>>
>>>C/C++ have their firm place. It's not for everybody.
>>>
>>>
>>>
>>>>My condolences. I did C/C++ for a few years and hated every minute of it. I'm convinced that the creators of C were on drugs. Seriously, computers should make things easier, not harder. Pointers to define strings? I shouldn't have to deal with that mess. The language and compiler should take care of those details for me. Different types of strings that aren't compatible? What a pain in the a$$. And don't get me started on pointers to pointers.