Yusei a écrit 4649 commentaires

Là où je bosse on a installé une version bricolée d'egroupware à des clients, dont un ou deux veulent synchroniser leur agenda avec leur PDA. On leur a donc installé Funambol. Il y a eu au moins deux fois des grosses pertes de données (le PDA qui commence à effacer tout l'agenda sur le serveur). Attention, donc, et prévoir une solution de restoration rapide.

Il ne faut pas confondre économie et politique économique. Les économistes prévoient très bien la plupart des problèmes dans les systèmes économiques, mais n'ont pas vocation à les corriger. C'est aux politiques économiques de décider d'un objectif et de s'appuyer sur les modèles économiques pour trouver des moyens d'y parvenir.

Pour prendre un exemple, lorsqu'une spéculation crée une crise monétaire dans un pays en développement, ce n'est pas parce que les économistes ne connaissaient pas le problème, c'est parce que les régulateurs n'ont pas eu envie de le résoudre.

Je pense que vu l'état de l'IA, on peut quand même lui concéder quelques avantages en lui laissant le temps de la réflexion et en lui donnant une entrée correcte... Quand des programmes commenceront à passer sérieusement le test de Turing comme ça, il sera temps de les rendre plus souples, mais en attendant je ne vois pas l'intérêt.

I'm not a unknow person.

il manque un "n" après le "a". Avec la phrase correcte, Alice s'excuse, demande ton nom, et le mémorise pour continuer à t'appeler comme ça par la suite.

on atteint des chiffres de plus de 97 %.

Quand on compile le compilateur, c'est ça ? (c'est ce qu'il m'a semblé comprendre dans la news précédente). Il y a des cas pas vraiment rares où le compilateur devrait être devin pour réussir à faire de l'inlining.

Pour prendre un exemple vraiment con, admettons que j'ai deux structures de données: une liste chaînée et un tableau. Au début de mon programme, je demande à l'utilisateur laquelle de ces deux structures il veut utiliser, et puis je fais des calculs. Par quel miracle Lisaac serait-il capable d'inliner le code de la liste ou du tableau dans mes calculs alors qu'il n'y a aucun moyen de savoir quelle est la structure de données choisie par l'utilisateur avant le runtime ?

de plus l'inlining se fait aisément, si tu résoud la liaison dynamique en utilisant une table dynamique.

Là j'avoue que je ne comprend pas ce que tu veux dire. Ce n'est pas du tout mon domaine mais pour moi la liaison dynamique c'est le contraire de l'inlining...

Tu trouveras des explications ici

Non, j'ai trouvé des slides, et les slides ça ne sert à rien sans la présentation qui va avec...

Faux, le compilateur Lisaac en est la preuve.

Mouais... j'ai plutôt eu l'impression, à lire les news, que Lisaac se rapproche souvent de l'efficacité du C et la dépasse parfois. De là à affirmer que c'est généralement au moins aussi rapide que du C, il y a une petite marge :)

Dans le concept de programmation objet, le fait qu'un objet puisse redéfinir une fonction définie dans une classe parente pose un problème pour l'inlining dont je ne suis pas convaincu qu'il puisse être résolu par le compilateur. On aurait donc sur ce point là une supériorité du C si on s'oblige à coder sans pointeurs de fonction. Et d'un autre côté un compilateur de langage de haut niveau possède des informations qui lui permettent certainement d'optimiser d'une autre manière. Pour l'instant... je n'ai pas d'opinion sur la rapidité relative de différents types de programmation, mais je doute qu'on ait des "preuves".

Bien sûr, l'utilisateur pourra lever les ambiguités, ce que je voulais dire c'est que, pour parler simplement, ça sera grave relou tant que les ordinateurs seront aussi mauvais en sémantique.

Et même s'ils commencent à comprendre ce qu'on dit, l'exercice est intéressant: faire un petit dessin à base de ronds, carrés et triangles, téléphoner à un ami, lui demander de refaire le dessin à partir de notre description. Il y a peu de chances que ça ressemble à quelque chose à moins d'utiliser un formalisme particulier (par exemple du papier quadrillé et des coordonnées). Le langage naturel pour être précis, c'est nul.

Personnellement, je ne rêve pas d'écrire mes programmes dans ma langue maternelle car sa grammaire est parfois ambigüe. J'imagine donc les galères de débuggage que ça peut générer.

Programmer dans un sous-ensemble de ma langue maternelle qui soit non-ambigü au niveau de la grammaire, pourquoi pas, mais là encore il y a des problèmes: la langue parlée est volontairement floue ("par là", "loin", "lourd"), si on veut être précis elle est verbeuse... peut-être pas l'idéal pour la programmation finalement.

Sauf erreur, ce n'est pas le langage qui gère la mémoire mais le compilateur. On peut donc imaginer une option "architecture" du compilateur qui permette de faire ce genre d'optimisations en fonction de l'architecture.

Évidemment, ça limite sérieusement le nombre d'architectures qu'on peut gérer.

Attention à la convention de Genève...

Je ne crois pas que les bons programmeurs puissent "sentir" la distinction entre deux bons algorithmes :) Facile de sentir que le tri à bulle est mauvais, mais pour choisir entre quicksort, mergesort et heapsort il faut un peu plus d'éléments. J'ai choisi cet exemple parce que justement on choisit souvent quicksort alors qu'il est moins bon "au pire".

Le fond du problème reste que si l'on n'a pas besoin de connaitre grand chose pour choisir un algorithme parmis ceux déjà créés, quand il faut créer soi-même c'est plus compliqué.

Je ne connais pas les sciences pour l'ingénieur, donc je manque d'éléments pour comprendre l'analogie.

En tout cas l'informatique n'a pas été formalisée après coup par des matheux, c'est eux qui l'ont créée pour répondre à une question bien précise (que peut-on calculer). Je n'ai pas l'impression que depuis elle soit devenue une science à part.

Ton exemple fait appel a des notions de maths de terminale.

Non. Ou alors en terminale tu as étudié les arbres aléatoires et les séries génératrices, ce qui conforterait la thèse selon laquelle le niveau de l'enseignement se dégrade.

C'est effectivement intéressant: The Art of Computer Programming (taocp) est-il un livre de maths ou non ? Les outils utilisés sont des outils mathématiques, et l'objet étudié est une machine de Turing (ou un algorithme, c'est pareil), qui est un objet mathématique.

Quand Knuth prend un algorithme et prouve qu'il est correct, il effectue une preuve mathématique. Je ne vois pas de différence entre le cours de maths de terminale où je devais prouver la correction (c'est le bon mot ?) de l'algorithme d'Euclide pour factoriser des nombres, et les preuves d'algorithmes de taocp.

Quand dans son quatrième tome il aborde les énumérations, on est en plein de la combinatoire, pour ceux qui en doutaient encore après la lecture des tomes précédents.

Quand il calcule la complexité d'un algorithme, difficile de nier qu'il s'agit aussi d'une preuve mathématique en regardant les méthodes utilisées. Alors finalement la question porte vraiment sur la nature mathématique ou non de l'objet qu'on étudie (l'algorithme).

Rappelons quand même que la machine de Turing est un formalisme qui a été créé pour répondre à la question: quels sont les objets mathématiques que l'on peut calculer ?

Quel est le meilleur algorithme de tri à inclure dans une bibliothèque (et donc pas pour un besoin spécifique mais en général) ?

Avec des notions de base en complexité, on peut calculer la complexité au pire de Quicksort, O(n^2) et celle de Mergesort O(n * log n), et en déduire que Mergesort est meilleur.

Si on arrive à calculer la complexité en moyenne, on se rend compte que Quickstort, en moyenne, est en O(n * log n), et si on investigue un peu on se rendra compte qu'en pratique il est en général plus rapide.

C'est un exemple classique qui explique pourquoi la complexité au pire n'est pas toujours suffisante pour choisir un algorithme. Et calculer la complexité en moyenne d'un algorithme, c'est souvent une autre paire de manches. J'ai eu à prouver celle de Mergesort en DEA...

En fait, j'ai l'impression que pour toi un "besoin pratique de l'informatique", ça sera plutôt d'ouvrir un livre, regarder les différentes complexités et savoir reconnaitre laquelle est la meilleure. Effectivement dans ce cas, il suffit de savoir qu'un logarithme est meilleur qu'une exponentielle.

Laquelle, de licence ? Creative Commons en proposent plusieurs. Il peut être utile de préciser, car si vous n'utilisez ni la clause "non commercial", ni la clause "pas d'oeuvres dérivées" et que le graphiste est plus restrictif sur sa licence, vous risquez de mal vous entendre.

En fait, tout depend d'ou on place la limite entre math et informatique.

Je ne place pas de limite entre maths et info, et c'est pour ça que je m'amusais à demander naïvement quelle était la différence. Je te rassure, je sais que tout le monde ne partage pas ce point de vue ;)

Pour le défendre, je ne ferais que souligner que les gens les plus connus en informatique sont mathématiciens. À commencer par les créateurs de l'informatique comme on la connait (Turing, Church, Von Neumann) jusqu'au auteurs plus récents (Knuth, qui a créé TeX mais surtout écrit The Art of Computer Programming, qui est un livre de maths, Claude Berge qui a plus ou moins créé la théorie des graphes, ...).

Pour moi, la recursivite, c'est de l'info pure, rien a voir avec les maths. Et ca ne necessite aucune notion de math. Les preuves de programme, idem. La complexite ca necessite des notions de math niveau terminale (premier cycle universitaire au max), pour les considerations pratiques en tout cas. Pareil pour la theorie des graphes etc, etc...

Houla, ok... je ne veux pas te vexer en suggérant que tu n'as pas beaucoup étudié l'informatique théorique, mais bon... tout ça c'est des maths. Toutes ces choses ont toutes été créées par des mathématiciens, et ils ne seront sûrement pas d'accord pour les voir sortir de leur domaine ;)

Pour prendre l'exemple le plus extrême, dire que la théorie des graphes n'est pas des maths, c'est euh... comment dire... ce n'est même pas un domaine de l'informatique qui s'apparente aux maths, c'est des maths, ça en a toujours été. Si on considère que les graphes sont un outil informatique parce qu'on s'en sert en informatique, on peut penser la même chose des transformées de Fourier, de la théorie de l'information, de la cryptographie...

fondamentalement, le travail d'un informaticien, meme de haut niveau, qui ecrit un programme n'a rien a voir avec celui d'un mathematicien.

Je suis d'accord pour le fait d'écrire un programme, mais c'est une petite partie du travail de l'informaticien, qui doit aussi concevoir le programme et le valider. Pour la conception et la validation, il s'agit de mathématiques.

Pour ne prendre qu'un exemple, lorsque les informaticiens ont créé des réseaux, ils se sont demandés comment reproduire certains algorithmes qui avant étaient centralisés, de manière décentralisée. Par exemple, si tu connais la topologie (maths !) de ton réseau, tu peux facilement calculer les distances (minimales) entre deux noeuds. Mais si tu es un ordinateur sur le réseau, et que tu ne connais pas à priori sa topologie, c'est plus compliqué. Il a donc fallu concevoir des algorithmes distribués qui faisaient le même travail. C'est de l'informatique ? des maths ? Au point de vue du travail à effectuer, c'est des maths de bout en bout, mais le domaine d'application est indiscutablement l'informatique.

Et là, comme on a effectivement bien dévié du sujet, je dirais quand même que je bosse (plus pour longtemps) pour un SSII, et quand je code des sites webs en Rails ou quand j'installe un serveur mails, je suis conscient de ne pas faire (beaucoup) de maths. Mais je ne crée rien de nouveau, je ne fais qu'assembler des briques qui servent à faire des traîtements classiques sur des données. Ce n'est malheureusement pas tous les jours que les informaticiens-programmeurs doivent résoudre de nouveaux problèmes.

Beaucoup trop de langages "universitaires" se focalise sur le langage

C'est pas très étonnant. Je ne serais pas non plus surpris d'apprendre que les frameworks universitaires (si ça existe) se focalisent sur les frameworks.

Je suis d'accord qu'un langage sans framework n'est pas très utile en pratique, mais comment reprocher à des gens qui font de la recherche sur les langages de s'intéresser au langage en lui même ? Évidemment que quand ils comparent C# et le leur, ils parlent du langage et pas du framework.

C'est d'autant plus vrai que le framework est assez indépendant du langage, et toi qui est fan de .NET tu ne diras pas le contraire. Si tout d'un coup Lisaac se mettait à cibler la plateforme .NET, ça ne le rendrait pas meilleur ou moins bon langage, mais ça résoudrait son problème de framework.

J'ai envie de dire que le langage en soit est presque accessoire

Tu risques d'être souvent déçu par les news sur des langages en cours d'élaboration alors, car tu n'y trouveras jamais un framework à la hauteur de celui de Java.

<Mr Jourdain>Grace à ce thread, j'ai enfin compris ce qu'était l'AOP, et réalisé que j'en faisais sans le savoir.

Il ne manque qu'un framework pour fabriquer des frameworks et la boucle est bouclée

Je parierais gros que parmis la population des programmeurs, y compris des meilleurs, seule un petite minorite a des connaissances approfondies en informatique theorique et estime que ca fait d'eux de meilleurs programmeurs.

Peut-être que ça explique la légendaire fiabilité de l'informatique ;)

Plus sérieusement, comme je le disais, si tout ce que tu fais c'est de la gestion de données, tu n'auras peut-être pas besoin de maths, encore que tu aies besoin de connaître quelques notions de complexité pour choisir tes structures de données.

Mais si tu veux résoudre de nouveaux problèmes avec tes données, pas simplement les lire/modifier/enregistrer/trier, tu vas avoir besoin d'écrire des algorithmes, et là tu vas avoir besoin d'éléments pour:
- écrire le code
- prouver que ton code fait ce que tu veux
- savoir si c'est efficace

Je prend des exemples à la con, mais il est assez difficile par exemple de concevoir un algorithme de routage si on ne sait pas ce qu'est un graphe. Difficile d'écrire l'algorithme de routage si on n'est pas à l'aise avec la récursion. Difficile de prouver qu'il fait ce que l'on veut. Difficile de calculer sa complexité.

L'informatique n'étant pas destinée uniquement à assembler des composants existants, dès qu'on veut créer du code on utilise des maths.

Par contre je suis sûr que beaucoup de gens les utilisent sans savoir que c'en est.

Il n'y a pas de raison pour qu'un langage dont la syntaxe ne reprend pas celle du C++ soit incompréhensible. Ruby l'a largement prouvé.

Il y a des langages qui sont innovants, performants et bien plus satisfaisants du point de vue de l'informaticien, mais qui ne se sont pas imposés simplement parce qu'ils n'avaient pas le soutien d'une grosse boîte comme Sun ou MS. Le langage Java est encore en retard sur Eiffel, qui existait pourtant bien avant.

Parler de remplacer Java ou C# implique bien plus que discuter les qualités du langage. Le langage Java n'a pas été conçu pour être un langage innovant, il a été conçu comme une sorte de C++ un peu plus propre adapté à la plateforme Java. Sa force n'a jamais été le langage, mais la plateforme et les bibliothèques. Pour n'importe quel projet je préfèrerais coder en Eiffel, mais pour n'importe quel projet je préfère le framework de Java.

En fait le problème avec le langage Java, c'est que tous ses choix sont des compromis décevants. C'est un langage qui se veut de haut niveau mais il reprend la syntaxe lourde du C++. Il se veut un langage orienté objet mais n'en reprend que le minimum vital. Grace à sa VM il est assez dynamique mais ne propose rien dans sa syntaxe pour en profiter. Forcément si on le compare au C++ c'est un petit progrès, mais si on le compare à d'autres langages c'est frustrant. Si seulement Sun avait copié Eiffel au lieu de copier C++...

Je trollais un peu, mais comme dans tout troll il y a une part de vérité.

Un ordinateur et un programme sont des objets mathématiques. Il existe de nombreux modèles mathématiques équivalents qui les décrivent, dont les plus connus sont les machines de Turing et le lambda calcul.

Toutes les questions concernant ce qu'on peut faire ou pas avec un ordinateur, la preuve de validité et sur la performance des algorithmes, ne trouvent leurs réponses que dans le cadre de ces modèles. Si on programme sans faire de maths, on ne peut résoudre que des problèmes très simples et rien de nouveau.

Ceci dit comme les compilateurs et bibliothèques se chargent d'une partie des maths, on peut généralement s'en passer tant qu'on se limite à des interfaces pour manipuler des données (tri, affichage, enregistrement...).

Que ce soit uniquement une étape du style "on mettra les bibliothèques après"
Ils ont dit au moins deux fois dans le thread ne pas gérer "encore" les bibliothèques partagées. En tout cas ce dont tu parles, ce n'est pas de programmation modulaire, c'est de la possibilité de charger le code pendant le runtime. La confusion vient surement du fait que tu pensais "programmation de modules chargeables au runtime".

mais si le support de bibliothèques/plugins/modules/cquevousvoulez élimine en grosse partie l'intérêt de l'algo principal d'optimisation dont ils sont fier

Il y a assez peu de chances, dans la mesure où c'est le genre d'optimisation qui n'a d'intérêt que dans les quelques pourcents de code les plus gourmands en calcul de toute application. Pour peu que tes plugins fassent des travaux plus ou moins indépendants les uns des autres, ce n'est pas là dessus qu'on pourrait gagner grand chose.

Maintenant, il faut se rendre compte qu'il y a des choses qui ne sont pas optimisables. Si tu as un algo compliqué et que tu veux pouvoir changer ses structures de données au runtime (sans ré-optimiser au runtime), tu auras de grosses difficultés théoriques, qui n'ont rien à voir avec le langage choisi. Reprocher ça aux créateurs de Lisaac n'aurait aucun sens, donc je pense que ce n'est pas ce que tu voulais dire.