Autor |
Nachricht |
TomS |
Verfasst am: 29. Dez 2020 10:53 Titel: |
|
Hallo Michael, erst mal danke für die Hinweise. Zu Go und dem speziellen Ansatz weiter unten mehr. Bisher habe ich nur einiges im Internet gelesen. Eigentlich dachte ich, dass ich ein NN-Framework für Julia nutze, aber ich werde zunächst doch zu Fuß programmieren, um die Sprache besser zu verstehen. Tic-Tac-Toe und allgemeinere Varianten wie (m,n,k)-Spiele haben alle das selbe Problem des spares rewards: die Belohnung erfolgt am Ende des Spiels, d.h. sehr selten. Das unterscheidet diese Probleme grundsätzlich z.B. von Mustererkennung, wo eben zu jedem Bild einer Katze oder eines Hundes sofort ein Feedback erfolgt. Damit wird das übliche Backtracking und die Anpassung der Gewichte mittels lokaler Optimierung wie gradient descent u.ä. unmöglich. Eine Variante ist, das NN nicht auf das Spielziel zu trainieren, sondern “sinnvolle Zwischenziele” einzuführen, für die dann jedesmal Backtracking erfolgen kann. Dabei gibt es mehrere Probleme: Zunächst muss man eine Bewertungsfunktion einführen, die nicht nur den Sieg bewertet sondern Stellungen, d.h. zwei Steine in einer Reihe, Drohung, Zentrum usw. Das ist für Tic-Tac-Toe einfach machbar - man kann alle zulässigen Spielbäume generieren und im Speicher halten - für komplexere Spiele - und das beginnt schon mit Vier-Gewinnt - sehr aufwändig. Letztlich implementiert man fast ein klassisches und sehr effizientes alpha-beta-pruning, lediglich ohne den Zuggenerator, um dies dann - extrem ineffizient - durch das NN erlernen zu lassen (Stockfish kann im normalen Spiel viel mehr Stellungen pro Sekunde analysieren als AlphaZero und hat wahrscheinlich die wesentlichen ausgefeiltere Stellungsbewertung). Dann gibt es noch ein theoretisches Problem, nämlich das der Q-Funktion. Vereinfacht gesagt bestimmt die Q-Funktion das Ziel des NNs. Im Falle von Tic-Tac-Toe ist die Q-Funktion trivial: sowohl für X als auch für O muss das NN auf Remis trainiert werden, da es sich um ein stark-gelöstes Spiel mit optimaler = Remis-Stragie für beide Spieler handelt. Vier-Gewinnt und Go (auf kleineren Brettern als 19 x 19) sind schwach gelöst, es existiert eine Gewinnstrategie für den Anziehenden. In allen Fällen kann bewiesen werden, dass keine Gewinnstrategie für den nicht-Anziehenden existiert. Demnach dürfte man das NN für Tic-Tac-Toe nie auf Sieg trainieren, im Falle von komplizierteren Spielen zumindest nicht für den Nachziehenden. Das ist aber praktisch irrelevant, da dies ja nur im Falle eines perfekt spielenden Gegners gilt. Im Falle von Tic-Tac-Toe ist das aber extrem relevant, da das Spiel so einfach ist; trainiert man das NN auf Remis, bleibt das Spiel immer langweilig; trainiert man es auf Sieg, verliert das NN evtl. auch in Positionen, wo Remis erreichbar wäre (AlphaZero spielt im Schach irrational und schwach in Situationen, wo es nach eigenem Wissen verlieren wird; es stellt zum Beispiel keine Fallen und führt keine komplexen Stellungen herbei, um den Gegner in Zeitnot zu bringen). Man muss also wieder sehr viel explizites Tic-Tac-Toe-Wissen anwenden. Tic-Tac-Toe ist also leider ein extrem ungeeignetes Beispiel für NNs, und kann deswegen nur eine kurze Übung sein. Zu AlphaGo und AlphaZero sowie Monte-Carlo-Tree-Search: Die Idee besteht darin, die Zwischenbewertung anhand der Wahrscheinlichkeit der zukünftigen Gewinne in einem Sub-Tree zu ermitteln. Es wird also kein Go-Wissen eingefüttert, es wird stattdessen anhand der Statistik der bisher gespielten (gelernten) Spiele ermittelt, welcher Sub-Tree zu spielen ist. Im Training werden die Sub-Trees irgendwann vollständig ausgespielt, so dass eine Bewertung erfolgen kann; die Backpropagation = das Lernen erfolgt jedoch für die Wahl des Sub-Trees. AlphaGo lernt also nicht direkt, zu gewinnen, es lernt, aus den vorhandenen Möglichkeiten diejenigen auszuwählen, für die die höchste Gewinnwahrscheinlichkeit vorliegt (so habe ich das verstanden). Ich hatte mir die Idee schon vor Jahren angeschaut. Der Kerngedanke ist recht einfach, die Umsetzung jedoch extrem aufwändig: man benötigt insbs. einen Spielbaumgenerator, eine exakte Buchführung, Backpropagation, also die komplexe Kombination beider Welten (und das sind nur die unmittelbar erkennbaren Elemente, dazu kommen noch zig technische Details). So mach ich es also auch nicht ;-) Ich möchte zwei Dinge kombinieren: 1) ein NN, das lernt, ein Spiel zu spielen, jedoch ohne Backpropagation, da dies entweder ziemlich sinnlos wird oder extrem kompliziert - siehe oben. 2) Einen evolutionären Algorithmus, der aus einer NN-Population die erfolgreichsten Kandidaten auswählt. Das ist sicher deutlich einfacher als Monte-carlo-tree-search, zugleich jedoch auch näher an der Realität als ein klassisches NN für gelöste Spiele. Das NN soll dabei ganz klassisch auf der Outputseite die Wahrscheinlichkeit der eigenen Züge ausgeben; dabei soll es auch die Regeln für die erlaubten Züge erlernen. Die Bewertung der Population erfolgt anhand d.h. mittels verschiedener Gewichtungen für Sieg (win w) und Remis (draw d). Das NN soll eine Teil der Spiele gegen sich selbst (jeweils eine andere NN-Instanz *) sowie einen Teil gegen einen random-Player spielen. Bei 64 NNs wären das mindestens 2016 Spiele je Runde plus die gegen den random-Player. Ein Spiel ist wenig aussagekräftig; nimmt man eher 100, wird die Zahl der notwendigen Spiele je Population bereits recht groß. Bei 32 NNs wäre das mit 496 Paarungen und demnach 49600 Partien recht überschaubar - zumindest bei 3*3 = 16 oder 4*4 = 32 Zügen je Partie (die Partien werden bei einem Sieg natürlich nicht weitergespielt). Ansonsten reduziere ich auf 16 NNs. Nach einer Population werden die besten z.B. 4 NNs ausgewählt und daraus 7 * 4 = 28 Clone plus Mutationen erzeugt, die dann in der nächsten Runde antreten. *) EDIT: gerade erkannt, dass es zusätzlich auch gegen die eigene Instanz spielen soll; dann werden es etwas mehr Spiele Was mir noch unklar ist, wo genau der Zufall bei der Evolution ansetzen soll. Es gibt zwei Möglichkeiten bei der Mutation der NNs zur Erzeugung einer neuen Generation: a) Mutationsrate pro neuer Generation werden K aus N Gewichte mutiert; über die Zeit wird R reduziert. b) Gewichtung der Mutation je weight im NN f() ist eine fixe Zufallsverteilung, epsilon wird über die Zeit reduziert. Das entspricht dem Ansatz des simulated annealings. Man untersucht heute in der KI die Neuroevolution zur Anpassung der Hyper-Parameter, d.h. die Zahl der Ebenen der NNs, der Neuronen, auch der Lernzyklen usw. Ich würde dies alles jedoch zunächst parametrierbar einbauen und die Evolution nur zur Anpassung der Gewichte nutzen. Mir ist klar, dass dies deutlich ineffizienter ist als MCTS, jedoch wesentlich einfach zu implementieren. Und man kann das sehr gut parallelisieren, ggf. auch für wenig Geld in eine Cloud schieben. |
|
|
ML |
Verfasst am: 29. Dez 2020 01:37 Titel: |
|
Hallo Tom,
TomS hat Folgendes geschrieben: | Über die Feiertage versuche ich mal, ein neuronales Netz für Tic-Tac-Toe und Vier-Gewinnt zu trainieren.
| das Erstellen einer KI für Vier-Gewinnt will ich perspektivisch nächstes Jahr in der Schule in einem Wahlpflichtfach anbieten. Falls Du Dich noch nicht im Detail auskennst, empfehle ich zur Lektüre folgende Veröffentlichungen: a) das Alpho-Go-Zero Cheat Sheet https://www.datasciencecentral.com/profiles/blogs/deep-learning-alphago-zero-explained-in-one-picture und b) das Paper "Mastering the game of Go without human knowledge", doi:10.1038/nature24270 Die dort vorgestellte KI ist eine der berühmten GO-Kis, die die menschlichen Meister degradiert hat und kann im Prinzip auch auf Vier-Gewinnt angepasst werden. Sie ist von der Programmierung her allerdings m. E. nicht ohne Tücken. So verwenden die Autoren beispielsweise eine KI mit zwei Köpfen statt zweier separater KIs. Allein, um den Überblick zu behalten, würde ich die einzelnen KIs vorziehen. Bei zwei KI-Köpfen stelle ich es mir auch schwer vor, die Verlustfunktionen gut auszutarieren, denn der Anlernvorgang muss letztlich auf die Optimierung beider KI-Ausgänge gleichzeitig optimieren. Allerdings stecke ich bestimmt nicht so tief in der Thematik drin wie die Verfasser des Papers. Mir hat der Kopf, ehrlich gesagt, ganz schön geraucht, als ich mir das Vorgehen im Detail angeschaut habe. Wenn Du sowas "nebenbei in den Weihnachtsferien" codest, alle Achtung! Oder kanntest Du die Papers eventuell noch nicht, und ich habe Dich soeben mit der Idee angefixt? Corona geht ja vielleicht noch länger als uns lieb ist Viele Grüße und viel Erfolg Michael |
|
|
TomS |
Verfasst am: 21. Dez 2020 16:18 Titel: |
|
Also dafür ist es sicher nicht gemacht, aber es funktioniert ;-) Ich parse die Kommandozeile, schicke das Argument --arg1 per Socket an einen Server; der empfängt das Argument, lädt das entsprechende Julia-Skript, compiliert es dynamisch und führt es aus. Das klappt sogar mit den Streuprogrammen von gestern. Nächster Schritt ist, das mit fertig compilierten Modulen anstelle von Skripten zu testen. Alternative wäre, den gesamten Code per Socket zu schicken. Für kurze Skripte allemal sinnvoll. Auch für Hacker sicher spannend ;-) Das Testscript, das dynamisch geladen und ausgeführt wird:
Code: | # script worker1 module worker1 export work using Printf function something1() println( @__FILE__, ": something1()" ) return nothing end function work() println( @__FILE__, ": work()" ) something1() return nothing end # work() end
| Das Skript, das die Anforderung wegschickt; das Parsen der Kommandozeile ist schön gelöst:
Code: | # module to send data via socket # module to launch tasks asynchronously via socket # tasks implemented by dynamically loaded julia scripts, retrieved from command line using Sockets using Printf using ArgParse # parse command line arguments function parse_commandline() s = ArgParseSettings() @add_arg_table s begin "--opt1" help = "an option with an argument" "--opt2" help = "another option with an argument" arg_type = Int default = 0 "--flag1" help = "an option without argument, i.e. a flag" action = :store_true "arg1" help = "a positional argument" required = true end return parse_args(s) end # sends launch commands via socket function socketclient( message ) # println( "Client on port 12321" ) sock = connect( 12321 ) # write( sock, "$message\r\n" ) println( sock, message ) close( sock ) return nothing end # retrieve task to be launched from command line function main() parsed_args = parse_commandline() # for ( arg, val ) in parsed_args # println( " $arg => $val" ) # end message = string( parsed_args["arg1"] ) # println( message ) socketclient( message ) return nothing end main()
| Der Server, der die Aufräge abarbeitet; Sockets wie vorhin, jedoch jetzt noch Laden, Parsen und Aufrufen des fremden Skripts
Code: | # module to process tasks asynchronously # tasks implemented by dynamically loaded julia scripts using Sockets using Printf # loads worker scripts and calls their standard work() functions function callworker( modname::AbstractString ) try include( modname * ".jl" ) # println( "call ", modname, "->work()" ) Main.eval( Meta.parse("using Main.$modname") ) mod = getfield( Main, Symbol(modname) ) Base.invokelatest( mod.work ) # standard entry function is work() catch ex println( "Caught exception: $ex" ) end return nothing end # listens to launch commands via socket function socketserver() println( @__FILE__, ": Process server on port 12321" ) try server = listen( 12321 ) instance = 0 while true sock = accept( server ) instance += 1 socklabel = "$(getsockname(sock)) number $instance" @async begin println( "Server connected to socket $socklabel" ) # write( sock, "Reply from echo server.\r\n" ) while isopen( sock ) message = readline( sock ) callworker( message ) # write( sock, "$message\r\n" ) println( "Echoed $message to socket $socklabel" ) end # println( "Closed socket $socklabel" ) end end catch ex println( "Caught exception: $ex" ) end return nothing end function main() socketserver() # callworker( "worker1" ) return nothing end main()
|
|
|
|
TomS |
Verfasst am: 21. Dez 2020 13:41 Titel: |
|
Sockets funktionieren stabil und übersichtlich. Ansonsten ist IPC Unix-artig mit Semaphoren und Signalen sowie Shared Memory vorhanden. Async. File-IO habe ich nicht ausprobiert. Leider gibt es keine echten MessageQueues. MPI habe ich nicht ausprobiert, ich brauche was einfaches. Server:
Code: | # module to receive data via socket using Sockets using Printf function socketserver() println( "Echo server on port 12321" ) try server = listen( 12321 ) instance = 0 while true sock = accept( server ) instance += 1 socklabel = "$(getsockname(sock)) number $instance" @async begin println( "Server connected to socket $socklabel" ) write( sock, "Reply from echo server.\r\n" ) while isopen( sock ) message = readline( sock ) # write( sock, "$message\r\n" ) # println( "Echoed $message to socket $socklabel" ) end println( "Closed socket $socklabel" ) end end catch ex println( "Caught exception: $ex" ) end return nothing end function main() socketserver() return nothing end main()
| Client:
Code: | # module to send data via socket using Sockets using Printf function socketclient( message ) println( "Client on port 12321" ) sock = connect( 12321 ) println( sock, message ) return nothing end function main() for num in 1:10 message = string( @__FILE__ ) * ": main()" * " -> worker(): " * string( num ) socketclient( message ) end return nothing end main()
|
|
|
|
TomS |
Verfasst am: 21. Dez 2020 00:03 Titel: |
|
Der Plot ist nicht ganz selbsterklärend, die Beschriftung fehlt noch. Der Nordpol entspricht der 0°-Vorwärtsstreuung. Die Farbe zeigt die Anzahl der Events („Zählrate“). Im Falle der Coulombstreuung liegt natürlich Energieabhängigkeit vor, ich werde dafür noch einen zweiten Plot einbauen. Der Appetit kommt beim Essen: - numerische Berechnung des Streuwinkels für beliebige Potentialfunktion - Heatmap auf rotierbarer Kugeloberfläche - Histogram |
|
|
masterpie |
Verfasst am: 20. Dez 2020 22:53 Titel: |
|
Woh, toll. Ich habe das bei mir als Pluto-Notebook eingegeben (musste noch drei Packages compilieren) und habe rechnen lassen. Da Pluto möchte, dass jede Kommentarzeile, using-Zeile, jede Funktion und natürlich main() in einer NB-Zeile stehen - angeblich wegen einfacherer Fehlersuche - kann ich sehen, welche Zeit pro Zeile vergeht (in ns, ms, us, ms und s). Bei den using-Zeilen ist die Plots-Initialisierung mit 17s "Klassenbester". Die Main-Funktion läuft bis zu den fertigen PNGs auf der Platte 342 s. Da ist also ordentlich was zu tun. Das rechtfertigt eine Software wie julia. Gruß, Masterpie |
|
|
TomS |
Verfasst am: 20. Dez 2020 20:57 Titel: |
|
Ich habe jetzt ein minimales Setup zusammen; unter Windows läuft das mit Julia 1.5.3 sehr smooth. Ich muss noch etwas experimentieren, wie man den JIT Compiler austrickst; das dauert schon etwas; andererseits lohnt sich's auch nicht, jede mini-Funktion gleich in ein prä-compiliertes Paket zu stecken. Der Julia-Kernel wird wohl je Script immer neu hochgezogen; ich hab noch nix anderes gefunden. Interessant wär's, einem eigenen listener-Script immer neue Module unterzujubeln; mal schauen, ob und wie das geht (ich denke an den Script-Namen per IPC / MPI o.ä., dann Laden und jeweils Aufruf einer worker-Funktion ...) Über die Feiertage versuche ich mal, ein neuronales Netz für Tic-Tac-Toe und Vier-Gewinnt zu trainieren. Anbei ein kleines Script zur Berechnung von Streuquerschnitten: Anstelle des eigtl. Streuquerschnitts als Funktion des Streuwinkels berechne ich (berechnet Julia) eine Heatmap für die Position der auslaufenden Teilchen auf einer Kugelfläche. Diese projiziere ich flächentreue in die xy-Ebene. Wenn ich überlege, wie wir da mit Fortran und gnuplot rumgehampelt haben ...
Code: | # module to calculate scattering cross sections using LinearAlgebra using OnlineStats using RDatasets using Plots using PlotThemes using Printf using LaTeXStrings # https://juliapackages.com/p/latexstrings # returns random in-vector in B^2 as impact parameter b <= 1.0 and sin(phi), cos(phi) # input none function in2vector() while true x, y = ( 2.0 * rand() - 1.0, 2.0 * rand() - 1.0 ) b2 = x^2 + y^2 if b2 <= 1.0 b = sqrt( b2 ) sin_phi = x / b cos_phi = y / b return ( b, sin_phi, cos_phi ) end end end # classical hard-sphere scattering: # returns out-vector on S^1 as radius = 1.0, sin(theta) and cos(theta); theta is scattering angle # input is impact parameter b; (a = 1.0 is not used) function hardsphere_out2vector( b::Real, a::Real = 1.0 ) sin_theta = 2.0 * b * sqrt( 1.0 - b^2 ) cos_theta = 2.0 * b^2 - 1.0 return ( 1.0, sin_theta, cos_theta ) end # classical Coulomb scattering: # returns out-vector on S^1 as radius = 1.0, sin(theta) and cos(theta); theta is scattering angle # input is impact parameter b; a is quotient of E_kin / E_inter function coulomb_out2vector( b::Real, a::Real = 1.0 ) x = b / a d = x^2 + 1 sin_theta = 2.0 * x / d cos_theta = (x^2 - 1.0) / d return ( 1.0, sin_theta, cos_theta ) end # Hammer equal-area projection from sphere S^2 to ellipsis ~B^2 in xy-plane # returns x, y # input is sin(theta) and cos(theta) function hammer( sin_phi::Real, cos_phi::Real, sin_theta::Real, cos_theta::Real ) sin_phi_half = sign( sin_phi ) * sqrt( (1.0 - cos_phi) / 2.0 ) cos_phi_half = sqrt( (1.0 + cos_phi) / 2.0 ) denom = sqrt( 1.0 + sin_theta * cos_phi_half ) x = sqrt( 2.0 ) * 2.0 * sin_theta * sin_phi_half / denom y = 2.0 * cos_theta / denom return ( x, y ) end # performs scattering using parametric function for scattering angle and calculates heat-map # returns heat map # input is scattering function and number ofr runs function work( func, runs ) xy_tupel = (0.0 , 2.0) heat = fit!( HeatMap(-3:.01:3, -3:.01:3), xy_tupel ) for n = 0:runs b, sin_phi, cos_phi = in2vector() r, sin_theta, cos_theta = func( b, 0.175 ) xy_tupel = hammer( sin_phi, cos_phi, sin_theta, cos_theta ) fit!( heat, xy_tupel ) end return heat end # calls worker functions for different scattering scenarios; calls plot routines function main() theme( :dark ) heat = work( hardsphere_out2vector, 1000000000 ) p = plot( heat, title = "Hard sphere scattering", marginals = false, legend = true ) savefig( p, "hardsphere.png" ) heat = work( coulomb_out2vector, 1000000000 ) p = plot( heat, title = "Coulomb scattering", marginals = false, legend = true ) savefig( p, "coulomb.png" ) return nothing end main()
|
|
|
|
masterpie |
Verfasst am: 19. Dez 2020 22:24 Titel: |
|
Musste recht viel nachinstallieren und einiges einem neuen Build unterziehen. Aber am Ende läuft es nun unter Windows. Mit Linux warte ich, bis die dort auch bei Version 1.5.x sind. Da wird etliches von Python und PythonQt genutzt. Viele Packages muss man erst mal installieren (wenn man im Netz darauf stößt) und initialisieren. Das dauert beim ersten mal seine Zeit. Aber wenn ich danach ein nb unter Pluto aufrufe, ist in kürzester Zeit das Ergebnis vorhanden. Da kann ich schon staunen. Werde mir das weiter anschauen. Gruß,Masterpie |
|
|
TomS |
Verfasst am: 19. Dez 2020 22:20 Titel: |
|
masterpie hat Folgendes geschrieben: | Ich habe nun julia auch unter openSusE-Leap15.2 installiert. Eigentlich nichts anderes als auf dem RaspberryPi, nur schlechter. Auch Version 1.03 und keine Updates. Versuche mit Updates aus dem Netz von anderen Anbietern haben nichts verbessert. Also unter SuSe-Linux für mich nicht nutzbar. | Zu Linux kann ich nichts sagen, war seit Jahren nicht mehr auf meinem Rechner. Ich hab die Windows-Version von der Julia-Homepage installiert, lief - fast perfekt: der Installer kommt nicht mit Multi-User-Umgebungen zurecht und installiert die SW immer ins persönliche Profil - seltsam. Pakete zieht Julia immer von github, das funktioniert gut.
masterpie hat Folgendes geschrieben: | Ich habe Mit Kernelneustart meinte ich den Kernel von Jupyter. | Ok, Missverständnis. Das Problem mit dem Julia-Kernel besteht weiter. Ich schau mal, was sich machen lässt. Ich muss auch etwas Profiling betreiben, wo die Zeit bis zum eigtl. Start liegenbleibt; könnte ja auch der JIT-Compiler sein.
masterpie hat Folgendes geschrieben: | Ich hGrafikausgaben unter Raspian/Linux gelingen nicht, da sich die Programmerweiterung nicht übersetzen und damit nicht installieren lässt. Unter Windows sieht es ähnlich aus. | Irgendein Paket hat - ungefragt - Qt nachinstalliert, ein anderes Python-Teile; das halte ich für lästig. Aber die Graphik-Ausgabe funktioniert, wobei ich das nicht direkt brauche; eine PNG-Erzeugung reicht. |
|
|
masterpie |
Verfasst am: 19. Dez 2020 18:17 Titel: |
|
TomS hat Folgendes geschrieben: | Den Sinn der Julia-Konsole habe ich ehrlich gesagt nicht verstanden... | Wahrscheinlich nur als eine Art Startplattform. (Alle weiteren Beschreibungen beziehen sich auf die Windows10-Julia 1.5x-Version) In dieser wird Pluto installiert. Das ist ein interaktives, reaktives Notebook und vollständig in Julia geschrieben und für die Arbeit mit Julia gedacht. Damit besteht keine Notwendigkeit mehr, Jupyter zu verwenden. Pluto wird eine schnellere Arbeitsweise gegenüber Jupyter bestätigt. Naja und das ist dann auch gleich eine ganz andere Arbeitsoberfläche als die Julia Konsole. Die Installation wird in verschiedenen Inet-Quellen beschrieben. Diese hier http://blog.schockwellenreiter.de/2020/08/2020080102.html gefiel mir recht gut. Da wird auch zum WARUM von Pluto und seinen Verbesserungen kurz etwas gesagt. Man findet aber unter YouTube noch etliche weitere Install-Anleitungen (meist in englisch) und sicher sind die YouTube-Videos der JuliaCon 2020 und 2019 auch recht interessant. Nach Start des Notebook-Servers (von Pluto) verlässt man die Julia-Konsole und kann unter seiner "Julia-IDE" auf Pluto weiter arbeiten. Ist ein editieren im Webbrowser. Viel Spaß, beim Erforschen der Möglichkeiten. Grüße, Masterpie P.S.: Grafik läuft nun ( 22:12) auch unter Windows nach längeren Reparaturarbeiten. |
|
|
masterpie |
Verfasst am: 19. Dez 2020 13:05 Titel: |
|
Ich habe nun julia auch unter openSusE-Leap15.2 installiert. Eigentlich nichts anderes als auf dem RaspberryPi, nur schlechter. Auch Version 1.03 und keine Updates. Versuche mit Updates aus dem Netz von anderen Anbietern haben nichts verbessert. Also unter SuSe-Linux für mich nicht nutzbar. Mit Kernelneustart meinte ich den Kernel von Jupyter. Der muss nicht immer neu gestartet werden. Nur wenn ich in einem nb die Ausgaben lösche und alles neu abarbeiten lasse, wird die Zeilennummerierung fortgesetzt. Das muss aber nicht störend sein. Grafikausgaben unter Raspian/Linux gelingen nicht, da sich die Programmerweiterung nicht übersetzen und damit nicht installieren lässt. Unter Windows sieht es ähnlich aus. Im Netz findet man Anwendungsbeispiele, die vielfach eine Version 1.3 oder 1.4 von julia erfordern. Das deckt nur die 1.5x-Version unter Windows ab. Ich denke, hier sollte man noch etwas Entwicklungszeit vergehen lassen, wenn man die hohe Verarbeitungsgeschwindigkeit nicht zwingend braucht. Ansonsten kann ich auch nur sagen, erstaunlich was hier openSource anbietet. Ich würde mich immer wieder mal melden, wenn es echte Fortschritte gibt. Grüße, Masterpie |
|
|
TomS |
Verfasst am: 19. Dez 2020 09:07 Titel: |
|
Ich arbeite bisher - sehr sparsam - mit Notepad++ und der Windows-Kommandozeile; alles was ich brauche, wird jeweils in ein kleines Skript reingepackt (das mache ich auch in anderen Sprachen so, auch für LaTeX; ich mag diese Einstellungen über graphische Front-Ends nicht). Ansonsten sieht das Notebook im Browser aber gut aus - ich werd’s mal mal testen. Von Visual Studio habe ich mich - außer für C++ - verabschiedet. Ich find‘s nicht schlecht, aber für meine Zwecke zu groß. Den Sinn der Julia-Konsole habe ich ehrlich gesagt nicht verstanden, aber ich bin halt auch Compiler-verseucht. Zum Kernel-Neustart: Kann man diesen verhindern, wenn man ein Julia-Skript per julia test.jl aus der Windows-Kommandozeile startet, also den Kernel gestartet lassen und ihm immer ein neues Skript unterschieben? Oder wird zwingend immer ein neuer Kernel-Prozess je Julia-Skript gestartet? wäre das wirklich der einzige Vorteil der Julia-Konsole? Ich stell morgen mal ein kleines Programm ein; schon cool, was als Open Source verfügbar ist; nicht nur Mathematik und Statistik, auch sehr gute Graphik, distributed computing, MPI, ... |
|
|
masterpie |
Verfasst am: 18. Dez 2020 15:44 Titel: |
|
TomS hat Folgendes geschrieben: | Interessant - aber Öl für‘s Feuer kann ich nicht erkennen ;-) | Danke, war ja auch nur als Spaß gedacht. Das Thema vi/vim hat schon heftige Stürme in entsprechenden Foren ausgelöst. Schön, wenn das hier sachlicher läuft. Ich habe in den letzten Stunden julia auf einem Raspi4B installiert und auch gleich noch die Jupyterumgebung. Muss man nicht machen. Man kann julia ja auch so im Terminal starten bzw. ist erst mal erforderlich, um danach die Kommandos julia> using IJulia julia> notebook() abzusetzen. Im Webbrowser (hier Chromium) wird Jupyter gestartet und darunter wird ein neues Notizblatt (nb) als Julia 1.0.3 Notebook gestartet. Darin kann dann wie üblich unter Jupyter gearbeitet werden. Kernelneustart dauert bei mir ewig. Würde ich nicht empfehlen. Dann lieber das nb verlasssen und neu starten. Das gleiche versuche ich jetzt unter Win10. Dauert alles etwas. Also Geduld ist angesagt. Ablauf sieht ziemlich genau so aus wie unter Raspian. Nur unter win10 ist das bereits julia 1.53 (vom 9.11.2020) während Raspian noch mit 1.03 daher kommt. Unter openSusE-Linux werde ich es mir auch noch anschauen. Unter Win10 habe ich durch die Anaconda-Installation auch Jupyter laufen und darunter mit Python3, Sympy getestet. Aber arbeite da lieber mit Spyder3. julia> using IJulia julia> notebook() tut, wie gewünscht. Nur hier fragt er nun, ob er mit install Jupyter via Conda, y/n? weitermachen soll. Na gut, dann y und die die dritte Jupyter-Installation auf die Platte. Ist ja noch etwas Platz vorhanden. Die ca. 15GB sind zu verschmerzen. Win10-Julia lädt miniconda installer ..., installiert und konfiguriert diesen und holt alle erforderlichen Programme und Pakete und extrahiert und installiert diese. Na, da geht eine ganz schöne Menge Daten über die Leitung. Sieht vieles wie die Anaconda-installation aus. Am Ende hat er Conda und IJulia installiert und Jupyter sogar von meinem Jupyter-Homeverzeichnis gestartet. Soweit allles rumpelfrei durchgelaufen. Gleiches Julia-Kurztestprogramm reingehämmert. Läuft alles und korrekt. Alles abgspeichert und Kernel neu gestartet. Läuft auch und naja ... schon einiges schneller als auf dem kleinen Raspi4. Alles heruntergefahren und alle Windows (etwas brutal) geschlossen. Mit den kryptischen Ausschriften auf der Julia-Konsole könnte man Mitmenschen erschrecken. Danach notebook() unter julia-Konsole neu gestartet und sofort wurde Jupyter gestartet. Dort im "Home" das Testprogramm aufgerufen. Kernelstart scheint etwas länger zu brauchen als der Python-Kernel braucht. Aber erträgliche Zeit. Testprogramm läuft wieder problemlos durch. Kernelrestart auch wieder möglich - für den Notfall sinnvoll. Die vielen kryptischen Ausschriften auf der Julia-Konsole muss man nicht beachten. Das lässt sich bestimmt beim Aufruf unterdrücken. Aber muss ja nicht alles beim ersten mal sein. Soweit bin ich erst mal arbeitsfähig für julia-Tests und somit zufrieden. Grüße, Masterpie |
|
|
TomS |
Verfasst am: 18. Dez 2020 13:10 Titel: |
|
Interessant - aber Öl für‘s Feuer kann ich nicht erkennen ;-) |
|
|
masterpie |
Verfasst am: 18. Dez 2020 10:05 Titel: |
|
TomS hat Folgendes geschrieben: | Also vi ist natürlich die Katastrophe schlechthin. | Na endlich mal ein Thema, wo ich ordentlich Öl ins Feuer kippen kann ... Ich arbeite seit 31 Jahren (einem Augustwochenende 1989) mit dem vi. Emacs habe ich immer mal versucht, aber mir fehlte die Geduld. Der heutige vi nennt sich zu recht vim (m-modifiziert) und kann erheblich mehr, als die Uraltversion aus Unix/SystemV-Zeiten. Dazu noch ein Tool wie make und man kann vieeeel lernen. Siehe z.B. die VLen hier https://ad-wiki.informatik.uni-freiburg.de/teaching/ProgrammierenCplusplusSS2020 von Frau Prof. Bast zu C++ in Freiburg. :thumb Ich finde, sie macht das sehr gut und lässt ihren Studenten viele Freiheiten. Am Ende müssen aber alle ein bestimmtes Schema einhalten - sicher wegen der Vergleichbarkeit bei der Bewertung. So nebenbei lernt der Student Linux-Kommandos, die Bedienung des vim und die Erstellung von Make-skripten. Bei den Preisen, die die Frau Prof. schon geholt hat, kann das nicht die falsche Lernmethode sein und wenn man vi/vim einmal in den Fingern hat, behält man diese Fertigkeiten. Von der Pike auf lernen und zu Beginn ohne IDE wird von fast allen Autoren/Lehrenden empfohlen. Vor 30 Jahren endete gerade die Zeit der begehbaren Rechner. Doch selbst damals moderne Workstations hatten kaum Taktfrequenzen über 20 MHz und meist nur 16 Bit-Datenbreite. Da war ein 19"-Schirm schon etwas Besonderes, doch kaum mal mit X11-Oberfläche und wenn, dann halt recht langsam. Meist bekam man ja doch nur ein ASCII-Terminal zugewiesen. Da war nix mit IDE und ähnlich netten Dingen. Dafür lief der vi bei IBM, DEC, DG, Sun, HP und was weiß ich noch wo. Auch 30 Jahre später, wenn man nichts sonst passendes auf einer "alten Möhre" fand. Der vi tat es immer. Selbst, wenn man mit C objektorientiert programmieren wollte. Klar diese Zeiten gehen zu Ende und wer effektiv arbeiten will, wird sich nach bestimmter Anlernzeit auch auf eine IDE stürzen. Bei Python habe ich das recht früh mit Spyder gemacht. Für die C-Sprachen hat man gute Auswahl von KDevelop, QtCreator, Code::Blocks, CodeLite, Xemacs, Kate, Anjuta und etlichen weiteren. Für Java sind Netbeans und Eclipse sicher die Wahl. Dennoch kann ich mit vim und make (cmake) auch heute recht schnell arbeiten und bin immer gut im Bilde, was ich tue und nicht was die IDE tut. Ein Makefile (oder CMake-) sollte ein Programmierer schreiben können (bei Java ein Ant-File). Funktioniert auch auf einem Intel-10-Kerner mit 5 GHz mit NVDIA-Supergrafikkarte oder einem Raspi4+ am 32"-4K-Flachdisplay. Ich war nie ein Anhänger irgendwelcher Glaubenskriege, welches OS, welche Programmiersprache, welche Tools. Man nimmt, was man muss oder was man will, wenn man es kann und darf. Dazu sind die Aufgaben zu unterschiedlich und jeder wird wissen, was für ihn das beste Tool, das beste OS oder die beste Programmiersprache inkl. Editor bis IDE ist. Wie hier schon richtig festgestellt: Es kommt auf die jeweilige Aufgabe an. Supermoderne Frameworks haben am richtigen Ort ihre Berechtigung - aber nicht immer. In der Netzwerk- und Systemprogrammierung würde ich bei C und Assembler bleiben und sicher beim Prototyping mit Python, Perl, TCL/Tk oder Bash schon zufrieden sein können. Bei größeren und komplexeren Projekten ist für mich C++ mit IDE und entsprechenden Standard-Libs und Qt angesagt. Mit Python kann ich dank Anaconda und Spyder auch unter Windows entwickeln. Mit Code::Blocks auch bedingt C++. Mit den MS-IDEs komme ich nicht klar und muss es nicht. Wenn mir Maple als am hilfreichsten erscheint, dann wird es das sein. Mit Processing und weiteren Möglichkeiten ist Programmierung möglich. Grüße, Masterpie P.S.: LabView ist auch etwas interessantes ... |
|
|
Steffen Bühler |
Verfasst am: 18. Dez 2020 09:06 Titel: |
|
Fehlt nur noch, dass hier einer mit Labview ankommt. Diesen Vortrag sollte jeder von uns mal gesehen haben. Viel Spaß! |
|
|
TomS |
Verfasst am: 18. Dez 2020 08:04 Titel: |
|
Die zu lösenden Probleme sind sich völlig unterschiedlich. In der Mathematik ist die Struktur des Problems zumeist klar - das erledigt der Mathematiker - lediglich die effiziente Implementierung stellt eine Herausforderung dar. Letztlich benötige ich Bibliotheken, die bestimmte Aufgaben lösen; welche das sind, in welcher Reihenfolge und mit welchen Abhängigkeiten, das legt der Mathematiker (oder Physiker, Ingenieur, ...) fest. Für eine bestimmte Aufgabenstellung lohnt ein Framework-Ansatz zumeist nicht. Frameworks hingegen definieren einen Rahmen für die Architektur, wobei z.B. Inversion of Control und Dependency Injection die „Orchestrierung“ des Zusammenspiels unterschiedlicher Klassen oder Microservices bzw. deren Instanzen ermöglichen (in diesem Sinne ist vieles, was sich heute mit dem Begriff Framework schmückt, tatsächlich kein solches). Diese hohe Flexibilität und Wiederverwendbarkeit benötigt man in der Mathematik eher selten. In meinem Umfeld sehe einen Trend hin zur Metamodellierung und Domain-driven Design / formalen Domain Specific Languages. Der Problemraum, die Abhängigkeiten, Geschäftsprozesse und -objekte werden modelliert, Software mit (lose gekoppelten) Interaktionen wird weitgehend generiert. Dabei kommen für den generierten Code sowie die orchestrierten Interaktionen zunehmend die selben Ansätze zum Einsatz. Die o.g. Das führt jetzt aber weit von der ursprüngliche Fragestellung weg. |
|
|
Qubit |
Verfasst am: 18. Dez 2020 06:05 Titel: |
|
Ich sehe im mathematischen Umfeld auch Julia stark im Kommen. Tatsächlich sind aber auch CAS inzwischen voll programmierbar (mit entsprechenden Schnittstellen). Ingenieure nutzen hingegen spezifische Programme zur Simulation und Berechnung. Ansonsten muss man natürlich schauen, um welche Anwendungen/Plattformen es sich handelt. Bleibt man systemnah / embedded, dann führt kaum ein Weg an C (und Assembler) vorbei, vielleicht wären da GO oder Rust eine Alternative? Im Business-Bereich dominiert die Java-Welt (mit entsprechenden Frameworks). Mit der neuen GraalVM ( https://www.graalvm.org ) wird es eine Runtime-Umgebung geben, die durchaus an kompilierten C-Code ranreichen wird. Hier hat man dann die freie Wahl, ob Java oder Scala,Scriptsprachen wie Groovy oder Kotlin oder aber auch Python. Wobei, Python selbst nimmt eine Sonderstellung ein, ist multiparadigmenfähig und hat gute Bindings zu C/Libs. Also, Mathematiker programmieren mit Libs, Informatiker mit Frameworks |
|
|
TomS |
Verfasst am: 17. Dez 2020 23:31 Titel: |
|
Also vi ist natürlich die Katastrophe schlechthin. Nein, es ging mir darum, dass wenn man von C / C++ / ... kommt, Python irgendwie lax aussieht; z.B. Strukturierung per Einrückung ohne explizites Blockende; ... ist halt Geschmacksache Ich will nicht in Abrede stellen, dass die Sprache für ernsthafte Aufgaben anwendbar ist. |
|
|
ML |
Verfasst am: 17. Dez 2020 23:13 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
Hallo,
TomS hat Folgendes geschrieben: | Und daran, dass du Python in Erwägung ziehst
| Na aber hallo. Und wehe, Du schlägst vor, Python mit einem Folter-Editor wie vi zu bedienen.
Zitat: | Ich hab mir das angeschaut: ja, sieht einfach aus, ist mir aber zu wischi-waschi ...
| Es kommt halt drauf an, was Du damit machen willst. Für die Entwicklung von neuronalen Netzen finde ich die Kombination Python+Tensorflow ziemlich gut, und Signale und Plots lassen sich mit Python anscheinend auch ganz gut ausgeben. Viele Grüße Michael |
|
|
masterpie |
Verfasst am: 17. Dez 2020 22:26 Titel: |
|
Ich habe vor 40 Jahren mit Assembler begonnen, dann C (die meiste Zeit und als einzige Sprache auch beruflich), etwas Basic und später etwas C++, Java und seit 8 Jahren bin ich von Python und seiner recht großen Wissenschaftscommunity begeistert – aber nur noch als Hobby. Bei den CAS-Systemen gefällt mir Maple sehr gut. Matlab habe ich mir kurz angesehen. Es soll mal von Python ersetzbar sein. Auf dem Raspi kann man Mathematica (Wolfram) kostenfrei nutzen und mit Raspi 400 läuft das auch schon ganz gut. Für C++ kann ich "Forschung mit Modernem C++" von Gottschling empfehlen. Der Autor arbeitet an der Weiterentwicklung mit, macht Lehrgänge (eigene Firma SimuNova, tolle eigene Bibliothek MTL4 - auf Geschwindigkeit getrimmt) und kennt Stroustrup persönlich gut. Bei MTL4 habe ich einen guten Eindruck gewonnen, was man aus C++ raus holen kann. Bei Python gefällt mir aktuell Physik mit Python von Natt gut. Neu und für mich noch nicht einschätzbar ist der "Python-Kurs" von Steinkamp. Die Bücher von Klein sollte man sicher haben oder kennen. Natürlich gibt es noch viele andere gute und sehr gute Bücher. Julia schaue ich mir mal demnächst an. Auf keinem der Systeme bin ich Profi gewesen. Heute mache ich das alles ohnehin nur zum Spaß – auf Win10, openSuSE-Linux und Raspian auf Raspis von Version 1 bis 4. Macht Spaß und man muss ja irgendwie durch den Lockdown kommen. Gruß, Masterpie |
|
|
TomS |
Verfasst am: 17. Dez 2020 22:02 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
ML hat Folgendes geschrieben: | Dass ich kein echter Programmierer bin, sieht man daran, dass ich noch nie den Reiz verspürt habe, eine eigene Programmiersprache zu erfinden.
| Und daran, dass du Python in Erwägung ziehst Ich hab mir das angeschaut: ja, sieht einfach aus, ist mir aber zu wischi-waschi ... Gerade quäle ich mich durch Julia-Code, mächtig, aber ungewohnt. |
|
|
ML |
Verfasst am: 17. Dez 2020 19:50 Titel: Re: Programmiersprachen für mathematische Anwendungen |
|
Hallo,
TomS hat Folgendes geschrieben: | Mich würde einfach mal interessieren, welche Sprachen ihr so kennt und verwendet - sowie natürlich eure Erfahrungen. | die Frage ist ja immer, ob man schnell ein Programm braucht oder ein schnelles Programm. Als Schüler habe ich mit Pascal angefangen, später in der Uni habe ich auf C umgesattelt. Inzwischen beschäftige ich mich vorwiegend mit Signalverarbeitung und neuronalen Netzen und nutze dazu Matlab. Es hat für meine Anwendungen mächtige Befehle, so dass ich bequem programmieren und parallelisieren kann. Für kleinere Anwendungen beim Arduino (in der Lehre) nutze ich das in der Entwicklungsumgebung genutzte C-ähnliche Konstrukt. Mittelfristig steige ich vermutlich auf Python um, da meine Schüler das meist schon können. Dass ich kein echter Programmierer bin, sieht man daran, dass ich noch nie den Reiz verspürt habe, eine eigene Programmiersprache zu erfinden. Viele Grüße Michael |
|
|
Nils Hoppenstedt |
Verfasst am: 17. Dez 2020 16:31 Titel: |
|
Steffen Bühler hat Folgendes geschrieben: | Ob man mit Matlab wiederum Klassen oder auch brauchbare Benutzeroberflächen mit Buttons und Slidern erstellen kann, weiß ich nicht. Und ob man mehrere kleine Matlab-Quellcodedateien statt einer großen zu einem Programm verlinken kann, ebenfalls nicht. Sound und Video sowie Datenbanken wären auch interessante Themen, halt alles, was das Gebiet der Mathematik nicht mehr so betrifft.
| Ja klar, das geht alles. Matlab ist in den letzten Jahren sehr mächtig geworden. Es gibt inzwischen auch gute Machine-Learning-Implementierungen.
Steffen Bühler hat Folgendes geschrieben: | Könnte ich zum Beispiel in ein Mikrofon sprechen, und Matlab macht in Echtzeit eine Digitalfilterung und gibt die aus? | Laut Mathworks geht dies ebenfalls: https://de.mathworks.com/help/audio/gs/real-time-audio-in-matlab.html Viele Grüße, Nils |
|
|
Steffen Bühler |
Verfasst am: 17. Dez 2020 16:11 Titel: |
|
Nils Hoppenstedt hat Folgendes geschrieben: | Was unterscheidet denn Matlab von einer Programmiersprache? | Wenn ich es richtig sehe, wohl nicht viel. Es gibt anscheinend Schleifen und Abfragen wie in jeder Programmiersprache. Und es gibt wohl auch Compiler, damit man ein ausführbares Programm erstellen kann. Somit scheint es sich vom reinen C strukturell nicht zu unterscheiden, es sind eben weitaus mehr mathematische Grundfunktionen drin, die man in C erst durch eine Library bekommt. Ob man mit Matlab wiederum Klassen oder auch brauchbare Benutzeroberflächen mit Buttons und Slidern erstellen kann, weiß ich nicht. Und ob man mehrere kleine Matlab-Quellcodedateien statt einer großen zu einem Programm verlinken kann, ebenfalls nicht. Sound und Video sowie Datenbanken wären auch interessante Themen, halt alles, was das Gebiet der Mathematik nicht mehr so betrifft. Könnte ich zum Beispiel in ein Mikrofon sprechen, und Matlab macht in Echtzeit eine Digitalfilterung und gibt die aus? |
|
|
TomS |
Verfasst am: 17. Dez 2020 15:59 Titel: |
|
Steffen Bühler hat Folgendes geschrieben: | Und: ein anständiges Programm muss objektorientiert sein, sonst wird es doch nur Spaghetticode mit globalen Variablen. | In der Informatik und vielen Anwendungen ja, in der Mathematik eher nein (lediglich für die Definition von Objekten wie komplexen Zahlen oder Quaternionen, mit denen dann jedoch prozedural oder funktional gearbeitet wird). Bzgl. deiner Kritikpunkte - Coding vs. professioneller SW-Entwicklung - gebe ich dir teilweise recht. Was ich am meisten vermisse ist das Verständnis von Nebenläufigkeiten. Ich arbeite z.Zt. als Systemarchitekt im industriellen Umfeld - Prozessleitsysteme, IIoT, Cloud, ... - und erkenne immer öfter, dass die Ausbildung diesen Anforderungen nicht gerecht wird. Nach Abschluss meines Studiums habe ich in der Industrie beobachtet, dass Informatiker speicherfressende Klassenbibliotheken entwicklen, während Mathematiker performante und robuste SW in C schreiben. Heutzutage generieren manche Kollegen schöne UIs mit Angular, die niederen Dienste verachten sie ... Ich würde heute für bestimmte Positionen ausschließlich Programmierer einstellen, die auch C beherrschen, unabhängig davon, ob das auch verwendet wird. Das wäre mir wichtiger als eine FFT - aber ich weiß, was du meinst. C++ ? Erstens inzwischen zu verwässert, und außerdem mag ich die STL nicht: kompakt, aber zu viel implizite Kapselung; solange keine Probleme auftreten ist alles OK, aber Debuggen? Interprozesskommunikation mit Streams? Was ich auch nicht mag ist, wenn dir eine Bibliothek ein bestimmtes Programmierparadigma alternativlos aufoktroyiert. |
|
|
Nils Hoppenstedt |
Verfasst am: 17. Dez 2020 15:45 Titel: |
|
Hallo Steffen, Nur interessehalber: Was unterscheidet denn Matlab von einer Programmiersprache? Viele Grüße, Nils |
|
|
Steffen Bühler |
Verfasst am: 17. Dez 2020 15:20 Titel: |
|
Matlab ist ja eher ein CAS als eine Programmiersprache. Sowas nehme ich natürlich auch, hier werkelt noch ein Mathcad 5.0 fröhlich vor sich hin. Was das nicht hinkriegt, mach ich mit Wolfram. |
|
|
Nils Hoppenstedt |
Verfasst am: 17. Dez 2020 14:21 Titel: |
|
Ich nutze hauptsächlich Matlab. Vorteile sind die hohe Performance bei Matrizen-Operationen (insbesondere Bildverarbeitung), die umfangreichen Visualisierungsmöglichkeiten und natürlich die riesige Matlab-Community. Viele Grüße, Nils |
|
|
Steffen Bühler |
Verfasst am: 17. Dez 2020 13:58 Titel: |
|
Fortran hab ich Mitte der 80er im Studium kurz kennengelernt, dann hab ich mir Basic auf dem Amiga selber beigebracht. Auch den 68000-Assembler, um den Prozessor richtig kennenzulernen. In den 90ern kam dann berufsbedingt Pascal, C, C++ dazu. Insbesondere letzere Sprache ist nach wie vor mein Favorit. Ästhetisch und alles andere als geschwätzig. Und: ein anständiges Programm muss objektorientiert sein, sonst wird es doch nur Spaghetticode mit globalen Variablen. Bei Visual Studio, Python und Co. sehe ich die Gefahr, dass effizientes Programmieren verlernt wird. So, ich brauch mal eben 1 Gigabyte Speicher für mein Bild? Kein Problem. Freigeben muss ich ja nichts, der Garbage Collector sorgt schon für alles. Drei if-Abfragen in einer for-Schleife? Warum soll das langsam sein, bei 4GHz Prozessortakt? Ich merk nichts. Vier returns in einer Funktion? Ist doch nicht schlimm, jemand anders muss das ja nicht verstehen, solange es funktioniert. Diese Arbeitsweise beobachte ich in den letzten zehn Jahren verstärkt bei jungen Kollegen. Und wundere mich so langsam auch nicht mehr, dass auch professionelle Software immer mehr Speicher will und trotzdem langsam ist. Man sollte die Informatik-Studenten vielleicht wirklich mal im Praktikum an einen 8bit-Prozessor mit 500KB RAM setzen und eine FFT programmieren lassen, einfach um wieder mehr Demut hineinzubringen. Viele Grüße Steffen |
|
|
TomS |
Verfasst am: 15. Dez 2020 21:20 Titel: Programmiersprachen für mathematische Anwendungen |
|
Mich würde einfach mal interessieren, welche Sprachen ihr so kennt und verwendet - sowie natürlich eure Erfahrungen. Ausgangspunkt für mich war C: schnell, unsicher, und in den 80igern gab's noch keine große Lib für Mathematik; komplexe Zahlen, Vektoren ... musste man vollständig selbst programmieren. An der Uni dann FORTRAN wg. diverser Bibliotheken und natürlich den Atlasten (*) Immerhin konnte man damit vernünftige Dinge berechnen, z.B. die elektromagnetischen Formfaktoren von Nukleonen ... Mit Computeralgebra bzw. symbolische Mathematik al la Mathematica, Maple usw. hat sich damals noch kaum jemand befasst; heute ist das nicht mehr wegzudenken. Da ich jedoch seit ca. 20 Jahren viel mit Software-Entwicklung im industriellen Umfeld zu tun habe (C, C++, C#, Ada, Java) war mir eine zu spezialisierte Programmiersprache eh' nicht so sympathisch. Auf der Suche nach einer universellen Programmiersprache mit dennoch starkem Fokus auf Mathematik bin ich dann über Python und einem kurzen Blick auf R bei Julia gelandet, was sowohl Mathematik als auch moderne Softwarekonzepte verbindet. https://en.wikipedia.org/wiki/Julia_(programming_language) https://julialang.org/ https://julialang.org/benchmarks/ Über Weihnachten hab' ich Zeit ... (*) Echte Programmierer meiden PASCAL Vor langer Zeit, in der goldenen Aera der Computer, war es noch einfach, die Maenner von den Memmen zu trennen (mitunter auch ``Echte Maenner'' und ``Muesli-Fresser'' genannt). Echte Maenner programmierten Computer, und Muesli-Fresser liessen es bleiben. Ein echter Computer- Programmierer sagte Dinge wie ``DO 10 I=0,10'' oder ``ABEND'', und der Rest der Welt quengelte ``Computer sind mir zu kompliziert'' oder ``Ich kann zu Computern keine gefuehlsmaessige Bindung aufbauen - sie sind zu unpersoenlich''. Dabei zeigt schon Remy Eyssen's Buch ``Echte Maenner moegen kein Muesli'' (Heine TB 6290), dass echte Maenner zu nichts und niemandem eine ``gefuehlsmaessige Bindung'' aufbauen, und dass sie auch keine Angst haben, unpersoenlich zu sein. Aber die Zeiten aendern sich. Heute stehen wir einer Welt gegenueber, in der kleine alte Damen vollcomputerisierte Mikrowellenherde kaufen koennen, in der 12 Jahre alte Dreikaesehochs gestandene Maenner bei ASTEROIDS und PACMAN sattmachen, und in der jeder seinen eigenen Heimcomputer kaufen und sogar verstehen kann. Der Echte Programmierer ist gefaehrdet, von Studenten mit einem igITT 2020 (deutsche Version des ABFALL II, A.d.Ue.) im Gepaeck ersetzt zu werden! Es gibt allerdings einige Unterschiede zwischen dem typischen PACMAN- spielenden Gymnasiasten und einem Echten Programmierer. Die Kenntnis dieser Unterschiede wird den Heranwachsenden ein Ziel geben, nach dem sie streben koennen - ein Vorbild, eine Vaterfigur. Ausserdem schuetzt sie die Echten Programmierer vor der Arbeitslosigkeit. Der einfachste Weg, um einen Echten Programmierer zu erkennen, fuehrt ueber die von ihm benutzte Programmiersprache. Echte Programmierer benutzen FORTRAN. Muesli-Fresser benutzen Pascal. Niklaus Wirth, der Schoepfer von Pascal, wurde einmal gefragt, wie man seinen Namen ausspreche. ``You can either call me by name, pronouncing it 'Veert', or call me by value, 'worth''', antwortete er. Diese Bemerkung zeigt sofort, dass Wirth ein Muesli-Fresser ist. Der einzige Parameteruebergabemechanismus, den Echte Programmierer akzeptieren, ist call-by-value-return (call-by-result, A.d.Ue.), wie er in den IBM/370 Fortran-G und -H-Compilern implementiert ist. Echte Programmierer brauchen schliesslich keine abstrakten Konzepte; sie sind vollkommen gluecklich mit einem Lochkartenstanzer, einem Fortran-IV-Compiler und einem Bier. Echte Programmierer erledigen Listenverarbeitung, Zeichenketten-Manipulationen, Abrechnungswesen (wenn ueberhaupt) und kuenstliche Intelligenz in FORTRAN. Was sie mit FORTRAN nicht machen koennen, machen sie mit Assembler; was sie mit Assembler nicht machen koennen, lassen sie veraechtlich liegen. Akademische Computerspezialisten sind in den letzten Jahren aufs Abstellgleis der strukturierten Programmierung geraten. Sie behaupten, dass Programme verstaendlicher werden, wenn bestimmte Sprachkonstrukte und Programmiertechniken benutzt werden. Sie koennen sich natuerlich nicht einigen, welche Konstrukte am besten geeignet sind, und die Beispiele, an denen sie ihren speziellen Standpunkt aufzeigen wollen, passen ausnahmslos auf eine einzige Seite irgendeines obskuren Journales. Als ich aus der Schule kam, dachte ich, ich sei der beste Programmierer der Welt. Ich konnte ein unschlagbares TIC-TAC-TOE-Spiel schreiben, beherrschte 5 verschiedene Programmiersprachen und schrieb fehlerfreie 1000-Zeilen-Programme. Dann kam ich in die Wirklichkeit. Meine erste Aufgabe bestand darin, ein 200000-Zeilen-FORTRAN-Programm zu lesen, zu verstehen und um den Faktor 2 zu beschleunigen. Jeder Echte Programmierer wird einem versichern, dass die gesamte strukturierte Programmierung der Welt in einem solchen Fall nicht hilft - hier braucht man wirklich Talent. Einige Beobachtungen zum Thema ``Echte Programmierer und strukturierte Programmierung'': * Echte Programmierer haben keine Angst vor GOTOs. * Echte Programmierer schreiben 5 Seiten lange DO-Schleifen, ohne durcheinander zu geraten. * Echte Programmierer lieben arithmetische IF-Statements (die mit den 3 Ausgaengen, A.d.Ue.), weil sie den Code interessanter machen. * Echte Programmierer schreiben selbstmodifizierende Programme, speziell wenn sie damit in einer kleinen Schleife 20 Nanosekunden einsparen koennen. * Echte Programmierer brauchen keine Kommentare, das Programm ist selbstdokumentierend. * Da FORTRAN strukturierte IF-, REPEAT...UNTIL- oder CASE- Anweisungen nicht kennt, braucht sich der Echte Programmierer nicht zu sorgen, dass er sie nicht benutzt. Ausserdem kann man sie noetigenfalls ueber "Assigned GOTOs" (Zuweisung eines Sprung- labels auf eine Variable, A.d.Ue.) simulieren. Auch Datenstrukturen waren in der letzten Zeit in der Diskussion. Abstrakte Datentypen, Records, Pointer, Listen und Zeichenketten sind in gewissen Kreisen populaer geworden. Wirth, der Muesli-Fresser, verfasste sogar ein ganzes Buch ("Algorithmen und Datenstrukturen", Teubner 1975), in dem er behauptete, dass man Programme schreiben koenne, die auf Datenstrukturen aufbauen, statt es umgekehrt zu machen. Wie jeder Echte Programmierer weiss, gibt es nur eine wirklich nuetzliche Datenstruktur, das Array. Zeichenketten, Listen, Records und Mengen sind allesamt Sonderfaelle von Arrays und koennen auch so behandelt werden, ohne dadurch die Sprache zu verkomplizieren. Das Schlimmste an den ganzen schoenen Typen ist ausserdem, dass man sie deklarieren muss, waehrend Echte Programmiersprachen, wie man weiss, den Type anhand des ersten Buchstabens eines maximal 6 Zeichen langen Bezeichners implizit festlegen. Welches Betriebssystem der Echte Programmierer benutzt? CP/M? Gott bewahre! Das ist doch im Grunde ein Spielzeug-Betriebssystem. Selbst kleine alte Damen und Hauptschueler koennen CP/M benutzen und verstehen. UNIX ist natuerlich schon viel komplizierter - der typische UNIX-Hacker weiss nie, wie das PRINT-Kommando diese Woche heisst - aber wenn man es genau nimmt, ist UNIX auch nur ein verherrlichtes Telespiel. Niemand arbeitet auf UNIX-Systemen an ernstzunehmenden Dingen - man schickt kleine Witzchen ueber USENET rund um die Welt, oder schreibt ein neues Adventure-Spiel oder Forschungsberichte. Nein, der Echte Programmier benutzt OS/370. Ein guter Programmierer kann die Beschreibung des Fehlers IJK305I in seinem JCL (Job Control Language, A.d.Tippers)-Manual finden und verstehen. Ein grossartiger Programmierer kann JCL schreiben, ohne je das Manual zu sehen. Ein wahrhaft ausserordentlich guter Programmierer kann Fehler in einem 6- Megabyte-Hexdump finden, ohne einen Taschenrechner zu benutzen. OS/370 ist wirklich ein bemerkenswertes Betriebssystem. Mit einem einzigen falsch plazierten Leerzeichen kann man die gesamte Arbeit mehrerer Tage zerstoeren, was die Wachsamkeit im Programmierteam ungemein foerdert. Der beste Weg zum System ist der Kartenstanzer. Zwar behaupten einige Leute, es gaebe ein Timesharing-System unter OS/370, aber nach sorgfaeltigen Nachforschungen bin ich zu dem Schluss gekommen, dass sie sich irren. Welche Werkzeuge kann ein Echter Programmierer benutzen? Nun, theoretisch koennte er seine Programme ueber die Maschinenkonsole eingeben und laufen lassen. In den fruehen Tagen der Computerei, als Computer noch Maschinenkonsolen hatten, wurde dies auch gelegentlich getan. Der typische Programmierer wusste den System-Urlader Bit fuer Bit auswendig und tastete ihn ein, sobald er von seinem Programm zerstoert worden war. Damals war Speicher auch noch Speicher - der war nicht einfach leer, wenn der Strom ausfiel. Hauptspeicher von heute hingegen vergessen entweder Dinge, die sie behalten sollen, oder halten Informationen, die schon lange weg sein sollten. Aber zurueck zum Thema. Die Legende sagt, dass Seymour Cray, der Erfinder des Cray-I- Supercomputers und der meisten anderen Rechner von Control Data, selbst das erste Betriebssystem fuer die CDC 7600 an der Maschinenkonsole eingetastet hat, als sie das erste Mal eingeschaltet wurde. Cray ist selbstverstaendlich ein echter Programmierer. Einer der Programmierer, die ich am meisten bewundere, arbeitet als Systemprogrammierer fuer Texas Instruments. Eines Tages erhielt er ein Ferngespraech von einem Benutzer, dessen System mitten in einer wichtigen Arbeit abgestuerzt war. Der Typ reparierte dann den Schaden ueber's Telefon. Er brachte den Benutzer dazu, an der Maschinenkonsole Disk-I/O-Instruktionen einzutasten, Systemtabellen in Hexadezimal zu reparieren und Registerinhalte ueber's Telefon durchzugeben. Die Moral von der Geschichte: Obwohl ein echter Programmierer normalerweise Kartenlocher und Schnelldrucker benutzt, kommt er im Notfall auch mit Maschinenkonsole und Telefon aus. In einigen Firmen besteht die Programmeingabe allerdings nicht mehr aus 10 schlangestehenden Ingenieuren, die auf einen 029-Locher warten. In meiner Firma zum Beispiel steht kein einziger Kartenlocher. Der Echte Programmierer muss in diesem Fall seine Arbeit mit einem Texteditor erledigen. Auf den meisten Rechnern stehen verschiedene Editoren zur Verfuegung, und der Echte Programmierer muss aufpassen, dass er einen erwischt, der seinen persoenlichen Stil wiedergibt. Viele Leute glauben, dass die besten Editoren der Welt im Xerox Palo Alto Research Center geschrieben wurden und auf Alto- und Dorado-Computern laufen. Ungluecklicherweise wuerde jedoch kein Echter Programmierer einen Computer mit einem Betriebssystem benutzen, das Smalltalk (Geplapper, A.d.Ue.) heisst, und sicherlich auch nicht ueber eine Maus mit einem Rechner kommunizieren. Einige Konzepte der Xerox-Editoren sind mittlerweile in Editoren eingeflossen, die unter sinnvoller benannten Betriebssystemen arbeiten, so wie EMACS und VI. Das Problem mit diesen Editoren ist, dass Echte Programmierer das Prinzip "Du kriegst, was du siehst" fuer schlecht halten. Der Echte Programmierer will einen "Du hast es so gewollt, da hast du's"-Editor, einen, der kompliziert ist, kryptisch, leistungsfaehig, gnadenlos und gefaehrlich. TECO, um genau zu sein. Es wurde beobachtet, dass TECO-Kommandofolgen dem Leitungsrauschen aehnlicher sind sind als lesbarem Text. Eins der unterhaltsameren Spiele, die mit TECO moeglich sind, besteht darin, den eigenen Namen als Kommando einzugeben und zu raten, was dann passiert. So ungefaehr jeder moegliche Tippfehler kann dank TECO das gerade editierte Programm zerstoeren, oder schlimmer noch, kann kleine mysterioese Fehler in einstmals funktionierende Unterprogramme einbringen. Aus diesem Grund editieren Echte Programmierer nur sehr widerwillig Programme, die schon fast laufen. Sie finden es viel einfacher, den binaeren Objektcode direkt zu aendern, fuer gewoehnlich mit einem wundervollen Programm, das SUPERZAP heisst (auf Nicht-IBM-Rechnern entsprechend anders). Dies funktioniert so gut, dass viele laufende Programme auf IBM-Systemen keine Aehnlichkeit mit dem urspruenglichen FORTRAN-Quellprogramm haben. In einigen Faellen ist nicht einmal mehr das Quellprogramm vorhanden. Wenn dann der Zeitpunkt gekommen ist, ein Programm zu aendern, wuerde kein Mananger auch nur daran denken, einem geringeren als einem Echten Programmierer diese Arbeit zu uebertragen - kein Muesli-fressender strukturierter Programmierer wuesste auch nur, wo er mit der Arbeit anfangen sollte. Man nennt das Arbeitssicherungsmassnahme. Hier eine Liste der wichtigsten Programmierhilfen, die der Echte Programmierer nicht benutzt: * FORTRAN-Praeprozessoren wie MORTRAN oder RATFOR. Diese Haute Cuisine der Programmierung eignet sich hervorragend, um Muesli zu produzieren. * Quellcodeorientierte Debugger. Echte Programmierer lesen Hexdumps. * Compiler, die Code fuer Array-Indexpruefung zur Laufzeit erzeugen. Sie ersticken jede Kreativitaet, zerstoeren die meisten der interessanteren Anwendungen der EQUIVALENCE-Vereinbarung, und machen Aenderungen des Betriebssystems mittels negativer Indizes unmoeglich. Und, schlimmer noch, solcher Code ist ineffizient. * Programm-Pflege-Systeme. Ein Echter Programmierer haelt seine Software als Kartenstapel unter Verschluss, denn dies zeigt, dass der Besitzer seine wichtigen Programme nicht unbewacht lassen kann. Wo der typische Echte Programmierer arbeitet? Welche Art von Programmen derart talentierter Individuen wuerdig ist? Nun, man kann sicher sein, dass man nie einen Echten Programmierer beim Schreiben von Buchhaltungsprogrammen in COBOL erwischen wird, oder gar beim Sortieren der Abonnentenadressen des SPIEGEL. Nein, ein echter Programmierer braucht Aufgaben von weltbewegender Bedeutung. Echte Programmierer arbeiten fuer das Los Alamos National Laboratory und schreiben dort Atomkriegs-Simulationen auf Cray-I-Supercomputern, oder sie arbeiten bei der National Security Agency und entschluesseln russische Funksprueche. Nur weil tausende Echter Programmierer fuer die NASA gearbeitet haben, waren "unsere Jungs" eher auf dem Mond als die Kosmonauten. Die Computer im Space Shuttle wurden von Echten Programmierern programmiert, und auch die Betriebssysteme der Cruise Missiles der Firma BOEING wurden von diesen echten Professionals entworfen. Einige der ehrfurchtseinfloessendsten Echten Programmierer arbeiten im Jet Propulsion Laboratory in Kalifornien. Viele von ihnen kennen das gesamte Betriebssystem der Pioneer- und Voyager-Sonden auswendig. Mit einer Kombination von grossen, bodengebundenen FORTRAN-Programmen und kleinen, von den Sonden mitgefuehrten Assembler-Programmen vollbringen sie unglaubliche Kunststuecke der Navigation und Improvisation. So treffen sie nur 10 Kilometer grosse Fenster nahe Saturn nach 6 Jahren Flug durch den Weltraum, oder reparieren bzw. umgehen defekte Sensoren, Sender oder Batterien. Angeblich soll es einem Echten Programmierer gelungen sein, in ein paar hundert Byte unbenutzten Speichers innerhalb der Voyager-Sonde ein Mustererkennungsprogramm zu pressen, das einen neuen Mond des Jupiters suchte, fand und fotografierte. Fuer die Galileo-Sonde ist vorgesehen, dass sie auf ihrem Weg zum Jupiter entlang einer schwerkraftgelenkten Bahn am Mars vorbeizieht. Diese Bahn fuehrt in einer Entfernung von 80 +/- 3 km an der Marsoberflaeche vorbei. Kein Mensch wuerde diese Art der Navigation einem Pascal-Programm oder gar -Programmierer anvertrauen. Viele der Echten Programmierer dieser Welt arbeiten fuer die amerikanische Regierung, meist fuer das Verteidigungsministerium. So soll es sein. In letzter Zeit erscheinen dunkle Wolken am Horizont der Echten Programmierer. Es scheint, als haetten einige einflussreiche Muesli-Fresser im Verteidigungsministerium entschieden, dass in Zukunft alle Verteidigungsprogramme in so einer Art von grosser, vereinheitlichter Programmiersprache namens ADA geschrieben werden muessten. Lange Zeit schien es, als laege ADA's Bestimmung im Verstoss gegen alle Regeln der Echten Programmierung. Es ist eine Sprache mit Strukturen, Datentypen, strenger Typbindung und Semikolons. Kurz, sie ist wie geschaffen, um die Kreativitaet des typischen Echten Programmierers zu verkrueppeln. Gluecklicherweise hat die jetzt vom DoD (Department of Defense, A.d.Tippers) ausgewaehlte Sprache noch genuegend interessante Eigenschaften, um dem Echten Programmierer eine Annaeherung zu ermoeglichen: Sie ist unglaublich komplex, sie enthaelt Moeglichkeiten, um mit dem Betriebssystem herumzumachen, und Edgar Dijkstra mag sie nicht. Dijkstra ist, wie man wissen sollte, der Autor von "GOTOs Considered Harmful", einem Meilenstein der Programmiermethodologie, der von Pascal-Programmierern und Muesli-Fressern gleichermassen bewundert wird. Und ausserdem, ein zu allem entschlossener Echter Programmierer kann in jeder Sprache FORTRAN-Programme schreiben. Der Echte Programmierer kann allerdings auch Kompromisse in Bezug auf seine Prinzipien eingehen und an etwas geringeren Aufgaben als der Vernichtung des Lebens arbeiten, sofern er dafuer entsprechend bezahlt wird. Viele Echte Programmierer schreiben z.B. Telespiele fuer Atari, allerdings spielen sie nicht damit. Ein Echter Programmierer weiss, wie er die Maschine jedesmal schlagen kann, und damit ist es keine Herausforderung mehr. Jeder bei Lucas-Film ist ein Echter Programmierer, denn es waere doch verrueckt, das Geld von 50 Millionen Star-Wars-Fans auszuschlagen. Der Anteil der Echten Programmierer im Bereich der Computer Graphics ist etwas niedriger als anderswo, was wahrscheinlich daran liegt, dass noch niemand irgendeinen Nutzen der Computer Graphic entdeckt hat. Andererseits werden Computer Graphics vornehmlich in FORTRAN abgehandelt, daher gibt es einige Leute, die so das Schreiben von COBOL-Programmen vermeiden. Im Allgemeinen spielt der Echte Programmierer, wie er arbeitet - mit Computern. Er ist staendig darueber erheitert, dass sein Arbeitgeber ihn tatsaechlich fuer etwas bezahlt, was er nur so zum Spass ebenso tun wuerde - allerdings achtet er darauf, diese Meinung nicht zu laut zu aeussern. Gelegentlich kommt der Echte Programmierer auch aus seinem Buero heraus, um sich ein wenig frische Luft und ein oder zwei Bierchen zu genehmigen. Hier daher einige Hinweise, wie man den Echten Programmierer ausserhalb des Computerraums erkennt: * Auf Parties stehen Echte Programmierer in einer Ecke und diskutieren ueber Sicherheitsmechanismen von Betriebssystemen und wie man darum herumprogrammiert. * Bei Fussballspielen vergleicht der Echte Programmierer die Ergebnisse mit seinen auf gruenliniertem Leporello-Papier gedruckten Computer-Simulationsergebnissen. * Am Strand zeichnet der Echte Programmierer Flussdiagramme in den Sand. * Ein Echter Programmierer geht in die Disco, um sich die Lichtorgel anzusehen. * Bei Begraebnissen sagt der Echte Programmierer typischerweise "Armer Hans-Helmut. Er war mit seinem Sortierprogramm schon fast fertig, als ihn der Herzinfarkt erwischt hat". * Im Supermarkt besteht der Echte Programmierer darauf, seine Bierdosen selber ueber das Fenster des Strichcodelesers zu schieben, weil er keinem Kassierer zutraut, dies beim ersten Versuch richtig zu machen. In welcher Umgebung der Echte Programmierer am besten funktioniert? Nun, dies ist eine sehr wichtige Frage fuer die Manager von Echten Programmierern. Wenn man bedenkt, wie teuer es ist, einen von ihnen in Betrieb zu halten, dann sollte man ihn oder sie in eine optimale Arbeitsumgebung versetzen. Der typische Echte Programmierer lebt vor einem Computerterminal. Rund um dieses Terminal liegen Ausdrucke von jedem Programm, an dem er je gearbeitet hat, sie stapeln sich grob chronologisch geordnet auf jeder ebenen Flaeche des Bueros. Im Zimmer verteilt finden sich ueber ein Dutzend mit kaltem Kaffee mehr oder minder gefuellte Tassen. Gelegentlich schwimmen Zigarettenkippen darin herum, in einigen Faellen auch Reste von Orangenschalen. Irgendwo liegen Kopien des OS JCL Manuals und der "Principles of Operation" an einer besonders interessanten Stelle aufgeschlagen herum, ausser bei extrem guten Leuten. An der Wand klebt ein Schnelldrucker-Kalender mit Snoopy drauf aus dem Jahre 1969. Ueber den Boden verteilt liegen Reste der Verpackungen von gefuellten Keksen (der Typ, der schon in der Fabrik so furztrocken gebacken wird, dass er auch bei laengerem Liegen im Automaten nicht schlechter wird). Schliesslich, in der linken, oberen Schublade des Schreibtischs, unter der Schachtel mit den Muntermachern, liegt eine Schablone fuer Flussdiagramme, die sein Vorgaenger dort vergessen hat. Echte Programmierer schreiben Programme und keine Dokumentation, das ueberlaesst man den Typen von der Wartung. Der Echte Programmierer ist in der Lage, 30, 40, ja sogar 50 Stunden in einem Rutsch zu arbeiten, und das unter hohem Zeitdruck. Genaugenommen mag er es so am liebsten. Schlechte Antwortzeiten regen den Echte Programmierer nicht auf - sie geben ihm eine Chance, zwischen zwei Kommandos ein bisschen Schlaf zu ergattern. Wenn die Planung nicht genuegend Zeitdruck bereithaelt, dann tendiert der Echte Programmierer dazu, seine Arbeit herausfordernder zu machen, indem er sich die ersten neun Wochen mit einem kleinen, aber sehr interessanten Teil des Problems befasst, um dann in der letzten Woche seine Aufgabe in zwei oder drei 50-Stunden-Marathonsitzungen zu beenden. Dies beeindruckt nicht nur den Manager, sondern schafft gleichzeitig eine hervorragende Entschuldigung fuer das Fehlen der Dokumentation. Und ueberhaupt: Kein Echter Programmierer arbeitet von 9 bis 5, ausser denen von der Nachtschicht. Echte Programmierer tragen keine Schlipse. Echte Programmierer tragen keine hochhackigen Schuhe. Echte Programmierer kommen zur Arbeit, wenn andere zum Mittagessen gehen. Ein Echter Programmierer vergisst vielleicht den Vornamen seiner Angetrauten, aber niemals den Inhalt der gesamten ASCII- (bzw. EBCDIC-) Tabelle. Echte Programmierer koennen nicht kochen. Da Supermaerkte um 3 Uhr morgens selten geoeffnet haben, muessen sie sowieso von Kaffee und Keksen leben. Die Zukunft betrachtend machen sich eine Reihe von Echten Programmierern Sorgen, dass die juengste Programmierergeneration nicht mehr mit der gleichen Lebensperspektive aufwaechst wie sie selbst. Viele der Juengeren haben noch nie einen Computer mit Maschinenkonsole gesehen. Kaum ein Schulabgaenger kann heute noch hexadezimal rechnen, ohne einen Taschenrechner zu benutzen. Die Studenten von heute sind weich - geschuetzt vor den Realitaeten der Programmierung durch symbolische Debugger, Texteditoren, die Klammern zaehlen, und benutzerfreundliche Betriebssysteme. Und das schlimmste ist, einige dieser angeblichen Computer-Spezialisten kommen zu Rang und Namen, ohne je FORTRAN zu lernen! Sind wir dazu verdammt, eine Industrie von UNIX- Hackern und Pascal-Programmierern zu werden? Nun, aus meiner Erfahrung heraus glaube ich, behaupten zu duerfen, dass das Schicksal den Echten Programmierern wohlgesonnen ist. Weder OS/370 noch FORTRAN zeigen irgendwelche Symptome des Aussterbens, trotz aller Anstrengungen der Pascal-Programmierer. Selbst subtilere Tricks wie das Hinzufuegen strukturierter Schleifen zu FORTRAN sind fehlgeschlagen. Sicher, einige Computerhersteller liefern FORTRAN-77-Compiler, aber jeder einzelne von ihnen laesst sich ueber eine einzige Compiler-Option in einen FORTRAN-66-Compiler verwandeln - mit DO-Schleifen, wie von Gott geschaffen. Selbst UNIX scheint fuer den Echte Programmierer nicht mehr so schlecht zu sein wie frueher. Die neueste UNIX-Version hat das Potential eines Betriebssystems, das eines Echten Programmierers wuerdig ist. Sie hat zwei verschiedene, leicht inkompatible Benutzerschnittstellen, einen geheimnisvollen und komplizierten Teletype-Treiber und virtuellen Speicher. Und wenn der Echte Programmierer die Strukturierung ignoriert, kann er sich sogar mit C anfreunden. Schliesslich gibt es keine Typenbindung, Bezeichner sind sieben (Zehn? Acht?) Zeichen lang, und man hat Zeiger als Bonus. Das ist, als haette man die besten Teile von FORTRAN und Assembler vereinigt, von den kreativeren Moeglichkeiten des #define ganz zu schweigen. Nein, die Zukunft ist nicht voellig schlecht. So hat sich in den vergangenen Jahren die populaere Presse sogar ueber die clevere neue Brut von Computer-Schraten und -Hackern geaeussert, die Plaetze wie Stanford und MIT zugunsten der Wirklichkeit verlassen haben. Allen Anzeichen nach lebt der Geist der Echten Programmierung weiter in diesen jungen Maennern und Frauen. Und solange es schlecht beschriebene Ziele, bizarre Fehler und unrealistische Zeitplaene gibt, solange wird es Echte Programmierer geben, die bereit sind, einzuspringen und das Problem zu loesen, und die sich die Dokumentation fuer spaeter aufheben. Lang lebe FORTRAN! |
|
|