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:
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.
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
>ifi<3
2
>print"1"
3
>print"2"
4
>print"3"
5
>
>> Hier nicht:>
1
>ifi<3
2
>print"1"
3
>print"2"
4
>print"3"
5
>
>> Hier auch nicht und das ist was ich will:>
1
>ifi<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.
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.
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.
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.
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."
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)
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.
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.
Thread beobachten
Seitenaufteilung abschalten