Les langages de programmation et AutoCAD

[Invité Patrick]

Un assez long article de votre serviteur (n'en abusez pas tout de même...), une réflexion de fond (j'espère) sur la programmation dans AutoCAD.

[(gile)]

Salut,

 

Si je peux comprendre ton désarroi, comme celui de tous qui ont investi dans le VBA, ton jugement semble être altéré par le fait que tu sois contraint d'avoir à apprendre un nouvel environnement de programmation. Et la mauvaise foi te rattrape parfois quand tu compares l'aisance de celui qui maitrise VBA avec les déboires de celui qui débute avec .NET.

 

S'il s'agit de dessiner "une polyligne en partant du point 0,0 pour aller au point 5,5, puis ensuite au point 10,10." point n'est besoin de langage de programmation, une macro de commande ou un script suffit. Et on peut faire déjà beaucoup avec ces outils de personnalisation (CF ce que fait rebcao).

 

Pour des taches plus complexes, un vrai langage de programmation sera plus adapté, voire incontournable. Mais apprendre un langage de programmation n'est pas facile et même si certains sont plus abordables que d'autre, ce n'est qu'au terme d'une certaine maitrise qu'on en tirera les avantages et que les choses deviendront plus faciles (je trouve beaucoup plus facile de faire en LISP ce que font certaines macros de rebcao). Tu sembles avoir oublié tes débuts en LISP ou en VBA.

 

Et plus les taches à accomplir sont complexes, plus l'outil de programmation nécessaire pour les automatiser devra être complexe. Si on peut dire que .NET est plus puissant que LISP ou VBA ce n'est pas uniquement parce que l'exécution est plus rapide, c'est surtout, à mon avis, parce que l'API .NET d'AutoCAD permet de faire des choses que ne permettent pas LISP ou VBA(voir ici par exemple).

 

Certes l'apprentissage de .NET est plus long que celui de LISP ou VBA mais quand on maitrise un peu l'environnement, certaines taches sont plus faciles à programmer et parfois avec beaucoup moins de code.

Par exemple si Visual LISP fournit les fonctions vlax-curve-* (il n'existe pas d'équivalent en VBA) pour faire des opérations géométriques sur les entités curvilignes, .NET en fournit beaucoup plus dans l'espace de nom AutodeskAutoCAD.Geometry avec, par exemple, des outils qui traitent aussi les surfaces.

 

Je ne pense pas que ce soit le fait que .NET soit un peu moins de "haut niveau" que LISP ou VBA qui rend son apprentissage plus long mais plutôt l'étendue des possibilités offerte par l'API .NET d'AutoCAD (il suffit de la comparer avec l'API COM utilisée par VBA et Visual LISP).

Le fait d'aller plus ou moins à la recherche d'aide ou d'exemples sur internet, ne dépend pas de l'environnement de programmation mais du niveau de connaissance du programmeur pour cet environnement, et effectivement avec .NET on est débutant plus longtemps qu'avec LISP ou VBA.

 

En conclusion, oui, .NET ne s'adresse pas au même public que le LISP ou le VBA. Ce ne peut pas être un outil de programmation pour les dessinateurs en raison du temps nécessaire à son apprentissage avant de pouvoir l'utiliser efficacement. C'est un environnement pour ceux qui font plutôt de la programmation sur AutoCAD (n'est-ce pas ce que tu fais ?) mais qui reste quand même bien plus abordable qu'ObjectARX/C++.

 

Pour les dessinateurs qui programment il reste toujours le LISP que tu sembles considérer avec un peu de condescendance (aurais-tu arrêté trop tôt pour passer au VBA ?).

À moins d'être allergique à sa syntaxe et à sa structure particulière, AutoLISP est relativement facile d'accès et permet très rapidement d'écrire des routines simples tout en offrant des possibilités qui n'ont rien à envier au VBA : en plus des fonctions AutoLISP spécifiques, Visual LISP permet l'accès aux mêmes outils que VBA via l'interface COM/ActiveX et avec ObjectDCL ou OpenDCL les boites de dialogue ne sont plus un problème.

 

[Invité Patrick]

Merci de tes remarques très pertinentes. Tu as ressenti du désarroi dans mes propos et tu as bien raison, mais il n'est pas uniquement lié à mon apprentissage actuel du .NET

 

Je n'exclue pas m'être mal exprimé dans mon article. C'est vrai qu'à la relecture, on a l'impression que je hais le .NET et que j'adore le LISP et le VBA, qui seraient donc le "paradis" perdu.

Disons pour préciser ma pensée que le LISP et le VBA furent un peu moins l'enfer, mais certainement pas le paradis.

Non je n'ai pas oublié mes premiers apprentissages du LISP (j'en parle d'ailleurs dans l'article) et les souhaits que j'exprime sur un langage de programmation plus "humain" auraient pu être exprimés il y a 20 ans du temps du LISP.

Ce à quoi je pense pour être plus précis est un langage bien plus proche du langage naturel, car il me semble qu'il devrait être possible d'introduire une couche intermédiaire (appelons la couche Champollion), entre les langages du .NET et le langage parlé.

Facile à dire n'est-ce pas? Pas facile à préciser et encore moins à faire, sans doute.

Mais il faut voir mon article comme un petit coup de gueule, c'est certain, vis à vis des gens qui nous emmènent vers les tréfonds des entrailles de la machine, avec délectation, tout obnubilés qu'ils sont par la beauté intrinsèque de la programmation.

 

C'est "intrinsèque" qui pose problème. Je voudrais aussi que les choses soient claires, tu es un programmeur expérimenté et dieu sait si tu rends des services à la communauté, je suis bien placé pour le savoir n'est-ce pas? Alors je ne voudrais pas que ces réflexions soient prises personnellement, Je ne suis pas un bon programmeur .NET, certes, mais j'ai quand même la tête dans le guidon, je baigne dans l'informatique, et je ne m'exclue pas du tout de mes propres critiques.

 

C'est plutôt une réflexion de fond que je lance. peu importe le langage finalement, car je ne suis apparemment pas le seul à cogiter sur ce sujet, je pense à un certain DesignScript.

 

[(gile)]

Ce à quoi je pense pour être plus précis est un langage bien plus proche du langage naturel, car il me semble qu'il devrait être possible d'introduire une couche intermédiaire (appelons la couche Champollion), entre les langages du .NET et le langage parlé.

 

En quoi AutoLISP/Visual LISP ne répond-il pas à ça ?

[Tramber]

DesignScript sera-t-il l'extension de l'enregistrement de macros de la V2009 ?

 

J'entends bien ce que tu exprimes, moi aussi, mais j'ai cette seule remarque : Autodesk a-t-il le choix ? Autocad est installé sur une plateforme PC et dans un environnement Windows.

 

Si l'éditeur devait amener un nouveau language dans l'implémentation de son logiciel qui soit l'intermédiaire que tu sembles demander, ca serait lequel ?

Je pose la question bêtement (car je suis assez ignorant dans le domaine).

 

Enfin je trouve que ton article fait l'impasse sur ce qu'il s'est passé il y a 10 ans, l'implémentation ActiveX. Elle nous aide quand même à faire des applications très puissantes. Et cette implémentation est stable. Que du bonheur :cool:

 

 

[Invité Patrick]

DesignScript est arrivé sur Autodesk Labs.