Newsgroup: it.comp.programmare
Titolo: Funzionale = Procedurale?

Salve,
Che differenza c'è tra programmazione funzionale e procedurale?
La procedurare è quella adottata in C/Pascal etc.. giusto? E quella 
funzionale? Centra qualcosa con quella strutturata?
Grazie
-- 
Luigi
Email: 
cybe...@email.it


da quello che ne so io funzioni e procedure sono la stessa cosa, ma in
alcuni linguaggi si dichiarano function ed in altri procedure.
Mi viene in mente che forse c'è una piccola differenza nel
passagio/ritorno dei parametr .
Ciai

 wrote in message
news:3c87be79...@news.tin.it...

Negativo. La programmazione funzionale è quella di linguaggi come il
Lisp e si basa sui principi del lambda calcolo.
--
Andrea Ferro
IHHC - Member of HT-Group  DVD Authoring operator  Fan of I.Asimov
C++ Master: 
http://www.brainbench.com/transcript.jsp?pid=2522556
This post expresses personal opinions which may or may not be the
opinions of the company(s) I work for. I speak for myself only.

 passagio/ritorno dei parametr .
Si, questo lo so, cmq le procedure non ritornano valori. Per il resto sono 
uguali. Era solo dal punto di vista della "filosofia di programmazione"
ciao
-- 
Luigi
Email: 
cybe...@email.it

 Lisp e si basa sui principi del lambda calcolo.
Ecco, immaginavo, allora mentre siamo in tema, quella strutturata è quella 
dove l'utente può definire nuovi tipi di dato?
Ciao
-- 
Luigi
Email: 
cybe...@email.it

Lisp e si basa sui principi del lambda calcolo.
Andrea, non è che magari hai qualche buon link riguardante il Lisp?
calcola che io utilizzo Win2k...
Grazie
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com

funzionale? Centra qualcosa con quella strutturata?
La programmazione funzionale e' quella basata sui linguaggi
funzionali (LISP, Forth, Scheme, Haskell, ecc...) per i
quali, cioe', il programma e' una funzione estremamente
specializzata, che invoca altre funzioni definite
nell'ambiente.  Nel caso della programmazione procedurale
(C/Pascal/Fortran, ecc..), invece, un programma e' un
insieme di istruzioni che si susseguono e puo' essere
composto in blocchi detti procedure e funzioni.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

 nell'ambiente.  
Io direi invece, con sfumatura un po' diversa, che la programmazione
funzionale (FP) e` un paradigma alternativo a "programmazione
procedurale", "programmazione a oggetti" (OO), "programmazione
generica", e cosi` via.  In FP si costruiscono funzioni componendo
altre funzioni ("funzioni d'ordine superiore") e non ci si basa sulla
modifica dei dati ma sul calcolo di risultati a partire da argomenti.
Esistono linguaggi specializzati (Haskell, ML, Erlang, ...) i quali
supportano FP come principale paradigma (nello stesso senso in
cui ad esempio Smalltalk supporta OO), ed esistono linguaggi
multiparadigma che hanno FP fra i loro paradigmi direttamente
supportati (Lisp e Scheme, certo, ma anche Python).  Forth, non
particolarmente.  Coplien, in "Multi-paradigm DESIGN for C++",
mostra come impostare un programma multi-paradigma in C++
che usa FP accanto ad altri paradigmi (C++ non supporta FP
particolarmente bene, non cioe` altrettanto direttamente di quanto
supporti programmazione procedurale, OO e generica, ma non
impedisce di "sintetizzare" impostazioni FP per certi scopi).
Esempio tipico: un quicksort elementare.  Nell'impostazione
procedurale o a oggetti si pensa subito in termini di "modificare
l'array passato come parametro cosi` che sia sortato".  In una
impostazione funzionale non si pensa neppure a modificare
un argomento!  Si calcola invece un risultato a partire appunto
dall'argomento.  E dunque quicksort (elementare) diventa:
def qs(unarray):
    if not unarray: return []
    return qs([ x for x in unarray if x < unarray[0]
        ]) + [ x for x in unarray if x == unarray[0]
        ] + qs([ x for x in unarray if x > unarray[0] ])
oppure, usando funzioni d'ordine superiore, anche qualcosa
del tipo:
def qs(unarray):
    if not unarray: return []
    def prima(x): return x < unarray[0]
    def dopo(x): return x >= unarray[0]
    return qs(filter(prima, unarray[1:])
        ) + [ unarray[0]
        ] + qs(filter(dopo, unarray[1:]))
Alex

 calcola che io utilizzo Win2k...
http://www.strout.net/python/pythonvslisp.html
 offre un'ottima analisi
di Lisp rispetto a Python e del perche` un dato progetto ha deciso di
migrare dal primo al secondo.  Il confronto e` con il vecchio Python 1.5,
e l'attuale Python 2.2 e` naturalmente molto piu` potente, ma le basi
del ragionamento restano valide.
Molti entusiasti di Python lo sono (o erano) anche di Lisp -- ad esempio,
entrambi i linguaggi sono "chiodo fisso" per Eric Raymond.  Richard
Stallmann (che sul Lisp ha basato il suo famoso editor Emacs) ha 
consegnato quest'anno il premio della FSF a Guido van Rossum con
una speciale menzione delle somiglianze di Python a Lisp.  Io stesso fui
assunto per il mio primo lavoro (tanto ma tanto tempo fa) sulla base
della mia padronanza del Lisp (in realta` Scheme, ma pochi capiscono
la differenza:-).
Menziono tutti questi fatti perche`, giudicando dalla tua rapida perdita
di entusiasmo per Python, non vedo alcuna ragione per cui dovresti
sprecare altro tempo ancora con il Lisp.  Se ben ricordo fra le ragioni
del tuo rapido raffreddamento c'e` che Python non e` il linguaggio piu`
diffuso nella realizzazione di videogame (ci sono "solo" un certo numero
di framework e alcuni videogame commerciali di successo che lo
usano): ebbene, Lisp che io sappia non e` MAI stato usato per videogame
e non esistono ne` framework ne` vg commerciali che vi si basino.  Poi
parlavi di opportunita` lavorative: con Python in rapida e tumultuosa
crescita, e Lisp in lento ma inesorabile calo, non crederai mica di averne
di piu` con Lisp che con Python?!
Alex

 dove l'utente può definire nuovi tipi di dato?
Non necessariamente.  La programmazione strutturata e` quella che
usa un certo numero di strutture di controllo (soprattutto IF e WHILE,
che sono a rigore sufficienti, ma spesso anche altre) e non il costrutto 
GOTO.  La possiiblita` di definire nuovi tipi di dato e` considerazione
"ortogonale" a questa.
Alex

 del ragionamento restano valide.
L'entusiasmo rende apostoli. E gli apostoli entusiasti come Alex a volte
scordano di precisare alcuni dettagli.
Dato che la discussione era posta in termini di paradigma di
programmazione e non di linguaggio, credo andrebbe precisato che:
In generale se un linguaggio è minimamente flessibile, è possibile
sviluppare codice in quel linguaggio seguendo un qualunque paradigma.
Nonostante questo la maggior parte dei linguaggi supportano uno o più
paradigmi in maniera diretta, gli altri risultano "scomodi": programmare
ad oggetti in Fortran è possibile, ma scomodo dato che il fortran è
disegnato per un paradigma imperativo procedurale.
Il Lisp è in assoluto il linguaggio più citato quando si parla di
programmazione funzionale. Se non altro perchè è il primo (credo in
assoluto, e comunque il primo ad avere una diffusione significativa) che
è progettato per tale paradigma. In Lisp l'uso del paradigma funzionale
(o se preferiste la codifica un algoritmo definito in termini di lambda
calcolo) è naturale e immediata. E' possibile esprimere anche del codice
"imperativo" ma la cosa risulta "scomoda".
Vi sono moltissimi altri linguaggi che supportano molto bene il
paradigma funzionale. Alcuni sono molto simili al Lisp, come Scheme che
come dice Alex viene spesso considerato come fosse Lisp anche in realtà
i due non sono proprio "uguali", altri invece sono molto diversi.
Il Python, per quello che ho capito del linguaggio, non è un linguaggio
che ha il paradigma funzionale come fondamento del linguaggio stesso e
della sua sintassi. In questo senso Python è un linguaggio
fondamentalmente imperativo. Però Python supporta il binding dinamico,
supporta le closures e supporta anche la lambda notazione. Pertanto
supporta in maniera piena un paradigma completamente funzionale.
La superiorità di Python in questo senso deriva proprio dalla sua
capacità di supportare si la notazione lambda, ma all'interno di una
sintassi sostanzialmente imperativa e con elementi del linguaggio che
gli permettono di supportare anche l'Object Orientation, la
strutturazione del codice e dei dati, le espressioni regolari (che con
Perl diventano quasi un paradigma di programmazione a se stante, seppur
limitato) e alte cose ancora.
Pertanto un problema semplice espresso in termini imperativi e con
alcune parti espresse ricorsivamente o in termini di lambda calcolo,
trova soluzione immediata in Python mentre in Lisp la parte imperativa
deve essere trasformata in notazione lambda ("deve" in realtà è un
pochino forte, ma un lisp-ragionamento è un lisp-ragionamento è un
lisp-ragionamento è un lisp-ragionamento ...) e in C la parte funzionale
deve essere espressa in termini imperativi (per fortuna almeno l'uso
della ricorsione è ammesso).


 della ricorsione è ammesso).
La ricorsione e` ammessa, ma le closures non esistono e l'uso di
funzioni di ordine superiore praticamente impossibile (puoi passare
una funzione ad un'altra, ma per costruire e ritornare nuove
funzioni devi praticamente fare un compilatore/interprete per
un nuovo linguaggio, come accennato all'inizio).  Il C++ e` un
po' meno peggio (torno a citare Coplien, Multi-PARADIGM design
for C++, sull'implementazione di FP in C++) ma condivide con
Common Lisp il peso di un'enorme complessita`.
Alex

di piu` con Lisp che con Python?!
1 - cercavo qualche link sul Lisp tanto per sapere cos'è non
perchè abbia intenzione di "lanciarmi" sul Lisp
2 - come ben sai la mia era una critica un pò esagerata ma
derivata dalla non esperienza. Cmq non capisco perchè tu
debba "attaccarmi" in questo modo....
3 - Il Python _e'_ un ottimo linguaggio e su questo non ci
piove, non mi dispiacerebbe approfondirlo ma al punto in cui
sono arrivato (non avendo mai costruito applicazioni
serie...se non qualcosina in Delphi :( ...) mi ero
stancato...non del Python in sè...ma nella mia mente
frullava questo ragionamento: "wow, bello sto Python...ma
che ci faccio ora?"... Questo non è un ragionamento derivato
da una mia negatività verso tal linguaggio ma dal semplice
fatto che non so che _fare_ :(
4 - Riguardo alla programmazione dei videogames non sono
cosi chiuso come ti è sembrato...Ho dato un'occhiata al
codice incluso in PyOpenGL (ho qualche riminiscenza delle
OGL) e lo ho trovato ottimo... Penso che il trinomio: Python
+ OpenGL + GLUT Library sia fantastico, ti permete di
scrivere parecchio codice in meno e avere più controllo
sull'applicazione (IMHO). Anyway sto usando DX&C++ per
ragioni varie...ad es. il fatto che la maggioranza delle
guide, dei tutorials, dei whitepapers e del codice usa
quella combinazione (presupponendo l'uso di DX ovviamente).
Il secondo motivo è perchè una persona + esperta di me mi ha
convinto ad utilizzare il framework M$ illustrandomi vari
vantaggi a detta sua..personalmente non ho nulla contro le
OGL ma nemmeno contro le DX (non essendo un esperto di
nessuna delle 2...).
5 - Spero di essere stato chiaro e averti spiegato la mia
posizione attuale...
ps. si dà il caso che stia studiando wxPython in questo
momento perchè Tkinter non mi piace (questione puramente di
gusti...) invece wxPython si


passato non permette questa abrogazione).
Cosa intendi?
Perchè dici che Python diverebbe + semplice togliendo
lambda? (e quindi il supporto per le funzioni
anonime...giusto?)


 gusti...) invece wxPython si
Questione, in effetti, di gusti.  Quando a suo tempo guardai
wxPython mi sembro` piuttosto buono (wxWindows e` assai piu`
di "piuttosto buono"... e` un ottimo framework per potere
sviluppare applicazioni C++ cross-platform), ma avendo una
discreta competenza pregressa su Tcl/Tk mi sento tutto
sommato piu` a mio agio con Tkinter, per le mie esigenze
tipicamente modeste relative alle interfacce utente.  Poi il
mio attuale cliente piu` importante ha scelto Tkinter, per
cui e` con Tkinter che mi trovo di recente a lavorare.  Ma
non avrei problemi a passare a wxPython se qualche altro
cliente preferisse specificamente quello.
Alex

cliente preferisse specificamente quello.
Condivido pienamente il tuo ragionamento.
(Il mio è un semplice gusto personale.)
Saluti da un Lawrence contento di essere tornato a discutere
di cose un pò meno frivole rispetto ai miei problemi :)


gusti...) invece wxPython si
Io ho dato un'occhiata ad anygui e mi piacciono molto la sua
semplicità e "pythonicità", penso che quando sarà un po' più completo
inizierò ad usarlo.
-- 
Marco Barisione (ICQ 84277092)

inizierò ad usarlo.
Gli ho dato un'occhiata e penso che se questo progetto
diventi oltremodo stabile e completo possa essere una gran
bella cosa: l'idea di "astrarre" dalla GUI specifica
potrebbe risolvere non pochi problemi :)


Marco Barisione wrote:

Stiamo facendo del nostro meglio.  Ma penso che anche quando sara`
completo, almeno nel release 1.0, non sara` altrettanto ricco di
toolkit come wxPython; e` molto importante (per tutti noi del gruppo
anygui, direi) che resti molto facile scrivere nuovi backend.  Noi
ne forniremo, diciamo, una decina, e gia` per questi fornire tutta
la ricchezza funzionale concepibile sarebbe un problema, ma,
soprattutto, scriverne un undicesimo per integrare codice Python
che usa anygui con qualsiasi altro ambiente GUI dovrebbe restare
semplice.  Se mai, dovra` essere possibile e agevole per il codice
Python che usa anygui scoprire quale sia il backend corrente,
cosi` da passare a chiamate dirette di un certo toolkit se e solo
se quello e` il toolkit del backend, mantenendo una funzionalita`
di minima qualsiasi sia il backend.  Ad esempio, supponi che il
"tabbed dialog" (o "panel" o "property page" ecc) non sia fra i
widget di anygui, come lo e` invece per wxPython e alcuni altri
toolkit: se tu scrivi un'applicazione Python che vorrebbe proprio
un tabbed dialog, usando anygui, puoi passare all'uso del tabbed
dialog nativo nei toolkit opportuni a te noti, e se scopri che
il backend corrente non e` fra quelli noti ripiegare invece su
di una funzionalita` di minima (tipo, finestre separate, o altre
simulazioni di tabbed dialog sulla base di widget piu` elementari).
Si dovrebbe accumulare un patrimonio di "megawidget" basati su
concetti di questo tipo, ma certo non avverra` prima del release
1.0, e non e` necessariamente la squadra di anygui che mettera`
insieme questo patrimonio.  Come nostro obbiettivo, anygui avra`
tutti gli strumenti elementari necessari e sufficienti per
rendere possibili e facili questi sviluppi; poi, speriamo nella
comunita` degli utenti.  Il livello di portabilita` cross
platform di applicazioni basate su anygui (come altro puoi
fare applicazioni che girano altrettanto bene su JVM, su BeOS,
su Mac, su Windows, su Linux, su .NET, su di un terminale di
testo e su di una pagina web con HMTL dinamico...?) dovrebbe
essere la "killer feature" per attrarre tale comunita`, assieme
alla massima semplicita` e Pythonicita` cui fai riferimento.
Alex

Lawrence Oluyede wrote:

Obbligando tutte le funzioni ad avere un nome non si perde
praticamente nulla in termini di potenza espressiva, rispetto
all'attuale situazione in cui un piccolo sottoinsieme delle
funzioni (quelle esprimibili in una singola espressione)
possono restare anonime.  La maggior semplicita` mi sembra
evidente: uno degli obbiettivi (ideali, non concretamente
raggiungibili) di Python e` di offrire UN buon modo, e se
possibile uno solo, per svolgere ogni dato compito.  Oggi
puo` non essere ovvio al principiante di Python (soprattutto
se viene da linguaggi dove lambda funziona bene:-) se debba
scrivere, che so:
    reduce(lambda x, y: 0.9 * x + y, sequenza)
ovvero:
    def mediaMobile(mediaPrecedente, nuovoDato):
        return mediaPrecedente * 0.9 + nuovoDato
    reduce(mediaMobile, sequenza)
mentre abrogando lambda si renderebbe ovvio che la seconda
forma, dando nomi chiari e appropriati e rendendo dunque
assai piu` facile capire cosa stia succedendo quando si
legge il codice, e` assai preferibile.
Ma come dicevo si tratta di considerazioni astratte e
teoriche, se non altro perche` il vincolo di compatibilita`
non permettera` mai di abrogare lambda.  L'idea di fare
un giorno un "Python 3000" senza vincoli di compatibilita`
non e` piu` molto alla moda, per ottime ragioni peraltro.
Alex

non e` piu` molto alla moda, per ottime ragioni peraltro.
Credo che il vincolo di compatibilità sia doveroso verso
tutto il codice prodotto _prima_ di quella particolare
feature specifica...in ogni caso è a discrezione dello
sviluppatore servirsi di lambda oppure no in base alla sua
opinione.. Penso che in ogni caso sia meglio non _abusarne_
altrimenti si può incorrere in una spiacevole cripticità del
codice..


 opinione..
Ma facendolo, imponi all'eventuale collega di lavoro o simile, di conoscere
il suo funzionamento...  se ci sono N modi per fare la stessa cosa, non puoi
dire, io scelgo la N1, e tutte le altre non le uso... perchè altri non la
pensano come te, e possono fare lo stesso ragionamento usando però la N2, N3
e così via.... quindi IMHO, meglio eliminare ciò che è superfluo, anche se
la compatibilità con applicazioni precedenti, è troppo importante :(
ciao
--
Luigi
Web Site: 
http://web.tiscali.it/luigi_web
E-mail: 
cybe...@email.it
ICQ #46240443

la compatibilità con applicazioni precedenti, è troppo importante :(
Guarda che io la penso come te....


Io replicavo su questa tua affermazione:
...in ogni caso è a discrezione dello
sviluppatore servirsi di lambda oppure no
perchè questo significa che esso può decidere di usarla.... se invece non
esistesse, non ci sarebbe questo problema :)


esistesse, non ci sarebbe questo problema :)
Esatto la cosa migliore è evitare di usare lambda e magari
inserirla nella lista delle features deprecated...(esiste
una feature del genere in Python? tipo i deprecated di
Java...)


 Java...)
Si`, anche se per ora il compilatore ancora non manda il
warning che secondo me dovrebbe (le librerie deprecate
i warning li mandano eccome).  L'unica feature deprecata
del _linguaggio_ Python (librerie a parte) e` per ora la
possibilita` di scrivere a <> b come sinonimo di a != b.
Alex

possibilita` di scrivere a <> b come sinonimo di a != b.
Scusa se continuo ma esistono PEP a riguardo e Van Rossum
ha intenzione di "provvedere" nella prossima versione?
Oppure questa caratteristica è in uno stato embrionale?


 [...cut...]
Perche non mi sono messo a cercare prima di postare??
Brutto vizio... :(
Anyway ho trovato questa PEP
(
http://python.sourceforge.net/peps/pep-0004.html
)
penso sia quella a cui mi riferivo


 possibilita` di scrivere a <> b come sinonimo di a != b.
Che perņ non č segnalata con un warning vero? Visto che ho provato con
Python 2.1 :)


 Python 2.1 :)
No, come appunto dicevo per ora il compilatore non usa i
warning per le parti deprecate del linguaggio vero e proprio
(solo i moduli deprecati delle librerie, come regex, usano il
sistema dei warning, per ora).
Alex

Cmq, non credo sia cosě dannoso poter scegliere tra <> e !=.
Anche se il secondo č piu diffuso (grazie alla diffuzione dei linguaggi che
lo usano.. C/C++ Java etc...)


 che lo usano.. C/C++ Java etc...)
<>, che pare suggerire che "diverso" equivalga a "minore o maggiore",
e` poi assurdo in quanto non tutti i tipi cui si applica il concetto di
eguale o diverso supportano anche quello di minore e maggiore; ad
esempio, se a o b sono numeri complessi, a > b e` un errore, e cosi`
pure a < b, non ha quindi senso che sia corretto a <> b.
Alex

pure a < b, non ha quindi senso che sia corretto a <> b.
<> da quanto ne so č un'ereditą del Pascal e sinceramente
trovo + logico l'operatore not equal (!=)


 trovo + logico l'operatore not equal (!=)
Che pure, se ci pensi, e` poco consistente: "not equal" dovrebbe essere 
'!=='. '!=' sembra piu` la negazione di un'assegnazione. ;)
-- 
Baci,
Mony

 '!=='. '!=' sembra piu` la negazione di un'assegnazione. ;)
Infatti lo sbaglio è a monte. Infatti la cosa migliore è
:= assegnamento o ancora meglio <-  (che però può generare confusione)
e = solo per l'uguaglianza


e = solo per l'uguaglianza
a me := è un operatore che non è mai piaciuto...
allo stato attuale la combinazione migliore è:
= per l'assegnamento
== per il confronto (if equal)
!= per il confronto (if not equal)
e bandire <> :)


 != per il confronto (if not equal)
Ma se in principio fossero state fatte scelte migliori, lo stato attuale
sarebbe anch'esso tale.


 sarebbe anch'esso tale.
...se non fosse cambiato nel frattempo, ovviamente.  Python non
vive in un mondo ipotetico e astratto, ma in uno reale dove anche
le aspettative di chi inizia ad usarlo (magari venendo da C) devono
essere soppesate per definire i compromessi ottimali.  Il genio di
Guido e` in misura non minima quello di avere fatto i compromessi
giusti piu` spesso di qualsiasi altro linguaggio.  Esistono anche dei
linguaggi progettati senza alcun compromesso, come Haskell, ma
non a caso si tratta di linguaggi di grande interesse teorico e
formativo ma assai minore importanza pratica.
Il doppione fra <> e != e` certo un compromesso basato sul fatto
che nel 1990 sia Pascal sia C avevano un grosso pubblico: oggi
quello con aspettative C-ose e` cresciuto, quello Pascal enormemente
calato, quindi cambiando il mondo esterno cambia anche la definizione
di cosa sia "migliore".
Alex

 e = solo per l'uguaglianza
Thomson e Ritchie spiegano perche` in C hanno invece usato == per
il confronto e = per l'assegnazione: si usano ALMENO due volte piu`
assegnazione che non confronti, quindi e` sacrosanto che il simbolo
per l'assegnazione sia due volte piu` corto!  Ragionamento assai
pragmatico e del tutto applicabile anche a Python.
Alex

 giusti piu` spesso di qualsiasi altro linguaggio.
Beh, ovvio che da questo punto di vista non si può assolutamente escludere
la fetta di C(++)- isti :)
