La dura via della programmazione --- ENTRATE TUTTI ---

[cdimauro]

Il libro è in PDF: puoi stamparlo e farlo rilegare, se ti piace in forma cartacea.

Per quanto riguarda SPE e SVN, per il momento lascia perdere. Quando avrai fatto un po' di pratica ne riparleremo.

[gepeppe]

Originariamente inviato da DanieleC88

È solo per non alimentare flame che non mi sono ancora pronunciato...

già...stava andando cosi bene fin'ora...non facciamo certi discorsi che non c'entrano nulla col thread.

[~FullSyst3m~]

Originariamente inviato da gepeppe

già...stava andando cosi bene fin'ora...non facciamo certi discorsi che non c'entrano nulla col thread.

Infatti, casomai apriamo un altro 3d e ci scanniamo là!

[nuovoUtente86]

Originariamente inviato da cdimauro

E' "limitato" molto meno del C, e comparabile a C++ e Java quanto a strumenti di alto livello.

E' la tua, appunto. E nel caso di Python continui a sbagliare.

ma python non viene eseguito da un VM?

[^TiGeRShArK^]

Originariamente inviato da nuovoUtente86

ma python non viene eseguito da un VM?

Che intendi per una VM?
Il CPython, l'implementazione + comunemente utilizzata, è interpretato.
IronPython viene tradotto in bytecode per il CLR del .NET e quindi utilizza il JIT compiler.
Discorso analogo vale per JPython che utilizza la VM della Sun e quindi anche l'ottimo JIT.
Infatti, se non sbaglio, le limitazioni sui thread di python valgono solo per l'implementazione classica, mentre le altre implementazioni non soffrono di quelle limitazioni.
Discorso analogo vale anche per JRuby, in cui addirittura l'utlima versione è + veloce di ruby 1.8.6 (anche se meno veloce della molto + ottimizzata 1.9.0, versione rilasciata solo come "preview" per gli sviluppatori).
Anche Java e C# vanno su una Virtual Machine, ma sinceramente, non ci si può proprio lamentare delle prestazioni medie.
Discorso diverso è x la latenza che non è deterministica a causa del garbage collector il che, con determinate tipologie di programmi, potrebbe causare qualche problema.
Per ovviare a questo c'è la versione Real-Time di Java lato sun.
Lato microsoft sinceramente non mi sono informato sulla presenza di specifiche versioni del linguaggio ottimizzate per il real-time perchè per ora non ne ho avuto assolutamente bisogno.
Comunque se la domanda aveva il senso "Ma python girando su una VM non è meno prestante dei linguaggi compilati classici", allora la risposta è: NO.
Con il tempo che risparmi per scrivere un sistema complesso in python puoi trovare algoritmi migliori che renderanno tutto il software + veloce.
Discorso diverso è ovviamente il problema di un determinato tipo di errori che, essendo un linguaggio dinamico, possono essere scoperti solo al run-time..... x la mia gioia e quella di FEK che è FELICISSIMO di questa peculiare caratteristica di ruby, python e dei linguaggi "dinamici" in genere

[by_to_by]

Originariamente inviato da ^TiGeRShArK^

Che intendi per una VM?
Il CPython, l'implementazione + comunemente utilizzata, è interpretato.
IronPython viene tradotto in bytecode per il CLR del .NET e quindi utilizza il JIT compiler.
Discorso analogo vale per JPython che utilizza la VM della Sun e quindi anche l'ottimo JIT.
Infatti, se non sbaglio, le limitazioni sui thread di python valgono solo per l'implementazione classica, mentre le altre implementazioni non soffrono di quelle limitazioni.
Discorso analogo vale anche per JRuby, in cui addirittura l'utlima versione è + veloce di ruby 1.8.6 (anche se meno veloce della molto + ottimizzata 1.9.0, versione rilasciata solo come "preview" per gli sviluppatori).
Anche Java e C# vanno su una Virtual Machine, ma sinceramente, non ci si può proprio lamentare delle prestazioni medie.
Discorso diverso è x la latenza che non è deterministica a causa del garbage collector il che, con determinate tipologie di programmi, potrebbe causare qualche problema.
Per ovviare a questo c'è la versione Real-Time di Java lato sun.
Lato microsoft sinceramente non mi sono informato sulla presenza di specifiche versioni del linguaggio ottimizzate per il real-time perchè per ora non ne ho avuto assolutamente bisogno.
Comunque se la domanda aveva il senso "Ma python girando su una VM non è meno prestante dei linguaggi compilati classici", allora la risposta è: NO.
Con il tempo che risparmi per scrivere un sistema complesso in python puoi trovare algoritmi migliori che renderanno tutto il software + veloce.
Discorso diverso è ovviamente il problema di un determinato tipo di errori che, essendo un linguaggio dinamico, possono essere scoperti solo al run-time..... x la mia gioia e quella di FEK che è FELICISSIMO di questa peculiare caratteristica di ruby, python e dei linguaggi "dinamici" in genere

ma come fai a sapere tutte queste cose?

[cdimauro]

Semplice: con l'esperienza e la buona volontà di rimboccarsi le maniche senza farsi paranoie dal primo nanosecondo.

x "Tiger" (ogni volta lo scrivo tra virgolette, ma non so se posso chiamarti col tuo vero nome ):
- non sbagli; il problema del GIL è legato esclusivamente a CPython e non al linguaggio di per sé;
- con Python puoi avere pieno controllo del Garbage Collector.

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Semplice: con l'esperienza e la buona volontà di rimboccarsi le maniche senza farsi paranoie dal primo nanosecondo.

x "Tiger" (ogni volta lo scrivo tra virgolette, ma non so se posso chiamarti col tuo vero nome ):
- non sbagli; il problema del GIL è legato esclusivamente a CPython e non al linguaggio di per sé;
- con Python puoi avere pieno controllo del Garbage Collector.

sul forum va benissimo "tiger", cesare
mmm..per quanto riguarda il pieno controllo del garbage collector immagino ti riferisci a Cpython, o no?

[cdimauro]

Sì. Ma anche con IronPython mi sembra sia possibile controllarlo.

Con Jython non credo sia possibile (altrimenti si troverebbe il modo di controllarlo anche da Java, suppongo ).

Non ho mai approfondito con PyPy.

[nuovoUtente86]

Originariamente inviato da ^TiGeRShArK^

Che intendi per una VM?
Il CPython, l'implementazione + comunemente utilizzata, è interpretato.
IronPython viene tradotto in bytecode per il CLR del .NET e quindi utilizza il JIT compiler.
Discorso analogo vale per JPython che utilizza la VM della Sun e quindi anche l'ottimo JIT.
Infatti, se non sbaglio, le limitazioni sui thread di python valgono solo per l'implementazione classica, mentre le altre implementazioni non soffrono di quelle limitazioni.
Discorso analogo vale anche per JRuby, in cui addirittura l'utlima versione è + veloce di ruby 1.8.6 (anche se meno veloce della molto + ottimizzata 1.9.0, versione rilasciata solo come "preview" per gli sviluppatori).
Anche Java e C# vanno su una Virtual Machine, ma sinceramente, non ci si può proprio lamentare delle prestazioni medie.
Discorso diverso è x la latenza che non è deterministica a causa del garbage collector il che, con determinate tipologie di programmi, potrebbe causare qualche problema.
Per ovviare a questo c'è la versione Real-Time di Java lato sun.
Lato microsoft sinceramente non mi sono informato sulla presenza di specifiche versioni del linguaggio ottimizzate per il real-time perchè per ora non ne ho avuto assolutamente bisogno.
Comunque se la domanda aveva il senso "Ma python girando su una VM non è meno prestante dei linguaggi compilati classici", allora la risposta è: NO.
Con il tempo che risparmi per scrivere un sistema complesso in python puoi trovare algoritmi migliori che renderanno tutto il software + veloce.
Discorso diverso è ovviamente il problema di un determinato tipo di errori che, essendo un linguaggio dinamico, possono essere scoperti solo al run-time..... x la mia gioia e quella di FEK che è FELICISSIMO di questa peculiare caratteristica di ruby, python e dei linguaggi "dinamici" in genere

No la domanda era riferita ai post precedenti a quello quotato in cui si discuteva se Java, C# e Python fossero o meno interpretati. Un utente, credo Wizard1993, aveva dato la sua definizione di interpretato...come un linguaggio eseguito da una macchina virtuale....e cdmauro come puoi vedere ha replicato che ciò non era corretto....da qui la mia domanda se Python fosse o meno eseguito da una VM...e se non lo si puo definire interpretato come lo possiamo chiamare: pseudocompilato?

[cdimauro]

Python, come qualunque altro linguaggio, non è vincolato alla particolare implementazione.

Io posso realizzare interpreti, compilatori, o meccanismi di tipo JIT sia con Python che con C++

[nuovoUtente86]

Originariamente inviato da cdimauro

Python, come qualunque altro linguaggio, non è vincolato alla particolare implementazione.

Io posso realizzare interpreti, compilatori, o meccanismi di tipo JIT sia con Python che con C++

assolutamente si, ma nella pratica quale è la tecnica piu utilizza?

[cdimauro]

La compilazione in bytecode/linguaggio intermedio. Ciò avviene per qualunque linguaggio .NET, Java & derivati e Python (questo considerato che .NET, Java dominano il mercato del software; vedi le statistiche che sono state riportate qualche tempo fa.).

Da questa forma ci sono poi diverse alternative sul cosa farci.
Con .NET puoi decidere di compilare il tutto alla prima esecuzione in un eseguibile nativo, oppure (caso comune) utilizzare un JIT per compilatore al volo il codice.
Con Java si utilizza un interprete bytecode, ma le parti più intensive vengono compilate in codice macchina nativo.
Con Python si utilizza un interprete bytecode.

[gepeppe]

Originariamente inviato da cdimauro

Python, come qualunque altro linguaggio, non è vincolato alla particolare implementazione.

Io posso realizzare interpreti, compilatori, o meccanismi di tipo JIT sia con Python che con C++

scusate il piccolo OT
cdimauro cavolo mi hai fatto venire voglia di studiare il python leggendo tutti i tuoi messasggi!!
Nella sezione giusta chiederò qualche libro per python, qui non mi sembra il caso
fine OT

[nuovoUtente86]

Originariamente inviato da cdimauro

La compilazione in bytecode/linguaggio intermedio. Ciò avviene per qualunque linguaggio .NET, Java & derivati e Python (questo considerato che .NET, Java dominano il mercato del software; vedi le statistiche che sono state riportate qualche tempo fa.).

Da questa forma ci sono poi diverse alternative sul cosa farci.
Con .NET puoi decidere di compilare il tutto alla prima esecuzione in un eseguibile nativo, oppure (caso comune) utilizzare un JIT per compilatore al volo il codice.
Con Java si utilizza un interprete bytecode, ma le parti più intensive vengono compilate in codice macchina nativo.
Con Python si utilizza un interprete bytecode.

il JIT di Java quindi compila in nativo solo il codice piu utilizzato, mentre quello del .Net viene cmq tutto tradotto "al volo" in linguaggio nativo?

[cdimauro]

Sì.

x gepeppe: http://www.python.it/doc/Howtothink/...l-it/index.htm

[nuovoUtente86]

Originariamente inviato da cdimauro

Sì.

x gepeppe: http://www.python.it/doc/Howtothink/...l-it/index.htm

Grazie.
Ma anche l' interprete Python è gestito come una macchina a stack?

[cdimauro]

Sì.

[gepeppe]

Originariamente inviato da cdimauro

Sì.

x gepeppe: http://www.python.it/doc/Howtothink/...l-it/index.htm

ah ti ringrazio. Ho trovato anche la versione pdf cosi me la posso stampare..