[Python] Turbopascal??

Enrico Franchi enrico.franchi a gmail.com
Lun 3 Gen 2011 15:11:39 CET




On 1/3/11 1:12 PM, "Giorgio Zoppi" <giorgio.zoppi a gmail.com> wrote:

> Sarebbe bene che all'universita di imparasse il C++ ad oggetti oltre
> che a Python o C#,

Da me lo insegnano. Io per primo sono coinvolto (in laboratorio ad
informatica). Anche ad ingegneria viene insegnato; fin troppo. Gli studenti
che ho dovuto seguire hanno detto esplicitamente di trovarsi piu' a loro
agio con C++ che con Java per i loro progetti (laurea specialistica, IIRC).

Eppure... C++ e' un incubo da insegnare. Perdi talmente tanto tempo con
problemi banali frutto di un design vecchio, quando non direttamente errato
(e Stroustrup ha l'onesta' di ammetterli) che non si ha tempo per insegnare
il resto. Ci vorrebbero il quadruplo dei corsi per insegnarlo ad un livello
decente. 

Il problema non sarebbe insegnare C++, ma insegnare:
0. a ragionare (risultato non scontato)
1. a programmare (non banale, e ci sono anche tanti studenti che
candidamente ammettono che a loro non interessa imparare a programmare)
2. a programmare decentemente
3. a programmare ad oggetti o con altri specifici paradigmi

Io credo che C++ venga in mezzo alle scatole in tutte e 4 le cose. Il
linguaggio complicato rende piu' difficile ragionarci. Il linguaggio
complicato rende meno divertente programmare (e di conseguenza meno studenti
ci si esercitano, diventando programmatori decenti). Per la 2. Si applica la
stessa considerazione per la 1., solo aggravata. C++ con il suo misturotto
di linguaggi (cft. "federazione di linguaggi" di Meyers) non aiuta.
Aggiungiamo quello che pensa Kay stesso della programmazione ad oggetti in
C++ (ovvero che quella non e' la programmazione ad oggetti che aveva in
mente lui, manco per niente) e otteniamo che C++ e' parte del problema, non
la soluzione. 

> che un utente sapesse cosa sono per esempio:
> open-close principle,
> hollywood principle,
>  Liskov Subtitution Principle, Dependency-Inversion
> Principle,Interface-Segregation Principle,
> e i design pattern.

Tutta questa roba non ha bisogno di C++ per essere insegnata. Non c'e'
niente di C++ che serva per OCP, DIP, inversion of control. Anzi, e' mio
parere che (come al solito) C++ venga fra le scatole anche per spiegare
questi concetti e che aggiunga complicazione.

Anche ISP e LSP sono perfettamente applicabili a linguaggi dinamici, solo
sono quasi *automatici* e in un certo senso riassunti e superati dal duck
typing stesso. Ma non c'e' motivo per cui il loro insegnamento debba
dipendere da C++.

Il fatto che Uncle Bob li abbia splendidamente trattati per lo piu' in C++,
non vuole dire che non possano essere trattati in altri linguaggi.
Accidenti, era il 2000 e lui lavorava con quello! Perfino in Agile
Development, etc. comincia a farsi vedere Java.

> Mi trovo a fare refactoring di un progetto di un tesista ing., che di
> C++ ad oggetti non ha nulla.

E' abbastanza possibile che il suddetto tesista non sia capace di
programmare ad oggetti. E questo probabilmente a prescindere da C++. Se si
vuole, si programma ad oggetti anche in C, solo piu' lungo e scomodo farlo
(specie i costrutti meno elementari). 




Maggiori informazioni sulla lista Python