È comune il prototipo in un linguaggio di livello superiore? [chiuso]

Non sarebbe utile farlo, perché a) le parti di quei linguaggi che traducono direttamente in C non sarebbero più semplici, e b) le parti che non si traducono direttamente in C sarebbero più difficili da riscrivere in C che se avessi scritto in C in primo luogo.

Questa non è una domanda con una risposta categorica sì o no. Consentitemi di valutare un aneddoto.

Esempio 1

Sono stato incaricato di eseguire il porting di un gioco scritto in Java in Flash, AS3. In superficie, questo ha il potenziale per andare relativamente agevolmente. Dopotutto, si potrebbe considerare che un lavoro del genere sia più chiaro del lavoro medio del cliente, perché hai già una specifica funzionale completamente costruita nella forma del gioco sorgente. Java e AS 3 sono entrambi linguaggi di alto livello e AS3 condivide molti tratti in comune con Java, come le strutture dei pacchetti, l'ereditarietà / multi-interfaccia, la formattazione (opt-in) e le nozioni di variabile pubblica / protetta / privata e dichiarazioni di funzioni. All'epoca ero ancora molto verde a Java e completamente nuovo al codice sorgente originale. Così mi sono tuffato per vedere cosa potevo trovare sperando che sarebbe stato facile e veloce.

Come si è scoperto, l'autore del codice aveva tentato di creare un motore astratto che potesse essere portato via da Java in qualche altro ambiente non definito. Questo mi ha dato la speranza che sarebbe stato facile portarlo. Sfortunatamente, ciò che ho scoperto è stato che stavo guardando la prospettiva di re-inventare Flash stesso su Flash, senza il vantaggio di Threads. Un porto letterale, come si è scoperto, sarebbe stata semplicemente una cattiva idea ... un incubo da prestazione. Inoltre, il gioco ha implementato un proprio linguaggio di scripting esterno personalizzato, che avrebbe significato creare un parser e un lexer per quel linguaggio se speravo di utilizzare tutti i file di dati di origine originali.

Alla fine, dati i limiti di tempo e di budget, il codice sorgente originale non è stato di grande aiuto. La parte più utile di averlo è che sapevo come imitare esattamente il flusso di controllo della logica del gioco ... ma avevo davvero bisogno della fonte originale per questo? Probabilmente no.

Ma quell'esempio potrebbe non essere così rilevante perché è una specie di rovescio della situazione. Speravo di usare un codice base che non scrivevo, in una lingua che non conoscevo al momento per accelerare lo sviluppo in un ambiente che conoscevo molto bene. Quindi, ecco un altro esempio

Esempio 2

Notando cosa stava facendo lo sviluppatore Java nel tentativo di creare una base di codice portatile, ho deciso di fare qualcosa di simile per me stesso nel mio lavoro su Flash ... scrivere codice che non si basava tanto sull'estensione delle classi flash.display. * ad esempio, e usando la composizione per creare viste. Non basandomi molto su flash.event. * E scrivendo invece un sistema di passaggio leggero dei miei, non legato in particolare a una lingua o piattaforma. Recentemente ho finito un gioco usando detto framework e volevo vedere se sarebbe stato facile portarlo in C # (linguaggio che conosco tanto quanto è simile a Java e AS3) come un progetto Unity 3D. A quanto pare, questo ha avuto molto più successo! Perché penso in modo più fluido in AS3 che in C #, avendo gli algoritmi già scritti risparmiati un sacco di tempo. Tutto quello che dovevo fare era semplicemente cambiare la sintassi, il che non è difficile quando le lingue coinvolte sono così simili in primo luogo.

Quindi, solo nella mia esperienza personale, non posso dire che la risposta sarà sempre sì o no. Dovresti considerare in che modo dipendere da specifici idiomi linguistici che ti trovi nel tuo linguaggio di alto livello e se ricrearli sarà facile o difficile in C.

Penso che sarebbe utile iniziare con lo pseudocodice. Scrivere un prototipo in un'altra lingua sembra una potenziale perdita di tempo, dal momento che il tuo linguaggio di livello superiore non è in grado di tradurre in "C" quasi altrettanto bene di pseudocodice.

Inoltre, usando lo pseudocodice, svilupperai una migliore comprensione del funzionamento effettivo del tuo sistema.

Durante lo stesso periodo in cui stai lavorando su pseudocodice, dovresti studiare C. Poi, quando hai finito con la pianificazione, potresti essere pronto a implementare realmente la cosa.

Dato che il tuo motivo proposto per scriverlo in un'altra lingua è stato quello di aiutarti a far progredire il progetto, puoi invece utilizzare alcuni diagrammi UML o qualcosa del genere per iniziare.

È possibile prototipare l'algoritmo - eliminare gli errori di progettazione della logica di base, usando un linguaggio decisamente "molto alto livello" (per esempio, Matlab, forse Ruby). Usalo per dimostrare che il tuo algoritmo funziona e funziona correttamente, quindi implementalo da zero in una lingua "di basso livello".

Non guadagnerai molto se scegli C ++ o anche Java o C # come "alto livello" e C come "basso livello" perché il guadagno in leggibilità non sarà significativo e la "traduzione" sarà ancora piuttosto dolorosa e abbastanza incline agli insetti. L'idea è l'essenza, il motore del tuo progetto nell'implementazione ad alto livello non dovrebbe occupare più di uno schermo o due, essere facile da afferrare, facile da leggere e tutti gli avvertimenti da provare in modo doloroso - essenzialmente, un blocco funzionante e percorribile diagramma.

Un motore di database si occupa principalmente di gestire I / O di basso livello in modo ottimale e di gestire in modo efficiente strutture complesse come b-tree e elenchi collegati.

Quindi è sicuramente un problema C / C ++, anche se ci sono alcune buone implementazioni Java là fuori.

Sviluppare algoritmi corretti che si comportano bene è molto più semplice in un linguaggio di livello superiore. Solitamente si tratta di provare diverse varianti e confrontare i risultati. Potresti quindi tradurre l'algoritmo "vincente" in C.

Una soluzione di compromesso potrebbe essere quella di scrivere l'implementazione iniziale in uno dei linguaggi JVM di livello superiore (Jython, Groovy vengono in mente) e quindi spostare classe per classe su Java quando l'implementazione si stabilizza.

Non penso che sia comune, ma è fatto. Uno dei più acuti architetti con cui abbia mai lavorato faceva la sua modellazione in Python e poi implementava quel codice in C ++.

In generale per rendere questo utile penso che tu debba davvero eseguire algoritmi complessi e altamente ottimizzabili che non sono facilmente espressi in modo semplice nella lingua di arrivo. Per la maggior parte delle situazioni di "mondo reale / affari", è relativamente facile esprimere l'intento di alto livello nella stessa lingua a cui ci rivolgiamo, e un'implementazione in detta lingua soddisfa i nostri requisiti di performance quindi non c'è bisogno / desiderio di modellare lingua di livello.

Data la tua situazione, dove hai una migliore conoscenza di un linguaggio di livello superiore, ho potuto vedere questa metodologia funzionare bene a breve termine. Non solo ti fornirà una tabella di marcia per mantenere le cose in pista, ma se hai domande, puoi chiedere con maggiore precisione.

Attualmente sto lavorando a un progetto che è scritto in C "a causa delle prestazioni" (questa era la motivazione originale), ma in effetti se profilato rivela che trascorre la maggior parte del tempo in attesa di altri sistemi (un DB, altro app scritte in Java, "eventi" su un socket).

Se si utilizza l'algoritmo sbagliato si ottengono prestazioni scadenti anche in C (ad esempio se si esegue una ricerca lineare per una chiave, "poiché C non ha tabelle hash e non si desidera utilizzare altre librerie", si va più lentamente che se lo fai con un linguaggio che ha tabelle hash o simili come C ++, Java, C #, Python ... e così via).

Se sei costretto a farlo in C per qualsiasi motivo, quindi la prototipazione in un'altra lingua che conosci non è per me un'idea così brutta solo se ti prototipi sapendo quali "problemi" avrai fare l'effettiva implementazione C, che è difficile se non si è sicuri di C. (Scoprirai presto ad es. che le librerie lib di C / C non hanno contenitori, solo array "semplici", hai bisogno di librerie non standard). Inoltre C non è OO, quindi se stai prototipando in modalità OO, sarà più difficile.

Riassumendo, la cosa migliore da fare è fare l'effettiva implementazione nel tuo linguaggio di "prototipazione", e poi, se davvero necessario, scrivere in C funzioni intensive della CPU, ma se solo C è accettabile, imparalo meglio prima di fare prototipo in altre lingue e, naturalmente, prima di scrivere l'implementazione.

Esistono molte applicazioni critiche per le prestazioni scritte in un linguaggio di livello superiore.

Ho programmato in Assembler e C in passato, e mentre è piuttosto freddo sentirsi così vicino al metallo, il loro uso è molto limitato al giorno d'oggi.

Ci sono così tante cose che ostacoleranno le prestazioni, che dubito che tu abbia mai raggiunto la parte in cui il linguaggio stesso è il fattore limitante. Questo sta considerando che è C vs C #.

Supponiamo di ottenere un aumento delle prestazioni del 10% -15% rispetto alla lingua. Questo non è nulla se paragonato all'aumento degli ordini di grandezza nell'ottenere l'algoritmo corretto implementato.

Quando si programma in C #, si avrà molto più tempo per concentrarsi sull'architettura e sull'implementazione di algoritmi / strutture dati, portando così a migliori ottimizzazioni di livello superiore.

Nel mondo reale sei sempre vincolato dal tempo, quindi trascorri il tuo tempo nella parte giusta del progetto.

Sono curioso di sapere quale sia il tuo piano per crearlo effettivamente in C? Hai intenzione di prototipare e quindi imparare C, e quindi ricodificarlo in C? Per me, questo sembra un po 'come il proverbiale "occhi più grandi dello stomaco", penso che molti programmatori vengano catturati mentre apprendono nuove tecnologie (lo so che ho). Ciò che intendo è che stai cercando di progettare qualcosa che sia chiaramente sensibile alle prestazioni senza nemmeno conoscere i dettagli del linguaggio che ritieni debba essere scritto, in pratica vuoi iniziare a progettare un'applicazione C prima di te Conoscere C quando il tempo può essere meglio speso per prima cosa per imparare C e quindi si può ottenere più informazioni su come scrivere l'applicazione desiderata. Forse ho scambiato la domanda e intendi consegnarla ad un altro programmatore per costruire il programma in C, nel qual caso potrebbe essere una buona idea, almeno meglio di un non-programmatore completo che prova a progettare un'app:)

A volte il prototipo è fatto per comprendere il problema che stai cercando di risolvere. E a volte, per conoscere le tecnologie sottostanti, se non lo conosci già.

Per il caso menzionato, stai considerando di prototipare in un linguaggio di scripting, ad esempio, python e per creare il codice effettivo in C.

Valutazione di alcune possibilità:

1 . Si prototipo in python e si scrive il software in C.

Il prototipo in un linguaggio di scripting può essere d'aiuto quando si desidera controllare rapidamente output rispetto all'input . Ciò è utile se hai principalmente bisogno di testare la tua logica per risolvere un problema. Inoltre, utile se vuoi mettere rapidamente insieme una demo per le altre persone.

Qualsiasi codice scritto in python non verrà utilizzato nel software finale. Ma può essere d'aiuto se stai trasmettendo il tuo prototipo a qualcuno che può leggere python e scrivere in C. Qui, la prototipazione può aiutare comunicare un'idea .

Questo metodo è appropriato per testare la fattibilità logica della soluzione.

2 . Si prototipo in C e si scrive il software in C.

La prototipazione in C, che è nuova per te, ha due vantaggi. Uno, mentre scrivi il prototipo, ottieni capisci le parti pertinenti della lingua , libreria, API, insidie, ecc. Due, mentre crei il software finale, puoi iniziare da il prototipo stesso che ti fa risparmiare tempo e riutilizza il codice .

Questo metodo è adatto per testare entrambi, la fattibilità logica e tecnologica della soluzione.

3 . Puoi prendere in considerazione modi non codificanti per prototipare a seconda del problema in questione.

Se è un pezzo di logica e idee che vuoi prototipare; pseudo codice , diagrammi di flusso e diagrammi a blocchi su carta sono buoni anche.

Se si tratta di un prototipo dell'interfaccia utente, prendi in considerazione uno strumento di simulazione dell'interfaccia utente o di nuovo un foglio di carta.

Penso che dovresti prototipare in una lingua che conosci (Pytho / Ruby / C # cosa no) in modo che:

1. Ottieni il massimo vantaggio dalle strutture / librerie fornite dalla lingua.
2. Passi il tuo tempo a decidere sulle scelte di progettazione invece che sui limiti della lingua.

In seguito, puoi usare uno strumento di profilazione per trovare le aree del collo della bottiglia. Reimplementare in C / C ++. Ripeti alcune volte il passaggio precedente, chi sa che il tuo prototipo potrebbe essere "abbastanza veloce"!

Non penso che stai guadagnando nulla con l'approccio che hai descritto, e diverse persone hanno descritto il perché in qualche dettaglio.

Un progetto con cui sono stato coinvolto ha utilizzato questo tipo di approccio: lo sviluppo di librerie matematiche per le architetture Cell / BE e Power7. Le funzioni sono state modellate in Haskell (utilizzando CoCoNUT) e le funzioni di output erano nell'assemblaggio ottimizzato per una particolare architettura di destinazione.

In questo caso gli obiettivi erano prestazioni elevate con istruzioni di assemblaggio ottimizzate e la possibilità di scegliere come target più architetture.

Cibo per se, spero che tu non muoia di fame:)

Per un motore di database ad alte prestazioni sarà necessario:

• multi-threading,
• gestione della memoria esplicita
• notifiche asincrone,
• semafori o primitive di sincronizzazione,
• facile accesso alle funzioni del file system di basso livello.

Gli algoritmi che scegli sono fondamentali per le prestazioni.

Il consiglio generale è di iniziare con un linguaggio di alto livello, quindi migrare solo i bit che devono essere ottimizzati in un linguaggio di livello inferiore.

Tuttavia , il linguaggio di alto livello che si sceglie deve essere in grado di supportare gli algoritmi che è necessario scrivere: e algoritmi efficienti possono in definitiva essere dominati dal controllo del threading, dall'uso efficiente della memoria e l'uso delle migliori operazioni di file system di basso livello disponibili. Pertanto, se l'obiettivo finale è rappresentato dalle prestazioni, non è possibile eseguire prototipi in linguaggi che non supportano le primitive da utilizzare.

Se hai bisogno di testare il tuo prototipo (o altre persone hanno bisogno di sviluppare software contro le sue interfacce), devi anche lavorare in una lingua che supporti le API previste. È quindi possibile consentire ad altre persone di testare il proprio codice ed eseguire i propri test di regressione durante l'ottimizzazione.

Queste considerazioni probabilmente escludono molte lingue per la prototipazione ad alto livello in questo caso - e probabilmente tutte quelle che hai menzionato (tranne forse C #). Ma è possibile, naturalmente, pseudo-codice in qualsiasi lingua (incluso l'inglese) e, se necessario, è possibile prototipare parti del progetto (funzioni di ordinamento, ad esempio) nella lingua preferita.

La stretta relazione tra C ++ e C (e differenze di prestazioni trascurabili) significa che ci sono pochissime ragioni per non preferire C ++ su C nel prodotto finale.

(Sto rispondendo sul presupposto che hai bisogno di un motore di database ad alte prestazioni per uno scopo particolare: se le tue intenzioni sono più modeste allora presumibilmente raccoglieresti un motore esistente dallo scaffale).

Penso che la fama di C sia ben meritata, perché il magnifico prodotto Unix è stato scritto in C. Tuttavia, rispetto alle persone che conoscono meglio C, sono piuttosto scettico sul perché dovrebbe essere usato. Si dice che Ken Thompson (dopo aver scritto una prima versione di Unix in linguaggio assembly) iniziò a scrivere Unix in Fortran, ma rinunciò dopo una settimana o un mese, e cominciò a usare C che era stato sviluppato dal suo collega Ken Ritchie a allo stesso tempo.

Sono rimasto sbalordito nel leggere recentemente che Fortran è più veloce di C e C ++.

Richard Mullins