Hallo! Ich lesen immer öfter von Projekten wo Python für Hardware Programmierung genutzt wird. Soweit ich weiß ist C/C++ sehr Hardware nah und im Bereich der Hardware Programmierung am weitesten verbreitet, aber was hält ihr von Python im Bereich der Hardware Programmierung? Kann es eine Alternative zu C/C++ sein? Ist der Code mit Python auch so effizient und schnell wie mit den C's? Ich freue mich auf eure Antworten!
Wie schnell Python Programme laufen, hängt sehr stark von der Laufzeitumgebung ab. PC's haben genug Power, um die Scripte zur Laufzeit in nativen Code zu übersetzen (JIT). Auf Mikrocontrollern wirst du jedoch meistens einen Script-Interpreter haben, der erheblich langsamer arbeitet. Ich schätze mal um Faktor 10. Doch selbst mit JIT übersetzte Python Scripte laufen noch deutlich langsamer als C/C++. Hier muss man allerdings sagen, dass ein schlecht gemachter Algorithmus noch viel mehr Performanceverlust kosten kann. Zeitkritische Sachen werden oft als C Bibliothek programmiert und dann als Modul in Python Scripte eingebunden. Also: Ja, Python ist eine erst zu nehmende Alternative auf den "großen" Mikrocontrollern. Auf dem ESP8266 läuft ein Python Interpreter so gerade eben mit eingeschränktem Funktionsumfang. Auf einem Arduion Uno wird Python hingegen niemals laufen können. Schau dir mal die Produkte von Makeblock an. Einige kann man in Arduino C/C++ programmieren und einige in Python. z.B. der Codey (http://stefanfrings.de/codey/index.html).
Es gibt noch einige Ansätze: - Python-Prozessoren (eingeschränktes Python, was in Maschinencode übersetzt) - micropython - Python als HDL, da ist es allerdings meist Beschreibung einer synchronen Funktionalität als Programmieren und am Schluss kommt ein FPGA- oder Chip-Design bei raus Man kann auch aus Python heraus sehr effizienten Code generieren (google Stephen Diehl, llvm), der dann auf einem uC läuft. Ist aber alles recht spezialisierte Technologie.
Wenn Du nicht der Freitagstroll bist: Gegenfrage: Warum? Was hat Python, dass da viele so drauf anspringen? Was bietet Python, was C/C++ (insb. auf uC!) nicht bietet oder besser kann? Der Leser ahnt es schon: ich mag Python nicht (auch nicht auf Non-uC). Unklares Speichermanagement, unklare typen, wer denkt sich Einrückungen als Spracheigenschaft aus …
Ich habe Python auf dem Raspi benutzt, mit PIGPIO. Wirklich zeitkritisches geht damit nicht, soweit ich es probiert habe. Aber vielleicht läßt es sich auch noch optimieren. https://github.com/joan2937/pigpio http://abyz.me.uk/rpi/pigpio/python.html
Stephan schrieb: > Was hat Python, dass da viele so drauf anspringen? Das haben die Jungs mit dem RPi angerichtet. Um möglichst wenig von der Hardware preiszugeben, haben sie das mit Python kaschiert.
Peter schrieb: > Ich lesen immer öfter von Projekten wo Python für Hardware > Programmierung genutzt wird. "Hardware Programmierung" ist Unsinn. Alle Programme laufen am Ende auf irgendeiner Hardware. Was du wohl meinst ist hardwarenahe Programmierung. Im Gegensatz zur Programmierung inner- und unterhalb eines Betriebssystems. > was hält ihr von Python im Bereich der Hardware Programmierung? > Kann es eine Alternative zu C/C++ sein? Ist der Code mit Python > auch so effizient und schnell wie mit den C's? Die meisten Python-Implementierungen sind (Bytecode)-Interpreter. Es ist zwar denkbar, Python direkt im Maschinencode zu compilieren, aber in der Praxis wird es dann eher zu C oder JVM-Bytecode compiliert. Das und die dann erforderliche Laufzeitumgebung blähen den Code so sehr auf, daß nur große µC (die man eher SOC nennt - system on chip) wie z.B. Raspberry Pi überhaupt dafür geeignet sind. Die sind dann dank mehreren Hundert MHz Taktfrequenz auch schnell genug, um den Bloat nicht mehr spüren zu lassen. Da der Trend immer mehr in diese Richtung geht (Ressourcenverbrauch spielt anscheinend keine Rolle mehr) werden auch Sprachen wie Python immer mehr hoffähig. Als hardwarenah würde ich das allerdings nicht bezeichnen.
Stephan schrieb: > Was hat Python, dass da viele so drauf anspringen? Es ist anders dokumentiert, in einer Form die dem Nachwuchs offenbar besser gefällt. Außerdem hat Python eine umfangreichere Standard Bibliothek, als C. Damit kann man viele coole Sachen "out of the Box" machen. Zum Beispiel ein Dokument von einem Webserver abrufen, irgend etwas heraus parsen und das dann per Email verschicken. > wer denkt sich Einrückungen als Spracheigenschaft aus … Ich finde das auch ganz schrecklich, habe aber bemerkt dass jüngere Leute das wesentlich lockerer sehen. Es hat aber auch eine gute Seite: Ich habe noch kein völlig unleserlich eingerücktes Python Script gesehen, denn das würde nicht funktionieren.
Habe selber auch nur mit Python auf PC gearbeitet, aber wenn die Arbeitsfunktionen in C/C++ geschrieben sind, dann ist (Micro)Python als GlueLogic scheinbar ganz brauchbar, siehe z.B. Projekte wie https://forum.lvgl.io/t/100-mhz-oscilloscope-with-raspberry-pi-pico-lvgl-v8-and-micropython/5669 Die µC können heute sehr viel in Hardwaredevices erledigen, das zu nutzen halte ich auch für besser als hochoptimierte, und dadurch unleserlicher/unwartbartbarer Code. Die 'GlueLogic' kenne ich allerdings noch von MS Ansatz mit COM/DCOM, wo VB die GL für C++ Komponenten war. Man musste dann auch in beiden Welten fit sein um das zu beherrschen. Und warum wird immer auf das Einrücken rumgeritten? Wenn man Code sowieso zur besseren Lesbarkeit formattiert, dann kann man Klammern oder gar begin; end; auch gleich weglassen. Ist nur eine Gewöhnungssache bis man die Strukturen genause schnell wie im C Code erkennt.
Peter schrieb: > Ist der Code mit Python auch so effizient und schnell wie mit den > C's? Da Python meistens (immer?) auf einem Interpreter läuft, ist es um Größenordnungen langsamer und braucht deutlich mehr Speicher und CPU-Leistung. Es ist eine Scriptsprache die sicher ihre Berechtigung und Anwendung hat, aber sicher nicht für hardwarenahe Programmierung von kleinen bis mittleren Mikrocontrollern.
Circuitpython kennt ihr? https://circuitpython.org/ bzw. das Original: https://micropython.org/ Aus performancetechnischer Sicht macht das nicht so viel Sinn. Aber ich behaupte mal, dass damit die Einstiegshürden für die MCUs sogar gegenüber Arduino noch einmal deutlich gesunken sind.
Stephan schrieb: > Gegenfrage: Warum? > Was hat Python, dass da viele so drauf anspringen? Was bietet Python, > was C/C++ (insb. auf uC!) nicht bietet oder besser kann? Eigentlich ganz einfach: Python hatte am Anfang ein paar sehr einfache Möglichkeiten dabei, um sich Graphen, Diagramm, Verläufe u.ä. graphisch anzeigen zu lassen. Dadurch wurde es in der Wissenschaft – wo kaum jemand ernsthaft programmieren kann, es aber dennoch häufig getan wird – rasch populär. Dadurch gab es für jeden Kleinkram schnell irgendeine vorgefertigte Bibliothek, und schon wurde die Sprache immer größer, bekannter, usw. Und dann folgt halt irgendwann der nächste logische Schritt, den wir bisher z.B. auch schon von Arduino kennen: Es wird ein einfaches System entwickelt für fachfremde Leute, die sich mit der Technik nicht näher auseinandersetzen müssen. Und am Ende bildet dieses System die Basis für Produkte, entwickelt von Leuten, die sich mit der Funktionsweise ihres Werkzeugs nicht mehr auseinandersetzen.
> Ist der Code mit Python auch so effizient und schnell wie mit den > C's? Etwa Faktor 10 langsamer als C. Es ist damit ein Zeichen unserer Zeit, um faul zu sein will man Energie verschwenden bis der Arzt kommt. Damit fuer ernsthafte Anwendung die letztlich bei Kunden landen sollen unbrauchbar da es sonst immer jemanden gibt der dasselbe billiger oder mit laengerer Akkulebensdauer hinbekommt. Das eine Sprache die mit Einrueckungen arbeitet ein Schuss ins Hirn ist, ist natuerlich auch klar. Ihre Berechtigung hat die vermutlich auf dem Level wo man frueher awk oder sed verwendet hat. Olaf
Odoo (https://www.odoo.com/de_DE) ist komplett in Python programmiert. Interessant finde ich, dass man damit überhaupt so große Projekte umsetzen kann. Es läuft aber auch rasch unerträglich lahm, sobald man eine ernsthafte Menge von Datensätzen angelegt hat. Wir (in der Firma) haben den Test deswegen abgebrochen und beschlossen, es nicht zu verkaufen (bzw. dafür zu entwickeln).
Tim . schrieb: > Aus performancetechnischer Sicht macht das nicht so viel Sinn. Aber ich > behaupte mal, dass damit die Einstiegshürden für die MCUs sogar > gegenüber Arduino noch einmal deutlich gesunken sind. Also negativ? D.h. man wird förmlich in die MCUs reingesaugt, je weniger man sich damit beschäftigt? ;-) Mein Gott, selbst Arduino ist schon EXTREM einfach mit minimaler Einstiegshürde. Wie einfach soll's denn sonst noch werden? Soll man als Bergsteiger erstmal lieber Marathonläufer werden, damit die Berge nicht zu steil sind?
C an sich ist ein Schuss ins Hirn. Wer tut sich solch einen Mist noch an? Es geht doch am Ende um Ergebnisse, welche mit Python oft deutlich schneller und besser erreicht werden als mit dem C -Murks. Hardwareprogrammierung ist eine andere Kategorie, aber Python nur wegen der Einrückung schlecht zu reden finde ich unpassend.
Axel S. schrieb: > Als hardwarenah würde ich das allerdings nicht > bezeichnen. Naja, auch wird auf der Erde sind Alpha Centauri relativ nah, astronomisch gesehen ;-)
> Mein Gott, selbst Arduino ist schon EXTREM einfach mit minimaler > Einstiegshürde. Wie einfach soll's denn sonst noch werden? Das leuchtet mir auch nicht ein. Warum muss etwas unbedingt maximal einfach sein? Es macht dann ja auch keinen Spass mehr wenn etwas zu einfach ist. > Soll man als Bergsteiger erstmal lieber Marathonläufer werden, > damit die Berge nicht zu steil sind? Wir haben aber eher das uebertragene Problem das die Leute eine Seilbahn auf die Spitze wollen um sich dann weiter Bergsteiger zu nennen. Wenn man aber weder seine Muskeln noch sein Gehirn benutzt weil alles so schoen einfach ist dann bildet sich das zurueck. Olaf
Stefan ⛄ F. schrieb: > Odoo (https://www.odoo.com/de_DE) ist komplett in Python programmiert. > Interessant finde ich, dass man damit überhaupt so große Projekte > umsetzen kann. Es läuft aber auch rasch unerträglich lahm, sobald man > eine ernsthafte Menge von Datensätzen angelegt hat. Wir (in der Firma) > haben den Test deswegen abgebrochen und beschlossen, es nicht zu > verkaufen (bzw. dafür zu entwickeln). Entschuldige, aber ich kenne einige odoo-Installationen, und bei allen Fällen mit Performanceproblemen lag das Problem nicht etwa an Python, sondern vielmehr an der ungetunten Datenbank. Die Defaultkonfiguration von PostgreSQL ist sehr konservativ und auf Maschinen mit nur etwa 512 MB Arbeitsspeicher ausgelegt...
Olaf schrieb: >> Mein Gott, selbst Arduino ist schon EXTREM einfach mit minimaler >> Einstiegshürde. Wie einfach soll's denn sonst noch werden? > > Das leuchtet mir auch nicht ein. Warum muss etwas unbedingt maximal > einfach sein? Es macht dann ja auch keinen Spass mehr wenn etwas zu > einfach ist. Manchmal geht es weniger um Spaß, sondern vielmehr um andere Dinge. Einfachheit bedeutet dann weniger Entwicklungskosten und eine kürzere Time-To-Market. > Wenn man aber weder seine Muskeln noch sein Gehirn benutzt weil alles so > schoen einfach ist dann bildet sich das zurueck. Ich nehme an, Du sprichst aus Erfahrung?
Beitrag #6905710 wurde von einem Moderator gelöscht.
Olaf schrieb: >> Mein Gott, selbst Arduino ist schon EXTREM einfach mit minimaler >> Einstiegshürde. Wie einfach soll's denn sonst noch werden? > > Das leuchtet mir auch nicht ein. Warum muss etwas unbedingt maximal > einfach sein? Es macht dann ja auch keinen Spass mehr wenn etwas zu > einfach ist. Dazu ein Zitat von Einstein: "Ich bin sehr dafür, die Dinge zu vereinfachen. Aber nicht einfacher als nötig." (existiert in mehreren Varianten, weil er es auf Englisch gesagt hat) Oder, mit mehr Bezug auf Programmiersprachen: "Einfache Dinge sollten einfach sein. Schwierige Dinge sollten machbar sein." Arduino & Co. kümmern sich aber immer nur um das erste. Vor allem sind sie bereit für mehr Einfachheit bei ersterem Einbußen bei letzerem hinzunehmen. So kann man bei Arduino [1] zwar einfachst einen IO-Pin auf 1 setzen, aber scheitert schon, wenn es zwei gleichzeitig sein sollen. Nun mag Arduino ein schlechtes Beispiel sein, weil es ja eigentlich nur eine Library ist, auf die man genausogut verzichten und es von Hand "richtig" machen kann. Nur stellt sich dann die Frage, wozu man Arduino (bzw. [1]) überhaupt braucht. [1] eigentlich libwiring
Auf die Performance wurde ja schon eingegangen. Eine andere Sache ist die Sprache selbst: Python ist nicht dafür gemacht Speicher direkt anzusprechen, dafür fehlen AFAIK die entsprechenden Sprachkonstrukte. Das Problem daran ist, dass besonders Mikrocontroller darauf ausgerichtet sind, über Speicherzugriffe direkt angesteuert zu werden und auf Registerebene auch entsprechend einfach aufgebaut sind um das zu ermöglichen. MicroPython bietet als Ersatz verschiedene Abstraktionen dafür an, z.B. SPI als Objekt mit write/read-Funktionen (Arduino-ähnlich) oder Inline-Sprachblöcke um C/Assembler-ähnliche Operationen ausführen zu können. Ab einer gewissen Programmkomplexität oder bei strengen Anforderungen an das Timing macht es einfach keinen Sinn mehr MicroPython zu benutzen, denn der Großteil des Programms ist dann eh nicht mehr in idiomatischem Python geschrieben. Die anfängliche Obfuskation der Hardware und des Speichers durch die Abstraktionen macht das Ganze in so einer Situation eher komplexer.
Axel S. schrieb: > Arduino & Co. kümmern sich aber immer nur um das erste. Weil die komplexeren Fälle bereits durch die zugrunde liegende Programmiersprache abgedeckt sind. Arduino wollte eben nicht das ganze Rad neu erfinden, sondern nur eine schicke Radkappe oben drauf setzen. Das haben sie gut gemacht, finde ich. Man darf nur nicht zu hohe Erwartungen in das System setzen. Was Arduino fehlt ist ein anständiger Editor und Fehlermeldungen welche die Zielgruppe verstehen kann. Anstelle der Konsole-Ausgangen des gcc braucht die IDE einen lustig animierten Hund, der die fehlerhafte Stelle ankläfft. Dazu eine farbige Markierung, und eine Sprechblase mit internationalisiertem Text wie "Das hier sieht aus wie der Name einer Variable, aber die gibt es nicht. Prüfe, ob du ihren Namen richtig geschrieben hast". Oder: "Hier hast du wahrscheinlich ein Semikolon vergessen".
Peter schrieb: > Ich freue mich auf eure Antworten! W. Garbage Collection und wegen GIL ist das Timing komplett undeterministisch.
Stefan ⛄ F. schrieb: > Anstelle der Konsole-Ausgangen des gcc > braucht die IDE einen lustig animierten Hund, > der die fehlerhafte Stelle ankläfft. Als Satire nicht schlecht. Aber bitte besser als solche markieren!
> Als Satire nicht schlecht. Aber bitte besser als solche markieren! Warum? Es gab doch schonmal das Konzept mit mehr oder weniger vielen Bomben. https://de.wikipedia.org/wiki/Bombe_(Fehlermeldung) Olaf
Hallo, Axel S. schrieb: > Als Satire nicht schlecht. Aber bitte besser als solche markieren! Wenn tatsächlich in der Zukunft, wie von einigen Politikern gefordert, alle Schüler Programmieren lernen sollen, wird man auf so was wohl nicht mehr verzichten können. Und mal ganz ehrlich, wer hat nicht schon gerätselt was ihm bestimmte Fehlermeldungen sagen wollen. rhf
Stephan >Was hat Python, dass da viele so drauf anspringen? Was bietet Python, >was C/C++ (insb. auf uC!) nicht bietet oder besser kann? >Der Leser ahnt es schon: ich mag Python nicht (auch nicht auf Non-uC). Ich glaube, vor 30 Jahren gab es ein ganz ähnliche Diskussion, nur die Begriffe waren anders. In etwas so: "Was hat C, dass da viele so drauf anspringen? Was bietet C, was Assembler (insb. auf uC!) nicht bietet oder besser kann?" Die Antwort auf die Frage erübrigt sich fast: Assembler ist immer noch schneller als C, wenn man wirklich die Feinheiten des Prozessorinstruktionssatzes nutzen will. Trotzdem programmiert kaum noch einer in Assembler. Die KI-Welt jedenfalls spricht Python. Und das ist die Zukunft.
chris schrieb: > Die KI-Welt jedenfalls spricht Python. Und das ist die Zukunft. **räusper** https://www.rust-lang.org/
:
Bearbeitet durch User
Also ich habe vor einigen Tagen einen RP2040 mit Python programmiert. 500ksps, drei Kanäle Round-Robin, DMA, Oversampling, drei verschiedene Filtermechanismen. Und auf dem zweiten Kern zwei Frequenzsteuerungen in Abhängigkeit der analogen Kanäle. Mit Kurvenanpassungen. Hätte man natürlich auch in C++ programmieren können. Hätte man natürlich auch in C programmieren können. Hätte man natürlich auch in Assembler programmieren können. Da hätte der RP2040 viel mehr idle-time gehabt… … und mindestens ein, möglicherweise mehrere mA gespart.
Hallo, Norbert schrieb: > Hätte man natürlich auch in C++ programmieren können. > Hätte man natürlich auch in C programmieren können. > Hätte man natürlich auch in Assembler programmieren können. Und warum hast du nicht? rhf
Roland F. schrieb: > Hallo, > Norbert schrieb: >> Hätte man natürlich auch in C++ programmieren können. >> Hätte man natürlich auch in C programmieren können. >> Hätte man natürlich auch in Assembler programmieren können. > > Und warum hast du nicht? Vielleicht weil er noch fertig werden wollte, bevor der allfällige Schnitter kommt.
Nachdem sowohl das geliebte XP geschwächelt hat und bei mehreren heftigen Chrashs auch mein VB6 komplett aus der Bahn geworfen hat, habe ich auf Ubuntu umgesattelt und als VB-Ersatz Phyton genommen. Einrücken ist ok!! Und OOP ist gut!! Jede Menge Funktionen. Relativ simple Grafik. Und hardwarenah ist relativ...Progrämmchen mit Soundsystem hat mir das ganze System so grundlegend zerschossen, dass ich echt bis in die niedere Festplattenformatierung runter mußte. War aber sicher auch mir als Anfänger geschuldet :-) C und Konsorten kommen mir nicht auf die Rechner und auf einen Controller schon gar nicht :-) Gruß Rainer
> … und mindestens ein, möglicherweise mehrere mA gespart. Ja richtig. Das koennte dann bedeuten das man einen Controller eine Nummer kleiner nehmen kann, vielleicht reicht auch ploetzlich ein kleinererer Spannungregler, die Platine kann etwas keiner werden. Was auch immer, in Summe ist ein Produkt das effiziente programmiert werden kann billiger. Klar beim basteln zuhause fuer drei LEDs ist das egal, verkauf aber mal 1Million pro Jahr und das sieht auf einmal ganz anders aus. Ich kenne Anwendungen da hat man monatelang entwickelt um noch ein Milliampere einzusparen! Olaf
Angehängte Dateien:
-
RPiZeroWS.jpg
180 KB
kleiner als ein Nano, dafür etwas mehr Power und Speicher, was will man weniger?
Olaf schrieb: >> … und mindestens ein, möglicherweise mehrere mA gespart. > > Ja richtig. Das koennte dann bedeuten das man einen Controller eine > Nummer kleiner nehmen kann, vielleicht reicht auch ploetzlich ein > kleinererer Spannungregler, die Platine kann etwas keiner werden. Was > auch immer, in Summe ist ein Produkt das effiziente programmiert werden > kann billiger. Klar beim basteln zuhause fuer drei LEDs ist das egal, > verkauf aber mal 1Million pro Jahr und das sieht auf einmal ganz anders > aus. Ich kenne Anwendungen da hat man monatelang entwickelt um noch ein > Milliampere einzusparen! > > Olaf Nun, zwischen Zuhause LED-Blinker basteln und eine Million Platinen gibt es noch feine Abstufungen. ;-) Z.B. fünfzig, von denen - sagen wir mal - zehn im Testbetrieb laufen.
Falk B. schrieb: > Peter schrieb: >> Ist der Code mit Python auch so effizient und schnell wie mit den >> C's? > > Da Python meistens (immer?) auf einem Interpreter läuft, ist es um > Größenordnungen langsamer und braucht deutlich mehr Speicher und > CPU-Leistung. Es ist eine Scriptsprache die sicher ihre Berechtigung und > Anwendung hat, aber sicher nicht für hardwarenahe Programmierung von > kleinen bis mittleren Mikrocontrollern. Wie wir vor kurzem hier gesehen haben: Beitrag "Re: c++ Code langsam" ist Python nicht immer langsamer als C oder C++. Und das waren reine Skripte, keine compilierten Sachen. Kein Wunder, Python baut ja auf optimierte C Bibliotheken auf. Ein Neuling, der wenig Ahnung von Low-Level und Asm Programmierung hat, macht mit Python und auf den uC optimierten Bibliotheken bessere Programme als mit C++. Zumindest wenn das Programm in den Speicher passt. Und wenn dann das Testen einfach auf dem PC in einer simulierten Umgebung geht, dann steigen auch die Profis um. Die Zukunft gehört den Mikrocontrollern, die 1. lieferbar sind, und 2. ordentliche High-Level Bibliotheken haben. Zumindest in Europa, wo nur noch hochpreisiges gemacht werden wird.
Genau dafür liebe ich dieses Forum! Das ist eine der besten Fachdiskussionen die ich hier verfolgt habe! Mein Fazit : Für µC bzw hardwarenahe Programmierung sind C/C++ weiterhin unschlagbar, jedoch auch nur wenn man diese Sprachen gut beherrscht und weis was man macht. Python bzw Circuit Python können auch auf bestimmte µC laufen, jedoch ist das eher was für fachfremde Anwender oder wenn man sich den Einstieg sehr sanft machen möchte. Ansonsten bietet Python sehr viele Bibliotheken und Möglichkeiten, dinge einfach umzusetzen. Vielen Dank an alle die sich beteiligt haben!
Peter schrieb: > jedoch auch nur wenn man diese Sprachen gut beherrscht und weis was man > macht. Das gilt für jede Programmiersprache. Ich kenne genug Sprachen, die endlich Deppensicher sein wollten, und es doch nicht sind.
Auch ich zähle zu der Fraktion, die C oder C++ für die Programmierung von Mikrocontrollern bevorzugt. Allerdings verdamme ich Python auf µC deswegen nicht, sondern verfolge lieber etwas dessen Entwicklung. Zwar ist Python i.Allg. sehr viel langsamer als C, ich gehe aber davon aus, dass in 90% der Mikrocontrolleranwendungen nur ein kleiner Bruchteil der zur Verfügung stehenden Rechenleistung genutzt wird. Da die Mikrocontroller immer schneller werden, wird dieser Bruchteil sogar tendenziell immer kleiner. Für ungenutzte Taktzyklen bekommt man auch keinGeld zurück. Was also tun? Auch bei Neuentwicklungen bewusst auf Klassiker wie den 8051 setzen, nur um dessen Kapazitäten auch voll auszuschöpfen zu können? Auch dann, wenn ein aktueller ARM nicht teurer oder sogar billiger ist? Das würde ich nicht tun. Eine IMHO sinnvolle Nutzung der freien Kapazitäten ist die Verarbeitung von Messgrößen u.ä. (bspw in Regelalgorithmen) in FP. Damit entfällt das bei Integerberechnungen oft erforderliche, aber fehlerträchtige Hin- und Herskalieren zwischen den einzelnen Rechenschritten, und man kann in realen physikalischen Einheiten rechnen, was viel übersichtlicher ist. Wenn dann immer noch Rechenkapazität übrig bleibt, kann man sich weitere Möglichkeiten überlegen, mit denen man auf Kosten von Taktzyklen die Softwareentwicklung vereinfachen und den Code zuverlässiger machen kann. Ob Python so eine Möglichkeit darstellt, sei mal dahingestellt, aber kategorisch ausschließen würde ich es nicht. Ressourcenverbrauch Die Entwicklung von Python reicht in die Zeit zurück, als 286er- und 386er-PCs mit 1 MiB RAM Standard und die 486er gerade so im Kommen waren. Heute hat selbst ein billiger Cortex-M0 deutlich mehr Rechenleistung als die damaligen High-End-PCs (mit 486er), und auch die RAM-Kapazität der Mikrocontroller geht teilweise schon in die MiB. Python wurde so konzipiert, dass es auf diesen Rechnern problemlos lauffähig war. Angesichts der Tatsache, dass - der µC normalerweise kein Betriebssystem hat, - typischerweise nur eine einzige Anwendung läuft und - mittlerweile relativ schlanke Python-Implementationen verfügbar sind, kann davon ausgegangen werden, dass auf einem aktuellen, mittelgroßern µC Python mindestens so gut läuft wie auf den PCs von damals. Natürlich müssen für den konkreten Anwendungsfall immer die Vor- und Nachteile abgewogen werden, deswegen würde ich Python weder generell empfehlen noch generell davon abraten. Speziell auf batteriebetriebenen Geräten würde ich kein Python einsetzen, bei einer Waschmaschinensteuerung fallen mir spontan aber kaum Gegenargumente ein. Was den Einsatz in kommerziellen Produkten betrifft: Der Endbenutzer freut sich, wenn das Produkt funktioniert und wird kaum feststellen können, ob die Firmware mit C, Arduino, Basic oder Python entwickelt worden ist. Noch etwas zum Thema Interpreter: Es hat sich in den letzten 10 bis 15 Jahren einiges bei der Generierung von Native-Code getan (s. bspw. Cython und PyPy). Nicht alle Diskussionsteilnehmer hier scheinen diesbezüglich auf dem aktuellen Stand zu sein ;-) Auch MicroPython und dessen Fork CircuitPython bieten dafür Unterstützung, sogar auf mehreren Ebenen: - Default: klassisches Python mit Bytecode-Generierung - Native: klassisches Python mit Native-Codegenerierung - Viper: Python mit Type-Hints und Native-Codegenerierung - Inline-Assembler: "Codegenerierung" durch den Programmierer - Inline-PIO-Assembler: für die Programmable IOs des RP2040 Für jede Python-Funktion kann die jeweils am besten geeignete der genannten 5 Codegenerierungsoptionen ausgewählt werden. Ich habe mal ein wenig mit MicroPython und der Thonny-IDE auf einem RPi Pico herumgespielt. Das Interessante dabei ist, dass man fast keinen Unterschied spürt, ob die Programme auf dem PC oder auf dem µC laufen. Man klickt auf den Run-Button in der IDE, und das Programm wird praktisch sofort gestartet, ohne dass es vorher kompiliert oder geflasht werden muss. Man kann auf dem µC genauso wie auf dem PC in einer interaktiven Shell Python-Anweisungen ausführen lassen. Das ist für den Einstieg in einen neuen µC-Typ ganz praktisch, weil man damit erst einmal aller Features einzeln und interaktiv ausprobieren kann, bevor man beginnt, daraus ein ganzes Programm zu erstellen. Auch zum Debuggen ist das ganz praktisch, weil man damit einzelne Funktionen isoliert testen kann, ohne dass man dafür hundert kleine Testprogramme schreiben, kompilieren und flashen muss. Darin unterscheidet sich MicroPython auch klar von Arduino und den einschlägigen BASICs, die diesen interaktiven Modus nicht haben. Allerdings hat MicroPython auch (noch) einige Schwächen. Bspw. ist der native-generierte Code für Funktionsaufrufe sehr langsam, und der Inline-Assembler scheint bestimmte Kombinationen aus Registern und Adressierungsarten nicht anzunehmen. Ich gehe aber davon aus, dass diese Dinge irgendwann behoben werden. Bis dahin bleibe ich dann einfach bei Arduino ;-)
Yalu X. schrieb: > Allerdings hat MicroPython auch (noch) einige Schwächen. Bspw. ist der > native-generierte Code für Funktionsaufrufe sehr langsam, und der > Inline-Assembler scheint bestimmte Kombinationen aus Registern und > Adressierungsarten nicht anzunehmen. Alles was er nicht kann, kann man sich mit dem data statement bauen:
1 | data(2,0b_1011_1010_00_010_000) # REV |
2 | data(2,0b_1011_1010_01_010_000) # REV16 |
3 | data(2,0b_1011_1010_11_010_000) # REVSH |
ARM v6-M Architecture Reference Manual hilft dabei. Wollt's nur erwähnen… ;-) Bzgl. call-Geschwindigkeit, interessant, da muss ich mal reinschauen.
Angehängte Dateien:
-
pyCharm_mit_MicroPython.jpg
120 KB
Eine kostenlose gescheite Entwicklungsumgebung (Comunnity Edition) für MicroPython ist z.B. pyCharm. Benutze ich für den ESP8266. https://www.jetbrains.com/de-de/pycharm/
Beitrag #6907065 wurde von einem Moderator gelöscht.
> dass in 90% der Mikrocontrolleranwendungen nur ein kleiner Bruchteil der > zur Verfügung stehenden Rechenleistung genutzt wird. Da die > Mikrocontroller immer schneller werden, wird dieser Bruchteil sogar > tendenziell immer kleiner. Für ungenutzte Taktzyklen bekommt man auch > keinGeld zurück. Das ist leider komplett falsch. Wenn mein Microcontroller 90% der Zeit nichts zutun hat dann ist er 90% der Zeit im Sleepmode. Dann reicht ploetzlich eine kleinere Batterie oder der Kunde bekommt eine 10x solange Laufzeit. Oder ich kann als Spannungregler einen LP2985 anstatt eines Schaltregler verwenden. Also viele kleine Dinge die entweder den Wert fuer den Kunden erhoehen oder die Entwicklung preiswerter machen. Klar es gibt sicher Ausnahmen wo es eher egal ist, aber das sind dann auch Ausnahmen. Im Mittel wird man Wert auf Effizienz legen oder immer zweiter am Markt sein. Olaf
Beitrag #6907256 wurde von einem Moderator gelöscht.
> Aber nur im Batteriebetrieb. Wenn nur Netzbetrieb vorgesehen ist, ergibt > ein Sleepmode meiner Meinung nach bei den winzigen Leistungen absolut > keinen Sinn. Keineswegs. Denke z.B mal an 4-20mA Geraete. Oder an Sensoren die potentialfrei sind wo man jede Energie erstmal ueber eine Barriere schaffen muss. Oder an ATEX Geraete wo deine Energie begrenzt ist. Oder selbst sowas banales wie einen Fahrkartenautomat oder etwas aehnliches das mit einer Solarzelle funktionieren muss. Olaf
Beitrag #6907287 wurde von einem Moderator gelöscht.
> Solarzelle? Ich sprach von Netzbetrieb.
Und? Auch da kann es billiger sein wenn deine Schaltung mit 1mA laeuft
und du ein Kondensatornetzeil hast, oder einen Trafo verwenden musst
weil die Schaltung 10mA braucht.
Klar, es gibt Anwendungen wo das alles geht und der Stromverbrauch des
Controllers banane ist. Aber es gibt auch viele wo das nicht so ist
und fuer die musst du eine richtige Sprache koennen. Wenn du das aber
kannst, wieso sich dann noch mit sowas exotischen wie einer
Interpretersprache abgeben?
Olaf
Olaf schrieb: > wieso sich dann noch mit sowas exotischen wie einer > Interpretersprache abgeben? Was bitteschön ist an einem Interpreter "exotisch" ?
Beitrag #6907485 wurde von einem Moderator gelöscht.
Olaf schrieb: >> dass in 90% der Mikrocontrolleranwendungen nur ein kleiner Bruchteil der >> zur Verfügung stehenden Rechenleistung genutzt wird. Da die >> Mikrocontroller immer schneller werden, wird dieser Bruchteil sogar >> tendenziell immer kleiner. Für ungenutzte Taktzyklen bekommt man auch >> keinGeld zurück. > > Das ist leider komplett falsch. Wenn mein Microcontroller 90% der Zeit > nichts zutun hat dann ist er 90% der Zeit im Sleepmode. Auch im Sleepmode verpufft die prinzipiell zur Verfügung stehende Rechenleistung ungenutzt. > Dann reicht ploetzlich eine kleinere Batterie oder der Kunde bekommt > eine 10x solange Laufzeit. Ja, deswegen habe ich ja oben geschrieben: Yalu X. schrieb: > Speziell auf batteriebetriebenen Geräten würde ich kein Python > einsetzen, bei einer Waschmaschinensteuerung fallen mir spontan aber > kaum Gegenargumente ein. Olaf schrieb: > Klar es gibt sicher Ausnahmen wo es eher egal ist, aber das sind dann > auch Ausnahmen. Im Mittel wird man Wert auf Effizienz legen oder immer > zweiter am Markt sein. Man könnte jetzt darüber diskutieren, welche Gerätekategorie die Ausnahme darstellt, die batteriebetriebenen: - Wetterstationen - elektronische Küchen- und Personenwaagen - Fahrradtachos - elektronische Fieberthermometer, Blutdruckmessgeräte u.ä. - ... oder die netzbetriebenen: - Waschmaschinen - Spülmaschinen - Mikrowellenherde - Fernseher und andere Unterhaltungselektronik ... Also bei mir im Haushalt überwiegen die netzbetriebenen Geräte ganz klar, im industriellen Umfeld ist deren Anteil sogar noch deutlich größer. Ein Großteil der Softwarekomponenten auf diesen Geräten ist nicht sehr zeitkritisch. Wären sie in Python programmiert, würde deswegen kein Mensch etwas davon merken. > Im Mittel wird man Wert auf Effizienz legen oder immer zweiter am > Markt sein. Eine Waschmaschine wird wegen der von Python verursachten paar Milliwatt Mehrverbrauch nicht in eine schlechtere Energieeffizienzklasse abrutschen. Auch bei batteriebetriebenen Geräten lohnt sich die verbrauchsoptimierte Programmierung nur dann, wenn der Mikrocontroller einen wesentlichen Anteil am Gesamtverbrauch hat. Olaf schrieb: > Wenn du das aber kannst, wieso sich dann noch mit sowas exotischen wie > einer Interpretersprache abgeben? Wie ich oben schon geschrieben habe, ist Python vorliegenden Kontext i.Allg. keine Interpretersprache. Aber wie ich oben schon geschrieben habe, programmiere ich selber meine Mikrocontroller vorwiegend in C und nicht in Python. Ich wollte nur aufzeigen, dass Python auf Mikrocontrollern dennoch nicht völlig unsinnig ist, wie es hier von einigen dargestellt wird.
Klingt interessant. Sollte ich bald mal ausprobieren. Ich steh auch noch bei 8051 und PSoC5-LP. Es ist eben alles eine Frage der Stückzahlen und der Arbeitsstunden, die man aufwenden muß, um eine gewünschte Funktionalität zu erreichen. Die Stunden sind bei Hobbyprojekten besonders teuer, denn sehr begrenzt verfügbar. Ich hätte sogar eine konkrete Anwendung: Abfrage eines Netzbetreiberzählers und über einen Algorithmus einen bidirektionalen Boost/Buck-Konverter einen Akku betreiben, der an PV und Wechselrichter hängt.
Mich hat mal interessiert, wie schnell man in MicroPython auf einem RP2040 I/O machen kann. Dazu habe ich ein Programm geschrieben, das auf verschiedene Weise 1.000.000-mal ein GPIO-Pin toggelt: 1. klassischer Python-Stil ohne Native-Kompilierung 2. wie (1), aber mit Native-Codegenerierung 3. wie (2), aber mit Type-Hint (Viper-Modus) 4. handoptimiert: direkter Registerzugriff über Pointer, keine Funktionsaufrufe, while- statt for-Schleife 5. mit Inline-Assembler Ausgabe:
1 | CPU-Frequenz: 133.00 MHz |
2 | |
3 | Zeit für 1000000 Schleifendurchläufe: |
4 | |
5 | Python 11106.14 ms |
6 | Native 6646.69 ms |
7 | Viper 5075.24 ms |
8 | Handoptimiert 67.71 ms |
9 | Assembler 30.16 ms |
Wegen der 1E6 Schleifendurchläufe entsprechen die genannten Zahlenwerte der Ausführungszeit von 1 Schleifendurchlauf in Nanosekunden gemessen. Der handoptimierte Code ist natürlich nicht mehr sehr pythonic, aber in diesem Stil wird man nur extrem zeitkritische Codeabschnitte schreiben.
:
Bearbeitet durch Moderator
4 ist dann in C, oder wie ist der Unterschied zwischen 4 und 5 zu erklären?
Yalu X. schrieb: > Der handoptimierte Code ist natürlich nicht mehr sehr pythonic, aber in > diesem Stil wird man nur extrem zeitkritische Codeabschnitte schreiben. Da siehst du mal, wie stark der Einfluss von Algorithmen ist. Oft macht das mehr aus, als die Programmiersprache.
Die Kurve der Python Euphorie wird den gleichen Verlauf nehmen, wie die seinerzeit von PERL. Wer unsauberes Programmieren lernen will, beginnt mit Perl oder Python
:
Bearbeitet durch User
otte schrieb: > Olaf schrieb: >> wieso sich dann noch mit sowas exotischen wie einer >> Interpretersprache abgeben? > > Was bitteschön ist an einem Interpreter "exotisch" ? Ich denke, das ist speziell auf µCs bezogen. Dort sind Interpretersprachen schon eher die Exoten.
> Aber wie ich oben schon geschrieben habe, programmiere ich selber > meine Mikrocontroller vorwiegend in C und nicht in Python. Ich wollte > nur aufzeigen, dass Python auf Mikrocontrollern dennoch nicht völlig > unsinnig ist, wie es hier von einigen dargestellt wird. Ich bin da durchaus bei dir das es Anwendungen gibt wo man eine langsame Sprache wie Python sinnvoll einsetzen kann. Was ich aber, hoffentlich gelungen, darstellen kann das es eine Menge Anwendungen gibt wo das nicht der Fall ist. Fuer diese Anwendung ist es zwingend notwendig das du im Embedded Bereich C programmieren kannst. Wenn du das aber sowieso kannst, warum sich dann noch mit einer zweiten Sprache und ihren Problemen belasten? > Also bei mir im Haushalt überwiegen die netzbetriebenen Geräte ganz > klar, im industriellen Umfeld ist deren Anteil sogar noch deutlich > größer. Gerade im Industriebereich entspricht das nicht meiner Erfahrung. Da versucht man wo immer es geht mit 2-Leiter Geraeten auszukommen weil der Installationsaufwand fuer eine extra Versorgung meist teurer ist als das Geraet selber. > man aufwenden muß, um eine gewünschte Funktionalität zu erreichen. Die > Stunden sind bei Hobbyprojekten besonders teuer, denn sehr begrenzt > verfügbar. Bei Hobbyprojekten sind Stunden eigentlich negativ teuer weil du da ja aus Spass bastelst und du dankbar fuer jeder weitere Stunde bist. :-D > Mich hat mal interessiert, wie schnell man in MicroPython auf einem > RP2040 I/O machen kann. Dazu habe ich ein Programm geschrieben, das auf > verschiedene Weise 1.000.000-mal ein GPIO-Pin toggelt: Das halte ich fuer einen besonders schlechten Test. Bei allen Controllern mit mehr wie 20Mhz Taktfrequenz die ich kenne laeuft die IO in einer eigenen schnarchlahmen Taktdomain. Da kannst du den Pin auch mit zwei Assemblercommandos toggeln und es ist lahm im Vergleich zur Ausfuehrungszeit einer Funktion. Daher hat das keine besondere Aussage. Wenn ich hier laester dann beziehe ich das erstmal darauf: .-) https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/ Olaf
Yalu X. schrieb: > CPU-Frequenz: 133.00 MHz Standard nach boot ist auf 125MHz gesetzt. Übertakten - mehrere Stunden - auf deutlich über 270MHz kein Problem bei mehreren Exemplaren. Mit PIO-Assembler kann man dann einen Port Pin mit 135MHz togglen. Innerhalb der Spezifikation immerhin noch mit 66½ MHz. Sieht auf meinem uralten 50MHz Analog Oszilloskop ›interessant‹ aus.
Norbert schrieb: > Standard nach boot ist auf 125MHz gesetzt. Ich habe die 133 MHz deswegen genommen, weil das laut Datenblatt die Standardtaktfrequenz des RP2040 ist. Auch in den Specs des Pico sind die 133 Mhz angegeben. Für den Vergleich der verschiedenen Toggle-Methoden spielt die Taktfrequenz ohnehin keine Rolle. > Übertakten - mehrere Stunden - auf deutlich über 270MHz kein Problem bei > mehreren Exemplaren. Meiner ist bei 285 MHz ausgestiegen :) Bei 280 Mhz läuft er noch gut und wird auch nur schwach lauwarm. > Mit PIO-Assembler kann man dann einen Port Pin mit 135MHz togglen. Mit einem Timer geht das wahrscheinlich ebenso, wobei die PIOs natürlich merh Möglichkeiten bieten. Diese Frequenz erreicht man – zumindest als kurzzeitigen Burst – auch in Python bei direktem Registerzugriff, indem man mehrere Registerzugriffe ohne Schleife direkt hintereinander schreibt. Aber die PIOs sind eine schon feine Sache. Schnelles Bit-Gewackel würde ich, wenn immer möglich, dorthin auslagern. Da das Füttern der PIOs mit Daten auch per DMA erfolgen kann, hat die CPU fast nichts mehr zu tun und damit alle Zeit der Welt, langsame Python-Programme auszuführen ;-) Und auch die PIO-Programmierung wird ja von MicroPython dank des PIO-Inline-Assembler gut unterstützt.
> Aber die PIOs sind eine schon feine Sache. Schnelles Bit-Gewackel würde > ich, wenn immer möglich, dorthin auslagern. Da das Füttern der PIOs mit Das kommt zwar vom Thema ab, aber da wuerde ich auch zustimmen. Sowas kenne ich noch von vor 20Jahren von der TPU im 68332. Ich hab mich immer gewundert das sich das nicht mehr verbreitet hat. Vielleicht mussten auch erst Patente von Motorola ablaufen? :) Olaf
Wurde die TPU jemals wirklich intensiv genutzt, oder war das eher nur so ein nutzloses Gimmick eines verirrten Chipentwicklers? Ich erinnere mich an das Motorola MicroTack Aufklapphandy. Aufgeschraubt und was fand ich drin: ein 68332 und ein DSP. Hatte sogar 2 RAM-Chips, damit sie 16bit schaufeln konnte. Stromverbrauch war astronomisch.
Abdul K. schrieb: > Wie steigt man jetzt als DAU in den RP2040 mit Python am besten ein? Wer das nicht von alleine herausfindet, der wir auch an allen folgenden Schritten scheitern.
Stefan ⛄ F. schrieb: > Wer das nicht von alleine herausfindet, der wir auch an allen folgenden > Schritten scheitern. Ganz schön frech! Nur, weil Du kein Buch geschrieben hast, auf das Du fleißig verlinken kannst, finde ich die Frage durchaus berechtigt, um nicht sinnlose Installationen wieder zu löschen.
So seh ich das auch.
:
Bearbeitet durch User
Klick doch einfach mal auf RP2040 oder gebe das bei Google ein. Nein das ist zu trivial, tue es nicht.
Stefan ⛄ F. schrieb: > Wer das nicht von alleine herausfindet, der wir auch an allen folgenden > Schritten scheitern. Ich bin auch der Ansicht, dass das Herausfinden die wichtige Sache ist! War mal ein großer Fan von "an der Uni lernst du wie man lernt", aber das scheint schon lange nicht mehr so zu sein... Gruß Rainer
Olaf schrieb: > Das halte ich fuer einen besonders schlechten Test. Bei allen > Controllern mit mehr wie 20Mhz Taktfrequenz die ich kenne laeuft die IO > in einer eigenen schnarchlahmen Taktdomain. In einer eigenen Taktdomain ist üblich, ja. Aber "schnarchlangsam"? Das dann doch eher nicht. Was du wohl meinst, sind die hochzüchteten Rechenknechte in PCs oder Smartphones. Ja, im Vergleich zu deren Takt ist das IO-Gefummel natürlich schnarchlangsam. Aber es sind halt nun gerade keine typischen µC-Anwendungen, bei denen man solche Geschosse benutzt...
Yalu X. schrieb: > Ausgabe: > > CPU-Frequenz: 133.00 MHz > Zeit für 1000000 Schleifendurchläufe: > Python 11106.14 ms > Native 6646.69 ms > Viper 5075.24 ms > Handoptimiert 67.71 ms > Assembler 30.16 ms Das ist ja mal klasse...danke für den Test. Zum Thema Ressourcen...schaue man einfach mal auf den Unterschied zwischen HAL und LLL. Selbst wenn man in C bleibt, liegen da Welten dazwischen. Ich persönlich mag C nicht sonderlich. Die Sprache hat uns zwar weit gebracht, aber sie ist halt mittlerweile auch sehr veraltet. Heute ist man um viele Erfahrungen klüger, die man einfach noch nicht hatte als C entwickelt wurde, und ein adäquater Ersatz wäre wirklich angebracht. Ich denke aber nicht daß Python dieser Ersatz werden wird, so eine Sprache müßte schon eigens für hardwarenahe Zwecke entwickelt werden, und das ist Python einfach nicht.
Ich skripte unter Linux schon länger mit Python herum. Es ist aus jeden Fall schneller weggetippt als ein Programm in C geschrieben und übersetzt. Ich bin kein professioneller Programmierer, sondern Systemadministrator. Da muss es oft schnell gehen, wofür eine Skriptsprache enorme Vorteile hat. Unter Windows verwende ich hauptsächlich Powershell. Bevor ich da einen Compiler ausgepackt habe, ist das Projekt in PS bereits fertig. Auch wenn Python anders als C, PHP oder Python ist, ist es nicht schlecht. Nur weil etwas anders ist, als das was man bisher kennt, muss man es nicht verteufeln. Es fördert die Kreativität und fordert den Denkapparat. Und Programmierung durch Einrückung gab es schon bei Fortran, ist also nichts neues (für mich jedenfalls - ja, ich hatte noch mit Fortran programmiert). Ich schmeiße jedenfalls lieber schnell den Editor an schreibe ein Programm als Skript, als den C-Compiler zu bemühen. Vor allem auch, da dieser nicht zu meinem üblichen Werkzeugkaste gehört. Warum das nicht auch auf einem µC nutzen, wenn nichts anderes (Geschwindigkeit, Stromverbrauch, Speicherplatz) dagegen spricht. Da die Kosten bei Einzelstücken oder auch im Privatumfeld nebensächlich sind, kann man auch mal einen größeren Prozessor für einige Euro nutzen und diesen in Python programmieren. Einen großen Vorteil gibt es noch bei Python (oder anderen Interpretersprachen). Um das Programm mal schnell zu ändern, braucht man keine Toolchain auf dem Rechner.
Walter K. schrieb: > Die Kurve der Python Euphorie wird den gleichen Verlauf nehmen, wie die > seinerzeit von PERL. Das ist naiver Unfug. Perl ist immer noch eine weit verbreitete Skriptsprache, in der Unmengen an produktivem Code implementiert ist, und für Python gilt dasselbe. Diese beiden Sprachen werden so bald ganz sicher nicht untergehen -- schon gar nicht, als bislang noch nichts Besseres in Sicht ist. Und selbst dann werden sie ebensowenig verschwinden wie Fortran, Cobol und Smalltalk -- Sprachen, in denen die Erfahrenen heute exorbitante Gehälter erzielen, weil das für die Unternehmen immer noch weniger kostet als Neuimplementierungen. Du mußt Python, Perl, Ruby und Co. nicht mögen, aber Du wirst Dich damit abfinden müssen, daß sie existieren, sonst ist das schlecht für Deinen Blutdruck -- und auf den sollten alte Männer wie wir bekanntlich achtgeben. > Wer unsauberes Programmieren lernen will, beginnt mit Perl oder Python Auch das ist naiver Unfug. Man kann in jeder Sprache unsauber Programmieren lernen und unsauber Programmieren, wie dieses Forum jeden Tag unter Beweis stellt. ;-)
@ Yalu Danke für Deine Beispiele
1 | # MicroPython, ESP8266 @ 80 MHz |
2 | # 1000 x einen Wert (1 - 1000) quadrieren |
3 | |
4 | 19243 µs # Classic |
5 | 7296 µs # Native |
6 | 333 µs # Viper |
7 | 270 µs # Viper gedengelt |
Nur_ein_Typ schrieb: > Walter K. schrieb: >> Die Kurve der Python Euphorie wird den gleichen Verlauf nehmen, wie die >> seinerzeit von PERL. > > Das ist naiver Unfug. Perl ist immer noch eine weit verbreitete > Skriptsprache, in der Unmengen an produktivem Code implementiert ist, > und für Python gilt dasselbe. Also, dann stimmt die Aussage oben ja :) >> Wer unsauberes Programmieren lernen will, beginnt mit Perl oder Python > > Auch das ist naiver Unfug. Man kann in jeder Sprache unsauber > Programmieren lernen und unsauber Programmieren, wie dieses Forum jeden > Tag unter Beweis stellt. ;-) Wobei man sagen muss, dass Perl und Python viele Schweinereien zulassen, so dass mehr Disziplin erforderlich ist, um darin sauber zu programmieren.
Christian H. schrieb: > Ich skripte unter Linux schon länger mit Python herum. Es ist aus jeden > Fall schneller weggetippt als ein Programm in C geschrieben und > übersetzt. Ich bin kein professioneller Programmierer, sondern > Systemadministrator. Nur ist das halt das exakte Gegenteil von "hardwarenah Programmieren". BTW, als ich als Sysadmin gearbeitet habe, habe ich es genauso gemacht. OK es war war Perl statt Python. Es war zwar tatsächlich mal so gedacht, aber in der Praxis verwendet niemand(?) C für Einmal- oder Wegwerf-Programme. > Auch wenn Python anders als C, PHP oder Python ist, ist es nicht > schlecht. Das hat ja auch keiner behauptet. Aber jeder hat nun mal seine Vorlieben. Und warum auch nicht. Perl, Python, Ruby, ... sind in der Praxis gleichwertig. Da muß der Grund, warum man eins dem anderen vorzieht, ein anderer sein. Ich kann Perl schon, während ich Python erst lernen [1] müßte. Schon ist die Entscheidung gefallen. [1] nicht wirklich lernen. Ich müßte mich umgewöhnen. > Einen großen Vorteil gibt es noch bei Python (oder anderen > Interpretersprachen). Um das Programm mal schnell zu ändern, braucht > man keine Toolchain auf dem Rechner. Was immer du damit sagen willst. Den Interpreter und die (bei Python nicht gerade kleine) Library brauchst du trotzdem.
Programmiersprachen sind wie Schraubendreher mit unterschiedlichen Köpfen. Am Ende geht es darum die Schraube zu drehen und sie muss halten. Wenn das Bauwerk nicht hält wird niemand sagen, dass der Schraubendreher Schuld war.
Wer Python und Perl in einen Topf wirft... es gibt wenige Sprachen die so sauber definiert sind wie Python. Auch C hat keine so klare Definition. (Zur Erinnerung: Python startete als Lernsprache, die Python-Philosophie sagt es soll genau einen Weg geben die Dinge zu tun und er soll offensichtlich sein.) Dynamische Typisierung kann man mögen oder nicht, hat Vor- und Nachteile. Aber diese Eigenschaft sagt nichts über die Sauberkeit einer Sprache aus. Perl dagegen ist ein buntes Sammelsurium von: "Ich konnte mir mit diesem neuen Konstrukt an der Stelle noch 2 Zeilen Code einsparen!!einself", es ist das pure Chaos. Was man bei der statischen Typisierung aber im Hinterkopf behalten sollte: Sie verhindert zwar einige Fehler, bringt aber ihrerseits Komplexität mit sich und sie verhindert auch nicht alle Fehler. (Vor allem das C Typsystem "kann so wenig", dass es auch wenig hilft, z.B. im Vergleich zu C++.) Daher setzt man in größeren Projekten auch Hilfsmittel zur statischen Codeanalyse ein und arbeitet mit Erweiterungen der Typsysteme. (Z.B. über Annotations - gibt's btw. auch für Python, z.B. als mypy) Python wird heutzutage an ganz vielen Stellen eingesetzt und ist eine der beliebtesten Programmiersprachen überhaupt, teilweise sogar noch vor C. (https://www.tiobe.com/tiobe-index/) Keine normale Linux-Distribution würde heute noch ohne Python funktionieren, es gibt komplette Webframeworks (z.B. Django), ORMs, Paketmanager, Backupsysteme etc. pp. Die Geschwindigkeit ist halt ein Preis den man leider zahlen muss - und manchmal ist der Preis auch zu hoch.
Johannes schrieb: > es gibt wenige Sprachen die so sauber definiert sind wie Python ... > Perl dagegen ist ein buntes Sammelsurium Das ist genau das, was ich mit persönliche Vorlieben meinte. Das Python so verdammt sauber definiert ist, macht dein Programm weder einfacher zu schreiben, noch schneller als ein vergleichbares Perl Programm. Für harwarenahes Programmieren (darum ging es mal in diesem Thread) taugen beide Sprachen nicht. Und der Tiobe Index ... wenn morgen - sagen wir mal - Go als neue fancy Lernsprache tituliert wird und Millionen Newbies bei Stackoverflow aufschlagen und ihre Frage zu Go stellen, dann wird Tiobe erstaunt feststellen, daß Go auf einmal sehr populär geworden ist.
Halten wir also fest, Mikrocontroller werden weder in Python, C++, C oder Assembler programmiert. Assembler, pahhh, nur für Verweichlichte. Die Puristen - und nur um die geht es hier schließlich - nehmen ihre Dokumentation auf Papyrus und kodieren die Mnemonics händisch in Sedezimal. Die Abgehobenen unter den Puristen benutzen - so sagt man - sogar nur Bitfolgen. So geht das! ;-)
So ist es! Programme müssen prinzipiell auch händisch per Taster in den µC übertragen werden, diese ganzen modernen Hilfen sind die reinste Verweichlichung. Währenddessen läuft der µPython Code, der die Wlan Config Page umsetzt, auf 5 verschiedenen Chips fehlerfrei. Die Geschwindigkeit stört niemanden, die Umsetzung ist so einfach das es kaum Fehler gibt und portabel ist es auch noch. Zudem kann man den Code 1:1 auf einem Desktop System entwickeln und testen.
Axel S. schrieb: > Christian H. schrieb: >> Auch wenn Python anders als C, PHP oder Python ist, ist es nicht >> schlecht. > > Das hat ja auch keiner behauptet. Najaaa... > Aber jeder hat nun mal seine > Vorlieben. Und warum auch nicht. Perl, Python, Ruby, ... sind in der > Praxis gleichwertig. Da muß der Grund, warum man eins dem anderen > vorzieht, ein anderer sein. Ich kann Perl schon, während ich Python erst > lernen [1] müßte. Schon ist die Entscheidung gefallen. > > [1] nicht wirklich lernen. Ich müßte mich umgewöhnen. Als jemand, der genau diesen Schritt gegangen und nach 14 Jahren mit Perl vor guten zehn Jahren zu Python gewechselt ist (und das niemals bereut hat), kann ich Dir aus meiner eigenen Erfahrung sagen: ja, das stimmt, Du müßtest Dich umgewöhnen, aber es würde sich möglicherweise trotzdem lohnen. Denn auch wenn Perls Infrastruktur an Tools und Bibliotheken dank des CPAN schon sehr, sehr gut ist, übertrifft die von Python jene von Perl noch einmal um Längen und ist in vielen Bereichen auch deutlich besser auf einander abgestimmt, da beißt die Maus keinen Faden ab. Und je nachdem, welche konkreten Anwendungsfälle Du lösen willst oder mußt, kann das schon einen erheblichen Unterschied ausmachen. Zudem gibt es eine Eigenschaft an Perl, die für viele Aufgaben, vor allem für jene, für die Larry Wall die Sprache ursprünglich entwickelt hat, eine prima Idee ist, aber bei längeren Programme häufig dazu führt, daß diese schlechter les- und damit auch schlechter wartbar werden: die eingebauten Regular Expressions. Andererseits ist es genau diese Eigenschaft, die mich auch heute noch immer mal wieder zu Perl greifen läßt, allerdings nur als UNIX-Filter auf der Kommandozeile mit "perl -pe". Obendrein ist Python meistens deutlich schneller, und der Code ist meistens sogar noch kompakter als der von Perl. Klar, das spielt häufig nur eine untergeordnete Rolle, aber auch das verringert unterm Strich und insgesamt die Entwicklungszeit.
Johannes schrieb: > Wer Python und Perl in einen Topf wirft... es gibt wenige Sprachen die > so sauber definiert sind wie Python. Auch C hat keine so klare > Definition. (Zur Erinnerung: Python startete als Lernsprache, die > Python-Philosophie sagt es soll genau einen Weg geben die Dinge zu tun > und er soll offensichtlich sein.) Ich wüßte jetzt nicht, daß Python als "Lernsprache" gestartet sei... hast Du dazu möglicherweise eine seriöse Quelle? > Dynamische Typisierung kann man mögen oder nicht, hat Vor- und > Nachteile. Aber diese Eigenschaft sagt nichts über die Sauberkeit einer > Sprache aus. > > Perl dagegen ist ein buntes Sammelsurium von: "Ich konnte mir mit diesem > neuen Konstrukt an der Stelle noch 2 Zeilen Code einsparen!!einself", es > ist das pure Chaos. Deinem negativen Urteil über Perl möchte ich mich ausdrücklich nicht anschließen, aber in einem Punkt hat Python zweifellos einen gewaltigen Vorzug, nämlich bei der Typisierung. Python ist nämlich entgegen anderslautender Gerüchte typsicher, auch wenn es den Typ an den Wert und nicht an den Variablennamen bindet, während Perl tatsächlich keine Typisierung kennt und deswegen Ausdrücke wie "print(3 + '4');" ohne Warn- oder Fehlermeldung zuläßt und "7" ausgibt. Python wirft an dieser Stelle natürlich einen TypeError mit dem Hinweis, daß die Addition von Ganzzahlen und Strings nicht unterstützt wird. > Daher setzt man in größeren Projekten auch Hilfsmittel zur statischen > Codeanalyse ein und arbeitet mit Erweiterungen der Typsysteme. (Z.B. > über Annotations - gibt's btw. auch für Python, z.B. als mypy) An dieser Stelle sei auch auf Attrs [1] verwiesen... [1] https://www.attrs.org/en/stable/ > Keine normale Linux-Distribution würde heute noch ohne Python > funktionieren, es gibt komplette Webframeworks (z.B. Django), ORMs, > Paketmanager, Backupsysteme etc. pp. Tatsächlich steht Python sogar ausdrücklich als Option im Linux Filesystem Hierarchy Standard (FHS) und ist somit Bestandteil der Linux Standard Base (LSB). > Die Geschwindigkeit ist halt ein Preis den man leider zahlen muss - und > manchmal ist der Preis auch zu hoch. Wobei es ja etliche Möglichkeiten gibt, Python bei Bedarf deutlich zu beschleunigen, angefangen bei alternativen Interpretern wie Pypy bis hin zu der Möglichkeit, Python ganz oder nur einzelne Teile des Codes in andere Programmiersprachen zu übersetzen und dann in nativen Code zu übersetzen. Und dann gibt es natürlich immer noch die Möglichkeit, performancekritische Teile in C oder C++ zu machen und diese dann über Python selbst, Cython oder Boost::Python in das Python-Programm einzubinden.
> Ich wüßte jetzt nicht, daß Python als "Lernsprache" gestartet sei... hast Du dazu möglicherweise eine seriöse Quelle? Auf die Schnelle: http://python-history.blogspot.com/2009/02/early-language-design-and-development.html - demnach basiert Python auf ABC, das eine Lernsprache gewesen ist. Ich hab es schon mehrfach gelesen und bisher nicht genauer recherchiert. Würde mich jetzt nicht wundern wenn tatsächlich nur ABC als Lernsprache konzipiert war und Python große Anleihen von ABC genommen hat, was Python irgendwo zwischen "war eine Lernsprache/war keine Lernsprache" platziert. Bzgl. dem Typsystem: Perl ist schwach typisiert, Python ist stark typisiert. Schwach typisierte Sprachen sind neben Perl z.B. noch JavaScript, PHP und Tcl. Erfahrungsgemäß "nervt" schwache Typisierung bei großen Projekten viel stärker als dynamische Typisierung. Es bringt lauter lustige Verhaltensweisen hervor die man vorher nicht erwartet hätte, z.B. "11"+1==111, "11"-1==10. (Es gibt viele Beispiele im Netz, ein paar z.B. hier: https://javascript.plainenglish.io/javascript-is-drunk-ec4ca3a84608?gi=7753695685e0 (war der erste Suchtreffer dazu))
Johannes schrieb: > Erfahrungsgemäß "nervt" schwache Typisierung bei großen Projekten viel > stärker als dynamische Typisierung. Es bringt lauter lustige > Verhaltensweisen hervor die man vorher nicht erwartet hätte, z.B. > "11"+1==111, "11"-1==10. Das liegt aber an sich weniger am Typsystem, sondern daran, dass (wie bei den meisten Sprachen) der Additions-Operator bei den Strings für die Konkatenation missbraucht wird. Wäre das nicht so, dann würde sich die Addition und Subtraktion hier gleich verhalten. Übrigens ist das etwas, das ausgerechnet Perl anders macht. Dort wird der Punkt für die Konkatenation verwendet.
Nur_ein_Typ schrieb: > auch wenn es den Typ an den Wert und > nicht an den Variablennamen bindet Hat mich eine Menge Hirnschmalz gekostet zu verstehen, dass Numpy-Operationen schon mal wieder Listen erzeugen! Aber als Anfänger hat man ja erst mal jede Menge Baustellen und die Fehlermeldungen in Py finde ich schlicht hervorragend!! Und das Verstehen dieser Fehlermeldungen trägt ganz entschieden zum Lernerfolg bei. Gruß Rainer
trotz meines Nicks hat Python einen entscheidenden Vorteil: Man weiss auch noch nach Jahren was man programmiert hat, bei C & Co ist das schon nach 2-3 Wochen vergessen. Das ist auch der Grund, warum im Laborbereich Python so erfolgreich ist, blitzschnell angepasst, läuft und es gibt unzählige Bibliotheken für jeden Zweck. Bevor ich in C programmiere, nehme ich lieber Assembler.
Rolf M. schrieb: > Johannes schrieb: >> Erfahrungsgemäß "nervt" schwache Typisierung bei großen Projekten viel >> stärker als dynamische Typisierung. Es bringt lauter lustige >> Verhaltensweisen hervor die man vorher nicht erwartet hätte, z.B. >> "11"+1==111, "11"-1==10. > > Das liegt aber an sich weniger am Typsystem, sondern daran, dass (wie > bei den meisten Sprachen) der Additions-Operator bei den Strings für die > Konkatenation missbraucht wird. Bitte schau' genauer hin, Rolf: bei "11" und 1 handelt es sich eben nicht um Strings, sondern um einen String und eine Ganzzahl, und zwischen diesen ist ein Additionsoperator nun einmal eher sinnlos. Streng, aber dynamisch typisierte Skriptsprachen wie Python und Ruby werden in diesem Fall also mit einem Fehler aussteigen, während nicht typisierte Skriptsprachen wie PHP oder Perl anstelle eines Fehlers den String einfach in eine Zahl wandeln und damit rechnen. Daher ergibt "11" + 1 in Perl tatsächlich 12 und "11" - 1 ergibt 10. Dieses Verhalten kann unter (zugegeben seltenen) Umständen zu schwer auffindbaren Fehlern führen. Und genau das hat natürlich mit dem fehlenden Typsystem von Perl und PHP zu tun, denn typsichere Skriptsprachen wie Python und Ruby lassen sowas eben nicht zu.
Johannes schrieb: > Bzgl. dem Typsystem: Perl ist schwach typisiert, Python > ist stark typisiert. Schwach typisierte Sprachen sind > neben Perl z.B. noch JavaScript, PHP und Tcl. Hmm. Mir will scheinen, dass die Einstufung von Tcl als "schwach typisiert" nicht so besonders viel aussagt, denn... > Erfahrungsgemäß "nervt" schwache Typisierung bei großen > Projekten viel stärker als dynamische Typisierung. Es > bringt lauter lustige Verhaltensweisen hervor die man > vorher nicht erwartet hätte, z.B. "11"+1==111, "11"-1==10. ...nichts davon funktioniert in Tcl: Strings werden durch Hintereinanderschreiben verkettet (ja, das klappt auch mit Variablen), und die Operatoren "+" und "-" sind außerhalb des "expr"-Kommandos (das mathematische Ausdrücke auswertet) nicht definiert.
Rainer V. schrieb: > Nur_ein_Typ schrieb: >> auch wenn es den Typ an den Wert und >> nicht an den Variablennamen bindet > > Hat mich eine Menge Hirnschmalz gekostet zu verstehen, dass > Numpy-Operationen schon mal wieder Listen erzeugen! Aber als Anfänger > hat man ja erst mal jede Menge Baustellen und die Fehlermeldungen in Py > finde ich schlicht hervorragend!! Und das Verstehen dieser > Fehlermeldungen trägt ganz entschieden zum Lernerfolg bei. Naja, ganz grundsätzlich sehe ich ziemlich häufig, daß Einsteiger besonders in Python dazu neigen, gleich von vorneherein mit den "dicken Brocken" anzufangen. Meiner ganz persönlichen Ansicht zufolge wäre es allerdings sinnvoller erstmal die Grundlagen der Sprache und ihre Bibliotheken zu lernen und sich erst danach mit Erweiterungen wie numpy, scipy, Pandas, oder Ähnlichen zu beschäftigen... Klar, ich verstehe: die wenigsten lernen Python als reinen Selbstzweck sondern sie wollen ein neues Werkzeug um ihr aktuelles Problem zu lösen. Numbercrunching, Machine Learning, Datenvisualisierung, Statistik, ein GUI-Programm oder eins mit einem schicken Webfrontend in Flask, Bottle oder Django, oder... Aber leider ist Python eine ausgesprochen flexible Sprache und diese Flexibilität nutzen manche Bibliotheksentwickler für völlig irre, aber auch sehr coole Dinge. Und wenn man ohnehin noch Einsteiger ist verwirrt so etwas eher als zu helfen... ;-) Deswegen rate ich in solchen Fällen erstmal die Sprache zu lernen. Datentypen und Kontrollstrukturen, List- und Dict-Comprehensions, Objektorientierung, was gibt es in der Standardbibliothek, wie funktionieren Dekoratoren, virtualenv / venv, Deskriptoren... und erst dann wenn man diese Dinge sicher beherrscht sollte man darüber nachdenken sich den "großen" Bibliotheken zu nähern. Ist aber nur meine ganz persönliche Meinung. Das kann jeder gerne anders sehen und machen. Viel Spaß und Erfolg jedenfalls!
Apropos Einstieg PyPico und Micropython ... Beitrag "PiPico Micropython" Das ein- oder andere nützliche Code Beispiel lässt sich dort finden ( inclusive der üblichen MC-Net Nörglerei )
> Beitrag "PiPico Micropython"
Apropos Thonny-IDE: die funktioniert mittlerweile super .. kann ich sehr
empfehlen.
Stefan ⛄ F. schrieb: > Programmiersprachen sind wie Schraubendreher mit unterschiedlichen > Köpfen. Am Ende geht es darum die Schraube zu drehen und sie muss > halten. Wenn das Bauwerk nicht hält wird niemand sagen, dass der > Schraubendreher Schuld war. Endlich mal was vernünftiges. Danke.
Sheeva P. schrieb: > Bitte schau' genauer hin, Rolf: bei "11" und 1 handelt es sich eben > nicht um Strings, sondern um einen String und eine Ganzzahl, Das ist mir bewusst. > und zwischen diesen ist ein Additionsoperator nun einmal eher sinnlos. Man könnte das gleiche auch für zwei Strings sagen. Offenbar wird hier für die Subtraktion der String implizit in einen Integer konvertiert, und dann kann die Operation durchgeführt werden. Da kann man nun darüber streiten, ob das eine gute Idee ist oder nicht. Aber dass der Additionsoperator sich nicht konsistent dazu verhält, liegt eben daran, dass er für Strings was anderes als eine Addition macht. Die Subtraktion ist dagegen für Strings nicht definiert. > Streng, aber dynamisch typisierte Skriptsprachen wie Python und Ruby > werden in diesem Fall also mit einem Fehler aussteigen, während nicht > typisierte Skriptsprachen wie PHP oder Perl anstelle eines Fehlers den > String einfach in eine Zahl wandeln und damit rechnen. Daher ergibt "11" > + 1 in Perl tatsächlich 12 und "11" - 1 ergibt 10. Ja, weil - wie gesagt - Perl den Additionsoperator nicht für die Konkatenation missbraucht. Somit ist die einzige Möglichkeit, die Operation durchzuführen, eine Konvertierung der "11" in einen Integer, genau wie bei der Subtraktion. > Dieses Verhalten kann unter (zugegeben seltenen) Umständen zu schwer > auffindbaren Fehlern führen. Und genau das hat natürlich mit dem > fehlenden Typsystem von Perl und PHP zu tun, denn typsichere > Skriptsprachen wie Python und Ruby lassen sowas eben nicht zu. Wobei die vollständig dynamische Typisierung auch ihre Tücken hat, die es wiederum bei statisch typisierten Sprachen nicht gibt.
Wühlhase schrieb: > Heute ist > man um viele Erfahrungen klüger, die man einfach noch nicht hatte als C > entwickelt wurde, und ein adäquater Ersatz wäre wirklich angebracht. > > Ich denke aber nicht daß Python dieser Ersatz werden wird, so eine > Sprache müßte schon eigens für hardwarenahe Zwecke entwickelt werden, > und das ist Python einfach nicht. Rust ist der geeignete Nachfolger von C!
Axel S. schrieb: > Nur stellt sich dann die Frage, wozu man Arduino > (bzw. [1]) überhaupt braucht. Die Arduino-Hardware nutze ich ganz gerne mal für kurze Testaufbauten, wenn ich weiß, ich brauche es nicht dauerhaft oder ich einfach keine Lust habe, selbst was zu layouten und Platinen zu bestellen. Mit den ganzen I/Os auf Buchsenleisten ist das ja recht praktisch. Allerdings nutze ich nicht die grottenschlechte IDE von Arduino und dieses merkwürdige vermurkste C, was dort verwendet wird, sondern schreibe die Programme wie sonst für AVR auch mit anderen Editoren und lasse den GCC drüber laufen. AVRdude ist es ja egal, ob ich meinen ISP dran habe, oder einen Arduino mit Bootloader, man muß es ihm nur sagen. ;-) Was Python angeht, ich käme nicht auf die Idee, es auf Mikrocontrollern zu verwenden, da bin ich eingefleischt im Lager C/Assembler. Allerdings hat Python für mich durchaus eine Daseinsberechtigung - als Beispiel habe ich vor einer Weile mal von einem Freund die Frage bekommen, ob ich die Journaldatei seiner Registrierkasse auswerten und bestimmte Daten extrahieren und als CSV besser auswertbar speichern könnte. Für so etwas, wo es nicht auf die letzte Millisekunde Laufzeit ankommt, man von den guten Funktionen zur Stringbearbeitung profitiert, und es unterm Strich noch den Vorteil bietet, daß ich so etwas unter Linux schreiben und der Freund ohne Probleme unter Windows laufen lassen kann, ist Python genial. In C hätte ich neben dem Betriebssystemproblem wesentlich mehr Aufwand treiben müssen.
nix_python schrieb: > Man weiss auch noch nach Jahren was man programmiert hat, > bei C & Co ist das schon nach 2-3 Wochen vergessen. Dass man seinen eigenen Code vergisst ist mir nicht unbekannt. Aber den Zusammenhang zur Programmiersprache musst du mal erklären. Den sehe ich nämlich überhaupt gar nicht.
nix_python schrieb: > trotz meines Nicks hat Python einen entscheidenden Vorteil: > > Man weiss auch noch nach Jahren was man programmiert hat, bei C & Co ist > das schon nach 2-3 Wochen vergessen. Das hat doch aber nichts mit der Sprache zu tun, sondern mit Erfahrung und daraus resultierendem Programmiertil. Ich habe früher auch mal so programmiert, daß ich nach wenigen Monaten wieder vergessen hätte was ich da gemacht habe und ich behaupte, daß es mit Python nicht besser gemacht hätte. Heute programmiere ich in C und Java so, daß es mir relativ wenig Mühe macht nach einem halben Jahr wieder in mein Projekt zurückzufinden.
> Heute programmiere ich in C und Java so, daß es mir relativ wenig Mühe > macht nach einem halben Jahr wieder in mein Projekt zurückzufinden. Das ist eine wichtige Fähigkeit die viele gern vergessen. Murks kann man natürlich in jeder Programmiersprache machen, auch z.B. in Rust. Was man mit dem Werkzeug anstellt liegt immer noch in der Hand des Entwicklers. Aber manche Werkzeuge sind einfach blöd, z.B. Schlitzschraubendreher (PHP). Man rutscht ständig ab und schneidet sich irgendwo. Zur schwachen/starken Typisierung: Die gibts natürlich in unterschiedlichen Qualitätsstufen, und Javascript und PHP stellen definitiv das untere Ende dieser Skala dar. (Ich muss jedes mal nachschauen wie man in Javascript auf null prüft weil's so hässlich ist.) Trotzdem gehen auch in Perl Dinge die nicht gehen sollten, z.B.:
1 | $foo= "123" + "456"; # $foo = 579 |
2 | $bar = sub_str($foo, 2, 1); # $bar = 9 |
3 | $bar .= " lives"; # $bar = "9 lives" |
4 | $foo -= $bar; # $foo = 579 - 9 = 570 |
(Sorry ich musste das sub str entstellen, scheinbar gibts hier eine wildgewordene Spam-Protection) Mit einer strikten Typisierung, d.h. jedes Objekt hat einen fest zugeordneten Typ, wäre das nicht möglich. Dazu hat Perl einfach extrem viele Eigenheiten, einige sind z.B. hier aufgelistet: https://metacpan.org/dist/perlsecret/view/lib/perlsecret.pod Ich brauch kein Werkzeug das ich erst nach ausführlichem Studium aller Interna so halbwegs verstehe.
Hallo Stefan. Stefan ⛄ F. schrieb: >> wer denkt sich Einrückungen als Spracheigenschaft aus … > > Ich finde das auch ganz schrecklich, habe aber bemerkt dass jüngere > Leute das wesentlich lockerer sehen. Nicht nur jüngere, auch so Oppas wie ich. ;O) > Es hat aber auch eine gute Seite: > Ich habe noch kein völlig unleserlich eingerücktes Python Script > gesehen, denn das würde nicht funktionieren. Ich bin ein Chaot und brauche darum eine extrem gut und deutlich strukturierte Umgebung, um mich zurechtzufinden. Einrückungen bieten genau dass. Mit den Unbequemlichkeiten drumherum komme ich problemlos klar. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Johannes schrieb: > Aber manche Werkzeuge sind einfach blöd, z.B. Schlitzschraubendreher > (PHP). Man rutscht ständig ab und schneidet sich irgendwo. Das ist aber mutig, PHP mit einem guten alten Schlitzschraubendreher zu vergleichen. Verwitterter alter Faustkeil, OK. PHP, von Maurerburschen im Delirium ersponnen, einer meinte noch: Mal ehrlich, das traust du dich nicht!
Hallo Johannes. Johannes schrieb: > Aber manche Werkzeuge sind einfach blöd, z.B. Schlitzschraubendreher > (PHP). Man rutscht ständig ab und schneidet sich irgendwo. Nein, auch Schlitzschraubendreher haben ihre Qualitäten. ;O) Wenn ich weiss, dass ich irgendein Gehäuse einmal total verdreckt oder überstrichen zurück bekomme, habe ich eine starke Tendenz dazu, Schlitzschrauben zu verwenden, weil die Schlitze bekomme ich leichter freigekratzt als Kreuz- oder Torxköpfe. Einen Schlitz bewkomme ich auch unterwegs mit einem Taschenmesser auf, wenn er nicht zu fest sitzt. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
> Einen Schlitz bewkomme ich auch unterwegs mit einem Taschenmesser auf, > wenn er nicht zu fest sitzt. Genau das ist der ultimative Beweiss wieso wir alle bis in alle Ewigkeit C benutzen werden. :-) Zumal ja jeder bereits ein Taschenmesser hat. > Rust ist der geeignete Nachfolger von C! Nein, das wird noch diskutiert! Auch hier im Forum.... Olaf
Nachdenklicher schrieb: > Allerdings nutze ich nicht die grottenschlechte IDE von Arduino und > dieses merkwürdige vermurkste C, was dort verwendet wird, sondern > schreibe die Programme wie sonst für AVR auch mit anderen Editoren und > lasse den GCC drüber laufen. Das "merkwürdig vermurkste C" nennt sich C++ und wird ganz einfach mit einem g++ übersetzt. Das scheinen die Arduino-Macher nur eher zu verstecken, indem sie es die "Arduino Programming Language" nennen. Es ist eher die Library und die undurchsichtige build-Magie, die merkwürdig vermurkst sind. > Für so etwas, wo es nicht auf die letzte Millisekunde Laufzeit ankommt, > man von den guten Funktionen zur Stringbearbeitung profitiert, und es > unterm Strich noch den Vorteil bietet, daß ich so etwas unter Linux > schreiben und der Freund ohne Probleme unter Windows laufen lassen kann, > ist Python genial. In C hätte ich neben dem Betriebssystemproblem > wesentlich mehr Aufwand treiben müssen. Gerade Stringverarbeitung ist etwas, wo der Unterschied zwischen C und Python größer nicht sein könnte. Python ist geradezu dafür gemacht, während es in C schon extrem umständlich und fehlerträchtig ist. Der Geschwindigkeitsunterschied fällt sowieso nicht ins Gewicht, da oft mehr Zeit für den File-Zugriff drauf geht als für die Verarbeitung.
Rolf M. schrieb: > Das "merkwürdig vermurkste C" nennt sich C++ und wird ganz einfach mit > einem g++ übersetzt. Das scheinen die Arduino-Macher nur eher zu > verstecken, indem sie es die "Arduino Programming Language" nennen. Es > ist eher die Library und die undurchsichtige build-Magie, die merkwürdig > vermurkst sind. C++ ist für mich vermurkstes C. ;-) Ich habe ja nix gegen OOP, aber C++ finde ich grauenhaft. Das dann kombiniert mit dem wirklich schlechten Editor der Arduino-IDE und der vermurksten Library ist doch zum Abgewöhnen. Rolf M. schrieb: > Gerade Stringverarbeitung ist etwas, wo der Unterschied zwischen C und > Python größer nicht sein könnte. Python ist geradezu dafür gemacht, > während es in C schon extrem umständlich und fehlerträchtig ist. Der > Geschwindigkeitsunterschied fällt sowieso nicht ins Gewicht, da oft mehr > Zeit für den File-Zugriff drauf geht als für die Verarbeitung. Eben. Und genau das ist ja der Gedanke dahinter, die Sprache nach dem Verwendungszweck auszusuchen. :-) Und bei der Geschwindigkeit ist es ja nicht nur der File-Zugriff. Bei einem Programm, das man 1x im Monat laufen läßt, ist es relativ gleich, ob es 10 oder 20 Sekunden braucht, insbesondere wenn man dagegen die beim Programmieren gesparte Zeit rechnet, weil man sich an der komfortablen Stringverbiegerei von Python bedient.
Nachdenklicher schrieb: > Bei einem Programm, das man 1x im Monat > laufen läßt, ist es relativ gleich, ob es 10 oder 20 Sekunden braucht, Bei C versus interpretiertem Python sind es aber eher 10 versus 400 Sekunden.
Python ist bei praktisch allen Datenstrukturen extrem effizient in der Ausdrucksweise, auch z.B. Linq oder Java Streams sind ein Witz dagegen. Beispiel: Indiziere eine Liste von Objekten über ihren Namen um O(log(n)) Zugriffszeiten bei der Namenssuche zu erreichen:
1 | class A: |
2 | def name(self)->str: |
3 | ... |
4 | |
5 | list_of_a=[...] |
6 | a_by_name={i.name():i for i in list_of_a}
|
7 | |
8 | for i in a_bunch_of_names: |
9 | if(i in a_by_name): ... |
10 | else: ... |
Sache erledigt. Man kann sich wirklich gut auf den Algorithmus
konzentrieren. In C (ohne ++) ein Dictionary zu bauen macht so gar
keinen Spaß, am Ende nehmen die Leute der Einfachheit halber einen list
lookup (der auch kein 1zeiler ist) und schwupps ist der C Code bei 1000
Instanzen langsamer als Python.
> C++ ist für mich vermurkstes C. ;-)
Du musst zugeben, es ist seit C++11 besser geworden. Man kann die
wichtigeren Teile von std inzwischen sogar halbwegs leserlich
nachimplementieren, ein std::function war zu prä-C++11 Zeiten an
Hässlichkeit nicht zu überbieten.
Wobei die std-Schreiber manchmal schon auf einem anderen Stern leben.
Stefan ⛄ F. schrieb: > Bei C versus interpretiertem Python sind es aber eher 10 versus 400 > Sekunden. Da die 20 Sekunden die Pythonlaufzeit waren, wäre die C-Laufzeit noch kürzer gewesen. Wir reden also von einem Zeitrahmen, wo das - gerade bei nur monatlicher Nutzung - wirklich völlig nebensächlich ist. Johannes schrieb: > Du musst zugeben, es ist seit C++11 besser geworden. ¯\_(ツ)_/¯ Hab mir das seit damals (keine Ahnung, welcher Standard das war) nie wieder angeschaut.
Axel S. schrieb: > Was immer du damit sagen willst. Den Interpreter und die (bei Python > nicht gerade kleine) Library brauchst du trotzdem. Der wird einmalig geschrieben und nicht mehr verändert. Änderungen erfolgen nur noch am Python-Code. Axel S. schrieb: > Nur ist das halt das exakte Gegenteil von "hardwarenah Programmieren". Wenn ich im Skript direkt auf die Hardware zugreifen kann, ist das hardwarenah. Es besagt nicht, dass es Echtzeit sein muss. Ich habe hier ein einfaches Beispiel: * Abfragen eines DS1820 Sensors * Abfragen eines Tasters. * Anzeigen der Temperatur auf einem Display * Senden der Temperatur über RS232 an ein anderes Gerät * Empfangen von Daten über RS232 von diesem Gerät * Ansteuerung von RGB-LED und Summer. Bis auf die Tastenabfrage läuft das Programm sehr gemächlich. Es muss sich ja nur einmal in der Minuten um seine Aufgaben kümmern. Das funktioniert bei mir auf einem RPi Nano unter Python. Ich würde sagen, dass ich hier die Hardware programmiert habe.
Was ist eigentlich aus LUA geworden? Man liest nichts mehr darüber.
Stefan ⛄ F. schrieb: > Was ist eigentlich aus LUA geworden? Man liest nichts mehr darüber. Und zu was? Zu Recht! Benutze es manchmal selbst in C/C++ Programmen, aber wirklich nur weil ich bis jetzt nichts anderes zum einbetten gefunden habe. Wenn ich Lua mit einem Satz beschreiben sollte würde ich sagen: So etwas kann sich nur ein Mönch ausdenken! PS. Bekiffter, ich habe bekiffter vergessen. Bitte im letzten Satz einfügen.
nix_python schrieb: > Man weiss auch noch nach Jahren was man programmiert hat, bei C & Co ist > das schon nach 2-3 Wochen vergessen. Das ist auch der Grund, warum im > Laborbereich Python so erfolgreich ist, blitzschnell angepasst, läuft > und es gibt unzählige Bibliotheken für jeden Zweck. > > Bevor ich in C programmiere, nehme ich lieber Assembler. Ich weiß zwar nicht ob es inzwischen einen "selektiven" Alzheimer gibt, aber wenn, dann hast du ihn. Was hat das mit der Programmiersprache zu tun ob man nach 2-3 Wochen noch durch das durchsteigt was man gemacht hat oder nicht? Und dann noch Assembler ins Spiel bringen...
Netzwanze schrieb: > Axel S. schrieb: >> Was immer du damit sagen willst. Den Interpreter und die (bei Python >> nicht gerade kleine) Library brauchst du trotzdem. > > Der wird einmalig geschrieben und nicht mehr verändert. Änderungen > erfolgen nur noch am Python-Code. Und bei einem Compiler ist das anders? Die obige Aussage bezieht sich ja darauf, dass es hieß, dass es ein großer Vorteil von Python sei, dass man keinen Compiler braucht, um das Programm zu ändern. Naja, dafür braucht man halt einen Interpreter, und den nicht nur zum ändern, sondern auch, wenn man das Programm nur ausführen will.
Bernd W. schrieb: > Einrückungen bieten > genau dass Und jeder besserer Editor oder der in einer Python-IDE überprüft das, so dass man da überhaupt keinen Mist bauen kann... Gruß Rainer
Rainer V. schrieb: > Und jeder besserer Editor oder der in einer Python-IDE überprüft das, so > dass man da überhaupt keinen Mist bauen kann... Das ist doch Quatsch, schon aus rein logischen Erwägungen MUSS das Quatsch sein. Da die Einrückung die einzige Information ist, kann keine IDE überprüfen, ob korrekt eingerückt wurde, um das zu tun, was tatsächlich intendiert war. Alles, was die IDE tun kann ist: zu überprüfen, ob's am Ende aufgeht. Bei Sprachen, bei denen die Struktur sinnvoll (nämlich durch Token für Anfang und Ende) bestimmt wird, ist die Einrückung eigentlich komplett überflüssig für den Inhalt. Aber: Hier kann die IDE vollautomatisch die zum geschriebenen Inhalt passende Einrückung erzeugen, was es dann dem Lesenden einfacher macht, Fehler in der Struktur zu finden. Form follows function, so ist es sinnvoll. Der Python-Ansatz hingegen ist Bullshit, weil er potentiell weniger Redundanz bietet und damit naturgemäß fehlerträchtiger ist.
c-hater schrieb: > Bei Sprachen, bei denen die Struktur sinnvoll (nämlich durch Token für > Anfang und Ende) bestimmt wird, ist die Einrückung eigentlich komplett > überflüssig für den Inhalt. Aber: Hier kann die IDE vollautomatisch die > zum geschriebenen Inhalt passende Einrückung erzeugen, was es dann dem > Lesenden einfacher macht, Fehler in der Struktur zu finden. In Python muss die IDE das gar nicht machen, weil die Einrückung bereits die Struktur wiedergibt und nicht erst damit synchronisiert werden muss. > Form follows function, so ist es sinnvoll. Der Python-Ansatz hingegen > ist Bullshit, weil er potentiell weniger Redundanz bietet und damit > naturgemäß fehlerträchtiger ist. Redundanz in Code ist schlecht, weil man dann immer zwei Dinge hat, die man synchron halten muss. Und das ist es, was fehlerträchtig ist.
Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso nicht Assembler? Und PHP sowie auch JS auch nicht? Hm
Abdul K. schrieb: > Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso > nicht Assembler? Und PHP sowie auch JS auch nicht? Hm In jeder Diskussion über Programmiersprachen wirst du für jede Sprache jemanden finden, der was dran auszusetzen hat. Und wie man hier gut sieht, gibt es auch immer jemanden, der eine Sprache gut findet, weil sie ein bestimmtes Sprachfeature hat, jemanden, der es neutral sieht und jemanden, der deshalb die Sprache meidet, wie der Teufel das Weihwasser. Das ist wie bei der Frage, ob auf ein Nutellabrot Butter gehört oder auf eine Pizza Ananas.
c-hater schrieb: > Alles, was die IDE tun kann ist: zu überprüfen, ob's am Ende aufgeht. Ja und das reicht auch. Den Mist, den ich logisch verzapft habe, kann und soll keiner erkennen oder gar korrigieren. Das mach ich dann schon selbst... Gruß Rainer
Abdul K. schrieb: > Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso > nicht Assembler? Und PHP sowie auch JS auch nicht? Hm Nicht ganz. Es gibt sicherlich an jeder Programmiersprache etwas auszusetzen. Das ist zum einen dem persönlichen Geschmack geschuldet, zum anderen der Entstehungsgeschichte bzw. dem manchmal etwas seltsamen Verlauf der selben. Es gibt aber auch - ich nenn sie mal euphemistisch - Sprachen, welche von Anfang an jegliche logische Grundsubstanz vermissen lassen. PHP (Patch Hack Patch) ist solch ein Leuchtturm-Objekt. Und wer mal etwas mehr mit Lua gearbeitet hat … Zu guter Letzt haben wir dann noch die vorgeschobenen Scheinargumente (straw man fallacy) die manche vorbringen. Zu dieser Kategorie gehört zB. die kategorische Ablehnung der Einrückung bei Python. Als wenn das die wichtigste sprachbestimmende Eigenschaft wäre. Und das obwohl man sich ja selbst disqualifiziert, wenn man zugibt mit einer einfachen Einrückung nicht klar zu kommen.
Abdul K. schrieb: > Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso > nicht Assembler? Und PHP sowie auch JS auch nicht? Hm Warum denn das? Weil jemand, der sich schon in seinem Nickname als "Hater" entblößt, trolligen Unsinn absondert? Wer laut eigener Aussage solche starken Gefühle gegenüber einem Werkzeug hat, hat sich doch schon komplett disqualifiziert und desavouiert.
Abdul K. schrieb: > Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso > nicht Assembler? Und PHP sowie auch JS auch nicht? Hm Ich werfe mal Forth in den Ring! Wer sich mal mit UPN auf HP Taschenrechnern anfreunden konnte - hat da schon mal einen guten Einstieg ;-)
Walter K. schrieb: > Ich werfe mal Forth in den Ring! Ja, aber das wird hier im Forum weitgehenst ignoriert, weshalb ich mich der Einfachheit halber meist als Assembler-Freund "oute". War schon auf Atari eine helle Freude und mit Forth Controller-Software (interaktiv) zu erzeugen, muß man einfach mal gemacht haben ... Gruß Rainer
Norbert schrieb: > Zu dieser Kategorie gehört > zB. die kategorische Ablehnung der Einrückung bei Python. Als wenn das > die wichtigste sprachbestimmende Eigenschaft wäre. Und das obwohl man > sich ja selbst disqualifiziert, wenn man zugibt mit einer einfachen > Einrückung nicht klar zu kommen. Ich denke, die meisten, die die Einrückungen in Python ablehnen, benutzen Einrückungen sehr fleißig und ausgiebig in anderen Sprachen. Ich z.B. lehne dieses Konzept ebenfalls strikt ab, denn meiner Meinung nach sollten Weißzeichen keinen Code erzeugen und ich denke, daß sehen recht viele so. Ich persönlich habe es z.B. außerdem gerne, daß, wenn ich einen Codeblock z.B. nach einem If-Statement aufmache, dessen Ende auch gleich mit festlegen kann. Ohne schließende Akkolade fehlt mir da einfach was.
Rainer V. schrieb: > Den Mist, den ich logisch verzapft habe, kann > und soll keiner erkennen oder gar korrigieren. Zumal derartige logische Fehler auch in C nicht ausgeschlossen sind.
1 | if (something) |
2 | do_this(); |
3 | do_that(); |
4 | do_something_else(); |
Wie soll hier irgendein Automatismus erkennen, welche der beiden möglichen Fehler der "richtige" ist? Fehlen die geschweiften Klammern, und do_that() soll nur aufgerufen werden, wenn something wahr ist, oder ist do_that() fälschlicherweise eingerückt und soll immer ausgeführt werden? Syntaktisch korrekt ist der Code auf jeden Fall, er wird ohne Fehlermeldungen kompilieren. (Und bevor jemand seine witzigen 5 Minuten hat - er wird natürlich nur kompilieren, wenn er in einer Umgebung steht, in der die Variable und Funktionen, auf die hier Bezug genommen wird, auch vorhanden sind.) Ein Automatismus könnte hier höchstens "Einrückung und Struktur passen nicht zusammen" erkennen, aber nicht automatisch lösen. Niemand außer einem Menschen, der weiß, was der Code bezwecken soll, weiß, welche der beiden Optionen richtig ist. Ein Editor könnte die Einrückung automatisch der Struktur anpassen, logisch richtig wird es damit aber nicht zwangsweise. "Man kann Mist bauen" ist also definitiv keine Eigenschaft, die exklusiv für die eine oder die andere Sprache wäre.
Hallo c-hater. c-hater schrieb: >> Und jeder besserer Editor oder der in einer Python-IDE überprüft das, so >> dass man da überhaupt keinen Mist bauen kann... > > Das ist doch Quatsch, schon aus rein logischen Erwägungen MUSS das > Quatsch sein. Da die Einrückung die einzige Information ist, kann keine > IDE überprüfen, ob korrekt eingerückt wurde, um das zu tun, was > tatsächlich intendiert war. > Alles, was die IDE tun kann ist: zu überprüfen, ob's am Ende aufgeht. Um in jedem Fall zu überprüfen, ob das was Du da gemacht hast, sinnvoll ist, bräuchtest Du eine KI die mindestens so kompetent ist wie Du selber. ;O) Letztlich kann eine IDE nur Formalismen überprüfen. > > Bei Sprachen, bei denen die Struktur sinnvoll (nämlich durch Token für > Anfang und Ende) bestimmt wird, ist die Einrückung eigentlich komplett > überflüssig für den Inhalt. Aber: Hier kann die IDE vollautomatisch die > zum geschriebenen Inhalt passende Einrückung erzeugen, was es dann dem > Lesenden einfacher macht, Fehler in der Struktur zu finden. Und jetzt interpretiere die Ein- und Ausrückung einmal als Token..... > Form follows function, so ist es sinnvoll. Form (Einrückungen) follows function (Les- und Wartbarkeit) > Der Python-Ansatz hingegen > ist Bullshit, weil er potentiell weniger Redundanz bietet und damit > naturgemäß fehlerträchtiger ist. "Echte" Redundanz hat einen zweiten Thread, besser sogar ein anderes paralleles Programm, das in einer anderen Sprache geschrieben wurde, mindestens aber mit einem anderen Compiler übersetzt wurde. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Walter und Abdul. Walter K. schrieb: > Abdul K. schrieb: >> Also doch nicht Python? Und auch nicht Perl, C, C++, Lua und sowieso >> nicht Assembler? Und PHP sowie auch JS auch nicht? Hm > > Ich werfe mal Forth in den Ring! > Wer sich mal mit UPN auf HP Taschenrechnern anfreunden konnte - hat da > schon mal einen guten Einstieg > ;-) Wenn ihr schon so beim Brainstorming für Microcontroller bzw. Embeddet freundliche Programiersprachen seit, dann vergesst JOVIAL nicht, einen ALGOL Abkömmling. ;O) Siehe: https://de.wikipedia.org/wiki/JOVIAL Der MIL-STD-1589C, der Jovial standardisiert, findet sich hier: http://everyspec.com/MIL-STD/MIL-STD-1500-1599/MIL-STD-1589C_14577/ Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Wenn ihr schon so beim Brainstorming für Microcontroller bzw. Embeddet > freundliche Programiersprachen seit, dann vergesst JOVIAL nicht, einen > ALGOL Abkömmling. ;O) Das Thema lautet: Hardware Programmierung mit Python. Wieso verstehst Du das nicht? Lass mich raten: Du bist Rentner und selbstverliebt in inhaltslose Beiträge.
Hallo Martin. Martin schrieb: > Das Thema lautet: Hardware Programmierung mit Python. Wieso verstehst Du > das nicht? Das hat nichts mit verstehen zu tun, dass passte halt gut zum Punkt der Diskussion. Genauso könntest Du Argumentieren, dass Einrückungen oder auch nicht kein Gegenstand der Diskussion ist. ;O) > Lass mich raten: Du bist Rentner Ich hoffe, das Rentner werden kann ich noch ein Jahrzehnt hinausschieben. > und selbstverliebt in inhaltslose > Beiträge. A) Wir sind auf der Welt um unseren Narzissmus auszuleben. ;O) B) Was inhaltslos ist, entscheidest Du nicht alleine. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Das mit den Weißzeichen finde ich schon ein nachvollziehbaren gewichtiges Argument. Eine eingebaute Logik zur Prüfung auf Sinnhaftigkeit finde ich sehr vorteilhaft. Bei MIL hm, da gab's doch noch so eine Sprache, die weltfremd war...
Nachdenklicher schrieb: > Ein Automatismus könnte hier höchstens "Einrückung und Struktur passen > nicht zusammen" erkennen, aber nicht automatisch lösen. Das verlangt ja auch niemand. OK. Ich nicht. > Ein Editor könnte die Einrückung automatisch der Struktur anpassen, > logisch richtig wird es damit aber nicht zwangsweise. Klar. Aber ich kann nach dem automatischen Einrücken schon sehen, daß da gar nicht das passiert, was ich meine. Aber eigentlich ist das auch akademisch, denn jeder Code-Editor kann schon seit Jahren Code beim tippen automatisch einrücken. Wenn der Cursor nach dem ersten Statement unvermittelt auf die Höhe des if springt, sollten eigentlich die Warnlampen angehen. Und sogar das greift noch zu kurz. Die meisten Projekte haben einen Coding Style Guide. Und oft steht da die (sehr sinnvolle) Forderung drin, daß Blöcke nach einer Kondition immer explizit geklammert sein müssen. Auch wenn da nur ein Statement steht. Außer bei Python. Da geht das halt nicht.
:
Bearbeitet durch User
Axel S. schrieb: > Und sogar das greift noch zu kurz. Die meisten Projekte haben einen > Coding Style Guide. Und oft steht da die (sehr sinnvolle) Forderung > drin, daß Blöcke nach einer Kondition immer explizit geklammert sein > müssen. Auch wenn da nur ein Statement steht. In Sprachen, die Blöcke klammern, mache ich das grundsätzlich genau so. Allerdings hast du bei Python immer "das Programm macht, nach was es auf den ersten Blick aussieht". Wenn es eingerückt ist, gehört es für den Interpreter in den Block, wenn nicht, dann nicht. Wenn man in C die fehlenden Klammern übersieht, was bei schlecht formatiertem Code, schnell mal passiert, und etwas falsch eingerückt ist, könnten User und Compiler unterschiedliche Meinungen haben. ;-)
Tja, es gibt 2 Arten von Leuten. Die, die mit Python gute und große
Softwareprojekte stemmen, und die, die sich heute noch über die
Whitespaces aufregen.
Ist ja völlig legitim das es für einen persönlich eine Umgewöhnung ist.
Umgewöhnung ist Arbeit, braucht Zeit etc. pp.
Aber funktionieren tut es. Und so lange die Bugtracker nicht vor Fehlern
überquellen die auf falsche Einrückung in Python zurückzuführen sind,
würde ich nicht davon ausgehen, dass es besonders fehlerträchtig ist.
Im Alltag (schreibe oft genug parallel an Code mit {} und Python)
gewöhnt man sich dran. Es kommt auch nicht zu Verwechslungen beim
Sprachwechsel, dafür ist die Syntax und das Denkmodell bei Python zu
unterschiedlich zu Sprachen mit {}.
Beitrag #6912045 wurde von einem Moderator gelöscht.
c-hater schrieb: > Bei Sprachen, bei denen die Struktur sinnvoll (nämlich durch Token für > Anfang und Ende) bestimmt wird, ist die Einrückung eigentlich komplett > überflüssig für den Inhalt. Aber: Hier kann die IDE vollautomatisch die > zum geschriebenen Inhalt passende Einrückung erzeugen, was es dann dem > Lesenden einfacher macht, Fehler in der Struktur zu finden. Völliger Quatsch, wenn der Token an der falschen Stelle steht, sieht mam das durch die Einreichung genauso gut oder schlecht wie in Python. Ein Token bringt keinen Vorteil.
Johannes schrieb: > Aber funktionieren tut es. Und so lange die Bugtracker nicht vor Fehlern > überquellen die auf falsche Einrückung in Python zurückzuführen sind, > würde ich nicht davon ausgehen, dass es besonders fehlerträchtig ist. Es gab durchaus auch mal jemanden, der eine Variante mit Klammern gemacht hat ("Python with Braces"), aber das hat keinen interessiert, und die Webseite dazu funktioniert nicht mehr. So wichtig scheint das also nicht zu sein, denn Python erfreut sich trotzdem sehr großer Beliebtheit. Btw:
1 | $ python3 -c "from __future__ import braces" |
2 | File "<string>", line 1 |
3 | SyntaxError: not a chance |
Das Militärdingens war(/ist?) übrigens ADA. - Obergefreiter
Axel S. schrieb: > Außer bei Python. Da geht das halt nicht. Ja, und? Das Lustige an diesem "Argument" mit dem Whitespace ist, daß es immer nur von Leuten kommt, die noch nie wirklich praktisch mit Python gearbeitet haben. Oft merkt man den damit "Argumentierenden" an, daß dieser Punkt sie so sehr stört, daß sie es gar nicht erst ausprobieren wollen. Eric S. Raymond, der Autor von fetchmail und "The Cathedral and The Bazaar" und ein passionierter "Sammler von Programmiersprachen", hat vor einigen Jahren seine eigenen Erfahrungen mit Python zusammengefaßt, die den meinen im Übrigen sehr ähneln. Auch er hatte anfangs starke Vorbehalte dagegen, Whitespace als Syntaxelemente zu benutzen. Trotzdem hat er es ausprobiert, und wie man seinen Ausführungen entnehmen kann, hat er das nicht bereut und sich schnell mit der Sprache angefreundet: [1]. Auch ich fühlte mich durch die Whitespace-Geschichte (mit einem gewissen Grauen) an ältere Fortran-Versionen erinnert, deswegen habe ich mich lange geziert, mir Python einmal genauer anzuschauen. Aber dann habe ich bemerkt, daß eine ganze Reihe von großen und sehr großen Projekten wie KDE, OpenOffice oder auch PostgreSQL Python als Skriptsprache inkorporiert hatten, und da habe ich mich gefragt: warum tun die das bloß, was ist der Punkt an dieser komischen Sprache? Also habe ich beschlossen, mir Python einmal genauer anzuschauen, zumal ich KDE, OpenOffice und auch PostgreSQL im Einsatz hatte. Und was soll ich sagen? Das mit dem Whitespace hat überhaupt gar nicht wehgetan, sicherlich auch, weil mein GNU Emacs damit ganz wunderbar umgehen konnte. Und dann fielen mir schon an den ersten ein, zwei Tagen die ersten großen Stärken von Python auf: die exorbitante Infrastruktur an mitgelieferten und extern verfügbaren Bibliotheken, seine hohe Performanz, die Klarheit, Les- und Wartbarkeit des Code, dazu Typsicherheit, Introspektion und Reflexion, und und und. Binnen einer Woche habe ich entschieden, meine damalige Standardskriptsprache Perl nach 13 oder 14 Jahren durch Python ersetzen. Und diese Entscheidung habe ich seit diesem Zeitpunkt noch nicht eine Sekunde lang bereut -- Perl nutze ich nur noch da, wo es bis dato nahezu unschlagbar ist, nämlich als Filter auf der Kommandozeile mit "perl -pe" oder "perl -e". (Leider ist genau das Feature, das Perl in diesem Bereich so gut macht, gleichzeitig auch das Feature, das Perl- und auch Ruby-Code so oft schlecht lesbar und wartbar macht, nämlich die in den Sprachkern eigebauten Regular Expressions...) Tatsächlich ist es allerdings so, daß man mit Perl durchaus les- und wartbaren Code schreiben kann, aber dazu muß man diszipliniert arbeiten und sich Mühe geben. In Python hingegen muß ich diszipliniert sein und mir Mühe geben, um schlecht les- und wartbaren Code zu schreiben... Wie dem auch sei: wenn man seine Abneigung gegen die Whitespace-Geschichte einmal überwunden hat und sich mal mit Python beschäftigt, stellt man schnell fest, wie mächtig und leisungsfähig die Sprache tatsächlich ist und daß diese Sache mit dem Whitespace in der Praxis überhaupt gar kein Problem darstellt. Aber dazu muß man natürlich einmal über den eigenen Schatten springen, und nach meinen Erfahrungen sind die, die das können, meistens die besseren Entwickler und Techniker. [1] https://www.linuxjournal.com/article/3882
Knallt ihn ab, den Troll schrieb: > Ich denke, die meisten, die die Einrückungen in Python ablehnen, > benutzen Einrückungen sehr fleißig und ausgiebig in anderen Sprachen. Natürlich, aber da läßt man Einrücken, anstatt es selber zu tun. Und wenn sich die Struktur ändert, wird auch automatisch entsprechend der neuen Struktur "umgerückt". Das ist, was die Sache so komfortabel macht. Die Einrückung ist dann nur noch Feedback für den Programmierer (die Sprachen selber benötigen sie ja nicht). Der sieht sofort, ob die neueste Umstrukturierung so verlaufen ist, wie er sich das vorgestellt hat. > Ich persönlich habe es z.B. außerdem gerne, daß, wenn ich einen > Codeblock z.B. nach einem If-Statement aufmache, dessen Ende auch gleich > mit festlegen kann. Ohne schließende Akkolade fehlt mir da einfach was. Naja, es muss ja nicht unbedingt eine "}" sein. In richtigen Sprachen steht dann da automagisch z.B. gleich ein "end if". Da weiß man dann auch gleich noch, welche Art Kontrollstruktur hier ihr Ende findet... Aber klar, das "}" ist immer noch weitaus besser als garnix an dieser Stelle.
c-hater schrieb: > Der sieht sofort, ob die neueste Umstrukturierung so verlaufen ist, wie > er sich das vorgestellt hat. Bei Python sieht man es nicht nach der Umstrukturierung sonder während. c-hater schrieb: > Aber klar, das "}" ist immer noch weitaus besser als garnix an dieser > Stelle. Es ist offensichtlich wenn ein Blick abgeschlossen ist, weil du folgende Bock weniger eingerückt ist. Was willst du mehr? Es ist übersichtlicher, ein eingerückt Bock oder irgendwelche Klammern, die im Quelltext untergehen? Garnix geht in Python nicht, da wird mindestens ein pass erwartet. c-hater schrieb: > In richtigen Sprachen steht dann da automagisch z.B. gleich ein "end if" a) Liegt das nicht an der Sprache und b) wer so lange Blöcke bekommt, dass er die "Überschrift" nicht mehr sieht und deshalb nicht mehr weiß was er tut, hat andere Probleme.
Karl schrieb: > c-hater schrieb: >> In richtigen Sprachen steht dann da automagisch z.B. gleich ein "end if" > > a) Liegt das nicht an der Sprache und b) wer so lange Blöcke bekommt, > dass er die "Überschrift" nicht mehr sieht und deshalb nicht mehr weiß > was er tut, hat andere Probleme. Mal abgesehen davon, dass moderne IDEs den zugehörigen Anfangsblock hinter der schließenden Klammer einblenden können wenn es der Benutzer will. Das sieht dann z.B. so aus: https://raw.githubusercontent.com/j0meinaster/bracket-peek/master/assets/inline.png Aber wer die Tools halt nicht kennt... für mich hab ich das Feature (weis gar nicht mehr welche Sprache das war, jedenfalls nicht JavaScript, das Bild ist nur Beispiel) gleich wieder abgeschaltet. Bringt mir persönlich nichts, und ich brauch für mich nicht so viel Bling Bling im Code.
Könnte das mal bitte jemand in Python umformulieren?
1 | void showMeThisInPython(){ |
2 | for(int i = 0; i < 15; i++){ |
3 | if(i > 2 && < 8){ |
4 | if(isEven(i){doSomeEvil();} |
5 | if(i > 5){ |
6 | doWithBiggerFive(i); |
7 | doSomeOther(); |
8 | }
|
9 | }
|
10 | else{ |
11 | switch(i){ |
12 | case 10: |
13 | foo(i); |
14 | break; |
15 | case 11: |
16 | boo(i); |
17 | break; |
18 | default:
|
19 | whooo(i); |
20 | }
|
21 | }
|
22 | }
|
23 | }
|
@ Wühlhase Hoffentlich ist bald Ostern, dann hast Du wieder was zu hoppeln.
In Python schier unmöglich: ;-)
1 | void showMeThisInPython( |
2 | ){for( |
3 | int i = 0; i < 15; i++){if( |
4 | i > 2 && i < 8){if( |
5 | isEven( |
6 | i)){doSomeEvil( |
7 | );}if( |
8 | i > 5){doWithBiggerFive( |
9 | i);doSomeOther( |
10 | );}}else{switch( |
11 | i){case 10:foo( |
12 | i);break;case 11:boo( |
13 | i);break;default:whooo( |
14 | i);}}}} |
Johannes schrieb: > weis gar nicht mehr welche Sprache das war, jedenfalls nicht > JavaScript, das Bild ist nur Beispiel Extension "Bracket Peek" für VS Code. Funktioniert wohl mit vielen "geklammerten Sprachen", mit Python natürlich mangels Klammern nicht. ;-) Gern geschehen.
Wühlhase schrieb: > Könnte das mal bitte jemand in Python umformulieren? Man könnte damit anfangen, es in funktionierenden und verständlichen C-Code umzuformulieren.
Hallo Rolf. Rolf M. schrieb: >> Könnte das mal bitte jemand in Python umformulieren? > > Man könnte damit anfangen, es in funktionierenden und verständlichen > C-Code umzuformulieren. Richtig. Weil das ist Syntax Akrobatik und keine solide Programmierarbeit. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Leute, an diesem Codeschnipsel soll nix funktionieren. Der ist nicht zum Ausführen gedacht, und das return fehlt auch nicht - es ist einfach nur nicht da. Wer nur C kennt, denke es sich bitte einfach, andere syntaxänliche Sprachen können darauf verzichten und ich wollte mich auf das Nötige beschränken. Ich wollte lediglich mal sehen, um wieviel übersichtlicher das hochgelobte Fehlen der Akkoladen in Python aussieht. Und so realitätsfern ist der Code ja nun wirklich nicht. Die bisherigen Antworten darauf sind zwar ernüchternd, aber entsprechen so dem altbekannten Forendurchschnitt. Oder ist die Pythonsyntax doch nicht so geil?
Nachdenklicher schrieb: > Extension "Bracket Peek" für VS Code. Funktioniert wohl mit vielen > "geklammerten Sprachen", mit Python natürlich mangels Klammern nicht. > ;-) > > Gern geschehen. Meinte das es nicht dieses Plugin war, sondern irgendeine andere IDE ;-) Zu dem Beispiel: Mal abgesehen von der grauenhaften Struktur des Codes und dem offensichtlichen Syntaxfehler - wo liegt das Problem? Auf die Schnelle (werd dafür ja nicht bezahlt):
1 | def show_me_this_in_python(): |
2 | |
3 | for i in range(15): |
4 | |
5 | if(i>2 and i<8): |
6 | if(isEven(i)): |
7 | doSomeEvil() |
8 | if(i>5): |
9 | doWithBiggerFive(i) |
10 | else: |
11 | if(i==10): foo(i) |
12 | elif(i==11): boo(i) |
13 | else: whooo(i) |
(Ich musste mich zusammenreißen das untere if-elif-else nicht als elif-elif-else als Ersatz für else zu schreiben, aber das hätte die Codestruktur verändert.) Sollte das C++ sein und i per Referenz übergeben/verändert werden dann 1) Schande über den Schreiber für so einen Hirnfurz, und 2) Statt for ein while und i als Rückgabewert der jeweiligen Methode.
Anmerkung: Man denke sich noch das fehlende doSomeOther() unter das doWithBiggerFive(i).
andersrum wird es interessanter: wie sehen 'multiple return values', 'Positional and Keyword Arguments' und andere Features in C aus? Vermutlich ist nicht alles für gute Performance auf kleinen Embedded Systemen brauchbar, aber trotzdem sind das für mich sehr schöne Features. Warum immer nur auf das Einrücken rumgeritten wird, was einfach nur Übung erfordert das schnell zu erfassen, kann ich nicht verstehen.
neuer PIC Freund (Gast) >In Python schier unmöglich: ;-) >void showMeThisInPython( ... Das ist kein Problem, weil in Firmen die etwas auf sich halten diese zyklomatische Komplexität verboten ist und der Entwickler im Code-Review glatt abgewatscht würde.
@ Johannes Warum springst Du über das Stöckchen von Wühlhase? Du bist doch nicht sein Hündchen, oder?
Bei Sprachparsern erhält man häufig solche Konstrukte. (Natürlich mit sinnvollen Bedingungen in den ifs und dann mit while statt for.)
@Martin Weil von ihm bisher mehr sinnvolle Beiträge kamen als von dir ;-) Aber ja, ich weiß worauf du hinaus willst und hab daher extra vorher nachgesehen.
Wühlhase schrieb: > Leute, an diesem Codeschnipsel soll nix funktionieren. Warum soll man es dann in eine andere Sprache umformulieren? > Der ist nicht zum Ausführen gedacht, und das return fehlt auch nicht - es > ist einfach nur nicht da. Was für ein return? > Wer nur C kennt, denke es sich bitte einfach, andere > syntaxänliche Sprachen können darauf verzichten und ich wollte mich auf > das Nötige beschränken. Das hier funktioniert in keiner mir bekannten Sprache:
1 | if(i > 2 && < 8){ |
> Die bisherigen Antworten darauf sind zwar ernüchternd, aber entsprechen > so dem altbekannten Forendurchschnitt. Nein, es entspricht der Qualität des von dir gezeigten Codes. Johannes S. schrieb: > andersrum wird es interessanter: wie sehen 'multiple return values', > 'Positional and Keyword Arguments' und andere Features in C aus? Mehrere Return-Werte lassen sich zwar nicht in C, aber zumindest in C++ inzwischen gut handhaben.
1 | #include <iostream> |
2 | #include <tuple> |
3 | #include <string> |
4 | |
5 | std::tuple<int, std::string> myfunc() |
6 | {
|
7 | return { 42, "Hello world" }; |
8 | }
|
9 | |
10 | int main() |
11 | {
|
12 | auto [ number, text ] = myfunc(); |
13 | std::cout << number << ' ' << text << '\n'; |
14 | }
|
Die Iteration über ein Dictionary aus Python:
1 | for key, value in something.items(): |
kann man damit entsprechend in C++ mit einer std::map so schreiben:
1 | for (auto& [ key, value ]: something) |
> Warum immer nur auf das Einrücken rumgeritten wird, was einfach nur Übung > erfordert das schnell zu erfassen, kann ich nicht verstehen. Warum recht viele so eine extreme Abneigung dagegen haben, verstehe ich auch nicht.
:
Bearbeitet durch User
Rolf M. schrieb: > int main() > { > auto [ number, text ] = myfunc(); > std::cout << number << ' ' << text << '\n'; > } Ist aber schon ein bisschen kryptisch.
Johannes schrieb: > Karl schrieb: >> a) Liegt das nicht an der Sprache und b) wer so lange Blöcke bekommt, >> dass er die "Überschrift" nicht mehr sieht und deshalb nicht mehr weiß >> was er tut, hat andere Probleme. > > Mal abgesehen davon, dass moderne IDEs den zugehörigen Anfangsblock > hinter der schließenden Klammer einblenden können wenn es der Benutzer > will. Das sieht dann z.B. so aus: > Aber wer die Tools halt nicht kennt... für mich hab ich das Feature > (weis gar nicht mehr welche Sprache das war, jedenfalls nicht > JavaScript, das Bild ist nur Beispiel) gleich wieder abgeschaltet. > Bringt mir persönlich nichts, und ich brauch für mich nicht so viel > Bling Bling im Code. Was bitteschön hat dein Bling Bling Tool mit meinen Aussagen zu tun?
Karl schrieb: > Rolf M. schrieb: >> int main() >> { >> auto [ number, text ] = myfunc(); >> std::cout << number << ' ' << text << '\n'; >> } > > Ist aber schon ein bisschen kryptisch. Was ist daran kryptischer als an der Python-Variante?
1 | number, text = myfunc() |
@Karl Das bezog sich auf den Kommentar von c-hater (den ich mit zitiert habe!) und war eine Ergänzung zu deinem Kommentar dazu.
Rolf M. schrieb: >>> std::cout << number << ' ' << text << '\n'; > Was ist daran kryptischer als an der Python-Variante? Das der Shift Operator zur Ausgabe missbrauch wird, man das Ziel aber links hin schreiben muss, finde ich schon ziemlich von hinten durch die Brust. Aber lassen wir das. Jede Sprache hat ihre "Macken".
Stefan ⛄ F. schrieb: > Rolf M. schrieb: >>>> std::cout << number << ' ' << text << '\n'; >> Was ist daran kryptischer als an der Python-Variante? > > Das der Shift Operator zur Ausgabe missbrauch wird, man das Ziel aber > links hin schreiben muss, finde ich schon ziemlich von hinten durch die > Brust. Aber lassen wir das. Jede Sprache hat ihre "Macken". Das hat im Grunde wenig mit C++ zu tun sondern ist den C++ Standard-Bibliotheken anzulasten und war auch in meinen Augen ein Griff ins Klo, den man nur nicht mehr los wird. C++ definiert nur die Möglichkeit Operatoren überladen zu können und das nutzen die Libs. Natürlich kann man damit auch großem Mist bauen. Mist kann man aber auch mit jeder anderen Sprache bauen. Ich vermute mal ganz am Anfang von C++ hat man krampfhaft versucht eine sinnvolle Anwendung der Überladung von Operatoren zu finden. Das Ergebnis landete dann fast von Anfang an in allen Büchern und Libs. Also was solls, keiner ist gezwungen die Syntax von oben zu benutzen. Wem printf reicht der nimmt halt das, oder baut sich seinen eigenen Kram. Aber die These "C++ ist Scheiße wegen der Ausgabe mit dem Shift-Operator" kann man so nicht stehen lassen.
Wühlhase schrieb: > Könnte das mal bitte jemand in Python umformulieren? Ist es so schwer von einer Syntax in die andere zu wechseln?
1 | def showMeThisInPython(): |
2 | for i in range(15): |
3 | if i > 2 and i < 8: |
4 | if isEven(i): doSomeEvil() |
5 | if(i > 5): |
6 | doWithBiggerFive(i) |
7 | doSomeOther() |
8 | else: |
9 | match i: |
10 | case 10: |
11 | foo(i) |
12 | case 11: |
13 | boo(i) |
14 | case _: |
15 | whooo(i) |
Wie man sieht, spart man sich 6 Zeilen mit }- Klammern und in den Zeilen
die {-Klammern und Semikolons.
Besseren Code bekommt man nicht durch die Syntax, sondern in dem man den
Code anders strukturiert:
1 | def showMeThisBetterInPython(): |
2 | for i in range(15): |
3 | if i > 2 and i < 8 and isEven(i): |
4 | doSomeEvil() |
5 | elif i > 5 and i < 8: |
6 | doWithBiggerFive(i) |
7 | doSomeOther() |
8 | elif i == 10: |
9 | foo(i) |
10 | elif i == 11: |
11 | boo(i) |
12 | else: |
13 | whooo(i) |
Interessant wird es erst, wenn man das Ganze in ein Objekt packt, daber dafür ist dein Beispiel zu trivial. Man kann auch noch mit Listen, Tupel oder Dictionaries arbeiten, ja nach dem, was man vor hat. Der Voerteil von Python ist halt, dass man nicht alles auf einen int runterbrechen muss.
Rolf M. schrieb: > Was ist daran kryptischer als an der Python-Variante? > number, text = myfunc() Die kryptischen Zeichen :: << << ' ' << << '\n' ?
Karl schrieb: > Rolf M. schrieb: >> Was ist daran kryptischer als an der Python-Variante? >> number, text = myfunc() > > Die kryptischen Zeichen :: << << ' ' << << '\n' ? Die sind aber eine andere Baustelle und haben rein gar nichts mit den mehreren Returnwerten zu tun. Ich hab das nur hingeschrieben, damit das Programm sein Ergebnis auch ausgibt. Aber ja, die Ausgabe über den Shift-Operator ist nicht gerade schön zu lesen. In C++20 kann man schreiben:
1 | cout << format("{} {}\n", number, text); |
was dann schon gar nicht mehr so weit von Python weg ist. Wobei für
jemanden, der das nicht kennt, "{} {}\n" auch eher kryptisch aussieht.
Leider ist die Unterstützung dafür in den Compilern noch recht dünn
gesät.
:
Bearbeitet durch User
Johannes schrieb: > def show_me_this_in_python(): > for i in range(15): > > if(i>2 and i<8): > if(isEven(i)): > doSomeEvil() > if(i>5): > doWithBiggerFive(i) > else: > if(i==10): foo(i) > elif(i==11): boo(i) > else: whooo(i) Ah, danke...schön daß jemand verstanden hat, worauf ich hinaus wollte. Mir gefallen Weißzeichen als Syntaxelement zwar nach wie vor nicht so recht, gleichwohl muß ich jedoch sagen daß mir in Sachen Übersichtlichkeit nichts fehlt. Codeblöcke über Einrückung zu trennen scheint tatsächlich mindestens so gut zu funktionieren wie mit {}. Danke für den Eindruck. Karl schrieb: > Ist es so schwer von einer Syntax in die andere zu wechseln? Natürlich nicht, wenn einem die Zielsyntax vertraut ist. Und das ist der Punkt: Ich kenne die Syntax nicht. Ich habe zweimal ernsthaft darüber nachgedacht, Python zu lernen und mich etwas mit der Sprache beschäftigt, und kenne daher auch z.B. das Dictionary, aber ich bin natürlich weit davon entfernt die Syntax von Python zu kennen. Und zur Diskussion über Einrückungen als Syntaxelement ist doch ein direkter Vergleich das beste Argument, daher meine Bitte an jemanden, der die Sprache kennt.
Wühlhase schrieb: > Und zur Diskussion über Einrückungen als Syntaxelement ist doch ein > direkter Vergleich das beste Argument, daher meine Bitte an jemanden, > der die Sprache kennt. Das hätteste doch alles mit dir allein ausmachen können. Und Wühlhase schrieb: > Ich habe zweimal ernsthaft darüber > nachgedacht, Python zu lernen und was denn noch? In jedem Tutorial hast du spätestens in "Kapitel 3" Einrückung... da brauchts doch kein blödsinniges "Codebeispiel" um zu erkennen, dass das was hat! Lustigerweise lehnen hier erstaunlich viele Spezialisten Python gerade wegen der Einrückung(!) ab und erzählen im gleichen Atemzug, dass sie Python gar nicht kennen...ist schon irgenwie merkwürdig :-) Rainer
Karl schrieb: > Rolf M. schrieb: >> int main() >> { >> auto [ number, text ] = myfunc(); >> std::cout << number << ' ' << text << '\n'; >> } > > Ist aber schon ein bisschen kryptisch. Weil Rolf '\n' anstelle von std::endl benutzt hat? ;-)
Rainer V. schrieb: > Das hätteste doch alles mit dir allein ausmachen können. Ja, hätte ich. Habe ich aber nicht...und nun? Wenn das für dich überflüssig war, was ist dann dein Post?
Wühlhase schrieb: > Ah, danke...schön daß jemand verstanden hat, worauf ich hinaus wollte. Das hättest Du der Einfachheit halber natürlich auch gleich erwähnen können. Ohne diese Erwähnung habe wohl nicht nur ich einen falschen Eindruck bekommen... > Mir gefallen Weißzeichen als Syntaxelement zwar nach wie vor nicht so > recht, gleichwohl muß ich jedoch sagen daß mir in Sachen > Übersichtlichkeit nichts fehlt. Codeblöcke über Einrückung zu trennen > scheint tatsächlich mindestens so gut zu funktionieren wie mit {}. Das tut es. Wobei mir an Johannes' Code noch zwei Dinge aufgefallen sind, nämlich erstens daß er um die Bedingungen bei seinen ifs und elifs Klammern benutzt, die in Python zwar erlaubt, aber (meistens) überflüssig sind, zweitens daß er an einigen Stellen von der Möglichkeit Gebrauch macht, einzelne Statements direkt hinter die Bedingungen zu schreiben und an anderen Stellen darauf verzichtet. Konsistenter, IMHO auch übersichtlicher und besser an PEP8 [1] orientiert wäre also dies:
1 | def show_me_this_in_python(): |
2 | '''we love docstrings''' |
3 | for i in range(15): |
4 | if i > 2 and i < 8: |
5 | if isEven(i): |
6 | doSomeEvil() |
7 | if i>5: |
8 | doWithBiggerFive(i) |
9 | else: |
10 | if i == 10: |
11 | foo(i) |
12 | elif i == 11: |
13 | boo(i) |
14 | else: |
15 | whooo(i) |
[1] https://www.python.org/dev/peps/pep-0008/
Hallo, Rainer V. schrieb: > Lustigerweise lehnen hier erstaunlich viele Spezialisten Python > gerade wegen der Einrückung(!) ab und erzählen im gleichen > Atemzug, dass sie Python gar nicht kennen... Ich glaube das das nicht speziell gegen Phyton gerichtet ist, sondern alle Fälle betrifft wo die Struktur/Formatierung des Quelltextes Teil der Sprachsyntax ist. > ...ist schon irgenwie merkwürdig :-) Finde ich gar nicht. rhf
Roland F. schrieb: > Rainer V. schrieb: >> Lustigerweise lehnen hier erstaunlich viele Spezialisten Python >> gerade wegen der Einrückung(!) ab und erzählen im gleichen >> Atemzug, dass sie Python gar nicht kennen... > > Ich glaube das das nicht speziell gegen Phyton gerichtet ist, sondern > alle Fälle betrifft wo die Struktur/Formatierung des Quelltextes Teil > der Sprachsyntax ist. Also ich finde das auch lustig, wie vehement hier gestandene und oft sogar erfahrene Ingenieure und Techniker ein Werkzeug ablehnen, das sie gar nicht kennen, dies nur wegen einer Eigenschaft, deren Alternative sie sogar selbst als redundant erkennen, während dasselbe Werkzeug laut aller einschlägiger Indizes und der Umfragen etwa von StackOverflow zu den beliebtesten Werkzeugen der Welt gehört... das sagt sicher mehr über die Ablehnenden als über das Werkzeug. ;-)
Hallo Roland F. Roland F. schrieb: > Ich glaube das das nicht speziell gegen Phyton gerichtet ist, sondern > alle Fälle betrifft wo die Struktur/Formatierung des Quelltextes Teil > der Sprachsyntax ist. Die alten Alpharüden und Silberrücken fühlen sich halt gegängelt. ;O) Das mit den Einrückungen ist aber auch nur eine Regel, wie alle anderen beim Programmieren auch, an die man sich halten muss. Nur die anderen Regeln kennen Sie seit ewig und sind daran gewöhnt. Ich will ja auch nicht behaupten, dass es bei mir anders ist, ab 30-40 lässt das mit der Flexibilität ja erheblich nach, aber ich war auch nie so der grosse Programmierer, von daher war die Gewöhnung nicht so fest. Zum Thema "Python und Microcontroller". Micropython hat nach der Wikipedia keinen Interpreter sondern einen Compiler. Nur die Syntax und Struktur der Sprache orientiert sich an Python(3). Daher würde ich eine ähnliche Performance wie bei C und Microcontrollern erwarten. Siehe: https://de.wikipedia.org/wiki/MicroPython Vieleicht meldet sich ja jemand, der beides kennt und vergleichen kann.....in Vergleich auch zu Assembler. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Micropython hat nach der > Wikipedia keinen Interpreter sondern einen Compiler. Der Codey Rocky basiert auf dem ESP32 mit Micropython. So langsam wie die Skripte dort laufen muss das dann aber ein sehr schlechter Compiler sein.
> Aber die These "C++ ist Scheiße wegen der Ausgabe mit dem > Shift-Operator" kann man so nicht stehen lassen. Ich finde ja eigentlich das C++ eine schoene Sprache ist. Zumindest die Teilmenge die ich davon benutze. :) Da Problem vieler komplexer Sprachen in den letzen 10-15Jahren ist aber das die IMHO vom Elfenbeinturm vereinnahmt wurden. Es duerfte mittlerweile schwer geworden sein Buecher zu diesem Thema zu finden die man noch versteht ohne die Sprache schon vorher verstanden zu haben. Da war frueher mal besser. Und da liegt IMHO auch letztlich der Naehrboden wieso oefters mal neue Sprachen modern werden. Da ist das alles noch hemdsaermliger und man kommt einfacher rein. Olaf
Bernd W. (berndwiebus) Benutzerseite 19.12.2021 13:42 >Zum Thema "Python und Microcontroller". Micropython hat nach der >Wikipedia keinen Interpreter sondern einen Compiler. Nur die Syntax und >Struktur der Sprache orientiert sich an Python(3). Daher würde ich eine >ähnliche Performance wie bei C und Microcontrollern erwarten. >Siehe: https://de.wikipedia.org/wiki/MicroPython >Vieleicht meldet sich ja jemand, der beides kennt und vergleichen >kann.....in Vergleich auch zu Assembler. Was die Performance angeht hat Yalu bereits hier im Thread Analysen dazu angestellt: Beitrag "Re: Hardware Programmierung mit Python" Maximimising Python Speed: https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html
Bernd W. schrieb: > Zum Thema "Python und Microcontroller". Micropython hat nach der > Wikipedia keinen Interpreter sondern einen Compiler. Du kannst Micropython genau wie das normale Python interaktiv nutzen. Das klingt mir eher nicht nach einem Compiler. Unter https://www.micropython.org/unicorn/ gibt es auch einen online-Emulator, auf dem Micropython läuft.
Für den RP2040 gibt es einen sehr schönen Simulator für Micropython: Beitrag "Re: PiPico Micropython"
Markus schrieb: > Für den RP2040 gibt es einen sehr schönen Simulator für > Micropython: > Beitrag "Re: PiPico Micropython" Für vier Euro gibt es einen sehr schönen Raspberry Pi Pico. Für null Euro Aufpreis gibt es ein sehr schönes Micropython UF2 Image. Knopf drücken, anstecken, Drag'n'Drop, fettich.
>Für vier Euro gibt es einen sehr schönen Raspberry Pi Pico. Ja, aber im Simulator kannst Du noch LEDs, Displays, Servos, MPUs usw. ansteuern. Im Repository gibt es auch schon neue Peripherie wie Schrittmotoren, die noch nicht in der aktuellen GUI sind.
Rolf M. schrieb: > Du kannst Micropython genau wie das normale Python interaktiv nutzen. > Das klingt mir eher nicht nach einem Compiler. Im REPL-Modus wird der Code interpretiert, sonst kompiliert. Kompiliert wird normalerweise nach Bytecode, der wiederum interpretiert wird. Mit Funktionsdekoratoren kann der Compiler angewiesen werden, für die entsprechenden Funktionen Native- statt Bytecode zu erzeugen. Der Compiler optimiert aber längst nicht so gut, wie man es von aktuellen C-Compilern gewohnt ist. Das hängt u.a. damit zusammen, dass Python im Gegensatz zu C eine sehr dynamische Sprache ist und damit zu Compilezeit nur wenig Informationen verfügbar sind, die den Compiler bei der Optimierung unterstützen könnten. Außerdem ist der Compiler Bestandteil des Laufzeitsystems und ist deswegen sehr schlank gehalten. Mit Type-Hints kann der Programmierer den Compiler bei der Optimierung etwas unterstützen. Für PCs gibt es Cython, das Python-Code (optional mit Typdeklarationen) nach C-Code kompiliert, der seinerseits von einem optimierenden C-Compiler in die Mangel genommen wird, was zu deutlich effizienterem Code führt. Evtl. kann man Cython per Crosscompiler auch für Mikrocontroller nutzen, ich habe das aber noch nicht ausprobiert.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.