Newsgroup: it.comp.programmare
Titolo: ***CHIEDO AIUTO AGLI ESPERTI***

Salve a tutti!
Da un po' di tempo mi sto interessando alla programmazione.
Per ora ho letto un paio di libri su Visual Basic e diciamo che più o meno
me la cavicchio ma senza saper fare nulla di eccezionale.
Diciamo che ho ben presente i meccanismi delle procedure, delle funzioni,
delle variabili, ecc... ma sono molto carente in controlli ActiveX e simili.
Siccome comunque la programmazione mi appassiona molto, voi ora cosa mi
consigliate di fare?
Secondo voi mi conviene approfondire la conoscenza del Visual Basic (nel
caso potreste consigliarmi qualche guida o manuale?) oppure passare a
qualche altro linguaggio?
Io pensavo di buttarmi su qualche altro linguaggio ma non sono sicuro sicuro
che sia la cosa giusta e non sono neanche sicuro su quale linguaggio
provare. Avevo pensato al Java o al Perl (di cui però non ho trovato nessuna
guida) o al Pascal (anche su questo mi sembra che il materiale sia scadente)
o al Delphi o al Phyton... Avevo escluso il C solo perchè mi hanno detto che
è parecchio complesso e forse prima è meglio impratichirsi con qualche altro
linguaggio.
Avevo anche pensato di imparare un po' di programmazione in Unix ma anche su
quello sono indeciso (strano vero?).
Confido in voi per fare un po' più di chiarezza nella mia testa confusa :-)
(sarebbe gradito se nei consigli che spero mi darete compaiono dei
riferimenti a eventuali guide o manuali cartacei da acquistare)
--
Ciao
Elminster
Togli "TOGLI QUESTO" dal mio indirizzo per rispondere

 riferimenti a eventuali guide o manuali cartacei da acquistare)
Non e` cartaceo, ma il manuale di Gauld tradotto in italiano da Fini, a:
http://www.freenetpages.co.uk/hp/alan.gauld/italian/index.htm
e` un ottimo modo di iniziare, centrato su Python ma con i necessari
cenni ad altri linguaggi (come Basic e Tcl) cosi` da aiutare il lettore a
distinguere quel che sta imparando sulla programmazione in generale
da quel che sta imparando specificamente sul dato linguaggio.
Alex

 quello sono indeciso (strano vero?).
Se impari bene il C conosci già il 50 %0 della programmazione in Unix, in 
quanto buona parte delle funzioni della libreria standard del C sono API 
di *nix.
-- 
Andrea Bergia - studente
Linux Registred User #281550

 interpretato...
Non conosco bene Python ma mi sembra che qui ci sia un'inesattezza.
Che io sappia la tipizzazione delle variabili in Python esiste, ma e'
dinamica.
E questo non vuol dire che sia meno forte che in altri linguaggi.
Parlare, poi, di "linguaggio interpretato" non ha molto senso, nessuno vieta
di scrivere un compilatore anche per Python.
--------------------------------
Inviato via 
http://usenet.libero.it

dinamica.
confermo
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

 vieta di scrivere un compilatore anche per Python.
Gia`.  Si potrebbe sperare che dopo tutti questi anni di sterili
polemiche in merito relativamente a Java, non si dovessero piu`
sentire "ragionamenti" del genere, ma apparentemente la mala
pianta non si sradica.  La situazione di Python e` virtualmente
identica a quella di Java: il compilatore c'e`, e produce
bytecode (in Python classico, il compilatore viene invocato
implicitamente e trasparentemente la prima volta che viene
importato un moduio non ancora compilato a bytecode); c'e` anche
l'interprete, noto anche come macchina virtuale, che ha il compito
di garantire l'esecuzione del bytecode indipendentemente dalla
architettura della macchina-fisica sottostante.  Esiste anche una
versione di Python (nota come Jython) che permette anche di invocare
un esplicito passo di compilazione che produce esattamente i tipi
di file (.class o .jar) usati da Java, e usa come suo bytecode il
bytecode tipico della Java Virtual Machine: presumibilmente, chi
disponesse di un compilatore da bytecode-JVM a codice nativo fatto
sufficientemente bene (non quello di gcc 3, ancora acerbo...:-)
potrebbe quindi produrre gia` oggi codice nativo a partire dai
sorgenti Python, ne` piu` ne` meno come a partire da quelli Java.
Alex

 dinamica.
Questo lo so. Mi sono spiegato male, lo ammetto. Quello che intendevo io è 
che non mi piace molto avere cose tipo:
a = "Ciao mondo"
a = 3 * 2
a = dir
Preferisco avere variabili di un certo tipo X a cui posso assegnare solo 
oggetti X. Gusti personali, che ci vuoi fare? ;-)


 oggetti X. Gusti personali, che ci vuoi fare? ;-)
Domanda interessante, volendola prendere sul serio.  Personalmente
suggerirei di iniziare con una disamina accurata dei pro e contro
della possibilita` di assegnare vincoli alle variabili, pero` non
certo limitata ai vincoli che un dato linguaggio X ti permette (o
ti obbliga), probabilmente legati alla comodita` d'implementazione
di X piuttosto che non alle effettive necessita` applicative.
Per esempio, potrebbe essere interessante asserire che il nome
'a' puo` essere applicato solo a numeri interi, positivi, pari,
senza un valore massimo predefinito.  Quali linguaggi ti permettono
di esprimere questo tipo di vincoli?  Mi viene in mente Mercury,
e se non sbaglio puoi fare cose simili in Oz, almeno nella
versione Mozart.  Ho solo sentito nominare altri linguaggi capaci
di compiti simili, come CLPR ed Eclipse, ma non ne so molto.
Comunque, il "constraint-oriented programming" e` sicuramente
un paradigma degno di nota.  Al giorno d'oggi e` ancora un campo
di ricerca: se quel che fai nella vita e` ricerca in questo ambito,
tanto di cappello, ma se vuoi sviluppare codice "di produzione",
non mi pare (ancora) il caso.
Se non puoi esprimere i VERI vincoli che discendono dalla tua
applicazione, quali ulteriori vantaggi restano a poterne esprimere
"alcuni, quelli che fan comodo all'implementatore del linguaggio
X"?  Sostanzialmente la possibilita`, per le implementazioni di
X, di generare codice piu` performante con fatica molto minore
nell'implementazione.  Un'implementazione ideale non ha bisogno
di simili stampelle (e` in grado di _inferire_ i tipi: Haskell
ad esempio lo permette in tutte le sue implementazioni), ma non
e` banale arrivarci (soprattutto per i linguaggi che permettono
molteplici successive assegnazioni allo stesso nome -- comunque,
e` possibile: vedi il compilatore "stalin" per il linguaggio
dinamico Scheme).
Se l'esigenza e` appunto una di ottimizzazione, suggerisco di
riflettere sul noto principio di Knuth: "L'ottimizzazione
prematura e` la radice di tutti i mali".  Certo non vorremo
iniziare ad ottimizzare prima ancora di aver cominciato a
scrivere il programma: piu` prematuro di cosi`!  Piuttosto, si
puo` intervenire inserendo vincoli di tipo quando il programma
e` funzionante ma non presenta prestazioni sufficienti.
Un linguaggio basato fortemente su questo principio e` Dylan,
certo molto interessante (anche se a mio vedere il ricchissimo
sistema di macro di cui e` dotato lo rende troppo complesso).
Ma si puo` seguire una strategia simile con Python: la
versione di Python che permette di vincolare i tipi di
alcune variabili, e produce codice macchina di conseguenza,
si chiama Pyrex ed e` in corso di sviluppo a parte di Greg
Ewing, 
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
 .
L'attuale versione 0.4.4.1 e` decisamente gia` usabile.
Personalmente, sono ancora piu` a mio agio a riscrivere il
codice da ottimizzare in C o C++ -- e` comunque tanto poco,
che lo sforzo non e` poi sostanziale -- ma devo ammettere
che Pyrex e` un progetto molto interessante e lo seguo con
la speranza di farne presto uso in produzione.
Alex

la speranza di farne presto uso in produzione.
Io spero di farne uso perchč trovo l'API per il C/C++ un pň...boh nn
ostica ma dispendiosa


 ostica ma dispendiosa
Quella del C e` necessariamente verbosa, perche` il C e` un
linguaggio di livello molto basso.  Per il C++, hai la scelta
fra varie soluzioni di piu` alto livello, e Boost nella nuova
versione 2 dovrebbe essere la migliore.
Alex

versione 2 dovrebbe essere la migliore.
il punto è che io nn sono MVP come te :)
Faccio parte della schiera di quelli che usano il C++ come se fosse
C. Quindi in pratica conosco solo il C e qualcosina del C++. Non credo
che la cosa migliorerebbe per me :)


 che la cosa migliorerebbe per me :)
Prova magari SCXX di Gordon McMillan: usa solo qualcosina del C++
(l'intenzione e` di supportare compilatori del cavolo, non "la
schiera" che dici, ma forse puo` venirti comunque comodo:-).
Comunque se vuoi _sostanzialmente_ programmare in C, c'e` poco
da fare: linguaggio di basso livello, quindi necessariamente
le interfacce espresse in esso saranno piu` grosse e verbose
di quelle espresse a livelli + alti.
Lungi da me volerti scoraggiare dallo studio di Pyrex, nota
bene: come dicevo e` una prospettiva assai interessante.
Alex (appunto MVP, come dicevamo, di Brainbench per il C++)