siehe Bild. Muss Mitte der 1960er gewesen sein.
Das dürfte Fortran sein.
Rufus Τ. Firefly schrieb: > Das dürfte Fortran sein. Kaum. Damals muss das FORTRAN gewesen sein. ;-)
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.
:
Bearbeitet durch Moderator
Zumindest ist es kein FORTRAN(1), das kannte noch kein
1 | IF(X.LT.0) GO TO 20 |
da haette es
1 | IF(X) 20, FOO, BAR |
heissen muessen. Letzteres hat ja jetzt eine froehliche Reinkarnation im ARM-Befehlssatz gefeiert.
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.
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:
1 | // Populate compagnon matrix
|
2 | void qf_qr::cmpgn (qf_coeff& cf) { |
3 | |
4 | unsigned s = cf.size (); |
5 | qf_coeff frow = cf[slice (s - 1, s, -1)]; // Inverts cf |
6 | |
7 | qf_coeff x = -frow.shift (1); |
8 | x /= frow[0]; |
9 | (*H)[row (0)] = x[slice (0, s - 1, 1)]; |
10 | (*H)[subdiag ()] = 1.0; |
11 | #ifdef _QF_QR_DUMP
|
12 | disp (n, n); |
13 | #endif
|
14 | |
15 | balance (); |
16 | #ifdef _QF_QR_DEBUG
|
17 | disp (n, n); |
18 | #endif
|
19 | }
|
(Auszug aus Qucs.)
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...
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. Oder solche Schönheiten wie in: http://de.wikibooks.org/wiki/Fortran:_FORTRAN_77:_Programmaufbau#Symbolische_Namen Wichtig waren jedoch die Spalten. Also beispielsweise das eminent wichtige Leerzeichen in Spalte 6, das musste sein: http://de.wikibooks.org/wiki/Fortran:_FORTRAN_77:_Programmaufbau#Das_Zeilenformat
:
Bearbeitet durch User
A. K. schrieb: > Ja. Auch das geht; Danke schön :-) Muß ich mir mal in einer ruhigen Stunde zu Gemüte führen.
Ok, DONAUESCHINGEN ist zu lang. DORTMUND wars leider auch, sonst könnte man denken, das wären Fussballergebnisse. ;-)
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 | DO 10 I = 1, 10 |
2 | ...
|
3 | 10 CONTINUE |
und
1 | DO 10 I = 1. 10 |
2 | ...
|
3 | 10 CONTINUE |
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
1 | IMPLICITE NONE |
eminent wichtig :-)
Karl Heinz schrieb: > Das Beispiel das du vorher hattest, war besser. Ok, also der Unterschied zwischen: DORTMUND=1.10 DORTMUND=1,10 DORTMUND=1:10
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
1 | Name=Ausdruck |
weil in 'Ausdruck' kein Komma vorkommen kann.
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;
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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. ;-) )
:
Bearbeitet durch Moderator
Fortran lässt sich vom Compiler besser optimieren als C.
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.
Wir wär es mit der schon früher erwähnten Spalte 6. In Spalte 1 macht sich ein Stern recht gut. ;-)
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“:
1 | IF(I)10,20,30 |
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.
:
Bearbeitet durch User
./. 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.
FORTRAN haben wir noch währends des Studiums Anfang der 70er auf Lochkarten für eine IBM 1620 gestanzt. Die 1620 lief erst störungsfrei wenn die Raumtemperatur stimmte. http://de.wikipedia.org/wiki/IBM_1620#mediaviewer/File:IBM_1620_Model_1.jpg
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: >> Fortran lässt sich vom Compiler besser optimieren als C. > > Woher hast du das? Web + etwas Kenntnis von C Compilern + Hirn.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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....
Angehängte Dateien:
-
welche_ps2.jpg
45 KB
ich habe hier noch ein Codeschnipsel (==Screenshot) der WDR Computernacht 2013
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**4932 oder |x| = 0 |
TEMPREAL hat den internen Aufbau:
1 | +---+-------------------+----+----------------+
|
2 | | S | Exponent+Bias | I | Mantisse | |
3 | +---+-------------------+----+----------------+
|
4 | |
5 | 79 64 63 0 |
6 | |
7 | S : Vorzeichenbit |
8 | | : Position des impliziten Kommas |
9 | I : erstes Bit der Mantisse |
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
1 | +---+-------------------+----+----------------+
|
2 | | S | Exponent+Bias | I | Mantisse | |
3 | +---+-------------------+----+----------------+
|
4 | 79 64 63| 0 |
5 | |
6 | S : Vorzeichenbit |
7 | | : Position des impliziten Kommas |
8 | I : erstes Bit der Mantisse |
9 | Bias : 16383 ( 3FFFH ) |
Heiner, kannst du dich bitte wieder nach A&B verziehen?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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: > es muss "denkweise" lauten Das würde ja voraussetzen, daß (...) Und genau deswegen sehe ich hier keinen einzigen Beweis.
?!? 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
1 | PRINT '(10I4)', IARRAY |
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.
:
Bearbeitet durch User
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.
1 | EQUIVALENCE (KH(5),JAHR),(KH(6),MTAG),(KH(1),KSAT(1)) |
So viel zum in FORTRAN nicht vorhandenen Aliasing. :-)
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
The Story of Mel: http://www.pbm.com/~lindahl/mel.html Dann gibt's da auch noch den Spruch: "Real Programmers can write FORTRAN in any language."
Was sich dann so äußern kann:
1 | cat /*dev/null; echo "Happy New Year"\! |
2 | cat <<c*/ /*dev/null | cat > /dev/null |
3 | c */ () {} /*
|
4 | c */ main() { cat(); printf("Happy New Year!\n"); } /*
|
5 | 17 format(' Happy New Year!')
|
6 | write (6,17) |
7 | stop |
8 | end |
9 | c This program runs in four languages with the same effect. |
10 | c The languages are C, Fortran, C Shell and Bourne Shell. |
11 | c Written by Vadim Antonov, avg@hq.demos.su |
12 | c*/ |
Auch immer wieder nett: http://www.leo.org/information/freizeit/fun/pascal.html
1 | ... |
2 | |
3 | Vor langer Zeit, in der goldenen Ära der Computer, war es noch einfach, |
4 | die Männer von den Memmen zu trennen (mitunter auch "Echte Männer" und |
5 | "Müsli-Fresser" genannt). Echte Männer programmieren Computer, und |
6 | Müsli-Fresser ließen es bleiben. |
7 | |
8 | ... |
9 | |
10 | Echte Programmierer brauchen schließlich keine abstrakten Konzepte, um |
11 | ihre Arbeit zu erledigen; sie sind vollkommen glücklich mit einem |
12 | Lochkartenstanzer, einem FORTRAN-IV-Compiler und einem Bier. Echte |
13 | Programmierer erledigen Listenverarbeitung, Zeichenketten-Manipulation, |
14 | Abrechnungswesen (wenn überhaupt) und künstliche Intelligenz in FORTRAN. |
15 | Was sie mit FORTRAN nicht machen können, machen sie mit Assembler, was |
16 | sie mit Assembler nicht machen können, lassen sie verächtlich liegen. |
17 | |
18 | ... |
19 | Kapitel 3 : Strukturierte Programmierung |
20 | Einige Beobachtungen zum Thema "Echte Programmierer und Strukturierte Programmierung": |
21 | |
22 | Echte Programmierer haben keine Angst vor GOTO's. |
23 | |
24 | Echte Programmierer schreiben 5 Seiten lange DO-Schleifen, ohne |
25 | durcheinander zu geraten. |
26 | |
27 | Echte Programmierer lieben das arithmetische IF-Statement (das mit |
28 | den 3 Ausgängen), weil sie den Code interessanter machen. |
29 | |
30 | Echte Programmierer schreiben selbstmodifizierende Programme, speziell |
31 | wenn sie damit in einer kleinen Schleife 20 Nanosekunden einsparen |
32 | können. |
33 | |
34 | Echte Programmierer brauchen keine Kommentare, das Programm ist |
35 | selbstdokumentierend. |
36 | |
37 | Da FORTRAN strukturierte IF-, REPEAT-UNTIL- oder CASE- Anweisungen |
38 | nicht kennt, braucht sich der Echte Programmierer nicht zu sorgen, |
39 | daß er sie nicht benutzt. Außerdem kann man nötigenfalls über |
40 | "Assigned GOTO's" (Zuweisung eines Sprung- Labels auf eine Variable) |
41 | simulieren. |
Kaj G. schrieb: > Auch immer wieder nett: > http://www.leo.org/information/freizeit/fun/pascal.html Ja, aber bitte im Original in englisch. Sonst geht die Hälfte des Witzes verloren (wie z.B Trash-80)
:
Bearbeitet durch User
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)
Michael Reinelt schrieb: > Nett! Sogar mit Lisp dazu aus Wikipedia:
1 | Lisp ist nach Fortran die zweitälteste Programmiersprache, |
2 | die noch verbreitet ist. |
So kriegen wir auch wieder den Dreh zurueck zu Fortran :D
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. ;-)
Kaj G. schrieb: > Lisp ist nach Fortran die zweitälteste Programmiersprache, > die noch verbreitet ist. Richtig, ich wende sie jeden Tag an! (Emacs)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.