Newsgroup: it.lavoro.informatica
Titolo: Linguaggi Ad Oggetti e Funzionali

Sono il solo a cui sembra che il vento stia tirando verso i linguaggi
funzionali? Da tanti piccoli indizi, tipo alcune varianti della
sintassi di Ruby, lo stile di programmazione di Linq etc.. ho sempre
di piu' l'impressione che il mondo della programmazione stia
gravitando lentamente dall OO  verso lo stile funzionale...voi cosa ne
pensate?
E se voleste "portarvi avanti" studiandovi un linguaggio funzionale,
da dove partireste?


L'impressione è giusta, ma la cosa è LUNGI dal divenire realtà, sfortuna-
tamente.
Se vuoi imparare, parti da Haskell.
-- 
|_|0|_| - Salvatore Iovene
|_|_|0| - Website:  
http://www.iovene.com/
|0|0|0| - Key:      
http://www.iovene.com/pubkey.asc
------- - Webcomic: 
http://geekhero.iovene.com/


wrote:

grazie del parere.. e se dovessi riassumere i vantaggi dello stile
funzionale su quello ad oggetti cosa diresti?

 funzionale su quello ad oggetti cosa diresti?
Sinteticità e solidità. Meno codice, meno errori, meno bug, migliore
mantenibilità.


 pensate?
Io penso che sarebbe un tornare indietro. Allora qualcuno dovrebbe
spiegarmi il motivo per farlo.
-- 
Ciao!
Luca

 migliore mantenibilit�.
Però è anche vero che la sinteticità si costruisce su strati
software superiori in numero. Non so, forse dico una bischerata io, ma
non è che se capisci bene la OOP e come va applicata, poi scopri che
de facto è il sistema migliore proprio per scrivere cose solide?
-- 
Ciao!
Luca


Guarda che stiamo parlando di funzionale vs OO, non di procedurale verso OO.


lo stile di programmazione di Linq etc..
Secondo me hanno fatto una schifezza immonda con Linq, forse non c'era
alternativa, non lo so, ma il risultato è una sintassi troppo poco
chiara ed immediata.

 verso OO.
I know. E personalmente se è una novità (che poi più di tanta
novità non è, visto che si parla ad esempio di LISP, 1958) cosi' a
pelle continuo a preferire la OOP. Ma forse perché non sono ancora
stato folgorato sulla via di Damasco...
-- 
Ciao!
Luca

 da dove partireste?
Io avevo provato ad iniziare con O'caml, ma non ho fatto grandi
progressi.
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 mantenibilità.
..piu' parentesi tonde... ;-p
A parte gli scherzi: perche dici sinteticita'?
I miei ricordi di linguaggi funzionali  sono molto lontani nel tempo
(ai tempi dell'uni), ma non mi sembra fossero particolarmente
sintentici.
Diversi si; sintetici credo di no.
Sicuramente sono piu' sintetici di Java (nel senso di meno verbosi,
meno rompipalle) ma non mi sembra che con un funzionale tu riesca a
scrivere codice piu' velocemente che con un linguaggio OO.
Pero', come ho detto, sono valutazioni basate su ricordi lontani nel
tempo.
Bisognerebbe avere la fortuna di usarli tutti e due per lavoro, per
capire quale e' il "migliore".
Ciao,
Nonnu.

 A parte gli scherzi: perche dici sinteticita'?
Un programma scritto in Haskell è dalle 2 alle 10 volte più corto
dello stesso programma scritto in C++, in genere.


 pensate?
I linguaggi funzionali sono una cosa molto particolare, in quanto quello 
funzionale è un paradigma che non ha una relazione diretta con la realtà, al 
contrario di altri: viene naturale pensare ad una serie di passi da compiere 
in sequenza (programmazione procedurale), o ad un insieme di oggetti legati 
fra di loro con modelli base da cui creare entità specifiche (programmazione 
ad oggetti), o addirittura ad una serie di dati organizzati in una struttura 
tabellare (database relazionali), ma viene molto meno naturale pensare ad un 
linguaggio dove non ci sono sostantivi ma solo verbi; si tratta di un 
approccio allo stesso tempo di basso livello (occorre definire ogni cosa 
passo per passo) ed estremamente astratto, e tutto sommato ben poco 
naturale: tant'è vero che per imparare davvero a usare un linguaggio 
funzionale occorre molto più allenamento che per altri tipi di linguaggio.
Detto questo, i linguaggi funzionali sono estremamente potenti, e vale 
sempre il discorso che un buon programmatore dovrebbe conoscere più "modi" 
di programmare possibili, sia per avere maggiori strumenti a disposizione 
che, soprattutto, per espandere la propria forma mentale.
Quanto alla tua osservazione, non credo che i linguaggi funzionali si stiano 
diffondendo particolarmente, oppure che altri linguaggi stiano via via 
migrando verso un approccio funzionale; si tende piuttosto ad inserire nei 
linguaggi "classici" alcune strutture sintattiche proprie di quelli 
funzionali, ma che si prestano bene ad essere inserite in altri contesti (si 
pensi ai metodi anonimi in C# o alle classi anonime in Java); questo non 
significa che quei linguaggi stiano diventando funzionali, ma solo che 
stanno integrando idee valide provenienti da ambienti diversi.
Massimo

 da dove partireste?
Io ho cominciato da Lisp/Scheme.

 A parte gli scherzi: perche dici sinteticita'?
Se parliamo di Lisp/Scheme, praticamente non hai dichiarazione
esplicita di variabili. Tutto è rappresentato da liste, anche il
programma.
Perciò ti risparmi tutta la digitazione delle dichiarazioni, cosa che
io trovo ottima. Questa uniformità, ovviamente, ha lati positivi ma
anche negativi (es. la gestione automatica della memoria del programma
è meno efficiente senza i tipi espliciti, meno controlli in
compilazione, ecc.).
PS: esiste anche la versione Lisp/Scheme ad oggetti, per chi non vuole
rinunciarci

 la realtà, al contrario di altri: 
Come fai a dirlo? In Lisp concateni le funzioni proprio come faresti in
matematica: (f3 (f2 (f1)) -> f3 usa l'out di f2, che usa l'out di f1.
Più chiaro e naturale di così!

 Io ho cominciato da Lisp/Scheme.
Puoi consigliarmi qualche testo introduttivo su Lisp?
Ciao e grazie,
Giulio
-- 
OnAir:
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 Puoi consigliarmi qualche testo introduttivo su Lisp?
Domanda difficile! :-) Pensa che le prime informazioni le ho lette su
un vecchio articolo introduttivo su Le Scienze (forse di Martin
Gardner).
Prova "Guida all'uso del linguaggio Lisp" di Quennec, Franco Angeli ed.
E' molto rigoroso (e quindi piuttosto ostico).


Se ti accontenti dello Scheme (che e' un dialetto lisp) c'e' l'ottimo:
Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book.html
Ciao,
Nonnu.
PS:forse non e' proprio introduttivo ma e' fatto bene.

 ha scritto nel messaggio 
news:489328de$0$18156$4faf...@reader3.news.tin.it...

Esatto: come faresti in *matematica*. Io parlavo della nuda e cruda realtà, 
però ;-)
Un programma procedurale o a oggetti può rappresentare benissimo cose come 
contabilità, programmi da ufficio, videogiochi, mailserver e applicazioni 
web.
Ma come rappresentare un'architettura e una struttura applicative in un 
programma funzionale?
Massimo

 un programma funzionale?
Se conosci i diagrammi DFD (flusso di dati), usati nella modellazione
di molte applicazioni gestionali, ti viene assolutamente spontaneo
rappresentarli con catene di funzioni: l'attività A emette il dato A1;
l'attività B legge A1 ed emette B1, ecc. Facile rappresentarlo con: (B
(A)).
Ovviamente ci sono sempre eccezioni, procedimenti non facilmente
rappresentabili.
A parte che un normale progettista/programmatore non si dovrebbe
trovare in difficoltà con concetti matematici elementari come le
funzioni... :-)

 Structure and Interpretation of Computer Programs
Sì, lo Scheme è molto più compatto di Lisp. Lo standard è di 50-100
pagine, contro 1000 e più del Lisp.
E' anche vero che certi semplici interpreti Lisp, che comprendono solo
le funzioni di base (10-20), sono stati estesi enormemente scrivendo
direttamente con quelle poche funzioni di base un gran numero di altre
funzioni previste dallo standard.
E' una cosa molto sorprendente, e dimostra la potenza del linguaggio.
 

 funzioni... :-)
Nessun problema a capire e usare le funzioni, ma qualche problema a usare 
solo quelle per rappresentare qualsiasi cosa direi che può sorgere...
Massimo

 funzioni... :-)
Non fosse altro perché sono la base, anche dell programmazione
strutturata.
-- 
Ciao!
Luca

 sorgere...
Stessa cosa per la programmazione procedurale e quella ad oggetti.
Niente di nuovo sotto il sole... :-)

 ancora imbattibile.
Come dicevo, certamente ci sono campi dove la traduzione in ling.
funzionale mi sembra veramente semplice. E ce ne sono altri dove questo
è meno facile, ma come in tutti i paradigmi.
Sul fatto che la OOp sia di sua natura più manutenibile ho i miei forti
dubbi. Pensa alla difficoltà di ricordare i dettagli di decine di
classi, con errori di digitazione scopribili solo a runtime (in parte).
Certo questo viene superato con gli aiuti dati dalle moderne IDE. Ma se
le stesse IDE ci fossero state ai tempi del Pascal o del C, magari le
cose sarebbero diverse... :-)
Alla fin fine anche tu dici che un OOP "fatto un attimo decentemente" è
ben manutenibile, ma lo stesso si può ben dire per un buon programma
procedurale.
 

 cose sarebbero diverse... :-)
 
"Ai tempi del C"?


 Stessa cosa per la programmazione procedurale e quella ad oggetti.
Uh, no, dissento.
La programmazione procedurale è basata sul concetto "quali sono i passi da 
fare?", mentre quella ad oggetti su "quali entità ci sono in gioco e come si 
relazionano fra loro?"; due schemi interpretativi ognuno con i propri 
limiti, ma senz dubbio abbastanza vasti per poter rappresentare situazioni 
reali.
Dover descrivere tutto in termini di funzioni, invece, mi sembra molto più 
astratto.
Massimo

 funzioni, invece, mi sembra molto più astratto.
Sì, infatti, sembra. Perchè in fondo quando chiami un metodo OO od una
funzione (guarda caso... :-) procedurale non fai una cosa così
enormemente diversa dalla programmazione funzionale.
Questione di abitudine, a mio parere.  

 ha scritto nel messaggio 
news:4894cf17$0$40311$4faf...@reader5.news.tin.it...

Ovviamente, sia i linguaggi procedurali che quelli ad oggetti possiedono le 
chiamate di funzione; e ci mancherebbe altro :-)
Però le funzioni sono, appunto, una parte dello schema generale; una parte 
che, unita alle altre (variabili, strutture, oggetti, etc.), consente di 
rappresentare all'interno di un programma una certa situazione.
Ma se hai a disposizione solo le funzioni, come fai?
Non dico che non si possa, eh. Dico solo che, per rappresentare in termini 
di funzioni un qualsiasi problema, c'è bisogno di molte più "pippe 
mentali"... e non è detto che alla fine ci si riesca.
Per esempio, mi viene piuttosto difficile rappresentare un qualsiasi 
videogioco in termini di programmazione funzionale...
Massimo

Massimo ha scritto:

All'università usammo CAML che se non ricordo male deriva da ML. Ora ML 
è un meta-linguaggio e proprio per questo si rivelò molto adatto a 
creare interpreti di altri linguaggi. per come lo ricordo credo si 
presti bene alle problematiche di intelligenza artificiale o all'analisi 
di stringhe. Alla fine come tutti i linguaggi va bene per alcune cose e 
  meno per altre. Di fatto credo che le difficoltà del paradigma siano 
assimilabili a quelle affrontate nel passaggio da procedurale a OO.
Ho ripreso i manuali di CAML quando mi hanno chiesto di prendermi in 
carico un progetto per un parser e allora molti mi consigliarono Haskell 
che rispetto a Caml è decisamente più rigoroso. Caml infatti consentiva 
anche la programmazione imperativa.
Sarebbero tutti argomenti interessanti peccato che il tempo non ci sia 
mai...

 mentali"... e non è detto che alla fine ci si riesca.  
Io mi stupisco sempre pensando che le centinaia di differenti linguaggi
di alto livello, procedurali, OO, funzionali, ecc., alla fine sono
tutti basati su un linguaggio stravecchio come l'assembler, a malapena
procedurale...
Quindi in fatto di "pippe mentali" ce ne facciamo tutti veramente
molte! :-)

 procedurale...
Già, ma purtroppo è un po' difficile farsi capire da un computer senza 
usarlo ;-)
Del resto, ci sono intere città basate sui mattoni... tutto stà in come 
vengono montati :-)
Massimo