Que faut-il préférer : LabVIEW ou le C ?

Que faut-il préférer : LabVIEW ou le C ?
Lequel des deux convient le mieux à cette tâche, étant donné ces contraintes ? Le Responsable Produits LabVIEW livre son analyse

De par le nombre important de ses composants et de ses caractéristiques qui sont semblables au C, le langage de programmation graphique LabVIEW est très souvent comparé au langage procédural.

Que faut-il préférer : LabVIEW ou le C ? « La réponse pourrait aussi bien être 42. Comme le stipule Le Guide du voyageur galactique » estime Simon Hogg, Responsable Produits LabVIEW, qui trouve que « la réponse n'a aucun sens tant que vous ne connaissez pas la question posée ni la nature du problème que vous essayez de résoudre ».

La véritable question que les développeurs devraient se poser est : « lequel des deux convient le mieux à cette tâche, étant donné ces contraintes ? ».

Pour Simon Hogg, « si vous envisagez de construire un système de mesure ou de contrôle, alors le logiciel de conception de systèmes NI LabVIEW est un outil qui peut vous éviter de prendre des risques, de dépenser de l'argent ou toute autre sorte d'inconvénient lié au développement de systèmes à l'aide de langages bas niveau comme le C ». Une réponse qui ne veut pas pour autant dire que « LabVIEW est un meilleur langage de programmation que le C, spécialement quand on sait que des sections entières de LabVIEW sont écrites non seulement en G mais aussi en C et en C++ ».

En fait, ces langages ont des qualités différentes que les programmeurs devraient connaître pour choisir le bon outil pour faire la bonne tâche : « la relation entre LabVIEW et le C s'apparente à celle du pain et de la farine. Si vous voulez faire un sandwich, commencez par prendre du pain. Par contre, si vous voulez préparer un gâteau, commencez avec de la farine. Faire du pain avec de la farine en partant de rien d'autre peut coûter cher et prendre pas mal de temps (surtout si vous voulez juste grignoter), mais s'il s'agit de faire un gâteau, alors la farine s'impose ».

Le C s'adapte mieux aux mises en œuvre de tâches de bas niveau riches en calculs et convient souvent mieux aux applications avec peu de ressources qui doivent être gérées de près, alors que LabVIEW est plus orienté vers l'exécution parallèle, les applications de test, mesure et contrôle de haut niveau.

« LabVIEW et le C sont tous les deux des outils utiles qui, dans les mains d'utilisateurs expérimentés, peuvent résoudre presque n'importe quel problème », conclut Hogg.

Source : Billet de blog de Simon Hogg


Et vous ?

:fleche: Que pensez-vous de cette analyse ? Utilisez-vous LabVIEW ?

Cette petite interview ne m'apprend pas grand chose : si on résume, le papa de ce langage dit que la comparaison entre deux langages ne peut se faire car elle répond à des besoins différents. Mais je pense que toute personne qui a un petit peu étudié l'informatique le sait non ? Je veux dire à la question : "Quel est le meilleur langage de programmation" il n'y a bien sûr aucune réponse : s'il y avait un langage meilleur qu'un autre tout le monde serait sur ce langage et il y en aurait qu'un seul. Néanmoins la comparaison culinaire me parait plutôt bonne pour expliquer cette chose abstraite. Pour discuter un peu de ce langage, je n'en avais jamais entendu parlé. Est-il réellement utilisé ? Pour moi ce langage doit répondre à des objectifs (faire des choses de manières plus graphiques) qu'aucun autre langage ne peut répondre (réellement ? ). A l'heure actuelle, et très subjectivement, créer des langages de programmation n'est pas réellement viable, c'est surtout un délire de geek barbus dans le sens ou la plupart des langages qui ont parfois plusieurs décennies se sont déjà penchés sur ces problèmes. Et si un langage arrive, et qu'il répond à une problématique qui n'est déjà pas résolue, il s'en suit d'autres problèmes que les autres langages ont répondus. En bref, je rejoins ce responsable mais je n'ai aucune envie d'utiliser ce langage.

Je pense qu'il est encore très utilisé aujourd'hui.

Peu de développeur le connaisse car on ne l'utilise généralement pas pour des application "standalone" dont on à l'habitude, mais plus pour la simulation ou lié avec des circuits électroniques, des contrôleurs, surtout pour l'industrie.

Je suis sure à 95% d'avoir déja vue une interface de contrôle de laser industriel faite avec Labview, il faut dire qu'on le reconnait au 1er coups d'œil avec son design très particulier.

Pour moi, le plus grand avantage de Labview, c'est qu'il existe des drivers (VIs) pour une multitude d'appareils de laboratoire ou industriels. De plus de nombreuses bibliothèques, dont certaines gratuites, sont disponibles pour tous les types d'applications.
Il offre aussi la possibilité d'écrire rapidement des applications à des personnes qui sont allergiques à la ligne de code.
Il est d'un accès très facile pour toute personne, un tant soit peu rigoureuse, ne connaissant pas de langage de programmation.

Pour les défaut :
Trop gourmand en puissance de calcul et en mémoire.
Hors de prix, surtout les versions exotiques comme Labview FPGA ou RT ou les bibliothèques d'applications un peu pointues.
Logiciel hautement propriétaire sans aucune concurrence. => NI pratique la politique qui lui convient.
Les meilleurs drivers (VIs) sont écrits pour les produit NI et les produits NI ne fonctionnent qu'avec Nidaq qui est optimisé pour Labview.

Bref, tant qu'une réelle solution concurrente à Labview n'existera pas, je n'utiliserai ce langage qu'avec réticence.

J'ajouterai qu'avec les deux "langages", on peut faire des programmes propres (lisibles par n'importe quel programmeur ayant un minimum de formation dans ledit langage), comme on peut écrire des usines à gaz lentes & boguées jusqu'au fond des octets.

J'utilise LABVIEW et je dois reconnaître que pour construire rapidement des applications pour un laboratoire ou un programme d'acquisition de données,
LABVIEW est plus rapide du fait de ses nombreux modules.
Même si Labview est cher, je trouve quand même que c'est assez intuitif pour les gens ayant fait peu de programmation "textuelle". (Même si cela reste de la programmation)
Comme dit, c'est très utile dans l'industrie mais tout dépend des besoins du programme à créer.
Pour "juste" faire des calculs, le C est plus pratique, mais pour un besoin rapide d'acquisition de valeurs, les modules NI et Labview sont plus avantageux.
C'est vrai qu'il est peu utilisé, mais je pense que l'avantage de Labview réside dans son côté pratique, d'autant que depuis la dernière version, pour peu qu'un module DAQ soit branché sur un ordinateur, si l'on compile le programme labview, l'ordinateur avec le module pourra le lire sans avoir LABVIEW installé.

Quand au C, le temps passé à faire du débug est parfois long et ce langage reste quand même plus compliqué car plus subtil.

Électronicien de formation j'ai bien sûr baigné dans le monde de LabView. Et bien je ne l'utilise plus depuis longtemps tellement je le trouve cher, lourd et atrocement compliqué dés qu'il faut faire des applications avec un peu de calcul intégré. Le soit disant avantage d'avoir des drivers intégrés est surtout lié à la quasi obligation d'acheter le matériel LabView correspondant.
Alors à la grande question de savoir ce que j'utilise et bien la réponse c'est "C" et "FreePascal/Lazarus".

J'utilise LabVIEW depuis 25 ans, par intermittence, car le développement n'est pas mon métier principal, simplement un outil que j'utilise selon mes besoins.

Je suis convaincu de la puissance de LabVIEW, notamment pour des bancs d'essais laboratoire ou de test en production, même s'il est clair que le soft est là pour faire vendre le matériel NI (et réciproquement).

Mais, parallèlement à un effort de "simplification" du développement (qui a donné naissance aux VI express, par exemple), je regrette que pour les besoins plus poussés, NI n'ait pas réussi à garder la même simplicité, et que LabVIEW ressemble alors un peu trop à une usine à gaz.

J'utilise LabVIEW depuis 20 ans mais c'était avant ...
https://forums.ni.com/t5/Discussions...4222052#M35390
https://forums.ni.com/t5/LabVIEW/Lab...2/td-p/4204448
Maintenant il faut que je trouve autre chose :calim2: