In quali circostanze le lingue dinamiche non sono appropriate? [chiuso]

Question

Quali fattori indicano che la soluzione di un progetto non dovrebbe essere codificata in un linguaggio dinamico?

Answer 1

La velocità è in genere la risposta principale. Anche se questo sta diventando meno un problema in questi giorni.

Answer 2

Familiarità e disponibilità dei programmatori a lavorare con la lingua.

Il tuo linguaggio dinamico è probabilmente il mio linguaggio statico.

Answer 3

Lo sviluppo a livello di sistema è un gruppo chiave di software che in genere non dovrebbe essere in linguaggi dinamici. (driver, roba a livello di kernel, ecc.)

Fondamentalmente tutto ciò che deve avere ogni grammo di prestazioni o accesso hardware di basso livello, dovrebbe essere in una lingua di livello inferiore.

Un altro indicatore è se si tratta di un numero elevato di dati, come il numero di dati scientifici. Cioè, se ha bisogno di correre veloce e fare scricchiolii numerici.

Penso che un tema comune siano i problemi che richiedono un uso intensivo del processore ... nel qual caso vedrai facilmente le differenze di prestazioni e scoprirai che il linguaggio dinamico non può darti il ??potere di usare l'hardware in modo efficace.

Detto questo, se stai facendo un intenso lavoro del processore e non ti dispiace il successo nelle prestazioni, allora potresti comunque potenzialmente usare un linguaggio dinamico.

---

Aggiornamento:

Nota che per crunching numerico intendo crunching numerico molto lungo nell'arena scientifica in cui il processo è in esecuzione per ore o giorni ... in questo caso un guadagno di prestazioni 2x è GINORMOUS ... se è su un livello molto più piccolo scala, quindi i linguaggi dinamici potrebbero ancora essere utili.

Answer 4

In larga misura, il linguaggio di programmazione è una scelta di stile. Usa la lingua che vuoi usare e sarai massimamente produttivo e felice. Se per qualche ragione ciò non è possibile, allora spero che la tua decisione finale si baserà su qualcosa di significativo, come una piattaforma contro cui devi correre o numeri di performance empirici reali, piuttosto che la scelta di stile arbitraria di qualcun altro.

Answer 5

Driver di dispositivo per scheda video

Answer 6

quando la velocità è cruciale. I linguaggi dinamici stanno diventando più veloci, ma ancora non vicini alle prestazioni di ciò che è un linguaggio compilato.

Answer 7

L'interoperabilità è assolutamente possibile con linguaggi dinamici. (ricorda il classico visual basic, che ha "lazy binding"?) Richiede che il componente COM sia compilato con alcuni extra per aiutare i loro chiamanti a chiamare per nome.

Non penso che il crunching dei numeri debba essere compilato staticamente, molto spesso dipende da come risolvi. Matlab è un buon esempio fatto per lo scricchiolio dei numeri e ha un linguaggio non compilato. Matlab, tuttavia, ha un runtime molto specifico per numeri e matrici.

Answer 8

Credo che dovresti sempre optare per un linguaggio tipicamente statico, ove possibile. Non sto dicendo che C # o Java abbiano buoni sistemi statici ma C # si sta avvicinando. Una buona tipo inferenza è la chiave perché ti darà benefici visti in linguaggi dinamici pur continuando a darti sicurezza e caratteristiche di quelli digitati staticamente. Problema risolto - niente più guerre di fiamma.

Answer 9

Codice a livello di sistema per sistemi integrati. Un possibile problema è che i linguaggi dinamici a volte nascondono le implicazioni delle prestazioni di una singola dichiarazione dall'aspetto semplice.

Come dire questa affermazione Perl:

@contents = <FILE>;

Se FILE è di pochi megabyte, questa è un'istruzione che consuma risorse: potresti esaurire l'heap o causare un timeout del watchdog o generalmente rallentare la risposta del sistema incorporato.

Se vuoi "programmare più vicino al metal", probabilmente vorrai utilizzare un tipo di livello statico e "medio" " linguaggio.

Answer 10

Che ne dici di interop? È possibile chiamare un componente COM da Ruby o Python?