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.
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 ...
> 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.
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).
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:
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é.
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.
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.
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.
En plus pourquoi exclure l'armée, l'hopital, la recherche et la pédagogie? pour ne pas se facher avec les éditeurs sur ces gros marchés?
Il ne s'agit vraisemblablement que de limiter la complexité du domaine étudié en restreignant les usages relativement particulier.
Il existe de grosses différences de nature entre déployer une application bureautique ou sous-traiter le développement d'une application de gestion et embarquer du code dans un véhicule millitaire par exemple.
Pour éviter d'obscurcir le propos et traitant de domaines différents, l'ATICA a certainement préféré limiter le champ de l'étude à un champ d'application déjà suffisamment vaste.
[^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 2.
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: RMLL 2003 à Metz
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 2.
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: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 6.
> 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
[^] # Re: Les produits développés En Erlang
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 6.
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
# RMLL 2003 à Metz
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 2.
http://wiki.ael.be/rmll2003/index.php/ThemeLangages(...)
Peut-être à bientôt à Metz !
--
Mickaël Rémond
Mickaël
[^] # Les produits développés En Erlang
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 6.
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
[^] # Concernant les variables
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 5.
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
[^] # Clarification sur l'architecture de Rei
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 9.
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
[^] # Re: A propos du slogan
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 2.
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
[^] # Re: Légende urbaine : un alligator dans l e ramasse-miettes
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Mickaël
# Un bon outil de modélisation libre: Wings3D
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche Sortie de Houdini 6. Évalué à 2.
Mickaël
[^] # Re: Le guide IdealX des logiciels libres utilisables en production
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche Le guide IdealX des logiciels libres utilisables en production. Évalué à 6.
Mickaël
[^] # Re: Le guide IdealX des logiciels libres utilisables en production
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche Le guide IdealX des logiciels libres utilisables en production. Évalué à 8.
Et les exemples de succès industriels existent ;-)
Mickaël
[^] # Re: L'ATICA recommande l'utilisation de la licence GPL pour les développe
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche L'ATICA recommande l'utilisation de la licence GPL pour les développements libres des administrations. Évalué à 3.
Il ne s'agit vraisemblablement que de limiter la complexité du domaine étudié en restreignant les usages relativement particulier.
Il existe de grosses différences de nature entre déployer une application bureautique ou sous-traiter le développement d'une application de gestion et embarquer du code dans un véhicule millitaire par exemple.
Pour éviter d'obscurcir le propos et traitant de domaines différents, l'ATICA a certainement préféré limiter le champ de l'étude à un champ d'application déjà suffisamment vaste.
Mickaël
[^] # Re: RTFM? STFW?
Posté par Mickaël Rémond (site web personnel) . En réponse à la dépêche Links en mode graphique. Évalué à 2.
pour pouvoir ensuite compiler Links avec le mode graphique.
Effectivement, ce n'est pas documenté.
Mickaël