Einstiegsfrage bezüglich Python

[narcosynthesis]

Schönen guten Tag,

Da ich mit C# als Entwicklersprache für ein Projekt, das ich gerade schreibe, relativ unzufrieden bin oder besser gesagt dem Fakt dass es Windows only ist (Mono kommt auch nicht in Frage) würde ich gerne eine Applikation schreiben, die plattformübergreifend ist - und habe mich als Sprache für diese Aufgabe für Python entschieden.

Erste Frage:

Kann man Python als Sprache empfehlen? Bisher wurde ja immer vermittelt dass sie einfach zu lernen sei, mächtig und gut strukturiert. Das Prinzip von Python weiß bislang auch zu überzeugen, aber wenn man von C# kommt, sind doch einige Dinge sehr anders. Von dem her würde ich gerne ein paar fundierte Meinungen hierzu hören.

if erste_frage.antwort == 'yes':
Zweite Frage:

Welcher Editor ist für das Programmieren von Python unter Windows zu empfehlen? Da ich auf meinem Notebook wegen Schulgebrauch nur Windows installiert habe, habe ich hier das Problem, keinen komfortablen GUI-Editor zu besitzen - ich habe gVIM getestet, bin aber nicht unbedingt zufrieden. Zu Hause, unter Kubuntu kann ich mit Kate recht komfortable programmieren, intended blocks und syntax highlighting funktionen sehr gut. Gibt es vergleichbares auch für Windows? IDLE gefällt mir da nicht so sehr. Oder empfehlt ihr es explizit?

if zweite_frage.antwort == 'yes':
Dritte Frage:

Printmedien. Welche Bücher kann man für das Erlernen von Python empfehlen? Ich habe bisher 'Byte of Python' durchgearbeitet, ein sehr interessantes Werk (die deutsche Übersetzung, muss man fairerweise dazu sagen), aber behandelt doch nicht all die Dinge die mich interessieren würde - und auch nicht die Lösung für viele Probleme die ich bei der Umstellung bisher noch habe. Ich wäre für Empfehlungen dankbar, persönlich haben mir die O'Reilly-Bücher zugesagt, Python in a Nutshell als Referenz-Nachschlagewerk und das Python Cookbook als Lernmaterial. Was sagt ihr zu diesen Werken, so ihr sie kennt?


# end block

Danke für das Durchlesen dieser Formulierungen und auch vielen Dank im Voraus für jegliche Antwort auf die Fragen.

mit freundlichen Grüßen

narcosynthesis.

[peschmae]

1) Ich denke Python kann man unbedingt empfehlen. Hab zwar damit selber nicht viel mehr gemacht als ein kleines Script, bisher, aber der erste Eindruck war gut und von Leuten die das kennen hab ich bisher auch nur gutes gehört.

2) Eventuell mal SciTE angucken? Sehr netter Editor, allerdings musst du den auf jeden Fall etwas konfigurieren - die Defaulteinstellungen sind ein bisschen blöd ;)
Aber die Konfiguration machst du ja nur einmal und gut ist :)

MfG Peschmä

[narcosynthesis]

Oh, SciTE gefällt mir wirklich gut. Danke für diesen Tipp.

Wenn ich jetzt noch die tausenden Fehler, die ich mit Python mache los werde, bin ich glücklich :) Danke schon einmal.

[Christoph]

Zu grafischen Oberflächen mit wxpython ist kürzlich ein brauchbares Buch ershcienen: Rappin, Dunn: wxPython in Action.

[OpOs]

kommt ganz drauf an, was du machen willst....
ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen. es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung. die sprache ist untypisiert und es gibt keinen klaren styleguide, zumindest ist mir noch keiner begegnet. die bibliotheken lassen kein muster bei der namensgebung erkennen. es kann gut sein, dass dein projekt 50 mal gut funktioniert und beim 51. mal abstuerzt, weil du irgendwo 'nen kleinen tippfehler drinnen hast oder eine typueberpruefung vergessen hast. SciTE wurde ja schon genannt, auch die notwendigkeit der manuellen konfiguration. vor allem sollte man bei den schriften ein "$(font.monospace)" hinzufuegen ich nutze gerne diese python referenz (http://www.reportlab.org/docs/PythonReferenz.pdf)

[narcosynthesis]

kommt ganz drauf an, was du machen willst....
ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen. es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung. die sprache ist untypisiert und es gibt keinen klaren styleguide, zumindest ist mir noch keiner begegnet. die bibliotheken lassen kein muster bei der namensgebung erkennen. es kann gut sein, dass dein projekt 50 mal gut funktioniert und beim 51. mal abstuerzt, weil du irgendwo 'nen kleinen tippfehler drinnen hast oder eine typueberpruefung vergessen hast.

Hört sich gar nicht gut an, was du da erzählst, diese Problematiken fallen mir als Laien natürlich nicht sonderlich auf, Typisierung ist schon ein Thema, aber ich muss mich da wohl noch mehr einarbeiten.

Prinzipiell würde ich einfach gerne eine gute, moderne Sprache verwenden, die plattformübergreifend agiert und trotzdem bei brauchbarer Performance einfach zu erlernen bleibt (Faulheit? Oder doch nur zu viel von PHP gewöhnt?).

Ruby ist da auch immer noch im Gespräch, aber ob ich von Ruby so viel mehr erwarten kann, es bleibt abzuwarten, was man dazu sagen mag.

@Christoph: Vielen Dank für die Empfehlung :)

[OpOs]

hab noch nie was in ruby gemacht, hab nur schnell mal bei wikipedia reingeschaut und ich muss sagen... auf den ersten blick sieht's aus wie python in 'ner anderen farbe... kann mich aber auch irren.

nochmal zu dem obengenannten ein beispiel: stell dir vor du hast in deinem programm folgende zeile:
if a==b: die zeile ist syntaktisch korrekt und wird in manchen testfaellen das gewuenschte ergebnis liefern. aber irgendwann kann es sein, dass der ausdruck nich das erwartete resultat liefert und du merkst, dass es eigentlich
if a==b(): heissen muesste. das mag zwar jetzt laecherlich erscheinen, aber wenn du mal ein groesseres projekt entwickelst, kann dich so ein fehler mehrere stunden suche kosten... vom compiler/interpreter kannst du da keine hilfe erwarten.
und nochmal zu den typueberpruefungen: auch hier kann ein programm scheinbar fehlerfrei funktionieren. wenn du eine variable als parameter an eine funktion uebergibst, muss das objekt nur die von der funktion aufgerufenen methoden implementieren...
ich hab mal ein kurzes script geschrieben, welches mehrere statusabfragen taetigen sollte, alles in die datenbank schreiben und 'ne mail rausschicken. das script lief fehlerfrei durch, nur die mail kam nicht. in der db war alles in ordnung, das script hatte also offensichtlich funktioniert. wenn ich nich nebenbei noch admin gewesen waere und zugriff auf die maillogs gehabt haette, haette ich den fehler wohl nich so schnell gefunden. statt eine einelementige liste mit der emailadresse zu uebergeben hab ich nur einen string mit der adresse angegeben. da sowohl listen als auch strings die iteration unterstuetzen, hat der interpreter nichts gemerkt und schoen fuer jeden buchstaben der adresse 'ne mail verschickt...
die loesung war einfach, von hand 'ne typueberpruefung durchzufuehren

ich will dir python keinesfalls ausreden. ich nutze es gern, weil man schnell und ohne viel umstaende komplexe programme oder nur kleine scripte schreiben kann. aber wenn du in 'nem team arbeitest und dein programm die kritische groesse ueberschreitet, wirst du fluchen... viel fluchen... hier musst du dokumentieren und zwar mehr als bei den meisten anderen sprachen

und du benoetigst 'nen editor, der dich bei blockweisen ein- und ausrueckungen unterstuetzt (ich weiss jetzt gar nich, ob scite das kann, aber kate kann's :)) mal schnell mit dem vi ueber ssh auf dem webserver in 'nem cgi-script 'nen block mit 'ner if-abfrage zu umschliessen iss 'n laengeres projekt

wenn gegen C# nur die fehlende portabilitaet steht, warum dann nicht ... java???

[Joghurt]

ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen.Das macht aber auch Sinn. In C++ und Java wird "self" ja immer implizit übergeben (dort heisst es this). Da bei Python Variablen nicht deklariert werden, muss die Referenz auf self immer angegeben werden, damit man zwischen (Methoden-)lokalen und Instanzvariablen unterscheiden kann. Desweiteren ist es notwendig, weil du Methoden dynamisch hinzufügen (oder löschen) kannst:

Beispiel:

class A(object):
def foo(self):
print "hier ist foo"

# Klassendefinition ist hier zuende
def blabla(self):
print "Ich rufe mal foo auf"
self.foo()

def neues_foo(self):
print "Ich bin der neue Foo"

a = A()
A.bar = blabla
a.bar() # Ausgabe: Ich rufe foo auf, hier ist foo
a.foo() # hier ist foo
b = A()
b.foo = neues_foo
b.foo(); a.foo() # neues foo, foo
old_foo = A.foo
A.foo = neues_foo
a.foo() # neues foo
old_foo(a) # ruft altes foo auf



es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung.Das stimmt. Das ist per design. Python geht davon aus, das der Programmierer weiss, was er tut und dass er sich an Konventionen hält. Z.B. sind Methoden, die mit einem _ beginnen, Klassenintern und nicht als Teil der API zu betrachten. Wenn man sie aber unbedingt aufrufen will, kann man es tun, sollte sich aber nicht wundern, wenn das Programm mit späteren Versionen der API nicht geht.

Meistens braucht man auch private nicht, da die Sachen anders gelöst sind.

Beispielsweise nutzt man in C++ und Java oft getter und setter-Methoden.
Beispiel
class Kreis {
private int durchmesser;
public int getDurchmesser() {
return durchmesser;
}
public void setDurchmesser(int durchmesser) {
this.durchmesser = durchmesser;
}Wenn man also auf bar zugreifen möchte, muss man mit get/set arbeiten. Der Gedanke dahinter ist einfach: Sollte man irgendwann mal seine Klasse so umschreiben, dass sie mit dem Radius arbeitet, laufen alte Programme wie gewohnt weiter, da man einfach die getter/setter entsprechend anpassen würde. Würde jemand direkt auf umfang zugreifen, wäre ein Wechsel nicht so einfach möglich.

In Python kann man jedoch den Zugriff auf eine Variable abfangen, so man denn will. Nehmen wir an, die Klasse Kreis hatte früher eine Variable durchmesser, die man einfach benutzen konnte

class Kreis(object):
def __init__(self):
self.durchmesser = 0
def tu_irgendwas(self):
# hier macht man irgendwas
k = Kreis()
k.durchmesser = 4
k.tu_irgendwas()Wenn man nun auf Radius umstellt, macht man


def Kreis(object):
def __init__(self):
self.radius = 0
def get_durchmesser(self):
return self.radius*2
def set_durchmesser(self, durchmesser):
self.radius = durchmesser/2
durchmesser = property(get_durchmesser, set_durchmesser)
Ein
kreis.durchmesser = 5setzt nun den Radius auf 2,5, alter Code ist weiterhin lauffähig.

Aus diesem Grund bräuchte man private und co. eigentlich so gut wie nie.


und es gibt keinen klaren styleguideUnd ob!
Style Guide for Python Code (http://www.python.org/dev/peps/pep-0008/)

[OpOs]

Das macht aber auch Sinn. In C++ und Java wird "self" ja immer implizit übergeben (dort heisst es this). Da bei Python Variablen nicht deklariert werden, muss die Referenz auf self immer angegeben werden, damit man zwischen (Methoden-)lokalen und Instanzvariablen unterscheiden kann. Desweiteren ist es notwendig, weil du Methoden dynamisch hinzufügen (oder löschen) kannst...

es ist in einer rein objektorientierten sprache (als was einem python ja immer verkauft wird), nicht sinn und zweck, prozedural zu programmieren von daher sollte das implizierte uebergeben von self standard sein. und das nichtdeklarieren von variablen in den meisten interpretierten sprachen halte ich persoenlich fuer einen bug und nicht fuer ein feature. und das dynamische hinzufuegen von methoden magst DU fuer 'ne tolle idee halten, der mensch der deinen code irgendwann verstehen und modifizieren muss, ist da sicher anderer meinung...


Das stimmt. Das ist per design. Python geht davon aus, das der Programmierer weiss, was er tut und dass er sich an Konventionen hält. Z.B. sind Methoden, die mit einem _ beginnen, Klassenintern und nicht als Teil der API zu betrachten. Wenn man sie aber unbedingt aufrufen will, kann man es tun, sollte sich aber nicht wundern, wenn das Programm mit späteren Versionen der API nicht geht.

ein programmierer, der weiss was er tut, ist eine illusion... modifikatoren wie private/protected/public oder static/virtual lassen wesentlich genauere annahmen zu, was ein entwickler mit einem bestimmten befehl beabsichtigt (hat). das kann einem auch helfen, seinen eigenen code irgendwann mal wieder zu verstehen. hierzu gehoert ebenfalls das deklarieren von variablen mit einem datentyp, der erkennen laesst, was damit gemacht werden soll.

und eine methode zu deklarieren, die verschiedene arten von eingabedaten akzeptiert und dann eine pruefung auf jede moegliche kombination von typen ist sicher nicht angenehmer, als in einer typisierten sprache eine methode einfach zu ueberladen...



Und ob!
Style Guide for Python Code (http://www.python.org/dev/peps/pep-0008/)
wenn ich mir packages wie "_mysql", "PIL" oder auch einige standardmodule anschaue, kann ich das nicht glauben... "StringIO.StringIO"??? wtf...

[Joghurt]

es ist in einer rein objektorientierten sprache (als was einem python ja immer verkauft wird)Python ist eine multi-paradigm-Sprache. Imperative, objektorientierte, funktionelle und teilweise auch aspektorientierte Programmierung wird unterstützt.


von daher sollte das implizierte uebergeben von self standard sein.Das Widerspricht der Python-Philosophie: "explicit is better than implicit"


und eine methode zu deklarieren, die verschiedene arten von eingabedaten akzeptiert und dann eine pruefung auf jede moegliche kombination von typen ist sicher nicht angenehmer, als in einer typisierten sprache eine methode einfach zu ueberladen...Wenn man sowas macht, versucht man, C++ oder Java in Python zu programmieren und macht etwas falsch. Slange die übergebenen Objekte die benutzen Methoden implementieren, ist es Wurst, von welcher Klasse sie abgeleitet sind. In der Praxis überlädt meine eine Methode ja auch höchstens so:
int foo(int bar, int baz);
int foo(float bar, float baz);
int foo(SupidupiInt bar, SupidupiInt baz); und nicht so
int foo(int bar, int baz);
int foo(FILE* zieldatei, const char* zu_schreibender_string)Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests ;))
Aber du hast recht, ein "Interface"-System wie bei Java wäre ganz nett. Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.

Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.
Als ich mit Python anfingt, hatte ich auch Bedenken ob des "Duck-typing" Ansatzes und den fehlendem private. In der Praxis bringt das aber mehr Vorteile als die theoretischen Nachteile.


wenn ich mir packages wie "_mysql", "PIL" oder auch einige standardmodule anschaue, kann ich das nicht glauben... "StringIO.StringIO"??? wtf...Ja, das Crux der Rückwärtskompabilität. Ich denke mal, dass wird in Python 3000 auch korrigiert.

[OpOs]

In der Praxis überlädt meine eine Methode ja auch höchstens so:
int foo(int bar, int baz);
int foo(float bar, float baz);
int foo(SupidupiInt bar, SupidupiInt baz); und nicht so
int foo(int bar, int baz);
int foo(FILE* zieldatei, const char* zu_schreibender_string)

aber diese ueberladung:
collection.add(object)
collection.add(array of object)
macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in python


Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests ;))
mir persoenlich ist es lieber, dass der compiler meckert, als dass ich ein fehlerhaftes und dadurch potenziell verheerendes programm ausfuehre, aber das mag meine persoenliche meinung sein.


Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.
dazu muss der entwickler die funktion aber auch entsprechend ausfuehrlich dokumentieren, waehrend es in java bereits aus der deklaration ersichtlich ist und man bei der doku weniger aufwand hat.


Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.
sei doch froh, dass dich der compiler darauf hingewiesen hat BEVOR du dir eventuell das system kaputt gemacht hast. mag ja sein, dass es nichts gegaehrliches war, aber wird es beim naechsten mal auch so sein...

wie gesagt, ich nutze python auch recht gerne, man muss sich aber im klaren ueber die fallstricke sein!

ich weiss, in c kann man mit dem zeigergefummle geausoviel bockmist machen, aber ich hab ja nich gesagt, dass c das gelbe vom ei iss.

[Joghurt]

aber diese ueberladung:
collection.add(object)
collection.add(array of object)
macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in pythonIn Python würdest du nur die "array of object" Methode definieren. Wenn jemand ein einfaches Objekt hat, macht er einfach beim Aufruf ein Tupel draus:

foo(liste_von_objekten)
foo((einzelnes_objekt,)) # oder foo([einzelnes_objekt])

[Romanday]

Was mich mal interessieren würde:

Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
Welches Problem läßt sich nicht viel schneller mit einer anderen
Programmiersprache lösen?

(Außer die 3D - Ünterstützung habe ich bis jetzt nichts gefunden.)

[RapidMax]

Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
Welches Problem läßt sich nicht viel schneller mit einer anderen
Programmiersprache lösen?

Der Einsatz von Python ist nur dort zwingen notwendig wo Python vorausgesetzt wird oder Python bereits im Einsatz ist. Und sinnvoll ist es oft, hängt aber mit der jeweiligen Situation ab. Zudem lässt sich jedes Problem mit einer anderen Programmiersprache schneller lösen, vorausgesetzt man nimmt die richtige, andere Programmiersprache.

Diese Antwort dürfte etwas so gummig sein, wie die Frage.

Gruss, Andy

[Romanday]

Diese Antwort dürfte etwas so gummig sein, wie die Frage.

Gruss, Andy

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.

Stichwort: Verbreitungsgrad

Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.
Bis jetzt sehe ich einfach noch keinen Sinn darin in Python tiefer
einzusteigen. Der Reiz fehlt. Ich sehe noch nicht die Vorteile.
Was soll ich damit zusammenbasteln, was es nicht schon in anderen
Sprachen gibt?

[Christoph]

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.

Das stimmt definitiv nicht. Ich setze Python sehr viel ein und habe in den Projekten regelmäßig mit Leuten zu tun, für die Python neu ist. Python ist nach meiner Erfahrung eine der am leichtesten zu lernende Sprache. Verglichen z.B. mit Perl ist die Lesbarkeit um mehrere Größenordnungen besser.



Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.

Python ist weniger für "fertige Apps" geeignet, insbesondere da es ähnlich wie Java eine Runtime-Umgebung braucht, also eine "fertige App" nicht so leicht zu installieren ist. Hauptproblem ist, dass es sich nicht einfach compilieren in ein Executable linken lässt.

Ideal ist es aber für Frameworks für bestimmte Anwendungsbereiche, speziell im wissenschaftlichen Bereich. Und da gibt es interessante "Apps" (z.B. PyLab, Matplotlib oder Gamera).

[RapidMax]

Gerade für Aufgaben, die eine komplexe Logik erfordern, d.h. normale Anwendungslogik, Geschäftsabläufe und ähnlichen Profitieren von einer Sprache die einem erlaubt sich auf die Aufgabe zu konzentrieren. Da Profitieren gerade Scriptsprachen wie Python (aber auch andere sind dazu gut geeignet: Ruby, Eiffel, etc.).

Was Python weiter als ideales Werkzeug im Sinne des Schweizer Taschenmesser auszeichnet ist die interaktive Python Shell. So ist schnell eine SMTP Verbindung aufgebaut um den Mailserver zu testen, oder eine Multipart-MIME EMail zerteilt. Oder man muss irgend ein propritäres Protokoll testen, hackt sich ein kleines Modul zusammen, dass die Nachrichten zerlegen und zusammenbauen kann und kann dann sich dann interaktiv mit der dazugehörigen Anwendung unterhalten und so Fehler suchen. Weiter schätze ich das einfache C-API von Python. Damit lässt sich auch recht einfach eine Anbindung z.B. an eine Bibliothek realisieren, um damit einfach und effizient Regression Tests zu formulieren.

Gruss, Andy

[Joghurt]

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.Ich denke, das wurde hier schon widerlegt ;) Der Code ist in der Regel sehr gut verständlich.


Stichwort: Verbreitungsgrad
NASA uses Python...
... so does Rackspace, Industrial Light and Magic, AstraZeneca, Honeywell, and many others (http://www.python.org/about/success)


Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.Oh doch, die will ich aber jetzt nicht aufzählen.


Was soll ich damit zusammenbasteln, was es nicht schon in anderen
Sprachen gibt?Keiner zwingt dich, über den Tellerrand zu schauen. Du kannst deine Programme in C, Basic, Pascal, VB, Java, LISP, Haskell oder was auch immer schreiben.

Hier geht es nicht darum, das/ob Python die beste Sprache ist, die jeder kennen muss; es geht nur darum, zu zeigen, was Pythonprogrammierer an der Sprache schätzen und so anderen eine Entscheidungshilfe zu geben, ob sie sich die Sprache mal anschauen oder es besser lassen.

Wenn du mit deiner aktuellen Sprache glücklich bist, prima! Ich war es nicht, weder mit BASIC, Pascal, C, C++ oder Java. Haskell ist ganz nett, aber mit Python programmiere ich bis jetzt am liebsten. Ich schaue mir immer wieder mal neue Sprache an, bis jetzt gefällt mir Python immer noch am besten.

[sauertopf]

Phyton ist eine Sprache mit klarer Syntax und gutem Funktionsumfang. Man kann damit schnell kleine Projekte prototypisch implementieren.

Werden die Projekte jedoch größer, werden folgende Eigenschaften ziemlich wahrscheinlich zum Projekt-Killer:

- Keine statische Typisierung
- Keine Informationskapselung auf Klassen- oder Modulebene
- Keine Eliminierung von Seiteneffekten
- Schlechte Lösung bei Namenskonflikten

Bei mittleren / großen Projekten sollte man auf diese Eigenschaften achten, denke ich.