Re: Εγκατάσταση PECL extension σε SUSE10

rouvas at di.uoa.gr rouvas at di.uoa.gr
Wed Jun 13 17:25:09 EEST 2007


Giorgos Keramidas said:
> On 2007-06-13 00:09, Θοδωρής Λύτρας <aspirin at myrealbox.com> wrote:
>>Στις Τρίτη 12 Ιούνιος 2007 20:46, ο/η Giorgos Keramidas έγραψε:
>>> <disclaimer id="php">
>>>   Σιχαίνομαι το PHP, οπότε μπορεί να λέω αηδίες λόγω έλλειψης
>>> εμπειρίας με το pear5.
>>> </disclaimer>
>>
>> Είναι βέβαια η μόνη γλώσσα που μιλάω (τώρα μαθαίνω λίγο javascript),
>> άρα δεν έχω μέτρο σύγκρισης, όμως πολύ θα ήθελα να μου εξηγήσεις γιατί
>> σιχαίνεσαι την PHP και από ποιά άποψη.
>>
>> No flamewar intended, ρωτώ από πραγματικό ενδιαφέρον!
>
> Intended ή όχι, με τον αριθμό των ανθρώπων που κυριολεκτικά `βγάζουν το
> ψωμί τους' πουλώντας, επεκτείνοντας ή γράφοντας εντελώς από την αρχή PHP
> scripts, δεν είναι εύκολο να αποφευχθεί ένα flame όταν κάποιος λέει
> πράγματα όπως αυτό που έγραψα εγώ.

Επειδη κι εγω δεν θελω να αρχισω πολεμο "ανακοινωσεων", θα πω τα κατωθι
και δεν θα ξαναμιλησω για την PHP. Την PHP την αγαπησα, κι ας μην ηταν η
πρωτη μου γλωσσα, για την απιστευτη ελευθερια και απλοτητα που σου δινει
για να φτιαξεις κατι. Η απουσια "κεντρικου σχεδιασμου" για μενα ειναι
πλεονεκτημα και οχι κατι το μεμπτο.

Παρακατω λεω τη γνωμη μου για τα σημεια που θιγονται

>
> Εμένα με ενδιαφέρει κυρίως η `linguistic' πλευρά και η σχεδιαστική
> πλευρά της γλώσσας του PHP, οπότε τα παρακάτω δεν είναι -- για κανένα
> λόγο -- προσωπική επίθεση, ούτε σε αυτούς που φτιάχνουν το PHP, ούτε σε
> όποιον χρησιμοποιεί το PHP για να φτιάξει όμορφα[2] πράγματα.
>
> Το <disclaimer> παραπάνω σημαίνει πως αυτό που έγραφα είναι δική μου,
> καθαρά προσωπική άποψη.  Αν κάποιος συμπαθεί το PHP και δεν θέλει να
> ακούει άσχημα πράγματα για το PHP, αυτό το σημείο είναι μια καλή
> ευκαιρία να σταματήσει το διάβασμα.
>
> 			   I. THREAD UNSAFETY
>
> Πολλά php modules δεν είναι thread-safe.  Το PHP Group υποστηρίζει ότι
> ``το core του PHP είναι thread-safe, αλλά ορισμένα extensions μπορεί να
> μην είναι''[1].  Σήμερα, με multicore SMP μηχανήματα, που μπορούν να
> τρέξουν με πολύ πιο αποδοτικό τρόπο multi-threaded εφαρμογές, είναι λίγο
> κρίμα.

Πραγματι αυτο ειναι κριμα, αλλα δεν ειναι προβλημα της PHP. Ειναι θεμα των
προγραμματιστων των modules να τα κανουν thread-safe. Η PHP ως γλωσσα,
αλλα και τα περισσοτερα απο τα modules της, δεν εχουν προβλημα.

>
> 			 II. UNMAINTAINABILITY
>
> Όλα τα PHP scripts που έχω δει ή έχω πειράξει ο ίδιος είναι -- στην
> καλύτερη περίπτωση -- unmaintainable σκουπίδια.  Μπορεί το οπτικό
> αποτέλεσμα του output που παράγουν να είναι «όμορφο σε Firefox», αλλά ο
> πηγαίος κώδικας του script είναι (στη συντριπτική πλειοψηφία των
> περιπτώσεων), ένας ανείπωτης πολυπλοκότητας χαμός από κακογραμμένα SQL
> queries, τα οποία είναι ενσωματωμένα σε πολύ άσχημα μορφοποιημένα PHP
> statements, τα οποία είναι με τη σειρά τους ενσωματωμένα σε ακόμα πιο
> άσχημα μορφοποιημένη HTML.

Ουτε και αυτο ειναι προβλημα της PHP. "Κωδικα κουβαρι" μπορεις να γραψεις
σε οποιαδηποτε γλωσσα. Ο προγραμματιστης πρεπει πρωτα απ'ολα να εχει
*πειθαρχια*. Αν δεν ακολουθει ο ιδιος τους κανονες (δικους του, του
framework, της γλωσσας, του περιβαλλοντος, κλπ) δεν υπαρχει περιπτωση να
προκυψει κωδικας που να ειναι "λογικος"

>
> 			    III. NAMESPACES
>
> Έχουν ενδιαφέρον οι προσπάθειες για «encapsulation» της λειτουργικότητας
> ενός PHP extension σε modules, αλλά κι αυτές έχουν πρόβλημα όταν κάποιος
> συνειδητοποιήσει ότι το PHP δεν έχει namespaces, δεν έχει static/extern
> symbol visibility για τα functions, κι ένα σωρό άλλα καλούδια που έχει
> ακόμα και η απλή ANSI C.

Αυτο ειναι ενα ζητημα, αλλα εγω το βλεπω ως ελευθερια κινησεων, παρα ως
μειονεκτημα. Βεβαια, μπορει εχει τη δυνατοτητα να δυναμιτισει την υπεροχη
βιβλιοθηκη που μολις ολοκληρωσα, αλλα σε καθε περιβαλλον με πολλους
βαθμους ελευθεριας υπαρχει αυτο.

>
> Τα προβλήματα που δημιουργούνται από το συνδυασμό unmaintainability που
> αποκαλεί συνήθως ο κόσμος «php script» και την έλλειψη
> namespaces/modularity είναι άπειρα.  Το κλασικό παράδειγμα είναι ο
> 15-χρονος web developer που ονομάζει μια δική του function read() --
> π.χ. για να διαβάσει ένα ένα χαρακτήρα bytes από ένα αρχείο σε ένα δικό
> του buffer -- και χαίρεται μέχρι να ανακαλύψει ότι δεν ήταν και τόσο
> καλή ιδέα, γιατί το τάδε external module νομίζει (για κάποιο περίεργο
> λόγο) ότι η read() είναι κάτι άλλο.

Δεν πειραζει, θα μαθει. Το προβλημα δεν ειναι η συμπτωση των ονοματων,
αλλα η υιοθετηση μιας σχεδιαστικης νοοτροπιας και πειθαρχιας που θα σου
επιτρεπει να ξεπερνας αυτα τα προβληματα. Ετσι κι αλλιως, στη αναπτυξη
συστηματων στον "πραγματικο κοσμο" θα βρεθεις πολλες φορες αντιμετωπος με
τετοια ζητηματα. Για παραδειγμα, μεχρι πριν απο λιγο δεν ηξερα την εντολη
"tac"... και το φοβερο και τρομερο υπερ-προγραμμα που εχω φτιαξει το
ονομαζω ακριβως ετσι...

>
> 			   IV. FUNCTION HELL
>
> Σαν γλώσσα, το PHP μπορεί να έχει κάποια μειονεκτήματα, αλλά αυτά δε
> φτάνουν με τίποτα σε πολυπλοκότητα τη μπαρόκ λατέρνα που λέγεται
> «standard PHP functions library».  Δεν υπάρχει κανένα standard στον
> τρόπο με τον οποίο ονομάζονται οι functions, δεν υπάρχει κανένα standard
> για error codes, return values, argument order, καμία απολύτως
> «high-level σχεδίαση» για την οργάνωση των modules σε συλλογές από
> functions που έχουν συνέπεια και προβλεψιμότητα.  Είναι πολύ δύσκολο,
> όταν ψάχνει κάποιος ένα PHP reference να βρει:
>
>     * Σε ποιό module είναι πιθανόν να βρίσκεται
>
>     * Πώς λένε τη function που ψάχνει
>
>     * Με τι σειρά ορισμάτων να την καλέσει
>
>     * Τι επιστρέφει
>
> Βασικά, δηλαδή, τα 4 πιο ουσιαστικά γνωρίσματα ενός function και οι 4
> πιο σημαντικές πληροφορίες σχετικά με ένα function είναι, για κάποιον
> που γράφει PHP, διαθέσιμες μόνο με συνεχόμενο και βαρετό, χρονοβόρο
> ψάξιμο στο reference manual :-(

Εχω την εντυπωση οτι υπερβαλλεις. Ετσι κι αλλιως, δεν χρησιμοποιηεις
συνεχεια καθε function που υπαρχει... Αυτες που χρησιμοποιες τις μαθαινεις
απεξω, για τις αλλες ουτως η αλλιως δεν θα κοιταξεις πρωτα στο manual να
δεις τι διαλο κανουν;

>
>
> 		 V. DO YOU WANT UNICODE WITH THAT, SIR?
>
> Το php5 δεν έχει *ακόμα* καλό support για Unicode[4].  Είναι πλέον
> αδιανόητο για κάποια γλώσσα να μην έχει support για κάποιας μορφής
> localized strings, εκτός κι αν αυτή η γλώσσα είναι assembly.

Διαφωνω. Εχει κανονικοτατη υποστηριξη για ολα τα character sets και για
UTF. Απλως η γλωσσα, χωρις module, υποστηριζει μονο ISO-8859-1. Για τα
υπολοιπα υπαρχει το mbstring module το οποιο το χρησιμοποιεις σαν μια
οποιαδηποτε βιβλιοθηκη.

-Σταθης

>
> 				VI. MORE
>
> Υπάρχουν άπειρα πράγματα που με «ενοχλούν» στο PHP, τα οποία δεν έχω
> χρόνο να γράψω τώρα :-)
>
> ----------
> [1]  http://www.php.net/release_4_3_0.php
>
> [2] Με τον ορισμό του «όμορφου πράγματος» που περιγράφεται ως «Η
> Ποιότητα Που Δεν Έχει Όνομα»[3], στο `Timeless Way of Building' του
> Christopher Alexander.  Θέλω να πιστεύω πώς όλοι οι προγραμματιστές που
> χρησιμοποιούν κάποια γλώσσα με μεράκι, μπορούν να κάνουν «όμορφα»
> πράγματα, ακόμα κι αν η γλώσσα δεν είναι τόσο καλή.
>
> [3] http://en.wikipedia.org/wiki/Quality_without_a_name
>
> [4] http://www.php.net/manual/en/ref.unicode.php
>
>
> --
> linux-greek-users mailing list -- http://lists.hellug.gr






More information about the Linux-greek-users mailing list