# Informatik <-> Mathematik

## Necoro

 *Knieper wrote:*   

> Programmieren ist reine Mathematik.

 

Nur weil man für alles (evtl) ein mathematisches Modell angeben könnte, ist es noch lange keine "reine Mathematik".

Diskussion abgetrennt -- Finswimmer

----------

## Knieper

 *Necoro wrote:*   

>  *Knieper wrote:*   Programmieren ist reine Mathematik. 
> 
> Nur weil man für alles (evtl) ein mathematisches Modell angeben könnte, ist es noch lange keine "reine Mathematik".

 

Doch, ist es. Nur weil manche die Mathematik nicht sehen oder nicht in der Lage sind, ihre Problemstellung vernünftig zu formulieren, heißt das noch lange nicht, dass die Mathematik nicht da ist. Von simpler Binärarithmetik in der CPU, über Typtheorie/Sprachtheorie bei der Umsetzung bis zur eigentlichen Problemspezifikation ist alles diskrete Mathematik. Du kannst mit einem "Rechner" naturgemäß nichts anderes machen, als rechnen.

----------

## Necoro

Naja - da greifst du mit dem Begriff "reine Mathematik" aber zu weit. Am Ende kann man wohl jede Naturwissenschaft darauf runterbrechen -- und das ist doch nicht ganz Sinn der Sache (oder sind Chemiker jetzt auch nur Atomphysiker?). Ab einem gewissen Level der Abstraktion dem Kind einen neuen Namen geben ist schon recht sinnvoll. Und auch, sich über die darunterliegenden Schichten keinen Kopf machen zu wollen.

----------

## Knieper

 *Necoro wrote:*   

> Naja - da greifst du mit dem Begriff "reine Mathematik" aber zu weit. Am Ende kann man wohl jede Naturwissenschaft darauf runterbrechen -- und das ist doch nicht ganz Sinn der Sache (oder sind Chemiker jetzt auch nur Atomphysiker?).

 

Der Informatiker steht vor einem anderen Problem - er beschreibt keine Naturphänomene und schafft im Normalfall nichts Greifbares, sondern bildet nur Modelle auf den Rechner ab und sorgt dafür, dass diese korrekt umgesetzt werden. Programmierung kann daher nichts anderes als Mathematik sein und jemand der kein Mathe kann wird nie ansatzweise ein guter Programmierer werden. Man kann nicht oben und unten Mathematik haben, es in der Mitte ignorieren und behaupten man mache Kunst (was durchaus einige Entwickler behaupten, aber die taugen meistens nichts).

----------

## Necoro

Ich habe den Eindruck, du gehst da irgendwie zu sehr mit dem Blick eines Theoretikers dran. Für die meisten Programmierer ist Programmieren und Systeme entwickeln in erster Linie eine ingenieurswissenschaftliche Tätigkeit (heißt ja nicht umsonst "Software Engineering"). Mathematik ist nur Mittel zum Zweck (wenn überhaupt).

 *Quote:*   

> Man kann nicht oben und unten Mathematik haben, es in der Mitte ignorieren und behaupten man mache Kunst

 

Man hat oben eine Anwendung und unten E-Technik. Mathematische Modelle kommen überhaupt nicht vor, wenn man es nicht will  :Smile: 

/edit: Vielleicht kann ja ein Mod unsere Diskussion auch in einen anderen Thread auslagern  :Smile: 

----------

## misterjack

Die Mathe ist wie in vielen Naturwissenschaft auch hier nur eine reine Hilfswissenschaft, nicht mehr nicht weniger, Mittel zum Zweck  :Smile:  Das Programmieren reinste Mathe wär, ist Bullshit.

----------

## tazinblack

Na da hab ich ja wieder was losgetreten.

Und alles nur, weil ich bedingt durch meinen damaligen Prof ein Mathetrauma hab.

Ich hab übrigens den Verdacht, dass der gar kein richtiger Prof war. 

Also bitte streitet Euch nicht!

... schlagt Euch lieber   :Very Happy: 

----------

## Knieper

 *Necoro wrote:*   

> Für die meisten Programmierer ist Programmieren und Systeme entwickeln in erster Linie eine ingenieurswissenschaftliche Tätigkeit (heißt ja nicht umsonst "Software Engineering"). Mathematik ist nur Mittel zum Zweck (wenn überhaupt).

 

Die meisten Programmierer haben schlicht keine Ahnung von ihrem Job. Ein Architekt muss Statik beherrschen, ein Programmierer... tja... Trial and Error.

 *Quote:*   

> Man hat oben eine Anwendung und unten E-Technik. Mathematische Modelle kommen überhaupt nicht vor, wenn man es nicht will 

 

Wenn man sich ganz dumm stellt, mag man die Mathematik nicht sehen, sobald man aber nur einen Typ deklariert, eine Klasse vererbt, eine Liste erstellt, eine Funktion schreibt, sich an LINQs query comprehensions erfreut usw. macht man Mathematik und nichts anderes.

Es ist nicht wie im Alltag, wo man einen Sack Kartoffeln trägt und keine Menge x dreckiger ockerfarbener Knollen, Programme sind nur Formalismen.

http://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Für die meisten Programmierer ist Programmieren und Systeme entwickeln in erster Linie eine ingenieurswissenschaftliche Tätigkeit (heißt ja nicht umsonst "Software Engineering"). Mathematik ist nur Mittel zum Zweck (wenn überhaupt). 
> 
> Die meisten Programmierer haben schlicht keine Ahnung von ihrem Job. Ein Architekt muss Statik beherrschen, ein Programmierer... tja... Trial and Error.

 

Richtig -- der Architekt muss Statik können. Der muss aber nicht unbedingt wissen, warum etwas in der Statik so und nicht anders ist. Er kann es einfach als gegeben hinnehmen. Sprich: Er sieht eine Formel, von der man ihm gesagt hat "Die berechnet Foobar" und wenn er Foobar haben will, setzt er die Werte ein. Fertig. Warum die Formel jetzt so ist, wie sie ist und ob da jetzt coole Eigenschaften von stetigen Funktionen im n-dimensionalen Raum verwendet werden oder nicht, interessiert ihn nicht ansatzweise.

Genauso ist es doch in der Informatik: Wenn du mit Typen arbeitest, kannst du das Typsystem einfach mal als gegeben hinnehmen. Die Erwägungen die dem System zu Grunde liegen und erst Recht die darunterliegenden Mathematik kann mir doch erstmal gestohlen bleiben, so lange ich daran nicht rütteln will.

Wenn du jetzt zB in Haskell programmierst, denn arbeitest du doch auch nicht vorher in Kombinatorische Logik ein, um das Hindley-Paper zu verstehen um denn im Endeffekt das HM-System zu verstehen um daraus wiederrum Schlüsse für die Typisierung deiner Funktionen in Haskell zu ziehen. Sondern du siehst HM (plus halt die ganzen Haskell-Erweiterungen) einfach mal als gegeben an und arbeitest damit. Oder (auch das kann sein), du hast keine Ahnung, warum das Haskell-Typsystem so ist wie es ist, sondern benutzt es nur. Aber auch damit kommt man zurecht.

----------

## Knieper

 *Necoro wrote:*   

> Wenn du jetzt zB in Haskell programmierst, denn arbeitest du doch auch nicht vorher in Kombinatorische Logik ein, um das Hindley-Paper zu verstehen um denn im Endeffekt das HM-System zu verstehen um daraus wiederrum Schlüsse für die Typisierung deiner Funktionen in Haskell zu ziehen.

 

Ähm, doch. Diese grundlegenden Typsysteme sollte jeder ernsthafte Programmierer drauf haben und man sollte auch wissen, welche Eigenschaften welche Fähigkeiten der Sprache ermöglichen. Das ist schlicht sein Handwerkzeug. Wir mussten damals selbst die Warren Abstract Machine im Kopf haben, was ich allerdings für übertrieben halte.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Wenn du jetzt zB in Haskell programmierst, denn arbeitest du doch auch nicht vorher in Kombinatorische Logik ein, um das Hindley-Paper zu verstehen um denn im Endeffekt das HM-System zu verstehen um daraus wiederrum Schlüsse für die Typisierung deiner Funktionen in Haskell zu ziehen. 
> 
> Ähm, doch. Diese grundlegenden Typsysteme sollte jeder ernsthafte Programmierer drauf haben und man sollte auch wissen, welche Eigenschaften welche Fähigkeiten der Sprache ermöglichen. Das ist schlicht sein Handwerkzeug. Wir mussten damals selbst die Warren Abstract Machine im Kopf haben, was ich allerdings für übertrieben halte.

 

Denn würde ich sagen: Gut dass du nicht in der Industrie arbeitest  :Razz: 

/edit: Nachtrag: Wenn ich an der Uni nicht mal gezielt eine entsprechende Vorlesung aufgesucht hätte, hätte ich im gesamten Studium nix von HM gehört. Und der einzige Dozent der da was gemacht hat, geht zum Ende des Monats auch noch.

----------

## Knieper

 *Necoro wrote:*   

> Denn würde ich sagen: Gut dass du nicht in der Industrie arbeitest 

 

Du weißt wo ich arbeite?  :Shocked: 

 *Quote:*   

> hätte ich im gesamten Studium nix von HM gehört

 

Falsche Uni? Bei mir gehörte das zu den Pflichtveranstaltungen im Grundstudium, genauso wie die Verifikation von C-Dialekten mit axiom./denot./operat. Semantiken in der Programmierungsvorlesung und zwei Semester Logik.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Denn würde ich sagen: Gut dass du nicht in der Industrie arbeitest  
> 
> Du weißt wo ich arbeite? 

 

Nein. Aber ich hätte spontan durch andere Beiträge von dir einfach mal auf akademischen Bereich getippt. (Und die Trefferchance liegt ja auch quasi bei 50%  :Very Happy: ).

 *Quote:*   

>  *Quote:*   hätte ich im gesamten Studium nix von HM gehört 
> 
> Falsche Uni? Bei mir gehörte das zu den Pflichtveranstaltungen im Grundstudium, genauso wie die Verifikation von C-Dialekten mit axiom./denot./operat. Semantiken in der Programmierungsvorlesung und zwei Semester Logik.

 

Verifikation in den verschiedensten Varianten gibts hier schon (mindestens drei Lehrstühle), aber sowohl Logik als auch Typsysteme und Programmiersprachen wird nicht sonderlich viel gelehrt. (Uni ist TU München -- ist halt vorrangig auf Softwareentwicklung und praktische Anwendung ausgerichtet).

Aber gerade deshalb sehe ich deine Aussage ja kritisch, der halben Informatikwelt (auch der akademischen) vorzuwerfen, sie habe keine Ahnung und sei stümperhaft.

Die eine Hälfte betrachtet Informatik eben vorrangig als Ingenieursarbeit, sprich Handwerk, wobei Programmiersprachen eben Handwerkszeug ist und man sich damit beschäftigt, wie man dieses Handwerkszeug anwenden kann um große Dinge zu schaffen. Und die andere Hälfte sieht eben das Handwerkszeug der anderen bereits als das große Ding was es zu erschaffen gilt und benutzt selber wiederum die Mathematik um dahin zu kommen.

----------

## Max Steel

Und die dritte Gruppe sieht euch an und lacht. denn die verlötet die 1000Füssler auf denen ihr programmiert mit Leichtigkeit.

----------

## Necoro

 *Max Steel wrote:*   

> Und die dritte Gruppe sieht euch an und lacht. denn die verlötet die 1000Füssler auf denen ihr programmiert mit Leichtigkeit.

 

Ach stimmt ... die gibts ja auch noch ^^ ... die landen bei mir im Kopf immer schon in der Rubrik "E-Techniker" ^^.

----------

## Knieper

 *Necoro wrote:*   

> Aber gerade deshalb sehe ich deine Aussage ja kritisch, der halben Informatikwelt (auch der akademischen) vorzuwerfen, sie habe keine Ahnung und sei stümperhaft.

 

Das ist so oder wie erklärst Du Dir sonst die vielen Fehler, die "historisch gewachsenen Programme" und die Unwissenheit der Masse der Programmierer? Das große Problem ist doch, dass man mehr fähige Leute benötigt, als die Gesellschaft und die Ausbildungsgänge hergeben. Man versucht mit OOP, Pattern, Frameworks etc. das Niveau so weit abzusenken, dass auch Quereinsteiger, BAler und FHler halbwegs benutzbare Software schreiben können, mit Informatik hat das aber nichts zu tun. Übertragen auf die Architektur dürfte heutzutage jeder mit einer Schippe Häuser entwerfen, bauen und verkaufen.

 *Quote:*   

> wobei Programmiersprachen eben Handwerkszeug ist

 

Das man nicht sinnvoll einsetzen kann, wenn man nicht weiß, wie es funktioniert.

 *Necoro wrote:*   

>  *Max Steel wrote:*   Und die dritte Gruppe sieht euch an und lacht. denn die verlötet die 1000Füssler auf denen ihr programmiert mit Leichtigkeit. 
> 
> Ach stimmt ... die gibts ja auch noch ^^ ... die landen bei mir im Kopf immer schon in der Rubrik "E-Techniker" ^^.

 

Dafür gibt es doch heute Computer Engineering, obwohl E-Technik, Technische Informatik, Rechnerarchitektur... auch zu den Pflichtveranstaltungen gehörten.

----------

## Necoro

An dieser Stelle klinke ich mich aus. Als jemand, der selber als BAler weiter in die Theoretische Informatik gegangen ist (und daher im Gegensatz zu dir wohl beide Seiten kennt) fühle ich mich von deiner Meinung persönlich beleidigt und sehe keinen Sinn gegen deine Borniertheit anzudiskutieren.

----------

## Knieper

 *Necoro wrote:*   

> (und daher im Gegensatz zu dir wohl beide Seiten kennt)

 

Ich habe denen ab und zu Nachhilfe gegeben und ein Hochschullehrer mit dem ich öfter zu tun habe, lehrt dort nebenbei. FHler trifft man manchmal, allerdings selten, im Berufsleben. Statt Dich auszuklinken, könntest Du mich überzeugen, dass das alles gar nicht so ist und die Ausbildung toll ist, man dort die ganzen Grundlagen lehrt, die nötig sind - wir wissen aber beide, dass dem nicht so ist und nur ganz wenige durch Eigeninitiative brauchbare Arbeit abliefern.

----------

## Necoro

 *Quote:*   

> man dort die ganzen Grundlagen lehrt, die nötig sind

 

Die Diskussion ist deshalb nicht zielführend, weil wir uns nicht einig sind, welche Grundlagen "nötig" sind um praktische Arbeit zu leisten. Dass die theoretische Ausbildung an der BA und FH eine andere ist (und auch die Schwerpunkte anders setzt), bestreitet niemand. Was ich aber bestreite, ist dass die Grundlagen die du forderst (und die ja sogar einen normalen Uni-Kanon übersteigen) zur Verbesserung der Software beitragen. Denn in der Software von heute sind die Aspekte, die mit Formalismen angegangen werden können wohl kaum noch vorhanden und die theoretischen Aspekte des SE sind wichtiger. Sicherlich, manchmal wäre es schon sinnvoller, wenn der Programmierer sieht "Ah - hier brauch ich Dijkstra" anstatt groß rumzuwurschteln. Aber die größere Gefahr geht eher vom Manager aus, der Kraft seiner Wassersuppe verordnet dass ab sofort "agile Programming" gebraucht wird und das System "SOA" und "Cloud" können muss. (Von der Deadline, die von ganz oben gesetzt wird, mal ganz zu schweigen. An der Uni kann man sich eben erlauben, einfach den Part "Future Work" etwas größer zu machen, oder noch n Jahr länger dran zu sitzen.)

(Noch was zum Thema BA: Wir hatten viele Themen nur recht oberflächlich gemacht, ja. Aber dafür wurden fast alle Gebiete der Informatik abgehakt. Dass jemand in Mastervorlesungen sitzt und weder Prolog, noch funktionales Programmieren, noch Datenbanken je gehört hat (häufig genug an der Uni passiert), gäbe es nicht.)

/edit: Noch ein Nachtrag: Was sicherlich eine großer Nachteil der BA ist, sind die teilweise unbrauchbaren Lehrkräfte. Aufgrund der miesen Bezahlung und der mangelnden Unterstützung von den meisten Firmen, gibt es kaum Lehrkräfte, die an einer BA unterrichten wollen. Die müssen da manchmal nehmen wen sie kriegen können -- und der muss nicht unbedingt Ahnung haben. Die hauptamtlichen Professoren dagegen sind meistens (!) sehr gut.

----------

## ChrisJumper

 *Quote:*   

> Du kannst mit einem "Rechner" naturgemäß nichts anderes machen, als rechnen.

 

Nun ich sehe das eher so wie Necro, weil die neue Schicht über der Mathematik viel vielfältiger sein kann. Sicher kann man das alles durch Mathematik erklären, aber die "Informatik" ist es die die Logik impliziert. Sie hat in meinen Augen auch die Mathematik geboren. Bestes Beispiel das Zählen, zuerst muss man die Information verarbeiten und auf eine Idee kommen es so zu handhaben, bevor man sich (der Menschliche Geist im allgemeinen, das Programm das einen Zeit/Raumlosen Geist darstellt) das Gerüst der Mathematik geschaffen hat. Also dem zuweisen eines beliebigen aber gemeinschaftlich standardisierten (Anfangs) Wertes und dies mit einer Logik verknüpfen.

Bevor man diese Werte die man zählen will abstrahieren kann wollen sehr viele Informationen/Signale (z.B. Audiovisuelles) verarbeitet werden bevor sie von Brain 0.1 erstmal geordnet wurden.

Als Mensch kann man das nicht entwirren (Informatik + Mathematik).

----------

## Knieper

 *Necoro wrote:*   

> Was ich aber bestreite, ist dass die Grundlagen die du forderst (und die ja sogar einen normalen Uni-Kanon übersteigen) zur Verbesserung der Software beitragen.

 

Fehlerfreie Software ist also nicht besser - ok... Und weil es so schlecht funktioniert, setzt man es vorwiegend in kritischen Bereichen ein?!

 *Quote:*   

> Denn in der Software von heute sind die Aspekte, die mit Formalismen angegangen werden können wohl kaum noch vorhanden

 

Das sehe ich anders. Einige verbreitete Sprachen machen es dank ihrer beknackten Semantik unnötig schwer, aber wenn es keinen Formalismus gäbe, könnte die Software nicht in ein ausführbares Programm umgewandelt werden.

 *Quote:*   

> und die theoretischen Aspekte des SE sind wichtiger.

 

Könntest Du das näher erläutern? Ich kenne in diesem Bereich nur lächerlichen Modellierungs- und Generierungskram der mehr der Beschäftigung als der Anwendung/Forschung dient.

 *Quote:*   

> Dass jemand in Mastervorlesungen sitzt und weder Prolog, noch funktionales Programmieren, noch Datenbanken je gehört hat (häufig genug an der Uni passiert), gäbe es nicht.)

 

Und wieder: schlechte Uni. Programmierung (FP), Logik (LP) und Datenbanken gehören zu den Pflichtveranstaltungen im Grundstudium, genau wie Betriebssysteme, Rechnernetze, und -architektur usw.. Eine Datenbankenvorlesung an sich ist genau genommen sogar überflüssig, weil in den meisten Fällen nur ein wenig Implementation, Modellierung und SQL gelehrt wird. Die Implementation ist simpel und ähnlich den Prinzipien, die man schon aus den Betriebssystem- und Datenstrukturen/Algorithmen-Vorlesungen kennt, die Modellierung ist dank dem Grundwissen in relationaler Algebra ein Witz und SQL ist nicht mehr als eine angebastelte DSL.

 *ChrisJumper wrote:*   

> weil die neue Schicht über der Mathematik viel vielfältiger sein kann. Sicher kann man das alles durch Mathematik erklären, aber die "Informatik" ist es die die Logik impliziert.

 

Das ist kein Henne-Ei-Problem. Beim Programmieren stellst Du einen Regelsatz auf, der auf einem Rechner abgearbeitet werden soll, mehr nicht. Wenn Du es anders nennst - Dein Problem. Wenn Du die Mathematik dahinter nicht verstehst - auch Dein Problem.

 *Quote:*   

> Als Mensch kann man das nicht entwirren (Informatik + Mathematik).

 

Dann liegt es an der komplexen Problemstellung, hat mit der Umsetzung und dem Programmieren aber nichts zu tun. Ein Rechner kann nicht "probieren", sondern nur Deinem Regelsatz folgen, wie kaputt und unvollständig auch immer der sein mag.

----------

## Necoro

 *Knieper wrote:*   

> Fehlerfreie Software ist also nicht besser

 

Fehlerfreie Software ist in meinen Augen ein Mythos. Keine genügend komplexe Software ist fehlerfrei... (ich meine -- es gibt sogar Bugs in Theorem Provern. Und deren Erschaffern kann man ja das Fehlen des mathematischen Backgrounds nicht wirklich aussprechen...)

----------

## Knieper

 *Necoro wrote:*   

> Fehlerfreie Software ist in meinen Augen ein Mythos.

 

Es gibt viele Projekte die vollständig verifiziert sind.

 *Quote:*   

> Keine genügend komplexe Software ist fehlerfrei...

 

Den dummen Spruch hört man immer nur von Leuten, die nicht wissen wie man Software entwickelt und über Trial-and-Error-OOP nie hinaus gekommen sind.

 *Quote:*   

> (ich meine -- es gibt sogar Bugs in Theorem Provern. [...] Und deren Erschaffern kann man ja das Fehlen des mathematischen Backgrounds nicht wirklich aussprechen...)

 

Absprechen kann man denen aber genügend finanzielle Rückendeckung und eine dichte Personaldecke. Meistens liegen die Fehler auch nur in der Implementation.

----------

## Necoro

 *Knieper wrote:*   

>  *Necoro wrote:*   Fehlerfreie Software ist in meinen Augen ein Mythos. 
> 
> Es gibt viele Projekte die vollständig verifiziert sind.

 

Auch was jenseits der akademischen Spielwiese?

----------

## franzf

 *Knieper wrote:*   

> Meistens liegen die Fehler auch nur in der Implementation.

 

Also in der Unfähigkeit, die theoretisch verifizierten Programme praktisch in Code umzusetzen? Was bringt so eine Software, die theoretisch fehlerfrei sein sollte, dann aber doch nicht das tut was sie soll?

----------

## Knieper

 *Necoro wrote:*   

> Auch was jenseits der akademischen Spielwiese?

 

Dort vorwiegend, an den Unis lohnen sich nur Prestigeprojekte (L4.verified).

 *franzf wrote:*   

> Also in der Unfähigkeit, die theoretisch verifizierten Programme praktisch in Code umzusetzen?

 

Wo steht das denn? Du musst immer Abwägen, an welcher Stelle Du aufhörst. Beim Compiler, bei der Hardware, bei Systemaufrufen oder eben sehr früh in der Kette und eher seltener bei der Implementation. Oft geht man den Weg anders herum, extrahiert aus dem Code ein Modell und verifiziert das.

 *Quote:*   

> Was bringt so eine Software, die theoretisch fehlerfrei sein sollte, dann aber doch nicht das tut was sie soll?

 

Du weißt, dass Dein Algorithmus funktioniert und die Protokolle keine Schwächen aufweisen (Aspier, CryptoVerif, ProVerif). Ob dann noch ein Tippfehler auftaucht, die Semantik einzelner Funktionen missverstanden wurden/sich änderten merkt man dann mit hoher Wahrscheinlichkeit durch Tests, Assertions, symbolische Ausführung oder statische Analyse (Calysto, Frama-C, KLEE, QuickCheck, Slam2).

----------

## EOF

 *Knieper wrote:*   

> Programmieren ist reine Mathematik.

 

 :Question:   :Idea: 

 *Wikipedia wrote:*   

>  [...] Für Mathematik gibt es keine allgemein anerkannte Definition. [...]

 

 :Wink: 

----------

## Erdie

Also wenn Informatik = Mathematik sein soll, dann ist das schon so etwas wie eine Beleidigung für einen guten Mathematiker. Dass Informatik sich massiv mathematischer Methoden bedient, ist unbetritten. Aber die Methoden der Mathematik gehen darüber weit hinaus und reichen bis in den philosophischen Bereich, in dem Sinne würde ich behaupten, die Informatik ist angewandte Mathematik, oder ein Teilgebiet derer. Das bedeutet aber nicht um Umkehrschluß, dass die Informatik reine Mathematik ist.

Ich bin Physiker und für mich ist die Mathematik so etwas wie die Königsdisziplin aller Naturwissenschaften. Sie ist als einzige frei in philosophischem Sinne. Leider zeicgt sie auch immer wieder unsere kognitiven Schranken. Mir ging das leider auch so.

----------

## Knieper

 *Erdie wrote:*   

> Dass Informatik sich massiv mathematischer Methoden bedient, ist unbetritten.

 

Nanana - was Informatiker in den letzten Jahren auf dem Gebiet der diskreten Mathematik, Beweistheorie, Kategorientheorie und speziell Logik geleistet haben, dürfte für keinen Mathematiker eine Beleidigung sein. Im Gegenteil, auf vielen Gebieten wird jetzt erst geforscht, weil den Mathematikern schlicht die Idee für Anwendungen fehlte. Nicht zu vergessen die ganzen neuen praktischen Werkzeuge, die erst dadurch möglich wurden...

 *Quote:*   

> Aber die Methoden der Mathematik gehen darüber weit hinaus und reichen bis in den philosophischen Bereich

 

Auch in der Informatik gibt es Zweige, die nur Mathematik nutzen (zB. Forschung im Bereich Mensch-Maschine-Kommunikation) und weit in den philosophischen bzw. gesellschaftspolitischen Bereich (Sicherheit, Datenschutz...) hinein reichen. Der Kern der Informatik, der sich mit Modellen, Kalkülen, Algorithmen, Typen, Software, Programmierung usw. beschäftigt ist und bleibt reine diskrete Mathematik.

----------

## Knieper

Bei reddit gibt es eine Patent-Diskussion, die ähnliche Argumente enthält: Why software patents are not fixable.

----------

