Hallo Manfred, hallo Leute, Am Montag, 22. August 2005 06:32 schrieb Manfred Rebentisch:
Am Sonntag, 21. August 2005 22:58 schrieb Joerg Rossdeutscher:
Am Freitag, den 19.08.2005, 06:06 +0200 schrieb Manfred Rebentisch:
1) PHP-basierend 2) C/Apache-Modul
Ich verstehe, ehrlich gesagt, nicht, wieso man das nicht in PHP machen sollte?
Mit PHP hat der Kunde eine allgemein gängige Lösung, mit der er beliebige Dienstleister betreuen kann, er ist frei in der Wahl des OS und des Webservers, und er hat hinter sich eine große Community, die an den Sachen weiterentwickelt. Wenn er sein System erweitert, hat er das ganze Spektrum von PHP zur Verfügung, also Anbindung von Datenbanken, Imaging-Software, etc, pp.
Ja, vielen Dank. Genau das haben wohl auch andere dem Kunden gesagt. Ist nachvollziehbar.
" große Community, die an den Sachen weiterentwickelt" Was nützt dem Kunden das, wenn an PHP weiter entwickelt wird? Seine PHP-Anwendung wird dadurch vielleicht garnicht besser, sondern muß angepaßt werden, weil Inkompatibilitäten entstanden sind.
Niemand sagt, dass man auf eine neuere PHP-Version umsteigen _muss_. Und auch C kann bei einem neuen Compiler Probleme machen.
" frei in der Wahl des OS" Meine C-Lösung ist an den Apache gebunden, mit etwa 0,05% des Source-Codes. Der Apache-Server läuft nicht nur unter Linux, sondern auch auf Windows-Server und vielen Unix'en. Meine C-Lösung läuft mit Apache mit. Und wenn wer Lust hat, wird eine Schnittstelle für einen anderen Webserver implementiert.
Das ist nur ein "me too" - aber kein Argument _gegen_ PHP ;-)
"mit der er beliebige Dienstleister betreuen kann" Bei der C-Lösung kann er zwar keine PHP-Dienstleister beauftragen, aber dann nimmt er eben C-Dienstleister.
Auch hier bestenfalls "me too" ;-)
vom Entwickler (Ja, GPL, aber da muss sich ja auch wieder jemand einarbeiten, und welcher Online-Dienstleister hat schon einen C-Programmierer in der Firma), ...
Ich meine, daß die Abhängigkeit von einem C-Programmierer oder einem PHP-Programmierer sich nichts nimmt: der Kunde kann es nicht selbst und einen Fachmensch muß er ohnehin anheuern (wenn der ursprüngliche Auftragnehmer perdu ist). Im übrigen haben sich selbst unsere Praktikanten innerhalb von ein bis zwei Tagen in die C-API eingearbeitet.
Da musst Du gute Praktikanten erwischt haben ;-) (oder Du redest nur vom "Hallo Welt"-Programm...) Ich habe vor einiger Zeit mal einen (zugegebenermaßen kurzen) Blick auf C geworfen und bin "leicht" verwirrt zurückgeschreckt. Dass man sowas in 2 Tagen lernen kann, bezweifle ich aus meiner Sicht ;-)
Übrigens haben die meisten (größeren) Firmen mit IT-Personal mindestens einen C-Programmierer im Haus. Gerade weil C-Programmierkenntnisse weltweit so stark verbreitet sind und bleiben werden, habe ich 'C' gewählt. PHP ist in C programmiert, Apache ist in C programmiert, Linux ist in C programmiert.
... und sehr viele Webanwendungen sind in PHP programmiert - jede größere Firma mit IT-Personal hat also vermutlich auch mindestens einen PHP-Programmierer. Ich würde den Spieß sogar umdrehen: bis zu einem gewissen Maß dürften viele Nebenbei-Webmaster PHP-Kenntnisse haben. Ob sie auch C-Kenntnisse haben, bezweifle ich aber ;-)
Also warum C? Hättest du jetzt Perl gesagt... aber C?
Meinst Du, weil die Abhängigkeit von einem Perl-Programmierer für den Kunden erträglicher wäre?
*LoL* BTW: ich habe in letzter Zeit einige Perl-CGIs wegen der IMHO leichteren Wartbarkeit nach PHP portiert. Ein weiterer Grund, diesmal ohne IMHO, ist die leichtere Integration in Typo3. CGIs lassen sich nur per <iframe> einbinden und dass sieht nicht sonderlich gut aus ;-)
Vielleicht bist Du Perl-Fachmann und ich will nicht überheblich sein, aber C-Programmierung ist einfacher zu lernen als Perl, es gibt
Vielleicht bin ich durch meine Erfahrungen mit PHP, Perl und (ganz früher, *duck*) Basic vorbelastet - jedenfalls finde ich PHP und Perl deutlich leichter zu lesen und zu lernen als C.
wesentlich mehr C-Programmierer und wenn ich mir existierende Perl-Anwendungen (die gut sein mögen) ansehe, stehen mir einfach die Haare zu Berge.
Wieso?
Und: ich wette, auch der Perl-Interpreter ist in C programmiert.
Wenn alle in C programmieren wollen und damit glücklich sind - wofür hat dann überhaupt jemand den Perl-Interpreter geschrieben? ;-)
Nicht zuletzt ist mein Argument für den Kunden, daß er ein unschlagbar schnelles System bekommt, mit dem er seinen Mitbewerbern einige Nasenlängen voraus ist.
Das ist wohl das einzige Argument, dass wirklich für C spricht. Ob es relevant ist, hängt aber von der Anwendung ab. Ein <?php echo "Hallo Welt"; ?> oder ein paar Datenbankabfragen dürften wohl in C auch nicht performanter zu programmmieren sein. Bei rechenintensiven Anwendungen kann die Sache anders aussehen. Allerdings relativiert sich dieses Argument mit den heutigen Prozessorleistungen wieder. BTW: Auch PHP kann man beschleunigen, z. B. mit eAccelerator (bisher ungetestet, steht auf meiner irgendwann-ToDo-Liste ;-)
Die Sicherheit gegen Hackerangriffe kann theoretisch auch mit PHP gewährleistet werden.
Nicht nur theoretisch - ich bin mir sicher, dass die von mir geschriebenen PHP-Scripte auch praktisch sicher sind.
Aber viele Systeme (wie PHP postnuke) können es eben nicht.
Du willst aufgrund einzelner Programme, die mit PHP programmiert werden, die Sicherheit von PHP allgemein anzweifeln? Ich bin mir sicher, dass gut geschriebene PHP-Anwendungen genauso sicher wie gut geschriebenes C sind. Andererseits gibt es auch weniger gut geschriebenes C, das sich dann, frei nach Ratti, in eine Programmiersprache für Buffer Overflows verwandelt. Zumindest dieses Problem stellt sich in PHP nicht. Zusammengefasst bleibt also nur die Geschwindigkeit als Argument für C (und das auch nur abhängig von der Aufgabenstellung) - der Rest ist bestenfalls "me too". Sorry, aber irgendwie kann ich Deine Vorliebe für C im Bereich von Webapplikationen nicht verstehen. Vielleicht solltest Du zu standalone-Programmen wechseln, da ist C eher gefragt ;-) Gruß Christian Boltz -- 2.-5.9.2005: Weinfest in Insheim Bei der Landjugend: Liquid, AH-Band und Deafen Goblins Mehr Infos: www.Landjugend-Insheim.de