Traduzione e lettura in italiano di Davide Bracaglia dall’essay originale di Paul Graham "Why Arc Isn't Especially Object-Oriented".
In questo momento c'è una sorta di mania per la programmazione Object-Oriented, ma alcuni dei programmatori più intelligenti che conosco sono tra i meno entusiasti.
La mia sensazione è che la programmazione Object-Oriented sia una tecnica utile in alcuni casi, ma non è qualcosa che deve pervadere ogni codice che si scrive. Dovreste essere in grado di definire nuovi tipologie, ma non dovreste esprimere ogni programma come la definizione di nuovi tipi.
Credo che ci siano cinque ragioni per cui alla gente piace la programmazione orientata agli oggetti, e tre e mezzo di queste sono negative:
La programmazione orientata agli oggetti è entusiasmante se si dispone di un linguaggio a tipi statici senza chiusure lessicali o macro. In un certo senso, offre un modo per aggirare queste limitazioni. (Si veda la decima regola di Greenspun).
La programmazione orientata agli oggetti è popolare nelle grandi aziende, perché si adatta al modo in cui scrivono il software. Nelle grandi aziende, il software tende a essere scritto da grandi team (che cambiano spesso) di programmatori mediocri. La programmazione orientata agli oggetti impone a questi programmatori una disciplina che impedisce a ciascuno di loro di fare troppi danni. Il prezzo è che il codice risultante è gonfio di protocolli e pieno di duplicazioni. Questo non è un prezzo troppo alto per le grandi aziende, perché il loro software probabilmente sarà comunque gonfio e pieno di duplicazioni.
La programmazione orientata agli oggetti genera molto di quello che sembra lavoro. Ai tempi del fanfold, c'era un tipo di programmatore che metteva su una pagina solo cinque o dieci righe di codice, precedute da venti righe di commenti elaborati. La programmazione orientata agli oggetti è come il crack per queste persone: permette di incorporare tutta questa impalcatura direttamente nel codice sorgente. Qualcosa che un hacker Lisp potrebbe gestire spingendo un simbolo in un elenco diventa un intero file di classi e metodi. È quindi un ottimo strumento se si vuole convincere se stessi, o qualcun altro, che si sta facendo molto lavoro.
Se un linguaggio è esso stesso un programma orientato agli oggetti, può essere esteso dagli utenti. Beh, forse. O forse si può fare ancora meglio offrendo i sottoconcetti della programmazione orientata agli oggetti à la carte. L'overloading, per esempio, non è intrinsecamente legato alle classi. Vedremo.
Le astrazioni orientate agli oggetti si adattano perfettamente ai domini di alcuni tipi specifici di programmi, come le simulazioni e i sistemi CAD.
Personalmente non ho mai avuto bisogno di astrazioni orientate agli oggetti. Common Lisp ha un sistema di oggetti enormemente potente e non l'ho mai usato. Ho fatto molte cose (per esempio tabelle di hash piene di chiusure) che avrebbero richiesto tecniche orientate agli oggetti per essere realizzate in linguaggi più stupidi, ma non ho mai dovuto usare CLOS.
Forse sono solo stupido o ho lavorato su un sottoinsieme limitato di applicazioni. C'è un pericolo nel progettare un linguaggio basato sulla propria esperienza di programmazione. Ma sembra più pericoloso inserire cose di cui non si è mai avuto bisogno perché si pensa che sia una buona idea.
Perché Arc Non è Particolarmente Object-Oriented // Why Arc Isn't Especially Object-Oriented