Linguaggi dinamici vs tipicamente statici per siti Web [chiuso]

Questa affermazione suggerisce che le lingue tipizzate staticamente non sono ideali per i siti Web:

Lo contrasterò con la costruzione di un sito Web. Durante il rendering di pagine Web, spesso sono presenti molti componenti che interagiscono su una pagina Web. Hai pulsanti qui e piccoli widget laggiù e ce ne sono dozzine su una pagina Web, così come forse dozzine o centinaia di pagine Web sul tuo sito Web che sono tutte dinamiche. Con un sistema con una superficie molto ampia come quella, l'uso di un linguaggio tipicamente statico è in realtà abbastanza flessibile. Troverei doloroso probabilmente programmare in Scala e renderizzare una pagina web con essa, quando voglio spingere interattivamente i pulsanti e cosa no. Se l'intero sistema deve essere coerente, come l'intero sistema deve digitare check solo per poter spostare un pulsante, penso che possa essere davvero poco flessibile.

^{Fonte: http://www.infoq.com/interviews/kallen-scala-twitter}

È corretto? Perché o perché no?

Non sono assolutamente d'accordo. Man mano che i sistemi diventano più grandi, i linguaggi tipizzati staticamente garantiscono robustezza a livello di componente e quindi flessibilità a livello di sistema.

Inoltre, l'esempio fornito dall'autore non ha davvero senso. Sembra piuttosto che questo ragazzo non sappia che il polimorfismo può essere ottenuto con mezzi diversi dalla tipizzazione delle anatre.

Ci sono un certo numero di persone che affermano che i linguaggi dinamici sono superiori, ma di solito si basano sulla loro mancanza di esperienza con i sistemi di tipo espressivo che supportano ad esempio sottotipi strutturali, tipi di dati algebrici e funzioni del primo ordine.

Prima di tutto, tieni presente che l'autore della suddetta dichiarazione parla dello sviluppo del sito web. Quindi è preoccupato per lo sviluppo della presentazione , ed è lì che pensa che Scala non sarebbe una buona scelta ...

Detto questo, ho una buona esperienza con lo sviluppo web. Ho lavorato per almeno 8 anni esclusivamente con esso, di cui 5 in agenzie digitali.

E, sì, nella mia esperienza un linguaggio compilato staticamente e digitato a livello di presentazione può essere un grosso ostacolo. Il contenuto deve essere modificato costantemente, molto più spesso dei requisiti aziendali. E di solito questo deve essere fatto da un team distinto (gli sviluppatori "front-end"). Normalmente sanno molto su HTML, JavaScript, standard web, CSS, ma non molto sui linguaggi lato server come Java e C #. Suppongono inoltre che qualsiasi tipo di modifica in un modello sia immediatamente disponibile; non vengono utilizzati per compilare e digitare errori. E hanno ragione: i linguaggi tipizzati staticamente sono ottimi per requisiti difficili e complessi, come l'accesso ai dati e le regole aziendali, ma non altrettanto buono per lo sviluppo dell'interfaccia.

Questo è, in effetti, uno dei principali vantaggi dell'utilizzo di un linguaggio di template specializzato e interpretato come Velocity . La sua facilità d'uso, potenza e flessibilità sono adeguate per gli sviluppatori del livello di presentazione. E poi i ragazzi lato server sono liberi di usare un linguaggio serio, tipicamente statico, ovunque ...

Tuttavia, concordo anche sul fatto che Scala sia leggermente diversa. Essendo allo stesso tempo molto meno prolisso e molto più espressivo di Java, credo che potrebbe essere usato per lo sviluppo di presentazioni, quindi forse potrebbe essere usato con successo come linguaggio modello. E se anche potesse essere combinato con un framework come Play (che compila il sito web automaticamente dopo ogni modifica), potrebbe essere un IMHO vincitore. Tuttavia, anche Play ha optato per un linguaggio modello (dinamico) simile a Groovy, che non è un buon segno.

Per riassumere: il problema con Scala è molto più legato al fatto che è stato compilato. In effetti il ​​suo meccanismo di inferenza del tipo ti fa quasi dimenticare che è anche tipizzato staticamente.

(E scusami per il mio inglese. Fammi sapere se qualcosa non è chiaro, proverò a sistemarlo.)

Penso che il testo (e la maggior parte delle risposte) stiano mescolando lingue tipicamente statiche e lingue eccessivamente dettagliate . Naturalmente, l'intersezione è molto grande (specialmente se si considerano solo le lingue più tradizionali); ma ci sono alcuni esempi interessanti di linguaggi non verbosi, tipicamente statici: Go, Haskell, Scala, Rust ...

Ti incoraggio a leggere la tipizzazione forte di Bruce Eckel contro i test forti . L'argomento principale è che la qualità del software si riduce ai test. Puoi testare in molti modi diversi. I compilatori verificano alcune cose in fase di compilazione: prova a memorizzare una stringa in una variabile int e probabilmente ti abbaia. Nei linguaggi dinamici, molti test si verificano in fase di esecuzione. In definitiva, non importa quando si verificano i test. Deve solo succedere. A che ora si guadagna non compilando in linguaggi dinamici si perde il test in fase di esecuzione. Metti alla prova tutto, giusto?

Detto questo, una preferenza per i linguaggi compilati con sistemi di tipo rigidi rispetto ai linguaggi dinamici è proprio questa: una preferenza. Un po 'come pugili contro slip o infradito contro mutandoni francesi. Non esiste una risposta giusta o sbagliata. Indossali con l'atteggiamento giusto e c'è solo fantastico.

Sono d'accordo con questo nella maggior parte dei casi, perché, ammettiamolo, quando si tratta di clienti su una piattaforma web, la flessibilità è un must.

I linguaggi digitati staticamente sono più robusti e sicuri di quelli tipicamente dinamicamente, ma quando inizi ad adattare il codice per agire in un modo che non era previsto e ne hai bisogno in fretta, le soluzioni sembrano un po 'complesse e rigide.

Quindi, se hai la possibilità di unire le tecnologie, consiglierei di creare un core in un linguaggio tipicamente statico (core non cambia molto) e usarlo dinamicamente per l'interazione dell'utente.

Penso che l'autore di questo post non abbia esaminato lo stesso Scala. Mentre sono d'accordo che Java e C # hanno dei limiti e sono un po 'poco flessibili per lo sviluppo web, Scala è un linguaggio tipicamente statico che è abbastanza diverso da quello che pensi normalmente quando lo senti. Scala consente anche la digitazione di anatre come una versione sicura del patching delle scimmie (attraverso conversioni implicite). Ciò rende la programmazione delle librerie un po 'più complessa perché dovrai pensare ai tipi, ma se usi solo una libreria come Lift, ti sembrerà un linguaggio dinamico, tranne che il compilatore ti informerà su ovvi bug in cui non lo usi giusto. Personalmente penso che il framework di ascensore web non debba nascondersi dal rubino su binari o simili. Dai un'occhiata agli esempi di codice qui o quie decidi tu stesso. Mi sto sviluppando da un po 'di tempo ormai e non ho mai avuto una situazione in cui ho avuto un errore di tipo e anche se "Ah amico, se questo fosse dinamico avrebbe funzionato" ... perché se fosse dinamico non mi avrebbe detto che si è verificato un errore fino a quando non si è bloccato durante l'esecuzione.

Personalmente penso che ciò che dicono sia vero per qualsiasi sistema, non solo per i siti Web. Avrai bisogno della digitazione statica quando parli con l'hardware, poiché qualsiasi altra cosa la digitazione dinamica ha gli stessi inconvenienti e benefici, indipendentemente da ciò che fai, in realtà, e ciò che è meglio dipende dal gusto e dai problemi specifici di ciascun progetto.

Risposta rapida pratica: dipende dalla dimensione e dalla complessità della dimensione del web. Piccolo sito Web, progr dinamico. lang., Sito Web complesso di grandi dimensioni, progr statico. Lang.

Risposta noiosa estesa: molti sviluppatori insistono sul fatto che un sito Web debba essere realizzato con un progresso dinamico. Langr. ma la verità è che, alla fine, gli strumenti di sviluppo web tendono ad usare o emulare linguaggi tipizzati statici.

Ho lavorato più volte con PHP e, prima o poi, abbiamo dovuto aggiungere un sacco di codice che verifica i tipi di dati dati, implicito in un progresso tipizzato statico. Lang.

Digitato Lagn. aiuta anche l'uso di IDE, che richiede molta verifica del tipo.

(portato dal tuo vicino prog. & designer del compilatore ;-))

Sono abbastanza d'accordo. Quando guardo la maggior parte del codice C # del front-end Web, c'è un sacco di casting dalle stringhe e serializzazione dei dati alle stringhe. Fondamentalmente, HTTP come protocollo si adatta bene ai linguaggi dinamici.