Qual è il problema reale con un progetto basato su prototipi?

But it seems like they are avoided for the creation of executable applications and of bigger projects in general. Why that?

Non lo so, ma l'ipotesi è falsa.

I progetti più grandi utilizzano linguaggi prototipo:

• JavaScript è la lingua più popolare su github.
• Cloud9 è un vero e proprio IDE basato su cloud scritto in JavaScript che si collega a GitHub . Il 98% di questo progetto è JavaScript, il 2% è CoffeScript, vai a dare un'occhiata all'origine e dimmi che è un'applicazione banale.
• Nodo , non come se non ne avessi mai sentito parlare, sembra proprio che sia il framework del server web a ciclo di eventi per la creazione di un'app Web in JavaScript.
• three.js è un 3dEngine in JavaScript. Perché, sai, non è davvero un grande progetto ...
• pdf.js
• Broadway non fa molto, decodifica semplicemente h.264 in modo nativo nel tuo browser senza codice.
• La JVM è stata implementata in JavaScript, consentendo al codice bytecode JVM di Scala, Java o Clojure di essere eseguito all'interno di JavaScript.
• Bcrypt è implementato in JavaScript.
• Uno dei migliori videogiochi di tutti i tempi è stato scritto in Lua .
• Lua è usato in molti posti.

Quanto "più grande" vuoi? Ti aspetti che qualcuno scriva un codice che emula un computer e può semplicemente prendere un ISO di Linux ed eseguire un intero sistema operativo dal tuo browser e puoi iniziare a scrivere codice da una riga di comando di Linux in C ++ ... o qualcosa di ridicolo come quello? Ok, ce l'abbiamo anche .

Seriamente, cos'è "più grande?"

Anche in questo caso, il linguaggio più proliferato su github ha portato a un IDE, un server web, un motore grafico 3D, uno strumento di rendering dei documenti PDF, un decoder video, una libreria di crittografia e un emulatore x86.

Non mi preoccuperò nemmeno di collegare l'infinità di webapp e roba nel negozio di cromo, quadri di tutte le forme e dimensioni, strumenti di analisi del codice statico o altri progetti "banali" che nessuno usa perché la lingua è solo così dolorosamente lento e non possiamo essere sicuri di come scrivere codice in esso.

Oh aspetta, possiamo essere certi di come scrivere codice di qualità in JavaScript. Si chiama leggere il divertente manuale, scrivere test unitari, analisi del codice statico e altre cose divertenti che fai in ogni altra lingua se sei competente anche in quella lingua.

Non è "rischioso" perché ha un prototipo, significa solo che devi sapere cosa stai facendo, nello stesso modo in cui hai bisogno di sapere come programmare in qualunque paradigma ti piaccia. Non è "lento" perché è un prototipo, lingue là fuori che non ho menzionato corrono a velocità quasi-C. Puoi trovare ulteriori informazioni sul tuo motore di ricerca locale.

Buongiorno.

OK, mettiamo da parte il dibattito su native vs JIT e static vs dynamic. Supponiamo di prendere per scontato che qualcuno voglia utilizzare un linguaggio JIT dinamico, come java, python o javascript. Perché scelgono una lingua con ereditarietà classica invece di una con eredità prototipale?

Il motivo principale è che javascript non è molto adatto alla programmazione di grandi sistemi e javascript è l'unico linguaggio prototipo abbastanza popolare da ottenere l'approvazione "a livello C" per un nuovo progetto. Javascript è dannoso per la programmazione di grandi sistemi perché manca un meccanismo di tipizzazione rigoroso. Nei sistemi di grandi dimensioni ci si basa su API per astrarre dettagli di implementazione. La tipizzazione rigorosa sposta la responsabilità di indirizzare correttamente le API dallo sviluppatore al compilatore. Vuoi che il compilatore faccia quel lavoro.

Un secondo motivo è dovuto al fatto che l'ereditarietà classica è ciò che la maggior parte dei programmatori conoscono e sono stati addestrati, e l'eredità prototipale è troppo strana per loro. Non sottovalutare mai i fattori di "popolarità" nelle decisioni tecniche.

Le prestazioni non influenzano la decisione. Grandi sistemi sono programmati in java ogni giorno e javascript V8 è all'incirca nello stesso ordine di grandezza delle prestazioni di java ( 3 volte più lento nei benchmark sintetici ).

Sono lenti come l'inferno. Quanto tempo pensi che ci vuole una VM JavaScript per fare una chiamata OO, rispetto a C ++? E sostanzialmente perdi tempo a inventare strutture che altre lingue ti offrono. E spero che non ti piaccia nemmeno la sicurezza del tipo.

Ho fatto un sacco di codice in Lua. Ri-inventare la ruota di classe ogni volta non era la mia idea di un buon momento. Ora lavoro in C ++ per scelta.

La flessibilità è lenta e non sicura.

A quelli che si lamentano della velocità e della scalabilità, fai queste domande:

1. Quanto velocemente deve essere. Sto parlando dei requisiti qui, non delle generalità (la pagina intera deve rispondere in una specie di dettaglio)
2. Quanti utenti useranno questo sistema ora, quanti tra 5 anni.
3. Interfaccia con altri sistemi e, in caso affermativo, come.

Le risposte alle domande di cui sopra influenzeranno notevolmente la tua decisione. Non hai bisogno della velocità del C ++ per il 95% delle applicazioni là fuori, forse di più. Per quanto riguarda la scalabilità. Meno di 1/10000 dell'1% delle applicazioni sarà mai scalabile a livello di google / ebay / amazon. La maggior parte, probabilmente meno dell'1% si ridimensiona al punto che hai più di 100 richieste al secondo, anche in azienda.

Ora se lavori per dire AOL o Google, allora probabilmente la velocità e la scalabilità sono importanti, per il resto di noi, non così tanto, è molto più importante averlo fatto e farlo velocemente il minor costo possibile.

Non penso che ci sia qualcosa di fondamentale, ma in javascript in particolare ci sono alcuni problemi che possono causare problemi nel software su larga scala:

1. L'incapsulamento è debole: è molto semplice per qualsiasi altro codice ispezionare e modificare qualsiasi altro codice. Ciò consente alcune cose potenti, ma può anche portare a problemi in grandi progetti. È difficile trovare bug che possano accadere se accidentalmente passi ad un codice che non è tuo.

2. convenienza sulla sicurezza: js ha caratteristiche come arguments.callee che permettono a qualsiasi funzione di richiamare tutto lo stack e accedere all'oggetto root (finestra in un browser). Ciò significa che devi davvero fidarti di qualsiasi codice di terze parti che chiami. Questo non è un problema per ogni applicazione, ma limita ciò che puoi fare (la modalità rigorosa lo risolve, ma non può essere invocato in un contesto del browser)

3. tutto ciò che è numerico è estremamente complicato: ogni numero è un float, che è probabilmente la scelta giusta se si ha solo un tipo di numero, ma si ha a che fare con i dati binari e l'intero aritmetico scomodo.

4. lo standard di stampa richiesto per lo stile tipico di Oo: è fantastico che tu possa creare una libreria che implementa le classi in javascript, ma in fondo ne avrai bisogno, e tutti i nuovi avranno bisogno di imparare il particolare libreria che usi.

Nessuno di questi uccide javascript per progetti di grandi dimensioni, e tutte le lingue hanno i loro svantaggi: questi sono solo alcuni aspetti da tenere presente durante l'utilizzo di js. Usando le nuove funzionalità di js e mirando solo ai moderni motori js (v8 per esempio), che puoi fare per un'app standalone, puoi evitare alcuni di questi problemi. Gli strumenti esterni possono anche fornire un aiuto (ad esempio il compilatore di chiusura di google esegue varie forme di controllo statico).