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

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} .

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.

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.

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.

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.

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.

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 .

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:

• http://www.quora.com/Welche-Unternehmen-verwenden-eine-Funktionssprache-als-an-Amtssprache

• http://pchristensen.com/blog/lisp-companies/

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.

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.

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.