Wieso ist property nicht änderbar ?

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Mathias
Beiträge: 5073
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunc)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Wieso ist property nicht änderbar ?

Beitrag von Mathias »

Turbo Pascal hast du noch vergessen. Das kannte auch schon Objekte.
Zuletzt geändert von Mathias am Sa 26. Sep 2020, 07:49, insgesamt 1-mal geändert.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot

Winni
Beiträge: 402
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.06, fpc 3.04
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Wieso ist property nicht änderbar ?

Beitrag von Winni »

Hallo!

Ja, stimmt.

Am Ende der Turbo-Laufbahn hat Borland schon
mal ein bischen geübt.

Winni

Warf
Beiträge: 1491
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Wieso ist property nicht änderbar ?

Beitrag von Warf »

Winni hat geschrieben:
Fr 25. Sep 2020, 22:51
Records waren schon in N. Wirths erster Version von Pascal vorhanden also ~ 1970.
Haben dann viele Sprachen abgekupfert und - damit es nicht so peinlich ist - gleich anders
genannt.
Also wenn wir schon das Geschichtsbuch aufmachen, dann war die erste "geläufige" Sprache die Kompositionstypen erlaubte wohl Algol 68, welches die teile bereits schon struct nannte (übrigens hatte Algol68 auch schon unions). Dann kam Wirth an und hat gemeint das record doch ein viel einleuchtenderer Name wäre und hat das dann so in Pascal eingebaut. In C widerum hat man dann wieder den namen aus algol verwendet. Und da C so ziemlich die einflußreichste sprache der Computergeschichte ist, heißt es überall anders jetzt auch struct.

Weder Pascal noch C haben wirklich groß das Rad neu erfunden, sondern waren beide praktisch eine Akkumulation von den Ideen die in anderen Sprachen vorher waren. Tatsächlich finde ich es interressant wie die Sprachen aber designed sind. Ein einfaches konzept wie Kompositionstypen heißt in Pascal records um den Vergleich zu Datenansammlungen aus der physischen Welt zu ziehen, während es in C (oder auch Algol) structs heißt, da man damit seinen speicherinhalt strukturieren kann.
Daran erkennt man die unterschiedliche Designphilosophie von Pascal und C, Pascal geht sehr didaktisch ran, C eher pragmatisch und technisch. ^ für pointer ist grundsätzlich eine gute idee, das symbol sieht so ein bisschen aus wie ein pfeil. Warum hat C das nicht übernommen? Ein wort: Înteger :mrgreen:
C's * ist zwar nichtssagend, aber dafür einfach zu tippen

Winni
Beiträge: 402
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.06, fpc 3.04
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Wieso ist property nicht änderbar ?

Beitrag von Winni »

Hi!

Also Algol 60 hatte keine Records.
Das kam erst als N. Wirth (und Hoare) dazugestossen sind.
Mitte der 60er.

Wirth hat dann in Pascal gleich mal was anderweitig als struct und union bekannt ist,
in den varianten Records vereinigt.

Das Wichtige, das Wirth gebracht hat, ist der Sicherheits-Aspekt:
Type-Sicherheit, die Notwendigkeit vom expliziten Casten und das
"Verstecken" von Pointern, solange es geht.

In C ist der wichtigste Datentyp der Pointer.
In Pascal tritt er erst in Erscheinung, wenn man ne verlinkte Liste
braucht. Wie ein Ringbuffer. Für "Fortgeschrittene"

Über die Lesbarkeit von C-Programmen wollen wir dann mal lieber
nicht reden. Man könnte das auch lesbar codieren.
Wie manche Demo- und "How-To"-Programme beweisen.
Aber die C-Jungs wollen ja immer die Welt in einer Zeile unterbringen.

Buena note
Winni

Warf
Beiträge: 1491
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Wieso ist property nicht änderbar ?

Beitrag von Warf »

Winni hat geschrieben:
Sa 26. Sep 2020, 01:36
Hi!

Also Algol 60 hatte keine Records.
Das kam erst als N. Wirth (und Hoare) dazugestossen sind.
Mitte der 60er.
Ich glaube das Wirth und Hoare damals als es um einen Nachfolger zu Algol 60 ging, ein proposal gemacht hatten (Algol W glaub ich). Das wurde allerdings nicht angenommen. Es gab glaub ich ne ganze menge proposals, und am ende is in Algol 68 so zu sagen ein "best of" der Ideen gelandet. Wenn man also mal von der Referenzimplementierung von Algol W absieht, da das ja nur ein vorschlag war, war dann Algol 68 die erste Sprache die das wirklich drin hatte.

Das gesagt, zum Thema pointer, ja C versteckt keine Pointer. Aus sicht der C entwickler machts ja auch Sinn, wenn du C benutzt schreibst du grade ein betriebsystem, wer da probleme mit pointern hat hat eh schon verloren. Hätte ja keiner ahnen können das man die sprache später auch noch für was anderes außer OS Kernels benutzt. :mrgreen:

Und die lesbarkeit von C ist in den allermeisten fällen gar nicht so schlimm wie oft gesagt wird. Ich hab demletzt mich mit dem Source der Core-Utils auseinander setzen müssen, und ich kann mich nicht beschweren, alles relativ verständlich.
In C kann man halt mehr ausdrücken (bzw. auch sachen einfacherer ausdrücken). In Pascal musst du um einen Typisierten pointer zu verwenden, den vorher als typen definieren (also z.b. "(Integer^)(p)^ := 42" geht nicht), in C geht das inline (also "*((int *)p) = 42" geht).
Und dann läuft man plötzlich in so probleme wie, wenn ich inline alle typen darstellen können muss, wie stell ich funktionspointer da, und wie funktionspointer von funktionen die funktionspointer zurückgeben, etc. Und dann kommen so grausige konzepte wie "(void *(void)) *fp[](int)" zustande.
In Pascal geht sowas einfach nicht so einfach, da man hie für jeden subtyp einen eigenen typen definieren muss, damit umgeht man zwar solche mosterkonstrukte, läuft aber dafür dann in so probleme das man für jeden scheiß einen eigenen typen definieren muss selbst wenn man den nur an einer stelle braucht. Und wenn man dann noch sowas wie generics hat dann läuft man in sowas:

Code: Alles auswählen

generic alloc<T>(const count: SizeInt): ^T; // geht nicht da ^T separat definiert werden muss
// Workaround
type generic TGenericPointerTypeProvider<T> = record
  type PT = ^T;
end;
generic alloc<T>(const count: SizeInt): specialize TGenericPointerTypeProvider<T>.PT;
Gegenbeispiel C++ (da C keine generics hat):

Code: Alles auswählen

template <typename T>
T *alloc(const count: size_t);
Also da find ich die C++ variante doch deutlich lesbarer.

Ist halt immer eine abwägung, C erlaubt halt mehr, dabei kann auch mehr schweinerei entstehen, während man in Pascal z.T. zu dämlichen workarounds gezwungen wird durch die restriktionen der Sprache.

Eine sache die ich bei Mode Delphi z.B. ganz schlimm finde (da ich für generics meist Delphi mode verwende) ist einfach das man pointer nicht als arrays benutzen kann. Bzw. das nur bei bestimmten typen wie Byte geht. Das erlaubt zum Glück Mode ObjFPC, aber das ist halt eine von den restriktionen die letzendlich dazu führen das der code massenhaft unlesbarer wird:

Code: Alles auswählen

elem := PDataType(@PByte(dataPtr)[index * SizeOf(TDataType)])^; // delphi
elem := dataPtr[index]; // objfpc
Eine zu strikte sprachdefinition kann also die lesbarkeit mehr einschränken als das es sie fördert

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

Re: Wieso ist property nicht änderbar ?

Beitrag von Mathias »

Winni hat geschrieben:
Sa 26. Sep 2020, 01:11
Hallo!

Ja, stimmt.

Am Ende der Turbo-Laufbahn hat Borland schon
mal ein bischen geübt.

Winni
Und sie haben es schon recht gut gemacht, siehe TurboVision.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot

Antworten