Hallo CMБ,
Die Frage ist dann allerdings, ob diese „Gestaltung nach …“
auch gelungen ist ?
Ich finde im grossen und ganzen schon, zumindest ist Pascal recht pingelig.
OK, die implementierung von Zeigern ist stellenweise etwas undurchsichtig und bei Funktionen mit variabler Parameterzahl hat N. Wirth auch etwas gemurkst, bei einigen System-Funktionen ist es ja möglich (z.B. writeln() ).
Pascal geht sehr streng mit den Datentypen um und erzieht
dadurch zu einem unterscheiden dieser.Nun gut, Pascal ist ja per Absicht als eine
streng typisierte Sprache entstanden, um ein
günstiges Laufzeitverhalten auf (damals) zeitge-
nössischer Architektur zu haben.
>>Soweit mit bekannt, war das kein grundlegender Gedanke von Wirth, sondern die Idee war zu erzwingen, dass Datentypen explizit konvertiert werden. Zudem lief UCSD-Pascal auf einer virtuellen Maschine. Dadurch musste nur der P-Code Interpreter auf eine andere Hardware portiert werden. UCSD-Pascal war ja eigentlich ein ganzes Betriebs-System, nicht nur ein Pascal-Compiler… Ist aber schon lange her. Übrigens hat damals ein Halbleiterhersteller (IMHO Western Digital, Irgendwo habe ich noch das Handbuch) versucht eine CPU für den UCSD-P-Code zu entwickeln, aber ausser ein paar Prototypen, welche nur leidlich funktionierten ist daraus nichts geworden.
Die Datentypen in Pascal sind dabei *exakt* die
zugrundeliegenden Gegebenheiten der Maschine,
also wie in C - wobei Pascals String-Typ die einzige
vorsichtige Abstraktion darstellt.
Sorry, aber das stimmt nicht. Integer waren immer 16 Bit. Schau doch mal in den Anhang von K&R, da steht geschrieben was C alles an Datentypen, je nach CPU, unterstützt. Da sind so komische Dinge wie 9-Bit char und 36-Bit Integer darunter. Soetwas hat Pascal nie unterstüzt.
Ganz gefährlich ist in diesem zusammenhang z.B.
BASIC, welches es normalerweise zulässt einen
Integer einer Stringvariablen zuzuweisen.Das halte ich gar nicht für gefährlich. Nur dann,
wenn die Prämisse „Maschinennähe“ lautet, ist so etwas
bestenfalls ineffizient.
Ich halte es für gefährlich, solange man nicht weiss was man da tut, was bei Schülern meist noch der Fall ist. Man gewöhnt sich da leicht einen schlechten Stil an, welcher dann bei einer anderen Programmiersprache zu „wundersamen“ verhalten der Programme führt.
Spätestens bei C lässt dies zwar der Compiler noch
zu, aber zur Laufzeit geschehen dann verwirrende Dinge.Verwirrend? Eigentlich nicht. Dann hast
Du einen Zeiger!? Dachte ich?
getchar() reicht da schon. 
)Viele Programmierer vergessen, dass getchar() & Co. eigentlich einen int liefern um einen Fehlerstatus liefern zu können:
char c;
c = getchar();
if ( c == EOF ) … ups !!
Pascal ist zwar sehr geignet das Programmieren zu lernen, hat
dann aber seine Grenzen, wenn es um praktische Programme geht.Das finde ich eigentlich auch nicht. Seinerzeit zum Ende
des Studiums (lang ist’s her) habe ich (learning by doing)
eine „größere“ Anwendung in Turbo-C/BGI geschrieben, ein
Kommilitone hat als „Konkurrent“ eine ähnliche Anwendung
in Turbo-Pascal/BGI gebaut. Beide Programme konnten
schöne Dinge und waren ziemlich umfangreich
Ich habe auch einige Jahre in Pascal (UCSD und Turbo-Pascal [CP/M und MS-DOS] ) Projekte programmiert und gepflegt, somit kenne ich die Limiten der Sprache.
Wie ich leider immer wieder bewiesen bekomme, ist C/C++ eine
Sprache für „Erwachsene“. Vieles was in C zulässig ist, sollte
nicht in jedem Fall auch gemacht werden. Gerade wenn Programme
auf unterschiedlichen CPUs laufen sollen, zeigt sich ob jemand
verstanden hat wie eine CPU arbeitet oder nicht (z.B.
Big/Little Endian, unterschiedliche grössen von int,
unterschiedliche Speicherbelegung von structs, usw.). Viele
Laufzeitprobleme entstehen auch schon beim Mischen von
signed/unsigned.Ja, aber das ganze Spiel macht man, weil die
Prämisse existiert, ein bestimmtes Problem mit
maximaler (Maschinen-)Geschwindigkeit zu lösen.
Ist dies nicht nötig, wäre es imho ausgesprochen
ungünstig, ein komplexes Programm in C zu schreiben.
Das geht zwar (hab ich selber früher genug gemacht),
aber die Produktivität ist sehr niedrig und die
Wartbarkeit (Robustheit) gerade bei C „verschwindend“.
Gerade der letzte Punkt hat sehr viel mit Disziplin zu tun, man kann selbst in Assembler wartbare Programme schreiben
P.S. Seit 20 Jahren gehöre ich zum C-Lager. Angefangen habe
ich vor über 30 Jahren mal mit BASIC auf einem Wang 2200VT,
dann kam 6502-Assembler und jede menge anderer
Programmiersprachen.Ich finde „schwache Typisierung“ für die entsprechende
Problemdomäne gar nicht schlecht, - dadurch sind
„generische Konzepte“ bereits kostenlos „mit“ zu haben, -
etwas, wofür man bei sinnvoll (C++ usw.) typisierten
bzw. unsinnig (Java usw.) typisierten Sprachen große
Bibliotheken und/oder Basteleien hinzuziehen muß
Mein Hauptbereich liegt bei MicroControllern, also „Systemprogrammierung“, dann kommen meist noch die Oberflächen auf einem PC hinzu, da verwende ich Teilweise C, weil ich dadurch Module auch auf dem PC verwenden kann. Der Rest ist dann meist C++ oder VB.
MfG Peter(TOO)
