Quali sono le cinque cose che odi della tua lingua preferita? [chiuso]

Ultimamente c'è stato un gruppo di perl-odio su Stack Overflow, quindi ho pensato di portare la mia domanda " Cinque cose che odi della tua lingua preferita " a Stack Overflow. Prendi la tua lingua preferita e dimmi cinque cose che odi di essa. Queste potrebbero essere cose che ti infastidiscono, hanno ammesso difetti di progettazione, problemi di prestazioni riconosciuti o qualsiasi altra categoria. Devi solo odiarlo e deve essere la tua lingua preferita.

Non confrontarlo con un'altra lingua e non parlare di lingue che odi già. Non parlare delle cose che ti piacciono nella tua lingua preferita. Voglio solo sentire le cose che odi, ma tollero in modo da poter usare tutte le altre cose, e voglio ascoltarle sulla lingua che avresti voluto che altre persone usassero.

Lo chiedo ogni volta che qualcuno cerca di spingere la mia lingua preferita su di me, e talvolta come una domanda di intervista. Se qualcuno non riesce a trovare cinque cose da odiare per il suo strumento preferito, non lo conosce abbastanza bene né per sostenerlo né per ottenere i grandi dollari che lo usano. Non l'ha usato in abbastanza situazioni diverse per esplorarlo completamente. Lo sta sostenendo come cultura o religione, il che significa che se non scelgo la sua tecnologia preferita, mi sbaglio.

Non mi interessa molto quale lingua usi. Non vuoi usare una lingua particolare? Allora no. Passi la dovuta diligenza per fare una scelta informata e ancora non la usi? Belle. A volte la risposta giusta è "Hai un forte team di programmazione con buone pratiche e molta esperienza in Bar. Passare a Foo sarebbe stupido".

Questa è una buona domanda anche per le revisioni del codice. Le persone che conoscono davvero una base di codice avranno tutti i tipi di suggerimenti per esso, e coloro che non lo conoscono così bene hanno lamentele non specifiche. Chiedo cose del tipo "Se potessi ricominciare da capo in questo progetto, cosa faresti diversamente?" In questa terra fantastica, gli utenti e i programmatori possono lamentarsi di tutto ciò che non gli piace. "Voglio un'interfaccia migliore", "Voglio separare il modello dalla vista", "Userei questo modulo invece di questo altro", "Rinominerei questo insieme di metodi", o qualunque cosa essi realmente donino mi piace la situazione attuale. Ecco come ottengo un controllo su quanto un particolare sviluppatore sa della base di codice. È anche un indizio su quanto del programmatore '

L'odio non è l'unica dimensione di capire quante persone sanno, ma l'ho trovato abbastanza buono. Le cose che odiano mi danno anche un'idea di quanto bene stiano pensando all'argomento.

Cinque cose che odio di Java:

• Nessuna funzione di prima classe.
• Nessuna deduzione di tipo.
• Mancanza di impostazioni predefinite corrette, ad esempio nella grafica.
• NullPointerException non contiene più informazioni su ciò che è null.
• La proliferazione di framework / interfacce di provider di servizi / sistemi di iniezione di dipendenza inutilmente configurabili. La configurabilità non viene quasi mai utilizzata, DRY viene violato egregiamente e il codice quadruplica per dimensioni e dimezza per leggibilità.

Lo so, dovrei dare un'occhiata a Scala.

Wow, sono sorpreso che SQL non sia ancora arrivato qui. Suppongo significhi che nessuno lo adora :)

• Sintassi incoerente tra le implementazioni
• Sottili differenze di codice possono avere enormi conseguenze sulle prestazioni per ragioni apparentemente oscure
• Scarso supporto per la manipolazione del testo
• Costo di ingresso facile ma curva di apprendimento ripida verso la padronanza della lingua
• Standardizzazione minima in tutta la comunità per le migliori pratiche, questo include lo stile di sintassi.

... E qualche motivo in più per odiarlo, senza costi aggiuntivi

• la clausola WHERE va per ultima, facilitando l'esecuzione prematura di un UPDATE o DELETE, distruggendo l'intero tavolo. Invece, il WHERE dovrebbe andare da qualche parte in primo piano.
• È difficile implementare la divisione relazionale.
• Posso impostare un valore su NULL, ma non riesco a verificarne l'uguaglianza con NULL. Posso controllare IS NULL, ma questo complica semplicemente il codice - inutilmente, secondo me.
• Perché è necessario rispecificare completamente la formula per una colonna GROUPed, anziché impostare un alias sulla colonna e quindi GROUP BY l'alias (o l'indice di colonna come con SORT)?

JavaScript :

1. Tutte le cose più interessanti sono follemente complesse, ma poi, tutto il bello è anche racchiuso in una così piccola quantità di codice che ti senti stupido per aver difficoltà a seguirlo

2. '+' è una scelta assurda di operatore per la concatenazione in un linguaggio debolmente tipizzato. Stavano cercando di spaventare i rumori?

3. È un campo minato di compatibilità tra browser (non importa se è acceso o meno)

4. In genere non è attendibile, associato a sporcizia come il blocco del pulsante Indietro, i popup che non muoiono mai, ecc.

5. È quasi impossibile eseguire il debug perché ci sono solo pochi messaggi di errore diversi e alcuni tipi diversi (Numero, Stringa, Oggetto, ecc.)

Se non fosse per jQuery, probabilmente lo odierei ancora come un tempo :)

PHP:

1) Mi obbliga a creare variabili non necessarie:

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

2) Un'implementazione di lambda così scadente è all'incirca equivalente all'utilizzo eval()e così terribilmente sbagliato che non l'ho mai usato (vedi http://www.php.net/create_function ).

3) Un sistema try / catch in grado di rilevare solo circa l'80% degli errori che potrebbero verificarsi.

4) Il supporto Regex è altrettanto debole del supporto lambda perché deve essere scritto all'interno di stringhe regolari, rendendo uno degli strumenti di programmazione più difficili da imparare circa tre volte più difficile. E PHP dovrebbe essere un linguaggio "facile"?!?!?

5) Non c'è modo di estrarre in sicurezza cose da $ _POST senza scriverle due volte o creare la propria funzione o utilizzare l'operatore "@":

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

6) Risposta bonus: '@'. Se non ti da fastidio scrivere il tuo codice correttamente, aggiungi semplicemente "@", e peccato per chiunque debba eseguire il debug del codice in un secondo momento.

C ++

• Troppo facile per corrompere casualmente la memoria e creare bug quasi impossibili da trovare (anche se, Valgrind fa molto per risolvere questo problema).
• Messaggi di errore del modello.
• Quando si utilizzano i modelli è facile finire per includere tutto in un unico file e quindi ottenere tempi di compilazione stupidi.
• La libreria standard è una barzelletta nell'era moderna (ancora nessun thread o rete di default?)
• Un sacco di brutte piccole porzioni di C che passano attraverso (in particolare, tutte le conversioni tra short / int / unsigned / etc ..)

C # / .NET:

• Le classi dovrebbero essere sigillate per impostazione predefinita
• Non ci dovrebbero essere lockdichiarazioni - invece, dovresti avere oggetti di blocco specifici e dovrebbero esserci metodi come quelli Acquireche restituiscono token di blocco usa e getta. Corollario: non dovrebbe esserci un monitor per ogni oggetto.
• GetHashCode()e Equals()non dovrebbe esserci System.Object- non tutto è adatto all'hashish. Invece, hanno un IdentityComparerche fa la stessa cosa, e mantenere il IComparer<T>, IComparable<T>, IEqualityComparer<T>eIEquatable<T> le interfacce per i confronti personalizzati.
• Scarso supporto per l'immutabilità
• Povero modo di scoprire metodi di estensione - dovrebbe essere una decisione molto più consapevole del semplice fatto che sto usando uno spazio dei nomi.

Quelli erano in cima alla mia testa - chiedimi domani e ne uscirò con un altro 5 :)

C

• manipolazione di stringhe.

Dover gestire manualmente i buffer di stringa è un problema soggetto a errori. Dal momento che così tante risorse informatiche si stanno realmente spostando e modificando le stringhe (i computer non sono usati tanto per roba da scricchiolii di numeri come la gente pensava che sarebbero tornati indietro nel tempo), è davvero bello poter usare i linguaggi gestiti o la stringa di C ++ oggetti da affrontare con questi. Quando devo farlo direttamente in C, mi sembra di nuotare nelle sabbie mobili.

Che ne dici di cinque cose che odio degli elenchi "Cose che odio di una lingua"? : D

5- Dipingere un rosso arancio non lo rende una mela.

Quando viene progettato un linguaggio, i progettisti in genere hanno in mente a cosa serve. Usarlo per qualcosa di completamente diverso può funzionare, ma lamentarsi quando non lo è è semplicemente stupido. Prendi Python. Sono sicuro che qualcuno ha o qualcuno un giorno farà un'utilità per creare exe dal codice Python. Perché sulla terra di Dio vorresti farlo? Sarebbe pulito, non fraintendetemi, ma non serve. Quindi smettila di lamentarti!

Un progetto ben progettato conterrebbe probabilmente codice da più lingue. Questo non vuol dire che non puoi completare un progetto con una sola lingua. Alcuni progetti potrebbero rientrare nelle capacità di qualunque lingua tu stia usando.

4- Stai in piedi su gambe di legno?

La piattaforma può avere una grande influenza su ciò che la lingua può fare. Con oggigiorno i garbage collector, o anche i primi tentativi di Pascal di "garbage collection", possono aiutare a svanire la memoria (forse malloc più ram ??). I computer sono più veloci e quindi ovviamente ci aspettiamo di più dalle nostre lingue. E francamente, probabilmente dovremmo. Tuttavia, c'è un prezzo enorme da pagare per la comodità del compilatore di creare tabelle hash o stringhe o una varietà di altri concetti. Queste cose potrebbero non essere ereditate dalla piattaforma di cui sono utilizzate. Dire che sono facili da includere in una lingua mi dice che potresti non avere una gamba su cui stare.

3- Chi è la colpa è davvero?

Bugs. Sai. Adoro i bug. Perché amo i bug. Perché significa che riesco a mantenere il mio lavoro. Senza bug, ci sarebbero molte pizzerie chiuse. Tuttavia, gli utenti odiano i bug. Ma ecco un po 'di acqua fredda. Ogni errore è colpa dei programmatori. Non la lingua. Un linguaggio con una sintassi così rigorosa che ridurrebbe in modo significativo il numero di bug che è stato possibile generare sarebbe un linguaggio completamente inutile. Le sue abilità potrebbero probabilmente essere contate da un lato. Vuoi flessibilità o potenza? Hai dei bug. Perché? Perché non sei perfetto e commetti errori. Prendi un esempio davvero identificabile in C:

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

Sappiamo tutti cosa sta per fare. Tuttavia, ciò che forse alcuni di noi non capiscono è che la funzionalità può essere molto utile. A seconda di cosa stai facendo. I sovraccarichi del buffer sono il costo di tale funzionalità. Quel codice sopra. Se lo avessi effettivamente rilasciato al pubblico. Questo è ancora .. dillo con me .. "Colpa mia". Non C per avermi permesso di farlo.

2- Non dovremmo metterlo nel cestino?

È molto facile indicare una caratteristica in una lingua che non capiamo perché non la usiamo spesso e la chiamiamo stupida. Lamentati che è lì, ecc. Goto mi intrattiene sempre. Le persone si lamentano sempre del fatto che Goto sia in una lingua. Eppure scommetto che il tuo ultimo programma includeva un tipo di goto. Se hai mai usato una pausa o un proseguimento, hai usato un goto. Questo è quello che è. Certo, è un goto "sicuro", ma è quello che è. I Goto hanno i loro usi. Se vengono usati goto "impliciti" come continue o break o goto espliciti (usando la parola chiave "goto" per qualsiasi lingua). Non che gli sviluppatori di lingue siano impeccabili, ma in genere ... se la funzionalità esiste dagli albori dei tempi (per quella lingua). Probabilmente quell'aspetto è una qualità distintiva di quella lingua. Significato .. è ' s viene utilizzato e probabilmente non è in giro a causa della compatibilità con le versioni precedenti. Viene utilizzato oggi. Come 5 minuti fa. E usato correttamente. Beh ... probabilmente qualcuno lo sta usando anche in modo improprio, ma questo si riferisce al n. 3 della mia lista.

1. - Tutto è un oggetto.

Ok .. questo è davvero un sottoinsieme di # 2. Ma questa è di gran lunga la lamentela più fastidiosa che vedo negli elenchi di odio. Non tutto è un oggetto. Esistono molti concetti che non appartengono o non devono essere oggetti. Mettere le cose a cui non appartengono è semplicemente brutto e può ridurre l'efficienza di un programma. Sicuro. Forse non molto a seconda della lingua. Questo si riferisce anche al n. 5. Questo significa ... si. I globali sono ok. Le funzioni associate ai metodi statici sono ok. Combinare la programmazione OO con funzioni globali è ok. Ora ... questo non significa che dovremmo uscire tutti e "liberare" il nostro codice dai suoi modelli di oggetti. Quando si progetta una sezione di codice o un intero progetto, cosa succede dietro le quinte dovrebbeessere preso in considerazione quando lo si mette insieme. Non solo dove vive quel concetto e molti altri fattori. Perché avvolgere le funzioni globali all'interno di classi o concetti di spazio dei nomi se non serve a nulla? Prendi variabili membro statiche. Questo mi diverte molto perché ... beh ... A seconda del linguaggio e dell'attuazione ovviamente, ma in generale, hai appena dichiarato un globale. Sì, ci sono alcuni motivi per avvolgere questi concetti non OO nei wrapper OO. Uno ovviamente è il codice auto-documentante. Questo può avere senso. Quindi .. come ho detto. Non uscire e "liberare" il tuo codice. Ma qualsiasi buon linguaggio moderno avrà un concetto globale al di fuori della sua modellazione OO. Sì, intendo specificamente sottolineare che un linguaggio di programmazione OO senza un concetto globale molto probabilmente ha un grave difetto di progettazione. Ancora però .. dipende dall'intenzione e dal design della lingua, quindi non sto cercando di scegliere una lingua specifica e ce ne sono troppe da analizzare proprio qui. Comunque, considera dove dovrebbe vivere il codice ed essere il più efficace. L'aggiunta di un sacco di bagliori a qualcosa che non aggiunge funzionalità o supporto semplicemente consuma la tastiera più velocemente. Non fa bene a nessuno. Beh ... a meno che non ti piacciano i punti brownie della persona che probabilmente ti ha insegnato erroneamente che tutto è un oggetto.

In breve, la programmazione non è solo toccando senza pensarci sulla tastiera. Ci sono molte considerazioni di progettazione in ogni progetto. So che è un cliché, ma devi guardarlo da ogni angolazione. Anche al giorno d'oggi linguaggi sicuri per i tipi. Non devi semplicemente scartare il codice e ti aspetti che funzioni bene. Certo .. potrebbe funzionare, ma potrebbe non essere il modo giusto di procedere. Nel complesso, scegli la lingua e il formato più adatti per il lavoro specifico E l'ambiente. Ma nessuna lingua toglie il pensiero dietro di essa. Se non stai pensando .. stai solo scrivendo.

Cinque cose che odio di Java (che, al momento, è la mia lingua preferita) in nessun ordine particolare.

1. Per quanto io sia un fan di Java Generics, ci sono molte stranezze che derivano dal modo in cui è stato progettato. Come tale c'è una miriade di fastidiosi limiti con i generici (alcuni dei quali sono il risultato della cancellazione del tipo).
2. Il modo in cui funzionano le interfacce Object.clone () e Cloneable è totalmente rotto.
3. Invece di prendere la strada maestra e trasformare tutto in un oggetto (a.la. SmallTalk), Sun ha eliminato due categorie distinte di tipi di dati: oggetti e primitive. Di conseguenza ora ci sono due rappresentazioni per tipi di dati fondamentali e curiosità strane come boxe / unboxing e non essere in grado di mettere le primitive in una raccolta.
4. L'altalena è troppo complessa. Non fraintendetemi: ci sono molte cose interessanti che si possono fare con Swing ma è un ottimo esempio di ingegneria eccessiva.
5. Questa lamentela finale è ugualmente colpa di Sun e di coloro che hanno scritto librerie XML per Java. Le librerie XML Java sono troppo complicate. Per leggere semplicemente in un file XML, spesso devo preoccuparmi di quale parser sto usando: DOM o SAX? Le API per ognuna sono ugualmente confuse. Il supporto nativo nel linguaggio per analizzare / scrivere facilmente XML sarebbe molto bello.
6. java.util.Date fa schifo. Non solo è inutilmente complicato, ma tutti i metodi utili sono stati deprecati (e sostituiti con altri che aumentano la complessità).

Ruby ha molti difetti legati alla sua velocità, ma non li odio. Ha anche difetti nell'evangelizzazione della comunità che va in mare, ma questo non mi disturba davvero. Questi sono ciò che odio:

• Le chiusure (blocchi) hanno 4 diverse sintassi di creazione e nessuna di esse è ottimale. La sintassi elegante è incompleta e ambigua con gli hash e la sintassi completa è brutta.
• La comunità tende a essere contraria alla vera documentazione, favorendo "leggere il codice". Lo trovo infantile e pigro.
• L'abuso di metaprogrammazione, in particolare nelle biblioteche, rende i bug un incubo da rintracciare.
• Su una nota correlata, la metaprogrammazione pervasiva rende difficile, se non impossibile, un IDE completo.

• Il modo in cui il blocco passa alle funzioni è sciocco. Non vi è alcun motivo per cui i blocchi debbano essere passati al di fuori dell'elenco dei parametri o avere una sintassi speciale dispari per l'accesso (rendimento). Sono dell'opinione che i blocchi avrebbero dovuto avere una sintassi meno ambigua (o che gli hash avrebbero potuto usare delimitatori diversi; forse <> anziché {}), e passare come parametri ai metodi avrebbe dovuto essere proprio come tutti gli altri parametri.

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

  Queste stranezze, come il blocco, devono essere l'ultimo parametro passato e il passaggio di più di un blocco è diverso con una sintassi più lunga, mi infastidisce davvero.

Perl

• Uso misto di sigilli

  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;
  

  • Ad esempio nessuno di questi è uguale:

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

  In Perl6esso è scritto :

  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;
  

• Mancanza di vero 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'}
  }
  

  In Perl6esso è scritto :

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

• Funzionalità regex mal progettate

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

  In Perl6esso è scritto :

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

• Mancanza di spedizione multipla

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

  In Perl6esso è scritto :

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

• Scarso operatore sovraccarico

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

  In Perl6esso è scritto :

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

Farò PHP come mi piace a volte e Python sarà fatto troppo.

• Nessuno spazio dei nomi; tutto è in una sorta di spazio dei nomi molto grande che è l'inferno in ambienti più grandi

• Mancanza di standard quando si tratta di funzioni: le funzioni di array prendono un ago come primo argomento, il pagliaio come secondo (vedi array_search ). Le funzioni di stringa spesso prendono prima il pagliaio, poi l'ago (vedi strpos ). Altre funzioni usano solo diversi schemi di denominazione: bin2hex , strtolower , cal_to_jd

  Alcune funzioni hanno strani valori di ritorno, al di fuori di ciò che è normale: questo ti obbliga a far dichiarare dal nulla una terza variabile mentre PHP potrebbe interpretare in modo efficiente un array vuoto come falso con il suo tipo di giocoleria. Non ci sono quasi altre funzioni che fanno lo stesso.

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

• Il linguaggio (fino a PHP6) fa del suo meglio per rispettare una compatibilità all'indietro quasi ritardata, facendogli trasportare cattive pratiche e funzioni quando non necessarie (vedi mysql_escape_string vs. mysql_real_escape_string ).

• La lingua si è evoluta da una lingua modello a una full-backend. Ciò significa che chiunque può produrre qualsiasi cosa voglia e viene abusato. Finisci con i template engine per un linguaggio di template ...

• Fa schifo durante l'importazione di file. Hai 4 modi diversi per farlo (include, include_once, request, require_once), sono tutti lenti, molto lenti. In effetti l'intera lingua è lenta. Almeno, più lentamente di Python (anche con un framework) e RoR da quello che raccolgo.

Mi piace comunque PHP. È la motosega dello sviluppo web: vuoi che un sito di piccole e medie dimensioni venga eseguito molto velocemente e sei sicuro che chiunque possa ospitarlo (anche se le configurazioni possono differire)? PHP è proprio lì ed è così onnipresente che bastano solo 5 minuti per installare uno stack LAMP o WAMP completo. Bene, ora torno a lavorare con Python ...

Ecco alcune cose che non mi piacciono di Java (che non è la mia lingua preferita):

• Cancellazione del tipo di farmaci generici (ovvero non farmaci generici reificati)
• Incapacità di rilevare più eccezioni (di diverso tipo) in un singolo blocco di cattura
• Mancanza di distruttori (finalize () è un sostituto molto scarso)
• Nessun supporto per chiusure o trattamento di funzioni come dati (le classi interne anonime sono un sostituto molto dettagliato)
• Eccezioni verificate in generale, o più specificamente, verifica delle eccezioni irrecuperabili (ad es. SQLException)
• Nessun supporto a livello di lingua per le raccolte letterali
• Nessuna deduzione di tipo quando vengono chiamati costruttori di classi generiche, ovvero i parametri di tipo devono essere ripetuti su entrambi i lati di '='

C ++

1. Sintassi del modello
2. Problemi di ereditarietà del diamante
3. La pletora / mancanza di librerie standard dei linguaggi moderni (anche se la spinta si avvicina).
4. iostreams
5. La sintassi utilizzata attorno a IOStreams

Pitone

1. Gli spazi sono significativi (a volte)
2. parole chiave sottolineate
3. Supporto thread limitato (almeno attualmente)
4. "sé" invece di "questo"
5. Gli spazi sono significativi (a volte)

Objective-C

1) Nessuno spazio dei nomi, solo convenzioni di denominazione manuali - non mi dispiace per quanto riguarda la separazione delle classi, ma mi manca la possibilità di importare tutte le definizioni delle classi in uno spazio dei nomi in una sola riga (come import com.me.somelibrary. *).

2) Le librerie presentano ancora alcuni buchi in aree importanti come il supporto RegEx.

3) La sintassi della proprietà è un po 'goffa e richiede tre righe (in due file separati) per dichiarare una proprietà.

4) Mi piace il modello di conservazione / rilascio, ma è più facile di quanto dovrebbe essere di rilasciare un riferimento e poi utilizzarlo accidentalmente in un secondo momento.

5) Sebbene non sia realmente una funzione del linguaggio, Xcode è così intrecciato con l'uso di Objective-C che non posso fare a meno di pensare a quell'aspetto ... fondamentalmente il completamento automatico, è molto incerto. È più simile a un sistema che ti premia per aver trovato qualcosa che desideri esiste, e poi lo presenta come una scelta in seguito. Ma poi suppongo che non mi siano mai piaciuti i motori di completamento automatico.

C ++

• Stringhe.
  Non sono interoperabili con le stringhe della piattaforma, quindi finisci per usare std :: vector metà del tempo. La politica di copia (copia su scrittura o copia profonda) non è definita, quindi non è possibile fornire garanzie di prestazione per una sintassi semplice. A volte si basano su algoritmi STL che non sono molto intuitivi da usare. Ci sono troppe librerie che sfortunatamente sono molto più comode da usare. A meno che tu non debba combinarli.

• Varietà di rappresentazioni di stringhe
  Ora, questo è un po 'un problema di piattaforma - ma spero ancora che sarebbe stato meglio quando una classe di stringhe standard meno ostinata sarebbe stata disponibile in precedenza. Le seguenti rappresentazioni di stringa che utilizzo frequentemente:

  • LPCTSTR generico,
  • LPC (W) STR assegnato da CoTaskMemAlloc,
  • BSTR, _bstr _t
  • (W) della stringa,
  • CString,
  • std :: vector
  • una classe roll-my-own ( sospiro ) che aggiunge il controllo dell'intervallo e le operazioni di base a un buffer (w) char * di lunghezza nota

• Costruisci modello.
  Sono stufo di tutto il tempo trascorso a confondere con chi-include-cosa, dichiarazioni in avanti, ottimizzazione delle intestazioni precompilate e include per mantenere sopportabili almeno i tempi di costruzione incrementali, ecc. È stato fantastico negli anni Ottanta, ma ora? Ci sono così tanti ostacoli per impacchettare un pezzo di codice in modo che possa essere riutilizzato che anche il cane della mamma si annoi ad ascoltarmi.

• Difficile da analizzare
  Ciò rende gli strumenti esterni particolarmente difficili da scrivere e da ottenere. E oggi, noi ragazzi del C ++ manchiamo principalmente nella catena degli strumenti. Adoro la mia riflessione su C # e i delegati, ma posso vivere senza di loro. Senza un grande refactoring, non posso.

• Il threading è troppo difficile Il
  linguaggio non lo riconosce nemmeno (ormai), e le libertà del compilatore - sebbene grandi - sono dolorose.

• Inizializzazione statica e su richiesta Tecnicamente, baro qui: questo è un altro pezzo del puzzle nel "codice di riepilogo da riutilizzare": è un incubo ottenere qualcosa di inizializzato solo quando è necessario. La migliore soluzione a tutti gli altri problemi di redist sta gettando tutto nelle intestazioni, questo problema dice "Neeener - non puoi".

Certo, gran parte di questo va oltre lo stretto ambito linguistico, ma l'IMO deve essere giudicata l'intera catena di strumenti e deve evolversi.

JavaScript :

• Il Objectprototipo può essere modificato. Ogni singolo oggetto nel tuo programma ottiene nuove proprietà e probabilmente qualcosa si rompe.

• Tutti gli oggetti sono mappe hash, ma è difficile utilizzarli in modo sicuro come tali. In particolare, se una delle tue chiavi risulta essere __proto__, sei nei guai.

• Nessuna chiusura dell'oggetto al momento del riferimento della funzione. In effetti, nessuna chiusura degli oggetti - viene invece thisimpostata ogni volta che viene chiamata una funzione con notazione oggetto o newoperatore. Risulta molto confuso, in particolare durante la creazione di callback di eventi, perché thisnon è impostato su ciò che il programmatore si aspetta.

  • Corollario: la chiamata di una funzione senza notazione oggetto o l' newoperatore comporta thisl'impostazione di un oggetto uguale all'oggetto globale, con conseguente rottura.

• Operatore di aggiunta sovraccarico per eseguire anche la concatenazione di stringhe, nonostante le due operazioni siano sostanzialmente diverse. Provoca dolore quando un valore che prevedi sia un numero è in realtà una stringa.

• ==e gli !=operatori eseguono la coercizione del tipo. Il confronto tra diversi tipi implica un elenco di regole che nessun mortale può ricordare per intero. Ciò è mitigato dall'esistenza di ===e !==operatori.

• Entrambi nulled undefinedesistono, con significati leggermente diversi, ma ridondanti. Perché?

• Strana sintassi per impostare catene di prototipi.

• parseInt(s)si aspetta un numero in stile C, quindi considera i valori con zeri iniziali come ottali, ecc. Puoi almeno parseInt(s, 10)ma il comportamento predefinito è confuso.

• Nessun ambito di blocco.

• Può dichiarare la stessa variabile più di una volta.

• Può usare una variabile senza dichiararla, nel qual caso è globale e probabilmente rompe il programma.

• with { }.

• Davvero difficile documentare con strumenti come JavaDoc.

Pitone:

• Mancanza di digitazione statica
• Gestione degli argomenti predefiniti (in particolare il fatto che è possibile modificare l'argomento predefinito per i futuri chiamanti!)
• Troppi caratteri di sottolineatura richiesti (è necessario chiamare i costruttori __init__ )
• Mancanza di membri e funzioni private appropriate (la convenzione dice solo che la maggior parte delle cose che iniziano con il trattino basso sono private, ad eccezione di tutte le cose come __getattr__ ciò che non lo è)
• Sintassi divertente per printing su un file (ma lo stanno risolvendo in Python 3)

C #

• Vorrei poterlo usare switch()su qualsiasi tipo, e questa casepotrebbe essere qualsiasi espressione.

• Impossibile utilizzare la sintassi dell'inizializzatore di oggetti con campi ' private setreadonly ' / autoprops. In genere, voglio un aiuto linguistico per creare tipi immutabili.

• Uso di {}per namespace e di classe e metodo e proprietà / blocchi indicizzatore e blocchi con più istruzioni e inizializzatori di array . Rende difficile capire dove ti trovi quando sono distanti o non corrispondenti.

• Odio scrivere (from x in y ... select).Z(). Non voglio tornare alla sintassi della chiamata del metodo perché nella sintassi della query manca qualcosa.

• Voglio una doclausola sulla sintassi della query, che è come foreach. Ma non è davvero una domanda allora.

Sto davvero raggiungendo qui. Penso che C # sia fantastico, ed è difficile trovare molto che non funziona.

PHP

1. Nessuna funzionalità di debug se non controlli il server e anche in questo caso fanno schifo
2. L'estrema quantità di codice PHP errato che fluttua intorno dà a tutti i programmatori PHP un nome negativo
3. Denominazione di funzioni incoerente
4. Incapacità di avere una variabile tipizzata statica se ne voglio una (sono un grande fan della digitazione dinamica il 90% delle volte)
5. REGISTER_GLOBALS è il diavolo

C (OK, non è il mio preferito, ma non era ancora stato fatto.)

• Sintassi della libreria socket.
• Nessun sovraccarico di funzioni.
• Stringhe di tipo C.
• Sovraccarico del buffer.
• Sintassi criptica. Non so quante volte ho cercato cose come Atoi, ho schiaffeggiato la mia fronte e ho gridato "Certo!"

EDIT: Probabilmente potrei trovarne di più se dovessi ricorrere a più codici di libreria (come ho fatto con i socket, ma quelli sono particolarmente cattivi), ma mi sentivo già come se stessi barando per scegliere su C. Così molte lingue esistono solo per prendere le parti buone di C e sostituiscono quelle cattive che è un po 'come battere un cavallo morto.

Lisp comune:

1. Le parole chiave sono spesso troppo prolisse.
2. Il supporto della biblioteca è pietoso.
3. Non funziona bene nei sistemi operativi che desiderano gestire la memoria in modo più rigoroso.
4. Non ha buone strutture per interagire con il sistema operativo.
5. La funzione "loop" non è ben definita e sicuramente non sembra Lispy.

Brainf * ck

• Il tuo punto forte è che sei Turing completo ?! Posso fare di più nelle espressioni regolari Perl!

• Mancanza di oggetti. Forza gente! È come, ciao ...

• Nessuna libreria di rete. Tutto quello che voglio è raschiare una pagina web, GOSH.

• Nessuna funzione di prima classe. Congratulazioni: puoi commiserare con i tuoi amici Java.

• Un nastro infinito per l'archiviazione e nient'altro. Questo è così analmente pretenzioso che potremmo anche scrivere Lisp.

JavaScript

1. numeri come stringhe: la matematica può essere frustrante quando i numeri vengono interpretati come stringhe. 5 + 2 = 52? Grrr ...
2. permessi - tutte le cose migliori richiedono il permesso dell'utente!
3. aggiornamenti dello schermo - Per aggiornare lo schermo, il browser deve essere in stato stabile. Non sembra esserci un modo per forzare l'aggiornamento dello schermo nel mezzo di uno script.
4. Lento, anche se Google Chrome è carino ...
5. Le differenze del browser rendono l'uso della lingua un [censurato].

PHP:

• Non si può mai essere sicuri che alcune estensioni quasi comuni siano disponibili su tutti i server web.
• cerca di essere tutto in futuro (vai, chiusure, ...)
• molti rischi per la sicurezza per utenti inesperti
• più sovraccarico dell'operatore sarebbe bello
• tutti i programmatori poveri che non imparano come farlo funzionare correttamente e che gli danno un brutto nome

Tuttavia PHP è il linguaggio (di scripting). ;-)

VB6

1. Solo Windows.
2. Non più supportato.
3. Le matrici possono iniziare da qualsiasi numero, piuttosto che essere tutte normalizzate su 0.
4. le applicazioni compilate dipendono da molte DLL per funzionare correttamente.
5. Molti controlli complicati come un controllo browser o parti di codice complicate tendono a rompere l'IDE quando si esegue il codice non compilato, ma funzionano bene quando compilati.

Ruby è la mia lingua preferita, ecco cosa non mi piace:

• Fili verdi + blocco delle librerie C = errore gigante
• COSÌ MOLTO LENTO
• La stessa libreria standard non è coerente con il suo uso del botto! metodi
• Il modulo include + estende è disordinato.
• "Classi aperte" non può essere definito - Voglio aggiungere un dostuff String #, ma non voglio che trapelino in tutte le librerie di terze parti
• Nessuna soluzione di packaging di distribuzione binaria.

Delphi:

• L'IDE è un po 'instabile.
• L'analisi del codice è talvolta confusa.
• Il debug a volte è difettoso.
• L'aggiornamento di diversi file di progetto può essere complicato.
• Se si avvia quando uno o più pacchetti non sono disponibili, il messaggio di errore viene visualizzato più volte.

JavaScript

• Ogni script viene eseguito in un unico 'spazio dei nomi' globale ... qualcosa che devi fare attenzione quando lavori con script di diverse fonti

• Se viene utilizzata una variabile ma non è stata definita in precedenza, viene considerata una variabile globale

• I fornitori di browser che definiscono gli standard a loro piacimento, rendendo la codifica per noi sviluppatori che utilizza un linguaggio così bello più difficile di quanto dovrebbe essere

• Case-Sensitivity - considerando che non esiste un IDE decente per lo sviluppo di js con controllo in fase di compilazione

• Soluzioni alternative (come l'uso del hasOwnPropertymetodo) per eseguire alcune operazioni altrimenti semplici.

Haskell:

1. Perdite di spazio dalla valutazione pigra.
2. Gerarchia numerica non costruita rispetto alle astrazioni matematiche.
3. Un IO monadico rigoroso può rendere più difficile il debug.
4. Le grandi implementazioni gestiscono l'I / O in modi che non sembrano del tutto compatibili con lo standard. (In particolare, l'output dei caratteri genera solo gli 8 bit bassi e quindi viene creato il codice che utilizza questo presupposto per eseguire l'I / O binario. Ick.)
5. L'associatività ($)dell'operatore potrebbe essere cambiata per rendere alcune espressioni più belle.

La maggior parte di questi non raggiunge il livello di odio e ci sono persone che cercano di risolvere o costruire soluzioni alternative solide per ognuno di questi.

Modifica: c'è stata una certa confusione sul punto 5. In particolare alcune persone sembrano pensare che intendessi l'ordine degli argomenti, cosa che non faccio. Piuttosto che spiegare cosa intendevo dire, indicherò le persone al seguente link, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , che lo esprime bene.