Hi. Ich suche eine Programmiersprache zur Erstellung eines FastCGI Programms. Soll mir als PHP Ersatz dienen. Erst mal nur experimentell. -Frei Verfügbar und ohne Lizenzkosten egal für welche Anwendung -Leicht erlernbare Sprache und Syntax, am Besten PHP ähnlich. -Viele fertige Module unter freien Lizenzen verfügbar, damit man nicht das Rad jedes Mal neu erfinden muss. -Einfacher Datenbankzugriff, XML Parser, Bildverarbeitung (GD). -Strings parsen und Datatenverarbeitung gut und einfach. -Ausreichend schnell -Sollte wenn möglich, nicht allzusehr Systemabhängig sein. was würdet ihr nehmen?
Beck schrieb: > was würdet ihr nehmen? PHP, sag doch erstmal was für ein Problem du mit php hast. Es muss ja auch nicht als CGI laufen, kann ja auch als Modul im Apache laufen.
Nachtrag: das gibt es ja noch Perl.
Ich schlage mal Python vor Beck schrieb: > -Frei Verfügbar und ohne Lizenzkosten egal für welche Anwendung Sollte kein Problem darstellen, s. http://www.python.org/psf/license/ > -Leicht erlernbare Sprache und Syntax, am Besten PHP ähnlich. Trifft zu, jedoch nahezu keine PHP-Ähnlichkeiten > -Viele fertige Module unter freien Lizenzen verfügbar, damit man nicht > das Rad jedes Mal neu erfinden muss. Trifft zu > -Einfacher Datenbankzugriff, XML Parser, Bildverarbeitung (GD). s.o. > -Strings parsen und Datatenverarbeitung gut und einfach. trifft ebenfalls zu > -Ausreichend schnell sollte auch erfüllt sein > -Sollte wenn möglich, nicht allzusehr Systemabhängig sein. Ist python ebenfalls
Nunja, ich wollte ein kleines Webseitenframework schreiben, was im an einigen Stellen tief in der Systemkonfiguration rumfummelt. Kein Adminpanel wie Syscp oder sowas. Sondern halt was spezielleres. Und mit PHP so tief im System rumfummeln, da bekomm ich Bauchweh. Dann lieber CGI.
Beck schrieb: > Dann lieber CGI wo ist der unterschied? CGI ist nur eine Schnittstelle wie man mit einem Webserver daten austauschen kann. Man kann PHP als Modul oder als CGI nutzen. Gefällt dir nun PHP nicht oder die art und weise wie man mit PHP Daten im System änderst. Perl ist als Admin-Script-Sprache entwicklet wurden. Es könnte für den zweck das richige sein. Aber ich sehe noch kein Grund warum man von PHP auf Perl wechseln sollte, wenn man eine Sprache schon kann und sie alles bietet was man braucht.
Peter schrieb: > Beck schrieb: >> Dann lieber CGI > wo ist der unterschied? CGI ist nur eine Schnittstelle wie man mit einem > Webserver daten austauschen kann. Man kann PHP als Modul oder als CGI > nutzen. > > Gefällt dir nun PHP nicht oder die art und weise wie man mit PHP Daten > im System änderst. > > Perl ist als Admin-Script-Sprache entwicklet wurden. Es könnte für den > zweck das richige sein. Aber ich sehe noch kein Grund warum man von PHP > auf Perl wechseln sollte, wenn man eine Sprache schon kann und sie alles > bietet was man braucht. Nunja, ich arbeite jetzt eh schon viel mit Shellscripten, die über php aufgerufen werden. Dann kann ich auch gleich CGI machen. Außerdem will ich mal ein Experiment machen: Ein kleines Webseitenframework unabhängig von PHP. Ich will mal gucken, ob ich ne einigermaßen gute "Startseite" ohne PHP zusammen bekomme. Mysql Datenbanken auslesen, XML Dateien auslesen, Bilder, und das zeug. Und das bevorzugt als FastCGI. Bevorzugt als FastCGI Programm. Ruby habe ich auch noch gefunden. Somit wären es schon 3: Perl, Phyton, Ruby. Perl hat wohl den Ruf: Write once, Read never, also schwer lesbarer Code. Phyton soll gewöhnungsbedürftig sein, weil man z.B. mit Einrückungen arbeiten muss. Ruby: soll relativ gut zu programmieren sein, aber bei Hostern nicht so verbreitet. Bei nem eigenen Server ist das aber kein Grund. Man kann auch CGI mit C++ oder so machen, C++ ist aber etwas umständlich und unbequem zu programmieren Java: Ist in meinen Augen (noch) keine freie Programmiersprache.
Beck schrieb: > Phyton soll gewöhnungsbedürftig sein, weil man z.B. mit Einrückungen > arbeiten muss. Geht so. IMHO trägt es sehr zur Lesbarkeit bei, wenn der Code mittels Einrückungen strukturiert wird. Außerdem musst du dich nicht mit alt-gr für geschweifte Klammern verrenken.
Beck schrieb: > Perl hat wohl den Ruf: Write once, Read never, also schwer lesbarer > Code. das ist das schöne an Perl, man kann es fast machen wie man will. Wenn man sich selber an ein paar Regeln hält, dann ist es genau so lesbar wie PHP. so kann man es machen, muss aber nicht
1 | @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
|
2 | @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
|
3 | ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
|
4 | close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
|
Beck schrieb: > Dann kann ich auch gleich CGI machen cgi steht für common gateway interface. es wird also nur festgelegt wie der webserver mit der anwendung, die die daten bereit stellt, kommuniziert. ob das php, c/c++, c#, bash, java oder was auch immer ist, ist dabei egal. fastcgi ist dabei nur eine erweiterung, es spawnd nicht immer einen neuen prozess pro anfrage sondern hält selbstständig einen pool. auch dieses interface ist nicht auf eine sprache festgelegt. es ist übrigens egal ob du php oder was anderes nimmst, wenn du tief ins system eingreifen willst dann muss dein cgi prozess die entsprechenden rechte haben, da bekomme ich bauchschmerzen, egal was für eine sprache dahinter steckt. ich persönlich bin übrigens für asp.net/c#, also mono unter linux.
Ich bin für c++, und dann gleich direkt als Apache Modul.
Und ich bin für Java im Zweifel mit Tomcat ;P
... schrieb: > Ich bin für c++, und dann gleich direkt als Apache Modul. welchen ernsthaften vorteil bringt das? die nachteile sind: apache bei jeder änderung neu laden, bei grösseren änderungen an der apache schnittstelle muss das modul angepasst werden, debugging ist umständicher...
LISP. Nur in LISP kannst du wirklich schönen Code schreiben, kurz, prägnant, sicher.
Zwie Blum schrieb: >> Ich bin für c++, und dann gleich direkt als Apache Modul. > > welchen ernsthaften vorteil bringt das? Ist kein PHP, sieht aber zumindest teilweise recht ähnlich aus. Man braucht das FastCGI geraffel nicht. Viele fertige Module unter freien Lizenzen verfügbar, damit man nicht das Rad jedes Mal neu erfinden muss. Einfacher Datenbankzugriff, XML Parser, Bildverarbeitung (GD). Ausreichend schnell. Im zweifelsfall also gar keinen :) Ich dachte einfach mein Vorschlag sei so abwegig, daß ich mir die Ironie-Tags sparen könnte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.