Cosa si può fare contro l'inerzia linguistica? [chiuso]

6

Spesso i progetti usano il linguaggio di programmazione X, ma utilizzerebbero il linguaggio di programmazione Y se fossero stati avviati da zero.

Ad esempio, i grandi modelli numerici possono essere scritti interamente in Fortran. Considerando che questa potrebbe essere una scelta ragionevole per i componenti che devono essere eseguiti velocemente (alternativa sarebbe C o C ++), potrebbe essere una scelta sbagliata per i componenti che non hanno bisogno di essere veloci (come le cose che riguardano input umani o semplici visualizzazioni), o dove il runtime non è il fattore limitante (come I / O, in particolare quando dalla rete).

Un altro esempio potrebbe essere quando un progetto viene costruito usando un linguaggio proprietario (come Matlab; no, i cloni FOSS non sono abbastanza buoni ) e fu avviato in un momento in cui le alternative FOSS non erano vitali, ma dieci anni dopo, lo sono; e sarebbe utile migrare.

Tuttavia, a causa di inerzia della lingua , non si verifica una migrazione. Il codice che funziona non deve essere toccato, il porting code è un processo costoso e dispendioso in termini di tempo e i programmatori hanno familiarità con il linguaggio X, ma non necessariamente nella lingua Y. Tuttavia, a lungo termine, una migrazione sarebbe probabilmente vantaggiosa.

Si può fare qualcosa per mitigare i problemi associati all'inerzia linguistica? Ci sono esempi notevoli di grandi progetti che hanno superato con successo questo problema? O è un progetto destinato a rimanere per sempre con le scelte iniziali?

    
posta gerrit 07.12.2012 - 18:59
fonte

3 risposte

12

Secondo la mia esperienza, la migrazione di un prodotto funzionante dalla lingua A alla lingua B avverrà solo se ci sono ragioni difficili, comprovate, tecniche o legali che renderanno impossibile lo sviluppo ulteriore del linguaggio. Quasi nessuna azienda investirà in una transizione linguistica per altri motivi.

Alcuni esempi del mondo reale che ho visto finora:

  • un componente chiave del prodotto non sarà ulteriormente sviluppato e non vi è una sostituzione adeguata nella lingua A

  • il sistema basato su COBOL gira su hardware così vecchio che non è possibile acquistare alcun pezzo di ricambio e la migrazione a un moderno dialetto COBOL su hardware moderno non sembra essere più economica di una migrazione a un altro linguaggio moderno

  • problemi di licenza con i componenti principali

  • il vecchio sistema era basato su componenti Windows a 16 bit in cui non sono più disponibili cavi a 32 bit e devi supportare Windows a 64 bit

  • il linguaggio stesso (il compilatore / interprete) non è più supportato, né dal creatore né da alcun fornitore di terze parti, o almeno non dall'ambiente di destinazione

risposta data 07.12.2012 - 19:30
fonte
2

Bene, i grandi progetti sono portati da una vecchia lingua a una nuova (e da vecchie piattaforme / tecnologie / framework a nuovi) ogni giorno. Almeno un paio di società con cui ho lavorato sono state sottoposte a tale passaggio (di solito da FORTRAN a C ++).

Ci sono anche alcuni casi di programmi open source portati da una lingua a un'altra. La prima versione di GNU Arch di Tom Lord (l'archetipo predecessore di GIT e strumenti simili di DRCS) è stata scritta come un gruppo di Script Bash e in seguito è stato portato su C.

Nella maggior parte dei casi, questi porting vengono eseguiti utilizzando strumenti di traduzione speciali (di terze parti o personalizzati). Di solito, il codice risultante necessita di alcuni (o molti) aggiustamenti manuali ma molto spesso è possibile eseguire tali porting.

Nonostante ciò, ci sono almeno un paio di buoni motivi per non che eseguono tali porting:

  1. La maggior parte delle volte, il porting di codice da una lingua / piattaforma / framework / tecnologia a uno nuovo non ha alcun senso. L'utente finale acquista una soluzione (un programma di lavoro) non una scelta interessante di strumenti e tecnologie di sviluppo. Di conseguenza, la società del software si concentra sulla vendita di prodotti di lavoro e su qualsiasi altra cosa.

  2. Il codice di porting è la parte facile. La maggior parte delle volte, devi portare molti altri dettagli (perché il nuovo ambiente non supporta più i vecchi). Il diavolo prospera nei dettagli e questi dettagli possono byte molto dolorosamente.

Quindi, di solito un progetto (piccolo, medio o grande, non importa) verrà portato su un nuovo "qualcosa" solo se il vecchio non può più essere usato. Un tipico esempio è il passaggio da architetture da 16 bit a 32 bit.

Naturalmente, ci sono un paio di strumenti / modi per facilitare il passaggio da una vecchia tecnologia a una nuova:

  1. Strumenti di traduzione validi e affidabili.

  2. Metodologie di porting collaudate.

risposta data 07.12.2012 - 19:54
fonte
0

... dipende sempre da cosa sia realmente il 'lungo termine'. Il codice e i runtime basati su server che soddisfano le esigenze specifiche (dati da aziende e persone) non verranno mai migrati. Quel pezzo di codice può avere 30 anni di investimenti, correzioni di bug e funzionalità integrate.

Dove si vede la maggior parte della migrazione durante la migrazione sta cambiando le interfacce utente - un'applicazione Visual Basic non può essere "portata" su un'applicazione iPhone, ecc. ecc. Nel valutare le migrazioni (o anche le nuove architetture), mantenere un attenzione a quella separazione di tipo MVC in modo che un giorno possa diventare possibile (o più semplice) mettere una nuova interfaccia utente su un'applicazione di successo.

Altro esempio: mentre ci spostiamo dai greenscreen alle architetture web, c'è ancora un lotto di funzionalità di guida al codice PL / SQL nelle applicazioni Oracle basate sui dati. In più di alcuni casi, non riesco a vedere alcun PL / SQL essere "riscritto" o portato su qualsiasi altra cosa, purché il database Oracle sia ancora in circolazione ...

    
risposta data 07.12.2012 - 20:38
fonte

Leggi altre domande sui tag