No need to invent clever algorithms if you know and understand the basic design patterns. These patterns (mostly) transcend languages and help to create understandable and efficient code.

Rarely have a problem with closing files. Much more often have a problem with opening them. Opt-in GC is nice, but can cause confusion in large systems because it is easy to confuse objects and forget which is GC'd and which must be manually de-allocated. I also like that GC can run when the CPU is not in use. It's like automatically multi-threading your deallocation for speed optimization (at the expense of memory of course). Agreed on WCF and COM. I think all MS developers are familiar with the term "Dll hell".

Quicksort in C#: array.sort(); There... done. :) And yes, I could code quicksort from scratch, but what is the bloody point? I'm not trying to show off and very few people get to see my code anyway. I argue that picking the "right" language was once a very important thing. These days it is getting to be less so. It is far more important to pick the "right" design pattern. I recomend the following book for any coder. Know it and live it. http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

I've never had a problem with C# garbage collection. I close my files when I'm done with them rather than in the descructor for example. I have had many problems with C++ memory allocation and COM reference counts however. I've spent hundreds of hours over the years trying to find out why a given object still has a reference count and is not destructing. I've also spent countless hours tracking weak references and null pointers. Not fun... and never again now that I use C# for most (but not all) of my coding.

Besides, using "using" works nicely for scoping classes.

In my experience (more than most of you less than others), most slow operations are a result of poor algorithm design. I don't care what language you use, a Theta N^N operation on any decent size dataset is going to be slow. C/C++ really only optimizes the way that calls are made and memory allocation and de-allocation. One of the beauties of modern languages and technologies like C# and .Net is that many, perhaps most common operations such as searching or sorting an array, collection or dictionary are already coded in a very efficient way. The developer can spend more time focusing on functionality rather than optimization. Additionally, some of what many consider "extravagant useless features" like garbage collection can enhance performance (at the cost of memory) by waiting for free CPU cycles to do unimportant work. And now with multi-core systems, parallel execution is a must for any high performance application. I've done some multi-threading in C and even assembly, but I don't recommend it... Besides, in a business environment, there is little cost to slow application performance in relation to slow development time. I can write the same application in C# in 1/10th the time it would take to code up in C++ (and never finish in C).

As soon as you said "kenetic energy" it all clicked. The temperature is in effect unlimited by the very nature of E=mc^2. The temperature being a measure of E must be infinite for the particle speed to reach c. Balanced by the fact that the relative mass would also be infinite at c. Nice... Thank you - unless I've got it wrong, then please correct. But it seems pretty simple now.

Since it sounds like you might have an answer, I've had this question for a long time. If a particles heat can be represented by it's entrophic motion, and since motion is limited by the speed of light, is there an absolute maximum temperature for a particle? Can a particle use uncertanty to violate this limit? Sorry for the off-topic post, but I've never had a better oportunity to ask this question and expect an intelligent answer.

oh yeah.. way worse than Cunningham, Stevens, Delay or a whole slew of other Republicans... (I do realize that Cunningham and Stevens were congressmen)

Perhaps you can answer a question for me. If I understand the concept correctly (and stop me where I go wrong), the event horizon can be defined as the point where any light that were to be ejected (I know, I know not possible) from the singularity perpendicular to the tangent (straight "up") would stop and return. With some simple evaluation, this means that the frequency of any light at the event horizon would be infinite to the "inside?" observer. A similar effect is observed on the "outside" going in whereas the light at the event horizon falling straight in has an infinite frequency to the outside observer. Given the relativistic time stretching effects that this implies, as I understand it, anybody falling in would experience "the end of the universe" as time around him speeds up infinitely. My question is, assuming that I am not simply mistaken about the relativistic effects of the event horizon, is; what happens to that item falling into the black hole when the black hole evaporates? What doest that item experience? Does the universe speed around it up until the black hole evaporates whereby it is released back into the universe? Does the item evaporate with the black hole? Is the item converted into radiation before it gets to the horizon and thus released over time before the black hole evaporates?