Articles précédents : Articles
- [85] Guide des prestataires
- [27] GNU/Linux Magazine Hors Série : Haute disponibilité
- [64] Sortie du noyau 2.6.4
- [2] Création d'un club de développement collaboratif pour OpenOffice.org
- [386] Mandrake Linux 10.0 Community disponible au téléchargement
- [11] Arrêt du projet FreeS/WAN
- [7] Un nouveau site pour débutants à GNU/Linux
- [19] Article francophone sur l'utilisation de Subversion
- [2] Solutions 2004 : appréciez l'expérience PHP
- [49] Java libre : Sun sur la défensive
Articles : Havoc Pennington se pose des questions sur les langages du libre
Posté par Aurélien Bompard (Jabber id, page perso, ). Modéré le 18 mars 2004.
Les réflexions sont très nombreuses, et impossibles à résumer ici, mais on peut dire que l'objectif principal de son article est d'inciter la communauté du logiciel libre à choisir l'attitude à adopter envers Java et .NET.
![[en]](../../../images/en.png)
L'article (2572 hits)-
La news sur gnomedesktop.org (615 hits)
> Lire la suite (244 commentaires, moyenne: 1,3). [dépêche : 421 caractères]
Attention, ce texte est potentiellement un nid à trolls. Blindez vos trollomètres, et essayons d'avoir le même objectif que Havoc : être constructif.
Re: Havoc Pennington se pose des questions les langages du libre
IL évacue quand même bien rapidement la question de Perl, Python et Ruby, vous ne trouvez pas ? Je veux bien qu'à son avis ils ne soient pas adéquats mais il faudrait encore expliquer pourquoi.
Pour ma part j'ai beaucoup programmé en Java, et maintenant je programme beaucoup en Ruby. J'ai du mal à voir en quoi ce dernier est moins intéressant pour développer un bureau. On pourrait dire qu'il est plus lent que Java, c'est vrai en théorie, mais subjectivement je n'ai pas la même impression de lourdeur quand je lance un programme Ruby que quand je lance un programme Java.
Idem pour Python, dont on entend beaucoup de bien et qui, si j'ai bien compris, serait plus facilement optimisable, voire compilable (confirmation ?).
Si on ajoute que ces langages sont libres et de plus haut niveau que Java (en tout cas beaucoup plus agréables à utiliser pour le programmeur), je ne vois pas trop d'arguments contre. Hmm, c'est pas compilé, c'est un argument ça ? :-)
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par wilk (Jabber id, page perso, ) le 18/03/2004 à 08:29. (lien). Évalué à 5.Pour couper court les poils du troll sur la lenteur des langages de scripts :
On se fout un peu qu'ils soient lent ou pas quand ils savent s'appuier au moment oportun sur des librairies natives. Il ne faudrait donc pas comparer la vitesse des langages mais plutôt la vitesse des librairies sur lesquelles il peut s'appuier.
L'erreur de java à été d'essayer de faire tout tout seul, d'où les lourdeurs qu'on connait alors que le langage en lui même est relativement rapide finalement.
Ceci n'empêche pas que python fasse bcp pour améliorer ses performances, du fait d'une menace d'attaque par tarte à la crème interposée ! Mais la condition reste que les améliorations ne doivent pas rendre la maintenance du langage problématique (ce qui est encore une différence avec java par ex)-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par L () le 18/03/2004 à 08:44. (lien). Évalué à 1.> L'erreur de java à été d'essayer de faire tout tout seul, d'où les lourdeurs qu'on connait alors que le langage en lui même est relativement rapide finalement.
Je m'attendais plutôt à quelque chose comme "d'où JNI pour mieux intégrer Java". Au fait, ça veut dire quoi un "langage rapide" ? :)-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par LupusMic (page perso, ) le 18/03/2004 à 09:19. (lien). Évalué à 2.Un langage, ce n'est pas seulement la spécification de sa syntaxe, mais aussi la spécification de son implémentation (pour des raisons de compatibilité).
Par exemple, une différence fondementale entre le C et le Pascal sont l'empilement des arguments, de la valeur de retour et de l'adresse de retour. Ils ne le font pas dans le même ordre.
Donc, oui, un langage peut être plus rapide suivant la spécification de son implémentation !-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 18/03/2004 à 10:54. (lien). Évalué à 5.D'ailleurs parmi les langages qui sont à la fois, bien implémentés, spécifiés, et optimisés (tant au niveau du code généré que de la rapidité de compilation).. faudrait pas oublier OCaml !
Certes c'est pas aussi "pratique" que Python .. mais question fiabilité et vérification du code.. le compilo est très très fort.
et en plus c'est francais :-)-
[^]Re: Havoc Pennington se pose des questions les langages du libre
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par yxorp () le 21/03/2004 à 23:13. (lien). Évalué à 1.
D'ailleurs parmi les langages qui sont à la fois, bien implémentés, spécifiés, et optimisés (tant au niveau du code généré que de la rapidité de compilation).. faudrait pas oublier OCaml !
Certes c'est pas aussi "pratique" que Python .. mais question fiabilité et vérification du code.. le compilo est très très fort.
Certes, mais quelques menues explications et références seraient les bienvenues plutôt qu'un banal "trollotage" du genre regardez mon langage, comment qu'il est l'plus fort !
(C'est fou ce qu'on invente comme mots quand on passe un tant soit peu de temps sur cette tribune :)
et en plus c'est francais :-)
\_0< CocoricooOoo !
-
-
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez () le 18/03/2004 à 08:49. (lien). Évalué à 4.Te plains pas, il y a un langage dont il ne parle même pas (peut-être ne sait-il pas qu'il existe :-)), l'Objective-C.
C'est un langage très rapide, très évolué et comparable (à mon avis) à Java et à .NET.
Avec cependant un gros avantage : il possède un framework éprouvé, simple à utiliser et complet sans être trop lourd (ce framework c'est GNUstep, qui répond aux specs OpenStep, comme Cocoa de MacOS X).-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par puxor () le 18/03/2004 à 08:58. (lien). Évalué à 4.objective-C ne se compare pas à .NET, car .NET n'est pas un langage mais une infrastructure (enfin on appelle ça comme on veut). À la limite, on pourrait le comparer à C#
Il est clair que la prise en compte de gnustep serait pas mal, surtout avec la compatibilité macosx (il me semble que cocoa n'est pas équivalent à gnustep ou openstep mais juste une partie du moteur de l'interface)-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez () le 18/03/2004 à 09:04. (lien). Évalué à 1.En effet, je mélange tout pour aller plus vite. Je penses de toutes façons que les langages sont associés à leurs frameworks respectifs, sauf pour le C++ qui en possède plusieurs.
Par contre pour cocoa, je ne crois pas m'être trompé, car la doc du framework se trouve sous cocoa sur le site d'Apple.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par puxor () le 18/03/2004 à 09:22. (lien). Évalué à 1.tu as raison :) (http://developer.apple.com/cocoa/(...))
-
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par matli () le 18/03/2004 à 09:02. (lien). Évalué à 2.D'ailleurs, n'était-ce pas le langage qui avait été envisagé dès le début de Gnome? Je suis en tout cas d'accord avec toi, cette solution semble vraiment intéressante de part le langage lui même, mais également de part le framework déjà disponible, et bien entendu parce qu'il n'est pas encombré de problème de brevet, de PI, de licence..., bref, parce qu'il est libre!
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez () le 18/03/2004 à 09:07. (lien). Évalué à 1.Ce langage possède peut-être quand même un petit souci :
Apple peut rajouter des specs à OpenStep, étant propriétaire.
Si GNUstep se rapproche trop d'eux, ils pourront facilement allourdir les specs de manière à limiter la compatibilité, en se basant sur la lenteur de développement (par rapport à la leur).-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par puxor () le 18/03/2004 à 09:28. (lien). Évalué à 1.Je ne pense pas qu'Apple s'amuse à rajouter beaucoup d'extensions à cocoa, leur interêt est d'avoir un environnement stable (niveau évolution, pas stabilité) s'ils veulent attirer les entreprises.
De plus (pour l'instant) la migration se fait plutôt dans le sens gnustep->cocoa que dans l'autre, et dans ce cas le rajout d'extensions à gnustep ne me paraît pas être dangereux, c'est dans l'autre sens que ça peut devenir un problème. Je ne crois pas que des entreprises soient intéressées (pour l'instant) par le portage d'applis macosX sous linux, encore que ça doublerait leurs parts de marché. La compatibilité va plus intéresser tous les geeks qui ont un ibook par exemple, encore faut-il que des killer-apps soient fait sous gnustep... mais ça fait tellement longtemps qu'on attend...-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Michel Galle () le 18/03/2004 à 09:52. (lien). Évalué à 1.gnumail ? :)
sinon, si des applications comme "omnigraffle" ou "cssedit", "poisonned" était porté à linux/bsd/gnustep, jserai fou :)
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Michel Galle () le 18/03/2004 à 09:59. (lien). Évalué à 5.>Apple peut rajouter des specs à OpenStep, étant propriétaire.
"openstep" n'est pas qu'à apple, faudrait vérifier ce qu'il en est de leur accord avec sun.
openstep a été normalisé avec NeXT et Sun.
depuis openstep, cocoa a rajouté quelques extensions, les plus visibles sont les "feuilles", et les "drawers". l'api a eu qq ajouts et améliorations aussi.
notons que cocoa a toutes ses classes prètes pour java aussi.
et oui, ils peuvent limiter la compatiblité en ajoutant a tout va des nouveautés, mais cela peut se retourner contre eux, en aliénant les developpeurs macs.
sinon, Havoc ne dit pas de simplement "suivre tout le temps". il explique que Gnome pourrait utiliser l'une de ces fondations, utiliser "officiellement" un langage plus évolué, mais pas forcément de chercher a rester compatible à tout va.
exemple :
c# et mono : ok MAIS gnome utiliserait en fait Gtk#, qui n'a que peu de rapports avec les classes .NET winforms etc sur windows.
java : la jvm etc, ok, mais pas swing, mais les classes java-gtk java-gnome etc
objective-c : pourquoi pas après tout ? objective-c est un beau langage, gnustep est découpé en 2 blocs en gros, fondation et appkit, nul n est obligé d'adopter appkit totalement parce que objective-c est intéressant, de nouvelles classes "gnome" pourrait etre ecrites en objective-C sans chercher a etre identiques a "cocoa".
bref , havoc cherche a promouvoir le choix de _un_ langage/framework plus évolué que C comme evolution de gnome, mais pas de dire "migrons à bidule et soyons compatible à vie"-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez () le 18/03/2004 à 10:10. (lien). Évalué à 1."openstep" n'est pas qu'à apple, faudrait vérifier ce qu'il en est de leur accord avec sun.
openstep a été normalisé avec NeXT et Sun.
Ils ont quand même déjà ajouté NSDocument et NSDocumentController.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Nicolas Roard (page perso, ) le 18/03/2004 à 16:08. (lien). Évalué à 2.notons que cocoa a toutes ses classes prètes pour java aussi.
Yep, mais bon, peu de monde les utilisent. C'est assez barbare à mon avis, il est beaucoup plus sympa d'attaquer Cocoa en Objective-C qu'en Java.
Ceci dit, GNUstep propose également des bindings Java hein.
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
-
-
-
-
-
[+] [^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par qbeek () le 18/03/2004 à 08:53. (lien). Évalué à -1.Perso je ne crois pas que Perl soit fait pour cela, la gestion des objets est un peu lourde. Ne connaissant pas Ruby, je crois que le Python est le langage qu'il faut.
- Il n'a pas de problème de licence car il est sous GPL.
- Sa dynamique de développement me semble bonne.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Pascal Terjan (Jabber id, page perso, ) le 18/03/2004 à 10:11. (lien). Évalué à 6.Ne connaissant pas Ruby, je crois que le Python est le langage qu'il faut.
Tu rates quelque chose :-)-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par reno () le 18/03/2004 à 13:36. (lien). Évalué à 1.Si je me souviens bien Ruby ne gere pas l'unicode, non?
Je ne suis pas sur non plus que le support des thread soit "fini"..
C'est un peu génant pour un projet comme Gnome, non?-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Erwan (page perso, ) le 18/03/2004 à 16:58. (lien). Évalué à 1.Si je me souviens bien Ruby ne gere pas l'unicode, non?
Ruby est fait par un japonais, par consequent au niveau des encodages il est nickel. Il gere bien sur l'unicode.
Le coup des threads, j'en sais rien.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Guillaume Laurent (page perso, ) le 18/03/2004 à 21:46. (lien). Évalué à 1.Ruby est fait par un japonais, par consequent au niveau des encodages il est nickel. Il gere bien sur l'unicode.
Tu es sur ? :-) Verifie bien. Si tu as une URL qui prouve que Ruby supporte l'Unicode, je suis interessé.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par fredix (Jabber id, page perso, ) le 18/03/2004 à 22:55. (lien). Évalué à 1.libpango1-ruby - Pango bindings for the Ruby language
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Guillaume Laurent (page perso, ) le 19/03/2004 à 11:04. (lien). Évalué à 1.Quel rapport ? C'est Pango qui gere l'unicode, pas Ruby.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par fredix (Jabber id, page perso, ) le 19/03/2004 à 21:37. (lien). Évalué à 1.Et alors, il y a quoi de génant d'utiliser pango ?
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Guillaume Laurent (page perso, ) le 19/03/2004 à 23:19. (lien). Évalué à 1.Comme on dit dans ces cas là : "si tu poses la question, c'est qu'il ne sert à rien de te répondre".
-
-
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Erwan (page perso, ) le 19/03/2004 à 07:05. (lien). Évalué à 1.J'ai pas d'URL sous la main, j'ai la flemme de chercher, mais je me suis servi de Ruby pour decouper en morceaux et appliquer quelques operations a un dico japonais->francais qui etait sous forme d'un ficher texte, en unicode.
Et ca a tres bien marche.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Guillaume Laurent (page perso, ) le 19/03/2004 à 12:34. (lien). Évalué à 1.je me suis servi de Ruby pour decouper en morceaux et appliquer quelques operations a un dico japonais->francais qui etait sous forme d'un ficher texte, en unicode.
Et ca a tres bien marche.
Ben oui, tu manipules toujours des bytes, ca ne veut pas dire que Ruby supporte l'unicode :-). Tu as essaye d'appliquer des regexp dessus, ou de faire des regexps en unicode ?
(et pour info, non, les strings Ruby ne sont pas en Unicode, et y a rien dans Ruby pour gerer l'Unicode. Ca m'a surpris aussi mais c'est pourtant vrai).
-
-
-
-
-
-
[+] [^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par gallenza () le 18/03/2004 à 15:06. (lien). Évalué à -2.J'adore Python et je pense qu'il serait très adapté, mais il n'a jamais été et ne sera à mon avis jamais GPL.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Jar Jar Binks (page perso, ) le 18/03/2004 à 16:08. (lien). Évalué à 0.La licence de Python est compatible GPL depuis python 2.1.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
-
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par VACHOR (page perso, ) le 18/03/2004 à 17:42. (lien). Évalué à 1.Un petit bench pour alimenter la bête poilue : http://www.osnews.com/story.php?news_id=5602&page=3(...)
Etonnant non ?!?-
[^]Re: Havoc Pennington se pose des questions les langages du libre
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Sebastien Tanguy (page perso, ) le 18/03/2004 à 21:33. (lien). Évalué à 2.Moi aussi, je peux sortir un benchmark à la con... Traiter un fichier texte avec des regexp est 5 fois plus rapide en perl et 2 fois plus rapide en python qu'en java, quelque soit la JVM ou les composants regexps utilisés...
Donc tout dépends de ce qu'on fait du langage... À chaque tâche son outil...
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Beretta_Vexee () le 18/03/2004 à 20:18. (lien). Évalué à 1.Je ne parlerais que de Python language que je connais le mieux dans la liste, oui python est plus lent voir beaucoup plus lent pour certain taches que les languages compilés, mais il a pour lui une trés grande facilitée d'utilisaiton et une bonne integration des autres languages.
De plus oui il est possible d'optimiser du code python en le transformant en java via Jython, en utilisant divers librairies comme Psyco ou autre, mais il reste tous de même plus lent que les autre de part sa nature interpretée.
Mais est ce réellement un probléme ?
Pour un noyau ou une bibliotheque graphique surment, mais il y a beaucoup d'autre domaine ou la facilitée de developpement et la rapiditée de developpement sont des attouts bien plus important.
Personnellement, ce qui me fait aimer pyhton et paradoxalement un des points qui rebute beaucoup de monde, c'est son indentation trés stricte, qui fait maintient une lisibilitée du code trés appreciée quand l'on bosse a 4 sur les même fichier ;-)--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Amand Tihon (page perso, ) le 18/03/2004 à 21:29. (lien). Évalué à 1.Je vais rejoindre un peu ce que tu dis ici.
En tant que codeur, j'adore le Python depuis que je m'y suis mis : concision, clarté (bon, on peut aussi faire du python illisible), indentation stricte, et surtout rapidité de développement assez spectaculaire.
En tant qu'utilisateur de mes propres réalisations (un daemon type mrtg, quelques GUI, des scripts pour me simplifier la vie), la vitesse d'exécution ne m'a jamais parue pénalisante.
Par contre, je pense que son inconvénient majeur est la quantité de mémoire nécessaire. Je suis en train de faire un client bittorrent en Python/Qt : c'est tout de suite 35 Mo de RAM utilisés avant même d'avoir ajouté un torrent (dont 30 Mo en "shared", mais je ne sais pas quelle quantité est effectivement partagée).-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par manatlan (Jabber id, page perso, ) le 18/03/2004 à 22:35. (lien). Évalué à 1.ca c'est l'effet QT ! c tout
en wx c 10mo
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Tennis Prono (page perso, ) le 19/03/2004 à 08:05. (lien). Évalué à 1.mais je ne sais pas quelle quantité est effectivement partagée
Test à deux balles: tu fais un "free" en ligne de commande et tu notes "used -/+ buffers/cache". Tu lances ton programme et tu notes la nouvelle valeur. Puis tu refais le test avec un programme Qt déjà lancé. Et la même chose avec un programme Python.--
Pas de bureau 3d libre sans drivers libres!
-
-
Re: Havoc Pennington se pose des questions les langages du libre
Vu que le troll sur les bières n'a pas pris sur GTK, on devrait peut-être le retenter ici ;)
Sérieusement, cet article ne me semble pas à ce point un nid à troll. Je dirais même que venant de Havoc Pennington, je suis un peu déçu, vu que je trouve son article très modéré et argumenté... mais peut être trop lisse et enfonçant des portes ouvertes. Bref, un bon point de départ pour le débat, mais pas le débat lui-même.
Peut-être qu'on devrait demander à MDI une réponse officielle ;)
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
-
[+] [^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Code34 (page perso, ) le 18/03/2004 à 12:34. (lien). Évalué à -1.C'est évidement un nid à troll.
Quand les développeurs ont quelque chose à faire, ils savent quel langage utiliser. Chaque langage a son utilité par rapport à un objectif à atteindre (je ne parle pas du java car chaque rêgle a aussi son exception).
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Yusei () le 18/03/2004 à 08:31. (lien). Évalué à 1.C'est pas tant ses arguments que le choix des deux plateformes proposées, qui est un nid à troll :-)
D'autant plus que si j'ai bien compris (j'ai lu ça hier un peu dans le brouillard, et là je dois partir), il envisage l'adoption de Mono mais pas des parties dépendant de MS... ce qui fait perdre beaucoup de son intérêt à Mono (plus moyen de lancer les applications faites pour Windows.NET®©).
Après, le fait d'adopter un Java version libre, pourquoi pas, même si j'ai des raisons (techniques) de n'aimer ni le langage ni la plateforme, ce sont des opinions sujettes à débat/troll, au choix :-)-
[+] [^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par TImaniac (page perso, ) le 18/03/2004 à 09:29. (lien). Évalué à -2.oui tu as du lire dans le brouillard.
L'ambition est double, il y a 2 "piles" d'API pour mono : d'un côté ils essai d'avoir un vrai toolkit pour gnome et de l'autre une compatibilité avec Microsoft pour faciliter la migration des futurs appli que les développeurs sous Windows vont bientôt devoir programmer à l'aide de .NET (because longhorn)...
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Black Fox (page perso, ) le 18/03/2004 à 17:55. (lien). Évalué à 1."D'autant plus que si j'ai bien compris (j'ai lu ça hier un peu dans le brouillard, et là je dois partir), il envisage l'adoption de Mono mais pas des parties dépendant de MS... ce qui fait perdre beaucoup de son intérêt à Mono (plus moyen de lancer les applications faites pour Windows.NET®©)."
Mono est une implémentation des spécification de la plateforme .Net (Compilateur Just In Time, Langage intermédiaire et compilateur C# -> Langage intermédiaire)
Mais Mono inclus aussi les librairies Microsoft, des bindings pour pouvoir utiliser windows.form et autre... Et ne comptent pas l'abandonner.
Ce que cherche Gnome est évidement un langage, le toolkit derière ils l'ont deja : GTK.
Donc Mono est une proposition tout autant que Java ce qui est normal (Bien que Objective-C, Python et Ruby devrait être serieusement envisagés à mon avis) apprès chacun peut tenter du FUD sur le fait que la spec ait été faite par microsoft... (Je rapelle pour les trolleurs habituels que microsoft as choisi un organisme de normalisation qui impose que les brevets ne puissent pas empécher l'utilisation de la norme)
Quant aux parties spécifiques de toute façon elles ne sont pas utilisables et n'ont même pas été normalisés (Mono les implémente et donc risque des problèmes sur ce point là et ils en sont concients) windows.form contiens par exemple la boucle des messages windows ce qui sous autre chose (GTK, QT) ne veut strictement rien dire.-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Erwan (page perso, ) le 19/03/2004 à 07:09. (lien). Évalué à 1.Mais Mono inclus aussi les librairies Microsoft, des bindings pour pouvoir utiliser windows.form et autre... Et ne comptent pas l'abandonner.
Les bindings windows.form (qui se basent sur wine pour l'affichage des widgets windows, d'ailleurs) c'est juste un "bonus", le noyau de Mono c'est la partie standard. D'ailleurs, ils disent bien qu'en cas de problemes juridiques ils pourront toujours abandonner les parties qui posent probleme (ce qui ne peut pas arriver a la partie standard). Mono servira principalement a utiliser Gtk#.
Au pire, il n'y aura pas de compatibilite entre .net et mono, ce qui ne veut pas dire que mono n'aura pas d'interet.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Brice Carpentier (Jabber id, page perso, ) le 20/03/2004 à 08:44. (lien). Évalué à 2.Je rapelle pour les trolleurs habituels que microsoft as choisi un organisme de normalisation qui impose que les brevets ne puissent pas empécher l'utilisation de la norme
Ce n'est pas exact.
L'ISO n'empêche en rien l'utilisation de la norme par des brevets.
L'ECMA impose que la licence d'utilisation des brevets soit "non-disciminatoire".
Oui, mais même avec un prix particulièrement non-disciminatoire du genre 0.01, il devient impossible de livrer un soft GPL basé sur ces brevets, car les utilisateurs ne pourront plus librement copier le logiciel (cherchez la clause 7 de la GPL).
Just my 2¢
Ps : l'explication n'est pas de moi, je l'ai lu sur la ML mono-list et j'ai très bien pu en déformer une partie par mégarde, mais le sens doit être là.--
Développeur OpenSource-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par TImaniac (page perso, ) le 20/03/2004 à 10:23. (lien). Évalué à 0.Non l'ECMA empêche toute exploitation commerciale des brevets. Bref, Microsoft ne peut demander le moindre kopec à Novell pour Mono.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Brice Carpentier (Jabber id, page perso, ) le 21/03/2004 à 21:11. (lien). Évalué à 1.Du tout.
L'ECMA indique clairement le terme "reasonnable".
Ils sont actuellement en train de faire une "legal review" à ce propos justement...--
Développeur OpenSource-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par TImaniac (page perso, ) le 22/03/2004 à 08:24. (lien). Évalué à 1.l'ECMA implique notamment "royalty free" et "non-discriminatory"
-
-
-
-
-
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Christophe Fergeau () le 18/03/2004 à 08:56. (lien). Évalué à 1.En fait, il y a quand même certains trous dans son argumentation, en particulier en ce qui concerne ses interrogations au sujet de .NET et des brevets, comme le souligne MDI par ex ( http://primates.ximian.com/~miguel/all.html#3%2F18%2F04%202%3A00%3A(...) ), Sun a probablement breveté certains bouts des API de Java.
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par TImaniac (page perso, ) le 18/03/2004 à 09:26. (lien). Évalué à 0.MDI a à travers ce post bien résumé la situation, sans réellement annoncer des certitudes quand aux problèmes des brevets. La conclusion donne par contre son avis sur la situation :
But this is similar to what happens to biology students: on their first
four semesters as they learn about all the dangers, infections, vectors
for infections and bacteria, they stop eating everything, they start
washing their hands with special products, they double clean their
utensils, they wash their fruits ten times a day.
Two years later they are eating food with their bare hands again.
Tout est dit...
-
[+] Re: Havoc Pennington se pose des questions les langages du libre
Sa réflexion semble au final plus se porter sur la façon de faire du tort à Microsoft plutôt que sur l'interet purement technique des langages.
C'est une approche un peu partisane qui n'est pas necessairement des plus pertinentes...
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par Michel Galle () le 18/03/2004 à 10:15. (lien). Évalué à 4.non
il dit qu'il veut éviter de favoriser microsoft au DETRIMENT du libre
qu'on le veuille ou non, OUI TOUT EST PARTISAN, en particulier la communauté GNOME est partisan _du libre_
et si on estime que microsoft fait tout pour empècher le simple _emploi_ du libre, alors oui, ils sont anti microsoft.
mais c'est seulement ds ces cas là
et encore une fois, utiliser MONO, ne veut _pas_ dire utiliser tout .NET et partir à vie dans la compatibilité des classes .net windows
gtk# !
heu au fait, la maturité et l'adoption de gnome ou kde et du libre en général fait du tort à microsoft. ben vi.
cela fait "moins" de tort à des entreprises comme sun ou ibm parce qu'elles essaient de composer avec. donc on se formalise pas sur elles.
>C'est une approche un peu partisane qui n'est pas necessairement des plus >pertinentes...
Havoc a absolument pas orienté son commentaire en "tuons microsoft", sinon il ne tolererait meme pas l'usage de gtk# par quelques applications en préparation ds gnome.
bref : hors sujet!-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par nicolassanchez () le 18/03/2004 à 10:20. (lien). Évalué à 2.heu au fait, la maturité et l'adoption de gnome ou kde et du libre en général fait du tort à microsoft. ben vi.
Suffit de voir comme Microsoft attaque Linux par tous les moyens...
voir http://www.microsoft.com/france/lesfaits(...) pour comprendre qu'ils ont peur...
-
[^]Re: Havoc Pennington se pose des questions les langages du libre
Posté par kerokero (page perso, ) le 19/03/2004 à 08:01. (lien). Évalué à 0.Combining Java and Linux is interesting from another standpoint: it merges the two major Microsoft-alternative platforms into a united front.
How Quickly Can .NET Win?
Plutôt guerriers comme tournures de phrases non ?
Et 18 fois on trouve le mot "microsoft" dans son article.
On ne me fera donc pas croire qu'il n'oriente pas ses choix techniques en fonction de cet aspect des choses.
Ce ne sont plus des arguments techniques objectifs à partir de ce moment la. Il en a parfaitement le droit. Mais à titre personnel je ne trouve pas ça très pertinent.
-
Le titre ne veut rien dire
"Havoc Pennington se pose des questions les langages du libre"
Il manque un mot? (je penche pour "SUR les langages du libre")
honnêtement, des erreurs comme ça ne devraient pas passer. Je veux bien que les modéros manquent de temps, mais quand même.
(tant que je suis à pinailler, j'aurai enlevé "à choisir l'attitude" ça alourdit la dernière phrase pour rien, mais bon, je pinaille...)
Ce serait vraiment bien de pouvoir faire ce genre de commentaires à part.
Déjà, ça n'apporte rien aux lecteurs. Seuls les modéros devraient pouvoir lire ces remarques. De plus, ça oblige les modéros à à lire les commentaires du site alors qu'ils peuvent avoir d'autres choses à faire (au hasard, modérer des news :)
Le mail @modérateurs n'est pas à mon avis une solution (y'a déjà assez de news en attente pour en plus noyer les modéros sous 36 mails pour des fautes d'orthographe)
Avant on pouvait cocher son commentaire à -1 directement pour qu'il ne soit pas affiché, c'était bien car ça permettait d'éviter aux visiteurs la lecture d'un commentaire inintéressant. Ça manque vraiment.
En fait ce qui serait vraiment bien, c'est une tribune supplémentaire qui ne soit pas en première page mais qui apparaisse sur la page d'admin, pour que les modéros puissent facilement la consulter.
Exemple de cas d'utilisation: je lis une news, j'aperçois une faute. Dans une boîte supplémentaire quelque part sur la page de commentaires, j'ai un lien pour examiner la tribune de correction (histoire de pas poster la même remarque 42 fois) et un textbox pour taper la remarque. Le titre de la news pourrait apparaître automatiquement en début de post pour que ce soit plus clair.
Je crois pas que ce soit optimal, et je suis sûr qu'en cherchant un peu on trouverait une meilleure solution, mais je pense que ça permettrait:
1. d'éviter à tout le monde ces commentaires inutiles,
2. de faire gagner du temps au modéros (s'il y en a qui parcourrent vraiment les commentaires à la recherche de ce genre de remarques)
3. d'augmenter la qualité des news grâce à la correction d'erreurs plus rapide et plus efficace.
Bon après pour ce qui est de coder, temp1337 c'est pas mon truc, ça me fait mal à la tête quand j'essaie de le lire
-
[^]Re: Le titre ne veut rien dire
Posté par Mathieu Pillard (page perso, ) le 18/03/2004 à 09:06. (lien). Évalué à 1.> Avant on pouvait cocher son commentaire à -1 directement pour qu'il ne soit pas affiché
Une idee comme ca si quelqu'un me lit: faudrait permettre a n'importe qui de voter pour soi-meme lorsque le vote est negatif... Ca devrait pas etre compliqué a faire, si ?-
[^]Re: Le titre ne veut rien dire
Posté par Arachne (page perso, ) le 18/03/2004 à 17:09. (lien). Évalué à 1.C'est faisable ("Envoie un patch"), mais je doute sérieusement du bien fondé de la chose : Si un commentaire est négatif c'est que la majorité des votants veulent le dissimuler, et donc ce serait clairement s'opposer au système actuel. L'absurdité de la chose me travaille... Pourquoi veux tu donc pouvoir faire ça ?
-
[^]Re: Le titre ne veut rien dire
Posté par Black Fox (page perso, ) le 18/03/2004 à 17:59. (lien). Évalué à 1.Parfois on veut poster quelquechose de marant ou lancer un troll pour s'ammuser et on se dit que ce serait bien qu'il commence à -1 comme ça les gens qui cherchent des discussions intéressantes ne l'auront pas en plein milieu.
-
[^]Re: Le titre ne veut rien dire
Posté par Arachne (page perso, ) le 18/03/2004 à 18:47. (lien). Évalué à 1.Hmmm à la lecture de ton post je me rends compte que je n'avais pas compris le message précédent. Je pensais qu'il voulait pouvoir plussoyer alors que son score est négatif, et non se moinssir volontairement. Donc rien à voir avec la choucroute.
En effet le rétablissement du -1 serait une bonne chose pour pouvoir troller sans se faire descendre, mais peut-être est-ce justement ce que les admins ne veulent pas ? :)
-
-
-
[+] Re: Havoc Pennington se pose des questions les langages du libre
C'est n'importe quoi ces débats sur ces langages de haut niveau... il n'y en a qu'un seul, un vrai, qui en qq lignes peut correspondre à des projets de centaines de millier de ligne de code en java ou aute : l'indien. Le seul problème est qu'il prend quelques $$$ en paramètre :-)
On oublie toujours OCaml
Encore une fois, lorsque l'on parle de langage de haut-niveanx performants, on
oublie OCaml : www.caml.inria.fr
Et pourtant, ce langage a de très nombreux avantages, mais il reste confiné dans son image de langage de chercheur sans intérêt. Rappelons quand même que ses inventeurs étaient à la base des hackers C (juste comme ça, Xavier Leroy a réalisé une ancienne implémentation de la bibliothèque thread de Linux...).
Alors, pour ne citer que quelques uns des avantages de ce langage qui gagne à être connu :
- il est libre
- c'est un langage formelle (de la famille de ML), avec la puissance d'expressivité que cela engendre
- néanmoins, il implémente des notions de langages impératifs, en particulier pour tout ce qui est gestion système (entrée/sorties, etc)
- il possède une couche objet (d'où le 'O' de Ocaml ;)
- il peut être compilé en byte-code ET nativement
- son compilateur est très bon, et implémente toutes les caractéristiques des compilateurs modernes de langages de haut niveau (garbage collector efficace entre autre)
- il peut utiliser les bibliothèques C
- il possède un système de modules formidables : les modules peuvent être paramétrés par d'autres modules, je vous laisse imager la puissance de la chose...
-Xavier Leroy est un mec passionnant à écouter (hmm... bon un peu HS :)
Bref, c'est un langage auquel la communauté aurait intéret às'intéresser, même s'il demande un petit effort d'adaptation au mécanisme formelle (mais une fois que le coup est pris, on ne peut plus s'en passer. Et puis on ne va âs se comporter en immobilistes frileux de sortir des sentiers battus du C/C--...)
-
[^]Re: On oublie toujours OCaml
Posté par Colin Leroy (page perso, ) le 18/03/2004 à 09:17. (lien). Évalué à 4.Et pourtant, ce langage a de très nombreux avantages, mais il reste confiné dans son image de langage de chercheur sans intérêt. Rappelons quand même que ses inventeurs étaient à la base des hackers C (juste comme ça, Xavier Leroy a réalisé une ancienne implémentation de la bibliothèque thread de Linux...).
C'est toujours celle de la glibc, si je ne me trompe (mais c'est plus lui qui la maintient) : http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
(HS mais bon... je peux pas résister: c'est mon oncle ;-))-
[^]Le deuxième effet OCaml
Posté par HappyCrow () le 18/03/2004 à 21:32. (lien). Évalué à 1.D'autres posts de cette page rappellent les qualités techniques de OCaml
(concision de la syntaxe, vitesse d'exécution, etc.).
Outre ces qualités importantes: n'oublions pas les qualités
liées à la présence d'un interpréteur (comme c'est le cas pour LISP,
perl, python...).
Grâce à l'interpréteur on peut tester à chaud chacune des fonctions développées
(en purement fonctionnel, tous les programmes sont des fonctions).
On élabore ainsi en même temps le programme et ses tests.
C'est à mon avis beaucoup plus confortable que les langages
uniquement compilés
(OCaml est compilable _ET_ interprétable):
En C ou en Java on fait édition puis compilation puis édition des
tests puis compilation des tests puis tests.
Avec un langage muni d'un interpréteur on fait
édition et tests en même temps, sans avoir à programmer les tests:
on les appelle uniquement depuis l'interpréteur.
Et _ça_, pour la vitesse de développement que ça entraine, c'est du
"killer feature" mes amis! :O)
P.S: le compilateur ocaml dérecursivise les fonctions récursives
terminales, ainsi vos fonctions écrites en purement fonctionnel
s'éxécutent en temps et place constante. Les compilateurs scheme
savent aussi faire cela.-
[^]Re: Le deuxième effet OCaml
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 18/03/2004 à 21:57. (lien). Évalué à 1.En anglais c'est les functions appellées "tail recursive" ...
-
[^]Re: Le deuxième effet OCaml
Posté par cykl (Jabber id, ) le 19/03/2004 à 00:33. (lien). Évalué à 1.Oui et la plupart des compilateurs modernes savent gerer les fonctions tail recursives, ce n'est plus limité au Scheme. Bref un peu de douceur dans le monde de brute des programmeurs en C :)
Par exemple gcc transforme tres bien des fonctions recursives terminales en iteration; bon la je triche un peu il y a je ne sais plus qu'elle condition dessous qui est du au fonctionement interne de gcc.
C'est active avec l'option :
-foptimize-sibling-calls
Optimize sibling and tail recursive calls.
Enabled at levels -O2, -O3, -Os.
-
-
-
-
[^]Re: On oublie toujours OCaml
Posté par vrm (page perso, ) le 18/03/2004 à 09:22. (lien). Évalué à 2.et eiffel hein ? le meilleur language objet du monde (oui Monsieur !)
-
[^]Re: On oublie toujours OCaml
Posté par Snark_Boojum () le 18/03/2004 à 10:00. (lien). Évalué à 4.Eiffel est un langage formidable, effectivement. Il n'est peut-être pas inutile de donner le lien suivant:
http://www.cetus-links.org/oo_eiffel.html(...)-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 10:18. (lien). Évalué à 0.En plus ça tourne sur .NET, donc sur Mono aussi... c'est bien il n'y a pas de langage imposé et 100 bindings à maintenir en permanence...
-
[^]Re: On oublie toujours OCaml
Posté par jcs (page perso, ) le 18/03/2004 à 11:29. (lien). Évalué à 3.et celui-là : http://smarteiffel.loria.fr(...) (the GNU Eiffel Compilier)
J'aime beaucoup eiffel (c'est avec Eiffel que j'ai découvert les notions d'objets) même si je le trouve parfois un peu "verbeux". La syntaxe est déroutante pour les nouveaux venus, mais elle oblige à "penser objet".
-
-
[^]Re: On oublie toujours OCaml
Posté par Staz (Jabber id, ) le 18/03/2004 à 10:03. (lien). Évalué à 2.rien à voir, c'est cobol le meilleur language du monde
-
[^]Re: On oublie toujours OCaml
Posté par Staz (Jabber id, ) le 18/03/2004 à 13:28. (lien). Évalué à 1.second degré, vous connaissez?
-
[^]Re: On oublie toujours OCaml
Posté par Black Fox (page perso, ) le 18/03/2004 à 18:01. (lien). Évalué à 2.Oui les gens conaissent le second degré et c'est bien pour ça qu'ils moinsent à mon avis, car bien que marrant ce propos n'est pas pertinant sur le sujet.
-
-
[^]Re: On oublie toujours OCaml
-
-
[^]Re: On oublie toujours OCaml
Posté par Anaximandre () le 18/03/2004 à 12:41. (lien). Évalué à 0.Effectivement, ce langage est très expressif mais y'a quand même un problème avec le système de types : les arguments covariants sont possibles (grâce à 'like'). Il est notoire que c'est dangereux. Les travaux de http://www.di.ens.fr/~castagna/(...) résolvent la situation mais c'est évidemment trop tard pour modifier Eiffel.
-
-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 09:40. (lien). Évalué à 1.Just for fun :
> Y a t'il des projets de portage de Caml vers l'Universal Runtime faisant
> partie du framework .net de microsoft ?
Yes. In the spring of '99, Microsoft Research approached us, along
with other academic groups working on modern programming languages, to
work on this new technology. One of us (Bruno Pagano) has been
working for about one year on a port of Objective Caml to the .net
infrastructure, under support from Microsoft Research.
Bruno has a prototype port that works relatively well (better than
expected initially), but still shows that the .net common runtime
system is not a perfect fit for OCaml.
I'm not sure I can give more details (Microsoft may not have released
all technical specs yet), but in summary, .net is a technology we
follow closely, although it is still unclear whether it is the future
of OCaml for Windows.
-
[^]Re: On oublie toujours OCaml
Posté par V () le 18/03/2004 à 10:28. (lien). Évalué à 2.Caml par microsoft (ça s'appelle F#) :
http://research.microsoft.com/projects/ilx/fsharp.aspx(...)
Voir aussi :
http://www.pps.jussieu.fr/~montela/ocamil/(...)-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 10:30. (lien). Évalué à 0.Merci pour le 2ème lien je connaissais pas !
-
[^]Re: On oublie toujours OCaml
Posté par nicolassanchez () le 18/03/2004 à 10:34. (lien). Évalué à 0.J'aimerais connaître l'intérêt d'un tel portage. Moi, quand j'utilise un langage, c'est pas pour sa syntaxe... je regarde sa vitesse, sa stabilité, ses caractéristiques internes...
bref, je ne vois pas l'intérêt qu'on peut avoir à porter 10000 langages sur le même runtime.
Si quelqu'un peut m'éclairer.-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 11:49. (lien). Évalué à 1.bah l'intérêt c'est justement ne plus avoir à se soucier de la vitesse, de la stabilité, des caractéristiques internes... et de justement ne plus avoir qu'à choisir la syntaxe la mieux adaptée au contexte : tous les langages auront le même genre de perfs (à la qualité du code généré par le compilo bien sûr), auront laccès à tous les API écrit dans n'importe quel langage, bref, voilà le gros intérêt... Et pour MDI c'est ne plus avoir à se soucier de l'interopérabilité entre tout ça, ne plus s'enmerder à faire des bindings, bref, gagner du temps tout en ne limitant pas le choix du langage pour le programmeur.
-
[^]Re: On oublie toujours OCaml
Posté par nicolassanchez () le 18/03/2004 à 12:16. (lien). Évalué à 2.Ce que je voulais dire c'est choisir un langage pour favoriser telle ou telle qualité.
Avec le runtime commun, il n'y a aucun moyen de privilégier un aspect particulier d'un langage.
Que je programme en C ou VB, la vitesse d'exécution sera la même.
Alors que moi je choisirais le C quand l'application devra être rapide, et le VB lorsque l'application nécessitera des capacités de plugins évoluées.
Tant qu'à faire, autant créer un langage mieux adapté au runtime plutôt que d'adapter par je ne sais quel moyen d'autres langages dont les qualités spécifiques sont perdues.
Pour finir, si des gens se donnent la peine de créer de nouveaux langages, c'est pas pour inventer une nouvelle syntaxe, mais pour apporter des nouveautés internes.-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 12:27. (lien). Évalué à 1.Et tu vas râler si ton appli en VB va tourner aussi vite que ton appli en C ?
Si t'as vraiment besoin d'aller vite vite vite, tu utiliseras un langage qui autorise l'utilisation des pointeurs, genre C++ ou C# et zou.
Pour la création d'un langage mieux adapté au runtime, c'est ce qu'ils ont essayé de faire avec C#.
Sinon ils sont partis d'un constat simple : la plupart des langages modernes utilisent la notion de programmation objet. Ils se sont donc servit de ça pour factoriser les points communs entre les langages, tout en essayant de garder le maximum de possibilités.
S'il n'y a qu'une seule plateforme commune, une seule plateforme est optimisée et profite à tous les langages : tous les efforts sont portés sur la même plateforme.
Je rajouterai que de toute façon tous les langages ciblent une architecture matérielle, donc cibler .NET n'est pas plus dur et tu peux faire les même "nouveautés" internes. Seulement si tu créés un nouveau langage, rien ne t'empêche de proposer un API révolutionnaire dessous, tu pourras en plus en faire profiter tous les langages et tu pourras profiter des API créés dans les autres langages sans avoir à te soucier de l'interopérabilité.
De plus tu n'aura pas besoin de recoder une VM pour chaque nouvelle architecture, une seule plateforme sera portée.
De plus imagine le potentiel de ton nouveau langage : il est directement exploitable avec un nombre impressionnant d'API, les utilisateurs potentiels pourront être séduit par la syntaxe sans avoir à réapprendre de nouveaux API...-
[^]Re: On oublie toujours OCaml
Posté par nicolassanchez () le 18/03/2004 à 12:41. (lien). Évalué à 2.Pour te répondre une dernière fois, je vais prendre un exemple concret.
J'ai des collègues qui ont développé une application pour tester des appareils de mesures quelconques. Leur application devait tourner pendant environ 4 jours pour effectuer les tests.
Ils l'ont développé en VB .NET et par manque de chance ont eu des problèmes de mémoire car le GC ne fonctionne pas correctement sur .NET. Leurs tests s'arrêtaient au bout de 2 jours avec un message du genre plus de mémoire.
Alors, on peut se dire qu'il fallait choisir un langage avec une meilleure gestion de la mémoire, mais c'est le runtime qui la gère donc ça ne changera rien.
Voila pourquoi je dis qu'on choisit un langage pour ses qualités internes et non pour sa syntaxe.
La seule chose qu'apporte le runtime commun, c'est la généralisation des défauts et la perte des qualités spécifiques.-
[+] [^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 17:37. (lien). Évalué à -1.Ben, voyons, et dis comme ça je vais gober l'excuse que c'est la faute à .NET... et pourquoi ça ne serait pas la faute du programme ? et pourquoi pas celle de l'OS sous-jacent ? Dans le premier cas, tu sais ce qu'il faut faire, dans le 2ème, on parle ici de linux...
-
[^]Re: On oublie toujours OCaml
Posté par Nicolas () le 18/03/2004 à 18:03. (lien). Évalué à 1.j'avais un lien sur le sujet (mais je sais plus ou) comme quoi windows est totalement bugue a ce niveau mais il existe un patch a xxxxxx neuros pour corriger ca...
-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 18:54. (lien). Évalué à 0.BOon bah voilà t'as trouvé le coupable (il était dur à trouver...) ! Bref rien à voir avec le sujet, qui est quand même Mono sous Linux...
-
[^]Re: On oublie toujours OCaml
Posté par nicolassanchez () le 18/03/2004 à 20:03. (lien). Évalué à 1.T'as du mal à comprendre le terme "exemple", ça peut arriver pour d'autres points avec Mono, et le fait de changer de langage n'y fera rien.
Ce que je voulais dire, c'est que tu pourras pas dire : "y'a un bug, je vais prendre tel langage, réputé pour être très fiable", même un langage super fiable deviendra dépendant de ton runtime commun.-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 20:11. (lien). Évalué à 1.désolé je préfère laisser le plus de problèmes possible à la VM, j'ai plus confiance dans la fiabilité de la VM que dans la fiabilité de ce que j'écris. C'est plus fort que moi. Si tu préfères tout faire à la main, le GC, etc. c'est toi qui vois.
Sinon je suis d'accord sur le fait qu'on ne choisi pas un langage parcqu'il est réputé pour être fiable (d'ailleur ça veut pas dire grand chose pour un langage). Evidemment que tu resteras dépendant du runtime, comme tu resteras dépendant du compilateur, que tu restera dépendant d'un OS, que tu resteras dépendant des API proposés à ton langage, etc. Je préfères factoriser les problèmes et essayer de fiabiliser une seule VM. Bref y'a le même problème partout, pas plus sur .NET qu'ailleur.-
[^]Re: On oublie toujours OCaml
Posté par nicolassanchez () le 19/03/2004 à 08:27. (lien). Évalué à 2.Ecoute j'ai développé en C sous Linux. Quand il y avait un bug, je n'ai jamais eu besoin de regarder si il y avait un bug dans le système, le langage ou n'importe ou ailleurs. J'avais juste à trouver MON erreur.
Depuis que je développe en VB.NET je passe mon temps à chercher le problème de .NET. C'est clair, il y a plus souvent des erreurs dans .NET que dans mon programme.-
[^]Re: On oublie toujours OCaml
Posté par pasBill pasGates () le 19/03/2004 à 09:32. (lien). Évalué à 1.Tu peux me donner des exemples precis ? Des bouts de code qui montrent le probleme ?
Je serais ravi que tu me les envoie (nvidiatnt atte hotmail poing com)
-
-
-
-
-
[^]Re: On oublie toujours OCaml
Posté par pasBill pasGates () le 18/03/2004 à 21:59. (lien). Évalué à 1.Je serais ravi d'avoir ce lien, parce que bon, tu vas trouver ca drole, mais j'y crois pas.
-
[^]Re: On oublie toujours OCaml
Posté par Nicolas () le 19/03/2004 à 17:05. (lien). Évalué à 1.au cas ou je me soit plante sur ton mail:
http://www.aful.org/wws/arc/python/2003-03/msg00221.html(...)-
[^]Re: On oublie toujours OCaml
Posté par pasBill pasGates () le 20/03/2004 à 00:00. (lien). Évalué à 1.Petit exemple pour montrer qu'il raconte n'importe quoi :
#include <stdio.h>
#include <stdlib.h>
#define COUNT 32
#define MAX (2<<23)/COUNT
int main(int argc, char *argv[])
{
srand(5);
char **Array=new char*[MAX*COUNT];
printf("Size: %d\n",MAX*COUNT);
for(int i=0;i<MAX*COUNT;i++)
{
Array[i]=new char[(rand()%COUNT)+2];
Array[i][1]='2';
}
printf("finished allocating\n");
for(int i=0;i<MAX*COUNT;i++)
delete[] Array[i];
delete[] Array;
return 0;
}
Ce code alloue 16 million d'elements de taille aleatoire entre 2 et 34 +1 elt de taille 16 million, ecrit un byte dans chaque allocation, et les desalloue.
Sur ma workstation qui a 512Mo de RAM (210 utilises avant le lancement), il fait monter l'usage jusqu'a 750Mo, donc il tappe dans le swap assez mechamment.
Il met 20s pour desallouer les 16 millions d'elements.
Bref, loin, tres loin de ce qu'il raconte et les temps sont a peu pres comparables sous Linux.-
[^]Re: On oublie toujours OCaml
-
-
-
-
-
-
[+] [^]Re: On oublie toujours OCaml
Posté par Black Fox (page perso, ) le 18/03/2004 à 18:06. (lien). Évalué à -1.C'est pas parce que microsoft programme avec les pieds qu'il faut faire pareils.
Pour le garbage collector j'ai jamais aimé ces petites bêtes, ...
Je programme en pascal et un monObj := TObj.Create; qui est pas suivi par un monObj.Free quelquepart je trouve ça déroutant au possible.
Quelqu'un pourait nous faire la liste des avantages d'un GC ici, je parle de vrais avantages, supléer à un modèle de programmation fait avec les pieds à tel point que l'on en oublie de libérer des objets n'est pas un avantages, c'est un cache misère.-
[^]Re: On oublie toujours OCaml
Posté par TImaniac (page perso, ) le 18/03/2004 à 18:58. (lien). Évalué à 1.Parcque quand on programme en objet, il y a tellement de dépendance entre eux qu'il est parfois difficile de juger du moment opportun pour le delete (ou free). le GC trace en permanence les objets utilisés et choisi un moment "calme" pour le faire, cad quand le programme utilise moins de ressources. De plus comme toujours il faut mieux faire confiance au GC qui a moins de chance de se planter que le programmeur : il faut mieux automatiser tout ce qui peut l'être, c'est une source de bug en moins (si le GC ne l'est pas bien sûr).
-
[^]Il y a un monde meilleur sans GC!
Posté par Lionel Draghi (page perso, ) le 20/03/2004 à 23:07. (lien). Évalué à 1.Je suis bien d'accord sur le fait d'automatiser tout ce qui peut l'être.
Comme à chaque fois que l'on discute de GC, il y a unanimité pour dire que c'est un attribut indispensable d'un langage moderne, et hop, on se focalise sur les détails du GC.
Je rappelle quand même que le problème de base, ce sont les fuites mémoire, et que le GC n'est qu'une des réponses à ce problème.
Mais comme il vaut mieux prévenir que guérir, la meilleure réponse c'est quand même que la sémantique du langage empèche les fuites de mémoire.
Alors savoir si l'algo est plus ou moins optimisé, si il consomme le temps CPU de façon déterministe, distribuée, intelligente, etc., et bien il faut le savoir : on peut aussi dormir sur ses deux oreilles sans jamais se poser ce genre de problèmes.
(pour l'anectote, c'est signé d'un utilisateur heureux d'Ada).
-
-
-
-
-
-
-
-
-
-
[^]Re: On oublie toujours OCaml
Posté par gc (page perso, ) le 18/03/2004 à 10:46. (lien). Évalué à 5.Son compilateur est d'ailleurs tellement performant qu'il obtient un score supérieur à g++, et quasi-identique à gcc sur le test suivant :
http://www.bagley.org/~doug/shootout/craps.shtml(...)
Quand on se rappelle que ce langage possède un garbage collector, l'inférence de type, des exceptions... et bien d'autres choses encore.
-
[^]Erlang a également été oublié
Posté par Mickaël Rémond (page perso, ) le 18/03/2004 à 10:55. (lien). Évalué à 7.Et oui, le langage Erlang n'est pas mentionné. Et pourtant, il propose des caractéristiques fort moderne qui en font un langage qui doit compter à l'avenir.
Pour mémoire, Erlang offre les caractéristiques suivantes:
- Distribution - Erlang est conçu pour fonctionner en environnement distribué. Une machine virtuelle Erlang constitue en fait ce que l'on nomme un «noeud» Erlang. Les processus s'exécutant sur différents «noeuds» communiquent exactement de la même manière que des processus qui s'exécutent sur un «noeud» local. La distribution des traitements est transparente pour le développeur.
- Robustesse - Erlang dispose de fonctions standards de détection d'erreurs qui peuvent être utilisées pour bâtir un système «tolérant aux pannes» et notamment capable de gérer les erreurs logiciels (bugs).
- Mise à jour du code «à chaud» (Sans interruption des traitements en cours) - Certains systèmes ne peuvent pas être arrêté, même pour mettre à jour les programmes. Erlang permet de mettre à jour ces programmes sans arrêter le système. L'ancien code peut-être neutralisé et remplacer par le nouveau code. Pendant la transition, l'ancien et le nouveau code peuvent cohabiter. Il est ainsi possible de corriger des bugs et d'installer de nouvelles versions sur un système sans perturber son fonctionnement.
- Temps réel logiciel - Erlang permet de développer des systèmes temps-réel logiciel. Ces systèmes nécessite des temps de réponse de quelques millisecondes. Il n'est pas possible, dans ces systèmes de tolérer de longues phases de récupération de la mémoire (garbage collection). Erlang utilise donc des techniques de récupération mémoire incrémentales.
- Machine virtuelle très optimisée, en particulier au niveau de la gestion de la mémoire. Par exemple, Yaws, le serveur Web Erlang, utilise le plus souvent moins de 10 Mo de RAM. Il est possible de compiler le code critique de manière native.
Erlang est aujourd'hui utilisé, entre autres pour des applications critiques:
- Dans le domaine des télécommunications,
- Dans le domaine bancaire,
- Dans le domaine du jeu vidéo,
- Comme plate-forme de serveurs d'applications pour le développement d'applications Web robustes.
Allez, jeter un oeil sur www.erlang.org-
[^]Re: Erlang a également été oublié
Posté par nicolassanchez () le 18/03/2004 à 11:36. (lien). Évalué à 1.Ton commentaire m'a réellement intéressé et j'ai donc voulu voir à quoi ça ressemble.
Utilisant une Debian, j'ai regardé si un paquet était disponible.
Effectivement il y en a un mais il est classé en non-US.
Il me semble que les non-US sont interdits pour cause de cryptographie ou un truc dans le genre. Du coup je ne sais pas si c'est l'idéal pour le futur de Gnome.-
[^]Re: Erlang a également été oublié
Posté par free2.org (page perso, ) le 18/03/2004 à 12:25. (lien). Évalué à 1.actuellement c'est surtout les brevets logiciels (qui n'existent pas encore en Europe, mais il va falloir lutter pour que ça dure) qui obligent certains softs à être dans non-US
tiens à propos j'arrive plus à vérifier les signatures des non-US (nouvelle clé ou nouvel apt ?)
-
[^]Re: Erlang a également été oublié
Posté par Mickaël Rémond (page perso, ) le 18/03/2004 à 17:52. (lien). Évalué à 1.Je pense que la partie non-us est lié à SSL. Tu peux compiler Erlang sans le support SSL.
-
-
[^]Re: Erlang a également été oublié
Posté par Anaximandre () le 18/03/2004 à 12:43. (lien). Évalué à 1.Mais ce n'est pas typé, malgré quelques travaux sur le suje
-
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.