Insegnamento: scelta tra C o C++

[DispatchCode]

Ho letto proprio poco fa qualche post in una discussione, che potete trovare qui, ed ho pensato di aprire io stesso un topic in quanto avrei risposto, aggiungendo altro OT... e quasi sicuramente non avrei permesso l'inizio di una discussione che spero potrà dirsi pacata e costruttiva, oltre che interessante ai più :D con considerazioni anche tecniche e non solo di cosa è "più conveniente trattare tra C e C++".

Cito quindi alcuni dei partecipanti, magari interessati al proseguo: @rodhellas , @Marcus Aseth e @Andretti60

Scrivo di seguito quanto avrei scritto in quel topic.

---

Molto interessante, grazie per aver condiviso :)
Se fosse il mio professore avrei altre domende da fargli al riguardo, ad esempio, tutto il codice scritto da te sopra di fatto è C++, la differenza più ovvia magari (con la premessa di non usare vector o altre "data structure" che ci sono solo in C++ e non in C) sarebbe che se scritto in C++, probabilmente il "scanf" sarebbe rimpiazzato da "cin" e "printf" sarebbe rimpiazzato da "cout", ed essendo "cin" ed "cout" più "user friendly" o "eleganti" (imho) rispetto a "scanf" e "printf" (non devi memorizzarti una lista di %d %s ecc...), allora qual'è il vero vantaggio di farlo in C?!
Insomma finirei per tormentarlo ad ogni lezione con le mie domande sul perchè :D

Quello a cui hai fatto accenno è forse un altro dei problemi delle scuole. Far passare l'insegnamento di uno pseudo C++ solo perchè si stanno utilizzando cin e cou.
A scuola sarebbe forse meglio guidare i ragazzi alla logica, condurli nei ragionamenti soffermandosi sul problem solving... non spiegare 1/10 del linguaggio (spesso anche male quando c'è di mezzo C++, proprio perchè si importa iostream al posto di stdio, e si dice che "questo è C++"). Per le università il discorso è differente, ma alla fine i linguaggi li apprendi fuori dalla scuola; non dico sul campo, non necessariamente, ma da autodidatta.

Io sono per tenere tutte quelle basi di C che permettono di capire bene come programmare ma allo stesso tempo prendere certe parti di C++ (come il cout) che rimuovono complessità inutile e permettono di concentrarsi meglio sul problema che si sta cercando di risolvere :P

Personalmente il misto C/C++ un pò "come viene" o "in base ai gusti" ("sale e pepe q.b." :D) lo trovo controproducente: o uno o l'altro. E considerando che l'altro (C++) è OOP, potrebbe non essere la scelta più indicata per gli studenti di un terzo anno di superiori, se prima non vengono fornite altre nozioni (argomenti di per sè complessi da trattare, considerando il numero di ore a disposizione anche).

Mi permetto di riprendere anche un tuo precedente intervento Marcus, poco più sopra, in risposta a rod, poichè vorrei aggiungere alcune cose:

Ah, pensavo ci fossere anche in C con quei nomi. Ma quello che penso è, se C++ offre degli strumenti che rendono il tutto più sicuro evitando di dover andare in seguito a caccia di bug difficili da trovare...perchè ostinarsi con C?

Come diceva rod, in C hanno altri nomi.
Le funzioni sono malloc/calloc per allocare memoria, e free per liberarla (deallocarla). Se si evitano puntatori in C++ sicuramente si sta facendo cosa buona e giusta.
Ad ogni modo in C non ho mai avuto particolari problemi; di solito si risolvono aprendo un debugger (strumento che purtroppo non tutti sanno più utilizzare).

Quando fai riferimento al delete in realtà non capisco se fai anche implicitamente riferimento alla "non deallocazione" della memoria. Se così fosse, sarebbero pratiche da evitare (intendo il non deallocare), così come il perdersi un free() in C. Tuttavia se non si sta utilizzando nulla di critico, non si hanno particolari problemi.

Sopratutto considerando che un insegnante può vietare ai suoi studenti l'uso di praticamente tutto quello in più che C++ offre e fargli svolgere gli stessi esercizi come se li stessero facendo in C, o sbaglio? Per poi poter dire alla fine "questo che abbiamo visto è il modo in cui si fà in C, ed ora vediamo l'equivalente in C++" e poter fare il paragone, mostrando entrambi i metodi ed aggiungendo gradualmente

Ma che senso avrebbe allora studiare/spiegare C++, se alla fine si tratta il C (portando oltretutto confusione agli studenti che pensano di conoscere poi C++)? :) Potrebbe aver un senso paragonare davvero qualcosa di C con qualcosa di C++; ma avrebbe forse senso nelle università per trattare concetti terzi. Alle superiori è già tanto se viene trattata la scrittura su file o poco più... :D


Al momento il mio intervento termina qui. Spero di non aver aperto inutilmente un topic trovandomi a "parlare" da solo. xD

 

[Marcus Aseth]

Ma che senso avrebbe allora studiare/spiegare C++, se alla fine si tratta il C (portando oltretutto confusione agli studenti che pensano di conoscere poi C++)? :) Potrebbe aver un senso paragonare davvero qualcosa di C con qualcosa di C++; ma avrebbe forse senso nelle università per trattare concetti terzi. Alle superiori è già tanto se viene trattata la scrittura su file o poco più... :D

Bhe il modo in cui l'avevo immaginato era introdurre C++ gradualmente, ovvero ad esempio partendo da esercizi su array e pointers come fosse C per poi spostarsi all'uso di "#include <array>" in C++ per mostrare come una data structure in C++ funziona (visto che molte delle member function sono simili tra esse, come begin(), end(), emplace(), back(), front() size() ecc...) per poi proseguire con "#include <vector>" e per concludere il ciclo dissezionando la costruzione di un vector in C++ (proprio tutto, dall'implementazione del subscript operator al radoppiare la memoria allocata quando si superà la capacità del container e mostrare perchè gli iterator associati potrebbero venire invalidati ecc..), ed avere gli studenti tornare alle basi per implementare il loro vector. Dopo questo esercizio basterebbe spiegare come una linked list funziona per poter chiedere agli studenti di implementarne una dal nulla.
Comunque il punto fondamentale della mia idea era questa graduale progressione, e non continuare ad usare C++ come fosse C ignorandone tutto il resto.

Poi non so, magari nella realtà un metodo simile non funzionerebbe?! Oppure magari come dici tu non basterebbe il tempo.
Questo non posso saperlo, ma il vantaggio che vedo in questo metodo è che lo studente sarebbe esposto a più cose, e quindi quando arriva il momento per lui di decidere in che direzione portare i suoi studi (magari da autodidatta anche) sarebbe in grado di fare una scelta più informata.
Nell'altro modo, non si rischia che il soggetto in questione impari C e non si curi mai di imparare altro per il resto della sua vita, e quindi adesso hai creato un professore un pò scarso per il futuro? :D
Scarso nel senso che insegna le cose non perchè sa che lo studente avrà bisogno di quello in futuro, ma perchè è l'unico modo che conosce e quindi insegna quello perchè non ha altra scelta.

 

[BAT]

Se questa è la scelta, i corsi di Informatica alle superiori non dovrebbero chiamarsi "Informatica" ma "Corso di C" oppure "Corso di C++".
Per fare bene informatica di base e contemporaneamente un linguaggio applicativo, le ore dovrebbero essere raddoppiate: metà per insegnare a ragionare da informatico e buttar giù algoritmi (va benissimo lo pseudocodice), l'altra metà per insegnare come fare certe cose in un determinato linguaggio.

 

[Marcus Aseth]

Comunque io stesso non mi fido al 100% della mia idea di come dovrebbe essere, principalmente perchè mi rendo conto di essere pesantemente di parte :D

 

[rodhellas]

In generale ritengo che qualsiasi linguaggio vada bene per iniziare, dipende se si vuole puntare alla produttività o alla "conoscenza". Nel primo caso, un java/c++/c#/phyton e altri vanno benissimo. Hai un sacco di librerie già pronte e non ti devi solo preoccupare di incastonare i vari pezzi per ottenere il risultato.
Al contrario linguaggi come C, pascal(personalmente non conosco) e volendo assembly (prendetela con le pinze) ti costringono proprio a ragionare sul codice, a concentrarti sul singolo algoritmo e non solo su quello generale (es. maneggiare le liste in C, le prime volte son santi che partono).
Nello specifico invece, concordo con il professore di StrLght, il C ti permette di avere le basi dei più usati/famosi linguaggi; alla fine ci basta aggiungere la parte della programmazione OOP, giusto un pò la sintassi da imparare e sei già bello che pronto per Java/c#/c++ etc.
Tanto per fare un esempio, nella mia università i bioinformatici fanno solo java e hanno delle grosse difficoltà anche nelle cose più semplici. Ad informatica facciamo prima C e poi Java e ci mettiamo le mani nei capelli (o ce la ridiamo) quando guardiamo il codice di qualche bioinfo.

 

[DispatchCode]

Io ho iniziato da Java una decina di anni fa (forse proprio 10), ma senza seguire un percorso scolastico. Quindi per esperienza personale so che quando vuoi capire il funzionamento di qualcosa... al C devi arrivare, e poi magari anche ad Assembly. Va però detto che il mio "imparare Java" è stato lo studio di un libro di 1000 pagine, più o meno, oltre che molta applicazione. Ciò che intendo dire è che ho avuto modo di avere una buona panoramica del linguaggio andando per tappe, cosa che in un istituto non avrei potuto avere.

Nell'altro modo, non si rischia che il soggetto in questione impari C e non si curi mai di imparare altro per il resto della sua vita, e quindi adesso hai creato un professore un pò scarso per il futuro? :D

Perchè escludi che iniziando dal C poi non si arrivi ad altro, come Java/C# o magari anche Rust, Go etc? :D Se lavori in campo informatico non puoi scegliere di conoscere o utilizzare solo C, altrimenti non fai il programmatore.
Il problema, e parlo sempre per esperienze personali, è a mio avviso che spesse volte chi programma in altri linguaggi con più livelli di astrazione non sa ciò che sta facendo davvero, non capisce l'impatto di ciò che sta scrivendo (aggiungendo che "tanto i PC di oggi hanno buone prestazioni"). Quindi affrontare un linguaggio come C, non ti da molta scelta se non l'affrontare alcuni concetti.

Poi Assembly è un discorso a parte; penso copra quasi solo l'area dello studio e della comprensione della macchina (oltre che al reverse engineering). Il suo utilizzo è bene o male relegato all'essere utilizzato inline, dove serve (come negli OS, per gestire qualcosa di critico che non può essere fatta in altri modi).
Parlo da amante dell'assembly e suo utilizzatore (nel tempo libero). :D

 

[Andretti60]

Scusate il ritardo :)

C'e differenza tra quale linguaggio usare per insegnare a programmare e quale linguaggio imparare per primo. Sembra il classico esempio del gatto che si mangia la coda. Come insegnare a programmare se non si insegna anche un linguaggio di programmazione? Viene prima l'uovo o la gallina?

E' un problema che molti college americani hanno risolto iniziando i loro corsi usando un metalinguaggio molto semplice, con un set minimo di istruzioni, usando una applicazione scritta apposta (in genere per ogni sistema operativo), in questo modo tengono separati il contesto di teoria di programmazione e linguaggio di programmazione. Solo dopo avere imparato i concetti della programmazione, si passa poi a imparare un linguaggio, e a quel punto può essere qualsiasi.

In passato, i linguaggi preferiti per imparare a programmare erano quelli più flessibili e con il minore numero possibile di keyword. Pascal e C erano tra questi. Altri come Fortran, Basic e Lisp erano troppo specifici o non abbastanza flessibili, difficili da imparare e con i quali era molto facile scrivere codice male strutturato. Fortran e Basic per esempio non permettevano nemmeno ricorsione, che e' uno dei concetti chiave che si impara della teoria della programmazione. Un grosso vantaggio di Pascal e C e' che erano gratuiti o quasi, con buone suite di programmazione e debugger, per qualunque piattaforma.

Adesso una buona scelta per primo linguaggio da imparare e' Java. Compilatore e suite di programmazione sono ben fatti e gratuiti per ogni piattaforma e sistema operativo. Si può usare sia come normale linguaggio strutturato che linguaggio a oggetti, cosa che per esempio manca nel linguaggio C. C++ permette di utilizzare programmazione a oggetti, ma al costo di un maggiore sforzo per impararlo, causa l'elevato numero di keyword. Grosso svantaggio del C++ e' una sua cronica mancanza di standard su piattaforme diverse, se imparate C++ su Microsoft dovrete poi adattarvi se passate ad un'altra piattaforma. Non che il C sia perfetto, non avendo gestione automatica della memoria e un uso selvaggio dei puntatori lo rende perfetto per applicazioni a basso livello (tipo servizi e sistemi embedded dove aiuta molto un controllo manuale del codice) mette in difficolta' gli studenti e crea non pochi problemi di mantenimento del codice anche tra i professionisti del settore.

Detto questo, ritornando alla domanda originale, e' meglio il C o il C++? Come linguaggio educativo, nessuno dei due. Come primo linguaggio, direi il C++ perché permette la programmazione ad oggetti. Rimane comunque una diatriba interessante, che dovrebbe fare capire agli interessati del settore a non "innamorarsi" troppo di un linguaggio, ma essere pronti a impararne altri, perché ogni linguaggio ha sue applicazioni ben precise.

 

[1nd33d]

Da che mi ricordo, all'ITIS informatico il C studiato in terza superiore serviva per lo più per introdurre i concetti della programmazione. Quindi l'esistenza di linguaggi di programmazione di cui molti adottano una sintassi "C-Like", il concetto di costrutti iterativi e condizionali, variabile e riferimento a variabile (puntatore)... il C è ottimo per insegnare l'abc della programmazione e un po' di teoria sui calcolatori.
Il C++ è un altro paio di maniche e secondo me non è preferibile, a scopo didattico, ad altri linguaggi come Java (OO puro) o Python (multiparadigma). Il C++ è un linguaggio (spesso inutilmente) complesso e difficile da padroneggiare, ha senso in alcuni ambiti specifici ma non lo vedo bene a scopo puramente didattico.
Sul fatto poi che l'OO sia un plus, mah... punti di vista, secondo me il paradigma OO è sopravvalutato, e in certi ambiti è scomodo. La promessa del "rappresentare un concetto reale come un oggetto" è buona fino a un certo punto...

 

[Andretti60]

... punti di vista, secondo me il paradigma OO è sopravvalutato, e in certi ambiti è scomodo. ...

Vero, ma non vuole dire che in altri ambienti sia invece una manna :) quindi e' necessario insegnarlo a scuola.
Ormai tutti i moderni linguaggi sono OOP, ma questo non vuole dire che "bisogna" forzatamente usare tecniche di programmazione ad oggetti anche se il linguaggio lo permette.
Potremmo dire lo stesso della ricorsione. Non occorre usarla. In molto casi si e' costretti, ma ha i suoi svantaggi, ossia un consumo di memoria on indifferente per cui e' inapplicabile per un certo tipo di problemi molto complessi, specie quando occorre un controllo molto "stretto" delle risorse e del processo.

 

[1nd33d]

Certo, ogni paradigma ha il suo perchè e merita di essere studiato... dico solo che ultimamente non sto più trovando l'OO così indispensabile, lo trovo utile spesso come struttura organizzativa dei dati, ma non molto di più.
Anche la ricorsione, come strumento, ha i suoi pro e contro, bisogna saperla usare. Per esempio una tail recursion non espone al problema delle risorse e anzi è una scelta implementativa cardine del paradigma funzionale (molto usato in ambito matematico, non certo "pesante" se usato bene), che trovo molto efficace ma che è insegnato troppo poco rispetto al blasonato e fin troppo abusato (ma ultimamente in fase di ridimensionamento) OOP.
Prendi anche Java, il linguaggio OO a tipaggio forte più diffuso. Nelle ultime versioni lo stanno ibridando con il funzionale, perchè quest'ultimo paradigma sta risalendo molto velocemente.

 

[Andretti60]

OOP venne troppo osannato negli anni '80 pensando fosse la soluzione di tutti i problemi, mentre invece si è rivelato essere solo uno strumento che va bene per una certa classe di problematiche, nulla di più.

 

[NicoZ96]

Mi permetto di introdurmi nella discussione avendo fatto anche io un ITIS informatico, il mio triennio è stato più o meno così:
3^ superiore: algobuild per imparare la logica base di cicli etc -> basi di C per capire la logica della programmazione -> algoritmi di sorting -> altri algoritmi
4^ superiore: java (OOP)
5^ superiore: HTML&CSS->PHP&MySQL

Per la mia esperienza, direi che le cose, fatte in questo ordine, permettono di avere una visione generale, ampia e molto utile per qualsiasi cosa uno voglia poi fare. Ad esempio io, con le basi che ho avuto, ci ho impiegato poco ad imparare nuovi linguaggi. Al momento sto studiando per diventare un dba di SQLServer, MySQL, MariaDB e Progress (il mio capo ha deciso così :D) e con le basi fornitemi dalla scuola non sto incontrando molti problemi.
Partire direttamente con C++ è sbagliato, è molto più complicato rispetto a C. Se bisogna scegliere un linguaggio per insegnare la logica della programmazione e certi ragionamenti, secondo me C è il più adatto.