Tempo del compilatore rispetto al tempo del programmatore [chiuso]

Prima di tutto, tempo di compilazione IS tempo di sviluppo: gli sviluppatori che costruiscono e testano un sistema devono attendere il codice da compilare tra ogni modifica del codice e la loro capacità di testarlo unitamente.

Detto questo, se il linguaggio fa in modo che gli sviluppatori possano codificare le cose correttamente con un risparmio di tempo che compensa il tempo in cui si siedono in attesa di una compilazione, probabilmente non gli dispiacerà più di tanto.

Inoltre, il fattore Legge di Moore ridurrà comunque i tempi di compilazione a lungo termine.

I want to briefly discuss managed or interpreted languages.

Ti rendi conto (spero) che "gestito" e "interpretato" siano concetti ortogonali.

• Una lingua gestita è quella in cui il sistema di runtime si occupa della gestione dinamica dello spazio.

• Una lingua interpretata è quella in cui il programma viene eseguito da un interprete anziché dalla compilazione in codice nativo.

Inoltre, interpretato rispetto a non interpretato è generalmente un problema di implementazione nella lingua.

Is programmer time worth more than compiler time?

In effetti, il tempo del compilatore è il tempo del programmatore. È ora che il programmatore debba attendere tra una modifica e l'altra. In effetti, questo è uno dei vantaggi delle lingue interpretate: il tempo del ciclo di modifica / test è ridotto rispetto alle lingue compilate.

Il vero compromesso è tra il tempo del programmatore e la velocità del prodotto finale; per esempio. il tempo che l'utente finale deve attendere mentre il programma viene eseguito. E ciò dipende sia dalla lingua scelta (o, più precisamente, dall'implementazione del linguaggio) che dall'applicazione.

Sono uno sviluppatore Java. L'IDE di Eclipse compila continuamente il mio codice mentre lo scrivo, quindi la compilazione non richiede alcun tempo notevole mentre lo sviluppo.

Trascorro quasi zero la compilazione del tempo rispetto al pensiero o alla programmazione.

Io uso principalmente Clojure, quindi quando sto sviluppando solitamente ho un REPL in esecuzione che compila le singole espressioni mentre le digito. Il tempo di compilazione è effettivamente istantaneo (almeno, non l'ho mai notato ... ottieni la risposta praticamente istantaneamente dopo aver premuto invio)

Quindi il quadruplo del tempo di compilazione in cambio di una produttività di sviluppo raddoppiata sarebbe chiaramente una vittoria nel mio caso. Tuttavia, non sono convinto che una tale proposta di linguaggio di programmazione esista. Quindi è un argomento un po 'ipotetico ....

Ridurre lo sforzo di sviluppo a metà su tutta la linea? Quello che proponi non è altro che il mitico proiettile d'argento! Quindi, sì, sarebbe un compromesso spettacolare. Il tempo di costruzione può essere sempre sotto controllo con macchine più veloci, parallelizzazione, legge di Moore ecc. Al momento, lo sforzo degli sviluppatori per caratteristica e qualità è praticamente irriducibile - anche le migliori metodologie software hanno difficoltà a dimostrare che lo riducono anche da un piccola quantità - e gli stipendi degli sviluppatori sono il collo di bottiglia nella produzione del software.

Se tu avessi un compilatore così mitico, metterei in avanti un business case al mio capo per comprare ad ogni sviluppatore un computer che fosse 4 volte più veloce di quello che abbiamo attualmente. Salterebbe alla prospettiva di raddoppiare la produzione di 30 sviluppatori spendendo circa $ 100.000.

Immagino che il compilatore sia davvero mitico .....

Bene, sviluppando in C ++ immagino di essere idoneo per una lunga compilazione:)

La verità è che sebbene il tempo di compilazione possa effettivamente diventare importante, c'è molto da fare per parallelizzarlo (lavoro su un server a 24 core, e usiamo distcc per riunirli), quindi compilare l'intera applicazione è circa 5/6 minuti nonostante le sue dimensioni piuttosto impressionanti. Le build incrementali sono di circa 20/30 secondi (c'è un po 'di tempo di caricamento per i controlli automatici delle dipendenze).

D'altra parte, il caricamento del programma richiede circa 1m / 1m30 a causa di un sacco di configurazioni che si verificano durante (e subito dopo) il caricamento della DLL.

Come tale, mentre mi sento paralizzato da una svolta lenta (fastidioso quando si vuole testare una soluzione rapida), il tempo di compilazione non è nemmeno la metà della storia.

Se avessi usato un linguaggio interpretato (per esempio Python), avrei probabilmente perso più tempo perché avrebbe dovuto comunque compilare (anche se implicitamente) e il tempo di caricamento sarebbe molto più lento ... (Bene, e ovviamente Python non è realmente multi-thread, quindi non sarebbe una buona idea: /)

Scarsa implementazione, ci sono tre cose che rallentano i compilatori:

Ottimizzazione
1. - molti buoni compilatori impiegano molto tempo per ottimizzare effettivamente la schifezza di ciò che appare come ovvio codice imperativo. Il vantaggio di questo è che non si deve passare molto tempo ad eseguire micro-ottimizzazione banale sulla base di ipotesi che potrebbero anche essere sbagliate, quando il compilatore spesso ha un'euristica e una conoscenza di gran lunga migliori della piattaforma target rispetto a te fare. In questo modo puoi concentrarti sulla scrittura del codice clear . Ciò consente di risparmiare un sacco di tempo durante la scrittura e ancora di più durante il debug.
2. caratteristiche della lingua - ci sono molte funzionalità linguistiche costose. Il sovraccarico ad esempio è uno. Prima di poter chiamare un metodo sovraccarico, è necessario eseguire un'analisi di tipo statico sul sito di chiamata. Un problema che un compilatore C non incontrerà per esempio. I sistemi di tipo statico in generale non sono esenti da costi, ma offrono ovvi benefici. Anche la programmazione generica può essere piuttosto costosa (specialmente qualcosa di espressivo come i modelli C ++), così come altri tipi di meta-programmazione. Quindi, mentre potrebbe richiedere del tempo al compilatore per capire cosa intendi esprimere e tradurlo in una forma eseguibile, hai il vantaggio di poter esprimere le cose molto più vicino ai tuoi pensieri. Puoi scrivere programmi, che sono significativamente più brevi e quindi più facili da mantenere.
3. sicurezza - molti compilatori (o strumenti di compilazione) eseguono analisi statiche oltre a quanto necessario per compilare un programma. Attraverso tutti i tipi di analisi del flusso e altre tecniche, sono in grado di individuare sezioni di codice che probabilmente sono errori e avvisano di conseguenza. Ciò consente di ridurre notevolmente il potenziale degli errori e di risparmiare tempo di debugging lungo, che consiste principalmente nel tentativo di riprodurre alcuni bug che si verificano molto raramente.

Penso che tutti questi siano di grande beneficio. Personalmente, non mi piace l'idea di fare qualcosa, che una macchina non solo può fare per me, ma probabilmente lo fa anche più velocemente e meglio. Non vedo alcun valore nell'eseguire compiti noiosi e ripetitivi. Questo consuma molto tempo, introduce nuove fonti di errore e mi mette a dura prova, impedendomi di concentrarmi su aspetti più importanti della programmazione.

Le prestazioni non contano nel calcolo, finché non lo è, cioè. E quando le prestazioni contano può essere il fattore trainante.

Le prestazioni non sono un fattore se questo linguaggio ipotetico modifica un tempo di compilazione di 2 o 3 secondi in dieci secondi. Come programmatore, non hai perso il contesto mentale in quei dieci secondi. Le prestazioni sono un fattore enorme se questo linguaggio ipotetico modifica una build di due ore già inaccettabile in una build di un giorno. Questo tipo di "miglioramento" cambierà drasticamente il modo in cui il team progetta, programma e test. Una build e un test notturno da zero potrebbero non funzionare più durante la notte. I programmatori perderanno il contesto mentale e subiranno una perdita di produttività piuttosto che un aumento di produttività.

Esempio: questo potrebbe accadere quando un prodotto passa da una lingua di file di input personalizzata a uno schema che usa python. SWIG è bello ma può aggiungere un enorme carico di build, rendendo facilmente questo ipotetico fattore di quattro una realtà.

Nessuna risposta giusta qui.

La compilazione più rapida tende a creare una tendenza, in alcuni programmatori e non tutti, a "lascia solo provare questo". Perché provare è "economico", cioè veloce, e quindi armeggiare succede invece di pensare.

Compilazione più lenta. girarsi tende a fare molta attenzione prima di compilare in modo da non perdere tempo in pista. Ma tende anche a essere frustrante a causa della lentezza della svolta, della mancanza di una rapida gratificazione e della percezione che quel tempo è un dispiacere.

In entrambi i casi ci sono percezioni (tempo perso contro feedback rapido) e diversi processi di pensiero.

In entrambi i casi, i programmatori veramente bravi non si preoccupano davvero - pianificano il loro lavoro, pensano prima di compilare comunque, e generalmente sanno cosa stanno facendo e quindi evitano di armeggiare.

I meno grandi programmatori possono avere le loro inadeguatezze mascherate dal ciclo di compilazione / esecuzione più veloce ... vengono catturate alla fine da una mancanza di comprensione in ogni caso - ma può richiedere più tempo per scoprire le loro debolezze.

L'intera storia dei "cicli di cpu sono economici" si è materializzata per la prima volta quando ero a Uni negli ultimi anni '80 - scatenata da qualche docente. OGNI SINGOLO LAVORO, da allora, l'ho messo alla prova e l'ho trovato una bugia.

I cicli della CPU contano quasi sempre qualcosa da qualche parte: su sistemi embedded, codice scadente o lento significa che il razzo non volerà dritto o la lavatrice si riempie eccessivamente. I sistemi Web si esauriscono e necessitano di hardware più costoso quando ci sono troppe connessioni. I sistemi aziendali sono troppo a lungo per le richieste. E avanti e avanti va. A mano a mano che le richieste aumentano, le dimensioni e la complessità del software aumentano, le prestazioni di elaborazione aumentano, le richieste aumentano ... e si ripetono le ripetizioni del ciclo.

In tutte queste cose c'è un compromesso, e di solito non è molto ovvio dove si trova fino a quando non scavi in profondità per guardare le cose.