Monade kann nicht erklärt werden

Nein, dies ist kein weiterer Versuch, die Monaden zu erklären. Ich weiß nicht, wie ich das machen soll und kann mir nicht vorstellen, wie ich mir das zum Beispiel aus der Vergangenheit aus der Vergangenheit erklären könnte.

Gleiches gilt für andere FP-Konzepte. Ich verstehe ihren Wert, wie man sie benutzt. Aber ich weiß nicht, wie ich dies Menschen vermitteln soll, die anfänglich negativ zu einem funktionalen Ansatz neigen. Ich denke nicht, dass es überhaupt möglich ist Übung löst diese Angelegenheit leicht, aber die Leute erreichen sie selten.

Ich weiß nicht einmal, wie ich einfachere Fragen beantworten soll. Trotz der Tatsache, dass ich seit mehr als 3 Jahren über Scala schreibe, kann ich die Vorteile der Sprache für eine Person von außerhalb nicht an den Fingern erklären. Zum Beispiel hatte ich vor ein paar Monaten eine gute Diskussion.

Alles begann mit der Frage: "Und für wen ist Ihre Sprache geschrieben?" .
All diese Immunität, Funktionen höherer Ordnung, ein großartiges Typensystem, Nebenwirkungen und andere Monaden drehten sich in meinem Kopf, aber ich verstand, dass dies nicht alles war. Die anschließende Klarstellung schickte mir schließlich einen Knockout: „Hier ist beispielsweise Java eine Sprache für Angestellte . Dieser Dialog endete mit einem inkohärenten Unsinn über die Unfähigkeit, den Unterschied ohne Übung zu erklären.

Wir wissen nicht, wie wir FP verkaufen sollen

Dies ist nicht nur eine Nacherzählung persönlicher Erfahrungen. Wir alle, Benutzer funktionaler Sprachen, befinden uns in ungefähr derselben Situation. Wir verstehen den großen Unterschied im Vergleich zu Blub- Sprachen perfekt, aber der Rest der Welt will uns nicht hören. Natürlich kann man sich über die begrenzten Konservativen ärgern, die "G" feilschen, ruhig Unsinn tragen, Mythen und Märchen miteinander nacherzählen, fest und selbstbewusst über Dinge diskutieren, für die sie nicht einmal ein paar Stunden aufgewendet haben. Sie können auch große Unternehmen mit ihren Vermarkterteams beschuldigen.

Aber zuallererst scheint mir das Problem zu sein, dass wir selbst nicht wissen, wie man FP verkauft. Ja, das ist keine leichte Aufgabe. Wenn ich mich erinnere, wie Menschen Entscheidungen treffen, wie und welche Dinge in den Trends enthalten sind, denke ich, dass dies möglich ist.

Mit der Entwicklung stimmt immer etwas nicht.

  • Die Prozesse sind langsam! Und jetzt, nach ein paar Jahren, ziehen jeden Morgen in allen Büros des Landes Menschen, die an der Tafel stehen, Aufkleber von einer Säule zur anderen.
  • Die Bereitstellung ist langsam! Und bewaffnet mit Devops-Werten machen wir 10 Veröffentlichungen pro Tag, während eine neue Generation von Admins sie mit Tonnen von Rubin, Python und Yaml füllt.
  • Bewerbungen sind kompliziert! Und so bauen Teams von 2-3 Entwicklern eine neue Microservice-Architektur auf, indem sie die Verantwortlichkeiten jedes Service im Detail durchdenken und 10 Pool-Anfragen für eine kleine Revision ausführen.

Nicht, dass ich all diese Branchenwahnsinn für schlecht gehalten hätte. Sie haben einfach auch viele Mängel. Und nicht jeder wusste, wie oder wie man sie richtig kocht. Fehlende oder fehlende bequeme Abstimmung. Diese Ansätze sind jedoch für die Branche zum „De-facto“ -Standard geworden. Und obwohl die Diskussion über Docker in der Produktion für einige eine offene Frage zu sein scheint, ist bereits alles passiert.

Ich bin sicher, dass das Gleiche mit funktionalen Sprachen passieren kann. Ja, das ist nicht ganz richtig - um Programmiersprachen mit Methoden und Ansätzen zu vergleichen. Aber wir haben etwas in ihrer Positionierung für uns selbst zu leihen. Alle haben ein genau definiertes Problem , das sie lösen. Und das ist Geschwindigkeit: Entwicklung, Kommunikation, Planung, Bereitstellung, Änderungen ...

Warum vergessen wir das Wichtigste zu sagen?

Gleichzeitig ist es aus Sicht der Positionierung funktionaler Programmiersprachen schwierig zu sagen, dass sie ein klares und verständliches Ziel haben. Sprachwissenschaftler „ FP vs OOP “ rutschen normalerweise schnell in ein Maß von Merkmalen und Konzepten, deren Wert vom OOP-Lager nicht gut verstanden wird. Artikel und Berichte im Format „ Sie sehen, wie diese Monaden hervorragend zusammengesetzt sind “ bestätigen oft die Meinung der Menschen, dass sie dies nicht brauchen, als sie zum Versuch inspirieren. All diese Interaktionen beantworten selten die Frage „ Warum ist das alles? "" Schön und prägnant? Im besten Fall werden weniger Fehler erwähnt.

Das Wichtigste bei der Verwendung funktionaler Sprachen ist die gleiche Entwicklungsgeschwindigkeit! Und diese Geschwindigkeit wird durch all diese langweiligen und beängstigenden Begriffe, Konzepte und Eigenschaften erreicht, die sich daraus ergeben. Leichtere Komposition durch Funktionen höherer Ordnung - plus Entwicklungsgeschwindigkeit. Immunität bedeutet neben Zuverlässigkeit und weniger Fehlern, mehr Zeit für nützliche Dinge zu geben, anstatt sie für Debugging, Hotfixes und Support aufzuwenden. Nun und so weiter, ich denke die Logik ist klar.

Ja, das klingt zu einfach und sogar offensichtlich.

Ja, ich habe hier nichts Neues gesagt. Die Bedeutung von Wortlaut und Betonung ist jedoch wichtig. Leider funktioniert unser Denken so. Um Barrieren abzubauen, reichen Erklärungen allein nicht aus. Brauche Übung! Es ist notwendig, dass eine Person oder ein Unternehmen Zeit damit verbringen möchte. Hinweise auf „Akademizität“ oder relative Schönheit werden nur wenige dazu inspirieren, sich mehrere Tage lang wie ein Idiot zu fühlen.

Es lohnt sich aufzuhören, sich als weise Leute aufzubauen, die Begriffe sofort nach links und rechts zu streuen und die Überlegenheit Ihres Lieblings-YP gegenüber Blub zu beweisen. Anstatt die Nützlichkeit von Merkmal X zu beweisen, ist es viel einfacher, es als Erklärung für eine verständlichere Eigenschaft zu verwenden. Wenn es anderen Technikern gelungen ist, ist es vielleicht an der Zeit, dass wir auch Verantwortung übernehmen und mit offensichtlichen und einfachen Dingen fest in Kontakt treten.

Wenn Sie das nächste Mal Schwierigkeiten haben, die Frage „ Warum? “ Zu beantworten, zögern Sie nicht, sich für Trumpfkarten zu entscheiden, z. B.: Höhere Entwicklungsgeschwindigkeit , billigerer Support , weniger Entwickler .

Ah und mehr. Community-Events spielen auch eine wichtige Rolle bei der Positionierung!
Deshalb warten wir auf alle auf der einzigen Funktionskonferenz in Russland - FPURE - Kasan - vom 24. bis 25. Mai auf alle, denen FP nicht gleichgültig ist.
Das Programm beinhaltet: Haskell, Scala, Elixir, Clojure, Theorie und Praxis und natürlich viele Gleichgesinnte, mit denen es etwas zu besprechen gibt!

Source: https://habr.com/ru/post/de450132/


All Articles