Die Menschheit versucht bereits seit 70 Jahren, KI dazu zu bringen, an ihrer Stelle Code zu schreiben.
Die Theorie der Verdrängung durch die allgegenwärtige KI-Programmierung ist unablässig zu hören, aber wenn man den Zeitverlauf länger betrachtet, stellt sich heraus, dass die Menschheit bereits siebzig Jahre lang versucht, KI für das Schreiben von Code einzusetzen. 1952 wollte Hopper, dass Programmierer „wieder zu Mathematikern werden“; in den 1980er Jahren sagte der „Lehrling des Programmierers“ am MIT genau das heutige KI-Paar-Programmieren voraus; in den 1990er Jahren versuchte Microsofts „Intentionelle Programmierung“ sogar, Quellcode-Textdateien zu beseitigen – jedes Mal glaubten die Pioniere, „dieses Mal wird es klappen“, und jedes Mal gab die Realität eine komplexere Antwort.
Lehrer Zou Xin zerlegt in der 4. Ausgabe des Buches Gesetze des Aufbaus (Abschnitt 11.3) nacheinander die Aufstieg- und Niedergangslogik von fünf KI-gestützten Programmierparadigmen. Nachdem Sie diesen siebzigjährigen Verlauf gelesen haben, erhalten Sie etwas Wertvolleres als die Frage „Sollte man Angst haben?“: Urteilskraft. Erkennen Sie die tatsächliche Reichweite dieser aktuellen Kugel und wo genau Ihr Platz als Ingenieur liegt.
Der folgende Text ist aus Abschnitt 3 von Kapitel 11 von Zou Xin entnommen und wird von CSDN mit Genehmigung veröffentlicht.
Um das „Heute“ und „Morgen“ der KI-Programmierung zu verstehen, müssen wir ihr „Gestern“ kennen. Dieser Artikel blickt tief auf mehrere wichtige historische Knotenpunkte zurück, analysiert die Erfahrungen und Lehren aus verschiedenen technischen Durchbrüchen und enthüllt das Wesen der aktuellen technischen Welle. Die Unterstützung oder sogar Automatisierung aller Phasen der Programmierung durch Werkzeuge war schon immer das zentrale Bestreben von Software-Ingenieuren und Informatikern. In jeder Epoche entstanden neue Technologien, auf die große Hoffnungen gesetzt wurden, die aber auch mit vielen Blasen einhergingen.
Um den Lesern beim Aufbau eines klaren Wissensrahmens zu helfen, fasst Tabelle 1 fünf wichtige KI-gestützte Programmierparadigmen zusammen und vergleicht sie aus Dimensionen wie Kernzielen, Schlüsseltechnologien, Darstellungsweisen von Code, Entwicklung der menschlichen Rolle und Haupteinschränkungen.
Tabelle 1: Fünf wichtige KI-gestützte Programmierparadigmen
01
Die Genesis der Automatisierung – Der Traum des Symbolismus
Maschinen, die schlussfolgern können
In der Anfangsphase der Entwicklung von Computersoftware waren sich die Wissenschaftler einig: Da Programme im Wesentlichen eine Reihe logischer Operationen auf Daten durchführen, sollte dieser Prozess mathematisch nachweisbar und automatisierbar sein. Diese Idee fand ihren konzentrierten Ausdruck auf der Dartmouth-Konferenz 1956. Diese Konferenz etablierte nicht nur offiziell die Disziplin „Künstliche Intelligenz“, sondern klärte auch ihre Kernvision. Der Konferenzvorschlag wagte die Vermutung: „Jeder Aspekt des Lernens oder jedes andere Merkmal der Intelligenz kann prinzipiell so genau beschrieben werden, dass eine Maschine ihn simulieren kann.“
Unter dieser großartigen Blaupause war „automatische Programmierung“ kein isoliertes technisches Problem, sondern eine unvermeidliche Folgerung der gesamten Vision. Die Vorstellungen der Pioniere zu dieser Zeit gingen weit über heutige Compiler hinaus. Sie wollten den gesamten Denkprozess menschlicher Programmierer von der Problemanalyse bis zur Codeerstellung simulieren. Diese Vision definierte die automatische Programmierung als ein zentrales KI-Problem über Wissen, Abstraktion und Formalisierung, und das vorherrschende Paradigma zu seiner Lösung war die symbolische KI (Symbolic AI). Ihr zentrales Glaubensbekenntnis lautet: Intelligenz entsteht durch logische Operationen auf Symbolen, die auf einer Reihe explizit kodierten Wissens und Regeln basieren.
Die Vision war zwar großartig, aber die Hardware zu dieser Zeit war noch sehr primitiv. In den 1950er und 1960er Jahren war die Programmierung äußerst mühsam: Programmierer mussten Code schreiben, indem sie Löcher in Karten stanzen, und dann Stapel von Lochkarten in den Computer laden. Der Arbeitsspeicher von Computern war extrem knapp und teuer, und es gab keine interaktive Rechenumgebung. Die umsetzbare Vision der „automatischen Programmierung“ zu dieser Zeit bedeutete „Programmieren auf eine Weise, die näher an der natürlichen Sprache oder dem menschlichen mathematischen Ausdruck liegt als die Maschinensprache“. Dies war der erste Schritt menschlicher Programmierer zu einer höheren Abstraktion von Maschinenbefehlen. Diese Herausforderung wurde von COBOL (Common Business-Oriented Language) bzw. FORTRAN gelöst.
Grace Hopper war eine wichtige Pionierin auf diesem Gebiet. Ihre Arbeit am UNIVAC I-Computer legte die praktische Grundlage für die „automatische Programmierung“.
- In ihrem bahnbrechenden Aufsatz Die Bildung des Computers (1952) erläuterte Hopper ihre großartige Vision der Automatisierung der Programmierung. Sie schlug das Konzept der schichtweisen Operation vor, das darauf abzielt, die Menschen schrittweise von der mühsamen Programmierarbeit zu befreien. Sie stellte sich vor, dass der „Bildungsprozess“ des Computers von der Ausführung grundlegender Maschinenbefehle über das Verstehen und Aufrufen von Unterprogrammbibliotheken bis hin zu symbolischen Operationen wie der automatischen Ableitung reicht. Die Kernphilosophie dieses Aufsatzes besteht darin, dass durch ständige Erhöhung des Abstraktionsgrades Programmierer „wieder zu Mathematikern werden“ können und sich auf das Problem selbst statt auf die Details der Maschine konzentrieren.
- COBOL: Hoppers Arbeit beschränkte sich nicht auf wissenschaftliches Rechnen. Sie war überzeugt, dass Computerprogramme auf Englisch geschrieben werden können, sodass auch Personen ohne mathematischen Hintergrund Computer nutzen können, insbesondere für kommerzielle Anwendungen. Durch die kontinuierliche Arbeit vieler Entwickler entstand COBOL, das in den folgenden Jahrzehnten den Bereich der kommerziellen Softwareentwicklung dominierte.
John Backus und FORTRAN
Wenn Hoppers Arbeit die Tür zur Automatisierung der kommerziellen Datenverarbeitung öffnete, dann definierte John Backus und sein Team bei IBM durch FORTRAN die Zukunft des wissenschaftlichen Rechnens.
- Backus gestand einmal, dass sein Motiv für die Entwicklung von FORTRAN aus „Faulheit“ stammte, weil er der mühsamen und fehleranfälligen Arbeit überdrüssig war, Assemblersprachen für verschiedene Großrechner von IBM zu schreiben.
- FORTRAN (1957): Als erster optimierender Compiler der Welt brach FORTRAN (Formelübersetzung) das damalige Vorurteil, dass Maschinencode nicht so effizient sei wie handgeschriebener Assembler. Es erzeugte erfolgreich effiziente Programme, die mit dem von Experten handgeschriebenen Code mithalten konnten, und reduzierte den Arbeitsaufwand für das Schreiben von Anweisungen auf ein Zwanzigstel des ursprünglichen Werts, wodurch es schnell breite Anerkennung in Wissenschaft und Ingenieurwesen gewann.
Zeitlicher Hintergrund und Einschränkungen
Das Aufkommen von Hochsprachen und Compilern war zweifellos eine Revolution. Diese Revolution offenbarte aber von Anfang an auch zwei grundlegende Widersprüche im Software-Engineering, die uns bis heute beeinflussen.
Erstens entstand das Abwägungsverhältnis zwischen Abstraktion und Leistung. Das Kernziel von Hochsprachen ist Abstraktion – die komplexen Details der Maschine zu verbergen, damit Programmierer auf eine Weise arbeiten können, die dem menschlichen Denken näher kommt. Diese Abstraktion ist aber nicht kostenlos, und frühe Programmierer zweifelten stark an ihrer Leistungsfähigkeit. FORTRAN bewies durch seine Optimierungsfähigkeit, dass hochgradige Abstraktion mit hoher Leistung einhergehen kann. Dies begründete ein grundlegendes Gesetz für die Anwendung von Programmiersprachen und Softwarewerkzeugen: Entwickler streben nach höherer Abstraktion, akzeptieren diese aber nur, wenn die Leistung akzeptabel ist. Dieses Gesetz wurde im Aufstieg und Niedergang späterer CASE-Werkzeuge, 4GL (Vierte Generation von Sprachen) und sogar früher interpretierter Sprachen wiederholt bestätigt.
Zweitens bildeten sich zwei völlig unterschiedliche Programmierkulturen heraus. FORTRAN verwendet algebraische Symbole und ist für wissenschaftliche und technische Berechnungen konzipiert, seine Zielgruppe sind Wissenschaftler und Ingenieure. COBOL hingegen verwendet englischähnliche Syntax, um kommerzielle Daten zu verarbeiten, seine Zielgruppe sind Geschäftsanalytiker. Diese beiden Sprachen spiegeln die Trennung zweier Philosophien wider: Sie richten sich an unterschiedliche Märkte, laufen auf unterschiedlicher Hardware und bringen ihre eigenen unabhängigen Ökosysteme aus Werkzeugen, Experten und Kulturen hervor – „Wissenschaftliches Rechnen“ und „Datenverarbeitung“. Diese Trennung hielt mehr als ein Jahrzehnt an, bis sie durch den Aufkommen allgemeiner Programmiersprachen wie C allmählich überbrückt wurde.
02
Die Industrialisierung der Software: Aufstieg und Niedergang von CASE
„Softwarekrise“ und der Ruf nach Ingenieurdisziplin: Software-Engineering
Mit der Verbreitung von Computeranwendungen und der rasanten Zunahme des Umfangs von Softwaresystemen erlebte die Softwareentwicklung Ende der 1960er und in den 1970er Jahren schwere „Wachstumsschmerzen“. Projekte litten allgemein unter Verspätungen, Budgetüberschreitungen und schlechter Qualität, ein Phänomen, das als „Softwarekrise“ bezeichnet wird. Um dieser Herausforderung zu begegnen, tauchte der Begriff „Software-Engineering“ 1968 offiziell in der akademischen Welt auf. Seine Kernidee besteht darin, die Prinzipien traditioneller Ingenieurdisziplinen zu übernehmen, um strengere, vorhersehbarere und systematisiertere Managementmethoden für die Softwareentwicklung einzuführen. Dieses Streben nach Ingenieurdisziplin legte die ideelle Grundlage für die Entstehung einer neuen Art von Werkzeugen.
Das Versprechen von CASE: Computer Aided Software Engineering
Die Kernvision von CASE (Computer-Aided Software Engineering) besteht darin, den gesamten Lebenszyklus der Softwareentwicklung – von der anfänglichen Anforderungsanalyse bis zur endgültigen Systemwartung – durch Computer zu automatisieren und zu integrieren. Sein Ziel ist es, durch Automatisierung die Entwicklungszeit zu verkürzen, die Kosten zu senken und die Softwarequalität zu verbessern. Diese Idee wurde stark von den CAD-Werkzeugen (Computer-Aided Design) für den Hardwareentwurf inspiriert.
Eine typische integrierte CASE-Umgebung besteht aus folgenden Schlüsselkomponenten.
- Oberes CASE und unteres CASE: Diese Klassifizierung spiegelt die unterschiedliche Positionierung der Werkzeuge im Lebenszyklus der Softwareentwicklung wider. Obere CASE-Werkzeuge konzentrieren sich auf die frühen, abstrakten Phasen wie Anforderungsanalyse und Systemdesign. Sie bieten grafische Modellierungswerkzeuge, die Methoden wie Datenflussdiagramme (DFD), Entity-Relationship-Diagramme (ERD) und Strukturdiagramme unterstützen. Untere CASE-Werkzeuge hingegen konzentrieren sich auf die späteren konkreten Implementierungsphasen wie automatische Codegenerierung, Debuggen, Testen und Reverse Engineering.
- Zentrales Repository: Es ist der technische Kern der CASE-Umgebung. Es handelt sich um eine zentrale Datenbank oder ein Datenwörterbuch, das alle Artefakte während des gesamten Projektentwicklungsprozesses speichert, einschließlich Diagrammen, Datendefinitionen, Bildschirmlayouts, Geschäftslogik usw. Dieses Repository soll die Konsistenz aller Entwicklungsaktivitäten sicherstellen und eine „einzelne Quelle der Wahrheit“ bereitstellen.
Die späten 1980er und frühen 1990er Jahre waren die Blütezeit der CASE-Werkzeuge. Auf dem Markt tauchten zahlreiche Produkte auf, und große Softwareunternehmen wollten ausgehend von CASE-Werkzeugen ein einheitliches Entwicklungsumfeld aufbauen, das den gesamten Lebenszyklus abdeckt.
Der Codegenerierungsassistent von Microsoft Visual Studio (siehe Abbildung unten) ist auch einer der wenigen Erfolgsfälle dieser Idee der „automatischen Codegenerierung“. Er hat das Grundgerüst der meisten Windows-Anwendungen erfolgreich aufgebaut und die Hürden für Entwickler erheblich gesenkt, komplexe Frameworks wie Anwendungen zur Verarbeitung mehrfenstriger Dokumente zu erlernen.
Mit MFC AppWizard können Programmierer bequem verschiedene Desktop-Anwendungen konfigurieren und automatisch ausführbaren Code des Grundgerüsts generieren
Unerfülltes Versprechen: Kritische Reflexion über CASE
Obwohl die Vision von CASE großartig war, erzielte sie in der Praxis nicht den erwarteten Erfolg und begann Mitte der