Java
Période. Arrêt complet. Fin de l'histoire.
Où commencer? Oh, je sais par où commencer: les génériques de Java incroyablement compliqués et laids et stupides et intrinsèquement cassés . Dois-je en dire plus? :( Ok bien, alors: tapez l'effacement .
Ensuite, il y a la gestion non déterministe des ressources. Kewl feetcher!
Quelle est la prochaine étape? Oh ouais: les stupides regex de Java sont mon boeuf le plus irritant et bouillonnant. Je ne peux pas compter le nombre de fois où j'ai été arrosé parce que je n'ai pas suffisamment de barres obliques inverses. C'est encore pire que de ne pas avoir accès aux propriétés Unicode de ce millénaire - ce qui est un taureau complet. Dix ans effrayants dépassés !!! Totalement inutile. Trash it.
Ensuite, il y a le bogue que les raccourcis de classe de caractères ne fonctionnent pas sur non-ASCII. Quelle douleur royale! Et n'envisagez même pas d'utiliser \p{javaWhiteSpace}
; il ne fait pas la bonne chose avec plusieurs points de code d'espaces blancs Unicode très courants.
Saviez-vous qu'il y a une \p{javaJavaIdentifierStart}
propriété? À quoi pensaient-ils? Je suis tellement content qu'ils aient eu de tels voyants intelligents wurkin sur dis difficile.
Avez-vous déjà essayé d'utiliser l'indicateur CANON_EQ? Savez-vous que c'est vraiment le cas et ce qu'il ne fait pas ? Qu'en est-il du soi-disant «boîtier Unicode»? Un tas de boîtiers normaux ne fonctionnent tout simplement pas.
Ensuite, il est difficile d'écrire des expressions rationnelles maintenables. Java n'a toujours pas compris comment écrire des chaînes multilignes, vous finissez donc par écrire des choses folles comme ceci:
"(?= ^ [A-Z] [A-Za-z0-9\\-] + $) \n"
+ "(?! ^ .* \n"
+ " (?: ^ \\d+ $ \n"
+ " | ^ [A-Z] - [A-Z] $ \n"
+ " | Invitrogen \n"
+ " | Clontech \n"
+ " | L-L-X-X \n"
+ " | Sarstedt \n"
+ " | Roche \n"
+ " | Beckman \n"
+ " | Bayer \n"
+ " ) # end alternatives \n"
+ ") # end negated lookahead \n"
Quelles sont toutes ces nouvelles lignes? Oh, juste la stupidité Java. Ils ont utilisé des commentaires Perl, pas des commentaires Java ( idiots! ) Qui vont jusqu'à la fin de la ligne. Donc, si vous ne les mettez pas \n
là, vous coupez le reste de votre modèle. Duh et double duh!
N'utilisez pas d'expressions régulières en Java: vous finirez par vouloir casser des choses, tout cela est si douloureux et cassé. Je ne peux pas croire que les gens supportent ça. Certains non .
Ensuite, nous pouvons commencer à parler du non-sens idiot de Java avec des encodages. Tout d'abord, il y a le fait que le codage par défaut de la plate-forme est toujours un codage 8 bits boiteux même si les charchars de Java sont Unicode. Ensuite, il y a comment ils ne déclenchent pas d'exception en cas d'erreur de codage. Vous êtes assuré d'obtenir de la merde. Ou que diriez-vous de ceci:
OutputStreamWriter(OutputStream out)
Creates an OutputStreamWriter that uses the default character encoding.
OutputStreamWriter(OutputStream out, Charset cs)
Creates an OutputStreamWriter that uses the given charset.
OutputStreamWriter(OutputStream out, CharsetEncoder enc)
Creates an OutputStreamWriter that uses the given charset encoder.
OutputStreamWriter(OutputStream out, String charsetName)
Creates an OutputStreamWriter that uses the named charset.
Quelle est la différence? Saviez-vous qu'un seul de ceux-ci lèvera une exception si vous avez une erreur d'encodage? Les autres les muselent.
Ensuite, il y a l'idiotie des caractères Java qui ne suffisent pas à contenir un personnage! Que diable pensent-ils? C'est pourquoi je les appelle des charchars. Vous devez écrire du code comme celui-ci si vous pensez qu'il fonctionne correctement:
private static void say_physical(String s) {
System.out.print("U+");
for (int i = 0; i < s.length(); i++) {
System.out.printf("%X", s.codePointAt(i));
if (s.codePointAt(i) > Character.MAX_VALUE) { i++; } // UG!
if (i+1 < s.length()) { System.out.printf("."); }
}
}
Et qui pense faire ça? À côté de personne.
Combien de personnages y a-t-il "\uD83D\uDCA9"
? Un ou deux? Cela dépend de la façon dont vous les comptez. Le moteur d'expression régulière traite bien sûr des caractères logiques, donc un modèle ^.$
réussira et un modèle ^..$
échouera. Cette folie est démontrée ici:
String { U+61, "\u0061", "a" } =~ /^.$/ => matched.
String { U+61, "\u0061", "a" } =~ /^..$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" } =~ /^.$/ => failed.
String { U+61.61, "\u0061\u0061", "aa" } =~ /^..$/ => matched.
String { U+DF, "\u00DF", "ß" } =~ /^.$/ => matched.
String { U+DF, "\u00DF", "ß" } =~ /^..$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" } =~ /^.$/ => failed.
String { U+DF.DF, "\u00DF\u00DF", "ßß" } =~ /^..$/ => matched.
String { U+3C3, "\u03C3", "σ" } =~ /^.$/ => matched.
String { U+3C3, "\u03C3", "σ" } =~ /^..$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" } =~ /^.$/ => failed.
String { U+3C3.3C3, "\u03C3\u03C3", "σσ" } =~ /^..$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" } =~ /^.$/ => matched.
String { U+1F4A9, "\uD83D\uDCA9", "💩" } =~ /^..$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" } =~ /^.$/ => failed.
String { U+1F4A9.1F4A9, "\uD83D\uDCA9\uD83D\uDCA9", "💩💩" } =~ /^..$/ => matched.
Cette idiotie est tout parce que vous ne pouvez pas écrire le parfaitement raisonnable \u1F4A9
, et bien sûr, vous ne recevez aucun avertissement que vous ne pouvez pas le faire. Cela fait juste la mauvaise chose.
Stoooopid.
Pendant que nous y sommes, la \uXXXX
notation entière est congénitalement morte de cerveau. Le préprocesseur Java ( oui, vous m'avez entendu ) y arrive avant Java, il vous est donc interdit d'écrire des choses parfaitement raisonnables comme "\u0022"
, car au moment où Java voit cela, son préprocesseur l'a transformé """
, donc vous perdez. Oh attendez, pas si c'est dans une expression régulière! Vous pouvez donc utiliser "\\u0022"
très bien.
Riiiiiiiight!
Saviez-vous qu'il n'y a aucun moyen en Java de faire un isatty(0)
appel? Vous n'êtes même pas autorisé à penser de telles pensées. Ce ne serait pas bon pour toi.
Et puis il y a toute l'abomination du chemin de classe.
Ou le fait qu'il n'y a aucun moyen de spécifier l'encodage de votre fichier source Java dans ce même fichier source afin de ne pas le perdre? Encore une fois, je demande à savoir: QU'EN PENSENT-ILS?
Arrète la folie! Je ne peux pas croire que les gens supportent ces ordures. C'est une blague complète. Je préfère être un Walmart plus gourmand que de subir les frondes et les flèches de la folie scandaleuse de Java. Tout est cassé, et non seulement ils ne peuvent pas le réparer, ils ne le répareront pas.
Ceci par les mêmes personnes foxy-grapey qui se targuaient d'une langue qui rendait illégal d'avoir une printf()
fonction. Gee, ça a très bien fonctionné, n'est-ce pas!?
Des crânes engourdis. La gifle est trop gentille pour eux. Si je voulais programmer en assembleur, je le ferais. Ce n'est pas une langue récupérable. L'empereur n'a pas de vêtements.
Nous le détestons. Nous le détestons pour toujours . Laissez-le mourir mourir mourir !