MichaelB: Fortsetzung

Beitrag lesen

Hallo,

Meinens Wissens nach ist es auch unter vielen anderen Pascal-Dialekten so. Bei Turbo Pascal war die Längenangabe eine Byte-Variable. Daher auch nur 255 Zeichen. Manch andere verwenden dafür Integer und dann hat man schon deutlich mehr.
Weiter unten kritisierst Du die Implementierungsabhängigkeit von Datentypen bei C, bei Pascal ist das für Dich in Ordnung, oder wie?

Halber Punkt für Dich. Warum nur ein halber? Weil bei C es viel mehr ungeregelte Dinge gibt wie bei Pascal. Und das ist, was mich stört. Die Vielzahl an ungeregelten Dingen.

C wurde an sich dafür entwickelt, um Betriebssysteme schreiben zu können, ohne alles in Assembler zu machen, damit dieses Betriebssystem möglichst einfach auf eine neue Hardware portiert werden kann. Irgendwie ist imho C so ein Mittelding zwischen Assembler und Hochsprachen wie Pascal oder Fortran oder ähnlichem.

Ich weiß ja nicht ob Du mein Posting zu Ende gelesen hast. Aber sowas in der Art schrieb ich bereits. Nur halt kürzer und prägnanter.
Das Problem ist nur, daß viele Leute C nicht nur in dem Einsatzgebiet einsetzen wollen, für das die Sprache gut geeignet ist.

Da Betriebssystem-Funktionen in der Regel sehr oft aufgerufen werden macht es sinn, diese so performant wie möglich zu machen. Wenn nun aufwendige Prüfungen auch dann jedesmal gemacht, wenn in einem bestimmten Code-Abschnitt die Prüfbedingungen garantiert nie verletzt werden können, dann leidet die Performance darunter.

Unter Pascal kann ich diese Prüfungen abschalten (zum Beispiel wenn mein Code durchgetestet ist). Und das mit einem Schalter und ohne den Quelltext verändern zu müssen.

Ein weiteres Ziel bei der Entwicklung von C war, sie möglichst einfach zu gestalten, was die Core-Syntax betrifft, damit die Erstellung eines Compilers für eine neue Plattform so einfach wie möglich ist.

Das erklärt aber nicht die Unlogik in der Syntax (darauf bist Du ja clevererweise überhaupt nicht eingegangen).
Warum beispielsweise für das switsch-Konstrukt zwei Schlüsselworte benötigt werden und für das äquivalente in Pascal nur Eines bleibt mir unklar. Wenn man schon eine minimalistische Sprache haben will, warum leistet man sich dann solche Schnitzer?
Und heutzutage gibt es eigentlich keine Berechtigung mehr eine Sprache so aufzubauen, dass der Compiler einfach ist. Trotzdem hat man es mehrfach versäumt C entsprechend nachzubessern.

Alles was nicht direkt in der Sprache notwendig ist, wurde in die Bibliotheken verlagert.
Ausserdem, wozu soll ich denn File-Handling-Funktionen in eine Sprache einbauen, wenn das OS auf dem das Programm dann läuft vielleicht gar keine Dateien kennt?

Auch das ist durchaus positiv zu bewerten. Ich habe ja auch bereits geschrieben, daß dies seine Vorteile hat. Ich wiederhole mich aber gern: Nicht _alles_ ist an Pascal besser oder gut gelöst aber vieles besser gegenüber C.

Warum müssen Prozeduren einen Datentyp (void) zurückgeben?
Weil es in C so etwas wie Prozeduren gar nicht gibt. Es gibt nur Funktionen, die nichts (void) zurückliefern;-)
Warum kann man bei einer mit void deklarierten Funktion überhaupt ein Rückgabewert angeben ohne das der Compiler meckert?
Dann verwendest Du anscheinen keinen Ansi-Compiler.

Keine Ahnung. Ältere Compiler konnten das jedenfalls nicht. Das sie über die Jahrzehnte etwas verbessert haben, möchte ja wohl auch sein.

Der Operatorreihenfolge ist ungeschickt gewählt. Beispiel:
int a;
a=10;
--x=(++x)--;
Na gut, nicht alles was möglich ist, ist auch sinnvoll. Das von Dir gewählte Beispiel hätte ich nie und nimmer geschrieben.

Ähm. Das sollte war auch nicht zum verwenden gedacht sondern sollte nur aufzeigen, wie unlogisch in C die Operationsreihenfolge ist. Was einem (wie ich bereits schrieb) zu sehr vielen Klammersetzungen nötigt die dann der Übersichtlichkeit schaden.

Und apropos Operator: Ganz krank ist ja nun dieses = für eine Zuweisung und == für Vergleich. Ich möchte nicht wissen, wie oft Programmierer darüber geflucht haben wenn in vielen unbeabsichtigen Verwechslungsfällen der Compiler keine Fehlermeldung liefert. --> Krankes Konzept da nicht am Menschen orientiert.
Die meisten Compiler die ich kenne, geben eine Warning aus, wenn innerhalb von Bedingungen Zuweisungen erfolgen. Das aber nur so nebenbei.
Ich persönlich fluche eher, weil ich in Pascal bei jeder Zuweisung := verwenden muß, nur damit ich bei den, viel seltener benötigten, Vergleichen ein einfaches = verwenden kann.

Dieses := war aber auch damals in anderen Programmiersprachen gang und gäbe. Hier hat man mutwillig eine Änderung vorgenommen ohne Not.
Wenn man sich einmal eingearbeitet hat, dann ist dass ja auch nicht mehr das Problem. Beim Umstieg aber schon.
Und wegen der Tipparbeit ... ich denke mal, daß hast Du nicht ernsthaft gemeint.

Da gefällt mir das C-Konzept viel besser (genauso wie es anscheinend auch den Entwicklern von praktisch allen Sprachen, die C-ähnliche Syntax verwenden genug gefallen hat, um es zu übernehmen).

Programmiersprachen mit C ähnlicher Syntax richten sich ja üblicherweise auch an C Programmierer. Da wäre es fatal solch grundlegenden Sachen zu ändern.

Auch die Mehrfachverwendung von Schlüsselwörtern mit jeweils komplett unterschiedlicher Bedeutung macht es einem nicht gerade einfach (beispielsweise: static).
Da hast Du sicherlich recht, allerdings ist dieser Makel auch in vielen anderen Sprachen anzutreffen.

In Pascal fällt mir kein eklatantes Beispiel ein. Vielleicht kannst Du mir mal weiterhelfen.

Viele Dinge in C sind nicht geregelt und implementierungsabhängig (Umfang von Datentypen usw).
Das stimmt so nicht. Es ist sehr wohl geregelt, man muß sich nur die plattformspezifische Implementierung genau ansehen.

Ähm ... warum gibt es überhaupt plattformspezifische Implementierungen? Gut. C ist hardwarenah und wenn ich beispielsweise ein Betriebssystem für eine Plattform schreibe, macht es ja auch Sinn schon wegen der Optimierungsmöglichkeiten. Aber auch nur dann. Aber wenn, dann würde ich int nicht mal so und mal so machen sondern einfach Variablentypen verwenden speziell für 8Bit, 16Bit, 32Bit usw. Dann weiß ich wenigstens, woran ich bin.

... Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.
Aber nur aufgrund impliziten Wissens.
Na gut, implizites Wissen um eine Programmiersprache ist doch Voraussetzung für eine halbwegs erfolgreiche VErwendung derselben, oder?

Schon. Aber nicht für das lernen.

Ok aber darauf will ich jetzt nicht ewig herumreiten. Ich habe auch kein Problem mit dieser Definition von Feldern. Damit komme ich ganz gut klar. Was mir weniger gefällt ist eben nur, daß man keinen Startwert angeben kann.
Imho ist die Festlegung des Starwertes auf 0 einfacher, da man sich ja nur genau eine Regel merken muß.

Wie schon mal gesagt. Nicht immer braucht man ein Feld mit dem Startwert 0. Und dann ist es einfach eine Fehlerquelle. Pascal gibt mir 'ne Fehlermeldung aus, wenn ich durch irgendwas den Array-Bereich verlasse. In C ist es dann ein schwer zu findener Bug.

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE.
Da kann ich nur sagen: Selbst schuld.
Wenn Du Dir das Leben unnötig schwer machst, dann ist das Dein Problem. Schieb es dann aber nicht auf die Sprache wenn Dir dann irgendwas fehlt.
Was hat eine eventuell vorhandene IDE mit Sprachkonzepten zu tun? Mir fällt auf die Schnelle keine Sprache ein, die unbedingt eine IDE benötigen, sofern der Quelltext auch als Textdatei gespeichert werden kann.

Aber der Umgang mit der Sprache wird deutlich vereinfacht und man kann Dinge machen, die sonst von der Sprache nicht unterstützt werden müssen (blödes Beispiel: Refactoring).
Ich kann mir auch sinnvollere Sichten auf die Sprache legen. Klassiches Beispiel sind GUI-Designer.
Das alles vereinfacht mir den Umgang mit der Sprache ohne das die Sprache selbst etwas dazu beitragen muss.

Ich persönlich kann sowohl mit als auch ohne IDE recht gut leben. Einerseits finde ich auch, dass einem IDE'S das Leben zwar erleichtern können, andererseits verstehe ich Christian auch recht gut, weil verschiedene IDE-Systeme dazu neigen, den Programmierer zu bevormunden.

Wenn sich das nicht abschalten läßt, hast Du die falsche IDE :-)

Ausserdem verhindern sie oft, dass Programmierer die Sprache besser verstehen lernen.

Sicher. Man kommt nicht umhin sich mit einer Sprache zu beschäftigen. Aber wenn man das dann drauf hat, warum sollte man sich das Leben dann nicht erleichtern?

Aber jedem das Seine und mir das Meine;-)

:-) Gute Einstellung.

Abschließend möchte ich noch etwas anmerken, das bis jetzt so noch nicht richtig rübergekommen ist.
Ich habe persönlich keine wirkliche 'Lieblingssprache' (deshalb bin ich wahrscheinlich auch in keiner ein sog. Spezialist). Gute Programme kann man an sich in jeder Sprache schreiben, die ich bis jetzt verwendet habe (und das sind auch schon einige). Allerdings fällt mir auch keine Sprache ein, in der man nicht absoluten Bockmist zusammenschustern kann. So gut kann kein Sprachkonzept sein, dass es nicht von einem mehr oder weniger kranken Geist umgangen werden kann.

Stimmt. Aber C macht es einem in vielen Fällen besonders leicht.

Wichtig ist nur, sich auf eine Sprache und deren Eigenheiten einzulassen. Will man in der einen Sprache alle Konzepte einer anderen Sprache umsetzen, dann ist man in der Regel auf dem falschen Weg.

Es geht nicht darum das Konzept einer Sprache auf eine andere zu übertragen. Mir genügte es, wenn C ein logisch Konzept hätte!

Hier nur ein Beispiel: Als ich damals mit Perl begonnen habe, da habe ich vorher praktisch ausschließlich in C programmiert. Anfangs habe ich einige Konzepte, die ich in C verwendet habe, in Perl vermisst und versucht diese nachzubilden. Im Laufe der Zeit habe ich dann immer mehr von Perl verstanden, was dazu geführt hat, das meine Scripts immer mehr richtige Perl-Scripts waren und weniger C-Programme, die halt irgendwie in Perl umgesetzt sind.

Da ist viel Wahres dran.
Aber C macht einen gerade in der Einarbeitung das Leben schwer. Denk nur mal an den Zeigerkram mit Referenzierung und Dereferenzierung. Wieviele Anfänger wie oft darüber gestolpert sind, möchte ich nicht wissen (und selbst den Profis passieren damit imemr wieder Fehler). Vielleicht liegt es an meinem Unvermögen, aber ich habe lange gebraucht um das zu kapieren.
Das Zeigerkonzept von Pascal habe ich dagegen recht schnell begriffen, obwohl ich davor nichtmal wußte was ein Zeiger ist.
Ebenso das Zeigerkonzept von Java was ja nun wiederum völlig verschieden ist zu Pascal oder C habe ich auch schnell verstanden.

Genauso verhält es sich auch mit den Programmiersprachen. Man sollte sich halt nur nicht in eine Sprache 'verlieben'.

Ich bin nicht in Pascal verliebt. Sonst würde ich wahrscheinlich immer noch damit programmieren. Was mir eben nur aufgefallen ist das trotz Pascal älter ist mit C eine Sprache geschaffen wurde die gegenüber Pascal viele Nachteile hat. Und das an vielen Stellen völlig unnötig.

Gruß
   MichaelB

0 111

Welche Programmiersprache ist die richtige?

Jürgen Ulmschneider
  • programmiertechnik
  1. 0
    Die dicke Tina
    1. 0
      wahsaga
      1. 0
        Andavos
    2. 0
      Onkel
      1. 0
        Fabian Transchel
    3. 0
      Atomfried
      1. 0
        Johannes Zeller
  2. 0
    Andavos
  3. 0
    Markus Trusk
    1. 0
      Andavos
      1. 0
        Markus Trusk
    2. 0
      Martin Jung
      1. 0
        MichaelB
        1. 0
          Martin Jung
          1. 0
            MichaelB
            1. 0
              Martin Jung
              1. 0
                MichaelB
                1. 0
                  Martin Jung
                  1. 0
                    MichaelB
    3. 0
      Andreas-Lindig
      1. 0
        MichaelB
  4. 0

    Nimm Java

    MichaelB
    1. 0
      Jürgen ulmschneider
      1. 0
        Fabian Transchel
        1. 0
          Christian Seiler
          1. 0
            Jürgen Ulmschneider
            1. 0
              Christian Seiler
              1. 0
                MichaelB
  5. 0
    Gerrit
    1. 0
      MichaelB
      1. 0
        Christian Seiler
        1. 0
          MichaelB
          1. 0
            Christian Seiler
            1. 0
              Jürgen ulmschneider
              1. 0
                MichaelB
              2. 0
                Ingo Turski
  6. 0
    Danny
    1. 0
      FrankieB
      1. 0
        MichaelB
        1. 0
          FrankieB
  7. 0
    Bio
    1. 0
      MichaelB
      1. 0
        Bio
        1. 0
          MichaelB
    2. 0
      Gerrit
      1. 0
        Gerrit
  8. 0
    Noodles
    1. 0
      MichaelB
      1. 0
        Noodles
        1. 0
          MichaelB
          1. 0
            Christian Kruse
            1. 0
              MichaelB
          2. 0
            GONZO
            1. 0
              MichaelB
    2. 0
      Jürgen Ulmschneider
      1. 0
        MichaelB
  9. 0
    Julian von Mendel
    1. 0
      MichaelB
  10. 0
    Jürgen Ulmschneider
    1. 0
      MichaelB
    2. 0
      Vinzenz
      1. 0
        MichaelB
        1. 0
          Klaus Mock
          1. 0
            MichaelB
          2. 0
            Frank Schönmann
            1. 0
              MichaelB
              1. 0
                Frank Schönmann
                1. 0
                  MichaelB
                  1. 0
                    Christian Seiler
                    1. 0
                      MichaelB
                      1. 0
                        Christian Kruse
                        1. 0
                          MichaelB
                          1. 0
                            Christian Kruse
                            1. 0
                              MichaelB
                              1. 0

                                Fortsetzung

                                MichaelB
                                1. 0
                                  Klaus Mock
                                  1. 0
                                    MichaelB
                  2. 0
                    Christian Kruse
                    1. 0
                      MichaelB
    3. 0
      Kopfwunde
    4. 0
      Eternius
      1. 0
        GONZO
        1. 0
          MichaelB
  11. 0
    Jürgen Ulmschneider
    1. 0
      MichaelB
      1. 0
        Fabian Transchel
        1. 0
          MichaelB
          1. 0
            Fabian Transchel
            1. 0
              MichaelB
      2. 0
        Christian Seiler
        • menschelei
        1. 0
          Fabian Transchel
  12. 0
    nobody
    1. 0
      Fabian Transchel
      1. 0
        MichaelB
        1. 0
          Fabian Transchel
          1. 0
            MichaelB
            1. 0
              Fabian Transchel
              1. 0

                Energien

                MichaelB
                • sonstiges
                1. 0
                  Christian Seiler
                  1. 0
                    Christian Seiler
                    1. 0
                      MichaelB
                  2. 0
                    Fabian Transchel
                    1. 0
                      Christian Seiler
                  3. 0
                    MichaelB
                  4. 0
                    Christian Seiler
                    1. 0
                      Klaus Mock
                      1. 0
                        Fabian Transchel
                    2. 0
                      Fabian Transchel
          2. 0
            Christian Seiler
            1. 0
              Fabian Transchel