D. I. schrieb:> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren> bei> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...
Das macht Moby schon - alleine und in ASM. Gut das Projekt darf nicht
komplexer sein, als LED-Blinky + Tastenentprellung. Und es muss auf
einem AVR laufen, schließlich ist x86 ASM zu komplex. Aber dann wird es
total effizient programmiert werden. Schließlich kann nur einer dran
arbeiten, dass heisst keine Schnittstellen, keine Architektur, keine
Absprachen,keine Meetings- kein Overhead, 100% Effizienz.
A. K. schrieb:> D. I. schrieb:>> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei>> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...>> Sicher, dass dies zu einem anderen Ergebnis führt? Solche Projekte haben> eine gewisse Neigung, in die Fritten zu gehen. ;-)
Nun ja das Ding lebt schon relativ lange und steckt in diversen
Endprodukten in unterschiedlicher Ausprägung in realen Produkten und
wird halt weiterentwickelt.
Moby A. schrieb im Beitrag #4635958:
> Sheeva P. schrieb:>> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den>> Anwendern selbst und ihren manchmal einfach bescheuerten Forderungen und>> Erwartungen.>> Damit hast Du wunderschön auf den Punkt gebracht was ich Dir an anderer> Stelle schon vorgehalten habe: Die Bedürfnisse Deiner Programmierung und> Deines Systems über die Forderungen und Erwartungen des Anwenders zu> stellen. Stichwort Admin-Welt! Das ist wieder mal der selbstherrliche> Entwickler wie er im Buche steht. Der Gott in weiß- äh der Gott am PC> ;-(
Weißt Du, ich arbeite gar nicht für Microsoft oder Adobe, und habe mit
den genannten GUI-Monstern aus diesen Häusern nicht einmal als Anwender
etwas zu tun. Es ist auch nicht meine Schuld, und erst recht nicht mein
Problem, daß es immer noch Leute gibt, die dieses Zeug kaufen.
Für die Feststellung, daß kommerzielle Software immer aufgeblähter
werden wird, je länger das Argument "jetzt mit neuen Funktionen, die
kein Mensch braucht" noch beim Verkauf zieht, bedarf keines besonderen
Genies, sollte also auch für Deinen Intellekt einigermaßen zugänglich
sein. Die meisten Anwender von Word, Excel, Access, Powerpoint und
Photoshop werden jedoch heute schon von ihrer Software überfordert und
benutzen nur einen kleinen Bruchteil der Funktionen dieser Software.
Und natürlich rede ich nicht davon, an den Forderungen und Erwartungen
von Anwendern vorbei zu entwickeln, was für eine selten dumme
Interpretation. Ganz im Gegenteil kritisiere ich, daß Kaufanreize immer
noch über neue, unnötige Funktionen gesetzt werden, anstatt sich darauf
zu beschränken, die benötigte und sinnvolle Funktionalität mit einer
sauberen Usability anzubieten. Gerade von Dir mit Deiner manischen
Phobie gegenüber allem, das komplizierter ist als ein Loch in den Schnee
zu pinkeln, hätte ich da eher volle Zustimmung erwartet. Stattdessen
versuchst Du schon wieder, mir die Worte im Mund herum zu drehen...
Langsam bekomme ich eine Idee davon, wen Einstein gemeint hat, als er
von unendlicher Dummheit sprach. :-)
Moby A. schrieb im Beitrag #4635945:
> Sheeva P. schrieb:>> War ja auch ne peinliche Geschichte mit Deinem C-Versuch.>>>> Ja, aber nicht für mich. :-)>> Also ich schrieb nichts in C.
Natürlich nicht. Das kannst Du ja auch gar nicht.
Sheeva P. schrieb:> wenn Du die geistigen Kapazitäten dazu hättest und nicht nur darauf> erpicht wärst, mir das Wort im Mund herum zu drehen.
Bei dir muss man nicht Worte im Mund umdrehen,
sondern ich ordne nur deine kruden Aussagen hier.
Du hingegen, nein, du verstehst das:
Sheeva P. schrieb:>> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit>> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie>> schon bei "Speichern" unverständlichen Welt wiedersieht.>> Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja,> das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst.
nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese
Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die
anderen vorhalten, was sie selber tun, sind krank. Such dir einen
Psychiater.
Sheeva P. schrieb:> LOL! Daß jemand, der so etwas wie GALBLAST.C verbrochen hat, mit> meinen Aussagen überfordert ist und sie nicht verstehen kann, dafür habe> ich ja ein gewisses Verständnis.
Es steht dir frei, das Programm besser zu schreiben (wäre nach 20 Jahren
ja mal Zeit, ist noch Win16), es ist open source.
Aber von Dummschwätzern wie dir kommt natürlich kein eigener Handschlag,
und die Anwender finden es gut zu bedienen, gut zu verstehen, gut zu
benutzen, sehen also keine Veranlassung es zu verunstalten.
Stefan U. schrieb:>> Übrigens hat nicht jeder Anwender den neuesten>> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP>> Programmierer voraussetzen.>> Blödes Argument.
Das Argument brauchte ich gar nicht bringen, das kommt hier:
Sheeva P. schrieb:> Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde> es mir nichts ausmachen, eine aufgeblähte Software zu benutzen,
Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben
darauf OOP-Software bis sie meinen daß alles in Odnung ist und
angemessen schnell läuft, und dann kommt die Software zum Anwender:
Stefan U. schrieb:> Ich habe OOP mit Turbo Pascal auf einem nicht vernetzten 286er mit 10Mhz> und 512MB RAM gelernt
Welchem auch immer, eben nicht dem leistungsfähigen Entwicklungsrechner
sondern dem realen Gerät und alle regen sich ZU REHT über die
lahmbarschige Bloatsoftware von Sheeva auf.
> weil ich bereits beim Design auf die nötige ... achte.> Alles andere ist m.M.n. als Gesamtkonzept Pfusch.
Tja, du hast echt Glück, wenn du Projekte mit sauberem Gesamtkonzept
umsetzen darfst.
In der Praxis ist es leider oft so, dass Kosten und Zieltermin schon vor
dem Funktionsumfang festgelegt werden. Dann werden Funktionen gefordert,
die sich gegenseitig stören bzw. wegen unvollständigem Konzept nicht
funktionieren können.
Irgendwann sagt Dir dein Auftraggeber "Fang schonmal an und mach
irgendwas sinnvolles. Die Detaul überlegen wir uns noch". Und dann
werden nur einige Konzept-Lücken geschlossen, stattdessen ständig andere
Funktionen gefordert. Und zwar nicht selten bis zum letzten Tag vor der
Abnahme - falls überhaupt eine offizielle Abnahme stattfindet. Manche
diese Forderungen stellen das gesamte Design der Software in Frage.
Und jetzt stelle Dir so ein Projekt vor, verteilt auf drei Firmen, die
sich nicht gerade lieb haben (da Konkurrenten) beauftragt von einem
Kunden, der Keine Ahnung hat (von Technik, Juristischen Aspekten und dem
Business) und trotzdem meint, selbst Projektleiter spielen zu können.
DAS, mein lieber Moby, ist die Realität, mit der sie die allermeisten
Programmierer tagtäglich herum schlagen müssen. Programmieren können ist
nur die halbe Miete (eher noch weniger). Projektarbeit ist die Kür.
Und zum Ausgleich arbeiten einige davon an Open-Source Projekten mit
oder machen ihre eigene Show, damit sie wenigstens einmal im Leben ein
aus ihrer Sicht sauberes Projekt durchziehen können, das man auch
vorzeigen kann ohne sich in den Boden zu schämen.
Ich behaupte, daß sich die Entwickler von 90% aller kommerziellen
Programme für ihre eigenen Werke schämen, da sie nichtmal die eigenen
Ansprüche von Qualität erfüllen.
Moby A. schrieb im Beitrag #4635907:
>>>> Scelumbro nochmal für Dich: Das hat auch niemand behauptet (jedenfalls> ich nicht).> Eine IDE wie VS zeigt aber alle konkreten Möglichkeiten der OOP auf, ist> insofern (und auch im Blick auf die vielen angebotenen> Spezial-Werkzeuge) Spiegelbild ihrer Komplexität
Moby, komplexe Software ist nicht die Folge von komplexen
Programmiersprachen. Ihre Komplexität ist vielmehr die Summe vieler
einfacher Teile. Die einfache Kombinierbarkeit dieser einfachen Teile
ist aber ein Vorteil von OOP. Viele Teile einer IDE haben auch nichts
mit der Programmiersprache an sich zu tun sondern bearbeiten Probleme
rund um ein Projekt wie Versionsverwaltung.
Moby A. schrieb im Beitrag #4634978:
> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP> Programmierung draus? Kilobyteweise Code...
Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du
bitte NICHT objektorientierte Programmierung mit irgend einer
Klassenbibliothek oder sonstiger Middleware.
Ich geb dir mal ein Beispiel: Wenn du mit Delphi eine GUI-Anwendung
schreibst, dann kostet dich ein simples "Hello World" bei Delphi 6 so um
die 400 KByte, bei Delphi 10 schon über 2 MB und wenn man dann noch nen
gefälligeren Skin drauf haben will, an die 3 MB - so etwa.
Das liegt aber NICHT an OOP, sondern an der jeweiligen Klassenbibliothek
und deren Grundstruktur, die ein echt4s Smart-Linking nicht zuläßt.
Wenn du hingegen mal sowas wie KOL (Key Objects Lib) ausprobiert
hättest, was nach einigem Installations-Eiertanz unter Delphi 6 recht
ordentlich läuft, dann würdest du sehen, daß das gleiche GUI-Programm
lediglich einige Dutzend KB (ich schätze so 20..25 K) benötigt. Und auch
die KOL ist tatsächlich OOP. siehe: "http://wiki.freepascal.org/KOL";
MaWin schrieb:> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie> schon bei "Speichern" unverständlichen Welt wiedersieht.
Eben. Verstehe ich genauso. In diesem Punkte treffen wir uns mal wieder.
Die Meinige macht auch ALLES mit MS Office, selbst Dinge, die ich
damit nie zuwege bringen würde.
Das ist eben immer wieder die für manche befremdliche tatsache, daß
Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch
verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS
Office geübt ist, ist damit weitaus besser und effektiver als jemand,
der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich
hier einen). ich sehe auch in der Firma viele, die mitdem Explorer
geradezu artistisch umgehen, was mir selbst (als TC-Benutzer) nicht
sonderlich genehm ist. OK, unsereiner kann damit selbstverständlich
umgehen, aber eben nicht so effektiv wie jemand, der damit warmgeübt
ist. Und bei der betreffenden Anwenderin sieht das genauso aus. Die Dame
hat ganz gewiß ein völlig anderes Arbeitsfeld und genau dieses ist es,
wo sie richtig gut sein muß - da ist sowas wie der PC nur eben das, was
er sein soll: ein Hilfsmittel und eben nicht der berufliche
Lebensinhalt.
Ganz viele der Schreiber hier in diesem Forum ignorieren das immer
wieder, bis hin dazu, daß so einer neulich solche Anwender und
Anwenderinnen als "brain dead" bezeichnet hat. Brett vor'm Kopf kann ich
dazu nur sagen.
W.S.
MaWin schrieb:> Sheeva P. schrieb:>>> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit>>> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie>>> schon bei "Speichern" unverständlichen Welt wiedersieht.>>>> Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja,>> das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst.>> nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese> Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die> anderen vorhalten, was sie selber tun, sind krank. Such dir einen> Psychiater.
Es war nicht die Anwenderin, sondern es warst Du, der mit dem
"Speichern" angefangen hat. Zum Glück hast Du die Entstehungsgeschichte
meiner Aussage ja bereits selbst zitiert; vielen Dank dafür, daß Du es
diesmal wenigstens korrekt und in der richtigen Reihenfolge zitiert
hast.
Und was das dummdreiste Provozieren angeht, kann ich Dir da lange nicht
das Wasser reichen. Beinahe jeder "Beitrag" von Dir ist mit persönlichen
Angriffen gespickt, nicht nur in diesem Thread hier. Jetzt rastest Du
aus, weil dieses Mal jemand dagegenhält und sich Deine wirren Pöbeleien
nicht widerspruchslos gefallen läßt. Das ist einerseits lustig, aber
auch sehr schade, denn schließlich wußten schon unsere Mütter: wie man
in den Wald hineinruft, so schallt es wieder heraus. Oder, kurz gesagt:
wenn Du schon so ein Mimöschen bist, solltest Du dringend damit
beginnen, Dein eigenes Sozial- und Kommunikationsverhalten zu
überarbeiten.
MaWin schrieb:> Übrigens hat nicht jeder Anwender den neuesten> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP> Programmierer voraussetzen.>> Sheeva P. schrieb:>> Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde>> es mir nichts ausmachen, eine aufgeblähte Software zu benutzen,
Ich habe die Zitate mal in die richtige Reihenfolge gebracht:
tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem
dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren
meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort,
insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.
Es ist wirklich schade, daß jemand, der so viel von Elektronik versteht
wie Du, so unfähig ist, ohne Beleidigungen zu kommunizieren. Daß Du Dich
unter Verdrehung der Tatsachen aber jetzt noch zum, selbstverständlich
gänzlich unschuldigen Opfer stilisierst, ist entweder unglaublich frech
oder ein Zeichen dafür, daß Du ein Problem mit der Diskrepanz ziwschen
Deiner Selbst- und Außenwahrnehmung hast, und die mir so warm empfohlene
professionelle Hilfe sehr viel nötiger hast als ich. Viel Glück!
Moby A. schrieb im Beitrag #4636025:
> A. K. schrieb:>> Moby/Sheeva: Meint ihr wirklich, dass ihr mit wechselseitigen>> Beschimpfungen weiter kommt?>> Ich beschimpfe niemand. Trotzdem kann und sollte man manchen Leuten> natürlich deutlich ihre Defizite vor Augen führen. Ein SheevaP hat das> mit seinem Kommunikationsniveau ganz besonders nötig.
:-)
W.S. schrieb:> Moby A. schrieb im Beitrag #4634978:>> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt>> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt>> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer>> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP>> Programmierung draus? Kilobyteweise Code...>> Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du> bitte NICHT objektorientierte Programmierung mit irgend einer> Klassenbibliothek oder sonstiger Middleware.
Danke für diesen sachlichen, unaufgeregten Beitrag.
> Das ist eben immer wieder die für manche befremdliche tatsache, daß> Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch> verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS> Office geübt ist, ist damit weitaus besser und effektiver als jemand,> der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich> hier einen).
Natürlich. Dennoch erscheint es mir einigermaßen widersprüchlich, wenn
die Anwender dieser Software sich dann einerseits über deren
Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf
einfache und bereits installierte Alternativen zurückweisen. Stattdessen
wurden in dem von mir vorgebrachten Beispiel dann gleich drei Admins,
ein Vorgesetzter, und ein Mitarbeiter des Einkaufs in Marsch gesetzt und
dann eine Erweiterung des Arbeitsspeichers für die Dame verbaut. Das
Problem, daß die Dame über zu langsame Software beklagt, ist leider
trotzdem geblieben.
Solche Geschichten begegnen unseren Admins ständig: ein Anwender will
unbedingt die teuerste Version seines Betriebssystems, kann aber weder
sagen, was der Unterschied zur einfachen Variante ist, noch, welche
Funktionen der teueren Version er braucht. Ein anderer Anwender möchte
dringend eine Photoshop-Lizenz um ein paar Bilder zu skalieren, weil er
Photoshop ja von zuhause kennt, und schreit unseren Einkäufer an, wenn
sein Ansinnen abgelehnt und stattdessen PSP empfohlen wird.
Gleichzeitig sehe ich die Diskussionen hier im Forum, wo Windows-User zu
Linux wechseln, weil sie von Windows die Nase voll haben, und sich dann
darüber beklagen, daß Linux nicht genauso wie Windows ist... ach, war
gerade das nicht der Grund für den Wechselgedanken?
Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und
Entwicklersicht sehe. Trotzdem komme ich beim besten Willen nicht um die
traurige Feststellung herum, daß die Erwartungen, die manche Anwender an
ihre Software, ihre Entwickler und ihre Admins stellen, manchmal einfach
unrealistisch, und in anderen Fällen schlicht ignorant sind. Niemand
kann mir einreden, daß daran immer nur die Admins und Entwickler schuld
seien. Und ich glaube, die unkritische Haltung "der Anwender hat immer
Recht" ist eine der wesentlichen Ursachen für die unrealistische
Erwartungshaltung und die daraus resultierende Unzufriedenheit vieler
Anwender.
Aber laßt uns zum eigentlichen Thema zurückkommen: der OO.
Sheeva P. schrieb:> Ich habe die Zitate mal in die richtige Reihenfolge gebracht:> tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem> dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren> meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort,> insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.
Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also,
daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt.
Offensichtlich bist du aber überfordert, Satz und Sachverhalt
nachzuvollziehen.
Sheeva P. schrieb:> Niemand> kann mir einreden, daß daran immer nur die Admins und Entwickler schuld> seien.
Dachte ich mir. Nennt man wohl Blindheit gegenüber eigenen Defiziten.
Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR
IHN sollte die Software geschrieben sein, schlieb also nicht plump die
Schuld auf ihn. Daß der Entwickler schlechte Rahmenbedingungen gehabt
haben mag, vor allem zu wenig Zeit, Überforderung, mag alles als
Entschuldigung herhalten. Letztlich hat er es aber verbrochen, selbst
wenn die Vorgaben von einem fachlich uninformierten Chef kamen. Red dich
also nicht raus und schieb die Schuld auf andere. Leider gibt es von
deinr Sorte viele unter den Entwicklern.
Sheeva P. schrieb:> Aber laßt uns zum eigentlichen Thema zurückkommen: der OO.
Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da
diskutiert es sich ja noch mit einem Islamisten besser. Aber so wie der
Wasser predigt und Wein trinkt, so predigst du OOP, nutzt aber lieber
Programme die ordentlich geschrieben wurden. Danke, mehr woltlen wir
nicht wissen.
MaWin schrieb:> Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR> IHN sollte die Software geschrieben sein, schlieb also nicht plump die> Schuld auf ihn.
Du behaupest also, Anwender können nicht zu dumm für ihre Arbeit sein?
Ui, hier ist ja wieder was los...
MaWin schrieb:> Sheeva P. schrieb:>> Ich habe die Zitate mal in die richtige Reihenfolge gebracht:>> tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem>> dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren>> meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort,>> insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.>> Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also,> daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt.
Also ich habe das ganz anders verstanden. Du hast Entwicklern und Admins
pauschal und böswillig unterstellt Ressourcen zu verschwenden. Sheeva
hat nur gesagt daß er sich eine Ressourcen verschwendende IDE leisten
kann weil er auf seinen Rechnern genügend Power hat.
> Offensichtlich bist du aber überfordert, Satz und Sachverhalt> nachzuvollziehen.
Offensichtlich willst Du ihn mißverstehen um ihn zu provozieren.
> Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR> IHN sollte die Software geschrieben sein, schlieb also nicht plump die> Schuld auf ihn.
Wenn die Software für die Anwender geschrieben wäre würden sie nicht
dauernd darüber schimpfen. Entweder ist die Software also nicht für die
Anwender geschrieben oder die Anwender kaufen die falsche Software.
Er erklärt das mit den Mechanismen des heutigen Softwaremarktes. Du
hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst?
> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da> diskutiert es sich ja noch mit einem Islamisten besser.
Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
Merkst Du eigentlich noch was?
> oder die Anwender kaufen die falsche Software.
Viele (vielleicht gar die meisten) Anwender müssen mit Software
arbeiten, die andere gekauft haben. Diese ärgern sich dann besonders
schnell über Mängel.
Karl Käfer schrieb:> Wenn die Software für die Anwender geschrieben wäre würden sie nicht> dauernd darüber schimpfen.> Entweder ist die Software also nicht für die Anwender geschrieben
Das stimmt natürlich sogar manchmal, beispielsweise bei Produkten wie
Windows, wo es nicht den einen Kunden gibt, sondern alle Kunden etwas
vorgesetzt bekommen.
Aber Auftragsentwicklung hätte natürlich den Kunden für den sie
geschrieben wird, und Software für den Markt sollte so sein daß
möglichst viele Menschen als Anwender in Frage kommen.
> oder die Anwender kaufen die falsche Software.
Kann schon sein, manchmal haben sie keine Wahl. Daher zahlen sie wohl
auch so ungerne dafür: Die Erlebnisse waren zu schlecht als daß die
Software was wert gewesen wäre.
> Er erklärt das mit den Mechanismen des heutigen Softwaremarktes.
Er erklärt es eher gar nicht, sondern sagt einfach der Anwender ist
schuld, der hat doch gefälligst seine Sofwtare toll zu finden.
> Du hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst?
Es liegt oft an Leuten wie Sheeva, die nicht in der Lage sind, sich in
andere Menschen hineinzuversetzen und hochtrabend selbstüberzeugt
glauben ihre Position wäre die einzige richtige. Eben wie religiöse
Dogmatiker.
Sheeva ist so ziemlich das Abziehbild von dem Entwickler der alles
falsch macht:
- Er glaubt, in OOP Läge das Heil.
- Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker
Software) als Entwicklungrechner als sie später der Kunde hat.
- Er sieht die Fehler beim Anwender und nicht bei sich selbst.
>> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da>> diskutiert es sich ja noch mit einem Islamisten besser.>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
Im Gegenteil, er ist schlimmer.
MaWin schrieb:> - Er glaubt, in OOP Läge das Heil.
Meiner Erfahrung nach ist das tatsächlich so.
MaWin schrieb:> - Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker> Software) als Entwicklungrechner als sie später der Kunde hat.
Aber sicher doch. Ein Entwicklungsrechner kann garnicht genup Power
haben. Trotz Xeon mit 16 Kernen (hyperthreaded), 32 Gig RAM und SSD baue
ich an meinen aktuellen Projekten z.T. > 1h. Der Rechner dürfte also
gerne noch schneller sein :-) (ja, die Projekte sind groß)
Zum TESTEN kann man dann gerne Gammel-Rechner einstzen, wie sie manche
Kunden noch verwenden...
MaWin schrieb:> - Er sieht die Fehler beim Anwender und nicht bei sich selbst.
Auch der Anwender ist nicht über jeden Zweifel erhaben...
MaWin schrieb:>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.>> Im Gegenteil, er ist schlimmer.
Weil er er wagt, gegen Deine und Mobys krude OOP-Verschwörungstheorien
anzudiskutieren?
Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges
stichhaltiges Argument. Pfui.
Stefan K. schrieb:> Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges> stichhaltiges Argument. Pfui.
Hmm, dein einziger Beitrag hier.
Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung.
Du ahst also im ganzen Thread nichst gebracht.
Stefan, das ist: Unter aller Sau.
MaWin schrieb:> Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung.
Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett
mitgelesen? Oder verwechselst Du irgendwen? Persönliche Diffamierung
finde ich hier hauptsächlich in Deinen Beiträgen.
Moby A. schrieb im Beitrag #4635907:
> Das hab ich mir noch nicht vorstellen müssen weil ich bereits beim> Design auf die nötige Anzahl identisch ansprechbarer Hardware-UARTS> achte. Alles andere ist m.M.n. als Gesamtkonzept Pfusch.
Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen
zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus
Konstengründen gestrichen.
Also was ist jetzt?
Stefan K. schrieb:> Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett> mitgelesen? Oder verwechselst Du irgendwen?
Bist du Sheeva Plug ? Argumente lieferte er jedoch nicht, bloss
Behauptungen. Und versucht sich in frechen Umdeutungen
Da behauptet er:
! > Wie schlecht objektorientierte Formulierungen von durchaus
! > objektorientierten Welten sein können, sieht man an MFC.
! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern
! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.
daß MFC kein OOP wäre. Das ist schlicht gelogen, aber irgendwie muss er
ja vermeiden daß seine allumfassendee Heilsbotschaft "OOP ist gut"
Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber
natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um
das WinAPI, aber nichtsdestrotrotz OOP und Grundlage für viele OOP
Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und
schlecht wartbar, aber immer noch eine Realisierung in OOP. Das darf
natürlich nach seiner Heilsdoktrin nicht sein.
Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges.
Also immer erst mal vor der eigenen Haustür kehren.
> Persönliche Diffamierung finde ich hier hauptsächlich in Deinen Beiträgen.
Blinde mit Scheuklappeen, ja ja.
Bernd K. schrieb:> Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen> zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus> Konstengründen gestrichen.>> Also was ist jetzt?
Moin,
darauf zu Pochen ist müßig bei Moby. Erweitern von Projekten kennt er
nicht und da haben schon gefühlt 100 Leute in anderen Threads
nachgehakt, nachgefragt... verzweifelt.
Heb dir deine Kraft für die Diskussion um OOP auf^^.
Zum Topic. Ich bin immer etwas verwundert, warum die Leute so Probleme
mit dem Konzept haben. Eigentlich abstrahiert es doch die Realität viel
besser als rein prozedurale Programmierung.
Das wird ja in der Naturkunde auch so gemacht.
Hier ein Beispiel aus aktuellem Anlass :)
Apfel --- Birne
Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in
Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden
(Ableitungen).
Moby A. schrieb im Beitrag #4636020:
> Dann erstelle mal ein leeres Win-Fenster mit Visual C++ und schau Dir> die resultierende Codegröße an. Da wird Dir auch ein>>> Window win("Titel", 800, 600);>> im Programm wenig Ersparnis bringen.> Wenn freilich die paar Ascii-Bytes dieser Zeile schon das ganze> Programm wären... So einfach ist es aber leider nicht. Warum nur?
Zugegenermaßen in C# ist die Datei 6,5K groß. Du tust allerdings so, als
wenn jedes eingebene Zeichen die Datei proportional weiter vergößern
würde. Die größten Platzfresser bei den Programm sind aber nun mal nicht
die Code Binaries, sondern die restlichen Ressourcen wie Bilder, Daten
und ähnliches.
Ach ich seh grad. Ich hab ausgerechnet Moby zitiert. Bitte ignorieren.
Grüße.
MaWin schrieb:> Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges.
Ich fordere hier einen besseren Umgangston ein. Beleidigungen und
persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen
"Diskussionsbeiträgen") werden in diesem Forum nicht toleriert:
MaWin schrieb:> Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser> Einstellung zum schlechtesten Programmierer der Welt machst auf den alle> Anwender einen Hass haben.MaWin schrieb:> Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die> du hier über OOP aufgetischt hast.MaWin schrieb:> Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben> darauf OOP-Software bis sie meinen daß alles in Odnung ist und> angemessen schnell läuft, und dann kommt die Software zum Anwender:MaWin schrieb:>>> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da>>> diskutiert es sich ja noch mit einem Islamisten besser.>>>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.>> Im Gegenteil, er ist schlimmer.
Stefan K. schrieb:> persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen> "Diskussionsbeiträgen") werden in diesem Forum nicht toleriert
Deine hingegen schon ? Merkwürdige Lebensauffassung.
Stefan K. schrieb:> krude OOP-Verschwörungstheorien> purer Populismus.> Hetze ohne ein einziges stichhaltiges Argument.> Pfui.
Nach
>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.>> Im Gegenteil, er ist schlimmer.
war das ja wohl mehr als angemessen.
Dafür, dass Du andere Forenteilnehmer mit Gewalttätern gleichsetzt, bist
Du bei Deiner eigenen Person merkwürdig empfindlich.
>Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in>Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden>(Ableitungen).
^^Vielleicht gibt es ja deshalb so viel Schlechtes in der Welt - weil
sie auf OO gründet!
(Tut mir leid, konnt´s mir nicht verkneifen)
Karl Käfer schrieb:> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.> Merkst Du eigentlich noch was?
Stop mal, mein Junge!
Du bist es, der hier nichts merkt.
Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter
gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat
stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit
einem Islamisten besser".
Abgesehen davon kann ich mich immer noch an einen Papst erinnern, der
mit dem Attentäter, der es auf ihn abgesehen hatte, diskutiert hat.
Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das
Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das
sachliche Ausdiskutieren von Argumenten ein. Aber stattdessen sehe ich
hier bösartige Unterstellungen und ne Menge Fanatismus.
Sheeva P. schrieb:> Dennoch erscheint es mir einigermaßen widersprüchlich, wenn> die Anwender dieser Software sich dann einerseits über deren> Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf> einfache und bereits installierte Alternativen zurückweisen.
Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows
und gerade MS Office von Milliarden von Leuten benutzt werden. Glaubst
du ernsthaft, diese wären alle mental gleichgeschaltet? Natürlich nicht!
Also gibt es immer eine Verteilung von Ansprüchen und Meinungen. Ob
Gauss oder ne andere Verteilung.
Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe
ich nirgendwo - ganz besonders nicht "einfache und bereits installierte
Alternativen". Was denn bitte? Nein, das war lediglich ein vorlauter
Zungenschlag deinerseits. Ich hab vor vielen Jahren in der Firma die
Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel
wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus
Leuten, die eben nicht zum EDV-Gesindel gehören.
Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben
dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten
und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht
dort gefunden haben, wo sie bisher waren.
Begreif das mal als ein echtes Problem.
Es IST ein echtes Problem.
Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für
DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen
Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild
heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen
und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene
wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die
167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun
wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen
sind anders, ebenso die Mengen usw. Verstehst du, was ich meine?
Sheeva P. schrieb:> Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und> Entwicklersicht sehe.
Zumindest ist die Erkenntnis dessen ein erster Schritt.
ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß
behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das
dahinterstehende Prinzip ist es, worauf es ankommt:
"Schreib dein Manual so, als ob du es für einen alten Advokaten
schreiben würdest. Der versteht von deiner Arbeit und deinem Fache
reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen.
Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz
- jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen
rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört
dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann
auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im
Gesagten hattest und nicht wo sein Verstand zu gering wäre."
W.S.
MaWin schrieb:> Stefan K. schrieb:>> Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett>> mitgelesen? Oder verwechselst Du irgendwen?>> Bist du Sheeva Plug ?
Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin
ich jedenfalls nicht er.
> Argumente lieferte er jedoch nicht, bloss Behauptungen.
Du scheinst mich mit jemandem zu verwechseln, eventuell mit Dir selbst.
> Und versucht sich in frechen Umdeutungen>> Da behauptet er:> ! > Wie schlecht objektorientierte Formulierungen von durchaus> ! > objektorientierten Welten sein können, sieht man an MFC.> ! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern> ! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.> daß MFC kein OOP wäre. Das ist schlicht gelogen,
Das wäre es, wenn ich das gesagt hätte. Habe ich aber gar nicht, wie Du
selbst hättest bemerken können, wenn Du nicht mehr Energie investieren
würdest, mich mißzuverstehen, als darin, meine Aussagen zu lesen.
Tatsächlich habe ich nicht geschrieben, daß die "MFC kein OOP wäre". Was
ich geschrieben habe, ist, daß die MFC kein OO-Design ist, sondern nur
ein OO-Wrapper um eine im Kern prozedurale API, die WinAPI. Verstehst Du
nicht den Unterschied zwischen "kein OO" und "kein OO-Design"?
Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein
OO-Schnittstelle zu einer nicht-OO-API statt eines OO-Designs ist; daß
sie aus einer Zeit stammt, in der es noch nicht sehr viele Erfahrungen
mit OO unter C++ gab und die OO unter C++ noch relativ unausgereift war;
daß Microsoft damals dazu tendierte, Frameworks unnötig aufzublähen und
die interne Funktionalität seines Betriebssystems als Geschäftsgeheimnis
zu betrachten.
Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als
Beispiel für die Stärken oder Schwächen der OO zu betrachten; da eignen
sich echte OO-Frameworks wie Qt, wxWidgets, die Boost-Libraries oder
sogar .NjET viel besser.
> aber irgendwie muss er ja vermeiden daß seine allumfassendee> Heilsbotschaft "OOP ist gut"
Das ist gar nicht meine Botschaft, und das habe ich auch nie gesagt. In
Wahrheit habe ich sogar ganz ausdrücklich geschrieben: "OO ist nur eins
von einer ganzen Reihe von Werkzeugen, die ich nutze" [1], daß "die
verbreiteten Sprachen [] alle mehrere Paradigmen unterstützen", die "in
der Praxis [] oft parallel genutzt" werden [2], daß ich "bei großen
Datenmengen [] eher zu funktionalen Techniken [tendiere]" [3], und:
"Wenn es morgen eine einfachere Möglichkeit gibt, dann bin ich der
Erste, der sie adoptiert" [4].
Von einer "Heilsbotschaft", gar einer "allumfassenden", habe ich nichts
geschrieben, das findet alles nur in Deinem eigenen Kopf statt. Pardon,
aber für die Vorgänge in Deinem Kopf bin ich nicht verantwortlich.
[1] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[2] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[3] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[4] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"> Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber> natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um> das WinAPI,
Nichts anderes habe ich gesagt, und das hier:
> aber nichtsdestrotrotz OOP und Grundlage für viele OOP> Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und> schlecht wartbar, aber immer noch eine Realisierung in OOP.
...steht dem, was ich gesagt habe, nicht entgegen. Das Problem scheint
zu sein, daß Du nicht zuhörst und deswegen oft etwas ganz anderes liest,
als Dein Gegenüber schreibt, und Dich dann an den Strohpuppen
hochziehst, die nur in Deinem eigenen Kopf stattfinden. Das andere
Problem ist, daß Du zwar wacker austeilen, aber nicht einstecken kannst,
und mit Widerspruch, sagen wir mal, eher mäßig gut umgehen kannst.
> Blinde mit Scheuklappeen, ja ja.
Wer im Glashaus sitzt, ...
Es gibt schon komische Leute hier, weil sie das Konzept von OOP nicht
verstehen ist es Teufelszeug und als Kronzeuge dafür muss MS herhalten.
Leute die auch mal über ihren Tellerand schauen und in OOP auch Vorteile
erkennen werden wild beschimpft und als blöd abgestempelt. Und das
Lamentieren über Programmgrößen und Performance ist überhaupt nicht
nachvollziehbar. 1. Hat das nichts mit OOP zutun und 2. ist die aussage,
dass ein leeres Fenster zuviel Speicher braucht ungefähr so wie die,
dass ein LKW zuviel Diesel brauch und zu langsam ist, um an die Arbeit
zu fahren.
W.S. schrieb:> Karl Käfer schrieb:>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.>> Merkst Du eigentlich noch was?>> Du bist es, der hier nichts merkt.> Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter> gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat> stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit> einem Islamisten besser".
MaWin hat dieser Interpretation jedenfalls nicht widersprochen.
> Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das> Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das> sachliche Ausdiskutieren von Argumenten ein.
Das sachliche Ausdiskutieren bedingt zunächst einmal das Vorbringen
von sachlichen Argumenten. MaWin hat zu diesem Thread bisher nur
unbelegte Behauptungen, bösartige Unterstellungen und wüste Pöbeleien
"beigetragen", oder kannst Du mir ein einziges sachliches oder gar
begründetes Argument von ihm zeigen? Schon sein erster Beitrag in diesem
Thread beinhaltet a) die unbelegte Behauptung, die Unterstützung durch
die OOP sei eine offene Frage, b) die Unterstellung, alle Uniabsolventen
könnten kein C++ sowie c) die unsinnige Behauptung, die MFC sei eine
objektorientierte Bibliothek und demonstriere, wie schlecht die OOP sei.
Und das war noch sein mit Abstand harmlosestes Posting in diesem Thread,
denn schon in seinem zweiten "Beitrag" hier mißversteht er mich
böswillig und absichtlich und behauptet, mir mangele es an Hirn, das
irgendjemand deswegen werfen möge. In einem ähnlichen Stil geht der
zweite "Beitrag" dann auch gleich weiter: KFZ-Hersteller sind allesamt
arrogant und darum nicht daran interessiert, potentiell tödliche Fehler
an ihren Produkten zu beheben. Dann wieder gezielt und persönlich gegen
mich: die "Analysen", von denen er keine zitieren oder verlinken kann,
soll ich -- "weil ich es gerne will" -- "von der Hand wischen" wollen,
und was ich "nicht will, das gibt es nicht"; ich "mache mir das Leben
schön", lebe "in einer Traumwelt" und "im Notfall" (in welchem
eigentlich?) "rede" ich mich "'raus".
Im dritten Beitrag ist dann Scelumbro das Ziel, der "der schlechteste
Programmierer der Welt" sein soll, "auf den alle Anwender einen Hass
haben". Wenn Du magst, kann ich noch seitenweise weitermachen, schlage
jedoch vor, daß wir uns das für diesmal sparen.
Zu all dem hast Du nichts gesagt, um Karl nun mit dieser Spitzfindigkeit
zu kommen, da sei doch gar nicht die Person, sondern nur die Diskussion
gemeint gewesen? Ach kommm.
> Aber stattdessen sehe ich hier bösartige Unterstellungen und ne Menge> Fanatismus.
Ja, aber die gehen allesamt von genau zwei Usern aus. Ich freue mich
aber, daß Du in einem der beiden Fälle mittlerweile etwas gesagt hast
und auch selbst zu einem sachlichen Umgang gefunden hast. Danke dafür.
> Sheeva P. schrieb:>> Dennoch erscheint es mir einigermaßen widersprüchlich, wenn>> die Anwender dieser Software sich dann einerseits über deren>> Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf>> einfache und bereits installierte Alternativen zurückweisen.>> Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows> und gerade MS Office von Milliarden von Leuten benutzt werden.
Ja, natürlich, das ist das inhärente Merkmal von Standardsoftware. Aber
wenn Du Dir mal zum Beispiel die Apple-Software anschaust, dann erkennst
Du schnell, warum die gerade bei solchen Leuten besonders erfolgreich
war und ist, die mit der Technik ganz besonders wenig zu tun haben
wollen: Grafiker, Musiker, und andere Kreative. Das liegt auch nicht
(nur) daran, daß die Macs schön hip aussehen, sondern das war auch schon
so, als die Macs noch genau dieselben langweiligen beigen Kisten waren
wie die PCs.
(Um Weiterem vorzubeugen: mein letzter Mac war ein Mac II).
> Glaubst du ernsthaft, diese wären alle mental gleichgeschaltet?
Nein, wie kommst Du darauf? Habe ich das irgendwo gesagt oder auch nur
angedeutet?
> Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe> ich nirgendwo - ganz besonders nicht "einfache und bereits installierte> Alternativen". Was denn bitte?
Es ging dabei um ein konkretes Beispiel, in dem für den Anwendungsfall
"Gesprächsnotizen" statt MS Wörd als "einfache und bereits installierte
Alternative" Notepad empfohlen worden war. Da kann ich mich ziemlich gut
dran erinnern, denn schließlich habe ich diese Story selbst erlebt und
hier als Beispiel eingebracht.
> Ich hab vor vielen Jahren in der Firma die> Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel> wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus> Leuten, die eben nicht zum EDV-Gesindel gehören.
Auch in diesem Punkt habe ich nie etwas Gegenteiliges behauptet. Würde
ich auch nie, schon gar nicht, weil wir im letzten Jahr von Groupwise
auf MS Exchange und Outlook umgestellt haben, mir die Schwierigkeiten
dabei voll bewußt und gut erinnerlich sind, und wir uns immer noch mit
verschiedenen Nickeligkeiten als Ergebnis der Migration herumschlagen.
Damit habe ich selbst zwar glücklicherweise nicht viel zu tun, bekomme
es aber natürlich bei den Kollegen in den anderen Teams immer noch
hautnah mit.
> Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben> dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten> und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht> dort gefunden haben, wo sie bisher waren.> Begreif das mal als ein echtes Problem.> Es IST ein echtes Problem.
Das weiß ich alles und habe auch niemals etwas anderes gesagt, oder?
Hier ging es aber doch gar nicht um verschiedene Versionen von MS-Office
oder um Alternativen dazu, sondern einzig und alleine darum, daß Notepad
für schnelle Notizen nun einmal besser geeignet ist als Wörd oder ein
anderer Wortprozessor. Nur darum ging es, und um nichts anderes. (Ganz
am Rande bemerkt: "Notepad" heißt übersetzt soviel wie "Notizblock", was
IMHO sehr eindeutig darauf hinweist, wofür dieses Programm besonders
geeignet ist.)
Wie kommst Du darauf, daß es um verschiedene Office-Versionen gegangen
sei? Drücke ich mich wirklich so unklar aus? Mache ich zu viele Worte
für die junge Generation Twitter, oder wo liegt das Problem?
Schau, ich verstehe sehr gut, daß Anwender nicht zwischen GUI-Monstern
wechseln wollen, wenn sie einmal eins gelernt haben. Was ich aber nicht
verstehe, ist, daß sie a) immer zu den fetten Profimonstern greifen,
wenn sie die Wahl haben, und b) für Aufgaben, die mit verfügbarer,
einfacher, kleiner und flotter Software wie Notepad gelöst werden
könnten, trotzdem immer noch zu denselben fetten Monstern greifen.
> Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für> DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen> Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild> heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen> und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene> wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die> 167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun> wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen> sind anders, ebenso die Mengen usw. Verstehst du, was ich meine?
Mein Sanskrit ist nicht mehr so gut, und mit den Hieroglyphen hatte ich
schon in der Schule meine Schwierigkeiten... Nein, im Ernst: wenn Du mir
sagen willst, daß die Umstellung auf eine neue Software einen
Lernaufwand erfordert, bin ich ganz bei Dir, wenngleich ich den
Lernaufwand in dem oben genannten Beispiel -- also: den "Umsteig" von
Wörd auf Notepad für einfache Notizen -- für ausgesprochen überschaubar
halte.
> Sheeva P. schrieb:>> Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und>> Entwicklersicht sehe.>> Zumindest ist die Erkenntnis dessen ein erster Schritt.
Dann wird es Dich vielleicht freuen, daß ich mir dieser Erkenntnis
bereits seit vielen Jahren bewußt bin, sie mich allerdings trotzdem
nicht davon abhält, mir aus meiner ganz persönlichen, professionellen
Perspektive eine Meinung über das leider oft inkonsistente und
irrationale Verhalten von "normalen Anwendern" zu bilden. Die "normalen
Anwender" setze ich da mal in Anführungszeichen, weil es so etwas meiner
Meinung nach nicht wirklich gibt; die Wahrnehmung von Anwendern als
Individuen mit individuellen Vorstellungen, Bedürfnissen und
Arbeitsweisen erscheint mir jedenfalls zielführender als die grobe
Einteilung zwischen "normale" und "unnormale" Anwender. ;-)
> ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß> behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das> dahinterstehende Prinzip ist es, worauf es ankommt:>> "Schreib dein Manual so, als ob du es für einen alten Advokaten> schreiben würdest. Der versteht von deiner Arbeit und deinem Fache> reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen.> Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz> - jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen> rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört> dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann> auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im> Gesagten hattest und nicht wo sein Verstand zu gering wäre."
Das ist alles schön, gut und auch sehr richtig, betrifft mich aber
nicht. Ich entwickle keine Software für Endanwender, sondern für einen
äußerst exklusiven Personenkreis, in welchem ich jedes einzelne Mitglied
seit Jahren persönlich kenne. Ich habe das schon einmal geschrieben,
aber es ist anscheinend untergegangen: mit Endanwendern wie der im
Beispiel genannten Dame habe ich nur insoweit zu tun, als diese mich
mögen, meine Kompetenzen schätzen (was beides auf Gegenseitigkeit
beruht, am Rande bemerkt), und darum mit ihren Problemen erst zu mir
kommen, bevor sie unsere Windows-Techniker fragen.
Meine eigentlichen Aufgaben liegen eher in einem Bereich, der neudeutsch
als "Big Data", "Data Mining" und "Data Science" bezeichnet wird:
Analyse, Exploration, Visualisierung von Daten, Distributed Computing,
Skalier- und Hochverfügbarkeit, Echtzeit-Streaming, solche Dinge. Ich
entwickle keine Anwendersoftware und betreue weder Anwender noch
Anwendersoftware. Die einzigen armen Leute, die mit meiner Software
arbeiten müssen, sind meine Mitarbeiter und Kollegen sowie ich selbst,
und wir alle kommen mit meiner Software erstaunlich gut zurecht.
Insofern ist MaWins Unterstellung, ich würde Anwender mit aufgeblähten
OO-Programmen nerven, selbst jedoch eher schnelle PP-Software nutzen,
ganz flashc. Im Moment benutze ich hauptsächlich Apache Spark, Apache
Storm und ein paar andere Werkzeuge aus dem Hadoop-Universum, die samt
und sonders objektorientiert sind, und die von mir verwendete
GUI-Software wurde mit Ausnahme des GNU/Emacs ebenfalls objektorientiert
entwickelt. Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und
ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert,
vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden
sind, noch in den Kinderschuhen steckte.
Sheeva P. schrieb:> Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und> ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert,> vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden> sind, noch in den Kinderschuhen steckte.
Neben dem Alter würde ich mal behaupten, dass viele
Kommandozeilenprogramme vom Umfang her auch nicht wirklich eine OOP
brauchen. Die meisten Programme beschränken sich ja auf einen Input,
einen Output und ein paar Parameter, die noch übergeben werden.
Klassisches EVA-Prinzip halt.
W.S. schrieb:> Karl Käfer schrieb:>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.>> Merkst Du eigentlich noch was?>> Stop mal, mein Junge!>> Du bist es, der hier nichts merkt.> Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter> gleichgesetzt.
Meine Interpretation hat MaWin doch mittlerweile selbst bestätigt und
sogar geschrieben er sei schlimmer. Das war übrigens noch bevor Du
Deinen Beitrag gepostet hast. Vielleicht merk ich mehr als Du denkst? ;)
Sheeva P. schrieb:> Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein> OO-Schnittstelle zu einer nicht-OO-API
Du kennst dich wohl nicht so aus, denn das WinAPI ist eine sehr gute
Implementation eines OO-Designs in normalem C. Objekte werden durch
Handles abgebildet, was self Pointer in das Datensegment des
Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B.
vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen
sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden
etc. und Fensterklassen um Unterklassen erweitern, DefWndProc.
Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet
wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine
class.
Weitere von dir abgeleitet Schlussfolgerungen sind damit genau so
falsch.
Sheeva P. schrieb:> Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als> Beispiel für die Stärken oder Schwächen der OO zu betrachten;
Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt.
Allerdings sind sher viele Programme damit geschrieben, es halt also
sher wohl einen erklecklicher Anteil an der Realität der OO Software.
> Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin> ich jedenfalls nicht er.
Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und
behauptet das wären seine Argumente.
Sheeva P. schrieb:> MaWin hat dieser Interpretation jedenfalls nicht widersprochen.
Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr so
lange ihnen niemand widerspricht und ziehst Diskussionen daher so lange
durch bis dir genervt niemand mehr widerspricht. Funktionierte
vielleicht bei deiner Mama, im echten Leben eher nicht.
Es gibt sehr viel Software.
Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.
Es gibt sehr viel schlechte Software.
Viele der Software ist schlecht trotz der OO Techniken.
Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden
ist.
Eine richtige statistische Auswertung gibt es dazu nicht.
Aber die Annahme, es wäre durch OO besser geworden, darf stark
angezweifelt werden.
Das tue ich, und begründe es, unter anderem weil man in C++ an vielen
Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext
kein einziges Zeichen steht. Das führt meiner Erfahrung nach zu
schlechter Wartbarkeit und dazu daß Programmierer den Überblick
verlieren wie aufwändig die Sachen sind die sie machen, also langsame
Bloatware erzeugen. Gegenargumente kamen keine. Demnach stimmt es also,
nach deiner Weltsicht.
Du ziehst über GalBast her.
Dieses (winzige) Programm jedoch besser zu machen bringst du nicht,
stattdessen investierst du ein mehrfaches an Mühe hier deine
Desinformationen zu erarbeiten.
Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir.
MaWin schrieb:> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext> kein einziges Zeichen steht.
Das must du mal genauer Erklären. Was soll denn ausgeführt werden, was
nicht im Quelltext steht? Du meinst jetzt aber nicht so trivialkram wie
ctor und dtor, oder doch?
MaWin schrieb:> Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir.
Das sagt bereits alles. Typen wie MaWin kann/darf/sollte man nicht ernst
nehmen...
MaWin schrieb:> Es gibt sehr viel Software.> Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.> Es gibt sehr viel schlechte Software.> Viele der Software ist schlecht trotz der OO Techniken.> Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden> ist.
Was ist den das für eine Argumentationstechnik?
> Es gibt sehr viel Software.> Ein guter Teil davon ist ohne OO Techniken geschrieben.> Es gibt sehr viel schlechte Software.> Viele der Software ist schlecht trotz des Verzichts auf OO Techniken.> Die Frage wäre, ob Software 'dank' Verzicht auf OO besser oder schlechter> ist.
Hast du sonst noch Argumente? Wie wäre es damit:
You Can Write FORTRAN in any Language
MaWin schrieb:> Aber die Annahme, es wäre durch OO besser geworden, darf stark> angezweifelt werden.
Genauso wie die Annahme, dass Software ohne OO besser wäre.
MaWin schrieb:> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext> kein einziges Zeichen steht.
C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, in den
man externe Bibliotheken einbindet.
Karl schrieb:> Das gleiche Argument gilt für jeden anderen Quelltext, in den> man externe Bibliotheken einbindet.
Das ist falsch, du hast es offenbar nicht verstanden.
Wenn man eine externe Bibliothek einbindet, passiert dadurch zunächst
einmal nichts.
Damit etwas passiert, muss man die exportierten Funktionen dieser
Bibliothek aufrufen.
Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas
hinschreiben, eineen Funktionsaufruf.
Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion
durch die externe aufgerufene Funktion.
Das sieht man schon beim Ansehen des Quelltextes, und kann nachforschen,
z.B. welche Seiteneffekte sie hat.
> C++ != OO.
Kann man so verstehen daß C++ nicht die reine Lehre des OO
widerspiegelt.
Oder daß C++ sowieso keine OO Sprache wäre.
Du wirst dieses hingerotze != also interpretieren wie es dir gerade in
den Kram passt.
MaWin schrieb:> Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas> hinschreiben, eineen Funktionsaufruf.>> Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion> durch die externe aufgerufene Funktion.
Aha, und bei OO passiert einfach so etwas, ohne das man etwas
hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da
vorstellst?
MaWin schrieb:>> C++ != OO.>> Kann man so verstehen daß C++ nicht die reine Lehre des OO> widerspiegelt.>> Oder daß C++ sowieso keine OO Sprache wäre.>> Du wirst dieses hingerotze != also interpretieren wie es dir gerade in> den Kram passt
Nein, das brauche ich nicht. Ich habe dir nur gezeigt, dass deine
Argumentation nichts mit OO zutun hat sondern mit der Programmiersprache
C++. Ich könnte genauso behaupten, dass Prozedurale Programmierung
schlecht ist, weil C zu Speicherüberläufen führt. Hat bloß nichts
miteinander zu tun.
Christian M. schrieb:> ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir> erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht.> Kann mir einer verklickern, wofür das gut sein soll?
Wenn Du damit schon so Probleme hat, wird Dich funktionale
Programmierung in den Selbstmord treiben.
Karl schrieb:> Ich habe dir nur gezeigt, dass deine Argumentation nichts mit OO> zutun hat sondern mit der Programmiersprache C++.
Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt,
mit dem du behauptest alles gesagt zu haben. Na dann, shut up.
Du hast geschrieben:
MaWin schrieb:> Aber die Annahme, es wäre durch OO besser geworden, darf stark> angezweifelt werden.> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext> kein einziges Zeichen steht.
Worauf ich antwortete:
Karl schrieb:> C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, ...
Deine Argumentation mit C++ gegen OO macht immer noch keinen Sinn.
Schade das du es nicht erkennst.
Karl schrieb:>> Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion>> durch die externe aufgerufene Funktion.>> Aha, und bei OO passiert einfach so etwas, ohne das man etwas> hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da> vorstellst?
Ich würde mich über ein Beispiel freuen!
MaWin schrieb:> Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt,> mit dem du behauptest alles gesagt zu haben. Na dann, shut up.
Genau C++ ist nicht Objektorientierte Programierung oder kurz C++ != OO.
Als jemand der sich mit Programierung beschäftigt, solltest du das doch
verstehen. Eine Interpretation, wie von dir gefordert, ist bei einer
Ungleichung nicht notwendig. Hinrotzen geht im Internet auch nicht, da
wurde noch keine App für erfunden, das Verb heißt schreiben.
Streitet euch doch nicht. Das Thema kann man doch ganz sachlich
diskutieren...
MaWin schrieb:> [...], denn das WinAPI ist eine sehr gute> Implementation eines OO-Designs in normalem C. Objekte werden durch> Handles abgebildet, was self Pointer in das Datensegment des> Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B.> vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen> sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden> etc. und Fensterklassen um Unterklassen erweitern, DefWndProc.
Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems
nicht zwangsläufig objektorientiert aufgebaut sein muss, um für
Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu
sein. Dass man die Techniken dann auch sprachlich verfügbar macht
(Klassen, Vererbung) ist dann eine logische Konzequenz (und
Verbesserung).
Ein (weiterer) großer Vorteil der OOP, den ich insbesondere im
Zusammenhang mit Grafikprogrammierung sehe, ist, dass man selbst bei
dynamisch erzeugten Objekten auf Pointer verzichten kann (gilt wohl
nicht für C++). Allein das macht einem das Leben schon deutlich
einfacher, auch wenn die Probleme mit falschen Referenzen die gleichen
sind.
MaWin schrieb:> Sheeva P. schrieb:>> Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein>> OO-Schnittstelle zu einer nicht-OO-API>> Du kennst dich wohl nicht so aus,
Das stimmt. Windows, die Windows-API und die MFC habe ich mir das letze
Mal vor rund zwanzig Jahren angeschaut und bin dann schnell
davongelaufen. Sorry, das ist nicht meine Welt: in a world without walls
and fences, who needs windows and gates?
> denn das WinAPI ist eine sehr gute Implementation eines OO-Designs in> normalem C.
Ach, die einen sagen so, die anderen anders. Was OO ist und was nicht,
da halte ich mich -- wie Du meiner Konversation oben mit dem klugen
Daniel Abrecht entnehmen kannst -- streng an den Erfinder der OO, Alan
Kay. Nach diesem Maßstab ist die Windows API nicht objektorientiert,
aber wenn Du magst, kannst Du das natürlich gerne anders sehen.
> Objekte werden durch Handles abgebildet,
Wenn ich mich recht entsinne, durch Void-Pointer... How to accidentally
shoot yourself six times in the foot.
> Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet> wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine> class.
Ja, äh... und? In manchen OO-Sprachen gibt es eine Klasse Integer, in
Java zum Beispiel -- trotzdem gibt es auch in Java noch einen nativen
Datentyp int. In Python gibt es old-style Klassen, die nicht von
_builtin_.object erben, und new-style Klassen, die das tun; das fällt
einem immer dann auf, wenn man von einer Tkinter-Klasse (old-style)
erben will und die Methoden der Elternklasse nicht mit "super()"
aufrufen kann. C++ ist aber nur eine Implementierung der OO -- manche
sagen sogar, keine besonders gelungene -- und nicht der Maßstab für OO.
> Sheeva P. schrieb:>> Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als>> Beispiel für die Stärken oder Schwächen der OO zu betrachten;>> Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt.
Aus meiner Sicht zeigt die MFC nur, daß man auch mit OO beschissene APIs
designen kann. Überraschung, wer hätte das gedacht?! Und, noch
wichtiger: wer hätte das jemals bestritten? Ich jedenfalls nicht. Das
ändert aber nicht das Geringste daran, daß man mit C++ auch sehr
elegante und saubere APIs designen und implementieren kann, think Qt.
Aber wenn Du eine wirklich vollkommen verkackte API sehen willst, dann
schau Dir doch spaßeshalber einfach mal OpenSSL an. Völlig prozedural,
komplett ohne OO, und trotzdem total, absolut, und auf ganzer Linie
komplett verkackt. Verglichen damit ist sogar die MFC ein Wunderwerk
technischer Eleganz und genialer Implementierung!
Aber käme ich jetzt auf die Idee, deswegen die PP zu verdammen und das,
was Du über die OO behauptest, andersherum über die PP sagen? Natürlich
nicht. Und wenn doch, würdest Du mich zurecht genauso auslachen wie ich
das gerade umgekehrt mache.
> Allerdings sind sher viele Programme damit geschrieben, es halt also> sher wohl einen erklecklicher Anteil an der Realität der OO Software.
Aber -- und das ist der kleine, feine Unterschied -- nicht an der OO.
Deine Strategie ist es, Dir eine beschissene OO-Implementierung heraus
zu suchen, darauf herumzuhacken, wie beschissen sie ist, und das dann
auf die OO zu schieben. Ich habe einige andere OO-Implementierungen
genannt: Qt, WxWidgets, die Boost-Bibliotheken, .NjET und die STL. Mein
Argument dabei ist, daß es offensichtlich möglich ist, saubere,
verständliche OO-Designs und -Implementierungen zu entwickeln. Geh' doch
einfach mal auf dieses Argument ein, oder paßt Dir das nicht in den
Kram?
>> Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin>> ich jedenfalls nicht er.>> Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und> behauptet das wären seine Argumente.
Nein, er sagt, das seien meine Argumente. Bitte lern lesen, das würde
die Diskussion wirklich ganz enorm vereinfachen.
> Sheeva P. schrieb:>> MaWin hat dieser Interpretation jedenfalls nicht widersprochen.>> Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr
Aus meiner (natürlich subjektiven) Sicht sind meine Aussagen wahr, sonst
würde ich sie ja nicht äußern. Es ist Dir unbenommen, eine andere Sicht
zu haben und natürlich ebenso, diese zu äußern. Wenn Du sie dann auch
noch sachlich und idealerweise sogar ohne Verbalinjurien begründen
kannst, dann -- aber nur dann -- schaffst Du es vielleicht sogar, mich
von Deiner Sicht zu überzeugen. Probier es doch einfach mal. Ich bin ein
vernunftbegabter Mensch (ok, meistens jedenfalls), und gegenüber
sachlichen, schlüssigen, logisch konsistenten und begründeten Ideen
(fast) immer aufgeschlossen.
> so lange ihnen niemand widerspricht
Papperlapapp: Du hast Deine Aussage ja sogar noch einmal bekräftigt,
indem Du Dich zu der absurden Beleidigung verstiegen hast, ich sei sogar
noch schlimmer als ein fanatischer Gewalttäter.
> und ziehst Diskussionen daher so lange> durch bis dir genervt niemand mehr widerspricht. Funktionierte> vielleicht bei deiner Mama, im echten Leben eher nicht.
Bei Deiner Mama hat es jedenfalls prima geklappt. ;-)
> Es gibt sehr viel Software.
Richtig, danke für den Hinweis.
> Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.
Ebenfalls richtig, danke nochmals.
> Es gibt sehr viel schlechte Software.
Wiederum richtig, aber ebenfalls keine Überraschung.
> Viele der Software ist schlecht trotz der OO Techniken.
Und noch einmal richtig, langsam wirst Du mir unheimlich.
> Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden> ist.
Das mag Deine Frage sein. Meine erste Frage ist allerdings, ob sich
durch die OO überhaupt etwas an der Softwarequalität geändert hat, und
erst die zweite Frage ist dann für mich, ob zum Guten oder zum
Schlechten.
> Eine richtige statistische Auswertung gibt es dazu nicht.
Die dürfte auch ziemlich schwierig werden, schließlich fällt mir auf
Anhieb ein gutes Dutzend an Qualitätsmerkmalen für Software ein. Und
selbst wenn wir uns auf bestimmte Kriterien einigen könnten, bleibt da
immer noch die Frage der Gewichtung.
> Aber die Annahme, es wäre durch OO besser geworden, darf stark> angezweifelt werden.
Natürlich. Ebenso darf aber auch die Annahme bezweifelt werden, daß es
durch die OO schlechter geworden sei.
Meine ganz persönliche Meinung dazu ist allerdings, daß sich in Wahrheit
überhaupt gar nichts geändert hat. Es gibt qualitativ minderwertige OO-
und ebenso minderwertige PP- und FP-Software, es gibt hochwertige OO-
und ebenso hochwertige PP- und FP-Software.
Überraschung: Software wird immer noch von Menschen gemacht! Von
Menschen, die ihre Werkzeuge mal mehr, mal weniger gut beherrschen. Gute
Entwickler entwickeln daher gute, schlechte Entwickler schlechte
Software. Solange das der Fall ist, wird es gute und schlechte Software
geben, und daran können und werden Programmierparadigmen leider auch
nichts ändern.
> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext> kein einziges Zeichen steht.
Abgesehen davon, daß OO nicht C++ und C++ nicht OO ist -- man kann in
C++ problemlos auch prozedural und funktional entwickeln -- scheinst Du
da ein anderes C++ zu kennen als ich. Kannst Du mir bitte ein konkretes
Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.
Sheeva P. schrieb:> Kannst Du mir bitte ein konkretes> Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.
Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu
erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt,
als einsichtig gemacht.
Beaker schrieb im Beitrag #4638054:
> Mimi mimi miiiiii> Mimi mimi miiiiii
Beaker, meine Lieber! Dass ich Dich wiedergefunden habe! So eine Freude.
https://www.youtube.com/watch?v=g0b6J5O2UdI
Kupferstecher schrieb:> Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems> nicht zwangsläufig objektorientiert aufgebaut sein muss, um für> Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu> sein.
Schon wieder solche Behauptungen, die von purer Ahnungslosigkeit zeugen.
Also: Das API von Windows ist definitiv prozedural und NICHT
objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen"
sollte man sich nicht verleiten lassen, auch das API des OS als OO
anzunehmen.
Wer sich mal ein objektorientiertes OS anschauen will, sollte über
EPOC-OS bzw. Symbian-OS nachlesen. Das war - nebenbei gesagt - eine
echte Spaßbremse für Anwendungs-Programmierer, weil als
Programmiersprache einzig C++ benutzbar war, weswegen es kaum
Anwendungen für diesen Zweig der Betriebssysteme gab.
Das, was hier vermutlich gemeint worden ist, ist nicht
"objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied!
W.S.
W.S. schrieb:> Also: Das API von Windows ist definitiv prozedural und _NICHT_> objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen"> sollte man sich nicht verleiten lassen, auch das API des OS als OO> anzunehmen.>> Das, was hier vermutlich gemeint worden ist, ist nicht> "objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied!
Das, was hier gemeint worden ist, ist objektorientiert!
- Die Zugriffe über Handles stellen die Objektreferezen dar.
- Allein das Arbeiten mit Structs/Records ist schon eine Vorstufe zur
Objektorientierung.
- Die Kapselung der Funktionen zum Betriebssystem.
Das sind alles Konzepte aus der Objektorientierung. Oder anders rum, die
Objektorientierung benutzt genau diese Konzepte. Die OOP ist ja nicht
zufällig entstanden.
Karl schrieb:> Sheeva P. schrieb:>> Kannst Du mir bitte ein konkretes>> Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.>> Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu> erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt,> als einsichtig gemacht.
Willst Du wohl bitte aufhören, weiteres Öl ins Feuer zu gießen!? Danke.
Meiner Meinung nach haben sich die Programmiersprachen immer in
bestimmten Kontexten entwickelt.
OOP hat sich mit der Einführung der graphischen Benutzeroberflächen
entwickelt, dort kann man die "Objekte" ja auch richtig sehen. Es macht
ziemlich viel Sinn, die Eigenschaften von graphischen Elementen zu
vererben und diese zu erweitern. Eine "reichhaltige" graphische
Oberfläche in Assembler zu programmieren, wäre wohl ziemlich mühselig.
Dass man OOP Konzepte später für alles Mögliche wie Treiber oder
ähnliches verwenden kann, betrachte ich eher als einen Seiteneffekt.
Lisp dagegen hat sich im Umfeld der künstlichen Intelligenz Forschung
entwickelt und ist für deren Probleme eher geeignet.
chris_ schrieb:> Hier noch was passendes:> http://www.heise.de/developer/artikel/Vererbung-fuer-Objekte-nuetzlich-fuer-Werte-gefaehrlich-3254433.html
Guter Artikel!
Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der
leider die guten Beiträge in dem von einigen wenigen Ahnungslosen
verursachten Dauerlärm untergehen.
Der Artikel zeigt anhand eines Beispiels, wie OOP falsch angewendet
werden kann bzw. wo die Grenzen gewisser Konzepte (in diesem Fall der
Implementierungsvererbung) liegen.
Man kann jetzt natürlich wie ein Rohrspatz über OOP schelten, weil sie
nicht idiotensicher ist. Aber das wäre so, als lehne man Autos ab, weil
beim Autofahren mehr Fehler passieren können als beim Zufußgehen.
Was die Implementierungsvererbung betrifft, ist sich ja sogar James
Gosling, der Entwickler von Java, nicht mehr ganz sicher, ob das ein
gutes Konzept ist:
http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html
1
... someone asked him [James Gosling]: "If you could do Java over again,
2
what would you change?" "I'd leave out classes," he replied. ... he
3
explained that the real problem wasn't classes per se, but rather
4
implementation inheritance (the extends relationship). Interface
5
inheritance (the implements relationship) is preferable. You should
> Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der> leider die guten Beiträge in dem von einigen wenigen Ahnungslosen> verursachten Dauerlärm untergehen.
Unterstrichen Punkt
OOP heisst Objekt-Orientierte-Programmierung und nicht
Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit
dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht
vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich).
Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark.
Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden.
Problematisch wird bei O-Orgien-Programmierung die Klassenstruktur.
Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur
noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von
Komposition benutzt wird.
Sieht man sich OO Programme im Grossen an, sieht es oft aus wie
Spaghetti.
Ein solcher Code ist nur sehr schwer zu pflegen. Die Verheissungen der
Wiederverwendbarkeit haben sich geradezu als Fluch erwiesen. Das Problem
liegt nicht in der Wiederverwendung selbst sondern in unüberlegter
Verwendung von Klassen aus fremdem Kontexten.
Es ist unerlässlich, Bereiche abzugrenzen, geradezu Feuerwände
einzuziehen, die es nicht erlauben, Klassen aus anderen Bereichen
unbesehen zu verwenden.
In diesem Sinne wird Software von Architekten erstellt. Den Code
erstellen Programmier-Maurer. Einfamilienhäuser können Maurer (Meister)
erstellen, Hochhäuser Architekten.
Beispiele: die Elbphilharmonie und der Kölner Dom ;-)
Hier kann ich diese Frage stellen:
Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und
Eagle, Hardware entwickeln lassen?
Heiner K. schrieb:> Hier kann ich diese Frage stellen:
Ja, gewissermaßen ...
> Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und> Eagle, Hardware entwickeln lassen?
... denn umgekehrt sehen das viele hier als selbstverständlich an. ;-)
Christian M. schrieb:> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die> Zahl das Objekt sein...?!>> Intern wird es ja eh prozedural verarbeitet.>> Bin ich zu alt?
Nein.
Einen String kann man gut als Objekt oder Klasse verstehen. Er wird mit
Methoden manipuliert, dabei ändert sich sein Inhalt, Zustand (meistens).
Richtig Sinn macht es erst, wenn ein Bild im Browser betrachtet wird. Es
kann verschoben, verkleinert, gedreht usw. werden. UND man kann leicht
ein Bild mit Rahmen daraus machen.
Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit.
Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings
auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist
man gezwungen, daraus eine Klasse zu machen.
Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung:
Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu.
OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus.
Das kann schon verwirren.
Ich empfehle sich zunächst mit dem Konzept von OOP vertraut zu machen.
Leider geht das nicht mal eben auf einer Seite.
Zunächst würde ich darauf in Javascript zu verzichten. Später finden
sich dann sinnvolle Anwendungen.
Mir sind die häufigen Abfragen nach dem Browser ein Dorn im Auge.
Das ist ein typischer Fall, wo Polymorphismen prozedural aufgelöst
werden.
Anscheinend ist nicht leicht, OOP sinnvoll anzuwenden.
Christian, wenn Du später diese Aussage verstehst, solltest Du mit OO
anfangen.
Heiner K. schrieb:> Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit.> Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings> auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist> man gezwungen, daraus eine Klasse zu machen.
Es wurde ja weiter oben in diesem Thread schon geschrieben, dass das
Math-Objekt ein Weg ist, mehrere Symbole (Funktionen und Konstanten) in
einem Namensraum zusammenzufassen. In C++ gibt es zu diesem Zweck
Namespaces, in Java und Python Module.
Da es in Javascript weder Namespaces noch Module gibt, könnte man auf
die Idee kommen, stattdessen eine Klasse mit lauter static-Elementen
anzulegen, die im Wesentlichen denselben Zweck erfüllt.
Da es in Javascript aber auch keine Klassen gibt, wird dort stattdessen
ein Objekt verwendet.
> Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung:> Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu.> OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus.> Das kann schon verwirren.
Die (nichtexistenten) Klassen in Javascript werden durch ihren
Konstruktor repräsentiert, der seinerseits natürlich eine Funktion ist.
Das ist an sich nicht schlimm, aber für Leute, die von Java, C++ oder
Delphi kommen, ungewohnt. Um diesen Leuten entgegenzukommen, gibt es in
Javascript inzwischen eine syntaktisch an Java und C++ angelehnte
Klassendeklaration der Form
1
class MyClass {
2
constructor(x) { ... }
3
methode1(x, y) { ... }
4
...
5
}
Echte Klassen gibt es deswegen aber immer noch nicht, denn diese
Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist
MyClass nach wie vor eine Funktion, was man leicht mit
1
typeof(MyClass) ——> function
feststellen kann.
Heiner K. schrieb:> Zunächst würde ich darauf in Javascript zu verzichten.
Das kommt darauf an: Man lernt ja OOP meist nicht als reine Philosophie
losgelöst von jeglicher Anwendung, sondern um danach in einer konkreten
Sprache programmieren zu können. Das kann Java oder C++ sein für
PC-Anwendungen oder eben Javascript, falls das Interesse eher in
Client-Side-Internet-Anwendungen liegt. IMHO lernt man mit Java oder C++
nicht "besser" OOP als in Javascript.
Nur wenn man wirklich tiefer in die "Philosophie" der Objektorientierung
vorstoßen möchte, sollte man sich eher mit einer reinen OOP-Sprache, wie
bspw. Ruby oder Scala beschäftigen (Smalltalk lasse ich mal auf Grund
des hohen Alters außen vor). Diese Sprachen zwingen einen regelrecht,
alles in Klassen zu packen, was einem auch eine gute Chance gibt, die
Grenzen der OOP zu erkennen.
Yalu X. schrieb:> Echte Klassen gibt es deswegen aber immer noch nicht, denn diese> Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist> MyClass nach wie vor eine Funktion, was man leicht mit>> typeof(MyClass) ——> function>> feststellen kann.
Das dachte ich lange auch. Dann musste ich feststellen, das damit
auchnoch eine Überprüfung eingebaut wurde, ob man es mit new aufgerufen
hat. Dass muss sein, weil super eingefürt wurde, welches kurzform für
new.target.prototype.constructor ist, wobei new.target nur gesetzt ist,
wenn mit new aufgerufen. Ich würde gerne solche Dinge tun:
ProxifyEarly(MyClass2,{});// TypeError: class constructors must be invoked with |new|
Man hätte new.target und super auch anders auflösen können, aber so wie
es jetzt ist, ist es ein unlösbares Problem. Dabei hätte ich so tolle
Anwendungsmöglichkeiten dafür gehabt, wenn ich schon das this im
constructor vor dessen aufruf in einen Proxy hätte packen können...
Heiner K. schrieb:> OOP heisst Objekt-Orientierte-Programmierung und nicht> Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit> dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht> vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich).
Vollkommen richtig.
Leider wird in vielen Lehrbüchern zu OOP-Sprachen die Vererbung als
die große Errungenschaft herausgestellt, weil es die meisten anderen
Konzepte wie Kapselung und verschiedene Formen der Polymorphie auch in
Nicht-OOP-Sprachen gibt. So entsteht beim Leser der Eindruck, ein
OO-Design sei nur dann gut, wenn möglichst viele Klassen zueinander in
einer Vererbungsbeziehung stehen.
Umgekehrt: Schafft der Leser es nicht, die einzelnen Klassen seines
Programms voneinander erben zu lassen oder gemeinsame Basisklassen zu
finden, weil die Problemstellung einfach keinen Anlass dafür gibt, hat
er ein schlechtes Gewissen und denkt, er hätte die OOP noch nicht
verstanden.
> Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark.> Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden.
Ebenfalls Zustimmung.
Aber gerade, weil die Kapselung nicht OOP-spezifisch ist, wird sie in
der OOP-Literatur zwar behandelt, aber im Vergleich zur Vererbung nicht
ganz so sehr in den Vordergrund gestellt. Da die Kapselung ohne viel
Nachdenken sowieso leicht zu bewerkstelligen ist, konzentriert der
Lernende seine geballte Kreativität auf eine möglichst komplexe
Klassenhierarchie :-)
> Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur> noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von> Komposition benutzt wird.
Solche Dinge wie
- wann man Vererbung einsetzt und wann besser Komposition oder gar
nichts von beidem,
- wann man eine Funktion als instanzbezogene Memberfunktion definiert
und wann besser als instanzunabhängige Klassenfunktion oder (in C++)
als freie Funktion, und
- falls man sich für eine instanzbezogene Memberfunktion entscheidet, in
welche Klasse man sie packt (es gibt genügend Beispiele, wo das
absolut nicht trivial ist),
lernt man erst in der Fortgeschrittenenliteratur, die aber kaum einer
liest, weil man ja mit dem Anfängerbuch bereits alle Sprachelemente
kennengelernt hat.
Hier ist noch ein Zitat vom C++-Entwickler Stroustrup zu diesem Thema:
1
Please note that object-oriented programming is not a panacea. "OOP"
2
does not simply mean "good" - if there are no inherent hierarchical
3
relationships among the fundamental concepts in your problem then no
4
amount of hierarchy and virtual functions will improve your code. The
5
strength of OOP is that there are many problems that can be usefully
6
expressed using class hierarchies - the main weakness of OOP is that too
7
many people try to force too many problems into a hierarchical mould.
8
Not every program should be object-oriented. As alternatives, consider
9
plain classes, generic programming, and free-standing functions (as in
10
math, C, and Fortran).
(Aus: http://www.stroustrup.com/bs_faq.html)
Genau die Software von Leuten, die mit roher Gewalt "too many problems
into a hierarchical mould" pressen, liefern das Futter für die Anti-OOP-
Schreihälse hier im Thread. Statt sich von diesen Negativbeispielen,
(die es übrigens für jedes Programmierparadigma gibt) abschrecken zu
lassen, sollte man aus ihnen lernen und versuchen, selber die gleichen
Fehler nicht zu machen.
Schlussbemerkung:
Ich bin selber auch kein riesiger Fan der OOP und setze sie nur dort
ein, wo ich die damit verbundenen Vorteile in Bezug auf eine bestimmte
Anwendung schon von vornherein deutlich erkennen kann. Mich nerven aber
Leute, die solche Dinge lautstark und in unzähligen Wiederholungen als
den größten Mist der Menschheitsgschichte abstempeln, ohne sich zuvor
mit der erforderlichen Intensität damit auseinandergesetzt zu haben.
Dann muss ich jetzt mal ganz blöd fragen:
Ich programmiere ausschließlich OOP, da ich nie was anderes
kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#,
Java, Python und JavaScript (bzw. TypeScript), je nach Projekt.
Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.
Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch
rein prozedurale Programmierung effizienter zu implementieren bzw.
wartungsfreundlicher sind?
Phony schrieb:> Dann muss ich jetzt mal ganz blöd fragen:>> Ich programmiere ausschließlich OOP, da ich nie was anderes> kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#,> Java, Python und JavaScript (bzw. TypeScript), je nach Projekt.>> Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.> Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch> rein prozedurale Programmierung effizienter zu implementieren bzw.> wartungsfreundlicher sind?
Stringverarbeitung zB ist in purem C wesentlich effizienter und
schneller. Natürlich muss man dazu verstehen, was ein Pointer ist. Aber
in der Zeit, die man damit verbringt, eine Stringklasse mit all ihren
Methoden zu studieren, kann man sich auch damit beschäftigen.
Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein
Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren
gegangen ist. Wer sich mit CPUs und Assembler auskennt, kann anhand des
Quelltextes in etwa voraussehen, was im Prozessor geschehen wird. Keine
andere Hochsprache ist da so konsistent.
Die wichtigsten Vorteile der OOP, zusammengehörige Daten zusammen zu
halten und mit einer einzigen Referenz darauf zugreifen zu können, sind
schon mit der Verwendung von structs gegeben und selbst mit Assembler
möglich.
OOP ist keine Alternative zur PP, sondern eine andere Ebene. Als
Autofahrer muss man nicht unbedingt wissen, was unter der Motorhaube
geschieht, aber deshalb sind Automechaniker nicht überflüssig, im
Gegenteil.
Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie
beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit
simpler PP, nur der Rahmen ist OOP-spezifisch.
Assembler ist auch nur der objektorientierte Rahmen von
Mikrocodeanweisungen im Prozessor, man steckt die einzelnen
Assemblerbefehle zusammen wie bei Lego.
D. I. schrieb:> Assembler ist auch nur der objektorientierte Rahmen von> Mikrocodeanweisungen im Prozessor, man steckt die einzelnen> Assemblerbefehle zusammen wie bei Lego.
Bis auf das 'objektorientierte' stimme ich dir zu.
Und so wie der Microcode bei den Prozessorentwicklern nicht veraltet
ist, weil nur wenige ihn kennen, ist auch die prozedurale Programmierung
nicht veraltet, sondern nur eine andere Ebene.
Dass wir auf den Schultern von Riesen stehen, ist kein Grund auf Sie
herabzublicken.
Jobst Q. schrieb:> Stringverarbeitung zB ist in purem C wesentlich effizienter und> schneller.
Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen
Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge
des Strings bekannt ist, und dass die Strings nicht null-terminiert
sind.
Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).
Jobst Q. schrieb:> Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie> beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit> simpler PP, nur der Rahmen ist OOP-spezifisch.
Das ist definitiv Quatsch. Rein inhaltlich gibt es überhaupt keinen
Unterschied. Lediglich die Strukturierung ist eine andere.
Jobst Q. schrieb:> Stringverarbeitung zB ist in purem C wesentlich effizienter und> schneller.
Stringverarbeitung ist nun aber gerade etwas, das man nicht in großem
Rahmen komplett in C machen will (ich zumindest nicht). Es ist einfach
zu umständlich und fehlerträchtig.
> Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein> Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren> gegangen ist.
Hauptgrund wird eher sein, dass Linus Torvalds C++ nicht mag. Seine
Aussagen dazu lassen vermuten, dass er sich aber auch nicht wirklich
damit beschäftigt hat.
Übrigens benutzt auch der Linux-Kernel OO-Konzepte (z.B. Polymorphie),
nur dass sie eben nicht direkt über in der Sprache eingebaute Mittel
verwendet werden, sondern zu Fuß implementiert sind.
Ähm, der Linux Kernel den ich kenne ist aber so etwas von
objektorientiert!
Auch wenn's zum Großteil c ist...
Im Übrigen ist ein Betriebssystem ein sehr, sehr gutes Beispiel bei dem
Objektorientierung sinnvoll ist.
Bestes Beispiel: Prozesse
da hat jeder seinen Stack, sein Register-File, einen Pointer zum
Entry-Point... und natürlich Funktionen wie Run/Stop/Suspend.
Ohne OOP hätte man jetzt unzählige einzelne (globale?) Arrays für alles.
Mit OOP ist das alles eine Klasse oder zumindest ein struct.
Da ist keine Vererbung im Spiel oder so aber es zeigt wie viel
strukturierter das werden kann (also 42 Arrays wo man mit dem richtigen
Index reinfingern muss vs. ein Array von Objekten).
Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das
als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für
Dateien (open, close, read, write) sind gleich - was sie tun aber nicht.
Unser Moby ist leider... Moby... seine These, dass er in asm kleineren
code erzeugt als ein ein c(++) compiler hat sich ja schon einmal als
falsch herausgestellt.
Ich schreibe viel prozedural und viel mehr objektorientiert... die
Grenze ziehe ich unscharf dort wo zuviele unterschiedliche Objekte mit
einander koexistieren müssen. Oft genug gibts es aber kein
(definierbares) Objekt...
73
Phony schrieb:> Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.
Hast Du in einem Deiner Programme Klassen geschrieben bei denen die
getter und setter transparent waren (d.h. den Wert direkt verwendet);
und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du
da auf OOP verzichtet.
Dumdi D. schrieb:> Hast Du in einem Deiner Programme Klassen geschrieben bei denen die> getter und setter transparent waren (d.h. den Wert direkt verwendet);> und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du> da auf OOP verzichtet.
OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite
oder sonst was ;-)
OOP ist ein Architekturkonzept. Natürlich ist auch in jedem OOP
basierten projekt sehr viel prozeduraler Code enthalten...
Boris P. schrieb:> OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite> oder sonst was ;-)
Wäre aber auch mal eine Herausforderung. Ich versuch's mal:
Wir verlieren uns in Details. Welche Sprache, OOP, PP ist die beste um
Programmileinileinschen zu schreiben.
In einem anderen Bild: Maurer unterhalten sich darüber, welche
Mauertechnik die beste ist.
OO macht aber Sinn, wenn wir es uns aus der Sicht eines Architekten
ansehen.
Der Linux-Kernel zeigt, dass es auch ohne OOP geht.
Ich kenne andere Systeme, mit Millionen LOC fast alle ohne OO-Sprache.
Einige Systeme sind sehr wohl objektorientiert strukturiert.
Die Voraussetzung für den Erfolg solcher Systeme sind saubere
Strukturen. Damit sind Module und deren Abhängigkeiten gemeint. Die
Module haben klare Interfaces. Die Implementation ist gekapselt. Wer was
verwenden darf ist klar geregelt. Wenn ich mir diese Module ansehe gibt
es zwei Klassen:
Bibliotheken wie Mathe, die Funktionen anbieten, die Elemente bekommen
und Ergebnis-Elemente liefern. Der Zeitpunkt des Aufrufs und deren
Reihenfolge haben keinen Einfluss auf das Ergebnis.
Module mit Zustand. Hier hat der Zeitpunkt des Aufrufs und deren
Reihenfolge einen Einfluss auf das Ergebnis.
Module fassen das zusammen, was zusammengehört.
Einige Herangehensweisen ignorieren Module mit Zustand. Sie beschreiben
an einer Stelle die Elemente, die Daten und an einer anderen Stelle wird
beschrieben wie sie verarbeitet werden. Diese Sicht fördert
unübersichtliche Strukturen.
Die wichtigste Idee hinter OO ist, Daten und die bereitgestellten
Funktionen zusammenzufassen.
Damit ein komplexes System übersichtlich bleibt, werden von einem Modul
nur die essentiellen Funktionen bereitgestellt. Wie sie implementiert
sind,
ist im Modul verborgen. Verborgen in dem Sinne, das der Anwender des
Moduls die Implementierung nicht sehen braucht, sie sich jedoch ansehen
darf. Nur eines darf er nicht, sich darauf verlassen, dass die
Implementation sich nicht ändert. Weil der Anwender die Implementierung
nicht sehen braucht, muss das Verhalten des Moduls klar im Interface
beschrieben sein.
Module in grossen Systemen sind riesig, sie enthalten wiederum Module
usw.
Es ergibt sich ein eine hierarchische Architektur.
Module werden oft in verschiedenen Kontexten benötigt. Da ist es
wünschenswert, sie parametrisieren zu können. Man kann generische Module
erstellen, die sogar andere Module als Parameter haben können.
Eigentlich geht es darum, Module zu abstrahieren und allgemeiner zu
formulieren.
Der Sinn des Ganzen ist Wiederverwendbarkeit.
Währen wir oben Module als Objekte mit Zustand, Interface und Kapselung
gesprochen haben. Haben wir es jetzt mit Klassen zu tun. Aber das ist
nicht die ganze Welt. Die oben erwähnten generischen Module sind eine
andere Sicht, die Möglichkeiten bietet von denen manche OO-Programmierer
nicht einmal träumen.
Um es noch einmal klarzustellen, die meisten (grossen) Module sind
Objekte und nur wenige Klassen und noch weniger generisch.
Diese Strukturen kann man auch mit Nicht-OO-Sprachen aufbauen. Es bedarf
klarer Regeln und Vorgaben.
Die wichtigste Regel besagt: "Du darfst nicht verwenden was Du willst
sondern nur was Du verwenden darfst."
Die OO-Sprachen unterstützen diese Regel durch ihre Kapselung. Leider
nur im Kleinen. Dafür stellen sie mächtige Konzepte wie Polymorphismen
und Vererbung bereit. Erklärt wird das Ganze an Objektileinileinchen.
Und jeder bastelt sich seine Klassen zurecht. Interfaces werden
überfrachtet und vor allem nicht beschrieben. Man kann sich ja den Code
ansehen.
Fatal wirkt sich dann aus, dass dann jeder eine Klasse, die ihm geeignet
scheint in sein Programm einbaut. Wir wundern uns dann, wie es passieren
kann, wenn jemand die Farbe in einem Fenster ändert, an anderen Stellen
auch alles grün wird.
Die freie Verwendbarkeit von Modulen ist hier das Problem ebenso das
Problem wie wohldurchdachte und dokumentierte Interfaces.
Auf der anderen Seite werden natürlich breit oder sogar global
verwendbare Module benötigt. Solche Module sollten nur von Könnern
erstellt werden.
Fazit:
Objektorientierung im Keinen ist ein mächtiges schönes Werkzeug, das
leider oft nicht einmal im Kleinen beherrscht wird. Nicht die Sprache,
sondern das Konzept und vor allen seine Implikationen.
Objektorientierung im Grossen ist eine essentielle Sichtweise, die
leider durch die Werkzeuge des Keinen nicht beherrschbar sind.
Hochhäuser aus der Sicht eines Maurers.
Wie sagte Tom DeMarco: A fool with a tool ...
P.S.
Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien). Was sind
denn die Treiber? Die Architektur ist vor allem sehr gut strukturiert.
Seine graue Eminenz Linus wacht darüber mit Argusaugen.
Hans W. schrieb:> Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das> als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für> Dateien (open, close, read, write) sind gleich - was sie tun aber nicht.
Nicht nur Dateisysteme, sondern auch die ganzen Gerätetreiber. Die sind
schließlich auch alle als virtuelle Dateien implementiert, die diese
ganzen Syscalls haben. Ein Linux-Treiber muss dazu eine Struktur mit
Funktionspointern auf seine Implementierung dieser Syscalls anlegen und
dem Kernel übergeben. Beim Zugriff auf das Device wird dann über diese
Pointer die richtige Funktion gefunden und ausgeführt. Das ist genau das
gleiche wie eine vtable, nur eben zu Fuß.
Heiner K. schrieb:> Der Linux-Kernel zeigt, dass es auch ohne OOP geht. [...]> Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien).
Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne
OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch
besondere sprachliche Mittel realisiert werden kann.
Karl Käfer schrieb:> Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne> OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch> besondere sprachliche Mittel realisiert werden kann.
Zu Erstens:
JA, nein.
Es geht ohne OOP. Objekte sind immanente Elemente eines Systems. Sie zu
erkennen ist ist die Leistung und sie bewusst anzuwenden ist OO. Das
könnte man als (P) Programmierung bezeichnen aber nicht im herkömmlichen
Sinne, Code zu produzieren.
Zu Zweitens:
JA
Genau darum geht der Streit in diesem Thread, kann man Objekt ORIENTIERT
programmieren ohne eine OO-Sprache im engeren Sinne zu verwenden.
Die Denkweise in Objekten liegt uns näher, als wir uns bewusst machen.
Der Gedanke des Zusammenfassens und Kapselns von Daten, Zustand und
Funktionen geht in dem Geplärre von Vererbung und Polymorphismus ebenso
unter wie das Konzept der Komposition.
Boris P. schrieb:> Jobst Q. schrieb:>> Stringverarbeitung zB ist in purem C wesentlich effizienter und>> schneller.>> Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen> Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge> des Strings bekannt ist, und dass die Strings nicht null-terminiert> sind.> Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).
Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder
Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit
strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden
könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen
gewaltigen Overhead verursacht. Sie kann von Vorteil sein, wenn ein
String nur einmal eingelesen und dann nur abgefragt wird. Das kann man
aber nicht Stringverarbeitung nennen, sondern höchstens
Stringverwendung.
In purem C ist ein String einfach nur eine Adresse, alles andere ergibt
sich daraus. Der Prozessor muss nichts überfüssiges machen, die
Stringverarbeitung ist schnellstmöglich. Wenn für jede neue
Stringvariable Speicher alloziiert und Strukturen aufgebaut und gefüllt
werden müssen, damit es ein vollwertiges Objekt ist, braucht das seine
Zeit und Resourcen. Wenn bei der Programmierung von Compilern
Stringobjekte statt char* verwendet würden, wären viele Kaffepausen
gesichert.
Ich bin nicht prinzipiell gegen OOP, für große Objekte bringt sie viele
Vorteile, aber für Strings ist sie überflüssig wie ein Kropf. Das schöne
an C++ ist, dass man die Möglichkeiten von OOP nutzen kann, aber nicht
muss.
Jobst Q. schrieb:> Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder> Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit> strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden> könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen> gewaltigen Overhead verursacht.
Schön, wie man ein negativ besetztes Wort mit etwas zusammenbringen
kann, mit dem es gar nichts zu tun hat...
Warum sollte bei einer Zuweisung ala a=b die Länge neu ermittelt werden
müssen? Und wozu sollte man strlen brauchen, wenn die Länge der
Ausgangsstrings bekannt ist und die Operationen darauf deterministisch
sind?
Jobst Q. schrieb:>> Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).>> Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder> Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit> strlen() oder ähnlichem.
Nein, fast immer genügt eine einzelne Addition bzw. Subtraktion. Der
zusätzliche Aufwand ist also im Gesamtkontext irrelevant.
> die genau deshalb einen gewaltigen Overhead verursacht.> Wenn bei der Programmierung von Compilern Stringobjekte statt char*> verwendet würden, wären viele Kaffepausen gesichert.
War starker Unterdruck nötig, sich diesen Unsinn aus den Fingern zu
saugen? Und nein, ich bin kein Fanboy, die Stringverarbeitung in C++ ist
nichts Halbes und nichts Ganzes.
Jobst Q. schrieb:> In purem C ist ein String einfach nur eine Adresse, alles andere ergibt> sich daraus. Der Prozessor muss nichts überfüssiges machen, die> Stringverarbeitung ist schnellstmöglich.
Nein, i.Allg. ist das nicht der Fall.
Bei den meisten String-Operationen ist es von Vorteil, wenn man die
Länge vorab kennt. Ein paar Beispiele:
Länge bestimmen:
Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei
nullterminierten Strings müssen die Zeichen gezählt werden.
Kopieren:
Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes
einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar
mitkopiert werden, das ist aber nur ein einzelner Integer-Wert.
Anhängen eines Strings s2 an einen anderen String s1:
Man weiß sofort, an welche Stelle im Buffer von s1 man s2 kopieren muss.
Die Länge von s1 muss zwar aktualisiert werden, das ist aber nur eine
einfache Addition.
Bereichsprüfung des Index:
Bei nullterminierten String muss vor der eigentlichen Prüfung die Länge
durch Abzählen bestimmt werden.
Vorteile (mit Einschränkungen) von nullterminierten Strings:
- Sie belegen ein paar Bytes weniger Speicher. Dafür darf aber das
Zeichen NUL ('\0') nicht im String vorkommen.
- Auf manchen Prozessorarchitekturen geht das Iterieren über alle
Zeichen des Strings etwas schneller. Es gibt aber auch Architektueren,
wo es genau anders herum ist. Außerdem ist bei der Iteration über
nullterminierte Strings kein Loop-Unrolling möglich.
Der Grund, warum C von Hause aus nur die nullterminierten Strings hat,
liegt darin, dass die Anzahl der vordefinierten Datentypen klein halten
wollte. Ein String mit Längenangabe wäre ein spezielles Struct, das aber
ein Anwendungsprogrammierer oder ein Bibliotheksschreiber auch selber
nach eigenem Gutdünken definieren kann.
C ist die einzige mir bekannte Programmiersprache mit nullterminierten
Strings. Alle anderen verwenden entweder
- Zeichenarrays mit zusätzlicher Längenangabe,
- verkettete Listen von Zeichen oder
- verkettete Zeichenarrays mit Längenangabe.
Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP
nichts, aber auch gar nichts zu tun hat :)
Yalu X. schrieb:> Jobst Q. schrieb:>> In purem C ist ein String einfach nur eine Adresse, alles andere ergibt>> sich daraus. Der Prozessor muss nichts überfüssiges machen, die>> Stringverarbeitung ist schnellstmöglich.>> Nein, i.Allg. ist das nicht der Fall.>> Bei den meisten String-Operationen ist es von Vorteil, wenn man die> Länge vorab kennt. Ein paar Beispiele:>> Länge bestimmen:
Ja, es ist beim Bestimmen der Länge von Vorteil, wenn man sie schon
kennt.
Welch tiefe Weisheit, auch Tautologie genannt.
Bei den meisten String-Operationen, die ich kenne und verwende, spielt
die Länge keine Rolle.
> Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei> nullterminierten Strings müssen die Zeichen gezählt werden.
Müssen sie nicht, wenn die Stringfunktionen die Adresse der Null am Ende
zurückgeben. Die Funktion strcpy tut das dummerweise nicht, sie gibt den
Anfang zurück, den man eh schon kennt. Aber da gibt es auch die Funktion
stpcpy die genau das tut, was sie soll.
Beispiel für die Längenbestimmung beim Aneinanderhängen von zwei
Strings:
l=stpcpy(stpcpy(buf,s1),s2)- buf;
Weder die Länge von s1 noch von s2 muss vorher bekannt sein und doch
bekommt man die Gesamtlänge fast gratis.
>> Kopieren:> Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes> einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar> mitkopiert werden, das ist aber nur ein einzelner Integer-Wert.
Strings sind aber selten große Blöcke, deshalb fällt das kaum ins
Gewicht.
Für Blöcke gibt es die mem-Funktionen. Jeden String als Block zu
definieren, halte ich nicht für sinnvoll.
Ein großer Vorteil der Null-terminierten Strings ist aber, dass man viel
seltener kopieren muss. Einen längeren String, zB eine Zeile aus einer
Datei in einem Puffer, kann man an Ort und Stelle in mehrere benötigte
Teilstrings zerlegen, indem man die Trennzeichen durch eine Null
ersetzt. Das geht mit keinem anderen Stringmodell.
Ein anderer großer Vorteil ist sehr simple Verkürzen der Strings. ZB das
Überspringen von Leerzeichen und tabs:
while(*s==' '||*s=='\t')s++;
Wie man eine solche Aufgabe mit Objektstrings löst, überlasse ich
anderen.
Deren Methoden erinnern mich stark an den Murks der Stringbehandlung in
GWBasic, mit dem ich mich rumquälte, bevor ich C entdeckte.
> Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP> nichts, aber auch gar nichts zu tun hat :)
Sehe ich nicht so. Strings sind ein gutes Beispiel, wie OOP-Dogmen
einfaches kompliziert und ineffektiv machen können.
wow der Unterschied...
Sollte das etwa gar nichts mit OOP zu tun haben?
Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte,
wie toll Stringverarbeitung mit C geht. Ich kann mir auch nicht
vorstellen, dass du dir das selber erzählst.
nfet schrieb:> Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte,> wie toll Stringverarbeitung mit C geht.
Stringverarbeitung mit C geht jedenfalls - sie wird millionenfach
durchgeführt. Ob sie "toll" ist, sei dahingestellt. Dazu müsste man erst
einmal definieren, was man unter toller Stringverarbeitung versteht.
"Toll" kann ja auch verrückt heißen... ;-)
Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine
einfache Iteration über die Zeichen eines Strings in C++ sein kann.
Mit C-Strings würde man einfach schreiben:
1
for(char*it=s;*it;it++){
Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in
C:
1
for(autoc:s){
Durch die auto-Deklaration funktioniert das sogar gleichermaßen für
string- wie für wstring-Typen.
nfet schrieb:> Sollte das etwa gar nichts mit OOP zu tun haben?
Mein diesbezüglicher Kommentar von oben bezog sich auf die interne
Repräsentation von Strings. Das von Jobst angeprangerte Mitführen der
Länge in einem String-Datentyp ist keine OOP-spezifische Eigenschaft.
Yalu X. schrieb:> for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) {>> Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine> einfache Iteration über die Zeichen eines Strings in C++ sein kann.>> Mit C-Strings würde man einfach schreiben:> for(char *it = s; *it; it++) {
Was ist jetzt an dem ersten komplizierter als am zweiten? Der Typenname
ist etwas länger, aber das war's dann auch.
> Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in> C:> for (auto c: s) {
Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere
Schreibweise. Und es macht nicht mal das gleiche. Im ersten Fall habe
ich schließelich einen Iterator auf die Stelle, wo das Zeichen steht,
den ich in weiteren Funktionen auf den String anwenden kann, während ich
bei deiner Variante nur das Zeichen selbst habe. Gut, das überspringen
von Zeichen in der Schleife könnte man damit auch machen.
Wobei man auto natürlich auch für den Iterator verwenden kann:
1
for(autoit=s.begin();it!=s.end();++it){
Das tolle an Iteratoren ist eben auch, dass die eigentliche
Datenstruktur dich gar nicht interessieren muss, während die
Pointer-Variante aus c ausschließlich mit Arrays funktioniert. Dann
klappt das z.B. auch bei einer Stringklasse, die die Daten intern als
verkettete Liste aus Arrays hält, wie man das bei Texteditoren
üblicherweise macht. Die arbeiten ja in der Regel mit sehr langen
Zeichenketten, bei denen man ständig mittendrin was einfügen muss.
Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine Frage
sein)
>for(char *it = s; *it; it++)
*it = s setzt den als itterator benutzten Zeiger auf Element 0 vom
Zielstring
>> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt? Hat das
Terminierungszeichen automatisch den Wert, dass es als Abbruchbedingung dient?
it++ => inkrement des itterators
Beaker schrieb:> Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine> Frage sein)>>for(char *it = s; *it; it++)> *it = s setzt den als itterator benutzten Zeiger auf Element 0 vom> Zielstring>>> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt?
Bedingung ist "wenn *it wahr".
Beim Terminierungszeichen '\0' (0) ist *it false (also Abbruch), sonst
true (weiter).
> Hat das Terminierungszeichen automatisch den Wert, dass es als> Abbruchbedingung dient?
Ja; weil 0 in C (als bool) als false interpretiert wird, alle anderen
Werte als true. Wäre für C-Strings als Terminierungszeichen nicht 0,
sondern z.B. 255 definiert, würde es also so nicht funktionieren (es sei
denn, dieser Wert würde dann als false interpretiert werden und die
anderen als true).
Rolf M. schrieb:> ...> Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere> Schreibweise.
Und das ist nicht "einfacher"? ;-)
> Und es macht nicht mal das gleiche.
Dann eben:
nfet schrieb:> Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte,> wie toll Stringverarbeitung mit C geht.
Du Ärmster! Soll ich dir jetzt ein Bild von mir schicken ?
Jobst Q. schrieb:> while(*s==' '||*s=='\t')s++;
Wie sehts mit
s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf
den ersten Blick, was passieren soll.
Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst,
auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in
einer Funktion sein. Alles andere ist schlechter Stil und das hat mit
OOP oder PP bekanntlich nichts zu tun.
nicht"Gast" schrieb:> Jobst Q. schrieb:>> while(*s==' '||*s=='\t')s++;>> Wie sehts mit>> s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf> den ersten Blick, was passieren soll.
Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek
vorhanden ist?
Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich
geschieht, was alles in der Methode Trimstart drinsteckt. Was in der
while-Zeile geschieht, ist dagegen klar für jeden, der was von C
versteht.
Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste
Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für
die
Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist,
gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen
kann.
>> Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst,> auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in> einer Funktion sein. Alles andere ist schlechter Stil und das hat mit> OOP oder PP bekanntlich nichts zu tun.
Auch bei mir steht
while(*s==' '||*s=='\t')s++;
return s;
nur in meiner Funktion nextvis(). In meinen Programmen steht dann
lediglich
s=nextvis(s);
Mikro 7. schrieb:> Rolf M. schrieb:>> ...>> Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere>> Schreibweise.>> Und das ist nicht "einfacher"? ;-)
Kommt drauf an, was du unter "einfacher" verstehst. Hier scheint nämlich
jeder was anderes damit zu meinen. Der eine versteht darunter, dass es
für den Prozessor effizienter ist, der nächste, dass es leichter
verständlich ist, der dritte, dass es weniger Zeichen zu tippen sind.
>> Und es macht nicht mal das gleiche.>> Dann eben:for (auto &c: s) ...
Das kann man immer noch nicht als Iterator in den String benutzen.
So wie ich das sehe, sind das jetzt Detailklauberreien. C ist ja eine
Untermenge von C++. Also kann ich da meine Strings genau so bearbeiten,
wenn ich das will.
Jobst Q. schrieb:> Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste> Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für> die> Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist,> gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen> kann.>>>
Soso,
irgend wie scheinst du dich an dem falschen Thema abzuarbeiten. Das
Zerlegen und/oder Trimmen von Zeichenketten ist in so ziemlich keiner
sinvollen Anwendung der zeitkritische Teil. (google mal nach "Premature
optimization is the root of all evil").
Bei der Verarbeitung von großen Datensätzen ist es eigentlich immer die
Beschaffung von Speicher, IO Operationen oder besondere Algorithmik,
welche einer genauen Betrachtung bedarf. Einfache Stringverarbeitung ist
da eher uninteressant.
BTW, ich weiß ja nicht wie du Quellcode liest, aber wenn ich irgend wo
im Text ein TrimStart sehe, dann weiß ich, dass die Whitespaces am
Anfang des Strings entfernt werden. Wie das passiert ist eigentlich
völlig Schnuppe, es sei denn ich hab Bugs an der Stelle oder es ist so
Schei*e implemtiert, dass es wirklich langsam wird.
Jobst Q. schrieb:> Auch bei mir steht>> while(*s==' '||*s=='\t')s++;> return s;>> nur in meiner Funktion nextvis(). In meinen Programmen steht dann> lediglich>> s=nextvis(s);
Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen
Speicher. Der geistert dann als Memory Leak für den Rest der
Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal
unkommentiert.
Jobst Q. schrieb:> Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek> vorhanden ist?
Kann man mit Vererbung eine neue Klasse erzeugen und die Methode
Implementieren?
Jobst Q. schrieb:> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich> geschieht, was alles in der Methode Trimstart drinsteckt. Was in der> while-Zeile geschieht, ist dagegen klar für jeden, der was von C> versteht.
Was wirklich geschieht, steht auch in einem C-Code nicht. Da kommt der
Compiler und macht sein ding.
Jobst Q. schrieb:> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich> geschieht, was alles in der Methode Trimstart drinsteckt. Was in der> while-Zeile geschieht, ist dagegen klar für jeden, der was von C> versteht.
Wenn man mal größere Frameworks verwendet hat oder auch nur in einem
größeren Team an einem Projekt gearbeitet hat, kann man nicht mehr
wissen was ein Funktionsaufruf aus einem anderen Projektteil genau tut.
Er sollte es halt ordentlich tun, sorgfältig dokumentiert und ohne
unbekannte Nebenwirkungen.
nicht"Gast" schrieb:>> s=nextvis(s);>> Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen> Speicher. Der geistert dann als Memory Leak für den Rest der> Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal> unkommentiert.
Deine unsinnigen Unterstellungen will ich mal nicht unkommentiert
lassen.
Wo steht denn, dass s der Startzeiger auf einen Speicher ist?
s steht für sourcepointer ist nach bewährter Tradition von
Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der
entsprechende Schreibzeiger ist t für targetpointer.
Leerzeichen können ja nicht nur am Anfang einer Zeile stehen. Würdest du
dann jedesmal einen neuen String anlegen?
Der Speicher für Stringverarbeitung heißt bei mir meistens buf und liegt
als lokale Variable auf dem Stack. Oder ist global und fängt dann mit
einem Großbuchstaben an. Wozu sollte man Speicher alloziieren, wenn es
garnicht nötig ist?
Jobst Q. schrieb:> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich> geschieht, was alles in der Methode Trimstart drinsteckt.
Und genau das soll er ja auch. Genau wie mich beim memcpy nur
interessiert, dass es einen Speicherblock von A nach B kopiert, nicht
aber, ob das jetzt durch eine simple Schleife mit byteweisem Kopieren
oder durch ein Duff-Device oder einen DMA-Transfer oder ein vom Compiler
inline erzeugtes für diesen Aufruf speziell optimiertes Stück Code
gemacht wird.
> Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste> Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für> die Aufgabe nötig ist.
Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,
wollen die meisten lieber ein komfortable als eine maximal schnelle
Stringverarbeitung.
Jobst Q. schrieb:> s steht für sourcepointer ist nach bewährter Tradition von> Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der> entsprechende Schreibzeiger ist t für targetpointer.
Uii,
er hat ein C Buch zu Hause stehen. Da bin ich ja total beeindruckt. So
ein Vollchecker, ein Profi, ein Vollnerd. Wenn du jetzt noch behauptest,
dass du schon mal in den Source von Linux geschaut (auch immer ein
beliebtes Totschlagargument) dann verneige ich mich vor Dir.
</Sarkasmus> (nur zur Sicherheit)
Genug der Schmeicheleien. Man kan hier nur das bewerten, was man lesen
kann.
BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an
der falschen Stelle gespart.
@nicht"Gast":
Auf die Gefahr hin, daß ich mich wiederhole:
Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche
argumentlosen Posts zerstören einen interessanten Thread.
Stefan
Stefan K. schrieb:> Auf die Gefahr hin, daß ich mich wiederhole:> Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche> argumentlosen Posts zerstören einen interessanten Thread.
kann man geteilter Meingung sein, aber hast ja in Summe Recht.
// Versöhnungskeks rüber reich.
nicht"Gast" schrieb:> BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an> der falschen Stelle gespart.
Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt
nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.
PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen
großen Mehraufwand beim Schreiben und Lesen des Quelltextes.
TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?
Und was hast du sonst noch für Sorgen?
Jobst Q. schrieb:> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.
Von CleanCodeDevelopment hast du offensichtlich noch nichts gehört.
Jobst Q. schrieb:> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?
TrimEnd
Jobst Q. schrieb:> nicht"Gast" schrieb:>>> BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an>> der falschen Stelle gespart.>> Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.>> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?>> Und was hast du sonst noch für Sorgen?Jobst Q. schrieb:> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?
nein, aber eine TrimEnd() und eine Trim(). Die Namensgebung kannst du
mir nicht anlasten, beschwer dich bei MS^^
Um mal zum Topic zurück zu kommen. Das schöne an der String Klasse in
dem Fall ist einfach, das die IDE gut parsen kann welche Methoden die
Klasse hat und über Intellisense (wie das bei Eclipse und QT Designer
benannt ist, weiß ich nicht, aber die beiden können das auch sehr gut)
die möglichen Methoden/Properties, oder was sonst noch anfällt,
hilfsbereiterweise anzeigen kann.
Um das mal zu Erläutern..
du hast einen
string foo = "nüscht";
wenn du jetzt "foo." eintippst, dann bringt die VS eine Liste mit
vorschlägen, was du mit deinem foo so alles anstellen kannst.
Das geht mit C sourcecode einfach deutlich schlechter, da keine
"offiziellen" Zusammenhänge erkennbar sind. Da kann dir die IDE
höchstens Vorschläge für den Funktionsnamen machen. Zusammenhänge sind
deutlich schwerer darstellbar.
nicht"Gast" schrieb:>> Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt>> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.>> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen>> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.
ach, vergessen...
'Schulterzuck'
Tom schrieb:> Jobst Q. schrieb:>> großen Mehraufwand beim Schreiben>> Wenn man mit Notepad entwickelt.
Freiwillig benutze ich keine Microsoft-Produkte.
Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind
schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle
Buchstaben richtig sind, steigt fast exponentiell.
Jobst Q. schrieb:> Freiwillig benutze ich keine Microsoft-Produkte.>> Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind> schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle> Buchstaben richtig sind, steigt fast exponentiell.
Was benutzt du denn für einen Editor zum programmieren. Die meisten
können wenigstens einfache Auto Vervollständigung. Da sollte die Länge
des Bezeichners egal sein.
Rolf M. schrieb:> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,> wollen die meisten lieber ein komfortable als eine maximal schnelle> Stringverarbeitung.
Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung
bestehen. Programme, die Textdateien einlesen und andere ausgeben.
Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen
Mensch und Maschine, etwas was beide verstehen.
Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch
komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie
mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine
Hilfe, sondern Behinderung.
Jobst Q. schrieb:> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung> bestehen. Programme, die Textdateien einlesen und andere ausgeben.> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen> Mensch und Maschine, etwas was beide verstehen.
Hast du das mal durch einen Profiler laufen lassen? Die IO Operationen
sind doch um Welten langsamer als die Bearbeitung der Strings.
Jobst Q. schrieb:> Rolf M. schrieb:>> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,>> wollen die meisten lieber ein komfortable als eine maximal schnelle>> Stringverarbeitung.>> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung> bestehen. Programme, die Textdateien einlesen und andere ausgeben.> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen> Mensch und Maschine, etwas was beide verstehen.
Und du hast verifiziert, dass die Nutzung einer Stringklasse in deinem
Programm ein Flaschenhals wäre? Oder vermutest du das nur (alias
"premature optimization")?
> Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch> komfortabler als die Arbeit mit Stringobjekten.
Mir würde wirklich keine Sprache einfallen, in der Stringhandling so
unkomfortabel ist wie in C.
Ich finde jedenfalls ein
1
stringc=a+b;
wesentlich komfortabler (und weniger fehleranfällig) als ein
1
char*c=malloc(strlen(a)+strlen(b)+1);
2
strcpy(c,a);
3
strcat(c,b);
4
// Plus später daran denken, den Speicher wieder freizugeben
> Mit diesen ist es wie mit Stützrädern bei Fahrrädern, wenn man Radfahren> kann, sind sie keine Hilfe, sondern Behinderung.
Rolf M. schrieb:> Mir würde wirklich keine Sprache einfallen, in der Stringhandling so> unkomfortabel ist wie in C.
Da sprichst du mir aus der Seele.
Naja, C kennt strenggenommen eigentlich überhaupt keine Strings. Und
selbst das, was salopp mit char bezeichnet wird, ist eigentlich kein
Textzeichen, sondern eine Integer-Variable. Naja, Steinzeit eben. Aber
wir scheinen unsere Faustkeile ja zu lieben...
W.S.
Boris P. schrieb:> Wie würde wohl einmyString = myString.Replace("Hund", "Salamander");> in C aussehen? Uaah, schauder...
Ganz einfach:
s=StrReplace(s,"Hund","Salamander");
Reine Formsache.
A. K. schrieb:> Klappt besonders gut mit> char b[100] = ...> char *s = StrReplace(b, "Hund", "Katze");> s = StrReplace(s, "Salamander", "Krokodil");
So ist es m.M.n falsch. StrReplace ruft free(b) oder realloc auf (muss
es, da 'Katze' länger als 'Hund' ist); und ich vermute ein free auf ein
lokale Variable führt zu undefiniertem Verhalten.
Jobst Q. schrieb:> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung> bestehen. Programme, die Textdateien einlesen und andere ausgeben.> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen> Mensch und Maschine, etwas was beide verstehen.
Solche Helferleins kennt jeder Programmierer, die schreibt man sich in
der Regel in Python oder Ähnlichem.
Aber wenn man nur nen Hammer kennt...
Jobst Q. schrieb:> Rolf M. schrieb:>> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,>> wollen die meisten lieber ein komfortable als eine maximal schnelle>> Stringverarbeitung.>> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung> bestehen. Programme, die Textdateien einlesen und andere ausgeben.> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen> Mensch und Maschine, etwas was beide verstehen.>> Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch> komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie> mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine> Hilfe, sondern Behinderung.
Richtige Kerle benutzen für Strings:
REPNZ MOVS
REPNZ SCAS
...
Da sieht man gleich, was da passiert.
Oder so ;-)
HVV schrieb:> aber vorher bitte ecx, esi, edi laden und das direction flag> setzen/löschen.....
Ja, das konnt ich alles mal. Vor Jahrzehnten. Als man PC-C-Compiler
nichtmal für viel Geld kaufen konnte und std::string noch nicht
existierte. Wobei ich zum ein paar Textfiles aufmischen heute auch
Python benutzen würde (und vereinzelt hab). Aber warum soll man sich
nicht das Leben schwer machen ;-)
PS: Die wirklich harten Kerle machen es so, dass es bei jeder
Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30
Jahre in jeweils kürzestmöglicher Zeit funktioniert!
A. K. schrieb:> PS: Die wirklich harten Kerle machen es so, dass es bei jeder> Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30> Jahre in jeweils kürzestmöglicher Zeit funktioniert!
Genau das überlasse ich heute gern den harten Burschen, die den GCC
nebst glibc und STL zusammenschrauben. Ich hab nämlich scon lang den
Überblick über intels/AMDs CPU Zoo verloren. Und dann hab ich auch noch
ARMs im Einsatz. War das schön früher auf der Mainframe. Ein fast in
Stein gemeißelter Befehlssatz. Und heute: "welche Vektoreinheiten hätten
sie denn gern?" "ich nehm die Blaue".
Moby A. schrieb im Beitrag #4645665:
> Vielleicht solltest Du Dir dazu mal vergegenwärtigen, für welches> Einsatzfeld Asm vermehrt zum Einsatz kommt. Da gehts eben nicht um PCs,> sondern um>>> der wachsende Bedarf>> an Software für Kleinstgeräte ... , wie sie im Internet der Dinge>> zahlreich zum Einsatz kommen.
TCP/IP Kommunikation in Assembler? Na dann viel Spaß.
Thread beobachten
Seitenaufteilung abschalten