Au debut j'aimais bien ROOT. C'etait fun, tu penses bien, apres avoir programme en FORTRAN et en KUMACs (langage de script pour PAW, le papa de ROOT), jouer avec le C++ c'etait bien (TM).
Le probleme c'est que ROOT a ete ecrit au debut par l'auteur (R. Brun) de PAW. Comme aux debuts de tout programmeur dans un nouveau langage, la premiere version merite toujours un rm -rf bien senti.
Cependant, cette reorganisation de ROOT n'a pas ete menee.
Du coup on se traine des methodes de programmation qui datent des annees 90 avec un arriere gout Fortraneux des plus desagreable ainsi qu'un design des classes relativement discutable.
D'ailleurs une multitude de choix sont discutable.
Tout d'abord, laisser a un physicien ecrire des macros C++ pour l'interpreteur (CINT) est une grosse boulette. Le profil type du physicien qui va utiliser ces macros est le nouveau switcher depuis FORTRAN/PAW. A force d'essayer de lui faciliter la transition (ce qui est une attention louable en soi) on lui donne de mauvaises habitudes (on peut ecrire des horreurs qui piquent les yeux avec cet interpreteur! du genre double hyp = a**2+b**2;).
Personnellement, je n'utilise jamais cet interpreteur : je prefere de loin utiliser le prompt de python et charger les objets ROOT qui m'interessent.
Avec ROOT 5, on commence a avoir un support a peu pret correct de la STL.
Cependant, dans la majeur partie des cas (remplissage de tuples par exemple) il faut toujours passer par des tableaux "a la C", je pense que la perte de performances (combien d'ailleurs?) ou l'overhead induit par les conteneurs de la STL sont un compromis plutot honnete par rapport au gain en "sûreté"!
Design objet : ben, oui parce que ROOT ca veut dire "the Root of all Objects : an object oriented data analysis framework".
Le probleme ici c'est que certains choix de l'arbre d'heritage me laissent dubitatif : est-ce qu'un histogramme 2D est vraiment une specialisation d'un histogramme 1D ? Ou dit autrement, est-ce qu'un cercle est vraiment une sorte d'ellipse[1] ?
Un autre gros probleme : la separation du stockage des donnees et de leur representation. Dans le cas general, ca n'existe pas. L'objet servant a representer les donnees, contient egalement ces memes donnees. Du coup on est un peu gene aux entournures.
Ex: si je veux etre absolument sur que les donnees de mon histogramme ne seront jamais modifiees, je vais mettre mon histo const. Mais alors je ne pourrai pas changer le style de mes points ou la couleur des barres de d'histogramme !
On se retrouve alors a faire des copies d'histogrammes completement superflues !
Corrollaire: la constness de ROOT est une notion vaguement saupoudree dans les classes.
Et le grand final : les options que l'on peut passer aux objets.
C'est simple, tout se fait avec des chaines de caracteres : histo->Draw("b,s,p");
Detail : ces options ne sont pas documentees (ou tres mal : use the source Luke!)
Bref, mon avis personnel est que ROOT est une usine a gaz dont le design complet est a revoir, meme s'il faut reconnaitre que les bibliotheques mathematiques n'ont pas a rougir face a GSL.
Des solutions comme HippoDraw[2] ou AIDA[3] me semblent avoir des bases plus solides et reposer sur des concepts plus robustes pour faire ce qu'on leur demande de faire.
Heureusement qu'il y a PyROOT pour faire passer la pillule.
# ROOT c'etait mieux a vent
Posté par Sebastien . En réponse à la dépêche ROOT 5.04 passe en LGPL. Évalué à 10.
Au debut j'aimais bien ROOT. C'etait fun, tu penses bien, apres avoir programme en FORTRAN et en KUMACs (langage de script pour PAW, le papa de ROOT), jouer avec le C++ c'etait bien (TM).
Le probleme c'est que ROOT a ete ecrit au debut par l'auteur (R. Brun) de PAW. Comme aux debuts de tout programmeur dans un nouveau langage, la premiere version merite toujours un rm -rf bien senti.
Cependant, cette reorganisation de ROOT n'a pas ete menee.
Du coup on se traine des methodes de programmation qui datent des annees 90 avec un arriere gout Fortraneux des plus desagreable ainsi qu'un design des classes relativement discutable.
D'ailleurs une multitude de choix sont discutable.
Tout d'abord, laisser a un physicien ecrire des macros C++ pour l'interpreteur (CINT) est une grosse boulette. Le profil type du physicien qui va utiliser ces macros est le nouveau switcher depuis FORTRAN/PAW. A force d'essayer de lui faciliter la transition (ce qui est une attention louable en soi) on lui donne de mauvaises habitudes (on peut ecrire des horreurs qui piquent les yeux avec cet interpreteur! du genre double hyp = a**2+b**2;).
Personnellement, je n'utilise jamais cet interpreteur : je prefere de loin utiliser le prompt de python et charger les objets ROOT qui m'interessent.
Avec ROOT 5, on commence a avoir un support a peu pret correct de la STL.
Cependant, dans la majeur partie des cas (remplissage de tuples par exemple) il faut toujours passer par des tableaux "a la C", je pense que la perte de performances (combien d'ailleurs?) ou l'overhead induit par les conteneurs de la STL sont un compromis plutot honnete par rapport au gain en "sûreté"!
Design objet : ben, oui parce que ROOT ca veut dire "the Root of all Objects : an object oriented data analysis framework".
Le probleme ici c'est que certains choix de l'arbre d'heritage me laissent dubitatif : est-ce qu'un histogramme 2D est vraiment une specialisation d'un histogramme 1D ? Ou dit autrement, est-ce qu'un cercle est vraiment une sorte d'ellipse[1] ?
Un autre gros probleme : la separation du stockage des donnees et de leur representation. Dans le cas general, ca n'existe pas. L'objet servant a representer les donnees, contient egalement ces memes donnees. Du coup on est un peu gene aux entournures.
Ex: si je veux etre absolument sur que les donnees de mon histogramme ne seront jamais modifiees, je vais mettre mon histo const. Mais alors je ne pourrai pas changer le style de mes points ou la couleur des barres de d'histogramme !
On se retrouve alors a faire des copies d'histogrammes completement superflues !
Corrollaire: la constness de ROOT est une notion vaguement saupoudree dans les classes.
Et le grand final : les options que l'on peut passer aux objets.
C'est simple, tout se fait avec des chaines de caracteres :
histo->Draw("b,s,p");
Detail : ces options ne sont pas documentees (ou tres mal : use the source Luke!)
Bref, mon avis personnel est que ROOT est une usine a gaz dont le design complet est a revoir, meme s'il faut reconnaitre que les bibliotheques mathematiques n'ont pas a rougir face a GSL.
Des solutions comme HippoDraw[2] ou AIDA[3] me semblent avoir des bases plus solides et reposer sur des concepts plus robustes pour faire ce qu'on leur demande de faire.
Heureusement qu'il y a PyROOT pour faire passer la pillule.
PS : il existe aussi un module Ruby pour ROOT
http://root.cern.ch/root/HowtoRuby.html(...) [En]
PS2: un site qui detaille un peu plus les faiblesses de ROOT
http://www.insectnation.org/howto/living-without-root(...) [En]
[1] http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-2(...) [En]
[2] http://www.slac.stanford.edu/grp/ek/hippodraw/index.html(...) [En]
[3] http://aida.freehep.org/index.thtml(...) [En]