Funktionsprogrammierung: Siebenmal messen, einmal schneiden

Guten Tag! In letzter Zeit höre ich sehr oft, dass der Sonnenuntergang der PLO gekommen ist. Heutzutage bewegen sich immer mehr Menschen zu einem funktionalen Paradigma. Bald werden Leute, die in C ++ / C # / Java schreiben, überhaupt nicht mehr übrig sein. Ist es so? Ich glaube nicht. Meiner Meinung nach kann die gedankenlose Verwendung von FP (funktionale Programmierung) zeitaufwändig werden und zusätzliche Kopfschmerzen verursachen, die mit aktuellen Entwurfsentscheidungen völlig unvereinbar sind. Lassen Sie uns dafür sorgen!



Ich möchte darauf hinweisen: Hier geht es nicht um Lambda-Ausdrücke in Java / Python, sondern um ein fortgeschritteneres FP wie Haskell oder Scala mit Katzen / Scalaz.

Also bestätige ich das:

1. AF ist bei weitem nicht überall anwendbar.
2. Die Integration in vorgefertigte Lösungen bereitet Kopfschmerzen.
3. Es ist nicht immer ratsam, Zeit mit AF zu verbringen.

Wir werden diese Punkte genauer analysieren und das Ausmaß der Tragödie bewerten.

1. AF ist bei weitem nicht überall anwendbar

Das scheint überraschend, aber nicht jeder versteht das. Darüber hinaus sind Sprachen wie C sehr weit vom Sonnenuntergang entfernt. Viel weiter als Haskell oder Scala. Schauen Sie sich eine Spiel-Engine an. Mit einer Wahrscheinlichkeit von 90% ist das meiste davon in C geschrieben. Sehen Sie sich die Firmware aller Haushaltsgeräte in Ihrer Wohnung an. Höchstwahrscheinlich ist dies wieder C! Betriebssysteme? Natürlich C.

Warum passiert das? Tatsache ist, dass all das direkt mit Eisen funktioniert. Eisen kennt keine Funktionen höherer Ordnung. Eisen ist eine Reihe von Registern (die bereits ein veränderlicher Zustand sind), Interrupts (die wiederum den Zustand ändern) und Befehlen, die Nullen und Einsen von einer Zelle in eine andere übertragen.

Natürlich können Sie die Abstraktion verwenden und all diese eisernen Dinge vergessen. Dies ist jedoch zunächst nicht immer sinnvoll. Wenn unser Programm recht einfach ist, macht es keinen Sinn, mit einigen Abstraktionsebenen zu schließen. Zweitens wird in solchen Programmen häufig die Arbeitsgeschwindigkeit auf eine der Schlüsselpositionen gesetzt. Daher werden die zusätzlichen Kosten für das „Erklären“ der FP-Drüse den Nutzen Ihrer Entwicklung vollständig ruinieren. AF kann sich hier nicht manifestieren.

2. Bei der Integration in schlüsselfertige Lösungen treten Kopfschmerzen auf

Jede Programmiersprache mit Selbstachtung verfügt über eine Vielzahl vorgefertigter Lösungen. In C # sind dies beispielsweise Entity Framework und .Net. In Java sind dies Ruhezustand und Frühling. Und fast jedes Framework zielt darauf ab, in unserem üblichen OOP-Stil zu arbeiten. Fast immer haben diese Lösungen variable Zustände und sind für die Arbeit mit reinen Phasenübergängen völlig ungeeignet.

Jeder Hardcore-Funktionsprogrammierer wird sagen, dass Sie diese Lösungen wegwerfen und ohne sie arbeiten müssen. Okay Lassen Sie uns als Referenz herausfinden, was wir durch eine solche Entscheidung verlieren werden:

1. Fast immer führen solche Entscheidungen zu Boilerplate-Code.
2. Wir verlieren eine riesige Ebene an Funktionalität. Natürlich können wir eine fertige Bibliothek nehmen, um in einem funktionalen Paradigma zu arbeiten. Aber fast immer ist eine solche Lösung viel weniger beliebt, was bedeutet, dass sie nicht die Hälfte aller Möglichkeiten beliebter Lösungen bieten kann.
3. Fertige Produkte, die diese Lösung verwenden, müssen fast vollständig überarbeitet werden.
4. Wir verlieren eine bewährte und hochdeterministische Lösung. Stattdessen bewegen wir uns in Richtung Unbekanntes. Gibt es Probleme bei gängigen Lösungen? Natürlich! Aber über sie ist in der Regel schon lange alles bekannt. In unserem neuen Ansatz wird dies definitiv nicht passieren.

Tatsächlich geht die Liste noch lange weiter. Meiner Meinung nach macht die Gesamtheit der Verluste AF zumindest nicht überall und nicht immer geeignet.

3. Es ist nicht immer ratsam, Zeit mit AF zu verbringen

Was jedoch überrascht, ist, dass Programmierer oft nicht sehen, was sich hinter dem Code verbirgt. Nicht immer eine Programmiersprache und ein Paradigma bestimmen die Qualität eines Produkts. Auf der Rückseite geht alles zur Containerisierung. Es ist fast nicht wichtig, worüber Sie schreiben: Python, Java, Scala. Code in einer dieser Sprachen kann in ein Bild eingeschlossen und als Container geliefert werden.

In einer solchen Welt ist es nicht so wichtig, was sich im Container befindet, wenn alle festgelegten Anforderungen erfüllt sind. Hier ist es wichtiger, wie das gesamte System organisiert ist. Es stellt sich die Frage: Sind Sie wirklich sicher, dass Ihre Zeit in das Studium von FP mit seiner Kategorietheorie investiert werden sollte? Es kann sich lohnen, in die Entwicklung der gesamten Systemarchitektur zu investieren. Darüber hinaus ist es viel einfacher, Personen ohne FP-Kenntnisse zu finden, die bereit sind, Ihnen solche Container zur Verfügung zu stellen.

Stellen Sie sich diese Situation vor. Sie sitzen nachts und studieren die ganze Theorie. Sie sehen sich Videos auf YouTube an, lesen Bücher und vertiefen sich in mathematische Berechnungen. Im Laufe der Zeit können Sie bereits eine kleine Anwendung erstellen, aber nicht alles ist klar. Sie beginnen weiter zu üben: Nehmen Sie fortgeschrittenere Bücher, gehen Sie zu Besprechungen, führen Sie Gespräche mit Kollegen über das Hoch. Aber dann erschien ein echtes Projekt. Mit Ihrem Wissen spielen Sie eine führende Rolle in diesem Projekt. Das Leben ist gut! Und so haben Sie genau den perfekten Service geschrieben. Es bleibt nur ein Problem. Was ist als nächstes zu tun? Wie konfiguriere ich den Automatisierungsprozess? Wie richte ich Smart Balancing ein? Wie finde ich meinen anderen Service? Möglicherweise haben Sie einfach keine Antwort auf diese Fragen! Sind Sie sich immer noch sicher, dass AF für Sie so notwendig ist?

Schlussfolgerungen

Tatsächlich habe ich eine äußerst positive Einstellung gegenüber AF. Ich möchte nur ein Werkzeug sagen, das weit davon entfernt ist, immer und überall zu sein. Meiner Meinung nach sollte ein Ingenieur nicht in Kategorien wie / nicht mögen denken. Stattdessen sollte es die objektivsten Gründe für die Verwendung dieser oder jener Lösung geben.

Bevor Sie ein funktionales Paradigma studieren / einführen, sollten Sie mindestens drei Fragen stellen: die Möglichkeit, sich in Ihrem Berufsfeld zu bewerben, wie stark sich dies auf die Integration in vorgefertigte Lösungen auswirken kann und ob sich der Zeit- und Ressourcenaufwand auszahlt. Wenn Sie aufgrund eines dieser Probleme keine Panikattacke haben, können Sie diese in Betrieb nehmen.

Vielen Dank für Ihre Aufmerksamkeit!