gelöscht, sorry, falsch gelesen.
Zeno schrieb: > Aber vielleicht geht ja so was auch in Python und ich bin nur zu blöd > dazu Naja, du kannst dir mit sowas behelfen:
1 | Anweisung 1 |
2 | Anweisung 2 |
3 | Anweisung 3 |
4 | if True: # Always keep the following in mind! |
5 | Anweisung 4 |
6 | Anweisung 5 |
7 | Anweisung 6 |
Kostet durch die Interpretation allerdings (meines Wissens) zusätzliche Laufzeit. Besser ist es wahrscheinlich, stattdessen die Hervorhebung mit Kommentaren zu machen:
1 | Anweisung 1 |
2 | Anweisung 2 |
3 | Anweisung 3 |
4 | #################################### |
5 | # Always keep the following in mind! |
6 | Anweisung 4 |
7 | Anweisung 5 |
8 | #################################### |
9 | Anweisung 6 |
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Besser ist es wahrscheinlich, stattdessen die Hervorhebung mit > Kommentaren zu machen: > > Anweisung 1 > Anweisung 2 > Anweisung 3 > # Always keep the following in mind! > Anweisung 4 > Anweisung 5 > # (end of reminder) > Anweisung 6 Man könnte auch auf so einen irreführenden Unfug komplett verzichten und einfach den Speicherplatz und die Lebenszeit die man verschwendet hat um sich den ausgefeilten Wortlaut dieser beiden Kommentarzeilen (insbesondere der zweiten) auszudenken oder der Zeit die man gebraucht hat um überhaupt auf so eine absurde Idee zu kommen besser damit verbringen einfach in zwei oder drei Zeilen Klartext hinzuschreiben warum der folgende Code notwendig ist oder genau an dieser Stelle stehen muss und zur Abtrennung logischer Abschnitte zwecks Lesbarkeit kann man ganz normale Leerzeilen einfügen so wie man das in anderen Sprachen ebenfalls tut. Edit: Ich bin mir übrigens noch nichtmal sicher ob das obige Konstrukt das Du da vorschlägst überhaupt kompiliert, wahrscheinlich eher nicht. Edit 2:Ich sehe Du hast Dein Posting korrigiert, ich lass das Zitat aber trotzdem stehen, zur Abschreckung.
:
Bearbeitet durch User
Bernd K. schrieb: > Edit 2:Ich sehe Du hast Dein Posting korrigiert, ich lass das Zitat aber > trotzdem stehen, zur Abschreckung. Das spricht für deinen Charakter: wenn jemand anders einen Irrtum bemerkt und korrigiert, muss man natürlich anschließend unbedingt nochmal selbst herausstellen, wie blöd derjenige doch war.
Jörg W. schrieb: > Bernd K. schrieb: >> Edit 2:Ich sehe Du hast Dein Posting korrigiert, ich lass das Zitat aber >> trotzdem stehen, zur Abschreckung. > > Das spricht für deinen Charakter: wenn jemand anders einen Irrtum > bemerkt und korrigiert, muss man natürlich anschließend unbedingt > nochmal selbst herausstellen, wie blöd derjenige doch war. Streitet Euch nicht, sonst ruf ich einen Modera... Oh.
Zeno schrieb: > Sven B. schrieb: >> Hä, aber der Interpreter motzt dann doch. Der streicht dir genau die >> Zeile an und sagt "Unexpected Indentation". Mir ist total unklar, wie >> das ein Problem sein kann. > > Aber nur wenn's eineindeutig ist. Hier würde der Interpreter meckern: > >
1 | > if i<3 |
2 | > print "1" |
3 | > print "2" |
4 | > print "3" |
5 | >
|
> > Hier nicht: >
1 | > if i<3 |
2 | > print "1" |
3 | > print "2" |
4 | > print "3" |
5 | >
|
> > Hier auch nicht und das ist was ich will: >
1 | > if i<3 |
2 | > print "1" |
3 | > print "2" |
4 | > print "3" |
5 | >
|
Und hier auch nicht. Oops.
1 | if (i<3) { |
2 | printf("Wert ist"); |
3 | printf("kleiner");} |
4 | if (i>3) |
5 | printf("Wert ist"); |
6 | printf("groesser"); |
> > Wenn ich jetzt versehentlich 2 geschrieben habe aber 3 möchte suche ich > mir einen Wolf wenn's umfangreicher wird. > Bei Pascal oder auch C meckert der Compiler wenn ich das schließende end > oder die } vergesse. Und er hält brav wieder die Klappe, wenn Du die fehlende Klammer an der falschen Stelle wieder einfügst. Das passiert Dir nie? Dann ist ja alles in Ordnung. Anderen Leuten passieren andere Sachen nie. :-} > Gut falsch setzen kann die schließenden Tags immer noch, aber ich finde > das fällt eher auf - mir geht es jedenfalls so. Erstaunlich. Fehler in einer prominent visuell sichtbaren Notation - Einrückungen - werden übersehen, Eigenschaften, die nicht sichtbar sind, sondern sich erst durch sorgfältiges Abzählen von Klammern ergeben, die fallen auf? Interssant ist auch der Glaube, daß man nur schließende Klammern falsch setzen kann. > Allerdings passiert es > bei modernen Editoren eher selten, da sie nach dem öffnenden Tag sofort > den schließenden in einer neuen Zeile setzen. Das ist eine Heuristik, die oft, aber keineswegs immer stimmt. Vergleichen wir doch mal einen typischen Fall. Man editiert viel häufiger als daß man neuschreibt. Nehmen wir den Fall einer Gruppe von Statements
1 | blubber = 1; |
2 | blather = 3; |
die von einer Bedingung abhängig gemacht werden soll. In Python geht das so:
1 | if wirklich: |
davorschreiben, die beiden obigen Zeilen markieren, TAB zum Einrücken drücken, fertig. Und in C? Die Zeilen markieren und CTRL ALT META PFANNEKUCHEN im EMACS drücken? > > Was ich in Python überhaupt nicht machen kann sind Böcke zur besseren > Strukturierung bzw. wenn ich Quelltextteile besonders hervorheben > möchte. Z.B.: > > Anweisung 1 > Anweisung 2 > Anweisung 3 > Anweisung 4 > Anweisung 5 > Anweisung 6 Stimmt, das kann man überhaupt nicht machen, denn in Python ist die Einrückung syntaktisch signifikant. Also steht sie für solche regelrecht abwegigen Markierungen (die jeder Editor, der sein Geld wert ist, bei der nächsten Gelegenheit wieder spurenlos tilgt) nicht zur Verfügung. Wobei das Idiom, stillzulegende Codeteile durch
1 | if 0: |
2 | Anweisung 1 |
3 | Anweisung 2 |
4 | ... |
zu klammern, durchaus via "if 1" zweckentfremdet werden könnte. Wenn man denn wollte. > > Im Beispiel möchte ich die Zeilen mit den Anweisungen 4 und 5 besonders > hervorheben. Geht in Python nicht in Pascal, C etc. sehr wohl, da dort > Einrückungen keine syntaktische Bedeutung haben. Ich könnte in Pascal > das sogar so schreiben: > > Anweisung 1; > Anweisung 2; > Anweisung 3; > begin > Anweisung 4; > Anweisung 5; > end; > Anweisung 6; > > Natürlich hat diese Klammerung keine syntaktische Bedeutung und wird vom > Compiler einfach weg optimiert, aber für die Lesbarkeit/Kennzeichnung > extrem vorteilhaft. Selbstverständlich hat sie syntaktische Bedeutung, was man sofort sieht, wenn man hinter Anweisung 3 eine Zeile "if <bedingung>" einfügt. > Aber vielleicht geht ja so was auch in Python und ich bin nur zu blöd > dazu, lasse mich aber gern eines besseren belehren - komm jetzt aber > nicht mit Kommentaren, das meine ich nicht Rein technisch gesehen wäre es für Python kein großes Problem, in analoger Weise redundante Einrückungen zu ignorieren. Ich halte die Entscheidung für gut, dies nicht zu tun, sondern es als Anhaltspunkt für ein Versehen zu nehmen.
Jörg W. schrieb: > Bernd K. schrieb: >> Edit 2:Ich sehe Du hast Dein Posting korrigiert, ich lass das Zitat aber >> trotzdem stehen, zur Abschreckung. > > Das spricht für deinen Charakter: wenn jemand anders einen Irrtum > bemerkt und korrigiert, muss man natürlich anschließend unbedingt > nochmal selbst herausstellen, wie blöd derjenige doch war. Du kannst es von mir aus auch löschen. Diesen ganzen unsinnigen Thread wird sich eh keiner mehr von Anfang bis Ende durchlesen und schon morgen oder spätestens übermorgen werden wieder zwei neue Seiten endloser Wiederholungen, haltloser Spekulationen und konstruierter Szenarien ohne praktische Relevanz drüber gewachsen sein.
:
Bearbeitet durch User
Bernd K. schrieb: > Jörg W. schrieb: >> Bernd K. schrieb: >>> Edit 2:Ich sehe Du hast Dein Posting korrigiert, ich lass das Zitat aber >>> trotzdem stehen, zur Abschreckung. >> >> Das spricht für deinen Charakter: wenn jemand anders einen Irrtum >> bemerkt und korrigiert, muss man natürlich anschließend unbedingt >> nochmal selbst herausstellen, wie blöd derjenige doch war. > > Du kannst es von mir aus auch löschen. Diesen ganzen unsinnigen Thread > wird sich eh keiner mehr von Anfang bis Ende durchlesen und schon morgen > oder spätestens übermorgen werden wieder zwei neue Seiten endloser > Wiederholungen, haltloser Spekulationen und konstruierter Szenarien ohne > praktische Relevanz drüber gewachsen sein. Erstaunlich das der Thread nun schon über ein Jahr läuft. Ja und ich muß mich selbst an die Nase fassen. Bin heut selbst drüber gestolpert und habe mir dummerweise auch den ganzen Thread rein gezogen. Aber hinterher ist man halt immer schlauer. @Wolfgang S. >Stimmt, das kann man überhaupt nicht machen, denn in Python ist die >Einrückung syntaktisch signifikant. Also steht sie für solche >regelrecht >abwegigen Markierungen (die jeder Editor, der sein Geld wert ist, bei >der nächsten Gelegenheit wieder spurenlos tilgt) nicht zur Verfügung. Das hab ich ja noch nie gehört. Was verwendest Du für einen Editor? Ein Editor der eigenmächtig Text verändert gehört von der Festplatte entsorgt. Eine solcher Editor ist wahrscheinlich das Heinzelmännchen welches dem Threaderöffner Bal das Leben schwer macht. @Jörg >Das spricht für deinen Charakter: wenn jemand anders einen Irrtum >bemerkt und korrigiert, muss man natürlich anschließend unbedingt >nochmal selbst herausstellen, wie blöd derjenige doch war. Laß es gut sein. Kritik an Python und jede andere Meinung zum Thema wird hier nicht geduldet. Du und einige andere haben halt eine andere Meinung zu diesem Feature von Python. Einige Leute fühlen sich dadurch gleich angepisst und müssen das Ganze auf Teufel komm raus gut reden. Es gibt Dinge die kann man einfach nicht gut reden, selbst wenn die dahinter stehende Überlegung im Ansatz gut ist. Selbst wenn eine Programmiersprache Schwächen aufweist, kann und wird man sie benutzen, wenn sie für den vorgesehenen Zweck optimal scheint. Keine Programmiersprache ist perfekt - habe ich ein paar Postings weiter oben schon mal gesagt-, aber es gehört schon eine gewisse Größe dazu sich dies einzugestehen, insbesondere dann wenn es die Lieblingssprache ist. Diese Größe fehlt hier offensichtlich einigen und insofern ist jede weitere Diskussion müßig. Zeno
Zeno schrieb: > Keine Programmiersprache ist perfekt Wenn man bedenkt, dass die Menschheit seit nunmehr reichlich 60 Jahren an Programmiersprachen werkelt...
Mark B. schrieb: > Wenn man bedenkt, dass die Menschheit seit nunmehr reichlich 60 Jahren > an Programmiersprachen werkelt... Das ist doch mal nüchtern betrachtet ein sehr kurzer Zeitraum. Kein Mensch ist perfekt! Und jetzt überlege mal wie lange es die Menschheit gibt. Da sind doch 60 Jahre Peanuts. Zeno
Zeno schrieb: > Mark B. schrieb: >> Wenn man bedenkt, dass die Menschheit seit nunmehr reichlich 60 Jahren >> an Programmiersprachen werkelt... > > Das ist doch mal nüchtern betrachtet ein sehr kurzer Zeitraum. > > Kein Mensch ist perfekt! Und jetzt überlege mal wie lange es die > Menschheit gibt. Da sind doch 60 Jahre Peanuts. Die Autos, die es 60 Jahre nach Erfindung des Automobils gab, waren schon verdammt gut - im Rahmen des damals technisch Machbaren. Beim Computer ebenso. Wenn man mich fragen würde, welche Programmiersprache so richtig verdammt gut ist - ich wüsste ehrlich gesagt nicht welche ich nennen soll. Man ist im Grunde genommen immer noch sehr weit davon entfernt, der Maschine ein Problem zu schildern, welches sie lösen soll.
:
Bearbeitet durch User
Mark B. schrieb: > Man ist im Grunde genommen immer noch sehr weit davon entfernt, > der Maschine ein Problem zu schildern, welches sie lösen soll. Genau das ist es. Deshalb muß man immer schauen mit welcher Programmierspache man das anstehende Problem am effizientesten lösen kann. Es gibt da keine allgemein gültige Regel. Manche Programmiersprachen wurden entwickelt um ein spezielles Problem effizient zu lösen. Und dies tun sie dann oftmals sehr gut. Natürlich kann man mit ihnen auch andere Dinge tun, aber ob es dann effizient ist steht auf einem anderen Blatt. Z.B. Fortan : Für mathematische Lösungsalgotithmen sehr gut geeignet. Arrayfunktionen auch optimal. Aber Stringverarbeitung eher Grotte. Letztendlich ist unter Umständen eine sinnvolle Kombination verschiedener Programmiersprachen zielführend. Aber das war hier nicht das Thema.
Interessant, wie viele Tools, Workarounds, Plugins, etc, es gibt fuer ein Problem, das angeblich keins ist. Dabei muesste es auch echt keines sein, wuerde man die Syntax als Skin ueber die Sprache legen. Dann koennten die einen Python mit und die anderen Python ohne Klammern programmieren und die Naechsten mit begin/end...
SloJo schrieb: > Interessant, wie viele Tools, Workarounds, Plugins, etc, es gibt fuer > ein Problem, das angeblich keins ist. Ach hör doch auf, C++ oder irgendeine andere Sprache ohne vernünftigen Editor zu schreiben der dir dabei hilft ist mindestens genauso schmerzhaft. Natürlich gibt es Tools, die die Sprache spezifisch unterstützen. Das wird aber sinnvoll sein völlig egal wie die Sprache aussieht.
SloJo schrieb: > Dann > koennten die einen Python mit und die anderen Python ohne Klammern > programmieren und die Naechsten mit begin/end... Die Vorzüge von Python liegen einfach nicht darin, ob man mit oder ohne Klammern programmiert, sondern darin, dass es: a) viele Programmierparadigmen unterstützt b) jede Menge Pakete/Plugins (numpy, GUI, ...) gibt c) unter Linux Standard ist d) plattformunabhängig ist e) man keine Funktionen überladen muss f) keinen Pufferüberlauf gibt g) erlaubt kompakten Code zu schreiben h) man kann von quick and dirty bis zu richtiger Softwareentwicklung alles machen Wer auf die ganzen Vorteile verzichten will, weil man lieber mit Klammern arbeitet, der soll dies tun. Es läuft doch ehr darauf hinaus, wie es auch mit dem Arduino ist. Die "alten Hasen" haben Monate gebraucht, um eine LED zum blinken zu bringen, nur die besten haben überlebt, und heute baut jeder Jungspund sein Ding mit Webserver und Bluetooth, ohne auch nur einmal sich mit Registern beschäftigen zu müssen.
Karl schrieb: > a) viele Programmierparadigmen unterstützt Das ist kein Alleinstellungsmerkmal von Python. https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages > b) jede Menge Pakete/Plugins (numpy, GUI, ...) gibt Die gibt es bei anderen populären Sprachen auch. > c) unter Linux Standard ist Der Standard unter Linux ist immer noch C. Abgesehen davon: Wer in der Sprache X programmieren will, installiert sich die Tools für diese. > d) plattformunabhängig ist Seit wann sind C, C++, Java oder LISP plattformabhängig? > e) man keine Funktionen überladen muss Müssen tut man das in keiner Sprache. In C++ zum Beispiel kann man es. > f) keinen Pufferüberlauf gibt kein Alleinstellungsmerkmal, siehe z.B. Java und C# > g) erlaubt kompakten Code zu schreiben kein Alleinstellungsmerkmal > h) man kann von quick and dirty bis zu richtiger Softwareentwicklung > alles machen Das gilt für nahezu jede höhere Programmiersprache, die Bibliotheken für die unterschiedlichsten Anwendungsfälle bietet. Also für ziemlich viele.
:
Bearbeitet durch User
Mark B. schrieb: > Karl schrieb: > > Das ist kein Alleinstellungsmerkmal von Python. > https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages Wurde auch nicht behauptet. >> b) jede Menge Pakete/Plugins (numpy, GUI, ...) gibt > > Die gibt es bei anderen populären Sprachen auch. aha, eine gui in C? >> c) unter Linux Standard ist > > Der Standard unter Linux ist immer noch C. Abgesehen davon: Wer in der > Sprache X programmieren will, installiert sich die Tools für diese. Der Pythoninterpreter ist in den Meisten Distributionen, die JRE oft nicht, das meinte ich damit. > Seit wann sind C, C++, Java oder LISP plattformabhängig? C/C++ muss neu Compiliert werden, bei Verwendung von dlls hat es sich. > Müssen tut man das in keiner Sprache. In C++ zum Beispiel kann man es. Aber ich eine Funktion mit einem Parameter int aufrufen möchte, aber ein real übergebe, dann geht es nicht. D.h. ich muss 2 Funktionen schreiben. > kein Alleinstellungsmerkmal, siehe z.B. Java und C# Hat auch niemand behauptet. >> g) erlaubt kompakten Code zu schreiben > > kein Alleinstellungsmerkmal Hat auch niemand behauptet. Aber schreibt doch mal a=5 b=2 c = a^b in Java, dann merkst du vielleicht was. >> h) man kann von quick and dirty bis zu richtiger Softwareentwicklung >> alles machen > > Das gilt für nahezu jede höhere Programmiersprache, die Bibliotheken für > die unterschiedlichsten Anwendungsfälle bietet. Also für ziemlich viele. Du hast es nicht verstanden.
Karl schrieb: > aha, eine gui in C? Ja, warum nicht? X11 ist in C geschrieben. Die bei Python üblichen GUIs sind ja nun auch nicht in Python selbst entstanden (Tk kommt von Tcl, war übrigens auch mal ziemlich „behypet“, Qt ist C++). > C/C++ muss neu Compiliert werden, bei Verwendung von dlls hat es sich. Man braucht den Sourcecode, bei Python aber auch. Das allein sichert natürlich noch keine plattformübergreifende Benutzbarkeit zu, aber auch bei Python gibt es durchaus Code, der nur auf bestimmten Plattformen benutzbar ist. Es ist dort nur sehr viel häufiger Code anzutreffen, der portabel ist als bei C++. >> Müssen tut man das in keiner Sprache. In C++ zum Beispiel kann man es. > > Aber ich eine Funktion mit einem Parameter int aufrufen möchte, aber ein > real übergebe, dann geht es nicht. D.h. ich muss 2 Funktionen schreiben. Default-Werte für Argumente gibt es in C++ ebenfalls, allerdings kann man sie nur von hinten nach vorn weglassen, da man bei der Übergabe die Parameter nicht benennen kann. Aber die positionsabhängige Variante (statt der benannten) hat Python ja auch.
:
Bearbeitet durch Moderator
Mooooment, was hier immer missverstanden wird: Python ist gut, verdammt gut sogar. Deswegen verstehe ich das aufkeimenende C++ vs. Python gerade nicht. Ich kann das hier komplett unterschreiben: Karl schrieb: > Die Vorzüge von Python liegen einfach nicht darin, ob man mit oder ohne > Klammern programmiert, sondern darin, dass es: > a) viele Programmierparadigmen unterstützt > b) jede Menge Pakete/Plugins (numpy, GUI, ...) gibt > c) unter Linux Standard ist > d) plattformunabhängig ist > e) man keine Funktionen überladen muss > f) keinen Pufferüberlauf gibt > g) erlaubt kompakten Code zu schreiben > h) man kann von quick and dirty bis zu richtiger Softwareentwicklung > alles machen Trotzdem sind die Whitespaces als syntaktisches Element scheiße. Davon rück ich nicht ab.
le x. schrieb: > Trotzdem sind die Whitespaces als syntaktisches Element scheiße. Davon > rück ich nicht ab. Und darum geht es in diesem Thread, auch wenn gerade ein paar Leute mit Argumentmangel auf einen Nebenschauplatz ausweichen wollen.
Karl schrieb: > Die Vorzüge von Python liegen einfach nicht darin, ob man mit oder ohne > Klammern programmiert, sondern darin, dass es: > a) viele Programmierparadigmen unterstützt Aber leider nur ein Formatierparadigma. Worum es hier geht. > Es läuft doch ehr darauf hinaus, wie es auch mit dem Arduino ist. D.h., Python ist das Arduino-Equivalent bei Programmiersprachen?
SloJo schrieb: > D.h., Python ist das Arduino-Equivalent bei Programmiersprachen? Damit könnte man gut leben: ist halt nicht alles ideal dran, aber es tut seinen Zweck, und man kommt häufig schnell damit zum Ziel.
Karl schrieb: >>> h) man kann von quick and dirty bis zu richtiger Softwareentwicklung >>> alles machen >> >> Das gilt für nahezu jede höhere Programmiersprache, die Bibliotheken für >> die unterschiedlichsten Anwendungsfälle bietet. Also für ziemlich viele. > > Du hast es nicht verstanden. Das bezweifle ich. Die Qualität eines Software-Projekts oder eines Software-Entwicklungsprozesses hängt nicht von der Programmiersprache ab. "Man kann in jeder Programmiersprache schlechten Code schreiben."
:
Bearbeitet durch User
Mark B. schrieb: > "Man kann in jeder Programmiersprache schlechten Code schreiben." Real Programmers can write FORTRAN programs in any language.
Jörg W. schrieb: > Real Programmers can write FORTRAN programs in any language. Korrekt. Man kann auch Java-Programme in C schreiben :-) http://www.ioccc.org/2005/chia/chia.c
Karl schrieb: > d) plattformunabhängig ist Das ist natürlich Blödsinn. Die Plattformunabhängigkeit kommt nur durch den für das jeweilige System eingesetzten Interpreter zustande. Wenn es für das System keinen Interpreter gibt wird Dein Pythoncode nicht laufen. Das ist so wie bei Java, Smalltalk etc. Und wenn Du in Deinem Code systemspezifische Sachen benutzt wird es auf dem anderen System ebenfalls nicht funktionieren. >Aber ich eine Funktion mit einem Parameter int aufrufen möchte, aber ein >real übergebe, dann geht es nicht. D.h. ich muss 2 Funktionen schreiben. Das es so rum nicht geht ist doch wohl normal. Wenn ich an eine Funktion ein Real also Float übergebe, diese jedoch einen Int erwartet dann wird das nicht funktionieren und ist auch völlig sinnlos. Das ist eigentlich das Hauptproblem bei dynamischer Typisierung da kann halt auch mal schnell Schrott rauskommen oder zumindest eine Exception. Im Übrigen kann man z.B. auch in Objectpascal Funktionen schreiben die unterschiedliche Datentypen übernehmen, dafür gibt es dort den Datentyp VARIANT - dem kannst Du so ziemlich alles übergeben. @Jörg Ich glaube Karl meinte hier >Default-Werte für Argumente gibt es in C++ ebenfalls, allerdings >kann man sie nur von hinten nach vorn weglassen, da man bei der >Übergabe die Parameter nicht benennen kann. Aber die >positionsabhängige was anderes. Aber das was Du da beschreibst (optionale Parameter, Defaultparameter) geht bei Pascal schon immer. Aber letztendlich ist das alles nicht das Thema des Threads. Um noch einmal auf den Ursprung -Einrückung als Sprachmerkmal- zurück zu kommen. Ich habe mittlerweile auch schone ein paar Dinge mit Python gemacht. Python ist gut hat viele gute Features und gerade im Bereich RasPi kommt man schnell zu einem Ergebnis. Ich gebe auch ehrlich zu, das ich Anfangs das mit Einrückung gut fand, weil es zu sauberen Quelltext zwingt. Die Praxis hat mir aber gezeigt, das es doch eher mehr hinderlich ist, insbesondere dann wenn man nur gelegentlich Python benutzt und dann einen Fehler suchen muß. Aber wer damit gut zurecht kommt und seine Aufgaben damit erledigen kann soll es benutzen. Ein schlechtes Feature sagt doch nichts über die Gesamtqualität der Sprache aus. Es gibt nach meiner Meinung andere Sprachen die mehr Designfehler haben und dennoch sehr gut eingeführt sind. Zeno
Zeno schrieb: > Aber das was Du da beschreibst (optionale Parameter, Defaultparameter) > geht bei Pascal schon immer. War mir gar nicht mehr bewusst. Da ist mein Pascal wohl schon zu sehr eingerostet dafür :), obwohl ich es zu CP/M-Zeiten gern genutzt habe (und auch auf RSX auf einem PDP-11-Clone). > Es gibt nach meiner Meinung andere Sprachen die mehr > Designfehler haben und dennoch sehr gut eingeführt sind. Dem würde ich keineswegs widersprechen. Man muss sich die blöden (OK, meine Meinung :) Einrückungen in Python weißgott nicht schön reden, und kann es dennoch produktiv benutzen. Aber man sollte dann auch (so wie derjenige, der diesen alten Thread aus der Versenkung geholt hat) mal drüber fluchen dürfen, wenn einem genau das eben gerade mal wieder total auf die Zehen gefallen ist. Ich würde wohl nicht so lauthals und öffentlich fluchen wie er, aber fluchen würde ich dennoch drüber. „Fluchen ist die Sprache, die Programmierer am besten beherrschen.“ (Autor unbekannt)
Jörg W. schrieb: > Da ist mein Pascal wohl schon zu > sehr eingerostet dafür Nö das geht soweit ich mich erinnern kann schon ab Turbopascal.
Zeno schrieb: > Nö das geht soweit ich mich erinnern kann schon ab Turbopascal. Ich meinte ja auch meine Erinnerung daran. Vermutlich habe ich es wirklich seit 25 Jahren nicht mehr in den Fingern gehabt.
Jörg W. schrieb: > mal drüber fluchen dürfen Das sehe ich genau so. Man muß Fehler, oder besser Dinge die man dafür hält - andere können das ja ganz anders sehen -, auch ansprechen dürfen ohne gleich dumm angemacht zu werden, wie es leider viel zu häufig hier im Forum passiert. Sag da mal was zu C, da geht aber was los und da fühlen sich dann einige Leute auch gleich derart auf den Schlips getreten, daß es nur noch unter der G-Linie geht. Leider sind viel zu wenige fähig über den Tellerand zu schauen. Es ist wie immer im Leben jedes Ding hat zwei Seiten - eine Gute und eine weniger Gute. Zeno
Jörg W. schrieb: > SloJo schrieb: >> D.h., Python ist das Arduino-Equivalent bei Programmiersprachen? > > Damit könnte man gut leben: ist halt nicht alles ideal dran, aber > es tut seinen Zweck, und man kommt häufig schnell damit zum Ziel. Im Unterschied zu Arduino macht python bei anspruchsvolleren Projekten/Problemen nicht schlapp. Es skaliert sehr gut von kleinen Einmalskripten bis hin zu umfangreichen Anwendungen. Insofern ist es auch kein großes Drama, wenn sich aus dem Einmalskript unbeabsichtigt was größeres entwickelt. Was python für mich auszeichnet ist, dass es für jedes Aufgabengebiet gute Bibliotheken hat, die einfach anzuwenden sind. So im Vergleich zu Anwendungsspezifischen sprachen wie MATLAB oder PHP. Mal so einige Beispiele: - digitale Signalverarbeitung: numpy/scipy - DLL wrappen, um komische Hardware anzusteueren: ctypes - mit Messgeräten reden: pyvisa - komplexe GUIs bauen: Gtk/pygobject, Tk wollte mir nie so recht gefallen - kleine Webapp: flask - Webseiten scrapen: beautifulsoup - Interaktiv skripten: ipython notebook / jupyter Auch ist es nicht allzu schwer, Module in C zu schreiben, wenn's um Performance geht. Dazu hat man eine ausdrucksstarke Sprache (functools, itertools, {list,dict,generator}-comprehensions) mit einer umfangreichen Standardbibliothek - was will man mehr? Ich benutze python seit mittlerweile über 6 Jahren, python hat mich auch bei neuen Aufgabenfeldern niemals 'im Stich gelassen'. Das angesprochene Problem mit langen Debuggen wegen falscher Einrückung hatte ich nie. A+++++ Would buy again.
Lukas K. schrieb: > Im Unterschied zu Arduino macht python bei anspruchsvolleren > Projekten/Problemen nicht schlapp. Was soll das blöde Arduino-Vorurteil hier? Ich sehe wirklich beide (auf ihre Weise) in der gleichen Kategorie: es gibt jeweils durchaus performantere Lösungen (keiner wird bestreiten, dass ein durchcompiliertes C-Programm häufig performanter als ein interpretierter Python-Script ist; keiner wird bestreiten, dass ein maßgeschneiderter Controller besser als eine Dosenlösung mit Arduino und digitalwrite() ist), aber es sind jeweils gute Allrounder.
Lukas K. schrieb: > Auch ist es nicht allzu schwer, Module in C zu schreiben, wenn's um > Performance geht. Das ist natürlich ein klarer Vorteil von Python: Wenns zu lahm ist, steigt man auf was Flottes um. In Projekten ohne Python hat man diese Möglichkeit ja leider nicht. Schade aber auch ;-) Jörg W. schrieb: > Was soll das blöde Arduino-Vorurteil hier? > > Ich sehe wirklich beide (auf ihre Weise) in der gleichen Kategorie: > es gibt jeweils durchaus performantere Lösungen > [...] aber es sind jeweils gute Allrounder. Dem kann ich nur zustimmen.
:
Bearbeitet durch User
Zeno schrieb: > Jörg W. schrieb: >> Da ist mein Pascal wohl schon zu >> sehr eingerostet dafür > > Nö das geht soweit ich mich erinnern kann schon ab Turbopascal. Mal so nebenbei angemerkt, mich interessiert auch immer wie viel Resonanz seitens der User gibt es für die jeweilige Programmiersprache, insbesondere auch für attraktive integrierte Entwicklungsumgebungen wie beispielsweise Lazarus-ide oder SharpDevelop (um mal zwei exemplarisch herauszugreifen). Ich habe mir deshalb angewöhnt immer zu schauen, wie rege die jeweilige Forenbeteiligung dabei ist. Bei SharpDevelop erlebt man ein Trauerspiel. Man hat das Gefühl das Produkt ist tot. Anfragen werden kaum noch beantwortet. In bekannten Delphi-Foren bewegt sich auch nicht mehr sehr viel. http://forum.delphi-treff.de/ Es wirkt auf mich irgendwie wie ein geschlossener Club bei dem die alten Clubmitglieder bereits alles wissen und neue nicht mehr nachströmen. Ganz anders ist das bei Lazarus. Dort wird emsig gepostet. Lazarus scheint viel mehr Leute anzuziehen als SharpDevelop, obwohl beide kostenfreie Produkte und Anfänger freundlich sind (weil noch überschaubar). http://forum.lazarus.freepascal.org/index.php Bei Programmiersprachen der jüngeren Zeit wie Rust, Nim, go usw. findet man z.T. gar keine "richtigen" Foren, sondern eher Blogs (Nim hat ein ordentliches Forum). Sucht man dann auch noch nach deutsch sprachigen Foren (auch wenn man engl. kann) erlebt man geradezu ein Trauerspiel. Entweder nicht vorhanden oder verwaist, siehe beispielsweise http://community.sharpdevelop.net/forums/24.aspx Was mir auch ein Rätsel ist, wie eine in meinen Augen ansprechende Webseite wie U++ http://www.ultimatepp.org/forums/ es gerade mal auf 1358 Registrierte Nutzer bringt. Was macht die so unattraktiv? Warum sind die so unterrepräsentiert? Ähnliches erlebt man, wenn man nach Erweiterungen schaut wie beispielsweise windows gui Frameworks, cross Framework gui usw. Bestrebungen zur Vereinfachung der Benutzung solcher FW hat U++ bereits (sonst könnten ja alle das allumfassende qt nehmen und gut ist für jedermann). Aber anscheinend reicht das manchen nicht und es entsteht neues (hier für C++) http://nanapro.org/en-us/ Leider wie es aussieht nur ein Ein-Mann-Projekt und entsprechend unbedeutend könnte es bald wieder in der Versenkung verschwinden, wie so viele andere Experimente dieser Art. Überhaupt ist es nicht selten und man stößt auf letzte Aktualisierungen die bereits Jahre zurückliegen. Das Interesse ist dann wohl verloren gegangen und das Produkt nicht mehr empfehlenswert. Lebendige Foren sind ein Indikator dafür was noch attraktiv ist oder was eher links liegen gelassen wird, was viele anzieht oder was wenig Resonanz erzeugt. Oder sollte etwa gelten, keine Postings, weil keine Probleme, also alles super toll? Ich glaube das nicht. Dort wo Interesse herrscht wird auch gepostet. Fehlende Forenaktivität ist ein Warnzeichen, hier stimmt etwas nicht. Nur ein paar Gedanken.
Mark B. schrieb: > Lukas K. schrieb: >> Auch ist es nicht allzu schwer, Module in C zu schreiben, wenn's um >> Performance geht. > > Das ist natürlich ein klarer Vorteil von Python: Wenns zu lahm ist, > steigt man auf was Flottes um. In Projekten ohne Python hat man diese > Möglichkeit ja leider nicht. Schade aber auch ;-) Ja ne. Nicht umsteigen, sondern gemeinsam verwenden. Den nicht performance-relevanten Teile wie GUI, Konfiguration und so baut man in Python. Den performance-kritischen Teil kann man dann in C schreiben.
Mark B. schrieb: > In Projekten ohne Python hat man diese > Möglichkeit ja leider nicht. Wieso soll das in anderen Sprachen nicht gehen. Wenn ich z.B. einen schnellen mathematischen Algorithmus brauche, dann schreibe ich das z.B. mit FORTRAN in eine DLL (respektive Lib unter Linux) und das funktioniert bei komplizierten Dingen trotz Laden der DLL und Parameterübergabe immmer noch schneller. Aber Leute das ist doch gar nicht das Thema. Es ging doch lediglich um die Einrückungen bei Phyton. DEn einen gefällt es und sie finden es toll -das mit den Einrückungen - und die anderen sehen es eher skeptisch und finden es nicht so prickelnd. Ist doch alles gut. Zeno
ach naja schrieb: > In bekannten Delphi-Foren bewegt sich auch nicht mehr sehr viel. Ja das ist leider so. Das hat aber mit der blöden Politik von Borland-Inprise-Borland-Embacadero zu tun. Das aktuelle Delphiprodukt inclusive IDE ist immer noch gut. Leider sehen das viele Chefs, obwohl sie Null Ahnung davon haben, anders und setzen deshalb auf .NET und C#, weil es gerade hip ist. Ich sehe das anders aber mich fragt ja keiner. Zeno
Zeno schrieb: > Mark B. schrieb: >> In Projekten ohne Python hat man diese >> Möglichkeit ja leider nicht. > > Wieso soll das in anderen Sprachen nicht gehen. Das war ironisch gemeint.
Lukas K. schrieb: > Nicht umsteigen, sondern gemeinsam verwenden. Den nicht > performance-relevanten Teile wie GUI, Konfiguration und so baut man in > Python. Den performance-kritischen Teil kann man dann in C schreiben. Ja, bis vor einigen Jahres war das wohl OK. Ich hatte in den letzten Jahren viel Ruby verwendet, wobei da das C-Interface noch besser/einfacher ist als bei Python. Python ist OK, wenn man keine hohe Performance benötigt und das Programm nur einige hundert Zeilen hat. Oder wenn man unbedingt Sachen wie matplotlib, numpy usw. verwenden möchte. Aber seit eigen Jahren gibt es bessere Sprachen, die Performance von C und Einfachheit von Python/Ruby gut vereinen. Aber leider kann man sie nicht immer verwenden -- aus verschiedenen Gründen.
Beitrag #4974871 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten