CdP, Lezione 1: le variabili (parte 1/2)

Premessa: questa lezione mi era venuta troppo lunga e così l'ho spezzata in due parti. Per la verità in questa prima parte neppure parleremo di variabili ma non mi andava di cambiargli il titolo! La seconda parte, con esempi ed esercizi, (e finalmente le variabili) la pubblicherò domani...

Anche questa lezione, come la precedente puramente introduttiva, sarà piuttosto facile e probabilmente noiosa per chi già conosce un minimo la materia. L'idea è infatti quella di introdurre il concetto di variabile: in effetti ci sarebbe moltissimo da dire su di esse ma ho deciso di optare per un approccio “morbido” senza voler cioè fornire informazioni non essenziali.

Come spiegato nella lezione precedente il mio obiettivo è quello di insegnare ai miei lettori come costruire un algoritmo per risolvere un problema: il passaggio successivo, ovvero l'implementazione dell'algoritmo in un linguaggio di programmazione vero e proprio, lo faremo a parte perché, al di là dei possibili problemi tecnici, è facile e scarsamente interessante.

Prima di entrare nel vivo è quindi necessario fornire una definizione di “algoritmo”. Sono sicuro che in rete ci saranno definizioni più accurate e corrette della seguente ma, come spiegato, voglio dare delle informazioni essenziali (*1), i casi speciali o molto rari non mi interessano.
Un algoritmo è:
1. una lista ordinata di istruzioni,
2. non ambigue e
3. deterministiche
4. per raggiungere uno scopo

Vediamo nel dettaglio i vari punti.
1. una lista ordinata di istruzioni: significa che l'ordine con cui i vari passaggi devono essere eseguiti è esplicito; non significa che le istruzioni debbano essere tutte in sequenza perché sarà infatti possibile “saltare” da una parte all'altra della lista. Importante la parola “istruzioni”: con “istruzione” non intendo necessariamente l'equivalente di un singolo comando di un linguaggio di programmazione ma anche qualcosa di più generico e complesso (sebbene non ambiguo!) come ad esempio “Lettura dei dati dal disco” oppure “L'utente inserisce i dati”. L'idea dietro a un algoritmo non è infatti quella di risolvere immediatamente tutti gli aspetti del problema ma di creare una base di partenza che potrà poi essere ampliata quando necessario. Da un punto di vista pratico questa apparente genericità non è affatto un problema: come vedremo, nello pseudo codice, queste istruzioni più generiche (ma non ambigue!) si tradurranno con delle chiamate di funzioni (le funzioni le vedremo prossimamente in un'altra lezione) come “LetturaDatiDalDisco();” oppure “InserimentoDatiUtente()”. In altre parole, anche nello pseudo codice, non ci preoccuperemo della struttura interna di queste funzioni e potremo così concentrarci sugli aspetti più essenziali dell'algoritmo. In seguito ognuna di queste istruzioni generiche dovrà essere espansa in un algoritmo separato. Questa compartimentazione è però molto utile perché aiuta lo sviluppatore a concentrarsi sugli aspetti fondamentali di un problema rimandando i dettagli, che potrebbero anzi causare confusione, a un secondo momento.
Tutto questo può suonare più complicato di quanto non sia: quando inizieremo a scrivere algoritmi non banali farò molti esempi che chiariranno bene questo modo di procedere.
2. non ambigue: le singole istruzioni devono essere chiari e non lasciare incertezze su cosa si debba fare. Se si pensa a un algoritmo come a una ricetta di cucina allora delle istruzioni non ambigue sono: “riempire la pentola con 1 litro di acqua per ogni 250 grammi di pasta”, “portare l'acqua ad ebollizione”; sono invece istruzioni ambigue “riempire la pentola con acqua abbondante”, “salare quanto basta”. Ugualmente precise dovranno essere le istruzioni dell'algoritmo: non si potrà scrivere “aumentare la variabile X di un po'” ma si dovrà specificare “aumentare la variabile X di 10”!
3. deterministiche: le singole istruzioni non possono basarsi sul caso. Non potrà esserci un'istruzione che dica “fai X oppure fai Y” ma dovrà essere del tipo “fai X se XXX altrimenti fai Y”. Questo non significa che in un algoritmo non si possa simulare il caso: un'istruzione della forma di “il 50% delle volte fai X, il 40% Y e il 10% Z” è lecita; sbagliata sarebbe “fai spesso X, un po' meno frequentemente Y e raramente Z”!
Insomma, per certi versi, il requisito di non ambiguità e il determinismo si sovrappongono...
4. per raggiungere uno scopo: un elenco a casaccio di istruzioni, benché ordinato, non ambiguo e deterministico, che però non risolve nessun problema non è un algoritmo (*2)!

Per scrivere i nostri algoritmi ci serviremo di uno pseudo codice: vediamo quindi che caratteristiche dovrà avere!
Poiché deve essere in grado di descrivere un algoritmo dovrà averne almeno la stessa espressività: dovrà quindi essere una sequenza di istruzioni ordinate, non ambigue e deterministiche. In più dovrà anche essere coerente: istruzioni dello stesso tipo andranno indicate sempre nello stesso modo.
La mia idea è di presentare lo pseudo codice che adoperò via via che introduco nuovi concetti...

Conclusione: a domani per le variabili!

Nota (*1): se in seguito mi accorgerò di aver dimenticato qualcosa di importante correggerò la mia definizione e informerò gli studenti.
Nota (*2): probabilmente risento ancora di quanto studiato su Kant (v. Su Kant, la metafisica della morale e altro): un'azione che si conforma alla morale, senza però essere fatta per la morale non può essere definita un'azione morale. Lo scopo è almeno tanto necessario quanto il mezzo: mi pare che ciò abbia senso anche per gli algoritmi! Vedere anche il corto KGB precede Kant che precede KGB...

Share