Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dzonatas Sol wrote: > >> Melinda Green wrote: >> >>> If you think things are complicated now, just wait until we start >>> leaning heavily on multithreading to spread the load! >>> >> Sounds like a good time to move UI implementation from C++ and go C#. >> It'll make it that much less complicated. >> > > I am sorry, but you honestly do not know what you are talking about. How > are threading problems somehow less complex in C#? Race conditions and > deadlocks do not magically go away.
I agree with Dzonatas that there's no reason to be insulting here. I won't say any more about that and will just deal with your question which is fair and which will make me reevaluate my opinions on the subject. First off, I'm a C++-turned-Java/Swing programmer and have never compiled a line of C# in my life. My understanding of C# is that it's a blatent, near identical copy of Java that happened because Sun screwed up by leaving Microsoft the legal option to do that. Because they'd gotten away with it, Microsoft didn't need to worry about trying to make C# look terribly different from Java, so they're basically the same language with similar standard services. So when I think about threading issues in Java, I find that I have the confidence to tackle many more tricky new threading issues than I ever would except to succeed with using C++. It's just so much easier pushing code around while feeling around for the most maintainable, scalable designs. Dealing with threading issues in Java feels more like a walk in the park compared to performing a high-wire act without a net. Sure, you can get good at these dangerous activities, but I see no need to bother when there are safer alternatives. Solving existing threading problems won't be any easier unless the code in question can be translated into C# first (which I do not recommend). On the other hand, new code which could benefit from being run asynchronously would be easier to write, test, debug and manage than the same C++ code would be. In my experience, I can consistently get four times as much finished, productive code in Java than I can in the same amount of time with C++. The lightning compile/link times completely changes the way that you develop code when your previously long long compile, edit, test, debug. cycle time suddenly drops to nothing. I have the same expectations from other interpreted languages such as Python. I know very little about Python but I feel it could be yet another language the GUI could be implemented in. This might look like an attractive option for many existing Linden developers who are already using Python for other critical components. Interpreted languages just rock. The C++ true-believers have two strong cards they like to play. The first is that the viewer is already in C++ and it just simplifies things if there is only one compiler involved. That argument carries some real weight. For better or worse, to introduce another language into the viewer we would need to get the legacy code to talk to code in another language. That weight definitely goes on the side of the scale that wants to keep everything in C++. But with a growing number of Python programmers in the ranks, they'd probably assess that weight as not terribly heavy. The second strong card they'll play is that there are certain situations in which performance is critical, and you can't get nearly the performance needed from a compiled language from an interpreted one. My answer is that sometimes you underestimate just how fast the object code produced by just-in-time compilers can be. The Java JIT compiler writes C++ versions of the Java logic for methods which it then compiles using the C++ compiler, so in the end the machine is running mostly native code produced by the java code. So the speed cost of Java/C# may surprise some people, and even in the worse case where some expensive inner loop really needs to be coded directly in C++ and maybe a little assembly code, that's fine. Coding those critical components in C++ would be using the right tool for the job. They're just an extremely rare case since that sort of code nearly always represents less than 5% of the code. Sometimes much less. My basic argument is that for the other 95% of the code, C++ is the *wrong* tool for the job. -Melinda _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
