Kleines selbstgeschriebenes Programm - Pascal

[mattberg]

Du könntest es theroetisch auch mit einer For-Schleife machen mithilfe von delims und usebackq. Aber das wird ziemlich kompliziert.
Mit Suchen und Ersetzen fährst du besser, je nachdem für wieviele Dateien du es brauchst.

Ja, ich wollte sowas in Pascal schreiben, aber es gibt ja noch die Suchen&Ersetzenfunktion, die das ganze stark vereinfacht hat .

[ayin]

Naja, du könntest das ganze schon in Pascal realisieren, aber dann müsstest du dich gut auskennen, Daten innerhalb einer Datei richtig zu interpretieren und auszuwerten. Das kann schon mal sehr knifflig sein, vor allem, wenn sich die einzelnen Zeilen stark unterscheiden.
Wäre aber eine Herausforderung mit den alten Mitteln.

[mattberg]

Ich habe noch eine Frage, in einem Programm habe ich statt der Case-of-Anweisung mal Labels und Goto benutzt, aber der Lehrer meinte, die sind verpönt. Warum eigentlich?

[Azau]

Die Gotos usw stammen noch aus der Zeit, als die Zeilen im Programmcode generell durchnummeriert werden mussten, lange bevor die prozedurale Programmierung mit den Schleifen aufkam. Und Schleifen udn dergleichen sidn wesentlich einfacher zu lesen. Wer in einem hundertseitigen Quellcode mal versucht hat, die ein oder andere Sprungmarke zu finden weiß, wie viel besser man jetzt dran ist.

Und damit man sich gar nicht erst was Falsches einprägt mit den Sprüngen sind die dementsprechend ungern gesehen.

[mattberg]

Die Gotos usw stammen noch aus der Zeit, als die Zeilen im Programmcode generell durchnummeriert werden mussten, lange bevor die prozedurale Programmierung mit den Schleifen aufkam. Und Schleifen udn dergleichen sidn wesentlich einfacher zu lesen. Wer in einem hundertseitigen Quellcode mal versucht hat, die ein oder andere Sprungmarke zu finden weiß, wie viel besser man jetzt dran ist.

Und damit man sich gar nicht erst was Falsches einprägt mit den Sprüngen sind die dementsprechend ungern gesehen.

Ah, ok, danke für die Erklärung.
Wenn man einen ganzen Haufen Prozeduren hat, blickt man da auch nicht einfach durch .
Naja, ich hab auch die Angewohnheit, dass ich die Variablen durchbuchstabiere, also a,b,c,d:integer;. Ich persönlich finde das einfacher handzuhaben als z.B. summe, quadrat:integer;. Das ist aber auch ungerngesehen, oder?

[helo]

Wenn man einen ganzen Haufen Prozeduren hat, blickt man da auch nicht einfach durch .

Auch die prozedurale Programmierung ist nicht der Weisheit letzter Schluss. Danach steigert man sich dann eben zur objektorientierten Programmierung...

Naja, ich hab auch die Angewohnheit, dass ich die Variablen durchbuchstabiere, also a,b,c,d:integer;. Ich persönlich finde das einfacher handzuhaben als z.B. summe, quadrat:integer;. Das ist aber auch ungerngesehen, oder?

So lange Programme klein und übersichtlich sind ist das alles kein Problem. Für ein Hello-World braucht auch keiner Objektorientierung.

So bald die Programme aber größer werden macht es die Arbeit um einiges leichter, wenn man sich ein paar tausend Zeilen tief in den Sourcecode nicht fragen muss, ob 'a' nun für eine Integer-Variable steht, die eine Summe repräsentiert oder nicht doch vielleicht ein String war, der mal für einen Dateinamen gedacht war.

Letztlich gehts darum, dass man sich am Anfang bei kleinen Programmen nicht aus Bequemlichkeit Unarten angewöhnt, die einem später das Leben unnötig schwer machen.

[ayin]

Auch die prozedurale Programmierung ist nicht der Weisheit letzter Schluss. Danach steigert man sich dann eben zur objektorientierten Programmierung...

Das kann man so nicht stehen lassen. Prozedural hat für gewisse Anwendungen durchaus Vorteile, OO hat woanders Vorteile. Es ist eben zweckdienlich entweder das eine oder das andere für sein Projekt umzusetzen.

So lange Programme klein und übersichtlich sind ist das alles kein Problem. Für ein Hello-World braucht auch keiner Objektorientierung.

Es gibt auch grosse Projekte die nicht OO sein müssen oder damit wesentlich unhandlicher sind oder zum Teil sogar unmöglich.

Letztlich gehts darum, dass man sich am Anfang bei kleinen Programmen nicht aus Bequemlichkeit Unarten angewöhnt, die einem später das Leben unnötig schwer machen.

Das kann ich so unterschreiben.

[helo]

Das kann man so nicht stehen lassen. Prozedural hat für gewisse Anwendungen durchaus Vorteile, OO hat woanders Vorteile. Es ist eben zweckdienlich entweder das eine oder das andere für sein Projekt umzusetzen.

Natürlich ist das so.

Ich bezog mich auf die Aussage das viele Prozeduren irgendwann unübersichtlich werden können. Wenn man den Punkt erreicht hat, dann kann das Organisieren in Objekte mit zugehörigen Member-Variablen und -Methoden Abhilfe schaffen.

Letztlich führt kein Weg darum für jedes Projekt separat zu entscheiden welchen Weg derjenige ist der zum Ziel führt.

Es gibt auch grosse Projekte die nicht OO sein müssen oder damit wesentlich unhandlicher sind oder zum Teil sogar unmöglich.

Kein Widerspruch von mir dazu (und auch keiner zu dem was ich vorher schrieb ).

Um meine Aussagen aus dem letzten Beitrag etwas zu präzisieren:
Für die meisten Sachen die man in Schule oder Studium programmiert bräuchte man nicht wirklich höhere Programmierkonstrukte. Sei es prozedural oder objektorientiert. Da käme man auch mit Gotos und ohne Namenskonventionen für Variablen und Methoden hin. Es geht da eben in erster Linie darum diese Techniken (richtig) zu lernen um sie dann später (im Beruf) parat zu haben, wenn es darum geht die passendste Vorgehensweise für ein konkretes Projekt auszuwählen (mit dem man ja letztlich sein Geld verdient).