Hallo, hin und wieder schreibe ich mal ein kleines Programm für irgendwelche Berechnungen in Quickbasic. Auf Dauer wäre eine modernere Programmiersprache angebracht. Habe mal C# (.Net) und Purebasic ins Auge gefasst. Hat aber alles seine Vor- und Nachteile (C# = Bindung an MS; Purebasic kostet 80€ usw.). Kann etwas C vom GCC, vielleicht gibt es auch etwas, womit man unkompliziert in C proggen kann. Eine einfache GUI für die erstelleten Programme wäre super, Consoleneingabe ohne Maus ist auf Dauer doof. Die Programme sollen in jedem Fall für Win-Rechner kompiliert werden können, für andere OS wäre auch gut. Für einen brauchbaren Tipp wäre ich dankbar!
Pelles C, ca 10MB Programmgröße. http://www.smorgasbordet.com/pellesc/ http://www.pellesc.de/index.php?page=download&lang=de&version=7.00 Ich habe die 7er-Version für XP, aktuell ist die 8.
http://www.fltk.org/doc-1.3/fluid.html Für Win und Linux der gleiche Code. Sieht anfangs schwierig aus, man gewöhnt sich aber leicht daran. Die Windows Version ist auch unter Quincy2005 zu finden: http://www.codecutter.net/tools/quincy/ Es gibt reichlich Tutorials und Videos dafür.
JonasKl schrieb: > hin und wieder schreibe ich mal ein kleines Programm für irgendwelche > Berechnungen in Quickbasic. > Auf Dauer wäre eine modernere Programmiersprache angebracht. Dann lade dir Lazarus herunter und programmiere in Pascal. Sowas wie Lazarus ist gerade für "hin und wieder mal ein kleines Programm" genau das Richtige. Erstens kannst du dich auf dein eigentliches Anliegen konzentrieren und zweitens ist eine grafische Oberfläche für deine Berechnungen gleich dabei. Und es kommt ne Exedatei bei heraus, ohne Notwendigkeit für irgendwelche fetten Laufzeitsysteme. W.S.
Python mit PyQt für GUI. Mit PyInstaller wandelt man das ganze dann in ein ausführbares Binary.
W.S. schrieb: > Dann lade dir Lazarus herunter und programmiere in Pascal. +1 Einer der wenigen Tage an denen ich W.S mal zustimmen muss. In der Kombination Desktop-GUI und Cross-Platform und leichtgewichtig (keine Laufzeitlibs) und nativer Code und freie Lizenz (komplett LGPL mit Zusatzerlaubnis zum statisch Linken) gibt es derzeit weit und breit keine Alternative, weder frei noch unfrei. Wenn es das nicht gäbe wäre die nächstbeste Wahl Qt, aber da mangelts leider am leichtgewichtig, also mal eben eine .exe machen und auf nem anderen Rechner starten is nicht, da muss erst noch eine dreistellige Zahl an Megabytes dlls mit beigelegt werden. Eventuell würd ich vielleicht auch noch die Kombination C++/wxWidgets in Betracht ziehen, das ist weniger schwergewichtig aber da muss man sich schon wieder die Tools zusammensuchen und RAD/GUI-Builder vom Kaliber der beiden zuvorgenannten Systeme gibts da leider auch nicht.
JonasKl schrieb: > mal ein kleines Programm für irgendwelche > Berechnungen in Quickbasic. JonasKl schrieb: > Purebasic kostet 80€ usw.). Es gibt auch eine Probeversion von Purebasic. Wenn die Programme nicht zu umfangreich werden, ist das eine ganz feine Sache. 800 Zeilen wollen erst mal geschrieben werden. Es entsteht eine .exe-Datei, die man ohne irgendwelchen anderen Kram mitzukopieren, auf einem anderen Rechner laufen lassen kann. MfG Paul
Ohne Zögern: Python. Ist für deinen Anwendungsfall wohl perfekt. Der Vorteil bei deiner Aufgabenstellung von Python gegenüber reinem C oder PureBasic ist, dass es sogenannte "list comprehensions" unterstützt. Man kann Berechnungen also fast so hinschreiben, wie man es aus der Mathematik gewöhnt ist und muss nicht erstmal extra irgendwelche Schleifen ausprogrammieren. Und falls in wirklich z.B. Matrixoperationen brauchst o.ä. gibts mit NumPy und Co Bibliotheken die sehr gut sind. Und mit PyPlot wird das ganze dann direkt geplottet und du brauchst nichtmal Excel oder sowas ;) Wird nicht umsonst in der wissenschaftlichen Community sehr oft angewendet. Bezüglich list comprehensions. Sieh dir mal die Beispiele hier an: http://www.secnetix.de/olli/Python/list_comprehensions.hawk Das so hinzuschreiben geht soweit ich weiß noch in C#, aber in C sicher nicht.
Finger weg von den ganzen Exoten, nimm Python! pyDev als IDE uns alles wird gut. Kaj schrieb: > Python mit PyQt für GUI. > Mit PyInstaller wandelt man das ganze dann in ein ausführbares Binary. Als Alternative zu PyQt wäre noch wxPython zu nennen. wxFormBuilder ist ein recht gutes Tool um grafisch GUIs zu basteln und den entsprechenden Code zu generieren.
Ich halte Python auch für eine gute Wahl. JonasKl schrieb: > Berechnungen in Quickbasic... > Eine einfache GUI für die erstelleten Programme wäre super, > Consoleneingabe ohne Maus ist auf Dauer doof. Wenn Du bisher eh nur Console gebaut hast und es Dir um reine Berechnungsprogramme geht, empfehle ich aufbauend auf Python "Jupyter Notebooks" zu erstellen. Nutze sie als Mathcad / Matlab Ersatz. Schau Dir mal die Beispiele unter http://nbviewer.jupyter.org/ an.
Nimm Python, damit kann man sehr effektiv und intuitiv programmieren und es existieren viele mächtige Bibliotheken. Mit Datentypen wie Listen und Dictionaries stehen elegante Werkzeuge zur Verfügung mit denen man mit ein paar Zeilen Code Programme erzeugt, für deren Funktionalität man in klassischen strukturierten Sprachen leicht hunderte Codezeilen benötigt. Gruß, Bernd
Bernd K. schrieb: > In der Kombination Desktop-GUI und Cross-Platform *und* > leichtgewichtig (keine Laufzeitlibs) und nativer Code und freie > Lizenz (komplett LGPL mit Zusatzerlaubnis zum statisch Linken) gibt es > derzeit weit und breit keine Alternative, weder frei noch unfrei. Was ist mit Tcl/Tk? > Wenn es das nicht gäbe wäre die nächstbeste Wahl Qt, aber da mangelts > leider am leichtgewichtig, also mal eben eine .exe machen und auf nem > anderen Rechner starten is nicht, da muss erst noch eine dreistellige > Zahl an Megabytes dlls mit beigelegt werden. Man kann Qt auch statisch linken, wenn man das will. Dann hat man eine einzige .exe Datei. Die dann zugegeben nicht ganz klein sein wird.
Bernd O. schrieb: > Nimm Python, > > damit kann man sehr effektiv und intuitiv programmieren Das mit dem "intuitiv" ist wohl Ansichtssache.
Obwohl in eigentlich nur unterschreiben kann, Python zu lernen, verwende ich ab und zu Lua-Quick-Try-Out um z.B. Datensätze zu visualisieren (wenn es z.B. mit einem Tabellenkalkulationsprogramm schwierig werden würde), http://www.aaabbb.de/Lua-Quick-Try-Out/Lua-Quick-Try-Out_en.php
Lazarus/FreePAscal..kein Scheiss..zum mal eben schnell die beste Wahl http://www.lazarus-ide.org/ Super Community, alle sehr einfach umsetzbar egal ob RS323 oder sonstwas und auch für Atmel/Arm in Form von mikroe zu bekommen
ach ja und Pascal hat den riesigen Vorteil!! Du kannst dee Programme einfach kopieren wie alte DOS Programme, es wird keine Intsllationssoftware oder sonstwas benötigt
Hach, die ganzen Programmiersprachenexoten hier. Zum Glück kommt auch die gute Empfehlung, Python zu nehmen. Die kann man voll unterstützen. Gegebenenfalls kannst du dir aber auch (wenngleich mir die Programmiersprache nicht gefällt) Javascript anschauen. Ich weiß ja nicht, was für Programme du machst, aber mit Javascript, HTML5 und diversen Frameworks läuft das alles dann in einem modernen Browser, somit schön plattformunabhängig. Die sehr gute und leicht zu bedienende GUI-Engine gibt's gratis dazu.
kann man mit Pyton ARM oder AVR programmieren?!Mit Pascal schon..ist also deutlich flexibler für die Zukunft
Bernd K. schrieb: > Wenn es das nicht gäbe wäre die nächstbeste Wahl Qt, aber da mangelts > leider am leichtgewichtig, also mal eben eine .exe machen und auf nem > anderen Rechner starten is nicht, da muss erst noch eine dreistellige > Zahl an Megabytes dlls mit beigelegt werden. Bei mir sind es gerade mal 18 MB. Das ist weit weg von dreistellig.
:
Bearbeitet durch User
So oder so würde ich auc C oder Pascal/Lazarus setzen. Einfach weil es am vielseitigsten ist. Schau Dir LAzarus nur 5 Minuten an und Du wirst begeistert sein
JonasKl schrieb: > hin und wieder schreibe ich mal ein kleines Programm für irgendwelche > Berechnungen Klingt für mich nach matlab. Gibt m.m.n. nix besseres und schnelleres für solche Aufgaben. Edit: vor allem auch, wenn man mit einer gui anstatt console berechnen will.
:
Bearbeitet durch User
Python hat sich in den letzten 20 Jahren auf den Platz 4 gemausert. Und das - obwohl es kein Produkt eines Software-Riesen ist bzw. war, wie es z.B. Java und C# sind. Python hat sehr breitgefächerte Community, von Web über Text Processing bis Machine Learning. Ich nutze es oft für "kleinere" Parsing Aufgaben und als "matlab". Stichwort Distribution Anaconda. Ich nutze es aber auch zum Schreiben von Tests für meine Baugruppen. Python OOP halte ich für etwas gewöhnungsbedürftig und neige eher zur funktionalen Programmierung. Refactoring ist schwierig und man kann leicht Fehler einbauen, die erst zur Laufzeit sichtbar werden. pylint dürfte bei größeren Projekten unverzichbar sein. Roadmap geht zum gradual typing. Ironischerweise gilt das gleiche auf für statische Sprachen wie C#. Zusammengefasst ... Python ist definitiv gute Wahl.
Sonja schrieb: > Super Community, alle sehr einfach umsetzbar egal ob RS323 oder sonstwas Auch das biete Python in überragender Qualität. Sonja schrieb: > ach ja und Pascal hat den riesigen Vorteil!! Du kannst dee Programme > einfach kopieren wie alte DOS Programme, es wird keine > Intsllationssoftware oder sonstwas benötigt Kann man mit Python auch, so wie mit so ziemlich allen anderen auch. Einfach das Pythonprogramm mit PyInstaller zu einem executable machen, am besten noch mit --onefile, dann gibt es sogar nur eine einzige datei, die man nach belieben kopieren kann. Sorry, aber irgendeinen "riesen Vorteil" für Pascal kann ich da leider nicht sehen. Sonja schrieb: > kann man mit Pyton ARM oder AVR programmieren?!Mit Pascal schon..ist > also deutlich flexibler für die Zukunft Für ARM ja, nennt sich MicroPython: http://micropython.org/ Am Ende kannst du in jeder Sprache Code für jede Platform schreiben, solange ein entsprechende Übersetzungseinheit (Compiler) vorhanden ist. Als Beispiel seien einfach mal Projekte wie EmScripten (C/C++ zu Javascript) oder Cython (Python zu C) genannt. Also auch dieser Vorteil ist damit leider dahin. Langsam wirds eng mit den "riesen Vorteilen" ;) Das schöne an Python ist, dass Python eine sehr mächtige Standard-Lib mitbringt. Man hat fertige Parser, Codecs, Libs für HTTP und Co. alles von Hause aus dabei, ohne das man "Third Party Libs" installieren muss. Reginald L. schrieb: > Gibt m.m.n. nix besseres und schnelleres > für solche Aufgaben. Octave, ist nicht zwingend besser oder schneller, aber gleichwertig :P
Kaj schrieb: > Octave, ist nicht zwingend besser oder schneller, aber gleichwertig :P Das ist doch Matlab für Arme ;P
Sonja schrieb: > kann man mit Pyton ARM oder AVR programmieren?! Ja, Python läuft auf Himbeeren, Bananen, Orangen und gar Äpfel - alle mit ARM CPUs. Ausserdem: * <https://micropython.org/>; * <http://www.eluaproject.net/>; AVRs sind mit 8 halt noch pickelig und dürfen nicht mitmachen, ausser sie sind erwachsen (32) dann liegt immerhin schon eLua drin. - - Als Äpfel noch babies waren (also ][ ) lief die ganze UCSD-Pascal IDE darauf - auf welchem AVR geht das?
Sonja schrieb: > So oder so würde ich auc C oder Pascal/Lazarus setzen. > Einfach weil es am vielseitigsten ist. > Schau Dir LAzarus nur 5 Minuten an und Du wirst begeistert sein Es kommt auf das Problem an. Wenn es um hardwarenahe Programmierung geht, führt sowieso kein Weg an C/C++ vorbei. Man wird kaum einen Controller finden, für den es keinen C-Compiler gibt - bei Pascal-Compilern wird's schnell eng. Wenn's darüber hinausgeht, gerät man mit der relativ strengen Typisierung von C/Pascal schnell ins Hintertreffen gegenüber der Flexibilität, die Python bietet. Mit ein paar Zeilen Python-Code erzeugt man Programme, die in C/Pascal ein Vielfaches an Quelltext benötigen. Vermutlich laufen die C/Pascal-Programme schneller und benötigen weniger Ressourcen - aber die Erstellung/Pflege ist entsprechend langwierig. Meine Arbeitszeit ist mir wertvoller als ein paar ms eingesparte Rechenzeit. Gruß, Bernd
Reginald L. schrieb: > Kaj schrieb: >> Octave, ist nicht zwingend besser oder schneller, aber gleichwertig :P > Das ist doch Matlab für Arme ;P Ich hatte mal eine Gleichung in Matlab zu lösen, die (optische) Darstellung der Lösung hat mir bei Octave aber deutlich besser gefallen :) root schrieb: > pylint dürfte bei größeren Projekten unverzichbar sein. PyLint und flake8. root schrieb: > Refactoring ist schwierig und > man kann leicht Fehler einbauen, die erst zur Laufzeit sichtbar werden. <klugscheißer> Für sowas hat man ja Unittest ;) </klugscheißer> Das Mitgebrachte Unittest-Modulo von Python finde ich übrigens auch recht gut. root schrieb: > Python hat sich in den letzten 20 Jahren auf den Platz 4 gemausert. > Und das - obwohl es kein Produkt eines Software-Riesen ist bzw. war Der nicht unerhebliche Einsatz bei Google dürfte aber schon erheblich zu dem Erfolg von Python beigetragen haben. :) http://quintagroup.com/cms/python/google
1 | Google has a strong relationship with the language itself and the Python |
2 | software foundation: Google is always sponsoring various Python conferences |
3 | (PyCon, EuroPython, etc). |
4 | |
5 | ... |
6 | |
7 | Python’s biggest strengths are flexibility, rapid development, scalability |
8 | and excellent performance. These are the reasons why Python is being so |
9 | actively used at Google. |
Meiner Meinung nach auch verdient. :)
Hallo Leute, Danke für die vielen Antworten! Bin sehr positiv überrascht! Also halte ich mal fest, Python oder Pascal wird wärmstens empfohlen, Javascript hätte den Vorteil, plattform- oder browserunabhängig zu sein. Ok, dann gehe ich mal in mich und überlege, was von den drei Sachen für meine Miniprojekte am besten geeignet ist. Noch mal vielen Dank! Weitere Anregungen hier in diesem Beitrag sind natürlich gerne Willkommen! Viele Grüße!
das klingt mit Python ja alles in de Tat nicht schlecht (Ich selber arbeite schon ewig mit Pascal und arbeite mich momentan in C ein) Aber wieso wird dann doch scheinbar recht wenig damit programmiert gerade im µc bereich liest man hier so gut wie nie was , ok Pascal natürlich auch :-) Wo ist der gravierende Nachteil für Python auf µc oder generell auch für PCs?
Nimm Lazarus! Damit kannst Du den Code für die gängigen Plattformen - Win, Linux, Mac OSX - übersetzen und Du erhältst für alle eine ausführbare Datei ohne irgendwelchen Overhead, wie Laufzeitumgebungen, Frameworks etc. Mit Lazarus kannst Du Konsolenanwendungen, Anwendungen mit GUI und auch DLL's bzw. Lib's erzeugen. Mit dem kommerziellen Pedant (Delphi) ist auch .Net möglich. Für Lazarus/Delphi gibt es sehr viele freie Komponenten mit denen sich eigentlich jede Aufgabe lösen läßt. Zeno
JonasKl schrieb: > Für einen brauchbaren Tipp wäre ich dankbar! Java als BASIC-Ersatz, auch nützlich für Android-Programmierung und als JavaScript im Browser. Für ernsthaftes: C++, auch nützlich für Objective-C auf iOS für Apple, und als C für Microcontrollerprogrammierung.
Kaj schrieb: > Kann man mit Python auch, so wie mit so ziemlich allen anderen auch. Ich persönlich programmieren mit dem neusten Python 3 (aktuell also 3.5). Daher kann ich sagen, dass bspw WinXP "nur" bis Python 3.4.3 unterstützt wird. Ob DOS überhaupt unterstützt wird weiß ich nicht, weil Python tote systeme nicht pflegen möchte. JonasKl schrieb: > Javascript hätte den Vorteil, plattform- oder browserunabhängig zu sein. Die anderen beiden haben den selben Vorteil.
Kaj schrieb: > <klugscheißer> > Für sowas hat man ja Unittest ;) > </klugscheißer> > Das Mitgebrachte Unittest-Modulo von Python finde ich übrigens auch > recht gut. Unittest ist sicher gut, aber auch kein Allheilmittel, weil die Tests schreibt auch derjenige der das Programm geschrieben hat und der denkt in den Kategorien des Programmes. Anwender des Programmes hingegen denken ganz anders und eigentlich müßten diese die Tests schreiben. Letztendlich kann ich mit Unittest nur einzelne Programmabschnitte abprüfen ob sie auch das tun was ich mir vorstelle, aber ich kann niemals ein Programm in seiner Komplexität abprüfen. Dies würde einen Testcode erfordern der von der Größe her in die Nähe des Programmcodes kommen dürfte. Ich erlebe das gerade praktisch mit einem Kollegen der seit zwei Jahren mein Programm (Delphi) mit C# neu implementieren will. Er nutzt umfänglich die Unittest und ja die Tests (der Programmkomponenten) laufen auch fehlerfrei durch, aber das Zusammenspiel der Komponenten im Gesamtprogramm scheint nicht korrekt zu funktionieren. Ich bringe das Teil mit zwei Mausklicks zum Absturz und zwar so das anschließend Neuinstallation nötig ist. Fazit: Unittest ist gut und hilft beim Prüfen einzelner Programmkomponenten ob diese wie gewünscht funktionieren, aber sie ist kein Garant, das dann auch das Gesamtprodukt fehlerfrei läuft. Zeno
JonasKl schrieb: > Hallo Leute, Danke für die vielen Antworten! Bin sehr positiv > überrascht! > > Also halte ich mal fest, Python oder Pascal wird wärmstens empfohlen, > Javascript hätte den Vorteil, plattform- oder browserunabhängig zu sein. Es sind nicht die Programmiersprachen selbst, die von einer bestimmten Plattform abhängig sind. Entscheidend ist ob es einen Compiler oder Interpreter für Deine jeweilige Zielplattform gibt.
Ihr könnt soviel diskutieren wie ihr wollt, am Ende läuft es sowieso immer auf die beiden überlegenen Brainfuck oder Ook! raus:
1 | ++++++++++ |
2 | [ |
3 | >+++++++>++++++++++>+++>+<<<<- |
4 | ] Schleife zur Vorbereitung der Textausgabe |
5 | >++. Ausgabe von 'H' |
6 | >+. Ausgabe von 'e' |
7 | +++++++. 'l' |
8 | . 'l' |
9 | +++. 'o' |
10 | >++. Leerzeichen |
11 | <<+++++++++++++++. 'W' |
12 | >. 'o' |
13 | +++. 'r' |
14 | ------. 'l' |
15 | --------. 'd' |
16 | >+. '!' |
17 | >. Zeilenvorschub |
18 | +++. Wagenrücklauf |
1 | Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
2 | Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
3 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. |
4 | Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
5 | Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? |
6 | Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
7 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook. |
8 | Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. |
9 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. |
10 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook. |
11 | Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
12 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. |
13 | Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
14 | Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. |
15 | Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook. |
16 | Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook. |
17 | Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! |
18 | Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook. |
Sonja schrieb: > Wo ist der gravierende Nachteil für Python auf µc oder generell auch für > PCs? Python ist eine interpretierte Sprache. Die Verwendung von Interpretersprachen auf Mikrocontrollern ist eher unüblich, wenngleich möglich. Und eben weil es eher unüblich ist, gibt es entsprechend weniger Code-Beispiele als bei den dafür üblichen Sprachen.
Sonja schrieb: > das klingt mit Python ja alles in de Tat nicht schlecht -e 's/klingt/ist/g' -e 's/nicht schlecht/ganz gut/' > Aber wieso wird dann doch scheinbar recht wenig damit programmiert > gerade im µc bereich µCs sind mit 8 einfach noch zu klein, die dürfen vllt. mal so grad CP/M oder ProDOS, meist aber so knapp BASIC. Mit 32 darf dann so richtig frei ausgesucht werden, alles was Spass macht (auch was verboten ist - wie Ada, BrainFuck und so Zeugs) > liest man hier so gut wie nie was , ok Pascal > natürlich auch :-) Hier ist ja auch nur der KindergAVRten, nur wenige Pr00$. > Wo ist der gravierende Nachteil für Python auf µc oder generell auch für > PCs? Auf Computern: KEINE Nachteile. Auf PCs: zwischen Tastatur & Bürostuhl Auf µCs: ein paar (Dutzend) kB an Laufzeitumgebung. Programme welche nur wenige Hunderte Bytes gross sind kann man nicht machen.
Sonja schrieb: > ach ja und Pascal hat den riesigen Vorteil!! Du kannst dee Programme > einfach kopieren wie alte DOS Programme, es wird keine > Intsllationssoftware oder sonstwas benötigt Obwohl ich Pascalfan bin muß ich sagen das dies nun kein Alleinstellungsmerkmal von Pascal ist. Wenn das Programm keine Frameworks oder Ähnliches benötigt bist Du da völlig frei, wo Du das Programm hin kopierst. Umfängliche (Pascal) Programme die noch jede Menge Beiwerk benötigen, brauchen i.d.R. schon einen Installer, damit es am Ende funktioniert. Zeno
JonasKl schrieb: > Also halte ich mal fest, Python oder Pascal wird wärmstens empfohlen Bevor Du dich entscheidest - wirf' auch mal einen Blick auf Wikipedia: Pascal: https://de.wikipedia.org/wiki/Pascal_(Programmiersprache) Pascal ist eine Anfang der 1970-er Jahre entwickelte imperative Programmiersprache, die heute noch in älteren Anwendungen und zur einführenden Lehre ins Programmieren Verwendung findet. Im produktiven Bereich wurde sie mittlerweile von Sprachen wie Java abgelöst. Python: https://de.wikipedia.org/wiki/Python_(Programmiersprache) Python ist eine universelle, üblicherweise interpretierte höhere Programmiersprache. Ihre Entwurfsphilosophie betont Programmlesbarkeit, außerdem ist Python-Code im Vergleich zu anderssprachigem Code teilweise deutlich kürzer. Gruß, Bernd
JonasKl schrieb: > Hallo, > > hin und wieder schreibe ich mal ein kleines Programm für irgendwelche > Berechnungen in Quickbasic. > Auf Dauer wäre eine modernere Programmiersprache angebracht. > ... > > Für einen brauchbaren Tipp wäre ich dankbar! Du schreibst also Zitat "hin und wieder" mal ein Zitat "kleines Programm". Das heißt nix anderes als dass du ein GELEGENHEITSPROGRAMMIERER bist und das wahrscheinlich auch bleiben wirst, sonst hättest du das bereits geändert und wärst zu einem der Nerds geworden, die dich hier gerade zu ihrem jeweiligen Lieblingswerkzeug, dass sie seit Jahren beherrschen und täglich verwenden missionieren wollen. Da solltest du nochmals GENAU darüber nachdenken, ob du auch so ein Nerd werden willst, denn das kostet ZEIT, viel ZEIT. Jeder der dir das Gegenteil weißmachen möchte ("das geht alles ratz fatz etc.") lügt oder hat längst vergessen, wie lange er sich mit dem Kram herumgequält hat bzw. das noch immer tut. Du kommst von (Quick-) BASIC, d.h. du weißt nichts über moderne Programmier-Paradigma wie Objekt orientierte Programmierweise, strenge Typisierung, Programmierung mit Zeigern, Exception Handling usw. All das ist dir fremd. Du hattest bisher ein kleines überschaubares Tool und man will dir nun überspitzt beschrieben Gigabyte große Installationen, wahre Tool Sammlungen als neue Programmierumgebung schmackhaft machen. Nun denn, entscheide, ob das der richtige Weg für dich ist und ob du die Zeit, den Elan dafür aufbringst, dich dort hindurch zu wühlen. Aber habe immer im Hinterkopf, was du von all dem aufgeblähten Kram letztlich wirklich benutzen wirst, denn nur das brauchst du auch.
MaWin schrieb: > Java als BASIC-Ersatz, auch nützlich für Android-Programmierung und als > JavaScript im Browser. NEEEEIIN! JavaScript hat nichts mit java zutun! Ansonsten würde ich auch python oder c empfehlen, idealerweise mit qt. Oder notfals Java, was ist da gerade angesagt? Nach AWT wars glaub ich mal Swing, oder? JavaScript würde ich dafür nicht empfehlen, das wird eher zur Web & Serverentwicklung genutzt, obwohl irgendwer schon ein nodejs qt wrapper gemacht hat. Ist etwa so wie c im Browser, geht mit emscripten aber ist hölle auf erden.
Für kleine Aufgaben verwende ich bis heute noch XProfan, das es auch in freien Versionen gibt. Hatte vor Jahren auch dies und das ausprobiert. Zum einen sind bei manchen Mega Installationen erforderlich bei anderen muß man sich für ein kleines Programm mit GUI durch zig Bibliotheken hangeln, bis man fündig wird. Bei wiederum anderen muß man eine ganze Galerie von DLLs usw. mitgeben. Das ist für einen (wie mich auch), der aus der alten BASIC-Ecke kommt, nicht immer leicht. Gerade, wie JonasKl schreibt, daß er mit Quickbasic gearbeitet hat, für den wird der Umstieg nicht so schwer, da XProfan auch noch Basic ähnliche Syntax behrrscht. Außerdem hat man mit der Runtime, die zur .exe automatisch mitcompiliert wird, alle Funktionen und Befehle parat. Man braucht also nicht in irgendwelchen Bibliotheken zu suchen. Gerade so kleine Berechnungen + etwas GUI sind da in Minuten umgesetzt.
Sonja schrieb: > ach ja und Pascal hat den riesigen Vorteil!! Du kannst dee Programme > einfach kopieren wie alte DOS Programme, es wird keine > Intsllationssoftware oder sonstwas benötigt Wenn man seinen Compiler bedienen kann, ist das auch mit C bzw. C++ und auch den üblichen Klassenbibliotheken (MFC, Qt, wxWidget) möglich. Das nennt sich statisches Linken. Es wird aus verschiedenen Gründen von verschiedenen Personenkreisen für "uncool" bzw. nicht empfehlenswert gehalten, aber es funktioniert.
Hey, ich schreibe so kleine GUIs unter umständen auch Apps mit Visual Studio und C# oder XAML... Visaul Studio ist sehr Umfangreich aber auch kostenlos :D
C# aber ist eine .Net-Sprache und nicht statisch linkbar. Zwar ist mittlerweile jedes Windows mit mindestens irgendeiner .Net-Version verseucht, aber die passende ist garantiert nicht dabei, wenn man mal irgendeine .Net-Anwendung verwenden will. Und dann müssen wieder zig Megabyte Kram runtergeladen und installiert werden. Gut, man kann jetzt ganz viele verschiedene Versionen des .Net-Krams auf seinem Rechner haben, aber ist das jetzt wirklich besser?
Rufus Τ. F. schrieb: > C# aber ist eine .Net-Sprache und nicht statisch linkbar. Gar nicht? Oh je. Was hat sich MS dabei wohl gedacht?
Mark B. schrieb: > Was hat sich MS dabei wohl gedacht? Na, das, an was Du da gerade denkst. Weil das ja viel besser, viel kompatibler und viel überlegener ist. Die Praxis beweist, daß das, wie so viele tolle Ideen von Microsoft, halt nicht wirklich zutrifft. Aber das ist das grundlegende Problem von "shared libraries". Tool X kann nicht verwendet werden, weil Library Y nicht in Version Z vorhanden ist. Der einzige reale Fortschritt gegenüber der klassischen DLL-Hölle ist der der Versionierung, daß also die Versionen Z, Z-1 und Z+4 gleichzeitig vorhanden sein können, ohne sich zu stören.
Habe jetzt mal Python2.7 installiert und wie hier gezeigt ein Fenster erstellt: https://www.youtube.com/watch?v=704lMVIcCVY Funktioniert super. Aber: zum Kompilieren (Run Modul F5) will Python immer nach Hause telefonieren. Wenn ich das blocke, kann anscheinend das lauffähige Programm nicht erstellt werden. Heißt das, man kann mit Python nur arbeiten, wenn man beim Kompilieren (Run Modul F5)eine funktionierende Internetverbindung hat???
Sofern keine wichtigen Gründe dagegen sprechen, würde ich ja ernsthaft in Betracht ziehen, die Programme einfach als WebApp zu entwickeln - also JavaScript (bzw. eine nach JavaScript übersetzbare Sprache wie z.B. CoffeeScript) + HTML für die GUI. Hat halt den Vorteil, dass das Programm dann ganz automatisch auf absolut jeder Plattform lauffähig ist, die über einen Webbrowser verfügt - also nicht nur Windows und Linux, sondern auch beliebigen Macs, iPads, iPhone- und Android-Smartphones. Ansonsten, falls WebApps aus irgendeinem Grund nicht in Frage kommen, wäre meine persönliche Empfehlung auch Python.
@Joachim S. (oyo) Bei WebApps ist auch Apache Cordova noch interressant.
Immer noch C# WPF und wenn es um Mobiltelefone geht dann mit Xamarin.
Joachim S. schrieb: > Sofern keine wichtigen Gründe dagegen sprechen, würde ich ja > ernsthaft > in Betracht ziehen, die Programme einfach als WebApp zu entwickeln - > also JavaScript (bzw. eine nach JavaScript übersetzbare Sprache wie z.B. > CoffeeScript) + HTML für die GUI. Dann brauchst du aber immer einen Webserver. Entweder lokal installiert oder übes Internet. Finde ich nicht so berauschend. Du kannst zwar auch so ein UI basteln, aber moderne Browser verhindern das Speichern von Dateien direkt. Das ist ein wenig blöd.
JonasKl schrieb: > Aber: zum Kompilieren (Run Modul F5) will Python immer nach Hause > telefonieren. Wenn ich das blocke, kann anscheinend das lauffähige > Programm nicht erstellt werden. > Heißt das, man kann mit Python nur arbeiten, wenn man beim Kompilieren > (Run Modul F5)eine funktionierende Internetverbindung hat??? Nein. Zum einen wird der Code streng genommen nicht "kompiliert", wenn Du F5 drückst, sondern einfach ausgeführt/interpretiert. Aber das nur nebenbei. Und das von Dir beobachtete Phänomen mit dem "nach Hause telefonieren" ist offenbar nur eine Eigenheit der "IDLE"-IDE, die Du da benutzt - und in Wirklichkeit telefoniert da offenbar gar nix nach Hause. Ich zitiere mal aus der Doku (https://docs.python.org/3/library/idle.html): "By default, IDLE executes user code in a separate subprocess via a socket, which uses the internal loopback interface. This connection is not externally visible and no data is sent to or received from the Internet. If firewall software complains anyway, you can ignore it. If the attempt to make the socket connection fails, Idle will notify you. Such failures are sometimes transient, but if persistent, the problem may be either a firewall blocking the connecton or misconfiguration of a particular system. Until the problem is fixed, one can run Idle with the -n command line switch. If IDLE is started with the -n command line switch it will run in a single process and will not create the subprocess which runs the RPC Python execution server. This can be useful if Python cannot create the subprocess or the RPC socket interface on your platform. However, in this mode user code is not isolated from IDLE itself. Also, the environment is not restarted when Run/Run Module (F5) is selected. If your code has been modified, you must reload() the affected modules and re-import any specific items (e.g. from foo import baz) if the changes are to take effect. For these reasons, it is preferable to run IDLE with the default subprocess if at all possible."
Hallo mh. mh schrieb: > Finger weg von den ganzen Exoten, nimm Python! pyDev als IDE uns alles > wird gut. Ich würde auch eher zu Python raten. Und dann zum aktuelleren Python3. Allen Unkenrufen zum Trotz verdrängt es mittlerweile Python 2.x > > Kaj schrieb: >> Python mit PyQt für GUI. >> Mit PyInstaller wandelt man das ganze dann in ein ausführbares Binary. > > Als Alternative zu PyQt wäre noch wxPython zu nennen. > wxFormBuilder ist ein recht gutes Tool um grafisch GUIs zu basteln und > den entsprechenden Code zu generieren. Wenn es wirklich leichtgewichtig mit der GUI sein soll, kann er auch nativ unter Python "tkinter" verwenden. Einfach zu handhaben, und ist nativ in allen Umgebungen, in die Python portiert wurde, zu nutzen. Also Windows, Linux, ARM (Rasberry Pi), Mac. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
JonasKl schrieb: > Habe jetzt mal Python2.7 installiert Schmeiß das bitte gleich wieder weg und nimm Python 3.
Wie, es gibt ein "richtiges" und ein "falsches" Python? Ich dachte Python sei so super cool. Da können doch solche Probleme gar nicht auftreten. ;-)
Joachim S. schrieb: > "By default, IDLE executes user code in a separate subprocess via a > socket, which uses the internal loopback interface. This connection is > not externally visible and no data is sent to or received from the > Internet. If firewall software complains anyway, you can ignore it. > If the attempt to make the socket connection fails, Idle will notify > you. Such failures are sometimes transient, but if persistent, the > problem may be either a firewall blocking the connecton or > misconfiguration of a particular system. Until the problem is fixed, one > can run Idle with the -n command line switch. > If IDLE is started with the -n command line switch it will run in a > single process and will not create the subprocess which runs the RPC > Python execution server. This can be useful if Python cannot create the > subprocess or the RPC socket interface on your platform. However, in > this mode user code is not isolated from IDLE itself. Also, the > environment is not restarted when Run/Run Module (F5) is selected. If > your code has been modified, you must reload() the affected modules and > re-import any specific items (e.g. from foo import baz) if the changes > are to take effect. For these reasons, it is preferable to run IDLE with > the default subprocess if at all possible." Ich bin sehr altes Semester. Kann jemand netterweise weiterhelfen? Was muss man tun, um Python auch offline nutzen zu können?
JonasKl schrieb: > Ich bin sehr altes Semester. Kann jemand netterweise weiterhelfen? Was > muss man tun, um Python auch offline nutzen zu können? Gar nichts musst Du tun, Python läuft standardmässig komplett offline. Was Du da als "nach Hause telefonieren" interpretiert hast, war offenbar einfach nur eine Eigenheit der "IDLE" genannten IDE, die Du da benutzt hast. Wenn Du in dieser IDE per F5 das Programm ausführen lässt, das Du da eingetippt hast, dann wendet die IDE eine etwas ungewöhnliche Methode an, um das Programm auszuführen, die Netzwerk-"Sockets" benutzt. Das hat (vermute ich jedenfalls) dazu geführt, dass eine auf Deinem PC installierte Firewall angeschlagen hat, was Du naheliegenderweise als "nach Hause telefonieren" interpretiert hast - obwohl da in Wahrheit gar keine Verbindung zum Internet aufgebaut wurde; es war trotzdem komplett "offline", selbst wenn Du den Netzwerkstecker gezogen hätte, hätte das Programm funktioniert. Wenn Du das eingegebene Programm als .py-Datei abspeicherst, und dann nicht über die IDE, sondern normal startest, wird das von Dir beobachtete Phänomen nicht auftreten. Es gibt auch die Möglichkeit, die "IDLE"-IDE mit dem Kommandozeilenparameter "-n" aufzurufen. Dann sollte dieses Phänomen ebenfalls nicht auftreten - diese Methode hat aber einen Nachteil, weshalb es grundsätzlich besser ist, die entsprechende Meldung der Firewall einfach zu ignorieren, denn die grundsätzlich berechtigte Sorge um "nach Hause telefonieren" ist in diesem Fall schlicht unbegründet.
:
Bearbeitet durch User
Sonja schrieb: > Schau Dir LAzarus nur 5 Minuten an und Du wirst begeistert sein Schau Dir Python nur 5 Minuten an und Du wirst begeistert sein. JonasKl schrieb: > Ich bin sehr altes Semester. Kann jemand netterweise weiterhelfen? Was > muss man tun, um Python auch offline nutzen zu können? Gar nichts, Python ist per default "offline". Ich weiß jetzt nicht, woher Du den Text kopiert hast, aber da geht es nicht um Python selbst, sondern um eine Entwicklungsumgebung namens IDLE, die zum Standardlieferumfang (zumindest unter Windows) gehört. Die verwendet wohl für interne Zwecke (beim Debugging) einen Netzwerk Socket auf dem Loopback Interface. Selbiges ist rein Rechnerintern und somit ebenfalls "offline". Als IDE verwende ich persönlich eclipse mit dem PyDev-Plugin, was wirklich toll funktioniert. IDLE mag für viele das Mittel der Wahl sein, hat mich aber nicht wirklich angesprochen, daher PyDev.
mh schrieb: > Sonja schrieb: >> Schau Dir LAzarus nur 5 Minuten an und Du wirst begeistert sein > Schau Dir Python nur 5 Minuten an und Du wirst begeistert sein. Pauschale Aussagen sind immer falsch. ;-) Ich habe mir Python vielleicht 5 Stunden lang angesehen und bin immer noch nicht begeistert. Vielleicht bin ich C/C++/Java/C# zu sehr gewohnt.
:
Bearbeitet durch User
Bernd O. schrieb: > Bevor Du dich entscheidest - wirf' auch mal einen Blick auf Wikipedia: > > Pascal: > https://de.wikipedia.org/wiki/Pascal_(Programmiersprache) > > Pascal ist eine Anfang der 1970-er Jahre entwickelte imperative > Programmiersprache, die heute noch in älteren Anwendungen und zur > einführenden Lehre ins Programmieren Verwendung findet. Im produktiven > Bereich wurde sie mittlerweile von Sprachen wie Java abgelöst. Oh. Habe ich die Markteinführung von JAltium-Designer verpasst ? Das war in der letzten Version noch in Delphi (aka object-pascal) geschrieben. > > Python: > https://de.wikipedia.org/wiki/Python_(Programmiersprache) > > Python ist eine universelle, üblicherweise interpretierte höhere > Programmiersprache. Ihre Entwurfsphilosophie betont Programmlesbarkeit, > außerdem ist Python-Code im Vergleich zu anderssprachigem Code teilweise > deutlich kürzer. Eine Sprache mit syntaktischen Whitespaces? Alles klar ... /regards
Mark B. schrieb: > Was ist mit Tcl/Tk? Da wird Kein native Code generiert (was TCLkit erzeugt ist zwar total witzig, aber kein native Code, der direkt das TCL Prog abbildet) /regards
Mark B. schrieb: > Vielleicht bin ich C/C++/Java/C# zu sehr gewohnt. Da JonasKl vorher QBasic genutzt hat, dürfte für ihn der Unterschied nicht so groß sein. Ich hatte am Anfang auch meine Probleme und wollte immer { } nutzen... :.) Ich nutze aktuell viel die WinPython Zusammenstellung. Diese hat einige zusätzliche Pakete und auch eine gute IDE (Spyder). Das Ganze muss nur entpackt werden und hat alles im Verzeichnis dabei.
KosmosK schrieb: > Mark B. schrieb: >> Vielleicht bin ich C/C++/Java/C# zu sehr gewohnt. > > Da JonasKl vorher QBasic genutzt hat, dürfte für ihn der Unterschied > nicht so groß sein. Das kann natürlich sein. > Ich hatte am Anfang auch meine Probleme und wollte immer { } nutzen... :.) Hehe, genau... :-}
Mark B. schrieb: > Wie, es gibt ein "richtiges" und ein "falsches" Python? Ich dachte > Python sei so super cool. Da können doch solche Probleme gar nicht > auftreten. ;-) Nein, es gibt kein "richtig" und "falsch", aber es gibt ein "End of Life und die Unterstüzung läuft aus. Deswegen sollte man gleich das aktuelle nehmen.". Nutzt ja auch (hoffe ich) keiner mehr freiwillig Visual Studio 2003. ;) Andreas H. schrieb: > Eine Sprache mit syntaktischen Whitespaces? Alles klar ... Und? Offenbar haben Firmen wie Google und deren Mitarbeiter keine Probleme damit. Ich hab damit auch keine Probleme, so wie zig tausend andere Softwareentwickler auch nicht. Magst du dein Problem vielleicht mal beschreiben? Wer natürlich der Meinung ist, dass Einrückung unnötig und nur zum Spaß da ist...
Mark B. schrieb: > Wie, es gibt ein "richtiges" und ein "falsches" Python? Ich dachte > Python sei so super cool. Da können doch solche Probleme gar nicht > auftreten. ;-) Ich hab hier eine DEC Rainbow 100(*), mit oginool Borland TurboPascal 3. Dies MUSS richtiger[TM] sein als diese diesis-programme vom Bill welche eingebautes Ablaufdatum haben. (* hey: die Kiste ist weniger leistungsfähig als ein AVRduino, kann sich ihr Pascal aber selber kompilieren!)
Mark B. schrieb: >> Da JonasKl vorher QBasic genutzt hat, dürfte für ihn der Unterschied >> nicht so groß sein. > > Das kann natürlich sein. > >> Ich hatte am Anfang auch meine Probleme und wollte immer { } nutzen... :.) > > Hehe, genau... :-} Mach dir nichts draus. Ging mir mit Python auch so. Ich bin auch so ein älteres Semester und hatte in den letzten 15 Jahren so manches ausprobiert. Letztendlich bin ich als Gelegenheitsprogger wieder an XProfan hängen geblieben. Und das nutze ich schon 20 Jahre lang. Natürlich immer das neuste Update.
Heinz B. schrieb: > bis heute > noch XProfan Heinz B. schrieb: > wieder > an XProfan hängen geblieben Er hat es geschrieben! Dafür geben ein paar Idioten Minuspunkte! Gruss Chregu
Kaj schrieb: > Magst du dein Problem vielleicht mal beschreiben? 1: Versehentliches Entfernen eines Tabs macht aus (PseudoCode) if(cond) { statement 1 statement 2 } dann if(cond) { statement 1 } statement 2 Die Auswirkungen sind evtl mehr als nur unangenehm. Diesen Fehler bekommt man auch schnell hin, wenn die Tab->' ' Funktion eines Editors benutzt wird und Dein TS sehr klein ist. 2: Wenn Du (im Rahmen Deines Projektflows) Hashes auf den Sourcecode generierst, dann musst Du jetzt auch Whitespaces berücksichtigen (die man sonst problemlos auf ein ' ' reduzieren konnte) Hat aber irgendwann mal ein Editor ' ' durch \tab ersetzt oder umgekehrt, dann stimmt der Hash nicht mehr. Willst Du wirklich noch mehr? > Wer natürlich der Meinung ist, dass Einrückung unnötig und nur zum Spaß > da ist... Ja. Wenn ich also Code fuzzifizieren MUSS dann will ich die Einrückung definitiv weg haben. Und das (falls Dir da keine Anwendung einfällt) braucht man wenn Code auf dem Kundensystem "transparent" compiliert werden muss (um die Laufzeit zu redurzieren) ohne das der Kunde trivial die benutzten Algorithmen reengineeren kann. Wird z.B. gerne bei "besseren" Digitalsimulatoren gemacht. /regards
Wenn Dir C# zu plattformabhängig ist dann nimm Java. Einfacher Syntax ähnlich C# mit umfangreichen Packages für fast alles was du brauchst. Python mit der Einrückung ist sehr gewöhnungsbedürftig und nicht so konsistent und straight forward wie Java aber natürlich ist das auch Geschmacksache.
Rufus Τ. F. schrieb: > C# aber ist eine .Net-Sprache und nicht statisch linkbar. Gut das sich .NET-Native anscheinend immer noch nicht herumgesprochen hat... https://msdn.microsoft.com/de-de/library/dn584397.aspx "During precompilation, required portions of the .NET Framework are statically linked into your app." "The .NET Native runtime is optimized for static precompilation" "Deployed: Ready-to-run binaries" > Zwar ist > mittlerweile jedes Windows mit mindestens irgendeiner .Net-Version > verseucht, aber die passende ist garantiert nicht dabei, wenn man mal > irgendeine .Net-Anwendung verwenden will. Und dann müssen wieder zig > Megabyte Kram runtergeladen und installiert werden. Weil irgendwer beim Erstellen nicht aufgepasst hat und genau Version x.y.z haben will anstatt alles, was in den absolut meisten Fällen ausreichen würde, ab Version x zuzulassen. https://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx Bei Java ist es auch fast üblich, dass ein eigenes JRE mitgeliefert wird, dass dann nie geupdatet wird... > Gut, man kann jetzt ganz viele verschiedene Versionen des .Net-Krams auf > seinem Rechner haben, aber ist das jetzt wirklich besser? Wie viele JREs, Qt-Varianten etc. pp.?
Andreas H. schrieb: > Mark B. schrieb: >> Was ist mit Tcl/Tk? > > Da wird Kein native Code generiert (was TCLkit erzeugt ist zwar total > witzig, aber kein native Code, der direkt das TCL Prog abbildet) Nur zur Anmerkung: Es wird allerdings ein Bytecode zur Laufzeit erzeugt, der dann die Interpretation auf (üblicherweise) einen Durchgang begrenzt. Von ActiveState gibt es mWn (kostenpflichtige) Software, die tatsächlich ein Kompilat auswirft. Hier laufen viele kleine Progrämmchen und GUIs für Maschinen unter Tcl/Tk und wir setzen den Tcl-Interpreter (und mittlerweile auch teilweise Tk) direkt auf STM32 (früher auch mal auf AVR) ein (unter NuttX). Das erspart einem dann ein "Monster" wie Linux und das Erstellen graphischer Oberflächen für Touchscreens wird zur reinen Freude :-) Sehr orthogonale Sprache, sehr flexibel und das gab es sogar als DOS-Ableger.
:
Bearbeitet durch Moderator
Mein Favorit ist und bleibt Watcom C / C++ / Fortran (77) Also erstmal C. Python ist C basiert.
Chris D. schrieb: > Hier laufen viele kleine Progrämmchen und GUIs für > Maschinen unter Tcl/Tk [...] Macht Dich das fehlende Typkonzept nicht alle? Strings als Feldindex sind nicht mehr witzig, wenn man eigentlich Ganzzahlen haben möchte. Und wenn der Index dann nur bis 7 läuft, weil man versehentlich doch eine Null vorangestellt hat, dann ist das nicht mehr originell. Oder gibt's da inzwischen etwas, wovon ich noch nix weiss?
Andreas H. schrieb: > Wenn ich also Code fuzzifizieren MUSS dann will ich die Einrückung > definitiv weg haben. Je nun, wat mutt, dat mutt. Gegen das Argument gibt es doch tatsächlich nichts mehr zu sagen ;) In dem Fall dann doch brainfuck. Oliver
:
Bearbeitet durch User
Chris D. schrieb: > Nur zur Anmerkung: > Es wird allerdings ein Bytecode zur Laufzeit erzeugt, der dann die > Interpretation auf (üblicherweise) einen Durchgang begrenzt. Das ist korrekt. Und TCL ist auch (für viele Anwendungen) ausreichend schnell. > > Von ActiveState gibt es mWn (kostenpflichtige) Software, die tatsächlich > ein Kompilat auswirft. Echt? Hast Du da Genaueres. Ich kenn nur die Variante die TCLkit realisiert. > > Hier laufen viele kleine Progrämmchen und GUIs für Maschinen unter > Tcl/Tk Hier auch :-) Aber insbesondere wird es bei praktisch allen relevanten ASIC Tools im Digitalbereich benutzt um Simulation, Synthese, Layout zu konfigurieren. /regards
JonasKl schrieb: >> If IDLE is started with the -n command line switch it will run in a >> single process and will not create the subprocess which runs the RPC >> Python execution server. This can be useful if Python cannot create the >> subprocess or the RPC socket interface on your platform. However, in >> this mode user code is not isolated from IDLE itself. Also, the >> environment is not restarted when Run/Run Module (F5) is selected. If >> your code has been modified, you must reload() the affected modules and >> re-import any specific items (e.g. from foo import baz) if the changes >> are to take effect. For these reasons, it is preferable to run IDLE with >> the default subprocess if at all possible." > > Ich bin sehr altes Semester. Kann jemand netterweise weiterhelfen? Was > muss man tun, um Python auch offline nutzen zu können? Prinzipiell kannst du Idle – wie im zitierten Text beschrieben – mit der Option -n starten, allerdings entstehen dadurch die genannten Nachteile. Also: - benutze Idle besser im Normalmodus, in dem das Benutzerprogramm als eigener Prozess läuft, - nimm dabei in Kauf, dass die beiden Prozesse über das lokale Loopback-Device miteinander kommunizieren (da ist überhaupt nichts Schlimmes dabei) und - überzeuge dich davon, dass Idle nicht "nach Hause" telefoniert, indem du testweise einfach den Netzwerkstecker ziehst. Dass hier zur Interprozesskommunikation das TCP-Protokoll (anstelle von Pipes, Unix-Domain-Sockets oder was es sonst noch alles gibt) benutzt wird, liegt wohl einfach daran, dass dieser Kommunikationsmechanismus auf praktisch allen Betriebssystemen verfügbar ist. Dasselbe Protokoll wird zwar auch zur Kommunikation über das Internet verwendet, bei Idle ist die Kommunikation aber wirklich zu 100% lokal. Die übetragenen Daten bleiben komplett innerhalb deines PCs. Nicht einmal deine Netzwerkkarte bekommt etwas von dieser Kommunikation mit, da das zur Kommunikation verwendete Loopback-Device kein echtes Netzwerkinterface, sondern ein reines Softwarekonstrukt innerhalb des Betriebssystems ist.
Possetitjel schrieb: > Chris D. schrieb: > >> Hier laufen viele kleine Progrämmchen und GUIs für >> Maschinen unter Tcl/Tk [...] > > Macht Dich das fehlende Typkonzept nicht alle? Nein :-} Ähem - ehrlich gesagt finde ich es sogar sehr angenehm, dort nicht eingeschränkt zu sein. > Strings als Feldindex sind nicht mehr witzig, wenn man > eigentlich Ganzzahlen haben möchte. Und wenn der Index > dann nur bis 7 läuft, weil man versehentlich doch eine > Null vorangestellt hat, dann ist das nicht mehr originell. Ist mir in der Art noch nicht passiert - aber das sollte doch eher die Ausnahme sein. Nicht vermisse ich dort allerdings Überläufe wie in C, weil mal wieder ein Variablenbereich nach ein paar Jahren dann doch nicht reichte. > Oder gibt's da inzwischen etwas, wovon ich noch nix > weiss? Zur strengen Typprüfung? Ich wüsste nicht, allerdings habe ich mich danach auch nicht explizit umgeschaut, da für mich nicht problematisch. Andreas H. schrieb: > Das ist korrekt. Und TCL ist auch (für viele Anwendungen) ausreichend > schnell. Ja - und wenn mal nicht, dann ist es sehr einfach, dort weitere Befehle in C zu implementieren. >> Von ActiveState gibt es mWn (kostenpflichtige) Software, die tatsächlich >> ein Kompilat auswirft. > > Echt? Hast Du da Genaueres. Ich kenn nur die Variante die TCLkit > realisiert. Ich hatte mir das damals mal angeschaut, die Software dann aber mangels intensiver Verwendung doch nicht gekauft. Musst einfach mal auf www.tcl.tk schauen - die Seite wird von ActiveState gehostet. >> Hier laufen viele kleine Progrämmchen und GUIs für Maschinen unter >> Tcl/Tk > Hier auch :-) > > Aber insbesondere wird es bei praktisch allen relevanten ASIC Tools im > Digitalbereich benutzt um Simulation, Synthese, Layout zu konfigurieren. Stimmt, davon hab ich gehört :-) Tcl/Tk hat eine kleine, aber emsige Fangemeinde. Insbesondere das quasi interaktiv Mögliche Bauen von Oberflächen per Shell finde ich genial. Und das ganze steht auch noch unter BSD-Lizenz. Damit erleichtert sich das Verkaufen als closed Software in Mikrocontrollersystemen sehr :-)
:
Bearbeitet durch Moderator
Mein Rat ginge auch zu Python! Extrem gut verbreitet, universell und gut unterstützt. Das wird sehr lange leben!
Thomas U. schrieb: > Mein Rat ginge auch zu Python! Extrem gut verbreitet, universell und gut > unterstützt. Das wird sehr lange leben! Mit den gleichen Argumenten könnte man freilich auch C empfehlen :)
Sonja schrieb: > das klingt mit Python ja alles in de Tat nicht schlecht (Ich selber > arbeite schon ewig mit Pascal und arbeite mich momentan in C ein) > Aber wieso wird dann doch scheinbar recht wenig damit programmiert > gerade im µc bereich liest man hier so gut wie nie was , ok Pascal > natürlich auch :-) > > Wo ist der gravierende Nachteil für Python auf µc oder generell auch für > PCs? Auf dem PC wird Python gar nicht so selten verwendet. Auf kleinen µCs ist es selten sinnvoll oder teils gar nicht möglich. Rufus Τ. F. schrieb: > Der einzige reale Fortschritt gegenüber der klassischen DLL-Hölle ist > der der Versionierung, daß also die Versionen Z, Z-1 und Z+4 > gleichzeitig vorhanden sein können, ohne sich zu stören. Ja, ist doch toll. In der Regel ist es ja eher so, dass Dinge, die auf anderen Systemen praktisch schon immer selbstverständlich sind und deren Fehlen unter Windows schon Generationen an Benutzern gestört hat, dort auch nie eingeführt werden.
Hallo Mark. Mark B. schrieb: > Wie, es gibt ein "richtiges" und ein "falsches" Python? Ich dachte > Python sei so super cool. Da können doch solche Probleme gar nicht > auftreten. ;-) In Python 3 wurden einige Inkonsistenzen, die in Python 2 noch vorhanden waren, beseitigt. Allerdings, um wirklich konsistent zu bleiben, war ein Bruch der Kompatibilität nötig. Darum der Übergang auf "3" Ich persönlich finde, das die Stringens, die Python 3 gegenüber Python 2 dadurch gewonnen hat, ein großer Vorteil ist. Gerade für mich, der nicht so intelligent ist, und große Probleme mit der Konzentration und dem Gedächnis hat, ist die starke Vereinheitlichung ein Vorteil, auch gegenüber anderen Programmiersprachen. Das ist so ähnlich, als würde ich z.B. bei der deutschen Sprache eine echte Rechtschreibreform machen, und den ganzen Kram wie unregelmäßige Verben, die Umlaute und das ß rauswerfen und durch einfachere und schlüssigere Konzepte ersetzten. Ich persönlich würde das begrüßen, und die Leute, die alle gezwungen sind, Deutsch als Fremdsprache zu lernen, vermutlich auch. Mark B. schrieb: > Thomas U. schrieb: >> Mein Rat ginge auch zu Python! Extrem gut verbreitet, universell und gut >> unterstützt. Das wird sehr lange leben! > > Mit den gleichen Argumenten könnte man freilich auch C empfehlen :) Ich habe ein Problem, die C Ausdrücke, die von geübten C Programierern verdichtet und in eine Zeile gequetscht werden, zu entwirren. Python kennt sowas nicht in der Form (obwohl es in Ansätzen auch geht), und durch die Struktur mit den Einrückungen wird für mich alles leichter erkennbar. Klar, man kann auch C offensichtlicher schreiben, aber dann schwindet auch für geübte Programmierer einer der Vorteile gegenüber Python. Genauso kann man auch Python Programme verkorksen......aber für Gelegenheitsprogramierer wie mich, die sich sowieso nicht wirklich weit von den Lehrbuchbeispielen entfernen, fehlt dann schon die Erfahrung und die Kreativität, die es zur gelungenen Verkorksung braucht. Ich bin ein Gelegenheitsprogrammierer, und C habe ich auch mal gelernt, und wenn ich mich wieder einarbeite, dauert das jeweils immer Wochen, und bei Python nur Stunden. Ich erkenne, das C unzweifelhaft seine Vorteile hat, aber für Anfänger und Gelegenheitsprogramierer ziehen die alle nicht wirklich. Übrigens werkeln in der Tiefe der Python Module oft C Programme. Python ist also durchaus auch dazu gedacht, Unterprogramme, die in anderen Programmiersprachen geschrieben sind, handlich zu verpacken und nutzbar zusammenzufügen. Als Abgrenzung gegenüber Basic: Basic ist zumindest unter Linux so gut wie nicht verbreitet. Mir ist open Source nur Gambas bekannt. Gambas ist zwar gut und bietet für den Otto Gelegenheitsprogrammierer jede Menge Module und Schnittstellen, aber Gambas ist wirklich ein Exot und eher von und für Leute geschrieben, die an VBA gewöhnt sind. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Mark B. schrieb: > Thomas U. schrieb: >> Mein Rat ginge auch zu Python! Extrem gut verbreitet, universell und gut >> unterstützt. Das wird sehr lange leben! > > Mit den gleichen Argumenten könnte man freilich auch C empfehlen :) Gut, das stimmt wohl. :) Aber warum C, C++, Java o.Ä. benutzen, solange man es nicht muss (z.B. weil man halt einen winzigen 8-bit µC mit nur ein paar hundert Byte RAM programmieren muss)? Für die Wahl der geeigneten Programmiersprache sollte doch die Faustregel gelten: So hoch wie möglich, so niedrig wie nötig. Warum also sich mit strenger Typisierung, fehlenden nützlichen Sprachfeatures oder gar Pointern etc. herumärgern und für die kleinste Aufgabe seitenweise Quellcode schreiben, wenn man die gleiche Aufgabe in Python o.Ä. in wenigen Zeilen lösen kann? Und ein gewaltiger, nicht zu unterschätzender Nachteil von Sprachen wie C,C++,Java etc. liegt imho schon darin, dass es keine interaktive Shell gibt, in die man einfach mal schnell testweise Befehle eingeben kann. Und gerade für Jemanden, der wie der Threadstarter bislang vor Allem ein Basic-Derivat genutzt hat, dürfte eine Sprache wie Python perfekt geeignet sein. Im Grunde ist Python ja geradezu das moderne Basic.
Hallo Andreas. Andreas H. schrieb: >> Magst du dein Problem vielleicht mal beschreiben? > > 1: Versehentliches Entfernen eines Tabs macht aus (PseudoCode) > > Die Auswirkungen sind evtl mehr als nur unangenehm. > Diesen Fehler bekommt man auch schnell hin, wenn die Tab->' ' Funktion > eines Editors benutzt wird und Dein TS sehr klein ist. > Hat aber irgendwann mal ein Editor ' ' durch \tab ersetzt oder > umgekehrt, dann stimmt der Hash nicht mehr. > > > Willst Du wirklich noch mehr? Vermeide halt Tabs, wenn Du mit Python arbeitest. Ansonsten sind die Probleme, die man sich mit Klammerebenen einhandeln kann, auch alles andere als trivial. Das Du gut darin trainiert bist, mit Klammerebenen statt mit Einrückungen zu jonglieren, bedeutet nicht zwangsweise, das Klammerebenen die so viel bessere Lösung sind. > Ja. Wenn ich also Code fuzzifizieren MUSS dann will ich die Einrückung > definitiv weg haben. Das ist einsichtig, aber dann bist Du natürlich auch nicht Teil der Zielgruppe von Python. ;O) > Und das (falls Dir da keine Anwendung einfällt) braucht man wenn Code > auf dem Kundensystem "transparent" compiliert werden muss (um die > Laufzeit zu redurzieren) ohne das der Kunde trivial die benutzten > Algorithmen reengineeren kann. Darum rate ich ja vielen Leuten, den Kleinkram, den sie in Auftrag geben, lieber selber zu machen. Dann sind sie weniger erpressbar. Zum Knöpfe annähen geht man ja auch nicht zum Schneider für Maßanzüge. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Kaj. Kaj schrieb: > Mark B. schrieb: > Nein, es gibt kein "richtig" und "falsch", aber es gibt ein "End of Life > und die Unterstüzung läuft aus. Deswegen sollte man gleich das aktuelle > nehmen.". Nutzt ja auch (hoffe ich) keiner mehr freiwillig Visual Studio > 2003. ;) "End of Life" wird wohl im Falle von Python 2 noch Jahrzehnte dauern. Weil viel auch in Python 2 schon geschrieben ist, und es eben viel Arbeit ist, das alles umzuschreiben. Praktisch ist die Unterscheidung zwischen Python 2 und Python 3 eher eine Art "Fork", auch wenn der Python 2 Ast gaaaanz laaaangsam Aussterben wird. "Python" ist halt open Source, und wenn sich ein paar Leute finden, die meinen, hier und da sollte trozdem mit, an und in Python 2 etwas weitergeschrieben werden, dann können und werden die das auch machen. Es existiert keine Firma, die das aus Geschäftsinteresse heraus unterbinden will und aus lizenzrechtlichen Gründen auch kann, solange Du keine Bibliotheken verwendest, die unfrei sind. Für Neueinsteiger und Neuentwicklungen empfielt sich trozdem Python 3. Die Fälle, wo keine passenden Python 3 Bibliotheken existieren, werden immer weniger. Mit freundlichen Grüßen: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Mark B. schrieb: >> Thomas U. schrieb: >>> Mein Rat ginge auch zu Python! Extrem gut verbreitet, >>> universell und gut unterstützt. Das wird sehr lange leben! >> >> Mit den gleichen Argumenten könnte man freilich auch C empfehlen :) > > Ich habe ein Problem, die C Ausdrücke, die von geübten C Programierern > verdichtet und in eine Zeile gequetscht werden, zu entwirren. Diese Probleme haben die C-Programmierer auch - wie die zahlreichen Fehler in Programmen stets auf's Neue beweisen :) C ist weniger technisch als vielmehr soziologisch interessant. Sprachen sind Mittel für soziale Gruppen, Eindringlinge fernzuhalten. Das trifft für das Rotwelsch der Gauner ebenso zu wie für das Latein der Ärzte oder die Programmiersprache C für echte Programmierer. Ein Projekt in C erfolgreich zu realisieren ist in dieser sozialen Gruppe genauso ein Initiationsritus, wie in anderen, sich die empfindlichsten Stellen der Genitalien verkrüppeln oder sich von den Kameraden demütigen zu lassen.
Bernd W. schrieb: > Das ist so ähnlich, als würde ich z.B. bei der deutschen Sprache eine > echte Rechtschreibreform machen, und den ganzen Kram wie unregelmäßige > Verben, die Umlaute und das ß rauswerfen und durch einfachere und > schlüssigere Konzepte ersetzten. Ich persönlich würde das begrüßen, und > die Leute, die alle gezwungen sind, Deutsch als Fremdsprache zu lernen, > vermutlich auch. Nun, das mit den unregelmäßigen Verben ist ein schöner Traum, wird aber niemals gelingen. Kein Mensch wird "ich seinte" sagen anstatt "ich war". Man kann den Menschen halt nicht vorschreiben, wie sie zu sprechen haben. Tatsächlich werden neu entstandene Verben in der deutschen Sprache (und auch in anderen, zum Beispiel französisch) so gut wie immer regelmäßig konjugiert: chillen - ich chillte hartzen - ich hartzte simsen - ich simste usw. ;-) > Mark B. schrieb: > Ich habe ein Problem, die C Ausdrücke, die von geübten C Programierern > verdichtet und in eine Zeile gequetscht werden, zu entwirren. > Python kennt sowas nicht in der Form (obwohl es in Ansätzen auch geht), > und durch die Struktur mit den Einrückungen wird für mich alles leichter > erkennbar. > Klar, man kann auch C offensichtlicher schreiben, aber dann schwindet > auch für geübte Programmierer einer der Vorteile gegenüber Python. Ich sehe das etwas anders. Wer möglichst viel Code in eine Zeile quetscht, ist in meinen Augen gerade kein guter Programmierer. Egal ob in C oder sonstwo.
Bernd W. schrieb: > Ansonsten sind die Probleme, die man sich mit Klammerebenen > einhandeln kann, auch alles andere als trivial. Das Du gut > darin trainiert bist, mit Klammerebenen statt mit Einrückungen > zu jonglieren, bedeutet nicht zwangsweise, das Klammerebenen > die so viel bessere Lösung sind. Das stimmt schon. Trotzdem bin ich der Meinung, dass alles, was syntaktisch eine Bedeutung hat, auch durch druckbare Zeichen repräsentiert werden sollte. Ob Blöcke nun durch "{ }" oder "begin end" gekennzeichnet werden, ist Geschmackssache. Blöcke aber anhand einer identischer Anzahl Leerzeichen zu kennzeichnen, finde ich Idiotie - tut mir leid. In jeder normalen Programmiersprache kann EIN Trennzeichen syntaktisch gleichwertig durch eine beliebig viel längere Kette von Trennzeichen ersetzt werden - nur nicht in Python. Das war vor 15 Jahren einer der wesentlichen Gründe, warum ich mich gegen Python und für Tcl entschieden habe - obwohl Tcl eigentlich eine noch exotischere Syntax hat.
Hallo Possentitjel. Possetitjel schrieb: > Sprachen sind Mittel für soziale Gruppen, Eindringlinge > fernzuhalten. Das trifft für das Rotwelsch der Gauner ebenso > zu wie für das Latein der Ärzte oder die Programmiersprache C > für echte Programmierer. Das klingt logisch. ;O) > Ein Projekt in C erfolgreich zu realisieren ist in dieser sozialen > Gruppe genauso ein Initiationsritus, wie in anderen, sich die > empfindlichsten Stellen der Genitalien verkrüppeln oder sich von > den Kameraden demütigen zu lassen. Leute, die sowas verlangten, haben bei mir schon in der Grundschule Widerwillen geweckt. Mein antisoziales Verhalten ist tief verwurzelt. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Hi Bernd, Bernd W. schrieb: > "End of Life" wird wohl im Falle von Python 2 noch Jahrzehnte dauern. > Weil viel auch in Python 2 schon geschrieben ist, und es eben viel > Arbeit ist, das alles umzuschreiben. Der Offizielle Support für Python 2 sollte schon 2015 enden, wurde aber auf 2020 verschoben. https://hg.python.org/peps/rev/76d43e52d978
1 | Update |
2 | ====== |
3 | |
4 | The End Of Life date (EOL, sunset date) for Python 2.7 has been moved |
5 | five years into the future, to 2020. This decision was made to |
6 | clarify the status of Python 2.7 and relieve worries for those users |
7 | who cannot yet migrate to Python 3. See also PEP 466. |
8 | |
9 | This declaration does not guarantee that bugfix releases will be made |
10 | on a regular basis, but it should enable volunteers who want to |
11 | contribute bugfixes for Python 2.7 and it should satisfy vendors who |
12 | still have to support Python 2 for years to come. |
13 | |
14 | There will be no Python 2.8. |
Natürlich ist Python 2 damit nicht sofort tot, aber es gibt halt keine Fixes mehr und (Sprach-)Features sowieso nicht. Das ist mMn so, als wenn man heute noch freiwillig mit Visual Studio 2003, oder Windows XP arbeitet. Ja, kann man machen, aber dann darf man auch nichts erwarten. Ich glaube auch, dass neuere PyQt Versionen auch nicht mehr zwingend mit Python 2.7 zusammen funktioniert. Kurz: Python 2 ist in der EOL-Phase. Grüße
Possetitjel schrieb: > Blöcke aber anhand einer identischer Anzahl Leerzeichen zu > kennzeichnen, finde ich Idiotie - tut mir leid. Nein. Vorausgesetzt, Du meidest Tabs wie die Pest, muss die Anzahl der vorangestellten Leerzeichen nicht identisch sein. Mindestens ein Leerzeichen mehr als in der vorherigen Zeile meint "Einrückung" und hätte dann die Bedeutung von "Klammer auf", und mindestens ein Leerzeichen weniger als in der vorherigen Zeile meint "Ausrückung"" und hätte dann die Bedeutung von "Klammer zu". Das Kriterium ist "mehr oder weniger" voraneilende Leerzeichen als in der letzten Zeile. Ich habe seit gut einem Jahr nichts mehr in Python geschrieben, aber ich ich denke mal, meine Erinnerung trügt mich nicht. Ein Algorithmus, der "mehr oder weniger" voraneilende Leerzeichen nutzt und gegen offene und geschlossene Klammer(gruppen?)n tauscht (und zurück), könnte also hilfreich für Leute sein, die die Einrückungen nicht mögen, aber mit der Klammertechnik Python Programme schreiben möchten. ;O). > In jeder normalen Programmiersprache kann EIN Trennzeichen > syntaktisch gleichwertig durch eine beliebig viel längere > Kette von Trennzeichen ersetzt werden - nur nicht in Python. Das ist eher ein Problem der Verwendung von Tabs. Die habe ich mir in Python abgewöhnt. Weil Tabs unterschiedlich lang definiert sein können, können sie beim Einfügen die Struktur durcheinanderwürfeln. Ebenso Code Stücke, die man von anderswo bezieht, und einfügen möchte, und die eine andere Anzahl von Leerzeichen für eine Einrückung verwenden. Das muss man vorher prüfen, und gegebenenfalls "Normieren". Im Gegensatz zu Tabs ist das aber offensichtlich. > Das war vor 15 Jahren einer der wesentlichen Gründe, warum > ich mich gegen Python und für Tcl entschieden habe - obwohl > Tcl eigentlich eine noch exotischere Syntax hat. Das kann ich nachvollziehen, auch wenn es für mich kein Grund wäre. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Possetitjel schrieb: > In jeder normalen Programmiersprache kann EIN Trennzeichen > syntaktisch gleichwertig durch eine beliebig viel längere > Kette von Trennzeichen ersetzt werden Das ist in Python doch auch so. Nur halt nicht am Zeilenanfang ;-) > - nur nicht in Python. oder in Haskell. oder in CoffeeScript. oder in Makefiles. oder in ABC, Boo, BuddyScript, Cobra, Converge, Curry, Elixir, Elm, F#, Genie, Gaml, ISWIM, LiveScript, Make, Miranda, Nemerle, Nim, occam, PROMAL, Sass Spin, XL, YAML... https://en.wikipedia.org/wiki/Off-side_rule
Possetitjel schrieb: > Sprachen sind Mittel für soziale Gruppen, Eindringlinge > fernzuhalten. Das trifft für das Rotwelsch der Gauner ebenso > zu wie für das Latein der Ärzte oder die Programmiersprache C > für echte Programmierer. Nicht wirklich. Latein wird in der Ätzteschaft verwendet, weil die Begriffe aus einer Zeit wissenschaftlichen Zusammenarbeits kommen, in der Latein DIE Sprache der Biologen war. Zudem ist es ein Vorteil, da so alle Ärzte der Welt die Diagnosen und Krankheiten verstehen. Man kann also seine Diagnosen mit ins Ausland nehmen und der dortige Ärzt weiss aufrund einiger Schlagworte, was Du hast.
S. K. schrieb: > Possetitjel schrieb: >> Sprachen sind Mittel für soziale Gruppen, Eindringlinge >> fernzuhalten. Das trifft für das Rotwelsch der Gauner ebenso >> zu wie für das Latein der Ärzte oder die Programmiersprache C >> für echte Programmierer. > > Nicht wirklich. Doch. > Latein wird in der Ätzteschaft verwendet, weil die Begriffe > aus einer Zeit wissenschaftlichen Zusammenarbeits kommen, in > der Latein DIE Sprache der Biologen war. Zudem ist es ein > Vorteil, da so alle Ärzte der Welt die Diagnosen und Krankheiten > verstehen. Man kann also seine Diagnosen mit ins Ausland nehmen > und der dortige Ärzt weiss aufrund einiger Schlagworte, was Du > hast. Das stimmt alles, was Du schreibst - aber es ist nur ein Teil der Wahrheit. Zum anderen Teil dieser Wahrheit gehört, dass Mediziner keineswegs immer und überall die soziale Reputation hatten, die sie heute haben. Zahnärzte gab's nicht; schmerzende Zähne hat der Barbier herausgerissen. Chirurgen gab's nicht; Blasen- steine haben fahrende Steinschneider herausoperiert (!). Der heutige "Götter in Weiss"-Mythos ist vor diesem sozialen und historischen Hintergrund zu sehen; das ist eine Art Kompensationsreaktion.
"Ich habe mir Python vielleicht 5 Stunden lang angesehen und bin immer noch nicht begeistert" so scheint es zu sein..also begeistert bin ich jetzt nicht davon, wie gesagt es ist ganz witzig, aber wenn es um runterladen installieren starten geht ist Lazarus einfach perfekt. Vielleicht schaue ich mir Python mal weiter für die Desktopprogrammierung an, da das aber so gut wie nie vorkommt werde ich wohl bei Pascal bzw C bleiben für die µC Warum wurde dieser beitrag gelöscht?!?! Hackt es oder was?!?!!
Joachim S. schrieb: > Possetitjel schrieb: > >> In jeder normalen Programmiersprache kann EIN Trennzeichen >> syntaktisch gleichwertig durch eine beliebig viel längere >> Kette von Trennzeichen ersetzt werden > > Das ist in Python doch auch so. Klar. Und alle Primzahlen sind ungerade. > Nur halt nicht am Zeilenanfang ;-) Eine Ausnahme ist genau eine Ausnahme zuviel. Programmierung ist kompliziert genug - da muss ich mir nicht mit solchen Inkonsistenzen die Arbeit noch schwerer machen lassen.
Bernd W. schrieb: > Possetitjel schrieb: > >> Blöcke aber anhand einer identischer Anzahl Leerzeichen zu >> kennzeichnen, finde ich Idiotie - tut mir leid. > > Nein. [...] Das Kriterium ist "mehr oder weniger" voraneilende > Leerzeichen als in der letzten Zeile. Okay, das wusste ich nicht. > Ein Algorithmus, der "mehr oder weniger" voraneilende Leerzeichen > nutzt und gegen offene und geschlossene Klammer(gruppen?)n tauscht > (und zurück), könnte also hilfreich für Leute sein, die die > Einrückungen nicht mögen, aber mit der Klammertechnik Python > Programme schreiben möchten. ;O). Etwas in dieser Art habe ich im Ernst schon erwogen -- z.B. auch für Pascal/C und zurück. Viele Grundkonstrukte sind ohnehin identisch, und C-spezifischen Krankheiten (" *(++p)-- ") will man sowieso nicht verwenden. Bernd W. schrieb: >> In jeder normalen Programmiersprache kann EIN Trennzeichen >> syntaktisch gleichwertig durch eine beliebig viel längere >> Kette von Trennzeichen ersetzt werden - nur nicht in Python. > > Das ist eher ein Problem der Verwendung von Tabs. Ja, klar -- aber da Tabulatoren und Leerzeichen optisch nicht unbedingt unterscheidbar sind, erwarte ich, dass sie auch keinen funktionalen Unterschied hervorrufen.
Hallo Svenja. Svenja schrieb im Beitrag #4744200: > Ihr habt echt einen an der Pfanne! Das bekomme ich öfter zu hören. Ich kann allerdings nichts daran ändern. Wie im allgemeinen fast alle Leute, "die echt einen an der Pfanne haben". Von daher ist Dein Hinweis leider nutzlos. Aber unten ist ein Link, wie Du Deinen Browser so einstellen kannst, dass ich ausgeblendet werde. Möge es für Deinen Frieden sorgen. Beitrag "User ausblenden" Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Possetitjel. Possetitjel schrieb: >> Nein. [...] Das Kriterium ist "mehr oder weniger" voraneilende >> Leerzeichen als in der letzten Zeile. > > Okay, das wusste ich nicht. Ich bin mir zwar nicht hundertprozentig, aber trotzdem sehr sicher, das es so ist. Im Zweifelsfalle lässt sich das ja ausprobieren. Als ich irgendwann zu Python 2.3 / 2.4 Zeiten angefangen habe, war es noch nicht so, und irgendwann in den letzten drei Jahren bin ich mal darüber gestolpert, dass es bei Python 3.irgendwas mittlerweile so ist (war?). Ich hatte in dusseligem Kopf tatsächlich Python Code mit einem Leerzeichen einrückung (wie ich es privat handhabe) mit Code mit vier Leerzeichen für eine Einrückung (wie es offiziell sein sollte), den ich irgendwo copiert hatte, gemischt und auch noch geändert. Das Programm funktionierte, aber der untere Abschluss war nicht am linken Rand, was eigentlich ein Zeichen für Kuddelmuddel mit den Ebenen ist. Da ich neugierig bin und es mit "funktionieren" nicht in jedem falle auf sich beruhen lasse, vor allem wenn es mich wundert, dass es funktioniert, hatte ich herumexperimentiert, und obiges herausgefunden. Dann habe ich mich zurückgelehnt und überlegt, und es schien mir als Kriterium für eine Ebene auch ausreichend. Publiziert gesehen habe ich es nie, und es könnte auch sein, das es ein Bug ist, weil ich mir vorstellen könnte, dass es ein Problem sein könnte, Anfängern diese "Freiheit" zu vermitteln. Also eigentlich der Idee von Python in gewissem Sinne zuwiederlaufend (aber im anderen Sinne auch entsprechend (siehe ducktyping)). Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Possetitjel schrieb: > Programmierung ist kompliziert genug - da muss ich mir nicht > mit solchen Inkonsistenzen die Arbeit noch schwerer machen > lassen. Grundsätzlich verstehe ich eine gewisse Abneigung ja, ich fand das am Anfang auch ungewohnt bis unsympathisch. Aber "Arbeit noch schwerer machen"? Das kann ich nicht ganz nachvollziehen. Denn im Grunde macht man bei den Einrückungen doch genau das gleiche, was man auch in jeder anderen Programmiersprache macht, nämlich Code-Blöcke einzurücken. Nur, dass man es bei Python nicht rein aus Konvention und Lesbarkeit macht, und es dem Vorteil daher kommt, dass man dadurch auf die ganzen unnötigen geschweiften Klammern verzichten kann, die die Lesbarkeit verringern und mehr Tipparbeit machen. > Ja, klar -- aber da Tabulatoren und Leerzeichen optisch nicht > unbedingt unterscheidbar sind, erwarte ich, dass sie auch > keinen funktionalen Unterschied hervorrufen. So etwas gibt es bei C, Java etc. streng genommen aber doch auch: Ersetze doch mal in einem C-Programm die Leerzeichen durch einen "Non-break space" (Unicode-Zeichen U+00A0). Dieses Zeichen ist optisch üblicherweise nicht von einem Leerzeichen zu unterscheiden, kann aber trotzdem nicht statt des Leerzeichens benutzt werden.
Was wann wo erlaubt ist, ob Tabs oder Leerzeichen, Einrückungstiefe, usw. kann man im "PEP 8 -- Style Guide for Python Code" nachlesen: https://www.python.org/dev/peps/pep-0008/ Eine Liste aller PEPs gibt es hier: https://www.python.org/dev/peps/ Zen of Python: https://www.python.org/dev/peps/pep-0020/#id3
1 | The Zen of Python |
2 | |
3 | Beautiful is better than ugly. |
4 | Explicit is better than implicit. |
5 | Simple is better than complex. |
6 | Complex is better than complicated. |
7 | Flat is better than nested. |
8 | Sparse is better than dense. |
9 | Readability counts. |
10 | Special cases aren't special enough to break the rules. |
11 | Although practicality beats purity. |
12 | Errors should never pass silently. |
13 | Unless explicitly silenced. |
14 | In the face of ambiguity, refuse the temptation to guess. |
15 | There should be one-- and preferably only one --obvious way to do it. |
16 | Although that way may not be obvious at first unless you're Dutch. |
17 | Now is better than never. |
18 | Although never is often better than *right* now. |
19 | If the implementation is hard to explain, it's a bad idea. |
20 | If the implementation is easy to explain, it may be a good idea. |
21 | Namespaces are one honking great idea -- let's do more of those! |
Leute, lasst doch bitte die Diskussion über die Einrückungen in Python aus diesem Thread heraus. Diese Diskussion fand bisher in praktisch jedem Thread statt, wo der Name "Python" auch nur am Rande erwähnt wurde, und so gut wie nie wurden wirklich neue Argumente dafür oder dagegen hervorgebracht. Manche Leute haben Probleme mit den Einrückungen, andere nicht. Das ist eben so und muss – so wie es aussieht – wohl jeder für sich selber herausfinden. Falls ihr zu dem Thema wirklich neue Erkenntnisse habt, die noch kein Mensch ausgesprochen oder aufgeschrieben hat, dann erweckt meinetwegen diesen alten Thread wieder zum Leben: Beitrag "Einrückung in Python" (bitte vorher durchlesen, ob der Gedanke nicht doch schon gepostet wurde) Aber stopft nicht diesen Thread hier damit zu!
Joachim S. schrieb: > Aber "Arbeit noch schwerer machen"? Das kann ich nicht ganz > nachvollziehen. > Denn im Grunde macht man bei den Einrückungen doch genau das gleiche, > was man auch in jeder anderen Programmiersprache macht, nämlich > Code-Blöcke einzurücken. > Nur, dass man es bei Python nicht rein aus Konvention und Lesbarkeit > macht, und es dem Vorteil daher kommt, dass man dadurch auf die ganzen > unnötigen geschweiften Klammern verzichten kann, die die Lesbarkeit > verringern und mehr Tipparbeit machen. Was für mich da vor allem der Vorteil ist: Mit Klammern habe ich die Informationen redundant, wobei der Mensch eher die Einrückung sieht, der Compiler sich aber ausschließlich nach den Klammern richtet. Wenn da mit den Klammern was durcheinander ist und die Einrückungsebene nicht dazu passt, sieht man den Fehler nicht so leicht. In Python gibt's die Klammern und damit die Redundanz und das Potenzial für Inkonsitenzen nicht. Der Intepreter und der Benutzer gehen beide ausschließlich nach der Einrückung. Deshalb finde ich die Idee eigentlich nicht so blöd.
Rufus Τ. F. schrieb: > Na, das, an was Du da gerade denkst. Weil das ja viel besser, viel > kompatibler und viel überlegener ist. > > Die Praxis beweist, daß das, wie so viele tolle Ideen von Microsoft, > halt nicht wirklich zutrifft. Aber das ist das grundlegende Problem von > "shared libraries". > > Tool X kann nicht verwendet werden, weil Library Y nicht in Version Z > vorhanden ist. > > Der einzige reale Fortschritt gegenüber der klassischen DLL-Hölle ist > der der Versionierung, daß also die Versionen Z, Z-1 und Z+4 > gleichzeitig vorhanden sein können, ohne sich zu stören. Es ist so wie Du schreibst. Der .Net Kram ist nicht wirklich fortschrittlich. Ich muß derzeit damit hantieren, weil mein AG das will. Es gibt zwar ein paar nette Features in C#, aber man hat es wieder mal nicht konsequent gemacht und so ist es wieder nur ein klassisches C im neuen Mäntelchen geworden. Zudem ist das Ganze noch deutlich langsamer als jede native Exe - egal mit welchem Compiler diese erzeugt wurde. Zeno
Yalu X. schrieb: > Leute, lasst doch bitte die Diskussion über die > Einrückungen in Python aus diesem Thread heraus. Bei allem Respekt: Bitte überdenke die Berechtigung dieser Zurechtweisung. Das sage ich nicht obwohl - sondern WEIL Du Moderator bist und also die Macht hast, meine Beträge zu löschen. > Diese Diskussion fand bisher in praktisch jedem Thread > statt, wo der Name "Python" auch nur am Rande erwähnt > wurde, und so gut wie nie wurden wirklich neue Argumente > dafür oder dagegen hervorgebracht. Das kannst Du nicht beurteilen. Auch wenn die Argumente FÜR DICH nicht neu waren, können sie es doch für den einen oder anderen Diskussionsteilnehmer gewesen sein. So wie für mich zum Beispiel. > Falls ihr zu dem Thema wirklich neue Erkenntnisse habt, > die noch kein Mensch ausgesprochen oder aufgeschrieben > hat, DAS ist das Kriterium für µC.net? Ernsthaft?
Possetitjel schrieb: > Auch wenn die Argumente FÜR DICH nicht neu waren, können sie es doch > für den einen oder anderen Diskussionsteilnehmer gewesen sein. > > So wie für mich zum Beispiel. Dann betrachte den von mir verlinkten Thread als tolle Möglichkeit, eine große Anzahl weiterer Argumente kennenzulernen, die vielleicht ebenso neu für dich sind.
Yalu X. schrieb: > Possetitjel schrieb: >> Auch wenn die Argumente FÜR DICH nicht neu waren, können >> sie es doch für den einen oder anderen Diskussionsteilnehmer >> gewesen sein. >> >> So wie für mich zum Beispiel. > > Dann betrachte den von mir verlinkten Thread als tolle > Möglichkeit, eine große Anzahl weiterer Argumente > kennenzulernen, die vielleicht ebenso neu für dich sind. Weisst Du, eigentlich möchte ich mich nur ungestört mit Bernd und Joachim über das Thema "Programmiersprachenempfehlung" unterhalten.
Chris D. schrieb: > Possetitjel schrieb: >> Chris D. schrieb: >> >>> Hier laufen viele kleine Progrämmchen und GUIs für >>> Maschinen unter Tcl/Tk [...] >> >> Macht Dich das fehlende Typkonzept nicht alle? > > Nein :-} Ähem - ehrlich gesagt finde ich es sogar sehr angenehm, dort > nicht eingeschränkt zu sein. Es schränkt ein bzw. es ist das eingeschränkteste Typsystem von allen, da es nur genau einen Typ gibt. Wo in anderen Sprachen der Compiler gemütlich testen kann, ob etwas passt, muss dass in diesen Sprachen der Mensch, fehleranfälliger und zeitraubender. An jeder Stelle, für jede noch so triviale Kleinigkeit. Ausführlicher: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ >> Strings als Feldindex sind nicht mehr witzig, wenn man >> eigentlich Ganzzahlen haben möchte. Und wenn der Index >> dann nur bis 7 läuft, weil man versehentlich doch eine >> Null vorangestellt hat, dann ist das nicht mehr originell. > > Ist mir in der Art noch nicht passiert - aber das sollte doch eher die > Ausnahme sein. Nicht vermisse ich dort allerdings Überläufe wie in C, > weil mal wieder ein Variablenbereich nach ein paar Jahren dann doch > nicht reichte. Da verhalten sich C und andere Sprachen, zumindest teilweise, wie wohldefinierte mathematische Objekte... > Stimmt, davon hab ich gehört :-) > Tcl/Tk hat eine kleine, aber emsige Fangemeinde. > Insbesondere das quasi interaktiv Mögliche Bauen von Oberflächen per > Shell finde ich genial. ASICs? Chisel (auch wenn ich Scala an sich nicht ab kann, als DSL ist der Ableger Chisel nicht schlecht) https://chisel.eecs.berkeley.edu/ https://riscv.org/
JonasKl schrieb: > hin und wieder schreibe ich mal ein kleines Programm für irgendwelche > Berechnungen in Quickbasic. > Auf Dauer wäre eine modernere Programmiersprache angebracht. Nach dem Durchlesen aller Beiträge würde ich an Deiner Stelle wohl bei Quickbasic bleiben.
Python mag auf den ersten Blick simpel erscheinen. Wenn man dann allerdings etwas tiefer in die Materie eintaucht, wird man bemerken, dass Python mitnichten simpel ist. Die Performance hingegen ist, wenn man Benchmark Game ( http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html ) glauben schenken darf katastrophal. Vorteil ist aber der Kommandozeileninterpreter und die Tatsache, dass man Programme nicht kompilieren muss vor dem Ausführen (kann man aber). Der Vorteil von "Sprachen" wie Ruby oder Python ist, dass sie sehr ausdrucksstark sind - also mit möglichst wenig Code kann man viel Funktionalität erreichen. Das geht natürlich auch zur Lasten der Performance. Desweiteren würde ich nicht darauf wetten, dass dieser Code dann notwendigerweise einfacher zu verstehen/warten ist, als Code in anderen Programmiersprachen. Und sicherer ist es auch nicht automatisch. Gut, es gibt keine Memory Leaks oder Buffer Overflows, aber es gibt ja auch noch andere Fehlertypen...
Arc N. schrieb: >> Nein :-} Ähem - ehrlich gesagt finde ich es sogar sehr angenehm, dort >> nicht eingeschränkt zu sein. > > Es schränkt ein bzw. es ist das eingeschränkteste Typsystem von allen, > da es nur genau einen Typ gibt. Wo in anderen Sprachen der Compiler > gemütlich testen kann, ob etwas passt, muss dass in diesen Sprachen der > Mensch, fehleranfälliger und zeitraubender. An jeder Stelle, für jede > noch so triviale Kleinigkeit. > Ausführlicher: > https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ Ich verstehe die Argumente durchaus - aber ich teile sie nicht. Mir war die Freiheit in dem Bereich immer wichtiger als die zusätzliche Last. Ich schrieb ja: ich hatte bisher deutlich mehr Probleme mit überlaufenden Dingen in C als mit fehlender Typprüfung, und das, obwohl ich viel mehr in Tcl schreibe als in C. Vielleicht ist auch die eigene Vergangenheit ein Knackpunkt: ich habe Tcl quasi zusammen mit C gelernt. Ich denke, wenn man lange nur C und andere Sprachen mit strengen Typprüfung kannte, dann ist es eventuell schwieriger, das im Hinterkopf zu behalten. Ist vielleicht eine Gewohnheitssache.
Bernd W. schrieb: > Vermeide halt Tabs, wenn Du mit Python arbeitest. Und wie stelle ich sicher, dass niemand aus dem Team einen Editor benutzt, der Tab<->Space replacement macht? Nein. Ich denke es ist sicherer nicht TABs sondern Python zu vermeiden. > Ansonsten sind die Probleme, die man sich mit Klammerebenen einhandeln > kann, auch alles andere als trivial. Das Du gut darin trainiert bist, > mit Klammerebenen statt mit Einrückungen zu jonglieren, bedeutet nicht > zwangsweise, das Klammerebenen die so viel bessere Lösung sind. Naja, eine versehentlich gelöschte Klammer meckert der Compiler an. Ein versehentlich gelöschtes Whitespace auch? > >> Ja. Wenn ich also Code fuzzifizieren MUSS dann will ich die Einrückung >> definitiv weg haben. > > Das ist einsichtig, aber dann bist Du natürlich auch nicht Teil der > Zielgruppe von Python. ;O) Wäre ich da sowieso nicht weil das nur bei Code sinnvoll ist, der "echt" compiliert wird. Ausserdem ist das nicht meine "Baustelle". Ich habe diese Methode bloss schon öfter gesehen. Viele Grüße Andreas
Andreas H. schrieb: > Nein. Ich denke es ist sicherer nicht TABs sondern Python zu vermeiden. Na ja, Python wird weltweit von hunderttausenden Programmierern genutzt. Auch wenn du dir das nicht vorstellen kannst, scheint es doch möglich zu sein, praktikable Lösungen für die von dir als unüberwindbar angesehenen Problemchen zu finden. Oliver
Arc N. schrieb: >> Stimmt, davon hab ich gehört :-) >> Tcl/Tk hat eine kleine, aber emsige Fangemeinde. >> Insbesondere das quasi interaktiv Mögliche Bauen von Oberflächen per >> Shell finde ich genial. > > ASICs? Chisel (auch wenn ich Scala an sich nicht ab kann, als DSL ist > der Ableger Chisel nicht schlecht) > https://chisel.eecs.berkeley.edu/ > https://riscv.org/ Du verwechselst da die Beschreibungsebene mit der Tool control language (Kein Mensch würde auf die Idee kommen einen Digitalteil in TCL zu beschreiben). Afaik unterstützt keine übliche Toolchain chisel. /regards
Oliver S. schrieb: > Na ja, Python wird weltweit von hunderttausenden Programmierern genutzt. Das ist doch unbestritten. Ich habe selber schon einem Azubi mal Programmieren über Python beigebracht. > Auch wenn du dir das nicht vorstellen kannst, scheint es doch möglich zu > sein, praktikable Lösungen für die von dir als unüberwindbar angesehenen > Problemchen zu finden. Das habe ich auch nie bestritten. Aber nur weil es Bereiche gibt, wo die "Eigenarten" von Python akzeptabel sind, heisst das noch lange nicht, dass das für alle Anwendungsbereiche gilt. Die (SW-)Welt besteht nicht nur aus WEB-/Game-/Office-Anwendungen. /regards
Für jedes Problem gibt es ein geeignetes Werkzeug. Wer weiter auf seine eierlegende Wollmilchsau pocht (mangels Tellerrandblick oder weil er schlicht nix anders kennt) wird auch in 10 Jahren noch hier oder in ähnlichen Threads missionieren.
Andreas H. schrieb: > Aber nur weil es Bereiche gibt, wo die "Eigenarten" von Python > akzeptabel sind, heisst das noch lange nicht, dass das für alle > Anwendungsbereiche gilt. Vielleicht mal zur Erinnerung, um was es hier überhaupt geht: JonasKl schrieb: > hin und wieder schreibe ich mal ein kleines Programm für irgendwelche > Berechnungen in Quickbasic. > Auf Dauer wäre eine modernere Programmiersprache angebracht. Es ist mal wieder nicht die Frage nach dem Leben, dem Universum und dem ganzen Rest, wobei die Antwort darauf ja auch schon bekannt ist. Der TO will einfach nur ab und an alleine mal eben schnell was hinprogrammieren, und dafür ist Python mehr als nur gut geeignet. Oliver
Andreas H. schrieb: > Bernd W. schrieb: >> Vermeide halt Tabs, wenn Du mit Python arbeitest. > > Und wie stelle ich sicher, dass niemand aus dem Team einen Editor > benutzt, der Tab<->Space replacement macht? Wenn er das eincheckt und in seinem Commit sämtliche Files komplett geändert sind, haust du ihm auf die Finger und sagst ihm, er soll das wieder "reverten". Übrigens werden bei besseren Editoren Tabs markiert, oder man kann das zumindest so einstellen. Somit sieht man es dann gleich, wenn irgendwo ein Tab ist. > Nein. Ich denke es ist sicherer nicht TABs sondern Python zu vermeiden. Auch eine Meinung... genausogut könnte man C, C++, Java u.s.w. vermeiden, weil man da immer so umständlich mit AltGr die Klammern setzen muss. >> Ansonsten sind die Probleme, die man sich mit Klammerebenen einhandeln >> kann, auch alles andere als trivial. Das Du gut darin trainiert bist, >> mit Klammerebenen statt mit Einrückungen zu jonglieren, bedeutet nicht >> zwangsweise, das Klammerebenen die so viel bessere Lösung sind. > > Naja, eine versehentlich gelöschte Klammer meckert der Compiler an. Meiner Erfahrung nach tut er das oft nicht, da er weiterparst und erst irgendwann später mal nicht mehr weiter weiß. Da meckert er dann. Eine vergessene Klammer irgendwo in einem Header kann im Extremfall auch mal zu einem Fehler in einem ganz anderen Header führen, weil der erst danach inkludiert wurde. >>> Ja. Wenn ich also Code fuzzifizieren MUSS dann will ich die Einrückung >>> definitiv weg haben. >> >> Das ist einsichtig, aber dann bist Du natürlich auch nicht Teil der >> Zielgruppe von Python. ;O) > > Wäre ich da sowieso nicht weil das nur bei Code sinnvoll ist, der "echt" > compiliert wird. Er kann in einen Byte-Code übersetzt werden. Aus dem läßt sich allerdings abgesehen von Kommentaren der ursprüngliche Code komplett wiederherstellen. Früher gab's sogar mal ein Tool, das das automatisiert gemacht hat, allerdings ist das inzwischen ziemlich veraltet. Ohne das ist der Aufwand hoch. > Ausserdem ist das nicht meine "Baustelle". Ich habe diese Methode bloss > schon öfter gesehen. Ich halte solche Obfuscater für ziemlichen Unsinn. Entweder man gibt seinen Source-Code raus oder nicht.
Rolf Magnus schrieb: > Ich halte solche Obfuscater für ziemlichen Unsinn. Entweder man gibt > seinen Source-Code raus oder nicht. Da hast Du prinzipiell recht. Aber wenn es um zur Laufzeit generierten Srccode geht dann wird das schwierig, weil es DEN Srccode nicht gibt und der Hersteller sicher nicht sein ganzes Produkt im Sourcecode liefern will (denn da steckt ja sein KnowHow drin). /regards
Oliver S. schrieb: > Der TO will einfach nur ab und an alleine mal eben schnell was > hinprogrammieren, und dafür ist Python mehr als nur gut geeignet. Du weisst doch gar nicht WAS er ab und zu mal schnell hinprogrammieren will. Und Le X. bringt es hier doch auf den Punkt: Le X. schrieb: > Wer weiter auf seine eierlegende Wollmilchsau pocht (mangels > Tellerrandblick oder weil er schlicht nix anders kennt) wird auch in 10 > Jahren noch hier oder in ähnlichen Threads missionieren. Inzwischen haben wir aber sowohl Vor- als auch Nachteile von Python hinreichend diskutiert, so dass er sich selber ein besseres Bild machen kann. Denn er wird doch am ehesten wissen was er mag/brauct oder eben nicht. /regards
P.S: Rolf Magnus schrieb: > Eine > vergessene Klammer irgendwo in einem Header kann im Extremfall auch mal > zu einem Fehler in einem ganz anderen Header führen, weil der erst > danach inkludiert wurde. Aber es führt zu einem Compile-Time Error, nicht zu einer falschen Ausführung des Programms. /regards
Oliver S. schrieb: > Der TO will einfach nur ab und an alleine mal eben schnell was > hinprogrammieren, und dafür ist Python mehr als nur gut geeignet. Jein: Wenn er nicht regelmäßig programmiert, wird er in eine neue Programmiersprache wohl auch nicht ausreichend "reinkommen". Egal ob das nun Python ist oder eine andere.
Andreas H. schrieb: > Oliver S. schrieb: >> Der TO will einfach nur ab und an alleine mal eben schnell was >> hinprogrammieren, und dafür ist Python mehr als nur gut geeignet. > > Du weisst doch gar nicht WAS er ab und zu mal schnell hinprogrammieren > will. Ach je, bist du wirklich so begriffsstutzig, oder tust du nur so? Ein paar Berechnungen, und etwas GUI, als QBasic-Ersatz. Steht wörtlich oben. Und selbst wenn das jetzt nicht allumfassend die Anfoderungen sind, und es auch nicht in alle Ewigkeit so bleiben werden, braucht das alles keine Detailanalysen, und auch keine 15 verschieden, ans jeweilige Problem angepasste Programmiersprachen. Oliver
Wenn du von BASIC kommst: VB.NET: * ist ein "MS-Standard" * kostenlose abgepeckte IDE, reicht für Kleinkram * massig Doku, Sourcen, Hilfe wenns klemmt RealBasic Ich sehe gerade das heisst jetzt xojo und bewegt sich auch zusätzlich in Richtung Netzanwendungen. * Ist kommerziell aber läuft auf allen Platformen: Win+Linux+Mac. Zielplatform angeben kompilieren, fertig. Kein Gefrickel mit Libs und Runtimes notwendig. ich fand das nicht schlecht. Wohl der komfortabelste Weg um alle wichtigen Platformen zu bedienen ohne grosse Anpassungen zu machen. Coolterm ist eine Anwendung die z.B. mit Realbasic geschrieben wurde, kannste ja mal anschauen. Python: * ecklige Sprache: Whitespace als Syntaxelement -> behindert² Probleme mit OO, macht sich aber erst in grossen Projekten bemerkbar. Nur zu handeln wenn man sich penibelst an gewisse Styleguides hält. * Versionschaos. Der Weg von 2.x nach 3.x ist immer noch nicht richtig abgeschlossen. Manche alten Libs funktionieren noch nicht mit der neuen 3er obwhol die schon ewig draussen ist. Ist ein Problem vieler Scriptsprachen im OS Umfeld. Perl und Tk oder Gtk ist auch so ein Krampf. Nutzt man noch eine weitere Schicht bei Tk wie Tixx wirds noch übler. Wenn man Glück hat läufts out of the box wenn nicht, musst du gewissen Libs nachinstallieren, evt. selber kompilieren. ActiveState macht da einen guten Job aber irgendwann trifft man immer auf eine dreckige Stelle die noch stinkt. Ich würde dir in deinem Fall zu einem BASIC-Dialekt oben raten, da sparst du viel Zeit und Ärger.
Oliver S. schrieb: > Ach je, bist du wirklich so begriffsstutzig, oder tust du nur so? > > Ein paar Berechnungen, und etwas GUI, als QBasic-Ersatz. Steht wörtlich > oben. Ein Kollege hat mal "ein paar Berechnungen" am WE zuhause gemacht. Er wollte wissen, wie sich das Wärmeverhalten seines (damals) aktuellen ASICs aussieht. Als er es später auf Arbeit gecheckt hat (mit Ansys?) war er auch ziemlich nah dran. FEM für den Hausgebrauch^^ Manche machen auch mal "ein paar Berechnungen" zur Leiterplattenoptimierung. Bist Du sicher das Deine Vorstellung von "ein paar Berechnungen" nicht vielleicht etwas naiv ist? /regards
Mark B. schrieb: > Oliver S. schrieb: >> Der TO will einfach nur ab und an alleine mal eben schnell was >> hinprogrammieren, und dafür ist Python mehr als nur gut geeignet. > > Jein: > Wenn er nicht regelmäßig programmiert, wird er in eine neue > Programmiersprache wohl auch nicht ausreichend "reinkommen". > > Egal ob das nun Python ist oder eine andere. Ich kenne viele, die eigentlich was anderes machen und nur nebenher hin und wieder für kleine Aufgaben ein Progrämmchen schreiben. Laut deiner obigen Aussage ist das aber gar nicht möglich, da sie die jeweilige Sprache nicht ausreichend gelernt haben können. Wie machen die das dann? Magie? Andreas H. schrieb: > P.S: > > Rolf Magnus schrieb: >> Eine >> vergessene Klammer irgendwo in einem Header kann im Extremfall auch mal >> zu einem Fehler in einem ganz anderen Header führen, weil der erst >> danach inkludiert wurde. > > Aber es führt zu einem Compile-Time Error, nicht zu einer falschen > Ausführung des Programms. Wäre nicht das erste mal, wenn einer meint, er hätte die Stelle, wo die Klammer fehlt, gefunden und sie dann aber an der falschen Stelle einfügt, weil die Einrückung nicht zu den Klammern passt. Und schwupps, geht's durch den Compiler, macht aber auch das falsche. Das passiert da - wie in Python - aber hauptäschlich dann, wenn kein konsistenter Style verwendet wird und jeder seinen Editor anders eingestellt hat. Ist also eher ein organisatorisches Problem als eins der Sprache. Pimmelschimmel schrieb: > Python: > * ecklige Sprache: Whitespace als Syntaxelement -> behindert² Sehr einleuchtendes Argument... Ich kann ja nachvollziehen, wenn der eine das als Vorteil, der andere eher als Nachteil sieht, aber warum das manche so abgrundtief hassen, nur weil es anders ist als sie gewöhnt sind, will mir nicht einleuchten. > Probleme mit OO, macht sich aber erst in grossen Projekten bemerkbar. Nun sind die vom TE angesprochenen Dinge keine großen Projekte. > * Versionschaos. Das ist bei Microsoft mit seinen Dutzenden von verschiedenen .net-Frameworks und Visual-Studio-Runtimes nicht anders. Wenn nicht jedes Programm das immer alles in genau der Version, die es braucht, mitliefert, kannst du davon ausgehen, dass du mindestens für jedes zweite Programm die passende Version irgendwo suchen musst.
Andreas H. schrieb: > Bist Du sicher das Deine Vorstellung von "ein paar Berechnungen" nicht > vielleicht etwas naiv ist? JonasKl schrieb: > Quickbasic Ganz sicher. Oliver P.S. Wer aus Langeweile nachmittags FEM-Programme bastelt, fragt erst gar nicht, womit. Der weiß das, und bleibt bei seinem geliebten FORTRAN
Rolf Magnus schrieb: >> Aber es führt zu einem Compile-Time Error, nicht zu einer falschen >> Ausführung des Programms. > > Wäre nicht das erste mal, wenn einer meint, er hätte die Stelle, wo die > Klammer fehlt, gefunden und sie dann aber an der falschen Stelle > einfügt, weil die Einrückung nicht zu den Klammern passt. Ja, leider auch wahr. Aber es ist zumindest erst mal ein Hinweis dass etwas nicht stimmt. Richtig machen sollte man es dann schon ;-) Oliver S. schrieb: > P.S. Wer aus Langeweile nachmittags FEM-Programme bastelt, fragt erst > gar nicht, womit. Der weiß das, und bleibt bei seinem geliebten FORTRAN Dann war dem Kollegen anscheinend nicht langweilig. Er hatte es iirc in C geschrieben. /regards
Da der TO aus der BASIC Ecke kommt und "nur" kleine Programme erstellt, kann dieser sich auch mal FreeBASIC anschauen :) Da gibt es auch GUIs zum zusammenklicken (Persönlich bin ich ebenfalls dem Python Fieber verfallen <3 )
Blubb schrieb: > Da der TO aus der BASIC Ecke kommt und "nur" kleine Programme erstellt, > kann dieser sich auch mal FreeBASIC anschauen :) Da gibt es auch GUIs > zum zusammenklicken Sieht ja auf den ersten Blick richtig nett aus. Vielleicht genau das, was der TO gesucht hat. /regards
Kaj schrieb: > Natürlich ist Python 2 damit nicht sofort tot, aber es gibt halt keine > Fixes mehr Wo steht das? Ich denke da steht das genaue Gegenteil: Bugfixes werden immer noch angenommen, mindestens bis 2020.
Bernd K. schrieb: > mindestens bis 2020 Wenn du denn zitierten Beitrag nochmal in Ruhe durchliest, wirst du merken, dass das genau so da steht
Andreas H. schrieb: >> Eine >> vergessene Klammer irgendwo in einem Header kann im Extremfall auch mal >> zu einem Fehler in einem ganz anderen Header führen, weil der erst >> danach inkludiert wurde. > > Aber es führt zu einem Compile-Time Error, nicht zu einer falschen > Ausführung des Programms. Bei Python führt es ebenfalls zu einem Compiletime Error.
Blubb schrieb: > Wenn du denn zitierten Beitrag nochmal in Ruhe durchliest, wirst du > merken, dass das genau so da steht Ähm nein. Der Poster hat fälschlicherweise behauptet daß es für 2.7 in Zukunft keine Bugfixes mehr gäbe. Und das obwohl er selbst noch eigenhändig die Ankündigung zitiert hat in der das völlig anders drinsteht. Lies nochmal was ich schrieb und worauf ich mich bezog, am besten diesmal etwas langsamer lesen.
Kaj schrieb: > Der Offizielle Support für Python 2 sollte schon 2015 enden, wurde aber > auf 2020 verschoben. [...] > Natürlich ist Python 2 damit nicht sofort tot, > aber es gibt [ab 2020] halt keine > Fixes mehr und (Sprach-)Features sowieso nicht. Doch, ich denke, dass das genauso gemeint war. Die [ab 2020]-Klammer habe ich ergänzt. Aber okay, der TO wird (egal wie was gemeint war) nun mitbekommen haben, dass er, wenn er python lernt, klug sein und direkt python3 lernen sollte.
Blubb schrieb: > Kaj schrieb: >> Der Offizielle Support für Python 2 sollte schon 2015 enden, wurde aber >> auf 2020 verschoben. [...] >> Natürlich ist Python 2 damit nicht sofort tot, >> aber es gibt [ab 2020] halt keine >> Fixes mehr und (Sprach-)Features sowieso nicht. > > Doch, ich denke, dass das genauso gemeint war. > Die [ab 2020]-Klammer habe ich ergänzt. Genauso war es gemeint :)
Blubb schrieb: >> aber es gibt halt keine >> Fixes mehr und (Sprach-)Features sowieso nicht. vs. >> aber es gibt [ab 2020] halt keine >> Fixes mehr und (Sprach-)Features sowieso nicht. > Doch, ich denke, dass das genauso gemeint war. > Die [ab 2020]-Klammer habe ich ergänzt. Ja, das mach ich auch immer so wenn ich Unsinn geschrieben habe, ich fälsche kurzerhand ein Zitat und füge genau die Worte ein die ich zuvor nur geträumt habe, solange bis es so klingt als ob ich Recht und der andere Unrecht hätte.
Bernd K. schrieb: > Ja, das mach ich auch immer so wenn ich Unsinn geschrieben habe, ich > fälsche kurzerhand ein Zitat und füge genau die Worte ein die ich zuvor > nur geträumt habe, solange bis es so klingt als ob ich Recht und der > andere Unrecht hätte. 1. Habe ich direkt darauf hingewiesen 2. Ist dies ein Zitierstil 3. Wollte ich dir deutlich machen, dass der Satz nach dem Zitat einen Bezug auf den Satz vor dem Zitat von Kaj hatte -.- Ist ja auch egal jetzt ... Wisch dir die Tränen weg und genieße den Abend :) Es gab ja eine Auflösung und alle wissen nun Bescheid. Danke Bernd! Der TO weiß nun aber wirklich, dass python2.7 "erst" 2020 stirbt und kann nun dank der vorhandenen Sicherheit der Bugfixes getrost für 3,x Jahre python2.7 lernen+nutzen. Ab 2020 kann er eine Umgewöhnung starten. Lernen bzw Weiterbilden soll ja auch gut für's Köpfchen sein. Supi :)
Danke für die Info zur Firewall! Habe noch eine Frage zu Python3: a = 15.1 b = 16.1 c = a + b print (c) wird so ausgegeben: 31.200000000000003 Woran liegt es, dass nicht 31.2 ausgegeben wird? a = 15.1 b = 16.2 c = a + b print (c) führt zu 31.299999999999997 a = 15.1 b = 16.3 c = a + b print (c) führt zu 31.4
JonasKl schrieb: > Woran liegt es, dass nicht 31.2 ausgegeben wird? 1. Daß binäre Gleitkommazahlen nicht ohne Rungungsfehler in dezimale umgerechnet werden können und umgekehrt. 2. Dass Du bei der Ausgabe nicht sinnvoll rundest.
Danke! Der Andere schrieb: > 2. Dass Du bei der Ausgabe nicht sinnvoll rundest. So weit bin ich noch nicht.
Der Andere schrieb: > 1. Daß binäre Gleitkommazahlen nicht ohne Rungungsfehler in dezimale > umgerechnet werden können und umgekehrt. Das Problem hat auch Google: https://www.google.ch/search?q=9999999999+-+9999999997&ie=utf-8&oe=utf-8&gws_rd=cr&ei=tn33V-_3DIOuU6TkgsgL#q=999999999999999+-+999999999999997
Nochmal zur Info: Das mit den Rundungsfehler ist kein Pronblem von Phyton, das hast du bei allen Sprachen, sobald Gleitkommazahlen benutzt werden. Bei der Anzeige ist das nicht so schlimm, viel fieser wird das wenn du z.B. vergleichst d = a + b - c; if (d == 0) ... geht dann ziemlich sicher schief. Man muss statt dessen auf ein entsprechend kleine Differenz prüfen. Siehe dazu: https://de.wikipedia.org/wiki/Gleitkommazahl#Pr.C3.BCfung_auf_Gleichheit
Der Python Weg zur formatierten Ausgabe wäre
1 | print("{0:3.2f}".format(c)) |
2 | #oder z.B. mit mehreren Parametern
|
3 | print("a={0:3.2f} , b={1:3.2f}, c={2:3.2f}".format(a,b,c)) |
Siehe http://www.python-kurs.eu/python3_formatierte_ausgabe.php
Daniel A. schrieb: > Der Andere schrieb: >> 1. Daß binäre Gleitkommazahlen nicht ohne Rungungsfehler in dezimale >> umgerechnet werden können und umgekehrt. > > Das Problem hat auch Google: > https://www.google.ch/search?q=9999999999+-+9999999997&ie=utf-8&oe=utf-8&gws_rd=cr&ei=tn33V-_3DIOuU6TkgsgL#q=999999999999999+-+999999999999997 In Deinem Beispiel geht es aber um ganze Zahlen. Wie soll da ein Rundungsfehler auftreten? Es sein denn vielleicht man wandelt sie zum Rechnen in Gleitkommazahlen um. Das wäre dann nicht besonders clever programmiert.
:
Bearbeitet durch User
@Mark Brandis Mit der ganzzahl wird intern als float gerechnet. Ze grösser die Zahlen, desto grösser der fehler.
Danke für die Antworten! Warum funktioniert das denn bei Quickbasic automatisch, wird dort anders mit Gleitkommazahlen verfahren?
Daniel A. schrieb: > @Mark Brandis > > Mit der ganzzahl wird intern als float gerechnet. Schlechtes Software-Design.
@Mark Brandis Bei JavaScript wird ab >2^31 automatisch intern auf float umgestellt.
64 Bit sind für die meisten Berechnungen ausreichend und da kann dann auf float, double verzichtet werden.
Daniel A. schrieb: > @Mark Brandis > > Bei JavaScript wird ab >2^31 automatisch intern auf float umgestellt. Frickelsprache ;-)
JonasKl schrieb: > Danke für die Antworten! Warum funktioniert das denn bei Quickbasic Quickbasic ist einfach besser! Oder sieh Dir an, wie die formatierte Ausgabe funktioniert.
JonasKl schrieb: > Warum funktioniert das denn bei Quickbasic automatisch, wird dort > anders mit Gleitkommazahlen verfahren? Da ich kein Quickbasic habe, verwende ich in den folgenden Beispielen stellvertretend dafür Lua, da dieses sich bzgl. der Ausgabe von Float- Zahlen ähnlich verhält. Gerechnet wird in Python, Quickbasic und Lua Sprachen gleich, da die Addition in allen Fällen von der FPU ausgeführt wird. Da sowohl 15.1 als auch 16.1 im verwendeten Binärformat nur näherungsweise dargestellt werden kann, entstehen hier die ersten beiden Fehler. Auch die Addition der beiden Werte ist leicht ungenau, so dass das berechnete Ergebnis am Ende nicht exakt 31.2, sondern 31.2000000000000028421709430404007434844970703125 oder in Hexdarstellung 0x1.f333333333334p+4 ist. In der Hexdarstellung erkennt man, dass das Ergebnis eigentlich 0x1.f33333333333333333333333333333333333...p+4 lauten sollte. Da die Mantisse einer Double-Zahl aber nur 52 Bit breit ist (ohne die führende 1), wird die Zahl gerundet. Zusammen mit den Rundungsfehlern der beiden Operanden und der Addition ist das Ergebnis am Ende ein ganz klein wenig zu groß. Bis hierher gibt es noch keinen Unterschied zwischen Python, Quickbasic und Lua. Der Unterschied liegt vielmehr in der Rundung bei der Ausgabe des Ergebnisses. Python:
1 | >>> 10/7 # Test mit einer "krummen" Zahl |
2 | 1.4285714285714286 # gerundet wird auf 17 Stellen |
3 | >>> a=15.1 |
4 | >>> b=16.1 |
5 | >>> c=a+b |
6 | >>> c |
7 | 31.200000000000003 # bei 17 Stellen ist der Fehler sichtbar |
8 | >>> c==31.200000000000003 # Konstante kopiert von der Zeile darüber |
9 | True # Variable stimmt mit dem angezeigten Wert |
10 | # überein |
Lua:
1 | > 10/7 -- Test mit einer "krummen" Zahl |
2 | 1.4285714285714 -- gerundet wird auf 14 Stellen |
3 | > a=15.1 |
4 | > b=16.1 |
5 | > c=a+b |
6 | > c |
7 | 31.2 -- bei 14 Stellen wird der Fehler kaschiert |
8 | > c==31.2 -- Konstante kopiert von der Zeile darüber |
9 | false -- Variable unterscheidet sich vom |
10 | -- angezeigten Wert |
Wie man sieht, verfolgen die beiden Sprachen bei der Ausgabe von FLoat-Zahlen verschiedene Strategien: Lua (und auch Quickbasic) runden die Ergebnisse so großzügig, dass kleinere Rundungsfehler nicht auffallen (sie sind aber trotzdem existent). Python hingegen gibt so viele Stellen aus, dass die angezeigte Zahl, wenn man sie erneut eingibt, immer exakt mit der in der Variable gespeicherten Zahl übereinstimmt. Wenn man also bspw. Zahlen im Textformat in eine Datei speichern möchte, um sie später wieder einzulesen, ist in Python garantiert, dass exakt die gleiche Zahl gelesen wird, die zuvor gespeichert wurde. In Lua ist dies i.Allg. nicht der Fall. In Lua wird die unformatierte Ausgabe von Zahlen i.Allg. nicht durch eventuelle Rundungsfehler verunstaltet. In Python muss man, wenn man dies verhindern möchte, die Ausgabe durch eine Formatangabe auf eine passende Anzahl von Stellen runden.
Yalu X. schrieb: >>>> 10/7 # Test mit einer "krummen" Zahl > 1.4285714285714286 # gerundet wird auf 17 Stellen Oh das wusst ich gar nicht. Liefert die Division in Python 3 jetzt endlich auch für Integerargumente ein Fließkommaergebnis so wie es sich gehört, wurde also dieser unsinnige nervtötende Overload mit der Integerdivision endlich entfernt? Das sind ja mal gute Nachrichten.
Bernd K. schrieb: > Oh das wusst ich gar nicht. Liefert die Division in Python 3 jetzt > endlich auch für Integerargumente ein Fließkommaergebnis so wie es sich > gehört Jepp, wurde laut PEP 238 -- Changing the Division Operator am 11.März 2001 für beschlossen.
Bernd K. schrieb: > Yalu X. schrieb: >>>>> 10/7 # Test mit einer "krummen" Zahl >> 1.4285714285714286 # gerundet wird auf 17 Stellen > > Oh das wusst ich gar nicht. Liefert die Division in Python 3 jetzt > endlich auch für Integerargumente ein Fließkommaergebnis so wie es sich > gehört, Ob sich das so gehört, ist Ansichtssache. Ich find's etwas inkonsistent, dass bei allen Berechnungen mit int auch als Ergebnis int rauskommt, außer bei der Division. Da ist es dann plötzlich float. Wenn man nen int will, muss man stattdessen // nehmen, wobei int // int einen int ergibt, float // float aber einen float mit abgeschnittenen Nachkommastellen. Finde ich alles nicht unbedingt so elegant.
KosmosK schrieb: > Jepp, wurde laut PEP 238 -- Changing the Division Operator > am 11.März 2001 für beschlossen. ymmd! :D
KosmosK schrieb: > Bernd K. schrieb: >> Oh das wusst ich gar nicht. Liefert die Division in Python 3 jetzt >> endlich auch für Integerargumente ein Fließkommaergebnis so wie es sich >> gehört > > Jepp, wurde laut PEP 238 -- Changing the Division Operator > am 11.März 2001 für beschlossen. Das ist gut. Ich denke ich könnte dann vielleicht doch mal mittelfristig ins Auge fassen erneut über einen Umstieg von 2.7 auf 3.x vorsichtig nachzudenken. Das will alles wohlüberlegt sein, nichts überstürzen.
Rolf Magnus schrieb: > Ich find's etwas inkonsistent, dass bei allen Berechnungen mit int > auch als Ergebnis int rauskommt, außer bei der Division. Auch beim Potenzoperator (**) kann mit Int-Operanden ein Float herauskommen. Beispiel: 2**2 = 4 (int) 2**(-2) = 0.25 (float) Da ist der Ergebnistyp nicht nur von den Operandentypen verschieden, sondern hängt auch noch von den konkreten Werten der Operandentypen ab. Dass für die gewöhnliche und die ganzzahlige Division zwei verschiedene Operatoren vorgesehen werden, ist – mathematisch gesehen – schon ganz sinnvoll: Die gewöhnliche Division ist die Multiplikation mit dem inversen Element in einem Körper (bspw. (ℚ,+,·) oder (ℝ,+,·)). Die ganzen Zahlen bilden bzgl. der Addition und Multiplikation keinen Körper (sondern nur einen Ring), weil das inverse Element der Multiplikation fehlt. Folglich kann hier auch keine Division definiert werden. Für die gewöhnliche Division gilt die Beziehung (a / b) · b = a für die ganzzahlige Division i.Allg. nicht. Es sprechen aber insbesondere auch die in PEP 238 genannten praktischen Gründe dafür, den Divisionsoperator (/) nur für die gewöhnliche Division (also mit gebrochenem Ergebnis) zu verwenden und für die ganzzahlige Division einen neuen Operator (//) zu definieren. Wenn es dich stört, dass bei der Division das Ergebnis einen anderen Typ als die Operanden hat, musst du dir Haskell anschauen ;-) Dort gibt es die gewöhnliche Division (/) ausschließlich für Fractional- Typen (bspw. Rational, Double und Float) und die ganzzahlige Division (div und quot) ausschließlich für Integral-Typen (bspw. Integer, Int und Word). Die beiden Operanden und das Ergebnis sind dabei immer vom selben Typ. In Haskell ist auch das Typendurcheinander bei der Potenzoperation sauber gelöst, indem nicht nur ein, sondern gleich 3 Operatoren dafür definiert sind (^, ^^ und **).
Ich verstehe ehrlich gesagt auch dieses C-Unding nicht, wie man drauf kommt, binäre Operationen mit ^ & ~ | << >> auszudrücken. Die Syntax hat sich leider durchgesetzt und ist mittlerweile in fast allen beliebten Programmiersprachen (Java, JavaScript, C#, Python, Go, etc.) genauso zu finden, aber der Sinn erschliesst sich mir nicht.
Tasg schrieb: > Ich verstehe ehrlich gesagt auch dieses C-Unding nicht, wie man drauf > kommt, binäre Operationen mit ^ & ~ | << >> auszudrücken. Was ist daran auszusetzen? C hat doch beileibe größere Schwachpunkte als ausgerechnet die Schreibweise dieser paar harmlosen Operatoren.
Yalu X. schrieb: > Rolf Magnus schrieb: >> Ich find's etwas inkonsistent, dass bei allen Berechnungen mit int >> auch als Ergebnis int rauskommt, außer bei der Division. > > Auch beim Potenzoperator (**) kann mit Int-Operanden ein Float > herauskommen. Aha, also ist ** der Potenzoperator, aber // nicht der Wuzeloperator (was ich jetzt intuitiv erwartet hätte). > Für die gewöhnliche Division gilt die Beziehung > > (a / b) · b = a > > für die ganzzahlige Division i.Allg. nicht. Für float aber auch nicht immer. Es muss gerundet werden. Das ist dann auch nicht viel anders als mit int, nur dass es sich dort meistens stärker auswirkt. > Es sprechen aber insbesondere auch die in PEP 238 genannten praktischen > Gründe dafür, den Divisionsoperator (/) nur für die gewöhnliche Division > (also mit gebrochenem Ergebnis) zu verwenden und für die ganzzahlige > Division einen neuen Operator (//) zu definieren. Gut, ist eben eine andere Herangehensweise. In C sagt man, dass eine Berechnung, wo alle Operanden vom Typ int sind, auch wieder int als Ergebnistyp hat. Das ist von den Regeln her einfacher als "immer int, außer bei Division und Potenzen, da ist es stattdessen float, und bei Potenzen aber auch nur dann, wenn ...". Solche Ausnahmen stellen für mich immer gewissermaßen eine Überraschung dar, weil da das Verhalten von der Regel abweicht. Und Überraschungen sind in Programmiersprachen und APIs immer zu vermeiden. Freilich ist mir aber klar, dass andere evtl. überrascht sind, wenn 1/2 == 0. > Wenn es dich stört, dass bei der Division das Ergebnis einen anderen Typ > als die Operanden hat, musst du dir Haskell anschauen ;-) > > Dort gibt es die gewöhnliche Division (/) ausschließlich für Fractional- > Typen (bspw. Rational, Double und Float) und die ganzzahlige Division > (div und quot) ausschließlich für Integral-Typen (bspw. Integer, Int und > Word). Die beiden Operanden und das Ergebnis sind dabei immer vom selben > Typ. Gut, das ist dann wieder eine andere Herangehensweise. Wobei mir das dann wiederum nach exzessiver Definition von Operatoren klingt. Tasg schrieb: > Ich verstehe ehrlich gesagt auch dieses C-Unding nicht, wie man drauf > kommt, binäre Operationen mit ^ & ~ | << >> auszudrücken. Warum nicht? Dann ist es wie bei den aus der Mathematik geläufigen Operatoren auch. Man würde ja auch niht erwarten, dass man "3 plus 5" schreiben muss. Übrigens gibt's in C auch im Standard-Header <iso646.h> für diese Operatoren (abgesehen von den Shifts) auch Namen aus Buchstaben. Statt ^ wäre das dann xor, statt & bitand, statt ~ compl und statt | bitor. In C++ ist man sogar noch weiter gegangen und hat diese Namen als echte Schlüsselwörter in die Sprache eingebaut. Allerdings nutzt sie keiner, weil sie überflüssig wie ein Kropf sind.
:
Bearbeitet durch User
Rolf M. schrieb: >> Für die gewöhnliche Division gilt die Beziehung >> >> (a / b) · b = a >> >> für die ganzzahlige Division i.Allg. nicht. > > Für float aber auch nicht immer. Es muss gerundet werden. Das ist dann > auch nicht viel anders als mit int, nur dass es sich dort meistens > stärker auswirkt. Yalu X. hat sich da wohl auf die mathematische Definition bezogen, nicht auf das was in der Informatik daraus "gebastelt" wird. Mathematisch ist iirc Dein Float eigentlich ein Restklassenring. Für reelle Zahlen gilt seine Aussage schon. (Natürlich nur für b /= 0. 0 hat ja kein inverses Element und "/ b" ist ja nicht weiter als "syntactic sugar" für die Multiplikation mit dem inversen Element von b.) /regards
Andreas H. schrieb: > Yalu X. hat sich da wohl auf die mathematische Definition bezogen, nicht > auf das was in der Informatik daraus "gebastelt" wird. > Mathematisch ist iirc Dein Float eigentlich ein Restklassenring. > Für reelle Zahlen gilt seine Aussage schon. Das ist mir schon klar, aber wir sprechen ja davon, wie es in Python umgesetzt ist. Dass es in der Theorie schon einen Sinn ergibt, bringt mir ja nix, wenn das in der Praxis nicht passt. Die Datentypen in der Informatik haben nun mal eine endliche Auflösung.
Rolf M. schrieb: > Aha, also ist ** der Potenzoperator, aber // nicht der Wuzeloperator > (was ich jetzt intuitiv erwartet hätte). Wieso? Potenzen sind wiederholte Multiplikationen (deswegen ein doppeltes * als Symbol), aber Wurzeln keine wiederholten Divisionen. >> Für die gewöhnliche Division gilt die Beziehung >> >> (a / b) · b = a >> >> für die ganzzahlige Division i.Allg. nicht. > > Für float aber auch nicht immer. Es muss gerundet werden. Das ist dann > auch nicht viel anders als mit int, nur dass es sich dort meistens > stärker auswirkt. Es gibt schon einen Unterschied: Bei der Float-Division ist der (sehr kleine) Rundungsfehler ein unerwünschter Randeffekt, der normalerweise ignoriert wird. In den seltenen Fällen, wo der Fehler trotzdem stört (weil man das Ergebnis auf mehr als 15 Dezimalstellen genau braucht), verwendet man meist eine Arithmetikbibliothek für höhere Genauigkeit, mit der der Fehler erneut ignoriert werden kann. Bei der Integer-Division hingegen wird das Abrunden des Ergebnisses meist nicht als Fehler angesehen, sondern als Feature bewusst genutzt. Es ist natürlich klar, dass auf einem realen Computer die FLoat- Arithmetik nicht dem mathematischen Ideal der Arithmetik mit reellen Zahlen entspricht, ebenso wenig, wie bspw. der Computer dem Ideal einer Turing-Maschine entspricht. Trotzdem ist es für Design-Entscheidung oft sinnvoll, von idealisierten Modellen auszugehen, auch wenn diese nicht exakt der Realität entsprechen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.