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!
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.
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.
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.
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.
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.
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
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
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.
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?
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. 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
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.
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.
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 XProfanHeinz 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.
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
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 :-)
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
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
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.
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.
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.
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
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:> 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.
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 abschalten