Was wären gute sachliche Argumente, um das Management zu überzeugen, eine funktionale Programmierung in Betracht zu ziehen? [geschlossen]

15

Es gibt Unmengen von "theoretischen" Argumenten, warum funktionale Programmierung eine gute Idee ist (zu viele, als dass dies eine offene Frage gewesen wäre, und das zu Recht).

Bei den meisten handelt es sich jedoch entweder um theoretische Argumente ("Eleganz" usw.) oder um Argumente für Entwickler.

Das Problem ist, dass die meisten von ihnen völlig unbrauchbar sind, wenn das Ziel darin besteht, die Idee der Geschäftsleitung eines großen Unternehmens vorzustellen , von dem einige noch nicht einmal Entwickler sind, und die sich hauptsächlich um geschäftliche Argumente kümmern : Kosten, Humankapitalmanagement , Produktlieferung, Kundenservice und Umsatz; sowie quantitative Fakten über theoretische Punkte, die nicht mit Fakten belegt werden können.

Gibt es zwingende Argumente, um diese geschäftlichen Bedenken auszuräumen und die Übernahme der funktionalen Programmierung als Konzept (keine bestimmte Sprache) gegenüber der typischen Mischung aus prozeduralem / OOP, z. B. Java / C ++ / (Perl | Python), in Betracht zu ziehen ? .

Ich suche vorzugsweise nach Argumenten, die quantitativ sind und / oder auf Recherchen oder Fallstudien beruhen. ZB "laut dieser Referenz beträgt die Fehlerrate von Multithread-Systemen in Lisp / F # 10% derjenigen von Java" oder "80% der Absolventen, die Präferenzen der gewünschten Technologie ausdrücken, die als funktionale Programmierung bezeichnet wird, als eine der drei Hauptinteressen".

Ich weiß, dass Graham Anwendungsfälle der funktionalen Programmierung für ein Startup vorgestellt hat und für einige seiner Argumente offen wäre, wenn sie für ein größeres etabliertes Unternehmen gelten könnten.

psIch bin mir vollkommen bewusst, dass Sie in Perl, wahrscheinlich in Python und (möglicherweise) sogar in Java 8 oder C ++ 14, etwas in der Nähe der funktionalen Programmierung tun können OOP / prozedurale Ansätze auch in diesen Sprachen

Für die Zwecke dieser Sprache wird "groß" als ausreichend groß definiert, um eine dedizierte Entwicklungsingenieur- / Toolgruppe zu haben, die festlegt, was alle Entwickler verwenden / tun dürfen. und mindestens Hunderte von Entwicklern am unteren Ende .

DVK
quelle
1
Du suchst diesen, denke ich? paulgraham.com/avg.html Eigentlich finde ich den Artikel etwas veraltet, zwischendurch sind viele funktionale Konzepte in die Mainstream-Sprachen eingeflossen .
Doc Brown
34
Warum sollte sich das Management auf hoher Ebene Gedanken machen, welche Programmiersprachen und Methoden verwendet werden? Warum sollten sie an einer solchen Entscheidung beteiligt sein? Sicher ist das eine Sache für die technischen Manager?
High Performance Mark
8
@HighPerformanceMark: Ersetzen Sie "High-Level-Management" durch "Technical Manager", und werten Sie die Frage erneut aus.
Robert Harvey
2
In welchem ​​Geschäft bist du? Wenn Sie Vertragsprogrammierung und Beratung durchführen, kann die funktionale Programmierung ein Modewort sein, von dem das Management glaubt, dass es Ihre Kunden beeindruckt.
JeffO
3
Welche betriebswirtschaftlichen Argumente hat Ihnen das Management für die von Ihnen aktuell verwendeten Sprachen gegeben?
JeffO

Antworten:

7

Es gibt ein sehr einfaches Argument, das das Management zumindest amüsieren könnte.

Es ist allgemein bekannt, dass die modernen Computer nicht mehr so ​​"schneller" werden wie früher, da die Frequenzskalierung vorerst an ihre Grenzen stößt. Sie erhöhen ihr Produktivitätspotential durch Hinzufügen von Kernen.

Dies bedeutet, dass die Programme parallelisiert werden müssen, um von dieser Architektur am meisten zu profitieren. Die parallele Programmierung ist jedoch viel schwieriger als die sequentielle Programmierung, da sie viele neue Herausforderungen mit sich bringt (eine umfassende Übersicht finden Sie im Wiki-Artikel ).

Funktionale Programmierung hilft dabei, einige dieser Herausforderungen zu bewältigen, z. B., dass die Rennbedingungen nicht zutreffen, wenn Sie nur unveränderliche Variablen und Methoden ohne Nebenwirkungen verwenden. Die Lernkurve für die funktionale Programmierung ist oft steil, aber die Lernkurve für die parallele Programmierung ist möglicherweise noch steiler und überhaupt nicht intuitiv.

Wenn die Herausforderung darin besteht, effizientere Programme auf effizientere Weise zu schreiben, können die Kosten für die Schulung von Personen zum Schreiben paralleler Programme mit den Kosten für die Schulung von Personen zum Erlernen der funktionalen Programmierung und den Risiken verglichen werden, die mit beiden Ansätzen verbunden sind.

In Bezug auf gemischte Sprachen (die sowohl den funktionalen als auch den imperativen Programmierstil unterstützen): Von einem Punkt aus könnten sie für den Übergang nützlich sein (die Leute könnten anfangen, sie auf "vertraute" Weise zu verwenden und allmählich neue Ansätze erlernen). Von einem anderen Punkt aus könnte dies ein Segen sein, da die potenziellen Vorteile, die die funktionale Programmierung mit sich bringt, mit dem ungeschickten Code von jemandem aufgehoben werden könnten. Dies kann durch die Festlegung klarer Kodierungsrichtlinien (siehe z. B. " Effective Scala " von Twitter) gemildert werden. Die Einhaltung dieser Richtlinien setzt jedoch eine gewisse Teamreife voraus. Unter diesem Gesichtspunkt könnten reine Funktionssprachen für die Softwareentwicklung "einfacher" sein, da sie strengere Regeln enthalten.

Ashalynd
quelle
Wenn Sie aktuelle Nachforschungen / Beweise für diese Behauptungen finden können, die sie stützen - insbesondere "Funktionale Sprachen helfen, einige dieser Herausforderungen zu bewältigen" -, ist dies wahrscheinlich die beste verfügbare Antwort.
DVK
Genau diese Frage wurde bereits einige Male diskutiert, z. B. quora.com/Why-does-functional-programming-favor-concurrency oder stackoverflow.com/questions/474497/…
Ashalynd
3
Abgesehen davon, dass viele OOP-Sprachen auch die funktionale Programmierung unterstützen, können Sie die funktionalen Aspekte beim Ausschütten des Babys mit dem Badewasser nutzen.
Andy
1
Richtig, es ging um "funktionale Programmierung", nicht um "funktionale Sprachen". Ändert den Wortlaut.
Ashalynd
40

Sie nähern sich dem von der falschen Seite. In den meisten Unternehmen ist das Management nicht für die "Auswahl des Programmierparadigmas" verantwortlich. Sie sind (oder sollten es zumindest sein) dafür verantwortlich, dass das Team effizient arbeitet. Wenn Ihr gesamtes Team davon überzeugt ist, dass funktionale Programmierung die Geschwindigkeit oder Qualität Ihrer Arbeit verbessert, sollte es nicht zu schwierig sein, das Management zu überzeugen. Wenn Ihr Team erst anfängt, funktionale Konstrukte in Ihren etablierten Programmiersprachen zu verwenden, und jeder damit einverstanden ist, sollten Sie nicht einmal um Erlaubnis bitten müssen (zum Teufel, ein Nicht-Programmierer versteht möglicherweise nicht einmal den Unterschied zwischen Nicht-Programmierern). funktionale und funktionale Konstrukte, warum wollen Sie dieses Thema mit ihm besprechen?).

Aber Vorsicht, wenn der Rest Ihres Teams eine andere Meinung zu FP hat und sich über Ihren Funktionscode beschwert, den andere Teammitglieder nicht verstehen, könnten Sie Probleme mit dem Management bekommen - aus gutem Grund, da in einem solchen Fall In diesem Fall verliert das Team an Effizienz.

Das Wichtigste ist also: Überzeugen Sie andere Teammitglieder oder Ihre Teamleiter, aber nicht das Management auf höchster Ebene!

EDIT: aufgrund deines Kommentars - eigentlich ist das eine Antwort auf deine Frage ;-). Das einzige sachliche Argument, über das ich spreche, lautet: "Das gesamte Team ist der Meinung, dass FP für die Erledigung der Aufgabe hilfreich ist . IMHO ist dies das Argument mit der höchsten Wahrscheinlichkeit, dass es vom Management auf hoher Ebene akzeptiert wird, und es ist sehr praktisch anwendbar. Der Versuch, technische Argumente zu verwenden Nicht-technischen Personen direkt arbeiten selten, nicht weil sie "zu dumm sind, um die technischen Argumente zu verstehen", sondern weil sie klug genug sind zu wissen, dass technische Entscheidungen von technischen Experten getroffen werden sollten, und sie sind auch klug genug, sich nicht zu verlassen auf die Meinung von nur einem Experten.

Doc Brown
quelle
7
Ich bin erstaunt, dass 19 Personen eine Antwort abgegeben haben, die die Frage überhaupt nicht beantwortet . Es ist eine praktische Frage in einer praktischen Situation. Teammitglieder haben KEINE Stimme und müssen nicht überzeugt werden. Sie werden auch nicht an nicht genehmigter Technologie / Sprache arbeiten - und ich auch nicht -, wie die Frage kristallklar machte.
DVK
1
@DVK Wenn niemand Ihren Code sieht, müssen Sie niemanden davon überzeugen, dass Ihre Sprache gut ist. Beginnen Sie einfach damit.
user253751
2
@DVK - Sie müssen mehr Informationen darüber bereitstellen, wie das Management die in Ihrem Unternehmen verwendeten Sprachen steuert. In den meisten Fällen hat das Management in diesem Bereich wenig Einfluss, da sie es den Teams und ihren Führungskräften überlassen.
JeffO
3
@DVK: Die Leute stimmen den Antworten zu, die sie für die jeweilige Frage am hilfreichsten finden. Wenn die meisten Leute Antworten hochstimmen, die besagen, dass Sie sich dem falschen Problem nähern, könnte dies darauf hindeuten, dass eine große Anzahl von Programmierern ähnliche Situationen erlebt hat und diese "Nicht-Antworten" hilfreich fanden. Die meisten sind sich einig, dass Ihr Unternehmen von Grund auf ungesund ist und nichts mit der Wahl der Sprache zu tun hat. Die meisten sind sich einig, dass dies angegangen werden muss. Jeder Versuch, sich direkt für eine Sprache zu entscheiden, führt Sie lediglich zum nächsten Hindernis und nicht zu einer Reihe von Lösungen.
Cort Ammon - Wiedereinsetzung von Monica am
1
@CortAmmon Ich stimme zwar zu, dass die Frage auf einen Fehler bei der Verwaltung des Unternehmens des Fragestellers hinweist, aber es ist höchst unwahrscheinlich, dass er in der Lage ist, solche Probleme zu beheben. Ich habe aus erster Hand gesehen, welche Probleme ein CTO verursachen kann (in der Tat musste ich erst gestern viel Zeit aufwenden, um ein Problem zu lösen, das durch die Regel verursacht wurde, dass unser Unternehmen keine Software außerhalb der "Programmdateien" bereitstellt "Verzeichnisse auf Windows-Rechnern, aber Ruby wird nicht in einem Verzeichnis mit einem Leerzeichen im Namen installiert.
Jules
16

Um zu verstehen, warum Functional Programming nicht die Welt erobert hat, müssen Sie das unternehmerische Denken verstehen, das hinter Programmiersprachenentscheidungen steht. So greifen Sie für einen Moment zu Java:

  1. Es gibt Armeen von Programmierern, die Unmengen von gewöhnlichem Java-Code schreiben können. Dies gilt nicht für Lisp- oder Haskell- (oder sogar Scala-) Programmierer.
  2. Alle anderen verwenden Java, es muss also gut sein. Korrektur: Manager müssen ihre Entscheidung für Java nicht mit einer unbekannten Sprache abgleichen, von der noch niemand in der Befehlsstruktur etwas gehört hat.

Wenn Ihre Organisation bereits im Königreich der Nomen verankert ist, wird eine umfassende Änderung der funktionalen Programmierung einfach nicht stattfinden. Die Sprachauswahl (und alle anderen sie umgebenden Optionen) ist bereits tief in der Unternehmenskultur verankert.

Angenommen, Ihr Ziel ist es, als Softwareentwickler zu wachsen

  1. Integrieren Sie funktionale Konzepte in Ihre bestehenden Programme, wo sie nützlich und angemessen sind.
  2. Verwenden Sie die neuen funktionalen Sprachfunktionen, wenn sie der Sprache hinzugefügt werden
  3. Lernen Sie objektorientierte Entwurfsmuster, von denen einige existieren, um die Sprachmängel in OO-Sprachen zu überwinden, die in funktionalen Sprachen nicht vorhanden sind.

Die Argumente von Paul Graham gelten eigentlich nur für Startups, und es gab eine Reihe von Warnmeldungen zu Unternehmen, die mit rein funktionalen Sprachen angefangen haben, aber dann von einem anderen Unternehmen aufgekauft wurden, dessen erste Aufgabe darin bestand, die Basis des funktionalen Codes sofort umzustellen zu einer OO-Sprache, so dass ihre vorhandenen Software-Entwickler es verstehen könnten.

Robert Harvey
quelle
1
Nein, mein Ziel ist es NICHT (im Sinne dieser Frage), "als Softwareentwickler zu wachsen". Mein Ziel ist es, die bestmöglichen Argumente zu sammeln, um sie den Menschen vorzustellen, die Entscheidungen treffen, und sie dazu zu bewegen, FP als anerkannten Ansatz zuzulassen. Nicht mehr und nicht weniger. Hervorheben der Vorteile von FP, insbesondere im Vergleich zu Standard-OOP / -Prozedural-Stacks.
DVK
Außerdem bedeutete die Frage, es sei denn, ich habe einen wesentlichen Schreibfehler begangen, definitiv nicht, auf eine "umfassende Änderung" als beabsichtigtes Ergebnis der angestrebten Argumente hinzuweisen.
DVK
+1 für das Königreich der Substantive. Ich habe es "Der Krieg zwischen Substantiven und Verben" genannt.
Rob
4
@DVK: Die Art und Weise, das Management von irgendetwas zu überzeugen, ist seit jeher dieselbe: Zeigen Sie ihnen, wie sie damit Geld sparen können.
Robert Harvey
9

Nach meiner (etwas zynischen) Erfahrung haben wir für ein Geschäft gearbeitet, in dem wir funktionale Programmierung verwendet haben, und bei mehreren anderen interviewt:

  1. Es gab immer einen CTO und andere hochrangige Techniker, die Erfahrung mit funktionaler Programmierung hatten und es schafften, die nicht-technischen Führungskräfte davon zu überzeugen. (Und im Übrigen können diese Leute Ihre Frage besser beantworten als ich.)
  2. Sobald diese Leute die Firma verlassen und durch Leute ersetzt werden, die diese Neigung nicht haben, werden die Dinge nach Süden gehen. Die neuen Leute werden alles, was schief geht (einschließlich ihrer eigenen Fehler), auf die seltsame Programmiersprache und das Paradigma zurückführen, die verwendet wurden, um das zu bauen, was vorher war. Sie werden die verbleibenden Leute mit funktionalen Programmierkenntnissen an den Rand drängen und sie aus dem Unternehmen verdrängen. Das System, das auf der funktionalen Sprache basiert, wird sich ohne Wartung verschlechtern. Dies ist meines Erachtens das größte Risiko, das ein Unternehmen eingeht, wenn es eine funktionierende Sprache verwendet und das nicht unterschätzt werden darf.
  3. Damit dies funktioniert, muss die Organisation über eine Kultur verfügen, die das Bauen statt Kaufen vorsieht. Weil die Übernahme einer funktionalen Sprache weniger "Kauf" -Optionen bedeutet.
  4. Es gab fast immer einige Kompromisse auf die technischen und nicht-technischen Verleumder der Idee. Der häufigste dieser Kompromisse ist, dass alle Nicht-JVM-Sprachen nicht berücksichtigt wurden. Clojure und Scala wurden vorgeschlagen, Haskell und O'Caml waren von Anfang an dabei.
Sacundim
quelle
4

Dinge, die für das obere Management zu beachten sind, wenn das obere Management an der Auswahl der Programmiersprachen beteiligt ist (was seltsam ist, sollten sie vertrauenswürdigen, sachkundigen Personen überlassen (sowohl Technologie- als auch Geschäftssinn):

  • Produktivität
    • Sowohl aktuelle als auch zukünftige Mitarbeiter
    • Alle Rollen (Architekten, Entwickler, Tester, OPs, ...)
  • Unterstützte Plattformen
    • Betriebssysteme (Hardware?)
  • Herausgeber der Sprache / Plattform
    • Lizenzen
  • Reifegrad der Sprache / Plattform
    • Unterstützung von / durch den Verlag und / oder die Community
    • Bibliotheken
  • Migrieren der aktuellen Codebasis
    • Oder Integration mit

Beachten Sie, dass diese nicht spezifisch für funktionale Programmiersprachen sind. Dies sind auch keine Argumente, es sei denn, Sie geben Daten mit diesen an. Wir können Ihnen keine Daten zur Verfügung stellen, da diese vollständig von der Umgebung Ihres Unternehmens abhängen. Das Einzige, was wir tun können, ist, Daten aus dem Internet zu sammeln, um zu zeigen, wie viel Wissen und Interesse für eine bestimmte Sprache besteht. Seien Sie vorsichtig, wenn Sie viele Fragen zu StackOverflow oder viele Tags auf Linkedin in eine beliebte Sprache übersetzen.

Erno
quelle
1
Unternehmen sind auch besorgt über die Einstellung von Mitarbeitern. Wenn es also schwieriger ist, einen funktionierenden Entwickler zu ersetzen, würde ich sagen, dass dies ein guter Grund für sie ist, sich an solchen Entscheidungen zu beteiligen.
Andy
1
@Andy - Ja, aus diesem Grund lehne ich die Frage nicht ab und denke, Manager sollten sich für die von mir genannten Themen interessieren. Ich mache mir mehr oder weniger Sorgen, dass die Lösung (Functional Programming Languages) ausgewählt wird, BEVOR das Problem (???) definiert wird.
Erno
Ist es wirklich so schwer, einen funktionalen Entwickler zu ersetzen? An der Anzahl der informierten Entwickler, die hier und auf anderen Websites im Internet posten, schätze ich, dass es wesentlich mehr funktionale Entwickler gibt, als Manager glauben.
Giorgio
@ Giorgio - Ich habe nie gesagt, dass es schwierig ist, sie zu ersetzen, aber meiner Erfahrung nach kann die Verfügbarkeit von Ort zu Ort unterschiedlich sein. Einige Hochschulabsolventen haben noch nie die Grundlagen erlernt, während sich einige Universitäten darauf spezialisiert haben. Für ein Unternehmen ist es sehr wichtig, auf die Langfristigkeit und den zu erwartenden Bedarf an Neueinstellungen zu achten.
Erno
@Erno: Ich stimme deiner Ansicht zu. Ich habe Andys Kommentar kommentiert. Wie auch immer, ich habe immer angenommen, dass es nur sehr wenige funktionierende Programmierer gibt und dass FP als etwas Esoterisches angesehen wird. In letzter Zeit habe ich eher den Eindruck, dass es viel mehr FP-Entwickler gibt als FP-Jobs.
Giorgio
3

Ich glaube nicht, dass Argumente oder Fakten helfen werden. Und schon gar nicht ohne Angabe der Probleme, die Sie lösen möchten.

Gegen den gängigen Glauben und die typische Selbsteinschätzung werden viele Entscheidungen auf der Grundlage des Bauchgefühls getroffen. Und oft sind diese Entscheidungen sehr gute Entscheidungen, weil sie auf unbewusster Ebene viel Erfahrung des Einzelnen beinhalten, der die Entscheidung trifft.

Wenn Sie eine solche Entscheidung anfechten möchten, wie "Wir werden uns bis zum Ende aller Computer an C-ähnliche Sprache halten", müssen Sie mehr tun, als nur einige Argumente anzugeben.

Der erste Schritt besteht wahrscheinlich darin, die Personen und Gründe für die Entscheidung aufzudecken, dass die Geschäftsleitung bei solchen technischen Entscheidungen ein Mitspracherecht haben sollte. Natürlich kann ich hier nur raten, aber es ist sehr wahrscheinlich, dass sie eine ganze Reihe von Entscheidungen getroffen haben, die vom technischen Personal getroffen wurden. Seien wir ehrlich: Die meisten Entwickler sind nicht sehr gut darin, (sogar technische) Entscheidungen auf Unternehmensebene zu treffen.

Sobald Sie diese Leute gefunden haben, sprechen Sie mit ihnen, um dort Vertrauen zu gewinnen. Möglicherweise ist der beste Ansatz: hören Sie ihnen zu. Worüber sorgen sie sich, welches Risiko und welche Chancen sehen sie. Mit welchen Problemen werden sie konfrontiert? Von hier aus könnten Sie Techniker in diese Art von Entscheidung einbeziehen. Das Management möchte diese Entscheidungen oft nicht wirklich treffen, vertraut sie aber anderen nicht an. Wenn Ihr Team also beginnt, sich auf architektonische Entscheidungen einzulassen und zu zeigen, dass die von Ihnen vorgeschlagenen Entscheidungen ein solides Management sind, ist es möglicherweise gewillt, Ihnen / Ihrem Team zu vertrauen.

Wichtig für fundierte Architekturentscheidungen ist:

  • Sammeln Sie Input von Stakeholdern (Management, Benutzer, Administratoren, Vertrieb, Kunden ...)
  • Basisentscheidungen auf dieser Eingabe
  • Klar kommunizieren: Was sind die (vorgeschlagenen) Entscheidungen? Welches Risiko wollen sie abmildern? Was widersprüchliche Interessen sind und mit einiger Verspätung: Wie gut haben sie funktioniert?

Wenn Sie für ein großes Unternehmen mit mehr als 10.000 Mitarbeitern arbeiten, sollten Sie einige der folgenden Lektionen lernen.

  • Die Geschwindigkeit der Codierung ist für das Endergebnis nicht wirklich relevant.
  • Dinge wie Wartbarkeit im Maßstab von Jahrzehnten ist.
  • Die Probleme, die Sie Ihrer Meinung nach mit funktionalen Sprachen lösen können, sind für das Endergebnis nicht wirklich relevant
  • Probleme wie die Schulung von 1000 Entwicklern, der natürliche Widerstand gegen Änderungen und die Aufrechterhaltung einer Codebasis, die von Entwicklern mit weniger als 5 Jahren Erfahrung in der verwendeten Technologie geschrieben wurde, sind.

Sobald Sie ein Vertrauensniveau erreicht haben, in dem Ihre Argumente Gehör finden und berücksichtigt werden, haben Sie auch eine Methode entwickelt, um Anforderungen zu erfassen und zu berücksichtigen, denen Sie, Ihr Team und das Management vertrauen.

Wenn dieser Prozess zu der Empfehlung führt, in bestimmten Bereichen einen funktionalen Ansatz zu verwenden, sind Sie fertig.

Wenn dieser Prozess die Empfehlung enthält, funktionale Ansätze zu ignorieren, die über das hinausgehen, was die aktuelle Programmiersprache bietet, sind Sie ebenfalls fertig.

Die schlechte Nachricht ist: Je nach Größe und Stil des Unternehmens kann dies einige Jahre oder Jahrzehnte dauern.

Die gute Nachricht ist: Sie werden unterwegs viel lernen.

Da der erste Schritt darin besteht, mit dem Sprechen zu beginnen und vor allem der Geschäftsleitung zuzuhören, empfehle ich, mit dem Lesen von Just Listen zu beginnen .

Jens Schauder
quelle
3

Ein guter Ansatz wäre zu zeigen, dass es gute Ergebnisse in der Branche gezeigt und angenommen hat.

Sie können einige Daten erhalten von:

Versuchen Sie im Idealfall, mit den Managern einiger börsennotierter Unternehmen zu sprechen, insbesondere in Ihrer Branche, und lassen Sie sich von ihnen Zahlen und Zeugnisse geben.

Google hat viele andere ähnliche Links für Haskell, OCaml usw.

LispGood
quelle
3
Einige Unternehmen werden dies als einen Fall dagegen ansehen , da OO-Praktiker die Anzahl der FP-Anhänger bei weitem übersteigen .
Robert Harvey
1
@RobertHarvey - das ist, zumindest in meinem speziellen Fall, ein bisschen wie ein roter Hering. Sie sind bereits intelligent genug, um DAS zu wissen. Was sie NICHT wissen (und was ich aus dieser Antwort herausgefunden habe) ist, dass Eaton Vance Scheme und vor allem Faceboook , BoA / ML, Deutsche Bank und Google [verwenden Haskell] verwendet. Das heißt, es ist etwas, woran sie denken KÖNNEN, einen Zeh einzutauchen, da sich andere Würdige dafür entschieden haben. Erstaunlich, dass die einzige wirklich nützliche Antwort, die versucht hat, die von mir gestellte Frage zu beantworten (und nicht die, auf die man antworten wollte), die mit den wenigsten Stimmen ist
DVK
1
@dvk: Die Frage, die Sie gestellt haben (wenn ich sie richtig verstehe), lautet: "Wie kann ich meine Chefs davon überzeugen, dass FP eine gute Sache ist?" Manchmal ist es nicht so. Wir leben in einer veränderlichen Welt und Functional Programming ist, ganz ehrlich gesagt, ein bisschen seltsam. Wenn Sie mir nicht glauben, schauen Sie sich Monaden an. Antworten, die sich mit diesen Kuriositäten befassen (und wie sie sich auf den Software-Design- und -Entwicklungsprozess auswirken), sind nützlich, unabhängig davon, ob Sie dies für sinnvoll halten oder nicht.
Robert Harvey
@RobertHarvey (1) Ich nehme das zurück. Jetzt haben ZWEI der nützlichen Antworten die niedrigste Bewertung :) (eine neue, die gerade veröffentlicht wurde, könnte mit Fakten verbessert werden, ist aber ein guter Anfang).
DVK
@RobertHarvey - ja. Die Frage war NICHT "Ist FP eine gute Sache" oder "Ist es möglich, Leute davon zu überzeugen, dass FP eine gute Sache ist". Die Frage lautete sehr genau: "Welche Argumente können verwendet werden, um WENN zu überzeugen, dass es eine gute Sache ist?". Es war NICHT "Wie kann ich FP in meiner Arbeit / Codierung auf eine positive Art und Weise heimlich einführen", wie Sie geantwortet haben - wenn dies eine Option wäre, die ich nicht an erster Stelle fragen würde, würde ich codieren: )
DVK
2

Sie kommen aus der falschen Richtung.

Sie versuchen, das Management von einem Wechsel zu einem Funktionsparadigma zu Ihrer eigenen Unterhaltung zu überzeugen, und Sie versuchen, Argumente einzubringen, um dies zu unterstützen, die nichts mit dem wahren Grund zu tun haben, warum Sie es wollen. Andernfalls müssten Sie die Frage nicht stellen, da Sie Ihre Argumente von oben auflisten können.

Vielmehr sollten Sie darüber nachdenken, was das aktuelle Geschäftsbedürfnis ist und wie es am besten bedient wird. Wenn es so kommt, dass es am besten mit einem Funktionsparadigma bedient wird, dann - yay! - Du darfst spielen. Aber wenn Sie eine faire Analyse unter Berücksichtigung der betrieblichen Geschäftsanforderungen, der erforderlichen Schulung der Mitarbeiter, des Hintergrunds zukünftiger Programmierer, der Wartung usw. durchführen, wird dies häufig nicht der Fall sein.

Anonymer Feigling
quelle
2
Dies ist ein bisschen umständlich und nicht allzu hilfreich bei der Beantwortung der Frage, die nicht nur dazu dienen sollte, OP bei seinem "Ansatz" zu unterstützen.
VF1
1

Führungskräfte ohne technische Kenntnisse sollten sich nicht um technische Aspekte wie die Verwendung von Funktionsparadigmen kümmern. Dies ist nicht ihr Fachgebiet und riecht nach Mikromanagement. Warum delegieren sie diese Entscheidungen nicht an Personen, die tatsächlich über die erforderlichen Fähigkeiten verfügen?

Vor diesem Hintergrund finden Sie hier einige Hinweise, um Menschen mit technischem Hintergrund (erster Fall) und solche ohne (zweiter Fall) zu überzeugen.

Erster Fall

Wenn Sie mit Leuten sprechen, die mit Programmieren vertraut sind, kann der Vergleich von Code, der ohne funktionale Programmierparadigmen geschrieben wurde, und demselben Code, der in funktionalem Stil geschrieben wurde, überzeugend genug sein:

Beispiel-C # -Code im imperativen Stil:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Derselbe Code wurde unter Berücksichtigung der funktionalen Programmierung umgeschrieben:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Dann frag sie:

  1. Wie viele Fehler kann ein Programmierer im ersten Beispiel machen? Was ist mit dem zweiten?

  2. Wie schwer ist es, Fehler zu erkennen?

  3. Wie schwierig ist es, Code zu ändern?

Alle drei Faktoren beeinflussen die Produktivität und damit die Produktkosten.

Zweiter Fall

Wenn Sie mit Leuten zu tun haben, die sich mit Programmieren nicht auskennen, können Sie ihnen nicht viel technisches erzählen. Überzeugend ist unter anderem, die tatsächlichen Auswirkungen von Funktionsparadigmen auf Ihre Arbeit und die Arbeit Ihrer Mitarbeiter aufzuzeigen.

Vergleichen Sie beispielsweise zwei Projekte desselben Teams, eines mit FP, das andere ohne FP. Zu zeigen, dass die Anzahl der Bugs viel geringer ist oder dass dies das erste Projekt war, das das Unternehmen tatsächlich pünktlich geliefert hat, sollte überzeugend genug sein.

Arseni Mourzenko
quelle
3
Ich verstehe, was Sie dort getan haben, aber Ihr Beispiel ist nicht ganz überzeugend. Sie haben Ihr funktionales Beispiel im Grunde genommen in ein imperatives Beispiel umgewandelt, was in keinem praktischen Unternehmensanliegen vorkommen würde. Sie yield returnsind ein kleiner Betrüger. Dies ist ein Beispiel dafür, wie Sie Code für die Verwendung in einem Linq-Szenario vorbereiten würden, und Ihre ifAnweisungen könnten mit ternären Operatoren prägnanter geschrieben werden. Ihr gesamtes erstes Beispiel könnte in Imperativfunktionen umgestaltet werden, so dass die Komplexität verborgen bleibt.
Robert Harvey
@RobertHarvey Sie könnten das erste Beispiel in eine Reihe von Imperativfunktionen umgestalten, aber es wären benutzerdefinierte Imperativfunktionen, die für diese Abfrage spezifisch sind. Sie müssten immer noch alles sehen, um sich von der Richtigkeit der Abfrage zu überzeugen. Dieses Refactoring würde die Größe des Imperativ-Codes noch weiter erhöhen. Auch wenn Sie es genauso kompakt schreiben könnten, müssen Sie den Code dennoch sorgfältig lesen, da die ganze Arbeit durch Nebenwirkungen erledigt wird. Sie möchten nicht, dass ein Nebeneffekt im zweiten Teil eines ternären Operators am Ende einer Zeile ausgeführt wird.
Doval
1
@RobertHarvey Ich bin mir nicht einmal sicher, ob die beiden Codeausschnitte gleichwertig sind, da der Imperative durch Erstellen einer zweiten Liste "filtert", anstatt nur die Iteration zu überspringen. Würde das reale Äquivalent nicht nur eine Schleife verwenden und damit noch tiefer verschachtelt sein?
Doval
5
Es steht außer Frage, dass Sie die Integration funktionaler Konzepte in eine ansonsten zwingende / OO-Sprache gut begründen, aber nicht unbedingt die Verwendung vollständig funktionaler Sprachen in einer Unternehmensumgebung, die bereits eine zwingende / OO-Sprache ist.
Robert Harvey
Ein weiteres (vielleicht weniger gültiges) Problem mit Ihrem Beispiel: Ich könnte das erste Beispiel in vollständig lesbarem Perl schreiben, das größtenteils kein FP-Perl ist - ich vermute - in 30% des Volumens. Vielleicht weniger. Kommt darauf an, ob du map/ grepals Nicht-FP akzeptierst . IOW, Sie argumentieren, dass Java eine schlechte Sprache ist, nicht, dass FP ein guter Ansatz ist.
DVK