Newsgroup: it.comp.programmare
Titolo: Programmazione "matematica" e programmazione "logica"

Vi pongo una domanda di taglio quasi "filosofico" ma che ha risvolti
tecnici ben precisi.
In sintesi: che importanza hanno al giorno d'oggi la programmazione
"matematica" e quella "logica"?
Spieghiamo un po' e scusate le virgolette ma non trovavo termini
migliori.
[Nota biografica: ho cercato di iniziare a programmare diverse volte
nella mia vita, alla fine ci sono riuscito, dopo aver imparato a
creare pagine web, con PHP e ora sto cercando di passare da quelli che
erano script, per quanto complessi, alla programmazione "vera e
propria"]
Con programmazione "matematica" intendo quel tipo di programmazione in
cui si cerca di convertire il problema, qualunque sia, in termni
numerici e lavorando solitamente molto a basso livello. Approccio che
trovo per esempio in "Algoritmi+Strutture Dati=Programmi" di Wirth. In
passato non sono mai riuscito a farci granchè.
Con programmazione "logica" intendo invece quel tipo di programmazione
meno "legata" come può ad esempio essere quella degli script web dove
difficilmente si riesce a mettere "alla frusta" un serverone (per
esempio AIX o Sun, per fare due esempi), e quindi si tende a rendere
gli script, soprattutto all'inizio, molto "verbali" (ad esempio stati
delle operazioni in stringa anche se non è necessario e generalmente
sovrabbondanze varie). Personalmente è da qui che ho iniziato la mia
"avventura" nel mondo informatico ed è da qui che ora sto anche
"scendendo" ragionando sul come fare le cose in maniera più
efficiente.
In "mezzo", se così si può dire, ci metterei linguaggi come Python,
che sto studiando ora, che permettono allo stesso tempo di astrarsi
sufficientemente dal contatto diretto con la macchina ma anche di
abbassarsi quando serve, o almeno è la mia sensazione.
Ora, facciamo un esempio: sto provando a sviluppare (per ora studio
concettuale) un programma che permetta movimenti e azioni su una mappa
graficamente presente su schermo. Ora, le due "scuole" sopraindicate
suggerirebbero possibilità diverse:
- Logica: si crea un file mappa in cui una serie di lettere/simboli
  introdotti con un qualunque editor indica le proprietà di ogni
  casella e ad ogni grafica per caselle corrisponde un file preciso,
  per esempio un .png con nome i caratteri che indicano quel caso
  particolare
- Matematica: si crea un file mappa in cui la descrizione di ogni
  casella viene prodotta in base a una serie di valori esadecimali
  (nel mio caso 16 bit a casella) e una funzione apposita permette di
  usare i valori indicanti la grafica della casella per estrarre le
  grafiche da un file che le raduna tutte.
Ora, vediamo gli effetti di tutto questo.
[Nota: sono ovviamente tutte ipotesi "intuitive" visto che a "basso
livello" non ho mai lavorato finora]
La soluzione "logica" permette una produzione molto molto rapida del
codice per gestire il tutto, ma richiede "tabelle di traduzione" che
spieghino a cosa corrisponde ogni simbolo per il programma di disegno;
questo sporcherebbe molto il codice e renderebbe la manutenzione poco
chiara, temo.
Inoltre le grafiche finiranno per creare una montagna di file
separati, facili da editare e verificare ma terribili da gestire anche
solo per la quantità (teniamo conto che nel mio progetto ci sarebbero
16 tipi di terreno, ognuno composto da 16 "tessere" diverse e
disponibile in 16 "flavour" diversi per un totale massimo di 16^3
grafiche).
Infine viene da chiedersi quante risorse consumi un metodo che, se
anche non spreca intenzionalmente, è comunque mosso da una logica che
non è "da macchina".
La soluzione "matematica" richiede molta programmazione a tavolino ma
permette diverse cose interessanti. La sua rigidità può indubbiamente
creare problemi di manutenzione ma se l'impianto iniziale è buono è
molto probabile che non si debba rimettere eccessivamente mano al
codice in caso di sfruttamento delle stesse routine per nuovi
programmi.
Il file della mappa si riduce immensamente. Se contiamo che i famosi
16 bit definiscono 4 caratteristiche diverse (anzi 5 per come vengono
usati gli ultimi 4 bit), abbiamo che ogni casella occupa 16 bit invece
che 40 (ipotizzando 8 bit per carattere e 5 caratteri), in pratica la
lettura della mappa diventerebbe molto più veloce sia perchè il file
non viene tradotto da binario a testo sia perchè il file stesso è
molto più corto. Inoltre muovendosi a livello di bit immagino che il
movimento del cursore risulti molto più facile quando fosse necessario
ricavare oltre alla tessera "attuale" anche le circostanti, ad
esempio.
Altri probabili vantaggi? Il fatto di poter correlare il valore dei
bit che indicano la scelta del terreno ad un puntatore nel file delle
grafiche attraverso una funzione matematica.
Lo svantaggio appunto sta nel fatto che bisogna astrarsi non poco
dall'azione che si vuole far compiere per avvicinarsi invece alla
macchina, cosa molto istruttiva ma sicuramente impegnativa
(indipendentemente dal fatto che io voglio effettivamente imparare).
Ora, visto che in ogni caso la potenza e tutto il resto non mancano
proprio alle macchine recenti, la soluzione ideale sembrerebbe usare
un linguaggio tipo Python quindi dalla forte impostazione "logica" ma
per lavorare anche "matematicamente". Quello che mi chiedo è: ha senso
oggi "mescolare" queste due filosofie?
Ha ancora senso preoccuparsi di lavorare parlando più direttamente
possibile alla macchina? O la differenza non si noterà se non nel dire
"questo codice è bello?"
E uscendo dal "giochino" della mappa, indipendentemente dal
linguaggio, conviene cercare di rendere meno "umani" i programmi nelle
loro indicazioni interne (es. le variabili di stato numeriche e non
stringhe) per renderli più "ordinati"?
PS: Chiedo scusa se il post suona confuso ma al momento non riesco a
rendere più chiaro il mio dubbio.
See you,
        Silver Drake
Pythawan Apprentice and Penguin Breeder
http://www.iammol.com
 - la webzine di It.Arti.Musica.Metal

Silver Drake wrote:
        [snippone]
Non sono sicurissimo di avere colto il tuo problema (anche perche 
'programmazione matematica' e 'programmazione logica' sono termini tecnici 
di valenza diversa e faccio fatica a scordarlo), ma, supponendo di avere 
grosso modo 'snasato'...
E` sempre piu` importante *fare il programma giusto* rispetto a *fare 
giusto il programma*.  Non importa quanto sia ben ottimizzato se risolve un 
problema che non importa a nessuno.  Per fare il programma giusto (quello 
che serve davvero) e` fondamentale potere avere versioni (magari subset) 
funzionanti al piu` presto possibile e adattarle rapidamente, perche` le
esigenze cambiano in continuazione.  Fondamentale dunque dedicare MOLTO
tempo/attenzione/sforzo a sviluppare dei TEST per il programma, cosi` da
potere [a] confermare quali parti sono funzionanti, [b] confermare che
"adattando rapidamente" non si e` rotto nulla.  Se mai si riesce a stare
"a bocce ferme" un momentino (il cliente e` felice della funzionalita`
attuale ma esige migliori prestazioni) allora e` il momento di misurare
accuratamente dove nascono gli sprechi di tempo e studiare come toglierli
(e ancora la suite di test e` fondamentale perche` e` quella che ci
assicura che le ottimizzazioni non hanno rotto nulla).
Gli aspetti "prestazionali" che non si possono trattare cosi` a cuor
leggero sono sostanzialmente di due tipi: [a] 'leak' di risorse,
tipicamente memoria, se il programma deve girare per piu` di un tempo
minuscolo (un CGI puo` cavarsela anche con i leak, programmi piu`
normali probabilmente no, tanto meno server / demoni / ecc); [b] le
considerazioni "big-O" -- se usi algoritmi e strutture dati che
implicano costo di esecuzione O(N * N) dove avresti potuto farcela
con O(N) stai probabilmente minando il tuo stesso lavoro alla radice,
anche se oggi (sui test) ti sembra che la differenza non si veda
(perche` i test sono *PICCOLI*, visto che DEVONO girare in fretta:
il cliente vorra` invece risolvere problemi *GRANDI*...).
Su [a] te la sbrighi i quasi scegliendo linguaggi di livello abbastanza
alto (e facendo un po' di attenzione in certi "punti caldi":-), e` un
problema davvero serio solo se programmi in linguaggi privi di
"garbage collection".  Su [b] ci vuole invece un po' di cultura e
un po' di attenzione.
Ma la maggior parte delle "ottimizzazioni", quelle che portano dei
benefici di puri fattori moltiplicativi (10%, o anche, spesso, 100%,
per la specifica parte "ottimizzata") piu` spesso che no, non ti
servono.  Tenere le cose semplici e flessibili (dove ottimizzare
vorrebbe dire farle piu` complicate e/o rigide) sara` piu` spesso
che no la scelta giusta.  "Fai la cosa piu` semplice che possa
funzionare" e` un buon principio...
Alex

 numerici e lavorando solitamente molto a basso livello. 
Che intendi per "convertire un problema in termini numerici" ?
La mia domanda nasce da una sincera curiosita', anche perche'
voglio convincermi che, effettivamente, *qualunque* problema
sia risolvibile in questo modo.  Cosa di cui, per il momento,
dubito.
Io credo che la distinzione un po' nebbiosa tra programmazione
"matematica" e programmazione "logica" che fai indichi, in realta',
due modi diversi di vedere la stessa cosa: la programmazione.
Ci sono molti tipi di programmazione: imperativa, funzionale, 
orientata agli oggetti, ecc.., senza contare che esistono diversi 
linguaggi che mescolano, tra loro, questi paradigmi.
Nell'ambito di ogni paradigma ci sono, poi, molti modi di risolvere
lo stesso problema (vedi, in programmazione procedurale, la 
distinzione tra bottom-up e top-down).
L'approccio alla risoluzione di un problema, quindi, puo' essere
molto diverso, a seconda dei casi.
Nel caso specifico che citi, il fatto di tenere delle variabili
di stato come numeriche o come stringa e' un dettaglio implementativo
che, a mio avviso, non ha un grandissimo peso nella progettazione
del programma, se non per migliorarne o meno la leggibilita'.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 programma, se non per migliorarne o meno la leggibilita'.
 
Quello che mi chiedevo più che altro era: una volta valutato se abbia
ancora senso lavorare "a basso livello" quando al giorno d'oggi hai
montagne di librerie che te lo potrebbero risparmiare (ma al prezzo di
una "perdita di controllo" sui modi di snellire e tenere "pulito" il
programma complessivo) il fatto di volerlo fare con un linguaggio di
alto livello (come può essere un Python contrapposto a un C) serve
oppure significa non poter sfruttare il lavoro di "snellimento" e quindi
ottenerne solo la complicazione?

...
Penso che il tuo dubbio sia tra la programmazione "script" (tipo
Python, PHP, Javascript etc.etc. e la programmazione
"imperativa/procedurale" ( tipo C ) ;
eviterei il termine "programmazione logica" che indica tutt'altra cosa
( il Prolog ad esempio).
La scelta del linguaggio e dell'ambiente di programmazione dipendono
dal problema che si vuole risolvere. I linguaggi "script" permettono
di realizzare velocemente piccole applicazioni che implicano
l'elaborazione massiva di stringhe alfanumeriche ( sottolineo
VELOCEMENTE PICCOLE e STRINGHE ); questo giustifica il loro massiccio
impiego nella programmazione per il Web. Inoltre i linguaggi di script
hanno una cosiddetta "learning curve" molto ripida , cioe' basta poco
tempo per apprenderne la maggior parte della funzionalita'.
I linguaggi classici, tipo il C, hanno una learning curve
probabilmente tra le piu' lente, ma con il C "ci si fa tutto", dai
sistemi operativi  alle librerie scientifiche, dai server web ai
compilatori ...
Se il tuo obiettivo e' imparare la programmazione, e' fondamentale
conoscere un linguaggio tipo il C.
Infine non e' assolutamente vero che la potenza dei sistemi di calcolo
attuali rende i linguaggi di script sufficienti per tutto,
l'informatica non e' solo il web !!! Ti sfido a fare una inversione di
matrice (10000x10000) di numeri reali a doppia precisione con
Javascript !
Spero di essere stato di aiuto
ciao
Luca

"imperativa/procedurale" ( tipo C ) ;
Sono d'accordo con il tuo messaggio, anche se piuttosto che parlare di linguaggi
di programmazione tradizionali parlerei di linguaggi a basso livello, però
vedere Python insieme a PHP e Javascript mi fa rabbrividire... 
Decisamente non sono proprio la stessa cosa, Python è un linguaggio di
programmazione completo con il quale puoi fare di tutto, anche se non proprio
tutto. 
Insieme al C (per i punti caldi di un programma) permette di fare qualsiasi
cosa, javascript e php non hanno neanche da lontano la stessa potenza...
Se invece mi parli di scripting perchè python è interpretato... beh... Puoi
compilarlo, interpretare il bytecode (come java) ma queste cose le sai
sicuramente visto che al massimo il novellino sono io...
Volevo solo dire che scripting per python mi sembra eccessivamente riduttivo...
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 Volevo solo dire che scripting per python mi sembra eccessivamente riduttivo...
Hai ragione, scusami. Mi hai dato lo spunto per approfondire Python
visto che non lo conosco quasi per niente...
ciao
Luca

 rabbrividire...
 
A voler essere fiscali anche il pur "piccolo" PHP vicino a Javascript mi
sembra un po' crudele... :P

visto che non lo conosco quasi per niente...
Di fatica ne farai poca a impararlo se conosci già bene qualche linguaggio di
programmazione, ancora meno se conosci LISP
