Newsgroup: it.comp.programmare.win32
Titolo: Programmare in C o C++?

Ciao.
Mi trovo a voler sfidare il mondo, volendo programmare con le API di windows
(Grafica elementare) con il linguaggio C!
In cosa sarebbe meglio il C++?
Il C è proprio del tutto superato?



Io programmo in C++ direttamente con le Win32 API, il C++ rispetto al
C puro (dal quale provengo) mi e' venuto utile non per le chiamate
alle API di sistema ma per strutturare meglio i miei programmi.
Il fatto di usare il C++ non implica necessariamente che tu debba
usare le MFC, anzi.  
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email 
happyman...@libero.it
 [Togliere nospam per scrivermi]
Salsa Web 
http://happyman.n3.net
 [Foto salseri/e & I.A.B.L.A. Ring]

"Giovanni Lauria" <wrs...@NOSPAMtiscalinet.it> ha scritto:

Detto in maniera molto grossolana il C++ ha un modello di programmazione
completamente diverso dal C e l'organizzazione del programma e' molto piu'
naturale e ti consente di rimanere molto piu' vicino ai problemi.
Lascia stare il C, non e' superato, e' morto e sepolto...
ciao
merlinO

completamente diverso dal C 
forse perchè uno è ad oggetti e l'altro no? :)
--
Lawrence Oluyede
rhy...@myself.com

Non sono totalmente d'accordo. Dipende dall'ambito applicativo.
Per esempio, nel settore dell'Automazione il C è molto più utilizzato,
nel settore embedded, dove prestazioni ed occupazione di memoria sono
importanti,
il C++ non ha possibilità di entrare ecc.
Quindi la scelta del linguaggio, che ricordiamocelo è un "mezzo"
e non un "file", dipende essenzialmente da ciò che si deve realizzare.
Ciao
Ellebi

Opps. replace "file" with "fine"

 importanti,
Concordo.
Non nascondo che in ambiente Windows mi sembri più semplice da usare un 
meccanismo ad oggetti che allontana da uno strato sottostante ancora più 
caotico.
L'affermazione che poi il linguaggio C sia "morto e sepolto" è 
evidentemente da newbie: chi ha un po' d'esperienza solitamente usa 
indifferentemente paradigmi di programmazione diversi, a seconda 
dell'ambiente in cui si trova.
Lou

 Ellebi
ciao
merlinO

Thank you guys!  : )
Giovanni Lauria <wrs...@NOSPAMtiscalinet.it> wrote in message
HVfB8.13042$US3.3...@twister1.libero.it...


 ritengo il C morto e sepolto (imho).
In ogni caso non definirei mai un linguaggio di programmazione "morto" 
solo perché sono arrivati nuovi paradigmi: rimane pur sempre una scelta 
legata all'applicazione -- e qui sono decisamente OT, visto che si parla 
di Win32, e pure io che me ne occupo molto poco ritengo C++ più adatto 
di C, come ho già scritto.
Lou
"La notizia della mia morte è certamente prematura", C. Bene

 Lou
ciao
merlinO

 forse perchè uno è ad oggetti e l'altro no? :)
Il C++ e' multi-paradigma, non solo orientato agli oggetti.
Non c'e' necessita' di continuare a usare il C, se c'e' il
C++.  Si riesce a fare tutto quello che si fa con il C, in 
modo anche migliore.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 importanti, il C++ non ha possibilità di entrare ecc.
Falso, almeno in parte.
Il C e' ancora molto utilizzato per ragioni di amicizia storica, 
compatibilita' all'indietro e manutenzione dei vecchi sistemi.
Non c'e' alcuna (e sottolineo *alcuna*) ragione per cui convenga
utilizzare il C, oggigiorno, per un nuovo progetto, anziche' il
C++.  Il C++ ha molti vantaggi rispetto al C, che abbracciano
*soprattutto* le prestazioni e l'occupazione di memoria.
Non c'e' alcun motivo per ritenere che un codice C++ sia meno
performante dell'equivalente C o che occupi piu' memoria.
Anzi, in molti casi e' l'esatto contrario.
Tieni presente che la libreria standard C++ e' stata studiata
con un occhio particolare verso le prestazioni, cosa che in
C e' stata considerata solo in forma minima.
Tieni anche presente che gli aspetti come il polimorfismo e 
l'RTTI (che subito molti si affretteranno ad additare come la
causa di tutti i mali del C++) non sono ricostruibili in C, 
senza impegnare le stesse risorse e gli stessi tempi di 
esecuzione del C++.
Decidere di utilizzare il polimorfismo puo' condurre a degli
enormi vantaggi, barattabili, in molti ambiti, con le 
prestazioni e l'occupazione di memoria.
Laddove questi aspetti non servano (e quindi puo' bastare
utilizzare i vecchi costrutti C) si continuera' ad utilizzare
il subset C del C++ (ma che e' sempre C++).


 dell'ambiente in cui si trova.
Chi ha un po' di esperienza sa che i diversi paradigmi sono 
sfruttabili senza uscire dal recinto del C++.
Il C++ e' multi-paradigma.  Consente, cioe', di essere sfruttato
come un "better C" e come un linguaggio orientato agli oggetti.
Considerare la programmazione in C come un paradigma diverso 
rispetto a quella in C++ e' fuorviante e inesatto.


 legata all'applicazione 
Il C++ non introduce solo un nuovo paradigma, ma rimpiazza *in toto*
il vecchio linguaggio.  


 Il C è proprio del tutto superato?
Decisamente.  Il C ha dominato gli anni '80 e parte degli anni '90,
ma ormai la programmazione seria non prescinde dall'uso del C++.


 
Quello che affermi č assolutamente vero in termini teorici.
Purtroppo in alcuni casi i compilatori C "puri" generano codice piů 
performante del compilatore C++ per la stessa piattaforma (anche se mi 
pare che negli ultimi tempi questa differenza stia diminuendo) e questo 
puň condizionare la scelta del linguaggio, soprattutto in ambito 
embedded, dove le prestazioni a volte sono determinanti.
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

modo anche migliore.
mmm non si è proprio notato il " :) "
--
Lawrence Oluyede
rhy...@myself.com

 
Molti progetti sono ancora sviluppati in C (il kernel di linux, per 
citarne uno) e questo linguaggio mi sembra ben lungi dall'essere 
"morto".
Apprezzo i vantaggi della programmazione ad ogetti e della 
programmazione generica, soprattutto per progetti di grosse dimensioni, 
ma non nego che in parecchie situazioni, quando devo sviluppare 
programmi semplici, pur utilizzando il compilatore C++ e alcune delle 
caratteristiche del linguaggio, sviluppo programmi che potrebbero 
venire compilati senza troppo sforzo (spostando la dichiarazione delle 
variabili e l'inizializzazione) da un compilatore C "puro".


 performante del compilatore C++ per la stessa piattaforma 
Ma dove ? ma quando ?
Se c'e' una differenza tra un compilatore e l'altro non e' certo
una differenza imputabile al *linguaggio* alla base.
Un compilatore C superottimizzato per una piattaforma specifica,
produce codice molto *migliore* (la butto sul vago) rispetto ad
un compilatore C che gira su quella piattaforma ma non e' 
ottimizzato per essa.


 "morto".
Il kernel Linux e' sviluppato in C per scelte che esulano, per
ammissione stessa di Torvalds, dalle performance o dall'occupazione
del codice.  La scelta e' ricaduta sul C per il semplice motivo che
il C++ e' troppo complesso per la maggior parte dei vecchi programmatore
e la manutenzione del codice sarebbe risultata difficoltosa.
Ma questo e' un problema dei programmatori, non del linguaggio.


 ti serve neanche in C++ e quindi non lo usi.
Ecco, questo mi sembra che sintetizzi i molteplici messaggi sul thread: 
quello che non ti serve non lo usi, per cui per applicazioni in cui non 
ti serve C++ puoi continuare ad utilizzare C. Non mi sembra una cosa 
tanto sconvolgente.
Lou

 il subset C del C++ (ma che e' sempre C++).
Ehm... decisamente non capisco: ma allora tutta la filippica era per non 
sentir dire "C"?
Sinceramente non mi mette nessuna ansia sapere se si chiama C++ o 
semplicemente C, mi è sufficiente che faccia quello per cui lo uso.
Pensavo adesso, che se ad oggi il C fosse "morto", fra una decina d'anni 
sarebbe praticamente "estinto", no?
Ho sufficiente pazienza per aspettare e vedere con i miei occhi che ne 
sarà, anziché alimentare inutili flames -sorriso-
Lou

Lawrence Oluyede wrote:

Un discorso che non ho sentito fare da nessuna parte in questo
thread e`, QUALE C?  Ci sono due standard ufficiali, uno di 12
anni fa e uno di 3 anni fa.  Penso che stiate dando tutti per
scontato l'uso dello standard C vecchissimo invece di quello solo
vecchio, giusto?
Il C99 comprende varie feature del C++ che il C90 (detto anche
C89, ma quello e` l'anno di adozione da parte di un singolo ente
nazionale, l'ANSI; lo standard internazionale, quasi identico,
fu adottato invece da ISO l'anno dopo, quindi C90) non aveva,
come la possibilita` di dichiarare le variabili non solo a inizio
blocco (un 'dettaglio' in realta` importantissimo, vantaggio
sostanziale di C++ su C90... ma non su C99).  Inoltre C99 ha
un piccolo numero di possibilita` in piu`, assenti da C90 *e* 
C++.  
La scelta fra C90, C99 e C++ e` dunque tutt'altro che semplice
oggi, basandosi anche sui dettagli di quale compilatore abbia
quale livello di implementazione dei vari standard sulle varie
piattaforme di interesse (e ovviamente su quale interesse
offrano per una data implementazione le feature di C99 rispetto
a quelle di C90 o C++).
Alex

 ma ormai la programmazione seria non prescinde dall'uso del C++.
Viene da chiedersi perche` l'ISO ha deciso allora di sancire il
nuovo standard C, detto C99 in quanto appunto sancito nel 1999:-).
Alex

 embedded, dove le prestazioni a volte sono determinanti.
Molti manuali di ingegneria del software considerano l'ottimizzazione delle
prestazioni un'operazione che si puo' fare sostanzialmente solo al termine
dello sviluppo. A priori le prestazioni possono cercate con l'impiego degli
algoritmi piu' performanti, ma solo quanto il sistema sara' terminato si
potra' capire (per esempio con un profiler) quali sono i punti in cui
intervenire per migliorare le prestazioni. Diverse analisi hanno dimostrato
che la maggioranza del codice non interviene signigicativamente sulle
performance del software, per una serie di motivi che vanno dal fatto che
alcune funzioni vengono chiamate solo una volta o si appoggiano ad API di
sistema gia' ottimizzate o riguardano fasi in cui non e' richiesta una
particolare velocita', ecc. I punti in cui intervenire rimangono quindi
molto pochi e per questi possono essere scelte soluzioni particolari (tipo
sviluppo di sezioni in assembler) o piu' semplicemente l'acquisto di
hardware piu' veloce.
In base a queste considerazioni troverei molto sbagliato scegliere il C come
linguaggio di base per lo sviluppo di un nuovo sistema rispetto al C++ che
porta molti vantaggi in piu' in termini di design, riutilizzailita' e
semplicita' di sviluppo.
ciao
merlinO


 
Manca un ++ da qualche parte?
Assolutamente vero (dovunque vada a cadere il ++, e anche senza nessun 
++).
Il problema è che (per quanto ne sò, sarei felice se tu mi fornissi 
qualche link per aggiornarmi) quasi sempre il compilatore C per una 
certa piattaforma è più ottimizzato dell'equivalente C++ (anche perchè 
la programmazione a livello di kernel è in buona parte C). 
E' una considerazione meramente pratica visto che, come giustamente 
affermi, C++ è C più altro e quindi rende "sorpassato" il C "nudo e 
crudo". 
Purtroppo molto spesso (soprattutto in certi ambiti) è necessario 
conciliare la grammatica con la pratica.


 certa piattaforma è più ottimizzato dell'equivalente C++ 
..non e' generalmente vero, almeno nella mia esperienza ho potuto 
constatare che non e' cosi'.


 tanto sconvolgente.
No, il discorso e' invertito: visto che in C++ puoi continuare a 
fare le stesse identiche cose che facevi in C, a volte con performance
ancora migliori, allora ti conviene utilizzarlo.
Il tuo discorso e' senza senso, e' come se uno mi proponesse una
jeep 4x4 per salire la montagna e io gli rispondessi: ma sai, visto
che il mulo mi ci porta lo stesso, allora uso il mulo.


 sarebbe praticamente "estinto", no?
Perche' no ? dieci anni in informatica sono un'eternita'.
Se vi saranno linguaggi migliori, piu' semplici e piu'
potenti, perche' non dovrebbe estinguersi ?


 nuovo standard C, detto C99 in quanto appunto sancito nel 1999:-).
Difatti me lo chiedo: non sarebbe il caso di far avanzare
un solo linguaggio che unisca le potenzialita' dei due ?


 un solo linguaggio che unisca le potenzialita' dei due ?
Il prossimo standard C++ (che immagino uscira` piu` o meno
quando vari compilatori implementeranno l'attuale, tanto per
garantire che non ci sia un momento di pace) probabilmente
incorporera` molte delle migliore di C99.
Ma l'esistenza degli standard C ha un grande vantaggio: la
semplicita` del C rispetto al C++ permette di sviluppare
compilatori e librerie che rispettano gli standard in tempi
evidentemente minuscoli a quelli occorrenti per il C++, e
di conseguenza curare poi gli aspetti di correttezza, qualita`
del codice generato, rapidita` di compilazione, e cosi` via.
L'enorme complessita` del C++ non permette questi lussi.  Se
ancora oggi nessun compilatore (tanto meno nessuna accoppiata
compilatore + libreria) DICE neppure di implementare il 100%
dello standard, questo ha costi evidenti.
Chi la struttura della sua applicazione la costruisce in
linguaggi di piu` alto livello (Smalltalk e le sue varianti,
Python, Erlang, Perl, Ruby, O'Haskell, O'Caml, Mercury/Oz,
e chi piu` ne ha piu` ne metta), o in linguaggi "intermedi"
(come Java, C#, Eiffel, ...), puo` comunque trarre vantaggio
dall'uso di un linguaggio capace di esprimere codice ad un
livello inferiore per accelerare quelle parti, spesso molto
piccole, di un'applicazione, che ne costituiscono i "colli
di bottiglia" relativamente alle prestazioni.  In queste
condizioni si trae un beneficio *relativo* (non nullo, ma
non necessariamente gigantesco) da tutte le complicazioni
supplementari del C++ rispetto al C.  Dipende da quale
tecnologia il linguaggio a piu` aldo (o intermedio) livello
suggerisca di usare per queste "estensioni native".  Con
Java, ad esempio, l'uso di JNI suggerisce di appoggiarsi su
C, non su C++.  Chi debba usare COM o XPCOM invece ha pur
sempre la vita piu` facile in C++.  Linguaggi flessibili come
Python permettono piena liberta` di scelta (dalle native
"API per C", attraverso SCXX, CXX, e sip, sino alla potenza
roboante di Boost che richiede compilatori C++ molto vicini
agli standard -- accontentandosi di MSVC++ e gcc, che sono
comunque sopportati [sarebbe sUpportati ma troppo forte e`
il richiamo di 'sopporta pazientemente i compilatori
molesti'... di deviazioni dagli standard ne hanno tante, ma
sono cosi` diffusi che non li si puo` ignorare...]:-).
Insomma, se esistesse un solo standard per i linguaggi
capaci di offrire pieno controllo della macchina, dal C
al C++, dovrebbe sicuramente essere "a strati" (come e`
ad esempio lo standard dell'SQL), permettendo l'esistenza
sul mercato di un compilatore standard-compliant limitato
al "sottoinsieme C" delle cose.  Visto che una fetta
importante (e non certo in calo, se sommi l'interesse per
tutti i linguaggi suelencati) puo` accontentarsi di questo
sottoinsieme, perche` dovrebbero aspettare i tempi,
sopportare i bug, &c, legati a compilatori obbligati a
gestire il linguaggio piu` complesso...?
Alex

 dovrebbe incidere sull'ottimizzazione del codice.
Diciamo che posso spendere X ore-uomo per scrivere un compilatore.
La risorsa e` dunque limitata.  Come la allochero`?
Le caratteristiche desiderabili di un compilatore sono tante.
Se deve gestire un linguaggio relativamente semplice, una frazione
maggiore della risorsa limitata "ore-uomo" a mia disposizione
potra` andare a curare aspetti come la completa correttezza (con
suite di test piu` ricche e accurate), l'ottimizzazione del codice
generato (non solo devo considerare meno casi, ma ho piu` ore-uomo
per considerarli), la rapidita` del processo stesso di compilazione,
l'accuratezza e completezza di diagnosi di errori e avvertimenti
(warning), la configurabilita` del compilatore, e cosi` via.
Se pensi che per un dato progetto software (tipo "un compilatore")
siano mai disponibili risorse illimitate, commetti un errore.  Anche
in open-source, con tutti i vantaggi che comporta, le risorse non
sono illimitate: basta vedere gcc, che pur con tutti i suoi
contributor non riesce ancora a darci un 3.* usabile in un
ambito "di produzione" (e neppure nella 3.1 supportera` in pieno
nessuno dei suoi linguaggi principali: C99, C++, Java, ...).
Parte del problema e` il concetto di "ritorni calanti": se
anche raddoppio il numero di persone che lavorano (diciamo
ad esempio a tempo pieno) su di un progetto, non raddoppia
il numero di "ore uomo efficaci" perche` una frazione sempre
maggiore del monte-ore totale e` spesa in comunicazione fra
i partecipanti, studio della crescente complessita` del
programma, ecc.  Il "paradosso del Mythical Man-Month" e`
che in molti casi aumentando il numero di persone in un
dato progetto si CALA il monte-ore efficace -- Brooks se ne
rese conto gia` ben oltre trent'anni fa; c'e` un punto di
ottimo (dipendente dalla strutturazione modulare della
architettura complessiva) e piu` oltre non si va.
Alex

 C++.  
Quali sono?
Lou

 Alex
merlinO

 design dell'applicazione e gestione del progetto.
Sto parlando di design &c del *COMPILATORE*.
La qualita` del codice macchina generato dal compilatore, come ogni
altro aspetto del funzionamento di un programma (e tale e` appunto il
compilatore), dipende dal totale di lavoro che c'e` da fare sul
programma stesso (appunto il compilatore) e le risorse efficaci
disponibili per lo sviuppo del programma (sempre il compilatore).
Essendo le risorse efficaci intrinsecamente limitate, vincolare a
maggiore sforzo su di un aspetto (es: gestire pienamente un linguaggio
di complessita` molto maggiore) puo` ovviamente presentare
riscontri negativi su ogni altro parametro di qualita` del
programma-compilatore (es: livello di ottimizzazione del codice
generato), in quanto restano minori risorse per curare questi
altri parametri.
Alex

Lou Cyphre wrote:

Come al solito per gli standard ISO in rete si trovano solo draft,
comunque a occhio mi pare che i documenti sotto:
http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/
siano ragionevolmente rispondenti.  Qualcuno ha la URL per un
buon riassunto, magari mirato a quello che effettivamente poi
lo standard C99 ha adottato?
Alex

vecchio, giusto?
Penso che derivi dal fatto che la maggior parte delle
persone che programma in C utilizza la versione C89/90...che
il K&R2 illustra in modo ottimale....io ad esempio non
conosco tutte le feature aggiunte da C99 anche se ho letto
qualche paper qua e la...non ci sono libri che spiegano
quest'ultina versione?
--
Lawrence Oluyede
rhy...@myself.com

lo standard C99 ha adottato?
se ti può servire:
http://www.baosys.com/work/cpp/html/18.10/meyers/meyers.htm
e
http://www.baosys.com/work/cpp/html/18.12/meyers/meyers.htm
--
Lawrence Oluyede
rhy...@myself.com

(come Java, C#, Eiffel, ...), [...cut...]
Per quale motivo fai una distinzione tra il primo gruppo di
linguaggi da te citato e il secondo?
--
Lawrence Oluyede
rhy...@myself.com

 sigle)
Che su tantissime piattaforme i compilatori C++ siano *molto* indietro
(o del tutto assenti) e` un fatto difficilmente contestabile. Ormai ci
sono DSP ben piu` complessi e potenti di tante CPU "commerciali", ma
sebbene siano di giganti come Texas Instruments o Analog Devices i
compilatori C++ sono poco piu` che una burla.
Anche io trovo inutile fare disquisizioni sulle potenzialita` teoriche
dei compilatori, dato che fino a prova contraria cio` che si usa sono i
compilatori reali e non i draft ISO/ANSI. :)
--
Lorenzo

 lo standard C99 ha adottato?
Ho fatto una piccola ricerca, ed ho trovato questo link, molto 
interessante:
 
http://david.tribble.com/text/cdiffs.htm
evidenzia tutte le differenze ed incompatibilità fra C90, C99 e C++98, 
con tanto di esempi.
Una curiosità: sul link che mi portava a questo (e che sfortunatamente 
non ho annotato) c'era uno stato dei compilatori più comuni (ambito PC) 
in riguardo al C99, ovvero il risultato di ricerche fatte sul sito dei 
produttori (non so adesso in che data).
Ne risultava che Microsoft e Borland non avessero nessun riferimento a 
"C99", mentre ad esempio lo Gnu C/C++ ha una pagina specifica con lo 
stato dell'implementazione.
Lou

Lawrence Oluyede wrote:

Questioni di livello dei linguaggio (studia i "function
point" per la definizione precisa, anche se le tabelle di
livelli di linguaggio che troverai in rete sono vecchie un'idea
possono sempre darla).  Grosso modo, una relazione X : Y : Z : T
dove X e` un linguaggio del primo gruppo (altissimo livello),
Y del secondo (medio-alto), Z puo` essere il C, T l'assembler,
propone rapporti piu` o meno costanti (1 riga di Z equivale a
N righe di Y, 1 riga di Y equivale a N righe di Z, ecc).
Piu` il linguaggio e` ad alto livello, maggiore la produttivita`
del programmatore, minore la "micro-ottimizzabilita` delle
prestazioni" a parita` di qualita` del compilatore (anche se
alcuni compilatori, come quello O'Caml, a volte sono davvero
sorprendenti, bisogna ammetterlo), quindi maggiore la probabilita`
che occasionalmente serva un 'aiutino' in un collo di bottiglia.
Alex

che occasionalmente serva un 'aiutino' in un collo di bottiglia.
ho compreso il ragionamento ma non comprendo la tua
distinzione...Java e Python non sono allo stesso livello?
--
Lawrence Oluyede
rhy...@myself.com

Lawrence Oluyede wrote:

No.  Vedi ad esempio i nuovi libri "in cottura" da Bruce Eckel,
guru ed autore del best seller "Thinking in Java" e altri (sul
suo sito trovi le beta dei suoi libri).  Python offre circa un
fattore 5 o 10 di produttivita` in piu` rispetto a Java a parita`
di altri fattori (usando Jython ottieni facilmente questa parita`
poiche` da Jython usi JVM e tutte le librerie disponibili per
Java.  Infatti Bruce in "Thinking in Java" mostra come accedere
a Jython da Java, e con che vantaggi; e in "Thinking in
Patterns" / "Thinking in Python" cominci a vedere caso per
caso gli enormi vantaggi del polimorfismo basato su firme e
della dinamicita` di Python rispetto alle scelte di progetto di Java.
Il confronto diretto e` piu` difficile, ma linguaggi come Ruby,
O'Haskell o Erlang offrono sostanzialmente lo stesso livello
di Python (si dibatte su dettagli, NON su ordini di grandezza).
O'Haskell in particolare lo fa in forma staticamente tipizzata
(gli altri sono tutti dinamici -> vita + facile, ma problemi i per
i davvero-paranoidi).
Vediamo l'esempio tipico in Python e Haskell:
qsort []     = []
qsort (x:xs) = qsort lt_x ++ [x] ++ qsort greq_x
                 where
                   lt_x   = [y | y <- xs, y < x]
                   greq_x = [y | y <- xs, y >= x] 
def qsort(xs):
  if not xs: return xs
  x = xs[0]
  lt_x = [y for y in xs[1:] if y < x]
  greq_x = [y for y in xs[1:] if y >= x]
  return qsort(lt_x) + [x] + qsort(greq_x)
Spero che l'equivalenza di livello fra i due linguaggi sia chiara
da questo banale esempio.  (Ovviamente in pratica userei
xs.sort(), questo e` appunto solo un esempio!).  In ambo i
linguaggi si potrebbe scrivere tutto in un solo statement, do
nomi ai risultati intermedi solo per chiarezza, ok?
In pratica, in un linguaggio di altissimo livello un quicksort
programmato in termini elementari e` circa 1 statement.
Come puoi pensare che siano allo stesso livello linguaggi
dove programmare quicksort in termini elementari richiede
5-10 statement?
Questo non perche` quicksort sia il tutto del programmare:
e` solo un tipico compito di intelligente rimescolamento di
dati.  Grosso modo, il rapporto si estende ad altri compiti
tipici, a parita` di librerie disponibili.
Alex

5-10 statement?
Credo di aver compreso quello che hai appena
spiegato....grazie
--
Lawrence Oluyede
rhy...@myself.com

 quei due libri non sono per programmatori Python esperti?
'Thinking in patterns' richiede un poco di esperienza di Java, ma
non di Python.  L'altro e` ancora troppo acerbo per principianti,
in effetti.
Alex

                    greq_x = [y | y <- xs, y >= x] 
Non conosco Python, ma la gestione delle liste mi sembra molto simile al 
Prolog (ed i suoi dialetti), solo che ne ricordo qualcosa di risalente 
ad una quindicina e più di anni fa: non è che hanno reinventato un'altra 
ruota?
Lou

Lou Cyphre wrote:

Questo e` Haskell, non Python.  Le novita` di Haskell (che ha una ventina
d'anni, considerando il diretto predecessore Miranda) rispetto ai linguaggi
precedenti (soprattutto Lisp) non sono certo nella gestione delle liste (in
cui il Lisp non lo batti...), ma nell'impostazione funzionale senza 
compromessi, con semantica rigorosamente lazy, sintassi pulita e
limpida, tipizzazione statica (senza bisogno di 'dichiarazioni', ovvio,
che quelle sono tecnologie anni '50: e` il lavoro del compilatore quello
di fare inferenza di tipi), typeclasses, monads, ecc.  (Se dovessi invece
spiegarti le differenze da ML dovrei puntare su altri aspetti).
Se cerchi un linguaggio multiparadigma funzionale / logico dai se mai
un'occhiata a Mercury o Mozart.  Haskell non supporta il paradigma
logico (come peraltro non lo supporta Python: OO, procedurale,
funzionale e generico/polimorfico sono i suoi paradigmi principali).
Alex

 spiegarti le differenze da ML dovrei puntare su altri aspetti).
Mah! Non sono sicuro che le dichiarazioni siano "tecnologie anni '50".
Se il linguaggio le gestisce bene, le dichiarazioni di tipi e dati
sono fondamentali in fase di manutenzione del codice.
L. Micheletto

 sono fondamentali in fase di manutenzione del codice.
Se il linguaggio le gestisce bene, le dichiarazioni te le fa LUI.  Perche`
_obbligare_ un essere umano a fare il lavoro di un computer?!  Ad
esempio, quando compilo con Haskell la definizione di qsort di cui ai
miei ultimi post, il compilatore inferisce il tipo (parametrizzato):
qsort :: Ord a => [a] -> [a]
Cioe`, per un qualsiasi tipo a di metaclass Ord ("ordinabile"), qsort
ha in input una lista di a, e in output una lista di a.  Ovviamente puoi
riportare questa asserzione (o qualsiasi altra da essa inferibile) nel
tuo codice, se la tua suite di test e` cosi` scarsa da doverti attaccare
a questi aspetti di ridondanza per garantire che al minimo edit non ti
crolla il mondo addosso (ma investiresti meglio il tuo tempo a rendere
piu` forte la tua suite di test: anche la piu` rigida type-correctness
statica del tuo programma non ti garantira` mai contro gli errori di
battitura piu` banali come usare un + invece di un - in un'espressione,
che una decente suite di test scoprira` subito, come pure scopre 
qualsiasi problema di tipizzazione, errori di logica, eccetera).
Finche` non avrai sostanziale esperienza [a] di un sistema di
tipizzazione rigorosa e inferenziale (Haskell, ML, ecc) e [b] di un
linguaggio di altissimo livello totalmente dinamico (Python, Erlang,
Ruby, ecc), non credo tu possa avere solide basi per le tue
opinioni su cosa sia o meno fondamentale usando i linguaggi
giusti.  Personalmente, ho esperienza sia di questi, sia dei linguaggi
cui probabilmente ti riferisci (tipo Java e C++: quest'ultimo e` stato
alla base della mia attivita` principale per anni, sinche` finalmente non
ho trovato buone opportunita` di guadagnarmi la pagnotta usando
invece Python -- sono tutt'ora MVP di Brainbench per il C++, e
faccio anche consulenze basate su Java e C++ se i soldi in gioco
sono abbastanza, per cui non e` che li scordero` facilmente:-),
quindi penso di avere un quadro complessivo piu` ampio.
Alex

Alex Martelli wrote:
 > crolla il mondo addosso (ma investiresti meglio il tuo tempo a rendere
 > piu` forte la tua suite di test: anche la piu` rigida type-correctness
 > statica del tuo programma non ti garantira` mai contro gli errori di
 > battitura piu` banali come usare un + invece di un - in un'espressione,
 > che una decente suite di test scoprira` subito, come pure scopre
 > qualsiasi problema di tipizzazione, errori di logica, eccetera).
IMHO in questo modo il problema si sposta alla test suite, e' piu
ridotto, ma resta.
So bene che piu lavoro fanno i tool/compilatori e meglio e' , ma torna
utile anche poter esplicitare i vincoli su tipi di dati e variabili
quando serve; tali funzionalita e' meglio che siano previste
dal linguaggio (in modo da averle in una forma standardizzata)
ed e' meglio che siano obbligatorie (semmai, se per certe variabili
decido di lasciare la tipizzazione al compilatore o al runtime che
almeno renda la cosa esplicita).
Non discuto i notevoli pregi di linguaggi come Haskell o Python
ma proprio per la loro natura con essi non si puo sviluppare
qualsiasi tipo di applicazione visto che presuppongono
la presenza nel runtime di funzionalita (per loro) a basso livello
non banali; in particolare che io sappia con essi non si sviluppano
applicazioni "troppo vicine all'hardware" in cui sono evidenti
i vantaggi delle dichiarazioni di tipi di dati e di variabili.
Non si puo definire "vecchia tecnologia" qualcosa che conserva
la sua validita.
L. Micheletto

 la sua validita.
Ma questa validita` bisogna dimostrarla, e tu la stai invece soltanto
asserendo ripetutamente.  La tua asserzione si riassume in: e`
meglio rendere obbligatorio per il programmatore dovere esprimere
ridondantemente certi vincoli, e non altri, "perche` si`".  E, putacaso,
quei vincoli di cui tu asserisci (senza uno straccio di ragionamento in
supporto) che e` opportuno rendere obbligatoria l'espressione
ridondante, sono proprio quelli che farebbero comodo ad un linguaggio
ed un compilatore basati su tecnologie vecchie e superate (ad esempio,
un sistema di tipi traballante ed incoerente come quelli di tutti i 
linguaggi piu` diffusi, con le sue radici negli anni 60/70).  Ma guarda te.
L'unico (enorme) vantaggio delle tecnologie antiquate e` il loro
radicamento nella testa della gente.  Non ci sono mai abbastanza
persone con l'umilta` intellettuale di fare un passo indietro e dire
"forse la cosa piu` importante che ho imparato in decenni di pratica
professionale e` che le stesse basi concettuali delle tecnologie che
meglio conosco e piu` uso sono mal fondate"; molto, molto piu`
comodo, certo, fare l'apologista per queste tecnologie cosi` aduse e
familiari, magari con argomenti cosi` evidentemente deboli come un
richiamo alla pretesa utilita` di queste tecnologie nella programmazione
di basso livello (come se per quest'ultima non si potessero anche usare
linguaggi-macchina indifferenti a queste prassi!) o "nella manutenzione"
(come se una ricca suite di test non fosse evidentemente necessaria
E sufficiente per garantire questa importante prassi).
L'enorme inerzia collettiva garantisce che la tecnologia obsoleta avra`
davanti a se ancora un lungo periodo di uso e sviluppo.  Nel contempo,
la superiorita` intriseca delle tecnologie alternative ricava interessanti
nicche ecologiche per quella minoranza di tecnici e ricercatori che hanno
una diversa flessibilita` mentale; occorre una certa "massa critica" in
ciascun caso, ma basta abbastanza poco, se la dominanza tecnologica
e` sostanziale e soprattutto se la tecnologia alternativa ha la capacita`
di infiltrare e sfruttare le nicchie ecologiche del mainstream.  E` questa
una delle grandi forze di Python: non e` cosi` puro e perfetto come, che
so, Haskell, ma ha un'incredibile capacita` di "radicamento in nicchie
aliene" -- il che pragmaticamente significa che un numero crescente
di professionisti e aziende possono sfruttarne i benefici anche inserendolo
al margine in catene di produzione dominate da tecnologie vetuste --
una forza che e` sempre mancata ad altri pur ottimi linguaggi come
quelli funzionali, Smalltalk, Dylan, quelli logici, ecc.
Alex

Alex Martelli wrote:
 > Lorenzo Micheletto wrote:
 >         ...
 >
 >>Non si puo definire "vecchia tecnologia" qualcosa che conserva
 >>la sua validita.
 >
 >
 > Ma questa validita` bisogna dimostrarla, e tu la stai invece soltanto
 > asserendo ripetutamente.  La tua asserzione si riassume in: e`
 > meglio rendere obbligatorio per il programmatore dovere esprimere
 > ridondantemente certi vincoli, e non altri, "perche` si`".  E, putacaso,
 > quei vincoli di cui tu asserisci (senza uno straccio di ragionamento in
 > supporto) che e` opportuno rendere obbligatoria l'espressione
 > ridondante, sono proprio quelli che farebbero comodo ad un linguaggio
 > ed un compilatore basati su tecnologie vecchie e superate (ad esempio,
 > un sistema di tipi traballante ed incoerente come quelli di tutti i
 > linguaggi piu` diffusi, con le sue radici negli anni 60/70).  Ma guarda te.
Vediamo di capirci, pure Haskell supporta le definizioni esplicite
ma non le rende obbligatorie perche puo *anche* gestire autonomamente
la tipizzazione.
Ha pure i costruttori "rigorosi" (gli strict constructors)
e quindi la "vecchia tecnologia" c'e' ancora tutta e viene usata
anche in Haskell.
Haskell semplicemente usa per default il suo meccanismo di
tipizzazione automatica e di lazy evaluation, ma questo di per se
rispetto ad un linguaggio equivalente che richiede che l'attivazione
di tale meccanismo sia esplicita non e' un gran vantaggio, viene
semplificata la codifica ma in cambio si rende piu facile
l'abuso della lazy evaluation IMHO.
L. Micheletto