Guten Morgen,
ich hab da auch mal ne Frage die mir hier vielleicht jemand beantworten kann.
Ich habe nun schon des öfteren funktionale Programmierung kennen gelernt (in der Schule und Uni). Aber bisher ist mir der wahre Anwendungsbereich verborgen geblieben. Ich weiß das man es benutzt, die Frage ist nur wofür???
Viele Grüße,
PaNic
Naja ich denke mal ein Grund wird es sein, dass man so die Schüler an die Programmierung ranführen kann weil die ja teilweise eine relativ einfach Syntax haben.
Ich weiß jetzt nicht genau in wie weit es Interpreter für die Sprachen gibt aber z.B. bei logischen Sprachen wie Prolog gibt es Interpreter die man einfach in einem anderen Programm (z.B. in C++) aufruft und so einfach Abfragen machen kann. Das wurde bei uns in der HS z.B. bei den Roboterhunden gemacht, da war die ganze Spiellogik als Prolog vorhanden und dann wurden die einfach nur so abgefragt.
Naja das man die Schüler damit an die Programmierung ranführt kann ich mir nicht vorstellen. Damit verwirrt man sie eigentlich eher.
Ich kenne es nur das man als Einstieg ganz oft Prolog benutzt. Haben wir auch gemacht und vor ein paar Jahren haben die das bei uns an der Uni auch gemacht.
Aber als vor ein paar Wochen ML dran war, gab es schon ne Menge verwirrte Gesichter 
ich habe an der uni auch mit einer funktionalen Sprache angefangen… nur weil heutzutage oop eher angewandt wird heißt das nicht dass diese nicht mehr existenzberechtigt sein.
Ich finde zum lernen von programmieren ist eine funktionale Sprache wesentlich effektiver als z.b. java. Man lernt schnell was Funktionen / Prozeduren bzw. Algorithmen sind und kann einfach schnell programme erstellen ohne sich mit Objekten / Instanzen oder Klassen rumschlagen zu müssen
Ich hab nicht gesagt das die nicht existenzberechtigt ist, im Gegenteil.
Ich möchte gerne wissen was man damit machen kann (also komplexere Sachen als Uniaufgaben oder so), bzw. ob es vielleicht jemanden gibt dem mal eine funktionale Sprache in der Praxis „begegnet“ ist.
In den Ferien werde ich mich mal an Haskell probieren, dann wird mal nachgesehn was man damit alles machen kann 
Im Vorwot des Open Book „How to Think Like a Computer Scientist - Learning With Python“ legen Lehrer/Forscher/Autor David Beazley (Universität von Chicago), sowie später der Hauptautor Jeff Elkner (Lehrer am College) recht gut dar, warum sie sich nach einiger Suche und auch jahrlangen Erfahrungen mit anderen Sprachen entschieden, ihren Schülern/Studenten als erste Sprache Python beizubringen.
Die Argumente gegen Java, C++ und C# lassen sich größtenteils 1:1 auch hierfür übernehmen.
Man schaue sich nur mal in den drei Sprachen ein Hello-Word-Programm an. Als Lehrer stehst du schon hier vor der Entscheidung, ob du den ganzen Kram drumrum (public, static, void, main, String, class, …) erklärst oder ignorieren lässt. In beiden Fällen strotzt selbst dieses einfachste aller Beispiele nur so vor Verwirrungspotenzial.
In vielen funktionalen Sprachen und sog. Skriptsprachen kannst du dagegen erstmal ohne viel Ballast die Basics erläutern und die Jungs und Mädels damit Erfahrungen aufbauen lassen. Stück für Stück kannst du sie von einfachen Ausgaben und Brechnugnen, an Dateioperationen, Funktionen und später an Klassen, Vererbung, etc. heranführen (okay, nicht in funktionalen Sprachen ).
Didaktisch ist das einfach sinnvoller.
Ok, also funktionale Programmierung ist gut für den Anfang. Das stimmt schon. Trotzdem verwirrt es viele.
Aber … funktionale Programmierung gibt es doch nicht nur um arme kleine Schüler/Studenten in die Programmierung einzuführen. Es gibt doch sicherlich auch eine Anwendung die darüber hinaus geht oder etwa nicht?
Ich habe schon oft gehört, das funktionale Sprachen für künstliche Intelligenz aller Art verwendet wird.
ho, ich durfte im ersten semester auch eine solche Sprache nennen, nennt sich opal und ist eine eigenentwicklung der tu-berlin.
im ersten semester hat man das teil gehasst, nach besuch der entsprechenden vorlesungen in richtung compiler-/interpreterbau, fortgeschr. funktionale techniken, typsysteme, … hat man dann das konzept begriffen und den compiler und seine probleme verstanden.
in diesem moment merkt man dann, das diese sprachen deutlich weiter sind als das heute am industriellen markt etablierte. so ist zum beispiel polymorphie ein konzept was schon das ein oder andere jahrzehnt auf dem buckel hat und es gerade erst merhr oder weniger schön in die java-welt geschafft hat. Über solche Features wird in der Forschung kaum noch geredet, und wenn dann mit irgendwelchen zusätzen welche den compiler vor ernste Probleme stellen
Funktionale Sprachen werden aber - meiner meinung nach - industriell kaum benutzt. In der Forschung sind sie nicht mehr wegzudenken, aber eben bisher auch nur dort. In der künstlichen Intelligenz gibt es verschiedene Gebiete, dort sind aber erstmal logische Programmiersprachen wie Prolog interessant. Die wikipedia-Seite dazu ist durchaus interessant.
Funktionale Sprachen bieten aber durchaus nette Sachen, zB. sieht in Opal eine Funktionsdeklaration etwa so aus:
FUN sample: int ** nat → int ** nat
kann also nicht nur mehrere variablen aufnehmen sondern auch zurückgeben.
interessant sind dann funktionen höherer ordnung wie:
FUN umba: int ** nat → (int → nat) → nat
hier ist der zweite Teil (int → nat) eine art funktionspointer, man kann beim aufruf also eine funktion mit genau diesen parameztern übergeben. In der richtigen reihenfolge:
FUM umba2: (int → nat) → int → nat
kann man sogar ‚halbfertige‘ funktionspointer generieren, man übergibt die funktion mit parametern (int → nat) und bekomm einen funktionspointer mit int → nat zurück, den man beliebig oft benutzen kann.
Funktionale Sprachen zeichnen sich aber auch dadurch aus, das es eigentlich keine „Welt“ gibt, alles an IO macht also sehr aufwändige Konzepte wie Monaden nötig, die intern eine Art eindeutigen Zustand verfolgen müssen, den es so sonst nicht gibt. So werden zB. Datenstrukturen in Rekursionen automatisch in den lokalen Zustand zurückgespielt.
An Sprachkonzepten gibt es relativ wenig, Opal beherrscht Zuweisungen, IF und Rekursion. Daneben noch einige Abwandlungen dieser Konzepte, die nur hier notwendig sind, aber viel mehr nicht.
Hi,
es gibt eine ganze Menge Gründe für die Funktionale Programmierung. Haskell ist hier immer die Vorzeigesprache, da sie schon ein Weilchen eine ganze Menge an Features unterstützt. Du findest auf der offiziellen Seite auch das Paper „Why Functional Programming matters“.
Da siehst du dann nochmal eine Menge der Vorteile.
Imho sind die wichtigsten:
Das funktionale Sprachen gerne an Unis oder Schulen für den Anfang verwendet werden liegt keineswegs allein daran, dass sie einfach zu lernen sind, eine Uni sollte immer den Anspruch der Vollständigkeit haben. Funktionale Programmierung ist halt ein Konzept mit vielen Vorteilen (auf die ich noch kommen werde).
Entscheidend für die Unis ist aber, dass Studenten das gleiche Wissen haben sollen. Insbesondere im ersten Semester gibt es viele unsichere Studenten.
Das Problem ist, dass viele Studenten gerade im ersten Semester sehr unsicher sind. Gerade bei weiblichen Studenten soll dies ein Problem sein. Ist hier keine sexistische These von mir! Es ist ja nun aber bekannt, dass die mathematisch/technisch/naturwissenschaftlichen Studienfächer häufig deutlich mehr männliche als weibliche Studenten haben. Hier fühlen sich Frauen also allein wegen ihrer geringen Anzahl schneller verunsichert. Natürlich geht es genug männlichen Studenten nicht anders (denen trauert die Uni nur weniger nach )
Jetzt gibt es häufig mal Kurse, die sich im ersten Semester der Programmierung widmen. HIer gibt es dann immer die Studenten, die schonmal programmiert haben und eben auch die, denen hier jegliche Erfahrung fehlt. Würde man nun mit C/C++, C# oder Java beginnen, würden einige der Studenten wohl im Vorteil sein und da es dann auch immer wieder Leute gibt, die dass ganz groß raushängen lassen müssen, werden hier einfach Leute verschreckt und brechen viel zu früh ab.
Mit einer funktionalen Sprache hat man eigentlich immer den Vorteil, dass es noch keiner vorher verwendet hat. Damit ist es für alle eine neue Denk- und Programmierweise und es bleiben einem ein paar dumme Sprüche erspart.
Ja, die anderen Vorteile liegen halt in der Mächtigkeit der funktionalen Sprachen.
Funktionale Sprachen haben einfach den Vorteil, dass sie auf dem Lambda Kalkül basieren. Dies ist eine sehr einfache „Ersetzungs“-Regel, die aber alles berechenbare berechnen kann. Der große Vorteil liegt einfach darin, dass alles eine Funktion ist. Ein funktionales Programm wertet eigentlich nur eine Funktion aus. Dazu werden die einzelnen Terme hier reduziert.
Funktionen kennt man aus der Mathematik, Lösungen für Probleme kann man dabei sehr leicht in eine Funktionale Sprache umsetzen.
Eines der schönsten Beispiele ist (finde ich) der Quicksort in Haskell, der besteht einfach nur aus:
[Python]
qsort :: (Ord x) => [x] → [x]
qsort [] = []
qsort (a:as) = [x| x ← as, x < a] ++ [a] ++ [x| x ← as, x >= a]
[/Python]
Die erste Zeile ist dabei die optionale Signatur. Die Sprache Haskell braucht diese nicht einmal. In diesem Fall wird angezeigt, dass eine Liste von Elementen des Typs x in eine Liste des gleichen Typs überführt wird. Dass (Ord x) => ist dabei eine Einschränkung, dass das x ein ordinaler Datentyp sein muss (es muss ja verglichen werden).
Danach wird Pattern matching angewendet, ist die zu sortierende Liste leer, ist die Sortierte Liste natürlich die leere Liste.
Der zweite Fall besteht darin, dass man eine nicht leer Liste hat. Listen sind hier rekursiv definiert, eine Liste ist entweder die leer Liste oder besteht aus einem Kopf und einer Liste. Der zweite Teil ist dann wieder entweder Leer oder hat einen Kopf und eine Liste…
a ist hier einfach der Kopf der Liste, man könnte natürlich auch ein zufälliges Pivotelement suchen. An sich findet man hier aber die Idee des Algorithmus.
[x | x ← as, x < a] heißt einfach nur, dass hier die Liste aller x, mit x aus der Liste as, gebildet wird, wobei für jedes dieser x gilt x < a. Natürlich spricht man in der Mathematik wohl kaum von Listen, aber sieht schon dass es sehr nah einer „normalen“ mathematischen Funktion ist.
So sieht es im allg. immer aus (weswegen der Code gerne als Elegant und leicht verständlich durchgeht). Vorallem hat man hier auch gleich eine formale Spezifikation der Funktion.
Ein ganz wichtiger Vorteil ist, dass es eben nur Funktionen gibt (so ziemlich). Es gibt keine Variablen im eigentlichen Sinne. Jede Funktion hat Funktionsparameter, diese sind aber ebend nur für einen Aufruf dieser Funktion gültig. Damit ist die Ausführung einer Funktion nicht von einem Zustand abhängig. Es können damit keine Seiteneffekte auftreten. Hier werden viele Fehlermöglichkeiten vermutet, die so (zumindest theoretisch) in einer Funktionalen Sprache vermieden werden.
Ein weiterer Vorteil liegt nun darin, dass sich damit die Parameter einer Funktion nach dem Aufruf nicht ändern können (es fehlt ja soetwas wie eine globale Variable oder eine Referenz oder so). Damit ist es egal wann ein Parameter weiter ausgewertet wird.
Das tolle ist, dass ein Parameter halt auch eine Funktion sein kann. Auch dafür gibt es dann sehr viele Beispiele, dass geläufigste ist wohl der Filter. Auch diesen wendet man auf eine Liste an. Man kann hier einfach eine boolsche Funktion F und eine Liste A reingeben und bekommt die Liste B, die alle Elemente aus A enthält, für die F(a in A) wahr ist.
Solche Funktionen können somit z.B. auch Listen erzeugen. Die Länge einer Liste ist dyn., man kann sogar endlos lange Listen schaffen.
Dank der Lazy-Evaluation kann man auch mit solchen Strukturen arbeiten. Statt erst die endlose Liste anzulegen und dann mit dieser weiter zu arbeiten (z.B. aus dieser Liste die ersten 10 Elemente zu nehmen) wird die Funktion erst dann ausgewertet, wenn sie wirklich gebraucht wird.
Auch in der Praxis wird funktional Programmiert. Das amerikanische Militär, die ESA oder NASA (bin mir nicht mehr ganz sicher) und Ericsson setzen als recht große Vertreter auf diese Art der Programmierung.
Man hat wie gesagt ein paar Vorteile. Sicherlich ist es heut zu tage möglich in Java per Gerenerics ähnliches zu ermöglichen wie das Polymorphiesystem von funktionalen Sprachen ermöglicht und über gewisse Pattern lassen sich auch high-order functions nachbauen, aber die Ideen dahinter gibt es schon länger und in der funktionalen Programmierung laufen sie auch. Dazu kommt, dass man fast direkt mathematische Formeln umsetzen kann, was dann natürlich noch weitere Vorteile mit sich bringt.
Das Sprachen wie Python funktinale Sprachkonstrukte neben imperativen erlauben ist nur eines der Zeichen dafür, dass sie nicht ganz nutzlos sein dürfte. Auch in dem Entwurf von C# 3.0 steht der Lambda-Operator drin…
Gruß Der Anmeldeboykottierer (der sich hier vielleicht auch irgendwann anmeldet, mal schauen).
Das die besagten Studienfächer deutlich unterbesetzt sind (was die Frauen angeht) ist kein Geheimnis, aber das sich je eine die ich kennengelernt habe verunsichert fühlte kann ich nicht unbedingt sagen. Eher im Gegenteil.
Ausserdem sind wir in der Uni nicht mit funktionaler Programmierung, sondern mit Java angefangen. Die Verwirrung kam bei den meisten deshalb auch erst später.
Danke für die 2 überaus ausführlichen Erklärungen was denn funktionale Programmierung ist, aber das und die Vorteile davon waren mir schon bekannt. Deshalb bin ich ja auch erst auf diese Frage gekommen…
Du schreibst die ganze Zeit von den Vorteilen funktionaler Programmierung, aber viele dieser Vorteile können auch schnell zu Nachteilen werden. Es kommt immer auf das Einsatzgebiet an. Probleme, die man auf mathematische Grundprobleme zurückführen kann, da haben funktionale Sprachen schon gewisse Vorteile. Bei den meisten kommerziellen Anwendungen steht aber die Datenverarbeitung im Vordergrund und weniger mathematische Berechnungen, Beweise oder Verifikationen. Und da hat die OOP nun mal diverse Vorteile gegenüber funktionalen Sprachen. Alleine der Punkt „Zustandsfreiheit“ funktionaler Sprachen hat die Konsequenz, dass Du schnell mit unübersichtlich vielen Parametern hantieren musst, weil Du jegliche Information der Funktion übergeben musst.
Das ist wohl auch der Grund, warum funktional primär nur noch in der Forschung und Wissenschaft programmiert wird. Man kann mit solchen Sprachen (ich schließe mal die Logiksprachen mit ein) prima solche mathematischen Probleme lösen. Häufig werden ja solche Systeme erstmal von einem theoretischen Standpunkt analysiert und formal als Denotationale Semantik oder Operationale Semantik definiert. Diese Semantiken lassen sich mit solchen Sprachen dann fast 1 zu 1 realisieren, während man mit OO Sprachen erstmal so seine Probleme hat (spreche da aus Erfahrung). 
Tut es doch eh immer, aber ja, hast du natürlich recht, auch die Funktionale Programmierung löst nicht alle Probleme. Da wird es auch nie ein Konzept geben, dass dies leisten wird. Klar, hab die Nachteile weggelassen.
Das finde ich ist etwas diskussionsbedürftig. Es mag häufig um die Arbeit mit Dateien gehen, aber allein die ganze Film/Foto/Bildverarbeitungswelt/CAD/3D (die imho einen guten Teil der kommerziellen Produkte ausmacht) basiert darauf, dass man eine Daten aus einer Datei einliest und mit diesen Berechnungen durchführt. Dies wäre mit Hilfe von Monaden in Funktionalen Sprachen wieder sehr elegant (ohne zig-tausende Parameter) lösbar.
An sich denke ich, dass gerade Spezifikation und Verifikation nur in kommerziellen Produkten wirklich zum Tragen kommt. Dem privaten Entwickler oder Studenten an 'ner Uni ist es doch noch relativ egal wie beweisbar korrekt sein Programm arbeitet, es funktioniert einfach. In größeren Firmen gibt es aber Menschen die sich für diese Beweise bezahlen lassen. Ein Großes Autohaus mit zwei Buchstaben, dass seinen Hauptsitz in Wolfsburg hat erlaubt deswegen z.B. keine verschachtelten Schleifen und keinen Wechsel der Programmiersprache (weiß nicht ob das noch aktuell ist). Und die sind bestimmt nicht die Ausnahme und auch kommerziell tätig.
Wobei hier deine Argumentation nicht weit genug geht, da müssten dann imperative Sprachen die gleichen Vorteile bieten. Imho macht die OOP doch ein wenig mehr aus, als die Zustände von Objekten. Aber das was über die Zustände hinausgeht findet man dann auch schnell in den funktionalen Sprachen wieder.
[QUOTE=byto;1211]
Man kann mit solchen Sprachen (ich schließe mal die Logiksprachen mit ein) prima solche mathematischen Probleme lösen. [/QUOTE]
Na ja, bei Logiksprachen stösst man finde ich schneller an Grenzen. Hier lässt sich nicht jedes Problem ganz so leicht formulieren.
An sich bleibt natürlich der Fakt bestehen, dass keine Herangehensweise überall gleich geeignet ist. Man merkt aber an Sprachen wie Python oder C#, dass ein Zusammenwachsen der Welten gibt und man die Möglichkeit bekommt an einer Stelle funktional und an einer anderen OO zu programmieren. Natürlich stösst man da schnell auf Dinge die nicht zu vereinen sind (currying in Java z.B.). Deswegen bieten sich halt Modelle wie .net an, die Komponenten aus solchen Sprachen erzeugen können, die auch interagieren können (ansonsten ist klar, dass es schon davor Komponenten gab und auch danach welche geben wird und wofür die gedacht sind!)
So, nur um es klar zu stellen, ich bin keineswegs jmd. der Funktionale Programmierung verwendet oder meint sie sei das einzigst wahre! Ich denke nur es gibt wirklich ein paar sehr interessante Ansätze und ein paar sehr Elegante Problemlösungen. Man sollte einfach auch beachten, was die Polymorphie in Funktionalen Sprachen schon am Anfang leistete (und weiterhin leistet) und wie umständlich man soetwas in anderen Sprachen nachbauen musste. Das Konzept der funktionalen Programmierung ist einfach noch jung und ich denke da ist noch Potential vorhanden (auch bei der OOP hat es doch ein Weilchen gedauert bis die sich ernsthaft etablieren konnte).
Ich denke halt, man sollte sie nicht pauschal als Lehr/Forschungskonzept abtun. Aber gut, wir werden ja irgendwann sehen, ob sich was daran ändert oder nicht.
Gruß Der Anmeldeboykottierer
Also vorweg, nicht dass Du mich mißverstehst: Ich gebe Dir grundsätzlich recht in dem, was Du über die funktionalen Sprachen geschrieben hast. Ich wollte nur zur Bedenken geben, dass man das nicht pauschal wertend beurteilen kann. Du hast nacheinander diverse „Vorteile“ aufgezählt, die aber je nach Kontext auch nachteilig sein können.
Es gibt kein Konzept, dass allgemeingültig alle Probleme der Informatik bestmöglich lösen kann. In meinen Augen lösen funktionale Sprachen primär andere Probleme als OO Sprachen. Oder anders gesagt: beide Paradigmen haben ihre Stärken in unterschiedlichen Aufgabenbereichen. Daher ergänzen sie sich gegenseitig anstatt in Konkurrenz zu stehen. Daher ist es in meinen Augen nicht umbedingt sinnvoll, von Vor- und Nachteilen zu sprechen.
Das finde ich ist etwas diskussionsbedürftig. Es mag häufig um die Arbeit mit Dateien gehen, aber allein die ganze Film/Foto/Bildverarbeitungswelt/CAD/3D (die imho einen guten Teil der kommerziellen Produkte ausmacht) basiert darauf, dass man eine Daten aus einer Datei einliest und mit diesen Berechnungen durchführt. Dies wäre mit Hilfe von Monaden in Funktionalen Sprachen wieder sehr elegant (ohne zig-tausende Parameter) lösbar.
Du hast natürlich recht, dass Bildbearbeitung sehr rechenlastig ist und man diese Berechnungen sicherlich funktional gut lösen kann. In der Praxis werden aber wohl dann doch eher Sprachen wie C++ verwendet, die dank Templates und Operatorüberladung dahingehend auch einiges an Komfort bieten. Java hingegen ist da wohl eher nicht die erste Wahl. 
An sich denke ich, dass gerade Spezifikation und Verifikation nur in kommerziellen Produkten wirklich zum Tragen kommt. Dem privaten Entwickler oder Studenten an 'ner Uni ist es doch noch relativ egal wie beweisbar korrekt sein Programm arbeitet, es funktioniert einfach.
Mit Forschung und Wissenschaft meine ich nicht irgendwelche Studenten, das wäre Lehre. Vielmehr meine ich damit den Teil der IT-Entwicklung, die sich primär mit der Weiterentwicklung und dem theoretischen Hintergrund beschäftigt. Nicht nur Universitäten forschen, sondern auch die Wirtschaft…
Wobei hier deine Argumentation nicht weit genug geht, da müssten dann imperative Sprachen die gleichen Vorteile bieten. Imho macht die OOP doch ein wenig mehr aus, als die Zustände von Objekten. Aber das was über die Zustände hinausgeht findet man dann auch schnell in den funktionalen Sprachen wieder.
Es war ja auch nur ein Beispiel von mir. Ich wollte nicht Dein ganzes Posting zerflücken sondern habe mir ein Beispiel rausgesucht. Natürlich ist das nicht der einzige Vorteil der OOP, das habe ich auch nie behauptet. Aber eine Vielzahl kommerzieller Anwendungen, die datenzentriert sind, profitieren halt immens vom objektorientierten Paradigma.
So…Es ist mir bewusst dass das ein sehr alter Thread ist…trotzdem kriegt er meinen Senf ab!
Da funktionale Sprachen eben den erwähnten Lambda-Kalkül verwenden, können sie einen sehr,sehr schnellen Code erzeugen. Intern wird eine vom Programmierer geschriebene Funktion nach den Regeln des Lambda-Kalkül in die Normalform gebracht, was oft eine wirklich enorme Vereinfachung des Code bedeutet.
Falls es jemanden interessiert, hier ist ein Link zu einem Lambda-Kalkül-Programm. Es berechnet eben die Nomalform von Lambda-Ausdrücken. http://fr.sourceforge.jp/projects/sfnet_lipsinterpreter/
Das Programm ist von jemandem geschrieben, den ich über die Uni kenne. Es ist nur für Linux und eher nur zur Anschaung gedacht. Aber man kann so lustige Sachen damit machen wie elendslange Ausdrücke konstruiren und mit !trace zu schauen wie diese vereinfacht werden. Vielleicht kann man es zu mehr nutzen, weiß es nicht, wir haben es jedenfalls so genützt um dem Lambda-Kalkül zu verstehen.
Ich werde hier noch einen Link zu einem Wettbewerb nachliefen, wo man sieht wieviel schneller funktionale Sprachen sind. Bei diesem Wettbewerb nehmen zwei Teams teil, deren Programme in funktionalen Sprachen geschrieben sind (Haskell und OCAML). Und die anderen haben die in Java. Gut, Java ist nicht wirklich ein Maß für die Performance, aber die funktionalen Programme sind im Durchschnitt ca. 10-mal schneller.
Zu meinen eigenen Erfahrungen: Im ersten Semester haben wir als erstes mit OCAML angefangen, und ich habe es gehasst. Ich kapierte es nicht, kein bisschen. Dachte schon, ich hab mir das falsche Studium ausgesucht, doch zum Glück kam dann C…soviel zu der Verständlichkeit 
Jetzt, im dritten Semester haben wir wieder OCAML und jetzt hab ichs eigentlich ganz gern, eben das ganze Hintergrundwissen aus den zwei Semestern davor habe.
Wirklich?
[QUOTE=Evgeni;10645]
trotzdem kriegt er meinen Senf ab![/quote]
Warum? Nach vier Jahren?
Okay - wenn’s was richtig durgreifendes wäre, aber… Naja…
Beschränke dich auf die Gegenwart - da gibts genug Arbeit, alleine schon im Wiki (ein guter Tip, die Langeweile zu überbrücken)!
Was ist eigentlich der Grund für deinen Post?
Ich habe nur geschrieben, was meiner Meinung nach in diesem Thread fehlte.
Aber wenn man hier nicht mehr posten soll, warum löscht man ihn dann nicht?
Genau deshalb schreibe ich auch nochmals vier Jahre später hier rein. Ich verstehe denn Sinn nicht Warum man alte Threads nicht nach vorne holen kann. In jedem Forum beschweren sich dann die Admins. Über Google findet man aber genau diese Threads zuerst und die beantworten mir meine Fragen meist ausführlich und zuverlässig. Wenn dann eine Ergänzung auch vier Jahre später noch folgt ist das für mich absolut in Ordnung und sehr erwünscht! Danke dafür.
Sorry für das absolute Offtopic, mein Beitrag ist natürlich nicht so sinnvoll, ihr könnt den Thread wieder nach hinten fallen lassen… wollte das nur mal los werden!
Ich kann grad nicht mehr nachdenken heute, ist die Aussage richtig oder falsch?
In jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des zugehörigen Entity-Typs E.