Langages de programmation textuels ou graphiques

StackOverflow https://stackoverflow.com/questions/13678

Question

Je fais partie d'une équipe de robotique dans un 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 langue.

C(++) :

  • Largement utilisé
  • Bonne préparation pour l'avenir (la plupart des postes de programmation nécessitent des programmeurs basés sur du texte.)
  • Nous pouvons développer notre base de code C de l'année dernière
  • Nous permet de mieux comprendre ce que fait notre robot.

LabVIEW

  • Visualisation plus facile du déroulement du programme (blocs et fils, au lieu de lignes de code)
  • Plus facile à enseigner (soi-disant...)
  • "L'avenir de la programmation est graphique." (Je le pense?)
  • Plus proche du background Robolab que peuvent avoir certains nouveaux membres.
  • Vous n'avez pas besoin de savoir intimement ce qui se passe.Dites simplement au module de trouver la boule rouge, pas besoin de savoir comment.

C'est une décision très difficile pour nous, et nous en débattons depuis un moment.Sur la base de ces avantages pour chaque langue et de votre expérience, Selon vous, quelle est la meilleure option ? Gardez à l’esprit que nous ne visons 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 tout aussi difficiles à apprendre.
  • Étant donné que notre objectif est en partie d’aider les gens à apprendre, dans quelle mesure devrions-nous nous appuyer sur des modules pré-écrits et dans quelle mesure devrions-nous essayer d'écrire par nous-mêmes ? ("Les bons programmeurs écrivent du bon code, les grands programmeurs copient du bon code." Mais cela ne vaut-il pas la peine d'ê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 en raison de sa facilité d'apprentissage et d'enseignement. Est-ce vrai? Je pense que le C pourrait être enseigné tout aussi facilement et que les tâches de niveau débutant seraient toujours disponibles avec C.J'aimerais vraiment entendre vos opinions. Y a-t-il une raison pour laquelle taper while{} devrait être plus difficile que de créer une "boîte while ?" N'est-il pas aussi intuitif que le programme s'écoule ligne par ligne, uniquement modifié par des ifs et des boucles, qu'il est intuitif que le programme s'écoule à travers le fil, uniquement modifié par des ifs et des boucles !?

Merci encore!

Modifier:Je viens de réaliser que cela relève du sujet du «débat en langue». J'espère que ça va, car il s'agit de ce qui est le mieux pour une branche spécifique de la programmation, avec certains objectifs.Si ce n'est pas le cas...Je suis désolé...

Était-ce utile?

La solution

Avant mon arrivée, notre groupe (des doctorants avec peu d'expérience en programmation) essayait d'implémenter une application LabVIEW de manière intermittente depuis près d'un an.Le code était désordonné, trop complexe (front et back-end) et surtout, ne fonctionnait pas.Je suis un programmeur passionné mais je n'ai jamais utilisé LabVIEW.Avec l'aide d'un gourou de LabVIEW qui pouvait m'aider à traduire les paradigmes de programmation textuelle que je connaissais en concepts LabVIEW, il a été possible de coder l'application en une semaine.Le point ici est que les concepts de base du codage doivent encore être appris, le langage, même celui comme LabVIEW, n'est qu'une manière différente de les exprimer.

LabVIEW est idéal à utiliser pour ce pour quoi il a été conçu à l'origine.c'est à dire.pour prendre les données des cartes DAQ et les afficher à l'écran, peut-être avec quelques manipulations mineures entre les deux.Cependant, la programmation algorithmes n'est pas plus facile et je dirais même que c'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 (c'est-à-dire y = x*x + x + 1) alors que LabVIEW implémenterait cela en utilisant une série de VIs qui ne se suivent pas nécessairement les uns les autres (c'est-à-direde gauche à droite) sur la toile.

De plus, la programmation en tant que carrière ne se limite pas à connaître les détails techniques du codage.Être capable de demander efficacement de l'aide/rechercher 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 la « boîte noire » de la programmation et est également utilisée dans d'autres abstractions de langage telles que Tuyaux Yahoo et Apple Automator - et peut-être qu'un futur langage graphique révolutionnera notre façon de programmer, mais LabVIEW en lui-même ne constitue pas un changement de paradigme massif dans la conception de langages, nous avons encore while, for, if contrôle de flux, transtypage, programmation événementielle et même objets.Si l'avenir s'écrit réellement dans LabVIEW, les programmeurs C++ n'auront pas beaucoup de mal à le traverser.

En guise de post-scriptum, je dirais que le C/C++ est plus adapté à la robotique puisque les étudiants seront sans doute amenés à un moment ou à un autre à gérer des systèmes embarqués et des FPGA.Des connaissances en programmation de bas niveau (bits, registres, etc.) seraient inestimables pour ce genre de choses.

@mendiant Actuellement LabVIEW est beaucoup utilisé dans l’industrie, notamment pour les systèmes de contrôle.Certes, il est peu probable que la NASA l'utilise pour les systèmes satellitaires embarqués, mais le développement de logiciels pour les systèmes spatiaux est alors une tâche ardue. un jeu de balle complètement différent...

Autres conseils

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

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

Clause de non-responsabilité Je ne suis pas un expert LabVIEW, je pourrais dire des choses biaisées, obsolètes ou tout simplement fausses :)

Avantages de LabVIEW

  • Oui ce est Facile à apprendre.De nombreux docteurs de notre groupe semblent avoir acquis suffisamment de compétences pour pouvoir les pirater en quelques semaines, voire moins.
  • Bibliothèques.C'est un point majeur.Vous devrez étudier attentivement cela pour votre propre situation (je ne sais pas de quoi 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 bibliothèque de graphiques rapide 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 fonctionnel.

Inconvénients de LabVIEW

  • C'est peut-être aussi Facile à apprendre.Quoi qu’il en soit, il semble que personne ne se soucie vraiment d’apprendre les meilleures pratiques, de sorte que les programmes deviennent rapidement un gâchis complet et irréparable.Bien sûr, cela se produira également avec les langages textuels si vous ne faites pas attention, mais à mon avis, il est beaucoup plus difficile de faire les choses correctement dans LabVIEW.
  • Il y a généralement problèmes majeurs dans LabVIEW avec la recherche de sous-VIs (même jusqu'à la version 8.2, je pense).LabVIEW a sa propre façon de savoir où trouver les bibliothèques et les sous-VIs, ce qui rend très facile le démantèlement complet de votre logiciel.Cela rend les grands projets pénibles si vous n'avez pas quelqu'un autour qui sait comment gérer cela.
  • Faire fonctionner LabVIEW avec le contrôle de version est une tâche ardue.Bien sûr, cela peut être fait, mais dans tous les cas, je m'abstiendrais d'utiliser le VC intégré.Vérifier LVDiff pour un outil de comparaison LabVIEW, mais ne pensez même pas à la fusion.

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

  • C'est personnel, mais je trouve que de nombreux algorithmes ne fonctionnent tout simplement pas lorsqu'ils sont programmés visuellement. C'est le bordel.
    • Un exemple est celui des choses strictement séquentielles ;cela devient assez vite fastidieux.
    • Il est difficile d'avoir une vue d'ensemble du code.
    • Si vous utilisez des sous-VIs pour de petites tâches (tout comme c'est une bonne pratique de créer des fonctions qui exécutent 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 chacun. d'eux.Cela devient très ennuyeux et fastidieux en quelques minutes seulement, vous êtes donc très tenté pas mettre des choses dans un sous-VI.C'est tout simplement trop compliqué.D'ailleurs:créer une très bonne icône peut prendre des heures professionnelles.Allez essayer 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 d’ici une semaine.Garanti.
  • @Brendan :entendre entendre!

Remarques finales

Quant à votre question « dois-je écrire mes propres modules » :Je ne suis pas sûr.Cela dépend de vos contraintes de temps.Ne perdez pas de temps à réinventer la roue si ce n’est pas nécessaire.Il est trop facile de passer des jours à écrire du code de bas niveau et de se rendre compte ensuite que vous n'avez plus de temps.Si cela signifie que vous choisissez LabVIEW, allez-y.

S'il existe des moyens simples de combiner LabVIEW et, par exemple, C++, j'aimerais en entendre parler :cela peut vous donner le meilleur des deux mondes, mais je doute que ce soit le cas.

Mais assurez-vous que vous et votre équipe consacrez du temps à l’apprentissage des meilleures pratiques.En regardant le code de chacun.Apprendre les uns des autres.Écrire du code utilisable et compréhensible.Et s'amuser !

Et s'il vous plaît, pardonnez-moi de paraître nerveux et peut-être quelque peu pédant.C'est juste que LabVIEW a été un réel un cauchemar pour moi :)

Je pense que le choix de LabVIEW ou non dépend de si vous souhaitez apprendre à programmer dans un langage couramment utilisé en tant que compétence commercialisable, ou si vous souhaitez simplement faire avancer les choses.LabVIEW vous permet d'accomplir des tâches très rapidement et de manière productive.Comme d'autres l'ont observé, cela ne vous libère pas comme par magie de la nécessité de comprendre ce que vous faites, et il est tout à fait possible de créer un désordre impie si vous ne le faites pas - bien que, de manière anecdotique, les pires exemples de mauvais style de codage dans LabVIEW sont généralement perpétrés par des personnes expérimentées dans un langage texte et qui refusent de s'adapter au fonctionnement de LabVIEW parce qu'elles « savent déjà programmer, bon sang !

Cela ne veut pas dire que la programmation LabVIEW n'est pas une compétence commercialisable, bien sûr ;juste que ce n'est pas aussi grand public que le C++.

LabVIEW rend extrêmement simple la gestion de différentes choses se déroulant en parallèle, ce que vous pourriez très bien avoir dans une situation de contrôle de robot.Les conditions de concurrence dans le code qui devraient être séquentielles ne devraient pas non plus poser de problème (c'est-à-diresi c'est le cas, vous vous trompez) :il existe des techniques simples pour s'assurer que les choses se produisent dans le bon ordre lorsque cela est nécessaire - enchaîner des sous-VIs à l'aide du fil d'erreur ou d'autres données, utiliser des notificateurs ou des files d'attente, construire une structure de machine à états, voire 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 reproche concernant la nécessité de créer des icônes de sous-VI soit très bien dirigé ;vous pouvez très rapidement en créer un contenant quelques mots de texte, peut-être avec une couleur de fond, et cela conviendra dans la plupart des cas.

«Les langages graphiques sont-ils la voie de l'avenir» est une fausse piste basée sur une fausse dichotomie.Certaines choses sont bien adaptées aux langages graphiques (le code parallèle par exemple) ;d'autres choses conviennent bien mieux aux langues de texte.Je ne m'attends pas à ce que LabVIEW et la programmation graphique disparaissent ou conquièrent le monde.

À propos, je serais très surpris si la NASA n'a pas utilisez 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 avait été largement utilisé dans le développement de l'avion.Il est également utilisé pour le contrôle en temps réel dans le Grand collisionneur de hadrons !

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

Cela ne répond pas directement à votre question, mais vous souhaiterez peut-être envisager une troisième option de mixage dans une langue interprétée. 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 au lieu de nombres à virgule flottante puisque la plupart des microcontrôleurs n'ont pas de FPU. En avant est une autre alternative avec une utilisation similaire.

Il devrait être assez facile d'écrire une fine couche d'interface en C, puis de laisser les étudiants se débrouiller avec des scripts interprétés.Vous pouvez même le configurer pour permettre au code d'être chargé dynamiquement sans recompiler ni 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 biasée contre en utilisant des outils visuels comme LabVIEW.J'ai toujours l'impression de toucher quelque chose qui ne fonctionne pas ou ne fonctionnera pas comme je le souhaite.Je préfère donc le contrôle absolu que vous obtenez avec le code textuel.

L'autre point fort de LabVIEW (outre les bibliothèques) est concurrence.C'est un langage de flux de données, ce qui signifie que le runtime peut gérer la simultanéité pour vous.Donc, si vous effectuez quelque chose de hautement concurrent et que vous ne souhaitez pas avoir recours à la synchronisation traditionnelle, LabVIEW peut vous aider.

L’avenir n’appartient pas aux langages graphiques tels qu’ils se présentent aujourd’hui.Il appartient à quiconque peut proposer une représentation du flux de données (ou un autre type de programmation respectueux de la concurrence) aussi simple que l'approche graphique, mais également analysable par les propres outils du programmeur.

Il existe une étude publiée sur le sujet hébergée par National Instruments :

Une étude des graphiques vs.Programmation textuelle pour l'enseignement du DSP

Il examine spécifiquement LabVIEW par rapport à MATLAB (par opposition à C).

Je pense que les langages graphiques seront toujours limités en expressivité par rapport aux langages textuels.Comparez le fait d'essayer de communiquer à l'aide de symboles visuels (par exemple, REBUS ou langue des signes) à la communication en utilisant des mots.

Pour des tâches simples, utiliser un langage graphique est généralement plus facile, mais pour une logique plus complexe, je trouve que les langages graphiques gênent.

Un autre débat impliqué dans cet argument, cependant, est celui de la programmation déclarative par rapport à la programmation déclarative.impératif.Le déclaratif est généralement meilleur pour tout ce qui ne nécessite pas vraiment un contrôle précis sur la façon dont quelque chose est fait.Toi peut utilisez C++ de manière déclarative, mais vous auriez besoin de plus de travail au départ pour y parvenir, alors que LABView est conçu comme un langage déclaratif.

Une image vaut mille mots, mais si une image représente mille mots dont vous n'avez pas besoin et que vous ne pouvez pas changer cela, alors dans ce cas, une image ne vaut rien.Tandis que vous pouvez créer des milliers d'images en utilisant des mots, en spécifiant chaque détail et même en attirant explicitement l'attention du spectateur.

LabVIEW vous permet de démarrer rapidement et (comme d'autres l'ont déjà dit) dispose d'une énorme bibliothèque de code pour effectuer diverses tâches liées aux tests, aux mesures et au contrôle.

Le plus gros inconvénient de LabVIEW, cependant, est que vous perdez tous les outils que les programmeurs écrivent pour eux-mêmes.

Votre code est stocké sous forme de VIs.Ce sont des fichiers binaires opaques.Cela signifie que votre code n'est pas vraiment le vôtre, mais celui de LabVIEW.Vous ne pouvez pas écrire votre propre analyseur, vous ne pouvez pas écrire un générateur de code, vous ne pouvez pas effectuer de modifications automatisées via des macros ou des scripts.

Ce c'est nul lorsque vous avez une application 5000 VI qui nécessite quelques ajustements mineurs appliqués universellement.Ton seulement L'option est de parcourir chaque VI manuellement, et le ciel vous aidera si vous manquez un changement dans un VI dans un coin quelque part.

Et oui, comme c'est binaire, vous ne pouvez pas faire de comparaison/fusion/correction comme vous le pouvez avec les langages textuels.Cela fait en effet de travailler avec plus d’une version du code un horrible cauchemar de maintenabilité.

Bien sûr, utilisez LabVIEW si vous faites quelque chose de simple, si vous avez besoin de prototyper ou si vous ne prévoyez pas de maintenir votre code.

Si vous souhaitez réaliser une programmation réelle et maintenable, utilisez un langage textuel.Vous serez peut-être plus lent au début, mais vous serez plus rapide à long terme.

(Oh, et si vous avez besoin de bibliothèques DAQ, NI en propose également des versions C++ et .Net.)

Mon premier post ici :) soyez doux...

Je viens d'un milieu intégré dans l'industrie automobile et je travaille maintenant dans l'industrie de la défense.Je peux vous dire par expérience que C/C++ et LabVIEW sont des bêtes vraiment différentes avec des objectifs différents en tête.C/C++ a toujours été utilisé pour le travail embarqué sur les microcontrôleurs car il était compact et les compilateurs/outils étaient faciles à trouver.LabVIEW, d'autre part, a été utilisé pour piloter le système de test (avec le banc d'essai comme séquenceur).La plupart des équipements de test que nous avons utilisés provenaient de NI, donc LabVIEW a fourni un environnement dans lequel nous disposions des outils et des pilotes requis pour le travail, ainsi que du support que nous souhaitions.

En termes de facilité d'apprentissage, il existe de nombreuses ressources pour C/C++ et de nombreux sites Web qui présentent des considérations de conception et des exemples d'algorithmes sur à peu près tout ce que vous recherchez, disponibles gratuitement.Pour LabVIEW, la communauté d'utilisateurs n'est probablement pas aussi diversifiée que C/C++, et il faut un peu plus d'efforts pour inspecter et comparer des exemples de code (il faut avoir la bonne version de LabVIEW, etc.)...J'ai trouvé LabVIEW assez facile à maîtriser et à apprendre, mais il y a des désagréments, comme certains l'ont mentionné ici, liés au parallélisme et à diverses autres choses qui nécessitent un peu d'expérience avant d'en prendre conscience.

Alors la conclusion après tout ça ?Je dirais que les DEUX langages valent la peine d'être appris car ils représentent en réalité deux styles de programmation différents et il vaut certainement la peine d'être conscient et compétent dans les deux.

Oh mon Dieu, la réponse est si simple.Utiliser LabView.

Je programme des systèmes embarqués depuis 10 ans, et je peux dire que sans au moins quelques mois d'infrastructure (infrastructure très soignée !), vous ne serez pas aussi productif qu'au premier jour avec LabView.

Si vous concevez un robot destiné à être vendu et utilisé pour l'armée, allez-y et commencez par C - c'est une bonne décision.

Sinon, utilisez le système qui vous permet d’essayer la plus grande variété dans les plus brefs délais.C'est LabView.

Je pense que les langages graphiques pourraient être le langage du futur.....pour tous ces développeurs ad hoc MS Access.Il y aura toujours une place pour les codeurs purement textuels.

Personnellement, je dois me demander quel est le véritable plaisir de construire un robot si tout est fait pour vous ?Si vous y déposez simplement un module « trouver la boule rouge » et que vous la regardez partir ?Quel sentiment de fierté éprouverez-vous face à votre accomplissement ?Personnellement, je n'aurais pas grand-chose.De plus, que vous apprendra-t-il sur le codage, ou sur l'aspect (très important) de l'interface logiciel/matériel qui est critique en robotique ?

Je ne prétends pas être un expert en la matière, mais posez-vous une chose :Pensez-vous que la NASA a utilisé LabVIEW pour coder les Mars Rovers ?Pensez-vous que quelqu'un de véritablement important dans le domaine de la robotique utilise LabView ?

Vraiment, si vous me demandez, la seule chose à laquelle l'utilisation de choses à l'emporte-pièce comme LabVIEW pour construire cela va vous préparer est d'être un constructeur de robots de jardin et rien de plus.Si vous voulez quelque chose qui vous donnera davantage une expérience industrielle, créez votre propre système de type « LabVIEW ».Créez votre propre module de recherche de balle ou votre propre module « suivez la ligne ».Ce sera beaucoup plus difficile, mais ce sera aussi beaucoup plus cool.:D

J'adore LabVIEW.Je le recommande vivement, surtout si les autres se souviennent d'avoir utilisé quelque chose de similaire.Il faut un certain temps aux programmeurs normaux pour s'y habituer, mais les résultats sont bien meilleurs si vous savez déjà programmer.

C/C++ équivaut à gérer votre propre mémoire.Vous nagerez dans les liens de mémoire et vous vous en soucierez.Optez pour LabVIEW et assurez-vous de lire la documentation fournie avec LabVIEW et faites attention aux conditions de concurrence.

Apprendre une langue est facile.Apprendre à programmer ne l’est pas.Cela ne change pas même s'il s'agit d'un langage graphique.L’avantage des langages graphiques est qu’il est plus facile de visualiser ce que fera le code plutôt que de rester là et de déchiffrer un tas de texte.

L'important n'est pas le langage mais les concepts de programmation.Peu importe la langue dans laquelle vous apprenez à programmer, car avec un petit effort, vous devriez être capable de bien programmer dans n'importe quelle langue.Les langues vont et viennent.

Clause de non-responsabilité:Je n'ai pas vu LabVIEW, mais j'ai utilisé quelques autres langages graphiques, notamment WebMethods Flow et Modeller, des langages de simulation dynamique à l'université et, euh, Scratch du MIT :).

D'après mon expérience, les langages graphiques peuvent faire du bon travail dans la partie « plomberie » de la programmation, mais ceux que j'ai utilisés gênent activement l'algorithmique.Si vos algorithmes sont très simples, cela pourrait être OK.

D’un autre côté, je ne pense pas non plus que le C++ soit adapté à votre situation.Vous passerez plus de temps à rechercher les problèmes de gestion des pointeurs et de la mémoire qu'à effectuer un travail utile.

Si votre robot peut être contrôlé à l'aide d'un langage de script (Python, Ruby, Perl, peu importe), alors je pense que ce serait un bien meilleur choix.

Ensuite, il existe des options hybrides :

S'il n'y a pas d'option de script pour votre robot et que vous avez un geek C++ dans votre équipe, envisagez de demander à ce geek d'écrire des liaisons pour mapper votre bibliothèque C++ à un langage de script.Cela permettrait à des personnes ayant d’autres spécialités de programmer le robot plus facilement.Les reliures feraient un bon cadeau à la communauté.

Si LabVIEW le permet, utilisez son langage graphique pour assembler des modules écrits dans un langage textuel.

Vous êtes à l'école secondaire.De combien de temps disposez-vous pour travailler sur ce programme ?Combien de personnes composent votre groupe ?Connaissent-ils déjà C++ ou LabView ?

D'après votre question, je vois que vous connaissez le C++ et que la plupart des membres du groupe ne le savent pas.Je soupçonne également que le chef du groupe est suffisamment perspicace pour remarquer que certains membres de l'équipe peuvent être intimidés par un langage de programmation textuel.C'est acceptable, vous êtes au lycée et ces gens sont normes.J'ai l'impression que les lycéens normaux seront capables de comprendre LabView de manière plus intuitive que le C++.Je suppose que la plupart des lycéens, comme la population en général, ont peur d'une ligne de commande.Pour vous, la différence est bien moindre, mais pour eux, c'est le jour et la nuit.

Vous avez raison de dire que les mêmes concepts peuvent être appliqués à LabView et au C++.Chacun a ses forces et ses faiblesses.La clé est de sélectionner le bon outil pour le travail.LabView était conçu pour ce genre d'application.Le C++ est beaucoup plus générique et peut être appliqué à de nombreux autres types de problèmes.

Je vais recommander LabView.Avec le bon matériel, vous pouvez être opérationnel presque immédiatement.Votre équipe peut passer plus de temps faire en sorte que le robot fasse ce que vous voulez, c’est là que devrait être le centre de cette activité.

Les langages graphiques ne sont pas l’avenir de la programmation ;ils font partie des choix disponibles, créés pour résoudre certains types de problèmes, depuis de nombreuses années.L’avenir de la programmation repose sur une couche d’abstraction, loin du code machine.À l’avenir, nous nous demanderons pourquoi nous perdons sans cesse tout ce temps à programmer la « sémantique ».

dans quelle mesure devrions-nous nous appuyer sur des modules pré-écrits et dans quelle mesure devrions-nous essayer d'écrire par nous-mêmes ?Il ne faut pas perdre de temps à réinventer la roue.Si des pilotes de périphériques sont disponibles dans Labview, utilisez-les.Vous pouvez apprendre beaucoup en copiant du code dont la fonction est similaire et en l'adaptant à vos besoins - vous voyez comment d'autres personnes ont résolu des problèmes similaires et devez interpréter leur solution avant de pouvoir l'appliquer correctement à votre problème.Si vous copiez aveuglément du code, les chances de le faire fonctionner sont minces.Il faut être bon, même si vous copiez du code.

Bonne chance!

Je vous suggère d'utiliser LabVIEW car vous pouvez faire en sorte que le robot fasse ce que vous voulez faire plus rapidement et plus facilement.LabVIEW a été conçu dans cet esprit.OfCourse C(++) est un excellent langage, mais LabVIEW fait ce qu'il est censé faire mieux que toute autre chose.Les gens peuvent écrire de très bons logiciels dans LabVIEW car il offre une portée et une prise en charge étendues.

Il y a une chose énorme que j'ai trouvée négative dans l'utilisation de LabVIEW pour mes applications :Organisez la complexité de la conception.En tant que physicien, je trouve Labview idéal pour le prototypage, le contrôle d'instruments et l'analyse mathématique.Il n'existe aucun langage dans lequel vous obtenez un résultat plus rapide et meilleur que dans LabVIEW.J'utilise LabView depuis 1997.Depuis 2005, je suis complètement passé au framework .NET, car il est plus facile à concevoir et à maintenir.

Dans LabVIEW, une simple structure « si » doit être dessinée et utilise beaucoup d'espace sur votre conception graphique.Je viens de découvrir que bon nombre de nos applications commerciales étaient difficiles à maintenir.Plus la demande devenait complexe, plus elle était difficile à lire.

J'utilise maintenant les langues de texte et je suis bien meilleur dans la maintenance de tout.Si vous compariez C++ à LabVIEW, j'utiliserais LabVIEW, mais comparé à C#, ce n'est pas gagnant

Comme toujours, cela dépend.

J'utilise LabVIEW depuis environ 20 ans maintenant et j'ai effectué un large éventail de tâches, du simple DAQ à la visualisation très complexe, des contrôles de périphériques aux séquenceurs de test.Si ce n’était pas suffisant, j’aurais certainement changé.Cela dit, j'ai commencé à coder Fortran avec des cartes perforées et j'ai utilisé de nombreux langages de programmation sur des « machines » 8 bits, à commencer par celles basées sur Z80.Les langages allaient de l'Assembleur au BASIC, du Turbo-Pascal au C.

LabVIEW a constitué une amélioration majeure en raison de ses bibliothèques étendues pour l'acquisition et l'analyse de données.Il faut cependant apprendre un paradigme différent.Et vous avez absolument besoin d'un trackball ;-))

Je ne connais rien à LabView (ni beaucoup à propos de C/C++), mais...

Pensez-vous que les langages graphiques tels que LabVEIW sont l’avenir de la programmation ?

Non...

Un langage graphique est-il plus facile à apprendre qu’un langage textuel ?Je pense qu’ils devraient être tout aussi difficiles à apprendre.

Plus facile à apprendre ?Non, mais ils sont plus facile à expliquer et à comprendre.

Pour expliquer un langage de programmation, vous devez expliquer ce qu'est une variable (ce qui est étonnamment difficile).Ce n'est pas un problème avec les outils de codage flowgraph/nodal, comme l'interface de programmation LEGO Mindstroms ou Quartz Composer.

Par exemple, il s'agit d'un programme LEGO Mindstroms assez compliqué - c'est très simple de comprendre ce qui se passe...mais que se passe-t-il si vous voulez que le robot exécute le INCREASEJITTER bloquer 5 fois, puis avancer pendant 10 secondes, puis réessayer la boucle INCREASEJITTER ?Les choses commencent à se gâter très vite.

Quartz Composer en est un excellent exemple, et c'est pourquoi je ne pense pas que les langages graphiques "seront un jour l'avenir".

Cela permet de réaliser très facilement des trucs vraiment sympas (effets de particules 3D, avec une caméra contrôlée par la luminosité moyenne des pixels d'une webcam).mais incroyablement difficile de faire des choses faciles, comme parcourir les éléments d'un fichier XML ou stocker cette valeur moyenne de pixel dans un fichier.

Étant donné que notre objectif est en partie d’aider les gens à apprendre, dans quelle mesure devrions-nous nous appuyer sur des modules pré-écrits et dans quelle mesure devrions-nous essayer d’écrire par nous-mêmes ?("Les bons programmeurs écrivent du bon code, les grands programmeurs copient du bon code." Mais cela ne vaut-il pas la peine d'être un bon programmeur, d'abord ?)

Pour apprendre, il est tellement plus facile à la fois d'expliquer et de comprendre un langage graphique.

Cela dit, je recommanderais un langage linguistique spécialisé basé sur du texte comme progression.Par exemple, pour les graphiques, quelque chose comme Traitement ou NoeudBox.Ce sont des langages "normaux" (Processing est Java, NodeBox est Python) avec des frameworks très spécialisés, faciles à utiliser (mais absurdement puissants) ancrés en eux.

Surtout, ce sont des langages très interactifs, vous n'avez pas besoin d'écrire des centaines de lignes juste pour obtenir un cercle à l'écran.Vous venez de taper oval(100, 200, 10, 10) et appuyez sur le bouton Exécuter, et il apparaît !Cela les rend également très faciles à démontrer et à expliquer.

Plus lié à la robotique, même quelque chose comme LOGO serait une bonne introduction - vous tapez "FORWARD 1" et la tortue avance d'une case.Tapez "LEFT 90" et il tourne à 90 degrés.Cela se rapporte très simplement à la réalité.Vous pouvez visualiser ce que fera chaque instruction, puis l'essayer et confirmer qu'elle fonctionne vraiment de cette façon.

Montrez-leur des choses brillantes, ils récupéreront les choses utiles qu'ils apprendraient de C en cours de route, s'ils sont intéressés ou progressent au point où ils ont besoin d'un "vrai" langage, ils auront toutes ces connaissances, plutôt que rencontrer l'erreur de syntaxe et compiler le mur de briques.

Il semble que si vous essayez de préparer notre équipe à un avenir dans la programmation, C(++) pourrait être la meilleure voie.La promesse des langages de programmation généraux construits avec des éléments visuels n’a jamais semblé se matérialiser et je commence à me demander s’ils le feront un jour.Il semble que même si cela peut être fait pour des domaines de problèmes spécifiques, une fois que vous essayez de résoudre de nombreux problèmes généraux, un langage de programmation basé sur du texte est difficile à battre.

À un moment donné, j'avais en quelque sorte adhéré à l'idée d'UML exécutable, mais il semble qu'une fois que vous auriez dépassé les relations d'objet et certains flux de processus, UML serait une façon assez misérable de créer une application.Imaginez essayer de tout connecter à une interface graphique.Cela ne me dérangerait pas d'avoir tort, mais jusqu'à présent, il semble peu probable que nous puissions bientôt programmer par pointer-cliquer.

J'ai commencé avec LabVIEW il y a environ 2 ans et je l'utilise maintenant tout le temps, donc peut-être biaisé, mais je le trouve idéal pour les applications où l'acquisition et le contrôle de données sont impliqués.

Nous utilisons LabVIEW principalement pour les tests où nous prenons des mesures continues et contrôlons les vannes de gaz et les enceintes ATE.Cela implique des entrées et sorties numériques et analogiques avec des routines d'analyse de signal et un contrôle de processus exécutés à partir d'une interface graphique.En décomposant chaque partie en sous-VIs, nous sommes en mesure de reconfigurer les tests d'un simple clic et glisser la souris.

Ce n'est pas exactement la même chose que C/C++, mais une implémentation similaire de mesure, de contrôle et d'analyse à l'aide de Visual BASIC semble complexe et difficile à maintenir en comparaison.

Je pense que le processus de programmation est plus important que le langage de codage lui-même et que vous devez suivre les directives de style d'un langage de programmation graphique.Les diagrammes LabVIEW montrent le flux de données (Programmation de flux de données) donc il devrait être facile de voir les conditions de course potentielles même si je n'ai jamais eu de problèmes.Si vous disposez d'une base de code C, sa construction dans une DLL permettra à LabVIEW de l'appeler directement.

Les deux choix présentent certainement des avantages ;cependant, puisque votre domaine est une expérience éducative, je pense qu'une solution C/C++ profiterait le plus aux étudiants.La programmation graphique sera toujours une option, mais elle ne fournit tout simplement pas les fonctionnalités d'une manière élégante qui la rendraient plus efficace à utiliser que la programmation textuelle pour la programmation de bas niveau.Ce n’est pas une mauvaise chose : le but même de l’abstraction est de permettre une nouvelle compréhension et une nouvelle vision d’un domaine problématique.La raison pour laquelle je pense que beaucoup peuvent être déçus par la programmation graphique est que, pour un programme particulier, le gain incrémentiel en passant de la programmation en C à la programmation graphique n'est pas du tout le même que celui du passage de l'assembleur au C.

La connaissance de la programmation graphique profiterait certainement à tout futur programmeur.Il y aura probablement des opportunités dans le futur qui ne nécessiteront que des connaissances en programmation graphique et peut-être que certains de vos étudiants pourraient bénéficier d'une première expérience dans ce domaine.D'un autre côté, une base solide dans les concepts fondamentaux de programmation offerte par une approche textuelle bénéficiera tous de vos étudiants et doit sûrement être la meilleure réponse.

Le capitaine de l'équipe pense que LabView est meilleur pour sa facilité d'apprentissage et d'enseignement.Est-ce vrai?

Je doute que cela soit vrai pour une seule langue ou un seul paradigme.LabView pourrait sûrement être plus facile pour les personnes ayant une formation en génie électronique ;y créer des programmes, c'est "simplement" dessiner des fils.Là encore, ces personnes pourraient également déjà être exposées à la programmation.

Une différence essentielle - outre le graphique - est que LV est une programmation (débit) basée sur la demande.Vous partez du résultat et dites ce qui est nécessaire pour y parvenir.La programmation traditionnelle a tendance à être impérative (c’est l’inverse).

Certaines langues peuvent fournir les deux.J'ai récemment créé une bibliothèque multithread pour Lua (Lanes) et elle peut être utilisée pour la programmation basée sur la demande dans un environnement autrement impératif.Je sais qu'il existe des robots à succès qui fonctionnent principalement en Lua (Ivan le fou à Lua Oh Six).

Avez-vous jeté un œil à Microsoft Robotics Studio ?http://msdn.microsoft.com/en-us/robotics/default.aspx

Il permet une programmation visuelle (VPL) :http://msdn.microsoft.com/en-us/library/bb483047.aspxainsi que des langages modernes tels que C#.Je vous encourage à jeter au moins un œil aux tutoriels.

Mon reproche contre Labview (et Matlab à cet égard) est que si vous envisagez d'intégrer le code dans autre chose que x86 (et Labview dispose d'outils pour mettre les VIs Labview sur ARM), vous devrez alors consacrer autant de puissance au problème. comme vous le pouvez parce que c'est inefficace.

Labview est un excellent outil de prototypage :beaucoup de bibliothèques, des blocs faciles à enchaîner, peut-être un peu difficile à réaliser avec des algorithmes avancés, mais il y a probablement un bloc pour ce que vous voulez faire.Vous pouvez obtenir des fonctionnalités rapidement.Mais si vous pensez pouvoir prendre ce VI et simplement le mettre sur un appareil, vous vous trompez.Par exemple, si vous créez un bloc additionneur dans Labview, vous disposez de deux entrées et d'une sortie.Quelle est l'utilisation de la mémoire pour cela ?Trois variables valant des données ?Deux?En C ou C++, vous savez, car vous pouvez soit écrire z=x+y ou x+=y et vous savez exactement ce que fait votre code et quelle est la situation de la mémoire.L'utilisation de la mémoire peut augmenter rapidement, notamment parce que (comme d'autres l'ont souligné) Labview est hautement parallèle.Soyez donc prêt à utiliser plus de RAM que vous ne le pensiez pour résoudre le problème.Et plus de puissance de traitement.

En bref, Labview est idéal pour le prototypage rapide mais vous perdez trop de contrôle dans d'autres situations.Si vous travaillez avec de grandes quantités de données ou une mémoire/puissance de traitement limitée, utilisez un langage de programmation basé sur du texte afin de pouvoir contrôler ce qui se passe.

Les gens comparent toujours labview avec C++ et jour "oh, labview est de haut niveau et il a tellement de fonctionnalités intégrées, essayez d'acquérir des données en faisant un dfft et en affichant les données, c'est si facile dans labview, essayez-le en C++".

Mythe 1 :Il est difficile de faire quoi que ce soit avec C++ parce que son niveau est si bas et que Labview a déjà implémenté de nombreuses choses.Le problème est que si vous développez un système robotique en C++, vous DEVEZ utiliser des bibliothèques comme opencv , pcl ..ect et vous seriez encore plus intelligent si vous utilisiez un framework logiciel conçu pour construire des systèmes robotiques comme ROS (système d'exploitation de robot).Vous devez donc utiliser un ensemble complet d’outils.En fait, il existe des outils de plus haut niveau disponibles lorsque vous utilisez ROS + python/c++ avec des bibliothèques telles que opencv et pcl.J'ai utilisé la robotique Labview et les algorithmes franchement couramment utilisés comme ICP ne sont pas là et ce n'est pas comme si vous pouviez utiliser facilement d'autres bibliothèques maintenant.

Mythe 2 :Est-il plus facile de comprendre les langages de programmation graphique

Ça dépend de la situation.Lorsque vous codez un algorithme complexe, les éléments graphiques occuperont un espace précieux à l’écran et il sera difficile de comprendre la méthode.Pour comprendre le code Labview, vous devez lire une zone de complexité O(n^2) dans le code que vous venez de lire de haut en bas.

Et si vous aviez des systèmes parallèles.ROS implémente une architecture basée sur des graphiques basée sur les messages des abonnés/éditeurs implémentés à l'aide du rappel et il est assez facile d'avoir plusieurs programmes en cours d'exécution et de communication.La séparation des composants parallèles individuels facilite le débogage.Par exemple, parcourir du code Labview parallèle est un cauchemar car le flux de contrôle saute d'un endroit à un autre.Dans ROS, vous ne dessinez pas explicitement votre architecture comme dans labview, mais vous pouvez toujours la voir en exécutant la commande ros run rqt_graph (qui affichera tous les nœuds connectés)

"L'avenir de la programmation est graphique." (Je le pense?)

J'espère que non, l'implémentation actuelle de labview ne permet pas de coder à l'aide de méthodes textuelles et graphiques.(il existe mathscript, mais c'est incroyablement lent)

Il est difficile de déboguer car vous ne pouvez pas masquer facilement le parallélisme.

Il est difficile de lire le code Labview car vous devez parcourir tellement de zones.

Labview est idéal pour l'acquisition de données et le traitement du signal, mais pas pour la robotique expérimentale, car la plupart des composants de haut niveau tels que SLAM (localisation et cartographie simultanées), l'enregistrement des nuages ​​de points, le traitement des nuages ​​de points, etc. sont manquants.Même s'ils ajoutent ces composants et qu'ils sont faciles à intégrer comme dans ROS, parce que labview est propriétaire et coûteux, ils ne suivront jamais le rythme de la communauté open source.

En résumé, si Labview est l'avenir de la mécatronique, je change de parcours professionnel vers la banque d'investissement...Si je ne peux pas apprécier mon travail, autant gagner de l'argent et prendre une retraite anticipée...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top