Premetto che mi sembra assurdo arrivare ad usare termini quali “demagogia” in discussioni di carattere tecnico.
Non sarà costruttivo postare tante foto, peraltro bellissime, molto interessanti e comunque in tema con la discussione, ma
altrettanto non costruttivo e sicuramente più demagogico è postare una ventina di link che nulla centrano con la discussione.
Trovo inoltre che nell’ottica della sana discussione non siano nemmeno accettabili risposte autoreferenziali del tipo
“Come detto questo lo considero irrilevante per giudicare bene o male una capsula.”
Sinceramente non mi sembra un modo corretto di porsi nei confronti di quella che altro non è se non una discussione tecnica tra persone appassionate dello stesso argomento.
Sinceramente venire a postare per vedersi fare le pulci - in base a quale esperienza tecnica poi? - fa scappare la voglia di farlo. Al contrario trovo stimolante postare per mettere in discussione le proprie idee con persone competenti.
Archipeppe ha spiegato benissimo il concetto di riutilizzabilità progettuale dalla flessibilità del progetto Gemini.
Poichè in una discussione bisogna sempre porre in dubbio per primi se stessi e le proprie idee, ho preferito rifletterci un attimo e tornare alla domanda iniziale di Andrew che, in sostanza, voleva capire perchè il progetto Gemini viene considerato il più “raffinato” tra i tre progetti degli anni 60-70 della Nasa.
Io mi sono intromesso nella discussione perchè ritengo di avere una esperienza tecnico/lavorativa relativa al concetto di modularità.
Ponendo in dubbio il mio modo di pormi ieri nella discussione, mi sono reso conto che forse non ho spiegato bene questo punto e, soprattutto, non ho fatto ben capire il vero pregio del concetto di modularità. Sperando di non essere nuovamente soggetto ad una esegesi critica autoreferenziale ma ad un sano dibattito passo ad illustrare il mio pensiero. La farò un po’ lunga … se qualcuno si addormenta non mi offendo e me ne assumo le colpe. 
Come ho detto un progetto modulare scompone in blocchi logici il problema e, cosa estremamente importante, stabilisce delle interfacce (perdonate la bestialità, ieri ho scritto alcune volte “interfaccie” con la “i” 
) tra i blocchi. Quest’ultima affermazione è la chiave dei vantaggi che derivano da una progettazione modulare e, al tempo stesso, è la parte più difficile da attuare.
Porto come esempio qualche cosa che i vari ipod hanno reso un po’ desueto ma credo sia semplice da capire:
Ricordate quei bei sistemi HiFi degli anni 70-80? C’erano sistemi compatti/integrati in cui, in un blocco monolitico, c’erano il piatto giradischi, la piastra registratore/riproduttore cassette il sintonizzatore e l’amplificatore/equalizzatore. Ovvio che non potevo cambiare uno di questi componenti, altrettanto ovvio che se mi si rompeva il riproduttore di cassette dovevo portare tutto a far riparare e restavo per giorni senza poter ascoltare musica da nessun media.
Al contrario c’erano quei bei sistemi (oddio ci sono ancora ma in quegli anni il fenomeno era più marcato) in cui i componenti erano separati e le case avevano imposto una interfaccia tra i componenti fatta di specifiche meccaniche dei connettori e specifiche elettriche che adattavano ingresso ed uscita dei componenti. In sostanza, oltre a poter far riparare solo il pezzo che eventualmente si rompeva, si poteva mettere l’amplificatore della marca X, il registratore di quella Y e così via. Il sistema era enormemente flessibile ma il grosso vantaggio era che, se io cambiavo un pezzo ero assolutamente cerrto che questo non avrebbe creato problemi ad un altro pezzo. Sulla presunta miglior qualità del pezzo X rispetto a quello Y nascevano guerre di religione che la discussione in corso qui è roba da educande. 
Chi ha un minimo di conoscenza di programmazione orientata agli oggetti ( magari con linguaggi seri come Eiffel, che consiglio spassionatamente) avrà riconosciuto il concetto base di incapsulamento che permette di descrivere con del software un oggetto del mondo reale che comunica con altri tramite interfacce e permette, punto importantissimo, di modificare il software all’interno di un oggetto senza che gli altri moduli siano influenzati.
Chi programma per diletto e/o senza una metodologia, al contrario, si rende conto dopo poco che modifiche apportate da una parte del programma vanno a modificare il comportamento di altre parti. Inoltre, con la programmazione modulare orientata agli oggetti, testo un modulo anche se gli altri non sono pronti e, una volta che sono sicuro che presenti alle sue interfacce il comportamento desiderato, sono sicuro che si integrerà alla perfezione nel resto del progetto.
Ora, e finalmente arriviamo alla astronautica, per poter stabilire se il progetto Gemini è o non è modulare dovrei avere in mano i disegni originali e, quasi sicuramente, non avrei comunque la competenza tecnica per poter capire a fondo tali progetti.
Fortunatamente ho trovato questo documento che vi consiglio di leggere
klabs.org/history/papers/gemini_mercury_experience.pdf
In esso si afferma chiaramente che, dopo le esperienza Mercury, la Nasa si era resa conto che un grosso problema nasceva dalle difficoltà di testare il funzionamento del sistema nella sua completezza e si individuava nell’approccio modulare la soluzione a tale problematica. Se siete interessati vi consiglio di leggere a pag.5, in fondo, il capitoletto intitolato “Checkout”
Inoltre troverete nei capitoletti precedenti conferma a quanto riferitoci da Archipeppe in merito all’interesse iniziale della NASA per la Gemini paraglider.
Trova conferma a questo punto quanto sostenevo ieri, e cioè che il rateo elevato di missioni del programma Gemini, nonostante i profili estremamente complessi e variabili da una missione all’altra, era dovuto ANCHE al progetto modulare che comportava una notevole maggior facilità di eseguire le procedure di checkout dei componenti. (N.B. “ANCHE”, ovviamente “NON SOLO”).
Pertanto chi obietta questo punto è pregato ora di farlo su basi tecniche e non autoreferenziali della serie “Io ritengo” … sinceramente “Io ritengo” non è rilevante.
Poichè il progetto Apollo è precedente a Gemini probabilmente ha potuto usufruire completamente di questo approccio modulare. Ad ogni modo eventualmente tale approccio è comunque una conseguenza dell’esperienza Gemini. Con questo penso di aver risposto da un’altra angolazione rispetto a quanto già esposto da Archipeppe in merito al perchè il progetto Gemini è da considerare il più raffinato dei tre.
Certo poi ci sono considerazioni di scomodità ed altro, ma quello che importa è un concetto progettuale per la prima volta applicato ad una astronave.
Se mi consentite torna ora chiaro perchè il progetto Gemini fu affidato allo staff di Jim Chamberlein, la cui linea di pensiero, l’esperienza aeronautica da cui lui proveniva, era quella inglese che adottava almeno in via embrionale tale concetto a livello di costruzione aeronautica già dagli anni della seconda guerra mondiale.
Guardate come ritornano alcuni concetti che a volte sembrano così lontani. Avete presente in F1 la Lotus 49? La prima vettura con motore portante in cui il motore non era più integrato nel telaio ma collegato a sbalzo al telaio ed era un componente facilmente sostituibile ed intercambiabile … Non per nulla anche Chapman proveniva da quella scuola di pensiero ingegneristico e, guarda caso, la Lotus 49 è pressochè contemporanea alla Gemini.
Scusate la lunghezza dello scritto.
