brazomyna a écrit :



Ne tombons pas dans la caricature du “Java c’est juste bon à faire de l’IHM”.





Vu les biblios disponibles ous Java, ne faudrait-il pas plutôt dire : Java est bon à tout sauf de l’IHM ?

" />







foetus a écrit :



Visual répond aussi pour les Winforms





Tu as malheureusement raison de préciser “pour Winform”. :(

jaretlafoudre a écrit :



Dejà java VS C… j’ai fait un test tout con quand j’ai voulu me lancer en pregramation native sur android, le calcul d’une madelbrot en java et j’ai pris l’algo tel quel en C, resultat : 58x plus rapide pour la version native… et encore en C j’aurais pu optimiser en utilisant les fonctions NEON…





Si moi je code le même algo en C# il sera 5% plus lent et sans optimisation particulière. Et un codeur familier de Java en ferait autant.

Glubglub a écrit :



Je ne voit pas en quoi c’est trollesque : exécuter un programme dans une machine virtuelle est forcément plus lent qu’un programme compilé en assembleur.

10 fois plus lent, selont quelques profs de mon ancienne fac.





Alors d’abord le dix fois plus lent à de quoi me faire rire. Machine virtuelle ou pas le code se retrouve in fine compilé (simplement moins optimisé qu’avec une compilation ordinaire) et ce n’est pas la surcouche pour ouvrir les fichiers ou afficher l’UI qui fera ramer le bousin vu le faible poids de ces appels. En pratique je vois des surcoûts globaux de 30% du fait du manque d’optimisation de la compilation JIT. Même si dans le cas de Java le surcroût est sans doute plus élevé. Quant aux coûts inhérents aux langages managés (comptage de références, etc), de nos jours les mêmes problèmes se posent avec un code C++ s’appuyant sur Boost et compagnie.



Ensuite avec les CPU qu’on a aujourd’hui il y a largement de quoi faire tout ce que fait un IDE dans le plus lent des langages qui soit et sans forcer. Si ça rame, c’est que quelqu’un a merdé. Il n’y a guère que pour une ou deux étapes longues par essence (compilation de gros projet, etc) qu’une différence se fera nécessairement sentir (et encore : les réductions de coût engendrées peuvent servir à mieux paralléliser).



Crois-moi, j’ai conçu des tonnes d’applis dans des langages managés (même si dotnet n’a pas à proprement parler une machine virtuelle), dont certaines bien exigeantes, et je n’ai eu aucun pb de performances au final alors que je n’hésite pas à y aller à la truelle. Je me contente d’éviter les erreurs stupides et les machins sur-architecturés. Et ce sont ces derniers qui doivent plutôt être en cause.



L’algo fait la vitesse, pas le langage. Dit comme ça c’est un peu simpliste mais c’est essentiellement vrai.

lordzeon a écrit :



Compilé oui … mais pour la VM.

Le code n’est pas natif pour le processeur.





Comme l’a précisé Brazonyma, la VM compile bel et bien le bytecode en code natif, à la volée (JIT = just in time).





C’est vrai … mais il faut avouer que les IDE en java ne sont pas vraiment rapide.



Et à côté de ça VS est écrit majoritairement en dotnet de nos jours (pas entièrement pour des raisons historiques et de compatibilité) et il est très véloce.







WilliamSauron a écrit :



Très vrai, et pourtant j’ai parfois dû “passer outre” le garbage collector. J’avais une application qui allouait beaucoup de petits objets à la durée de vie faible. Hé bien, en maintenant manuellement un petit pool d’objets “libérés” j’ai multiplié les performances par 3.





J’ai aussi eu une fois à faire ça pour éviter de faire bosser le GC et maintenir une fluidité impeccable. Mais la technique existe aussi dans le monde non-managé, pour des raisons un peu différentes. ;)







brazomyna a écrit :



C’est sûrement beaucoup lié à l’architecture: un IDE ultra généraliste, générique et extensible comme Eclipse ne peut pas se comporter de façon aussi optimisée qu’un IDE ultra spécialisé dans une techno précise.





VS n’est pas plus restreint qu’Eclipse, tu peux y ajouter le support de tous les langages que tu veux via des plugins, avec prise en charge de la coloration syntyaxique, du déboguage de ta propre gestion de projets, etc. C’est très extensible.







TheDidouille a écrit :



C’est dingue le nombre de personnes sous Windows qui savent même pas configurer une variable d’environnement! Des mec qui d/l un IDE en plus…





Parce que c’est devenu rare. Les applis de nos jours sous Windows utilisent plutôt des clés de registre. Je dois toucher aux variables d’environnement une fois par an et à chaque fois j’hésite un peu pour retrouver où ils ont foutu l’UI pour ça.

TheDidouille a écrit :



tu connais vraiment pas eclipse





Connais-tu vraiment Visual Studio ?





c’est aussi une plateforme pour faire des appli développer avec des équipes qui se connaissent pas



Ils ont intégré un chat ? Plus sérieusement, à quelle fonctionnalité songes-tu ?





, qui peuvent utiliser des versions différentes de lib, d’application qui peuvent s’étendre, portable, sans maintenance.



Un IDE qui produit des applis sans maintenance et résoud tout seul le DLL hell ? A ce stade ce n’est plus un IDE, c’est Jésus.

brazomyna a écrit :



PS: un lien assez parlant: List of Eclipse-based software.

Genre dedans, tu trouves RSSOwl, un RSS reader ; uDig, un soft pour faire des carte géographiques, Lotus Notes dont je parlais avant, etc…





Sauf qu’en fait ce n’est pas basé sur Eclipse mais sur un framework (RCP) développé pour Eclipse et qui est en somme un framework UI avec des mécanismes d’extensibilité. De telles choses existent aussi côté dotnet, même si la plupart ne sont pas utilisées par VS.







brazomyna a écrit :



Improbable ; on a des preuves photographiques qui contredisent cette théorie ubuesque.





" />







WilliamSauron a écrit :



C’est même surtout parce que les variables d’environnement sont une solution globale à un problème local.





Je ne suis pas d’accord. Le problème est : où est tel composant ? Quel que soit le mécanisme pour exposer cette info à toutes les applications, tu peux ou non distinguer les différents versions disponibles (différentes variables d’environnement par ex).