Okuryazar programlama, iyi / kötü tasarım metodolojisi


10

Son zamanlarda okuryazar programlama kavramını buldum . Ve oldukça ilgi çekici buldum. Yine de bir program yapılandırmanın kötü bir yol olduğu iddialarıyla karşılaşmadım. Pek çok yeri kapsamıyor gibi görünüyor. Burada bile bununla ilgili herhangi bir soru bulamadım.

Benim sorum kusurları ya da belgeleri ele alma yolları ile ilgili değil . Belgeleri, okuryazar programlama akışı için ne anlama geldiğinin bir yan etkisi olarak görüyorum. Tasarımın başlangıçta kolay programlama ve ileri programlama akışı kavramına yönelik olduğunu biliyorum .

Sorunu küçük cümle temelli problemlere bölme kavramı gerçekten parlak bir fikir gibi görünüyor. Böylece programın akışının anlaşılmasını kolaylaştıracaktır.

Okuryazar tasarım yönteminin bir sonucu da, gerekli fonksiyon sayısının programcının hayal gücü ile sınırlı olacağıdır. Belirli bir görev için bir işlev tanımlamak yerine scrap, okuryazar yönteminde bir olarak oluşturulabilir . Bu, ayrı bir fonksiyon derlemesi yerine kodun otomatik olarak yerleştirilmesini ve müteakip eşdeğer hızı elde etmek için prosedürler arası bir derleme optimizasyon adımının gerekliliğini sağlayacaktır. Aslında Donald E. Knuth ilk girişimi , bu gerçeği nedeniyle daha düşük bir yürütme süresi gösterdi. Derleyicilerin birçoğuna yapılabileceğini biliyorum, ancak bu benim endişem değil.

Bu yüzden, bunun neden kötü / iyi bir tasarım metodolojisi olduğunu düşünmesi gerektiğine dair geri bildirim almak istiyorum?


2
Zeroth, okuryazar programlama etiketini oluşturdum ve Wikipedia makalesine dayanan bir özet ekledim. Lütfen wiki etiketinin ilgili bilgilerle genişletilmesine yardımcı olun.
yannis

@YannisRizos Buraya ekleyeceğim, düzenleme ayrıcalıklarım yok.
sıfır

1
Peki, ben de :) Bazı kaynaklar ekledim (wikipedia makalesi ve sorunuzdaki bağlantılar), düzenleme hakem incelendiğinde ve kabul edildiğinde görünecektir (?!). Bu ilgi çekici bir yaklaşım ve zaten araştırdığınız için, geri dönüp orada bahsetmeye değer olduğunu düşündüğünüz bir şey bulduğunuzda etiket wiki'yi geliştirin.
yannis

1
Okuryazar Programlama sitesinin yazarına UX stackexchange sitesini ziyaret etmesini öneririm - renkler okumak için gerçekten kötü.
Danny Varod

1
FYI, literate-programmingStackOverflow üzerinde de bir etiket var. Hala çok fazla olmasa da, daha fazla içerik var.
Ross Patterson

Yanıtlar:


9

Bu, ayrı bir fonksiyon derlemesi yerine kodun otomatik olarak yerleştirilmesini ve müteakip eşdeğer hızı elde etmek için prosedürler arası bir derleme optimizasyon adımının gerekliliğini sağlayacaktır.

Bu alakasız. Onlarca yıldır var. Sorgudan kaldırabilirsiniz, çünkü modern derleyicilerle optimize edicilerini bozmak mantıklı değildir.

Bu yüzden, bunun neden kötü / iyi bir tasarım metodolojisi olduğunu düşünmesi gerektiğine dair geri bildirim almak istiyorum?

Okuryazar programlamanın dezavantajı yoktur. (Bu duygu için düzinelerce -1 oy bekliyorum.) Bir uygulayıcı olarak, hiç problem görmedim.

"Yüksek düzeyli bir dilde programlama" elde edilen kod değiştirilerek alt üst edilir. " Sağ. Aynı şekilde, C ++ 'da programlama .oüretilen dosyayı değiştirerek bozulur . Bu doğru, ama alakasız.

Okuryazar programlar yazmak yalnızca derleyici dostu dosyalar ve insan dostu dosyalar üreten uygun bir araç seti ile yazılan, üst düzey ve ayrıntılı (kod düzeyi) tasarımın tek bir belgede birleştirilmesi anlamına gelir.

Knuth okuryazar programlama icat ettiğinde, ana akım OO dilleri yoktu. Bu nedenle, orijinal web ve örgü araçlarının büyük bir kısmı, soyut veri türleri için sınıf benzeri tanımlar yaratmasına izin verdi.

Bunların çoğu günümüzde önemsiz. Okuryazar Programlama araçları, modern, üst düzey nesne yönelimli (veya işlevsel) programlama dillerine odaklanmışsa oldukça basit olabilir. C (veya Pascal veya Assembler) sınırlamaları nedeniyle ayrıntılı çözümlere daha az ihtiyaç vardır.

Okuryazar programlar yazma yaklaşımı okuma yazma bilmeyen programlar yazma yaklaşımından farklı değildir. Yine de dikkatli tasarım, birim testi ve düzgün kodlama gerektirir. Ekstra tek iş, kod yazmanın yanı sıra açıklama yazmaktır.

Bu nedenle sadece - tutarlı açıklamalar yazma ihtiyacı - okuma yazma programlama bazı programcılar için zordur. Başarılı olan çok sayıda programcı vardır (kodları tüm birim testlerini geçer, düzgün ve anlaşılması kolaydır), ancak kendi dillerinde tutarlı bir cümle yazamıyor gibi görünmektedir. Bunun neden doğru olduğunu bilmiyorum.

Sadece çok az başarılı ve sonra sadece kazara başarılı görünen çok sayıda programcı var. (Stack Overflow'da, birçok programcının temel bilgileri bile kavramaya çalıştığını gösteren yeterince kötü sorular var.) Büyük ölçüde tutarsız yığın taşması soruları soran programcılar için, gerçekten iyi bir okuryazar programlama işi yapamayacaklarını biliyoruz, çünkü iyi bir programlama işi yapmayın.


7
Çok sayıda programcı, okuryazar programlama, yorum yazma, hatta bir e-posta gibi, herhangi bir ortamda, resmi veya gayri resmi bir şeyi açıklarken neredeyse hiç tutarlı değildir. Bu harika bir yazılım hiç işe
yaramaz

3

Benim için okuryazar programlamanın en önemli yönü (hatta sadece iyi bir yorum) dokümantasyon sağladığı kadar değil, daha ziyade programcının amacını ifade ediyor. Belirtilen amacı bilerek, onu takip eden kodun gerçekten ne yapması gerektiğini hemen değerlendirebilirsiniz. Niyet olmadan, kodun doğru olduğu varsayımıyla başlamalısınız ve daha sonra tümüyle çevreleyen kodlara aşina olmayı gerektirdiğinden, daha yorucu ve zaman alıcı olan indüksiyonla doğru veya yanlış olduğunu kanıtlamanız gerekir.

Bu nedenle, niyet genellikle, kodu tanımayan diğer kişilerin, onu çevreleyen daha geniş bağlamı bilmek zorunda kalmadan hızlı bir şekilde atlayıp hata bulmalarını sağlar.

Ve elbette, basit İngilizce çoğu insan için işaretçi aritmetiğinden daha sezgisel olduğundan, kodun temel akışını ve tasarımını daha hızlı öğrenmenize yardımcı olur.


1

Litterat programlama kavramında kendim için yeni olsa da (ve bu yüzden tekneyi tamamen kaçırıyorum), bir DSL konseptiyle aynı çizgide gibi görünüyor .

Bir DSL'in arkasındaki fikir, bir problem alanını, bu problemleri çözmek için algoritmalar oluşturmak için kullanılabilecek basit, doğal dil odaklı bir dilbilgisine damıtmaktır.

Bana göre, aynı fikir ya da en azından temel temeli, okuryazar programlama ile aynı ya da en azından yakından ilişkilidir.

Örneğin, güçlü dünyada DSL'leri daha düzenli kullanmak ve yaygın sorunları çözmek için yeni DSL'ler oluşturmak için güçlü bir baskı vardır. Bu push, hem dil içindeki araçlardan (kolay oluşturucular) hem de DSL tabanlı bir API'yi destekleyen çekirdek kitaplıklardan gelir.

En azından dünyanın bu köşesindeki eğilimin okuryazar programlamaya yönelik olduğu düşünüldüğünde, bunun için çabalamanın iyi bir yöntem olduğunu söyleyebilirim.

Ne yazık ki, iyi bir dsl oluşturmak için gerekli düşünme düzeyi çoğu zaman programcıların ötesinde, gördüğümden. Zaman zaman ihtiyaç duyulan bazı kavramlarla şahsen mücadele ettiğimi biliyorum. Bu tür tekniklerin daha yaygın bir şekilde benimsenmesini engelleyen bu zorluk olabilir.

Bu aracı kullanırken klasik durumunuz bir şeydir, ancak oluşturmak tamamen farklı bir düzeydedir.


Bakış açımı biraz genişletmek için, DSL'lerin okuryazar programlama ile aynı şey olması değil, daha çok okuryazar programlamayı daha mümkün kılıyorlar . Özellikle doğal dil DSL'leri olduğunda .

Mükemmel 1.8 sürümünde, doğal dil DSL özelliği daha güçlü komut zincirleri eklenerek önemli ölçüde geliştirildi .

Örneğin, yalnızca kod cümleleri değil , aşağıdaki kod satırları programlanmaktadır :

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Not: Kod örneği Guillaume Laforge'un blogundan gelir

Okuryazar programlamanın ardındaki temel fikir, doğal dilin insanlar için daha anlaşılır olmasıdır. Groovy'nin doğal dil DSL yetenekleri bence bunu çok daha yakın bir gerçeklik haline getiriyor. Özellikle bu DSL'ler bir uygulama için iş kuralları oluşturmak amacıyla kullanıldığında.

Doğal dil kullanarak bir sistemin kritik bileşenlerini "kodlayabilme", ​​okuryazar programlamanın özüdür. Doğal dili kod parçalarıyla dağıtmak, okuryazar programlamanın piç haline getirilmiş bir şeklidir. Yararlı olsa da, doğal dili kod olarak kullanmanıza izin veren doğal dil DSL'lerinin ileriye doğru büyük bir sıçrama olduğuna inanıyorum .

Genel olarak programlama kabiliyetini genişletmek, sürecin bir sonraki adımıdır, ancak büyük ölçüde bunu yapacak araçlar zaten mevcuttur. Evet, henüz "genel" bir DSL yok, ancak daha küçük alanlar için bu özellik mevcut.

Bunun eylemdeki diğer örnekleri için (belirli bir sırayla):


2
İlginç bir bakış açısı. Benim bakış açımdan DSL ile pek uyumlu değil. Okuryazar programlama olduğundan içinde olmayan bazı DSL dili. Ve araçlar da bir DSL gibi değil. Sorun alanına yönelik değillerdir. Okuryazar programlamanın bir DSL gibi olduğunu düşündüğünüz bir örnek verebilir misiniz? Bir bağlantı veya bir örnek referansı cevabınızı netleştirmeye yardımcı olabilir.
S.Lott

Bunun bir örneği gibi şeylerle "programı" izin Groovy 1.8 komut zinciri turn left then rightya paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/...
cdeszaq

@ S.Lott - DSL'ler ve okuryazar programlama arasında kesinlikle bir fark olduğunu kabul ediyorum, ancak DSL'lerin doğal ish dili yazabileceğiniz ve istenen algoritmayı ifade etmesini sağlayabileceğiniz gerçek okuryazar programlama elde etmek için bir araç olabileceğini düşünüyorum . Bana göre, doğal dili ve kodu karıştırmak piç bir okuryazarlık biçimidir.
cdeszaq

"natural-ish dilini yazıp istediğiniz algoritmayı ifade etmesini sağlayabilirsiniz" en iyi ihtimalle mümkün değildir. Arka plan, gerekçe, doğruluk kanıtı, karmaşıklık iddiaları ( big- O ) ve bir DSL planının parçası olmayan alogitmik olmayan destekleyici belgeler vardır. Şimdi açıklığa kavuşturduğunuza paralel olarak katıldığımdan emin değilim.
S.Lott

1
msgstr "program mantığının açıklaması". Mantığın kendisi değil. Ama bir açıklama. Mantık nadiren açıklayıcıdır. Asla bir doğruluk kanıtı içermez (bu zor ve bazen imkansızdır). Nadiren big-O karmaşıklığının bir gerekçesi içerir. Ve nadiren düşük performans veya daha fazla bellek olan alternatifleri açıklar. Bu yüzden, DSL'nin "açıklama" dan çok az düştüğünü öneririm.
S.Lott

-2

Bence bu LP'nin bir çeşit DSL olduğunu düşünmek yanlış. LP - geliştirilmiş programın dergisi (şemalar, şemalar, sahte kod parçaları, yani parçalar) olduğu için mimarisi ve benzeri ... Kesinlikle kağıt defter analogu - çoğu geliştirici bunları kullanıyor ancak programı bitirdikten sonra - defterlerinizi, kağıtlarınızı bırakın ...

Uzun zaman önce her fizikçi, astonomer, kimyager / simyacı, matematikçinin kendi not defterleri, birçok şemaya sahip el yazmaları, gerekli bilgiler, tablolar vardır ve bunlar olmadan başarılı deneyimlerini, sonuçlarını anlayabilir veya tekrarlayabilirsiniz. Ve her zaman bu tür insanlar arasında el yazmaları / defterler avlanır.

Bugün birçok programcı kod yazıyor ve bazen yorum ekliyor! Byt programı sadece kod değil - düşünceler, fikirler, hayal gücü, kavramlar ve yeni geliştirici yabancı kodu devraldığında - tüm fikir ve kavramları sık sık bozar, farklı "boşluklar" ve "arka kapılar" yapar, umarım beni anlarsın :)

Yani, LP için temel gereklilik (araç olarak!) Bunların hepsine basit, hafif, okunabilir sözdizimi ile izin vermek. Birçok LP aracını denedim, ancak bugün bu talebi yerine getirmeyi amaçlayan kendi NanoLP ( http://code.google.com/p/nano-lp/ ) geliştiriyorum .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.