Euh, d'abord quel besoin d'être agressif et grossier ?
Ensuite, la discussion (et LinuxFR) porte sur le logiciel libre. Et je persiste à dire que je ne connais pas d'application utile, libre et écrite en Java. Les seules choses libres en Java que je connaisse sont des outils... pour développer en Java !
Alors ok, tu me parles de grands systèmes d'information et de site webs en Java, c'est très bien, mais ce n'est pas du logiciel libre tout d'abord, et ensuite c'est fait par et pour des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
La pluspart des entreprises (et encore plus des particuliers) n'ont pas ces resources et veulent pouvoir exploiter le peu de puissance qu'ils ont (cpu & mémoire) au mieux.
En bref, j'attends qu'on me montre une application utilisable par le grand public (genre Open Office, Mozilla, MPlayer...), qui soit du logiciel libre et qui soit en Java. Pour l'instant je n'en ai pas vu. D'où ma remarque.
Enfin, je ne suis pas tout à fait d'accord avec tes remarques sur le calcul mathématique. En effet, certes les librairies les plus performances sont en assembleur, mais il existe également des librairies écrites dans des langages de haut niveau avec des techniques de programmation modernes qui battent souvent les codes écrits à la main. Exemple: Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main (et ici je parle bien de "plus vite" pas "2 fois moins vite" comme toi).
Alors c'est effectivement vrai qu'une JVM peut optimiser au runtime de certaines façons qui sont impossible à voir pour un compilateur C ou C++, mais par contre je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.
[^] # Re: Mono 0.24
Posté par enicolas . En réponse à la dépêche Mono 0.24. Évalué à 4.
Ensuite, la discussion (et LinuxFR) porte sur le logiciel libre. Et je persiste à dire que je ne connais pas d'application utile, libre et écrite en Java. Les seules choses libres en Java que je connaisse sont des outils... pour développer en Java !
Alors ok, tu me parles de grands systèmes d'information et de site webs en Java, c'est très bien, mais ce n'est pas du logiciel libre tout d'abord, et ensuite c'est fait par et pour des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
La pluspart des entreprises (et encore plus des particuliers) n'ont pas ces resources et veulent pouvoir exploiter le peu de puissance qu'ils ont (cpu & mémoire) au mieux.
En bref, j'attends qu'on me montre une application utilisable par le grand public (genre Open Office, Mozilla, MPlayer...), qui soit du logiciel libre et qui soit en Java. Pour l'instant je n'en ai pas vu. D'où ma remarque.
Enfin, je ne suis pas tout à fait d'accord avec tes remarques sur le calcul mathématique. En effet, certes les librairies les plus performances sont en assembleur, mais il existe également des librairies écrites dans des langages de haut niveau avec des techniques de programmation modernes qui battent souvent les codes écrits à la main. Exemple: Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main (et ici je parle bien de "plus vite" pas "2 fois moins vite" comme toi).
Alors c'est effectivement vrai qu'une JVM peut optimiser au runtime de certaines façons qui sont impossible à voir pour un compilateur C ou C++, mais par contre je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.