Qual è il più grande difetto di progettazione che hai affrontato in qualsiasi linguaggio di programmazione? [chiuso]

Tutti i linguaggi di programmazione hanno i loro difetti di progettazione semplicemente perché non un singolo linguaggio può essere perfetto, proprio come con la maggior parte (tutte?) Altre cose. A parte questo, quale difetto di progettazione in un linguaggio di programmazione ti ha infastidito di più nella tua storia di programmatore?

Nota che se una lingua è "cattiva" solo perché non è progettata per una cosa specifica non è un difetto di progettazione, ma una caratteristica del design, quindi non elencare tali fastidi delle lingue. Se una lingua non è adatta per quello per cui è stata progettata, questo è ovviamente un difetto nel design. Neanche le cose specifiche per l'implementazione e le cose nascoste.

Uno dei miei grandi fastidi è il modo switchin cui i casi nei linguaggi derivati ​​da C passano al caso successivo se si dimentica di usare break. Comprendo che ciò è utile in un codice di livello molto basso (ad es. Duff's Device ), ma di solito è inappropriato per il codice a livello di applicazione ed è una fonte comune di errori di codifica.

Ricordo che nel 1995, quando stavo leggendo i dettagli di Java per la prima volta, quando arrivai alla parte switchsull'affermazione, rimasi molto deluso dal fatto che avessero mantenuto il comportamento di fall-through predefinito. Questo si trasforma switchin un glorificato gotocon un altro nome.

Non mi è mai piaciuto l'uso di =per assegnazione e ==test di uguaglianza nei linguaggi derivati ​​da C. Il potenziale di confusione ed errori è troppo elevato. E non farmi nemmeno iniziare ===in Javascript.

Meglio sarebbe stato :=per il compito e =per la verifica dell'uguaglianza. La semantica avrebbe potuto essere esattamente la stessa di oggi, in cui l'assegnazione è un'espressione che produce anche un valore.

La scelta di +in Javascript sia per l' aggiunta che per la concatenazione di stringhe è stata un terribile errore. Poiché i valori non sono tipizzati, ciò porta a regole bizantine che determinano se +aggiungere o concatenare, a seconda del contenuto esatto di ciascun operando.

Inizialmente sarebbe stato facile introdurre un operatore completamente nuovo, ad esempio $per la concatenazione di stringhe.

Trovo Javascript predefinito a livello globale per un grosso problema e spesso fonte di bug se non si utilizza JSLint o simili

Il preprocessore in C e C ++ è un kludge massiccio, crea astrazioni che perdono come setacci, incoraggia il codice spaghetti attraverso i nidi di #ifdefdichiarazioni di ratto e richiede ALL_CAPSnomi orribilmente illeggibili per aggirare i suoi limiti. La radice di questi problemi è che opera a livello testuale piuttosto che a livello sintattico o semantico. Avrebbe dovuto essere sostituito con funzionalità di linguaggio reale per i suoi vari casi d'uso. Ecco alcuni esempi, anche se è vero che alcuni di questi sono risolti in C ++, C99 o estensioni non ufficiali ma di fatto standard:

• #include avrebbe dovuto essere sostituito con un sistema di moduli reale.

• Le funzioni e i modelli / generici incorporati potrebbero sostituire la maggior parte dei casi d'uso delle chiamate di funzione.

• Per dichiarare tali costanti è possibile utilizzare una sorta di caratteristica di costante di tempo manifest / compilare. Le estensioni di enum di D funzionano benissimo qui.

• Le macro a livello di albero della sintassi reale potrebbero risolvere molti casi d'uso vari.

• I mixin di stringhe potrebbero essere utilizzati per il caso d'uso dell'iniezione di codice.

• static ifo versiondichiarazioni potrebbero essere utilizzate per la compilazione condizionale.

Si potrebbero elencare centinaia di errori in centinaia di lingue, ma IMO non è un esercizio utile dal punto di vista della progettazione linguistica.

Perché?

Perché qualcosa che sarebbe un errore in una lingua non sarebbe un errore in un'altra lingua. Per esempio:

• Rendere C una lingua gestita (cioè raccolta dei rifiuti) o legare i tipi primitivi ne limiterebbe l'utilità come linguaggio semi-portatile di basso livello.
• L'aggiunta della gestione della memoria in stile C a Java (ad esempio, per risolvere i problemi di prestazioni) la interromperebbe.

Ci sono lezioni da imparare, ma le lezioni raramente sono ben definite e per capirle devi capire i compromessi tecnici ... e il contesto storico. (Ad esempio, l'implementazione ingombrante di generici da parte di Java è una conseguenza di un requisito aziendale prevalente per mantenere la retrocompatibilità.)

IMO, se sei seriamente intenzionato a progettare una nuova lingua, devi effettivamente utilizzare una vasta gamma di lingue esistenti (e studiare lingue storiche) ... e decidere quali sono gli errori. E devi tenere a mente che ognuna di queste lingue è stata progettata in un particolare contesto storico, per colmare un bisogno particolare.

Se ci sono lezioni generali da imparare, queste sono al livello "meta":

• Non è possibile progettare un linguaggio di programmazione ideale per tutti gli scopi.
• Non puoi evitare di commettere errori ... specialmente se visto da dietro.
• Molti errori sono dolorosi da correggere ... per gli utenti della tua lingua.
• Devi tener conto del background e delle abilità del tuo pubblico target; cioè programmatori esistenti.
• Non puoi piacere a tutti.

C e C ++ : tutti quei tipi interi che non significano nulla.

Soprattutto char. È testo o è un numero intero minuscolo? Se è testo, è un carattere "ANSI" o un'unità di codice UTF-8? Se è un numero intero, è firmato o non firmato?

int era inteso per essere il numero intero "nativo", ma sui sistemi a 64 bit, non lo è.

longpuò essere o non essere più grande di int. Può essere o meno la dimensione di un puntatore. È praticamente una decisione arbitraria da parte degli autori del compilatore sia che si tratti di 32 bit o 64 bit.

Sicuramente una lingua degli anni '70. Prima di Unicode. Prima dei computer a 64 bit.

null.

Il suo inventore, Tony Hoare, lo definisce "l'errore di miliardi di dollari" .

È stato introdotto in ALGOL negli anni '60 ed esiste oggi nella maggior parte dei linguaggi di programmazione comunemente usati.

L'alternativa migliore, usata in lingue come OCaml e Haskell, è forse . L'idea generale è che i riferimenti agli oggetti non possono essere nulli / vuoti / inesistenti a meno che non vi sia un'indicazione esplicita che potrebbero essere così.

(Anche se Tony è fantastico nella sua modestia, penso che quasi tutti avrebbero commesso lo stesso errore, e per caso è stato il primo.)

Ho la sensazione che le persone che hanno progettato PHP non usassero una tastiera normale, non usassero nemmeno una tastiera colemak, perché avrebbero dovuto capire cosa stavano facendo.

Sono uno sviluppatore di PHP. PHP non è divertente da digitare.

Who::in::their::right::mind::would::do::this()? L' ::operatore deve tenere premuto il tasto Maiusc e quindi premere due tasti. Che spreco di energia.

Although-> this-> è-> non-> molto-> meglio. Ciò richiede anche tre pressioni di tasti con lo spostamento tra i due simboli.

$last = $we.$have.$the.$dumb.'$'.$character. Il simbolo del dollaro viene utilizzato moltissime volte e richiede che il premio si estenda fino alla cima della tastiera più una pressione del tasto Maiusc.

Perché non potevano progettare PHP per usare chiavi che sono molto più veloci da digitare? Perché non è possibile we.do.this()o avere varati iniziare con una chiave che richiede solo un singolo tasto - o per niente (JavaScript) e semplicemente pre-definire tutti i var (come devo fare comunque per E_STRICT)!

Non sono una dattilografa lenta, ma questa è solo una scelta di design scadente.

L'uso di forme ispirate al desktop all'interno di asp.net .

È sempre sembrato un pasticcio e si è messo in mezzo o il modo in cui funziona davvero il web. Per fortuna asp.net-mvc non soffre allo stesso modo, anche se con merito a Ruby ecc. Per quell'ispirazione.

Per me è l'assoluta mancanza di PHP di convenzioni di denominazione e ordinamento degli argomenti nella sua libreria standard.

Sebbene la necessità di JASS di annullare i riferimenti dopo che l'oggetto referenziato è stato rilasciato / rimosso (o il riferimento perderebbe e diversi byte di memoria andrebbero persi) è più grave, ma poiché JASS è un linguaggio a scopo singolo, non è così critico.

Il più grande difetto di progettazione che devo affrontare è che Python non è stato progettato come Python 3.x per cominciare.

Decadimento della matrice in C e di conseguenza in C ++.

Tipi primitivi in ​​Java.

Infrangono il principio secondo cui tutto è un discendente java.lang.Object, che da un punto di vista teorico porta a un'ulteriore complessità delle specifiche del linguaggio e da un punto di vista pratico rendono l'uso delle raccolte estremamente noioso.

L'autoboxing ha contribuito ad alleviare gli svantaggi pratici, ma a costo di rendere le specifiche ancora più complicate e di introdurre una grossa buccia di banana grassa: ora puoi ottenere un'eccezione del puntatore null da quella che sembra una semplice operazione aritmetica.

Conosco meglio Perl, quindi lo prenderò.

Perl ha provato molte idee. Alcuni erano buoni. Alcuni erano cattivi. Alcuni erano originali e non ampiamente copiati per una buona ragione.

Una è l'idea del contesto : ogni chiamata di funzione ha luogo in un elenco o in un contesto scalare e può fare cose completamente diverse in ogni contesto. Come ho sottolineato su http://use.perl.org/~btilly/journal/36756 questo complica ogni API e spesso porta a sottili problemi di progettazione nel codice Perl.

La prossima è l'idea di legare la sintassi e i tipi di dati in modo così completo. Ciò ha portato all'invenzione del legame per consentire agli oggetti di mascherarsi come altri tipi di dati. (Puoi anche ottenere lo stesso effetto usando il sovraccarico, ma il pareggio è l'approccio più comune in Perl.)

Un altro errore comune, fatto da molte lingue, è iniziare offrendo scoping dinamico piuttosto che lessicale. È difficile ripristinare questa decisione di progettazione in un secondo momento e porta a verruche di lunga durata. La descrizione classica di quelle verruche in Perl è http://perl.plover.com/FAQs/Namespaces.html . Si noti che questo è stato scritto prima che Perl aggiungesse ourvariabili e staticvariabili.

Le persone non sono legittimamente in disaccordo sulla tipizzazione statica rispetto a quella dinamica. Personalmente mi piace la digitazione dinamica. Tuttavia, è importante disporre di una struttura sufficiente per consentire la cattura di errori di battitura. Perl 5 fa un buon lavoro con severi. Ma Perl 1-4 ha sbagliato. Diverse altre lingue hanno pedine che fanno la stessa cosa di rigorose. Fintanto che sei bravo a far applicare il controllo dei filacci, questo è accettabile.

Se stai cercando altre idee cattive (molte), impara PHP e studia la sua storia. Il mio errore preferito in passato (risolto da tempo perché portava a così tante falle di sicurezza) era quello di consentire a chiunque di impostare qualsiasi variabile passando i parametri del modulo. Ma questo è tutt'altro che l'unico errore.

Ambiguità di JavaScripts per blocchi di codice e valori letterali degli oggetti.

  {a:b}

potrebbe essere un blocco di codice, dove aè un'etichetta ed bè un'espressione; oppure potrebbe definire un oggetto, con un attributo ache ha il valoreb

Tornerò a FORTRAN e all'insensibilità agli spazi bianchi.

Ha pervaso le specifiche. La ENDcarta doveva essere definita come una carta con una 'E', una 'N' e una 'D' in quell'ordine nelle colonne 7-72 ​​e nessun altro non bianco, piuttosto che una carta con "END" nella corretta colonne e nient'altro.

Ha portato a una facile confusione sintattica. DO 100 I = 1, 10era un'istruzione di controllo del ciclo, mentre DO 100 I = 1. 10era un'istruzione che assegnava il valore 1.1 a una variabile chiamata DO10I. (Il fatto che le variabili possano essere create senza dichiarazione, il loro tipo a seconda della loro prima lettera, ha contribuito a questo.) A differenza di altre lingue, non c'era modo di usare gli spazi per separare i token per consentire la chiarimento delle ambiguità.

Ha anche permesso ad altre persone di scrivere codice davvero confuso. Ci sono ragioni per cui questa funzione di FORTRAN non è mai stata duplicata mai più.

Uno dei maggiori problemi con BASIC è stata la mancanza di un metodo ben definito per estendere il linguaggio oltre i suoi primi ambienti, portando a una serie di implementazioni completamente incompatibili (e un tentativo post-facto quasi irrilevante di qualsiasi standardizzazione).

Quasi ogni lingua verrà piegata all'uso generico da parte di un programmatore pazzo. È meglio pianificare l'uso generico all'inizio nel caso in cui l'idea folle decolla.

Credo nei DSL (linguaggi specifici del dominio) e una cosa che apprezzo in una lingua è se mi permette di definire un DSL al di sopra di esso.

In Lisp ci sono macro: la maggior parte delle persone lo considera una buona cosa, così come io.

In C e C ++ ci sono macro - le persone si lamentano di loro, ma sono stato in grado di usarle per definire DSL.

In Java, sono stati esclusi (e quindi in C #) e la loro mancanza è stata dichiarata una virtù. Certo, ti permette di avere intellisense, ma per me è solo un'opera d' arte . Per fare il mio DSL, devo espandermi a mano. È una seccatura e mi fa sembrare un cattivo programmatore, anche se mi permette di fare molto di più con tonnellate di codice in meno.

Dichiarazioni , in ogni lingua che le possiede. Non fanno nulla che tu non possa fare con le espressioni e ti impediscono di fare molte cose. L'esistenza di un ?:operatore ternario è solo un esempio di come cercare di aggirarli. In JavaScript, sono particolarmente fastidiosi:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

Per me, è il problema di progettazione che affligge tutti i linguaggi derivati ​​da C; vale a dire l '" altro penzolante ". Questo problema grammaticale avrebbe dovuto essere risolto in C ++, ma è stato portato avanti in Java e C #.

Penso che tutte le risposte finora indicano un singolo fallimento di molte lingue tradizionali:

Non è possibile modificare la lingua principale senza influire sulla compatibilità con le versioni precedenti.

Se questo viene risolto, praticamente tutti gli altri problemi possono essere risolti.

MODIFICARE.

questo può essere risolto nelle biblioteche con spazi dei nomi diversi e potresti pensare di fare qualcosa di simile per la maggior parte del nucleo di una lingua, anche se ciò potrebbe significare che devi supportare più compilatori / interpreti.

In definitiva, non credo di sapere come risolverlo in un modo totalmente soddisfacente, ma ciò non significa che non esiste una soluzione o che non si può fare di più

Overflow aritmetico intero silenzioso di Java

Sia Java che C # hanno fastidiosi problemi con i loro sistemi di tipi a causa del desiderio di mantenere la retrocompatibilità durante l'aggiunta di generici. A Java non piace mescolare generici e array; C # non consente alcune firme utili perché non è possibile utilizzare i tipi di valore come limiti.

Come esempio di quest'ultimo, consideralo

public static T Parse <T> (tipo <T> tipo, stringa str) dove T: Enum

oggetto statico pubblico Parse (Type type, string str)

MyEnum e = Enum.Parse (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Parse (typeof (MyEnum), str);

tl; dr: pensa al polimorfismo parametrico quando inizi a progettare il tuo sistema di tipi, non dopo aver pubblicato la versione 1.

Mi sento come se mi stessi aprendo per essere fiammeggiato, ma odio davvero la capacità di passare semplici vecchi tipi di dati per riferimento in C ++. Odio solo leggermente essere in grado di passare tipi complessi per riferimento. Se sto guardando una funzione:

void foo()
{
    int a = 8;
    bar(a);
}

Dal punto di chiamata, non c'è modo di dire che bar, che può essere definito in un file completamente diverso, è:

void bar(int& a)
{
    a++;
}

Qualcuno potrebbe obiettare che fare qualcosa del genere potrebbe essere solo una cattiva progettazione del software e non dare la colpa alla lingua, ma non mi piace che la lingua ti permetta di farlo in primo luogo. Usando un puntatore e chiamando

bar(&a);

è molto più leggibile.

ALTER

Quando ho imparato COBOL, l'istruzione ALTER faceva ancora parte dello standard. In breve, questa affermazione consentirebbe di modificare le chiamate di procedura durante il runtime.

Il pericolo era che si potesse inserire questa affermazione in una sezione oscura del codice a cui si accedeva raramente e che poteva potenzialmente cambiare completamente il flusso del resto del programma. Con più istruzioni ALTER potresti rendere quasi impossibile sapere cosa stava facendo il tuo programma in qualsiasi momento.

Il mio istruttore universitario, con molta enfasi, dichiarò che se avesse mai visto quella dichiarazione in uno dei nostri programmi ci avrebbe automaticamente bocciato.

Il peggior peccato di un linguaggio di programmazione non è stato ben definito. Un caso che ricordo è C ++, che, nelle sue origini:

1. Era così mal definito che non era possibile ottenere un programma da compilare ed eseguire seguendo i libri o gli esempi.
2. Una volta ottimizzato il programma per la compilazione e l'esecuzione in un compilatore e sistema operativo, dovresti ricominciare da capo se hai cambiato compilatore o piattaforma.

Come ricordo, ci sono voluti circa un decennio per definire C ++ abbastanza bene da renderlo affidabile dal punto di vista professionale come C. È qualcosa che non dovrebbe mai più accadere.

Qualcos'altro che considero un peccato (dovrebbe andare in una risposta diversa?) È avere più di un modo "migliore" per svolgere un compito comune. È il caso di (di nuovo) C ++, Perl e Ruby.

Le classi in C ++ sono una sorta di modello di progettazione forzata nel linguaggio.

Non c'è praticamente alcuna differenza in fase di runtime tra una struttura e una classe, ed è così confuso capire qual è il vero vantaggio di programmazione reale di "nascondere le informazioni" che voglio metterlo lì.

Sto per essere sottovalutato, ma i compilatori C ++ sono così difficili da scrivere che questa lingua sembra un mostro.

Anche se ogni lingua ha i suoi difetti, nessuno è fastidioso una volta che li conosci. Tranne questa coppia:

Sintassi complessa accoppiata a API complesse

Ciò è particolarmente vero per un linguaggio come Objective-C. Non solo la sintassi è straordinariamente complessa, ma l'API utilizza nomi di funzioni come:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Sono tutto per essere esplicito e non ambiguo, ma questo è ridicolo. Ogni volta che mi siedo con xcode, mi sento come un n00b, e questo è davvero frustrante.

1. caratteri firmati in C - un abominio inventato per consentire ai matematici di avere grandi collezioni di piccoli oggetti
2. Usare case per trasportare contenuti semantici, ancora una volta per i matematici, che non hanno bisogno di parlare e non hanno mai abbastanza spazio per le loro formule
3. Assegna / Assegna in modo semplice rispetto a Assegna in dialetti di base - nessun matematico coinvolto qui penso