A. K. schrieb:> Damals muss das FORTRAN gewesen sein.
Klar, mehr konnte der (schweinisch laute) Paralleldrucker ja nicht
darstellen. ;-)
Aber bazzzel, pass auf, gleich wird ein FORTRAN-Jünger um die Ecke
kommen und dir erklären, dass FORTRAN keine „antike“
Programmiersprache ist. :-)
Jörg Wunsch schrieb:> ....gleich wird ein FORTRAN-Jünger um die Ecke> kommen und dir erklären, dass FORTRAN keine „antike“> Programmiersprache ist. :-)
Jünger? Das kann nur ein Fortran-ÄLTER sein.
MfG Paul
Jörg Wunsch schrieb:> Aber bazzzel, pass auf, gleich wird ein FORTRAN-Jünger um die Ecke> kommen und dir erklären, dass FORTRAN keine „antike“> Programmiersprache ist. :-)
Ist es ja auch überhaupt nicht, der aktuelle Standard ist Fortran 2008
(von 2010) und der nächste (Fortran 2015) ist schon unterwegs. Ein
Fortran-Jünger bin ich aber trotzdem nicht ;-)
Fortran ist einfach nicht tot zu kriegen, und es würde mich nicht allzu
sehr wundern, wenn es 100 Jahre alt würde (2057 treffen wir uns dann auf
der Geburtstagsparty :)).
Der gepostete Code ist übrigens konform zu FORTRAN IV (1962) bis Fortran
2015. Die Versionen vor IV kannten noch keine booleschen Ausdrücke.
Yalu X. schrieb:> Fortran ist einfach nicht tot zu kriegen
Das erinnert mich irgendwie an den Witz mit dem Programmierer, den
sie im Jahr 2999 auftauen, weil aus seinen Unterlagen hervorgeht,
dass er COBOL beherrscht. :-)
Paul Baumann schrieb:
> Jünger? Das kann nur ein Fortran-ÄLTER sein.
Fortran-Jünger können auch älter als Fortran sein und das waren sie dann
auch, als sie noch jünger und auch Fortran selbst noch jung waren.
spiritus lector schrieb im Beitrag #3974486:
> Vor ein paar jahren erzählte mir ein Physiker
Ja, die Physiker. Das sind vermutlich die letzten „Kunden“ dieser
Sprache.
Meine Vermutung war jedoch schon vor 30 Jahren, dass die Ursache dafür
nicht die überragende Qualität dieser Programmiersprache ist, sondern
vielmehr die Tatsache, dass all die alten, in FORTRAN geschriebenen
Algorithmen sowieso kein Mensch nachvollziehen kann – selbst der
ursprüngliche Autor nicht, und der ist mittlerweile sowieso gestorben.
Also muss man stattdessen die Sprache immer weiter nutzen … ;-)
Im Ernst: wenn ich mir aktuelle C++-Entwicklungen ansehe, dann scheint
man sich dort ernsthaft Mühe zu geben, bislang immer noch fest in
FORTRAN-Hand befindliche Domänen zu erstürmen. Allerdings hat das den
Nachteil, dass den entsprechenden C++-Code dann auch ein gestandener
C-Programmierer nicht mehr versteht:
A. K. schrieb:> Aber dafür ist das ein Sprache, in denen Leerzeichen vogelwild verteilt> werden dürfen, weshalb es egal ist, ob da GOTO oder GO TO steht.
Völlig wild, also auch "G O T O" oder "G O T O"? Oder waren da
schon bestimmte Regeln, so daß eben nur GOTO und GO TO erlaubt waren?
Sorry, die Sprache kenn ich nur dem Namen nach. Ich hab mich nie mit
Fortran beschäftigt.
Jörg Wunsch schrieb:> Ja, die Physiker. Das sind vermutlich die letzten „Kunden“ dieser> Sprache.
Nachdem die große Forth-Revolution ausgeblieben war, halten sie sich
eben an Bewährtes...
A. K. schrieb:> npn schrieb:>> Völlig wild, also auch "G O T O" oder "G O T O"?>> Ja. Auch das geht: DONAUESCHINGEN=1,10, denn wer hier völlig konfus wird> und als Ausweg nur eine Zuweisung von 1,10 an DONAUESCHINGEN sieht, der> ist schief gewickelt. Das ist der Anfang einer Schleife.
Das Beispiel das du vorher hattest, war besser.
Denn der einzige Unterschied zwischen
1
DO10I=1,10
2
...
3
10CONTINUE
und
1
DO10I=1.10
2
...
3
10CONTINUE
ist nun mal der . Und der macht aus der eigentlich beabsichtigen
DO-Anweisung eine Zuweisung an eine Variable.
Ist ein berühmter Fehler, der angeblich zum Verlust einer Nasa Sonde
geführt haben soll (irgend eine Merkur-Sonde)
Daher ist in FORTRAN auch ein
npn schrieb:> A. K. schrieb:>> Aber dafür ist das ein Sprache, in denen Leerzeichen vogelwild verteilt>> werden dürfen, weshalb es egal ist, ob da GOTO oder GO TO steht.>> Völlig wild, also auch "G O T O" oder "G O T O"? Oder waren da> schon bestimmte Regeln, so daß eben nur GOTO und GO TO erlaubt waren?
Das erste was ein Fortran Compiler macht, wenn er sich eine Zeile
vornimmt, das ist dass er ALLE Leerzeichen (mit Ausnahme der in Strings)
aus der Zeile rauswirft.
FORTRAN ist(war) so gebaut, dass man es mit simplen Pattern Matching
parsen konnte.
((war) deshalb, weil ich bei FORTRAN 77 ausgestiegen bin. Und selbst da
hab ich nicht mehr alles mitgemacht)
A. K. schrieb:> Karl Heinz schrieb:>> Das Beispiel das du vorher hattest, war besser.>> Ok, also der Unterschied zwischen:> DORTMUND=1.10
korrekt
> DORTMUND=1,10
Syntax Error (Ein DO verlangt ein Label, in dem der CONTINUE zu finden
ist)
> DORTMUND=1:10
auch ein Syntax Error.
Aber wie gesagt: meine Kentnisse enden bei FOTRAN 77. Kann sein, dass
spätere Entwicklungen da was geändert haben.
Karl Heinz schrieb:> Das erste was ein Fortran Compiler macht, wenn er sich eine Zeile> vornimmt, das ist dass er ALLE Leerzeichen (mit Ausnahme der in Strings)> aus der Zeile rauswirft.
Wobei es anfangs offiziell auch keine klassischen Strings gab, also wie
sie heute üblich sind, sondern sowas wie 10HKARL HEINZ nötig wurde.
Karl Heinz schrieb:> Syntax Error (Ein DO verlangt ein Label, in dem der CONTINUE zu finden> ist)
Sowas ist dann aber ziemlich sicher kein Syntax Error, sondern eine
andere Art Fehler.
>> DORTMUND=1:10> auch ein Syntax Error.
In Köln wär ich da nicht so sicher? ;-)
A. K. schrieb:> Karl Heinz schrieb:>> Syntax Error (Ein DO verlangt ein Label, in dem der CONTINUE zu finden>> ist)>> Sowas ist dann aber ziemlich sicher kein Syntax Error, sondern eine> andere Art Fehler.
ACK. Da will ich mich nicht zu weit aus dem Fenster lehnen um welchen
Fehler es sich dann konkret handeln wird. Aber irgendeiner ist es
sicher. Denn das Muster
1
DORTMUND=1,10
passt weder auf die Maske
1
DO<Zahl>Name=Ausdruck<Komma>Ausdruck
(für <Zahl> findet sich nichts)
noch passt es auf das Schema
Karl Heinz schrieb:> ACK.
Nope, stimmt, das Label war ja dahinter. Mea culpa. So kriegt man nix
hübsches raus, nur Unsinn. Aber der Unterschied zwischen
DOIII=1.11
und
DO11I=1,I1
ist auch nicht in jedem Font sofort ersichtlich.
Dafür müsste beispielsweise in PL/I sowas möglich sein:
IF IF = THEN THEN THEN = ENDIF; ENDIF;
Durfte eine Zeile länger als 80 Zeichen sein? Dann passte die nicht mehr
auf eine Lochkarte.
Bei meinem Fortran-Kurs 1977 mussten wir noch Baudot-codierte
Lochstreifen aus dem LO-15 Fernschreiber im Rechenzentrum abgeben.
Stunden später lag der Ergebnisausdruck im Ausgabefach. Lochkarten waren
zu teuer für einfache Studenten.
Der Computer war eine Univac 1108
Christoph Kessler (db1uq) schrieb:> Durfte eine Zeile länger als 80 Zeichen sein?
Beim Original-FORTRAN wurde alles ab Spalte 72 implizit als Kommentar
bewertet, damit man dort die Kartennummer ablochen kann.
Keine Ahnung, ob das bei aktuellen FORTRAN-Varianten immer noch der
Fall ist.
spiritus lector schrieb im Beitrag #3974486:
> Vor ein paar jahren erzählte mir ein Physiker das workstationhersteller> mehr auffwand in die Optimierung des Fortan Compilers stecken als in die> Entwicklung des C-Compilers, da der Großteil der "Physiker-Programme" in> FORTRAN erstellt wurde und "richtuig viel" rechenzeit benötigen.
Ja, leider stimmt das. Als ich Ende der 80er einen C-Programmierkurs in
einem physikalischen Institut einer großen Uni in Deutschland für die
dortigen Mitarbeiter (zu denen ich auch gehörte) gab und diesen mit
"C wird FORTRAN eines Tages auch in der Naturwissenschaft ablösen."
einleitete, wurde ich vom Publikum ziemlich ausgelacht und keiner wollte
mir glauben.
(Naja, der Kurs wurde dann doch noch zu einem Erfolg und ich konnte
tatsächlich einige der eingefleischten Fortran-Programmierer überzeugen,
ihre Programme nach C zu portieren und weiterhin auch mit C zu arbeiten.
;-) )
Jörg Wunsch schrieb:> Christoph Kessler (db1uq) schrieb:>> Durfte eine Zeile länger als 80 Zeichen sein?>> Beim Original-FORTRAN wurde alles ab Spalte 72 implizit als Kommentar> bewertet, damit man dort die Kartennummer ablochen kann.
Die wiederrum war deswegen wichtig, weil einem so ein Kartenstapel schon
mal runtergefallen ist.
Glücklich preisen konnte sich dann derjenige, der seine Karten
durchnummeriert hatte. Da gab es eigene Programme, die die Karten dann
in beliebiger Reihenfolge eingelesen und einen neuen, anhand dieser
Nummerierung sortierten, Kartenstapel ausgestanzt haben.
> Durfte eine Zeile länger als 80 Zeichen sein?
Klar. Dann stand in der Spalte 1 wenn ich mich recht entsinne ein:
C
fuer Continuation aka Fortsetzung...
A. K. schrieb:> Fortran lässt sich vom Compiler besser optimieren als C.
Das liegt doch wohl eher an der Simplizität von Fortran?
Ich kann mir jedenfalls beim besten Willen nicht vorstellen, dass im
Endergebnis Fortran-Programme effektiver als C-Programme sind...
./. schrieb:>> Durfte eine Zeile länger als 80 Zeichen sein?>> Klar. Dann stand in der Spalte 1 wenn ich mich recht entsinne ein:> C> fuer Continuation aka Fortsetzung...
Die Spalte 1 war, meiner Erinnerung nach für die Kommentarmarkierung.
Das 'C' war in Spalte 6.
Aber ist schon lange her.
Frank M. schrieb:> A. K. schrieb:>> Fortran lässt sich vom Compiler besser optimieren als C.>> Das liegt doch wohl eher an der Simplizität von Fortran?
In FORTRAN gabs keine Pointer. Womit das ganze Thema Aliasing wegfällt.
Die Compiler konnten als nach Herzenslust alles an Common Subexpression
Elimination rausholen was sie wollten.
Die ersten wesentlichen 'Optimierungen' bestanden in der Erkennung von
Schleifen die auf skalaren Maschinen (wie die berühmte Cray) parallel
ausgeführt werden konnten.
Karl Heinz schrieb:> Das 'C' war in Spalte 6.
Und es durfte ein beliebiges Zeichen sein. Ein ‚C‘ (oder ‚D‘) hat
man eher nicht verwendet, damit man es nicht mit einem Kommentar
verwechselt. Üblich war es eigentlich, die Fortsetzungszeilen mit
‚1‘, ‚2‘, ‚3‘, … durchzunummerieren.
Ab Spalte 1 stand natürlich außer dem C oder D für Kommentare ansonsten
ein numerischer Label.
spiritus lector schrieb im Beitrag #3974486:
> Klar Naturwissenschaftler haben mehr bedarf an "Formelübersetzer"> (FORmular TRANslator) als an verwässerten Assembler wie C.
Wobei das Original-FORTRAN mit seinen Label-Nummerierungen und GOTOs
ja deutlich mehr Ähnlichkeit zu Assembler hatte denn C. Mein Favorit:
das „arithmetische IF“:
Karl Heinz schrieb:> Das 'C' war in Spalte 6.
In Spalte 6 führte alles (außer Leerzeichen und 0) dazu, daß diese Zeile
eine Fortsetzungszeile der vorherigen war. Egal, ob C oder sonstwas.
Allerdings war das auch wieder limitiert, ich glaube auf 19
Fortsetzungszeielen - müsste ich aber nachschauen.
A. K. schrieb:> Wobei es anfangs offiziell auch keine klassischen Strings gab, also wie> sie heute üblich sind, sondern sowas wie 10HKARL HEINZ nötig wurde.
Das H (vom 10H..., nicht vom Heinz) kam von "Hollerith-Konstante".
Hollerith war der Typ, der 1890 mit Lochkarten eine Volkszählung
organisierte - das Format der Lochkarten zog sich dann bis zu FORTRAN
und aus seiner Firma wurde über Umwege IBM.
Frank M. schrieb:>> Fortran lässt sich vom Compiler besser optimieren als C.>> Das liegt doch wohl eher an der Simplizität von Fortran?
Es gibt einige Spracheigenschaften, in denen die Freiheit von C einer
effektiven Optimierung etwas im Weg steht. Die bekannteste und wohl auch
wichtigste ist das Potential von Aliasing.
Man hat sich in C diesem Thema im Laufe der Zeit verstärkt gewidmet,
wodurch man mit entsprechender Nachhilfe seitens des Programmierers dem
Compiler helfen kann, aber das erinnert dann an Fleissarbeit des
Programmierers, um dem Compiler in C explizit das zu sagen, was er in
Fortran auch selber schon rausfinden kann.
Siehe https://en.wikipedia.org/wiki/Pointer_aliasing> Ich kann mir jedenfalls beim besten Willen nicht vorstellen, dass im> Endergebnis Fortran-Programme effektiver als C-Programme sind...
Ich schon. In jenem Einsatzbereich, für den Fortran typisch ist.
./. schrieb:> Klar. Dann stand in der Spalte 1 wenn ich mich recht entsinne ein:> C> fuer Continuation aka Fortsetzung...
Nein, das C musste in Spalte 6 stehen.
Die Spalte 1 blieb stets frei. Wenn dort ein Zeichen war, dann wurde
dieses und der ganze Rest der Zeile als Kommentar behandelt.
http://www.fh-jena.de/~kleine/history/languages/GC28-6515-10-FORTRAN-IV-Language.pdf
Seite 14
Karl Heinz schrieb:> Die Compiler konnten als nach Herzenslust alles an Common Subexpression> Elimination rausholen was sie wollten.
Nicht nur dies. Wenn man weiss, dass keine Überlappungen zwischen formal
verschiedenen Arrays vorkommen können, dann ist man auch bei Unrolling
wesentlich freier.
foo schrieb:> Wenn dort ein Zeichen war, dann wurde dieses und der ganze Rest der> Zeile als Kommentar behandelt.
Oder als Label, wenn es mit einer Ziffer anfängt.
P.S.:
Was ich oben schrieb ist auch nicht ganz richtig.
Ein C für "Comment" in Spalte 1 leitete eine Kommentarzeile ein.
Sonst standen da allenfalls Statement Nummern.
Irgendein Zeichen in Spalte 6 diente zur Kennzeichnung von Folgekarten,
wenn der Platz in einer Zeile nicht für das Statement ausreichte.
Praktischer Weise verwendete man da Folgen wie 1,2,3 oder A,B,C damit
man die Folgekarten möglichst nicht durcheinanderwarf.
Genau sowie weitere Einschränkungen steht das im oben verlinkten
Dokument.
foo schrieb:> Was ich oben schrieb ist auch nicht ganz richtig.> Ein C für "Comment" in Spalte 1 leitete eine Kommentarzeile ein.> Sonst standen da allenfalls Statement Nummern.
C oder * leiten einen Kommentar ein.
>> Irgendein Zeichen in Spalte 6 diente zur Kennzeichnung von Folgekarten,> wenn der Platz in einer Zeile nicht für das Statement ausreichte.> Praktischer Weise verwendete man da Folgen wie 1,2,3 oder A,B,C damit> man die Folgekarten möglichst nicht durcheinanderwarf.
Aber nicht 0 - das wurde ebenso ignoriert wie ein Leerzeichen in dieser
Spalte.
Klaus Wachtler schrieb:> C oder * leiten einen Kommentar ein.
Den * kannte ich nicht. Dafür aber noch D als „Debug-Kommentar“:
konnte per Übersetzungsoption entweder als normales Statement oder
als Kommentar bewertet werden. Gewissermaßen einen primitive Form
von ifdef.
Jörg Wunsch schrieb:> Den * kannte ich nicht. Dafür aber noch D als „Debug-Kommentar“:> konnte per Übersetzungsoption entweder als normales Statement oder> als Kommentar bewertet werden. Gewissermaßen einen primitive Form> von ifdef.
War aber kein Standard.
Karl Heinz schrieb:> In FORTRAN gabs keine Pointer. Womit das ganze Thema Aliasing wegfällt.A. K. schrieb:> Es gibt einige Spracheigenschaften, in denen die Freiheit von C einer> effektiven Optimierung etwas im Weg steht. Die bekannteste und wohl auch> wichtigste ist das Potential von Aliasing.
Echte Pointer gibt es erst in den neueren Fortrans (ab Fortran 90).
Allerdings gibt es dort keine Pointer-Arithmetik wie in C, und Pointer
können nur auf solche Variablen zeigen, die als TARGET deklariert sind.
Diese Restriktionen wirken ein wenig dem Pointer-Wildwuchs, wie er in C
prinzipiell möglich ist, entgegen
Aber auch in den älteren Fortrans (seit FORTRAN II) gab es schon
Referenzen (nämlich für die Argumentübergabe an Unterprogramme), und
damit auch Aliasing. Beispiel:
1
PROGRAM PCTEST
2
I = 3
3
CALL SUB(I, I)
4
END
5
6
SUBROUTINE SUB(J, K)
7
print *, 'J = ', J
8
K = 4
9
print *, 'J = ', J
10
END
Nach der Zuweisung K = 4 in SUB hat auch J den Wert 4, da wegen des
Aufrufs von SUB mit zweimal demselben Argument J und K Referenzen auf
dieselbe Variable I sind.
Seit FORTRAN 66 gibt es auch explizites Aliasing mit EQUIVALENCE, mit
dem man mehrere Variablen (auch unterschiedlichen Typs) übereinander
legen kann.
Karl Heinz schrieb:> Glücklich preisen konnte sich dann derjenige, der seine Karten> durchnummeriert hatte. Da gab es eigene Programme, die die Karten dann> in beliebiger Reihenfolge eingelesen und einen neuen, anhand dieser> Nummerierung sortierten, Kartenstapel ausgestanzt haben.
Ich durfte mein Programmierpraktikum noch auf Lochkarten machen,
allerdings nicht in Fortran, sondern in Simula-67.
Im Rechenzentrum stand noch ein mechanischer Lochkartensortierer - damit
konnte man runtergeschmissene Lochkartenstapel sortieren, so man denn
Sequenznummern in den Spalten 72-80 hatte - ich habs mal spaßeshalber
ausprobiert.
Die Sequenznummern musste man allerdings erst mal dort hin bekommen -
der einfachste Weg war, sich den ganzen Kartenstapel vom Rechner mit
Sequenznummern kopieren zu lassen.
Wenn ich mich recht erinnere, gab es von IMB Kartenstanzer mit einem
Zusatz, der automatisch Seriennummern dazugestanzt hat - gesehen habe
ich das aber nicht.
Dies Lochkartenstanzer hatten die besten Tastaturen, die je erlebt habe:
Sehr leichtgängig, aber mit deutlichem Druckpunkt; das krachen des
Stanzwerkes verstärkte diesen Eindruck natürlich noch.
Uhu Uhuhu schrieb:> Wenn ich mich recht erinnere, gab es von IMB Kartenstanzer mit einem> Zusatz, der automatisch Seriennummern dazugestanzt hat - gesehen habe> ich das aber nicht.
doch, die gab es.
Kartenstapel ohne Nummern rein, Kartenstapel mit Nummern raus.
Rein mechanisch :-)
Yalu X. schrieb:> Allerdings gibt es dort keine Pointer-Arithmetik wie in C, und Pointer> können nur auf solche Variablen zeigen, die als TARGET deklariert sind.> Seit FORTRAN 66 gibt es auch explizites Aliasing mit EQUIVALENCE, mit> dem man mehrere Variablen (auch unterschiedlichen Typs) übereinander> legen kann.
Das genau ist der Unterschied.
Fortran ist von Haus aus restriktiv. Wer grössere Freiheiten benötigt,
der muss sich explizit mit TARGET, EQUIVALENCE etc drum bemühen.
C ist von Haus aus permissiv und wer mehr Optimierung will als das
hergibt, der muss in seinem Programm allerlei Kram reinschreiben, wie
etwa "restrict" bei Pointern.
Uhu Uhuhu schrieb:> Dies Lochkartenstanzer hatten die besten Tastaturen, die je erlebt habe:> Sehr leichtgängig, aber mit deutlichem Druckpunkt; das krachen des> Stanzwerkes verstärkte diesen Eindruck natürlich noch.
Die Klassiker von IBMs Tastaturen imitieren deshalb auch ein wenig den
Krach vom Stanzwerk, damit der Eindruck nicht verloren geht. ;-)
A. K. schrieb:> Die bekannteste und wohl auch wichtigste ist das Potential von Aliasing.
Na ja, in einer Sprache ohne Pointer kann man das schlecht hinbekommen.
Dafür gibts in Fortan "richtige" Common-Blocks. Damit kann man durchaus
sowas wie Aliasing hinbekommen, nur dass der Compiler davon schlicht
nichts mitbekommt.
Uhu Uhuhu schrieb:> Dafür gibts in Fortan "richtige" Common-Blocks. Damit kann man durchaus> sowas wie Aliasing hinbekommen, nur dass der Compiler davon schlicht> nichts mitbekommt.
Du kannst in jeder Sprache ein Grab schaufeln und dich hineinlegen.
Das mit der besseren Optimierbarkeit von Fortran ist etwas
wirklichkeitsfremd.
Wenn man C in dem Sprachumfang nutzt, den Fortran bietet, ist es nicht
schlechter optimierbar, als Fortran.
Pointer ohne irgendwelche bekannten Randbedinungen sind nicht nur für
Compiler ziemlich unberechenbar und werden in vielen Programmiersprachen
deshalb gar nicht angeboten.
Uhu Uhuhu schrieb:> Wenn man C in dem Sprachumfang nutzt, den Fortran bietet, ist es nicht> schlechter optimierbar, als Fortran.
Es geht weniger um den Umfang, den man nutzt, als um das Risiko, das der
Compiler mit einrechnen muss. Auch wenn man die Schweinereien, gegen die
er sich wappnen muss, überhaupt nicht verwendet.
Aliasing hast du in C schnell als Risiko an der Backe, weil es keine
Array-Parameter gibt, sondern nur Pointer auf Array-Inhalte. In
korrektem Fortran wird es nicht vorkommen, dass zwei Parameter mit
verschiedener Adresse ins gleiche Objekt zeigen. Also Überlappung
auftreten kann. In C schon, und der Compiler kann es mangels Kenntnis
der betreffenden Objekte auch nicht herausfinden, es sei denn er
optimiert Aufruf und Funktion in einem Aufwasch.
Die Folge ist, dass ein Compiler auch dann mit Aliasing rechnen muss,
wenn weit und breit keines existiert. Weil das Risiko immer mitfährt, es
könnte doch eines geben.
Sobald du mit Strings hantierst hast du in C mit der historischen Rolle
von "char *" zu tun. Dieser Typ darf ausdrücklich jeden anderen Typ
aliasen. Und da Stringverarbeitung in C Einzelzeichenverarbeitung über
Pointer ist...
In C landest du immer wieder beim Problem, dass Arrays nicht mehr als
Platzreservierungen sind. Sie aber nicht geschlossen als Programmobjekte
in Erscheinung treten, sondern stets als Pointer auf irgendein Element
davon. Neben Optimierungseffekten ist dadurch auch eine automatische
Indexprüfung oft nicht möglich, was uns einen Rattenschwanz an buffer
overflows eingetragen hat.
Klaus Wachtler schrieb:> doch, die gab es.> Kartenstapel ohne Nummern rein, Kartenstapel mit Nummern raus.> Rein mechanisch :-)
Wobei der absolute GAU war, wenn einem der noch unnumerierte Stapel auf
dem Weg zum Duplizierer/Nummerierer kurz davor herunter fiel ...
;-) schrieb:> FORTRAN 77 ist das.>> ;-)
Falls sich das auf die ursprngliche Frage bezieht (nach über 60
Beiträgen??), woran erkennst du, daß es ausgerechnet 77 ist?
npn schrieb:> Falls sich das auf die ursprngliche Frage bezieht (nach über 60> Beiträgen??), woran erkennst du, daß es ausgerechnet 77 ist?
Zumal sich der Fragesteller ziemlich sicher ist, dass der Ausdruck aus
den 60ern ist. FORTRAN-77 war ja nicht die 77te Inkarnation, sondern
ist, wie der Name schon sagt, von 1978.
Jay schrieb:> Wobei der absolute GAU war, wenn einem der noch unnumerierte Stapel auf> dem Weg zum Duplizierer/Nummerierer kurz davor herunter fiel ...
Im Kölner Uni-RZ gabs da Anfang der 80er eine Cyber76 mit einem
Lochkartenleser, der ähnlich wie vor einer Supermarktkasse mit ganzen
Schuhkartons von Lochkarten gefüttert wurde.
Die Leute haben also ihre Schuhkartons entleert und dann den ganzen
Stapel mit den Karten seitwärts stehend aufs "Band" gelegt. Je länger
das Programm, desto mehr Schuhkartons waren es. Lange Programme kamen da
manchmal auf 3 bis 4 Kartons... ;-)
Der Leser war affenschnell (ich schätze mal ca. 30 Karten pro Sekunde)
und man hörte nur "PRRRRRRRRRRRRRRR", wenn die Karten im tiefschwarzen
Schlund verschwanden und dann am anderen Ende des Tunnels wieder
erschienen.
Aber manchmal passierte dann genau das, was man keinem in dieser
Situation wünschte:
Nach einem kurzen aber lauten "KAWUMMMM" flogen die Lochkarten in
kleinen Fetzen oben aus den Lüftungsschlitzen des Lochkartenlesers und
rieselten dann langsam wie Schnee wieder auf die Erde.
Ich habe da schon Leute weinen sehen....
npn schrieb:> ;-) schrieb:>> FORTRAN 77 ist das.>>>> ;-)>> Falls sich das auf die ursprngliche Frage bezieht
bezieht sich darauf
> (nach über 60 Beiträgen??),
wurde es immer noch nicht spec. identifiziert nur Oberbegriff wie
"Windows"
> woran erkennst du, daß es ausgerechnet 77 ist?
die Vermutung liegt nahe
an der Gleitkomma Zahl.
Für die internen Operationen verwendet der Prozessor einen speziellen
Datentyp "TEMREAL" mit folgendem Gültikeitsbereich:
1
3.4*10**-4932<|x|<1.2*10**4932oder|x|=0
TEMPREAL hat den internen Aufbau:
1
+---+-------------------+----+----------------+
2
|S|Exponent+Bias|I|Mantisse|
3
+---+-------------------+----+----------------+
4
5
7964630
6
7
S:Vorzeichenbit
8
|:PositiondesimplizitenKommas
9
I:erstesBitderMantisse
10
Bias:16383(3FFFH)
Irrtum natürlich reserviert - denn irren ist menschlich - sagte auch der
Igel als er von der Klobürste gestiegen ist - aber bisher folgten hier
nur beleglose Ansichten.
;-)
;-) schrieb:> TEMPREAL hat den internen Aufbau:
Und worin besteht nun der Zusammenhang zwischen dem Foto aus der Frage
und deiner Präsentation von Intels 8087 Fliesskommaformat?
Jörg Wunsch schrieb:> A. K. schrieb:>> Damals muss das FORTRAN gewesen sein.>> Klar, mehr konnte der (schweinisch laute) Paralleldrucker ja nicht> darstellen. ;-)>> Aber bazzzel, pass auf, gleich wird ein FORTRAN-Jünger um die Ecke> kommen und dir erklären, dass FORTRAN keine „antike“> Programmiersprache ist. :-)
@bazzal:
FORTRAN ist keine antike Programmiersprache und wird allzeit alles
überleben, die Welt, das All, das ganze Universum
;-)
Wegen deinem Ausschnitt aus der Computernacht, womögl. der Vorgänger
oder Vor-Vorgänger oder um die Diskussion anzuwärmen,
Basic von 1964 kann es auch sein - aber da sind andere schlauer.
"WRITE" passt da nicht rein - vermute ich mal.
edit: "|" Formatierung ging verloren
A. K. schrieb:> ;-) schrieb:>> TEMPREAL hat den internen Aufbau:>> Und worin besteht nun der Zusammenhang zwischen dem Foto aus der Frage> und deiner Präsentation von Intels 8087 Fliesskommaformat?
Den darfst du dir selber herbeiführen und durch Zusammenhänge aus dem
CODE folgern.
A. K. schrieb:> Aliasing hast du in C schnell als Risiko an der Backe, weil es keine> Array-Parameter gibt, sondern nur Pointer auf Array-Inhalte.
Das ist in Fortran genauso: Arrays (und nicht nur die) werden
grundsätzlich per Referenz übergeben. Dabei geht (genauso wie in C)
meist auch die Größeninformation verloren, zumindest dann, wenn Aufrufer
und aufgerufenes Unterprogramm in verschiedenen Modulen liegen.
> Die Folge ist, dass ein Compiler auch dann mit Aliasing rechnen muss,> wenn weit und breit keines existiert. Weil das Risiko immer mitfährt, es> könnte doch eines geben.
Das muss er in Fortran auch. Es gibt vielleicht ein paar weniger Fälle,
wo Aliasing auftreten kann, aber komplett ausschließen kann man es
keineswegs.
> Neben Optimierungseffekten ist dadurch auch eine automatische> Indexprüfung oft nicht möglich, was uns einen Rattenschwanz an buffer> overflows eingetragen hat.
Über Buffer-Overflows in Fortran wird nur deswegen nicht geredet, weil
damit i.Allg. keine Programme fürs Internet geschrieben werden. Bei nur
lokal laufenden Programmen führt der Buffer-Overflow zu einem falschen
Ergebnis oder einem Segfault, stellt aber keine Angriffsfläche für
Hacker dar.
;-) schrieb:> npn schrieb:>> ;-) schrieb:>>> FORTRAN 77 ist das.>>>>>> ;-)>>>> Falls sich das auf die ursprngliche Frage bezieht>> bezieht sich darauf>>> (nach über 60 Beiträgen??),>> wurde es immer noch nicht spec. identifiziert nur Oberbegriff wie> "Windows"
Das stimmt nicht ganz:
Yalu X. schrieb:> Der gepostete Code ist übrigens konform zu FORTRAN IV (1962) bis Fortran> 2015. Die Versionen vor IV kannten noch keine booleschen Ausdrücke.
Warum es nun ausgerechnet FORTRAN 77 sein soll, erschließt sich mir auch
nicht ganz, und deine Begründung mit dem TEMPREAL verstehe ich genauso
wenig wie A. K.
>>Meine Vermutung war jedoch schon vor 30 Jahren, dass die Ursache dafür>>nicht die überragende Qualität dieser Programmiersprache ist, sondern>>vielmehr die Tatsache, dass all die alten, in FORTRAN geschriebenen>>Algorithmen sowieso kein Mensch nachvollziehen kann – selbst der>>ursprüngliche Autor nicht, und der ist mittlerweile sowieso gestorben.
Tatsächlich ist Fortran immer noch die meist genutzte Sprache, wenn es
um wirklich rechenintensive Anwendungen geht, wie. z.B. Klimamodelle,
Astronomie, theoretische Chemie, Simulation von Atombomben,
Verbrennungsvorgängen in Motoren, etc. Dies liegt weniger daran, dass
Fortran so gut ist, als dass es in diesem Bereich keine echte
Alternative gibt. C ist für numerische Rechnungen denkbar ungeeignet.
Matrixoperationen oder komplexe Zahlen sind in Standard-C eine echte
Qual, in Fortran ab Version 90 dagegen ziemlich einfach. Natürlich lässt
sich das in C oder besser C++ als Funktions- bzw Klassenbibliothek
genauso gut implementieren, nur leider gibt es dafür keine Norm.
Fortran-Programme können meist problemlos portiert werden, was auch ein
Grund dafür ist, dass sich Software-Fossile aus den 1960er Jahren bis
heute gehalten haben.
Hauptproblem bei Fortran ist, dass die meisten Programmier nicht über
das Niveau von Fortran 77, häufig nicht einmal über F IV hinausgekommen
sind und die modernen Features, die ab F90 eingeführt wurden, nicht
nutzen.
ADA wäre ein moderner und sicherer Ersatz für Fortran gewesen, leider
hat es sich ausserhalb spezieller Bereiche (Militär, Raumfahrt) nicht
durchsetzen können.
@Yalu:
Gleitkomma-Arithmetik in FORTRAN77 benutzt für die Realisierung der
Gleitkomma-Arithmetik den zuvor beschriebenen Processor ( Ab 1980 )
oder einen mit FORTRAN77 gelieferten Emulator ( vor 1980 ) mit gleichen
Funktionsumfang.
Die vorher genannten Auszüge waren für das bessere Verständnis der
FORTRAN77 spezifischen Anwendung notwendig eine Basis herzustellen, den
besagten codeschnibischap
insbesondere
1
PI=3.141592654
2
^^^^^^^^^
näher zu bestimmen den ich hier nicht im geringsten Ansatz der Antworten
erkennen konnte und eine Behauptung mit Bezug der Processoren die
Gleitkomma beherschen, erlaubte aufzustellen.
Sicher kann man auch durch Behauptung
> Der gepostete Code ist übrigens konform zu FORTRAN IV (1962) bis Fortran> 2015. Die Versionen vor IV kannten noch keine booleschen Ausdrücke.
sagen, dass es ein Allerweltslisting ist, aber ist das so üblich in
FORTRAN 2015 ;-) man kann muss es aber nicht.
Yalu X. schrieb:> Warum es nun ausgerechnet FORTRAN 77 sein soll, erschließt sich mir auch> nicht ganz, und deine Begründung mit dem TEMPREAL verstehe ich genauso> wenig wie A. K.
Getrolle, in ungewöhnlicher Variante. So lange irgendwelchen
unzusammenhängenden, oberflächlich technisch klingenden Blödsinn posten,
bis der Thread tot ist.
A. K. schrieb:> Yalu X. schrieb:>> Warum es nun ausgerechnet FORTRAN 77 sein soll, erschließt sich mir auch>> nicht ganz, und deine Begründung mit dem TEMPREAL verstehe ich genauso>> wenig wie A. K.>> Getrolle, in ungewöhnlicher Variante. So lange irgendwelchen> unzusammenhängenen oberflächlich technisch klingenden Blödsinn posten,> bis der Thread tot ist.
Das liegt darin dass man das "getrolle" nicht verstehen will und sich
eben nicht damit auskennt. Mit dem "getrolle" wurde eine Obergrenze der
Version gezogen der Du anscheinend nicht ent/ gewachsen bist. So einfach
ist das.
Bisher kamen von Dir nur sinnlose Gegenbehauptungen ohne Bezug oder
einfach nur "Schulterzucken" mit Fragen warum das so ist.
ergänzend revidiertes "getrolle":
Auf Bezug der Sendung '1966' kann es sich um FORTRAN IV oder auch um
FORTRAN 66 handeln.
Da es galt, immer das neueste zu zeigen und FORTRAN 66 1966 eingeführt
wurde, liegt der Verdacht nahe, dass es sich dann womöglich um die
Version
FORTRAN 66 handeln könnte.
"FORTRAN II, III, IV and FORTRAN 66
----------------------------------
FORTRAN II (1958) was a significant improvement, it added the
capability
for separate compilation of program modules, assembly language modules
could also be 'linked loaded' with FORTRAN modules.
FORTRAN III (1958) was never released to the public. It made possible
using assembly language code right in the middle of the FORTRAN code.
Such "inlined" assembly code can be more efficient, but the advantages
of an HLL are lost (e.g. portability, ease of use).
FORTRAN IV (1961) was a 'clean up' of FORTRAN II, improving things
like the implementation of the COMMON and EQUIVALENCE statements,
and eliminating some machine-dependant language irregularities.
A FORTRAN II to FORTRAN IV translator was used to retain backward
compatibility with earlier FORTRAN programs.
On May 1962 another milestone was traversed, an ASA committee started
developing a standard for the FORTRAN language, a very important step
that made it worthwhile for vendors to produce FORTRAN systems for
every new computer, and made FORTRAN an even more popular HLL.
The new ASA standard was published in 1966, and was known accordingly
as FORTRAN 66, it was the first HLL standard in the world.
"
http://www.ibiblio.org/pub/languages/fortran/ch1-1.html
und um es zu komplettieren:
"FORTRAN 77 standard
-------------------
Formally outdated many years ago, compilers for FORTRAN 77 are still
used today, mainly to re-compile legacy code.
FORTRAN 77 added:
o DO loops with a decreasing control variable (index).
>> hat das listing nicht
o Block if statements IF ... THEN ... ELSE ... ENDIF.
>> hat das listing ebenso nicht
Before F77 there were only IF GOTO statements.
>> hat das listing
o Pre-test of DO loops. Before F77 DO loops were always
executed at least once, so you had to add an IF GOTO
before the loop if you wanted the expected behaviour.
o CHARACTER data type. Before F77 characters were always
stored inside INTEGER variables.
o Apostrophe delimited character string constants.
o Main program termination without a STOP statement.
>> hat das listing im zweiten bild aber
"
FORTRAN 77 schliesse ich aus.
FORTRAN IV ebenso
revidiere:
Es kann sich nur um FORTRAN 66 handeln.
;-)
Mike schrieb:> C ist für numerische Rechnungen denkbar ungeeignet. Matrixoperationen> oder komplexe Zahlen sind in Standard-C eine echte Qual, in Fortran ab> Version 90 dagegen ziemlich einfach.
Matrixoperationen in älteren Fortrans (bis 77) sahen auch nicht arg viel
anders aus als in C. Fortran 90 sollte man nicht mit C, sondern eher mit
C++ vergleichen, das 1985 eingeführt wurde und um 1990 herum die
Templates erhielt. Seither gibt es auch gute und einfach anzuwendende
Lineare-Algebra-Bibliotheken für C++. Komplexe Zahlen gibt es in C++
schon länger in der Standardbibliothek und in C seit C99 sogar nativ.
Dass Fortran in gewissen Anwendungsbereichen noch nicht verdrängt wurde,
hängt vermutlich damit zusammen, dass Studenten der entsprechenden
Fächer wenig Zeit und Lust haben, mehr als eine Programmiersprache zu
lernen, da diese für sie einfach nur ein Werkzeug ist, das seinen Zweck
erfüllen und nicht 100% perfekt sein muss.
FORTRAN 77 müssen sie auf jeden Fall lernen, um bereits bestehenden Code
verstehen und weiterverwenden können. Wenn sie nun ständig in altem
FORTRAN-77-Code herumwühlen, entsteht wenig Motivation, den eigenen Code
in einem anderen Stil zu schreiben. Deswegen bleiben andere Sprachen wie
C++ komplett außen vor, aber auch neuere Fortran-Features haben nur eine
geringe Chance, verwendet zu werden.
Die nächste Generation von Studenten befindet sich dann in genau
derselben Situation und wird deswegen ebenfalls nicht über den
FOTRAN-77-Level hinauskommen.
Dass Fortran seit Version 2003 sogar objektorientiert ist, ist zwar ganz
nett, bringt aber dem Number-Crunching-Programmierer nicht die
Riesenvorteile, für die es sich arg lohnen würde, noch einmal etwas
Neues zu lernen. Interessanter sind da schon die Features für Parallel-
Computing (Fortran 2008), wobei ich mir nicht so sicher bin, ob die
tatsächlich jemand nutzt.
A. K. schrieb:> Getrolle,
widerlegt
> in ungewöhnlicher Variante.
hast wieder was dazugelernt
> So lange irgendwelchen> unzusammenhängenden,
widerlegt
> oberflächlich technisch klingenden Blödsinn posten,
widerlegt
> bis der Thread tot ist.
die Frage des TE/TO scheint somit beantwortet zu sein.
der anscheinend doch wissende "troll"
;-)
;-) schrieb:> der anscheinend doch wissende "troll"
der sich selbst widerspricht und doch jedesmal behauptet, daß es nur
diese version sein kann.
;-) schrieb:> FORTRAN 77 ist das.;-) schrieb:> FORTRAN 77 schliesse ich aus.
Und mit solchen "Begründungen" versucht etwas zu beweisen.
;-) schrieb:> o DO loops with a decreasing control variable (index).>>> hat das listing nicht>> o Block if statements IF ... THEN ... ELSE ... ENDIF.>>>> hat das listing ebenso nicht
Hat denn das Listing den Anspruch, den gesamten Sprachumfang
darzustellen? Und nur weil ein bestimmtes Statement nicht in den paar
Zeilen des Listings vorkommt, ist das ein Beweis?
Merkwürdige Vorgehensweise...
?!? schrieb:> Hat denn das Listing den Anspruch, den gesamten Sprachumfang> darzustellen?
nein - muss es das?
> Und nur weil ein bestimmtes Statement nicht in den paar> Zeilen des Listings vorkommt, ist das ein Beweis?
vorest bis es widerlegt werden kann - ja
> Merkwürdige Vorgehensweise...
es muss "denkweise" lauten
bis wohl ganz schön geknickt wa?
macht nichts - mir gehts manchmal nicht anders.
;-)
?!? schrieb:> ;-) schrieb:>> es muss "denkweise" lauten>> Das würde ja voraussetzen, daß (...)
soweit kann ich nicht denken ;-)
> Und genau deswegen sehe ich hier keinen einzigen Beweis.
Dann musst du technisch blind und auf den ohren taub sein.
Dann hilft es halt nichts. Musst es so hinnehmen.
Ich kann damit leben.
Frage wurde beantwortet und bevor er jetzt tot geflammt wird..
an dem ich sicher nicht schuld sein will .. tschüss und ade!
;-)
FORTRAN 66
Da ging noch was unter in der Formatierung:
?!? schrieb:> Und nur weil ein bestimmtes Statement nicht in den paar> Zeilen des Listings vorkommt, ist das ein Beweis?
Der damalige Coder kann nicht in die Zukunft sehen, mit welchen Futures
die nächste FORTRAN Version auf den Markt kommt so blieben nur die
verwendeten Statement zur Annahme der Version.
ade ;-)
A. K. schrieb:> In C landest du immer wieder beim Problem, dass Arrays nicht mehr als> Platzreservierungen sind. Sie aber nicht geschlossen als Programmobjekte> in Erscheinung treten, sondern stets als Pointer auf irgendein Element> davon.
Nein, Arrays sind durchaus mehr, als einfache Platzreservierungen - man
kann sie zwar dazu missbrauchen, aber man muss es nicht.
Einer der Clous von C ist die Pointerarithmetik - die dann man dem
Compiler überlassen, oder auch nicht. Wenn man sie ihm überlässt, behält
er auch bei verschachtelte unions von structs den Überblick und kann
problemlos optimieren.
Wenn der Programmierer mit expliziten Pointern logisch dasselbe macht,
dann kann er schlicht nicht damit rechnen, dass der Optimierer große
Klimmzüge macht, um da noch ein paar Takte oder Bytes rauszuholen - wer
C schreibt, sollte wissen, was er tut, denn unter dieser Prämisse wurde
die Sprache entworfen.
Fortran besteht in erster Linie mal aus Zugeständnissen an die
Computertechnologie von vor 50 Jahren: kleine Speicher, langsame
Prozessoren und alles zusammen furchtbar teuer.
Gegenüber Algol-60 kann man Fortran - das später kam - nicht eben als
Fortschritt bezeichnen. (Cobol, das als Konkurrenz zu Fortran entstand,
war allerdings selbst gegenüber Fortran noch ein Rückfall in die
Steinzeit.)
;-) schrieb:> Da ging noch was unter in der Formatierung:>> ?!? schrieb:>> Und nur weil ein bestimmtes Statement nicht in den paar>> Zeilen des Listings vorkommt, ist das ein Beweis?>> Der damalige Coder kann nicht in die Zukunft sehen, mit welchen Futures> die nächste FORTRAN Version auf den Markt kommt so blieben nur die> verwendeten Statement zur Annahme der Version.>> ade ;-)
Bevor ihr euch noch völlig zerfleischt. Könnte es nicht vielleicht sein,
daß das eine viel spätere, also neuere FORTRAN-Version ist, aber im
Listing nur Anweisungen zu sehen sind, wie sie auch von älteren
verstanden werden?
Das ist doch das gleiche, als wenn man mit einem aktuellen C++-Compiler
ein simples und primitives c-Programm schreibt. Im Quelltext muß keine
einzige C++-typische Anweisung zu sehen sein, nur einfach c-Syntax.
Trotzdem ist es mit einer modernen C++-Version geschrieben.
Frank M. schrieb:> A. K. schrieb:>> Fortran lässt sich vom Compiler besser optimieren als C.>> Das liegt doch wohl eher an der Simplizität von Fortran?>> Ich kann mir jedenfalls beim besten Willen nicht vorstellen, dass im> Endergebnis Fortran-Programme effektiver als C-Programme sind...
Ein Schreibzugriff über einen Pointer kann alle möglichen anderen
Variablen verändern, das schränkt beim optimieren ziemlich ein.
https://www.google.de/#q=ansi+aliasing
... und weil FORTRAN so "ungeheuer modern" war (in den 70ern), konnte
man damit natürlich als Physiker auch Diagramme erstellen.
FORTRAN kannte (heute auch noch?) die FORMAT Anweisung mit den
speziellen Vorschubzeichen.
Diagramme, am Lineprinter "gezeichnet", konnten damit auch mit Grautönen
erstellt werden!
Ein "+" im Format verhindert den Papiertransport (leider aber auch des
Farbtuchs), macht also ein etwas stärkeres Grau bzw. Schwarz am Papier.
Und weil halt die Zerfallskurve von Cäsium (welches habe ich vergessen)
mit mehreren Parametern dargestellt werden sollte, wurde einiges recht
dunkel gedruckt.
Nachdem nach 2 Tagen der Ausdruck noch immer nicht da war (und der
Abgabetermin ...) bin ich mit meinem Kollegen alle 2 Stunden im IRZ
nachschauen gewesen ... bis der Assistent kam und fragte ob wir was
suchen.
Ende: "Ah Ihr wart das ! Kommt gleich mit" - ab zum Prof
der Lineprinter hat so schön schwarz gedruckt, daß das Farbband (im
Gegenwert eines kleinen PKW) KO ging - und wir zur Standpauke beim Prof
...
Zur "Strafe" mussten wir dann IBM - Kanal programmieren lernen ...
rfk
rfk schrieb:> FORTRAN kannte (heute auch noch?) die FORMAT Anweisung mit den> speziellen Vorschubzeichen.
Das ist im Prinzip dasselbe, wie die printf-Formatstrings, nur viel
unbequemer.
Uhu Uhuhu schrieb:> Das ist im Prinzip dasselbe, wie die printf-Formatstrings, nur viel> unbequemer.
Findest du die tatsächlich unbequemer? Wenn der Rest von Fortran so gut
wäre wie die Ein-/Ausgabeformate, würde ich nur noch in Fortran
programmieren :)
Oder wie gibst du in C ein Array beliebiger Länge so aus, dass immer
nach jeweils 10 Werten eine neue Zeile begonnen wird?
In Fortran geht das ganz einfach mit
Nachdem ich gelesen habe, dass COBOL 2014 jetzt raus ist wundert mich
gar nichts mehr. Auch nicht dass FORTRAN 77 mit dem sie uns gequält
haben 1985 im Informatik Unterricht jetzt objektorientiert und
parallelisiert sein soll :-(
Parallelisiert ergibt da nun wirklich Sinn, auch wenn wohl eine
Diskrepanz zwischen der grobkörnigen Parallelisierung der realen
Hardware und den Konzepten der Sprache bestehen wird.
Zur Unterhaltung ein komplettes Fortran Programm.
Im übrigen war FORTRAN für kaufmännischen Anwendungen, wegen der
Implementierung der Festkommabearbeitung, völlig ungeeignet.
In den 70gern war COBOL, sogar noch heute, und RPG die
Programmiersprache der Kaufleute.
klausb schrieb:> Zur Unterhaltung ein komplettes Fortran Programm.
sieht ein bischen aus wie alte druidische Geheimschriften.
Ich bekomme Gehirn-Knoten mit dem ganzen Goto-rumgehopse ... Selbst
diese nur 119 Zeichen scheinen mir schon kaum wartbar. Und sowas war mal
die Krone der (damaligen) Programmier-Kunst? SCHAUDER
Wegstaben Verbuchsler schrieb:> Selbst diese nur 119 Zeilen scheinen mir schon kaum wartbar.
So isses. Nur deshalb hält sich die Sprache ja so lange, keiner
vergreift sich freiwillig an den Produkten seiner Vorfahren. :-)
Das Programm ist aus der Zeit vor der Veröffentlichung von Dahl,
Dijkstra und Hoare.
Ex existierten zu der Zeit, zu Wartungszwecken, extra Unterlagen wie
Blockdiagramm und Programmbeschreibung.
Im übrigen ist, auch heute noch, unübersichtliches programmieren eine
subtile Form der Arbeitsplatzsicherung. ;-)
Wegstaben Verbuchsler schrieb:> klausb schrieb:>> Zur Unterhaltung ein komplettes Fortran Programm.>> sieht ein bischen aus wie alte druidische Geheimschriften.>> Ich bekomme Gehirn-Knoten mit dem ganzen Goto-rumgehopse ...
Als so schlimm hab ich es in meiner Fortran Zeit gar nicht empfunden. (3
Jahre Industrie Programmierung mit Fortran. Lang, lang ist es her. Ich
war jung und brauchte das Geld).
Auch in Fortran ist es nicht verboten Einrückungen zu machen und den
Code mit Leerzeilen zu strukturieren.
Allerdings: Ja, die Sache mit den Labels ist natürlich schon schlimm.
Seien wir froh, dass sich bessere Strukturen etabliert haben.
Karl Heinz schrieb:> Auch in Fortran ist es nicht verboten Einrückungen zu machen und den> Code mit Leerzeilen zu strukturieren.
Auch Kommentare waren nicht verboten. ;-)
Ich kannte einen Burschen, der saß am Terminal, hielt in der Rechten
eine Zigarette und tippte mit dem linken Mittelfinger hexadezimalen
Maschinencode per Primitivst-Debugger in den Speicher. Das war in der
ersten Hälfte der 80er und gab einen Blick auf damals eigentlich schon
vergangene Computer-Zeiten frei.
Kann man von so einem Genie ernsthaft erwarten, mit irgend welchen
funktionslosen ASCII-Zeichen Speicherplatz zu verschwenden?
Wegstaben Verbuchsler schrieb:> Ich bekomme Gehirn-Knoten mit dem ganzen Goto-rumgehopse ... Selbst> diese nur 119 Zeichen scheinen mir schon kaum wartbar. Und sowas war mal> die Krone der (damaligen) Programmier-Kunst? SCHAUDER
Nein, das war natürlich nicht die Krone der damaligen Programmierkunst?
Wie kommst du auf das dünne Eis?
Das FORTRAN-Zeug war massenkompatibel für den Gebrauchsprogrammierer.
Zumindest wenn man es mit APL vergleicht:
http://www.vaxman.de/publications/apl_slides.pdf
Jay schrieb:> Zumindest wenn man es mit APL vergleicht:
Wo sind die APL Programmierer denn jetzt? Sitzen die heute in der Klapse
oder Guimmizelle und labern wirres Zeugs? Glaube nach 4 Wochen ASM
damals drohte meine Freundin auch mich zu verlassen, wenn ich mich
weiter so "merkwürdig" verhalten würde. Es lag am ASM, Rückentwicklung
zum brabbelnden Säugling, ganz klar.
Michael Reinelt schrieb:> Ja, aber bitte im Original in englisch.
Ok :)
http://www.pbm.com/~lindahl/real.programmers.html
[offtopic]
Hat zwar nichts mit Fortran zu tun, gibt mir aber trotzdem zu denken :-/
http://www.leo.org/information/freizeit/fun/programmevol.html
Bei dem "Seasoned professional" bin ich schon raus, und ueber den
"Master Programmer" brauchen wir gar nicht erst reden... Ich bin mir
nicht sicher ob Fortran oder Assembler schwerer zu warten sind, als das
was der "Master Programmer" da abliefert (auch wenn das eventuell stark
uebertrieben sein mag, so kommt mir der ein oder andere Code fuer
eigentliche einfache Sachen genau so uebertrieben vor!)
[/offtopic]
Kaj G. schrieb:> http://www.leo.org/information/freizeit/fun/programmevol.html
Nett! Sogar mit Lisp... auch eine der Sprachen, die ich eine Zeitlang
geschrieben habe (AutoCAD), leider nie verinnerlicht, aber gerne können
tät.
Immerhin verwende ich car und cdr gerne als variablennamen wenns um
Listen geht :-) (sehr zur Freude meiner Kollegen)
Christian J. schrieb:> Wo sind die APL Programmierer denn jetzt? Sitzen die heute in der Klapse> oder Guimmizelle und labern wirres Zeugs?
Sieht ganz so aus. Ab und zu mische ich im hiesigen Irrenhaus mit (A&B)
und mit wirrem Zeug habe ich dich unlängst reichlich eingedeckt. ;-)
Thread beobachten
Seitenaufteilung abschalten