nicht angemeldet Tim Tepaße
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Hellihello
In Berlin haben sich die Schulen darauf geeingt, Plone als CMS zu verwenden, ein auf Zope basierendes CMS, daher in Python programmiert. Eben las ich einen Vergleich von Perl und Python an. Python ist scheinbar genauso praktisch zu handhaben, erlaubt sogar die Einbindung von C, wenn das performatorisch nötig scheint. Auf dem 100Euro-Laptop läuft Python.
Warum fällt neben Perl und PHP zwar ROR aber nicht auch der Name Python und warum neben dem Apachen nicht der Webserver ZOPE? Obwohl laut Wikipedia namhafte Unternehmen darauf sezten: Yahoo Real Estate, NASA / Space Telescope Science Institute (Hubble), NATO, US Navy, Technische Universität Dresden, Bundesamt für Strahlenschutz, Die Zeit, Humboldt-Universität zu Berlin, Lufthansa, TU München, Volkswagen AG, Technische Universität Wien etc.pp.
Ist das eine gefühlter Infomangel oder kommt das hier im Forum nicht vor oder überles ich das oder "braucht" man das nicht oder ist Typo3 und Apache und PHP einfach besser oder oder oder?
Dank und Gruß,
frankx
Hallo Frank,
Warum fällt neben Perl und PHP zwar ROR aber nicht auch der Name Python und warum neben dem Apachen nicht der Webserver ZOPE? (...)
Zope ist meines Wissens eher ein Applications Server, den man eher hinter einem Webserver betreibt.
Ist das eine gefühlter Infomangel oder kommt das hier im Forum nicht vor oder überles ich das oder "braucht" man das nicht oder ist Typo3 und Apache und PHP einfach besser oder oder oder?
Tatsächlich ist das Interesse im semiprofessionellen oder hobbyesken Umfeld wie hier in SELFHTML eher geringer. Ich hatte mal vor Jahren mehr als Scherz hier im Forum die Kategorie Python eingerichtet, die dann in die Neuorganisation der Kategorien noch etwas weiter geführt wurde. Zu sagen, dass die Kategorie wenig benutzt wurde, wäre eine Untertreibung; ein Thread pro Quartal war schon viel. Konsequenterweise wurde die Kategorie wieder entfernt.
Ein Grund der nicht so großen Sichtbarkeit von Python ist meiner Meinung die Tatsache, dass lange Zeit die sehr günstigen 08/15-Hosting-Angebote eben nicht Python (als CGI) im Angebot hatten und Perl und PHP als Pionieren in diesem Bereich nun mal die Nase vorne haben. Für das Ausprobieren aus reiner Neugierde blieb dann nicht mehr viel Motivation übrig.
Nebenbei: Größere Web-Frameworks anderer Sprachen wie Zope, Turbogears und das von mir besonders bevorzugte Django haben dazu noch das Problem, dass sie anstatt des langsameren CGIs entweder im Webserver (z.B. mittels mod_python) betrieben werden oder aber mittels Weiterleitung über FastCGI, SCGI dahinter als eigener Prozess. Gegen ersteres haben Shared Hoster berechtigte Sicherheitsbedenken, bei letzterem mögen sie nicht die langlaufenden Prozesse. Für Otto Normalwebfrickler bleibt dann nur CGI übrig.
Neben der leichten Unbekanntheit und der Bescheidenheit der Pythonistas ist es also auch eine leichte Behinderung durch infrastrukturelle Einschränkungen. Insofern finde ich das schon verständlich, dass man das eher im semi- bis professionelleren Bereich findet, in dem man Kontrolle über seinen Webspace hat und im Prinzip sich erst für eine Sprache, dann für die Infrastruktur des Webservers Gedanken machen kann.
Was eigentlich eine Schande ist. Ich mag Python. Und dessen WSGI-Interface. Und Django.
Tim
Hellihello Tim
dank der Antwort.
Zope ist meines Wissens eher ein Applications Server, den man eher hinter einem Webserver betreibt.
Zope enthält den Webserver Zserver, eine erweiterte Version des in Python geschriebenen Servers Medusa. Ein weiterer Webserver wird daher nicht benötigt. Es ist jedoch problemlos möglich (und wird auch oft praktiziert), Zope „hinter“ einem Apache-Webserver zu betreiben.
(http://de.wikipedia.org/wiki/Zope_(Webanwendungsserver)).
Nebenbei: Größere Web-Frameworks anderer Sprachen wie Zope, Turbogears und das von mir besonders bevorzugte Django haben dazu noch das Problem, dass sie anstatt des langsameren CGIs entweder im Webserver (z.B. mittels mod_python) betrieben werden oder aber mittels Weiterleitung über FastCGI, SCGI dahinter als eigener Prozess. Gegen ersteres haben Shared Hoster berechtigte Sicherheitsbedenken, bei letzterem mögen sie nicht die langlaufenden Prozesse. Für Otto Normalwebfrickler bleibt dann nur CGI übrig.
Neben der leichten Unbekanntheit und der Bescheidenheit der Pythonistas ist es also auch eine leichte Behinderung durch infrastrukturelle Einschränkungen. Insofern finde ich das schon verständlich, dass man das eher im semi- bis professionelleren Bereich findet, in dem man Kontrolle über seinen Webspace hat und im Prinzip sich erst für eine Sprache, dann für die Infrastruktur des Webservers Gedanken machen kann.
Was eigentlich eine Schande ist. Ich mag Python. Und dessen WSGI-Interface. Und Django.
Warum schafft es dann aber sowas wie ROR sich zu etablieren? Weil die so ein feines Framework geschaffen haben? In der letzten Ausgabe von "IX" war wenn ich recht erinnere ein Interview mit Xing/OpenBC, die begründet haben, warum sie ihr Auftritt mit ROR machen (Schnelligkeit bei der Entwicklung von sauberem Produktivcode).
Im Grunde also alles "Geschmackssache"? Denn Zend erarbeitet ja auch fleißig weiter an einem Framework für PHP, für Perl gibts ja auch eins, Javascript erwähn ich jetzt mal nicht, da ja (leider nur) clientseitig. Nun spiel ich ja mit "meinem" virtuellen Server, könnter da also auch einen Zope installieren, mod_python gibts glaub ich sowieso beim Apache2. Der Grund, hier mal etwas zu forschen wäre schlicht die Tatsache, dass die Berliner Schulen sich für diese Combi entschieden haben, und ich Anbindung an einen Endnutzer (eine Schule) hier habe. Andereseits versteht man wohl erst bei Blick in die Tiefe, warum manche sich für Zope/Python entscheiden statt für Apache/Perl oder Apache/ROR (was ja auch den Apache2.2 voraussetzt und irgendwelche Mongrels, die ohne Serverkontrolle auch nicht vorhanden sind).
Dank und Gruß,
frankx
Hallo,
Javascript erwähn ich jetzt mal nicht, da ja (leider nur) clientseitig.
Das stimmt ja nun mal gar nicht. http://en.wikipedia.org/wiki/Server-side_JavaScript
Andereseits versteht man wohl erst bei Blick in die Tiefe, warum manche sich für Zope/Python entscheiden
Kannst du vielleicht etwas darüber schreiben? Ich finde das interessant aber hab nicht wirklich die Zeit und Lust mich da reinzuarbeiten, wenn es sowieso nichts für mich ist.
statt für Apache/Perl oder Apache/ROR (was ja auch den Apache2.2 voraussetzt
Wieso Apache 2.2? Ich habe hier noch den 1.3er und ROR funktioniert wunderbar. Oder meinst du etwas anderes?
Jeena
Hellihello jeena,
Hallo,
Javascript erwähn ich jetzt mal nicht, da ja (leider nur) clientseitig.
Das stimmt ja nun mal gar nicht. http://en.wikipedia.org/wiki/Server-side_JavaScript
Cool, kann "man" da unter Apache auch DOM-Bäume mit Javascript aufbauen - document.createElement("input") ... etc.? Habs nur überflogen und muss jetzt erstmal los.
Andereseits versteht man wohl erst bei Blick in die Tiefe, warum manche sich für Zope/Python entscheiden
Kannst du vielleicht etwas darüber schreiben? Ich finde das interessant aber hab nicht wirklich die Zeit und Lust mich da reinzuarbeiten, wenn es sowieso nichts für mich ist.
Nun, grundsätzlich schon. Aber mich verpflichten bzw. versprechen kann ich jetzt ersmal (zu) nix, weil das bei mir vorerst mal rein interessengeleitet ist. Grundsätzlich verfolge ich aber schon den Gedanken, die Ausbeute von Informationszusammenstellung (öffentlich) zu Dokumentieren.
statt für Apache/Perl oder Apache/ROR (was ja auch den Apache2.2 voraussetzt
Wieso Apache 2.2? Ich habe hier noch den 1.3er und ROR funktioniert wunderbar. Oder meinst du etwas anderes?
Ist nur dem Hören nach. Ein Könner in meinem Umfeld wollte ein ROR-Projekt rundum installieren. Und er meinte, Apache2.2 sei nötig. Wozu genau aber weiß ich nicht, und wozu die "Mongrels" weiß ich auch nicht. Es geht im wesentlichen um das "OR" also on Rails, dachte ich.
Dank und Gruß, bis später,
frankx
echo $begrüßung;
[Zope]
Als ich mir vor ca. einem Jahr Zope ansah, fand ich es ziemlich angestaubt, da es doch schon recht alt ist. Seit seiner Entstehung hat sich sowohl Python als auch der allgemeine Programmierstil weiterentwickelt. Da es eine Reihe von Projekten gibt, die auf bestimmte althergebrachte Leistungsmerkmale aufsetzen, die man heutzutage vermutlich anders lösen würde, kann man sich nur schwer von diesen Altlasten befreien. Und das geht nicht nur Zope so: http://www.golem.de/0711/55771.html, um nur mal ein recht prominentes Beispiel zu nennen.
Neben der leichten Unbekanntheit und der Bescheidenheit der Pythonistas ist es also auch eine leichte Behinderung durch infrastrukturelle Einschränkungen.
Ich schätze die Behinderung deutlicher ein. Zwar bietet beispielsweise auch 1&1 Python in seinen Webhosting-Paketen an, aber wenn man mal genau hinsieht, entpuppt sich das im Prinzip nur als ein Werbeprospekt-Pluspunkt. Die eingesetzte Version ist nicht besonders aktuell und einfach so loslegen, wie das mit PHP funktioniert, ist einfach nicht drin.
Warum schafft es dann aber sowas wie ROR sich zu etablieren? Weil die so ein feines Framework geschaffen haben?
Meiner Meinung nach, weil sie versprehen, dass die Entwicklung ganz einfach und ganz schnell geht. Das freut sowohl Entscheider als auch Umsetzer, doch stimmt das mMn nur auf den ersten Blick und für die 0815-Standard-Aufgaben. Doch so einfach sind die zu erledigenden Aufgaben nicht immer. Sobald man mehr als eine 1:1-Abbildung auf Datenbanktabellen haben möchte, fangen teilweise ziemliche Verrenkungen an. Probier doch mal in den Frameworks, die du dir ansehen willst, eine Funktion in ein SQL-Statement einzubinden. Manchmal wird man sogar gegängelt, bestimmte Schreibweisen bei den Tabellen- und Feldnamen zu verwenden. Und das beobachtete ich in allen von mir näher betrachteten Frameworks.
Die ersten 90% eines Projektes benötigen die ersten 90% der Zeit. Die anderen 10% benötigen die anderen 90% der Zeit. - Egal, welches Framework man verwendet.
Im Grunde also alles "Geschmackssache"?
Ja, so sehe ich das auch.
Andereseits versteht man wohl erst bei Blick in die Tiefe, warum manche sich für [X] entscheiden statt für [Y].
(Ich erlaubte mir mal, das Zitat zu verallgemeinern.)
Einerseits wird es wohl daran liegen, dass sie mit X schon vertraut sind, die Einarbeitung in Y auch wieder aufwendig ist, andererseites, wenn man von vorn anfangen kann, man das Gefühl hat mit X besser zurecht zu kommen, oder einem dessen Syntax besser gefällt.
echo "$verabschiedung $name";
Hi
Doch so einfach sind die zu erledigenden Aufgaben nicht immer. Sobald man mehr als eine 1:1-Abbildung auf Datenbanktabellen haben möchte, fangen teilweise ziemliche Verrenkungen an.
Kannst du bitte einen Verrenkung beschreiben?
Die Railsmodelle mit ActiveRecords kennen eigentlich AFAIK 1:1, 1:n und m:n Beziehungen, die mit Attributen wie z.B. 'has_one' oder 'belongs_to' abgebildet werden.
Bye
Kurt
echo $begrüßung;
Doch so einfach sind die zu erledigenden Aufgaben nicht immer. Sobald man mehr als eine 1:1-Abbildung auf Datenbanktabellen haben möchte, fangen teilweise ziemliche Verrenkungen an.
Kannst du bitte einen Verrenkung beschreiben?
Eine der Verrenkungen stand im nachfolgenden Satz: "eine Funktion in ein SQL-Statement einbinden"
Beispiel im Zend Framework: http://framework.zend.com/manual/en/zend.db.html#zend.db.adapter.write.insert - man muss diese Funktion oder einen Ausdruck in ein eigenes Objekt Zend_Db_Expr packen.
Auch andere datenbankspezifische Funktionalität lässt sich meist nicht nutzen, weil diese Frameworks oft (immer?) auf dem kleinsten gemeinsamen SQL-Nenner aufbauen, damit zum einen das Datenbanksystem austauschbar bleibt, und zum anderen nach oben hin eine einheitliche Schnittstelle zur Verfügung gestellt werden kann.
Weitere Beispiele:
Die Railsmodelle mit ActiveRecords kennen eigentlich AFAIK 1:1, 1:n und m:n Beziehungen, die mit Attributen wie z.B. 'has_one' oder 'belongs_to' abgebildet werden.
Solche Beziehungen lassen sich oft auch mit den anderen Framworks abbilden. Doch das sind in meinen Augen auch nur mehr oder weniger 0815-Anwendungsfälle.
Ich meinte mit der "1:1-Abbildung" nicht die Beziehungen der Daten untereinander, sondern den Umgang der Frameworks mit den Tabellen. Jede Tabelle wird mit einer eigenen Klasse abgebildet. Natürlich kann man sie miteinander verknüpfen, aber nur für die vorgegebenen Standardfälle.
echo "$verabschiedung $name";
Hi
Danke für die Ausführungen ...
Ich verstehe zuwenig von Datenbanken, Rails hat aber sowas wie find_by_sql. Zend kenn ich nicht mal theoretisch ...
Ich denke für Leute die keine komplexen Datenbankakrobatik brauchen, sind solche Frameworks ein guter Einstieg.
Tschau
Kurt
Hallo frankx,
dein Interesse an Python ist berechtigt, wenn es eine Sprache bzgl Reichtum, Support und Geschwindigkeit mit Perl aufnehmen kann ist es Python.
Und Python hat wohl die steilere Lernkurve, ich weiß von größeren Projekten (Non-Web) wo man von Perl umgestiegen ist, weil die Leute den Code der anderen nicht mehr handeln konnten...
Das Grundproblem ist aber das beide Lager kaum Überschneidungen haben... ich hatte früher massive Probleme alten Perl-Code zu warten und lange überlegt auf Ruby oder Python umzusteigen. (PHP ist mir zu Nischenmäßig)
Python-Code find ich aber ad-hoc unlesbar, während man PHP und Ruby irgendwie als Perldialekte begreifen kann.
Alleine die Einrückungsyntax...
Manche sehen übrigens in Ruby auch das sauberere Perl. (Die ganze Kritik an Perl hat zu massiven Redesigns in Perl6 geführt, die Ruby-community setzt auch große Hoffnungen auf Parrot als VM)
Die Perl-Leute haben den Stallgeruch von "Shell-scriptern", während die Python-Menschen aus der "Pascal-Ecke" kommen ... d.h. da gibts keien sanfte Migration für das Perl/PHP Lager ist es viel einfacher mal mit Ruby rumzuexperimentieren, Scriptinganfänger hingegen kommen mit Py deutlich besser zurande.
OK was die Frameworks anbelangt also Django, Rails und Catalyst, reicht es in einen Buchladen zu gehen und zu beobachten wo sich die Regale biegen ... bei Rails! (wo ich jetzt reinschnuppere, schon weil die Konzepte genial sind und ich nicht vom Support von Hostern eingeschränkt bin ... und eben weil ich mein Hirn nicht verbiegen muss um den Code zu lesen)
Da ich meinen Perl Codingstyle stark an Perl6 orientiere
hoffe ich dass das in 2 Jahren in einer Art Perl6 on Rails konvergiert.
Das ist aber Spekulation ... sollte Perl6 nicht kommen, werden die ganzen kommenden Generationen die jetzt auf Python ausgebildet werden, das Blatt sicher wenden.
Was deine Frage mit den Berliner Schulen anbelangt... möchtest du einen Lehrplan auf Perl5 aufbauen?
Ciao
Kurt
Hellihello Kurt,
dein Interesse an Python ist berechtigt, wenn es eine Sprache bzgl Reichtum, Support und Geschwindigkeit mit Perl aufnehmen kann ist es Python.
Kann "man" das so sagen? Oder müsste man das genauer formulieren in Bezug auf den Projektumfang? So einen kleinen Internetshop, ein Protal für eine Schule, eine Art Board im übersichtlichen Rahmen - um nur mal ein paar Beispiele zu nennen, sind doch mit PHP/PEAR/Zend-Framework gut bedient, oder nicht? Ich bin beileibe hier kein Fan von irgendwas oder ein Verfechter von diesem vs. jenem.
Und Python hat wohl die steilere Lernkurve, ich weiß von größeren Projekten (Non-Web) wo man von Perl umgestiegen ist, weil die Leute den Code der anderen nicht mehr handeln konnten...
Also für große Projekte ist Python vielleicht besser geeignet. Warum eigentlich? Läuft das nicht eh alles in Klassen, Funktionen, Eigenschaften und deren Kommunikation untereinander? Wie kann ich mir das vorstellen, dass bei der einen Sprache ein Haufen von ifs/whiles und foreaches am Ende soviel mehr unübersichtlichen Code produzieren (mal abgesehen von Rubys "Scaffoliding").
Das Grundproblem ist aber das beide Lager kaum Überschneidungen haben... ich hatte früher massive Probleme alten Perl-Code zu warten und lange überlegt auf Ruby oder Python umzusteigen. (PHP ist mir zu Nischenmäßig)
Ah, das erklärt, warum ich davon bisher sowenig mitbekommen habe.
Python-Code find ich aber ad-hoc unlesbar, während man PHP und Ruby irgendwie als Perldialekte begreifen kann.
Alleine die Einrückungsyntax...
Bei Python ist doch die Einrückung Syntaxbestandteil, oder?
Manche sehen übrigens in Ruby auch das sauberere Perl. (Die ganze Kritik an Perl hat zu massiven Redesigns in Perl6 geführt, die Ruby-community setzt auch große Hoffnungen auf Parrot als VM)
Muss ich mal googlen, warum Ruby eine VM braucht, später...;
Die Perl-Leute haben den Stallgeruch von "Shell-scriptern", während die Python-Menschen aus der "Pascal-Ecke" kommen ... d.h. da gibts keien sanfte Migration für das Perl/PHP Lager ist es viel einfacher mal mit Ruby rumzuexperimentieren, Scriptinganfänger hingegen kommen mit Py deutlich besser zurande.
Dann doch wieder verwunderlich, dass Anfänger (viele fangen doch scheints mit PHP "an") nicht mit Python anfangen. Nun eben, weils die großen Maßenprovider standardmäßig nicht anbieten vermutlich.
OK was die Frameworks anbelangt also Django, Rails und Catalyst, reicht es in einen Buchladen zu gehen und zu beobachten wo sich die Regale biegen ... bei Rails! (wo ich jetzt reinschnuppere, schon weil die Konzepte genial sind und ich nicht vom Support von Hostern eingeschränkt bin ... und eben weil ich mein Hirn nicht verbiegen muss um den Code zu lesen)
Neuerdings hörte ich vom Zend-Framework für PHP, mit seinem ersten Release von einigen Monaten. Hatte das mal runtergeladen. Der Unterschied zu den PEAR-Klassen hat sich mir auf Anhieb nicht erschlossen, aber es muss ein komplettes Konzept dahinter stecken. Aber auch hier die rein menschliche Verwunderung, warum sich Leute aufmachen, da was neues zu erfinden oder zu bauen. Denen muss doch anderswo was fehlen, oder ist das Spieltrieb?
Da ich meinen Perl Codingstyle stark an Perl6 orientiere
hoffe ich dass das in 2 Jahren in einer Art Perl6 on Rails konvergiert.Das ist aber Spekulation ... sollte Perl6 nicht kommen, werden die ganzen kommenden Generationen die jetzt auf Python ausgebildet werden, das Blatt sicher wenden.
Also dann doch Python statt ROR. Den PHPler den ich kenne (also er macht auch Java und C#) ist ganz begeistert von ROR.
Was deine Frage mit den Berliner Schulen anbelangt... möchtest du einen Lehrplan auf Perl5 aufbauen?
Nein, das ist so: Die Berliner Schulen haben sich auf die gemeinsame Nutzung eines CMS geeinigt. Und das ist eben Plone. Was ist Plone war meine Frage, jetzt suche ich Antworten (;-). Kurz darauf haben sich die Brandenburger für Typo3 entschieden. Da wusste ich, was gemeint ist (;-). Es geht bei den Schulen darum, das jede Schule eben ihre Webpräsenz selbst pflegt, aber das auf einer gemeinsamen Basis.
Dank und Gruß,
frankx
echo $begrüßung;
Neuerdings hörte ich vom Zend-Framework für PHP, mit seinem ersten Release von einigen Monaten. Hatte das mal runtergeladen. Der Unterschied zu den PEAR-Klassen hat sich mir auf Anhieb nicht erschlossen, aber es muss ein komplettes Konzept dahinter stecken.
Genau das ist es zum einen, dass es nicht nur wie bei PEAR eine mehr oder weniger lose Klassensammlung ist, sondern ein Framework. Zum anderen muss sich PEAR mit ein paar PHP-4-OOP-Altlasten und Workarounds aufgrund fehlender Funktionalität (z.B. Exceptions) abplagen, die man mit dem Zend Framework, das PHP 5 voraussetzt, schon vom Ansatz her nicht zu berücksichtigen braucht.
Aber auch hier die rein menschliche Verwunderung, warum sich Leute aufmachen, da was neues zu erfinden oder zu bauen. Denen muss doch anderswo was fehlen, oder ist das Spieltrieb?
Der treibende Kern ist hier die Firma Zend. Und die hat nicht nur Kontakte zu großen professionellen PHP-Anwendern (Firmen wie z.B. IBM), bei dem man auch mal die Bedürfnisse nach etwas modernem, einheitlichen zur Sprache gebracht hat. Ein wichtiger Grund war sicher auch die Lizenzierung und das CLA, das jeder Beitragende abgeben muss, und die damit einhergehende Rechtssicherheit der Anwender.
echo "$verabschiedung $name";
Hellihello $name,
Der treibende Kern ist hier die Firma Zend. Und die hat nicht nur Kontakte zu großen professionellen PHP-Anwendern (Firmen wie z.B. IBM), bei dem man auch mal die Bedürfnisse nach etwas modernem, einheitlichen zur Sprache gebracht hat. Ein wichtiger Grund war sicher auch die Lizenzierung und das CLA, das jeder Beitragende abgeben muss, und die damit einhergehende Rechtssicherheit der Anwender.
Und solche wirtschaftlichen Interessen gibt es auch in Bezug auf Perl, Ruby (on Rails) und Python?
Dank und Gruß,
frankx
Hi
... die man mit dem Zend Framework, das PHP 5 voraussetzt, schon vom Ansatz her nicht zu berücksichtigen braucht.
jetzt muss ich mal dumm fragen: unterstützen alle Hoster mittlerweile PHP5?
Gruß
Kutr
Hallo,
jetzt muss ich mal dumm fragen: unterstützen alle Hoster mittlerweile PHP5?
da möchte ich auch ein paar Fragen stellen:
Unterstützen alle Hoster mittlerweile Ruby?
Unterstützen alle Hoster mittlerweile Perl?
Unterstützen alle Hoster mittlerweile .NET?
[Liste nach Belieben fortzusetzen]
Freundliche Grüße
Vinzenz
Hallo,
jetzt muss ich mal dumm fragen: unterstützen alle Hoster mittlerweile PHP5?
da möchte ich auch ein paar Fragen stellen:
Unterstützen alle Hoster mittlerweile Ruby?
Unterstützen alle Hoster mittlerweile Perl?
Unterstützen alle Hoster mittlerweile .NET?
Bei perl weiß ich es nicht... bei den anderen bezweifle ichs!
... weißt du's???
Gruß
Kurt
echo $begrüßung;
jetzt muss ich mal dumm fragen: unterstützen alle Hoster mittlerweile PHP5?
Wer nach der Abkündigung von PHP4 immer noch kein PHP5 unterstützt sollte nicht länger als Hoster bezeichnet werden.
echo "$verabschiedung $name";
Hellihello frankx,
... So einen kleinen Internetshop, ein Protal für eine Schule, eine Art Board im übersichtlichen Rahmen - um nur mal ein paar Beispiele zu nennen, sind doch mit PHP/PEAR/Zend-Framework gut bedient, oder nicht?
Es gibts einen einfachen Grund warum ich mich nie intensiv mit PHP beschäftigt habe... ich bevorzuge Allrounder und PHP ist der König unter den Websprachen und sonst überall ein Betler.
Ruby ist für mich ein modernisiertes Perl, PHP ein abgespecktes.
Und Python hat wohl die steilere Lernkurve, ich weiß von größeren Projekten (Non-Web) wo man von Perl umgestiegen ist, weil die Leute den Code der anderen nicht mehr handeln konnten...
Also für große Projekte ist Python vielleicht besser geeignet. Warum eigentlich?
Weil Perl syntaktisch wahnsinnig reich ist und Python klarere vorgaben macht wie was zu proggen ist. (Perlfreaks nennen sowas gerne "Faschismus") Wenn aber jeder seinen eigene Individualität entfaltet, leidet die Lesbarkeit des Codes für die Gruppe. Auch leidet die Fehlertoleranz wenn jeder Schreibfehler immernoch gültiger Perlcode ist ...und wenn der Compiler nicht meckert dann fröhliche Fehlersuche. (Pythonleute bezeichnen Perlcode gerne als "Linenoise")
Bei Python ist doch die Einrückung Syntaxbestandteil, oder?
ja! sehr gewöhnungsbedürftig ... aber Python findet man mittlerweile überall ob in GIMP oder in Nokia-Handys.
Manche sehen übrigens in Ruby auch das sauberere Perl. (Die ganze Kritik an Perl hat zu massiven Redesigns in Perl6 geführt, die Ruby-community setzt auch große Hoffnungen auf Parrot als VM)
Muss ich mal googlen, warum Ruby eine VM braucht, später...;
Ruby/PHP ist Faktor 4 langsamer als Perl/Python, auf Parrot hingegen wärs 1. Liga.
Parrot hat den Anspruch das Scriptsprachen mit C mithalten.
Dann doch wieder verwunderlich, dass Anfänger (viele fangen doch scheints mit PHP "an") nicht mit Python anfangen. Nun eben, weils die großen Maßenprovider standardmäßig nicht anbieten vermutlich.
Webanfänger fangen mit PHP an. Keine Schule wird aber in ihrem Inf-Unterricht mit PHP anfangen. Python wär hingegen ne sehr gute Wahl.
Also dann doch Python statt ROR. Den PHPler den ich kenne (also er macht auch Java und C#) ist ganz begeistert von ROR.
Naja dass wird noch 5-10 Jahre dauern bis überhaupt eine Sprache klar dominiert. Ich erinnere mich vor 10 Jahren wurde noch massiv in TCL entwickelt...gibts das noch?
Grüße
Kurt
Hellihello Kurt,
Es gibts einen einfachen Grund warum ich mich nie intensiv mit PHP beschäftigt habe... ich bevorzuge Allrounder und PHP ist der König unter den Websprachen und sonst überall ein Betler.
Ruby ist für mich ein modernisiertes Perl, PHP ein abgespecktes.
Ja, das kann ich verstehen, und sehe ja auch an meinen Lernerfolgen, dass PHP im Grunde eine schlichte und einfache Möglichkeit ist, über haupt die Progammierlogik mal auszuprobieren mit allen logischen Möglichkeitn. Kannste erstmal PHP, kannste auch gut Perl oder Ruby lernen. Das muss jetzt nicht heißen, dass das für alle oder auch sonst ein sinniger Weg ist.
Und Python hat wohl die steilere Lernkurve, ich weiß von größeren Projekten (Non-Web) wo man von Perl umgestiegen ist, weil die Leute den Code der anderen nicht mehr handeln konnten...
Also für große Projekte ist Python vielleicht besser geeignet. Warum eigentlich?
Weil Perl syntaktisch wahnsinnig reich ist und Python klarere vorgaben macht wie was zu proggen ist. (Perlfreaks nennen sowas gerne "Faschismus") Wenn aber jeder seinen eigene Individualität entfaltet, leidet die Lesbarkeit des Codes für die Gruppe. Auch leidet die Fehlertoleranz wenn jeder Schreibfehler immernoch gültiger Perlcode ist ...und wenn der Compiler nicht meckert dann fröhliche Fehlersuche. (Pythonleute bezeichnen Perlcode gerne als "Linenoise")
Fein (;-). Und deshalb ist Ruby interessant, weil das Framework genauso enge Vorgaben macht. Der Xing-Mann im IX-Interview sagte ja, dass auch Einsteiger in der Firma bereits am ersten Tag produktiven Code schreiben könnten.
Bei Python ist doch die Einrückung Syntaxbestandteil, oder?
ja! sehr gewöhnungsbedürftig ... aber Python findet man mittlerweile überall ob in GIMP oder in Nokia-Handys.
Manche sehen übrigens in Ruby auch das sauberere Perl. (Die ganze Kritik an Perl hat zu massiven Redesigns in Perl6 geführt, die Ruby-community setzt auch große Hoffnungen auf Parrot als VM)
Muss ich mal googlen, warum Ruby eine VM braucht, später...;
Ruby/PHP ist Faktor 4 langsamer als Perl/Python, auf Parrot hingegen wärs 1. Liga.
Parrot hat den Anspruch das Scriptsprachen mit C mithalten.
Dann doch wieder verwunderlich, dass Anfänger (viele fangen doch scheints mit PHP "an") nicht mit Python anfangen. Nun eben, weils die großen Maßenprovider standardmäßig nicht anbieten vermutlich.
Webanfänger fangen mit PHP an. Keine Schule wird aber in ihrem Inf-Unterricht mit PHP anfangen. Python wär hingegen ne sehr gute Wahl.
Delphi wird im Informatikkurs an dem hiesigen Gymnasium meines Wissens verwandt.
Also dann doch Python statt ROR. Den PHPler den ich kenne (also er macht auch Java und C#) ist ganz begeistert von ROR.
Naja dass wird noch 5-10 Jahre dauern bis überhaupt eine Sprache klar dominiert. Ich erinnere mich vor 10 Jahren wurde noch massiv in TCL entwickelt...gibts das noch?
Dank und Gruß,
frankx
echo $begrüßung;
Python-Code find ich aber ad-hoc unlesbar, [...]
Alleine die Einrückungsyntax...Bei Python ist doch die Einrückung Syntaxbestandteil, oder?
Dieses Argument der Einrückung wird oft und gern von Gegnern oder von nur mit anderen Sprachen vertrauten Programmierern verwendet, die nur sehr wenige Blicke auf Python geworfen haben.
Der Zwang, den Code einzurücken ist nur eine ganz kleine Freiheitsbeschränkung. Als erfahrener Programmierer verwendet man zwecks Übersichtlichkeit sowieso Einrückungen, gerade auch in Sprachen, die das nicht erfordern. Man zwingt sich also selbst, ohne sich darüber aufzuregen. Nur wenn der Zwang von außen kommt ... :-)
Ein wesentlicher Vorteil ist, dass einem dann solche Fehler nicht mehr passieren können:
<?php
if ($bedingung)
anweisung1();
anweisung2();
unbedingt_weiter();
?>
Nun kommt mir nicht mit dem Argument: "Ja, wenn man konsequent auch einzeilige Anweisungen {}-klammert, ..." - denn dann hätten wir wieder den selbst auferlegten Zwang.
echo "$verabschiedung $name";
Hi
Dieses Argument der Einrückung wird oft und gern von Gegnern oder von nur mit anderen Sprachen vertrauten Programmierern verwendet, die nur sehr wenige Blicke auf Python geworfen haben.
Ich bin kein Gegner, ich sag nur ich hab gewöhnungsprobleme, weil ich krampfhaft die Klammern suche.
Ausserdem programmiere ich gerne dynamisch und in evals machen sich einrückungen schwerer als klammern.
In perl macht es zuweilen sinn die Einrückungen freier zu interpretieren um die Struktur der Daten und des Codes hervorzuheben. Perltidy hat für sowas etliche switches.
Ach und obiges PHP-Beispiel sollte emacs automatisch richtig einrücken können.
Cheers
Kurt
echo $begrüßung;
Ich bin kein Gegner, ich sag nur ich hab gewöhnungsprobleme,
Vielleicht ist der Ausdruck "Gegner" mit einer zu starken negativen Bedeutung verbunden. Ich korrigiere das im Nachhinein in "Nicht-Fan".
Ach und obiges PHP-Beispiel sollte emacs automatisch richtig einrücken können.
Hmm, das wäre in meinen Augen auch wieder eine Art der Bevormundung. Das kann ungünstigenfalls dazu führen, dass man die automatische Korrektur gar nicht bemerkt, und somit noch nicht einmal mehr das urspüngliche Vorhaben erkennbar ist. So hat man möglicherweise als der nicht ursprüngliche Autor nicht nur einen Quasi-Syntaxfehler zu finden sondern auch noch die Logik zu analysieren und verstehen. Gut, das sollte nicht so schwer sein für einen geübten Programmierer, kostet aber alles Zeit.
echo "$verabschiedung $name";
Hi
Vielleicht ist der Ausdruck "Gegner" mit einer zu starken negativen Bedeutung verbunden. Ich korrigiere das im Nachhinein in "Nicht-Fan".
Faszinierter Aussenstehender!
Hmm, das wäre in meinen Augen auch wieder eine Art der Bevormundung. Das kann ungünstigenfalls dazu führen, dass man die automatische Korrektur gar nicht bemerkt, und somit noch nicht einmal mehr das urspüngliche Vorhaben erkennbar ist.
Also bei emacs mit Perl ist es bei mir so, dass ich einige Fehler gleich bemerke, weil die Indentation zu spinnen beginnt.
Wie auch immer, der OP wollte wissen, wie die Kluft zwischen Python und den anderen Scriptsprachen zustandekommt und ich meine dass solche syntaktischen Verständigungsprobleme eine beträchtliche Anfangshürde darstellen.
ciao
Kurt
Hi
Vielleicht ist der Ausdruck "Gegner" mit einer zu starken negativen Bedeutung verbunden. Ich korrigiere das im Nachhinein in "Nicht-Fan".
Faszinierter Aussenstehender!
um ein neutrales Beispiel zu bringen, ich finde lisp interessant und für meine Entwicklungsumgebung wärs nicht schlecht meinen Emacs besser erweitern zu können, was ich regelmäßig wieder versuche. Aber ich seh einfach den Code vor lauter Klammern nicht mehr...
Bye
Kurt
Hellihello Kurt,
Wie auch immer, der OP wollte wissen, wie die Kluft zwischen Python und den anderen Scriptsprachen zustandekommt und ich meine dass solche syntaktischen Verständigungsprobleme eine beträchtliche Anfangshürde darstellen.
Das ja ne lustige Wendung im Erklärungsansatz, aber sicherlich könnte das eine Hürde sein, dass Leute dann schlicht die Finger davon lassen. Immerhin gibts aber eine neue Python-Version laugt "IX" (das habe ich erst gestern gelesen) und Python ist die Programmiersprache auf dem 100-Dollar-Laptop.
Vielfältiges Sprachengewirr. Dass Zend wirtschaftliche Interessen vielleicht auch deshalb verfolgt, weil Sie ihre IDE unterbringen wollen (mittlerweile auch auch Plugin für Eclypse) macht deren Engagement ja verständlich. Bei Python las ich noch, dass Sie eine andere Lizenz haben, und deshalb die Sprache u.U. für professionelle Programmierungen aus ökonomischer Sicht interessanter sein könnte?
Dank und Gruß,
frankx
Hi
Bei Python las ich noch, dass Sie eine andere Lizenz haben, und deshalb die Sprache u.U. für professionelle Programmierungen aus ökonomischer Sicht interessanter sein könnte?
also was Python aus meiner Sicht kommerziell interessant macht sind
IronPython http://de.wikipedia.org/wiki/IronPython und
Jython http://de.wikipedia.org/wiki/Jython
Viele kommerzielle Entwickler werden schlicht kein Interesse haben ihren Code offenzulegen und deswegen viele Scriptsprachen scheuen. Wenn mans aber kompilieren kann ist man auf einer ziemlich sicheren Seite.
denk ich zumindest ich bin kein Py-Experte ...
Bye
kurt
Hellihello Kurt,
Viele kommerzielle Entwickler werden schlicht kein Interesse haben ihren Code offenzulegen und deswegen viele Scriptsprachen scheuen. Wenn mans aber kompilieren kann ist man auf einer ziemlich sicheren Seite.
denk ich zumindest ich bin kein Py-Experte ...
Ja, denkich auch. Und die Lizenz von Py spielt da auch irgendwie mit.
Dank und Gruß,
frankx
Hallo,
Bei Python las ich noch, dass Sie eine andere Lizenz haben, und deshalb die Sprache u.U. für professionelle Programmierungen aus ökonomischer Sicht interessanter sein könnte?
also was Python aus meiner Sicht kommerziell interessant macht sind
IronPython http://de.wikipedia.org/wiki/IronPython und
Jython http://de.wikipedia.org/wiki/Jython
Zu IronPython kann ich nichts sagen (ich nutze kein .NET), aber Jython kannst Du in meinen Augen aktuell komplett vergessen. Das ist noch auf dem Stand von CPython 2.2 und führt daher schon extrem viel aktuellen Python-Code (das ist v.a. wichtig, wenn man externe Pakete nutzen will) nicht mehr aus (aktuell ist CPython 2.5!). Als ich es das letzte mal probiert hatte, war's jedenfalls (zumindest für meine Zwecke) unbrauchbar.
Als Alternative zu Jython gibt's noch JPE bei dem noch länger nichts passiert ist als bei Jython und JPype, das laut Blog noch lebt, allerdings habe ich den aktuellen Sourcecode nicht zum Kompilieren bekommen (gut, ich hab's nicht wirklich probiert). JPype ist im Gegensatz zu Jython keine Implementierung von Python in Java (so wie Quercus eine PHP-Implementierung in Java ist), sondern ein Interface zwischen CPython und Java. Die Idee klingt vielversprechend, wenn's denn auch mal funktionieren würde. ;-)
Viele kommerzielle Entwickler werden schlicht kein Interesse haben ihren Code offenzulegen und deswegen viele Scriptsprachen scheuen. Wenn mans aber kompilieren kann ist man auf einer ziemlich sicheren Seite.
Python kann man grundsätzlich kompilieren, das macht Python sogar von selbst. Wenn Du irgend ein Modul einbindest, dann wird das aus Performance automatisch als Bytecode in einer *.pyc-Datei abgelegt. Das wäre also nicht unbedingt das Problem.
Allerdings: Jython hat die Möglichkeit, Python in Java-Bytecode zu kompilieren, der direkt auf der JVM ausgeführt wird, was für sich genommen bereits durchaus ne nette Idee ist. JPype kann das selbstverständlich nicht, weil's nur ein Interface zu CPython ist, das wäre der Nachteil davon.
Viele Grüße,
Christian
Hallo,
Zu IronPython kann ich nichts sagen (ich nutze kein .NET), aber Jython kannst Du in meinen Augen aktuell komplett vergessen. Das ist noch auf dem Stand von CPython 2.2 und führt daher schon extrem viel aktuellen Python-Code (das ist v.a. wichtig, wenn man externe Pakete nutzen will) nicht mehr aus (aktuell ist CPython 2.5!). Als ich es das letzte mal probiert hatte, war's jedenfalls (zumindest für meine Zwecke) unbrauchbar.
da gibst AFAIK einen direkten Zusammenhang, die "Microschufte" haben den Jython-Entwickler eingekauft um IronPython zu machen ...
Als Alternative zu Jython gibt's noch ...
Ähm und Psyco http://psyco.sourceforge.net/introduction.html? JIT-Compiler ähnlich Parrot!
Der Entwickler ist jetzt by PyPy aktiv...
Python kann man grundsätzlich kompilieren, das macht Python sogar von selbst. Wenn Du irgend ein Modul einbindest, dann wird das aus Performance automatisch als Bytecode in einer *.pyc-Datei abgelegt. Das wäre also nicht unbedingt das Problem.
Na aber ich vermute man hat trotzdem das gleiche Problem wie bei Perl, dass man mit vertretbarem Aufwand den Code mit Reverse Engineering doch wieder rekonstruieren kann.
(Keine Ahnung in wie weit das auch für Java-Bytecode gilt.)
Bye
Kurt
Moin Moin!
Eben las ich einen Vergleich von Perl und Python an. Python ist scheinbar genauso praktisch zu handhaben, erlaubt sogar die Einbindung von C, wenn das performatorisch nötig scheint.
Perl kann das durchuaus auch, typischerweise per XS, wer's mag, darf aber auch Perl mit C, C++, Java und ein paar andere mischen -- direkt im Quelltext.
Oft ist Perl-Code nicht wesentlich langsamer als C-Code, gelegentlich sogar schneller.
Alexander
Hi
Oft ist Perl-Code nicht wesentlich langsamer als C-Code, gelegentlich sogar schneller.
schön wärs, aber ...
"There are a number of factors explaining the lack of significant difference between C and Perl OpenGL performance:
* POGL is a compiled C module
* Most of the work is performed by the GPU
* POGL leverages OpenGL::Array (OGA) objects "
Gruß
Kurt