Differenze architettoniche tra linguaggi dinamici e statici

Ci sono differenze architettoniche importanti nella progettazione di applicazioni che saranno costruite su linguaggi statici (come C # o Java) e linguaggi dinamici (come Ruby o Python)?

Quali sono le possibilità di progettazione che potrebbero essere una buona scelta per un tipo che è una cattiva per l'altro? Ci sono funzioni utili ottenibili con un tipo che non è con l'altro (nel design e nell'architettura, ovviamente)?

Inoltre, ci sono modelli di progettazione specifici per la dinamica?

Vediamo alcune cose direttamente:

1. Gli script interattivi e i linguaggi statici non si escludono a vicenda. F # e Haskell hanno entrambi interfacce REPL.
2. I linguaggi dinamici e le alte prestazioni non si escludono a vicenda, anche se alcune ottimizzazioni lo sono. Al giorno d'oggi JavaScript funziona abbastanza velocemente sulla maggior parte dei browser.
3. Anche nei linguaggi dinamici, devi ancora documentare, ricordare e pensare ai tipi.
4. A causa della crescente popolarità dell'inferenza dei tipi, molti linguaggi statici non devono più notarli molto spesso. In linguaggi statici con una forte deduzione del tipo, il compilatore capisce quali sono i tipi dal tuo codice in modo che il più delle volte e ti dice se fai mai qualcosa che viola le definizioni dei tipi. Per quanto riguarda la sintassi, ciò fornisce il meglio di entrambi i mondi.
5. OOP e linguaggi dinamici non si escludono a vicenda. PHP ora supporta le classi e persino l'ereditarietà.

A parte queste sorprendenti somiglianze, ci sono alcune differenze pratiche che influenzano il processo di sviluppo:

1. I linguaggi dinamici consentono modi interessanti per trasferire i dati nel piccolo .
2. I linguaggi statici consentono di ridurre la quantità di test da eseguire rendendo impossibili molti tipi di bug.
3. Allo stesso modo, i linguaggi statici consentono interessanti funzionalità di validazione e conversione automatica, come le unità di misura in F # .
4. Prese all'estremo, i linguaggi statici consentono contratti di codice e verifica formale, che possono documentare e appianare prevenire cose come potenziali divisioni per zeri, cicli infiniti, riferimenti null, dimensioni o indici di elenco non validi, errori di intervallo e altri stati logicamente non validi che potresti definire.
5. Portando questo estremo ancora di più, le ottimizzazioni della CPU possono essere fatte sulla base di questi vincoli statici, che producono prestazioni ancora migliori.

Esiste anche un tipo di programma che non avrebbe mai potuto essere realizzato senza la tipizzazione statica: Singularity , un sistema operativo senza limiti di processo hardware. È scritto in una piccola quantità di C, un po 'di C # e un dialetto di C # chiamato Spec #, che supporta i contratti di codice.

Nonostante sia scritto in un linguaggio spazzatura, le prestazioni di comunicazione multitasking e tra processi su questo sistema operativo sono in realtà migliori di qualsiasi altra cosa là fuori, a causa del fatto che tutti i processi vengono eseguiti in uno spazio di memoria e grazie alle ottimizzazioni formali di verifica I sopra menzionato. Non è possibile farlo senza la digitazione statica, perché affinché i programmi non possano compromettere il resto del sistema, gli oggetti di comunicazione devono essere verificabili staticamente.

La maggior parte delle volte, tuttavia, le architetture dovrebbero essere molto simili. I linguaggi statici possono rendere più facile ragionare sui programmi in molti casi perché i tipi sono ben definiti, ma un programma di linguaggio dinamico ben scritto avrebbe anche tipi che sono, almeno, ben definiti nella mente degli sviluppatori.

C'è una differenza architettonica significativa. Prestazione.

A seconda del budget dell'hardware, del carico di lavoro previsto e degli accordi sul livello di servizio, potrebbe non essere possibile soddisfare i requisiti con un linguaggio dinamico.

Molto spesso la velocità di sviluppo e la flessibilità fornite dai linguaggi dinamici compensano i tempi di risposta più lenti a un maggiore consumo di CPU e memoria. Ma per i sistemi più grandi con limiti di budget o prestazioni, i costi generali di un linguaggio dinamico possono essere elevati.

Non ho mai pensato in questo senso. Quindi, quando ha fatto un Google, il blog di Peter Norvig è stato uno dei maggiori successi. Dice che alcuni modelli di progettazione sono più facili da implementare nei linguaggi dinamici rispetto ai linguaggi orientati agli oggetti tradizionali come il C ++. Penso che dovrebbero esserci differenze anche nel design / nell'architettura, poiché osserva che l'implementazione è più semplice nei linguaggi dinamici. Cercherò di aggiungere altro alla risposta mentre studio ulteriormente.

Ci sono differenze architettoniche importanti nella progettazione di applicazioni che saranno costruite su linguaggi statici (come C # o Java) e linguaggi dinamici (come Ruby o Python)?

No.

È leggermente più semplice scrivere quadri fantasiosi per linguaggi dinamici. Ma non è un'applicazione.

Quali sono le possibilità di progettazione che potrebbero essere una buona scelta per un tipo che è una cattiva per l'altro?

Nessuno, davvero.

Puoi scrivere cose buone in entrambe le lingue.

Ci sono funzioni utili ottenibili con un tipo che non è con l'altro (nel design e nell'architettura, ovviamente)?

No.

La differenza è che i linguaggi dinamici sono "scrivi, esegui, correggi". Puoi sperimentare e risolvere rapidamente.

I linguaggi statici sono "scrivere, compilare, compilare, eseguire, correggere". Non puoi sperimentare così facilmente.

Oltre a ciò, sono quasi identici nelle loro capacità.

Esistono modelli di progettazione specifici per la dinamica?

Può essere. Il Python eval()e le execfile()funzioni - in un certo senso - evidenziano una funzione di linguaggio dinamico che è difficile (ma tutt'altro che impossibile) da gestire in un linguaggio statico. Sarebbe molto più righe di codice per compilare ed eseguire il codice nello stesso spazio di processo.

Non è specifico per il linguaggio dinamico. È più semplice