Lisp iş akışınız nasıl görünüyor? [kapalı]

Şu anda Lisp'i öğreniyorum, Lokomotif BASIC -> Z80 Assembler -> Pascal -> C -> Perl -> C # -> Ruby. Benim yaklaşımım aynı anda:

• SBCL, QuickLisp, closure-html ve drakma kullanarak basit bir web kazıyıcı yazın
• SICP derslerini izleyin

Bence bu iyi çalışıyor; İyi 'Lisp gözlükleri' geliştiriyorum, çünkü Lisp'i oldukça kolay bir şekilde okuyabiliyorum. Ayrıca Lisp ekosisteminin nasıl çalıştığı hakkında bir fikir ediniyorum, örneğin bağımlılıklar için Quicklisp.

Gerçekte kaçırdığım şey, tecrübeli bir Lisper'in gerçekte nasıl çalıştığını hissetmek .

.NET kodlarken, Visual Studio ReSharper ve VisualSVN ile ayarlanmış. Testler yazarım, uygularım, reddederim, taahhüt ederim. Sonra bir hikayeyi tamamlamak için yeterince şey yaptığımda, bazı AUAT'lar yazıyorum. Ardından, yeni işlevselliği test etmek ve umarım onaylamak için müşteriye göndermek için TeamCity'deki bir Sürüm oluşturma işlemini başlatıyorum. Bir yükleyiciye ihtiyaç duyan bir uygulama ise, yükleyiciyi CI sistemi üzerinden inşa etmek için WiX veya InnoSetup kullanın.

Öyleyse sorum şu: deneyimli bir Lisper olarak, iş akışınız nasıl görünüyor? Çoğunlukla REPL'de mi yoksa editörde mi çalışıyorsunuz? Ünite testleri nasıl yapılır? Sürekli entegrasyon? Paketleme ve dağıtım? Masanızda otururken bir tarafa bir fincan kahve ve diğerine John McCarthy'nin çerçeveli bir fotoğrafını bastırırken ne yaparsınız ?

Şu anda Lisp kodlamasıyla başa çıkabildiğimi hissediyorum, ancak Lisp'in gelişimi değil ...

Comp.lang.lisp ve Lisp Forum'daki kişilerin çoğu, Allegro veya LispWorks gibi ticari bir uygulama için ödeme yapmak istemediğinizi varsayarak Emacs ve SLIME kombinasyonlarını önerir. SLIME videosu çalışma işlemini gösterir. Evde kişisel programlar geliştirmek için Emacs ve SLIME kullanıyorum ve bu kombinasyon çok verimli olabilir.

SLIME, Emacs ve REPL arasında entegrasyon sağlar. Genelde yaptığım tüm dosyalarımı yüklemek, sonra üzerinde çalıştığım dosyayı Emacs'ta açmak. Her bir işlevi yazdıktan veya değiştirdikten sonra C-x C-e, REPL'de işlev tanımını yürüten tuşuna basın . Sonra REPL arabelleğine geçip işlevi deneyebilirim. REPL'in geçmişinin tümü standart Emacs anahtar dizileri kullanılarak kullanılabilir ve düzenlenebilir, bu nedenle işlev çağrılarını farklı parametrelerle yeniden yapmak kolaydır.

Öncelikle Clojure ile çalışıyorum ve işte kurulumum:

1. Eclipse IDE (Bunu, bazen Clojure ile aynı projede, birçok Java işi yaptığım için kullanıyorum)
2. Clojure için saat yönünün tersine eklenti (bu bir REPL içerir)
3. Bağımlılık ve yapı yönetimi için Maven
4. Kaynak kod kontrolü için Egit

Kodlama sırasındaki iş akışı genelde şöyledir:

1. Geçerli kaynak dosyaları yükleyerek bir REPL açın.
2. REPL'de kod ve test
3. Bazı kodlardan memnun olduğumda, kaynak dosyaya kopyalayıp yapıştırın
4. Zaman zaman REPL'i yeniden başlatın (ya geri dönüşsüz bir ad alanını karıştırdığımda ya da sadece her şeyin kaynak dosyalarda çalışıp çalışmadığını kontrol etmek için)
5. Ayrıca, her Maven derlemesi tarafından otomatik olarak çalıştırılan kaynak dosyalara testler yazın. Bazen REPL'de yaptığım gayri resmi testler doğrudan birim testlerine dönüşüyor.
6. Bu noktada taahhütte bulunun - hemen hemen düzenli bir gelişim iş akışı

Genel olarak, geliştirme sırasında REPL'in daha etkileşimli kullanımı dışında normal bir Java / C # iş akışından çok farklı değildir.

Diğer cevapları desteklemek için, "Sorun hakkında sert düşün, sonra çözümü yaz" ve "repl ile başla ve programını yinelemeli bir şekle sok" stilinin bir kombinasyonunu yapıyorum. Genellikle ortada. Yaptığım şey, programımın neye benzemesini istediğime dair genel bir fikirle başlamam ve daha sonra yaklaşımımı gözden geçirmek için gittiğimde sorun alanı hakkında yeni bilgiler edinmeye çalışarak yazmaya başladım. Uygulamada bunun anlamı çok fazla deney yapmak ve çok fazla mala kodu yazmak. Farklı yaklaşımlar denerim ve yönü çok hızlı değiştirebilirim. Lisp bu gelişme için iyidir. Bu yüzden TDD'yi o kadar sevmiyorum, ilk önce TDD'yi etkili bir şekilde yapabilmek için ne yapmak istediğimi bilmek zorundayım.

Yapmaya çalıştığım bir diğer önemli şey, programın farklı bölümleri arasındaki protokol hakkında daha fazla düşünmektir. Diğer OO dillerinden farklı olarak, Common Lisp CLOS'ta Genel işlev kavramı üzerinde daha çok durulur, IOW yöntemleri sınıfların dışında yaşar ve gelişimin odağıdır. Bazen sadece istediğim protokolü tanımlayan bir grup GF ile başlıyorum, basit bir uygulama yazıyorum ve gerçek bir uygulama yazmadan önce protokolü çıkarmak için kullanıyorum. Bir sürü blog gönderisini saklayan bir katman yazıyorum, blog gönderilerinin nasıl oluşturulduğunu, düzenlendiğini ve arandığını tanımlayan bir GF kümesine sahip olabilirim ve blog gönderilerini bir listede bellekte saklayan basit bir uygulama yazardım. ve protokolümden memnun kaldıktan sonra, blog gönderilerini bir veritabanına kaydeden veya dosyalara yazan bir uygulama yazıyorum.

Lisp, mevcut çözümünüzün en üst seviyede olduğunu bildiğimde yön değiştirmeyi ve farklı bir yaklaşım yapmayı çok kolaylaştırıyor.

Ayrıca önemli nokta: Ortamınızı sonuna kadar kullanın, kodunuzu daha fazla hata ayıklama bilgisiyle derlemek için farklı derleme ayarları kullanma hakkında bilgi edinin, lisp'in hem derlenip hem de yorumlanabileceğinden yararlanın. MOP gibi lisps introspective tesislerini kullanın, dokümantasyona bakmak için inceltici özellikleri kullanın, nesnelerin içine bakmak için denetçiyi kullanın, düzenli olarak hyperspec'e bakın, sisteminize işletim sistemi gibi davranın, kodunuz için statik bir derleyiciden çok daha fazlası Bundan daha güçlü.

Yeni başlayanlar için lisp, python ve ruby'den çok fazla kazanmak değildir, ancak onunla daha fazla deneyim kazandıkça, daha az ortamlarda muazzam kazanç elde edersiniz.

En önemlisi, bu dili eğlendirmek ve sevmek zorundasınız, bazen cesaretini kırmak ve şu anda popüler olan blub dillerini kullanmak çok kolaydır. Lisp'e sadık kalırsan, geri ödeyecek.

Bir REPL ile bağlantısı olan bir editörde çalışma eğilimindeyim (genellikle emacs'lerde düzenleme ve SLIME’yi Ortak Lisp ortamına köprü olarak kullanma). Hem “altta” hem de “üstte” başlama eğilimindeyim, ortaya doğru çalışıp, tasarımım ilerledikçe revize ediyorum.

Test gelince, neden bir REPL var. Gittikçe kodu test etmeye yardımcı olduğunu buluyorum. Bazen gittiğim gibi daha resmi testler veya ölçütler yazacağım (genellikle optimizasyon aşamasındayım). Bir fonksiyonelliğin daha yavaş, iyi bilinen bir uygulamasına sahip olun, optimize edilmiş bir sürüm için kod (deneme editör penceresinde) deneyin, bunu yalancı lisp koduna gönderin ve hem daha hızlı olup olmadığını kontrol edin hem de sonuçları daha yavaş döndürün kodu.

Paketlemeye kadar, ASDF tarafından kurulabilen projeleri paketlememe, indirme havuzuna koymama ve versiyonlama işlemine başlamama yardımcı olacak bazı kodlarım var.