Ist (höhere) Mathematik wirklich SO wichtig fürs Programmieren?

SierraX

Well-Known Member
Auch wenn es schon etwa 13 oder 14 Jahre her ist, klingt mir das nachfolgende Zitat eines Berufsschullehrers für die FiAe der Nachbarklasse in den Ohren...
"Wie wollen sie programmieren lernen, wenn sie nicht mal die Mitternachtsformel kennen?"

Wie schon erwähnt sind seit dem viele Jahre ins Land gegangen. Auch mit Aussagen wie "Selber programmieren oder scripten werdet ihr FiSi's eh nie brauchen"

Gut... aus mir ist kein Programmierer geworden, der eine Applikation von A-Z für den Verkauf entwickeln musste. Aber ich hab sehr wohl schon Programme geschrieben die dauerhaft eingesetzt werden und weit über ein "Hallo Welt" hinaus gehen.

Jetzt hatte ich als Seiteneinsteiger "nur" einen Hauptschulabschluss und eine Berufsausbildung zum Bürokaufmann also Vorraussetzungen die ja nicht weit über die Grundrechenarten und den 3-Satz hinaus gingen.

Sachen wie scripten und programmieren musste ich mir bisher also selbst anlesen, ausprobieren etc. was durch die fehlenden mathematischen Grundlagen vielleicht manchmal etwas länger dauert. Die Aussage "Selber programmieren oder scripten werdet ihr FiSi's eh nie brauchen" wird mit Wandlung der klassischen Systemadministration zu DevOps immer unwahrer (wobei ich das eh noch nie glauben wollte).

Es stellt sich aber für mich immer mehr die Frage braucht man heute noch die (nennen ich es mal) Gymnasial Mathematik um wirklich programmieren zu lernen? Hat man sie jemals seit den 90ern dafür gebraucht?
 
Ich sage mal so: Es kommt drauf an, was man entwickelt. Für den normalen Wald- und Wiesencode, der sicher über 95% aller dort draußen geschriebenen Codezeilen ausmacht, reichen die 4 Grundrechenarten - und wenn man gut sein will dazu noch Modulo - vollkommen aus. Dort sind andere Dinge wichtiger. Beispielsweise ein "Gefühl" für Algorithmen und Datenstrukturen, Kenntnis gängiger Design Pattern und Best Practices in Sachen Programmarchitektur. Mathematisch fit muss man lediglich für einen kleinen Teilbereich sein, wo wirklich gerechnet wird. Datenauswertungen, Datentransformationen wie Audio- und Video-Codecs oder auch Kompressionsalgorithmen. 3D-Grafik. Um mal drei Punkte herauszupicken. Und da sind wir dann ganz schnell bei Bibliotheken. Du wirst sehr wahrscheinlich keinen Audiocodec entwickeln, stattdessen libvorbis oder libopus nehmen. Du wirst auch kein Kompressionsverfahren bauen, schließlich gibt es zlib und gefühlt 25 Alternativen. Kurz gesagt, jemand hat die Arbeit gemacht und du greifst darauf zurück, ohne selbst das notwendige mathematische und technische Verständnis haben zu müssen. Daher ist unter dem Strich meine Meinung, dass die Behauptung man müsse zum Programmieren ein gutes mathematisches Verständnis haben einfach falsch.
 
Es kann nie schaden aber ich sehe es sonst so wie Yamagi. Mathe ist nett und an sehr, sehr vielen Stellen hilfreich aber im Normalfall kommt man auch gut ohne aus. Irgendjemand hat sich im Normalfall schon mal eines Problems angenommen und das sollte man auch nutzen.

Hat man noch nie von der Modulooperation gehört, dann kommt man auch nicht auf die Idee diese einzusetzen - man kann es aber auch anders lösen. Das Wissen um die Mathematik ermöglicht manchmal sehr elegante Lösungen, die auch wirklich immer funktionieren.

Aber ich würde mir keinen Kopf deswegen machen... Einzelne Sachen kann man auch immer noch mal nachgucken.
 
Ich warte bis heute vergebens darauf, dass mich mal eine Programmiersprache nach der Taylorreihe fragt, vielleicht schlägt dann meine große Stunde. Bis dahin würde ich die Eingangsfrage einfach mal pauschal verneinen.
 
Ich beschäftige mich ja mit Sprachen, nicht nur mit Programmiersprachen, die sind nur ein besonderer Fall davon. Man kann Mathematik als eine abstrakte Sprache betrachten die es durch rigide Regeln möglich macht bestimmte Zusammenhänge zu beweisen und wichtiger noch, neue, noch unbekannte Zusammenhänge herauszufinden. Programmiersprachen sind sehr viel lockerer und auch unterschiedlich formuliert da sie andere Zwecke verfolgen. Mathe braucht man also insbesondere da wo es um Beweise geht und darum neue Zusammenhänge zu erforschen. Programmieren ist also eine recht andere Disziplin und Mathe spielt nur in wenigen Bereichen eine Rolle was nicht heißt das man es nicht dennoch an der einen oder anderen Stelle gebrauchen kann. Ich würde zu den von Yamagi genannte noch Kryptographie hinzuzählen.
 
Kryptographie, 3D-Grafik, Audio, Video, Datenkompression, Machine Learning - es gibt sehr viele Bereiche, in denen man ohne Mathe nichts wird. Jedoch sind es, wie schon gesagt, sehr spezielle Bereiche, in die der 0815-Anwendungsprogrammierer wohl her nur mal reinschnuppert und nicht sein täglich Brot.

Aber du kannst trotzdem in allen Bereichen programmieren, weil es eben Bibliotheken gibt.
 
Bibliotheken die ganze Arbeit machen zu lassen nennt sich Programmieren? Auweia.
 
Gern, aber mir fehlt die Zeit.

Du hast eben noch erklärt, es gebe Bibliotheken, und damit meintest du mit ziemlicher Sicherheit ungefähr das Gleiche wie ich: Code, den man nicht selbst schreiben muss, sondern einfach irgendwas Fertiges "einbinden" und "nutzen". Das ist dann aber Zusammenkopieren und kein Programmieren.
 
Ich ein solcher Lehrer für FIAE. :)

Mathematik spielt sicherlich eine Rolle - sekundär etwa dann, wenn es um Präzision und formale Beschreibungen geht. Die konkreten mathematischen Werkzeuge der Programmierer liegen aber meist in der Linearen Algebra, die in der Schule - zumindest in der Oberstufe - weniger dran kommt. zuglufttier hat schon eine gute Liste mit Bereichen erstellt.

Ich würde noch ergänzen wollen, dass die Verwendung von Bibliotheken durchaus mathematisches Verständnis erfordert, wenn es um Laufzeiten oder Speicherbedarf geht. Dann muss ich wissen, ob ich den Algorithmus A mit liearer Laufzeit und quadratischem Speicher dem Algorithmus B mit logarithmischem Speicherbedarf und polynomieller Laufzeit vorziehen möchte oder nicht.

Ebenso sollte ich Laufzeiten von eigenen Algorithmen abschätzen können: Eine Schleife über ein Array der Länge n gegenüber zweier geschachtelter Schleifen jeweils über ein Arrays der Länge n/2.
 
Wer zusammenkopiert und das Ziel erreicht, ist ein guter Programmierer. Wer alles selber programmiert und das Ziel verfehlt, ist ein schlechter Programmierer.

Irgendwo dazwischen liegt die Wahrheit ;)

Aber zurück zum Thema: Das wurde auch ausreichend beleuchtet, glaube ich. Mathe kann nie schaden, es ist aber nicht zwingend notwendig.
 
Ein gewisses Grundverständnis in der Mathematik hilft schon ungemein. Dabei geht es aber weniger darum, dass ich alle Schul-Formeln der Mathematik aus dem Kopf aufsagen kann. Es geht mehr darum, dass ich ein reelles Problem auf ein bereits gelöstes mathematisches Problem abbilden kann und somit gedanklich nur noch "glue-code" überlegen muss. Als Beispiel mal ein Problem in eine Matrix überführen und dann optimierte Matrix-Multiplikation drüber laufen lassen, statt mit verschachtelten Schleifen und vielen "if" zu arbeiten.

Ein "unfähiger" Programmierer würde sich halt selbst Gedanken machen und es alles selbst "erforschen" und dabei ggf. eine weniger gute Lösung finden. Aber Lösung ist Lösung, auch wenn Zeit und Performance dann schlechter sind.

Wenn ich mein Problem aber mit einer bereits geschriebenen, getesteten und sich breit im Einsatz befindlichen Bibliothek erledigen kann, dann sollte man diese auch nutzen. Das "Not-Invented-Here" Syndrom hat schon so das ein oder andere Projekt in den Abgrund gerissen. Auch ist niemand ein Universal-Genie und hat auch Zeit sich in sämtliche Kernthemen einzuarbeiten. Gerade im Bereich Kryptographie gibt es so viele Themen und Randfälle, alleine dort alles zu verstehen und gut umzusetzen ist quasi unmöglich. Man übersieht immer etwas.
 
"Not Invented Here" hat allerdings auch den Erfolg von Apple und Microsoft und nicht zuletzt die freien BSDs nach NetBSD überhaupt erst möglich gemacht. Immerhin gibt es immer etwas, was etwas besser (natürlich subjektiv) funktionieren könnte als die bestehenden Lösungen.

Gerade in C++ ist mir das schon aufgefallen: Es gibt eine Vielzahl an Bibliotheken für jeden Mist - und jede von ihnen macht etwas anderes anders als ich das gern hätte. Tja.
 
Es ist aber ein Unterschied, ob eine bestehende Lösung mein Problem komplett lösen würde und ich sie trotzdem nicht nehme, oder ob mein Problem mit der Lösung nicht lösbar ist und ich deshalb etwas neues schreiben muss.
 
Bestehende "Lösungen" lösen die wenigsten meiner Probleme, um irgendwas muss ich immer herumprogrammieren. Das wäre manchmal tatsächlich aufwändiger als einfach alles neu zu schreiben.

Und nur, weil etwas mein Problem lösen würde, wäre das noch lange kein Grund, es auch zu nutzen. Erinnerst du dich an die npm-Geschichte? Ich lache immer noch.
 
Man muss nicht den übelsten Ranz aus der Programmierwelt ausbuddeln, um gegen Bibliotheken zu wettern ;) Ich rede von richtigen Bibliotheken für Kryptographie, Parsing und Netzkommunikation und nicht von "Helper-Functions"...

Oder warum genau sollte ich SSL und Co. noch mal selbst implementieren? Oder warum sollte ich einen XML-Parser noch mal schreiben? Es wäre ziemlich vermessen zu behaupten man selbst könne alles besser machen als die bestehenden Lösungen, wo meist deutlich mehr Augen und KnowHow draufschauen.
 
Ich möchte noch den neuen Gedanken einbringen, dass insbesondere funktionale Sprachen und rekursive Algorithmen sicher ein tieferes mathematisches Verständnis begrüßen. Sprachen wie Elixir oder Erlang können sicher in ihrer Verwendung von mathematischen Vorkentnissen enorm profitieren. :)
 
Ah, das legendäre Viele-Augen-Prinzip, das bei z.B. Linuxianern ja auch so prima funktioniert. Wenn tausend Leute die gleichen fünf Prozent des Quellcodes lesen, können 95 Prozent des Quellcodes aber trotzdem noch übelster Ranz (prima Wort, das klau' ich jetzt häufiger) sein. Und leider sind diese 95 Prozent das auch oft genug.

Du solltest SSL "und Co." nicht selbst implementieren, ich kann nur empfehlen, nur dann auf externe Bibliotheken zurückzugreifen, wenn unbedingt nötig. Wohlgemerkt: "Extern" ist, was nicht Teil der Standardbibliothek ist.

Um beim Beispiel C++ zu bleiben: Ich wäre schön doof, z.B. std::filesystem selbst zu implementieren. Trotzdem gibt es immer noch etliche (auch neue) Bibliotheken, die auf boost::filesystem zurückgreifen, um ein Problem zu lösen, wodurch man gleich einen ganzen Rattenschwanz an Abhängigkeiten von diesem Boost-Klotz mitnehmen muss. So was zum Beispiel ist ein Grund, die entsprechende Bibliothek selbst zu schreiben: Kleinhalten von Komplexität (und damit Fehlerquellen).
 
Sprachen wie Elixir oder Erlang können sicher in ihrer Verwendung von mathematischen Vorkentnissen enorm profitieren.
Warum gerade Elixier und Erlang. Was ein Prozess ist, ist ja nicht so schwer zu verstehen. Und gerade Erlang/OTP ist m.E. eher eine auf praktische Anwendungen orientiertes Sprache. Aber sagen wir es mal so: In funktionalen Sprachen, und da denke ich eher an Haskel & Co, kann man mathematische Sachverhalte vermutlich leichter implementieren.
 
@CrimsonKing

Die C/C++ Standardbibliothek enthält trotzdem kein SSL, keinen XML-Parser, keine Lokalisierungsgeschichte wie ICU und vieles andere nicht. Entsprechend _muss_ ich Bibliotheken benutzen die nicht im Standard sind.

Mag ja sein, dass du nur 10-Zeiler meinst, aber dann erwähne das auch, aber bezeichne die Nutzung von Bibliotheken nicht als "kein Programmieren" ;)
 
Warum gerade Elixier und Erlang. Was ein Prozess ist, ist ja nicht so schwer zu verstehen. Und gerade Erlang/OTP ist m.E. eher eine auf praktische Anwendungen orientiertes Sprache. Aber sagen wir es mal so: In funktionalen Sprachen, und da denke ich eher an Haskel & Co, kann man mathematische Sachverhalte vermutlich leichter implementieren.

Erlang und Elixir sind funktionale Sprache, daher hatte ich sie genannt. Haskell ist sicher auch ein gutes Beispiel mit vielleicht nicht ganz so großer Verbreitung. :)


PS
Ich kann die Sub-Diskussion zu Bibliotheken immer noch nicht ganz dem Thread-Thema zuordnen. ;)
 
Ich möchte noch den neuen Gedanken einbringen, dass insbesondere funktionale Sprachen und rekursive Algorithmen sicher ein tieferes mathematisches Verständnis begrüßen. Sprachen wie Elixir oder Erlang können sicher in ihrer Verwendung von mathematischen Vorkentnissen enorm profitieren. :)

Gut, gerade funktionale Programmiersprachen basieren auf mathematischen Modellen, entsprechend ist dort ein Verständnis von der Mathe dahinter vom Vorteil ;)
 
Zurück
Oben