2010-12-01T23:00:00Z
Bonjour, je vais vous parler aujourd’hui d’un sujet qui me tient à cœur, les langages de programmation et AutoCAD.
Pas de temps pour tout lire? Voilà un résumé
L’auteur exprime son attachement à AutoCAD®, qu’il utilise depuis environ 20 ans. Il décrit l’évolution de la programmation dans AutoCAD®, passant du LISP au VBA puis à l’environnement .NET. Il souligne que l’objectif de la programmation dans AutoCAD® est de simplifier les tâches des utilisateurs plutôt que de se concentrer sur des performances techniques. L’auteur critique le passage à des langages de programmation moins adaptés aux besoins des utilisateurs d’AutoCAD®, comme le Visual Basic et le C#, qui sont moins intuitifs et nécessitent plus de temps de développement. Il propose de développer un langage de programmation de haut niveau orienté spécifiquement vers le dessin assisté par ordinateur, afin de mieux répondre aux besoins des utilisateurs finaux.
AutoCAD® me tient à cœur parce que je travaille avec lui depuis très longtemps, depuis environ 20 ans [1]. Au début, je tirais des traits qui étaient censés représenter des choses réelles. C’est typiquement ainsi que le dessinateur AutoCAD® travaille, en représentant par des objets géométriques, des objets réels. Ainsi, un double trait peut représenter un mur en dessin d’architecture. Nous savons qu’il s’agit d’un mur parce que conventionnellement c’est ainsi qu’il est représenté. Nous sommes sûrs qu’il ne s’agit pas d’un tuyau, car il est quasiment impossible qu’un tuyau se trouve à cet endroit sur le plan, sans que le bâtiment ne s’écroule. C’est vous dire l’empirisme de la méthode…
Cette façon de faire a des limites. Elle peut conduire à des erreurs d’interprétation. Elle suppose que le dessinateur, ainsi que toutes les personnes qui liront son plan, aient la connaissance du métier, des conventions et des symboles qui servent à représenter la réalité.
Pendant très longtemps, c’était la seule façon de faire lorsque les gens ne disposaient pas encore d’ordinateur. Pas d’autre solution que la bonne vieille planche à dessin. Le Dessin Assisté sur Ordinateur en 2D a donc longtemps été la norme en dessin technique sur ordinateur. Les choses ont commencé à bouger lorsqu’on a pu rassembler quelques objets primaires tels que des lignes, et en faire un bloc. Puis lui donner un nom. Mais nous restions encore dans le domaine du symbolique.
Beaucoup plus tard, nous avons commencé à utiliser la 3D en CAO, en particulier dans le domaine de la mécanique, puis plus tard, dans le domaine de l’architecture. L’idée est alors venue de ne plus représenter et manipuler seulement des objets primaires et des regroupements d’objets primaires tels que les blocs, mais des objets existants réellement, tels que des murs, des fenêtres, du mobilier, etc. Nous commencions à donner de l’intelligence à des objets… Je vous laisse méditer sur la fin de cette phrase.
Bien entendu, ces objets du monde réel étaient toujours représentés virtuellement par un ensemble d’objets primaires géométriques. Il ne peut pas en être autrement. On ne peut pas faire rentrer un bâtiment entier dans la mémoire d’un ordinateur, aussi puissant soit-il. Ne croyez pas ce qu’on vous raconte, le Building Object Model, (BOM), n’existe pas encore…
Mais que vient faire la programmation dans cette discussion ? Car je sens une impatience dans votre regard.
J’y viens. Programmer un ordinateur, c’est écrire une suite d’instructions pour lui faire exécuter des tâches qui seraient soient trop fastidieuses, soit trop lentes, voire impossibles, à faire exécuter par un être humain. Et il est clair qu’en termes de CAO, et plus particulièrement d’AutoCAD®, de nombreux programmes ont été écrit pratiquement depuis l’origine du logiciel pour automatiser le dessin. Le langage LISP est certainement le plus connu. Il avait été choisi par Autodesk® il y a bien longtemps parce que c’était un langage de très haut niveau bien adapté à l’absence de structures d’un dessin AutoCAD®. D’autre part, ce langage permet de manipuler des listes, autrement dit des collections d’objets, et Dieu sait si dans un dessin AutoCAD® il y a de nombreuses collections d’objets.
Mais si vous regardez le code source d’un programme écrit en LISP, vous y reconnaîtrez difficilement les objets du monde réel. Vous pourrez peut-être avec un peu de chance, si le programmeur a bien fait son travail, reconnaître le nom de certaines variables. Mais sinon, rien n’est plus éloigné de votre dessin que le code source d’un programme LISP.
La programmation est un travail de spécialistes. Certes, beaucoup de personnes se sont lancées dans la programmation LISP pour AutoCAD®, et sont arrivés à faire des programmes respectables souvent au prix de nombreuses heures, parfois sur leur temps personnel, et je parle en connaissance de cause, passé à se documenter, à discuter avec d’autres personnes sur Internet, à lire des ouvrages sur le sujet, pour acquérir les connaissances de base du programmeur. Car malgré que le LISP soit un langage très agréable, orienté vers l’intelligence artificielle, il ne fait pas l’économie de l’intelligence du programmeur.
Les choses étaient assez claires jusqu’à l’époque où le LISP était la seule façon de programmer dans AutoCAD®, je parle ici naturellement de la programmation que faisaient les utilisateurs finaux, et pas les professionnels du développement, qui programmaient plutôt en langage C. Mais, vous allez me dire, les choses sont assez claires : pour écrire un programme, il faut être programmeur.
Et bien précisément, il ne me semble pas que cela soit une impérieuse nécessité, même si cela a toujours été le cas. Pour être un bon programmeur, il faut avoir certaines qualités. Il faut avoir de la logique, connaître le domaine auquel la programmation va s’appliquer, en l’occurrence AutoCAD®, être capable de s’exprimer correctement, de comprendre un cahier des charges, de le traduire en projet, puis ensuite en algorithme, puis ensuite en code.
Notez qu’en ce qui concerne le LISP, il n’est pas nécessaire de connaître les arcanes du fonctionnement d’un ordinateur, de savoir comment fonctionne un compilateur. C’est sans doute une des raisons de la popularité du LISP, c’est qu’il était, entre guillemets, accessible aux non-spécialistes.
Puis est venu beaucoup plus tard le Visual Basic pour applications, (VBA), et plus récemment, l’environnement de Microsoft .NET, que l’on nous présente comme le summum des environnements de développement. Au point que le pauvre VBA est lentement abandonné malgré les nombreux services qu’il a rendus.
Est-ce que le VBA est devenu un mauvais langage ? Est-ce que le LISP n’est plus suffisant ?
Non, non. Vous n’y êtes pas du tout. Le VBA est abandonné parce que Microsoft l’a décidé ainsi [2]. Alors, que nous reste-t-il à la place ? Eh bien, vous avez toujours le bon vieux LISP qui peut rendre des services, à part si vous avez à programmer des boîtes de dialogue, auquel cas vous aurez beaucoup de mal. Et puis naturellement le fameux environnement .NET Visual Studio, que Microsoft met en avant avec son partenaire Autodesk®.
Seulement là, ça se complique un peu. On ne passe pas d’un langage adapté à AutoCAD® comme le LISP, à un langage toujours relativement adapté à AutoCAD® comme le VBA, mais on passe de deux langages, parfois complémentaires d’ailleurs, le LISP et le VBA, à un environnement de programmation comportant plusieurs langages, qui est un outil assez clairement réservé aux professionnels.
C’est bien là le nœud du problème. On entend dire que l’environnement .NET c’est mieux, c’est plus rapide, c’est plus puissant, que ce que nous avions jusqu’à maintenant.
Mais on entend aussi des petites voix de plus en plus nombreuses dire, que le mieux est l’ennemi du bien…
Nous sommes donc passés d’un langage de très haut niveau, le LISP, à un langage de niveau un peu moins élevé, le VBA, à un langage encore moins élevé, le Visual Basic, C# ou F# dans l’environnement .NET. À force de passer de langages très élevés à des langages moins élevés, il ne me semble pas que l’on élève le niveau, mais bien au contraire qu’on risque de toucher le plancher. Rien moins que ça.
Parce que finalement, quel est le but de la programmation dans AutoCAD® ? Est-ce que c’est de connaître les possibilités de la machine, est-ce que c’est de se préoccuper de quelle façon est compilé une DLL, de gagner deux millisecondes par ci par là ? Non pas du tout, ces choses-là sont des préoccupations de programmeur professionnel déconnecté du monde réel. Ce qui intéresse seulement les utilisateurs d’AutoCAD® et que le travail soit fait plus rapidement qu’à la main, et franchement, qu’une procédure mette 2 ms de plus qu’une autre leur est totalement égal.
En matière de programmation pour AutoCAD®, nous sommes clairement en train de nous éloigner des besoins. Les gens qui programment pour AutoCAD® perdent leur temps à apprendre des choses qui peuvent servir à un concepteur de système d’exploitation, mais certainement pas à une personne au service des utilisateurs de CAO.
Pour prendre l’exemple de la création d’une simple ligne. Il est naturellement bien plus rapide de la programmer en LISP, ou en VBA d’ailleurs, que de le faire dans l’environnement .NET. Je pense qu’aucun programmeur n’en disconviendra. Alors on voit des développeurs .NET tenter l’impossible, courageusement mais pathétiquement, et se lancer dans des explications fumeuses: Si un programme dessine 10 000 lignes en LISP, 10 000 lignes en VBA, et 10 000 lignes en Visual Basic .NET, la version écrite en Visual Basic .NET dessinera ces lignes beaucoup plus rapidement… La belle affaire ! Mais cela n’intéresse personne. Quel dessinateur AutoCAD® passe ses journées à dessiner toutes les 10 secondes 10 000 lignes ? Je vais vous dire ce qui intéresse le dessinateur AutoCAD® utilisant des développements : c’est que lorsqu’il demande une modification d’un développement à son service informatique, celui-ci soit capable de corriger une ligne de code plutôt que 25. Et franchement, le développeur aussi est intéressé par cela. Et ce n’est certainement pas dans l’environnement .NET que cela se produira; parce que pendant que le LISPeur a déjà fait sa correction, le programmeur VBA lui, est en train de terminer de taper sa ligne, et le malheureux programmeur .NET est encore en train de chercher une hypothétique aide sur le Web parmi d’hypothétiques exemples de codes comment il pourrait bien faire cette correction sans voir s’écrouler l’édifice.
Alors, tout reste à inventer. J’allais dire à réinventer. Non. Il faut reprendre le problème à la racine. Repartir du besoin de l’utilisateur final. Inventer un langage de programmation qui soit d’un niveau bien plus élevé que le VBA et le LISP. Un ordinateur est tout à fait capable de comprendre une phrase exprimée logiquement telle que celle-ci : dessine-moi une polyligne en partant du point 0,0 pour aller au point 5,5, puis ensuite au point 10,10. Il n’y a absolument aucune difficulté à ce qu’un ordinateur comprenne cette phrase. L’immense avantage est que les êtres humains qui entourent la machine, oui il y en a encore, auront également compris de quoi il s’agit. C’est un avantage déterminant, car nous n’aurons plus besoin de Champollion pour passer des centaines d’heures à transcrire la langue parlée en langue comprise par la machine.
Remarquez que cela existe déjà, cela s’appelle l’algorithmique. Mais les techniciens de l’informatique vous diront qu’un ordinateur n’est pas capable de comprendre directement un langage algorithmique. C’est vrai. Eh bien il suffit qu’ils se mettent au travail, et fassent l’intermédiaire entre la machine et les êtres humains. Au lieu de laisser cela aux programmeurs des services informatiques des sociétés utilisant AutoCAD® qui ont vraiment autre chose à faire que de comprendre le fonctionnement interne des machines.
Tous les efforts mis dans le développement de l’environnement .NET devraient être donc tournés vers l’écriture de bibliothèques indépendantes du langage informatique et capable de manipuler des objets que les dessinateurs AutoCAD® connaissent. Ainsi le rôle du programmeur du service informatique de ces sociétés serait de décrire de façon algorithmique une procédure qui elle, serait transcrite de façon transparente en langage compréhensible par la machine, puis l’exécution du code serait lancée.
Et, je suis désolé de le dire, le langage Visual Basic, le C#, le F#, ne ressemblent en rien du tout à des langages de très haut niveau.
L’environnement de développement .NET est censé répondre à tous les besoins, malheureusement, et donc certainement pas en particulier aux besoins des dessinateurs AutoCAD®.
Je termine sur une note d’espoir : il paraît qu’un nouveau langage appelé DesignScript est en train de sortir [3], ce sont les rumeurs qui courent à l’Autodesk® University 2010, très bien. Mais comme je l’ai compris, même si nous aurons des informations plus précises plus tard, il s’agirait d’une sorte de langage de macro plutôt destiné au domaine de la construction et de l’architecture.
Ce dont je parle, et ce à quoi je pense dans cet article c’est quelque chose qui n’est pas du tout orienté métier ni produits verticaux, comme l’on dit, mais qui est orienté DAO, car quoi qu’on en dise et quoi qu’on veuille faire croire, la plupart des gens dessinent encore en 2D des objets qui sont tout à fait virtuels et symboliques, et j’ai comme l’impression que ces gens-là sont laissés pour compte par des êtres géniaux qui croient leur avoir rendu un grand service en leur assurant que l’essence de l’existence est de gagner deux millisecondes.
versão português
AutoCAD est un logiciel de la société Autodesk®
.