Ben avec la méthode GAPI t'as pas besoin des libs qui fonctionnent :)
Chacun ses dépendances mais ca change rien aux objectifs et aux résultats obtenus : avec GAPI t'obtient les méthodes, les signaux, l'arbre d'héritage, etc.
Bref comme je l'ai dis seule l'approche est différente, mais il y en a un qui est éprouvé.
Attend mais je compare ce qui est comparable : C# et Java ont la même syntax pour les generics, ils pouvaient donc faire les même choix de conception. Comparer l'asm avec un langage de haut niveau est stupide puisque comme leur nom l'indique ils ne sont pas de même niveau, n'ont pas la même sémantique, etc.
Si tu lis mes posts tu t'apercois que le problème que tu cites est sans incidence réelle.
Si tu lis mes posts cela peut avoir une incidence réelle, je penses notamment aux scénarios d'introspection. C'est d'ailleur comme ca que je suis tombé sur le problème en Java : je testais des types et je ne comprennais pas pourquoi cet andouille me répondait qu'un ArrayList c'est pareil qu'un ArrayList.
J'ai aussi voulu montrer qu'un choix de conception dans le langage peut avoir un impact non négligeable dans certains scénarios.
En l'état actuel tu trouveras très peu de code où il y a le problème puisqu'il n'y a pas encore grand monde à avoir utilisé les generics.
Autant je trouve l'approche intéressante (introspection), autant je trouve qu'il n'y a rien de nouveau sous le soleil dans les objectifs.
Sans vouloir encore et toujours la ramener à Mono, mais ils génèrent leurs bindings pour GTK+, Gnome et autre GStreamer en utilisant depuis le début un outil qui répond aux même objectifs : créer automatiquement les bindings.
L'utilitaire en question, c'est GAPI : http://www.mono-project.com/GAPI(...)
L'approche est différente puisque ce sont les en-tête .h qui sont parsés et non un système d'introspection. Le résultat est le même (bien qu'on puisse récupérer un peu plus d'info dans le .h, comme le nom des arguments) et n'est plus du tout expérimental dans Mono.
De plus l'utilitaire génère une description au format XML des API, un 2ème utilitaire permet de "patcher" au besoin (parcque ce n'est jamais parfait, ou pour modifier le design pour qu'il colle un peu plus au langage cible) et enfin un autre utilitaire qui génère le binding à partir du document XML. Vous l'aurez compris il est tout à fait possible de réutiliser ces outils pour générer des bindings dans un autre langage.
(Ah oui au fait : avec IronPython on a déjà accès à tous les bindings Gnome automatiquement ;) )
Comment veux-tu qu'un compilo te prévienne d'un OutOfMemoryException ou d'un NullPointerException.
C'est pareil pour toutes les méthodes. L'opération "." devrait donc être signalée comme pouvant lever une exception de type "NullPointerException". Bref théoriquement il faudrait catcher toutes les lignes. Sauf que c'est pénible. Ben c'est aussi pénible à l'arrivée avec les exceptions "personnalisée". Je vois pas pourquoi obliger le programmeur à en catcher certaines et pas d'autres, surtout quand les autres sont les plus courantes et les plus souvent levées !
Dans ce cas là, je passe un sale quart d'heure parce que c'est ma responsabilité de livrer des applis testées
Et si le client il patch son OS et donc ses lib Java, sans t'avertir (genre il fait apt-get update), ton programme ne le détectera jamais. Alors que si les exceptions faisaient parti de la signature de la méthode, le runtime gueulerai dès le début en disant : "houlà, lib incompatible, peut pas lancer ca moa"
Parce que tu n'as pas l'air de savoir ce que l'on appelle un type primitif. Un type primitif est un type géré directement par le processeur
J'essai justement de montrer que Java fait l'erreur de boxer les types primitifs dans leurs équivalent objet (et donc non géré par le processeur) pénalisant fortement la gestion des listes de ces types ! Je vois clairement la différence puisque je la mets largement en évidence.
Pour les exceptions non trappées, je préfère que le compilo me prévienne qu'une méthode est suceptible de jeter une exception plutôt que d'aller le voir dans la doc ou de m'en appercevoir au runtime
Sauf que bien entendu toutes les exceptions "standards" sont "ignorées" par le compilo : "InvalidCastException", "NullPointerException", "OutOfMemoryException", etc. C'es les plus courantes et le compilo te diras jamais rien.
Si une librairie tierce change le prototype d'une méthode, je préfère être prévenu par mon compilo parce que la responsabilité, au final, elle est pour ma pomme et bien entendu je vais recompiler avec cette nouvelle bibliothèque!
oué mais si tu patches bêtement la lib sans recompiler ton appli ? Genre le client met à jour son OS et les libs qui vont bien, sans bien entendu recompiler les appli : une lib introduit une exception, boum le runtime Java ne voit pas la différence et casse tout. En C# t'as pas le problème grâce à la gestion du versionning qui détectera ce genre de différence.
Les maîtres mots dans mon secteur sont robustesse et maintenabilité.
Les miens aussi. J'ai essayé de montré assez clairement que C# introduisait pas mal de robustesse. Question maintenance je penses qu'on sera d'accord pour dire que .NET/Mono est bien mieux que Java pour ca : le versionning est un des plus complets en .NET/Mono alors qu'il est quasiment absent de Java.
Pour les perfs je voulais juste montré que c'était ici un choix vraiment regrettable de la part de Sun parcque la différence de perf est vraiment conséquente. Mais j'y vois surtout un problème au runtime pour l'introspection : on a des objects et plus aucune vérification de type, question robustesse boum.
N'importe quoi, toutes les libs que je connais, pour gérer des collections de types primitifs
Donc ces libs sont limités dans les types supportés. Le jour où tu veux concevoir une classe générique qui n'est pas dans ces libs tu fais comment ? Vraiment c'est très limité.
Désolé pour le FUD, je pensais que ces libs faisait plus de boulot "dynamique" pour optimiser ce que le compilo oou le runtime Java ne permettait pas, ce qui n'était possible qu'à travers JNI dans mes suppositions. Mais visiblement ces libs sont très limités dans leurs possibilités par rapport à ce que propose une véritable genericité optimisée native.
Il existe des types primitifs en Java (comme en C#), car c'est plus performant qu'un pointeur sur un objet
Bravo ! C'est ce que j'essai d'expliquer depuis le début. Et c'est d'autant plus visible niveau perf quand tu dois utiliser beaucoup d'instance de ces types, typiquement dans un tableau une liste ou une collection. D'où l'intérêt de l'implémentation C#. Les generics Java casse tout l'intérêt niveau performance des types primitifs.
Je vois pas en quoi je ne maîtrise pas le sujet.
u sujet de JNI, à partir du moment ou tu attaques une librairie C à partir de code C# tu retrouves exactement les mêmes pb qu'en Java(et heureusement!).
Ah non ! En C# tu garderas la portabilité déjà. Pas besoin de recompiler le schmurck JNI pour chaque plateforme. Ensuite le compilo fait un minimum de vérification sur la façon d'utiliser les pointeurs en C#, il est même plutôt contraignant, mais c'est une question de robustesse. Ensuite il faut explicitement déclarer le morceau de code incriminé "unsafe", et compiler le code en "unsafe", pointant ici explicitement les éventuels problèmes au lieu de les cacher. Bref, question robustesse c'est quand même mieux.
Pour les exceptions conditionnelles en Java, c'est une question de feeling certains sont pour, d'autres contre.
Je suis pas entièrement contre non plus, mais comme je te l'ai montré c'ests bancale, notamment en cas de patch ou maj, donc c'est pas robuste pour 2 sous.
En terme de performance, la clause "final" ne sert à rien pour un bon compilateur
C'est pour ca que j'ai précisé que c'est relatif, dans 90% des cas le compilo s'en sort très bien.
.On peut aussi argumenter le contraire, combien d'entre nous n'ont pas pester parce que justement le développeur d'une librairie n'avait pas autorisé la dérivation d'une fonction.
Effectivement mais question robustesse la solution C# est quand même préférable : mieux vaut tout "bloquer" par défaut que de laisser toutes les portes ouvertes en espérant que le programmeur cherchera à les fermer.
Bref même si on peut avoir des préférences (comme tu dis les goûts et les couleurs), le fait est que les choix de C# sont dans l'ensemble plus "robuste" par rapport au choix Java, même si à l'utilisation c'est pas toujours le plus pratique.
Quant aux références, on peut difficilement faire moins partial, car il s'agit d'une interview d'Anders Hejlsberg, le créateur de C#, il serait étonnant qu'il dise autre chose.
Peut être mais au moins ils expliquent leurs choix d'implémentation, et je trouves que les explications sont tout à fait valable et il fait preuve d'un impressionnant pragmatisme. J'aimerai une interview similaire des concepteurs de Sun, et qu'ils justifient leurs choix par rapport aux autres langages.
Qu'il y t il de mal à utiliser une librairie plus performante. De toute pour éviter l'auto boxing et avoir des perfs max en c# tu seras obligé de faire pareil.
Sauf que le libs en question font la plupart du temps appel à du code natif (question perf) pour contourner les problème du langage initial : tu perds la portabilité, souvent la sécurité, et de plus ce n'est pas standardisé (ne fait pas parti du framework de base). En C# tu as tout un tas de "goodies" (generics, stackalloc, pointeurs, structure, delegates), qui permettent bien souvent d'éviter l'utilisation de libs spécialisées, permettant de conserver la portabilité, une part plus importante de sécurité (cela reste "managé" et le compilo en est conscient), bref c'est mieux et non ce n'est pas pareil qu'en Java. Si on part de ton principe on sait même pas pourquoi en Java ils se sont embêtés à mettre des types primitifs, autant en faire des objets normaux. En concevant les generics ont a l'impression qu'ils ont oublié pourquoi ils avaient fait la distinction entre type primitif et le reste.
sur un Athlon 1.4 Ghz (1700+) avec seulement 512 de RAM.
Moi je compares surtout avec Visual Studio c'est peut être pour ça :-)
Le truc qui m'a le plus fait halluciné, c'est que si tu as le malheur d'avoir un thread qui reste à tourner pendant le déboggage et que tu t'en apercoit pas (du coup tu appuis pas sur le bouton rouge pour stopper le déboggage), tu relances pleins de fois le déboggage et le pc ramme de plus en plus, jusqu'à ce que tu fasse un ps -edf | grep java et là qu'une réaction : "...".
Autant pour moi, les List generic en C# sont l'équivalent des ArrayList. Enfin de toute façon mon but n'était pas de démontrer que C# était plus performant que C++ (ce que je ne crois pas évidemment), mais que Java avait un gros problème de ce côté là.
En même temps Anakin MDI n'a pas encore entièrement basculé : grâce à lui des programmeurs Windows s'intéresse à Linux, certains migre des applications ASP.NET, d'autres découvrent les vertues des logiciels libres, etc.
Euh faut pas non plus se pisser dessus, Eclipse 3 n'a et ne sera jamais une référence en matière de réactivité. Sous Windows la completion est parfois lente à la détente, parfois l'interface "rammme" et on a la désagréable impression qu'il se passe un temps fou entre le moment où on cliquent et le moment où on a un retour (même si c'est moins d'une seconde).
Enfin ce n'est pas forcement lié à Java, Eclipse 3 faisant je trouve beaucoup de boulot par derrière, c'est un des IDE les plus puissant que j'ai vu donc bon je trouve normal qu'il demande une grosse config pour être à l'aise.
Pour Linux il y a clairement un problème avec Eclipse et/ou Java.
Sa force est dans la métaprogrammation
gni ? Pour moi métaprogrammation == programme qui génère un programme, et pour moi l'introspection, les generics C# et la génération dynamique de code sont quand même beaucoup plus fort que ce qu'offre C++...
Non mais il va creuser un peu et utiliser la fonctionnalité sans forcément voir tous les ecueils qui se cachent derrière.
En même temps partout la fonctionnalité est documentée en indiquant l'utilité des struct :
- avoir un type "primitif" personnalisé alloué sur la pile, qui contient juste quelques données (par exemple un point avec 2 entiers pour les coordonnées) : dans ce genre de cas c'est en général bénéfique question perf et surtout place mémoire.
- avoir un mapping d'une structure C : de ce point de vu c'est comme si je te disais que les API JNI sont très dangereux parcqu'ils permettent de faire des conneries. Ben c'est pareil pour les pointeurs : les concepteurs de C# ont préféré appeler un chat un chat, un pointeur est un pointeur et pas besoin de créer un truc bancale, non portable et qui cache à l'utilisateur des manque flagrant de sécurité.
Pour les exceptions non trappées ils sont juste parti d'un constat simple : la plupart des dév finissent par faire des throw Exception (je dis pas que c'est intelligent). De plus les concepteurs de Java se sont bien apercu que c'était vite lourd de trapper toutes les exceptions : la preuve les exception "standards" n'ont pas l'obligation d'être trappées.
Et puis c'est aussi une question de design : les exceptions ne font pas parti de la signature de la méthode. En cas de version 1.1 d'une classe qui rajoute un test pouvant lever une exception (un cas non prévu dans la version 1.0), ben hop tu casses potentiellement tous les clients qui utilisent ta classe, à moins de tous les recompiler car seul le compilateur vérifie que les exceptions sont bien trappées.
Bref c'est bancale, lourd, et au final souvent mal utilisé.
Dans certains cas je trouve au contraire C# beaucoup plus robuste : d'abord vis à vis des exceptions le comportement sera toujours celui attendu (je l'ai montré plus haut en Java ce n'est pas le cas, c'est même pas documenté). Le versionning en C# est beaucoup plus fin, précis et vérifiable. Les pointeurs en C# permettent au compilateur d'effectuer des vérifications (ce ne sont pas des bêtes pointeurs C++) alors que JNI tent à cacher tout cela, sans résoudre le moindre problème. Par défaut en Java les méthodes sont virtuelles : je trouve cela dangereux car bien souvent les développeurs oublient les "final", sans parler d'éventuel problème de perf (mais c'est relatif), c'est surtout offrir la possibilité à une classe dérivée de modifier le comportement de la classe initiale alors que ce n'était pas forcement prévu.
Pour les generics idem, le compilo Java fait son taf mais dans un scénario d'introspection tout se barre en couille puisqu'on retrouve le type generique "object" partout, permettant de faire tout et n'importe quoi.
Donc tu vois pour moi c'est l'inverse, C# est plus robuste que Java ;)
En C# aussi il y a des tests de débordement de tableau. De toute façon là on n'utilise pas des tableaux et pas des listes, et en C# comme en Java tout comme en C++ il y a des vérifications.
Cherchez pas une excuse je vous dis que le problème de conception vient bien de Java et de leur implémentation des generics :)
Le test et l'erreur retournée par le programme Java met clairement en évidence le problème : il y a allocation d'un objet sur le tas pour chaque entier.
Ton exemple n'est d'aucune utilité en pratique. J'ai sous les yeux un programme de 67000 lignes en Java et aucune des listes ne contient de types primitfs mais seulement des objets évolués.
Euh, que ce soit dans la doc de MS ou de Sun, c'est clairement indiquer qu'il ne faut pas abuser de l'autoboxing, notamment dans le cas de parcours de collection. S'ils le disent c'est qu'on rencontre souvent la situation (prend des programmes qui font un minimum de calcul mathématique). Evidemment que mon exemple est pas super utile, j'avais la flemme d'écrire un vrai truc.
M'enfin le coup du "oué mais si j'ai un problème j'utilise une lib dédiée" voilà quoi. Le débutant il y pense ? Ben non. Alors que pourtant ils auraient pu résoudre le problème dès le début. Enfin si tu te résigne à utiliser une lib spécifique tu es bien d'accord qu'il y a un problème de perf.
En revanvhe, le "struct"du c#
C'est pas vraiment le sujet mais bon, abordons le puisque tu insistes ;)
D'abord le débutant n'utilisera jamais les structures car il ne sait pas ce que c'est. Le débutant il codera comme en Java, et parfois mettra des int dans une list ;)
Il faut bien voir que le "struct" et présent au même titre que les pointeurs pour laisser le choix aux programmeurs expérimenter d'optimiser leur code. C'est également un moyen très élégant de mapper une structure C en C#, pour utiliser des libs natives.
Bref je suis persuadé que l'on verra bcp plus de problèmes de ce type dans un programme en c# que de listes de type primitifs.
Ben voyons. Un débutant il se dira : "tiens un mot clé que je ne connais pas utilisons le !" Par contre mettre des entiers ou des flottants dans une liste ca, non jamais, c'est vraiement un truc qu'on fait jamais. Surtout quand on débute à la fac avec des exemples qui font typiquement du calcul. Faut arrêter de dire des conneries.
Dans tous les cas C# ne t'oblige pas à utiliser les structs ou les pointeurs, alors que Java ne te propose pas d'alternative pour contourner le problème non documenté des types primitifs et des generics. Ah si utiliser JNI ou une lib qui le fait. YaHoo.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 0.
Chacun ses dépendances mais ca change rien aux objectifs et aux résultats obtenus : avec GAPI t'obtient les méthodes, les signaux, l'arbre d'héritage, etc.
Bref comme je l'ai dis seule l'approche est différente, mais il y en a un qui est éprouvé.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 4.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
"ArrayList c'est pareil qu'un ArrayList."
---> "ArrayList < int > c'est pareil qu'un ArrayList < double >."
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Si tu lis mes posts tu t'apercois que le problème que tu cites est sans incidence réelle.
Si tu lis mes posts cela peut avoir une incidence réelle, je penses notamment aux scénarios d'introspection. C'est d'ailleur comme ca que je suis tombé sur le problème en Java : je testais des types et je ne comprennais pas pourquoi cet andouille me répondait qu'un ArrayList c'est pareil qu'un ArrayList.
J'ai aussi voulu montrer qu'un choix de conception dans le langage peut avoir un impact non négligeable dans certains scénarios.
En l'état actuel tu trouveras très peu de code où il y a le problème puisqu'il n'y a pas encore grand monde à avoir utilisé les generics.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 2.
# du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 8.
Sans vouloir encore et toujours la ramener à Mono, mais ils génèrent leurs bindings pour GTK+, Gnome et autre GStreamer en utilisant depuis le début un outil qui répond aux même objectifs : créer automatiquement les bindings.
L'utilitaire en question, c'est GAPI : http://www.mono-project.com/GAPI(...)
L'approche est différente puisque ce sont les en-tête .h qui sont parsés et non un système d'introspection. Le résultat est le même (bien qu'on puisse récupérer un peu plus d'info dans le .h, comme le nom des arguments) et n'est plus du tout expérimental dans Mono.
De plus l'utilitaire génère une description au format XML des API, un 2ème utilitaire permet de "patcher" au besoin (parcque ce n'est jamais parfait, ou pour modifier le design pour qu'il colle un peu plus au langage cible) et enfin un autre utilitaire qui génère le binding à partir du document XML. Vous l'aurez compris il est tout à fait possible de réutiliser ces outils pour générer des bindings dans un autre langage.
(Ah oui au fait : avec IronPython on a déjà accès à tous les bindings Gnome automatiquement ;) )
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
C'est pareil pour toutes les méthodes. L'opération "." devrait donc être signalée comme pouvant lever une exception de type "NullPointerException". Bref théoriquement il faudrait catcher toutes les lignes. Sauf que c'est pénible. Ben c'est aussi pénible à l'arrivée avec les exceptions "personnalisée". Je vois pas pourquoi obliger le programmeur à en catcher certaines et pas d'autres, surtout quand les autres sont les plus courantes et les plus souvent levées !
Dans ce cas là, je passe un sale quart d'heure parce que c'est ma responsabilité de livrer des applis testées
Et si le client il patch son OS et donc ses lib Java, sans t'avertir (genre il fait apt-get update), ton programme ne le détectera jamais. Alors que si les exceptions faisaient parti de la signature de la méthode, le runtime gueulerai dès le début en disant : "houlà, lib incompatible, peut pas lancer ca moa"
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
J'essai justement de montrer que Java fait l'erreur de boxer les types primitifs dans leurs équivalent objet (et donc non géré par le processeur) pénalisant fortement la gestion des listes de ces types ! Je vois clairement la différence puisque je la mets largement en évidence.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Sauf que bien entendu toutes les exceptions "standards" sont "ignorées" par le compilo : "InvalidCastException", "NullPointerException", "OutOfMemoryException", etc. C'es les plus courantes et le compilo te diras jamais rien.
Si une librairie tierce change le prototype d'une méthode, je préfère être prévenu par mon compilo parce que la responsabilité, au final, elle est pour ma pomme et bien entendu je vais recompiler avec cette nouvelle bibliothèque!
oué mais si tu patches bêtement la lib sans recompiler ton appli ? Genre le client met à jour son OS et les libs qui vont bien, sans bien entendu recompiler les appli : une lib introduit une exception, boum le runtime Java ne voit pas la différence et casse tout. En C# t'as pas le problème grâce à la gestion du versionning qui détectera ce genre de différence.
Les maîtres mots dans mon secteur sont robustesse et maintenabilité.
Les miens aussi. J'ai essayé de montré assez clairement que C# introduisait pas mal de robustesse. Question maintenance je penses qu'on sera d'accord pour dire que .NET/Mono est bien mieux que Java pour ca : le versionning est un des plus complets en .NET/Mono alors qu'il est quasiment absent de Java.
Pour les perfs je voulais juste montré que c'était ici un choix vraiment regrettable de la part de Sun parcque la différence de perf est vraiment conséquente. Mais j'y vois surtout un problème au runtime pour l'introspection : on a des objects et plus aucune vérification de type, question robustesse boum.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Donc ces libs sont limités dans les types supportés. Le jour où tu veux concevoir une classe générique qui n'est pas dans ces libs tu fais comment ? Vraiment c'est très limité.
Désolé pour le FUD, je pensais que ces libs faisait plus de boulot "dynamique" pour optimiser ce que le compilo oou le runtime Java ne permettait pas, ce qui n'était possible qu'à travers JNI dans mes suppositions. Mais visiblement ces libs sont très limités dans leurs possibilités par rapport à ce que propose une véritable genericité optimisée native.
Il existe des types primitifs en Java (comme en C#), car c'est plus performant qu'un pointeur sur un objet
Bravo ! C'est ce que j'essai d'expliquer depuis le début. Et c'est d'autant plus visible niveau perf quand tu dois utiliser beaucoup d'instance de ces types, typiquement dans un tableau une liste ou une collection. D'où l'intérêt de l'implémentation C#. Les generics Java casse tout l'intérêt niveau performance des types primitifs.
Je vois pas en quoi je ne maîtrise pas le sujet.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Ah non ! En C# tu garderas la portabilité déjà. Pas besoin de recompiler le schmurck JNI pour chaque plateforme. Ensuite le compilo fait un minimum de vérification sur la façon d'utiliser les pointeurs en C#, il est même plutôt contraignant, mais c'est une question de robustesse. Ensuite il faut explicitement déclarer le morceau de code incriminé "unsafe", et compiler le code en "unsafe", pointant ici explicitement les éventuels problèmes au lieu de les cacher. Bref, question robustesse c'est quand même mieux.
Pour les exceptions conditionnelles en Java, c'est une question de feeling certains sont pour, d'autres contre.
Je suis pas entièrement contre non plus, mais comme je te l'ai montré c'ests bancale, notamment en cas de patch ou maj, donc c'est pas robuste pour 2 sous.
En terme de performance, la clause "final" ne sert à rien pour un bon compilateur
C'est pour ca que j'ai précisé que c'est relatif, dans 90% des cas le compilo s'en sort très bien.
.On peut aussi argumenter le contraire, combien d'entre nous n'ont pas pester parce que justement le développeur d'une librairie n'avait pas autorisé la dérivation d'une fonction.
Effectivement mais question robustesse la solution C# est quand même préférable : mieux vaut tout "bloquer" par défaut que de laisser toutes les portes ouvertes en espérant que le programmeur cherchera à les fermer.
Bref même si on peut avoir des préférences (comme tu dis les goûts et les couleurs), le fait est que les choix de C# sont dans l'ensemble plus "robuste" par rapport au choix Java, même si à l'utilisation c'est pas toujours le plus pratique.
Quant aux références, on peut difficilement faire moins partial, car il s'agit d'une interview d'Anders Hejlsberg, le créateur de C#, il serait étonnant qu'il dise autre chose.
Peut être mais au moins ils expliquent leurs choix d'implémentation, et je trouves que les explications sont tout à fait valable et il fait preuve d'un impressionnant pragmatisme. J'aimerai une interview similaire des concepteurs de Sun, et qu'ils justifient leurs choix par rapport aux autres langages.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 0.
Sauf que le libs en question font la plupart du temps appel à du code natif (question perf) pour contourner les problème du langage initial : tu perds la portabilité, souvent la sécurité, et de plus ce n'est pas standardisé (ne fait pas parti du framework de base). En C# tu as tout un tas de "goodies" (generics, stackalloc, pointeurs, structure, delegates), qui permettent bien souvent d'éviter l'utilisation de libs spécialisées, permettant de conserver la portabilité, une part plus importante de sécurité (cela reste "managé" et le compilo en est conscient), bref c'est mieux et non ce n'est pas pareil qu'en Java. Si on part de ton principe on sait même pas pourquoi en Java ils se sont embêtés à mettre des types primitifs, autant en faire des objets normaux. En concevant les generics ont a l'impression qu'ils ont oublié pourquoi ils avaient fait la distinction entre type primitif et le reste.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Moi je compares surtout avec Visual Studio c'est peut être pour ça :-)
Le truc qui m'a le plus fait halluciné, c'est que si tu as le malheur d'avoir un thread qui reste à tourner pendant le déboggage et que tu t'en apercoit pas (du coup tu appuis pas sur le bouton rouge pour stopper le déboggage), tu relances pleins de fois le déboggage et le pc ramme de plus en plus, jusqu'à ce que tu fasse un ps -edf | grep java et là qu'une réaction : "...".
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[^] # Re: Use the force
Posté par TImaniac (site web personnel) . En réponse au journal Amer. Évalué à 4.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Enfin ce n'est pas forcement lié à Java, Eclipse 3 faisant je trouve beaucoup de boulot par derrière, c'est un des IDE les plus puissant que j'ai vu donc bon je trouve normal qu'il demande une grosse config pour être à l'aise.
Pour Linux il y a clairement un problème avec Eclipse et/ou Java.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
gni ? Pour moi métaprogrammation == programme qui génère un programme, et pour moi l'introspection, les generics C# et la génération dynamique de code sont quand même beaucoup plus fort que ce qu'offre C++...
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
En même temps partout la fonctionnalité est documentée en indiquant l'utilité des struct :
- avoir un type "primitif" personnalisé alloué sur la pile, qui contient juste quelques données (par exemple un point avec 2 entiers pour les coordonnées) : dans ce genre de cas c'est en général bénéfique question perf et surtout place mémoire.
- avoir un mapping d'une structure C : de ce point de vu c'est comme si je te disais que les API JNI sont très dangereux parcqu'ils permettent de faire des conneries. Ben c'est pareil pour les pointeurs : les concepteurs de C# ont préféré appeler un chat un chat, un pointeur est un pointeur et pas besoin de créer un truc bancale, non portable et qui cache à l'utilisateur des manque flagrant de sécurité.
Pour les exceptions non trappées ils sont juste parti d'un constat simple : la plupart des dév finissent par faire des throw Exception (je dis pas que c'est intelligent). De plus les concepteurs de Java se sont bien apercu que c'était vite lourd de trapper toutes les exceptions : la preuve les exception "standards" n'ont pas l'obligation d'être trappées.
Et puis c'est aussi une question de design : les exceptions ne font pas parti de la signature de la méthode. En cas de version 1.1 d'une classe qui rajoute un test pouvant lever une exception (un cas non prévu dans la version 1.0), ben hop tu casses potentiellement tous les clients qui utilisent ta classe, à moins de tous les recompiler car seul le compilateur vérifie que les exceptions sont bien trappées.
Bref c'est bancale, lourd, et au final souvent mal utilisé.
Dans certains cas je trouve au contraire C# beaucoup plus robuste : d'abord vis à vis des exceptions le comportement sera toujours celui attendu (je l'ai montré plus haut en Java ce n'est pas le cas, c'est même pas documenté). Le versionning en C# est beaucoup plus fin, précis et vérifiable. Les pointeurs en C# permettent au compilateur d'effectuer des vérifications (ce ne sont pas des bêtes pointeurs C++) alors que JNI tent à cacher tout cela, sans résoudre le moindre problème. Par défaut en Java les méthodes sont virtuelles : je trouve cela dangereux car bien souvent les développeurs oublient les "final", sans parler d'éventuel problème de perf (mais c'est relatif), c'est surtout offrir la possibilité à une classe dérivée de modifier le comportement de la classe initiale alors que ce n'était pas forcement prévu.
Pour les generics idem, le compilo Java fait son taf mais dans un scénario d'introspection tout se barre en couille puisqu'on retrouve le type generique "object" partout, permettant de faire tout et n'importe quoi.
Donc tu vois pour moi c'est l'inverse, C# est plus robuste que Java ;)
Au fait un article qui devrait t'intéresser :
Les generics en C#, Java, C++ comparés :
http://www.artima.com/intv/generics.html(...)
Pourquoi pas d'exception trappées en C# par rapport à Java :
http://www.artima.com/intv/handcuffs.html(...)
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Cherchez pas une excuse je vous dis que le problème de conception vient bien de Java et de leur implémentation des generics :)
Le test et l'erreur retournée par le programme Java met clairement en évidence le problème : il y a allocation d'un objet sur le tas pour chaque entier.
[^] # Re: Correction
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Il a les 2 pattes de la même longueur, surtout la gauche.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
real 0m0.580s
user 0m0.031s
sys 0m0.000s
En C++ en fait il faut plusieurs dizaines de secondes, mais je vais pas trop prendre ca en compte, vu que c'est exécuté sous cygwin avec g++...
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 3.
Euh, que ce soit dans la doc de MS ou de Sun, c'est clairement indiquer qu'il ne faut pas abuser de l'autoboxing, notamment dans le cas de parcours de collection. S'ils le disent c'est qu'on rencontre souvent la situation (prend des programmes qui font un minimum de calcul mathématique). Evidemment que mon exemple est pas super utile, j'avais la flemme d'écrire un vrai truc.
M'enfin le coup du "oué mais si j'ai un problème j'utilise une lib dédiée" voilà quoi. Le débutant il y pense ? Ben non. Alors que pourtant ils auraient pu résoudre le problème dès le début. Enfin si tu te résigne à utiliser une lib spécifique tu es bien d'accord qu'il y a un problème de perf.
En revanvhe, le "struct"du c#
C'est pas vraiment le sujet mais bon, abordons le puisque tu insistes ;)
D'abord le débutant n'utilisera jamais les structures car il ne sait pas ce que c'est. Le débutant il codera comme en Java, et parfois mettra des int dans une list ;)
Il faut bien voir que le "struct" et présent au même titre que les pointeurs pour laisser le choix aux programmeurs expérimenter d'optimiser leur code. C'est également un moyen très élégant de mapper une structure C en C#, pour utiliser des libs natives.
Bref je suis persuadé que l'on verra bcp plus de problèmes de ce type dans un programme en c# que de listes de type primitifs.
Ben voyons. Un débutant il se dira : "tiens un mot clé que je ne connais pas utilisons le !" Par contre mettre des entiers ou des flottants dans une liste ca, non jamais, c'est vraiement un truc qu'on fait jamais. Surtout quand on débute à la fac avec des exemples qui font typiquement du calcul. Faut arrêter de dire des conneries.
Dans tous les cas C# ne t'oblige pas à utiliser les structs ou les pointeurs, alors que Java ne te propose pas d'alternative pour contourner le problème non documenté des types primitifs et des generics. Ah si utiliser JNI ou une lib qui le fait. YaHoo.