È una programmazione di stile imperativa (diciamo con Java / C) più soggetta a errori rispetto a qualcosa di più dichiarativo [chiuso]

La domanda è un po 'oscura. Uno stile di programmazione è più "incline agli errori" di un altro? Cosa significherebbe? Gli umani causano errori, non programmi. Tuttavia, alcuni stili di programmazione sono migliori per mitigare certi tipi di errore umano. Penso che sia ragionevole dire che un linguaggio compilato che non fornisce un errore di sintassi in fase di compilazione è più incline agli errori di uno che lo fa, ed è questo il senso che userò.

Alcune lingue forniscono più attenuazione di altre. Ad esempio, le lingue tipizzate staticamente forniscono errori che mitigano le violazioni di tipo *. In alcune lingue, come Haskell, il sistema dei tipi è così potente che "ottenere i tipi giusti è la maggior parte della battaglia". Direi che queste lingue forniscono più attenuazione di altre. Vale a dire, è più facile avere violazioni di tipo inattese in lingue digitate dinamicamente, ma ciò non le rende peggiori lingue

Quindi, nessun linguaggio renderà gli umani meno inclini agli errori, quindi nessuna lingua è meno soggetta a errori di per sé. Tuttavia, alcune lingue avranno strategie di mitigazione più efficaci che cattureranno gli errori umani prima che diventino bug degli utenti.

Ovviamente, niente di tutto ciò renderà un programmatore cattivo buono, né sostituirà strategie di mitigazione più solide come i test di unità.

* _{Questo non vuol dire che le lingue digitate dinamicamente siano più soggette a errori, solo che esiste una classe di bug (violazione del tipo) che non sarà mitigata direttamente dalla lingua.}

Gli errori vengono dagli umani e non dalle lingue. Né la lingua né il tipo di lingua sono rilevanti per determinare la propensione all'errore.

I codificatori pigri d'altra parte sono più inclini agli errori di quelli diligenti.

Questa è una domanda molto soggettiva. Direi che in fin dei conti è la chiarezza che conta di più quando si tratta di ridurre gli errori nei programmi, e per me personalmente, la programmazione dichiarativa è più chiara. Se riesco a capire l'essenza di ciò che un metodo è in grado di realizzare senza leggere oltre, sono già una gamba su qualcuno che deve capire che cosa faccia questo metodo per capire il quadro generale, secondo me. Questo non vuol dire che io possa in realtà sapere cosa fa (i metodi di denominazione del programmatore in modi fuorvianti), che in molti modi è peggio che non capire quello che fa affatto.

Suppongo che alla fine dipenda da cosa è più chiaro per te più di ogni altra cosa.

Uno stile inutilmente imperativo è più incline agli errori di uno stile che si basa più su funzioni pure e valori immutabili perché i valori mutabili hanno il potenziale per bug di aliasing. Se un particolare programma può essere implementato in entrambi i modi, l'approccio imperativo ha un rischio maggiore di bug a parità di tutti gli altri.

Tuttavia, non tutte le lingue supportano bene uno stile puramente funzionale. È relativamente difficile sfruttare l'immutabilità in Java, ad esempio, perché né la lingua né le librerie standard lo supportano.

Gli umani commettono errori. Più un umano deve fare, più errori fa. Pertanto, ci sono due cose che una lingua può fare:

• Aiuta a rilevare gli errori in anticipo, ad es. attraverso un sistema di tipo strong. Questo è stato coperto da altre risposte.
• Riduci la quantità di lavoro che l'umano deve fare.

Il secondo punto non riguarda semplicemente la durezza. "Lavorare" l'umano deve fare non solo la digitazione del codice. Gran parte del lavoro è nella mappatura dalla tua idea di come qualcosa funzioni a un modo di esprimerlo nel codice.

Di conseguenza, più direttamente le tue idee mappano ai costrutti del linguaggio di programmazione, meno traduzioni devi fare e meno errori introduci in quella traduzione. Ad esempio, in una lingua senza funzioni di ordine superiore, se hai una lista di cose e vuoi un elenco di cose che derivano dalle cose originali, devi tradurre dall'idea astratta "dammi una lista di derivati di cose in un'altra lista "per" creare una lista, andare oltre la lista originale, calcolare la derivata dell'elemento corrente, aggiungerla alla lista di destinazione "e poi tradurla in codice come

result = new List();
for each element in source { // what if you don't even have foreach?
  result.add(derive_from(element));
}

In una lingua che ha funzioni di ordine superiore, puoi esprimere più chiaramente la tua idea, perché devi solo tradurla per "usare la cosa che mi dà una lista con elementi corrispondenti ad un'altra lista, dargli il modo di ricava un nuovo elemento ", o nel codice:

result = map(source, derive_from);

Il codice è succinto, ma soprattutto, esprime più direttamente l'intenzione. C'era meno traduzione mentale e quindi meno spazio per l'errore.