Welche Programmiersprache ist die richtige?

[Christian Kruse]

Hallo MichaelB,

Dafür sind viele Dinge in C katastrophal gelöst.
Und viele Dinge sind in Pascal so gar nicht möglich.
Das musst Du mir mal näher erklären. Beide sind Turing-complete. Was soll also in C
möglich sein was in Pascal nicht möglich ist?

Ein String länger als X. Ich sage extra: ein String. Wenn ich mit Pointern arbeite, bin
ich wieder bei C-Zuständen.

Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.
Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.
Ja ich kann und MUSS es selber tun. Für mich ein Rückschritt ohne Zwang.

Die Philosophie von C ist Minimalismus. Wenn dir das nicht gefällt, wähle eine andere
Sprache.

In Pascal kann ich sagen Array[5..15] usw.
Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.
Ohne vernüftige Begründung bleibt das eine Aussage auf dem Niveau wie  "Windows ist für
DAUs und Linux für Profis".

Pascal wurde als Lehr-Sprache entwickelt. Dementsprechend ist das Abstraktionslevel,
die Syntax und dementsprechend ist der Aufwand, den man betreiben muss, wenn man bestimmte
Konstrukte erreichen will.

C ist nicht als Lehrsprache entwickelt worden. C ist eine Sprache für Programmierer. Das
merkt man sowohl an der Syntax als auch an den Freiheiten und dem Abstraktions-Grad.

falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Das ist bei C genau so:
char array[100];
Fängt bei 0 an, hört bei 99 auf.
Was ich meinte (so schrieb ich es auch), dass es eben beim hinschauen nicht klar ist

Es ist auf den ersten Blick klar. Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.

Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.

Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.
Irgendwie sehe ich nicht den rechten Sinn in dieser Trennerei (wegen der Übersichtlichkeit
dafür gibts moderne IDEs).

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE. Ich schaue in die
Header-Datei, wenn ich etwas wissen will.

Allenfalls das besch* Konzept von C macht dies manchmal notwendig (ohne dabei irgendein
Benefit zu liefern).

Das Konzept ist hierbei dasselbe wie bei Pascal. Zeilenweises kompilieren. Wie gesagt, in C
sind es Prototypen und in Pascal waren es forward-Deklarationen. Kein Unterschied.

BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.
Das ist allerdings richtig. Nur nützt mir das wenig, wenn ich vorhandenen Code übernehmen
muss. Weil landläufig wird diese Trennung vorgenommen.

Sie ist ja auch durchaus sinnvoll. Das nennt man in der hiesigen Lehrsprache das
'Geheimnisprinzip'.

C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.
Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.
Stimmt. Das war zumindest unter Turbo Pascal so.

Das war nicht nur unter Turbo Pascal so.

Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen
Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.
Falsch. Zumindest die Implementierung in Turbo Pascal war es so, daß die Länge am Anfang
des Strings gespeichert wurde.

Turbo Pascal ist kein Massstab.

(was auch nicht gerade positiv für die Perforamce ist).
Zähle halt mit.
Brauch ich ja wieder eine extra Variable. Wofür? Wo es mir doch andere Sprachen wesentlich
einfacher machen.

Die machen es genau so: entweder mitzählen oder jedesmal neu zählen. Davon mal ab hält dich
keiner davon ab, einen eigenen String-Baukasten zu schreiben. Das ist ganz einfach. Schau
dir den Source dieses Forums an.

[... switch ...]
Sorry. Aber das ist ja noch länger. *kopfschüttel*

Die Länge ist unerheblich.

Das fehlen von Bereichen macht Programme fehleranfällig.
Das ist nun wirklich aus der Luft gegriffen.
Wieso? Ein konkretes Beispiel habe ich gleich mitangegeben:
In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
In C müsste ich ein int nehmen und müsste sämtliche Bereichsüberprüfungen von Hand machen.

Und wo ist das bitte sehr fehleranfällig?
Nein, sags mir nicht, die Buzzwords sind und bleiben immer die selben.

Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!
Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di
Doch. Der C-Compiler vergibt implizit Nummern sofern nicht eine eigene angegeben ist.

Das sagte ich dir gerade. Es ist nur nicht definiert, welche Nummer er vergibt. Statt 2
könnte er auch eine beliebige andere Zahl aus dem int-Zahlenraum nehmen. Einzige Bedingung,
die gestellt wird: sie müssen direkt aufeinander folgen.

auswählt. Wenn du sichergehen willst, dass Di mit zwei indiziert wird, musst du die
Definition wie folgt ändern:
[Quelltext]
Toll. Nur das es überhaupt nicht das ist, was ich haben will.

Du hast nicht verstanden, warum ich dir das geschrieben habe. Macht nix. Lies mein Posting
einfach nochmal.

Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.
Ich beklage mich auch nur darüber, daß C einem es unnötig(!) schwer macht.

Wenn dir diese Philosophie nicht gefällt, wähle eine andere Sprache. Gibt genug.

Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C.
Schon die Strenge Typisierung in Pascal vermeidet viele Probleme (das ist auch der Grund,
warum man das in Java wieder eingeführt hat).

Das ist doch Humbug. Die Typisierung ist in Pascal gleich wie in C. Arbeite ich mit
Pointern, kann ich mich über jede Typisierung hinwegsetzen. Tue ich das nicht, muss ich
mich dran halten. Pascal wie C.

Die weitaus meisten Fehler (und damit Sicherheitslücken) die in Programmen auftreten
liegen nicht nur daran, daß C so verbreitet ist sondern an den teilweise kaputten Konzept.

Belege?

Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.
Pointer brauche ich immer, wenn ich mit Arrays dynamischer Größe (also praktisch Listen)
arbeite.

Nein. Siehe PHP, Perl, Ruby, Python, Java, etc, pp.

Aber üblicherweise implementiert man sowas einmal (falls nicht sogar schon in einer
Bibliothek vorhanden) und verwendet es dann nur noch.

Dann mach das doch. Weder in C noch in Pascal hält dich etwas davon ab.

Grüße,
 CK