Un article sur le site Arstechnica donne des exemples (et du code ; par exemple avec GTK#) et développe l'idée que ce framework offre des gages de rapidité de développement, du fait d'une grande simplicité. La conclusion de l'article esquisse une comparaison avec Java : « En quoi est-ce différent de Java ? A mon avis Java rend les choses plus difficile que nécessaire ». NdM : Ce dernier propos est en parfaite résonance avec ce qui semble être un des aspects majeurs de l'argumentaire des auteurs de Mono en faveur de leur produit. Il fait, en effet, penser aux déclarations agressives vis-à-vis de Java tenues par le leader du projet Mono, Miguel de Icaza, lors d'une interview donnée à News.com. Ainsi, selon Miguel de Icaza « Le problème avec J2EE est qu'il est devenu très, très académique et que la complexité de tous ces systèmes parfaitement conçus à l'université ne convient pas nécessairement quand vous avez des dates limites ».
Il est à noter que le projet GNOME est actuellement en phase de réflexion sur son avenir afin de faciliter et d'en accélérer le développement.
Le projet Mono est l'un des candidats envisagé mais il rencontre une grande résistance du fait de son « origine » Microsoft et des incertitudes sur les problèmes de brevets.
Une autre difficulté est qu'il sera, par essence, toujours en retard sur les dernières nouveautés de Microsoft comme c'est déjà le cas actuellement, selon l'aveu même du leader du projet Mono signalant que « Nous sommes en retard ; nous sommes très en retard ; nous avons 18 mois de retard par rapport à Microsoft ».
Aller plus loin
- Le projet Mono (2 clics)
- La présentation d'Arstechnica (2 clics)
- L'interview de Miguel de Icaza (2 clics)
- La sortie de Mono 1.0 sur DLFP (11 clics)
# C'est un troll.
Posté par gc (site web personnel) . Évalué à 10.
D'abord on peut lire :
Mono's main pull for developers is that it is cross-platform and makes writing applications very fast because of its extensive framework. Mono also has the concept of garbage collection. Gone are the days of using malloc() and free() and recording where you allocated memory and making sure you free() it. Java has GC as well, but Java never really caught on as an application language.
Gni ? Ça veut dire que l'auteur pense que Java n'a jamais été utilisé pour écrire des vrais programmes ? C'est du grand n'importe quoi.
Ensuite on nous présente un exemple de code, avec le morceau de bravoure suivant :
The great power of Mono and .NET lies in the ONE line of code:
bool matches = Regex.IsMatch( input, regex );
.NET and Mono are actually a collection of libraries that form a framework which allows you, the programmer, to write the logic of your application. I can call one line of code to do input validation on a string which saves you possibly hours of time. Things like Input validation, network communication, file reading and writing, text encoding, regular expressions, formatting, XML Parsing, LDAP Access, remoting, and GUI development are reduced to just a few lines of code compared to possibly hundreds.
Euh, oui c'est sûr si on compare .Net à l'assembleur, c'est sûr qu'il faut une seule ligne par rapport à plein de lignes pour faire ça. Sauf que .Net vient chasser sur les terres de Java, hors en Java ça s'écrit en une ligne (et avec moins de caractères en plus).
boolean matches = input.matches( regex );
Bon on se décourage pas on continue. On nous montre ensuite une belle page de Gtk#, bon on aime ou on aime pas, moi je trouve que le style impératif forcé de Gtk+ donne des fonctions illisibles et trop longues mais bon c'est pas le sujet. La conclusion est assez fantastique :
a commercial software provider would target Mono and it would "just work" on all platforms that Mono supported. How is this different from Java? In my opinion Java makes things harder than it needs to be. For starters, enforced exception handling can't auto-box/unbox primitive types and doesn't support arbitrary length parameter lists String.Format() style.
Alors le type a rien prouvé du tout vu qu'il n'a jamais comparé avec Java sauf à dire que en Java y'a pas d'applications, mais bon il se permet quand même de dire qu'en Java c'est trop dur (sous-entendu c'est plus simple en .Net ? oui mais où et comment ?). Ensuite il parle à la fois d'exception et des types primitifs, là j'avoue que je comprends pas le rapport, mais il pointe un problème effectivement de Java (la dualité int/Integer et compagnie qui est vraiment un truc chiant en Java) et ensuite nous parle de l'impossibilité d'appeler une méthode Format avec un nombre variable de paramètres.
Ok, donc, .Net est vachement mieux que Java parce que... y'a pas le problème des types primitifs de Java, et y'a des méthodes avec nombre variable de paramètres ? On est d'accords que ce sont des problèmes de Java mais si .Net compte là-dessus pour faire la différence ça laisse rêveur...
Il finit par :
The framework of Mono provides the ability to make a very tedious task in C/C++ almost trivial in C#. As the above example, RegEx, shows, it helps the programmer concentrate on the program itself, rather than the logic supporting the code.
Ouais bon d'accord mais ça on sait que la gestion automatique de la mémoire c'est une avancée importante, et qu'une bonne bibliothèque de base c'est capital. Bref, cet article ne montre aucun intérêt de .Net par rapport à Java, (alors que .Net est là juste pour tuer Java, ce qui est de notoriété publique)
Cependant, et pour adopter un point de vue plus utile à Linux et au logiciel libre, ça peut être intéressant de disposer d'un runtime libre (Mono), car en face il n'y a pas de runtime libre Java correct à ma connaissance - mais il ne me semble pas que ce point soit abordé dans l'article.
[^] # Re: C'est un troll.
Posté par lezardbreton . Évalué à 9.
Effectivement, cette phrase peut choquer les afficionados de java.
Pour expliquer ce que l'auteur voulait dire, je vous fournis une statistique que j'ai faite récemment sur l'environnement d'une entreprise de grande dimension pour laquelle je travaille.
Le catalogue des applications logicielles pour Windows contient 2143 logiciels différents. Parmi ceux-ci, 56 ont une machine virtuelle java comme pré-requis, soit 2.61%. Il existe aussi 5 applications ayant comme pré-requis le framework .Net, soit 0.23% du parc.
Je pense pour ma part que c'est assez révélateur de l'état actuel de la popularité de ces deux plate-formes sur les postes clients, et il reste donc beaucoup de chemin à faire.
[^] # Re: C'est un troll.
Posté par gc (site web personnel) . Évalué à 4.
Bon, alors essayons de trouver des stats. Comparons par exemple Java avec C++, puisque le C++ était le langage le plus poussé en avant par Microsoft pour faire des applications jusqu'à l'arrivée de .Net (le VB étant réservé aux scripts et petits programmes).
Recherchons sur google les matches de gens qui cherchent à embaucher des développeurs C++ et Java (ça n'indique pas le nombre de programmes en circulation mais plutôt la tendance d'avenir ce qui est ce qui nous intéresse je suppose).
"software developer" c++ hire -> 7500 matches
"software developer" java hire -> 13200 matches
Allez hop recherchons les annonces sur jobpilot.fr. Dans les 4 dernières semaines pour du développement logiciel, 11 annonces matchent C++ et 18 matchent Java.
Voilà déjà deux exemples assez intéressant : je persiste à dire que c'est du grand n'importe quoi de dire que Java n'a jamais percé dans le domaine du développement logiciel. Dans le développement logiciel actuellement, bien sûr : il reste de nombreuses applications en Cobol, Fortran et compagnie fossilisées sur leur slowlaris mais on s'en tappe on ne parle pas de ça.
[^] # Re: C'est un troll.
Posté par Yann KLIS (site web personnel) . Évalué à 7.
Par contre, je suis tout à fait d'accord avec toi pour dire que l'article insiste bcp sur la simplicité de développement en utilisant comme exemple qqch qui existe déjà dans les bibliothèques de Mono. C'est-à-dire que si je décide par exemple de développer un éditeur de vidéo, Mono ne rendra pas le développement plus simple s'il n'y a pas de base des bibliothèques servant à manipuler et découper des vidéos.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 5.
Je crois que ce que voulais dire l'auteur de l'article (pourri) de Arstechnica est que Java n'a jamais vraiment pris pour faire des applications desktop, ce qui n'est pas complètement faux, mais ce qui néglige aussi le fait que beaucoup d'applications spécifiques (du genre la gestion de l'inventaire dans une boite lambda) sont maintenant développées un modèle de client léger, domaine dans lequel Java excelle.
Ceci dit, je suis d'accord avec toi, l'article de Arstechnica est pourri et l'interview de De Icaza est grotesque. C'est encroyable combien le Java bashing fait recette dans le monde linux. Et dire que Sun ne comprend toujours pas qu'il faut open sourcer Java, ça devient pathétique.
[^] # Re: C'est un troll.
Posté par lezardbreton . Évalué à 2.
Mais est ce que cela te choque si je te dis que je pense avoir près de la moitié des applications développées en Visual Basic, et une bonne partie en C/C++ ?
PS: en aucun cas je n'ai dit que java n'est pas prêt pour le desktop, je n'y connais rien en développement, et j'ai répondu bash comme langage de programmation préféré pour le sondage "Linux Journal's 2004 Readers' Choice" :)
PS2: qu'est ce que ça excite les gens cette histoire de java/Mono... Ca m'impressionera toujours !
[^] # Re: C'est un troll.
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par syj . Évalué à 4.
mais depuis que j'ai trouvé ce site, je trouve que çà va plus vite ;-)
http://mshiltonj.com/sm/categories/languages/(...)
Fait attention C# est la même couleur que sql, et c'est la courbe de Sql qui se trouve au-dessus de Java
Par contre, si tu regarde les courbes sur les technologies, le resultat est faut car la requête qui récupère les annonces .Net récupère des annonce qui n'ont rien à voir avec les techno de Microsoft probablement les URL en .net. Il explique çà dans son blogue
[^] # Re: C'est un troll.
Posté par Erwan . Évalué à 3.
[^] # Re: C'est un troll.
Posté par jcs (site web personnel) . Évalué à 10.
Non, je ne pense pas. Les afficionados sont bien conscients que Java s'il est omniprésent côté serveur, il est presque complètement abscent côté client. ll n'y a qu'à regarder les offres d'emplois pour s'en rendre compte : quand il est question de java c'est toujours Tomcat, EJB, Servlets et compagnie.
La raison de ce déséquilibre ? Même s'il existait des problèmes de performance au début, je pense qu'une grande partie en revient à Microsoft et ses facéties au sujet de la JVM qu'il distribuait, telles que les problèmes d'interopérabilité. Par contre sur d'autres terres vierges comme les téléphones portables, Java, côté client cette fois, se taille la part du lion, au point même d'en faire un argument commercial, les fameux jeux Java sur les derniers modèles.
[^] # Re: C'est un troll.
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par reno . Évalué à 5.
Dans l'article, ou il parle juste d'application sans précision, il dit une bétise point.
Ce qui globalement correspond à la (piètre) qualité de l'article..
Pour information, je ne suis pas du tout un fan de Java, j'ai essayé d'utiliser Swing en 99, c'était une catastrophe: buggé jusqu'a la moelle, avec Sun mettant des *années* pour corriger des bugs tres genant et tres voté dans la bugparade (et ce n'est pas une exagération malheureusement :-( )..
Maintenant pour ce qui est de .Net ou Mono, je laisse le soin aux autres d'essuyer les plâtres. Dans les deux cas, a mon avis, c'est trop tôt, dans 3-4 ans, pourquoi pas d'ils murissent bien..
[^] # Re: C'est un troll.
Posté par Croconux . Évalué à 10.
Swing. C'est vrai, si SWT était apparu plus tôt à mon avis, java aurais beaucoup plus insipré les développeurs d'application de bureau. Mais Sun voulait à tout prix rester 100% indépendant de la plateforme. Les appels à du code natif sont fortement découragés (d'ailleurs c'est imbitable). Depuis le début Sun décourage tout ce qui est natif (compilation ahead of time, lib native). Ils avaient très peur de Microsoft et du fait que tout le monde se mette à coder en utilisant des libs natives trop liées à windows.
C'est justement la force de .NET: Toutes les APIs sont dispo directement. Il n'y a pas une appli .NET sur 20 qui puisse tourner sur autre chose que windows. Il n'y a pas longtemps dans un article de ZDnet un journaliste déblatérait encore des conneries sur le fait que mono allait permettre de faire tourner des appli windows sous linux, office, les jeux... Mouais...
Un programme qui commence par "using Microsoft.DirectX" ou "using Microsoft.Office" ça ne tournera jamais allieurs que sous windows (et la bonne version encore). Il faut prendre .NET pour ce que c'est : Un environnement pour développer des appli windows.
[^] # Re: C'est un troll.
Posté par capicapio . Évalué à 2.
Et windows représente quel pourcentage du parc?
[^] # Re: C'est un troll.
Posté par lezardbreton . Évalué à 3.
[^] # Re: C'est un troll.
Posté par vrm (site web personnel) . Évalué à 3.
public void autoBoxing() { int a = 12; Integer b = a; int c = b; }[^] # Re: C'est un troll.
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Probablement parce que les concepteurs de Java sont des gros feignants.
Déjà que la justification pour ne pas avoir d'héritage multiple c'est "ben on avait pas le courage, et pis bon, avec les interfaces on limite la casse"...
[^] # Re: C'est un troll.
Posté par Croconux . Évalué à 3.
Ce n'est pas celle que donne James Gosling. Au moment de la conception de java il est allé voir dans les universités comment les profs enseignaient le concept d'héritage multiple pour savoir comment le traiter dans java. A sa surprise la plupart des profs lui ont dit qu'il ne l'enseignait pas ou ne faisait que le survoler. La raison : Ca apporte autant de problème que ça n'en résout. Et puis il me semble qu'au début vu comment les compilateurs C++ l'implémentaient de façon assez sportive et pas standardisée.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Ça dépend qui tu entends par "gens qui savent". Si tu parles des théoriciens des langages, c'est partiellement vrai (Stroustrup est avant tout un pragmatique). Si tu parles des gens qui utilisent les langages pour développer avec, c'est complètement faux (c'est même bien pour ça que C++ est devenu aussi complexe : chaque feature est là parce que quelqu'un l'utilise.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Je suis d'accord avec toi, Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème. Disons que "less is more" me convient plus, mais vu le succès de Perl et de C++, je suppose que pour beaucoup de gens, "more is more"...
Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.
> Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème.
Ben oui mais a un moment il faut bien que ton langage serve à quelque chose :-). Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur. Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
> Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.
Sans doute. :-)
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 3.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C
Effectivement, on a déjà eu cette discussion. Bon, je continue de penser que Stroustrup a fait un langage utilisable en pratique, avec des avantages concrets sur les concurrents, plutôt qu'un bel objet de laboratoire, et qu'il a eu raison de le faire. Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout. Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
mais aussi dans la bonne direction comme les structs
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 0.
- les JVM propriétaires de Sun uniquement
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Le seul véritable argument (valable aussi pour Python, etc.) est que la plupart du temps le code sera exécuté à une vitesse bien suffisante. C'est au cas par cas, ensuite, que l'on s'intéresse aux portions critiques.
Le problème de Java n'est pas la vitesse, mais tu n'utilises pas le bon argument.
> Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Il en a fallu autant à Java pour avoir des génériques. Il ne faut pas oublier aussi que C99 a retardé le travail sur C++98 chez beaucoup d'implémenteurs.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
> illustrer par divers exemples que la conception et l'implémentation sont des choses différentes.
Justement c'est ce que tu as du mal à comprendre.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Oups, j'avais oublié ça. Je te l'apprends peut être, mais gcc supportait déjà les templates vers 1994, mais de façon très bugguée. Dire que C99 a retardé le travail de normalisation est une vaste blague. De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
Tu ne me l'apprends pas mais ça ne présente aucun intérêt.
> Dire que C99 a retardé le travail de normalisation est une vaste blague.
Ah mais je veux bien qu'on me contredise, mais ce qui est rigolo c'est que tu n'emploies que des arguments foireux pour démontrer ce point. Intéressant.
> De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.
Personne ne dit qu'elle est simple, mais beaucoup de choses semblent confuses dans ta tête. Ce que tu dis là par exemple n'a aucun intérêt vis à vis de ce que je disais.
[^] # Re: C'est un troll.
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
Pas seulement. Le seul problème est qu'en Java, les plus mauvaises JVM sont Open-source; Mais si tu prends celle de BEA, par exemple, elle déchire pour toutes les applications serveur (quand je dis elle déchire, je veux dire qu'elle est vraiment plus rapide que celle de Sun, et également gratuite).
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Je ne suis pas d'accord.
L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
Ok tu fais bien de me corriger, c'est au fait que les plus mauvaises soient open source que je pensais, c'est vraiment un inconvénient.
> L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++
Je ne dis pas que ça ne peut pas l'être mais qu'il faut savoir quelle est la bonne bibliothèque à utiliser, par exemple. Je pense à des cas où l'emploi d'une bibliothèque était efficace, et l'emploi d'une autre, en apparence similaire (en fait, similaire pour le néophyte) l'était beaucoup moins. Tout ceci à disparu de Java, ou bien les bibliothèques proposées dans la dernière version ne présentent plus cet inconvénient ?
[^] # Re: C'est un troll.
Posté par Philip Marlowe . Évalué à 1.
As-tu quelque lien à ce sujet ? Parce qu'entre deux releases, on ne peut pas dire que l'équipe de SmartEiffel abuse de la communication... Je suis utilisateur d'Eiffel pour mon travail et les progrès de SmartEiffel m'intéressent beaucoup (en gestation : un IDE, l'implémentation de la concurrence selon SCOOP), mais les dernières infos de leur site dataient de juin 2003. Dataient, SmartEiffel 2.0 beta #1 est sur le site depuis le 16 jullet, je viens de m'en rendre compte.
Ceci dit, l'information à leur sujet n'est pas pléthorique, alors y a-t-il des sites que je ne connais pas, ou les connais-tu personnellement ?
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 0.
Je serais curieux de te voir poster tout ceci sur fclc++, je pense que des gens comme G. Dos Reis (qui travaille justement avec Stroustrup) auraient quelques trucs à t'expliquer, et ça te permettrait de comprendre tes erreurs. On constatera aussi que, curieusement, les professionnels qui sur ce forum maîtrisent plusieurs langages (Java, Ada) ne font pas le même bilan que toi, et font une critique constructive du langage qui n'a rien à voir avec ces puérilités sur virtual.
Les remarques sur la surcharge d'opérateurs sont aussi ridicules : ainsi personne ailleurs qu'en numérique n'utilise de matrices ou de vecteurs ? C'est classique d'une critique faite « dans son petit monde à soi ».
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Pour le virtual, je t'explique. Dans les langages objets avant C++, la notion d'objet implique celle de polymorphisme. Si B hérite de A, je peux écrire un code qui pense utiliser des A mais lui transmettre des B, tout ce passera bien, les méthodes de B seront appelées. En C++, ceci ne fonctionne que si on ajoute virtual devant les méthodes qu'on veut voir fonctionner correctement. Bien entendu, on peut toujours avoir B qui hérite de A, passer un B à un code qui attend un A et obtenir un comportement débile car les méthodes redéfinies dans B ne sont pas appelées. Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. Or, un langage doit être prévisible simplement. Un tel comportement est nuisible et ne fait que compliquer la tâche du programmeur sans aucun intérêt pratique.
Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java. De cette manière, on ne peut pas se tirer dans le pied en croyant avoir du polymorphisme mais en ayant en fait un truc boiteux. On peut aussi imaginer une solution à la C++ mais qui empêche de se tirer dans le pied, en ayant une seule sémantique (et pas une sémantique qui dépend du mode de passage) et en interdisant la redéfinition des méthodes non virtuel. Personnellement, j'aime moins, mais bon, c'est un choix.
Les arguments des défenseurs de la sémantique débile du C++ sont multiples et plutôt foireux.
Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles. On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage. Ce sont les structs du C#, mais ça existe depuis longtemps en Eiffel et Sather (et ça manque drôlement en Java).
Le plus pourri est celui qui dit que virtuel permet d'optimiser le code. C'est grotesque. De toute manière, on obtient la même chose avec du final (i.e., la possibilité de virer le passage par la table des méthodes virtuelles et d'inline les méthodes associées si ça vaut le coup). De plus, depuis Eiffel et Sather, on sait que des techniques évoluées permettent de laisser le compilateur faire ça de façon beaucoup plus efficace que le programmeur.
Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 0.
> Pour le virtual, je t'explique.
Alors là c'est toi qui est gonflé ! Pourquoi rappeler tout ceci alors que je le sais pertinemment, je ne n'aurais pas parlé sur ce sujet sinon ? N'importe quel programmeur C++ doit savoir ça, c'est la base pour la partie objet. Le fait est que si tu veux que tous tes objets aient le comportement que tu attends, dès le départ tu dis dans ton projet « toutes les fonctions membres seront virtuelles », et c'est fini. Aucune difficulté. Seulement ce qui ne te plait pas c'est que le comportement qui te sert le plus nécessite un mot clé. C'est du délit de sale gueule, il n'y a pas d'autre argument "contre".
> Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java.
Non. C'est un choix dans la conception du langage, point. De plus C++ n'est pas objet mais propose un support pour la programmation OO, c'est différent. Il n'a pas prétention à être un langage objet. Bref, tu lui donnes des prétentions et tu le critiques dessus, alors je dis que c'est ridicule. Le support OO est présent, point. Si ce n'est pas le langage qui te convient, prends-en un autre plus adapté à ton projet. Mais le simple fait de devoir marquer « virtual » des fonctions n'est certainement pas un élément déterminant pour exclure C++. Tes qualifications de « boiteux » et autre sont totalement subjectives. C++ n'a pas vocation à être simple à apprendre mais puissant à l'utilisation. Il nécessite un investissement plus grand en apprentissage, mais c'est payant au bout du compte. L'apprendre à la légère n'est pas une option, mieux vaut utiliser un langage plus simple à apprendre.
> Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles.
Je ne sais pas si ça nécessite un argument, mais ce serait bien que tu cites ceux qui ont réellement été pris en compte et pas ceux que tu as pu lire ici ou là. Des fanatiques du C++ ont pu te sortir n'importe quel mauvais argument, moi ce qui m'intéresse serait le raisonnement de Stroustrup et du comité. Pour ma part, c'est juste un choix du langage et j'utilise la syntaxe qui va bien en fonction de ce que je veux faire.
> On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage.
Mais tout ça ce sont des questions de conception justement. Tu dois savoir si tu utilises tes objets avec une sémantique de valeur ou d'identité, tu les définis en fonction de ça, et pour ça tu utilises le langage. C++ n'impose pas une seule sémantique contrairement à Java, donc tu as plus de choix, plus d'efforts à faire sur la conception et sa transposition en code.
> Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
Non, mais ce qui ne m'intéresse pas, c'est des arguments contre des arguments qui ne m'intéressent pas. Si tu vois passer des arguments pipeau pour virtual, ça ne m'intéresse pas de voir ce que tu dis contre eux, parce que moi-même ils ne m'ont pas convaincu. J'aurais d'ailleurs préféré que C++ ait le comportement que tu dis ! Seulement ce n'est vraiment pas bien grave, la solution est tellement triviale (déclarer correctement) que c'est tout sauf un argument contre C++ : C++ a bien d'autres problèmes qui font qu'on préférera d'autres langages à celui-ci, mais le "virtual" comme problème insoluble n'est vraiment pas sérieux. Si tu veux faire de l'objet à la Java en C++, tous tes objets ont des fonctions membre virtuels et tu les utilises avec une sémantique d'identité, autant que possible avec des références, sinon des pointeurs, et jamais directement. Je ne dis pas que l'apprentissage nécessaire pour bien s'en servir est comparable à Java ou autre sur ce point là.
Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Il me semble avoir lu les deux arguments débiles que j'évoque sous la plume de Stroustrup, mais comme je n'en suis pas certain, j'ai préféré ne rien dire. Sur son site on trouve le même genre d'arguments débiles du genre "toutes classes ne sont pas destinées à devenir des classes de base", ce qui signifie dans le contexte des classes dont on peut dériver d'autres classes. Et surtout un argument sur la table des méthodes virtuelles qui prend de la place. Les deux "problèmes" sont réglés par des objets lightweights, ce qui évite les problèmes de sémantique variable selon le mode de passage et ce qui rend donc le langage plus clair. De plus, la table des méthode virtuelles peut être supprimée automatiquement par un compilateur intelligent dans un langage sans pointeur.
Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
> Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.
Je réponds quand c'est nécessaire, et je n'en fais pas plus que nécessaire en réponse aux trolls dans ton genre. C++ a des défauts mais toi tu ne ressors que les vieux trolls et arguments ridiculisés depuis longtemps.
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
J'en doute quand je lis « Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. »
Ou je me dis plutôt que tu ne veux pas comprendre pourquoi ça se passe comme ça.
Des langages différents, des objectifs différents, des choix différents. Pourquoi cet intégrisme sur les solutions Java ? Si l'objet répondait à tous les problèmes, C++ aurait été abandonné depuis longtemps.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
Au fait, tu as remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 3.
Oui et c'est à mon avis l'un des seuls défauts du langage. La sémantique de l'héritage est d'ailleurs assez complexe par rapport à Java et je ne la trouve pas très convainquante. Si tu as un exemple de l'utilité pratique du bousin, je suis preneur.
Par contre, il n'y a pas de changement de sémantique suivant le mode de passage qui rend le C++ inconsistant. Je n'ai d'ailleurs surement pas assez insisté sur ce point : je trouve idiot d'avoir à ajouter virtual, mais c'est surtout une question de goût. Cela pose aussi des problèmes de génie logiciel : le concepteur d'une classe doit explicitement rendre ces méthodes modifiables et doit donc penser aux extensions possibles, ce qui est beaucoup plus dur que de penser aux méthodes qui ne doivent surtout pas être modifiées. Je trouve donc que le final de Java est plus utile, mais je ne me battrais par pour ça.
Ce qui pose vraiment problème en C++ et qui est une erreur de conception à mon avis, c'est que le comportement des méthodes d'un objet dépend du mode de passage de celui-ci. De plus, il n'y a pas de garde fous en C++, alors que c'est le cas en C# (tu ne peux redéfinir une méthode non virtual que si tu le demandes de façon très explicite en ajoutant un new).
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."
When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.
Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Sinon, les explications données ne sont pas très convainquantes :
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.
[^] # Re: C'est un troll.
Posté par Philip Marlowe . Évalué à 2.
Je me suis tué à le dire : se prendre pour un compilateur, c'est un trouble du comportement !
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 3.
Dans le cas de C#, le code est transformé en code intermédiaire, si le compilateur a procédé à des optimisations, comme par exemple des inlines, je vois de gros problèmes dans certains scénarios :
Je déclare une classe qui dérive d'une classe du code intermédiaire...
je fais la même chose au runtime de manière dynamique...
C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation !
Tu vois où est le problème maintenant ;)
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Donc C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation ! est peut être vrai, mais pas pour les raisons que tu indiques.
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
Et puis les scénarios de chargement dynamique au runtime sont de plus en plus courant, ne serais-ce que pour faire une architecture de plugin, on parcourt un assembly au runtime et on créé des instances à la volée... Enfin tout ca pour dire que les cas où le compilateur peut faire son boulot trankilou il est rare...
Je me trompes peut-être complètement :)
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Ceci étant, sur le fond, quand on a besoin d'un vrai polymorphisme, on doit avoir des méthodes virtuals avec late biding. Alors qu'on marque explicitement les méthodes en question virtual ou qu'on marque final celles qui ne sont pas polymorphes, franchement, c'est la même chose...
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
class MainClass
{
public static void Main(string[] args)
{
A a = new B();
B b = new B();
a.d();
b.d();
}
}
class A{
public void d(){
Console.WriteLine("Je suis une voiture");
}
}
class B : A{
public new void d(){
Console.WriteLine("Je suis une ford");
}
}
on obtient effectivement :
Je suis une voiture
Je suis une ford
Je vois effectivement ce que tu veux dire.
Le compilateur se base sur la définition stricte de a et fait dès lors exécuter d de A. Le compilateur n'a pas tenu compte du véritable type de a. Considérons une instruction if et imaginons qu'en fonction de l'évaluation de la condition, on assigne dans a soit un objet A, soit un object B. Le compilateur lui-même ne peut savoir que a contient réellement un objet B. Ce n'est qu'en cours d'exécution de programme que cette constatation peut-être faite, et, par défaut, le compilateur ne génère pas de code permettant de faire cette constatation. (sinon on aurait les même problème de perfs qu'avec les virtual)
Effectivement celà peut-être troublant, mais bon, ce n'est pas non plus vraiment génant à mon goût... celui qui développe la classe sait explicitement ce qu'il fait, il redéfini une méthode d'une classe alors que normalement il ne peut pas (elle n'est pas virtual), donc celà paraît normal qu'il ne puisse pas en modifier le comportement... Je pense que celà permet de redéfinir une méthode, et, en connaisssant le type exact on peut appeler cette version de la méthode. (pour contourner le fait que les méthodes ne sont pas virtual par défaut).
Enfin perso je me souvient pas avoir rencontrer le problème.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . Évalué à 2.
Je fais un contrôle MonButtonAmélioré
celui qui considère que c'est un bouton de base, il aura accès aux méthodes comme si c'était un bouton, la classe bouton n'ayant pas autorisé la virtualisation, l'utilisateur n'est pas perdu. L'utilisateur qui considère que c'est une instance de MonButtonAmélioré appelera ma méthode qui fait des trucs en plus, et là il saura à quoi s'attendre puisque c'est lui qui a demandé explicitement une référence vers cette sous-classe.
En gros je crois qu'il faut voir celà comme ca :
1 - tu peux toujours redéfinir une méthode dans une classe qui hérite d'une autre
2 - soit la classe mère veut que ce soit la classe fille qui définisse une méthode précise, auquelle cas le développeur la met virtual. Sinon dans tous les autres cas le comportement ne change pas, il faut que le développeur fasse une référence explicite au type exacte de la classe pour obtenir le comportement différent si c'est une classe hérité avec une méthode new.
On retrouve le même principe pour les interfaces :
class A : InterfaceB {
interfaceB.methode(){
}
}
là il faut utiliser explicitement une référence à l'intefaceB (par exemple (new A() as InterfaceB).methode(); ) pour pouvoir en utiliser une méthode.
Je trouve à la limite ce comportement plus cohérent pour l'utilisateur...
Imagines le cas suivant :
class Véhicule{
private nom = "voiture" //ca pourrait évoluer
public ToString(){
Console.WriteLine(nom);
}
}
class Mercedes : Véhicule{
public new ToString(){
Console.WriteLine("Mercedes Class A");
}
}
Maitenant on prend toujours le cas où c'est la Mercedes qui est instanciée, mais la référence est pas la même.
Je veux lister mes véhicules pour aovir leur types :
j'obtiendrai en C# quelque chose comme ca en utilisant que des références de
Véhicule :
voiture
camion
voiture
4x4
en Java il obtiendrait celà :
voiture
Mercedes Class A
camion
Ford Focus 1.4l
Bref le new est là pour ne pas brider le développeur qui a besoin d'un nom particulier, mais lui empêche tout de même de changer le comportement qui peut être attendu par l'utlisateur qui ne s'attend peut être pas à une redéfinission de la méthode. C'est celui qui développe la super classe qui décide de mettre virtual ou pas.
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 1.
Trop de copier/coller tue le copier/coller... Je me demande comment j'ai réussi à faire ça...
[^] # Re: C'est un troll.
Posté par Bière Drabo . Évalué à 1.
Le problème est plutôt la cohabitation de deux approches et le fait que ce soit trompeur si on les mélange, mais c'est le choix de C++ : n'en privilégier aucune. On peut s'efforcer :
- quand on fait de l'objet de n'avoir que du virtual (sans se poser de question) et de n'accéder aux objets que par pointeur ou référence, « à la Java », c'est assez naturel dans une sémantique d'identité
- quand on fait de la sémantique de valeur, utiliser les objets directement ou des références constantes.
C'est vrai qu'une solution plus propre serait d'avoir une différence de nature entre ces deux catégories. Difficile de juger de la pertinence des choix quand les premiers éléments de C++ étaient vraiment envisagés comme de futures extensions de C. Je trouve quand même un peu fort de parler d'erreur de conception : tout le monde s'accorde sur la syntaxe pénible et l'héritage lourd dans l'évolution de C++, mais l'essentiel (pour ce langage et avec ses objectifs) est de permettre un paradigme quitte à ce que le fait d'en permettre plusieurs apparaisse bancal quand on n'en considère qu'un seul.
[^] # Re: C'est un troll.
Posté par Black Fox . Évalué à 2.
T'inquiette le leader de ce groupe as été débauché de chez borland et est le créateur du compilo turbo pascal ainsi que du Delphi (Et les évolutions du language Pascal Object qui vont avec) :p
Par contre le multi héritage n'est pas prévu pour la CLI 2.0 et je trouve ça vraiment domage...
Que certains langages .Net ne le supportent pas : ok
Mais que ce ne soit même pas présent ça manque vraiment (le seul language qui l'implémente est le C++, mais hors de la CLI donc si cette fonctionalité est utilisée les autres languages ne peuvent pas utiliser les classes produites, la réflexion est impossible, ...)
[^] # Re: C'est un troll.
Posté par Philip Marlowe . Évalué à 1.
Eiffel Software implémente un compilateur Eiffel pour .NET qui supporte l'héritage multiple. Cela s'appelle ENViSioN.
http://www.eiffel.com/products/(...)
[^] # Re: C'est un troll.
Posté par Dring . Évalué à 1.
Cela dit, je ne vois pas ce que ça apporte par rapport au passage d'un tableau de taille variable.
Mais pour les habitués du printf, j'imagine que c'est plus naturel. Amélioration ou pollution ?
[^] # Re: C'est un troll.
Posté par kra . Évalué à 1.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Regarde mieux :
- c'est plus rapide (concatener des String en Java est assez couteux)
- c'est beaucoup plus lisible.
- il est impossible d'internationaliser une chaine construite à coup de "+".
[^] # Re: C'est un troll.
Posté par kra . Évalué à 0.
perso je lis de gauche a droite et mon cerveau a du mal a remplacer un %i par le n-ieme argument lui correspondant situe apres la chaine que je lis, chose qui ne se produit pas en Java, vu que t'ecris sequentiellement ta chaine.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
"Erreur numero %1 a la ligne %2, colonne %3 du fichier %4", errno, lineNb, colNb, fileName
"Erreur numero " + error + " a la ligne " + lineNb + ", colonne" + colNb + " du fichier " + fileName
Tu n'a pas besoin de "remplacer les %i", tu infères leur valeur par le contexte du string. Lequel contexte est beaucoup plus clair si le string n'est pas entrelardé de '"' et de '+'. Sans compter que c'est bien plus facile à écrire, par exemple j'ai volontairement fait une erreur dans le 2eme exemple, tu arrives à la voir facilement ?
[^] # Re: C'est un troll.
Posté par kra . Évalué à -1.
si par erreur, tu entends l'absence d'espace apres colonne, j'appelle pas vraiment ca une erreur, plus une faute de frappe.
Je l'ai vu a la deuxieme lecture de la ligne.
bref, toujours est il que pour ecrire ta premiere ligne, tu as du ecrire le message d'erreur, puis donner le nom des variables en te demandant dans quel ordre tu dois les donner : 2 etapes au lieu d'une.
ensuite, quand tu "infere leur valeur par le contexte du string", tu devines ce que la ligne veut dire, pas ce qu'elle fera effectivement, ce qui me parait quand meme le plus important.
quand a ce qui est d'entrelacer avec des " et des +, c'est pas pire que d'entrelacer avec des %i
peut etre es tu rentre dans la matrice du C, ce qui fait que tu es parfaitement habitue a lire un printf.
l'ecriture java-style me parait plus naturelle.
[^] # Re: C'est un troll.
Posté par jmfayard . Évalué à 5.
ces 2 syntaxes sont à chier par rapport à l'interpolation directe de variables à la Perl ou Ruby, beaucoup plus naturelles et lisibles :
"Erreur numero $error a la ligne $lineNb, colonne $colNb du fichier $fileName"
ou quelquechose comme
"Erreur numero %{error} a la ligne %{lineNb}, colonne %{colNb} du fichier %{fileName}"
[^] # Re: C'est un troll.
Posté par reno . Évalué à 1.
Je viens de lire un tutorial sur D ( http://www.digitalmars.com/d/index.html(...) ) ou ils present printf comme la huitieme merveille du monde..
Je pense que les devs de Java et de D auraient dut regarder la syntaxe de Ruby au moins pour ce point la!
OK, c'est du "sucre syntaxique" mais les commandes d'affichage sont tellement utilisé que ça le vaut et moi entre un:
1- puts "Erreur numero %{error} a la ligne %{lineNb}, colonne %{colNb} du fichier %{fileName}"
2- printeln "Erreur numero " + error.toString + " a la ligne " + lineNb + ", colonne" + colNb + " du fichier " + fileName
3- printf( "Erreur numero %d a la ligne %ld, colonne %ld du fichier %s", errno, lineNb, colNb, fileName);
Je prends 1!
La grosse difference entre 1 et 2 est que dans 1 le toString est appelé "magiquement"..
Normalement string+objet, cela fait type error et heureusement pour la vérification de typage, mais dans 1, la syntaxe indique bien quand veut obtenir une string en final et donc c'est remplacé par string+objet.toString..
Le printf est vraiment tres moche, il n'y a que le C++ qui ait réussi a faire pire.. Le seul avantage que je lui voit c'est qu'on peut facilement faire des formattage assez complexe (indentation a gauche, a droite,etc..), possibilité qui est quand même assez rarement utilisé..
Je ne vois pas pourquoi ce "syntactic sugar" bien agréable devrait être réservé aux languages "de script"..
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Euh, en java aussi, quand tu concatènes à coup de '+' il appelle toString() tout seul comme un grand.
> Je ne vois pas pourquoi ce "syntactic sugar" bien agréable devrait être réservé aux languages "de script"..
Plus exactement, aux langages interpretés. Un langage compilé ne peut pas faire ce genre de choses, déjà parce que le nom d'une variable n'est pas une information que la compilation conserve (donc plus moyen d'interpoler "blah %{foo} blah").
[^] # Re: C'est un troll.
Posté par Sidoine de Wispelaere . Évalué à 1.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
C'est vrai, mais :
- un langage compilé ne sait pas faire ça, donc on est un peu hors sujet :-)
- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).
C'est pas pour rien que Ruby a sprintf() aussi :-) (et Perl aussi, mais j'aime pas Perl).
[^] # Re: C'est un troll.
Posté par boubou (site web personnel) . Évalué à 2.
Ba si, sans problème, il suffit d'avoir le support pour le faire dans le compilateur. On analyse statiquement le contenu de la chaîne et on traduit les noms de variables en offset dans la pile.
La seule difficulté réside dans le fait que la chaîne de format doit être statique, ce qui limite les applications possibles et surtout qui nécessite un support spécifique au niveau du compilateur (pour empêcher l'utilisation de la construction avec une chaîne dynamique).
On peut aussi imaginer qu'on conserve la table des symboles pour les variables locales, mais c'est un peu lourdaux (mais faisable).
- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).
Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ce qui suppose que les variables soient locales, non ? Enfin bon, oui, j'imagine bien qu'il doit être possible de bidouiller un compilo pour que ça marche plus ou moins bien, mais je ne suis pas convaincu de l'interêt de l'exercice.
> Ajouter ce genre de fonctionnalité sous forme de modificateur est ultra trivial.
Oui, tu vas juste re-inventer printf().
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Appelle-ça comme tu veux, en pratique le résultat est le même : un cycle edition/compilation/run en plus. Et non, ça n'est pas une faute de frappe parce qu'il n'est pas naturel d'ajouter un espace avant de fermer des quotes. C'est bien une erreur.
Je l'ai vu a la deuxieme lecture de la ligne.
Alors que "... colonne%3 ...", tu le vois tout de suite.
pour ecrire ta premiere ligne, tu as du ecrire le message d'erreur, puis donner le nom des variables en te demandant dans quel ordre tu dois les donner : 2 etapes au lieu d'une.
Parce que tu crois que découper ton string à coup de " et + c'est rapide ? :-)
tu devines ce que la ligne veut dire, pas ce qu'elle fera effectivement, ce qui me parait quand meme le plus important
Quand tu lis du code rapidement pour avoir une idée de ce qu'il fait, tu ne t'emmerde pas comprendre ce que fait exactement chaque ligne, ou alors tu n'avances plus, et avoir un string lisible te fait gagner du temps. Tu regardes le détail uniquement quand tu débugges, et dans ce cas compter les arguments n'est pas vraiment un pb. Ça reste même plus facile qu'assembler le string (surtout quand les arguments sont plus complexes que de simples noms de variables, mets des appels de méthodes à la place, pour voir :-).
quand a ce qui est d'entrelacer avec des " et des +, c'est pas pire que d'entrelacer avec des %i
Bon, si tu as envie d'y croire... Et ça fait combien de temps que tu développes, et avec quels langages, pour pouvoir affirmer ça ?
peut etre es tu rentre dans la matrice du C, ce qui fait que tu es parfaitement habitue a lire un printf.
On est beaucoup dans ce cas :-).
l'ecriture java-style me parait plus naturelle.
Même question : sur quelle expérience concrète te bases-tu pour dire ça ?
[^] # Re: C'est un troll.
Posté par Yusei (Mastodon) . Évalué à 2.
Depuis quand on a besoin de montrer sa b^W^W son CV pour pouvoir dire qu'on préfère un style à un autre ?
S'il y avait une solution qui satisfasse tout le monde, ça se saurait, hein.
(À choisir entre le style Java et le printf, je préfère le printf, mais bon rien ne vaut la méthode perl/ruby)
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Depuis que ce genre de question a une influence directe sur l'heure à laquelle tu rentres chez toi le soir. :-)
C'est facile de dire "je préfère ce style là" quand on a jamais vraiment codé. Mais quand c'est ton boulot, que tu as testé les deux, et qu'avec l'un tu te fais plus chier que l'autre, tu as de vrais arguments pour parler.
[^] # Re: C'est un troll.
Posté par kra . Évalué à -2.
on va dire que ca fait 3 ans que je code a peu pres tous les jours, en C/C++ les 2 premieres annees, java les 2 dernieres (oui je sais ca fait 4 annees, mais j'ai fait une annee java et c/c++)
et sinon, t'as combien de poils de cul toi, histoire de continuer a elever le debat?
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Je ne vois pas l'interêt de discuter avec quelqu'un qui parle d'un sujet sans en avoir la moindre expérience, ce que ta première réponse laissait supposer.
Bon, je suppose que je me suis trop emmerdé avec des '+' pour apprécier ton point de vue (certes, dans des cas triviaux ou le string est simple, c'est tout à fait lisible et je l'utilise aussi parfois, mais au dela ça devient vite lourd).
[^] # Re: C'est un troll.
Posté par Yusei (Mastodon) . Évalué à 3.
(Je précise que je parle de la syntaxe de Java uniquement, puisqu'ici on parle de "style" et pas de performances)
[^] # Re: C'est un troll.
Posté par Moonz . Évalué à 1.
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: C'est un troll.
Posté par kra . Évalué à 1.
point.
je n'ai jamais evoque une quelconque histoire d'optimisation, de traduction ou je ne sais quoi.
si vous voulez continuer a vous branler la nouille sur des sujets aussi vagues, continuez sans moi.
[^] # Re: C'est un troll.
Posté par djano . Évalué à 1.
Regarde mieux :
- c'est plus rapide (concatener des String en Java est assez couteux)
- c'est beaucoup plus lisible.
- il est impossible d'internationaliser une chaine construite à coup de "+".
1) tu connais pas les stringbuffers?
2) plus lisible, plus lisible. C'est pas mon avis....
3) apres avoir fait des append() avec tes stringbuffers (voir le 1), hop!! un tostring() et tu as une string. Elle est pas belle la vie?
[^] # Re: C'est un troll.
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Si, merci, mais ça simplifie pas vraiment le code de devoir passer par une classe intermédiaire, et si la lisibilité est un critère...
> 2) plus lisible, plus lisible. C'est pas mon avis....
Ben monte un club avec kra, je sais pas moi... Dès que ton string devient un peu complexe, ça devient franchement pénible à lire autant qu'a écrire. Si une syntaxe printf-like existe dans quasiment tous les langages un peu utilisés, ça n'est pas juste pour faire plaisir aux codeurs C.
> 3) apres avoir fait des append() avec tes stringbuffers (voir le 1), hop!! un tostring()
Avant de répondre à un argument, ça serait bien de le comprendre :-). Tiens, va voir par là :
http://developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i(...)
la section "No word puzzles".
[^] # Re: C'est un troll.
Posté par bleh . Évalué à 1.
- StringBuffer est un tableau d'une taille défini par défaut à 16 caractères et chaque "append()" peut potentiellement povoquer une "expansion" du tableau d'origine avec les couts d'un appel à arraycopy().
- Le principe d'expansion du StringBuffer est assez rudimentaire, en gros doublement de la capacité initiale à chaque fois ce qui fait que pour une simple String on peut avoir un espace mémoire assez conséquent utilisé.
- On crée toujours 2 objets, un procédé qui reste couteux en Java.
Bref, au niveau lisibilité ce n'est pas forcement terrible et ça reste couteux. Personnellement je pense qu'un printf() pourrait être intéressant.
# La vie réelle
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
bien sur et nous, on développe tous pour des gens qui viennent de Mars.
Si la personne se renseignait un tout petit peu plus, elle aurait pu regarder des sites comme Objectweb ou on voit des gens comme Dassault, Thalès, INRIA, la CNAF qui utilisent Java...
Et si il veut jouer à ça, combien d'applications d'entreprises tournent sous Mono ?
http://about.me/straumat
# du fait d'une grande simplicité
Posté par Philip Marlowe . Évalué à -2.
# La réécriture des news
Posté par patrick_g (site web personnel) . Évalué à 10.
Par contre ce qui est vraiment problématique à mes yeux c'est l'ajout d'un adjectif qui n'est absolument pas présent dans ma contribution initiale :
A propos de Miguel de Icaza le modéro à ajouté le terme "agressives" dans la phrase suivante :
Il fait, en effet, penser aux déclarations agressives vis-à-vis de Java tenues par le leader du projet Mono
La réécriture OUI quand c'est pour corriger des fautes ou ou reformuler en bon français.
Si le modéro veut préciser un truc il l'ajoute avec la mention : NdM
Par pitié pas d'ajout d'adjectifs qui ne sont pas dans la news de départ.
...c'est que j'ai peur de me faire casser la gueule à la récré par Miguel moi maintenant !
[^] # Re: La réécriture des news
Posté par Anonyme . Évalué à -1.
L'adjectif « agressif » me semble neutre : quel autre qualificatif donner aux propos de MDI lorsqu'il nous joue le *ouais moi je suis un mec sérieux dans l'entreprise qui travaille avec du concret, des délais, pas un branleur d'universitaire* ? Le passage que tu as choisi de citer ne donne aucun argument de fond, ne constitue qu'en une attaque gratuite et directe de java. Faut assumer qu'il rentre dans la catégorie "propos agressif" ! Je ne vois pas où est le problème à faire remarquer qu'il s'agit d'un commentaire agressif et non pas d'une information, contrairement à ce que tu sous-entendais dans ta dépêche. Il me semble que linuxfr est censé un minimum éviter de présenter pour information ce qui n'est que parti-pris.
Bien sur, linuxfr pourrait écrire « patrick_g » pense que le propos de MDI prouve le point de vue adopté par l'article. Mais ça aurait sonné un peu bizarre, non ?
[^] # Re: La réécriture des news
Posté par Anonyme . Évalué à 2.
[^] # Re: La réécriture des news
Posté par patrick_g (site web personnel) . Évalué à 2.
N'étant pas développeur je ne suis pas compétent pour juger la pertinence technique de l'article (qui doit être faible vu les messages postés ici).
Je ne connais ni Java ni C# ni Python ni C++ ni même le Basic et, dans mon ignorance, je ne peux pas savoir si, quand Icaza affirme que "Java est inutilement compliqué", il pipote ou pas.
Il me semble AMHA que ce n'est qu'aprés la publication sur le site de ma news que tu aurais pu poster un message disant que l'article ne valait rien et que l'interview était inutilement polémique.
Mais bon y'a pas mort d'homme et je te remercie (toi et les autres) de prendre du temps pour modérer les news.
C'est juste que j'ai lu que DLFP était en demande de contributions de la part de ses inscrits et j'ai essayé de me bouger un peu (à peine une dizaine de news et plus d'un an et demi...j'ai honte).
[^] # Re: La réécriture des news
Posté par Anonyme . Évalué à 1.
Disons qu'il aurait en effet été préférable qu'il soit explicite que le qualificatif agressif est un ajout (NDM: agressif).
« C'est juste que j'ai lu que DLFP était en demande de contributions de la part de ses inscrits et j'ai essayé de me bouger un peu »
En l'état actuel, ta dépêche me semble interessante puisqu'elle permet de mettre au clair certaines choses sur java et mono. Moi non plus je ne connais ni mono ni java et n'ai pas de projets en ce sens. C'est toujours interessant de prendre connaissance de l'avis (argumenté) de ceux qui savent.
[^] # Re: La réécriture des news
Posté par patrick_g (site web personnel) . Évalué à 2.
C'est peut-être un biais mais les contributeurs non-connaisseurs comme moi sont appatés par le sentiment de comprendre et courent le risque de se faire rouler par des articles simples mais mensongers.
Je vois pas trop ce qu'on pourrait y faire à part réserver la publication de news aux gens capables d'analyser vraiment la pertinence des articles cités.
[^] # Re: La réécriture des news
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: La réécriture des news
Posté par Bière Drabo . Évalué à 2.
[^] # Re: La réécriture des news
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
Je ne sais pas comment tu fais pour te qualifier de "neutre" lorsque tu parles de Miguel de Icaza ou de GNOME !!
[^] # Re: La réécriture des news
Posté par gallenza . Évalué à -6.
[^] # Re: La réécriture des news
Posté par Anonyme . Évalué à -1.
Je ne sais pas comment tu fais pour démontrer que cela m'est impossible.
# Je suis content...
Posté par Julien Bidault . Évalué à 4.
Par contre l'article est à chier...s'extasier devant une regexp, et critiquer un autre langage qui est soi disant plus compliqué alors que ca se fait rigoureusement pareil dans les 2, je trouve ca naze...
C'est bien qu'un projet libre voit le jour : mais on s'élève pas en abaissant les autres...pis mono est qd même loin d'etre fini...
[^] # Re: Je suis content...
Posté par syj . Évalué à 0.
Je trouve même étonnant qu'il soit en première page.
Si tous les utilisateurs de LFR poste depeche concernant le dernier tutoriel qu'il vienne de trouver. Je pleins les pauvres modérateurs.
# Bravo l'innovation!!!
Posté par ufoot (site web personnel) . Évalué à 10.
Le leur:
----------8<--------------------------------------------------------------------------
using System;
using System.IO;
using System.Text;
using System.Text.RegularExpressions;
namespace Volume_27
{
///
/// Linux.Ars Volume 27 Example 1
///
class Example1
{
static void Main(string[] args)
{
if( args.Length == 0 )
{
Usage();
Console.ReadLine();
return;
}
String input = "";
for(int i = 0; i < args.Length; i++)
input = input + ((i==0)?"":" ") + args[i];
Console.Write
("Enter a regular expression to test the string \"{0}\": ", input);
String regex = Console.ReadLine();
bool matches = Regex.IsMatch( input, regex );
Console.WriteLine
("\"{0}\" DOES {1} Match \"{2}\"", input, (matches)?"":"NOT", regex);
}
public static void Usage()
{
String ExecPath = Environment.GetCommandLineArgs()[0];
String Executable =
ExecPath.Substring(ExecPath.LastIndexOf(Path.DirectorySeparatorChar) + 1);
Console.WriteLine("-------------------------------------------------");
Console.WriteLine("{0} usage:", Executable );
Console.WriteLine();
Console.WriteLine("\t{0} [Input String]", Executable);
Console.WriteLine();
Console.WriteLine
("\t[Input String]: An input string that should be tested against");
Console.WriteLine("\t the prompted regular expression");
Console.WriteLine();
Console.WriteLine("-------------------------------------------------");
}
}
}
----------8<--------------------------------------------------------------------------
Et le mien:
----------8<--------------------------------------------------------------------------
#!/usr/bin/perl
sub usage {
printf <<EOF
-------------------------------------------------
$0 usage:
$0 [Input String]
[Input String]: An input string that should be tested against
the prompted regular expression
-------------------------------------------------
EOF
}
$input = shift;
if (not $input) {
usage();
<>;
exit(0);
}
printf ("Enter a regular expression to test the string \"$input\":");
$regex = <>;
chomp $regex;
$matches = $input =~ $regex;
printf("\"$input\" does%s match \"$regex\"\n",($matches ? "": " NOT"));
----------8<--------------------------------------------------------------------------
Et maintenant je passe en revue leurs arguments:
1) L'article:
A user of a platform that supports Mono will hopefully see better-quality applications, applications that can just be installed (no compiling, not even for packaging), and applications that are secure.
Ce que j'en dis:
Bullshit marketting. La problématique d'installation dépasse largement le cadre de la compilation. Il n'y a qu'à voir le cas de Java où bien que le bytecode soit parfaitement portable et que la compilation soit souvent faite de manière transparente par les divers environnements de prod (serveurs d'appli par exemple), le packaging est une science en soi. Quand à l'argument sur la sécurité, ça me laisse rêveur.
2) L'article:
Mono also has the concept of garbage collection. Gone are the days of using malloc() and free()
Ce que j'en dis:
Eh oh les copains réveillez-vous ça fait plus de 10 ans que ça existe...
3) L'article:
And now to execute the same exact binary on Linux
Ce que j'en dis:
Certes Perl génère le bytecode à la volée donc la notion de binaire est ici faussée, ceci dit en terme de compatibilité entre les différentes plate-formes .NET a du retard à rattraper, et pas que par rapport à Perl, grosso-modo à part Visual Basic tout le monde est en avance... Mon p'tit programme Perl il marche sur bien plus de machines que celui en Mono.
4) L'article:
The great power of Mono and .NET lies in the ONE line of code:
"bool matches = Regex.IsMatch( input, regex );"
Ce que j'en dis:
The great power of Perl lies in the ONE line of code:
"$matches = $input =~ $regex;"
5) L'article:
Things like Input validation, network communication, file reading and writing, text encoding, regular expressions, formatting, XML Parsing, LDAP Access, remoting, and GUI development are reduced to just a few lines of code compared to possibly hundreds.
Ce que j'en dis:
http://www.cpan.org(...)
6) L'article:
forgue@ahab:~$ ./v27e1.exe Linux.Ars is cool
Enter a regular expression to test the string "Linux.Ars is cool": ^L.*\.C*
"Linux.Ars is cool" DOES Match "^L.*\.C*"
Ce que j'en dis:
Ils utilisent quoi comme shell? Parce que moi bash il m'explose le Linux.Arts is cool en 3 paramètres "Linux.Arts" "is" "cool". Et ce traitement est fait par le shell avant d'envoyer les paramètres au programme donc pour parler "en C" argv[1]="Linux.Arts" et argv[3]="cool". Donc concrêtement sur une machine Linux de base (c'est souvent bash qui est installé mais je soupçonne les autres shells de faire pareil...) leur exemple ne fonctionne pas il faut taper:
forgue@ahab:~$ ./v27e1.exe "Linux.Ars is cool"
avec les guillemets donc.
Ils l'ont vraiment testé leur programme sous un UNIX ou bien ils ont pris l'exemple Windows et remplacé l'invite shell après coup??? J'ai des doutes...
7) L'article:
Console.WriteLine("-------------------------------------------------");
Console.WriteLine("{0} usage:", Executable );
Console.WriteLine();
Console.WriteLine("\t{0} [Input String]", Executable);
Console.WriteLine();
Console.WriteLine
("\t[Input String]: An input string that should be tested against");
Console.WriteLine("\t the prompted regular expression");
Console.WriteLine();
Console.WriteLine("-------------------------------------------------");
Ce que j'en dis:
Et après on va dire que Perl n'est pas clair, honnêtement je trouve la construction avec <<EOF bien plus élégante mais bon.
Bon, pour conclure, je ne critique pas .NET ni Mono je connais pas trop le détail mais je suis pas ébourriffé par la présentation 8-)
PS: Je tiens à préciser que je ne suis vraiment pas expert en Perl ni défenseur de Perl, mais franchement n'importe quel langage de script (Python, Ruby, Perl...) permet de coder leur truc en 2 coups de cuillère à pot. Le problème c'est que leur exemple est mal choisi: un langage compilé est assez inadapté à ce type de code/réalisation. Et ça reflète un problème récurrent de l'industrie logicielle: on utilise souvent les mauvais outils...
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . Évalué à 4.
Ouai, ba ça prouve juste que tu ne sais pas de quoi tu parles. .NET a un modèle de sécurité très évolué, dans le même esprit de celui de Java, qui permet de sandboxed une application de façon très fine, un peu comme les capabilities linux. Et bien entendu, sans aucune coopération de l'application qu'on exécute. A ma connaissance, il n'est pas possible de faire aussi fin et précis en Perl. Cf mon article sur l'architecture de sécurité de Java paru dans MISC (http://www.miscmag.com/articles/index.php3?page=808(...)).
Bon, ceci étant, nous sommes d'accord, l'article est pourri et effectivement, beaucoup des avantages de C#/.NET et de Java par rapport au C et au C++ se retrouve dans les langages comme Perl et Python, par exemple.
[^] # Re: Bravo l'innovation!!!
Posté par Anonyme . Évalué à 6.
Ca prouve surtout que l'article tient des propos qui ne sont pas convaincants. Ca ne signifie pas que ces propos soient faux, ça signifie que les arguments donnés sont impertinents.
Je trouve plutôt salutaire d'adopter une attitude un minimum cartésienne lorsqu'on tripote un sujet qu'on ne maitrise pas, au lieu de gober des propos gratuits, même s'il est possible que ces propos gratuits soient exacts.
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Bravo l'innovation!!!
Posté par bmc . Évalué à 1.
[^] # Re: Bravo l'innovation!!!
Posté par ufoot (site web personnel) . Évalué à 4.
Oui, mais c'est bien ce que je pensais, ce type de protection ne permet que de se dédouaner de problèmes d'accès aux ressources système de la machine locale sur lequel s'exécute le programme. Et la sécurité c'est bien plus que çà. On peut faire du gruyère sandboxé, sans problèmes. C'est pour ça que je dis que c'est du "bullshit marketting". Ca permet de colmater des brèches et ça facilite le travail du développeur pour border son appli.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Ceci étant dit:
perl + sandbox sur Google (3ème lien):
http://secu.zzu.edu.cn/book/Perl/Perl%20Bookshelf%20%5B3rd%20Ed%5D/(...)
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
[^] # Re: Bravo l'innovation!!!
Posté par boubou (site web personnel) . Évalué à 2.
Maintenant je pense qu'on est d'accord les diverses techniques d'isolation des process sont toujours plutôt meilleures que "rien du tout je risque de laisser /etc/shadow en lecture et en plus je risque le buffer overflow", m'enfin ça ne suffit pas à faire une appli sécurisée, et l'article prête à confusion.
Bof. Avec les techniques modernes de sandboxing tu peux contrôler exactement ce à quoi ton programme a accès, fichier par fichier, socket par socket, etc. Tu peux mettre en place une véritable politique de sécurité extrêmement fine et sans aucune coopération du programme que tu exécutes. En fait, tu as un niveau de contrôle qui est comparable à celui offert par le noyau linux associé aux capabilities. Un peu comme si tu créais un utilisateur spécifique pour faire tourner un programme et que tu contrôlais exactement ce à quoi il a accès. Et je ne parle même pas des mécanismes de signature de code. Ok, l'article prête à confusion, mais les machines virtuelles permettent tout de même de faire beaucoup plus de choses que ce qu'on peut faire en C ou en C++. Donc évacuer ça par "bullshit marketting", c'est exactement du même niveau que de dire que l'extension NX des AMD est du marketing. C'est faux, même si ça ne résout pas tous les problèmes...
Ceci étant dit:
perl + sandbox sur Google (3ème lien):
http://secu.zzu.edu.cn/book/Perl/Perl%20Bookshelf%20%5B3rd%20Ed%5D/(...))
Je dis pas que ça fait tout ce que fait .NET, mais il faut toujours se méfier des phrases du type "Perl ne sait pas faire", j'en ai déjà fait les frais 8-)
Oui, oui, je connais le mode safe de perl, mais bon, ce n'est vraiment qu'une partie infime de ce qu'on peut faire avec Java ou .NET.
[^] # Re: Bravo l'innovation!!!
Posté par Yhar Gla . Évalué à 3.
Ça je me demande bien! Quand je fais
$ ./v27e1.exe
bash: ./v27e1.exe: cannot execute binary file
Alors que
$ mono v27e1.exe
ça fonctionne. Je pense qu'il ont pas testé mais juste écrit des lignes de commande bidons.
[^] # Re: Bravo l'innovation!!!
Posté par kruskal . Évalué à 5.
Avec binfmt-misc il est possible pour le kernel de lancer quasiment n'importe quel type de binaire. Il suffit de lui dire quelles extentions de fichier ou quels magic-codes associer avec tel ou tel interpréteur
[^] # Re: Bravo l'innovation!!!
Posté par hex . Évalué à 4.
http://www.mono-project.com/about/technical.html(...)
(cf. question/réponse numéro 53)
[^] # Re: Bravo l'innovation!!!
Posté par gc (site web personnel) . Évalué à 7.
Mono also has the concept of garbage collection. Gone are the days of using malloc() and free()
Ce que j'en dis:
Eh oh les copains réveillez-vous ça fait plus de 10 ans que ça existe...
Tu veux plutôt dire "ça fait près de 50 ans que ça existe", sûrement ?
L'idée et l'implémentation d'un garbage collector remonte à Lisp, et Lisp remonte à 1958.
[^] # Re: Bravo l'innovation!!!
Posté par Flink . Évalué à 6.
---> [encourant]
[^] # Re: Bravo l'innovation!!!
Posté par jde . Évalué à 1.
The great power of Mono and .NET lies in the ONE line of code:
"bool matches = Regex.IsMatch( input, regex );"
Ce que j'en dis:
The great power of Perl lies in the ONE line of code:
"$matches = $input =~ $regex;"
Et puisqu'on les compare toujours, j'ajoute :
The great power of Java lies in the ONE line of code:
"boolean matches = Pattern.matches(regex, input);"
[^] # Re: Bravo l'innovation!!!
Posté par gc (site web personnel) . Évalué à 1.
[^] # Re: Bravo l'innovation!!!
Posté par gnujsa . Évalué à 2.
Les guillemets sont facultatifs car il n'y a qu'un argument en paramètre. On peut donc récuperer tout les arguments en une seuls chaine (en faite un tableau)
par exemple:
"@ARGV" en perl
"$@" en shell script
Dans ton exemple il suffit de remplacer :
$input = shift;
par
$input = "@ARGV";
Ça doit certainement être possible avec le language de Micro^W^W^W avec Mono. D'ailleurs j'ai l'impression qu'il s'agit aussi d'un tableau d'arguments:
[...]
String input = "";
for(int i = 0; i < args.Length; i++)
input = input + ((i==0)?"":" ") + args[i];
[...]
c'est fou ce que ça l'air simple comparé à $input = "@ARGV";
;-)
[^] # Re: Bravo l'innovation!!!
Posté par Black Fox . Évalué à 2.
String input = "";
foreach(string arg in args)
{
input += ((i==0) ? "":" ") + arg;
}
# Mouais...
Posté par Yhar Gla . Évalué à 2.
Je suis d'accord avec tous ceux qui trouvent que c'est abuser de juger Mono supérieur à Java sur un test de 2 petits programmes. On a même pas l'équivalent Java pour comparer. Et puis quand bien même Mono serait plus adapté au dev, se poserait encore la question des perfs.
Pis en plus le 2eme exemple il compile pas chez moi:
$ mcs dialog.cs
dialog.cs(7) error CS0246: Cannot find type `Window'
Compilation failed: 1 error(s), 0 warnings
Il me manque un truc? J'ai installé gtk-sharp pourtant et j'ai fait
$ export MONO_PATH=/usr/lib/mono/gtk-sharp/gtk-sharp.dll
Ou que j'ma gouru (à part que j'ai jamais lu aucune doc à propos de .Net et Mono :)?
[^] # Re: Mouais...
Posté par TImaniac (site web personnel) . Évalué à 2.
mais de toute façon tu auras un autre problème : il n'y a pas de point d'entrée dans le code (pas de Main) donc ca râle logiquement à la compilation.
Leur exemple est basé sur MonoDevelop qui créé une deuxième classe qui contient le point d'entré et la création d'une instance de la fenêtre codée.
# Mon grain.
Posté par Homer . Évalué à -2.
Pourquoi? Soit disant l'origine microsoftienne. Plus serieusement, tout n'est pas dans la phrase: "nous avons 18 mois de retard sur microsoft"? Si gnome se sert d'un tel projet, combien d'entre vous pensent que c'est du suicide?
On fait la guerre à m$ depuis des lustres, et c'est pour se retrouver handicapé par ce mono. Ok, il est plus probable que gnome soit raisonnable et opte pour autre chose. Mais alors, à quoi sert mono si aucun desktop ne veut de lui? Car il ne faut pas s'y tromper: Java est au TOP de sa forme. Java n'a jamais aussi bien marché. Et maintenant java est utilisé par d'autre personnes que des branleurs d'universitaires.
Non, serieusement, je leur souhaitent bien du courage...
ps: oui vous avez compris, mono ça me fait bien rire
[^] # Re: Mon grain.
Posté par Pinaraf . Évalué à 3.
Et puis, avantage de mono : ils sont compatibles avec ASP.net par exemple, ce qui pourrait faciliter les migrations.
Java a l'avantage de l'ancienneté et du fait qu'il soit reconnu, mais il a pris une baffe à cause des conneries de VM microsoft
[^] # Re: Mon grain.
Posté par Homer . Évalué à 3.
Il faut faire la distinction entre les projets qui sont absoluments nécessaires, comme XUL, car rien n'existait auparavent, et ceux qui sont là pour proposer une alternative. Le java d'aujourd'hui à t'il vraiment atteint ses limites? Avions-nous absolument besoin de mono?
[^] # Re: Mon grain.
Posté par hex . Évalué à 1.
Mais c'est une prouesse technique.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 0.
Tu me montres ca ?
[^] # Re: Mon grain.
Posté par Pinaraf . Évalué à 1.
En vérité, Mono est inutile et non libre :)
Mais c'est une prouesse technique.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 1.
Oui, de meme rien ne prouve que d'autres projets libres ne seront pas attaques eux non plus par une societe X pour non respect de brevet, pourtant ca ne les empeche pas d'avancer.
D'autre part, MS n'a jamais utilise l'arme des brevets de maniere offensive. Ils le pourraient tres facilement, ils ne l'ont jamais fait.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 1.
Cette affirmation est totalement dépourvue d'intérêt. Le fait qu'ils pourraient le faire très facilement est le point important. Ils ne se genent pas pour des pratiques illégales, alors si c'est légal on se doute bien que ça ne leur posera aucun problème.
[^] # Re: Mon grain.
Posté par Éric (site web personnel) . Évalué à 2.
à défaut d'avoir une boule de cristal, savoir ce qu'ils ont déjà fait sur le sujet en question me parait au contraire une information diablement intéressante ...
Oui, peut être qu'ils ont la possibilité. Maintenant ils ont aussi probablement la possibilité dès demain de racheter Suse RedHat Ximian et Mandrake ... et racheter les boites commerciales qui se montent sur le sujet. Sans forcément tout arrêter notre GNU/Linux ça mettrait probablement beaucoup de foutrait probablement du plomb dans l'aile pour notre OS et nos solutions (surtout du coté commercial). Faut-il pour autant arrêter tout ?
Ah ben oui ... avec des "si" on peut faie beaucoup de choses. Le fait est que pour l'instant de ce coté là ils jouent globalement le jeu alors qu'ils pourraient faire autrement.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 1.
à défaut d'avoir une boule de cristal, savoir ce qu'ils ont déjà fait sur le sujet en question me parait au contraire une information diablement intéressante ...
J'ai parlé de l'affirmation de notre propagandiste, pas de la discussion sur le sujet.
> Ah ben oui ... avec des "si" on peut faie beaucoup de choses. Le fait est que pour l'instant de ce coté là ils jouent globalement le jeu alors qu'ils pourraient faire autrement.
As-tu vu que j'ai répondu à un seul de ses paragraphe et non au deux ? Indice ? Merci de ne pas me faire dire ce que je n'ai pas dit. On est probablement d'accord sur le fond.
[^] # Re: Mon grain.
Posté par Yusei (Mastodon) . Évalué à 2.
En tout cas ce n'est sûrement pas par bonté d'âme. Et donc c'est plutôt une bonne chose, parce que la bonté d'âme c'est sûrement moins "stable" qu'un intérêt pragmatique ;-)
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à -2.
[^] # Re: Mon grain.
Posté par yoplait . Évalué à 0.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à -1.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 2.
Il y a ta paranoia et tes insultes envers les gens qui ne sont pas d'accord avec toi, et il y a la realite.
La realite : MS n'a jamais utilise les brevets comme arme offensive.
T'appelles ca du FUD.
Tu m'expliques ou est le fear, uncertainty ou doubt dans cette affirmation que tout le monde reconnait comme vraie ?
[^] # Re: Mon grain.
Posté par gnujsa . Évalué à 3.
Ils pouvaient le faire, ils ne l'ont pas fait, donc, il ne le feront pas. (allez-y, foncez sur mono)
C'est absolument pas evident. Aujourd'hui, MS regne en maitre sur le marché des OS. Si demain, la balance s'inverse, pourquoi n' utiliseraient-il pas leurs brevets ? On voit avec l'exemple de SCO, qu'une entreprise a l'agonie peut vraiment faire n'importe quoi. A ce moment là, si Gnome et une grande partie des LL utilisent Mono, il sera trop tard. C'est maintenant qu'il faut se poser ce genre de question. Les enjeux sont beaucoups trop important.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 2.
Et meme en imagineant un scenario pareil, cela vaudrait aussi pour les autres composants de Linux qui potentiellement couvriraient des patentes, et pas seulement des patentes MS, il n'y a pas que MS qui a la possibilite de lancer des proces. Bref, Mono n'est pas specialement plus vulnerable ou plus risque que les autres composants majeurs d'une distrib Linux
[^] # Re: Mon grain.
Posté par Anonyme . Évalué à 0.
Par contre, je ne vois pas en quoi cela démontre que « Mono n'est pas specialement plus vulnerable ou plus risque que les autres composants majeurs d'une distrib Linux ».
1. Mono n'est pour le moment aucunement un composant majeur des distribs GNU/Linux
2.Par quelle magie tout les autres projets composant GNU/Linux seraient tous aussi dépendants de brevets ?
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 2.
Il y a tellement de patentes que c'est tres difficile de les eviter, d'ou la pratique d'amasser un portfolio de patentes plus gros que le voisin histoire de lui dire "tais-toi sinon je te poursuis aussi"
[^] # Re: Mon grain.
Posté par gnujsa . Évalué à 0.
Que Gnome ou KDE repose sur une base aussi fragile, ferait surement plaisir à MS...
[^] # Re: Mon grain.
Posté par yoplait . Évalué à 2.
Chut. En cas de pepin avec un brevet, deux autres solutions bien moins embetantes s'offrent aux developpeurs : Faire jouer le prior art, si il y a moyen de prouver que cette technique a ete realisee avant. Trouver un workaround pour eviter de violer le brevet, ce qui est souvent voire toujours faisable.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 1.
Je n'insulte pas les gens qui ne sont pas d'accord avec moi, ou du moins il y a énormément de gens avec qui je ne suis pas d'accord (tous ? on est tous différents a priori) que je n'insulte pas, tout simplement parce qu'il sont capables de mener une discussion sensée. Mais pour les fudeurs et petits collabos comme toi, c'est vrai que je ne me retiens pas.
> La realite : MS n'a jamais utilise les brevets comme arme offensive.
> T'appelles ca du FUD.
> Tu m'expliques ou est le fear, uncertainty ou doubt dans cette affirmation que tout le monde reconnait comme vraie ?
C'est un abus de langage, ici il s'agit au contraire d'une note positive, une propagande pour MS, mais c'est sans doute de ça que tu parles aussi. C'est un fud inversé :)
C'est tout simple : tu présentes MS comme boite qui pose des brevets et ne les utilise pas. C'est faux, ça ne concerne que le passé. La phrase proprement dite est évidemment vraie : toute propagande, tout mensonge, pour convaincre, doit se baser sur un élément vrai, et le détourner. Tu t'en es servi de manière à sous-entendre (et encore, sous-entendre est faible) que MS ne s'en servira pas à l'avenir. C'est ce que tu fais systématiquement ici (à croire que tu l'as appris chez les dirigeants MS) : matraquer des vérités qui ne sont pas les points intéressants, qui en évoquent d'autres, mais ces autres points ne sont pas garantis. De le propagande classique.
[^] # Re: Mon grain.
Posté par Pinaraf . Évalué à 2.
Un DUF quoi...
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 1.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 2.
Ah, collabo, comme c'est mignon, on sent le gars qui reflechit avec son cerveau.
tu présentes MS comme boite qui pose des brevets et ne les utilise pas. C'est faux, ça ne concerne que le passé.
Oui, car comme tout le monde je ne peux pas deviner le futur, donc je me base sur le passe, comme tout le monde fait.
C'est marrant, parce que a peu pres tous ceux qui critiquent MS ici pour ses pratiques se basent sur son comportement passe pour cela.
Faut savoir, on peut utiliser le passe de MS pour alimenter des idees de complots futurs, mais on ne peut pas le faire de maniere positive ?
Tu te moques de qui ?
C'est ce que tu fais systématiquement ici (à croire que tu l'as appris chez les dirigeants MS) : matraquer des vérités qui ne sont pas les points intéressants, qui en évoquent d'autres, mais ces autres points ne sont pas garantis. De le propagande classique.
Ben oui, tout comme ceux qui se basent sur les pratiques illegales passees de MS pour dire qu'elle va faire des coups de pute dans le futur, c'est pas garanti, c'est de la propagande classqiue, et tu en es tout autant coupable que moi.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à -1.
Si tu as une critique à faire, exprime-toi. J'emploie les termes qui me semblent appropriés, et dans ce cas pas à la légère.
> Faut savoir, on peut utiliser le passe de MS pour alimenter des idees de complots futurs, mais on ne peut pas le faire de maniere positive ?
Non, c'est logique, car comme le disait Yusei, on se doute que si les brevets ne sont pas utilisés c'est pas par principe, c'est pour l'instant leur intérêt. Aucune raison donc de s'y fier.
> Tu te moques de qui ?
Regarde n'importe quel attitude similaire à un « principe de précaution » et tu verras que c'est exactement la même chose, et il est naturel d'avoir cette approche ici : le passé démontre la malhonnêteté de MS, et qu'ils se soient retenus sur un point ne garantit rien pour l'avenir. Quelle mauvaise foi que de prétendre que ceci n'est pas une attitude prudente et logique !
> Ben oui, tout comme ceux qui se basent sur les pratiques illegales passees de MS pour dire qu'elle va faire des coups de pute dans le futur, c'est pas garanti, c'est de la propagande classqiue, et tu en es tout autant coupable que moi.
Qu'elle va en faire, personne ne dit ça, apprend donc à lire. Qu'on ne peut pas s'y fier, ça oui. Tu comptes aussi nous apprendre qu'il faut faire confiance en la bonté des entreprises malgré la logique de profit ? Tu vis dans ton propre monde, ou plus probablement tu sais que tu emploies ces arguments capitalistes fallacieux (d'où mon adjectif de collabo, tu vois, ce n'était pas gratuit).
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 4.
Oui, oui, on a bien compris, pour toi quelqu'un qui travaille avec Microsoft est comparable à quelqu'un qui travaillait avec le régime de Vichy. Bravo, tu es vraiment très fort, tu as gagné ton point Godwin et tu as accessoirement démontré que tu n'étais pas quelqu'un de fréquentable, ce qui va simplifier nos interactions futures.
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 0.
Certainement pas. Qu'est-ce que c'est que ces affirmations dégueulasses ? Je ne compare personne à ça, pas plus PBPG que quiconque, et ce que je dis de lui ne concerne pas son travail chez MS (on peut travailler pour des raisons financières sans partager l'idéologie de son supérieur) mais ses propos.
N'ayant plus rien à dire tu ne trouves pas mieux que ce genre d'accusations infondées, et dont tout le monde peut constater qu'elles sont fausses ? C'est vraiment lamentable.
> Bravo, tu es vraiment très fort, tu as gagné ton point Godwin et tu as accessoirement démontré que tu n'étais pas quelqu'un de fréquentable, ce qui va simplifier nos interactions futures.
Mauvaise foi, ignorance ou bêtise je ne sais pas, alors au cas où, je te rappelle un truc que tu n'as pas compris à propos du point Godwin : il faudrait que j'aie fait l'association dont tu m'accuses pour qu'il soit fondé, or ce n'est bien évidemment pas le cas. D'où sors-tu cette prétendue comparaison, ton vocabulaire n'est quand même pas à ce point limité ?
[^] # Re: Mon grain.
Posté par Yusei (Mastodon) . Évalué à 3.
Tu dis juste que c'est "dépourvu d'intérêt" :-) (je ne suis pas doué du tout pour lire entre les lignes, ça s'est vu ?)
Comme je le disais, je trouve que l'affirmation "ils ne s'en sont jamais servi" permet effectivement de penser qu'ils ne s'en serviront pas par la suite, si on suit le raisonnement que j'ai fait (ie. ils ne s'en servent pas parce que ce n'est pas dans leur intérêt). Ce n'est certainement pas une garantie, mais c'est un élément de réflexion.
(Ça me fait penser à l'histoire d'un poulet qui, observant que les fermiers le nourrissaient et ne lui faisaient pas de mal, en tira la conclusion qu'il était en sécurité, tout ça)
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 1.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 2.
Bof. Dans le cas présent, on sait qu'il y a des brevets et on sait que MS ne sait pas engagé à faire du royalty free. Pour les standards du W3, on sait en général qu'il n'y a pas de brevet dans les grosses boites qui sont membres du W3 (ce qui élimine pas mal de monde) ou que les licences sont royalty free. C'est le cas aussi pour pdf par exemple.
D'autre part, MS n'a jamais utilise l'arme des brevets de maniere offensive. Ils le pourraient tres facilement, ils ne l'ont jamais fait.
En effet et c'est un point important. Ceci étant, MS est actuellement en très bonne santé. Si Mono lui cause beaucoup de tord, que se passera-t-il ?
Tout ça pour dire que Mono n'est pas une solution aussi pérenne que C++ associé à des bibliothèques libres car le risque existe et est identifié. On ne peut pas en dire autant de Java, contrairement à ce que beaucoup de gens affirment (je ne te mets pas dans ce groupe).
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 1.
Quid de Samba ?
Ceci étant, MS est actuellement en très bonne santé. Si Mono lui cause beaucoup de tord, que se passera-t-il ?
Personne ne le sait, de meme personne ne sait ce qui arrivera a Samba, pourtant tout le monde supporte le developpement de Samba.
[^] # Re: Mon grain.
Posté par gnujsa . Évalué à 4.
Rien avoir. Dans un monde rempli de Linux ( et de UNIX libre), samba ne sert à rien. Samba sert juste à communiquer avec des machines Windows. Si MS utilise ses brevets contre samba, ça ne m'empechera pas d'utiliser Linux. Ça n'empechera pas sa progression non plus. Tout au plus ça rendra les migrations "partiel" plus difficile (ou ça les rendra plus radical). Imagine que des applications comme Gnome, Gimp, Mozilla, etc.. se mettent à utiliser mono, et que MS se mette à utiliser leurs brevet, ça porterait un coup fatal au «Desktop Linux».
Les enjeux avec samba sont beaucoups plus faible.
D'ailleurs, un jour, Samba et Wine ne serviront plus à rien ;-)
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 3.
1) Windows sera encore dominant pendant des annees(3,4, 10 ,20,... personne ne sait vraiment)
2) sans Samba, pas d'interop Linux <-> Windows, donc bloquage enorme a l'entree de Linux dans les entreprises
--> Samba est certainement bcp plus vital a Linux aujourd'hui que Mono le sera dans 2-3 ans
[^] # Re: Mon grain.
Posté par TImaniac (site web personnel) . Évalué à -1.
Bref, Microsoft pourra toujours faire valoir ses brevets sur la partie Windows.Form par exemple, mais celà n'affectera pas les applications développées POUR Linux avec GTK# & Co.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 3.
Ba oui, on l'oublie parce que c'est FAUX. Cf mon vieux post : http://linuxfr.org/comments/441211.html#441211.(...) En résumé, l'ECMA demande du RAND et la partie soumise à l'ECMA est bien brevetée (cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)).
Ce qu'il y a de fou, c'est que tu nous as déjà fait le coup pour ta news qui présentait Mono 1.0 comme le messie et que je t'ai déjà répondu en te citant un des inventeurs de .NET, mais tu persistes à diffuser ces mensonges. Ca devient pénible.
Alors, moi aussi, je radote. Pour implémenter CLI et C#, il faut utiliser des méthodes brevetées par MS et MS ne s'est engagé qu'à faire du RAND, point final.
Bien sûr, GTK# n'est pas breveté par MS, mais comme il faut un compilateur C# et une machine virtuelle CLI pour le faire tourner, on s'en fout.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 2.
But the first question that those third parties must ask is whether another commercial deployment of the CLI standard--say, for Linux or Unix--could infringe on a Microsoft patent. According to Microsoft's director of intellectual property Michele Herman, who I interviewed earlier this year, the answer is a qualified yes
According to Herman, third parties will have to enter into a reasonable and non-discriminatory (RAND) license agreement with Microsoft. "But," says Herman, "while RAND sometimes means there could be a financial obligation, [Microsoft] ...will be offering a conventional non-royalty non-fee RAND license. We've always made that clear to anyone who has asked." In other words, there will be no financial obligation.
La directrice de l'IP chez MS elle-meme dit que la licence sera gratuite.
[^] # Re: Mon grain.
Posté par Anonyme . Évalué à 2.
Le reste n'est à ce stade que prévisions.
[^] # Re: Mon grain.
Posté par TImaniac (site web personnel) . Évalué à 0.
Au lieu de blablatérer sur les brevets et leurs risques pour Mono, réfléchi plutôt pourquoi Microsoft a déposé des standards à l'ECMA et à l'ISO, pourquoi Microsoft a fait Rotor, pourquoi les ingé de Microsoft ne se font pas virer pour avoir bien voulu répondre aux questions des développeurs de Mono, pourquoi De Icaza était invité aux "meetings" Microsoft... Peut-être parcque Microsoft pense que celà peut être bon pour eux que leur techno soit réutilisée. Bref, quand ils disent que la licence sera gratuite, celà va complètement dans ce sens, et j'ai franchement du mal à suivre ton raisonnement... regarde le fond et les intérêts de chacuns plutôt que d'essayer de discréditer une techno parcque t'aime pas Microsoft.
[^] # Re: Mon grain.
Posté par jmfayard . Évalué à 4.
2 plate-formes globalemet équivalentes
JAVA : 1 langage imposé, MULTI-plateforme
.NET: Multi-langages, MONO PLATEFORME
Argument auquel Microsoft peut désormais répondre : pas tout à fait, il y a la PLATEFORME MONO
Donc MONO enlève une épine du pied à Microsoft... A condition que ça ne vienne pas empiéter sur ses plate-bandes en pratique, ce qui serait le cas si les business qui comptent utiliseraient vraiment une autre plateforme que la leur. C'est là qu'intervient le fait que mono n'aura jamais l'API complète de .Net, que Mono sera toujours en retard sur .Net (18 mois pour l'instant d'après Miguel lui même) et que l'épée de Damoclès des brevets sur .Net reste délicieusement suspendue (rappelons que comme l'a énoncé Redhat récemment, même un brevet RAND+Free est contraire au principe de logiciel libre : parfait pour les compagnies, mauvais pour le dévelopeur de LL (va t'on signer un contrat de brevets avec Microsoft)), et que Microsoft aura toute latitude légale ou médiatique si besoin est.
Donc, pour répondre à ta question, Microsoft a intérêt à la fois à ce que Mono existe, et à ce que l'épée de Damoclès reste planante.
[^] # Re: Mon grain.
Posté par TImaniac (site web personnel) . Évalué à 2.
Q:Parlons un peu des brevets logiciels, un sujet sensible depuis quelques mois. Parmi les brevets déposés par Microsoft, citons "le double clic sur les pocket PC" ou encore la "todo list auto-générée". Pourquoi ces brevets ? Est ce en prévision de procès envers d'autres sociétés ?
R:Les brevets logiciels sont un sujet sensible actuellement, particulièrement lorsqu'ils proviennent de Microsoft. Il faut savoir que certains de nos concurrents nous dépassent "haut la main" en termes de nombres de brevets déposés A ma connaissance, Microsoft n'a jamais fait jouer de façon rétroactive ses brevets.
Ces brevets sont à comprendre comme des protections contre d'éventuels procès. C'est le cas, par exemple, du procès Eolas, un procès qui à terme risquait de paralyser non seulement Microsoft mais aussi toute l'industrie en interdisant l'utilisation de plugins dans les applications, et en particulier dans Internet Explorer.
Donc oui, ces brevets servent à nous prémunir de ces procès, et Microsoft a clairement communiqué sur le fait que nous accordons des droits d'utilisations gratuits de ces techniques faisant l'objet de dépots de brevets, comme par exemple les Schémas XML de Office 2003.
Si Microsoft a clairement communiqué sur le sujet, je pense qu'il doit y avoir moyen de trouver un communiqué... Enfin en tout cas Microsoft laisse quand même sous-entendre à quoi leur servent les brevets...
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 2.
Soit, mais elle dit aussi qu'il faut un accord explicite. Novell/Ximian n'a pas cet accord explicite. Quand ils l'auront, on en reparlera. Soit dit en passant, ça me rejouirait car C# et .NET en général sont vraiment des technologies impressionnantes.
[^] # Re: Mon grain.
Posté par TImaniac (site web personnel) . Évalué à 3.
But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went
further and have agreed that our patents essential to implementing C#
and CLI will be available on a "royalty-free and otherwise RAND" basis
for this purpose.
Ok c'est pas exactement royalty-free que demande l'ECMA mais bien RAND, mais le fait est que celà reste royalty-free quand même (cf citation).
Ce qu'il y a de fou, c'est que tu nous resors la même chose à chaque fois, et que tes citation te contredise, même si mes propos ne sont pas exact, l'idée y est. Il doit y avoir que toi à vouloir traduire l'anglais comme bon te semble...
[^] # Re: Mon grain.
Posté par Anonyme . Évalué à 2.
Ben non « royalty-free and otherwise RAND » ne signifie pas que ça reste royalty-free dans tout les cas mais bien que cela sera royalty-free ou sinon RAND.
[^] # Re: Mon grain.
Posté par boubou (site web personnel) . Évalué à 3.
Mauvais exemple. Oui, tout le monde supporte samba, mais personne ne demande d'abandonner NFS à son profit. Le problème avec Mono n'est pas tant qu'il pourrait se faire atomiser par MS, c'est plutôt que De Icaza et d'autres voudraient en faire LA solution pour continuer à developper Gnome. Personnellement, que MS atomise samba, ça me gênerait pour collaborer avec certains collègues un peu bornés, mais çe ne m'empêcherait pas de bosser. Par contre, si certaines futures applis incontournables de Gnome sont développées avec Mono et que Mono est abandonné à cause d'une action légale de MS, ça pourrait me gêner beaucoup plus. I
[^] # Re: Mon grain.
Posté par Bière Drabo . Évalué à 2.
Et donc la conclusion c'est ça : personne ne sait. Et non le faussement rassurant « MS ne fait rien » que tu as essayé de faire passer ailleurs.
[^] # Re: Mon grain.
Posté par Black Fox . Évalué à 2.
Le seul problème est pour l'implémenteur (Mono) qui bien qu'il n'y ait pas de royalties (truc à payer par client), ça ne veut pas dire qu'il n'y auras pas un cout pour lui (pour payer le droit d'uitlisation du brevet)
Pour l'instant l'équipe de Mono n'as pas l'air de trouver de problèmes à ça... mais dans tout les cas l'utilisateur n'auras pas à payer.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 6.
C'est quoi le probleme de Java ? Qu'un soft ne tourne pas sur les differentes plateformes ? Non, le probleme c'est la lenteur pour les applis desktops, le manque de softs Java, ...
Et ca MS n'y est pour rien, c'est Sun qui a mal vendu son truc.
[^] # Re: Mon grain.
Posté par Pinaraf . Évalué à 1.
[^] # Re: Mon grain.
Posté par Sebastien Cesbron . Évalué à 6.
Je suis personnellement développeur java côté serveur et j'ai de plus en plus envie d'écrire des applis linux. Mon pb c'est que pour moi il y a un manque sous linux c'est la disponibilité d'un langage de haut niveau type Java C# pour écrire des applis. Y 'a t'il parmis vous des devins pour me dire de quoi l'avenir sera fait ?
Pour ce qui est de la mise en open source de java les choses bougent (notamment grâce à mono) mais sun est encore très réticent. Un autre problème de java est qu'il y a actuellement une mini guerre interne à l'intérieur de la communauté jav. Si vous devez écrire une appli java il faut choisir entre Swing (qui d'un point de vue conception est quand même très bien gaulé et qui est de plus en plus rapide) et swt (la base d'eclipse qui est selon moi la meilleure plateforme de développement actuelle).
En tous cas je suis intimement persuadé qu'aller vers Mono est très dangereux pour Linux. Il ne faut pas oublier les capacités d'adaptation de Microsoft (la rapidité à laquelle Netscape à disparu). Mono permet à Microsoft de se rapprocher de Linux et nul ne sait ce qu'il peut faire ensuite
Mes 2 centimes
Seb
[^] # Re: Mon grain.
Posté par psycose . Évalué à 2.
ta question m'as subitement interpellé,
l'avenir est ce que l'on en fait, et moi de ce coté là :-°, j'ai bien l'impression de choisir Ada
suite à ta question, je t'invites donc à (re)jetter un oeil de ce côté là pour des applis de meilleurs __qualités__
korek ça !
[^] # Re: Mon grain.
Posté par Frédéric Lopez . Évalué à 2.
Les applis clientes Java fonctionnent peut-être à une vitesse acceptable de nos jours (encore que j'aie quelques doutes), mais le problème de Java c'est qu'il traîne une mauvaise réputation depuis un sacré bout de temps. On est quand même passé en quelques années de PC à 133Mhz/32Mo à des PC à 2Ghz/512Mo et c'est vrai qu'à l'époque, Java c'était inutilisable sur le desktop.
> Mon pb c'est que pour moi il y a un manque sous linux c'est la
> disponibilité d'un langage de haut niveau type Java C# pour écrire
> des applis.
Tu blagues là non ? Ou alors je serais curieux de connaître ta définition d'un "langage de haut niveau"...
> Y 'a t'il parmis vous des devins pour me dire de quoi l'avenir sera
> fait ?
Oui, tu as de la chance, j'en ai justement un sous la main, et il me dit que l'avenir ne sera pas fait d'un unique langage mais d'une multitude, comme c'est le cas actuellement, et que ça n'aura toujours aucun sens de ne maîtriser qu'une seule technologie...
> Mono permet à Microsoft de se rapprocher de Linux et nul ne sait
> ce qu'il peut faire ensuite
Mono n'est que l'implémentation d'un language dont les spécifications ont été définies par Microsoft.
Faut arrêter la parano, c'est pas l'Etoile Noire de l'Empire non plus...
[^] # Re: Mon grain.
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Je devrais m'amuser à refaire tourner mes vieux benchs sur mes babasses d'aujourd'hui ...
http://www.redfoxcenter.org/Java/benchmark.html(...)
[^] # Re: Mon grain.
Posté par Yusei (Mastodon) . Évalué à 10.
C'est ridicule, l'éventuelle compatibilité de Mono avec le .NET de Microsoft n'a aucune influence sur le fait que ce soit un bon ou mauvais framework pour développer Gnome. Quoi qu'il arrive, et même si MS se met à faire n'importe quoi pour rendre Mono incompatible avec son .NET, ça ne le rendra pas inutilisable pour autant.
Quoi que l'on pense de Mono, c'est une plateforme de développement libre de plus, je ne vois pas en quoi cela pourraît être une mauvaise chose.
Par contre, que Mono puisse être un jour une alternative viable à .NET, c'est plus discutable.
[^] # Re: Mon grain.
Posté par pasBill pasGates . Évalué à 4.
A l'epoque de la sortie des kernels 2.4 et 2.6, j'ai vu une publicite importante faite autour de ces 2 noyaux, les devs avaient peur que leur projet n'interesse personne ?
Si gnome se sert d'un tel projet, combien d'entre vous pensent que c'est du suicide?
Pas moi.
MS pourrait transformer .NET en un API Klingon extra-terrestre que Gnome continuerait toujours de tourner.
On fait la guerre à m$ depuis des lustres, et c'est pour se retrouver handicapé par ce mono.
En quoi est-ce un handicap ?
Qu'est ce que Mono fait qui rendrait les choses moins bien qu'elles ne sont aujourd'hui ?
[^] # Re: Mon grain.
Posté par Erwan . Évalué à 4.
C'est qui "on" ? C'est toi ?
# MONO, Mac OS X et Xcode
Posté par pepie34 . Évalué à 1.
Plus compliqué, est-ce que Windows.Form est disponible grâce à Darwine?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.