Wenn man sich was wünschen dürfte...

[stahli]

Unabhängig von konkreten und existierenden Programmiersprachen habe ich mal einige grundsätzliche Überlegungen bzw. Fragen, was Ihr generell als sinnvoll bzw. zweckmäßig ansehen würdet.

Ich will hier keine Pascal-Änderungen anregen, sondern einfach mal ein paar grundsätzliche (quasi philosophische) Überlegungen anstellen und diskutieren - wem das gelingt auch gern unter Berücksichtigung der Sicht eines Programmieranfängers.

„Das war aber schon immer so“ und „das kennt man halt so“ wären natürlich legitime Standpunkte, mir geht es aber darum, was der sinnvollere Ansatz ist. In dem Fall würde ich die Fragen halt so stellen: Hätte man nicht damals besser….


1) 1-basierte Listen

Ich fände generell 1-basierte Listen sinnvoll.
Wenn ich 3 Autos habe, dann zähle ich die abends in der Garage ja auch immer von 1 an durch.
In einer Hochsprache finde ich 0-basierte Listen umständlich und unnötig.


2) Werte- und Referenzzuweisungen

Delphi-Quellcode:

I1, I2: Integer;
I2 := I1; // kopiert den Wert. Änderungen in I1 wirken sich nicht auf I2 aus und umgekehrt

P1, P2: TPerson;
P2 := P1; // kopiert den Zeiger, also "beinhalten" P1 und P2 das gleiche Objekt (die gleiche Person). Änderungen „in P1“ (Vornamenänderung) wirken sich auch auf P2 aus und umgekehrt.

Wäre es generell nicht sinnvoll, das zu vereinheitlichen?

Delphi-Quellcode:

I2 := I1; // kopiert den Wert
I2 -> I1; // lässt I2 den Inhalt von I1 referenzieren

P2 := P1; // würde eine Objektkopie erzeugen (andere Speicherstelle (und wenn das Objekt über eine ID verfügt auch andere ID) , wobei alle Propertys (einschließlich anderen Referenzen wie z.B. Vater und Mutter als Personenobjekte) kopiert würden
P2 -> P1; // lässt P2 den Inhalt von P1 referenzieren

Als Parameter könnte man das ähnlich regeln:

Delphi-Quellcode:

MyProcedure(I: Integer; P: TPerson); // beides KEINE Referenzen sondern Datenkopien
MyProcedure(-> I: Integer; -> P: TPerson); // beides als Referenzen (wie im Delphi var-Parameter)

Allerdings bin ich mir selbst nicht sicher, wie die beste Lösung aussehen sollte.
Der Vorteil des „->“ (gelesen: "referenziert") wäre, dass es zwischen primitiven Werten und Businessobjekten dann nicht mehr unterschiedliche Verfahrensweisen geben würde.
Andererseits würde die klassische Zuweisung von Objektinstanzen nicht (mehr) das tun, was man landläufig kennt.

Delphi-Quellcode:

Person.Chef := Cheffe

würde eben eine Datenkopie von Cheffe erzeugen und zuweisen, was man sicher seltenst benötigt. Viel eher will man wohl tatsächlich i.d.R. ein anderes Objekt referenzieren.
Logisch wäre somit dann

Delphi-Quellcode:

Person.Chef -> Cheffe

Eine Schreibweise mit „:=“ würde bei (Business)Objekten dann so gut wie nicht mehr vorkommen.

Positiv wäre, dass man in Anweisungen und bei Übergabeparametern sowohl bei primitiven Typen als auch bei Businessobjekten immer eine einheitliche Schreib- und Verfahrensweise hätte.


3) Strings im Quelltext

So etwas ist ja ziemlich umständlich:

Delphi-Quellcode:

S := Vorname + ' ' + Nachname + '(' + Ort + ')';

C# bietet so etwas:

Delphi-Quellcode:

S := String.Format("{0} {1} ({2:x})", Vorname, Nachname, Ort) // wobei das x für Formatierungsregeln steht

Wäre es nicht sinnvoll, so etwas zu haben wie:

Delphi-Quellcode:

S := '<Vorname> <Nachname> (<Ort:x>)'

Wenn man noch Regeln unterbringen will wie bedingte Leerzeichen, wird es schon schwieriger:

Delphi-Quellcode:

S := '<Vorname><? ?><Nachname> (<Ort:x>)' // <? ?> steht hier für einen bedingtes Leerzeichen bzw. Text, wenn beide Bezeichner rechts und links keine leeren Strings enthalten

Verkürzt könnte man es noch so schreiben:

Delphi-Quellcode:

S := '<Vorname? ?Nachname> (<Ort:x>)'

(Eine einfache und logische Lösung für den Fall, dass man z.B. die Klammern nur will, wenn der Ort und der linke Text nicht leer sind fällt mir hier erst mal nicht ein. Klassisch würde man ja S1, S2 und S3 als Trenner festlegen und den Ergebnisstring dann zusammenbauen. Das wird man vielleicht nicht umgehen können aber vielleicht kann man bestimmte Standardkriterien durch einfache Regeln abbilden.)

Der Parser müsste natürlich die Klammern interpretieren können.
Der Editor müsste umschaltbar sein, so dass man entweder die Klammern (Formatanweisungen) sieht oder diese ausblendet werden und die Darstellung auf die farbigen Bezeichner reduziert wird.
S := 'Vorname Nachname (Ort)'
(So ähnlich, wie man im Word Felder und Formeln unterschiedlich anzeigen kann.)

[Sir Rufo]

1. 0-basiert ist doch genau richtig.
   
   Gerade wenn man ein Raster in einer Liste unterbringt, dann ist die Berechnung über die Koordinaten super simpel:
   
   Delphi-Quellcode:

   var
     LIdx, x, y : Integer;
   
   LIdx := x + y * ColCount;

   Oder das ganze zurück:
   
   Delphi-Quellcode:

   x := LIdx mod ColCount;
   y := LIdx div ColCount;

2. Delphi-Quellcode:

   x := y;

   ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.
   
   Die Variable
   Delphi-Quellcode:

   var foo : TObject;

   hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.
   
3. Gibt es schon in C# 6.0
   
   Code:

   var test = "Moin";
   var str = $"{test}";

[Stevie]

3) String Interpolation - sehr schönes Feature, wie auch die anderen in C# 6.0, die nicht revolutionär sind, aber den Code vereinfachen.

Meine Prognose - wird es in Delphi in den nächsten 10 Jahren nicht geben, weil der Fokus zu sehr auf RAD liegt.
Die Devise: "Null Zeilen Code schreiben, dafür gibts ne Komponente" (die das ganze dann macht und dafür zigtausende Zeilen Framework Code durchläuft)

[mm1256]

Zitat:

Zitat von stahli (Beitrag 1316125)

3) Strings im Quelltext

So etwas ist ja ziemlich umständlich:

Delphi-Quellcode:

S := Vorname + ' ' + Nachname + '(' + Ort + ')';

Ich finde das oftmals sogar praktischer und leicht lesbarer als die Format-Funktion von Delphi. Und wenn's mal Strings mit Trennzeichen oder Begrenzer sein sollen, auch abhängig vom Inhalt des Strings, dann gibt's dafür die eigene kleine Toolsammlung. Die tut dann auch genau das, was ich von ihr erwarte. Als Standard-Funktion würde ich das gar nicht haben wollen.

Aber, wenn ich schon ein paar Wünsche frei hätte, dann würden diese weniger in Richtung Spracherweiterung, sondern mehr in Richtung IDE-Verbesserung gehen. Dann hätte ich z.B. gerne einen Code-Formatierer der meinen Code genauso formatiert wie ich ihn haben will, und mich gleich beim Schreiben entsprechend unterstützt. Der bei Vervollständigung der Prozeduren und Funktionen mit [Strg]+[Shift]+[C] diese nicht alphabetisch anordnet, sondern so wie ich es für richtig erachte: Zuerst Form-Events, dann Komponenten-Events, dann "private" und "public".

[Stevie]

Es geht nicht nur um die Lesbarkeit des Codes sondern auch um die Einfachheit, Strings zu lokalisieren. Lokalisier mal nen string, der aus zig Einzelschnipseln im Code zusammen getackert wird.
"Dafür gibts ja Format", sagt jetzt jemand. Jup, und dann lokalisier doch mal nen String, der da lautet "Der %s %s wohnt in %s" ohne den Kontext zu kennen (vor allem wenn dann noch Sprachen dazu kommen, bei denen die Grammatik anders funktioniert. Ein String, der da lautet "Der {vorname} {nachname} wohnt in {ort}" ist dann wohl unmisverständlich (klar, der übersetzer muss nun nur noch wissen, dass die Dinger, die zwischen {} stehen nicht übersetzt werden, weil das Variablen namen sind. :)

Der einzige Knackpunkt daran wird wohl nur das Refactoring von Variablennamen sein, aber das ist das Problem des Toolings.

[Rollo62]

Ich bin auch für 0-basierte String und StringListen sowieso, ist dann endlich kompatibel zu C/C++ Code.

Ausserdem sind die neuen MobileCompiler sowieso 0-basiert.

Ich baue gerade meine Libraries nach und nach auf 0-basiert um.
Da gibt es schöne TStringHelper ClassHelper die man dafür nehmen sollte.

Rollo

[Bjoerk]

Hattest du dieses Thema nicht schon mal? Bin ganz klar für 1 basiert. Jeder der anfängt zu programmieren, baut Schleifen 1..N. Notfalls könnte man ja das Offset auch angeben (geschieht bei statischen Arrays ja sowieso). Anderseits ist es ja aber auch kein Problem sich seine eigene Classes1 zu schreiben. Habe z.B. ich gemacht, weil mein Statik-Kram 1 basiert ist (historisch bedingt). An den Wertetypen hingegen würde ich nichts ändern.

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1316126)

Delphi-Quellcode:

x := y;

ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.

Die Variable

Delphi-Quellcode:

var foo : TObject;

hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.

Dafür muß man das aber auch wissen!
Immer wieder beliebt ist doch auch

Delphi-Quellcode:

  A1 : array[0..5] of word;
  A2 : array of word;
  pWrd : word;

begin
  setlength(A2,6);
  pwrd:=@A1;
  pwrd^:=5;
  pwrd:=@A2;
  pwrd^:=5;
end;

Un nun kommt die Frage "warum steht in A1[0] 5 und in A2[0] nicht?
Das sind doch beides Arrays?"

Gut wir wissen, daß ein dyn.Array etwas anderes ist als ein statisches, aber einem unvoreingenommenen Leser erschließt sich das eben nicht auf den ersten Blick.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1316155)

Zitat:

Zitat von Sir Rufo (Beitrag 1316126)

Delphi-Quellcode:

x := y;

ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.

Die Variable

Delphi-Quellcode:

var foo : TObject;

hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.

Dafür muß man das aber auch wissen!

Wissen sollte man das, wird ja oft genug allenortens vorgebetet. Gehört sozusagen zum OOP-Basiswissen.

Zitat:

Zitat von p80286 (Beitrag 1316155)

Immer wieder beliebt ist doch auch

Delphi-Quellcode:

  A1 : array[0..5] of word;
  A2 : array of word;
  pWrd : word;

begin
  setlength(A2,6);
  pwrd:=@A1;
  pwrd^:=5;
  pwrd:=@A2;
  pwrd^:=5;
end;

Un nun kommt die Frage "warum steht in A1[0] 5 und in A2[0] nicht?
Das sind doch beides Arrays?"

Gut wir wissen, daß ein dyn.Array etwas anderes ist als ein statisches, aber einem unvoreingenommenen Leser erschließt sich das eben nicht auf den ersten Blick.

Habe mal wegen diesem Codeschnipsel gefragt:

Zitat:

Computer sagt: Nein.

Sprich, das wird noch nicht einmal kompiliert.

Das hier schon

Delphi-Quellcode:

var
  a1   : array [ 0 .. 5 ] of word;
  a2   : array of word;
  LWord: Pword;
begin
  SetLength( a2, 6 );
  LWord  := @a1[ 0 ];
  LWord^ := 5;
  Assert( a1[0] = 5 );
  LWord  := @a2[ 0 ];
  LWord^ := 5;
  Assert( a2[0] = 5 );
end;

Und was soll ich sagen ... so wie es jeder unvoreingenommene Leser erwarten würde, alles im grünen Bereich.

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1316132)

"Dafür gibts ja Format", sagt jetzt jemand. Jup, und dann lokalisier doch mal nen String, der da lautet "Der %s %s wohnt in %s" ohne den Kontext zu kennen (vor allem wenn dann noch Sprachen dazu kommen, bei denen die Grammatik anders funktioniert. Ein String, der da lautet "Der {vorname} {nachname} wohnt in {ort}" ist dann wohl unmisverständlich (klar, der übersetzer muss nun nur noch wissen, dass die Dinger, die zwischen {} stehen nicht übersetzt werden, weil das Variablen namen sind. :)

Hihi, dass damit die Übersetzung auf einmal leichter wäre ist ein Fehlschluss. Das mag in Deutsch und Englisch so klappen, aber man muss sich bei sowas im Hinterkopf behalten, dass es genügend Sprachen gibt, in denen du den Ort nicht einfach so per Format reinsetzen kannst, sondern ihn deklinieren musst :wink:
Man macht sich das schnell ein bisschen zu einfach, und ein Großteil der Programmierer auf der Welt denkt da recht anglozentrisch, und auch im Deutschen wird ja wirklich wenig dekliniert. Gibt es für <Ort> nur eine feste Auswahl, geht es ja auch noch, hinterlegt der Übersetzer eben mehrere Versionen davon - aber dann kommt der Fall, wo <Ort> eine Nutzereingabe ist.

Also, spielen wir das mal durch. Du fragst in einem Formular u.A. nach dem Wohnort einer Person, und bildest daraus einfache Sätze. Maria gibt Helsinki an, und als zukünftigen Wohnort Kuopio.

Zitat:

Maria wohnt in Helsinki.
Maria zieht nächste Woche von Helsinki nach Kuopio.

Klappt doch, oder?

Zitat:

Maria lives in Helsinki.
Next week Maria moves from Helsinki to Kuopio.

Na wer sagt's denn?

Zitat:

Maria asuu Helsingissä.
Ensi viikolla Maria muutaa Helsingistä Kuopioon.

Uppsi :oops:

Also bitte hört auf, euch einzureden, Stringformatierung würde eure Übersetzungsprobleme lösen. Es tut wirklich sehr weh. Lokalisierung ist ein ziemlich f#ck$ng schweres Thema, bei dem einfache Formatierung und Interpolation aber schlichtweg kaum was wert sind.

[Dejan Vu]

Zum Thema 'Zuweisung'... Irgendwie habe ich mich daran gewöhnt, das es Referenzen und 'echte' Werte gibt. Insofern macht mir das nichts aus, das es einen Unterschied in der Semantik zwischen 'a:=b' und 'a:=b' gibt :stupid:

Die weiter oben gezeigten -mal wieder- konstruierten Beispiele werden in der Praxis nur von Selbstkasteiungsfetischisten verwendet.

Wenn ich mir das so überlege, gibt es das hier bei mir eigentlich nie:

Delphi-Quellcode:

Var
  a, b := TFoo;

Begin
  a := TFoo.Create;
  b := a;
  b.Bar := 'Foo';
  if a.Foo='Bar' then

D.h. ich verändere Kopien von Objektinstanzen NIE.

@implementation: Das ist sehr interessant. Gottseidank (oder vielmehr: Hoffentlich) betrifft das nur wenige Sprachen... :gruebel:

[bepe]

1. Wäre das nicht ziemlich unpraktisch und unlogisch? Wenn kein Bit gesetzt ist dann hat ein Zähler den Wert 0 und nicht 1. Auch beim Positionieren/Auffinden von Einträgen in "selbst verwalteten Listen" ist das so sinnvoller. Sprich ich habe einen Speicherblock und bestimme die Position eines Eintrags einfach per: Blockanfang + (Eintrag Größe * Zähler). 1 basiert würde das nicht passen.

Klar, du redest von Listen und meinst mit Sicherheit Klassen wie StringList, ObjectList etc.. Aber das würde es ja noch uneinheitlicher machen, wenn nur die bei 1 beginnen.

2. Ein Grund mehr der gegen 1. spricht. Je mehr das Framework oder der Compiler uns von grundlegenden Strukturen und Techniken fern hält, desto leichter verliert man das Bewusstsein für das was man macht.

Wie z.B. hier. Wie bereits erwähnt, wird hier nicht mit Objekten hantiert sondern mit einfachen "Zahlen" Werten jongliert. Aber das Bewusstsein dafür gerät schnell in den Hintergrund da der Compiler das De- Referenzieren für uns übernimmt.

(Das soll keine Rede gegen Hochsprachen oder Vereinfachungen sein.)

3. Das ist doch genauso umständlich? Ob ich jetzt Anführungszeichen oder Spitzklammern und Steuersymbole tippe. Sehe gegenüber Format, ggf. mit ein par IfThen, keinen Vorteil (ja, gut die Platzhalter hätten einen sprechenden Namen...). Aber String Operationen würden langsamer da der Compiler jedes Mal implizit einen Parser anwerfen muss. Das müsste per OptIn gesteuert werden... evtl. ein Prefix, sowas wie z.B. Format :stupid:

Und zum Thema Übersetzung und Lokalisierung... Da gibt es eine einfache Lösung: Keine String Literale im Quelltext verstreuen. Wer sowas macht verdient es gar nicht seine Texte wiederzufinden ;) Und wenn man schon Übersetzen muss, dann kann man sie gleich auf Resourcestrings oder ähnliches umstellen. Ein Austauschen von Wörtern, innerhalb eines Satzes, ist keine Übersetzung. Man muss also eh eine "echte" Lösung finden.

[uligerhardt]

Zitat:

Zitat von Dejan Vu (Beitrag 1316159)

@implementation: Das ist sehr interessant. Gottseidank (oder vielmehr: Hoffentlich) betrifft das nur wenige Sprachen... :gruebel:

Du Optimist. :mrgreen:
Auf jeden Fall gibt's das in Polnisch auch. Dann vermutlich auch in Russisch und anderen slawischen Sprachen. Da kommen dann schon mal ein paar Sprecher zusammen. ;-)

[Jumpy]

Jetzt haben ja alle schön gegen Stahlis 1-3 gewettert. Wer bringt den mal 4-6 oder 7-10? Oder traut sich jetzt keiner mehr was zu sagen, da es dazu dann direkt wieder die Gegenposition gibt? Oder sind alle wunschlos glücklich?

Ich hätte gerne einen Compiler, der das macht was ich mir wünsche und vorstelle, und nicht das, was ich unwissender tatsächlich geschrieben habe. So ein schlauer (BTC*-)Compiler würde dann merken, dass ich eigentlich "for i:=0 to List.Count-1" meine obwohl ich "for i:=1 to List.Count" geschrieben habe und somit wäre Problem 1 auch gelöst :zwinker:.


*BTC: BrainToCode :-D

[baumina]

Meine Vorstellungen sind, dass ich irgendwann meinem Computer nur noch sagen muss:
"Hier möchte ich einen neuen Knopf. Wenn ich diesen Knopf drücke, soll die Bestellung an XY gemailt werden und die Artikel im Lager als bestellt gebucht werden", daraufhin wird ein Programmcode automatisch erstellt.

Einziger Nachteil an der Geschichte ist, dass mein Beruf ausstirbt und ich arbeitslos bin, aber zum Glück passiert das ja erst, wenn ich in Rente bin oder schon nimmer lebe.

[stahli]

Ihr seid ja ganz schön gemein! ;-(

Die letzten zwei Vorschläge sind aber gar nicht so übel.
Das vereinfacht nochmal einiges. ;-)

[Sir Rufo]

Ich wüsste nicht was da jetzt gemein ist.

Hast du ein kollektives Kopfnicken erwartet oder eine sachliche Diskussion, wo alle Pros&Cons auf den Tisch kommen?

Gemein wäre es, wenn wir alle mit dem Kopf nicken, dich ermutigen noch mehr Fahrt aufzunehmen und warten bis du mit Vollgas gegen die Wand gefahren bist. :stupid:

[stahli]

Nee, nur die letzten zwei Vorschläge waren etwas gemein. :-)

Es war schon zu erwarten, dass da einiger Gegenwind kommt. Aber mit etwas Zustimmung hätte ich schon gerechnet.
In meiner Welt sind das eigentlich selbstverständliche Anliegen, die jeder unterstützen müsste. :stupid:

[Pfaffe]

Hallo baumia, sowas in der Art wäre es wohl?
http://www.ingenieur.de/Themen/Softw...-Software-Code

Warum wollt Ihr die Programmiererei immer optimieren, die macht doch nur max. 10% bei einem Projekt aus?
Was ist eigentlich so gut daran, dass eine weitere Person meinen Quellcode verstehen kann? Wir sollte uns an Steuerregeln, Hartz 4-Regeln, Energieeinsparberechnungen, usw. orientieren. Die versteht auch Niemand, und davon leben ganze Berufsgruppen.

[Sir Rufo]

Auch die letzten beiden Vorschläge sind nicht gemein, sondern theoretisch sogar jetzt schon machbar.

Nehmen wir mal an, dass das fertige Programm eine Größe von 2MB hat, dann kann man durch alle möglichen Kombinationen von Byte-Werten iterieren und hat am Ende jedes Programm, dass bis zu 2MB gross ist. Zusätzlich hat man auch jedes Bild, jeden Text (in jeder Sprache, sogar in der, die es bis jetzt noch nicht gibt), etc.

Jetzt muss man nur noch einen Test schreiben, um zu prüfen, welche Permutation meinem Gusto entspricht und gaaaaaaanz viel Zeit haben. :stupid:

[Codehunter]

Also ob Listen nun 0- oder 1-basiert sind, das ist mir eigentlich ziemlich egal. Stören tut mich allenthalben, dass das so inkonsistent ist. Die meisten TIrgendwasList sind 0-basiert, Strings sind 1-basiert. Ich will gar nicht wissen wie oft ich mich schon bei Copy() verheddert habe weil ich unbewusst immer 0-basiert denke.

Aber das heute noch zu ändern dürfte kaum mehr möglich sein ohne die Kompatibilität über Board zu werden. Und umschaltbar per Compilerschalter macht die Sache nur noch unsinniger.

Bzgl. Referenzen und Speicherkopien: Ich frage mich schon lange, warum es in Delphi drei Varianten gibt:

Delphi-Quellcode:

procedure Foo(A: Typ);
procedure Foo(var A: Typ);
procedure Foo(const A: Typ);

Hier dürften doch Variante 1 und 3 so ziemlich das selbe sein. So richtig schick wird das dann in diesem Fall:

Delphi-Quellcode:

procedure Foo(const A: PString);
begin
   A^:= 'XYZ';
end;

procedure Bar;
var
   B: String;
begin
   B:= 'ABC';
   ShowMessage(B); // "ABC"
   Foo(@B);
   ShowMessage(B); // "XYZ"
end;

Mir ist schon klar WARUM das funktioniert. Mich nervt nur der Stil, den man in vielen (kommerziellen) Units findet. Da wird zwischen Referenzen und Zeigern wild hin und her gecastet. Das geht sogar soweit dass man Zeiger auf Zeiger referenziert.

Bzgl. Lokalisierung stimme ich euch voll und ganz zu. Es gibt tausendundeine Möglichkeit wie man das realisieren kann. Der offizielle (Borland-) Weg über Resourcen-DLLs hat mir noch nie gefallen. Viel zu sperrig das ganze. Ich nutze dafür lieber INI-Dateien und hatte mir seinerzeit (für Delphi 7) einen eigenen INI-Parser geschrieben. Den Rest darf man dann natürlich auch "zu Fuß" machen. Am besten gehts wenn man sein Projekt von Anfang an auf MUI hin konzipiert.

[Sir Rufo]

Zitat:

Zitat von Codehunter (Beitrag 1316237)

Mir ist schon klar WARUM das funktioniert.

Und es verletzt auch nicht die Regel bei

Delphi-Quellcode:

const

Parametern. Denn der Wert ist der Zeiger und nicht das worauf der Zeiger zeigt. Den Zeiger kann ich dort nicht verändern, aber sehr wohl das, worauf der Zeiger da zeigt. ;)

[implementation]

Zitat:

Zitat von Codehunter (Beitrag 1316237)

Bzgl. Referenzen und Speicherkopien: Ich frage mich schon lange, warum es in Delphi drei Varianten gibt:

Delphi-Quellcode:

procedure Foo(A: Typ);
procedure Foo(var A: Typ);
procedure Foo(const A: Typ);

Tatsächlich gibt es auch noch eine vierte, wenn auch seltene :stupid:

Delphi-Quellcode:

procedure Foo(out A: Typ);

[bernd2015]

Fände es SEHR wünschenswert, wenn man sich an Beiträge angehängte Screenshots ohne Anmeldung/Registrierung ansehen könnte!

[stahli]

So, bin jetzt ohne Aufsicht und kann mir etwas mehr Zeit nehmen...

Also ich akzeptiere natürlich alle Argumente, sehe das aber immer noch etwas anders. Vielleicht kann ich das noch etwas genauer erklären...


1) 0-basiert

Wenn man in Listen Blöcke unterbringen will muss man natürlich mit 0 rechnen um zu einer bestimmten Position zu kommen.
Man kann zu dem Ergebnis aber dann auch problemlos 1 hinzu zählen, auf den tatsächlichen Eintrag zu kommen.
Dafür spart man sich das sonst immer wiederkehrende ... to List.Count - 1.
Ok, bei foreach ist das auch nicht mehr so interessant.

Letztlich ist es Geschmackssache.

Ich sehe es in dem Falle eher aus Beginner-Sicht. Wenn ein Schüler eine Liste mit 10 Einträgen durchlaufen soll wird er bei 1 anfangen.


2) Zuweisungen

Das ist schon etwas schwieriger.

Aber wenn man auch hier einem Schüler über die Schulter schauen würde, würde er sich mit einer "vermeintlichen" unterschiedlichen Handhabung anfänglich eher schwer tun.
Natürlich wird der Pointer kopiert aber es fühlt sich anders an (für mich jedenfalls ;-)).


3) Strings + Bezeichner im Quelltext

Die Lokalisierung hatte ich da gar nicht im Fokus sondern einfach die Lesbarkeit des Quelltextes.
Der Quelltexteditor ist ja auch eine graphische Schnittstelle - halt für den Programmierer.
Im Sinne von WYSIWYG könnte doch der Codeeditor hier auch eine Roh- und eine formatierte Sicht auf den Code bieten.
Im Normalfall werden dann die Formatierungsdetails ausgeblendet und wenn man sie braucht zeigt man sie halt an und kann sie bearbeiten.

[EDIT] Ein Refactoring von FirstNamme in FirstName könnte die IDE auch realisieren, wenn der Bezeichner in spitzen Klammern steht. Dazu muss halt sowohl der Editor als auch der Parser damit umgehen können.

Aus meiner Sicht wäre das eine klare Erleichterung der Arbeit.


... ok, zumindest weiß ich jetzt, dass ich keine Begeisterung ausgelöst habe. :stupid:


@Bernd2015
Also es ging schon um Sprachkonstrukte in der Programmierung.
ALLE DENKBAREN Wünsche können in dem Thread hier nicht erfüllt werden. ;-)

[Hansa]

Warum soll das Begeisterung auslösen ? Wenn man jetzt hingeht und zählt ab 1 statt 0 (ich stimme Stahli da zu, dass das logischer wäre !), aber mathematisch korrekter wäre es wohl nicht. Der Hauptpunkt ist aber : never change a running system. Würde man das ändern, au Mann, das gäbe Riesen-Durcheinander, Kompatibilitätsprobleme usw. bis in die letzte Programmeckee.

[Stevie]

Es heulen doch jetzt schon alle über ZBS - obwohl das wohl endlich konsistent ist!

Von allen Dingen, die ich mir wünschen würde kämen die Sachen wohl nicht in meiner Liste vor - wenn jemand nicht zwischen Wert und Referenztypen unterscheiden kann, dann soll er wieder mit Playmobil spielen gehen :twisted:

Und nein, ich werd meine Wunschliste hier nicht mit euch diskutieren, weil es nichts bringt und ich da keinen Nerv drauf habe - die, die davon etwas umsetzen könnten, wissen davon und das ist entscheidend.

[stahli]

Zitat:

Zitat von stahli (Beitrag 1316125)

Ich will hier keine Pascal-Änderungen anregen, sondern einfach mal ein paar grundsätzliche (quasi philosophische) Überlegungen anstellen und diskutieren - wem das gelingt auch gern unter Berücksichtigung der Sicht eines Programmieranfängers.

Mich hatte interessiert, ob ganz grundsätzlich die Pro´s oder Contra´s 1 überwiegen - unabhängig von existierenden Sprachen und gängigen Standards.

[Stevie]

Beide Alternativen sind gleich blöd. Aber vielleicht ist zero based auch besser? :stupid:

[SMO]

Zitat:

Zitat von stahli (Beitrag 1316282)

Mich hatte interessiert, ob ganz grundsätzlich die Pro´s oder Contra´s 1 überwiegen - unabhängig von existierenden Sprachen und gängigen Standards.

Wenn wir hier schon dabei sind, seltsam anmutende Kleinigkeiten zu diskutieren (bitte nicht persönlich nehmen, stahli):

Ich würde mir wünschen, dass Leute nicht den Akut (´) als Apostroph (') missbrauchen und von der Unsitte abkommen, Pluralformen mit Apostroph-S zu bilden. Das ist sowohl in der englischen als auch der deutschen Sprache falsch, aber man sieht es in beiden immer wieder, besonders bei Abkürzungen. Es heißt "eine CPU, zwei CPUs" und nicht etwa "zwei CPU's" oder schlimmer noch "zwei CPU´s". :warn:

Wieso sich die Arbeit machen und ein oder zwei Tasten mehr als nötig drücken, um ein Zeichen zu produzieren, das da gar nicht hingehört? Ein Wort wird nicht entstellt wenn ein kleines S direkt angehängt wird. Wie implementation schön in Beitrag #10 gezeigt hat, gibt es Sprachen, die ihre Wörter viel drastischer beugen! So wird z.B. im Kroatischen je nach Deklination aus einer Irena eine Irene und aus einem Branko ein Branka. Also, nur keine Berührungsängste und weg mit den sinnlosen Apostrophen!

Zitat:

Zitat von bernd2015 (Beitrag 1316246)

Fände es SEHR wünschenswert, wenn man sich an Beiträge angehängte Screenshots ohne Anmeldung/Registrierung ansehen könnte!

Das nervt mich bei einigen Foren auch. Soll das Bandbreite sparen, oder Leute zum Registrieren animieren? Vielleicht kann ja der Forenbetreiber etwas dazu sagen.

Zum Thema 0-basiert vs. 1-basiert: ich bevorzuge ersteres. Ist logischer und auch weiter verbreitet.

[Luckie]

Die null basierenden Listen sind wohl der Hardware geschuldet bzw. historisch bedingt. Ein Byte Array im Speicher fängt eben bei 0 an. Dann kann man schön in einer Schleife durch iterieren. Siehe dazu auch die Char-Arrays von C. Ein ShortString fängt ja auch bei 0 an. Das ein String bei 1 anfängt ist so auch nicht richtig. Zu einem String gehört die Größenangabe und die liegt im 0ten Byte. Also alles gut und konsistent.

Es ist eben so, dass manche Dinge historisch gewachsen sind. Siehe auch als Schleifenzähler das i. Selten sieht man da einen Schleifenzähler, der was mit der Schleife zu tun hat. Historisch eben. Man muss eben so was manchmal im Hinterkopf haben. Aber das ist auch Reallife so. Siege Tastaturen von Taschenrechnern und Telefonen. Da hatte wohl noch niemand die Idee, dies zu vereinheitlichen. Oder die Uhrzeit. Die Uhrzeit basiert auf den 60'er System. Die Franzosen haben es nach der Revolution mal mit dem Dezimalsystem probiert. Das Ergebnis dürfte klar sein. ;) Obwohl das Dezimalsystem bei Berechnungen mit der Uhrzeit vorteilhaft wäre. Genauso die Gradeinteilung des Kreises.

[Dejan Vu]

In der Mathematik ist in einer Iteration I_0 der Initialwert. 'Eigentlich' immer (was heißt bei einem Entwickler schon 'eigentlich')...

Ich habe in den 79er Jahren mit einem HP9845 erste Gehversuche gemacht. Dort gab es -wow- Arrays. Die konnte man damals schon 1-basiert oder 0-basiert definieren.

Code:

10 OPTION BASE 1
20 DIM A[10]
30 REM A[1] ist das erste, A[10] das letzte Element

Code:

10 OPTION BASE 0
20 DIM A[10]
30 REM A[0] ist das erste, A[9] das letzte Element

Man wusste damals schon, das es zwei Lager gibt :stupid:

[Luckie]

Geht in Delphi doch auch. Oder irre ich mich da?

[Dejan Vu]

Aber nicht 1976.

[Stevie]

Zitat:

Zitat von Luckie (Beitrag 1316304)

Geht in Delphi doch auch. Oder irre ich mich da?

Nur bei statischen Arrays. Dynamische fangen immer bei 0 an.

[Pfaffe]

Wenn ein Kind seinen ersten (1) Geburtstag feiert, dann ist ein Jahr rum, das Leben fängt also bei 0 an.

[jobo]

Zitat:

Zitat von Pfaffe (Beitrag 1316309)

Wenn ein Kind seinen ersten (1) Geburtstag feiert, dann ist ein Jahr rum, das Leben fängt also bei 0 an.

Eine Sichtweise, die ich nie verstanden habe und auch nie verstehen werde.
Mein erster Geburtstag ist für mich der Tag meiner Geburt, aber damit gehöre ich vermutlich zu einer sehr kleinen Minderheit weltweit!

[Sir Rufo]

Zitat:

Zitat von jobo (Beitrag 1316314)

Zitat:

Zitat von Pfaffe (Beitrag 1316309)

Wenn ein Kind seinen ersten (1) Geburtstag feiert, dann ist ein Jahr rum, das Leben fängt also bei 0 an.

Eine Sichtweise, die ich nie verstanden habe und auch nie verstehen werde.
Mein erster Geburtstag ist für mich der Tag meiner Geburt, aber damit gehöre ich vermutlich zu einer sehr kleinen Minderheit weltweit!

Die Feier eines Gedenktages erfordert einen Tag, dem man gedenken kann und das geht eben nur für Tage, die in der Vergangenheit liegen. Somit haben wir den konkreten Geburtstag (der Tag an dem es geschehen ist) und die Tage an denen wir uns dieses Ereignisses gedenken.

Wir feiern den Geburtstag am gleichen Jahrestag im Gedenken an den konkreten Geburtstag, der aber in der Vergangenheit liegt.

Von der Geburt an befinden wir uns im 1. Lebensjahr, sind aber noch kein Jahr alt. Ab dem ersten Geburtstag befinden wir uns im 2. Lebensjahr sind aber trotzdem erst 1 Jahr alt.

Das Lebensjahr beschreibt einen zeitlichen Abschnitt von einem Jahr.
Das Alter beschreibt die vergangenen Abschnitte.

Die Altersangabe verändert sich auch im Laufe eines Lebens. Fängt an in Tagen über Wochen, Monate bis wir dann endgültig bei den Jahren angekommen sind. Erwachsen wird man, wenn man sein Alter nicht mehr als Dezimalzahl verkündet.

Zitat:

Ich bin schon 14 einhalb

Alt fühlt man sich, wenn man der (Jahres)-Altersangabe ein + anhängt (man hat das Gefühl, man muss hier etwas kaschieren) :mrgreen:

[Bernhard Geyer]

Zitat:

Zitat von Pfaffe (Beitrag 1316309)

Wenn ein Kind seinen ersten (1) Geburtstag feiert, dann ist ein Jahr rum, das Leben fängt also bei 0 an.

Und wenn ich jetzt mir eine Auswahl zwischen zwei Äpfel gibt sag ich dann auch ich will den 0ten Apfel :roll:

[Hansa]

Da hat Bernhard auch Recht. Aber : es gibt ein Binärsystem. Um 256 Zahlen darzustellen komme ich mit einem Byte aus, aber nur, sofern ich die 0 mitnehme.