Welche anderen Programmiersprachen kennt Ihr denn so und wie
würdet Ihr die Tauglichkeit von Python für allgemeine nicht-resourcenkritische
Aufgaben im Vergleich einschätzen ??
Python im Vergleich
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das haben wir in einer FAQ schon mal zusammengetragen:
http://www.pythonwiki.de/PythonDeForum/ ... 6d6a7ef550
http://www.pythonwiki.de/PythonDeForum/ ... 6d6a7ef550
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Kennen: Python, Ruby, Java (lange her), Visual Basic (länger her), Pascal (ewig her).
Probiert haben: Haskell, O'Caml, C++
Vorteile von Python gegenüber den meisten Sprachen: Quellcode sehr leicht verständlich, es programmiert sich sehr schnell. Es gibt noch viele andere Vorteile, ich bin daran so gewöhnt, dass es schwer wäre sie aufzulisten.
Probiert haben: Haskell, O'Caml, C++
Vorteile von Python gegenüber den meisten Sprachen: Quellcode sehr leicht verständlich, es programmiert sich sehr schnell. Es gibt noch viele andere Vorteile, ich bin daran so gewöhnt, dass es schwer wäre sie aufzulisten.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
C(++) nur sinnvoll für Resourcenfresser oder wo Schnelligkeit ein Kriterium ist. Extrem sicherheitsloch-anfällig, da man das Speicher-Management selber machen muss (was dem Nichtinformatiker zuviel ist). Ausserdem ist Python notfalls mit C(++) erweiterbar...
VisualBasic: Mal abgesehen davon, dass es ein MS-Produkt ist (und nur unter Win läuft), wer will schon ein Sprache lernen, die nicht klar zwischen GUI und Programm unterscheidet?
Perl: Äquivalent zu Python, aber mühsamer zum schreiben und absolut kotzig um alten Quelltext wieder zu lesen
JAVA: Viel Firmen arbeiten mit Java, das ist sicher ein +. Kein funktionelles oder prozedurales Coden, das ist sicher ein -. Kein wirklicher Standard (verschiedene Firmen basteln an verschiedenen JAVAs).
C# und die ganzen .net-Sachen: irrelevant, da alle oben genannten Sprachen früher oder später auch damit kompatibel sein werden.
Ruby: JAVA - Popularität - kein Standard
Exotisches: Lisp, Scheme, Prolog, Cobol, Oberon etc. zu speziell! Wird nur zu Unterrichtszwecken oder in bestimmten Gebieten verwendet (Oberon an der ETH, Prolog unter Computerlinguisten in Europa [die Amis benutzen Lisp])
Du kriegst heutzutage eigentlich mit allen Sprachen alles hin, die Frage die du dir deshalb stellen musst ist: "Wie gross soll der Aufwand sein um Programme zu schreiben und was mag ich persönlich"
Python schneidet da ganz gut ab.
Eine andere Frage, die für mich momentan wichtig ist: Wieviele Firmen könne Leute brauchen, die Python beherrschen. In der Schweiz sind die leider Gottes dünn gesäht. Da bist du mit Java besser bedient...
VisualBasic: Mal abgesehen davon, dass es ein MS-Produkt ist (und nur unter Win läuft), wer will schon ein Sprache lernen, die nicht klar zwischen GUI und Programm unterscheidet?
Perl: Äquivalent zu Python, aber mühsamer zum schreiben und absolut kotzig um alten Quelltext wieder zu lesen
JAVA: Viel Firmen arbeiten mit Java, das ist sicher ein +. Kein funktionelles oder prozedurales Coden, das ist sicher ein -. Kein wirklicher Standard (verschiedene Firmen basteln an verschiedenen JAVAs).
C# und die ganzen .net-Sachen: irrelevant, da alle oben genannten Sprachen früher oder später auch damit kompatibel sein werden.
Ruby: JAVA - Popularität - kein Standard
Exotisches: Lisp, Scheme, Prolog, Cobol, Oberon etc. zu speziell! Wird nur zu Unterrichtszwecken oder in bestimmten Gebieten verwendet (Oberon an der ETH, Prolog unter Computerlinguisten in Europa [die Amis benutzen Lisp])
Du kriegst heutzutage eigentlich mit allen Sprachen alles hin, die Frage die du dir deshalb stellen musst ist: "Wie gross soll der Aufwand sein um Programme zu schreiben und was mag ich persönlich"
Python schneidet da ganz gut ab.
Eine andere Frage, die für mich momentan wichtig ist: Wieviele Firmen könne Leute brauchen, die Python beherrschen. In der Schweiz sind die leider Gottes dünn gesäht. Da bist du mit Java besser bedient...
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Jython? Ist allerdings erst auf dem CPython 2.1-Stand (2.2 alpha steht vor der Tür).Clython hat geschrieben:Eine andere Frage, die für mich momentan wichtig ist: Wieviele Firmen könne Leute brauchen, die Python beherrschen. In der Schweiz sind die leider Gottes dünn gesäht. Da bist du mit Java besser bedient...
Wo fehlt dir ein Standard bei Ruby? Es gibt sowieso nur eine Implementation, das ist dann der Standard

My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ach, jetzt versteh ich es. Das soll ne Gleichung sein!Clython hat geschrieben:erm leonidas, du hast da zwei Vorzeichen: - (minus) kein Standard

My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Danke für Eure Antworten (gerne auch noch ein paar mehr) !
Der Hintergrund meiner Frage ist der folgende:
kurz davor, ein mittelgroßes, nicht-resourcenkritisches C++-Programmierprojekt
aus dem Bereich automatische Text- und Listenbearbeitung neu zu
überdenken und zu programmieren, suche ich eine passende Programmiersprache.
Daß Python eine dynamisch typisierte Sprache mit starker Typisierung
usw... ist, ist mir schon bekannt; was ich aber auch wissen muß, ist die Eignung von Python eben für ein Projekt der oben beschriebenen Art im Umfang von 10000 bis 20000 Zeilen - und zwar möglichst schon, *bevor* ich fünfzehntausend Codezeilen nach Python portiert haben werde,
denn ein dritter Wechsel der Implementationssprache kommt nicht in
Frage.
Mit anderen Worten: ich müßte (mit wenigen Tagen Python-Erfahrung,
aber steigender Überzeugung) möglichst jetzt schon wissen,
ob (und welche) Probleme mit Python nach ein paar tausend
Zeilen Code auftreten können.
In einem Paper habe ich mal gelesen, die dynamische Typisierung
könnte bei mittleren bis großen Projekten langfristig problematisch
werden, da der Fehlertest zur Compilezeit ja wegfällt und daher Python
besser für kleine Projekte unter 1000 Zeilen geeignet wäre - kann das wirklich zum ernstzunehmenden Problem bei der Programmierung, Testbarkeit oder späteren Erweiterung und Wartung werden ?
Grüße
Der Hintergrund meiner Frage ist der folgende:
kurz davor, ein mittelgroßes, nicht-resourcenkritisches C++-Programmierprojekt
aus dem Bereich automatische Text- und Listenbearbeitung neu zu
überdenken und zu programmieren, suche ich eine passende Programmiersprache.
Daß Python eine dynamisch typisierte Sprache mit starker Typisierung
usw... ist, ist mir schon bekannt; was ich aber auch wissen muß, ist die Eignung von Python eben für ein Projekt der oben beschriebenen Art im Umfang von 10000 bis 20000 Zeilen - und zwar möglichst schon, *bevor* ich fünfzehntausend Codezeilen nach Python portiert haben werde,
denn ein dritter Wechsel der Implementationssprache kommt nicht in
Frage.
Mit anderen Worten: ich müßte (mit wenigen Tagen Python-Erfahrung,
aber steigender Überzeugung) möglichst jetzt schon wissen,
ob (und welche) Probleme mit Python nach ein paar tausend
Zeilen Code auftreten können.
In einem Paper habe ich mal gelesen, die dynamische Typisierung
könnte bei mittleren bis großen Projekten langfristig problematisch
werden, da der Fehlertest zur Compilezeit ja wegfällt und daher Python
besser für kleine Projekte unter 1000 Zeilen geeignet wäre - kann das wirklich zum ernstzunehmenden Problem bei der Programmierung, Testbarkeit oder späteren Erweiterung und Wartung werden ?
Grüße
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Warum sollte das?Tester hat geschrieben:In einem Paper habe ich mal gelesen, die dynamische Typisierung könnte bei mittleren bis großen Projekten langfristig problematisch werden
Wenn dein Projekt nicht resourcenkritisch ist, ist Python wohl ideal...

Allerdings würde ich ehr dein Programm neuschreiben, statt versuchen 1zu1 den C++ Code zu übersetzten, das kann nur schief laufen...
Kannst du dir nicht eine kleines Problemfeld aus deinem C++ Code schnappen und es mal in Python neuschreiben??? Wir helfen auch gern dabei, wenn's Probleme gibt, denke ich

-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
Hi!
Gruß, mawe
Dafür ist Python auf jeden Fall geeignet. Vielleicht interessiert Dich dazu das Buch Text Processing in Python.Tester hat geschrieben: Der Hintergrund meiner Frage ist der folgende:
kurz davor, ein mittelgroßes, nicht-resourcenkritisches C++-Programmierprojekt
aus dem Bereich automatische Text- und Listenbearbeitung neu zu
überdenken und zu programmieren, suche ich eine passende Programmiersprache.
Gerade Python ist eine der (Script-)Sprachen, die sehr gut skaliert. Übrigens, wenn Dein Project in C++ 15000 Codezeilen hat, wird die Python-Version erheblich kürzer seinTester hat geschrieben: was ich aber auch wissen muß, ist die Eignung von Python eben für ein Projekt der oben beschriebenen Art im Umfang von 10000 bis 20000 Zeilen

Die Antwort auf diese Bedenken sind Unittests. Dazu auch ein Buchvorschlag: Dive Into PythonTester hat geschrieben: In einem Paper habe ich mal gelesen, die dynamische Typisierung
könnte bei mittleren bis großen Projekten langfristig problematisch
werden,
Gruß, mawe
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Eben das wollte ich sagen, nachdem ich vom 20000 Zeilen gehört habe. Aber wie jens sagte, ist es oft sinnvoller das Programm komplett neu zu überdenken, da der Versuch C++ 1:1 in Python umzuschreiben viel Arbeit ist und warscheinlich suboptimal sein wird. Du könntest auch versuchen für Teilprobleme schon fertige Python-Bibliotheken zu nutzen, denn davon hat Python sehr viele.mawe hat geschrieben:Gerade Python ist eine der (Script-)Sprachen, die sehr gut skaliert. Übrigens, wenn Dein Project in C++ 15000 Codezeilen hat, wird die Python-Version erheblich kürzer seinTester hat geschrieben:was ich aber auch wissen muß, ist die Eignung von Python eben für ein Projekt der oben beschriebenen Art im Umfang von 10000 bis 20000 Zeilen![]()
Nein, ich denke nicht das dynamische Typisierung Probleme macht, denn ich kenne niemanden der solche Sprachen wirklich im Alltag nutzt (also nicht nur kurz ansehen, dynamische Typisierung: bäh! Schnell zurück zu Java!) der sich deswegen beschwert hätte. Im Gegenteil, dadurch bekommt man die praktische Fähigkeit des Duck typing, die manchmal recht praktisch ist.mawe hat geschrieben:Die Antwort auf diese Bedenken sind Unittests. Dazu auch ein Buchvorschlag: Dive Into PythonTester hat geschrieben:In einem Paper habe ich mal gelesen, die dynamische Typisierung könnte bei mittleren bis großen Projekten langfristig problematisch werden,
In der Liste von Sprachen mit dynamischen Typen tauchen einige Sprachen auf, wie LISP (interessante Sprache nur zu viele Implementationen), Smalltalk (herausragende Sprache nur zu wenige nutzbare Implementationen), Objective-C (naja, wird in Mac OS X überall benutzt), Python (wird immer populärer), Ruby (wird auch immer populärer) usw.
Und wann man von der Typenprüfung wirklich nicht loskommt gibt es noch PyProtocols, das eine Art verbessertes isinstance() ist.
Wie mawe gesagt hat, lohnt es sich für größere Projekte zumindest Teile von Extreme Programming zu realisieren z.B. Test-first programming (erst Unittests dann Code schreiben um die Unittests zu erfüllen).
Eine alternative zum unittest Modul wäre py.test, allerdings wäre für dich wohl aktuell unittest besser, vor allem da es im Buch "Dive into Python" sehr gut erklärt wird (das Buch ist für nicht komplette Anfänger großartig).
Für interessierte gibt es hier einen Vergleich von unittest und py.test.
Zuletzt noch zum Support bei Python: deutschsprachige Hilfe findest du hier in ziemlich guter Qualität (Eigenlob! Ich konnts nicht lassen *g*), aber auch in der Python-de Mailingliste, sowie in de.comp.lang.python. Englischsprachige Hilfe gibt es in comp.lang.python, wo so ziemlich alle deine Fragen gelöst werden können.
Versuch doch mal einen Teil deines Programms in Python zu schreiben, dann siehst du wie es sich "anfühlt". Viele Tricks lernt man erst mit bischen Erfahrung, aber das ist zu schaffen.
Zuletzt noch den Zen of Python, ein erstaunlicher Text (und Easter-Egg), den zumindest ich am Anfang meiner Python-Zeit nicht verstanden habe, aber inzwischen habe ich festgestellt das dieser Text jede Menge Tipps hat, wie man in Python am besten programmiert:
Code: Alles auswählen
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice