Vous pouvez vous dire “quelle mouche le pique ?” A quoi bon en effet perdre son temps à bricoler des fichiers XML issus du TClientDataSet de Delphi puisque Delphi n’est plus qu’un souvenir (malgré quelques sursauts du côté d’Embarcadero à 3500 euros HT pour la version 2010, faut en vouloir !) et que le XML produit par le TClientDataSet est une curiosité ? More...
J'avais prédis dans une ancienne interview donnée au Journal du Net que les "Delphistes seraient les cobolistes des années 2010" et s'il est vrai que faire du Delphi Win32 aujourd'hui n'a plus guère de sens, il restait au moins Delphi.NET. Hélas celui-ci aussi a fini par passer à la trappe (voir mon billet "Delphi Prism, la seconde mort de Delphi").
Borland voulait se recentrer sur les outils ALM. Une belle erreur qui a conduit au bradage de leurs outils de développement, les seuls produits intéressants chez Borland. Il ne leur restait donc plus grand chose à vendre. En 2008 la firme a perdu 200 millions de dollars, c'était prévisible.
Mais ma prédiction s'est révélée presque exacte à 6 mois près ! En effet, doucement, sans bruit (car hélas sans aucun intérêt de personne) Borland a été racheté en mai dernier par Micro Focus, les rois ... du Cobol !!!
Reste CodeGear/Embarcadero et la mise à poubelle de la VCL.NET et Delphi.NET au profit de Prism (en fait Chrome sous licence, voir le billet cité plus haut pour plus de détail).
Entre le Cobol ou la mort pure et simple, Borland n'en finit pas de mourir et de s'enfoncer dans la non-existence. Mais s'en est définitivement terminé. Enfin, aurait-on presque envie de dire.
Ça fait de la peine quand même, cette longue agonie. Pour un ex-borlander comme moi, j'aurais préféré une mort en beauté, soudaine, fauché en pleine gloire. Non, Nielsen, le PDG "génial" de l'annonce de la vente des EDI aura été le fossoyeur sadique du mythe Borland, sadique car en plus il n'a pas fait ça proprement.
Cela étant dit, Vive C#, Vive Silverlight (et toutes les technos .NET) et merci à Microsoft ne nous avoir offert un alternative crédible et séduisante au terrible dilemme de n'avoir comme autre choix la mort professionnelle avec Delphi ou de vraiment finir coboliste avec Borland ! :-)
J'en parle très rarement, vu le peu d'intérêt du sujet, mais l'ancien delphiste que je suis a toujours un oeil nostalgique sur Delphi. La mort de Delphi est arrivée avec l'annonce de la volonté de vendre l'EDI et le langage par Borland. L'époque était déjà trouble avant cette dernière d'où d'ailleurs mon bouquin en 2005 "De Delphi à C#" (que mon éditeur n'a hélas jamais voulu appeler comme ça malgré mon instance, mais plus banalement "delphi 2006 et c#").
Cette vente loupée et jamais réalisée qui s'est transformée en la création de l'écran de fumée "CodeGear" histoire de donner l'impression qu'il s'était passé quelque chose a réellement marqué la mort de Delphi. La vraie vente, trop tardive, à des inconnus du monde du développement (Embarcadero) n'a fait que confirmer que les carottes étaient cuites.
Mais Delphi n'était que moribond, dans un coma qui devenait de plus en plus profond et irréversible mais il y avait parfois quelques sursauts reflexes. Le coup de grâce vient d'être porté par Embarcadero qui a annoncé la fin de Delphi .NET, le seul produit intelligent (mais mal fini) des dernières années. La VCL.NET est morte dans la foulée (et tout le code développé autour).
Certes "Delphi Prism" est désormais en vente, mais il ne s'agit d'une part que d'un plugin Visual Studio et d'autre part ce n'est même pas un produit CodeGear ni Embarcadero mais une simple évolution du plugin Chrome de RemObjects, société qui reste indépendante, un simple partenaire de Embarcadero ce qui pose quand même problème en termes de maîtrise de la technologie par Embarcadero, ce qui entraîne de facto quelques doutes sur l'avenir du produit, de ses évolutions et du code qui sera produit avec.
Pendant très longtemps, en tant que partenaire Borland, j'ai insisté pour que Delphi.NET soit un plugin VS et que l'EDI "BDS" soit abandonné vu l'impossibilité de le mettre au point. Idée rejetée pendant des années. Pour finalement y venir mais trop tard pour sauver le produit. Delphi Prism n'est certainemenett pas un mauvais produit, au moins avec VS comme EDI on est sûr que l'environnement de développement est de bonne qualité ! De plus, j'ai été dans les premiers à dire du bien de Chrome en affirmant que c'était la voie à suivre pour Delphi.NET. J'ai été exhaussé, mais trop tard, et au pied de la lettre... Une tragédie grecque !
Delphi.NET, seul produit d'avenir qui aurait pu sauver le langage est donc enterré, avec ces quelques fidèles et leur code VCL.NET qu'ils peuvent mettre à la poubelle.
Je suis à la fois bien triste, on n'efface pas son passé comme on reformate un disque dur, et en même temps bien heureux d'avoir dès 2005 recommandé à tous mes lecteurs et à mes clients d'abandonner définitivement Delphi pour Visual Studio et C#. Bien malins et surtout aujourd'hui serins ceux qui m'ont écouté !
La page se tourne définitivement.
Vive C# !
Il y a bien fort peu de chose qui puisse faire regretter un delphiste d'être passé à C#, et quand je parle de regrets, c'est un mot bien fort, disons plus modestement des manques agaçants.
Rien qui puisse faire réellement pencher la balance au point de revenir à Delphi, non, ce langage est bel et bien mort, assassiné par Borland/Inprise/Borland/CodeGear et son dernier big boss, tod nielsen qui ne mérite pas même les majuscules à son nom mais là n'est pas la question.
Donc il existe syntaxiquement trois choses qui peuvent agacer le delphiste, même, comme moi, quand cela fait au moins cinq ans maintenant que je ne pratique presque plus que C# (et un peu de Delphi pour maintenir des vieilleries et aider certains clients à tourner la page en migrant sous C#).
La première qui revient à longueur de code, ce sont ces satanés parenthèses dans les "if". On n'arrête pas de revenir en arrière parce qu'on rajoute un test dans le "if" et qu'il faut remettre tout ça entre de nouvelles parenthèses qui repartent depuis le début. Certes on gagne l'économie du "then" pascalien, mais que ces parenthèses du "if" sont épouvantables et ralentissent la frappe bien plus qu'un "then" unique et ponctuel qu'on ne touche plus une fois écrit même si on rajoute "and machin=truc" ! A cela pas d'astuce ni truc. Et aucun espoir que les parenthèses de C# dans les "if" soient abandonnées un jour pour revenir au "then" ... Donc faut faire avec ! Le dogme "java/C++" est bien trop fort (quoi que C# possède le Goto de Delphi, ce qui n'est pas la meilleure idée du langage :-) ).
La seconde tracacerie syntaxique est cette limitation totalement déroutante des indexeurs : un seul par classe et il ne porte pas de nom. this[], un point c'est tout. Je sais pas ce que notre bon Hejlsberg avait en tête, mais pourquoi diable n'a-t-il repris de Delphi qu'un seul indexeur et non pas la feature entière ? Il fait beaucoup de recherche, et le fait bien, mais je présume qu'il n'a jamais plus codé un "vraie" appli depuis des lustres... Car dans la vraie vie, il existe plein de situations où un objet est composé de plus d'une collections. Une voiture a 4 roues et 2 ou 4 portières. Pourquoi lorsque je modélise la classe Voiture je devrais donner plus d'importance aux roues qu'aux portières et choisir lesquelles auront le droit d'être l'unique indexeur de la classe ? Pourquoi tout simplement ne pas avoir Voiture.Roues[xx] et Voiture.Portières[yy] ? Mon incompréhension de ce choix très gênant dans plus d'un cas a été et reste des années après totale. Surtout après toutes les évolutions de C# sans que jamais cette erreur de conception ne soit corrigée. Pas suffisant pour faire oublier toute la puissance de C# et le bonheur qu'on a à travailler dans ce langage, mais quand même, ça agace.
Enfin, dans la même veine d'ailleurs, l'absence de "Set of" est cruelle. Pourquoi avec zappé cette feature de Delphi dans C# alors que bien d'autres ont été reprises (avec raison ou moins comme le Goto) ?
Mais là on peut trouver des astuces et certains (dont je fais partie) ont écrit ou essayer d'écrire des classes "SetOf" qui permettent de gérer des ensembles comme Delphi, mais que c'est lourd tout ce code au lieu d'écrire "variable machin : set of typeTruc" !
Autre astuce moins connue, et c'est pour ça que je vous la livre, est l'utilisation fine des Enums. En effet, tout comme sous Delphi, il est possible d'affecter des valeurs entières à chaque entrée d'une énumération. On peut donc déclarer "enum toto { item1 = 5, item2 = 28, item3 = 77 }".
Mais ce que l'on sait moins c'est que rien ne vous interdit d'utiliser des puissances de 2 explicitement car les Enums savent d'une part parser des chaînes séparées par des virgules et d'autre part savent reconnaître les valeurs entières cumulées.
Ainsi, avec enum Colors { rouge=1, vert=2, bleu=4, jaune=8 }; on peut déclarer :
Colors orange = (Colors)Enum.Parse(typeof(Colors),"rouge,jaune"); // étonnant non ?
La valeur de "orange" sera 9 qu'on pourra décomposer facilement, même par un simple Convert.ToInt64.
Pour ne pas réinventer la roue et éviter de faire des coquilles je reprends cet exemple tel que fourni dans la doc MS. Voici le code complet qui vous permettra, peut-être, d'oublier plus facilement "Set of" de Dephi...
Stay tuned!
Code de la doc MS :
using System;
public class ParseTest
{
[FlagsAttribute]
enum Colors { Red = 1, Green = 2, Blue = 4, Yellow = 8 };
public static void Main()
{
Console.WriteLine("The entries of the Colors Enum are:");
foreach (string colorName in Enum.GetNames(typeof(Colors)))
{
Console.WriteLine("{0}={1}", colorName,
Convert.ToInt32(Enum.Parse(typeof(Colors), colorName)));
}
Console.WriteLine();
Colors myOrange = (Colors)Enum.Parse(typeof(Colors), "Red, Yellow");
Console.WriteLine("The myOrange value {1} has the combined entries of {0}",
myOrange, Convert.ToInt64(myOrange));
}
}
/*
This code example produces the following results:
The entries of the Colors Enum are:
Red=1
Green=2
Blue=4
Yellow=8
The myOrange value 9 has the combined entries of Red, Yellow
*/