programmation graphique?

[flyingman]

Bonjour,

J'aimerais avoir vos opinions concernant les langages de programmation graphique ( type LABview), les secteur ou ils sont performants ( ou nuls).

Merci.
-----

[invite504c296f]

Ta question ne veux rien dire. Un langage de programmation graphique, ca n'existe pas. LAbView n'est que logiciel de traitement du signal avec une configuration en mode graphique. Maintenant si tu cherches des bibliothèques graphiques afin de créer des boîtes de dialogues avec des champs textes ou des boutons, il en existe plusieurs (WxWidgets(gratuit), Qt(payant), GTK+(gratuit), ...), mais derrière tu auras toujours un langage de programmation (C++, Python, Perl, ...) associé afin d'écrire les interactions de ta boite de dialogue (quand on clique sur le bouton, qu'est-ce qui se passe) et les dispositions des widgets. Toutes les librairies proposent à peu près les mêmes widgets (boutons, champs texte, labels, frame, topwindow, onglet, menu, ...) mais tu peux leur ajouter des fonctionnalités via d'autres librairies, comme pour mettre un diagramme ou des widgets exotiques.

[invite665ff684]

Salut,

en effet, comme l'a dit joshua_fr un language de programmation "graphique", çà existe pas. Toutefois, on trouve différentres sortes de languages : procédural, pascal, objet, c, c++, java,etc., et on peut aussi trouver des languages spéciaux, comme le lisp. De là, à trouver un language graphique, je pense que tu veux dire soit un language à interface graphique, comme Visual : Basic, C++, Java, ou peut-êre un language dédié au graphisme, tel la programmation de directx, ou de démos, voire de moteur 3d, mais là encore, il faut utiliser un language, qui n'a pas de dénomination "graphique"...

@+

[flyingman]

Non, vraiment ca existe allez voir sur le site de Nationnal Instrument (ni.com) vous verrez LABVIEW et c'est entierement graphique (et je ne confond pas avec un langage quelquonc avec un editeur d'IHM !( typt VB)

Merci.

[A voir en vidéo sur Futura]

[invite665ff684]

Autant pour moi, alors. Je suis allé y jeter un coup d'oeil. Pur moi cela ressemble à du Delphi, et NI le dit : a environnement graphical, et non un language de programmation graphique. Toutefois, cela réduit considérablement les lignes de coeds, et les "boutons", composants additionels, sont facilement intégrable. L'interface est pas mal, et une bonne ergonomie est présente.

Plus d'infos, et des screen shots ici : http://zone.ni.com/devzone/conceptd....256F480065722D

Merci, je connaissais pas ce produit.

[erik]

Salut,

D'apres ce que j'ai pu comprendre sur le site de Nationnal Instrument, Labview, est juste un machin qui permet de faire de l'analyse de données. Difficile d'appeler ça un langage de programmation, du moins ce n'est pas un langage de programmation au sens généraliste du terme. Labview est destiné (apparemment) à un domaine d'application Trés spécifique, à l'opposé d'un langage (du moins à mon sens) qui doit te permettre de résoudre une vaste gamme de probleme.
En c (ou c++) par exemple tu peux aussi bien coder un programme de jeux, un tableur, un OS, un truc qui te fait de l'analyse de données, n'importe quoi sous windows, un super truc intelligent sous linux ....

Erik

[flyingman]

Décidement ... c'est pas gagné !

Je répète ce que dit NI à propos de LABVIEW : C'est un "langage" ( ou interface de programation) qui permet de faire TOUS types de programmes! Comme du C++ ! ( oui meme de l'OO!).

MErci.

[invite665ff684]

Décidement ... c'est pas gagné !

Je répète ce que dit NI à propos de LABVIEW : C'est un "langage" ( ou interface de programation) qui permet de faire TOUS types de programmes! Comme du C++ ! ( oui meme de l'OO!).

MErci.

Qu'est ce qui n'est pas gagné ? tu viens de répéter ce que je viens de dire. On reste d'accord sur le fait qu'un language de programmation graphique n'existe pas sous ce nom.

[invite504c296f]

Bof, il a l'air très puissant niveau conception d'interface pour du traitement de signal, mais quand je vois qu'il faut 5 pages au créateur e labview pour dire que, oui, mais peut-être que vous ne le voyais pas, mais alors si, enfin vous pouvez l'utiliser pour faire de la programmation, mais alors pas comme vous l'entendez, patati patata. En fait Non. Ce n'est pas un langage de programmation, c'est encore plus que ça. Je n'en vois vraiment pas l'interet. Tu n'auras jamais la puissance d'un langage écrit quand tu te sers d'un truc qui te pond du code quand tu clique sur des boutons, il y aura toujours un endroit ou il te faudra aller dans le code.

[zoup1]

Je confirme que LabView est bel et bien un langage de programmation... Pour être plus précis il me semble que le language lui-même s'appelle le G language. (attention je crois qu'il y a plusieurs trucs qui s'appellent ainsi).

On peut définir des entrés, des sorties, des opérations, des structures de controles... bref, c'est un language.

Il est vrai qu'il est plutot orienté traitement de données, ce veut dire en particulier que sont interface sert principalement à déssiner des tableaux qui ressemblent à des facesa avant de vrais instruments de mesure, et qu'il existe un grand nombre de librairies orientées traitement de données pour labView.

C'est une programmation modulaire. Pour laquelle on définit des VIs (virtuals instruments). Chaque VI est définie par ses entrées et ses sorties et les relations qui existent entres-elles. Chaque VI est réutilisable ensuite en tant que tel pour inclure dans un niveau VI, comme un composant sur un circuit intégré.

A mon sens, l'idée, qui ne date pas d'hier quand même est extrèmement séduisante. En pratique elle permet de développer extrèmement rapidement des applications relativement complexes avec une interface et une interactivité soignée.

Cependant cette solution a tendance a enfermer dans un marché, (celui de National Instrument) et est relativement couteuse, tant au niveau de logiciel lui-même, qu'au niveau du matériel -même si d'autres constructeurs proposent des cartes d'acquisition qui sont compatibles avec LabView.

Pour ma part, j'ai toujours préféré faire du code avec un langage de programmation plus standard, (C par exemple). Labview gère en fait des flux d'informations et il n'est pas toujours très simple de savoir comment ses flux sont gérés et d'avoir un contrôle sur eux. La localité des variables est aussi un truc qui peut parfois devenir un peu difficile. La synchronisation d'acquisition n'est pas toujours très simple à réaliser.

Note, par ailleurs il est également possible de définir des VI dont la partie traitement est écrite dans un autre langage que le G. Ceci permet d'améliorer les performances pour les tâches gourmandes en temps de calcul.

[invitefa385fb5]

Hello,
Juste qques confirmations en tant que devellopeur Labview,C ... :
LV est un des rare langage graphique créé a l'origine pour l'intrumentation: Pour resumer et par exemple, avec la carte adequate, il est capable de remplacer un oscilloscope à 50 voies avec affichage et traitement.
Il est tres utilisé en industrie ( PSA, RENAULT, Thales, Philips, ...) par son utilisation tres simple qui permet de devellopper tres rapidement ( je peux developper une calculette evoluée en 5 minutes ...).
Il a evidemment qques inconvenients comme par exemple l'obligation pour un programme d'avoir LV ou tout au moins son moteur.
Sinon, moi, j'aime bien

[invite665ff684]

Il a evidemment qques inconvenients comme par exemple l'obligation pour un programme d'avoir LV ou tout au moins son moteur.
Sinon, moi, j'aime bien

Oh tu sais, ce n'est plus un inconvénient, maintenant que cette pratique est devenue courante. Visual,toute la série, Delphi, Java, Python, il faut aussi la présence du "moteur".

Par contre, toi qui développe, tu utilises aussi cette notion de "language graphique"...

[invitee17aeca5]

en qbasic ,on peu arriver à des résultas apréciables (voir ici )
et le blitz3D ,2D ,c pas mal non plus

[invite665ff684]

C'est pas pour dire, mais le Qbasic est vieux comme le monde, et l'évolution des languages l'a avantageusement remplacé.

[zoup1]

Excuse moi Tix, mais je crois que tu es complètement hors sujet...

[invite42dac78c]

HORREUR !!

"Un langage de programmation graphique, ca n'existe pas." => euh... c'est pas que ça n'existe pas, mais que ça ne veut rien dire : tu programme ne mode graphique, ou tu cré un programme graphique ???

" Qt(payant),"=> HORREUR !! QT=lib KDE et j'ai jamais payé KDE => payant pour windows !!! Gratuit pour linux !!!

[flyingman]

Tout d'abord je voudrais recentrer le debat: la question originelle etait de savoir si la programmation graphique était bien ou pas( pour creer des logiciels), et non pas de savoir si on pouvait appeller cela( cette facon de concevoir des logiciels) un "langage" !!!!!!!
Sérieusement on s'en fou ! La seule chose que je vois, c'est qu'on peut generer du code machine aussi élaboré qu'avec un "vrai" langage!

Alors je ne voudrais pas jetter de l'huile sur le feu, mais moi je ne vois pas pourquoi on ne pourrait pas proceder de la sorte !
Je prendrais comme example le langage "normale", je m'explique:
Pour communiquer, il existe plusieurs sorte de langage: la parole, l'ecrit et ......celui des signes! Peut on dire que le "langage" des signes n'en est pas un?

Moi je pense que nous avons à faire à une gueguerre de clochers!

Amicalement.

[invite665ff684]

Je prendrais comme example le langage "normale", je m'explique:
Pour communiquer, il existe plusieurs sorte de langage: la parole, l'ecrit et ......celui des signes! Peut on dire que le "langage" des signes n'en est pas un?

Le language des signes est un language à part entière. Aucune norme existe pour qualifier ce que doit être un language humain. Chaque peuple a le sien. Toutefois, pour recentrer le débat, labview est identique à du Delphi, ou Visual, mais de façon plus spécialisée. LabView consiste à du gagne-temps, et c'est tant mieux. Il est vrai que el code produit ne sera peut-être pas optimisé, mais il n'en, reste pas moins une bonne plateforme de développement pour des applications spécifiques. Si c'est pour faire une calculette scientifique, autant passer ton chemin.

et désolé pour avoir trop négocié le nom de LabView.

@+

[invite504c296f]

" Qt(payant),"=> HORREUR !! QT=lib KDE et j'ai jamais payé KDE => payant pour windows !!! Gratuit pour linux !!!

Qt est aussi payant sous Linux pour les appli commerciales.
Pour LabView, ok on va pas épiloguer sur 30 posts pour savoir si c'est un langage ou pas, mais je serai interessé de savoir pour quels types d'applications ce logiciel vaut-il le coup?

[invite665ff684]

Qt est aussi payant sous Linux pour les appli commerciales.
Pour LabView, ok on va pas épiloguer sur 30 posts pour savoir si c'est un langage ou pas, mais je serai interessé de savoir pour quels types d'applications ce logiciel vaut-il le coup?

Je confirme que QT est payant, à partir du moment où tu utilises ses bibliothèques dans un but commercial. licence GPL si je ne me trompe.

Quand à labview, les applications sont multiples, mais sa principales référence demeure dans les mesures scientifiques. La productivité est croissante, du fait du laps de temps gagné avec LabView. De plus, cet environnement a reçu un award 2004.

Pour plus de renseignements sur ses applications, vous pouvez jeter un oeil ici :

labview_application

On y apprend des application médicales, cardiovasculaires, mais aussi dans le domaine des transports, ferroviaires, et autres.

@+

[invite42dac78c]

Si tu explique ce que c'est qu'un language graphique, je pourais pe adérer à ton idée....

Perso, je programme ne PHP ça fait un joli truc graphique (cf HTML et GD)

et en C++ ce qui fait des programmes non graphique si on ne rajoute pas de lib (et je n'en rajoute pas)

Pour ce qui est de l'ide, j'utilise Kwrite, programme mode graphique....

ce qui n'est pas un language...

[zoup1]

Si tu explique ce que c'est qu'un language graphique, je pourais pe adérer à ton idée....

Perso, je programme ne PHP ça fait un joli truc graphique (cf HTML et GD)

et en C++ ce qui fait des programmes non graphique si on ne rajoute pas de lib (et je n'en rajoute pas)

Pour ce qui est de l'ide, j'utilise Kwrite, programme mode graphique....

ce qui n'est pas un language...

Ce dont il est question dans ce fil est d'un language de programmation graphique, pas d'un language pour faire des graphiques.

Le principe est le suivant, au lieu d'écrire des lignes de codes comme en PHP ou en C++, tu construis ton programme graphiquement en utilsant des opérateurs et en définissant les relations qui existent entre ces opérateurs. Cela ce fait a peu près comme on le fait pour dessiner un circuit électronique. On utilise des fils pour relier les sorties d'un objet aux sorties de l'autre.

Va voir le site de National Instrument pour te rendre compte de ce à quoi ressemble Labview.

[invite665ff684]

Ce dont il est question dans ce fil est d'un language de programmation graphique, pas d'un language pour faire des graphiques.

Le principe est le suivant, au lieu d'écrire des lignes de codes comme en PHP ou en C++, tu construis ton programme graphiquement en utilsant des opérateurs et en définissant les relations qui existent entre ces opérateurs. Cela ce fait a peu près comme on le fait pour dessiner un circuit électronique. On utilise des fils pour relier les sorties d'un objet aux sorties de l'autre.

Va voir le site de National Instrument pour te rendre compte de ce à quoi ressemble Labview.

C'est pas pour te decevoir, mais tu n'apportes rien de nouveau à ce que j'ai déjà souligné, en l'occurence une ressemblance à du Visual ...

[invitefa385fb5]

Hello,

voici un exemple d'une partie de diagramme ( cad le "code" ) d'une fonction LV qui compare une chaine de caractere à un tableaux d'entier ascii avec caracteres jokers et autres ...

[zoup1]

C'est pas pour te decevoir, mais tu n'apportes rien de nouveau à ce que j'ai déjà souligné, en l'occurence une ressemblance à du Visual ...

Si cela me decoit car je pense que cela n'a rien à voir !!! (note bien que cette notion de visual m'est relativement etrangère et rasssemble pour moi un ensemble de machin disparate que Microsoft regroupe sous un vocable "Visual" comme si "Visual" était synonyme de IDE).

Tu trouve que le diagramme de scyrius ressemble à du Visual je ne sais pas quoi ?

[erik]

Bon,
Bien que dubitatif au départ (voir mon message sur la première page), y'a pas de doute c'est bien un lagage de programmation graphique! Je ne savais vraimment pas qu'un truc comme ça pouvait exister.
Alors du coup une question à ceux qui connaisse : est il facile de débugger et/ou de reprendre un code qui ressemble à ce qu'à présenté scyrius ?

Erik

[zoup1]

Oui et non,

Oui parce qu'il existe la possibilité de faire des modules indépendants qui font une tache bien précise (un VI). Ensuite tu peux les réutiliser. Oui parce que tu disposes d'outils graphique qui te permettent de visualiser les flux de données dans ton diagramme et de faire du déboguage pas à pas.

Non, parce que si tes (VI) ne sont pas bien déboggué, il n'est pas toujours très simple de s'y retrouver. Non parce que... comme généralement tu utilises ce language pour faire de l'acquisition, tu es souvent confronté à des problèmes de synchronisation qui ne sont pas toujours très simples à gérer. Non parce que les structures de données et en particulier la localité (ou plutot la porté) des variables est à mon sens pas toujours très claire (mais c'est sans doute une preuve de mon ignorance en la matière).

En fait, c'est un peu comme partout, si tu programme bien, c'est facile de débogguer si tu programmes comme un cochon, tu risques d'avoir les plus grandes peines du monde à traquer le bug.
Comme le mode de programmation est très largement différent d'un language traditionnel, il est difficile de faire des comparaisons....

Mais en terme de conclusion, je dirais plutot assez facile à débogguer...

[invite665ff684]

Pour zoup1, Visual n'est pas une dénomination propre à Microsft, voir Visual Delphi, pour plus de clarté.
Quoiqu'il en soit, ce que représente le code joint par scyrius ressemble plus à un schéma électronique. J'aimerais bien voir maintenant le code généré, et nous verrons s'il est facile de débugger comme tu le dis zoup1

[zoup1]

J'aimerais bien voir maintenant le code généré, et nous verrons s'il est facile de débugger

Le diagramme est le code !!!! Il n'y a pas de code généré.

Bon pour être exact on peut compiler les VI... mais c'est une compilation directe, sans passage par un code intermédiaire...

[invite665ff684]

Eh ben, c'est dingue. J'ai jamais vu de programmation, sans ligne de code. Mais en effet, je confirme que cela reste assez facile à debugger, si le diagramme est "le programme".