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. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.