Freie Programmiersprache für FastCGI als PHP Ersatz unter Linux. Tipps?

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.

... 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...

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.