Noch zwei weitere Anmerkungen.
1. Ich schaue öfters mal beim Tiobe Index vorbei und wenn man dem Glauben schenken darf, dann ist Python auch relativ gut positioniert, zumindest was die Verbreitung betrifft. Aber das ist wohl nicht wirklich Aussagefähig, da dort auch Sprachen zu finden sind, die ich eher zum Bereich "nicht mehr auf der Höhe der Zeit" zähle.
Wen es interessiert:
http://www.tiobe.com/index.php/content/ ... index.html
2. Welche Entwicklungsumgebung ist für Python zu empfehlen?
Ich orientiere mich da sehr gerne an kleineren Umgebungen und für Python selbst habe ich noch keine Auswahl gefunden, die mich zufrieden stellt.
Hier auf dem Windows Rechner schreibe ich bisher alles in einem simplen Editor (Notepad ++) und übersetze dann einfach auf Kommandozeile, ab und zu nutze ich auch IDLE (was mir nicht sooo gut gefällt) und auch für Eclipse habe ich mir das Python Plugin besorgt (Installation war relativ unkompliziert), aber mir persönlich ist Eclipse zu schwerfällig.
Unter Linux habe ich etwas mehr Auswahl (dort habe ich auch die ERIC Umgebung) und diverse andere Editoren.
Unter Mac OS X schreibe ich meisstens alles auch nur im Editor oder direkt in X-CODE, was auch wirklich gross und umfangreich ist, aber für mich zu meinen Lieblings-Entwicklungsumgebungen zählt. Dort schreibe ich auch gerne C mit.
Na ja, also zum Vergleich, um eine vernünftige Umgebung für Windows zu finden:
Unter meinem Win XP habe ich z.B. für C/C++ die Umgebung von Bloodshed am laufen.
(http://www.bloodshed.net/dev/devcpp.html)
Natürlich ist das ganze nicht so umfangreich wie z.B. Visual Studio 6 (oder 5), aber mir gefällt es deutlich besser, da es ein Leichtgewicht ist, genau das tut (und das auch sehr gut) was es soll und mir völlig reicht.
Es ist Open Source und macht auch wirklich Spass.
Sowas in der Richtung suche ich auch für Python.
ne0h
Was bietet mir Python und was nicht ?
Hier möchte ich dann aber mal für Perl eintreten!ne0h hat geschrieben:Wirklich viele Alternativen kristallisieren sich hier nicht heraus und in Punkto Struktur, Flexibilität, Plattformunabhängigkeit, schneller Entwicklung und Bibliotheksumfang sehe ich IMHO keine gleichwertige Konkurrenz zu Python (jedenfalls bis jetzt nicht).
Perl ist toll, hat eine sehr gute Unterstützung von OOP und Funktionaler Programmierung, lässt sich sehr flüssig schreiben, hat eine unglaublichumfngreiche und tolle Bilbiothek (will ich auch für Python.. :/ ) und flexibler als Python.
Es ist eben...anders. Ich fühle mich bei Python auch heimischer, bin allerdings ebenso begeistert von Perl. Vor allem das CPAN erleichtert einem das Leben sehr, ebenso der Verzicht auf Grenzen. In Perl kann man absolut grausamen Code schreiben, allerdings ebenso in jeder anderen Sprache. Was mir an Python Code bisher so untergekommen ist war nicht wirklich immer schön und verständlich.
Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
Dafür geben Django und RoR dem Entwickler die Struktur vor, so dass er sich nicht mehr Gedanken um eine sinnvolle Trennung der einzelnen Komponenten machen muss. Das ist in manchen Fälle sehr hinderlich, da man einzelne Teile einer solchen Anwendung nicht herauslösen kann, für viele Webanwendung allerdings genug.
Ich selbst mag Django, weil man damit schnell zu Ergebnissen kommt, ohne allzu viel nachdenken zu müssen. Ich weiß aber auch, wo die Schwächen und Grenzen von Django liegen.
Zumal das freie Entwickeln ohne feste Vorgaben eines Frameworks ein hohes Maß an Disziplin und Erfahrung erfordert. In diesem Fall ist der Programmierer nämlich für die Trennung der Komponenten verantwortlich, und sowas kann auch katastrophal schief gehen. Man braucht schon ein gewisses Maß an Erfahrung, Disziplin und Erfahrung, um die Vorteile von werkzeug oder paste gegenüber Django oder RoR wirklich auszunutzen, und nicht jeder hat diese Erfahrung.
Zumal Java-Webentwickler sich eher in RoR und Django wiedererkennen dürften, wo vieles fest vorgegeben ist, so wie in den meisten Java-Webframeworks auch.
Ich selbst mag Django, weil man damit schnell zu Ergebnissen kommt, ohne allzu viel nachdenken zu müssen. Ich weiß aber auch, wo die Schwächen und Grenzen von Django liegen.
Zumal das freie Entwickeln ohne feste Vorgaben eines Frameworks ein hohes Maß an Disziplin und Erfahrung erfordert. In diesem Fall ist der Programmierer nämlich für die Trennung der Komponenten verantwortlich, und sowas kann auch katastrophal schief gehen. Man braucht schon ein gewisses Maß an Erfahrung, Disziplin und Erfahrung, um die Vorteile von werkzeug oder paste gegenüber Django oder RoR wirklich auszunutzen, und nicht jeder hat diese Erfahrung.
Zumal Java-Webentwickler sich eher in RoR und Django wiedererkennen dürften, wo vieles fest vorgegeben ist, so wie in den meisten Java-Webframeworks auch.
Ich programmiere kein Perl, aber wenn ich mir so den Code des Perlmeisters im Linux-Magazin anschaue, sieht OOP in Perl ein bisschen abstrus aus.audax hat geschrieben:Perl ist toll, hat eine sehr gute Unterstützung von OOP
Ich habe noch nichts gefunden, was es für Python nicht geben würde...hat eine unglaublichumfngreiche und tolle Bilbiothek (will ich auch für Python.. :/ )
Wie hat jemand im [url=http://forum.ubuntuusers.de/post/127069 ... sers-Forum[/url] doch so schön gesagt: Timtowtdi ist kein Konzept, sondern der Mangel desselben.flexibler als Python.
Es gibt viele Leute, die mir zustimmen würden, wenn ich sage, dass Flexibilität im Bezug auf Perl mehr Nachteil denn Vorteil ist.
Die Unterschiede in der Syntax und Semantik sind jedenfalls ziemlich groß...Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
Eben. Du programmierst kein Perl. Ich kann kein C und für mich sieht nahezu jeglicher C-Code unglaublich wirr aus, das ist also kein gutes Argument.lunar hat geschrieben:Ich programmiere kein Perl, aber wenn ich mir so den Code des Perlmeisters im Linux-Magazin anschaue, sieht OOP in Perl ein bisschen abstrus aus.audax hat geschrieben:Perl ist toll, hat eine sehr gute Unterstützung von OOP
Auch in der Qualität? Wenn ich mir da Module wie BeautifulSoup anschaue...Ich habe noch nichts gefunden, was es für Python nicht geben würde...hat eine unglaublichumfngreiche und tolle Bilbiothek (will ich auch für Python.. :/ )
Vor allem stört mich bei Python die dämliche Bennenung der Module, da ist Perl wesentlich organisierter. Durch den Cheeseshop und das Tagging gehts mittlerweile halbwegs, aber auch große Teile der Module, die dort rumschwirren sind ziemlich unreif.
Aber ich gebs zu, das Argument der großen Bibliothek ist mittlerweile nicht mehr ganz so stark, da holt Python gut auf,
Es gibt auch viele PHP-Programmierer...Wie hat jemand im Ubuntuusers-Forum doch so schön gesagt: Timtowtdi ist kein Konzept, sondern der Mangel desselben.flexibler als Python.
Es gibt viele Leute, die mir zustimmen würden, wenn ich sage, dass Flexibilität im Bezug auf Perl mehr Nachteil denn Vorteil ist.
Und hier widerspreche ich dir einfach mal komplett. Perl hat weniger syntaktischen Zucker, dafür mehr Freiheiten. Perl braucht keine List-Comprehensions, keine extra Generator Syntax, das funzt auch ganz gut so.Die Unterschiede in der Syntax und Semantik sind jedenfalls ziemlich groß...Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
List Comprehensions z.B. werden in Perl durch inline-for-Schleife gemacht, was für mich nicht weniger eindeutig ist und im Prinzip auch das gleiche in Grün.
Weil so etwas in Python nach den Grundprinzipien der Lesbarkeit und Einfachheit gar nicht zu Debatte steht wurden erst die LC eingeführt.
Ich sage hier nicht, dass Python unterlegen ist, Python ist ja immerhin die Sprache meiner Wahl.
Hier möchte ich dann aber mal für Perl eintreten!
Perl ist toll, hat eine sehr gute Unterstützung von OOP und Funktionaler Programmierung, lässt sich sehr flüssig schreiben, hat eine unglaublichumfngreiche und tolle Bilbiothek (will ich auch für Python.. :/ ) und flexibler als Python.
Es ist eben...anders. Ich fühle mich bei Python auch heimischer, bin allerdings ebenso begeistert von Perl. Vor allem das CPAN erleichtert einem das Leben sehr, ebenso der Verzicht auf Grenzen. In Perl kann man absolut grausamen Code schreiben, allerdings ebenso in jeder anderen Sprache. Was mir an Python Code bisher so untergekommen ist war nicht wirklich immer schön und verständlich.
Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
Hi,
wenn ich Perl und Python so vergleiche fallen, jedenfals mir persönlich, schon einige gravierende Unterschiede ein.
Perls OOP-Konzept ist mir persönlich nicht wirklich gelegen und zudem habe ich nicht nur ein Mal herbe Kritik am OOP-Konzept von Perl gelesen/gehört.
Ich finde dort den Objektorientierten Ansatz nicht so wieder, wie ich Ihn kenne und vor allem gelernt habe.
Die Bibliotheken in Perl sind, da hast Du auch völlig recht, sehr umfangreich.
Nur kann ich nicht sagen, dass mir die Flexibilität in Perl jemals wirklich geholfen hat. Ich habe meine ersten Schritte in der Welt der Programmierung mit Pascal/Delphi gemacht und unabhängig von der typisierten Konzeption jener Sprache(n), habe ich in Perl bisher nie so saubere Programme gefunden....
Aber auch das mag nur daran liegen, dass die Perl Programme, die ich mir angesehen habe, von sehr schlechten Programmierern verfasst wurden.
Deshalb möchte ich Perl hier auch nicht schlecht machen, mir liegt nichts an einer Denunziation einer Programmiersprache. Es "liegt" mir nur einfach nicht gut, ich fühle mich zu Perl nicht wirklich hingezogen.
Auch sehe ich keine wirkliche Ähnlichkeit in so großem Maße zwischen Python und Perl, wobei Python ja mit Einflüssen von Perl entwickelt wurde. Mir scheintes jedoch, dass Python gewisse Konzepte einfach direkter und "natürlicher" umsetzt.
Das findet sich auch darin wieder, dass nicht gerade wenige Leute sagen, dass Python tatsächlich so funktioniert, wie man es erwartet und nicht eben "unkontrolliert" oder auch "unnatürlich". Wobei "unnatürlich" vielleicht etwas missdeutig ist. Ich verstehe darunter einfach, dass meine Gedanken beim Aufbau eines Programms, sprich der Programmlogik, in Python einfacher und direkter umgesetzt werden können, einfach so, wie ich es eben erwarte.
Trotz dessen finde auch ich Perl interessant und habe schon das eine oder andere Skript mit Perl realisiert, dass mir gute Dienste geleistet hat. Das gute Gefühl gibt es mir dennoch nicht.
ne0h
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
TIOBE ist bekannt - ich halte davon aber nicht viel, bis hin zu gar nichts.ne0h hat geschrieben:1. Ich schaue öfters mal beim Tiobe Index vorbei und wenn man dem Glauben schenken darf, dann ist Python auch relativ gut positioniert, zumindest was die Verbreitung betrifft. Aber das ist wohl nicht wirklich Aussagefähig, da dort auch Sprachen zu finden sind, die ich eher zum Bereich "nicht mehr auf der Höhe der Zeit" zähle.
In Python benutzt man eher Editoren als IDEs. Da gibt es einen Thread dazu im Forum. Vim und Emacs sind aber eine gute Wahlne0h hat geschrieben:2. Welche Entwicklungsumgebung ist für Python zu empfehlen?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das Perl-Denken ist eben völlig anders, der OOP Ansatz wird allerdings nur auf den ersten Blick etwas verstörend. Wegen dieses schlimmen ersten Eindruck wird die Syntax dafür in Perl 6 übrigens auch geändert, ebenso wird dafür syntaktischer Zucker eingefügt
So sehen dann übrigens Generatoren und "LC" in Perl aus (wobei ich jetzt kein Perl-Profi bin ):
Ist natürlich weniger syntaktischer Zucker, aber doch eigentlich nicht weniger verständlich.
So sehen dann übrigens Generatoren und "LC" in Perl aus (wobei ich jetzt kein Perl-Profi bin ):
Code: Alles auswählen
#!/usr/bin/perl
use strict;
use warnings;
sub say { print "@_" . "\n"; }
my $iter = range(1, 10, 2);
my @list;
while (my $number = $iter->()) { push @list, $number };
say "@list";
say map {$_ + 10} @list;
sub range {
my ($from, $to, $step) = @_;
$from -= $step;
return sub {
$from += $step;
return $from < $to ? $from : undef
};
}
Objective C totzusagen halte ich für verfrüht. Klar, die Sprache (von NextStep kommend) ist nur auf dem Mac verbreitet, doch dort ist sie der Standard und wer für das iPhone oder den iPod Touch entwickeln will, kommt daran nicht vorbei, da es (wenigstens zur Zeit) die einzige Wahl ist. Und da (zumindest in den Mac-begeisterten USA) der Marktanteil von Apple stetig steigt, wird es auch immer mehr Bedarf an echten Mac-Anwendungen geben. Und Cross-Plattform, darauf stehen Mac-Anwender eher nicht.
Ich kann mir daher nicht vorstellen, dass man mit Qt und C++ schneller gute GUI-Anwendungen für den Mac entwickeln kann als mit Cocoa und Objective C - allerdings ist das eher ein Vorurteil als durch eigene Erfahrung begründet. Aber auch Objective-C wirkt irgendwie total primitiv... PyObjc ist aber auch Mist, da es die Nachrichten verhunzt. MacRuby könnte eine interessante Alternative werden...
Obwohl, man könnte mit python4ply mal eine Python-Variante bauen, die zumindest syntaktisch Schlüsselwort-Nachrichten vernünftig abbildet. Das ganze auf Objective-C 2 mit dessen GC basieren zu lassen, wie es der Ansatz von MacRuby ist, klingt aber besser.
Oder man (irgendwer, ich wohl nicht) baut ein neues Python in Objective-C from scratch. Vielleicht reicht es, wenn es ein Subset ist. Statt C-Extensions kann man dann direkt auf Cocoa-Bibliotheken zugreifen. Eigentlich ist Python ja keine so umfangreiche Sprache - leider steckt der Teufel in der Meta-Ebene.
Vala - das habe ich noch nie gehört und kann es mir leider auch nicht anschauen, da wohl live.gome.org gerade tot ist. Aber ist die Sprache wirklich nach Claudia Black (sie spielte eine Vala bei Stargate) benannt?! Braucht man noch eine weitere Sprache? Auch C++ (C with classes) und Objective-C hatten ja mal als Präprozessoren für C angefangen. Ist Vala auch einer? Das Vala keine Laufzeitbibliothek haben will bedeutet doch wohl, dass es keine automatische Speicherverwaltung gibt. Das erscheint mir dann schon sehr primitiv und als etwas, mit dem zumindest ich mich im 3. Jahrtausend eigentlich nicht mehr auseinandersetzen will.
ne0h, du schreibst, du willst Python mit den Rest verglichen wissen. Wie? Indem es heißt, Python ist schneller als Ruby und langsamer als Java? Oder indem wir aufzählen, was für Bibliotheken es gibt? Oder welches die Vorzeigeanwendungen (für Python vielleicht Zope, allerdings ist mir das zu nahe an JavaEE dran) sind? Konkrete Fragen kann man leichter beantworten.
Zu den Rahmenwerken: Dem einen gefällt es, wenn das Rahmenwerk eine Struktur vorgeben (wie es Django und Rails machen), dem anderen, wenn man selbst basteln kann. Ich finde Struktur und Vorauswahl wichtig, weil auf diese Weise auf in einem Team ohne weitere Konventionen klar ist, was wie gemacht wird. Es ist häufig mein Eindruck, dass die sehr flexiblen Lösungen gerade von "Einzelkämpfern" propagiert werden.
Soll ich Rails und Django vergleichen, dann hat Rails den flexibleren und mächtigeren ORM und hat außerdem das Konzept von Datenbank-Migrationen, das bei Django fehlt. Dessen ORM ist primitiv, für einfache CMS-Aufgaben aber ausreichend. Sich mit etwas wie sqlalchemy (dem Hibernate von Python) erst auseinandersetzen zu müssen ist in diesem Kontext häufig unnötig. Und was dort einige als Vorteil sehen, ist für mich eher ein Nachteil: Das Ding ist mir zu low-level. Es braucht weitere Bibliotheken, um dahin zu kommen, wo ich es benutzen will.
Die unterschiedliche Mentalität kommt vielleicht auch durch das Betriebssystem: Ich will eine Installation, mit der ich dann alles machen. Ich will nicht - wohlmöglich manuell - verschiedene Bibliotheken selbst installieren. Linux-Anwender sind glaube ich bibliotheksaffiner und haben kein Problem damit, dieses und jedes zu installiert (meist ja mit apt-get und co. auch recht einfach).
Auf eine Django-Schulung angesprochen sagte ich, dass ich nur Python 2.5 bräuchte und den Rest als ZIP auf einem USB-Stick mitbringen würde. Ich stieß auf Unglaube, da die Linux-Fraktion irgendwie stundenlang vorher noch Webserver und Datenbanken installieren wollte - jedenfalls nicht erwartet hat, dass einmal kopieren ausreichen würde.
Übrigens etwas, das mir auch bei Java gefällt: Wenn Java installier ist, kann man Webserver, Datenbank, alles andere unter Java betreiben und einfach und plattformübergreifend betreiben.
Was mich an Django übrigens total stört ist, dass die Kernentwickler einfach nicht voran kommen und das newforms-admin- und das queryset-refactor-Seitenprojekt seit Monaten (wenn es nicht schon Jahre sind) vor sich hindümpelt. Schön, dass die ihre trunk-Version stabil halten wollen, aber wenn sie stattdessen sagen wir alle 3 Monate ein Release machen würden, dann könnte man auch man den trunk zweitweilig instabil machen und Änderungen schneller und mehr im Bewußtsein der Community durchführen, auf dass es vielleicht mehr Leute gibt, die Mitmachen würden. So heißt es aber immer, "wartet noch, bis wir's fertig haben" und das ist IMHO total kontraproduktiv. Ich bin jedenfalls eher abgeschreckt als bereit da mitzuarbeiten.
Was ich bei Python allgemein nicht so gut finde, bzw. bei Ruby und Rails bewundere ist, dass dort alle an einem Strang ziehen und ein Rahmenwerk vorantreiben. Rails ist noch nicht so alt wie Django und dennoch deutlich fortschrittlicher. Natürlich verliert so ein Rahmenwerk dann auch irgendwann seine Unschuld und ist so komplex, dass der Ruf nach etwas einfacherem laut wird. Merb ist vielleicht die Antwort auf so einen Ruf und ich finde Rails inzwischen deutlich komplizierter. Als ich das 2005 studiert hatte, war es noch wesentlich leichter zu verstehen. So wie Django jetzt... Ich glaube, Python-Entwickler sind eher Individualisten (um nicht Eigenbrödler zu sagen), was mich ein bisschen beunruhigt, denn dann ist das nicht die richtige Sprache, um sie in der Firma einzuführen.
Durch Rails hat Ruby auch den Vorteil, dass insbesondere Hersteller von Java-IDEs aufmerksam geworden sind (den laufen gefühlt die Entwickler weg; real glaube ich ist da keine große Abwanderung) und sie investieren in Ruby-IDEs. Aufmerksamkeit von der "Industrie" ist nicht so falsch.
Bei Python ist das total dürftig. Ähnlich wie bei Webrahmenwerken ist es so, dass jeder glaubt, sich selbst eine IDE zu bauen, die besser ist, als die ganzen anderen halbfertigen Lösungen und erzeugt eine weitere halbfertige... Schon der Kleinkrieg zwischen den verschiedenen UI-Rahmweken, die man benutzen könnte, sorgt für eine unschöne Verdopplungen. Relativ mächtig ist wohl Eric, aber da der Autor keine unter Windows installierbare Version zur Verfügung stellen kann/will, wird er auch mich nicht als Kunden gewinnen. Ich habe mich mit einer Kombination aus vim bzw. TextMate und KomodoEdit abgefunden. Doll ist das aber alles nicht. Ein gescheiter Debugger wäre schon nett. Zugegeben bin ich dann auch zu geizig, mit Komodo oder WingIDE zu kaufen. Aber hey, von Java bin ich nur die besten IDEs zum 0-Preis gewohnt.
Für Ruby und Rails ist übrigens IMHO Netbeans Klasse. Für Java setzte ich zwar nicht auf diese IDE und tue mich daher schwer, extra für Ruby zu wechseln und würde eigentlich lieber bei Eclipse bleiben, doch das wird auch immer fetter und insbesondere auf dem Mac sieht das einfach hässlich aus. Nicht das XCode jetzt so schick wäre... aber irgendwie hätte ich gerne etwas, das in Ästhetik und Bedienung hübsch und praktikabel ist und dann auf Mac und Windows funktioniert (Linux ist mir recht egal).
Also: Viel Text, wenig Botschaft. Ohne den Anwendungszweck zu kennen, ist das alles eh aus der Historie eingefärbter persönlicher Geschmack, was nun gut ist oder nicht.
Stefan
Ich kann mir daher nicht vorstellen, dass man mit Qt und C++ schneller gute GUI-Anwendungen für den Mac entwickeln kann als mit Cocoa und Objective C - allerdings ist das eher ein Vorurteil als durch eigene Erfahrung begründet. Aber auch Objective-C wirkt irgendwie total primitiv... PyObjc ist aber auch Mist, da es die Nachrichten verhunzt. MacRuby könnte eine interessante Alternative werden...
Obwohl, man könnte mit python4ply mal eine Python-Variante bauen, die zumindest syntaktisch Schlüsselwort-Nachrichten vernünftig abbildet. Das ganze auf Objective-C 2 mit dessen GC basieren zu lassen, wie es der Ansatz von MacRuby ist, klingt aber besser.
Oder man (irgendwer, ich wohl nicht) baut ein neues Python in Objective-C from scratch. Vielleicht reicht es, wenn es ein Subset ist. Statt C-Extensions kann man dann direkt auf Cocoa-Bibliotheken zugreifen. Eigentlich ist Python ja keine so umfangreiche Sprache - leider steckt der Teufel in der Meta-Ebene.
Vala - das habe ich noch nie gehört und kann es mir leider auch nicht anschauen, da wohl live.gome.org gerade tot ist. Aber ist die Sprache wirklich nach Claudia Black (sie spielte eine Vala bei Stargate) benannt?! Braucht man noch eine weitere Sprache? Auch C++ (C with classes) und Objective-C hatten ja mal als Präprozessoren für C angefangen. Ist Vala auch einer? Das Vala keine Laufzeitbibliothek haben will bedeutet doch wohl, dass es keine automatische Speicherverwaltung gibt. Das erscheint mir dann schon sehr primitiv und als etwas, mit dem zumindest ich mich im 3. Jahrtausend eigentlich nicht mehr auseinandersetzen will.
ne0h, du schreibst, du willst Python mit den Rest verglichen wissen. Wie? Indem es heißt, Python ist schneller als Ruby und langsamer als Java? Oder indem wir aufzählen, was für Bibliotheken es gibt? Oder welches die Vorzeigeanwendungen (für Python vielleicht Zope, allerdings ist mir das zu nahe an JavaEE dran) sind? Konkrete Fragen kann man leichter beantworten.
Zu den Rahmenwerken: Dem einen gefällt es, wenn das Rahmenwerk eine Struktur vorgeben (wie es Django und Rails machen), dem anderen, wenn man selbst basteln kann. Ich finde Struktur und Vorauswahl wichtig, weil auf diese Weise auf in einem Team ohne weitere Konventionen klar ist, was wie gemacht wird. Es ist häufig mein Eindruck, dass die sehr flexiblen Lösungen gerade von "Einzelkämpfern" propagiert werden.
Soll ich Rails und Django vergleichen, dann hat Rails den flexibleren und mächtigeren ORM und hat außerdem das Konzept von Datenbank-Migrationen, das bei Django fehlt. Dessen ORM ist primitiv, für einfache CMS-Aufgaben aber ausreichend. Sich mit etwas wie sqlalchemy (dem Hibernate von Python) erst auseinandersetzen zu müssen ist in diesem Kontext häufig unnötig. Und was dort einige als Vorteil sehen, ist für mich eher ein Nachteil: Das Ding ist mir zu low-level. Es braucht weitere Bibliotheken, um dahin zu kommen, wo ich es benutzen will.
Die unterschiedliche Mentalität kommt vielleicht auch durch das Betriebssystem: Ich will eine Installation, mit der ich dann alles machen. Ich will nicht - wohlmöglich manuell - verschiedene Bibliotheken selbst installieren. Linux-Anwender sind glaube ich bibliotheksaffiner und haben kein Problem damit, dieses und jedes zu installiert (meist ja mit apt-get und co. auch recht einfach).
Auf eine Django-Schulung angesprochen sagte ich, dass ich nur Python 2.5 bräuchte und den Rest als ZIP auf einem USB-Stick mitbringen würde. Ich stieß auf Unglaube, da die Linux-Fraktion irgendwie stundenlang vorher noch Webserver und Datenbanken installieren wollte - jedenfalls nicht erwartet hat, dass einmal kopieren ausreichen würde.
Übrigens etwas, das mir auch bei Java gefällt: Wenn Java installier ist, kann man Webserver, Datenbank, alles andere unter Java betreiben und einfach und plattformübergreifend betreiben.
Was mich an Django übrigens total stört ist, dass die Kernentwickler einfach nicht voran kommen und das newforms-admin- und das queryset-refactor-Seitenprojekt seit Monaten (wenn es nicht schon Jahre sind) vor sich hindümpelt. Schön, dass die ihre trunk-Version stabil halten wollen, aber wenn sie stattdessen sagen wir alle 3 Monate ein Release machen würden, dann könnte man auch man den trunk zweitweilig instabil machen und Änderungen schneller und mehr im Bewußtsein der Community durchführen, auf dass es vielleicht mehr Leute gibt, die Mitmachen würden. So heißt es aber immer, "wartet noch, bis wir's fertig haben" und das ist IMHO total kontraproduktiv. Ich bin jedenfalls eher abgeschreckt als bereit da mitzuarbeiten.
Was ich bei Python allgemein nicht so gut finde, bzw. bei Ruby und Rails bewundere ist, dass dort alle an einem Strang ziehen und ein Rahmenwerk vorantreiben. Rails ist noch nicht so alt wie Django und dennoch deutlich fortschrittlicher. Natürlich verliert so ein Rahmenwerk dann auch irgendwann seine Unschuld und ist so komplex, dass der Ruf nach etwas einfacherem laut wird. Merb ist vielleicht die Antwort auf so einen Ruf und ich finde Rails inzwischen deutlich komplizierter. Als ich das 2005 studiert hatte, war es noch wesentlich leichter zu verstehen. So wie Django jetzt... Ich glaube, Python-Entwickler sind eher Individualisten (um nicht Eigenbrödler zu sagen), was mich ein bisschen beunruhigt, denn dann ist das nicht die richtige Sprache, um sie in der Firma einzuführen.
Durch Rails hat Ruby auch den Vorteil, dass insbesondere Hersteller von Java-IDEs aufmerksam geworden sind (den laufen gefühlt die Entwickler weg; real glaube ich ist da keine große Abwanderung) und sie investieren in Ruby-IDEs. Aufmerksamkeit von der "Industrie" ist nicht so falsch.
Bei Python ist das total dürftig. Ähnlich wie bei Webrahmenwerken ist es so, dass jeder glaubt, sich selbst eine IDE zu bauen, die besser ist, als die ganzen anderen halbfertigen Lösungen und erzeugt eine weitere halbfertige... Schon der Kleinkrieg zwischen den verschiedenen UI-Rahmweken, die man benutzen könnte, sorgt für eine unschöne Verdopplungen. Relativ mächtig ist wohl Eric, aber da der Autor keine unter Windows installierbare Version zur Verfügung stellen kann/will, wird er auch mich nicht als Kunden gewinnen. Ich habe mich mit einer Kombination aus vim bzw. TextMate und KomodoEdit abgefunden. Doll ist das aber alles nicht. Ein gescheiter Debugger wäre schon nett. Zugegeben bin ich dann auch zu geizig, mit Komodo oder WingIDE zu kaufen. Aber hey, von Java bin ich nur die besten IDEs zum 0-Preis gewohnt.
Für Ruby und Rails ist übrigens IMHO Netbeans Klasse. Für Java setzte ich zwar nicht auf diese IDE und tue mich daher schwer, extra für Ruby zu wechseln und würde eigentlich lieber bei Eclipse bleiben, doch das wird auch immer fetter und insbesondere auf dem Mac sieht das einfach hässlich aus. Nicht das XCode jetzt so schick wäre... aber irgendwie hätte ich gerne etwas, das in Ästhetik und Bedienung hübsch und praktikabel ist und dann auf Mac und Windows funktioniert (Linux ist mir recht egal).
Also: Viel Text, wenig Botschaft. Ohne den Anwendungszweck zu kennen, ist das alles eh aus der Historie eingefärbter persönlicher Geschmack, was nun gut ist oder nicht.
Stefan
Auch in der Qualität? Wenn ich mir da Module wie BeautifulSoup anschaue...[/quote]audax hat geschrieben:Ich habe noch nichts gefunden, was es für Python nicht geben würde...hat eine unglaublichumfngreiche und tolle Bilbiothek (will ich auch für Python.. :/ )
Möchtest du jetzt wirklich behaupten, dass CPAN hätte eine durchweg gute Qualität?
Ein Punkt, in dem ich dir zustimme. Allerdings halten sich mehr und mehr Bibliotheken an PEP 8.Vor allem stört mich bei Python die dämliche Bennenung der Module, da ist Perl wesentlich organisierter. Durch den Cheeseshop und das Tagging gehts mittlerweile halbwegs, aber auch große Teile der Module, die dort rumschwirren sind ziemlich unreif.
Es gibt auch viele Perl-Programmierer Die Masse allein zählt nicht, aber Namen zählen. Und man findet viele erfahrene Programmierer, die Perl kritisieren (u.a. Eric Raymond)Es gibt auch viele PHP-Programmierer...Wie hat jemand im Ubuntuusers-Forum doch so schön gesagt: Timtowtdi ist kein Konzept, sondern der Mangel desselben.
Es gibt viele Leute, die mir zustimmen würden, wenn ich sage, dass Flexibilität im Bezug auf Perl mehr Nachteil denn Vorteil ist.
Du widersprichst dir vor allem selbst, in dem du behauptest, es gäbe wenig Unterschiede, dann aber auf das Fehlen von LCs, von Generatoren, etc. hinweist,Und hier widerspreche ich dir einfach mal komplett.Die Unterschiede in der Syntax und Semantik sind jedenfalls ziemlich groß...Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
Im Übrigen finde ich deine Behauptungen angesichts der nun mal real existierenden großen syntaktischen Unterschiede zwischen Perl und Python mehr als merkwürdig.
In Python gibt es keine Präfixe für Namen, je nach dem, welcher Typ dahinter steht. In Python gibt es keine Semikolons und keine geschweiften Klammern, es gibt keine '=>' und '->' Operatoren, und auch =~ fehlt.
Pakete als Klassen zu missbrauchen, ist für mich reichlich seltsam, ebenso wie der Zwang zu Präfixzeichen für Namen. Wo liegt der Sinn in dynamischer Typisierung, wenn ich dann wieder typbezogenen Präfixe für die Namen verwenden muss?
Summa summarum mag in Perl programmieren, wer will, aber ich kann jeden verstehen, der diese Sprache seltsam oder gar schlecht findet, Ich tue das ja auch
Edit: Quotes korrigiert
Zuletzt geändert von lunar am Freitag 21. März 2008, 15:40, insgesamt 2-mal geändert.
Das hat in den letzten Jahren weder ObjC noch Win32-API totgekriegt und wird es auch nicht. Eine native Anwendung fühlt sich immer anders an, als eine mit einem Crossplatform-Toolkit. Bei Windows merkt man das bloß nicht so stark wie auf OSX weil sich da sowieso jeder seit Jahren sein eigenen Süppchen kocht.lunar hat geschrieben:Objective C ist außerhalb von OS X ziemlich total tot, und wird in Zukunft auch unter Mac immer mehr an Bedeutung verlieren, weil solche Anwendungen nur in geringen Maße portabel sind.
Ansonsten ist das schade, dass ObjC so wenig verbreitet ist, eine sehr schöne Sprache. Eine der wenigen dynamisch typisierten Sprachen(die einzige?) außerhalb der interpretierten Spachen.
Nein, aber eine riesige Auswahl von Qualitativ hochwertigen Modulen, toller Doku gleich Dabei und der Möglichkeit als einfacher Benutzer Anmekrungen in der Doku zu hinterlassen.lunar hat geschrieben:Möchtest du jetzt wirklich behaupten, dass CPAN hätte eine durchweg gute Qualität?
Python wird langsam etwas reifer \o/Ein Punkt, in dem ich dir zustimme. Allerdings halten sich mehr und mehr Bibliotheken an PEP 8.Vor allem stört mich bei Python die dämliche Bennenung der Module, da ist Perl wesentlich organisierter. Durch den Cheeseshop und das Tagging gehts mittlerweile halbwegs, aber auch große Teile der Module, die dort rumschwirren sind ziemlich unreif.
Du widersprichst dir vor allem selbst, in dem du behauptest, es gäbe wenig Unterschiede, dann aber auf das Fehlen von LCs, von Generatoren, etc. hinweist,Es gibt auch viele PHP-Programmierer...Wie hat jemand im Ubuntuusers-Forum doch so schön gesagt: Timtowtdi ist kein Konzept, sondern der Mangel desselben.
Es gibt viele Leute, die mir zustimmen würden, wenn ich sage, dass Flexibilität im Bezug auf Perl mehr Nachteil denn Vorteil ist.Er kritisiert hauptsächlich die Syntax von Perl, und die Perlsche-Ausdrucksweise. Wem die nicht liegt, der soll Perl auch ruhig links liegen lassenEs gibt auch viele Perl-Programmierer Die Masse allein zählt nicht, aber Namen zählen. Und man findet viele erfahrene Programmierer, die Perl kritisieren (u.a. Eric Raymond)Und hier widerspreche ich dir einfach mal komplett.Die Unterschiede in der Syntax und Semantik sind jedenfalls ziemlich groß...Python und Perl sind sich weitaus ähnlicher als mancher hier denkt...
Im Übrigen finde ich deine Behauptungen angesichts der nun mal real existierenden großen syntaktischen Unterschiede zwischen Perl und Python mehr als merkwürdig.
In Python gibt es keine Präfixe für Namen, je nach dem, welcher Typ dahinter steht. In Python gibt es keine Semikolons und keine geschweiften Klammern, es gibt keine '=>' und '->' Operatoren, und auch =~ fehlt.
Pakete als Klassen zu missbrauchen, ist für mich reichlich seltsam, ebenso wie der Zwang zu Präfixzeichen für Namen. Wo liegt der Sinn in dynamischer Typisierung, wenn ich dann wieder typbezogenen Präfixe für die Namen verwenden muss?
[/quote]
Ich muss zugeben, dass ich rein syntaktischen Unterschieden keine große Bedeutung zumesse. Der eingebaute Regex-Kram von Perl ist historischer Natur, die Prefixe ergen sich daraus, dass ein in Arrays und Hashes eben nur Skalare gespeichert werden können und man deshalb zwischen dem Objekt selbst und der Referenz auf das Objekt unterscheiden muss. Aus dieser Referenzsache ist dann auch der '->' entstanden, ebenso wie der '=>' nur syntaktischer Zucker.
In Perl wegen Hashes/Dicts ebenso aus Paaren erstellt und der '=>' ist nur dafür da, es hübscher aussehen zu lassen.
Die großen Unterschiede sind eigentlich nur die Handhabung der Referenzen, die in Perl ganz explizit geschieht, in Python aber hinter den Kulissen geschieht und das Verwenden von Klammern und Semikolons...
Es gibt nun mal unterschiedliche GUI-Frameworks, auch für Ruby gibt es nicht das Framework.Schon der Kleinkrieg zwischen den verschiedenen UI-Rahmweken, die man benutzen könnte, sorgt für eine unschöne Verdopplungen.
Es existieren Windows-Binaries für PyQt4, die Eric4 mitbringen. Im Übrigen dürfte es dem Autor von Eric wohl herzlichst egal sein, ob du seine IDE nun benutzt, oder nicht Zumal der Mensch wohl Linux-User ist, und ich ihn folglich verstehen kann. Ich habe auch keinen Bock, mich mit cx_freeze, pyinstaller oder py2exe herumzuschlagen, nur damit Windows-Nutzer glücklich sind. Mein Code läuft auf Linux, das reicht mir.Relativ mächtig ist wohl Eric, aber da der Autor keine unter Windows installierbare Version zur Verfügung stellen kann/will, wird er auch mich nicht als Kunden gewinnen.
Und wenn du jetzt das "ein Entwickler muss auf seine User achten"-Argument herausholen willst, oder das "es würde aber mehr User die Software nutzen"-Argument, dann lass es gleich sein. Du kannst freien Entwicklern nicht vorschreiben, was sie wie wofür zu programmieren haben. Das ist nun mal der Preis der Freiheit, den du bezahlen musst.
Die Win32-API ist aber nicht besonders lebendig. Oder kennst du ein reines Win32-API-Programm für Windows, welches wirklich noch aktiv entwickelt wird?Darii hat geschrieben:Das hat in den letzten Jahren weder ObjC noch Win32-API totgekriegt und wird es auch nicht.lunar hat geschrieben:Objective C ist außerhalb von OS X ziemlich total tot, und wird in Zukunft auch unter Mac immer mehr an Bedeutung verlieren, weil solche Anwendungen nur in geringen Maße portabel sind.
Was Objective-C angeht angeht, so ist es noch lebendig, aber eben nur auf dem Mac. Außer Apple und anderen, auf den Mac spezialisierten Firmen entwickelt niemand wirklich damit. Und ob das IPhone der Sprache wirklich so viel Auftrieb gibt, bleibt erstmal abzuwarten.
Ja und? Das ändert nichts daran, dass Cross-Plattformanwendung mehr und mehr an Bedeutung gewinnen.Eine native Anwendung fühlt sich immer anders an, als eine mit einem Crossplatform-Toolkit.
@sma
Danke für Deinen langen Beitrag.
In vielen Punkten hast Du recht und in vielen Punkten kann ich nichts dazu beitragen, weil ich mich nicht so gut auskenne wie Du bzw. mir noch die Erfahrungen fehlen.
Vielleicht ist es nicht so sinnvoll gewesen, hier diesen Thread zu eröffnen und nach einem solchen Vergleich zu fragen.
Wie man sieht, führt das Ganze schnell zu Grundsatzdiskussionen (die auch nicht falsch sind, aber des öfteren zu Streit führen) und jeder Programmierer wird letzten Endes für das Einstehen, was ihm die besten Erfolge beschert hat.
Ich werde einfach mal in Python investieren und mich dann umorientieren, wenn ich keine Erfolge damimt erzielen werde.
Vielleicht wird es in absehbarer Zukunft eine ähnliches Framework geben wie ROR , welches gewisse Vorzüge vereint und als de facto Standard gelten wird.
Ich lasse mich überraschen.....
ne0h
Danke für Deinen langen Beitrag.
In vielen Punkten hast Du recht und in vielen Punkten kann ich nichts dazu beitragen, weil ich mich nicht so gut auskenne wie Du bzw. mir noch die Erfahrungen fehlen.
Vielleicht ist es nicht so sinnvoll gewesen, hier diesen Thread zu eröffnen und nach einem solchen Vergleich zu fragen.
Wie man sieht, führt das Ganze schnell zu Grundsatzdiskussionen (die auch nicht falsch sind, aber des öfteren zu Streit führen) und jeder Programmierer wird letzten Endes für das Einstehen, was ihm die besten Erfolge beschert hat.
Ich werde einfach mal in Python investieren und mich dann umorientieren, wenn ich keine Erfolge damimt erzielen werde.
Vielleicht wird es in absehbarer Zukunft eine ähnliches Framework geben wie ROR , welches gewisse Vorzüge vereint und als de facto Standard gelten wird.
Ich lasse mich überraschen.....
ne0h
Naja, Lisp- und Scheme-Systeme, die ich ebenfalls als dynamisch typisiert klassifizieren würde, kompilieren in der Regel direkt in Maschinencode. Und VisualWorks-Smalltalk hat (da hies es noch anders) seit 1989 einen JIT (der Name wurde erst von Java-VMs fast 10 Jahre später geprägt) was sich IMHO auch als nicht-rein-interpretiert qualifiziert. Tja, und Forth-Systeme, die noch nicht mal dynamisch typsiert sind sondern komplett untypisiert, kompilieren mit ihrem threaded-code-Ansatz eigentlich auch alle.Darii hat geschrieben:Ansonsten ist das schade, dass ObjC so wenig verbreitet ist, eine sehr schöne Sprache. Eine der wenigen dynamisch typisierten Sprachen(die einzige?) außerhalb der interpretierten Spachen.
Stefan
Ich habe bisher für die Python Entwicklung nichts gefunden was besser wäre als Eclipse + Pydev. Klar, eclipse ist ein echter Leistungs- und Speicherfresser, aber dafür kann es mit pydev alles was mir in vielen anderen editoren/ides fehlt: Gutes Highlighting, Syntaxvervollständigung, Templating, Refactoring, Plugins, STABILITÄT, flexibles ausführen uvm...und man kann auch java, c++, erlang. Wozu man grad "Lust" hat^^
Wenn man einen entsprechenden pc und Monitor hat tuts auch mit Java, ääääh Eclipse, ich wollte ja nicht andeuten das alle Java Programme irgendwie lahm sind....auch wenns einem so vorkommen könnte.........
Habe alles hier genannte schon durchprobiert (teilweise aber schon ~1 Jahr her) aber soooo toll war nicht wirklich viel davon, vieles unfertig und meistens hat irgendwas praktisches gefehlt (jaja, emacs kann alles, ich weiß---).
Zur Sprachendebatte:
Das einzige was ich an perl als vorteilhaft ansehe ist das riieessige cpan. Alles was man will. Alles andere hab ich auch mit python und dank gruppenzwang (oder sagen wir lieber "mentalität" der Programmiersprache) sogar lesbar(er)
Zu C++, ich glaube nicht das irgendwer diese Sprache wirklich "beherrscht", es gibt einfach zu viele Möglichkeiten abstrußen code zu produzieren von dem keiner ausser dem compiler weiß was der Salat eigentlich zu bedeuten hat. Abgesehen davon einer meiner all-time-favorites Neben C wenns ans eingemachte, oder eher eingebettete , geht.
Zu Java, ein echter Performancekiller, man kann in Java wunderbar performante Programme schreiben, macht bloss keiner. Über den Speicherverbrauch braucht man auch nichts zu sagen, aber ram ist billig. Ansonsten ist java ganz nett, leichter als C++ isses allemal und vor allem verbreitet und theoretisch unmodifiziert portabel, praktisch oft nicht wirklich aber nujaaaaa.
Python hingegen ist Klasse wenns darum geht schnell was auf die Beine zu stellen. Will man was großes machen kommt jedoch auch dort schnell ein overhead dazu, unittesting etc., aber das is ja immer so...Ästhetisch gesehen habe ich noch nichts besseres gesehen.
Man muss halt immer im Hinterkopf haben was man letzendlich erreichen will. Die Sprache ist nur das Werkzeug dazu!
Wenn man einen entsprechenden pc und Monitor hat tuts auch mit Java, ääääh Eclipse, ich wollte ja nicht andeuten das alle Java Programme irgendwie lahm sind....auch wenns einem so vorkommen könnte.........
Habe alles hier genannte schon durchprobiert (teilweise aber schon ~1 Jahr her) aber soooo toll war nicht wirklich viel davon, vieles unfertig und meistens hat irgendwas praktisches gefehlt (jaja, emacs kann alles, ich weiß---).
Zur Sprachendebatte:
Das einzige was ich an perl als vorteilhaft ansehe ist das riieessige cpan. Alles was man will. Alles andere hab ich auch mit python und dank gruppenzwang (oder sagen wir lieber "mentalität" der Programmiersprache) sogar lesbar(er)
Zu C++, ich glaube nicht das irgendwer diese Sprache wirklich "beherrscht", es gibt einfach zu viele Möglichkeiten abstrußen code zu produzieren von dem keiner ausser dem compiler weiß was der Salat eigentlich zu bedeuten hat. Abgesehen davon einer meiner all-time-favorites Neben C wenns ans eingemachte, oder eher eingebettete , geht.
Zu Java, ein echter Performancekiller, man kann in Java wunderbar performante Programme schreiben, macht bloss keiner. Über den Speicherverbrauch braucht man auch nichts zu sagen, aber ram ist billig. Ansonsten ist java ganz nett, leichter als C++ isses allemal und vor allem verbreitet und theoretisch unmodifiziert portabel, praktisch oft nicht wirklich aber nujaaaaa.
Python hingegen ist Klasse wenns darum geht schnell was auf die Beine zu stellen. Will man was großes machen kommt jedoch auch dort schnell ein overhead dazu, unittesting etc., aber das is ja immer so...Ästhetisch gesehen habe ich noch nichts besseres gesehen.
Man muss halt immer im Hinterkopf haben was man letzendlich erreichen will. Die Sprache ist nur das Werkzeug dazu!
Warum bringst du Unittests gerade mit Python in Zusammenhang? Gerade in durch JUnit bin ich damit als erstes in der Java-Welt in Berührung gekommen. Oder spielst du auf die unterschiedliche Typisierung in beiden Sprachen an?
Swing war lahm, Java war das zumindest in der Referenz-Implementierung nie..D0T hat geschrieben:Wenn man einen entsprechenden pc und Monitor hat tuts auch mit Java, ääääh Eclipse, ich wollte ja nicht andeuten das alle Java Programme irgendwie lahm sind....auch wenns einem so vorkommen könnte.........
Es gibt einen Standard. Anhand dieses Standards kann man jeden C++ Code interpretieren, folglich ist die Behauptung, niemand würde C++ wirklich verstehen, ziemlich gewagt und in sich unhaltbar.Zu C++, ich glaube nicht das irgendwer diese Sprache wirklich "beherrscht", es gibt einfach zu viele Möglichkeiten abstrußen code zu produzieren von dem keiner ausser dem compiler weiß was der Salat eigentlich zu bedeuten hat.
Dir scheint da irgendwie der praktische Umgang mit C++-Entwicklern zu fehlen...
Ist es vermessen, anzunehmen, dass diese Behauptung in irgendeiner Weise belegbar oder zumindest von persönlicher Erfahrung unterlegt ist?Zu Java, ein echter Performancekiller, man kann in Java wunderbar performante Programme schreiben, macht bloss keiner.
Es ist die portabelste aller Sprachen, die in der professionellen Webentwicklung zu finden sind! Im Gegenteil zu anderen Sprachen wie Python ist es nämlich nicht nur plattformunabhängig, sondern dank der J2EE-Standards sogar unabhängig von der konkreten Auslieferungsschicht. Eine Firma muss nur einen einzigen Applikationsserver aufsetzen, und kann dort alle möglichen Web-Anwendungen deployen (wobei deployen in diesem Kontext eher "kopieren" meint).Ansonsten ist java ganz nett, leichter als C++ isses allemal und vor allem verbreitet und theoretisch unmodifiziert portabel, praktisch oft nicht wirklich aber nujaaaaa.
Dieses hohe Maß an Standardisierung erreicht keine andere Sprache in diesem Bereich. P
ython und Perl sind zwar ebenfalls plattformunabhängig, aber nicht unabhängig von der Auslieferungsschicht. Perl hat noch nicht mal einen Standard für die Webserver-Schnittstelle.
Python hat zwar WSGI, aber das spielt auf wesentlich niedrigerer Ebene. Die darüber liegenden Frameworks sind total zersplittert und zueinander weitgehend inkompatibel. Eine Firma, die bereits Pylons-Webanwendungen betreibt, kann nicht ohne weiteres eine Django-Anwendung dazu schaltet. Dafür muss eine neue Serverkonfiguration her. Zudem reden die Anwendungen nicht miteinander, weil es keinen Standard für die Datenauslieferung gibt.
Die Webanwendung in Java selbst ist zwar überkompliziert, bürokratisiert und so mit enorm viel Boilerplate-Code verbunden, dass Deployment allerdings ist nirgendwo so einfach wie bei Java-Anwendungen.