[php] eindeutiges Zufallsbild

[Sebastian Mendel]

Norbert Pfeiffer schrieb:
> Hi Lutz,
> 
>> ... SPL (http://www.php.net/manual/de/ref.spl.php) ...
> ja,
> und auch sofort das KO-Kriterium entdekt:
> <copy>
>     Installation
>     This extension is available and compiled by default in PHP 5.
> </copy>
> Das ist hinreichend um sich zumindestens vorlaeufig nicht damit
> zu beschaeftigen. Falls meine Kunden irgendwann alle nach PHP4
> und von dort nach PHP5 wechseln moechten oder muessen, weil die
> Provider den alten Kram loeschen, werde ich natuerlich zum
> 'gluehenden' Anhaenger vorgefertigter Teilloesungen, falls
> sie nachweislich schneller sein sollten ...

Entwickelst du etwa neue Sachen auch in php 3 nur weil die bisherigen
Scripte auf dieser Webpräsenz noch für php 3 entwickelt wurden?

Verwenden deine Kunden Provider die nur eine php-Version nutzen können?

Und was ist mit Refactoring?

Wenn ein Auto-Händler es nicht schafft seinem Kunden zu erklären das ein
neuer LKW zwar Geld kostet aber dafür nur noch halb so oft in die
Werkstatt muss und auch Bergauf 84 statt nur 40 km/h schafft dann ist er
kein guter Händler und nicht nur für sein eigenes Geschäft sondern
langfristig gesehen auch für den Kunden schlecht.


> Wobei der Nachweis durch einen oeffentlichen Test bei einem
> oeffentlichen Provider erfolgen sollte. Auf nicht-oeffentlichen
> Servern kann man auch Wasser nach oben fliessen lassen.
> 
> 
>> Hast Du zufällig mal eine Messung gemacht ...
> hmm,
> haette ich ja liebend gerne, nur wie misst man die Zeit vom
> Start des Interpreters bis zur Abarbeitung des Scriptcodes.
> In alten PHP-Versionen wurde nicht 'en Block' interpretiert,
> da gab es noch Tricks und Kniffe.
> Aber in den neueren Versionen werden solche Dinge IMHO nicht
> mehr funktionieren.
> 
> 
> PS:
> Solange sich an den Prozessoren nichts wesentliches aendert,
> muss der Code immer in den gleichen Maschienencode compiliert
> oder interpretiert werden, wie sie unsere Vorfahren aus
> fruehen Assemblerzeiten noch kannten.
> Okay, frueher war ein Wort 4Bit breit und jetzt 64Bit, aber
> deswegen bleibt es ein Geradeausprogramm mit Sprungmarken.
> 
> D.h. jedoch, dass jeder Layer, der ueber dem Code liegt,
> zurueckgefuehrt werden muss. Und genau das kostet die Zeit.
> - Bei kompilierten Anwendungen ist das uninteressant, es
>   passiert ja waehrend der Entwicklungsphase.
> - Bei interpretierten Anwendungen tritt der Zeitaufwand
>   bei jedem Scriptstart auf (und deswegen gackert er hier).
> - Bei echtem fast-cgi wird beim Serverstart interpretiert,
>   so dass man seinem OOP-Affen ungestraft Zucker geben kann.
> - Nur hat kein Provider einen fast-cgi-Server im Einsatz,
>   macht bei einem Massenhoster auch kaum Sinn ...


die Iterator-Klassen liegen im 'Bytecode' vor.

<cite "Norbert">
"This extension is available and compiled ..."
</cite>


> OOP hat natuerlich viele Vorteile, der Projektleiter kann
> nun strohdumm und aus Manager-Resourcen besetzt werden.
> Auch die Anforderungen an den Coder sind deutlich niedriger,
> zaehlen muss er hoechstens noch bis 3 oder FF.
> Das schafft Platz fuer billigere Leute mit Pisa-Niveau.
> Eine grosse Chance fuer eingeborene Schulabgaenger ...

Wieso ist dann gerade php (ohne OOP) für Anfänger so einfach?
PHP hat seinen gesamten Erfolg doch gerade der Einfachheit zu verdanken,
und mit dieser Einfachheit war auch das nicht benötigen von OOP gemeint.

OOP macht es nur für erfahrene Programmierer einfacher. Und da auch
nicht das Entwickeln sondern viel mehr das Pflegen/Warten,
Weiterentwickeln, Strukturieren und Dokumentieren.


-- 
Sebastian Mendel

www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet