Coding Nerd Talk (Funktionale Sprachen etc)

    Reply to Holzfaellen



    1. Math. Funktionen


    Haha, ja ich denke im 3. semester sollte man "irgendwann" verstanden haben was eine funktion ist :D


    Gerne können wir über funktionale sprachen reden, da hab ich nämlich eher noch nicht mit gearbeitet und ich weiss nicht, inwieweit mein verständnis davon von mir erdacht ist,

    oder durch externe referenzen verifiziert ist. (ist vermutlich ein typisches Entwicklerproblem :p )


    Nachdem ich kein Mathematiker bin, erfasse ich die operationen die man mit funktionen machen kann vielleicht anders. Aber es ist doch schon so, dass

    man jede gegebene math. funktion in einer prozeduralen methode programmieren kann?


    f(X) = a^2 + b2 + 2ab


    ist son ding, womit wir uns sehr intensiv beschäftigt haben irgendwann vor langer langer zeit; mir ist der unterschied zwischen math. funktionen und oop methoden schon klar.


    2. Prozedurale und funktionale sprachen


    das klassiche


    x = x + 1;


    das wohl jedem natur-mathematiker das blanke entsetzen in die augen treibt, sollte es bei funktionalen programmiersprachen nicht geben?


    Und ich versuche in meinem code weitestgehend, doppelte variablenverwendung wie o.g. x=x+1 zu vermeiden. Auch Schleifen usw. ersetze ich lieber durch sprachintegrierte abfragen (z.b. ms linq)

    Das hat sich einfach so als "good practice" erwiesen für mich, ich meine aber mal zu dem schluss gekommen zu sein, dass sich damit der code besser in funktionale sprachen portieren lässt.


    so sachen wie if abfragen unterliegen ja anderen regeln, soweit ich weiss, aber so tief stecke ich da gar nicht (mehr) drin.


    3. Eine verwegene Idee?


    Vermutlich gibt es in aktuellen programmiersprachen (noch?) keine mechanismen um integrale zu bilden oder gleichungen auf eine besteimmte variable aufzulösen (kommt vl noch?).

    Also quasi die Operationen auf math. funktionen anzuwenden, die ein mathematiker tätigt.


    Z.b. ich definiere eine Formel einmal als funktionalen code, brauche mir aber selber als entwickler keine gedanken drum machen, wie ich die formel umstellen muss,

    um nach einer bestimmten variable aufzulösen.

    Das ergibt nämlich in der klassichen programmierung gerne redundanzen, was wiederrum bei änderung der formel fehler erzeugt, wenn

    bestimmte auflösungen nicht angepasst werden.

    Das könnte schon mal jemand erfinden...


    4. MetaPhysik und Meta Ebene


    MetaPhysik ist ein ziemlich abstrakter begriff, den kant begründet hat. Als Informatiker spricht man von der Meta Ebene, z.b. wenn es um Daten geht, die Struktur von Daten (ggf. formalisiert) beschreiben.

    Klassisch tauchen metadaten oft in mensch-gelesenen Spezifikationen auf. Irgendwann hat man aber auch die meta ebene formalisiert wie zb. in form von XML-Schemas.


    5. OOP


    Ich weiss nicht, ob du da aus meiner Bemühung was rausziehen konntest, einige grundsätze der oop zu vermitteln.

    Dazu ggf. später mehr.

    Mir war aber nicht klar, dass du schon 3 Jahre mathe machst,

    hatte erst den eindruck du bist grad in der findungsphase, was das richtige für dich ist.

    (Hatte den eindruck aus irgendeinem anderen thread, vl verwechsle ich dich auch)

    Zitat von SeeBee

    Aber es ist doch schon so, dass

    man jede gegebene math. funktion in einer prozeduralen methode programmieren kann?

    Ne da kriegt man ganz schnell Probleme. Alleine die Realität gibt einem da grenzen. In der Informatik kann man ja nur endliche Mengen haben. Also die ganzen Zahlen (Alle Positiven und Negativen Zahlen ohne Komma) sind ja schon unendlich groß und dafür reicht der Speicher Platz nicht.


    Wenn man sich jetzt einfach nur auf Turing Maschinen Konzentriert, dann hat man das Problem jetzt nicht aber vielleicht sagt die das Halte Problem was? Also das ein Computer nicht sagen kann ob der Algorithmus irgendwann abricht oder unendlich lange weiter läuft. Daraus kann man auch eine Funktion definieren die man nicht Programmieren kann, weil es sonnst dem Halte Problem widersprechen würde.


    Und weiter, in der Mathematik beschäftigt man sich ja auch nicht nur mit der Menge der Zahlen sondern es gibt deutlich größere Mengen. Zum Beispiel die Menge aller Polynome zum Beispiel. Oder die Menge der Funktionen auf der Menge aller Polynome. Das kann man ja immer so weiter machen. Das wird schwierig das zu Programmieren.


    Es gibt auch Funktionen die man gar nicht angeben kann. Vielleicht sagt dir das Auswahlaxiom was? Das Auswahlaxiom Postuliert eine bestimmte art von Funktion und man kann zeigen das man diese art von Funktionen im allgemeinen nicht durch eine Konstruktion angeben kann. Da können sehr schnell Sachen schief gehen, wenn man nicht genau aufpasst. Daher kommt auch das Banach Tarski Paradox, was besagt das man nur durch Zerschneiden und Drehung der Einzelteile, aus einer Kugel zwei kriegen kann: https://de.wikipedia.org/wiki/Banach-Tarski-Paradoxon

    Zitat von SeeBee

    Und ich versuche in meinem code weitestgehend, doppelte variablenverwendung wie o.g. x=x+1 zu vermeiden. Auch Schleifen usw. ersetze ich lieber durch sprachintegrierte abfragen (z.b. ms linq)

    Das hat sich einfach so als "good practice" erwiesen für mich, ich meine aber mal zu dem schluss gekommen zu sein, dass sich damit der code besser in funktionale sprachen portieren lässt.

    Interessant. Immer wenn ich Programmiere ist mir sowas immer egal. Aber ich Programmiere ja natürlich auch nicht so große Projekte wie du, da behält man ja so oder so leicht den überblick. Bei Haskell, was ich immer ganz cool fand ist das es da überhaupt keine while Schleifen gibt sondern man alles über rekursives aufrufen der Funktionen machen muss. Haskell ist aber trotzdem Turing complete. Also insgesamt würde ich schon sagen das ich mit Haskell den meisten Spaß beim Programmieren hatte.

    Zitat von SeeBee

    3. Eine verwegene Idee?

    Hm, kennst du Wolfram Alpha? Vielleicht ist das ja schon das was du meinst?

    Wolfram|Alpha: Making the world’s knowledge computable
    Wolfram|Alpha brings expert-level knowledge and capabilities to the broadest possible range of people—spanning all professions and education levels.
    www.wolframalpha.com

    Es geht natürlich da nicht alles. So oder so ist Integrieren ein sehr Schwieriges Problem für das es nicht immer eine Antwort gibt und mit vielen Trickserein. Das ist auch nichts womit ich viel zu tun hab. Aber ein paar einfachere und vielleicht auch schwerere Integrale kriegt wolfram Alpha schon hin.


    Was ich Persönlich noch sehr interessant finde, bezüglich diesen Mathe Programmen ist Lean.

    https://en.wikipedia.org/wiki/Lean_(proof_assistant)

    Das ist aber wahrscheinlich eher für die reinen Mathematiker Interessant da es dort Primär darum geht Beweise zu verifizieren und zu formalisieren.

    Zitat von SeeBee

    Ich weiss nicht, ob du da aus meiner Bemühung was rausziehen konntest, einige grundsätze der oop zu vermitteln.

    Dazu ggf. später mehr.

    Ein bisschen OOP kannte ich schon. Vor allem mit Python hab ich schon ein bisschen rum gespielt, da mich vor dem Studium vor allem Neuronale Netze interessiert hat und damit hab ich ein bisschen experimentiert. Aber in diesem Semester muss ich ein paar Sachen mit Java machen. Kann also sein das ich vielleicht mal deine Hilfe brauchen :P.

    Zitat von Holzfaellen

    Wenn man sich jetzt einfach nur auf Turing Maschinen Konzentriert, dann hat man das Problem jetzt nicht aber vielleicht sagt die das Halte Problem was? Also das ein Computer nicht sagen kann ob der Algorithmus irgendwann abricht oder unendlich lange weiter läuft. Daraus kann man auch eine Funktion definieren die man nicht Programmieren kann, weil es sonnst dem Halte Problem widersprechen würde.

    Das versteh ich noch ^^


    Hm. Scheins aber nur zur hälfte. Ist es nicht so, dass man zwar mathematisch eine Funktion definiert, die für unendliche mengen anwendbar ist, aber dann, wenn es zur ausführung kommt, dann "nur" die grenzwerte benennen muss?


    Ich meine z.b. f(x) = x^2 gilt ja auch für die gesamte (undendliche) Menge der ?reelen? Zahlen. Zur ausführung, wenn man das z.b. plotten will, muss man aber die Menge der zahlen kennen, die man für x einsetzt.


    Oder denk ich da jetzt zu einfach? Gib doch mal ein beispiel für so eine nicht programmierbare funktion.


    Ich meine, in dem moment wo eine funktion nicht abbricht, kann sie keinen wert zurückgeben, was doch der essentielle sinn auch einer mathematischen funktion ist?


    Deshalb verwirrt mich das jetzt etwas :p


    Du musst jetzt sehr viel Geduld haben, denn ich habe mich (Abgesehen vl. von imaginären zahlen) nie mit höherer mathematik beschäftigt. Irgendwann nach integralen und matrizenrechnung war bei mir die schule aus XD Abgesehen davon fehlt mir die Basis (siehe letzte Frage)


    Zitat von Holzfaellen

    keine while Schleifen gibt sondern man alles über rekursives aufrufen der Funktionen machen muss

    Das kann aber auch reltiv resourcen intensiv werden (Stack) - oder aufwendig zu programmieren. je nachdem wie man programmiert. Denn mit einer schleife hat man nur eine einzige varible auf dem stack, bei einer rekursion mit der tiefe x werden alle lokalen variablen x mal auf den stack gelegt. Dann müsste man ggf anfangen, mit (funktor)-objekten oder globalen variablen zu arbeiten, um das zu vermeiden. Ein Funktor objekt bildet im wesentlichen eine Funktion an. In C++ könnten man schreiben:


    class Functor;

    // (Klassendefinition folgt hier)

    Functor f(environ); // deklaration des funktors.

    f(); // aufrufen der funktion.


    In c# und glaub auch java kann man das einfacher mit s.g. anonymen delegaten oder anonymen funktionen bewerkstelligen.


    Ich denke aber, es gibt ganz klar einen unterschied zwischen - ich nenns mal "mathematische kern routinen" und "domänenspezifschen anwendugs- und verwaltungscode". Bei ersterem brütet ein guter Mathematiker vl. mal 2 Wochen über einer einzigen Formel, die dann zu wenigen zeilen code führen. oop code schreibt man schon mal mehrere tausend zeilen in wenigen stunden.


    Wenn die funktion in o.g. beispiel sauber isoliert wäre, würden dann wohl nur wirklich erforderliche variablen auf dem stack der rekursiven funktion liegen. Im domänencode geht es da halt meist etwas chaotischer zu...


    Ich denke, in einem Unternehmen, in dem OO-Spezialisten und Mathematiker gut zusammenarbeiten können und ihre domäne kennen, läuft das wesentlich besser. Denn meist sind Mathematiker die, die von der Materie mehr anwendungs domäne mehr ahnung haben, aber die OO Leute sind die, die das Programm in seinem Umfang besser zusammenhalten können. Wer da jetzt wo auf wen hören muss ist gar nicht so einfach abbildbar. Oftmals ist halt der Mathematiker der Projektleiter und bremst den OOler dann aus, weil er immer den hut aufbehalten möchte.


    Zitat von Holzfaellen

    Ein bisschen OOP kannte ich schon. Vor allem mit Python hab ich schon ein bisschen rum gespielt, da mich vor dem Studium vor allem Neuronale Netze interessiert hat und damit hab ich ein bisschen experimentiert. Aber in diesem Semester muss ich ein paar Sachen mit Java machen. Kann also sein das ich vielleicht mal deine Hilfe brauchen :P.

    Gerne.


    Zunächst mal: Python ist in der Art und weise wie man objekte definiert vergleichsweise umständlich.

    Außerdem ist das OO-Model (weil es eine dynamische sprache ist) nur schwer aus dem Quellcode ersichtlich.

    Das macht es eigentlich unmöglich, in python auch nur mittelgrosse programme sinnvoll zu warten.

    Python Mit (teilweise) OO verwende ich für testscripts und co.

    Sogar einen IO-Treiber für IOT haben wir (notgedrungen, auf die schnelle) mit Python geschrieben.

    Aber als ernstzunehmende Sprache für OO-Apps würde ich dringend von solchen scriptsprachen abraten.


    OO lernen sollte man imo zumindest in zweiter linie nicht mit Quellcode sondern mit UML-Diagrammen.

    Jedenfalls sollte man besser eine typsichere, nichtdynamische sprache wie java oder c# nehmen, um oo zu lernen.

    Eine gute Übung, wenn man etwas weiter ist:

    ein OO-Diagramm der objektorientierung zu entwerfen.

    Da gibt es dann Klassen mit namen wie "Class", "SealedClass", "AbstractClass" usw.

    Man arbeitet dann auf der Meta Ebene.


    Ich habe halt die erfahrung gemacht, dass sich leute, die zuerst zu viel mit prozeduraler Programmierung machen ein bisschen den Blick verlieren, den man bei OOP braucht. Denn ein OO-Model lässt sich schwer formell auf korrektheit überprüfen.


    Was aber ganz essesentiell ist, sind die s.g. Kardinalitäten. Wenn die nicht richtig abgebildet sind, bekommt man irgendwann eklige Problem mit dem OO Model und muss dann irgendwann viel "manuell" refacturen=überarbeiten, was sehr fehlerträchtig ist. Normalerweise folgt refacturing sehr einfachen starren regeln und ist deshalb sehr sicher, die meisten prüfungen übernimmt der compiler. Deshalb gibt es auch tools für Refacturing Muster, die 100e Muster anbieten, speziell für das umbauen von oo-code.


    Beispiele für Kardinalitäten: /(hatEin-BEziehung)

    Richtig: Ein Tisch hat 4 Beine.

    Falsch: Ein Bein hat 4 Tische.


    Beispiele für Ableitungen: (istEin-beziehung)

    Hund ist ein Tier - richtig oder falsch

    Tier ist ein Hund - richtig oder falsch

    Ein Schwanz hat einen Hund?

    Ein Hund hat einen Schwanz?


    Diese beiden beziehungstypen "IstEin" und "HatEin" sind die fundamentalen beziehungstypen zwischen objekten. Sie sind direkt dem menschlichen Verstand entlehnt.


    Auf den ersten blick sieht das vielleicht etwas seltsam aus, aber solche fragen richtig zu beantworten ist für ein gutes oo modell unerlässlich. In OO Modellen arbeitet man auch selten mit empirischen Konzepten wie Hund oder Katze sondern mehr mit Konzepten der Vernunft und Anschauung, also z.b. einer Rechnung und einer Rechnungsposition. Oder einem Protokollstack. Da wird es dann schon schwieriger sich für die richtige Vererbungshierarchie zu entscheiden.


    Dass ein Hund ein Tier ist dürfte jedem einleuchten. Dass die Aussage "Ein Tier ist ein Hund" etwas schräg klingt, wird auch jedem auffallen. Eine solche Verwechlung ist in der oo aber ein fundamentaler Design fehler, der sich meist aber relativ einfach durch Umgennenen der Klasse beheben lässt. Bei OO sind imo namen, besonders die konsistenz und die eindeutigkeit - sehr wichtig. Der Mathematiker sagt ja eher "Namen sind Schall und Rauch"...


    Ein Kollege hat mal stunden damit verbracht darüber zu lesen, wie polymorphe Ausnahmen (Exceptions) auf dem Stack verwaltet werden, ohne wirklich verstanden zu haben, zu was sie gut sind. Wichtig finde ich echt, dass man nicht zu technisch an die oo rangeht. Man sollte mehr Erkenntnistheoretisch an die sache rangehen, denn oo modelle lassen sich relativ gut formalisierbar auch aus menschlicher sprache und der art ableiten, wie der mensch seine umwelt wahrnimmt. Deshalb bin ich sehr gespannt, was ich bzgl. kognitiver Architekturen und "MindToCode" - also quasi programmieren mit gedankenkraft - noch so errleben werde.

    Zitat von Holzfaellen

    das man diese art von Funktionen im allgemeinen nicht durch eine Konstruktion angeben kann. Da können sehr schnell Sachen schief gehen, wenn man nicht genau aufpasst

    Das vertsehe ich nicht, musste erstmal was über das Auswahlaxiom in erfahrung bringen... Was versteht man hier unter einer konstruktion?


    Solche Konstruktionen, die über meine workarounds.h definiert werden? Ikea Betten.Monate Gudfik? ;-) Vermutlich ist Konstruktion ein sehr definierter Begriff... (siehe letzte frage)

    Zitat von Holzfaellen

    Auswahlaxiom


    Also das wäre mal vl. ein Einstieg, um endlich mal mit der mathematischen Notationen etwas besser zurecht zu kommen, denn mit Mengen arbeite ich in der OO sehr viel. Ich kratze hier aber momentan noch an der Basis:


    Zitat

    Das Auswahlaxiom besagt, dass zu jeder Menge von nichtleeren Mengen eine Auswahlfunktion existiert, also eine Funktion, die jeder dieser nichtleeren Mengen ein Element derselben zuordnet und somit „auswählt“. Für endliche Mengen kann man das auch ohne dieses Axiom folgern, daher ist das Auswahlaxiom nur für unendliche Mengen interessant.

    Ich verstehe das so, dass man zu einem konkreten mathematischen model definieren kann,

    "hier gilt das auswahlaxiom". (Ich musste erstmal in erfahrung bringen, was man unter axiom versteht)


    Denn dieses axiom gilt ja nicht grundsätzlich, wenn man von irgendeiner Menge von Mengen spricht,

    sondern nur wenn es relavant ist, aus einer der mengen ein einzelnes element auszuwählen.

    Man könnte ja genausogut funktionen definieren, die auf alle elemente anwendbar sind.

    Blos mit unendlichen Mengen mengen kann man nicht "für jedes element" operieren,

    denn sonst wäre das halteproblem da..

    Deshalb braucht man für jede unendliche Menge so eine funktion, die das auswahlaxiom "befriedigt".


    Sehe ich das etwa richtig?


    Zitat von Holzfaellen

    axiom / Konstruktion

    Wichtige Frage:

    Wie heisst denn nochmal die "Lehre", der modernen ERkenntnistheorie,die solche Begriffe

    wie "axiom", "these" usw. definiert ?


    Ich stehe da nämlich noch auf dem Level von Kant und habe mich nie an diese Thematik rangewagt. Glaube auf dem Gymnasium hätte man sowas beigebracht bekommen, oder? Evtl. würde ich sogar mal einen udemy kurs darüber angehen, und wenns nur ist, dass ich bei den Covidioten Diskussionen endlich mal behaupten kann, ich weiß, wie Wissenschaft funktioniert ^^ (Vielleicht fange ich dann ja auch mal an, alles in der bildzeitung zu glauben, vor dem steht, dass es wissenschaftler herausgefunden haben hihi)


    Zitat von Holzfaellen

    vor dem Studium vor allem Neuronale Netze interessiert

    Damit habe ich auch mal etwas rumgespielt, ein video mit musik-visuals gebastelt. Ich hab auch etwas die theorie dahinter verinnerlicht, die Funktionsweise des Perceptrons. Ich wollte das auch mal selber implementeiren, bin aber an irgendwann an der Berücksichtigung der Loss-Funktion bei der BackPropagation steckengeblieben. NAja, wenn man das nur zwischen maxdome, youtube, mucke machen und arbeiten betreibt ist das etwas unergiebig.