According to this report C# has seen it's user base double over the last six months, and should double again in the next year.
Read the fine print, and C# usage was at 6% six months ago, and stands at 12%, according to a survey of 800 developers by a polling firm. That next doubling would mean C# would be used by 24% of the tech sector.
Read a little further, and usage is any sort of dabbling with the language. Most of those surveyed use C# for less than 20% of their work, and are in a kick-the-tires phase.
And this is news? C# has been in a kick-the-tires phase since it's release. Apocryphal stories about using C# for production development pop out every so often, but they remain apocryphal and very scattered.
--Nat
Re:We are
ziggy on 2002-05-07T16:36:22
What's an "apartment threaded DLL"?Sounds like you're undertaking a rewrite because the current implementation using the previous version of VB sucked due in large parts to VB. Presumably, VB.Net would be just as good as C#, except for the fact that the syntax blows.So we're switching everything to C#, rather than the new version of VB, because the developers are quite aware of VB's suckage.From what little I've read about it, shimming up the existing VB to be a VB.Net app shouldn't be too difficult (unless there are implemenation details tied to VB's current suckage). From there, doing a rote decompile from IL to C# should be straightforward.
If Microsoft is really serious about C# as the ultimate JavaKiller, then they must be facilitating this migration path (or just more focused on the marketing campaign than the technology).
Re:We are
Matts on 2002-05-07T21:37:46
What's an "apartment threaded DLL"?
Why would I care?;-)
Seriously, I think it basically means that it's single threaded, but it takes care of locking the DLL (and making clients wait) while other requests are taking place. At least thats the naive view of it I have from 10,000 feet. Perhaps someone else can describe it better (or look it up in MSDN for us).
Honestly I think the port is a mistake - I'm all for refactoring, but a complete re-write is a major undertaking. There's stuff we need to be able to support, which will require rewriting major chunks, but I can't imagine a need to do a ground-up rewrite of a 2 year old application. Refactoring is almost always going to be faster and more effective (especially in the sort of company I work for).
The main push for it is from the developers, who have learned C# in their downtime, and want to hone their skills on it. Either they are just curious (that's what management probably hope), or they're getting ready for when they have to jump ship;-) Re:We are
ziggy on 2002-05-08T03:33:42
That appears to be correct. It looks like a single-threaded hunk of code that lives in-process within a multithreaded application.I think it basically means that it's single threaded, but it takes care of locking the DLL (and making clients wait) while other requests are taking place.Wow. That sounds like a very stupid hack to add stability to a threaded application when you don't know how to write threadsafe code, but are using multiple threads because it's faster. Maybe synchronized methods in java really are too hard for your average basic junkie.
