Warum hat C Fortran abgelöst und warum konnte sich Pascal nur in der DOS Ära behaupten?



  • Das war ich irgendwann mit FORTRAN, ASSEMBLER, C aber leid und habe für alles C/C++ gewählt.

    C warst du als leid, da hast du die imaginäre Sprache C/C++ gewählt? Sehr unglücklich ausgedrückt.



  • Inhalt Werkzeugkasten vorher:

    • Fortran
    • Assembler
    • C

    Inhalt Werkzeugkasten nachher:

    • C
    • C++

    Das ist nun nicht wirklich schwer zu verstehen, außer man will es unbedingt.



  • Geschichte der Progsprach schrieb:

    Vom Verbreitungsgrad hätte Pascal doch eigentlich auch in der Windowswelt noch weiterbestehen müssen.

    Wieso ist es nicht so gekommen?

    weil C (das übrigens fast gleich alt ist wie Pascal, nämlich rund 38 Jahre) damals Rückenwind aus mehreren Richtungen hatte:

    * C war "Haussprache" von *n*x, dem "Betriebssystem der Zukunft", wie man auch sagte
    * C war "Haussprache" auf zwei 68K-Heimcomputern (amiga + st), die 1985-1990 sehr populär waren
    * C-Unterstüztung für windows

    In den spätern 80ern war zeitweise ein Nachfolger von Pascal (nämlich Modula-2) recht populär auf einigen 68K-Maschinen - warum hätte man dann zum Vorgänger Pascal zurücksatteln sollen ?

    Außerdem sind die Unterschiede zwischen den beiden Algol-Abkömmlingen Pascal und C gar nicht so groß - nur, daß C eine wesentlich knackigere Syntax hat, in wohltuendem Gegensatz zu den damals längeratmigen Syntaxen von Cobol, Fortran, Pascal ... und wie sie alle hießen.



  • Vielleicht will Progsprach ja nur eine Studie anfertigen über die Entwicklung der einzelnen Programmiersprachen und die Gründe erfahren, warum man da in der Vergangenheit als Programmierer - teils mehrfach - gewechselt ist? Irgendwie war da auch Marketing-Politik der Compiler-Hersteller oder anderen Interessenten dabei. PASCAL war einmal sehr beliebt solange BORLAND mässige Preise hatte.



  • ich würd mal behaupten dass C in naher Zukunft erstmal nicht ausstirbt.
    Da man diese Programmiersprache gerne für Microcontroller Programmierung benutzt...



  • Geschichte der Progsprach schrieb:

    Und wäre Ada für wissenschaftliche Berechnungen nicht besser geeignet?

    Ich habe noch keinen Ada-Code in dem Bereich gesehen. Wäre mir auch neu, dass Ada dafür irgendwelche nennenswerten Vorteile hätte. Wir reden da in den meisten Fällen ja nicht von sicherheitskritischen Anwendungen.

    rüdiger schrieb:

    Und Fortran ist im wissenschaftlichen Umfeld wirklich nicht tot. Ohne einen Fortran-Compiler hat man im HPC-Bereich keine Chance.

    Für bestehende Projekte schon, bei Neuentwicklungen meine ich aber zu beobachten, dass immer mehr in C++ gemacht wird. Ich kann aber auch nur für Finite Elemente-Codes und was da so dran hängt sprechen. Teilweise baut man sich dann ganz hübsche Interfaces um bestehende effiziente Fortran- oder C-Codes fürs 'number crunching' und nutzt an anderen Stellen generische Programmierung, OOP und Co. aus. Teilweise baut man aber auch komplette Codes in C++. Gegenüber Fortran verliert man u.U. etwas Performance, aber ich denke, dass viele Leute das in Kauf nehmen um Code zu schreiben, der generisch, modular und einfach wartbar ist.



  • Walli schrieb:

    einfach wartbar

    einfach wartbar... ...was für ein Traum. 🙂 ...hier mal ein kleiner Ausschnitt aus dem Fortran Code, mit dem ich es momentan zu tun habe:

    SUBROUTINE mkgylm(
         >                  jspins,rv,thet,nsp,nspd,jspd,
         >                  rh,rhdr,rhdt,rhdf,rhdrr,rhdtt,rhdff,
         >                  rhdtf,rhdrt,rhdrf,
         <                  agr,agru,agrd,g2r,g2ru,g2rd,gggr,
         <                  gggru,gggrd,grgru,grgrd,gzgr)
    
    [...]
    
              agr(i) = sqrt(grr**2+grt**2+grf**2)
    
              IF (agr(i).LT.chsml) CYCLE points_2
    
              dagrr = (rdr*drdr*rv3+rdt* (rdrt*rv1-rdt)+
         +            rdf* (rdrf*rv1-rdf)/sint2)/agr(i)/rv3
    
              dagrt = (rdr*rdrt*rv2+rdt*rdtt+rdf* (-rdf/tant1+rdtf)/sint2)/
         +            (agr(i)*rv3)
    
              dagrf = (rdr*rdrf*rv2+rdt*rdtf+rdf*rdff/sint2)/
         +            (agr(i)*rv3*sint1)
    
              g2r(i) = drdr + 2.e0*rdr/rv1 + (rdtt+rdt/tant1+rdff/sint2)/rv2
    
              dzdr = ((rdru-rdrd)*ro- (rou-rod)*rdr)/ro2
    
    c         dzdtr,dzdfs vanish by definition.
              dzdtr = 0.0
              dzdfs = 0.0
    
              gggr(i) = grr*dagrr + grt*dagrt + grf*dagrf
    
              gzgr(i) = dzdr*grr + dzdtr*grt + dzdfs*grf
    
              grru = rdru
              grtu = rdtu/rv1
              grfu = rdfu/rvsin1
    
              agru(i) = sqrt(grru**2+grtu**2+grfu**2)
    
              dagrru = (rdru*rdrru*rv3+rdtu* (rdrtu*rv1-rdtu)+
         +             rdfu* (rdrfu*rv1-rdfu)/sint2)/agru(i)/rv3
    
              dagrtu = (rdru*rdrtu*rv2+rdtu*rdttu+
         +             rdfu* (-rdfu/tant1+rdtfu)/sint2)/ (agru(i)*rv3)
    
              dagrfu = (rdru*rdrfu*rv2+rdtu*rdtfu+rdfu*rdffu/sint2)/
         +             (agru(i)*rv3*sint1)
    
              g2ru(i) = rdrru + 2.e0*rdru/rv1 +
         +              (rdttu+rdtu/tant1+rdffu/sint2)/rv2
    
              gggru(i) = grru*dagrru + grtu*dagrtu + grfu*dagrfu
    
              grgru(i) = grr*grru + grt*grtu + grf*grfu
    
              grrd = rdrd
              grtd = rdtd/rv1
              grfd = rdfd/rvsin1
    
              agrd(i) = sqrt(grrd**2+grtd**2+grfd**2)
    
              dagrrd = (rdrd*rdrrd*rv3+rdtd* (rdrtd*rv1-rdtd)+
         +             rdfd* (rdrfd*rv1-rdfd)/sint2)/agrd(i)/rv3
    
              dagrtd = (rdrd*rdrtd*rv2+rdtd*rdttd+
         +             rdfd* (-rdfd/tant1+rdtfd)/sint2)/ (agrd(i)*rv3)
    
              dagrfd = (rdrd*rdrfd*rv2+rdtd*rdtfd+rdfd*rdffd/sint2)/
         +             (agrd(i)*rv3*sint1)
    
              g2rd(i) = rdrrd + 2*rdrd/rv1 +
         +              (rdttd+rdtd/tant1+rdffd/sint2)/rv2
    
              gggrd(i) = grrd*dagrrd + grtd*dagrtd + grfd*dagrfd
    
              grgrd(i) = grr*grrd + grt*grtd + grf*grfd
    

    100.000 Zeilen davon, selbstverständlich kaum Kommentare. Die meisten wissen glaube ich gar nicht, wieviel gut wartbarer Code eigentlich wert ist. Aber in erster Linie ist das unabhängig von der Programmiersprache. 😋



  • Walli schrieb:

    Für bestehende Projekte schon, bei Neuentwicklungen meine ich aber zu beobachten, dass immer mehr in C++ gemacht wird. Ich kann aber auch nur für Finite Elemente-Codes und was da so dran hängt sprechen. Teilweise baut man sich dann ganz hübsche Interfaces um bestehende effiziente Fortran- oder C-Codes fürs 'number crunching' und nutzt an anderen Stellen generische Programmierung, OOP und Co. aus. Teilweise baut man aber auch komplette Codes in C++. Gegenüber Fortran verliert man u.U. etwas Performance, aber ich denke, dass viele Leute das in Kauf nehmen um Code zu schreiben, der generisch, modular und einfach wartbar ist.

    Den Eindruck habe ich auch gewonnen. Zumindest bei dem Institut, für die ich mal ein bisschen gewerkelt habe, haben die stark auf Metaprogrammierung und Boost gesetzt. Durch die ganze Metaprogrammierung haben die sogar schnelleren Code generiert als Fortran.

    @Gregor
    pfff das nutzt ja nicht mal die richtig fiesen FORTRAN Features und wer braucht schon Variablennamen die länger als 6 Zeichen sind? 😉

    http://www.pbm.com/~lindahl/real.programmers.html



  • rüdiger schrieb:

    @Gregor
    pfff das nutzt ja nicht mal die richtig fiesen FORTRAN Features und wer braucht schon Variablennamen die länger als 6 Zeichen sind? 😉

    http://www.pbm.com/~lindahl/real.programmers.html

    In dem Code gibt es durchaus diverse Highlights. Letzt habe ich zum Beispiel eine Stelle über ~1000 Zeilen entdeckt, die aus einer Zeit stammt, in der es in Fortran noch keine Schleifen gab. 😋



  • Geschichte der Progsprach schrieb:

    Welche Vorteile hat hier Fortran?

    - Keine Zeigerarithemtik (dafür in Fortran 77 massig andere Altlasten)
    - viele hochoptimierte Bibliotheken (siehe BLAS und LAPACK)
    - gute Compiler
    - schon lange komplexe Datentypen
    - seit Fortran 9x Operationen auf Felder

    Geschichte der Progsprach schrieb:

    Wie sieht es mit der Threadingfähgikeit von Fortran in Multicore CPUs aus, ist Fortran dafür überhaupt geeignet?

    Üblicherweise nutzt man dafür OpenMP und für Kommunikation zwischen Knoten MPI, und das gibt es jeweils für C, C++ und Fortran. OpenMP wird faktisch von jedem Compileranbieter unterstützt. OpenMP macht es sehr einfach Schleifen zu parallelisieren, so daß man sich kaum mit den Problemen von Threads herumschlagen muß. Die Syntax verdeckt das meiste von dem LowLevel Gefrickel, mit dem man sonst konfrontiert ist. Natürlich ist OpenMP nicht so flexibel wie ein direktes Threadinterface. Allerdings interessiert das bei technischwissenschaftlicher Software nicht so sehr.

    P.S. Fortran 77 Code ist zum K****, seit Fortran 90 wurde viel von dem alten Mist abgeändert.



  • Geschichte der Progsprach schrieb:

    Ok, aber gibt's mittlerweile nicht lauter C Implementierungen für die gestellten Mathematischen Probleme?

    C kennt erst seit C 1999 komplexe Datentypen, und die braucht man in der Physik eigentlich immer. Als C endlich komplexe Datentypen konnte, gab es aber schon Fortran95, und da ist der Druck auf C zu Wechseln relativ gering. Mit Fortran 2003 wurde eine normierte Schnittstelle zu C eingeführt, so daß man viele Libraries nun aus Fortran herausnutzen kann. Daher gibt es noch weniger Gründe C zu benutzen. Aktuell ist Fortran 2008 und die Compiler haben bisher Fortran 2003 und Fortran 2008 nur in Teilen umgesetzt, aber das ist schon mehr als C von Haus aus kann. C hat einige Stärken die aber im technisch wissenschaftlichen Rechnen nicht sonderlich wichtig sind. Hochoptimierende Fortran Compiler gibt es.



  • Alles schön mit neuerem FORTRAN versus C. Nur da wurde irgendwann der langgediente MSF-Compiler von MS als nicht mehr unterstützt herausgekegelt oder sogar verweigert. Gut, man konnte zwischenzeitlich alles auch mit C machen - und viele FOPRTRAN-Programmierer haben so den Umstieg gemacht. Ich fühle mich heute in C und C++ genauso fit wie wie vorher in FORTRAN.



  • berniebutt schrieb:

    Alles schön mit neuerem FORTRAN versus C. Nur da wurde irgendwann der langgediente MSF-Compiler von MS als nicht mehr unterstützt herausgekegelt oder sogar verweigert. Gut, man konnte zwischenzeitlich alles auch mit C machen - und viele FOPRTRAN-Programmierer haben so den Umstieg gemacht.

    Huh? Fortran wird auf Supercomputern eingesetzt. Da gibt es eh kein MS?! 😕



  • in fortran muß man einfach mehr tippen und das nicht so spaßig...



  • Gregor schrieb:

    Huh? Fortran wird auf Supercomputern eingesetzt. Da gibt es eh kein MS?! 😕

    Ja und nein! Als die PCs in den 80er Jahren verfügbar waren, gab es dort sofort auch FORTRAN (von MS und anderen). Auf C musste man etwas warten oder UNIX-Maschinen einsetzen.


  • Mod

    PC != Supercomputer

    Microsoftcompiler auf Supercomputern sind echte Exoten. Daher juckt die Einstellung von MS-Fortran die Gesamtverbreitung von Fortran so gut wie gar nicht, da das Hauptverbreitungsgebiet von Fortran die Supercomputer sind.



  • SeppJ schrieb:

    PC != Supercomputer ... Daher juckt die Einstellung von MS-Fortran die Gesamtverbreitung von Fortran so gut wie gar nicht, da das Hauptverbreitungsgebiet von Fortran die Supercomputer sind.

    Hätte nicht sein müssen für PCs! Ein ordentlich gepflegter FORTRAN-Compiler auf PC-Systemen kann es auch tun. Gibt es ja noch, nur nicht von MS! 🙂
    Edit: Aber Programmierer wollten und wollen nur möglichst eine Programmiersprache für alles. Genau das hat C am besten bieten können und bietet es noch heute!


Anmelden zum Antworten