C'est bien, ça s'améliore. Dommage que mono soit encore loin derrière :-)
Loin derrière ? Mono compile presque toutes les nouveautés, Mono devrait supporter intégralement C# 3 au moment de la sortie officielle de Visual Studio 2008 (le produit commercial rattaché au lancement officiel de C# 3) pour janvier, ils n'auront jamais été aussi synchro.
On peut compiler du caml ou du F# en .Net. Implémentation != language
Bien sûr, mais les exemples de langages que tu proposes sont des langages de "haut niveau" qui respect les paradigmes objets de base, ce qui est le point commun requis par la VM de .NET.
Et il y a parfois des corrélations fortes : le langage peut supposer la présence d'un garbage collector avec un fonctionnement bien précis, le langage peut supposer la présence de certains types de base, le langage peut supposer la présence d'un framework de sécurité sous-jacent, de possibilité d'introspection, etc.
Mais pour ce qui est de la consommation de ressources et la fluidité .Net a encore du chemin avant de rattraper le vieux Delphi.
.NET ajoute une couche d'abstraction (VM) et des services associés qui ont effectivement un coût. Mais Delphi ne proposait pas tous ces services, c'est donc difficilement comparable.
mais definir la semantique de chaque bloc tu ne peux pas.
Mouaich, ca peut très bien être explicite dans le nom de la méthode, dans la doc (et donc l'auto-complétion) :
mon_arbre.foreach_while_do_finally(while, do, finally);
Après effectivement c'est moins puissant que les block notamment dans les exemples que tu donnes.
Tu peux toujours contourner le problème en prenant en paramètre une interface imposant de passer par exemple un objet contenant 3 "fonctions", chacune correspondant à un bloc.
Ca serait un peu plus lourd syntaxiquement, mais tu gardes les mêmes possibilités.
Après je te dirais franchement que je n'aime pas du tout les exemples sur lesquels on travail, j'ai peur que les développeur face trop mumuse avec pour avoir leur petites libs de boucles à eux, qu'eux seuls comprennent (avec tous les bugs qui vont avec).
Un peu comme en C++ ou tu peux faire tout et n'importe quoi avec les templates et les macros (certains se sont amusés à reproduire la syntaxe de Lisp) : ca peut devenir imbitable pour un intérêt très limité.
d'abord F-Spot recopie ailleurs, dans son cache à lui, les photos qu'on lui apporte
Ou pas. Il te propose les 2. C'est vrai que si on coche pas la case correspondante, par défaut il recopie. Parcqu'on peut aussi lui brancher un appareil photo par exemple (auquel cas il n'y a pas besoin de lui dire quoi faire).
Mais tu as raisons, F-Spot propose par défaut une abstraction du support de tes photos. L'idée est de proposer plutôt une vue par tag et une vue temporelle plutôt qu'un arbre de dossier qui est beaucoup plus contraignant.
Il faudrait effectivement ajouter à F-Spot une fonction de "surveillance" de répertoire pour qu'il détecte les renommages et les ajout/suppression. vu l'organisation assez spéciale des dossiers F-Spot.
2007/09/26/toto.jpg
Pas si compliqué :)
C'est un tout petit sous-ensemble que tu as pris là.
Java ou .NET inclu beaucoup plus que ca, ce que tu me décris là c'est Java il y a 5 ou 10 ans.
Moi je veux un serveur d'application, je veux un framework web, je veux un framework web-services, je veux un framework d'IHM vectorisé, je veux un framework de workflow, je veux un framework 3D, je veux un framework audio/video, je veux un framework pour l'embarqué, je veux un framework pour client web, je veux des API de sécurité, je veux des API de gestion de plugins, je veux des API pour les schema W3C, pour XSLT, un framework pour composants transactionnels, des API de cryptographie, j'en oublie sûrement plein.
Et je veux surtout que le tout soit unifié, pas un assemblage de trucs disparate qui vienne de différentes sources, chacune avec ses concepts pas toujours compatibles entre eux me forcant à m'adapter en permanence sans profiter de mon acquis.
Enfin tout ce qui fait la force de Java ou .NET quoi.
Ben justement si:
Toutafé, y'a pleins de choses bien, mais les inconvénients sont trop bloquant pour qu'ils soient utiles. C'est comme Lisaac aujourd'hui : pas de modularité binaire == utilisation anecdotique (pour moi).
le language ne permet pas d'encapsuler les requêtes sql correctement,
C# 3 :
var res = from s in auteurs
where s.Length == 5
orderby s
select s.ToUpper();
Quand tu parles de framework, tu t'éloignes du language pour en venir aux bibliothèques.
Pas totalement, quand je parle framework je parle aussi machine virtuelle (bytecode, JIT, GC, securité, etc.) : le langage expose plus ou moins de possibilité en fonction de la machine "cible". C'est fortement lié.
Enfin, J2EE, .Net réinventent la roue (Squeak, Delphi), en moins bien et surtout en beaucoup plus lent et volumineux.
Il est où le serveur d'application en Squeak ou Delphi ? Elle
C'est le même type qui a fait C# et qui a fait Delphi dans le passé, je vois mal comment il aurait pu faire "moins bien". D'ailleur .NET est tellement moins bien que Delphi que Delphi cible maintenant .NET comme plateforme "cible" (entre autre), ce qui démontre au passage tout l'intérêt d'avoir une VM intermédiaire standardisée.
sauf que ca ca s'applique aussi à la transition imperatif/Objet
Pas convaincu. Il n'y a pas pour moi d'opposition entre impératif et objet. L'objet est plus une façon de programmer, de représenter les données : tu peux très bien appliquer le concept en C. Cette méthode (objet) est tellement naturelle (chercher à encapsuler, factoriser) qu'elle conduit à introduire dans la syntaxe des langages impératifs des constructions dédiées. Mais c'est une évolution, pas un "saut".
Tu peux toujours faire de l'impératif en Java comme tu peux faire de l'objet en C. C'est pas forcement les bons outil pour la bonne utilisation, mais c'est tout à fait possible.
Tout le problème c'est que pour voir les avantages que ca apporte il faut accepter d'y consacrer un peu de temps...
Certes, mais pour cela faut voir la transition : pourrais-je toujours programmer comme avant ? Pourrais-je utiliser ma syntaxe favorite (argument .NET) ? Pourrai-je faire la même chose qu'avant ? (framework complet) Existe-t-il un IDE où je puisse être productif ? Est-ce compatible avec l'existant ? Existe-t-il un support (forum, doc, etc.) ?
Beaucoup trop de langages "universitaires" se focalise sur le langage en lui même. J'ai envie de dire que le langage en soit est presque accessoire si on oublie le reste.
donc si je resume, on avait une syntaxe du genre :
Oué mais nan, j'étais parti sur un foreach_while qui supposait qu'on avait 2 blocks d'instructions en paramètres. Tu es revenus à un foreach "classique", d'où mes nouveaux exemples.
ou alors y a de fines nuances sur le comportement...
Y'a juste des évolutions : C# 1 : pointeurs de méthodes, C# 2 : méthodes anonymes (plus besoin de déclarer une méthode séparée que l'on référence), C# 3 : expression lambda.
Alors oui, dans C# 3 tu peux toujours faire comme en C# 2 ou C# 1.
qu'on veut 3 blocs en parametres, etc, on fait comment ?
Bah pareil ! C'est quoi le problème ? Mon premier exemple prenait 2 blocs, chacun était dans mon exemple une lambda expression séparé par une virgule (dur dur). Je te laisse deviner comment ajouter un 3ème paramètre ;)
le i, tu le declares avant ?
Bah nan, c'est une lambda expression, le i est justement ici sa déclaration. Son type est défini par inférence à partir du type de la méthode Foreach.
C'est justement parcque tu ne comprends pas cette écritureque j'avais commencé par la syntaxe C# 2 ;) Mais certains trouvent plus joli, plus concis et plus propre la 3ème.
Enfin tout ca pour dire que je ne vois absolument pas la différence, au final je peux déclarer une méthode qui prends plusieurs paramètres, chaque paramètre peut être un bloc de code, que tu l'écrives sous la forme d'une fonction anonyme ou sous la forme d'une lambda expression.
On peut lui reprocher sa syntaxe
C'est un gros défaut, c'est vraiment illisible, on passe son temps à compter les parenthèses.
Moi je vois surtout qu'il manque un framework. Un vrai bon gros framework uniformisé et qui reprend la plupart des outils nécessaire pour réaliser une grande variété d'application.
C'est le gros point commun entre Java et C# : c'est le framework.
surtout l'ignorance des programmeurs qui restent dans leur caverne.
Pas convaincu, on est beaucoup à être passé à un moment par le Lisp et autre OCaml. C'est gentil mais sans framework ca sert à rien.
Même dans le langage : des besoins "industriels" comme le versionning des types, l'introspection (plugins, automatisation, etc.), voir même la facilité d'inter-actions dans un IDE, tout ca nécessitent un langage qui a été un minimum pensé dans ce sens.
Lisp c'est joli pour les mathématiciens, mais ca sert pas à grand chose pour un informaticien (qui ne fait pas des algos mathématiques la plupart du temps).
En fait le problème avec le langage Java, c'est que tous ses choix sont des compromis décevants.
Décevant ? Je comprends ta frustration mais moi je vois les choses différement : en réutilisant la syntaxe du C++, elle facilite la vie de millions de développeurs, en limitant volontairement les aspects objets, elle simplifie la compréhension du code pour un développeur "moyen", etc.
Ces langages sont une suite logique d'évolutions, et c'est cet "héritage" du passé qui font qu'ils sont utilisables et utilisés.
A quoi sert un langage si personne ne le comprend ?
A quoi sert un langage si seul les chercheurs sont capables d'en appréhender les concepts (soit de trop haut niveau, soit top différent des concepts existants) ?
Bref, la beauté du langage ne fait toutes les qualités requises pour un langage "ready" pour un large public de développeur.
foreach_while
Bof, en C# 3 je peux faire ca :
maliste.foreach_while(elem => elem.Foo() , elem => elem.truc == 0);
qui applique la Foo à tous les éléments de ma liste tant que la propriété truc vaut 0.
dynamiques limités
Ca évolue, regarde le Dynamic Language Runtime que vient de sortir MS, il s'appui intégralement sur les briques de base existante.
complexité de la grammaire (et donc lenteur de la compilation)
Mouaich. Suffisament rapide pour être compilé en temps réel par les IDE. Je ne suis pas sûr que des langages comme Lisaac qui visent une grande quantité d'optimisations à la compilation améliore la chose. Enfin je ne vois pas en quoi Java & co ont 30 ans de retard là dessus.
pas de curryfication, pas de tail recursion, ..
Et ca fait de Java et C# des langages qui n'auraient jamais dû exister ?
Faut aussi bien voir que ces langages évoluent : généricité, lambda expression, langages de requête, etc.
montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.
Ou sont suffisament générique et d'assez haut niveau pour supporter un vaste éco-système.
Ces frameworks ne pourraient pas exister sans une base technique qui le permet (bytecode pour les tisseurs, introspection pour les tests U, etc.)
Même si beaucoup de tes critiques sont pertinentes, il n'y a pas à l'heure actuelle d'alternative pour leurs segments d'utilisation. Tous les autres langages ont leurs défauts propres qui ne leur permet pas de remplacer Java ou C# pour de nombreuses utilisations.
Alors dire que ces langages ne devraient pas exister, cela suppose qu'on est au moins le bon goût de proposer une alternative. Benoît Sonntag le dit lui même, Lissac n'en ai pas une.
J'ai jamais prétendu que Mono allait révolutionner le monde ou quoique ce soit, d'ailleur je n'en parle même plus et y'a longtemps que j'ai arrêté de vous enmerdez avec ca.
Sans vouloir faire mon prétentieux, j'ai pas l'impression d'avoir mis un style pompeux dans les depêches que j'ai proposé sur ce site concernant Mono, j'ai essayé d'un mettre un macimum d'objectivité, laissant le lecteur juger lui même de ce qui est "innovant" ou "génial".
Je n'ai pas eu la prétention de faire un joli document LaTeX comme boubou pour en faire un "libre blanc" de la situation des brevets autour de Mono, alors que visiblement il était aussi connaisseur que moi en droit, avait les mêmes problèmes d'interprétation de texte anglais que moi, et évitait savamment les arguments qui puisse contredire la conclusion écrite à l'avance de son document, qui se résume à du bon gros FUD : "avec MS, on sait jamais", bref argumentation de la peur, du doute.
Alors oué, je suis peut être pas doué sur la forme (orthographe, argumentation, ce que tu veux), mais moi j'avais juste l'impression de défendre un projet de logiciel libre. Je sortais pas des trucs "vos technos n'auraient même pas mérité d'existé" et autres conneries du genre.
T'inquiète pas, je suis pas revenu troller longtemps, je vois que certains sont toujours autant admiratif de la forme, même lorsqu'elle s'apparente au plus gros troll, plutôt que de discuter du fond.
Tout d'abord: pourquoi es-tu aussi agressif envers les créateurs de Lisaac ?
Agressif ? Bof, pas plus que le commentaire noté +10 de Benoît Sonntag qui dit à 2 reprises que C# et Java sont des langages qui n'auraient jamais dû existé (sans aucune argumentation) quand Lisaac est "moderne". Du bon gros troll de base. Ajouté à cela le ton pompeux et auto-complimenté de la dépêche (même si contenant plein d'informations), ca donne vraiment une impression de "vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
Alors voilà, je demande à voir, je me poses les questions du programmeur/concepteur de tous les jours, et je prends pour exemple la modularité.
En quoi le code n'est pas modulaire sous prétexte que la liaison avec la bibliothèque se fait à la compilation, et pas au runtime ?
Même si la modularité au sein d'un composant monolithique est une bonne pratique de programmation, la modularité perd une bonne partie de son intérêt si on ne peut pas remplacer un composant par un autre de manière plus "technique" (lib, module, framework, etc.). La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc. D'après ce que je comprends, Les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité, où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
Je vois que leur objectif est de faire un OS, comment feront-ils pour charger et décharger un module à chaud ? Accepter un éco-système de drivers externes ?
Que ce soit uniquement une étape du style "on mettra les bibliothèques après", je peux comprendre (se focaliser sur les nouveautés d'optimisation), 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, je ne vois absolument pas l'intérêt. (il a sûrement d'autre qualité cependant)
, mais il est tout à fait possible de faire du code modulaire comme ça.
Faire du code modulaire n'est pas une fin en soit, ce qu'on recherche c'est les avantages que la modularité apporte. Lisaac semble limité son utilité.
Lisaac simule des schemas d'executions et trace tous les types possibles.
Sauf qu'un des gros atouts de l'objet, c'est de bosser avec des contrats d'interface, sans connaître le type sous-jacent, souvent fourni par un composant tiers, soit mis à la disposition des programmeurs (framework).
Rassures moi : Lisaac envisage bien la programmation modulaire quand même ? Non parcqu'il est soit disant génial et il faut abandonner C# et Java, alors je me pose des questions de programmation de tous les jours... (je ne fais pas référence à tes propos mais à ceux de Benoît).
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. Travaillons ensemble vers autre chose que C# et Java...
Tu proposes quoi pour replacer Java/C# ? Non parcque Lissac ne semble pas pour toi un bon candidat (remplace plutôt ce qui se faisait habituellement en C ou ASM).
Que reproches-tu à C# ou Java dans leurs utilisations classiques (IHM/SI/SOA/Web etc.) et que proposes-tu à la place ?
Le compilateur arrive à retomber, à 96 % sur du code monomorphique
Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé.
Je conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
Quelques remarques : "Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style : "La spécification 0.2 apporte des innovations importantes"
Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.". "certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien) "Non content"[...]
Et j'en passe.
Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.
Perdu j'ecris des drivers windows pour mon boulot et des drivers linux pour notre matos pour me faire plaisir.
T'es pas le bon exemple, mais prend la plupart des moules qui traîne par ici.
Si on laisse les constructeurs fournir des drivers binaires leur visions financiere dictera la suite et on aura jamais de pilote libre.
Bah je croyais que le modèle du libre était le plus pertinent pour les entreprises sur le long terme ? Faut savoir ! Utilisons les arguments habituels sur les atouts du libre, mais ne leur mettons pas des batons techniques dans les roues, ca ne fait que dégrader l'image du libre et les oportunités qu'ils pourraient y trouver.
Et quand c'est vraiment plus gerable, hop une release majeur ou on casse toute la compatibilité ancienne
Oui, et ? C'est du grand classique : t'as les API officielles, les API legacy/deprecated mais encore fonctionnels et les trucs plus gérés. C'est toujours mieux que le cycle de vie des API actuels de Linux ou tu passes beaucoup trop rapidement de officiel à unsupported.
tu veut que l'on parle de l'echange de fichier entre les differentes versions de Word ?
C'est un format de données, pas une API. Enfin si tu veux faire un parallèle, toute l'argumentation du libre repose sur la péreinité des données, la normalisation ISO & Co, bref la stabilité du format ODF. T'imagines si à chaque mise à jour mineure d'OpenOffice.org fallait aller modifier à la mano les balises XML du document pour respecter le nouveau schema parcque les développeurs avaient décider qu'il fallait modifier certaines balises pour s'adapter à leurs besoins tous les 4 matins ? (bah oui, t'as les sources, tu peux le faire !)
pour API Win32 oui c'est stable et tes appli , comme pour linux, marche entre deux version de windows ou deux version de linux kernel.
Certes, mais on parle des API des drivers là.
Par contre ne crois pas que pour les drivers windows rien ne change, prend un disque fournit avec une des tes cartes et regarde, tu trouveras un repertoire 9x,2K,XP et Vista.
2K,XP en général, c'est le même driver. Ce qui peut changer, c'est qu'avec XP est apparu une certification par Microsoft pour XP (signature numérique du driver), mais globalement tu avais un avertissement mais le driver fonctionnait.
Pour vista, des pilotes XP marchent encore. Ca dépend évidemment du type de matos. Là encore mon but est même pas d'essayer d'avoir quelque chose de stable entre 2 grosses releases, mais déjà entre 2 releases mineures.
Comme tu le fais remarquer, un driver pour Windows n'a pas 36000 dossiers, t'imagines sous Linux si on récapitule tous les drivers nvidia par exemple ?
Justement, combien de temps apres la sortie de Vista as t'on put trouver des drivers nVidia correct ?
Y'avait un driver correct depuis le début. Mais qui ne gérait pas plus de trucs que dans XP, et donc ne gérait pas les nouveautés de Vista qui a introduit un nouveau modèle de driver. Ca n'a pas empêcher Vista de supporter l'ancien modèle (sans les nouveautés évidemment) et nvidia s'est lancé dans le nouveau modèle de driver parcqu'il est certain de sa péreinité (pour quelques années en tout cas).
C'est justement tout le contraire, tout les elements disponible pour ré-écrire comme tu le pense les driver ou le kernel sont accessible, ce qui n'est pas le cas avec Windows ou tu ne peut que regarder faire.
Mais sous Windows tu peux faire un driver libre si tu veux, et le déployer, lui assurer un support, etc. Sous Linux tu sais très bien que c'est quasiment impossible, tu es toujours obligé de courrir après les nouveautés du kernel (même si ton drivers est open-source, ca change rien), la seule solution, c'est d'intégrer ton driver au cycle de vie du driver et de perdre la main dessus.
La dispo de la source c'est la possibilité d'une alternative, le binaire c'est l'absence de cette alternative.
Je suis d'accord. Gardons la dispo des sources, et stabilisons les API qui sera un énorme avantage pour tous, mêmes quand on a les sources.
Si on devait un jour "geler" les interfaces cela serait tout simplement le signe du refus d'évoluer.
Windows fait évoluer ses interfaces, c'est pas pour ca qu'elles ne sont pas un minimum stable.
Tu garanti le resultat avec un driver 32 de XP sous Vista 64 bits ? Tu me trouve un driver XP pour mon joystick logitech qui marchait tres bien sous 95 et qui ne marche pas sous XP?
Est-ce que j'ai dis que c'était toujours le cas ?
Pareil sous Linux : tu prends un drivers de linux 2.2, je te met au défit de le recompiler sur un 2.6 toi même.
Réponse non, le vendeur de materiel ne porte pas ces pilotes et t'impose de racheter du nouveau materiel pour un nouvel OS
Non, car on aura un driver libre. C'est pas parcqu'on autorise les drivers binaire qu'on n'interdit les drivers libres.
Pour avoir fais des drivers vxd,wdm et kmdf maintenant je te garanti qu'un driver USB unique entre 95,98 et 2000
Forcement y'a eu un gros gap entre 95/98 et 2000. J'interdit pas les gros changements, mais pas tout le temps. A chaque grosse version. entre la première version de Win2000 et le dernier service pack il s'est écoulé plusieurs années, et tes pilotes se sont mis à ne plus marcher ?
mais si tu decide de payer quelqu'un pour le faire tu as plein de SSLL ou de dev. indépendant qui peuvent faire le boulot.
On est d'accord, dans la vraie vie de monsieur tout le monde, c'est une illusion. Une pseudo solution.
Le code irait en grossissant et perdrait en performance à chaque modification, creation d'une nouvelle API si pour toi c'est simplifier les choses...
C'est pourtant ce que font tous les gros softs dignes de ce nom qui s'interfacent avec des composants extérieurs. Je dis pas que c'est plus simple. Je dis que c'est penser aux utilisateurs. Si pour toi un soft ne doit pas être conçu pour ses utilisateurs, ca sert à rien qu'on discute.
Là encore, tous tes arguments se basent sur une critique des drivers binaires. Moi je demande une API stable. Rien d'incompatible avec les drivers libres. La compatibilité avec les drivers binaires n'est qu'un avantage supplémentaire.
La stabilite des API, c'est une catastrophe. Imagine un OS fige dans ses API depuis des decennies.
Qui te parle de décennies ? Quelques années ca serait déjà pas mal (genre 3-5 ans). Stable veut pas dire "figés". Je demande juste une certaine "durée de vie".
Windows et Mac OS ont des API stables. Gnome et KDE ont des API stables. Y'a que le kernel qui a cette abération.
Et tu n'imagines pas la difficulte que c'est de maintenir tout ca, de devoir avoir deux interfaces de drivers dans le noyau.
Bof, j'imagine très bien, c'est pas la mort. Pas pire que maintenir 100000 drivers quand les API changent en tout cas. Sous Windows ils le font, c'est que c'est faisable. Si le but est de faciliter les utilisateurs (qu'ils soient end-users ou développeurs de driver). De plus si c'est pas le kernel qui le fait, c'est d'autres projets qui vont le faire, chacun va réinventer la roue (nvidia, Dell, etc.).
Cela explique bien a mon avis le temps de developpement qu'a pris Vista pour un gain final pas enorme.
Quand mon driver graphique plante, l'OS le relance. Quand mon driver audio plante, l'OS le relance. Pour moi c'est un gain énorme. Quand un service pack sortira, le kernel sera modifié, je sais que mes drivers marcheront toujours, pas comme sous Linux où je prie systématiquement pour que mon matos fonctionne comme avant.
Euh, tu as deja eu acces a du code de constructeurs ???
Houlà à aucun moment j'ai dis qu'il fallait se contenter des drivers binaires, ne pas réécrire de drivers libres, ne pas faire pression sur les constructeurs pour qu'ils libèrent leurs specs. Au contraire. Mais ca ne doit pas être une excuse pour ne pas offrir tout le confort d'un API stable aux utilisateurs.
Enfin bon c'est le classique débat entre les développeurs qui se focalise sur leur logiciel et les développeurs qui se focalisent sur les utilisateurs de leur logiciel.
Je te rappelle quand meme que sous Windows qui a l'air d'etre ta reference, tu passes un temps dingue a devoir trouver tous les drivers qui vont bien.
Ah bon ? Moi c'est rigolo sous Windows, le driver est toujours sur un CD avec le matos quand l'OS ne le reconnait pas directement (après éventuel téléchargement sur Windows Update sans intervention de ma part). Sous linux, si le matos ne marche pas, ben tant pis pour moi. Au pire je trouve d'obscures documentation qui me disent comment recompiler le noyau pour obtenir telle ou telle fonctionnalité. Yahoo. Chacun son expérience hein.
tout ca pour dire que sous Linux on pourrait faciliter la vie des constructeurs, démocratiser Linux, sachant qu'on pourrait combiner les avantages des OS proprio (à savoir qu'eux n'ont pas le choix de stabiliser leurs API) : API stables, et kernel + drivers libres pour meilleur support péreinité.
Les 2 qualités ne sont pas opposés, et ca serait un sacré atout de Linux face à Windows. Mais non, les développeurs du kernel préfèrent garder la main mise sur les drivers et leur interdire toute vie alternative. Au nom de quoi ? D'un supplément de souplesse dans les API. Mouarf. Elle est où l'API révolutionnaire par rapport à Windows ou Mac OS X qui justifie cette souplesse par rapport à un modèle plus stable ?
Un pilote (binaire ou non) s'execute dans l'espace kernel et a donc acces a tout [..] La confiance dans le fournisseur de ce pilotes est donc necessaire.
Kernel mal conçu. Beaucoup de pilotes n'ont aucun intérêt à tourner avec les privilèges du kernel et pourrait très bien fonctionner en mode utilisateur. Bref, le vrai problème est ailleur pour ce qui est de la "confiance". Et c'est valable également pour un driver Open-source, on peut faire confiance au fait qu'il ne contient pas de code malicieux, mais on est jamais à l'abris d'une erreur de programmation qui fait tout péter.
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Les sources assurent une meilleure péreinité, une meilleure portabilité (32/64 bits par exemple), mais ca n'est pas non plus une garantie qui remplace une stabilité des API. Parfois c'est une simple illusion.
Plutôt que de s'amuser à maintenir des milliers de drivers dans un même bouzin (pas le choix, c'est monolithique et les interfaces bougent en permanence), ils feraient mieux de s'atteler à stabiliser les API, proposer des nouvelles API et continuer à supporter binairement les anciennes. C'est du boulot, mais c'est sûrement pas pire que maintenir des milliers de drivers. Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Si en plus ca pouvait faire réfléchir à l'architecture du kernel (stabilité des API, privilèges du code exécuté)
Et oui, ca laisserait la porte ouverte aux pilotes binaires, mais c'est quoi le problème ? Au pire on a du matos supplémentaire qui fonctionne sous Linux sans alternative libre, au mieux ca fait double emploi avec un driver libre. C'est où le problème ?
Enfin si le kernel ne veut pas bouger, heuresement des acteurs plus pragmatiques commencent à se bouger le cul (style Dell : http://linux.dell.com/projects.shtml ) ou des petits projets comme FUSE ( http://fuse.sourceforge.net/ ). Dommage d'en arriver à des abérations où on est obligé de créer des couches de glue supplémentaire pour palier des manques de conception sous-jacent.
Ah oui dernier point : stabiliser les API favoriserait l'apparition de drivers alternatifs maintenus par d'autres personnes que les developpeurs du kernel, voir des kernels alternatifs qui profiterait de l'API stable pour supporter un grand nombre de drivers.
pas sa licence OEM,
Ce qui prouve bien que la licence est indissociable de la machine, elle ne peut être vendue séparement ;) (humour hein) que comme pour sa voiture on peut choisir essence ou diesel
Oué bah oué, c'est comme si t'avais le choix entre Windows XP Pro et Windows XP Home. Moi je veux du GPL, et y'a aucune commission pour forcer les constructeurs à imposer des modèles GPL ;)
Question à 2 balles :
Pourquoi as-tu repris uniquement la partie de la conférence annoncant l'ouverture du labo entre MS et Novell (alors que c'est pas la news du siècle, ca fait plusieurs mois qu'ils ont annoncé la création de ce labo) ?
Nan parcque la vraie nouvelle info dans la conférence, c'est surtout que Microsoft et Sun vont également ouvrir un laboratoire commun avec le même type de collaborations, notamment autour de la virtualisation.
Ben je rapelle que la seule suite implémentant( et de facon incorrecte) ooxml en lecture et écriture c'est la suite office.
Vois toujours pas l'argument. MS Office propose toujours d'enregistrer en vieux .doc. L'utilisateur a toujours le choix, notamment en entreprise où il est facile d'imposer des règles.
MS Office 2003 avait un format XML, pas grand l'a utilisé malgré la position "dominante" de MS...
Mais bon c'est plus simple pour toi, si OOXML marche, c'est uniquement un abus de position dominante. grosso merdo MS est condamné à abuser de sa position.
Le vrai FUD c'est joué a microsoft en disant 'attention y a des brevets' et quand on demande les brevets 'ben euh je sais pas, y en a c'est tout'.
Oué c'est aussi du FUD. C'est pas parcque MS se permet de FUDer qu'il faut faire pareil.
Tu vas attaquer quoi toi ?
Comme tu le dis, ton hypothèse part d'un rêve. Partant de là c'est pas très crédible ton scénario. Et ca ne dit d'ailleur pas pourquoi les autres softs comme OOo ne seront pas attaqués.
Linux, où tu es sur que si il y a une once de brevet qui apparait le code va etre réecris ?
Tu vas rire, c'est exactement la même politique officielle de Mono (cf FAQ). Dans la vraie vie c'est pas toujours possible, comme ca ne sera pas toujours possible dans Linux. C'est EXACTEMENT pareil. C'est marrant de prendre 2 situations identiques et de bien sûr imaginer 2 scénarios différents, comme ca arrange.
Rappellons que Novell peut se faire racheter par exemple.
Oué, IBM peut changer de stratégie, RedHat peut se faire rachter, MS peut couler, les poules peuvent se mettre à avoir des dents, bla bla bla. Tu pourras toujours imaginer des scénarios, c'est pas un argument pour autant.
Tu peux imaginer que Novell se fasse racheter... par RedHat ou IBM aussi tiens. Tu peux imaginer que Novell soit racheter par MS mais que le portefeuille de brevets soit vendu... à IBM.
T'as que l'embarras du choix. Mais on est plus dans le domaine de la science fiction que dans la réalité.
J'ai dis ca moi ?
Je n'ai meme jamais parler de moonloght dans mon argumentaire.
Comme souvent, vous vous exprimez avec tellement de sous-entendus... Mais bon jolie pirouette, bravo. Désolé d'avoir supposé que tu parlais du journal qui parle de Moonlight. Met Mono dans ma phrase tu préfères ?
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Loin derrière ? Mono compile presque toutes les nouveautés, Mono devrait supporter intégralement C# 3 au moment de la sortie officielle de Visual Studio 2008 (le produit commercial rattaché au lancement officiel de C# 3) pour janvier, ils n'auront jamais été aussi synchro.
On peut compiler du caml ou du F# en .Net. Implémentation != language
Bien sûr, mais les exemples de langages que tu proposes sont des langages de "haut niveau" qui respect les paradigmes objets de base, ce qui est le point commun requis par la VM de .NET.
Et il y a parfois des corrélations fortes : le langage peut supposer la présence d'un garbage collector avec un fonctionnement bien précis, le langage peut supposer la présence de certains types de base, le langage peut supposer la présence d'un framework de sécurité sous-jacent, de possibilité d'introspection, etc.
il est où le framework IHM en .Net ?
Il est là : http://www.microsoft.com/downloads/details.aspx?familyid=7B9(...)
et là :
http://www.microsoft.com/downloads/details.aspx?familyid=2B6(...)
C'est pas en standard dans le framework, mais c'est sans doute pas plus mal, tout le monde n'est pas d'accord sur le pattern le plus adapté et encore moins sur la façon de l'implémenter.
Pour les IHM web tu as par contre un framework complet et de nombreux frameworks annexes.
Mais pour ce qui est de la consommation de ressources et la fluidité .Net a encore du chemin avant de rattraper le vieux Delphi.
.NET ajoute une couche d'abstraction (VM) et des services associés qui ont effectivement un coût. Mais Delphi ne proposait pas tous ces services, c'est donc difficilement comparable.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Mouaich, ca peut très bien être explicite dans le nom de la méthode, dans la doc (et donc l'auto-complétion) :
mon_arbre.foreach_while_do_finally(while, do, finally);
Après effectivement c'est moins puissant que les block notamment dans les exemples que tu donnes.
Tu peux toujours contourner le problème en prenant en paramètre une interface imposant de passer par exemple un objet contenant 3 "fonctions", chacune correspondant à un bloc.
Ca serait un peu plus lourd syntaxiquement, mais tu gardes les mêmes possibilités.
Après je te dirais franchement que je n'aime pas du tout les exemples sur lesquels on travail, j'ai peur que les développeur face trop mumuse avec pour avoir leur petites libs de boucles à eux, qu'eux seuls comprennent (avec tous les bugs qui vont avec).
Un peu comme en C++ ou tu peux faire tout et n'importe quoi avec les templates et les macros (certains se sont amusés à reproduire la syntaxe de Lisp) : ca peut devenir imbitable pour un intérêt très limité.
[^] # Re: Merci...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Linux et la photographie : état des lieux. Évalué à 2.
Ou pas. Il te propose les 2. C'est vrai que si on coche pas la case correspondante, par défaut il recopie. Parcqu'on peut aussi lui brancher un appareil photo par exemple (auquel cas il n'y a pas besoin de lui dire quoi faire).
Mais tu as raisons, F-Spot propose par défaut une abstraction du support de tes photos. L'idée est de proposer plutôt une vue par tag et une vue temporelle plutôt qu'un arbre de dossier qui est beaucoup plus contraignant.
Il faudrait effectivement ajouter à F-Spot une fonction de "surveillance" de répertoire pour qu'il détecte les renommages et les ajout/suppression.
vu l'organisation assez spéciale des dossiers F-Spot.
2007/09/26/toto.jpg
Pas si compliqué :)
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Java ou .NET inclu beaucoup plus que ca, ce que tu me décris là c'est Java il y a 5 ou 10 ans.
Moi je veux un serveur d'application, je veux un framework web, je veux un framework web-services, je veux un framework d'IHM vectorisé, je veux un framework de workflow, je veux un framework 3D, je veux un framework audio/video, je veux un framework pour l'embarqué, je veux un framework pour client web, je veux des API de sécurité, je veux des API de gestion de plugins, je veux des API pour les schema W3C, pour XSLT, un framework pour composants transactionnels, des API de cryptographie, j'en oublie sûrement plein.
Et je veux surtout que le tout soit unifié, pas un assemblage de trucs disparate qui vienne de différentes sources, chacune avec ses concepts pas toujours compatibles entre eux me forcant à m'adapter en permanence sans profiter de mon acquis.
Enfin tout ce qui fait la force de Java ou .NET quoi.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Toutafé, y'a pleins de choses bien, mais les inconvénients sont trop bloquant pour qu'ils soient utiles. C'est comme Lisaac aujourd'hui : pas de modularité binaire == utilisation anecdotique (pour moi).
le language ne permet pas d'encapsuler les requêtes sql correctement,
C# 3 :
var res = from s in auteurs
where s.Length == 5
orderby s
select s.ToUpper();
Quand tu parles de framework, tu t'éloignes du language pour en venir aux bibliothèques.
Pas totalement, quand je parle framework je parle aussi machine virtuelle (bytecode, JIT, GC, securité, etc.) : le langage expose plus ou moins de possibilité en fonction de la machine "cible". C'est fortement lié.
Enfin, J2EE, .Net réinventent la roue (Squeak, Delphi), en moins bien et surtout en beaucoup plus lent et volumineux.
Il est où le serveur d'application en Squeak ou Delphi ? Elle
C'est le même type qui a fait C# et qui a fait Delphi dans le passé, je vois mal comment il aurait pu faire "moins bien". D'ailleur .NET est tellement moins bien que Delphi que Delphi cible maintenant .NET comme plateforme "cible" (entre autre), ce qui démontre au passage tout l'intérêt d'avoir une VM intermédiaire standardisée.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 0.
Pas convaincu. Il n'y a pas pour moi d'opposition entre impératif et objet. L'objet est plus une façon de programmer, de représenter les données : tu peux très bien appliquer le concept en C. Cette méthode (objet) est tellement naturelle (chercher à encapsuler, factoriser) qu'elle conduit à introduire dans la syntaxe des langages impératifs des constructions dédiées. Mais c'est une évolution, pas un "saut".
Tu peux toujours faire de l'impératif en Java comme tu peux faire de l'objet en C. C'est pas forcement les bons outil pour la bonne utilisation, mais c'est tout à fait possible.
Tout le problème c'est que pour voir les avantages que ca apporte il faut accepter d'y consacrer un peu de temps...
Certes, mais pour cela faut voir la transition : pourrais-je toujours programmer comme avant ? Pourrais-je utiliser ma syntaxe favorite (argument .NET) ? Pourrai-je faire la même chose qu'avant ? (framework complet) Existe-t-il un IDE où je puisse être productif ? Est-ce compatible avec l'existant ? Existe-t-il un support (forum, doc, etc.) ?
Beaucoup trop de langages "universitaires" se focalise sur le langage en lui même. J'ai envie de dire que le langage en soit est presque accessoire si on oublie le reste.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Oué mais nan, j'étais parti sur un foreach_while qui supposait qu'on avait 2 blocks d'instructions en paramètres. Tu es revenus à un foreach "classique", d'où mes nouveaux exemples.
ou alors y a de fines nuances sur le comportement...
Y'a juste des évolutions : C# 1 : pointeurs de méthodes, C# 2 : méthodes anonymes (plus besoin de déclarer une méthode séparée que l'on référence), C# 3 : expression lambda.
Alors oui, dans C# 3 tu peux toujours faire comme en C# 2 ou C# 1.
qu'on veut 3 blocs en parametres, etc, on fait comment ?
Bah pareil ! C'est quoi le problème ? Mon premier exemple prenait 2 blocs, chacun était dans mon exemple une lambda expression séparé par une virgule (dur dur). Je te laisse deviner comment ajouter un 3ème paramètre ;)
le i, tu le declares avant ?
Bah nan, c'est une lambda expression, le i est justement ici sa déclaration. Son type est défini par inférence à partir du type de la méthode Foreach.
C'est justement parcque tu ne comprends pas cette écritureque j'avais commencé par la syntaxe C# 2 ;) Mais certains trouvent plus joli, plus concis et plus propre la 3ème.
Enfin tout ca pour dire que je ne vois absolument pas la différence, au final je peux déclarer une méthode qui prends plusieurs paramètres, chaque paramètre peut être un bloc de code, que tu l'écrives sous la forme d'une fonction anonyme ou sous la forme d'une lambda expression.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 0.
C'est un gros défaut, c'est vraiment illisible, on passe son temps à compter les parenthèses.
Moi je vois surtout qu'il manque un framework. Un vrai bon gros framework uniformisé et qui reprend la plupart des outils nécessaire pour réaliser une grande variété d'application.
C'est le gros point commun entre Java et C# : c'est le framework.
surtout l'ignorance des programmeurs qui restent dans leur caverne.
Pas convaincu, on est beaucoup à être passé à un moment par le Lisp et autre OCaml. C'est gentil mais sans framework ca sert à rien.
Même dans le langage : des besoins "industriels" comme le versionning des types, l'introspection (plugins, automatisation, etc.), voir même la facilité d'inter-actions dans un IDE, tout ca nécessitent un langage qui a été un minimum pensé dans ce sens.
Lisp c'est joli pour les mathématiciens, mais ca sert pas à grand chose pour un informaticien (qui ne fait pas des algos mathématiques la plupart du temps).
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Décevant ? Je comprends ta frustration mais moi je vois les choses différement : en réutilisant la syntaxe du C++, elle facilite la vie de millions de développeurs, en limitant volontairement les aspects objets, elle simplifie la compréhension du code pour un développeur "moyen", etc.
Ces langages sont une suite logique d'évolutions, et c'est cet "héritage" du passé qui font qu'ils sont utilisables et utilisés.
A quoi sert un langage si personne ne le comprend ?
A quoi sert un langage si seul les chercheurs sont capables d'en appréhender les concepts (soit de trop haut niveau, soit top différent des concepts existants) ?
Bref, la beauté du langage ne fait toutes les qualités requises pour un langage "ready" pour un large public de développeur.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Lisaac :
mon_arbre.for_all { i : ITEM;
//code
};
C# :
mon_arbre.Foreach(delegate(ITEM i)
{
//code
});
ou (toujours C#) :
mon_arbre.Foreach(i =>
{
//mon code
});
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Bof, en C# 3 je peux faire ca :
maliste.foreach_while(elem => elem.Foo() , elem => elem.truc == 0);
qui applique la Foo à tous les éléments de ma liste tant que la propriété truc vaut 0.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 0.
Ca évolue, regarde le Dynamic Language Runtime que vient de sortir MS, il s'appui intégralement sur les briques de base existante.
complexité de la grammaire (et donc lenteur de la compilation)
Mouaich. Suffisament rapide pour être compilé en temps réel par les IDE. Je ne suis pas sûr que des langages comme Lisaac qui visent une grande quantité d'optimisations à la compilation améliore la chose. Enfin je ne vois pas en quoi Java & co ont 30 ans de retard là dessus.
pas de curryfication, pas de tail recursion, ..
Et ca fait de Java et C# des langages qui n'auraient jamais dû exister ?
Faut aussi bien voir que ces langages évoluent : généricité, lambda expression, langages de requête, etc.
montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.
Ou sont suffisament générique et d'assez haut niveau pour supporter un vaste éco-système.
Ces frameworks ne pourraient pas exister sans une base technique qui le permet (bytecode pour les tisseurs, introspection pour les tests U, etc.)
Même si beaucoup de tes critiques sont pertinentes, il n'y a pas à l'heure actuelle d'alternative pour leurs segments d'utilisation. Tous les autres langages ont leurs défauts propres qui ne leur permet pas de remplacer Java ou C# pour de nombreuses utilisations.
Alors dire que ces langages ne devraient pas exister, cela suppose qu'on est au moins le bon goût de proposer une alternative. Benoît Sonntag le dit lui même, Lissac n'en ai pas une.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
J'ai jamais prétendu que Mono allait révolutionner le monde ou quoique ce soit, d'ailleur je n'en parle même plus et y'a longtemps que j'ai arrêté de vous enmerdez avec ca.
Sans vouloir faire mon prétentieux, j'ai pas l'impression d'avoir mis un style pompeux dans les depêches que j'ai proposé sur ce site concernant Mono, j'ai essayé d'un mettre un macimum d'objectivité, laissant le lecteur juger lui même de ce qui est "innovant" ou "génial".
Je n'ai pas eu la prétention de faire un joli document LaTeX comme boubou pour en faire un "libre blanc" de la situation des brevets autour de Mono, alors que visiblement il était aussi connaisseur que moi en droit, avait les mêmes problèmes d'interprétation de texte anglais que moi, et évitait savamment les arguments qui puisse contredire la conclusion écrite à l'avance de son document, qui se résume à du bon gros FUD : "avec MS, on sait jamais", bref argumentation de la peur, du doute.
Alors oué, je suis peut être pas doué sur la forme (orthographe, argumentation, ce que tu veux), mais moi j'avais juste l'impression de défendre un projet de logiciel libre. Je sortais pas des trucs "vos technos n'auraient même pas mérité d'existé" et autres conneries du genre.
T'inquiète pas, je suis pas revenu troller longtemps, je vois que certains sont toujours autant admiratif de la forme, même lorsqu'elle s'apparente au plus gros troll, plutôt que de discuter du fond.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 7.
Agressif ? Bof, pas plus que le commentaire noté +10 de Benoît Sonntag qui dit à 2 reprises que C# et Java sont des langages qui n'auraient jamais dû existé (sans aucune argumentation) quand Lisaac est "moderne". Du bon gros troll de base. Ajouté à cela le ton pompeux et auto-complimenté de la dépêche (même si contenant plein d'informations), ca donne vraiment une impression de "vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
Alors voilà, je demande à voir, je me poses les questions du programmeur/concepteur de tous les jours, et je prends pour exemple la modularité.
En quoi le code n'est pas modulaire sous prétexte que la liaison avec la bibliothèque se fait à la compilation, et pas au runtime ?
Même si la modularité au sein d'un composant monolithique est une bonne pratique de programmation, la modularité perd une bonne partie de son intérêt si on ne peut pas remplacer un composant par un autre de manière plus "technique" (lib, module, framework, etc.). La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc. D'après ce que je comprends, Les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité, où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
Je vois que leur objectif est de faire un OS, comment feront-ils pour charger et décharger un module à chaud ? Accepter un éco-système de drivers externes ?
Que ce soit uniquement une étape du style "on mettra les bibliothèques après", je peux comprendre (se focaliser sur les nouveautés d'optimisation), 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, je ne vois absolument pas l'intérêt. (il a sûrement d'autre qualité cependant)
, mais il est tout à fait possible de faire du code modulaire comme ça.
Faire du code modulaire n'est pas une fin en soit, ce qu'on recherche c'est les avantages que la modularité apporte. Lisaac semble limité son utilité.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Sauf qu'un des gros atouts de l'objet, c'est de bosser avec des contrats d'interface, sans connaître le type sous-jacent, souvent fourni par un composant tiers, soit mis à la disposition des programmeurs (framework).
Rassures moi : Lisaac envisage bien la programmation modulaire quand même ? Non parcqu'il est soit disant génial et il faut abandonner C# et Java, alors je me pose des questions de programmation de tous les jours... (je ne fais pas référence à tes propos mais à ceux de Benoît).
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Travaillons ensemble vers autre chose que C# et Java...
Tu proposes quoi pour replacer Java/C# ? Non parcque Lissac ne semble pas pour toi un bon candidat (remplace plutôt ce qui se faisait habituellement en C ou ASM).
Que reproches-tu à C# ou Java dans leurs utilisations classiques (IHM/SI/SOA/Web etc.) et que proposes-tu à la place ?
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 6.
Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé.
Je conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
Quelques remarques :
"Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style :
"La spécification 0.2 apporte des innovations importantes"
Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.".
"certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien)
"Non content"[...]
Et j'en passe.
Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à -4.
T'es pas le bon exemple, mais prend la plupart des moules qui traîne par ici.
Si on laisse les constructeurs fournir des drivers binaires leur visions financiere dictera la suite et on aura jamais de pilote libre.
Bah je croyais que le modèle du libre était le plus pertinent pour les entreprises sur le long terme ? Faut savoir ! Utilisons les arguments habituels sur les atouts du libre, mais ne leur mettons pas des batons techniques dans les roues, ca ne fait que dégrader l'image du libre et les oportunités qu'ils pourraient y trouver.
Et quand c'est vraiment plus gerable, hop une release majeur ou on casse toute la compatibilité ancienne
Oui, et ? C'est du grand classique : t'as les API officielles, les API legacy/deprecated mais encore fonctionnels et les trucs plus gérés. C'est toujours mieux que le cycle de vie des API actuels de Linux ou tu passes beaucoup trop rapidement de officiel à unsupported.
tu veut que l'on parle de l'echange de fichier entre les differentes versions de Word ?
C'est un format de données, pas une API. Enfin si tu veux faire un parallèle, toute l'argumentation du libre repose sur la péreinité des données, la normalisation ISO & Co, bref la stabilité du format ODF. T'imagines si à chaque mise à jour mineure d'OpenOffice.org fallait aller modifier à la mano les balises XML du document pour respecter le nouveau schema parcque les développeurs avaient décider qu'il fallait modifier certaines balises pour s'adapter à leurs besoins tous les 4 matins ? (bah oui, t'as les sources, tu peux le faire !)
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à -1.
Certes, mais on parle des API des drivers là.
Par contre ne crois pas que pour les drivers windows rien ne change, prend un disque fournit avec une des tes cartes et regarde, tu trouveras un repertoire 9x,2K,XP et Vista.
2K,XP en général, c'est le même driver. Ce qui peut changer, c'est qu'avec XP est apparu une certification par Microsoft pour XP (signature numérique du driver), mais globalement tu avais un avertissement mais le driver fonctionnait.
Pour vista, des pilotes XP marchent encore. Ca dépend évidemment du type de matos. Là encore mon but est même pas d'essayer d'avoir quelque chose de stable entre 2 grosses releases, mais déjà entre 2 releases mineures.
Comme tu le fais remarquer, un driver pour Windows n'a pas 36000 dossiers, t'imagines sous Linux si on récapitule tous les drivers nvidia par exemple ?
Justement, combien de temps apres la sortie de Vista as t'on put trouver des drivers nVidia correct ?
Y'avait un driver correct depuis le début. Mais qui ne gérait pas plus de trucs que dans XP, et donc ne gérait pas les nouveautés de Vista qui a introduit un nouveau modèle de driver. Ca n'a pas empêcher Vista de supporter l'ancien modèle (sans les nouveautés évidemment) et nvidia s'est lancé dans le nouveau modèle de driver parcqu'il est certain de sa péreinité (pour quelques années en tout cas).
C'est justement tout le contraire, tout les elements disponible pour ré-écrire comme tu le pense les driver ou le kernel sont accessible, ce qui n'est pas le cas avec Windows ou tu ne peut que regarder faire.
Mais sous Windows tu peux faire un driver libre si tu veux, et le déployer, lui assurer un support, etc. Sous Linux tu sais très bien que c'est quasiment impossible, tu es toujours obligé de courrir après les nouveautés du kernel (même si ton drivers est open-source, ca change rien), la seule solution, c'est d'intégrer ton driver au cycle de vie du driver et de perdre la main dessus.
La dispo de la source c'est la possibilité d'une alternative, le binaire c'est l'absence de cette alternative.
Je suis d'accord. Gardons la dispo des sources, et stabilisons les API qui sera un énorme avantage pour tous, mêmes quand on a les sources.
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à 5.
Windows fait évoluer ses interfaces, c'est pas pour ca qu'elles ne sont pas un minimum stable.
Tu garanti le resultat avec un driver 32 de XP sous Vista 64 bits ? Tu me trouve un driver XP pour mon joystick logitech qui marchait tres bien sous 95 et qui ne marche pas sous XP?
Est-ce que j'ai dis que c'était toujours le cas ?
Pareil sous Linux : tu prends un drivers de linux 2.2, je te met au défit de le recompiler sur un 2.6 toi même.
Réponse non, le vendeur de materiel ne porte pas ces pilotes et t'impose de racheter du nouveau materiel pour un nouvel OS
Non, car on aura un driver libre. C'est pas parcqu'on autorise les drivers binaire qu'on n'interdit les drivers libres.
Pour avoir fais des drivers vxd,wdm et kmdf maintenant je te garanti qu'un driver USB unique entre 95,98 et 2000
Forcement y'a eu un gros gap entre 95/98 et 2000. J'interdit pas les gros changements, mais pas tout le temps. A chaque grosse version. entre la première version de Win2000 et le dernier service pack il s'est écoulé plusieurs années, et tes pilotes se sont mis à ne plus marcher ?
mais si tu decide de payer quelqu'un pour le faire tu as plein de SSLL ou de dev. indépendant qui peuvent faire le boulot.
On est d'accord, dans la vraie vie de monsieur tout le monde, c'est une illusion. Une pseudo solution.
Le code irait en grossissant et perdrait en performance à chaque modification, creation d'une nouvelle API si pour toi c'est simplifier les choses...
C'est pourtant ce que font tous les gros softs dignes de ce nom qui s'interfacent avec des composants extérieurs. Je dis pas que c'est plus simple. Je dis que c'est penser aux utilisateurs. Si pour toi un soft ne doit pas être conçu pour ses utilisateurs, ca sert à rien qu'on discute.
Là encore, tous tes arguments se basent sur une critique des drivers binaires. Moi je demande une API stable. Rien d'incompatible avec les drivers libres. La compatibilité avec les drivers binaires n'est qu'un avantage supplémentaire.
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à 2.
Qui te parle de décennies ? Quelques années ca serait déjà pas mal (genre 3-5 ans). Stable veut pas dire "figés". Je demande juste une certaine "durée de vie".
Windows et Mac OS ont des API stables. Gnome et KDE ont des API stables. Y'a que le kernel qui a cette abération.
Et tu n'imagines pas la difficulte que c'est de maintenir tout ca, de devoir avoir deux interfaces de drivers dans le noyau.
Bof, j'imagine très bien, c'est pas la mort. Pas pire que maintenir 100000 drivers quand les API changent en tout cas. Sous Windows ils le font, c'est que c'est faisable. Si le but est de faciliter les utilisateurs (qu'ils soient end-users ou développeurs de driver). De plus si c'est pas le kernel qui le fait, c'est d'autres projets qui vont le faire, chacun va réinventer la roue (nvidia, Dell, etc.).
Cela explique bien a mon avis le temps de developpement qu'a pris Vista pour un gain final pas enorme.
Quand mon driver graphique plante, l'OS le relance. Quand mon driver audio plante, l'OS le relance. Pour moi c'est un gain énorme. Quand un service pack sortira, le kernel sera modifié, je sais que mes drivers marcheront toujours, pas comme sous Linux où je prie systématiquement pour que mon matos fonctionne comme avant.
Euh, tu as deja eu acces a du code de constructeurs ???
Houlà à aucun moment j'ai dis qu'il fallait se contenter des drivers binaires, ne pas réécrire de drivers libres, ne pas faire pression sur les constructeurs pour qu'ils libèrent leurs specs. Au contraire. Mais ca ne doit pas être une excuse pour ne pas offrir tout le confort d'un API stable aux utilisateurs.
Enfin bon c'est le classique débat entre les développeurs qui se focalise sur leur logiciel et les développeurs qui se focalisent sur les utilisateurs de leur logiciel.
Je te rappelle quand meme que sous Windows qui a l'air d'etre ta reference, tu passes un temps dingue a devoir trouver tous les drivers qui vont bien.
Ah bon ? Moi c'est rigolo sous Windows, le driver est toujours sur un CD avec le matos quand l'OS ne le reconnait pas directement (après éventuel téléchargement sur Windows Update sans intervention de ma part). Sous linux, si le matos ne marche pas, ben tant pis pour moi. Au pire je trouve d'obscures documentation qui me disent comment recompiler le noyau pour obtenir telle ou telle fonctionnalité. Yahoo. Chacun son expérience hein.
tout ca pour dire que sous Linux on pourrait faciliter la vie des constructeurs, démocratiser Linux, sachant qu'on pourrait combiner les avantages des OS proprio (à savoir qu'eux n'ont pas le choix de stabiliser leurs API) : API stables, et kernel + drivers libres pour meilleur support péreinité.
Les 2 qualités ne sont pas opposés, et ca serait un sacré atout de Linux face à Windows. Mais non, les développeurs du kernel préfèrent garder la main mise sur les drivers et leur interdire toute vie alternative. Au nom de quoi ? D'un supplément de souplesse dans les API. Mouarf. Elle est où l'API révolutionnaire par rapport à Windows ou Mac OS X qui justifie cette souplesse par rapport à un modèle plus stable ?
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à 2.
Kernel mal conçu. Beaucoup de pilotes n'ont aucun intérêt à tourner avec les privilèges du kernel et pourrait très bien fonctionner en mode utilisateur. Bref, le vrai problème est ailleur pour ce qui est de la "confiance". Et c'est valable également pour un driver Open-source, on peut faire confiance au fait qu'il ne contient pas de code malicieux, mais on est jamais à l'abris d'une erreur de programmation qui fait tout péter.
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Les sources assurent une meilleure péreinité, une meilleure portabilité (32/64 bits par exemple), mais ca n'est pas non plus une garantie qui remplace une stabilité des API. Parfois c'est une simple illusion.
Plutôt que de s'amuser à maintenir des milliers de drivers dans un même bouzin (pas le choix, c'est monolithique et les interfaces bougent en permanence), ils feraient mieux de s'atteler à stabiliser les API, proposer des nouvelles API et continuer à supporter binairement les anciennes. C'est du boulot, mais c'est sûrement pas pire que maintenir des milliers de drivers. Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Si en plus ca pouvait faire réfléchir à l'architecture du kernel (stabilité des API, privilèges du code exécuté)
Et oui, ca laisserait la porte ouverte aux pilotes binaires, mais c'est quoi le problème ? Au pire on a du matos supplémentaire qui fonctionne sous Linux sans alternative libre, au mieux ca fait double emploi avec un driver libre. C'est où le problème ?
Enfin si le kernel ne veut pas bouger, heuresement des acteurs plus pragmatiques commencent à se bouger le cul (style Dell : http://linux.dell.com/projects.shtml ) ou des petits projets comme FUSE ( http://fuse.sourceforge.net/ ). Dommage d'en arriver à des abérations où on est obligé de créer des couches de glue supplémentaire pour palier des manques de conception sous-jacent.
Ah oui dernier point : stabiliser les API favoriserait l'apparition de drivers alternatifs maintenus par d'autres personnes que les developpeurs du kernel, voir des kernels alternatifs qui profiterait de l'API stable pour supporter un grand nombre de drivers.
[^] # Re: Le libre n'avait rien à gagner ...
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, ton univers impitoyable.... Évalué à -1.
Ce qui prouve bien que la licence est indissociable de la machine, elle ne peut être vendue séparement ;) (humour hein)
que comme pour sa voiture on peut choisir essence ou diesel
Oué bah oué, c'est comme si t'avais le choix entre Windows XP Pro et Windows XP Home. Moi je veux du GPL, et y'a aucune commission pour forcer les constructeurs à imposer des modèles GPL ;)
Bref, toutes les comparaisons sont foireuses :)
[^] # Re: C'est un partenariat normal entre deux sociétés concurrentes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft et Novell. Évalué à 3.
Pourquoi as-tu repris uniquement la partie de la conférence annoncant l'ouverture du labo entre MS et Novell (alors que c'est pas la news du siècle, ca fait plusieurs mois qu'ils ont annoncé la création de ce labo) ?
Nan parcque la vraie nouvelle info dans la conférence, c'est surtout que Microsoft et Sun vont également ouvrir un laboratoire commun avec le même type de collaborations, notamment autour de la virtualisation.
http://www.betanews.com/article/Dueling_Interop_Labs_Microso(...)
[^] # Re: Mon cher Albert,
Posté par TImaniac (site web personnel) . En réponse au journal "OOXML is a superb standard" qui a dit ca a votre avis?. Évalué à 1.
Vois toujours pas l'argument. MS Office propose toujours d'enregistrer en vieux .doc. L'utilisateur a toujours le choix, notamment en entreprise où il est facile d'imposer des règles.
MS Office 2003 avait un format XML, pas grand l'a utilisé malgré la position "dominante" de MS...
Mais bon c'est plus simple pour toi, si OOXML marche, c'est uniquement un abus de position dominante. grosso merdo MS est condamné à abuser de sa position.
Le vrai FUD c'est joué a microsoft en disant 'attention y a des brevets' et quand on demande les brevets 'ben euh je sais pas, y en a c'est tout'.
Oué c'est aussi du FUD. C'est pas parcque MS se permet de FUDer qu'il faut faire pareil.
Tu vas attaquer quoi toi ?
Comme tu le dis, ton hypothèse part d'un rêve. Partant de là c'est pas très crédible ton scénario. Et ca ne dit d'ailleur pas pourquoi les autres softs comme OOo ne seront pas attaqués.
Linux, où tu es sur que si il y a une once de brevet qui apparait le code va etre réecris ?
Tu vas rire, c'est exactement la même politique officielle de Mono (cf FAQ). Dans la vraie vie c'est pas toujours possible, comme ca ne sera pas toujours possible dans Linux. C'est EXACTEMENT pareil. C'est marrant de prendre 2 situations identiques et de bien sûr imaginer 2 scénarios différents, comme ca arrange.
Rappellons que Novell peut se faire racheter par exemple.
Oué, IBM peut changer de stratégie, RedHat peut se faire rachter, MS peut couler, les poules peuvent se mettre à avoir des dents, bla bla bla. Tu pourras toujours imaginer des scénarios, c'est pas un argument pour autant.
Tu peux imaginer que Novell se fasse racheter... par RedHat ou IBM aussi tiens. Tu peux imaginer que Novell soit racheter par MS mais que le portefeuille de brevets soit vendu... à IBM.
T'as que l'embarras du choix. Mais on est plus dans le domaine de la science fiction que dans la réalité.
J'ai dis ca moi ?
Je n'ai meme jamais parler de moonloght dans mon argumentaire.
Comme souvent, vous vous exprimez avec tellement de sous-entendus... Mais bon jolie pirouette, bravo. Désolé d'avoir supposé que tu parlais du journal qui parle de Moonlight. Met Mono dans ma phrase tu préfères ?