[Linuxtrent] Re: Applicazioni in Pascal
- From: Luca Manini <manini.luca@xxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Mon, 31 Oct 2005 12:01:52 +0100
>>>>> "Toyotoshy" == Toyotoshy <umbertobox@xxxxxxxx> writes:
Lele> Il Pascal è un ottimo linguaggio, abbastanza semplice e
Lele> molto di legno, particolarmente adatto per insegnare a
Lele> programmare per la sua chiarezza, a discapito con
Lele> concisività. Negli anni recenti, ha
Toyotoshy> 1) e' questo il principale motivo per cui nelle scuole
Toyotoshy> superiori si tende ad insegnare il Pascal piuttosto che
Toyotoshy> il C?
Azzardo (nel senso che non vado a controllarne la validità) una
spiegazione storica. Chi insegna (di solito) informatica alle
superiori? I laureati in matematica? Se sì quali laureati, quelli
che hanno scelto l'indirizzo "didattico"? Se sì l'esame di TAMC
(teoria e applicazione delle macchine calcolatrici?) mi pare
fosse obbligatorio (forse solo de facto) per quell'indirizzo? Se
sì che linguaggio si insegnava? Credo Pascal (ed infatti io me lo
sono saltato).
Toyotoshy> 2) Secondo voi pensare di insegnare alle superiori il C
Toyotoshy> ... e' un delirio vero e proprio?
Io credo che si possa insegnare C come primo linguaggio (l'ho
anche fatto, qualche volta), anche se forse non è la scelta
migliore. Come dici tu è una questione di tempo (sia di tempo
totale che di prospettiva temporale) e di obiettivi.
La mia impressione è che il C ponga due grossi problemi al momento
di utilizzarlo per la prima volta:
1) gestione memoria (malloc/free);
2) puntatori (che sfuggono);
3) puntatori (casting).
Notare che la gestine (manuale) della memoria è effettivamente
solo una palla, è definitivamente meglio avere un garbage
collector (che funzioni) che non averlo. Peraltro, per molti
programmi anche "veri" i memory leak NON sono un problema, quindi
c'è una sola soluzione banale, non fate mai free della memoria.
I puntatori sono, alla fine, uno strumento utile, ma all'inizio
"tagliano troppo" e "sfuggono". Incapsulate tutto ciò che taglia
in funzioni/strutture che non tagliano: alla fine, programmare è
astrarre, quindi...
La questione del casting (ovvero di usare puntatori alla struttura
"sbagliata") è, nella mia esperienza, un falso problema perché
(per le cose che uno deve scrivere all'inizio -- e non solo) ha
una soluzione banale: scrivete ANSI C, non mentite al compilatore,
usate il gcc con -Wall.
Secondo me, il problema pratico più grande al momento di insegnare
C è che si deve anche insegnare anche un bel pezzo di ambiente
(include, make, librerie, gcc, loader, ..., Emacs) e che occorre
"più disciplina" (per esperienza so che gli " studenti" soccombono
sempre alla tentazione di scrivere una cosa a caso, sperare che
"funzioni" e altrimenti sperare di capire perché no -- con il C
non mi pare il caso!)
Da questo punto di vista altri "ambienti" sono molto migliori;
facci oun esempio con Python perché lo conosco abbastanza:
- niente ciclo di compile-run;
- librerie per semplice copia incolla in un altro file "di lato";
- uso automatico della versione più recente (file) della lib;
- traceback autoesplicativo;
- garbage collection;
- dynamic typing;
Toyotoshy> ed andare pian pianino verso il java (e dunque verso la
Toyotoshy> programazione ad oggetti) e' un delirio vero e proprio?
A parte il fatto che della questione "oggetti" il lato
programmazione (piuttosto che analisi e/o design) non è forse
quello centrale, resta il fatto che è solo uno dei possibili
paradigmi. Per insegnarlo bene lo si deve insegnare
"motivandolo", e un linguaggio in cui la scelta è già stata fatta
non mi pare proprio il massimo. In altri linguaggi (OK, sempre
Python, ma è anche per risparmiarvi Oz [http://www.mozart-oz.org])
uno può programmare procedurale, funzionale, a oggetti, streaming
e quindi "va a oggetti" solo quando gli pare il caso.
--
bye, Luca
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
