La programmation clusterisée à la portée de tous ? Un livre sur Erlang

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
7
juin
2003
Livre
Je viens de terminer un livre consacré à Erlang (publié chez Eyrolles) pour expliquer les bases du langage. Le livre va très vite sur des sujets pratiques: Réalisation de serveur TCP/IP, Proxy LDAP, etc.

Parmi les exemples, on apprend à réaliser un serveur de jeu vidéo multijoueurs (le développement de ce serveur continue d'ailleurs dans le cadre du projet REI: Rei.vawis.net).

Pour ceux qui ne connaissent pas ce langage, Erlang est un langage et un environnement de développement distribué sous forme de logiciel libre. C'est un langage orienté concurrence, pour réaliser avant tout des applications tolérantes aux pannes, des applications distribuées, des agents logiciels mobiles, etc. Il est utilisé surtout pour faire des applications serveurs robustes (slogan d'Erlang : "What's soft and never breaks ?": Qu'est-ce qui est à base de logiciel et qui ne casse jamais ?).

Vous pouvez trouver des extraits sur les liens fournis.

Amusez-vous bien !

Aller plus loin

  • # A propos du slogan

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

    Il y a aussi un jeu de mots sur le slogan en anglais ;)

    Soft, en plus d'être l'abréviation de Software, signifie avant tout *mou*. Donc la phrase se traduit littéralement par :

    Qu'est-ce qui est mou et ne casse jamais ?

    • [^] # Re: A propos du slogan

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

      Ça veut aussi délicat, à mon avis c'est plus proche du sens du jeu de mot...

      Qu'est-ce qui est délicat et ne casse jamais ?

      • [^] # Re: A propos du slogan

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

        c plus l'oposition mou != dur pour le jeu de mots
        mou et qui ne casse pas
        ça a lair bien

        • [^] # Re: A propos du slogan

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

          Hum, mais ce qui est mou, ça ne casse pas, puisque c'est mou...

          Par contre ce qui est délicat, ça casse facilement. Donc qu'est ce qui est délicat et qui ne casse pas ?

          (Qu'est-ce qui est hors sujet et qui va se prendre un moins 12 ?)

          • [^] # Re: A propos du slogan

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

            ouai en fait ça se tient aussi
            surtout ce que tu as mis entre parentheses

          • [^] # Re: A propos du slogan

            Posté par  . Évalué à 3.

            Y'a pire en hors sujet... et puis pour une fois qu'un message n'a pas de fautes d'orthographe, ça mérite de rester visible...

            Par contre je n'ai toujours pas compris le titre : La programmation clusterisée à la porte de tous ? Un livre sur Erlang

            À la portée, je vois, mais à la porte... y'a un jeu de mot ?

            • [^] # Re: A propos du slogan

              Posté par  . Évalué à 3.

              pour une fois qu'un message n'a pas de fautes d'orthographe

              A ce sujet...

              Vous pouvez trouver des extraits sur les liens fournis.

              Par ailleurs, l'à propos des termes utilisés pour ce message me laisse dubitatif quant à la lecture dudit bouquin.

              Hop, moinssez-moi tout ça.

    • [^] # Re: A propos du slogan

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

      Une petite précision sur le slogan:

      Erlang fonctionne sur une machine virtuelle offrant des caractéristiques de temps réel "mou" (soft). Cela permet également d'expliquer un autre aspect du slogan.

      Des heures d'amusement, je vous dis ;-)

      --
      Mickaël Rémond

      Mickaël

  • # PLEAC-Erlang

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

    Si il y a des passionnés d'Erlang je rappelle que PLEAC-Erlang[1] aurait bien besoin d'aide, pour augmenter son 1.86% actuel de complétude :).

    PS : la news ne dit pas que Erlang est un langage de style fonctionnel, et qu'il est souvent associé à un grand nom de l'industrie, à savoir Ericsson

    1: http://pleac.sourceforge.net/pleac_erlang/t1.html(...)

    • [^] # Re: PLEAC-Erlang

      Posté par  . Évalué à 1.

      euh ... PLEAC c'esy quoi exactement ? je suis allé sur le site et j'ai un peu du mal à saisir le concept !

      Il est écrit que c'est pour traduire le "Perl Cookbook" en Erlang ! Ça veut dire quoi ?

      • [^] # Re: PLEAC-Erlang

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

        le perl cookbook est une reference en terme de livre de reference justement

        ya plusieurs projets pour reprendre le model de ce livre, tres apprecié donc, dans d'autre language & domaine....

      • [^] # Re: PLEAC-Erlang

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

        En gros, si j'ai bien compris le principe, on propose un certain nombre de tâches que l'on fait très couramment (ex: extraire une substring) et on demande de les réaliser dans tous les langages du site (python, ruby, erlang, assembleur, etc...).

        C'est super cool comme idée mais apparemment, c'est peu connu des développeurs vu le faible taux de "traduction"

    • [^] # Re: PLEAC-Erlang

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

      Tiens, à propos, pourquoi y a pas Java dans les langages du PLEAC ?

  • # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

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

    Sur la page de garde du projet Rei:
    "The current work, before going to Milestone 5, is to rewritte the code in Python, and to use the NebulaDevice engine".

    Erlang est peut etre pas si bien, si ils reecrivent tout en python ?
    Ou j'ai pas compris le sens du message ?

    • [^] # Clarification sur l'architecture de Rei

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

      Je précise le sens de tout cela. Le jeu est développé avec deux éléments bien distincts: Le client et le serveur.

      Le serveur est bien développé en Erlang. A ce titre, il tire bien parti des aspects de concurrence et de distribution du langage. Je suis en train de développer la partie cluster permettant l'ajout de nouveaux noeuds de manière automatique, et c'est vraiment très simple et agréable.

      En revanche, le client est en 3D. Il doit s'appuyer sur un moteur 3D. Nous avons dans un premier temps utilisé Ogre (http://ogre.sourceforge.net/(...)), pour un premier prototype. Ce premier prototype était développé en C++ pour accéder directement à l'API de OGRE.

      Nous voulions également évaluer le moteur Nebula (http://www.nebuladevice.org/(...)), logiciel libre également, mais déjà utilisé pour des jeux commerciaux. Nebula dispose d'une API très bien foutue qui permet de développer en C++, mais également de scripter complétement le jeu, par défaut avec TCL. Nous développons donc ce second prototype directement en langage de haut niveau et avons préféré Python parmi les bindings déjà proposés.

      Cela n'exclut pas de réaliser un binding Erlang dans un second temps, non pas pour le client, mais pour permettre l'accès direct sur le serveur au moteur de physique de Nebula, afin de valider les comportements sur le client (et notamment essayer de détecter la triche): Le moteur et les algos utilisés sur le client et sur le serveur seront ainsi identiques.

      Voilà, voilà.

      En espérant que cela clarifie quelque peu l'architecture du projet Rei.

      --
      Mickaël Rémond

      Mickaël

    • [^] # Précisions

      Posté par  . Évalué à 2.

      Remarque très pertinente : je m'étais mal exprimé sur le site, en effet.

      Je viens de modifier la page de garde ( http://rei.vawis.net(...) ) pour expliciter un peu les choses, comme Mickaël l'a fait dans son post.

      Merci pour la remarque, donc. :-)

      -- Thierry Mallard

  • # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

    Posté par  . Évalué à 2.

    tiré de Erlang-fr :
    Les variables ne peuvent être affectées qu'une seule fois. On ne peut jamais modifier le contenu d'une variable.
    Le nom français de ce type de donnée serait-il mal choisi ?
    Par définition il me semble qu'une variable ca doit varier
    Ou alors je n'ai rien compris
    Just my 2¢

    • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

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

      En XSLT, une variable n'est pas réafectable non plus. Ca semble être une caractéristique de langages fonctionnels, mais je n'en suis pas sûr.

    • [^] # Concernant les variables

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

      En anglais, les variables Erlang sont également appelées variables. La caractéristique à laquelle tu fais référence ici s'appelle l'assignement unique des variables. C'est une caractéristique courante des langages fonctionnels (comme XSLT). Elle fonctionne main dans la main avec le mécanisme de correspondance de motifs (pattern matching).

      Tu dois maintenant te poser une foule de questions sur comment programmer dans ces conditions. Je te rassure, c'est possible et une fois que l'on a bien compris, le mécanisme semble limpide et très élégant. Tout est expliqué dans le bouquin.

      --
      Mickaël Rémond

      Mickaël

    • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

      Posté par  . Évalué à 7.

      Effectivement, ceci n'est pas une variable mais une valeur qui possède un nom (un "let binding").

      Ce concept est très courant en style fonctionnel, car il est issu des mathématiques (où il n'existe pas de variables).
      D'autre part, l'impossibilité de "réaffecter" une variable fait partie de la contrainte "pas d'effet de bord", qui garanti l'absence de surprises (donc une maîtrise totale de ce que fait le programme).
      Dans l'absolut, les langages extrémistes (haskell par ex.) ne te garantissent ni l'ordre d'exécution, ni même qu'il va t'exécuter (en fait évaluer) ce que tu écris (il le fera que s'il est obligé en réalité). Dans ce contexte, une affectation de variable qui se trimbalerait ne serait pas trop la bienvenue !

      Pour répondre au sujet de XSLT, oui, la balise porte un nom erroné, mais le concept est le bon ; le principe de ce langage est de décrire le document sortant (plus exactement la transformation), pas d'exétuter des taches (le but est de tranformer une document, pas de faire de la domotique, il y a multideskOS pour ça). Bien sur les naxor du C et autres langages impératif n'ont plus qu'à apprendre les concepts courants du secteur déclaratif.


      Je regarde un peu ce langage et je fais un post sur mon blog pour ceux que ça intéresse.

    • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

      Posté par  . Évalué à 3.

      Pareil en Prolog, auquel la syntaxe d'Erlang le fait beaucoup ressembler.

      L'idée est que la variable ne peut être affectée qu'une fois, mais cette valeur (à laquelle la variable est "bindée", c'est-à-dire attachée) n'est déterminée qu'à l'exécution et dépend de celle-ci. De plus, on parle de variables locales principalement, donc d'un passage à l'autre de la fonction concernée une variable prend plusieurs valeurs différentes ; mais ce n'est pas à proprement parler la "même" variable mais bien plusieurs instances différentes : dans un scope donné, on a accès à une valeur unique et constante de cette variable.

      Evidemment cela interdit de programmer manuellement des structures de contrôle itératives de type boucles (il y a souvent des contournements possibles type mapcar, qui est une construction du Lisp permettant de lancer une fonction sur chaque élément d'une liste successivement). Dans ce type de langages (langages fonctionnels ou déclaratifs) la récursivité est une méthode de programmation naturelle, ce qui ne rend pas forcément la sémantique d'un programme très lisible - la plupart des algorithmes n'étant pas intuitivement récursifs.

      • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

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

        > Dans ce type de langages (langages fonctionnels ou déclaratifs) la
        > récursivité est une méthode de programmation naturelle, ce qui ne rend
        > pas forcément la sémantique d'un programme très lisible - la plupart des
        > algorithmes n'étant pas intuitivement récursifs.

        Là, je ne suis pas d'accord. Cela paraît effectivement bizarre au premier abord de traiter la plupart des problèmes sous forme récursive. Seulement, lorsqu'on y a gouté et que l'on s'est imprégné du raisonnement, on finit par raisonner naturellement de cette manière. Les algorithmes sont en général plus concis.

        Un ami, qui a développé pendant un certain temps en Erlang, s'est mis à intégrer la récursivité dans son mode de raisonnement. Il a ensuite dû programmer en Python et trouvait que son programme ramait, occupaiut l'ensemble de la mémoire, etc. En fait, il avait utilisé la récursivité dans ses programmes Python, mais le langage n'est pas optimiser pour cela et on fait rapidement exploser son programme (Je ne sais pas si c'est encore le cas, mais Python ne proposait pas d'optimisation de la pile d'appel des programmes en cas d'appel de fonction récursif terminal. La récursivité terminale permet de programmer des fonctions récursives sans faire exploser la pile d'appel de fonctions).

        Tout cela pour dire que si la récursivité est peu employée, c'est surtout parce que traditionnellement, les langages ne sont pas prévus pour la supporter de manière efficace. Erlang, ou Lisp par exemple, permette d'utiliser la récursivité abondamment.

        Franchement, en essayant Erlang et en s'accrochant un peu, on a ensuite vraiment du mal à revenir à un autre langage.

        Dans les livres de programmation, on présente l'algorithme factoriel pour expliquer la récursivité et on s'en tient en général là. On a alors l'impression que la récursivité s'applique à des cas biens particuliers de traitement. En pratique, c'est un outil extrêmement puissant, qui me manque dans les autres langages.

        Dans le bouquin, j'explique que la récursivité permet notamment de faire des boucles dont le traitement peut être contrôlé bien plus finement que la simple boucle for. La récursivité est plus difficile à assimiler, mais c'est un outil extrêmement puissant, qui va au-delà du simple exemple universitaire classique.

        Mickaël

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

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

        • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

          Posté par  . Évalué à 1.

          Là, je ne suis pas d'accord. Cela paraît effectivement bizarre au premier abord de traiter la plupart des problèmes sous forme récursive. Seulement, lorsqu'on y a gouté et que l'on s'est imprégné du raisonnement, on finit par raisonner naturellement de cette manière. Les algorithmes sont en général plus concis.

          Mmmh oui, c'est vrai. Seulement tu ne me l'enlèveras pas l'idée que la récursivité n'est pas une méthode naturelle pour le cerveau humain : celui-ci en effet définit les problèmes et les solutions à l'image de son propre mode de fonctionnement, qu'il perçoit comme séquentiel.

          De plus si l'on veut que la récursivité soit aussi efficace que l'itération, alors il faut penser à faire en sorte qu'elle soit terminale. C'est, là aussi, rarement naturel dans l'énoncé du problème ; par exemple la factorielle programmée en récursivité terminale devient une fonction à deux arguments (exemple bateau ;-).

          • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

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

            Tout dépend en fait de ce que l'on appelle "approche naturelle", "méthode naturelle", etc.

            Je reste persuadé que la programmation est un outil. A ce titre, rien n'est vraiment très naturel et doit s'apprendre. Seuls quelques langages sont conçus avec pour objectif d'être suffisamment naturel pour être maîtrisable rapidement par des enfants, par exemple.

            Pour le reste, toutes les techniques de programmation sont des outils et s'apprennent. La récursivité s'apprend comme toutes les autres techniques et elle constitue un outil extrêmement puissant. Dans le bouquin je montre que c'est une structure plus puissante que la boucle car plus souple et adaptable au problème à traiter.

            Je pense cependant que je ne vais pas te convaincre aussi facilement que cela ;-) Je te propose de discuter de vive voix de cela si l'on a l'occasion de se croiser ... Peut-être à Metz ?

            En revanche, Erlang, avant d'être un langage fonctionnel, est surtout un langage concurrent. C'est la concurrence du langage qui rend la conception des applications plus simple et plus "naturelle". Erlang fonctionne à base de processus légers. Il est possible de lancer autant de processus que le design de l'application l'exige naturellement. Il suffit d'observer les activités concurrentes, simultanées dans le monde, pour être capable d'en déduire l'organisation de son application.

            L'exemple bateau est celui des ascenceurs. Pour modéliser un système d'ascenseurs, il suffit de créer un processus par ascenseur. Les usagers commandent les ascenseurs en leur envoyant des messages (passage de messages).

            Le fait qu'Erlang soit un langage orienté concurrence parait anecdotique. C'est pourtant un élément fondamental dans un langage. Prenons l'exemple de la conception d'un serveur Web. La logique veut que l'on utilise un processus par client connecté. C'est le design le plus "naturel". Chaque nouvelle connexion entraîne la création d'un nouveau processus. Dans la plupart des autres langages, ce design logique n'est cependant pas possible. Les langages traditionnels les plus concurrents supportent et sont capables de gérer en général au maximum 1000 processus (Threads). Cela signifie que le design n'est plus valable si l'on considère que le serveur peut accueillir plus de 1000 connexions simultanées. C'est embêtant comme limite, non ? Cela conduit implique de sortir du design "naturel" pour ce tourner vers des contournements. En Erlang, cette limitation n'existe pas. Le design d'une application peut être calqué sur l'analyse de la concurrence réelle des entités de l'application.

            Mickaël

          • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

            Posté par  . Évalué à 1.

            Sais-tu qu'il existe un pattern pour rendre une récursivité terminale (quand c'est possible) ?

            • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

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

              Il existe des approches pour mettre en œuvre la récursivité terminale. L'une d'elle, comme déjà évoqué, consiste évidemment à utiliser les paramétres de fonction pour accumuler les résultats dans un paramètre d'appel qui passe d'appel en appel, plutôt que d'imposer le stockage des résultats dans la pile d'appel de fonction. L'approche en Erlang est assez naturelle puisque c'est également la manière dont sont implémentés les serveurs. Un serveur n'est finalement qu'une fonction récursive qui stocke son état dans les paramètres de la fonction.

              Mickaël

            • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

              Posté par  . Évalué à 1.

              Pourquoi n'est-il pas implémenté dans le langage ?

              Pour Mickaël : Un serveur n'est finalement qu'une fonction récursive qui stocke son état dans les paramètres de la fonction.

              Oui, c'est une machine de Turing, aussi ;)

    • [^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

      Posté par  . Évalué à 3.

      Ou alors je n'ai rien compris Oui en fait c'est plutôt ça ;-) À propos de ton post, et de certains autres qui ont suivi, je rappelle quand même que les mathématiciens parlaient de "variables" pour décrire ce genre d'objet bien avant la naissance de l'informatique. Il existe 3 notions de variables: - la variable "applicative", qu'on retrouve en maths ou dans les langages fonctionnels (Caml, Erlang, Haskell, Lisp, Scheme,...) - la variable "impérative", qu'on retrouve dans les langages usuels (C, Java, Ada,...) - la variable "logique", qu'on retrouve en Prolog, et qui diffère de la variable applicative (en raison de l'unification). Pour une discussion à ce propos, on peut se reporter à "Logique, Réduction, Résolution" de R. Lalement chez Masson.

  • # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang

    Posté par  . Évalué à 5.

    Erlang est à la base du système téléphonique le plus stable jamais créer: 99,99999% de disponibilité, le downtime réel calculé sur la base installée est inférieur à 2mn par an et par MGW (AXD 301).
    Auparavant, le produit le plus stable jamais créer par Ericsson était l'AXE10 (le swicth GSM) entre 5 9 et 6 9 de disponibilité.
    Les performances de ces deux produits sont exeptionnels et loin d'être representatifs de ce qui est disponible sur le marché chez d'autres constructeurs et dans d'autres domaines chez Ericsson.

    (Engine Integral d'Ericsson).
    http://www.ericsson.com/multiservicenetworks/ShowImage.asp?ImageId=(...)

    • [^] # Les produits développés En Erlang

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

      Les deux produits d'Ericsson, développés en Erlang, que tu cites, sont réellement impressionnants. Ils atteignent une disponibilité record. Et lorsque l'on connait la complexité d'un routeur ATM, leur travail est d'autant plus impressionnant (La complexité, en terme de sous-systèmes à intégrer, est décrite comme au même niveau qu'une navette spatiale).

      Ericsson n'est plus la seule société désormais à utiliser Erlang. Les produits de Nortel (Nortel sur Erlang-Projects) sont également extrêmement robustes et s'appuient sur Erlang.

      Le besoin de haute-disponibilité, de tolérance aux pannes, et montée en charge, ne s'appliquent pas qu'au domaine des télécoms/réseaux. Erlang commence a être utilisé dans la banque pour assurer la robustesse des systèmes de transactions bancaires et d'autres domaines, comme la signalisation ferroviaire, s'y intéressent.

      Et quand on y réfléchit bien, le modèle du service sur le web a besoin de ce type de caractéristiques. C'est la condition sine qua non pour pouvoir faire payer pour un service sur le Web: la fiabilité.

      --
      Mickaël Rémond

      Mickaël

      • [^] # Re: Les produits développés En Erlang

        Posté par  . Évalué à 1.

        Ericsson n'est plus la seule société désormais à utiliser Erlang.

        D'après le chapitre 1 de ton bouquin tu dis que Ericsson a décidé de ne plus utiliser Erlang. Peux tu en donner la raison ?

        • [^] # Re: Les produits développés En Erlang

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

          Oui, je peux en donner la raison.

          En 1998, un manager de chez Ericsson a décidé que seul C++ et Java pourrait être utilisé, trouvant en particulier que Java était l'avenir de l'équipement telco. C'est une décision administrative et non technique (Java pour l'équipement telco !! Impossible)

          En pratique, les projets utilisant déjà Erlang continue de l'utiliser et le succès des produits basés sur Erlang est tel, qu'ils sont liés à Erlang pendant encore 10 ans au moins.

          Par ailleurs, Java n'a pas du tout fonctionné pour ce genre de développement, et le C++ conduit Ericsson à des développements moins fiables et plus couteux.
          Le manager en question est parti d'Ericsson récemment, et le retour en grâce d'Erlang est possible chez eux.

          Entre temps, les créateurs d'Erlang sont partis d'Ericsson suite à la décision du dit-manager et ont fondé Bluetail. Avant de partir, ils ont convaincu Ericsson de placer Erlang sous une licence libre. Après un an et des poussières d'activité et plusieurs produits à succès (Mail robustifier, Web robustifier, Accelerateur SSL) ils sont rachetés par Alteon, puis Alteon par Nortel, pour 152 millions de dollars (si ma mémoire est bonne).

          Le développement du langage est maintenant de plus en plus communautaire et de moins en moins emprunt de l'image d'Ericsson, même si beaucoup d'activité autour de ce langage est nordique: société développant des produits de localisation dans un batiment par bluetooth (parlement Danois, nombreuses "appliances"), beaucoup d'autres sociétés mènent des développements dans ce langage dans le monde (France: Par exemple Cellicium, Afrique du sud, Etats-Unis: par exemple Sendmail, etc).

          Mickaël

          • [^] # Re: Les produits développés En Erlang

            Posté par  . Évalué à 1.

            C'est bizarre je sentais comme un costard cravate derrière cette histoire.

            Enfin grâce à lui cela a permis d'avoir ce langage en Open Source, sinon les créateurs ne seraient pas partis et convaincu Ericsson de le libérer.
            On peut le remiercier finalement :)

  • # RMLL 2003 à Metz

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

    Pour ceux que cela intéresse, passez aux RMLL 2003 à Metz, pour assister à la série de conférences sur les langages de programmation de haut niveau. Je vais présenter Erlang et Rei, mais il y a également beaucoup d'autres interventions très intéressantes:

    http://wiki.ael.be/rmll2003/index.php/ThemeLangages(...)

    Peut-être à bientôt à Metz !

    --
    Mickaël Rémond

    Mickaël

    • [^] # Re: RMLL 2003 à Metz

      Posté par  . Évalué à 1.

      Erlang m'intéresse beaucoup et cela peut etre une motivation pour aller au RMLL. Tu vas la faire en anglais ? vu que je suis nul je ne vais rien comprendre, donc je préfère laisser tomber sinon.

      • [^] # Re: RMLL 2003 à Metz

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

        Ma présentation d'Erlang aux RMLL sera en français. Tu peux donc venir et en profiter !

        Par ailleurs, je pense qu'on aura normalement un petit "stand" pour présenter les actions de l'association Erlang projects, faire des démos et discuter du langage ...

        A bientôt à Metz, j'espère !

        Mickaël

        • [^] # Re: RMLL 2003 à Metz

          Posté par  . Évalué à 2.

          J'ai fais mes comptes et malheureusement cela me coute moins cher d'acheter ton livre que de venir à Metz, mais ce n'est que partie remise !

          Par contre si quelqu'un pouvait enregistrer ta conf et la mettre à disposition sur le Net ca serait fabuleux (ce que j'aurais fais avec ton accord si j'étais venu).

          Une dernière chose, il est dommage que le binding Gtk pour Erlang ne soit plus maintenu, il date de Mai 2002 :

          http://sourceforge.net/projects/erlgtk/(...)

          • [^] # Re: RMLL 2003 à Metz

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

            Par contre si quelqu'un pouvait enregistrer ta conf et la mettre à disposition sur le Net ca serait fabuleux (ce que j'aurais fais avec ton accord si j'étais venu).

            Je n'ai rien contre un enregistrement. Parles-tu d'une vidéo ou d'un enregistrement audio. Pour ce qui est de l'enregistrement audio, je dois pouvoir le faire moi même en MP3 sans trop de difficulté.

            Ce n'est que partie remise effectivement pour se voir ;-)

            Concernant le binding GTK, je crois qu'il fonctionne encore. Si cela t'intéresse tu peux cependant essayer d'en reprendre la maintenance, en particulier si tu disposes de patches pour les dernières versions de la bibliothèque.

            Ce dont je rêve, c'est un support officiel de ce binding dans la distribution standard Erlang, aussi bien sur Linux que sur Windows pour préserver le côté multi-plateforme.

            Mickaël

            • [^] # Re: RMLL 2003 à Metz

              Posté par  . Évalué à 1.

              Parles-tu d'une vidéo ou d'un enregistrement audio

              Audio bien sûr, voir en ogg pour être au poil :
              http://www.april.org/actions/rms/20011120/enregistrement.html(...)

              Par contre il y a de grosses chutes dans le niveau sonore, qui vient je pense de la compression ogg qui merdoit sur les voix. Dans le doute mp3 ira bien à défaut de speex.

              Pour le binding je n'ai pas réussi à compiler contre Gtk2 vu que le script utilise encore gtk-config qui n'existe plus, pkg-config est utilisé. J'ai bien changé cela dans le configure.in mais j'ai eu pas mal d'erreur.
              Je vais donc essayer plus sérieusement depuis le cvs et avec les patches que tu cites.

              En tout cas merci pour ton bouquin, à midi j'ai couru à la fnac le chercher :) ; rien que la mise à jour du code à chaud et la migration de process sur un autre serveur je trouve cela génial.

              • [^] # Re: RMLL 2003 à Metz

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

                Pour l'audio, l'Archos n'enregistre qu'en MP3, donc je vais le laisser dans ce format. Je pense que le passage de MP3 vers OGG risque pour le coup de dégrader pas mal la qualité...

                Je vais donc essayer plus sérieusement depuis le cvs et avec les patches que tu cites.

                Je ne suis pas sûr que ça marche. Il faudra peut être patcher le machin toi même pour que cela passe...

                En tout cas merci pour ton bouquin, à midi j'ai couru à la fnac le chercher :) ; rien que la mise à jour du code à chaud et la migration de process sur un autre serveur je trouve cela génial.

                Cool :-)

                N'hésite pas à continuer la discussion en privé par mail (lorsque ce sujet DLFP sera mort), si tu as des questions ou des remarques (Mon adresse mail est dans le bouquin et n'est pas difficile à trouver sur le net ;-)

                Mickaël

  • # Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang

    Posté par  . Évalué à 1.

    pour se faire du clustering en deux coups de cuillère à pot... en plus avec une knoppix .... c'est par ici :

    http://www.debianplanet.org/node.php?id=961(...)

    pas encore eu le temps de tester mais ça a l'air d'être sympa à faire !

  • # Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang

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

    Une question bète : et en perf pure cela donne quoi ? Par rapport au C, Java et le c++ ?

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

  • # Sytème de types

    Posté par  . Évalué à 2.

    Je capte pas trop, quelqu'un connait le lien entre les papiers qu'on trouve sur google :
    http://directory.google.com/Top/Computers/Programming/Languages/Erl(...)

    et cet exemple :
    start(PortNo) when integer(PortNo) ->
    start(PortNo, {user, server}).


    C'est statiquement typé ou pas finalement ?¿?

    • [^] # Re: Sytème de types

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

      Erlang est dynamiquement typé. Ce que tu vois, ce sont des "guardes", qui permettent de sélectionner la clause de la fonction qui sera exécutée. Ce sont des conditions d'exécution. Les guardes peuvent portés sur les quelques types Erlang, sur la nature d'une structure de données, mais également permettent de vérifier certaines caractéristiques des paramètres de la fonction, comme par exemple le fait qu'une valeur soit strictement supérieure à zéro, ou bien comprise dans une plage de valeurs. Ces conditions sont vérifiées lors de l'exécution. Par exemple: is_negatif(Valeur) when Valeur < 0 -> true; is_negatif(Valeur) -> false. Renvoie 'true' si on lui passe un nombre négatif et 'false' dans le cas contraire. Ce peut être une manière d'implémenter les conditions en Erlang. C'est pour cela que dans le bouquin j'explique l'importance des fonctions et leur omniprésence. Il faut bien maîtriser en Erlang tout ce que l'on peut faire à l'aide des fonctions.

      Mickaël

      • [^] # Re: Sytème de types

        Posté par  . Évalué à 1.

        Oui, j'avais parfaitement compris, ça fait quelques temps que je pratique ce type de langages, mais pourquoi avoir choisi des types dynamiques dans une application qui nécessite de la robustesse. Et surtout, à quoi font références ces site webs ?

        Que penses-tu de mon post sur http://membres.lycos.fr/nraynaud29/blog/index.php?m=200306#14(...)
        Y'a des grosses conneries ?

        • [^] # Re: Sytème de types

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

          Pour les références que tu cherches sur le langage, peut-être que cela peut correspondre à tes besoins: Core Erlang.

          Pour le reste, c'est toujours un débat sans fin entre les ceux qui pensent que la robustesse ne peut venir que du contrôle de type et les industriels pragmatiques qui réalisent des applications sans cette caractéristique ;-)

          Si tu reprends l'historique des conférences utilisateurs Erlang, tu constateras que c'est un débat qui revient sans fin. Certains proposent des évolutions pour transformer le langage en un langage fortement statiquement typé. Les expériences n'ont manisfestement pas encore convaincu.

          Les guardes dont tu parles permettent cependant dans les cas où cela est nécessaire de tester le type de la structure passé en paramétre d'une fonction, mais ce test est fait dynamiquement. Par ailleurs, il est possible de développer ton code en ajoutant une couche de typage si tu en as besoin. Tu peux par exemple voir les travaux de Thomas Arts sur un outil baptisé Specweb, ajoutant une couche de typage à Erlang. En France, Fabien Dagnat travaille également sur des choses intéressantes.

          Les tenants d'Erlang sont également adeptes de l'extreme programming et de la validation d'un développement par sa couverture en terme de test, tout en conservant la même facilité de développement. Toujours est-il qu'Ericsson a réalisé en Erlang le routeur ATM AXD 301 et qu'il est robuste, qu'il est TRES disponible et qu'il est le produit phare du marché.

          La robustesse du résultat est je pense le fruit d'une bonne méthodologie de développement, d'un bon outillage de validation des développements, des facilités pour implémenter la tolérance aux pannes, de la dynamicité du langage, du mécanisme de supervision (processus travailleurs et superviseurs) impliquant une séparation du code de gestion des erreurs du code de l'application lui-même.

          Mickaël

Suivre le flux des commentaires

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