Langages de programmation textuels et graphiques

Question

Je fais partie d'une équipe de robotique de lycée, et il y a un débat sur le langage à utiliser pour programmer notre robot. Nous choisissons entre C (ou peut-être C++) et LabVIEW. Il y a des avantages pour chaque langage.

C(++) :

• Largement utilisé
• Bonne préparation pour l'avenir (la plupart des postes de programmation exigent des programmeurs en mode texte).
• Nous pouvons développer notre base de code C de l'année dernière.
• Permet de mieux comprendre ce que fait notre robot.

LabVIEW

• Visualisation plus aisée du déroulement du programme (blocs et fils, plutôt que lignes de code).
• Plus facile à enseigner (soi-disant...)
• "L'avenir de la programmation est graphique." (Vous le pensez ?)
• Plus proche de l'historique de Robolab que certains nouveaux membres peuvent avoir.
• Pas besoin de savoir intimement ce qui se passe. Dites simplement au module de trouver la balle rouge, sans avoir besoin de savoir comment.

C'est une décision très difficile pour nous, et nous avons débattu pendant un certain temps. En se basant sur les avantages de chaque langue et sur l'expérience que vous avez acquise, quelle est, selon vous, la meilleure option ? Gardez à l'esprit que nous ne recherchons pas nécessairement l'efficacité pure. Nous espérons également préparer nos programmeurs à un avenir dans la programmation.

Aussi :

• Pensez-vous que les langages graphiques tels que LabVEIW sont l'avenir de la programmation ?
• Un langage graphique est-il plus facile à apprendre qu'un langage textuel ? Je pense qu'ils devraient être aussi difficiles à apprendre l'un que l'autre.
• Vu que nous sommes partiellement enracinés dans l'aide à l'apprentissage, Dans quelle mesure devons-nous nous fier à des modules pré-écrits et dans quelle mesure devons-nous essayer d'écrire par nous-mêmes ? ("Les bons programmeurs écrivent du bon code, les grands programmeurs copient du bon code." Mais ne vaut-il pas mieux être un bon programmeur, d'abord).

Merci pour le conseil !

---

Modifier : J'aimerais insister davantage sur cette question : Le capitaine de l'équipe pense que LabVIEW est meilleur pour sa facilité d'apprentissage et d'enseignement. C'est vrai ? Je pense que le C pourrait être enseigné tout aussi facilement, et que les tâches de niveau débutant seraient toujours possibles avec le C. J'aimerais vraiment connaître votre opinion. Y a-t-il une raison pour que la saisie de while{} soit plus difficile que la création d'une "boîte while" ? N'est-il pas tout aussi intuitif que le programme s'écoule ligne par ligne, uniquement modifié par des ifs et des boucles ?

Merci encore !

---

Edit : Je viens de réaliser que ceci tombe dans le sujet "débat sur la langue". J'espère que c'est d'accord, car il s'agit de savoir ce qui est le mieux pour une branche spécifique de la programmation, avec certains objectifs. Si ça ne l'est pas... Je suis désolé...

Answer 1

Avant mon arrivée, notre groupe (des scientifiques titulaires d'un doctorat, avec peu de connaissances en programmation) essayait d'implémenter une application LabVIEW de façon intermittente depuis près d'un an. Le code était désordonné, trop complexe (front-end et back-end) et surtout, il ne fonctionnait pas. Je suis un programmeur passionné, mais je n'avais jamais utilisé LabVIEW. Avec l'aide d'un gourou de LabVIEW qui a pu traduire les paradigmes de programmation textuels que je connaissais en concepts LabVIEW, il a été possible de coder l'application en une semaine. Ce qu'il faut retenir, c'est que les concepts de base du codage doivent toujours être appris, le langage, même celui de LabVIEW, n'est qu'une manière différente de les exprimer. .

LabVIEW est idéal pour ce pour quoi il a été conçu à l'origine, c'est-à-dire pour prendre des données à partir de cartes DAQ et les afficher à l'écran, avec peut-être quelques manipulations mineures entre les deux. Cependant, la programmation algorithmes n'est pas plus facile et je dirais même qu'elle est plus difficile. Par exemple, dans la plupart des langages procéduraux, l'ordre d'exécution est généralement suivi ligne par ligne, en utilisant une notation pseudo-mathématique (par ex. y = x*x + x + 1 ) alors que LabVIEW le mettrait en œuvre en utilisant une série de VI qui ne se suivent pas nécessairement les uns les autres (c'est-à-dire de gauche à droite) sur le canevas.

En outre, la programmation en tant que carrière ne se limite pas à la connaissance des aspects techniques du codage. Être capable de demander de l'aide et de chercher des réponses, d'écrire du code lisible et de travailler avec du code existant sont autant de compétences clés qui sont indéniablement plus difficiles dans un langage graphique tel que LabVIEW.

Je pense que certains aspects de la programmation graphique pourraient devenir courants - l'utilisation de sous-VIs incarne parfaitement le principe de "boîte noire" de la programmation et est également utilisée dans d'autres abstractions de langage telles que Les tuyaux de Yahoo et l'Automator d'Apple - et peut-être qu'un futur langage graphique révolutionnera la façon dont nous programmons, mais LabVIEW lui-même n'est pas un changement radical de paradigme dans la conception des langages. while, for, if le contrôle de flux, le typage, la programmation par événement, et même les objets. Si l'avenir est vraiment écrit en LabVIEW, les programmeurs C++ n'auront pas beaucoup de mal à passer de l'un à l'autre.

En guise de post-scriptum, je dirais que le C/C++ est plus adapté à la robotique puisque les étudiants auront sans doute à faire face à des systèmes embarqués et des FPGA à un moment ou à un autre. La connaissance de la programmation de bas niveau (bits, registres, etc.) serait inestimable pour ce genre de choses.

@mendicant En fait, LabVIEW est très utilisé dans l'industrie, notamment pour les systèmes de contrôle. Il est vrai que la NASA ne l'utilise probablement pas pour les systèmes de satellites embarqués, mais le développement de logiciels pour les systèmes spatiaux est une tâche difficile. tout autre jeu de balle ...

Answer 2

J'ai rencontré une situation assez similaire dans le groupe de recherche dans lequel je travaille actuellement. Il s'agit d'un groupe de biophysique, et nous utilisons LabVIEW partout pour contrôler nos instruments. Cela fonctionne à merveille : il est facile d'assembler une interface utilisateur pour contrôler tous les aspects de vos instruments, pour visualiser leur état et pour enregistrer vos données.

Et maintenant je dois m'empêcher d'écrire une diatribe de 5 pages, parce que pour moi LabVIEW a été un cauchemar. Laissez-moi plutôt essayer de résumer quelques avantages et inconvénients :

Avis de non-responsabilité Je ne suis pas un expert de LabVIEW, je peux dire des choses qui sont biaisées, dépassées ou tout simplement fausses :)

Les pros de LabVIEW

• Oui, c'est facile à apprendre . De nombreux doctorants de notre groupe semblent avoir acquis suffisamment de compétences pour pouvoir travailler en quelques semaines, voire moins.
• Bibliothèques . C'est un point important. Vous devriez étudier attentivement votre situation (je ne sais pas ce dont vous avez besoin, s'il existe de bonnes bibliothèques LabVIEW pour cela, ou s'il existe des alternatives dans d'autres langages). Dans mon cas, trouver, par exemple, une bonne et rapide bibliothèque de graphiques en Python a été un problème majeur, qui m'a empêché de réécrire certains de nos programmes en Python.
• Votre école l'a peut-être déjà installé et fonctionne.

Les inconvénients de LabVIEW

• C'est peut-être trop facile à apprendre. Dans tous les cas, il semble que personne ne se soucie vraiment d'apprendre les meilleures pratiques, de sorte que les programmes deviennent rapidement un désordre complet et irréparable. Bien sûr, cela peut aussi arriver avec les langages textuels si vous ne faites pas attention, mais il est beaucoup plus difficile de faire les choses correctement dans LabVIEW.
• Il y a souvent problèmes majeurs dans LabVIEW avec la recherche de sous-VIs (même jusqu'à la version 8.2, je crois). LabVIEW a sa propre façon de savoir où trouver les bibliothèques et les sous-VI, ce qui rend très facile de casser complètement votre logiciel. Cela rend les grands projets pénibles si vous n'avez pas quelqu'un qui sait comment gérer cela.
• Il est difficile de faire fonctionner LabVIEW avec le contrôle de version. . Bien sûr, c'est possible, mais dans tous les cas, je m'abstiendrais d'utiliser le VC intégré. Voir aussi LVDiff pour un outil de diff LabVIEW, mais ne pensez même pas à fusionner.

(Les deux derniers points rendent difficile le travail en équipe sur un projet. C'est probablement important dans votre cas)

• C'est personnel, mais je trouve que de nombreux algorithmes ne fonctionnent pas lorsqu'ils sont programmés visuellement. C'est un désordre .
  • Un exemple est le matériel qui est strictement séquentiel ; cela devient vite encombrant.
  • Il est difficile d'avoir une vue d'ensemble du code.
  • Si vous utilisez des sous-VI pour de petites tâches (tout comme c'est une bonne pratique de créer des fonctions qui effectuent une petite tâche et qui tiennent sur un seul écran), vous ne pouvez pas simplement leur donner des noms, mais vous devez dessiner des icônes pour chacune d'entre elles. Cela devient très ennuyeux et fastidieux au bout de quelques minutes, et on est alors très tenté no pour mettre des trucs dans un sous-VI. C'est tout simplement trop compliqué. Btw : faire une très bonne icône peut prendre des heures à un professionnel. Essayez de créer une icône unique, immédiatement compréhensible et reconnaissable pour chaque sous-VI que vous écrivez :)
• Vous aurez le canal carpien en une semaine. C'est garanti.
• @Brendan : Bravo, bravo !

Remarques finales

Quant à votre question "devrais-je écrire mes propres modules" : Je ne suis pas sûr. Cela dépend de vos contraintes de temps. Ne passez pas votre temps à réinventer la roue si vous n'avez pas à le faire. Il est trop facile de passer des jours à écrire du code de bas niveau et de réaliser ensuite que vous n'avez plus de temps. Si cela signifie que vous choisissez LabVIEW, allez-y.

S'il existe des moyens faciles de combiner LabVIEW et, par exemple, C++, j'aimerais bien en entendre parler : cela pourrait vous donner le meilleur des deux mondes, mais je doute qu'il y en ait.

Mais veillez à ce que vous et votre équipe consacriez du temps à l'apprentissage des meilleures pratiques. Regarder le code de l'autre. Apprendre les uns des autres. Écrire un code utilisable et compréhensible. Et s'amuser !

Et je vous prie de me pardonner si je vous semble nerveux et peut-être un peu pédant. C'est juste que LabVIEW a été un réel cauchemar pour moi :)

Answer 3

Je pense que le choix de LabVIEW ou non se résume à savoir si vous voulez apprendre à programmer dans un langage couramment utilisé comme une compétence commercialisable, ou si vous voulez simplement faire des choses. LabVIEW vous permet de faire des choses très rapidement et de manière productive. Comme d'autres l'ont fait remarquer, il ne vous dispense pas par magie de comprendre ce que vous faites, et il est tout à fait possible de créer un désordre infernal si vous ne le faites pas - bien que, de manière anecdotique, les pires exemples de mauvais style de codage dans LabVIEW soient généralement perpétrés par des personnes qui ont de l'expérience dans un langage texte et refusent de s'adapter au fonctionnement de LabVIEW parce qu'elles "savent déjà comment programmer, bon sang !

Cela ne veut pas dire que la programmation LabVIEW n'est pas une compétence commercialisable, bien sûr, mais simplement qu'elle n'est pas aussi populaire que le C++.

LabVIEW permet de gérer très facilement différentes activités en parallèle, ce qui peut être le cas dans une situation de commande de robot. Les conditions de course dans un code qui devrait être séquentiel ne devraient pas être un problème non plus (si c'est le cas, c'est que vous vous y prenez mal) : il existe des techniques simples pour s'assurer que les choses se passent dans le bon ordre lorsque c'est nécessaire - enchaîner des subVI en utilisant le fil d'erreur ou d'autres données, utiliser des notificateurs ou des files d'attente, construire une structure de machine à états, et même utiliser la structure de séquence de LabVIEW si nécessaire. Encore une fois, il s'agit simplement de prendre le temps de comprendre les outils disponibles dans LabVIEW et leur fonctionnement. Je ne pense pas que le grief concernant la nécessité de créer des icônes subVI soit très bien dirigé ; vous pouvez très rapidement en créer une contenant quelques mots de texte, peut-être avec une couleur de fond, et cela conviendra à la plupart des usages.

La question "Les langages graphiques sont-ils la voie de l'avenir ?" est un leurre fondé sur une fausse dichotomie. Certaines choses sont bien adaptées aux langages graphiques (le code parallèle, par exemple) ; d'autres conviennent bien mieux aux langages textuels. Je ne m'attends pas à ce que LabVIEW et la programmation graphique disparaissent ou envahissent le monde.

Incidemment, je serais très surpris si la NASA n'a pas utiliser LabVIEW dans le programme spatial. Quelqu'un a récemment décrit sur la liste de diffusion Info-LabVIEW comment il avait utilisé LabVIEW pour développer et tester le contrôle en boucle fermée des surfaces de vol actionnées par des moteurs électriques sur le Boeing 787, et a donné l'impression que LabVIEW était largement utilisé dans le développement de l'avion. LabVIEW est également utilisé pour le contrôle en temps réel dans le cadre de l'étude de faisabilité de l'avion. Le grand collisionneur de hadrons !

L'endroit le plus actif actuellement pour obtenir des informations supplémentaires et de l'aide sur LabVIEW, en dehors du site et des forums de National Instruments, semble être le suivant LAVA .

Answer 4

Lorsque je travaillais pour le Jet Propulsion Laboratory en 1990, LabView et la "programmation graphique" étaient "l'avenir". Apparemment, ils le sont toujours.

Answer 5

Cela ne répond pas directement à votre question, mais vous pouvez envisager une troisième option consistant à intégrer un langage interprété. Lua par exemple, est déjà utilisé dans le domaine de la robotique. Il est rapide, léger et peut être configuré pour fonctionner avec des nombres à virgule fixe plutôt qu'à virgule flottante, car la plupart des microcontrôleurs ne possèdent pas de FPU. Forth est une autre alternative avec un usage similaire.

Il devrait être assez facile d'écrire une fine couche d'interface en C, puis de laisser les étudiants se lâcher avec des scripts interprétés. Vous pourriez même le configurer pour permettre au code d'être chargé dynamiquement sans avoir à recompiler et flasher une puce. Cela devrait réduire le cycle d'itération et permettre aux étudiants de mieux apprendre en voyant les résultats plus rapidement.

Je suis partial. contre en utilisant des outils visuels comme LabVIEW. J'ai toujours l'impression de tomber sur quelque chose qui ne fonctionne pas ou ne fonctionnera pas comme je le voudrais. Je préfère donc le contrôle absolu qu'offre le code textuel.