nicht angemeldet
PHP vs. Perl ->MySQL?
sethHallo Forum
Eine ganz banale Frage, wirklich sehr allgemein in die Runde geworfen, bei der folgende "Umgebungsvariabeln" bestehen:
1)Es soll eine Plattform im Internet aufgebaut werden.(Quellcodeausgabe)
2)Es soll private Bereiche geben.(persönlicher Login)
3)Es sollen Clienteingaben so abgelegt werden, daß sie über Abfragen auswertbar sind (DB & DBMS?)
4)Die Abfrage-Ergebnisse sollen auch für Berechnungen zur Verfügung stehen.
5)Es soll auch mit kalendarischen Werten gerechnet werden können. Eine Art Outlookkalender mit Terminierungsmöglichkeiten. Client wird nach dem Einloggen informiert, daß dies und jenes Ereignis bevorsteht. (Veranstaltung, Party, Geburtstag o. ä.)
Folgende Dinge wurden mir bereits zugetragen:
PHP
---
Ist für Webausgabe das einzig wahre. Einfache Ausgabe von Quellcode.
PHP kann MySQL bedienen.
Perl
----
Für kalendarische Operationen unschlagbar, da Kalendermodule verfügbar sind.
Für Webausgabe umständlicher.
Perl kann auch MySQL bedienen.
Zu My SQL:
Ist wohl die verbreiteste Datenbank der Welt. Bräuchte man für ein dynamisches Websystem zwingend ein DBMS oder könnte man das nicht viel einfacher und übersichtlicher in Bsp. eine .csv-Datei die Informationen hineinschreiben?
Allgemein zum Code gefragt:
Ist PHP oder eher Perl die "übersichtlichere" Programmiersprache.
Welches lernt sich besser/leichter?
Danke - waren jetzt doch ein Paar Fragen mehr als gedacht ;-)
Viele Grüße von HP-User
-
Hallo,
schau dich doch mal beim Zend Framework um http://framework.zend.com/
Folgende Dinge wurden mir bereits zugetragen:
PHP
Ist für Webausgabe das einzig wahre.
Ach ja? Ruby? Java? Perl? Python?
Perl
Für kalendarische Operationen unschlagbar, da Kalendermodule verfügbar sind.
Die Zeiten, dass es für dies und das keine Module gibt, sind wohl vorbei. Kalender wohl eher Javascript ...;
Zu My SQL:
Ist wohl die verbreiteste Datenbank der Welt. Bräuchte man für ein dynamisches Websystem zwingend ein DBMS oder könnte man das nicht viel einfacher und übersichtlicher in Bsp. eine .csv-Datei die Informationen hineinschreiben?Klar, oder andere textbasiertes wie SQLLite http://framework.zend.com/manual/de/zend.db.adapter.html
Allgemein zum Code gefragt:
Ist PHP oder eher Perl die "übersichtlichere" Programmiersprache.
Welches lernt sich besser/leichter?Übersichtlich wird es, wenn Du Dich an einen Coding-Standard hältst: http://framework.zend.com/manual/de/coding-standard.html
Mit PHP liegst Du in jedem Fall richtig. Es gibt auch andere als das Zend-Framework (Symfony z.B.). Perl ist jetzt nicht falsch, aber alles andere ist wohl weltanschaulicher Natur ...;
Gruß
jobo
-
Hi jobo
_Stark_ vereinfacht gesagt(man möge mich jetzt vierteilen):
Ist Zend dann quasi so wie Frontpage damals für Webseitenschreiber - nur das eben auch serverseitige Funktionen nutzbar sind?
Bei solchen WYSIWYG- Editoren (spätestens hier erfolgt die Steinigung *lol*) ist nman da nicht eingeschränkt? Oder hat das Zend auch Möglichkeiten, vom Benutzer gemachte eingaben (All Input is Evil-Input) zu filtern?
Wie stell ich mir das vor. Grafische Oberfläche, Quellcode-Screen oder ganz anders?
Ich mach mal dort die Quickstart Tour - bis später
Gruß HP-User
-
Hallo,
Hi jobo
_Stark_ vereinfacht gesagt(man möge mich jetzt vierteilen):
Ist Zend dann quasi so wie Frontpage damals für Webseitenschreiber - nur das eben auch serverseitige Funktionen nutzbar sind?
Nein garnicht.
Ich mach mal dort die Quickstart Tour - bis später
Jau, wenn das nicht ein bisschen viel ist für einen absolute Beginner ...;
Es ist ein "php-Framework" http://de.wikipedia.org/wiki/Liste_von_Webframeworks
Gruß
jobo
-
-
-
hi,
1)Es soll eine Plattform im Internet aufgebaut werden.(Quellcodeausgabe)
2)Es soll private Bereiche geben.(persönlicher Login)
3)Es sollen Clienteingaben so abgelegt werden, daß sie über Abfragen auswertbar sind (DB & DBMS?)
4)Die Abfrage-Ergebnisse sollen auch für Berechnungen zur Verfügung stehen.
5)Es soll auch mit kalendarischen Werten gerechnet werden können. Eine Art Outlookkalender mit Terminierungsmöglichkeiten. Client wird nach dem Einloggen informiert, daß dies und jenes Ereignis bevorsteht. (Veranstaltung, Party, Geburtstag o. ä.)Das geht alles ganz wunderbar mit Perl zu machen ;)
Darüber hinaus ist Perls DBI-Schnittstelle so aufgebaut, dass sich über den DBD-Layer eine Unabhängigkeit zur DB-Engine ergibt, d.h., ein Perl-Script kann sich mit PostgreSQL genauso verbinden wir mit Sybase, Oracle usw. und wenn sich die Statements auf ANSI SQL beschränken, ist der ganze Code derselbe.
Aber es gibt einen anderen gewichtigen(!) Grund, der gegen Perl spricht:
Bei jedem HTTP-Request auf ein Perl-CGI-Script wird der Interpreter neu gestartet, die Perl-Sources eingelesen (Moduldateien, Scriptdatei) und kompiliert. Erst dann kommt der Code zum 'Zug'. Des Weiteren muss eine etwaige DB-Verbindung auch erst einmal hersgestellt werden. Alles zusammen ist ein Overhead, der bei vielen Requests einen Server in die Knie zwingen kann, Alternativen hierzu gibt es als FastCGI oder mod_perl.Mit diesen Alternativen ist es auch möglich, eine DB-Verbindung persistent zu machen. Ab hier und damit erst wird Perl so richtig schön ;)
Content in CSV-Datei? Ja, irgendwie muss der Inhalt ja erstellt und bearbeitet werden. Aber ich lasse nicht den Serverprozess(Response) auf eine editierbare Text-Datei zugreifen, schneller ists, solch eine Datei vorher entweder in eine Binärdatei umzuwandeln oder die für Responses vorgesehenen Objekte in einer DB abzulegen (Object-Relational-Mapping oder OO-DB). Diese Umwandlung/Transformation macht der Content-Manager...
Übersichtlichkeit Code? Na, ich weiß nicht, was Du da bisher an Perl gesehen hast. Meinem Perl-Code schreibe ich so, dass er jederzeit aus der Hand gegeben werden kann und meine Schnittstellen (Module) sind nicht nur klar definiert und gut dokumentiert sondern sogar austauschbar und durchweg teamfähig ;)
Viele Grüße,
Hotti-
Hi hotti
OK, das war jetzt eine Menge (pro) Infos für Perl. Hinzu kommt, daß ich schon ein bischen mit Perl "hantiert" habe.
Bei einem Login-Projekt ist es erstmal so, daß ich jedem Client, der sich einloggt, einen separaten Ordner verpassen würde. Die Dateien in diesem Ordner sind dann auch nur für diesen Client da.
Sorgen bereiten mir solche Dinge wie Race-Conditions, für den Fall, daß sich der Client z. B. (Ehefrau) Zuhause einlogt, und ihr Ehemann ebenfalls als Client von einem anderen Rechner (z. B. auf Arbeit) zeitgleich einloggt.
Mit den selben Logindaten gibt es Probleme. Solche gleichzeitigen Logins müssten verhindert werden.Soweit ich weis, ist es möglich eine Datei mehrfach für Lesebetrieb zu öffnen. Sollen aber Daten geändert werden, ist das solange kein Problem, wie nur einer drin ist.
Die Logins müssten also sauber getrennt werden. Double Login darf nie möglich sein.
Ich habe früher CSV-Dateien von Perl selber einlesen und zurückschreiben lassen. Bei großen Projekten soll ein DBMS aber besser sein - warum eigentlich? Ich hab da eher bedenken, die Kontrolle aus der Hand zu geben.
Die HTML-Quelltextausgabe über Perl ist auch ein wenig nervig.
Für Ausgabe:print qq(<h1>Super Überschrift),"\n";
print qq(</h1>),"\n";Von den Maskierungen mal abgesehen. BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Sonst ist Perl schon ne tolle Sache - vor allem die Module!
Gruß HP-User
-
hi,
Sorgen bereiten mir solche Dinge wie Race-Conditions, für den Fall, daß sich der Client z. B. (Ehefrau) Zuhause einlogt, und ihr Ehemann ebenfalls als Client von einem anderen Rechner (z. B. auf Arbeit) zeitgleich einloggt.
Logtable in einer Datei? Handler sperren mit LOCK_EX ;)
Du setzt einfach ein Lock auf den Handler, der wird automatisch wieder freigegeben, wenn der Prozess, welcher das Lock gesetzt hat, fertig ist.Bei Bedarf kannst Du auch den ganzen Prozess locken, lege eine Datei namentlich fest und setze den Lock zu Beginn des Scripts. Somit kannst du auch DB-Zugriffe (mysql) atomar machen, wenn nur MyISAM-Tabellen zur Verfügung stehen. Ein eigenes Perl-Modul schreiben: Lock.pm
use Lock qw(auto);MySQL kennt aber auch andere Mechanismen, z.B. Named Lock's.
Mit den selben Logindaten gibt es Probleme. Solche gleichzeitigen Logins müssten verhindert werden.
Soweit ich weis, ist es möglich eine Datei mehrfach für Lesebetrieb zu öffnen. Sollen aber Daten geändert werden, ist das solange kein Problem, wie nur einer drin ist.
Mach Dich mal ein bischen schlauer ;)
Bischen Code aus einem meiner Konstruktors (z.B. für die LogTable):
eval{ $self->{FH}->open($file, O_RDWR|O_CREAT|O_BINARY) || die $!; if($cfg{lock}){ flock($self->{FH}, LOCK_EX) || carp("Your system does not support flock()"); } $self->_deserialize; # Hash komplett einlesen };-> Stellt sicher, dass nur _ein_ Prozess die Logtabelle lesen und beschreiben darf. Der Nächste, der kommt, muss (kurz) warten. Das Alles erledigt flock().
Die Logins müssten also sauber getrennt werden. Double Login darf nie möglich sein.
Überdenke Deinen Login-Prozess. Z.B. so: User 'otto' meldet sich ein Zweitesmal an. Was könnte denn Passieren?
Fall a) die Session-ID ist dieselbe. Hier überschreibe ich lediglich den Anmeldezeitstempel (Verfallsdatum wird nur verlängert).
Fall b) 'otto' kommt mit einer neuen Session-ID. Hier mache ich einen neuen Eintrag.
Cleanup: Läuft immer dann, wenn ein Objekt zur LogTable erstellt wurde, da werden alle Einträge gelöscht, deren Verfallsdatum erreicht ist. Ein klarer Fall für den Destruktor der Klasse Login ;)
Ich habe früher CSV-Dateien von Perl selber einlesen und zurückschreiben lassen. Bei großen Projekten soll ein DBMS aber besser sein - warum eigentlich?
'Zig Tabellen vs. 'zig Dateien? Zu überlegen wäre das ''zig'. Andererseits ists eine Frage der Organisation, z.B. so (multidomain-fähiges Framework):
DB: Abhängig von $ENV{SERVER_NAME} wird das Data-Base-Handle an einen entsprechende DBase gebunden
FileSystem: Abhängig von $ENV{SERVER_NAME} wird der Ordner für die Dateien festgelegtIch hab da eher bedenken, die Kontrolle aus der Hand zu geben.
Wir kommen zur Frage der Sinnfälligkeit von OOP und Modulen...
Die HTML-Quelltextausgabe über Perl ist auch ein wenig nervig.
Ja. Überlege den Einsatz eines Template-Systems ;)
Von den Maskierungen mal abgesehen. BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Frage diejenigen, die sich mit PHP rumschlagen ;)
Btw., ich habe mal einen einfachen Chat sowohl in Perl als auch in PHP geschrieben, etwa diegleiche Zeilenanzahl und beides gleichermaßen überschaubar.
Sonst ist Perl schon ne tolle Sache - vor allem die Module!
Ja! Vor Allem die Module, die selbst geschrieben sind ;)
Hotti
--
Wenn Du aus Fehlern lernen kannst, mach welche.-
Hallo,
Von den Maskierungen mal abgesehen. BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Frage diejenigen, die sich mit PHP rumschlagen ;)
PHP ist eine Templatesprache. Mit Alternativer Syntax http://php.net/manual/de/control-structures.alternative-syntax.php
<ul> <?php foreach ($myList as $entry):?> <li><?php echo $entry?></li> <?php endforeach?> </ul>Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden. Hotti ist bekanntermaßen einer der wenigen Perl-Fans hier. Das ist, so wie ich es sehe, meist historisch bedingt.
Gruß
jobo
-
Abend Leute
@jobo
Rein vom Gefühl her seh ich doch auch, daß so gut wie alles im Internet, was serverseitige Skripts verwendet, in PHP Hand ist (75% laut Wiki).Perl kann ich schon ein wenig. Bei PHP müsste ich bei "Null" anfangen. Das Versionswirrwarr mal nicht beachtend. Bei Version 5 ist glaub aktuell Schluß. Version 6.x wurde eingestellt.
@hotti
Zu Perl: Angenommen ich bau mir wirklich ür jeden Login - oder besser gesagt für jeden Kunden, der sich registriert und einloggt, einen eigenen Ordner mit Unterdatei(en).Spinnen wir mal diesen Gedanken weiter:
Wie sieht es bei 10'000 Kunden aus. Bei 1 Mio Kunden? Bei 10 Mio. Kunden?Alles rein hypothetisch. wieviel Ordner darf ein Apache-Server haben? Ist das von der reinen Speichergröße der Serverfestplatte abhängig. Oder gibt es eine Physikalische Oberkannte?
Gruß HP-User
-
hi,
@hotti
Zu Perl: Angenommen ich bau mir wirklich ür jeden Login - oder besser gesagt für jeden Kunden, der sich registriert und einloggt, einen eigenen Ordner mit Unterdatei(en).Spinnen wir mal diesen Gedanken weiter:
Wie sieht es bei 10'000 Kunden aus. Bei 1 Mio Kunden? Bei 10 Mio. Kunden?Keine Ordner, klarer Fall für eine DB! Die Kundendaten samt PasswortHashes gehören in eine DB und wenn der Index auf dem richtigen Feld sitzt, liegt die Dauer einer Abfrage (z.B. Login) auch bei mehreren Mio Kunden im Millisekundenbereich. Kundendaten im FS ist völlig indiskutabel.
Bleiben wir mal beim Login (Kunde ist bereits registriert): K gibt 'user/pass' ein, die Abfrage über die Kundentabelle sei ok. Du brauchst jetzt eine zweite Tabelle zum Speichern der aktuellen Logins, in dieser Tabelle stehen nur die aktuellen Logins, nicht jedoch _jede_ Browsersitzung. Auch diese Tabelle sollte performant zu befragen sein, denn die Abfrage, ob ein K. eingeloggt ist, kommt bei jedem Request.
Alle Prozesse, die auf Kundentabelle und Logintabelle zugreifen, müssen atomar sein (vom Lesen bis zum Beschreiben).
Mit dem Perl-Modul Benchmark und eingeschalteten profiling (mysql) kannst Du solche Sachen während der Entwicklung prima testen.
Andererseits, wenn es nur eine Handvoll Benutzer für Logins gibt (z.B. Content-Manager, Shop-Master) ist eine Lösung über Dateien durchaus auch sinnvoll, solche Manager-Accounts sind ohnehin klar getrennt von Kundendaten und brauchen auch weniger Datenfelder (Benutzername, Gruppe, PasswortHash). Es gibt Perl-Module als Interface für Passwortdateien...
Vom Dateisystem wird der SourceCode geladen, Templates sind ebenfalls im FS besser aufgehoben, als in einer DB oder Binary. Wenn bei einem Request z.B. ein Script plus 2..10 Moduldateien geladen werden, musst Du nicht befürchten, dass beim zusätzlichen Laden eines Templates aus dem FS die Performance einbricht ;)
Ein Framework mit Perl zu schreiben, macht Spaß, guck, dass Du das mit mod_perl oder als FastCGI machen kannst. Weitere Laufzeitoptimierungen gibt es mit SelfLoader und AutoLoader, für Methoden, die nicht bei jedem Request gebraucht werden: Die werden erst auf Anforderung compiliert wobei die Source entweder aus dem FS oder aus dem RAM geladen wird. Der Code fürs Login wäre z.B. solch ein Kandidat...
Hotti
-
Hallo,
@hotti
Zu Perl: Angenommen ich bau mir wirklich ür jeden Login - oder besser gesagt für jeden Kunden, der sich registriert und einloggt, einen eigenen Ordner mit Unterdatei(en).file_get_contents/file_put_contents sowie serialize/unserialize mit php, einfacher gehts nicht ...; auch wenn der anstatz u.u. (s. hottis anmerkungen) nicht korrekt sein mag, bei größeren datensammlungen. fgetcsc() gibts auch ...; wie gesagt, php für einfach und schnell oder für groß und kompliziert, extra gemacht für webanwendungen ...;
Gruß
jobo
-
-
Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden.
Soso, Glauben - und Wissen; schon ein Unterschied. Schon mal überlegt, was unnützer Tratsch anrichtet?
-
Hallo,
Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden.
Soso, Glauben - und Wissen; schon ein Unterschied. Schon mal überlegt, was unnützer Tratsch anrichtet?Wer ist "unnützer Tratsch"? Und was richtet er an? Wenn Du es weißt, solltest Du es schreiben, wenn nicht, dann vielleicht ein neues Posting eröffnen? Hast Du Zahlen oder Belege? Ich finde z.b.:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Dass es hier Fangemeinden auf beiden Seiten gibt ist klar. PHP ist eine wirklich taugliche Templatesprache für Webseiten. Und hat Haufenweise Frameworks zur Verfügung. Und PHP ist ja im Grunde aus Perl hervorgegangen bzw. in Kenntnis dessen entwickelt worden: "PHP wurde 1995 von Rasmus Lerdorf entwickelt. Der Begriff stand damals noch für Personal Home Page Tools und war ursprünglich als Ersatz für eine Sammlung von Perl-Skripten gedacht, die Lerdorf zur Protokollierung der Zugriffe auf seinen Online-Lebenslauf geschrieben hatte."
Ansonsten noch: http://regulargeek.com/2011/02/09/web-scripting-programming-language-job-trends-february-2011/
Lass Du doch mal Zahlen springen ;-)
Gruß
jobo
-
Hallo,
"Unlike Perl, which is a general purpose scripting language that you can use for a wide variety of purposes (and not just generating web pages), PHP was designed from the ground up to be used for scripting web pages. As a result, it has lots of facilities built into that you may have to write yourself or use some pre-written module if you were using Perl. "
http://www.thesitewizard.com/archive/phpvscgi.shtml
Gruß
jobo
-
Hallo,
http://100days.de/serendipity/
"wetter.com - Relaunch with symfony2, Assetic, Varnish and Twig
After a lot of hard work, on march 10 a complete rebuild of wetter.com went online. The site is #1 or #2 in germany for weather forecasts since years with millions of visits/day. It was built completely new on PHP 5.4, Symfony 2, MySQL, SolR, Varnish and NginX. The task to re-build the whole site from scratch was given to our partner TFT (Tomorrow Focus Technologies) who invited 100 DAYS into the project to develop the symfony2 parts. This post describes the experiences we made when developing and launching this large scale application."und:
"In 2007, the first Plat_Forms contest took place with support of Zend Technologies, University of Berlin, Heise Publishing Company and OSBF. It was a web development platform comparison like it had never been done before: 9 teams in controlled environment doing the same task in a limited time. During that time, the team of Prof. Lutz Prechelt collected data and after the contest, the results together with the data regarding the workflow of the individual teams was evaluated in a scientific way.
Back then, the PHP teams had outperformed Java and Perl in terms of development productivity and usability of the resulting applications. The results of this contests helped to position PHP in many large organisations because they proved common prejudices against PHP wrong: No, PHP is not insecure, no it is not slow, etc."
und daraus folgend:
http://www.plat-forms.org/results-2011
"Plat_Forms - The web development platform comparison"Ich bleibe bei meiner Meinung, dass Perl aus historischen Gründen noch mit dabei ist. Ob das ein Gerücht ist und was ich damit anrichte, sollen andere entscheiden, ist ja immer noch Meinungsfreiheit hier. Und klar, dass CPAN seinem Namen gemäß sich hier für Perl stark machen muss. Aber ohne Zahlen und Fakten hilft es auch nix, andere Ansichten als "Gerüchte", die mutmaßlich Schanden anrichten, abzutun.
Gruß
jobo
-
Hallo,
http://stackoverflow.com/questions/1633000/list-of-large-projects-built-using-perl large perl projects ...;
Gruß
jobo
-
-
-
Wer ist "unnützer Tratsch"? Und was richtet er an?
Schwer von Begriff? Du richtest Intrigen an. Das ist unmoralisch nach breiter Auffassung. Siehe weiter unten zur Meinungsfreiheit.
Dass es hier Fangemeinden auf beiden Seiten gibt ist klar.
Das Fanverhalten sehe ich klar auf deiner Seite, nämlich unbelegte Behauptung zum einseitigen Schlechtmachen von Perl in die Welt zu setzen.
Hast Du Zahlen oder Belege?
Vielleicht. Jedenfalls bist du derjenige mit der Behauptung und hast daher die Bringschuld für die Belege. Lass uns sie anschauen.
Ich finde z.b.: [TIOBE]
Wie ist eine Webseite, die vorgibt, Suchmaschinenergebnisse von den Namen von Programmiersprachen zu messen, ein Beleg für deine Behauptung, dass "dass größere Projekte [nicht mehr] mit Perl gemacht oder begonnen werden"? Der Zusammenhang fehlt.
Abgesehen davon sind die eklatanten Schwächen dieser Statistik bereits ausführlich dokumentiert. Ein KO-Kriterium ist, dass der Urheber dieser Statistik es gutheißt, dass sein System durch externe Manipulation untergraben wird. Das nächste Mal mach dich schlau, bevor du Material anführst.
PHP ist ja im Grunde aus Perl hervorgegangen
Das ist zwar wahr, aber wie ist das ein Beleg für deine Behauptung, dass "dass größere Projekte [nicht mehr] mit Perl gemacht oder begonnen werden"? Der Zusammenhang fehlt.
Ansonsten noch: [regulargeek]
Dieses Blog führt Graphen von Stellenangeboten an. Das ist ein brauchbarer Indikator, wenn wir davon ausgehen, dass das Anteil der Eingestellten, die ein größeres Projekt machen/beginnen, an der Gesamtzahl der Eingestellten einer jeweiligen Sprache gleich ist. Leider versäumt der Autor des Blogeintrags, Perl in den Vergleich aufzunehmen. Lasse also mich Perl mit PHP auf den dort angegebenen Diensten vergleichen:
Ich stelle fest, es gibt mehr Stellenangebote für Perl als PHP. Unter der genannten Annahme gibt es somit mehr größere Projekte, die mit Perl als mit PHP gemacht oder begonnen werden. Dies würde also deiner Behauptung widersprechen, nein, sogar auf den Kopf stellen.
Perl […] is a general purpose scripting language […] PHP was designed […] to be used for scripting web pages
Das ist zwar wahr, aber wie ist das ein Beleg für deine Behauptung, dass "dass größere Projekte [nicht mehr] mit Perl gemacht oder begonnen werden"? Der Zusammenhang fehlt.
wetter.com - Relaunch with […] PHP 5.4
Das ist eine Anekdote und hat keine Aussagekraft. Dieser Beleg ist zu verwerfen.
Plat_Forms contest
An den Wettbewerben nahmen ein paar Dutzend Programmierer teil, die alle dieselbe Aufgabe lösen mussten. Plat_Forms hat zwar einen wissenschaftlichen Mantel an, aber die Teilnehmer wurden nicht danach gefragt, ob sie abseits der Wettbewerbe größere Projekte mit ihrer angestammten Sprache machen/beginnen. Wie also sind die Wettbewerbe ein Beleg für deine Behauptung, dass "dass größere Projekte [nicht mehr] mit Perl gemacht oder begonnen werden"? Der Zusammenhang fehlt.
ist ja immer noch Meinungsfreiheit hier.
Ich verbiete dir den unnützen Tratsch nicht, sondern fordere dich mit Gegenrede heraus. Ich hoffe, dass du zur Einsicht kommst und es in deinem weiteren Leben vermeidest.
-
Wer ist "unnützer Tratsch"? Und was richtet er an?
Schwer von Begriff? Du richtest Intrigen an. Das ist unmoralisch nach breiter Auffassung. Siehe weiter unten zur Meinungsfreiheit.
Wer aggressiv wird, glaubt sich praktisch immer im Unrecht
Dass es hier Fangemeinden auf beiden Seiten gibt ist klar.
Das Fanverhalten sehe ich klar auf deiner Seite, nämlich unbelegte Behauptung zum einseitigen Schlechtmachen von Perl in die Welt zu setzen.
s.o. Noch deutlicher kannst du dein Fanverhalten (das du nach deiner Aussage nicht hast) nicht zeigen.
Ich stelle fest, es gibt mehr Stellenangebote für Perl als PHP.
Es werden massiv mehr Projekte in diesen Bereichen. Da die Anfragen an PHP-Programmierer steigen, die an Perl-Programmierer aber ziemlich konstant böeibt, sehe ich in der Statistik, die Projekte in Perl werden gegenüber deneb in PHP massiv weniger.
Desweiteren heisst die Statistik ebenfalls nur, dass weniger Leute für Perl verfügbar sind als für PHP, sonst würden nicht mehr gesucht.
Da könnte ich jetzt wieder herauslesen, das die interessanten und grossen Projekte nicht mehr in Perl umgesetzt werden, sonst würden sich mehr Programmierer drauf spezialisieren.
Ja, es ist schon schön, wie man sich jede Statistik schön rechnen kann, nur ich muss dabei nicht aggressiv werden, weil ich mich nicht angegriffenfühle.Liegt vermutlich daran, dass ich u.a. PHP UND Perl programmiere und das zu ca. gleichen Teilen. Da aber 80% meiner Tätigkeit C/C++ ausmachen, könnte ich jetzt behaupten, dass erzunehmende Projekte weder in Perl noch in PHP umgesetzt werden. Das wäre aber genau so ein Unsinn, wie deine Reaktion hier.
-
Ich bin ja immer wieder erstaunt, was heutzutage im Selfforum als Diskussionsniveau durchgeht. Die Löcher in der formalen Logik sind so groß, dass man einen LKW durchfahren kann. *Gesichtspalmierung* Kein Wunder, dass die Elite längst abgewandert ist.
Wer aggressiv wird, glaubt sich praktisch immer im Unrecht
Was für eine Salonanalyse… der wahre Grund ist, dass jobo etwas unsäglich Dummes geschrieben/sich dumm gestellt hat.
Noch deutlicher kannst du dein Fanverhalten […] nicht zeigen.
Ja und? Ist es jetzt schlimmer, jemanden durch Gegenrede zu moralischem Verhalten anzuregen, als Gerüchte in die Welt zu streuen? Willst du mir deswegen metaphorisch ans Bein pinkeln? Mann, Mann, Mann.
Es werden massiv mehr Projekte in diesen Bereichen.
Wenn das heißen soll, der gesamte Markt wächst, so ist das wahr.
Da die Anfragen an PHP-Programmierer steigen, die an Perl-Programmierer aber ziemlich konstant böeibt, sehe ich in der Statistik, die Projekte in Perl werden gegenüber deneb in PHP massiv weniger.
Du irrst. Die Statistik bezieht sich auf die Stellenangebote. Du musst die absoluten Zahlen als Argumentationsgrundlage zum Gegenstand der Diskussion (zur Erinnerung: "[jobo glaubt] nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden.") heranziehen, nicht die relativen Veränderungen. (Gedankenexperiment zur Falsifizierung: die Angebote für Supercolliderprogrammierer verdoppelten sich etwa von 23 auf 42.)
Wenn wir davon ausgehen, dass das Anteil der Eingestellten, die ein größeres Projekt machen/beginnen, an der Gesamtzahl der Eingestellten einer jeweiligen Sprache gleich ist, gibt es mehr größere Projekte, die mit Perl als mit PHP gemacht oder begonnen werden. Eine gegenteilige Annahme ist absurd und benötigt eine waschechte Erläuterung von dir, wie du darauf kommst.
Desweiteren heisst die Statistik ebenfalls nur, dass weniger Leute für Perl verfügbar sind als für PHP, sonst würden nicht mehr gesucht.
Du irrst. Der Arbeitsmarkt funktioniert nicht auf diese Weise; Nachfrage wird größtenteils nicht durch Angebot reguliert. Stattdessen sind überwiegend Faktoren ausschlaggebend, die sich an den existenten Bedürfnissen der Organisation orientieren.
Nochmal auf gut deutsch: keine Personalabteilung sagt: "Oh, es gibt so viele Javaprogrammierer, mehr als für jede andere Sprache. Lass uns deshalb Angebote für Javaprogrammierer schreiben, so kaufen wir viele zu einem günstigen Preis ein." Der Chef der Technik würde denen ordentlich Backpfeifen verabreichen, bis sie wieder zur Besinnung kommen. Stattdessen schreiben sie Angebote für Sprache XYZ, weil die bestehende Codebasis schon in XYZ ist. Weiterhin werden neue Projekte in XYZ gemacht, weil sich sonst die Angestellten nicht rentieren.
Da könnte ich jetzt wieder herauslesen, das die interessanten und grossen Projekte nicht mehr in Perl umgesetzt werden, sonst würden sich mehr Programmierer drauf spezialisieren.
So ein Quatsch; das ist keine notwendige Bedingung.
-
-
-
-
-
gudn tach!
<ul>
<?php foreach ($myList as $entry):?>
<li><?php echo $entry?></li>
<?php endforeach?>
</ul>in perl geht so was recht angenehm mittels [HTML::Template](http://search.cpan.org/perldoc?HTML::Template). fuer komplexere websites mit session-verwaltung und allem pipapo gibt es aber auch spezialisierte perl-module wie z.b. [dancer](http://perldancer.org/) oder [catalyst](http://de.wikipedia.org/wiki/Catalyst_Web_Framework). (gibt auch nette tutorials dafuer.) > Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden. wie schon gesagt, ist das quark. wenn du solche meinungen aeusserst, dann solltest du entweder dazusagen, dass du dich darueber nicht im ansatz informiert hast oder - besser - sie gar nicht erst aeussern; aus dem grund, den der user CPAN etwas unfreundlich erklaert hat. in diesem fall haette ein kurzer blick in die wikipedia dich vor dieser aeusserung bewahrt. ein relativ bekanntes projekt, das in perl geschrieben wurde, ist [bugzilla](http://www.bugzilla.org/). weitere finden sich unter <http://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Perl> > Hotti ist bekanntermaßen einer der wenigen Perl-Fans hier. Das ist, so wie ich es sehe, meist historisch bedingt. ja und nein. ich habe vor einigen jahren mit php angefangen, bin dann auf perl gestossen und hab dann aufgehoert, php zu nutzen. perl ist z.b. bequemer als php, wenn man auch an vielen nicht-web-projekten arbeitet und dann die entsprechenden module (z.b. [pdl](http://pdl.perl.org/), vergleichbar mit numpy/scipy bzw. matlab bzw. octave) nutzen kann. das ist aber letztlich alles geschmackssache, so wie linux vs. windows, kde vs. gnome, vim vs. emacs, c++ vs. java, latex vs. word und itchy vs. scratchy. prost seth-
hi,
fuer komplexere websites mit session-verwaltung und allem pipapo gibt es aber auch spezialisierte perl-module wie z.b. dancer oder catalyst. (gibt auch nette tutorials dafuer.)
Module für Session-Management gibt es haufenweise. Da ist keines dabei, was ich empfehlen könnte; eine Session aufzubauen, braucht kein Modul, nicht einmal ein eigens Geschriebenes, das sind nur ein paar Zeilen Code. Session mit cookie
Interessanter ist da schon Crypt::PasswdMD5 für kompatible Passwort-Dateien und nicht verkehrt ists, eigene Überlegungen hinsichtlich Laufzeitoptimierung anzustellen, Stichwort AutoLoader: Für use (komplexe) Module, die einem zwar eine Menge Arbeit abnehmen, tatsächlich aber nicht bei jedem Request gebraucht werden.
Hotti
-
gudn tach!
dancer/catalyst.
Module für Session-Management gibt es haufenweise. Da ist keines dabei, was ich empfehlen könnte; eine Session aufzubauen, braucht kein Modul,ja, man kann auch alles von hand programmieren, habe ich auch schon gemacht. aber obige tools nehmen einem einige arbeit ab und machen den code (weil's einfach weniger ist) uebersichtlicher. zumindest bei groesseren projekten, die viele dynamische subpages beinhalten, kann sowas durchaus sinn machen.
aber das ist wohl letztlich nur ein weiterer punkt in meiner aufzaehlung: from scratch vs. built-in
prost
seth
-
-
Hallo,
gudn tach!
<ul>
<?php foreach ($myList as $entry):?>
<li><?php echo $entry?></li>
<?php endforeach?>
</ul>> > in perl geht so was recht angenehm mittels [HTML::Template](http://search.cpan.org/perldoc?HTML::Template). Ja, für PHP gibt es auch eine Menge Frameworks oder gab es, die mit eigenen Templatesystemene gearbeitet haben. > > fuer komplexere websites mit session-verwaltung und allem pipapo gibt es aber auch spezialisierte perl-module wie z.b. [dancer](http://perldancer.org/) oder [catalyst](http://de.wikipedia.org/wiki/Catalyst_Web_Framework). (gibt auch nette tutorials dafuer.) Ja und bei PHP gibts Symfony, Zend Framework, Django und eine Menge mehr. > > > Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden. > > wie schon gesagt, ist das quark. wenn du solche meinungen aeusserst, dann solltest du entweder dazusagen, dass du dich darueber nicht im ansatz informiert hast oder - besser - sie gar nicht erst aeussern; aus dem grund, den der user CPAN etwas unfreundlich erklaert hat. in diesem fall haette ein kurzer blick in die wikipedia dich vor dieser aeusserung bewahrt. ein relativ bekanntes projekt, das in perl geschrieben wurde, ist [bugzilla](http://www.bugzilla.org/). weitere finden sich unter [http://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Perl](http://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Perl) Nun, ich rede von \_begonnen\_. Das Perl eine taugliche Sprache ist, bestreitet doch niemand. Aber sie taugt eben auch für eine Menge mehr als für Web, und mit PHP-Frameworks und Ruby-on-Rails, die direkt für Web und nur für Web zugeschnitten sind, haben Catalyst und Co eben starkt Konkurrenz. Die Projekte, von denen ich gelesen habe, sind eben \_historisch\_ bedingt in Perl, aber von neuen Projekten habe ich jetzt nix gelesen, wohl aber von ein zwei, die in Perl begonnen wurden (jetzt aber scheinbar nicht mehr in Perl weitergeschrieben wurden). S.a. das Heise-Zitat für Hotti oder Martins Beitrag: <https://forum.selfhtml.org/?t=209706&m=1427700>. Man kann hier zwar geteilter Meinung sein, so ganz von der Hand zu weisen ist mein Hypothese aber nicht, insofern das pauschale Urteil "mach dich erstmal schlau" etwas daneben ...; auf diese angepisste oder agressive Art von CPAN will ich gar nicht weiter eingehen. Den Link zu Perl-Projekten habe ich ja hier auch irgendwo gepostet. > ja und nein. ich habe vor einigen jahren mit php angefangen, bin dann auf perl gestossen und hab dann aufgehoert, php zu nutzen. perl ist z.b. bequemer als php, wenn man auch an vielen nicht-web-projekten arbeitet und dann die entsprechenden module (z.b. [pdl](http://pdl.perl.org/), vergleichbar mit numpy/scipy bzw. matlab bzw. octave) nutzen kann. Genau das ist ja auch die Stärke und mutmaßlich auch gleichzeitig die Schwäche von Perl. > das ist aber letztlich alles geschmackssache, so wie linux vs. windows, kde vs. gnome, vim vs. emacs, c++ vs. java, latex vs. word und itchy vs. scratchy. Naja, für größere Web-Projekte muss man dann schon auch schauen, wie schnell man ein Team dazu bekommt, produktiven Code zu schreiben (erinnere mich da an ein Interview mit einem von Xing (Ruby-on-Rails) - ich kann mir wirklich nicht vorstellen, dass da bei Firmen in der Größenordnung Perl in nennenswerten Maßstab für die Web-Präsenz eine Rolle spielt, aber irren ist ja bekanntlich menschlich und klar kenne ich die nicht alle etc.pp. und sorry, dass ich hier mit Gerüchten die Selfhtml-Gemeinde in die Irre führe ... aber wie man sieht, merken die das ja self). Gruß jobo
-
-
Hallo,
Von den Maskierungen mal abgesehen. BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Frage diejenigen, die sich mit PHP rumschlagen ;)
PHP ist eine Templatesprache. Mit Alternativer Syntax http://php.net/manual/de/control-structures.alternative-syntax.php
<ul>
<?php foreach ($myList as $entry):?>
<li><?php echo $entry?></li>
<?php endforeach?>
</ul>Genau an dieser Stelle gefällt mir PHP auch besser als vergleichbare Template-Systeme die mit Perl gemacht sind. Ausgenommen [EmbPerl](http://search.cpan.org/~grichter/Embperl-2.4.0/Embperl/Syntax.pm), damit werde ich mich demnächst mal etwas näher befassen. > Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden. [Hoffnung vs. Glaube](http://www.heise.de/newsticker/meldung/Android-lernt-Perl-752697.html) Hotti-
Hallo,
Hallo,
Von den Maskierungen mal abgesehen. BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Frage diejenigen, die sich mit PHP rumschlagen ;)
PHP ist eine Templatesprache. Mit Alternativer Syntax http://php.net/manual/de/control-structures.alternative-syntax.php
<ul>
<?php foreach ($myList as $entry):?>
<li><?php echo $entry?></li>
<?php endforeach?>
</ul>> > Genau an dieser Stelle gefällt mir PHP auch besser als vergleichbare Template-Systeme die mit Perl gemacht sind. Ausgenommen [EmbPerl](http://search.cpan.org/~grichter/Embperl-2.4.0/Embperl/Syntax.pm), damit werde ich mich demnächst mal etwas näher befassen. Naja, PHP kannst Du einfach zwischen HTML wurschteln. Einfacher gehts nicht ...; > > > Ich glaube nicht, dass größere Projekte noch mit Perl gemacht oder begonnen werden. > > [Hoffnung vs. Glaube](http://www.heise.de/newsticker/meldung/Android-lernt-Perl-752697.html) Zitat: "für die altehrwürdige Skriptsprache" ;-) Gruß jobo-
hi,
Zitat: "für die altehrwürdige Skriptsprache" ;-)
Mit 55 bin ich auch ein alter Knacker, so alt wird kein Schwein ;)
Btw., PHP, da bin ich jetzt auch mit 'drin'. In einem bereits vorhandenen und produktiven Projekt finde ich einen Programmierstil vor, der mir aus meinen Perl-Zeiten bis etwa 2005 bestens bekannt ist. Somit ist es für mich eine kleine Reise in die Vergangenheit, denn Perl erlaubt es, bereits ab 2001 mit Version 5.6, solche Projekte viel pflegeleichter anzugehen, z.B. mit einer zentralen Verwaltung der Konfiguration, klar definierten Schnittstellen und überschaubarem sowie teamfähigen Code.
Perl ermöglicht z.B. sowas in einem Response-Handler (mod_perl oder ein einziges ausführbares CGI-Script):
use Response; my $res = Response->new; print $res->response; # beliebiger Content # fertig!Die gesamte Programmlogik nach MVC/MVP steckt in der Klasse Response, weitere Klassen werden bei Bedarf zur Laufzeit entweder als Code (bereits kompiliert) hinzugeladen oder als Source, die erst zur Laufzeit kompiliert wird.
Meinen beiden Domänen rolfrost.de und handwerkzeugs.de ist es äußerlich nicht anzusehen, dass ein eigens entwickeltes multidomain-, multiuser- und mandantenfähiges (Shop) Framework dahintersteckt, welches nur ein einziges ausführbares CGI-Script braucht (Source s.oben), die Klasse Response und alle anderen Klassen gleichermaßen benutzt, die somit nur einmal geschrieben werden müssen.
Leider muss ich dieses Projekt ersteinmal beseite legen, mein Job geht vor ;)
Hello *PHP, vielleicht kommen wir _in_ein_paar_Jahren_ mal zu dem Punkt, an dem ich _vor_ein_paar_Jahren_ begonnen habe, richtig guten Code zu schreiben.
Hotti
-
Hallo,
Perl ermöglicht z.B. sowas in einem Response-Handler (mod_perl oder ein einziges ausführbares CGI-Script):
use Response;
my $res = Response->new;
print $res->response; # beliebiger Contentfertig!
<http://framework.zend.com/> Perl war da eher mit dabei, aber deshalb ja "altehrwürdig". Und Ruby und PHP (inkl. Framework!!!) sind nun aber, in Kenntnis der Perl-Fähigkeiten, extra dafür (weiter)entwickelt worden. > Hello \*PHP, vielleicht kommen wir \_in\_ein\_paar\_Jahren\_ mal zu dem Punkt, an dem ich \_vor\_ein\_paar\_Jahren\_ begonnen habe, richtig guten Code zu schreiben. Zend-Framework (s.o.) inkl. Coding-Standards ...; besser noch, gleich mit 2.0 (beta) anzufangen ...; Gruß jobo
-
-
-
-
-
-
Tach!
BTW:Wie wird den Quellcode in PHP geschrieben? Ist das einfacher dort?
Letztlich ist es eine Frage deines eigenen Bauchgefühl. Es wäre keine schlechte Idee, wenn du mal ein PHP-Anfängertutorial beginnen würdest. Du musst es ja nicht ganz durcharbeiten, aber vielleicht soweit, wie du denkst, dass du ein Gefühl für die Sprache bekommen hast. Empfehlen kann ich leider keins, denn alle die ich kenne kranken daran, dass sie unsinniges Zeug erzählen (zum Beispiel $_GET/$_POST erstmal kopieren oder Entitys statt Umlaute verwenden) oder nicht gleich von Anfang an auf sicheres Programmieren achten (Werte ohne Kontextwechselbeachtung ausgeben). Das Quake-Net-Tutorial ist da noch das kleinere Übel, das ist noch eines der besten und die Sicherheit kommt zumindest in späteren Kapiteln dran.
dedlfix.
-
-
hi,
Aber es gibt einen anderen gewichtigen(!) Grund, der gegen Perl spricht:
Bei jedem HTTP-Request auf ein Perl-CGI-Script wird der Interpreter neu gestartet, die Perl-Sources eingelesen (Moduldateien, Scriptdatei) und kompiliert. Erst dann kommt der Code zum 'Zug'. Des Weiteren muss eine etwaige DB-Verbindung auch erst einmal hersgestellt werden. Alles zusammen ist ein Overhead, der bei vielen Requests einen Server in die Knie zwingen kann, Alternativen hierzu gibt es als FastCGI oder mod_perl.Sind diese Alternativen nicht verfügbar und soll trotzdem ein Framework mit Perl gebaut werden (pures Perl-CGI) muss der Code so schlank wie möglich sein (s. Anm.). Das mache ich bspw. so, dass Module (Klassen) nur auf Anforderung (je nach REQUEST_URI) geladen werden. D.h., anstelle
use Class;verwende ichrequire Class;, wobei das Argument für require auch in einer Variablen stehen kannrequire $class; # it works, wohingegenuse $class; # wrong!nicht funktioniert.Anm.: Wie schon gesagt, nach dem Laden des Perl-Interpreters werden alle Sourcen, Source der Class main und Sources aller anderen Klassen, welche mit 'use' eingebunden sind, kompiliert. Es lohnt, sich in dieser Hinsicht einen Kopf zu machen und es ist für Perl-CGI's nahezu tödlich, bei jedem Request > 300 Methoden zu komilieren, wo für den Request selbst tatsächlich nur eine Handvoll Methoden gebraucht werden. Und? Es geht auch anders.
Schönes Osterfest ;)
Horst Haselhuhn
-
-
Zu Perl vs. PHP möchte ich als bekennender Perl-Fanboy anmerken: Die Verfügbarkeit bei Hostern wie Entwicklern ist für PHP drastisch größer.