Prove empiriche per la scelta del paradigma di programmazione per affrontare un problema

La wiki di C2 discute di prove empiriche per la programmazione orientata agli oggetti che sostanzialmente conclude che non c'è nulla al di là di un richiamo all'autorità. Questa è stata modificata l'ultima volta nel 2008. La discussione qui sembra confermarlo: domande sul fatto che OO sia obsoleto , quando la programmazione funzionale è una cattiva scelta e tutti i vantaggi e gli svantaggi di AOP ricevono risposta con le opinioni dei partecipanti senza fare affidamento sulle prove.

Naturalmente, le opinioni dei professionisti affermati e famosi sono cose gradite e preziose da avere, ma sono più plausibili quando sono coerenti con i dati sperimentali. Questa prova esiste? So che l'ingegneria del software basata sull'evidenza è una cosa, ma posso praticarla in questo contesto? In particolare, se ho un problema particolare Pche voglio risolvere scrivendo un software, esiste un corpus di conoscenze, studi e ricerche che mi farebbero vedere come il risultato della risoluzione di problemi come Pè dipeso dalla scelta del paradigma di programmazione?

So che quale paradigma emerge come "la risposta giusta" può dipendere da quali metriche un particolare studio presta attenzione, da quali condizioni lo studio mantiene costante o varia e senza dubbio anche da altri fattori. Ciò non influisce sul mio desiderio di trovare queste informazioni e di valutarle criticamente.

Diventa chiaro che alcune persone pensano che stia cercando una soluzione "gira la manovella" - una macchina per salsicce in cui metto informazioni sul mio problema e da cui deriva una parola come "funzionale" o "strutturato". Questa non è la mia intenzione. Quello che sto cercando è la ricerca di come - con un sacco di avvertimenti e ipotesi che non affronterò qui ma una buona letteratura in materia - alcune proprietà del software variano a seconda del problema e della scelta del paradigma.

In altre parole: alcune persone dicono che "OO offre maggiore flessibilità" o "i programmi funzionali hanno meno bug" - (parte di) quello che sto chiedendo è la prova di ciò. Il resto sta chiedendo prove contrarie o ipotesi in base alle quali queste affermazioni sono vere o prove che dimostrano che queste considerazioni non sono importanti. Ci sono molte opinioni sul perché un paradigma sia migliore di un altro; c'è qualcosa di oggettivo dietro uno di questi?

Per la versione precedente, vedere la Revisione 1 di questa risposta . Tuttavia, i commenti e le modifiche alla domanda chiariscono ulteriormente ciò che la domanda sta cercando e mi permettono di essere più chiaro.

Sì, l'ingegneria del software basata sull'evidenza (EBSE) è una cosa. Sembra esserci qualche sforzo verso i database EBSE, come questo alla Durham University e al SEED, che è stato avviato da un professore della Cal Poly . Tutti questi sforzi, così come quelli discussi in una serie di articoli che possono essere trovati attraverso il server IEEE Xplore o la Biblioteca digitale ACM(l'abbonamento o l'acquisto richiesto per molti documenti in entrambi) si basano su medicine basate sull'evidenza. Forniscono revisioni della letteratura sui dati empirici pubblicati (osservazione ed esperimento). In effetti, includendo la "revisione della letteratura" in una stringa di ricerca su qualsiasi ricerca di pubblicazione si ottengono informazioni sulla maggior parte degli argomenti: oltre 14000 hit su ACM e oltre 1000 sul database IEEE (se limitato a soli argomenti di elaborazione).

Osservando i tipi generali di argomenti discussi in questi database EBSE e revisioni della letteratura, vedo un filo conduttore: tendono ad essere indipendenti dalla tecnologia. L'enfasi sembra essere principalmente incentrata sul processo e sulla metodologia piuttosto che sugli strumenti specifici utilizzati per condurre l'ingegneria del software.

Quindi, questo concetto esiste nell'ingegneria del software. Academia è a conoscenza del concetto basato sull'evidenza e può applicarlo con successo all'ingegneria del software.

In particolare, la domanda che affronta l'applicazione delle tecniche EBSE alla selezione di un paradigma sembra difficile, a causa del numero elevato di variabili coinvolte, costringendo a fare ipotesi e riducendo la capacità di ripetere l'esperimento o l'osservazione. È detto proprio nella domanda - "quale paradigma emerge come" la risposta giusta "può dipendere da quali metriche un particolare studio presta attenzione, da quali condizioni lo studio mantiene costante o varia e senza dubbio anche da altri fattori" . Sebbene ciò non significhi che studiare quale paradigma sia "migliore" in una data situazione, rende incredibilmente difficile completare qualsiasi tipo di revisione della letteratura di questi documenti ed estrarre ancora informazioni su di essi.

Sicuramente non esiste una soluzione "girare la manovella" per scegliere un paradigma.

Dato un paradigma di programmazione, è possibile trovare studi nei vari database accademici e di settore su come quel paradigma influenza vari aspetti dello sviluppo del software - qualità, difetti, efficienza e così via - in varie condizioni specifiche, che vanno dalla conoscenza e dall'esperienza del team al dominio problematico. Qualsiasi documento rigoroso dovrebbe identificare chiaramente le condizioni in cui i dati sono stati raccolti e le ipotesi. Il problema diventa il tentativo di isolare i fattori che lo rendono buono in ciascuna di quelle condizioni.

Accademicamente, ci sono alcune affermazioni che sono facili da ricercare. Ad esempio, l'affermazione secondo cui il paradigma funzionale si adatta bene alle applicazioni che richiedono concorrenza deriva dal teorema di Church-Rosser . Per questo motivo, è probabile che un sistema software scritto in un linguaggio funzionale abbia meno difetti relativi alla concorrenza rispetto allo stesso sistema scritto in un linguaggio procedurale o orientato agli oggetti.

Tuttavia, da un punto di vista pratico, un team di software non può sempre utilizzare lo strumento o la tecnica "migliore" per il lavoro solo perché la ricerca lo indica. Sebbene ci impegniamo a produrre sistemi software di altissima qualità, operiamo entro limiti. Spesso vedo questi vincoli minimizzati (o addirittura rimossi dall'equazione) quando si discute dell'efficacia di qualsiasi metodologia.

Come professionista, quando sono coinvolto nella scelta delle tecnologie da utilizzare, cerco di identificare i migliori strumenti possibili. Ma poi mi costringo a ciò che è noto e ben compreso dal team che ho. Tornando al mio esempio precedente, se ho un team esperto nella creazione di applicazioni simultanee in C ++ e nessuna esperienza in Haskell, non ha senso proporre di costruire il sistema in Haskell come probabilmente non sarò in grado di fare vincoli di pianificazione e budget, e la mia qualità probabilmente soffrirà a causa della mancanza di esperienza nella toolchain.

Ricapitolando, l'ingegneria del software basata sull'evidenza è generalmente una buona cosa che esiste e le recensioni di letteratura esistono e sono prontamente disponibili. Tuttavia, ci sono aspetti dell'ingegneria del software in cui l'applicazione di approcci basati sull'evidenza offre scarso valore. La selezione di un paradigma di programmazione per uno sforzo di sviluppo su larga scala è una di queste.

Se vuoi scoprire come l'orientamento agli oggetti affronta la riusabilità o i difetti nella programmazione funzionale, troverai facilmente pubblicazioni su questi. Tuttavia, non ho trovato (né avrei confidato in alcun modo) una pubblicazione in grado di affrontare efficacemente la selezione di paradigmi attraverso l'ampia gamma di progetti di ingegneria del software nel mondo reale.

Ho letto The Art of Unix Programming di Eric S. Raymond. Ha alcune intuizioni storiche molto interessanti sulle cose che ora diamo per scontate. Cita alcuni buoni studi dal software IEEE che usano prove empiriche come la densità dei difetti. Potrebbe essere una buona fonte se stai cercando studi accademici.

Anche tecniche come la modularizzazione mediante funzioni non erano sempre pratiche comuni. Una delle mie citazioni preferite dal libro finora:

Dennis Ritchie ha incoraggiato la modularità dicendo a tutti che le chiamate di funzione erano davvero molto economiche in C. Tutti hanno iniziato a scrivere piccole funzioni e a modulare. Anni dopo abbiamo scoperto che le chiamate di funzione erano ancora costose sul PDP-11 e che il codice VAX impiegava spesso il 50% del suo tempo nell'istruzione CALLS. Dennis ci aveva mentito! Ma era troppo tardi; eravamo tutti catturati ...

- Steve Johnson

Tuttavia, ci sono davvero due problemi nel diventare troppo empirici. Il primo è che la qualità del codice è una cosa molto soggettiva. Il codice può essere terribile e comunque corretto. La percezione delle persone di un paradigma di programmazione è una metrica molto valida, perché il codice è scritto per essere letto tanto quanto per i computer, se non di più.

Il secondo problema è che il 50% degli sviluppatori ha talento di programmazione inferiore alla media. Non importa se il tuo sviluppatore principale è più produttivo utilizzando la programmazione funzionale se la "lotta" fatica a scrivere software funzionante utilizzandolo, figuriamoci software bello e ben progettato. Allo stesso modo con i linguaggi di programmazione TMTOWTDI , il tuo sviluppatore principale scriverà ancora codice pulito e modulare, ma i programmatori meno talentuosi scriveranno rumore di linea a causa della mancanza di struttura imposta.

Ecco perché penso che OOP sia salito al vertice della popolarità nonostante le sue carenze. Non è così restrittivo da ostacolare i più talentuosi, ma la sua struttura offre un modo conciso di comunicare e imporre buoni principi di progettazione ai meno talentuosi.

Nella nostra linea di lavoro abbiamo la tendenza a valutare una soluzione basata troppo sui suoi meriti tecnici da sola. Uno sforzo riuscito deve tenere conto anche del lato umano dell'equazione.

Ci sono concorsi di programmazione che utilizzano un sistema di classificazione dei computer e ti consentono di scrivere in varie lingue e pubblicare tutti i tipi di risultati e cose. Scommetto che hanno buoni dati per te. Ecco un elenco di 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Immagino che tu possa fare paragoni significativi di soluzioni a problemi molto semplici e chiari, come la somma dei quadrati, o la serie di Fibonacci, o disegnare una linea retta usando l'algoritmo della linea di Bresenham. La maggior parte delle attività di programmazione nel mondo reale non ha obiettivi così chiari e ogni lingua ha i suoi punti deboli. Gran parte del vantaggio di una lingua è soggettivo. È possibile trovare dati più significativi rilevando la felicità del programmatore e del cliente rispetto al conteggio delle righe di codice o del numero di difetti.

Ricordo che quando ho trascorso mezza giornata a scrivere uno dei miei primi programmi Awk, ho pensato che avrei impiegato un'intera settimana a fare la "stessa" cosa in Java. Questo perché la mia soluzione Java si sarebbe concentrata sull'essere robusta, poiché la soluzione Awk era veloce e sporca e richiedeva alcune modifiche manuali sull'input e sull'output ed era davvero buttata via quando avevo finito. Awk e Java sono entrambi fantastici, ma non per le stesse cose.

Immagino che ciò che sto dicendo sia che per le applicazioni del mondo reale, confrontare le lingue o gli strumenti in modo significativo è estremamente difficile: il vecchio problema delle mele e delle arance. In bocca al lupo! Mi piacerebbe vedere quello che scopri.

Ho studiato diversi modi per sviluppare software per oltre 30 anni. C'è una carenza di buone prove pubblicate sulla scelta di un paradigma.

Ho messo insieme una grande bibliografia ASCII ricercabile. Ciò include molti documenti e articoli IEEE e ACM. Taggo gli articoli con il tipo di prova fornita. Ecco i tag più comuni:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Ora cerca PARADIGM e conta i tag

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Se vuoi approfondire, http://cse.csusb.edu/dick/lab.html e spero che ti aiuti ...

Sembra che in molti casi non vi sia un corpus di ricerca abbastanza grande o di qualità sufficientemente elevata da consentire di trarre conclusioni generali sul fatto che una pratica nell'ingegneria del software sia migliore di un'altra. In particolare stavo cercando ricerche per lavorare in diversi paradigmi, ma la mancanza di disponibilità non si limita a quell'arena, quindi inquadrerò la mia risposta in un senso più ampio.

Un documento del 2004, Evidence-Based Software Engineering di Kitchenham et al , descrive in modo abbastanza succinto i benefici che devono derivare da un approccio basato sull'evidenza e i problemi con la sua implementazione nell'ingegneria del software. Non discuterò qui i vantaggi (è chiaro dalla domanda che mi piacerebbe poter lavorare in questo modo), ma i problemi sono rilevanti come risposta alla domanda che ho posto.

• in primo luogo, se non sei un membro dell'ACM, probabilmente non puoi assolutamente leggere il link sopra, che copre il primo problema: non tutta la ricerca esistente è effettivamente disponibile per i professionisti.
• molte pratiche di ingegneria del software continuano in segreto come parte di processi commercialmente riservati, quindi non c'è visibilità su ciò che ha funzionato o non ha funzionato per quelle persone.
• l'ingegneria del software è una pratica qualificata, quindi è difficile (non impossibile, semplicemente difficile) organizzare uno studio adeguatamente accecato.
• le diverse parti del ciclo di vita del software influiscono sui risultati reciproci in una misura difficile da controllare in qualsiasi esperimento.
• come dimostrato dalle discussioni qui, molti professionisti non vedono la "letteratura" (o il lato accademico dell'ingegneria del software in generale) come rilevante per il loro lavoro.

Quindi la risposta che sto cercando è "no", le prove che sto cercando probabilmente non esistono. Dovrei scegliere il mio paradigma in base ai criteri popolari esistenti di ciò che conosco, che cosa è interessante e opinione di esperti.

Non credo che questo tipo di studio esista. Si potrebbe credere che non sia il paradigma di programmazione che conta tanto quanto l'algoritmo reale che viene utilizzato. Ad esempio, dato qualsiasi sistema non banale, uno che si basa su algoritmi di piccolo spazio rispetto a uno che si basa su algoritmi di piccolo tempo genererebbe metriche diverse. Quello che ha il tempo migliore sarebbe molto probabilmente considerato più valido, a meno che lo spazio non sia un problema, allora è vero il contrario. Lo trovo simile alla pavimentazione di una strada. Mentre l'algoritmo o la ricetta per realizzare i materiali è costante in tutti i processi, è possibile che un'azienda pensi che pavimentare due corsie contemporaneamente (una su ciascun lato della strada) sia meglio che pavimentare due corsie contemporaneamente sullo stesso lato della strada . Alla fine della giornata non ha importanza in quanto il processo di creazione del top nero è sempre lo stesso, l'unica differenza è l'approccio. Tornando alla programmazione, se hai un team di sviluppatori C, scrivi il codice in modo procedurale, se hai un team di sviluppatori Java scrivilo in OO. Non rimanere bloccato sul paradigma tanto quanto l'implementazione dell'algoritmo. Perché alla fine della giornata puoi scrivere Java come C e puoi provare a scrivere C come Java.

AGGIORNARE

Per rispondere al commento graham mi ha lasciato:
Presumo per architettura che intendi paradigma di programmazione. Se hai intenzione di usare Clojure, forse dovresti assumere un team di programmatori Clojure. Tuttavia, sulla base di una ricerca rapida, Clojure è un linguaggio basato su Java e sembra essere funzionale. Date queste informazioni, prenderei i programmatori Java (dal momento che tecnicamente possono semplicemente scrivere Java e ti daranno gli stessi risultati) o cercare programmatori funzionali come gli sviluppatori Haskell. Ora, in termini di scelta di ciò che è meglio, dipende completamente dalla tua squadra. Non avrei mai un team di esperti di database relazionali ad organizzare una soluzione cloud per me, né un team di programmatori funzionali avrebbe creato una soluzione orientata agli oggetti per me. Devi usare i punti di forza della squadra, non hai la visione glorificata che hai in testa per quello che una squadra "dovrebbe"

Paradigmi diversi portano a soluzioni diverse. Quale adattamento è "migliore" dipende in gran parte da:

• la soluzione
• il team di sviluppo
• l'ambiente operativo

Non conosco uno studio così definitivo, e anche se ce ne fosse uno non mi fiderei.

Questo è il lavoro dell'architetto.

Sostituire la saggezza dell'architetto con le conclusioni forse irrilevanti di uno studio è una ricetta per il disastro.

Nota: un commento menziona la decisione "dell'algoritmo" e quindi la scelta della lingua. Gli algoritmi sono il meccanismo strutturale centrale per i linguaggi procedurali. I linguaggi orientati agli oggetti si concentrano su classi e modelli di collaborazione / comunicazione. Se sei convinto (come l'architetto) che una soluzione incentrata sugli algoritmi sia "migliore", segui i linguaggi procedurali o funzionali.

Addendum: non fidarsi degli studi non è "superstizione", è buon senso. Gli esperimenti scientifici devono essere obiettivi e ripetibili. I progetti software sono altamente soggettivi, ma peggio ancora sono esperimenti irripetibili . Semplicemente non è possibile implementare un progetto X con il team Y, misurare i risultati, quindi ripristinare i tempi, cancellare i ricordi e ripetere lo stesso progetto con lo stesso team. Le informazioni scoperte o implicite dagli studi possono essere utili all'architetto, ma non possono mai essere definitive.