Si Apple refuse java sur App Store c'est au nom de son système fermé. Afin d'avoir des applications rien que pour eux. C'est une question économique et non une question de langage.si apple à refusé le java au sein des applications sur l'app store je pense qu'il y a une raison.
Remplacer JAVA par Python? J'y crois pas.
Edit:
Ah et remplacer JAVA par JS, j'en parle même pas. C'est comme remplacer une fourchette par des baguettes, ok pour le riz ou les sushi mais pour les lasagnes ça va être plus dur.![]()
J'y crois pas non plus, même si je trouve ça bien python.
On cherche à faire du multi-platforme ?
Personnellement je pense que le C++, et notamment grace à Qt, va connaitre un renouveau !!
Sans rien changer, le même programme compile pour windows, mac, linux, android, et bientôt iOS et windows phone ! Que demander de plus !
C/C++, il est sous nos yeux depuis 40 ans, je ne vois pas pourquoi chercher autre chose personnellement !![]()
Je suis d'accord. Les outils de développement Java sont légions. Je ne vois pas d'autres langages ayant autant d'outils (EDI, Integration Continue, analyse syntaxique, build, documentation, ...).
La JVM est extensible, on peut se plugger facilement : javaagent, JMX, aspectJ.
Les API sont depuis le début une affaire de standard.
J'imagine bien que justement il est plus simple de démarrer une application Javascript car il suffit d'un navigateur et d'un éditeur de texte mais si on veut un développement d'entreprise, là c'est autre chose.
Ce que j'aime bien avec ces articles, c'est que ça génère du troll à foison grâce à des gens qui n'y connaissent rien mais qui tiennent cependant à le faire savoir.
http://www.php.net/manual/fr/language.oop5.abstract.php
http://www.php.net/manual/fr/languag...interfaces.php
Effectivement, je vois pas dans le post d'origine une seule preuve que Java est en train de mourir...
Pour des programmeurs Java qui sont habitués à se faire alerter pour tout et n'importe quoi par leur compilo oui. Pour des devs rigoureux, le temps passé en debug est le même qu'un autre langage. Par contre, une fois que t'as goûté (et que tu t'es cassé les dents 2/3 fois) aux typages faibles et aux conversions implicites, tu décuples ta productivité et alors ça sera très difficile de repasser à Java !
var MA_VAR = 4
Après si tu t'amuses à modifier des variables qui ont cette gueule, je vois pas l'intérêt d'utiliser des conventions de nommage... :/
Les interfaces et les classes abstraites existent en PHP...
Un exemple de limitation de visibilité en JavaScript :
(function(){
var toto = 3;
})()
ta variables toto est limitée au scope de la fonction. Effectivement les scopes sont très différents du Java, effectivement ça peut paraitre bizarre au début mais avec des bonnes libs, ce genre de truc peut être encapsulé facilement (par exemple la gestion des namespaces de ExtJS qui est basé sur les scopes de fonction).
Tu connais quoi comme autre langage ? Tu connais C# ?Je pense pas que l'API de dotNET ait grand chose à lui envier
Comment tu fais des RIA full web en Java côté client ? Tu utilises GWT ?
Côté serveur je suis bien d'accord, mais comme j'essaye de le démontrer je pense que c'est plus une question de stratégie des SSII, que grâce aux qualités intrinsèques de Java.
Manque de culture sans doute, et le concept d'héritage multiple alors... je ne parle pas des interfaces qui ne sont qu'un cache-misère.
Si tu veux un langage clair, sans fioriture et full OO, tu peux regarder Eiffel, d'ailleurs, le langage Java commence à repomper les idées d'Eiffel, telle que la programmation par contrat, c'est pathétique.
![]()
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Et pourquoi diable penser à Javascript ? Parce qu'il y a "Java" dedans ?
Je trouve ça amusant ce genre de citations qui ne peuvent être écrites que par une personne qui ne connaît de toute évidence pas Javascript. Dans pas mal de contextes aujourd'hui, Javascript ne souffre pas d'un problème de productivité, bien au contraire !
Si Javascript ne prendra pas la place de Java dans les usines-à-gaz pour entreprises, c'est parce qu'il n'est pas taillé pour l'industrialisation à grande échelle de ce genre d'appli. C'est normal, c'est pas fait pour.
Une autre raison du succès de Java dans les boîtes est que des personnes qui ne sont pas des cracks de l'info peuvent un peu développer. Il faut cesser tout voir à travers le prisme du développeur expert : le développeur expert représente une minorité des employés.
sisi t'en fais pas, je fais du javascript même si ce n'est pas mon langage favori (et de loin).
Là où tu as raison, c'est que js n'est pas fait pour les projets d'envergure. Le problème, c'est que les décideurs pensent que c'est l'avenir parce qu'ils ont lu 3 articles où le mot revenais souvent, et du coup veulent en mettre partout (les buzz words...). C'est à ce moment là qu'on tombe sur des abérations telles que node.js, avec des décideurs qui obligent à faire de gros projets avec du javascript en backend. Soyons clair, je n'ai rien contre js, mais 90% des cheveux que je m'arrache, c'est à cause de ça, pas à cause du java backend tout joli tout rose, fortement outillé, très bien documenté, avec des patterns établis et puissants...
Il y a une différence essentielle entre JavaScript et Java. En effet, si dans le cadre du développement d'une application Web, on peut choisir Java pour la partie serveur, l'utilisation de JavaScript pour la partie cliente quant à elle est imposée par les navigateurs Web, puisque c'est le seul langage à être plus ou moins unanimement supporté. On peut cependant choisir de coder la partie cliente dans un autre langage et considérer JavaScript comme une sort de code portable vers lequel on compile l'application (comparable au bytecode de la JVM).
Quant à l'utilisation de JavaScript pour des projets d'envergure, je n'y vois aucun inconvénient tant qu'on programme en JavaScript avec la même rigueur que dans un autre langage. Cela dit, s'il s'agit d'utiliser JavaScript en dehors du contexte d'un navigateur, je suis moi aussi dubitatif.
Je crois qu'effectivement les langages trop verbeux sont plus sur le declin que l'inverse.
Etant developpeur C# je pense que ce qu'il manque à JAVA c'est un certain degré de syntaxic sugar, toutes ces lignes ecrites comme plomberie inutile associé à un certain conservatisme bien pensant (voir condescendant)... ca s'effrite.
le var nom = "Rastapopoulos" sujet à moquerie, sera bientot la norme, remplaçant le bien pensant string nom = "Rastapopoulos" ou autre
Dictionary<string, List<string>> dico = new Dictionary<string, List<string>>();pas malin et ignorant des IDE d'aujourd'hui.
Dans ce sens je pense que Scala et groovy sont sur une pente très positive, et que soit JAVA va suivre (closure, etc...), soit ses surcouches rendront sa syntaxe obsolète.
On peut se rendre compte qu'il n'y a pas que les ordi qui traite du binaire... ça déteint aussi sur les dev parfoisSi tu ne veux pas de contraintes de programmation, tu ne fais pas de programmation...
Quoi qu'on en dise, le programme fait ce qu'on lui dit de faire, pas ce qu'on veut qu'il fasse, et ceci est independant du langage... Certains sont moins verbeux, d'autres plus, mais ce n'est pas ca qui "libere" les developpeurs ou les contraint.
Après je serais presque d'accord avec toi. À l'exception des opérateurs, quel horreur ces multiply, ces negate, etc. des negate(pow(A.multiply(B.add(...
Dégeu.
Jamais, dans aucun de mes programmes C/ASM/Python/PHP/ADA/etc je n'ai eu des lignes aussi longues qu'en Java xD
Alors si c'est pénalisant des noms trop long, même si ce n'est pas LA chose à corriger au plus vite. (cf. les exemples sur http://cl.ly/RvaL)
Si tu pars sur un postulat idiot, oui tu trouve un résultat idiot. Trouvaille ?On va le remplacer par quoi? Du javascript?? hahaha, laissez-moi rire... impensable, à moins d'accepter de diviser sa productivité par 2 (et de remplacer une bonne partie de notre temps de dév par du temps de debug)
J'ai étudié et travaille depuis des années en Java. C'est une horreur, disons le d'emblée. Beaucoup (trop de failles de sécu), une JVM très très très gourmande en RAM.
À titre perso, j'utilise de plus en plus C#, pourtant on peut vraiment pas m'accuser d'être pro-Microsoft, n'utilisant quasiment aucun de leurs outils.
Mais C# réussi quasiment partout ou Java pêche.
Quelques trucs comme ça :
- Avouons-le, l'API Java a été fait par des théoriciens des cordes qui se touchent devant leurs hiérarchies (des profs aussi parfois) mais n'ont pas compris qu'il était PARFOIS utile de créer, pour Swing notamment, des classes concrètes. Pour gérer des trucs dépassés (second degré) comme l'affichage d'une image, la lecture d'une musique ou des graphiques...
À coté Qt, c'est 3 lignes pour une classe de 100 lignes en Java avec un héritage aux interfaces Java
C# lui a déjà tout dans le ventre, comme Qt.
- Java est naze niveau perf. Clairement tu dév avec, tu te fous des perfs.
Pour le même algorithme général, C est quasi 10 fois plus rapide. 7 fois pour C++. C# peut générer un vrai binaire, en perdant le multiplateforme. Mais Java n'est pas multiplateforme dans la pratique, donc bon. Qui n'a jamais modifier son code pour l'adapter à Linux, Windows ou Mac ? Tiens centre une fenêtre à l'écran alors !
- Des types primitifs peuvent servir, désolé.
- Des pointeurs j'en veux quand même, na !
- Pas de surcharges d'opérateurs... non mais allô quoi !
- Pas de raccourcis pour les TRÈS laborieux getters/setters ! Ni dans les param du constructeurs. Pas de destructeurs ! (faisons confiance au GC, hein)
T'en de choses en tête... vous pourrez trouver aussi une comparaison ici (http://cl.ly/RvaL). Peu de choses finalement que Java fait et que C# ne fait pas. Puis Java, ok sur Android... mais sous iOS et WP...
Par contre, Java permet de créer un code rapidos, le traitement des chaines est un régal, ET... C# n'est encore pas beaucoup appris (mais ça vient dans les écoles. Le jour où, Java ne fera pas pleurer dans les chaumières...
C'est bien ce que je disais, les développeurs Java (pour les étudiants n'ayant jamais fait d'assembleur ni de C, ce qui est pour moi inconcevable à titre personnel) se foutent complètement des perfs. Le tout c'est qu'ils soient pas hypocrite, qu'ils se l'avouent.
Enfin, un test simple, fait une multiplication de deux matrices. Avec un bête algo. Prends le meilleur pour chaque langage, en gardant la même complexité Oméga.
Tu n'as jamais lancé de profiler ? Fait un clock() pour voir ? Je sais pas c'est la base normalement...
Et non critiquer n'est pas simple quand c'est argumenté.
Okay, tu as gagné, le C/C++ est plus rapide. Well done.
Sauf que ... c'est un test simple, même pas besoin de pointeur... Et c'est moi qui suis hypocrite ?
Prends une bonne grosse application programmée par des dizaines de personnes voir plus. Bizarrement, l'avantage de la gestion de la mémoire se transforme en désavantage avec une gestion de la mémoire catastrophique car faite à l'arrache.
Alors oui, on a le "ah mais non, moi monsieur je programme bien"... Toujours est-il que ce n'est pas le cas de tout le monde.
Il est clair que si tu veux faire une application où tu vas aller dans les moindre recoin pour grapiller des ms et de la mémoire, vaut mieux pas être dans un langage haut niveau maintenant, pour l'application en entreprise (ce qui permet à un langage de vivre) avec plein de gens pas aussi doué que toi, oui, le GC est plus doué que la moyenne...
... ou alors bien faite, mais qui revient à avoir écrit un gc spécifique à l'application!
Greenspun l'avait déjà dit en 1993 : "any sufficiently complicated C [or C++] or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."
![]()
Il y a des benchmarks bien plus complets. Et ils placent généralement Java dans les langages les plus rapides. Exemple :
http://attractivechaos.github.io/plb/
Un developpeur qui se fout des performances a raison dans plus de 90% des cas...
Lorsque tu as besoin de multiplier 2 matrices (de taille raisonnable) une fois par mois, ca ne sert a rien de passer 2 semaines a trouver un algo qui te fera gagner quelques secondes.
Normalement, il faut d'abord faire quelque chose qui fonctionne avant de se poser des questions d'optimisation, selon la bonne vieille regle des 80/20 : tu passes 80% de ton temps dans 20% de ton code : tant que tu n'as pas identifie exactement les 20%, ca ne sert a rien d'optimiser !
Je ne compte plus combien de gens j'ai vu optimiser, a mort, la lecture de la configuration pour un programme serveur qui tourne en 24/7... Ca ne sert a rien.
Par contre, une fois ton application ecrite, un petit coup de profiler qui te donne les quelques methodes dans lesquelles tu passes le plus de temps, et hop, c'est bon.
Tu remarqueras que ces notions sont independantes du langage.
Et je pense que tu ne t'es pas penche sur les performances des JVM depuis un bout de temps
C'est un peu comme comparer les performances des processeurs en comparant les bogomips (c'est a dire le nombre de NOP qu'un processeur peut executer par seconde) : ca te donne une idee de quelque chose, mais pas de programmes reels.Enfin, un test simple, fait une multiplication de deux matrices. Avec un bête algo. Prends le meilleur pour chaque langage, en gardant la même complexité Oméga.
Tu n'as jamais lancé de profiler ? Fait un clock() pour voir ? Je sais pas c'est la base normalement...
Java est utilise dans la plupart des cas pour faire des serveurs qui sont utilises par de multiples clients. Oui, Java va etre plus lent que le C pour faire un appel a clock(). Mais ce n'est pas pour cela qu'il est utilise -- et le C non plus.
Partager