Zerosquare (./3899):Franchement, le PHP a une mauvaise réputation à cause de certains trucs historiques, et le fait que c'est permissif (donc qui permet de faire du code dégeu), mais tu peux faire des trucs très propres quand même, encore plus avec les frameworks modernes (et composer ça marche plutôt très bien).
SCPCD : ça marche aussi si tu remplaces "C++" par "Java" (ou "Javascript", ou "PHP"...)
Folco (./3884) :Je veux voir le langage qui te permet de faire ce genre de transformations de types avec une syntaxe plus lisible.
C'est quand même violemment inbranlable la syntaxe du C++ ##gerbe##
Pen^2 (./3902) :Le Java est moins puissant que le C++, il est compilé en bytecode (donc tu as l'overhead du JIT qui le rend souvent plus lent que du code natif), il utilise un GC (avec tous les inconvénients que ça engendre), …
(et concernant java j'ai toujours pas compris ce qu'on lui reproche, justement c'est pas permissif, il a une bonne bibliothèque standard, etc. Et c'est pas plus verbeux qu'autre chose, et sans doute largement moins que le C++. C'est pas bien de troller comme ça un dimanche, tu pourrais attendre lundi )
Kevin Kofler (./3907) :La belle affaire, et l'assembleur encore plus. Sauf que c'est tellement pénible et compliqué à écrire que je ne serais pas étonné que dans le monde réel la tendance s'inverse presque...
Le Java est moins puissant que le C++
Kevin Kofler (./3907) :En quoi ça concerne le langage lui même ? La même chose compilée en natif changerait quoi pour le gars écrivant le programme ?
il est compilé en bytecode
Kevin Kofler (./3907) :Ah oui, effectivement, s'affranchir de la libération mémoire, un inconvénient très fâcheux.
il utilise un GC (avec tous les inconvénients que ça engendre)
Kevin Kofler (./3909) :Frahcnement, j'ai jamais vu un programme bloqué à cause du GC, faut arrêter avec cet argument. En théorie OK, mais dans ce cas là, faut aussi arrêter les interruptions matérielles, etc
Un autre gros inconvénient est que le GC bloque l'exécution régulièrement à des endroits difficilement prévisibles
Kevin Kofler (./3909) :Certes, mais ça ne m'a strictement jamais posé problème, et je ne suis même pas sûr d'en avoir déjà écrit un.
tu ne contrôles pas quand le finalisateur de l'objet sera appelé.
Kevin Kofler (./3909) :Je ne vois pas bien en quoi c'est un hack, ça fait ce que ça dit et c'est plutôt pratique
il y a ce hack de "try with resources"
Kevin Kofler (./3909) :Il y a des warnings, et tu peux oublier d'écrire ton close dans le destructeur C++, oublier de libérer la mémoire, etc. Bref, oui, tu peux oublier plein de trucs, mais je ne suis pas certain que le Java soit moins sûr que le C++ sur ce plan là.
Sauf que tu ne peux pas oublier d'appeler le destructeur en C++ alors que tu peux oublier d'utiliser "try with resources" ou d'appeler close() explicitement en Java.
Pen^2 (./3910) :Ça s'y rapproche en pratique. Dans mon expérience, le -Xms ne sert pas à grand chose, le -Xmx est la seule chose qui compte réellement.
Je ne connais pas les détails des implémentations des GC, mais je doute quand même un peu qu'ils continuent d'allouer jusqu'au XMX sans rien libérer avant, ce serait débile et il ne me semble pas que ce soit ce que je constate.
Mais là encore, c'est un problème de runtime et moi je parle plutôt du langageLe langage ne peut pas être implémenté sans GC (à moins de tout leaker, ce qui n'est pas une implémentation utilisable en pratique). Même les compilateurs qui compilent le Java en code natif utilisent un GC, par exemple, GCJ utilisait le Boehm Conservative GC. Donc les inconvénients existent dans tout runtime, de par la conception du langage.
Tu as un langage qui te promet sur le papier que tu ne dois jamais rien libérer et tu te tapes une construction qui reprend une syntaxe RAII (de plus avec un mot clé qui à l'origine est prévu pour autre chose, mais try-finally allait déjà dans le même sens) en tant que sucre syntaxique pour un workaround (la méthode close()) parce que tu dois après tout, si si, libérer explicitement tes ressources. FAIL!Kevin Kofler (./3909) :Je ne vois pas bien en quoi c'est un hack, ça fait ce que ça dit et c'est plutôt pratique
il y a ce hack de "try with resources"
Godzil (./3911) :Oui, "640 KB should be enough for everybody".
Sinon c’est un problème de runtime, mais le fait que java a des tailles fixes de mémoire est un vrai problème dignes d’OS des années 1980...
Kevin Kofler (./3906) :En PHP, tu utilises "=" et zou, tu transformes ton type (oui, je sais, mais na )
Je veux voir le langage qui te permet de faire ce genre de transformations de types avec une syntaxe plus lisible.
Godzil (./3914) :Je fais référence au fait que DOS et pas mal d'applications DOS n'utilisent que 640 kibioctets même si la machine a des gigaoctets de RAM. Ça rejoint les tailles arbitraires de heap Java.
Non rien avoir avec cette citation.
Zerosquare (./3917) :
M'étonne pas, Nil aime bien transformer les types en meufs, et vice-versa.
Arvi89 (./3901) :Ce discours vaut pour n'importe quel langage. Le soucis est justement que c'est trop facile de faire des trucs dégueux, donc en pratique, les gens font des truc dégueux.
Franchement, le PHP a une mauvaise réputation à cause de certains trucs historiques, et le fait que c'est permissif (donc qui permet de faire du code dégeu), mais tu peux faire des trucs très propres quand même, encore plus avec les frameworks modernes (et composer ça marche plutôt très bien).
Warpten (./3921) :Ce n'est pas final qui empêche la libération par le GC, mais l'utilisation dans le callback (qui maintient en vie la référence).
ils ont des problemes de memoire parce que y a du final partout pour reutiliser des variables dans des callback
Pen^2 (./3902) :On a a déjà discuté, ce qu'on lui reproche est plus ou moins juste suivant le sens par lequel on l'aborde. En fait comme souvent dans les discutions a propos de langage de programmation, tous les argument sont pertinent, on oublie juste que s'il existe plusieurs langages, c'est avant tout que certain sont bons pour certaines choses et pas d'autre.
(et concernant java j'ai toujours pas compris ce qu'on lui reproche, justement c'est pas permissif, il a une bonne bibliothèque standard, etc. Et c'est pas plus verbeux qu'autre chose, et sans doute largement moins que le C++. C'est pas bien de troller comme ça un dimanche, tu pourrais attendre lundi )
Uther (./3927) :
mais il reste généralement plus performant et maintenable que les langes a typage dynamique