OOP - für was in aller Welt soll denn das gut sein?

[Christian M. (Gast)]

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

[Jonas (Gast)]

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.

[Jan H. (j_hansen)]

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.

[Trolljäger (Gast)]

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.

[Sheeva P. (sheevaplug)]

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. :-)

[Mark B. (markbrandis)]

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.

[Random .. (thorstendb)]

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.

[Karl (Gast)]

Lies dir das hier (und die weiteren Teile) durch, danach kannst du 
nochmal fragen:

https://wiki.delphigl.com/index.php/Tutorial_Softwareentwicklung1

[Der Andere (Gast)]

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.

[Carl D. (jcw2)]

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.

[Karl (Gast)]

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.

[Christian M. (Gast)]

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

[Christian M. (Gast)]

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

[Der Andere (Gast)]

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.

[TriHexagon (Gast)]

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..

[D. I. (Gast)]

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.

[Stefan S. (Gast)]

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...

[Tim (Gast)]

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.

[Stefan S. (Gast)]

Ja, nicht OPP sondern OOP.

Und ECS wäre das neue Stichwort:

https://en.wikipedia.org/wiki/Entity_component_system

[Mark B. (markbrandis)]

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?

[Md M. (Firma: Potilatormanufaktur) (mdma)]

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 :-)

[Michael B. (laberkopp)]

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.

[Rolf M. (rmagnus)]

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.

[Daniel A. (daniel-a)]

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.

[vn nn (Gast)]

Beitrag "Re: Wieso Objektorientiert?"
Beitrag "Re: Verständnis OOP für hardwarenahe Programmierer"

[Karl (Gast)]

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

[Mark B. (markbrandis)]

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?

[Daniel A. (daniel-a)]

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.

[Marc (Gast)]

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.

[c-hater (Gast)]

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...

[Dussel (Gast)]

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.

[Stefan S. (Gast)]

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.

[Rolf M. (rmagnus)]

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.

[Paul B. (paul_baumann)]

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

[Daniel A. (daniel-a)]

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.

[T.roll (Gast)]

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.

[TriHexagon (Gast)]

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 ;)

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Daniel A. (daniel-a)]

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.

[Rolf M. (rmagnus)]

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.

[Christian M. (Gast)]

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

[Tobias (Gast)]

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...

[(prx) A. K. (prx)]

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.

[Sheeva P. (sheevaplug)]

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.

[Michael B. (laberkopp)]

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.

[Sheeva P. (sheevaplug)]

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/

[Sheeva P. (sheevaplug)]

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.

[Vancouver (Gast)]

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.

[Marc (Gast)]

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.

[Sheeva P. (sheevaplug)]

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. :-)

[Michael B. (laberkopp)]

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.

[Mark B. (markbrandis)]

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/

[Sheeva P. (sheevaplug)]

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.

[W.S. (Gast)]

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.

[Stefan S. (Gast)]

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.

[TriHexagon (Gast)]

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?

[Sheeva P. (sheevaplug)]

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. :-)

[Carl D. (jcw2)]

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.

[Baku M. (baku)]

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

[Christian M. (Gast)]

@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

[Daniel A. (daniel-a)]

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:

"use strict"; // ungetestet

function Person(name){
  this.name = name;
}

Person.prototype.introduce = function introduce(){
  alert("Hi, I'm "+this.name);
};

Seit ES6 ist es aber gereits ganz brauchbar geworden:

"use strict"; // ungetestet

class Person {
  constructor(name){
    this.name = name;
  }
  introduce(){
    alert("Hi, I'm "+this.name);
  }
}

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.

[Sheeva P. (sheevaplug)]

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.

[TriHexagon (Gast)]

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.

[(prx) A. K. (prx)]

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).

[W.S. (Gast)]

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.

[nasefuss (Gast)]

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.

[nenene (Gast)]

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?

[(prx) A. K. (prx)]

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.

[W.S. (Gast)]

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.

[Mark B. (markbrandis)]

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.

[Mark B. (markbrandis)]

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 ;-)

[Sheeva P. (sheevaplug)]

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?

[c-hater (Gast)]

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...

[(prx) A. K. (prx)]

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.

[Daniel A. (daniel-a)]

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:

// person.h

#ifndef DPA_PERSON_H
#define DPA_PERSON_H

struct DPA_Person {
  const char* name;
};

void DPA_Person_introduce( struct DPA_Person* );

#endif

// person.c

#include <stdio.h>
#include <DPA/example/person.h>

void DPA_Person_introduce( struct DPA_Person* person ){
  printf( "Hi, I'm %s\n", person->name );
}

Beispiel für Vererbung, der Einfachheit halber ohne virtuelle Methoden:

// developer.h

#ifndef DPA_DEVELOPER_H
#define DPA_DEVELOPER_H

#include <DPA/example/person.h>

struct DPA_Developer {
  struct DPA_Person person;
  const char* company;
};

void DPA_Developer_introduce( struct DPA_Developer* );

#endif

// developer.c

#include <stdio.h>
#include <DPA/example/person.h>

void DPA_Developer_introduce( struct DPA_Developer* developer ){
  printf(
    "Hi, I'm %s from %s\n",
    developer->person->name,
    developer->company,
  );
}

// main.c
#include <DPA/example/person.h>
#include <DPA/example/developer.h>

int main(){

  Person tom = {
    .name = "tom"
  };

  Developer john = {
    .person = {
      .name = "john"
    },
    .company = "ABC AG"
  };

  DPA_Person_introduce(tom);
  DPA_Person_introduce(john.person);
  DPA_Developer_introduce(john);

  return 0;
}

Ausgabe:

Hi, I'm tom
Hi, I'm john
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:

// output_device.h

#ifndef DPA_OUTPUT_DEVICE_H
#define DPA_OUTPUT_DEVICE_H

struct DPA_OutputDevice;
struct DPA_OutputDeviceInterface {
  void(*init)(struct OutputDevice*);
  void(*print)(struct OutputDevice*,const char*);
  void(*destroy)(struct OutputDevice*);
};

struct DPA_OutputDevice {
  const struct OutputDeviceInterface* interface;
};

extern const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface;

#endif

// terminal_x86.h

#ifndef DPA_TERMINAL_X86_H
#define DPA_TERMINAL_X86_H

#include <DPA/ExampleOS/output_device.h>

struct DPA_Terminal_x86;
struct DPA_Terminal_x86_Interface {
  struct DPA_OutputDeviceInterface interface;
  void(*clear)( struct DPA_Terminal_x86* );
};

struct DPA_TerminalCharacter_x86 {
  uint8_t character,
  uint8_t color
} __attribute__((packed));

struct DPA_Terminal_x86 {
  union {
    const struct DPA_Terminal_x86_Interface* interface;
    struct DPA_OutputDevice outputDevice;
  };
  uint_least16_t columns;
  uint_least16_t rows;
  uint_least32_t cursor;
  volatile DPA_TerminalCharacter_x86* buffer;
};

// terminal_x86.c

#include <string.h>
#include <DPA/ExampleOS/terminal_x86.h>

static void init( struct DPA_OutputDevice* od ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  terminal->columns = 80;
  terminal->rows    = 25;
  terminal->buffer  = *(volatile struct DPA_TerminalCharacter_x86*)0xB8000;
}

static void print( struct DPA_OutputDevice* od, const char* text ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  char character;
  uint_least8_t  color  = terminal->color;
  uint_least32_t cursor = terminal->cursor; 
  uint_least32_t size   = terminal->columns * terminal->rows;
  while( character = *text++ ){
    if( cursor >= size )
      cursor = 0;
    terminal->buffer[cursor++] = (struct DPA_TerminalCharacter_x86){
      .character = character,
      .color = color
    };
  }
  terminal->cursor = cursor;
}

static void clear( struct DPA_Terminal_x86* terminal ){
  memset( (void*)terminal->buffer, 0, terminal->columns * terminal->rows );
}

static void destroy( struct DPA_OutputDevice* od ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  (void)terminal;
}

const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface = {
  .terminal = {
    .init = init,
    .print = print,
    .destroy = destroy
  },
  .clear = clear
};

const struct DPA_OutputDeviceInterface* outputDeviceList[] = {
  &DPA_terminal_x86_interface.terminal
};

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.

[TriHexagon (Gast)]

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

struct Foo;

Foo* foo_create();
void foo_doThis(Foo* foo);
void foo_doThat(Foo* foo);

foo.c

#include "foo.h"

struct Foo {
  int a;
  //...
};

Foo* foo_create() {
  Foo* foo = malloc(sizeof(Foo));
  //...
  foo->a = 0;
  //...
}

void foo_doThis(Foo* foo) {
  //...
}

void foo_doThat(Foo* foo) {
  //...
}

Großer Nachteil dabei ist, dass man die Struktur nicht mehr auf den 
Stack legen kann. Jedenfalls außerhalb von foo.c.

[TriHexagon (Gast)]

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.

[Stefan F. (Gast)]

Ü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.

[Tommi (Gast)]

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?

[(prx) A. K. (prx)]

Tommi schrieb:
> C++? Ich nehme an, dass dort das statische Anlegen
> von Instanzen möglich ist?

Ja.

[Tommi (Gast)]

A. K. schrieb:
> Ja.
Ein Beispiel wäre nicht schlecht.
Ich denke dass das nicht ganz offtopic ist.

[Marc (Gast)]

class A {...}

A statischesA;

[Bernd K. (prof7bit)]

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..

[(prx) A. K. (prx)]

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.

[+++ (Gast)]

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

[(prx) A. K. (prx)]

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.

[Tommi (Gast)]

@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.

[Stefan F. (Gast)]

Schau Dir Arduino an. Dort wird C++ angewendet, soweit es auf kleinen µC 
Sinn macht.

[Michael B. (laberkopp)]

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.

[Michael B. (laberkopp)]

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.

[(prx) A. K. (prx)]

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.

[Stefan F. (Gast)]

>> 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.

[Michael B. (laberkopp)]

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.

[Chris F. (chfreund)]

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.

[Georg A. (georga)]

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.

[Chris F. (chfreund)]

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. 
;-)

[Georg A. (georga)]

> 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 ;)

[Michael B. (laberkopp)]

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.

[Mark B. (markbrandis)]

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.

[Chris F. (chfreund)]

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?

[Sheeva P. (sheevaplug)]

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".

[Michael B. (laberkopp)]

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.

[Michael B. (laberkopp)]

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.

[Michael B. (laberkopp)]

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.

[Mikro 7. (mikro77)]

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]

[nicht"Gast" (Gast)]

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 ^^

[Chris F. (chfreund)]

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.

[Sheeva P. (sheevaplug)]

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! :-)

[Stefan F. (Gast)]

> 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.

[Mark B. (markbrandis)]

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.

[Carl D. (jcw2)]

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.

[(prx) A. K. (prx)]

Kurz ausgedrückt: Was ich nicht verstehe, das taugt nichts.

[Mark B. (markbrandis)]

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. ;-)

[Chris F. (chfreund)]

Sheeva P. schrieb:
>> Andere Leute sagen dazu;: Du bist dumm.
> Solange es reicht, C++ auch ohne Debugger zu verstehen, [...]

Made my day ... lol

[W.S. (Gast)]

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.

[Sheeva P. (sheevaplug)]

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.

[Carl D. (jcw2)]

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.

[(prx) A. K. (prx)]

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. ;-)

[(prx) A. K. (prx)]

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.

[Michael B. (laberkopp)]

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.

[Carl D. (jcw2)]

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.

[Sheeva P. (sheevaplug)]

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. ¦-)

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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. :-)

[(prx) A. K. (prx)]

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.

[Michael B. (laberkopp)]

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.

[Michael B. (laberkopp)]

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.

[Assembler ist das Beste der Welt (Gast)]

Am besten alles in Assembler schreiben.
Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen 
lernen.

[Hurz (Gast)]

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...

[Karl (Gast)]

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.

[Sheeva P. (sheevaplug)]

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. :-)

[(prx) A. K. (prx)]

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.

[Chris F. (chfreund)]

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. ;-)

[Chris F. (chfreund)]

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.

[Michael B. (laberkopp)]

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.

[Chris F. (chfreund)]

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. 
:)

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Bernd K. (prof7bit)]

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!

[Carl D. (jcw2)]

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.

[Karl Käfer (Gast)]

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. ;-)

[Tobias (Gast)]

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 
:-)

[Karl (Gast)]

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++).

[Daniel A. (daniel-a)]

@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.

[MaWin (Gast)]

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.

[Karl Käfer (Gast)]

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.

[W.S. (Gast)]

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.

[W.S. (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Dieter V. (Gast)]

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.

[Andreas H. (ahz)]

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

[Sheeva P. (sheevaplug)]

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ß.

[Scelumbro (Gast)]

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.

[Stefan F. (Gast)]

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.

[TriHexagon (Gast)]

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...

[Stefan S. (Gast)]

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

[MaWin (Gast)]

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.

[TriHexagon (Gast)]

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.

[HVV (Gast)]

Scelumbro schrieb:
> Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein
> AVR. Deswegen Programmiert auch niemand Windows mit ASM.

Ach Nein? Google mal MASM32...

[August E. (Gast)]

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 ;-)

[W.S. (Gast)]

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.

[Carl D. (jcw2)]

> 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?

[Durchstarter (Gast)]

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.

[Andreas H. (ahz)]

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

[Carl D. (jcw2)]

Moby A. schrieb im Beitrag #4634978:
> Ja, ein gewisser Hang die Dinge imposant aufzublasen wohnt dem Menschen
> schon inne ;-)

Ach!

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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.

[Scelumbro (Gast)]

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.

[Bernd K. (prof7bit)]

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.

[(prx) A. K. (prx)]

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.  ;-)

[Durchstarter (Gast)]

>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.

[(prx) A. K. (prx)]

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.

[Scelumbro (Gast)]

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.

[TriHexagon (Gast)]

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?

Window win;

//Oder mit ein paar Parametern
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.

[Sheeva P. (sheevaplug)]

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.

[MaWin (Gast)]

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.

[Sheeva P. (sheevaplug)]

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. ;-)

[Sheeva P. (sheevaplug)]

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?
>

> Window win;
> 
> //Oder mit ein paar Parametern
> Window win("Titel", 800, 600);
>

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". ;-)

[Daniel A. (daniel-a)]

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.

[(prx) A. K. (prx)]

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 .

[Sheeva P. (sheevaplug)]

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.

[MaWin (Gast)]

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.

[Scelumbro (Gast)]

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?

[Sheeva P. (sheevaplug)]

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. ;-)

[(prx) A. K. (prx)]

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.

[Carl D. (jcw2)]

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.

[Helmut D. (Gast)]

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 :-)

[Stefan F. (Gast)]

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

[(prx) A. K. (prx)]

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.

[D. I. (Gast)]

Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei 
dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...

[(prx) A. K. (prx)]

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. ;-)