Articles précédents : Développeur
- [5] Appel à contribution pour "Do & don't for device drivers".
- [35] Recherche directeurs de thème
- [18] Version d'évaluation d'une distribution RedHat pour x86_64 (Opteron™).
- [71] Le format PNG sur nos sites WEB
- [4] Résumé GNOME - 19.04.2003
- [24] L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?
- [30] Driver Savage XP Castlerock / CLE266 : Une implémentation libre
- [8] Glade 2.0.0 est disponible
- [116] Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
- [19] Kit du développeur d'OpenOffice.org 1.0.2
Liens connexes
- Erlang Projects (964 hits)
- La page du livre sur le site Eyrolles (1223 hits)
- Le jeu Rei (805 hits)
- Erlang.org (650 hits)
- Erlang-fr (1356 hits)
Dépêche modérée par
Développeur : La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Mickaël Rémond (page perso, ). Modéré le 07 juin 2003.
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 !
![[en]](../../../images/en.png)
Erlang Projects (964 hits)![[fr]](../../../images/fr.png)
La page du livre sur le site Eyrolles (1223 hits)-
Le jeu Rei (805 hits)
-
Erlang.org (650 hits)
-
Erlang-fr (1356 hits)
> Lire les commentaires (65 commentaires, moyenne: 2).
A propos du slogan
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 Yusei () le 07/06/2003 à 14:22. (lien). É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 madko (Jabber id, ) le 07/06/2003 à 15:14. (lien). Évalué à -1.c plus l'oposition mou != dur pour le jeu de mots
mou et qui ne casse pas
ça a lair bien--
Linux, ya moins bien, mais c'est plus cher!!!-
[^]Re: A propos du slogan
Posté par Yusei () le 07/06/2003 à 15:25. (lien). É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 zyglotron () le 07/06/2003 à 16:19. (lien). É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 Pode () le 07/06/2003 à 18:27. (lien). É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 Sylvain Rampacek (Jabber id, page perso, ) le 07/06/2003 à 20:28. (lien). Évalué à 1.merci !
c'est corrigé !
-
-
-
-
-
-
[^]Re: A propos du slogan
Posté par Mickaël Rémond (page perso, ) le 07/06/2003 à 20:52. (lien). É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
PLEAC-Erlang
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 harbort () le 08/06/2003 à 09:38. (lien). É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 PloufPlouf (Jabber id, page perso, ) le 08/06/2003 à 15:47. (lien). É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 Christophe KINNE () le 08/06/2003 à 19:30. (lien). Évalué à 1.Le Perl Cookbook ne serait-il pas edité sous le nom de "Perl en action" de chez O'Reilly ?
-
[^]Re: PLEAC-Erlang
-
-
-
[^]Re: PLEAC-Erlang
Posté par yoho (page perso, ) le 10/06/2003 à 13:27. (lien). É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 yoho (page perso, ) le 10/06/2003 à 13:41. (lien). Évalué à 1.Tiens, à propos, pourquoi y a pas Java dans les langages du PLEAC ?
-
[^]Re: PLEAC-Erlang
-
[^]Re: PLEAC-Erlang
Posté par yoho (page perso, ) le 20/06/2003 à 12:54. (lien). Évalué à 1.Sorry, je suis vraiment un boulet :)
-
-
Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
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 Mickaël Rémond (page perso, ) le 07/06/2003 à 21:03. (lien). É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
-
[^]Précisions
Posté par Thierry Mallard () le 11/06/2003 à 07:53. (lien). É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
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¢
Développeur OpenSource
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Olivier Meunier (page perso, ) le 07/06/2003 à 20:01. (lien). É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 Mickaël Rémond (page perso, ) le 07/06/2003 à 21:11. (lien). É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
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Dugland Bob (page perso, ) le 07/06/2003 à 21:17. (lien). É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 Dugland Bob (page perso, ) le 07/06/2003 à 22:45. (lien). Évalué à 1.Bon, j'ai oublié de parler de la transparence référencielle mais je pense qu'elle vous est venue immédiatement à l'esprit avec le passage sur les effets de bourd :-)
-
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Moby-Dik () le 07/06/2003 à 22:26. (lien). É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 Mickaël Rémond (page perso, ) le 08/06/2003 à 07:50. (lien). É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.-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par alenvers () le 08/06/2003 à 09:08. (lien). Évalué à 2.> 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à.
Il me semble que la plupart des algorithmes de parcours d'arbres et de graphes sont presque toujours présentés de mamière récursive. La version non-récursive étant bien moins "naturelle"...
Pour ce qui est des optimisations, python n'est vraiment pas un bon exemple. Le but de python c'est de compiler et de s'exécuter sans trop de problèmes. Le fait de ne pas dérécursifier la récursivité terminale et/ou d'effectuer de la compiliation partielle n'est pas très étonnant dans cette optique (faisons un truc qui marche ensuite optimisons).
>simple exemple universitaire classique.
Un mauvais exemple par ailleur si on l'apprend dans le cadre d'un langage impératif genre pascal, C, ... La factorielle est un processus purement itératif ==> boucle.
A part ça,
Ente
for (fact=1, i =2 ; i <=n ; fact*=i++) ;
ou
fact(0) = 1
fact(n) = fact(n-1) * n
J'ai choisi.
L'un me semble plus lisible que l'autre, pas vous ?
La récursivité semble généralement naturelle à ceux qui ont pas mal pratiqués les démonstrations par induction/récurrence.-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
-
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Moby-Dik () le 08/06/2003 à 10:15. (lien). É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 Mickaël Rémond (page perso, ) le 09/06/2003 à 08:03. (lien). É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.
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Dugland Bob (page perso, ) le 09/06/2003 à 20:23. (lien). É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 Mickaël Rémond (page perso, ) le 10/06/2003 à 06:49. (lien). É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.
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
-
-
-
-
-
[^]Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Anaximandre () le 10/06/2003 à 08:39. (lien). É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
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 Mickaël Rémond (page perso, ) le 07/06/2003 à 21:25. (lien). É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-
[^]Re: Les produits développés En Erlang
Posté par fredix (Jabber id, page perso, ) le 08/06/2003 à 02:53. (lien). É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 Mickaël Rémond (page perso, ) le 08/06/2003 à 07:39. (lien). É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).-
[^]Re: Les produits développés En Erlang
Posté par fredix (Jabber id, page perso, ) le 08/06/2003 à 11:48. (lien). É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
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
-
[^]Re: RMLL 2003 à Metz
Posté par fredix (Jabber id, page perso, ) le 08/06/2003 à 12:48. (lien). É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 Mickaël Rémond (page perso, ) le 09/06/2003 à 07:34. (lien). É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 !-
[^]Re: RMLL 2003 à Metz
Posté par fredix (Jabber id, page perso, ) le 10/06/2003 à 12:17. (lien). É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 Mickaël Rémond (page perso, ) le 10/06/2003 à 15:46. (lien). É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.-
[^]Re: RMLL 2003 à Metz
Posté par fredix (Jabber id, page perso, ) le 10/06/2003 à 16:16. (lien). É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 Mickaël Rémond (page perso, ) le 10/06/2003 à 17:19. (lien). É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 ;-)
-
-
-
-
-
Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
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
Une question bète : et en perf pure cela donne quoi ? Par rapport au C, Java et le c++ ?
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Nicolas Boulay () le 10/06/2003 à 13:03. (lien). Évalué à 1.Allo la terre ?
Personne pour donner une idée des perfs purs à attendre de Erlang ???--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par yoho (page perso, ) le 10/06/2003 à 13:39. (lien). Évalué à 1.Moi j'y connais rien, mais pour avoir fait un peu de "temps réel" au cours de mes études, j'ai toujours entendu dire que c'étais un peu plus lent que les autre langages. Néanmoins, c'est difficilement comparable :
On n'utilise pas un langage temps réel pour faire de la 3D hyper-optimisée, c'est inaproprié.
On n'utilise pas du Visual Basic pour faire des commandes d'Airbus, c'est inaproprié aussi...
:)-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Nicolas Boulay () le 10/06/2003 à 15:24. (lien). Évalué à 1.Langage temps réel ? cela n'a pas de sens !
Disons que je sépares les langages en 2, l'un type script : quick&dirty (bash, perl), l'autre pour les applis plus grosse : C, java, c++, maintenant Caml,... Sachant que l'un déborde sur l'autre mais avec toujours les mêmes default (php, perl,..)
Donc soit Erlang a une vitesse comparrable au C voir java/c++, il est donc "rapide" soit il est comparrable à perl ou python, il est donc "lent", et tout ce qui est calcul disparait (sachant qu'il fait des check de type dynamique, il doit être plus lent que les autres).--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par yoho (page perso, ) le 10/06/2003 à 16:26. (lien). Évalué à 1.Ah bon ? et Prolog, Lisp, ADA, tu les classes où dans ta liste ?
Néanmoins, tu as raison, "langage temps réel" cela ne veut rien dire. Je voulais parler d'un "langage pour les systèmes temps réels" (http://www.inria.fr/valorisation/logiciels/temps-reel.fr.html(...) ).
Je pense qu'Erlang fait partie de cette catégorie, mais il est possible que je me trompe.-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Nicolas Boulay () le 11/06/2003 à 07:19. (lien). Évalué à 1.Ada est clairement un langage pour grosse application (embarqué en général d'ailleurs).
Lisp a part dans emacs, je ne vois pas où c'est utilisé comme langage autre que script.
Prolog est utilisé ailleurs que dans la recherche ?--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Anaximandre () le 11/06/2003 à 08:28. (lien). Évalué à 1.Prolog est utilisé ailleurs que dans la recherche ?
Prolog lui-même non, mais ses descendants oui, par exemple chez ILOG. On parle alors de langages de contraintes (CLP), car ils ne se cantonnent pas à l'unification, mais permettent l'expression de contraintes plus complexes. Cf. par exemple http://contraintes.inria.fr/(...) .
-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Mickaël Rémond (page perso, ) le 11/06/2003 à 10:30. (lien). Évalué à 1.Le Lisp est très utilisé dans l'industrie:
http://www.lisp.org/table/commercial-use.htm(...)
Pas nécessaire à partir d'implémentations Open Source, mais souvent à base d'Arlequin, de Frantz Lisp ou d'autres implémentations commerciales.
-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par yoho (page perso, ) le 20/06/2003 à 13:00. (lien). Évalué à 1.Savoir si prolog ou lisp sont utilisés n'est pas la question : selon toi il n'existe que deux types de logiciels, ce que je dément et je t'ai montré le contraire.
Les langages ne sont pas inventés pour "faire bien". Ils ont toujours une raison d'être.
-
-
-
-
-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Mickaël Rémond (page perso, ) le 10/06/2003 à 16:44. (lien). Évalué à 1.Répondre brièvement aux questions sur les performances est le plus souvent impossible. On peut écrire des dizaines de thèses sur la performance comparée des langages informatiques (intrinsèque ou lié à l'implémentation).
En évitant la dérive vers le troll (autant que possible):
- Erlang n'est pas fait pour le calcul numérique. Ne pas l'utiliser pour cela.
- Pour faire du calcul numérique, s'appuyer sur une bonne bibliothèque de calcul numérique (binding).
- Ne pas ce fier au benchmark «Bagley». Il n'est ni fait ni à faire pour Erlang: Il prend en compte le lancement de la machine virtuelle avec le boot d'un environnement Erlang complet (lançant l'application Erlang SASL notamment); il ne prend pas en compte les possibilités de compilation native (HiPE); et pas mal d'erreurs dans les tests eux-mêmes. (Personne n'a pris la peine de corriger dans la communauté Erlang, parce que tout le monde s'en fout).
- Une comparaison d'un même algorithme en C et en Erlang n'est pas directement comparable, car le même programme Erlang, même compiler nativement fait plus de choses, en particulier lié à son caractère dynamique.
- Pour les applications réseaux et notamment les serveurs, les performances d'Erlang sont très bonnes (j'aurais pu dire Rulez). Voir en particulier: http://www.sics.se/~joe/apachevsyaws.html(...) pour une comparaison de performance sur un serveur Web et http://tsunami.idealx.org/(...) pour un outil de benchmark capable de montée en charge. Erlang est fait pour les serveurs et ça se voit.
Voilà. J'espère que j'ai, globalement répondu à tes questions, de manière objective.-
[^]Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Nicolas Boulay () le 11/06/2003 à 07:21. (lien). Évalué à 1.au moins c'est clair, pas de numérique pure mais des trucs complexes.
--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
Sytème de types
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 Mickaël Rémond (page perso, ) le 10/06/2003 à 06:44. (lien). É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.
-
[^]Re: Sytème de types
Posté par Dugland Bob (page perso, ) le 10/06/2003 à 12:17. (lien). É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 Mickaël Rémond (page perso, ) le 10/06/2003 à 17:13. (lien). É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.-
[^]Re: Sytème de types
Posté par Mickaël Rémond (page perso, ) le 10/06/2003 à 17:21. (lien). Évalué à 1.Le lien vers Core Erlang: http://www.csd.uu.se/projects/hipe/corerl/(...)
-
-
-
Cette page a été générée par Templeet en 0.2372s (dont 0.0202 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.