# Zukunft der Programmierung



## MrWhite (17. Jul 2011)

Ich habe mir heute mal ein paar Gedanken um die Zukunft der Programmierung gemacht. Ich gehe mal davon aus, dass die Hardware auf absehbare Zeit vollkommen abstrahiert wird und in einigen Jahrzehten die kuenstliche Intelligenz das Schreiben der Instruktionen selbst uebernehmen kann.

Man wird wohl aber trotzdem noch eine formale Sprache brauchen, um der KI die Anforderungen zu erklaeren, eine Art Problemdefinitionssprache, bzw. eine Business Rules Definition Language.

Ansaetze dazu gibt es ja mit sogenannten Business Rules Engines und DSLs. Ich frage mich aber, ob man so eine Sprache nicht allgemeingueltig definieren koennte. Also eine Sprache, die einfach Semantiken fuer einen Zielkontext definieren und beschreiben kann, so dass eine "Maschine" spaeter das Konstrukt/Geschaeft versteht und in ein entsprechendes Programm und dessen Instruktionen umsetzen kann.

Was denkt ihr darueber? Welche Vorraussetzungen muesste eine solche Sprache erfuellen? Gibt es irgendwelche triftigen Gruende, die so etwas unmoeglich machen?

Eure Meinungen wuerden mich sehr interessieren.


----------



## schalentier (17. Jul 2011)

Ich glaube, wenn irgendwann eine KI Software schreiben kann, wuerde man der KI auf Englisch oder auch Deutsch die Anforderungen mitteilen koennen... ;-)

Allerdings denke ich nicht, dass das sobald moeglich ist. Immerhin muesste die KI dann kreativ sein koennen - und das ist kaum im aktuellen Jahrhundert realisierbar. Ein passender Vergleich ist vielleicht ein Aufsatz, den meine Mutter in ihrer Schulzeit geschrieben hat: Es ging darum, was so im Jahre 2000 los ist und sie war der Meinung, dass dann Autos fliegen koennen. Damals war das bestimmt vorstellbar, aber naja... davon sind wir noch bissel entfernt 

Es gibt aber dennoch jede Menge interessanter Experimente in diese Richtung. Z.B. hab ich schon mal folgendes ueberlegt: Wenn man TDD (TestDrivenDevelopment) ins Extreme treibt und wirklich vor der ersten Zeile Code alle Anforderungen der Software als Tests vorliegen haette, koennte man z.B. mit einem genetischen Algorithmus quasi zufaelligen Code schreiben lassen, bis alle Tests gruen sind. 

Auch interessant ist Cucumber. Damit kann man mit Natuerlicher Sprache Tests schreiben, so in etwa:


```
Funktionalität: Addition
  Um dumme Fehler zu vermeiden
  möchte ich als Matheidiot
  die Summe zweier Zahlen gesagt bekommen

  Szenariogrundriss: Zwei Zahlen hinzufügen
    Angenommen ich habe <Eingabe_1> in den Taschenrechner eingegeben
    Und ich habe <Eingabe_2> in den Taschenrechner eingegeben
    Wenn ich <Knopf> drücke
    Dann sollte das Ergebniss auf dem Bildschirm <Ausgabe> sein

  Beispiele:
    | Eingabe_1 | Eingabe_2 | Knopf | Ausgabe |
    | 20        | 30        | add   | 50      |
    | 2         | 5         | add   | 7       |
    | 0         | 40        | add   | 40      |
```

Dieses Beispiel kann so wirklich ausgefuehrt werden...

Ich glaube nicht, dass die Sprache das Problem ist, vielmehr ist es die Kreativitaet die notwendig ist, um unvollstaendige Anforderungen (es gibt keine vollstaendigen Anforderungen) trotzdem irgendwie realisieren zu koennen. Sei es durch Ueberlegen, durch Nachfragen beim Kunden oder durch Intuition. 

Ausserdem waere ich dann arbeitslos ;-)


----------



## The_S (18. Jul 2011)

schalentier hat gesagt.:


> Ausserdem waere ich dann arbeitslos ;-)



Nein. Der Job der Entwickler wäre es dann ein solches Problem komplett zu beschreiben (also programmieren  )


----------



## ARadauer (18. Jul 2011)

> in einigen Jahrzehten die kuenstliche Intelligenz das Schreiben der Instruktionen selbst uebernehmen kann.


DAs glaube ich nicht, es gibt immer eine Form der Sprache in der man dem Rechner die Fachlichen Anforderungen beibringen muss. Programmierer wird es noch lange geben. Auch wenn sich die Sprachen weiter entwickeln...


----------



## Landei (18. Jul 2011)

Mein Reinschnuppern in Haskell hat meine Meinung zu dem Thema grundlegend geändert. Seit ich da gesehen habe, was es noch alles an nützlichen Abstraktionen zu entdecken gibt, habe ich wenig Angst um meinen Job. Denn bevor die KI etwas kann, müssen wir es erst einmal können, und da ist das Ende der Fahnenstange noch lange nicht erreicht: Wir wissen noch lange nicht genug über Typsysteme, Datenstrukturen, freie Theoreme, Morphismen u.s.w.


----------



## Sonecc (18. Jul 2011)

schalentier hat gesagt.:


> (...) Es ging darum, was so im Jahre 2000 los ist und sie war der Meinung, dass dann Autos fliegen koennen. Damals war das bestimmt vorstellbar, aber naja... davon sind wir noch bissel entfernt
> (...)



Innovative Technik: Jetzt geht das erste fliegende Auto in Serie - Nachrichten Wissenschaft - WELT ONLINE

Vielleicht nicht das, was deine Mutter sich vorgestellt hat (also im Sinne von den Autos aus I-Robot z.B.), aber dennoch real


----------



## MrWhite (18. Jul 2011)

ARadauer hat gesagt.:


> DAs glaube ich nicht, es gibt immer eine Form der Sprache in der man dem Rechner die Fachlichen Anforderungen beibringen muss. Programmierer wird es noch lange geben. Auch wenn sich die Sprachen weiter entwickeln...



Genau das schreibe ich ja. Ich bin jedoch der Ansicht, dass man in Zukunft keine imperativen Konstrukte mehr verwendet bzw. braucht und auch die Modellbeschreibungen, so wie wir sie heute kennen, hinfällig werden.

Ich denke, dass wir in Zukunft wahrscheinlich nur noch das Problem beschreiben müssen, also den Computer dazu bringen müssen es zu verstehen, sprich ihm die Semantiken und Aufgaben verständlich zu machen. Vollkommen unabhängig von Hardware und APIs, und dass das eigentliche Programm dann quasi generiert wird.


----------



## ice-breaker (18. Jul 2011)

MrWhite hat gesagt.:


> Genau das schreibe ich ja. Ich bin jedoch der Ansicht, dass man in Zukunft keine imperativen Konstrukte mehr verwendet bzw. braucht und auch die Modellbeschreibungen, so wie wir sie heute kennen, hinfällig werden.


100% ack.
In einigen Jahren werden wir dutzende Cores, wenn nicht sogar hunderte haben, die ersten Modelle gibt es ja schon. Der 768Core Java-Server von Azul, oder für den Privatkunden viel relevanter die 480 Core ARM Server von <Name einsetzen>.
Und Many-Core ARM-Desktop-Rechner sind keine große Vision. Windows 8 wird ARM unterstützen. Von da ist es nur noch ein Katzensprung bis eine Firma diese Marktlücke erkennt.

Mit imperativer Programmierung haben wir bei Quads oder Hexacores momentan schon Mühe dieses sinnvoll auszunutzen. Sprachen wie Scala oder Erlang mit trotzdem einen leicht verständlichen Modell hingegen, brechen diese imperative Programmierung oder erlauben daher mühelos dutzende Cores auszulasten - ohne jegliche Arbeit. Funktionale Sprachen haben da glaube ich auch kein Problem.
Meiner Meinung nach werden sich die Sprachen in solch eine Richtung entwickeln, und das in absehbarer Zeit.

Bis Computer anhand unserer Beschreibungen Code produzieren wird noch eine Ewigkeit vergehen, das werde ich nicht mehr erleben. Wer mal Programmcode formal verifiziert hat, der weiß wie schwierig alleine der Nachweis der Korrektheit eines Codes ist.


----------



## Marco13 (18. Jul 2011)

Auf jeden Fall wird der Übergang kein harter Schnitt sein, in dem Sinne dass nicht irgendwann "das perfekte Programmier-Programm" erfunden wird. Der Übergang wird eher fließend sein: Bestimmte Aspekte werden immer weiter abstrahiert und automatisiert. Vermutlich auch erst nur in ganz speziellen Domänen, die dann immer weiter verallgemeinert werden. 

Das angesprochene Beispiel, dass wir ~"in einigen Jahren dutzende oder hunderte von Cores" haben, kommt da schon ein bißchen zu spät. 6-8 cores ist schon nicht ungewöhnlich, und die nutzt man bestenfalls wenn man während des Programmierens/Compilierens noch eine CD brennt und gleichzeitig eine MP3 hört. Mit CUDA oder OpenCL hat man schon >1000 cores, und es ist allgemein antizipiert, dass Moore's Law weiterhin Bestand haben wird, sich aber darin äußern wird, dass sich die Anzahl der _Cores_ alle 18 Monate verdoppelt. 

Deswegen ist das aber ein gutes Beispiel, für einen Bereich, in dem Abstraktion und Automatisierung notwendig sind. Der Übergang von Single- zu Multi- oder Many-Core-Archtekturen erfordert vollkommen neue Programmierparadigmen (und ich glaube, wie _dramatisch_ der Unterschied ist, ist vielen noch gar nicht bewußt...). Gleichzeitig will sich aber fast niemand über low-level-details seiner Hardware Gedanken machen müssen. Stattdessen will man sagen: "Erledige diese Aufgabe, und zwar auf allen Kernen, die du zur Verfügung hast (egal ob das 2 oder 2000 sind)". 

Auf dieser Ebene kann das noch mit Bibliotheken und "Building blocks" abgebildet werden. Damit wird erreicht, dass die (unspezifische) "Schwierigkeit" des Programmierens erstmal _gleich bleibt_ (obwohl sie eigentlich viel komplizierter werden würde - eben wenn man diese Building Blocks NICHT hätte). 

In die andere Richtung, "nach oben" und von der Hardware weg glaube ich, dass auch erst lange Zeit "klassische" Ansätze verwendet werden - also welche, die es heute schon gibt. Zuerst wird vermutlich nur die Granularität der Automatisierbarkeit bzw. automatischen Integrierbarkeit verändert. Zum Beispiel in dem Sinne, dass nicht mehr Abhängigkeiten zu Schnittstellen einzelner Pakete formalisiert werden (duch [c]import package.Interface[/c]) sondern zu Paketen als ganzes (im Sinne eines Mechanismus, der in die Richtung von [c]Require-Bundle: org.eclipse.ui[/c], aber vermutlich noch deutlich darüber hinaus geht).

Nur kontinuierlich werden bestimmte, leicht formalisierbare Abläufe auch automatisiert werden können. Heute denke ich da an Dinge wie JAXB, wo aus Schemadefinitionen ausführbarer Code wird. Dinge wie das EMF decken auch Bereiche der automatischen Codegenerierung aus formalen Modellen heraus ab. Diese Mechanismen werden vermutlich immer intelligenter und mächtiger. Aber dass in den nächsten Jahren jemand ein Programm entwickelt, das Programmierer überflüssig machen könnte, glaube ich nicht.

Und wenn doch, dann... Pschschscht, Code 10-38...!!!!


----------



## SlaterB (18. Jul 2011)

woher kommt der Glaube dass sich irgendwas automatisieren oder KI-ieren lassen wird?
ich sehe die heutige Programmierung in vieler Hinsicht noch nicht wesentlich weiter als Lochkarten von vor 50 Jahren, 
genau wie aktuelle Autos so wie die aller ersten auf dem Boden fahren,
mag sein dass es irgendwann Fortschritte geben wird, aber wie kann man davon ausgehen, dies fest planen?

all die vorhandenen Fortschritte wie höhere Programmiersprachen, nebenläufige Prozesse im Betriebssystem, Kerne und Speicher, das sind doch Nebensächlichkeiten,
wenn es darum geht x*y auszurechnen kann ein moderner PC oder gar eine Wolke auch nicht mehr Wasser kochen als ein Taschenrechner oder ein Hochhaus-Rechner vor langer Zeit

-----

> "Erledige diese Aufgabe, und zwar auf allen Kernen, die du zur Verfügung hast (egal ob das 2 oder 2000 sind)"
sowas stelle ich mir nur schwer vor, entweder sind Dinge trivial oder zu kompliziert für nicht-kreative Rechner,

man denke an manche Java-Flaschenhälse wie String + String in Schleifen oder Puffern für Schreiben in Dateien, Einsatz von ArrayList oder LinkedList,
sowas kann nur ein Mensch als Regeln vorgeben, und das sind ganz allgemeine Dinge, noch nicht mal individuelle Programme, 
ein Computer macht vielleicht alles, wenn er es überhaupt versteht, als eine Art Bruteforce, ob man solch generischen Code im Programm haben will..

wobei nach dem Satz der Code sicher schon vorhanden ist, 
nur irgendwie automatisch zerrissen und die Ergebnisse automatisch zusammengeführt werden sollen?
auch diese kleinere Aufgabe stelle ich mir noch schwer genug vor


----------



## Marco13 (18. Jul 2011)

SlaterB hat gesagt.:


> woher kommt der Glaube dass sich irgendwas automatisieren oder KI-ieren lassen wird?
> ich sehe die heutige Programmierung in vieler Hinsicht noch nicht wesentlich weiter als Lochkarten von vor 50 Jahren,
> genau wie aktuelle Autos so wie die aller ersten auf dem Boden fahren,



In vieler Hinsicht sind Computer und Autos vergleichbar, aber ... gerade in bezug auf diese Punkt IMHO nicht so direkt - Oder zumindest wird das, was ich als Kernfrage dieses Threads ansehe, daran nicht so deutlich: Die Tools mit denen man arbeitet werden immer intelligenter, und die Beschreibungen finden auf immer höherer Ebene statt. 

Wenn man es darauf anlegt: 
- Assembler ist die Sache mit der Kurbel vorne am Motor 
- C ist ein I'er Golf
- Java+IDE ist ein 7er BMW mit Tempomat, Verkehrszeichenerkennung, Navi und HUD
- Aber das selbstfahrende Auto, wo man nur noch das Ziel ins Navi eingibt, und sich dann bequem zurücklehnt, wird es früher oder später sowohl auf der Straße als auch im übertragenen Sinne in der Programmierung geben  Bis dahin kommen aber noch Zwischenschritte, wie z.B. automatische Kolonnenfahrten oder so, und natürlich sind noch viele Fragen zu klären.



SlaterB hat gesagt.:


> > "Erledige diese Aufgabe, und zwar auf allen Kernen, die du zur Verfügung hast (egal ob das 2 oder 2000 sind)"
> sowas stelle ich mir nur schwer vor, entweder sind Dinge trivial oder zu kompliziert für nicht-kreative Rechner,


Nun, das geht schon, mit OpenCL zum Beispiel: Man sagt ihm: "Diese beiden Vektoren sollen addiert werden" und das macht er entweder mit 2 oder mit 1000 Kernen, das hängt von der cl_platform und dem cl_device ab. Aber das ist natürlich (wie schon angedeutet) nur die unterste Ebene - eben die Building blocks. Das hat ja mit Kreativität und Problemlösung nichts zu tun, sondern ist rein mechanisch.

Tatsache ist aber, dass auch die "klassische" KI oft genau dieses Argumentationsproblem hat: Es wird an "künstlicher Intelligenz" geforscht, und am Ende ist das, was rauskommt, ja doch nur irgendein Algorithmus - also AUCH etwas rein mechanisches. Das Ziel in bezug auf die Programmierung ist dann vielleicht, möglichst viel low-level-Wissen in die Tools zu stecken, damit sich der Programmierer auf höherer Ebene mit den Problemen befassen kann. 

Das Beispiel, das du genannt hast, passt da sehr gut:


SlaterB hat gesagt.:


> man denke an [...] Einsatz von ArrayList oder LinkedList,
> sowas kann nur ein Mensch als Regeln vorgeben, und das sind ganz allgemeine Dinge, noch nicht mal individuelle Programme,


Diese Vorgabe von Regeln wäre ja schon ein nächster Schritt: Wenn es nun eine Möglichkeit gäbe, zu beschreiben, was man mit dieser 'List' machen will, könnte man darauf basierend ja Entscheidungen treffen - wie ein Mensch auch. Wenn man sagt: "Ich brauche oft 'addFirst' und 'removeFirst'", dann ist es eine LinkedList, und wenn man sagt "Ich brauche oft 'get(i)' dann ist es eine ArrayList. Das könnte auf rein formalen Kriterien (eben die Komplexität im Sinn der O-Notation) basieren. Die nächsthöhere Stufe könnte dann z.B. sein, dass man nur noch sagt: "Ich brauche eine sortierte Liste", und dder Computer dann erkennt, dass er "sort" aufrufen muss, und dafür wegen der vielen 'get(i)' eine ArrayList am besten wäre - oder vielleicht doch ein TreeSet, wenn oft sortiert eingefügt werden muss...?

Es gibt schon einige Ansätze, um _Das Programmieren_ auf eine höhere Ebene zu ziehen. Dass wir immernoch auf Lochkarten-Niveau Code hinhacken hat vielleicht damit zu tun... dass... Programmierer sehr konservativ sind (oder? Es klingt widersprüchlich, aber ... COBOL lebt!  ). 

Ich verfolge das nicht in aller Tiefe, aber da wird schon intensiv geforscht. Zwei Dinge, über die ich mal zufällig gestolpert war (und das ist auch schon lange her!), und die, wie ich finde, SEHR interessant aussehen, waren z.B.
Code Bubbles Project: Rethinking the User Interface Paradigm of Integrated Development Environments
oder sowas wie
Natural Programming


----------

