Okuryazar programlama neden ana akım değildir? [kapalı]

Okuryazar programlamanın iyi idealleri vardır. Neden bunun ana akım olmadığını düşünüyorsunuz? Çünkü teslim edilemedi mi?

İlk önce Knuth'un yazıları kitabında gördüm ve düzgün göründüğünü düşündüm. Sonra programda neler olup bittiğini anlamak için edebiyat programlama ekranını kullanmaya çalıştım ve göründüğünden daha zor buldum. Program listelerinden geçmeye çok alıştığım için olabilirdi, ama kafa karıştırıcı görünüyordu.

Sonra kaynak koduna baktım, ve o zaman beni oradan kapattı. Program metni tamamen yeni bir şekilde yazılmalı, program metni ile derleyicinin gördükleri arasında daha az yazışmalar görüldü ve bunun için hiçbir fayda görmedim.

Ayrıca, insanlar aslında Y yaparken kodun X yaptığı konusunda uzun ve inandırıcı argümanlar yazabilirler ve yanıltıcı yorumlardaki payıma katılıyorum. Oldukça erken ne yaptığını görmek için kodu okumak için bir düşkünlük geliştirdim. Okuryazar programlama bunun antitezidir.

Ben suçlamaz ağ etkisi . Diğer kişilerin kodunuzu ve belgelerinizi düzenlemesi için onu anlayabilmeleri gerekir.

Bu, insanları cweb / noweb gibi bir şeyden uzaklaştırıyor, çünkü onları kullanmak, TeX'i ve proje için kullandığınız programlama dilinin üstündeki programa özel sözdizimini öğrenmenizi gerektiriyor. Bu, özellikle de ilk başta TeX için bu kadar büyük bir çizim olan matematik dizilimine ihtiyaç duymamaları halinde çok büyük bir zaman kaybı olarak görülebilir. (Ve pek çok uygulama programcısı için buna gerçekten ihtiyaç duymazlar.) Bunun yerine Visual Studio'nun XML yorumları gibi bir şey tercih ediyorlar, çünkü bu zaten popüler ve iyi kurulmuş.

Okuryazar programlamanın başladığını gördüğüm yerler, programcıların çoğunun matematik, CS ya da istatistik konularında önemli bir eğitime (doktora) sahip oldukları ve bu nedenle LaTeX ile ilgili aileleri olduğu yerde, bilimsel / istatistiksel hesaplama alanındadır. Yazdıkları belgelerin TeX'te en iyi yazılmış birçok karmaşık formülü içermesi daha muhtemeldir ve bunların R'de programlanması daha muhtemeldir. SWeave'ı bilen R programcılarının oranı kesinlikle çok daha yüksektir. cweb'i bilen C programcılarının oranı.

Okurken 90'lı yılların sonunda Edebiyat Programcılığı kavramı beni çok etkiledi ve Knuth'un programlama yaklaşımına ve dizgi çalışmalarına hala merak duyuyorum. Hiçbir şey ama en iyisi yapacak.

Knuth'un tasarladığı Literatür Programlama sistemi hemen göze çarpmadan çok daha fazlasını yaptı, yani temel programlama dilinde Knuths kaynak belgesinde üretilen kod oluşturma aracının standart Pascal adlı birçok eksikliğinin üstesinden geldi.

Standard Pascal’ı denememiş yeterince şanslı olanlar için, işte dikkat çeken bazı noktalar.

• Tek geçişli bir derleyiciye sahip olmayı kolaylaştırmak için, dil belirtimi tüm bildirimlerin belirli bir sırada gelmesi gerektiğini söyledi. Wikipedia sayfasından: "Her prosedür veya fonksiyon, hepsinin bu sırada olması gereken kendi etiket etiketleri, sabitler, türler, değişkenler ve diğer prosedürler ve fonksiyonlara ilişkin beyannamelere sahip olabilir." Bu yapabildin demek değil kaynak dosyada mantıksal birlikte grup eşyalarını.
• Dize kullanımı düz C'den daha sıkıcıydı.
• Tanımlayıcılar isteğe bağlı uzunlukta olamaz.
• Artık hatırlayamadığım birçok şey var.

Tüm bunlar temel olarak Knuth'un daha iyi bir programlama diline ihtiyacı olduğu anlamına geliyordu (bu yüzden bir tane icat etti) ve Pascal'ı anadil dili olarak kullandı.

Çoğu modern dil bu işleri çok çaba sarf etmeden yapabilir, bu nedenle Edebiyat Programcılığının çözeceği büyük bir bölümü çıkarmaktır.

Ayrıca modern diller, kodun kendisine konulacak daha fazla düşünceye izin verecek şekilde daha etkileyicidir.

Peki geriye ne kaldı? Kaynak kodundan bir TİP dokümantasyon formu üretebilme ve bu TAT bugün mevcut.

Sadece JavaDoc'u düşünün - Java çalışma zamanı API'si, belki de bugün mevcut olan en büyük Literatür Programlaması parçasıdır (kod aslında sunulmadığı dışında, ancak Java başlangıçtan beri açıktıysa OLABİLİRDİR). Örneğin http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Benzer sistemler. NET ve diğer genel programlar için var olduğuna inanıyorum.

90'lı yıllarda okuryazar programlamaya bayılırken keşfettiğim bir şey, Tam Olarak Doğru Olanı yapmak isteyen ve kendi okuryazar programlama sistemlerini yazmayı içeren çok tutkulu insanları cezbetmesiydi, çünkü hiçbiri kendileri için yeterince iyi değildi. noweb herkes için yeterince iyi bir en az ortak payda sağlayarak bunu kesmek için iyi bir girişimdi, ancak o zaman bile LP zamanımın çoğunu güzel bir yazıcı geliştirmek için harcadım ...

Başka bir konu, bunun gerçekten anti-çevik olmasıdır. Bazı açılardan, yavaşlamak iyi bir şey çünkü sizi daha ön düşünmeye ve ilk kez doğru şeyler yapmaya zorluyor. Diğer taraftan, ilerledikçe titizlikle belgelemek, kodunuzu yeniden düzenlemenin önünde büyük bir engel olduğu anlamına gelir. LP kodunu eklemeden önce kodunuzun sertleşmesini beklerseniz, sizi izlerinizde durdurabilecek çok günlük bir dokümantasyon görevi görürsünüz.

Alçakgönüllü görüşüme göre, birçok şirketin Okuryazar Programlamanın amaçlarına zıt bir kültüre sahip: daha hızlı sonuçlar istiyorlar (yalnızca uygulama üretimde iken kalite hakkında ağlıyorlar). Kendi tecrübelerime göre, patronlarım daha hızlı sonuçların "istediğim günden sonra çalıştırılabilir bir program" anlamına gelmediğini anlamayı reddetti. Onlar için, eğer bir geliştirici klavyesini yazmakla meşgul değilse, çalışmıyor demektir, "tasarım anlamında zamanını boşa harcıyor". Evet, biliyorum patronum bir göt deliği.

Kodlayıcılar İngilizce değil kod yazarlar.

Kodlayıcılar dokümantasyon yazmayı sevmez, çünkü kodun çalıştırılmasına yardımcı olmaz.

Kodlayıcılar dokümantasyon yazma konusunda iyi değil çünkü fikirlerini ifade etmek için zayıf bir ortam.

Okuryazar programlama, dokümantasyonun kodun daha sonradan düşündüğü bir sonraki seviyeye götürülmesi fikri gibi görünüyor. Belki işe yarayabilir, ama çoğu kodlayıcı iğrenç dokümantasyona benziyor.

Prensip olarak, insanlar çok salaktır. Genç insanlar tarafından bu basit tekniğin doğası hakkında ifade edilen sonsuz bir tahmin ve yanlış anlama akışı olan açık bir tanıklık.

İnsanlar LP'yi şu şekilde alır: (a) bir dokümantasyon yöntemi (b) bazı özel beceriler veya yetenekler gerektiren bazı cilalanmış yazılar yazma yöntemi (c) kendi fikirleriyle Leo programlama editörünün yaratıcısı olarak hiçbir ipucu yok. vb. vb.

Bununla birlikte, LP basit bir şekilde: (1) programların bir (= herhangi bir) insan dilinde bir kod ve öbekler karışımı halinde yazılması, ikincisi diğer kod öbekleri ve / veya içerilen öbeklerin kısaltmasıdır. Bu, sayısız programlama ders kitabının yazarlarının yaptığı tam olarak budur. (2) İnsandaki cümleleri genişleten basit bir önişlemcidir. yorumlayıcı). Aksi halde, "okuryazar kaynak" ı güzel, iyi biçimlendirilmiş okunabilir bir metne dönüştürmek için biçimlendirme sembollerini içermek üzere, yazılı metni başka bir küçük yardımcı programla genişletebilirsiniz.

Gençler bu son derece basit bir fikri asla denemezler - ve asla denememeleri veya yapmamaları gibi sahte sebepleri hayal ederler veya hayal ederler.

Temel olarak, bir insan dilinde yazılmış "sahte kodda" programlama ve ardından basit bir önişlemci yardımcı programı ile genişletme ana fikri, program akışınızın kod katlanması veya bölünmesi gibi İşlevlere / alt programlara girerek, ayrıntılarda kendinizi kaybetmemeniz için gerekli, ancak makinenin çalışması için tamamen gereksizdir.

Bunu okur programlama 2 yönü vardır do dilek ana programlama dahil edildi - gömülü görüntüleri (örn tasarım diyagramları) Önceki ve alternatif girişimleri (ve işaretçiler örneğin "ben bu başka bir yol denedi çünkü bu gibi nedenidir ve işe yaramadı çünkü ... "). Bu özelliklerin her ikisi de doktor yorumları ve URI'lerle ele alınabilir.

Çünkü programların mantığı konuştuğumuz gibi çalışmıyor. Bir program iyi tanımlanmış bir akışa, koşullara ve döngülere sahiptir.

Çok kodladıktan sonra bu terimlerle DÜŞÜNÜYORUM. Beynim sorunları çalıştırılabilir kodun hedef alanına dönüştürüyor. Üstelik, programları okuryazar yapmak için fazladan bir dönüşüm adımı yapmak zorunda kalmak yerine, bunu genellikle programlama dilinde yazmam çok daha etkili.

Aslında, programlarımın zaten okuryazar olduğuna inanıyorum ... konuşan tanımlayıcılar, iyi işlev adları, birkaç ay sonra hemen kendimi anlayamayacağım bazı korsanlıklar yaptığım yorumlar.

Sonuç olarak: Java kodum, her "okuryazar" programlamanın istediği gibi kendi başına okuryazardır.

Diğer yollarla programlamaya başladım - derleyicinin istediği gibi değil, aklıma uygun bir şekilde düzenlenmiş bir kodun olmasını hayal ettim. Leo'yu bu amaç için neredeyse ideal buldum . Ayrıca, dışarıda değiştirilen dosyaların kaydını tutmayı da destekler. Bu dosyalar herhangi bir özel işaretlemeye sahip olmak zorunda değildir, bu yüzden takımdaki diğer kişilerin bilmesine gerek kalmadan Leo'yu kendim için kullanabilirim. Bu özellik - "@shadow ağaçları" - hala ümit verici olmasına rağmen, daha fazla göz küresine ihtiyaç duyuyor, çok umut verici. Ve ayrıca "ah hayır, büyük bir dosyadaki her şey" sorununu da hem ağacı çerçevesine düzenleyerek hem de harici dosyaları destekleyerek düzeltir.

Benim için, adının aksine, "okuryazar programlama" hiç belgelerle ilgili değil. Daha önce olduğundan daha fazla dokümantasyon yok. Bu, kaybolmama yardımcı olan bir yapıya sahip olmakla ilgilidir . Özellikle JSP dosyalarının yönetimini yönetirken yemin ederim (ve Leo'nun orijinal olarak Python'a yönelik olmasına rağmen ve JSP dilini desteklemiyor olmasına rağmen - dosyayı el ile Leo ağacına bölmeliyim!).

Kod üzerine bir tez yazılabilecek değerli bir öğretim aracı olarak görüyorum ve daha sonra çalışma kodlarının parçaları okurlara kodun nasıl, neyin ve niçin olduğunu öğretmek için araya giriyor.

Tamamen eğitici bir ortam dışında, sadece Knuth'un en iyi nasıl kullanılacağını gerçekten anladığını düşünüyorum.

Tüm dünyaların en kötüsü - çok spesifik olmayan bir dilde oldukça doğru, oldukça spesifik bir bilgisayar programı yazmalısınız: ingilizce. Bu yüzden tam olarak doğru cümleleri kullanarak dikkatlice yazmak zorundasınız - bu yüzden de sadece kod yazmak olabilir.