View Full Version : [Python] Inizio dei miei studi
Non è difficile il linguaggio in sè.
E' rognoso doversi abbassare al livello della macchina per trovare la soluzione di bug che non sai da dove spuntano e che ti fanno perdere ORE ed ORE (quando va bene :asd: ) di lavoro in cui avresti potuto scrivere altro codice per risolvere il tuo problema ;)
c'è però da considerare che qualsiasi programmatore deve sapere abbassarsi al livello della macchina per potersi definire tale. poi se decide di non abbassarsi a quel livello è un altro conto.. è una scelta consapevole.
inoltre il C non preclude l'uso di certe tecnice di ingegneria del software per ridurre l'introduzione di bug e rendere più facile la loro identificazione, solo che ti lascia la completa libertà e questo spesso si traduce in codice scritto male da questo punto di vista (cosa che però non vale per il kernel di linux)
AnonimoVeneziano
18-11-2007, 11:25
1) se, magari...
2) Linux tra tutti i software del mondo è l'ultimo che possa essere preso come esempio di buona programmazione.
Beh, credo che praticamente tutti i sistemi operativi del mondo siano scritti in C + Assembly tranne alcuni dedicati ad ambiti speciali (o il BEOS che è scritto in C++)
Personalmente dubito vedremo mai un Sistema operativo scritto in python :) A meno che non si crei un compilatore statico di python ovviamente.
Ciao
cdimauro
18-11-2007, 20:41
purtroppo mi sa che si deve conoscere obbligatoriamente, è richiesto in troppi campi questo linguaggio (c/c++)
L'unica cosa che un programmatore è obbligato a fare è risolvere i problemi che gli vengono sottoposti, "nel migliore dei modi". ;)
è cosi difficile questo linguaggio? dopo che se ne impara uno non dovrebbe essere più facile imparare gli altri, dovrebbe bastare studiare la sintassi no?
Ha una sintassi orrenda.
Conservati questo http://www.hwupgrade.it/forum/showthread.php?t=1604185 link e riprendilo quando avrai maggior dimestichezza con le funzioni in Python: vedrai l'enorme differenza d'approccio al problema nei due linguaggi.
E stiamo parlando soltanto di "puntatori" a funzione: ti lascio immaginare gli argomenti più avanzati. :p
cdimauro
18-11-2007, 20:46
c'è però da considerare che qualsiasi programmatore deve sapere abbassarsi al livello della macchina per potersi definire tale. poi se decide di non abbassarsi a quel livello è un altro conto.. è una scelta consapevole.
Me la fornisci una dimostrazione di quello che hai detto? Perché, fino a prova contraria, a me risulta che un programmatore debba risolvere problemi...
inoltre il C non preclude l'uso di certe tecnice di ingegneria del software per ridurre l'introduzione di bug e rendere più facile la loro identificazione,
Per farlo deve "mimare" ciò che altri linguaggi realizzano nativamente, rendendo il codice ancora più complesso da scrivere e interpretare.
E allora tanto vale affidarsi direttamente a questi linguaggi: se ne guadagna in produttività, semplicità e manutenibilità...
solo che ti lascia la completa libertà e questo spesso si traduce in codice scritto male da questo punto di vista
Non so se te ne sei reso conto,ma quello che hai appena detto è già motivo sufficiente per cercare di evitare linguaggi come questo.
cdimauro
18-11-2007, 20:49
Beh, credo che praticamente tutti i sistemi operativi del mondo siano scritti in C + Assembly tranne alcuni dedicati ad ambiti speciali (o il BEOS che è scritto in C++)
Ne esistono diversi scritti in Pascal, ad esempio.
Il linguaggio non è importante per la scrittura di un s.o. (fatta eccezione per un po' di "glue code" in assembly in alcuni punti critici).
Personalmente dubito vedremo mai un Sistema operativo scritto in python :) A meno che non si crei un compilatore statico di python ovviamente.
Ciao
Esattamente, e ciò, infatti, non preclude la strada per questo linguaggio, come pure a tanti altri. :)
mindwings
19-11-2007, 11:30
Me la fornisci una dimostrazione di quello che hai detto? Perché, fino a prova contraria, a me risulta che un programmatore debba risolvere problemi...
concordo :O
AnonimoVeneziano
19-11-2007, 12:14
Ne esistono diversi scritti in Pascal, ad esempio.
Il linguaggio non è importante per la scrittura di un s.o. (fatta eccezione per un po' di "glue code" in assembly in alcuni punti critici).
Esattamente, e ciò, infatti, non preclude la strada per questo linguaggio, come pure a tanti altri. :)
Beh, volendo si potrebbe usare anche il VB6 :D
Comunque python è un linguaggio che ha un sacco di caratteristiche dinamiche che è parecchio difficile implementare in un buon ed efficiente compilatore statico. Praticamente i tipi di dato si sanno solo a runtime, questo porta sicuramente difficoltà nell'implementazione del compilatore e scarsa ottimizzazione del codice risultante. Insomma, giurerei che un compilatore statico di python genererebbe codice lento , sicuramente la scelta migliore per questo linguaggio sarebbe un JIT.
Direi che , oltre alla retrocompatibilità con il codice scritto fino ad ora, l'utilizzo del C come linguaggio dominante per la programmazione dei sistemi operativi più diffusi è anche dovuto alla semplicità con cui avviene la traduzione del codice C in codice macchina.
Un compilatore C , per quanto ottimizzato o particolare, non ha molta scelta sul come generare in output il codice oggetto. Questo porta alla possibilità per il programmatore di non trovarsi "sorprese" in uscita dal compilatore con codice che non rispecchia la sua idea originale dell'algoritmo (in pratica vede il proprio algoritmo scritto in versione assembly molto simile a come l'aveva scritto in C). E' uno dei motivi per cui il codice C, se scritto bene, è molto veloce e la ritengo una caratteristica fondamentale per un linguaggio di programmazione per sistemi operativi , perchè permette di scrivere algoritmi veloci per quelle parti "critiche" del sistema operativo che devono avere una latenza vicino al real-time (tipo lo scheduler dei processi) senza doversi preoccupare sulla fase di traduzione in codice macchina.
Ciao
Th3 Kn0wl3dg3
19-11-2007, 13:35
Conservati questo http://www.hwupgrade.it/forum/showthread.php?t=1604185 link
non c'ho capito una mazza...
Beh, volendo si potrebbe usare anche il VB6
Comunque python è un linguaggio che ha un sacco di caratteristiche dinamiche che è parecchio difficile implementare in un buon ed efficiente compilatore statico. Praticamente i tipi di dato si sanno solo a runtime, questo porta sicuramente difficoltà nell'implementazione del compilatore e scarsa ottimizzazione del codice risultante. Insomma, giurerei che un compilatore statico di python genererebbe codice lento , sicuramente la scelta migliore per questo linguaggio sarebbe un JIT.
Direi che , oltre alla retrocompatibilità con il codice scritto fino ad ora, l'utilizzo del C come linguaggio dominante per la programmazione dei sistemi operativi più diffusi è anche dovuto alla semplicità con cui avviene la traduzione del codice C in codice macchina.
Un compilatore C , per quanto ottimizzato o particolare, non ha molta scelta sul come generare in output il codice oggetto. Questo porta alla possibilità per il programmatore di non trovarsi "sorprese" in uscita dal compilatore con codice che non rispecchia la sua idea originale dell'algoritmo (in pratica vede il proprio algoritmo scritto in versione assembly molto simile a come l'aveva scritto in C). E' uno dei motivi per cui il codice C, se scritto bene, è molto veloce e la ritengo una caratteristica fondamentale per un linguaggio di programmazione per sistemi operativi , perchè permette di scrivere algoritmi veloci per quelle parti "critiche" del sistema operativo che devono avere una latenza vicino al real-time (tipo lo scheduler dei processi) senza doversi preoccupare sulla fase di traduzione in codice macchina.
Ciao
non c'ho capito una mazza 2: il ritorno
cdimauro
19-11-2007, 13:37
Beh, volendo si potrebbe usare anche il VB6 :D
Certamente. :D
Comunque python è un linguaggio che ha un sacco di caratteristiche dinamiche che è parecchio difficile implementare in un buon ed efficiente compilatore statico. Praticamente i tipi di dato si sanno solo a runtime, questo porta sicuramente difficoltà nell'implementazione del compilatore e scarsa ottimizzazione del codice risultante. Insomma, giurerei che un compilatore statico di python genererebbe codice lento , sicuramente la scelta migliore per questo linguaggio sarebbe un JIT.
Ci sono già delle soluzioni, infatti: http://psyco.sourceforge.net/introduction.html (questo è vecchio e non più aggiornato, ma funziona ancora molto bene) e http://pypy.org/ (questo è più giovane e immaturo, ma rappresenta il futuro dei compilatori JIT per Python) sono i più diffusi.
Qui http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=psyco&lang2=python c'è un confronto (prestazionale e consumo di memoria) fra Python e la sua "versione JIT" con Psyco.
Comunque in 3 anni che sviluppo con Python non nascondo che mi sono posto il problema delle prestazioni, ma non ho mai adottato nessuna soluzione particolare (nemmeno Psyco ho mai provato) perché non ho avuto l'oggettiva necessità di velocizzare il mio codice. ;)
Direi che , oltre alla retrocompatibilità con il codice scritto fino ad ora, l'utilizzo del C come linguaggio dominante per la programmazione dei sistemi operativi più diffusi è anche dovuto alla semplicità con cui avviene la traduzione del codice C in codice macchina.
Un compilatore C , per quanto ottimizzato o particolare, non ha molta scelta sul come generare in output il codice oggetto. Questo porta alla possibilità per il programmatore di non trovarsi "sorprese" in uscita dal compilatore con codice che non rispecchia la sua idea originale dell'algoritmo (in pratica vede il proprio algoritmo scritto in versione assembly molto simile a come l'aveva scritto in C).
Questo si verificava nei primi tempi, quando erano molto diffuse le architetture CISC che, comunque, non usufruivano (o ne facevano poco uso) di concetti come pipeline di esecuzione, esecuzione out-of-order, cache, ecc.
Infatti operatori come ++ e -- sono stati introdotti nel linguaggio perché si "mappavano" direttamente con le modalità d'indirizzamento della CPU su cui sarebbe dovuta girare la prima versione di Unix.
Adesso se prendi il disassemblato di un tuo sorgente C puoi vedere spesso l'ottimizzatore tira fuori soluzioni quanto meno "strane", difficilmente riconducibili alla volontà del programmatore di realizzare esattamente ciò che voleva.
Le architetture sono molto cambiate, e i compilatori pure (tanto per fare un altro esempio, x = x + 1, x += 1 e x++ vengono tutte convertite nel medesimo abstract tree: è poi il backend che provvede a generare il codice che, per lui, è "migliore"). ;)
E' uno dei motivi per cui il codice C, se scritto bene, è molto veloce e la ritengo una caratteristica fondamentale per un linguaggio di programmazione per sistemi operativi , perchè permette di scrivere algoritmi veloci per quelle parti "critiche" del sistema operativo che devono avere una latenza vicino al real-time (tipo lo scheduler dei processi) senza doversi preoccupare sulla fase di traduzione in codice macchina.
Ciao
Questo si verifica con tanti altri linguaggi procedurali (e non, come il C++, ad esempio).
Anzi, per dirla tutta, oggi i compilatori di molti linguaggi spesso hanno soltanto il frontend diverso, mentre condividono la parte più importante, cioé il backend, che si occupa di effettuare tutte le ottimizzazioni possibili dato l'abstract tree che è stato generato dal frontend, a cui ovviamente si vanno ad aggiungere quelle ottimizzazioni legati all'architettura target per cui si va a generare il codice.
Lo puoi vedere coi compilatori GNU. ;)
cdimauro
19-11-2007, 13:38
non c'ho capito una mazza...
non c'ho capito una mazza 2: il ritorno
Ottimo: sei sulla buona strada! :p
AnonimoVeneziano
19-11-2007, 14:19
Comunque in 3 anni che sviluppo con Python non nascondo che mi sono posto il problema delle prestazioni, ma non ho mai adottato nessuna soluzione particolare (nemmeno Psyco ho mai provato) perché non ho avuto l'oggettiva necessità di velocizzare il mio codice. ;)
Non ne dubito, oggigiorno le questioni prestazionali sono più uno spauracchio che altro. Le macchine sono molto veloci e anche se un linguaggio non è il massimo della velocità perchè interpretato difficilmente si sente, anzi, a volte il linguaggio più ricco aiuta i programmatori a scegliere la soluzione giusta per rendere il programma più veloce (tipo adottare i contenitori giusti per i propri dati che abbiano tempi di esecuzione più rapidi per le operazioni che dobbiamo eseguire).
Questo si verificava nei primi tempi, quando erano molto diffuse le architetture CISC che, comunque, non usufruivano (o ne facevano poco uso) di concetti come pipeline di esecuzione, esecuzione out-of-order, cache, ecc.
Infatti operatori come ++ e -- sono stati introdotti nel linguaggio perché si "mappavano" direttamente con le modalità d'indirizzamento della CPU su cui sarebbe dovuta girare la prima versione di Unix.
Adesso se prendi il disassemblato di un tuo sorgente C puoi vedere spesso l'ottimizzatore tira fuori soluzioni quanto meno "strane", difficilmente riconducibili alla volontà del programmatore di realizzare esattamente ciò che voleva.
Le architetture sono molto cambiate, e i compilatori pure (tanto per fare un altro esempio, x = x + 1, x += 1 e x++ vengono tutte convertite nel medesimo abstract tree: è poi il backend che provvede a generare il codice che, per lui, è "migliore"). ;)
Forse non sono riuscito a spiegare bene quello che intendevo.
Ovviamente su ogni architettatura abbiamo uno specifico modo di tradurre determinate espressioni che dipendono essenzialmente dall' ISA della macchina, ma non è propriamente questo che intendevo dire.
Ipotizziamo di stare usando python per scrivere un sistema operativo.
Python è un linguaggio di livello molto alto rispetto al C. Gestisce la memoria per conto suo, il binding è totalmente dinamico ... etc.
Per implementare queste caratteristiche il compilatore statico dovrebbe usare un sacco di "workaround" come tabelle di puntatori (tipo vptr table per il c++ e le funzioni virtual) ed altri trucchi in modo da ottenere un codice eseguibile compilato che abbia le stesse funzionalità della versione interpretata. Il codice risultante avrà quindi molte aggiunte da parte del compilatore derivate da ciò. Aumenta la complessità e diminuisce la possibilità di ottimizzazione .
Il C invece è un linguaggio totalmente statico. Il compilatore non deve fare assunzioni strane su nulla. La cosa più sofisticata che si ritrova nel C è l'allocazione dinamica della memoria tramite "malloc()". Il codice C scritto dal programmatore si ritrova quindi molto simile in struttura al codice macchina in uscita dal compilatore. Il programmatore ha il controllo sul codice che scrive ed è per questo che è un buon linguaggio per scrivere un sistema operativo (dopotutto , anche se molto vecchio, è stato pensato proprio per questo).
Questo si verifica con tanti altri linguaggi procedurali (e non, come il C++, ad esempio).
Anzi, per dirla tutta, oggi i compilatori di molti linguaggi spesso hanno soltanto il frontend diverso, mentre condividono la parte più importante, cioé il backend, che si occupa di effettuare tutte le ottimizzazioni possibili dato l'abstract tree che è stato generato dal frontend, a cui ovviamente si vanno ad aggiungere quelle ottimizzazioni legati all'architettura target per cui si va a generare il codice.
Lo puoi vedere coi compilatori GNU. ;)
Sono daccordo che oggigiorno ci sono altre alternative valide al C. Altri linguaggi di programmazione con tipizzazione statica (come il C++) e con struttura non troppo complessa. Penso che ora come ora ci si possa permettere anche di usare linguaggi più complessi in questo campo ,senza però andare al livello di python, ruby e compagnia.
Il C in ogni caso è molto ben radicato causa : abitudine, efficienza se messo in buone mani e compatibilità con la base codice già scritta .
Ciao
cdimauro
19-11-2007, 14:27
In effetti non avevo capito allora. :p Adesso è chiaro, e condivido. :)
Th3 Kn0wl3dg3
19-11-2007, 15:32
azz... ma perchè non capisco un cavolo?!? mi sento un piccolo idiota....:muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro:
marko.fatto
19-11-2007, 15:43
azz... ma perchè non capisco un cavolo?!? mi sento un piccolo idiota....:muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro:
Tranquillo... Se non hai certe conoscenze proprio terra-terra il discorso che hanno appena fatto non è poi così facile da capire..
edit: con terra-terra intendo vicine alle funzioni base del so
cdimauro
19-11-2007, 15:44
azz... ma perchè non capisco un cavolo?!? mi sento un piccolo idiota....:muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro:
Te l'avevo già detto: è MOLTO meglio che tu non capisca queste cose. :D
Concentrati sull'acquisizione della mentalità del programmatore, e vedrai che pian piano tutte queste cose che adesso sono criptiche diventeranno chiare. ;)
Th3 Kn0wl3dg3
19-11-2007, 16:13
spero davvero che sia cosi
Me la fornisci una dimostrazione di quello che hai detto? Perché, fino a prova contraria, a me risulta che un programmatore debba risolvere problemi...
che io sappia un programmatore deve svilluppare il software, per cui si tratta di un problema specifico e non di problemi in generale (anche se esistono mille sfaccettature), poi mi risulta difficile pensare di risolvere i problemi se non li conosco. quindi la conoscenza della macchina è un prerequisito per un programmatore.
se poi è possibile potrà scegliere diversi livelli di astrazione, ma la consapevolezza di quello che si sta facendo è pur sempre fondamentale
cdimauro
19-11-2007, 18:04
che io sappia un programmatore deve svilluppare il software, per cui si tratta di un problema specifico e non di problemi in generale (anche se esistono mille sfaccettature),
Mi sembra ovvio: il software è per definizione "pratico".
poi mi risulta difficile pensare di risolvere i problemi se non li conosco.
Anche questo è lapalissiano.
quindi la conoscenza della macchina è un prerequisito per un programmatore.
Questa conseguenza logica, però, non so da dove la tiri fuori. Mi spieghi come si riallaccia con quanto hai scritto sopra, cortesemente?
se poi è possibile potrà scegliere diversi livelli di astrazione, ma la consapevolezza di quello che si sta facendo è pur sempre fondamentale
Anche questa è da dimostrare: su quale base fai quest'affermazione?
Comunque è molto strano: "casualmente" le applicazioni che ho scritto in Python al momento se ne fregano altamente del livello di astrazione più basso... e funzionano lo stesso!
Misteri dell'informatica...
Python è un linguaggio di livello molto alto rispetto al C. Gestisce la memoria per conto suo, il binding è totalmente dinamico ... etc.
Per implementare queste caratteristiche il compilatore statico dovrebbe usare un sacco di "workaround" come tabelle di puntatori (tipo vptr table per il c++ e le funzioni virtual) ed altri trucchi in modo da ottenere un codice eseguibile compilato che abbia le stesse funzionalità della versione interpretata. Il codice risultante avrà quindi molte aggiunte da parte del compilatore derivate da ciò. Aumenta la complessità e diminuisce la possibilità di ottimizzazione .
Aumenta localmente perche' maggiore e' il lavoro da fare da parte del compilatore. Complessita' che potrebbe (potenzialmente) calare da altre parti, visto che spesso alcune di queste funzionalita' sono replicate nel codice. Oltretutto direi che le possiblita' di ottimizzazione aumentano visto che il codice di partenza e' piu' inefficiente (semmai e' piu' difficile ottenere le stesse performance :D). Per quelle parti gestite direttamente dal linguaggio (es.: gestione della memoria) si possono fare molte piu' assunzioni sul loro uso e quindi ci sono piu' possibilita' di ottimizzazione.
Con questo non voglio dire che sia possibile o proponibile fare un S.O. in python, ma in generale non ci sono problemi a farne uno con un linguaggio dinamico, i sistemi operativi basati su lisp ne sono un esempio.
AnonimoVeneziano
19-11-2007, 23:30
Aumenta localmente perche' maggiore e' il lavoro da fare da parte del compilatore. Complessita' che potrebbe (potenzialmente) calare da altre parti, visto che spesso alcune di queste funzionalita' sono replicate nel codice. Oltretutto direi che le possiblita' di ottimizzazione aumentano visto che il codice di partenza e' piu' inefficiente (semmai e' piu' difficile ottenere le stesse performance :D). Per quelle parti gestite direttamente dal linguaggio (es.: gestione della memoria) si possono fare molte piu' assunzioni sul loro uso e quindi ci sono piu' possibilita' di ottimizzazione.
Con questo non voglio dire che sia possibile o proponibile fare un S.O. in python, ma in generale non ci sono problemi a farne uno con un linguaggio dinamico, i sistemi operativi basati su lisp ne sono un esempio.
Ammetto di non aver mai scritto un sistema operativo (beh, ho fatto un accrocco che scriveva a malapena un testo dopo il boot e accettava in ingresso qualche carattere, ma non lo considererei un sistema operativo :p) e tanto meno un compilatore, però correggimi se sbaglio :
Prendiamo come esempio questo codice C++:
for ( int count = 0; count < 100000000; count++)
obj->funzione();
Dove "obj" è un puntatore a tipo "Oggetto" definito:
class Oggetto {
int a;
public :
Oggetto();
void funzione();
}
Oggetto::Oggetto() : a(0){}
void Oggetto::funzione() { a++; }
In C++ il binding dinamico è disabilitato di default a meno che "funzione()" non sia dichiarata "virtual" . Se non è dichiarata virtual allora il compilatore può essere abbastanza sicuro del fatto che funzione() è proprio la funzione della classe "Oggetto" . In base a questa assunzione il compilatore , se è furbo , visto che funzione() è molto piccola e viene chiamata ben 100000000 volte dovrebbe fare un inline di funzione() nel for risparmiando un bel po' di overhead causato dal costo della chiamata di funzione ( che in funzioni così piccole può addirittura raddoppiare il tempo di esecuzione ).
In python un :
obj.funzione()
Come si traduce? "obj" ha un tipo dinamico , ossia dipende in fase di esecuzione. L'inline è ovviamente impossibile e l'implementazione della chiamata bisognerebbe farla attraverso dio solo sa quale modo , visto che il compilatore non ha neanche uno straccio di tipo statico a cui attaccarsi :D Chissà che giro solo per implementare una chiamata di funzione quando in C/C++ addirittura ci sarebbe potuto stare l'inline in fase di compilazione.
Se mi sai spiegare come in python il codice compilato risultante possa essere più efficiente ti ringrazierei :)
Ciao
Comunque è molto strano: "casualmente" le applicazioni che ho scritto in Python al momento se ne fregano altamente del livello di astrazione più basso... e funzionano lo stesso!
Misteri dell'informatica...
se possibile -_-
obj.funzione()
Come si traduce? "obj" ha un tipo dinamico , ossia dipende in fase di esecuzione. L'inline è ovviamente impossibile e l'implementazione della chiamata bisognerebbe farla attraverso dio solo sa in quale modo , visto che il compilatore non ha neanche uno straccio di tipo statico a cui attaccarsi :D Chissà che giro solo per implementare una chiamata di funzione quando in C/C++ addirittura ci sarebbe potuto stare l'inline in fase di compilazione.
Se mi sai spiegare come in python il codice compilato risultante possa essere più efficiente ti ringrazierei :)
Se sei fortunato il compilatore riesce ad intuire il tipo di obj dal contesto, ad esempio perche' e' stato inizializzato proprio nel corpo della funzione che contiene il loop.
class Foo:
def __init__(self):
self.a = 0
def funzione(self):
self.a += 1
...
obj = Foo()
...
for i in range(1000000):
obj.funzione()
ovviamente non sempre si e' fortunati :D, per cui ci si deve arrangiare con un trucchetto non molto differente dal togliere il virtual in C++, ovvero dire chiaramente quale e' il metodo che andra' usato:
...
for i inrange(1000000)
Foo.funzione(obj)
Saranno poi i test a dover garantire che tale codice venga chiamato sempre con il tipo corretto (ma anche in C++ ti resta il problema analogo).
Una via di mezzo puo' essere quella di creare dei code-path specifici per i tipi piu' usati, in questo modo riusciamo a gestire anche il caso generale, e il nostro compilatore trasformerebbe il codice iniziale in qualcosa di equivalente a
...
if obj.__class__ == Foo:
obj.a += 1000000
else:
for i in range(1000000):
obj.funzione()
Quest' ottimizzazione ovviamente funziona solo se abbiamo dei dati di profiling per decidere su quale classe vale la pena di fare questa cosa. In generale possiamo ricavarceli staticamente. L'ideale sarebbe ovviamente poterlo fare a runtime, ma nel caso di un sistema operativo forse e' eccessivo.
Tutto questo in linea teorica, visto che l'attuale compilatore python non mi sembra faccia inline di questo tipo.
C'e' pero' una libreria molto interessante, psyco, che si occupa di fare compilazione JIT di bytecode python in codice nativo in modo totalmente trasparente all'utente. Anche se non si applica direttamente al nostro caso (proprio perche' fa ottimizzazioni sul bytecode a run-time), e' uno spunto interessante per capire come funzionino le ottimizzazioni su linguaggi dynamici:
http://psyco.sourceforge.net
http://psyco.sourceforge.net/accu2004-psyco.tgz
cdimauro
20-11-2007, 07:28
se possibile -_-
Per la mia esperienza piuttosto bisognerebbe chiedersi quando non è possibile... ;)
Per la mia esperienza piuttosto bisognerebbe chiedersi quando non è possibile... ;)
ma tu sai come funziona la macchina, quindi puoi scegliere quello che credi meglio. di sicuro se un programmatore va a un colloquio di lavoro e non sa cos'è la memoria centrale gli ridono in faccia.
hai mai visto un meccanico che non sa com'è fatto un motore? a un certo punto è anche una questione di interesse verso la materia, non soltanto di utilità pratica.
cdimauro
20-11-2007, 09:51
Chi inizia l'interesse di cui parli lo può benissimo riservare a DOPO che si sarà fatto le ossa.
Perché al momento l'importante è formare la mentalità del programmatore, e questo, checché tu ne dica (e non dimostri), NON RICHIEDE NESSUNA CONOSCENZA DELLA MACCHINA.
Esempio pratico: Python gestisce le stringhe unicode conservando i caratteri usando quantità a 16 o 32 bit. La scelta fra le due dipende strettamente dall'architettura su cui gira (quindi dalla particolare implementazione della virtual machine).
Pensi che mi sia mai interessato di sapere se nelle macchine su cui lavoro i caratteri unicode siano rappresentati con 16 o 32 bit? No, mai.
Sai perché? Semplicemente perché a me interessa memorizzare caratteri unicode (in stringhe), ma non di sapere anche quanto occupano.
E sono sicuro che il mio codice funzionerà ugualmente bene in entrambi i casi.
Ti faccio un altro esempio sulla stessa "linea", ma tirando in ballo i numeri interi: non me ne frega niente di sapere se sono memorizzati come quantità a 32 o 64 bit; o ancora se vengono usati i "BigInt". A me interessa sapere che posso memorizzare numeri interi dotati di segno, e che le operazioni definite facciano il loro sporco lavoro.
Anzi, il bello con Python (a partire dalla 2.4 mi pare) è che in maniera trasparente se non basta un intero a 32 o 64 bit, il sistema automaticamente passa ad adottare i "BigInt", e il mio codice... continua a funzionare! :p
Ed è così che faccio tutti i giorni: mi concentro soltanto sul problema da risolvere, usando i (macro)tipi di dati giusti. Il resto viene da sé: non me ne occupo e ti assicuro che dormo tranquillo lo stesso.
Anzi, dormo sicuramente più tranquillo di uno che potrebbe aver sbagliato a usare un int a 16 bit anziché a 32 bit, o che ha passato un intero a una funzione che si aspettava un puntatore (e prima o poi salterà fuori il famigerato segmentation fault, che è sempre dietro l'angolo con certi linguaggi).
Son tre anni che programmo con Python, e ho riscoperto il piacere di programmare: quello di risolvere i problemi, piegando la macchina ai miei voleri, e senza esser costretto a dover capire io, prima, come funziona la macchina. ;)
P.S. Soprattutto se programmo in Python... programmo in Python! Non mischio sintassi e/o codice C in programmi Python, come ho visto fare in questo thread. :read: :Prrr:
P.S. Nei colloqui di lavoro non ho mai chiesto ai candidati se conoscessero o meno il concetto di memoria centrale. Perché a me interessa gente che sappia programmare, non che conosca necessariamente la letteratura informatica in merito. ;)
In C++ il binding dinamico è disabilitato di default a meno che "funzione()" non sia dichiarata "virtual" . Se non è dichiarata virtual allora il compilatore può essere abbastanza sicuro del fatto che funzione() è proprio la funzione della classe "Oggetto" . In base a questa assunzione il compilatore , se è furbo , visto che funzione() è molto piccola e viene chiamata ben 100000000 volte dovrebbe fare un inline di funzione() nel for risparmiando un bel po' di overhead causato dal costo della chiamata di funzione ( che in funzioni così piccole può addirittura raddoppiare il tempo di esecuzione ).
Se il compilatore conosce il tipo di obj al momento della compilazione e' in grado di mettere comunque inline una funzione virtual che rispecchia i requisiti per l'inlining. I compilatori di ultima generazione sono davvero ottimi in questo aspetto e sono in grado di mettere inline funzioni non dichiarate inline e implementate in altre unita'. Da cui la regola generale: e' diventato quasi perfettamente inutile dichiarare inline una funzione, meglio lasciar fare al compilatore nel 99.9% dei casi.
Th3 Kn0wl3dg3
20-11-2007, 12:53
scusate ragazzi, stiamo divagando un pò troppo mi sembra...
AnonimoVeneziano
20-11-2007, 13:49
Se sei fortunato il compilatore riesce ad intuire il tipo di obj dal contesto, ad esempio perche' e' stato inizializzato proprio nel corpo della funzione che contiene il loop.
class Foo:
def __init__(self):
self.a = 0
def funzione(self):
self.a += 1
...
obj = Foo()
...
for i in range(1000000):
obj.funzione()
ovviamente non sempre si e' fortunati :D, per cui ci si deve arrangiare con un trucchetto non molto differente dal togliere il virtual in C++, ovvero dire chiaramente quale e' il metodo che andra' usato:
...
for i inrange(1000000)
Foo.funzione(obj)
Saranno poi i test a dover garantire che tale codice venga chiamato sempre con il tipo corretto (ma anche in C++ ti resta il problema analogo).
Una via di mezzo puo' essere quella di creare dei code-path specifici per i tipi piu' usati, in questo modo riusciamo a gestire anche il caso generale, e il nostro compilatore trasformerebbe il codice iniziale in qualcosa di equivalente a
...
if obj.__class__ == Foo:
obj.a += 1000000
else:
for i in range(1000000):
obj.funzione()
Quest' ottimizzazione ovviamente funziona solo se abbiamo dei dati di profiling per decidere su quale classe vale la pena di fare questa cosa. In generale possiamo ricavarceli staticamente. L'ideale sarebbe ovviamente poterlo fare a runtime, ma nel caso di un sistema operativo forse e' eccessivo.
Tutto questo in linea teorica, visto che l'attuale compilatore python non mi sembra faccia inline di questo tipo.
C'e' pero' una libreria molto interessante, psyco, che si occupa di fare compilazione JIT di bytecode python in codice nativo in modo totalmente trasparente all'utente. Anche se non si applica direttamente al nostro caso (proprio perche' fa ottimizzazioni sul bytecode a run-time), e' uno spunto interessante per capire come funzionino le ottimizzazioni su linguaggi dynamici:
http://psyco.sourceforge.net
http://psyco.sourceforge.net/accu2004-psyco.tgz
Interessante.
Però comunque sembra che necessiti molto di analizzare quello che succede a runtime (tramite profiling) per riuscire a tirare fuori qualcosa di simile a quello che tirerebbe fuori un compilatore C++ o sbaglio?
Comunque è vero, forse stiamo divagando un po' troppo ... :stordita:
Chi inizia l'interesse di cui parli lo può benissimo riservare a DOPO che si sarà fatto le ossa.
e chi ha detto cosa va fatto prima o dopo.. io ho solo detto che andrebbe fatto
Perché al momento l'importante è formare la mentalità del programmatore, e questo, checché tu ne dica (e non dimostri), NON RICHIEDE NESSUNA CONOSCENZA DELLA MACCHINA.
aggiungo: NELLA MAGGIOR PARTE DEI CASI
ps. io non dimostrerò niente.. ma te?
Th3 Kn0wl3dg3
20-11-2007, 17:01
piccola curiosità: tutti quelli che hanno partecipato a questo bel dibattito arabo per me (e che non penso mi sia d'aiuto, ma solo ke mi fa confondere) sono tutti laureati? come azz... le sapete tutte queste cose?
cdimauro
20-11-2007, 19:28
e chi ha detto cosa va fatto prima o dopo.. io ho solo detto che andrebbe fatto
Cosa va fatto prima è a dir poco ovvio: acquisire la MENTALITA' del programmatore.
Il resto può benissimo venire dopo.
aggiungo: NELLA MAGGIOR PARTE DEI CASI
ps. io non dimostrerò niente.. ma te?
Io preferisco riportare la definizione di algoritmo:
http://it.wikipedia.org/wiki/Algoritmo e http://en.wikipedia.org/wiki/Algorithm
e non mi pare di notare alcun riferimento all'architettura di un elaboratore...
cdimauro
20-11-2007, 19:32
piccola curiosità: tutti quelli che hanno partecipato a questo bel dibattito arabo per me (e che non penso mi sia d'aiuto, ma solo ke mi fa confondere) sono tutti laureati? come azz... le sapete tutte queste cose?
Sono laureato, ma non vuol dire niente: contano i fatti. La laurea è soltanto un pezzo di carta.
L'unica cosa positiva del conseguire la laurea è avere la fortuna (perché di questo si tratta) di conoscere professori validi che sappiano spiegare bene le loro materie e farti acquisire la giusta mentalità critica, perché per il resto all'università non mancano certo i raccomandati e/o quelli che rovivano gli studenti.
Th3 Kn0wl3dg3
20-11-2007, 19:36
e tutte queste cose che sai, i termini ecc ecc le hai imparate all'università?
p.s. secondo voi a quale facoltà mi conviene inscrivermi? ingengeria informatica, scienze informatiche o informatica? premetto che io voglio fare il programmatore di professione, analista programmatore e diventare un sistemista/esperto di sicurezza
e tutte queste cose che sai, i termini ecc ecc le hai imparate all'università?
L'universita' non ti deve insegnare i termini e i concetti (o almeno non tutti), ma ti deve insegnare il metodo e la forma mentale per apprendere termini e concetti nuovi.
La maggior parte dei termini che conosco non vengono dall'universita', ma il metodo che seguo per impararli si'.
p.s. secondo voi a quale facoltà mi conviene inscrivermi? ingengeria informatica, scienze informatiche o informatica? premetto che io voglio fare il programmatore di professione, analista programmatore e diventare un sistemista/esperto di sicurezza
Ingegneria e' piu' completa, mentre informatica e' piu' specializzata.
Cosa va fatto prima è a dir poco ovvio: acquisire la MENTALITA' del programmatore.
Il resto può benissimo venire dopo.
e in che modo questo dovrebbe essere in contrapposizione con quello che ho detto? :fagiano:
Io preferisco riportare la definizione di algoritmo:
http://it.wikipedia.org/wiki/Algoritmo e http://en.wikipedia.org/wiki/Algorithm
e non mi pare di notare alcun riferimento all'architettura di un elaboratore...
io preferisco la definizione di programmatore http://en.wikipedia.org/wiki/Computer_programmer di cui trovo interessante la parte seguente
Application versus system programming
Computer programmers often are grouped into two broad types: application programmers and systems programmers. Application programmers write programs to handle a specific job, such as a program to track inventory within an organization. They also may revise existing packaged software or customize generic applications which are frequently purchased from independent software vendors. Systems programmers, in contrast, write programs to maintain and control computer systems software, such as operating systems and database management systems. These workers make changes in the instructions that determine how the network, workstations, and CPU of the system handle the various jobs they have been given and how they communicate with peripheral equipment such as printers and disk drives. Because of their knowledge of the entire computer system, systems programmers often help applications programmers debug, or determine the source of, problems that may occur with their programs.
Th3 Kn0wl3dg3
21-11-2007, 05:21
Ingegneria e' piu' completa, mentre informatica e' piu' specializzata.
potresti spiegarti meglio?
cdimauro
21-11-2007, 07:28
e in che modo questo dovrebbe essere in contrapposizione con quello che ho detto? :fagiano:
Perché tu hai scritto questo:
"c'è però da considerare che qualsiasi programmatore deve sapere abbassarsi al livello della macchina per potersi definire tale."
che è una sentenza assolutista del tutto priva di fondamento.
io preferisco la definizione di programmatore http://en.wikipedia.org/wiki/Computer_programmer di cui trovo interessante la parte seguente
Peccato che, a parte questa parte, non c'è NULLA che possa confermare la tua tesi di cui sopra.
Inoltre ti faccio notare che hai corretto la tua affermazione con questo:
"aggiungo: NELLA MAGGIOR PARTE DEI CASI"
che non si applica alla programmazione di sistema (di cui hai riportato uno stralcio prima), ma a quella applicativa, visto che scrivere s.o., driver et similia riguarda una NICCHIA e non il software comune... :read:
Perché tu hai scritto questo:
"c'è però da considerare che qualsiasi programmatore deve sapere abbassarsi al livello della macchina per potersi definire tale."
che è una sentenza assolutista del tutto priva di fondamento.
io non mi affiderei mai a un meccanico che non sa come è fatto un motore... tu ti affideresti a un programmatore che non sa come è fatto un computer?
Peccato che, a parte questa parte, non c'è NULLA che possa confermare la tua tesi di cui sopra.
a parte questo?
Inoltre ti faccio notare che hai corretto la tua affermazione con questo:
"aggiungo: NELLA MAGGIOR PARTE DEI CASI"
che non si applica alla programmazione di sistema (di cui hai riportato uno stralcio prima), ma a quella applicativa, visto che scrivere s.o., driver et similia riguarda una NICCHIA e non il software comune... :read:
mmmno.. io parlavo di programmazione in generale che comprende sia quella di sistema che quella applicativa (da qui il "maggiorparte dei casi").
comunque non hai letto bene una parte di quello che ho quotato prima per cui lo riscrivo:
Because of their knowledge of the entire computer system, systems programmers often help applications programmers debug, or determine the source of, problems that may occur with their programs.
cdimauro
21-11-2007, 08:32
io non mi affiderei mai a un meccanico che non sa come è fatto un motore... tu ti affideresti a un programmatore che non sa come è fatto un computer?
Sì, perché un programmatore deve... risolvere problemi, non conoscere a menadito la macchina su cui gira.
D'altra parte mi potresti dire quale sarebbe il valore aggiunto rappresentato dalla conoscenza della macchina quando sviluppi un programma in Python, Java, ma anche in Pascal, C, C++?
Tanto per essere chiaro su dove voglio arrivare: mi sapresti dire quanto occupa un char in C? E uno short? E un int? E un long? Stiamo parlando del C, uno dei linguaggi a più basso livello: la risposta dovrebbe essere secca e... certa.
a parte questo?
A parte questo, non c'è null'altro, appunto.
La cosa interessante, poi, è che anche per buona parte nella programmazione di sistema si può lavorare tranquillamente senza conoscere dettagli dell'architettura ospite: è sufficiente conoscere quelli del s.o., infatti. ;)
mmmno.. io parlavo di programmazione in generale che comprende sia quella di sistema che quella applicativa (da qui il "maggiorparte dei casi").
E io torno a ripeterti che nella stragrande maggioranza dei casi, invece, non è assolutamente necessario "abbassarsi al livello della macchina", come hai sempre affermato.
Se non sei d'accordo puoi benissimo esporre il tuo pensiero in merito e spiegarmi perché lo ritieni necessario, fornendo anche esempi possibilmente.
comunque non hai letto bene una parte di quello che ho quotato prima per cui lo riscrivo:
Sì, l'avevo già letto, e non cambia nulla.
In primis perché, appunto, la programmazione di sistema è di nicchia, e in secondo luogo perché all'interno della maggior parte di essa non è applicabile il concetto di "abbassarsi al livello della macchina".
Tra l'altro quell'affermazione la ritengo errata: un programmatore di sistema NON deve necessariamente avere una cognizione di tutto il sistema. Anche in questo campo i rami applicativi sono diversi ed eterogenei... ;)
il programmatore deve sapere risolvere problemi sulla macchina che è diverso da saper risolvere problemi in generale, senza la seconda componente non sei un programmatore (e nessuno ha detto a menadito).
la dimensione di un qualsiasi tipo del C in ogni caso la puoi conoscere a runtime.
comunque io ho detto che nella maggior parte dei casi non è necessario abbassarsi al livello della macchina. la mia aggiunta al tuo commento significava appunto quello.
poi ancora non hai letto bene quello che ho quotato :fagiano: prima di tutto si parla di programmazione applicativa, poi la programmazione di un sistema operativo è programmazione di sistema. ma anche se il sistema operativo costituisce un'interfaccia tra le applicazioni e l'hardware, c'è da dire che quest'interfaccia non è abbastanza di alto livello per poter dimenticare cosa sia l'hardware. penso ad esempio alle primitive che fornisce per l'allocazione della memoria
cdimauro
21-11-2007, 10:25
il programmatore deve sapere risolvere problemi sulla macchina che è diverso da saper risolvere problemi in generale, senza la seconda componente non sei un programmatore (e nessuno ha detto a menadito).
Anche questo lo dovresti dimostrare, perché io con Python (ma potrei citarti anche altri linguaggi) non ho mai avuto l'esigenza di conoscere la macchina su cui girano le mie applicazioni.
Nonostante tutto... sono un programmatore, se permetti! :p
la dimensione di un qualsiasi tipo del C in ogni caso la puoi conoscere a runtime.
A runtime è troppo tardi, e non hai risposto alle mie domande.
comunque io ho detto che nella maggior parte dei casi non è necessario abbassarsi al livello della macchina. la mia aggiunta al tuo commento significava appunto quello.
Ah, bene allora: dal contesto non si capiva.
poi ancora non hai letto bene quello che ho quotato :fagiano:
T'avevo già detto che l'avevo letto, e te lo ribadisco.
prima di tutto si parla di programmazione applicativa, poi la programmazione di un sistema operativo è programmazione di sistema.
Certamente, ma adesso sei tu che a quanto pare sembri non aver letto quello che ho scritto. ;)
Domanda: è necessario conoscere tutti i dettagli di una macchina per realizzare un INTERO s.o.?
ma anche se il sistema operativo costituisce un'interfaccia tra le applicazioni e l'hardware, c'è da dire che quest'interfaccia non è abbastanza di alto livello per poter dimenticare cosa sia l'hardware. penso ad esempio alle primitive che fornisce per l'allocazione della memoria
Penso che con Python la memoria venga allocata ugualmente, anche se non si conosce l'architettura della macchina su cui gira.
Penso che se in C eseguo una malloc di una struttura dati, funzionerà (ovviamente se c'è abbastanza memoria a disposizione) a prescindere dal s.o. che ci sta sotto e dell'architettura su cui a sua volta gira il s.o..
E potrei continuare. ;)
Il concetto mi pare sia chiaro, no?
potresti spiegarti meglio?
Ingegneria Informatica ti da' una preparazione piu' completa anche su aspetti non strettamente legati all'informatica, come matematica, elettronica, chimica e fisica. Al contrario Informatica si concentra piu' sull'informatica, per ovvi motivi.
Th3 Kn0wl3dg3
21-11-2007, 14:24
quali sono questi ovvi motivi?
@cdimauro
la cosa strana è che qualunque cosa dica tu devi per forza dire il contrario :p
io continuerò a pensare che un programmatore che non sa come è fatto un computer farebbe meglio a fare qualche altro lavoro, tu auspichi invece un mondo dove i programmatori vivono in una cupola di vetro. sia mai sporcarsi le mani nel capire come funziona.. sarebbe reato.
se non ti basta sapere a runtime la dimensione di un tipo in C puoi usare la libreria limit.h
comunque l'allocazione automatica della memoria esiste anche in C, non solo in python. mentre se invece esegui una malloc come hai già detto allochi memoria indipendentemente dal SO e dallo specifico hardware.. ma qui non ci siamo capiti. è ovvio che è superfluo conoscere il funzionamento di un pezzo di hardware specifico, ma io parlavo dell'architettura (astratta) del computer. e questa la si deve conoscere, perchè se esegui una malloc allora stai per prima cosa dicendo che esiste una memoria da allocare.
infatti il C è un linguaggio di alto livello (ora non si sa bene se chiamarlo medio livello o cosa.. sta di fatto che al basso livello c'è l'assembly) che non dipende dalla particolare architettura, ma ne fornisce un'astrazione.
in conclusione se avessi inteso quello che hai inteso te allora avrei citato l'assembly (questo si che dipende dalla specifica architettura), ma non l'ho inteso, perchè è perfettamente inutile imparare una specifica architettura
AnonimoVeneziano
21-11-2007, 14:51
Ehm, ma una via di mezzo non può andar bene .... ? :stordita:
cdimauro
21-11-2007, 15:27
@cdimauro
la cosa strana è che qualunque cosa dica tu devi per forza dire il contrario :p
Sarà una coincidenza. :D
io continuerò a pensare che un programmatore che non sa come è fatto un computer farebbe meglio a fare qualche altro lavoro, tu auspichi invece un mondo dove i programmatori vivono in una cupola di vetro. sia mai sporcarsi le mani nel capire come funziona.. sarebbe reato.
Se è un tuo pensiero ne prendo atto, perché prima avevo la malsana impressione che fosse un dogma di fede dell'informatica. :p
Comunque stai manipolando troppo il mio pensiero: io ho detto che un programmatore deve risolvere problemi, e questo è l'assunto fondamentale.
Poi ho detto un'altra cosa: che sarebbe MOLTO MEGLIO non avere a che fare con certe rogne.
Il che NON pone le due cose in maniera mutuamente esclusiva.
Infatti SE (condizione) un particolare problema costringe necessariamente a scendere a livello più basso, è chiaro che... lo si dovrà fare. Qualcuno ha parlato di programmazione di sistema? Sì, in alcuni settori richiede di scendere a un livello molto basso, tanto che... si arriva a ricorrere all'assembly.
se non ti basta sapere a runtime la dimensione di un tipo in C puoi usare la libreria limit.h
Ecco che già devi ricorrere a un file descrittivo per ottenere informazioni che NON puoi ottenere dal linguaggio. ;)
E dimmi un po': puoi conoscere anche l'endianess con quella libreria? Puoi conoscere anche l'ordine con cui il compilatore alloca i bit in una word di una struttura definita come campi di bit?
Vedi, il problema è che il C sarà un linguaggio a basso livello, ma... non arriva così in basso. Come tanti altri linguaggi tra l'altro: Pascal, Modula-2, Oberon, ecc. l'elenco è chilometrico.
Il motivo è molto semplice: un linguaggio NON è generalmente disegnato per essere culo & camicia con una particolare architettura. Perché altrimenti sapremmo già qual è la dimensione di un char, o addirittura se è signed o unsigned (eh, già: nemmeno questo, che io ricordi, è definito nel linguaggio).
comunque l'allocazione automatica della memoria esiste anche in C, non solo in python. mentre se invece esegui una malloc come hai già detto allochi memoria indipendentemente dal SO e dallo specifico hardware.. ma qui non ci siamo capiti. è ovvio che è superfluo conoscere il funzionamento di un pezzo di hardware specifico, ma io parlavo dell'architettura (astratta) del computer. e questa la si deve conoscere, perchè se esegui una malloc allora stai per prima cosa dicendo che esiste una memoria da allocare.
Tutto qui? Potevi dirlo anche prima. :p
Beh, in Python non ne hai bisogno. In Java nemmeno. E si campa ugualmente bene. :D
infatti il C è un linguaggio di alto livello (ora non si sa bene se chiamarlo medio livello o cosa.. sta di fatto che al basso livello c'è l'assembly) che non dipende dalla particolare architettura, ma ne fornisce un'astrazione.
Sì, ed è un limite del C, che ti offre soltanto una PARTICOLARE visione (o paradigma) con cui risolvere problemi, e tra l'altro vincolata a concetti di basso livello (memoria & puntatori).
Ma il C è UN linguaggio. Per fortuna. Anche se sfortunatamente è fra quelli più diffusi e usati.
in conclusione se avessi inteso quello che hai inteso te allora avrei citato l'assembly (questo si che dipende dalla specifica architettura), ma non l'ho inteso, perchè è perfettamente inutile imparare una specifica architettura
Invece se lavori in C ti è necessario scendere di livello in alcuni casi e legarsi a una particolare piattaforma.
Anzi: si è sempre legati a una particolare piattaforma (in particolare a un compilatore), e realizzare applicazioni portabili (anche usando compilatori diversi) richiede un bel po' di lavoro.
Non sarà come l'assembly ovviamente, ma per realizzare cose che altri linguaggi risolvono in maniera più elegante, costringe il programmatore a lavorare su un livello di astrazione più basso.
E qui, lo ribadisco ancora una volta, è un limite del linguaggio, perché il PRINCIPALE obiettivo per un programmatore è quello di risolvere i problemi che gli si presentano. E questo nella maggioranza dei casi NON si traduce nel conoscere e far uso di aspetti di più basso livello (a meno che, appunto, il linguaggio non vincoli necessariamente in tal senso).
cdimauro
21-11-2007, 15:34
Ehm, ma una via di mezzo non può andar bene .... ? :stordita:
Se è compatibile con la definizione di un problema, e risulta la soluzione "migliore", perché no.
I buoni programmatori devono risolvere i problemi nel migliore dei modi.
Legarsi mani e piedi a particolari soluzioni / piattaforme / filosofie / religioni (!) è stupido e illogico. ;)
Se per un problema trovo che il C o Java o altro rappresenta lo strumento che mi permette di ottenere la soluzione "migliore", non ho certo difficoltà a usarlo. ;)
Th3 Kn0wl3dg3
22-11-2007, 12:51
ehm.. vi siete dimenticati di me?
ehm.. vi siete dimenticati di me?
già :F come va?
Th3 Kn0wl3dg3
22-11-2007, 19:48
va tutto bene, solo che adesso non posso studiare molto perchè la scuola mi prende un sacco di tempo. approposito dell'università che mi dite? cosi per farmi un'idea. vi quoto quello che avevo scritto:
secondo voi a quale facoltà mi conviene inscrivermi? ingengeria informatica, scienze informatiche o informatica? premetto che io voglio fare il programmatore di professione, analista programmatore e diventare un sistemista/esperto di sicurezza
AnonimoVeneziano
22-11-2007, 19:57
va tutto bene, solo che adesso non posso studiare molto perchè la scuola mi prende un sacco di tempo. approposito dell'università che mi dite? cosi per farmi un'idea. vi quoto quello che avevo scritto:
Però , hai le idee chiare :D
Io non ti posso consigliare comunque . Visto che sono ancora deciso a fare o il pompiere o il calciatore non mi ritengo la persona più adatta a dare pareri... :D
Ciao
va tutto bene, solo che adesso non posso studiare molto perchè la scuola mi prende un sacco di tempo. approposito dell'università che mi dite? cosi per farmi un'idea. vi quoto quello che avevo scritto:
quoto quello che ha detto fek
in poche parole se oltre all'informatica ti interessa la scienza in generale ti consiglio ingegneria informatica, mentre se ti interessa solo l'informatica (e magari più la pratica della teoria) scegli scienze informatiche.
Th3 Kn0wl3dg3
23-11-2007, 12:56
quoto quello che ha detto fek
in poche parole se oltre all'informatica ti interessa la scienza in generale ti consiglio ingegneria informatica, mentre se ti interessa solo l'informatica (e magari più la pratica della teoria) scegli scienze informatiche.
non mi interessa la scienza, solo ed esclusivamente l'informatica. in informatica cosa si fa? e in scienze informatiche? che qualifica ti danno? tenete conto di quelle che vorrei fare finita l'università...
^TiGeRShArK^
23-11-2007, 13:54
non mi interessa la scienza, solo ed esclusivamente l'informatica. in informatica cosa si fa? e in scienze informatiche? che qualifica ti danno? tenete conto di quelle che vorrei fare finita l'università...
L'informatica senza scienza (soprattutto matematica e fisica) imho non serve a nulla :p
AnonimoVeneziano
23-11-2007, 14:07
Considerando che l'informatica è una materia multidisciplinare è D'OBBLIGO conoscere altro oltre all'informatica in se.
Se sai programmare, ma non hai idea COSA programmare allora è sempre un problema :p
Metti il caso che ti chiedono di programmare un sistema di controllo per un braccio meccanico. Senza conoscenze di robotica non ne saresti in grado.
Metti il caso che ti chiedono di programmare un elaboratore digitale di segnali. Senza teoria di segnali è la stessa cosa.
E ci sono un sacco di esempi simili.
Ciao
cdimauro
23-11-2007, 14:26
Ma non puoi studiare qualunque branca della scienza. ;)
In informatica (scienze) c'è una forte componente matematica, e un po' di fisica: quanto basta per farsi le ossa per poi concentrarsi esclusivamente sullo sviluppo e funzionamento del software.
Informatico e ingegnere sono due figure diverse, con ruoli diversi.
Th3 Kn0wl3dg3
23-11-2007, 16:00
che ruolo ha l'informatico e che ruolo ha l'ingegnere? cioè per diventare un programmatore, sistemista e addetto alla sicurezza che corso dovrei fare?
Ma non puoi studiare qualunque branca della scienza. ;)
In informatica (scienze) c'è una forte componente matematica, e un po' di fisica: quanto basta per farsi le ossa per poi concentrarsi esclusivamente sullo sviluppo e funzionamento del software.
Informatico e ingegnere sono due figure diverse, con ruoli diversi.
ho letto tutto il 3d e dico questo:
è difficile da scrivere ma ci provo.
Consigliando phyton si ha in pratica detto all'utente del 3d: Inizia con questo tool vedrai che ti trovi bene ecc ecc... mentre si sà benissimo che non tutti hanno iniziato con questo tool.
Quello che voglio dire (spero di spiegarmi bene scrivendo) è che con linguaggi di alto livello si ragiona con la "mente", per impalcare un algoritmo, come "ragiona il tool di alto livello".
Mentre è ragionando a basso livello che si trova l'algoritmo giusto per quel tipo di problema.
In sostanza quello che voglio dire è:
In un linguaggio di alto livello si è "costretti" a ragionare algoritmi come infatti è dato dal linguaggio usato e conosciuto, e secondo me questo è deleterio proprio per la "mente" che si allena a risolvere problemi ad alto livello...
Il problema per uno che inizia, è grande, e se ne accorge solo in futuro.
Per esempio io ho iniziato con il basic poi vb6 ma dico che ho studiato l'asm per capire la macchina + approfonditamente.
Ora sto cercando di risolvere un problema in programmazione 3d e per risolverlo devo andare + a basso livello, cioè la mia mente, se ragiona ad alto livello "directx", non mi riesce di risolverlo.
Devo, e lo sto facendo, ragionare + a basso livello. Riesco a farlo proprio perchè ho studiato il c/c++ e l'asm.
Se dovessi risolvere "il mio algoritmo" soltanto con le istruzioni "directx" non ce la potrei fare. Sto risolvendo facendo funzioni e algoritmi in c/c++ e no istruzioni "directx"
Per concludere:
la frase per stringere il discorso è questa:
Mai (non sempre per cose futili [algoritmi futili]) ragionare, per risolvere un algoritmo, come ragiona il tool di alto livello adottato per lo sviluppo del programma adoperato alla bisogna.
E' deleterio proprio alla "mente" che si approccia al problema come il linguaggio utilizzato di alto livello.
Quando non si stà al pc e la mente và pensando all'algorimto da utilizzare per risolvere il problema facendolo in funzione del linguaggio usato... non vi è mai capitato??
Se il linguaggio è di alto livello non si riesce a risolverlo se non andare su google e fare copia e incolla di un qualcosa che serve per riuscire a capire il problema. E' la "mente" che ci rimette.
Linguaggio di alto livello = mente che ragiona ad alto livello
Linguaggio di basso livello = mente che ragiona a basso livello
"E' meglio usare un linguaggio di alto livello ma con la mente che ragiona come un linguaggio di basso livello" e non il contrario
ciao
Mentre è ragionando a basso livello che si trova l'algoritmo giusto per quel tipo di problema.
E' vero l'esatto contrario: l'algoritmo giusto per risolvere un problema e' qualunque algoritmo che risolve il problema ed e' piu' facile da trovare piu' alto e' il livello di astrazione al quale si puo' ragionare, piu' vicino al dominio del problema e non quello della macchina.
Se dovessi risolvere "il mio algoritmo" soltanto con le istruzioni "directx" non ce la potrei fare. Sto risolvendo facendo funzioni e algoritmi in c/c++ e no istruzioni "directx"
Tralasciando che DirectX non sono istruzioni ma e' un API di interfacciamento a diversi device, quale sarebbe questo algoritmo 3d che non puoi risolvere con "istruzioni" DirectX ma per il quale devi fare non meglio precisate funzioni in C++/Asm?
Apri pure un thread perche' qui e' OT.
cdimauro
23-11-2007, 20:40
che ruolo ha l'informatico e che ruolo ha l'ingegnere? cioè per diventare un programmatore, sistemista e addetto alla sicurezza che corso dovrei fare?
L'informatico, perché si fa massicciamente programmazione e teoria informatica.
Quanti ai sistemi e alla sicurezza, fra corsi obbligatori e complementari il programma è molto ricco.
L'ingegnere invece ha un programma multidisciplinare dove la componente informatica è ridotta rispetto all'informatico.
^TiGeRShArK^
23-11-2007, 20:44
Ma non puoi studiare qualunque branca della scienza. ;)
perchè no? :fagiano:
a me piacciono praticamente tutte.. :stordita:
^TiGeRShArK^
23-11-2007, 20:51
Quando non si stà al pc e la mente và pensando all'algorimto da utilizzare per risolvere il problema facendolo in funzione del linguaggio usato... non vi è mai capitato??
Ma anche no.
La mente serve a risolvere i problemi..
Io di solito divido il problema in vari sotttoproblemi ad libitum fino a che sono tanto semplici da poter essere risolti con 3/4 righe di codice.
Una volta che tutto è risolto procedo all'"assemblaggio" finale (anche se in realtà l'assemblaggio avviene mano a mano grazie all'onnipresente refactoring).
L'assemblaggio finale in realtà consiste nel riunire i vari progetti usati e produrre il risultato da *configurare* (comer nel mio caso attuale.. mi rompo troppo le palle configurare.. è così bello programmare :cry: ) o da testare...(eh si.. :stordita: per ora lo unit testing l'ho abbandonato :stordita:.. ma dovrò riprenderlo in futuro per progettini un pò + corposi :fagiano: )
Per concludere la mente se ne frega altamente del linguaggio usato...
Anche perchè credo che la mia mente farebbe un bel minestrone della madonna se cercasse di risolverla in qualche linguaggio e per caso si dovesse mettere a saltare tra tutti quelli che ho usato finora :asd:
cdimauro
23-11-2007, 21:09
ho letto tutto il 3d e dico questo:
è difficile da scrivere ma ci provo.
Consigliando phyton si ha in pratica detto all'utente del 3d: Inizia con questo tool vedrai che ti trovi bene ecc ecc... mentre si sà benissimo che non tutti hanno iniziato con questo tool.
E si sa pure che è meglio cominciare col piede giusto.
Quello che voglio dire (spero di spiegarmi bene scrivendo) è che con linguaggi di alto livello si ragiona con la "mente", per impalcare un algoritmo, come "ragiona il tool di alto livello".
Mentre è ragionando a basso livello che si trova l'algoritmo giusto per quel tipo di problema.
Io preferisco ragionare "con la mente" come dici tu, perché la soluzione al mio problema dev'essere quanto più facile da definire, assimilare e comprendere.
Inoltre con un modello ad alto livello posso apportare velocemente variazioni (e quindi sperimentare) che, invece, a più basso livello mi richiederebbero uno sforzo maggiore.
In sostanza quello che voglio dire è:
In un linguaggio di alto livello si è "costretti" a ragionare algoritmi come infatti è dato dal linguaggio usato e conosciuto, e secondo me questo è deleterio proprio per la "mente" che si allena a risolvere problemi ad alto livello...
Io sono dell'opinione diametralmente opposta: la mente deve imparare a risolvere i problemi nel migliore dei modi, e per far questo un modello più ad alto livello è migliore perché più vicino al modo di ragionare dell'uomo, e quindi più assimilabile e manutenibile.
Il problema per uno che inizia, è grande, e se ne accorge solo in futuro.
Sì: se parte col piede sbagliato se ne accorgerà sicuramente di quanto tempo avrà buttato via in dettagli inutili o di poco conto.
Per esempio io ho iniziato con il basic poi vb6 ma dico che ho studiato l'asm per capire la macchina + approfonditamente.
Io ho cominciato col linguaggio macchina (e soltanto in parte col BASIC) e col senno di poi avrei preferito (ai tempi: 26 anni fa) cominciare con SmallTalk, Simula, Pascal, Modula-2 o altro.
Ora sto cercando di risolvere un problema in programmazione 3d e per risolverlo devo andare + a basso livello, cioè la mia mente, se ragiona ad alto livello "directx", non mi riesce di risolverlo.
Devo, e lo sto facendo, ragionare + a basso livello. Riesco a farlo proprio perchè ho studiato il c/c++ e l'asm.
Se dovessi risolvere "il mio algoritmo" soltanto con le istruzioni "directx" non ce la potrei fare. Sto risolvendo facendo funzioni e algoritmi in c/c++ e no istruzioni "directx"
Al contrario: se modellassi il tuo problema a un livello di astrazione più alto sarebbe più facile trovare una soluzione ai tuoi problemi.
Ecco qui http://directpython.sourceforge.net/ una libreria per lavorare con le DX in Python.
Riporto l'esempio più semplice:
#*************************************************
# sampleBasic.py
#
# Very basic sample that shows some simple
# DirectPython functionality. The rendering
# is not very pretty, many old samples were
# just thrown together.
#
# Author: Heikki Salo
# Created: 1.2.2006
# Updated: 1.4.2006
#
#*************************************************
import array
import math
import d3d
from d3dc import *
#Two simple pre-transformed triangles.
trilist = (
(10.0, 400.0, 0.5, 1.0, 0xffffff00),
(190.0, 10.0, 0.5, 1.0, 0xffff00ff),
(370.0, 400.0, 0.5, 1.0, 0xff00ff00),
(200.0, 10.0, 0.5, 1.0, 0xffffff00),
(380.0, 400.0, 0.5, 1.0, 0xffff00ff),
(560.0, 10.0, 0.5, 1.0, 0xff00ff00)
)
#Use indices to index tristrip
indices = (0, 1, 2, 3)
tristrip = [(450.0, 350.0, 0.5, 1.0, 0xffffff00),
(550.0, 350.0, 0.5, 1.0, 0xff8080ff),
(475.0, 400.0, 0.5, 1.0, 0xff00ff00),
(575.0, 400, 0.5, 1.0, 0xffffffff)]
trifan = [(500.0, 10.0, 0.5, 1.0, 0xff0000ff),
(470.0, 150.0, 0.5, 1.0, 0xff0f0f00),
(530.0, 180.0, 0.5, 1.0, 0xffff0000),
(580.0, 150.0, 0.5, 1.0, 0xff00ff00),
(610.0, 100.0, 0.5, 1.0, 0xfff0ff00)]
linelist = [(10.0, 350.0, 0.5, 1.0, 0xff00ff00),
(50.0, 450.0, 0.5, 1.0, 0xff00ff00),
(30.0, 350.0, 0.5, 1.0, 0xff0f0f00),
(70.0, 450.0, 0.5, 1.0, 0xff00ff00),
(50.0, 350.0, 0.5, 1.0, 0xffff0000),
(90.0, 450.0, 0.5, 1.0, 0xfff0ff00)]
linestrip = [(200.0, 250.0, 0.5, 1.0, 0xff00ff00),
(250.0, 300.0, 0.5, 1.0, 0xffff0f00),
(300.0, 250.0, 0.5, 1.0, 0xff0fff00),
(350.0, 300.0, 0.5, 1.0, 0xfff0ff00),
(400.0, 250.0, 0.5, 1.0, 0xff00ff00)]
texts = [(u"Trianglestrip", 450, 410, 500, 500, 0xffff0000),
(u"Trianglefan", 630, 130, 500, 500, 0xffff0000),
(u"Linelist", 50, 420, 500, 500, 0xffff0000),
(u"Linestrip", 250, 320, 500, 500, 0xffff0000),
(u"Basic sample without the framework", 250, 20, 300, 200, 0x40ff0000)]
#See the FAQ
fakefullscreen = False
def mainloop():
#Create a windowed device. This sample does not
#support real fullscreen mode, see the other samples
#and d3dx.Frame if you want fullscreen.
window = (200, 200, 800, 600)
title = u"Basic (and messy) sample"
d3d.createDevice(title, u"textures/x.ico", window[2], window[3], False, CREATE.HARDWARE)
if fakefullscreen:
win = d3d.getWindow()
desktop = win[2]
d3d.setWindow(0, 0, desktop[0], desktop[1], title, STYLE.MAXIMIZE | STYLE.POPUP)
else:
d3d.setWindow(*window)
#Font, size 20 and bold
font = d3d.Font(u"Arial", 20, True)
texture = d3d.Texture("textures/tree.dds")
#Render strip from an IndexBuffer.
vbuffer = d3d.VertexBuffer(FVF.XYZRHW | FVF.DIFFUSE, tristrip)
#IndexBuffer is not needed (order is simple), but it
#is used as an example.
ibuffer = d3d.IndexBuffer(indices)
angle = 0.0
info = texture.info()
w = info[0]
h = info[1]
pos = (50, 50) #The upper left corner of the sprite.
while 1:
#Handle messages. This very basic sample
#only checks for QUIT and esc.
for m in d3d.getMessages():
if m[0] == WM.QUIT:
return
elif m[0] == WM.KEYDOWN:
if m[1] == VK.ESCAPE:
return
#Clear the buffer and begin the scene.
d3d.clear()
d3d.beginScene()
d3d.setState(RS.FVF, FVF.XYZRHW | FVF.DIFFUSE)
d3d.drawVertices(TYPE.TRIANGLELIST, trilist)
d3d.drawVertices(TYPE.TRIANGLESTRIP, vbuffer, ibuffer)
d3d.drawVertices(TYPE.TRIANGLEFAN, trifan)
d3d.drawVertices(TYPE.LINELIST, linelist)
d3d.drawVertices(TYPE.LINESTRIP, linestrip)
#Draw some alphablended text inside the rectangle. Text is
#rendered using sprites, so reset transformations.
d3d.setTransform((0, 0, 0), (0, 0, 0), (1, 1, 1), MATRIX.SPRITE)
d3d.drawTexts(font, texts)
#Set sprite transformation. Not necessarily needed and
#should not set on per-sprite basis. It is recommended
#to use proper matrix libraries.
matrix = array.array("f", (
math.cos(angle), math.sin(angle), 0.0, 0.0,
-math.sin(angle), math.cos(angle), 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
pos[0] + w / 2, pos[1] + h / 2, 0.0, 1.0,
))
d3d.setMatrix(matrix, MATRIX.SPRITE)
angle += 0.01
#Draw a transparent sprite using the whole texture.
d3d.drawSprites(texture, [(-w / 2, -h / 2, 0.5, -1, -1, -1, -1, 0x80ffffff)])
#End the scene and present the drawing.
d3d.endScene()
d3d.present()
if __name__ == "__main__":
mainloop()
Per concludere:
la frase per stringere il discorso è questa:
Mai (non sempre per cose futili [algoritmi futili]) ragionare, per risolvere un algoritmo, come ragiona il tool di alto livello adottato per lo sviluppo del programma adoperato alla bisogna.
E' deleterio proprio alla "mente" che si approccia al problema come il linguaggio utilizzato di alto livello.
Sono in totale disaccordo: è con un approccio più ad alto livello che si arriva più velocemente alla soluzione del problema, e con meno possibilità di commettere errori.
Pseudocodice, diagrammi di flusso e diagrammi a blocchi non li hanno inventati certo per passarsi il tempo...
Quando non si stà al pc e la mente và pensando all'algorimto da utilizzare per risolvere il problema facendolo in funzione del linguaggio usato... non vi è mai capitato??
Se il linguaggio è di alto livello non si riesce a risolverlo se non andare su google e fare copia e incolla di un qualcosa che serve per riuscire a capire il problema. E' la "mente" che ci rimette.
Non so a quale mente ti riferisca, ma di certo non è la mia né quella di tante altre persone che, invece, preferiscono nettamente l'approccio al problema da un livello di astrazione più alto.
Linguaggio di alto livello = mente che ragiona ad alto livello
Linguaggio di basso livello = mente che ragiona a basso livello
Già questo dimostra qual è la metodologia migliore.
"E' meglio usare un linguaggio di alto livello ma con la mente che ragiona come un linguaggio di basso livello" e non il contrario
ciao
Del tutto in disaccordo, e pedagogicamente fuorviante.
Ovviamente son d'accordo con fek e Tiger. ;)
cdimauro
23-11-2007, 21:10
perchè no? :fagiano:
a me piacciono praticamente tutte.. :stordita:
Pure a me piacciono, ma poi non ti laurei più. :p
perchè no? :fagiano:
a me piacciono praticamente tutte.. :stordita:
Alcune sono belle finche' non cominci a studiarle e conoscerle, e poi si rivelano meno interessanti. In ogni caso la singola facolta' puo' avere indirizzi con corsi diversi, per cui verifica quale ha i corsi che piu' ti interessano e orientati su quello, meglio se dopo aver sentito qualcuno che lo sta seguendo o l'ha seguito. Poi comunque il corso di laurea non fissa su pietra i lavori che potrai fare, io ho una laura in matematica, ma faccio il sistemista e il programmatore, per cui...
Se vuoi continuare a parlarne pero' meglio se apriamo una discussione apposita, che qui siamo OT.
Th3 Kn0wl3dg3
24-11-2007, 19:23
marco.r, hai una laurea in matematica ma fai il sistemista e il programmatore? hai fatto corsi di specializzazione? comunque se quello che ha detto cdimauro è vero andrò sicuramente ad informatica
cdimauro
24-11-2007, 20:17
Non ho motivo di mentire. ;)
Th3 Kn0wl3dg3
25-11-2007, 23:17
è un modo di dire, lo so che menti! ma come fa una persona laureata in matematica a fare il programmatore e il sistemista? cioè, potete illustrarmi un pò meglio questa cosa delle facoltà?
wingman87
25-11-2007, 23:59
Io sono al primo anno di informatica (non ingegneria) e sinceramente non sono molto contento perchè il ritmo mi sembra più lento di quello delle superiori, non dico che voglio stressarmi però un po' di lavoro in +, essendo l'informatica ciò che mi piace, non mi dispiacerebbe.
Praticamente mi sembra di sprecare il mio tempo, 5 anni sono davvero tanti e impiegati a questo ritmo io li trovo sottosfruttati. Spero che le cose migliorino nei trimestri successivi. Per ora sono un po' deluso e questo forse mi fa vedere le cose + nere di quello che sono...
è un modo di dire, lo so che menti! ma come fa una persona laureata in matematica a fare il programmatore e il sistemista? cioè, potete illustrarmi un pò meglio questa cosa delle facoltà?
Era per esemplificare il fatto che non e' detto che la Via del Programmatore preveda per forza come tappa (Ing\. )?Informatica.
Un mio collega di laboratorio e' psicologo eppure programma benissimo (gli serve per i suoi esperimenti).
Nel mio caso l'aspetto sistemistico e' arrivato a causa di eventi fortuiti e me la sono cavata grazie all'esperienza extra-scolastica. Per quel che riguarda la programmazione invece il corso di laurea in Matematica prevedeva (eravamo ancora prima del 3+2) l'orientamento informatico per cui ho inserito nel piano di studi diversi esami che mi interessavano per cui i linguaggi, algorirtmi e un po' di cose di base le ho studiate anche io.
Th3 Kn0wl3dg3
26-11-2007, 19:29
capito
Th3 Kn0wl3dg3
23-12-2007, 18:36
Rieccomi... era tanto che non mi facevo sentire, ma ho avuto un sacco di problemi..enormi proprio..infatti python è andato a farsi benedire.... sono restato fermo all'esercizio dei nomi e tra meno di un mese sono 20 annucci... mi sa mi sa che abbandono.. non vedo speranza:muro: :muro:
cdimauro
26-12-2007, 17:51
Se pensi di non farcela, lascia perdere.
Spero, però, che non applicherai lo stesso principio anche su cose più importanti che ti capiteranno nella vita...
Th3 Kn0wl3dg3
08-01-2008, 12:41
non è questo, il fatto è che non lo so nemmeno io e nè ho mai applicato nè mai applicherò questo principio nelle cose più importanti che mi capiteranno nella vita, anche se per me la cosa più bella sarebbe fare il lavoro che mi piace: programmatore/esperto di sicurezza, sistemi ecc
cdimauro
08-01-2008, 13:04
Allora sforzati: rimboccati le maniche, studia e sperimenta.
Nessuno qui è diventato programmatore dal giorno alla notte. ;)
^TiGeRShArK^
08-01-2008, 18:24
non è questo, il fatto è che non lo so nemmeno io e nè ho mai applicato nè mai applicherò questo principio nelle cose più importanti che mi capiteranno nella vita, anche se per me la cosa più bella sarebbe fare il lavoro che mi piace: programmatore/esperto di sicurezza, sistemi ecc
..evidentemente non ti piace abbastanza...
Th3 Kn0wl3dg3
10-01-2008, 15:37
Non è nemmeno questo, a me piace un sacco davvero altrimenti non avrei postato ecc ecc, però c'è un qualcosa di oscuro che non capisco... non so come spiegarlo.. sembro pazzo
cdimauro
10-01-2008, 19:27
Quando avrai chiarito i tuoi problemi scrivi un messaggio e facci sapere cosa c'è che non va, ti da fastidio o altro.
Rieccomi... era tanto che non mi facevo sentire, ma ho avuto un sacco di problemi..enormi proprio..infatti python è andato a farsi benedire.... sono restato fermo all'esercizio dei nomi e tra meno di un mese sono 20 annucci... mi sa mi sa che abbandono.. non vedo speranza:muro: :muro:
ma che palle sto thread, è stato tutto un piagnisteo e un consolarti e infonderti coraggio per farti imparare un linguaggio semplicissimo da usare :asd:
ma sai che ti dico, abbandona va' :D
che ormai sei pure vecchio, oserei aggiungere :asd:
banryu79
10-01-2008, 21:06
Non è nemmeno questo, a me piace un sacco davvero altrimenti non avrei postato ecc ecc, però c'è un qualcosa di oscuro che non capisco... non so come spiegarlo.. sembro pazzo
Ciao Th3 Knowl3dg3,
se posso dirti la mia senza peli sulla lingua (non sono un gatto :D ) IMHO il tuo è un semplice problema di VOLONTA'.
Ed è una cosa che nessuno può darti ma dipende esclusivamente da te.
Senza di quella non vai da nessuna parte, il discorso sull'età, il fatto che sei troppo vecchio e tutte le altre cose sono solo SEGHE MENTALI e, se vuoi, puoi lasciartele alle spalle.
Non dico che sia facile, però dico che è certamente POSSIBILE.
Se posso darti un consiglio: studia e studia e studia e metteti a fare esercizi e a scrivere codice.
Scopri se ti piace.
Quando ti trovi di fronte ad un problema scegli di provare a risolverlo da solo, non chiedendo tramite i post la soluzione ad altri utenti del Forum.
Usa il Forum come "ultima spiaggia" solo dopo aver provato con le tue risorse.
Ma la cosa più importante: scopri se ti piace programmare o meno.
Te lo dico perchè per guadagnarsi da vivere esistono lavori meno ingrati di quello del programmatore, credo :rolleyes:
Ciao :)
Th3 Kn0wl3dg3
10-01-2008, 21:45
bè a me è piaciuto un sacco e sono stato tanto felice quando ho risolto quell'esercizion da solo, per voi era una cosa da bambini,ma per me che lo stavo studiando no...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.