[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