nicht angemeldet
Hallo Stefan,
Ich glaube, dass viele noch Perl mit CGI und Ausfuehrbare Programme gleichsetzen, da sie wenn ueberhaupt eben immer die Perl-Scripte zu
Gesicht bekommen.
Generell haben Scripts halt immer den Vorteil, plattformunabhaengig zu sein und auch fuer Leute bearbeitbar zu sein, die keinen Compiler haben. Und da die Rechner immer schneller werden, wiegt auch das Argument, dass compilierte Prozeduren schneller sind als interpretierte, allmaehlich immer weniger. Sicherlich waere es Unsinn, eine CAD-Anwendung in Perl zu schreiben. Aber was die meisten CGI-Progs tun, ist eigentlich gar nicht aufwendig. CGI-Prozesse haben ja meist nur eine kurze Lebensdauer, sie lesen was, wurschteln ein wenig herum und geben dann irgendwas an den Browser aus.
Daher ist es sinniger, man entwickelt lieber in einer typischen Windows-Sprache, was in der Tat mit allen geht, wenn man eben die CGI-Schnittstelle anzusprechen
weiss.
Die Frage ist allerdings mittlerweile, welches eigentlich die typische Windows-Sprache ist. Microsoft scheint ja auch allmaehlich auf den Trichter zu kommen, dass man nicht fuer alles gleich ein Kompilat braucht, und dass aber andererseits die alte DOS-Batch-Sprache ausgedient hat weil zu schwach. Da kommen dann nun Dinge wie der neue Windows Scripting Host ins Gerede. JScript ist schon recht ausgereift, ECMA-Script soll Standard werden unter Windows. Aber ich koennte mir auch vorstellen, dass Perl sich in der Windows-Welt weiter breit macht, nachdem fast jeder, der irgendwann mal mit Internet-Programmierung Bekanntschaft gemacht hat, auch den Perl-Interpreter kennenlernte.
Wenn man zudem noch die TCP/IP-Schnittstelle programmtechnisch bedienen kann, wird's richtig spassig. Schon fast eine ungute Mischung, denn dann kann eben das ueber CGI-aufgerufene Programm, auch Programme anderer Rechner nutzen (siehe: Meta-Suchmaschinen) usw.
Oh, Stefan, ich sehe schon, ich darf in Hamburg auf einen "Hacker-Workshop" hoffen <g>.
Viele Gruesse
Stefan Muenz