Ich habe zunächst mal 5 Fragen über Programmiersprachen

1. Wann ist eine Programmiersprache "gut", wann "schlecht"?
2. Warum/Wann sind Entwurfsmuster "gut", warum/wann "schlecht"?
3. Was ist positiv/negativ an imperativen Programmiersprachen?
4. Was ist positiv/negativ an objektorientierten Programmiersprachen?
5. (speziell C) Was sind die Nachteile/Vorteile von C?

Max M.

Hi!

Zu deiner ersten Frage: Das kann man so nicht beantworten. Es kommt ganz darauf an, was man haben will. Das eine Programm kann man mit der einen Sprache besser schreiben und ein anderes Programm wiederum mit ner anderen Sprache.

Bashar

1. Darüber könnte man leicht religiöse Kriege führen. Jede Sprache hat Vor- und Nachteile, auch wenn man die nicht sehen will. Ich kann beispielsweise VB absolut nichts abgewinnen, andere schätzen sie gerade, weil salopp gesagt jeder Depp damit in kurzer Zeit ansprechend aussehende Windowsapplikationen schreiben kann.

2. Entwurfsmuster können nicht gut oder schlecht sein. Man kann sie höchstens falsch verstehen und in der falschen Situation anwenden.

3. Positiv: Geschwindigkeit. Einfach zu verstehen, wenn man kapiert hat, wie ein Computer funktioniert. Die besten Compiler existieren für imperative Sprachen (C, C++, Fortran) Negativ: Imperative Programmierweise erschwert die theoretische Betrachtung von Programmen, erschwert das Verstehen komplizierter Abläufe, und verbaut einem einige interessante Entwicklungen im Bereich des Sprachendesigns.

4. Hierzu sagt man besser nichts. OO ist ein Hype. Was nicht heißt dass OO schlecht ist, aber es gibt hier die unterschiedlichsten Behauptungen über Vorteile, die sich bei näherer Betrachtung in Luft auflösen.
BTW ist objektorientiert nicht das Gegenteil von imperativ, falls du das mit dieser Fragestellung implizieren wolltest.

5. Krieg ich auf die Schnelle nicht zusammen, ausserdem geht das wieder in die Richtung der ersten Frage. Fakt ist, dass C eine der bekanntesten und gebräuchlichsten Sprachen überhaupt ist, dass sehr viele neuere und bekannte Sprachen in der einen oder anderen Weise direkt oder indirekt auf C basiert (C++, Java, C#, Javascript, PHP, Perl ...) dass so gut wie jedes Betriebssystem in C geschrieben ist, und dass es die Haussprache von Unix ist. Fakt ist aber auch, dass C extreme Anforderungen an Programmierer stellt, die in der Praxis meistens nicht gegeben sind.

1 & 2:

du stelltst die falsche frage: eine programmiersprache oder ein entwurfsmuster kann nicht gut oder schlecht sein. sie bzw. kann nur mehr oder weniger zweckmässig für ein bestimmtes problem sein.

3 & 4

siehe oben; für manche Anwendungsgebiete ist oo einfach nicht praktikabel....für andere hingegen einfach unschlagbar.

5

Vorteil: C-Code ist an Ästhetik nicht zu überbieten.....das ist wie Lyrik. Einfach nur ehrlich und direkt.
Nachteil: Gibts nicht......obwohl.....einen gibts, metaprogrammierung (also die Modifikation eines Programms durch sich selbst während der Laufzeit) lässt sich nicht ganz so toll in C realisieren.

Ich hoffe ich konnte Dir damit etwas helfen

ich wollte in dem letzten abschnitt nicht sagen, dass Lyrik "ehrlich und direkt" ist.........;der eindruck entsteht wohl beim lesen. also nicht falsch verstehen......C ist so ästhetisch wie Lyrik.
anderer punkt: im vergleich zu vielen anderen sprachen (z.B. oo), ist C ehrlich und direkt.

Bashar

icke schrieb:

Vorteil: C-Code ist an Ästhetik nicht zu überbieten.....das ist wie Lyrik.

Offensichtlich Geschmackssache.

Einfach nur ehrlich und direkt.

Ebenso. Mangelhafte Abstraktionsmöglichkeiten sind nicht pauschal von Vorteil.

Gregor

Bashar schrieb:

icke schrieb:

Vorteil: C-Code ist an Ästhetik nicht zu überbieten.....das ist wie Lyrik.

Offensichtlich Geschmackssache.

Genau, das ist Geschmackssache und ich vertrete jetzt auch gleich mal die Gegenmeinung. Ich habe noch keinen C-Code gesehen, der auch nur ansatzweise als ästhetisch bezeichnet werden könnte. Meistens ist es eine Qual, C-Code zu lesen. Ich habe jetzt einfach mal nach C-Code gegoogelt und habe u.a. folgende Codes gefunden:

(hier stand eben noch der Code, ich habe mich aber dazu entschlossen, ihn rauszunehmen. Begründung: siehe unten)

Ich lasse mich natürlich gerne davon überzeugen, dass C-Code doch ästhetisch ist. Wie wäre es, wenn mir jemand die Ästhetik von C an den oben gezeigten Beispielen erläutert.

IMHO kann z.B. guter C++-Code sehr viel ästhetischer sein als C-Code.

Bashar

Was soll das bringen? Einfach wahllos rumgugeln und ein paar schlechte Beispiele posten kann jeder, das bringt uns eher in Richtung Flamewar.

Gregor

Bashar schrieb:

Was soll das bringen? Einfach wahllos rumgugeln und ein paar schlechte Beispiele posten kann jeder, das bringt uns eher in Richtung Flamewar.

Ok, hast Recht. ...ich werde die Beispiele gleich mal rausnehmen und gebe den anderen die Möglichkeit, Beispiele zu finden, die an Ästhetik kaum zu übertreffen sind.

Taurin

Hab ich gerade in nem C-Skript gelesen:
Die Beführworter von C halten den Code für kurz und prägnant und loben die
vielen Möglichkeiten, die C bietet.
Die Gegner von C halten den Code für zu kurz und kryptisch und kritiesieren
die vielen Fallstricke, die C durch seine vielen Möglichkeiten bietet.

Ein Krieg, der noch die nächsten Jahrzehnte toben wird

Gregor

Taurin schrieb:

Hab ich gerade in nem C-Skript gelesen:
Die Beführworter von C halten den Code für kurz und prägnant und loben die
vielen Möglichkeiten, die C bietet.

1. C bietet nur sehr wenige Möglichkeiten, sich auszudrücken. C++ hat zum Beispiel viel mehr Sprachmittel, die einem weitere Möglichkeiten bei der Programmierung eröffnen.

2. Ich bezweifele, dass C-Code besonders kurz und prägnant ist.

1. Wann ist eine Programmiersprache "gut", wann "schlecht"?

Vielleicht ist diese dann gut, wenn man nach Monaten sein eigenes Programm noch in Details versteht. Eine gute Programmiersprache sollte also vor allem lesbar sein. C erfüllt dies nicht, C++ schon eher.

DrGreenthumb

C ist mehr das krasse Gegenteil von "kurzem Code" und Vorteile sehe ich in der Sprache überhaupt keine...

Ich meine so aus Programmiertechnischer Sicht, da ist dass doch eher zum Heulen.

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?