Pourquoi choisir tel ou tel compilateur pour réaliser une application ?

Delphi, Visual Basic, C++, FoxPro, PowerBuilder. La liste est longue.
Les éditeurs de logiciels rivalisent d’arguments pour vanter la simplicité et la puissance des produits qu’ils proposent. Les forums informatiques se font l’écho de remarques plus ou moins flatteuses (ou plus ou moins critiques) à l’égard de tel ou tel produit.
Alors y a-t-il de bons et de mauvais produits ?

Je suis consultant indépendant. J’interviens sur Delphi, Visual Basic, et Foxpro. J’anime sur ces deux derniers des réunions de formation. Mes missions s’effectuent chez le client en équipe avec ses propres collaborateurs.
Il m’a semblé intéressant de marquer un temps dans les développements et de réfléchir à ce qu’apporte véritablement chacun de ces outils. Mon but n’est pas de dresser ici un tableau comparatif des fonctionnalités de chacun mais plutôt de les replacer par rapport au besoin final et au contexte commercial.

Autant de projets, autant de personnages
L’entretien avait duré une demi-heure avec le responsable du service ‘Immobilier’. Il supervisait une quinzaine de rédacteurs et de négociateurs.
Pour l’instant il était debout près de l’ordinateur d’une secrétaire et me regardait en souriant comme ‘un qui va en raconter une bien bonne’.

– Ce que je vais vous montrer Monsieur m’a demandé des semaines de travail. Des soirées entières. Visual Basic est un produit très facile, très souple et j’en ai tiré le meilleur parti. Ainsi j’ai défini mes variables au fil de l’eau, à chaque fois que j’en avais besoin. J’ai défini une option ‘Implicit’ et voilà. Vous connaissez l’option Implicit ?

– Oui mais ce n’est pas très rigoureux comme méthode.

– Ca c’est votre problème. Si cela ne vous plaît pas vous modifierez. Mais ce que j’ai fait fonctionne parfaitement.

Il cliqua sur une icône et un message d’erreur barra l’écran : Fatal error. File Not found.
Pour le coup il s’assit en maugréant.

– Evidemment ils ne sont pas techniciens. Ils cassent tout.

Finalement le logiciel se lança. C’était des écrans avec des objets énormes de toutes les couleurs. Régulièrement des messages conversationnels apparaissaient et simulaient un dialogue avec l’utilisateur : C’est parfait ! Etes-vous sûr(e) de ce chiffre ? Alors bravo !

La mission dura trois mois. J’ai synthétisé en un seul écran une vingtaine de petits formulaires plus ou moins semblables. Surtout j’ai structuré le code pour aboutir à une réécriture quasi complète. Pourtant une chose était certaine : le logiciel renfermait au niveau des formules de calcul et des algorithmes un savoir-faire et une connaissance parfaite du métier de l’immobilier.

Le métier de consultant est riche de contrastes. J’ai déjeuné l’autre jour avec un spécialiste Delphi. Le repas durant il me décrivit la puissance de l’architecture objet qu’il avait mise en place.
De temps à autre, pour limiter sans doute le côté doctoral (ou simplement pour faire jeune) il émaillait d’abrégés ou de mots d’argot.

– Nous avons pensé une architecture trois tiers. Bien sûr je me suis attaché au polymorphisme. J’ai fait la démo avant la mise en dév. Ils étaient cassés les mecs.

– Et le logiciel ? Quelle est sa fonction ?

– Des suivis de tab financiers. Du moins je crois…

Ce qui résulte de ces deux anecdotes c’est que la valeur de chaque logiciel va être fonction de sa capacité à répondre à la fois aux attentes d’un super technicien et en même temps à la faculté d’adaptation d’un homme de terrain.

[pagebreak]

Les IHM : Interfaces Homme-Machine
J’ai connu la micro informatique au début des années 80. A cette époque l’écriture de plusieurs dizaines de lignes de code étaient nécessaire avant d’afficher le moindre écran. Qui ne disposait pas de suffisamment de connaissances ne voyait donc jamais son logiciel se lancer.

Aujourd’hui nous disposons de RAD (Rapid Application Development). Delphi, Visual Basic, FoxPro, PowerBuilder etc… sont des RAD. Quelques clics de souris et le futur écran s’affiche déjà.
Encore quelques lignes de code (parfois grapillées sur Internet) et cela fonctionne tant bien que mal.

La palette des objets graphiques permettant la réalisation des écrans diffère très peu d’un environnement Delphi à un environnement Visual Basic.
Outre les classiques Libellés ou Champs de saisie les objets de Liste, Listes déroulantes (combobox)  sont quasiment identiques. Les objets de grille sont aussi en standard.

Bien sûr il existe des variantes : Visual FoxPro propose par exemple des Listes déroulantes à plusieurs colonnes.
Cependant globalement pour l’utilisateur final la convivialité du logiciel qui sera livré sera identique quel que soit l’outil employé pour son développement et l’on peut même parvenir au prix d’un peu de peine à ce qu’il ne sache même pas ce qui a été utilisé.

Les choses seront peut-être différentes pour le concepteur.
Visual Basic par exemple permet en valorisant à True la propriété multiline d’un champ de saisie de gérer la saisie d’un texte libre sans imposer comme Delphi ou Fox le remplacement par un objet spécifique.

Le fait d’enfermer dans un cadre graphique plusieurs objets attachés à une même fonctionnalité (les éléments d’une adresse par exemple) n’auront sur Delphi ou Visual Basic aucune incidence sur le code informatique.
Ce sera différent pour FoxPro car chaque élément aura alors le cadre pour parent et non plus l’écran lui-même.

Plus importante est la notion de classe pour la réalisation d’objets métier. Sous Visual Basic il va s’agir d’ActiveX. Ce sont des éléments autonomes que l’on place le plus souvent dans le répertoire Windows et que l’on inscrit en base de registre. Un même ActiveX peut être appelé par différents logiciels.
Sous FoxPro sous le nom de Classe depuis sa version 3 en 1995 et sous Delphi sous le nom de Cadre depuis sa version 5 trois ans après ces éléments son inclus dans le projet lui même.
Cela présente deux avantages : tout tient dans l’exécutable livré à l’utilisateur final. Oubliées les copies dans le répertoire de Windows et l’inscription en base de registre.
Surtout le programmeur qui utilise un objet de Cadre ou de Classe peut, dans son projet, en modifier la présentation en déplaçant les objets qui le composent, en neutralisant certains évènements.

Enfin autre aspect déterminant pour le concepteur : l’assistance du compilateur.
Quasiment inexistante sous FoxPro qui se contente de modifier la couleur des mots réservés elle consiste sous Delphi ou Visual Basic à proposer d’emblée, dès la saisie du point après un nom d‘objet, l’ensemble de ses propriétés et de ses méthodes.
Visual Basic pousse même jusqu’à la rectification de la casse des mots réservés et des noms de variables.
Il est ainsi possible de limiter au maximum les erreurs liées à la compilation. Le débutant (ou l’informaticien confirmé en panne de mémoire) voit s’afficher, dès la saisie du nom d’une fonction la liste des paramètres qui lui sont nécessaires. La règle vaut aussi pour les fonctions et les procédures du projet lui-même.
Le debuggage diffère sensiblement d’un environnement à l’autre.
Lorsque l’on s’est lassé des messages de Delphi indiquant que l’optimisation du code ne permet pas l’affichage de certains espions on apprécie à sa juste valeur celui de Visual Basic. Sa souplesse va jusqu’à permettre la modification du code pendant l’analyse et de déplacer l’indicateur de ligne de traitement en cours. Ainsi en cas d’erreur, une fois la correction apportée, l’exécution est reprise à l’endroit même de l’interruption ou quelques lignes plus en amont. Cette fonctionnalité représente des heures d’économie sur le global de temps de développement d’un projet.

[pagebreak]
La connexion aux données
La grande majorité des outils de développement est prévue pour fonctionner dans un contexte de client-serveur et se connecter à une base de données comme Oracle ou SQL Serveur.
Même Access ou FoxPro qui disposent de leur propre moteur de données sont dotés de ces moyens d’interface : ADO (Access Data Object) pour Visual Basic ou Access, ADO ou DB-Express pour Delphi, SqlConnect pour FoxPro.
Ces environnements proposent en outre des moyens d’exploiter au mieux les sélections d’enregistrements qui ont été effectuées : déplacement dans le jeu d’enregistrements, localisation, mise à jour, etc…

En synthèse donc ni l’interface graphique ni la connexion aux données ne peuvent constituer un argument valable pour retenir tel ou tel outil de développement.
Il s’agit pourtant d’un aspect essentiel mais le choix se situera à un autre niveau : formation ? déploiement ?

Le déploiement d’une application
Windows a révolu le temps ou la livraison d’un logiciel se limitait à la copie de quelques fichiers que l’on apportait sur une disquette. Le CD Rom est devenu désormais l’unité de valeur.

Parallèlement à l’exécutable lui-même est jointe une série de fichiers qui va en permettre le fonctionnement.
C’est à ce niveau que vont se situer les principales différences :

– Sous Delphi
L’exécutable est autonome. Il est sensiblement plus volumineux que pour d’autres environnements. Les DLL ne seront nécessaires que pour l’accès aux données.
Ainsi un programme qui ne gérerait pas d’autres données que des fichiers (ASCII ou propriétaires) se limiterait à un simple EXE.
Le fait de connecter une base de données va nécessiter l’ajout de plusieurs DLL dont la nature sera fonction du moteur employé.

– Sous FOX
L’exécutable bien que suffixé .EXE n’est pas autonome et nécessite un runtime. C’est ce qui justifie la liste des fichiers jointe lors de la génération du kit de déploiement.

– Sous Visual Basic
C’est la pire situation. L’exécutable n’est pas autonome et il nécessite en outre d’y joindre les ActiveX qui auront pu être ajoutés à la version standard (grilles, champs formatés, calendriers).
L’emploi d’une base de données, que ce soit Access ou Oracle implique la diffusion de MDAC.exe, compression de plusieurs drivers et qui pèse environ six MO.

Le kit de déploiement peut être réalisé à partir d’utilitaires vendus dans le commerce. Chaque éditeur propose avec sa version de compilateur un outil permettant la construction du kit.
Delphi utilise une version allégée d’InstallShield. VB et FoxPro utilisent des outils propriétaires.

A ce niveau on comprend que le choix d’un outil de développement présente plusieurs implications.
Le fait de copier des ActiveX et des DLL dans le répertoire de Windows et de les inscrire parallèlement en base de registre est indispensable pour assurer le fonctionnement du logiciel que l’on est en train d’installer mais n’est peut-être pas sans effet sur des applications existantes.
Cela est sous entendu dans le message diffusé lors de l’installation : un fichier plus récent a été trouvé sur le disque. Voulez-vous le remplacer ?.
Certaines sociétés disposant d’un parc important d’ordinateurs pré-installent les composants.
Le développeur intervenant sous Visual Basic dispose d’une liste de composants répertoriés qu’il peut utiliser. L’installation de son logiciel se limite aux quelques fichiers qu’il a réalisés.

Voici comment nous avons traité le problème sur un site fonctionnant sous Visual Basic et pour lequel nous devions disposer d’un outil pour envoyer des mails.
Nous avons créé avec Delphi un petit programme avec le composant SMTP. Le programme reçoit en paramètre tout ce qui est nécessaire au composant et place les informations reçues dans ses propriétés.
La livraison inclut un exécutable qui est ensuite  appelé avec un ordre Shell :

CCommande = ‘’MD_Internet.exe ‘’
CCommande =  CCommande + ‘’MAIL « 
CCommande =  CCommande + ‘’smtp.wanadoo.fr-‘’
CCommande =  CCommande + cMailDestin + ‘’-‘’
CCommande =  CCommande + cNomDestin + ‘’-‘’
CCommande =  CCommande + cFichierJoint + ‘’-‘’
CCommande =  CCommande + cTexte + ‘’-‘’
CCommande =  CCommande + cMailEmetteur + ‘’-‘’
Shell Ccommande

Une variante aurait été de compiler ce petit exécutable en un ActiveX ou une DLL mais le résultat aurait été sensiblement le même.
Les difficultés liées aux envois de mails avec Visual Basic (dans sa version 6 du moins) sont ainsi évitées mais le client dispose de toute la puissance d’Internet

[pagebreak]

Le niveau technique
C’est peut-être là que se situe la véritable différence.
J’ai choisi volontairement au début de cet article deux profils type. En fait beaucoup d’entre nous connaissent ce genre de situations et les intervenants dont elles dépendent. Ils savent comme moi que nous ne pouvons négliger ni un profil ni un autre.
Des langages comme Visual Basic sont très tolérants, Foxpro l’est encore plus. Delphi, directement issu du Pascal en a conservé toute sa rigueur et sa structure.
La notion des variables très (voire trop) souple d’un côté est donc intransigeante de l’autre.

 
Si l’on considère que le langage Pascal est issu de l’Université on comprend sa démarche pédagogique. On peut alors programmer en respectant ses règles de rigueur même dans des environnements de développement plus tolérants. Un code Visual Basic où chaque procédure ou chaque fonction commencera avec la déclaration des variables locales qui y sont employées gagnera en clarté et en réputation de l’auteur.
Toutefois un utilisateur ‘lambda’ peut se voir faciliter l’accès à un langage informatique et formuler son savoir-faire de façon plus concrète qu’un cahier de charge.
Une ligne
Update BASE_Clients
Set Clients_Type = ‘S’
Where Clients.CP Like ‘94%’

Est plus facilement exploitable que le littéral
‘Pour des raisons internes il faudra passer systématiquement à S le type de tous les clients du Val de Marne’

Deux conséquences découlent de cet état de fait
D’une part le coût. Un développeur Delphi est réputé plus ‘professionnel’ et acheté sur le marché plus cher que son équivalent en Visual Basic.
La règle est encore plus injuste quand on voit un développeur ACCESS (donc en fait un développeur Visual Basic) être payé au prix d’un utilisateur de bureautique.
L’impact budgétaire devient donc significatif dans la réalisation d’un projet dès que l’on varie d’un environnement à l’autre.

D’autre part la valeur de l’expérience. Un développeur Delphi étant plus recherché et mieux rémunéré que son équivalent en Visual Basic, cela engendre une attirance naturelle de beaucoup de jeunes informaticiens vers un outil qu’ils savent mieux considéré. Il suffit de consulter certains forum pour s’en convaincre.
C’est profondément injuste si l’on considère que la valeur d’un logiciel tient plus à sa fonctionnalité et à son ergonomie qu’à la pureté de son style d’écriture mais le marché est ainsi fait.

Parallèlement à mes missions je réalise en interne certains logiciels qui sont ensuite exploités notamment en gestion de fichier. Ils me servent aussi de vitrine et j’écarte d’emblée des compilateurs que pourtant j’apprécie parce que je les sais moins reconnus. Certaines Sociétés font de même au même titre qu’Oracle sera plus côté que SQL Serveur, SQL Serveur plus que FOXPRO et FOXPRO plus qu’ACCESS. Pourtant pour des bases de données petites ou moyennes aucun de ces outils ne démérite.

La conclusion tient donc au fait que l’on dispose actuellement sur le marché de produits complémentaires. Les uns d’approche très simple mais qui se révèlent plus lourds à déployer et moins rigoureux.
Les autres d’un abord moins intuitif mais qui fournissent un ensemble technique plus cohérent.

Chacun trouve sa place. Des non-informaticiens ont ainsi accès à des outils leur permettant de concrétiser leur métier et leur savoir-faire dans des logiciels ‘maison’. Des techniciens peuvent à leur tour produire des logiciels structurés et robustes en utilisant en point de départ ce que les premiers leur proposent.
Visual Basic aidera les premiers. Delphi donnera aux seconds le moyen d’un produit fini et professionnel.

Une alternance aurait été une interface de programmation capable de produire en sortie des codes informatiques différents. Ce produit a existé et s’est appelé NSDK puis NatStar. Il permet de produire indifféremment du code C, Cobol ou Pascal.
Il n’a malheureusement pas connu le succès qu’il méritait.

Visual Basic jusqu’alors reconnu pour sa simplicité connaît avec sa version .Net un tournant définitif vers des horizons nettement moins évidents.

Faut-il alors considérer comme terminée l’époque où des non-techniciens pouvaient réaliser leurs propres outils et  la micro informatique, de moins en moins micro, va-t-elle impliquer un alourdissement des connaissances comme elle a déjà entraîné celui de nos disques durs ?