Articles précédents : Interview
- [46] Interview de Marcus Brinkmann, développeur du Hurd
- [9] Interviews de l'auteur de GnomeMeeting
- [3] Interview de Gérald Sédrati-Dinet sur Divergence FM
- [11] Interviews FOSDEM, le retour de la vengeance
- [1] Nouvelles interviews FOSDEM
- [2] Interviews FOSDEM
- [73] Interview de Timothy Miller, du projet Open Graphics
- [12] Interviews FOSDEM 2005
- [25] Interview de Vivian Siegel (PLoS)
- [105] Interview de Richard Stallman sur KernelTrap
Liens connexes
- L'interview (1627 hits)
- Mono (806 hits)
- Son blog (871 hits)
Dépêche modérée par
Dépêche éditée par
Interview : Interview de Miguel de Icaza par O'reilly
Posté par Gonéri Le Bouder (Jabber id, page perso, ). Modéré le 24 mars 2005.
Dans cette interview, de Icaza présente entre autres les évolutions qu'apportera la prochaine version de Mono : l'API Windows.Forms, C# 2.1, portages vers les architectures 64 bits et de nouveaux ports, support de Java et d'autres langages, etc. Bien sûr, les problèmes liés aux brevets logiciels, souvent critiqués dans ce projet, sont aussi évoqués.
O'Reilly est un éditeur spécialisé dans les ouvrages traitant de l'informatique.
![[en]](../../../images/en.png)
L'interview (1627 hits)-
Mono (806 hits)
-
Son blog (871 hits)
> Lire la dépêche (165 commentaires, moyenne: 2,1).
Quelques liens utiles
L'annonce de Mono 1.0 sur DLFP : http://linuxfr.org/2004/07/02/16698.html(...)
Débat 15 j + tard : http://linuxfr.org/2004/07/16/16823.html(...)
et l'article sur Wikipedia : http://fr.wikipedia.org/wiki/Mono(...)
-
[^]Re: Quelques liens utiles en français
Posté par j (page perso, ) le 25/03/2005 à 00:09. (lien). Évalué à 3.je ne sais pas si c'est récent ou pas mais le site de monodevelop a maintenant quelques pages en français :
Acueil : http://monodevelop.org/lang/fr/(...)
Didacticiels : http://monodevelop.org/lang/fr/tutorial.aspx(...)
"Hello World" : http://monodevelop.org/lang/fr/tutorials/helloworld.aspx(...)
Utilité de Mono
Je ne m'exprimerai que sur Mono. Pour moi ce dernier est une très bonne chose, de nombreuses entreprises utilisent .Net qui en soit est tout de même plutôt bon même si ce n'est pas mon fer de lance. Mono permet à des entreprises comme la mienne de répondre à la demande des clients sans toute-fois être obligé de changer notre environnement de travail ni notre politique de déployement chez ces derniers. Bien sur après il y a tous les problèmes liés aux brevets mais je ne m'étendrai pas dessus ici.
-
[^]Re: Utilité de Mono
Posté par vrm (page perso, ) le 24/03/2005 à 11:56. (lien). Évalué à 4.Perso l'utilité de Mono et plus de me fournir un environement de dev intéressant pour gnome (GTK#, glade) plutot que la compatibilité .NET (R.A.F. de winforms). Comme quoi chacun trouve sont intéret dans MONO
-
[^]Re: Utilité de Mono
Posté par Jiel (page perso, ) le 24/03/2005 à 17:44. (lien). Évalué à 1.Perso l'utilité de Mono et plus de me fournir un environement de dev intéressant pour gnome (GTK#, glade) plutot que la compatibilité .NET (R.A.F. de winforms). Comme quoi chacun trouve sont intéret dans MONO
Bof. Les winforms, GTK#, le C# ou le Java, je trouve ça dommage de mettre ça en avant pour faire des logiciels libres. La communauté du logiciel libre a assez de bon langages... J'ai l'impression que Mono "cautionne" le monde de l'informatique propriétaire, comme si le libre était incapable d'innover! On peut être curieux et observer ce qui se passe dans l'informatique en général, mais améliorons plutôt nos outils avant d'essayer de refaire ceux des autres!
Et je parle pas des risques légaux, le rêve des éditeurs de logiciels propriétaires, c'est de voir une toute petite ligne à eux dans un gros soft libre: ainsi le soft ne serait plus du tout libre! D'autre part, est-ce qu'un logiciel libre ne marchant qu'avec une machine virtuelle java propriétaire peut vraiment être qualifié de "libre"?
Bref Miguel s'amuse et c'est son droit, mais je suis pas sûr que ca soit d'un grand intérêt pour la communauté.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 18:41. (lien). Évalué à 5.MDI a quand derrière la tête plusieurs idées :
- proposer une plateforme moderne, libre et performante pour Linux (ce qui exclu déjà pas mal de "beaux" outils comme tu dis), bref une alternative à Java.
- proposer une solution au problème récurant de la nécessité de maintenir pleins de bindings pour différents langages dans certains environnement, MDI ayant bien entendu Gnome derrière la tête. MDI veut proposer autre chose que des libs écrites en C aux programmeurs, et le C# semble un bon compromis entre sécurité/productivité et performances/intégration de l'existant.
- MDI veut attirer des développeurs venant de Windows, et même s'il attire ne serait-ce que 1% des développeurs Windows, je te laisse imaginer l'impact sur la communauté Linux :).
- MDI fait aussi un pari : il sait pertinament que cette plateforme a un avenir (parcque MS s'y est jeté) et que la plateforme .NET sera incontournable dans le futur, qu'on le veuille ou non. Proposer une compatiblité avec cette plateforme c'est aussi par soucis d'interopérabilité, au même titre que OOo gère le .doc ou que Samba existe.
D'autre part, est-ce qu'un logiciel libre ne marchant qu'avec une machine virtuelle java propriétaire peut vraiment être qualifié de "libre"?
D'où l'intérêt de proposer des VM libres tient :)
Mono a en plus l'avantage d'être multi-plateforme, le projet n'étant pas une simple VM pour Linux, mais une implémentation pour de nombreuses plateformes matérielles.
J'espère t'avoir convaincu que cette plateforme peu apporté quelque chose à la communauté Linux.-
[^]Re: Utilité de Mono
Posté par Jiel (page perso, ) le 24/03/2005 à 19:26. (lien). Évalué à 5.- MDI veut attirer des développeurs venant de Windows, et même s'il attire ne serait-ce que 1% des développeurs Windows, je te laisse imaginer l'impact sur la communauté Linux :).
Il va peut etre attirer quelques amoureux du C#. Les autres, s'ils n'ont pas déjà migrés sous GNU/Linux, c'est qu'ils ont leurs raisons.
-
[^]Re: Utilité de Mono
Posté par fabb () le 24/03/2005 à 20:45. (lien). Évalué à 2.> - proposer une solution au problème récurant de la nécessité de maintenir pleins de bindings pour différents langages dans certains environnement, MDI ayant bien entendu Gnome derrière la tête.
Dans ce domaine, le projet Gnome ne l'a jamais suivi. J'ai aucune crainte. C# sera un binding parmis d'autre.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 21:25. (lien). Évalué à 2.Dans ce domaine, le projet Gnome ne l'a jamais suivi.
Je croyais que c'était MDI qui avait préconisé le langage C dans Gnome parcque justement facile à binder... En tout cas ca se vérifie très bien, suffit de voir KDE le bordel que c à binder leur C++ bizzare.-
[^]Re: Utilité de Mono
Posté par fabb () le 24/03/2005 à 21:42. (lien). Évalué à 1.> Je croyais que c'était MDI qui avait préconisé le langage C dans Gnome parcque justement facile à binder...
Ben oui et il avait raison. Mais il a proposé C# afin de facilité les bindings et il s'est fait renvoyé dans les choux.
Pour un binding, Gnome ne propose pas par exemple python->C# et C# fait le reste vers les librairies C. Gnome propose python->C, java->C, perl->C, etc...-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 21:58. (lien). Évalué à 2.Me semble pas que MDI est encore tenté officiellement de faire taper l'incruste à Mono dans Gnome... MDI s'est déjà fait envoyé sur les choux pour d'autres raisons, là il est à mon avis plus prudent et cherche avant tout à démontrer l'utilité de son projet.
Gnome ne propose pas par exemple python->C#
C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C. Et ca s'appelle IronPython, un compilateur Python pour .NET.-
[^]Re: Utilité de Mono
Posté par fabb () le 24/03/2005 à 22:10. (lien). Évalué à 1.> Me semble pas que MDI est encore tenté officiellement de faire taper l'incruste à Mono dans Gnome...
Effectivement. Il ne l'a dit qu'au début de Mono. Après, il ne l'a plus jamais proposé (à ma connaissance).
> C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C.
Oui. Désolé pour mon imprécision.
-
[^]Re: Utilité de Mono
Posté par Nicolas Évrard (Jabber id, page perso, ) le 25/03/2005 à 01:05. (lien). Évalué à 3.
Gnome ne propose pas par exemple python->C#
C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C. Et ca s'appelle IronPython, un compilateur Python pour .NET.
Tiens en parlant d'IronPytho, CPython est surtout très apprécié pour l'immense bibliothèque de module disponible, ces modules sont pour certains écrits en python (et alors tout va bien) mais pour tout ceux qui sont écrit en C, est-ce qu'il ne risque pas de ralentir l'adoption d'IronPython car indisponibles sous cette implémentation ?
On le voit avec Jython, c'est une implémentation vraiment intéressante mais très peu utilisée car elle ne vient pas avec "les batteries inclues" comme on dit.
Évidemment les performances annoncées par IronPython sont impressionantes mais si les bibliothèques ne suivent pas j'ai bien peur que cette implémentation reste quelque peu marginale.
On me dira qu'on s'en fout puisque de toute façon les bibliothèques seront là via la magie de la CLR, ben oui c'est vrai mais alors on court le risque d'un split de la communauté en deux ... enfin qui vivra verra.
PS: À quand un compilateur scheme -> CLR ?--
Le scheme c'est bien.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 25/03/2005 à 11:19. (lien). Évalué à 4.PS: À quand un compilateur scheme -> CLR ?
http://www.cs.indiana.edu/~jgrinbla/index.htm(...)-
[^]Re: Utilité de Mono
Posté par Nicolas Évrard (Jabber id, page perso, ) le 25/03/2005 à 13:13. (lien). Évalué à 2.Ce n'était qu'une boutade mais merci beaucoup tout de même pour le lien.
--
Le scheme c'est bien.
-
-
-
-
-
-
-
-
-
[^]Re: Utilité de Mono
Posté par fabb () le 24/03/2005 à 20:47. (lien). Évalué à 5.Dans ce cas il y a aussi eclipse/java/java-glade/etc...
Petite démo :
http://people.redhat.com/overholt/nativeeclipse/index.html(...)
Devrait être dispo "out of the box" pour FC4. C'est dans FC4T1.
-
-
[^]Re: Utilité de Mono
Posté par thaodalf () le 24/03/2005 à 12:11. (lien). Évalué à 3.ca parait bizare de voulloir capitaliser sur un langage, mono, alors que celui-ci a obligatoirement du retard sur la version de référence, .Net.
les entreprises s'attendent a avoir les meme fonctionnalité vu que mono est présenté comme un mirroir a .net mais en faite mieux faut s'orienter vers d'autre technologie qui sont synchrone entre leur version windows et unix. ca montre beaucoup plus la "force" des LL multiplatforme.-
[^]Re: Utilité de Mono
Posté par Unixfix le Gaulois () le 24/03/2005 à 12:36. (lien). Évalué à 4.Cela faisait longtemps que l'on avait pas entendu M de Icaza. Apparament il a bossé dur son mono.
Ce qui m'etonnera toujours c'est son entetement a s'accrocher a Microsoft. D'abord son clone d'outlook (evolution) et maintenant Mono son clone de la platforme .NET de M$.
Ce qui est aussi particulierement etonnant c'est la description des avantages de Mono. On croirait entendre Bill.....
--
Slackware depuis 1996-
[^]Re: Utilité de Mono
Posté par zerbro (page perso, ) le 24/03/2005 à 12:57. (lien). Évalué à 9.Ce qui m'etonnera toujours, c'est de voir des gars du LL s'insurger du fait qu'on s'inspire de microsoft.
Quoiqu'on en dise MS est une formidable source d'inovation, recherche etc.. etc... Autant on peut critiquer leurs politiques commerciale et autres (et je suis le 1er), que leurs logiciels ne respectent pas assez l'utilisateurs -trop buggé etc... (et je suis encore le 1er), autant on ne peut pas critiquer le fait que leurs idées sont souvent _tres_ bonnes.
D'ailleur evolution est, pour moi, de loin le meilleur logiciel de messagerie (et c'est bien plus que ca d'ailleur) sous linux. Donc merci MDI d'avoir cloné outlook pour faire evolution.
Et pour finir, j'ajouterais que MS fait de la recherche et que leurs travaux sont qd meme vraiment exellent (je parle de leurs articles etc... et qui sont accessibles en ligne).
svp arreton de crier sur tout et n'importe quoi qd ca parle de MS. Pourtant j'aime vraiment pas cette boite, et je n'ai plus de windows d'installé depuis quelques années. Mais il faut aussi tenter de reconnaitre ce qui est bien, non ?-
[^]Re: Utilité de Mono
Posté par Croconux () le 24/03/2005 à 13:57. (lien). Évalué à 4.Ce qui m'etonnera toujours, c'est de voir des gars du LL s'insurger du fait qu'on s'inspire de microsoft.
Il n'y a pas de mal à s'inspirer si en reprenant les bonnes idées.
Le commentaire précédent parlait de Outlook qui est tout sauf un bon exemple en matière d'ergonomie. C'est vraiment une horreur. Pourquoi s'en inspirer? Parce que le decidor utilise Outlook et donc on lui pond un truc qui y ressemble pour ne pas le dépayser.
Pour en revenir à Mono, JMC a raison. Les implémentation libres de .NET resteront toujours des ré-implémentation du framework de MS. Les dépots auprès de l'ECMA ne couvrent pas grand chose. Le standard, c'est le framework MS. Les implémentations libres resteront toujours à la traine par rapport au framework officiel.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 14:16. (lien). Évalué à 6.Alors pourquoi Mono n'est pas en retard sur les spec officiels de l'ECMA ?
Pourquoi considérer que Mono est plus en retard que MS ? Mono n'implémente pas toutes les parties du framework .NET de la même manière que MS n'implémente pas tout le framework Mono.
J'ai même envie de dire que Mono est en avance : ils implémentent une bonne partie des libs de MS, Mono tourne sur Linux, MacOSX, S390, PPC, AMD64, SPARC et propose des libs inédites dans .NET, notamment en matière de sécurité et crypto. Alors maintenant qui est en retard ?
Les implémentation libres de .NET resteront toujours des ré-implémentation du framework de MS.
Pour le Windozien qui veut juste la compatibilité de ses applis, oui. Pour le Linuxien qui s'en fou ou le Windozien qui souhaite développer une appli portable Non. A croire que tu fais partis des premiers :)-
[^]Re: Utilité de Mono
Posté par Guillaume Knispel () le 24/03/2005 à 17:07. (lien). Évalué à 5.Donc finalement Mono / .net ne change rien.
Il y a MS et tout un écosystème qui gravite autour, et une partie du LL qui clone / tente d'obtenir une petite compatibilité partielle avec les "standards" MS, et lorsque l'on veut quelque chose de portable, il faut le prévoir d'origine.
Finallement, mono n'est-il pas condamné à échouer la ou Java à (partiellement puisque pas libre donc dispo pour un nombre assez restreint de plateformes du moins dans ses versions implantants toutes les fonctionnalités) réussit ?
Hm quoique Mono est libre donc il faudrait plutôt le comparer aux JVM libres...
Reste à étudier la question des qualités intrinsèques de C# et de la VM. Personellement je ne vois pas trop l'interet des VM dans le cadre du logiciel libre.
Et C# n'est pas vraiment une révolution par rapport à Java...
-
[^]Re: Utilité de Mono
Posté par Croconux () le 24/03/2005 à 19:00. (lien). Évalué à 7.Alors pourquoi Mono n'est pas en retard sur les spec officiels de l'ECMA
L'ECMA n'a fait qu'accepter une spec soumise par MS. Rien ne dit qu'ils continueront à fournir leurs specs. MS n'est pas réputé pour encourager l'interopérabilité. Au début, ils fallait bien qu'ils fassent un geste, .NET avait une étiquette "techno 100% MS" par rapport à Java. Ils ont soumis les documents de base pour montrer que leur technologie n'était pas si fermée que ça. Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Pourquoi considérer que Mono est plus en retard que MS
Parce que c'est MS qui fixe les règles du jeu ? Ils continueront de faire évoluer leur techno dans le sens qui leur plait en soumettant les specs comme standard tant que ça les arrangera. Ils peuvent ajouter toutes les features qu'ils veulent et qui ne seront disponible que sur leur implémentation, un peu comme les bidouilles spécial IE. Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML. S'ils sortent des extentions qui ne tournent que sous leur framework que peut-on faire ? Rien. C'est comme quand on reçoit des document en .doc qu'on ne peut pas lire parce qu'on n'a que la version n-1. Au final les gens migrent parce qu'ils ne peuvent pas lire les documents qu'on leur envoie.
J'ai même envie de dire que Mono est en avance
On peut dire que OOo est en avance par rapport à MSO parce qu'il est multi plateforme, sait lire les .doc et en plus les .sdw. Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
et propose des libs inédites dans .NET
Qui tournent aussi sur le framework de MS. Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Pour le Windozien qui veut juste la compatibilité de ses applis, oui. Pour le Linuxien qui s'en fou ou le Windozien qui souhaite développer une appli portable Non
Les premiers sont un poil plus nombreux que les seconds. Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens. Souvent on code d'abord et on se mort la bitte après.
croire que tu fais partis des premiers :)
A titre personnel, le Rubyist que je suis s'en fout un peu. Au boulot, je vais devoir me taper du .NET et je peux te dire que comme 99.99% des boites se sera avec le framework MS. Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 20:08. (lien). Évalué à 1.L'ECMA n'a fait qu'accepter une spec soumise par MS.
Au fait, les specs sont fournit par MS, Intel et HP, y'a pas que MS qui a son mot à dire.
Depuis les specs de la version 2.0 je te rappelle que Novell fait également partie intégrante du processus de normalisation.
Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Sauf que tu dis strictement n'importe quoi.
MS a normalisé la partie qui ne pourra plus bougé : les fondements, cad les libs de base et la VM : si MS casse la compatiblité avec cette norme ils cassent aussi la compatibilité avec toutes les applis .NET. Et si on regarde avec quelles difficultés ils conservent le support du win32 depuis des lustres, idem pour leur HTMLmadeIE (puisque tu aimes bien comparer avec le passé), alors on peut se dire que y'a pas de soucis à se faire concernant l'interopérabilité technique avec Mono.
De plus .NET n'est pas une simple évolution de win32, MS a pu repenser depuis 0 leur plateforme, ils y ont mis le temps et les moyens, c'est pas pour du jour au lendemain tout changer et faire chier le libre.
Je te rappelles aussi que Mono tourne aussi sous Windows, et que dans tous les cas les applis développées pour Mono resteront portables, quelque soit les choix de MS concernant son implémentation propriétaire.
Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML.
Je te rappelles que MS a fortement misé sur les technos XML (XML? XML Schema, XSLT, SOAP/Web Services, etc.) , notamment avec .NET, et qu'il est l'un des plus respectueux vis-à-vis de ces standards qui favorisent l'interopérabilité. Et jusque là tous leurs nouveaux produits vont dans ce sens.
Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
Pourquoi ? Parcque le support des .doc par OOo n'est pas parfait. Pour Mono, le support des standards et parfait et la compatiblité technique l'est aussi. Après chaque projet à ses libs spécifiques, Mono s'efforcant d'implémenter celle de MS.
Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Visiblement tu aimes bien dire n'importe quoi.
Si tu parles de ce qui tourne effectivement SUR Mono ou SUR le framework .NET, alors OUI, tout ce qui tourne sur le framework tourne sur Mono et inversement (auw bugs prêts bien sûr).
Ce qui n'est pas compatible ce sont certaines lib "natives" comme les WinForms ou les API Gnome dans Mono. Comme quoi y'a des incompatibilité dans les 2 sens.
Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens.
D'où l'idée de profiter du fait que MS les force à switcher vers .NET pour assurer un minimum d'interopérabilité dans notre monde Linux : tout le monde va y gagner, et personne ne va s'en plaindre.
Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.
D'où l'intérêt d'arrêter de FUDer sur la partie juridique, qui est du même niveau que dans toutes les autres solutions à base de LL.
D'où l'intérêt aussi d'avoir une boîte derrière pour soutenir commercialement le produit : Novell.-
[^]Re: Utilité de Mono
Posté par ufoot (page perso, ) le 26/03/2005 à 08:01. (lien). Évalué à 3.> > Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
> Sauf que tu dis strictement n'importe quoi.
Sur ce point précis honnêtement je pense au contraire qu'il a (très) franchement raison 8-/-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 26/03/2005 à 08:19. (lien). Évalué à 2.Bah moi je dis que non :)
Lorsqu'ils auront conquérit 99% du marché ils ne pourront plus se permettre de casser l'interopérabilité, comme c'est le cas pour IE ou le support du win32.-
[^]Re: Utilité de Mono
Posté par Stéphane TRAUMAT (page perso, ) le 26/03/2005 à 08:54. (lien). Évalué à 2.N'importe koi... c quand micrisoft a eu 90% du marché des browsers, qu'il s'est mis à ne plus respecter la norme HTML et à l'étenvre avec des valign=top par exemple!
-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 26/03/2005 à 09:12. (lien). Évalué à 2.Non pas n'importe quoi :)
Ce que tu dis ne contredis pas mes propos.
Ils peuvent s'amuser à "étendre" la norme en rajoutant des trucs, mais question interopérabilité ils sont obligé de garder une compatibilité avec l'existant (pour faire tourner les vieux sites).
Mais bon là ils partent sur des bases plus saines puisqu'ils utilisent des standards bien définis et propres grammaticalement. (Parcque bon les premières normes HTML étaient beaucoup trop laxistes et pas assez contraingnantes).-
[^]Re: Utilité de Mono
Posté par fabb () le 26/03/2005 à 09:32. (lien). Évalué à 1.> Ils peuvent s'amuser à "étendre" la norme
Il ne l'étende pas, il la polue. C'est nettement différent. S'il ne font que l'étendre les pages qui respectent les standards devrait être rendue correctement. Mais sous IE ce n'est pas le cas.
Mozilla va aussi au-delà des standards et ça ne pose pas de problème.
> Parcque bon les premières normes HTML étaient beaucoup trop laxistes et pas assez contraingnantes
Les premières normes n'étaient laxistes. Par contre, le développement des bituneurs était plus rapide que la norme. Donc les développements n'étaient pas basés sur des standards et ce sont les butineurs qui "définissaient" les normes. Comme tout est devenu ugly, html (surtout la version 4 transitionnal) est devenu laxiste. Puis html 4 strict + css a remis de d'ordre.
-
-
-
-
-
-
-
-
-
[^]Re: Utilité de Mono
Posté par Nosferatu () le 24/03/2005 à 14:53. (lien). Évalué à 2.Quoiqu'on en dise MS est une formidable source d'inovation, recherche etc.. etc...
Pardon ? une formidable source d'inovation ?
Les menus déroulants proviennent du mac, le système de fenêtrage tel qu'il a été prévu pour windows provient des travaux faits avec IBM sur OS/2 + inspirations sur les OS de l'époque: Next, Apple, XWindow, Unix (X window date de 1985).
Franchement, comme système de fenêtrage inovant, on trouve mieux. MacOS, eux, ils inovent.
Pour ce qui est de la recherche, il y a quelques jolies choses (NTFS, RIFF, ...), mais vu la taille de la société, il est suprenant qu'ils n'inovent pas plus.
leurs idées sont souvent _tres_ bonnes.
Souvent ? hum...
vas-y, lâches toi, tu as une liste de bonnes idées ?
Je trouve que tu extrapoles un peu.
Et puis les idées, elles sont faites pour être partagées, donc tant que tout reste dans le secret, elles sont inaceptables.
Donc merci MDI d'avoir cloné outlook pour faire evolution
C'est pas parce que tu as fait un programme qui gères ton courrier, contacts et tâches que tu es forcément un clone d'outlook!
Bon, ok, on ne peut pas nier que l'interface des 1.x y ressemble franchement.
Et pour finir, j'ajouterais que MS fait de la recherche et que leurs travaux sont qd meme vraiment exellent
C'est à dire ? tu es un mec qui lit et applique ce qu'ils expliquent ?
je ne pense pas, parce que si c'était le cas tu ne t'enflammerai pas autant.
Par exemple, ici:
http://blogs.msdn.com/oldnewthing/archive/2003/09/05/54806.aspx(...)
Tu as des exemples faux par rapport à la description qui est faite.
svp arreton de crier sur tout et n'importe quoi qd ca parle de MS.
Le jour où leurs programmes seront libres, ou déjà leurs formats.
Le jour où ils arrêteront d'être hors la loi.
Le jour où ils se calmeront avec leurs brevets à la con.
Le jour où ils seront loyaux sur le marché.
Là on pourra dire qu'ils ne font pas que de la merde. En attendant, toujours est-il qu'ils sont cons, et je vois pas où est le mal de dire ça puisque c'est vrai.
Allez, dans les news récentes tu as quelques liens intéressants:
http://slashdot.org/articles/05/03/24/0348241.shtml?tid=109&tid(...)
http://yro.slashdot.org/yro/05/03/23/2311234.shtml?tid=155&tid=(...)
Mais il faut aussi tenter de reconnaitre ce qui est bien, non ?
Oui, quand c'est justifié.-
[^]Re: Utilité de Mono
Posté par zerbro (page perso, ) le 24/03/2005 à 16:58. (lien). Évalué à 9.
C'est à dire ? tu es un mec qui lit et applique ce qu'ils expliquent
Oui. J'ai étudié ces 6 derniers mois deux articles en rapport avec l'image, et ils sont tres bien. J'ai donc eu l'occasion de les etudier, de les critiquer, de les comparer avec d'autres méthodes et de les implémenter.
J'ai pu en étudier un autre sur la classification des signaux audios, et les résultats obtenus sont _exellents_ le mec connaissait tres bien les descripteurs utiles pour ces signaux, les exploiter, et utiliser une méthode de classification récente et adapté. L'article se lisait de plus tout seul car très bien écrit.
Les chercheurs de microsoft font du bon travail, c'est un fait, ils sont meme tres appréciés dans le milieur de la recherche.
Il faut arreter de croire que MS bosse que sur windows, je vois dans l'image, il y a énormément a prendre dans leurs articles. MS fait de la recherche dans beaucoup de domaines.
Donc leurs idées, ils les partagent : les chercheurs de MS mettent leurs aticles en ligne comme tous les chercheurs. Ensuite, il ne faut pas regarder l'innovation que dans leurs produit vendu et encore moins windows. Je te parle d'innovation au niveau recherche, car il me semble que c'est le moteur de l'innovation...
Rien n'empeche les developpeurs de LLd'aller chercher dans les publies de MS.
En attendant, toujours est-il qu'ils sont cons, et je vois pas où est le mal de dire ça puisque c'est vrai.
Donc la tu insultes un de mes potes, et pleins de mecs qui bossent avec eux pour la recherche. Mais bon, toi, t'es un mec bien surement, qui détient la vérité absolue et a un regard objectif sur le monde...
Bref, je reponds a ce post, et je ne répondrais pas a tes posts suivants.-
[+] [^]Re: Utilité de Mono
Posté par Nosferatu () le 24/03/2005 à 18:09. (lien). Évalué à -6.Eh, je n'ai jamais dit que tout ce qu'ils publiaient était merdique.
mais tu as dit:
Et pour finir, j'ajouterais que MS fait de la recherche et que leurs travaux sont qd meme vraiment exellent
Il y a une nuance, non ?
Je ne suis pas aussi catégorique que toi. C'est tout.
Donc la tu insultes un de mes potes
On choisis ses amis ^^
Bref, je reponds a ce post, et je ne répondrais pas a tes posts suivants.
merci
-
[+] [^]Re: Utilité de Mono
Posté par reno () le 25/03/2005 à 06:20. (lien). Évalué à -2.>Les chercheurs de microsoft font du bon travail, c'est un fait
Les chercheurs de microsoft ont aussi produit BOB.. Donc ils font de la merde aussi, c'est un fait aussi.
La leçon est qu'il faut voir au cas par cas la production pas généraliser..
Ils font parfois du bon travail, parfois de la merde.-
[^]Re: Utilité de Mono
Posté par LeMagicien Garcimore () le 25/03/2005 à 15:35. (lien). Évalué à 2.Les chercheurs de microsoft ont aussi produit BOB
Kezako ?-
[^]Re: Utilité de Mono
-
-
-
-
-
[^]Re: Utilité de Mono
Posté par Mickaël L () le 24/03/2005 à 16:47. (lien). Évalué à 1.En tout cas, mono, ça n'a pas grand chose d'une innovation. C'est un repompage d'idées venant d'autres langages...
-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 17:45. (lien). Évalué à 3.ASP.NET est très innovant par rapport à ce qui existe (JSP/JFaces ou PHP)
.NET propose un environnement qui défini des types de base et une syntaxe de base non spécifique à un langage, favorisant l'intégration de codes générés à partir de différents langages, avec bien entendu la possibilité de mixer le tout.
C# est pour moi un des premiers langages proposant à la fois tous les avantages d'une VM et l'intégration de notions de plus bas niveau (pointeurs, delegate) pour intégrer facilement du code natif (lib écrites en C), bref de grosses facilités de rétutilisation de l'existant.
L'intégration des web services est exemplaire et d'un simplicité déconcertante.
Le système de versionning est l'un d'es plus complet que je connaisse, pour ne pas dire le plus complet.
Le compilateur JIT est performant, le code intermédiaire étant optimisé pour.
Alors NON, .NET/C#/Mono ne sont pas une révolution, mais OUI c'est un ensemble d'innovations.-
[^]Re: Utilité de Mono
Posté par Croconux () le 24/03/2005 à 20:57. (lien). Évalué à 6.ASP.NET est très innovant par rapport à ce qui existe (JSP/JFaces ou PHP)
Pour avoir pratiqué je suis plutot dubitatif vis à vis d'ASP.NET. Mon plus gros reproche concerne la non séparation entre la partie présentation et la partie code. Les deux sont tellement liés qu'on peut se demander à quoi ça sert de les mettre dans deux fichier séparés (aspx/code behind). D'ailleurs on n'est pas obligé : On peut bricoler l'apparence des contrôles via le code ou mettre du code dans l'aspx. Si on modifie un truc d'un côté, ça explose de l'autre. Bref, tout se tient, se mélange, toutes les tambouilles sont imaginables. C'est d'ailleur un gros problème dans ma boite. On a des pros de la bidouille qui inventent des trucs pas possible. J'ose à peine imaginer ce que ça va donner en ASP.NET vu l'amplitude possible des débordements dans la goritude. S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
favorisant l'intégration de codes générés à partir de différents langages
En théorie c'est génial, dans le pratique tout le monde code en C# parce que c'est le langage conçu pour .NET. Pour tous les autres langages, il y a des adaptation à prévoir pour que ce soit utilisable. Sans parler des langages qui ont de base un framework bien établi. OK, il est possible de coder avec la syntaxe de Python sur .NET mais il faut utiliser les classes du framework .NET. Python s'interface aussi avec du code compilé. Mais si on veut porter un soft en Python qui utilise des modules natifs il faut porter aussi ces modules (l'interface du moins). Bref, le multi langages c'est plutot un exercice se style. Dans ma boite on a du code en Delphi qu'on a tenté de compiler en .NET avec Delphi.NET, et là, c'est le drame. Marche pas top.
C# est pour moi un des premiers langages proposant à la fois tous les avantages d'une VM et l'intégration de notions de plus bas niveau (pointeurs, delegate) pour intégrer facilement du code natif (lib écrites en C)
Là je suis d'accord. Les delegates sont vraiment bien pratiques. Celà dit pour profiter d'un langage de haut niveau et des libs natives on a déjà Python, Ruby et Perl qui marchent très bien. Comme dit Germaine : "Reviens Léon, j'ai les mêmes à la maison"
Le système de versionning est l'un d'es plus complet que je connaisse
Idem pour moi. C'est relativement simple simple et ça marche bien. C'est un truc qui manque vraiment en Java. MS a tiré la leçon du "DLL hell".-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 21:23. (lien). Évalué à 2.Ben en fait pour ASP.NET je dois dire que j'ai eu beaucoup de mal au début : on fait effectivement un peu tout et n'importe quoi au début, et il faut bien capter la philosophie du truc pour arriver à maîtriser le bousin :)
Mais reste que le fait de proposer des composants réutilisables en faisant abstraction de la syntaxe HTML qui est derrière, je trouve ca génial.
Si tu as codé ton site uniquement avec les WebForms par exemple il est très facile de changer le "rendu" de code derrière pour changer totalement de normes HTML par exemple. Le système de session et de viewstate est également impressionnant, on peut réellement programmer l'appli web comme on programme un interface graphique, en réagissant à des événements de boutons, avec la transparence de ce qui se passe derrière.
Bon évidemment je suis conscient que cela peut être dangereux, c'est pourquoi il est à mon avis nécessaire de bien comprendre ce qui se passe réellement entre le client et le serveur.
S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
Franchement c'est la première fois qu'on me propose de programmer entièrement en objet un site web, et ceci de manière plutôt élégante, alors même si c'est la partie où j'ai eu le plus de mal je crois qu'à l'arrivé que c'est ce qui m'a le plus impressionné.
Bref, le multi langages c'est plutot un exercice se style.
Dans certains cas c'est quand même fort pratique, je penses surtout à C++ managed, qui permet d'avoir une superbe transition avec du code natif, notamment grâce à la possibilité de mixer natif et managé.
Pour avoir d'autres langages utiles que C#, XAML sera un très bon exemple, les procédures stockées côté SQLServer aussi. Le multi-langage c'est surtout pour faciliter certaines transitions.
Celà dit pour profiter d'un langage de haut niveau et des libs natives on a déjà Python, Ruby et Perl qui marchent très bien.
Je peux faire l'équivalent des DllImport de manière portable ?-
[^]Re: Utilité de Mono
Posté par Nicolas Évrard (Jabber id, page perso, ) le 25/03/2005 à 01:45. (lien). Évalué à 5.
S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
Franchement c'est la première fois qu'on me propose de programmer entièrement en objet un site web, et ceci de manière plutôt élégante, alors même si c'est la partie où j'ai eu le plus de mal je crois qu'à l'arrivé que c'est ce qui m'a le plus impressionné.
Et Zope c'est du poulet ? :)
De l'introduction que j'ai eu à l'ASP.NET (alors que je connaissais déjà moyennement zope) je me rapelle avoir pensé (c'était il y a 2 ans un peu d'indulgence avec ma mémoire) : "Oui c'est joli, bonnes idées mais ça n'est vraiment pas révolutionnaire ça ressemble furieusement aux concepts de zope".
Car en zope, quand tu crées un site tu commences par définir un tas d'objets qui agissent différement, ces produits sont extrèmement nombreux et font un peu de tout (du traitement de formulaire au traitement d'image en passant par les inévitables connexions aux bases de données). Et tu les assembles à coup de zpt, de scripts python ou d'autres produits que tu as écrit pour l'occasion et le tour est joué (dis comme ça c'est facile, dans la vraie vie c'est autre chose).--
Le scheme c'est bien.
-
-
[+] [^]Re: Utilité de Mono
Posté par Fabien Penso (Jabber id, page perso, ) le 24/03/2005 à 21:43. (lien). Évalué à -2.Celà dit pour profiter d'un langage de haut niveau et des libs natives on a déjà Python, Ruby et Perl qui marchent très bien. Comme dit Germaine : "Reviens Léon, j'ai les mêmes à la maison"
Bof, c'est de l'interpreté, pas de typage fort tout ça, c'est moyen. Puis bon Perl pour développer propre de gros projets...
C# c'est bon, mangez en :)-
[^]Python
Posté par Antoine () le 28/03/2005 à 23:35. (lien). Évalué à 2.Bof, c'est de l'interpreté
??? C'est compilé dynamiquement en byte-code (sauvé dans un fichier .pyc pour Python) puis exécuté par une VM.
pas de typage fort
Tu confonds typage fort et typage statique. En Python ou Ruby, le typage est fort mais dynamique.-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 09:21. (lien). Évalué à 2.??? C'est compilé dynamiquement en byte-code (sauvé dans un fichier .pyc pour Python) puis exécuté par une VM.
Et la VM elle fait quoi ? Ah ben elle interprête le bytecode comme c'est rigolo :)
Tu confonds typage fort et typage statique.
Reste que le typage fort pert tout son intérêt lorsqu'il est dynamique, puisque son principal intérêt est d'effectuer des vérifications et optimisations à la compilation-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 11:31. (lien). Évalué à 1.Et la VM elle fait quoi ? Ah ben elle interprête le bytecode comme c'est rigolo
Oui, c'est rigolo. Exactement comme une VM Java ou C#.
A ce compte-là, ton processeur interprète aussi les instructions qu'on lui envoie - puisqu'en interne il les convertit en micro-instructions qui n'ont plus rien à voir avec le jeu d'instructions original (dans les processeurs modernes, le backend est découplé du frontend).
Mais bon, j'imagine que je réponds à un troll.
Reste que le typage fort pert tout son intérêt lorsqu'il est dynamique, son principal intérêt est d'effectuer des vérifications et optimisations à la compilation
N'importe quoi. Les vérifications et optimisations peuvent être faites lors de l'exécution, il n'y a pas que la compilation dans la vie.-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 12:01. (lien). Évalué à 2.Oui, c'est rigolo. Exactement comme une VM Java ou C#.
rataiii
En ce qui concerne la VM de Mono/C#, elle commence par compiler en code natif le bytecode (mécanisme JIT et AOT)
Mono est d'ailleur livré avec un interprêteur et un compilateur, le premier ayant l'avantage de tourner sur plus de plateformes, le 2ème étant beaucoup plus rapide mais limité à certaines plateformes matérielles.
A ce compte-là, ton processeur interprète aussi les instructions qu'on lui envoie
Dans tous les cas il y a une grosse différence entre l'interprété et la compilation du bytecode, dans un cas le mécanisme d'interprétation se situe au niveau de la VM, c'est du logiciel qui interprête, dans l'autre cas c'est le proc, du matos qui interprête si tu veux : et y'a d'énormes différences de perfs. Donc ce n'est pas un troll du tout.
N'importe quoi. Les vérifications et optimisations peuvent être faites lors de l'exécution, il n'y a pas que la compilation dans la vie.
Tu comprends rien à ce que je veux dire. Evidemment que ca peut être fait à l'exécution, mais question perf c'est toujours mieux d'optimiser AVANT l'exécution, et c'est toujours beaucoup mieux d'avoir une vérification statique à la compile qu'à la compile, parcque en général c'est pas le même qui développe et qui exécute.
La VM a bien assez à faire pour compiler en code natif et optimiser pour le proc en dessous, si en plus faut qu'elle se farcisse une vérification de type à tout bout de champ tout en cherchant à optimiser en conséquence, voilà quoi.
Faut chercher à faire le maximum de chose en amont, pour se bouffer moins d'erreur à l'exécution, et pour laisser faire à la VM les optimisations qui ne peuvent être faites qu'à l'exécution.-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 12:31. (lien). Évalué à 2.En ce qui concerne la VM de Mono/C#, elle commence par compiler en code natif le bytecode (mécanisme JIT et AOT)
C'est un mécanisme d'optimisation, qui ne change rien au fait qu'il y ait du bytecode dans l'affaire, et rien au caractère soi-disant "interprété" du langage.
Python peut aussi être couplé avec un mécanisme ressemblant à un JIT, qui s'appelle Psyco : http://psyco.sourceforge.net/(...)
Il y a également des travaux en cours pour rendre Python auto-amorçable (compilateur écrit en Python) et plus facilement JITtable : http://codespeak.net/pypy/(...)
Evidemment que ca peut être fait à l'exécution, mais question perf c'est toujours mieux d'optimiser AVANT l'exécution
Tu te contredis. Si c'était mieux d'optimiser à la compilation, alors Java et Mono n'utiliseraient pas un JIT (qui veut dire "Just-In-Time", c'est-à-dire "juste à l'exécution" - et non à la compilation).
si en plus faut qu'elle se farcisse une vérification de type à tout bout de champ
Les vérifications de type peuvent être autant optimisées que le reste (en faisant de l'inférence de types et/ou en créant plusieurs branches du code en fonction des types rencontrés : Psyco utilise la seconde méthode, Pypy semble se diriger vers la première).
Il ne fait pas de doute que l'implémentation actuelle de Python soit souvent plus lente que celles de Mono/Java, mais les caractéristiques du langage (et notamment son caractère soi-disant "interprété") ne sont pas le facteur limitant.-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 12:44. (lien). Évalué à 2.un mécanisme ressemblant à un JIT, qui s'appelle Psyco
Ah non ! Psycho c'est du AOT, et on perd la portabilité. D'ailleur ca tourne que sur x86.
Enfin l'existence de ce projet montre clairement qu'il y a une grosse différence entre mode compilé et mode exécuté ;-)
Tu te contredis. Si c'était mieux d'optimiser à la compilation, alors Java et Mono n'utiliseraient pas un JIT
c'est juste qu'il y a pleins de sortes d'optimisation, dont certaines sont dépendantes de la machine cible, d'où l'idée de garder un bytecode optimisé (pour le typage par exemple, mais aussi tout ce qui concerne les optimisations sur la logique du programme, déroulement de boucle, élimination de variables inutiles, résolution de méthode virtuelles, etc.), et d'effectuer les dernières optimisations à l'exécution (ou juste avant, quand on connait la machine cible).
Donc le JIT est utile (suffit de comparer les perfs avec et sans).
Il ne fait pas de doute que l'implémentation actuelle de Python soit souvent plus lente que celles de Mono/Java, mais les caractéristiques du langage (et notamment son caractère soi-disant "interprété") ne sont pas le facteur limitant.
Ce qui esst clairement limitant c'est sont côté trop dynamique. Reste que si tu fais quelques hypothèses et qut tu attaques plus tôt les optimisations tu gagneras en perfs, c'est ce qui se passe avec Psycho ou IronPython.
Enfin à part la question de perf, un langage avec typage statique est plus sûr qu'une langage sans typage statique, qui permet des choses vraiment douteuses d'un point de vu méthodologique, comme la modification en "live" d'interface.-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 12:48. (lien). Évalué à 2.Autant pour moi, Psycho fait du JIT. Enfin reste que ca tourne uniquement sur x86 et visiblement le code généré est pas 100% compatible avec la sémantique du langage (ce qui me paraît enmerdant).
-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 12:54. (lien). Évalué à 2.D'ailleur ca tourne que sur x86.
Et alors ? Ton JIT Mono tourne sur tous les processeurs, peut-être ?
D'après la page d'accueil de Mono, les architectures supportées par le compilateur JIT sont : x86, x86-64, PPC. Tous ces portages ont été faits à la main, puisqu'il faut se farcir la génération de code natif. Sur les autres architectures, on retombe sur la VM traditionnelle.
Si autant de temps avait été investi dans Psyco que dans Mono, Psyco pourrait tourner sur autant d'architectures que Mono. Cela n'a rien à voir, encore une fois, avec la nature du langage source (Python).
qui permet des choses vraiment douteuses d'un point de vu méthodologique, comme la modification en "live" d'interface.
Oui, et qui permet aussi des choses très utiles comme faire des objects-proxy en dix lignes de code. Bref, cela a ses atouts et ses inconvénients.
-
-
-
-
-
-
[^]Re: Python
Posté par Fabien Penso (Jabber id, page perso, ) le 29/03/2005 à 09:24. (lien). Évalué à 1.??? C'est compilé dynamiquement en byte-code (sauvé dans un fichier .pyc pour Python) puis exécuté par une VM.
Bien sur, la plupart des interpretés utilise un byte-code histoire d'aller plus vite, ça change rien.
Le problème c'est que le résultat est que tu ne peux pas avoir de typage fort (ma langue a fourché), et donc pleins de vérifications ne peuvent pas etre faites en amont, t'es obligé de les faire à la main.
Comment tu fais en python pour forcer le type d'un argument ? Bah tu peux pas le spécifier dans la signature de la methode, comme tout bon language interpreté. Ce que je voulais indiquer c'est que c'est des vérifications en moins pour plus tard, perso je préfère pouvoir forcer un argument d'implémenter une interface que je définis, pour etre tranquille.-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 11:37. (lien). Évalué à 2.Bien sur, la plupart des interpretés utilise un byte-code histoire d'aller plus vite, ça change rien.
Java et .Net aussi utilisent un bytecode. Quelle est la différence alors ?
(vu que ton reproche à l'égard de Python / Perl / Ruby était qu'ils étaient interprétés, ce qui devient une notion très floue au regard des techniques actuelles...)
et donc pleins de vérifications ne peuvent pas etre faites en amont, t'es obligé de les faire à la main
Les vérifications de type (ou plus exactement de signature) sont faites à l'exécution, si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback. Il n'y a rien à faire à la main, sauf si tu veux remplacer le traceback par un autre message d'erreur.-
[^]Re: Python
Posté par Fabien Penso (Jabber id, page perso, ) le 29/03/2005 à 12:06. (lien). Évalué à 4.Les vérifications de type (ou plus exactement de signature) sont faites à l'exécution, si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback. Il n'y a rien à faire à la main, sauf si tu veux remplacer le traceback par un autre message d'erreur.
Super, quand t'as un projet avec 20 mecs qui bossent dessus pendant 2 ans, à la fin tu commences à avoir un truc assez gros. Puis ton truc tu l'exécutes, tu le tests, tout bien nikel.
Puis plus tard, un beau jour, quand ton truc est en production, bah paf, gros crash, ouais, tu tombes dans un scénario qui n'a jamais été testé dans les tests fonctionnels. Pas de bol, et dire que ça aurait été évité avec une verif de typage à la compilation...-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 12:37. (lien). Évalué à 2.Puis plus tard, un beau jour, quand ton truc est en production, bah paf, gros crash, ouais, tu tombes dans un scénario qui n'a jamais été testé dans les tests fonctionnels. Pas de bol, et dire que ça aurait été évité avec une verif de typage à la compilation...
Heu... Tu crois franchement que si un scénario n'a jamais été testé, les seules erreurs possibles sont des erreurs de typage ?
Le typage statique te donne la conscience tranquille vis-à-vis du système de types du langage, mais c'est tout. Sans compter que les erreurs de type sont les plus faciles à débusquer, que ce soit à l'exécution ou à la compilation (elles sont explicites)...
-
-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 12:21. (lien). Évalué à 2.Java et .Net aussi utilisent un bytecode. Quelle est la différence alors ?
Ben y'en a qui le compile, d'autre qui l'interprête. Question de perf.
si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback.
C'est vrai le client il va adorer ce genre de truc. Enfin si tu fais payer très cher la maintenance ca peut être un bon moyen d'avoir des rentrées d'argent régulières :)-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 12:42. (lien). Évalué à 2.Ben y'en a qui le compile, d'autre qui l'interprête. Question de perf.
Tu n'es pas obligé de faire deux fois la même réponse... J'ai déjà répondu ci-dessus.
Au passage, ton bytecode .Net ne sera pas "compilé" sur les machines où le JIT n'est pas supporté.
C'est vrai le client il va adorer ce genre de truc. Enfin si tu fais payer très cher la maintenance
Oui, car les erreurs de typage sont les seules qui nécessitent de la maintenance, et il n'y a jamais de bugs en dehors des erreurs de typage. Vraiment n'importe quoi.-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 12:53. (lien). Évalué à 2.Oui, car les erreurs de typage sont les seules qui nécessitent de la maintenance, et il n'y a jamais de bugs en dehors des erreurs de typage. Vraiment n'importe quoi.
Houlà j'ai pas dis que c'était les seules erreurs, mais je vois pas pourquoi sous prétexte qu'il y a pleins d'erreurs possible on se refuse à chercher à en minimiser certaines. Le typage fort n'est pas la solution miracle, mais c'est la solution à plusieurs problème, permettant d'avoir un peu plus de confiance dans le code qu'on écrit.
D'ailleur le bon programmeur cherchera a typer le maximum de choses (tout va dans ce sens, comme la notion de généricité par exemple) afin de justement s'assurer que le compilo puisse vérifier le maximum de conneries. La notion de typage avec les interfaces rejoint la notion de contrat, également fortement utilisé dans le processus de qualité logiciel.
Et puis le typage fort permet des optimisations, ca sera toujours ca de gagner à l'exécution, puisque ca en moins à faire : pourquoi s'intéresser aux perfs à l'exécution et ainsi perdre un peu de perf - le fait d'optimiser bouffe des perfs - alors que cela pourrait être fait avant ? Pourquoi laisser la possibilité au programme de claquer entre les doigts de l'utilisateur alors que cela pourrait être vérifier avant ?-
[^]Re: Python
Posté par Antoine () le 29/03/2005 à 12:59. (lien). Évalué à 2.pourquoi s'intéresser aux perfs à l'exécution
C'est une bonne question. Dans une grande partie d'applications (de bureau), les performances du langage applicatif sont tout à fait secondaires, par rapport à celles des bibliothèques. Sans compter qu'on peut écrire des saloperies avec un langage rapide (je ne pense pas qu'OpenOffice soit écrit en Python, ni même en Java).-
[^]Re: Python
Posté par TImaniac (page perso, ) le 29/03/2005 à 13:09. (lien). Évalué à 3.les performances du langage applicatif sont tout à fait secondaires, par rapport à celles des bibliothèques.
Tout à fait d'accord.
Mais parfois certains langages "attaquent" un peu plus bas dans le système, afin de ne pas être uniquement des langages applicatifs mais plus "généralistes". D'autre part certaines libs ont besoin d'être portables, et les langages bas-niveau (C+/C++, ASM) demandent à être recompilé sur chaque plateforme, ce qui est très lourd au niveau déploiement.
Pour OOo et Java, attend la prochaine news en première page de LinuxFr, tu vas tout savoir :)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 12:39. (lien). Évalué à 6.Déjà Mono n'est pas un langage, et concernant le langage proprement dit, C#, Mono a même eu de l'avance sur MS.
Ensuite Linux (l'OS dans son ensemble) a et a toujours eu du retard sur ses modèles concurrents, c'est pas pour ça qu'il est ignoré et qu'il est idiot de capitaliser dessus : il y a d'autres avantages, ben pour Mono c'est pareil, la compatibilté technique en plus pour favoriser la migration.
Ah oui, on peut aussi dire que le framework .NET est en retard sur Mono pour les libs GTK#, Gecko# & co.
mieux faut s'orienter vers d'autre technologie qui sont synchrone entre leur version windows et unix.
Mono est synchrone sur Windows et Unix. Et le socle technique est parfaitement synchrone, de toute facon quelque soit la plateforme tu auras toujours des libs dispo pour une seule plateforme pour une raison X ou Y.
T'en connais beaucoup des technos libres qui n'ont pas de retard sur leur modèle concurrent ? (et qui propose autant de chose que Mono bien entendu). Java, principal voir unique réel concurrent dans la même catégorie, a exactement les même problèmes d'implémentation et de retard sur la version officielle de Sun.-
[^]Re: Utilité de Mono
Posté par thaodalf () le 24/03/2005 à 13:27. (lien). Évalué à 3.j'ai jamais fait de .net ou de mono donc je me basse juste sur ce que j'ai lu. ce que j'ai voulu dire par "non synchrone" c'est que si un dvlpeur passe de .net a mono et que disons 20% des fonctionnalités ne sont pas présente ou alors sont présente pour tel os mais pas pour l'autre, ca va lui paraître chiant. ensuite certain langage/framework, tu parle de java, réussisent à garder des versions synchrone sur différentes platforme, là je pense a python entre linux, windows (j'ai a peine approché python sur mac).
l'histoire des lib spécifique a une plateforme sont pour moi une autre histoire.-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 13:35. (lien). Évalué à 3.l'histoire des lib spécifique a une plateforme sont pour moi une autre histoire.
Ah non ce n'est pas une autre histoire, parcque c'est justement cette partie qui n'est pas synchrone. Les bases techniques (VM, libs généralistes, compilo) sont synchrones.
, là je pense a python entre linux, windows
Sauf que j'ai dit "dans la même catégorie"
Je ne considère par Python comme exactement dans la même catégorie, même si Python est également généraliste.
c'est que si un dvlpeur passe de .net a mono et que disons 20% des fonctionnalités ne sont pas présente ou alors sont présente pour tel os mais pas pour l'autre, ca va lui paraître chiant.
T'inquiète pas ca va lui paraître beaucoup moins chiant que d'apprendre une nouvelle plateforme complète de A à Z :-) (passer de .NET à Python par exemple). Le développeur il va déjà être content de retrouver son langage, la philosophie de la plateforme, ses outils et une bonne partie de ses libs.-
[^]Re: Utilité de Mono
Posté par Stéphane TRAUMAT (page perso, ) le 24/03/2005 à 14:52. (lien). Évalué à 2.c'est que si un dvlpeur passe de .net a mono et que disons 20% des fonctionnalités ne sont pas présente ou alors sont présente pour tel os mais pas pour l'autre, ca va lui paraître chiant.
Moi j'aurais une question... Le gros avantage de .net, à mon avis, est l'outil de dev Visual Studio.. quand on développe une appli avec, est ce facile de la faire tourner sous Linux ?-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 14:57. (lien). Évalué à 1.Ben ca dépend de ce que tu fais. Avec VS.NET tu peux très bien faire du pur .NET, y'aura aucun problème de portabilité pour peux que tu fasses attention à un ou 2 détails "OS-specific" (nom de fichier, path, etc.), toolkit graphique (WinForms). Si tu utilises GTK# depuis VS.NET t'auras aucun problème.
Par contre évidemment si tu commences à faire du C++ mixed avec du mélange code managé/code natif, ou tout simplement que tu t'amuses à appeler des libs natives présentes uniquement sur l'OS de MS, forcement... Mais là ce n'est pas vraiment un problème spécifique à VS.NET.
Par défaut un projet VS.NET C# marche très bien sous Mono.-
[^]Re: Utilité de Mono
Posté par Stéphane TRAUMAT (page perso, ) le 24/03/2005 à 15:56. (lien). Évalué à 2.Prenons un exemple, je fais une appli classique style gestion des contacts.
Sous visual studio 2004, j'utilise le designer d'écran, une base postgresql, j'affiche, je modifie, je supprime et j'ajoute des contacts...
Comment je fais pour passer ça sous Linux ?-
[^]Re: Utilité de Mono
Posté par TImaniac (page perso, ) le 24/03/2005 à 16:20. (lien). Évalué à 2.Si t'as utilisé le designer d'écran pour ASP.NET (bref une appli web) , y'aura pas de problème :-p
Evidemment si t'utilises le designer de WinForms, ben, avec la version actuelle de Mono t'aura une chance sur 2 : soit les winforms que tu utilises sont entièrement implémentées, soit il en manque un bout. D'après la dernière version svn ils en sont à plus de 90% de réalisé.
-
[^]Re: Utilité de Mono
-
-
-
-
-
-
[^]Re: Utilité de Mono
Posté par push () le 24/03/2005 à 23:05. (lien). Évalué à 4.Ensuite Linux (l'OS dans son ensemble) a et a toujours eu du retard sur ses modèles concurrents
J'ai peur de mal comprendre là ?
des modèles concurrents ? c'est une blague ?
Comment peut-on réduire Gnu/Linux à un vulgaire produit concurrent ?
-
-
Copier les autres...
Copier les autres est une bonne chose en soi :
- les idées sont ce qui se copie le plus, alors autant en profiter,
- reprendre une idée intéressante pour en faire quelque chose de mieux est un bienfait pour ceux qui en bénéficient. Les logiciels libres sont exemplaires en ce sens puisqu'ils bénéficient à tous !
- GNU a bien copié Unix (puisqu'il en est justement question dans le sigle Gnu is Not Unix)
À ce dernier sujet, le système GNU, plus connu sous le nom Linux (héhé ;-), est aujourd'hui le rejeton de la famille Unix qui a le plus fort taux de croissance aussi bien en terme d'adoptants (utilisateurs, contributeurs...) que de technologies et d'innovations. À ce jour ce sont plutôt les Unix qui sont à la traine derrière le bulldozer Linux : IBM abandonne AIX, Compaq abandonne True64... pour ne prendre que quelques exemples.
Concernant la dépêche, il faut noter que non seulement O'Reilly est un éditeur connu pour ses ouvrages informatiques, mais aussi (et surtout) qu'ils sont de grands adoptants du libre :
- éditeur de prédilection pour les ouvrages sur Perl (notamment),
- ils ont déjà sorti des livres dont les contenus sont ouverts,
- ils organisent des événements autour du mouvement du libre.
Une typo s'est glissée dans la dépêche : plateforme au lieu de plate-forme.
-
[^]Re: Copier les autres...
Posté par LeMagicien Garcimore () le 24/03/2005 à 22:39. (lien). Évalué à 1.Une typo s'est glissée dans la dépêche : plateforme au lieu de plate-forme.
Non c'est bien plate-forme.-
[^]Re: Copier les autres...
Posté par R4f (page perso, ) le 25/03/2005 à 09:15. (lien). Évalué à 2.> Non c'est bien plate-forme.
C'est qu'est-ce que je dis : dans la news il est utilisé plateforme au lieu de plate-forme.
Ex. : dans ma traduction du Brave Gnu World : http://www.gnu.org/brave-gnu-world/issue-30.fr.html(...) (plate-forme et plates-formes ont été utilisées à plusieurs reprises).
-
liste d'applications basée sur mono
OSnews a publié , y a pas très longtemps, la listes des applications libres basée sur mono.
Parmis les plus intéressantes il y a Beagle, Tomboy, F-spot, monodevelop...
je pense que la technologie .net est très utile pour ce genre de projet.
Dans cette liste y a aussi GraphMonkey, c'est une calculatrice graphique que j'ai réalisé : http://graphmonkey.sourceforge.net/(...) :-)
-
[^]Re: liste d'applications basée sur mono
Posté par nolius () le 24/03/2005 à 19:49. (lien). Évalué à 2.j'ai oublié de mettre le lien vers la page osnews: http://www.osnews.com/story.php?news_id=9780(...)
Vers une division de GNU/Linux ?
Vers une division de GNU/Linux ?
Ça semble se profiler.
Novell pousse Mono et Red Hat pousse Java.
Novell fournira Mono et des petits programmes qui utilisent Mono, Red Hat ne le fera pas (et ni via Fedora Extra car il y a des problèmes (brevets, etc)).
Néanmoins Novell n'oublie pas Java mais :
- ne développe pas pour gcj, alors que Red Hat y est le paquet
- pousse JBoss alors que Red Hat pousse Jonas
On peut y voir simplement une façon de se démarquer, des raisons ""marketing"". Je n'y crois pas.
Red Hat a toujours été profondément pro-LL. A ce propos, Netscape Enterprise Suite acheté par Red Hat devrait être introduit dans Fedora (FC5) sous licence libre (la licence n'a pas été décidé mais elle sera libre). J'ignore si edirectory de Novell est libre.
Novell, bien que son virage vers le libre soit réussit et soit profitable au LL, a une culture logiciel propriétaire et développe/fournit encore beaucoup de logiciel propriétaire.
Je crois qu'il y a des enjeux majeurs dans cette guerre C#/Java !
Ces deux "géants" du logiciel libre s'affrontent dans un combat "à la vie, à la mort". Et je dirait "à la mort" du côté de Red Hat car dans le pire des scénario Novell peut toujours récupérer le boulot de Red Hat.
C# et .NET a des problèmes de brevets importants. De plus c'est MS qui est derrière et c'est pratiquement toujours un très mauvais signe.
MS ne dépose pas des brevets pour rien ! On le sait tous, l'histoire l'a déjà largement démontré. Lorsque que MS fait un truc, ce n'est pas pour permettre une "concurrence non-faussée" :-) (Le procès entre MS et l'Europe le prouve très clairement) ni pour aider le LL.
La FAQ de mono est "inquiétante" :
http://www.mono-project.com/FAQ:_Licensing(...)
Why does Novell require a copyright assignment?
When a developer contributes code to the C# compiler or the Mono runtime engine, we require that the author grants Novell the right to relicense his/her contribution under other licensing terms.
This allows Novell to re-distribute the Mono source code to parties that might not want to use the GPL or LGPL versions of the code.
Particularly embedded system vendors obtain grants to the Mono runtime engine and modify it for their own purposes without having to release those changes back.
Ça donne le droit à Novell de changer de licence. Ça parait anodin mais avec les brevets de MS ça ne l'ai plus.
Si MS utilisent ses brevets sur C# .Net, la version GPL de mono devient illégale et Novell peut décider de prendre une licence qui fait "plaisir" à MS. Peut-être toujours open source mais pas forcément dans l'esprit du logiciel libre, que j'espère on chérit tous ici.
Seth Nickell décrit les problèmes potentiels de mono :
http://www.gnome.org/~seth/blog/mono(...)
J'ai quelques questions (uniquement relatives aux brevets et non sur les mérites techniques) :
- Il y a-t-il de meilleurs infos que celles données par Seth Nickell ?
- Quelqu'un a-t-il un lien sur les problèmes que peut poser gcj et gnupath ?
- Il y a-t-il un comparatif entre les problèmes posé par mono et gcj/gnupath ?
Sur java, j'ai ça :
http://www.gnu.org/philosophy/java-trap.fr.html(...)
J'ai toujours apprécié le formidable MDI. Mais après m'être informé sur C#, ECMA, les brevets C#/NET, les conditions que fixent Novell pour l'ajout de code à mono, le crédit que j'avais pour MDI est en chute libre.
-
[^]Re: Vers une division de GNU/Linux ?
Posté par TImaniac (page perso, ) le 24/03/2005 à 21:52. (lien). Évalué à 2.Il y a-t-il de meilleurs infos que celles données par Seth Nickell ?
Oui, concrêtement il n'y a pas encore de brevets sur .NET, ils n'ont pas encore été validés.
Ensuite ils ne concernent qu'une petite partie de Mono, même pas les WinForms en fin de compte. Et comme le dis MDI : y'a les mêmes problèmes dans la plupart des gros projets libres.
Quelqu'un a-t-il un lien sur les problèmes que peut poser gcj et gnupath ?
Suffit de voir comment Sun a réagit fasse à l'incompatilbité de la VM de MS pour voir que Sun a encore tous les droits sur sa techno. ((C), TM, Patents, etc.)
En ce qui concerne le copyright assigné à Novell, je te ferais remarqué au passage que la FSF est une fondation fan de ce genre de pratique également, et qu'on peut très bien imaginer que si la fondation passe entre de mauvaises mains... (même si je n'y crois pas).
Concrêtement ce copyright est plutôt rassurant : Novell s'étant engager à payer les éventuelles licences si jamais il y avait un problème de brevet (donc je suppose qu'ils ont bien vérifier et qu'ils espèrent bien ne pas avoir un kopec à débourser), ce qui garantie une sorte de pérénité à Mono.
Sur la bataille entre Novell et Red Hat je suis tout à fait d'accord, j'espère juste qu'ils vont trouver un terrain d'entente, en facilitant par exemple l'intégration des 2 technos, coomme le font Sun/IBM et MS entre .NET et Java.-
[^]Re: Vers une division de GNU/Linux ?
Posté par Stéphane TRAUMAT (page perso, ) le 24/03/2005 à 22:04. (lien). Évalué à 1.Concrêtement ce copyright est plutôt rassurant
Disons que tu reprochais à Java d'etre trop lié à SUN (on en a déja beaucoup parlé)...du coup, Mono est plutot lié à Novell la non ?-
[^]Re: Vers une division de GNU/Linux ?
Posté par TImaniac (page perso, ) le 24/03/2005 à 22:07. (lien). Évalué à 2.Sauf que Mono est sous GPL et respecte des standards établies par un consortium indépendant. Au pire on fork et basta.
-
[^]Re: Vers une division de GNU/Linux ?
Posté par fabb () le 24/03/2005 à 23:18. (lien). Évalué à 0.> respecte des standards établies par un consortium indépendant.
Microsoft est un consortium indépendant qui établit des standards ?
Fun.
> Au pire on fork et basta.
Avec des brevets ?
Regarde du côté de mp3. Novell ne fournit pas de lecteur mp3 (cause brevets) alors qu'il y a des lecteur mp3 sous GPL.
Tu m'expliques ton "basta" ?-
[^]Re: Vers une division de GNU/Linux ?
Posté par Frédéric Lopez () le 25/03/2005 à 01:24. (lien). Évalué à 2.Regarde du côté de mp3. Novell ne fournit pas de lecteur mp3 (cause brevets) alors qu'il y a des lecteur mp3 sous GPL.
SUSE LINUX Professional 9.2
package descriptions
mpg321 - A Free Command Line MP3 player :
http://www.novell.com/products/linuxpackages/professional/mpg321.ht(...)
Sinon, d'après ce lien :
http://www.mars.org/mailman/public/mad-dev/2002-August/000721.html(...)
il ne semble pas évident que Thomson/Fraunhoffer détiennent des brevets sur l'encodage. En tout cas, ils n'ont visiblement jamais attaqué de projets libres sur ce terrain, donc je ne vois pas trop pourquoi il faudrait s'en inquiéter maintenant.-
[^]Re: Vers une division de GNU/Linux ?
-
[^]Re: Vers une division de GNU/Linux ?
Posté par fabb () le 25/03/2005 à 02:13. (lien). Évalué à 1.Il me semble que mp3 est gratuit pour décoder dans le cas d'une utilisateur non commerciale (malheurement, je ne connais pas d'engagement formel).
Par contre mp3 est payant dans tous les autres cas.
Cherches lame (ou équivalent) pour Novell. Si tu le trouves, je ferme ma gueule.
Par exemple, j'ai regardé le paquet glame et j'ai :
%configure --disable-mp3lame-
[^]Re: Vers une division de GNU/Linux ?
Posté par Frédéric Lopez () le 25/03/2005 à 12:32. (lien). Évalué à 2.Il me semble que mp3 est gratuit pour décoder dans le cas d'une utilisateur non commerciale (malheurement, je ne connais pas d'engagement formel).
Non, c'est seulement pour la diffusion ou le streaming de MP3 si on en croit Thomson/Fraunhoffer, voir : http://www.mp3licensing.com/help/developer.html(...) . En même temps, ils disent en gros qu'il faut payer des licenses dès que le mot MP3 apparaît quelque part, difficile de leur faire confiance à ce sujet. D'autant qu'il n'est toujours pas évident qu'ils aient des brevets sur le décodage MP3.
Cherches lame (ou équivalent) pour Novell. Si tu le trouves, je ferme ma gueule.
Lame est un encodeur, pas un décodeur. Tu avais parlé de lecteurs MP3 dans ton précédent post, c'est pour ça que j'avais réagi. La librairie Lame n'est probablement pas dans SuSE, tout comme elle n'est pas dans Debian.
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.