Php vs others!

[defacer]

ΌΤΑΝ γίνει αυτό ΕΧΩ ΠΡΟΒΛΗΜΑ ΝΑ ΧΡΗΣΙΜΟΠΟΙΗΣΩ implicit convert ?

 

Όχι, δεν έχεις. Το point μου είναι πως εφόσον έχεις ήδη φτάσει στο σημείο να τα κάνεις όλα αυτά, το implicit conversion πλέον είναι ανάξιο λόγου.

 

Επίσης, ένας "προτεινόμενος" τρόπος να κάνεις το validation είναι χρησιμοποιώντας τη filter_var('123', FILTER_VALIDATE_INT), η οποία σου κάνει το conversion μόνη της. Αν πας μ' αυτό τον τρόπο δεν υπάρχει καν το implicit.

 

Και τέλος δεν έχω κάποιο θέμα με τα implicit όπως δεν έχω και με όλα τα άλλα πράγματα της PHP. It's a tool, I use it. But it's a badly built tool.

[geomagas]

Βγαίνουμε πολύ offtopic γιατί καταλήξαμε στα interviews κλπ. Νομίζω δεν έχει νόημα να συνεχίσουμε στο thread, οπότε δίνω ένα σε spoiler κι απο κει και πέρα μαλλον καλύτερα με PM?

 

Όλο το spoiler είναι ακριβώς ο λόγος που δεν είχα ποτέ καμία ονείρωξη με τις συνεντεύξεις...

Όσο σκέφτομαι ότι συμβαίνουν τέτοια πράγματα στον κόσμο...

 

Το PM δεν έχει κανένα νόημα σ' ένα forum, εκτός αν θέλεις να αναφερθείς επί προσωπικού, που δεν βλέπω το λόγο.

 

Ontopic:

Ακόμα προσπαθώ να καταλάβω πως δικαιολογείται η έκφραση "είναι για πέταμα".

Εντάξει, θα μπορούσε να έχει φτιαχτεί αλλιώς "από κάτω" και να είναι πιο αποδοτική.

Εντάξει, πολλοί θα προτιμούσαν διαφορετική σύνταξη και, στην τελική, συμπεριφορά.

Εντάξει, φτιάχνει το μουσακά με άλλη συνταγή.

Αλλά double-clawed hammer από πού κι ως πού;

 

Μάλλον θα πρέπει να εκπαιδευτώ λίγο παραπάνω στο "έτσι είναι αν έτσι πιστεύεις"...

[Aztec]

Όχι, δεν έχεις. Το point μου είναι πως εφόσον έχεις ήδη φτάσει στο σημείο να τα κάνεις όλα αυτά, το implicit conversion πλέον είναι ανάξιο λόγου.

 

Επίσης, ένας "προτεινόμενος" τρόπος να κάνεις το validation είναι χρησιμοποιώντας τη filter_var('123', FILTER_VALIDATE_INT), η οποία σου κάνει το conversion μόνη της. Αν πας μ' αυτό τον τρόπο δεν υπάρχει καν το implicit.

 

Και τέλος δεν έχω κάποιο θέμα με τα implicit όπως δεν έχω και με όλα τα άλλα πράγματα της PHP. It's a tool, I use it. But it's a badly built tool.

 

 

βρε συ defacer πες οτι εγω θέλω να κάνω το validation με loop και ascii chart. Αλλα στη συνέχεια ο αλγοριθμος απαιτεί να πάρω εναν εναν τους χαρακτηρες να τους πολλαπλασιάσω με εναν εναν απο τους χαρακτήρες απο ένα άλλο string .Και λεώ string γιατί δεν μπορείς να κάνεις cast το '00000001'.Χρειάζεσαι τα μηδενικά.Σε όλα αυτες τις πράξεις δεν θα χρειαστώ καθόλου να κάνω cast. 

 

To point ποιο είναι ? σωστά μιλάς όταν λες ότι καλύτερα είναι να ξέρουμε τι γίνεται και να μην έχουμε δυσάρεστα αποτελέσματα. Αλλά καποιες φορές το implicit conversion βολευει. 

 

Πολύ καλό παράδειγμα που πείθει έχω στην SQL αλλά είναι εκτός θέματος

[defacer]

Όλο το spoiler είναι ακριβώς ο λόγος που δεν είχα ποτέ καμία ονείρωξη με τις συνεντεύξεις...

Όσο σκέφτομαι ότι συμβαίνουν τέτοια πράγματα στον κόσμο...

Θα ήταν ενδιαφέρον το ποιά είναι αυτά τα πράγματα και γιατί τα θεωρείς τόσο άσχημα. Αλλά offtopic.

 

Ακόμα προσπαθώ να καταλάβω πως δικαιολογείται η έκφραση "είναι για πέταμα".

Εντάξει, θα μπορούσε να έχει φτιαχτεί αλλιώς "από κάτω" και να είναι πιο αποδοτική.

Εντάξει, πολλοί θα προτιμούσαν διαφορετική σύνταξη και, στην τελική, συμπεριφορά.

Εντάξει, φτιάχνει το μουσακά με άλλη συνταγή.

Αλλά double-clawed hammer από πού κι ως πού;

 

Μάλλον θα πρέπει να εκπαιδευτώ λίγο παραπάνω στο "έτσι είναι αν έτσι πιστεύεις"...

Δεν ξέρω πώς αλλιώς να το πω.

 

Δε με απασχολεί η σύνταξη και δε με απασχολεί η documented συμπεριφορά. Με απασχολεί πως στην PHP γίνεται απλά ο,τι να 'ναι. Και γίνεται σε τέτοιο βαθμό που όταν βγαίνεις εσύ και λες "δε βλέπω το πρόβλημα" μου είναι πολύ δύσκολο να κάνω άλλη σκέψη πέρα του ότι αν δε βλέπει το πρόβλημα δεν υπάρχει άλλη περίπτωση παρά το ότι δε θέλει ή δε μπορεί να το δει.

 

Γράψε σε μια λίστα τις γλώσσες που ξέρεις, κι αυτές που δεν ξέρεις ακριβώς αλλά πάνω κάτω το έχεις πιάσει το νόημα, έχεις διαβάσει άλλους που τις ξέρουν καλά, πράγματα δηλαδή που ακόμα κι αν δεν τα ξέρεις απο πριν όταν τα βλέπεις είναι κατανοητά. Βάλτες στη σειρά από την πιο καλοσχεδιασμένη στην πιο κακοσχεδιασμένη.

 

Εγώ αν το κάνω αυτό, τελευταία στη λίστα είναι η PHP με μεγάλη διαφορά από την προτελευταία (θέση στην οποία μάλλον θα βάλω τη JavaScript αν και δεν είμαι σίγουρος). Και τυχαίνει (ή ίσως πετυχαίνει) η PHP να είναι μια γλώσσα που τη γνωρίζω σε βάθος επί πολλά χρόνια, οπότε ξέρω όχι μόνο τα μηχανικά της μέρη αλλά και τη φιλοσοφία και την ιστορία και ενίοτε και τα παρασκήνιά της, οπότε δε μου έχει μείνει κανένα περιθώριο για να δικαιολογήσω (benefit of the doubt) τα κακώς κείμενα. Γι' αυτό τη λέω γλώσσα για πέταμα.

 

Τι άλλο να πω; Ότι ο Rasmus ο ίδιος (ειδικά η τότε εκδοχή του Rasmus) κατ' επανάληψη έχει αναφερθεί στον εαυτό του ως χομπίστα και "βαριέται να προγραμματίσει" και άλλα τέτοια; Ότι οι παλιότερες εκδόσεις πριν την Zend Engine 2 (pure Rasmus δηλαδή) ήταν για πέταμα στο τετράγωνο; Δεν ξέρω πώς να το μεταδώσω πραγματικά.

 

Ίσως με αντιπαράδειγμα τη Ruby? Ο Matz έχει πει αρκετές φορές πως βασικός του μπούσουλας ήταν το principle of least surprise, πράγμα το οποίο νομίζω δε χρειάζεται να συζητήσουμε. Μπορείς να κοιταχτείς στον καθρέφτη και να βάλεις την PHP και το least surprise στην ίδια πρόταση;

 

Στο PHP chatroom του StackOverflow μιλάνε top rated users σχολιάζοντας το "PHP sucks" και κανένας δε λέει το αντίθετο. Απλά λένε "ναι απλά άλλο να το λες για rant κι άλλο να κάνεις σωστή κριτική", "maybe sucks αλλά τη δουλειά την κάνει με το παραπάνω" και άλλα τέτοια.

 

Στην τελική πες μου το εξής. Ποιά είναι για σένα η χειρότερη γλώσσα που έχεις πιάσει στα χέρια σου και γιατί; Από την απάντησή σου νομίζω θα φανούν πολλά.

 

@Aztec δε διαφωνούμε σε κάτι.

[geomagas]

Δε με απασχολεί η σύνταξη και δε με απασχολεί η documented συμπεριφορά. Με απασχολεί πως στην PHP γίνεται απλά ο,τι να 'ναι. Και γίνεται σε τέτοιο βαθμό που όταν βγαίνεις εσύ και λες "δε βλέπω το πρόβλημα" μου είναι πολύ δύσκολο να κάνω άλλη σκέψη πέρα του ότι αν δε βλέπει το πρόβλημα δεν υπάρχει άλλη περίπτωση παρά το ότι δε θέλει ή δε μπορεί να το δει.

Ε, εμένα με απασχολεί η σύνταξη και η documented συμπεριφορά. Θέλω απλά να μου δίνουν ότι μου υπόσχονται. Μετά απ' αυτό, με συγχωρείς αλλά δεν μπορώ να δω πρόβλημα...

 

Στην τελική πες μου το εξής. Ποιά είναι για σένα η χειρότερη γλώσσα που έχεις πιάσει στα χέρια σου και γιατί; Από την απάντησή σου νομίζω θα φανούν πολλά.

 

Η javascript. Διότι δεν έχω χωνέψει ακόμα τη λογική με τα prototypes.

Αν έπρεπε να αποφασίσω, θα έλεγα ότι η δεύτερη είναι η php. Έρχομαι από background με strict types και όλες οι "χαλαρές" γλώσσες με κάνουν να νοιώθω ότι θα πρέπει να διπλοτσεκάρω τα πάντα.

 

Αυτά όμως είναι δικά μου βίτσια. Μέχρι να φτάσω να πω ότι μία γλώσσα είναι για πέταμα... ε, έχω δρόμο...

 

Γράψε σε μια λίστα τις γλώσσες που ξέρεις...

κλπ

 

Μπα... Αντί για αυτά, έκανα κάτι πιο χρήσιμο.

Επειδή αναφέραμε τη reset() vs array_values() και χώσαμε και λίγο O-notation, είπα να εξετάσω σε τι βαθμό ακριβώς η array_values() είναι αναποτελεσματική (ήμουν σίγουρος ότι είναι, απλά δεν ήξερα πόσο).

Έκανα λοιπόν ένα στοιχειώδες benchmark, με εντυπωσιακά αποτελέσματα. Απολαύστε υπεύθυνα.

 

Σημείωση: Το έτρεξα σε δύο άλλους servers με ανάλογα αποτελέσματα, και με πιο μεγάλο array. Επειδή είμαι και λίγο ζαλισμένος, αν έχω κάνει καμιά πατάτα, πείτε μου. Για να μπορώ κι εγώ να σταθώ αξιοπρεπώς σε μία συνέντευξη...

 

Εγώ πάντως, κάτι έμαθα σήμερα.

[defacer]

Έκανα λοιπόν ένα στοιχειώδες benchmark, με εντυπωσιακά αποτελέσματα. Απολαύστε υπεύθυνα.

 

Πλάκα κάνεις έτσι; Μετράς ένα iteration και έχεις signal to noise μικρότερο της μονάδας. Επιπλέον ακόμα και στο ένα iteration που μετράς το πιο expensive operation είναι... το warning που προκαλείς με την "κακή" κλήση της reset().

 

Δε θα πω πολλά για να μην πατρονάρω πάλι, αλλά ίσως πρωτού αρχίσεις να μαθαίνεις από τα αποτελέσματα των benchmarks καλό θα ήταν να μάθεις πρώτα να κάνεις benchmarks.

 

<?php

$arraySize = $argv[1];
$iterations = $argv[2];

function get_my_array()
{
    global $a;
    return $a;
}

echo "Array size: $arraySize elements\n";
$a = array_fill(0, $arraySize, null);

echo "reset() x $iterations: ";
$t=microtime(true);
for($i = 0; $i < $iterations; ++$i) {
    $b = get_my_array();
    $x = reset($;
}
$t=microtime(true)-$t;
echo " $t sec\n";


echo "array_values() x $iterations: ";
$t=microtime(true);
for($i = 0; $i < $iterations; ++$i) {
    $x = array_values(get_my_array())[0];
}
$t=microtime(true)-$t;
echo "$t sec\n";

 

 

Intel Core 2 Duo E8400 @ 3.6GHz

F:\www\@php>php -f test.php 10000 1000
Array size: 10000 elements
reset() x 1000:  0.70503997802734 sec
array_values() x 1000: 1.534087896347 sec


F:\www\@php>php -f test.php 100000 1000
Array size: 100000 elements
reset() x 1000:  9.3735361099243 sec
array_values() x 1000: 19.839135169983 sec


F:\www\@php>php -f test.php 1000 10000
Array size: 1000 elements
reset() x 10000:  0.54003000259399 sec
array_values() x 10000: 0.96905493736267 sec


F:\www\@php>php -f test.php 1000 100000
Array size: 1000 elements
reset() x 100000:  4.6632671356201 sec
array_values() x 100000: 9.1105208396912 sec

 

 

 

Και για να καταλάβεις πόσο κακό κάνει το warning εδώ, επανάληψη του τελευταίου run με $x = reset(get_my_array()):

 

 

 

F:\www\@php>php -f test.php 1000 100000

Array size: 1000 elements

reset() x 100000:  4.6742670536041 sec

array_values() x 100000: 9.1935257911682 sec

 

F:\www\@php>php -f test.php 1000 100000

Array size: 1000 elements

reset() x 100000:  9.3115320205688 sec

array_values() x 100000: 9.0915198326111 sec

 

 

 

 

Ελπίζω όντως να έμαθες κάτι σήμερα.

[Kercyn]

 

 

Μετράς ένα iteration και έχεις signal to noise μικρότερο της μονάδας

 

Επειδή θα με ενδιαφέρουν πολύ σύντομα τα benchmarks, μπορείς να μου πεις τι εννοείς εδώ;

[defacer]

Ότι το resolution της επιστρεφόμενης τιμής της microtime() είναι πολύ λίγο για να μετρήσεις σαφώς το πόσο πήρε ένα μόνο iteration.

 

Αν ας πούμε έχεις να μετρήσεις "με το μάτι" κάποιο event που παίρνει 0.3s με ένα ρολόι ακρίβειας 1s τότε ξεκινώντας τη μέτρηση σε τυχαία χρονική στιγμή έχεις 30% να πάρεις μέτρηση 1s και 70% να πάρεις 0s. Η κάθε μία μέτρηση είναι λάθος (στην πρώτη περίπτωση είναι 233% λάθος και στην άλλη "μόνο" 100%).

 

Αν όμως κάνεις 100 μετρήσεις στατιστικά θα πάρεις 0.3 * 100 * 1 + 0.7 * 100 * 0 = 30sec, που διαιρώντας το με το 100 φτάνεις στη σωστή μέτρηση 0.3 (με ικανό sample size, και 100 ίσως λίγο είναι γιατί μπαίνουν κι άλλοι παράγοντες).

[Kercyn]

Μάλιστα, οπότε (για να δω αν κατάλαβα) λες ότι το 1 function call γίνεται resolve πολύ γρήγορα για να το πιάσει το ρολόι, κι έτσι είναι λάθος να πάρουμε μόνο ένα δείγμα. Ξεκινάμε τη μέτρηση στο 1 call, περιμένουμε να περάσουν όλα τα iterations, μετράμε πάλι και διαιρούμε με τον αριθμό των iterations;

[defacer]

Ναι.

 

Όχι αναγκαστικά όμως ότι το ίδιο το call γίνεται πολύ γρήγορα για το ρολόι. Δε μετράς μόνο το call, μετράς μαζί και άλλα πράγματα όπως την ίδια την κλήση της microtime κλπ. Μπορεί π.χ. η microtime() να λέει ότι έχει 1nsec ακρίβεια, αλλά τι να το κάνεις αυτό όταν το ίδιο το call στη microtime() παίρνει ~100nsec? Σ' αυτή την περίπτωση μετρώντας κάτι που παίρνει 2 ή 4 nsec εσύ θα βλέπεις ότι έχουν διαφορά ~2% ενώ στην πραγματικότητα η διαφορά είναι 100%.

 

Επιπλέον αν έχεις ας πούμε ένα event στα 0.3s κι ένα ρολόι στα 0.2s πάλι θα έχεις 50% σφάλμα παρόλο που το ρολόι είναι "πιο γρήγορο". Είτε χρειάζεσαι ένα πολύ πολύ γρηγορότερο ρολόι (δύσκολο εδώ) είτε κάνεις iterations.

[gon1332]

Επίσης καλό είναι να βάζεις 2 παραπάνω iterations και στο τέλος να διαγράφεις από τους χρόνους τον μεγαλύτερο και τον μικρότερο. Αυτοί οι χρόνοι λογικά θα ωφείλονται σε κάποιες ακραίες καταστάσεις του συστήματος. Επίσης καλό είναι ο μέσος όρος να συνοδεύεται και από τυπική απόκλιση. Αν έχουμε μεγάλη τυπική απόκλιση τότε ο μέσος όρος δεν είναι και τόσο αντιπροσωπευτικός.

[Kercyn]

Μάλιστα. Ευχαριστώ πολύ

[defacer]

Όντως είναι βασική βελτίωση να παίρνεις όπως λες το median των 3 ή και των 13 αν έχεις χρόνο.

 

Στην προκειμένη το benchmark είναι CPU bound και το σύστημα γενικά δεν ζορίζεται (single-threaded είμαστε) οπότε δεν περιμένεις αξιομνημόνευτη τυπική απόκλιση. Αλλά και πάλι είναι βασικό στη γενική περίπτωση.

 

Update: είμαι τεμπέλης αυτή τη στιγμή. Διάβασε όμως τα links που δίνει το παλικάρι εδώ. Αυτός ξέρει πολλά. 

[geomagas]

Πλάκα κάνεις έτσι; Μετράς ένα iteration και έχεις signal to noise μικρότερο της μονάδας. Επιπλέον ακόμα και στο ένα iteration που μετράς το πιο expensive operation είναι... το warning που προκαλείς με την "κακή" κλήση της reset().

 

Μα είπα ήδη ότι το "benchmark" ήταν στοιχειώδες, δεν το είπα;

Εσύ τι κατάλαβες, ότι θα το δημοσίευα σε κανένα επιστημονικό περιοδικό;

Και βέβαια μετράω και το κόστος του warning, αφού αυτά τα δύο συγκρίναμε εξ αρχής. Από συνέπεια το κάνω, όχι από άγνοια!

Εσύ τα άλλαξες στο δικό σου, επειδή έτσι σε συμφέρει αυτή τη φορά:

 

    $b = get_my_array();
    $x = reset($;

 

Δεν είναι δίκαιο.

 

Δε θα πω πολλά για να μην πατρονάρω πάλι, αλλά ίσως πρωτού αρχίσεις να μαθαίνεις από τα αποτελέσματα των benchmarks καλό θα ήταν να μάθεις πρώτα να κάνεις benchmarks.

 

Αυτό δεν είναι πατρονάρισμα;

 

F:\www\@php>php -f test.php 10000 1000
Array size: 10000 elements
reset() x 1000:  0.70503997802734 sec
array_values() x 1000: 1.534087896347 sec


F:\www\@php>php -f test.php 100000 1000
Array size: 100000 elements
reset() x 1000:  9.3735361099243 sec
array_values() x 1000: 19.839135169983 sec


F:\www\@php>php -f test.php 1000 10000
Array size: 1000 elements
reset() x 10000:  0.54003000259399 sec
array_values() x 10000: 0.96905493736267 sec


F:\www\@php>php -f test.php 1000 100000
Array size: 1000 elements
reset() x 100000:  4.6632671356201 sec
array_values() x 100000: 9.1105208396912 sec

 

Δηλαδή, έστω με την "καλή" (που όμως δεν γουστάρεις) κλήση της reset() αυτές είναι οι διαφορές;

Γι αυτό το πράγμα μιλάμε;;;

Εγώ νόμιζα πως θα πέθαινε κανένα γατάκι...

 

Ελπίζω όντως να έμαθες κάτι σήμερα.

 

Πολλά. Όχι αυτά που νομίζεις...

[defacer]

Μα είπα ήδη ότι το "benchmark" ήταν στοιχειώδες, δεν το είπα;

Εσύ τι κατάλαβες, ότι θα το δημοσίευα σε κανένα επιστημονικό περιοδικό;

Εγώ πάλι λέω πως καλό είναι να αναλαμβάνουμε τις ευθύνες μας.

 

Και βέβαια μετράω και το κόστος του warning, αφού αυτά τα δύο συγκρίναμε εξ αρχής. Από συνέπεια το κάνω, όχι από άγνοια!

Εσύ τα άλλαξες στο δικό σου, επειδή έτσι σε συμφέρει αυτή τη φορά:

Στην καλύτερη για σένα περίπτωση το κάνεις λόγω παρανόησης.

 

Φυσικά και δεν συγκρίναμε αυτά τα 2, το έχω πει 17 φορές από την αρχή του thread ότι δεν πρέπει να δημιουργείς warning. Επιπλέον πιάστηκες από τα O(1) που είπα και υποτίθεται ότι μέτρησες reset vs array_values, όχι reset + warning vs array_values.

 

Αυτό δεν είναι πατρονάρισμα;

 

Σωστά.

 

Δηλαδή, έστω με την "καλή" (που όμως δεν γουστάρεις) κλήση της reset() αυτές είναι οι διαφορές;

Γι αυτό το πράγμα μιλάμε;;;

Εγώ νόμιζα πως θα πέθαινε κανένα γατάκι...

 

Αν το "δεν γουστάρω" δεν ήταν τυπογραφικό, θα πρέπει μάλλον να ξαναδιαβάσεις τι έγραφα νωρίτερα. Μήπως να δώσω links?

 

Αν θέλεις να δεις γατάκι να πεθαίνει, θα πρέπει να βγάλεις από τη μέση και το ένα copy του πίνακα που προκαλεί η reset() (ναι, προκαλεί κι αυτή copy όλου του πίνακα -- τα σπάει η PHP λέμε) αφαιρώντας το function call και κάνοντας κατευθείαν reset και array_values πάνω στον πίνακα:

F:\www\@php>php -f test.php 10000 1000
Array size: 10000 elements
reset() x 1000: 0.0010011196136475 sec
array_values() x 1000: 0.63303589820862 sec

Αρχικά το είχα βάλει κι αυτό στο post μου αλλά το αφαίρεσα με edit ακριβώς επειδή ήταν άδικο για σένα: ναι μεν η διαφορά είναι χαοτική αλλά επειδή η κουβέντα είχε ξεκινήσει από τη γκρίνια ότι πρέπει να αποφύγεις το warning και επειδή το warning δε χρειάζεται να το αποφύγεις εκτός κι αν έχεις function call, κράτησα το function call το οποίο ευθύνεται για παραπάνω από 99% του running time της reset() version αλλά μόνο για το ~50% του running time της array_values.