Of course, if you used a ditto machine it didn't matter if the monochrome result sucked. All you had to do was sniff it and it was just fine...

Yep. I've got all three side-by-side along with VS6 under XP. No problems so far.

I've got to agree. While it took some getting used to, I like the new interface. Especially in Outlook, where I no longer have to surf all over the screen to set appointment options. The private appointment toggle is now up with the other settings where it belongs, instead of hiding out down in the lower right hand corner all by itself.

My wife and I went to the Legoland in Carlsbad, CA for a day on our honeymoon in 2001 and it was amazing. A lot of the really intricate things were built out of standard pieces.

What got me excited about LINQ was a post I read somewhere where they were talking about PLINQ, where some of the LINQ queries are automatically parallelized to take advantage of multi-core environments. It made the point that performaing that optimization was possible with LINQ because you tell the compiler what you want to accomplish, not what steps to take to accomplish that.

MrPlankton wrote:

No differance between vb and c# in capability...

Not true, actually. There are some parts of the underlying IL that are exposed differently by VB.NET and C#. Try overriding an inherited interface implementation in VB.NET. It won't allow you to do that. Try it in C# and it works just fine. Of course, some would argue that you shouldn't ever do that in practice, but that is another discussion.

I'll disagree with a number of the posts on this topic. One of the first projects where I did any OO design was done in C for real time control of a robotic palletizing system. It went into production in 1992 on 2 386sx16s with 1MB of memory for each cell, and a 386dx33 with 4MB for the overall controller. It is still in use today on the same hardware, with the software still only using a fraction of the memory and processing power available to it. We developed standard interfaces for the PLC communication, digital I/O, etc so that we could build additional iterations of the system and plug different hardware into the same control logic as needed. We also wrote a custom object request broker to glue everything together. It included the ability to tell an object to persist its state to the filesystem and then restart, enabling hot patching of the system.

rolandoC wrote:

Myself, I use 1152×864, but that is partly because I code in LabVIEW with a limitedly large screen.

LabVIEW development on a single screen that size? Sounds pretty painful to me. That is an environment that benefits greatly from two displays. 1920x1200 laptop/1280x960,1024x768 desktop

Dario Solera wrote:

The upload bandwidth is 384 Kbit/s and, altought we have not big images or something, the response of the website is quite slow (on localhost it's blazing fast).

I briefly hosted a DotNetNuke site off my Comcast connection (224Kbits upload) while we were deciding if the idea would go big enough to be worthwhile hosting it somewhere. As long as you have a fast enough CPU to support it, turning on IIS6 compression for dynamic content made the site feel quite a bit more responsive when connecting remotely. I put the web server behind a firewall (IPCop, in this case) and only forwarded 80/443 to the Windows Server box.