Php vs others!

[παπι]

https://ideone.com/FJbdzs

[geomagas]

https://ideone.com/FJbdzs

 

Έχει διορθωθεί σε νεότερη έκδοση να υποθέσω;

Σε 5.3.28 (στη δική μου "γαλέρα"...) παίρνω

PHP Parse error:  syntax error, unexpected '[', expecting ',' or ';' in - on line 7

[defacer]

@geomagas:

 

Θα απαντήσω συγκεκριμένα αργότερα. Προς το παρόν 2 πράγματα:

 

1. Δεν λέω "μακριά από την PHP", το έχω πει παραπάνω από μια φορά σ' αυτό το thread ότι είναι πολύ καλό εργαλείο επίλυσης προβλημάτων και συγκεκριμένα ότι τη χρησιμοποιώ συνέχεια επαγγελματικά ακριβώς για να μη βγαίνει αυτό το συμπέρασμα. Απορώ γιατί με βάζεις σ' αυτή την κατηγορία.

 

2. Don't get me wrong αλλά θα το πω πολύ συνοπτικά: δε βλέπεις το πρόβλημα με την PHP γιατί δεν ξέρεις αρκετή PHP. Αυτό με το reset(get_my_array()) ναι μεν δουλεύει αλλά κάνει emit ένα E_STRICT warning. Δύο πράγματα μπορεί να συμβαίνουν εδώ: είτε τρέχεις κώδικα χωρίς όλα τα warnings ενεργοποιημένα και ορατά οπότε δεν το βλέπεις, είτε το βλέπεις αλλά δεν το θεωρείς πρόβλημα. Και στις δύο περιπτώσεις νομίζω ότι δεν έχει νόημα να συνεχίσουμε αυτή την κουβέντα γιατί δε βλέπουμε τα πράγματα από την ίδια κατεύθυνση.

Από την άποψη ότι με τον τρόπο που είναι δομημένος είναι σχεδόν αδύνατο να προσθέσουν ή να υλοποιήσουν κάποια πράγματα εντελώς σωστά (λόγω της παραγωγής κώδικα σε ένα πέρασμα) στην γλώσσα;

 

Εννοείται πως γενικολογούμε τώρα αλλά μέσες άκρες ναι, ακριβώς έτσι. Υπάρχουν περιπτώσεις όπου κατά την προετοιμασία ενός RFC κάποιος έκατσε να γράψει proof of concept patch και τα παράτησε επειδή λόγω των ιδιαιτεροτήτων του compiler απλά δεν ήταν ρεαλιστικό να γίνει.

 

Υπάρχει ακόμα και RFC που λέει ότι πρέπει να αλλάξει ο compiler για να πάμε μπροστά, αλλά ρεαλιστικά (ξέροντας 5-10 πράγματα για πολλούς από τους βασικούς contributors στην PHP) δεν πρόκειται να γίνει ως έχουν τα πράγματα σήμερα.

 

Το ένα πέρασμα αυτό καθαυτό δεν είναι η αιτία για όλα τα στραβά του compiler, αλλά φαντάζεσαι πώς πάνε αυτά: επειδή δεν παίζει να ξαναγράψουμε τώρα τον compiler θα υλοποιήσουμε αυτό το feature έτσι κι έτσι, και μετά ξανά το ίδιο και ξανά το ίδιο και έχεις φτάσει σήμερα ο compiler πρώτον να είναι ένα πέρασμα (δυσχεραίνοντας τις αλλαγές λόγω υπερβολικού coupling) και δεύτερον να έχει μαζέψει σε κάποια σημεία patch πάνω στο patch σε βαθμό που για να μπεις πλέον να πειράξεις κάτι εκει μέσα πρέπει να είναι πολύ σημαντικό. Τόσο σημαντικό που στην πράξη απλά δεν μπαίνεις.

 

ΥΓ: Έκανα λίγο random clicking στα RFC και είδα αυτό που δεν το είχα ξαναδεί. Δείτε το introduction code section και πείτε μου μετά ότι μιλάμε για κάτι που λέγεται σοβαρή γλώσσα προγραμματισμού.

[παπι]

"12d9" + 1 = 13

 

Viva la weak type

https://ideone.com/eywgyQ

κλαιω.

[geomagas]

1. Δεν λέω "μακριά από την PHP", το έχω πει παραπάνω από μια φορά σ' αυτό το thread ότι είναι πολύ καλό εργαλείο επίλυσης προβλημάτων και συγκεκριμένα ότι τη χρησιμοποιώ συνέχεια επαγγελματικά ακριβώς για να μη βγαίνει αυτό το συμπέρασμα. Απορώ γιατί με βάζεις σ' αυτή την κατηγορία.

Ναι δεν το είπες εσύ, αυτό το είπε ο ZAKKWYLDE του οποίου απάντησα.

Εσύ λες ότι είναι για πέταμα.

 

2. Don't get me wrong αλλά θα το πω πολύ συνοπτικά: δε βλέπεις το πρόβλημα με την PHP γιατί δεν ξέρεις αρκετή PHP. Αυτό με το reset(get_my_array()) ναι μεν δουλεύει αλλά κάνει emit ένα E_STRICT warning. Δύο πράγματα μπορεί να συμβαίνουν εδώ: είτε τρέχεις κώδικα χωρίς όλα τα warnings ενεργοποιημένα και ορατά οπότε δεν το βλέπεις, είτε το βλέπεις αλλά δεν το θεωρείς πρόβλημα. Και στις δύο περιπτώσεις νομίζω ότι δεν έχει νόημα να συνεχίσουμε αυτή την κουβέντα γιατί δε βλέπουμε τα πράγματα από την ίδια κατεύθυνση.

Ωραία, από το "ένα άλλο κλασικό πρόβλημα της PHP (references σε temporaries) σε εμποδίζει από το να πάρεις το πρώτο στοιχείο ενός πίνακα χωρίς να ξέρεις το key που αντιστοιχεί σ' αυτό σαν μέρος ενός expression" περάσαμε στο "κάνει emit ένα ψωρο-E_STRICT"... Είμαστε σε καλό δρόμο.

 

Πόσους έχεις δει να ασχολούνται σοβαρά στη ζωή τους με τα E_STRICT;

Ελικρινά, πόσες φορές έχεις δει σε listings αυτό:

error_reporting(E_ALL & ~(E_STRICT|E_NOTICE));

Τυχαίο;

 

...Μήπως υπερβάλλεις τελικά;

...Αλλά πάλι, δεν ξέρω "αρκετή php", οπότε μπορεί να κάνω και λάθος...

[Kercyn]

"12d9" + 1 = 13

 

Viva la weak type

https://ideone.com/eywgyQ

κλαιω.

 

Δεν καταλαβαίνω πού κολλάς. Και τα 12 ζάρια έφεραν 1.

[sonyxp]

U say WHAT?? --Bitch please... Μάθε μπαλίτσα αγόρι μου. Σε rails είναι το τουίτα http://en.m.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

 

Δεν μου αρέσει η μπάλα... (προτιμώ το volley).

 

Δεν είπα ότι το Twitter είναι γραμμένο σε asp , απλά είπα για την φήμη/χρήση τους... δηλαδή η php χρησιμοποιείται περισσότερο.

Το aspx είναι file extension. Asp.Net εννοείς.

 

ναι!

[ZAKKWYLDE]

Ναι δεν το είπες εσύ, αυτό το είπε ο ZAKKWYLDE του οποίου απάντησα.

Εσύ λες ότι είναι για πέταμα.

 

Καλά εγώ πλακίτσα έκανα...προφανώς και δεν απορρίπτεις μια γλώσσα επειδή δεν σου αρέσουν τα $ ή τα { } η δεν ξέρω γω τι άλλο.

[gon1332]

Εννοείται πως γενικολογούμε τώρα αλλά μέσες άκρες ναι, ακριβώς έτσι. Υπάρχουν περιπτώσεις όπου κατά την προετοιμασία ενός RFC κάποιος έκατσε να γράψει proof of concept patch και τα παράτησε επειδή λόγω των ιδιαιτεροτήτων του compiler απλά δεν ήταν ρεαλιστικό να γίνει.

 

Υπάρχει ακόμα και RFC που λέει ότι πρέπει να αλλάξει ο compiler για να πάμε μπροστά, αλλά ρεαλιστικά (ξέροντας 5-10 πράγματα για πολλούς από τους βασικούς contributors στην PHP) δεν πρόκειται να γίνει ως έχουν τα πράγματα σήμερα.

 

Το ένα πέρασμα αυτό καθαυτό δεν είναι η αιτία για όλα τα στραβά του compiler, αλλά φαντάζεσαι πώς πάνε αυτά: επειδή δεν παίζει να ξαναγράψουμε τώρα τον compiler θα υλοποιήσουμε αυτό το feature έτσι κι έτσι, και μετά ξανά το ίδιο και ξανά το ίδιο και έχεις φτάσει σήμερα ο compiler πρώτον να είναι ένα πέρασμα (δυσχεραίνοντας τις αλλαγές λόγω υπερβολικού coupling) και δεύτερον να έχει μαζέψει σε κάποια σημεία patch πάνω στο patch σε βαθμό που για να μπεις πλέον να πειράξεις κάτι εκει μέσα πρέπει να είναι πολύ σημαντικό. Τόσο σημαντικό που στην πράξη απλά δεν μπαίνεις.

 

ΥΓ: Έκανα λίγο random clicking στα RFC και είδα αυτό που δεν το είχα ξαναδεί. Δείτε το introduction code section και πείτε μου μετά ότι μιλάμε για κάτι που λέγεται σοβαρή γλώσσα προγραμματισμού.

 

Ω καλά ξεμπερδέμματα. Κανείς δεν πρόκειται να ασχοληθεί να το διορθώσει αυτό το πράγμα. Πιστεύω όμως ότι όλο και κάποιος θα ξεκινήσει κάποιο project με LLVM. Έχει αρχίσει και γίνεται της μόδας τώρα τελευταία. Αν δεν κάτσει κανείς να γράψει ένα σοβαρό frontend, τότε πολύ δύσκολο είναι να την αγγίξει τη γλώσσα κάποιος ή να γίνει σωστή δουλειά. Υπάρχει και μία δυσκολία στις βελτιστοποιήσεις κώδικα κοντά στη μηχανή. Ένα δενδράκι για ενδιάμεση αναπαράσταση είναι ότι πρέπει, βασικά SSA. Θα κέρδιζε πολύ από άποψη βελτιστοποιήσεων αν είχε κάποια ενδιάμεση αναπαράσταση. Άρχισε να χρησιμοποιεί και ο gcc από την 4.0 έκδοση και πήρε τα πάνω του.

[defacer]

Πόσους έχεις δει να ασχολούνται σοβαρά στη ζωή τους με τα E_STRICT;

Ελικρινά, πόσες φορές έχεις δει σε listings αυτό:

error_reporting(E_ALL & ~(E_STRICT|E_NOTICE));

Τυχαίο;

 

...Μήπως υπερβάλλεις τελικά;

...Αλλά πάλι, δεν ξέρω "αρκετή php", οπότε μπορεί να κάνω και λάθος...

 

Όπως είπα νωρίτερα, είμαστε στην περίπτωση που δεν πιστεύεις πως το E_STRICT είναι πρόβλημα.

 

Προσωπικά έχω δει όλους τους developers τους οποίους έχω σε υπόληψη να ασχολούνται σοβαρά με τα E_STRICT. YMMV.

 

FYI και με απόλυτη ειλικρίνεια, κώδικας ο οποίος παράγει οποιουδήποτε είδους notice για μένα μπαίνει στην κατηγορία "χρειάζεται οπωσδήποτε φτιάξιμο" και προγραμματιστές οι οποίοι τα κλείνουν πρέπει να μάθουν να μην το κάνουν (και να φτιάξουν τον κώδικά τους αντί γι' αυτό) διαφορετικά δεν μπορούμε να δουλέψουμε μαζί.

 

Όταν έλεγα "ναι μεν δουλεύει αλλά" δεν έκανα κωλοτούμπα, απλώς για μένα φρεσκογραμμένος κώδικας που δουλεύει αλλά δίνει warning είναι το ίδιο με κώδικα που δεν δουλεύει: θέλει οπωσδήποτε φτιάξιμο.

 

Αν θές μια τρίτη γνώμη μπορείς εύκολα να κάνεις google, θα δεις ότι "όλοι" λένε να έχεις τα warnings στο φουλ (παράδειγμα), και προφανώς δεν είναι πρακτικό να τα έχεις στο φουλ εκτός κι αν κατά την "κανονική" λειτουργία δεν παράγεται κανένα απολύτως. Αυτό που λες στο "πόσες φορές το έχεις δει" (όχι πολλές) απλά σε βάζει στο δρόμο του να γράψεις κακό κώδικα τον οποίο μετά θα δυσκολευτείς να κάνεις debug.

 

Επίσης κάνε τον παραλληλισμό με την ενεργοποίηση όλων των warnings και του treat warnings as errors σε κώδικα C ή C++.

Ω καλά ξεμπερδέμματα. Κανείς δεν πρόκειται να ασχοληθεί να το διορθώσει αυτό το πράγμα. Πιστεύω όμως ότι όλο και κάποιος θα ξεκινήσει κάποιο project με LLVM. Έχει αρχίσει και γίνεται της μόδας τώρα τελευταία. Αν δεν κάτσει κανείς να γράψει ένα σοβαρό frontend, τότε πολύ δύσκολο είναι να την αγγίξει τη γλώσσα κάποιος ή να γίνει σωστή δουλειά. Υπάρχει και μία δυσκολία στις βελτιστοποιήσεις κώδικα κοντά στη μηχανή. Ένα δενδράκι για ενδιάμεση αναπαράσταση είναι ότι πρέπει, βασικά SSA. Θα κέρδιζε πολύ από άποψη βελτιστοποιήσεων αν είχε κάποια ενδιάμεση αναπαράσταση. Άρχισε να χρησιμοποιεί και ο gcc από την 4.0 έκδοση και πήρε τα πάνω του.

 

Καλές οι βελτιστοποιήσεις, αν και out of the box αν δε βάλεις κάποιο opcode cache τότε η έλλειψη application server κάνει την PHP εντελώς ακατάλληλη για οποιαδήποτε εφαρμογή έχει ρεαλιστικό φόρτο εργασίας, και αν πάλι βάλεις opcode cache τότε η διαφορά θα είναι χαοτική σε σχέση με το τι θα μπορούσε να γίνει με βελτιστοποιήσεις.

 

Το δεντράκι θα επέτρεπε και άλλα καλούδια όπως το φανταστικό compiler support για expression trees/lambdas της C# -- έχω ένα project όπου παίζω μ' αυτές τις ιδέες αλλά επειδή δεν υπάρχει καλύτερη επιλογή εκεί κάνω parse το PHP source με τον parser του nikic που είναι γραμμένος επίσης σε PHP, οπότε το performance είναι άθλιο πέρα από κάθε περιγραφή.

 

Αλλά δε νομίζω ότι θα γίνει αυτό εκτός κι αν υπάρξουν κοσμοϊστορικές αλλαγές στα php internals επειδή

1. Θα ήταν τρομερός όγκος εργασίας, θα έπρεπε να κινείται παράλληλα με το development του παλιού compiler και δε θα υπήρχε κανένα χειροπιαστό αποτέλεσμα μέχρι να τελειώσει η δουλειά. Αυτός ο συνδυασμός που σκοτώνει ήταν και ένας βασικός λόγος που ναυάγησε εντυπωσιακά η προσπάθεια να γίνει η PHP encoding-aware.
2. Δεν υπάρχει κοινό όραμα για το τι θα πρέπει να γίνει με την PHP επομένως δεν υπάρχει και αρκετή υποστήριξη για να τρέξουν επιτυχώς τέτοιες μεγαλεπήβολες πρωτοβουλίες. Κάθε τόσο κάποιος/κάποιοι νέοι devs με πολλή όρεξη και καλή διάθεση μπαίνουν μέσα για ν' αλλάξουν τον κόσμο, τρώνε την παπάρα από το άθλιο "περιβάλλον" της internals και απλά εγκαταλείπουν. Ο nikic θα είναι λογικά το επόμενο θύμα.

Γενικά η σκατοκατάσταση με την "οικουμενική κυβέρνηση" στην PHP και η σκατοσυμπεριφορά αρκετού κόσμου στα internals είναι το μεγαλύτερο πρόβλημα της γλώσσας.

 

Αν σ' ενδιαφέρει για μια ιδέα μπορείς να διαβάσεις αυτό το blog post (μη το καταπιείς αμάσητο, δεν είναι η μία και μοναδική αλήθεια) και ιδιαίτερα τα comments (συμμετέχουν αρκετοί internals) ή επίσης και αυτό.

 

Κάποιες μέρες απορώ πώς γίνεται η PHP να υπάρχει ακόμα.

"12d9" + 1 = 13

 

Viva la weak type

 

 

Και η JS έχει weak typing αλλά δεν κάνει έτσι.

 

Χωρίς να ξέρω, έχω την αίσθηση ότι αυτό το epic fail έχει να κάνει με την ιστορική επιλογή του Rasmus το + να είναι πάντα αριθμητική πρόσθεση, το οποίο με τη σειρά του πιθανολογώ πως έχει άμεση σχέση με το ότι οι μεταβλητές από το request έρχονται πάντα σε string type, δηλαδή is_string($_GET['whatever']) === true.

 

Επειδή μιλάμε για εποχές που η PHP έκανε πράγματα που τα βλέπεις και θέλεις να βγάλεις τα μάτια σου (magic quotes, register_globals, κλπ) είναι φανερό πως αν είχες ένα $var = "42" από το request και έγραφες $var + 1 "δε θα ήταν πρέπον" να πάρεις πίσω "421" όπως στη JS (μιλάμε τώρα ότι το κοινό ήταν άνθρωποι που δεν κατανοούσαν το τι είναι type σε μια γλώσσα προγραμματισμού). Και για να πάρεις το επιθυμητό int 43 τα πράγματα έγιναν όπως έγιναν και τα λουζόμαστε μέχρι σήμερα.

[sonyxp]

Μια ερώτηση! η Ruby n Rails (πως στο καλό λέγεται αυτή η κολοκύθα), τι ρόλο βαράει ακριβώς; χρεισιμοποείται;; 

 

Είναι για scripts μόνο (js like) ή μπορείς να στήσεις ολόκληρη σελίδα...

[Kercyn]

Η RoR είναι ένα framework γραμμένο σε Ruby κι απ' ό,τι ξέρω χρησιμοποιείται πολύ.

[geomagas]

Όπως είπα νωρίτερα, είμαστε στην περίπτωση που δεν πιστεύεις πως το E_STRICT είναι πρόβλημα.

Όχι, είμαστε στην περίπτωση που δεν μπορώ να φανταστώ που θα χρειαζόταν να κάνω τέτοιες ακροβασίες. Και αν τις έκανα, το να πάρω πίσω ένα E_STRICT θα ήταν fair enough, και αξιοπρεπής προειδοποίηση από την πλευρά της γλώσσας ("Ρε σύ, καλά, να στο εκτελέσω, οκ, αν επιμένεις, αλλα... εχμ.... μήπως κάνεις μ@λ@κί@???")

 

FYI και με απόλυτη ειλικρίνεια, κώδικας ο οποίος παράγει οποιουδήποτε είδους notice για μένα μπαίνει στην κατηγορία "χρειάζεται οπωσδήποτε φτιάξιμο" και προγραμματιστές οι οποίοι τα κλείνουν πρέπει να μάθουν να μην το κάνουν (και να φτιάξουν τον κώδικά τους αντί γι' αυτό) διαφορετικά δεν μπορούμε να δουλέψουμε μαζί.

Δηλαδή δεν πρόκειται να δουλέψουμε μαζί;;; Ε δεν πειράζει, θα πιω και θα ξεχάσω... :-D

Πάντως, δεν αντέχω να μην το πω, το αμέσως επόμενο βήμα είναι να γράφεις κώδικα με ένα προφυλακτικό σε κάθε δάχτυλο. Δεν συμφέρει...

 

Όταν έλεγα "ναι μεν δουλεύει αλλά" δεν έκανα κωλοτούμπα, απλώς για μένα φρεσκογραμμένος κώδικας που δουλεύει αλλά δίνει warning είναι το ίδιο με κώδικα που δεν δουλεύει: θέλει οπωσδήποτε φτιάξιμο.

Να στο φτιάξω;

$a=get_my_array();
echo reset($a);

Fixed.

Bonus: Τώρα μπορείς να χρησιμοποιήσεις το $a παρακάτω, ενώ πριν το αποτέλεσμα της συνάρτησης θα χανόταν, και δεν καταλαβαίνω (ούτε η php!) γιατί θα ήθελες να κάνεις reset ένα array αμέσως πριν "χαθεί"... Δεν έχει δίκιο η κακομοίρα που σου γκρινιάζει;

Είναι θέμα λογικής.

 

Επίσης κάνε τον παραλληλισμό με την ενεργοποίηση όλων των warnings και του treat warnings as errors σε κώδικα C ή C++.

Ε όχι, αυτό είναι το λάθος που δεν πρόκειται να κάνω.

Προσπάθησα να στο πω και πριν με τους pointers.

Αν δεν καταλαβαίνεις τι θέλω να πω, πες το βράδυ της γυναίκας σου (<--php):

"Αυτό το παστίτσιο δεν είναι σαν της μάνας μου! (<--C)"

Θα σου εξηγήσει αυτή.

 

Και η JS έχει weak typing αλλά δεν κάνει έτσι.

Πες ότι θέλεις να διασταυρώσεις έναν ελέφαντα με μία κότα.

Το ερώτημα είναι αν είναι προτιμώτερο να πάρεις ελεφαντόκοτες ή κοτοελέφαντες;

Ή γιατί χρειάστηκε να κάνεις μία τέτοια διασταύρωση εξ αρχής;

 

Μήπως διυλίζουμε τον κώνωπα;

 

Κάθε γλώσσα έχει τους κανόνες της, και όσο είναι συνεπής με αυτούς, δεν καταλαβαίνω γιατί κάποιος μπορεί να λέει ότι είναι "για πέταμα".

[sonyxp]

Παιδιά, δεν ξέρω τι λέτε με όλα αυτά τα μεγάλα Ποστ (βαριέμαι να τα διαβάσω, σορρυ και χωρίς να σας προσβάλω) αλλά πιστεύω ότι θα συμφωνήσουμε σε κάτι...

 

"Μάθε ότι ζητάει η αγορά, δεν πρέπει κάποιος να φανατίζεται και γενικά στα @ μας το τι γίνεται... το θέμα είναι τι θα μας δώσει δουλειά!"

 

 

Βασικά το λέω για να το ακούσω ο ίδιος, ακόμα έχω 'κομπλεξ' με γλώσσες και 'υποτιμώ' πράγματα και καταστάσεις

 

[Aztec]

 

 

Και η JS έχει weak typing αλλά δεν κάνει έτσι.

 

Χωρίς να ξέρω, έχω την αίσθηση ότι αυτό το epic fail έχει να κάνει με την ιστορική επιλογή του Rasmus το + να είναι πάντα αριθμητική πρόσθεση, το οποίο με τη σειρά του πιθανολογώ πως έχει άμεση σχέση με το ότι οι μεταβλητές από το request έρχονται πάντα σε string type, δηλαδή is_string($_GET['whatever']) === true.

 

Επειδή μιλάμε για εποχές που η PHP έκανε πράγματα που τα βλέπεις και θέλεις να βγάλεις τα μάτια σου (magic quotes, register_globals, κλπ) είναι φανερό πως αν είχες ένα $var = "42" από το request και έγραφες $var + 1 "δε θα ήταν πρέπον" να πάρεις πίσω "421" όπως στη JS (μιλάμε τώρα ότι το κοινό ήταν άνθρωποι που δεν κατανοούσαν το τι είναι type σε μια γλώσσα προγραμματισμού). Και για να πάρεις το επιθυμητό int 43 τα πράγματα έγιναν όπως έγιναν και τα λουζόμαστε μέχρι σήμερα.

 

Γιατί θεωρείς οτι είναι καλύτερο να έχεις εναν operator με διπλή λειτουργία(addition, concatenation) και όχι διαφορετικούς operator για αριθμητική πράξη και concatenation. Δεν είναι η μόνη γλώσσα η PHP στην οποία ισχύει αυτό.