Forschung und offene Herausforderungen in der Theorie der Programmiersprache

Im Geiste einiger allgemeiner Diskussionen wie dieser eröffne ich diesen Thread mit der Absicht, Meinungen zu den offenen Herausforderungen und aktuellen Themen der Programmiersprachenforschung zu sammeln . Ich hoffe, dass die Diskussion sogar Meinungen über die Zukunft der Forschung in Programmiersprachen zum Vorschein bringt.

Ich glaube, dass diese Art der Diskussion neuen studentischen Forschern wie mir, die sich für PL interessieren, sowie jenen helfen wird, die bereits ein wenig involviert sind.

Meines Erachtens besteht das übergeordnete Ziel der PL-Theorie darin, die Kosten für die groß angelegte Programmierung durch die Verbesserung der Programmiersprachen und des technischen Ökosystems, in dem Sprachen verwendet werden, zu senken.

Hier einige hochrangige, etwas vage Beschreibungen von PL-Forschungsgebieten, die anhaltende Aufmerksamkeit erhalten haben und dies wahrscheinlich noch eine Weile tun werden.

• Die meiste Programmiersprachenforschung wurde im Rahmen der sequentiellen Berechnung durchgeführt, und inzwischen haben wir uns wohl auf einen Kern von Merkmalen geeinigt, die in den meisten modernen Programmiersprachen verfügbar sind (z. B. Funktionen höherer Ordnung, (partielle) Typinferenz, Musterabgleich) , ADTs, parametrischer Polymorphismus) und sind gut verstanden. Es gibt noch keinen solchen Konsens über Programmiersprachenmerkmale für die gleichzeitige und parallele Berechnung.

• In Bezug auf den vorherigen Punkt hat das Forschungsgebiet der Typisierungssysteme festgestellt, dass sich der größte Teil seiner Tätigkeit mit sequentieller Berechnung befasst. Können wir diese Arbeit verallgemeinern, um nach nachvollziehbaren und nützlichen Typisierungsdisziplinen zu suchen, die die gleichzeitige und parallele Berechnung einschränken?

• Als Sonderfall des vorangegangenen Punktes bezieht sich die Curry-Howard-Korrespondenz auf strukturelle Beweistheorie und funktionale Programmierung, was zu einem nachhaltigen Technologietransfer zwischen Informatik und (Grundlagen der) Mathematik führt, wobei beispielsweise die Homotopietypentheorie ein eindrucksvolles Beispiel ist. Es gibt viele verlockende Hinweise, die auf (einige Formen von) gleichzeitigen und parallelen Berechnungen ausgedehnt werden können.

• Die Spezifikation und Verifizierung von Programmen ist in den letzten Jahren viel weiter fortgeschritten, z. B. mit interaktiven Proof-Assistenten wie Isabelle und Coq. Die Technologie ist jedoch noch weit davon entfernt, im alltäglichen Programmieralltag in großem Maßstab einsetzbar zu sein. Es bleibt noch viel zu tun, um diesen Zustand zu verbessern.

• Programmiersprachen und Verifikationstechnologien für neuartige Berechnungsformen. Ich
  denke hier insbesondere an die Quantenberechnung und die biologisch inspirierten Rechenmechanismen, siehe zB hier .

• Vereinigung. Es gibt viele Ansätze für Programmiersprachen, -typen und -prüfungen, und man hat manchmal das Gefühl, dass es viele Überschneidungen zwischen ihnen gibt und dass ein abstrakterer Ansatz darauf wartet, entdeckt zu werden. Insbesondere biologisch inspirierte Rechenmechanismen werden uns wahrscheinlich weiterhin überfordern.

Ein Problem der PL-Forschung ist, dass es keine eindeutigen offenen Probleme wie die P / NP-Frage gibt, bei denen wir sofort sagen können, ob eine vorgeschlagene Lösung funktioniert oder nicht.

Lassen Sie mich einige Annahmen auflisten, die die Programmiersprachenforschung einschränken. Es ist schwer, sich von diesen zu lösen, weil sie einen wesentlichen Teil der Programmiersprachen ausmachen oder weil das Erforschen von Alternativen "kein Programmiersprachendesign mehr" wäre. Mit jeder Annahme liste ich ihre einschränkenden Wirkungen auf.

1. Programme sind syntaktische Konstrukte.

   • Echte Programmierer würden niemals iPads zum Erstellen von Quellcode verwenden. Und selbst wenn, könnten sie niemals so effizient sein wie mit Emacs, Eclipse, NetBeans, XCode usw.
   • Die Erforschung alternativer Formen der Programmerstellung ist nicht das Design von Programmiersprachen, sondern das Design von grafischen Benutzeroberflächen oder die Ausbildung (vgl. Scratch).

2. Ein teilweise geschriebenes Programm kann nicht ausgeführt werden.

   • Zumindest tritt ein Laufzeitfehler auf, wenn die Ausführung zu einem fehlenden Teil gelangt.
   • Was nützt es, unvollendete Programme auszuführen?

3. Programme geben Anweisungen an Computer.

   • Das Design von Programmiersprachen hat nichts darüber zu sagen, wie man Gesetze schreibt und organisiert. Geräte.
   • Bakterien schreiben keine Programme.

4. Das Programmieren ist wie das Entwickeln und kann nicht von gewöhnlichen Leuten durchgeführt werden.

   • Gewöhnliche Menschen kennen die Syntax, die Konzepte und die Werkzeuge nicht und können daher möglicherweise keine Programme schreiben.
   • Selbst wenn wir versuchen, es normalen Menschen zu ermöglichen, Programme zu schreiben, werden sie nur Triviales schreiben können.

Ich denke, ich könnte weitermachen.

Es gibt ein Problem, über das ich mich gewundert habe. Ich habe keine Ahnung, ob es sich um eine offene Herausforderung handelt.

Das mathematische Wissen hat mit der Zeit stetig zugenommen. Die theoretischen Grundlagen, Konzepte, Notationen und Beweise haben sich im Laufe der Jahrhunderte entwickelt. Mathematiker haben die Aggregation verwaltet, ohne zu jedem Zeitpunkt systematisch und formal die globale Konsistenz zu überprüfen (obwohl es Versuche gab, dies zu tun).

Es ist zu erwarten, dass sich Programmiersprachen und Programmbibliotheken im Laufe der Zeit ähnlich aggregieren und weiterentwickeln. Mit welchen Tools kann die Aggregation von Programmierergebnissen und Bibliotheken verwaltet werden, um sie konsistent zu halten und für alle effektiv nutzbar zu machen, da Computer formeller und in Bezug auf Konsistenz anspruchsvoller sein können. Müssen wir die Bibliotheken für jede neue Programmiersprache wiederholen? Warum sollten wir eine Sprache wählen müssen, weil sie die richtigen Bibliotheken für die beabsichtigte Anwendung hat und nicht für ihre eigentümlichen Eigenschaften als Programmiermedium?

Zu einem anderen Thema finden Sie möglicherweise Ideen in der folgenden Frage: Werden Programmiersprachen mehr wie natürliche Sprachen? Mir ist klar, dass die Idee viele theoretische Informatiker vielleicht nicht anspricht, aber dennoch nützlich sein kann, wenn man sich mit verschiedenen Themen oder aus einer anderen Perspektive befasst. Ich bin weit davon entfernt, vielen der veröffentlichten Ideen zuzustimmen, aber dafür ist die Diskussion gedacht.

Während des letzten Jahrhunderts gab es eine enorme Innovation und Explosion in Programmiersprachen von angewandter und theoretischer Seite. Es könnte jedoch der Fall sein, dass dies ein einzigartiges / einmaliges Ereignis in der Geschichte des Rechnens ist, ähnlich einer "evolutionären Explosion". (siehe auch "warum gibt es so viele programmiersprachen?" auf cs.se) und dass die zukunft in dieser hinsicht nicht wie in der vergangenheit sein wird. Es gibt jedoch einige erkennbare langfristige aktuelle Trends im Spiel / in der Entwicklung.

• Programmier- / Softwarekomplexität und Möglichkeiten zum Verwalten / Minimieren / Reduzieren / Reduzieren ist ein Thema, das das Sprachdesign schon immer beeinflusst hat und in der heutigen Zeit mit sehr großen / komplexen Softwaresystemen möglicherweise noch wichtiger ist. Es war ein wesentlicher Aspekt des OOP-Entwurfs, aber jetzt haben wir hochkomplexe OOP-Systeme! Das gezielte Nachdenken darüber hat zu Klassikern auf diesem Gebiet geführt, wie Mythical Man-Month von Brooks, was in vielerlei Hinsicht immer noch eine sehr gültige Perspektive ist, möglicherweise sogar relevanter als zu der Zeit, als es geschrieben wurde.

• Parallelität. Die Hardware verlagert sich in Richtung größerer Parallelität (z. B. Multicore usw.), und Taktratenerhöhungen reichen nicht mehr aus, um die Leistung zu steigern. Diese Verschiebung geschah um die Mitte der 2000er Jahre und hat einen großen Einfluss auf die Sprachforschung / -gestaltung. Parallelität war immer ein Thema, hat aber einen neuen Stellenwert / eine neue Dringlichkeit, und es gibt einige weit verbreitete Meinungen / Einigkeit darüber, dass Parallelität übermäßig kompliziert und schwierig in der Programmierung ist und möglicherweise verschiedene theoretische Ansätze dies abmildern könnten. ein netter Hinweis dazu: Die Landschaft des Parallel Computing Research: Ein Blick von Berkeley

• Datenerfassung / Big Data . diese beeinflussen das Design der Programmiersprache. Auch neue Richtungen in der Datenbankarchitektur beeinflussen die Programmiersprachen.

• Supercomputing hat einen erheblichen Einfluss auf das Sprachdesign und überschneidet sich auch mit Parallelität und Datenverarbeitung / Big Data, z. B. mit neuen Sprachen wie MapReduce .

• visuelle / Datenflussprogrammierung . Es hat eine Zunahme dieser Arten von "Sprachen" gegeben (in gewisser Weise ist visuelle Programmierung in vielerlei Hinsicht eine Entkopplung der Programmierung von "Sprachen"). auch starke Fremdbestäubung mit Parallelität.

• AI . Dies ist eher eine weit verbreitete Wildcard und es ist derzeit nicht ganz klar, wie sie sich auf die Computersprachen und die Programmierung auswirken wird, aber wahrscheinlich wird sie sehr umfangreich sein. in der vergangenheit [in einer anderen form] führte es zu ganzen sprachen wie prolog . Ein frühzeitiger Hinweis darauf, wie es mit bemerkenswerten Ergebnissen angewendet werden kann, ist Genetische Algorithmen / Genetische Programmierung .

Eine Referenz, die einige hilfreiche Ideen im Sinne der "Zukunft der Programmiersprachen" Beyond Java von Tate enthalten könnte. Er denkt (wenn auch kontrovers) darüber nach, dass Java (wahrscheinlich eine der komplexesten / umfassendsten Programmiersprachen, die es gibt) langsam in die Jahre gekommen ist und es erste Anzeichen für neue Sprachen / Ansätze gibt, die seinen Platz auf lange Sicht einnehmen.