Bir soruna yönelik programlama paradigması seçimi için ampirik kanıtlar

C2 wiki'sinin Nesne Odaklı Programlama için Ampirik Kanıtlar tartışması vardır. Bu son olarak 2008'de düzenlendi. Burada tartışma bunu ortaya koyuyor gibi görünüyor: OO'nun modası geçmiş olup olmadığı , işlevsel programlamanın kötü bir seçim olduğu ve AOP'nin avantajları ve dezavantajlarının tümü, kanıtlara dayanmadan katkıda bulunanların görüşleri ile cevaplanmaktadır.

Tabii ki, yerleşik ve tanınmış uygulayıcıların görüşleri hoş karşılanır ve değerli şeylerdir, ancak deneysel verilerle tutarlı olduklarında daha mantıklıdırlar. Bu kanıt var mı? Kanıta dayalı yazılım mühendisliğinin bir şey olduğunu biliyorum, ancak bu bağlamda pratik yapabilir miyim? Özellikle, Pyazılım yazarak çözmek istediğim özel bir sorunum varsa, sorun çözmenin sonucunun Pprogramlama paradigmasının seçimine nasıl bağlı olduğunu görmemi sağlayacak bir bilgi, çalışma ve araştırma grubu var mı?

Hangi paradigmanın "doğru cevap" olarak ortaya çıktığını biliyorum, belirli bir çalışmanın hangi metriklere dikkat ettiğini, çalışmanın hangi koşullara bağlı olduğunu veya değiştiğini ve şüphesiz diğer faktörlere bağlı olabileceğini biliyorum. Bu, bu bilgiyi bulma ve eleştirel olarak değerlendirme isteğimi etkilemez.

Bazı insanların "krank çevir" çözümü aradığımı düşündüğü anlaşılıyor - sorunum hakkında bilgi koyduğum ve "işlevsel" veya "yapılandırılmış" gibi bir kelime olan bazı sosis makinesi. Niyetim bu değil. Aradığım şey, buraya girmediğim çok sayıda uyarı ve varsayımla, ancak konuyla ilgili iyi literatürün nasıl olacağı üzerine araştırma yapmaktır. Yazılımın belirli özellikleri, soruna ve paradigma seçimine bağlı olarak değişir.

Başka bir deyişle: bazı insanlar "OO daha iyi esneklik verir" ya da "fonksiyonel programların daha az hataya sahip olduğunu" söylüyorlar. Geri kalanlar buna karşı kanıtlar ya da bu ifadelerin altında olduğu varsayımları ya da bu hususların önemli olmadığını gösteren kanıtlar istiyor. Bir paradigmanın neden diğerinden daha iyi olduğuna dair birçok görüş vardır; bunların arkasında objektif bir şey var mı?

Önceki yanıt için bu cevabın Revizyon 1'ine bakınız . Bununla birlikte, soruya yapılan yorumlar ve düzenlemeler sorunun ne aradığını daha da netleştirir ve daha net olmamı sağlar.

Evet, kanıta dayalı yazılım mühendisliği (EBSE) bir şeydir. Durham Üniversitesi ve SEED'de, Cal Poly'de bir profesör tarafından başlatılan EBSE veritabanlarına yönelik birkaç çaba var gibi görünüyor . Tüm bu çabaların yanı sıra IEEE Xplore sunucusu veya ACM Dijital Kütüphanesi'nde bulunabilecek bir dizi makalede ele alınanlar(her ikisinde de birçok makale için abonelik veya satın alma gereklidir) kanıta dayalı tıbba dayanmaktadır. Yayınlanmış ampirik (gözlem ve deney) verilerin literatür taramasını sağlarlar. Aslında, herhangi bir yayın aramasında bir arama dizesine "literatür taraması" dahil etmek çoğu konuda bilgi verir - ACM'de 14000'den fazla ve IEEE veritabanında 1000'den fazla isabet (yalnızca bilgi işlem konuları ile sınırlı olduğunda).

Bu EBSE veritabanlarında ve literatür incelemelerinde tartışılan genel konu türlerine baktığımda, ortak bir konu görüyorum - bunlar teknolojiden bağımsız olma eğilimindedir. Vurgu, yazılım mühendisliğini yürütmek için kullanılan özel araçlardan ziyade çoğunlukla süreç ve metodoloji etrafında toplanmış gibi görünmektedir.

Yani, bu kavram yazılım mühendisliğinde var. Academia kanıta dayalı kavramın farkındadır ve bunu yazılım mühendisliğine başarıyla uygulayabilir.

Özellikle, bir paradigma seçimine EBSE tekniklerinin uygulanmasına ilişkin soru, ilgili değişkenlerin sayısının fazla olması, varsayımların yapılmasını zorlamanın yanı sıra deneyi veya gözlemi tekrarlama yeteneğini azaltması nedeniyle zor görünmektedir. Sorunun tamında - "hangi paradigmanın" doğru cevap "olarak ortaya çıktığı söylenir, belirli bir çalışmanın hangi metriklere dikkat ettiğini, çalışmanın hangi koşulları tuttuğunu veya değiştiğini ve şüphesiz diğer faktörlere de bağlı olabileceğini" söyleyebilir . Bu, belirli bir durumda hangi paradigmanın "en iyi" çalışıldığı anlamına gelmese de, bu belgelerin her türlü literatür incelemesini tamamlamak ve bunlar arasında bilgi elde etmek için inanılmaz derecede zor hale getirir.

Bir paradigma seçmek için kesinlikle bir "krank çevirme" çözümü yoktur.

Bir programlama paradigması göz önüne alındığında, çeşitli akademik ve endüstri veritabanlarında, bu paradigmanın, yazılımın bilgi, deneyim ve deneyiminden çeşitli spesifik koşullar altında kalite, kusur, verimlilik vb. Çeşitli yönlerini nasıl etkilediğine ilişkin çalışmalar bulabilirsiniz. sorunlu etki alanına takım. Herhangi bir titiz kağıt, verilerin toplandığı koşulları ve varsayımları açıkça tanımlamalıdır. Sorun, bu koşulların her birinde iyi olmasını sağlayan faktörleri izole etmeye çalışmaktadır.

Akademik olarak, araştırılması kolay bazı ifadeler vardır. Örneğin, işlevsel paradigmanın eşzamanlılık gerektiren uygulamalar için çok uygun olduğu ifadesi Church-Rosser teoreminden kaynaklanmaktadır . Bu nedenle, işlevsel bir dilde yazılmış bir yazılım sisteminin eşzamanlılık ile ilgili olarak, yordamsal veya nesne yönelimli bir dilde yazılmış aynı sistemden daha az kusura sahip olması muhtemeldir.

Bununla birlikte, pratik bir bakış açısından, bir yazılım ekibi, sadece araştırma gösterdiği için iş için her zaman "en iyi" araç veya tekniği kullanamaz. En kaliteli yazılım sistemlerini üretmek için çaba göstersek de, kısıtlamalar dahilinde çalışıyoruz. Genellikle, herhangi bir metodolojinin etkinliğini tartışırken bu kısıtlamaların minimize edildiğini (hatta denklemden çıkarıldığını) görüyorum.

Bir uygulayıcı olarak, kullanılacak teknolojileri seçerken, mümkün olan en iyi araçları belirlemeye çalışıyorum. Ama sonra kendimi sahip olduğum ekip tarafından bilinen ve iyi anlaşılan şeyle sınırlandırıyorum. Önceki örneğime dönersek, C ++ 'da eşzamanlı uygulamalar oluşturma konusunda tecrübeli bir ekibim varsa ve Haskell'de deneyimim yoksa, muhtemelen yapamayacağım için Haskell'de sistem kurmayı önermek mantıklı değil zamanlama ve bütçe kısıtlamaları ve kalite, araç zincirindeki deneyim eksikliğinden dolayı etkilenecektir.

Özetlemek gerekirse, kanıta dayalı yazılım mühendisliği genellikle iyi bir şeydir ve literatür taramaları mevcuttur ve bunlar kolayca elde edilebilir. Bununla birlikte, kanıta dayalı yaklaşımların uygulanmasının çok az değer sağladığı yazılım mühendisliğinin bazı yönleri vardır. Programlama paradigmasının büyük ölçekli bir geliştirme çabasına seçilmesi bunlardan biridir.

İşlevsel programlamada nesne yöneliminin yeniden kullanılabilirliği veya kusurları nasıl ele aldığını öğrenmek istiyorsanız, bunlarla ilgili yayınları kolayca bulabilirsiniz. Ancak, gerçek dünyadaki yazılım mühendisliği projelerinin birçoğunda paradigma seçimini etkin bir şekilde ele alabilecek bir yayın bulamadım (veya herhangi bir güven duymayacağım).

Eric S. Raymond'un Unix Programlama Sanatı'nı okuyorum . Şu anda kabul ettiğimiz şeyler hakkında çok ilginç tarihi içgörüler var. Hata yoğunluğu gibi ampirik kanıtlar kullanan IEEE yazılımından bazı iyi çalışmalardan bahsediyor . Akademik tarzda çalışmalar arıyorsanız bu iyi bir kaynak olabilir.

İşlevleri kullanarak modülerleştirme gibi teknikler bile her zaman yaygın bir uygulama değildi. Şu ana kadarki kitaptan en sevdiğim alıntılardan biri:

Dennis Ritchie, işlev çağrılarının C'de gerçekten, gerçekten ucuz olduğunu söyleyerek modülerliği teşvik etti. Herkes küçük işlevler yazmaya ve modülerleştirmeye başladı. Yıllar sonra PDP-11'de fonksiyon çağrılarının hala pahalı olduğunu ve VAX kodunun zamanının% 50'sini CALLS talimatında geçirdiğini öğrendik. Dennis bize yalan söylemişti! Ama çok geçti; hepimiz bağlandık ...

- Steve Johnson

Yine de çok ampirik olmanın iki sorunu var. Birincisi, kod kalitesinin çok öznel bir şey olmasıdır. Kod korkunç olabilir ve yine de doğru olabilir. İnsanların bir programlama paradigması algısı çok geçerli bir metriktir, çünkü daha fazla olmasa bile insanların bilgisayarları kadar okuması için kod yazılmıştır.

İkinci sorun, geliştiricilerin% 50'sinin ortalama programlama yeteneğinin altında olmasıdır. Eğer "rabble" güzel, iyi tasarlanmış bir yazılım değil, onu kullanarak çalışma yazılımı yazmak için mücadele ederse, en iyi geliştirici fonksiyonel programlama kullanarak daha verimli olup olmadığı önemli değildir . Benzer şekilde, TMTOWTDI programlama dilleri ile, en iyi geliştiriciniz hala temiz, modüler kod yazacak, ancak daha az yetenekli kodlayıcılar dayatılan yapının eksikliği nedeniyle hat gürültüsü yazıyor.

Bu yüzden OOP'nin eksikliklerine rağmen popülerlikte zirveye yükseldiğini düşünüyorum. O kadar kısıtlayıcı değil ki, en yetenekli olanı azarlıyor, ancak yapısı en az yetenekli olanlara iyi tasarım prensiplerini iletmek ve dayatmak için özlü bir yol sunuyor.

Çalışma alanımızda, bir çözümü yalnızca teknik değerlerine dayanarak çok fazla değerlendirme eğilimindeyiz. Başarılı bir çaba, denklemin insan tarafını da hesaba katmalıdır.

Bir bilgisayar derecelendirme sistemi kullanan ve çeşitli dillerde yazmanıza ve her türlü sonuç ve şeyi yayınlamanıza izin veren programlama yarışmaları vardır. Eminim sizin için iyi veriler var. İşte 8 listesi: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Karelerin toplamı veya Fibonacci serisi gibi çok basit ve net problemlerle çözümlerin anlamlı karşılaştırmalarını yapabileceğinizi veya Bresenham'ın çizgi algoritmasını kullanarak düz bir çizgi çizebileceğinizi hayal ediyorum. Gerçek dünyadaki programlama görevlerinin çoğu, net bir kale direklerine sahip değildir ve her dilin tatlı noktaları vardır. Bir dilin faydasının çoğu özneldir. Programcıyı ve müşteri mutluluğunu araştırarak, kod satırlarını veya hata sayısını sayarak daha anlamlı veriler bulabilirsiniz.

İlk Awk programlarımızdan birini yazarak yarım gün geçirdiğimi hatırlıyorum, Java'da "aynı" şeyi yapmamın bir hafta süreceğini düşündüm. Ama bunun nedeni Java çözümümün Awk çözümü hızlı ve kirli olduğu ve giriş ve çıkışta manuel ayarlamalar yapması gerektiğinde sağlam olmaya odaklanmış olacaktı ve işim bittiğinde gerçekten atıldı. Awk ve Java ikisi de harika, aynı şeyler için değil.

Sanırım söylüyorum, gerçek dünya uygulamaları için dilleri veya araçları anlamlı bir şekilde karşılaştırmak son derece zor - eski elma ve portakal sorunu. İyi şanslar! Ne bulduğunu görmek isterim.

30 yılı aşkın bir süredir yazılım geliştirmenin farklı yollarını inceliyorum. Bir paradigma seçerken iyi yayınlanmış kanıtların eksikliği vardır.

Aranabilir büyük bir ASCII bibliyografyası oluşturdum. Bu birçok IEEE ve ACM makalesini ve makalesini içerir. Öğeleri sağlanan kanıt türüyle etiketliyorum. En yaygın etiketler şunlardır:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Şimdi PARADIGM'yi arayın ve etiketleri sayın

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Daha derine inmek istiyorsanız, http://cse.csusb.edu/dick/lab.html ve umarım yardımcı olur ...

Birçok durumda, yazılım mühendisliğindeki bir uygulamanın diğerinden daha iyi olup olmadığına dair genel sonuçların çıkarılmasına izin verecek kadar büyük veya yeterince yüksek bir araştırma grubu yoktur. Özellikle farklı paradigmalarla ilgili araştırmalar arıyordum, ancak kullanılabilirlik eksikliği bu arena ile sınırlı değil, bu yüzden cevabımı daha geniş bir çerçevede çerçeveleyeceğim.

Kitchenham ve ark.'nın 2004 tarihli Kanıta Dayalı Yazılım Mühendisliği makalesi , kanıta dayalı bir yaklaşımdan elde edilecek faydaları ve bunu yazılım mühendisliğinde uygulama problemlerini kapsamaktadır. Buradaki faydaları tartışmayacağım (bu şekilde çalışabilmek istediğim sorudan anlaşılıyor), ancak sorunlar sorduğum soruya bir cevap olarak ilgili.

• Birincisi, eğer ACM üyesi değilseniz, muhtemelen ilk sorunu kapsayan yukarıdaki bağlantıyı hiç okuyamazsınız: mevcut araştırmaların hepsi aslında uygulayıcılar için mevcut değildir.
• ticari olarak gizli süreçlerin bir parçası olarak birçok yazılım mühendisliği uygulaması gizlice devam eder, bu nedenle bu insanlar için neyin işe yarayıp neyin yaramadığına dair bir görünürlük yoktur.
• yazılım mühendisliği yetenekli bir uygulamadır, bu nedenle uygun şekilde kör bir çalışma düzenlemek zordur (imkansız değil, sadece zor).
• yazılım yaşam döngüsünün farklı bölümleri, herhangi bir deneyde kontrol edilmesi zor olan ölçüde birbirlerinin sonuçlarını etkiler.
• buradaki tartışmalardan anlaşıldığı üzere, birçok uygulayıcı "literatürü" (ya da genel olarak yazılım mühendisliğinin akademik yönünü) yaptıkları çalışmalarla ilgili olarak görmemektedir.

Yani aradığım cevap "hayır", aradığım kanıt muhtemelen mevcut değil. Paradigmamı bildiklerimin, havalı ve uzman görüşünün mevcut popüler kriterlerine göre seçmeliyim.

Bu tür bir çalışmanın var olduğuna inanmıyorum. Kullanılan algoritma kadar önemli olan programlama paradigması olmadığına inanılır. Örneğin, küçük uzay algoritmalarına dayanan önemsiz olmayan bir sistem verildiğinde, küçük zaman algoritmalarına dayanan bir ayet farklı metrikler üretecektir. Daha iyi zamana sahip olan, büyük olasılıkla daha geçerli sayılır, alan bir sorun olmadıkça tersi doğrudur. Bir yol döşemeye benzer buluyorum. Malzemelerin yapılması için algoritma veya tarif tüm süreçler boyunca sabit olsa da, bir şirket aynı anda iki şeridin kaldırılmasını (yolun her iki tarafında bir tane) aynı anda iki şeridin döşenmesinden daha iyi olduğunu düşünebilir. . Günün sonunda, siyah tepeyi yapma süreci hala aynı olduğu için önemli değil, tek fark yaklaşımdır. Programlamaya geri dönersek, C geliştiricilerinden oluşan bir ekibiniz varsa, kodu geliştirici bir şekilde yazın, Java geliştiricilerinden oluşan bir ekibiniz OO'ya yazın. Algoritmanın uygulanması kadar paradigmaya asılmayın. Çünkü günün sonunda C gibi Java yazabilir ve Java gibi C yazmayı deneyebilirsiniz.

GÜNCELLEME

Graham beni bıraktığı yorumu cevaplamak için:
Ben mimarlık ile programlama paradigması demek istediğinizi düşünüyorum. Eğer Clojure kullanacaksanız, bir takım Clojure programcıları kiralamanız gerekir. Ancak, hızlı bir aramaya dayalı Clojure, Java tabanlı bir dildir, bu yüzden işlevsel olur. Bu bilgiler göz önüne alındığında, Java programcılarını alacağım (teknik olarak sadece Java yazabilecekleri ve size aynı sonuçları verecektir) veya Haskell geliştiricileri gibi fonksiyonel programcıları arayacağım. Şimdi neyin en iyi olduğunu seçmek tamamen ekibinize bağlıdır. İlişkisel veritabanı uzmanlarından oluşan bir ekibin benim için bir bulut çözümü düzenlemesini ya da işlevsel programcılardan oluşan bir ekibin benim için nesne yönelimli bir çözüm oluşturmasını istemem. Kafanın içinde sahip olduğun yüceltilmiş vizyona sahip olmadığın takımın güçlü yönlerini bir takımın "ne" olması gerektiği için kullanmalısın

Farklı paradigmalar farklı çözümlere yol açar. Hangi uyum 'en iyi' büyük ölçüde aşağıdakilere bağlıdır:

• çözüm
• geliştirme ekibi
• operasyonel ortam

Böyle kesin bir çalışma bilmiyorum ve bir tane olsa bile buna güvenmem.

Mimarın işi budur.

Mimarın bilgeliğinin bir çalışmanın olası alakasız sonuçlarıyla değiştirilmesi, bir felaket reçetesidir.

Not: Bir yorum "algoritmaya" karar verildikten sonra dili seçmekten bahseder. Algoritmalar, prosedürel diller için merkezi yapısal mekanizmadır. Nesneye yönelik diller, sınıflar ve işbirliği / iletişim kalıplarına odaklanır. (Mimar olarak) algoritma merkezli bir çözümün 'en iyi' olduğuna ikna olduysanız, prosedürel veya işlevsel dillere bağlı kalın.

Zeyilname: çalışmalara güvenmemek 'batıl inanç' değildir, sağduyu. Bilimsel deneyler objektif ve tekrarlanabilir olmalıdır. Yazılım projeleri oldukça özneldir, ancak daha da kötüsü, tekrarlanamayan deneylerdir . Y ekibiyle bir X projesini uygulayamaz, sonuçları ölçemez ve sonra zamanı geri alamaz, anıları silemez ve aynı projeyi aynı ekiple yeniden yapamazsınız. Çalışmalar tarafından keşfedilen veya ima edilen bilgiler mimar için yararlı olabilir, ancak asla kesin olamaz.