Moin zusammen,
ich habe zurzeit ein Problem, das ich recht gut in Programmierschritte
zerteilen kann und von dem ich auch eine ungefähre Vorstellung habe, wie
es in Code zu gießen wäre.
In Bascom könnte ich das selbständig umsetzen.
Nun möchte ich aber dieses Problem nicht mit einem Mikrocontroller und
einem LCD, sondern als richtiges Programm lösen. Da fängt mein Problem
an.
Konkret geht es um die Entwicklung eines kleinen Programms für die
technische Redaktion (vorerst nur für mich selbst gedacht), das aus
verschiedenen Eingabeparametern die Mindestanforderungen an die
Dokumentation für Elektronikprodukte ausgibt (was muss formal vorhanden
sein, Inhalt ist eine andere Baustelle).
Parameter können sein
a) anzuwendende Richtlinien
(sind bekannt, Mehrfachauswahl)
b) Produktgruppe
(sind bekannt, genau eine Auswahl aus vorgegebenen Möglichkeiten)
c) Platzierung des CE-Zeichens
(falls mindestens eine Richtlinie anzuwenden ist, Mehrfachauswahl -
mindestens jedoch eine)
d) Platzierung des WEEE-Zeichens
(falls die WEEE-Richtlinie anzuwenden ist, Mehrfachauswahl - mindestens
jedoch eine)
Aus diesen vier Parametern ergeben sich die Anforderungen. Ich würde mir
gern eine kleine GUI basteln, die "nichts weiter" machen soll als die
Ergebnisse der Auswahl in Variablen einzutragen. Diese Variablen sollen
danach mit ifs verwurstet werden und ein Ergebnis in eine Textbox o.ä.
ausgeben.
Eine kurze Recherche ergab, dass Python einfach zu erlernen wäre und
recht bekannt ist. Python kann offenbar objektorientiert oder auch nicht
objektorientiert eingesetzt werden. Da ich OOP nicht leiden kann (bisher
nur auf die Schnauze geflogen damit), würde ich gerne weiterhin ohne
auskommen.
Welche Werkzeuge benötige ich, womit muss ich anfangen?
- GUI
- Variablen händeln (evtl. Array, geht aber auch mit Variablen)
- Bedingungen (if, Schleife etc.)
Ist ActivePython mit Eclipse geeignet oder doch was anderes? Kann jemand
ein Tutorial empfehlen?
Vielen Dank!
Häuptling Rauchender Kopf schrieb:> Python kann offenbar objektorientiert oder auch nicht> objektorientiert eingesetzt werden.
Python verwendet wie die meisten anderen Sprachen auch OOP. Wirklich
ganz ohne OOP zu programmieren ist bei den verbreiteten Sprachen gar
nicht so einfach, außer bei C. Ist es wirklich so schlimm
1
file.write(...)
statt
1
write(file, ...)
zu schreiben? Ich würde diese Einschränkung noch einmal überdenken und
vielleicht überlegen, warum du mit OOP "auf die Schnauze" geflogen bist
und ob du es vielleicht einfach nur nicht richtig verstanden hast.
Ich habe früher jahrelang in Fortran (nicht am PC), Microsoft-Basic und
Assembler programmiert, bis ich vor ca 10 Jahren auf Linux umgestiegen
bin, seitdem mache ich (fast) alles in Python. Leicht zu lernen, die
Programme sind sehr übersichtlich, plattformübergreifend. Schau Dich mal
bei
http://www.python-kurs.eu/http://www.python-forum.de/
und und mache ein paar Versuche, ich könnte mir gut vorstellen, dass Du
schnell drin bist.
peg
Ich habe hier schon mal geschrieben, nachdem ich ein paar kleine
hardwarenahe Progrämmchen auf dem Raspbery hinbekommen habe:
Ich halte Python für das BASIC des 21. Jahrhunderts, man kann das ganze
objektorientierte Geschwafel geflissentlich ignorieren und damit
gewöhnliche herkömmliche böse imperialistische Programme schreiben.
Also keinen falschen Respekt davor haben.
"Head first Python" in der zweiten Auflage ist sehr gut geschrieben. Der
Objektorientierte Ansatz kommt auch im letzten Drittel, es wird aber
nicht darauf herumgeritten.
Häuptling Rauchender Kopf schrieb:> Da ich OOP nicht leiden kann
Wenn du nur ein Script schreibst, was in der Konsole läuft, dann geht es
auch fast ohne OOP oder du merkst es nicht.
Bei der GUI z.B. mit Tcl/Tk kommst du um OOP nicht drumrum. Dein
Eingabefeld ist dann ein Objekt, mit dem du interagieren kannst.
Gui programmierung ist ans system gebunden (win/linux) deshalb habe ich
leider auch nur oop gefunden oder durch game engines .net sprachen.
mit JS und canvas kann man grafisch was machen und mit w3school lernen.
ich glaube die genauichkeit beim rechen ist da nicht so toll, es kann
man googlen, da gibts probleme
sonst sind die bibliotheken und frameworks eher mit viel arbeit
verbunden sich da einzuarbeiten, man könnte sfml davon die c variante
probieren cfml , aber die doku ist nur für c++
es gibt noch eine alte gui programmier möglichkeit freebasic, auf der
seite sind viele IDE's ein chat tuts und beispiele auf deutsch. man muss
transparente bilder (PNG) erst durch ein script einbinden.
so richtig einfache komplette 2d game engines fallen mir keine ein, den
die meisten sind etwas unpraktisch zum programmieren, da sie an
einsteiger gerichtet sind und eher mit klicken oder blueprints
funktionieren.
Phyton ist halt wegen dem interpreter etwas ungewöhnlich ist bei linux
meist vorinstalliert aber bei windows???
vielleicht geht auch einfach was eigenes per openGL und C da muss man
aber matrizen rechenen
Kritical R. schrieb:> vielleicht geht auch einfach was eigenes per openGL und C da muss man> aber matrizen rechenen
Ich denke das ist doch sehr übertrieben da mit openGL drauf loszugehen.
Es geht hier doch nur um Textboxeb und Buttons.
Python bringt in der Standardinstallation tkinter mit. Das ist ein GUI
Framework, das auf Windows und Linux läuft. Außerdem gibt es dazu
Beispiele wie man da einfach Buttons und Textfelder kombiniert.
Kritical R. schrieb:> Phyton ist halt wegen dem interpreter etwas ungewöhnlich ist bei linux> meist vorinstalliert aber bei windows???
Es gibt Tools, mit denen lässt sich ein Pythonprogramm in eine exe
packen, sodass man auf dem Zielrechner kein Python installieren muss.
Häuptling Rauchender Kopf schrieb:> Eine kurze Recherche ergab, dass Python einfach zu erlernen wäre und> recht bekannt ist. Python kann offenbar objektorientiert oder auch nicht> objektorientiert eingesetzt werden. Da ich OOP nicht leiden kann (bisher> nur auf die Schnauze geflogen damit), würde ich gerne weiterhin ohne> auskommen.>> Welche Werkzeuge benötige ich, womit muss ich anfangen?> - GUI> - Variablen händeln (evtl. Array, geht aber auch mit Variablen)> - Bedingungen (if, Schleife etc.)
Ja Python ist ziemlich Anfänger geeignet. Ich bin sicher wenn man
Programmieren kann, kommt man in Python ziemlich schnell rein. Sicher
gibt es auch den einen oder anderen syntactic sugar aber denn muss man
nicht kennen. Das Buch "automate the boring stuff with python" wurde mir
von vielen als guter Start empfohlen, ich selbst habe es allerdings noch
nicht gelesen, Mir selbst hat das Buch "Learning Python: Powerful
Object-Oriented Programming" geholfen in die Sprache rein zu kommen.
Generell empfehle ich dir gleich mit Python3 Anzufangen, Python2 soll
2020 in den Status EOL gehen, das Pferd Humpelt also schon.
Was dein Konkretes Vorhaben angeht. Wenn es Wirklich GUI sein soll dann
sind die Tkinter Bindings schon beim cPython mit dabei und daher eine
gute Wahl um schnell los zu legen. Schöner finde ich aber das Look&Feel
von QT.
Wenn es noch etwas ganz anders sein darf, kann ich mir Dein Problem auch
gut als Webapplikation vorstellen, dann Könntest du mit den Python Flask
oder Django Framework dein Programm entwickeln und der Benutzer kann es
mit einen Handelsüblichen Browser steuern.
@Häuptling
welches OS? Wenn WIN ...
Für so einfache Sachen incl. GUI und mit Fähigkeiten Richtung Basic
würde ich AutoIT empfehlen. Da hat man so was ruck zuck fertig und eine
EXE kann man auch draus machen.
Sascha
Dein Problem kann man gut im Browser mit JavaScript, HTML und CSS lösen,
optional kann man auch ein Webframework verwenden.
Damit bist du wesentlich flexibler und schneller am Ziel.
wenn Du vom Basic kommt wieso dann nicht Lazarus Pascal?
Da kannst Du alles mit amchen und das wichtigste die Prgrammierumgebung
ist der Hammer und put of the Box, runerladen
starten..Programmeiren..keine Progamme zusammensuchen keine Fumellei mit
Eisntellung udn Pfaden etc pp
https://www.lazarus-ide.org
Damit kannst Du mit oer ohne OOP Schreiben, unter Win Linux Amiga OS etc
pp
Und ganz nebenbei wird die Portierung für STM32 immer weiter entwickelt,
so das Du später auch auf µC damit weiter arbeiten kannst
P.S. und keine Nerverei wegen irgendwelcher Lizenzen. Lazarus /
Freepascal erlaubt problemlos kommerzielle Nutzung jeder Art, die
bedingunen hierfür sind ein Witz, ich meine es war nur, das irgendwo in
der Hilfe oder so stehen sollte das es mit Freepsacal geschrieben
wurde..und bin mir nicht mal sicher ob das zwingend war.
Der Totalcommander ist in Lazarus geschrieben z.B.
Hallo,
ich kann dir auch nur Python ans Herz legen. Allerdings solltest du
deine unbegründete angst vor Objektorientierung überwinden. Datentypen
wir Listen und Dictionaries sind schon Objekte. Sehr einfach zu
verwenden und sehr mächtig.
Mein aktueller Favorit bezüglich Entwicklungsumgebung ist eine virtuelle
Python Umgebung die ich mit miniconda erstelle, für code prototyping
benutze ich JupyterLab und später PyCharm fürs refactoring um Klassen
und Module zu bauen.
Pthon hat ein sehr einfaches GUI interface namens tkinter was sehr
leicht zu verwenden ist und hier wahrscheinlich ausreicht. Alternativ
gibt es das mächtige QT. Ich benutze zur Zeit Kivy, was ich allerdings
einem Anfänger und OOP verweigerer nicht ans Herz legen würde.
Anstelle der GUI parameter auswahl kannst du auch ein einfaches JSON
oder INI file schreiben und das mit einem fertigen Parser auslesen. So
hast du auch gleich eine Referenz mit welchen parametern dein Programm
gelaufen ist wenn du das file mit den ausgaben archivierst.
Python ist ein sehr mächtiges Werkzeug dank der vielen Bibliotheken. Es
kann nicht schaden es zu lernen ;-)
Hallo Blabla.
Blabla schrieb:> Pthon hat ein sehr einfaches GUI interface namens tkinter was sehr> leicht zu verwenden ist und hier wahrscheinlich ausreicht.
Richtig. Und tkinter hat den Vorteil, das es so Plattformübergreifend so
gut wie überall läuft. Es gehört zum Standardpacket von Python, und bis
auf wenige Ausnahmen ist tkinter immer mit dabei, wenn man Python
installiert.
Egal ob Linux, Windows oder Mac, Python/tkinter läuft.
Um mit Fenstern und Buttons herumzumachen ist es wohl in 95% aller Fälle
ausreichend.
Siehe im Anhang Buttontest5.zip. Darin ist buttontest.py, ein Python3
Skript und ein GIF enthalten. Es werden damit ein paar Möglichkeiten
gezeigt, was man mit Python/tkinter und Buttons machen kann.
buttontest5.py und P600-Dioden2.gif sollten dabei immer im gleichen
Ordner sein.
Obwohl tkinter z.b. keine Transparenz kennt, lässt sich Transparenz
damit per "stipple" faken.
Die Grenzen von tkinter werden erst bei sehr Grafiklastigen Anwendungen,
wie zum Beispiel einem Gerberviewer erreicht.
(Negativ Beispiel:
https://www.mikrocontroller.net/wikifiles/5/5a/PyGerberAnalyse_B5_13Jun2013.zip
)
> Alternativ> gibt es das mächtige QT. Ich benutze zur Zeit Kivy, was ich allerdings> einem Anfänger und OOP verweigerer nicht ans Herz legen würde.
Objektorientierungs Verweigerer ist ein Begriff, den ich so nicht stehen
lassen möchte. Ich würde lieber Objektorientierungs Vermeider schreiben.
Obwohl mir die Theorie zur Objektorientierung und die Vorteile, die sie
bietet geläufig und einsichtig sind, habe ich ein Problem damit, so
etwas praktisch umzusetzten.
Und auch eine gewisse Übung stellt sich nicht ein. Es kostet mich
Unmengen an Zeit, objektorientiert zu Arbeiten und wird, da ich dabei
die Grenzen meiner Konzentrationsfähigkeit regelmäßig überschreite, sehr
Ffhleranfällig.
Aber man kommt in Python/tkinter auch schon sehr weit, wenn man sich an
der Objektorientierung weitestgehend vorbeihangelt.
> Python ist ein sehr mächtiges Werkzeug dank der vielen Bibliotheken. Es> kann nicht schaden es zu lernen ;-)
Was ich bestätigen kann.
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de
wie groß bzw schnell/langsam sind eigentlich Python Programme wenn sie
als .exe verpackt werden?
Schade ist halt, das es nie echte Executable sind
Wenn es eine GUI/RAd wie Lazarus Pascal gäbe und dann noch kleine
ausführbare Files dabei rauskommen würden, wäre Python sicherlich eine
ernsthafte Überlegung wert, so scheue ich aber den ernsthaften Umstieg
und was mit PYthon in 10 Jahren ist..vielleicht hält der Hype
an..zumindest sollte die Community mittlerweile so groß sein, das es
selbst wenn es ein Nisschendasein tristen würde, vermutlich ausreichend
Anwender weiterhin am laufen halten, so das diese Sorge unbegründet
wäre..
Tanja Schmidt schrieb:> Schade ist halt, das es nie echte Executable sind
Wo ist das Problem? Unter Linux sind Python-Scripte echte ausführbare
Dateien. Nur weil ein Programm im ELF oder PE Format vorliegt wird das
nicht besser...
Hi, ob Verweigerer oder Vermeider ist mir eigentlich egal, ich denke nur
es ist schwierig an Objektorientierung vorbei zu kommen. Selbst ein
String ist schon ein Objekt! Warum also die Augen davor verschliessen?
Ich finde es sehr nützlich OOP im Alltag einzusetzen und es macht mir
das Leben eher leichter als schwerer, muß ja auch nicht jeder so
empfinden. Bewusstes vermeiden stelle ich mir schwieriger vor als die
Konzepte dahinter zu verstehen und anzuwenden.
Gerade bei dem Szenario was der TO beschrieben hat würde es sich
anbieten seine verschiedenen Variablensätze in Klassen zu organisieren.
@Tanja
Ich kann dir leider nichts darüber sagen wie sich python als .exe
verhält weil ich es noch nie gebraucht habe, aber schnell ist es! Sehr
schnell sogar wenn man es richtig anstellt. Ich benutze es inzwischen
als Matlab Ersatz wegen der besseren Performance die nahe an C ran kommt
wenn man nummerische Berechnungen betreibt (Es stehen die gleichen
Bibliotheken in C dahinter).
Python wird jetzt auch erst 30 Jahre alt, daher würde ich mir über die
nächsten 10 eher keine sorgen machen.
Blabla schrieb:> Ich finde es sehr nützlich OOP im Alltag einzusetzen
Dein Name passt schon ganz gut.
Denn wer sich in den letzten 10 Jahren etwas umgesehen hat, wird wohl
auf viel Kritik am OOP Konzept gestossen sein, insbesondere an Vererbung
und dynamic dispatch. Viele der modernen Sprachen wie etwa auch Go-Lang
vermeiden OOP ja eher, und auch von Entwicklern der AAA-Games gab es ja
viel Kritik an OOP. Ich hatte den OOP Hype um 1990 auch voll mitbekommen
und habe bis vor einigen Jahren auch versucht alles in Objekte zu
quetschen und mit Vererbung und Methoden zu erschlagen, insbesondere
auch im Ruby, dass ja noch mehr als Python auf OOP fixiert ist. Zum
Thema etwa
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
oder
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Tanja Schmidt schrieb:> wie groß bzw schnell/langsam sind eigentlich Python Programme wenn sie> als .exe verpackt werden?
Bei dem was der TS machen will, spielt Performance kaum eine Rolle.
Ansonsten kann man je nach Anwendungsfall ja messen.
Hallo Blabla.
Blabla schrieb:> Hi, ob Verweigerer oder Vermeider ist mir eigentlich egal, ich denke nur> es ist schwierig an Objektorientierung vorbei zu kommen. Selbst ein> String ist schon ein Objekt! Warum also die Augen davor verschliessen?
Das ist Richtig. Aber ich verschliesse nicht die Augen davor, es klappt
einfach im Kopf nicht mehr wie früher.
>> Ich finde es sehr nützlich OOP im Alltag einzusetzen und es macht mir> das Leben eher leichter als schwerer, muß ja auch nicht jeder so> empfinden.
Ich "denke" sogar Opbjektorientiert. Das wird mir klar, wenn ich alte
Notizen (zu allem möglichen, nicht nur Programmieren) durchlese, und
meine verfälschte Erinnerung dazu bemerke. Die Versatzstücke der
Konfabulation sind irgendwie stereotyp. So als wären es "Objekte", die
an die Situation angepasst werden.
> Bewusstes vermeiden stelle ich mir schwieriger vor als die> Konzepte dahinter zu verstehen und anzuwenden.
Wenn Du nicht verstehen kannst, dass Du etwas Verstehst, aber trozdem
nicht Umsetzten kannst, dann kannst Du auch schlecht verstehen, dass
Vermeiden einfacher sein kann. ;O)
>> Gerade bei dem Szenario was der TO beschrieben hat würde es sich> anbieten seine verschiedenen Variablensätze in Klassen zu organisieren.
Richtig.
> Ich kann dir leider nichts darüber sagen wie sich python als .exe> verhält weil ich es noch nie gebraucht habe, aber schnell ist es!
Wie das unter Windows geht, weiss ich nicht, und unter Linux ist es so
wenig nötig, dass es keiner macht.
Es ist aber möglich, in Python C Routinen einzubauen, wo das aus
Geschwindigkeitsgründen opportun ist.
Was aber auch geht, ist Python in C zu übersetzten, und das dann ganz
gewöhnlich als C-Programm zu compilieren.
Habe ich aber auch noch nicht selber gemacht. Aber ich kenne die
betrüblichen Fälle von Leuten, die sich Software mit C-Quellen
eingekauft haben. Die C-Quellen stellten sich aber dann hinterher als
von einer anderen Programiersprache (Java oder Python oder noch
irgendwas anderes) nach C übersetztes heraus. Das Compilieren
funktionierte auch, und das Programm lief, aber die Quellen waren zur
Weiterentwicklung unbrauchbar, weil total verknotet und in einer Weise
geschrieben, wie es kein Mensch machen würde.
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Stefan S. schrieb:> Blabla schrieb:>> Ich finde es sehr nützlich OOP im Alltag einzusetzen>> Dein Name passt schon ganz gut.
Wieso?
Was ist denn an seiner Aussage falsch?
> Denn wer sich in den letzten 10 Jahren etwas umgesehen> hat, wird wohl auf viel Kritik am OOP Konzept gestossen> sein, insbesondere an Vererbung und dynamic dispatch.
Hmm. Und?
Die Hysterie in den 90ern war genauso dämlich wie die
jetzige Verteufelung.
Das Problem liegt meiner Meinung nach darin, dass weder
der Erfinder der OOP selbst noch irgend einer seiner
Schüler und Missionare eine einfache und klare Erklärung
dafür gibt, WAS ein Objekt IST.
Liest man nach, hat man nicht mehr den Eindruck, es
ginge um Computerwissenschaften, sondern fühlt sich,
was den Grad des Geschwurbels angeht, in ein
philosophisches Seminar über vergleichende Literatur-
wissenschaft versetzt.
Dabei ist es ganz einfach. Das, was die Codierknechte
"Objekt" nennen, kennen die Theoretiker schon ziemlich
lange, und sie nennen es "Automat".
Ein Automat besteht aus einem Zustandsspeicher, z.B.
in Gestalt einer Flipflop-Batterie ("Felder", "Member-
variablen") und einer Kombinatorik ("Methoden", "Member-
functions"). Automaten sind ein klar definiertes Konzept:
Eingabealphabet, Ausgabealphabet, Menge der Zustände,
Überführungsfunktion, Ausgabefunktion. Alles was darüber
ist, ist vom Übel.
Vom historisch vorangehenden "Paradigma" der modularen
Programmierung unterscheidet sich die objektorientierte
Programmierung primär dadurch, dass man die Objekte
DYNAMISCH, d.h. zur Laufzeit erzeugen und wieder
vernichten kann, was mit klassischen "Modulen" nicht
möglich war. Deren Art und Anzahl stand zur Compilezeit
schon fest.
Alles andere, also z.B. die ereignisgesteuerte
Programmierung, oder die Vererbung und alles, was mit
ihr zusammenhängt, ist begleitenden Belletristik, die
mit der Kernidee der OOP nicht viel zu tun hat.
Die ganzen schrecklich komplizierten Probleme, die z.B.
mit der Vererbung zusammenhängen, sind Probleme, die sich
die OOP-Leute aufgrund ihres Hanges zur Übertreibung selbst
organisiert haben. Das hat mit der Quintessenz der objekt-
orientierten Programmierung nix zu tun.
Man kann auch eine gerade Linie vom "Paradigma" der
"strukturierten Programmierung" über die "modulare
Programmierung" hin zur "objektorientierten Programmierung"
ziehen: Die strukturierte Programmierung zielt auf die
Steuerstruktur des Programmes, also auf die Kombinatorik
des durch das Programm beschriebenen Automaten. Es handelt
sich aber i.d.R. noch um EINEN großen Automaten, weil die
Variablen, die die gesamte Programmlaufzeit leben, global
sind. Lokale Variablen sind auch temporäre Variablen; sie
entsprechen den elektrischen Wellenfronten, die durch die
Gatter der Kombinatorik hindurchlaufen.
Die modulare Programmierung zerlegt das Programm dadurch,
dass die Module gekapselt sind und private Variablen haben,
in ein NETZ von Automaten. Deren Art und Anzahl wird aber
bei der Programmübersetzung endgültig festgelegt.
Variablen, die die gesamte Programmlaufzeit leben, sind
NICHT mehr notwendigerweise global. Ein Modul hat keinen
direkten Zugriff auf den Zustand eines anderen Moduls.
Die objektorientierte Programmierung macht den Sack dann
insofern zu, als das Gesamtprogramm weiterhin als Automaten-
NETZ (und nicht als ein großer monolithischer Automat)
aufgefasst wird, Anzahl, Art und Verschaltung der Teil-
automaten, die dieses Automatennetz bilden, aber DYNAMISCH,
d.h. zur Laufzeit verändert werden kann.
Vererbung ist eine bequeme Sache, um eine größere Anzahl
untereinander ähnlicher Automatentypen strukturiert zu
beschreiben, aber man sollte aus der Vererbung keinen Kult
machen.
All das ist für einen Hardwaremenschen leicht vorstellbar.
Wenn zur Laufzeit ein neues Exemplar eines Objektes
hergestellt wird, dann ist das so, als würde er einen
weiteren HCT-Baustein aus dem Regal nehmen und in das
Steckbrett drücken. Vererbung ermöglicht Dinge wie "Ich
brauche etwas wie einen HC14, aber mit elf statt mit
sechs Invertern -- und außerdem sollen noch zwei
Flipflops drin sein". Bei realer Hardware ist das für
Normalsterbliche, denen keine Chipfabrik gehört, eine
Illusion -- aber in der Softwerkerei geht das.
> Ich hatte den OOP Hype um 1990 auch voll mitbekommen
Ich auch. Schrecklich.
> und habe bis vor einigen Jahren auch versucht alles in> Objekte zu quetschen und mit Vererbung und Methoden zu> erschlagen, [...]
Ich nicht.
Ich habe mich der Hysterie verweigert, durchaus auch zu
meinem eigenen Schaden. Dennoch konnte ich mich nicht
überwinden, mich durch diesen entsetzlichen Berg von
unverständlichem Geschwurbel, künstlichen Begriffen für
längst bekannte Sachverhalte und komplizierten Erklärungen
für einfache Konzepte hindurchzukämpfen.
Aber zum Glück scheint der Irrsinn ja abzuflauen, und die
Erklärungen haben ich mir inzwischen selbst entwickelt.
Bernd W. schrieb:> Objektorientierungs Verweigerer ist ein Begriff, den> ich so nicht stehen lassen möchte. Ich würde lieber> Objektorientierungs Vermeider schreiben. Obwohl mir> die Theorie zur Objektorientierung und die Vorteile,> die sie bietet geläufig und einsichtig sind, habe> ich ein Problem damit, so etwas praktisch umzusetzten.
Das glaube ich Dir auf's Wort.
Ich ziehe nur in Zweifel, dass DU der größere Teil
dieses Problems bist. :)
Vieles, was über OOP geschrieben wird, ist aus meiner
Sicht einfach hinrissiger Mist. Es ist nicht falsch,
aber völlig unnötigerweise irrsinnig kompliziert.
> Und auch eine gewisse Übung stellt sich nicht ein.> Es kostet mich Unmengen an Zeit, objektorientiert zu> Arbeiten
Dann hast Du den Kniff noch nicht gefunden, wie man sie
zweckmäßig anwendet (was in Anbetracht der üblichen
"Erklärungen" nicht verwunderlich ist). OOP soll ja
dem Programmierer das Leben vereinfachen -- und nicht
schwieriger machen.
> und wird, da ich dabei die Grenzen meiner> Konzentrationsfähigkeit regelmäßig überschreite, sehr> Ffhleranfällig.
Hmm, naja.
Ich verwende keine Hardcore-OOP-Sprache, also weder C++
noch Java; in der Regel bastele ich mit Tcl herum, was
ja nicht im eigentlichen Sinne objektorientiert ist.
"Echte" OOP, also so richtig mit Vererbung und so, hat
mir bisher nie gefehlt.
Was aber ECHT nützlich ist, das ist das Konzept der
Kapselung... also nicht nur Modularisierung im Sinne von
"der Quelltext besteht aus mehreren Teilen" sondern
Kapselung: Ein "Modul" bekommt seine Zustandsvariablen,
die zwar die gesamte Programmlaufzeit leben, auf die
aber von außerhalb des Modules nicht zugegriffen wird.
Von außen aufgerufen werden AUSSCHLIESZLICH die Methoden,
die bei Bedarf ihrerseits auf die Modulvariablen zugreifen
und diese ändern.
Der Charme dieser Methode besteht darin, dass ich den
genauen Aufbau der internen Datenstrukturen nicht kennen
muss, wenn ich von außerhalb irgendeine Aktion auslösen
will -- was meinem unzuverlässigen Gedächtnis EXTREM
entgegenkommt.
Das ist zwar im Sinne der reinen Lehre (noch) nicht
objektorientiert, aber das ist mir scheissegal, weil
es NÜTZLICH ist -- und es trainiert die Denkweise, in
"Automaten" zu denken.
> Aber man kommt in Python/tkinter auch schon sehr weit,> wenn man sich an der Objektorientierung weitestgehend> vorbeihangelt.
Naja... wenn Du mit Tk klarkommst (was ja offensichtlich
der Fall ist, wenn Du tkinter verwendest), weisst Du ja
schonmal, wie man Objekte verwendet, denn die Widgets
haben ja alle Merkmale von Objekten: Sie haben in der
Regel einen Zustand, den man von außen setzen und
abfragen kann, und man kann sie zur Laufzeit erzeugen
und vernichten. Alles da, was ein Objekt (=Automat)
braucht.
Ob das im Sinne der reinen Lehre "objektorientiert"
ist, ist mir sowas vom wumpe... das kannst Du Dir gar
nicht vorstellen... :)
Egon D. schrieb:> Automaten sind ein klar definiertes Konzept: Eingabealphabet,> Ausgabealphabet, Menge der Zustände, Überführungsfunktion,> Ausgabefunktion.
Allerdings ist bei Objekten die Zustandsmenge meistens unendlich groß.
Bei "Automat" denkt man erstmal an "endlicher Automat", und genau das
sind Objekte meist nicht. Die genannten Funktionen sind meist auch
nicht-trivial und lassen sich kaum mit einem mathematischen Ausdruck
angeben. Auch wenn deine genannten Elemente also prinzipiell existieren,
lassen sie sich nur schwer formalisieren und am Code ablesen. Daher ist
diese Abstraktion nicht so beliebt.
Stell dir die normale Java String Klasse vor. Die hat konzeptionell
unendlich viele Zustände (d.h. sie ist so programmiert als hätte sie
unendlich viele, tatsächlich ist sie durch die Plattform auf 16^64
limitiert IIRC). Das sind so viele, dass man sich davon kein
Zustandsdiagramm malen möchte. Was ist das Eingabealphabet? Das
kartesische Produkt aller Member-Funktionen mit allen möglichem
Eingabe-Parametern? Könnte man aufstellen, ist aber doch eher
unhandlich. Die Übergangsfunktion ist trivial, da String immutable ist.
Also auch eher nutzlos. Wenn man jetzt sagt OOP ist böse, frage ich
mich, ist auch die String-Klasse böse? Nahezu jede Sprache außer C hat
eine String-Klasse (selbst die Nicht-OOP-Sprachen), also irgendwie
scheint OOP doch ganz nützlich zu sein.
Jetzt stell dir eine Klasse vor, welche einen kompletten Schaltplan
enthält, z.B. für ein Simulationsprogramm. Die hat wieder eine Menge
Unterobjekte, und die Zustandsmenge ist enorm unübersichtlich und
konzeptionell unendlich. Für die Schaltung selbst könnte man natürlich
gut eine Übertragungsfunktion angeben, aber für die Schaltplan-Klasse?
Die hat vielleicht eine Funktion addElement, die hat 1 Zeile der Form
Elements.add(...). Das ist relativ simpel, aber wie soll man das in der
Automatentheorie abbilden? Erscheint mir wenig praktikabel.
So arbeiten nichtmal theoretische Informatiker, und die machen sonst
viel mit endlichen und unendlichen Automaten...
Eine einfache praxisnahe Definition von Objekt wäre: eine Sammlung von
Daten mit zugehörigen Funktionen, welche damit arbeiten. Die Funktionen
stellen die Konsistenz der Daten sicher und kapseln die interne
Darstellung.
Wenn du unter Windows arbeitest, kannst du das
Visual Studio verwenden.
Da kannst du das Windows API verwenden, in C oder Basic
programmieren, und das beste ist:
Du brauchst KEIN OOP, und die EXE hat gerade mal 20 kByte.
Der graphische Editor macht dir die Program Oberfläche praktisch
von alleine, du musst nacher nur mehr den Inhalt einfüllen.
Da gibt es in der mitgelieferten Hilfe auch gute Tutorials.
Wenn du auf Bloatware stehts, nimm Pyhon :-)
Udo K. schrieb:> Der graphische Editor macht dir die Program Oberfläche praktisch> von alleine
Welcher grafische Editor von VS produziert denn Nicht-OOP Code? Noch
dazu in C? Soweit ich mich erinnere ist das entweder für C# (total OOP)
oder C++ mit MFC (ziemlich OOP). C mit Visual Studio macht überhaupt
keinen Spaß, weil das nichtmal C99 unterstützt.
Tanja Schmidt schrieb:> wie groß bzw schnell/langsam sind eigentlich Python Programme wenn sie> als .exe verpackt werden?
Das kommt drauf an. Mit PyInstaller (kann executables fuer Windows und
Linux packen (ich glaube aber nicht als "cross-compiler")) kannst du
a) eine statische (grosse) exe bauen, die alles enthaelt (dein programm,
pythoninterpreter und alle libs)
b) eine kleinere exe bauen, die dein Programm und den Pythoninterpreter
enthaelt, dafuer aber die ganzen libs als extra dateien bei liegen.
Hier ein Beispiel:
1
#!/usr/bin/env python
2
3
defmain():
4
print("Hello World!")
5
6
7
if__name__=='__main__':
8
main()
Option a):
1
$ pyinstaller --onefile main.py
erzeugt eine einzige ausfuehrbare Datei, die hier bei mir auf Linux,
~6MB gross ist.
Option b):
1
$ pyinstaller main.py
Der erzeugte Ordner ist ~13MB gross und enthaelt 50 Dateien:
Dafuer ist die ausfuehrbare Datei "nur" noch gut 1MB gross.
Wenn man mit einem Framework wie Qt arbeitet, dann wird der Ordner in
Option b) auch schnell 100MB gross.
Das schoene an PyInstaller ist, dass man sich um nicht viel kuemmern
muss. Einfach das main-Script angeben, fertig. PyInstaller sucht dann
alle noetigen Libs zusammen.
Was die Performance angeht:
Die erzeugte exe ist nicht langsamer, als wenn du das Script normal
ausfuehren lassen wuerdest.
Wenn man wirklich Performance Probleme hat (also nach dem man so
wirklich alles aus Python rausgeholt hat), dann kann man immernoch
Cython nehmen.
https://cython.org/
1
Cython is an optimising static compiler for both the Python programming
2
language and the extended Cython programming language (based on Pyrex).
3
It makes writing C extensions for Python as easy as Python itself.
4
5
Cython gives you the combined power of Python and C to let you
6
7
write Python code that calls back and forth from and to C or C++
8
code natively at any point.
9
10
easily tune readable Python code into plain C performance by adding
11
static type declarations, also in Python syntax.
12
13
use combined source code level debugging to find bugs in your Python,
14
Cython and C code.
15
16
interact efficiently with large data sets, e.g. using multi-dimensional
17
NumPy arrays.
18
19
quickly build your applications within the large, mature and widely
20
used CPython ecosystem.
21
22
integrate natively with existing code and data from legacy, low-level
23
or high-performance libraries and applications.
24
25
The Cython language is a superset of the Python language that
26
additionally supports calling C functions and declaring C types on
27
variables and class attributes. This allows the compiler to generate
28
very efficient C code from Cython code. The C code is generated once
29
and then compiles with all major C/C++ compilers in CPython 2.6, 2.7
30
(2.4+ with Cython 0.20.x) as well as 3.3 and all later versions.
Ich verstehe die Leute nicht, die hier so gegen OOP sind. Nehmen wir
einfach mal ein string in Python, der ein Objekt und kein char-array
ist.
Machen wir eine Schleife über die Buchstaben:
for LETTER in STRING:
so einfach geht es in Python. In c braucht man eine Krüppelvariable zum
zählen. Ich denke mit der Objektvariante hat das Gehirn weniger arbeit.
In Python kann man sich auch selber festlegen, wie ein Objekt iterriert.
Man ist bei OOP auch nicht gezwungen alles mit Vererbung zu machen. Wie
immer das Werkzeug da einsetzen wo es sinnvoll ist.
Karl schrieb:> Ich verstehe die Leute nicht, die hier so gegen OOP sind. Nehmen wir> einfach mal ein string in Python, der ein Objekt und kein char-array> ist.>> Machen wir eine Schleife über die Buchstaben:>> for LETTER in STRING:
Nein gegen OOP muss man nicht sein, aber viele Leute sehen in OOP immer
noch das einzig wahre, selig machende.
Dein obiges Codebeispiel hat mit OOP auch nicht viel zu tun, das wird
allgemein als Iterator bezeichnet, ist sehr sicher und bequem zu nutzen
und ist oft genauso effizient wie eine explizite Schleife.
Auch die angenehmere Schreibweise myString.length statt length(mystring)
hat mit OOP nicht wirklich etwas zu tun, das ist einfach eine andere
Syntax, seit D-Lang meist mit UFCS bezeichnet (Nim nennt es treffender
Method-Call-Syntax), siehe
https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
Nachteilig ist echte OOP etwa oft bei der Performance, wenn die Objekte
alle auf dem Heap alloziert werden müssen und auf sie indirekt über
Pointer zugegriffen wird. Der Cache wird dann kaum ausgenutzt, und die
Performance kann drastisch sinken.
Stefan S. schrieb:> Nachteilig ist echte OOP etwa oft bei der Performance, wenn die Objekte> alle auf dem Heap alloziert werden müssen
Wo müssen sie das? Selbst die JVM kann das optimieren.
Stefan S. schrieb:> Der Cache wird dann kaum ausgenutzt,
In C++ z.B. kann std::vector alle Objekte hinereinander anlegen. Die
Performance ist dann identisch zu der eines simplen Arrays.
Dr. Sommer schrieb:> Stefan S. schrieb:>> Der Cache wird dann kaum ausgenutzt,> In C++ z.B. kann std::vector alle Objekte hinereinander anlegen. Die> Performance ist dann identisch zu der eines simplen Arrays.
Ja aber doch nur wenn die Objekte alle gleich groß sind. Bei OOP mit
Vererbung sind die Objekte ja eben heterogen und belegen unterschiedlich
viel Speicher, dann hat man im std::vector ja in der Regel nur die
Pointer auf die Instanzen abgelegt.
Stefan S. schrieb:> Bei OOP mit> Vererbung sind die Objekte ja eben heterogen und belegen unterschiedlich> viel Speicher
Ja. Aber wie willst du diesen Fall ohne OOP effizienter abdecken? Mit
"Variant"-artigen Datentypen? So wie std::variant? (Oh, wieder ein
Objekt)
> Wenn du auf Bloatware stehts, nimm Pyhon :-)
Ja nimm genau das: Pyhon
Und zeige mir nicht triviale SW welche e.g. kleiner 2MB installiert ist.
Alle Windows Updates (selbstverständlich auch Windows selbst) sind ja so
bequem unbloatig weil der Hersteller eben NICHT auf Python setzt. Issia
logisch.
Man muss sich eben darüber klar sein, ob man Vererbung und diese
heterogenen Objekte wirklich im konkreten Fall braucht. Und auch dann
kann man Union-Types/ATD/Case-Variants oder wie auch immer das genannt
wird nehmen, also ähnlich der Union bei C Structs. Die Objekte sind dann
alle gleich groß, haben aber teilweise unterschiedlichen Inhalt. So
verschwendet man etwas Speicherplatz, dafür liegen dann die Instanzen
aber direkt hintereinander im Speicher, was die Cache-Effizienz stark
verbessert. Natürlich geht das nicht immer, wenn man eine Liste/Array
mit Objekten sehr unterschiedlicher Größe hat, dann macht echtes OOP
Sinn.
Stefan S. schrieb:> Und auch dann> kann man Union-Types/ATD/Case-Variants oder wie auch immer das genannt> wird nehmen
Ja. Das geht in C++ z.B. mit std::vector<std::variant<TypA, TypB,
TypC>>. In der einen Zeile werden 5 verschiedene Klassen benutzt.
Objektorientierter geht's ja wohl kaum. Bevor man sich aber über so
Dinge wie Cache-Effizienz sorgen macht sollte man natürlich messen, ob
das wirklich der Flaschenhals im Programm ist. Sonst macht man es sich
alles unnötig kompliziert.
Dr. Sommer schrieb:> Ja. Das geht in C++ z.B. mit std::vector<std::variant<TypA, TypB,> TypC>>. In der einen Zeile werden 5 verschiedene Klassen benutzt.
So weit bin ich mit meinen C++ Kenntnissen noch nicht vorgedrungen.
> Objektorientierter geht's ja wohl kaum. Bevor man sich aber über so> Dinge wie Cache-Effizienz sorgen macht sollte man natürlich messen, ob> das wirklich der Flaschenhals im Programm ist. Sonst macht man es sich> alles unnötig kompliziert.
Das ist natürlich völlig richtig.
Stefan S. schrieb:> Man muss sich eben darüber klar sein, ob man Vererbung und diese> heterogenen Objekte wirklich im konkreten Fall braucht. Und auch dann> kann man Union-Types/ATD/Case-Variants oder wie auch immer das genannt> wird nehmen, also ähnlich der Union bei C Structs. Die Objekte sind dann> alle gleich groß, haben aber teilweise unterschiedlichen Inhalt. So> verschwendet man etwas Speicherplatz, dafür liegen dann die Instanzen> aber direkt hintereinander im Speicher, was die Cache-Effizienz stark> verbessert. Natürlich geht das nicht immer, wenn man eine Liste/Array> mit Objekten sehr unterschiedlicher Größe hat, dann macht echtes OOP> Sinn
Mit OOP hast du die Möglichkeit die Objektverwaltung in eine eigene
Klasse zu kapseln und diese für die die jeweile Anwendung zu optimieren.
Das kann z.B. so
> Dr. Sommer schrieb:>> Ja. Das geht in C++ z.B. mit std::vector<std::variant<TypA, TypB,>> TypC>>. In der einen Zeile werden 5 verschiedene Klassen benutzt.>
oder wenn die Objekterzeugung und/oder der Speicherplatz der
Flaschenhals ist evtl mit Objekt-Pools gelöst werden.
Thread beobachten
Seitenaufteilung abschalten