Das deutsche Python-Forum

lunar hat geschrieben:Wenn zwei Drittel des Teams Python nicht können, ist es auch nicht sinnvoll, Python zu nutzen.

Und wenn einer im Urlaub ist und der andere erkrankt, dann kann auf einmal das ganze Team Python.

Wollte sagen: man kann es auch so formulieren, dass ja nur 1 Mann mehr auf Python umsteigen müsste, als auf Perl umsteigen muss.
Außerdem geht aus den in diesem Thread schon genannten Quellen eindeutig hervor, dass Python übersichtlicher und vor allem in OOP mächtiger und komfortabler ist als Perl bzw. dass Perl für große, integrierte Projekte herzlich schlecht geeignet ist.

Wenn jemand der Meinung ist, dass Perl in diesen Punkten ansatzweise an Python herankommt, möge er bitte Beispiele nennen.

snafu hat geschrieben:@pgarcia: Wie kommst du darauf, dass Perl langsam ausstirbt?

Deswegen: http://www.ohloh.net/languages/compare? ... s&percent=

@Michael Schneider: Ob diese Quellen die "Überlegenheit" von Python bzw. die mangelnde Eignung von Perl wirklich so eindeutig zeigen, sei mal dahingestellt. Fakt ist, dass "Übersichtlichkeit" und "Wartbarkeit" keine sprachimmanenten Eigenschaften sind, sondern eben vor allem von der Erfahrung und dem Können des Programmierers abhängen. Ein Umstieg auf eine andere Sprache führt nicht zwangsläufig zu besserem Quelltext, selbst wenn man eine Überlegenheit dieser Sprache annimmt. Im Gegenteil, in einer unbekannten Sprache schreibt man selten sofort guten Quelltext. Die Einarbeitungszeit sollte man nicht unterschätzen. Bei einem kleinen Projekt zählt sich das kaum aus, vor allem, wenn man bedenkt, dass nur ein Python-Programmierer zur Überprüfung des Quelltexts der anderen Programmierer zur Verfügung steht.

@pgarcia: Die Statistik zeigt nur, dass im Verhältnis weniger Leute zu Perl-Projekte auf Ohloh beitragen als zu Python-Projekten. Ob das allerdings daran liegt, dass Perl ausstirbt, oder dass andere Sprache an Popularität gewonnen haben, geht aus dieser Statistik so nicht hervor. Die Statistik über die absoluten Werke (Klick auf "values") zeigt allerdings, dass die Anzahl der Mitarbeiter an Perl-Projekten sogar gestiegen ist, so dass von Aussterben eigentlich keine Rede sein kann (zumindest mit dieser Statistik als Argument).

Ob Perl noch eine Zukunft hat, wird oft diskutiert, z.B.:

http://www.perlmonks.com/?node_id=561229
http://contentment.org/2008/04/perl-is- ... -away.html

usw.. Tatsache ist, daß gerade im Linux-Bereich sehr viel Perl-Code für Systemverwaltungsaufgaben verwendet wird. Es gibt auch allerhand Perl-Spezialisten, die sich sehr gut mit dem CPAN auskennen, also massiv Module einbinden können und so sehr schnell erstaunliche Sachen vollbringen. Das machen die nach wie vor.
Aber man sieht auch Schwächen von Perl5, deshalb die (Neu-)Entwicklung von Perl6.

Ich sehe Python eigentlich als "sauberes Perl", das dann das "echte" Perl eben verdrängt (-> Killer-Applikation).
Schade für Perl, ich mag es eigentlich sehr, aber wenn ich nicht "if(){}" oder $a, @a, $_ schreiben muß, dann tu' ich's auch nicht. ist doch z.B. echt gruselig. Das versteht so doch kein Mensch, wenn er's nicht gelernt hat. Die einfachen Fälle der Textbearbeitung sind in Python also nun wirklich eleganter gelöst. Echt schwach ist auch die "plattgedrückte" Argumentübergabe an Funktionen mit @_. Am Anfang jeder Funktion muß man da erstmal die Argumente einzeln rausziehen. Python zeigt (mal wieder), daß das nicht nötig wäre.
Nee, nee, ich komm' von Perl, und (das meiste von) Python zu lernen, war extrem einfach und ging sehr schnell. Hatte eigentlich nur Vorteile. Es gab auch fast nichts, was ich vermißt hätte, denn mit "import re" gibt's ja z.B. auch RegExes, wenn man sie denn tatsächlich mal braucht. Wenn man auf Python umsteigt, braucht man also auf kaum etwas (eigentlich auf nichts) zu verzichten. Man gewinnt eigentlich nur, bis auf vielleicht bei der Geschwindigkeit. Aber so der Renner ist Perl-Code ja nun auch nicht, also gibt sich auch das nicht viel.

Allerdings habe ich bislang Perl-Leute toleranter und aufgeschlossener erlebt als Python-Nutzer. Das könnte an Perls "TMTOWTDI"-Philosophie liegen.

import this hat geschrieben:There should be one-- and preferably only one --obvious way to do it.

Das fördert offenbar nicht gerade Toleranz und Mitmenschlichkeit, sondern einige scheinen dann zu glauben, nur sie hätten den allein seelig machenden Weg, den "one and only way".

Aber das dürfte nicht das Problem bei einem internen Software-Projekt sein.

Gruß

problembär hat geschrieben:

Code: Alles auswählen

$a =~ s/x/u/g;

ist doch z.B. echt gruselig. Das versteht so doch kein Mensch, wenn er's nicht gelernt hat. Die einfachen Fälle der Textbearbeitung sind in Python also nun wirklich eleganter gelöst. Echt schwach ist auch die "plattgedrückte" Argumentübergabe an Funktionen mit @_. Am Anfang jeder Funktion muß man da erstmal die Argumente einzeln rausziehen. Python zeigt (mal wieder), daß das nicht nötig wäre.

Wenn er es nicht gelernt hat, jup. Ich möchte aber auch nicht mit jemanden an einem Projekt arbeiten, der die Sprache nicht kennt und Erfahrung hat.
Klar macht Python von der Sprache her vieles richtiger, allerdings ist Perl nun auch ne ganze Ecke älter und die meisten Schwachpunkte lassen sich mittlerweile gut ausmerzen. Als Beispiel sei Moose für die Objektorientierung genannt.
Ich benutz jedenfalls Perl und Python, Perl vorrangig für Aufgaben, bei denen ich quasi nur ein paar CPAN-Module zusammenklebe und Python für Projekte mit mehr Eigenarbeit.

Und wie schon gesagt: Perl stirbt nicht aus, es werden nur ein paar andere Sprachen schneller verbreitet

Es wäre sicherlich eine strategische Frage, ob man als Unternehmen in Zulunft auf Python setzen will. Aber dafür muss man sicherlich den Programmierern längerfirstig die Chance geben, sich langsam in Python einzuarbeiten. (Oder eben auf BWLer Art die bisherigen entlassen und neue Python-Fachkräfte holen ...)

Gleich mit einem großen Projekt mit einer neuen Sprache starten, halte ich auch eher für gewagt.

Generell sieht man das ja bei großen Software-Projekten auch. Im PDMS Umfeld wird heutzutage viel auf Java oder C# gesetzt; es gibt aber noch genügend Core-Komponenten, die in C++ umgesetzt worden sind und immer noch Verwendung finden. Da stellt man eben langsam um.

Ein re-write einer vorhandenen Software mit 3 Mann würde ich nicht als 'großes Projekt' bezeichnen. Eigentlich genau die richtige Projektgröße für eine neue Sprache. Auch, da bei einem re-write ja üblicherweise kein sooo großer Zeitdruck besteht.