Haskell'de büyük ölçekli tasarım? [kapalı]

Özellikle Haskell'de büyük fonksiyonel programlar tasarlamak / yapılandırmak için iyi bir yol nedir?

Ben bir sürü öğreticilerden geçtim (Kendimi benim favorim olan bir Şema Yazın, Gerçek Dünya Haskell ile bir saniye) - ama programların çoğu nispeten küçük ve tek amaçlı. Ayrıca, bunların bazılarının özellikle zarif olduğunu düşünmüyorum (örneğin, WYAS'taki geniş arama tabloları).

Şimdi daha hareketli programlar içeren daha büyük programlar yazmak istiyorum - çeşitli farklı kaynaklardan veri almak, temizlemek, çeşitli şekillerde işlemek, kullanıcı arayüzlerinde görüntülemek, ısrar etmek, ağlar üzerinden iletişim kurmak vb. okunabilir, bakımı yapılabilir ve değişen gereksinimlere uyarlanabilir olması için en iyi yapılardan biri hangisidir?

Büyük nesne yönelimli zorunlu programlar için bu soruları ele alan oldukça büyük bir literatür vardır. MVC, tasarım modelleri vb. Gibi fikirler, endişelerin ayrılması ve OO tarzında tekrar kullanılabilirlik gibi geniş hedeflerin gerçekleştirilmesi için iyi reçetelerdir. Buna ek olarak, daha yeni zorunlu diller, acemi görüşüme göre Haskell'in daha az uygun göründüğü bir 'büyüdükçe tasarım' yeniden düzenleme tarzına katkıda bulunuyor.

Haskell için eşdeğer bir literatür var mı? Egzotik kontrol yapılarının hayvanat bahçesi, bu amaçla en iyi şekilde kullanılan fonksiyonel programlamada (monadlar, oklar, uygulanabilir vb.) Nasıl kullanılır? En iyi hangi uygulamaları önerebilirsiniz?

Teşekkürler!

EDIT (bu Don Stewart'ın cevabının bir devamıdır):

@dons bahsetti: "Monadlar türlerdeki önemli mimari tasarımları yakalarlar."

Sanırım sorum şu: bir kişi saf mimari dilde temel mimari tasarımlar hakkında nasıl düşünmeli?

Birkaç veri akışı ve birkaç işlem adımı örneğini düşünün. Veri akışları için bir dizi veri yapısına modüler ayrıştırıcılar yazabilirim ve her bir işlem adımını saf bir işlev olarak uygulayabilirim. Bir veri parçası için gereken işlem adımları, değerine ve diğerlerinin değerine bağlı olacaktır. Bazı adımları GUI güncellemeleri veya veritabanı sorguları gibi yan etkiler izlemelidir.

Verileri ve ayrıştırma adımlarını iyi bir şekilde bağlamanın 'Doğru' yolu nedir? Çeşitli veri tipleri için doğru olanı yapan büyük bir fonksiyon yazılabilir. Veya şimdiye kadar işlenmiş olan şeyleri takip etmek ve her işlem adımının monad durumundan sonra ihtiyaç duyduğu her şeyi almasını sağlamak için bir monad kullanabilirsiniz. Ya da biri büyük ölçüde ayrı programlar yazıp mesaj gönderebilirdi (bu seçeneği pek sevmiyorum).

Bağladığı slaytlarda İhtiyacımız Olan Şeyler madde işareti bulunur: "Tasarımın türlere / işlevlere / sınıflara / monad'lara eşlenmesi için deyimler". Deyimler nelerdir? :)

Ben bu konuda biraz konuşmak Haskell Mühendislik Büyük Projeler ve Tasarım ve xmonad Uygulanması. Genel olarak mühendislik, karmaşıklığı yönetmekle ilgilidir. Haskell'de karmaşıklığı yönetmek için birincil kod yapılandırma mekanizmaları:

Tip sistemi

• Etkileşimleri basitleştirerek soyutlamaları uygulamak için yazı sistemini kullanın.
• Anahtar değişmezleri türlerle zorla
  • (örneğin, belirli değerler bir kapsamdan kaçamaz)
  • Belirli kodun GÇ yok, diske dokunmuyor
• Güvenliği zorunlu kılın: işaretli istisnalar (Belki / İkisi), kavramları karıştırmaktan kaçının (Word, Int, Adres)
• İyi veri yapıları (fermuarlar gibi), örneğin sınır dışı hataları statik olarak dışladığı için bazı test sınıflarını gereksiz hale getirebilir.

Profiler

• Programınızın yığın ve zaman profilleri hakkında nesnel kanıt sunun.
• Özellikle yığın profili, gereksiz bellek kullanımını sağlamak için en iyi yoldur.

Saflık

• Durumu kaldırarak karmaşıklığı önemli ölçüde azaltın. Tamamen işlevsel kod ölçeklendirir, çünkü bileşimseldir. İhtiyacınız olan tek şey, bazı kodların nasıl kullanılacağını belirlemek için kullanılan türdür - programın başka bir bölümünü değiştirdiğinizde gizemli bir şekilde kırılmaz.
• Çok sayıda "model / görünüm / denetleyici" tarzı programlama kullanın: harici verileri mümkün olduğunca çabuk tamamen işlevsel veri yapılarına ayrıştırın, bu yapılarda çalışın, sonra tüm işler yapıldıktan sonra render / flush / serialize edin. Kodunuzun çoğunu saf tutar

Test yapmak

• QuickCheck + Haskell Kod Kapsamı, türlerle kontrol edemediğiniz şeyleri test ettiğinizden emin olmak için.
• GHC + RTS, GC yapmak için çok fazla zaman geçirip geçirmediğinizi görmek için mükemmeldir.
• QuickCheck ayrıca modülleriniz için temiz, dikey API'ler belirlemenize yardımcı olabilir. Kodunuzun özelliklerini belirtmek zorsa, muhtemelen çok karmaşıktır. Kodunuzu test edebilecek, iyi oluşturulmuş temiz bir dizi özelliğe sahip olana kadar yeniden düzenlemeye devam edin. Sonra kod muhtemelen iyi tasarlanmış.

Yapılandırma Monadları

• Monadlar, türlerdeki önemli mimari tasarımları yakalar (bu kod donanıma erişir, bu kod tek kullanıcılı bir oturum vb.)
• Örneğin, xmonad'daki X monad, sistemin hangi bileşenleri tarafından hangi durumun görülebileceğinin tasarımını tam olarak yakalar.

Tür sınıfları ve varoluş türleri

• Soyutlama sağlamak için tip sınıflarını kullanın: polimorfik arayüzlerin arkasındaki uygulamaları gizleyin.

Eşzamanlılık ve paralellik

• Gizlice parkolay, composable paralelizm'le rekabeti yenmek için programa.

Elden Geçirme

• Haskell'de çok refactor olabilirsiniz . Türleri akıllıca kullanıyorsanız, büyük ölçekli değişikliklerinizin güvenli olmasını sağlar. Bu, kod tabanı ölçeğinize yardımcı olacaktır. Yeniden düzenleme işlemlerinizin tamamlanana kadar tür hatalarına neden olduğundan emin olun.

FFI'yı akıllıca kullanın

• FFI, yabancı kodla oynamayı kolaylaştırır, ancak bu yabancı kod tehlikeli olabilir.
• Döndürülen verilerin şekliyle ilgili varsayımlarda çok dikkatli olun.

Meta programlama

• Şablon Haskell veya jenerikler bir miktar kazan plakasını kaldırabilir.

Paketleme ve dağıtım

• Cabal kullan. Kendi inşa sisteminizi yuvarlamayın. (DÜZENLEME: Aslında Stack'i şimdi başlamak için kullanmak istersiniz .).
• İyi API dokümanları için Haddock kullanın
• Graphmod gibi araçlar modül yapılarınızı gösterebilir.
• Mümkünse kitaplıkların ve araçların Haskell Platform sürümlerine güvenin. Kararlı bir bazdır. (Düzeltme: Yine, bu gün büyük olasılıkla kullanmak istediğiniz Yığını kadar istikrarlı bir taban hazırlamak ve çalıştırmak için.)

Uyarılar

• -WallKodunuzu kokulardan temiz tutmak için kullanın . Daha fazla güvence için Agda, Isabelle veya Catch'a da bakabilirsiniz. Tüy bırakmayan kontrol için, iyileştirmeler önerecek harika ipucuna bakın .

Tüm bu araçlarla, bileşenler arasındaki mümkün olduğunca çok etkileşimi kaldırarak karmaşıklığı kaldırabilirsiniz. İdeal olarak, bileşimi olduğu için bakımı çok kolay olan çok geniş bir saf kod tabanına sahipsiniz. Bu her zaman mümkün değildir, ama amaçlamaya değer.

Genel olarak: ayrıştırmak sonra, mümkün olan en küçük referentially şeffaf bileşenler halinde sistem mantıksal birimler modüllerde bunları uygulamak. Bileşen grupları (veya iç bileşenler) için küresel veya yerel ortamlar monad'lara eşlenebilir. Temel veri yapılarını tanımlamak için cebirsel veri türlerini kullanın. Bu tanımları geniş çapta paylaşın.

Don size yukarıdaki detayların çoğunu verdi, ama işte benim iki sent Haskell'deki sistem armağanları gibi gerçekten cesur durumdaki durumlu programlar yapmaktan.

1. Sonunda, bir monad transformatör yığınında yaşıyorsun. Altta IO var. Bunun üstünde, her büyük modül (soyut anlamda, dosya içinde modül anlamında değil) gerekli durumunu bu yığındaki bir katmanla eşler. Bu nedenle, veritabanı bağlantı kodunuzu bir modülde gizlediyseniz, hepsini MonadReader Connection m => ... -> m ... türünde olacak şekilde yazarsınız ve sonra veritabanı işlevleriniz her zaman bağlantılarını diğer işlevler olmadan alabilir varlığının farkında olmak zorunda olan modüller. Veritabanı bağlantınızı taşıyan bir katman, diğeri yapılandırmanız, üçüncüsü paralellik ve senkronizasyonun çözünürlüğü için çeşitli semaforlarınız ve mvarlarınız, başka bir günlük dosyanızın işlemesi vb.

2. Önce hata işlemenizi anlayın . Şu anda daha büyük sistemlerde Haskell için en büyük zayıflık, Maybe gibi berbat olanlar da dahil olmak üzere çok sayıda hata işleme yöntemidir (bu yanlıştır, çünkü neyin yanlış gittiğine dair herhangi bir bilgiyi geri veremezsiniz; yalnızca eksik değerler anlamına gelir). Önce bunu nasıl yapacağınızı anlayın ve kitaplıklarınızın ve diğer kodların sonuncunuza kullandığı çeşitli hata işleme mekanizmalarından bağdaştırıcılar kurun. Bu sizi daha sonra keder dünyasından kurtaracak.

Zeyilname (yorumlardan alınmıştır; Lii & liminalisht sayesinde ) -
büyük bir programı yığın halinde monadlara dilimlemenin farklı yolları hakkında daha fazla tartışma:

Ben Kolera , bu konuya büyük bir pratik giriş sunuyor ve Brian Hurtlift , özel monadınıza monadik eylemler yapma sorununa çözümler anlatıyor. George Wilson , mtlözel monad türünüz yerine, gerekli tip sınıfları uygulayan herhangi bir monad ile çalışan kodu yazmak için nasıl kullanılacağını gösterir . Carlo Hamalainen , George'un konuşmasını özetleyen bazı kısa, faydalı notlar yazdı.

Haskell'de büyük programlar tasarlamak, diğer dillerde yapmaktan farklı değildir. Büyük çapta programlama, probleminizi yönetilebilir parçalara ayırmak ve bunları nasıl birleştireceğinizle ilgilidir; uygulama dili daha az önemlidir.

Bununla birlikte, büyük bir tasarımda, parçalarınızı sadece doğru bir şekilde bir araya getirebildiğinizden emin olmak için tip sistemini denemek ve kullanmak güzel. Bu, aynı türe sahip gibi görünen şeyleri farklı kılmak için newtype veya fantom tiplerini içerebilir.

Siz ilerledikçe kodu yeniden düzenleme söz konusu olduğunda, saflık büyük bir nimettir, bu yüzden kodun mümkün olduğunca saf tutmaya çalışın. Saf kodun yeniden düzenlenmesi kolaydır, çünkü programınızın diğer bölümleriyle gizli bir etkileşimi yoktur.

Bu kitapla ilk kez yapısal fonksiyonel programlamayı öğrendim . Tam olarak aradığınız şey olmayabilir, ancak fonksiyonel programlamaya yeni başlayanlar için, bu, ölçekden bağımsız olarak fonksiyonel programları yapılandırmayı öğrenmek için en iyi ilk adımlardan biri olabilir. Tüm soyutlama seviyelerinde, tasarım her zaman açıkça düzenlenmiş yapılara sahip olmalıdır.

Fonksiyonel Programlama Teknesi

http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/

Şu anda "İşlevsel Tasarım ve Mimarlık" başlıklı bir kitap yazıyorum. Saf fonksiyonel yaklaşım kullanarak büyük bir uygulamanın nasıl oluşturulacağı konusunda eksiksiz bir teknik seti sunar. Uzay gemilerini sıfırdan kontrol etmek için SCADA benzeri bir uygulama "Andromeda" oluştururken birçok fonksiyonel desen ve fikri açıklar. Ana dilim Haskell. Kitap şunları kapsar:

• Diyagramlar kullanarak mimari modellemeye yaklaşımlar;
• Gereksinimlerin analizi;
• Gömülü DSL alan modellemesi;
• Harici DSL tasarımı ve uygulaması;
• Etkileri olan alt sistemler olarak Monadlar;
• Fonksiyonel arayüzler olarak serbest monadlar;
• Okunan eDSL'ler;
• Serbest monadik eDSL'ler kullanarak Kontrolün Ters Çevrilmesi;
• Yazılım İşlem Belleği;
• Lensler;
• Devlet, Okuyucu, Yazar, RWS, ST monadları;
• Saf olmayan durum: IORef, MVar, STM;
• Çok iş parçacıklı ve eşzamanlı alan modellemesi;
• GUI;
• UML, SOLID, GRASP gibi genel teknik ve yaklaşımların uygulanabilirliği;
• Saf olmayan alt sistemlerle etkileşim.

Burada kitabın koduna ve 'Andromeda' proje koduna aşina olabilirsiniz .

Ben Bu gerçekleşene kadar öğemi "Fonksiyonel Programlama Tasarım ve Mimarlık" (Rus) okuyabilir 2017 yılı sonunda bu kitabı bitirmek için bekliyoruz burada .

GÜNCELLEME

Kitabımı çevrimiçi olarak paylaştım (ilk 5 bölüm). Reddit'teki yazıyı görün

Gabriel'in blog yazısı Ölçeklenebilir program mimarileri kayda değer olabilir.

Haskell tasarım desenleri ana tasarım desenlerinden önemli bir şekilde farklıdır:

• Geleneksel mimari : B tipi bir "ağ" veya "topoloji" oluşturmak için A tipindeki birkaç bileşeni bir araya getirin

• Haskell mimarisi : Aynı tip A'nın yeni bir bileşenini oluşturmak için, ikame parçalarından karakter olarak ayırt edilemeyen çeşitli bileşenleri A tipi ile birleştirin

Görünüşe göre zarif bir mimarinin, bu hoş homojenlik hissini sergileyen kütüphanelerden düşme eğilimi gösterdiği sık sık bana vuruyor. Haskell'de bu özellikle belirgindir - geleneksel olarak "yukarıdan aşağıya mimari" olarak kabul edilecek kalıplar mvc , Netwire ve Cloud Haskell gibi kütüphanelerde yakalanma eğilimindedir . Yani, umarım bu cevap bu konudaki diğerlerinin yerine geçme girişimi olarak yorumlanmayacaktır, sadece yapısal seçimler kütüphanelerde alan uzmanları tarafından ideal olarak kaldırılabilir ve kaldırılmalıdır. Bence, büyük sistemler inşa etmedeki asıl zorluk, bu kütüphaneleri tüm pragmatik endişeleriniz karşısında mimari "iyiliği" üzerinde değerlendirmektir.

As liminalisht yorumlardaki bahisler kategori tasarım deseni Benzer şekilde içinde konu üzerine Gabriel tarafından başka bir yazı vardır.

Ben kağıt bulduk " Haskell Kullanarak Öğretim Yazılım Mimarisi (pdf)" Haskell büyük ölçekli yapısı hakkında düşünme için yararlı Alejandro Serrano tarafından.

Belki de bir adım geri gitmeli ve sorunun tanımını ilk etapta bir tasarıma nasıl çevireceğinizi düşünmelisiniz. Haskell çok yüksek düzeyde olduğu için, sorunun tanımını veri yapıları, prosedürler olarak eylemler ve işlevler olarak saf dönüşüm şeklinde yakalayabilir. O zaman bir tasarımınız var. Bu kodu derlediğinizde ve kodunuzda eksik alanlar, eksik örnekler ve eksik monadik transformatörler hakkında somut hatalar bulduğunuzda geliştirme başlar, çünkü örneğin bir G / Ç prosedürü içinde belirli bir durum monadına ihtiyaç duyan bir kütüphaneden veritabanı erişimi gerçekleştirirsiniz. Ve işte, program var. Derleyici zihinsel eskizlerinizi besler ve tasarıma ve geliştirmeye uyum sağlar.

Bu şekilde, Haskell'in yardımından en başından beri faydalanırsınız ve kodlama doğaldır. Aklınızdaki somut sıradan bir sorunsa, "işlevsel" veya "saf" veya yeterli genel bir şey yapmak umurumda olmaz. Bence aşırı mühendisliğin BT'deki en tehlikeli şey olduğunu düşünüyorum. Sorun, bir dizi ilgili sorunu özetleyen bir kütüphane oluşturmak olduğunda işler farklıdır.