FabioBuono ha scritto:
Non sono molto d'accordo, anche ocaml o lisp sembrano linguaggi del cavolo ma ci si fanno applicazioni mission critical e molto altro...
Del tutto marginali, di supernicchia
Allo stesso modo javascript nel suo essere estremamente facile permette di fare cose molto complesse e non banali...
Mah. Si possono fare cose complesse con qualsiasi idioma, perfino Fortran e Cobol. E' un mezzo, non un fine.
per certi aspetti quasi programmazione funzionale. Che è molto usata, pensa al nucleo di autocad, di mathlab, e così via...
Mah al quadrato. Di nuovo si tratta di supernicchie, una goccia nell'oceano
Quindi anche per me il futuro è funzionale, perché già ora il paradigma funzionale sta entrando ogni giorno di più...
Come dice Yoda è difficile prevedere il futuro: mi pare assai probabile cge non sarà altro che C, o cugini vari del C.
Per quanto riguarda mongo e i database NoSql in generale, è il contrario, ci lavorano aziende enormi, guarda questa lista
https://www.mongodb.com/who-uses-mongod
E questi sono solo gli utenti mongodb,
Facebook per esempio usa questo
Insomma i fatti dicono che i NoSql sono e saranno sempre più usati.
I fatti dicono che NoSQL, e mongodb in particolare, non serve/no praticamente a nulla, se non per ambiti superridotti e di nicchia.
Un forum come questo, tanto per dire, non funziona con mongo.
facebook usa mysql e "cugini vari" da una vita, così come wikipedia eccetera.
ed ha richieste (facebook) del tutto banali, rispetto ad esempio a quello ryanair (ho appena prenotato un biglietto, lo menziono per questo motivo)
Nessun sito che abbia il sia pur minimo requisito di consistenza usa, userà, potrebbe usare, nosql e mongodb in particolare.
Insomma... è solo questione di conoscerlo, e usarlo, quando possibile e corretto. Cioè in 1 caso ogni milione.
Però è certamente vero che javascript non sembra un linguaggio tanto espressivo e quasi nessuno lo usa davvero in modo tale. Ma il problema non è del linguaggio ma del fatto che è usato da tanta gente che non sa usarlo. Anche lisp, quello originale non sembra espressivo e potentissimo a un'occhiata poco attenta.
Difficilmente si può sostenere che LISP abbia avuto successo, così come la programmazione funzionale e - addirittura - il mondo "a oggetti-finti" (C++, C#, Java)
Sono le classiche "mode" che ciclicamente si vedono, almeno dal 1985.
Difficilmente vedremo mai un kernel linux in Javascript, o un rsync in lisp.
O un sito di booking di voli con mongodb.
Come saprai mongo non fa nessun genere di join: anche solo mettere un collegamento in un documento json a "qualcosa di diverso", tipo banalmente l'elenco dei messaggi postati, è praticamente impossibile.
Così come individuare univocamente gli elementi del blobbone JSON (cioè capire banalmente se i dati inseriti sono duplicati o no, insomma ri-normalizzarli).
L'unico ambito in cui funziona bene è quello di memorizzazione di un documento json con una chiave di ricerca, e non si ha alcuna necessità di informazioni attendibilmente serbate.
Fine.
Per tutto il resto... è inutile (più precisamente deleterio).
Ci si accorge di questo fatto non appena si usa mongodb per un qualche progetto non banale, con i suoi limiti enormi.
In sostanza mentre con SQL "canonico" puoi fare grosso modo tra il 90% e il 100% di quello che puoi fare con mongo (a seconda dei casi), con quest'ultimo puoi fare lo 0,1% di quanto normale, banale con i "classici" RDBMS.
Insomma attenzione al classico "fa fico, non so cosa significhi di preciso, "tutti" (mio cuggino?) dicono che è fico, quindi sarà fico per forza, lo usa pure facebook (!)".
Buzzword, o snakeoil.
Purtroppo anche ggente ipoteticamente formata, quando non conosce questi strumenti, incappa nell'errore devastante di usarli inappropriatamente.
Per poi tornare a SQL "normale", o (nel caso) a Postgres col suo "ibrido-json" (per gli amanti di queste situazioni, cioè in sostanza chi non sa progettare abbastanza bene i db fin dall'inizio), che praticamente fa tutto quello che fa mongo, ma molto più affidabilmente
... o magari per andare di CassandraSE, cioè usando un RDBMS "cugino di MYSQL" (cioè mariadb) per fare tutto, TRANNE quello per il quale un cluster cassandra è più adatto (cioè pochissimo)