Développeur : Lisaac 0.12 en GPL v3
Posté par Ontologia (page perso, ). Modéré le 24 septembre 2007.
Les benchs effectués sur des traductions fidèles de programmes C donnent des résultats différents en fonction de l'architecture cible : on obtient, grossièrement, un code de 20 % plus rapide à 30 % plus lent.
La spécification 0.2 apporte de nombreuses nouveautés au langage : un système de types amélioré, une syntaxe où la casse permet de séparer clairement mot-clé, prototype/type et variables, un système de contrats amélioré et gérant l'héritage, une gestion automatique des micro/macro objets, l'héritage alimentaire, une gestion des blocks très puissante. L'innovation la plus visible est l'apparition des résultats multiples : une méthode peut retourner plusieurs valeurs, de même qu'elle peut en accepter plusieurs en argument.
Le compilateur est en outre capable de produire des statistiques sur les appels potentiels sur NULL et de prédire l'endroit où ils risquent d'arriver. Les temps d'exécution, la consommation mémoire et surtout la stabilité du compilateur ont été considérablement améliorés.
L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code. Cette technique de compilation, qui analyse et prédit les chemins potentiellement empruntés par le code à l'exécution permet une optimisation très poussée de celui-ci afin se rapprocher des performances du C (voir les benchs).
Dominique Colnet (auteur de SmartEiffel) et Benoit Sonntag ont quasiment terminé un traducteur Eiffel vers Lisaac. Ce traducteur permettra à Lisaac de bénéficier d'une bibliothèque Eiffel rigoureusement traduite de l'originale, et donc de disposer d'une bibliothèque testée et sûre. Cette bibliothèque devra ensuite être retravaillée afin d'utiliser au mieux la puissance d'un langage objet à prototype.
La version 0.3 de Lisaac, implémentera la gestion de la concurrence avec le modèle COP, qui automatisera celle-ci. La version 0.4 apportera la stabilisation syntaxique, sémantique et fonctionnelle du langage, ce qui permettra le lancement du projet Isaac OS, le système d'exploitation objet à prototype. Le projet Isaac sera ainsi réellement lancé.
Espérons que la communauté répondra présent à ce formidable défi.
NdM : l'"héritage alimentaire" est appelé comme cela car c'est un héritage qui possède toutes les propriétés de l'héritage classique, mais "secrètement". C'est à dire que vu de l'extérieur de l'objet qui utilise ledit héritage alimentaire, on ne sait pas qu'il hérite.
![[en]](../images/en.png)
Isaac Project (1020 hits)-
Page de téléchargement (218 hits)
-
Benchmarks (462 hits)
![[fr]](../images/fr.png)
Lisaac sur Wikipédia (1031 hits)
> Lire la dépêche (345 commentaires, moyenne: 2,3).
Vous avez demandé le commentaire #869384.
sonntag
J'interviens pour la première fois, car je suis un peu déçu des remarques que cet article occasionne et aussi parce que pour la première fois, je pense que mon produit a un petit intérêt.
(Après 6 ans de travail)
J'aimerai des critiques constructives après m'être battu pour que Lisaac soit Libre !
Premièrement : On arrive enfin à compiler des prototypes. Expressivité importante: une donnée peut devenir du code et inversement durant l'exécution. L'héritage peut être modifié durant l'exécution, modèle fomel avec les blocks...
Deuxièmement : Nous avons les meilleures performances dans le domaine de l'objet pur (Et cela ne se discute même pas!).
Et Troisièmement : Je n'interviendrai pas ultérieurement, donc je salue tous les programmeurs de SmallTalk, SmartEiffel, Self, IO, ...
Et je dénonce les langage c#, Java, ... comme étant des langages qui n'auraient jamais du faire partie de l'histoire de l'informatique ! Ils ont 30 ans de retard... (tout en restant cool)
Pour finir, je dirai que Lisaac est un petit langage moderne qui est dédié à des programmeurs qui aiment le bas niveau, le C ou ASM.
Je viens de cette catégorie, j'ai tout fait dans ce sens.
Si j'interviens ce soir, c'est parce que nous avons besoin de soutien!
Faites l'effort de découvrir ce langage, (comme je l'ai fait à l'époque pour SmartEiffel et Self) vous n'en serrez pas déçu. Et si vous avez des idées pour améliorer la bête, je suis tout prêt à vous répondre.
Travaillons ensemble vers autre chose que C# et Java...
[^]Re: sonntag
Rassure-toi, j'ai l'impression que tous les commentaires (sauf un) sont très encourageants et admiratifs quant à Lisaac.
C'est comme ça sur DLFP : il y a plusieurs sons de cloches, mais sur beaucoup de sujets, le "collectif" parle d'une voix relativement claire (il n'y a qu'à regarder la note du commentaire de Lucas comparée à celles des autres pour s'en convaincre).
Bravo pour Liisac, à toi et à tous les autres contributeurs (même si je ne saisis pas encore vraiment tous les intérêts de ce langage, n'étant pas programmeur).
[^]Re: sonntag
Pour ma part, les quelques dépêches/journaux proposés par Ontologia m'avaient donné envie de regarder du côté de Lisaac, mais j'avoue qu'il y a tellement de "langages libres" que j'aimerais apprendre mieux (Eiffel, OCaml...) que je n'avais pas pris le temps d'essayer. C'est l'occasion de m'y mettre, pour voir.
(J'avoue aussi que les exemples de codes ne me parlent pas du tout, mais c'est peut-être normal)
[^]Re: sonntag
Quel genre d'exemple te parlerait mieux ?
[^]Re: sonntag
En fait je comprend les exemples mais, comme beaucoup ici, je trouve ça assez laid. Les exemples sont simples, donc je comprend, mais ça m'inquiète quand j'imagine du code en plus grande quantité. Les exemples que je vois sur le site ne me montrent pas les qualités du langage.
(à part la syntaxe condition.if que je trouve rigolote)
[^]Re: sonntag
En fait, du code Lisaac, ce n'est pas forcément moche ... C'est même joli si on a la bonne coloration syntaxique.
Tu veux voir du code Lisaac ? http://codebrowse.launchpad.net/~mildred/liworld/trunk/files(...) (dans le répertoire src)
Sinon, le code Lisaac ressemble fortement à du C, et est du même coup facile à apréhender. Il semblerait que Benoît l'ait étudiée pour. Par contre, le truc qui peut être déroutant, c'est que tu n'a ni mot clef break, ni continue. Du coup du dois te débrouiller autrement. C'est faisable facilement mais ça force a réfléchir souvent un peu plus.
Une question: Lisaac optimise-t-il les boucles du genre :
( + bool :BOOLEAN; ... 1.to 20 do { i:INTEGER; bool.if { // Quelque chose } }; )Ça permet de remplacer les Break et Continues facilement je trouve.
PS: à quand la possibilité de poster facilement du code sur DLFP ? Par exemple pouvoir utiliser la balise <p> ou <br/>La Roue du Temps
[^]Re: sonntag
Bon j'ai déjà fait la remarque, ne te sens pas visé, mais si on regarde SmallTalk, on voit qu'il n'a pas eu un grand succès, par contre Ruby lui, qui n'en est pas si loin que ça de Smalltalk, a bien décollé.
Il a décollé pour plusieurs raisons:
1- un langage très souple, mais ça Smalltalk l'avait déjà.
2- une syntaxe *très* agréable: car parlant au programmeurs C, shell, Perl, mais en plus propre.
3- une killer-app Ruby on Rails, qui a été réalisée car Ruby a 1 et 2.
Isaac a (1) mais pas (2) *a mon avis*..
Hors (3), le vrai déclic, ne vient que si suffisamment de programmeurs s'interesse au langage donc il faut d'abord avoir (1) (la c'est bon) *et* (2)..
Après chacun a ses préférences pour la syntaxe, mes favoris actuels sont Ruby et Scala.
Après je ne prétends pas avoir la recette ultime..
[^]Re: sonntag
Isaac a (1) mais pas (2) *a mon avis*..
c'est pas sympa pour Isaac_Newton, vu que tu t'es visiblement trompé, réessaie avec Lisaac cette fois-ci :-)
[^]Re: sonntag
En plus benoît m'a dit que la syntaxe de Lisaac a été étudiée pour être proche du C et être facilement compréhensible par n'importe qui.
Après, le problème, c'est que sur les court exemples, on a le mot clef Section qui peut perturber, mais c'est comme le public: du C++. le vrai code Lisaac est très joli.
La Roue du Temps
[^]Re: sonntag
Je dois être bigleux, mais plus je vois de code Lisaac, et moins je vois de rapport (lexical / grammatical) avec du C ....
Honnêtement, je ne vois pas en quoi Lisaac est plus joli que du C.
[^]Re: sonntag
>Lisaac a été étudiée pour être proche du C
Pour une valeur très faible de proche: le ':=' a la place du =, ça ne fait pas très C!
Bon plus sérieuseusement, moi je ne le trouve pas joli (des gouts et des couleurs je sais), pour être plus constructif, ce que je n'aime pas dans la syntaxe de Lissac:
-Les types tout en majuscules, beh ça fait mal aux yeux, commencer par une majuscule est suffisant et bien plus lisible.
-Le dernier élément évalué qui est la valeur de retour de la fonction: les gars d'EROS avait fait une étude et avait trouvé que c'était une mauvaise idée du point de vue de la sécurité car souvent des fonctions retournaient des trucs qu'elles n'auraient pas due.. Donc ils suggèrent d'utiliser plutôt un mot clef explicite, le ^ de Smalltalk me paraît tout indiquer ici.
-Les +| -var : type := value; pour définir des variables, on s'y fait peut-être mais au départ c'est plutôt génant.
Je prefere la syntaxe de Limbo:
a: type; // declare a et l'initialise avec la valeur du type par defaut
a : type = val; // declare a et l'initialise avec val
a := val; // inférence de type: declare a avec le type de val et l'initialise avec val, c'est la variante la plus utile.
a = val; // a doit être déjà déclaré.
Après pour le scope (+ et -), je ne sais pas trop, juste que par défaut cela devrait être local.
[^]Re: sonntag
En fait, je ne suis même pas sûr que la qualité intrinsèque du langage compte tant que ça.
Regarde PHP, beaucoup de monde sait programmer en PHP, alors que c'est un langage qui a toujours été en retard sur beaucoup de concepts, et que presque personne de "cultivé" ne peut trouver "beau".
Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
[+] [^]Re: sonntag
Lisaac cherche des codeurs type C/C++ voir java/C# pas ceux qui touche à PHP ou VBA...
[^]Re: sonntag
Certes, mais je dirais que PHP et Perl se sont ouvert des niches car ils sont arrivés les premiers sur leur créneau.
Après justement sur le créneau du Web et du scripting, Ruby gagne du terrain car justement il est plus élégant (avec beaucoup de difficulté car le poids de l'installé est énorme).
>Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
Tout à fait exact.
[^]Re: sonntag
Hum ... Il n'a pas eu, certes, le succès escomptée. Pourtant, aujourd'hui, il semble avoir le vent en poupe et permet même de construire des outils assez en avance : squeak, open croquet, seaside, pour ne citer qu'eux, sont assez détonnant, surtout en perspective des applications qu'ils ont permis de produire comme par exemple Dabble DB ou Qwaq. Ce qui est marrant, c'est qu'il semble que c'est via Ruby qu'un certain nombre de programmeurs s'oriente de plus en plus vers Smalltalk.
Jusqu'à présent, par son essence même, Smalltalk semble être le seul qui permet de construire rapidement et proprement une application d'une certaine qualité, une application qui reste ... objet (et pas seulement dans la programmation). Aussi, si Lisaac me semble intéressant, il me laisse toutefois un sentiment de perplexité (je ne sais pourquoi) ; mais il faudrait que je l'essai à nouveau. Je pense qu'il prendra probablement toute sa force dans un environnement approprié (isaacOS ?).
[^]Re: sonntag
arrete de te plaindre Benoit. Si tu veux communiquer sur ton langage, fait plutot passer la news sur freshmeat ou plnews. LinuxFr est ... comment dire.... une tribune ou les opinions sont bien tranchees ! :-)
[^]Re: sonntag
Fresmeat c'est fait. Plnews, on peut pas poster.
Slashdot, ça passe pas, évidemment.
[^]Re: sonntag
Je suis admiratif du travail effectué sur ce langage qui a l'air bien sympathique. Par contre, côté syntaxe, je souffre.
Je suppose qu'une partie de la syntaxe est héritée du SmallTalk ou de Eiffel, en tout cas d'un langage que je ne connais pas. J'ai vraiment du mal à comprendre la logique des exemples de code.
La page sur la simplicité vante le faible nombre de mot-clé, mais j'ai l'impression que cela se paie en "caractère-clé", ce qui rend le code plutôt pénible à déchiffrer. Comme Perl quoi...
phil.freehackers.org
[^]Re: sonntag
non en fait c'est le coté ultra minimaliste du code qui impose ça.
Tout est objet même les clause logique du if, même les bloc de code des 2 branches du if...
Une fois que tu as compris ça, tout devient plus claire :)
[^]Re: sonntag
Comme le langage est très extensible, tu peux utiliser une syntaxe très proche du C.
par exemple un test peut très bien s'écrire
if (condition) then {...} else {...};
Ou encore tu peux faire un appel de fonction (grâce aux paramètres multiples de la version 0.2) ainsi:
mafonction(param, param);
On dirait presque du C. Après bien sûr de base tu ne peux pas le faire car les fonctions de la lib sont écrites autrement (avec des mots-clefs) ... Mais Lisaac a cette possibilité.
Enfin, s'approcher de cette syntaxe n'est pas le but de Lisaac. Mais c'est pour dire que Lisaac n'a pas une syntaxe si étrange que ça. Je me rappelle le jour ou j'ai commencé à programmer en Lisaac, avant je ne comprenant rien à la syntaxe, mais moins d'une heure après, j'avais tout compris.
La Roue du Temps
[^]Re: sonntag
Je connais peu les problèmes spécifiques de développement bas niveau, mais clairement, ce que tu as fait me semble avoir plus qu'un "petit intérêt" :
- Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ? (Forth ?) Clairement, Lisaac me semble une innovation dans ce domaine et elle est la bienvenue.
- De ce que j'en ai vu, l'interface Lisaac/C semble être extrêmement aisée puisqu'on peut écrire du code C dans une méthode Lisaac, ce qui me paraît également un très bon point pour travailler avec des systèmes existants.
Un créneau qui me semblerait intéressant, c'est de convaincre des développeurs de modules du noyau Linux ou/et des développeurs de (modules) xorg d'utiliser Lisaac (attention qd même aux questions de licence), car cela donnerait une forte visibilité à Lisaac. Est-ce dans tes projets ?
Linux est écrit en C, un langage qui n'aurait jamais dû exister. J'aimerais beaucoup que C puisse être mis à la poubelle et remplacé par un langage de plus niveau et *nix lui-même remplacé par des OS mieux conçus. On peut rêver d'un OS en Haskell (voir le boulot très intéressant d'Andrew Tolmach sur le sujet) et de machines Lisp mais C ne pourra sans doute être remplacé que progressivement, de manière évolutive. J'attends donc beaucoup de Lisaac...
Judicaël.
PS : Pour justifier mes remarques sur C : Les débordements de tampons, responsables de la majeure partie des failles de sécurité, étaient inexistants en 1974 sous le système le plus sécurisé de l'époque. Il faut dire qu'il était écrit en PL/I, un langage certes assez gros, mais dans lequel on pouvait manipuler des chaînes de caractères de façon décente. Plus d'infos : http://www.acsac.org/2002/papers/classic-multics.pdf
Pour mémoire, 33 ans après, je viens de jeter un coup d'oeil au 60 premières vulnérabilités données sur CVE (http://www.cve.mitre.org/cve/) sur les 365 de ce mois (septembre 2007). Pour 9 d'entre elles (15%), on trouve "buffer overflow" ou "stack overflow" dans le résumé...
[^]Re: sonntag
>Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ?
Le C++ :-) ?
Pas taper!
Plus sérieusement: D qui a le gros avantage justement d'être proche du C++, tout en étant mieux fait (c'était pas dur ;-) ).
Pour ta comparaison C/Haskell, bof: le C pour moi, a un gros avantage sur Haskell: je comprends ce que fait le compilateur, Haskell repose sur des concepts que je ne comprends pas (et oui j'ai lu plein de tutoriels sur les monad mais ça ne m'a pas éclairé).
Ceci dit, je suis d'accord qu'il y a mieux que le C, mais pour moi ce n'est pas Haskell: je veux développer des programmes, pas faire des math.
[^]Re: sonntag
C'est pas la même chose ?
[^]Re: sonntag
Non, ce n'est pas la même chose.
C'est d'ailleurs la raison pour laquelle la plupart des langages de recherche ne percent pas : parce que leurs concepteurs pensent qu'un langage de programmation doit s'apparenter à un langage formel décrivant des objets mathématiques.
[^]Re: sonntag
C'est d'ailleurs la raison pour laquelle la plupart des langages de recherche ne percent pas : parce que leurs concepteurs pensent qu'un langage de programmation doit s'apparenter à un langage formel décrivant des objets mathématiques.
Ce qui n'est pas le cas pour Lisaac.
Il est certes très minimaliste, mais pas à but mathématique.
Benoit Sonntag l'a certes pensé en tant que chercheur, mais aussi en tant qu'auteur de logiciel généraliste : il a été demo-coder, il a écrit un logiciel de dessin vectoriel, etc...
C'est vraiment un langage qui a été conçu pour faire de tout.
[^]Re: sonntag
Heu, quel est le rapport ? (question sérieuse)
[^]Re: sonntag
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...).
[^]Re: sonntag
Il me semble que tu surestimes tres largement le role des maths (et de l'informatique theorique) dans la programmation. Contrairement a ce que tu dis, je pense que la quasi totalite des problemes qui se posent en programmation se resolvent sans faire de maths.
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.
Bien sur il faut etre capable de comprendre des notions de base comme la complexite, mais ca reste totalement elementaire d'un point de vue mathematique, et ca ne necessite absolument pas de passer par de quelconques modeles mathematiques de programmes.
Bon, je ne remet pas en cause l'interet de l'informatique theorique d'un point de vue intellectuel, mais force est de constater le decalage enorme entre les preoccupations des informaticiens (ceux qui font des programmes qui servent) et les preoccupations que les theoriciens imaginent chez les informaticiens.
Cela dit, ce message n'avait pas forcement lieu d'etre dans un thread sur Lissac. Son contenu ne lui etait pas destine.
[^]Re: sonntag
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.
[^]Re: sonntag
En fait, tout depend d'ou on place la limite entre math et informatique.
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...
Mais on s'ecarte du sujet. Ce que je voulais dire, c'est que non, les programmes informatiques ne sont pas des objets mathematiques. Il peuvent effectivement etre formellement decris comme tel, mais fondamentalement, le travail d'un informaticien, meme de haut niveau, qui ecrit un programme n'a rien a voir avec celui d'un mathematicien.
[^]Re: sonntag
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, ...).
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...
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.
[^]Re: sonntag
En fait, si, j'ai fait beaucoup d'informatique theorique. Mais je ne suis pas vexe, car je sais qu'il y a une petite part de mauvaise fois dans mes propos. J'ai bosse avec des logiciens, des types qui ecrivent des papiers de recherche incomprehensibles en voulant formaliser des concepts somme toute relativement simple de l'informatique, alors ca m'a traumatise.
Mais sur le fond, je persiste. "The Art of Computer Programming" n'est en rien un livre de math, meme si Knuth a demarre dans les maths. Le fait d'utiliser des notions de math ne fait pas de quelqu'un un mathematicien, ni des concepts crees des concepts mathematiques.
On pourrait appliquer le meme raisonnement a la physique. La physique ce n'est pas des maths. Ce n'est pas parcequ'on resoud une equa diff qu'on est un mathematicien.
Quand a tes exemples, pareil, les maths ne sont qu'un outil, d'ailleurs en general utilise a un niveau elementaire, licence au maximum. OK, il y a de la crypto qui depote pas mal niveau math mais c'est plutot une exception.
Enfin bon, la question de ce que sont les mathematique est complexe est tres interessante. J'imagine que des tas de gens mieux place que moi ont beaucoup ecris sur le sujet.
[^]Re: sonntag
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 ?
[^]Re: sonntag
Les sciences pour l'ingénieur étant le plus possible cohérentes, elles ont besoin de preuve de type mathématiques pour justement démontrer cette cohérence.
Si je prends la théorie des éléments finis très utilisée en calcul de structure, elle a été mise au point par des mécaniciens, puis des matheux ont formalisé tout cela avec la notion de formulation faible et d'espace de Sobolev. Cela ne veut d'ailleurs pas dire que tout calcul éléments finis est mathématiquement juste car seul un petit bout de ce qu'utilise les mécaniciens est 'prouvé' mathématiquement.
Alors maintenant, on trouve des bouquins qui sont 'à cheval' entre les mthas et la mécanique et qui expose les éléments finis plutôt d'un point de vue ou plutôt de l'autre.
C'est pas pour cela qu'un ingénieur fait des maths lorsqu'il calcule un pont ! Il utilise des maths pour faire des Sciences Pour l'Ingénieur (le fameux SPI qu'on voit un peu partout maintenant).
[^]Re: sonntag
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.
[^]Re: sonntag
> Je n'ai pas l'impression que depuis elle soit devenue une science à
> part.
Justement, je me le demande parfois. Les maths se sont construites en même temps que les sciences pour l'ingénieur jusqu'en 1900 pour faire grossier. Depuis, c'est plus flou de savoir qui avance le premier les billes (par exemple, la notion de distribution était utilisé en SPI avant que Swartz ne formalise tout cela sous cette appellation).
Aujourd'hui, je ne suis pas sur que ce soit toujours des matheux qui portent les nouveaux langages. En france, l'informatique est rattaché aux maths appliquées donc le lien est fort et la france est forte en math ! Je ne sais pas si aux USA le lien est aussi fort, surtout que la bas il n'y a pas cette distinction math appli - math pure.
Donc, il y a l'effet INRIA en france donc on le voit sur les langages réalisés plus particulièrement en france.
Mais si je prends perl6 par exemple, je suis loin d'être aussi sur de ton affirmation. Que les concepteurs essayent de faire le plus logique possible, je veux bien le croire (normal) mais j'ai vraiment l'impression que de plus en plus de langage vont se faire sans que cela soit un groupe de matheux qui en soit à l'origine.
[^]Re: sonntag
> En france, l'informatique est rattaché aux maths appliquées.
Alors pourquoi y a-t-il des sections différentes au CNU pour les maths appliquées et l'informatique.
Comment expliques-tu qu'après ma thèse, j'ai été qualifié en 25 (mathématiques) et en 27 (informatique) mais pas en 26 (maths appliquées) ?
Pour ceux qui lisent encore ceci mais qui ne comprennent rien à ce que je raconte, je recommence en plus verbeux. Après une thèse, pour pouvoir se présenter à un concours pour être enseignant chercheur, il faut envoyer un dossier au CNU qui dit si on a le droit. Le CNU est divisé en section pour éviter qu'un historien ne se retrouve avec un dossier de chimiste. Dans mon cas, des matheux ont accepté de me qualifier en 25 (resp. 27) et ont donc reconnu que ce que je faisais, c'était suffisamment des maths (resp. de l'informatique) pour eux mais pas en 26. Je ne fais donc pas de maths appliquées.
[^]Re: sonntag
Je suis d'accord avec toi. J'ai un peu trop globalisé ;-) En gros, je voulais dire que l'informatique en france est globalement dans la sphère des maths (et je dirais globalement plutôt du coté math appli) alors que petit à petit, il va se passer la même chose que dans les autres discipline du SPI et le génie logiciel aura (ou a déjà) avoir sa place propre comme le génie électrique.
De ce que je vois, l'informatique à la fac ou dans les écoles d'ingenieurs est souvent proche soit des UFR de math, soit des écoles de math.
[^]Re: sonntag
Le truc de l'informatique c'est que c'est à la frontière de pleins de choses:
L'info théorique pure, c'est des modèles mathématiques de la calculabilité, des machines, des programmes. C'est à la frontière des maths, de la logique, ...
L'informatique sert à des humains, qui bossent potentiellement dans n'importe quelle discipline. Donc l'info s'applique, peut fournir des outils pour n'importe quelle discipline.
Pour que ces outils soient utilisables par le plus grand nombre, on doit faire des interface intuitives, utilisables, efficaces. On fait de l'ergonomie.
L'informatique peut servir à faire tourner un robot ou une chaine de production : on fait de la robotique, de l'automatique, voire de l'IA.
L'informatique se sert de morceaux de siliciums et de puce, on utilise de l'électronique, qui elle est faite POUR exécuter des programmes (CPU), mais l'informatique peut s'intéresser à d'autres modes de calculs.
L'informatique permet en général de résoudre des problèmes, on fait de l'algorithmique, qui utilise parfois des maths pures, des propriétés mathématiques pures complexes pour certains problème, on fait de l'algorithmique. Les problèmes qu'on attaque sont soit des problèmes assez théoriques, soit des problèmes très pratiques.
On fait aussi du traitement de données au sens large, là tout dépend du domaine d'application, avec des algorithmes, des interfaces pour présenter les données, des analyses de données pour les présenter à l'utilisateur, en utilisant des outils statistiques, des algorithmes, ...
Les utilisateurs, enfin, certains, croient que l'informatique se résument à ce qu'ils voient sur leur écran. C'est l'arbre qui cache la forêt.
En conclusion, l'informatique, au sens large, c'est transversal, c'est à l'interface de pleins de domaine. Science des ordinateurs, du traitement de l'information, des calculs automatiques, de la communication avec des machines, ...
Et encore j'ai du oublier des trucs.
[^]Re: sonntag
Là, j'imagine que tu ne sais pas vraiment ce qu'est la théorie de la complexité pour dire ça. Idem pour les preuves etc.
Que bon nombre de programmeur fassent des programmes ne nécessitant que des notions ultra basiques d'informatique théorique ne signifie pas que ces notions théoriques se limites à ces connaissances basiques.
[^]Re: sonntag
Si, je sais vraiment ce qu'est la théorie de la complexité. Je sais que certaines parties de cette theorie volent tres haut, mais que pour les considerations pratiques, il suffit d'avoir _vraiment_ compris ce que sont un logarithme, une exponentielle, une limite. Le reste vient tout seul.
Donc c'est bien un niveau terminale. Un excellent eleve de terminale pourrait obtenir facilement une comprehension de la theorie de la complexite suffisante pour n'importe quel besoin pratique de l'informatique.
Si tu peux me decrire un contre exemple, ca m'interesse.
[^]Re: sonntag
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.
[^]Re: sonntag
Ton exemple fait appel a des notions de maths de terminale. Rien de plus. OK, la demo est peut-etre penible a ecrire, mais ca ne change pas l'aspect elementaire des maths qu'il y a derriere.
[^]Re: sonntag
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.
[^]Re: sonntag
Ou alors j'ai fait une terminale avant toi.
Plus serieusement je reconnais mon erreur. Mais il n'en reste pas moins que l'idee derriere cette distinction en general/pire des cas et n log n / n^2 est simple a comprendre pour ces algos de tri. Meme si effectivement la moyenne peut etre difficile a calculer de facon rigoureuse.
Je pense que si les bons programmeurs "sentent" ces distinctions, peu d'entre eux ecrivent des series generatrices sur des coins de table.
[^]Re: sonntag
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é.
[^]Re: sonntag
un trie à bulle est bon si les élements ne sont pas trop en désordre.
[^]Re: sonntag
Je ne voudrais pas pinailler, surtout que j'ai admis avoir eu tort, mais c'est justement sur des considerations pratiques que tu choisis QuickSort, alors que la theorie t'indiquerait plutot de prendre MergeSort systematiquement, qui a une complexite egale en moyenne a QuickSort, et meilleure dans le pire des cas.
Bref, de toute facon, il y a un malentendu dans cette conversation. Je suis d'accord, l'info a besoin d'outils mathematiques, generalement triviaux mais pas toujours (tiens je te file un bon contre-exemple: les SVM). Ce n'est pas ca que je remet en cause. Mais bon, on a eu une discussion la dessus un peu plus haut, je n'en rajoute pas.
[^]Re: sonntag
SVM ? Sciences et Vie Micro ? oO
Windows has no users. It has hostages.
[^]Re: sonntag
je suppose, vu le contexte, que c'est 'Support Vector Machine':
http://en.wikipedia.org/wiki/Support_vector_machine
[^]Re: sonntag
Oui, desole pour l'acronyme esoterique. D'habitude c'est moi qui rale contre ca.
[^]Re: sonntag
Les gens utilisent quicksort car c'est un tri en place avec une faible constante.
Heapsort est en place mais fait de gros déplacement dans la mémoire ce qui cause des problèmes dès qu'on veut trier de gros volumes de données.
Merge-sort n'est, par défault, pas en place. Il utilise deux fois plus de mémoire et ça pose des problèmes. On peut en faire un tri en place mais c'est beaucoup plus compliqué.
Dans la vraie vie, quicksort est effectivement plus rapide.
Dans un autre genre. L'algo de multiplication de polynômes qui a la meilleur complexité passe pas de la FFT et tourne en n.log(n). En pratique, à part pour des polynômes vraiment grands (plusieurs milliers de coefs), les gens utilisent l'algorithme de Kartsuba (en n^{3/2}) et des généralisations.
[^]Re: sonntag
Disons qu'il me semble là qu'on parle de la complexité d'un algorithme donné et pas de la complexité du problème. Alors effectivement, si on ne s'intéresse qu'a la complexité de l'algo, ça va.
Si le programmeur se rend compte que la complexité de son algo est exponentielle il est tout de même très intéressant de savoir dans quelle classe se trouve le problème. S'il est dans P, alors faudra sans doute se creuser la tête pour trouver un algo polynomial. S'il est NP-complet soit on se dit "tant pis" soit faut se tourner vers une bonne approximation. Classer les problèmes ne me parait pas si évident. Bon, on ne lui demandera peut être pas d'en faire la preuve, mais même intuitivement ça nécessite bien souvent une bonne expérience des "réductions" (si on ne veut pas être à côté de la plaque, l'intuition est parfois trompeuse).
Tous les programmeurs ne sont pas confrontés à ces problème et bon nombre d'informaticiens n'ont qu'une connaissance assez vague de ces notions (moi aussi). Je pense cependant que dans certains besoins pratique de l'informatique cela peut arriver. Et quand ça arrive, qu'est-ce qu'on fait ?
[^]Re: sonntag
Le fait que les professionnels de l'informatique ne connaissent rien au math, et plus généralement à la théorie est pour moi un gros problème.
Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
[^]Re: sonntag
Il me semble que tu sous-estimes tres largement le rôle des maths (et de l'informatique théorique) dans la programmation.
Sérieusement, des affirmations comme « la quasi totalite des problemes qui se posent en programmation se resolvent sans faire de maths » ne veulent pas dire grand-chose: ça ne sert à rien de considérer la "totalité" des problèmes en programmation car personne n'est confronté à tous ces problèmes en même temps. Ça dépend énormément du domaine. Quand on bosse dans le domaine des compilateurs, outils d'analyse statique, moteurs de preuve, etc. c'est très utile.
« le decalage enorme entre les preoccupations des informaticiens (ceux qui font des programmes qui servent) et les preoccupations que les theoriciens imaginent chez les informaticiens. »
C'est rigolo cette tournure: pour toi les théoriciens ne sont pas des informaticiens. Moi j'aurai appelé "informaticiens" les théoriciens et "programmeurs" ceux qui font des programmes ...
[^]Re: sonntag
Sincèrement, je suis d'accord avec le fait que l'utilisation de mathématique est relativement marginale dans l'informatique. En fait, tout dépend du milieu dans lequel tu te retrouves. Je travaille par exemple en finance de marché. A part les pricers (calculateurs de prix de produits), les calculateurs de risques (VAR, CVAR, etc...), aucune mathématique à l'horison.
Comme d'habitude, notre environnement influence notre vision globale de l'informatique, et donc personne n'aura le dernier mot.
[^]Re: sonntag
Mouais... Et les requètes sur des bases de données, c'est pas de la théorie des ensembles ? Les conditions dans tes if, c'est pas de la logique ? et la théorie des ensemble et la logique, c'est pas des mathématiques ?
Souvent, ce qui est considéré comme "informatique" n'est finalement que des mathématiques appliqués, notamment logique, théorie des ensembles et arithmétique.
[^]Re: sonntag
Et les additions que l'épicier fait c'est pas des maths ?
[^]Re: sonntag
Bof, il n'y a pas besoin de connaître la théorie des ensembles pour faire une requête sur une base de donnée, il n'y a pas non besoin de connaître la théorie des ensemble pour faire un logiciel de base de donnée.
Donc non une base de donnée ce n'est pas lié à la théorie des ensembles, après tu peux l'analyser en termes de théorie des ensemble si ça t'amuse mais bof.
Par ton raisonnement, je peux dire que la cuisine c'est des math..
[^]Re: sonntag
et l'algèbre relationnelle c'est pas des maths peut être ?
[^]Re: sonntag
Et les espaces de Riemann, c'est pas des maths peut-être ? C'est pas pour cela qu'Einstein était un mathématicien !
Je trouve que pas mal de post ici confondent math et génie logiciel.
[^]Re: sonntag
A mon avis, la différence est là : si tu travailles sur les espaces de Riemann en soit, tu es mathématicien, sinon tu l'utilises juste comme outil et ça ne fait pas de toi un mathématicien.
Il y a des informaticiens qui travaillent sur les graphes, la complexité etc. en soit. Il y en a d'autres qui ne font que l'appliquer. Parmis les informaticiens, il y en a des matheux et y'a les autres (sûrement pareil en physique d'ailleurs).
Alors oui, selon moi quand on ne fait qu'appliquer des outils mathématiques (aussi complexe soit-ils), on ne fait pas des maths.
Ayant posé cela, revenons au fil de la discussion.
Il y avait deux débats mélangés : y'a-t-il des informaticiens qui font des maths ? et a-t-on besoin de connaître les maths pour faire de l'informatique ?
A la première question, je réponds : "oui, mais pas tous"
A la seconde : "même si on ne fait qu'appliquer des outils, il est souvent nécessaire de bien les comprendre, donc faut quand même comprendre un minimum les maths"
Pour finir, je concluerais en disant que je prends plaisir à troller là-dessus, et que je sais très bien que certains boulot dans l'informatique ne nécessite quasiment aucune connaissance de maths. Personnellement, je ne suis ni un grand théoricien, ni un grand technicien :-) (les deux m'intéressent pourtant)
[^]Re: sonntag
> A la seconde : "même si on ne fait qu'appliquer des outils, il est
> souvent nécessaire de bien les comprendre, donc faut quand même
> comprendre un minimum les maths"
Je suis Administrateur Système et Réseau. je peux t'assurer que la plupart des copains qui le sont aussi ne sont pas des matheux pour un sous.
Il n'y a pas besoin d'être bon en math pour régler un serveur samba ou postfix. Pour faire ces choses là, il faut savoir faire du génie logiciel donc connaitre les limites de ceux-ci et les conséquences de telle ou telle action.
[^]Re: sonntag
C'est un peu ce que je voulais dire par "si on ne fait qu'appliquer des outils" [mathématiques]. Dans ce cas, tu n'appliques pas d'outils mathématiques (enfin il me semble, hein :-)). J'ai même rajouté à la fin de mon commentaire : "je sais très bien que certains boulot dans l'informatique ne nécessite quasiment aucune connaissance de maths."
Et enfin, j'ai quand même dit que je "trollais".
[^]Re: sonntag
Pas besoin de math pour regler un serveur postfix ou samba, pas besoin de genie logiciel non plus. On s'est pas mal ecarte debat initial, mais on parlait des programmeurs, quand meme, sinon le debat n'a plus aucun sens.
[^]Re: sonntag
Mais je suis aussi programmeur lorsque j'ai le temps. Et en admin système, tu programmes, certes du bash la plupart du temps...
La ou je veux en venir est qu'on n'est pas tous des dieux de l'informatique et je vois bien que mes programmes sont à cent lieux des optimisations que font pas mal de gens sur dlfp. Mais enfin, je code et je n'y connais rien au concept mathématique qui sont derrière l'informatique. Cela ne m'a pas empêché de faire à une époque un tout petit peu d'assembleur.
Je comprends que lorsqu'on fait un nouveau langage ou une nouvelle structure de données btree... On s'amuse à essayer de démontrer par A + B que ce que l'on fait est bien mais cela concerne combien d'informaticien en pratique. Très peu.
En plus, je me souviens que certain algo de convergence en calcul numérique converge super bien alors que mathématiquement, on n'arrive pas à le démontrer et que l'inverse arrive aussi (un super algo qui converge d'après le théorème mais qui ne marche pas en pratique). Il faut voir que la machine fait pas mal d'erreur et ne suis donc pas toujours les maths elle aussi.
[^]Re: sonntag
Oui, c'est juste l'argument que je remettais en cause.
En fait, je pense que la vrai question est de savoir dans quelle mesure les gens qui font avancer l'informatique, qui concoivent des trucs nouveaux, utilisent des concepts avances de mathematique (pas ce qu'on apprend en fac d'info). Mon point de vue c'est que globalement non, meme si il y a des tas d'exceptions. C'est tres discutable, je le reconnais.
Mais qu'il y ai des millions de gens qui soient informaticiens, au sens large, et qui n'y connaissent rien en math, c'est evident, personne ne le conteste.
[^]Re: sonntag
Je ne sais pas mais globalement, j'ai l'impression que si les premiers jets ont été fait par des matheux, les versions suivantes ont été faites par des experts de génie logiciel. Par exemple, pour Fortran, qui est dans les organismes de normalisation ?
Si je prends l'exemple de Sather, l'équipe qui l'a conçu en partant d'Effeil à divergé sur un point de conception. Dans Effeil, Meyer essaye par tous les moyens d'unifier tous les concepts autour de sa notion d'objet alors que Sather est construit pour orthogonaliser un maximum les concepts afin que l'implémentation et la syntaxe de l'un n'intervienne que le moins possible sur l'autre. Je trouve que cette approche est du grand art de génie logiciel.
Dernier exemple pris exprès à contre courant de << l'approche francaise >>, Perl est un grand langage (pour moi) qui est piloté par un linguiste. En cela, Perl ouvre peut être la voie. Ce n'est peut être pas le premier dans ce cas là mais cela doit être l'un des plus utilisé.
Sur ce dernier langage, je ne suis pas d'accord avec Benoit et la manière dont il a critiqué les autres langages (même s'il ne cite pas Perl). Perl6 n'a pas la même ambition que Lisaac mais lorsque l'on connait la qualité des personnes qui travaillent dessus depuis pas mal d'année, la somme des concepts que ce langage va permettre d'utiliser, cela me donne un sentiment de profond respect.
[^]Re: sonntag
Tu as une notion des mathématiques vraiment étendue...
La logique par exemple semble faire partie pour toi de la défintion commune des maths, autant dire que ce n'est pas mon point de vue.
[^]Re: sonntag
Je vais te filer un poly de logique d'une centaine de pages dans laquelle il n'y a pas la moindre petite ligne de code ou même une seule allusion à la programmation et on en reparle après...
[^]Re: sonntag
Attention à la convention de Genève...
[^]Re: sonntag
La logique n'a pas grand rapport avec le code non plus. C'est une discipline en soit, à côté de la discipline des mathématiques. Je ne comprends pas le sens de ta phrase...
[^]Re: sonntag
http://fr.wikipedia.org/wiki/Logique_math%C3%A9matique
La logique, c'est des mathématiques, d'après cet article, en tout cas...
[^]Re: sonntag
et d'après celui là : http://fr.wikipedia.org/wiki/Logique non.
La logique (du grec λόγος (logos), ce qui veut dire, entre autres, raison ou discours) est dans une première approche l'étude des règles formelles que doit respecter toute déduction correcte.
Elle est depuis l'antiquité l'une des grandes disciplines de la philosophie, avec l'éthique et la métaphysique. En outre, on a assisté durant le XXe siècle au développement fulgurant d'une approche mathématique et informatique de la logique. Elle trouve de nos jours de nombreuses applications en ingénierie, en linguistique, en psychologie cognitive, en philosophie analytique ou en communication.
[^]Re: sonntag
C'est pas parce que que la théorie est cohérente mathématiquement que l'on fait des maths. Les sciences pour l'ingénieur, c'est quoi ?
Exemple, je fais du calcul de structure par élément finis, c'est des maths ? Et bien non. Lorsque je démontre que les éléments finis converge dans des cas précis, oui, là, je fais des maths. Mais pas lors d'une utilisation sur des cas réels.
[^]Re: sonntag
Le problème avec tout ça, c'est qu'un informaticien, ça peut être l'administrateur système, l'analyste programmeur, ou le chercheur en théorie des graphes.
Pour prendre une analogie mécanique, cela revient au même que dire qu'un mécanicien ou qu'un ingénieur de chez peugeot sont tous les deux de mécanos.
Oui, l'utilisation des mathématiques est marginale chez ton concessionnaire automobile mais non l'utilisation des mathématiques n'est pas marginale dans les bureaux d'études automobile.
La grande majorité des informaticiens sont des mécaniciens de l'informatique. Oui, ils n'utilisent pas beaucoup de maths. C'est aussi compatible avec le fait que les maths prennent une part importante en informatique.
Bref.
[^]Re: sonntag
J'ai l'impression que c'est surtout un problème français.
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
"Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
[^]Re: sonntag
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
Ca t'apprendra à penser que les ingénieurs sont des gros nuls à peine capable (sic) d'écrire un intranet en Java :-)
[^]Re: sonntag
et au milieu il y a les ingés qui veulent devenir chercheurs, qui savent à peu près à quoi s'en tenir des 2 cotés :-)
Cela dit, j'ai rencontré des ingés qui pensent effectivement que la recherche ca sert à rien...mais par contre coté chercheur, bien que n'en ayant pas rencontrés beaucoup (la plupart étant mes profs), je n'ai pas vu le coté "les ingés c'est des nuls". Cela dit je ne doute pas que certains pensent comme cela. Mais bon, faudrait pas non plus prendre l'arbre pour la foret quoi...enfin, j'espere que les gens visés ne sont bien que l'arbre qui planque la foret, sinon c'est grave ^^
[^]Re: sonntag
Et moi j'en ai marre de ceux qui croient que programmer c'est juste pisser du code. Si tu programmer intelligemment, tu as besoin de notions théoriques.
Premièrement tout programmeurs devrait penser à la complexité algorithmique de ses programmes, oui c'est des maths mais si ton programme est exponentiel alors qu'ils pourrait être linéaire ca fait une différnece.
Deuxièmement tout programmeur devait aussi de poser des questions sur les bases théoriques des langages qu'il utilise. Les langages reposent sur des notions qui peuvent paraître simple au premier abord mais sont souvent complexes. Comprendre la logique de son langage c'est produite du code mieux pensé, mieux adapté, éviter les pièges, etc ...
Troisièmement, la tendance actuelle est clairment d'avoir des langages plus formels: plus de typage, un typage plus fort et plus souple, des notions théoriques puissantes, ... Tout ceci pour donner des langages puis sûrs et plus souples. Sans parler des langages où on peut donner la spécifications des programmes, ceux ou on prouve les programmes, etc ...
Ok le C c'est simple mais le programmeur à tout à gérer à la main ce qui introduit forcément plus de bugs (segfault, bufferoverflow,etc...), la réutilisabilité du code est faible, etc ... Quand à la rapidité du C, qui dit que ce que le programmeur va faire à la main n'est pas mieux fait par un système automatique d'un langage évolué ? SI tous les programmeurs utilisaient toujours les meilleurs algorithmes connus ca se saurait.
Un langage est un outil et plus un outil est puissant plus il demande d'apprentissage pour le manier mais plus le résultat en vaut le coup.
D'ailleurs serait il possible d'avoir un comparatif sur les gains qu'apporte Lissac sur le développement de Isaac OS en comparaison avec les problèmes qu'apportent le C sur Linux ou *BSD par exemple ? Par exemple quelque chose que sur Issac est fait naturellement alors que chez les autres c'est compliqué a faire.
Pour en remetrre une couche sur la programmation et les maths, j'ai découvert récemment Concoqtion ( http://www.metaocaml.org/concoqtion/ ), le niveau mathématique dedans est vraiment élevé (j'espère qu'un jour j'arriverai à comprendre ....) en revanche sa puissance à l'air tout simplement ahurissante !
[^]Re: sonntag
>>«je veux développer des programmes, pas faire des math.»
>Et moi j'en ai marre de ceux qui croient que programmer c'est juste pisser du code. Si tu programmer intelligemment, tu as besoin de notions théoriques.
Très peu.. La principale qualité d'un bon développeur c'est d'être capable de comprendre le besoin et ensuite de sortir du code maintenable pour y répondre, point.
>Premièrement tout programmeurs devrait penser à la complexité algorithmique de ses programmes
Un niveau de math *très différent* de celui réclamé pour essayer de comprendre Haskell, ce qui était le sujet de cette phrase de mon post.
>Deuxièmement tout programmeur devait aussi de poser des questions sur les bases théoriques des langages qu'il utilise.
Ah? Les langages que j'utilise le plus sont le C, le shell (et le Perl quand je ne peux pas l'éviter) et je regarde attentivement D pour le futur, qu'est ce que tu entends par 'base théorique' dans leur cas?
>Troisièmement, la tendance actuelle est clairment d'avoir des langages plus formels:: plus de typage, un typage plus fort et plus souple,
La tendance en recherche oui. Ailleurs c'est loin d'être évident: Ruby, D les langages qui montent, sont très différent d'Haskell, Coq et consorts..
Je ne vois pas pourquoi tu montes sur tes grand chevaux dans ton post: personne ne t'empeche de t'éclater avec de la preuve de programme, chacun son truc, je préfère écrire des programmes qu'essayer de comprendre des math comme celle utilisée pour Haskell ou Coq.
[^]Re: sonntag
Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ? J'ai un peu programmé avec ce langage et ça ressemblait un peu à un Java sans machine virtuelle et plus proche du C.
Lisaac, tu peux directement inclure du code C (via les backquotes ``), et tu maîtrise vraiment le résultat en C obtenu. Et si ton compilateur C permet d'écrire de l'assembleur, tu peux le faire directement depuis Lisaac
La Roue du Temps
[^]Re: sonntag
Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?
Si.
Le D est vraiment adapté à la programmation système puisque tu peux aussi choisir de ne pas utiliser le ramasse-miette.
Sinon, le D a aussi un gros avantage: la compilation est _très_ rapide (c'est presque du pascal).
[^]Re: sonntag
>Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?
Si: http://www.digitalmars.com/d/iasm.html
>Lisaac, tu peux directement inclure du code C
D s'interface assez bien aussi avec le C, un peu comme le C++ appelle du C et la syntaxe de D est assez proche de celle du C..
Pour le détail:
http://www.digitalmars.com/d/interfaceToC.html
[^]license et divers points techniques
Ne serait-il pas mieux d'ajouter une exception à la GPLv3 de la bibliothèque (ou changer pour la LGPLv3) afin de permettre le développement de logiciels en licence GPLv2, QPL, propriétaire, etc ?
Concernant les fonctionnalités:
* je n'aime vraiment pas du tout la syntaxe smalltalk, n'est-il pas possible d'avoir un préprocesseur intégré (à la camlp5 ou ocaml+twt) ? Avoir quelquechose de ressemblant à Python ou à D (ou même caml) serait un grand plus.
* Concurrence : les performances sont-elles les mêmes en architecture multi-coeur, multi-processeur ?
* Interaction avec les bibliothèques existantes : comment lier le code à du c ? Est-t-il possible d'écrire facilement des librairies partagées ?
[^]Re: license et divers points techniques
1) Je pense que cela n'est qu'une question d'habitude.
2) y'a pas encore de concurrence propre en Lisaac, c'est prévu pour la suite. pthread marche mais c'est pas top.
3) C'est très facile de réutiliser du C. Par contre, il n'y a pas encore de notion de lib partagé.
[^]Re: license et divers points techniques
Pour les fonctionnalités :
* la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
- très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
- conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
- La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
(cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
- tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
* concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
* interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.
[^]Re: sonntag
Depuis le temps que je voyais des news sur Lisaac, je n'avais pas eu le temps d'éssayer. Et bien c'est chose faite. Enfin c'est en cours.
Je ne vais pas parler du langage car je ne le connais pas encore suffisament, et je n'ai pas eu le temps de m'habituer à la syntaxe, mais je vais parler de l'environement.
Je trouve que l'environnement de Lisaac est beaucoup trop intrusif. Je ne supporte pas qu'un programme pense savoir mieux que moi ce que je veux.
Donc pour moi, il y a quelques choses essentielles à modifier dans le package fournit :
- ne pas allez modifier le fichier .bashrc de l'utilisateur, ou en tout cas pas sans lui demander avant si il le desire.
- dans le fichier d'indentation de vim, ne pas forcer l'utilisateur à utiliser les même tabulation que l'auteur.
Peut-être que l'auteur adore les tabulations qui on une largeur de 2 espace et qui sont automatiquement converties en espace, mais ce n'est pas le cas de tout le monde.
Et lors de l'instalation de la syntaxe pour vim, indiquer clairement que l'instalation du fichier de configuration par default est le fichier .vimrc et non pas une config du fichier de syntaxe. Il est douloureux de voir que l'installation d'un script de coloration syntaxique a virer toute la configuration de votre éditeur...
Donc j'ai installé Lisaac et je dois dire que l'installation m'a fortement refroidit. Mais je ne me suis pas découragé, et je vais quand même faire quelques petites remarques.
La syntaxe est particulière et pour le moment je ne la trouve pas très lisible, mais il va falloir voir à l'usage. En général il me faut un temps d'adaptation quand j'éssaye un nouveau langage. Par contre je n'aime pas que les langages qui forcent l'utilisation des majuscules et minuscules. Je trouve moche de devoir ecrire les noms des prototypes en majuscule, mais c'est une question de goûts. Y a-t'il une raison particulière qui force ceci ?
Ensuite un point de détails, mais la doc ne semble pas à jours car elle parle de category dans la section Header, mais le compilateur le signale comme deprecated.
Mais je dois avouer que si je n'ai pas accrocher au niveau de la syntaxe, le reste du langage me plait bien pour l'instant. Il est relativement puissant, et simple à apprendre si l'on connait déjà un peu les concept qui sont derrière.
Pour faire quelques tests j'ai recoder en Lisaac quelques un des codes de calculs scientifique que j'avais code en C. Ça ce fait très bien et naturellement. Le code Lisaac me semble même dans quelques cas plus simple à comprendre.
Et question perf, mon code en C est super optimisé, alors que le code Lisaac est loin de l'être puisque je ne connait encore aucune des subtilitées du langage, ni les manière de rendre le code rapide et facilement optimisable. Et pourtant les perfs sont plustot bonnes. J'obtiens en moyenne du code 40% plus lent, ce qui me laisse penser que l'on peut obtenir des perfs equivalentes quand on maîtrise le langage.
Donc un bilan plustot encourageant. Mes principaux grief étant dirigés vers l'instalation et celle-ci ne se faisant qu'une seule fois...
Pour l'instant il reste clair pour moi que mes codes critiques resterons en C, mais je vais surement ecrire quelques programmes non critique en Lisaac pour l'étudier plus en profondeur et voir si l'investissement en temps est valable.
[^]Re: sonntag
Merci pour tes remarques concernant l'install, on va en prendre bonne note.
Je me demandais : As-tu compilé le c produit par lisaac, avec les mêmes optimisation que ton source initial en C ?
genre :
-O3 -fomit-frame-pointer -ftree-vectorize -msse -march=pentium4 -mtune=pentium4
Ensuite, il suffit d'optimiser l'algorithme pour avoir des performances, la gestion mémoire n'est pas à ta charge. Par contre utiliser des variables temporelles, des déroulement de boucles peuvent aider.
Mais nicO saurait mieux répondre que moi sur le sujet :)
[^]Re: sonntag
Pour les premiers essais j'utilisait les binnaires fournits directement par Lisaac, mais justement, ne sachant pas quelles options il passait à gcc je me suis mits à les compiler avec exactement les mêmes options que pour mon code. Les comparaisons sont faites avec ces derniers binnaires.
Pour ce qui est des algorithmes, ils sont déjà optimisés à mort, mais même avec les meilleurs algos, si tu les implémente comme un pieds tu obtiens un programme qui se trainne comme un bousin. Et même si tu fais gaffe de bien coder ton algo il peut toujours y avoir certains coûts cachés dans certaines constructions du langage.
Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
Le programme en C est beaucoup plus complèxe à ce niveau car toute la mémoire est gérée manuellement et le tout optimisé pour tenir en mémoire sur cette machine. Mais cela n'explique pas toute la différence de perfs.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
[^]Re: sonntag
"-funroll-loop" est inclus dans -O3 souvent -funroll-all-loops fait encore mieux. Sinon, je pense que Ontologia pensait faciliter la vie du compilo avec les variables en question.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
Forcément en C, c'est toi qui a fait les optims pas le compilo :)
[^]Re: sonntag
Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
C'est prévu.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Tu parles du cache code ou du cache données ?
En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
Dans le C généré par lisaac, tu as souvent :
while( cond) {
((int *)struct1->struct2->struct3)[index ] = ...
...
}
Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
Benoi