C ist "freier" als Pascal

Für sonstige Unterhaltungen, welche nicht direkt mit Lazarus zu tun haben
thosch
Beiträge: 324
Registriert: Mo 10. Jul 2017, 20:32

Re: C ist "freier" als Pascal

Beitrag von thosch »

Nun ja, als Anhänger der Sprache Pascal sag ich da mal, C/C++ unterscheidet nicht so sehr zwischen aktuellen und "veralteten Betriebssystemen. Es gibt für C/C++ bedeutend mehr Grafikbibliotheken für das alte DOS, die DOS GUIS, die mit Freedos angeboten werden, sind durchweg in C/C++ geschrieben. Pascal hat dagegen die Unterstützung für dieses alte Betriebssystem so weit zurück gefahren, dass da nur noch einige handverlesene Grafik- und GUI bibliotheken verfügbar sind, die es allerdings dann auch immer noch gibt, womit auch Pascal keine Textmode- und Kommandozeilenbastion ist. Nicht mal ide 16Bit Version von Freepascal, denn da könnte der GUI Fan, der noch DOS nutzt, auf die Idee kommen, GVision 3 von Matthias Köppe nach Freepascal zu portieren. Vielleicht ist ja auch so eine Portierung dort gar nicht mehr nötig, je nach Grad der Portabilität und Kompatibilität zum Guten alten Turbo Pascal.

Moderne Betriebssysteme werden, denke ich auch von Pascal optimal unterstützt.

Vielleicht sind die C/C++ Bibliotheken aber auch plattformunabhängiger geschrieben. In der LCL ist in der Unit Graphics auf der Windows Seite immer noch Windows API enthalten ( CreateFont() ). In der FCL ist das OK, in der LCL nicht mehr. Dort gehören gann FCL Aufrufe hin und die Fontklasse in der FCL entsprechend angepasst. Klar kann man dann das Ganze für Linux einfach noch mal anpassen, ist aber unnötige Arbeit, da ja in der FCL aller systemabhängige Code liegen könnte, dann brauchte man die LCL in keinem weiteren Betriebssystem mehr anzufassen und würde funktionieren.

Und für Uralt Betriebssysteme wäre es auch einfacher, eine grafische Oberfläche für die Programmierung von Tools (GUI-Tools) anzubieten. Mag ja sein dass DOS hoffnungslos veraltet ist. Diesen Eindruck teile ich aber aufgrund der Aktivitäten in Freedos und der verbliebenen DOS Freaks nun überhaupt nicht. Warum für ein sooo veraltetes Betriebssystem dann überhaupt eine freie Version entwickeln??? Recht widerspüchlich das Ganze. Soll doch jeder das als Betriebssysten verwenden dürfen, was er braucht oder möchte. Ich bleibe bei Linux und gelegentlich Windows. Und unter Linux bei KDE, Gnome oder XFCE. Wer DOS will, soll es nutzen, aber bitte auch anerkennen, das heutzutage eine grafische Oberfläche zeitgemäßer ist. Das Freedos Team hat diesen Umstand erkannt und auch die C/C++ Gemeinde hat das erkannt und einige wirklich modern aussehende GUI's für DOS entwickelt. Fehlt noch eine IDE in grafischem Design zum Entwickeln von Backends für die alten DOS Kommandos. Es sei denn, die Spielefreaks wollen mit DOS nur ihre alten Spiele weiter spielen, aber keine neue Software für dieses Uralt System mehr entwickeln. Für paar Assemblerversuche oder Programmierung von Grafikkartenregistern, .... reichen natürlich die alten DOS Werkzeuge wiederum komplett aus. Und wer für das Uraltsystem ein GUI will, der bekommt das ja auch. Egal ob im nostalgischen Design wie bei OpenGEM oder in einem moderneren Outfit, wie Ozone- oder Aura-GUI oder auch SEAL. Und die alten Windows 9.x Betriebssysteme gibt es außerdem zum Gratis Download. Ob legal oder illegal, wenn Microsoft da nichts unternimmt, vielleicht aus Werbegründen, dann gilt hier, wo kein Kläger, da kein Richter. Dann wiederum gibt es aber für die GUI ein leistungsfähiges Entwicklungssystem, unser Lazarus.

Kurz und gut, vielleicht ist die Programmierphiliosophie der C/C++ Gemeinde einfach unideologischer. Es gibt weniger Beschränkungen, sei es auch, weil man egal ob veraltet oder nicht, die Bibliotheken weiterhin anbietet. Ist ja immerhin auch Aufwand, ständig neue Bibliotheken erlernen zu müssen.

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: C ist "freier" als Pascal

Beitrag von marcov »

Warf hat geschrieben:z.B.

Code: Alles auswählen

for (int c = 0, FILE* f = fopen(argv[1], "r"); (c = fgetc(f)) != EOF; putchar(c));

ist bereits die Grundfunktion von dem CoreUtil cat. In Pascal ist das deutlich aufwendiger.


dagegen ist ein normaler For loop kurzer:

Code: Alles auswählen

for i:=0 to 10 do
 

13 nicht leer Zeichen

gegen

Code: Alles auswählen

for (i=0;i<11;i++) 


16 nicht leer Zeichen.

Aber ich denke was mit Freiheit am meisten gemeint ist, ist die Typstrenge. Z.B. die Strikte Trennung zwischen Boolean und Integern, welche in C gar nicht vorhanden ist.


Ich denke das es meistens sich an alte Sentimenten hängt aus Zeiten das man unions nutzen mussten um eine Sequenz bytes aus einem Buffer nach integer zu Konvertieren statt pinteger(@buf[32])^ oder so. C99 ist auch Typsicher im Prinzip, also der Int<>boolean Äquivalents kann es nicht sein.

Ja, es gibt ein paar barocke Sachen an beide Seiten wie fallthrough switch() (Duff's device), obenstehenden WHILE-getarnt-als-FOR, ? und , (aber halb die C programmieren kennen kennen Comma ueberhaubt nicht) usw, aber manche haben mehr Problemen als Nutzen. (wie zb wie oft man BREAK's vergisst oder == vs = vermischt)

Die C Koder sehen noch immer ein paar weniger Charakter als eine riesiger Unterschied (und oft eben mit Executiongeschwindigkeit, da hat es aber nichts mit von tun), weil das wichtige Feature einer Sprache eher Lesbarkeit und vermeiden von Fehler ist. Eigentlich reduziert das alles bis "C ist l33t"

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: C ist "freier" als Pascal

Beitrag von mschnell »

marcov hat geschrieben:

Code: Alles auswählen

for i:=0 to 10 do
 

13 nicht leer Zeichen

gegen

Code: Alles auswählen

for (i=0;i<11;i++) 


16 nicht leer Zeichen.


naja, eigentlich sollte man das vergleichen:

Code: Alles auswählen

for i:=0 to 10 do begin
end;

gegen

Code: Alles auswählen

for (i=0;i<11;i++){
}


:twisted:
-Michael

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: C ist "freier" als Pascal

Beitrag von marcov »

Nein, die gebe ich nie ein, das macht der IDE :-)

(was noch ein andere Grund das reine Karakter zahlen Unsinn ist.

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: C ist "freier" als Pascal

Beitrag von Timm Thaler »

mschnell hat geschrieben:gegen

Code: Alles auswählen

for (i=0;i<11;i++){
}


Jup, die Brackets bei C sind der größte Scheiss überhaupt. Was mich das schon Zeit gekostet hat, weil die mal wieder falsch zugeordnet waren oder irgendwo eine gefehlt hat, oder zuviel war.

diogenes
Beiträge: 200
Registriert: So 11. Jul 2010, 18:39
OS, Lazarus, FPC: Linux
CPU-Target: 64 Bit
Wohnort: Wien
Kontaktdaten:

Re: C ist "freier" als Pascal

Beitrag von diogenes »

Ich hab' da einen Spruch:

Code: Alles auswählen

 
C stammt von zwei Programmierern und ist, was sie wollen.
Pascal stammt von einem Programmier-Lehrer und ist, was Programmierer brauchen.
 

Den Spruch muss man natürlich immer mit einem ;) nehmen, aber er ist, denke ich, nicht ganz von der Hand zu weisen. Kernigan (oder war's Ritchie?) hat einmal gemeint, eigentlich sei C ein komplizierter Assembler oder so ähnlich. Ich denke, das hat er eben wegen der Typfreiheit gesagt. Lesbarkeit ist da nicht gefragt, nur Kürze. Wenn der Code leicht verstanden werden soll, kommentiert man halt, und dann schreibt man eh so viel wie in einem Pascal-Quelltext, wenn nocht sogar mehr.
Der Heiligie Niklaus (Wirth) hat Pascal ja tatsächlich als Lehrsprache konziopiert und ist deswegen ja typstreng und ein wenig wortreich. Aber dafür ist der Code leichter lesbar und erfassbar. Das sich das auch für die professionelle Programmierung, speziell beim Warten des Codes anderer Autoren bewährt bzw. bewähren kann, ist ein Nebeneffekt, aber durchaus ein Argument, um, wenn schon nicht FPC und Lazaros, so doch vielleicht Delphi einzusetzen. Ich würde FPC/Lazarus empfehlen wegen der Portierbarkeit und wegen des gunstigen Preises.

Im Übrigen denke ich, dass es deswegen so viele Programmiersprachen gibt, weil das Problem "Wie sag ich's dem Computer, ohne dass die Lesbarkeit verschwindet" zu denen gehört, die sich grundsätzlich nicht richtig lösen lassen, denn ansonsten gäbe es genau eine Programmiersprache.
Ceterum censeo computatores per Pascal docendos esse.

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: C ist "freier" als Pascal

Beitrag von Mathias »

Der grösste Nachteil von C/C++ ist, das es mehr verbreitet ist als Pascal.
Bei Desktop-Anwendungen, merkt man den Nachteil nicht so gross, da man Lazarus nehmen kann,

Aber es gibt leider Sachen, da kommt man kaum um C++, ZB. Arduino, Shader-Programmierung.

Bis jetzt wurde nur über den Dialekt von C/C++ gesprochen.
Was bei C/C++ noch dazu kommt, ist das Gewürge mit den *.h und *.cpp, da hat Pascal mit dem Unit-System die Nase Meilenweit voran. :wink:
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

MitjaStachowiak
Lazarusforum e. V.
Beiträge: 394
Registriert: Sa 15. Mai 2010, 13:46
CPU-Target: 64 bit
Kontaktdaten:

Re: C ist "freier" als Pascal

Beitrag von MitjaStachowiak »

Jiipii, ein sag' deine Meinung-Thread :mrgreen:

Also zunächst einmal kann man in C wie auch in C++ Code sehr viel kompakter schreiben, als in Pascal. Inzwischen erlauben die meisten Compiler auch das Einbetten prädikatenlogischer Therme in den Code, womit man sehr viel kompakter z.B alle Elemente aus einer Liste durchgehen kann, die eine bestimmte Eigenschaft haben. Ich arbeite sonst viel mit Java und EcmaScript - was ich in Pascal vermisse, sind die diversen fest-eingebauten Funktionen, wie Array.sort(), Array.push(), Array.unshift(), String.indexOf usw. Diese objektorientierte Schreibweise ist einfach besser, als Length(Array) oder LeftString(s). Dass Strings bei [1] anfangen und man Variablen und Funktionen (noch) nicht inline definieren kann, nervt auch, aber hier entwickelt sich Pascal auch ständig weiter...

Bis weilen stolpert man aber auch in Sprachen, wie Java, über Syntax-Sünden, wie switch { case a : [...] break; } Das sind sehr heimtückische Fehlerquellen - dann lieber echte gotos. Mehrfachvererbung ist für den Compiler ein Albtraum. Meistens findet man eine brauchbare Klassenstruktur ohne Mehrfachvererbung. Man kann in Pascal die zusätzlichen Klassen ja einfach als Variablen in die die Haupt-Hirachie aufnehmen. Das ersetzt die meisten Usecases von Mehrfachvererbung; jedoch wäre es schön, wenn man auf die Eigenschaften der so mehrfach vererbten Ausdrücke per default über die Hauptklasse zugreifen könnte. Also so:

Code: Alles auswählen

 
 TSub = class
  subVar : integer = 3; // ja, die direkte Initialisierung von Variablen bei deren Definition wäre schon echt super
 end;
 TMain = class(TSonstwas)
  inheritsfrom // wäre syntaktisch gleich zu var, aber mit default-Zugriff
   subClass : TSub = TSub.Create();
 end;
 
var m = TMain.Create();
m.subVar := 4// TMain hat keine Variable subVar, also wird automatisch auf m.subClass.subVar zurückgegriffen
 


Naja, so hat jede Sprache ihre Vor- und Nachteile :wink:
Aber z.B. Java ist wesentlich weniger "frei" als Pascal oder C aber gerade das ist der Grund, warum alle* Universitäten heute Java lehren.
*Diese Aussage wurde nicht empirisch belegt, aber es ist so :mrgreen:

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: C ist "freier" als Pascal

Beitrag von Mathias »

was ich in Pascal vermisse, sind die diversen fest-eingebauten Funktionen, wie Array.sort(), Array.push(), Array.unshift(), String.indexO

Bei den Strings sieht es da bei Pascal gar nicht mehrt so schlecht aus.
So etwas kann Pascal auch.

Code: Alles auswählen

var
  s:String;
begin
  s:='Hello world';
  Caption:=IntToStr(s.IndexOf('o'));
end;
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: C ist "freier" als Pascal

Beitrag von Timm Thaler »

MitjaStachowiak hat geschrieben:... sind die diversen fest-eingebauten Funktionen, wie Array.sort(), Array.push(), Array.unshift(), String.indexOf usw. Diese objektorientierte Schreibweise ist einfach besser, als Length(Array) oder LeftString(s).


Aua! Gerade bei C finde ich das äußerst anstrengend zu lesen, besonders wenn dann auch noch die verschiedenen Schreibweisen gemischt werden.

Code: Alles auswählen

isCustomBaudRate = !ui->baudRateBox->itemData(idx).isValid();


Häh? Also wenn ich da lange genug draufstarre, komme ich auch drauf, was da passiert. Noch schlimmer wird es aber, wenn ich das selbst schreiben muss. Wenn ich jedesmal erst googeln muss, welche Schreibweise welcher Befehl jetzt wieder verlangt... ich hab dann irgendwann aufgegeben und bin gerade noch durch eine göttliche Fügung bei Lazarus gelandet.

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: C ist "freier" als Pascal

Beitrag von Mathias »

Diese Zeile müsste ich auch googeln, unleserlicher geht es kaum noch.
Was ich mit C++ schon Zeit verloren habe wegen des Syntax. Ein kleiner Arduino Sketch, braucht fast eine Stunde, nur wegen des komplizierten Syntax. :|
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

MitjaStachowiak
Lazarusforum e. V.
Beiträge: 394
Registriert: Sa 15. Mai 2010, 13:46
CPU-Target: 64 bit
Kontaktdaten:

Re: C ist "freier" als Pascal

Beitrag von MitjaStachowiak »

Code: Alles auswählen

s.IndexOf('o')
Finde ich super!

Wo Mathias gerade hier ist: Kann man in Pascal eigentlich einene Datenstrukturen wie Array oder String definieren, die sich mit Reference Counting selber freigeben?
Also z.B ein Record mit variabler Größe dieser Art:

Code: Alles auswählen

 
TRefCount = heap object
 v1 : integer;
 v2 : double;
 arr : Array of Byte; // Größe dieses Arrays ist variabel, aber v1, v2, arr hängen immer zusammen im Speicher
end;
 

Wenn ich richtig informiert bin, haben AnsiStrings z.B. ein s[-1]-Element, da der Length-Wert hier größer als 1 Byte ist. Bei einem ReallocMem von AnsiStrings muss also der entsprechende, übergeordnete Datenblock verschoben werden. Also ist sowas prinzipiell schon vorhanden, aber kann ich das auch irgendwie für eigene Datenstrukturen nutzen?

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: C ist "freier" als Pascal

Beitrag von Warf »

MitjaStachowiak hat geschrieben:

Code: Alles auswählen

s.IndexOf('o')
Finde ich super!

Wo Mathias gerade hier ist: Kann man in Pascal eigentlich einene Datenstrukturen wie Array oder String definieren, die sich mit Reference Counting selber freigeben?
Also z.B ein Record mit variabler Größe dieser Art:

Code: Alles auswählen

 
TRefCount = heap object
 v1 : integer;
 v2 : double;
 arr : Array of Byte; // Größe dieses Arrays ist variabel, aber v1, v2, arr hängen immer zusammen im Speicher
end;
 

Wenn ich richtig informiert bin, haben AnsiStrings z.B. ein s[-1]-Element, da der Length-Wert hier größer als 1 Byte ist. Bei einem ReallocMem von AnsiStrings muss also der entsprechende, übergeordnete Datenblock verschoben werden. Also ist sowas prinzipiell schon vorhanden, aber kann ich das auch irgendwie für eigene Datenstrukturen nutzen?


ein s[-1] element wäre mir neu. Es gibt das s[0] Element welches in 0 Terminierenden Strings nur noch historische Gründe hat. Die Länge des Strings, sowie der ReferenzCounter allerdings sind Elemente eines Hilfs Records die im Speicher vor dem Character String liegen. Wenn ein String erzeugt wird werden SizeOf(HilfsRecord) + Length(Str) Bytes alloziiert, zurück bekommt man dann einen Zeiger auf das Erste Element des Strings. Um nun den auf den ReferenzCounter Zuzugreifen müsste man so etwas machen: (PHilfsRecord(StrPointer) - 1)^.RefCount := 5.

Wie genau der Record und seine Felder heißen weiss ich nicht (kann man aber leicht nachschauen), aber all diese Daten werden im Heap gespeichert, und in deinem Objekt welches eine String Variable enthält (oder Array) steht nur der Zeiger drin.

PS: Wenn du selbst Referenzzählung implementieren möchtest geht dies über Klassen welche COM Interfaces verwenden, da diese das unterstützen. Du kannst also Theoretisch eine Klasse schreiben, den Gesamten Public Teil der Klasse in ein Interface Kopieren, und dann diese Klasse nur noch über Variablen des Interface Typen verwenden, und schon hast du deine Referenzzählung.

Ich finde es wirklich schade dass es keine Möglichkeit gibt Referenzgezählte Typen anderweitig selbst zu schreiben, denn die Möglichkeit ist ja implementiert, für Interfaces, Strings und Arrays, warum also nicht für Allgemeine Klassen und Structs. Man kann ja nicht mal den := Operator so überladen um eigene Referenzzählung zu Implementieren (man hat beim überladen keinen Zugriff auf die zu überschreibende Variable)

braunbär
Beiträge: 369
Registriert: Do 8. Jun 2017, 18:21
OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: 64Bit
Wohnort: Wien

Re: C ist "freier" als Pascal

Beitrag von braunbär »

MitjaStachowiak hat geschrieben:Also zunächst einmal kann man in C wie auch in C++ Code sehr viel kompakter schreiben, als in Pascal.

Kompaktheit auf Kosten der Lesbarkeit, wie es in C der Fall ist, ist m.E kein Gewinn. Aber ein paar Konstrukte, die etwas kompakteren Code ermöglichen würden, fehlen mir in Pascal schon. Verwenden sollte man so etwas halt mit Augenmaß.
Im FPC kann man den Operator ++ via Compilerswitch "freischalten", das ist immerhin schon etwas. Andererseits wird man das nicht verwenden, wenn man aus welchen Gründen immer eine (auch nur eventuelle, zufünftige) Kompatibilität zu Delphi im Hinterkopf behalten muss. Da wäre es schön, wenn Delphi nachziehen würde.

MitjaStachowiak hat geschrieben:was ich in Pascal vermisse, sind die diversen fest-eingebauten Funktionen, wie Array.sort(), Array.push(), Array.unshift(), String.indexOf

Ob ich string.indexof(x) schreibe oder die Funktion pos verwende, macht keinen großen Unterschied. Die objekt-orientierte Schreibweise gefällt mir auch marginal besser, aber ... pfff

MitjaStachowiak hat geschrieben:Dass Strings bei [1] anfangen und man Variablen und Funktionen (noch) nicht inline definieren kann, nervt auch,

Dass man in einer HÖHEREN Programmiersprache mit dem Zählen bei 0 statt bei 1 anfängt, ist reiner Schwachsinn. Ich finde es jammerschade, dass sich Pascal da bei offenen Arrays ohne Not an C angelehnt hat. Kein normaler Mensch fängt bei 0 zu zählen an, von ganz seltenen Ausnahmefällen einmal abgesehen, und das Offset eines Array-Elements vom Arrayanfang im Speicher interessiert mich als Anwendungsprogrammierer überhaupt nicht. Wir programmieren aus gutem Grund nicht mehr in Assembler!

Und was soll eine inline-Definition einer Variablen sein? Und Funktionen kann man doch als inline definieren.

MitjaStachowiak hat geschrieben:Syntax-Sünden, wie switch { case a : [...] break;

Sehr viel weiter daneben kann man eine Sprachsyntax nicht designen...
Die nächste Steigerungsstufe des Schwachsinns wäre dann eigentlich nur mehr "comefrom" statt "goto"

MitjaStachowiak hat geschrieben: Mehrfachvererbung ist für den Compiler ein Albtraum.

Was für den Compiler ein Alptraum ist, ist mir als Anwendungsprogrammierer eigentlich ziemlich egal. Aber Mehrfachvererbung kann zu Mehrdeutigkeiten führen, und das macht Programme schlechter wartbar und ist damit ein Argument gegen Mehrfachvererbung. Es ist im Prinzip das gleiche Problem, das die aktuelle with-Syntax produziert.

jedoch wäre es schön, wenn man auf die Eigenschaften der so mehrfach vererbten Ausdrücke per default über die Hauptklasse zugreifen könnte.

Das hätte die gleichen negativen Konsequenzen wie direkte Mehrfachvererbung.

MitjaStachowiak hat geschrieben:Aber z.B. Java ist wesentlich weniger "frei" als Pascal oder C aber gerade das ist der Grund, warum alle* Universitäten heute Java lehren.

java kann man als Interpretersprache nicht sinnvoll mit kompilierten Sprachen wie Pascal oder C vergleichen. Und natürlich bedingt die uneingeschränkte Portabilität von Java-Programmen, die auf jedem System mit Java-Framework laufen müssen, Einschränkungen, denn jede Art von direkter Nutzung spezifischer Hardware-Features müssen in dieser Sprache absolut tabu bleiben.

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: C ist "freier" als Pascal

Beitrag von Warf »

braunbär hat geschrieben:Ob ich string.indexof(x) schreibe oder die Funktion pos verwende, macht keinen großen Unterschied. Die objekt-orientierte Schreibweise gefällt mir auch marginal besser, aber ... pfff


Seit fpc 3.0.2 gibt es auch für Grunddatentypen wie Integer oder String die Dotted notation z.B.

Code: Alles auswählen

(2).ToString();
'str'.IndexOf('r');
(2.3).IsInfinity;
True.ToInteger;


braunbär hat geschrieben:Dass man in einer HÖHEREN Programmiersprache mit dem Zählen bei 0 statt bei 1 anfängt, ist reiner Schwachsinn. Ich finde es jammerschade, dass sich Pascal da bei offenen Arrays ohne Not an C angelehnt hat. Kein normaler Mensch fängt bei 0 zu zählen an, von ganz seltenen Ausnahmefällen einmal abgesehen, und das Offset eines Array-Elements vom Arrayanfang im Speicher interessiert mich als Anwendungsprogrammierer überhaupt nicht. Wir programmieren aus gutem Grund nicht mehr in Assembler!


In der kompletten Theoretischen Informatik wird mit 0 Angefangen zu Zählen, das hat verschiedene Gründe, zum einen das wir in der Informatik fast Ausschließlich auf Modulo Arithmetik arbeiten, also auf Mengen von 0 bis p-1 für eine Primzahl p. Es würde also für den Theoretiker keinen Sinn ergeben mit 1 Anzufangen. Aus Praktischer Sicht hat 0 den großen Vorteil dass jede Zahl mit 0 Multipliziert wieder 0 ergibt, und damit eignet sich das ganze hervorragend für Zeigerarithmetik.

Und da der einzige Vorteil mit 1 anzufangen ist, das es "natürlicher" ist, dann trainiere ich mir doch lieber an mit 0 anzufangen, und genieße dafür reale Vorteile.

braunbär hat geschrieben:Sehr viel weiter daneben kann man eine Sprachsyntax nicht designen...
Die nächste Steigerungsstufe des Schwachsinns wäre dann eigentlich nur mehr "comefrom" statt "goto"


Es ist alles Gewöhnungssache. Weder das Switch Case aus C, als auch das Select Case aus Pascal machen Intuitiv Sinn. Was ihr nicht vergessen dürft, ihr Programmiert seit ewigkeiten mit Pascal. Als ich demletzt Swift verwendet habe, eine Programmiersprache ohne Semikolons, viel es mir auch unfassbar Schwer mich daran zu gewöhnen keine Semikolone mehr zu tippen, obwohl keine Semikolone Objektiv betrachtet mehr sinn ergibt als Semikolone benutzen zu müssen.

Lustigerweise ist comefrom auch wenn es nur als Witz konzipiert wurde, für die Automatisierte verifikation besser als goto, da man damit besser Code auf erreichbarkeit überprüfen kann.

braunbär hat geschrieben:java kann man als Interpretersprache nicht sinnvoll mit kompilierten Sprachen wie Pascal oder C vergleichen. Und natürlich bedingt die uneingeschränkte Portabilität von Java-Programmen, die auf jedem System mit Java-Framework laufen müssen, Einschränkungen, denn jede Art von direkter Nutzung spezifischer Hardware-Features müssen in dieser Sprache absolut tabu bleiben.


Naja Java als Interpretersprache zu bezeichnen ist ganz schön Grenzwertig (bis hin zu Komplett falsch). Denn Java Code wird Kompiliert zu Maschinen Code, nur halt für eine Virtuelle Maschine, welche in der Realität gar nicht exsistiert. Die Aufgaben des Compilerbaus sind für die JVM sind die selben wie für Sprachen welche für eine Reale Maschinen ausgelegt sind. Immerhin kann der FPC ja auch Pascal Code in JVM Maschinensprache übersetzen.
Eine interpretierte Sprache wiederum unterscheidet sich grundlegend von Java, da dabei kein Kompilierprozess durchgeführt wird.

Grundsätzlich gilt die Regel, in Hochsprachen ist es eigentlich Egal wie die Compiler/Interpreter realisiert sind. Das spielt für die Sprachkonstrukte kaum eine Rolle.

C# z.B. wird wie Java für eine VM Kompiliert, beherscht dennoch Zeigerarithmetik.
Swift wird Kompiliert, vom Sprachdesign erinnert die Sprache aber deutlich eher an z.B. Python welches Interpretiert wird. Außerdem Teilt sich Swift viele Features mit Groovie, wobei Swift Kompiliert wird, und Groovie auf der JVM läuft.
Haskell teilt fast alle Paradigmen mit Lisp, wobei Lisp auf der JVM läuft und Haskell entweder Interpretiert oder Kompiliert wird.

Worauf ich hinaus will, der Programmierer sollte niemals Annahmen über eine Programmiersprache aufgrund ihrer Umgebung treffen oder umgekehrt. Wie die Sprachfeatures funktionieren hat den Programmierer nicht zu Interessieren (außer zur performance analyse), und daher können beliebige Konstrukte (natürlich im entsprechenden Kontext) analysiert und miteinander Verglichen werden.

Was man allerdings nicht machen kann ist z.B. Unendliche DatenObjekte wie sie Haskell kennt versuchen mit einer Imperativen Sprache wie Pascal zu vergleichen, da dies auf dem konzeptionellen Unterschied der Sprachen zurückzuführen ist, und damit niemals in Pascal umgesetzt werden könnte. Genauso kann man Prozeduale Programmierung nicht mit Java vergleichen, da Java rein OOP arbeitet

Was viel wichtiger ist, sind die Konzepte der Sprachen zu vergleichen. C ist dafür Konzipiert möglichst Maschinenähnlich zu arbeiten, während Pascal mehr versucht mathematische Konzepte zu Realisieren, und damit von der Tatsächlichen Maschine zu abstrahieren (z.B. Sets), allerdings immer noch Verbindungen zu Unterliegenden Maschine zu haben, im gegensatz zu z.B. Swift oder Haskell welche komplett von der Tatsächlichen Maschinenimplementierung abstrahieren.
Somit würde es mehr Sinn ergeben Pascal zu C++ oder Ada zu vergleichen als zu C.

Die Zeit in der man Pascal mit C vergleichbar war, waren allerhöchstens vor ObjectPascal, seit dem ist ein Vergleich mit C etwa so Passend wie ein Vergleich von Java 8 zu der 1970er Version von Pascal


Außerdem, C ist mitlerweile eine reine Nieschensprache (auch wenn die Niesche sehr groß ist), und wird außerhalb der Elektrotechnik, und dem Betriebsystembau kaum noch verwendet. Der Vergleich von Pascal mit C hinkt also in jeder Hinsicht. Viel Interresanter ist es da Pascal mal zu neuen Sprachen/Neuen Konstrukten zu vergleichen.
Generell kann ich sagen, nachdem ich für die Uni ein Projekt in Swift gemacht habe, und nun wieder zu Pascal zurückgewechselt bin, gibt es doch schon sehr viele Dinge die Swift deutlich besser macht als Pascal. Die Vermeidung von Null-Pointern außer es wird mit dem ? operator explizit gekennzeichnet, oder enums die variablen Speichern können, alles herforragende Konstrukte die ich mittlerweile in Pascal sehr vermisse.

Man merkt deutlich das moderne Sprachdesigner versuchen Fehler aus der Vergangenheit (z.B. Nullpointer) zu umgehen, ohne dabei die guten Konzepte die wir bereits kennen (z.B. Null als Nichts u.a. in linked Lists als Listenende) über den Haufen zu werfen.

Pascal hat immerhin mitlerweile Hilfsklassen (auch wenn diese Leider keine Felder enthalten können), Variante Records, Operator overloading, dotted notation für Grunddatentypen, und viele weitere Features. Leider ist Pascal bei sowas immer sehr langsam (der Typische Ablauf ist normalerweise: Neues Feature taucht auf, ein paar Jahre später kommt es zu Delphi hinzu, und dann wird es in fpc übernommen). Ich fände es deutlich besser wenn sich die Entwickler vom FPC mal was trauen würden, und z.B. Referenzgezählte eigene Typen einbauen würden, oder Funktionale Features wie erweiterte Listen(arrays) zu Implementieren. Es muss ja nicht per Default aktiviert werden, sondern z.B. per Compilerswitch.

Es gibt ja, was einige nicht wissen, den AutoDeref Switch, mitdem man Zeiger auf Records nicht mehr dereferenzieren muss, und damit die lästige ^ Syntax wegfällt.

Antworten