Üst düzey yönetimi işlevsel programlamayı düşünmeye ikna etmek için iyi olgusal argümanlar ne olurdu? [kapalı]

İşlevsel programlamanın neden İyi bir fikir olduğu konusunda tonlarca "teorik" argüman vardır (bunun açık bir soru olarak kalması için çok fazla ve doğru şekilde).

Ancak, bunların çoğu ya teoriden ("zarafet" vb.) Yapılmış ya da geliştiricilere yönelik argümanlardır.

Sorun şu ki, çoğu , fikri geliştirici olmayan ve hepsi de iş argümanlarını önemseyen büyük bir şirketin üst yönetimine fikri sunmak olduğunda çoğu işe yaramaz : maliyet, beşeri sermaye yönetimi , ürün teslimi, müşteri hizmetleri ve gelir; gerçeklerle desteklenemeyen teorik noktalar üzerindeki nicel gerçeklerin yanı sıra.

İşlevsel programlamanın bir kavram olarak (belirli bir dil değil) benimsenmesini , prosedürel / OOP'un tipik karışımını, örneğin Java / C ++ / (Perl | Python) karşılaştırmayı düşünürken, bu iş kaygılarını gidermek için herhangi bir zorlayıcı argüman var mı? .

Tercihen, nicel ve / veya araştırma veya vaka çalışmalarına dayanan argümanlar arıyorum. Örneğin, "bu referansa göre, Lisp / F # içindeki çok iş parçacıklı sistemlerin hata oranı Java'nın% 10'udur" veya "en iyi 3 ilgi alanına göre fonksiyonel programlama adı verilen istenen teknolojinin tercihlerini ifade eden üst düzey mezunların% 80'i" dir.

Bunu biliyorum Graham starup için fonksiyonel programlama kullanım durumları sunuldu ve onlar daha büyük bir tesis şirket için geçerli olabilir varsayarak onun argümanları bazı açık olacaktır.

_{ps Perl, muhtemelen Python ve (muhtemelen) Java 8 veya C ++ 14'te işlevsel programlamaya yakın bir şey yapabileceğinizin farkındayım. Ancak bu, Perl, C ++ veya Java kullanan bir kuruluşun işlevsel vs'yi destekleyeceği anlamına gelmez. Bu dillerde bile OOP / prosedürel yaklaşımlar}

_{Bu dilin amaçları doğrultusunda, "büyük", tüm geliştiricilerin kullanmasına / yapmasına izin verildiğini belirleyen özel geliştirme mühendisliği / araçlar grubuna sahip olacak kadar büyük olarak tanımlanır; ve en az yüzlerce geliştirici düşük uçta} .

En azından yönetimi eğlendirebilecek çok basit bir argüman var.

Modern bilgisayarların eskisi gibi "daha hızlı" olmadıkları iyi bilinmektedir, çünkü frekans ölçeklendirme şimdilik sınırlara ulaştı. Çekirdek ekleyerek potansiyel üretkenliklerini arttırırlar.

Bu, bu mimariden en iyi şekilde yararlanmak için programların paralelleştirilmesi gerektiği anlamına gelir. Ancak paralel programlama, getirdiği birçok yeni zorluk nedeniyle sıralı programlamadan çok daha zordur ( kapsamlı genel bakış için Wiki makalesine bakın ).

İşlevsel programlama bu zorluklardan bazılarından kurtulmanıza yardımcı olur, örneğin sadece yan etkileri olmayan değişmez değişkenleri ve yöntemleri kullanırsanız yarış koşulları geçerli değildir. Fonksiyonel programlama için öğrenme eğrisi genellikle diktir, ancak paralel programlama için öğrenme eğrisi daha dik olabilir ve hiç de sezgisel olmayabilir.

Dolayısıyla, zorluk daha verimli programlar daha verimli bir şekilde yazmaksa, insanların paralel programlar yazma eğitim maliyetlerini, fonksiyonel programlamayı öğrenmeleri için eğitim maliyetleri ve her iki yaklaşımın da getirebileceği riskler karşılaştırabiliriz.

Karma dillerle ilgili olarak (hem işlevsel hem de zorunlu programlama stilini destekler): bir noktadan itibaren geçiş için kullanışlı olabilirler (insanlar bunları "tanıdık" şekilde kullanmaya başlayabilir ve yavaş yavaş yeni yaklaşımlar öğrenebilir). Başka bir noktadan, bu kılık değiştirmiş bir nimet olabilir, çünkü fonksiyonel programlamanın getirdiği potansiyel avantajlar birinin sakar koduyla iptal edilebilir. Bu kurallara uymak belirli bir takım olgunluk gerektiriyor olsa da, açık bir kodlama yönergeleri oluşturarak bunu hafifletebilir (örn . Twitter tarafından " Etkili Scala "). Bu açıdan bakıldığında, saf fonksiyonel diller, tasarımla getirdikleri daha katı kurallar nedeniyle yazılım geliştirme için "daha kolay" olabilir.

Buna yanlış taraftan yaklaşıyorsunuz. Çoğu şirkette yönetim, "programlama paradigmasını seçmek" ten sorumlu değildir, ekibin verimli çalışmasını sağlamaktan sorumludur (veya en azından sorumludur). Ekibinizin tamamı işlevsel programlamanın işinizin hızını veya kalitesini artıracağına ikna olmuşsa, yönetimi ikna etmek de çok zor olmamalıdır. Dahası, ekibiniz yerleşik programlama dillerinizde fonksiyonel yapılar kullanmaya başlarsa ve herkes bundan memnunsa, izin istemeniz bile gerekmez (heck, programcı olmayan bir kişi arasındaki farkı bile anlamayabilir) işlevsel ve işlevsel yapılar, neden bu konuyu onunla tartışmak istiyorsunuz?).

Ancak, ekibinizin geri kalanının FP hakkında farklı bir fikri varsa ve diğer ekip üyelerinin anlamadığı işlevsel kodunuzdan şikayet etmeye başlarlarsa, yönetim ile sorun yaşayabilirsiniz - iyi bir nedenden dolayı, böyle bir durumda, ekip verimliliği kaybeder.

Yani asıl konu: diğer ekip üyelerini ya da ekip liderlerini ikna etmek, fakat üst düzey yönetimi değil!

DÜZENLEME: Yorumunuza nedeniyle - aslında, bu ise sorunuzun ;-) bir cevabı. Bahsettiğim tek bir argüman, "tüm ekip FP'nin işi yapmak için yararlı olduğunu düşünüyor . IMHO, üst düzey yönetim tarafından kabul edilen en yüksek arı olma şansı olan argüman ve pratik olarak uygulanabilir. Teknik argümanlar kullanmaya çalışmak teknik olmayan insanlara nadiren çalışırlar, çünkü "teknik akıl yürütmeyi anlamayacak kadar aptallar" değil, teknik kararların teknik uzmanlar tarafından alınması gerektiğini bilecek kadar akıllı oldukları ve güvenmeyecek kadar akıllı oldukları için sadece bir uzmanın görüşü üzerine.

Fonksiyonel Programlamanın neden dünyayı ele geçirmediğini anlamak için, programlama dili kararlarının ardındaki kurumsal düşünceyi anlamanız gerekir. Java'yı bir süreliğine seçmek için:

1. Sıradan Java kodu yığınları yazabilen programcı orduları vardır. Bu Lisp veya Haskell (hatta Scala) programcıları için geçerli değildir.
2. Diğer herkes Java kullanıyor, bu yüzden iyi olmalı. Corrolary: yöneticiler, komut yapısında hiç kimsenin duymadığı bazı gizli dillere karşı Java seçimlerini haklı göstermek zorunda değiller.

Kuruluşunuz zaten İsimler Krallığı'na yerleşmişse, Fonksiyonel Programlama'da toptan bir değişiklik yapmak sadece gerçekleşmeyecektir. Dil seçimi (ve onu çevreleyen diğer tüm seçimler) şirket kültürüne derinden gömülüdür.

Hedefinizin bir yazılım geliştiricisi olarak büyümek olduğunu varsayarsak, en iyi seçenek

1. İşlevsel kavramları mevcut programlarınıza yararlı ve uygun olan yerlerde dahil edin ,
2. Yeni işlevsel dil özelliklerini dile eklendikçe kullanın ve
3. İşlevsel dillerde bulunmayan OO dillerindeki dil eksikliklerinin üstesinden gelmek için var olan nesne yönelimli tasarım modellerini öğrenin.

Paul Graham'ın argümanları gerçekten sadece yeni başlayanlar için geçerlidir ve tamamen İşlevsel dilleri kullanmaya başlayan şirketlerin birkaç uyarıcı öyküsü vardır, ancak daha sonra ilk iş emri fonksiyonel kod tabanını hemen dönüştürmek olan başka bir şirket tarafından satın alınmıştır. mevcut yazılım geliştiricilerinin anlayabilmesi için bir OO diline çevirin.

(Biraz alaycı) tecrübemde, fonksiyonel programlamayı kullandığımız bir dükkanda çalışmış ve başkalarıyla görüşmüştük:

1. Her zaman bir CTO ve fonksiyonel programlama konusunda deneyim sahibi olan ve teknik olmayan yöneticilerini ikna etmeyi başaran diğer üst düzey teknik insanlar vardı. (Ve bu arada, bu insanlar sorunuzu cevaplamak için benden daha nitelikli.)
2. Bu insanlar şirketten ayrıldıktan ve yerini bu eğilime sahip olmayan kişiler aldığında, işler güneye gider. Yeni adamlar, daha önce gelenleri inşa etmek için kullanılan garip programlama dili ve paradigması hakkında yanlış giden her şeyi (ve özellikle kendi başarısızlıklarını da dahil olmak üzere) suçlayacaklar. Kalan insanları fonksiyonel programlama becerileri ile marjinalleştirecek ve onları şirketten çıkaracaklar. İşlevsel dil üzerine kurulmuş olan sistem bakımsız olarak bozulacaktır. Bu tür bir şey, bence, bir işletmenin işlevsel bir dili benimsemesi durumunda üstlendiği en büyük risktir ve hafife alınmamalıdır.
3. Bunun çalışması için kuruluşun "satın almak yerine inşa" kültürüne sahip olması gerekir. Çünkü işlevsel bir dili benimsemek daha az "satın alma" seçeneği anlamına gelecektir.
4. Hemen hemen her zaman vardı bazı fikir, teknik ve teknik olmayan detractors uzlaşmadır. Bu uzlaşmalardan en yaygın olanı, JVM olmayan herhangi bir dilin dikkate alınmamasıdır; Clojure ve Scala önerildi, Haskell ve O'Caml hemen yarasadan çıktı.

Üst yönetim, programlama dillerinin seçiminde yer alırsa / varsa, dikkate alınması gerekenler (garip, güvenilir, bilgili kişilere bırakmaları gerekir (hem teknoloji hem de iş anlayışı):

• verimlilik
  • Hem mevcut hem de gelecekteki çalışanlar
  • Tüm roller (mimarlar, geliştiriciler, testçiler, OP'ler, ...)
• Desteklenen platformlar
  • İşletim sistemleri, (donanım?)
• Dilin / platformun yayıncısı
  • Lisanslar
• Dilin / platformun olgunluğu
  • Yayıncının ve / veya topluluğun desteği /
  • Kütüphaneler
• Geçerli kod tabanını taşıma
  • Veya ile entegrasyon

Bunların işlevsel programlama dillerine özgü olmadığını unutmayın. Bunlarla veri sağlamadığınız sürece bunlar da argüman değildir. Verileri tamamen işletmenizin ortamına bağlı olduğu için veremeyiz. Yapabileceğimiz tek şey, belirli bir dil için ne kadar bilgi ve ilgi olduğunu göstermek için web'den veri toplamaktır. StackOverflow ile ilgili birçok soruyu veya Linkedin'deki birçok etiketi popüler bir dile çevirirken dikkatli olun.

Tartışmaların veya gerçeklerin yardımcı olacağını düşünmüyorum. Ve kesinlikle çözmek istediğiniz sorunları belirtmeden değil.

Ortak inanca ve tipik öz değerlendirmeye karşı bağırsak hissine bağlı olarak birçok karar verilir. Ve çoğu zaman bu kararlar çok iyi kararlardır, çünkü bilinçaltına karar veren bireyin deneyimini içerirler.

"Tüm bilgisayarların sonuna kadar C diline sadık kalacağız" gibi bir karara itiraz etmek istiyorsanız, sadece bazı argümanlar sunmaktan daha fazlasını yapmanız gerekir.

İlk adım, büyük olasılıkla üst yönetimin bu tür teknik kararlarda söz sahibi olması gerektiği kararının arkasındaki kişileri ve nedenlerini ortaya çıkarmaktır. Tabii ki sadece burada tahmin edebiliyorum, ancak büyük olasılıkla teknik kişisel tarafından kötü bir şekilde alınan kararların geçmişine sahipler. Kabul edelim: Çoğu geliştirici şirket düzeyinde (hatta teknik) kararlar vermede çok iyi değildir.

Bir kez bu insanlar orada güven kazanmak için onlarla konuşmak bulundu. Muhtemelen en iyi yaklaşım şudur: onları dinleyin. Ne hakkında endişe ediyorlar, gördükleri risk ve şanslar neler? Karşılaştıkları sorunlar nelerdir. Buradan teknoloji insanlarını bu tür bir karara dahil etmek için harekete geçebilirsiniz. Yönetim genellikle bu kararları vermek istemez, ancak başkalarına bu konuda güvenmez. Dolayısıyla, ekibiniz mimari karara katılmaya başlar ve önerdiğiniz kararların sağlam bir yönetim olduğunu gösterirseniz size / ekibinize güvenmeye istekli olabilirsiniz.

Sağlam mimari kararlar bulmak için önemli olan:

• Paydaşlardan girdi toplama (Yönetim, Kullanıcılar, Yöneticiler, Satış, Müşteriler ...)
• Kararları bu girdiye dayandırın
• Açık bir şekilde iletişim kurun: (önerilen) kararların ne olduğu; Hangi riski azaltmayı hedefledikleri; Çatışan çıkarlar nedir ve bir miktar gecikme ile: ne kadar iyi çalıştılar.

10K + çalışanı olan büyük bir şirkette çalışıyorsanız, aşağıdaki derslerden bazılarını öğrenmeye hazır olun.

• kodlama hızı sonuç olarak gerçekten önemli değildir.
• onlarca ölçekte sürdürülebilirlik gibi şeyler.
• işlevsel dilleri kullanarak çözebileceğinizi düşündüğünüz sorunlar, sonuç olarak gerçekten alakalı değildir
• 1000 geliştiricinin eğitimi gibi problemler, değişime karşı doğal direnç ve kullanılan teknolojide 5 yıldan az deneyime sahip geliştiriciler tarafından yazılan bir kod tabanının korunmasıdır.

Argümanlarınızın duyulduğu ve dikkate alındığı bir güven seviyesine ulaştığınızda, sizin, ekibinizin ve yönetiminizin güvendiği gereksinimleri bir araya getirme ve dikkate almanın bir yolunu da bulacaksınız.

Bu işlem, belirli alanlarda işlevsel bir yaklaşım kullanma önerisi üretiyorsa, işiniz tamamlanmıştır.

Bu süreç, mevcut ana programlama dilinin size sunduklarının ötesine geçen fonksiyonel yaklaşımları göz ardı etme önerisini üretiyorsa, yapılır.

Kötü haber şu: Şirketin büyüklüğüne ve stiline bağlı olarak bu kolayca birkaç yıl veya on yıl alabilir.

İyi haber şu: Yolda çok şey öğreneceksiniz.

İlk adım konuşmaya başlamak ve özellikle üst düzey yönetimi dinlemek olduğundan, Just Listen okuma ile başlamanızı tavsiye ederim .

İyi bir yaklaşım, endüstride iyi sonuçlar gösterdiğini ve kabul edildiğini göstermek olacaktır.

Şuradan bazı veriler alabilirsiniz:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

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

İdeal olarak, listelenen bazı şirketlerin yöneticileriyle, özellikle de endüstrinizdeyken konuşmaya çalışın ve onlardan numaralar ve referanslar alın.

Google, Haskell, OCaml vb. İçin benzer birçok bağlantıya sahiptir.

Buna yanlış yönden geliyorsun.

Kendi eğlenceniz için işlevsel bir paradigmaya geçişin yönetimini ikna etmeye çalışıyorsunuz ve bunu desteklemek için gerçek nedenle ilgisi olmayan şeyleri desteklemek için tartışmalara girmeye çalışıyorsunuz. Aksi takdirde soruyu sormanıza gerek kalmaz, çünkü argümanlarınızı başınızın üstünden listeleyebilirsiniz.

Bunun yerine, düşünmeniz gereken şey mevcut iş gereksiniminin ne olduğu ve en iyi nasıl sunulduğudır. Böyle bir durumda en iyi şekilde işlevsel bir paradigma kullanılarak servis edilirse - yay! - oynayacaksın. Ancak, operasyonel iş ihtiyaçlarını, iş arkadaşlarının gerekli eğitimini, gelecekteki programcıların arka planlarını, bakımını vb. Dikkate alarak adil bir analiz yaparsanız, genellikle böyle olmaz.

Hiçbir teknik beceriye sahip olmayan üst yönetim, işlevsel paradigmaların kullanımı gibi teknik yönleri önemsememelidir. Bu onların uzmanlık alanı değil ve mikro yönetim kokuyor. Neden bu kararları gerçekten gerekli becerilere sahip kişilere devretmiyorlar?

Bununla birlikte, teknik geçmişi olan (ilk vaka) ve bir (ikinci vaka) olmayan insanları ikna etmek için bazı ipuçları var.

İlk dava

Programlamayı bilen insanlarla konuşuyorsanız , fonksiyonel programlama paradigmaları olmadan yazılan kodu ve işlevsel tarzda yazılmış aynı kodu karşılaştırmak yeterince ikna edici olabilir:

Zorunlu stili kullanan örnek C # kodu:

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);
}

Aynı kod işlevsel programlama dikkate alınarak yeniden yazılmıştır:

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))
    );

O zaman onlara sorun:

1. Bir programcı ilk örnekte kaç hata yapabilir? İkincisi ne olacak?

2. Hataları tespit etmek ne kadar zor?

3. Kodu değiştirmek ne kadar zor?

Her üç faktör de verimliliği ve dolayısıyla ürünün maliyetini etkiler.

İkinci dava

Programlamayı bilmeyen insanlarla uğraşıyorsanız, onlara söyleyebileceğiniz teknik bir şey yoktur. İkna olmanın yollarından biri, işlevsel paradigmaların sizin iş arkadaşlarınız ve işiniz üzerindeki gerçek etkisini göstermektir.

Örneğin, aynı ekip tarafından yapılan, biri FP kullanan, diğeri kullanmayan iki projeyi karşılaştırın. Hata sayısının çok daha düşük olduğunu veya şirketin zamanında teslim ettiği ilk proje olduğunu göstermesi yeterince ikna edici olmalıdır.