Le lingue statiche e tipicamente dinamiche possono essere viste come strumenti diversi per diversi tipi di lavori?

9

Sì, domande simili sono state poste ma sempre allo scopo di scoprire "qual è la migliore".

Lo sto chiedendo perché mi sono inventato principalmente in JavaScript e non ho molta esperienza nella scrittura in linguaggi tipicamente statici.

Ciononostante, vedo sicuramente valore nell'apprendimento del C per la gestione di operazioni impegnative a livelli di codice più bassi (che presumo abbia molto a che fare con statica vs dinamica a livello di compilatore), ma quello che sto cercando di avvolgere la testa è se ci sono contesti di progetto specifici (forse alcuni tipi di operazioni dinamiche ad alta intensità di dati?) che coinvolgono cose diverse dalle prestazioni in cui ha molto più senso andare con Java o C # rispetto a qualcosa come Python.

dynamic-typing static-typing

— Erik Reppen
fonte

5

La risposta è si". Ogni tipo di lingua - in effetti ogni lingua - ha i suoi punti di forza e di debolezza e quindi è più adatto ad alcuni compiti rispetto ad altri.

— ChrisF

è interessante usare C come esempio, dal momento che è una specie del linguaggio più tipicamente debole che potresti concedere e comunque chiamarlo staticamente tipizzato. C non è veloce a causa del sistema di tipi, i controlli dei tipi avvengono in fase di compilazione. C è veloce perché ci sono poche o nessuna misura di sicurezza e controlli per impedirti di spararti al piede. e perché si compila in binari nativi.

— Sara

10

Sì, sicuramente.
La digitazione dinamica presenta vantaggi evidenti nei casi in cui si desidera essere in grado di trattare tutto come un solo tipo. La serializzazione / deserializzazione è uno degli esempi classici. Questo è il motivo per cui così tanta programmazione Web viene eseguita in linguaggi di script tipizzati in modo dinamico: sono adatti a un'attività che comporta la conversione di tutti i tipi di dati da e verso stringhe.

Per la programmazione delle applicazioni, d'altra parte, i linguaggi statici funzionano molto meglio perché cercare di trattare tutto come un singolo tipo non è spesso un requisito. Spesso si desidera disporre di strutture dati efficienti con i dati rappresentati come se stessi e non essere convertiti in altri tipi molto frequentemente. Ciò rende le funzionalità della digitazione dinamica uno svantaggio anziché un vantaggio, motivo per cui le applicazioni sono quasi esclusivamente scritte in linguaggi tipizzati staticamente.

— Mason Wheeler
fonte

3

@Erik: Non sono sicuro che lo direi nemmeno. Le cose cambiano durante lo sviluppo. I requisiti possono cambiare o scopri che non stai implementando correttamente un requisito e il codice deve essere aggiornato. Essere in grado di cambiare una cosa e usare gli errori del compilatore risultanti per mostrarti dove trovare tutto ciò che deve essere cambiato fornisce un enorme impulso alla convenienza e alla velocità di sviluppo che perdi nelle lingue in cui quella tecnica non è disponibile. Questo è uno dei motivi per cui non vedi app complicate sviluppate in linguaggi dinamici.

— Mason Wheeler,

9

@Mason Wheeler: Ottima risposta. + 1 Aggiungo che il controllo del tipo statico aiuta anche a trovare prima i bug avendo la correttezza del tipo di controllo del compilatore. Ad esempio, ho eseguito il debug di un programma Ruby a 200 righe ieri e c'erano due bug relativi al tipo che potevo rilevare solo eseguendo il programma. Non voglio pensare a cosa succede in un progetto a 100000 linee. Quindi la digitazione dinamica ti dà maggiore flessibilità, il che è buono nei contesti che hai descritto, al prezzo che non puoi trovare alcuni bug al momento della compilazione. Quindi la tipizzazione statica non è solo correlata all'efficienza, ma anche alla correttezza.

— Giorgio,

1

@MasonWheeler Due anni e molto più C # e Java di quanto mi aspettassi in seguito, ora non sarei d'accordo con un paio di cose. Le app Web complesse sono realizzate interamente con linguaggi dinamici. Compilare vs. tempo di esecuzione non ha senso quando è possibile apportare modifiche che sono immediatamente visibili. E ho sviluppato l'opinione secondo cui tutti i tipi di confusione hanno molto più senso in un linguaggio procedurale che in un linguaggio che dovrebbe essere guidato da OOP in cui i dati non dovrebbero cambiare costantemente le mani in primo luogo.

— Erik Reppen,

1

@Erik: * wince * Prima di tutto, giudicare la tipizzazione statica come un concetto di Java è come giudicare le auto come un concetto di Pinto. In secondo luogo, qualsiasi cosa in cui i cambiamenti possono essere "immediatamente visibili" non è, per definizione, un programma molto complesso, perché anche con un hardware moderno, i programmi complessi richiedono un bel po 'di tempo per preparare il codice, sia esso un compilatore o un interprete ( o un compilatore JIT) che esegue la preparazione. Anche le applicazioni Web più impressionanti tendono ad essere programmi molto semplici supportati da database molto complessi, il che è una questione completamente diversa.

— Mason Wheeler,

1

La capacità di fare astrazioni complesse è ortogonale all'avere un sistema di tipo statico vs dinamico e anche ortogonale alla velocità. Ci sono sistemi di tipo statico là fuori che consentono astrazioni incredibilmente potenti (anche se a volte arcane). Avere cambiamenti che compaiono all'istante è anche indipendente dal sistema di tipi: puoi certamente costruire interpreti per linguaggi tipicamente statici.

— Rufflewind,

4

Per come la vedo io, se riesci a lavorare in modo naturale in un linguaggio tipicamente statico, allora la tipizzazione statica è la strada da percorrere. In generale, lo scopo di un sistema di tipi è impedire all'utente di eseguire operazioni con semantica indefinita - come (string) "hello" + (bool) true. Avere il livello extra di sicurezza che ti impedisce di eseguire queste operazioni può essere un buon modo per prevenire bug nel tuo codice, anche senza test di unità estesi. Cioè, la sicurezza dei tipi offre un altro livello di fiducia nella correttezza semantica del codice.

Ma i sistemi di tipo sono molto difficili da ottenere. Non credo che ci sia un sistema di tipi perfetto in natura al momento in cui scrivo. (Per "sistema di tipo perfetto" intendo un sistema di tipo rigoroso, che non richiede annotazioni in codice dettagliato, che non genera errori di tipo falsi positivi e i cui errori di tipo sono facili da comprendere per il programmatore.) Inoltre, può essere difficili da capire i sistemi di tipo veramente buoni che esistono. Quando stavo imparando Haskell, non posso dirti il numero di errori di tipo oscuro che ho avuto nel tentativo di scrivere quello che sembrava (per me) come il codice corretto. Di solito il codice non era in realtà corretto (il che è un punto a favore del sistema di tipi), ma ci è voluto moltodi lavoro per comprendere i messaggi di errore del compilatore, in modo da poter correggere i problemi sottostanti. Nei linguaggi OO, alla fine potresti ritrovarti a pensare "questo argomento dovrebbe essere contraddittorio con il tipo di input, non covariante!" O (più probabilmente) tornare ai tipecast per sfuggire ai limiti del sistema dei tipi. I sistemi di tipo possono diventare molto più complicati di quanto si pensi.

Per quello che vale, ho capito che la difficoltà nel trovare buoni sistemi di tipo fa parte di ciò che ha motivato Gilad Bracha a includere il supporto del sistema di tipi collegabile in Newspeak.

— Aidan Cully
fonte

Test unitari WRT, sono completamente d'accordo. Vedi sempre persone che dicono "se hai buoni test unitari, possono verificare la correttezza del tipo per te". Mi ha sempre ricordato come Paul Graham (che crede fermamente che la digitazione dinamica sia sempre una buona cosa) affermi che un linguaggio che ti fa fare manualmente il lavoro del compilatore è un linguaggio imperfetto. Sorta ti fa fermare e pensare ...

— Mason Wheeler,

Penso che molte delle preoccupazioni sui "pericoli" delle lingue tipizzate dinamicamente non tengano conto del modo in cui scriviamo queste cose. Gran parte di Python e JS possono essere scritti in stile console. Vite la compilazione contro il tempo di esecuzione, posso provarlo ora e vedere cosa succede. Penso che tu abbia raggiunto un ottimo punto, comunque. Niente mi rende più folle nello sviluppo web sul lato client di quando tutti i presunti buoni venditori di browser danno un passaggio confuso al codice orribile mentre IE6 o 7 fa l'inaspettato, che è quello di cagare quando dovrebbe piuttosto che solo, beh ... succhiare in un modo più tipico.

— Erik Reppen,

I tipi di disadattamento di mason-wheeler sono errori di trival, e non è che i linguaggi dinamici non controllino i tipi, è solo in fase di esecuzione. La mia esperienza è che la maggior parte dei linguaggi statici hanno lo stesso livello di copertura dei test unitari, non stanno perdendo alcun test perché il compilatore controlla i tipi in anticipo e i linguaggi dinamici non devono aggiungere test specifici per verificare i tipi , il sistema di runtime controlla i tuoi tipi, se il tuo test unitario copre il tuo metodo li catturerebbe.

— jbtule,

4

Sono strumenti diversi, ma non per prestazioni. Si tratta di complessità .

I linguaggi dinamici di solito puntano alla massima flessibilità e portano mancanza di convalida e una sorta di garanzia. Quindi, è molto potente nei programmi su piccola scala, ma diventa quasi impossibile mantenere programmi su larga scala (complessità).

Le lingue statiche di solito mirano alla massima convalida. Il loro primo obiettivo è in genere rilevare errori (o bug) il prima possibile. Molte garanzie sono fatte per la convalida. Quindi è più difficile imparare e iniziare, ma man mano che i programmi aumentano, fornisce una migliore convalida del programma con costi molto inferiori (sforzi di codifica).

Di conseguenza, i linguaggi dinamici di solito si adattano a programmi piccoli (intendo molto piccoli) come pagine Web dinamiche, browser Web DSL (non per applicazioni browser!) O script di shell. Le lingue statiche si adattano meglio alle programmazioni di sistema o ad altri elementi.

Le descrizioni sopra sono qualcosa che riguarda linguaggi puramente dinamici o statici. La maggior parte delle lingue della vita reale sono tra loro e mostra varie caratteristiche.

Vedi qui per maggiori dettagli: https://softwareengineering.stackexchange.com/a/105417/17428

— Eonil
fonte

1

"i linguaggi dinamici di solito si adattano a programmi piccoli (intendo molto piccoli)": nella mia esperienza puoi usare linguaggi dinamici anche per applicazioni di medie dimensioni (e, naturalmente, ci sono persone che li usano con successo per applicazioni di grandi dimensioni). Sono d'accordo che più grande diventa la base di codice, più puoi trarre profitto dai controlli statici forniti dai linguaggi statici.

— Giorgio,

2

@Giorgio Beh, forse è perché sono dipendente dalle cose di validazione statica. È così dolce per me, e letteralmente non posso vivere senza di loro nemmeno su piccola scala: p

— Eonil

Vedo i vantaggi dei linguaggi statici (e ho valutato la tua risposta). Recentemente ho usato Python e Common Lisp e ammetto che in pratica si ottengono buoni risultati se si utilizza un design pulito e, soprattutto in Python, se si scrivono abbastanza test. Questi linguaggi possono essere molto efficaci per costruire un prototipo che può essere facilmente trasformato nel tuo codice di produzione. Ma sì, per i progetti più complessi vorrei avere tutto l'aiuto possibile, quindi preferisco un linguaggio statico.

— Giorgio,

1

Attualmente programma in linguaggi di tipo statico (C # e F #), ma mi piace programmare in linguaggi dinamici (Smalltalk, Ruby). Ci sono molti pro e contro che le persone associano a un tipo rispetto a un altro che riguardano più la lingua rispetto a quando si applicano i tipi. Ad esempio, i linguaggi dinamici di solito hanno una sintassi più chiara e concisa, tuttavia F # e OCaml con il loro sistema di inferenza del tipo hanno una sintassi pulita come qualsiasi linguaggio dinamico. E con la tipizzazione statica, hai veri e propri refactoring automatici e completamento automatico, ma Smalltalk, con il suo intero codice sorgente in un database e ogni metodo compilato separatamente, è stata la prima lingua ad avere davvero gravi refactoring automatizzati, e ha funzionato benissimo. In definitiva, i moderni linguaggi dinamici e statici oggi sono sicuri per i tipi, che è l'aspetto più importante del tuo sistema di tipi,

— jbtule
fonte

A volte ho sospettato che la tipizzazione statica sia solo una piccola parte dell'equazione di ciò che rende una lingua più o meno flessibile. Penso che anche quello che sto iniziando a capire è che molti sviluppatori preferiscono un comodo set di binari per guidarli piuttosto che avere il regno libero di fare cose assurdamente pericolose come sovraccaricare gli operatori. VS mi fa venire voglia di dare dei calci ai cuccioli a volte, ma sono stato sicuramente curioso di vedere F # e ciò che hai detto a riguardo mi rende ancora più curioso. Presumo che questo sia qualcosa di più della semplice cosa C # in cui è possibile trasmettere implicitamente un tipo più inclusivo.

— Erik Reppen,

@erik, Oh sì, più che la digitazione implicita e var: F # Tipo inferenza

— jbtule

-1

È il 2015 ora, che aggiunge alcuni frammenti interessanti alla conversazione:

Parti significative del mondo back-end aziendale stanno prendendo in considerazione o stanno iniziando a utilizzare Python (dinamico) al posto di Java (rigoroso statico)
Il mondo del frontend aziendale sta vedendo cose come AngularJS v2, basato su TypeScipt: un'estensione tipizzata di Javascript.

Quindi i ragazzi del backend sono stanchi della superflua giacca dritta della tipizzazione rigorosa, mentre i ragazzi del frontend sono stanchi del caos della tipizzazione dinamica.

Abbastanza ironico: mi chiedo se si incontreranno nel mezzo o si precipiteranno a vicenda con il boom sonoro di una scadenza che passa sopra ...? ;)

— Cornel Masson
fonte

A meno che tu non fornisca alcuna prova, direi che nel peggiore dei casi il mondo di backend sta passando a Go, ma dio proibisce qualsiasi roba dinamica. Il mito secondo cui un linguaggio di programmazione statico ha sempre molta cerimonia è stato a lungo sfatato con sistemi di inferenza più potenti e solide implementazioni REPL

— Den

Ci sono molti back-end tipizzati dinamicamente in uso su larga scala. Django in particolare è molto popolare nel giornalismo e sta gestendo i back end per la New York Times, il Guardian e il Washington Post. Walmart è in esecuzione su Node. L'unico mito è l'idea che non è possibile scrivere in scala senza tipi statici. E dopo aver trascorso un po 'di tempo a pensare ad alcuni disastri della base di codice legacy Java in cui mi sono imbattuto, penso che le persone che si sentono a proprio agio nel farlo stiano meglio se lavorano con elettricità statica o dinamica.

— Erik Reppen,

Anzi, preferirei avere un abile team Python nel mio grande progetto aziendale, anziché un povero Java. Solo per chiarire la mia posizione: ho pubblicato la risposta sopra come valutazione di

— Cornel Masson,

Anzi, preferirei avere un team di Python esperto nel mio grande progetto aziendale, piuttosto che un povero Java. Solo per chiarire: ho pubblicato la risposta di cui sopra come un'osservazione delle tendenze che sto vedendo nella mia base di clienti, rete di settore e ricerca generale. Il backend tradizionalmente rigoroso abbraccia meno rigore, frontend tradizionalmente più flessibile, di più. Non è nemmeno un'opinione su quale sia "giusto" (se presente) - non sono sicuro del motivo per cui sono stato sottoposto a downgrade. Forse l'ironia è persa ...

— Cornel Masson,