Pour ton coup du String/StringBuffer. OK, mais alors pourquoi le type String existe ? Excuse-moi mais pour déclarer une chaîne, ça me parait plus logique d'utiliser le type String, que le type StringBuffer.
Et puis ce qu'on considère comme des réussites en Java comme Jext ou Borland JBuilder, c'est LENT. Jext me bouffe 5MO de RAM, pour un éditeur de texte, c'est pas normal !! JBuilder, j'en parle même pas. Delphi est 10 fois plus rapide et moins bouffeur de RAM.
On dit souvent à propos de Java que l'avantage c'est les classes de base. OK toujours, mais les classes de base sont horriblement lentes. On doit donc réécrire autre chose, mais tu perds la portabilité, car tu dois linker avec les librairies systèmes.
Autre chose, javac n'optimise RIEN !! Si tu désassemble ton bytecode, tu verras que c'est affreux !! Tout est traduit litéralement, sans aucun effort d'optimisation, et pourtant javac est long à la compilation.
Le problème essentiel de Java va être que tu as deux possibilités pour programmer : la débutante où tu utilises les classes de bases et les types String et autres. Alors c'est facile, mais lent, et tu fait taper sur les doigts. Deuxième solution, tu bidouilles ton code à la main, t'optimises, tu désassemble pour corriger, bref tu bosses. Mais ou est la simplicité de Java à ce moment là ? On se croirait revenu en asm : si tu décrémente ta boucle au lieu de l'incrémenter, tu économise une instruction, et donc ... Je m'arrêtes là, mais je croyais que le but des langages de haut niveau était justement d'éviter ce genre de trucs, en les mettant au niveau du compilateur.
Le pense donc que Java n'est pas un mauvais langage en soi, mais qu'il s'embrouille avec des trucs imbuvables, comme sa volonté d'adopter à peu près la syntaxe de C++, ce qui compléxifie inutilement la chose. Java est jouable pour des mainframes ou la vitesse n'est pas génante, vu la puissance qui est sous le capot. Pour moi, dans l'état actuel des choses, programmer un Java rapide est très dur, bien plus que du C, et très contraignant.
[^] # Re: en JAVA????
Posté par Anonyme . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.
Et puis ce qu'on considère comme des réussites en Java comme Jext ou Borland JBuilder, c'est LENT. Jext me bouffe 5MO de RAM, pour un éditeur de texte, c'est pas normal !! JBuilder, j'en parle même pas. Delphi est 10 fois plus rapide et moins bouffeur de RAM.
On dit souvent à propos de Java que l'avantage c'est les classes de base. OK toujours, mais les classes de base sont horriblement lentes. On doit donc réécrire autre chose, mais tu perds la portabilité, car tu dois linker avec les librairies systèmes.
Autre chose, javac n'optimise RIEN !! Si tu désassemble ton bytecode, tu verras que c'est affreux !! Tout est traduit litéralement, sans aucun effort d'optimisation, et pourtant javac est long à la compilation.
Le problème essentiel de Java va être que tu as deux possibilités pour programmer : la débutante où tu utilises les classes de bases et les types String et autres. Alors c'est facile, mais lent, et tu fait taper sur les doigts. Deuxième solution, tu bidouilles ton code à la main, t'optimises, tu désassemble pour corriger, bref tu bosses. Mais ou est la simplicité de Java à ce moment là ? On se croirait revenu en asm : si tu décrémente ta boucle au lieu de l'incrémenter, tu économise une instruction, et donc ... Je m'arrêtes là, mais je croyais que le but des langages de haut niveau était justement d'éviter ce genre de trucs, en les mettant au niveau du compilateur.
Le pense donc que Java n'est pas un mauvais langage en soi, mais qu'il s'embrouille avec des trucs imbuvables, comme sa volonté d'adopter à peu près la syntaxe de C++, ce qui compléxifie inutilement la chose. Java est jouable pour des mainframes ou la vitesse n'est pas génante, vu la puissance qui est sous le capot. Pour moi, dans l'état actuel des choses, programmer un Java rapide est très dur, bien plus que du C, et très contraignant.