Bible Parser 2014 ?

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 ?