Esperienze di “lingua convertitori”?

Question

Ho letto un paio di articoli di stampa che citano i convertitori da una lingua all'altra.

Io sono un po ' più scettici circa l'uso di questo tipo di strumenti.Qualcuno conosce o ha esperienze diciamo su Visual Basic, Java o vs convertitori?Solo un esempio di pick

http://www.tvobjects.com/products/products.html, sostiene di essere il "leader" o così, in questo aspetto, Tuttavia, se leggi questo:

http://dev.mysql.com/tech-resources/articles/active-grid.html

C'è l'autore afferma:

"Il consenso di MySQL utenti è che la conversione automatica di strumenti per MS Access non funzionano.Ad esempio, gli strumenti che traducono Accesso esistente applicazioni Java sono spesso il risultato di 80% completa di soluzioni di finitura l'ultimo 20% del lavoro è più che partire da zero."

Ben sappiamo che abbiamo bisogno ' 80% del tempo di realizzare il primo 80% della funzionalità e un altro 80% del tempo per l'altro 20 %....

Così qualcuno ha provato questi strumenti e li ha trovati per essere utile?

Answer 1

A me sembra, come è quasi sempre il caso con MS-ACCESS domande aventi tag attirare la più ampia StackOverflow popolazione, che le persone che rispondono sono mancanti la questione fondamentale, che ho letto come:

Ci sono strumenti che è possibile convertire correttamente un'applicazione per l'Accesso a qualsiasi altra piattaforma?

E la risposta è

ASSOLUTAMENTE NON

Il motivo è semplicemente che gli strumenti della stessa famiglia, che utilizzano modelli simili per gli oggetti dell'interfaccia utente (ad esempio, VB6) la mancanza di tante cose, che fornisce l'Accesso di default (come si fa a convertire un Accesso continuo sottomaschera a VB6 e non perdere la funzionalità?).E altre piattaforme non ancora condividono la stessa base del modello di VB6 e Access, in modo che coloro che hanno anche altri ostacoli per cancellare.

Il citato MySQL articolo è molto interessante, ma in realtà si confonde con i problemi che vengono con incompetently-app sviluppate vsi problemi che sorgono con gli strumenti di sviluppo utilizzati.Una brutta schema dei dati non è inerente all'Accesso-è inerente alla [più] novizio gli utenti del database.Ma gli articoli sembra attribuire questo problema di Accesso.

E interamente si affaccia la possibilità di fissazione di schema, di upsize a MySQL e mantenere il front-end in Access, che è di gran lunga l'approccio più semplice al problema.

Questo è esattamente quello che mi aspetto da persone che semplicemente non ottenere l'Accesso -- non prendere in considerazione anche che Access come front-end di un'entità a protezione diretta, di grande capacità motore di database del server può essere una soluzione migliore al problema.

Che l'articolo non davvero prendere in considerazione la conversione di un Accesso app, e c'è una buona ragione per questo.Tutti gli strumenti che ho visto, che pretendono di convertire le applicazioni di Accesso (per qualsiasi piattaforma) convertire nulla, ma i dati (in questo caso non convertire le app a tutti -- idioti!), o convertire la struttura frontale pedissequamente, con una corrispondenza 1:1 tra gli oggetti dell'interfaccia utente nell'Accesso all'applicazione e nell'applicazione di destinazione.

Questo non funziona.

L'accesso del design dell'applicazione è specifica per sé, e altre piattaforme che non supportano lo stesso set di funzionalità.Quindi, ci deve essere la traduzione di Accesso dispone di un sostituto per l'originale funzione della domanda di trasformazione.Questo non è qualcosa che può essere fatto in modo automatico, a mio parere.

In secondo luogo, quando contemplando la conversione di un Accesso app per la distribuzione nel browser web, l'applicazione del modello è diverso, cioè, da stateful di stato, e quindi non è solo una questione di un paio di Accedere a funzioni che non sono supportate, ma completamente diverso modello fondamentale di come gli oggetti dell'interfaccia utente di interagire con i dati.Forse un 100% unbound Accesso app potrebbe essere relativamente facilmente essere convertito in un browser-based di attuazione, ma come molti di quelli che ci sono?Si tratta di un Accesso app che non usa le sottomaschere di qualsiasi tipo (dal momento che non possono essere scollegati), e di un'applicazione che utilizza solo una manciata di eventi ricco modello di evento (la maggior parte dei quali lavorano solo con associati a forme/controlli).In breve, un 100% unbound Accesso app sarebbe uno che combatte contro tutto lo sviluppo di Accesso paradigma.Chi pensa che vogliono costruire un unbound applicazione in Access davvero non dovrebbe essere Access, in primo luogo, come il punto di Accesso è vincolato forme/controlli!Se si elimina, avete buttato fuori la maggioranza di Accesso del RAD vantaggio rispetto ad altre piattaforme di sviluppo, e ha guadagnato quasi nulla in cambio (oltre enorme complessità di codice).

Per creare un'app per la distribuzione nel browser web che esegue la stessa attività come le applicazioni di Accesso richiede da-la-terra-up riprogettazione dell'interfaccia utente dell'applicazione e del flusso di lavoro.Non c'è conversione che funzionerà, in quanto il successo di Accesso modello di domanda è antitetico all'applicazione web di successo del modello.

Naturalmente, tutto questo cambia con Access 2010 e Sharepoint Server 2010 con i Servizi di Accesso.In questo caso, è possibile costruire la propria applicazione in Access (utilizzando oggetti per il web) e distribuire su Sharepoint per gli utenti di eseguire nel browser.I risultati sono funzionalmente 100% equivalente (e il 90% visivamente), ed eseguire su tutti i browser (senza CIOÈ le dipendenze specifiche qui).

Così, a partire da questo mese di giugno, il modo più conveniente per convertire un Accesso app per la distribuzione nel browser potrebbe ben essere per l'aggiornamento a A2010, convertire il design di utilizzare tutti gli oggetti web, e poi distribuire con Sharepoint.Che non è una banale progetto, in quanto l'Accesso web di oggetti che hanno un numero limitato di funzionalità rispetto a oggetti client (e non VBA, per esempio, in modo da imparare il nuovo macro, che sono molto più potenti e sicuri rispetto a quelli vecchi, in modo che non è il terribile disagio può sembrare, per chi ha familiarità con Accesso eredità macro), ma probabilmente sarebbe stato molto meno lavoro rispetto a una scala completa riprogettazione per la distribuzione sul web.

L'altra cosa è che non richiede alcun corso di aggiornamento per gli utenti finali (nella misura in cui il web-oggetto la versione è la stessa come l'originale versione del client), in quanto sarà lo stesso anche per il client di Accesso, come nel browser web.

Così, in breve, direi che la conversione è una chimera, e quasi sempre non vale la pena.Io sono d'accordo con il citato sentimento, infatti (anche se ho un sacco di problemi con gli altri commenti da quella di origine).Ma vorrei anche far attenzione che il desiderio della conversione è spesso disorientato e si perde sul più economico, più facile e migliore di soluzioni che non richiedono all'ingrosso sostituzione di Accedere all'applicazione da cima a fondo.Molto spesso l'insoddisfazione con Jet/ASSO come archivio dati confonde la gente a pensare che è necessario sostituire l'Accesso dell'applicazione.E se è vero che molti sviluppati dall'utente l'Accesso apps sono pieni di terribile, non gestibile compromessi e sono tenuti insieme con la gomma da masticare e il salvataggio di filo.Ma un mal progettati applicazione di Accesso può essere migliorata in collaborazione con il back-end di upsize andrevision dei dati schema -- non deve essere scartato.

Questo non significa che non è facile - è molto spesso non.Come dico ai clienti tutto il tempo, di solito è più facile costruire una nuova casa di ristrutturare una vecchia.Ma uno dei motivi abbiamo ristrutturare case antiche è perché hanno insostituibile caratteristiche che non vogliamo perdere.È molto spesso il caso che un Accesso app contiene implicitamente un sacco di regole di business e la modellizzazione di flussi di lavoro che non deve essere perso in una nuova app (il vecchio Netscape enigma, il ritmo di Joel Spolsky).Queste cose non può essere evidente all'esterno sviluppatore che provano a porta su una piattaforma diversa, ma per l'utente finale, se l'applicazione produce risultati che sono fuori da un penny in confronto alla vecchia app, che sarà infelice (e probabilmente dovrebbe essere, dal momento che ciò può significare che altri aspetti di un'app in grado di non produrre risultati affidabili, sia).

Comunque, ho divagato un po ' troppo lungo, ma il mio parere è che la conversione non funziona mai, tranne per il più banale apps (o per quelli che sono stati progettati per essere convertiti, ad esempio, un 100% unbound Accesso app).Sono tutti per la revisione del luogo di sostitutivo.

Ma, naturalmente, che il modo di fare della mia vita, cioè, con la fissazione di Accedere alle applicazioni.

Answer 2

provato? No, in realtà costruita (più di uno) convertitore lingua.

Ecco quello che ho (e miei colleghi) costruito per il B2 Spirit Stealth Bomber per convertire il software di missione, codificato in un linguaggio legacy, gioviale, in codice C mantenibile, con il 100% di conversione automatizzata. Uno dei requisiti è che non c'è stato permesso di vedere il codice sorgente. Non è uno scherzo.

Hai ragione: se si ottiene solo un alto tasso di conversione medio (ad esempio, 70-80%), lo sforzo di rifinire la conversione è ancora molto significativo se davvero si può fare a tutti. Ci rivolgiamo il 95% + e fare meglio quando ha detto di impegnarsi di più, come è avvenuto per la B2. L'unica ragione per la gente accetta convertitori alto tasso medio è perché non riescono a trovare (o non finanzierà!) Uno migliore, insistere sulla partenza oggi , e accettare il fatto che la conversione in questo modo può essere dolorose (di solito non sanno quanto), ma è in realtà meno doloroso di ricostruire da zero. (Mi capita di essere d'accordo con questa valutazione: in generale, i progetti che cercano di ricodificare un grande sistema da zero solito fallire e conversioni utilizzando gli strumenti a tasso medio alto di conversione non hanno più in alto un tasso di fallimento.)

Ci sono un sacco di strumenti di conversione cattivi là fuori, qualcosa schiaffeggiato insieme a una montagna di codice Perl fare regex su stringhe di testo, o qualche parser YACC-based con la generazione di codice essenzialmente one-to-one per ogni istruzione in unità di compilazione . I primi sono costruiti da persone che avevano una conversione caduto su di loro dal cielo. Questi ultimi sono spesso costruiti da ingegneri buone intenzioni che non hanno compilatore sfondo decente.

Per un cattivo esempio singolarmente, vedere la mia risposta a questa domanda SO sulla migrazione COBOL: l'esperienza migrazione legacy Cobol / PL1 a Java , che è esattamente un traduttore diretta dichiarazione ... che produce la roba che ha dato origine al termine 'JOBOL'.

Per ottenere tali tassi di conversione ad alta precisione, è necessario parser di alta qualità, e mezzi per costruire regole di traduzione di alta qualità, che conservano la semantica e ottimizzare per le proprietà di destinazione per la lingua e casi particolari. In sostanza, è necessario ciò che equivale a tecnologia di compilazione configurabile. La ragione ci riusciamo, IMHO, è il nostro DMS Software Reengineering Toolkit , che era progettato per fare questo lavoro. (Io sono l'architetto; controllare il mio icona SO / bio)

.

Un sacco di attenzione test aiuta, anche.

DMS "sa" che cosa il compilatore conosce il codice, in virtù di avere un compilatore simile front-end per la lingua di interesse, e di avere la capacità di costruire AST, tabelle dei simboli, il controllo e i flussi di dati, grafici di chiamata. Esso utilizza gran parte della tecnologia compilatore che la comunità compilatore trascorso l'inventare nell'ultimo mezzo secolo, perché quella roba ha dimostrato di essere utile in traduzione!

DMS sa più che la maggior parte dei compilatori sanno, perché è in grado di leggere / analizzare / trasformare l'intera applicazione in una sola volta; maggior parte dei compilatori bastone per unità di compilazione singoli. Così regole di conversione di codice Si può che dipendono l'intera applicazione in contrasto con appena l'istruzione corrente. Noi spesso aggiungiamo conoscenza problem o applicazioni specifiche per migliorare la traduzione. Questo dimostra spesso quando la conversione di funzioni speciali di una lingua, o le chiamate sulle librerie, dove si deve riconoscere la chiamate di libreria come idiomi particolari, e li traducono in chiamate su composizioni di librerie di destinazione e costrutti del linguaggio.

Questa funzione viene utilizzata per costruire i traduttori (ad esempio, il traduttore JOVIAL), o generatori di codice specifici del dominio.

Il più delle volte si costruisce complessi strumenti di ingegneria del software automatizzati che risolvono i problemi SPECIFic ai clienti, come strumenti di analisi del programma (codice morto, codice duplicato, codice di stile spezzato, metriche, architettura estrazione, ...), e strumenti di cambiamento di massa (piattaforma [non langauge] migrazioni, inserimento livello dati, sostituzione API, ...)

Answer 3

Un paio di problemi in tal senso il successo o il fallimento della conversione cross-language sono la ricchezza semantica relativa delle lingue, ed i loro modelli semantici.

• La traduzione da C ++ a C dovrebbe essere relativamente facile, ma la traduzione di C di idiomatica C ++ sarebbe quasi impossibile perché sarebbe quasi impossibile per trasformare automaticamente un programma procedurale in un OO programma.

• Traduzione di Java in C sarebbe relativamente semplice, anche se la gestione storage management sarebbe disordinato. Traduzione di C in Java sarebbe quasi impossibile se il programma C ha fatto funky aritmetica puntatore o la fusione tra interi e diversi tipi di puntatore.

• Traduzione di un linguaggio funzionale a un linguaggio imperativo sarebbe molto più facile se il risultato sarebbe probabilmente inefficiente, un non-idiomatica. Traduzione di un linguaggio imperativo di un linguaggio funzionale è probabilmente al di là dello stato dell'arte .... a meno che non si implementa un interprete per il linguaggio imperativo nel linguaggio funzionale.

Ciò significa che alcuni traduttori sono necessariamente sarà più successo di altri in termini di:

• completezza e l'accuratezza della traduzione, e
• leggibilità e la manutenibilità del codice risultante.

Answer 4

Cose che dovrebbe mai fare, parte I da Joel Spolsky

" .... Lo hanno fatto, rendendo il singolo peggior errore strategico che qualsiasi società di software può fare:

Si decise di riscrivere il codice da zero ".

Ho un elenco dei convertitori di MS Access sul mio sito . Non ho mai sentito niente di buono su uno di loro in qualsiasi post nei newsgroup relativi di accesso che ho letto su una base quotidiana. E ho letto un sacco di post su una base quotidiana.

Si noti inoltre che v'è una notevole quantità di funzionalità di Access, come ad esempio moduli continui rilegati o sottomoduli, che è più lavoro da riprodurre in altri sistemi. Non necessariamente un sacco di lavoro, ma più lavoro. E più problemi quando arriva il momento di distribuire e installare l'applicazione.

Answer 5

Ho usato un convertitore automatico da C # per Visual Basic.NET. Ha funzionato abbastanza bene tranne che per l'aggiunta di alcune dichiarazioni inutili If True.

Ho anche tentato di utilizzare Capannone della pelle per convertire Python-to-C ++, ma non ha funzionato a causa della sua mancanza di supporto per la divisione new-style.

Answer 6

Sono strumenti utilizzati per la conversione di un progetto VB6 in VB.Net - che si spera sarebbe forse uno degli esempi più semplici di questo genere di cose. La mia esperienza è stata che tutto doveva essere controllato, nei minimi dettagli, e la metà della roba era mancante / sbagliato.

Certamente mi sento di raccomandare una migrazione a mano, oppure a seconda della lingua che si sta targetting, vorrei prendere in considerazione una completa riscrittura se questo ti dà la possibilità di fare grandi miglioramenti al codice di base.

Martin

Answer 7

Ho provato solo libero e di base a pagamento per i trasformatori. Ma il problema principale è che è molto molto difficile avere fiducia nel fatto che la conversione è del tutto riuscito.

Di solito sono i più utilizzati per sezione di codice a mano convertito in un momento, in cui si esamina ogni pezzo di codice. Spesso nella mia esperienza una riscrittura, invece di una conversione si rivela essere una scelta migliore.