(C) Datenmodell für größere Programme

[Markus Pitha]

Hallo,

Bisher bin ich schon zwei Mal an einem größeren privaten Projekt gescheitert, da ich im Laufe des Programmierens plötzlich andere Richtungen einschlagen musste, wodurch der Code immer mehr zum Spaghetticode mutierte und das Programm mehr und mehr unübersichtlicher wurde, wobei mir nach einigen Tagen, in denen ich nicht am Projekt gearbeitet hatte, nicht mal die Tonnen an Kommentaren halfen die ich dazugschrieb.
Am liebsten wäre mir natürlich ein objektorientiertes Datenmodell (C++), wo ich aber anfangs immer bei dem Problem war, dass ich eigentlich noch nicht so wirklich wusste, auf welche Probleme ich später mal stoßen werde wo dieses oder jenes vielleicht nicht so funktioniert, wie ich es mir im Vorhinein vorgestellt hatte.
Das zweite Problem meinerseits ist, dass ich Schwierigkeiten dabei habe, mir zu überlegen, was ich denn nun in welche Struktur, Funktion, oder Klasse packen soll, dass ich im Endeffekt den besten Nutzen daraus habe, oder besser gesagt, dass das Programm im Endeffekt so übersichtlich und effizient wie möglich ist.
Wie geht ma so etwas eigentlich am besten an? Gibt es irgendwelche Eselsbrücken, um die einzelnen Aufgaben als solche auch zu erkennen und dementsprechend die Funktionen oder Klassen zu gestalten? Natürlich habe ich immer grobe Vorstellungen darüber, was ich ungefähr wie strukturieren will, aber letztendlich scheitere ich dann doch letztendlich immer wieder an den Feinheiten.

Markus.

[lulu]

Huhu Markus

Bisher bin ich schon zwei Mal an einem größeren privaten Projekt gescheitert, da ich im Laufe des Programmierens plötzlich andere Richtungen einschlagen musste, wodurch der Code immer mehr zum Spaghetticode mutierte und das Programm mehr und mehr unübersichtlicher wurde, wobei mir nach einigen Tagen, in denen ich nicht am Projekt gearbeitet hatte, nicht mal die Tonnen an Kommentaren halfen die ich dazugschrieb.

Mmmmh, dann stimmt vermutlich etwas an Deinen Kommentaren nicht.
Wenn Du "Tonnen" davon schreibst diese aber nicht hilfreich sind ist da etwas verkehrt.

Und wenn Du plötzlich, bei einem privaten Projekt, andere Richtungen einschlagen musst hast Du offensichtlich schlecht geplant.

Das zweite Problem meinerseits ist, dass ich Schwierigkeiten dabei habe, mir zu überlegen, was ich denn nun in welche Struktur, Funktion, oder Klasse packen soll, dass ich im Endeffekt den besten Nutzen daraus habe, oder besser gesagt, dass das Programm im Endeffekt so übersichtlich und effizient wie möglich ist.

Dafür sind eigene Erfahrungswerte nützlich, aber auch durch das studieren von Quellcode anderer Programmierer (die Sprache ist dabei egal) kannst Du viel lernen.

Vielleicht hilft es Dir wenn Du erst das Konzept, dann die Dokumentation
und erst ganz zum Schluss das Programm schreibst.

Auch ein einfaches Flussdiagramm kann bereits sehr nützlich sein.

Arbeite an Deinem "coding style" und überarbeite ggf. ältere Programme
wenn dort grundlegende Sachen zu verbessern sind.
Zeig Dein Programm jemandem mit mehr Erfahrung und lass Dir Tipps geben, dann gibt es natürlich auch Bücher die sich damit beschäftigen.

Vielleicht magst Du ja, wenn es nicht zu lang ist, mal ein besonders misslungenes Code-Beispiel posten.

Viele Grüße

lulu

[Markus Pitha]

Hello,

Mmmmh, dann stimmt vermutlich etwas an Deinen Kommentaren nicht.
Wenn Du "Tonnen" davon schreibst diese aber nicht hilfreich sind ist da etwas verkehrt.

Ich meine damit, dass ich später meistens drauf komme, dass ich vielleicht dieses oder jenes besser kommentiert hätte, an das ich vielleicht vorher nicht dachte. Ich kommentiere zwar auch für mich hilfreich, aber immer wieder gibt es doch Situationen, wo ich mir trotzdem erst wieder mal herleiten muss, was ich nun eigentlich gemeint habe.

Dafür sind eigene Erfahrungswerte nützlich, aber auch durch das studieren von Quellcode anderer Programmierer (die Sprache ist dabei egal) kannst Du viel lernen.

Das finde ich zum Teil richtig. Ich könnte genauso gut die Fehler anderer dadurch leicht abschauen.

Vielleicht hilft es Dir wenn Du erst das Konzept, dann die Dokumentation
und erst ganz zum Schluss das Programm schreibst.

Ich mache mir eigentlich immer zuerst Handnotizen, wo ich grobe Unterteilungen der möglichen Funktionen mit Pfeilen zu den jeweiligen Aufgabenstellungen verbinde.

Arbeite an Deinem "coding style" und überarbeite ggf. ältere Programme
wenn dort grundlegende Sachen zu verbessern sind.

Ja. Das habe ich in der Vergangenheit immer so gemacht, aber nur in Perl.
Wahrscheinlich liegt meine Misere auch daran, dass ich bis dato nie in C oder C++ Programme geschrieben habe, die größer als 600 Zeilen waren.

Zeig Dein Programm jemandem mit mehr Erfahrung und lass Dir Tipps geben, dann gibt es natürlich auch Bücher die sich damit beschäftigen.

Das mache ich eigentlich oft hier und mir wurden eigentlich immer sehr nützliche Verbesserungsvorschläge unterbreitet.

Vielleicht magst Du ja, wenn es nicht zu lang ist, mal ein besonders misslungenes Code-Beispiel posten.

Es sieht durch das Verrutschen der Einrückung und ohne Syntaxhighlighting wahrscheinlich noch wüster aus, als es ist, aber hier mal mein letztes Beispiel.

http://test.pithax.net/main.c

..und so sieht es in Funktion aus.

http://pics.pithax.net/game.jpg  ~ 130k

Zum Verständnis, warum ich es jetzt abgebrochen habe war der Grund, dass ich in diesem Spiel noch zusätzlich Features in Form von "Goodies" einbauen wollte, die es dem Spieler ermöglichen sollen das Schiff, das den Ball immer wieder wegschleudert, aufzubessern. Bisher gibt es gerade mal ein Goodie, das aber noch nicht mal voll ausprogrammiert wurde (die Goodies verschwinden nach einer gewissen Zeit noch nicht), oder das Implementieren der anderen Goodies hätte wiederum ein Umschreiben des Codes zur Folge, da sich dann die Grafik des Schiffes verändern hätte sollen, und das will ich mir eigentlich nicht antun.
Solche Dinge, wie das Umschreiben im Nachhinein will ich eben vermeiden.

Markus.

[flashnfantasy]

Suche mal im Internet (zB mit Google) nach Bernd Österreich
oder speziell nach Unified Modelling Language - UML.

Letztlich, daß ist meine Überzeugung, ist Erfahrung das Wichtigste.
Selbst Objectorientierung oder sonstwas hilft nicht weiter, wenn die Programmierer das nicht im Blut haben.

[Biesterfeld]

Hej Markus,

Bisher bin ich schon zwei Mal an einem größeren privaten Projekt gescheitert, da ich im Laufe des Programmierens plötzlich andere Richtungen einschlagen musste, wodurch der Code immer mehr zum Spaghetticode mutierte und das Programm mehr und mehr unübersichtlicher wurde, wobei mir nach einigen Tagen, in denen ich nicht am Projekt gearbeitet hatte, nicht mal die Tonnen an Kommentaren halfen die ich dazugschrieb.

Kenn ich. Kenn auch niemanden der nicht zumindest berichten würde genau so angefangen zu haben.

Deine Probleme sind letzendlich Gegenstand der Wissenschaft die sich mit Softwaremodellierung auseinandersetzt. Ich weiß jetzt nicht ob du schonmal was von UML gehört hast, aber das ist genau die Modellierungssprache die versucht, zunächst die Semantik einer Software zu erfassen. Ein Buchtip, der ganz gut sein soll (hab es allerdings selber nicht gelesen) ist der von Bernhard Rumpe, Modellierung mit UML.

Wie geht ma so etwas eigentlich am besten an? Gibt es irgendwelche Eselsbrücken, um die einzelnen Aufgaben als solche auch zu erkennen und dementsprechend die Funktionen oder Klassen zu gestalten? Natürlich habe ich immer grobe Vorstellungen darüber, was ich ungefähr wie strukturieren will,

Aufschreiben! Wie dir Lulu schon gesagt hat. Erstmal ein Klassen-Diagramm schreiben. Software-Tools wie z.B. Poseidon helfen dir dabei.
Dann alle Klassen, Felder und Methoden ausführlich (!) dokumentieren. Also wirklich sagen, was sie machen sollen und wie sie es machen sollen. Erst wenn du das Gefühl hast, das Modell entspricht der fertigen Software, setzt du dich an die Implementation. Natürlich wird es jetzt nochmal zu Änderungen im Modell (dem sog. Refactoring) kommen, aber mach dir klar, dass der Umfang der Änderung direkt mit dem Ausmaß an nachsichziehenden Problemen korelliert.

Beste Grüße
Biesterfeld

[Christoph Zurnieden]

Hi,

Bisher bin ich schon zwei Mal an einem größeren privaten Projekt gescheitert,

Nur zwei mal? Noch jung, was? ;-)
Na, das wird noch öfter vorkommen, mach Dir nix draus.

nicht mal die Tonnen an Kommentaren halfen die ich dazugschrieb.

Zuviel istauch nicht gesund.

Am liebsten wäre mir natürlich ein objektorientiertes Datenmodell

Warum? Nein, wirklich: welchen Grund hast Du ein objektorientiertes Datenmodell anzuwenden?

Wie geht ma so etwas eigentlich am besten an?

Üben.

Gibt es irgendwelche Eselsbrücken

Mmh... ja, es gibt da so einiges, aber keine Patentrezepte. Die "Standardwerke" über Datenstrukturen und Algorithmen wurden Dir ja schon empfohlen.
Aber eine Regel, die mit Sicherheit schon irgendwann einmal angesprochen wurde, die ich aber gerne noch einmal wiederhole: "Keep it simple, stupid!"

• keine komplexen Algorithmen für einfache Aufgaben
• auch für komplexe Aufgaben kann es einfache Algorithmen geben es ist jedoch unwahrscheinlich, wenn in Sedgwick et al nichts darüber zu finden ist.
• "Gut genug" ist gut genug und bedarf keiner Optimierung.

Natürlich habe ich immer grobe Vorstellungen darüber, was ich ungefähr wie strukturieren will, aber letztendlich scheitere ich dann doch letztendlich immer wieder an den Feinheiten.

Dann mußt Du Deine Vorstellungen verfeinern. Sammel zusammen, was Du benötigst und programmiere das.
Sowas Banales! Ts!
Moooment! ;-)
Ersteinmal sollst Du sammeln, was Du benötigst und nicht, was Du nicht benötigst. "Das Programm soll nicht abstürzen" ist keine gute Anweisung, denn ich kann Dir ein Programm schreiben, das die Platte putzt jedoch nicht abstürzt. War es das, was Du mit "Das Programm soll nicht abstürzen" bezweckt hattest? Wohl kaum, was? ;-)
Du möchtest doch ein Spielchen programmieren, ja? Mit einem Ball? Dann mal anhand eines Ballspieles: Pong gegen die Wand.
Was wird dazu benötigt? Ein Ball, eine Wand und ein Mittel mit dem man den Ball bewegen kann. Die nötigen Algorithmen sind "Einfallswinkel gleich Ausfallswinkel" und "Geschwindkeit gleich Weg durch Zeit".
Daraus kannst Du jetzt die Datenstrukturen ziehen:
So ein Ball hat einige Eigenschaften, ganz ohne wär's kein Ball. Da jemand damit spielen soll, muß er den Ball erkennen können. Der Einfachheit halber nehmen wir mal visuelle Wahrnehmung an, der Ball muß sichtbar sein. Das bedingt schonmal, das sich die Farbe des Balles deutlich von der Farbe des Hintergrundes unterscheidbar sein muß. Erste Eigenschaft ist also die Farbe und im Hinterkopf entsteht schon der erste Bezug, nämlich der zur Hintergrundfarbe. Ist der Ball kleiner als ein Pixel ist er nicht sichtbar, also muß er eine gewisse Größe haben. Zweite Eigenschaft ist somit die Dimension.
Der Ball hat somit neben seiner schieren Existenz noch zwei weitere Eigenschaften. Aber man könnte, wenn das Solitärpong einmal funktioniert auf die Idee kommen noch ein paar Gimmicks einzubauen. Z.B. ist von Bällen bekannt, das sie eine unterschiedlichen Grad an Elastizität haben können, nicht nur Farbe sondern auch Muster, verschieden rauhe Oberflächen usw. Es wäre demnach empfehlenswert die Datenstruktur "Ball" erweiterbar zu halten. Wie dies genau zu geschehen hat ist die Sache der Programmiersprache, bei C würde ich z.B. ein Struct vorschlagen, das läßt sich problemlos erweitern.
Die gleiche Prozedur wäre dann noch mit Wand und Schläger durchzuführen. Wenn Du dann anfängst Code zu schreiben oder vielleicht sogar schon vorher fällt Dir auf, das da noch Wesentliches fehlt. Verschiedene Fragen wie z.B. "Wie groß soll das Spielfeld sein?", "Was passiert mit Bällen, die außerhalb des Spielfeldes landen?", "Welche Anfangsgeschwindigkeit hat der Ball?" und "Wo kommt der Ball am Anfang her" tauchen auf und drängen unnachgiebig darauf beantwortet zu werden.

Ah, noch ein Tip von jemandem, der schon öfter darauf reingefallen ist: falle nicht auf Buzzwords rein, denke selber und zwar nach!

so short

Christoph Zurnieden

[Ludger]

Hi,

Am liebsten wäre mir natürlich ein objektorientiertes Datenmodell

Warum? Nein, wirklich: welchen Grund hast Du ein objektorientiertes Datenmodell anzuwenden?

ist nicht jedes Datenmodell objektorientiert, huestel?

Wie geht ma so etwas eigentlich am besten an?

Üben.

Ueben reicht da manchmal nicht.

Gibt es irgendwelche Eselsbrücken

Mmh... ja, es gibt da so einiges, aber keine Patentrezepte. Die "Standardwerke" über Datenstrukturen und Algorithmen wurden Dir ja schon empfohlen.
Aber eine Regel, die mit Sicherheit schon irgendwann einmal angesprochen wurde, die ich aber gerne noch einmal wiederhole: "Keep it simple, stupid!"

Richtig, denn das Doofe ist das Gute.

• keine komplexen Algorithmen für einfache Aufgaben
• auch für komplexe Aufgaben kann es einfache Algorithmen geben es ist jedoch unwahrscheinlich, wenn in Sedgwick et al nichts darüber zu finden ist.

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

[...] Ah, noch ein Tip von jemandem, der schon öfter darauf reingefallen ist: falle nicht auf Buzzwords rein, denke selber und zwar nach!

Da erinnere ich mich gerade ungerne daran, dass Du sogar mich mal mit diesem Vorwurf angegangen bist.

Gruss,
Ludger

[flashnfantasy]

ist nicht jedes Datenmodell objektorientiert, huestel?

Nein, die allerwenigsten Datenmodelle sind objektorientiert - selbst wenn sie es behaupten.
Objektorientierung bedeutet Hiding, Inheritance und Polymorphie.
Und gerade an der Polymorphie scheitern die meisten Datenmodelle.

[...] Ah, noch ein Tip von jemandem, der schon öfter darauf reingefallen ist: falle nicht auf Buzzwords rein, denke selber und zwar nach!

Da erinnere ich mich gerade ungerne daran, dass Du sogar mich mal mit diesem Vorwurf angegangen bist.

Buzzwords - Objektorientierung ist keine Lösung, sondern nur ein anderer Weg, und einen, den ich nicht jedem empfehlen würde.

Also, falls du mit C scheiterst, dann wirst du mit C++ auch scheitern, halt nur noch tragischer oder gründlicher.

[Christoph Zurnieden]

Hi,

Also, falls du mit C scheiterst, dann wirst du mit C++ auch scheitern, halt nur noch tragischer oder gründlicher.

Ich bin ja eher der Meinung, das beim Schadenspotential C um Schamhaaresbreite gewinnt >;->

so short

Christoph Zurnieden

[Ludger]

Hí,

ist nicht jedes Datenmodell objektorientiert, huestel?

Nein, die allerwenigsten Datenmodelle sind objektorientiert - selbst wenn sie es behaupten.
Objektorientierung bedeutet Hiding, Inheritance und Polymorphie.
Und gerade an der Polymorphie scheitern die meisten Datenmodelle.

Objektorientiertheit bedeutet nicht primaer "Hiding, Inheritance & Polimorphie" sondern eben Objektorientiertheit.

Datenmodelle sind immer objektorientiert. Daten sind ein Abbild (Nachbau) der Realitaet. Aus ihnen gewinnen wir Informationen. Die Realitaet abstrahieren wir zu Daten.

Gruss,
Ludger

[flashnfantasy]

Objektorientiertheit bedeutet nicht primaer "Hiding, Inheritance & Polimorphie" sondern eben Objektorientiertheit.

Das ist eine von diesen Aussagen, die man getrost vergessen kann.
Aus 'A folgt A' ist immer richtig.

Dann erkläre mal den Unterschied zu den relationalen Datenmodellen ?

Man unterscheidet in folgende Datensysteme:

• prozedural (Assembler, Basic, COBOL, Pascal, C)
• funktional (LISP, PL1)
• relational (Datenbanken)
• KI (Prolog)
• Objektorientiert (Smalltalk, C++, Python, Eiffel)

Jedes System kann eine reale Welt modellieren, alle Systeme sind ineinander überführbar, aber trotzdem gibt es klare Abgrenzungen.

[Christian Kruse]

你好 flashnfantasy,

Man unterscheidet in folgende Datensysteme:

*ouch* Da fängts schon an.

• prozedural (Assembler, Basic, COBOL, Pascal, C)
• funktional (LISP, PL1)

Das sind Programmiersprachen. Keine “Datensysteme”.

• relational (Datenbanken)

Relationale Datenbanken sind _eine_ Art von Datenbank-Systemen (es gibt
durchaus noch andere :).

• KI (Prolog)

Prolog ist eine _logische_ Programmiersprache. Sie wird gerne mal für KI
eingesetzt, aber hat ansonsten nichts mit KI zu tun.

• Objektorientiert (Smalltalk, C++, Python, Eiffel)

C++ ist eine hybride Programmiersprache, eine Mischung aus prozeduraler und
objekt-orientierter Sprache, keine objekt-orientierte.

Du schmeisst alles mögliche in einen Topf und raus kommt eigentlich nur ein
Wortschwall von Luftblasen: piekt man rein bleibt nichts mehr übrig.

再见,
克里斯蒂安

[Ludger]

Hi,

Man unterscheidet in folgende Datensysteme:

Du schmeisst alles mögliche in einen Topf und raus kommt eigentlich nur ein
Wortschwall von Luftblasen: piekt man rein bleibt nichts mehr übrig.

Du hast dieses Subjekt ja dankenswerterweise bereits auf das beste abgefruehstueckt. Allerdings erlaube ich mir da noch eine kleine Anmerkung: "Datensystem" ist cool!

;-)

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Warum? Nein, wirklich: welchen Grund hast Du ein objektorientiertes Datenmodell anzuwenden?

ist nicht jedes Datenmodell objektorientiert, huestel?

Als Model ja, nur die Implementation in heutige Hardware ist unmöglich. Objektorientierung würde als Grundsatz ein reines Objekt benötigen; ein Etwas ohne Eigenschaften, nur Existenz. Das ist nunmal nicht möglich. Es gibt jedoch ein oder zwei Sprachen, die sich dem ganz gut annnähern.

Wie geht ma so etwas eigentlich am besten an?
Üben.
Ueben reicht da manchmal nicht.

Es sind aber die sprichwörtlichen 99%.

"Keep it simple, stupid!"

Richtig, denn das Doofe ist das Gute.

Nein, andersrum wird da ein Schuh draus: das Intelligente ist das Schlechte.

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

Bitte um eine saubere Beweisführung.

[...] Ah, noch ein Tip von jemandem, der schon öfter darauf reingefallen ist: falle nicht auf Buzzwords rein, denke selber und zwar nach!

Da erinnere ich mich gerade ungerne daran, dass Du sogar mich mal mit diesem Vorwurf angegangen bist.

Mir egal, Hauptsache: Du erinnerst Dich.

so short

Christoph Zurnieden

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Christoph
=> Hallo Christoph.

Als Model ja, nur die Implementation in heutige Hardware ist unmöglich. Objektorientierung würde als Grundsatz ein reines Objekt benötigen; ein Etwas ohne Eigenschaften, nur Existenz. Das ist nunmal nicht möglich. Es gibt jedoch ein oder zwei Sprachen, die sich dem ganz gut annnähern.

Ruby und ..?

Einen schönen Samstag noch.

Gruß, Ashura

[Christoph Zurnieden]

Hi,

Es gibt jedoch ein oder zwei Sprachen, die sich dem ganz gut annnähern.

Ruby und ..?

Ruby gehört eher nicht dazu, die Objektorientiertheit ist nicht konsequent genug. Smalltalk und Objective-C wären da die Kandidaten, wenn überhaupt. Manche würden auch noch gerne Modula mit reinnehmen, aber da schwanke ich selber und entscheide nach Tageslaune. Heute z.B.: nö.
Aber so ein Streit ist, wie angeführt müßig, da eher Geschmacksache denn objektiv [sic?]. Nur was C++ mit Objektorientiertheit zu haben soll habe ich nie ganz begriffen, denn da fehlt es doch noch erheblich. Ich habe sogar dsa dumme Gefühl, das so manches ... ähm ... Mißgeschick aus dem Anspruch resultiert C++ Objektorientiertheit zuzusprechen und danach zu handeln.

so short

Christoph Zurnieden

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Christoph
=> Hallo Christoph.

Ruby gehört eher nicht dazu, die Objektorientiertheit ist nicht konsequent genug.

*g* Sag das mal Matz--[Wikipedia: Yukihiro_Matsumoto].

Smalltalk und Objective-C wären da die Kandidaten, wenn überhaupt. Manche würden auch noch gerne Modula mit reinnehmen, aber da schwanke ich selber und entscheide nach Tageslaune. Heute z.B.: nö.

Ruby ist nach Smalltalk entstanden. Matz war der Auffassung , dass Sprachen, wie z. B. Smalltalk nicht _objektorientiert genug_ waren. ([Wikipedia: Ruby#Merkmale_der_Sprache]

Aber so ein Streit ist, wie angeführt müßig, da eher Geschmacksache denn objektiv [sic?].

Richtig, objektiv ist unmöglich.

Nur was C++ mit Objektorientiertheit zu haben soll habe ich nie ganz begriffen, denn da fehlt es doch noch erheblich. Ich habe sogar dsa dumme Gefühl, das so manches ... ähm ... Mißgeschick aus dem Anspruch resultiert C++ Objektorientiertheit zuzusprechen und danach zu handeln.

Dazu kann ich noch nicht viel sagen, da ich mich damit noch nicht befasst habe.

Einen schönen Samstag noch.

Gruß, Ashura

[Ashura]

puts "Hallo " + gets.chomp + "."

?>
=> Hallo.

*g* Sag das mal Matz--[Wikipedia: Yukihiro_Matsumoto].

[Wikipedia: Yukihiro_Matsumoto] natürlich.

Einen schönen Samstag noch.

Gruß, Ashura

[Christoph Zurnieden]

Hi,

Smalltalk und Objective-C wären da die Kandidaten, wenn überhaupt. Manche würden auch noch gerne Modula mit reinnehmen, aber da schwanke ich selber und entscheide nach Tageslaune. Heute z.B.: nö.

Ruby ist nach Smalltalk entstanden. Matz war der Auffassung , dass Sprachen, wie z. B. Smalltalk nicht _objektorientiert genug_ waren.

Dann sag' ich es direkt: er hat's nicht geschafft.
Aber das ist wiederum zuviel, denn: er konnte ja gar nicht anders.
Aber bevor noch Mißverständnisse auftreten: Ruby ist keine schlechte Sprache, beileibe nicht!

so short

Christoph Zurnieden

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Christoph
=> Hallo Christoph.

Ruby ist nach Smalltalk entstanden. Matz war der Auffassung , dass Sprachen, wie z. B. Smalltalk nicht _objektorientiert genug_ waren.

Dann sag' ich es direkt: er hat's nicht geschafft.
Aber das ist wiederum zuviel, denn: er konnte ja gar nicht anders.

Ob Ruby den Vorstellungen eines Jeden von einer objektorientierten Sprache entspricht, vermag ich noch nicht zu sagen.
Aber lass' dir gesagt sein: Ruby entwickelt sich ständig weiter.

Aber bevor noch Mißverständnisse auftreten: Ruby ist keine schlechte Sprache, beileibe nicht!

Richtig. :-)

Einen schönen Sonntag noch.

Gruß, Ashura

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Christoph
=> Hallo Christoph.

Dann sag' ich es direkt: er hat's nicht geschafft.

Das hatte ich vorhin noch vergessen:

Auf was beziehst du dich hierbei? Woran meinst du zu erkennen, dass Ruby nicht gänzlich objektorientiert ist?

Einen schönen Sonntag noch.

Gruß, Ashura

[Christoph Zurnieden]

Hi,

Dann sag' ich es direkt: er hat's nicht geschafft.

Das hatte ich vorhin noch vergessen:

Auf was beziehst du dich hierbei? Woran meinst du zu erkennen, dass Ruby nicht gänzlich objektorientiert ist?

Weil es das nicht sein _kann_.
Wäre gemein von mir so zu argumentieren, wenn ich das nicht schon vorher gesagt hätte.

Aber ich habe bei Ruby schon lange nicht mehr reingeschaut und werde es Montag mal tun, da habe ich ein paar Stunden Zeit. Hoffe ich zumindest.

Bis dahin denn

Christoph Zurnieden

[Ludger]

Hi,

Warum? Nein, wirklich: welchen Grund hast Du ein objektorientiertes Datenmodell anzuwenden?

ist nicht jedes Datenmodell objektorientiert, huestel?

Als Model ja, nur die Implementation in heutige Hardware ist unmöglich. Objektorientierung würde als Grundsatz ein reines Objekt benötigen; ein Etwas ohne Eigenschaften, nur Existenz. Das ist nunmal nicht möglich. Es gibt jedoch ein oder zwei Sprachen, die sich dem ganz gut annnähern.

jede Sprache erlaubt es Objekte zu erstellen (sogar COBOL in aelteren Versionen), alles andere ist eher eine Stilfrage.

"Keep it simple, stupid!"

Richtig, denn das Doofe ist das Gute.

Nein, andersrum wird da ein Schuh draus: das Intelligente ist das Schlechte.

Warum ist nicht das Doofe das Gute?   :-)

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

Bitte um eine saubere Beweisführung.

Huestel.

Gruss,
Ludger

[Anonymous]

jede Sprache erlaubt es Objekte zu erstellen (sogar COBOL in aelteren Versionen), alles andere ist eher eine Stilfrage.

Das ist falsch.

[Ludger]

Hi,

jede Sprache erlaubt es Objekte zu erstellen (sogar COBOL in aelteren Versionen), alles andere ist eher eine Stilfrage.

Das ist falsch.

och, da kann man mit Dateien, dem so genannten COPY-Konzept folgend durchaus objektorientiert kodieren.

Wirklich wahr.

Gruss,
Ludger

[Anonymous]

jede Sprache erlaubt es Objekte zu erstellen (sogar COBOL in aelteren Versionen), alles andere ist eher eine Stilfrage.

Das ist falsch.

och, da kann man mit Dateien, dem so genannten COPY-Konzept folgend durchaus objektorientiert kodieren.

Das ist etwas anderes. Objekt-Orientiert programmieren heisst nicht, dass Sprach-Konstrukte zur Verfügung stehen müssen, es ist eher ein Programmier-Stil.

Um Objekte zu erstellen müssen allerdings die notwendigen Sprach-Konstrukte existieren. Und die hat Cobol nicht.

Wirklich wahr.

Bei COBOL möchte ich das doch bezweifeln.

[Ludger]

Hi,

Um Objekte zu erstellen müssen allerdings die notwendigen Sprach-Konstrukte existieren. Und die hat Cobol nicht.

Wirklich wahr.

Bei COBOL möchte ich das doch bezweifeln.

doch, doch, aber eine besonders geartete Unterstuetzung von Objekten ist bei aelteren COBOL-Versionen in der Tat nicht vorhanden. Aber das macht doch nichts.

Gruss,
Ludger

[Anonymous]

Wirklich wahr.

Bei COBOL möchte ich das doch bezweifeln.

doch, doch, aber eine besonders geartete Unterstuetzung von Objekten ist bei aelteren COBOL-Versionen in der Tat nicht vorhanden. Aber das macht doch nichts.

Dann zeig mal Code. Ich lasse mich da gern einen besseren belehren, aber ich kann mir nicht vorstellen, wie man bei COBOL Objekt-Orientierung hineinquetschen kann.

[Ludger]

Hi,

Wirklich wahr.

Bei COBOL möchte ich das doch bezweifeln.

doch, doch, aber eine besonders geartete Unterstuetzung von Objekten ist bei aelteren COBOL-Versionen in der Tat nicht vorhanden. Aber das macht doch nichts.

Dann zeig mal Code. Ich lasse mich da gern einen besseren belehren, aber ich kann mir nicht vorstellen, wie man bei COBOL Objekt-Orientierung hineinquetschen kann.

"zeig malm Code" hilft hier nicht. Sagt Dir vielleicht etwas die Aussage "Entitaeten programmieren"? Dann kannnst Du Dir die Chancen und Grenzen von COBOL vielleicht besser vorstellen.

Gruss,
Ludger

[Anonymous]

Dann zeig mal Code. Ich lasse mich da gern einen besseren belehren, aber ich kann mir nicht vorstellen, wie man bei COBOL Objekt-Orientierung hineinquetschen kann.

"zeig malm Code" hilft hier nicht.

Zeig mal Code ist genau das, was nötig wäre. Ich kenne COBOL _sehr_ gut. Also, tacheless, oder war das wieder nur heisse Luft?

[Ludger]

Hi.

Ich kenne COBOL _sehr_ gut. Also, tacheless, oder war das wieder nur heisse Luft?

dann sind wir ja Leidensgenossen. Aber leider bist Du ja ganz anscheinend nicht in der Lage abstrakt zu denken. Sonst wuerdest Du wissen, was gemeint war.

"Zeig mal Code!" ist ja nun wirklich der Gipfel der Niveaulosigkeit.

Gruss,
Ludger

[Anonymous]

Also doch nur heisse Luft. War mir eigentlich von vornherein klar.

[Ludger]

Hi,

Also doch nur heisse Luft. War mir eigentlich von vornherein klar.

was ist Dir denn unklar an der Aussage, dass jede Programmiersprache - so zu sagen notgedrungen - objektorientiert ist?

Oder sagt Dir "Entitaten programmieren" irgendetwas?

Gruss,
Ludger

[Anonymous]

was ist Dir denn unklar an der Aussage, dass jede Programmiersprache - so zu sagen notgedrungen - objektorientiert ist?

Wenn du das glaubst, hast du nicht verstanden, was "Objekt-Orientiert" bedeutet.

Oder sagt Dir "Entitaten programmieren" irgendetwas?

"Entitäten programmieren" ist ein Null-Wort. Wird gerne von BWLern und Leuten, die nicht vom Fach sind, genutzt. Passt ja, du bist ja auch nicht vom Fach, wenn ich mich recht erinnere.

[Ludger]

Hi,

Oder sagt Dir "Entitaten programmieren" irgendetwas?

"Entitäten programmieren" ist ein Null-Wort. Wird gerne von BWLern und Leuten, die nicht vom Fach sind, genutzt. Passt ja, du bist ja auch nicht vom Fach, wenn ich mich recht erinnere.

ich habe das in den letzten 20 Jahren exakt von einer Person gehert. Und es schien mir schluessig und relevant.

BWLer-Gesuelze kenne ich auch zu genuege, wuerde ich hier aber eher nicht bereitstellen.

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

Bitte um eine saubere Beweisführung.

Huestel.

Das hört sich gar nicht gut an, hast Du es mal mit Salbeitee probiert?

so short

Christoph Zurnieden

[Biesterfeld]

Hej,

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

Bitte um eine saubere Beweisführung.

Ist das denn nicht die Aussage der Kolmogorov-Komplexität?
Meine Frage ist übrigens nicht rethorisch.

Beste Grüße
Biesterfeld

[Christoph Zurnieden]

Hi,

Fuer komplexe Aufgaben kann es keine einfachen Algorithmen geben.

Bitte um eine saubere Beweisführung.

Ist das denn nicht die Aussage der Kolmogorov-Komplexität?

Ja, kann man so sagen. Allerdings meinte ich keine Komplexität im mathematischem Sinn, da habe ich mich nicht gut genug ausgedrückt und bitte daher um Entschuldigung.

Also nochmal und ausführlich:

Jede berechenbare Aufgabe A läßt sich in berechenbare Teilaufgaben A_i teilen. Ist A = A_i läßt sie sich logischerweise nicht mehr teilen, wir sind bei der einfachen Turingmaschine angelangt.
Andersrum lassen sich diese Teilaufgaben natürlich auch zusammenfassen, theoretisch zwar in beliebiger Art und Reihenfolge, doch praktische Erwägungen geben einige Regeln vor. trifft man sich in der Mitte kommt man zu recht einfachen Algorithmen und zwar genau die Algorithmen, die bei Sedgwick et al aufgeführt sind. Somit lassen sich auch komplexe Aufgaben auf einige wenige einfache Algorithmen reduzieren. Das Zusammenspiel dieser Algorithmen, der Algorithmus zur Lösung der Aufgabe A also, bleibt dabei mathematisch gesehen natürlich immer noch genau so komplex, wie er von Anfang an war. "Divide&Conquer" wie's so schön heißt.
Und noch etwas steckte in meiner Behauptung: manche komplexen Aufgaben sehen nur so aus, sind aber in Wahrheit höchst simpel.

so short

Christoph Zurnieden