[Gc] Java e Perl [Archivio] - Hardware Upgrade Forum

Vincenzo1968

14-02-2013, 20:01

Sono l'ultima persona che potrebbe rispondere a questa domanda in quanto non conosco bene(quasi per niente) né Java né Perl.

Ma della jvm me ne sono occupato nel contest17; qualcosina so. Di Perl invece non so proprio niente. Non sapevo nemmeno che girasse su una virtual machine. So solo che è stato velocissimo nel punto b.1 del contest 19.
Anche la jvm s'è rivelata molto efficiente nel punto A del medesimo contest.

Un confronto si potrebbe fare sulla quantità di memoria utilizzata. Ci vuole qualcuno che conosca bene e l'una e l'altra delle vm.

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

The_ouroboros

14-02-2013, 20:21

perl non va su vm.
Perl usa reference count mentre java si basa sulla nullità degli oggetti (in soldoni, diciamo) :D

cdimauro

15-02-2013, 04:15

Anche CPython usa il reference count, mentre PyPy, Jython e IronPython usano GC più evoluti (tipo generazionali).

Difficile dire quale sia l'approccio migliore. il RC è molto semplice da implementare in una VM, e rilascia immediatamente la risorsa quando questa non è referenziata (a meno di strutture cicliche complesse; comunque prima o poi verrà eliminata), quindi anche l'operazione di GC è abbastanza prevedibile.

Viceversa, l'approccio usato nelle altre VM ha prestazioni complessivamente migliori, e compatta meglio la memoria, ma c'è lo svantaggio di occupare mediamente molta più memoria (perché si ritarda la sua liberazione) e che l'intervento del GC non è prevedibile e può mangiare una fetta consistente di CPU quando si attiva il processo, rendendo la VM non responsiva in quel momento (esistono approcci avanzati in sistemi multicore).

P.S. Anche Perl usa una VM.

The_ouroboros

15-02-2013, 05:50

vero :fagiano:
Devo smettere di rispondere alle cose dopo 10 ore di lavoro :P

The_ouroboros

15-02-2013, 07:43

Approccio generazionale?

Inviato dal mio LT22i con Tapatalk 2

cdimauro

15-02-2013, 10:03

http://blogs.msdn.com/b/abhinaba/archive/2009/03/02/back-to-basics-generational-garbage-collection.aspx
http://c2.com/cgi/wiki?GenerationalGarbageCollection

VICIUS

15-02-2013, 10:06

Approccio generazionale?

Inviato dal mio LT22i con Tapatalk 2

La jvm ha diversi algoritmi di gc anche piuttosto differenti tra di loro. In ogni caso tutti si basano sull'assunto che in genere gli oggetti hanno una vita brevissima. Questo porcata scritta in java per esempio:

for (int i = 0; i < 10000; ++i) {
t = new String(t + new String("a"));
}

Crea 4/5 nuovi oggetti ad ogni ciclo. Che possono essere buttati pochi nanosecondi dopo.

Quando un oggetto è creato viene messo in una zona del heap chiamata young generation che è quella che viene visitata più spesso dal gc. In genere gli oggetti che sono presenti in questa zona sono praticamente tutti rimossi ed i pochi che rimangono possono essere compattati in pochissimo tempo. Se un oggetto sopravvive ad un certo numero di passaggi viene promosso ad una zona chiamata tenure che contiene oggetti più vecchi che non ha senso controllare così spesso.

The_ouroboros

15-02-2013, 10:44

grazie per la spiegazione.
Argomento interessante in effetti.

Letture consigliate?

banryu79

15-02-2013, 11:30

grazie per la spiegazione.
Argomento interessante in effetti.

Letture consigliate?
Gli scritti di Brian Goetz (http://www.briangoetz.com/pubs.html) (sempre sia lodato!) :O

Puoi partire da qui -> http://www.ibm.com/developerworks/java/library/j-jtp10283/ per poi continuare a frugare con i link che trovi a fine articolo (l'articolo è il primo di una serie). Non preoccuparti per la data dell'articolo (2003), è un buon punto di partenza per approfondire l'arrgomento.

Parte due -> http://www.ibm.com/developerworks/java/library/j-jtp11253/

E tre -> http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html

Poi se non ti bastasse, beccati questa -> http://www.iecc.com/gclist/GC-faq.html

Vincenzo1968

15-02-2013, 11:40

Gli scritti in materia di Brian Goetz (sempre sia lodato!) :O
Puoi partire da qui -> http://www.ibm.com/developerworks/java/library/j-jtp10283/ per poi continuare a frugare con i link che trovi a fine articolo (l'articolo è il primo di una serie).
Non preoccuparti per la data dell'articolo (2003), è un buon punto di partenza per approfondire l'arrgomento.

E sempre sia lodata la IBM che pubblica articoli interessanti nel suo sito. Io, un per dire, ho trovato articoli su Flex e Bison di notevole interesse:

http://www.ibm.com/developerworks/linux/library/l-flexbison/index.html

http://www.ibm.com/search/csass/search/?sn=dw&lang=en&cc=US&en=utf&hpp=20&dws=dw&q=bison&Search=Search

:D

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

banryu79

15-02-2013, 12:08

E sempre sia lodata la IBM che pubblica articoli interessanti nel suo sito.
Amen :O

-> http://www.ibm.com/search/csass/search/?q=%22garbage+collector%22&dws=dw&ibm-search.x=0&ibm-search.y=0&sn=dw&lang=en&cc=US&ddr=&en=utf&lo=en&hpp=20

e questo è per Vincenzo, (sì lo so, è roba datata 2000 ma d'altronde tu 1968, ecchevuoi?) -> http://www.javaworld.com/jw-09-2000/jw-0915-lucene.html

Vincenzo1968

15-02-2013, 12:25

http://ecx.images-amazon.com/images/I/51ME%2BosGMrL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_.jpg

Ce l'ho :O

http://www.amazon.com/gp/product/0471941484/ref=nosim/104-1464220-8871162?n=283155

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

Vincenzo1968

15-02-2013, 12:28

Amen :O

-> http://www.ibm.com/search/csass/search/?q=%22garbage+collector%22&dws=dw&ibm-search.x=0&ibm-search.y=0&sn=dw&lang=en&cc=US&ddr=&en=utf&lo=en&hpp=20

e questo è per Vincenzo, (sì lo so, è roba datata 2000 ma d'altronde tu 1968, ecchevuoi?) -> http://www.javaworld.com/jw-09-2000/jw-0915-lucene.html

How search engines work

Creating and maintaining an inverted index is the central problem when building an efficient keyword search engine.

M'hanno rubato l'idea... :D

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

The_ouroboros

15-02-2013, 12:36

grazie a tutti per aver aiutato con i vostri link un povero sysadmin/integratore :D

Vincenzo1968

15-02-2013, 12:46

Lucene also implements a variety of tricks to compress the dictionary and posting files -- thereby reducing disk I/O -- without incurring substantial CPU overhead.

Minnale, mi rubano le idee! Pure io stavo pensando d'implementare una qualche forma di compressione per il mio indice...

:D

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

Vincenzo1968

15-02-2013, 16:24

Occhio!

L'ultima versione è la 5.16. Io avevo disgraziatamente installata la versione 5.14.
Ma ho prontamente aggiornato la versione:

http://img534.imageshack.us/img534/6731/perlversion.jpg

scaricando i sorgenti da qui:

http://www.perl.org/get.html#unix_like

Una volta scompattato il tar.gz, portatevi all'interno dela cartella e date i seguenti comandi:

sh Configure -de
make
sudo make install

Occhio! : http://www.cpan.org/

http://perldoc.perl.org/index-tutorials.html
http://www.perl.it//documenti/pod2it/index.html
http://www.perl.it/documenti/corsoperl.html

http://img154.imageshack.us/img154/1703/firmaclanubuntuhwupgrade0ot.png

WarDuck

15-02-2013, 18:06

Perl non lo utilizzerei neanche se rimanesse l'ultimo linguaggio di programmazione al mondo :asd:

Quindi il problema semplicemente non si dovrebbe neanche porre :asd:

GByTe87

15-02-2013, 18:11

The_ouroboros

15-02-2013, 18:39

Lo pensavo anche io anni fa...poi il perl mi ha conquistato...

Inviato dal mio LT22i con Tapatalk 2

Vincenzo1968

15-02-2013, 18:50

Intanto Perl è risultato velocissimo nel contest 19 contrariamente a Python. E tanto basta. :O

cdimauro

16-02-2013, 07:11

Perl non lo utilizzerei neanche se rimanesse l'ultimo linguaggio di programmazione al mondo :asd:

Quindi il problema semplicemente non si dovrebbe neanche porre :asd:
Perl o si ama o si odia. :D

Da ignorante (e pythonista), aborro la sua sintassi. :asd:
Vox populi, vox dei. :D
Lo pensavo anche io anni fa...poi il perl mi ha conquistato...
A morality tale of Perl versus Python (https://www.ibm.com/developerworks/mydeveloperworks/blogs/amcohen/entry/a_morality_tale_of_perl_versus_python263?lang=en)
Intanto Perl è risultato velocissimo nel contest 19 contrariamente a Python. E tanto basta. :O
E chi lo nega? In alcuni ambiti può rivelarsi più veloce, ma mediamente Python (3) è leggermente migliore di Perl (http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=perl). ;)

Inoltre non c'è nulla di simile a PyPy.

Comunque Perl ha una sintassi orribile e i sorgenti sono di gran lunga meno manutenibili. Difatti ha perso popolarità anche nell'ambito dell'amministrazione dei sistemi, che era il suo settore prediletto, dove persino Python sta prendendo sempre più piede.

The_ouroboros

16-02-2013, 07:22

Comunque Perl ha una sintassi orribile e i sorgenti sono di gran lunga meno manutenibili. Difatti ha perso popolarità anche nell'ambito dell'amministrazione dei sistemi, che era il suo settore prediletto, dove persino Python sta prendendo sempre più piede.
A me come sintassi piace molto.. Soprattutto Moose x l'oop :D

Inviato dal mio LT22i con Tapatalk 2

The_ouroboros

16-02-2013, 07:27

E cpan non lo trovi da nessun altra parte...

Inviato dal mio LT22i con Tapatalk 2

VICIUS

16-02-2013, 08:34

A me come sintassi piace molto.. Soprattutto Moose x l'oop :D

Inviato dal mio LT22i con Tapatalk 2
Hai avuto altre esperienze oppure perl è l'unico che conosci? Onestamente trovo difficile credere che esista qualcuno che, conoscendo uno degli altri linguaggi di scripting, possa decidere di usare di sua spontanea volontà perl.

E cpan non lo trovi da nessun altra parte...

Inviato dal mio LT22i con Tapatalk 2

CPAN è nato per il semplice motivo che la libreria standard di perl è comica. Non sono tutti al livello di java o .net ma in genere gli altri linguaggi non hanno bisogno di appoggiarsi a siti esterni se vogliono andare oltre l'hello world.

Che poi non ci sia niente di simile è una falsità. npmjs, rubyforge, pear, maven repository sono giusto un paio di siti che mi vengono in mente.

Vincenzo1968

16-02-2013, 09:08

Perché la considerate "orribile" la sintassi di Perl? Potreste farmi degli esempi esplicativi di qualche costrutto confrontandolo con quello degli altri linguaggi?

The_ouroboros

16-02-2013, 09:19

Hai avuto altre esperienze oppure perl è l'unico che conosci? Onestamente trovo difficile credere che esista qualcuno che, conoscendo uno degli altri linguaggi di scripting, possa decidere di usare di sua spontanea volontà perl.

python, js, C,C++,Java,C#,asm x86 e lisp :fagiano:

cdimauro

16-02-2013, 14:59

Perché la considerate "orribile" la sintassi di Perl? Potreste farmi degli esempi esplicativi di qualche costrutto confrontandolo con quello degli altri linguaggi?
Due cose al volo, che sono col telefonino.

La sintassi per manipolare i parametri passati a una su routine, e la "programmazione oggetti".

Sono le due cose che ricordo principalmente che mi hanno fatto accapponare la pelle. Ma c'è molto di più, ovviamente.

P.S. Concordo in toto con Vicius.

The_ouroboros

16-02-2013, 15:08

La sintassi per manipolare i parametri passati a una su routine, e la "programmazione oggetti".

io invece ho trovato queste cose molto belle e ben pensate :eek:
Il mondo è belle perchè è vario :cool:

The_ouroboros

16-02-2013, 15:09

package Point;
use Moose;
use Carp;

has 'x' => (isa => 'Num', is => 'rw');
has 'y' => (isa => 'Num', is => 'rw');

sub clear {
my $self = shift;
$self->x(0);
$self->y(0);
}

sub set_to {
@_ == 3 or croak "Bad number of arguments";
my $self = shift;
my ($x, $y) = @_;
$self->x($x);
$self->y($y);
}

package Point3D;
use Moose;
use Carp;

extends 'Point';

has 'z' => (isa => 'Num', is => 'rw');

after 'clear' => sub {
my $self = shift;
$self->z(0);
};

sub set_to {
@_ == 4 or croak "Bad number of arguments";
my $self = shift;
my ($x, $y, $z) = @_;
$self->x($x);
$self->y($y);
$self->z($z);
}

o

{
package Eatable;
use Moose::Role;

requires 'calories';

}

{
package Fruit;
use Moose;

has colour => (
is => "ro",
isa => "Str",
default => "See through" );
}

{
package Banana;
use Moose;
extends 'Fruit';
with 'Eatable';

has quantity => (
is => "ro",
isa => "Int",
default => 1 );

has paid => (
is => "rw",
isa => "Int",
default => 30 );

sub calories {
my ($self,@stuff) = @_;
return 42;
}

no Moose;
}

E bellissimo, almeno per me :D

VICIUS

16-02-2013, 17:07

La sintassi usata in perl per definire i metodi è un crimine contro l'umanità. La signature è una parte importantissima che concentra tantissime informazioni utili a chi legge il codice. La funzione accetta parametri? Quali sono? Hanno un tipo? Se si quale? Ritorna un valore? ecc.

In un linguaggio come C ad posso sapere tantissime cose sulla funzione semplicemente leggendomi una riga ignorando la sua implementazione. Con perl questo non lo posso fare. Sono costretto a leggermi l'intero metodo per sapere cosa fa di preciso e come devo chiamarlo.

Questo è un problema per me programmatore perché mi costringgere a leggere tonnellate di codice in più facendomi perdere tempo. Inoltre pone un limite ai controlli che l'interprete può fare sul codice. Non potendo sapere quanti sono i parametri perl non ha modo di dirti se stai sbagliando ad invocore un certo metodo. In php, che è un perl riuscito un po' meglio, posso comunque chiamare una funzione che ha due parametri passandone uno solo ma almeno mi stampa un warning.

Poi in ordine sparso ci sono l'uso di %, $, @, & per distinguere tra hash, array, ecc. Variabili dai nomi assurdi come $_ senza un motivo o altri costrutti come "$a = <>;" di cui non ricordo nemmeno il nome.

In sostanza quello che mi da fastidio di perl è l'inutile cripticità della sintassi. In alcuni è come se sia stata scelta una certa sintassi solo perché mettere quel simbolo li in quel modo faceva figo. Dimenticando completamente che i programmi vanno scritti per noi stessi e gli altri programmatori. Al computer che una cosa sia scritta in brainfuck, perl o java interessa poco.

Non mi sono mai addentrato abbastanza in perl per arrivare a fare oop. Dagli esempi che hai postato mi pare di capire che sia più un hack basato sui namespace piuttosto che di veri e propri oggetti.

Faccio un piccolo appunto su uno degli esempi che hai postato. Usare l'ereditarietà per creare un Point3D a partire da un Point è una pessima idea. In casi come questo in cui si va ad aggiungere è quasi sempre preferibile usare la composizione. Come è scritto ora è impossibile definire un operatore di uguaglianza che sia simmetrico. Finiresti col avere bug assurdi.

The_ouroboros

16-02-2013, 17:20

Categorico...
Rispetto la tua opinione ma amo lo stesso il perl...

Inviato dal mio LT22i con Tapatalk 2

banryu79

16-02-2013, 20:15

Categorico...
Rispetto la tua opinione ma amo lo stesso il perl...

Basta che non ti fai male... :D

...
LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months from now.

Geniale :asd:

Vincenzo1968

16-02-2013, 22:02

Quindi alla fine il miglior linguaggio in assoluto resta il C.
Python o è inefficiente dal punto di vista della velocità d'esecuzione(CPython) o è un po' più efficiente come prestazioni(ma non di moltissimo) ma inefficiente dal punto di vista delle risorse utilizzate(PyPy, etc)(quantità di ram occupata per via del GC). Insomma è inefficiente. Lo stesso dicasi per gli altri linguaggi.

Grazie a tutti per avermi chiarito le idee. Mi tengo stretto il mio linguaggio :O

Ciao.

GByTe87

16-02-2013, 23:05

Discorso già fatto, C è inefficiente sul versante TTM (Time To Market). :O

wingman87

17-02-2013, 00:23

Non ho mai studiato nulla di Perl, però alcune delle critiche fatte da VICIUS secondo me potrebbero applicarsi anche a Python. Linguaggio di cui non sono un esperto, ho solo letto un libro tradotto male, e quindi potrei anche sbagliarmi...

cdimauro

17-02-2013, 14:20

Categorico...
Rispetto la tua opinione ma amo lo stesso il perl...
Sui gusti non si discute.
Quindi alla fine il miglior linguaggio in assoluto resta il C.
Python o è inefficiente dal punto di vista della velocità d'esecuzione(CPython) o è un po' più efficiente come prestazioni(ma non di moltissimo) ma inefficiente dal punto di vista delle risorse utilizzate(PyPy, etc)(quantità di ram occupata per via del GC). Insomma è inefficiente. Lo stesso dicasi per gli altri linguaggi.

Grazie a tutti per avermi chiarito le idee. Mi tengo stretto il mio linguaggio :O

Ciao.
Ne abbiamo già parlato non so quante volte, ma sei veramente duro.

Chiediti perché YouTube è realizzato interamente in Python (a parte Lighttpd, che è in C). Perché Google, Amazon, ecc. usano così tanto Python? Sono masochisti?
Discorso già fatto, C è inefficiente sul versante TTM (Time To Market). :O
Ma non solo: anche la leggibilità e la manutenibilità del codice vanno a braccetto con Python. :)
Non ho mai studiato nulla di Perl, però alcune delle critiche fatte da VICIUS secondo me potrebbero applicarsi anche a Python. Linguaggio di cui non sono un esperto, ho solo letto un libro tradotto male, e quindi potrei anche sbagliarmi...
Ti sbagli sicuramente. Nulla di quanto ha scritto su Perl è applicabile a Python.

Python è l'antitesi di Perl.

Vincenzo1968

17-02-2013, 15:11

http://img89.imageshack.us/img89/3695/successfulltrollj.jpg
.

Vincenzo1968

17-02-2013, 15:18

The_ouroboros

17-02-2013, 15:38

i gc sono molto migliorati da quando java era più "lento" di C/C++ (ma molto più gestibile).
E cmq nulla è assoluto :fagiano:

WarDuck

17-02-2013, 15:39

Ammatula che Vicius dica: "la jvm ha diversi algoritmi di gc anche piuttosto differenti tra di loro. In ogni caso tutti si basano sull'assunto che in genere gli oggetti hanno una vita brevissima".
Dalla discussione emerge che il GC o rallenta le prestazioni o combina porcherie con l'occupazione di memoria.
Quindi i linguaggi possono classificarsi in:

1) Linguaggi buoni: tutti quei linguaggi che non utilizzano GC.
2) Linguaggi non buoni: tutti quei linguaggi che utilizzano GC.

Ergo:

Linguaggi buoni: C, C++.
Linguaggi non buoni: tutti gli altri.

:O

Un linguaggio non usa un Garbage Collector.

L'implementazione di un linguaggio può, tant'è che esistono alcune librerie C++ per implementarlo anche in programmi scritti con questo linguaggio.

Nota comunque che un garbage collector per rilasciare le risorse può risultare più efficiente della gestione manuale, in quanto nel primo caso spesso la VM può fare auto-profiling e capire da sola quando è conveniente fare GC.

Lasciati inoltre dire che è una tremenda cazzata dividere i linguaggi in "buoni" o "non buoni", specie se il criterio che scegli è ad-minchiam.

Vincenzo1968

17-02-2013, 17:25

Lasciati inoltre dire che è una tremenda cazzata dividere i linguaggi in "buoni" o "non buoni", specie se il criterio che scegli è ad-minchiam.

Senti ma l'hai notato il mio post precedente con questa?

http://img89.imageshack.us/img89/3695/successfulltrollj.jpg

WarDuck

17-02-2013, 17:44

Senti ma l'hai notato il mio post precedente con questa?

http://img89.imageshack.us/img89/3695/successfulltrollj.jpg

No, delle tue faccine (oltre ad essere esteticamente orribili) non mi interessa nulla.

wingman87

17-02-2013, 21:08

Ti sbagli sicuramente. Nulla di quanto ha scritto su Perl è applicabile a Python.

Anche questo?
In un linguaggio come C ad posso sapere tantissime cose sulla funzione semplicemente leggendomi una riga ignorando la sua implementazione. Con perl questo non lo posso fare. Sono costretto a leggermi l'intero metodo per sapere cosa fa di preciso e come devo chiamarlo.
Nel caso di python è un problema legato alla tipizzazione dinamica. Se non è così c'è qualcosa che non mi torna.

E sempre sulla stessa questione:
Questo è un problema per me programmatore perché mi costringe a leggere tonnellate di codice in più facendomi perdere tempo. Inoltre pone un limite ai controlli che l'interprete può fare sul codice.

Vincenzo1968

17-02-2013, 22:36

Ti sbagli sicuramente. Nulla di quanto ha scritto su Perl è applicabile a Python.

Python è l'antitesi di Perl.

Che babbiamo? Si sbaglia sicuramente!

Criticare python... Cose da pazzi :rolleyes:
Accostare python a perl... E dove siamo? Nel Congo Belga?(cit.)

Wingman ma che ti salta in mente? :rolleyes:

cdimauro

18-02-2013, 05:52

Anche questo?

Nel caso di python è un problema legato alla tipizzazione dinamica. Se non è così c'è qualcosa che non mi torna.

E sempre sulla stessa questione:
La tipizzazione dinamica è un problema che riguarda ovviamente tutti i linguaggi che ne fanno uso, e dunque Python non è certo escluso.

Ciò detto, in quel contesto Vicius si riferiva alla firma della funzione, che in Perl è... sconosciuta. Non sai quanti parametri possono essere passati finché, appunto, non vai a vedere nel codice. Cosa che non si applica sicuramente a Python, in quanto ogni funzione ha una firma che consente di capire subito di quanti parametri ha bisogno.

Di fatti dal messaggio di Vicius non hai riportato alcuni pezzi, in cui chiariva proprio questo aspetto, e faceva anche un confronto con PHP...

Al netto dei tipi dei parametri, ovviamente, ma questo dipende dalla sua natura dinamica, e lo stesso vale per tutti i linguaggi simili. Scegliendo dei nomi autoesplicativi sia per il nome della funzione/metodo, che per i parametri, questo problema dovrebbe venir risolto.

Se ciò non fosse sufficiente, a partire da Python 3 è possibile "annotare" il tipo e il risultato di una funzione (http://www.python.org/dev/peps/pep-3107/):
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
...

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
...
Una delle possibili applicazioni di questa nuova funzionalità è proprio lo static type checking per strumenti di analisi del codice, oppure per progetti come Cython, che a questo punto possono fare a meno della loro sintassi speciale per indicare al compilatore il tipo dei parametri e/o del risultato finale, per generare il codice finale ottimizzato in base al tipo passato.

Python, come vedi, non è certo paragonabile a Perl.
Che babbiamo? Si sbaglia sicuramente!

Criticare python... Cose da pazzi :rolleyes:
Accostare python a perl... E dove siamo? Nel Congo Belga?(cit.)

Wingman ma che ti salta in mente? :rolleyes:
Questo si chiama trollare, ed è una cosa che fai spesso. E lo fai perché sei sostanzialmente ignorante all'infuori dal tuo mondo C-centrico, che cerchi di proteggere in tutti i modi. Tipico atteggiamento del programmatore che conosce un solo strumento, e classifica come letame gli altri, per difendere il "suo".

Infatti parli di cose che sconosci, e non lo fai nemmeno con l'umiltà di chi, non sapendo, vorrebbe imparare qualcosa di nuovo. I tuoi interventi quando si parla di confronti di linguaggi di programmazione sono sempre dello stesso tipo (eloquente la tua "classificazione" in "buoni" e "non buoni").

Spero che la mia risposta a wingman87 sia sufficiente a farti capire che il silenzio sarebbe una scelta migliore quando non si sa di cosa si parla, invece di far divampare inutili flame.

The_ouroboros

18-02-2013, 06:50

Se ciò non fosse sufficiente, a partire da Python 3 è possibile "annotare" il tipo e il risultato di una funzione (http://www.python.org/dev/peps/pep-3107/):
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
...

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
...
Una delle possibili applicazioni di questa nuova funzionalità è proprio lo static type checking per strumenti di analisi del codice, oppure per progetti come Cython, che a questo punto possono fare a meno della loro sintassi speciale per indicare al compilatore il tipo dei parametri e/o del risultato finale, per generare il codice finale ottimizzato in base al tipo passato.

Interessante, si vede che il python 3 non l'ho ancora visto per bene rimanendo al 2...
Grazie per questo tip che non conoscevo :)

cdimauro

18-02-2013, 07:40

The_ouroboros

18-02-2013, 07:43

Infatti in giro vedo molto 2.7.. Anche dove lavoro io..

Inviato dal mio LT22i con Tapatalk 2

wingman87

18-02-2013, 08:24

La tipizzazione dinamica è un problema che riguarda ovviamente tutti i linguaggi che ne fanno uso, e dunque Python non è certo escluso.
Sì, diciamo che la tipizzazione dinamica ha i suoi pregi ma anche i suoi difetti... Il più grossi secondo me sono quelli che ho sollevato.

Ciò detto, in quel contesto Vicius si riferiva alla firma della funzione, che in Perl è... sconosciuta. Non sai quanti parametri possono essere passati finché, appunto, non vai a vedere nel codice. Cosa che non si applica sicuramente a Python, in quanto ogni funzione ha una firma che consente di capire subito di quanti parametri ha bisogno.

Di fatti dal messaggio di Vicius non hai riportato alcuni pezzi, in cui chiariva proprio questo aspetto, e faceva anche un confronto con PHP...

Non volevo fare un confronto con Perl, che non conosco. Quindi il mio intervento non andava letto come "sotto questi aspetti Perl è come Python", ma andava letto come "queste stesse critiche si potrebbero fare anche a Python", forse avrei potuto specificare, in modo più generale, ai linguaggi a tipizzazione dinamica.

Se ciò non fosse sufficiente, a partire da Python 3 è possibile "annotare" il tipo e il risultato di una funzione (http://www.python.org/dev/peps/pep-3107/):
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
...

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
...
Una delle possibili applicazioni di questa nuova funzionalità è proprio lo static type checking per strumenti di analisi del codice, oppure per progetti come Cython, che a questo punto possono fare a meno della loro sintassi speciale per indicare al compilatore il tipo dei parametri e/o del risultato finale, per generare il codice finale ottimizzato in base al tipo passato.

Questa è una caratteristica mooolto interessante, che potrebbe cambiare da così a così la mia attuale opinione sul linguaggio.

kwb

18-02-2013, 09:51

Purtroppo Python 3 non riesce a prendere piede, a causa di alcune scelte (legittime) che sono state fatte, che rendono difficile il porting dei vecchi moduli Python 2.x.

Altrimenti ci sarei (saremmo, perché è il desidero di tutta la comunità) passato già da un bel pezzo.

Sono passati già più di 4 anni dalla 3.0, da poco è stata rilasciata la 3.3, e purtroppo per andare in produzione spesso siamo costretti a rimanere alla 2.7...
Da principiante di python, che ha iniziato con Python 2.7, posso dire che credo bene che la gente sia un po' restia a usare python 3.
Ora non so bene quali modifiche siano state apportate ma la cosa che ho notato subito ( e penso di non essere stato l'unico ) è il cambio del print, trasformato in funzione.
Per come la vedo io, sebbene ci sia stata la volontà di uniformare e unire i comandi sotto un'unica linea ( come mi hai spiegato ), cambiare il print dopo 2.7 releases di python mi è parso un po' stupido. Soprattuto considerando che l'interprete 3.3 non è retrocompatibile con il vecchio print ( ho passato ore in cui credevo che l'interprete 3.3 non si fosse installato correttamente sulla macchina :rolleyes: ) .

Come ripeto, non so di preciso quali cambiamenti siano stati fatti, ma il cambio di un comando fondamentale come il print non mi è parsa una mossa astuta.

Detto ciò mi eclisso e torno nelle tenebre a seguire questa discussione :Prrr:

The_ouroboros

18-02-2013, 10:03

mi pare di ricordare, in effetti, che abbia rotto un sacco di programmi e librerie "legacy" :stordita:

cdimauro

18-02-2013, 10:15

Se hai dubbi è giusto che ne parli, perché come li hai tu li avranno anche altri utenti, e se si può dare una mano per chiarire alcune questione, peraltro importanti, lo si fa.

Le modifiche principali, e incompatibili, di Python 3 rispetto ai predecessori sono le seguenti:
- print non è più un'istruzione, ma una funzione;
- le stringhe sono unicode; le vecchie stringhe "di default", sono invece oggetti "byte" (contengono byte grezzi);
- conseguenza del punto precedente, i file di testo restituiscono stringhe (unicode) anziché le vecchie stringhe di byte;
- l'operatore <> non esiste più, e c'è soltanto != per l'ineguaglianza;
- non esistono più gli interi, ma soltanto i long; per la precisione, i long hanno preso il posto degli interi.

Nel primo caso si tratta di un grosso cambiamento, è inutile negarlo, ma si tratta di una cosa che Python si porta appresso da troppo tempo. E', infatti, un'eccezione al linguaggio, che prevede una sintassi apposta per una funzionalità che, sebbene comune, non meritava, appunto, di essere trattata diversamente dagli altri casi (open, ad esempio).
Inoltre la nuova forma della print consente una flessibilità maggiore.

Il secondo punto riguarda una delle problematiche che viene spesso dimenticata o è, peggio ancora, sconosciuta: quella delle codifica dei caratteri (ne sa qualcosa chi sta partecipando a uno dei contest). Avendo come stringhe quelle unicode "di default", anziché i byte grezzi (e quindi senza codifica), questo problema viene risolto e i programmatori sono sensibilizzati sull'argomento.

Il terzo, come dicevo, dipende dal secondo, e ne condivide problematiche e ragioni d'essere.

Il quarto rientra nella filosofia di Python: niente duplicazioni di funzionalità.

Idem per il quinto caso: gli int rappresentavano una duplicazione dei long, visto che questi ultimi potevano coprire esattamente tutto ciò che gli int facevano... e molto di più (sono interi a precisione illimitata). E' proprio questa la modifica più grossa, che crea parecchie rogne nel porting dei moduli da Python 2.x a Python 3.

Comunque c'è da dire che il passaggio a Python 3 non è stato certo deciso senza tenere conto di queste problematiche, e offrire adeguati strumenti per la transizione.
Infatti fin da Python 2.6 è possibile modificare il comportamento del compilatore in modo da adeguarsi ai cambiamenti imposti dal Python 3.
Ad esempio:
from __future__ import print_statement
in questo modo print non è più un'istruzione, ma diventa una funzione, come per Python 3, anche se si sta usando Python 2.6 (o 2.7: è uguale), e si potrà testare bene il nostro codice prima di fare il grande passo.
Nulla è stato lasciato al caso, ed è previsto anche uno script, 2to3, che consente di effettuare una conversione "grossolana" (per quanto possibile) del sorgente Python 2.6 in Python 3.

Spero sia utile a chi voglia approcciarsi alla nuova versione di Python, che rappresenta sicuramente il futuro di questo linguaggio.

The_ouroboros

18-02-2013, 10:21

leggevo che avevano previsto dal lancio della 3.1, 5 anni per l'adozione.
La 3.0 mi pare avesse problemi di I/O e quidi non contasse come inizio timeline

cdimauro

18-02-2013, 10:32

La 3.0 è stato un enorme lavoro, che purtroppo s'è trascinato alcune problematiche e bug, che sono stati corretti nella 3.1, rilasciata poco dopo. D'altra parte c'era da aspettarselo: troppi i cambiamenti fatti.

Comunque non è che la 3.0 non debba essere considerata. Dato il poco lasso di tempo rispetto alla 3.1, diciamo che quest'ultima l'ha eclissata.

Ciò detto, non ricordo la previsione di 5 anni per l'adozione di Python 3. Non credo sia realistica, perché tutto dipende dal porting dei moduli, e quelli non sono a carico della comunità degli sviluppatori (core) di Python, ma di chi realizza tali librerie, coi loro tempi...