Re: [ROOT] ROOT C# port

From: Brett Viren (bv@bnl.gov)
Date: Tue Apr 09 2002 - 19:45:33 MEST


I see.  

Some of these are valid improvements over the current state of ROOT,
although not necessarily C++ issues.  Some specific comments:

Joe Robe writes:
 > - no pointer shit which makes everyone mad who is not a professional
 > programmer
 > - no memory leaks

The reliance on and (imo) fuzzy conventions regarding heap object
ownership in ROOT could improve.  Passing by pointer should be avoided
as much as possible.

But, C++ allows one to avoid "new" in many situations and even mix
heap and stack objects in owning containers (witness libsigc++
manage() idiom).  Having a garbage collected language to avoid "new"
altogether is nice and has been done in numerous places in the past
(scheme, other lisps and C + libgc come to mind).  But this may be too
slow in some situations (think track/shower fitters in high rate,
multi event detectors).

 > - no dll, regsvr32 etc shit anymore

I have no idea what this means, but it sounds Windowsy so I aggree
with the epithet.

 > - TRUE ype safety

Yes, this is a major criticism I have with ROOT, specifically Rt and
the use of CINT in compiled code.  However, C++ is a very strongly
typed langage, so I don't see how reimplementing ROOT in C# would be
any different in this area.

 > - superb OOP support with even integer beeing an object

It may be my ignorance, but I am not sure I see the benefit of
fundamental types being objects.

 > - all what you need BASIC types (strings, collections etc.)

C++ has the STL.  ROOT's use of its own collection classes is often
criticized and well understood by the fact that its development
started before the STL was standardized.  Porting ROOT to C# wouldn't
necessarily remove TString, TList, etc.

 > - no dictionary files

Again, an aspect of ROOT, not the implmentation language.  Although, I
aggree with your implied point that having a truly reflective language
would solve a lot of problems, particularly in the area of I/O.
However, I think this state of affairs can be cleaned up by either
making CINT understand all of C++ or at least arbitrary templates
(both are maybe impossible) or switching to OpenC++ to provide ROOT
with its necessary meta programming.

 > - superb integrated GUI development, no need for moc files etc.

moc is part of Qt, not C++ nor ROOT (although, of course CINT plays
the role of moc in ROOT if you use Rt, I/O or other services needing
ROOT's meta programming protocol, but see above).  ROOT's GUI library
leaves much to be desired and I personally have railed against it time
and time again, but switching implementation language doesn't
necessarily mean any improvement, it just means the TG classes will
now be implemented in C# instead of C++.  Using native C# GUI would
mean following in the footsteps of QtRoot (that is Bertini's not
Fine's) and may indeed be worthwhile.

 > - object oriented database module build in

Does RDBC not fit this bill?

 > - true oop acces to file 

Not sure what "true oop access" means, but: TFile/TTree?

 > and security system 

I'm not sure I understand what this means exactly.

 > AND to the compiler (try do
 > this with CINT !)

I guess you refer again to built in language reflection, which I again
agree would be nice.

 > - security settings on exe level (well I guess UNIX had that before, but not
 > windoze)

Security settings is an OS issue, not an implementation language
issue.  Putting it into the language is another example of MS lack of
the use of even monkey brains in their designs.

 > It would be nice if the developers at root would think in USER terms and not
 > only in developer terms :) Ask any root user how much time they spend
 > developing and debugging code in comparison to do their ACTUAL work! 

The ROOT team has shown many times in the past just how driven they
are by user desires, often with sub-day turnarounds of requested
features.

However, I do agree that I spend quite a lot of time, particularly in
the area of the GUI (although, since my product is an event display,
much of the entire work is in this area) debugging and understanding
ROOT.  Unfortunately, the ROOT GUI is in a cross roads state of being
just good enough that replacing it has a high work/benefit ratio but
using it has a high pain/pleasure ratio.

However:

 > C# and
 > .NET is about PRODUCTIVITY, I cant wait to go back to my REAL work instead
 > of debugging root/qt and whatever problems.

I still don't see the use of C# over C++ will help any of these
problems except for maybe the reduction of (explicitly) heap allocated
objects and your implied suggestion that making use of C#'s built in
reflection instead of CINT's bolt on one could be useful.  While, at
the same time will introduce other problems, largely being lack of
availability, afordability, standardization.  As well as lack of track
record but an abundance of a bad track record for its primary
developer (MS).

All that said, I would applaud anyone who attempts to port ROOT to C#
(what ever that indeed means), just as I applauded those who developed
IP over carrier pigeon protocol.  But, I think it is disingenuous to
expect the ROOT team to do much to further this idea.

Warmest regards,
-Brett.



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:48 MET