Erlang

[Valeriano Manassero]

poi ripeto, Erlang non è proprio OOP eh

Ecco, senza analizzare manco il resto (su cui avrei da aggiungere visto dall'"alta sponda" ma me ne sta mancando la voglia), questo è più che sufficiente a renderlo del tutto inadeguato per il classico sviluppo web odierno.
Ripeto: avrà ottime nicchie su cui essere applicato, ma il web proprio no.

[andrea.paiola]

Ecco, senza analizzare manco il resto (su cui avrei da aggiungere visto dall'"alta sponda" ma me ne sta mancando la voglia), questo è più che sufficiente a renderlo del tutto inadeguato per il classico sviluppo web odierno.
Ripeto: avrà ottime nicchie su cui essere applicato, ma il web proprio no.

mi pare una visione moooolto semplicistica

[Valeriano Manassero]

mi pare una visione moooolto semplicistica

Perdona la franchezza, ma se articolo il discorso mi dici che non capisci, se taglio corto sono un semplicista, lol.
Il fatto è che, ovviamente, ne io ne te conosciamo a fondo tutto l'"ambaradan" e parlarne solo per dare aria alla tastiera non è mio uso. Ci fosse un esperto di Erlang nel forum almeno potrei avere informazioni dettate dall'esperienza.
Pace, credo continuerò a dormire la notte

[andrea.paiola]

Perdona la franchezza, ma se articolo il discorso mi dici che non capisci, se taglio corto sono un semplicista, lol.
Il fatto è che, ovviamente, ne io ne te conosciamo a fondo tutto l'"ambaradan" e parlarne solo per dare aria alla tastiera non è mio uso. Ci fosse un esperto di Erlang nel forum almeno potrei avere informazioni dettate dall'esperienza.
Pace, credo continuerò a dormire la notte

Bravo

se hai tempo magari rispondi nel merito... se non ci sono oggetti non sei felice insomma... se ho capito bene eh...
se ti "spaventa" la ripetizione di codice ti informo che anche nella programmazione funzionale esistono delle modalità per generalizzare le funzioni e, sempre se ti interessa, posso mostrarti la documentazione o portare esempi ( non troverai le questioni proprie della programmazione OOP tipo l'ereditarietà, ovviamente )

[Valeriano Manassero]

Bravo

se hai tempo magari rispondi nel merito... se non ci sono oggetti non sei felice insomma... se ho capito bene eh...
se ti "spaventa" la ripetizione di codice ti informo che anche nella programmazione funzionale esistono delle modalità per generalizzare le funzioni e, sempre se ti interessa, posso mostrarti la documentazione o portare esempi ( non troverai le questioni proprie della programmazione OOP tipo l'ereditarietà, ovviamente )

Non è che un linguaggio di programmazione deve soddisfare e generare la mia felicità, ma se dai uno sguardo al mondo esterno vedrai che lo sviluppo ad oggetti ha un potenziale notevolmente più forte rispetto al funzionale, non è un caso che la tendenza generale sia questa.
L'ulteriore sviluppo sta nella programmazione ad aspetti che è comunque figlia della OOP. Certo che nel linguaggio funzionale puoi raggruppare il codice, bella scoperta, ma come tu stesso hai detto, manca l'ereditarietà (ovvero il tratto caratteristico che fa la differenza).
Se proponessi *oggi* lo sviluppo in un linguaggio funzionale ad un qualsiasi mio cliente, con ogni probabilità verrei preso a calci in culo (giustamente).
E' chiaro che stiamo parlando di web app, per questo ti dico che erlang e similari non mi hanno affatto stupito dalla descrizione che mi hai fatto, semplicemente non li vedo all'altezza. E come Il Borro ti ha fatto notare, in alcuni ambiti specifici è un'ottima soluzione (lo dicevo anche mi).

[andrea.paiola]

Se proponessi *oggi* lo sviluppo in un linguaggio funzionale ad un qualsiasi mio cliente, con ogni probabilità verrei preso a calci in culo (giustamente).

ma che clienti hai? ( non sono ironico )

di che contesto parli?

[Uno]

Se devo fare un'applicazione con database geograficamente distribuita o scrivere un O.S. per domotica su kernel Linux o altro... un pensierino ce lo farei...

Anche un software per comunicazioni che regge bene anche su hardware non eccelsi tipo il server jabber ejabberd

[andrea.paiola]

Anche un software per comunicazioni che regge bene anche su hardware non eccelsi tipo il server jabber ejabberd

certo! ^^

[andrea.paiola]

ecco è uscito un interessantissimo articolo che mi pare riassumere bene un po' tutti i punti di forza e le difficoltà di Erlang

Conclusioni

"Ha senso, per me, imparare Erlang?" Questa è la domanda che mi sono posto quando è diventato impossibile ignorare i bip sul radar, e prima di questo esercizio. Penso che una persona esperta sia di Python che di C/C++ abbia le spalle coperte per la stragrande maggioranza delle necessità di sviluppo: sia di sistemi grandi ed articolati che di sistemi che richiedono elevate prestazioni (chi è esperto del linguaggio e della piattaforma Java potrebbe pensarla allo stesso modo).
Erlang va a ricoprire una nicchia di utilizzo molto peculiare: quella dei sistemi fault-tolerant e distribuiti (che tipicamente sono distribuiti per essere fault-tolerant, ma potrebbero esserlo anche per necessità di bilanciamento del carico e di scalabilità): implementare una simile soluzione in qualunque altro linguaggio consisterebbe di fatto nel ricreare un sottoinsieme del runtime già disponibile e testato per Erlang, per creare ad esempio gli alberi di supervisione che invece in Erlang sono pattern fondamentali di architettura. La maniera pressoché nativa in cui è possibile effettuare distribuzione del carico è qualcosa di cui avrei beneficiato largamente in alcuni progetti a cui ho lavorato in passato, e che comunque sono stati costruiti in stile message passing proprio perché non è così facile distribuire lo stato: avere nel linguaggio stesso (e non nel framework di deploy) le primitive per far sì che un problema possa scalare in maniera semplice aumentando hardware è una cosa che mi farebbe dormire tranquillo anziché impazzire di micro-ottimizzazioni.
Accettato Erlang come linguaggio utile, lo si può definire facile? Probabilmente avvicinarsi ad Erlang è più difficile che avvicinarsi a qualunque altro linguaggio imperativo: ricorsione al posto dell'iterazione, pattern matching e clausole multiple come principale meccanismo di scelta... il salto di paradigma è davvero lungo, e non nego che aver studiato il Prolog mi abbia aiutato all'inizio. Ma visto che il message passing è un paradigma architetturale solido ed indipendente dal linguaggio, non mi sembra una cattiva occasione quella di sperimentarlo in un linguaggio che non accetta compromessi.
Per me è stato di stimolo anche un famoso aforisma di Alan Perlis:

un linguaggio che non influenzi il tuo modo di pensare alla programmazione non vale la pena di essere conosciuto.