"C" versus Pascal

[ATS3788]

Hallo
Ich lerne zu Zeit "C" Nicht C++, wegen µC Programierung.
Also ich verstehe nicht warum "C" die Erfolgs Sprache wurde.
so was wie "i++" oder "+=" oder Bit Manipulation hätte man
auch in Delphi umsetzen können. OK der Header das ist eine
tolles feature. Nur Pascal ist einfach eleganter,
alleine nur die String Behandlung in "C"
Mich würde interessieren was eure Erfahrung zu meiner Frage
"C" versus Pascal
ist.

PS
Versteht mich nicht falsch "C" ist ein tolles Werkzeug für
µC "Pics"

[Popov]

Also (das ist nur meine persönliche Kenntnis und Meinung) ist C (wie auch einige andere Programmiersprachen) eigentlich nur ein Unfall der Geschichte. C hätte es gar nicht geben dürfen und es war nicht geplant (ähnlich wie Pascal, das eigentlich nur als Lehrsprache konzipiert wurde). Ich weiß es nicht ganz genau, aber vor C soll es A und B gegeben haben. Danach kommt C. Schon die einfache Nummerierung zeigt, dass das eigentlich nicht als etwas erfolgreiches geplant war, sonst hätte man dem Ganzen einen guten Namen gegeben, wie man es auch bei Basic, Pascal, Java usw. tat. So wie ich das mal erfahren habe wollte man eigentlich nur Unix programmieren und es fehlte eine vernünftige Sprache. Pascal gab es noch nicht, Basic (na ja), und Assembler auf Dauer ist ja auch kompliziert. Also bevor man Unix schrieb, hat man sich erst eine Programmiersprache entwickelt. Und weil nicht geplant war, dass Menschen in Zukunft damit zu tun haben werden, hat man es einfach gemacht. Genau so als wenn man eine Funktion auf die Schnelle schreibt und den Variablen so viel aussagekräftige Namen wie - i, a, c, k, tv, ux und q gibt. Es ist ja nicht geplant, dass es jemand anders liest, also gibt man sich auch nicht die Mühe. Das hat man sich auch nicht bei C gemacht. Es sollte nur eine Sprache für den Auftrag werden, die einfacher als Assembler ist aber fast genauso mächtig.

Also wurde schnell etwas zusammengeklopft und ein völlig bedeutungsloses Betriebssystem namens Unix erschaffen. Denn auch das war nicht auf Erfolg konzipiert. Und eigentlich ist es das gewesen. Eine Firma brauchte ein Betriebssystem, also sollte eins geschrieben werden. Man nannte es Unix. Und weil eine passende Programmiersprache fehlte hat man vorher C als vorläufiges Hilfswerkzeug entwickelt.

Nur dann kam etwas womit keiner gerechnet hat - der Erfolg. Und der kam so: entweder war man früherer lockerer drauf oder die Angst vor Raubkopien war noch nicht da, verteilte man Unix auf den Unis zu Studienzwecken. Nutzung war nicht erlaubt (ohne zu bezahlen) aber man durfte es frei studieren. Das hatte noch einen schönen Nebeneffekt - es wurden viele Fehler gefunden, so dass man sie schnell reparieren und Unix wurde dadurch ein richtig stabiles Betriebssystem. Es war fast so wie es heute mit Open Source ist, nur das Unix kein Open Source im eigentliches Sinne war, sondern man nichts dagegen hatte, dass die Studenten es studieren. Das nebenbei die Fehler ausgemerzt wurden, war ein netter Nebenerfolg. Ja, und nun zurück zu C. Da Unix in C geschrieben war und es irgendwann an vielen Unis üblich wurde Unix zu studieren, konnten bald viele Studenten C ganz gut. Und nachdem die fertig mit dem Studium waren, haben sie einfach weiter mit C gemacht.

Also, hätte man gewusst, dass C so ein Erfolg wird, man hätte sich vermutlich mehr Mühe gegeben. Das ist aber wie so oft im Leben, man hat ein Problem in der Firma, man kommt irgendwie nicht in die Ecke ran, wo ständig die Kugelschreiber hin rollen, also holt man sich ein Stöcken vom Sperrmüll auf der Straße. Und dann bleibt es im Büro und entwickelt sich über Jahre zum Universallwerkzeug. Jeder stochert damit in seiner Ecke rum. Und dann sagt man sich - hätte ich das gewusst, dann hätte ich mir einen guten Stock bei Obi besorgt. Stadtessen haben wir nun eine abgebrochene Querlatte von einem Schrank hier.

Also das ist meine Geschichte zu C.

[Der schöne Günther]

Zitat:

Brian and I had just started working with an early release of Pascal from Professor Nichlaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power.

[...]

When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:

Code:

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

http://www.gnu.org/fun/jokes/unix-hoax.html

[Namenloser]

Hatte zufälligerweise gerade vor ein paar Tagen noch einen Text von Niklaus Wirth gelesen, mit einem interessanten Seitenhieb auf C:

Zitat:

Zitat von Niklaus Wirth

This new compiler, written in Pascal, could not be tested during development, because no Pascal compiler was available yet. The whole program for compiling at least a very substantial subset of Pascal, had to be written without feedback from testing. This was an exercise that was extremely healthy, and it would be even more so today, in the era of quick trial and interactive error correction. After we believed that the compiler was “complete”, one member of the team was banned to his home to translate the program into a syntax-sugared, low-level language, for which a compiler was available. He returned after two weeks of intensive labor, and a few days later the first test programs were compiled correctly by the compiler written in Pascal. The exercise of conscientious programming proved to have been extremely valuable. Never contain programs so few bugs, as when no debugging tools are available!

Thereafter, new versions, handling more and more of Pascal’s constructs, and producing more and more refined code, could be obtained by bootstrapping. Immediately after the first bootstrap, we discarded the translation written in the auxiliary language. Its character had been much alike that of the ominous low-level language C, published a year later. After this experience, it was hard to understand that the software engineering community did not recognize the benefits of adopting a high-level, type-safe language instead of C.

[Furtbichler]

Zunächst einmal: Das was Popov in den Tiefen seines Gedächtnisses herausgefischt hat, stimmt soweit (jedenfalls, wenn ich das mit dem Zeugs korreliere, was sich in den Niederungen meines Gedächtnisses befindet).

'C' ist ein etwas besserer Macroassembler: Eine Zuweisung hinterlässt das Ergebnis meist auf dem Stack und so ist auch 'a = b+c' ein Ausdruck, mit dem weiter gerarbeitet werden kann: 'if x == a=b+c'. Praktisch. Damit war in den frühen 70er Jahren eine Programmiersprache/Makroassembler entwickelt, mit dem sich sehr kompakte und schnelle Programme schreiben ließen.

Kernighan und Ritchie haben bei Unix das Ziel verfolgt, das sich das OS ruhig verhält und den Spezialisten, die es bedienen, so wenig wie möglich auf den Sack geht. Wenn also etwas funktioniert, wollten sie kein 'Operation Successful' sehen. Ähnlich wurde 'C' konzipiert: Sie viel wie möglich sollte machbar sein und Spezialisten (eben die beiden) wollten mit wenig Zeichen viel ausdrücken: In 'C' kann man sehr kurze Programme schreiben, ohne überflüssigen Schnickschnack wie 'var','then', 'procedure', 'function', 'do', 'begin', 'end' usw. Unlesbarer werden die Programme damit ja nicht.

So und nun meine Theorie: Da die meisten Programmierer Abkürzungsfetischisten sind (anders kann ich mir die bescheuerten Bezeichner 'ptr' 'chr' sowie die ungarische Notation nicht erklären) fanden viele diese Sprache natürlich total cool, denn wer meinen Code nicht versteht, ist eben nicht so cool wie ich. Blöderweise lässt der C-Compiler so ziemlich jeden Murks durchgehen, weswegen extra Lint entwickelt werden musste, das den gröbsten Quark moniert.

Lustig finde ich, das C-Programmierer beinahe zwnghft Abk vw. Alleine dafür gehört C verboten. Oder die Programmierer umgeschult. Auf Gesetzestextautoren :mrgreen:

Man kann in C allerdings auch hervorragend lesbaren Code schreiben. Wenn man will. C ist durch seine fehlende Strukturierung (kein Unit-Konzept, Klassen etc.) nur für kleine Projekte geeignet. Wenigstens durch die Header-Dateien hat man in Ansätzen das Unit-Konzept von Pascal eingefrickelt.

Fazit: Man sollte C können, wenn man mitreden will, und für µC und den hardwarenahen Bereich allgemein ist es eh Standard. Man muss ja nicht der Abkürzeritis und der Endloscodezeilenverwurst verfallen.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242193)

Fazit: Man sollte C können, wenn man mitreden will, und für µC und den hardwarenahen Bereich allgemein ist es eh Standard. Man muss ja nicht der Abkürzeritis und der Endloscodezeilenverwurst verfallen.

Was ich da so in Delphi schon gesehen habe...
C macht es zwar deutlich einfacher unlesbaren Code zu schreiben, aber es gibt genug Programmierer, die das auch in Delphi schaffen.

[BUG]

Zitat:

Zitat von Furtbichler (Beitrag 1242193)

'C' ist ein etwas besserer Macroassembler:

C war ein besserer Makro-Assembler. Wer einmal in den Unix V6 Quellcode (siehe Internet) gesehen hat, wird das bestätigen. Besonders die Structs ... gruselig.
Auch der Abkürzungswahn hatte Gründe, die z.B. bei den Linkern zu suchen waren. Nach 6-8 Stellen war denen der Rest des Namens egal.
Das war gestern.

Heute kenne ich keine Stelle z.B. in der Typsicherheit, wo modernes C wirklich Nachteile gegenüber Pascal hätte.

[vagtler]

Zitat:

Zitat von jaenicke (Beitrag 1242206)

[...] C macht es zwar deutlich einfacher unlesbaren Code zu schreiben, aber es gibt genug Programmierer, die das auch in Delphi schaffen.

A bad programmer can write C in any language! :mrgreen:

[Luckie]

Die ungarische Notation hat bei einer nicht typisierten Sprache schon Sinn. In C kannst du einem Char auch einen Integer zuweise, ohne dass der Compiler meckert. Nur ob dann auch das herauskommt, was du eigentlich beabsichtigt hast, ist was anderes. Die ungarische Notation hilft solche Fehler zu vermeiden. weil man "sieht" was die Variable für einen Datentyp hat.

[Furtbichler]

Zitat:

Zitat von Luckie (Beitrag 1242334)

Die ungarische Notation hat bei einer nicht typisierten Sprache schon Sinn.

Is klar. Aber mit Lint wär das nicht passiert. Aus Sicht eines C-Programmierers ist das natürlich ein Schattenparkertool.

Imho hat das (ungarische Notation) hat aber eher etwas mit schlechtem Codestil zu tun: Wenn ich nicht sofort sehe, was für ein Typ eine Variable ist, dann hab ich im Code etwas sehr falsch gemacht. Typisch für C ist komplexer, kompakter, dreckiger Code mit sehr kurzen Variablennamen. Das man dann in die Vorwärtsverteidigung geht und wenigstens die Variablen per Namenskonvention einem Typ zuordnen kann, ist typisch für die C-Fraktion.

Aber C hat natürlich auch Vorteile ('#define' ist einer davon).

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242341)

Imho hat das (ungarische Notation) hat aber eher etwas mit schlechtem Codestil zu tun

Bei normalen Variablen ja, eindeutig.

Bei visuellen Komponenten sehe ich das anders. Niemand weiß die Namen aller Komponenten auf allen Formularen auswendig. Wenn die aber mit der ungarischen Notation bezeichnet sind, braucht man nur schreiben btn und hat alle Buttons. Die Liste dürfte bei den meisten Formularen komplett in die Quelltextvervollständigung passen oder zumindest kurz genug sein um diese sofort zu überblicken.

Deshalb spart man sich so den Blick auf das Formular, wenn man den Code dahinter schreibt. Und auch im Objektinspektor findet man die Komponenten so sehr schnell.

[blackfin]

Leicht OT, muss ich aber hier mal loswerden:
Ich persönlich finde Sprachen wie Python, die mir vorschreiben, wie ich Quellcode einzurücken und zu formatieren habe, viel viel schlimmer und nerviger als ungarische Notation, curly braces oder C im Allgemeinen. :)
Ohne einen angepassten Editor / IDE oder Autoformatter sind solche Sprachen der Graus (für mich...) und in meinen Augen die echten "Unfälle", auch wenn z.B. Python sonst eine geniale Sprache wäre.

Dagegen finde ich den (mentalen) Wechsel zwischen C-Notation und Pascal-Notation relativ leicht machbar.
Ich programmiere µCs eigentlich gerne mit C und könnte mir da auch irgendwie kein Pascal vorstellen, im Gegensatz zu den Desktop-Anwendungen zu den µC-Projekten.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1242346)

Bei visuellen Komponenten sehe ich das anders.

Komischerweise sehe ich das auch so wie Du. Weiß auch nicht warum.

[jaenicke]

Zitat:

Zitat von blackfin (Beitrag 1242449)

Ich persönlich finde Sprachen wie Python, die mir vorschreiben, wie ich Quellcode einzurücken und zu formatieren habe, viel viel schlimmer und nerviger als ungarische Notation, curly braces oder C im Allgemeinen. :)

Naja, also wenn ich so manche Delphi Quelltexte sehe, die so grauenvoll formatiert sind, dass man kaum etwas erkennen kann... da würde ich mir fast schon wünschen, dass da der Compiler aussteigt und nen Fehler ausspuckt...

[blackfin]

Zitat:

Naja, also wenn ich so manche Delphi Quelltexte sehe, die so grauenvoll formatiert sind, dass man kaum etwas erkennen kann... da würde ich mir fast schon wünschen, dass da der Compiler aussteigt und nen Fehler ausspuckt...

Generell hast du ja recht, aber ich verstehe eine Programmiersprache als ein Werkzeug.
Wenn mir ein Hobel vorschreiben würde, in welchem Winkel ich die Tischkante anzulegen habe, und zwar nur so, würde ich mir den nicht kaufen :)
Natürlich muss ein Werkzeug auch elementare Dinge verhindern, wie z.B. mit G0 ins Werkstück fahren :lol: (Generelle Syntax, Klammern, Trenner, Operatoren etc.), aber so etwas wie den persönlichen Geschmack der Formatierung meiner Meinung nach nicht, man kann es auch übertreiben.
Selbstredend gibt es bei keinem Zwang dann auch immer Leute, die dann Müll(code) produzieren, aber das nehme ich lieber in Kauf als aufgezwungenen Stil... :)

Um aber wieder auf das Thema zurückzukommen, habe ich an den Threadersteller gleich eine Frage:
Was erwartest du dir hier eigentlich genau für eine Diskussion?
Einfach nur ein "ich mag C lieber, weil..." oder ein haarkleines auseinandernehmen der einzelnen Features?
Versteh das nicht falsch, das soll kein Angriff sein, sondern eine ernstgemeinte Frage, da ich mir unter einer "C vs Pascal"-Diskussion ausser den üblichen Verdächtigen (bessere Lesbarkeit beim einen, kürzerer Code beim anderen etc.) nicht viel vorstellen kann :)

Wenns allein um die Erfahrung geht:
Ja, ich stimme dem allgemeinen Kanon in einer Sache mit ein: Von mir selbst geschriebener C-Code ist nach einiger Zeit der Nicht-Sichtung auf Anhieb immer etwas schwieriger zu lesen als verglecichbarer Pascal-Code, von dem her stimmt es meiner Meinung nach schon, dass C auf den ersten Blick immer etwas schwieriger zu verstehen ist. Wenn man dann aber wieder im Projekt "drin" ist, nehmen sich beide nicht viel.
Allerdings ist auch C / C++ von der "Unlesbarkeit" nicht sonderlich schlimm. Schlimmer finde ich da generell asynchronen Code mit Callback-Gespringe (egal welche Sprache :-))

[Furtbichler]

Bei C fällt mir ein Codeschnippsel ein, der zum Verschlüsseln des Kennwortes beim Unix-Login verwendet wird bzw. vor 30 Jahre wurde, als ich mich im Rahmen des Studiums damit beschäftigt habe. Dort wurden zwei Arrays deklariert:

Delphi-Quellcode:

var
  a1 : array [0..19] of Byte;
  a2 : array [0..19] of Byte;

Und dann wurde mit

Delphi-Quellcode:

for i:=0 to 39 do a1[i] := foobar[i]

in beide Arrays geschrieben, um anschließend u.a. mit

Delphi-Quellcode:

a2[x]

zu arbeiten. Das ist doch krank, oder?

Natürlich geht das ebensogut mit Delphi, aber das macht normalerweise keiner. Was ich damit sagen will (und schon vorher erwähnte): Ich glaube, die Sprache an sich ist schon ok. Sie erlaubt ne ganze Menge, aber das macht ein Hobel oder ein Hammer auch: Es sind eben Universalwerkzeuge. In den Händen eines guten Handwerkers sind sie sehr nützlich, aber wenn ein Cretin das in die Finger bekommt...

Ebenso bei 'C': Ich glaube, ein Programmierer wird bei der Sprache bleiben, die ihm am besten liegt: Typsicher + Prosa? Delphi! Modern, robust und elegant? C#! Kompakt-Tricks-Kryptisch-Kurz? C. Nicht die Sprache ist schräg, sondern die Programmierer, die es lustig finden, wenn außer ihnen niemand den Code versteht. Bei 'C' tummeln sich einfach mehr Nerds als bei Delphi. Dafür scheint mir Delphi eine Sprache für Individualisten und Einzelkämpfer zu sein. Wäre dem nicht so, wäre die virale Verbreitung moderner Softwarearchitekturen auch hier in der DP stärker zu beobachten.

Im C#-Team, mit dem ich derzeit arbeite, gibt es keine Diskussion über Formatierung (weil das imho zweitrangig ist) aber dafür hitzige Diskussionen über Bezeichner, Architektur, Clean Code, SoC, LoD, SRP, OCP usw. Wenn in einer Methode 10 Zeilen sind, wird schon refaktorisiert usw. Das kenne ich von Delphi-Teams so nicht. Wenn man sich die Diskussionen hier so anschaut, dann scheinen die 'Guten' gerade mal das Viewmodel-Konzept in Ansätzen umzusetzen, zumindest was die strikte Trennung von Funktion und UI betrifft. Einige andere Ansätze sind vereinzelt anzutreffen. Nicht, das das keiner so umsetzt, aber der Fokus in den Diskussionen hier ist ein anderer.

In einem 'C' Forum kann ich mir ketzerisch vorstellen, das man darüber diskutiert, wie schneller und kryptischer man eine Routine noch machen kann.

Na ja, Vorurteile eben ;-)

[Namenloser]

C-Programmierer spielen gerne mit dem Feuer. Ich muss gestehen, ich hatte mich vor diesem Semester nie wirklich mit C beschäftigt, aber mir wurde Angst und Bange, als ich erfuhr, wie alleine schon printf funktioniert...

Solange man alles richtig macht, eine sichere Sache. Aber ein kleiner Flüchtigkeitsfehler reicht, um den kompletten Stack zu zerschießen. Ggf. reicht es auch schon, das gleiche Programm nur für eine andere Architektur zu kompilieren...

Sowas würde in Pascal mit WriteLn oder in Delphi mit Format nie passieren.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242485)

Nicht, das das keiner so umsetzt, aber der Fokus in den Diskussionen hier ist ein anderer.

Das liegt aber denke ich auch daran, dass solche Diskussionen in Entwicklungsteams eher intern passieren. So ist es zumindest bei uns.

Vereinzelt gibt in Foren wie diesem auch Fragen in der Richtung, aber die spiegeln nur selten die Diskussionen dazu wieder.

Zitat:

Zitat von Furtbichler (Beitrag 1242485)

Im C#-Team, mit dem ich derzeit arbeite, gibt es keine Diskussion über Formatierung

Die macht Visual Studio ja auch normalerweise automatisch.
In Delphi mache ich das eher unbewusst so, dass eine Quelltextformatierung hinterher in der Regel keine Änderungen mehr verursacht.

[Popov]

Kleinwenig OT: blackfin hat Python erwähnt. Hört sich interessant an, wollte es mir mal angucken. Auf der Seite von Phyton findet man anscheinend einen Compiler. Weiß einer ob es da eine IDE dafür gibt (kostenlos mal zum testen), oder programmiert man da mit dem Editor?

[DeddyH]

https://wiki.python.org/moin/Integra...ntEnvironments

[jaenicke]

Siehe Wiki:
https://wiki.python.org/moin/Integra...ntEnvironments

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1242485)

Bei C fällt mir ein Codeschnippsel ein, der zum Verschlüsseln des Kennwortes beim Unix-Login verwendet wird bzw. vor 30 Jahre wurde, als ich mich im Rahmen des Studiums damit beschäftigt habe. Dort wurden zwei Arrays deklariert:

Delphi-Quellcode:

var
  a1 : array [0..19] of Byte;
  a2 : array [0..19] of Byte;

Und dann wurde mit

Delphi-Quellcode:

for i:=0 to 39 do a1[i] := foobar[i]

in beide Arrays geschrieben, um anschließend u.a. mit

Delphi-Quellcode:

a2[x]

zu arbeiten. Das ist doch krank, oder?

Nö, das war State of the Art. Damals wurde noch mit mit Speicher und CPU-Zyklen gegeizt.
Heute hingegen steht auf meinem Schreibtisch soviel Rechenpower wie damals in einem mittleren Rechenzentrum.

Die Zeiten ändern sich eben.

Gruß
K-H

[ATS3788]

Danke für die guten Infos.
Habe ein Haufen neuer Sachen gelernt.:thumb:
Ich sehe es ähnlich wie die meisten
Nur alleine der StrToÍnt oder IntToStr in Pascal
egal ob Du das mit einem byte oder integer, word,
you name it, machst
in "C" gibt es für jeden Integer Typ einen eigenen Befehl.
Weiß allerdings nicht ob das so auch in C++ ist.
Es ist eine neue Erfahrung und C ist echt gut für µC

http://www.pmpcomp.fr/
Hatte mal ein wenig mit seiner Microchip Pascal Umsetzung gearbeitet
Er steckt da viel Liebe in dies Projekt.

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1242577)

Nö, das war State of the Art.

Ähh. 'Union' wäre 'state of the art'.

[Furtbichler]

Ich denke, wenn man weiss, was man tut und performancekritische kryptische Anweisungen dokumentiert, ist 'C' für µC ok.