comme dirait un de mes anciens profs (je garderais mes commentaires pour moi, de manière à rester un minimum respectueux)
C'est vrai que faire des insinuations sur ton prof, tout en te gardant des insultes, c'est vachement respectueux.
"c'est parce que B, c'est avant-C"
C'est surtout parce que Z c'était une allusion à ZF (la théorie axiomatique des ensembles de Zermelo-Fränkel), et que B est une allusion à Nicolas Bourbaki, le mathématicien polycéphale auteur des Éléments de mathématique.
le super langage/méthode/etc... de spécification formelle développée par un je-sais-plus-qui (que mes études m'ont fait détester) avec lequel a été spécifié (et programmé ?) les lignes de métro totalement automatisées...
Je ne suis pas fan du B, mais il faudrait peut-être connaître un peu plus que ce que tu as appris en cours pour avoir les moyens de critiquer. Le B sert (et a été utilisé avec succès) dans le développement d'applications critiques. Ça reste néanmoins un outil proche du monde de la recherche, et il est évidemment hors de question que ce soit utilisé à grande échelle actuellement, mais ses descendants se trouveront peut-être un jour en entreprise (quoique j'en doute, la théorie intuitionniste des types me semblant posséder un meilleur potentiel à terme).
Il se trouve qu'il ya des gens dont c'est le métier d'étudier les langues.
C'était bien mon propos: fais-tu partie des linguistes pour faire des affirmations aussi péremptoires que celles que tu fais sur la facilité/difficulté de telle ou telle langue? Peux-tu m'indiquer des références sur le web confirmant tes dires? Ou es-tu juste capable de dire que t'as un copain anglophone qui t'as dit ça, bel exemple de démonstration!
Il n'y a que deux langues où on a "créé" des mots pour désigner ces inventions. les autres ont importé les mots avec les machines ou les bouquins (comme fast-food en français - on n'a pas de mot pour ça on prend l'américain)
Mais il ne suffit pas que tu le dises pour que ce soit vrai. Donne des exemples significatifs. Par exemple, quels vocables les langues allemande, arabe, chinoise, russe, hébreux, japonaise, wolof, etc, utilisent-elles?
Malgré les provocations qui émaillent ton texte, je reviens au véritable problème: il y a dans le monde plus de gens, et notamment de chercheurs, qui parlent anglais que français. Comme mon boulot est de faire de la recherche et pas de la traduction de pages web, je préfère directement écrire mes pages en anglais de façon à être compris du plus grand nombre (sachant aussi que les chercheurs français en informatique parlent généralement anglais, et comprennent en tout cas l'anglais technique). La loi Toubon sera appliquée quand l'État donnera les moyens aux gens de donner des versions bilingues de leurs productions.
Ce sont, à ma connaissance, les fondateurs de Sather, langage issu de Eiffel, qui ont prétendu que l'utilisation de la contravariance renforçait la sécurité du code.
Non, non, il s'agit d'un résultat général connu des théoriciens des langages de programmation, ce n'est absolument pas spécifique à Sather.
Dans un système de types avec sous-typage, on cherche à savoir quand on peut redéfinir ou pas une méthode, et quelles sont les contraintes à avoir sur les types des méthodes pour que le programme soit bien typé. On se trouve là en présence d'un problème indécidable. Mais, si on restreint la redéfinition à la contravariance sur les paramètres, alors on sait que le programme sera bien typé.
Ça ne veut pas dire que toute forme de covariance est à proscrire, simplement qu'il y a des cas où ça produira des programmes acceptés par le compilateur qui produiront quand même une erreur de type.
Un exemple que certaines formes de covariance sont acceptables, tu le donnes: c'est l'exemple des méthodes "binaires" (style is_equal). En fait, on sait qu'on peut accepter toutes les méthodes avec contravariance et toutes les méthodes binaires.
Le problème d'Eiffel, c'est qu'il permet plus que les méthodes binaires, car on peut employer like avec autre chose que Current, et obtenir ainsi des méthodes avec covariance, qu'Eiffel acceptera, peut-être à tort.
Ca fait deux ans que j'utilise Eiffel au travail, et le problème de la covariance / contravariance ne s'est jamais posé pour moi.
Mais ça tu n'en sais rien justement! Tu peux juste dire que, pour toutes les exécutions de tes programmes Eiffel utilisant la covariance, il n'y a pas eu de plantage. Mais rien ne te garantit plus que ça n'arrivera pas avec certaines données que tu n'as pas encore testées.
C'est justement le principe du typage fort que de te garantir qu'il n'y aura jamais d'erreur de type.
La question de la variance est devenue "idéologique". On devrait se contenter de faits mathématiques: la covariance des paramètres pose des problèmes dans le cas de la redéfinition de méthode.
Y a-t-il un chantre de la contravariance qui peut m'expliquer comment on se débrouille avec les héritiers de cette classe pour garder à cette fonction le même sens ?
L'exemple que tu donnes ici est celui d'une méthode "binaire", cas particulier pour lequel on sait que ça marche. C'est d'ailleurs ce qu'on appelle MyType dans la plupart des langages à objets modernes (i.e de la recherche).
c'est moi ou l'institut national de la recherche en informatique appliquée n'applique pas la loi Toubon ?
Toubon, il a oublié d'embaucher des traducteurs avec sa loi. En tant que chercheur (pas à l'INRIA), j'ai pas que ça à foutre que de faire mes pages en deux langues. Donc je préfère les faire en anglais en sachant que je serai compris par plus de monde. Incroyable n'est-ce pas?
Je dis ça parce que on a la seule langue au monde à avoir un vocable spécifique pour ordinateur - à la place de computer.
Ah oui, tu connais toutes les langues vivantes actuelles?
Nous avons aussi une langue plus précise et plus simple à bien maitriser que l'anglais.
Et comment tu le démontres ça?
Et puis au cas où un jeune de banlieue voulait marcher sur nos pate bandes ça lui ferait toujours ça à apprendre en plus.
Arf', merci pour les jeunes de banlieue, dont moi y en a faire partie (moi y en a pas encore avoir compris syntaxe français, alors anglais très compliqué, c'est sûr!).
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/(...) .
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.
Au contraire, l'algorithmique n'a rien d'indépendant. Le but était et reste l'analyse de la résolution de problèmes par ordinateurs ou plus généralement par des dispositifs "théoriques" comme les machines de Turing.
pour rappel NP ne veu pas dire non polynomial, mais non solvable polynomialement, ie on enpeut pas trouver de solutions par une approche polynomiale, mais la solution peut elle etre polynomiale)
NP = "non-déterministe polynomial", i.e une machine de Turing non-déterministe peut résoudre le problème en temps polynomial.
Problème: une machine non-déterministe physique, on connaît pas encore :-)
Faut éviter de gober tout le marketing autour de MathML et autres normes XML.
Sur cette intro à MathML http://www.dessci.com/en/support/tutorials/math(...) ils parlent des deux modes possible (avec un exemple): "presentation encoding" et "content markup". On peut utiliser deux syntaxes pour representer la meme formule, mais l'une est utilisée pour l'aspect "graphique" (web ou bouquin) alors que l'autre decrit l'objet mathématique.
Le "presentation encoding", c'est un truc qui de toute façon n'aurait jamais dû exister, c'est complètement inintéressant de représenter des termes en oubliant leur structure. Quant au soi-disant "content markup", ce ne sont que des macros, qui en plus sont prédéfinies, on ne peut même pas en définir soi-même! Mais au moins, ça a le mérite d'insister sur la structure des termes (leur syntaxe abstraite en somme).
Donc effectivement, MathML peut etre plus intéressant sur le plan sémantique que LaTeX, qui ne s'occupe reellement que de la présentation (certe structurée, mais en perdant de l'info sur les operateur mathématiques).
On aura une sémantique intéressante le jour où on aura moyen d'identifier des termes syntaxiquement différents, ce qui est loin d'être le cas pour le moment. Cela dit il y a des travaux là-dessus qui sont prometteurs (genre OpenMath, etc).
J'ajoute que TeX dispose de l'opérateur \special{...} qui permet d'envoyer des informations «à l'extérieur», pour justement être traitées par d'autres outils.
Dernière remarque: c'est un fait connu qu'il n'y a pas de notation commune en maths (contrairement à la physique par exemple), or MathML en impose une, contrairement à (La)TeX. Par exemple, regardez le nombre de notations pour un produit scalaire, ou pour un intervalle ouvert, ou même pour l'application de fonction (eh oui, il arrive qu'on écrive les applications de fonction en notation postfixe).
Comparer les sémantiques de XML et LaTeX me semble hasardeux:
- XML est une notation
- TeX est un langage de programmation (et LaTeX est une bibliothèque de macros écrites en TeX).
Ensuite, pour ce qui est des notations mathématiques, ni MathML ni le mode maths de (La)TeX ne sont intéressants sur le plan sémantique. Tout au plus peut-on dire que MathML ne s'occupe que de la structure d'une formule, alors que (La)TeX s'occupe aussi de sa présentation.
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Anaximandre . En réponse à la dépêche Après X, voici Y.... Évalué à 3.
C'est vrai que faire des insinuations sur ton prof, tout en te gardant des insultes, c'est vachement respectueux.
"c'est parce que B, c'est avant-C"
C'est surtout parce que Z c'était une allusion à ZF (la théorie axiomatique des ensembles de Zermelo-Fränkel), et que B est une allusion à Nicolas Bourbaki, le mathématicien polycéphale auteur des Éléments de mathématique.
le super langage/méthode/etc... de spécification formelle développée par un je-sais-plus-qui (que mes études m'ont fait détester) avec lequel a été spécifié (et programmé ?) les lignes de métro totalement automatisées...
Je ne suis pas fan du B, mais il faudrait peut-être connaître un peu plus que ce que tu as appris en cours pour avoir les moyens de critiquer. Le B sert (et a été utilisé avec succès) dans le développement d'applications critiques. Ça reste néanmoins un outil proche du monde de la recherche, et il est évidemment hors de question que ce soit utilisé à grande échelle actuellement, mais ses descendants se trouveront peut-être un jour en entreprise (quoique j'en doute, la théorie intuitionniste des types me semblant posséder un meilleur potentiel à terme).
[^] # Re: Inria
Posté par Anaximandre . En réponse à la dépêche Une nouvelle version stable de SmartEiffel. Évalué à 1.
[^] # Re: Et le Troll, il arrive quand ?
Posté par Anaximandre . En réponse à la dépêche Une nouvelle version stable de SmartEiffel. Évalué à 3.
Non, non, il s'agit d'un résultat général connu des théoriciens des langages de programmation, ce n'est absolument pas spécifique à Sather.
Dans un système de types avec sous-typage, on cherche à savoir quand on peut redéfinir ou pas une méthode, et quelles sont les contraintes à avoir sur les types des méthodes pour que le programme soit bien typé. On se trouve là en présence d'un problème indécidable. Mais, si on restreint la redéfinition à la contravariance sur les paramètres, alors on sait que le programme sera bien typé.
Ça ne veut pas dire que toute forme de covariance est à proscrire, simplement qu'il y a des cas où ça produira des programmes acceptés par le compilateur qui produiront quand même une erreur de type.
Un exemple que certaines formes de covariance sont acceptables, tu le donnes: c'est l'exemple des méthodes "binaires" (style is_equal). En fait, on sait qu'on peut accepter toutes les méthodes avec contravariance et toutes les méthodes binaires.
Le problème d'Eiffel, c'est qu'il permet plus que les méthodes binaires, car on peut employer like avec autre chose que Current, et obtenir ainsi des méthodes avec covariance, qu'Eiffel acceptera, peut-être à tort.
Ca fait deux ans que j'utilise Eiffel au travail, et le problème de la covariance / contravariance ne s'est jamais posé pour moi.
Mais ça tu n'en sais rien justement! Tu peux juste dire que, pour toutes les exécutions de tes programmes Eiffel utilisant la covariance, il n'y a pas eu de plantage. Mais rien ne te garantit plus que ça n'arrivera pas avec certaines données que tu n'as pas encore testées.
C'est justement le principe du typage fort que de te garantir qu'il n'y aura jamais d'erreur de type.
[^] # Re: Et le Troll, il arrive quand ?
Posté par Anaximandre . En réponse à la dépêche Une nouvelle version stable de SmartEiffel. Évalué à 2.
Y a-t-il un chantre de la contravariance qui peut m'expliquer comment on se débrouille avec les héritiers de cette classe pour garder à cette fonction le même sens ?
L'exemple que tu donnes ici est celui d'une méthode "binaire", cas particulier pour lequel on sait que ça marche. C'est d'ailleurs ce qu'on appelle MyType dans la plupart des langages à objets modernes (i.e de la recherche).
Cela dit, ça fait un bail que ces problèmes ont été très bien analysés, notamment par G. Castagna (http://www.di.ens.fr/~castagna/(...) ) et son super article "Covariance and contravariance: conflict without a cause" (ftp://ftp.di.ens.fr/pub/users/castagna/covariance.ps.Z(...) )
[^] # Re: Inria
Posté par Anaximandre . En réponse à la dépêche Une nouvelle version stable de SmartEiffel. Évalué à 5.
[^] # Re: La programmation clusterisée à la portée de tous ? Un livre sur Erlang
Posté par Anaximandre . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 1.
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 porte de tous ? Un livre sur Erlang
Posté par Anaximandre . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 3.
[^] # Re: Droit d'auteur et travailleurs
Posté par Anaximandre . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
En général, on fait remonter la notion moderne d'algorithme à l'énoncé de ses fameux problèmes (cf http://www.sciences-en-ligne.com/momo/chronomath/anx1/pb23_hilbert.(...) ) par Hilbert (cf http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Hilbert.htm(...) ), et ces problèmes étaient purement mathématiques.
cf. http://aleph0.clarku.edu/~djoyce/hilbert/problems.html(...) pour l'article (1900) de David Hilbert.
[^] # Re: Droit d'auteur et travailleurs
Posté par Anaximandre . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
NP = "non-déterministe polynomial", i.e une machine de Turing non-déterministe peut résoudre le problème en temps polynomial.
Problème: une machine non-déterministe physique, on connaît pas encore :-)
Pour le reste, OK.
[^] # Re: EuroTex 2003 [pour faire plaisir a jyb]
Posté par Anaximandre . En réponse à la dépêche EuroTex 2003. Évalué à 2.
Sur cette intro à MathML http://www.dessci.com/en/support/tutorials/math(...) ils parlent des deux modes possible (avec un exemple): "presentation encoding" et "content markup". On peut utiliser deux syntaxes pour representer la meme formule, mais l'une est utilisée pour l'aspect "graphique" (web ou bouquin) alors que l'autre decrit l'objet mathématique.
Le "presentation encoding", c'est un truc qui de toute façon n'aurait jamais dû exister, c'est complètement inintéressant de représenter des termes en oubliant leur structure. Quant au soi-disant "content markup", ce ne sont que des macros, qui en plus sont prédéfinies, on ne peut même pas en définir soi-même! Mais au moins, ça a le mérite d'insister sur la structure des termes (leur syntaxe abstraite en somme).
Donc effectivement, MathML peut etre plus intéressant sur le plan sémantique que LaTeX, qui ne s'occupe reellement que de la présentation (certe structurée, mais en perdant de l'info sur les operateur mathématiques).
On aura une sémantique intéressante le jour où on aura moyen d'identifier des termes syntaxiquement différents, ce qui est loin d'être le cas pour le moment. Cela dit il y a des travaux là-dessus qui sont prometteurs (genre OpenMath, etc).
J'ajoute que TeX dispose de l'opérateur \special{...} qui permet d'envoyer des informations «à l'extérieur», pour justement être traitées par d'autres outils.
Dernière remarque: c'est un fait connu qu'il n'y a pas de notation commune en maths (contrairement à la physique par exemple), or MathML en impose une, contrairement à (La)TeX. Par exemple, regardez le nombre de notations pour un produit scalaire, ou pour un intervalle ouvert, ou même pour l'application de fonction (eh oui, il arrive qu'on écrive les applications de fonction en notation postfixe).
[^] # Re: EuroTex 2003 [pour faire plaisir a jyb]
Posté par Anaximandre . En réponse à la dépêche EuroTex 2003. Évalué à 4.
- XML est une notation
- TeX est un langage de programmation (et LaTeX est une bibliothèque de macros écrites en TeX).
Ensuite, pour ce qui est des notations mathématiques, ni MathML ni le mode maths de (La)TeX ne sont intéressants sur le plan sémantique. Tout au plus peut-on dire que MathML ne s'occupe que de la structure d'une formule, alors que (La)TeX s'occupe aussi de sa présentation.