Bible Parser a maintenant plus de dix ans d’existence et n’a cessé de se perfectionner tous azimuts. Il souffre néanmoins de plusieurs inconvénients persistants, qui rendent sa réécriture nécessaire. D’abord, il se fonde sur un antique environnement de développement, Visual Basic 6, qui n’a plus cours depuis 2008 (apparition d’une évolution majeure : .NET). Cet environnement est désormais obsolète, produit des interfaces archaïques, et surtout pose le problème infernal des composants partagés, qu’on qualifie à juste titre de DLL Hell, « l’enfer des DLL » (cf. l’explication officielle de Microsoft sur MSDN). C’est un défaut qui apparaît surtout sur certains systèmes récents, et c’est peu dire que c’est agaçant. Ensuite, Bible Parser a été codé au fur et à mesure du temps sans vision d’ensemble, ni, au départ, de logique propre. Ainsi, son code présente certaines redondances qui pourraient facilement être optimisées. Pour faire court, je privilégiais davantage à mes débuts le « ça fonctionne !!! » au plus sobre et pragmatique « ça fonctionne et c’est joli ». Enfin, Bible Parser n’est pas multi-plateformes, c’est-à-dire que son environnement natif est Windows – il ne tourne donc sous Mac et Linux qu’indirectement (Parallels Desktop/Bootcamp ou Wine).
Pour toutes ces raisons, et d’autres encore qu’il serait fastidieux de détailler ici, Bible Parser sera réécrit totalement. Mais l’affaire n’est pas mince. Il n’est pas évident de faire table rase de 10 ans d’habitudes (parfois mauvaises) de programmation, ni de se lancer dans un nouveau projet dont on connaît l’ampleur, à plus forte raison quand des fonctions élémentaires (ou plus précisément, « de base ») devront, comme le reste, être réécrites (navigation, liste des corpus, système de conversion en Unicode, en HTML). Il y a un côté extrêmement créatif et excitant à programmer, et puis il y a un côté foncièrement rébarbatif et formel. Plus on réfléchit en amont, plus on anticipe, et mieux c’est. En ce sens, j’admire un bon programmeur autant qu’un écrivain talentueux.
Quand on sait que Bible Parser présente, si l’on exclut les modules et les fichiers de ses répertoires « tools », « lex », « ref », « install » et « modules », plus de 12 500 éléments (essentiellement des fichiers objet, .OBJ et des fonctions .BAS), on comprend la réticence que j’ai à me lancer (et si on ajoute les autres répertoires, le total excède les 75 000 fichiers) … Pour vous donner une idée, Bible Parser se compose de plus de 122 000 lignes de code, qu’on peut faire tenir dans un ouvrage de 2375 pages – à condition bien sûr d’écrire tout petit… Encore que ces chiffres ne rendent pas compte du texte saisi dans les différents composants eux-mêmes, ainsi que leurs propriétés parfois nombreuses…
Vous conviendrez donc qu’il faut une forte motivation pour repartir de zéro.
Initialement je prévoyais de livrer une première version au premier semestre 2014, c’est-à-dire fin juin – début juillet. Et déjà j’entrevoyais que cette première version (au nom de code évocateur « Phénix ») serait, en termes de fonctionnalités, encore bien loin de l’actuelle version 2013 – quoique représentative de la « nouvelle donne ». D’autres obligations, et une réflexion de fond, m’ont cependant détourné de la tâche. Mais le temps de la réflexion est terminé, et la décision est prise : Bible Parser va bel et bien être réécrit ab ovo. Il ne sortira sans doute pas avant l’année prochaine – en l’état, j’ai encore du mal à estimer le temps qui sera nécessaire pour le rendre présentable. La ligne directrice du projet est la suivante : moins, mais mieux. C’est-à-dire se concentrer sur l’essentiel : la consultation et l’analyse du texte biblique dans les langues originales. C’est déjà beaucoup. Mais cela va écarter quelques fonctions « gadget » qui polluent plus qu’elles ne servent.
Les axes de travail sont les suivants :
1- interface visuelle et intuitive,
2- logiciel modulable et personnalisable,
3- environnement multi-plateformes,
4- installation simple,
5- prise en main intégrée,
6- rapidité,
7- originalité, efficacité.
1 : je rappelle que je ne suis pas programmeur professionnel, mais simple amateur, dilettante de surcroît. Je ne peux me payer le luxe d’apprendre d’autres langages de programmation que VB et sa famille élargie. L’interface sera donc plus moderne, mais sans verser dans ce que j’appellerais le « post-moderne »… avec par exemple des animations ou effets tape à l’œil. L’idéal serait de se passer totalement des menus (cf. Glo Bible). Ce vers quoi je m’achemine sera vraisemblablement plus orienté par une sélection facile du corpus à consulter (auto-complétion ou visuels).
2 : à chaque étape du développement, la modularité sera mise en avant. Autrement dit, chaque portion de code devra être le plus générique possible, pour être réutilisée ad libitum : ainsi la consultation des versions bibliques, le système de concordance, les définitions, l’analyse morphologique, les requêtes, devront être pensées pour toutes les situations présentes et à venir. J’ai trop souvent dû créer des modules supplémentaires pour ajouter un corpus, ou la concordance d’un corpus… Ce que je vise dans l’idéal, c’est qu’un utilisateur puisse ajouter son propre corpus, et bénéficier de toutes les fonctionnalités associées. En vérité, ce n’est pas très difficile, mais cela suppose une bonne dose de rigueur méthodologique au moment de la conception initiale du module.
3 : c’est un des points phare, et cependant ce n’est pas encore gagné. Le sondage ci-dessus permettra d’orienter cet axe. Beaucoup d’utilisateurs Mac ou Linux m’ont sollicité au fil des années. Je tiens désormais une vraie piste pour satisfaire cette demande. Peut-être pas encore pour les e-devices, type smartphones ou tablettes, mais il est possible de compiler un code unique pour Windows, Mac et Linux avec Xojo. Or Xojo est un héritier de Visual Basic 6, présente des atouts majeurs comme sa simplicité de prise en mains, et surtout compile pour les trois environnements (et qui sait, prochainement, pour iOS…). Problème : la communauté des programmeurs est réduite (250 000 développeurs dans le monde paraît-il), la documentation assez chiche à mon goût, et il est difficile de prévoir si l’environnement continuera d’être mis à jour au fil du temps. Xojo s’appelait précédemment REALbasic, et cela fait en fait des années que je lorgne dessus… J’ai lu attentivement l’ouvrage de J. Lee Ford (2006), mais il est beaucoup trop basique. Il me reste ceux de Choate, Tejkowski ou Neuburg, mais je crains que ce ne soit insuffisant. Il n’existe pas encore d’ouvrage édité consacré à Xojo. Or, malgré la qualité de la documentation en ligne, on reste un peu sur sa faim. En cas de difficulté spécifique, on risque donc d’être un peu seul… ce qui n’arriverait jamais dans un environnement comme .NET. Mais les qualités intrinsèques de Xojo sont telles que je suis à deux doigts de succomber à ses atouts.
4 : c’est le point noir de Bible Parser actuellement. Du moins quand un petit détail vient enrayer la machine. Et ce détail s’appelle souvent DLL ou OCX… Avec Xojo et VB.NET, il n’y aura plus de déconvenue de ce type. D’autant que Bible Parser est loin d’utiliser des composants spécifiques ou élaborés !
5 : incorporer des tutoriels vidéo (courts et spécialisés) à l’intérieur de l’interface permettra de documenter, à la source, chaque fonction, et ainsi d’épargner bien du temps en support.
6 : la rapidité tiendra à deux points : l’optimisation du code, et le format des bases de données. J’hésite encore à passer au SQL ou au XML, en raison principalement du travail titanesque de conversion que cela suppose (et ce même aidé avec des scripts d’automatisation… car mes bases n’ont pas toutes le même format). Dans un premier temps, BP sera programmé de manière plus optimale. Je verrai ensuite pour le changement d’accès au données…
7 : ce qui fait l’intérêt de BP dans un monde où les logiciels bibliques (gratuits ou payants) sont de plus en plus sophistiqués, c’est qu’il peut servir tant aux personnes maîtrisant les langues bibliques, tout en leur apportant néanmoins des données utiles (critique textuelle, corpus lemmatisés, données grammaticales, informations contextuelles ou parallèles) qu’aux personnes souhaitant effectuer, en français, des recherches un peu pointues, sans connaissance préalable. Le bon mélange, c’est l’accès à des fonctions puissantes et originales par un minimum d’action et de prérequis. Rapidement.
A cet effet je suis preneur de toute suggestion. A commencer par l’environnement à retenir. Pour l’instant, j’ai une petite préférence pour Xojo, avec lequel j’ai programmé, comme exercice, une mini-application de consultation du NT (dans les versions Stapfer et Oltramare), qui marche parfaitement sur Windows et Mac, nativement. Mais je n’exclus pas VB Express 2013 en raison de la facilité à se documenter sur le langage (les bons ouvrages sont pléthore), ni même des environnements libres que je viens de découvrir, comme MonoDevelop ou SharpDevelop.
Des idées, sur le fond et sur la forme ?
Bonjour Didier,
Je suis développeur professionnel (principalement langage Microsoft .Net Csharp).
Je connais très bien ce sentiment de faire évoluer un produit ou on avait commencer il y a des années avec les connaissances de l’époque et qui au fur et à mesure du temps, bien que ca tourne, ca devient ingérable et dépassé.
Je te conseille une chose, le multiplate-forme c’est LE WEB, l’avenir ce n’est plus des applications fenêtré sur PC ou MAC, à partir de là, tu choisis ce que tu maîtrise le mieux, je crois le Visual Basic, passe donc en VB.Net, c’est ULTRA puissant et ce n’est pas 250.000 développeurs, ce sont des millions ! Le langage diffère légèrement mais tu vas prendre beaucoup de plaisir de programmer en objet, de passer de la 2D en VB à la 3D en VB.Net. Tu ne seras jamais bloqués ou perdu par une question technique, google te répondra toujours par des exemples de millions d’utilisateurs. Tu as des tonnes de bouquins sur le sujet et c’est ultra important de ne jamais être bloqué sur un point technique.
Regarde ce qui se fait sur le web par Google ou Microsoft, des applications solides et complexes, il n’y a aucune limite.
J’espère t’avoir aidé.
David
Merci infiniment pour ce précieux conseil.
La communauté utilisatrice et l’accès à une documentation abondante sont effectivement deux points très sensibles, où Xojo n’est pas terrible. J’ai déjà des pavés bien complets sur .NET, mais ceux consacrés à REALBasic, forcément plus anciens, n’abordent que les données de base, sans aller très loin… D’autant que l’interface de VB.NET est quand même plus engageante que celle de Xojo (auto-complétion, accès à l’aide, souffleurs pour variables…) !
Ah, le choix est difficile… En tout cas, c’est un conseil qui tombe à point nommé, merci encore.
Une autre problématique c’est la pérennité de la plateforme de développement elle-même. Microsoft s’est distancé de la plateforme .NET dans la dernière année. J’en conviens, le nombre de programmeur permet lui permet une certaine inertie avant de tomber dans l’oubli.
Le C# va peut être être abandonnée par un nouveau language ( Midori ? ) avec l’arrivée de Windows 9. Sa rapidité de développement est recherchée mais ses performances laissent à désirer semble-t-il.
A ma connaissance, le développement de Mono a été sérieusement freiné.
Si l’on regarde du côté du net, les langages Perl, Python et Ruby semblent bien adaptés au traitement textuel. Ils sont disponibles pour les trois plateformes.
Et surtout, l’utilisation d’une base de donnée derrière le code nécessite une sacrée – 😉 – analyse.
Désolé, plus de questions que de réponse. 😉
Merci pour ses indications.
À mon niveau, je ne peux me permettre d’être à la pointe. Je cherche surtout à me lancer dans une technologie qui a des chances d’exister encore dans dix ans, et je pense que .NET fera l’affaire. Par ailleurs je n’ai ni le temps ni sans doute l’énergie d’apprendre un langage radicalement différent.
En tout cas merci pour les indications ; le choix d’un langage est souvent cornélien…
Cher Sylvain,
Je ne suis pas d’accord avec toi, cela fait 14 ans que je programme en .Net VB et C#, et le support de Microsoft est constant, la nouvelle version qui sortira pour windows 9, on n’y est pas encore, ne remplacera pas mais sera une évolution du langage, les performances sont excellentes, je participe a des gros projets en temps réels et ca fonctionne impeccablement.
C’est le deuxieme langage le plus utilisés au monde après le JAVA qui doit son succès au domaine libre.
Je ne pense pas que Microsoft va ‘casser’ la branche .Net auxquelles des milliers de développeurs participent.
David
Finalement j’ai opté pour .NET, et quel plaisir ! Les choses ont tellement évolué… Tout est plus robuste, intuitif, documenté, un vrai plaisir de programmer. Je ferai sans doute un petit truc sous Xojo. Mais le gros du travail sera sous VB . NET sachant qu’au fond une partie du code est réutilisable sans peine. Encore merci à vous, vous avez fait penché la balance.
Bonjour Davis,
Effectivement le .NET possède une masse critique importante et ne disparaîtra pas au cours des 5 prochaines années. De même, La courbe d’apprentissage de .NET est beaucoup plus douce a quelqu’un qui vient de VB.
Il y a l’idéal et le réalisable à court terme ! 😉
J’ai hâte de voir la nouvelle mouture 🙂
Oui c’est exactement ça : je suis forcé d’être pragmatique…
Le travail a déjà bien commencé, et je réalise combien je me compliquais la vie à m’accrocher à VB6. J’espère publier la version 1 d’ici à la fin d’année.
Microsoft ouvre .NET à l’open source et propose un Visual Studio 2013
http://www.nextinpact.com/news/90895-microsoft-ouvre-net-a-open-source-et-propose-visual-studio-2013-gratuit.htm#/page/1
Tu sembles éligible pour son utilisation gratuite… Une version BP 2015 multiplateforme ? 🙂
Ces nouvelles sont réjouissantes.
Je vais découvrir avec joie cette version Community.
Je suis déjà extrêmement satisfait de la version expresse, même si j’en perçois parfois les limites.
J’espère de tout coeur que le framework sera rendu compatible à Linux et Mac ! Apparemment, c’est en cours… Mais j’avoue que j’ai un peu de mal à y croire, depuis le temps.
Merci pour les news !