Hallo Programmierer, ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. Kann mir einer verklickern, wofür das gut sein soll? Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden, komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern? Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die Zahl das Objekt sein...?! Intern wird es ja eh prozedural verarbeitet. Bin ich zu alt? Gruss Chregu
Zu alt kann ich nicht beurteilen, aber womöglich zu sehr auf prozedural eingeschoßen. Die Grundidee ist doch, dass du Objekte hast, welche für dich bestimmte Dinge tun bzw. bestimmte Dinge darstellen. Wie die das genau machen, kann dir aber relativ egal sein. Was du nur willst, wie du dem Objekt informationen gibt´s und was du von ihm erwarten kannst. So können Objekte einmal entstehen und stehen dann für eine bestimmte Tätigkeit, du musst nicht jedesmal den gesamten Code anpacken. Es können sich dann auch Aufgaben geteilt werden, da Person A Objekt X macht und Person B Objekt Y und auf den anderen zugreifen, ohne zu wissen wie er es genau macht. Soviel zumindest zur Theorie. Die Praxis wird dir ein erfahrerener OO Programmierer sagen können.
Christian M. schrieb: > ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir > erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. > Kann mir einer verklickern, wofür das gut sein soll? Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher zu dem Thema. Effizienter wäre es, du würdest dort einmal in zwei, drei Ressourcen hineinschauen und dann mit konkreten Fragen kommen. > Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden, > komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern? Weder kennt hier jemand den Kurs den du da machst, noch das Beispiel, udn warum das kompliziert sein soll. > Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String > manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die > Zahl das Objekt sein...?! Es gibt verschiedene Arten von Objekten. Strings sind jeweils ein Objekt mit Methoden. Das Math-Objekt hingegen ist einfach eine Sammlung von Methoden, mit denen man übergebene Zahlen bearbeiten kann usw. > Intern wird es ja eh prozedural verarbeitet. OOP ist für das Rundherum zuständig, die konkreten Anweisungen müssen natürlich z.B. prozedural geschrieben werden.
Christian M. schrieb: > Bin ich zu alt? Nein, zu troll. Wenn du keiner bist, ignorier denn OOP-Kram. Triviale Projekte kannst du auch ohne lösen. Was anspruchsvolleres machst du offensichtlich nicht, denn dann würdest du keine so dumme Frage stellen.
Christian M. schrieb: > ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir > erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. > Kann mir einer verklickern, wofür das gut sein soll? Wofür könnten eine bessere Codeorganisation, definierte Schnittstellen, Modularisierung, Erweiterbarkeit und Wiederverwendbarkeit wohl gut sein? Vielleicht, um mit möglichst geringem Aufwand stabile, wartbare Software zu entwickeln. > Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden, > komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern? Der Sinn erschließt sich Dir möglicherweise erst, wenn Du es verstanden hast. Geht vielen so, die aus der prozeduralen Programmierung kommen. Am Anfang eines Kurses (was ist ein JS-Kurs? JavaScript?) schon zu erwarten, daß Du den vollen Durchblick hast, ist ein bisschen viel verlangt. > Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String > manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die > Zahl das Objekt sein...?! Da hier keiner Deinen Code kennt, kann Dir niemand sagen, was das Math.-Objekt ist und wozu es gut ist. Anhand des Namens vermute ich mal, daß es irgendwas mit Mathematik zu tun hat, aber was das in einer Telefonliste zu suchen hat, erschließt sich mir (noch?) nicht. > Bin ich zu alt? Wenn Du "Telefon" noch mit "ph" schreibst, ... Womöglich weißt Du sogar noch, wie man ein Wählscheibentelefon bedient. :-)
Christian M. schrieb: > Aber mir erschliesst sich der Sinn eines solch abstrakten Gebildes absolut > nicht. Stichwort: Funktionen und Daten. In der prozeduralen Programmierung sind beide voneinander getrennt. Man hat auf der einen Seite Datentypen und auf der anderen Seite Funktionen, die mit den Daten etwas anstellen. In der OOP ist diese Trennung aufgehoben. Eine Klasse enthält sowohl die nötigen Datentypen als auch den nötigen Code, um das zu tun was ihre Aufgabe ist.
sagen dir "structs" etwas? Damit bündelst du Daten, damit du einen gemeinsamen "Aufhänger" hast. In der OOP kommen - vereinfacht gesagt - noch die Methoden hinzu. Viele gehen noch weiter, und erlauben keinen direkten Zugriff auf die Variablen in einem (jetzt:) Objekt, sondern nur über GetXxx() und SetXxx() Methoden, welche die Daten vorher prüfen. Die Daten selbst sind dann idR. als privat deklariert und von aussen nicht direkt zugreifbar. Jetzt kanst du weiterhin von Objekten erben. Beispielweise hast du ein Objekt (z.B. "Mensch"), welches Daten und Methoden (= Funktionen) für eine gemeinsame Basisfunktionalität bereitstellt (z.B. Name, Strasse, Hausnummer, PLZ, Ort, Land). Dann schreibst du weitere Klassen, welche besondere, weitergehende Eigenschaften enthalten, und von der Basisklasse erben (z.B. zwei Klassen "Mann" und "Frau".) Das klingt für dieses Beispiel vllt. etwas trivial, ist aber Teil der Grundidee. Im anderen Fall stellst du beispielsweise eine gemeinsame Schnittstelle zur Verfügung. So gibt es im Basisobjekt "GeoObject" die Variablen für eine Position, Farbe, Zeichenstärke etc., sowie eine (virtuelle) Funktion "Draw()". Die Klassen "Rechteck, Quadrat, Kreis, Ellipse" erben von dieser, und implementieren selbst die Funktion "Draw()". Der Teil deines Programms, welcher für das Zeichnen zuständig ist, braucht jetzt nur Objekte vom Typ "GeoObject" zu speichern, und kann diese über die Draw() Funktion zeichen.
:
Bearbeitet durch User
Lies dir das hier (und die weiteren Teile) durch, danach kannst du nochmal fragen: https://wiki.delphigl.com/index.php/Tutorial_Softwareentwicklung1
Trolljäger schrieb: > Triviale Projekte kannst du auch ohne lösen. Also ist entweder Linux ein triviales Projekt, oder der Troll bist du. OOP ist eine (durchaus erfolgreiche) Methode/Art der Programmierung, nicht mehr und nicht weniger.
Das Math-Objekt ist schlicht eine Sammlung von Funktionen aus dem Bereich Mathematik, analog zu <math.h> für C-Programmierer. Nur gibt es eben bei JavaScript keine andere Bündelungsmöglichkeit als das Objekt. Es kann als Namespace- oder Library-Ersatz benutzt werden, oder eben als Objekt im Sinne von OO. Und es ist für die Laufzeitumgebung die einzige Möglichkeit so was wie eine Bibliotek von Funktionen bereitzustellen. Und man kann auch in fortgeschrittenem Alter Verständnis für JavaScript entwickeln, obwohl ich mir gut vorstellen kann, daß der erste Kontakt Fremdeln verursacht.
Der Andere schrieb: > Trolljäger schrieb: >> Triviale Projekte kannst du auch ohne lösen. > > Also ist entweder Linux ein triviales Projekt, oder der Troll bist du. Nur weil er geschrieben hat, dass man triviale Projekte ohne OOP lösen kann heißt das nicht, dass man schwierige Projekte nur mit OOP lösen kann. Die meisten Forenteilnehmer befinden sich auch nicht auf dem geistigem Niveau eines Linus Torvalds.
Sheeva P. schrieb: > Da hier keiner Deinen Code kennt, kann Dir niemand sagen, was das > Math.-Objekt ist und wozu es gut ist. Anhand des Namens vermute ich mal, > daß es irgendwas mit Mathematik zu tun hat Naja, eben, ich versuche es Momentan mit "Gehirnwäsche", also ich setz mich dem solange aus, bis es mir logisch ist: https://youtu.be/txFu0VNSPbE?list=PLWjV3rrL77CAZGdXwnqJDUDXCCqh-Au-0 Nach diesem Video fragt nur einer, der noch nie mit OOP zu tun gehabt hat, was das Math.-Objekt ist! Gruss Chregu
Sheeva P. schrieb: > Der Sinn erschließt sich Dir möglicherweise erst, wenn Du es verstanden > hast. Geht vielen so, die aus der prozeduralen Programmierung kommen. Am Ja, vielleicht. Ich lese immer: Ein Auto hat eine Farbe, eine Marke, vier Räder und macht "Hup Hup", aber ich habe gar kein Auto, und will auch nie Eins! > Anfang eines Kurses (was ist ein JS-Kurs? JavaScript?) schon zu > erwarten, daß Du den vollen Durchblick hast, ist ein bisschen viel > verlangt. OK, ich bleib dran! :-)) Vielleicht kann mir jemand ein konkretes Beispiel geben, wo OOP klar ein Vorteil ist gegenüber Prozedural. Und Nein, Trolljäger, vielleicht habe ich noch keine komplexeren Projekte gemacht, nur so kleines Zeug wie: http://www.magnetmotor.ch/ibm.html und http://www.magnetmotor.ch/lcd-sim.html Arbeite ja nicht bei LT oder MS :-)) Chregu
Christian M. schrieb: > Ja, vielleicht. Ich lese immer: Ein Auto hat eine Farbe, eine Marke, > vier Räder und macht "Hup Hup", aber ich habe gar kein Auto, und will > auch nie Eins! Manchmal braucht man Autos, nicht überall sind so gute (aber auch teure) öffentliche Verkehrsmittel wie in der Schweiz :-) OOP ist einfach eine Art ein Problem zu strukturieren. Es hat einige Vorteile gegenüber der rein prozeduralen Programmierung aber man kann sich damit auch wunderbar ins Knie schießen. Ich habe schon mehr Scheißcode in C++ gesehen als guten. Versuch dich einfach unvoreingenommen auf die Ideen einzulassen. Wenn du von C oder Pascal aus kommst (oder sonstigen prozeduralen Sprachen) wirst du dir an Anfang im Wege stehen, dazu braucht es eine Menge Übung.
Mit OOP lässt sich viel einfacher robuste, fehlerfreie und erweiterbare Software entwickeln. Einerseits ist es dank Datenkapselung möglich fehlerhafte Programmzustände auszuschließen. Andererseits kann man existierende Software wunderbar mithilfe von Vererbung und Polymorphie erweitern und wiederverwenden. Wie man diese Mechanismen zu seinem Vorteil ausreizen kann sieht man besonders gut bei Entwurfsmuster wie z.B. Adapter, Observer etc..
Christian M. schrieb: > Vielleicht kann mir jemand ein konkretes Beispiel geben, wo OOP klar ein > Vorteil ist gegenüber Prozedural. Und Nein, Trolljäger, vielleicht habe > ich noch keine komplexeren Projekte gemacht, nur so kleines Zeug wie: > http://www.magnetmotor.ch/ibm.html > und > http://www.magnetmotor.ch/lcd-sim.html > > Arbeite ja nicht bei LT oder MS :-)) > > Chregu Ja bei so Mini-1-Mann-Projekten ist OOP nicht unbedingt notwendig. Bei Softwareprojekten in der Größenordnung von Mannjahren sieht das anders aus. Wenn du damit noch nicht in Kontakt gekommen bist, hattest du halt noch nicht mit professioneller Softwareentwicklung in größeren Projekten zu tun. Ist ja keine Schande etwas nicht zu verstehen wenn man damit nichts zu tun hat.
Nicht dass ich von diesem Thread irgend etwas gelesen hätte oder das vorhabe -- aber dass der OPP Hype, insbesondere die Vererbung etwas am abebben ist hatte ich ja schon mehrfach erwähnt. Siehe etwa http://spf13.com/post/is-go-object-oriented/ und insbesondere auch die Links zu Reddit und HackerNews https://news.ycombinator.com/item?id=7868485 https://www.reddit.com/r/golang/comments/27p2bc/is_go_an_object_oriented_language_spf13com/ Ich muss mir das auch noch mal in Ruhe durchlesen...
Mark B. schrieb: > In der OOP ist diese Trennung aufgehoben. Eine Klasse enthält sowohl die > nötigen Datentypen als auch den nötigen Code, um das zu tun was ihre > Aufgabe ist. Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht.
Ja, nicht OPP sondern OOP. Und ECS wäre das neue Stichwort: https://en.wikipedia.org/wiki/Entity_component_system
Tim schrieb: > Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht. Laut Definition in diesem Buch ist es so: https://books.google.de/books?id=9NGWq3K1RwUC&pg=PA18&redir_esc=y&hl=en#v=onepage&q&f=false In welcher konkreten Programmiersprache ist es denn anders?
Christian M. schrieb: > http://www.magnetmotor.ch/ibm.html Ist das kommerziell? Dann solltest du die Rechtschreibung nochmal prüfen. Was ist das überhaupt für ein geiler Online-Shop? Das Sortiment besteht nur aus BC547C und 1N4148. Und beides im 100er-Pack. Also wenn ich das mal brauche, bestelle ich auf jeden Fall bei dir :-)
:
Bearbeitet durch User
Christian M. schrieb: > OOP - für was in aller Welt soll denn das gut sein? Du zeigst ja nicht mal das Programm aus dem Kurs. Da kann man nicht beurteilen, ob dir der Dozent vielleicht unverständlich/unlogisches serviert hat. ABER: Wenn du in prozeduralen Sprachen irgendwelche Module schreiben willst die du an jemand anderen geben kannst, dann packst du die in eine DLL (Library). Diese DLL exportiert nach aussen nur Funktionen, damit dir der Fremde Mensch nicht unkontrolliert an deinen Daten rumfummelt. Und wenn diese DLL nicht bloss einen Datensatz verarbeiten soll sondern mehrere verschiedene, dann brauchst du auch Funktionen um neue Daten anzulegen. Schon bist du beim objektorientierten Programmieren, mit einer Klasse (deine DLL), und Methoden die auf versteckte (private) Daten arbeiten, und Funktionen um neue Instanzen der Klasse (Datensätze) anzulegen bzw. wegzuwerfen. Deine Windows Programme sind nicht anders strukturiert, dort hast du Fenster (HWND) in Klassen, und von dort kennst du auch den Weg, um ein Standardfenster (z.B. einer Edit-Box) andere Eigenschaften zu geben (z.B. syntaxhighlighting): Du baust eine Unterklasse (WndProc) die nur die Methoden (Messages) behandelt die anders sind und ansonsten weiterleitet. u.s.w. ist OOP eigentlich eine logische Folge. Aber wie bei allen Methoden gibt es Leute die sie nicht verstanden haben und dogmatisch befolgen, dann sind die Ergebnisse meistens unlogisch und bringen viel overhead.
Mark B. schrieb: > In welcher konkreten Programmiersprache ist es denn anders? In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept nicht bereits in der Sprache selbst verankert ist. OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann - in der einen besser, in der anderen weniger gut. Grundelement von OOP ist daher auch nicht, dass man Code und Daten nun in einen gemeinsamen Block schreibt. Viel mehr geht's um ganz andere Dinge wie z.B. Vererbung und Polymorphie. Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP zu tun hat, in ein Objekt-Korsett gesteckt. Für das Verständnis von OOP sollte man solche Dinge erstmal beiseite lassen.
Bei OOP ist die Idee, ein Objekt durch seine Eigenschaften und darauf anwendbaren Aktionen zu beschreiben. Je nach Programmiersprache gibt es Variationen, wie OOP umgesetzt oder wird. Haufig wird nur über Funktionen des Objekts dessen Daten verändert. Dadurch kann ein von den Daten entkoppeltes Interface definiert werden, das sich auf alle Objekte die diesem genügen anwenden lässt. Dies ist vor allem in Java populär. Andere Sprachen wie c und Go verfolgen eine andere Philosophie. Dort hat man structs, die auch andere Structs beinhaltenkönnen, und Funktionen die diese als Argument nehmen. Es ist der Unterschied zwischen "Ein Objekt ist eine Sammlung von darauf anwendbaren Methoden" und "Ein objekt ist eine Samlung von Eigenschaften, welches von Funktionen verarbeitet werden kann". Beide Sichtweisen haben ihre vor- und nachteile. Bei JS gibt es einen grossen unterschied zwischen ES6 (ECMAScript 2015) und ES5. Bei ES6 gibt es das class keyword, bei ES5 musste man aufwendig mit Funktionen und Prototypen arbeiten. Was Vererbung angeht, das ist ein Konzept um Redundanz zu verringern. Man kann es übertreiben, und manche sprachen können Mehrfachvererbung, und manche nicht. Es ist ein bischen ein Zweischneidiges schwert.
Rolf M. schrieb: > Mark B. schrieb: >> In welcher konkreten Programmiersprache ist es denn anders? > > In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept > nicht bereits in der Sprache selbst verankert ist. > OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein > Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann - > in der einen besser, in der anderen weniger gut. You Can Write FORTRAN in any Language
Rolf M. schrieb: > Mark B. schrieb: >> In welcher konkreten Programmiersprache ist es denn anders? > > In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept > nicht bereits in der Sprache selbst verankert ist. > OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein > Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann - Je nun... das stimmt schon. Die meisten Leute würden wohl trotzdem die Sprache C nicht unbedingt als OOP-Sprache einstufen, sondern als imperative, prozedurale Sprache. Also anders gefragt: Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und bei der Daten und Funktionen durch das Konzept der Klasse keine Einheit bilden?
Mark B. schrieb: > Also anders gefragt: > Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und > bei der Daten und Funktionen durch das Konzept der Klasse keine > Einheit bilden? GO? https://en.wikipedia.org/wiki/Go_(programming_language) Man kann Methoden auf Objekten aufrufen, aber die Methoden sind nicht in der Objektbeschreibung definiert, sondern als Funktionen ausserhalb.
:
Bearbeitet durch User
Mark B. schrieb: > Tim schrieb: >> Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht. > > Laut Definition in diesem Buch ist es so: > https://books.google.de/books?id=9NGWq3K1RwUC&pg=P... Wieso sollte der Autor relevant sein? Kennt den jemand? > In welcher konkreten Programmiersprache ist es denn anders? In Common Lisp. In Perls Moose ist es wohl genauso, aber Perl kenne ich nicht wirklich.
Rolf M. schrieb: > Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird > etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP > zu tun hat, in ein Objekt-Korsett gesteckt. Nein. Ein Objekt ist die Instanz einer Klasse. Die Zusammenfassung der Methoden, die für alle Instanzen der gleichen Klasse benutzt werden und der Daten, die jeweils nur für die einzelne Instanz gelten. Dieses math-Dingens ist also üblicherweise eben kein Objekt, sondern nur eine (nicht instanziierbare) Klasse. Eben weil es darin keine Daten gibt, sondern nur Methoden. Allerdings: so ganz sauber ist die Unterscheidung auch wieder nicht, denn es gibt in vielen OOP-Sprachen auch Daten, die direkt zur Klasse gehören. Das betrifft natürlich vor allem Konstanten. Beim Beispiel math etwa: math.Pi Wie auch immer: Um OOP zu verstehen, muss man als allererstes den Unterschied zwischen einer Klasse und ihren Instanzen, also aus der Klasse konstruierten Objekten verstehen, sonst wird das nix. Aber ja, ich gebe zu, dass ich auch schwere Probleme hatte, mir diesen OOP-Kram zu verinnerlichen. Dabei war es für mich noch vergleichsweise einfach, weil ich von rein prozeduraler Programmierung mit Pascal auf Object Pascal umgestiegen bin und obendrein Assembler konnte, so dass ich jederzeit hinter die Kulissen gucken konnte, was da eigentlich genau passiert. Trotzdem habe ich ungefähr ein Jahr aktive Programmierung benötigt, um wirklich "OOP zu denken" und Programme von Grund auf entsprechend zu designen. Für eingefleischte C-ler, die für OOP-Konzepte naturgemäß auf C++ umsteigen müssten, ist die Hölle definitiv um vieles heisser...
Das größte Problem sehe ich darin, dass objektorientierte Programmierung anscheinend meistens an winzigen Beispielprogrammen gezeigt wird. Da ist sie deutlich aufwendiger, als das Programm einfach prozedural zu schreiben, ohne dass dadurch ein Vorteil entsteht. Erst wenn man mal ein großes Programm schreibt und weiß, dass es sowas wie objektorientierte Programmierung gibt, werden die Vorteile klar.
Dussel schrieb: > Erst wenn man mal ein großes Programm schreibt und weiß, dass es sowas > wie objektorientierte Programmierung gibt, werden die Vorteile klar. Aber auch umgekehrt: Im Lehrbuch hat man ein schönes Beispiel wo OOP schön funktioniert, aber in der Praxis ist alles komplizierter und unschöner.
c-hater schrieb: > Rolf M. schrieb: > >> Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird >> etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP >> zu tun hat, in ein Objekt-Korsett gesteckt. > > Nein. Ein Objekt ist die Instanz einer Klasse. Ach was, mach Sachen! Und das ist auch der Sinn von Klassen - dass man sie instanziiert, oder zumindest davon ableitet. Eine Klasse, die ausschließlich statische Elemente hat, sollte meiner Meinung nach gar keine Klasse sein. Bei Sprachen, die Funktionen nur in Klassen zulassen, geht's aber nicht anders, und das meinte ich damit, dass Dinge, die eigentlich nichts mit OOP zu tun haben, in ein Objekt-Korsett gesteckt werden. Vielleicht hätte ich besser Klassen-Korsett sagen sollen.
Rolf M. schrieb: > Eine Klasse, die ausschließlich statische > Elemente hat, sollte meiner Meinung nach gar keine Klasse sein. Das ist auch die Ansicht vieler Berufsschul-Lehrer. MfG Paul
Rolf M. schrieb: > Eine Klasse, die ausschließlich statische > Elemente hat, sollte meiner Meinung nach gar keine Klasse sein. Ich denke das korrekte Sprachelement dafür sind Namespaces. Namespaces sind das einzige, das ich in C gegenüber C++ vermisse, und sie werden viel zu selten verwendet. Ich denke der Ersatz in z.B. Java mittels Packages und Klassen ist durchaus vertretbar. Stefan S. schrieb: > Aber auch umgekehrt: Im Lehrbuch hat man ein schönes Beispiel wo OOP > schön funktioniert, aber in der Praxis ist alles komplizierter und > unschöner. Ja, man muss auf vieles Aufpassen. z.B. das man keine Kreise von Ellipsen ableitet, oder umgekehrt. Oder dass man keine Interfaces nutzt, und dann Mehrfachvererbung brauchte. Oder dass man eine Sendefunktion hat, deren Sendepuffer aber aufgefüllt werden könnte, und man nichts anderes machen kann bis der Puffer wieder leer wird ohne das Design zu ändern. Oder wenn man plötzlich vor Singelton Repository Factory Factory Factory Beans steht. Oder wenn man plötzlich zwei Ballklassen ohne gemeinsames Interface hat. Oder... Natürlich funktioniert das auch umgekehrt.
OOP wurde für Leute gemacht, die nicht wie ein Computer denken können. OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung Das Problem an der immer extremeren Extrahierung ist die massiv steigende Prozessorlast. OOP hat durch diese Verschachtelung einen großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt.
T.roll schrieb: > OOP wurde für Leute gemacht, die nicht wie ein Computer denken können. > OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die > Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung > > Das Problem an der immer extremeren Extrahierung ist die massiv > steigende Prozessorlast. OOP hat durch diese Verschachtelung einen > großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt. Na wenigstens steht er zudem was er ist, das kann man von anderen nicht behaupten ;)
Daniel A. schrieb: > Mark B. schrieb: >> Also anders gefragt: >> Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und >> bei der Daten und Funktionen durch das Konzept der Klasse keine >> Einheit bilden? > > GO? https://en.wikipedia.org/wiki/Go_(programming_language) > > Man kann Methoden auf Objekten aufrufen, aber die Methoden sind nicht in > der Objektbeschreibung definiert, sondern als Funktionen ausserhalb. Laut dem verlinkten Artikel ist Go allerdings nicht objektorientiert... Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der Mann sollte es wissen, schließlich hat er es erfunden. :-) Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden) das Verhalten (behaviour) eines Objekts festlegen. Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add", die mit zwei Integers aufgerufen wird, wird diese beiden addieren und das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" + "b" => "ab". Die dritte Eigenschaft, die eine OO-Sprache ausmacht, ist Vererbung. Das heißt, ich kann ein Objekt von einem anderen erben lassen und damit dessen Eigenschaften und Methoden übernehmen, überschreiben, oder durch weitere Methoden verändern.
Marc schrieb: > Mark B. schrieb: >> In welcher konkreten Programmiersprache ist es denn anders? > > In Common Lisp. In Perls Moose ist es wohl genauso, aber Perl kenne ich > nicht wirklich. Perl{5,6} und auch Moose machen das ganz klassisch, nur daß die Definition da nicht Klasse, sondern Package heißt.
T.roll schrieb: > OOP wurde für Leute gemacht, die nicht wie ein Computer denken können. Nö. OOP wurde für Leute gemacht, die komplexe Probleme lösen müssen. > OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die > Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung Nö. OOP bietet verschiedene Arten einer Beziehung. So ist die Hosentasche üblicherweise Bestandteil einer Hose (Beziehungstyp has-a), welche wiederum eine Spezialisierung eines Kleidungsstücks (Beziehungstyp is-a) ist. > Das Problem an der immer extremeren Extrahierung ist die massiv > steigende Prozessorlast. OOP hat durch diese Verschachtelung einen > großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt. Nö, moderne Compiler optimieren das einfach weg. Es gibt ein paar Features der OOP, die Kosten verursachen -- in C++ etwa Exceptions -- aber wenn man diese Features vermeidet, ist das Binary am Ende kein Byte größer als eine klassische prozedurale Implementierung.
Sheeva P. schrieb: > Laut dem verlinkten Artikel ist Go allerdings nicht > objektorientiert... Es wurde bei der englischen version nicht explizit als solche spezifiziert, aber auf der Deutschen version schon. Gemäss der offiziellen FAQ sind beide Ansichten richtig: https://golang.org/doc/faq#Is_Go_an_object-oriented_language > Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine > OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der > Mann sollte es wissen, schließlich hat er es erfunden. :-) Die Erde dreht sich weiter. Wie ich in meinen vorherigen beiträgen bereits andeute, betrachte ich das OOP Konzepte nicht so strict: * Obwohl in go methoden nicht in den Structs declariert werden, kann man dennoch methoden zu Datentypen definieren, die man ganz normal auf dem Objekt aufrufen kann, also zu diesem gehören. Deshalb betrachte ich die Datenkapselung als erfüllt. Ich finde diese version ist sogar flexibler. * Obwohl die von dir beschriebene Form der Polymorphie, so nicht direkt vorkommt, stellt dein Beispiel kein Problem dar. Entweder du hast ein anderes Objekt auf welchem die Methode aufgerufen wird, das geht in go, oder du gibst der concat funktion den korrekten Namen. Aber weshalb soll das feature notwendig sein, um ein Objekt zu beschreiben? Es hat keinen Einfluss auf Inhalt, Methoden, Funktionalität oder Verwendung des Objekts, es ist also ein unnötiges Feature. * Obwohl es in go keine Vererbung gibt, haben anonyme strukt member exakt den selben Effekt. Aber es ist besserer stil, statdessen interfaces zu verwenden. Dadurch vermeidet man auch unnötige OO probleme. PS: Ich habe noch keine go programme geschrieben, und es gibt auch dinge die mir daran nicht gefallen, aber einige von deren Konzepten sind einfach verdammt gut.
:
Bearbeitet durch User
Sheeva P. schrieb: > Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine > OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der > Mann sollte es wissen, schließlich hat er es erfunden. :-) > > Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander > getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die > Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden) > das Verhalten (behaviour) eines Objekts festlegen. Hmm, für mich ist Datenkapselung eher, dass man auf die Daten nicht direkt zugreifen kann, sondern nur über bereitgestellte Funktionen. Man weiß nicht mal, wie die Daten sind. Das ist für mich etwas, das bei OOP wichtig ist, aber nicht unbedingt ein OOP-Konzept. In C gibt es den FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist für mich auch Datenkapselung, aber nicht OOP. > Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern > sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add", > die mit zwei Integers aufgerufen wird, wird diese beiden addieren und > das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit > zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" + > "b" => "ab". Das, was du beschreibst, ist eher einfache Funktionsüberladung. Das wesentliche Element von Polymorphie ist, dass man beim Aufruf der Funktion den Typ des Objekts gar nicht kennt. Deshalb wird zur Laufzeit automatisch entschieden, welche Funktion dann tatsächlich aufgerufen werden soll ("dynamic dispatch"). Wenn die Entscheidung, welche Funktion aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten abhängig ist, spricht man von multiple dispatch, was in keiner mir bekannten OOP-Sprache direkt umgesetzt ist.
Nochmal schnell zu JS und meinem Unverständnis: Jan H. schrieb: >> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String >> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die >> Zahl das Objekt sein...?! > > Es gibt verschiedene Arten von Objekten. Strings sind jeweils ein Objekt > mit Methoden. Das Math-Objekt hingegen ist einfach eine Sammlung von > Methoden, mit denen man übergebene Zahlen bearbeiten kann usw. Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! => Unlogisch und unkonsequent, oder?! Danke, Gruss Chregu
Christian M. schrieb: > Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, > die Methoden haben, Strings sind erstmal Strings. Punkt. Wenn du zum String Methoden hinzufügst (z.B. set, get), dann erhältst du ein Objekt. In der Regel verbirgt man die string-Variable vor dem Zugriff von außen und erlaubt jegliche Veränderung nur über Methoden. Damit vermeidet man unerwünschte Veränderungen...
Christian M. schrieb: > Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, > die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da > muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! => Hängt von der Sprache ab. Manche OOP Sprachen, wie etwa C++, unterscheiden zwischen Variablen, die Objekte im Sinn von Klasseninstanzen sind, und anderen Daten, die keine Objekte sind. In Sprachen wie Smalltalk sind hingegen alle Daten Objekte und die üblichen mathematischen Operatoren sind auch nur Methoden.
:
Bearbeitet durch User
Daniel A. schrieb: > Sheeva P. schrieb: >> Laut dem verlinkten Artikel ist Go allerdings nicht >> objektorientiert... > > Es wurde bei der englischen version nicht explizit als solche > spezifiziert, aber auf der Deutschen version schon. Die deutschsprachige Wikipedia schreibt aber auch: "Auf Klassen wird bewußt verzichtet". Tatsächlich ist die Datenkapselung aber eine der wesentlichen Eigenschaften der OO. Wenn Go die nicht umsetzt, dann ist es leider auch keine OO-Sprache, gleichgültig, was seine Entwickler behaupten oder was in der deutschsprachigen Wikipedia steht. > Gemäss der offiziellen FAQ sind beide Ansichten richtig: > https://golang.org/doc/faq#Is_Go_an_object-oriented_language Aus dieser FAQ: "Go takes a different approach." Ok, "Go verfolgt einen anderen Ansatz". Kein Problem -- aber ein anderer Ansatz, dem wesentliche Eigenschaften der Objektorientierung fehlen, ist eben kein objektorientierter Ansatz. Ich verstehe nicht, wie man auf der einen Seite sagen kann, man habe einen besseren Ansatz gefunden, der dem OO-Ansatz überlegen sei, auf der anderen Seite aber behauptet, der neue Ansatz sei in Wirklichkeit dann irgendwie doch objektorientiert, obwohl dabei wesentliche Teile dessen fehlen, was OO ausmacht. Sorry, aber das ist doch schizophren. >> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine >> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der >> Mann sollte es wissen, schließlich hat er es erfunden. :-) > > Die Erde dreht sich weiter. Natürlich. Aber OO hat bestimmte Eigenschaften. Wenn die erfüllt sind, ist es OO. Wenn nicht, dann nicht.
Sheeva P. schrieb: > Sorry, aber das ist doch schizophren. Aber Marketing. Hast du da jemals was anderes gehört ? XML löst endlich alle Dateiformatprobleme, Scrum alle Programmierprobleme, Java ermöglicht plattformunabhängige Programmierung und WYSIWYG ist was für die Deppen von früher heute können wir aus HTML-Quelltext das Ergenis sehen.
Rolf M. schrieb: > Sheeva P. schrieb: >> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine >> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der >> Mann sollte es wissen, schließlich hat er es erfunden. :-) >> >> Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander >> getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die >> Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden) >> das Verhalten (behaviour) eines Objekts festlegen. > > Hmm, für mich ist Datenkapselung eher, dass man auf die Daten nicht > direkt zugreifen kann, sondern nur über bereitgestellte Funktionen. Man > weiß nicht mal, wie die Daten sind. Das ist für mich etwas, das bei OOP > wichtig ist, aber nicht unbedingt ein OOP-Konzept. In C gibt es den > FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt > zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist > für mich auch Datenkapselung, aber nicht OOP. Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus gefiddelt? :-) Nee, echt jetzt: Fachbegriffe haben die Aufgabe, bestimmte Dinge für Fachleute greif- und benennbar zu machen. Wenn sich jeder seine eigene Definition zulegt, kommen wir nach Babylon. Ein FILE*-Handle ist keine Datenkapselung, sondern schlicht eine Datenstruktur, nicht weniger, aber auch nicht mehr. Datenstrukturen sind der Kern jeder Datenkapselung, gehen aber über die reine Strukturierung von Daten hinaus. >> Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern >> sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add", >> die mit zwei Integers aufgerufen wird, wird diese beiden addieren und >> das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit >> zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" + >> "b" => "ab". > > Das, was du beschreibst, ist eher einfache Funktionsüberladung. Das > wesentliche Element von Polymorphie ist, dass man beim Aufruf der > Funktion den Typ des Objekts gar nicht kennt. Deshalb wird zur Laufzeit > automatisch entschieden, welche Funktion dann tatsächlich aufgerufen > werden soll ("dynamic dispatch"). Dynamic Dispatching ist eines der Elemente von Polymorphie, virtuelle Funktionen, das Überladen von Funktionen und Operatoren etc. sind andere Elemente, die dazugehören. Im Kern dreht sich alles darum, dieselben Schnittstellen mit unterschiedlichen Datentypen nutzen zu können. Gerade am Wegesrand gefunden: http://openbook.rheinwerk-verlag.de/oop/
Christian M. schrieb: > Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, > die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da > muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! => > Unlogisch und unkonsequent, oder?! In JavaScript sind Zahlen Objekte, und haben Eigenschaften und Methoden. Da man aber nicht ständig Funktionen wie sin(), max() oder exp() braucht, ist es durchaus sinnvoll, diese Funktionen nicht direkt an die Zahl-Objekte zu klemmen, sondern sie in eine eigene Einheit auszulagern -- und genau diese Funktion hat das Math-Objekt, das mathematische Funktionen und Konstanten bündelt. Dadurch bleibt der globale Namensraum sauber, und die einzelnen Number-Objekte bleiben klein und performant. Entschuldige, aber was ist eigentlich Dein Ziel? Wolltest Du nun JavaScript lernen oder dessen Entwicklern Fehler nachweisen? Wenn Du alles, das Du noch nicht verstehst, gleich als "unlogisch und unkonsequent" abtust, wirst Du vermutlich nicht allzu weit kommen. Und wenn Du den JavaScript-Entwicklern die Unzulänglichkeiten von JavaScript nachweisen willst, dann gib' Dir keine Mühe: das hat Douglas Crockford in "JavaScript: The Good Parts" bereits sehr ausführlich und überaus kompetent getan.
Der Sinn der OOP wird klarer, wenn Du etwas kompliziertere Objekte betrachtest als Zahlen und Strings. Angenommen, Du willst eine Bibliothek für Vektorarithmetik schreiben. Einen Vektor kannst Du auf verschiedene Arten implementieren, z.B. als Array, als verkettete Liste, als feste Anzahl einzelner Variablen. Wenn Du jetzt eine Funktion hast, um Vektoren zu addieren, dann sieht diese Funktion für alle drei Implementierungen völlig unterschiedlich aus. Der Array-Methode musst Du zwei Array-Pointer übergeben, der Listenmethode zwei Listenpointer, der Variablenmethode eine Haufen einzelner Werte. Beim Objektorientierten Ansatz ist Dein Vektor in ein Objekt gekapselt. Statt einer Funktion rufst Du eine Additions-Methode des Objekts auf und übergibst als Parameter ein anderes Vektorobjekt. Dabei spielt die interne Implementierung eines Objekts überhaupt keine Rolle. Für den Benutzer ist das eben ein Vektor und sonst nichts. Du kannst die verschiedenen Vektorklassen beliebig gegeneinander austauschen, ohne dass Du Deine Software ändern musst. Die Methoden abstrahieren so weit von der internen Darstellung des Vektors, dass Du sie verwenden kannst, ohne die Details zu kennen. Änderungen an der Vektorklasse erfordern keine Änderung am Programm. Wenn Deine Software irgendwann auf einem echten Vektorprozessor laufen soll, der z.B. Vektoraddition in der Hardware unterstützt, dann leitest Du aus der alten Vektorklasse eine neue ab, die die Vektoradditiion an die Hardware durchreicht und alle übrigen Funktionen wie bisher an das alte Vektorrobjekt weitergibt. Das nennt man Vererbung. Du darfst nicht den Fehler machen, die Kapselung in Objekte als Einschränkung zu sehen. Objekte werden erst dadurch flexibel einsetzbar, dass sie ihren inneren Aufbau verbergen und vom Benutzer kein Wissen darüber voraussetzen. Die Vorteile der OOP werden einem nicht so schnell klar, wenn man gerade damit anfängt, das ging mir auch so. Aber nach einer Weile willst Du nciht mehr darauf verzichten, Wobei es naürlich auch Situationen gibt, in denen sich OOP einfach nicht lohnt, z.B. auf kleinen Microcontrollern. Aber das Fass will ich hier nicht schon wieder aufmachen.
Rolf M. schrieb: > Wenn die Entscheidung, welche Funktion > aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten > abhängig ist, spricht man von multiple dispatch, was in keiner mir > bekannten OOP-Sprache direkt umgesetzt ist. Schon wieder Common Lisp.
Marc schrieb: > Rolf M. schrieb: >> Wenn die Entscheidung, welche Funktion >> aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten >> abhängig ist, spricht man von multiple dispatch, was in keiner mir >> bekannten OOP-Sprache direkt umgesetzt ist. > > Schon wieder Common Lisp. Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist: "(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-)
Sheeva P. schrieb: > In C gibt es den >> FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt >> zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist >> für mich auch Datenkapselung, aber nicht OOP. > > Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus > gefiddelt? :-) Warum sollte er, dafür gibt es die Funktion fileno, sozusagen eine Memberfunktion von FILE zum Zugriff auf diese private Variable.
Sheeva P. schrieb: > Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist: > "(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-) https://xkcd.com/224/
Michael B. schrieb: > Sheeva P. schrieb: >> Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus >> gefiddelt? :-) > > Warum sollte er, dafür gibt es die Funktion fileno, Ja, genau damit macht man das... Entschuldige, aber ich habe leider nicht verstanden, was Du mir damit sagen möchtest. > sozusagen eine > Memberfunktion von FILE zum Zugriff auf diese private Variable. In C gibt es keine privaten Variablen. Ja, static existiert, ist aber was anderes als "private" in C++-Structs oder -Klassen.
Christian M. schrieb: > Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, > die Methoden haben Laß mal deine konkrete Programmiersprache, die du grad übst, außen vor und betrachte das Ganze mit etwas größerem Abstand. Also: Stell dir vor, du müßtest irgend eine Anwendung schreiben, die mit vielen unterschiedlichen Dingen sich abgibt, wobei aber diese Dinge eine Reihe gleicher Anforderungen erfüllen müssen - das klassische Beispiel ist ein Grafikprogramm, wo man auf dem Bildschirm oder Drucker oder sonstiger Fläche eine Vielzahl von Dingen haben kann: Punkte, Kreise, Dreiecke, Vierecke, rote und blaue, gefüllte und ungefüllte. Die sind alle unterschiedlich, aber sie müssen in einigen Hinsichten gleich behandelt werden: speichern, laden, zeichnen, und so weiter. Jetzt könntest du für jede Art dieser Dinge in einer umfänglichen Routine if ding=kreis else if ding=viereck.. usw. alle Varianten berücksichtigen, wenn es daran geht, all die Dinge, die der Grafiker auf seinem Bildschirm haben will zu zeichnen. Das ist umfänglich und wenn ein neues Ding dazukommt, mußt du deine Riesenroutine umschreiben, damit sie auch das neue Ding zeichnen kann. Mit Objekten macht man das anders. Da hat so ein Objekt nicht nur seine Eigenschaften (wie XY-Position, Größe, Farbe usw), sondern auch seine Methoden und eine davon ist die Methode "Zeichne_Dich". Deine Routine zum Zeichnen aller Dinge des Bildes, was der Grafiker da grad entwirft, schnurrt deshalb auf Mini-Größe zusammen: for all do Zeichne_Dich; und jedes Objekt zeichnet sich selber - und zwar unabhängig von allen anderen Objekten. Dem Kreis ist es egal, wie ein Dreieck sich zeichnet. Er braucht bloß zu können, sich selbst zu zeichnen. Genauso geht es, wenn dem Grafiker sein Bild nicht gefällt und er das eine Ding mehr nach rechts rücken will und das andere nach oben, oder das nächste etwas größer oder gedreht. Zu diesem Zweck haben all die Objekte des Grafikprogramms eine Reihe von Eigenschaften (Properties), die man von außen verändern kann (ohne wissen zu müssen, was man damit innerhalb des Objektes anrichtet), die aber bei allen gleich sind (dank Vererbung). Die Koordinate ist ein typisches Beispiel. Wenn du prozedural programmierst, mußt du auch für das Verrücken eines Kringels eine Riesenroutine starten, denn jedes Ding ist ja ein Record (oder in C ein Struct) und du kannst nicht mit dem gleichen Befehl auf Records (Struct's) von unterschiedlicher Definition zugreifen (ein struct Dreieck ist eben was anderes als ein struct Kreis). Wenn man jedoch Kreis, Dreieck, Rechteck usw. von einem gemeinsamen Vorfahren "Kringel" ableitet, der solche Eigenschaften wie Koordinate, Drehwinkel, Größe, Farbe, Füllung usw. bereits in sich hat, dann kann man eben diese Eigenschaften bei allen Dingen auf dem Bild des Grafikers ändern, ohne unterscheiden zu müssen, um was für ein Ding es sich grad handelt. Also etwa so: Current_Kringel.X = 147 (egal ob es konkret ein Dreieck oder Viereck ist) Kurzum: Wenn man mit einer Vielzahl von Dingen hantieren muß, die in gewisser Hinsicht alle gleich behandelt werden müssen, die aber dennoch innerlich unterschiedlich sind, dann ist OOP angesagt. Für irgend eine blöde Variable inclusive Strings ist sowas hingegen Mumpitz. Da ist eine simple Zuweisung nebst Formel (wenn nötig) völlig ausreichend. Ein String.LöscheDich ist Unfug, String:='' tut's auch. Etwas klarer jetzt? W.S.
W.S. schrieb: > Ein String.LöscheDich ist Unfug, String:='' tut's auch. Wobei man etwas aufpassen muss. Letztere Anweisung kann in einigen Sprachen einen neuen, leeren String erzeugen, und der alte String muss vom GC entsorgt werden. Und dann ist da natürlich die Schreibweise -- clearString(str) bzw. str.clear. Wobei man für letzteres nicht unbedingt OOP benötigt, in DLang, Nim und einigen anderen Sprachen wird str.clear automatisch in den Funktionsaufruf clear(str) gewandelt. Dlang nennt das UFCS: http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 Bei Nim hat man zugegebener Weise das Problem, wenn man clear() vom Modul strings qualifiziert importiert, dann müsste man ja strings.clear(str) schreiben und str.strings.clear wäre nicht schön und funktioniert wohl auch nicht. Einige sehen da ein Problem, aber die meisten importieren einfach das ganze Modul, also alle Funktionen unqualifiziert, dann funktioniert es, und da andere gleichnamige Funktionen in der Regel andere Parameter haben gibt es auch meist keine Probleme. Und wenn doch, dann meckert der Compiler, und man muss eben den Modulnamen angeben.
Moby A. schrieb im Beitrag #4624966: > Jan H. schrieb im Beitrag #4621860 >> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher >> zu dem Thema. > > Die sind auch nötig. > Das ist nichts was naturgegeben intuitiv und ohne steile Lernkurve > einfach anzuwenden wär. > OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge > neuer Bürokratie ein. > Das lohnt sich erst bei grösseren Projekten. Und wie wir wissen, spricht hier einer aus Erfahrung... Ne echt jetzt, wie wär's wenn du das OOP Bashing mal unterlassen könntest. Du hast schlicht keine Ahnung davon. Du hast OOP noch nicht ein einziges Mal angewendet. Was außer einem ATtiny und Assembler kennst du überhaupt?
Moby A. schrieb im Beitrag #4624966: > Jan H. schrieb im Beitrag #4621860 >> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher >> zu dem Thema. > > Die sind auch nötig. Eigentlich sind die meisten davon ähnlich überflüssig wie Deine "Beiträge" zu diesem Thread hier. OO ist kein Hexenwerk, wobei es zugegeben ein wenig schwieriger ist, sie ausgerechnet an JavaScript mit einer etwas exotischen Realisierung der OO lernen zu wollen. > OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge > neuer Bürokratie ein. > Das lohnt sich erst bei grösseren Projekten. OO ist auch bei kleinen Projekten sinnvoll, wenngleich die Stärken der OO mit zunehmender Projektgröße immer stärker zum Tragen kommen. Ab einer gewissen Projektgröße ist die Entwicklung ohne OO kaum noch beherrschbar. In den meisten Fällen trägt OO allerdings sehr dazu bei, die Projektgröße kleiner und beherrschbarer zu machen, auch bei kleinen Projekten. Insofern führt OO keine Bürokratie ein, sondern hilft dabei, sie zu verringern und das Projekt insgesamt zu vereinfachen -- was naturgemäß zu fehlerärmerer, stabilerer und besser wartbarer Software führt. Das kann man natürlich alles nicht wissen, wenn man OO nicht kennt und aus Angst vor dem Scheitern auch nicht lernen will. Und bevor Du jetzt schon wieder einen fremden Thread kaperst, lies' doch einfach Kapitel 2 des von mir oben schon verlinkten Openbook. Dann kannst Du vielleicht wenigstens etwas halbwegs kompetentes zum Thema beitragen. :-)
Moby A. schrieb im Beitrag #4625040: > TriHexagon schrieb: >> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher >> zu dem Thema. > > einfach mal zur Kenntnis zu nehmen. Besser wäre "Erkenntnis gewinnen" Leider sind eben 99,99% dieser Seiten für "Zur-Kenntnis-Nehmer" geschrieben. Zudem kann man doch nicht OOP dafür verantwortlich machen, daß ein so geringer Anteil der IT-Schaffenden sie zur Lösung von Problemen einzusetzen versteht. Ich entwickle täglich mit OO die Software, die mir einen Lebenunterhalt verdient. Und dann bin ich ja Anwender der üblichen PC-Software-Verdächtigen, Moby A. schrieb im Beitrag #4625040: > Damit muß dann um die Ecke gedacht werden. Alles im lächerlichen Namen der > Vereinfachung? die MS aus welchen Gründen auch immer, durch "Um-die-Ecke-Denken" programmiert. Vielleicht sind diese Ecken ja für manche sehr straight und nur für die Anderen ein Hindernis beim Denken.
Um mal wieder auf den Ausganspost zurück zu kommen: Christian M. schrieb: > Hallo Programmierer, Bin ich nicht, aber ich habe in meinem langen Leben schon viele Zeilen Software entwickelt. Ziemlich viele, und in verschiedensten Sprachen. > ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir > erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. > Kann mir einer verklickern, wofür das gut sein soll? > Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden, > komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern? Naja. Das Grundproblem bei dir ist wahrscheinlich, daß man dir eine an sich gute Sache (OOP) anhand einer totalverkackten 'Programmiersprache' (JS) beibringen will. Das muß zwangsläufig zu Abwehrreaktionen führen! > Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String > manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die > Zahl das Objekt sein...?! Und da hast du schon die Depperei entdeckt. In anderen Sprachen bindet man z.B. die math.h ein, um die Bibliotheksfunktionen zu nutzen, oder man hat 'Zahlenobjekte' einer Klasse, die von selber die höheren Funktionen kann. Das math von JS ist kein Objekt, sondern eine Krücke. Nun gut, in der realen Welt ist auch die Krücke ein reales Objekt... > Intern wird es ja eh prozedural verarbeitet. Am Ende ist alles Assembler. Aber das ist auch nur eine Metaebene, zu guterletzt wird alles in Microcode auf dem Prozessor abgearbeitet. Wer eine Telephonliste von Freunden in Microcode realisieren will, hat meine Hochachtung! Assembler ist ja auch nicht das, was wirklich auf dem Blech abläuft. > Bin ich zu alt? Kann sein... Mit dem Alter kommt die Erfahrung, und man merkt auch leichter, wenn man verarscht wird. Wenn man MIR z.B. auch nur irgendwas neues, aktuelles, hippes mit JS beibringen wollte, dann würde ich von vornherein nur lachen (oder wahlweise abkotzen). Was ist denn das überhaupt für ein bescheuerter Kurs, bei dem man 'programmieren' mit JS lernen soll? Die Dozenten haben als Ausbildung wahrscheinlich auch nur "Webseiten programmieren (sic!) mit JavaScript in drei Wochen" > Gruss Chregu Dito, Baku
@W.S.: Vielen Dank für diese mal anschauliche Erklärung! Nicht dieses "Auto ist rot, Auto hupt"! :-) @Baku M.: Ist der Online-Kurs bei codecademy. HTML/CSS habe ich schon durch, danach folgt dann noch git und noch ein paar. Wenn ich das durch habe, stellt mich eine Firma als Programmierer an. Hobbymäßig habe ich schon ziemlich viel programmiert, auf dem C64 ein bisschen, Z80, 68HC11, Amiga, PIC und PC/Windows. Assembler, BASIC, Arexx, alles ausser C. Gruss Chregu
Sheeva P. schrieb: > Aus dieser FAQ: "Go takes a different approach." > > Ok, "Go verfolgt einen anderen Ansatz". Kein Problem -- aber ein anderer > Ansatz, dem wesentliche Eigenschaften der Objektorientierung fehlen, ist > eben kein objektorientierter Ansatz. Ich verstehe nicht, wie man auf der > einen Seite sagen kann, man habe einen besseren Ansatz gefunden, der dem > OO-Ansatz überlegen sei, auf der anderen Seite aber behauptet, der neue > Ansatz sei in Wirklichkeit dann irgendwie doch objektorientiert, obwohl > dabei wesentliche Teile dessen fehlen, was OO ausmacht. Sorry, aber das > ist doch schizophren. Ein anderer Ansatz muss ja nicht im Wiederspruch zu OO stehen. Es spielt doch keine rolle, ob man es nun Klassen nennt oder wie in go Structtypen. Es spielt keine Rolle, ob man Datentypen funktionen zuordnet, oder man Funktionen datentypen zuordnet. Das resultat ist das selbe, der Ansatz ein anderer, aber OO wiederspricht er nicht zwangslaufig. Baku M. schrieb: > Wenn man MIR z.B. auch nur irgendwas neues, aktuelles, hippes mit JS > beibringen wollte, dann würde ich von vornherein nur lachen (oder > wahlweise abkotzen). > Was ist denn das überhaupt für ein bescheuerter Kurs, bei dem man > 'programmieren' mit JS lernen soll? Du kennst dich mit JS nicht (mehr) aus, glaubst aber alles darüber zu wissen? JS ist auch schon einige Jahre alt, und es hat sich stark verändert. Damals, befor es ES6 gab, war es für OO wirklich unbrauchbar:
1 | "use strict"; // ungetestet |
2 | |
3 | function Person(name){ |
4 | this.name = name; |
5 | }
|
6 | |
7 | Person.prototype.introduce = function introduce(){ |
8 | alert("Hi, I'm "+this.name); |
9 | };
|
Seit ES6 ist es aber gereits ganz brauchbar geworden:
1 | "use strict"; // ungetestet |
2 | |
3 | class Person { |
4 | constructor(name){ |
5 | this.name = name; |
6 | }
|
7 | introduce(){ |
8 | alert("Hi, I'm "+this.name); |
9 | }
|
10 | }
|
Man kann fast alles, was man nativ schreiben kann, auch als webanwendung schreiben. Inklusive 3D Games, Videochat & Verarbeitungsprogramme und co. Zugegebenermassen wird für Dinge, die viel Leistung brauchen haufig von anderen Sprachen nach asmjs übersetzt, aber asmjs ist immernoch ein JS subset. Einige unschönheiten konnte auch ES6 nicht ausbügeln, aber gröstenteils kann es sich sehen lassen.
:
Bearbeitet durch User
Daniel A. schrieb: > Ein anderer Ansatz muss ja nicht im Wiederspruch zu OO stehen. Es spielt > doch keine rolle, ob man es nun Klassen nennt oder wie in go > Structtypen. In C gibt es auch Structs, trotzdem ist es keine OO-Sprache. > Es spielt keine Rolle, ob man Datentypen funktionen > zuordnet, oder man Funktionen datentypen zuordnet. Doch, das sind zwei fundamental unterschiedliche Konzepte. Das eine heißt Datenkapselung, das andere heißt Typsicherheit. Die Datenkapselung ist ein wesentlicher Bestandteil von OO, Typsicherheit nicht. Obendrein unterstützt Go auch keine Vererbung und keinen Polymorphismus. Versteh' mich bitte nicht falsch, ich hab' nichts gegen Go, aber wenn man einen vollkommen anderen Ansatz verfolgt, der nicht einmal eine einzige der wesentlichen Eigenschaften von OO unterstützt, dann ist es keine OO. Darum sollen sich die Go-Leute doch bitte ein anderes Wort ausdenken, anstatt zu versuchen, einen etablierten Fachbegriff umzudefinieren.
Sheeva P. schrieb: > Obendrein unterstützt Go auch keine Vererbung und keinen Polymorphismus. Also eigentlich unterstützt Go Polymorphismus, nämlich mithilfe von Interfaces (in Rust sind es Traits). Das mag vielleicht nicht der klassische Weg sein wie in C++ oder Java, aber praktisch ist es Polymorphismus, schließlich bilden sie eigene Typen. Diese neue, leicht gewichtete Variante von OOP (keine Vererbung) sieht man fast überall bei den neuen Sprachen. Bei Go, Rust ist es so und bei Nimrod scheint es auch so zu sein. Den Ansatz finde ich gar nicht so schlecht, kann mir aber vorstellen, dass man Vererbung vermissen wird. Moby A. schrieb im Beitrag #4625040: > TriHexagon schrieb: >> Du hast schlicht keine Ahnung davon. > > Dazu langt es schon, die nötige Masse von > >> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher >> zu dem Thema. > > einfach mal zur Kenntnis zu nehmen. > Was wird da wohl alles drin beschrieben sein? > Es braucht viele viele Erklärungen. Das bedeutet nichts anderes als daß > hier intuitives prozedurales Denken mit Gewalt umgebogen werden muß. Mit > viel zu vielen neuen Konstruktionen. Damit muß dann um die Ecke gedacht > werden. Alles im lächerlichen Namen der Vereinfachung? > Für viele Anwendungen ist das überflüssig wie ein Kropf... Ne echt > jetzt. Hahaha, also ist jetzt die Anzahl der Literatur, über ein Thema, ein Indikator dafür wie komplex eben dieses ist. Wenn man das so sieht kommt man wohl zur Erkenntnis, dass Kochen komplexer ist als Quantenphysik. Es gibt schließlich viel mehr über das Kochen zu lesen als über Physik. Ne was kann OOP dafür, dass es zigtausend Bücher über den einen gleichen Sachverhalt gibt, obwohl ein einziges Gutes ausreicht? Es gibt auch zigtausend Bücher über C#. Da wird zum Teil beim gleichen Verlag jedes Jahr ein neues rausgehauen, aber sagt es mehr aus oder hat sich was an C# verändert (wohlgemerkt Anfängerbücher)? Nö. Besser sind die auch nicht, nur kann man noch mal Bücher verkaufen, da die Menschen oft glauben, sie brauchen das Neuste. Ich z.B. habe mir nie ein Buch über OOP gekauft, darüber gabs in meinem C# Buch damals zwei oder drei kleine Kapitel, die völlig ausreichend waren, um OOP zu verstehen und anwenden zu können. Das habe ich schon zur Schulzeit gelernt, allein mit einem Buch, so schwer kanns also nicht sein.
TriHexagon schrieb: > Ich z.B. habe mir nie ein Buch über OOP gekauft, darüber gabs in meinem > C# Buch damals zwei oder drei kleine Kapitel, die völlig ausreichend > waren, um OOP zu verstehen und anwenden zu können. Wen dem Einen wie Schuppen aus den Haaren fällt, dafür braucht der Andere eben 5 Mio Bücher - und verzweifelt trotzdem (oder deshalb).
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4624966: > Die sind auch nötig. > Das ist nichts was naturgegeben intuitiv und ohne steile Lernkurve > einfach anzuwenden wär. > OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge > neuer Bürokratie ein. > Das lohnt sich erst bei grösseren Projekten. Einem Teil deiner Sätze stimme ich zu. Für viele Programmierer ist prozedurales Denken und Programmieren die gewohnte Herangehensweise. Kommt vom PAP her. Wer das gar sehr verinnerlicht hat, braucht Zeit und passenden Lesestoff, um den Sinn des Ganzen zu kapieren - es ist nämlich relativ viel. Weiters führt OOP tatsächlich ne Menge neuer Bürokratie ein, jaja, aber zugleich vereinfachen sich die Dinge eben genau dadurch ganz erheblich - vorausgesetzt, man setzt OOP dort ein wo sie sinnfällig ist und nicht fanatisch auf Biegen oder Brechen. Zum Schluß: Es lohnt sich auch bei kleinen Projekten, da kommt es eben auf's Projekt an. Ich habe OOP schon bei vielen µC-Projekten benutzt. In C und mit händisch angefertigten Objekt-Typen. Insbesondere bei Menüsystemen und Grafikdisplays ist sowas ne echte Erleichterung. Für eine ganz kleine Anwendung schau dir die Lernbetty und dort das (ganz simple) Menü an. Ja, diese Minimalst-system hätte man auch anders schreiben können, aber wenn du mal draufguckst, solltest du das Potential erkennen, was da drinsteckt. W.S.
c-hater schrieb: > Für eingefleischte C-ler, die für OOP-Konzepte naturgemäß auf C++ > umsteigen müssten, ist die Hölle definitiv um vieles heisser... Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der ich denke und mich ausdrücke. Um C++ mache ich einen großen Bogen, und das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann.
Dann mal eine Frage an die Profis hier: Wie löst ihr das Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch eine Konfig-Datei festgelegt). Diese Daten beeinflussen ja auch Objekte niedrigster Hierachiestufe. Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn der Hash-Eintrag nicht da ist? Irgendeine statisch-typisierte Lösung? oder ein Factory Pattern? Falls Singleton: wie vermeidet ihr Perfomance-Verluste durch Locks beim Multithreading? Wie löst ihr das, so dass man auch in Zukunft (neue Version braucht z.B. weitere Konfiguration) flexibel bleibt?
nasefuss schrieb: > Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der > ich denke und mich ausdrücke. Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng.
nasefuss schrieb: > das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann Naja.. Man kann da schon einiges machen, aber das ist kein Vergleich zu dem, was man in Pascal mit Delphi/Lazarus und so geboten kriegt. Und eines muß ich mal wieder loswerden: Wer soweit ist, daß er in C Kategorien denkt, der sollte was dagegen tun, Horizont erweitern. W.S.
nenene schrieb: > Dann mal eine Frage an die Profis hier: Wie löst ihr das > Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch > eine Konfig-Datei festgelegt). Vielleicht solltest Du für diese Fragestellung einen eigenen Thread aufmachen. > Diese Daten beeinflussen ja auch Objekte niedrigster Hierachiestufe. Nicht unbedingt. Zunächst einmal gibt es auch konfigurierbare Systeme, deren Software überhaupt gar nicht per OOP implementiert ist... > Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn > der Hash-Eintrag nicht da ist? > Irgendeine statisch-typisierte Lösung? > oder ein Factory Pattern? > > Falls Singleton: wie vermeidet ihr Perfomance-Verluste durch Locks beim > Multithreading? > > Wie löst ihr das, so dass man auch in Zukunft (neue Version braucht z.B. > weitere Konfiguration) flexibel bleibt? ...und um solche Fragen beantworten zu können, müsstest Du näher ausführen was denn nun genau die Anforderungen an das konkrete System sind. Eine pauschale Antwort hierzu wird es vermutlich nicht geben.
:
Bearbeitet durch User
A. K. schrieb: > nasefuss schrieb: >> Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der >> ich denke und mich ausdrücke. > > Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng. Das ist mMn nicht das, was er ausdrücken wollte. Dass man eine Lieblingssprache hat, mit der man am besten klar kommt, ist keinesfalls ungewöhnlich. Auch mir liegt C am ehesten, aber ich mag auch C++ und Java. Python zu lernen habe ich mir seit einer Weile vorgenommen... sollte das endlich mal wahr machen ;-)
:
Bearbeitet durch User
nenene schrieb: > Dann mal eine Frage an die Profis hier: Wie löst ihr das > Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch > eine Konfig-Datei festgelegt). Diese Daten beeinflussen ja auch Objekte > niedrigster Hierachiestufe. > Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn > der Hash-Eintrag nicht da ist? > Irgendeine statisch-typisierte Lösung? > oder ein Factory Pattern? Ehrlich gesagt, habe ich Dein Problem nicht ganz verstanden. Vielleicht magst Du einen eigenen Thread aufmachen und dort dann ein wenig genauer beschreiben, was genau Du machen willst?
nasefuss schrieb: > Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der > ich denke und mich ausdrücke. Um C++ mache ich einen großen Bogen, und > das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann. Du setzt in plain C Vererbung und Polymorphie um? Nicht, dass das nicht wirklich ginge, aber wer kann das dann noch lesen und verstehen? Also: Höchstens als Machbarkeitsstudie interessant und vielleicht, um auch eingefleischten C-lern begreiflich zu machen, was in C++ passiert. Dafür ist es durchaus akzeptabel, ich selber hab' mir die OOP-Sache ja letztlich auch erst wirklich erfolgreich beigebracht, indem ich auf Asm-Ebene verfolgt habe, was da so im Detail passiert. Erst dadurch ist wirkliches Verständnis entstanden und damit die Möglichkeit, den Kram sinnvoll zu nutzen. Diese Umwege haben aber wirklich nur Leute nötig, die von der ein prozeduralen Programmierung kommen. Leute, die direkt von Anfang an OO programmieren, brauchen das nicht. Das Schlimme ist: so gut wie kein Programmieranfänger programmiert wirklich OO, selbst wenn er mit einer OO-Sprache beginnt. Er benutzt i.d.R. vielmehr fertige Klassen, leimt die mit ein bissel prozeduralem Kram zusammen und versteht am Ende einen Scheissdreck davon, wie man OO-Programme schreibt...
Man muss nicht mit OOP aufgewachsen sein, um es als Fortschritt zu sehen. C++ hatte damals etliche Leute recht fix überzeugt (*) und mit Zortech C++ kam auch recht schnell ein guter nativer x86 Compiler raus. Zu diesem Zeitpunkt kannten aber die meisten Leute nur prozedurale Programmierung - die paar Leute mit Smalltalk oder Simula Kenntnissen spielten keine Rolle. *: Freilich nicht unbedingt ohne Kritik. Mit manchen Stellen der Syntax konnte ich mich nach der Lektüre vom Stroustrup nicht anfreunden.
c-hater schrieb: > Du setzt in plain C Vererbung und Polymorphie um? Nicht, dass das nicht > wirklich ginge, aber wer kann das dann noch lesen und verstehen? Ich mache das häufig, der Code wird dadurch strukturierter, besser gekapselt und schlussendlich besser lesbar. Hier mal einige Implementierungsmöglichkeiten, je nach Anwendungsfall kann man es auch anders machen. Beispiel mit Objekten:
1 | // person.h
|
2 | |
3 | #ifndef DPA_PERSON_H
|
4 | #define DPA_PERSON_H
|
5 | |
6 | struct DPA_Person { |
7 | const char* name; |
8 | };
|
9 | |
10 | void DPA_Person_introduce( struct DPA_Person* ); |
11 | |
12 | #endif
|
1 | // person.c
|
2 | |
3 | #include <stdio.h> |
4 | #include <DPA/example/person.h> |
5 | |
6 | void DPA_Person_introduce( struct DPA_Person* person ){ |
7 | printf( "Hi, I'm %s\n", person->name ); |
8 | }
|
Beispiel für Vererbung, der Einfachheit halber ohne virtuelle Methoden:
1 | // developer.h
|
2 | |
3 | #ifndef DPA_DEVELOPER_H
|
4 | #define DPA_DEVELOPER_H
|
5 | |
6 | #include <DPA/example/person.h> |
7 | |
8 | struct DPA_Developer { |
9 | struct DPA_Person person; |
10 | const char* company; |
11 | };
|
12 | |
13 | void DPA_Developer_introduce( struct DPA_Developer* ); |
14 | |
15 | #endif
|
1 | // developer.c
|
2 | |
3 | #include <stdio.h> |
4 | #include <DPA/example/person.h> |
5 | |
6 | void DPA_Developer_introduce( struct DPA_Developer* developer ){ |
7 | printf( |
8 | "Hi, I'm %s from %s\n", |
9 | developer->person->name, |
10 | developer->company, |
11 | );
|
12 | }
|
1 | // main.c
|
2 | #include <DPA/example/person.h> |
3 | #include <DPA/example/developer.h> |
4 | |
5 | int main(){ |
6 | |
7 | Person tom = { |
8 | .name = "tom" |
9 | };
|
10 | |
11 | Developer john = { |
12 | .person = { |
13 | .name = "john" |
14 | },
|
15 | .company = "ABC AG" |
16 | };
|
17 | |
18 | DPA_Person_introduce(tom); |
19 | DPA_Person_introduce(john.person); |
20 | DPA_Developer_introduce(john); |
21 | |
22 | return 0; |
23 | }
|
Ausgabe:
1 | Hi, I'm tom |
2 | Hi, I'm john |
3 | Hi, I'm john from ABC AG |
Anderes Beispiel, ungetestet. Man kann auch einfach so eine art Interface machen und als vtable für Polymorphie verwenden:
1 | // output_device.h
|
2 | |
3 | #ifndef DPA_OUTPUT_DEVICE_H
|
4 | #define DPA_OUTPUT_DEVICE_H
|
5 | |
6 | struct DPA_OutputDevice; |
7 | struct DPA_OutputDeviceInterface { |
8 | void(*init)(struct OutputDevice*); |
9 | void(*print)(struct OutputDevice*,const char*); |
10 | void(*destroy)(struct OutputDevice*); |
11 | };
|
12 | |
13 | struct DPA_OutputDevice { |
14 | const struct OutputDeviceInterface* interface; |
15 | };
|
16 | |
17 | extern const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface; |
18 | |
19 | #endif
|
1 | // terminal_x86.h
|
2 | |
3 | #ifndef DPA_TERMINAL_X86_H
|
4 | #define DPA_TERMINAL_X86_H
|
5 | |
6 | #include <DPA/ExampleOS/output_device.h> |
7 | |
8 | struct DPA_Terminal_x86; |
9 | struct DPA_Terminal_x86_Interface { |
10 | struct DPA_OutputDeviceInterface interface; |
11 | void(*clear)( struct DPA_Terminal_x86* ); |
12 | };
|
13 | |
14 | struct DPA_TerminalCharacter_x86 { |
15 | uint8_t character, |
16 | uint8_t color |
17 | } __attribute__((packed)); |
18 | |
19 | struct DPA_Terminal_x86 { |
20 | union { |
21 | const struct DPA_Terminal_x86_Interface* interface; |
22 | struct DPA_OutputDevice outputDevice; |
23 | };
|
24 | uint_least16_t columns; |
25 | uint_least16_t rows; |
26 | uint_least32_t cursor; |
27 | volatile DPA_TerminalCharacter_x86* buffer; |
28 | };
|
1 | // terminal_x86.c
|
2 | |
3 | #include <string.h> |
4 | #include <DPA/ExampleOS/terminal_x86.h> |
5 | |
6 | static void init( struct DPA_OutputDevice* od ){ |
7 | struct DPA_Terminal_x86* terminal = (void*)od; |
8 | terminal->columns = 80; |
9 | terminal->rows = 25; |
10 | terminal->buffer = *(volatile struct DPA_TerminalCharacter_x86*)0xB8000; |
11 | }
|
12 | |
13 | static void print( struct DPA_OutputDevice* od, const char* text ){ |
14 | struct DPA_Terminal_x86* terminal = (void*)od; |
15 | char character; |
16 | uint_least8_t color = terminal->color; |
17 | uint_least32_t cursor = terminal->cursor; |
18 | uint_least32_t size = terminal->columns * terminal->rows; |
19 | while( character = *text++ ){ |
20 | if( cursor >= size ) |
21 | cursor = 0; |
22 | terminal->buffer[cursor++] = (struct DPA_TerminalCharacter_x86){ |
23 | .character = character, |
24 | .color = color |
25 | };
|
26 | }
|
27 | terminal->cursor = cursor; |
28 | }
|
29 | |
30 | static void clear( struct DPA_Terminal_x86* terminal ){ |
31 | memset( (void*)terminal->buffer, 0, terminal->columns * terminal->rows ); |
32 | }
|
33 | |
34 | static void destroy( struct DPA_OutputDevice* od ){ |
35 | struct DPA_Terminal_x86* terminal = (void*)od; |
36 | (void)terminal; |
37 | }
|
38 | |
39 | const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface = { |
40 | .terminal = { |
41 | .init = init, |
42 | .print = print, |
43 | .destroy = destroy |
44 | },
|
45 | .clear = clear |
46 | };
|
1 | const struct DPA_OutputDeviceInterface* outputDeviceList[] = { |
2 | &DPA_terminal_x86_interface.terminal |
3 | };
|
Nach diesem Muster könnte man beliebig viele DPA_OutputDevice typen definieren und über die DPA_OutputDeviceInterface schnittstelle ansprechen. Alles total übersichtlich und einfach zu verstehen.
A. K. schrieb: > Man muss nicht mit OOP aufgewachsen sein, um es als Fortschritt zu > sehen. C++ hatte damals etliche Leute recht fix überzeugt (*) Interessanterweise scheint es Leuten, die Jahre lang nur prozedural programmiert haben und nichts anderes kennen, schwerer zu fallen OOP zu lernen als diejenigen, die nur OOP gemacht haben, PP zu lernen. @Daniel Abrecht Genau genommen ist das eine Komposition und keine Vererbung. Aber es ist ein gängiger Workaround Vererbung nachzubilden. Ein C++ Compiler dürfte das ungefähr so umsetzten. In Rust setzt man sowas entweder mit einer Komposition um oder man verwendet type aliasing: http://stackoverflow.com/questions/32736170/what-is-the-best-way-to-inherit-a-struct-in-rust-1-3 Man kann in C übrigens auch richtig kapseln, nämlich indem man die Deklaration der Datenstruktur nicht öffentlich macht und Zeiger als Handle verwendet. Nur ausgewählte Funktionen (quasi Methoden) können mit den Daten operieren. foo.h
1 | struct Foo; |
2 | |
3 | Foo* foo_create(); |
4 | void foo_doThis(Foo* foo); |
5 | void foo_doThat(Foo* foo); |
foo.c
1 | #include "foo.h" |
2 | |
3 | struct Foo { |
4 | int a; |
5 | //...
|
6 | };
|
7 | |
8 | Foo* foo_create() { |
9 | Foo* foo = malloc(sizeof(Foo)); |
10 | //...
|
11 | foo->a = 0; |
12 | //...
|
13 | }
|
14 | |
15 | void foo_doThis(Foo* foo) { |
16 | //...
|
17 | }
|
18 | |
19 | void foo_doThat(Foo* foo) { |
20 | //...
|
21 | }
|
Großer Nachteil dabei ist, dass man die Struktur nicht mehr auf den Stack legen kann. Jedenfalls außerhalb von foo.c.
Daniel A. schrieb: > Alles total übersichtlich und einfach zu verstehen. In C++ wäre es jedenfalls übersichtlicher und einfacher. Genau deswegen mach ich in C kaum noch OOP, weil dann kann ich ja gleich zu C++ greifen, dass mir wiederum auch andere Vorteile bietet.
Über die technischen vor- und Nachteile von OOP kann man lange philosophieren. Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt.
OOP habe ich bisher nur in Delphi benutzt, dort werden Instanzen aber immer dynamisch erzeugt. Auf einen kleinen µC liese sich das nicht übertragen, da ja dann eine Speicherverwaltung/Betriebssystem notwendig wäre. Wie ist das in C++? Ich nehme an, dass dort das statische Anlegen von Instanzen möglich ist?
Tommi schrieb: > C++? Ich nehme an, dass dort das statische Anlegen > von Instanzen möglich ist? Ja.
Tommi schrieb: > OOP habe ich bisher nur in Delphi benutzt, dort werden Instanzen aber > immer dynamisch erzeugt Du kannst auch den Datentyp Object verwenden, dessen Speicherort kannst (musst) Du manuell verwalten, also kannst Du es auch auf dem Stack haben, in dieser Hinsicht verhält sich Object genau wie ein Record..
Man kann C++ vollständig statisch schreiben, ohne auf Grundfunktionen der OOP verzichten zu müssen. Das ist ein Grund, weshalb man es für Mikrocontroller mit sparsamer RAM-Ausstattung verwenden kann, bei denen dynamische Speicherverwaltung nicht in Frage kommt. Man ist dabei natürlich eingeschränkt, aber m.E. besser dran als in C.
:
Bearbeitet durch User
An Python sieht man die Vorteile von OOP ganz gut. Dort sind Datentypen wie Strings oder Listen Objekte und haben Funktionen, die man darauf anwenden kann. Z.B.: https://docs.python.org/3.5/library/string.html https://docs.python.org/3.5/tutorial/datastructures.html
Tommi schrieb: > Ein Beispiel wäre nicht schlecht. > Ich denke dass das nicht ganz offtopic ist. Die Speicherverwaltung der Klasseninstanzen unterscheidet sich in C++ nicht von der Speicherverwaltung von Skalaren, Arrays und Structs (Pascal: Records). Globale instanzen sind statisch und lokale (nichtstatische) Instanzen landen auf dem Stack. Dynamisch alloziert (jenseits des Stacks) wird nur explizit. Natürlich schränkt das ein. So ziemlich jede normale nicht eigens dafür geschriebene C++ Lib kann man bei Verzicht auf den Heap vergessen. Auch wenn das kein typisches OOP Beispiel ist: Für Stringverarbeitung wird man normalerweise dynamischen Speicher verwenden, weil das einfach nahe liegt. Ohne Heap muss man sich ersatzweise eben auf eine Stringverarbeitung verlegen, die mit einer für die jeweilige Instanz definierten maximalen Länge arbeitet und keine temporären Instanzen auf dem Heap benötigt. Man kann aber trotzdem typische Elemente von OOP Sprachstrukturen verwenden, wie etwa heterogene Datenstrukturen über Vererbung. Etwa mehrere verschiedene Typen von Temperatursensoren so zusammenfassen, dass sich zwar die Implementierung unterscheidet, nicht aber die Verwendung. Oder auf ähnliche Art unterschiedlichsten Konfigurationsparametern ein gemeinsames Interface verpassen.
:
Bearbeitet durch User
@A.K. Danke für die Ausführungen! Mit gewissen Vorbehalten gegen C (wofürs ja auf dem Mikrocontrolle kaum eine Alternative gibt), habe ich mich bisher von C++ ferngehalten. Wenn sich eine statische OOP dort aber so einfach umsetzen lässt, ist es doch mal ein Versuch wert.
Schau Dir Arduino an. Dort wird C++ angewendet, soweit es auf kleinen µC Sinn macht.
Sheeva P. schrieb: >> sozusagen eine Memberfunktion von FILE zum Zugriff auf diese >> private Variable. > > In C gibt es keine privaten Variablen. Ja, static existiert, ist aber > was anderes als "private" in C++-Structs oder -Klassen. Was verstehst du am Wort 'sozusagen' nicht ? Übrigens gibt es sehr wohl Impementationen, die FILE in einer Art exportieren, daß die interne Struct darauf gar nicht abgebildet wird. Stefan U. schrieb: > Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode > ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt. Immer diese Laien. Du hast offensichtlich noch nie versucht, ein vo jemand anderem geschriebenes reales OOP (z.B. C++) Programm zu durchblicken oder ? GERADE das was alles 'versteckt' abläuft macht es UNENDLICH SCHWER nachzuvollziehen was das Programm tut (und was man ändern bzw. wie man ergänzen darf ohne es kaputt zu machzen). C ist wesentlich wartungsfreundlicher.
A. K. schrieb: > Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng. Aha, Englisch als Muttersprache, in der Schule Deutsch gelernt und dann in Spanien spanisch gesprochen um im Alter in Griechenland an griechisch-Kursen teilzunehmen. Dein Leben ist nicht das normale Leben.
Michael B. schrieb: > Dein Leben ist nicht das normale Leben. Den Spruch kenn ich schon. Aber damit kann ich leben. ;-) Für seinen Bildungshorizont ist allerdings jeder selbst verantwortlich. Ich bin mir freilich sicher, dass niemand, der mit APL anfängt, ein Leben lang nur bei dieser einen Sprache bleibt. Ebenso jene, die in den 80ern mit dem BASIC des C64 laufen lernten. Wenn das allerdings heissen soll, dass jene, die sich heute als Jungspunde in C stürzen, überwiegend bis zur Rente nur darin verharren werden, dann Amen.
:
Bearbeitet durch User
>> Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode >> ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt. > Immer diese Laien. > Du hast offensichtlich noch nie versucht, Ja laberkopp, wenn du meinst. Dann reichen 20 Jahre Berufserfahrung mit OOP wohl nicht aus, um auf dein Niveau zu kommen.
Stefan U. schrieb: > Ja laberkopp, wenn du meinst. Dann reichen 20 Jahre Berufserfahrung mit > OOP wohl nicht aus, um auf dein Niveau zu kommen. Nein, reichen nicht.
Michael B. schrieb: > Immer diese Laien. > Du hast offensichtlich noch nie versucht, ein vo jemand anderem > geschriebenes reales OOP (z.B. C++) Programm zu durchblicken oder ? > GERADE das was alles 'versteckt' abläuft macht es UNENDLICH SCHWER > nachzuvollziehen was das Programm tut (und was man ändern bzw. wie man > ergänzen darf ohne es kaputt zu machzen). > > C ist wesentlich wartungsfreundlicher. Das ist totaler Unsinn. Den einzigen Laien den ich hier sehe, der bist Du. Du redest abfällig über Dinge über die Du keinen Überblick hast. Ich verwende C++, C und ASM seit Beginn der 90er und nutze es eben da wo es Sinn macht und passt. Solche plumpen Sprüche und dann auch noch andere Laien nennen, weil die die eigene Meinung nicht teilen. Benenne doch mal die Vorteile von C gegenüber C++ bei Großprojekten.
So weit hergeholt mit der Wartungs(un)freundlichkeit bei C++ ist das nicht. Bei fremden Codes ist es durch die virtuellen Methoden und zigfache (Mehrfach) Vererbung manchmal schon unmöglich, allein durch statisches Code-Anschauen rauszufinden, welche der 100 identisch benannten "get/add/etc"-Funktionen am Ende für ein Objekt aufgerufen wird. Klar lässt sich sowas mit einem Debugger rausfinden, aber das ist auch nicht immer so einfach (Echtzeit, ISR, etc.). Da hilft dann nur noch Verstreuen von printf aka neudeutsch "Instrumentierung" ;) Dagegen ist die Code-Vereinfachung durch die Standard-Container mit Templates wirklich sehr schön.
Georg A. schrieb: > So weit hergeholt mit der Wartungs(un)freundlichkeit bei C++ ist das > nicht. Bei fremden Codes ist es durch die virtuellen Methoden und > zigfache (Mehrfach) Vererbung manchmal schon unmöglich [..] > Klar lässt sich sowas mit einem Debugger rausfinden, aber das ist auch > [..] Schlechter und unübersichtlich aufgebauter Quellcode ist immer wartungsunfreundlich, egal in welcher Sprache. C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw. keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt die man nicht verstanden hat, dann sollte man es auch nicht verwenden. ;-)
> Schlechter und unübersichtlich aufgebauter Quellcode ist immer > wartungsunfreundlich, egal in welcher Sprache. Das komische ist aber gerade bei C++, dass selbst bei nur einem Autor die Einzelklassen "schön" und strukturiert aussehen können, aber dann das Gesamtkonstrukt gerade wegen den anonymen Objekten nicht mehr durchschaubar ist. So extrem ist mir das noch bei keiner anderen Sprache aufgefallen. Bei Perl oder C sieht man schon an einem File aus dem Projekt, ob alles Schrott ist ;)
Chris F. schrieb: > Schlechter und unübersichtlich aufgebauter Quellcode ist immer > wartungsunfreundlich, egal in welcher Sprache. Sicher, bloss lässt sich C++ besser zur obfuscation einsetzen als C. In C muss man wenigstens hinschreiben, wenn was passieren soll, an der Stelle wo es passiert, und das hingeschriebene ist eindeutig. In C++ holen sich die jüngsten Coder einen runter was sie heute wieder an neuesten Quirks gelernt haben, die sie sofort einsetzen müssen, um ihre eigene eingebildete Überlegenheit vor allen anderen Programmierern zu zeigen. Das geht so weit, daß der modernere C-Compiler die Konstrukte des alten nicht mehr übersetzen kann. Die Regel "Benutze nie mehr als nötig" wurde in C++ noch nie befolgt. Es hat seinen Grund, warum heutige Programme grottig langsam und fehlerhaft schlecht sind, Scrum alleine ist nicht an allem schuld. > C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine > sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw. > keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt > die man nicht verstanden hat, dann sollte man es auch nicht verwenden. Was hilft das, wenn du ein Programm von einem anderen bekommst ? Das ist leider die Realität im Business. Wirst du auch noch lernen, wenn du aus der Schule kommst.
Michael B. schrieb: >> C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine >> sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw. >> keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt >> die man nicht verstanden hat, dann sollte man es auch nicht verwenden. > > Was hilft das, wenn du ein Programm von einem anderen bekommst ? Das ist > leider die Realität im Business. Wirst du auch noch lernen, wenn du aus > der Schule kommst. Beides ist richtig. Es gibt leider viele Firmen, die qualitativ schlechten Sourcecode akzeptieren. Meistens weil die Entscheidungsträger sowieso nicht verstehen wie qualitativ gute Software denn aussieht.
Michael B. schrieb: > Sicher, bloss lässt sich C++ besser zur obfuscation einsetzen als C. > [..] > In C++ holen sich die jüngsten Coder einen runter was sie heute wieder > an neuesten Quirks gelernt haben, die sie sofort einsetzen müssen, um > [..] > Die Regel "Benutze nie mehr als nötig" wurde in C++ noch nie befolgt. Es > [..] > leider die Realität im Business. Wirst du auch noch lernen, wenn du aus > der Schule kommst. Besser kann man nicht zeigen, dass man noch nie im professionellen Umfeld mit C++ gearbeitet hat. Beantworte bitte meine Frage und benenne die Vorteile von C gegenüber C++ in großen Projekten. Wie wurde da in der Architekturplanung vorgegangen und warum ist das dann in C++ schlechter?
Michael B. schrieb: > Sheeva P. schrieb: >>> sozusagen eine Memberfunktion von FILE zum Zugriff auf diese >>> private Variable. >> >> In C gibt es keine privaten Variablen. Ja, static existiert, ist aber >> was anderes als "private" in C++-Structs oder -Klassen. > > Was verstehst du am Wort 'sozusagen' nicht ? Das Wort kenne ich, aber hier ist es falsch. Es gibt eine Definition, was eine Memberfunktion ist. fileno(3) ist keine, auch nicht "sozusagen". Es gibt auch eine Definition, was eine private Variable ist. Eine Variable in einem C-Struct ist keine, auch nicht "sozusagen".
Chris F. schrieb: > Beantworte bitte meine Frage und benenne die Vorteile von C gegenüber > C++ in großen Projekten. Deine Frage wurde beantwortet, aber du verstehst es nicht, was soll man da noch dazu schreiben ? Der erste wichtige Unterschied liegt darin begründet, daß man ein grosses C Programm lesend verstehen kann, während man ein C++ Programm debuggen muss um nachvollziehen zu können, was an einigen Stellen passieren mag. Bei Projekten, die mehr als 1 Person erfordern, so daß die anderen niemals das ganze Programm lesen und überblicken können, ist das immanent wichtig. So lange du zu Hause nur deine kleinen Projekte machst, ist es natürlich egal. Man kann sich auch in C++ beschränken und Konstrukte nur dort einsetzen wo sie gut und sinnvoll sind. Tut aber keiner, zumindest kein C++ Verfechter. So ist leider die Realität, und dazu muss man keinen Code von indischen Softwareentwicklern bekommen, dazu reichen die deutschen Uniabsolventen schon aus.
Sheeva P. schrieb: > Das Wort kenne ich, aber hier ist es falsch. Das Wort ist keineswegs falsch, sondern: Lässt man das Wort weg, wäre der Satz falsch. Da du geistig offenbar nicht in der Lage bist das Wort richtig einzuordnen und es einfach überliest als ob es nicht da wäre, kommst du fälschlicherweise zu der Schlussfolgerung, der Satz wäre falsch. Andere Leute sagen dazu;: Du bist dumm. Aber es mangelt dir nicht an Selbstüberheblichkeit den Fehler anderen Leuten zuzuordnen.
Mark B. schrieb: > Es gibt leider viele Firmen, die qualitativ schlechten Sourcecode > akzeptieren. Meistens weil die Entscheidungsträger sowieso nicht > verstehen wie qualitativ gute Software denn aussieht. Es gibt viele Firmen, deren Mitarbeiter den schlechten Code massenhaft produzieren (kein Wunder, wenn man z.B. die Leistung von Programmierern in der Anzahl geschriebener Zeilen bewertet, oder ihnen in Scrum pro Sprint mehr abgearbeitete Änderungen abverlangt). Gute Software habe ich schon lange nicht mehr gesehen. Dabei bin ich nicht besonders anspruchsvoll: Den Source Code von CP/M, GEM und Windows 3.1 beispielsweise kann ich durchaus als gut gelten lassen. Abschreckende Beispiele waren MFC, PGP und OpenOffice Calc. Google Chrome beispielsweise ist nicht mal wirklich schlecht, aber unendlich aufgebläht durch den typischen C++ Effekt. Funktionen die fast nichts tun, nur weiterleiten um die (Zugriffs- Aufruf- Typen-) Beschränkungen von C++ zu umgehen.
:
Bearbeitet durch User
Michael B. schrieb: > Der erste wichtige Unterschied liegt darin begründet, daß man ein > grosses C Programm lesend verstehen kann, während man ein C++ Programm > debuggen muss um nachvollziehen zu können, was an einigen Stellen > passieren mag. Tatsächlich? ;-) Ich denke, dass könnte vielleicht auch daran liegen, dass C-Konstrukte wesentlich einfacher zu verstehen sind. Bei C++ dagegen wird man allein von den syntaktsichen Möglichkeiten erschlagen (C++11... läßt auch Grüßen). Selbst wenn man den Überblick hat, sich auch in STL und Boost eingearbeitet hat, braucht es einiges an praktischer Erfahrung, um mit C++ sinnvoll zu arbeiten (und anderen Code zu verstehen). Daher sind bei C++ im Unternehmen Schulungen und Coding Guidelines ein wichtiger Faktor. Richtig angewand kann man die (umfangreichen) Vorteile der Sprache nutzen. Und mit vernünftigen Design, lassen sich (imho) C++ Programme (viel!) besser verstehen als C Programme. "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." [Bjarne Stroustrup]
Mikro 7. schrieb: >> Der erste wichtige Unterschied liegt darin begründet, daß man ein >> grosses C Programm lesend verstehen kann, während man ein C++ Programm >> debuggen muss um nachvollziehen zu können, was an einigen Stellen >> passieren mag. > > Tatsächlich? ;-) Na ja, warscheinlich ist es mal wieder das kleine, feine, gut Dokumentierte, dessen Funktionen ausschließlich gut benamst sind, C - Programm. Und gegen dieses muss das große, aufgeblähte, mit grauenvoll benamsten Klassen, die über tausende Zeilen groß sind antreten. Kein Wunder das da OOP "verliert" PS: C++ ist eine grauenvolle Sprache. Da gibts wesentlich bessere, aber darum gehts hier ja nicht ^^
Was hier als "Argumente" gebracht wird ist wie früher die Diskussion ob man auf dem Amiga Makroassembler (lang lebe OMA2 ;-)) oder bei PC-Programmen Pascal oder C verwenden sollte um Anwendungen zu schreiben, weil reiner Assembler ja viel besser sei und solche "Skriptsprachen" total lame und die Compiler total viel unnötiges Zeug einfügen. (bitte entsprechende newsgroup- und irc-flame Diskussionen hier einfügen) Weil etwas mehr Möglichkeiten bietet als etwas anderes, bietet es auch mehr Möglichkeiten Unfug zu machen. Aber deswegen ist es nicht direkt schlecht, es bedarf eben mehr Sorgfalt und Richtlinien/Absprachen und einer ordentlichen Architektur. Wenn ein Substandardprogrammierer, der nicht lernwillig ist, sich aus ideologischen Gründen auf einzelne Programmiersprachen beschränkt ist das sein Ding. Wenn er Code in einer Sprache die er nicht lernen und begreifen will (oder kann) für unlesbar hält ist das auch sein Ding. Hellhörig werde ich immer wenn ich so Sprüche höre wie: "solange du/man zu hause die kleinen Projekte" oder wenn eine gegensätzliche Ansicht geäußert wird: "du bist ja geistig nicht in der Lage die Wahrheit zu sehen"/"Du bist dumm", wenn eine Sprache starke Typisierung und Zugriffsbeschränkungen ermöglicht: "Es müssen Funktionen gebaut werden die mit Murks die Zugriffsbeschränkungen aufheben" Die Frage müsste lauten: "Warum hat wohl der Ersteller dieser Bibliothek da Zugriffsbeschränkungen eingebaut?" Für Substandardprogrammierer die weder Bock auf Lernen oder Selbstreflektion haben, ist das dann so wie bei MFC oft gesehen: Beschränkungen werden weggecastet, dadurch Zugriff auf Ecken wo der User nicht dransollte, komische Fehlermeldungen, Linkerfehler, so kommt er dann zum persönlichen Fazit: MFC/C++/Windows/Microsoft ist alles Scheisse obwohl es daran liegt, dass er es nicht bedienen kann oder lernen will. In reinem C ist es übrigens noch VIEL schlimmer wenn man sich nicht an den Aufbau von komplexen Frameworks hält und mit deren Eigenheiten lebt. Das ist z.B. bei gängigen Linuxtools so, wer eine stored-procedure für eine Datenbank, ein Kernel- oder Webserver-Modul bauen will, der wird zu Vorgehensweisen gezwungen die total nebulös sind, verwendet Schnittstellen die aus Rohdatenstrukturen, Funktionszeigercallbacks usw... bestehen und muss die darunterliegende Struktur wie ein rohes Ei behandeln. Wenn nun eine Sprache daherkommt die das alles durch Sprachmittel und Compilerprüfungen vereinfacht, dann ist das für große Projekte mit einem Zeitplan und Budget ein Segen und sorgt für bessere Resultate mit weniger eigenem, zu wartenden, Code.
Michael B. schrieb: > Sheeva P. schrieb: >> Das Wort kenne ich, aber hier ist es falsch. > > Das Wort ist keineswegs falsch, sondern: > Lässt man das Wort weg, wäre der Satz falsch. Der Satz bleibt auch mit dem Wort falsch. > Da du geistig offenbar nicht in der Lage bist das Wort richtig > einzuordnen und es einfach überliest als ob es nicht da wäre, kommst du > fälschlicherweise zu der Schlussfolgerung, der Satz wäre falsch. Deine Pöbeleien ändern nichts daran, daß der Satz falsch ist. > Andere Leute sagen dazu;: Du bist dumm. > Aber es mangelt dir nicht an Selbstüberheblichkeit den Fehler anderen > Leuten zuzuordnen. Solange es reicht, C++ auch ohne Debugger zu verstehen, ist Dein kindisches Gepöbel nur eine Aussage über Dich selbst. Lustig! :-)
> daß man ein grosses C Programm lesend verstehen kann, > während man ein C++ Programm debuggen muss Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++ nicht beherrschen.
Stefan U. schrieb: >> daß man ein grosses C Programm lesend verstehen kann, >> während man ein C++ Programm debuggen muss > > Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++ > nicht beherrschen. Jein. Man kann in jeder Sprache schlechten Code schreiben. Also auch in C. Also auch in C++. Und schlechter Code ist eben oft schwer zu verstehen.
Mark B. schrieb: > Stefan U. schrieb: >>> daß man ein grosses C Programm lesend verstehen kann, >>> während man ein C++ Programm debuggen muss >> >> Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++ >> nicht beherrschen. > > Jein. Man kann in jeder Sprache schlechten Code schreiben. Also auch in > C. Also auch in C++. Und schlechter Code ist eben oft schwer zu > verstehen. Die Aussage war aber: in C++ ist es IMMER unlesbar. Der Trugschluß ist wahrscheinlich C++ sieht doch aus wie C, also muß ich das nach 20 Jahren C verstehen und wenn nicht, liegt's an C++. Und wer ersthaft meint per Debugger zu verstehen, was er als C++ nicht versteht, der hat noch nie gesehen, was ein ordentlicher Compiler so an Code generiert.
:
Bearbeitet durch User
Kurz ausgedrückt: Was ich nicht verstehe, das taugt nichts.
Carl D. schrieb: > Die Aussage war aber: in C++ ist es IMMER unlesbar. Das stimmt so natürlich nicht - klar. A. K. schrieb: > Kurz ausgedrückt: Was ich nicht verstehe, das taugt nichts. Und wenn der Bauer nicht schwimmen kann, liegt es an der Badehose. ;-)
Sheeva P. schrieb: >> Andere Leute sagen dazu;: Du bist dumm. > Solange es reicht, C++ auch ohne Debugger zu verstehen, [...] Made my day ... lol
Michael B. schrieb: > C ist wesentlich wartungsfreundlicher. .. als C++ Ja, sehe ich genauso. Der Grund liegt aber nicht in der OOP, sondern darin, wie das Ganze in C++ umgesetzt worden ist. Anstatt mal endlich sinnvolle und merkbare Schlüsselwörter einzuführen, hat Stroustrup wieder mal in die typische C Kiste gegriffen und doppelte Doppelpunkte, Tilden vor Methoden und eine Menge Automatismen eingeführt, die man sich alle merken muß, um damit nicht auf die Fresse zu fliegen. Stroustrup hat's übertrieben - und zwar in die falsche Richtung. Ich hab ihn seit Jahren im schrank stehen und schon etliche Male darüber den großen Brechreiz bekommen. Nein, C++ nicht mit mir. Ich vergleiche das mit dem Ansatz von Pascal und finde letzteren um Größenordnungen besser, sauberer strukturiert, lesbarer. A. K. schrieb: > Wenn das allerdings heissen soll, dass jene, die sich heute als > Jungspunde in C stürzen, überwiegend bis zur Rente nur darin verharren > werden, dann Amen. AMEN. kruzisakramenzifix AMEN. Ich sehe da kein Licht am Horizont. Mit Pascal wäre das kein Problem gewesen, Pascal ist flexibel genug für Zukünftiges. Aber die Jungspunde wollen ja nichts als C können und alle bisherigen Versuche, aus dieser Furche herauszukommen, sind an zu kleinem geistigen Horizont gescheitert. Das sieht alles wie ein bissel durchgemangeltes C aus, wo ohne jegliche Fortune alle häßlichen Altlasten von C beibehalten wurden. Ich vergleiche das mal mit dem Versuch, vom Turnschuh wegzukommen, indem man hinten nen Stöckel-Absatz drannagelt. Sorry, ein eleganter Pumps wird auf solche Weise nicht draus. Höchstens eine Botte, mit der man auf die Nase fällt. Also bleibt es bis auf nicht absehbare Zeiten eben beim ollen häßlichen C und all seinen Unzulänglichkeiten. W.S.
W.S. schrieb: > Michael B. schrieb: >> C ist wesentlich wartungsfreundlicher. > > .. als C++ > Ja, sehe ich genauso. Der Grund liegt aber nicht in der OOP, sondern > darin, wie das Ganze in C++ umgesetzt worden ist. Anstatt mal endlich > sinnvolle und merkbare Schlüsselwörter einzuführen, hat Stroustrup > wieder mal in die typische C Kiste gegriffen und doppelte Doppelpunkte, > Tilden vor Methoden und eine Menge Automatismen eingeführt, die man sich > alle merken muß, um damit nicht auf die Fresse zu fliegen. > > Stroustrup hat's übertrieben - und zwar in die falsche Richtung. Ich hab > ihn seit Jahren im schrank stehen und schon etliche Male darüber den > großen Brechreiz bekommen. Nein, C++ nicht mit mir. Ich vergleiche das > mit dem Ansatz von Pascal und finde letzteren um Größenordnungen besser, > sauberer strukturiert, lesbarer. Das ist aber nur eine Frage Deines persönlichen Geschmacks, über den sich bekanntlich nicht streiten läßt, und somit kein technisches oder in einer anderen Weise sachliches Argument. Bei mir sieht es anders aus: ich habe keine Angst vor Tilden, Doppelpunkten und anderen Sonderzeichen (solange wir hier nicht über APL reden... :-)) und finde Pascal schwer lesbar, was höchstwahrscheinlich daran liegt, daß ich seit dreißig Jahren nichts mehr damit gemacht habe. In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar, wenn man nicht daran gewöhnt ist. Wie sonst wäre es zu erklären, daß es dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen: C++, na klar, aber auch Java, Perl, ECMAScript, R, Google Go, PHP, sowie etwa 60 andere. Das hätten die Autoren dieser Sprachen sicherlich nicht gemacht, wenn sie die Syntax als schlecht lesbar empfunden hätten. Man kann sicher trefflich über die Designentscheidungen von Stroustrup und den Standardisierungsgremien philosophieren, allein: es nutzt nichts. Die Designentscheidungen sind nun einmal gemacht, und sich darüber zu ärgern, kann und wird nichts mehr daran ändern. Jetzt hat man als Entwickler die Wahl: entweder, man findet Dich mit den Gegebenheiten ab, oder man läßt es bleiben und sucht sich die Nische, in der man mit einer Sprache und Syntax arbeiten kannst, die einem eher zusagen. > Ich sehe da kein Licht am Horizont. Mit Pascal wäre das kein Problem > gewesen, Pascal ist flexibel genug für Zukünftiges. > > Aber die Jungspunde wollen ja nichts als C können und alle bisherigen > Versuche, aus dieser Furche herauszukommen, sind an zu kleinem geistigen > Horizont gescheitert. Das liegt keineswegs am geistigen Horizont -- eine Unterstellung, die Du Dir gerne hättest verkneifen können --, sondern an einem anderen Grund: nämlich daran, daß C nunmal der etablierte Industriestandard ist, und es Unmengen von Code, Libraries etc. dafür gibt. Das sind nunmal handfeste, sachliche und technische Gründe, die eindeutig für C sprechen, auch wenn die Pascal-Freunde das nicht gerne hören.
Man sollte halt auch Bedenken, daß bei C++ eine der wichtigsten
Designentscheidung war, kompatibel zu C zu sein. Was kein Problem
darstellen muß. Zudem gibt es ein C++-Kommitee, daß lange ringt, bis
neue Features implementiert werden. Und wenn dann so was wie das
Umdeuten eines Keywords wie bei "auto" ansteht (das ist in 2 Jahrzehnten
der einzige Fall), dann werden vorher alle verfügbaren Sourcen
gescanned, um abzuklären ob das geht.
Und für alle, denen OO mit C++ zu kryptisch ist, gibt es auch
Object-FORTRAN oder noch besser Object-COBOL, da kann man dann auch
Romane schreiben.
> Und wenn der Bauer nicht schwimmen kann, liegt es an der Badehose. ;-)
Ist doch klar. Was denn sonst. Schließlich leben wir doch gerade in
einer Phase, in der, wenn man sich verzockt hat, immer alle anderen
Schuld sind.
Sheeva P. schrieb: > Das ist aber nur eine Frage Deines persönlichen Geschmacks, über den > sich bekanntlich nicht streiten läßt, und somit kein technisches oder in > einer anderen Weise sachliches Argument. Ich teile die Kritik an C++ seitens W.S., verstehe aber auch den Ansatz von Stroustrup. Die Syntax ist an mehreren Stellen übel verkrampft und auch zweideutig. Die Grundstruktur der Sprache sorgt für unnötig schlechte Lesbarkeit, aufgrund verkorkster Deklarationstechnik. Das ist freilich kein Fehler von C++, sondern ein Erbe von C, das durch die Komplexität von C++ verstärkt auftritt. Hätte Stroustrup aber eine syntaktisch völlig neue Sprache definiert, es wäre ihm wahrscheinlich so ergangen wie Wirth. Viel Lob aus den Rängen der Akademie, wenig Erfolg in der Masse. > Bei mir sieht es anders aus: > ich habe keine Angst vor Tilden, Doppelpunkten und anderen Sonderzeichen > (solange wir hier nicht über APL reden... :-)) Ich favorisiere zwar eine klarere eher wortorientierte Ausdrucksweise, kann aber mit Sonderzeichen leben. APL mag mich in Aspekten wie räumlichem Denken bei der Programmierung beeinflusst haben, aber weder in der Ausdrucksform der Sprache noch in der Strukturierung von Programmen. Das ist aber auch nicht der Punkt. (NB: Ich tippe Worte schneller als den Salat aus AltGR-Sonstwas auf deutscher Tastatur, weshalb ich lange Zeit US-Layout vorzog). Zu den Fehlern von C und damit C++ gehört die Deklarationssyntax. Statt dem C'schen hin- und her mit Hilfe von Vorrangtabellen, über das Anfänger immer und manche ein Leben lang stolpern, gehört sich so etwas linear von links nach rechts, oder von mir aus auch umgekehrt. Dass ich mit dieser Ansicht nicht allein bin zeigt GO, denn das adressiert u.A. genau diesen Punkt, ohne sich syntaktisch allzu radikal von C zu lösen. > In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar, > wenn man nicht daran gewöhnt ist. Wie sonst wäre es zu erklären, daß es > dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen: Das ist weniger der Qualität zuliebe so, als aus der Erkenntnis abgeleitet, dass viele Leute eine ihnen bekannt vorkommende Syntax präferieren. > Die Designentscheidungen sind nun einmal gemacht, und sich > darüber zu ärgern, kann und wird nichts mehr daran ändern. Die normative Kraft des Faktischen. > Jetzt hat man > als Entwickler die Wahl: entweder, man findet Dich mit den Gegebenheiten > ab, oder man läßt es bleiben und sucht sich die Nische, in der man mit > einer Sprache und Syntax arbeiten kannst, die einem eher zusagen. Ja. > Das liegt keineswegs am geistigen Horizont Der Begriff "Bildungshorizont" kam ursprünglich von mir, nicht von W.S. Und ich stehe dazu, zumindest im Kontext eines studierten Informatikers. So jemand sollte ein Spektrum von Sprach-Paradigmata kennengelernt haben. Und damit meine ich nicht so sehr C vs Pascal, oder C++ vs Java, denn die unterscheiden sich in dieser Hinsicht nicht voneinander. Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale Sprachen mit Skalaren als dominanten Datentypen. IMHO ist dies auch so etwas, das Informatik von Programmieren unterscheidet. > Das sind nunmal handfeste, sachliche und technische Gründe, > die eindeutig für C sprechen, auch wenn > die Pascal-Freunde das nicht gerne hören. Natürlich. Weshalb ich u.A. C und C++ verwende. Dass ich zwar gelegentlich als Kritiker von C auftrete, mir diese Sprache aber keineswegs fremd ist, dürften manche hier schon gemerkt haben. ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar, > wenn man nicht daran gewöhnt ist. Japaner jonglieren mit 4 verschiedenen Schriftsystemen im gleichen Text, in 3 verschiedenen Paradigmata, von denen die komplexeste Schrift eigentlich überhaupt nicht zur Sprache passt. Und das völlig selbstverständlich, jedenfalls bei ausreichender Bildung. Das heisst aber bloss, dass Menschen mit ausreichend Aufwand auch arg unpraktische Systeme zu beherrschen in der Lage sind. Nicht aber, dass man - wenn man die Wahl hat - so etwas anstreben sollte.
A. K. schrieb: > Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden > Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale > Sprachen mit Skalaren als dominanten Datentypen. Natürlich. Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die damit untergegangen sind. Die taugen höchsten in Nischen als Macrosprache (Emacs, AutoCad) oder Rule-Engine. Die Wahl der falschen Sprache kann also sehr wohl fatal sein, obwohl alles Turing vollständige Sprachen sind, also leistungsmässig äquivalent. W.S. schrieb: >> C ist wesentlich wartungsfreundlicher. > > .. als C++ > Ja, sehe ich genauso. Psssst, das darfst du hier nicht sagen. Die Anderen hier sehen gar nichts.
Moby A. schrieb im Beitrag #4629249: > Ob dieser Hinweis hier wirklich bei jedem auf fruchtbaren Boden fällt? > Manch einer betrachtet gerade die lernintensiven "arg unpraktischen" > Systeme mit ihrer komplizierteren Herangehensweise als der Weisheit > letzten Schluß. Komplexität (= flexiblere Realisierungsformen) wird hier > geradezu angehimmelt als Wert an sich. . > Ausgeblendet wird dabei mal eben der höhere "Verwendungs-Aufwand" = der > Aufwand, das nötige Wissen zur Anwendung zu erwerben und dieses immer > wieder wirklich richtig einzusetzen. Mit höheren Ansprüchen dünnt die > Spitze der "Könner" aber aus und das Mittelmaß bestimmt öfter die > Landschaft. Mit Mittelmaß wiederum büßen Systeme mit hohen Ansprüchen an > möglicher Effizienz ein. . > Ausgeblendet wird schließlich in den Fokus zu nehmen, wieviel > Komplexität die konkrete Anwendung vielleicht gerade nur zu ihrer > Umsetzung benötigt. > > Solche "arg unpraktischen" Systeme können je nach Anwendungsfall sein: > OOP (vs. prozedural) oder auch 32-Bit (vs. 8-Bit) bzw. im Bedienkomfort > Linux (vs. Windows). Schreibt einer, der sich laut anderem Thread einen hochkomplexen 32bit Rechner zulegt und dann schon beim Passwort eintippen vor großen Problemen steht: "da werden ja gar keine Zeichen angezeigt". Aber schön, daß hier auch die unbeleckten mitschreiben dürfen.
:
Bearbeitet durch User
A. K. schrieb: > Hätte Stroustrup aber eine syntaktisch völlig neue Sprache definiert, es > wäre ihm wahrscheinlich so ergangen wie Wirth. Viel Lob aus den Rängen > der Akademie, wenig Erfolg in der Masse. Es ging darum, C mit OO zu erweitern und dabei trotzdem, soweit möglich, kompatibel zu C zu bleiben, mit allen Implikationen, die die Erweiterung einer existierenden Sprache nunmal hat. So gesehen, mögen die Ergebnisse von Stroustrup und Co. nicht perfekt sein, aber bezüglich der gewünschten Ziele ist das Ergebnis ziemlich gut. > Zu den Fehlern von C und damit C++ gehört die Deklarationssyntax. Statt > dem C'schen hin- und her mit Hilfe von Vorrangtabellen, über das > Anfänger immer und manche ein Leben lang stolpern, gehört sich so etwas > linear von links nach rechts, oder von mir aus auch umgekehrt. Dass ich > mit dieser Ansicht nicht allein bin zeigt GO, denn das adressiert u.A. > genau diesen Punkt, ohne sich syntaktisch allzu radikal von C zu lösen. Go hat auch fünf verschiedene Vorränge, ok, C kennt 15. Aber bei Software ohne mathematischen oder statistischen Hintergrund ist das doch wohl eher nebensächlich; die meisten Entwickler, die ich kenne, benutzen an dieser Stelle im Zweifelsfall einfach Klammern. >> Die Designentscheidungen sind nun einmal gemacht, und sich >> darüber zu ärgern, kann und wird nichts mehr daran ändern. > > Die normative Kraft des Faktischen. Ja, genau. Gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden. > Und ich stehe dazu, zumindest im Kontext eines studierten Informatikers. > So jemand sollte ein Spektrum von Sprach-Paradigmata kennengelernt > haben. Und damit meine ich nicht so sehr C vs Pascal, oder C++ vs Java, > denn die unterscheiden sich in dieser Hinsicht nicht voneinander. > Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden > Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale > Sprachen mit Skalaren als dominanten Datentypen. IMHO ist dies auch so > etwas, das Informatik von Programmieren unterscheidet. Tja, ich bin kein studierter Informatiker und habe trotzdem verschiedene Paradigmen kennengelernt. Da die verbreiteten Sprachen aber alle mehrere Paradigmen unterstützen, ist das eher von akademischem Interesse. In der Praxis werden Paradigmen oft parallel genutzt. Warum auch nicht? >> Das sind nunmal handfeste, sachliche und technische Gründe, >> die eindeutig für C sprechen, auch wenn >> die Pascal-Freunde das nicht gerne hören. > > Natürlich. Weshalb ich u.A. C und C++ verwende. Dass ich zwar > gelegentlich als Kritiker von C auftrete, mir diese Sprache aber > keineswegs fremd ist, dürften manche hier schon gemerkt haben. ;-) Kein Zweifel daran. Aber Deine Kritik ist ja auch fundiert und sachlich, und genau das ist der kleine, feine Unterschied. ¦-)
Moby A. schrieb im Beitrag #4629249: > Manch einer betrachtet gerade die lernintensiven "arg unpraktischen" > Systeme mit ihrer komplizierteren Herangehensweise als der Weisheit > letzten Schluß. Sicher nicht. Wenn es morgen eine einfachere Möglichkeit gibt, dann bin ich der Erste, der sie adoptiert. Für professionelle Entwickler geht es immer nur um Effizienz, alles andere ist nebensächlich. > Komplexität (= flexiblere Realisierungsformen) wird hier > geradezu angehimmelt als Wert an sich. Nö. > Ausgeblendet wird dabei mal eben der höhere "Verwendungs-Aufwand" = der > Aufwand, das nötige Wissen zur Anwendung zu erwerben Den leistet man genau ein einziges Mal.
Michael B. schrieb: > Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare > Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die > damit untergegangen sind. Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei denen wesentliche Teil der geschäftskritischen Software in Smalltalk implementiert sind. > Die Wahl der falschen Sprache kann also sehr wohl fatal sein, Das mag ja gerne sein, aber auf OO im Allgemeinen und C++ im Besonderen trifft das zweifellos nicht zu. Erfreulich, daß Du auch in der Sache etwas beitragen kannst. :-)
Sheeva P. schrieb: > Go hat auch fünf verschiedene Vorränge, ok, C kennt 15. Bei der Deklaration verwendet man besser überhaupt keine. Es geht mit um den Unterschied zwischen sowas wie der C Notation int (*a)[5] int *b[5] und der wesentlich leichter linear von links nach rechts lesbaren Schreibweise a: pointer to array[5] of int b: array[5] of pointer to int oder der dazu analogen an C orientierten Kurzschrift von Go a *[5]int b [5]*int Um die C Deklaration zu entschlüsseln benötigt man nicht nur Prioritäten, sondern muss überhaupt erst einmal rausfinden, wo man anfangen muss. Man muss einen komplexen Parser im Kopf trainieren, statt einfach von links nach rechts zu lesen. Oben ist es noch relativ klar, man fängt beim Namen der Variablen an und handelt sich entlang der Prioritäten nach aussen. In der Syntax namenloser Typen (z.B. Casts) wird das schon interessanter: int (*)[5] int *[5] Dazu kommt, dass man in den Pascal/Go Varianten den Namen der Variablen sofort findet, während sich der Name in C irgendwo mittendrin versteckt. Klassendefinitionen in C++ leiden massiv darunter, dass der Name der Variablen und insbesondere der Funktion mitten im Gewirr steckt, schon in relativ einfachen Fällen. Weil der nicht immer sehr kurze Return-Typ der Funktion vorneweg steht, und die Parameter dahinter. Was man nur durch konsequente Formatierung des Quellcodes einigermassen in den Griff kriegt. Name vorneweg, Parameter und Return-Typ dahinter, ist von Haus aus weit übersichtlicher. Ich habe das hier schon aus Faulheit recht einfach gehalten. Noch ein weiteres * oder[] hinzu, angereichert mit const, und der Unterschied in der Lesbarkeit wird noch wesentlich krasser. Es soll C Programmierer geben, die bis an ihr Lebensende nicht wissen, wie man einen konstanten Pointer schreibt. Weshalb man in C gut beraten ist, auf Zwischen-Typedefs zu setzen um das zu zerlegen. @Moby: Bleib in deiner eigenen Welt. Die hier ist nichts für dich. Es geht mir hier um die unterschiedliche Struktur von ggf. auch komplexen Hochsprachen, nicht um Fundamentalkritik an Hochsprachen generell.
:
Bearbeitet durch User
Sheeva P. schrieb: >> Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare >> Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die >> damit untergegangen sind. > > Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei > denen wesentliche Teil der geschäftskritischen Software in Smalltalk > implementiert sind. Wenn du lesen könntest, hättest du im Satz oben bemerkt, daß Smalltalk nicht in der Liste "weder in..wurden brauchbare Programme geschrieben" steht. Der Satz schliesst also nicht aus, daß man in Smalltalk auch mal ein brauchbares Programm schreiben kann. Er sagt nur, daß manch eine Firma an der Fehlentscheidung zu Grunde gegangen ist. Aber deine Lesefähigkeit ist offenkundig unterentwickelt. Das sieht man auch an deinen anderen Beiträgen hier.
A. K. schrieb: > Die Syntax ist an mehreren Stellen übel verkrampft und auch zweideutig. > Die Grundstruktur der Sprache sorgt für unnötig schlechte Lesbarkeit, > aufgrund verkorkster Deklarationstechnik. Das ist freilich kein Fehler > von C++, sondern ein Erbe von C, das durch die Komplexität von C++ > verstärkt auftritt. Sagen wir mal so: In Objective-C ist das alles noch viel schlimmer.
Am besten alles in Assembler schreiben. Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen lernen.
Assembler ist das Beste der Welt schrieb: > Am besten alles in Assembler schreiben. > Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen > lernen. Ja, Moby...
Assembler ist das Beste der Welt schrieb: > Am besten alles in Assembler schreiben. > Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen > lernen. Volle Kontrolle hat man aber nur auf dem selbst entwickelten Prozessor, deshalb am besten selber Transistoren zusammenlöten! P.S. Während in Villarriba schon gefeiert wird, wird in Villabajo noch Assembler geschrieben.
Michael B. schrieb: > Sheeva P. schrieb: >>> Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare >>> Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die >>> damit untergegangen sind. >> >> Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei >> denen wesentliche Teil der geschäftskritischen Software in Smalltalk >> implementiert sind. > > Wenn du lesen könntest, hättest du im Satz oben bemerkt, daß Smalltalk > nicht in der Liste "weder in..wurden brauchbare Programme geschrieben" > steht. Der Satz schliesst also nicht aus, daß man in Smalltalk auch mal > ein brauchbares Programm schreiben kann. Er sagt nur, daß manch eine > Firma an der Fehlentscheidung zu Grunde gegangen ist. Wenn hingegen Du lesen könntest, hättest Du meine Aussage verstanden, daß die Verwendung von Smalltalk nicht zum Untergang des Unternehmens führen muß. Offensichtlich solltest Du lieber an Deiner eigenen Lesefähigkeit und Deinem Textverständnis arbeiten, statt Dir über meine Gedanken zu machen. Aber wo Du schon so lieb darum bittest, schauen wir uns doch einmal den sachlichen Gehalt Deiner anderen Aussagen an... Tatsächlich ist ein wesentlicher Teil der Funktionalität des GNU/Emacs in Lisp geschrieben, AutoCAD hat einen Lisp-Interpreter eingebaut, ebenso Audacity und LilyPond. Zudem wird Lisp laut diesem [1] Beitrag häufig in "Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, Electronic Design Automation/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical Computer Aided Design (CAD), Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring" eingesetzt. Dr. Dobb's hat dazu einen schon etwas älteren Artikel [2] darüber, wofür Prolog so alles eingesetzt wird. Für APL bin ich jetzt zu faul zum Suchen, Tatsache ist jedenfalls: nicht nur Deine implizite Andeutung ist falsch, daß Unternehmen aufgrund ihrer Verwendung von Smalltall untergingen, ebenso falsch ist Deine Behauptung, in Prolog und Lisp seien keine brauchbaren Programme geschrieben worden. Neben Deinen Lesefähigkeiten und Deiner Sozialkompetenz ist also auch Dein Fachwissen noch ziemlich ausbaufähig, was insbesondere dann etwas peinlich wirkt, wenn Du hier die dicke Host gibst und professionelle Entwickler mit jahrzehntelanger Berufserfahrung abkanzelst. Zum Glück erkennen geneigte Leser durch Deine Ausfallerscheinungen, was vom sachlichen Gehalt Deiner Aussagen zu halten ist. :-) [1] https://www.quora.com/What-is-Lisp-used-for [2] http://www.drdobbs.com/parallel/the-practical-application-of-prolog/184405220 > Aber deine Lesefähigkeit ist offenkundig unterentwickelt. Solange ich C++ ohne Debugger verstehe, bin ich da unbesorgt. :-)
Sheeva P. schrieb: > Für APL bin ich jetzt zu faul zum Suchen, In den Jahren um 1980 herum wurde APL produktiv auf einem Mainframe in einem grösseren Unternehmen eingesetzt. Mir bekannte Einsatzbereiche waren - naheliegend - das CAD Umfeld und rechnerische Verfahren. Aber auch gänzlich andere Rollen, nämlich interaktive Verwaltungsaufgabe, also Datenbank mit Dialog-Frontend. Programmierung in diesen Bereichen hatte mir damals ein paar Mäuse über Ferienjobs eingebracht.
:
Bearbeitet durch User
Eins vorneweg: Man darf den Trollen nie gegenüber persönlich verletzend werden, besonders nicht, wenn die selber damit angefangen haben. "Michael Bertrand" ist eine arme Sau und wir sollten ihm genau das geben was er in seinem Leben sonst nie erfährt: Einen respektvollen Umgangston. Das durch den Einsatz von Smalltalk irgeneine Firma zugrunde geht, halte ich für ein Gerücht. Leute die mit solchen Sprachen arbeiten wissen auch wo deren Grenzen sind und können auch mit den Systemen umgehen die ihre Smalltalk-Umgebungen hosten. Es wird auch heute noch im Finanzsektor und in der Forschung intensiv eingesetzt. Wer Smalltalk kennt weiß auch, dass Javascript und C++ eigentlich garnicht "richtig" objektorientiert sind. ;-)
A. K. schrieb: > Sheeva P. schrieb: >> Für APL bin ich jetzt zu faul zum Suchen, > In den Jahren um 1980 herum wurde APL produktiv auf einem Mainframe in [..] Das gibt es auch heute noch innerhalb von Versicherungsrechenkernen. Da hatte ich mal auf der Arbeit mit zu tun. Wurde auf Windows von einer C-Dll aufgerufen, die wiederum von einem Cobol-Tool aufgerufen wurde.
Chris F. schrieb: > Das durch den Einsatz von Smalltalk irgeneine Firma zugrunde geht, halte > ich für ein Gerücht. Das liegt wahrscheinlich an deiner unzureichenden Praxiserfahrung. > Man darf den Trollen nie gegenüber persönlich verletzend werden, > besonders nicht, wenn die selber damit angefangen haben. Hmm, angefangen. Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?" Nach deiner Doktrin darfst du jetzt also anfangen. > "Michael Bertrand" ist eine arme Sau .. ... ist ein persönliche Beleidigung aber das ist DIR natürlich recht. Aber das ist ein schöner Thread: Hier hat man gleich die ganze 'Elite', die Verursacher der aktuellen Softwarekrise ist, auf einen Haufen.
Michael B. schrieb: >> "Michael Bertrand" ist eine arme Sau und wir >> sollten ihm genau das geben was er >> in seinem Leben sonst nie erfährt: >> Einen respektvollen Umgangston. > > ... ist ein persönliche Beleidigung aber das ist DIR natürlich recht. Dafür das Du so austeilst bist Du aber SEHR dünnhäutig, mein Lieber. ;-) Mein Mitleid hast Du Dir ehrlich erarbeitet. Benenne doch mal die Firm_EN_ die an Smalltalk zu Grunde gingen. Wenn die eh pleite und kaputt sind, sollte das ja kein Problem sein. Leg los. :)
Moby A. schrieb im Beitrag #4630612:
> Alles bitteschön dort wo es wirklich Sinn macht ;-)
Natürlich. Kein denkender Mensch benutzt einen Akkuschrauber, um Nägel
einzuschlagen. Daß es Menschen gibt, die das trotzdem versuchen, spricht
weder gegen Akkuschrauber, noch gegen Nägel.
Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck
von Akkuschraubern natürlich nicht verstehen.
Chris F. schrieb: > Dafür das Du so austeilst bist Du aber SEHR dünnhäutig, mein Lieber. ;-) ;-) > Mein Mitleid hast Du Dir ehrlich erarbeitet. Mitleid bekommt man geschenkt. Nur Neid muß man sich erarbeiten.
Moby A. schrieb im Beitrag #4630642: > Sheeva P. schrieb: >> Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck >> von Akkuschraubern natürlich nicht verstehen. > > Das sagt der Richtige ;-) Gut erkannt.
Moby A. schrieb im Beitrag #4630642: > Sheeva P. schrieb: >> Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck >> von Akkuschraubern natürlich nicht verstehen. > > Das sagt der Richtige ;-) Er ist ja schon drollig unser Moby. Oft wirkt er zwar nur unfreiwillig komisch aber manchmal hat man fast das Gefühl er übt sich in der vollendetsten Form der Selbstironie, so extrem in der Aussage und doch zugleich der Spott über sich selbst so subtil zwischen den Zeilen versteckt daß man es fast nicht bemerkt. Meisterhaft!
:
Bearbeitet durch User
Bernd K. schrieb: > Er ist ja schon drollig unser Moby. Oft wirkt er zwar nur unfreiwillig > komisch aber manchmal hat man fast das Gefühl er übt sich in der > vollendetsten Form der Selbstironie, so extrem in der Aussage und doch > zugleich der Spott über sich selbst so subtil zwischen den Zeilen > versteckt daß man es fast nicht bemerkt. Meisterhaft! Nur verstanden hat er dich nicht. Also wohl doch eher unfreiwillig komisch.
Heiner schrieb im Beitrag #4632584: > Moby A. schrieb im Beitrag #4632581: >> Ich denke bei Kurt Bindl bist Du wirklich besser aufgehoben, da kann man >> Deine Beiträge eher als fachspezifisch werten ;-) > > Komm schon Moby, jeder der hier schon länger als ein paar Wochen > vorbeischaut, weiß noch wie du dich bis auf die Knochen blamiert hast > mit deinem Wissen. Es war wohl weniger das Wissen, als vielmehr dessen Absenz. ;-)
Moby A. schrieb im Beitrag #4633161: > Zu was steigende und steigende und steigende Komplexität generell führt > kann man gerade bei der bundesweiten Netz-Störung bei Vodafone/Kabel > beobachten. Stimmt. Wenn die gesamte Netz-Software in ASM programmiert wäre, hätte das nicht passieren müssen. Schuld ist nur die Faulheit, ASM zu lernen :-)
Moby A. schrieb im Beitrag #4633161: > OOP bläst die geradezu > explosionsartig auf. Und der Trend zu immer neuen, detaillierteren > Konstruktionen geht weiter... Nein bei einer ordentlichen Softwareentwicklung führt OOP genau zu dem Gegenteil. Komplexe Systeme werden in kleine Pakete zerlegt und der Code kann gut lesbar geschrieben werden (das bezieht sich nicht explizit aus C++).
@Moby AVR (moby-project) Es ist wohl wahr, das man schlechten Code schreiben kann, wenn man jedes Konstrukt und jedes Pattern hineinpackt, nur wel es existiert. Solange man aber nur Konstrukte verwendet die zur jeweiligen Problemstellung passen, und man ein Gesammtkonzept sowie Namenskonventionen hat, ist es bei OOP doch wesentlich einfacher zu lesen, sich zurechtzufinden, und auch grössere Änderungen vorzunehmen. Was ich an OOP am meisten schätze ist, das zusammengehörende Daten zusammengefasst werden. Ich arbeite gerade an einem Projekt, welches älter als ich bin ist, das teile enthält von 1992. Es ist in C und Fortran, und es gibt Tonnenweise globale Variablen und Convertierfunktionen zwischen z.B. c und Fortran strings. Die Funktionsaufrufe c->fortran und umgekehrt wurden erreicht, indem c Funktinsnamen und Typen in abhängigkeit vom Compiler an die Fortran ABI angepasst wurde. Und nun lauft das Refactoring, wo das alles geändert werden muss... Da lernt man die Modernen Interopabilitätstandards und die Designpatterns sowie OOP erst richtig zu schätzen.
Karl schrieb: > Nein bei einer ordentlichen Softwareentwicklung führt OOP genau zu dem > Gegenteil. Komplexe Systeme werden in kleine Pakete zerlegt und der Code > kann gut lesbar geschrieben werden (das bezieht sich nicht explizit > aus C++). Eine ordentliche Softwareentwicklung besteht sowieso daraus, komplexe Systeme in kleine Pakete zu unterteilen und die in gut lesbaren Code zu formulieren, ob mit OOP oder ohne. Ob OOP das gut unterstützt oder nicht, ist eine durchaus offene Frage. Bei C++ kann man da Zweifel haben, bei Java sieht es besser aus finde ich, aber Java lebt zu sehr in seiner eigenen Welt. Wenn heute davon geredet wird, ein Uniabsolvent könne "C++" kann er meist bloss "C" und wenn man davon redet, die Programme wären in "C++" geschrieben, sind sie meist bloss in "C". Oder schlecht. Wie schlecht objektorientierte Formulierungen von durchaus objektorientierten Welten sein können, sieht man an MFC.
Moby A. schrieb im Beitrag #4633161: > Zu was steigende und steigende und steigende Komplexität generell führt > kann man gerade bei der bundesweiten Netz-Störung bei Vodafone/Kabel > beobachten die immer noch nicht behoben ist. Das gilt für Software mit > ihrer steigenden Bürokratie ganz genauso (ob die wohl dahintersteckt?). Nach dem Buschfunk liegt es an einem defekten Backbone-Switch -- die sind aber alle in Assembler programmiert. Es bestätigt sich, was die klugen Benutzer moderner Hochsprachen bereits wissen: unlesbarer Assembler-Spaghetticode ist nicht dazu geeignet, die Komplexität realer Probleme zu beherrschen. Darum fällt einem Assembler bei allem, das komplizierter ist als blinkende LEDs, irgendwann böse auf die Füße -- Dir früher, anderen später. Aber wem sage ich das. In Deinem ersten Assemblerthread haben Dir die hier anwesenden Experten sogar in Deinen wenigen Dutzend Zeilen trivialsten Codes etliche gravierende Anfängerfehler nachgewiesen. Aber Respekt vor Deinem Mut! Jeder, der sich irgendwo so blamiert hat wie Du hier, würde normalerweise mikroskopisch kleine Nanobrötchen backen. > OOP bläst die geradezu explosionsartig auf. Und der Trend zu immer > neuen, detaillierteren Konstruktionen geht weiter... Bloß gut, daß die > Experten hier alles unter Kontrolle haben. Stimmts, Karl Käfer? Nein, Moby AVR, stimmt nicht. Das genaue Gegenteil trifft zu: schwierigere Probleme können nur gelöst werden, weil OO die Komplexität reduziert.
Sheeva P. schrieb: > Wie sonst wäre es zu erklären, daß es > dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen: C++, na > klar, aber auch Java, Perl, ECMAScript, R, Google Go, PHP, sowie etwa 60 > andere. Das hätten die Autoren dieser Sprachen sicherlich nicht gemacht, > wenn sie die Syntax als schlecht lesbar empfunden hätten. GRÖHL... Also, du verwechselst mal wieder die Dinge ganz gehörig. Andersherum wird der berüchtigte Schuh draus: Es hat bereits vor langen Jahren genug Leute gegeben, die erkannt haben, daß man mit C auf Dauer nicht froh wird, weil C eben nicht geeignet ist, mit wachsenden Anforderungen mitzuwachsen. Genau deshalb hane sich all diese Leute darangemacht, etwas neueres zu kreieren: C++, Java und Konsorten. Aber da sie nun mal bereits beim Entwurf ihrer "neuen" Sprache von C geistig verbogen sind (oder sagen wir's dezenter "vororientiert" sind), ist bei allen Versuche, was Neues zu kreieren, eben immer ein durchgemangeltes C dabei herausgekommen. Die C-Programmierer kommen eben nicht mehr aus ihrer geistigen Furche heraus. Das ist es. Eine andere Frage ist es, warum gerade berufsmäßige Programmierer sich auf C gestürzt haben und schlichtweg bessere Pascal aufgegeben haben. Ich hatte dazu mal nen Burschen gefragt, der mal bei mir in der Firma war und sich dann woanders zum Programmierer entwickelt hat. Antwort: Bei Pascal muß man ja so viel schreiben und der Chef bildet sich ein, er könnte sowas verstehen, weil es ja lesbar aussieht. W.S.
Sheeva P. schrieb: > Den leistet man genau ein einziges Mal. Nein, im Allgemeinen eben nicht. Es gibt Ausnahme in Form von reinen Programmierern, die den ganzen Tag nichts anderes machen. Alle anderen Leute, die beruflich neben Anderem eben auch programmieren, haben den Aufwand jeden Tag. Ich merk das ja an mir selber beim ständigen Umschalten von C nach Delphi und wieder zurück - und weil ich daneben eben auch noch einen Sack ganz anderer Esel zu kämmen habe. Wer nix anderes tut als immerzu nur in einem engen Kreis ähnlichster Sprachen zu programmieren, der merkt das halt nicht und kommt dann zu solchen Aussagen wie du. Und was die Zukunft angeht: Ich schätze, es wird weiter mit C gehen, ganz gleich, wie unangemessen C für künftige Aufgaben sein wird. Dafür gibt es dann in steigendem Maße Zusatz-Zeugs wie Programmgeneratoren, Kontrolletti-Systeme (MISRA & Co) und so weiter. Mit steigender Komplexität steigt die Bugrate an, weswegen sich insbesondere Kontrolettizeugs rasant vermehren wird. Pascal wird sich in Form von Delphi in den Sphären von Datenbank-Affinem halten und die Kraft, einen Schnitt zu machen und was wirklich dem dann erforderlichen Stand der Dinge entsprechendes zu schaffen, wird keiner haben. Ob ich das dann gut finden werde? Nö. Hauptsache ABS, ESP und anderer Krempel in meinem Auto sind nicht so buggy wie derzeit beim Tesla. W.S.
Karl Käfer schrieb: > Nach dem Buschfunk liegt es an einem defekten Backbone-Switch -- die > sind aber alle in Assembler programmiert. Eher noch ein wenig weiter unten. Switching Engines sind spezielle Hardware, nicht Software. Die Software konfiguriert und verwaltet.
MaWin schrieb: > Eine ordentliche Softwareentwicklung besteht sowieso daraus, komplexe > Systeme in kleine Pakete zu unterteilen und die in gut lesbaren Code zu > formulieren, > > ob mit OOP oder ohne. > > Ob OOP das gut unterstützt oder nicht, ist eine durchaus offene Frage. Nein, eigentlich nicht. Diese Diskussion gibt es nur im Embedded-Umfeld, wo die OO ihre Stärken wegen der meist eher überschaubaren Projektgrößen nicht voll ausspielen kann. Aber überall dort, wo Projekte regelmäßig größer als einige 10k oder 100k LOC sind, ist die Diskussion schon lange entschieden, und zwar eindeutig für die OOP. > Wenn heute davon geredet wird, ein Uniabsolvent könne "C++" kann er > meist bloss "C" und wenn man davon redet, die Programme wären in "C++" > geschrieben, sind sie meist bloss in "C". Oder schlecht. Vielleicht kenne ich andere Uniabsolventen als Du. > Wie schlecht objektorientierte Formulierungen von durchaus > objektorientierten Welten sein können, sieht man an MFC. Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.
W.S. schrieb: > Es hat bereits vor langen Jahren genug Leute gegeben, die erkannt haben, > daß man mit C auf Dauer nicht froh wird, weil C eben nicht geeignet ist, > mit wachsenden Anforderungen mitzuwachsen. Genau deshalb hane sich all > diese Leute darangemacht, etwas neueres zu kreieren: C++, Java und > Konsorten. Aber da sie nun mal bereits beim Entwurf ihrer "neuen" > Sprache von C geistig verbogen sind (oder sagen wir's dezenter > "vororientiert" sind), ist bei allen Versuche, was Neues zu kreieren, > eben immer ein durchgemangeltes C dabei herausgekommen. Die > C-Programmierer kommen eben nicht mehr aus ihrer geistigen Furche > heraus. Das ist es. > > Eine andere Frage ist es, warum gerade berufsmäßige Programmierer sich > auf C gestürzt haben und schlichtweg bessere Pascal aufgegeben haben. Ich verstehe ja, daß es Dich ärgert und schmerzt, daß die C-basierten sich letztlich gegen Dein geliebtes Pascal durchgesetzt haben. Aber wenn Du den Entwicklern und Anwendern von C-basierten Sprachen pauschal vorwirfst, von C verdorben, zu faul, oder zu dumm zu sein, um andere Sprachen zu erlernen dann ist das ebenso arrogant wie dumm von Dir selbst und disqualifiziert nicht darum nur Deinen Standpunkt. Darüber hinaus ist Deine hohle Unterstellung aber auch vollkommen falsch, soweit es mich betrifft: ich bin vor vielen Jahren von Basic und Assembler erst zu C, später zu C++ gekommen, habe viele Jahre lang Perl genutzt und erfreue mich heute an Python und Lua. Und morgen setze ich vielleicht auf Rust, Nim, Go oder Scala? Das wird sich zeigen, ich bin da flexibel. Warum ich mit Pascal nie warm geworden bin? Keine Ahnung. Tatsächlich habe ich von TurboPascal über Kylix bis Delphi und Lazarus immer wieder einmal hineingeschaut (und manchmal sogar Geld ausgegeben), aber irgendwie hat es mich nie so richtig überzeugt.
W.S. schrieb: > Sheeva P. schrieb: >> Den leistet man genau ein einziges Mal. > > Nein, im Allgemeinen eben nicht. > > Es gibt Ausnahme in Form von reinen Programmierern, die den ganzen Tag > nichts anderes machen. > > Alle anderen Leute, die beruflich neben Anderem eben auch programmieren, > haben den Aufwand jeden Tag. > > Ich merk das ja an mir selber beim ständigen Umschalten von C nach > Delphi und wieder zurück - und weil ich daneben eben auch noch einen > Sack ganz anderer Esel zu kämmen habe. Wer nix anderes tut als immerzu > nur in einem engen Kreis ähnlichster Sprachen zu programmieren, der > merkt das halt nicht und kommt dann zu solchen Aussagen wie du. Wie gesagt: im Moment nutze ich hauptsächlich C, C++, Python und Lua, und Programmieren ist nur eine Nebenaufgabe meiner eigentlichen Arbeit bei der Datenverarbeitung, -analyse und -visualisierung. Trotzdem kann ich Deine Aussagen leider beim besten Willen nicht nachvollziehen: OO ist nur eins von einer ganzen Reihe von Werkzeugen, die ich nutze, wie mit dem Hammer und dem Akkuschrauber: für einen Nagel nehme ich einen Hammer, für eine Schraube einen Akkuschrauber. So what? > Ob ich das dann gut finden werde? Nö. Hauptsache ABS, ESP und anderer > Krempel in meinem Auto sind nicht so buggy wie derzeit beim Tesla. Naja, verglichen mit einem System zum autonomen Fahren, wie es gerade bei einem Tesla versagt hat (wobei auch der Fahrer des Tesla den LKW ja wohl übersehen hat), sind ein ABS und ein ESP doch eher trivial.
Moby A. schrieb im Beitrag #4634054: > Und wie Du oben schon selber bestätigt hast taugt Asm für mehr als nur > blinkende LEDs ;-) Also ich lese da was anderes, eher das Gegenteil: > Darum fällt einem Assembler bei allem, das komplizierter ist > als blinkende LEDs, > irgendwann böse auf die Füße -- Dir früher, anderen später.
Sheeva P. schrieb: > Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist: > "(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-) Naja, ohne die Diskussion weiter in Richtung Lisp treiben zu wollen, solltest Du Dir Common Lisp vielleicht mal ansehen. Die Sprache ist nämlich wirklich Klasse und (entgegen der "öffentlichen" Meinung) auch gut im Einsatz. Allerdings erkennt man viele Vorteile erst, wenn man nach einer Weile CL wieder zu was anderem wechseln muss :/ Das Stichwort in Zusammenhang mit OOP wäre CLOS (Common Lisp Object System). Da kannst Du z.B. auch den Method Dispatch (fast) beliebig umbauen ;-) Da Du ja KEIN Anfänger bist: "The Art of the Metaobject Protocol" von Gregor Kiczales u.a. (JA, das IST der Kiczales, der auch AspectJ entwickelt hat). Und bitte, bitte kein Language War. Das ist doch so ermüdend ;-) /regards
Moby A. schrieb im Beitrag #4634073: > OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen > Datenmengen. Gerade bei großen Datenmengen tendiere ich eher zu funktionalen Techniken, weil die sich oft besser parallelisieren und verteilen lassen. > Handwerkszeug welches man beherrscht macht immer Freude. Die Frage ist > nur: Brauchts das wirklich? Da sind wir wieder beim Akkuschrauber. Den "brauche" ich eigentlich nicht, im Sinne von: er ist nicht notwendig. Schrauben kann ich schließlich auch von Hand mit einem Schraubendreher eindrehen. Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir das Schrauben wesentlich einfacher und angenehmer machen. > Bei einem Blick ins aktuelle VS2015 wird jedem Anfänger schwarz vor > Augen. Der will vielleicht nur eine einfache Anwendung schreiben, steht > aber vor einem ganzen Gebirge von OOP-Bürokratie und Anwender-APIs. Visual Studio war immer schon ein überfrachtetes Monster, und .NjET ist ein ebensolches Framework. Das liegt aber nicht an der OO, sondern an MS' Tendenz, alles mit riesigen Monolithen totzuschlagen. Word, Excel und Co. haben allesamt nichts mit OO zu tun, sind aber genauso überfrachtet. > Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau > ich immer zuerst auf den Umfang der Doku ;-) Das ist eine ziemlich dumme Idee. Mir sind im Laufe meines Lebens viele Dinge begegnet, die schwer zu erklären, aber einfach zu verstehen sind, angefangen bei der Abseitsregel im Fußball über das Reizen beim Skat bis zur Datenbanknormalisierung, um nur ein paar Beispiele zu nennen. Zudem können manche Leute besser, andere hingegen weniger gut erklären; einige Dinge lassen sich leichter an einem konkreten Kontext erklären, der für das Verständnis der Erklärung erst einmal begriffen sein muß.
Moby A. schrieb im Beitrag #4634073: > OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen > Datenmengen. Manchmal lieber Moby habe ich das Gefühl du weißt überhaupt nicht was OOP bedeutet. Es kommt nicht darauf an wie große die Datenmenge ist, sondern wie komplex die Probleme sind die mit den Daten zu lösen sind. Ein paar einfache Datenbankoperationen auf ein paar Millionen Datensätze? Schreibe ich nicht in C++ / Java usw. sondern in SQL bzw. der Skriptsprache (i.d.R eher Prozedural) des Datenbankanbieters. Beste und performanteste Lösung. > Gerne. Das will ich Dir auch gar nicht ausreden. > Handwerkszeug welches man beherrscht macht immer Freude. Die Frage ist > nur: Brauchts das wirklich? Brauchts immer mehr davon? > Bei einem Blick ins aktuelle VS2015 wird jedem Anfänger schwarz vor > Augen. Der will vielleicht nur eine einfache Anwendung schreiben, steht > aber vor einem ganzen Gebirge von OOP-Bürokratie und Anwender-APIs. Wenn > mir jemand erzählen will wie einfach doch dies und jenes sei schau ich > immer zuerst auf den Umfang der Doku ;-) Erstens haben weder moderne APIs noch IDEs unmittelbar etwas mit OOP zu tun. Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein AVR. Deswegen Programmiert auch niemand Windows mit ASM. Zweites war jeder Softwareentwickler sicher mal ein Anfänger, aber glücklicherweise sind es nicht mehr alle. Und nur weil dich als Anfänger eine moderne IDE überfordet, so schließe bitte nicht von dir auf andere. Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein professionlles Werkzeug. Oder lehnst du CAD Programme ab, weil nicht jeder Anfänger einen Motor konstruieren kann? Ich für meinen Teil habe auch ein Weilchen gebraucht, aber nun liebe ich die unzähligen Hilfsfunktionen meines Eclipse und könnte auch bei den großen Projekten die ich betreue kaum die Übersicht behalten.
Ist es nicht so, dass man beruflich in der Programmiersprache entwickeln muss, die einem vorgesetzt wird? (Bei mir ist und war das so, die ganzen 20 Jahre in 6 Unternehmen. Und die sind teilweise mit und teilweise ohne OOP.) Wenn dem so ist, dann kommt man mit einer flexiblen Einstellung wesentlich besser voran, als mit der Diskussion, wessen ... der längste ist, bzw wessen Lieblings-Programmiersprache die Beste ist.
Moby A. schrieb im Beitrag #4634054: > Jan H. schrieb im Beitrag #4621860 >> ungefähr sieben Trilliarden Webseiten und fünf >> Millionen Bücher zu dem Thema. > > und immer fettere OOP Installationen zu bedeuten haben. ? 1. Hat die Größe des Maschinencodes von einer klassischen Anwendung, keinen Einfluss auf die Installationsgröße, da er nicht mal 1% davon ausmacht. 2. Nein ganz und gar nicht bedeutet OOP mehr Maschinencode. Das liegt schon daran, dass es nicht die Umsetzung von OO zu Maschinencode gibt. Moby A. schrieb im Beitrag #4634073: >> bei OOP doch wesentlich einfacher zu lesen, sich zurechtzufinden, und >> auch grössere Änderungen vorzunehmen. > > OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen > Datenmengen. Definiere Groß. >10k, >100k oder >1M LOC? Mein 3k LOC Programm damals hat jedenfalls nicht an OOP gelitten, eher im Gegenteil. War ne kleine Physiksimulation für die Schule (Stoßgesetze). Könnte man dank OOP auch prima erweitern und ausbauen. Moby A. schrieb im Beitrag #4634241: > Sheeva P. schrieb: >> Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir >> das Schrauben wesentlich einfacher und angenehmer machen. > > Wenn denn OOP nur annähernd so simpel wäre... Der Vergleich hinkt > gewaltig. > >> Visual Studio war immer schon ein überfrachtetes Monster > > Es ist ein Spiegelbild der OOP-Möglichkeiten. > >>> Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau >>> ich immer zuerst auf den Umfang der Doku ;-) >> >> Das ist eine ziemlich dumme Idee. > > Ganz und gar nicht. Je mehr Doku notwendig desto mehr Umfang hat die > Sache. Die einfachsten Dinge haben sogar gar keine Doku nötig, weil > sie selbsterklärend sind. Das ist der anzustrebende, mehr oder weniger > illusorische Idealzustand. Nichtsdestotrotz ist aber das die > Zielrichtung. OOP mit seinen realen Spielarten läuft in die entgegen > gesetzte. Ja Moment mal. Einerseits gibst du zu, OOP eignet sich für große Projekte. Andererseits sagst du aber, OOP erhöht die Komplexität und erschwert den Durchblick. Wie kommst du dann darauf, dass sich OOP für große Projekte eignet? Wenn das zu lösende Problem schon komplex genug ist, und das sind große Programme ja immer, warum sollte man dann ein Paradigma wählen, dass dem ganzen noch ne Schippe an Komplexität drauflegt? Warum willst du keine PP verwenden, wenn du doch der Meinung bist, dass diese in Sachen Komplexität der OOP überlegen ist. Ja OOP soll ja gar die Dokumentation erschweren. Fazit: Deine Meinung zu OOP ist undifferenziert und emotional. Was eine Folge von viel Halbwissen, deiner verzerrten Vorstellung von Einfachheit und schlechter Erfahrung von überladender Anwendungssoftware ist. Das grundlegene Problem ist aber, dass du das weder einsehen wirst, egal wie die Fakten sind, denn du hast in dieser Sache recht und alle in diesem Forum, die dir widersprechen im Unrecht. Das sind fehlgeleitete Anhänger der ketzerischen Religion namens Komplexität. Das trifft in der Diskussion um OOP als auch in der Diskussion um ASM/C zu. Ach ja AVR vs. ARM hab ich noch vergessen. Dabei kennst du nur AVRs und ASM...
TriHexagon schrieb: > Fazit: Deine Meinung zu OOP ist undifferenziert Meine auch :-) Wobei es ja meist weniger um OOP geht, als um Vererbung. Go erlaubt ja wohl tatsächlich überhaupt keine Vererbung. Ich hatte darüber schon mal etwas gelesen, aber wohl nicht ganz verstanden. Heute abend werde ich dies mal lesen: http://stackoverflow.com/questions/1727250/embedding-instead-of-inheritance-in-go
Sheeva P. schrieb: > Visual Studio war immer schon ein überfrachtetes Monster Eclipse bestimmt nicht. Herr wirf Hirn. Sheeva P. schrieb: > Naja, verglichen mit einem System zum autonomen Fahren, wie es gerade > bei einem Tesla versagt hat (wobei auch der Fahrer des Tesla den LKW ja > wohl übersehen hat), sind ein ABS und ein ESP doch eher trivial. Aber ebenfalls fehlerhaft. Ich kenne bei beiden unfallgefährliche Ausfälle (d.h. bei ABS nicht-mehr-bremsen-können wo es ohne ABS gut verzögernd ginge und bei ESP Vollbremsung ohne Grund - sicher Sensorfehler der Softwaremässig nicht erkannt wurde weil Plausibilitätsprüfung fehlt)), und es gab sicher auch schon Tote nur hinterher weiss man das nicht mehr, der Fahrer kann es ja nicht mehr sagen, und arrogante KFZ Hersteller würden es stets abstreiten. Tempomaten als Fahrerassistenzsystem (siehe Tesla) sind sicher auch für viele Tote bei Lastwagen-Auf-Stauende Auffahrunfälle zuständig, auch da weiss man es hinterher nur nicht mehr, aber ich merk ja selbst wie ich beim Tempomat am liebsten ein Buch lesen würde (und dann den Tempomaten wieder ausschalte). Sheeva P. schrieb: > die Diskussion schon lange entschieden, und zwar eindeutig für die OOP. Auch wenn du nicht mehr drüber nachdenken magst, gibt es Viele, die die Realität beobachten, und OOP für viele Probleem aktueller Software verantwortlich machen, und deren Analysen sind nicht so einfach wie du es gerne willst von der Hand zu wischen. Aber was du nicht willst gibt es ja nicht, so macht man sich das Leben schön. > Vielleicht kenne ich andere Uniabsolventen als Du. Bestimmt. Deine Traumwelt halt. > Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern > lediglich ein Wrapper um die c- und assemblerbasierte WinAPI. Ah, im Notfall immer rausreden, sehr pragmatisch.
Stefan S. schrieb: > TriHexagon schrieb: >> Fazit: Deine Meinung zu OOP ist undifferenziert > > Meine auch :-) > > Wobei es ja meist weniger um OOP geht, als um Vererbung. Go erlaubt ja > wohl tatsächlich überhaupt keine Vererbung. Ich hatte darüber schon mal > etwas gelesen, aber wohl nicht ganz verstanden. Heute abend werde ich > dies mal lesen: > > http://stackoverflow.com/questions/1727250/embedding-instead-of-inheritance-in-go Sehr gute Idee! Es ist immer gut seinen Horizont zu erweitern und sich mit neuartigen Sprachen/Konzepten zu beschäftigen. Das würde unseren Moby mal richtig gut tun ;), wobei ich ihm eher zu konservativen Sprachen raten würde. Ich hätte schon mal Lust mal ein kleineres Programm in Rust umzusetzen, leider fehlt mir dazu gerade die Zeit.
Scelumbro schrieb: > Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein > AVR. Deswegen Programmiert auch niemand Windows mit ASM. Ach Nein? Google mal MASM32...
HVV schrieb: > Scelumbro schrieb: >> Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein >> AVR. Deswegen Programmiert auch niemand Windows mit ASM. > > Ach Nein? Google mal MASM32... Ach ja? Ist Windows tatsächlich mit Assembler programmiert? Man lernt eben nie aus ;-)
Stefan U. schrieb: > Ist es nicht so, dass man beruflich in der Programmiersprache entwickeln > muss, die einem vorgesetzt wird? Nö. So geht es womöglich den Leuten, die als Codeschreiber eingesetzt werden. Bei mir sieht das anders aus: Ich benutze das, was ich zuvor eingekauft habe. Allerdings sehe ich das Ganze durchaus kritisch: Die Auswahl ist heutzutage geradezu mickrig geworden, wenn man das µC-Gebiet im Auge hat. Da ist außer C eigentlich nix mehr zu finden (und Hersteller wie Mikroe sind bisher zu kurz gesprungen), weswegen sich die Auswahl auf verschiedene C-Compiler-Hersteller eingrenzt. Ist halt ne Monokultur geworden - und sowas ist erwiesenermaßen von Grund auf schlecht, jedenfalls auf lange Sicht. Übrigens gilt dies auch für die derzeitige µC-Hardware, die inzwischen vom Cortex dominiert ist. Nee, das ist kein schlechter Prozessor in all seinen Ausbaustufen, im Gegenteil, er ist besser als alles zuvor, aber dennoch ist es ne Monokultur und das ist auf lange Sicht bedenklich. W.S.
> Ist halt ne Monokultur geworden - und sowas ist erwiesenermaßen von > Grund auf schlecht Ja war das noch schön, als ein Zeichen 6..9 Bits hatte und man mal im Einer-, mal im Zweier-Komplement rechnete. Und schön auch die gefühlt 100 verschiedenen FP-Formate nur bei einem Hersteller (DEC). Schön auch, wenn man für jede Kiste eine eigene Hochsprache hat. Ein Hoch auf die Vielfallt! Oder nennt man das schlicht Chaos?
Leute ihr frustriert mich^^ - ich habe schon mal versucht Trolltjreads zu starten (um den Hatern was zu schreiben zu geben), die ich bewusst mit Reizthemen versah. Dazu noch meinen Unwillen zu lernen angedeutet und ein paar Rechtschreibfehler eingebaut. Hat nichts genutzt. Das hier funktioniert viel besser. Im ernst - ich würde mich auf den Standpunkt stellen, dass man OO einfach sinnvoll (nicht auf Teufel komm raus jedes Pattern) und seinen Fähigkeiten entsprechend einsetzten muss. Das ist mit C und ASM ja auch nicht anders. Selbst in meinem kleinen Ein-Mann-Projekt habe ich OO eingesetzt und ich denke auf eine Weise wo es Sinn macht. Inetrfaces und Vererbung scheinen mir ein mächtiges Schwert zu sein. Ich habe eine Testumgebung gemacht. Wenn ich einen weiteren Test brauche, leite ich die Basisklasse ab, implmentiere die 3 Methoden aus dem Interface, die individuell sein sollen und bin nach 10 bis 30 Minuten fertig.
W.S. schrieb: > Nö. So geht es womöglich den Leuten, die als Codeschreiber eingesetzt > werden. Nö. So geht es allen Leuten die in Firmen arbeiten, wo sie selber nicht an der Entscheidungsfindung zu diesem Thema beteiligt sind. Also z.B. bei allen Firmen, deren Produkte länger leben als man selber in der Firma ist oder die SW für >10 Jahre supported werden muss (Die NASA sucht wohl immer noch einen Hacker für die Voyager - der Letzte der alten Truppe geht in Rente - http://www.popularmechanics.com/space/a17991/voyager-1-voyager-2-retiring-engineer/). Ähnliches bei Firmen wo Haftungsfragen etwas "böser" hochkommen. Warum "kleben" wohl die Banken/Versicherungen soooo an Cobol? > Die Auswahl ist > heutzutage geradezu mickrig geworden, wenn man das µC-Gebiet im Auge > hat. Da ist außer C eigentlich nix mehr zu finden Aha. Obwohl: https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/arm-elf_topics_and_tutorial.html (Und wenn man sich die Realtime & LowLevel Features von Ada anschaut dann wundert man sich erst mal, warum überhaupt noch jemand uC's in C(++) programmiert ... Bis man mal auf die Preise schaut^^) > Übrigens gilt dies auch > für die derzeitige µC-Hardware, die inzwischen vom Cortex dominiert ist. Auch nicht überall. Broadcom (http://www.broadcom.com/products/search?q=mips) und Dialog Semi (http://www.dialog-semiconductor.com/media-centre/press-releases/press-releases-details/2012/03/26/dialog-semiconductor-extends-green-voip-ic-family-to-address-high-end-phones) benutzen z.B. MIPS. Also nicht frustriert sein. Ist doch eigentlich wie immer ;-) /regards
Moby A. schrieb im Beitrag #4634978: > Ja, ein gewisser Hang die Dinge imposant aufzublasen wohnt dem Menschen > schon inne ;-) Ach!
Moby A. schrieb im Beitrag #4634241: > Sheeva P. schrieb: >> Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir >> das Schrauben wesentlich einfacher und angenehmer machen. > > Wenn denn OOP nur annähernd so simpel wäre... Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung -- kann man in weniger als einer halben Stunde erklären. >> Visual Studio war immer schon ein überfrachtetes Monster > > Es ist ein Spiegelbild der OOP-Möglichkeiten. Nein. Es ist ein Spiegelbild von Microsofts Tendenz, allen möglichen und unmöglichen Mist in eine einzelne monolithische Anwendung zu stopfen. Wie gesagt, dieselbe fatale Tendenz siehst Du bei der Office-Software, wo von 80/20-Programmen geredet wird: 80 Prozent der Nutzer nutzen höchstens 20 Prozent der Funktionen. All das hat mit OO nichts zu tun. >>> Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau >>> ich immer zuerst auf den Umfang der Doku ;-) >> >> Das ist eine ziemlich dumme Idee. > > Ganz und gar nicht. Je mehr Doku notwendig desto mehr Umfang hat die > Sache. Die einfachsten Dinge haben sogar gar keine Doku nötig, weil > sie selbsterklärend sind. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung -- kann man leicht auf weniger als einer DIN-A4-Seite erklären. Das einzige Problem ist wieder einmal, daß Du nicht den leisesten Hauch einer Ahnung davon hast, wovon hier die Rede ist. Das sieht man besonders gut an dummen Aussagen wie der, daß die Überfrachtung von VS an der OO läge. Tatsächlich ist die OO aber ein Programmierparadigma und kann auch mit einfachen Texteditoren benutzt werden. Daran ändert sich nichts, weil jemand den Texteditor mit Build- und Debuggingtools, Versionsverwaltung, Dokumentations- und Hilfswerkzeugen und anderem Zeug überfrachtet.
MaWin schrieb: > Sheeva P. schrieb: >> Visual Studio war immer schon ein überfrachtetes Monster > > Eclipse bestimmt nicht. Eclipse ist ebenfalls ein überfrachtetes Monster, genauso wie KDevelop, IntelliJ, Codeblocks, Qt Creator, und jede anderen IDE, die ich bisher gesehen habe. Zu dumm für Dich, daß das alles nichts mit OO zu tun hat. Schließlich kann man OO nicht nur mit überfrachteten IDEs, sondern mit jedem einfachen Texteditor benutzen. > Herr wirf Hirn. Zum Glück erkennst Du selbst, was Dir fehlt. > Sheeva P. schrieb: >> die Diskussion schon lange entschieden, und zwar eindeutig für die OOP. > > Auch wenn du nicht mehr drüber nachdenken magst, gibt es Viele, die die > Realität beobachten, und OOP für viele Probleem aktueller Software > verantwortlich machen, und deren Analysen sind nicht so einfach wie du > es gerne willst von der Hand zu wischen. Selbst wenn es so viele gäbe, wäre das nur ein argumentum ad populum. Aber in Wirklichkeit gibt es ja gar nicht so viele. > Aber was du nicht willst gibt es ja nicht, so macht man sich das Leben > schön. [...] > Bestimmt. Deine Traumwelt halt. Ach, Du Armer, hast Du es mal wieder nötig? Schade eigentlich: Du kannst kaum deutlicher sagen, daß Du kein sachliches Argument hast. >> Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern >> lediglich ein Wrapper um die c- und assemblerbasierte WinAPI. > > Ah, im Notfall immer rausreden, sehr pragmatisch. Erfreulicherweise habe ich gar keinen Notfall. Es ist nämlich nicht meine Schuld, daß die Realität so ist, wie ich sie beschrieben habe, und es ist auch nicht meine Schuld, daß das Design der MFC ebenso verhunzt ist wie die meisten anderen MS-Produkte auch. Aber auch das hat nichts mit OO zu tun, sondern damit, wie MS seine Bananaware zusammenzimmert.
Moby A. schrieb im Beitrag #4634978: > Scelumbro schrieb: >> Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein professionlles >> Werkzeug. > > Schließen sich Professionalität und einfache Anwendung etwa aus? Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür. > TriHexagon schrieb: >> Nein ganz und gar nicht bedeutet OOP mehr Maschinencode. > > In der Theorie. Nein, in der Praxis. > OOP ist einfach zu komplex anzuwenden. Das kannst Du doch gar nicht beurteilen. Du hast die OO noch nie angewendet und kennst sie nicht einmal; Dir sind ja sogar prozedurale Sprachen viel zu "bürokratisch", zu "kompliziert", bzw.: zu hoch.
Moby A. schrieb im Beitrag #4635007: > Sheeva P. schrieb: >> Wenn denn OOP nur annähernd so simpel wäre... Zitieren lernen: das war nicht von mir, sondern von Dir. >> Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung >> -- kann man in weniger als einer halben Stunde erklären. > > Klasse. Du bist ja echt lustig. Wozu es dann noch der > > Jan H. schrieb im Beitrag #4621860 >> ungefähr sieben Trilliarden Webseiten und fünf >> Millionen Bücher zu dem Thema > > bedarf? Wie bereits oben gesagt: derer bedarf es gar nicht, und die meisten davon beschäftigen sich ja auch kaum mit der OO, sondern mit anderen Themen wie konkreten Umsetzungen von OO in verschiedenen Sprachen, Diagrammtypen und Werkzeugen zur Modellierung, und so weiter. > VS bietet alle Möglichkeiten der OOP und ist als solches das Spiegelbild > ihrer Komplexität. Jeder popelige Texteditor bietet alle Möglichkeiten der OO und ist als solcher das Spiegelbild ihrer Einfachheit.
Moby A. schrieb im Beitrag #4635011: > Sheeva P. schrieb: >> Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür. > > Stimmt. Für diese Form aufgeblasener Programmierung braucht's ne > Ausbildung. Wenn Du Aussagen schon aus dem Zusammenhang reißt, solltest Du das nicht ganz so offensichtlich machen. :-) Und, Pardon, für Deine permanente Überforderung bin ich nicht verantwortlich. >> Das kannst Du doch gar nicht beurteilen. Du hast die OO noch nie >> angewendet und kennst sie nicht einmal > > Du kannst von Glück reden, daß ich meine Aussagen zum Können anderer > nicht so an den Haaren herbeiziehe. Mir ist da noch ein tolles > C-Programm als Beispiel Deiner Fähigkeiten in Erinnerung... naja, wollen > wir die Geschichte hier nicht nochmal aufwärmen ;-) LOL! Du meinst meine kleine Falle, in die Du so "erfolgreich" hineingetappt bist? Nee, wat hebbt wij lacht.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4635014: > Im übrigen mußt Du Dich in punkto OOP schon entscheiden: Brauchts nun ne > Ausbildung oder passt das Thema auf ein A4 Blatt ? Moby nochmal für dich: IDEs haben nichts mit OOP zu tun. Die Grundlagen von OOP passen auf ein DIN A4 Blatt. Die von Eclipse nicht. Oder müssen für dich eine CNC Fräse oder auch nur eine Drehbank auch so gebaut sein, dass jeder Anfänger damit sofort Motorteile herstellen kann? Man kann übrigens sehr komfortabel in Eclipse ASM für deine AVRs programmieren. Selbst die eher kleinen Programme von ein paar Dutzend Zeilen die du so machst. Sich in Eclipse ordentlich einzuarbeiten dauert übrigens weniger lang als eine Ausbildung zu den oben genannten Werkzeugen. Also keine Angst, auch du kannst das schaffen. Vielleicht verlierst du dann langsam deine Angst vor den Fortschritten der Softwareentwicklung der letzten 20 Jahre.
Moby, hier ist eine Frage an Dich: - Du hast 2 identische UARTs in deinem µC, beide sollen verwendet werden - RX und TX sollen vollkommen selbstständig im Interrupt laufen - Jeder UART braucht deshalb zwei FIFO-Queues - Du brauchst also Code für 2 UART und insgesamt 4 FIFOs - Du willst kein Flash verschwenden und keine Zeile Code duplizieren [Zeit vergeht] - Es stellt sich raus Du brauchst noch ein dritten UART: - leider gibts keinen mehr, also Software-UART - er soll das selbe Interface wie die anderen beiden UARTs haben und sich genauso verhalten. - Du willst kein Flash verschwenden und keine Zeile Code duplizieren Jetzt lass mal hören wie Du Dir das vorstellst.
Sheeva P. schrieb: >> Wenn denn OOP nur annähernd so simpel wäre... > > Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung > -- kann man in weniger als einer halben Stunde erklären. Kannst du das bitte auch Moby in einer halben Stunde auf 1x A4 erklären? Das würde solche "Kurt"-Threads wie dieser hier erübrigen. ;-)
>Schließen sich Professionalität und einfache Anwendung etwa aus? Eine Motorsäge und ein Harvester machen am Ende das gleiche. Trotzdem liegen in ihrer Bedienung Welten dazwischen. >In der Theorie. Praktisch führt die ineffiziente Anwendung durch den >selten perfekt erfahrenen Programmierer aber zur Vergeudung von >Ressourcen. OOP ist einfach zu komplex anzuwenden. Oft genug ist die wichtigste Rescource die Arbeitszeit. Und wenn ich die auf Kosten von ein paar kB sparen kann (Desktop PC), wenn die Anwendung nicht unbedingt das letzte bisschen Laufzeit erfordert, wird sich mein Chief für die kB nicht interessieren. Außerdem ist auch ein prozedural Prorammierender selten "perfekt erfahren" und baut genau so Mist. Das ist aber nicht die Schuld des Konzeptes.
Moby A. schrieb im Beitrag #4634978: > Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt > schon, wie ineffizient bereits das OS aufgebaut ist. Yep. Wieso haben wir in der Mikro-Computerei eigentlich jemals das Stadium der Fernschreiber als Ein- und Ausgabemedium verlassen? Schon der C64 war doch viel komplexer als nötig. > Auch wenn ich meine Ergebnisse in erster Linie damit erziele langt es > schon noch für den Blick über den Tellerrand- leider mit den > beschriebenen Erfahrungen. Frühe Kartographen pflegten solche Gebiete mit "there be dragons" zu kennzeichnen.
Durchstarter schrieb: > Oft genug ist die wichtigste Rescource die Arbeitszeit. Und wenn ich die > auf Kosten von ein paar kB sparen kann (Desktop PC), wenn die Anwendung > nicht unbedingt das letzte bisschen Laufzeit erfordert, wird sich mein > Chief für die kB nicht interessieren. > Außerdem ist auch ein prozedural Prorammierender selten "perfekt > erfahren" und baut genau so Mist. Das ist aber nicht die Schuld des > Konzeptes. Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und wieviel 1GB Festplattenplatz beim Kunden? Und selbst mit den gammeligsten Skriptsprachen und schlechtesten Frameworks braucht man ein langes Weilchen um dieses GB mit Code vollzubekommen.
Moby A. schrieb im Beitrag #4635007: > VS bietet alle Möglichkeiten der OOP und ist als solches das Spiegelbild > ihrer Komplexität. Das hat erstmal mit Überfrachtung rein gar nix zu > tun. LOL "alle Möglichkeiten der OOP" magst du das bitte näher ausführen, ich kenne ein paar IDEs und OOP kenne ich auch, trotzdem kann ich mir nicht vorstellen was das bedeuten soll? Liegt es an deinem Halbwissen? Moby A. schrieb im Beitrag #4635011: > Sheeva P. schrieb: >> Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür. > > Stimmt. Für diese Form aufgeblasener Programmierung braucht's ne > Ausbildung. Oh wow ich wusste ja gar nicht, dass ich und so viele Leute hochbegabt sind. Eine ganze Ausbildung in so kurzer Zeit allein zu bewältigen, dass ist sehr bemerkenswert. Vielleicht aber überschätzt du das Ganze gänzlich. Aber es gibt ja so einiges, was du hier behauptest... Moby A. schrieb im Beitrag #4634978: > TriHexagon schrieb: >> Nein ganz und gar nicht bedeutet OOP mehr Maschinencode. > > In der Theorie. Praktisch führt die ineffiziente Anwendung durch den > selten perfekt erfahrenen Programmierer aber zur Vergeudung von > Ressourcen. OOP ist einfach zu komplex anzuwenden. Blablabla. Nur haltlose Behauptungen, gib mal ein Beispiel mit Quellcode. Dass eine schlechte Architektur ineffiziente Programme hervorrufen gilt genauso für PP. Moby A. schrieb im Beitrag #4634978: > Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt > schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt > doch dafür die Übergabe einiger Paramater mit sagen wir mal einer > prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP > Programmierung draus? Kilobyteweise Code... Du meinst die WinAPI? Tja bloßt blöd, dass es sich hierbei um PP handelt und nicht, wie du fälschlicherweise glaubst, um OOP. "Kilobyteweise Code" gibts auch nicht. Weißt du wie man ein Fenster in OOP anzeigen lassen kann, wenn man es einfach umsetzt? Das kann so gehen mit einer Zeile, wo ist die Komplexität?
1 | Window win; |
2 | |
3 | //Oder mit ein paar Parametern
|
4 | Window win("Titel", 800, 600); |
Moby A. schrieb im Beitrag #4634978: >> Könnte man dank OOP auch prima erweitern und ausbauen. > > Sicher. Prima erweitern und ausbauen kann ich aber auch schon meine > Asm-Programme. Alles eine Frage gelungener Systematik bei der > Programm-Implementierung. Das wirst du kaum schaffen ohne eine einzige Zeile im bestehenden Code zu ändern. Das ist ja der Clou an der Sache. Ich habe eine Erweiterung nicht vorgesehen und trotzdem muss ich nicht eine einzige Zeile ändern oder in den alten Code hinzufügen, dank OOP. Ich mache eine neue Datei und schreibe eine neue Klasse die von PhysicObject erbt. Sowas wird mit PP ziemlich schwer ohne Funktionszeigern und die baut man nur ein, wenn man sie braucht. Davor wurden sie nicht gebraucht. Und zack schon hat man das Problem. Moby A. schrieb im Beitrag #4634978: >> Dabei kennst du nur AVRs und Asm > > Woher willst Du das wissen? > Auch wenn ich meine Ergebnisse in erster Linie damit erziele langt es > schon noch für den Blick über den Tellerrand- leider mit den > beschriebenen Erfahrungen. So weit kann der Blick nicht gewesen sein, dass du hier so viel Halbwissen rum posaunst.
Moby A. schrieb im Beitrag #4635014: > Sheeva P. schrieb: >> LOL! Du meinst meine kleine Falle, in die Du so "erfolgreich" >> hineingetappt bist? Nee, wat hebbt wij lacht. > > Klar doch. Jetzt war's ne Falle. War es damals schon, das weißt Du doch. > War ja auch ne peinliche Geschichte mit Deinem C-Versuch. Ja, aber nicht für mich. :-) Moby A. schrieb im Beitrag #4635014: > Im übrigen mußt Du Dich in punkto OOP schon entscheiden: Brauchts nun ne > Ausbildung oder passt das Thema auf ein A4 Blatt ? Die OO braucht keine Ausbildung, alles Nötige paßt auf ein Din-A4-Blatt. Bei der Professionalität ging es um IDEs, ich habe das für Dein schwaches Gedächtnis noch einmal rekonstruiert: Scelumbro schrieb: >>> Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein >>> professionlles Werkzeug. Moby A. schrieb im Beitrag #4634978: >> Schließen sich Professionalität und einfache Anwendung etwa aus? Sheeva P. schrieb: > Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür. Wie gesagt: nicht ganz so plump aus dem Zusammenhang reißen, hm? Sonst wird es wieder peinlich für Dich.
Scelumbro schrieb: > Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für > alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein > halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und > wieviel 1GB Festplattenplatz beim Kunden? Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser Einstellung zum schlechtesten Programmierer der Welt machst auf den alle Anwender einen Hass haben. Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle Programme zu gross und zu langsam sind, auf Grund der Arroganz von Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht, so wie es ist", und sich faul zurücklehnen.
A. K. schrieb: > Sheeva P. schrieb: >>> Wenn denn OOP nur annähernd so simpel wäre... >> >> Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung >> -- kann man in weniger als einer halben Stunde erklären. > > Kannst du das bitte auch Moby in einer halben Stunde auf 1x A4 erklären? Einem Troll kann man nichts erklären, weil er das gar nicht will. > Das würde solche "Kurt"-Threads wie dieser hier erübrigen. ;-) Das halte ich für ein Gerücht. ;-)
TriHexagon schrieb: > Weißt du wie man ein Fenster in OOP anzeigen lassen kann, wenn man es > einfach umsetzt? Das kann so gehen mit einer Zeile, wo ist die > Komplexität? >
1 | > Window win; |
2 | >
|
3 | > //Oder mit ein paar Parametern |
4 | > Window win("Titel", 800, 600); |
5 | >
|
Bist Du denn von allen guten Geistern verlassen? Jetzt gleich wird er behaupten, Parameter seien der ultimative Beweis für die "ausgeuferte Bürokratie der OOP". ;-)
MaWin schrieb: > Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle > Programme zu gross und zu langsam sind, auf Grund der Arroganz von > Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle > Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht, > so wie es ist", und sich faul zurücklehnen. Die grösse des Programms hat nichts mit dessen Laufzeit, und nichts mit OOP zu tun. Ausserdem denken viele, grosse ausführbare Dateien bedeuten viel code, was auch nicht zutrifft. Bei grossen Programmen sind meist Ressourcen wie Bilder enthalten, oder es wurden viele statische Libraries mithinein kompiliert und die Option nicht verwendete Methoden zu entfernen nicht gesetzt, oder irgendwo ist ein grosses Array. Die kunden würden es einfach merkwürdig finden, wenn die Anwendung so kompiliert würde, das sie nur wenige KB gross wäre. Die laufzeit ist von der Komplexität, die ein gutes OOP Programm sowisonicht hat, auch nicht wirlich abhängig. Diese ist meistens das Resultat blokierender Aktionen, die nicht in andere Threads ausgelagert wurden, langsamer Netzwerkverbindungen, grosser Datenmengen und nicht idealen Verarbeitungsalgorithman, oder langsamen Winapi operationen, etc. All das hat nichts mit OOP zu tun.
MaWin schrieb: Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser > Einstellung zum schlechtesten Programmierer der Welt machst auf den alle > Anwender einen Hass haben. So einfach ist das nicht, erst recht nicht so pauschal. Du scheinst das nur aus der Sicht von Standardanwendungen zu sehen. Bei Programmen für die Masse ist es sehr nervend, wenn beispielsweise ein Support-Programm fürs Smartphone einen 1Gb Installer mitsamt SQL Express mitbringt, nur weil das für den Anbieter so einfacher ist. Das macht verhasst. Wenn man allerdings eine kundenspezifische Lösung benötigst, dann kann es schon sinnvoll sein, eine zeitlich aufwändige aber schlanke Lösung zu verbilligen, indem man zugunsten kürzerer Entwicklung eine fettere Variante mit vergleichweise billiger Hardware bewirft .
MaWin schrieb: > Scelumbro schrieb: >> Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für >> alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein >> halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und >> wieviel 1GB Festplattenplatz beim Kunden? > > Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser > Einstellung zum schlechtesten Programmierer der Welt machst auf den alle > Anwender einen Hass haben. > > Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle > Programme zu gross und zu langsam sind, auf Grund der Arroganz von > Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle > Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht, > so wie es ist", und sich faul zurücklehnen. Warum kaufen (oder klauen) die Anwender dann genau diese Programme? Warum muß jeder Hansel, der die Helligkeit seiner Urlaubsfotos korrigieren will, dazu unbedingt Photoshop haben? Warum nutzen Anwender Monster wie Wörd, um ein paar Gesprächsnotizen anzufertigen? Einer Anwenderin, die sich darüber beschwert hat, daß das alles so langsam sei, habe ich empfohlen, Gesprächsnotizen einfach mit Notepad zu machen. Da hat die Dame mir tatsächlich erklärt, nur für ein paar Gesprächsnotizen werde sie doch jetzt nicht noch ein neues Programm lernen. Was soll man da noch sagen? Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen, daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei. Sorry, aber solche Probleme liegen nicht an der Software, sondern an den Anwendern selbst und ihren manchmal einfach bescheuerten Forderungen und Erwartungen. Entwickler und Programmierer liefern das, was die Anwender kaufen, und solange sich eine Software mit dem Werbebanner "jetzt noch mehr Funktionen, die kein Mensch je brauchen wird" besser verkaufen läßt, müssen Entwickler und Programmierer solche Funktionen einbauen.
Sheeva P. schrieb: > Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß > es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden > die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein > Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas > mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen, > daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei. > > Sorry, aber solche Probleme liegen nicht an der Software, sondern an den > Anwendern selbst Danke für die erklärend erheitenden Worte. Du nutzt also lieber selbst keine IDE weil zu gross und bulky, sicher in OOP geschrieben, sondern antiquirte (Kommandozeilen) Software, sicher prozedural nach guter alter Art geschrieben, weil die einfach handlicher ist und dem Job angemessen und empfiehlst das auch anderen z.B. mit Notepad (Quellcode habe ich hier) statt Word (OOP). Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die du hier über OOP aufgetischt hast. Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie schon bei "Speichern" unverständlichen Welt wiedersieht. Ich gucke nämlich öfters mal Anwendern über die Schulter, welche Probleme sie so mit Software haben. Übrigens hat nicht jeder Anwender den neuesten i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP Programmierer voraussetzen.
MaWin schrieb: > Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser > Einstellung zum schlechtesten Programmierer der Welt machst auf den alle > Anwender einen Hass haben. > > Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle > Programme zu gross und zu langsam sind, auf Grund der Arroganz von > Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle > Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht, > so wie es ist", und sich faul zurücklehnen. Wärst du bereit für irgendeine Software einen Aufpreis für eine Size-Optimized-Variante zu bezahlen, die sich von der Standardvariante nur dadurch unterscheidet, dass die Binaries (nicht die sonstigen Resourcen, den die üppig bebilderte Onlinehilfe auch für Analphabeten will ja trotzdem jeder) x% kleiner sind? Ein Office-Optimized? Und mit was für einem Effekt? Für ein paar gesparte Minuten beim Download? Für ein paar gesparte MB auf der Festplatte?
MaWin schrieb: > Sheeva P. schrieb: >> Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß >> es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden >> die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein >> Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas >> mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen, >> daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei. >> >> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den >> Anwendern selbst > > Danke für die erklärend erheitenden Worte. Für Dich immer gerne, wenngleich die Erheiterung ganz bei mir liegt. ;-) > Du nutzt also lieber selbst keine IDE weil zu gross und bulky, Nein, da hast Du wohl wieder einmal etwas flashc verstanden. Ich nutze keine IDEs, weil sie mir zu unflexibel sind, weil ich bis dato keine IDE gefunden habe, die alle von mir genutzten Paradigmen und Sprachen -- und darunter sind nicht nur Programmiersprachen, sondern auch Auszeichnungs- und Datenformate wie XML, JSON, HTML, LaTeX -- ähnlich gut unterstützt. Darüber hinaus bin ich allerdings ohnehin kein großer Freund von GUIs, wie sogar Du hättest verstehen können, wenn Du die geistigen Kapazitäten dazu hättest und nicht nur darauf erpicht wärst, mir das Wort im Mund herum zu drehen. Meine Briefe und Präsentationen schreibe ich mit LaTeX statt mit Wörd/LoWriter oder Powerpoint/LoImpress, statt einer Tabellenkalkulation wie Excel benutze ich lieber iPython und Pandas, und wenn ich eine Datenbank haben will, greife ich nicht zu Access oder LoBase, sondern habe PostgreSQL und für simple, kleine Dinge SQLite installiert. Klar, für einige Dinge sind GUI-Programme einfach besser: zum Websurfen, zur Visualisierung, für CAD und interaktive Grafikbearbeitung nutze natürlich auch ich GUI-Software. Aber wo ich GUIs meiden kann, benutze ich keine. Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde es mir nichts ausmachen, eine aufgeblähte Software zu benutzen, wenn ich sie denn benutzen wollen würde. Aber, wie gesagt: ich will ja gar nicht. > Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die > du hier über OOP aufgetischt hast. LOL! Daß jemand, der so etwas wie GALBLAST.C verbrochen hat, mit meinen Aussagen überfordert ist und sie nicht verstehen kann, dafür habe ich ja ein gewisses Verständnis. Aber versteh' bitte auch, daß ich so jemanden nicht ernstnehmen kann, wenn er versucht, mir etwas über Softwaredesign, -paradigmen und -entwicklung zu erzählen. > Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit > Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie > schon bei "Speichern" unverständlichen Welt wiedersieht. Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja, das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst. > Übrigens hat nicht jeder Anwender den neuesten i7-4.5GHz Gaming-PC mit > 16GB, TB-SSD, GBitEthernet wie ihn OOP Programmierer voraussetzen. Es ist zum Glück und erfreulicherweise nicht mein Problem, daß Du noch mit einem dampfbetriebenen 286er unterwegs bist. Wenn Du mehr von Software und Softwareentwicklung verstündest als von primitivem Verbalinjurien und dem gezielten, böswilligen Mißverstehen Deines Gegenübers, ja dann könntest Du vielleicht genug verdienen, um Dir einen richtigen Computer zu kaufen. ;-)
:
Bearbeitet durch User
MaWin schrieb: > Übrigens hat nicht jeder Anwender den neuesten > i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP > Programmierer voraussetzen. Für OOP per se benötigt man keine Highend-Umgebung. OOP bedeutet nicht, dass es sich um einen riesigen Apparat handelt. Zumal man sich die Basis des Prinzips auch interpretiert aneignen kann. Eine solche Umgebung kann allerdings sinnvoll sein, wenn bei grossen Projekten die eingesparte Arbeitszeit teurer ist als die Investition im gute Hardware. Das dürfte freilich auch für FPGA Design gelten.
:
Bearbeitet durch User
Lustige Diskusion. Kann man mit VisualStudio nicht auch ASM-Programme schreiben? Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen führt.
Carl D. schrieb: > Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen > führt. Wenn ich mir den ganzen Kindergarten so anschaue ("wer hat den längsten?"), dann krieg ich ganz andere Blähungen :-)
MaWin schrieb: > Übrigens hat nicht jeder Anwender den neuesten > i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP > Programmierer voraussetzen. Blödes Argument. Ich habe OOP mit Turbo Pascal auf einem nicht vernetzten 286er mit 10Mhz und 512MB RAM gelernt und darauf auch zwei kommerzielle Anwendungen entwickelt. Heutzutage verbergen sich derart leistungsfähige Rechner zum Beispiel in Glühlampen-Fassungen. Mein Smarthone leistet schon ein vielfaches davon, und das ist wahrlich kein High-End Gerät. Abgesehen davon ist die Aussage grundsätzlich falsch, dass OOP den Code oder den Ressourcen-Bedarf wesentlich erhöhe. > OOP bedeutet nicht, dass es sich um einen riesigen Apparat handelt. Yepp
Carl D. schrieb: > Lustige Diskusion. > Kann man mit VisualStudio nicht auch ASM-Programme schreiben? > Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen > führt. Und wenn man die Entwicklung unter einem Windows-Blähsystem mit VS durchführt, statt unter einem ranken schlanken Commandline-Linux mit vi/make, dann wird das gleiche Programm dadurch natürlich um Größenordnungen fetter.
Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...
D. I. schrieb: > Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei > dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ... Sicher, dass dies zu einem anderen Ergebnis führt? Solche Projekte haben eine gewisse Neigung, in die Fritten zu gehen. ;-)
D. I. schrieb: > Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren > bei > dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ... Das macht Moby schon - alleine und in ASM. Gut das Projekt darf nicht komplexer sein, als LED-Blinky + Tastenentprellung. Und es muss auf einem AVR laufen, schließlich ist x86 ASM zu komplex. Aber dann wird es total effizient programmiert werden. Schließlich kann nur einer dran arbeiten, dass heisst keine Schnittstellen, keine Architektur, keine Absprachen,keine Meetings- kein Overhead, 100% Effizienz.
A. K. schrieb: > D. I. schrieb: >> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei >> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ... > > Sicher, dass dies zu einem anderen Ergebnis führt? Solche Projekte haben > eine gewisse Neigung, in die Fritten zu gehen. ;-) Nun ja das Ding lebt schon relativ lange und steckt in diversen Endprodukten in unterschiedlicher Ausprägung in realen Produkten und wird halt weiterentwickelt.
Moby A. schrieb im Beitrag #4635958: > Sheeva P. schrieb: >> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den >> Anwendern selbst und ihren manchmal einfach bescheuerten Forderungen und >> Erwartungen. > > Damit hast Du wunderschön auf den Punkt gebracht was ich Dir an anderer > Stelle schon vorgehalten habe: Die Bedürfnisse Deiner Programmierung und > Deines Systems über die Forderungen und Erwartungen des Anwenders zu > stellen. Stichwort Admin-Welt! Das ist wieder mal der selbstherrliche > Entwickler wie er im Buche steht. Der Gott in weiß- äh der Gott am PC > ;-( Weißt Du, ich arbeite gar nicht für Microsoft oder Adobe, und habe mit den genannten GUI-Monstern aus diesen Häusern nicht einmal als Anwender etwas zu tun. Es ist auch nicht meine Schuld, und erst recht nicht mein Problem, daß es immer noch Leute gibt, die dieses Zeug kaufen. Für die Feststellung, daß kommerzielle Software immer aufgeblähter werden wird, je länger das Argument "jetzt mit neuen Funktionen, die kein Mensch braucht" noch beim Verkauf zieht, bedarf keines besonderen Genies, sollte also auch für Deinen Intellekt einigermaßen zugänglich sein. Die meisten Anwender von Word, Excel, Access, Powerpoint und Photoshop werden jedoch heute schon von ihrer Software überfordert und benutzen nur einen kleinen Bruchteil der Funktionen dieser Software. Und natürlich rede ich nicht davon, an den Forderungen und Erwartungen von Anwendern vorbei zu entwickeln, was für eine selten dumme Interpretation. Ganz im Gegenteil kritisiere ich, daß Kaufanreize immer noch über neue, unnötige Funktionen gesetzt werden, anstatt sich darauf zu beschränken, die benötigte und sinnvolle Funktionalität mit einer sauberen Usability anzubieten. Gerade von Dir mit Deiner manischen Phobie gegenüber allem, das komplizierter ist als ein Loch in den Schnee zu pinkeln, hätte ich da eher volle Zustimmung erwartet. Stattdessen versuchst Du schon wieder, mir die Worte im Mund herum zu drehen... Langsam bekomme ich eine Idee davon, wen Einstein gemeint hat, als er von unendlicher Dummheit sprach. :-)
Moby A. schrieb im Beitrag #4635945: > Sheeva P. schrieb: >> War ja auch ne peinliche Geschichte mit Deinem C-Versuch. >> >> Ja, aber nicht für mich. :-) > > Also ich schrieb nichts in C. Natürlich nicht. Das kannst Du ja auch gar nicht.
Moby/Sheeva: Meint ihr wirklich, dass ihr mit wechselseitigen Beschimpfungen weiter kommt?
Sheeva P. schrieb: > wenn Du die geistigen Kapazitäten dazu hättest und nicht nur darauf > erpicht wärst, mir das Wort im Mund herum zu drehen. Bei dir muss man nicht Worte im Mund umdrehen, sondern ich ordne nur deine kruden Aussagen hier. Du hingegen, nein, du verstehst das: Sheeva P. schrieb: >> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit >> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie >> schon bei "Speichern" unverständlichen Welt wiedersieht. > > Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja, > das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst. nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die anderen vorhalten, was sie selber tun, sind krank. Such dir einen Psychiater. Sheeva P. schrieb: > LOL! Daß jemand, der so etwas wie GALBLAST.C verbrochen hat, mit > meinen Aussagen überfordert ist und sie nicht verstehen kann, dafür habe > ich ja ein gewisses Verständnis. Es steht dir frei, das Programm besser zu schreiben (wäre nach 20 Jahren ja mal Zeit, ist noch Win16), es ist open source. Aber von Dummschwätzern wie dir kommt natürlich kein eigener Handschlag, und die Anwender finden es gut zu bedienen, gut zu verstehen, gut zu benutzen, sehen also keine Veranlassung es zu verunstalten. Stefan U. schrieb: >> Übrigens hat nicht jeder Anwender den neuesten >> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP >> Programmierer voraussetzen. > > Blödes Argument. Das Argument brauchte ich gar nicht bringen, das kommt hier: Sheeva P. schrieb: > Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde > es mir nichts ausmachen, eine aufgeblähte Software zu benutzen, Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben darauf OOP-Software bis sie meinen daß alles in Odnung ist und angemessen schnell läuft, und dann kommt die Software zum Anwender: Stefan U. schrieb: > Ich habe OOP mit Turbo Pascal auf einem nicht vernetzten 286er mit 10Mhz > und 512MB RAM gelernt Welchem auch immer, eben nicht dem leistungsfähigen Entwicklungsrechner sondern dem realen Gerät und alle regen sich ZU REHT über die lahmbarschige Bloatsoftware von Sheeva auf.
> weil ich bereits beim Design auf die nötige ... achte. > Alles andere ist m.M.n. als Gesamtkonzept Pfusch. Tja, du hast echt Glück, wenn du Projekte mit sauberem Gesamtkonzept umsetzen darfst. In der Praxis ist es leider oft so, dass Kosten und Zieltermin schon vor dem Funktionsumfang festgelegt werden. Dann werden Funktionen gefordert, die sich gegenseitig stören bzw. wegen unvollständigem Konzept nicht funktionieren können. Irgendwann sagt Dir dein Auftraggeber "Fang schonmal an und mach irgendwas sinnvolles. Die Detaul überlegen wir uns noch". Und dann werden nur einige Konzept-Lücken geschlossen, stattdessen ständig andere Funktionen gefordert. Und zwar nicht selten bis zum letzten Tag vor der Abnahme - falls überhaupt eine offizielle Abnahme stattfindet. Manche diese Forderungen stellen das gesamte Design der Software in Frage. Und jetzt stelle Dir so ein Projekt vor, verteilt auf drei Firmen, die sich nicht gerade lieb haben (da Konkurrenten) beauftragt von einem Kunden, der Keine Ahnung hat (von Technik, Juristischen Aspekten und dem Business) und trotzdem meint, selbst Projektleiter spielen zu können. DAS, mein lieber Moby, ist die Realität, mit der sie die allermeisten Programmierer tagtäglich herum schlagen müssen. Programmieren können ist nur die halbe Miete (eher noch weniger). Projektarbeit ist die Kür. Und zum Ausgleich arbeiten einige davon an Open-Source Projekten mit oder machen ihre eigene Show, damit sie wenigstens einmal im Leben ein aus ihrer Sicht sauberes Projekt durchziehen können, das man auch vorzeigen kann ohne sich in den Boden zu schämen. Ich behaupte, daß sich die Entwickler von 90% aller kommerziellen Programme für ihre eigenen Werke schämen, da sie nichtmal die eigenen Ansprüche von Qualität erfüllen.
Moby A. schrieb im Beitrag #4635907: >> > > Scelumbro nochmal für Dich: Das hat auch niemand behauptet (jedenfalls > ich nicht). > Eine IDE wie VS zeigt aber alle konkreten Möglichkeiten der OOP auf, ist > insofern (und auch im Blick auf die vielen angebotenen > Spezial-Werkzeuge) Spiegelbild ihrer Komplexität Moby, komplexe Software ist nicht die Folge von komplexen Programmiersprachen. Ihre Komplexität ist vielmehr die Summe vieler einfacher Teile. Die einfache Kombinierbarkeit dieser einfachen Teile ist aber ein Vorteil von OOP. Viele Teile einer IDE haben auch nichts mit der Programmiersprache an sich zu tun sondern bearbeiten Probleme rund um ein Projekt wie Versionsverwaltung.
Moby A. schrieb im Beitrag #4634978: > Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt > schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt > doch dafür die Übergabe einiger Paramater mit sagen wir mal einer > prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP > Programmierung draus? Kilobyteweise Code... Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du bitte NICHT objektorientierte Programmierung mit irgend einer Klassenbibliothek oder sonstiger Middleware. Ich geb dir mal ein Beispiel: Wenn du mit Delphi eine GUI-Anwendung schreibst, dann kostet dich ein simples "Hello World" bei Delphi 6 so um die 400 KByte, bei Delphi 10 schon über 2 MB und wenn man dann noch nen gefälligeren Skin drauf haben will, an die 3 MB - so etwa. Das liegt aber NICHT an OOP, sondern an der jeweiligen Klassenbibliothek und deren Grundstruktur, die ein echt4s Smart-Linking nicht zuläßt. Wenn du hingegen mal sowas wie KOL (Key Objects Lib) ausprobiert hättest, was nach einigem Installations-Eiertanz unter Delphi 6 recht ordentlich läuft, dann würdest du sehen, daß das gleiche GUI-Programm lediglich einige Dutzend KB (ich schätze so 20..25 K) benötigt. Und auch die KOL ist tatsächlich OOP. siehe: "http://wiki.freepascal.org/KOL" MaWin schrieb: > Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit > Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie > schon bei "Speichern" unverständlichen Welt wiedersieht. Eben. Verstehe ich genauso. In diesem Punkte treffen wir uns mal wieder. Die Meinige macht auch ALLES mit MS Office, selbst Dinge, die ich damit nie zuwege bringen würde. Das ist eben immer wieder die für manche befremdliche tatsache, daß Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS Office geübt ist, ist damit weitaus besser und effektiver als jemand, der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich hier einen). ich sehe auch in der Firma viele, die mitdem Explorer geradezu artistisch umgehen, was mir selbst (als TC-Benutzer) nicht sonderlich genehm ist. OK, unsereiner kann damit selbstverständlich umgehen, aber eben nicht so effektiv wie jemand, der damit warmgeübt ist. Und bei der betreffenden Anwenderin sieht das genauso aus. Die Dame hat ganz gewiß ein völlig anderes Arbeitsfeld und genau dieses ist es, wo sie richtig gut sein muß - da ist sowas wie der PC nur eben das, was er sein soll: ein Hilfsmittel und eben nicht der berufliche Lebensinhalt. Ganz viele der Schreiber hier in diesem Forum ignorieren das immer wieder, bis hin dazu, daß so einer neulich solche Anwender und Anwenderinnen als "brain dead" bezeichnet hat. Brett vor'm Kopf kann ich dazu nur sagen. W.S.
MaWin schrieb: > Sheeva P. schrieb: >>> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit >>> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie >>> schon bei "Speichern" unverständlichen Welt wiedersieht. >> >> Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja, >> das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst. > > nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese > Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die > anderen vorhalten, was sie selber tun, sind krank. Such dir einen > Psychiater. Es war nicht die Anwenderin, sondern es warst Du, der mit dem "Speichern" angefangen hat. Zum Glück hast Du die Entstehungsgeschichte meiner Aussage ja bereits selbst zitiert; vielen Dank dafür, daß Du es diesmal wenigstens korrekt und in der richtigen Reihenfolge zitiert hast. Und was das dummdreiste Provozieren angeht, kann ich Dir da lange nicht das Wasser reichen. Beinahe jeder "Beitrag" von Dir ist mit persönlichen Angriffen gespickt, nicht nur in diesem Thread hier. Jetzt rastest Du aus, weil dieses Mal jemand dagegenhält und sich Deine wirren Pöbeleien nicht widerspruchslos gefallen läßt. Das ist einerseits lustig, aber auch sehr schade, denn schließlich wußten schon unsere Mütter: wie man in den Wald hineinruft, so schallt es wieder heraus. Oder, kurz gesagt: wenn Du schon so ein Mimöschen bist, solltest Du dringend damit beginnen, Dein eigenes Sozial- und Kommunikationsverhalten zu überarbeiten. MaWin schrieb: > Übrigens hat nicht jeder Anwender den neuesten > i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP > Programmierer voraussetzen. > > Sheeva P. schrieb: >> Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde >> es mir nichts ausmachen, eine aufgeblähte Software zu benutzen, Ich habe die Zitate mal in die richtige Reihenfolge gebracht: tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort, insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst. Es ist wirklich schade, daß jemand, der so viel von Elektronik versteht wie Du, so unfähig ist, ohne Beleidigungen zu kommunizieren. Daß Du Dich unter Verdrehung der Tatsachen aber jetzt noch zum, selbstverständlich gänzlich unschuldigen Opfer stilisierst, ist entweder unglaublich frech oder ein Zeichen dafür, daß Du ein Problem mit der Diskrepanz ziwschen Deiner Selbst- und Außenwahrnehmung hast, und die mir so warm empfohlene professionelle Hilfe sehr viel nötiger hast als ich. Viel Glück!
Moby A. schrieb im Beitrag #4636025: > A. K. schrieb: >> Moby/Sheeva: Meint ihr wirklich, dass ihr mit wechselseitigen >> Beschimpfungen weiter kommt? > > Ich beschimpfe niemand. Trotzdem kann und sollte man manchen Leuten > natürlich deutlich ihre Defizite vor Augen führen. Ein SheevaP hat das > mit seinem Kommunikationsniveau ganz besonders nötig. :-)
W.S. schrieb: > Moby A. schrieb im Beitrag #4634978: >> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt >> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt >> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer >> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP >> Programmierung draus? Kilobyteweise Code... > > Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du > bitte NICHT objektorientierte Programmierung mit irgend einer > Klassenbibliothek oder sonstiger Middleware. Danke für diesen sachlichen, unaufgeregten Beitrag. > Das ist eben immer wieder die für manche befremdliche tatsache, daß > Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch > verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS > Office geübt ist, ist damit weitaus besser und effektiver als jemand, > der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich > hier einen). Natürlich. Dennoch erscheint es mir einigermaßen widersprüchlich, wenn die Anwender dieser Software sich dann einerseits über deren Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf einfache und bereits installierte Alternativen zurückweisen. Stattdessen wurden in dem von mir vorgebrachten Beispiel dann gleich drei Admins, ein Vorgesetzter, und ein Mitarbeiter des Einkaufs in Marsch gesetzt und dann eine Erweiterung des Arbeitsspeichers für die Dame verbaut. Das Problem, daß die Dame über zu langsame Software beklagt, ist leider trotzdem geblieben. Solche Geschichten begegnen unseren Admins ständig: ein Anwender will unbedingt die teuerste Version seines Betriebssystems, kann aber weder sagen, was der Unterschied zur einfachen Variante ist, noch, welche Funktionen der teueren Version er braucht. Ein anderer Anwender möchte dringend eine Photoshop-Lizenz um ein paar Bilder zu skalieren, weil er Photoshop ja von zuhause kennt, und schreit unseren Einkäufer an, wenn sein Ansinnen abgelehnt und stattdessen PSP empfohlen wird. Gleichzeitig sehe ich die Diskussionen hier im Forum, wo Windows-User zu Linux wechseln, weil sie von Windows die Nase voll haben, und sich dann darüber beklagen, daß Linux nicht genauso wie Windows ist... ach, war gerade das nicht der Grund für den Wechselgedanken? Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und Entwicklersicht sehe. Trotzdem komme ich beim besten Willen nicht um die traurige Feststellung herum, daß die Erwartungen, die manche Anwender an ihre Software, ihre Entwickler und ihre Admins stellen, manchmal einfach unrealistisch, und in anderen Fällen schlicht ignorant sind. Niemand kann mir einreden, daß daran immer nur die Admins und Entwickler schuld seien. Und ich glaube, die unkritische Haltung "der Anwender hat immer Recht" ist eine der wesentlichen Ursachen für die unrealistische Erwartungshaltung und die daraus resultierende Unzufriedenheit vieler Anwender. Aber laßt uns zum eigentlichen Thema zurückkommen: der OO.
Sheeva P. schrieb: > Ich habe die Zitate mal in die richtige Reihenfolge gebracht: > tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem > dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren > meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort, > insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst. Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also, daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt. Offensichtlich bist du aber überfordert, Satz und Sachverhalt nachzuvollziehen. Sheeva P. schrieb: > Niemand > kann mir einreden, daß daran immer nur die Admins und Entwickler schuld > seien. Dachte ich mir. Nennt man wohl Blindheit gegenüber eigenen Defiziten. Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR IHN sollte die Software geschrieben sein, schlieb also nicht plump die Schuld auf ihn. Daß der Entwickler schlechte Rahmenbedingungen gehabt haben mag, vor allem zu wenig Zeit, Überforderung, mag alles als Entschuldigung herhalten. Letztlich hat er es aber verbrochen, selbst wenn die Vorgaben von einem fachlich uninformierten Chef kamen. Red dich also nicht raus und schieb die Schuld auf andere. Leider gibt es von deinr Sorte viele unter den Entwicklern. Sheeva P. schrieb: > Aber laßt uns zum eigentlichen Thema zurückkommen: der OO. Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da diskutiert es sich ja noch mit einem Islamisten besser. Aber so wie der Wasser predigt und Wein trinkt, so predigst du OOP, nutzt aber lieber Programme die ordentlich geschrieben wurden. Danke, mehr woltlen wir nicht wissen.
MaWin schrieb: > Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR > IHN sollte die Software geschrieben sein, schlieb also nicht plump die > Schuld auf ihn. Du behaupest also, Anwender können nicht zu dumm für ihre Arbeit sein?
Ui, hier ist ja wieder was los... MaWin schrieb: > Sheeva P. schrieb: >> Ich habe die Zitate mal in die richtige Reihenfolge gebracht: >> tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem >> dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren >> meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort, >> insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst. > > Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also, > daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt. Also ich habe das ganz anders verstanden. Du hast Entwicklern und Admins pauschal und böswillig unterstellt Ressourcen zu verschwenden. Sheeva hat nur gesagt daß er sich eine Ressourcen verschwendende IDE leisten kann weil er auf seinen Rechnern genügend Power hat. > Offensichtlich bist du aber überfordert, Satz und Sachverhalt > nachzuvollziehen. Offensichtlich willst Du ihn mißverstehen um ihn zu provozieren. > Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR > IHN sollte die Software geschrieben sein, schlieb also nicht plump die > Schuld auf ihn. Wenn die Software für die Anwender geschrieben wäre würden sie nicht dauernd darüber schimpfen. Entweder ist die Software also nicht für die Anwender geschrieben oder die Anwender kaufen die falsche Software. Er erklärt das mit den Mechanismen des heutigen Softwaremarktes. Du hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst? > Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da > diskutiert es sich ja noch mit einem Islamisten besser. Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. Merkst Du eigentlich noch was?
> oder die Anwender kaufen die falsche Software.
Viele (vielleicht gar die meisten) Anwender müssen mit Software
arbeiten, die andere gekauft haben. Diese ärgern sich dann besonders
schnell über Mängel.
Karl Käfer schrieb: > Wenn die Software für die Anwender geschrieben wäre würden sie nicht > dauernd darüber schimpfen. > Entweder ist die Software also nicht für die Anwender geschrieben Das stimmt natürlich sogar manchmal, beispielsweise bei Produkten wie Windows, wo es nicht den einen Kunden gibt, sondern alle Kunden etwas vorgesetzt bekommen. Aber Auftragsentwicklung hätte natürlich den Kunden für den sie geschrieben wird, und Software für den Markt sollte so sein daß möglichst viele Menschen als Anwender in Frage kommen. > oder die Anwender kaufen die falsche Software. Kann schon sein, manchmal haben sie keine Wahl. Daher zahlen sie wohl auch so ungerne dafür: Die Erlebnisse waren zu schlecht als daß die Software was wert gewesen wäre. > Er erklärt das mit den Mechanismen des heutigen Softwaremarktes. Er erklärt es eher gar nicht, sondern sagt einfach der Anwender ist schuld, der hat doch gefälligst seine Sofwtare toll zu finden. > Du hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst? Es liegt oft an Leuten wie Sheeva, die nicht in der Lage sind, sich in andere Menschen hineinzuversetzen und hochtrabend selbstüberzeugt glauben ihre Position wäre die einzige richtige. Eben wie religiöse Dogmatiker. Sheeva ist so ziemlich das Abziehbild von dem Entwickler der alles falsch macht: - Er glaubt, in OOP Läge das Heil. - Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker Software) als Entwicklungrechner als sie später der Kunde hat. - Er sieht die Fehler beim Anwender und nicht bei sich selbst. >> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da >> diskutiert es sich ja noch mit einem Islamisten besser. > > Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. Im Gegenteil, er ist schlimmer.
MaWin schrieb: > - Er glaubt, in OOP Läge das Heil. Meiner Erfahrung nach ist das tatsächlich so. MaWin schrieb: > - Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker > Software) als Entwicklungrechner als sie später der Kunde hat. Aber sicher doch. Ein Entwicklungsrechner kann garnicht genup Power haben. Trotz Xeon mit 16 Kernen (hyperthreaded), 32 Gig RAM und SSD baue ich an meinen aktuellen Projekten z.T. > 1h. Der Rechner dürfte also gerne noch schneller sein :-) (ja, die Projekte sind groß) Zum TESTEN kann man dann gerne Gammel-Rechner einstzen, wie sie manche Kunden noch verwenden... MaWin schrieb: > - Er sieht die Fehler beim Anwender und nicht bei sich selbst. Auch der Anwender ist nicht über jeden Zweifel erhaben...
:
Bearbeitet durch User
MaWin schrieb: >> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. > > Im Gegenteil, er ist schlimmer. Weil er er wagt, gegen Deine und Mobys krude OOP-Verschwörungstheorien anzudiskutieren? Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges stichhaltiges Argument. Pfui.
Stefan K. schrieb: > Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges > stichhaltiges Argument. Pfui. Hmm, dein einziger Beitrag hier. Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung. Du ahst also im ganzen Thread nichst gebracht. Stefan, das ist: Unter aller Sau.
MaWin schrieb: > Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung. Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett mitgelesen? Oder verwechselst Du irgendwen? Persönliche Diffamierung finde ich hier hauptsächlich in Deinen Beiträgen.
Moby A. schrieb im Beitrag #4635907: > Das hab ich mir noch nicht vorstellen müssen weil ich bereits beim > Design auf die nötige Anzahl identisch ansprechbarer Hardware-UARTS > achte. Alles andere ist m.M.n. als Gesamtkonzept Pfusch. Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus Konstengründen gestrichen. Also was ist jetzt?
Stefan K. schrieb: > Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett > mitgelesen? Oder verwechselst Du irgendwen? Bist du Sheeva Plug ? Argumente lieferte er jedoch nicht, bloss Behauptungen. Und versucht sich in frechen Umdeutungen Da behauptet er: ! > Wie schlecht objektorientierte Formulierungen von durchaus ! > objektorientierten Welten sein können, sieht man an MFC. ! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern ! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI. daß MFC kein OOP wäre. Das ist schlicht gelogen, aber irgendwie muss er ja vermeiden daß seine allumfassendee Heilsbotschaft "OOP ist gut" Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um das WinAPI, aber nichtsdestrotrotz OOP und Grundlage für viele OOP Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und schlecht wartbar, aber immer noch eine Realisierung in OOP. Das darf natürlich nach seiner Heilsdoktrin nicht sein. Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges. Also immer erst mal vor der eigenen Haustür kehren. > Persönliche Diffamierung finde ich hier hauptsächlich in Deinen Beiträgen. Blinde mit Scheuklappeen, ja ja.
Bernd K. schrieb: > Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen > zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus > Konstengründen gestrichen. > > Also was ist jetzt? Moin, darauf zu Pochen ist müßig bei Moby. Erweitern von Projekten kennt er nicht und da haben schon gefühlt 100 Leute in anderen Threads nachgehakt, nachgefragt... verzweifelt. Heb dir deine Kraft für die Diskussion um OOP auf^^. Zum Topic. Ich bin immer etwas verwundert, warum die Leute so Probleme mit dem Konzept haben. Eigentlich abstrahiert es doch die Realität viel besser als rein prozedurale Programmierung. Das wird ja in der Naturkunde auch so gemacht. Hier ein Beispiel aus aktuellem Anlass :) Apfel --- Birne Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden (Ableitungen). Moby A. schrieb im Beitrag #4636020: > Dann erstelle mal ein leeres Win-Fenster mit Visual C++ und schau Dir > die resultierende Codegröße an. Da wird Dir auch ein > >> Window win("Titel", 800, 600); > > im Programm wenig Ersparnis bringen. > Wenn freilich die paar Ascii-Bytes dieser Zeile schon das ganze > Programm wären... So einfach ist es aber leider nicht. Warum nur? Zugegenermaßen in C# ist die Datei 6,5K groß. Du tust allerdings so, als wenn jedes eingebene Zeichen die Datei proportional weiter vergößern würde. Die größten Platzfresser bei den Programm sind aber nun mal nicht die Code Binaries, sondern die restlichen Ressourcen wie Bilder, Daten und ähnliches. Ach ich seh grad. Ich hab ausgerechnet Moby zitiert. Bitte ignorieren. Grüße.
MaWin schrieb: > Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges. Ich fordere hier einen besseren Umgangston ein. Beleidigungen und persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen "Diskussionsbeiträgen") werden in diesem Forum nicht toleriert: MaWin schrieb: > Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser > Einstellung zum schlechtesten Programmierer der Welt machst auf den alle > Anwender einen Hass haben. MaWin schrieb: > Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die > du hier über OOP aufgetischt hast. MaWin schrieb: > Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben > darauf OOP-Software bis sie meinen daß alles in Odnung ist und > angemessen schnell läuft, und dann kommt die Software zum Anwender: MaWin schrieb: >>> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da >>> diskutiert es sich ja noch mit einem Islamisten besser. >> >> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. > > Im Gegenteil, er ist schlimmer.
Stefan K. schrieb: > persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen > "Diskussionsbeiträgen") werden in diesem Forum nicht toleriert Deine hingegen schon ? Merkwürdige Lebensauffassung. Stefan K. schrieb: > krude OOP-Verschwörungstheorien > purer Populismus. > Hetze ohne ein einziges stichhaltiges Argument. > Pfui.
Nach >> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. > > Im Gegenteil, er ist schlimmer. war das ja wohl mehr als angemessen. Dafür, dass Du andere Forenteilnehmer mit Gewalttätern gleichsetzt, bist Du bei Deiner eigenen Person merkwürdig empfindlich.
:
Bearbeitet durch User
>Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in >Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden >(Ableitungen). ^^Vielleicht gibt es ja deshalb so viel Schlechtes in der Welt - weil sie auf OO gründet! (Tut mir leid, konnt´s mir nicht verkneifen)
Karl Käfer schrieb: > Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. > Merkst Du eigentlich noch was? Stop mal, mein Junge! Du bist es, der hier nichts merkt. Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit einem Islamisten besser". Abgesehen davon kann ich mich immer noch an einen Papst erinnern, der mit dem Attentäter, der es auf ihn abgesehen hatte, diskutiert hat. Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das sachliche Ausdiskutieren von Argumenten ein. Aber stattdessen sehe ich hier bösartige Unterstellungen und ne Menge Fanatismus. Sheeva P. schrieb: > Dennoch erscheint es mir einigermaßen widersprüchlich, wenn > die Anwender dieser Software sich dann einerseits über deren > Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf > einfache und bereits installierte Alternativen zurückweisen. Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows und gerade MS Office von Milliarden von Leuten benutzt werden. Glaubst du ernsthaft, diese wären alle mental gleichgeschaltet? Natürlich nicht! Also gibt es immer eine Verteilung von Ansprüchen und Meinungen. Ob Gauss oder ne andere Verteilung. Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe ich nirgendwo - ganz besonders nicht "einfache und bereits installierte Alternativen". Was denn bitte? Nein, das war lediglich ein vorlauter Zungenschlag deinerseits. Ich hab vor vielen Jahren in der Firma die Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus Leuten, die eben nicht zum EDV-Gesindel gehören. Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht dort gefunden haben, wo sie bisher waren. Begreif das mal als ein echtes Problem. Es IST ein echtes Problem. Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die 167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen sind anders, ebenso die Mengen usw. Verstehst du, was ich meine? Sheeva P. schrieb: > Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und > Entwicklersicht sehe. Zumindest ist die Erkenntnis dessen ein erster Schritt. ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das dahinterstehende Prinzip ist es, worauf es ankommt: "Schreib dein Manual so, als ob du es für einen alten Advokaten schreiben würdest. Der versteht von deiner Arbeit und deinem Fache reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen. Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz - jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im Gesagten hattest und nicht wo sein Verstand zu gering wäre." W.S.
MaWin schrieb: > Stefan K. schrieb: >> Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett >> mitgelesen? Oder verwechselst Du irgendwen? > > Bist du Sheeva Plug ? Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin ich jedenfalls nicht er. > Argumente lieferte er jedoch nicht, bloss Behauptungen. Du scheinst mich mit jemandem zu verwechseln, eventuell mit Dir selbst. > Und versucht sich in frechen Umdeutungen > > Da behauptet er: > ! > Wie schlecht objektorientierte Formulierungen von durchaus > ! > objektorientierten Welten sein können, sieht man an MFC. > ! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern > ! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI. > daß MFC kein OOP wäre. Das ist schlicht gelogen, Das wäre es, wenn ich das gesagt hätte. Habe ich aber gar nicht, wie Du selbst hättest bemerken können, wenn Du nicht mehr Energie investieren würdest, mich mißzuverstehen, als darin, meine Aussagen zu lesen. Tatsächlich habe ich nicht geschrieben, daß die "MFC kein OOP wäre". Was ich geschrieben habe, ist, daß die MFC kein OO-Design ist, sondern nur ein OO-Wrapper um eine im Kern prozedurale API, die WinAPI. Verstehst Du nicht den Unterschied zwischen "kein OO" und "kein OO-Design"? Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein OO-Schnittstelle zu einer nicht-OO-API statt eines OO-Designs ist; daß sie aus einer Zeit stammt, in der es noch nicht sehr viele Erfahrungen mit OO unter C++ gab und die OO unter C++ noch relativ unausgereift war; daß Microsoft damals dazu tendierte, Frameworks unnötig aufzublähen und die interne Funktionalität seines Betriebssystems als Geschäftsgeheimnis zu betrachten. Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als Beispiel für die Stärken oder Schwächen der OO zu betrachten; da eignen sich echte OO-Frameworks wie Qt, wxWidgets, die Boost-Libraries oder sogar .NjET viel besser. > aber irgendwie muss er ja vermeiden daß seine allumfassendee > Heilsbotschaft "OOP ist gut" Das ist gar nicht meine Botschaft, und das habe ich auch nie gesagt. In Wahrheit habe ich sogar ganz ausdrücklich geschrieben: "OO ist nur eins von einer ganzen Reihe von Werkzeugen, die ich nutze" [1], daß "die verbreiteten Sprachen [] alle mehrere Paradigmen unterstützen", die "in der Praxis [] oft parallel genutzt" werden [2], daß ich "bei großen Datenmengen [] eher zu funktionalen Techniken [tendiere]" [3], und: "Wenn es morgen eine einfachere Möglichkeit gibt, dann bin ich der Erste, der sie adoptiert" [4]. Von einer "Heilsbotschaft", gar einer "allumfassenden", habe ich nichts geschrieben, das findet alles nur in Deinem eigenen Kopf statt. Pardon, aber für die Vorgänge in Deinem Kopf bin ich nicht verantwortlich. [1] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?" [2] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?" [3] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?" [4] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?" > Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber > natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um > das WinAPI, Nichts anderes habe ich gesagt, und das hier: > aber nichtsdestrotrotz OOP und Grundlage für viele OOP > Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und > schlecht wartbar, aber immer noch eine Realisierung in OOP. ...steht dem, was ich gesagt habe, nicht entgegen. Das Problem scheint zu sein, daß Du nicht zuhörst und deswegen oft etwas ganz anderes liest, als Dein Gegenüber schreibt, und Dich dann an den Strohpuppen hochziehst, die nur in Deinem eigenen Kopf stattfinden. Das andere Problem ist, daß Du zwar wacker austeilen, aber nicht einstecken kannst, und mit Widerspruch, sagen wir mal, eher mäßig gut umgehen kannst. > Blinde mit Scheuklappeen, ja ja. Wer im Glashaus sitzt, ...
Es gibt schon komische Leute hier, weil sie das Konzept von OOP nicht verstehen ist es Teufelszeug und als Kronzeuge dafür muss MS herhalten. Leute die auch mal über ihren Tellerand schauen und in OOP auch Vorteile erkennen werden wild beschimpft und als blöd abgestempelt. Und das Lamentieren über Programmgrößen und Performance ist überhaupt nicht nachvollziehbar. 1. Hat das nichts mit OOP zutun und 2. ist die aussage, dass ein leeres Fenster zuviel Speicher braucht ungefähr so wie die, dass ein LKW zuviel Diesel brauch und zu langsam ist, um an die Arbeit zu fahren.
W.S. schrieb: > Karl Käfer schrieb: >> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. >> Merkst Du eigentlich noch was? > > Du bist es, der hier nichts merkt. > Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter > gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat > stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit > einem Islamisten besser". MaWin hat dieser Interpretation jedenfalls nicht widersprochen. > Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das > Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das > sachliche Ausdiskutieren von Argumenten ein. Das sachliche Ausdiskutieren bedingt zunächst einmal das Vorbringen von sachlichen Argumenten. MaWin hat zu diesem Thread bisher nur unbelegte Behauptungen, bösartige Unterstellungen und wüste Pöbeleien "beigetragen", oder kannst Du mir ein einziges sachliches oder gar begründetes Argument von ihm zeigen? Schon sein erster Beitrag in diesem Thread beinhaltet a) die unbelegte Behauptung, die Unterstützung durch die OOP sei eine offene Frage, b) die Unterstellung, alle Uniabsolventen könnten kein C++ sowie c) die unsinnige Behauptung, die MFC sei eine objektorientierte Bibliothek und demonstriere, wie schlecht die OOP sei. Und das war noch sein mit Abstand harmlosestes Posting in diesem Thread, denn schon in seinem zweiten "Beitrag" hier mißversteht er mich böswillig und absichtlich und behauptet, mir mangele es an Hirn, das irgendjemand deswegen werfen möge. In einem ähnlichen Stil geht der zweite "Beitrag" dann auch gleich weiter: KFZ-Hersteller sind allesamt arrogant und darum nicht daran interessiert, potentiell tödliche Fehler an ihren Produkten zu beheben. Dann wieder gezielt und persönlich gegen mich: die "Analysen", von denen er keine zitieren oder verlinken kann, soll ich -- "weil ich es gerne will" -- "von der Hand wischen" wollen, und was ich "nicht will, das gibt es nicht"; ich "mache mir das Leben schön", lebe "in einer Traumwelt" und "im Notfall" (in welchem eigentlich?) "rede" ich mich "'raus". Im dritten Beitrag ist dann Scelumbro das Ziel, der "der schlechteste Programmierer der Welt" sein soll, "auf den alle Anwender einen Hass haben". Wenn Du magst, kann ich noch seitenweise weitermachen, schlage jedoch vor, daß wir uns das für diesmal sparen. Zu all dem hast Du nichts gesagt, um Karl nun mit dieser Spitzfindigkeit zu kommen, da sei doch gar nicht die Person, sondern nur die Diskussion gemeint gewesen? Ach kommm. > Aber stattdessen sehe ich hier bösartige Unterstellungen und ne Menge > Fanatismus. Ja, aber die gehen allesamt von genau zwei Usern aus. Ich freue mich aber, daß Du in einem der beiden Fälle mittlerweile etwas gesagt hast und auch selbst zu einem sachlichen Umgang gefunden hast. Danke dafür. > Sheeva P. schrieb: >> Dennoch erscheint es mir einigermaßen widersprüchlich, wenn >> die Anwender dieser Software sich dann einerseits über deren >> Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf >> einfache und bereits installierte Alternativen zurückweisen. > > Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows > und gerade MS Office von Milliarden von Leuten benutzt werden. Ja, natürlich, das ist das inhärente Merkmal von Standardsoftware. Aber wenn Du Dir mal zum Beispiel die Apple-Software anschaust, dann erkennst Du schnell, warum die gerade bei solchen Leuten besonders erfolgreich war und ist, die mit der Technik ganz besonders wenig zu tun haben wollen: Grafiker, Musiker, und andere Kreative. Das liegt auch nicht (nur) daran, daß die Macs schön hip aussehen, sondern das war auch schon so, als die Macs noch genau dieselben langweiligen beigen Kisten waren wie die PCs. (Um Weiterem vorzubeugen: mein letzter Mac war ein Mac II). > Glaubst du ernsthaft, diese wären alle mental gleichgeschaltet? Nein, wie kommst Du darauf? Habe ich das irgendwo gesagt oder auch nur angedeutet? > Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe > ich nirgendwo - ganz besonders nicht "einfache und bereits installierte > Alternativen". Was denn bitte? Es ging dabei um ein konkretes Beispiel, in dem für den Anwendungsfall "Gesprächsnotizen" statt MS Wörd als "einfache und bereits installierte Alternative" Notepad empfohlen worden war. Da kann ich mich ziemlich gut dran erinnern, denn schließlich habe ich diese Story selbst erlebt und hier als Beispiel eingebracht. > Ich hab vor vielen Jahren in der Firma die > Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel > wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus > Leuten, die eben nicht zum EDV-Gesindel gehören. Auch in diesem Punkt habe ich nie etwas Gegenteiliges behauptet. Würde ich auch nie, schon gar nicht, weil wir im letzten Jahr von Groupwise auf MS Exchange und Outlook umgestellt haben, mir die Schwierigkeiten dabei voll bewußt und gut erinnerlich sind, und wir uns immer noch mit verschiedenen Nickeligkeiten als Ergebnis der Migration herumschlagen. Damit habe ich selbst zwar glücklicherweise nicht viel zu tun, bekomme es aber natürlich bei den Kollegen in den anderen Teams immer noch hautnah mit. > Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben > dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten > und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht > dort gefunden haben, wo sie bisher waren. > Begreif das mal als ein echtes Problem. > Es IST ein echtes Problem. Das weiß ich alles und habe auch niemals etwas anderes gesagt, oder? Hier ging es aber doch gar nicht um verschiedene Versionen von MS-Office oder um Alternativen dazu, sondern einzig und alleine darum, daß Notepad für schnelle Notizen nun einmal besser geeignet ist als Wörd oder ein anderer Wortprozessor. Nur darum ging es, und um nichts anderes. (Ganz am Rande bemerkt: "Notepad" heißt übersetzt soviel wie "Notizblock", was IMHO sehr eindeutig darauf hinweist, wofür dieses Programm besonders geeignet ist.) Wie kommst Du darauf, daß es um verschiedene Office-Versionen gegangen sei? Drücke ich mich wirklich so unklar aus? Mache ich zu viele Worte für die junge Generation Twitter, oder wo liegt das Problem? Schau, ich verstehe sehr gut, daß Anwender nicht zwischen GUI-Monstern wechseln wollen, wenn sie einmal eins gelernt haben. Was ich aber nicht verstehe, ist, daß sie a) immer zu den fetten Profimonstern greifen, wenn sie die Wahl haben, und b) für Aufgaben, die mit verfügbarer, einfacher, kleiner und flotter Software wie Notepad gelöst werden könnten, trotzdem immer noch zu denselben fetten Monstern greifen. > Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für > DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen > Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild > heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen > und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene > wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die > 167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun > wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen > sind anders, ebenso die Mengen usw. Verstehst du, was ich meine? Mein Sanskrit ist nicht mehr so gut, und mit den Hieroglyphen hatte ich schon in der Schule meine Schwierigkeiten... Nein, im Ernst: wenn Du mir sagen willst, daß die Umstellung auf eine neue Software einen Lernaufwand erfordert, bin ich ganz bei Dir, wenngleich ich den Lernaufwand in dem oben genannten Beispiel -- also: den "Umsteig" von Wörd auf Notepad für einfache Notizen -- für ausgesprochen überschaubar halte. > Sheeva P. schrieb: >> Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und >> Entwicklersicht sehe. > > Zumindest ist die Erkenntnis dessen ein erster Schritt. Dann wird es Dich vielleicht freuen, daß ich mir dieser Erkenntnis bereits seit vielen Jahren bewußt bin, sie mich allerdings trotzdem nicht davon abhält, mir aus meiner ganz persönlichen, professionellen Perspektive eine Meinung über das leider oft inkonsistente und irrationale Verhalten von "normalen Anwendern" zu bilden. Die "normalen Anwender" setze ich da mal in Anführungszeichen, weil es so etwas meiner Meinung nach nicht wirklich gibt; die Wahrnehmung von Anwendern als Individuen mit individuellen Vorstellungen, Bedürfnissen und Arbeitsweisen erscheint mir jedenfalls zielführender als die grobe Einteilung zwischen "normale" und "unnormale" Anwender. ;-) > ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß > behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das > dahinterstehende Prinzip ist es, worauf es ankommt: > > "Schreib dein Manual so, als ob du es für einen alten Advokaten > schreiben würdest. Der versteht von deiner Arbeit und deinem Fache > reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen. > Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz > - jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen > rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört > dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann > auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im > Gesagten hattest und nicht wo sein Verstand zu gering wäre." Das ist alles schön, gut und auch sehr richtig, betrifft mich aber nicht. Ich entwickle keine Software für Endanwender, sondern für einen äußerst exklusiven Personenkreis, in welchem ich jedes einzelne Mitglied seit Jahren persönlich kenne. Ich habe das schon einmal geschrieben, aber es ist anscheinend untergegangen: mit Endanwendern wie der im Beispiel genannten Dame habe ich nur insoweit zu tun, als diese mich mögen, meine Kompetenzen schätzen (was beides auf Gegenseitigkeit beruht, am Rande bemerkt), und darum mit ihren Problemen erst zu mir kommen, bevor sie unsere Windows-Techniker fragen. Meine eigentlichen Aufgaben liegen eher in einem Bereich, der neudeutsch als "Big Data", "Data Mining" und "Data Science" bezeichnet wird: Analyse, Exploration, Visualisierung von Daten, Distributed Computing, Skalier- und Hochverfügbarkeit, Echtzeit-Streaming, solche Dinge. Ich entwickle keine Anwendersoftware und betreue weder Anwender noch Anwendersoftware. Die einzigen armen Leute, die mit meiner Software arbeiten müssen, sind meine Mitarbeiter und Kollegen sowie ich selbst, und wir alle kommen mit meiner Software erstaunlich gut zurecht. Insofern ist MaWins Unterstellung, ich würde Anwender mit aufgeblähten OO-Programmen nerven, selbst jedoch eher schnelle PP-Software nutzen, ganz flashc. Im Moment benutze ich hauptsächlich Apache Spark, Apache Storm und ein paar andere Werkzeuge aus dem Hadoop-Universum, die samt und sonders objektorientiert sind, und die von mir verwendete GUI-Software wurde mit Ausnahme des GNU/Emacs ebenfalls objektorientiert entwickelt. Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert, vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden sind, noch in den Kinderschuhen steckte.
Sheeva P. schrieb: > Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und > ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert, > vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden > sind, noch in den Kinderschuhen steckte. Neben dem Alter würde ich mal behaupten, dass viele Kommandozeilenprogramme vom Umfang her auch nicht wirklich eine OOP brauchen. Die meisten Programme beschränken sich ja auf einen Input, einen Output und ein paar Parameter, die noch übergeben werden. Klassisches EVA-Prinzip halt.
W.S. schrieb: > Karl Käfer schrieb: >> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. >> Merkst Du eigentlich noch was? > > Stop mal, mein Junge! > > Du bist es, der hier nichts merkt. > Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter > gleichgesetzt. Meine Interpretation hat MaWin doch mittlerweile selbst bestätigt und sogar geschrieben er sei schlimmer. Das war übrigens noch bevor Du Deinen Beitrag gepostet hast. Vielleicht merk ich mehr als Du denkst? ;)
Sheeva P. schrieb: > Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein > OO-Schnittstelle zu einer nicht-OO-API Du kennst dich wohl nicht so aus, denn das WinAPI ist eine sehr gute Implementation eines OO-Designs in normalem C. Objekte werden durch Handles abgebildet, was self Pointer in das Datensegment des Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B. vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden etc. und Fensterklassen um Unterklassen erweitern, DefWndProc. Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine class. Weitere von dir abgeleitet Schlussfolgerungen sind damit genau so falsch. Sheeva P. schrieb: > Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als > Beispiel für die Stärken oder Schwächen der OO zu betrachten; Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt. Allerdings sind sher viele Programme damit geschrieben, es halt also sher wohl einen erklecklicher Anteil an der Realität der OO Software. > Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin > ich jedenfalls nicht er. Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und behauptet das wären seine Argumente. Sheeva P. schrieb: > MaWin hat dieser Interpretation jedenfalls nicht widersprochen. Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr so lange ihnen niemand widerspricht und ziehst Diskussionen daher so lange durch bis dir genervt niemand mehr widerspricht. Funktionierte vielleicht bei deiner Mama, im echten Leben eher nicht. Es gibt sehr viel Software. Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben. Es gibt sehr viel schlechte Software. Viele der Software ist schlecht trotz der OO Techniken. Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden ist. Eine richtige statistische Auswertung gibt es dazu nicht. Aber die Annahme, es wäre durch OO besser geworden, darf stark angezweifelt werden. Das tue ich, und begründe es, unter anderem weil man in C++ an vielen Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext kein einziges Zeichen steht. Das führt meiner Erfahrung nach zu schlechter Wartbarkeit und dazu daß Programmierer den Überblick verlieren wie aufwändig die Sachen sind die sie machen, also langsame Bloatware erzeugen. Gegenargumente kamen keine. Demnach stimmt es also, nach deiner Weltsicht. Du ziehst über GalBast her. Dieses (winzige) Programm jedoch besser zu machen bringst du nicht, stattdessen investierst du ein mehrfaches an Mühe hier deine Desinformationen zu erarbeiten. Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir.
MaWin schrieb: > Das tue ich, und begründe es, unter anderem weil man in C++ an vielen > Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext > kein einziges Zeichen steht. Das must du mal genauer Erklären. Was soll denn ausgeführt werden, was nicht im Quelltext steht? Du meinst jetzt aber nicht so trivialkram wie ctor und dtor, oder doch?
MaWin schrieb: > Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir. Das sagt bereits alles. Typen wie MaWin kann/darf/sollte man nicht ernst nehmen...
MaWin schrieb: > Es gibt sehr viel Software. > Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben. > Es gibt sehr viel schlechte Software. > Viele der Software ist schlecht trotz der OO Techniken. > Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden > ist. Was ist den das für eine Argumentationstechnik? > Es gibt sehr viel Software. > Ein guter Teil davon ist ohne OO Techniken geschrieben. > Es gibt sehr viel schlechte Software. > Viele der Software ist schlecht trotz des Verzichts auf OO Techniken. > Die Frage wäre, ob Software 'dank' Verzicht auf OO besser oder schlechter > ist. Hast du sonst noch Argumente? Wie wäre es damit: You Can Write FORTRAN in any Language MaWin schrieb: > Aber die Annahme, es wäre durch OO besser geworden, darf stark > angezweifelt werden. Genauso wie die Annahme, dass Software ohne OO besser wäre. MaWin schrieb: > Das tue ich, und begründe es, unter anderem weil man in C++ an vielen > Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext > kein einziges Zeichen steht. C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, in den man externe Bibliotheken einbindet.
Karl schrieb: > Das gleiche Argument gilt für jeden anderen Quelltext, in den > man externe Bibliotheken einbindet. Das ist falsch, du hast es offenbar nicht verstanden. Wenn man eine externe Bibliothek einbindet, passiert dadurch zunächst einmal nichts. Damit etwas passiert, muss man die exportierten Funktionen dieser Bibliothek aufrufen. Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas hinschreiben, eineen Funktionsaufruf. Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion durch die externe aufgerufene Funktion. Das sieht man schon beim Ansehen des Quelltextes, und kann nachforschen, z.B. welche Seiteneffekte sie hat. > C++ != OO. Kann man so verstehen daß C++ nicht die reine Lehre des OO widerspiegelt. Oder daß C++ sowieso keine OO Sprache wäre. Du wirst dieses hingerotze != also interpretieren wie es dir gerade in den Kram passt.
MaWin schrieb: > Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas > hinschreiben, eineen Funktionsaufruf. > > Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion > durch die externe aufgerufene Funktion. Aha, und bei OO passiert einfach so etwas, ohne das man etwas hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da vorstellst? MaWin schrieb: >> C++ != OO. > > Kann man so verstehen daß C++ nicht die reine Lehre des OO > widerspiegelt. > > Oder daß C++ sowieso keine OO Sprache wäre. > > Du wirst dieses hingerotze != also interpretieren wie es dir gerade in > den Kram passt Nein, das brauche ich nicht. Ich habe dir nur gezeigt, dass deine Argumentation nichts mit OO zutun hat sondern mit der Programmiersprache C++. Ich könnte genauso behaupten, dass Prozedurale Programmierung schlecht ist, weil C zu Speicherüberläufen führt. Hat bloß nichts miteinander zu tun.
Christian M. schrieb: > ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir > erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. > Kann mir einer verklickern, wofür das gut sein soll? Wenn Du damit schon so Probleme hat, wird Dich funktionale Programmierung in den Selbstmord treiben.
Karl schrieb: > Ich habe dir nur gezeigt, dass deine Argumentation nichts mit OO > zutun hat sondern mit der Programmiersprache C++. Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt, mit dem du behauptest alles gesagt zu haben. Na dann, shut up.
Du hast geschrieben: MaWin schrieb: > Aber die Annahme, es wäre durch OO besser geworden, darf stark > angezweifelt werden. > Das tue ich, und begründe es, unter anderem weil man in C++ an vielen > Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext > kein einziges Zeichen steht. Worauf ich antwortete: Karl schrieb: > C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, ... Deine Argumentation mit C++ gegen OO macht immer noch keinen Sinn. Schade das du es nicht erkennst. Karl schrieb: >> Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion >> durch die externe aufgerufene Funktion. > > Aha, und bei OO passiert einfach so etwas, ohne das man etwas > hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da > vorstellst? Ich würde mich über ein Beispiel freuen! MaWin schrieb: > Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt, > mit dem du behauptest alles gesagt zu haben. Na dann, shut up. Genau C++ ist nicht Objektorientierte Programierung oder kurz C++ != OO. Als jemand der sich mit Programierung beschäftigt, solltest du das doch verstehen. Eine Interpretation, wie von dir gefordert, ist bei einer Ungleichung nicht notwendig. Hinrotzen geht im Internet auch nicht, da wurde noch keine App für erfunden, das Verb heißt schreiben.
Streitet euch doch nicht. Das Thema kann man doch ganz sachlich diskutieren... MaWin schrieb: > [...], denn das WinAPI ist eine sehr gute > Implementation eines OO-Designs in normalem C. Objekte werden durch > Handles abgebildet, was self Pointer in das Datensegment des > Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B. > vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen > sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden > etc. und Fensterklassen um Unterklassen erweitern, DefWndProc. Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems nicht zwangsläufig objektorientiert aufgebaut sein muss, um für Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu sein. Dass man die Techniken dann auch sprachlich verfügbar macht (Klassen, Vererbung) ist dann eine logische Konzequenz (und Verbesserung). Ein (weiterer) großer Vorteil der OOP, den ich insbesondere im Zusammenhang mit Grafikprogrammierung sehe, ist, dass man selbst bei dynamisch erzeugten Objekten auf Pointer verzichten kann (gilt wohl nicht für C++). Allein das macht einem das Leben schon deutlich einfacher, auch wenn die Probleme mit falschen Referenzen die gleichen sind.
MaWin schrieb: > Sheeva P. schrieb: >> Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein >> OO-Schnittstelle zu einer nicht-OO-API > > Du kennst dich wohl nicht so aus, Das stimmt. Windows, die Windows-API und die MFC habe ich mir das letze Mal vor rund zwanzig Jahren angeschaut und bin dann schnell davongelaufen. Sorry, das ist nicht meine Welt: in a world without walls and fences, who needs windows and gates? > denn das WinAPI ist eine sehr gute Implementation eines OO-Designs in > normalem C. Ach, die einen sagen so, die anderen anders. Was OO ist und was nicht, da halte ich mich -- wie Du meiner Konversation oben mit dem klugen Daniel Abrecht entnehmen kannst -- streng an den Erfinder der OO, Alan Kay. Nach diesem Maßstab ist die Windows API nicht objektorientiert, aber wenn Du magst, kannst Du das natürlich gerne anders sehen. > Objekte werden durch Handles abgebildet, Wenn ich mich recht entsinne, durch Void-Pointer... How to accidentally shoot yourself six times in the foot. > Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet > wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine > class. Ja, äh... und? In manchen OO-Sprachen gibt es eine Klasse Integer, in Java zum Beispiel -- trotzdem gibt es auch in Java noch einen nativen Datentyp int. In Python gibt es old-style Klassen, die nicht von _builtin_.object erben, und new-style Klassen, die das tun; das fällt einem immer dann auf, wenn man von einer Tkinter-Klasse (old-style) erben will und die Methoden der Elternklasse nicht mit "super()" aufrufen kann. C++ ist aber nur eine Implementierung der OO -- manche sagen sogar, keine besonders gelungene -- und nicht der Maßstab für OO. > Sheeva P. schrieb: >> Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als >> Beispiel für die Stärken oder Schwächen der OO zu betrachten; > > Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt. Aus meiner Sicht zeigt die MFC nur, daß man auch mit OO beschissene APIs designen kann. Überraschung, wer hätte das gedacht?! Und, noch wichtiger: wer hätte das jemals bestritten? Ich jedenfalls nicht. Das ändert aber nicht das Geringste daran, daß man mit C++ auch sehr elegante und saubere APIs designen und implementieren kann, think Qt. Aber wenn Du eine wirklich vollkommen verkackte API sehen willst, dann schau Dir doch spaßeshalber einfach mal OpenSSL an. Völlig prozedural, komplett ohne OO, und trotzdem total, absolut, und auf ganzer Linie komplett verkackt. Verglichen damit ist sogar die MFC ein Wunderwerk technischer Eleganz und genialer Implementierung! Aber käme ich jetzt auf die Idee, deswegen die PP zu verdammen und das, was Du über die OO behauptest, andersherum über die PP sagen? Natürlich nicht. Und wenn doch, würdest Du mich zurecht genauso auslachen wie ich das gerade umgekehrt mache. > Allerdings sind sher viele Programme damit geschrieben, es halt also > sher wohl einen erklecklicher Anteil an der Realität der OO Software. Aber -- und das ist der kleine, feine Unterschied -- nicht an der OO. Deine Strategie ist es, Dir eine beschissene OO-Implementierung heraus zu suchen, darauf herumzuhacken, wie beschissen sie ist, und das dann auf die OO zu schieben. Ich habe einige andere OO-Implementierungen genannt: Qt, WxWidgets, die Boost-Bibliotheken, .NjET und die STL. Mein Argument dabei ist, daß es offensichtlich möglich ist, saubere, verständliche OO-Designs und -Implementierungen zu entwickeln. Geh' doch einfach mal auf dieses Argument ein, oder paßt Dir das nicht in den Kram? >> Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin >> ich jedenfalls nicht er. > > Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und > behauptet das wären seine Argumente. Nein, er sagt, das seien meine Argumente. Bitte lern lesen, das würde die Diskussion wirklich ganz enorm vereinfachen. > Sheeva P. schrieb: >> MaWin hat dieser Interpretation jedenfalls nicht widersprochen. > > Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr Aus meiner (natürlich subjektiven) Sicht sind meine Aussagen wahr, sonst würde ich sie ja nicht äußern. Es ist Dir unbenommen, eine andere Sicht zu haben und natürlich ebenso, diese zu äußern. Wenn Du sie dann auch noch sachlich und idealerweise sogar ohne Verbalinjurien begründen kannst, dann -- aber nur dann -- schaffst Du es vielleicht sogar, mich von Deiner Sicht zu überzeugen. Probier es doch einfach mal. Ich bin ein vernunftbegabter Mensch (ok, meistens jedenfalls), und gegenüber sachlichen, schlüssigen, logisch konsistenten und begründeten Ideen (fast) immer aufgeschlossen. > so lange ihnen niemand widerspricht Papperlapapp: Du hast Deine Aussage ja sogar noch einmal bekräftigt, indem Du Dich zu der absurden Beleidigung verstiegen hast, ich sei sogar noch schlimmer als ein fanatischer Gewalttäter. > und ziehst Diskussionen daher so lange > durch bis dir genervt niemand mehr widerspricht. Funktionierte > vielleicht bei deiner Mama, im echten Leben eher nicht. Bei Deiner Mama hat es jedenfalls prima geklappt. ;-) > Es gibt sehr viel Software. Richtig, danke für den Hinweis. > Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben. Ebenfalls richtig, danke nochmals. > Es gibt sehr viel schlechte Software. Wiederum richtig, aber ebenfalls keine Überraschung. > Viele der Software ist schlecht trotz der OO Techniken. Und noch einmal richtig, langsam wirst Du mir unheimlich. > Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden > ist. Das mag Deine Frage sein. Meine erste Frage ist allerdings, ob sich durch die OO überhaupt etwas an der Softwarequalität geändert hat, und erst die zweite Frage ist dann für mich, ob zum Guten oder zum Schlechten. > Eine richtige statistische Auswertung gibt es dazu nicht. Die dürfte auch ziemlich schwierig werden, schließlich fällt mir auf Anhieb ein gutes Dutzend an Qualitätsmerkmalen für Software ein. Und selbst wenn wir uns auf bestimmte Kriterien einigen könnten, bleibt da immer noch die Frage der Gewichtung. > Aber die Annahme, es wäre durch OO besser geworden, darf stark > angezweifelt werden. Natürlich. Ebenso darf aber auch die Annahme bezweifelt werden, daß es durch die OO schlechter geworden sei. Meine ganz persönliche Meinung dazu ist allerdings, daß sich in Wahrheit überhaupt gar nichts geändert hat. Es gibt qualitativ minderwertige OO- und ebenso minderwertige PP- und FP-Software, es gibt hochwertige OO- und ebenso hochwertige PP- und FP-Software. Überraschung: Software wird immer noch von Menschen gemacht! Von Menschen, die ihre Werkzeuge mal mehr, mal weniger gut beherrschen. Gute Entwickler entwickeln daher gute, schlechte Entwickler schlechte Software. Solange das der Fall ist, wird es gute und schlechte Software geben, und daran können und werden Programmierparadigmen leider auch nichts ändern. > Das tue ich, und begründe es, unter anderem weil man in C++ an vielen > Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext > kein einziges Zeichen steht. Abgesehen davon, daß OO nicht C++ und C++ nicht OO ist -- man kann in C++ problemlos auch prozedural und funktional entwickeln -- scheinst Du da ein anderes C++ zu kennen als ich. Kannst Du mir bitte ein konkretes Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.
Sheeva P. schrieb: > Kannst Du mir bitte ein konkretes > Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke. Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt, als einsichtig gemacht.
Beaker schrieb im Beitrag #4638054: > Mimi mimi miiiiii > Mimi mimi miiiiii Beaker, meine Lieber! Dass ich Dich wiedergefunden habe! So eine Freude. https://www.youtube.com/watch?v=g0b6J5O2UdI
Kupferstecher schrieb: > Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems > nicht zwangsläufig objektorientiert aufgebaut sein muss, um für > Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu > sein. Schon wieder solche Behauptungen, die von purer Ahnungslosigkeit zeugen. Also: Das API von Windows ist definitiv prozedural und NICHT objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen" sollte man sich nicht verleiten lassen, auch das API des OS als OO anzunehmen. Wer sich mal ein objektorientiertes OS anschauen will, sollte über EPOC-OS bzw. Symbian-OS nachlesen. Das war - nebenbei gesagt - eine echte Spaßbremse für Anwendungs-Programmierer, weil als Programmiersprache einzig C++ benutzbar war, weswegen es kaum Anwendungen für diesen Zweig der Betriebssysteme gab. Das, was hier vermutlich gemeint worden ist, ist nicht "objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied! W.S.
W.S. schrieb: > Also: Das API von Windows ist definitiv prozedural und _NICHT_ > objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen" > sollte man sich nicht verleiten lassen, auch das API des OS als OO > anzunehmen. > > Das, was hier vermutlich gemeint worden ist, ist nicht > "objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied! Das, was hier gemeint worden ist, ist objektorientiert! - Die Zugriffe über Handles stellen die Objektreferezen dar. - Allein das Arbeiten mit Structs/Records ist schon eine Vorstufe zur Objektorientierung. - Die Kapselung der Funktionen zum Betriebssystem. Das sind alles Konzepte aus der Objektorientierung. Oder anders rum, die Objektorientierung benutzt genau diese Konzepte. Die OOP ist ja nicht zufällig entstanden.
Karl schrieb: > Sheeva P. schrieb: >> Kannst Du mir bitte ein konkretes >> Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke. > > Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu > erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt, > als einsichtig gemacht. Willst Du wohl bitte aufhören, weiteres Öl ins Feuer zu gießen!? Danke.
Meiner Meinung nach haben sich die Programmiersprachen immer in bestimmten Kontexten entwickelt. OOP hat sich mit der Einführung der graphischen Benutzeroberflächen entwickelt, dort kann man die "Objekte" ja auch richtig sehen. Es macht ziemlich viel Sinn, die Eigenschaften von graphischen Elementen zu vererben und diese zu erweitern. Eine "reichhaltige" graphische Oberfläche in Assembler zu programmieren, wäre wohl ziemlich mühselig. Dass man OOP Konzepte später für alles Mögliche wie Treiber oder ähnliches verwenden kann, betrachte ich eher als einen Seiteneffekt. Lisp dagegen hat sich im Umfeld der künstlichen Intelligenz Forschung entwickelt und ist für deren Probleme eher geeignet.
Hier noch was passendes: http://www.heise.de/developer/artikel/Vererbung-fuer-Objekte-nuetzlich-fuer-Werte-gefaehrlich-3254433.html
chris_ schrieb: > Hier noch was passendes: > http://www.heise.de/developer/artikel/Vererbung-fuer-Objekte-nuetzlich-fuer-Werte-gefaehrlich-3254433.html Guter Artikel! Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der leider die guten Beiträge in dem von einigen wenigen Ahnungslosen verursachten Dauerlärm untergehen. Der Artikel zeigt anhand eines Beispiels, wie OOP falsch angewendet werden kann bzw. wo die Grenzen gewisser Konzepte (in diesem Fall der Implementierungsvererbung) liegen. Man kann jetzt natürlich wie ein Rohrspatz über OOP schelten, weil sie nicht idiotensicher ist. Aber das wäre so, als lehne man Autos ab, weil beim Autofahren mehr Fehler passieren können als beim Zufußgehen. Was die Implementierungsvererbung betrifft, ist sich ja sogar James Gosling, der Entwickler von Java, nicht mehr ganz sicher, ob das ein gutes Konzept ist: http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html
1 | ... someone asked him [James Gosling]: "If you could do Java over again, |
2 | what would you change?" "I'd leave out classes," he replied. ... he |
3 | explained that the real problem wasn't classes per se, but rather |
4 | implementation inheritance (the extends relationship). Interface |
5 | inheritance (the implements relationship) is preferable. You should |
6 | avoid implementation inheritance whenever possible. |
> Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der > leider die guten Beiträge in dem von einigen wenigen Ahnungslosen > verursachten Dauerlärm untergehen. Unterstrichen Punkt OOP heisst Objekt-Orientierte-Programmierung und nicht Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich). Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark. Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden. Problematisch wird bei O-Orgien-Programmierung die Klassenstruktur. Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von Komposition benutzt wird. Sieht man sich OO Programme im Grossen an, sieht es oft aus wie Spaghetti. Ein solcher Code ist nur sehr schwer zu pflegen. Die Verheissungen der Wiederverwendbarkeit haben sich geradezu als Fluch erwiesen. Das Problem liegt nicht in der Wiederverwendung selbst sondern in unüberlegter Verwendung von Klassen aus fremdem Kontexten. Es ist unerlässlich, Bereiche abzugrenzen, geradezu Feuerwände einzuziehen, die es nicht erlauben, Klassen aus anderen Bereichen unbesehen zu verwenden. In diesem Sinne wird Software von Architekten erstellt. Den Code erstellen Programmier-Maurer. Einfamilienhäuser können Maurer (Meister) erstellen, Hochhäuser Architekten. Beispiele: die Elbphilharmonie und der Kölner Dom ;-) Hier kann ich diese Frage stellen: Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und Eagle, Hardware entwickeln lassen?
Heiner K. schrieb: > Hier kann ich diese Frage stellen: Ja, gewissermaßen ... > Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und > Eagle, Hardware entwickeln lassen? ... denn umgekehrt sehen das viele hier als selbstverständlich an. ;-)
:
Bearbeitet durch User
Christian M. schrieb: > Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String > manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die > Zahl das Objekt sein...?! > > Intern wird es ja eh prozedural verarbeitet. > > Bin ich zu alt? Nein. Einen String kann man gut als Objekt oder Klasse verstehen. Er wird mit Methoden manipuliert, dabei ändert sich sein Inhalt, Zustand (meistens). Richtig Sinn macht es erst, wenn ein Bild im Browser betrachtet wird. Es kann verschoben, verkleinert, gedreht usw. werden. UND man kann leicht ein Bild mit Rahmen daraus machen. Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit. Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist man gezwungen, daraus eine Klasse zu machen. Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung: Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu. OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus. Das kann schon verwirren. Ich empfehle sich zunächst mit dem Konzept von OOP vertraut zu machen. Leider geht das nicht mal eben auf einer Seite. Zunächst würde ich darauf in Javascript zu verzichten. Später finden sich dann sinnvolle Anwendungen. Mir sind die häufigen Abfragen nach dem Browser ein Dorn im Auge. Das ist ein typischer Fall, wo Polymorphismen prozedural aufgelöst werden. Anscheinend ist nicht leicht, OOP sinnvoll anzuwenden. Christian, wenn Du später diese Aussage verstehst, solltest Du mit OO anfangen.
Heiner K. schrieb: > Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit. > Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings > auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist > man gezwungen, daraus eine Klasse zu machen. Es wurde ja weiter oben in diesem Thread schon geschrieben, dass das Math-Objekt ein Weg ist, mehrere Symbole (Funktionen und Konstanten) in einem Namensraum zusammenzufassen. In C++ gibt es zu diesem Zweck Namespaces, in Java und Python Module. Da es in Javascript weder Namespaces noch Module gibt, könnte man auf die Idee kommen, stattdessen eine Klasse mit lauter static-Elementen anzulegen, die im Wesentlichen denselben Zweck erfüllt. Da es in Javascript aber auch keine Klassen gibt, wird dort stattdessen ein Objekt verwendet. > Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung: > Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu. > OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus. > Das kann schon verwirren. Die (nichtexistenten) Klassen in Javascript werden durch ihren Konstruktor repräsentiert, der seinerseits natürlich eine Funktion ist. Das ist an sich nicht schlimm, aber für Leute, die von Java, C++ oder Delphi kommen, ungewohnt. Um diesen Leuten entgegenzukommen, gibt es in Javascript inzwischen eine syntaktisch an Java und C++ angelehnte Klassendeklaration der Form
1 | class MyClass { |
2 | constructor(x) { ... } |
3 | methode1(x, y) { ... } |
4 | ... |
5 | } |
Echte Klassen gibt es deswegen aber immer noch nicht, denn diese Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist MyClass nach wie vor eine Funktion, was man leicht mit
1 | typeof(MyClass) ——> function |
feststellen kann. Heiner K. schrieb: > Zunächst würde ich darauf in Javascript zu verzichten. Das kommt darauf an: Man lernt ja OOP meist nicht als reine Philosophie losgelöst von jeglicher Anwendung, sondern um danach in einer konkreten Sprache programmieren zu können. Das kann Java oder C++ sein für PC-Anwendungen oder eben Javascript, falls das Interesse eher in Client-Side-Internet-Anwendungen liegt. IMHO lernt man mit Java oder C++ nicht "besser" OOP als in Javascript. Nur wenn man wirklich tiefer in die "Philosophie" der Objektorientierung vorstoßen möchte, sollte man sich eher mit einer reinen OOP-Sprache, wie bspw. Ruby oder Scala beschäftigen (Smalltalk lasse ich mal auf Grund des hohen Alters außen vor). Diese Sprachen zwingen einen regelrecht, alles in Klassen zu packen, was einem auch eine gute Chance gibt, die Grenzen der OOP zu erkennen.
Yalu X. schrieb: > Echte Klassen gibt es deswegen aber immer noch nicht, denn diese > Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist > MyClass nach wie vor eine Funktion, was man leicht mit > > typeof(MyClass) ——> function > > feststellen kann. Das dachte ich lange auch. Dann musste ich feststellen, das damit auchnoch eine Überprüfung eingebaut wurde, ob man es mit new aufgerufen hat. Dass muss sein, weil super eingefürt wurde, welches kurzform für new.target.prototype.constructor ist, wobei new.target nur gesetzt ist, wenn mit new aufgerufen. Ich würde gerne solche Dinge tun:
1 | function ProxifyEarly(constructor,handler,...args){ |
2 | var o = Object.create(constructor.prototype); |
3 | var p = new Proxy(o,handler); |
4 | return constructor.apply(p,...args) || o; |
5 | }
|
6 | |
7 | function MyClass1(){} |
8 | ProxifyEarly(MyClass1,{}); // ok |
9 | |
10 | class MyClass2{} |
11 | ProxifyEarly(MyClass2,{}); // TypeError: class constructors must be invoked with |new| |
Man hätte new.target und super auch anders auflösen können, aber so wie es jetzt ist, ist es ein unlösbares Problem. Dabei hätte ich so tolle Anwendungsmöglichkeiten dafür gehabt, wenn ich schon das this im constructor vor dessen aufruf in einen Proxy hätte packen können...
Heiner K. schrieb: > OOP heisst Objekt-Orientierte-Programmierung und nicht > Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit > dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht > vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich). Vollkommen richtig. Leider wird in vielen Lehrbüchern zu OOP-Sprachen die Vererbung als die große Errungenschaft herausgestellt, weil es die meisten anderen Konzepte wie Kapselung und verschiedene Formen der Polymorphie auch in Nicht-OOP-Sprachen gibt. So entsteht beim Leser der Eindruck, ein OO-Design sei nur dann gut, wenn möglichst viele Klassen zueinander in einer Vererbungsbeziehung stehen. Umgekehrt: Schafft der Leser es nicht, die einzelnen Klassen seines Programms voneinander erben zu lassen oder gemeinsame Basisklassen zu finden, weil die Problemstellung einfach keinen Anlass dafür gibt, hat er ein schlechtes Gewissen und denkt, er hätte die OOP noch nicht verstanden. > Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark. > Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden. Ebenfalls Zustimmung. Aber gerade, weil die Kapselung nicht OOP-spezifisch ist, wird sie in der OOP-Literatur zwar behandelt, aber im Vergleich zur Vererbung nicht ganz so sehr in den Vordergrund gestellt. Da die Kapselung ohne viel Nachdenken sowieso leicht zu bewerkstelligen ist, konzentriert der Lernende seine geballte Kreativität auf eine möglichst komplexe Klassenhierarchie :-) > Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur > noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von > Komposition benutzt wird. Solche Dinge wie - wann man Vererbung einsetzt und wann besser Komposition oder gar nichts von beidem, - wann man eine Funktion als instanzbezogene Memberfunktion definiert und wann besser als instanzunabhängige Klassenfunktion oder (in C++) als freie Funktion, und - falls man sich für eine instanzbezogene Memberfunktion entscheidet, in welche Klasse man sie packt (es gibt genügend Beispiele, wo das absolut nicht trivial ist), lernt man erst in der Fortgeschrittenenliteratur, die aber kaum einer liest, weil man ja mit dem Anfängerbuch bereits alle Sprachelemente kennengelernt hat. Hier ist noch ein Zitat vom C++-Entwickler Stroustrup zu diesem Thema:
1 | Please note that object-oriented programming is not a panacea. "OOP" |
2 | does not simply mean "good" - if there are no inherent hierarchical |
3 | relationships among the fundamental concepts in your problem then no |
4 | amount of hierarchy and virtual functions will improve your code. The |
5 | strength of OOP is that there are many problems that can be usefully |
6 | expressed using class hierarchies - the main weakness of OOP is that too |
7 | many people try to force too many problems into a hierarchical mould. |
8 | Not every program should be object-oriented. As alternatives, consider |
9 | plain classes, generic programming, and free-standing functions (as in |
10 | math, C, and Fortran). |
(Aus: http://www.stroustrup.com/bs_faq.html) Genau die Software von Leuten, die mit roher Gewalt "too many problems into a hierarchical mould" pressen, liefern das Futter für die Anti-OOP- Schreihälse hier im Thread. Statt sich von diesen Negativbeispielen, (die es übrigens für jedes Programmierparadigma gibt) abschrecken zu lassen, sollte man aus ihnen lernen und versuchen, selber die gleichen Fehler nicht zu machen. Schlussbemerkung: Ich bin selber auch kein riesiger Fan der OOP und setze sie nur dort ein, wo ich die damit verbundenen Vorteile in Bezug auf eine bestimmte Anwendung schon von vornherein deutlich erkennen kann. Mich nerven aber Leute, die solche Dinge lautstark und in unzähligen Wiederholungen als den größten Mist der Menschheitsgschichte abstempeln, ohne sich zuvor mit der erforderlichen Intensität damit auseinandergesetzt zu haben.
Yalu X. schrieb: > Smalltalk lasse ich mal auf Grund > des hohen Alters außen vor) Pharo soll eine sehr gute moderne Smalltalk-Variante sein: https://de.wikipedia.org/wiki/Pharo_(Programmiersprache)
Dann muss ich jetzt mal ganz blöd fragen: Ich programmiere ausschließlich OOP, da ich nie was anderes kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#, Java, Python und JavaScript (bzw. TypeScript), je nach Projekt. Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten. Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch rein prozedurale Programmierung effizienter zu implementieren bzw. wartungsfreundlicher sind?
Phony schrieb: > Dann muss ich jetzt mal ganz blöd fragen: > > Ich programmiere ausschließlich OOP, da ich nie was anderes > kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#, > Java, Python und JavaScript (bzw. TypeScript), je nach Projekt. > > Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten. > Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch > rein prozedurale Programmierung effizienter zu implementieren bzw. > wartungsfreundlicher sind? Stringverarbeitung zB ist in purem C wesentlich effizienter und schneller. Natürlich muss man dazu verstehen, was ein Pointer ist. Aber in der Zeit, die man damit verbringt, eine Stringklasse mit all ihren Methoden zu studieren, kann man sich auch damit beschäftigen. Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren gegangen ist. Wer sich mit CPUs und Assembler auskennt, kann anhand des Quelltextes in etwa voraussehen, was im Prozessor geschehen wird. Keine andere Hochsprache ist da so konsistent. Die wichtigsten Vorteile der OOP, zusammengehörige Daten zusammen zu halten und mit einer einzigen Referenz darauf zugreifen zu können, sind schon mit der Verwendung von structs gegeben und selbst mit Assembler möglich. OOP ist keine Alternative zur PP, sondern eine andere Ebene. Als Autofahrer muss man nicht unbedingt wissen, was unter der Motorhaube geschieht, aber deshalb sind Automechaniker nicht überflüssig, im Gegenteil. Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit simpler PP, nur der Rahmen ist OOP-spezifisch.
Assembler ist auch nur der objektorientierte Rahmen von Mikrocodeanweisungen im Prozessor, man steckt die einzelnen Assemblerbefehle zusammen wie bei Lego.
D. I. schrieb: > Assembler ist auch nur der objektorientierte Rahmen von > Mikrocodeanweisungen im Prozessor, man steckt die einzelnen > Assemblerbefehle zusammen wie bei Lego. Bis auf das 'objektorientierte' stimme ich dir zu. Und so wie der Microcode bei den Prozessorentwicklern nicht veraltet ist, weil nur wenige ihn kennen, ist auch die prozedurale Programmierung nicht veraltet, sondern nur eine andere Ebene. Dass wir auf den Schultern von Riesen stehen, ist kein Grund auf Sie herabzublicken.
Jobst Q. schrieb: > Stringverarbeitung zB ist in purem C wesentlich effizienter und > schneller. Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge des Strings bekannt ist, und dass die Strings nicht null-terminiert sind. Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1). Jobst Q. schrieb: > Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie > beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit > simpler PP, nur der Rahmen ist OOP-spezifisch. Das ist definitiv Quatsch. Rein inhaltlich gibt es überhaupt keinen Unterschied. Lediglich die Strukturierung ist eine andere.
Jobst Q. schrieb: > Stringverarbeitung zB ist in purem C wesentlich effizienter und > schneller. Stringverarbeitung ist nun aber gerade etwas, das man nicht in großem Rahmen komplett in C machen will (ich zumindest nicht). Es ist einfach zu umständlich und fehlerträchtig. > Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein > Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren > gegangen ist. Hauptgrund wird eher sein, dass Linus Torvalds C++ nicht mag. Seine Aussagen dazu lassen vermuten, dass er sich aber auch nicht wirklich damit beschäftigt hat. Übrigens benutzt auch der Linux-Kernel OO-Konzepte (z.B. Polymorphie), nur dass sie eben nicht direkt über in der Sprache eingebaute Mittel verwendet werden, sondern zu Fuß implementiert sind.
Ähm, der Linux Kernel den ich kenne ist aber so etwas von objektorientiert! Auch wenn's zum Großteil c ist... Im Übrigen ist ein Betriebssystem ein sehr, sehr gutes Beispiel bei dem Objektorientierung sinnvoll ist. Bestes Beispiel: Prozesse da hat jeder seinen Stack, sein Register-File, einen Pointer zum Entry-Point... und natürlich Funktionen wie Run/Stop/Suspend. Ohne OOP hätte man jetzt unzählige einzelne (globale?) Arrays für alles. Mit OOP ist das alles eine Klasse oder zumindest ein struct. Da ist keine Vererbung im Spiel oder so aber es zeigt wie viel strukturierter das werden kann (also 42 Arrays wo man mit dem richtigen Index reinfingern muss vs. ein Array von Objekten). Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für Dateien (open, close, read, write) sind gleich - was sie tun aber nicht. Unser Moby ist leider... Moby... seine These, dass er in asm kleineren code erzeugt als ein ein c(++) compiler hat sich ja schon einmal als falsch herausgestellt. Ich schreibe viel prozedural und viel mehr objektorientiert... die Grenze ziehe ich unscharf dort wo zuviele unterschiedliche Objekte mit einander koexistieren müssen. Oft genug gibts es aber kein (definierbares) Objekt... 73
Phony schrieb: > Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten. Hast Du in einem Deiner Programme Klassen geschrieben bei denen die getter und setter transparent waren (d.h. den Wert direkt verwendet); und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du da auf OOP verzichtet.
Dumdi D. schrieb: > Hast Du in einem Deiner Programme Klassen geschrieben bei denen die > getter und setter transparent waren (d.h. den Wert direkt verwendet); > und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du > da auf OOP verzichtet. OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite oder sonst was ;-) OOP ist ein Architekturkonzept. Natürlich ist auch in jedem OOP basierten projekt sehr viel prozeduraler Code enthalten...
:
Bearbeitet durch User
Boris P. schrieb: > OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite > oder sonst was ;-) Wäre aber auch mal eine Herausforderung. Ich versuch's mal:
1 | class symbol_table extends Object{hello_world(){}} |
2 | class symbol_printer extends symbol_table{greating(){console.log(this.hello_world.name);}} |
3 | new class extends symbol_printer{constructor(){super();this.greating();}}; |
Scheint definitiv möglich in ES6, mit nichts als Ableitung, und einer Ableitung pro Zeile zu Programmieren :)
Wir verlieren uns in Details. Welche Sprache, OOP, PP ist die beste um Programmileinileinschen zu schreiben. In einem anderen Bild: Maurer unterhalten sich darüber, welche Mauertechnik die beste ist. OO macht aber Sinn, wenn wir es uns aus der Sicht eines Architekten ansehen. Der Linux-Kernel zeigt, dass es auch ohne OOP geht. Ich kenne andere Systeme, mit Millionen LOC fast alle ohne OO-Sprache. Einige Systeme sind sehr wohl objektorientiert strukturiert. Die Voraussetzung für den Erfolg solcher Systeme sind saubere Strukturen. Damit sind Module und deren Abhängigkeiten gemeint. Die Module haben klare Interfaces. Die Implementation ist gekapselt. Wer was verwenden darf ist klar geregelt. Wenn ich mir diese Module ansehe gibt es zwei Klassen: Bibliotheken wie Mathe, die Funktionen anbieten, die Elemente bekommen und Ergebnis-Elemente liefern. Der Zeitpunkt des Aufrufs und deren Reihenfolge haben keinen Einfluss auf das Ergebnis. Module mit Zustand. Hier hat der Zeitpunkt des Aufrufs und deren Reihenfolge einen Einfluss auf das Ergebnis. Module fassen das zusammen, was zusammengehört. Einige Herangehensweisen ignorieren Module mit Zustand. Sie beschreiben an einer Stelle die Elemente, die Daten und an einer anderen Stelle wird beschrieben wie sie verarbeitet werden. Diese Sicht fördert unübersichtliche Strukturen. Die wichtigste Idee hinter OO ist, Daten und die bereitgestellten Funktionen zusammenzufassen. Damit ein komplexes System übersichtlich bleibt, werden von einem Modul nur die essentiellen Funktionen bereitgestellt. Wie sie implementiert sind, ist im Modul verborgen. Verborgen in dem Sinne, das der Anwender des Moduls die Implementierung nicht sehen braucht, sie sich jedoch ansehen darf. Nur eines darf er nicht, sich darauf verlassen, dass die Implementation sich nicht ändert. Weil der Anwender die Implementierung nicht sehen braucht, muss das Verhalten des Moduls klar im Interface beschrieben sein. Module in grossen Systemen sind riesig, sie enthalten wiederum Module usw. Es ergibt sich ein eine hierarchische Architektur. Module werden oft in verschiedenen Kontexten benötigt. Da ist es wünschenswert, sie parametrisieren zu können. Man kann generische Module erstellen, die sogar andere Module als Parameter haben können. Eigentlich geht es darum, Module zu abstrahieren und allgemeiner zu formulieren. Der Sinn des Ganzen ist Wiederverwendbarkeit. Währen wir oben Module als Objekte mit Zustand, Interface und Kapselung gesprochen haben. Haben wir es jetzt mit Klassen zu tun. Aber das ist nicht die ganze Welt. Die oben erwähnten generischen Module sind eine andere Sicht, die Möglichkeiten bietet von denen manche OO-Programmierer nicht einmal träumen. Um es noch einmal klarzustellen, die meisten (grossen) Module sind Objekte und nur wenige Klassen und noch weniger generisch. Diese Strukturen kann man auch mit Nicht-OO-Sprachen aufbauen. Es bedarf klarer Regeln und Vorgaben. Die wichtigste Regel besagt: "Du darfst nicht verwenden was Du willst sondern nur was Du verwenden darfst." Die OO-Sprachen unterstützen diese Regel durch ihre Kapselung. Leider nur im Kleinen. Dafür stellen sie mächtige Konzepte wie Polymorphismen und Vererbung bereit. Erklärt wird das Ganze an Objektileinileinchen. Und jeder bastelt sich seine Klassen zurecht. Interfaces werden überfrachtet und vor allem nicht beschrieben. Man kann sich ja den Code ansehen. Fatal wirkt sich dann aus, dass dann jeder eine Klasse, die ihm geeignet scheint in sein Programm einbaut. Wir wundern uns dann, wie es passieren kann, wenn jemand die Farbe in einem Fenster ändert, an anderen Stellen auch alles grün wird. Die freie Verwendbarkeit von Modulen ist hier das Problem ebenso das Problem wie wohldurchdachte und dokumentierte Interfaces. Auf der anderen Seite werden natürlich breit oder sogar global verwendbare Module benötigt. Solche Module sollten nur von Könnern erstellt werden. Fazit: Objektorientierung im Keinen ist ein mächtiges schönes Werkzeug, das leider oft nicht einmal im Kleinen beherrscht wird. Nicht die Sprache, sondern das Konzept und vor allen seine Implikationen. Objektorientierung im Grossen ist eine essentielle Sichtweise, die leider durch die Werkzeuge des Keinen nicht beherrschbar sind. Hochhäuser aus der Sicht eines Maurers. Wie sagte Tom DeMarco: A fool with a tool ... P.S. Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien). Was sind denn die Treiber? Die Architektur ist vor allem sehr gut strukturiert. Seine graue Eminenz Linus wacht darüber mit Argusaugen.
Hans W. schrieb: > Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das > als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für > Dateien (open, close, read, write) sind gleich - was sie tun aber nicht. Nicht nur Dateisysteme, sondern auch die ganzen Gerätetreiber. Die sind schließlich auch alle als virtuelle Dateien implementiert, die diese ganzen Syscalls haben. Ein Linux-Treiber muss dazu eine Struktur mit Funktionspointern auf seine Implementierung dieser Syscalls anlegen und dem Kernel übergeben. Beim Zugriff auf das Device wird dann über diese Pointer die richtige Funktion gefunden und ausgeführt. Das ist genau das gleiche wie eine vtable, nur eben zu Fuß.
Heiner K. schrieb: > Der Linux-Kernel zeigt, dass es auch ohne OOP geht. [...] > Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien). Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch besondere sprachliche Mittel realisiert werden kann.
Karl Käfer schrieb: > Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne > OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch > besondere sprachliche Mittel realisiert werden kann. Zu Erstens: JA, nein. Es geht ohne OOP. Objekte sind immanente Elemente eines Systems. Sie zu erkennen ist ist die Leistung und sie bewusst anzuwenden ist OO. Das könnte man als (P) Programmierung bezeichnen aber nicht im herkömmlichen Sinne, Code zu produzieren. Zu Zweitens: JA Genau darum geht der Streit in diesem Thread, kann man Objekt ORIENTIERT programmieren ohne eine OO-Sprache im engeren Sinne zu verwenden. Die Denkweise in Objekten liegt uns näher, als wir uns bewusst machen. Der Gedanke des Zusammenfassens und Kapselns von Daten, Zustand und Funktionen geht in dem Geplärre von Vererbung und Polymorphismus ebenso unter wie das Konzept der Komposition.
Boris P. schrieb: > Jobst Q. schrieb: >> Stringverarbeitung zB ist in purem C wesentlich effizienter und >> schneller. > > Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen > Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge > des Strings bekannt ist, und dass die Strings nicht null-terminiert > sind. > Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1). Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen gewaltigen Overhead verursacht. Sie kann von Vorteil sein, wenn ein String nur einmal eingelesen und dann nur abgefragt wird. Das kann man aber nicht Stringverarbeitung nennen, sondern höchstens Stringverwendung. In purem C ist ein String einfach nur eine Adresse, alles andere ergibt sich daraus. Der Prozessor muss nichts überfüssiges machen, die Stringverarbeitung ist schnellstmöglich. Wenn für jede neue Stringvariable Speicher alloziiert und Strukturen aufgebaut und gefüllt werden müssen, damit es ein vollwertiges Objekt ist, braucht das seine Zeit und Resourcen. Wenn bei der Programmierung von Compilern Stringobjekte statt char* verwendet würden, wären viele Kaffepausen gesichert. Ich bin nicht prinzipiell gegen OOP, für große Objekte bringt sie viele Vorteile, aber für Strings ist sie überflüssig wie ein Kropf. Das schöne an C++ ist, dass man die Möglichkeiten von OOP nutzen kann, aber nicht muss.
Jobst Q. schrieb: > Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder > Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit > strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden > könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen > gewaltigen Overhead verursacht. Schön, wie man ein negativ besetztes Wort mit etwas zusammenbringen kann, mit dem es gar nichts zu tun hat... Warum sollte bei einer Zuweisung ala a=b die Länge neu ermittelt werden müssen? Und wozu sollte man strlen brauchen, wenn die Länge der Ausgangsstrings bekannt ist und die Operationen darauf deterministisch sind?
Jobst Q. schrieb: >> Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1). > > Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder > Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit > strlen() oder ähnlichem. Nein, fast immer genügt eine einzelne Addition bzw. Subtraktion. Der zusätzliche Aufwand ist also im Gesamtkontext irrelevant. > die genau deshalb einen gewaltigen Overhead verursacht. > Wenn bei der Programmierung von Compilern Stringobjekte statt char* > verwendet würden, wären viele Kaffepausen gesichert. War starker Unterdruck nötig, sich diesen Unsinn aus den Fingern zu saugen? Und nein, ich bin kein Fanboy, die Stringverarbeitung in C++ ist nichts Halbes und nichts Ganzes.
Jobst Q. schrieb: > In purem C ist ein String einfach nur eine Adresse, alles andere ergibt > sich daraus. Der Prozessor muss nichts überfüssiges machen, die > Stringverarbeitung ist schnellstmöglich. Nein, i.Allg. ist das nicht der Fall. Bei den meisten String-Operationen ist es von Vorteil, wenn man die Länge vorab kennt. Ein paar Beispiele: Länge bestimmen: Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei nullterminierten Strings müssen die Zeichen gezählt werden. Kopieren: Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar mitkopiert werden, das ist aber nur ein einzelner Integer-Wert. Anhängen eines Strings s2 an einen anderen String s1: Man weiß sofort, an welche Stelle im Buffer von s1 man s2 kopieren muss. Die Länge von s1 muss zwar aktualisiert werden, das ist aber nur eine einfache Addition. Bereichsprüfung des Index: Bei nullterminierten String muss vor der eigentlichen Prüfung die Länge durch Abzählen bestimmt werden. Vorteile (mit Einschränkungen) von nullterminierten Strings: - Sie belegen ein paar Bytes weniger Speicher. Dafür darf aber das Zeichen NUL ('\0') nicht im String vorkommen. - Auf manchen Prozessorarchitekturen geht das Iterieren über alle Zeichen des Strings etwas schneller. Es gibt aber auch Architektueren, wo es genau anders herum ist. Außerdem ist bei der Iteration über nullterminierte Strings kein Loop-Unrolling möglich. Der Grund, warum C von Hause aus nur die nullterminierten Strings hat, liegt darin, dass die Anzahl der vordefinierten Datentypen klein halten wollte. Ein String mit Längenangabe wäre ein spezielles Struct, das aber ein Anwendungsprogrammierer oder ein Bibliotheksschreiber auch selber nach eigenem Gutdünken definieren kann. C ist die einzige mir bekannte Programmiersprache mit nullterminierten Strings. Alle anderen verwenden entweder - Zeichenarrays mit zusätzlicher Längenangabe, - verkettete Listen von Zeichen oder - verkettete Zeichenarrays mit Längenangabe. Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP nichts, aber auch gar nichts zu tun hat :)
Yalu X. schrieb: > Jobst Q. schrieb: >> In purem C ist ein String einfach nur eine Adresse, alles andere ergibt >> sich daraus. Der Prozessor muss nichts überfüssiges machen, die >> Stringverarbeitung ist schnellstmöglich. > > Nein, i.Allg. ist das nicht der Fall. > > Bei den meisten String-Operationen ist es von Vorteil, wenn man die > Länge vorab kennt. Ein paar Beispiele: > > Länge bestimmen: Ja, es ist beim Bestimmen der Länge von Vorteil, wenn man sie schon kennt. Welch tiefe Weisheit, auch Tautologie genannt. Bei den meisten String-Operationen, die ich kenne und verwende, spielt die Länge keine Rolle. > Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei > nullterminierten Strings müssen die Zeichen gezählt werden. Müssen sie nicht, wenn die Stringfunktionen die Adresse der Null am Ende zurückgeben. Die Funktion strcpy tut das dummerweise nicht, sie gibt den Anfang zurück, den man eh schon kennt. Aber da gibt es auch die Funktion stpcpy die genau das tut, was sie soll. Beispiel für die Längenbestimmung beim Aneinanderhängen von zwei Strings: l=stpcpy(stpcpy(buf,s1),s2)- buf; Weder die Länge von s1 noch von s2 muss vorher bekannt sein und doch bekommt man die Gesamtlänge fast gratis. > > Kopieren: > Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes > einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar > mitkopiert werden, das ist aber nur ein einzelner Integer-Wert. Strings sind aber selten große Blöcke, deshalb fällt das kaum ins Gewicht. Für Blöcke gibt es die mem-Funktionen. Jeden String als Block zu definieren, halte ich nicht für sinnvoll. Ein großer Vorteil der Null-terminierten Strings ist aber, dass man viel seltener kopieren muss. Einen längeren String, zB eine Zeile aus einer Datei in einem Puffer, kann man an Ort und Stelle in mehrere benötigte Teilstrings zerlegen, indem man die Trennzeichen durch eine Null ersetzt. Das geht mit keinem anderen Stringmodell. Ein anderer großer Vorteil ist sehr simple Verkürzen der Strings. ZB das Überspringen von Leerzeichen und tabs: while(*s==' '||*s=='\t')s++; Wie man eine solche Aufgabe mit Objektstrings löst, überlasse ich anderen. Deren Methoden erinnern mich stark an den Murks der Stringbehandlung in GWBasic, mit dem ich mich rumquälte, bevor ich C entdeckte. > Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP > nichts, aber auch gar nichts zu tun hat :) Sehe ich nicht so. Strings sind ein gutes Beispiel, wie OOP-Dogmen einfaches kompliziert und ineffektiv machen können.
1 | for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) { |
2 | if ( (*it = ' ') or (*it=='\t') ) { |
3 | it++; |
4 | }
|
5 | }
|
wow der Unterschied... Sollte das etwa gar nichts mit OOP zu tun haben? Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte, wie toll Stringverarbeitung mit C geht. Ich kann mir auch nicht vorstellen, dass du dir das selber erzählst.
nfet schrieb: > Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte, > wie toll Stringverarbeitung mit C geht. Stringverarbeitung mit C geht jedenfalls - sie wird millionenfach durchgeführt. Ob sie "toll" ist, sei dahingestellt. Dazu müsste man erst einmal definieren, was man unter toller Stringverarbeitung versteht. "Toll" kann ja auch verrückt heißen... ;-)
nfet schrieb:
1 | for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) { |
Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine einfache Iteration über die Zeichen eines Strings in C++ sein kann. Mit C-Strings würde man einfach schreiben:
1 | for(char *it = s; *it; it++) { |
Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in C:
1 | for (auto c: s) { |
Durch die auto-Deklaration funktioniert das sogar gleichermaßen für string- wie für wstring-Typen. nfet schrieb: > Sollte das etwa gar nichts mit OOP zu tun haben? Mein diesbezüglicher Kommentar von oben bezog sich auf die interne Repräsentation von Strings. Das von Jobst angeprangerte Mitführen der Länge in einem String-Datentyp ist keine OOP-spezifische Eigenschaft.
Yalu X. schrieb: > for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) { > > Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine > einfache Iteration über die Zeichen eines Strings in C++ sein kann. > > Mit C-Strings würde man einfach schreiben: > for(char *it = s; *it; it++) { Was ist jetzt an dem ersten komplizierter als am zweiten? Der Typenname ist etwas länger, aber das war's dann auch. > Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in > C: > for (auto c: s) { Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere Schreibweise. Und es macht nicht mal das gleiche. Im ersten Fall habe ich schließelich einen Iterator auf die Stelle, wo das Zeichen steht, den ich in weiteren Funktionen auf den String anwenden kann, während ich bei deiner Variante nur das Zeichen selbst habe. Gut, das überspringen von Zeichen in der Schleife könnte man damit auch machen. Wobei man auto natürlich auch für den Iterator verwenden kann:
1 | for (auto it=s.begin(); it!=s.end(); ++it) { |
Das tolle an Iteratoren ist eben auch, dass die eigentliche Datenstruktur dich gar nicht interessieren muss, während die Pointer-Variante aus c ausschließlich mit Arrays funktioniert. Dann klappt das z.B. auch bei einer Stringklasse, die die Daten intern als verkettete Liste aus Arrays hält, wie man das bei Texteditoren üblicherweise macht. Die arbeiten ja in der Regel mit sehr langen Zeichenketten, bei denen man ständig mittendrin was einfügen muss.
Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine Frage sein) >for(char *it = s; *it; it++) *it = s setzt den als itterator benutzten Zeiger auf Element 0 vom Zielstring >> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt? Hat das Terminierungszeichen automatisch den Wert, dass es als Abbruchbedingung dient? it++ => inkrement des itterators
Beaker schrieb: > Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine > Frage sein) >>for(char *it = s; *it; it++) > *it = s setzt den als itterator benutzten Zeiger auf Element 0 vom > Zielstring >>> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt? Bedingung ist "wenn *it wahr". Beim Terminierungszeichen '\0' (0) ist *it false (also Abbruch), sonst true (weiter). > Hat das Terminierungszeichen automatisch den Wert, dass es als > Abbruchbedingung dient? Ja; weil 0 in C (als bool) als false interpretiert wird, alle anderen Werte als true. Wäre für C-Strings als Terminierungszeichen nicht 0, sondern z.B. 255 definiert, würde es also so nicht funktionieren (es sei denn, dieser Wert würde dann als false interpretiert werden und die anderen als true).
Rolf M. schrieb: > ... > Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere > Schreibweise. Und das ist nicht "einfacher"? ;-) > Und es macht nicht mal das gleiche. Dann eben:
1 | for (auto &c: s) ... |
nfet schrieb: > Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte, > wie toll Stringverarbeitung mit C geht. Du Ärmster! Soll ich dir jetzt ein Bild von mir schicken ?
Jobst Q. schrieb: > while(*s==' '||*s=='\t')s++; Wie sehts mit s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf den ersten Blick, was passieren soll. Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst, auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in einer Funktion sein. Alles andere ist schlechter Stil und das hat mit OOP oder PP bekanntlich nichts zu tun.
nicht"Gast" schrieb: > Jobst Q. schrieb: >> while(*s==' '||*s=='\t')s++; > > Wie sehts mit > > s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf > den ersten Blick, was passieren soll. Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek vorhanden ist? Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich geschieht, was alles in der Methode Trimstart drinsteckt. Was in der while-Zeile geschieht, ist dagegen klar für jeden, der was von C versteht. Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für die Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist, gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen kann. > > Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst, > auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in > einer Funktion sein. Alles andere ist schlechter Stil und das hat mit > OOP oder PP bekanntlich nichts zu tun. Auch bei mir steht while(*s==' '||*s=='\t')s++; return s; nur in meiner Funktion nextvis(). In meinen Programmen steht dann lediglich s=nextvis(s);
Mikro 7. schrieb: > Rolf M. schrieb: >> ... >> Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere >> Schreibweise. > > Und das ist nicht "einfacher"? ;-) Kommt drauf an, was du unter "einfacher" verstehst. Hier scheint nämlich jeder was anderes damit zu meinen. Der eine versteht darunter, dass es für den Prozessor effizienter ist, der nächste, dass es leichter verständlich ist, der dritte, dass es weniger Zeichen zu tippen sind. >> Und es macht nicht mal das gleiche. > > Dann eben:for (auto &c: s) ... Das kann man immer noch nicht als Iterator in den String benutzen.
So wie ich das sehe, sind das jetzt Detailklauberreien. C ist ja eine Untermenge von C++. Also kann ich da meine Strings genau so bearbeiten, wenn ich das will.
Jobst Q. schrieb: > Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste > Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für > die > Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist, > gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen > kann. > >> Soso, irgend wie scheinst du dich an dem falschen Thema abzuarbeiten. Das Zerlegen und/oder Trimmen von Zeichenketten ist in so ziemlich keiner sinvollen Anwendung der zeitkritische Teil. (google mal nach "Premature optimization is the root of all evil"). Bei der Verarbeitung von großen Datensätzen ist es eigentlich immer die Beschaffung von Speicher, IO Operationen oder besondere Algorithmik, welche einer genauen Betrachtung bedarf. Einfache Stringverarbeitung ist da eher uninteressant. BTW, ich weiß ja nicht wie du Quellcode liest, aber wenn ich irgend wo im Text ein TrimStart sehe, dann weiß ich, dass die Whitespaces am Anfang des Strings entfernt werden. Wie das passiert ist eigentlich völlig Schnuppe, es sei denn ich hab Bugs an der Stelle oder es ist so Schei*e implemtiert, dass es wirklich langsam wird. Jobst Q. schrieb: > Auch bei mir steht > > while(*s==' '||*s=='\t')s++; > return s; > > nur in meiner Funktion nextvis(). In meinen Programmen steht dann > lediglich > > s=nextvis(s); Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen Speicher. Der geistert dann als Memory Leak für den Rest der Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal unkommentiert.
Jobst Q. schrieb: > Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek > vorhanden ist? Kann man mit Vererbung eine neue Klasse erzeugen und die Methode Implementieren?
Jobst Q. schrieb: > Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich > geschieht, was alles in der Methode Trimstart drinsteckt. Was in der > while-Zeile geschieht, ist dagegen klar für jeden, der was von C > versteht. Was wirklich geschieht, steht auch in einem C-Code nicht. Da kommt der Compiler und macht sein ding.
Jobst Q. schrieb: > Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich > geschieht, was alles in der Methode Trimstart drinsteckt. Was in der > while-Zeile geschieht, ist dagegen klar für jeden, der was von C > versteht. Wenn man mal größere Frameworks verwendet hat oder auch nur in einem größeren Team an einem Projekt gearbeitet hat, kann man nicht mehr wissen was ein Funktionsaufruf aus einem anderen Projektteil genau tut. Er sollte es halt ordentlich tun, sorgfältig dokumentiert und ohne unbekannte Nebenwirkungen.
nicht"Gast" schrieb: >> s=nextvis(s); > > Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen > Speicher. Der geistert dann als Memory Leak für den Rest der > Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal > unkommentiert. Deine unsinnigen Unterstellungen will ich mal nicht unkommentiert lassen. Wo steht denn, dass s der Startzeiger auf einen Speicher ist? s steht für sourcepointer ist nach bewährter Tradition von Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der entsprechende Schreibzeiger ist t für targetpointer. Leerzeichen können ja nicht nur am Anfang einer Zeile stehen. Würdest du dann jedesmal einen neuen String anlegen? Der Speicher für Stringverarbeitung heißt bei mir meistens buf und liegt als lokale Variable auf dem Stack. Oder ist global und fängt dann mit einem Großbuchstaben an. Wozu sollte man Speicher alloziieren, wenn es garnicht nötig ist?
Jobst Q. schrieb: > Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich > geschieht, was alles in der Methode Trimstart drinsteckt. Und genau das soll er ja auch. Genau wie mich beim memcpy nur interessiert, dass es einen Speicherblock von A nach B kopiert, nicht aber, ob das jetzt durch eine simple Schleife mit byteweisem Kopieren oder durch ein Duff-Device oder einen DMA-Transfer oder ein vom Compiler inline erzeugtes für diesen Aufruf speziell optimiertes Stück Code gemacht wird. > Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste > Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für > die Aufgabe nötig ist. Da Stringhandling in den wenigsten Progammen der Flaschenhals ist, wollen die meisten lieber ein komfortable als eine maximal schnelle Stringverarbeitung.
Jobst Q. schrieb: > s steht für sourcepointer ist nach bewährter Tradition von > Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der > entsprechende Schreibzeiger ist t für targetpointer. Uii, er hat ein C Buch zu Hause stehen. Da bin ich ja total beeindruckt. So ein Vollchecker, ein Profi, ein Vollnerd. Wenn du jetzt noch behauptest, dass du schon mal in den Source von Linux geschaut (auch immer ein beliebtes Totschlagargument) dann verneige ich mich vor Dir. </Sarkasmus> (nur zur Sicherheit) Genug der Schmeicheleien. Man kan hier nur das bewerten, was man lesen kann. BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an der falschen Stelle gespart.
@nicht"Gast": Auf die Gefahr hin, daß ich mich wiederhole: Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche argumentlosen Posts zerstören einen interessanten Thread. Stefan
Stefan K. schrieb: > Auf die Gefahr hin, daß ich mich wiederhole: > Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche > argumentlosen Posts zerstören einen interessanten Thread. kann man geteilter Meingung sein, aber hast ja in Summe Recht. // Versöhnungskeks rüber reich.
nicht"Gast" schrieb: > BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an > der falschen Stelle gespart. Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück. PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen großen Mehraufwand beim Schreiben und Lesen des Quelltextes. TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion? Und was hast du sonst noch für Sorgen?
Jobst Q. schrieb: > nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück. > PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen > großen Mehraufwand beim Schreiben und Lesen des Quelltextes. Von CleanCodeDevelopment hast du offensichtlich noch nichts gehört. Jobst Q. schrieb: > TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion? TrimEnd
Jobst Q. schrieb: > nicht"Gast" schrieb: > >> BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an >> der falschen Stelle gespart. > > Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt > nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück. > PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen > großen Mehraufwand beim Schreiben und Lesen des Quelltextes. > > TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion? > > Und was hast du sonst noch für Sorgen? Jobst Q. schrieb: > TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion? nein, aber eine TrimEnd() und eine Trim(). Die Namensgebung kannst du mir nicht anlasten, beschwer dich bei MS^^ Um mal zum Topic zurück zu kommen. Das schöne an der String Klasse in dem Fall ist einfach, das die IDE gut parsen kann welche Methoden die Klasse hat und über Intellisense (wie das bei Eclipse und QT Designer benannt ist, weiß ich nicht, aber die beiden können das auch sehr gut) die möglichen Methoden/Properties, oder was sonst noch anfällt, hilfsbereiterweise anzeigen kann. Um das mal zu Erläutern.. du hast einen string foo = "nüscht"; wenn du jetzt "foo." eintippst, dann bringt die VS eine Liste mit vorschlägen, was du mit deinem foo so alles anstellen kannst. Das geht mit C sourcecode einfach deutlich schlechter, da keine "offiziellen" Zusammenhänge erkennbar sind. Da kann dir die IDE höchstens Vorschläge für den Funktionsnamen machen. Zusammenhänge sind deutlich schwerer darstellbar.
nicht"Gast" schrieb: >> Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt >> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück. >> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen >> großen Mehraufwand beim Schreiben und Lesen des Quelltextes. ach, vergessen... 'Schulterzuck'
Tom schrieb: > Jobst Q. schrieb: >> großen Mehraufwand beim Schreiben > > Wenn man mit Notepad entwickelt. Freiwillig benutze ich keine Microsoft-Produkte. Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle Buchstaben richtig sind, steigt fast exponentiell.
Jobst Q. schrieb: > Freiwillig benutze ich keine Microsoft-Produkte. > > Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind > schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle > Buchstaben richtig sind, steigt fast exponentiell. Was benutzt du denn für einen Editor zum programmieren. Die meisten können wenigstens einfache Auto Vervollständigung. Da sollte die Länge des Bezeichners egal sein.
Rolf M. schrieb: > Da Stringhandling in den wenigsten Progammen der Flaschenhals ist, > wollen die meisten lieber ein komfortable als eine maximal schnelle > Stringverarbeitung. Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung bestehen. Programme, die Textdateien einlesen und andere ausgeben. Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen Mensch und Maschine, etwas was beide verstehen. Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine Hilfe, sondern Behinderung.
Jobst Q. schrieb: > Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung > bestehen. Programme, die Textdateien einlesen und andere ausgeben. > Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen > Mensch und Maschine, etwas was beide verstehen. Hast du das mal durch einen Profiler laufen lassen? Die IO Operationen sind doch um Welten langsamer als die Bearbeitung der Strings.
Jobst Q. schrieb: > Rolf M. schrieb: >> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist, >> wollen die meisten lieber ein komfortable als eine maximal schnelle >> Stringverarbeitung. > > Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung > bestehen. Programme, die Textdateien einlesen und andere ausgeben. > Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen > Mensch und Maschine, etwas was beide verstehen. Und du hast verifiziert, dass die Nutzung einer Stringklasse in deinem Programm ein Flaschenhals wäre? Oder vermutest du das nur (alias "premature optimization")? > Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch > komfortabler als die Arbeit mit Stringobjekten. Mir würde wirklich keine Sprache einfallen, in der Stringhandling so unkomfortabel ist wie in C. Ich finde jedenfalls ein
1 | string c = a + b; |
wesentlich komfortabler (und weniger fehleranfällig) als ein
1 | char* c = malloc(strlen(a) + strlen(b) + 1); |
2 | strcpy(c, a); |
3 | strcat(c, b); |
4 | // Plus später daran denken, den Speicher wieder freizugeben
|
> Mit diesen ist es wie mit Stützrädern bei Fahrrädern, wenn man Radfahren > kann, sind sie keine Hilfe, sondern Behinderung.
Rolf M. schrieb: > Mir würde wirklich keine Sprache einfallen, in der Stringhandling so > unkomfortabel ist wie in C. Wie würde wohl ein
1 | myString = myString.Replace("Hund", "Salamander"); |
in C aussehen? Uaah, schauder... Da lobe ich mir doch die moderne, objektorientierte und effiziente Stringbehandlung, wie sie z.B. C# bietet.
Rolf M. schrieb: > Mir würde wirklich keine Sprache einfallen, in der Stringhandling so > unkomfortabel ist wie in C. Da sprichst du mir aus der Seele. Naja, C kennt strenggenommen eigentlich überhaupt keine Strings. Und selbst das, was salopp mit char bezeichnet wird, ist eigentlich kein Textzeichen, sondern eine Integer-Variable. Naja, Steinzeit eben. Aber wir scheinen unsere Faustkeile ja zu lieben... W.S.
Boris P. schrieb: > Wie würde wohl einmyString = myString.Replace("Hund", "Salamander"); > in C aussehen? Uaah, schauder... Ganz einfach: s=StrReplace(s,"Hund","Salamander"); Reine Formsache.
Jobst Q. schrieb: > Ganz einfach: > s=StrReplace(s,"Hund","Salamander"); > Reine Formsache. Klappt besonders gut mit char b[100] = ... char *s = StrReplace(b, "Hund", "Katze"); s = StrReplace(s, "Salamander", "Krokodil");
:
Bearbeitet durch User
Jobst Q. schrieb: > Ganz einfach: > s=StrReplace(s,"Hund","Salamander"); > Reine Formsache. Tja, fehlt nur noch die Implementierung...
A. K. schrieb: > Klappt besonders gut mit > char b[100] = ... > char *s = StrReplace(b, "Hund", "Katze"); > s = StrReplace(s, "Salamander", "Krokodil"); So ist es m.M.n falsch. StrReplace ruft free(b) oder realloc auf (muss es, da 'Katze' länger als 'Hund' ist); und ich vermute ein free auf ein lokale Variable führt zu undefiniertem Verhalten.
Jobst Q. schrieb: > Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung > bestehen. Programme, die Textdateien einlesen und andere ausgeben. > Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen > Mensch und Maschine, etwas was beide verstehen. Solche Helferleins kennt jeder Programmierer, die schreibt man sich in der Regel in Python oder Ähnlichem. Aber wenn man nur nen Hammer kennt...
Jobst Q. schrieb: > Rolf M. schrieb: >> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist, >> wollen die meisten lieber ein komfortable als eine maximal schnelle >> Stringverarbeitung. > > Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung > bestehen. Programme, die Textdateien einlesen und andere ausgeben. > Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen > Mensch und Maschine, etwas was beide verstehen. > > Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch > komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie > mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine > Hilfe, sondern Behinderung. Richtige Kerle benutzen für Strings: REPNZ MOVS REPNZ SCAS ... Da sieht man gleich, was da passiert. Oder so ;-)
:
Bearbeitet durch User
aber vorher bitte ecx, esi, edi laden und das direction flag setzen/löschen.....
HVV schrieb: > aber vorher bitte ecx, esi, edi laden und das direction flag > setzen/löschen..... Ja, das konnt ich alles mal. Vor Jahrzehnten. Als man PC-C-Compiler nichtmal für viel Geld kaufen konnte und std::string noch nicht existierte. Wobei ich zum ein paar Textfiles aufmischen heute auch Python benutzen würde (und vereinzelt hab). Aber warum soll man sich nicht das Leben schwer machen ;-)
Carl D. schrieb: > Als man PC-C-Compiler nichtmal für viel Geld kaufen konnte Der erste C Compiler für DOS-PCs kam immerhin schon 1982.
:
Bearbeitet durch User
Carl D. schrieb: > Richtige Kerle benutzen für Strings: Und Waschlappen machten es so: https://www.cs.auckland.ac.nz/references/macvax/op-codes/Instructions/movc.html
A. K. schrieb: > Carl D. schrieb: >> Richtige Kerle benutzen für Strings: > > Und Waschlappen machten es so: > https://www.cs.auckland.ac.nz/references/macvax/op-codes/Instructions/movc.html Ja, wenn sie sich ne Vax leisten konnten, oder Assi an der Uni waren ;-) 1982 hatte ich nur ein z80-CP/M Board zur Verfügung. Und irgendwann eine TP-Raubkopie.
PS: Die wirklich harten Kerle machen es so, dass es bei jeder Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30 Jahre in jeweils kürzestmöglicher Zeit funktioniert!
A. K. schrieb: > PS: Die wirklich harten Kerle machen es so, dass es bei jeder > Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30 > Jahre in jeweils kürzestmöglicher Zeit funktioniert! Genau das überlasse ich heute gern den harten Burschen, die den GCC nebst glibc und STL zusammenschrauben. Ich hab nämlich scon lang den Überblick über intels/AMDs CPU Zoo verloren. Und dann hab ich auch noch ARMs im Einsatz. War das schön früher auf der Mainframe. Ein fast in Stein gemeißelter Befehlssatz. Und heute: "welche Vektoreinheiten hätten sie denn gern?" "ich nehm die Blaue".
>Genau das überlasse ich heute gern den harten Burschen, die den GCC >nebst glibc und STL zusammenschrauben. Das sehe ich genau so. Deshalb verstehe ich das hier auch nicht so richtig: http://www.heise.de/developer/meldung/Programmiersprachen-Ranking-Assembler-steigt-neu-in-TIOBEs-Top-10-ein-3263014.html
Moby A. schrieb im Beitrag #4645665: > Vielleicht solltest Du Dir dazu mal vergegenwärtigen, für welches > Einsatzfeld Asm vermehrt zum Einsatz kommt. Da gehts eben nicht um PCs, > sondern um > >> der wachsende Bedarf >> an Software für Kleinstgeräte ... , wie sie im Internet der Dinge >> zahlreich zum Einsatz kommen. TCP/IP Kommunikation in Assembler? Na dann viel Spaß.
Führt die Assembler-Diskussion bitte in diesem Thread fort: Beitrag "Assembler wieder auf dem Weg nach vorn" Dort ist sie besser aufgehoben.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.