Bonjour,
j'aimerais connaitre votre avis sur les langages / frameworks les mieux adaptés au développement d'IHM (sous Windows ainsi que sous Unix/Linux) dans le monde de l'informatique industrielle.
A titre d'exemple, nous utilisons actuellement essentiellement les MFC sous Windows et X11/Motif sous Unix.
Quid de .Net (2.0), WPF, Qt, ... ?
Que peuvent par exemple utiliser les développeurs de progiciels ?
Je vous remercie d'avance pour vos avis éclairés !!!
Tout dépend ce que l'on veut faire mais globalement ->
-> Lorsqu'on développe sur plusioeurs plate-forme le mieux est quand même de choisir du portable.
Développer en MFC est une atrocité et ce n'est pas portable.
Développer en X11 est uen atrocité et ce n'est pas portable.
Les deux sont donc doublement coûteux: longs temps de développement et en plus faut le faire deux fois. A bannir :evil:
Pas portable pour l'instant.
Qt est excellent.
On peut développer relativement vite avec, même très vite pour du C++, et c'est remarquablement portable.
Maintenant il y a la question du temps de développement. Faut il obligatoirement coder l'IHM en C++ :?:
- Si non: alors on prend un langage de script intelligent comme Python et une librairie "wrapper" d"un toolkit tel que QT ou WxWidgets. Respectivement PyQT et wxPython. Ensuite on interface quasi automatiquement l'IHM avec les routines de calculs ou je ne sais quoi écrites en C++, au moyen d'un outil comme SWIG.
Réduction garantie du temps de développement: facteur 5 à 10 au minimum
- Si oui. Alors on prend QUAND MEME un PyQT ou wxPython pour prototyper l'IHM. Ce qui permet de gagner un temps fou pour le développement (pas de compilation). Quand c'est prototypé on recode en C++.
Réduction garantie du temps de développemet 3 à 5 au minimum. Plus que cela si le client demande de nombreuses modifications de l'interface ;)
Et quand je dis réduction, je sais de quoi je parle, puisque je me base sur mon expérience.
Mais faut-il coder en C++ ?
Bon on va pas coder en Java quand même. Mais à notre triste époque on oublie des outils d'une puissance formidable comme Lisp. Avec Lisp on a:
- performance à l'exécution très proche de C/C++.
- d'une gestion automatique de la mémoire.
- portabilité parfaite.
- un langage adapté aux applis industrielles.
- Langage standardisé y compris la librairie graphique (CLIM). Lisp à ma connaissance est le seul langage entièrement standardisé.
- Modèle de développement incrémental qui permet (c'est avéré) de coder de 5 à 10 fois plus vite qu'en Java ou C++, au bas mot.
- un langage simple parfaitement adapté au développement d'applications complexes. L'expérience montre que plus l'application est complexe, plus Lisp révèle sa valeur.
- Des outils de développement commerciaux (IDE) respectant le standard et existant à l'identique sur les plates-formes (Allegro ou Lispworks)
Oui je sais, Lisp on y pense plus de nos jours, on le considère comme obsolète. A tort. Lisp est très en avance sur son temps dans tous les compartiments du jeu du développement. Mais bon je ne sais pas si je vais convraincre là :D
Tout d'abord merci pour ta Réponse :lol:, je n'en attendais pas moins de ta part.
Pour en revenir ma question initiale, si je réduis les degrés de liberté (je parle au mécanicien là :wink: ) en ajoutant les contraintes suivantes:
pérennité, cout+accès à la formation, et tout l'historique de nos librairies en C auxquelles on veut toucher le moins possible ...
que devient ta réponse ?
:lol:
Strictement la même. Je dirais même plus: la même d'autant plus.
Car si je ne l'ai pas dit, ces contraintes sont toujours présentes dans mon esprit, parce que toujours présentes dans tous mes développements :) Et je ne pense pas être un cas isolé. :D
Appeler du C depuis Lisp est très simple. Depuis un langage de script, également grâce à Swig.
Se former à Python n'est rien du tout. 2 jours et ça le fait.
Se former à Lisp, en dépit des idées reçues, c'est quasiment rien.
Dès que tu as compris que:
(+ 1 2 3)
est évalué à 6, tu as compris 99% de Lisp. Et le reste est aussi facile :lol:
La mode java passera un jour. C, C++, Lisp, Python resteront. Aucun doute
Bonjour.
je vais tempérer un peu l'élan d'enthousiasme de notre ami geek, capable de vendre n'importe quel langage :wink:
Oublie le Lisp. C'est sympa... peut-être. L'assembleur aussi c'était sympa, on a jamais fait plus rapide, pourtant personne ne te diras de coder un IHM en assembleur - ni même le programme de vol d'une fusée, et là pourtant, la vitesse c'est important. D'ailleurs ça ne se fait pas non plus en Lisp...
Pour le reste, je le rejoins d'une certaine manière. Mais je vais poser le problème autrement.
D'une part, tu as eds parties "mêtiers" de code écrites en C. Bien. d'autre part tu veux un IHM sympa, pas trop difficile à développer et à maintenir. Ok.
Le mieux selon moi (et mon expérience de la chose) c'est de décoreller les deux. Cela s'obtient avec l'aide d'un langage de script (TCL, Python, Perl, Php,...)
Phase 1 : définir les points d'entrée des fonctions mêtiers (commandes, requêtes, etc...)
Phase 2 : Une petite surcouche pour interagir avec ces points d'entrée à partir du langage de script (commande + paramètres + valeur de retour)
Phase 3 : Codage d'un IHM dont les éléments lancent des commandes de script ou lise les retours des requètes de script.
Tout ceci est en gros compatible avec les avis précédents, cela ajoute juste une méthode de travail, dont l'intérêt est de pouvoir tester séparement l'IHM et le code mêtier, de pouvoir écrire des macos, des scripts d'automatisation et/ou de configuration, etc...
Quant à la technologie, tu as le choix. Moi je te propose :
Tcl/Tk
Perl/Tk
Python/Tk
Sinon, si tu veux faire vraiment du code à compiler pour l'IHM, regarde du côté de "Fox toolkit" (http://www.fox-toolkit.org/).
Qt, je ne sais pas pourquoi, je n'aime pas vraiment. Peut-être parce que c'est partiellement commercial ?
Je veux croire que c'est une plaisanterie et non pas une énorme ânerie.
Là vraiment je ne vois pas le rapport avec la choucroute. Ni même le bien fondé de l'argumentation. Apprends donc que coder une IHM en Lisp est au moins aussi rapide qu'avec un langage de script. A croire que tu ne l'as jamais fait pour écrire une phrase aussi .... (je m'auto-censure, là, c'est sans doute plus sage :) ). Mais cette argumentation est extrêment décevante venant de toi.
En plus je tiens à la redire, le toolkit graphique de LISP est *garanti* par un standard, ce qui est un argument énorme quand le posteur initial s'inquiète de la portabilité ainsi que de la pérénité. Quel autre langage offre un toolkit graphique standardisé au fait :?:
Tiens c'est ce que je croyais avoir exprimé. :shock:
Pas besoin de surchouche. Avec un outil comme SWIG la surcouche est générée automatiquement. Ou alors quelque chose m'a échappé.
Mais surcouche ou pas, en quoi poses tu le problème autrement ? :shock: J'aimerais comprendre.
Autant je suis d'accord avec le langage de script, d'autant plus d'accord que c'est moi qui l'a dit le premier (na :!:) TK avec tout le bien que j'en pense est maintenant très largement surclassé par un PyQT ou ou un wxPython. Mais alors vraiment très très largement. Comme on dit de nos jours, il n'y a pas photo.
Exemple très simple. Est il possible d'imprimer avec Tk ? Non... Avec wxPython ou PyQT oui. Et il me semble que pour une IHM rien que cet argument suffit à éliminer Tk.
On ne sait pas pourquoi en effet.
Et en quoi est-ce un contre argument si c'est bon et si c'est pour un développement commercial ?
Encore moi, j'ai pas pu me retenir :D
Il n'y a vraiment que sur un forum français qu'on peut voir ça.
Lisp est pourtant bien vivant dans l'industrie.
Voici à ce titre une page intéressante sur le site d'un éditeur américain d'un IDE commercial Lisp. (J'en connais au moins d'eux autres (Corman et Lispworks) ce qui en soit montre que Lisp est loin d'être mort. ;) )
http://www.franz.com/success/
France Telecom a développé il y a quelque temps un gros truc en Lisp
http://www.franz.com/success/customer_apps/telecom/francetelecom.lhtml
On oublie Lisp ? Peut être. Mais quand il s'agit de développer des applications très complexes ou soumises à des charges terribles, ou de tirer parti d'un modèle de développement incrémental ce n'est sûrement pas Java ou TCL qui vont le faire.
Alors finalement on adopte le bon vieux Lisp (ou Erlang pour faire allusion à une discussion récente sur ce forum)
"Oublie le Lisp" ..
Tss tss.
Mais qu'elle misère de lire ça :cry: :cry: :cry: :cry:
Désolé si je ne suis pas d'accord avec toi.
Pour faire court, il y a des langages "naturels" et d'autres pas. La logique d'écriture en C, C++,etc... est la même, cohérente avec la façon naturelle de penser des humains.
D'autres langages sont issus de cerveaux géniaux peut-être, mais hors de la sphère de compréhension de l'humain normal.
Et alors ?
Hé bien, quand il s'agit de travailler - professionellement - on peut avoir deux approches, que je vois toutes les deux tous les jours :
1- Même si ce n'est pas optimum, j'utilise des techniques que tout le monde peut reprendre et comprendre, afin d'assurer une pérennité et une évolutivité à mon travail, ou
2- Je fais le maximum pour utiliser des moyens que je suis seul à comprendre afin de me rendre indispensable et de bloquer toute tentative d'ouverture de mon code.
Utiliser le Lisp (et encore désolé, Erlang) dans une activité rémunérée relève du second cas de figure.
Pour comprendre le Lisp (ou le Postscript), il faut l'esprit tordu. J'y arrive pour avoir appris à programmer sur des HP en notation polonaise inverse mais c'est à des années lumières de ce que sait faire un jeune actuellement - tout comme l'assembleur, d'où mon parallèle précédent.
Oui, il y a certainement des gens qui utilisent Lisp, d'autres Prolog, Fortran ou DOS... Mais ce sont des dinosaures !
Ou alors des nostalgiques, ou des geeks comme moi qui cherchent le frisson de l'exotisme...
Mais jamais, jamais je ne laisserais faire des travaux en Lisp dans mon secteur. le type qui me proposerais ça pourrait se trouver un autre job fissa !
Ensuite, ce buzz sur la charge... Pour Java, c'est vrai, ça ne tient pas. Mais que ce soit Perl, Php, Tcl, C, C++ ou d'autres, ils tiennent le coup.
De plus, dans le cas qui nous est posé, c'est sans objet : les IHMs n'ont pas besoin de temps de réaction à la micro-seconde - sauf pour les animations 3D.
Bon j'arrête là. Parce que les langages exotiques c'est sympa pour se marrer entre programmeur, pas pour des réalisations pros.
Voilà qui explique sans doute pourquoi on trouve plus de bug dans du code C ou C++ que dans du code Lisp. :lol:
Sans blague ?
:lol:
Ainsi donc tu as abandonné Erlang ;)
De même que d'avoir proposé Php pour répondre à la question de l'IHM était assez marrant.
Vraiment je suis très déçu. Tu critiques Lisp, d'accord c'est ton droit. Mais il est évident pour moi que tu ne le connais pas (ce que j'appelle connaître et qui est un peu plus que d'avoir codé un Hello World), et là c'est moins bien. Au moins quand je critique Java je pense d'un autre côté avoir montré que je le maîtrise un peu. Tu critiques indirectement Prolog. Domamge. Un grand langage aussi celui là.
Bon j'arrête là aussi.
Au fait cette Gentoo tu as réussi à l'installer ? :lol:
Oui.
3 jours de compilation... J'ai obtenu X11 et Gnome. C'est maigre...
Il faudrait que je réessaye avec mon PC de développement qui est un peu plus rapide mais comme je m'en sert plus souvent qu'une fois tous les trois jours, c'et mal parti.
Quant à Erlang, non, je n'abandonne pas. Je n'ai simplement pas eu le temps de travailler sur mon jeu - et en plus j'essaie de voir en parallèle comment le faire en C++ et en Erlang. Déjà je peux dire que pour moi ce langage fait partie de la catégorie "langage geek" intéressant, mais à ne pas utiliser de manière pro pour les raisons évoquées plus haut (encore que, pour certaines plate-formes... mais non, car personne ne sait s'en servir au boulot).
Ceci dit, je ne suis pas omniscient, je ne parle que pour le domaine dans lequel je travaille.
lol :lol:
lol :lol:
On se demande bien qu'elle idée ils ont eu chez Ericsson de créer spécialement le langage pour piloter des routeurs téléphoniques ? Quand je pense qu'ils avaient TCL sous la main, faut quand même qu'ils soient bêbêtes :)
Argument d'autant plus désespérant que je ne doute pas qu'il soit vrai. Personne ne sait, et surtout personne ne veut savoir.... quelle pitié. :cry:
Bon dès que j'ai 5 mn je poste un message pour tenter d'élever le débat :)
Le dinosaure que je suis va donc tenter d'élever un peu le débat. :)
Et si ça se trouve on va conclure que le dinosaure n'est pas là on l'on croyait.
Alors voyons:
Il n'en est rien. Et c'est vraiment s'abuser soi même que de dire ça.
Prenons d'abord l'assembleur, puisqu'il est venu dans la discussion. Est-ce seulement un langage ? Même pas. On comprendra pourquoi un peu plus loin :) Peut être que le macro assembleur est-il un balbutiement de langage ? Enfin bref comment code-t-on en assembleur ? La pensée est soumise totalement, incontournablement, à la dictature de la machine. Les valeurs contenues dans les registres et les limites qui vont avec, l'ordre d'exécution des instructions, la mémoire, la pile. Bref tout de la machine, dans les moindres détails, impose sa loi au programmeur.
Est-ce naturel ? Je ne le crois pas. Si ça l'était tant que cela, personne n'aurait eu l'idée de créer C. Pourquoi le langage C ? Pour continuer à piloter (je ne dis pas programmer) la machine, mais déjà avec un meilleur niveau d'abstraction, un début d'affranchissement des contraintes imposées par le système, afin de s'exprimer plus librement. Ainsi peut-on grâce à C appeler une routine, sans se préoccuper de restaurer la pile, gros progrès :)
Peut être bien que l'abstraction n'est pas encore suffisante puisqu'on a créé C++, qui apporte plus en ce domaine. Avons nous là un langage naturel ? Je ne pense pas. En C++ on est toujours sous la houlette de la machine. Et même avec lui programmer est extrêmement répétitif et contraignant.
Programmer avec un tel langage est aussi naturel que de conduire sa voiture en ayant en permanence conscience des mouvements des soupapes dans le moteur et en veillant constamment à éviter qu'elles ne s'entrechoquent :lol:
Voyons maintenant en quoi la pensée du reptile et de l'homme diffèrent. Le reptile pense-t-il d'abord ? Je n'en sais rien. Mais à le regarder on dirait plutôt qu'il ne fait qu'accomplir des tâches répétitives trop beaucoup de réflexion.
Qu'est ce donc alors que la pensée de l'homme, la particularité de sa pensée naturelle ? C'est de concevoir. De formuler des concepts, des idées, de les assembler pour finalement en produire d'autres. Des concepts très élevés, très abstrait, loin du détail et de ses limitations. Si je veux pouvoir exprimer, coder des concepts naturellement, il me faut un langage qui ai le niveau d'abstraction suffisant. Je prends un exemple: l'ensemble des entiers naturels. J'ai le concept en tête. Mais l'ensemble est infini. Comment exprimer cela dans un programme ? En Assembleur, en C en C++, en Java ;) je ne peux pas.
Par contre si je prends Haskell (je prends celui là parce que c'est un récent (1998) hein, pas un vieux comme lisp ;) ) c'est différent. Haskell est un langage fonctionnel non-strict (évalutation paresseuse). Ce langage de pointe (donc forcément pas connu en France, moins encore utilisé... en France...) abstrait totalement de la machine. Ainsi avec Haskell, le codeur n'a même pas à penser à l'ordre d'exécution du programme. Le programme est totalement déclaratif et permet même de déclarer des types infinis. Je veux coder le concept de l'ensemble des entiers naturel ? Une ligne de code le fait:
Je peux quand je veux accéder à une partie des éléments de l'ensemble (magie de l'évaluation paresseuse). Je n'ai jamais à penser que la mémoire de la machine est trop réduit pour contenir l'ensemble. Au contraire je peux passer cet ensemble infini en argument à une fonction, je peux déclarer toujours en une ligne (donc je vous fait grâce :) ) un sous-ensemble des entiers naturels pairs.
Bref à chaque ligne de code je manipule des concepts, des idées de façon naturelle, car tels que je les pense, sans devoir penser à les faire entrer au chausse-pied dans une puce de silicium. Voilà ce qu'est la programmation naturelle selon moi. Exprimer les concepts à un (très) haut niveau d'abstraction où la machine s'efface, disparaît et où la créativité, l'efficacité s'expriment. Celui qui code en C peut il même approcher de la chose. Jamais....
Revenons à Lisp. Langage à très haut niveau abstraction, il permet de construire des applications industrielles, par assemblage de concepts, avec une facilité, une concision et une expressivité du code que les codeurs "naturels" C/C++/Java/Perl/TCL ne peuvent même pas imaginer. Je ne vais pas rentrer dans le détail des explications. D'autres l'on fait bien avant moi, et bien mieux que je ne pourrais jamais le faire. A ceux que la question intéresse, je recommande le remarquable ouvrage de Paul Graham "On Lisp" que l'on peut télécharger ici: http://www.paulgraham.com/onlisp.html. Malheureusement c'est en anglais, mais sa lecture ouvre des horizons.
Alors quand on me sort ça:
Dans le contexte de la discussion, je le prends pour un compliment extrêmement flatteur. Je me dis que je pense mon informatique. Je me dis que j'ai la chance de coder de façon sûre en 10 lignes ce que d'autres ne parviennent pas à coder en 10000, je me dis que du coup, professionnellement j'ai un net avantage (bon pas souvent exploité en France mais qu'importe, il n'y a pas que la France ;) ), Je me dis que quand je code 10 lignes au lieu de 10000 , il me reste du temps pour faire autre chose, je me dis que j'ai de la chance de ne pas coder, encore et toujours, les mêmes 10000 lignes le nez dans le guidon. Je caresse l'idée séduisante de me sentir plus le maître de la machine que son esclave. Et mieux que cela, de la triste condition de reptile condamné à la répétition de tâches sans intérêt, je me sens promu au grade d'Homo Sapiens. C'est Byzance. :lol:
Déjà, programmer est en soi un acte de dinosaure... Maintenant on clique et quelque part la machine fait le reste... On ne sait pas vraiment quoi mais tant pis.
C'est bien. Dans le principe c'est même sûrement vrai. En fait c'est ce que j'apprécie dans un language : sa facilité d'abstraction.
Mais je ne suivrais pas dans ce débat qui n'est pas le bon. Le problème n'est pas de trouver l'oiseau rare génial - sinon on aurait chacun écrit notre propre language de programmation en raison du phénomène de rejet "NIH" (Not Invented Here) - mais de trouver l'outil permettant de programmer confortablement, sérieusement et sûrement.
Et là, il faut un language répandu, connu, suivi et enseigné.
Peut-être. Mais je ne crois pas. J'ai fait du Lisp, heureusement pas longtemps. Je ne vois pas ce qu'il y a d'industriel à écrire du code dont un caractère sur deux est une parenthèse.
En fait, personnellement, je préfère (je crois déjà l'avoir dit) avoir à maintenir 1000 lignes de code compréhensible que 10 lignes illisibles.
Il te reste le temps de rédiger les vingt pages de doc nécessaires pour que quelqu'un d'autre que toi puisse maintenir tes dix lignes, peut-être ? :D
Là, on aborde un autre sujet qui me tient à coeur : la réutilisation. Mon credo est qu'il ne faut pas réécrire du code existant, il faut dès que possible en réaliser une version réutilisable et le plus générique possible (package, classe, bibliothèques, jar, ... en fonction du language). Ensuite, on appelle les points d'entrée - et ça prend moins de 10 lignes ;)
Donc : Intellectuellement, je te donne raison - sauf pour le Lisp, il y a des limites à la décence des grammaires, quand même - mais pour la pratique, je pense qu'il y a des compromis, le premier étant de tenir compte de l'environnement ( personnels et leurs connaissances, historique des projets passés, perénnité des matériels et des applications, ... )
Ah oui ? Et quelle facilité d'abstraction il y a dans Java ou TCL en regard d'un Haskell ou d'un Lisp ? Je suis curieux de savoir ?
Je suis vraiment navré de le dire aussi brutalement. En tout cas sache bien que mon intention n'est pas de te froisser, mais là ce que tu écris prouve simplement que tu ne connais que ce que tu appelles tes "langages naturels" et pas les autres. Je dis connaître, pas avoir vu une fois quelque part.
Je ne voudrais pas avoir l'air de contredire systématiquement, mais quand même si Lisp ne rentre pas dans cette catégorie alors je me demande lequel y entre.
Suivi ? :lol: C'est vraiment un gag. Lisp est sans doute le premier langage standardisé et complètement implémenté en fonction de ce standard (ce que même C++ n'est pas, quand à Java, ou TCL où diable est le standard ? )
Pas répandu. Autre gag vraiment. Pas répandu en France oui.
Mais s'il n'était pas répandu du tout, comment autant d'éditeurs commerciaux pourraient ils en vivre ? Tiens au fait qu'est-ce que me racontais l'autre jour à propos des difficulté de la société qui édite ton compilateur ADA ? ;)
Je crois que la situation est bien résumée là. Tu ignores tout de Lisp.
Maintenant je ne saisis pas pourquoi sur un forum tu te lances à critiquer si fortement un langage que tu connais si peu et à argumenter qu'on ne peut pas sans servir dans l'industrie uniquement parce que tu ne l'a jamais fait.
Que tu ne l'aimes pas, je peux le comprendre, que tu insistes à dire qu'on ne peux pas s'en servir industriellement sans autre argument qu'une boutade et en montrant que tu es mal à l'aise avec, c'est un peu léger.
Illisibles pour toi. Maintenir 1000 lignes de code, sans doute pleines de bugs, prendra sans doute plus de 100 fois plus de temps. Tu parles d'un argument. :lol:
Ah là là, on croit vraiment rêver. "Jar et le plus générique possible". :lol: Java n'est pas générique, seulement pseudo-générique.
Lisp lui est générique à un point dont tu n'as forcément pas idée, sinon tu n'aurais pas écrit ça. Mais quand même, insinuer qu'en Lisp on ne connaît pas le package ou le "point d'entrée", ou qu'on a pas penser à réutiliser du code (alors que Lisp est un champion dans ce domaine également) je suis plié de rire. J'en éprouve même de la compassion.
Faut savoir. J'ai raison, ou je n'ai pas.
Re lol :lol:
Sais tu qu'au départ, les premiers Lisp avaient une syntaxe différente, sans parenthèses ? Et puis il a évolué comme ça. Il doit y avoir un bien fondé là-dedans.
Bon cette fois j'arrête définitivement. Moi épuisé. Moi plus pouvoir parler homme Néanderthal. :P