Umiejętność programowania, dobra / zła metodologia projektowania

10

Niedawno znalazłem pojęcie programowania literackiego . Uznałem to za dość intrygujące. Jednak nie spotkałem się z twierdzeniami, że jest to zły sposób na strukturę programu. Wydaje się, że nie obejmuje wielu miejsc. Nawet tutaj nie mogłem znaleźć żadnych pytań na ten temat.

Moje pytanie nie dotyczy wad i sposobów zarządzania dokumentacją. Uważam, że dokumentacja jest efektem ubocznym tego, co oznaczałoby przepływ programów piśmiennych. Wiem, że projekt pierwotnie miał na celu łatwą dokumentację, a także koncepcję dalszego programowania.

Pomysł podzielenia problemu na małe problemy oparte na zdaniu wydaje się naprawdę świetnym pomysłem. Ułatwi to w ten sposób zrozumienie przebiegu programu.

Konsekwencją umiejętnego projektowania jest także to, że liczba wymaganych funkcji będzie ograniczona do wyobraźni programisty. Zamiast definiować funkcję dla określonego zadania, można ją utworzyć jako scrapmetodę czytania i pisania. Spowodowałoby to automatyczne wstawienie kodu zamiast oddzielnej kompilacji funkcji, a następnie wymaganie kroku optymalizacji procedury między kompilacjami w celu uzyskania równoważnej prędkości. W rzeczywistości pierwsza próba Donalda E. Knutha wykazała gorszy czas wykonania z tego właśnie powodu. Wiem, że kompilatory można na wiele z tego zrobić, jednak nie jest to moim zmartwieniem.

Chciałbym więc uzyskać informację zwrotną, dlaczego należy uważać to za złą / dobrą metodologię projektowania?

design-patterns language-design literate-programming zero
źródło
2
Zeroth, stworzyłem tag programistyczny i dodałem streszczenie na podstawie artykułu z Wikipedii. Pomóż rozwinąć tag wiki z odpowiednimi informacjami.
yannis
@YannisRizos Dodam go tutaj, nie mam uprawnień do edycji.
zero
1
Cóż, ja też :) Dodałem trochę zasobów (artykuł w Wikipedii i linki w twoim pytaniu), pojawią się one, gdy edycja zostanie sprawdzona i zaakceptowana (?!). To intrygujące podejście, a ponieważ już go odkrywasz, wróć i ulepszaj tag wiki za każdym razem, gdy znajdziesz coś, o czym Twoim zdaniem warto tam wspomnieć.
yannis
1
Poleciłbym autorowi strony Literate Programming odwiedzić stronę wymiany stosów UX - kolory są naprawdę złe do czytania.
Danny Varod
1
Do Twojej wiadomości, literate-programmingStackOverflow ma również tag. Jest tam więcej treści, choć wciąż niewiele.
Ross Patterson

Odpowiedzi:

9

Spowodowałoby to automatyczne wstawienie kodu, zamiast oddzielnej kompilacji funkcji, a następnie wymaganie etapu optymalizacji kompilacji między procedurami w celu uzyskania równoważnej prędkości

To nie ma znaczenia. Od dziesięcioleci. Możesz usunąć to z pytania, ponieważ nowoczesne kompilatory nie mają sensu obalać optymalizatorów.

Chciałbym więc uzyskać informację zwrotną, dlaczego należy uważać to za złą / dobrą metodologię projektowania?

Umiejętność programowania nie ma żadnych wad. (Spodziewam się dziesiątek głosów -1 za to zdanie). Jako praktykujący nigdy nie widziałem żadnych problemów.

Istnieje kilka argumentów, przeciwko którym wszystko, co sprowadza się do „programowania w języku wyższego poziomu, zostaje obalone przez udoskonalenie wynikowego kodu”. Dobrze. W ten sam sposób, w jaki programowanie w C ++ jest podważone przez udoskonalenie .otworzonego pliku. To prawda, ale bez znaczenia.

Pisanie piśmiennych programów oznacza jedynie połączenie wysokiego poziomu i szczegółowości (na poziomie kodu) projektu w jednym dokumencie, napisanym za pomocą odpowiedniego zestawu narzędzi, który tworzy pliki przyjazne dla kompilatora i pliki przyjazne dla ludzi.

Kiedy Knuth wynalazł umiejętność pisania i czytania, główne języki OO nie istniały. Dlatego wiele oryginalnych narzędzi internetowych i tkackich pozwoliło mu tworzyć definicje klasowe dla abstrakcyjnych typów danych.

Wiele z tego jest obecnie bez znaczenia. Narzędzia do programowania piśmiennego mogą być dość proste, jeśli koncentrują się na nowoczesnych, obiektowych (lub funkcjonalnych) językach programowania wysokiego poziomu. Istnieje mniejsze zapotrzebowanie na skomplikowane obejścia ze względu na ograniczenia C (lub Pascala lub asemblera).

Podejście do pisania programów czytania i pisania nie różni się od pisania programów niepiśmiennych. Nadal wymaga starannego projektowania, testów jednostkowych i starannego kodowania. Jedyną dodatkową pracą jest pisanie wyjaśnień oprócz pisania kodu.

Tylko z tego powodu - konieczności pisania spójnych wyjaśnień - umiejętność pisania i czytania jest trudna dla niektórych programistów. Istnieje spora liczba programistów, którzy odnoszą sukcesy (ich kod przechodzi wszystkie testy jednostkowe, jest zgrabny i łatwy do zrozumienia), ale nie potrafią napisać spójnego zdania w swoim ojczystym języku. Nie wiem, dlaczego to prawda.

Istnieje bardzo duża liczba programistów, którzy wydają się odnosić niewielkie sukcesy, a potem tylko przypadkowo. (W przepełnieniu stosu jest wystarczająco dużo złych pytań, które wskazują, że wielu programistów stara się nawet zrozumieć podstawy.) W przypadku programistów, którzy zadają w dużej mierze niespójne pytania dotyczące przepełnienia stosu, wiemy, że nie potrafią naprawdę dobrze napisać programowania, ponieważ mogą nie wykonuj dobrej roboty programistycznej.

S.Lott
źródło
7
Duża liczba programistów jest mało spójna, tłumacząc coś na dowolnym nośniku, zarówno formalnym, jak i nieformalnym, zarówno w zakresie programowania, pisania komentarzy, a nawet wiadomości e-mail. To cudowne, że oprogramowanie w ogóle działa :)
Andres F.
3

Najważniejszym aspektem umiejętności czytania i pisania (a nawet po prostu dobrego komentowania) jest dla mnie nie tyle dostarczenie dokumentacji, co raczej określenie intencji programisty. Znając podaną intencję, możesz od razu ocenić, czy kod po nim naprawdę robi to, co powinien. Bez intencji musisz zacząć od założenia, że ​​kod jest poprawny, a następnie udowodnić, że jest poprawny lub błędny przez indukcję - co jest bardziej wyczerpujące i czasochłonne, ponieważ często wymaga również zapoznania się z całym otaczającym kodem.

Tak wyrażona intencja często pozwala innym osobom niezaznajomionym z kodem szybko wskoczyć i znaleźć błędy bez konieczności poznawania otaczającego go szerszego kontekstu.

I oczywiście pomaga także szybciej nauczyć się podstawowego przepływu i projektowania kodu, ponieważ zwykły angielski jest często bardziej intuicyjny niż arytmetyka wskaźników dla większości ludzi.

Mike Owens
źródło
1

Chociaż sam jestem nowicjuszem w programowaniu śmieciowych programów (i dlatego prawdopodobnie całkowicie tęsknię za łodzią), wydaje się, że bardzo zgadza się z koncepcją DSL .

Ideą DSL jest rozdzielenie dziedziny problemów na prostą gramatykę zorientowaną na język naturalny, którą można wykorzystać do budowy algorytmów rozwiązywania tych problemów.

Dla mnie ten sam pomysł, a przynajmniej jego podstawowa podstawa, jest taki sam lub przynajmniej ściśle związany z programowaniem literackim.

Na przykład w groovy świecie istnieje silna potrzeba regularnego korzystania z DSL i tworzenia nowych DSL w celu rozwiązania typowych problemów. Takie wypychanie pochodzi zarówno z narzędzi w języku (łatwych konstruktorów), jak iz bibliotek podstawowych obsługujących interfejs API oparty na DSL.

Biorąc pod uwagę, że trend, przynajmniej w tej części świata, jest w kierunku programowania literat, powiedziałbym, że jest to dobra metoda, aby dążyć.

Niestety, poziom myślenia potrzebny do stworzenia dobrego dsl często przekracza większość programistów, z tego co widziałem. Wiem, że od czasu do czasu mam problemy z niektórymi pojęciami. Być może ta trudność uniemożliwiła takim technikom szersze zastosowanie.

To klasyczny przypadek korzystania z tego narzędzia to jedno, ale tworzenie go odbywa się na zupełnie innym poziomie.

Aby nieco rozwinąć mój punkt widzenia, nie jest tak, że DSL są takie same jak programowanie literackie, ale raczej sprawiają, że programowanie literackie jest o wiele bardziej możliwe . Szczególnie, gdy są to DSL w języku naturalnym .

W wersji 1.8 Groovy zdolność DSL w języku naturalnym została znacznie ulepszona dzięki dodaniu mocniejszych łańcuchów poleceń.

Na przykład, następujące wiersze kodu programowania , nie tylko pseudo-zdania:

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"

Uwaga: próbka kodu pochodzi z bloga Guillaume Laforge

Podstawową ideą programowania piśmiennego jest to, że język naturalny jest bardziej zrozumiały dla ludzi i to jest ważne. Moim zdaniem, możliwości DSL języka naturalnego Groovy sprawiają, że jest to o wiele bliższa rzeczywistość. Zwłaszcza, gdy te DSL są używane do tworzenia reguł biznesowych dla aplikacji.

Umiejętność „kodowania” krytycznych elementów systemu za pomocą języka naturalnego jest samą istotą umiejętności czytania i pisania. Konieczność przeplatania języka naturalnego z fragmentami kodu jest przeklętą formą umiejętności czytania i pisania. Chociaż przydatne, uważam, że DSL w języku naturalnym, które pozwalają używać języka naturalnego jako samego kodu, stanowią ogromny krok naprzód.

Poszerzenie możliwości programowania na ogół jest kolejnym krokiem tego procesu, ale w dużej mierze narzędzia do tego celu są już dostępne. Tak, nie ma jeszcze „ogólnej” DSL, ale w przypadku mniejszych domen istnieje możliwość.

Aby uzyskać więcej przykładów tego w akcji (w określonej kolejności):

cdeszaq
źródło
2
Ciekawy punkt widzenia. Z mojego punktu widzenia wcale nie wygląda to dobrze z DSL. Ponieważ umiejętność programowania jest w języku innym niż DSL. Narzędzia też nie przypominają DSL. Nie są zorientowane na domenę problemową. Czy możesz podać przykład, w jaki sposób uważasz, że umiejętność pisania i czytania jest jak DSL? Link lub odniesienie do przykładu może pomóc w wyjaśnieniu twojej odpowiedzi.
S.Lott,
Jednym z przykładów są łańcuchy poleceń w Groovy 1.8, które pozwalają ci „programować” za pomocą takich rzeczy jak : turn left then rightlub paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…
cdeszaq
@ S.Lott - Zgadzam się, że zdecydowanie istnieje różnica między DSL a programowaniem alfabetyzacji, ale myślę, że DSL mogą być narzędziem do osiągnięcia prawdziwego programowania alfabetyzacji, w którym można pisać język naturalny i wyrażać pożądany algorytm. Dla mnie mieszanie języka naturalnego i kodu jest dranią formą umiejętności czytania i pisania.
cdeszaq
„możesz wpisać język naturalny i wyrazić pożądany algorytm” w najlepszym wypadku jest mało prawdopodobne. Jest tło, uzasadnienie, dowód poprawności, twierdzenia o złożoności ( duże- O ) i mnóstwo niealogitmicznej dokumentacji pomocniczej, która nie jest częścią schematu DSL. Nie jestem pewien, czy zgadzam się z tym, co zostało wyjaśnione.
S.Lott,
1
„wyjaśnienie logiki programu”. Nie sama logika. Ale wyjaśnienie. Logika rzadko jest oczywista. Nigdy nie zawiera dowodu poprawności (jest to trudne, a czasem niemożliwe). Rzadko zawiera uzasadnienie złożoności wielkiej-O. I rzadko tłumaczy alternatywy, które są albo niższą wydajnością, albo większą ilością pamięci. Sugerowałbym więc, że DSL nie ma wystarczającego „wyjaśnienia”.
S.Lott,
-2

Myślę, że błędem jest myśleć, że LP to coś w rodzaju DSL. Ponieważ LP jest - dziennikiem (ze schematami, schematami, fragmentami pseudokodu, tj. Fragmentami) opracowanego programu, ma architekturę i tak dalej ... Jest absolutnie analogiczny do papierowego notatnika - wielu programistów korzysta z niego, ale po zakończeniu programu - porzuć swoje zeszyty, papiery ...

Dawno temu każdy fizyk, astonomer, chemik / alchemik, matematyk posiadał własne zeszyty, rękopisy z wieloma schematami, potrzebne informacje, tabele, a bez nich można zrozumieć lub powtórzyć ich udane doświadczenie, jego wyniki. I zawsze między takimi ludami istnieje polowanie na manuskopy / zeszyty.

Dziś wielu programistów pisze kod, a czasem dodaje komentarze! Program Byt to nie tylko kod - to myśli, pomysły, wyobraźnia, koncepcje, a gdy nowy programista dziedziczy kod obcy - często łamie wszelkie pomysły i koncepcje, tworzy różne „luki” i „tylne drzwi”, mam nadzieję, że mnie rozumiesz :)

Tak więc głównym wymaganiem dla LP (jako narzędzia!) Jest również zezwalanie na wszystkie z prostą, lekką, czytelną składnią. Próbowałem wielu narzędzi LP, ale dziś rozwijam własny - NanoLP ( http://code.google.com/p/nano-lp/ ), który ma na celu spełnienie tego żądania.

Paul-AG
źródło