Journal Quel langage, pour cette utilisation ?

Posté par  .
Étiquettes : aucune
0
21
nov.
2005
Cher journal,

je m'adresse à toi aujourd'hui, parce que j'ai besoin de tes conseils. En effet ça fait plusieurs années que je pratique le xhtml, css, php et mysql pour créer des applications web dynamiques.

J'aimerais maintenant créer des applications systèmes n'ayant pas besoins d'un navigateur, ou d'un serveur pour fonctionner. Même si la plus part des mes applications se serviront d'une base de données, ou d'une connexion internet. La plus part de mes applications possèderont une interface graphique.

Je cherche donc un langage libre, et utilisable sur les principaux os: gnu/linux, ms windows, et mac os. J'aimerais que ce langage me permette de créer des applications compilées, donc sans devoir utiliser un interpréteur pour que l'application fonctionne.

Quel langage me conseils tu ? le C et C++ ? car à part ceux-ci je ne vois pas d'autres langages possibles pour faire ce que je souhaite.

  • # Original

    Posté par  . Évalué à 5.

    Si tu es curieux, tu peux te tourner vers des langages un peu plus originaux mais intéressants, comme par exemple l'objective-caml, qui peut être interpreté, compilé pour une machine virtuelle ou en natif ; le Eiffel, si je ne me trompe pas, qui peut être compilé pour une jvm ou en natif.

    Voilà ce qui me passait par la tête. Ensuite, tout dépend du type d'application que tu veux faire.

    • [^] # Re: Original

      Posté par  . Évalué à 5.

      Le Eiffel est du genre beaucoup plus propre et moins usine à gaz que le C++.

      Java aussi peut faire l'affaire, avec un compilateur et gcj par exemple (pour la portabilité sue autre chose que linus, là je sais pas)

      Pour ce qui est de l'interface graphique, les toolkits sont souvent disponibles dans pas mal de langages, sauf peut être swing pour java. D'autres ont des langages de prédilectiion, QT le C++ par exemple, mais des Bindings doivent être disponible pour d'autres langages.

      J'aurais tendance à déconseiller le C, qui est AMHA un peu dépassé, même si on peut améliorer son utilisation avec de bonnes bibliothèques. Les langages objets sont à mon avis un meilleur investissement.

      C'est sympa aussi de voir des langages style OCaml, dans lesquels on peut programmer, en plus de l'iteratif et de l'objet (comme les autres), en fonctionnel, ce qui permet de faire des choses un peu différemment, plus simplement dans certains cas.

      Voila, je suis pas sûr de t'avoir aidé, mais le monde des langages compilés se limite pas à C/C++ ;) Au passage, n'importe quel langage est potentiellement compilé, il existe sans doute des compilateurs pour des langages à priori uniquement interprétés.

      • [^] # Re: Original

        Posté par  . Évalué à 2.

        Merci de m'aider dans ma conquête de nouveaux langages. Je me doute bien qu'il y a pas que le C et le C++ mais disons que je cherche un langage qui dépend d'une structure.

        Le jour où y'a plus la structure, y a plus le langage !

        Merci ;)

      • [^] # Re: Original

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        FreePascal: simple, efficace, élégant, idéal pour débuter:
        http://www.freepascal.org/

        Lazarus si tu veux un ide pour faire une appli rapidement:
        http://www.lazarus.freepascal.org/

        Un langage comme Python peut se compiler si je ne m'abuse (je commence seulement à m'y intéresser, les spécialistes confirmeront).

        Java avec gcj est effectivement un bon choix aussi.

        Il y en a tant d'autres ! Tu n'as que l'embarras du choix, il faut tester pour faire son choix... Regardes les pages wikipédia sur les différents langages: les avantages/inconvénients sont souvent décrits.

        • [^] # Re: Original

          Posté par  . Évalué à 9.

          Tu peux compiler un script python en bytecode Java (Jython) ou .Net (utilisable avec Mono bien sûr) avec IronPython (qui me semble légèrement mort en passant), mais je vois pas l'intérêt sous un système d'exploitation correct. Pour le système d'exploitation pas correct (désolé, la fatigue, toussa, on fait plus attention aux trolls), ya py2exe. Je sais que pygtk fonctionne avec py2exe, je crois que wxpython aussi (donc logiquement pyqt aussi), mais je sais pas comment ça se passe avec IronPython/Jython (tu peux bien sûr utiliser respectivement Swing/AWT/SWT et GTK#/WinForms, mais dans ce cas tu pourras plus utiliser ton programme dans un autre envitonnement comme CPytohn (le standard). Si tu fais du Swing/AWT/SWT, t'obliges l'utilisation de Jython, idem pour GTK# et IronPython. Quoique GTK# et pygtk ont peut être une API semblable, j'ai jamais touché à GTK#)

          Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
          J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.

          Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.


          [1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
          Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
          Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
          Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...


          Bon, j'arrête là de m'étaler

          • [^] # Re: Original

            Posté par  . Évalué à 2.

            Super ton exemple, merci.

            D'ailleur j'aimerais bien savoir comment tu as géré le fait de savoir quel élément du tree view est vu ou non lors d'un redim d'une fenetre par exemple.

            • [^] # Re: Original

              Posté par  . Évalué à 1.

              J'ai pas mon prog sous la main (je l'ai pas avant Noel d'ailleurs), donc me demande pas de me souvenir des fonctions de GTK que j'utilisais ;)
              Pour le principe, c'était simplement que lorsque la fenêtre intérieure bougeait, les coordonnée actives du treeview changeaient aussi (j'utilise surement pas le bon vocabulaire, désolé...). Il y a un callback pour surveiller cet événement. Dès que ces coordonnées changent:
              - je retire le premier élément (il y a une fonction pour obtenir un élément à partir de ses coordonnées), et le replit
              - je remplit l'élement suivant tant qu'il est dans la zone d'affichage (en calculant ses coordonnées)
              Ca nécessite uniquement de connaitre la position de l'élément. Je dois l'avouer que ça, je l'ai fait "à l'arrache" (j'ai fais une colonne invisible "position" et je la remplissait dès le dépliage de l'élément parent). Il y avait sûrement plus rapide avec les fonctions de GTK, mais je venais de passer deux jours dans la doc pour réaliser ce que je te décrit, j'en avais marre ;)

          • [^] # Re: Original

            Posté par  (site web personnel) . Évalué à 3.

            bel exemple !

            qques correctifs :
            -ironpython est loin d'être mort ... il est juste hébergé chez microsoft directement (jim s'est fait embauché chez ms)... et y a une release toutes les 2 semaines ... mais ça targette dot.net v2

            pour un prog "ironpython", y a juste une petite DLL "ironpython" à trimballer avec l'exe, (en plus du runtime dot.net), et c'est bon

      • [^] # Re: Original

        Posté par  . Évalué à 2.

        JE pense qu'il est important d'avoir programmé en impératif
        ET en fonctionnel.

        Les deux styles de programmations sont utiles et on ne s'en rend
        compte qu'après avoir vraiment goûté aux deux.

        Deux exemples (à la con car trop simple):
        - pour programmer un produit de 2 matrices, l'approche impérative
        me semble très efficace;
        - pour programmer un tri, l'approche fonctionnelle a beaucoup plus
        de sens.

      • [^] # Re: Original

        Posté par  (site web personnel) . Évalué à 3.

        Bon, ben puisqu'on propose Eiffel, je vais encore proposer Lisaac, son petit frère qui a été conçu sous le regard du concepteur de GNU/SmartEiffel.

        Lisaac possède une interface graphique, from scratch, multiplateforme. La gestion de l'interface est vraiment simple (une dizaine de ligne pour faire un éditeur simple de texte). Pour le réseau c'est pas encore la joie, mais il suffit de faire quelques binding en C.

        Je mettrais bientôt la lib graphique sur le site, quand on aura repris certaines incohérences et décidé de certains choix.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # python

    Posté par  (site web personnel) . Évalué à 10.

    J'ai eu exactement le même parcours ... pendant très longtemps je ne jurai (et ne fesai) que par php, et des applications web ...
    et puis un jour, j'ai voulu refaire des GUI, des scripts, et des programmes qui renvoi autre chose que des flux ... naturellement j'ai taté le phpgtk, mais ça ne m'a pas trop branché ...

    je voulais un langage libre, multi plateforme, puissant et bien documenté (un peu comme le php ;-), en qques sortes) ...
    Et c'est tout naturellement que je me suis tourné vers le python ...(et pour l'anecdote, c'est un client bittorrent en python, avec un beau GUI, le tout en 3mo : qui m'a fait tilter, c'est là que j'ai vu que c'était possible)
    il existe des LIBS/api pour quasiment tout ce qui est imaginable, ce n'est que du bonheur ...

    au jour d'aujourd'hui, je suis un accroc, je ne conçois même plus développer dans un autre langage (car tu peux tout faire avec .... ironpython -> dot.net, et jython -> java) . Même mes applis web "à flux", sont en python ... je suis possédé

    il m'a owné, comme on dit ....

    • [^] # Re: python

      Posté par  . Évalué à 2.

      Le Python j'y ai pensé aussi, mais est ce réellement un langage performant pour des logiciels de gestions recevant de gros résultat de requete SQL ?

      • [^] # Re: python

        Posté par  . Évalué à 4.

        Pour moi les 2 défauts :
        - un peu lent sur les gestions de la BD et pas de gestion bd aussi réutilisable que sous java (jdbc).
        - la gestion fine des variables (gestion au niveau du bit) est un peu compliquée

        Par contre pour une appli rapide (à créer) et pas trop consommatrice de mémoire , c'est ce qu'il faut : la facilité du perl avec le bonheur de l'objet ;)

        • [^] # Re: python

          Posté par  (site web personnel) . Évalué à 6.

          > " pour une appli rapide (à créer)"
          Juste pour qu'il n'y ai pas d'ambiguité ... autant, il est facile d'avoir rapidement un resultat (dev rapide), autant le python permet aussi, pour peu d'être un peu méthodique, de batir des cathédrales ...
          le langage étant simple, et plutot assez lisible (à cause de sa structuration innée), permet d'être très scalable aussi ...

          pas qu'on associe python a petits développements rapide pour le fun ;-)

          • [^] # Re: python

            Posté par  . Évalué à 4.

            Je suis tout à fait d'accord avec toi, perso j'aime beaucoup Python car il est tout à fait possible de produire du code modulaire et structuré. Je passe d'ailleurs beaucoup de temps sur ce langage, pour moi c'est l'avenir du scripting.

            Une critique toutefois (mais qui n'est pas inhérente uniquement au langage) : la facilité de développement provoque une ré-invention constante de la roue. Peu de standardisation des outils, comme en Java. Un lien intéressant :

            http://dirtsimple.org/2005/07/reinvent-no-more-forever.html

          • [^] # Re: python

            Posté par  . Évalué à 3.

            J'ai été un peu vite en besogne en effet, je fais actuellement du python et c'est vrai que pour faire une ihm complexe avec une logique métier tout aussi simple, python c'est parfait, on ne se soucie que de la logique du logiciel pas de sa gestion mémoire mais forcément cela se paie quelque part :
            Cependant, au bout de quelques miliers de lignes de code, le programme n'est plus accessible à toutes les machines...

            Mon plus gros regret est bien sur la gestion des bases de données où il manque vraiment une bonne couche d'abstraction à la jdbc.

            Sinon il est vrai que c'est peut-être l'avenir du script (troll : même Microsoft voit que l'avenir du script doit être dans l'objet ;) ), la présence d'objet éclaircit le code et le rend de plus en plus réutilisable mais c'est de plus en plus dur de faire un script diretement sur la ligne de commande.


            Pourquoi ma comparaison avec Perl. Perl a tendance avec son "there is more than one way" a généré (chez moi en tout cas) du code difficilement maintenable. De plus la gestion objet de perl est présente mais n'est pas une base du langage comme le sont les listes ou les hachages. Cependant cela reste un excellent langage qui permet de toucher de l'octet au robot web avec énormément de faciliter. De plus, le CPAN est vraiment un gros atout de Perl.

            Pour finir, le site de python est python.org (et non .com malheureusement ;) )

            • [^] # Re: python

              Posté par  (site web personnel) . Évalué à 3.

              > Mon plus gros regret est bien sur la gestion des bases
              > de données où il manque vraiment une bonne couche
              > d'abstraction à la jdbc.

              t'as essayé SQLobject ? en matière d'abstraction db, y a pas mieux, non ?

        • [^] # Re: python

          Posté par  (site web personnel) . Évalué à 1.

          la facilité du perl avec le bonheur de l'objet ;)


          belle tentative de lancé de troll.

          Par contre, une explication précise sur ce point m'interesse. j'ai jamais réellement compris pourquoi python etait plus objet que perl au niveau de sa grammaire ...

          • [^] # Re: python

            Posté par  . Évalué à -2.

            j'ai jamais réellement compris pourquoi python etait plus objet que perl au niveau de sa grammaire ...

            Parce qu'en perl on sent que la couche objet a été rajoutée à l'arrache ("bénédiction" de tes références pour en faire des objets, c'est rigolo mais bon...)

            Parce qu'en Python tout, sans exception, est objet ?

            Parce que Python a été pensé comme un langage objet ?

            • [^] # Re: python

              Posté par  . Évalué à 10.

              Parce que Python a été pensé comme un langage objet ?

              Tu confonds avec Ruby

        • [^] # Re: python

          Posté par  . Évalué à 0.

          j'avous t'avoir plusser uniquement parce que c'est une des premiere fois que je vois quelqu'un dire du mal de l'outil qu'il utilise...
          c'est rare ! la plupart du temps on vois des truc du style : "mon truc a moi il est bien c'est le meilleure, le reste capucestpas(libre/bien/rapide/ergonomique/puissant/etc...)

          ca au moins c'est un commentaire vantant les merite de ton outils sans pour autant oublier ses faiblesse !

          et ÇA c'est bien !

      • [^] # Re: python

        Posté par  . Évalué à 3.

        Ta question à propos des "logiciels de gestions recevant de gros résultats de requete sql" n'est pas très compréhensible...

        Si ça peut te rassurer je bosse régulièrement sur des grosses bases oracles et postgresql, python ne pose aucun problème particulier... Mais généralement quand on à un problème de perf à cause de "gros résultats sql" c'est que l'analyse n'est pas bonne et qu'il faut déléguer plus de taches au moteur de la bdd.

        • [^] # Re: python

          Posté par  (site web personnel) . Évalué à -1.

          La BDD est là pour stocker les données et pour faciliter les requêtes. Elle n'est pas là pour combler les faiblesses du langage et faire office de couche métier. Alors quand y'a un problème de perf, non, ne pas déléguer plus de tâches au moteur de bdd. Tous les moteurs de bdd ont une limite, et il y aura un moment où tu ne pourras plus passer à l'échelle. D'où l'intérêt de choisir un langage adapté pour la couche métier, qui propose des services spécifiques lorsqu'on s'attend à avoir beaucoup de données à traiter. Je te laisse deviner lesquels choisir, c'est simple, il suffit de voir ce qui se fait autour de toi.

          • [^] # Re: python

            Posté par  . Évalué à 3.

            Je ne parle pas de couche métier dans la bdd, mais simplement du fait que quand on parle de perf sur une bdd ça vient rarement du langage lui-même mais plutôt de la structure des données, mauvaise requete, mauvais index etc, donc un problème d'analyse...

            Oubien on parle simplement de quantité de données à traiter, mais alors ça n'a rien à voir avec une bdd, d'où l'ambiguité de la question.

            Google utilise copieusement python par ex, mais ça ne nous apprend rien sur les perfs de python !

    • [^] # Re: python

      Posté par  (site web personnel) . Évalué à 8.

      oups, j'ai oublié de dire ce que je voulais dire dans ton cas (je me suis emporté ;-) ... à propos de "me permette de créer des applications compilées,"
      - en python, tu peux freezer une appli (grouper ses scripts et son runtime, dans un fichier unique, par exemple) pour tous les OS, avec pyinstaller (sinon, py2exe/win, cx_freeze/nux, py2app/mac ...). Avec le widget WX, tu peux avoir un "exe" de 3mo avec du GUI
      - avec ironpython, en targettant la clr2 (voire mono), tu peux créer des "exe" (necessitant le runtime dot.net)
      - avec jython, tu peux construire tes class java (mais necessitant la jvm)
      - et avec shedskin, tu devrais pouvoir produire du binaire sous peu (le projet avance vite)
      - sinon la techno "pypy" : python quasiment entièrement interprété en python (le serpent qui se mort la queu), devrait amener à un runtime quasi nulle à terme ...

      mais bon l'interprété a plutôt le vent en poupe ...

  • # C# ou Java.

    Posté par  (site web personnel) . Évalué à -2.

    C# ou Java.
    C'est pas interprété, c'est multi-plateforme et c'est plus moderne (et plus productif surtout) que C/C++.
    Ma préférence : C#.
    http://monofrance.free.fr

    • [^] # Re: C# ou Java.

      Posté par  . Évalué à 2.

      Tant qu'à faire, autant choisir l'original (donc Java) et pas le clone, qui s'est appuyé sur les bonnes idées de Sun pour ré-inventer la roue :-)

      En plus, SWT a le vent en poupe et permet de réaliser des clients lourds avec widgets natifs.

      Et puis Eclipse (à condition de bosser en Java) apporte une productivité jamais atteinte jusque là AMHA.

      Quelques lectures sur les designs patterns pour pondre du code bien structuré, et le tour est joué.

      Pour la persistance des données, tu peux coupler Hibernate (couche d'abstraction par rapport à toutes les BDD du marché) et XDoclet pour avoir un code du style :


      /* @hibernate.class table="clients" */
      class MonObjetPersistant {

      private String nomClient;

      /**
      * @hibernate.property
      */
      public String getNomClient() {
      return nomClient;
      }

      }



      Et hop, tu peux directement et automatiquement sauvegarder tes instances Java en base (mapping objet relationnel). Pratique.

      Certains pensent que c'est pas la panacée niveau beauté du code, perso je trouve que c'est un excellent compromis pour ne pas se coltiner des XML de mapping à la main.

      Enfin, toujours est-il que pour réaliser des clients lourds multi-plateformes, avec des IHM sympa, Java+SWT est l'idéal. Le nombre d'outils dispo répondront à tous tes besoins tiers.

      • [^] # Re: C# ou Java.

        Posté par  (site web personnel) . Évalué à 1.

        Tant qu'à faire, autant choisir l'original (donc Java) et pas le clone, qui s'est appuyé sur les bonnes idées de Sun pour ré-inventer la roue :-)
        Comme si Java avait inventé quelque chose... En s'appelant C#, Microsoft a au moins le mérite d'avoir choisi de rappeler l'origine du langage.

        Certains pensent que c'est pas la panacée niveau beauté du code, perso je trouve que c'est un excellent compromis pour ne pas se coltiner des XML de mapping à la main.
        Ahahah, le coup des méta-données pour faire du mapping... Ils l'ont piqué sur qui Java déjà ? :-p

    • [^] # Re: C# ou Java.

      Posté par  . Évalué à 3.

      J'aimerais que ce langage me permette de créer des applications compilées, donc sans devoir utiliser un interpréteur pour que l'application fonctionne.


      Je pense qu'il inclut les machines virutelles dans "interpreteurs". Il veut du portable, ok, mais au niveau du code, et qui ne nécessite rien d'installé au préalable.

    • [^] # Re: C# ou Java.

      Posté par  . Évalué à 1.

      Trop gros, 'passeront pas (oui, oui, j'utilise bien le pluriel:).

    • [^] # A si tu compares a C/C++, forcement...

      Posté par  . Évalué à 2.

      J'ai deja fait du Java, un peu de C#, et je me demande toujours ce que ca apporte par rapport a Python ou Ruby (a part le fait que "ca fait plus pro quand on en parle au patron").

      La principale difference que j'ai vu c'est que la gestion des chaines de characteres ou des listes est nettement plus simple avec Python ou Ruby qu'avec Java ou C#.

      • [^] # Re: A si tu compares a C/C++, forcement...

        Posté par  (site web personnel) . Évalué à -1.

        Euh, si tu ne vois pas la différence entre Python et Java, tu n'as peut être jamais entendu parler de la notion de "type", si ?

      • [^] # Re: A si tu compares a C/C++, forcement...

        Posté par  (site web personnel) . Évalué à 2.

        Des différences ? En voilà :
        - Méta-données
        - Génériques
        - Evénements
        - Compilation native multi-plateforme
        - Typage relativement fort et statique
        - Appels bibliothèques natives multi-plateforme et intégré au langage
        - De meilleurs perf sans sacrifier la portabilité
        - Le versionning des composants
        T'en veux d'autre ?

        • [^] # Re: A si tu compares a C/C++, forcement...

          Posté par  (site web personnel) . Évalué à 3.

          oulalala ....

          c'est pas pour feeder un début de trolls ... (et puis on s'est déjà pris la tête dans d'autres posts, on va pas recommencer ;-) ...)

          si tu comparais à python, une grande partie de tes "différences" n'en sont pas ... réellement ...

          - Méta-données
          en python : no prob ...

          - Génériques
          les "génériques" (terme pompeux de crosoft) sont nativement dans python depuis des lustres (cf ses propriétés de typage dynamique)

          - Compilation native multi-plateforme
          python compile aussi le py en pyc, c'est natif et multi plateforme ...

          - Typage relativement fort et statique
          c'est une différence, mais est-ce un avantage ?!?
          (d'ailleurs, l'inférence de type dans dot.net (donc mono), c pour la V3 de la clr ;-)

          - Appels bibliothèques natives multi-plateforme et intégré au langage
          en python aussi ... non ? ;-)

          ...
          je ne crache pas sur mono ou sur dot.net, j'en mange beaucoup au boulot ... et j'en suis même très satisfait, et très content .... pk je peux faire du "python" avec, soit avec boo, soit avec ironpython ;-)

          • [^] # Re: A si tu compares a C/C++, forcement...

            Posté par  (site web personnel) . Évalué à 2.

            les "génériques" (terme pompeux de crosoft) sont nativement dans python depuis des lustres (cf ses propriétés de typage dynamique)
            Ahahaha. Les génériques ont justement l'avantage de proposer un typage statique pour éviter d'éventuelles couilles à l'exécution et au passage améliorer les perfs. Alors en Python je vois mal, mais alors très mal comment tu vas t'y prendre. Mais vas-y montre moi puisque t'y crois :)
            Allez, propose moi par exemple un morceau de code qui me déclare une pile d'entier, et uniquement d'entier. Bien sûr l'implémentation de la pile est générique.

            python compile aussi le py en pyc, c'est natif et multi plateforme ...
            "pyc is a compiler that compiles python source code to bytecode"
            T'as un processeur qui interprête le bytecode Python en natif toi ?

            c'est une différence, mais est-ce un avantage ?!?
            Là n'est pas la question. C'est en tout cas une grosse différence.

            Appels bibliothèques natives multi-plateforme et intégré au langage
            en python aussi ... non ? ;-)
            Non. Ou alors j'ai jamais vu. Mais je veux bien que tu me montres encore une fois :)

            Python n'a peut être pas toutes les diff que j'ai cités, mais il en a la plupart.

            • [^] # Re: A si tu compares a C/C++, forcement...

              Posté par  (site web personnel) . Évalué à 1.

              > Allez, propose moi par exemple un morceau de code
              > qui me déclare une pile d'entier

              arghhh ... cassé ... tu m'as eu ... brice ...
              j'avais oublié le coté statique des génériques ...

              > T'as un processeur qui interprête le bytecode Python en natif toi ?
              non, mais on peut en dire de même pour le produit généré par mono, ou dot.net ... ce dernier ne peut marcher qu'avec le runtime qui va bien
              (tout comme le pyc, marchera, sur plusieurs plateformes, avec le runtime de python adéquate)

              >> Appels bibliothèques natives multi-plateforme et intégré au langage
              >> en python aussi ... non ? ;-)
              > Non. Ou alors j'ai jamais vu. ...
              os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)
              non ?!?

              mais tout le débat, si on continue, va se finir sur le typage static vs dynamic ... alors autant y aller de suite, non ? ;-)

              • [^] # Re: A si tu compares a C/C++, forcement...

                Posté par  . Évalué à 1.

                >>> Appels bibliothèques natives multi-plateforme et intégré au langage
                >>> en python aussi ... non ? ;-)
                >> Non. Ou alors j'ai jamais vu. ...
                >os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)

                Je pense qu'il pensait plutôt à une sorte de dlopen. Et oui, c'est possible (à tout hasard, le module dl ? :)). Par contre multiplatforme je vois pas comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)

                • [^] # Re: A si tu compares a C/C++, forcement...

                  Posté par  (site web personnel) . Évalué à 2.

                  comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)
                  Ben avec Mono par exemple, tu peux wrapper OpenGL, et ce sera les mêmes binaires que tu redistribueras sous Linux et Windows. Evidemment OpenGL sera spécifique, mais ton bytecode sera parfaitement portable. Le gros avantage c'est aussi d'assurer l'intégration dans le langage C#, et donc d'avoir toutes les vérifications de type du compilateur et aussi la sécurité d'exécution qui va avec.

                  • [^] # Re: A si tu compares a C/C++, forcement...

                    Posté par  . Évalué à 1.

                    C'est un binding ça, non ? Je pense que les langages ne supportant pas ça sont plus rares que ceux qui les supportent ;)

                    • [^] # Re: A si tu compares a C/C++, forcement...

                      Posté par  (site web personnel) . Évalué à 2.

                      Je pense que les langages ne supportant pas ça sont plus rares que ceux qui les supportent ;)
                      Sauf que en C# c'est intégré dans la syntaxe, et ca permet d'invoquer directement une lib native sans wrapper nécessitant un langage intermédiaire comme dans la plupart des langages. Je ne connais aucun autre langage qui permette cela de manière portable.

              • [^] # Re: A si tu compares a C/C++, forcement...

                Posté par  (site web personnel) . Évalué à 2.

                arghhh ... cassé ... tu m'as eu ... brice ...
                :-p

                non, mais on peut en dire de même pour le produit généré par mono, ou dot.net ...
                Sauf que Mono/.NET est conçu pour être compilé en natif, ce que fait l'environnement d'exécution. Bref, je reste sur mon affirmation, Python/Ruby ne sont pas compilé en natif de manière multiplateforme. Seule Psycho se rapproche de l'idée, en perdant la portabilité (et donc une partie de l'intérêt).

                os, string, ... bref toutes les libs faisant partie de "python"
                C'est pas la question.
                En C#, je peux déclarer :
                [DllImport("opengl")]
                public static extern void FonctionNative(string arg1, int arg2);
                C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.

                Bref, t'es cassé sur toute la ligne :)

                Oui c'est effectivement en bonne partie du au typage, qui empêche Python d'avoir par exemple une gestion du versionning. Bref, c'est pas pareil, et y'a bien de grosses différences, cqfd.

                • [^] # Re: A si tu compares a C/C++, forcement...

                  Posté par  . Évalué à 1.

                  > [DllImport("opengl")]
                  > public static extern void FonctionNative(string arg1, int arg2);
                  > C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.

                  http://wikipython.flibuste.net/moin.py/CodeWindows#head-3508(...)
                  Contrairement à ce qui est annoncé, c'est pas limité à l'API Windows. C'est pas véritablement intégré au langage, mais c'est pas non plus plus complexe que ton truc ;) (je trouve même là syntaxe plus propre - mais c'est strictement subjectif, c'est juste que j'ai été traumatisé à vie par la syntaxe [Truc(bidule)] par l'API windows ;)...)

                  • [^] # Re: A si tu compares a C/C++, forcement...

                    Posté par  (site web personnel) . Évalué à 2.

                    Ca n'a rien à voir, ce que tu me montres c'est l'interopérabilité COM/ActiveX sous Windows. Comme dans tous les langages de script sous Windows. Bref, rien à voir avec un simple appel de méthode dans une lib qui exporte un API en C quelconque.

                    • [^] # Re: A si tu compares a C/C++, forcement...

                      Posté par  . Évalué à 2.

                      Non, sur http://starship.python.net/crew/theller/ctypes/ il est bien écrit:
                      > ctypes allows to call functions exposed from dlls/shared libraries
                      (sous-entendu: n'importe quelle librairie)

                      Dans le tutorial, tu as un exemple avec /lib/libc.so.6... Rien à voir avec COM ou ActiveX ;)

                      • [^] # Re: A si tu compares a C/C++, forcement...

                        Posté par  (site web personnel) . Évalué à 2.

                        Oué effectivement l'exemple précédent n'était pas pertinent. Cela dit c'est pas plus portable, tu es obligé d'avoir un code différent sous Linux et Windows, les extensions de bibliothèques étant différentes. Avec Mono tu il mappe automatiquement la référence de bibliothèque sur un .dll sous Windows, un .so sous Linux, etc. Bref, pas de code spécifique selon la plateforme.

                        • [^] # Re: A si tu compares a C/C++, forcement...

                          Posté par  . Évalué à 2.

                          C'est pas non plus la mer à boire hein... T'as juste à tester os.name... La vraie critique qu'on pourrait faire, c'est qu'on doit préciser le chemin entier, et encore... c'est pas plus difficile de chercher automatiquement dans $LD_LIBRARY_PATH, /usr/lib et /lib... Ca se fait en quelques lignes de codes. Tiens, juste pour m'amuser: 
                          def LoadLibraryPath(lib):
	search_path = os.getenv("LD_LIBRARY_PATH")
	
	if search_path is not None:
		search_path = search_path.split(os.path.pathsep)
	else:
		search_path = []
	
	for p in ["/lib", "/usr/lib"]+search_path:
		if os.path.exists(os.path.join(p, lib+".so")):
			return LoadLibrary(os.path.join(p, lib+".so"))
                          Maintenant, il n'y a plus qu'à tester os.name et agir en conséquence (j'avoue que je 'lai pas fait parce que je connais pas trop RiscOS, OS/2 et autres systèmes gérés par Python...). Ca m'a pris plus de temps taper le message que le code :) (c'est la faute à templeet...)

              • [^] # Re: A si tu compares a C/C++, forcement...

                Posté par  (site web personnel) . Évalué à 2.

                Ah oui tiens si tu es fan de la syntaxe Python, essai une variante typée statiquement et plus performante : Boo.

    • [^] # Re: C# ou Java.

      Posté par  . Évalué à 2.

      Je ne veux pas utiliser Java, puisqu'il faut utiliser la machine virtuel pour ca fonctionne. Et pour C#, je veux pas utiliser une langage MS.

      • [^] # Re: C# ou Java.

        Posté par  (site web personnel) . Évalué à 2.

        Bon bah lache l'affaire. Sachant que tous les langages modernes ont besoin d'un environnement d'exécution pour proposer des services de sécurité et d'abstraction, il ne te reste plus grand chose. Désolé, mais c'est pas en s'arrêtant à l'origine d'un langage que tu vas réussir à faire des choix pertinents en informatique (à mon sens). Bon ben il te reste plus que le C/C++, c'est vieux, c'est pas productif, mais ca marche et c'est performant. Amuses toi bien :)

        • [^] # Re: C# ou Java.

          Posté par  . Évalué à 1.

          Bon ben il te reste plus que le C/C++

          Nan nan, il reste Objective-C aussi : un lagage objet avec une très bonne API, un très bon IDE, proche du C syntaxiquement, et plein de bonne choses reprises ailleurs (C# reprends les delegates je crois, avec une decennie -au moins- de retard).

          • [^] # Re: C# ou Java.

            Posté par  (site web personnel) . Évalué à 1.

            C# reprends les delegates je crois, avec une decennie -au moins- de retard
            En même temps les delegates c'est les pointeurs de fonction ala C, c'est pas une innovation qui tue :)
            Et puis Objective-C utilise un environnement d'exécution, et visiblement ca ne répond pas aux critères.

  • # haskell, io ?

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,

    Comme certains l'ont stipulé, le langage Eiffel est très intéressant et, avec le compilateur smarteiffel 2.0 (même en version béta), on obtient du code natif avec des performances semblables à ceux du C++. La cerise sur le gateau d'Eiffel est évidemment son garbadge collector et sa conception soignée.

    Sinon, pour proposer des choses originales, il y a aussi Haskell. C'est un langage fonctionnel pure avec un compilateur natif. Je me suis un jour amusé avec en écrivant une petite appli OpenGL et j'ai été bluffé par ses performances et sa concision. Et il existe de quoquette librairies pour celui-ci. Par contre, il est vrai, il demande un effort pour appréhender son côté fonctionnel.

    Sinon, si tu aimes explorer des horizons nouveaux, il y a le langage objet à prototype Io (http://www.iolanguage.com). C'est un langage à VM (à ne pas confondre avec interpréteur). Il est sous licence BSD.

    Voilà. (Désolé pour les fautes d'orthographe).

  • # Ruby ?

    Posté par  (site web personnel) . Évalué à 3.

    Bon on a eu droit à Haskell, C, C++, C#, Java, Eiffel, Pascal, Python.
    Encore un petit effort : Ruby : j'aimerais avoir des avis sur Ruby; On en entends parler avec Ruby on Rail pour les applis web, mais pour faire des "vraies" applis ?
    Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...

    • [^] # Re: Ruby ?

      Posté par  (site web personnel) . Évalué à 4.

      je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...

      Je ne pense pas.

      Autant j'aime beaucoup python (à défaut de connaître Ruby) et trouve PyQt très agréable, autant je suis heureux que KDE ne soit pas interprété :)

      • [^] # Re: Ruby ?

        Posté par  . Évalué à 4.

        Même si KDE et GNOME ne sont pas interprétés, c'est quoi l'intérêt de développer des applications KDE et GNOME en C ou C++ de nos jours ?

        Certe je verrais mal un Gimp en python mais la plupart des applications desktop pourraient être sans problème codé avec un langage script ... Il n'y en a finalement que peu qui ont besoin de la forte réactivité d'un langage compilé bas niveau.

        • [^] # Re: Ruby ?

          Posté par  (site web personnel) . Évalué à 2.

          Oui, à condition que les bibliothèques sur lesquelles reposent lesdites applications ne soient pas interprétées. Et on en revient au C/C++/autre.

          Je crois que si tout KDE (Qt compris ?) était codé en python, personne ne l'utiliserait :)

          Des nouveaux modules python, codés au départ en python, sont ensuite recodés en C pour une question de performances.

    • [^] # Re: Ruby ?

      Posté par  . Évalué à 3.

      Encore un petit effort : Ruby : j'aimerais avoir des avis sur Ruby; On en entend parler avec Ruby on Rail pour les applis web, mais pour faire des "vraies" applis ?

      http://ruby-gnome2.sourceforge.jp/

      Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...

      C'est certain dans le domaine des IHM graphiques sous forme interprété ou en bytecode.
      Mais ça m'étonnerait pour ce qui est des bibliothèques bas niveau, comme GTK+ ou QT.

    • [^] # Re: Ruby ?

      Posté par  . Évalué à 4.

      Je pense que les deux sont complementaires.
      - Du C ou du C++ pour ecrire les bibliotheques qui ont des traitements couteux
      - Du Ruby ou du Python pour "coller" les bibliotheques entre elles et creer des applications

      Pour Firefox c'est pareil: du C++ pour les couches basses (Gecko, composants XPCOM), et Firefox est programme en Javascript.

      En tout cas, c'est l'approche que j'utilise.

  • # pkoi pas une appli web ?

    Posté par  . Évalué à 1.

    Si tu connais déjà bien les applis web, pourquoi ne souhaites tu pas continuer dans ce sens ?
    Si c'est l'installation d'un serveur qui t'embête tu peux très bien créer un exécutable indépendant qui fasse serveur et bdd tout en utilisant le navigateur comme interface graphique.

    Par exemple tu peux remplacer avantageusement apache+php+mysql par python+sqlite+py2exe.

    • [^] # Re: pkoi pas une appli web ?

      Posté par  . Évalué à 1.

      J'aime les applications web mais en effet l'installation d'apache, de mysql, du mod_php etc. m'embête.

      Pour le moment je trouve que python est un bon choix !

      • [^] # Re: pkoi pas une appli web ?

        Posté par  (site web personnel) . Évalué à 3.

        Pour le moment je trouve que python est un bon choix !
        Tes choix sont vraiment incompréhensibles :
        - tu précises ne pas vouloir d'interprété.
        - je te propose Java
        - tu veux pas non plus de VM
        Conclusion : tu te penches sur Python qui utilise à la fois une VM et qui est interprété (????)

        • [^] # Re: pkoi pas une appli web ?

          Posté par  . Évalué à 2.

          Je pense que ce qui embête le monsieur c'est le fait d'être obligé d'installer un runtime pour distribuer son prog.
          Avec python on freeze et hop (même si l'exe prend 3 Go en RAM).
          Ca doit être possible avec Java aussi je pense.

    • [^] # Re: pkoi pas une appli web ?

      Posté par  (site web personnel) . Évalué à 2.

      ça m'arrive souvent de faire une interface "web" à un programme python ... afin d'éviter de trimballer un gui ... c'est très pratique ....

      les 10 lignes suivantes suffisent amplement pour réaliser celà :
      http://www.bigbold.com/snippets/posts/show/654

      au passage, l'accès SQLlite versions ultra simple :
      http://www.bigbold.com/snippets/posts/show/653

      • [^] # Re: pkoi pas une appli web ?

        Posté par  . Évalué à 2.

        Page de garde

        BigBold.com
        Ruby on Rails Development and Training in the United Kingdom
        020 7870 7779
        Ruby on Rails Work


        Fais gaffe quand même ;-)

        • [^] # Re: pkoi pas une appli web ?

          Posté par  (site web personnel) . Évalué à 2.

          oui, je savais ... t'inquiètes pas ...

          c'est même moi, avec mes contributions, qui ai fait passé le mot clé "python" au-dessus de ruby ... il y a qques mois ...
          après, c karakot qui a grandement surenchéri ;-)

          et une première appli, en PYTHON (et pygtk), devrait bientôt voir le jour pour utiliser ces snippets ;-)

  • # ObjectiveC++

    Posté par  (site web personnel) . Évalué à 3.

    Ben oui, on a eu droit au plus classique du genre ici alors pourquoi pas celui la.

    Je ne sais pas si l'ObectiveC++ est déjà intégré dans la branche principale de gcc. Si oui, c'est à mon avis un choix intéressant. L'ObjectiveC est à la base de Java qui est lui même à la base de C#. Son modèle object est très souple pour les IHM.

    Avec l'ObectiveC++, le modèle MVC peux prendre toute son ampleur. Le modèle en C++ pour la vitesse et la vue en ObjectiveC pour sa souplesse et la cohérence de ses classes graphiques.

    Sinon, peu présent sur linuxfr et que je n'ai jamais utilisé mais /a priori/ robuste, il y a aussi Pike qui est un langage de script avec un syntaxe "a la C".

  • # Personne ne parle de QT

    Posté par  . Évalué à 2.

    Pourtant, il semble correspondre à ton cahier des charges ... Non ?

    • [^] # Re: Personne ne parle de QT

      Posté par  (site web personnel) . Évalué à 2.

      Parcque QT c'est une bibliothèque, accessible depuis de nombreux langages. Hors le débat n'est pas sur le choix d'une bibliothèque (auquel cas on serait retomber sur un troll GTK/Qt/wx&Co), mais les langages.

  • # Et Ada dans tout ca on en fait quoi?

    Posté par  . Évalué à 3.

    C'est un langage assez bien fichu qui a mon avis ne doit pas être négligé dans tes choix.

    En plus linux magazine publie actuellement des articles sur Ada (A quand un hors serie reprenant tous les articles Ada?).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.