Warum gibt es so viele Programmiersprachen?

Ich beherrsche C / C ++ ziemlich fließend und kann mich in den verschiedenen Skriptsprachen (awk / sed / perl) zurechtfinden. Ich habe viel mehr mit Python angefangen, weil es einige der raffinierten Aspekte von C ++ mit den Skriptfunktionen von awk / sed / perl kombiniert.

Aber warum gibt es so viele verschiedene Programmiersprachen? Ich vermute, all diese Sprachen können das Gleiche tun. Warum also nicht einfach an einer Sprache festhalten und diese zum Programmieren von Computern verwenden? Insbesondere ist es aus irgendeinem Grund ich sollte eine funktionale Sprache als Computer - Programmierer wissen?

Einige verwandte Lektüre:

• Warum sind neue Programmiersprachen erfolgreich - oder scheitern?
• Gibt es noch Forschungsbedarf in Programmiersprachen?

Programmiersprachen entwickeln sich und werden mit der Zeit verbessert (Innovation).

Menschen nehmen Ideen aus verschiedenen Sprachen auf und kombinieren sie zu neuen Sprachen. Einige Funktionen wurden verbessert (Vererbungsmechanismen, Typensysteme), andere hinzugefügt (Speicherbereinigung, Ausnahmebehandlung), andere entfernt ( gotoAnweisungen, Zeiger-Manipulationen auf niedriger Ebene).

Programmierer verwenden eine Sprache auf eine bestimmte Art und Weise, die von keinem Sprachkonstrukt unterstützt wird. Sprachdesigner identifizieren solche Verwendungsmuster und führen neue Abstraktionen / Sprachkonstrukte ein, um solche Verwendungsmuster zu unterstützen. In der Assemblersprache gab es keine Verfahren. Keine Klassen in C. Keine Ausnahmebehandlung in (frühem) C ++. Keine sichere Möglichkeit, neue Module in frühen Sprachen zu laden (einfach in Java). Keine eingebauten Threads (easy-peasy in Java).

Forscher überlegen sich alternative Möglichkeiten, um Berechnungen auszudrücken. Dies führte unter anderem zu Lisp und dem funktionalen Sprachzweig des Sprachbaums, Prolog und dem logischen Programmierzweig, Erlang und anderen akteurbasierten Programmiermodellen.

Im Laufe der Zeit lernen Sprachdesigner / -forscher all diese Konstrukte und ihre Interaktion besser zu verstehen und entwerfen Sprachen, um viele der gängigen Konstrukte einzubeziehen, die alle so konzipiert sind, dass sie nahtlos zusammenarbeiten. Das Ergebnis sind wunderbare Sprachen wie Scala, die Objekte und Klassen (ausgedrückt durch Merkmale anstelle von Einzel- oder Mehrfachvererbung), funktionale Programmierfunktionen, algebraische Datentypen, die gut in das Klassensystem und den Mustervergleich integriert sind, und akteurbasierte Parallelität enthalten.

Forscher, die an statische Typsysteme glauben, sind bestrebt, ihre Ausdrucksfähigkeit zu verbessern, indem sie Dinge wie typisierte generische Klassen in Java (und all die wunderbaren Dinge in Haskell) zulassen, damit ein Programmierer mehr Garantien erhält, bevor er ein Programm ausführt, dass die Dinge nicht funktionieren schief gehen. Statische Typsysteme stellen für den Programmierer häufig eine große Belastung dar (Eingabe der Typen), weshalb diese Belastung durch Untersuchungen gemildert wurde. Sprachen wie Haskell und ML ermöglichen es dem Programmierer, alle Typanmerkungen wegzulassen (es sei denn, sie tun etwas Schwieriges). Mit Scala kann der Programmierer die Typen im Methodenbestand weglassen, um die Arbeit des Programmierers zu vereinfachen. Der Compiler fügt alle fehlenden Typen ein und informiert den Programmierer über mögliche Fehler.

Schließlich unterstützen einige Sprachen bestimmte Domänen. Beispiele hierfür sind SQL, R, Makefiles, die Graphviz-Eingabesprache, Mathmatica und LaTeX. Das Integrieren der Funktionen dieser Sprachen in Mehrzwecksprachen (direkt) wäre ziemlich umständlich. Diese Sprachen basieren auf Abstraktionen, die für ihre jeweilige Domäne spezifisch sind.

Ohne die Weiterentwicklung des Entwurfs von Programmiersprachen würden wir alle weiterhin Assembler oder C ++ verwenden.

Was die Kenntnis einer funktionalen Programmiersprache angeht : Mit funktionalen Sprachen können Sie Berechnungen anders ausdrücken, häufig präziser als mit anderen Programmiersprachen. Betrachten Sie den Unterschied zwischen C ++ und Python und multiplizieren Sie ihn mit 4. Wie bereits in einer anderen Antwort erwähnt, gibt Ihnen die funktionale Programmierung eine andere Denkweise bei Problemen. Dies gilt für alle anderen Paradigmen; Einige sind besser für einige Probleme geeignet, andere nicht. Dies ist der Grund, warum Sprachen mit mehreren Paradigmen immer beliebter werden: Sie können Konstrukte aus einem anderen Paradigma verwenden, ohne die Sprache zu ändern, und schwieriger, Paradigmen in einer Software zu mischen.

tldr: Es gibt keine Silver Bullet-Sprache.

Ich hoffe, sie werden mich nicht verklagen, aber hier ist ein Bild von einer der Stanford-Präsentationen.

Wenn Sie sich für eine Sprache entscheiden, können Sie nur zwei dieser drei Funktionen auswählen .

Und deshalb sind die Leute traurig und wollen eine Super-Sprache erfinden, die alle drei abdeckt.

Tatsächlich gibt es eine riesige Liste von Anforderungen (einige von ihnen können Sie in anderen Antworten sehen), aber sie fügen nur Details zu den Kernfunktionen hinzu. Darüber hinaus gibt es historische und politische Gründe, eine Sprache einer anderen vorzuziehen.

Kombinationen solcher Faktoren ergeben eine neue Sprache.

( Und ich habe gehört, dass jeder gute Programmierer seine eigene neue Sprache schreiben sollte;) )

Die Welt ist gefüllt mit Dingen, die viele verschiedene Variationen haben: Textverarbeitungsprogramme, Autos, Haushaltsdesigns, Getränke, Süßigkeiten, Stifte, Schaufeln usw. Die Gründe, warum wir so viele haben, lassen sich auf ein paar Prinzipien zusammenfassen:

• Jemand glaubt, sie könnten bestehende Produkte verbessern
• Ein anderes Design ist aufgrund lokaler Überlegungen erforderlich (denken Sie: Häuser auf Stelzen oder Häuser auf Betonplatten).
• Eine neue Produktkategorie deckt einen Bedarf ab, der zuvor noch nicht bestand

Gehen Sie in ein Geschäft für Bürobedarf und sehen Sie sich den Abschnitt "Schreibgeräte" an - es gibt Hunderte von Stiftsorten. Sie alle machen ungefähr dasselbe: Tinte auf eine Schreibfläche bringen. Aber jeder Stift, den Sie zum Verkauf sehen, ist da, weil einer der drei oben genannten Gründe.

• Patronenfüllfederhalter sind eine Verbesserung gegenüber getauchten Füllfederhaltern, die selbst eine Verbesserung gegenüber Federkielen darstellen.
• Die NASA brauchte einen Stift, der ohne die Schwerkraft schreiben konnte, also wurde der Druck-Tintenroller erfunden.
• Der allererste Stift selbst könnte ein in Teer oder Blut getauchter, spitzer Stock gewesen sein. Zuvor haben die Leute Steine ​​zusammengekratzt oder Pigmente mit Fell auf die Wände gestrichen. (Nur eine Vermutung.)

Die Entwicklung der Stifte wird fortgesetzt, da kein Produkt den Bedürfnissen jedes Benutzers entspricht. Einige Stifte sind billig und zum Einmalgebrauch bestimmt, andere sind teuer und aus hochwertigen Materialien hergestellt. manche verwenden Gele, manche verwenden Tinte, manche verwenden Pigmente; Einige haben Twist-Off-Kappen, andere haben überhaupt keine Kappen. breite Fässer, schmale Fässer, runde Fässer, quadratische Fässer; kurz lang; rot, weiß, schwarz, blau. Usw.

Aber genug über Stifte.

Unsere derzeitige Vielzahl von Programmiersprachen lässt sich auf die allerersten zurückführen: die numerischen Maschinencodes für frühe Computer in den 1940er Jahren. Primitive, schwer zu bedienen und mühsam in den Computer einzutreten, aber sie haben den Job gemacht. Es dauerte nicht lange, bis die Programmierer den Maschinencodes mnemonische Wörter (wie ADD, CALL, LOAD) zuwiesen, wodurch die Sprachklasse "Assemblersprachen" entstand.

Unterschiedliche Prozessorarchitekturen erforderten unterschiedliche Gedächtniscodes, abhängig von den spezifischen Merkmalen der zugrunde liegenden Maschinen. Diese Unterschiede zu berücksichtigen bedeutete, verschiedene Assemblersprachen zu erfinden.

(Vielleicht können Sie jetzt sehen, wohin das führt ...)

Programmierer sahen sich ihre Assemblersprachenprogramme an und sahen Muster: Dieselben Befehlsfolgen wurden verwendet, um Schleifen, Bedingungen, Variablenzuweisungen, Funktionsaufrufe usw. zu bilden. So wurden die prozeduralen Programmiersprachen geboren. Diese Sprachen kapselten Anweisungsgruppen unter Überbegriffen wie "if", "while", "let" usw.

Aus einer mathematischen Analyse der Computerprogrammierung gingen die funktionalen Sprachen hervor - eine völlig neue Art, die Berechnung zu betrachten. Nicht besser, nicht schlechter, nur anders.

Und dann gibt es objektorientierte, statisch typisierte, dynamisch typisierte, späte Bindung, frühe Bindung, geringe Speichernutzung, hohe Speichernutzung, parallelisierbar, Sprachen für bestimmte Verwendungszwecke und so weiter und so fort.

Letztendlich haben wir verschiedene Programmiersprachen, weil wir verschiedene Programmiersprachen wollen . Jeder Sprachdesigner hat seine eigenen Vorstellungen, wie seine "Traum" -Sprache aussehen und funktionieren wird. Vielfalt ist eine gute Sache.

Funktionale Programmiersprachen basieren in der Regel auf dem unterschiedlichen (aber leistungsäquivalenten) Rechenmodell: der Lambda-Rechnung . Es gibt einige untypisierte Sprachen (mit Python-ähnlicher Typisierung) wie LISP, Scheme (verwendet für die weithin erkennbare Struktur und Interpretation von Computerprogrammen in Büchern / Kursen) und statisch typisierte Sprachen wie Haskell, ML, F #.

SICP hat mich zum funktionalen Programmieren gebracht, aber andere Leute empfehlen dieses Paper von John Hughes und dieses Interview mit ihm.

Die funktionale Programmierung wird jetzt zum Beispiel von Microsoft vorangetrieben, die F # (ihre funktionale Sprache für .NET) in VS2010 und 11 aufgenommen haben. Sie beschäftigen auch einige Haskell-Entwickler in MSR, IIRC.

Beachten Sie, dass es auch einige funktionale Programmiersprachen gibt, die nicht aus der Lambda-Rechnung stammen, wie z. B. Refal , das auf Pattern Matching und Rewriting basiert.

Da die Abstraktionsebene in funktionalen Sprachen unterschiedlich ist, ändert sich Ihre Einstellung zur Problemlösung, wenn Sie Techniken der funktionalen Programmierung verwenden. Einige sagen, dass es Sie generell zu einem besseren Programmierer machen kann.

Gibt es einen Grund, warum ich als Computerprogrammierer eine funktionale Sprache beherrschen sollte?

Ja. Weil haskell meine Denkweise geändert hat. Es könnte auch Ihre Denkweise verändern.

Story: Früher dachte ich, ich könnte jede Programmiersprache an einem Tag lernen . Eines Tages habe ich Haskell gegründet. Ich beendete alles, was vor Monaden kam, in einem halben Tag. Jetzt ist es ein Jahr her seit diesem Tag und ich stecke immer noch hoffnungslos bei Monaden fest.

Lesen:

1. Sprachen- und Gedanken-Wiki

2. Notation als Denkhilfe von Kenneth E. Iversion, Vortrag zum Turing Award

Aber warum gibt es so viele verschiedene Programmiersprachen?

Notation ist ein Werkzeug zum Nachdenken. Wir brauchen verschiedene maßgeschneiderte Notationen, um bequem mit verschiedenen Gedanken umgehen zu können. Also schaffen wir neue Sprachen.

Außerdem lesen . ;-)

Es könnte kaum einen Programmierer geben, der nicht irgendwann durch die Einschränkungen der verwendeten Sprache frustriert ist und sich entschlossen hat, seinen Juckreiz zu kratzen. So wird eine neue Sprache - oder ein Dialekt einer bestehenden - geboren.

Abadi und Cardelli entwickeln in "A Theory of Objects" eine ganze Familie von Programmiersprachen aus objektorientierten Grundlagen. Sie beweisen, dass funktionale Programmierung ein Sonderfall von OO ist, nicht jedoch das Gegenteil.

Etwas Neues zu erfinden, macht Spaß. Deshalb erschaffen die Menschen mit größerer Wahrscheinlichkeit eine weitere Sprache, als dazu beizutragen, eine bestehende Sprache zu verbessern. Natürlich gibt es Sprachverwalter, die Änderungen ihrer Sichtweise nicht begrüßen. Bestes Beispiel ist die Kluft zwischen Common Lisp- und Scheme-Anhängern.

Da andere bereits gute Antworten auf diese Frage gegeben haben, möchte ich nur Alan Perlis zitieren.

Hüten Sie sich vor der aufregenden Teergrube, in der alles möglich ist, aber nichts von Interesse leicht fällt.

Auch http://weblog.raganwald.com/2004/10/beware-of-turing-tar-pit.html ist eine gute Lektüre.

Warum gibt es so viele Länder auf der Welt? Wäre es nicht einfacher, wenn wir nur 5 oder 6 Supermächte oder sogar ein universelles Königreich der Erde hätten? Es ist leicht zu argumentieren, warum es nicht besser wäre - zunächst einmal kann der Wettbewerb in verschiedenen Ländern zu Fortschritten führen, und im Hinblick auf Demokratie, Menschenrechte usw. können viele Länder besser sein als eines - - aber das erklärt nicht, warum wir viele Länder haben. Es erklärt nur, warum viele Länder besser wären .

Ebenso kann man sich fragen, warum so viele verschiedene menschliche Sprachen? Polnisch, Arabisch, Mandarin ... Wäre es nicht einfacher, wenn es nur eine Sprache gäbe? Man könnte so oder so argumentieren, aber das wären Gründe, warum es besser wäre, wenn das Leben so oder so wäre. Es würde nicht erklären, warum es so viele verschiedene menschliche Sprachen gibt.

Die Sache ist, es gibt viele Menschen auf dem Planeten, und wir alle machen unser Ding, wir alle haben unsere Meinung, wir alle wollen das Sagen haben und unser eigenes Land oder unsere eigene Programmiersprache haben, und wir denken oft, dass wir es besser wissen als andere, oder zumindest nicht die Mühe zu verstehen, was andere zu bieten haben.

Lesen Sie diesen sehr aufschlussreichen Blog-Beitrag: Warum so viele Python-Webframeworks? Anscheinend gibt es in Python ungefähr 50 Web-Frameworks. Das ist einfach lächerlich; Dafür gibt es absolut keinen vernünftigen Grund. Aber der Autor des Posts antwortet: Es gibt so viele Python-Webframeworks, weil es so einfach ist, eines zu erstellen . Sie brauchen keinen vernünftigen Grund dafür, dass es mehr Python-Web-Frameworks oder mehr Programmiersprachen gibt. Die Leute werden weiterhin neue erstellen, weil sie nicht wissen, was bereits verfügbar ist, oder weil sie hoffen, dass sie Geld verdienen können, oder weil es einfach Spaß macht, neue Dinge zu erstellen!

Lassen Sie mich ein persönliches Beispiel beschreiben. Vor ungefähr 10 Jahren habe ich einen C ++ - Code für eine finnische Firma geschrieben. Wissen Sie, in Finnland gibt es diese riesigen Lastwagen, die lange Strecken zurücklegen und eine Menge Zeug von einem Ort zum anderen liefern. Ich bin mir sicher, dass es solche Lastwagen auch in Amerika gibt. Ein typisches Problem ist es also, sicherzustellen, dass alle rund 24 Reifen in Ordnung sind. Natürlich gibt es eine bewährte Technologie: Druck und Temperatur können überwacht werden, und drastische Änderungen lassen darauf schließen, dass etwas schief gelaufen ist. Natürlich ist all diese Technologie proprietär, patentiert und hat alle Auswirkungen. (Denken Sie daran: Patente sollen Innovationen fördern!) Das finnische Unternehmen wollte also den Zustand der Reifen durch ... Geräusche erkennen. Die Idee war, Mikrofone zu installieren, um den Ton von allen Reifen zu hören und eine Art Signalverarbeitungszauber auf diese Töne anzuwenden, um zu sehen, ob einer der Reifen ein Problem hatte, und ich machte einen Prototyp von diesem Wahnsinn. (Sie hatten sogar ein spezielles Labor für die Aufzeichnung von Sample-Sounds. Einmal schickten sie mir eine beeindruckende Videoaufzeichnung zu einer bestimmten Gelegenheit, als es ihnen gelang, einen Sample-Reifen zu explodieren, nachdem er 5 oder 10 Tonnen Druck ausgesetzt und auf eine lächerliche Temperatur erwärmt worden war .) Natürlich gab es auch hier keinen besonderen rationalen Grund für diese Entwicklung, außer dass es Spaß machte und einige Leute Geld verdienen wollten. Verstehen Sie also auch, dass es so viele Gründe gibt, warum jemand eine neue Programmiersprache entwickeln würde. Es gibt keine Notwendigkeit oder sogar Möglichkeit, sie alle zu lernen. (Sie hatten sogar ein spezielles Labor für die Aufzeichnung von Sample-Sounds. Einmal schickten sie mir eine beeindruckende Videoaufzeichnung zu einer bestimmten Gelegenheit, als es ihnen gelang, einen Sample-Reifen zu explodieren, nachdem er 5 oder 10 Tonnen Druck ausgesetzt und auf eine lächerliche Temperatur erwärmt worden war .) Natürlich gab es auch hier keinen besonderen rationalen Grund für diese Entwicklung, außer dass es Spaß machte und einige Leute Geld verdienen wollten. Verstehen Sie also auch, dass es so viele Gründe gibt, warum jemand eine neue Programmiersprache entwickeln würde. Es gibt keine Notwendigkeit oder sogar Möglichkeit, sie alle zu lernen. (Sie hatten sogar ein spezielles Labor für die Aufzeichnung von Sample-Sounds. Einmal schickten sie mir eine beeindruckende Videoaufzeichnung zu einer bestimmten Gelegenheit, als es ihnen gelang, einen Sample-Reifen zu explodieren, nachdem er 5 oder 10 Tonnen Druck ausgesetzt und auf eine lächerliche Temperatur erwärmt worden war .) Natürlich gab es auch hier keinen besonderen rationalen Grund für diese Entwicklung, außer dass es Spaß machte und einige Leute Geld verdienen wollten. Verstehen Sie also auch, dass es so viele Gründe gibt, warum jemand eine neue Programmiersprache entwickeln würde. Es gibt keine Notwendigkeit oder sogar Möglichkeit, sie alle zu lernen. Einmal schickten sie mir eine beeindruckende Videoaufzeichnung zu einem bestimmten Anlass, als es ihnen gelang, einen Musterreifen zu explodieren, nachdem er einem Druck von 5 oder 10 Tonnen ausgesetzt und auf eine lächerliche Temperatur erwärmt worden war.) Auch hier gab es keinen besonderen Grund Grund für diese Entwicklung, außer dass es Spaß machte und einige Leute Geld verdienen wollten. Verstehen Sie also auch, dass es so viele Gründe gibt, warum jemand eine neue Programmiersprache entwickeln würde. Es gibt keine Notwendigkeit oder sogar Möglichkeit, sie alle zu lernen. Einmal schickten sie mir eine beeindruckende Videoaufzeichnung zu einem bestimmten Anlass, als es ihnen gelang, einen Musterreifen zu explodieren, nachdem er einem Druck von 5 oder 10 Tonnen ausgesetzt und auf eine lächerliche Temperatur erwärmt worden war.) Auch hier gab es keinen besonderen Grund Grund für diese Entwicklung, außer dass es Spaß machte und einige Leute Geld verdienen wollten. Verstehen Sie also auch, dass es so viele Gründe gibt, warum jemand eine neue Programmiersprache entwickeln würde. Es gibt keine Notwendigkeit oder sogar Möglichkeit, sie alle zu lernen.

All dies gilt natürlich nur, wenn Sie an die Evolution glauben. Wenn Sie an eine Form intelligenten Designs glauben, dass Gott auch alle Programmiersprachen erstellt hat, dann müssten Sie einen Zweck hinter dieser Vielzahl finden. Vielleicht wollte Gott den Wettbewerb zwischen verschiedenen Programmiersprachen fördern, damit die Kunst der Softwareentwicklung ihren höchstmöglichen Stand erreicht.

Zusammenfassend gibt es viele Leute, viele Länder, viele Programmiersprachen. Das ist nur die Natur des Lebens! Lassen Sie uns dafür dankbar sein: Dies bedeutet nur, dass das Gebiet der Programmierung / Informatik sehr lebendig und aufblühend ist.

Warum gibt es so viele verschiedene Programmiersprachen?

Weil es Entscheidungen zu treffen gibt:

• Art der Spezifikation: Imperativ vs. funktional
• Typisierung: Statisch getippt vs. dynamisch getippt
• Auswertungsreihenfolge: Call-by-Value vs. Call-by-Name
• Modularität: Klassenbasiert vs. abstrakt Datentypbasiert
• Ausführungsmodell: sequentiell vs. simultan

Glücklicherweise handelt es sich bei den letzten beiden um unwesentliche Dichotomien, dh man könnte beide Auswahlmöglichkeiten in einer einzigen Programmiersprache zusammenfassen. Die ersten drei Dichotomien ergeben jedoch 8 Kombinationen. Selbst in einer idealen Welt gibt es also mindestens 8 Programmiersprachen. Wenn Sie einen Drilldown durchführen, stehen Ihnen innerhalb bestimmter Paradigmen weitere differenzierte Entwurfsoptionen zur Verfügung. Wenn man sich zum Beispiel für eine klassenbasierte statisch typisierte Sprache entscheidet, gibt es verschiedene Möglichkeiten, das Typsystem zu entwerfen. Es gibt noch keinen kanonischen Weg, dies zu tun. Wenn Sie sich für eine parallele Programmiersprache entscheiden, gibt es verschiedene Möglichkeiten, die Parallelität darzustellen: Semaphoren, bedingte kritische Bereiche, Monitore, Nachrichtenübermittlung (synchron vs. asynchron). Innerhalb der synchronen Nachrichtenübermittlung

Ein Teil unserer Forschung in der Programmiersprachtheorie widmet sich der Lösung dieser Dichotomien. Ich habe zum Beispiel in einem Artikel mit dem Titel "Aufgaben für anwendungsbezogene Sprachen " an der Auflösung der Dichotomie zwischen imperativer und funktionaler Programmierung gearbeitet. Unsere Methode wurde nun von Haskell übernommen und ist sowohl eine funktionale als auch eine imperative Sprache. Das bedeutet nicht, dass die Dichotomie vollständig aufgelöst ist. Ein Haskell-Programmierer steht immer noch vor der Wahl, ob er sein Problem funktional oder zwingend lösen möchte. Luca Cardelli arbeitete an der Lösung der Dichotomie zwischen statischer und dynamischer Typisierung. Paul Levy arbeitete an der Lösung der Dichotomie zwischen Call-by-Value und Call-by-Name . Nicht alle dieser Ergebnisse wurden bisher in realen Programmiersprachen umgesetzt.

Wenn all diese Sprachen dasselbe können, warum nicht einfach an einer Sprache festhalten und diese für die Programmierung von Computern verwenden?

Denn für einen Programmierer in der realen Welt reicht es nicht aus, nur etwas zu tun. Es ist auch wichtig, wie es gemacht wird. Bei ordnungsgemäßer Ausführung wird die Problemdomäne im Programm korrekt dargestellt, die Modularität des Problems bleibt erhalten, und die Programme sind leicht zu verstehen, zu ändern und zu warten. All diese Dinge wirken sich auf die Kosten der Programmentwicklung und -wartung aus. Sie wirken sich auch auf die Zuverlässigkeit und Sicherheit der Software aus.

Beispielsweise verwenden viele Leute ein Programm mit dem Namen " Quicken " für Finanzkonten. Das ursprüngliche Programm wurde in einer internen Version von Visual Basic entwickelt und war recht gut. Es war jedoch schwierig, es zu erweitern und zu warten. Im Laufe der Jahre, als das Unternehmen versuchte, es für neuere Funktionen zu erweitern, wurde das Programm mit Millionen von unzufriedenen Kunden überall zunehmend buggy. Sie werden wahrscheinlich von einer Neuentwicklung der Software in einer stark typisierten objektorientierten Programmiersprache profitieren.

Gibt es einen Grund, warum ich als Computerprogrammierer eine funktionale Sprache beherrschen sollte?

Historisch gesehen wurde "funktionale Programmierung" von Godel, Kleene und Church nach der üblichen mathematischen Praxis erfunden, und "imperative Programmierung" wurde von Turing erfunden, um den Begriff der mechanischen Berechnung festzuhalten. Vor Turing gibt es keinen Beweis dafür, dass die Mathematik jemals imperative Programmierideen analysiert hat. (Während alle traditionellen mathematischen Algorithmen in einem "imperativen Stil" ausgedrückt wurden, war ihr wesentlicher Inhalt immer noch funktional.) Daher ist imperative Programmierung für die menschliche Zivilisation sehr neu und ihre Mathematik ist immer noch nicht sehr gut verstanden. Der Hauptgrund, warum jeder etwas über funktionale Programmierung wissen sollte, ist zu verstehen, wie Programmierung mathematisch sein kann. (Ich gebe nicht zu, dass imperative Programmierung nicht mathematisch ist, Das ist es, woran funktionierende Programmierer Sie glauben lassen würden. Aber ich würde zustimmen, dass wir beim gegenwärtigen Stand der Technik noch nicht wissen, wie man imperative Programmierung mathematisch macht. Viele von uns arbeiten genau an diesem Problem.)

Sie könnten es als Evolution ansehen.

Anfangs wurden Computer nur mit Binärcodes programmiert. Danach wurden Mnemonics eingeführt und Assemblersprachen eingeführt, die größtenteils stark von der verwendeten CPU abhängen.

Nach der Einführung der höheren Sprachen (3. Stufe) (Pascal, C, ADA, Cobol) waren einige sehr allgemein gehalten (wie C), andere eher für die Datenverarbeitung geeignet (Cobol), andere für Berechnungen (Fortran).

Danach entstanden Sprachen der 4. Stufe, wie Logiksprachen (wie Prolog). Die allgemeinsten Sprachen sind Nachfolger von Fremdsprachen. Einige von ihnen sind Java, C #.

Wir sehen auch spezifische Sprachen für Internet / Web, wie ASP.NET, PHP.

Und Sprachen für eine bestimmte Domain (DSL), die meist mit einer generischen Sprache zusammenarbeiten.

Dann gibt es Sprachen, in denen Kinder Programmieren lernen können, wie zum Beispiel LOGO.

Auch Sprachen für das schnelle Schreiben von Code, wie Python, Ruby usw., Sprachen für den Umgang mit XML (XSLT).

Und ich habe wahrscheinlich viele Sprachen und sogar Kategorien von Sprachen vergessen.

Andere Antworten sind gut, werden ein paar neue Blickwinkel hinzufügen. Während DC schreibt, entwickeln sich Sprachen genauso wie echte menschliche Sprachen! und sie leihen sich Konzepte und Syntax wieder wie echte menschliche Sprachen aus. Mit anderen Worten, es gibt auch ein ziemlich reales Studium der Etymologie der Computersprachen.

Dies bedeutet auch, dass es eine lange Geschichte und Zeitlinie gibt, die hauptsächlich um die 1930er Jahre mit Lambda-Kalkül begann .

Es gibt ein starkes Zusammenspiel / Synergie / Symbiose zwischen Theorie und Anwendung mit Programmiersprachen. Neue Anwendungen werden erfunden, was zu neuen Theorien führt und umgekehrt. Eine Programmiersprache ist in vielerlei Hinsicht eine Brücke zwischen Theorie und Anwendung .

Eine interessante Fallstudie aus der Geschichte ist Fortran. es ist nicht bekannt, aber frühere Versionen von Fortran (meist vor Fortran77) hatten eine mehrdeutige Grammatik . Dies bedeutet, dass derselbe Befehl vom Compiler legitimerweise auf unterschiedliche Weise "interpretiert" / kompiliert werden konnte, da es mehrere gültige "Interpretationen" gab (dies ist nicht der gleiche technische Sinn für "interpretierte" Sprachen).

Die Theorie der formalen Grammatik wurde also zu der Zeit entwickelt, als Fortran erfunden wurde, und es war eine kleine Krise, als das Problem der Sprachmehrdeutigkeit entdeckt wurde. Die Fortan-Syntax wurde neu formuliert, um diese Mehrdeutigkeit zu vermeiden, und spätere Sprachen zeigten eine größere Sensibilität für Grammatik-Mehrdeutigkeiten in ihrem Design. OOP ist auch ein sehr wichtiges / vorrangiges Beispiel für ein theoretisches Konzept / einen Fortschritt in Programmiersprachen, das in viele existierende Sprachen "einwirkt" oder "kräuselt" und diese transformiert.

Andere Fallstudien sind die Erfindung neuer Technologien. Beispielsweise hat die Erfindung der relationalen Datenbank enorme Auswirkungen auf Computersprachen, z. B. mit SQL und Computersprachenschnittstellen (z. B. in Java, "JDBC"). Ebenso das World Wide Web mit noch größerer Wirkung. Unmittelbar um den Dotcom-Boom herum schien es eine Explosion von Sprachen zu geben, die weitgehend mit dem frühen Wachstum des WWW zusammenfiel und mit evolutionären Explosionen verglichen werden könnte .

Es scheint auch eine lange Tendenz zu geben, dass neue Programmiersprachen in Verbindung mit der massiven exponentiell zunehmenden Rechenleistung des Moores-Gesetzes, von der manche meinen, dass sie sich verlangsamt, zunehmen .

Die aktuellen langfristigen Trends in Programmiersprachen scheinen in Richtung Big Data und Parallelisierung zu gehen, z . B. mit MapReduce . Derzeit besteht auch ein Interesse an Schließungen .

Ein weiterer wichtiger Aspekt von Sprachen ist, dass sie immer mehr Abstraktionsebenen repräsentieren . Sie bauen auf Abstraktionen auf niedrigerer Ebene auf, um Abstraktionen auf höherer Ebene zu erstellen (ähnlich einer Pyramide). Auf diese Weise ist der Fortschritt der Entwicklung der Computersprache wahrscheinlich endlos und wir können relativ sicher sein, dass auch in Zukunft wichtige neue erfunden werden. Dies ist wahrscheinlich analog zu einem ähnlichen Konzept in der Psychologie, das Chunking genannt wird.

Jeder, der viele Computersprachen studiert hat, muss zugeben, dass eine Herdenmentalität beobachtet werden kann, bei der sich einige Aspekte als überhypte Modeerscheinungen herausstellen, dh nicht so kritisch wie befürwortet, oder sogar im Laufe der Zeit aussterben (im Gebrauch)! Einige der Kernideen / -änderungen bleiben bestehen, aber der (Über-) Hype lässt nach. in diesem Sinne fallen auch Programmiersprachen aus der Mode . Zwei Fälle aus meiner Sicht aus dem letzten halben Jahrzehnt, die zwar nützlich sind, aber überarbeitet wurden:

• Testgetriebene Entwicklung (implementiert in Sprachfunktionen)
• Aspektorientierte Programmierung

Zunehmend kann eine Selbstähnlichkeit in vielen wichtigen Sprachen beobachtet werden, sodass sie alle dazu tendieren, viele ähnliche Funktionen auf ihre eigene Weise zu implementieren, dh wie bei Produktvergleichsdiagrammen, die viele Funktionen in einem Raster "abhaken".

Sie waren es nicht, es ist nur ein Marketing-Trick - wenn Sie die Sprache irgendwie wie "C" aussehen lassen, dann senkt dies die offensichtliche Eintrittsbarriere.

Einige, die überhaupt keinen C-Einfluss haben: SQL, Pascal, Delphi, FORTRAN, COBOL, Ada, PowerBuilder, HyperTalk, Lisp, Simula, FOKAL, BASIC, PL / I, Algol, Algol-68, SNOBOL, Modula, Visual BASIC, Tutor, Logo, Forth, DIBOL, Helix, AppleScript, Python, Erlang, Ruby, Auswahl, Englisch, RPG, PL / SQL, ASP, Prolog, SmallTalk, Perl, Bash, Zauberstab BASIC, REXX, DOS-Batch-Sprache.

Diejenigen, die irgendwie wie C aussehen, aber sehr wenig gemeinsam haben: JavaScript, Java, C #, (wohl) Objective-C.

Es ist alles Marketing, Java, C ++ und JavaScript sieht ein bisschen wie C aus, könnte aber unter der Decke kaum unterschiedlicher sein.