[sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD?

Melinda Green melinda at superliminal.com
Sat Jun 13 11:08:01 PDT 2009


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


More information about the SLDev mailing list