Havoc Pennington se pose des questions sur les langages du libre

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
18
mar.
2004
Gnome
Havoc Pennington, membre reconnu des développeurs de GNOME, et employé chez Red Hat, nous fait part de ses pensées sur les nouveaux langages de programmation qui apparaissent, et sur la façon dont la communauté du logiciel libre doit y répondre. Les deux principales cibles sont Java et .NET.

Les réflexions sont très nombreuses, et impossibles à résumer ici, mais on peut dire que l'objectif principal de son article est d'inciter la communauté du logiciel libre à choisir l'attitude à adopter envers Java et .NET. Havoc commence par rappeler brièvement que ces langages sont déjà considérés, voire employés, dans des applications importantes du libre comme GNOME, Mozilla ou OpenOffice.org, et regarde ensuite Java et .NET sous différents aspects, sans oublier Python, Perl et Ruby.

Attention, ce texte est potentiellement un nid à trolls. Blindez vos trollomètres, et essayons d'avoir le même objectif que Havoc : être constructif.

Aller plus loin

  • # Re: Havoc Pennington se pose des questions les langages du libre

    Posté par  (Mastodon) . Évalué à 8.

    IL évacue quand même bien rapidement la question de Perl, Python et Ruby, vous ne trouvez pas ? Je veux bien qu'à son avis ils ne soient pas adéquats mais il faudrait encore expliquer pourquoi.

    Pour ma part j'ai beaucoup programmé en Java, et maintenant je programme beaucoup en Ruby. J'ai du mal à voir en quoi ce dernier est moins intéressant pour développer un bureau. On pourrait dire qu'il est plus lent que Java, c'est vrai en théorie, mais subjectivement je n'ai pas la même impression de lourdeur quand je lance un programme Ruby que quand je lance un programme Java.

    Idem pour Python, dont on entend beaucoup de bien et qui, si j'ai bien compris, serait plus facilement optimisable, voire compilable (confirmation ?).

    Si on ajoute que ces langages sont libres et de plus haut niveau que Java (en tout cas beaucoup plus agréables à utiliser pour le programmeur), je ne vois pas trop d'arguments contre. Hmm, c'est pas compilé, c'est un argument ça ? :-)
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à 5.

      Pour couper court les poils du troll sur la lenteur des langages de scripts :
      On se fout un peu qu'ils soient lent ou pas quand ils savent s'appuier au moment oportun sur des librairies natives. Il ne faudrait donc pas comparer la vitesse des langages mais plutôt la vitesse des librairies sur lesquelles il peut s'appuier.
      L'erreur de java à été d'essayer de faire tout tout seul, d'où les lourdeurs qu'on connait alors que le langage en lui même est relativement rapide finalement.

      Ceci n'empêche pas que python fasse bcp pour améliorer ses performances, du fait d'une menace d'attaque par tarte à la crème interposée ! Mais la condition reste que les améliorations ne doivent pas rendre la maintenance du langage problématique (ce qui est encore une différence avec java par ex)
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Havoc Pennington se pose des questions les langages du libre

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

          Un langage, ce n'est pas seulement la spécification de sa syntaxe, mais aussi la spécification de son implémentation (pour des raisons de compatibilité).

          Par exemple, une différence fondementale entre le C et le Pascal sont l'empilement des arguments, de la valeur de retour et de l'adresse de retour. Ils ne le font pas dans le même ordre.

          Donc, oui, un langage peut être plus rapide suivant la spécification de son implémentation !
          • [^] # Re: Havoc Pennington se pose des questions les langages du libre

            Posté par  . Évalué à 5.

            D'ailleurs parmi les langages qui sont à la fois, bien implémentés, spécifiés, et optimisés (tant au niveau du code généré que de la rapidité de compilation).. faudrait pas oublier OCaml !

            Certes c'est pas aussi "pratique" que Python .. mais question fiabilité et vérification du code.. le compilo est très très fort.

            et en plus c'est francais :-)
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

        Posté par  . Évalué à 4.

        Te plains pas, il y a un langage dont il ne parle même pas (peut-être ne sait-il pas qu'il existe :-)), l'Objective-C.

        C'est un langage très rapide, très évolué et comparable (à mon avis) à Java et à .NET.
        Avec cependant un gros avantage : il possède un framework éprouvé, simple à utiliser et complet sans être trop lourd (ce framework c'est GNUstep, qui répond aux specs OpenStep, comme Cocoa de MacOS X).
        • [^] # Re: Havoc Pennington se pose des questions les langages du libre

          Posté par  . Évalué à 4.

          objective-C ne se compare pas à .NET, car .NET n'est pas un langage mais une infrastructure (enfin on appelle ça comme on veut). À la limite, on pourrait le comparer à C#
          Il est clair que la prise en compte de gnustep serait pas mal, surtout avec la compatibilité macosx (il me semble que cocoa n'est pas équivalent à gnustep ou openstep mais juste une partie du moteur de l'interface)
        • [^] # Re: Havoc Pennington se pose des questions les langages du libre

          Posté par  . Évalué à 2.

          D'ailleurs, n'était-ce pas le langage qui avait été envisagé dès le début de Gnome? Je suis en tout cas d'accord avec toi, cette solution semble vraiment intéressante de part le langage lui même, mais également de part le framework déjà disponible, et bien entendu parce qu'il n'est pas encombré de problème de brevet, de PI, de licence..., bref, parce qu'il est libre!
          • [^] # Re: Havoc Pennington se pose des questions les langages du libre

            Posté par  . Évalué à 1.

            Ce langage possède peut-être quand même un petit souci :

            Apple peut rajouter des specs à OpenStep, étant propriétaire.

            Si GNUstep se rapproche trop d'eux, ils pourront facilement allourdir les specs de manière à limiter la compatibilité, en se basant sur la lenteur de développement (par rapport à la leur).
            • [^] # Re: Havoc Pennington se pose des questions les langages du libre

              Posté par  . Évalué à 1.

              Je ne pense pas qu'Apple s'amuse à rajouter beaucoup d'extensions à cocoa, leur interêt est d'avoir un environnement stable (niveau évolution, pas stabilité) s'ils veulent attirer les entreprises.
              De plus (pour l'instant) la migration se fait plutôt dans le sens gnustep->cocoa que dans l'autre, et dans ce cas le rajout d'extensions à gnustep ne me paraît pas être dangereux, c'est dans l'autre sens que ça peut devenir un problème. Je ne crois pas que des entreprises soient intéressées (pour l'instant) par le portage d'applis macosX sous linux, encore que ça doublerait leurs parts de marché. La compatibilité va plus intéresser tous les geeks qui ont un ibook par exemple, encore faut-il que des killer-apps soient fait sous gnustep... mais ça fait tellement longtemps qu'on attend...
            • [^] # Re: Havoc Pennington se pose des questions les langages du libre

              Posté par  . Évalué à 5.

              >Apple peut rajouter des specs à OpenStep, étant propriétaire.

              "openstep" n'est pas qu'à apple, faudrait vérifier ce qu'il en est de leur accord avec sun.

              openstep a été normalisé avec NeXT et Sun.

              depuis openstep, cocoa a rajouté quelques extensions, les plus visibles sont les "feuilles", et les "drawers". l'api a eu qq ajouts et améliorations aussi.

              notons que cocoa a toutes ses classes prètes pour java aussi.


              et oui, ils peuvent limiter la compatiblité en ajoutant a tout va des nouveautés, mais cela peut se retourner contre eux, en aliénant les developpeurs macs.


              sinon, Havoc ne dit pas de simplement "suivre tout le temps". il explique que Gnome pourrait utiliser l'une de ces fondations, utiliser "officiellement" un langage plus évolué, mais pas forcément de chercher a rester compatible à tout va.

              exemple :

              c# et mono : ok MAIS gnome utiliserait en fait Gtk#, qui n'a que peu de rapports avec les classes .NET winforms etc sur windows.

              java : la jvm etc, ok, mais pas swing, mais les classes java-gtk java-gnome etc

              objective-c : pourquoi pas après tout ? objective-c est un beau langage, gnustep est découpé en 2 blocs en gros, fondation et appkit, nul n est obligé d'adopter appkit totalement parce que objective-c est intéressant, de nouvelles classes "gnome" pourrait etre ecrites en objective-C sans chercher a etre identiques a "cocoa".

              bref , havoc cherche a promouvoir le choix de _un_ langage/framework plus évolué que C comme evolution de gnome, mais pas de dire "migrons à bidule et soyons compatible à vie"
            • [^] # Re: Havoc Pennington se pose des questions les langages du libre

              Posté par  . Évalué à 1.

              Apple n'a pas pour habitude de faire mumuse comme certains a changer leur spec pour limiter la compatibilité.
              De plus ils ont des documentations pour les developpeurs en général très détaillées, et completes.
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à -1.

      Perso je ne crois pas que Perl soit fait pour cela, la gestion des objets est un peu lourde. Ne connaissant pas Ruby, je crois que le Python est le langage qu'il faut.
      • Il n'a pas de problème de licence car il est sous GPL.
      • Sa dynamique de développement me semble bonne.
      Ma selection : Python
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

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

      Un petit bench pour alimenter la bête poilue : http://www.osnews.com/story.php?news_id=5602&page=3(...)

      Etonnant non ?!?
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à 1.

      Je ne parlerais que de Python language que je connais le mieux dans la liste, oui python est plus lent voir beaucoup plus lent pour certain taches que les languages compilés, mais il a pour lui une trés grande facilitée d'utilisaiton et une bonne integration des autres languages.

      De plus oui il est possible d'optimiser du code python en le transformant en java via Jython, en utilisant divers librairies comme Psyco ou autre, mais il reste tous de même plus lent que les autre de part sa nature interpretée.

      Mais est ce réellement un probléme ?
      Pour un noyau ou une bibliotheque graphique surment, mais il y a beaucoup d'autre domaine ou la facilitée de developpement et la rapiditée de developpement sont des attouts bien plus important.

      Personnellement, ce qui me fait aimer pyhton et paradoxalement un des points qui rebute beaucoup de monde, c'est son indentation trés stricte, qui fait maintient une lisibilitée du code trés appreciée quand l'on bosse a 4 sur les même fichier ;-)
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

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

        Je vais rejoindre un peu ce que tu dis ici.

        En tant que codeur, j'adore le Python depuis que je m'y suis mis : concision, clarté (bon, on peut aussi faire du python illisible), indentation stricte, et surtout rapidité de développement assez spectaculaire.

        En tant qu'utilisateur de mes propres réalisations (un daemon type mrtg, quelques GUI, des scripts pour me simplifier la vie), la vitesse d'exécution ne m'a jamais parue pénalisante.

        Par contre, je pense que son inconvénient majeur est la quantité de mémoire nécessaire. Je suis en train de faire un client bittorrent en Python/Qt : c'est tout de suite 35 Mo de RAM utilisés avant même d'avoir ajouté un torrent (dont 30 Mo en "shared", mais je ne sais pas quelle quantité est effectivement partagée).
  • # Re: Havoc Pennington se pose des questions les langages du libre

    Posté par  . Évalué à 1.

    Vu que le troll sur les bières n'a pas pris sur GTK, on devrait peut-être le retenter ici ;)

    Sérieusement, cet article ne me semble pas à ce point un nid à troll. Je dirais même que venant de Havoc Pennington, je suis un peu déçu, vu que je trouve son article très modéré et argumenté... mais peut être trop lisse et enfonçant des portes ouvertes. Bref, un bon point de départ pour le débat, mais pas le débat lui-même.

    Peut-être qu'on devrait demander à MDI une réponse officielle ;)
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à 1.

      ou à RMS :p
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  (Mastodon) . Évalué à 1.

      C'est pas tant ses arguments que le choix des deux plateformes proposées, qui est un nid à troll :-)

      D'autant plus que si j'ai bien compris (j'ai lu ça hier un peu dans le brouillard, et là je dois partir), il envisage l'adoption de Mono mais pas des parties dépendant de MS... ce qui fait perdre beaucoup de son intérêt à Mono (plus moyen de lancer les applications faites pour Windows.NET®©).

      Après, le fait d'adopter un Java version libre, pourquoi pas, même si j'ai des raisons (techniques) de n'aimer ni le langage ni la plateforme, ce sont des opinions sujettes à débat/troll, au choix :-)
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

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

        oui tu as du lire dans le brouillard.
        L'ambition est double, il y a 2 "piles" d'API pour mono : d'un côté ils essai d'avoir un vrai toolkit pour gnome et de l'autre une compatibilité avec Microsoft pour faciliter la migration des futurs appli que les développeurs sous Windows vont bientôt devoir programmer à l'aide de .NET (because longhorn)...
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

        Posté par  . Évalué à 1.

        "D'autant plus que si j'ai bien compris (j'ai lu ça hier un peu dans le brouillard, et là je dois partir), il envisage l'adoption de Mono mais pas des parties dépendant de MS... ce qui fait perdre beaucoup de son intérêt à Mono (plus moyen de lancer les applications faites pour Windows.NET®©)."

        Mono est une implémentation des spécification de la plateforme .Net (Compilateur Just In Time, Langage intermédiaire et compilateur C# -> Langage intermédiaire)
        Mais Mono inclus aussi les librairies Microsoft, des bindings pour pouvoir utiliser windows.form et autre... Et ne comptent pas l'abandonner.

        Ce que cherche Gnome est évidement un langage, le toolkit derière ils l'ont deja : GTK.
        Donc Mono est une proposition tout autant que Java ce qui est normal (Bien que Objective-C, Python et Ruby devrait être serieusement envisagés à mon avis) apprès chacun peut tenter du FUD sur le fait que la spec ait été faite par microsoft... (Je rapelle pour les trolleurs habituels que microsoft as choisi un organisme de normalisation qui impose que les brevets ne puissent pas empécher l'utilisation de la norme)

        Quant aux parties spécifiques de toute façon elles ne sont pas utilisables et n'ont même pas été normalisés (Mono les implémente et donc risque des problèmes sur ce point là et ils en sont concients) windows.form contiens par exemple la boucle des messages windows ce qui sous autre chose (GTK, QT) ne veut strictement rien dire.
        • [^] # Re: Havoc Pennington se pose des questions les langages du libre

          Posté par  . Évalué à 1.

          Mais Mono inclus aussi les librairies Microsoft, des bindings pour pouvoir utiliser windows.form et autre... Et ne comptent pas l'abandonner.

          Les bindings windows.form (qui se basent sur wine pour l'affichage des widgets windows, d'ailleurs) c'est juste un "bonus", le noyau de Mono c'est la partie standard. D'ailleurs, ils disent bien qu'en cas de problemes juridiques ils pourront toujours abandonner les parties qui posent probleme (ce qui ne peut pas arriver a la partie standard). Mono servira principalement a utiliser Gtk#.

          Au pire, il n'y aura pas de compatibilite entre .net et mono, ce qui ne veut pas dire que mono n'aura pas d'interet.
        • [^] # Re: Havoc Pennington se pose des questions les langages du libre

          Posté par  . Évalué à 2.

          Je rapelle pour les trolleurs habituels que microsoft as choisi un organisme de normalisation qui impose que les brevets ne puissent pas empécher l'utilisation de la norme
          Ce n'est pas exact.
          L'ISO n'empêche en rien l'utilisation de la norme par des brevets.
          L'ECMA impose que la licence d'utilisation des brevets soit "non-disciminatoire".
          Oui, mais même avec un prix particulièrement non-disciminatoire du genre 0.01€, il devient impossible de livrer un soft GPL basé sur ces brevets, car les utilisateurs ne pourront plus librement copier le logiciel (cherchez la clause 7 de la GPL).

          Just my 2¢

          Ps : l'explication n'est pas de moi, je l'ai lu sur la ML mono-list et j'ai très bien pu en déformer une partie par mégarde, mais le sens doit être là.
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à 1.

      En fait, il y a quand même certains trous dans son argumentation, en particulier en ce qui concerne ses interrogations au sujet de .NET et des brevets, comme le souligne MDI par ex ( http://primates.ximian.com/~miguel/all.html#3%2F18%2F04%202%3A00%3A(...) ), Sun a probablement breveté certains bouts des API de Java.
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

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

        MDI a à travers ce post bien résumé la situation, sans réellement annoncer des certitudes quand aux problèmes des brevets. La conclusion donne par contre son avis sur la situation :
        But this is similar to what happens to biology students: on their first
        four semesters as they learn about all the dangers, infections, vectors
        for infections and bacteria, they stop eating everything, they start
        washing their hands with special products, they double clean their
        utensils, they wash their fruits ten times a day.

        Two years later they are eating food with their bare hands again.


        Tout est dit...
  • # Re: Coquille dans le titre !

    Posté par  . Évalué à 7.

    Havoc Pennington se pose des questions les langages du libre
    il manque un sur, c'est sûr !
  • # Re: Havoc Pennington se pose des questions les langages du libre

    Posté par  . Évalué à -1.

    Sa réflexion semble au final plus se porter sur la façon de faire du tort à Microsoft plutôt que sur l'interet purement technique des langages.

    C'est une approche un peu partisane qui n'est pas necessairement des plus pertinentes...
    • [^] # Re: Havoc Pennington se pose des questions les langages du libre

      Posté par  . Évalué à 4.

      non

      il dit qu'il veut éviter de favoriser microsoft au DETRIMENT du libre

      qu'on le veuille ou non, OUI TOUT EST PARTISAN, en particulier la communauté GNOME est partisan _du libre_

      et si on estime que microsoft fait tout pour empècher le simple _emploi_ du libre, alors oui, ils sont anti microsoft.

      mais c'est seulement ds ces cas là

      et encore une fois, utiliser MONO, ne veut _pas_ dire utiliser tout .NET et partir à vie dans la compatibilité des classes .net windows

      gtk# !


      heu au fait, la maturité et l'adoption de gnome ou kde et du libre en général fait du tort à microsoft. ben vi.
      cela fait "moins" de tort à des entreprises comme sun ou ibm parce qu'elles essaient de composer avec. donc on se formalise pas sur elles.

      >C'est une approche un peu partisane qui n'est pas necessairement des plus >pertinentes...

      Havoc a absolument pas orienté son commentaire en "tuons microsoft", sinon il ne tolererait meme pas l'usage de gtk# par quelques applications en préparation ds gnome.

      bref : hors sujet!
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

        Posté par  . Évalué à 2.

        heu au fait, la maturité et l'adoption de gnome ou kde et du libre en général fait du tort à microsoft. ben vi.

        Suffit de voir comme Microsoft attaque Linux par tous les moyens...

        voir http://www.microsoft.com/france/lesfaits(...) pour comprendre qu'ils ont peur...
      • [^] # Re: Havoc Pennington se pose des questions les langages du libre

        Posté par  . Évalué à 0.

        Combining Java and Linux is interesting from another standpoint: it merges the two major Microsoft-alternative platforms into a united front.

        How Quickly Can .NET Win?

        Plutôt guerriers comme tournures de phrases non ?

        Et 18 fois on trouve le mot "microsoft" dans son article.

        On ne me fera donc pas croire qu'il n'oriente pas ses choix techniques en fonction de cet aspect des choses.

        Ce ne sont plus des arguments techniques objectifs à partir de ce moment la. Il en a parfaitement le droit. Mais à titre personnel je ne trouve pas ça très pertinent.
  • # Le titre ne veut rien dire

    Posté par  . Évalué à 1.

    "Havoc Pennington se pose des questions les langages du libre"
    Il manque un mot? (je penche pour "SUR les langages du libre")
    honnêtement, des erreurs comme ça ne devraient pas passer. Je veux bien que les modéros manquent de temps, mais quand même.

    (tant que je suis à pinailler, j'aurai enlevé "à choisir l'attitude" ça alourdit la dernière phrase pour rien, mais bon, je pinaille...)

    Ce serait vraiment bien de pouvoir faire ce genre de commentaires à part.
    Déjà, ça n'apporte rien aux lecteurs. Seuls les modéros devraient pouvoir lire ces remarques. De plus, ça oblige les modéros à à lire les commentaires du site alors qu'ils peuvent avoir d'autres choses à faire (au hasard, modérer des news :)
    Le mail @modérateurs n'est pas à mon avis une solution (y'a déjà assez de news en attente pour en plus noyer les modéros sous 36 mails pour des fautes d'orthographe)
    Avant on pouvait cocher son commentaire à -1 directement pour qu'il ne soit pas affiché, c'était bien car ça permettait d'éviter aux visiteurs la lecture d'un commentaire inintéressant. Ça manque vraiment.

    En fait ce qui serait vraiment bien, c'est une tribune supplémentaire qui ne soit pas en première page mais qui apparaisse sur la page d'admin, pour que les modéros puissent facilement la consulter.
    Exemple de cas d'utilisation: je lis une news, j'aperçois une faute. Dans une boîte supplémentaire quelque part sur la page de commentaires, j'ai un lien pour examiner la tribune de correction (histoire de pas poster la même remarque 42 fois) et un textbox pour taper la remarque. Le titre de la news pourrait apparaître automatiquement en début de post pour que ce soit plus clair.

    Je crois pas que ce soit optimal, et je suis sûr qu'en cherchant un peu on trouverait une meilleure solution, mais je pense que ça permettrait:
    1. d'éviter à tout le monde ces commentaires inutiles,
    2. de faire gagner du temps au modéros (s'il y en a qui parcourrent vraiment les commentaires à la recherche de ce genre de remarques)
    3. d'augmenter la qualité des news grâce à la correction d'erreurs plus rapide et plus efficace.
    Bon après pour ce qui est de coder, temp1337 c'est pas mon truc, ça me fait mal à la tête quand j'essaie de le lire
    • [^] # Re: Le titre ne veut rien dire

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

      > Avant on pouvait cocher son commentaire à -1 directement pour qu'il ne soit pas affiché

      Une idee comme ca si quelqu'un me lit: faudrait permettre a n'importe qui de voter pour soi-meme lorsque le vote est negatif... Ca devrait pas etre compliqué a faire, si ?
      • [^] # Re: Le titre ne veut rien dire

        Posté par  . Évalué à 1.

        C'est faisable ("Envoie un patch"), mais je doute sérieusement du bien fondé de la chose : Si un commentaire est négatif c'est que la majorité des votants veulent le dissimuler, et donc ce serait clairement s'opposer au système actuel. L'absurdité de la chose me travaille... Pourquoi veux tu donc pouvoir faire ça ?
        • [^] # Re: Le titre ne veut rien dire

          Posté par  . Évalué à 1.

          Parfois on veut poster quelquechose de marant ou lancer un troll pour s'ammuser et on se dit que ce serait bien qu'il commence à -1 comme ça les gens qui cherchent des discussions intéressantes ne l'auront pas en plein milieu.
          • [^] # Re: Le titre ne veut rien dire

            Posté par  . Évalué à 1.

            Hmmm à la lecture de ton post je me rends compte que je n'avais pas compris le message précédent. Je pensais qu'il voulait pouvoir plussoyer alors que son score est négatif, et non se moinssir volontairement. Donc rien à voir avec la choucroute.
            En effet le rétablissement du -1 serait une bonne chose pour pouvoir troller sans se faire descendre, mais peut-être est-ce justement ce que les admins ne veulent pas ? :)
  • # Re: Havoc Pennington se pose des questions les langages du libre

    Posté par  . Évalué à -2.

    C'est n'importe quoi ces débats sur ces langages de haut niveau... il n'y en a qu'un seul, un vrai, qui en qq lignes peut correspondre à des projets de centaines de millier de ligne de code en java ou aute : l'indien. Le seul problème est qu'il prend quelques $$$ en paramètre :-)
  • # On oublie toujours OCaml

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

    Encore une fois, lorsque l'on parle de langage de haut-niveanx performants, on
    oublie OCaml : www.caml.inria.fr

    Et pourtant, ce langage a de très nombreux avantages, mais il reste confiné dans son image de langage de chercheur sans intérêt. Rappelons quand même que ses inventeurs étaient à la base des hackers C (juste comme ça, Xavier Leroy a réalisé une ancienne implémentation de la bibliothèque thread de Linux...).

    Alors, pour ne citer que quelques uns des avantages de ce langage qui gagne à être connu :
    - il est libre
    - c'est un langage formelle (de la famille de ML), avec la puissance d'expressivité que cela engendre
    - néanmoins, il implémente des notions de langages impératifs, en particulier pour tout ce qui est gestion système (entrée/sorties, etc)
    - il possède une couche objet (d'où le 'O' de Ocaml ;)
    - il peut être compilé en byte-code ET nativement
    - son compilateur est très bon, et implémente toutes les caractéristiques des compilateurs modernes de langages de haut niveau (garbage collector efficace entre autre)
    - il peut utiliser les bibliothèques C
    - il possède un système de modules formidables : les modules peuvent être paramétrés par d'autres modules, je vous laisse imager la puissance de la chose...
    -Xavier Leroy est un mec passionnant à écouter (hmm... bon un peu HS :)

    Bref, c'est un langage auquel la communauté aurait intéret às'intéresser, même s'il demande un petit effort d'adaptation au mécanisme formelle (mais une fois que le coup est pris, on ne peut plus s'en passer. Et puis on ne va âs se comporter en immobilistes frileux de sortir des sentiers battus du C/C--...)
    • [^] # Re: On oublie toujours OCaml

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

      Et pourtant, ce langage a de très nombreux avantages, mais il reste confiné dans son image de langage de chercheur sans intérêt. Rappelons quand même que ses inventeurs étaient à la base des hackers C (juste comme ça, Xavier Leroy a réalisé une ancienne implémentation de la bibliothèque thread de Linux...).

      C'est toujours celle de la glibc, si je ne me trompe (mais c'est plus lui qui la maintient) : http://pauillac.inria.fr/~xleroy/linuxthreads/(...)

      (HS mais bon... je peux pas résister: c'est mon oncle ;-))
      • [^] # Le deuxième effet OCaml

        Posté par  . Évalué à 1.

        D'autres posts de cette page rappellent les qualités techniques de OCaml
        (concision de la syntaxe, vitesse d'exécution, etc.).
        Outre ces qualités importantes: n'oublions pas les qualités
        liées à la présence d'un interpréteur (comme c'est le cas pour LISP,
        perl, python...).
        Grâce à l'interpréteur on peut tester à chaud chacune des fonctions développées
        (en purement fonctionnel, tous les programmes sont des fonctions).
        On élabore ainsi en même temps le programme et ses tests.
        C'est à mon avis beaucoup plus confortable que les langages
        uniquement compilés
        (OCaml est compilable _ET_ interprétable):
        En C ou en Java on fait édition puis compilation puis édition des
        tests puis compilation des tests puis tests.
        Avec un langage muni d'un interpréteur on fait
        édition et tests en même temps, sans avoir à programmer les tests:
        on les appelle uniquement depuis l'interpréteur.

        Et _ça_, pour la vitesse de développement que ça entraine, c'est du
        "killer feature" mes amis! :O)

        P.S: le compilateur ocaml dérecursivise les fonctions récursives
        terminales, ainsi vos fonctions écrites en purement fonctionnel
        s'éxécutent en temps et place constante. Les compilateurs scheme
        savent aussi faire cela.
        • [^] # Re: Le deuxième effet OCaml

          Posté par  . Évalué à 1.

          En anglais c'est les functions appellées "tail recursive" ...
          • [^] # Re: Le deuxième effet OCaml

            Posté par  . Évalué à 1.

            Oui et la plupart des compilateurs modernes savent gerer les fonctions tail recursives, ce n'est plus limité au Scheme. Bref un peu de douceur dans le monde de brute des programmeurs en C :)

            Par exemple gcc transforme tres bien des fonctions recursives terminales en iteration; bon la je triche un peu il y a je ne sais plus qu'elle condition dessous qui est du au fonctionement interne de gcc.

            C'est active avec l'option :
            -foptimize-sibling-calls
            Optimize sibling and tail recursive calls.

            Enabled at levels -O2, -O3, -Os.
    • [^] # Re: On oublie toujours OCaml

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

      et eiffel hein ? le meilleur language objet du monde (oui Monsieur !)
    • [^] # Re: On oublie toujours OCaml

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

      Just for fun :


      > Y a t'il des projets de portage de Caml vers l'Universal Runtime faisant
      > partie du framework .net de microsoft ?

      Yes. In the spring of '99, Microsoft Research approached us, along
      with other academic groups working on modern programming languages, to
      work on this new technology. One of us (Bruno Pagano) has been
      working for about one year on a port of Objective Caml to the .net
      infrastructure, under support from Microsoft Research.

      Bruno has a prototype port that works relatively well (better than
      expected initially), but still shows that the .net common runtime
      system is not a perfect fit for OCaml.

      I'm not sure I can give more details (Microsoft may not have released
      all technical specs yet), but in summary, .net is a technology we
      follow closely, although it is still unclear whether it is the future
      of OCaml for Windows.
      • [^] # Re: On oublie toujours OCaml

        Posté par  . Évalué à 2.

        • [^] # Re: On oublie toujours OCaml

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

          Merci pour le 2ème lien je connaissais pas !
        • [^] # Re: On oublie toujours OCaml

          Posté par  . Évalué à 0.

          J'aimerais connaître l'intérêt d'un tel portage. Moi, quand j'utilise un langage, c'est pas pour sa syntaxe... je regarde sa vitesse, sa stabilité, ses caractéristiques internes...

          bref, je ne vois pas l'intérêt qu'on peut avoir à porter 10000 langages sur le même runtime.

          Si quelqu'un peut m'éclairer.
          • [^] # Re: On oublie toujours OCaml

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

            bah l'intérêt c'est justement ne plus avoir à se soucier de la vitesse, de la stabilité, des caractéristiques internes... et de justement ne plus avoir qu'à choisir la syntaxe la mieux adaptée au contexte : tous les langages auront le même genre de perfs (à la qualité du code généré par le compilo bien sûr), auront laccès à tous les API écrit dans n'importe quel langage, bref, voilà le gros intérêt... Et pour MDI c'est ne plus avoir à se soucier de l'interopérabilité entre tout ça, ne plus s'enmerder à faire des bindings, bref, gagner du temps tout en ne limitant pas le choix du langage pour le programmeur.
            • [^] # Re: On oublie toujours OCaml

              Posté par  . Évalué à 2.

              Ce que je voulais dire c'est choisir un langage pour favoriser telle ou telle qualité.
              Avec le runtime commun, il n'y a aucun moyen de privilégier un aspect particulier d'un langage.

              Que je programme en C ou VB, la vitesse d'exécution sera la même.
              Alors que moi je choisirais le C quand l'application devra être rapide, et le VB lorsque l'application nécessitera des capacités de plugins évoluées.

              Tant qu'à faire, autant créer un langage mieux adapté au runtime plutôt que d'adapter par je ne sais quel moyen d'autres langages dont les qualités spécifiques sont perdues.

              Pour finir, si des gens se donnent la peine de créer de nouveaux langages, c'est pas pour inventer une nouvelle syntaxe, mais pour apporter des nouveautés internes.
              • [^] # Re: On oublie toujours OCaml

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

                Et tu vas râler si ton appli en VB va tourner aussi vite que ton appli en C ?
                Si t'as vraiment besoin d'aller vite vite vite, tu utiliseras un langage qui autorise l'utilisation des pointeurs, genre C++ ou C# et zou.
                Pour la création d'un langage mieux adapté au runtime, c'est ce qu'ils ont essayé de faire avec C#.
                Sinon ils sont partis d'un constat simple : la plupart des langages modernes utilisent la notion de programmation objet. Ils se sont donc servit de ça pour factoriser les points communs entre les langages, tout en essayant de garder le maximum de possibilités.
                S'il n'y a qu'une seule plateforme commune, une seule plateforme est optimisée et profite à tous les langages : tous les efforts sont portés sur la même plateforme.
                Je rajouterai que de toute façon tous les langages ciblent une architecture matérielle, donc cibler .NET n'est pas plus dur et tu peux faire les même "nouveautés" internes. Seulement si tu créés un nouveau langage, rien ne t'empêche de proposer un API révolutionnaire dessous, tu pourras en plus en faire profiter tous les langages et tu pourras profiter des API créés dans les autres langages sans avoir à te soucier de l'interopérabilité.
                De plus tu n'aura pas besoin de recoder une VM pour chaque nouvelle architecture, une seule plateforme sera portée.
                De plus imagine le potentiel de ton nouveau langage : il est directement exploitable avec un nombre impressionnant d'API, les utilisateurs potentiels pourront être séduit par la syntaxe sans avoir à réapprendre de nouveaux API...
                • [^] # Re: On oublie toujours OCaml

                  Posté par  . Évalué à 2.

                  Pour te répondre une dernière fois, je vais prendre un exemple concret.

                  J'ai des collègues qui ont développé une application pour tester des appareils de mesures quelconques. Leur application devait tourner pendant environ 4 jours pour effectuer les tests.

                  Ils l'ont développé en VB .NET et par manque de chance ont eu des problèmes de mémoire car le GC ne fonctionne pas correctement sur .NET. Leurs tests s'arrêtaient au bout de 2 jours avec un message du genre plus de mémoire.

                  Alors, on peut se dire qu'il fallait choisir un langage avec une meilleure gestion de la mémoire, mais c'est le runtime qui la gère donc ça ne changera rien.

                  Voila pourquoi je dis qu'on choisit un langage pour ses qualités internes et non pour sa syntaxe.

                  La seule chose qu'apporte le runtime commun, c'est la généralisation des défauts et la perte des qualités spécifiques.
                  • [^] # Re: On oublie toujours OCaml

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

                    Ben, voyons, et dis comme ça je vais gober l'excuse que c'est la faute à .NET... et pourquoi ça ne serait pas la faute du programme ? et pourquoi pas celle de l'OS sous-jacent ? Dans le premier cas, tu sais ce qu'il faut faire, dans le 2ème, on parle ici de linux...
                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 1.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: On oublie toujours OCaml

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

                        BOon bah voilà t'as trouvé le coupable (il était dur à trouver...) ! Bref rien à voir avec le sujet, qui est quand même Mono sous Linux...
                        • [^] # Re: On oublie toujours OCaml

                          Posté par  . Évalué à 1.

                          T'as du mal à comprendre le terme "exemple", ça peut arriver pour d'autres points avec Mono, et le fait de changer de langage n'y fera rien.

                          Ce que je voulais dire, c'est que tu pourras pas dire : "y'a un bug, je vais prendre tel langage, réputé pour être très fiable", même un langage super fiable deviendra dépendant de ton runtime commun.
                          • [^] # Re: On oublie toujours OCaml

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

                            désolé je préfère laisser le plus de problèmes possible à la VM, j'ai plus confiance dans la fiabilité de la VM que dans la fiabilité de ce que j'écris. C'est plus fort que moi. Si tu préfères tout faire à la main, le GC, etc. c'est toi qui vois.
                            Sinon je suis d'accord sur le fait qu'on ne choisi pas un langage parcqu'il est réputé pour être fiable (d'ailleur ça veut pas dire grand chose pour un langage). Evidemment que tu resteras dépendant du runtime, comme tu resteras dépendant du compilateur, que tu restera dépendant d'un OS, que tu resteras dépendant des API proposés à ton langage, etc. Je préfères factoriser les problèmes et essayer de fiabiliser une seule VM. Bref y'a le même problème partout, pas plus sur .NET qu'ailleur.
                            • [^] # Re: On oublie toujours OCaml

                              Posté par  . Évalué à 2.

                              Ecoute j'ai développé en C sous Linux. Quand il y avait un bug, je n'ai jamais eu besoin de regarder si il y avait un bug dans le système, le langage ou n'importe ou ailleurs. J'avais juste à trouver MON erreur.

                              Depuis que je développe en VB.NET je passe mon temps à chercher le problème de .NET. C'est clair, il y a plus souvent des erreurs dans .NET que dans mon programme.
                              • [^] # Re: On oublie toujours OCaml

                                Posté par  . Évalué à 1.

                                Tu peux me donner des exemples precis ? Des bouts de code qui montrent le probleme ?

                                Je serais ravi que tu me les envoie (nvidiatnt atte hotmail poing com)
                      • [^] # Re: On oublie toujours OCaml

                        Posté par  . Évalué à 1.

                        Je serais ravi d'avoir ce lien, parce que bon, tu vas trouver ca drole, mais j'y crois pas.
                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 1.

                          Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: On oublie toujours OCaml

                            Posté par  . Évalué à 1.

                            Petit exemple pour montrer qu'il raconte n'importe quoi :

                            #include <stdio.h>
                            #include <stdlib.h>

                            #define COUNT 32
                            #define MAX (2<<23)/COUNT

                            int main(int argc, char *argv[])
                            {
                            srand(5);
                            char **Array=new char*[MAX*COUNT];
                            printf("Size: %d\n",MAX*COUNT);
                            for(int i=0;i<MAX*COUNT;i++)
                            {
                            Array[i]=new char[(rand()%COUNT)+2];
                            Array[i][1]='2';
                            }
                            printf("finished allocating\n");
                            for(int i=0;i<MAX*COUNT;i++)
                            delete[] Array[i];
                            delete[] Array;

                            return 0;
                            }

                            Ce code alloue 16 million d'elements de taille aleatoire entre 2 et 34 +1 elt de taille 16 million, ecrit un byte dans chaque allocation, et les desalloue.

                            Sur ma workstation qui a 512Mo de RAM (210 utilises avant le lancement), il fait monter l'usage jusqu'a 750Mo, donc il tappe dans le swap assez mechamment.
                            Il met 20s pour desallouer les 16 millions d'elements.

                            Bref, loin, tres loin de ce qu'il raconte et les temps sont a peu pres comparables sous Linux.
                  • [^] # Re: On oublie toujours OCaml

                    Posté par  . Évalué à -1.

                    C'est pas parce que microsoft programme avec les pieds qu'il faut faire pareils.

                    Pour le garbage collector j'ai jamais aimé ces petites bêtes, ...
                    Je programme en pascal et un monObj := TObj.Create; qui est pas suivi par un monObj.Free quelquepart je trouve ça déroutant au possible.

                    Quelqu'un pourait nous faire la liste des avantages d'un GC ici, je parle de vrais avantages, supléer à un modèle de programmation fait avec les pieds à tel point que l'on en oublie de libérer des objets n'est pas un avantages, c'est un cache misère.
                    • [^] # Re: On oublie toujours OCaml

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

                      Parcque quand on programme en objet, il y a tellement de dépendance entre eux qu'il est parfois difficile de juger du moment opportun pour le delete (ou free). le GC trace en permanence les objets utilisés et choisi un moment "calme" pour le faire, cad quand le programme utilise moins de ressources. De plus comme toujours il faut mieux faire confiance au GC qui a moins de chance de se planter que le programmeur : il faut mieux automatiser tout ce qui peut l'être, c'est une source de bug en moins (si le GC ne l'est pas bien sûr).
                      • [^] # Il y a un monde meilleur sans GC!

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

                        Je suis bien d'accord sur le fait d'automatiser tout ce qui peut l'être.

                        Comme à chaque fois que l'on discute de GC, il y a unanimité pour dire que c'est un attribut indispensable d'un langage moderne, et hop, on se focalise sur les détails du GC.
                        Je rappelle quand même que le problème de base, ce sont les fuites mémoire, et que le GC n'est qu'une des réponses à ce problème.

                        Mais comme il vaut mieux prévenir que guérir, la meilleure réponse c'est quand même que la sémantique du langage empèche les fuites de mémoire.

                        Alors savoir si l'algo est plus ou moins optimisé, si il consomme le temps CPU de façon déterministe, distribuée, intelligente, etc., et bien il faut le savoir : on peut aussi dormir sur ses deux oreilles sans jamais se poser ce genre de problèmes.

                        (pour l'anectote, c'est signé d'un utilisateur heureux d'Ada).
    • [^] # Re: On oublie toujours OCaml

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

      Son compilateur est d'ailleurs tellement performant qu'il obtient un score supérieur à g++, et quasi-identique à gcc sur le test suivant :

      http://www.bagley.org/~doug/shootout/craps.shtml(...)

      Quand on se rappelle que ce langage possède un garbage collector, l'inférence de type, des exceptions... et bien d'autres choses encore.
    • [^] # Erlang a également été oublié

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

      Et oui, le langage Erlang n'est pas mentionné. Et pourtant, il propose des caractéristiques fort moderne qui en font un langage qui doit compter à l'avenir.

      Pour mémoire, Erlang offre les caractéristiques suivantes:
      - Distribution - Erlang est conçu pour fonctionner en environnement distribué. Une machine virtuelle Erlang constitue en fait ce que l'on nomme un «noeud» Erlang. Les processus s'exécutant sur différents «noeuds» communiquent exactement de la même manière que des processus qui s'exécutent sur un «noeud» local. La distribution des traitements est transparente pour le développeur.
      - Robustesse - Erlang dispose de fonctions standards de détection d'erreurs qui peuvent être utilisées pour bâtir un système «tolérant aux pannes» et notamment capable de gérer les erreurs logiciels (bugs).
      - Mise à jour du code «à chaud» (Sans interruption des traitements en cours) - Certains systèmes ne peuvent pas être arrêté, même pour mettre à jour les programmes. Erlang permet de mettre à jour ces programmes sans arrêter le système. L'ancien code peut-être neutralisé et remplacer par le nouveau code. Pendant la transition, l'ancien et le nouveau code peuvent cohabiter. Il est ainsi possible de corriger des bugs et d'installer de nouvelles versions sur un système sans perturber son fonctionnement.
      - Temps réel logiciel - Erlang permet de développer des systèmes temps-réel logiciel. Ces systèmes nécessite des temps de réponse de quelques millisecondes. Il n'est pas possible, dans ces systèmes de tolérer de longues phases de récupération de la mémoire (garbage collection). Erlang utilise donc des techniques de récupération mémoire incrémentales.
      - Machine virtuelle très optimisée, en particulier au niveau de la gestion de la mémoire. Par exemple, Yaws, le serveur Web Erlang, utilise le plus souvent moins de 10 Mo de RAM. Il est possible de compiler le code critique de manière native.

      Erlang est aujourd'hui utilisé, entre autres pour des applications critiques:
      - Dans le domaine des télécommunications,
      - Dans le domaine bancaire,
      - Dans le domaine du jeu vidéo,
      - Comme plate-forme de serveurs d'applications pour le développement d'applications Web robustes.

      Allez, jeter un oeil sur www.erlang.org

      Mickaël

      • [^] # Re: Erlang a également été oublié

        Posté par  . Évalué à 1.

        Ton commentaire m'a réellement intéressé et j'ai donc voulu voir à quoi ça ressemble.
        Utilisant une Debian, j'ai regardé si un paquet était disponible.

        Effectivement il y en a un mais il est classé en non-US.

        Il me semble que les non-US sont interdits pour cause de cryptographie ou un truc dans le genre. Du coup je ne sais pas si c'est l'idéal pour le futur de Gnome.
        • [^] # Re: Erlang a également été oublié

          Posté par  . Évalué à 1.

          actuellement c'est surtout les brevets logiciels (qui n'existent pas encore en Europe, mais il va falloir lutter pour que ça dure) qui obligent certains softs à être dans non-US

          tiens à propos j'arrive plus à vérifier les signatures des non-US (nouvelle clé ou nouvel apt ?)
        • [^] # Re: Erlang a également été oublié

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

          Je pense que la partie non-us est lié à SSL. Tu peux compiler Erlang sans le support SSL.

          Mickaël

      • [^] # Re: Erlang a également été oublié

        Posté par  . Évalué à 1.

        Mais ce n'est pas typé, malgré quelques travaux sur le sujet. Personnellement, ça me pose un gros problème qu'un langage ne soit pas fortement typé.
        • [^] # Re: Erlang a également été oublié

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

          Si tu regardes ce qui a été développé en Erlang, tu verras que des systèmes robustes, critiques, gigantesques comme un routeur ATM ou un système bancaire ont été développés en Erlang.

          Alors, oui théoriquement cela peut sembler gênant et certains s'offusquent de ne pas trouver de typage statique fort en Erlang. En pratique, cela ne pose pas de problème et les études faites par Ericsson sur le sujet ont montré qu'il y avait peu d'erreurs liées au typage dans le code Erlang.

          Si tu ajoute à cela les fonctionnalités que les autres langages n'ont pas (Séparation complète des données gérés par les processus légers Erlang: Une erreur dans un processus ne peut pas contaminer le reste du système, Mécanisme de gestion des erreurs au travers d'un arbre de supervision, distribution transparente de l'éxécution), tu peux voir qu'il y a final plus d'avantage que d'inconvénient à développer en Erlang.

          Mickaël

          • [^] # Re: Erlang a également été oublié

            Posté par  . Évalué à 3.

            Oui oui je connais bien Erlang et ses applications. Aucun doute sur le fait qu'il a fait ses preuves au niveau industriel dans des applis critiques. C'est un très bon langage. La gestion des threads me laisse froid mais le mécanisme de gestion des erreurs et la reconfiguration dynamique sont réellement intéressants.

            Mais par contre, l'argument d'Ericsson selon lequel il y a peu d'erreurs liées au typage me fait bien rire.

            Les programmeurs habitués à des systèmes de types évolués (comme celui d'OCaml) savent bien qu'un programme refusé à cause d'une erreur de type est généralement (ce n'est pas une loi mathématique mais une constatation) incorrect sur le plan conceptuel. Autrement dit, une erreur dans un programme Erlang, comme dans tout langage, serait une erreur de type pour un système évolué. Bon évidemment, je ne dis pas qu'on peut tout capturer, on sait bien que c'est impossible. Mais le système de types de Caml rattrape un nombre d'erreurs phénoménal.

            D'ailleurs des gens ont proposé des systèmes pour Erlang, notamment par inférence (cf travaux de Dagnat). Tout n'est pas réglé, mais ça risque pas de l'être si on ne fait pas de recherche dans cette direction.
            • [^] # Re: Erlang a également été oublié

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


              Les programmeurs habitués à des systèmes de types évolués (comme celui d'OCaml) savent bien qu'un programme refusé à cause d'une erreur de type est généralement (ce n'est pas une loi mathématique mais une constatation) incorrect sur le plan conceptuel. Autrement dit, une erreur dans un programme Erlang, comme dans tout langage, serait une erreur de type pour un système évolué.

              Absolument, et n'oublions pas non plus l'autre avantage d'un typage puissant : la sémantique en plus est dans le code (ce qui permet au compilateur de détecter les erreurs), et donc elle n'a pas besoin d'être dans les commentaires ou dans la doc.

              Ca fait du boulot et des incohérences en moins pour ceux qui font des docs... et des infos en plus de partagées dans le cas général :-)
    • [^] # Re: On oublie toujours OCaml

      Posté par  . Évalué à 4.

      Je pense que s/Formelle/Fonctionnel/ serait mieux, même si OCaml se permet aussi quelques fonctionnalités telles la validation formelle (cf. le prouveur COQ)

      Pour répondre à un commentaire plus haut sur la syntaxe, c'est important d'avoir un langage dont la syntaxe permet d'exprimer facilement des commandes et des structures adaptées à la résolution de tel ou tel problème. ( et pour les structures OCaml c'est vraiment trop d'la balle! )

      C'est pourquoi un programmeur (ou un décideur) devrait être plus sensible à adapter le choix du langage de développement au problème posé. (Et passer ainsi d'un paradisgme inpératif au fonctionnel, voire, au logique en fonction des tâches à accomplir).
      • [^] # Re: On oublie toujours OCaml

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

        Je pense que s/Formelle/Fonctionnel/ serait mieux, même si OCaml se permet aussi quelques fonctionnalités telles la validation formelle (cf. le prouveur COQ)


        ouitoutàfait, mes doigts ont fourchés...

        A ma décharge : c'est pasque je suis en plein rapport sur un bô projet utilisant Coq, et du coup j'ai du "formel" à tout bout de champ... m'en vais vérifié qu'il n'y ait pas eu quelques subsitutions formel/fonctionnel dedans d'ailleur...

        Donc OCaml est un langage fonctionnel bien sûr...
    • [^] # Re: On oublie toujours OCaml

      Posté par  . Évalué à 5.

      C'étaient pas des hackers C à la base. Caml est une création de Guy Cousineau, inspiré du métalangage ML de LCF et créé par Robin Milner.

      Xavier Leroy a tout repris à zéro pour sa thèse et a créé (pas tout seul bien sûr) plein de versions de Caml (Light, Special, Objective). Il se trouve qu'en plus d'être un excellent théoricien c'est aussi un putain de programmeur. Il a d'ailleurs développé les threads pour faire tourner Caml...

      Je ne suis pas sûr que l'implémentation soit libre au sens de la GPL. Il me semble que tu n'as pas le droit de diffuser une version modifiée des sources, mais uniquement des patchs. C'est assez libre pour moi, mais sûrement pas pour RMS.

      Sinon, tu connais beaucoup de langages de programmation qui ne sont pas formels, toi? La spécificité de Caml, c'est qu'on connaît (grosso modo) sa sémantique formelle, ce qui est différent. D'ailleurs, on la connaît à moitié. Je mets au défi quiconque de me sortir toutes les règles de sémantique (abstraite, opérationnelle, voire dénotationelle) et les preuves formelles associées (Church-Rosser, autoréduction, etc) de Caml tel qu'il est implémenté.

      Je connais pas de langage ne pouvant pas utiliser des bibliothèques C pour ma part. OK c'est plus ou moins difficile selon les implémentations. Et justement, c'est pas non plus ultra-facile en Caml, malheureusement.

      C'est vrai que les foncteurs (modules paramétrés) c'est génial mais c'est pas une invention de Caml non plus. D'ailleurs, il reste pour l'instant quelques limitations gênantes sur lesquels ils travaillent, au demeurant, avec notamment des recherches sur l'intégration des mixins (le monde est petit: ces derniers sont plus ou moins dus à Gilad Bracha qui fait partie maintenant de l'équipe de développement pour Java).

      Ces précisions faites, je suis tout à fait d'accord pour encourager à l'utilisation de Caml. Je ne vois personnellement pas de meilleur langage pour l'instant. Pourquoi est-ce le meilleur? Parce que l'équipe Caml est pragmatique et pas jusqu'au-boutiste. Ils veulent une sémantique claire et élégante mais aussi un langage réellement utilisable (un tant soit peu efficace, avec une stratégie d'évaluation "intuitive", etc). Comparé à Haskell, il est certes moins élégant sur le plan théorique, mais c'est un très bon compromis pour ce qu'on attend d'un langage sur les plans théorique et pratique.
      • [^] # Re: On oublie toujours OCaml

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

        Il me semble que tu n'as pas le droit de diffuser une version modifiée des sources, mais uniquement des patchs.

        oui, la licence des compilateurs est QPL. Mais la bibliothèque standard est LGPL.

        Et justement, c'est pas non plus ultra-facile en Caml, malheureusement.

        ça se fait quand même assez bien. Qu'est-ce qu'il y a comme languages où l'interfaçage est plus facile (hormis C++ et C#) ?

        C'est un très bon compromis

        Tout à fait.
    • [^] # Re: On oublie toujours OCaml

      Posté par  . Évalué à 1.

      Je pense qu'une des raisons pour laquelle pas grand monde s'interesse a OCaml, c'est la difficulté d'apprentissage (personnellement j'ai renoncé).

      Et la lisibilité d'OCaml est à mon avis inférieure à celle de Python ou Ruby..

      Les performances d'OCaml sont nettement supérieur certes, mais c'est aussi le cas pour le C..
      • [^] # Re: On oublie toujours OCaml

        Posté par  . Évalué à 2.

        Vrai, mais il n'y a pas que le difficulté d'apprentissage

        L'université m'a obligé à me mettre à OCaml.

        Au début ça m'a donné des boutons tout partout. Puis doucement on s'y fait. On fini prèsque par aimer. les boutons se font discret.

        Et puis on part de l'université, et par la force des choses et pour diverses raisons, on ne pratique plus. Et la on perd tout très vite, ce qui n'a pas été le cas pour d'autres langagages. Je serais aujourd'hui clairement incapable de m'y remettre.

        Par ailleur j'essaye d'arreter de fumer, alors ça ne m'enchante pas...
      • [^] # Re: On oublie toujours OCaml

        Posté par  . Évalué à 2.

        Le Caml parait difficile si tu as été habitué à programmer dans d'autres langages. N'étant pas habitué à programmer lorsque j'ai appris le Caml, celui-ci ne pas spécialement choqué. Pire, on finit par prendre du plaisir à implémenter des algos complexes en une poignée de lignes de code, le tout de manière tout à fait élégante.

        Mais mon principal point de désaccord porte sur la lisibilité. A l'heure d'aujourd'hui je dois avoir autant (voire un chouilla plus) d'expérience en Java qu'en Caml, et le sens d'un programme Caml me saute toujours bien plus vite aux yeux (concision, approche fonctionnelle ...).
        Je crois que le problème c'est d'arrêter deux secondes de penser itératif pour penser fonctionnel (on oublie les variables, les séquences, les for et les while .... ).

        Ma seule conclusion objective : la "non-lisibilté" de Caml ne peut que provenir des habitudes bien trop répandues de programmation impérative (ou alors objet).
      • [^] # Re: On oublie toujours OCaml

        Posté par  . Évalué à 1.

        C'est une question d'habitude.
        C'est vrai qu'il est plus difficile pour qqun qui connait C ou Java d'apprendre Caml que Eiffel ou Python.
        Mais une fois qu'on y est on y est on ne peut plus s'en passer et on se sent à l'étroit dans les autres langages. On plus on développe beaucoup plus vite... Moi je ne pourrais plus retourner à autre chose...
      • [^] # Re: On oublie toujours OCaml

        Posté par  . Évalué à 1.

        Pour ma part, j'avais une formation très technique (C/C++/Java/Cobol!/Perl) quand je me suis mis à Caml. Au départ ça a été l'horreur : j'aimais pas la syntaxe, j'avais juste l'impression de manipuler une calculette, j'avais un a priori contre le récursif, etc. Classique quoi!

        Et puis bon, j'étais bien obligé de m'y mettre pour les cours...

        Et là j'ai découvert l'élégance et la concision de la récursivité (avec une syntaxe adaptée bien sûr), un système de types statique très expressif et par inférence (ça c'est magique), l'ordre supérieur, le filtrage, la séparation entre monde fonctionnel et monde impératif...

        Et puis ensuite, passage à Ocaml avec ses objets bien plus intéressants qu'en Java et son système de modules (plutôt) évolué.

        Et là, on se demande comment on va encore pouvoir programmer dans les autres langages "old school". :-)

        De fait la syntaxe est très adaptée au style de programmation "applicatif".

        Pour ce qui est de l'efficacité, je suis toujours effaré de voir beaucoup d'informaticiens (notamment les hackers) tout ramener systématiquement à la rapidité et aux capacités d'optimisation. Faut-il que les sempiternels cours de génie logiciel mettant en avant l'abstraction, la réutilisabilité, l'orthogonalité, la maintenabilité, etc, n'aient eu aucune influence sur les étudiants!
    • [^] # Re: On oublie toujours OCaml

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

      Et en plus, il torche tous les autres langages sur le 'langages shootout':
      http://www.bagley.org/~doug/shootout/craps.shtml?xcpu=2&xmem=2&(...)
      (notons que je n'ai pas pris les paremetres par defaut, mais que j'ai file comme coef 2 a la memoire, 2 au cpu et 1 au nombre de ligne. Quoi qu'il en soit OCaml apparait toujours dans les trois premiers.

      Le probleme d'ObjectiveCaml, c'est que justement, c'est ni du C++, ni du Java, ni du C. Or a quoi sont formes les gens aujourd'hui ? La force de C++, C# et Java, c'est de se ressembler. Tu peux coder un java sans probleme si tu as appris le C++. ObjectiveCaml est un peu plus lourd. En plus, cote gui, c'est pas forcement la joie. Et puis, il lui manque des bindings pour KDE.
      • [^] # Re: On oublie toujours OCaml

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

        En plus, cote gui, c'est pas forcement la joie.

        L'interface GTK+ est trés complète. Et le support pour GTK 2.4 est pratiquement terminé.

        Certes y'a pas de bindings pour ta plateforme favorite (KDE) mais bon, vu le langage de barbare employé ça ne m'étonne pas.
        • [^] # Re: On oublie toujours OCaml

          Posté par  . Évalué à 2.

          Certes y'a pas de bindings pour ta plateforme favorite (KDE) mais bon, vu le langage de barbare employé ça ne m'étonne pas.

          L'allemand est une très belle langue.
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

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

    Voici une autre réaction aux propos de Havoc :
    http://www.advogato.org/person/lupus/diary.html?start=10(...)
    Evidement c'est partisant, vu que c'est un des développeurs principaux de Mono. Celà dis il reprend un à un tous les arguments de Havoc... A vous de juger...
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

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

    En parlant de .NET, voici un article de Edd Dumbil publié chez O'Reilly : Will Mono Become the Preferred Platform for Linux Development? (http://www.onlamp.com/pub/a/onlamp/2004/03/11/mono.html(...)) où il est question du projet Mono, de l'IDE MonoDevelop, de l'avenir du développement sous Linux et des prochaines évolutions de GNOME.
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 1.

    il doit être content le monsieur d'avoir un moteur de jeu à son nom.

    bon ,je --->[]
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 0.

    Quelqu'un sait ou en est le projet Mono ? Est ce qu'il est possible de développer des applis qui tiennnet la route ou bien est ce encore trop tot. En ce qui me concerne je n'ai jamais aimé Java, je n'ai pas forcement d'arguments techniques c'est juste un sentiment.
    A chaque fois que je vois du java, je pense a des barrettes de mémoire(c bizzarre non ?). Sinon d'un point de vue license n'y a t'il pas des problèmes a avoir la plateforme .NET sous linux ?
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à -10.

    Et-il possible de citer de vrai logiciel libre et pas ces grosses bouses que sont: Gnome, Mozilla, OOo et Evolution?
    Pour Gnome, la consomation en RAM (c'est pour cela qu'il est pres pour Java) est impressionante pour ce qu'il apporte. Un vrai VM ( + Rox)permet de faire mieux avec moins de ressources.
    Mozilla, c'est beau, mais c'est lourds. Les versions lights (Galeon , Epiphany) sont beaucoup plus interressantes.
    OOo, depuis la 1.1, ça va mieux, mais s'il faut a nouveau 30 secondes pour le lancer comme ce fut le cas avant, je conseil MS Office.
    Evolution, connait pas, c'est que ça doit pas être utile.

    On n'a pas tous le dernier PC à la mode, l'un des avantages de LL, c'est qu'ils sont souvent leger. Alors quand j'etant parler de Java pour les LL, je prend peur. Pour .NET, j'en sais rien.
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 7.

    > Havoc Pennington se pose des questions sur les langages du libre.

    Le fond de l'article n'est pas là. L'article s'attarde principalement sur la plateforme et non sur le language.
    .NET est une plateforme et C# est un language utilisé avec .NET .
    Havoc attaque principalement .NET et non C# (entre autre à cause des librairies .NET qui n'ont pas de spec).
    Si C# est utilisé au-dessus de Gnome, Havoc ne voit pas de problème. Par contre si l'ajoute de C# à Gnome implique d'offrir une plateforme .NET alors Havoc n'est pas du tout daccord. Par contre Havoc est moins opposé à offrir une plateforme JAVA. Entre autre car il y a gnuclass, une communauté java important, et de bonne relation entre la communauté java et Sun.

    Enfin l'une des plus grosse préoccupation d'havoc est d'éviter un fork de Gnome et de conserver le support des entreprises commerciales.

    La question du languages est presque annexe.
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      si, il y a bien une question des langages : .NET est indépendant du langage et donc laisse le choix à l'utilisateur, Java non. Basé le développement d'un API en Java limite son utilisation (même si y'a des bidouille pour utiliser dans d'autres langages, c'est pas ce qu'on appelle de l'intégration). Un environnement comme Gnome ne doit pas à mon avis limiter l'utilisateur dans le choix d'un seul langage. De plus la plateforme .NET permet réellement de faire des API plus "bas-niveau" de par l'interopérabilité avec le C (bien meilleur qu'en Java), la gestion des pointeurs et bien sûr la possibilité d'utiliser du code existant dans un des langages .NET.

      Et puis de toute façon c'est pas compliqué : on peut faire tourner du bytecode Java sur .NET (Mono) et l'inverse n'est pas possible. Techniquement c'est vite vu. D'un point de vue ethique, Sun a autant de brevets sur sa JVM que Microsoft sur son API haut niveau. Seulement voilà : l'API haut niveau peut être remplacé (et de toute façon il est dépendant de Windows donc pas utile sous nux, sauf pour des migrations), et les spécifs de la VM .NET sont normalisée ISOtifié et tout ce que vous voulez.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 1.

        > .NET est indépendant du langage
        .NET c'est une infrastructure de développement + une machine virtuelle. En théorie, c'est indépendant du langage, mais en pratique la machine virtuelle est fortement optimisée pour exécuter de C# (voire du java). En revanche les pour les autres lanages c'est pas toujours cela (cf. ocaml, eiffel...). D'autre part les librairies .NET ne sont pas libre et non standardisée.

        > Basé le développement d'un API en Java limite son
        > utilisation
        Pourquoi? J'utilise tous les jours les librairies Apache, et ma foi c'est pas pire qu'ailleurs.

        >Un environnement comme Gnome ne doit pas à mon avis
        > limiter l'utilisateur dans le choix d'un seul langage.
        Entièrement d'accord. C'est déja le cas aujourd'hui.

        > De plus la plateforme .NET permet réellement
        > de faire des API plus "bas-niveau"
        > de par l'interopérabilité avec le C (bien meilleur qu'en Java
        Pour accéder à des librairies en C depuis Java tu peux soit utiliser le JNI, c'est effectivement un peu lourd mais cela oblige à faire du code (au niveau java) peu près portable. Soit utiliser des interface spécifiques (type CNI pour gcj), c'est plus rapide, plus léger, mais c'est lié à ta machine virtuelle commen c#.

        > la gestion des pointeurs
        Le but c'est justement de s'en passer. Sinon on utlie du C ou du C++ et c'est tres bien.

        > bien sûr la possibilité d'utiliser du code
        >existant dans un des langages .NET.
        Pour ton info, plus de langages ont été porté en bytecode Java qu'en MSIL.

        >on peut faire tourner du bytecode Java sur .NET (Mono) et
        > l'inverse n'est pas possible
        C'est faux. Va regarder le site halcyon

        > D'un point de vue ethique, Sun a autant de brevets
        > sur sa JVM que Microsoft sur son API haut niveau
        Et d'un point de vue pratique ?

        > l'API haut niveau peut être remplacé (et de toute façon
        > il est dépendant de Windows donc pas utile sous
        > nux, sauf pour des migrations)
        Pas vraiment compris ce que tu as voulu dire.

        >et les spécifs de la VM .NET sont normalisée ISOtifié et
        > tout ce que vous voulez.
        Et tu crois que cela empéchera Microsoft de les modifier selon son bon vouloir. Rien ne les oblige. Faut pas être naif :-)).
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

          Posté par  . Évalué à 2.

          "Et tu crois que cela empéchera Microsoft de les modifier selon son bon vouloir. Rien ne les oblige. Faut pas être naif :-)). "

          Si le but est une compatibilité avec MSwindows je suis daccord que le changement des specs est un problème mais dans ce que l'on parle actuellement je vois vraiment pas.
          Si des programmes Gnomes sont developés sous Mono ils resterons compatibles avec Mono, c'est pas parce que microsoft change sa VM que Mono est obligé de suivre aveuglément, ...

          Donc argument HS
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

          .NET c'est une infrastructure de développement + une machine virtuelle. En théorie, c'est indépendant du langage, mais en pratique la machine virtuelle est fortement optimisée pour exécuter de C# (voire du java). En revanche les pour les autres lanages c'est pas toujours cela (cf. ocaml, eiffel...). D'autre part les librairies .NET ne sont pas libre et non standardisée.
          .NET a été conçu pour le langages intégrant la notion d'objet : c'est effectivement une restriction, mais tous les langages modernes semble intégrer cette notion.
          Pour ce qui est de l'implémentation des autres langages, wait&see... tu as testé pour juger de la qualité des compilateur et du code généré ?

          D'autre part les librairies .NET ne sont pas libre et non standardisée.
          Si les parties indépendantes de l'OS. Les parties "hautes", surtout les WinForms ne sont pas standardisées. Est-ce un problème sous Linux où l'on veut plutôt utiliser GTK ou Qt ?
          Pourquoi? J'utilise tous les jours les librairies Apache, et ma foi c'est pas pire qu'ailleurs.
          Ah tu l'utilises dans n'importe quel langage ? Ou alors t'as triché et tu fais tourner du bytecode Java au dessus de Mono ;)

          Pour accéder à des librairies en C depuis Java tu peux soit utiliser le JNI, c'est effectivement un peu lourd mais cela oblige à faire du code (au niveau java) peu près portable. Soit utiliser des interface spécifiques (type CNI pour gcj), c'est plus rapide, plus léger, mais c'est lié à ta machine virtuelle commen c#.
          et c'est où le problème ?
          Le plus impressionnant c'est C++, tu peux mixer du code .NET et du code C++ traditionnel, ça marche (me demande pas comment) très bien. Si .NET peut être un point de rassemblement pour les API ca me paraît déjà pas mal...

          Le but c'est justement de s'en passer. Sinon on utlie du C ou du C++ et c'est tres bien.
          Non le but c'est de laisser le langage décider. Tu utilises un langage qui ne gère pas les pointeurs si tu veux. Mais faut laisser le choix. Notamment pour utiliser du code C c'est bien pratique, mais aussi pour des algo bas-niveau.

          Pour ton info, plus de langages ont été porté en bytecode Java qu'en MSIL.
          Pour ton info ces langages portés ne respectent pas de conventions dans les type, de conventions dans les appels, n'implémentent pas les generics correctement, ne peuvent utiliser les pointeurs 'celà limite tous les langages bas-niveau)... TOut ça pour dire que celà n'apporte pas beaucoup d'intérêt à l'objectif d'interopérabilité... qui est quand même le but si on écoute MDI.

          C'est faux. Va regarder le site halcyon
          J'ai regarder. J'ai pas trouvé d'exemple concret.
          Et la marmotte... si tu regardes de plus près, Java n'est même pas foutu de pouvoir implémenter les generics correctement sur sa propre VM... Nan, que ça marche sur certains morceau de code je veux bien, mais sur des scénario plus compliquer j'y crois pas... Eclipse tourne sur .NET, trouve moi une appli comme celle là en .NET qui tourne sur une machine Java et là peut être que j'y croirait... Mais franchement y'a des parties du code IL .NET qu'on peut pas transposer en Java...


          Et d'un point de vue pratique ?

          Ben d'un point de vue pratique, Sun a déjà fait valloir ses droits sur ces brevets, pas Microsoft.

          Et tu crois que cela empéchera Microsoft de les modifier selon son bon vouloir. Rien ne les oblige. Faut pas être naif :-)).
          Désolé mais Microsoft ne peut pas ne pas respecter la norme ISO sinon bonjour la réputation... De plus ce n'est pas du tout dans leur intérêt de casser la compatiblité avec l'existant...
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

            Posté par  . Évalué à 1.

            > .NET a été conçu pour le langages intégrant la notion d'objet

            Certains langages purement objets ne sont pas supporté correctement par la machine virtule de c#. Voci une petite listes des limitations :

            - C++ et Eiffel implementent l'heritage multliple. Non supporté par la CLR.
            - "Mix-ins" demandé par Python. Non supportés.
            - Généricité supportée uniquement comme en C++. Impossible encore pour Eiffel.

            Le CLR a été conçue à la base pour implémenter c#, tous les langages qui s'en approchent (comme java) seront hautement favorisés, les autres non (cf. smarteifffel, ocaml).


            > Est-ce un problème sous Linux où l'on veut plutôt
            > utiliser GTK ou Qt ?
            Ce n'est pas un pb au contraire. Mais je vois pas en quoi utiliser c# ou java change quoique ce soit dans ce cas.

            > Le plus impressionnant c'est C++, tu peux mixer du code .NET
            > et du code C++ traditionnel
            Ton exemple est mal choisi. C++ n'est pas supporté par la CLR.
            De plus dans ce cas, appeler une librairie xyz (native ou non) me parait une approche un peu plus propre que de mélanger du code dans un même source. Enfin, si tu souhaites programmer comme cela c'est ton droit.

            > Non le but c'est de laisser le langage décider.
            Moi je préfère quand c'est le développeur qui décide :-) Si je veux faire un driver linux, j'utiliserai le C (et ni c# ni java). Si c'est pour faire un programme de PAO, je préfèrerai un langage de haut niveau et je me tape complètement d'avoir des pointeurs.

            > Pour ton info ces langages portés ne respectent pas
            > de conventions dans les type
            C'est comme pour la CLR de Microsoft, implémenter un langage Python en bytecode Java en fait un citoyen de seconde classe. (Au moins Sun ne s'en vante pas).

            > Eclipse tourne sur .NET
            Eclipse tourne sous ikvm. avec Classpath (l'implémentation GNU des classes Java) et SWT et tourne également trés bien sous Java...

            > Et la marmotte... si tu regardes de plus près,
            C'est pas la peine de t'énerver...

            >Java n'est même pas foutu de pouvoir implémenter
            >les generics correctement sur sa propre VM...
            Franchement, même si c'est loin d'être parfait, je préfère nettement l'implémentation des génériques de Java que les templates de C++ (performants mais trop complexes)

            > Ben d'un point de vue pratique, Sun a déjà fait valloir
            > ses droits sur ces brevets, pas Microsoft
            Ah bon un lien svp ??

            >Désolé mais Microsoft ne peut pas ne pas respecter la norme
            > ISO sinon bonjour la réputation...
            LOL.

            > De plus ce n'est pas du tout dans leur intérêt
            > de casser la compatiblité avec l'existant...
            Très trés naif. Même avec l'existant qui tourne sous Linux ?

            .Net, c'est Microsoft, quelque soit les qualités de la plateforme, adopter .Net c'est faire le jeu de Microsoft. En tant que défenseur du libre, je ne leur ferai pas ce cadeau.
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

              Pour l'héritage multiple je suis bien d'accord. Ils ont fait ce choix parcqu'ils estiment que l'éhritage multiple pose beaucoup trop de problèmes. C'est discutable effectivement.

              Généricité supportée uniquement comme en C++
              je te conseilles la lecture de cet interview : http://www.artima.com/intv/generics.html(...)

              Mais je vois pas en quoi utiliser c# ou java change quoique ce soit dans ce cas
              Non ca change rien. Sauf que dans un cas tu proposes un API pour plusieurs langages d'un seul coup.

              Enfin, si tu souhaites programmer comme cela c'est ton droit.
              Non non rassures toi je trouve ça crade aussi, mais c'est moins brutale comme transition dans le cas de portages.

              Franchement, même si c'est loin d'être parfait, je préfère nettement l'implémentation des génériques de Java que les templates de C++
              cf le lien plus haut et tu comprendras pourquoi je suis d'accord avec toi mais que je préfères encore plus la version .NET ;)

              Ah bon un lien svp ??
              Tu te rappelles pas de l'attaque de Sun envers Microsoft qui estimait que Microsoft ruinait Sun en implémentant une JVM non compatible ? (et puis Microsoft paie des licence à Sun, donc bon...)

              Très trés naif. Même avec l'existant qui tourne sous Linux ?
              Vois pas le problème, Mono tourne sous windows donc bon...

              adopter .Net c'est faire le jeu de Microsoft
              Dans ce cas vois Mono comme quelque chose qui n'a rien à voir avec .NET et qui n'est même pas compatible, utilise que les API Gnome et tout ira comme dans le meilleur des mondes pour toi :)
              • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

                Posté par  . Évalué à 1.

                > Non ca change rien. Sauf que dans un cas tu proposes
                > un API pour plusieurs langages d'un seul coup.
                Tu propose une API pour les langages qui supportent de fonctionner dans une envirronement .NET. (c'est à dire pas C++, pas Eiffel, pas Ocaml, pas Python, etc.).

                > cf le lien plus haut et tu comprendras pourquoi je suis d'accord avec toi mais
                >que je préfères encore plus la version .NET ;)
                Et cela sort quand sous Linux ?

                > Tu te rappelles pas de l'attaque de Sun envers Microsoft qui estimait que
                >Microsoft ruinait Sun en implémentant une JVM non compatible ?
                Cela n'a strictement aucun rapport.

                >Très trés naif. Même avec l'existant qui tourne sous Linux ?
                >Vois pas le problème, Mono tourne sous windows donc bon...
                Bien moi je le vois. M$ décide d'étendre .Net, ajoute des fonctionnalité brevetées, cachées, dépendant de l'os et évidemment impossibles à implémenter rapidement dans la version Linux. Tous les développeurs vont se plaindre (à juste titre) et dire : Linux c'est de la merde, sous Win 2019, on peut faire ci et ca et patati et patata...

                Utiliser une technologie "standardisée" par M$, c'est avoir la certitude d'être et rester l'éternel numero deux (au mieux).

                > Dans ce cas vois Mono comme quelque chose qui n'a rien à voir
                > avec .NET et qui n'est même pas compatible

                Alors pourquoi parles-tu tout le temps de .Net dans tes posts. Emploie uniquement le terme Mono et cela sera bien plus claire.

                Pour moi Mono, c'est sensé être "compatible" avec .Net, c'est en tout cas l'objectif affiché (c'est indiqué à la 1ere ligne du site web!) et encore une fois je n'ai aucune envie de servir les intérets de M$.
                • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

                  (c'est à dire pas C++, pas Eiffel, pas Ocaml, pas Python, etc.).Là tu affirmes haut et fort que tous ceux qui s'amusent à porter ces langages sur .NET ne font que du mauvais boulot... C'est encore jeune tout ça, et quand tu regardes OCamil ou IronPython et ses perfs bah tu te dis que c'est déjà pas trop mal... Ensuite .NET est amené a évolué s'il manque des choses pour implémenter certains langages "vitaux". Pour C++ c'est tout de suite vue, ce n'est pas un vrai langage objet. Mais même si à terme tous les langages ne sont pas portés sur langages, parcque obn je comprend qu'il peut y a voir des choix techniques vraiment incompatible, celà reste une plateforme facilement utilisable de l'extérieur et donc une belle passerelle ou point de rendez-vous entre les libs.

                  Et cela sort quand sous Linux ?
                  tu rajoutes l'option -2 au compilo de mcs de Mono et zou t'as les generics (c'est encore en fini faut otut de même préciser)

                  Cela n'a strictement aucun rapport.
                  Ah bah si, Sun a fait valoir ses droits sur la JVM. La JVM serait un standard ECMA, Microsoft aurait pu faire ce qu'ils voulaient avec.

                  Bien moi je le vois. M$ décide d'étendre .Net[...]
                  Le but est de porter pour le moment la version 1.0 pour faciliter la migration. En 2019 la place de Linux sur le marché des OS ne sera sûrment plus la même... Reste que la base du framework sera toujours la même, ce qui ne sera pas portable, c'est ce qui sera dépendant de l'OS (naturellement). Mono aura (j'espère) ses propres qualités qui n'auront rien à envier à .NET. Et si c'est plus compatible, bah tant pis, on verra ça comme une techno concurrente de .NET qui n'a rien à voir et pi voilà.

                  Alors pourquoi parles-tu tout le temps de .Net dans tes posts
                  Parcque tou le monde parles de .NET. Mais c'est vraiq ue je devrais parler de Mono.

                  c'est sensé être "compatible" avec .Net
                  Me semble pas que ce soit le sujet du débat, là il s'agit de choisir une plateforme de développement à intégrer à Gnome pour pouvoir proposer des API utilisables par le maximum de programmeur.
                  • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

                    Posté par  . Évalué à 1.

                    > Là tu affirmes haut et fort que tous ceux qui s'amusent
                    > à porter ces langages sur .NET ne font que du mauvais boulot

                    Non. j'affirme juste qu'il y a un tas de langages qui ne pourront pas être portés efficacement dans cet environnement et qui par ricochet souffriront de la comparaison avec c# (ou même java).

                    > C++ c'est tout de suite vue, ce n'est pas un vrai langage objet
                    Et alors... c'est tout de même trés utilisé.

                    >> c'est sensé être "compatible" avec .Net
                    >Me semble pas que ce soit le sujet du débat,

                    SI SI SI , pour moi le débat se situe la justement. Bon je me répète. Je n'ai aucune envie de prendre .Net car c'est "standardisé" par M$, et l'adopter c'est faire leur jeu.
                    Je pense que la communauté du libre n'a pas à faire ce genre de cadeau à M$.

                    Reprendre le byte code Java ou C#, ce ne me pose pas vraiment de pb (encore que), reprendre .Net si.
                    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

                      Comm c'est dit plus haut, dit toi que c'est pas compatible avec .NET, que c'est juste un bonus supplémentaire, et que c'est quelque chose totalement nouveau, sous licence libre, avec des standards à l'ECMA et à l'ISO.
                    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

                      Non. j'affirme juste qu'il y a un tas de langages qui ne pourront pas être portés efficacement dans cet environnement et qui par ricochet souffriront de la comparaison avec c# (ou même java).

                      C'est sans importance. Le but des langages autres que C# sous .NET n'est pas de permettre de developper avec mais de recuperer sans trop de pbs du code existant. Personne ne va developper en Managed C++, par contre faire un wrapper avec autour d'une grosse appli C++ que tu n'as pas envie de re-ecrire en C#, oui.

                      Mais pour developper une appli neuve, tu vas evidemment prendre C# sans te poser de questions.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 1.

        > si, il y a bien une question des langages

        Oui et non. C'est pas le language qui pose le plus gros problème. Gnome est fait pour supporter tous (ou presque) les languages. Le problème est de reprendre des éléments et/ou spécification de la plateforme .NET ou java pour les mettres dans Gnome et non en surcouche de Gnome (comme c'est le cas de Gnome-java actuellement par exemple).

        Les developpeurs de la plateforme Gnome se moquent que tu utilises C# pour faire une appli du moment que le support de C# est une surcouche de Gnome. Par contre supporter la *plateforme* .NET par Gnome, ça ne peut pas se faire en faisant une surcouche. Dans ce cas, .NET doit être au "coeur" de Gnome.

        Prenons l'exemple d'XAML. Pour l'intégré dans Gnome, il faut modifier la plateforme Gnome. Que la modification soit faite en C ou en C# ou ... n'est pas le plus important. Par contre si pour avoir le support XAML pour les applis Gnome il faut utiliser des librairies/composants de .NET et/ou risquer d'être attaqué par MS pour des problèmes de brevet, là il y a de gros problèmes.

        Le problème est que la plateforme Gnome doit évoluer. Havoc souligne que cette évolution doit rester neutre par rapport aux sociétés commerciales. Si la plateforme Gnome intègre des trucs (spec, API .NET, etc... et quelque soit le language) qui l'emprisonne dans un solution MS (par exemple), alors Ibm, Sun, les contributeurs bénévoles, etc... ne voudrons plus aider Gnome même si celà peut répondre à une demande à court/moyen terme voir même favoriser la diffusion de Gnome.
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

          tu n'as pas bien compris.
          1 des objectifs de MDI c'est de pouvoir proposer un API indépendant du langage, entendre par là ne pas avoir à supporter plusieurs bindings.

          XAML c'est pour Windows à la base, je vois pas torp le rapport... Ce qui veut être repris dans XAML c'est le principe de correspondance entre les classes .NET et les balises XML... Bref, celà peut être le plus simplement du monde adapté à GTK# par exemple.

          Pour ce qui est d'utiliser les librairies .NET de Microsoft, je vois pas trop, vu que MDI s'acharne à tout réécrire... De plus le but n'est pas d'utiliser les API windows sous Nux, c'est ici juste pour la compatiblité et attirer les développeurs windozien et faciliter la transition vers Linux, sinon tu utilises des lib .NET (Mono) 100% GPL au dessus de GTK, de Mozilla, de Qt, etc... je vois vraiment pas où est le problème.
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

            Posté par  . Évalué à 2.

            > 1 des objectifs de MDI c'est de pouvoir proposer un API indépendant du langage, entendre par là ne pas avoir à supporter plusieurs bindings.

            J'ai parfaitement compris ça. C'est la même chose que .NET.

            > Pour ce qui est d'utiliser les librairies .NET de Microsoft, je vois pas trop, vu que MDI s'acharne à tout réécrire...

            Il est là le problème. MS à des brevets sur .NET (et pas sur CLI et C#).

            De l'article :
            Microsoft has set a clever trap by standardizing the core of the CLI and C# language with ECMA, while keeping proprietary the class libraries such as ASP.NET and XAML. There's the appearance of an open managed runtime, but it's an incomplete platform, and no momentum or standards body exists to drive it to completion in an open manner. Many interesting class libraries are clearly encumbered by Microsoft IP and nobody concerned about legal liability will want to ship them. The core may also be encumbered, though that remains uncertain.

            Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.

            Even if we use some unencumbered ideas or designs from the .NET world, we should never define our open source managed runtime as a .NET clone.

            If we built on the ECMA core, it would be critical to launch a large-scale effort to standardize and market a comprehensive alternative API set to replace the Microsoft-encumbered class libraries. This would be a heck of a lot of work.


            > c'est ici juste pour la compatiblité
            Si c'est compatible (je parle de .NET et non de C#) il y a problème.
            Je parlais d'"implémenter" .NET dans Gnome. Je ne parlais pas de copier les fichiers des classes .NET d'une machine Windows avec Licence MS sous Linux.
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

              D'après MDI (qui tu penses bien a du réfléchir à 2 fois), à partir du moment où ils réécrivent tout il n'y a pas de violation de brevets. La seule chose que pourra faire Microsoft c'est ce que fait SCO actuellement, c'est râler parcque ils ont pomper le code, mais ils sont pas cons pour faire ça...
              Toute la partie basse du framework, la VM sont parfaitement utlisables sous Gnome sans violer quoique ce soit. Ils implémentent juste un standard (ECMA) et écrivent des API au dessus.
              • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

                Posté par  . Évalué à 1.

                Quant aux parties ou microsoft pourait utiliser des brevets si on prends ce shema : http://primates.ximian.com/~miguel/tmp/two-stacks.png(...) c'est les parties à gauche (Non standardisés) et de toute façon si gnome utilise Mono il utiliseras la partie de droite, pas le reste
                • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

                  Posté par  . Évalué à 2.

                  Merci pour l'info. De plus on peut penser que Novell a réflechit à la question.
                  Néanmoins même si Havoc a tord (ce qu'il annonce dès le début "Hopefully it will start a discussion and become rapidly outdated"), je trouve qu'il pose le "débat" sur le futur de Gnome sur de bonnes bases (c-à-d sans oublier d'éléments importants). J'espère que quelque chose de fédérateur sortira de tout ça et que Gnome s'engagera solidement vers la bonne direction. Car actuellement c'est le flou et aucune décision n'a été prise par rapport aux nouvelles technologies type .NET, XAML, etc... qui semble gagner en popularité.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 2.

        > les spécifs de la VM .NET sont normalisée ISOtifié et tout ce que vous voulez.

        Pas .NET dans son ensemble (ASP.NET, XAML, etc...). Le C# n'est pas le problème. C'est la plateforme .NET qui pose problème.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 1.

        Imposer une machine virtuelle et un Fw, c'est bien plus que d'imposer un langage.

        De plus, l'interdiction d'utiliser les pointeurs en java, c'est justement l'intérêt du java. Comme la façon dont les exceptions sont utilisée, la façon dont le rtti fonctionne, enfin la notion d'interface et les templates compilées.

        Avoir une machine virtuelle acceptant tous les langages, c'est d'un coup, vouloir tout monopoliser et interdire toutes innovations spécifiques, liées au langage.

        Par exemple :
        Le C a des qualités, en terme de maturité de spécification, de compatibilité binaire, qui le rendent bien supérieure au C++ (sur ces 2 points). Un bon dev sait exactement ce que le compilateur fait, et ce que le compilateur est autoriser a optimiser si il utilise du C. Donc vouloir avoir 1 machine virtuel qui fait tout (du C, du java), c'est avoir une machine virtuelle qui n'est bonne dans aucun domaine.
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 10.

    Si on veut evoluer vers un nouveau langage pour le développment des applications du libres se serrait biens de réfléchir pourquoi faire cela avant de donner directement de noms: Java et .Net.

    Je suis pour que l'on arrete de coder des grosses applis en C et que l'on evolue franchement vers un autre langage de plus haut niveau.
    Les langage de plus haut niveau permettent d'acelerer l'ecriture du code, d'en faciliter la maintenance et de garantir une plus grande robustesse de l'application (Ils ont étaient inventé pour cela!), je n'ai jamais compris pourquoi encore tant de monde codaient en C!

    Ensuite quitte à changer de langage, il faudrait qu'il aporte VRAIMENT quelque chose de nouveau. Et la il va falloir choisir quel apport est le plus utile.

    Veut on un langage avec un framework déja tout fait? Un nombre de bibliothèque permettant déja de quasiment tout faire que l'on a juste à récuperer? C'est le cas de Java et .Net. L'inconvenient c'est que c'est langages (ou les principaux langages de la plateforme .Net) ne sont pas révolutionnaire et même un peu "creux". En plus pour Java, il serrait complètement nul de passer à ce langage avant que la version 1.5 (générécité at un peu d'assertion) ne sorte et quelle soit supportée par gcj.
    De plus Objective-C semble etres un choix qui rivalise trés biens avec les deux précédent.

    Veut on un langage apportant reelement quelque chose?
    OCaml est un bon choix. Il permet de garder plusieurs paradigmes pour satisfaire la communauté et est de trés haut niveau.
    Eiffel serrait un super choix si il y avait une implémentation correcte. Il apporte de rééles assertions, c'est un langage objet trés bien fait.

    A mon avis, Java et .Net ne sont certainement pas les meilleurs choix sur lesquels discuter. Il sont soutenu par de grosses boites qui font de la pub mais bon ils ne sont pas révolutionnaire et quitte à évoluer, autant franchir un grand pas.

    ps0: Quand je parle du "langage .Net", c'est par abus ... ne geulez par pour ca.

    ps1: Pour ceux qui parle de Python ou autres langage iinterprétés à typage dynamique, il faudrait arreter un peu de réver. Python est bien mais quitte à prendre un langage sans typage fort et interprété, pourquoi pas Squeak ou CLOS qui apportent vraiment quelque-chose (un niveau meta).

    ps2: Pour la personne qui, plus haut, à dis qu'un langage pouvait etres qualifié de rapide (et non pas seulement l'implémentation, il justifiait cela par les spécif de C qui disent comment empiler les args bla bla bla). Je te fait un compilo C absolument pourri si tu veut qui fera rire même un interpréteur de PHP.

    ps3: Peut on reelement faire changer la communautée de langage?
    Quand je vois le nombre d'abruti qui crache sur la programmation objet (peuh ... c'est nul un objet, en C tu fait un struct et c'est la même chose, et puis moi je prog orienté objet en C!), qui hurle si on leur demande un GC (mais de dieu! c'est pourtant simple quand tu fout ton objet sur la pile y'a pas de problème, et puis c'est marqué dans la doc qu'il faut supprimer l'objet si on est dans tel cas ...), qui adulent le C++, qui ne comprennent la portabilité qu'a coup de "#ifdef", qui cherchent encore des cycles d'horloges plutot qu'un plus petit X pour leurs algo en O(X), qui ne regardent un langage que par ca syntaxe (peuh ... y pas de "{" en Eiffel?, Javascript c'est pareil que PHP qui est pareil que le C++ (c'est objet) qui ressemble à s'y m'éprendre (d'ailleur je me fais avoir souvent) au C), enfin qui, sous-pretexte que Linux/Gtk/Gnome est écrit en C, vont me dire que c'est le meilleur langage au monde, je me demande vraiment comment changer les choses.

    Oui je provoque un peu mais je ne parle que quand je connais. En l'occurence, les langages de progs et leurs atous/faiblesses je les connais.
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      OCaml est un bon choix[...]
      Eiffel serrait un super choix si il y avait une implémentation correcte
      Vu que Eiffel et OCaml sont porté sur .NET, je comprend pas trop ta remarques :
      L'inconvenient c'est que c'est langages (ou les principaux langages de la plateforme .Net) ne sont pas révolutionnaire et même un peu "creux"[...]
      Pourquoi choisir un langage ? Laissons le choix au programmeur. .NET a été conçu dans cette perspective.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 0.

        Oulalala attention F# n'est pas, en tout cas pour l'instant, un port de OCaml pour .NET !!!! c'est juste un "rat de laboratoire" pour prouver l'interopérabilité de .NET

        Bref c'est décevant.. et d'un autre coté OCaml ça tourne aussi sous windaube sans .NET et puis l'implémentation de microsoft était plus limitée que celle de l'Inria..
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 2.

        Tu as regardé l'implémentation de Eiffel#? Ou comment trafiquer à mort pour faire de l'héritage multiple sur une plateforme concus pour l'héritage simple! Faut arreter de faire des hacks partout!
        Pour 'Ocaml#' je ne connait pas l'implémentation mais celle par défaut de Ocaml (celle de L'inria) est super performante et propose un interpréteur + une VM + un compilo natif ... je veut biens qu'ils refassent la roue sur .Net mais bon...

        Ensuite je ne crois pas (personellement) qu'une plateforme "universelle". Quand tu me dit
        >Pourquoi choisir un langage ? Laissons le choix au programmeur. .NET a été conçu dans cette perspective.
        Je veut bien mais bon. .Net doit me fournir 2 choses:
        -un compilo me permettant d'etre portable sur différentes architectures (la c'est OK mais on attend encores les différentes architectures ...)
        -Un framework utilsable entres les différents langages. C'est la reele nouvauté de .Net qui est dure à croire. Penser que l'on va facilement partager du code ecrit en Eiffel et en Ocaml c'est un peu illusoire (à mon sens). En parti car pour assurer cette interoperabilité, il faut suivre des spécifications précises (bin oui, l'interoperabilité n'est pas magique) qui je trouve, "brident" ton utilisation du langage _choisi_.
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

          les diffrérentes architectures ? bah ca tourne sur x86, sur ppc, et sur un bon nombre de petite plateforme pour pda et autres phone (cf Compact Framework .NET).
          Pour Mono, c'est x86 seulement pour le moment, avec déjà en béta SPARC et PPC.
          Pour la question des langages, celà reste la meilleur solution pour proposer des API sans avoir à binder comme un fou. De plus la VM accepte la notion de pointeurs, et donc toutes les fonctionnalités d'une architecture matérielle. Tu peux donc faire ce que tu veux... Après effectivement il faudra s'arranger pour que ton code généré soit "CLSCompliant" si tu veux qu'il soit bien intégré avec les autres langages... reste que c'est moins bidouille que CORBA, BONOBO ou les objets COM.... Tu développes ton appli comme d'hab dans ton langage, c'est juste pour les interfaces externes de tes modules (les parties publiques) que tu es obliger de respecter les conventions, pour le reste tu fais ce que tu veux...
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      J'en profite pour rajouter que l'implémentation des generics en Java est vraiment pas top, celà se rapproche des Templates plus qu'autre chose, la VM ne supporte pas les generics, et c'est le compilo qui fait que un "Replace" dans les bouts de code concernés... Bonjour les problème de Self-Reflexion pendant l'exécution... Bref, n'attend pas les generics de Java, car c'est pas des vrais generics (contrairement à ceux de C# 2.0) ;)
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      > ps3: Peut on reelement faire changer la communautée de langage? [...]

      La question mérite en effet d'être posée. J'ai parfois l'impression que la "communauté" - comme on l'appelle - n'est pas fichue de se rendre compte qu'il serait beaucoup efficace d'arrêter de coder des bennes à ordures d'applis avec pas portables avec des languages et des APIs de trop bas niveau, et porter un peu les efforts sur la production d'outils de haut niveau.

      Le problème de portabilité n'est pas seulement une question de language. C'est aussi une question d'API. Si on développe une API avec les APIs Gnome elle ne pourra pas s'intégrer correctement dans un environnement KDE et vice-versa. Idem pour toutes les applis web en techno LAMP. Utilisez des API de haut niveau qui garantissent une portabilité sur tous environnements. Programmez orienté aspect !!! Contribuez au projet JAC (http://jac.objectweb.org(...)) !
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      > Je te fait un compilo C absolument pourri si tu veut qui fera rire
      > même un interpréteur de PHP.

      OK.

      Et quand tu auras fini, tu nous fera un interpréteur PHP plus rapide que du C compilé avec un bon compilo ? ;-)
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      Je te plussoierais violement si je le pouvais encore. Pas uniquement parce que tu parle de OCaml et que je l'aime bien ce petit langage, mais tout simplement parce que tes paroles sont pleines de bon sens :)

      On en revient toujours au problème d'inertie au changement qui caractérise toute société un peu ancienne. Ben ouais, la communauté du libre commence à plus être toute jeune, même si de nouveaux éléments arrivent chaque jour : elle possède un historique TRÈS fortement marqué par C/C++, c'est dur de changer...
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

      Posté par  . Évalué à 3.

      > je n'ai jamais compris pourquoi encore tant de monde codaient en C!

      Pour des raisons de vitesse et de place mémoire. A par Eclipse il n'y a pas beaucoup de gros projet graphique en java. Et Eclipse ça te bouffe une quantité de mémoire délirante.

      J'ose à peine imaginer la mémoire nécessaire pour utilise evolution/gnome si tout est écrit en java (ou C#).

      Puis j'aime bien le Language C.

      Havoc ne dit absolument pas que Gnome (la *plateforme*) sera écrite en java/C#/(language de votre chois). Gtk# utilise Gtk+. Gtk+ n'est pas une réécriture de Gtk+ en C#.

      Il faut bien distinguer la plateforme (donc se que supporte la plateforme) et les languages utilisés pour développer la plateforme ou pour développer les applis. Tu peux déjà faire des applis en Java pour Gnome si tu veux. Car la plateforme le permet. Par contre tu ne peut pas faire de composant .NET exploitable par toutes les applis Gnome. S'il y a cette possibilité, elle ne sera pas forcément codé en C# au niveau de la plateforme.

      PS : J'en ai un marre de voir les languages de bas niveau comme le C se faire descendre uniquement car sur une brochure publicitaire le C n'est pas aussi sexy que la C#/Java/... . Le C a rendu, rend et rendra d'énorme service. Il est le language de développement le plus utilisé (et de très loin) et ce n'est pas un hazard. Merci le language C pour Linux/Apache/Gnome/PostgreSQL/etc... qui sont rapides, *FIABLE* et ne nécessite pas 1 Go de mémoire pour fonctionner.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 0.

        je n'ai jamais compris pourquoi encore tant de monde codaient en C!

        - Parce que le C est un générique (tu peux attaquer n'importe quel problème en C)
        - Le C est portable (standardisé ISO)
        - Le C est "plus que" très lié à UNIX
        - Le C a une syntaxe claire et efficace (Sinon, pourquoi Java, C#... l'ont repompé)
        - Le C permet de produire du code très propre et facilement réutilisable
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

          Posté par  . Évalué à 3.

          >- Parce que le C est un générique (tu peux attaquer n'importe quel problème en C)
          Non. Tu peut attaquer n'importe quel problème avec à peu prés tout langage. Cepandant, il y a des langages plus adapté pour cetains problèmes. Le C est pratique pour la programation systeme mais je ne suis pas sûr qu'il soit trés intelligent de l'utiliser quand on nécessite des abstaction fortes (connexion BD, distribution, interface graphique ...). L'asm est générique aussi ... dans le même sens que tu le défini.

          >- Le C est portable (standardisé ISO)
          Non. Portable ne veut pas dire #ifdef i386 #ifdef powerpc ...

          > - Le C est "plus que" très lié à UNIX
          Oui et alors? C est trés lié à la programation systeme sous UNIX. A part le fait que "tout le monde l'utilise lors moi je vais aussi l'utiliser", je pense que l'utilsation du C dans certaine application est une erreur.

          >- Le C a une syntaxe claire et efficace (Sinon, pourquoi Java, C#... l'ont repompé)
          Non. Le C, une syntaxe claire? Demande a ceux qui font les front-end des compilos. Pourquoi Java et C# l'utilse (et javascript, et PHP) ... bin justement pour des gars comme toi [la je ménerve un peu].

          >- Le C permet de produire du code très propre et facilement réutilisable
          Non. mais la j'en ai mare ...

          ... alors debrouillez vous, faites comme vous voulez, utilsez le C pour faire des grosses applis, n'esseyez pas de comprendre qu'il y a autant de décalage entre "Eclipse" et "emacs" qu'entre "emacs" et "cat" (même si cela ne justifie pas totalement ca consomation de mèmoire), de toutes facon c'est pas avec un post sur LinuxFR que je vais pouvoir faire comprendre mon point de vu ... stop.
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

          Posté par  . Évalué à 2.

          "- Le C a une syntaxe claire et efficace (Sinon, pourquoi Java, C#... l'ont repompé)"
          La syntaxe du C est tout sauf claire et efficace, mais Java et C# l'ont repompé....pour que les nombreux programmateurs déjà habitués à cette horrible syntaxe ne soient pas dépaysés.
          C'est tellemnt évident que je me demande si ta question était vraiment du premier degré ??
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

            Tout a fait. Faire un lexer pour du code C est une horreur (sans parler du C++). Je m'etais essaye a faire un refactorer mais on se casse tres vite les dents sur le parser de code. Des trucs comme:
            int *a, *b, c[5]; -> mmh, joli casse-tete pour debrouiller tout ca de facon automatique
            void *f( int a ); -> f renvoie un void * ou f est un pointeur de fonction ?

            La difficulte est presente des le debut, quand tu veux savoir de facon automatique si une ligne est une definition (int a, MyObject *a[MY_OBJECT_ARRAY_SIZE], struct a ** b;) ou une ligne d'utilisation.

            Et des que tu rajoutes les typedef, les macros et les objets, c'est une horreur sans nom.

            A cote de ca, Java ou python ont une syntaxe deterministe plus claire, qui permer d'analyser et de modifier un programme via un autre programme.
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

              Posté par  . Évalué à 1.

              > void *f( int a ); -> f renvoie un void * ou f est un pointeur de fonction ?

              C'est une déclaration de fonction qui retourne un (void *) et attend un int en paramètre.
              Le problème ici c'est qu'il n'est pas obligatoire d'utiliser extern comme pour les variable pour lever l'ambiguïté.
              Ainsi :
              int i ; <= définition
              extern int i ; <= déclaration
              void *f(int a) ; <= déclaration
              extern void *f(int a) ; <= toujours déclaration
              de plus les fontions ont un traitement particulier :
              void * (*t)(int) = f ;
              void * (*u)(int) = &f ;
              t(10) ;
              u(10) ;
              Les deux marches.
              Il n'y a pas de variables fonction mais que des pointeurs de fonction. Une définition de fonction est toujours une définition d'un pointeur de fonction (c'est bizarre). Donc il faudrait écrire *t(10). Mais ça ne marche pas car c'est considéré comme le déréférencement d'un (void *). En même temps c'est normal sinon on pourrait faire un "sizeof(f)" qui retournerait la taille de la fonction (ce qui n'a pas vraiment sens...)

              Conclusion, c'est un peu le merdier pour les fonctions... Pour le reste, c'est assez claire.
              Le C++ apporte beaucoup d'amélioration et même ou sous-ensemble C.

              > Et des que tu rajoutes les typedef, les macros et les objets, c'est une horreur sans nom.

              Le C++ permet d'éviter les typedef et les macros.

              > permer d'analyser et de modifier un programme via un autre programme.

              C'est la même horreur que les macros !
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

              Posté par  . Évalué à 2.

              Java [a] une syntaxe deterministe plus claire

              Muhahahah !

              Je n'ai pas le temps de donner des explications détaillées, mais un petit lien illustrera mon propos :
              http://java.sun.com/docs/books/jls/first_edition/html/19.doc.html(...)
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

              Posté par  . Évalué à 1.

              Perso je prog en pascal et c'est vrai que c'est vraiment désordoné le C...
              Les déclaration de variables, bah c'est dans le bloc var... les constantes bah le bloc const... les types (struct (record), object) dans la bloc type...

              Bon après pour les pointeurs je dis pas on peut très bien programmer qu'avec ça même en pascal mais ça reste dificilement lisible :D
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

              Posté par  . Évalué à 3.

              Tout a fait. Faire un lexer pour du code C est une horreur (sans parler du C++). Je m'etais essaye a faire un refactorer mais on se casse tres vite les dents sur le parser de code. Des trucs comme:

              Je ne vois pas pourquoi on parle de lexer ici. Ce qui compte, c'est que la syntaxe soit agréable pour un être humain, pas pour un programme informatique. Le front-end du compilateur est écrit une seule fois, tandis que la syntaxe du langage est subie à chaque instant par tout programmeur l'utilisant. Autant que cette syntaxe soit "humainement lisible", et tant pis si le compilo est un peu plus compliqué à écrire...
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

            Posté par  . Évalué à 2.

            La syntaxe du C est tout sauf claire et efficace,

            Si c'est pas clair, c'est que c'est mal codé....
            • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

              Posté par  . Évalué à 0.

              Bien sûr, quand tu veux tu nous fais un programme clair en Brainf?ck hein...
              Faut arrêter d'être stupide, oui on peut faire des programmes clairs en C, mais le langage ne le facilite pas.
              • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

                Posté par  . Évalué à 2.

                tu pourrais etendre ton raisonnement a n'importe quoi :
                - Oui on peut faire des mails clairs,
                - Mais aucun outils ne nous facilite la tache.

                Je trouve ça un peu pretentieux comme remarque.

                Si tu voyais ce que je peux lire comme code mal tarabiscoté, ou des mecs te tapes des methodes de 6000 lignes (150 car / ligne) pour avoir un certains comportement asymptotiques sur un pauvre detail, mais qui oblige a passer des heures sur des testes qui coute carrement plus, tu te dis qu'on en a RIEN a foutre des PARADIGMES et autres termes baveux de mauvais marketeux, pretentieux, qui touche que dalle. A part se rendre incomprehensible, couter beaucoups de tunes, ils ne font que creer des problemes.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

        La base de l'OS sera toujours codé en C, la grosse question c'est de proposer un framework complet d'API pour le maximum de langages, c'est ça le vrai problème. Et c'est pour ça que MDI s'est engagé dans Mono...
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

        Pour des raisons de vitesse et de place mémoire. A par Eclipse il n'y a pas beaucoup de gros projet graphique en java. Et Eclipse ça te bouffe une quantité de mémoire délirante.

        laurent@stan:~/tmp$ ps aux | grep galeon
        laurent 22836 0.2 5.0 63756 46068 ? S 16:23 0:23 /usr/lib/galeon-bin

        Tout ça pour lire linuxfr et écrire ce commentaire. Si c'est pas délirant ;-)
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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


        Merci le language C pour Linux/Apache/Gnome/PostgreSQL/etc... qui sont rapides, *FIABLE* et ne nécessite pas 1 Go de mémoire pour fonctionner.


        Il aurait juste falu 10 fois moins d'effort pour arriver au même niveau de qualité avec certains autres langages sur de gros projets comme ceux que tu cites.
        .
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

      Posté par  . Évalué à 2.

      [ . . . ]
      ps2: Pour la personne qui, plus haut, à dis qu'un langage pouvait etres qualifié de rapide (et non pas seulement l'implémentation, il justifiait cela par les spécif de C qui disent comment empiler les args bla bla bla). Je te fait un compilo C absolument pourri si tu veut qui fera rire même un interpréteur de PHP.
      [ . . . ]

      Avant de commenter, je vais préciser que j'adore tous les langages, mon Fw d'application préféré libre est KDE, il est très agréable de l'utiliser avec du C++.

      Et je n'ai pas de problèmes avec les langage objet. Je ne critique pas les autres langages en precisant les avantages du C.

      Maintenant, les avantages du C / F77 sont simples, t'as qu'a faire de la maintenance sur une appli que 50 millions de lignes, vielle de 10 ans en C, et le faire sur une appli en C++. Quand je fais du C, je sais non seulement ce que fais le compilateur en fonction de l'archi HW, je sais aussi ou sont instancie les symboles en mémoire, a quel moment ils le sont. Si il y a un bug, je connais exactement l'objet a modifier. Je suis pas la entrain de recompiler wattmilleobjet, et passer wattmiltestesderegression.

      La ou je bosse, ils dépensent 10 fois plus de frique a résoudre des problèmes C++ que des problèmes C.

      Les perfos du C++ sont catastrophiques, et j'ai surement fait + de maths que 90 % des mecs qui me rabaches cet histoire de comportement asymptotique d'algo, style toi. Parce que c'est trop le b-a ba comme argument.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

        Tu es sur que vous savez coder en C++ dans ta boite ? :-)

        Et tu es sur que le programme en C que tu trouves si simple a fixer est vraiment aussi complexe que les programmes en C++ ?

        Ton argument sur la simplicite du C par rapport a C++ est vide. C'est comme dire qu'une bicyclette est plus simple qu'une voiture, et que les conducteur perdent du temps a reparer des pannes qu'un cycliste n'aurait pas. C'est vrai, mais les deux ne rendent pas le meme service, si un cycliste cherche a faire la meme chose avec son velo qu'un conducteur avec sa voiture (genre aller de Paris a Nice ou depasser les 50 km/h), il va comprendre pourquoi le conducteur a choisi la voiture.

        Il semble que tu ais encore la naivete des programmeurs debutants qui n'ont pas encore vraiment ete confrontes a des problemes reels. Ou alors tu es completement coince dans tes certitudes, ce qui est plus grave.
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      Je suis globalement d'accord avec toi sur ton PS3, j'ai juste des remarques :


      Quand je vois le nombre d'abruti qui crache sur la programmation objet (peuh ... c'est nul un objet, en C tu fait un struct et c'est la même chose, et puis moi je prog orienté objet en C!),

      Ca n'empèche pas qu'on peut avoir de bons arguments, ou d'autres façons de développer très efficace.
      "Objet" est un de ces mots clés qui paralysent les facultés d'analyse de la communauté informatique depuis les années 80, il faut conserver un esprit critique là dessus aussi. Voici quelques exemples de banalités générées par un excès inverses :
      - "le switch est inutile puisque tu as l'héritage",
      - "les générique sont une forme pauvre/primitive d'héritage" (ou autre truc complètement réducteur comme ce que dis Anders Hejlsberg dans l'interview http://www.artima.com/intv/generics.html(...) citée par quelqu'un dans un autre message)
      - "la notion de classe a succédé à celle de module"
      etc.
      (si vous êtes d'accord avec une de ces affirmations, inquiétez-vous :-)


      Il y en a aussi qui hurle si on leur demande un GC (mais de dieu! c'est pourtant simple quand tu fout ton objet sur la pile y'a pas de problème, et puis c'est marqué dans la doc qu'il faut supprimer l'objet si on est dans tel cas ...)

      Il y en a aussi qui n'en ont vraiment pas besoin parce qu'ils utilisent un langage sain de ce coté là (voir mon mail plus haut).


      (peuh ... y pas de "{" en Eiffel?

      Un truc marant (enfin, j'me comprends), c'est que maintenant avoir une syntaxe à la C sert d'argument pour dire qu'un langage est lisible (j'ai vu ça dans la justification de conception du langage Samourai de Sun lab).
      En gros, "C'est lisible, car tous les programmeurs C/C++ vont s'y mettre sans problème",

      MDR.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 1.

        [. . .]
        Il y en a aussi qui hurle si on leur demande un GC (mais de dieu! c'est pourtant simple quand tu fout ton objet sur la pile y'a pas de problème, et puis c'est marqué dans la doc qu'il faut supprimer l'objet si on est dans tel cas ...)

        [. . .]

        Je voudrais juste savoir si le mec qui a ecrit cette ENORMITE, sait ce que fait un :

        struct A { inline ~A() {}; };

        en c++, quand on utilise des variable automatique (avec ou sans rtti, avec ou sans heritages, avec ou sans les exceptions, ... plus bien d'autre, on pourrait ecrire 3 bouquins de Strouducul rien que sur cette ligne de code)?

        Je ne parle meme pas de rajouter d'autres destructeurs, ou de ne pas declarer de destructeur. Il faut multiplier ce probleme en considerant tout les compilateur et toutes les plateformes.


        ET VIVE LE CPP ..................
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 2.

    Il ne faut pas se leurrer, les Frameworks Java ou .NET sont une alternative à POSIX. Si la voie de Java est prise, Gnome peut aller directement à la poubelle en tant qu'environnement graphique, ce ne sera plus qu'un ensemble d'applications en Java style "explorateur de fichier" ou "barre des tâches", comme c'était le cas à la base d'ailleurs. Il est donc plus rationnel de prendre la voie .NET mais avec un framework spécifique, un framework Gnome, libre, différent de celui de Microsoft (quitte à avoir également un framework Windows pour la compatibilité, comme le fait Mono actuellement). À mon avis, même si plein de gens aiment le critiquer, MDI a raison.
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

      Posté par  . Évalué à 1.

      Je penses que ni Java ni C#.NET ne sont des solutions à retenir.

      Pour que Gnome ne se séparre pas totalement du reste de la communauté, il faut qu'il reste proche du C pour permettre l'utilisation de bibliothèques communes écrites en C.
      Par exemple, pour les appareils photos numériques une bibliothèque écrite en C, GPhoto2, est utilisée par kde, gnome et d'autres encore.
      L'utilisation du Java risque d'inciter le développement de telles bibliothèques directement en Java et ne permettra donc pas son utilisation par d'autres projets.

      Pour le C#, malgré l'ouverture des spécifications etc., je pense qu'il ne faut pas s'aventurer de ce côté là. On ne sait pas ce que peut inventer MS pour nous attaquer.
      De plus, (je ne suis pas sûr) il me semble que Mono ne soit pas terminé et se lancer avec un langage qui n'est pas encore fonctionnel, c'est un peu risqué.

      Pour ma part la solution serait l'Objective-C avec la conservation du Foundation Framework de GNUstep et la création d'un GUI spécifique Gnome.
      Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

        Pour ma part la solution serait l'Objective-C avec la conservation du Foundation Framework de GNUstep et la création d'un GUI spécifique Gnome.


        Heu... franchement, l'intérêt serait très limité. Pourquoi créer une GUI spécifique Gnome alors que l'ApplicationKit existe ? il est laaaargement plus intéressant de continuer à bosser sur l'AppKit pour l'améliorer que d'implémenter un framework graphique inspiré de gnome, hein. L'AppKit est un foutu bon framework -- voire même, c'est ce qu'il y a de plus intéressant dans OpenStep -- FoundationKit est sympa, mais le truc qui tue, c'est l'AppKit hein.

        Il faut également que l'ObjC permet la communication inter-process, la distribution d'objets de manière quasi-transparente (plus facile que le Net-remoting de .NET).


        Il faut également noter j'imagine ? :-)
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

          Posté par  . Évalué à 1.

          C'est vrai que c'est idiot de construire un gui pour gnome dessus. Merci de me le faire remarquer...

          Dans ce cas, ils pourraient remplacer le C++ par l'ObjC simplement ? non ? c'est idiot ?
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

            Dans ce cas, ils pourraient remplacer le C++ par l'ObjC simplement ? non ? c'est idiot ?

            Non, au contraire. C++ est parfait pour certaines choses, mais à mon sens, pour programmer des GUI, ObjC est plus adapté (messages, dynamisme..). Bon après, personnellement je trouve que le framework OpenStep est justement au top pour ça, car élégant et exploitant bien ObjC. Mais bon, quitte à réinventer la roue pour un toolkit graphique, oui, ObjC me semble une meilleure idée que C++.

            Ah, quand je parlais d'améliorer l'AppKit, je voulait dire d'améliorer l'implémentation actuelle de GNUstep hein... l'AppKit en lui même (design) ne nécessite pas vraiment de bouleversement -- Apple ne l'a d'ailleurs pas vraiment touché ... juste ajouté quelques nouveaux widgets (si, ils ont ajouté NSDocument également, mais bon..).
          • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

            Posté par  . Évalué à 1.

            oui, imposer un language a des developpeur libres ne marchera jamais.
            .net n'est pas un language mais un framework, on pourra donc utiliser plusieur language différents avec.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 2.

        Evidemment qu'il y aura toujours des gens pour utiliser POSIX/Gtk/X mais il y a également des gens intéressés par la programmation à un plus haut niveau d'abstraction, pour tout un tas de raisons déjà évoquées. Ceux là se retrouvent face à plusieurs choix : {Python, Perl et Ruby}, Java ou .NET.

        Et puis le Java ou .NET c'est plus qu'un ensemble de bibliothèques, c'est une alternative au système de bibliothèques dynamique, à COM et tout ça, bref à l'architecture même du système.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

        T'as essayé Mono avant de juger de la qualité du compilateur ?
        On ne sait pas ce que peut inventer MS pour nous attaquer.
        Tu crois que s'il a voulu normaliser et ISOtifier et porter certaines appli sous nux (wmp par exemple), proposer une version FreeBSD et fait un espace de nom Windows indépendant du reste c'est pour ensuite s'amuser à tout foutre en l'air ?
        Pour ce qui est du NetRemoting, attendons Indigo qui a l'air d'être tiptop d'après MDI :)
        • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

          Posté par  . Évalué à 0.

          > [...] ISOtifier [...]

          C'est une "norme" ECMA, pas une norme ISO. Nuance de taille. Ça veut dire qu'il ont fourni une spec, un code correspondant effectivement à la spec (à un degré indeterminé, si tu me trouve un jour la procedure de vérification utilisé, je serai interressé), et un chèque à une boîte (ECMA) qui a ensuite publié la spec. Ça n'engage à rien sur l'avenir, sauf à appeler le truc .NET2 ou TrucMuche à la prochaine version, qui peut aussi bien sortir demain et complètement différente, et ça eux seuls le savent et en décident. Bref, faudrait calmer le jeu sur cette fameuse "norme", et allez voir les quelques rares autres trucs déposés à l'ECMA histoire de constater que cette boîte ne tiens pas une seconde la comparaison avec l'ISO.
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

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

      Java ça pourrait être pas mal : cela pourrait tourner aussi sous Win32, et proposerait l'alternative sur les terres ennemies. Ainsi, le choix Windows ou Linux ne se poserait plus dans le sens :
      -"si je laisse cette personne sous Linux, c'est foutu, il vaut mieux que lui mette un bon gros Windows",
      mais
      - "tu veut faire des jeux ?"
      >> Oui -> Win32
      >> Non -> un Linux suffira :-)

      Quoique les applis de P2P mériteraient d'être plus accessible sous Linux, cause c'est une des premières choses demandées actuellement, avec les jeux.
  • # Les langages et la jvm

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

    Juste pour lever une incompréhension, la jvm supporte d'autres langages que java.

    La page suivante en liste 189:
    http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...)

    Il me semble que cela devrait répondre à nombre de considérations sur la "syntaxe" à adopter...

    Personnellement ce qui me parait le plus intéressant de toute cette discussion, c'est le fait que "gcj" va peut être arriver à maturité, et faire tourner des applications comme celles de jakarta et jboss. Ensuite la plate forme java pourra enfin être intégrée à gnu/linux.

    Par contre ce qui me fait un peu peur, c'est le fait d'aider microsoft, c'est fou, .NET va être portable *grâce* aux développeurs du libre.
    • [^] # Re: Les langages et la jvm

      Posté par  . Évalué à 2.

      Faudra que tu m'expliques en quoi la portabilité de .NET est un avantage pour Microsoft. Microsoft vend un *système d'exploitation*. La portabilité l'intéresserait si c'était pour porter des applications d'un système concurent vers le sien, pas l'inverse. De toute façon, succès de Java ou pas, les gens utiliseront quand même Windows, car Windows fait tourner Java aussi bien qu'une autre plateforme.

      Par ailleurs .NET n'est pas marqué du sceau de satan. ... Ah si, j'oubliais que Bill Gates, c'est Satan.
      • [^] # Re: Les langages et la jvm

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

        mort de rire. microsoft n'est certes satan, c'est une entreprise très bonne en marketing et qui a largement fonctionné grâce à un système de croissance à outrance.

        Ajd ils doivent changer de modèle, passer à un système plus pérenne par abonnement.

        Ah, c'est aussi une entreprise terriblement agressive avec ses concurrents. Un vrai tyrannosaure dans le genre. Et c'est elle qui considère les logiciels libres comme sa menace majeure. Pour eux le logiciel libre est anti patriotique, et ptet même lié aux terroristes...

        .net est une plate forme microsoft qui a pour l'instant été plutôt mal marketée. Mais rajouter sur les listes de nos chers décideurs "portable", et bien c rendre un service à leur marketing, c faciliter l'acceptation du bidule alors qu'il n'est même pas terminé, c tout.

        C'est pas la mort hein.

        Pour ce qui est de la syntaxe, certes on peut faire fonctionner du java sur .net (et c cool), mais il me semble que certains développeurs dotgnu bossent pour faire la même chose... ;)
    • [^] # Re: Les langages et la jvm

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

      Comme je l'ai dit plus haut, un langage porté sur la JVM ne respecte aucun standard, aucune norme pour les types, les appels de fonctions, etc. Bref, tout l'intérêt de l'interopérabilité est perdu. De plus l'absence de la notion de pointeurs limite l'interopérabilité avec l'existant et la création d'API bas-niveau.
      • [^] # Re: Les langages et la jvm

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

        Entre nous, là, comme ça, pourquoi défends tu autant .net? Pourquoi autant d'énergie?

        Je suis curieux de tout et me demande vraiment.

        Personnellement, et bien je connais java depuis 1996 et j'avoue que dès le début je l'ai apprécié, par sa simplicité et son côté oo. D'un autre côté, je trouve que d'autres langages sont bien intéressants, comme python ou les langages fonctionnels (dont je ne connais que lisp).

        En ce qui concerne C#, et bien la syntaxe semble très bien, et la plate forme aussi, normal puisque cela reprend largement les concepts java (qui eux même viennent aussi d'ailleurs bien sûr). Ce qui m'embête personnellement c'est l'utilisation/possibilité des pointeurs (un truc que j'aime pas, c'est tout à fait arbitraire et personnel), et puis bien sûr le fait que ce soit microsoft qui soit derrière.

        Corrigez moi, est ce que le framework de librairies .net n'était pas à l'origine codé en java (ou pour java, je ne sais plus) et a ensuite été transformé/porté pour .net? Le contraire ne serait pas possible (porter du C# en bytecode jvm?)?
        • [^] # Re: Les langages et la jvm

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

          Pourquoi je défends .NET ? Sans doute pour les même raisons que MDI. Parcque je trouve ca techniquement impressionnant, que ca résoud pas mal de problème, que j'aime développer avec et que bah voilà quoi, ca te suffit pas ? :) Ah si, je défend .NET aussi contre tous les vilains trolls et les préjugés sur cette techno qui a eu le malheur d'avoir été conçu par "le mal".
          Euh non, les librairies .NET n'était pas codé en Java... Enfin j'ai jamais entendu ca, et je vois pas trop l'intérêt, vu que les API de bases sont pour la plupart de simple appels aux API natifs, et le reste est construit au dessus...
          Pour ce qui est de porter du C# en bytecode Java, nan c'est pas possible malgrès ce que certaines sociétés veulent faire croire, because y'a des notions du framework .NET qui ne peuvent être implémenter au dessus de Java (à moins de ne plus faire tourner les parties concernées au dessus de la JVM et à moins de supprimer les fonctionnalités de reflexivité du code au runtime).
        • [^] # Re: Les langages et la jvm

          Posté par  . Évalué à 0.

          "Corrigez moi, est ce que le framework de librairies .net n'était pas à l'origine codé en java (ou pour java, je ne sais plus) et a ensuite été transformé/porté pour .net?"

          Jamais entendu parler de ça, sources ???
          • [^] # Re: Les langages et la jvm

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

            Chose qui me paraitrait bizarre, c'est que ms redéveloppe entièrement tout alors qu'ils avaient une bonne machine virtuelle et des librairies sous la main...

            Là comme ça sans trop chercher j'ai trouvé ça ->
            Will .NET Meet JVM Half-way?
            http://developer.sys-con.com/viewitem.cfm?thread=7039(...)

            Voici un extrait et un message, mais bon, rien de bien vérifiable, c'est pour ça que je demandais qu'on me corrige...

            "The DotGNU Portable.NET guys have now taken the relatively obvious step of compiling C# to Java."

            ---
            Strange. The core class library of .NET was originally written in Java (with a modified code-generation back-end). I still have Microsoft's source code on one of my removeable harddisk cartridges, dating from fall 1999, to prove it.

            The plan was use the Java compiler and then come back later with a tool to translate Java source into C# (only then wasn't being called C# yet).

            Roger V. IES
          • [^] # Re: Les langages et la jvm

            Posté par  . Évalué à 1.

            T'en as jamais entendu parler tout simplement car c'est faux.

            Les libs .NET ne sont pas ecrites en Java.
      • [^] # Re: Les langages et la jvm

        Posté par  . Évalué à 1.

        quel est l'interet des pointeurs pour un langage de haut niveau ?

        c'est vraiment la mer a boire que de faire un binding java sur du "C" ?

        Quand je pense qu'il y en a qui hurle parceque le java utilise des types de base, MAIS QUE FONT-ILS ???
        • [^] # Re: Les langages et la jvm

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

          Ah quoi ca sert d'avoir les pointeurs dans un langage de haut niveau ? Bah à utiliser beaucoup plus facilement l'existant, notamment les libs C. Et puis comme le dit très bien le concepteur du C# :
          The irony is that although there have been all kinds of debate and writing about how C# has unsafe code and "Oh my God, it is badness," the funny thing is that unsafe code is a lot safer than any kind of code you would ever do with JNI. Because in C#, unsafe code is integrated with the language and everybody understands what's going on.

          First of all let's just immediately do away with the notion that there is a security hole with unsafe code, because unsafe code never runs in an untrusted environment, just like JNI code never runs in an untrusted environment. The right way to think about unsafe code is that it takes the capabilities of JNI and integrates them into the programming language. That makes it easier, and therefore less error prone, and therefore less unsafe, to write code for interoperating with the outside world.


          JNI : Java Native Interface

          De plus les pointeurs permettent souvent d'obtenir un gain de performances non négligeable dans certains cas (je peux te montrer des exemple où la vitessse est multipliée par 50), il faut tout de même préciser au compilateur que l'ont souhaite utiliser les pointeurs et l'expliciter dans le code, bref, ceux qui veulent peuvent les utiliser, les autres n'en auront jamais besoin. Où est le problème ?
          • [^] # Re: Les langages et la jvm

            Posté par  . Évalué à 1.

            j'ai une appli Java, ou on utilise de l'openGL. tu peux tres bien utiliser des pointeurs C en java, mais tu ne pourras pas les manipuler dans java. C'est grace a la suppresion de la manipulation des pointeurs, que les langages modernes peuvent etre sur et economique en terme de dev. Regarde ce que fait le rtti en java, et essaye d'imaginer une implementation ou tu pourrai manipuler des pointeurs ... (je vis ce cauchemar en C++ au taffe)

            T'inquietes, conscernant l'optimisation, je suis au parfum, je peux simplement te dire qu'il vaut mieux utiliser des variables locals, plutot que des ref ou des pointeurs. de plus, tu ne peux pas inliner du C dans ta machine virtuelle, donc l'argument de l'optimisation ne tiens pas debout 2 secondes.

            Meme en pyton, en perl, en ce que tu veux tu as des binding d'openGL, je ne vois vraiment pas ce qu'apporte d'avoir des pointeurs dans java, si tu peux avoir un binding correcte.
            • [^] # Re: Les langages et la jvm

              Posté par  . Évalué à 1.

              J'oublie un truc : la portabilite, t'en fais quoi si tu joues avec les pointeurs dans le cadre d'optimisations ?

              tu crois qu'un double c'est aligne pareil sur PowerG5, UltraSparc, 586, Itanium et x-86 ?? S'en parler du facteur "options de compilation" ...

              tu croies que "void f (float f[2])" et "void f (float *f)" c'est pareil sur tous les compilateurs, sur toutes les plateformes ???

              Pour cela, il y a le C, pas le java.
            • [^] # Re: Les langages et la jvm

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

              tu peux tres bien utiliser des pointeurs C en java, mais tu ne pourras pas les manipuler dans java
              C'est une belle contradiction mais je vois ce que tu veux dire ;)

              essaye d'imaginer une implementation ou tu pourrai manipuler des pointeurs ...
              Bah j'imagine très bien puisque c'est le cas en C# :) Et justement j'essai de te montrer que de toute façon tu peux faire autant de conneries avec rtti qu'avec les pointeurs, c'est pourquoi le concepteur du C# a choisi de ne pas "se voiler la face" et d'appeler un pointeur un pointeur lorsqu'il est manipulé : non seulement le programmeur est conscient de leur utilisation puisqu'il doit l'expliciter (grâce au mot clé qui fait peur "unsafe") et surtout il peut les manipuler ce qui est le but to comme dans rtti. Surtout que du coup il n'est plus obligatoire d'utiliser un API qui respecte rtti, on peut utiliser directement ce qu'on veut.

              C'est je trouve un joli compromis et c'est rigolo ceux qui râle c'est uniquement les développeurs Java qui n'ont pas essayé C#, pour la simple et bonne raison que par défaut on ne peut utiliser les pointeurs et qu'il faut le vouloir et donc avoir un minimum de connaissances.

              Pour ce qui est des optimisations je grise une image 50 fois plus vite en choppant un pointeur sur les données en manipulant directement les bits qu'en m'amusant à faire des getPixel suivit de setPixel...
              • [^] # Re: Les langages et la jvm

                Posté par  . Évalué à 1.

                une machine virtuelle sûr, qui optimise, dont le bytecode est PORTABLE, pourrat difficilement manipuler des pointeurs.

                Tu peux utiliser le symbole "glvertex3d" simplement depuis java car tu as les meme types de base qu'en c/c++, et que tu passes une reference. C'est tout.

                Tu ne peux pas faire :
                double f(char * buff) { double *d = (double *)buff; return *d;}
                J'espere que tu comprends le probleme.

                Le besoin d'utiliser des pointeurs est TRES limite. De tout facon, que ce soit la VM de pointpasNet ou de java, les perfos sont mauvaises, donc autant que ce soit safe et simple.

                Bon, faire un fromage pour parler de la manipulation des pointeurs (que j'aime bien) dans pointNet n'a aucun interet. Cependant, ne commence pas a dire que ça empeche les autres langages de binder du C. Et ne me parle pas d'optimisation CPU en parlant de manipulation de pointeur via l'utilisation d'une VM.
                • [^] # Re: Les langages et la jvm

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

                  une machine virtuelle sûr, qui optimise, dont le bytecode est PORTABLE, pourrat difficilement manipuler des pointeurs.
                  le pointeur est une notion présente sur toutes les architectures matérielles, je ne vois pas en quoi ce n'est pas portable...

                  Le besoin d'utiliser des pointeurs est TRES limite
                  J'ai jamais dit le contraire, c'est pourquoi il est important d'avoir un langage qui ne les propose pas par défaut. Mais très limité ne signifie pas "inutile", c'est donc un "+" supplémentaire qui fait parfois la différence.

                  Cependant, ne commence pas a dire que ça empeche les autres langages de binder du C
                  Je ne dit pas que celà empêche les autres langages de binder, je dis que celà facilite drôlement le binding et qu'il faut mieux appeler un chat un chat : c'est un confort d'utilisation.

                  Et ne me parle pas d'optimisation CPU en parlant de manipulation de pointeur via l'utilisation d'une VM
                  e tout facon, que ce soit la VM de pointpasNet ou de java, les perfos sont mauvaises
                  Alors ça c'est de l'argument pertinent qui déchire tout. On sent que tu as du essayé .NET et les pointeurs dessus...
                  En tout cas celà doit tellement être nul question perf que Microsoft a choisi de développer la plupart de ses nouveaux API pour longhorn avec .NET... Encore une fois on sent bien que tu as essayé toi...

                  Mais reste que si les pointeurs te font vraiment peur et que tu n'es pas un développeur système, et que ça te fait peur de pouvoir éventuellement optimiser ton code, tu peux toujours programmer en Java sur .NET et rassure toi ils ont pas rajouter le support des pointeurs au langage Java, ils l'ont laissé à C# et C++...
                  Je finirais par rajouter que les pointeurs sur .NET ne font pas parti des CLS (Common Langage Specification), cad qu'un langage qui cible .NET ne se sentira pas frustré s'il n'utilise pas les pointeurs, et un API qui expose une interface avec par exemple des pointeurs en paramètre de fonction publique verra le compilateur râler proprement.
            • [^] # Re: Les langages et la jvm

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


              C'est grace a la suppresion de la manipulation des pointeurs, que les langages modernes peuvent etre sur et economique en terme de dev.

              Faut nuancer, la suppression n'est pas la seule solution.
              Un langage peut aussi rendre les pointeurs plus sur, en les typant, en adoptant des règles qui empèchent la plus grande partie des "dangling references", en rendant les objets non pointable sauf déclaration explicite dans le code, en définissant des pointeurs "read-only", etc.
  • # Re: Havoc Pennington se pose des questions sur les langages du libre

    Posté par  . Évalué à 1.

    Je veux pas troller mais un truc qui me fait toujours rire, c'est le nombre de langage libre ou proche de l'esprit du libre qui sont proposés chaque fois qu'on parle de programmation ici.

    J'ai une question : si tous ces langages sont si géniaux, pkoi ne sont-ils pas plus répandus ?

    Je mettrais de coté le Perl et autre langages du même style qui servent autant d'outils d'admin que de langages à proprement parler...

    mais objectivement consultez des petites annonces, et vous verrez principalement C/C++, Java, .NET (VB ou C#)...

    Le java n'est surement pas le langage idéal...mais il répond à un certain nombre de besoins, et s'avère de ce fait très utilisé...
    Ex : sortez moi un langage ayant une VM dédiées aux appareils mobiles et qui soit aussi développée que celle de Java ? Le MIDP c un standard...
    Le Java est aussi un langage intéressant pour les applis utilisant un réseau (donc aussi le web), grace à sa sécurité (sandboxing, etc...)

    Maintenant c pas le plus libre, c pas le plus rapide, c peut etre pas le plus sécurisé, c'est pas celui qui a la syntaxe la plus jolie, c'est pas le plus objet...mais c un excellent compromis pour plusieurs usages...

    donc la question d'imposer un langage est idiote à mon avis...à chaque besoin son langage...y serait ridicule de faire une appli qui doit traiter des milliards d'infos dans un temps très court en java, y serait bete de faire une GUI complexe orientée web en ASM/C...

    A lire vos commentaires, on dirait des marchands de tapis, chacun essaye de "fourguer" son langage préféré...etre informaticien veut pas dire etre binaire : y'a pas qu'un choix possible...
    • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

      Posté par  . Évalué à 1.

      Si de bons langages ne sont pas repandu je suppose que c'est parce que les decideurs n'en ont pas encore entendu parler, qu'ils ne sont pas assez tester et cie... La plupart des langages dont on parle ici sont tout de même encore assez récent, et rarement poussé en avant comme sun peut pousser java ou MS pousser C# et .net.
      Les boites ont tendance a se copier entre elles, et si personne n'utilise tel super langage, elles ne le feront pas non plus.
      Et finalement, en tant que dev on ne m'a que rarement laisser le choix du langage à utiliser quand je devais developper, même si parfois le lanage imposé n'était pas le plus adapté.
      Ensuite je vois également l'effet de masse : si VisualC++ se nommait VisualOCAML, je suis sur que ocaml serait plus recherché ;)

      Bref ça cest se que je pense, mais je suis peut etre loin de la réalité.
      • [^] # Re: Havoc Pennington se pose des questions sur les langages du libre

        Posté par  . Évalué à 1.

        Ce que tu dis est très vrai...

        Le fait est que j'y suis très sensibilisé à l'approche des décideurs vu que je suis dans une fac de gestion, et que je fais une spé informatique...donc le design d'infrastructures SI, le choix de technologies, la conduite de projet SI c mon coeur de cible.

        Et justement, on voit clairement que les décideurs, ils veulent du standard qui marche :
        - je suis personnellement très intéressé par la mise en forme à base de div+CSS2 (soit du vrai beau XHTML)...le fait est que le support d'IE étant assez mauvais, et IE étant majoritaire, on peut pas encore recommander à une entreprise de faire ses portals avec ce type d'approche...donc tu te rabattras sur les tables, qui même si elles sont moins dans la philo d'accessibilité du XHTML, sont toutefois 100% compatibles avec tt les navigos.

        En prog c pareil : en C++ ou en Java, t'a des communautés de developpeurs qui se chiffrent en millions chacune, tt les SSII offrent un support de ces technologies...elles sont fiables, suivies, monitorées...tu trouves facilement des gens maitrisant ces technologies, à différents échelon (même ceux qui font pas ma spé font un peu de java pour voir la tete que ca a...

        D'un autre coté les langages que vous citez sont très confidentiels...la communauté est réduite, y doit surement y avoir qu'une poignée de SSII qui ont des gars en assurant le support, et de ce fait ca doit couter bcp plus cher...

        voilà aussi pkoi ce n'est pas utilisé...

Suivre le flux des commentaires

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