Ich habe zunächst mal 5 Fragen über Programmiersprachen

JoelH

Geschmacksache, jedes Problem fordert eine Lösung.
Wenn sie falsch sind sind sie nicht gut. Was soll diese Frage ? We willst du eine differenzierte Meinung darauf verifizieren ?
ich finde es ist die Geschwindigkeit. Durch die abstrakte Sichtweise, die der Programmeirer allerdings bis aufs haar genau kennt entstehen keine Nachteile aber durchaus Vorteile.Ehrlcih gesagt ist es auch wieder Geschmacksache. Ich hasste struckturiertes Programmeiren als ich von c64Basic auf Pascal umstieg ich hasste OOP als ich von P auf C++ umstieg. Ich hasse irgendwas weil ich in RUBY meine Liebe gefunden habe .....
s.o. wie auch immer OOP bringt keinen schnellen Erfolg. zB. Java, dass ist eine Sprache wo man als Newbie mehr in den Vererbungstrees sucht als dass man mal eine Zeile Code selbst schreibt. Das frustriert. Ich fand es geil dass man c64 Basci innerhalb von 3 Min. verstanden hatte =>
10 Print"Joel"
20 goto 10
daran gibt es nichts was man nicht versteht wenn man zählen kann. OOP ist anders, da muss man erst die Idee verinnerlichen um zu verstehen was passiert. Das sit aber auch das Positive, man kann einfacher was abbilden was man kennt.
Es ist eine Frage der Sichtweise
k.a.

peterchen

Geschmacksache. Darüber könnte man leicht religiöse Kriege führen. Das kann man so nicht beantworten.

Na kommt schon - da gibt wes doch objektive Kriterien.

a) Elemente des Problembereichs lassen sich gut in de Programmiersprache umsetzen.
(Fortran hat Matritzen, C++ nicht. was nimmst du für Mathemathische Berechnungen?)

b) Ausdrucksstärke, Exaktheit "wasserdichte" Implementierung der Sprachelemente.
Das muß meistens mit Mächtigkeit ausbalanciert werden.
(Negativbsp: C akzeptiert viel - u.a. auch Tippfehler - als compilierbaren Code. Die "Typfreiheit" von Scriptsprachen

c) Die Programmiersprache unterstützt die benötigten Techniken (z.B. kann man in klassischem C sehr wohl Objektorientiert programmieren - nur ist das ziemlich unangenehm. OO ist in C möglich, wird aber nicht unterstützt ) Die Techniken wiederum hängen von äußeren Faktoren - z.B. Teamstruktur - ab.

d) Integrierbarkeit mit Entwicklungstools (IDE, Compiler, Debugger). Auch hier: was und wieviel gebraucht wird, hängt von Aufgaben und Umgebung ab

e) Produktivität
Das überlappt sich mit anderen Punkten, sollte aber nochmal separat erwähnt werden.

Warum/Wann sind Entwurfsmuster "gut", warum/wann "schlecht"?
Jedes Pattern ist erstmal nur eine Möglichkeit, mit de rman in der Vergangenheit gut gefahren ist. Eine gute Design-Pattern-Diskussion sollte Einsatzbereiche, Grund und die tragenden Nachteile von Alternativen nennen. (Hatte mal nen guten Link, aber der ist mir leider abhanden gekommen)
Ein Pattern ist gut, wenn es dein Problem ohne großen Mehraufwand löst (implementaiton + debuggen + dokumentation!), und dabei flexibel gegenüber Änderungen ist.
Was ist positiv/negativ an imperativen Programmiersprachen?
Imperative Programmiersprachen sind perfekt, wenn du gerne das Kommando hast, gern mal rumbrüllst und um jeden Sch*** dreimal kontrollierst, weil's sonst ja sowieso schiefgeht

Positiv (was mir so einfällt):
- Viele Algorithmen sind bereits in imperativer Beschreibung verfügbar (siehe 1a)
- Prozessorarchitektur ist imperativ - Modellierung nahe am problem: siehe 1a

Negativ:
- Vernachlässigung der Datenmodellierung
- Bei rein prozeduraler Implementation: der Komplexität größerer Projekte nichtgewachsen (sind bei C glaub ich in der Größenordnung von 10.000 zeilen)

Was ist positiv/negativ an objektorientierten Programmiersprachen?
Hier müßte man vielleicht stärker zwischen OO-Sprachelementen und OO-Modellierung unterscheiden. aber ich versuch's mal in einem Topf:
sehr flexibles, mächtiges Modellierungswerkzeug das sich auf viele Problembereiche anwenden läßt. Die "klassische" Modellierung ist aber zu starr für heutige Anforderungen. Man stößt bei etwa de rzehnfachen projektgröße auf ähnliche Probleme wie bei Prozeduraler programmierung.
(speziell C) Was sind die Nachteile/Vorteile von C?
Machinennähe. Kurz und knapp, aber nicht sehr klar. Schlecht zu parsen.

Bashar

peterchen schrieb:

Geschmacksache. Darüber könnte man leicht religiöse Kriege führen. Das kann man so nicht beantworten.

Na kommt schon - da gibt wes doch objektive Kriterien.

Nö. Es gibt Anforderungen, die man hat. Wenn man eine Schraube in die Wand kriegen will, kann man das mit einem Hammer versuchen. Könnte aber sein, dass das Ergebnis nicht wirklich ansprechend ist. Ist deshalb ein Hammer schlecht? Ist ein Schraubenzieher gut?

Negativ:
- Bei rein prozeduraler Implementation: der Komplexität größerer Projekte nichtgewachsen (sind bei C glaub ich in der Größenordnung von 10.000 zeilen)

Jo, aber es war nach imperativ, nicht nach prozedural gefragt. OO ist idR auch imperativ.

(speziell C) Was sind die Nachteile/Vorteile von C?
Machinennähe. Kurz und knapp, aber nicht sehr klar. Schlecht zu parsen.

C++ ist genauso maschinennah wie C. Ada ist wahrscheinlich näher. Aber AFAIK besser zu parsen. C ist sehr klar ... jede Anweisung sagt direkt, was sie tut. a+b ist nur eine Addition, Foo bar; reserviert nur Speicher. In C++ ruft ersteres abhängig von den Typen von a und b einen beliebig komplexen benutzerdefinierten operator+ auf, zweiteres ruft einen beliebig komplexen Konstruktor auf ... du hast also lauter Wölfe in Schafspelzen, in C nur Schafe. Oder nur Wölfe, wie mans nimmt
Ich persönlich bevorzuge Sprachen, die Abstraktion, die über prozedurale Abstraktion hinausgeht, erlauben. Aber für andere, beispielsweise für den Linux-Kernel, ist genau diese Eigenschaft von C eins der wichtigsten Kriterien.

peterchen

Wenn man eine Schraube in die Wand kriegen will, kann man das mit einem Hammer versuchen. Könnte aber sein, dass das Ergebnis nicht wirklich ansprechend ist. Ist deshalb ein Hammer schlecht? Ist ein Schraubenzieher gut?

Natürlich hängt das "gut" oder "schlecht" von den Anforderungen ab - was für eine Schraube, was für eine Wand. Ich dachte, dem eigentlich nicht widersprochen zu haben. Nur halt ein "kommt drauf an" ist halt ein bißchen mager. Ein Schraubenzieher ist schlecht für eine Ziegelmauer.

es war nach imperativ, nicht nach prozedural gefragt. OO ist idR auch imperativ

Schon klar, deswegen hab ich ja auch "Bei rein prozeduraler Implementation" gesagt - da die Frage auch nach nem "im ggs zu OO" klang.

C++ ist genauso maschinennah wie C.

Von den Sprachelementen ja. Von der Denkweise nein. Maschinennähe war ja als "sowohl positiv als auch negativ" gemeint.
C ist insofern schlecht zu parsen, als da eine Menge "Meta-Information" nicht aus dem Quelltext selbst ersichtlich ist und damit nicht extern nachvollziehbar / nutzbar. "analysieren" wäre vielleicht ein besseres Wort gewesen.

Spacelord

peterchen schrieb:

...

c) Die Programmiersprache unterstützt die benötigten Techniken (z.B. kann man in klassischem C sehr wohl Objektorientiert programmieren - nur ist das ziemlich unangenehm. OO ist in C möglich, wird aber nicht unterstützt ) Die Techniken wiederum hängen von äußeren Faktoren - z.B. Teamstruktur - ab.

...

Das ist so nicht richtig!
Man kann mit C objektorientierte Programmierung simulieren,aber wenn es darauf ankommt die Vorteile der OOP zu nutzen versagt C!! Zum Beispiel die Polymorphie.
Da sind in C Fallunterscheidungen angesagt die in der OOP nicht erwünscht sind und weitestgehend auch nicht benötigt werden.

MfG Spacelord

peterchen

Zum Beispiel die Polymorphie

typedef int (*tFunc)(void * obj);

typedef struct
{ 
   tFunc * pFunc;
} A;

typedef struct
{
   struct A baseA;
   // other members
} B;

int A_Func_Impl(void * obj)
{
  printf("A_Func\n");
}

int B_Func_Impl(void * obj)
{
  printf("B_Func\n");
}

void A_Init(void * obj)
{
   A * pA = obj;
   pA->pFunc = A_Func_Impl;
}

void B_Init(void * obj)
{
  B * pB = obj;
  pB->baseA->pFunc = B_Func_Impl;
}

int A_Func(void * obj)
{
   A * pA = obj;
   return pA->pFunc(obj);
}

void main()
{
  A a; A_Init(&a);
  B b; B_Init(&b);

  A * pA = &a;
  A_Func(pA);

  A * pB = &b;
  A_Func(pB);
}

Wenn du mehrere virtuelle methoden brauchst, kannst du genauso eine VMT einführen wie in einer C++ - Implementation.

Es geht. Es ist nur unangenehm.

Dann deklarier doch mal einen Typ A. B und C sind Subtypen von A.
Jetzt legst du ein Array mit A Typen an das mit B und C "Objekten" gefüllt wird.
Jetzt führst du eine "virtuelle" A Methode auf den Objekten des Arrays aus.
Wie machst du das mit C ohne Fallunterscheidung?

Gregor

peterchen schrieb:

Es geht. Es ist nur unangenehm.

...und unglaublich dumm. Wenn man schon Objektorientierung haben möchte, dann sollte man auch eine Sprache wählen, die dies entsprechend unterstützt. Wenn man es anders macht, zeigt man nur, dass man keine Ahnung von den Werkzeugen hat, die einem zur Verfügung stehen.

(IMHO)

peterchen

Wenn man es anders macht, zeigt man nur, dass man keine Ahnung von den Werkzeugen hat, die einem zur Verfügung stehen.

Genau meine Rede. Ich meine nur: es gibt objektive Kriterien, nach denen man die Brauchbarkeit einer Programmirsprache für einen bestimmten Aufgabenbeeich analysieren kann - und davon ausgehend: auch bewerten kann welche Konzepte einen größeren problembereich abdecken.

@Spacelord:
Was ist da da Problem? An obigen Code anknüpfend -

typedef struct { A baseA; } C;

int C_Func_Impl(void * obj) { printf("and C, you see?\n"); }
C_Init(void * obj) {  B * pB = obj;    pB->baseA->pFunc = C_Func_Impl; }

void main()
{
  A * array[3];  // Array of A pointers

  array[0] = malloc(sizeof(A));  // initialize an A instance
  A_Init(array+0);

  array[1] = malloc(sizeof(B));  // initialize a B instance
  B_Init(array+1);

  array[2] = malloc(sizeof(C)); // initialize a C instance
  C_Init(array+1);

  for(int i=0; i<3; ++i)  // iterate through the items
  { 
     A_Func(array+i);     // Watch the magic happen
  }
}

peterchen

Vielleicht noch mal meine Motivation: Ich will noiemandem verklickern, er soll in C OO-proggen.
Aber man sollte sich mal genau anschauen, ob man in seinem C++ nicht manchmal genau den gleichen Mist macht...