Quelles sont les cinq choses que vous détestez au sujet de votre langue préférée? [fermé]

Wow, je suis surpris que SQL ne l'ait pas encore fait ici. Suppose que cela signifie que personne ne l'aime :)

• syntaxe incohérente entre les implémentations
• les différences subtiles de code peuvent avoir des ramifications de performances massives pour des raisons apparemment obscures
• mauvais support pour la manipulation de texte
• coût D'entrée facile mais courbe d'apprentissage raide vers la maîtrise de la langue
• normalisation minimale dans la communauté pour les meilleures pratiques, ceci inclut style de syntaxe.

...Et quelques raisons bonus pour le détester, sans frais supplémentaires

• la clause WHERE va en dernier, ce qui facilite l'exécution prématurée d'une mise à jour ou D'une suppression, détruisant toute la table. Au lieu de cela, le où devrait aller quelque part à l'avant.
• il est difficile de mettre en œuvre la division relationnelle.
• je peux définir une valeur à NULL, mais je ne peux pas la tester pour l'égalité avec NULL. Je peux vérifier est nul, mais cela complique simplement le code-inutilement, à mon avis.
• Pourquoi devons-nous respecter complètement la formule pour une colonne groupée, plutôt que de définir un alias sur la colonne, puis de le grouper par l'alias (ou l'index de colonne comme avec SORT)?

JavaScript:

1. Toutes les choses les plus cool sont incroyablement complexes, mais alors, toute la fraîcheur est également enveloppée dans une si petite quantité de code que vous vous sentez stupide de lutter pour le suivre

2. '+' est un choix absurde d'opérateur pour la concaténation dans un langage faiblement typé. Étaient-ils essayer pour effrayer les noobs?

3. C'est un champ de mines de compatibilité multi-navigateur (peu importe s'il est même allumé ou non)

4. Il est généralement non fiable-associé à l'écume telle que le blocage du bouton de retour, les pop-ups qui ne meurent jamais, etc.

5. Il est presque impossible de déboguer car il n'y a que quelques messages d'erreur différents et quelques types différents (Nombre, chaîne,objet, etc.)

Si ce n'était pas pour jQuery, je le détesterais probablement autant que je le faisais:)

PHP:

1) me force à faire des variables inutiles:

$parts = explode('|', $string);
$first = $parts[0];

2) une implémentation de lambdas si boiteuse est à peu près équivalente à l'utilisation de eval() et si hideusement fausse que je ne l'ai jamais utilisée (voir http://www.php.net/create_function).

3) un système try / catch qui ne peut attraper environ 80% des erreurs qui pourraient se produire.

4) Le support Regex est tout aussi boiteux que le support lambda car il doit être écrit dans des chaînes régulières, ce qui en fait l'un des plus des outils de programmation difficiles à apprendre environ trois fois plus difficiles. Et PHP est censé être un langage "facile"?!?!?

5) aucun moyen de retirer en toute sécurité des choses de $_POST sans l'écrire deux fois ou créer votre propre fonction, ou en utilisant l'opérateur'@':

$x = isset($_POST['foo']['bar']) ? $_POST['foo']['bar'] : null;

6) réponse Bonus:'@'. Si vous ne pouvez pas être dérangé d'écrire votre code correctement, ajoutez simplement'@', et tant pis pour quiconque doit déboguer votre code plus tard.

C++

• beaucoup trop facile de corrompre la mémoire au hasard et de créer des bugs presque impossibles à trouver (bien que, Valgrind va un long chemin vers la réparation de cela).
• messages D'erreur du modèle.
• Lorsque vous utilisez des modèles, il est facile de devoir tout inclure dans un fichier, puis d'obtenir des temps de compilation stupides.
• la bibliothèque standard est une blague à l'époque moderne (toujours pas de threads ou de réseau par défaut?)
• beaucoup de vilains petits morceaux de C piquer à travers (en particulier, toutes les conversions entre court/int/unsigned/etc..)

C#/. NET:

• les Classes doivent être scellées par défaut
• Il ne devrait pas y avoir d'instruction lock - à la place, vous devriez avoir des objets de verrouillage spécifiques, et il devrait y avoir des méthodes telles que Acquire qui renvoient des jetons de verrouillage jetables. Corollaire: il ne devrait pas y avoir de moniteur pour chaque objet.
• GetHashCode() et Equals() ne devraient pas être dans System.Object - tout ne convient pas au hachage. Au lieu de cela, ayez un IdentityComparer qui fait la même chose, et gardez le IComparer<T>, IComparable<T>, IEqualityComparer<T> et IEquatable<T> interfaces pour des comparaisons personnalisées.
• mauvais support pour l'immuabilité
• mauvaise façon de découvrir les méthodes d'extension - cela devrait être une décision beaucoup plus consciente que le simple fait que j'utilise un espace de noms.

Ceux-ci étaient sur le dessus de ma tête-demandez-moi demain et je vais venir avec un autre 5:)

C

• manipulation de chaîne.

Devoir traiter manuellement les tampons de chaîne est une douleur sujette aux erreurs. Étant donné que tant d'informatique bouge et modifie vraiment les chaînes (les ordinateurs ne sont pas utilisés autant pour les gros nombres que les gens pensaient qu'ils le seraient quand), c'est vraiment agréable de pouvoir utiliser des langages gérés ou des objets string C++pour les gérer. Quand je dois le faire en C droit, j'ai l'impression de nager dans des sables mouvants.

Que diriez-vous de cinq choses que je déteste sur les listes" choses que je déteste sur certaines langues"? : D

5- peindre un rouge orange n'en fait pas une pomme.

Lorsqu'un langage est conçu, les concepteurs ont généralement à l'esprit ce qu'il est utile pour. L'utiliser pour quelque chose de complètement différent peut fonctionner, mais se plaindre quand ce n'est pas juste stupide. Prenez Python. Je suis sûr que quelqu'un A ou que quelqu'un fera un jour un utilitaire pour créer des exe à partir du code Python. Pourquoi sur Dieu terre voulez-vous vouloir faire cela? Ce serait bien-ne vous méprenez pas - mais cela n'a aucune utilité. Alors cessez de vous plaindre!

Un projet bien conçu contiendrait probablement du code provenant de plusieurs langues. Cela ne veut pas dire que vous ne pouvez pas terminer un projet avec une seule langue. Certains projets peuvent être bien dans les capacités de la langue que vous utilisez.

4- êtes-vous debout sur les jambes en bois?

La plate-forme peut être une grande influence de ce que la langue pouvez faire. Avec les garbage collectors de nos jours, ou bien même pascals tentative précoce de "garbage collection", peut aider à la mémoire s'estomper (peut-être malloc plus de ram??). Les ordinateurs sont plus rapides et donc bien sûr, nous attendons plus de nos langues. Et franchement, nous devrions probablement. Cependant, il y a un prix énorme à payer pour la commodité du compilateur pour créer des tables de hachage ou des chaînes ou une variété d'autres concepts. Ces choses peuvent ne pas être héritées de la plate-forme dont elles sont utilisées. Pour dire qu'ils sont facile pour inclure à une langue me dit juste que vous ne pouvez pas avoir une jambe pour se tenir debout.

3- C'est la faute de qui?

Bugs. Vous savez. J'aime bugs. Pourquoi ai-je l'amour de bugs. Parce que ça veut dire que je peux garder mon travail. Sans bugs, il y aurait beaucoup de pizzerias fermées. Cependant, les utilisateurs détestent les bugs. Mais voici une petite giclée d'eau froide. Chaque bug est la faute des programmeurs. Pas le langage. un langage avec une syntaxe aussi stricte qui réduirait considérablement le nombre de bugs étaient possibles à générer serait un langage complètement inutile. Ses capacités pourraient probablement être comptées sur une main. Vous voulez la flexibilité ou de la puissance? Vous avez des bugs. Pourquoi? Parce que tu n'es pas parfait, et tu fais des erreurs. Prenez un exemple vraiment identifiable en C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

Nous savons tous ce que ça va faire. Cependant, ce que certains d'entre nous ne réalisent peut-être pas.. cette fonctionnalité peut être très bénéfique. En fonction de ce que vous faites. Des dépassements de mémoire tampon sont le coût de cette fonctionnalité. Le code ci-dessus. Si je publiais ça au public. C'est de nouveau.. dites-le avec moi.. "Ma faute". Pas C pour m'avoir permis de le faire.

2- on ne devrait pas mettre ça dans la corbeille?

Il est très facile de pointer une fonctionnalité dans une langue que nous ne comprenons pas parce que nous ne l'utilisons pas souvent et l'appelons stupide. Se plaindre que c'est là etc. Goto me divertit toujours. Les gens se plaignent toujours que goto soit dans une langue. Pourtant je parie que votre dernier programme comprenait un type de goto. Si vous avez déjà utilisé une pause ou continuer, vous avez utilisé un goto. C'est ce qu'il est. Certes, c'est un Goto" sûr", mais c'est ce que c'est. Les Goto ont leurs usages. Que les gotos" implicites " comme continue ou break soient utilisés ou explicites (en utilisant le mot-clé "goto" pour n'importe quelle langue). Non pas que les développeurs de langage sont impeccables, mais généralement... si la fonctionnalité existe depuis la nuit des temps (pour cette langue). Il est probable que cet aspect soit une qualité déterminante de cette langue. Sens.. il est utilisé et probablement ne traîne pas à cause de la rétrocompatibilité. Il est utilisé aujourd'hui. D'autant plus que 5 minutes auparavant. Et utilisé correctement. Bien.. on peut dire que quelqu'un l'utilise mal aussi, mais cela concerne #3 sur ma liste.

1. - Tout est un objet.

Ok.. celui-ci est vraiment un sous-ensemble de n ° 2. Mais c'est de loin la plainte la plus ennuyeuse que je vois dans les listes de haine. Tout n'est pas un objet. Il y a un grand nombre de concepts qui n'appartiennent pas ou besoin d'être des objets. Mettre les choses là où elles n'appartiennent pas est tout simplement laid et peut diminuer l'efficacité d'un programme. Assurer. Peut-être pas beaucoup selon la langue. Cela concerne également le numéro 5. Ce moyen... Oui. Le mondial sont ok. Les fonctions appliquées aux méthodes statiques sont correctes. La combinaison de la programmation OO avec des fonctions globales est ok. Maintenant.. cela ne signifie pas que nous devrions tous sortir et" libérer " notre code de ses modèles d'objets non plus. Lors de la conception d'une section de code ou d'un projet entier, que se passe-t-il derrière les scènes devraient être prises en compte lors de la mise en place. Non seulement là où ce concept vit et de nombreux autres facteurs. Pourquoi envelopper des fonctions globales dans des classes ou des concepts d'espace de nom si cela ne sert à rien? Prenez des variables membres statiques. Qui amuse beaucoup de moi parce que.. Bien..En fonction de la langue et de la mise en œuvre bien sûr, mais en général, vous venez de déclarer un global. Oui, il y a quelques raisons d'envelopper ces concepts non-OO dans des wrappers OO. L'un bien sûr étant auto documentant code. Qui peut faire sens. Si.. comme je l'ai dit. Ne sortez pas et "libérez" votre code. Mais tout bon langage moderne aura un concept global en dehors de sa modélisation OO. Oui, je veux spécifiquement souligner qu'un langage de programmation OO sans concept global a probablement un sérieux défaut de conception. Encore une fois cependant.. cela dépend de l'intention et de la conception de la langue, donc je n'essaie pas de choisir une langue spécifique et il y en a beaucoup trop à analyser ici. Anywho, considérez où le code devrait vivre et être le plus efficace. L'ajout d'un tas de flare à quelque chose qui n'ajoute pas de fonctionnalité ou de support porte simplement le clavier plus rapidement. Il n'est pas n'importe qui tout de bon. Bien.. sauf si vous aimez les points de brownie de la personne qui vous a probablement appris à tort que tout est un objet.

En bref, la programmation ne se contente pas de taper sur le clavier. Il y a beaucoup de considérations de conception à tout projet. Je sais que c'est cliché, mais vous devez regarder à partir de chaque angle. Même avec des langues de type sûr de nos jours. Vous ne vous contentez pas de lancer du code et de vous attendre à ce qu'il fonctionne bien. Assurer.. cela peut fonctionner, mais ce n'est peut-être pas la bonne façon de s'y prendre. Dans l'ensemble, Choisissez la langue et le format qui conviennent le mieux au travail spécifique et à l'environnement. Mais non langue enlève la pensée derrière elle. Si vous ne pensez pas.. vous avez juste à taper.

Cinq choses que je déteste à propos de Java (qui, actuellement, est ma langue préférée) dans aucun ordre particulier.

1. autant que je suis fan des génériques Java, il y a beaucoup de bizarreries qui découlent de la façon dont il a été conçu. En tant que tel, il y a une myriade de limitations ennuyeuses avec les génériques (dont certaines sont le résultat de l'effacement de type).
2. L'objet way.clone () et le travail des interfaces Clonables est totalement cassé.
3. au lieu de prendre la route et de faire tout un objet (a.la. SmallTalk), Sun wimped out a créé deux catégories distinctes de types de données: les objets et les primitives. En conséquence, il y a maintenant Deux représentations pour les types de données fondamentales et les curiosités bizarres telles que la boxe/unboxing et ne pas être en mesure de mettre des primitives dans une Collection.
4. Le Swing est trop complexe. Ne vous méprenez pas: il y a beaucoup de choses cool que L'on peut faire avec Swing, mais c'est un excellent exemple de sur-Ingénierie.
5. cette plainte finale est également la faute de Sun et ceux qui ont écrit des bibliothèques XML pour Java. Les bibliothèques Java XML sont beaucoup trop compliquées. Pour simplement lire dans un fichier XML, je dois souvent me soucier de l'analyseur que j'utilise: DOM ou SAX? Les API pour chacun est tout aussi déroutant. Support natif dans la langue pour facilement l'analyse / écriture XML serait très agréable.
6. java.util.Date suce. Non seulement c'est inutilement compliqué, mais toutes les méthodes utiles ont été obsolètes (et remplacés par d'autres qui augmentent la complexité).

Ruby a beaucoup de défauts liés à sa vitesse, mais je ne les déteste pas. Il a aussi des défauts avec l'évangélisation de la communauté allant à la mer, mais cela ne me dérange pas vraiment. Voici ce que je déteste:

• Les fermetures (blocs) ont 4 syntaxes de création différentes, et aucune d'entre elles n'est optimale. La syntaxe élégante est incomplète et ambiguë avec des hachages, et la syntaxe complète est moche.
• la communauté a tendance à être contre la documentation réelle, favorisant "lire le code". Je trouve ce enfantin et paresseux.
• l'abus de métaprogrammation, en particulier dans les bibliothèques, fait des bogues un cauchemar à traquer.
• sur une note connexe, la métaprogrammation omniprésente rend un IDE complet difficile, voire impossible à réaliser.

• La façon dont le bloc passant aux fonctions est fait est stupide. Il n'y a aucune raison pour que les blocs soient passés en dehors de la liste des paramètres, ou aient une syntaxe spéciale étrange à accéder (yield). Je suis d'avis que les blocs auraient dû être donnés un moins ambigu la syntaxe (ou les hachages auraient pu utiliser différents délimiteurs; peut-être plutôt que {}), et passer en tant que paramètres aux méthodes aurait dû être comme tous les autres paramètres.

  object.method(1, {|a| a.bar}, "blah")
  

  Ces bizarreries, comme le bloc doit être le dernier paramètre passé et passer plus d'un bloc est différent avec une syntaxe plus longue, m'ennuient vraiment.

Perl

• Usage mixte des sigils

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = $array[0]; # not @array[0], you would get the length instead
  my $four = $array->[0]; # definitely not $array[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = @$array[1,2]; # coerce to array first
  
  my $length_a = @array;
  my $length_s = @$array;
  
  my $ref_a = \@array;
  my $ref_s = $array;
  

  • Par exemple aucun de ceux-ci sont les mêmes:

    $array[0]   # First element of @array
    @array[0]   # Slice of only the First element of @array
    %array[0]   # Syntax error
    $array->[0] # First element of an array referenced by $array
    @array->[0] # Deprecated first element of @array
    %array->[0] # Invalid reference
    $array{0}   # Element of %array referenced by string '0'
    @array{0}   # Slice of only one element of %array referenced by string '0'
    %array{0}   # Syntax error
    $array->{0} # Element of a hash referenced by $array
    @array->{0} # Invalid reference
    %array->{0} # Deprecated Element of %array referenced by string '0'
    

  Dans Perl6 c'est écrit:

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = @array[0];
  my $four = $array[0]; # $array.[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = $array[1,2];
  
  my $length_a = @array.length;
  my $length_s = $array.length;
  
  my $ref_a = @array;
  my $ref_s = $array;
  

• Manque de vrai OO

  package my_object;
  # fake constructor
  sub new{ bless {}, $_[0] }
  # fake properties/attributes
  sub var_a{
    my $self = shift @_;
    $self->{'var_a'} = $_[0] if @_;
    $self->{'var_a'}
  }
  

  Dans Perl6 c'est écrit:

  class Dog is Mammal {
      has $.name = "fido";
      has $.tail is rw;
      has @.legs;
      has $!brain;
      method doit ($a, $b, $c) { ... }
      ...
  }
  

• Caractéristiques regex mal conçues

  /(?=regexp)/;           # look ahead
  /(?<=fixed-regexp)/;    # look behind
  /(?!regexp)/;           # negative look ahead
  /(?<!fixed-regexp)/;    # negative look behind
  /(?>regexp)/;           # independent sub expression
  /(capture)/;            # simple capture
  /(?:don't capture)/;    # non-capturing group
  /(?<name>regexp)/;      # named capture
  /[A-Z]/;                # character class
  /[^A-Z]/;               # inverted character class
  # '-' would have to be the first or last element in
  # the character class to include it in the match
  # without escaping it
  /(?(condition)yes-regexp)/;
  /(?(condition)yes-regexp|no-regexp)/;
  /\b\s*\b/;              # almost matches Perl6's <ws>
  /(?{ print "hi\n" })/;  # run perl code
  

  Dans Perl6 c'est écrit:

  / <?before pattern>  /;   # lookahead
  / <?after pattern>   /;   # lookbehind
  / regexp :: pattern  /;   # backtracking control
  / ( capture )        /;   # simple capture
  / $<name>=[ regexp ] /;   # named capture
  / [ don't capture ]  /;   # non-capturing group
  / <[A..Z]>           /;   # character class
  / <-[A..Z]>          /;   # inverted character class
  # you don't generally use '.' in a character class anyway
  / <ws>               /;   # Smart whitespace match
  / { say 'hi' }       /;   # run perl code
  

• Manque de multiples expédition

  sub f(   int $i ){ ... }  # err
  sub f( float $i ){ ... }  # err
  sub f($){ ... } # occasionally useful
  

  Dans Perl6 c'est écrit:

  multi sub f( int $i ){ ... }
  multi sub f( num $i ){ ... }
  multi sub f( $i where $i == 0 ){ ... }
  multi sub f(     $i ){ ... } # everything else
  

• Mauvaise surcharge de L'opérateur

  package my_object;
  use overload
    '+' => \&add,
    ...
  ;
  

  Dans Perl6 c'est écrit:

  multi sub infix:<+> (Us $us, Them $them) |
                      (Them $them, Us $us) { ... }
  

Je vais faire PHP comme je l'aime parfois et Python sera fait beaucoup trop.

• Pas d'espace de noms; tout est dans un sorte de très grand espace de noms qui est l'enfer dans des environnements plus grands

• Manque de normes quand il s'agit de fonctions: Tableau fonctions prendre un aiguille comme premier argument, botte de foin comme deuxième (voir array_search ). Les fonctions de chaîne prennent souvent le botte de foin première, aiguille deuxième (voir strpos). D'autres fonctions juste utiliser différents schémas de nommage: bin2hex, strtolower, cal_to_jd

  Certaines fonctions ont un retour étrange valeurs, hors de ce qui est normal: cette vous oblige à avoir une troisième variable déclaré de nulle part alors que PHP pourrait interpréter efficacement un vide tableau comme false avec son type jongler. Il y a près pas d'autres fonctions faisant la même chose.

  $var = preg_match_all('/regexp/', $str, $ret);
  echo $var; //outputs the number of matches 
  print_r($ret); //outputs the matches as an array
  

• La langue (JUSQU'à PHP6) fait son mieux vaut respecter un proche retardé rétrocompatibilité, fabrication il porter de mauvaises pratiques et fonctions autour quand pas nécessaire (voir mysql_escape_string vs mysql_real_escape_string).

• Le langage a évolué à partir d'un création de modèles de langage à un un backend complet. Cela signifie que quelqu'un peut produire n'importe quoi quand ils veulent, et ça devient abusé. Vous vous retrouvez avec moteurs de modèles pour un modèle langue...

• Il suce à importer des fichiers. Vous 4 façons différentes de le faire (include, include_once, exiger, require_once), ils sont tous lents, très lent. En fait, l'ensemble de la langue est lente. Au moins, assez plus lent que python (même avec un cadre) et RoR de ce que je rassembler.

J'aime toujours PHP, cependant. C'est la tronçonneuse du développement web: vous voulez un site petit à moyen fait très vite et être sûr que n'importe qui peut l'héberger (bien que les configurations puissent différer)? PHP est là, et il est tellement omniprésent qu'il ne faut que 5 minutes pour installer une pile complète LAMP ou WAMP. Eh bien, je suis revenir à travailler avec Python maintenant...

Voici quelques choses que je n'aime pas à propos de Java (qui n'est pas ma langue préférée):

• effacement de type générique (c'est-à-dire pas de génériques réifiés)
• incapacité d'attraper plusieurs exceptions (de types différents) dans un seul bloc de capture
• Manque de destructeurs (finalize() est un très mauvais substitut)
• Pas de support pour les fermetures ou le traitement des fonctions comme des données (les classes internes anonymes sont un substitut très verbeux)
• exceptions vérifiées en général, ou plus spécifiquement, vérification des exceptions irrécupérables (par exemple SQLException)
• Aucune prise en charge au niveau de la langue pour les collections littérales
• aucune inférence de type lorsque les constructeurs de classes génériques sont appelés, c'est-à-dire que le ou les paramètres de type doivent être répétés des deux côtés du '= '

C++

1. Syntaxe Du Modèle
2. Problèmes D'héritage de diamant
3. la pléthore/le manque de bibliothèques standard que les langages modernes ont (bien que boost se rapproche).
4. IOStreams
5. la syntaxe utilisée autour D'IOStreams

Python

1. les espaces sont significatifs (parfois)
2. mots clés soulignés
3. Prise en charge limitée des threads (au moins actuellement)
4. "auto" au lieu de "ce"
5. les espaces sont significatifs (parfois)

Objectif-C

1) Pas d'espaces de noms, juste des conventions de nommage manuelles-cela ne me dérange pas en termes de séparation de classe, mais je manque de pouvoir importer toutes les définitions de classe dans un espace de noms en une seule ligne (comme import com. me. somelibrary.*).

2) les bibliothèques ont encore quelques trous dans des domaines importants comme le support des expressions rationnelles.

3) la syntaxe des propriétés est un peu maladroite, nécessitant trois lignes (dans deux fichiers séparés) pour déclarer une propriété.

4) j'aime le conserver / relâcher le modèle, mais il est plus facile qu'il ne devrait l'être de libérer une référence, puis de l'utiliser accidentellement plus tard.

5) bien que ce ne soit pas vraiment une fonctionnalité de langage, Xcode est tellement étroitement lié à L'utilisation D'Objective-C que je ne peux m'empêcher de penser à cet aspect... fondamentalement, l'autocomplétion, est très douteux. C'est plus comme un système qui vous récompense pour trouver quelque chose que vous voulez existe, puis le présente comme un choix par la suite. Mais alors je suppose que je n'ai jamais aimé autocomplete moteur.

C++

• Les Chaînes de caractères.
  Ils ne sont pas interopérables avec les chaînes de plate-forme, donc vous finissez par utiliser std::vector la moitié du temps. La stratégie de copie (copie en écriture ou copie profonde) n'est pas définie, de sorte que les garanties de performance ne peuvent pas être données pour une syntaxe simple. Parfois, ils s'appuient sur des algorithmes STL qui ne sont pas très intuitifs à utiliser. Trop de bibliothèques roulent leurs propres qui sont malheureusement beaucoup plus confortables à utiliser. Sauf si vous devez les combiner.

• Variété de représentations de chaîne
  Maintenant, c'est un petit problème de plate - forme-mais j'espère toujours que cela aurait été mieux quand une classe de chaîne standard moins obstinée aurait été disponible plus tôt. Les représentations de chaîne suivantes que j'utilise fréquemment:

  • LPCTSTR Générique,
  • LPC (W)STR alloué par CoTaskMemAlloc,
  • BSTR, _bstr _t
  • (W) chaîne,
  • CString,
  • std:: vecteur
  • un rouleau-mon-propre classe ( soupir ) qui ajoute la vérification de plage et les opérations de base à un tampon (W) char * de longueur connue

• Construire le modèle.
  Je suis malade à mort de tout le temps passé à brouiller avec qui-inclut-quoi, les déclarations en avant, l'optimisation des en-têtes précompilés et les inclusions pour garder au moins les temps de construction incrémentiels supportables, etc. C'était génial dans les années quatre-vingt, mais maintenant? Il y a tellement d'obstacles à emballer un morceau de code afin qu'il puisse être réutilisé que même les mamans le chien s'ennuie, écoute-moi.

• Difficile à analyser
  Cela rend les outils externes particulièrement difficiles à écrire et à obtenir. Et aujourd'hui, nous les gars c++ manquent surtout dans la chaîne d'outils. J'aime ma réflexion C# et mes délégués mais je peux vivre sans eux. Sans grand refactoring, Je ne peux pas.

• Le Filetage est trop dur
  Le langage ne le reconnaît même pas (maintenant), et les libertés du compilateur - bien que grandes-sont à douloureux.

• Initialisation statique et à la demande Techniquement, je triche ici: c'est une autre pièce de puzzle dans le "wrap up code for reuse": C'est un cauchemar d'obtenir quelque chose initialisé seulement quand c'est nécessaire. La meilleure solution à tous les autres problèmes de redist est de tout jeter dans les en - têtes, ce problème dit "neeener-vous ne pouvez pas".

Certes, beaucoup de cela dépasse la portée du langage strict, mais IMO toute la chaîne d'outils doit être jugée et les besoins d'évoluer.

JavaScript:

• Le prototype Object peut être modifié. Chaque objet de votre programme obtient de nouvelles propriétés, et quelque chose se casse probablement.

• Tous les objets sont des cartes de hachage, mais il est difficile de les utiliser en toute sécurité en tant que tels. En particulier, si l'une de vos clés se trouve être __proto__, Vous êtes en difficulté.

• Pas de fermeture d'objet à l'Heure de référence de la fonction. En fait, aucune fermeture d'objet du tout-à la place, this est définie chaque fois qu'un la fonction est appelée avec la notation d'objet ou l'opérateur new. Il en résulte beaucoup de confusion, en particulier lors de la création de rappels d'événements, car this n'est pas défini sur ce que le programmeur attend.

  • corollaire: l'appel d'une fonction sans notation d'objet ou l'opérateur new entraîne la définition de this égale à l'objet global, ce qui entraîne beaucoup de casse.

• Opérateur d'Addition surchargé pour effectuer également la concaténation de chaîne, malgré les deux les opérations étant fondamentalement différentes. Cela entraîne de la douleur lorsqu'une valeur que vous attendez d'être un nombre est en fait une chaîne.

• == et les opérateurs != effectuent une coercition de type. Les comparaisons entre différents types impliquent une liste de règles dont aucun mortel ne peut se souvenir complètement. Ceci est atténué par l'existence d'opérateurs === et !==.

• Les deux null et undefined existent, avec des significations subtilement différentes, mais redondantes. Pourquoi?

• Syntaxe Bizarre pour la mise en place de chaînes prototypes.

• parseInt(s) attend un nombre de style C, donc traite les valeurs avec des zéros en tête comme octal, etc. Vous pouvez au moins parseInt(s, 10) mais le comportement par défaut est source de confusion.

• Aucune portée de bloc.

• Peut déclarer la même variable plus d'une fois.

• Peut utiliser une variable sans la déclarer, auquel cas elle est globale et casse probablement votre programme.

• with { }.

• Vraiment difficile à documenter avec des outils de type JavaDoc.

Python:

• manque de typage statique
• gestion des arguments par défaut (en particulier le fait que vous pouvez modifiez l'argument par défaut pour les futurs appelants!)
• trop de traits de soulignement requis (les constructeurs doivent être appelés __init__)
• manque de membres et de fonctions privés appropriés (la convention dit simplement que la plupart des choses qui commencent par underscore sont privées, sauf pour toutes les choses comme __getattr__ qui ne l'est pas)
• syntaxe drôle pour print ing à un fichier (mais ils corrigent cela en Python 3)

C#

• J'aimerais pouvoir switch() sur n'importe quel type, et que case pourrait être n'importe quelle expression.

• Impossible d'utiliser la syntaxe de l'initialiseur d'objet avec les champs' readonly ' / private set autoprops. Généralement, je veux de l'aide linguistique pour créer des types immuables.

• L'Utilisation de {} pour namespace et classe et méthode et bien/indexeur blocs et multi-blocs d'instruction et initialiseurs de tableau. Faire il est difficile de comprendre où vous êtes quand ils sont éloignés ou non.

• Je déteste écrire (from x in y ... select).Z(). Je ne veux pas avoir à revenir à la syntaxe d'appel de méthode parce que la syntaxe de requête manque quelque chose.

• Je veux un do clause sur la syntaxe de la requête, qui est comme foreach. Mais ce n'est pas vraiment une requête.

J'arrive vraiment ici. Je pense que C# est fantastique, et il est difficile de trouver beaucoup qui est cassé.

PHP

1. aucune fonctionnalité de débogage si vous ne contrôlez pas le serveur, et même alors ils sont un peu nuls
2. la quantité extrême de mauvais code PHP flottant donne à tous les programmeurs PHP un mauvais nom
3. nom de fonction incohérent
4. incapacité d'avoir une variable typée statique si j'en veux une (je suis un grand fan de typage dynamique 90% du temps)
5. REGISTER_GLOBALS est le diable

C (OK, ce n'est pas mon préféré, mais ça n'avait pas encore été fait.)

• syntaxe de la bibliothèque de sockets.
• Pas de surcharge de fonction.
• chaînes de style C.
• dépassement de tampon.
• syntaxe cryptique. Je ne sais pas combien de fois j'ai regardé des trucs comme atoi, giflé mon front, et crié " bien sûr!"

EDIT: je pourrais probablement en trouver plus si j'avais recours à plus de code de bibliothèque (comme je l'ai fait avec les sockets, mais ceux-ci sont particulièrement mauvais), mais je j'avais déjà l'impression de tricher pour avoir choisi C. tant de langues existent seulement pour prendre les bonnes parties de C et remplacer les mauvaises que c'est un peu comme battre un cheval mort.

Common Lisp:

1. Les mots-clés sont souvent trop verbeux.
2. Le support de la Bibliothèque est pitoyable.
3. ne fonctionne pas bien dans les systèmes d'exploitation qui veulent gérer la mémoire plus strictement.
4. n'a pas de bonnes installations pour interagir avec le système d'exploitation.
5. L'installation "loop" n'est pas bien définie,et ne semble pas Lispy.

BrainF*ck

• Votre point culminant est que vous êtes Turing complet ?! Je peux faire plus dans les expressions régulières Perl!

• Manque d'objets. Allez, les gens! C'est comme, bonjour...

• Pas de bibliothèques réseau. Tout ce que je veux, c'est gratter une page Web, mon Dieu.

• Pas de fonctions de classe. Félicitations - vous obtenez de compatir avec vos amis Java.

• Une bande infinie pour le stockage et rien autre. C'est tellement prétentieux que nous pourrions aussi bien écrire Lisp.

JavaScript

1. nombres comme chaînes-les mathématiques peuvent être frustrant quand les nombres sont intpreted comme chaînes. 5 + 2 = 52? Grrr...
2. autorisations-toutes les meilleures choses nécessite l'autorisation de l'utilisateur!
3. mises à jour de l'écran - le navigateur doit être à l'état stable pour mettre à jour l'écran. Il ne semble pas y avoir un moyen de forcer l'écran à se mettre à jour au milieu d'un script.
4. lent - bien que Google Chrome est agréable...
5. différences de navigateur font en utilisant la langue d'un [censuré].

PHP:

• on ne peut jamais être sûr que certaines extensions presque communes sont disponibles sur tous les serveurs web.
• essaie d'être tout à l'avenir ( Goto, fermetures,... )
• de nombreux risques de sécurité pour les utilisateurs inexpérimentés
• plus de surcharge de l'opérateur serait bien
• Tous les pauvres programmeurs qui n'apprennent pas à le faire fonctionner correctement, et lui donnent un mauvais nom

Néanmoins, PHP est le langage (script). ;-)

VB6

1. Windows uniquement.
2. N'est plus pris en charge.
3. les tableaux peuvent commencer à n'importe quel nombre, plutôt que tous étant normalisés à 0.
4. les applications compilées dépendent de nombreuses dll pour fonctionner correctement.
5. de nombreux contrôles compliqués comme un contrôle de navigateur ou des morceaux de code compliqués ont tendance à casser L'IDE lorsque vous exécutez du code non compilé, mais fonctionnent très bien lorsqu'ils sont compilés.

Ruby est ma langue préférée, voici ce que je n'aime pas:

• threads verts + bibliothèques C bloquantes = échec géant
• SI DOULOUREUSEMENT LENT
• la bibliothèque standard elle-même est incompatible avec son utilisation de bang! méthodes
• Module inclure + étendre est désordonné.
• les "Classes ouvertes" ne peuvent pas être étendues - je veux ajouter une chaîne#dostuff, mais je ne veux pas que cela fuit dans toutes les bibliothèques tierces
• Pas de solution d'empaquetage de déploiement binaire.

Delphi:

• IDE est un peu instable.
• L'aperçu du Code est parfois confus.
• le débogage est parfois bogué.
• la mise à jour de plusieurs fichiers de projet peut être lourde.
• Si vous démarrez lorsqu'un ou plusieurs paquets ne sont pas disponibles, Le message d'erreur est affiché plusieurs fois.

JavaScript

• Chaque script est exécuté dans un seul 'espace de noms' global...quelque chose que vous devez surveiller lorsque vous travaillez avec des scripts de différentes sources

• Si une variable est utilisée mais n'a pas été définie auparavant, elle est considérée comme une variable globale

• Les fournisseurs de navigateurs constituent des normes à leur guise, ce qui rend le codage pour les développeurs américains en utilisant un langage aussi beau plus difficile qu'il ne le devrait soit

• Sensibilité à la casse-considérant qu'il n'y a pas D'IDE décent pour développer des js avec une vérification à la compilation

• Solutions de contournement (telles que l'utilisation de la méthode hasOwnProperty) pour effectuer certaines opérations, sinon simples.

Haskell:

1. Les Fuites D'espace de l'évaluation paresseuse.
2. hiérarchie numérique non construite en ce qui concerne les abstractions mathématiques.
3. Les e / s monadiques strictes peuvent rendre le débogage plus difficile.
4. les grandes implémentations gèrent les e/s d'une manière qui ne semble pas tout à fait compatible avec la norme. (En particulier, la sortie de caractères ne génère que les 8 bits faibles - puis le code est construit qui utilise cette hypothèse pour faire des e / s binaires.)
5. Associativité de ($) l'opérateur pourrait être modifié pour rendre certaines expressions plus jolies.

La plupart d'entre eux n'atteignent pas le niveau de la haine, et il y a des gens qui essaient de réparer ou de construire des solutions de contournement solides pour chacun d'eux.

Edit: il y a eu une certaine confusion sur le point 5. En particulier, certaines personnes semblent penser que je voulais dire l'ordre des arguments, ce que je ne sais pas. plutôt que d'expliquer ce que je voulais dire, je vais simplement pointer les gens vers le lien suivant, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , qui l'exprime bien.