French respondents exhibited a strong anti-Microsoft sentiment as sixty-one percent (61%) stated that an alternative to Microsoft was the most compelling reason to support OSS. This sentiment was echoed to a lesser extent among the Germans (37%) and Swedes (35%).
While US respondents were the most likely to have heard about Shared Source (91%) followed by the Japanese (86%) and the Swedes (81%) most respondents had heard only very little about the initiative. The French were the least likely to have heard anything about Shared Source with only 63% saying they have heard nothing at all.
After being read a series of possible Shared Source benefit statements, large majorities in every country save for France (41%) said that the Shared Source initiative offered at least the same benefits as OSS.
Overall, the greatest challenges we face are with the International audience especially the French, Germans, and Japanese.
The French are looking for an alternative to Microsoft, have high familiarity and favorability of OSS and Linux, and a strong belief that Linux has a lower TCO than proprietary software. This geography, while not yet ready to broadly deploy Linux with their businesses, is very interested in OSS and its potential. The vast majority of this audience had not heard anything about Shared Source, but was more positive than negative towards the idea. They do not feel, however, that Shared Source will provide better benefits than OSS.
Par disjonction de cas, on peut facilement inférer que :
- si le rapport est un faux, de toute évidence quelqu'un nous déteste
- si le rapport est authentique, de toute évidence nous détestons quelqu'un et il est fort probable que celui-ci nous le rende plus ou moins ouvertement.
Sans vouloir jouer les rabat-joie, il faut être honnête : la principale raison pour laquelle Eiffel est populaire dans les milieux académiques français, c'est justement que c'est un langage conçu par un Français
Le langage Ada aussi a été conçu par un français (Jean Ichbiah). Je vous conseille d'aller jeter un coup d'oeil à cette petite histoire d'Ada :
Une rapide comparaison de ce qui a été réalisé en C et de ce qui a été réalisé en lisp que je vous invite à faire nous conduit à une conclusion inévitable et sans appel
Vous n'avez de toute évidence pas la moindre idée de ce qui a été fait en Lisp, en C ou en n'importe quel autre langage ; un petit aperçu s'impose
Les langages dans lesquels ont été écrits le plus grand nombre de lignes de code sont
- Cobol (entreprises, gestion, comptabilité)
- Ada (systèmes embarqués, domaine militaire)
- Lisp (toute l'informatique jusqu'au début des années 80 - avant l'apparition du C)
- Fortran (tout le calcul scientifique jusqu'à très récemment)
arrivent seulement ensuite C, C++ et Java
Y-a-t-il des systèmes d'exploitations écrits en Lisp ? oui... des tas. Il y avait même des machines spécialement construites autour d'un interprète Lisp (tout comme il y a des machines qui executent directement du byte code Java)
Je vais tenter de donner des éléments de réponse à vos questions :
- vous recommanderiez quoi comme bouquin pour mieux saisir les joies de la programmation fonctionnelle ?
La question est difficile... Mon livre préféré est celui de X. Leroy et P. Weis que je recommande vivement, mais il s'agit de Caml même s'il s'efforce de donner un aperçu syntétique de la question.
Je vous conseille d'aller faire un tour dans la section livres de plusieurs langages fonctionnels (Haskell, Caml, ML), d'éventuellement télécharger des tutoriels pour vous en faire une idée : http://www.haskell.org(...) (livres en anglais exclusivement) http://www.ocaml.org(...)
- plus ca va, plus python a l'air d'integrer des fonctionnalites de programmation fonctionnelle. Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ? D'apres ce que je vois, les langages fonctionnels supportent aujourd'hui le double paradigme fonctionnel et imperatif. Donc eux aussi se rapprochent ?
Tous les langages fonctionnels ne supportent pas le double paradigme fonctionnel/impératif : contre-exemple Haskell.
Lisp est aussi vieux que Fortran et antérieur à C, Ada, etc. Autrement dit les langages fonctionnels ne se rapprochent pas, ils ont toujours été là.
Quant à savoir si les langages purement impératifs vont un jour adopter les paradigmes venus du monde fonctionnel, jusqu'à présent toutes les initiatives en ce sens ont échoué, que ce soit Pizza (au dessus de Java) ou autres. C'est fondamentalement un problème de conception, à l'image des machines virtuelles de Java et de Python sont irrécupérables (et resteront à jamais des tortues devant celle de Caml)
- y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels ?
Caml et Haskell ont des wrappers pour toutes les librairies graphiques nécessaires (ils ont d'ailleurs des interfaces C, COM, etc?). Vous trouverez nombre d'applications Caml qui utilisent une interface Tk ou GTk, j'ai même vu un jeu en openGL
(voir les entrées correspondante dans la bosse -the hump- sur le site caml précédemment cité)
- j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante [comment on traduit 'lazy' ?] et ses capacites de mise a jour dynamique. Il semble que ce genre de fonctionnalite ne fasse pas partie de OCaml mais que ca soit bien quand meme. Vous pouvez m'expliquer ?
Il ne faut faire la part entre les différents concepts :
- typage dynamique / typage statique
Le typage dynamique se fait à l'exécution (Lisp), le typage statique à la compilation (Caml), certains langages ont une part des deux (Java)
Le principe du typage statique est "si le programme compile correctement, il n'explosera pas à l'exécution" autrement dit pas de segfaults, pas de message d'erreur "method not found", etc.
Cela désigne le fait que lors de l'appel à une fonction, tous les arguments sont évalués même s'ils sont inutiles (strict) ou seulement les arguments nécessaires sont évalues (paresseur). Exemples caractéristiques Caml / Haskell.
Cependant, les langages paresseux comportent toujours des mécanismes pour forcer une évaluation stricte (! en Haskell) et inversement les langages stricts ont des calculs déférés (type lazy en Caml)
- réflexivité
C'est un concept plus difficile, il s'agit de pouvoir se manipuler soi-même en tant que langage. Par exemple en Lisp les fonctions sont des listes, donc on peut les manipuler comme des listes (prendre la tête, coller avec une autre queue, etc.)
- mise à jour dynamique
Je ne vois pas très bien ce que vous voulez dire par là, sans doute faites vous référence à la particularité de pouvoir changer les éléments en cours d'éxécution (un peu à la SmallTalk).
Il faut savoir que cela est caractéristique des langages interprétés (typiquement SmallTalk), seulement tant Lisp que Caml ou Haskell viennent en version interprétée ou compilée.
Lisp (même compilé) permet certaines manipulations du genre (Java aussi par exemple), mais il s'agit là plutôt de réflexivité
Maintenant, avoir un système self-réflexif statiquement typé ? j'ai entendu parler d'expériences smalltalk mais c'est tout. Peut-être caml s'en approche par camlp4 et le chargement dynamique de libs mais on est loin du compte. P4 offre un vrai système de macros sympa (je connais pas celui de lisp).
MetaOCaml (et son cousin MetaML) comme leur nom l'indique s'efforcent de permettre la métaprogrammation tout en conservant les qualités bien connues des langages de la famille ML
# Pourquoi nous détestent-ils ?
Posté par AnneDeMontMorency . En réponse à la dépêche Halloween VII. Évalué à 2.
While US respondents were the most likely to have heard about Shared Source (91%) followed by the Japanese (86%) and the Swedes (81%) most respondents had heard only very little about the initiative. The French were the least likely to have heard anything about Shared Source with only 63% saying they have heard nothing at all.
After being read a series of possible Shared Source benefit statements, large majorities in every country save for France (41%) said that the Shared Source initiative offered at least the same benefits as OSS.
Overall, the greatest challenges we face are with the International audience especially the French, Germans, and Japanese.
The French are looking for an alternative to Microsoft, have high familiarity and favorability of OSS and Linux, and a strong belief that Linux has a lower TCO than proprietary software. This geography, while not yet ready to broadly deploy Linux with their businesses, is very interested in OSS and its potential. The vast majority of this audience had not heard anything about Shared Source, but was more positive than negative towards the idea. They do not feel, however, that Shared Source will provide better benefits than OSS.
Par disjonction de cas, on peut facilement inférer que :
- si le rapport est un faux, de toute évidence quelqu'un nous déteste
- si le rapport est authentique, de toute évidence nous détestons quelqu'un et il est fort probable que celui-ci nous le rende plus ou moins ouvertement.
Terrifiant non ?
Anne
[^] # Re: Eiffel
Posté par AnneDeMontMorency . En réponse à la dépêche SmallEiffel devient SmartEiffel. Évalué à 8.
Le langage Ada aussi a été conçu par un français (Jean Ichbiah). Je vous conseille d'aller jeter un coup d'oeil à cette petite histoire d'Ada :
http://www.cs.fit.edu/~ryan/ada/ada-hist.html(...)
[^] # Re: Mouai
Posté par AnneDeMontMorency . En réponse à la dépêche Common LISP, un langage à (re)découvrir. Évalué à 4.
Le lisp est plus vieux que le C
Une rapide comparaison de ce qui a été réalisé en C et de ce qui a été réalisé en lisp que je vous invite à faire nous conduit à une conclusion inévitable et sans appel
Vous n'avez de toute évidence pas la moindre idée de ce qui a été fait en Lisp, en C ou en n'importe quel autre langage ; un petit aperçu s'impose
Les langages dans lesquels ont été écrits le plus grand nombre de lignes de code sont
- Cobol (entreprises, gestion, comptabilité)
- Ada (systèmes embarqués, domaine militaire)
- Lisp (toute l'informatique jusqu'au début des années 80 - avant l'apparition du C)
- Fortran (tout le calcul scientifique jusqu'à très récemment)
arrivent seulement ensuite C, C++ et Java
Y-a-t-il des systèmes d'exploitations écrits en Lisp ? oui... des tas. Il y avait même des machines spécialement construites autour d'un interprète Lisp (tout comme il y a des machines qui executent directement du byte code Java)
[^] # Re: Quelques questions
Posté par AnneDeMontMorency . En réponse à la dépêche Common LISP, un langage à (re)découvrir. Évalué à 7.
- vous recommanderiez quoi comme bouquin pour mieux saisir les joies de la programmation fonctionnelle ?
La question est difficile... Mon livre préféré est celui de X. Leroy et P. Weis que je recommande vivement, mais il s'agit de Caml même s'il s'efforce de donner un aperçu syntétique de la question.
Je vous conseille d'aller faire un tour dans la section livres de plusieurs langages fonctionnels (Haskell, Caml, ML), d'éventuellement télécharger des tutoriels pour vous en faire une idée :
http://www.haskell.org(...) (livres en anglais exclusivement)
http://www.ocaml.org(...)
- plus ca va, plus python a l'air d'integrer des fonctionnalites de programmation fonctionnelle. Vous croyez qu'un langage imperatif peut s'approcher d'un langage fonctionnel suffisamment pour en procurer les avantages ? D'apres ce que je vois, les langages fonctionnels supportent aujourd'hui le double paradigme fonctionnel et imperatif. Donc eux aussi se rapprochent ?
Tous les langages fonctionnels ne supportent pas le double paradigme fonctionnel/impératif : contre-exemple Haskell.
Lisp est aussi vieux que Fortran et antérieur à C, Ada, etc. Autrement dit les langages fonctionnels ne se rapprochent pas, ils ont toujours été là.
Quant à savoir si les langages purement impératifs vont un jour adopter les paradigmes venus du monde fonctionnel, jusqu'à présent toutes les initiatives en ce sens ont échoué, que ce soit Pizza (au dessus de Java) ou autres. C'est fondamentalement un problème de conception, à l'image des machines virtuelles de Java et de Python sont irrécupérables (et resteront à jamais des tortues devant celle de Caml)
- y a-t-il des boite a outils graphique (style Qt, gtk, ...) et des constructeurs d'interface (glade, Qt Designer, ...) avec vos langages fonctionnels ?
Caml et Haskell ont des wrappers pour toutes les librairies graphiques nécessaires (ils ont d'ailleurs des interfaces C, COM, etc?). Vous trouverez nombre d'applications Caml qui utilisent une interface Tk ou GTk, j'ai même vu un jeu en openGL
(voir les entrées correspondante dans la bosse -the hump- sur le site caml précédemment cité)
- j'ai cru comprendre qu'une des forces du Lisp etait la souplesse de ses types definies de facon plutot faineante [comment on traduit 'lazy' ?] et ses capacites de mise a jour dynamique. Il semble que ce genre de fonctionnalite ne fasse pas partie de OCaml mais que ca soit bien quand meme. Vous pouvez m'expliquer ?
Il ne faut faire la part entre les différents concepts :
- typage dynamique / typage statique
Le typage dynamique se fait à l'exécution (Lisp), le typage statique à la compilation (Caml), certains langages ont une part des deux (Java)
Le principe du typage statique est "si le programme compile correctement, il n'explosera pas à l'exécution" autrement dit pas de segfaults, pas de message d'erreur "method not found", etc.
- évaluation stricte / évaluation paresseuse (lazy)
Cela désigne le fait que lors de l'appel à une fonction, tous les arguments sont évalués même s'ils sont inutiles (strict) ou seulement les arguments nécessaires sont évalues (paresseur). Exemples caractéristiques Caml / Haskell.
Cependant, les langages paresseux comportent toujours des mécanismes pour forcer une évaluation stricte (! en Haskell) et inversement les langages stricts ont des calculs déférés (type lazy en Caml)
- réflexivité
C'est un concept plus difficile, il s'agit de pouvoir se manipuler soi-même en tant que langage. Par exemple en Lisp les fonctions sont des listes, donc on peut les manipuler comme des listes (prendre la tête, coller avec une autre queue, etc.)
- mise à jour dynamique
Je ne vois pas très bien ce que vous voulez dire par là, sans doute faites vous référence à la particularité de pouvoir changer les éléments en cours d'éxécution (un peu à la SmallTalk).
Il faut savoir que cela est caractéristique des langages interprétés (typiquement SmallTalk), seulement tant Lisp que Caml ou Haskell viennent en version interprétée ou compilée.
Lisp (même compilé) permet certaines manipulations du genre (Java aussi par exemple), mais il s'agit là plutôt de réflexivité
Lisp
forces :
- réflexivité
faiblesses :
- typage dynamique
Caml
forces :
- typage statique
- vitesse
faiblesse :
- absence de réflexivité (cependant MetaOCaml)
- je crois que je devrai faire un tour sur un newsgroup de programmation fonctionelle.
Il y a une FAQ qui peut vous être utile
- ca a l'air cool l'inria, vous etes tous payes pour vous eclatez sur des trucs qui vous plaisent ? Comment qu'on rentre ?
On rentre par concours. Voir http://inria.fr(...) pour les postes disponibles (tout niveaux : chercheurs, ingénieurs confirmés ou débutants...)
[^] # Re: vive Lelisp ;)
Posté par AnneDeMontMorency . En réponse à la dépêche Common LISP, un langage à (re)découvrir. Évalué à 1.
MetaOCaml (et son cousin MetaML) comme leur nom l'indique s'efforcent de permettre la métaprogrammation tout en conservant les qualités bien connues des langages de la famille ML
http://cs-www.cs.yale.edu/homes/taha/MetaOCaml/(...)
http://www.cse.ogi.edu/PacSoft/projects/metaml/(...)
http://www.cse.ogi.edu/PacSoft/projects/Mustang/Overview.html(...)