• # Erlang

    Posté par (page perso) . Évalué à 2.

    Ne connaissant pas vraiment erlang, un petit tours sur wikipedia m'a fait découvrir que:
    - Yaws (un serveur http: yaws.hyber.org) a été fait en Erlang
    - Wings 3D égallement (www.wings3d.com)
    En plus évidemment de la liste trouvée sur http://www.erlang-projects.org/Public/projects

    Cela peut peut-être t'aider.
    Bonne continuation dans ton projet!
  • # Pourquoi ce langage?

    Posté par . Évalué à 1.

    Question bête mais j'aurais voulu savoir pourquoi tu avais choisi ce langage et pour en faire quoi?

    De ce que j'ai pu lire sur wikipedia, Erlang m'a l'air très orienté Telecom. C'est ce que tu fais?

    Je me rappelle d'avoir vu quelque part un article où il vantait les mérites de ce langage parce que wow c trop bien c concurrent friendly.

    Mais au delà de ça, tu pourrais nous en dire plus?

    P.S Mon but étant de comprendre les avantages de ce langage dont je ne connais quasiment rien (à part ce que j'ai pu voir sur wikipedia)
    • [^] # Re: Pourquoi ce langage?

      Posté par (page perso) . Évalué à 6.

      Effectivement, Erlang est né du secteur des Telecom (chez Ericsson). Ce qui fait que les choix sur la conception du langage ont été issues des préoccupation de ce domaine : performance, monté en charges, rechargement à chaud, etc. L'usage de ce langage, comme tout langage fonctionnel, est resté marginal ou niché dans certaines activités (autre que les télécoms) parce que la lingua-franca auprès de la masse des développeurs et des entreprises reste le C-like (au sens syntaxique et impérative).

      Or, les architectures de nos PC ont basculé il y a 1 à 2 ans vers les multi-coeurs et cette tendance va en s'accélérant. Le problème est alors posé aux langages de programmation actuels : on passe d'une approche séquentielle vers une approche parallèle. Et voilà où actuellement le bas blesse : les langages impératives actuels ne sont pas adaptés à cette approche. Il en résulte alors deux tendances :

      - récupérer des techniques et des concepts issues des langages fonctionnelles pour les introduire dans les langages impératives existants,
      - sortir de nouvelles API sur les aspects du parallélisme

      C'est ce que l'on observe avec C# (premier point) et Java (second point) par exemple.

      En attendant, des langages comme Erlang répondent déjà à ce genre de problématique et ont fait leur preuve. C'est pourquoi celui-ci reprend du poil de la bête.
      Par exemple, sur la plate-forme Java est apparue le langage fonctionnel scala qui prend lui aussi de l'ampleur.

      Alors, que sera le 21e siècle : encore impérative avec tout un tas de hacks pour faciliter tant bien que mal la programmation parallèle ou finalement fonctionnelle dont l'approche permet de répondre élégamment à ce type de programmation ?
      • [^] # Re: Pourquoi ce langage?

        Posté par (page perso) . Évalué à 2.

        tu voulais sans doute dire http://fr.wiktionary.org/wiki/l%C3%A0_o%C3%B9_le_b%C3%A2t_bl(...) (bât)

        et sinon d'autres liens pouvant être utiles
        Programmation_fonctionnelle
        Programmation_imp%C3%A9rative
        éventuellement Calcul_parall%C3%A8le
      • [^] # Re: Pourquoi ce langage?

        Posté par . Évalué à 2.

        "performance"

        J'ai du mal lire. Erlang est très lent. Il est passe a la gestion multiprocesseurs il y a peu de temps.

        "La première sécurité est la liberté"

        • [^] # Re: Pourquoi ce langage?

          Posté par (page perso) . Évalué à 1.

          Performant ne signifie pas uniquement 'rapidité d'exécution atomique de code'.
          La performance signifie aussi 'temps d'exécution /globale/ du code' dans une appli et le débit de traitement des requêtes (et le design joue bcp ici). Et à ce niveau, Erlang n'a pas à rougir. (Bien sûr, il existe des plate-formes plus performantes qu'Erlang.)

          Quand à la gestion multiprocesseur, elle existe au plus depuis OTP, donc depuis 1996. Il est probable qu'elle existait déjà dans le langage avant, mais je n'ai pas d'info là dessus.

          Il y a un peu d'info ici : http://www.ericsson.com/technology/opensource/erlang/
          • [^] # Re: Pourquoi ce langage?

            Posté par . Évalué à 2.

            "Quand à la gestion multiprocesseur, elle existe au plus depuis OTP, donc depuis 1996."

            J'ai découvert Erlang il y a peu de temps, et les personnes s'occupant de l'association disait que la VM multi-cpu allait sortir bientôt (c'était il y a 2 ou 3 ans maximum). La VM Erlang savait gérer plein de threads mais sur un seul processus physique.

            Ici on a une idée des perfs :
            http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)

            C'est souvent 3 ou 4 fois plus lent que Java.

            "La première sécurité est la liberté"

            • [^] # Re: Pourquoi ce langage?

              Posté par (page perso) . Évalué à 1.


              J'ai découvert Erlang il y a peu de temps, et les personnes s'occupant de l'association disait que la VM multi-cpu allait sortir bientôt (c'était il y a 2 ou 3 ans maximum). La VM Erlang savait gérer plein de threads mais sur un seul processus physique.

              Ok, la VM multi-proc d'Erlang (donc non OTP) existe apparemment depuis 2 à 3 ans. Néanmoins, OTP existe lui depuis 1996 et j'ai toujours entendu qu'OTP gérait les archi multi-procs ; mais peut-être que c'était de l'intox (je n'ai pas vérifié de moi même ceci).


              Ici on a une idée des perfs :
              http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)

              C'est souvent 3 ou 4 fois plus lent que Java.

              Quant aux perfs, ce qui est testé sont relatifs à des algo, c'est ce que j'appelle des perfs locales. Or, ce qui est intéressant dans une appli sont les perfs globales. Ainsi, on a souvent des surprises d'appli, pourtant écrites en C, qui se révèlent plus lourdes /à l'usage/ que les même mais écrites dans des langages de plus haut niveau (le design influe, mais pas seulement, sur les perfs globales).
              • [^] # Re: Pourquoi ce langage?

                Posté par . Évalué à 2.

                C'est vrai sur des applications avec des IO et que l'on y fait pas attention. Les accès disques et réseaux deviennent prépondérant. Mais c'est du même niveau que de choisir un mauvais algorithme.

                "La première sécurité est la liberté"

            • [^] # Re: Pourquoi ce langage?

              Posté par (page perso) . Évalué à 1.

              Pour donner de l'eau à ton moulin, j'ai trouvé ceci qui confirme tes dires. Apparemment, même OTP ne gérait pas les archi multi-processeurs en 2005.

              http://www.erlang.se/euc/05/1710OTPupdate.ppt

              Comme quoi, faut toujours faire attention à ce que l'on nous dit ou aux interprétations que l'on pourrait avoir aux propos d'autrui.
              • [^] # Re: Pourquoi ce langage?

                Posté par . Évalué à 2.

                Erlang disait pouvoir gérer des milliers de threads très facilement, j'avais été très intéressé. Puis j'ai vu que la VM entrelaçait chaque instruction de chaque threads (donc chaque threads avance quasiement en même temps), cela explique la perf de fou du test thread-ring sur le shootout. Le problème est que cela tue les perfs à cause de la gestion calamiteuse des caches que cela impose.

                Donc, j'ai un peu laissé tombé :)

                "La première sécurité est la liberté"

                • [^] # Re: Pourquoi ce langage?

                  Posté par . Évalué à 2.

                  Le problème est que cela tue les perfs à cause de la gestion calamiteuse des caches que cela impose.
                  Tu aurais plus de détails sur cette phrase jetée à même le sol ?

                  Sinon, il n'y a pas de threads en Erlang, uniquement des processus qui s'échangent des messages. (thead -> mémoire partagée)
                  • [^] # Re: Pourquoi ce langage?

                    Posté par . Évalué à 2.

                    Le problème est que cela tue les perfs à cause de la gestion calamiteuse des caches que cela impose.
                    Tu aurais plus de détails sur cette phrase jetée à même le sol ?


                    Le cache repose sur une certaine localité d'accès. En gros, tu va réutiliser bientôt ce que tu est en train d'utiliser. Mais avec plein de threads en même temps, tu diminues les chances d'avoir tes données en cache. C'est le même problème que pour les machines utilisant l'hyperthreading (SMT) : tu pollues beaucoup plus le cache.

                    "La première sécurité est la liberté"

    • [^] # Re: Pourquoi ce langage?

      Posté par (page perso) . Évalué à 2.

      J'avais un intéret professionnel pour étudier la vm et maintenant je m'intéresse à titre perso au langage et à ce que l'on peut faire avec...
    • [^] # Re: Pourquoi ce langage?

      Posté par (page perso) . Évalué à 3.

      La question ne m'est pas posée, mais je peux y répondre quand même car elle me concerne aussi.

      1: J'ai choisi Erlang (ou Scheme ou Haskell ou Caml, selon le projet) car c'est le bien (tm) et pour programmer proprement et efficacement.

      2: Il parait que C, C++ sont très orientés bogues. C'est ce que tu fais ?

      3: C'est trop bien parcque wow c'est trop bien ; c'est intelligent-people friendly (et les algos de qualité sont fournis avec le cerveau du codeur)

      4: je pourrais, oui. Mais je vais arrêter mon discours élitiste pro-fonctionnel ici.

      (mon but étant de faire comprendre que si c'était de la merde, ça serait PHP^W utilisé par des collégiens pour faire leur page web, ou alors tout le temps en exemple sur le site thedailywtf)
      • [^] # Re: Pourquoi ce langage?

        Posté par . Évalué à 2.

        C'est pas bien de critiquer le PHP !
        Regarde, quelle puissance ! :

        <?php
        if (FALSE == "0")
        {
        $a = "b";
        if (0 == "abc")
        $bb = 42;
        function b() { return "b"; }
        }
        echo ${str_repeat($a(), 2)};
        ?>


        Affiche bien sur "42" ;)

        (Je ne sais pas pourquoi la balise code ne préserve pas les espaces d'indentation)
  • # Agrégateur Erlang

    Posté par . Évalué à 1.

    Je connais celui ci : http://planet.trapexit.org/

    Personnellement j'aime bien l'Erlang et son approche orienté agent -> http://en.wikipedia.org/wiki/Software_agent (ça change de l'OO).
    Je me suis amusé comme loisir à réaliser un petit web-chat[1] qui tourne justement sur Yaws, mentionné dans un commentaire précédent.

    [1] : http://www.euphorik.ch:8090/ (serveur de pré-production, vous pouvez écrire n'importe quoi).
    • [^] # Pour réponde à la question

      Posté par . Évalué à 1.

      Voila les blogs que je connais :
      * http://yarivsblog.com/
      * http://steve.vinoski.net/blog/
      * http://armstrongonsoftware.blogspot.com/ (moyennement actif)
    • [^] # Re: Agrégateur Erlang

      Posté par (page perso) . Évalué à 1.

      En fait, l'approche orienté agent est issue de celle OO. Elles ne s'excluent pas, au contraire, puisqu'en OO un agent peut-être tout simplement un objet ! En fait, c'est l'implémentation actuelle de la POO dans langages qui est relativement limitée et qui pose problème.

      Il faut voir à ce sujet SCOOP (Simple Concurrent Object-Oriented Programming). Dans cette approche, à chaque objet est associé un thread dans lequel est exécuté chaque appel de méthodes. Si la méthode est de type requête (retour de valeur) alors la méthode est synchrone, sinon elle est asynchrone. De plus, comme dans Ada, des conditions d'entrée peuvent être définies au niveau des méthodes ; si la condition n'est pas respectée, l'appel de la méthode est mise en attente jusqu'à ce qu'elle soit remplie. Ainsi, comme les changements d'états sont en rétention dans l'objet, il n'y a pas d'effet de bord ou de changement d'état entre threads !
      • [^] # Re: Agrégateur Erlang

        Posté par . Évalué à 1.

        Ce que tu décris comme étant 'SCOOP' (apparemment, d'après Wikipedia lié à Eiffel) est exactement le fonctionnement d'Erlang.

        Mais c'est vrai qu'il existe plusieurs monde de l'OO, en Smalltalk on parle de passages de messages alors qu'un C++ on parlera d'appels, le fonctionnement étant assez différent.

        Dans ma réponse je pensais évidemment à l'OO "classic" (et simpliste?) à la C++/Java/C# et cie..
        • [^] # Re: Agrégateur Erlang

          Posté par (page perso) . Évalué à 2.

          Si on veut jouer les troubles fêtes, en ne s'appuyant que sur la définition de la POO telle qu'énoncé par son concepteur, Alan Kay, et dans laquelle l'envoi de messages entre objets est un concept clé de la POO, alors on peut dire que les langages actuels tel que C++, Java, C#, etc. ne sont pas des langages orientés-objet. (On pourrait plus les qualifier de langages orientés composants, une mixture de modulaire et d'objet.)

          Voir à ce sujet l'échange de mails avec Alan Kay au sujet de la POO :
          http://discuss.joelonsoftware.com/default.asp?design.4.48554(...)
          ou
          http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
          (je ne comprend pas, l'accès direct à cet URL me donne une erreur 403 alors qu'en passant par Google, je n'ai pas de problème : http://www.google.fr/search?hl=fr&client=firefox-a&r(...)

          et sa phrase :
          "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them"
          • [^] # Re: Agrégateur Erlang

            Posté par (page perso) . Évalué à 2.

            Il faut savoir que SmallTalk n'est pas le premier langage objet... C'est Simula ( http://fr.wikipedia.org/wiki/Simula ) qui a lancé la danse en 1964, en proposant la notion de coroutine en plus.
            Alan Key a joué un peu avec vers 69-71 et fut convaincu de l'intérêt de l'approche en lisant la thèse d'Ivan Sutherland sur sketchpad qui avait codé son logiciel de CAO (en 62) en assembleur mais en était arrivé à la conclusion qu'il devait avoir une approche OO pour pouvoir s'en sortir.

            C++, de l'aveu de Bjarne Stroustrup, a été conçu à partir de Simula... ( http://en.wikipedia.org/wiki/C%2B%2B#History )
            On connait la suite...

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

            • [^] # Re: Agrégateur Erlang

              Posté par . Évalué à 2.

              D'ailleurs, c'est marrant de voir que le créateur de la POO, appuie beaucoup sur l'échange de message et le typage dynamique (type MATCH...) que sur l'héritage.

              "La première sécurité est la liberté"

Suivre le flux des commentaires

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