Quais são as cinco coisas que você odeia no seu idioma favorito? [fechadas]

Ultimamente, tem havido um grupo de ódio por Perl no Stack Overflow, então pensei em trazer minha pergunta " Cinco coisas que você odeia no seu idioma favorito " para o Stack Overflow. Pegue o seu idioma favorito e me diga cinco coisas que você odeia. Isso pode ser algo que apenas o incomoda, admitiu falhas de design, problemas de desempenho reconhecidos ou qualquer outra categoria. Você só tem que odiar, e tem que ser o seu idioma favorito.

Não compare com outro idioma e não fale sobre idiomas que você já odeia. Não fale sobre o que você gosta no seu idioma favorito. Eu só quero ouvir as coisas que você odeia, mas tolera, para poder usar todas as outras coisas, e quero ouvir sobre o idioma que você gostaria que outras pessoas usassem.

Eu pergunto isso sempre que alguém tenta colocar seu idioma favorito em mim, e às vezes como uma pergunta de entrevista. Se alguém não consegue encontrar cinco coisas para odiar sobre sua ferramenta favorita, ele não a conhece bem o suficiente para advogá-la ou receber grandes quantias em dinheiro usando-a. Ele não o usou em situações diferentes o suficiente para explorá-lo completamente. Ele está defendendo isso como uma cultura ou religião, o que significa que, se eu não escolher sua tecnologia favorita, estou errado.

Eu não me importo muito com qual idioma você usa. Não quer usar um idioma específico? Então não. Você passa pela devida diligência para fazer uma escolha informada e ainda não a usa? Bem. Às vezes, a resposta certa é "Você tem uma equipe de programação forte, com boas práticas e muita experiência em Bar. Mudar para Foo seria estúpido".

Essa é uma boa pergunta para revisões de código também. As pessoas que realmente conhecem uma base de código terão todo o tipo de sugestões e as que não a conhecem tão bem têm queixas inespecíficas. Eu pergunto coisas como "Se você pudesse começar de novo neste projeto, o que faria de diferente?" Nesta área de fantasia, usuários e programadores reclamam de tudo e de tudo que não gostam. "Quero uma interface melhor", "Quero separar o modelo da visualização", "Eu usaria este módulo em vez deste outro", "Renomearia esse conjunto de métodos" ou o que eles realmente não não gosto da situação atual. É assim que eu entendo o quanto um desenvolvedor em particular sabe sobre a base de código. Também é uma pista sobre quanto do programador '

O ódio não é a única dimensão de descobrir o quanto as pessoas sabem, mas eu achei uma boa. As coisas que eles odeiam também me dão uma pista de como eles estão pensando sobre o assunto.

Cinco coisas que eu odeio em Java:

• Não há funções de primeira classe.
• Nenhuma inferência de tipo.
• Falta de padrões saudáveis ​​em gráficos, por exemplo.
• NullPointerException não contém mais informações sobre o que é nulo.
• A proliferação de estruturas inúteis "configuráveis" / interfaces de provedor de serviços / classes de fábrica / sistemas de injeção de dependência. A configurabilidade quase nunca é usada, o DRY é violado de forma flagrante e o código quadruplica em tamanho e metade em legibilidade.

Eu sei, eu deveria dar uma olhada no Scala.

Uau, estou surpreso que o SQL ainda não tenha chegado aqui. Acho que isso significa que ninguém ama :)

• Sintaxe inconsistente nas implementações
• Diferenças sutis de código podem ter implicações enormes no desempenho por razões aparentemente obscuras
• Suporte deficiente para manipulação de texto
• Custo de entrada fácil, mas curva de aprendizado acentuada para dominar o idioma
• Padronização mínima em toda a comunidade para práticas recomendadas, isso inclui estilo de sintaxe.

... E algumas razões bônus para odiá-lo, sem nenhum custo extra

• a cláusula WHERE vai por último, facilitando a execução precoce de um UPDATE ou DELETE, destruindo toda a tabela. Em vez disso, o WHERE deve ir para algum lugar na frente.
• É difícil implementar a divisão relacional.
• Posso definir um valor como NULL, mas não posso testá-lo quanto à igualdade com NULL. Posso verificar IS NULL, mas isso apenas complica o código - desnecessariamente, na minha opinião.
• Por que precisamos re-especificar completamente a fórmula de uma coluna GROUPed, em vez de definir um alias na coluna e, em seguida, GROUP BY o alias (ou índice da coluna como no SORT)?

JavaScript :

1. Todas as coisas mais legais são incrivelmente complexas, mas toda a legalidade também é envolvida em uma quantidade tão pequena de código que você se sente estúpido por ter dificuldades em segui-lo

2. '+' é uma escolha absurda de operador para concatenação em uma linguagem de tipo fraco. Eles estavam tentando assustar os noobs?

3. É um campo minado de compatibilidade entre navegadores (não importa se está ativado ou não)

4. Geralmente não é confiável - associado a escárnio, como bloquear o botão Voltar, pop-ups que nunca morrem etc.

5. É quase impossível depurar, porque existem apenas algumas mensagens de erro diferentes e alguns tipos diferentes (Número, String, Objeto etc.)

Se não fosse pelo jQuery, provavelmente ainda o odeio tanto quanto costumava :)

PHP:

1) Obriga-me a fazer variáveis ​​desnecessárias:

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

2) Uma implementação de lambdas tão ridícula que é aproximadamente equivalente a usar eval()e tão terrivelmente errada que eu nunca a usei (consulte http://www.php.net/create_function ).

3) Um sistema try / catch que pode capturar apenas cerca de 80% dos erros que podem ocorrer.

4) O suporte ao Regex é tão coxo quanto o suporte ao lambda, porque ele precisa ser escrito em cadeias regulares, tornando uma das ferramentas de programação mais difíceis de aprender cerca de três vezes mais difícil. E o PHP deveria ser uma linguagem "fácil"?!?!?

5) Não há como extrair com segurança coisas de $ _POST sem escrever duas vezes ou criar sua própria função ou usar o operador '@':

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

6) Resposta de bônus: '@'. Se você não pode se incomodar em escrever seu código corretamente, basta adicionar '@', o que é ruim para quem precisar depurar seu código posteriormente.

C ++

• É muito fácil corromper aleatoriamente a memória e criar bugs quase impossíveis de encontrar (embora Valgrind se esforce muito para corrigir isso).
• Mensagens de erro do modelo.
• Ao usar modelos, é fácil acabar tendo que incluir tudo em um arquivo e obter tempos de compilação estúpidos.
• A biblioteca padrão é uma piada na era moderna (ainda não há threads ou rede por padrão?)
• Muitos bits desagradáveis ​​de C cutucando (em particular, todas as conversões entre short / int / unsigned / etc.)

C # / .NET:

• As aulas devem ser seladas por padrão
• Não deve haver nenhuma lockinstrução - em vez disso, você deve ter objetos de bloqueio específicos e métodos como os Acquireque retornam tokens de bloqueio descartáveis. Corolário: não deve haver um monitor para cada objeto.
• GetHashCode()e Equals()não deve estar dentro System.Object- nem tudo é adequado para hash. Em vez disso, tem um IdentityComparerque faz a mesma coisa, e manter os IComparer<T>, IComparable<T>, IEqualityComparer<T>e IEquatable<T>as interfaces para comparações personalizados.
• Fraco apoio à imutabilidade
• Maneira ruim de descobrir métodos de extensão - deve ser uma decisão muito mais consciente do que apenas o fato de eu estar usando um espaço para nome.

Aqueles estavam fora do topo da minha cabeça - pergunte-me amanhã e eu vou apresentar outros 5 :)

C

• manipulação de cordas.

Ter que lidar manualmente com os buffers de cadeia de caracteres é um problema propenso a erros. Como muita computação está realmente movendo e modificando seqüências de caracteres (os computadores não são usados ​​tanto para grandes trituradores de números quanto as pessoas pensavam que estariam há muito tempo), é muito bom poder usar linguagens gerenciadas ou a string do C ++ objetos para lidar com isso. Quando eu tenho que fazer isso em linha reta C, parece nadar na areia movediça.

Que tal cinco coisas que eu odeio nas listas "Coisas que eu odeio em algum idioma"? : D

5- Pintar um vermelho laranja não o torna uma maçã.

Quando uma linguagem é projetada, os designers geralmente têm em mente o que é útil. Usá-lo para algo completamente diferente pode funcionar, mas reclamar quando não é apenas burro. Veja o Python. Tenho certeza de que alguém tem ou alguém algum dia criará um utilitário para criar exe's a partir do código Python. Por que diabos você gostaria de fazer isso? Seria legal - não me interpretem mal - mas não adianta. Então pare de reclamar!

Um projeto bem projetado provavelmente conteria código de vários idiomas. Isso não quer dizer que você não pode concluir um projeto com apenas um idioma. Alguns projetos podem estar dentro das habilidades de qualquer idioma que você esteja usando.

4- Você está de pé com pernas de madeira?

A plataforma pode ser uma grande influência do que o idioma pode fazer. Hoje em dia, os coletores de lixo, ou até mesmo as tentativas iniciais de "coleta de lixo", podem ajudar na perda de memória (talvez mais memória RAM?). Os computadores são mais rápidos e, é claro, esperamos mais das nossas línguas. E, francamente, provavelmente deveríamos. No entanto, existe um preço enorme a pagar pela conveniência do compilador de criar tabelas de hash ou seqüências de caracteres ou uma variedade de outros conceitos. Essas coisas podem não ser herdadas da plataforma em que são usadas. Dizer que eles são fáceis de incluir em um idioma apenas me diz que você pode não ter uma perna para se apoiar.

3- Quem é realmente a culpa?

Insetos. Você sabe. Eu amo insetos. Por que eu amo insetos? Porque isso significa que eu consigo manter meu emprego. Sem bugs, haveria muitas pizzarias fechadas. No entanto, os usuários odeiam erros. Mas aqui está um pouco de água fria. Todo bug é culpa dos programadores. Não é o idioma. Uma linguagem com uma sintaxe tão rígida que reduziria significativamente quantos erros eram possíveis de gerar seria uma linguagem completamente inútil. Suas habilidades provavelmente poderiam ser contadas por um lado. Você quer flexibilidade ou poder? Você tem bugs. Por quê? Porque você não é perfeito e comete erros. Veja um exemplo realmente identificável em C:

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

Todos sabemos o que isso vai fazer. No entanto, o que talvez alguns de nós não percebemos é que essa funcionalidade pode ser muito benéfica. Dependendo do que você está fazendo. A saturação de buffer é o custo dessa funcionalidade. Esse código acima. Se eu realmente divulgasse isso ao público. É isso mesmo .. diga comigo .. "Minha culpa". Não C por me permitir fazê-lo.

2- Não devemos colocar isso na lixeira?

É muito fácil apontar para um recurso em um idioma que não entendemos porque não o usamos frequentemente e o chamamos de estúpido. Reclame que está lá etc. Goto sempre me diverte. As pessoas sempre se queixam de estar em um idioma. No entanto, aposto que seu último programa incluiu um tipo de goto. Se você já usou uma pausa ou uma continuação, usou um goto. É isso que é. É verdade que é um jogo "seguro", mas é o que é. Goto tem seus usos. Se gotos "implícitos", como continuar ou interromper, são usados ​​ou gotos explícitos (usando a palavra-chave real "goto" para qualquer idioma). Não que os desenvolvedores de idiomas sejam impecáveis, mas normalmente ... se a funcionalidade existe desde o início dos tempos (para esse idioma). Provavelmente esse aspecto é uma qualidade definidora dessa linguagem. Significado .. é ' está sendo usado e provavelmente não está disponível por causa da compatibilidade com versões anteriores. Está sendo usado hoje. Como em 5 minutos atrás. E usado corretamente. Bem ... indiscutivelmente alguém está usando isso de forma inadequada também, mas isso está relacionado ao # 3 da minha lista.

1. - Tudo é um objeto.

Ok .. este é realmente um subconjunto de # 2. Mas essa é de longe a queixa mais irritante que vejo nas listas de ódio. Nem tudo é um objeto. Existem muitos conceitos que não pertencem ou precisam ser objetos. Colocar coisas onde elas não pertencem é apenas feio e pode diminuir a eficiência de um programa. Certo. Talvez não muito, dependendo do idioma. Isso também se refere ao # 5. Isso significa ... sim. Global estão ok. As funções, ao contrário dos métodos estáticos, estão ok. Combinar programação OO com funções globais está ok. Agora ... isso não significa que todos nós devemos sair e "liberar" nosso código de seus modelos de objetos também. Ao projetar uma seção de código ou um projeto inteiro, o que acontece nos bastidores deveser considerado ao montá-lo. Não apenas onde esse conceito vive e muitos outros fatores. Por que agrupar funções globais dentro de classes ou conceitos de namespace, se não serve para nada? Tome variáveis ​​de membro estáticas. Isso me diverte muito porque ... bem ... Dependendo do idioma e da implementação, é claro, mas de um modo geral, você acabou de declarar global. Sim, existem alguns motivos para agrupar esses conceitos que não são de OO nos wrappers de OO. Um, claro, é o código de auto-documentação. Isso pode fazer sentido. Então .. como eu digo. Não saia e "liberte" seu código. Mas qualquer boa linguagem moderna terá um conceito global fora da modelagem OO. Sim, quero dizer especificamente que uma linguagem de programação OO sem um conceito global provavelmente tem uma falha séria no design. Mais uma vez .. depende da intenção e do design do idioma, então não estou tentando escolher um idioma específico e há muitos para analisar aqui. Seja qual for, considere onde o código deve residir e ser o mais eficaz. Adicionar um monte de reflexos a algo que não adiciona funcionalidade ou suporte apenas desgasta o teclado mais rapidamente. Não faz bem a ninguém. Bem ... a menos que você goste de brownie da pessoa que provavelmente lhe ensinou incorretamente que tudo é um objeto.

Em resumo, a programação não está apenas tocando no teclado sem pensar. Há muitas considerações de design em qualquer projeto. Eu sei que é clichê, mas você tem que olhar de todos os ângulos. Mesmo nos dias de hoje, idiomas com segurança de digitação. Você não apenas explica o código e espera que funcione bem. Claro ... isso pode funcionar, mas pode não ser o caminho certo a seguir. No geral, escolha o idioma e o formato mais adequado para o trabalho específico E o ambiente. Mas nenhuma linguagem tira o pensamento por trás dela. Se você não está pensando ... você está apenas digitando.

Cinco coisas que eu odeio no Java (que atualmente é a minha linguagem favorita) em nenhuma ordem específica.

1. Por mais que eu seja fã do Java Generics, existem muitas curiosidades que surgem da maneira como ele foi projetado. Como tal, existem inúmeras limitações irritantes com genéricos (alguns dos quais são resultado de apagamento de tipo).
2. A maneira como Object.clone () e as interfaces Cloneable funcionam é totalmente interrompida.
3. Em vez de pegar a estrada e transformar tudo em um objeto (a. SmallTalk), a Sun criou duas categorias distintas de tipos de dados: objetos e primitivas. Como resultado, agora existem duas representações para tipos de dados fundamentais e curiosidades estranhas, como boxe / unboxing e não poder colocar primitivas em uma coleção.
4. O balanço é muito complexo. Não me entenda mal: há muitas coisas legais que se pode fazer com o Swing, mas é um ótimo exemplo de excesso de engenharia.
5. Essa reclamação final é igualmente culpa da Sun e daqueles que criaram bibliotecas XML para Java. As bibliotecas Java XML são muito complicadas. Para simplesmente ler um arquivo XML, muitas vezes tenho que me preocupar com o analisador que estou usando: DOM ou SAX? As APIs para cada uma são igualmente confusas. O suporte nativo na linguagem para analisar / gravar facilmente XML seria muito bom.
6. java.util.Date é uma merda. Não é apenas desnecessariamente complicado, mas todos os métodos úteis foram preteridos (e substituídos por outros que aumentam a complexidade).

Ruby tem muitas falhas relacionadas à sua velocidade, mas eu não as odeio. Também tem falhas no evangelismo da comunidade, mas isso realmente não me incomoda. Estes são o que eu odeio:

• Os fechamentos (blocos) têm 4 sintaxes de criação diferentes e nenhuma delas é ideal. A sintaxe elegante é incompleta e ambígua com hashes, e a sintaxe completa é feia.
• A comunidade tende a ser contra a documentação real, favorecendo 'ler o código'. Eu acho isso infantil e preguiçoso.
• O abuso de metaprogramação, principalmente nas bibliotecas, torna os bugs um pesadelo para rastrear.
• Em uma nota relacionada, a metaprogramação abrangente torna um IDE abrangente difícil, se não impossível, de ser feito.

• A maneira como o bloco passa para as funções é tolo. Não há razão para que os blocos sejam passados ​​para fora da lista de parâmetros ou tenham uma sintaxe especial ímpar para acessar (rendimento). Sou da opinião de que os blocos deveriam ter recebido uma sintaxe menos ambígua (ou hashes poderiam ter usado delimitadores diferentes; talvez <> em vez de {}), e a passagem como parâmetros para métodos deveria ter sido exatamente como todos os outros parâmetros.

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

  Essas esquisitices, como o bloco, devem ser o último parâmetro passado e passar mais de um bloco é diferente com sintaxe mais longa, realmente me incomoda.

Perl

• Uso misto de sigilos

  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;
  

  • Por exemplo, nenhum deles é o mesmo:

    $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'
    

  Em Perl6que está escrito :

  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;
  

• Falta de OO verdadeiro

  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'}
  }
  

  Em Perl6que está escrito :

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

• Recursos de regex mal projetados

  /(?=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
  

  Em Perl6que está escrito :

  / <?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
  

• Falta de expedição múltipla

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

  Em Perl6que está escrito :

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

• Má sobrecarga do operador

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

  Em Perl6que está escrito :

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

Eu faço PHP como eu gosto às vezes e Python será feito demais.

• Sem espaço para nome; tudo está em uma espécie de espaço para nome muito grande, o que é um inferno em ambientes maiores

• Falta de padrões quando se trata de funções: funções de matriz usam uma agulha como primeiro argumento, palheiro como segundo (consulte array_search ). As funções de corda geralmente levam o palheiro primeiro, a agulha depois (consulte as notas ). Outras funções usam apenas esquemas de nomeação diferentes: bin2hex , strtolower , cal_to_jd

  Algumas funções têm valores de retorno estranhos, fora do normal: isso força você a ter uma terceira variável declarada do nada, enquanto o PHP pode interpretar com eficiência uma matriz vazia como falsa com seu tipo de malabarismo. Não há outras funções fazendo o mesmo.

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

• A linguagem (até PHP6) faz o possível para respeitar uma compatibilidade com versões anteriores com retardamento quase retardado, fazendo com que ela pratique más práticas e funções quando não for necessária (consulte mysql_escape_string vs. mysql_real_escape_string ).

• O idioma evoluiu de um modelo de modelo para um de back-end completo. Isso significa que qualquer pessoa pode produzir qualquer coisa quando quiser, e isso é abusado. Você acaba com mecanismos de modelo para uma linguagem de modelos ...

• É péssimo na importação de arquivos. Você tem 4 maneiras diferentes de fazê-lo (incluir, incluir_once, exigir, exigir_once), todos eles são lentos, muito lentos. De fato, toda a linguagem é lenta. Pelo menos, muito mais lento que python (mesmo com uma estrutura) e RoR do que eu entendo.

Eu ainda gosto de PHP, no entanto. É a serra elétrica do desenvolvimento da Web: você deseja que um site pequeno a médio seja feito rapidamente e certifique-se de que alguém possa hospedá-lo (embora as configurações possam diferir)? O PHP está aí, e é tão onipresente que leva apenas 5 minutos para instalar uma pilha completa de LAMP ou WAMP. Bem, vou voltar a trabalhar com Python agora ...

Aqui estão algumas coisas que eu não gosto no Java (que não é minha linguagem favorita):

• Eliminação do tipo de genéricos (ou seja, sem genéricos reificados)
• Incapacidade de capturar várias exceções (de tipos diferentes) em um único bloco de captura
• Falta de destruidores (finalize () é um substituto muito ruim)
• Não há suporte para fechamentos ou tratamento de funções como dados (classes internas anônimas são um substituto muito detalhado)
• Exceções verificadas em geral ou mais especificamente, verificando exceções irrecuperáveis ​​(por exemplo, SQLException)
• Não há suporte no nível do idioma para coleções literais
• Nenhuma inferência de tipo quando construtores de classes genéricas são chamados, ou seja, o (s) parâmetro (s) do tipo deve ser repetido nos dois lados do '='

C ++

1. Sintaxe do modelo
2. Problemas de herança de diamantes
3. A infinidade / falta de bibliotecas padrão que as línguas modernas possuem (embora o impulso chegue perto).
4. IOStreams
5. A sintaxe usada nos IOStreams

Pitão

1. Os espaços são significativos (às vezes)
2. palavras-chave sublinhadas
3. Suporte de segmento limitado (pelo menos atualmente)
4. "eu" em vez de "isso"
5. Os espaços são significativos (às vezes)

Objetivo-C

1) Sem espaços para nome, apenas convenções de nomes manuais - não me importo com isso em termos de separação de classes, mas sinto falta de poder importar todas as definições de classe em um espaço para nome em uma única linha (como import com.me.somelibrary. *)

2) As bibliotecas ainda têm alguns buracos em áreas importantes como o suporte ao RegEx.

3) A sintaxe da propriedade é um pouco desajeitada, exigindo três linhas (em dois arquivos separados) para declarar uma propriedade.

4) Gosto do modelo de retenção / liberação, mas é mais fácil do que deveria ser lançar uma referência e depois usá-la acidentalmente mais tarde.

5) Embora não seja realmente um recurso de linguagem, o Xcode está tão entrelaçado com o uso do Objective-C que não consigo deixar de pensar sobre esse aspecto ... basicamente o preenchimento automático é muito duvidoso. É mais como um sistema que recompensa você por encontrar algo que você deseja que exista e depois o apresenta como uma opção posteriormente. Mas acho que nunca gostei de mecanismos de preenchimento automático.

C ++

• Cordas.
  Como eles não são interoperáveis ​​com as strings da plataforma, você acaba usando std :: vector metade do tempo. A política de cópia (cópia em gravação ou cópia profunda) não está definida, portanto, garantias de desempenho não podem ser dadas para sintaxe direta. Às vezes, eles contam com algoritmos STL que não são muito intuitivos de usar. Muitas bibliotecas lançam suas próprias, que infelizmente são muito mais confortáveis ​​de usar. A menos que você precise combiná-los.

• Variedade de representações de strings
  Agora, esse é um problema de plataforma - mas ainda espero que tenha sido melhor quando uma classe de strings padrão menos obstinada estivesse disponível anteriormente. As seguintes representações de seqüência de caracteres que eu uso com freqüência:

  • LPCTSTR genérico,
  • STR LPC (W) alocado por CoTaskMemAlloc,
  • BSTR, _bstr _t
  • w) corda
  • CString,
  • std :: vector
  • uma classe roll-my-own ( suspiro ) que adiciona verificação de intervalo e operações básicas a um buffer (w) char * de comprimento conhecido

• Modelo de construção.
  Estou doente de morte por todo o tempo gasto com declarações de quem inclui o quê, encaminhamento, otimização de cabeçalhos pré-compilados e inclui manter pelo menos tempos de compilação suportáveis, etc. Foi ótimo nos anos 80, mas agora? Existem tantos obstáculos para empacotar um pedaço de código, para que possa ser reutilizado que até o cachorro da mãe fica entediado ao me ouvir.

• Difícil de analisar
  Isso torna as ferramentas externas especialmente difíceis de escrever e acertar. E hoje, nós, C ++, faltam principalmente na cadeia de ferramentas. Eu amo minha reflexão em C # e delegados, mas posso viver sem eles. Sem grande refatoração, não posso.

• A segmentação é muito difícil A
  linguagem nem a reconhece (a essa altura), e as liberdades do compilador - embora grandes - são muito dolorosas.

• Inicialização estática e sob demanda Tecnicamente, eu trapaceio aqui: essa é outra peça do quebra-cabeça no "código de finalização para reutilização": é um pesadelo obter algo inicializado apenas quando necessário. A melhor solução para todos os outros problemas redist é colocar tudo em cabeçalhos, esse problema diz "neeener - você não pode".

É verdade que muito disso está além do escopo estrito da linguagem, mas na IMO toda a cadeia de ferramentas precisa ser julgada e precisa evoluir.

JavaScript :

• O Objectprotótipo pode ser modificado. Cada objeto em seu programa obtém novas propriedades e provavelmente algo quebra.

• Todos os objetos são mapas de hash, mas é difícil usá-los com segurança. Em particular, se uma de suas chaves estiver __proto__, você está com problemas.

• Nenhum fechamento de objeto no tempo de referência da função. De fato, nenhum fechamento de objeto - em vez disso, thisé definido sempre que uma função é chamada com a notação de objeto ou o newoperador. Isso resulta em muita confusão, principalmente ao criar retornos de chamada de eventos, porque thisnão está definido para o que o programador espera.

  • Corolário: chamar uma função sem notação de objeto ou o newoperador resulta em thisser igual ao objeto global, resultando em muita quebra.

• Operador de adição sobrecarregado para também executar concatenação de cadeias, apesar das duas operações serem fundamentalmente diferentes. Isso causa dor quando um valor que você espera ser um número é de fato uma string.

• ==e os !=operadores executam coerção de tipo. Comparações entre diferentes tipos envolvem uma lista de regras que nenhum mortal pode se lembrar por completo. Isso é atenuado pela existência de ===e !==operadores.

• Ambos nulle undefinedexistem, com significados sutilmente diferentes, porém redundantes. Por quê?

• Sintaxe estranha para configurar cadeias de protótipos.

• parseInt(s)espera um número no estilo C, portanto trata valores com zeros à esquerda como octais, etc. Você pode pelo menos, parseInt(s, 10)mas o comportamento padrão é confuso.

• Nenhum escopo de bloco.

• Pode declarar a mesma variável mais de uma vez.

• Pode usar uma variável sem declará-la; nesse caso, é global e provavelmente interrompe seu programa.

• with { }.

• Realmente difícil de documentar com JavaDoc como ferramentas.

Pitão:

• Falta de digitação estática
• Manipulação de argumento padrão (especificamente o fato de que você pode alterar o argumento padrão para futuros chamadores!)
• Muitos sublinhados necessários (os construtores devem ser chamados __init__)
• Falta de membros e funções privadas apropriadas (a convenção apenas diz que a maioria das coisas que começam com sublinhado são privadas, exceto todas as coisas assim __getattr__)
• Sintaxe engraçada para printinserir um arquivo (mas eles estão corrigindo isso no Python 3)

C #

• Eu gostaria de poder switch()de qualquer tipo, e isso casepoderia ser qualquer expressão.

• Não é possível usar a sintaxe do inicializador de objetos com campos 'somente leitura' / private setautopropulsões. Geralmente, quero ajuda de idioma para criar tipos imutáveis.

• Uso de {}para namespace e classe e método e blocos de propriedade / indexador e blocos de várias instruções e inicializadores de matriz . Torna difícil descobrir onde você está quando eles estão distantes ou incompatíveis.

• Eu odeio escrever (from x in y ... select).Z(). Não quero ter que voltar à sintaxe de chamada de método porque a sintaxe da consulta está faltando alguma coisa.

• Eu quero uma docláusula na sintaxe da consulta, que é como foreach. Mas não é realmente uma consulta então.

Estou realmente chegando aqui. Eu acho que o C # é fantástico e é difícil encontrar muito que está quebrado.

PHP

1. Não há recursos de depuração se você não controla o servidor, e mesmo assim eles meio que sugam
2. A quantidade extrema de códigos PHP ruins que circulam por todos os lados dá a todos os programadores de PHP um nome ruim
3. Nomenclatura inconsistente da função
4. Incapacidade de ter uma variável de tipo estático, se eu quiser uma (eu sou um grande fã de digitação dinâmica 90% do tempo)
5. REGISTER_GLOBALS é o diabo

C (OK, não é o meu favorito, mas ainda não foi feito.)

• Sintaxe da biblioteca de soquetes.
• Sem sobrecarga de função.
• Cordas no estilo C.
• Excesso de buffer.
• Sintaxe enigmática. Não sei quantas vezes procurei coisas como atoi, dei um tapa na testa e gritei "Claro!"

Edição: Eu provavelmente poderia ter mais, se eu recorresse a mais código de biblioteca (como fiz com soquetes, mas esses são particularmente ruins), mas eu já sentia que estava trapaceando por escolher C. Muitos idiomas existem apenas para usar as partes boas de C e substituir as ruins que é como bater em um cavalo morto.

Lisp comum:

1. Palavras-chave geralmente são muito prolixo.
2. O suporte da biblioteca é lamentável.
3. Não funciona bem em sistemas operacionais que desejam lidar com a memória com mais rigor.
4. Não possui boas instalações para interagir com o sistema operacional.
5. O recurso "loop" não está bem definido e com certeza não parece Lispy.

BrainF * ck

• Seu destaque é que você é Turing completo ?! Eu posso fazer mais em expressões regulares do Perl!

• Falta de objetos. Vamos lá pessoal! É como, olá ...

• Nenhuma biblioteca de rede. Tudo o que eu quero é raspar uma página da web, GOSH.

• Não há funções de primeira classe. Parabéns - você começa a se solidarizar com seus amigos de Java.

• Uma fita infinita para armazenamento e nada mais. Isso é tão pretensioso que podemos escrever Lisp.

Javascript

1. números como strings - a matemática pode ser frustrante quando os números são interpretados como strings. 5 + 2 = 52? Grrr ...
2. permissões - todas as melhores coisas requerem permissão do usuário!
3. atualizações da tela - O navegador deve estar no estado estacionário para atualizar a tela. Não parece haver uma maneira de forçar a atualização da tela no meio de um script.
4. Lento - embora o Google Chrome seja legal ...
5. As diferenças no navegador tornam o uso do idioma um [censurado].

PHP:

• Nunca se pode ter certeza de que certas extensões quase comuns estão disponíveis em todos os servidores da web.
• tenta ser tudo no futuro (ir, fechamentos, ...)
• muitos riscos de segurança para usuários inexperientes
• mais sobrecarga do operador seria bom
• todos os programadores pobres que não aprendem a fazê-lo funcionar corretamente e lhe dão um nome ruim

No entanto, o PHP é a linguagem (de script). ;-)

VB6

1. Apenas Windows.
2. Não mais suportado.
3. As matrizes podem começar com qualquer número, em vez de serem normalizadas para 0.
4. aplicativos compilados dependem de muitas DLLs para serem executadas corretamente.
5. Muitos controles complicados, como o controle de um navegador ou partes complicadas de código, tendem a interromper o IDE quando você executa o código não compilado, mas funciona bem quando compilado.

Ruby é meu idioma favorito, eis o que eu não gosto:

• Threads verdes + bloqueio de bibliotecas C = falha gigante
• TÃO DORAMENTE LENTO
• A própria biblioteca padrão é inconsistente com o uso do bang! métodos
• O módulo include + extend está bagunçado.
• "Classes abertas" não podem ter escopo definido. Quero adicionar uma string # dostuff, mas não quero que isso vaze para todas as bibliotecas de terceiros
• Nenhuma solução de empacotamento de implantação binária.

Delphi:

• O IDE é um pouco instável.
• O insight do código às vezes é confuso.
• Às vezes, a depuração é incorreta.
• Atualizar vários arquivos de projeto pode ser complicado.
• Se você iniciar um ou mais pacotes indisponíveis, a mensagem de erro será exibida várias vezes.

Javascript

• Todo script é executado em um único 'namespace' global ... algo que você precisa observar ao trabalhar com scripts de diferentes fontes

• Se uma variável é usada, mas ainda não foi definida de antemão, ela é considerada uma variável global

• Os fornecedores de navegadores criam os padrões como desejarem, tornando a codificação para nós desenvolvedores que usamos uma linguagem tão bonita mais difícil do que deveria

• Case-Sensitivity - considerando que não existe um IDE decente para o desenvolvimento de js com verificação em tempo de compilação

• Soluções alternativas (como o uso do hasOwnPropertymétodo) para executar algumas operações simples.

Haskell:

1. Vazamentos de espaço na avaliação preguiçosa.
2. Hierarquia numérica não construída em relação a abstrações matemáticas.
3. O IO monádico estrito pode dificultar a depuração.
4. As grandes implementações lidam com E / S de maneiras que não parecem totalmente compatíveis com o padrão. (Em particular, a saída de caracteres gera apenas 8 bits baixos - e, em seguida, é criado o código que usa essa suposição para executar E / S binária. Ick.)
5. A associatividade do ($)operador pode ser alterada para tornar algumas expressões mais bonitas.

A maioria delas não chega ao nível de ódio, e há pessoas tentando consertar ou construir soluções sólidas para cada uma delas.

Edit: Houve alguma confusão sobre o ponto 5. Em particular, algumas pessoas parecem pensar que eu quis dizer a ordem dos argumentos, o que não quero. Em vez de explicar o que eu quis dizer, vou apontar as pessoas para o seguinte link, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , que o expressa bem.