Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

OO Philosophie.

Werbeanzeige

DragonMaster

Community-Fossil

Beiträge: 1 603

  • Private Nachricht senden

21

16.09.2004, 15:58

Zitat

Also, C'- und D'toren sind nichts, was durch die OO erzwungen wird. in Objective-C muss ich beispielswiese den C'tor manuell aufrufen, ich kann es also vergessen (zumindest theoretisch) und Objective-C ist IMHO "objektorientierter", als z.B. C++.
Das mag sein, das Objective-C objekorientierter ist. Aber wenn ich den C-Tor Manuell aufrufen muss? Das empfinde ich als große schwäche. Denn der Sinn von ctor und dtor ist es doch grad das ein Objekt fertig benutzbar konstruiert wird und auch wieder ordnungsgemäß zerstört wird. Wenn man das Manuell machen muss, kann man das schnell vergessen.

Quellcode

 
1
2

let map funktion [] = []
    map funktion (head::tail) = (funktion head :: map funktion tail)


C-/C++-Quelltext

 
1
2
3
4
5
6
7
8

template <typename T, typename F>
std::list<T> map (std::list<T> const & list, F f)
{
   std::list<T> result;
   for (std::list<T>::const_iterator it=list.begin(); it!=list.end(); ++it)
      result.push_back (f(*it));
   return result;
}
Man kann sich über die Syntax einer Sprache streiten. Sicher das obere Beispiel ist kürzer, aber für mich 0% verständlich, da ich die Sprache nicht kenne. Ob ein Code leserlich ist hängt nicht zu 100% von der Syntax ab, sondern es hängt zu 80% davon ab, wie gut man die Sprache kennt. Und der vergleich der Syntax der Sprachen hat zu 0% was mit diesem Thema zu tun. Ich könnt hier jetzt auch Perl reinwerfen und sagen, das ist mist.

Zitat

Viele funktionale Sprachen sind statisch typisiert, wie z.B. SML, O'Caml, ... . Bieten aber ein tolles Type-Inference-System. Sowas, wie in Java oder C++ ist doch schon fast eine Zumutung.
Najo das mag halt sein. Aber auch hier hat das absolut nichts mit diesem Thema zu tun. Die Typisierung von C und auch C++ hat hier etwas mit der CPU-Architektur zu tun. C wurde als Sprache konzipiert die sehr CPU nah sein sollte. Und da C die Basis von C++ ist, hat sich das eben durchgezogen.
Ich empfinde es sogar als angenehmer wenn ich feste Typen habe die feste größen haben. Bei Variablen die zugleich eine Zahl oder auch ein String sein können, ist einfach nur störend. Man weis nie von welchem Typ die Variable gerade hat. Und wenn ich so ein Dynamisches Ding haben will, dann kann ich mir so eines auch mit Sprachen wie z.B. C++ bauen ;) Wie das ganze nun aber dargestellt wird hängt wiederum von der Syntax ab und hat rein gar nichts mit OO zu tun.

Zitat

Ich kann mir vorstellen, dass sich ein Teil dieser Diskussion daraus ergibt, dass sich C++ (leider) durchgesetzt hat. Das bietet natürlich eine grosse Angriffsfläche gegen die meistbenutzte Sprache, die OO erlaubt.
Besser könnt ich es auch nicht ausdrücken. Und ich kann mich hier auch nur wieder einmal wiederholen. Es geht hier ja nicht darum welche Sprach nun eine bessere Syntax hat oder welche Sprache die Prinzipien von OO beser umsetzt. Das war nicht Thema dieses Threads. Die Sprache ist nicht OO. Sie ist das Werckzeug das ich benutzen kann um OO zu programmieren. Und wenn einem eine Sprache nicht gefällt dann sollte man sich eine andere suchen.
Ich kann auch nicht sagen warum sich C so durchgesetzt hat. Aber warum sich C++ so durchgesetzt hat ist leicht zu erklären. Das liegt an der Erfolgsgeschichte von C. Da C++ eine Mischsprache aus C und OO Elementen ist, kann man alle Codes die in C geschrieben wurden auch in C++ einsetzen. Warum sich C durchgesetzt hat? Da kann ich nur Raten. Aber ich denke es liegt daran das man sehr CPU nah programmieren kann und das mit einer Hochsprache.[/cpp]
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

helium

Treue Seele

Beiträge: 180

Wohnort: NRW, Burscheid (nahe Köln)

  • Private Nachricht senden

22

16.09.2004, 17:23

Zitat

Ja. Allerdings gibts das "Design by Contract", wo die "sich selbst testende Klasse" ein wesentlicher Gesichstpunkt ist.

Auf Invarianten trifft das sicherlich zu. Vor- und Nachbedingungen könnten aber in allen Paradigmen verwendet werden.

Zitat

Die Begriffe "OO" und "Skriptsprache" haben für mich nichts miteinander zu tun, es gibt alle 4 Kombinationsmöglichkeiten.

Für mich auch nicht. Aber weder SmallTalk, noch Objective-C sind Scriptsprachen.

Zitat


Aber wenn ich den C-Tor Manuell aufrufen muss? Das empfinde ich als große schwäche.

Habe ich nie bestritten. Ich wollte es nur erwähnt haben.


Zitat


Man kann sich über die Syntax einer Sprache streiten. Sicher das obere Beispiel ist kürzer, aber für mich 0% verständlich, da ich die Sprache nicht kenne. Ob ein Code leserlich ist hängt nicht zu 100% von der Syntax ab, sondern es hängt zu 80% davon ab, wie gut man die Sprache kennt. Und der vergleich der Syntax der Sprachen hat zu 0% was mit diesem Thema zu tun. Ich könnt hier jetzt auch Perl reinwerfen und sagen, das ist mist.

Natürlich wurde von mir vorrausgesetzt, das man beide Sprachen kann. Und dann würde man ganz schnell feststellen, das die Synthax nur die Hälfte der Wahrheit ist. Auch die Vorgehensweise, die das in beinahe allen funktionalen Sprachen vorhandenen Pattern Matchings (hat nichts mit RegEx zu tun), macht den Code viel übersichtlicher und klarer.

Zitat


Najo das mag halt sein. Aber auch hier hat das absolut nichts mit diesem Thema zu tun. Die Typisierung von C und auch C++ hat hier etwas mit der CPU-Architektur zu tun. C wurde als Sprache konzipiert die sehr CPU nah sein sollte. Und da C die Basis von C++ ist, hat sich das eben durchgezogen.

Falsch verstanden. SML ist genau so statisch Typisiert, wie C und C++ und bietet beinahe die selben Typen an. Der Unterschied ist, das ich beinahe nirgendwo Typen angeben muss, da die Sprache (wie bei funktionalen Sprachen üblich, ist eben eine Sache des Paradigmas) die Typen prinzipiel selbst herleitet. Explizite Typangaben sind so gut, wie nie notwendig.

Zitat


Bei Variablen die zugleich eine Zahl oder auch ein String sein können, ist einfach nur störend.

Das klingt nach erfahrungen mit VB. Es geht aber nicht um schwache oder starke Typisierung, sondern um dynamische oder statische Typisierung.

Also ein Auto kann nur als Auto verwendet werden, nicht als Zahl oder String. Das es sich um ein Auto handelt steht bei dynamisch typisierten Sprachen allerdings erst zur Laufzeit fest.

Zitat


Und wenn ich so ein Dynamisches Ding haben will, dann kann ich mir so eines auch mit Sprachen wie z.B. C++ bauen

Nö. Das kannste in Objective-C und auch in Scriptsprachen, wie PHP (AFAIK erst ab Version 5), aber nicht in C++. Das ist absolut statisch.

Zitat


Wie das ganze nun aber dargestellt wird hängt wiederum von der Syntax ab und hat rein gar nichts mit OO zu tun.

Das hat nix mit der Synthax zu tun. Aber ich gebe dir recht, das es nicht ganz so viel mit der OO zu tun hat, vor allem wenn man sprachen wie SELF betrachtet, in der es nur Objekte, aber keine Typen gibt.

Zitat


Und wenn einem eine Sprache nicht gefällt dann sollte man sich eine andere suchen.

Ja, aber finde mal eine gute Sprache, die dennoch praxisrelevant eingesetzt werden kann. Meine Favoriten sind JMatch und Scala, da beide auf Java-VMs lauffähigen Code generieren.

DragonMaster

Community-Fossil

Beiträge: 1 603

  • Private Nachricht senden

23

16.09.2004, 17:49

Zitat

Natürlich wurde von mir vorrausgesetzt, das man beide Sprachen kann. Und dann würde man ganz schnell feststellen, das die Synthax nur die Hälfte der Wahrheit ist. Auch die Vorgehensweise, die das in beinahe allen funktionalen Sprachen vorhandenen Pattern Matchings (hat nichts mit RegEx zu tun), macht den Code viel übersichtlicher und klarer.
Es ist sicher sehr vorteilhaft wenn der Compiler einem einiges an Arbeit abnimmt. Dadurch kann man weniger Fehler machen, da der Compiler (wenn korrekt Implementiert) an jedem Symbol logisch vorgeht. Was man von einem Menschen nich behaupten kann.
Und wie gesagt. Es ist eine Sache der Syntax einer Programmiersprache und in diesem Falle auch eines des Übersetzers.

Zitat

Falsch verstanden. SML ist genau so statisch Typisiert, wie C und C++ und bietet beinahe die selben Typen an. Der Unterschied ist, das ich beinahe nirgendwo Typen angeben muss, da die Sprache (wie bei funktionalen Sprachen üblich, ist eben eine Sache des Paradigmas) die Typen prinzipiel selbst herleitet. Explizite Typangaben sind so gut, wie nie notwendig.
:) Akzeptiert. Nur eine Sache. Es ist zwar ein Standard von C/C++ das man auch immer den Typ mit angeben muss und wenn man ihn nicht angibt immer ein Ineger genommen wird. Aber man kann mit einem Compiler Feature in etwa das selbe machen wie in SML. Solange man einer Variable direkt einen Wert zuweist kann der Compiler auch erkennen um welchen Typ es sich handelt. Also z.B.

C-/C++-Quelltext

 
1
2
3

var1 = 0; // integer

var2 = 1.0; // double

var3 = 1.0f; // float
Bei Strings geht das wahrlich nicht. Da es keinen String-Typ in C/C++ gibt. Ich weis nicht wie das bei SML ist, aber mit einem Feature ist das sicherlich dann nicht so gut als wenn es ein fester bestandteil einer Sprache ist.

Zitat

Das klingt nach erfahrungen mit VB. Es geht aber nicht um schwache oder starke Typisierung, sondern um dynamische oder statische Typisierung.

Also ein Auto kann nur als Auto verwendet werden, nicht als Zahl oder String. Das es sich um ein Auto handelt steht bei dynamisch typisierten Sprachen allerdings erst zur Laufzeit fest.
VB ist nur einer der Übeltäter ;D

Zitat

Nö. Das kannste in Objective-C und auch in Scriptsprachen, wie PHP (AFAIK erst ab Version 5), aber nicht in C++. Das ist absolut statisch.
Hmm....sicherlich intern ist und bleibt es Statisch. Aber von aussen verhält sich ein solches Objekt wie ein dynamischer Typ. Das geht schon. Ist zwar was aufwand, aber machbar. Schnell ist der Typ natürlich auch nicht. Da man intern immer Konvertieren muss. Je nachdem was grad verlangt wird.
Aber ob nun selbst gemacht oder von der Sprache eingebaut. Intern sind alle Typen statisch. Hier macht es nur der Compiler für uns. Oder der Interpret. Auch wenn man es nicht sieht aber wenn man "123" hat und daraus 123 machen will, muss man konvertieren. Ob nu von Hand oder ob es die Sprache macht, ist am ende egal.
Was nun besser oder schlechter ist. Sei dahingestellt und ist auch reine geschmackssache.

Zitat

Ja, aber finde mal eine gute Sprache, die dennoch praxisrelevant eingesetzt werden kann. Meine Favoriten sind JMatch und Scala, da beide auf Java-VMs lauffähigen Code generieren.
Gute frage :) Eine absolute super Sprache wird es nie geben. Das ist mal sicher. Man muss sich halt raussuchen womit man gut umgehen kann.


Nun sollten wir aber langsam wieder zum Thema kommen ;) Sonst muss ich Patrick zu 100% recht geben.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

Werbeanzeige