Dlaczego umiejętność czytania i pisania nie jest głównym nurtem programowania? [Zamknięte]

32

Programowanie piśmienne ma dobre ideały. Dlaczego uważasz, że to nie jest główny nurt? Czy to dlatego, że nie udało się dostarczyć?

Casebash
źródło
2
Ponieważ narzędzia, które zostały opracowane do tego celu, są nadal dość słabe. Microsoft prawdopodobnie ma szansę przewodzić w tym zakresie.
Job
3
Kiedy podchodzę do nowego problemu, często używam własnego „programowania piśmiennego”, używając ołówka i papieru. Pozwala mi to ignorować semantykę języka i mieszać w języku ludzkim, aby opisać te rzeczy, które będą nazywane funkcjami itp.
oosterwal
1
Nawet Knuth nie jest już przekonany o tej koncepcji: „Porzucamy stare pojęcie„ programowania piśmiennego ”, które stosowałem przy opracowywaniu TEX82, ponieważ dokumentacja okazała się zbyt wielkim problemem”. tug.org/TUGboat/tb31-2/tb98knut.pdf .
h0b0
6
Dla osób niezaznajomionych z TeX-em i jego filozofią należy wspomnieć, że cytat Knutha najprawdopodobniej ma ironiczne znaczenie.
3
@ h0b0 & user1249: Cały artykuł autorstwa Knutha jest ironią, o czym można się dowiedzieć po przeczytaniu go. Wyśmiewa także Steve'a Jobsa, Internet, Agile, refaktoryzację, OOP, AOP i wiele innych rzeczy. To żart!
Andres F.,

Odpowiedzi:

35

Po raz pierwszy zobaczyłem to w księdze pism Knutha i pomyślałem, że wygląda to schludnie. Potem spróbowałem użyć wyświetlacza programowania literackiego, aby zrozumieć, co się dzieje w programie, i okazało się, że jest trudniejsze niż się wydaje. Możliwe, że byłem zbyt przyzwyczajony do przeglądania list programów, ale wydawało się to mylące.

Potem spojrzałem na kod źródłowy, i to mnie tu i ówdzie wyłączyło. Musiałbym nauczyć się pisać programy w zupełnie nowy sposób, z mniejszą korespondencją między tekstem programu a tym, co widział kompilator, i nie widziałem żadnych korzyści.

Ponadto ludzie mogą pisać długie i przekonujące argumenty, że kod wykonuje X, podczas gdy faktycznie wykonuje Y, i natrafiłem na moją część wprowadzających w błąd komentarzy. Uwielbiam czytać kod, aby zobaczyć, co robi dość wcześnie. Umiejętność programowania jest antytezą tego.

David Thornley
źródło
4
Umiejętności programowania, a także komentarze w ogóle, nie dotyczą tego, co robi Twój kod. Możesz to odczytać z samego kodu. Chodzi przede wszystkim o to, dlaczego i jak , a tych istotnych informacji prawie zawsze brakuje bez odpowiedniego programowania. Nie trzeba dodawać, że część „ dlaczego? ” Dość często obejmowała skomplikowaną i skomplikowaną matematykę, czasem wykresy i tabele, czasem diagramy. Kompetentne narzędzia programistyczne są niezbędne do utrzymania takich komentarzy w czytelny sposób.
SK-logic
1
@ SK-logika uczciwa, ale David Thornley twierdzi, że nawet DLACZEGO DLACZEGO może okazać się kłamstwem wprowadzającym w błąd (jeszcze trudniejszym do zrozumienia).
MrFox,
1
+1 Knuth pisał w (tematycznym) dzikim zachodzie dni programowania, gdy praca w „zaawansowanym” języku oznaczała pisanie „C” prawie na wierzchu metalu zamiast za pomocą kodu maszynowego. Pamięć była tak ciasna, że ​​zmienne, a inne nazwy były zwykle tylko pojedynczymi literami, często ponownie wykorzystywanymi od zakresu do zakresu. Zdecydowana większość programów, w których jeden klucz został nakręcony, napisany i utrzymany przez jedną osobę, każdy w swoim ekscentrycznym stylu. Konieczność przejęcia bazy kodu była bardziej odszyfrowująca niż czytanie. Nie było żadnej kontroli źródła itp.
TechZen
1
Knuth patrzył w dół drogi, 30 lat temu. Wiedział, że programy staną się większe, bardziej skomplikowane, będą pisane przez zespoły ze zmieniającymi się członkami, będą działać przez lata lub dekady i będą wymagały wkładu, oceny i ostatecznie akceptacji ze strony nieprogramistów. Programowanie piśmienne było pomysłem na rozwiązanie tego wszystkiego. Opracowywał to, co dziś nazywamy logiką biznesową i BDD. Podstawową ideą jest to, że programiści będą wiedzieć, co robić, a osoby niebędące programistami mogą podążać za nimi. Jak wspomniano, pomysł nie powiódł się, ponieważ nie istnieje mechanizm wymuszający powiązanie między tekstem „piśmiennym” a kodem.
TechZen
BTW: Dlatego lubię języki „samodokumentujące”, takie jak Objective-C. Na początku kod wygląda na zagracony absurdalnie długimi nazwami metod, ale nawet programista, który nie zna języka ani interfejsu API, może szybko ustalić, co robi kod. A co najlepsze, zmieniaj kod, a „komentarze” zmieniają się automatycznie. Oczywiście, dlatego Objective-C został napisany z wbudowanym autouzupełnianiem. Bez niego pisanie Objective-C jest dość piekielne.
TechZen
13

Winiłbym efekt sieci . Aby inni mogli edytować Twój kod i dokumentację, muszą być w stanie to zrozumieć.

To odsuwa ludzi od czegoś takiego jak cweb / noweb, ponieważ korzystanie z nich wymagałoby nauki TeXa i specyficznej dla programu składni nad językiem programowania, którego używasz w projekcie. Może to być postrzegane jako ogromna strata czasu, zwłaszcza jeśli nie potrzebują żadnego składu matematycznego, który byłby tak dużym pociągnięciem dla TeX-a. (A dla wielu programistów aplikacji tak naprawdę nie będą tego potrzebować.) Zamiast tego wolą coś w rodzaju komentarzy XML Visual Studio, ponieważ jest to już popularne i ugruntowane.

Miejsca, w których widziałem, jak rozwija się umiejętność programowania, to komputeryzacja naukowa / statystyczna, gdzie większość programistów ma znaczące wykształcenie (akademie doktoranckie) w zakresie matematyki, CS lub statystyki, a zatem zna już LaTeX. Dokumentacja, którą piszą, najprawdopodobniej zawiera wiele skomplikowanych formuł, które najlepiej napisać w TeXie, i częściej programują w R. Udział procentowy programistów R, którzy znają SWeave, jest zdecydowanie wyższy niż, powiedzmy, odsetek programistów C, którzy wiedzą o cweb.

Larry Wang
źródło
2
Ta odpowiedź wydaje się zakładać, że wszystkie kompetentne narzędzia programistyczne używają LaTeX. Czy to prawda? Wydaje się, że nic nie wymaga koncepcji.
AShelly
@AShelly: Nie jest wymagane - wiem, że przynajmniej noweb pozwala używać HTML. Ale w praktyce ludzie, którzy piszą dokumentację HTML, używają javadoc i podobnych zamiast literackich narzędzi programistycznych.
Larry Wang
1
@ Ahelly, aby umiejętne programowanie działało, musisz mieć możliwość wygenerowania dokumentu do wydrukowania. Jest to o wiele łatwiejsze, gdy format jest oparty na tekście, i według mojej wiedzy najsilniejszym opartym na tekście formatyzatorem dokumentów jest TeX, a najłatwiejszym sposobem pracy z TeX jest użycie LaTeX.
@ Ahelly, możesz rzucić okiem na org-modewsparcie programowania w zakresie umiejętności czytania i pisania . Jest to całkiem przydatne i znacznie łatwiej jest mi zrozumieć (nie wspominając o zarządzaniu ) niż sama WEB lub NOWEB. Ważnym aspektem kodu jest czytelność, która jest czytelna. (cf github.com/vermiculus/stack-mode )
Sean Allred
12

Podczas nauki fascynowała mnie koncepcja programowania piśmienniczego pod koniec lat 90. i nadal intryguje mnie podejście Knutha do programowania i składu. Nic, tylko najlepsze.

Opracowany przez Knutha system Literate Programming zrobił znacznie więcej niż od razu, a mianowicie przezwyciężył wiele niedociągnięć w podstawowym języku programowania wygenerowanym przez narzędzie do generowania kodu z dokumentu źródłowego Knutha, mianowicie standardowego Pascala.

Dla tych, którzy mieli szczęście, że nie wypróbowali Standard Pascal, oto niektóre z najważniejszych wydarzeń.

  • Aby ułatwić posiadanie kompilatora jednoprzebiegowego, w specyfikacji języka podano, że wszystkie deklaracje muszą występować w określonej kolejności. Ze strony wikipedii: „Każda procedura lub funkcja może mieć własną deklarację etykiet goto, stałych, typów, zmiennych i innych procedur i funkcji, które muszą być w tej kolejności”. Oznaczało to, że nie można logicznie pogrupować swoich rzeczy w pliku źródłowym.
  • Obsługa sznurka była bardziej nużąca niż w zwykłym C.
  • Identyfikatory nie mogą mieć dowolnej długości.
  • O wiele więcej rzeczy, których już nie pamiętam.

Wszystko to w zasadzie oznaczało, że Knuth potrzebował lepszego języka programowania (więc wynalazł jeden) i używał Pascala jako języka asemblera.

Większość współczesnych języków potrafi robić te rzeczy bez większego wysiłku, dlatego też usuwa DUŻĄ część pracy, którą miały rozwiązać Programowanie Literackie.

Również współczesne języki są bardziej wyraziste, co pozwala na głębsze zastanowienie się nad samym kodem.

Co pozostaje? Zdolność do generowania formularza typeset dokumentacji z kodu źródłowego, a ŻE istnieje dzisiaj.

Pomyśl tylko o JavaDoc - Java Runtime API to chyba największy dostępny obecnie program do pisania i pisania (poza tym, że kod nie jest właściwie prezentowany, ale Mógłby tak być, gdyby Java była otwarta od samego początku). Zobacz na przykład prezentację struktury kolekcji na http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Wierzę, że podobne systemy istnieją dla .NET i innych programów głównego nurtu.


źródło
To make it possible to have a single-pass compiler, all declarations had to come in a certain order. Taka kolejność deklaracji z pewnością upraszcza projektowanie kompilatorów, ale nie włącza ani nie zapobiega kompilacji jednoprzebiegowej. Na przykład Delphi nie ma tego ograniczenia kolejności, ale nadal jest to jednokierunkowy kompilator Pascal.
Mason Wheeler
Zgoda. Turbo Pascal również nie miał tego ograniczenia. Należy jednak pamiętać, że to ograniczenie było w definicji Pascala od samego początku.
1
Nie, Knuth już dawno przeszedł na CWEB, nie chodzi o naprawianie braków Pascala. Nie, JavaDoc nie ma nic wspólnego z „umiejętnym programowaniem” Knutha - mówi o zasadniczej zmianie sposobu tworzenia kodu i twierdzenie, że pozwala mu to rozwiązać złożoność, którą, jak twierdzi, inaczej nie byłby możliwy dla niego ani nikogo innego.
Ron Burk
@RonBurk CWEB po prostu kompiluje się do lepszego „języka asemblera”. Nie unieważnia to oryginalnych decyzji projektowych.
Thorbjørn Ravn Andersen
5

Jedną z rzeczy, które odkryłem, kiedy miałem talent do programowania piśmiennego w latach 90., było to, że przyciągnęło to bardzo pasjonujących ludzi, którzy chcieli robić dokładnie to, co właściwe - i to wymagało napisania własnego systemu programowania, ponieważ żaden z nich nie był dla nich wystarczająco dobry. noweb była dobrą próbą odcięcia tego, zapewniając wszystkim wystarczająco dobry, najmniej wspólny mianownik, chociaż nawet wtedy spędziłem większość mojego LP na opracowywaniu do tego ładnej drukarki ...

Inną kwestią jest to, że jest naprawdę anty-zwinny. W pewnym sensie spowolnienie jest dobre, ponieważ zmusza cię do myślenia bardziej z góry i poprawiania sytuacji za pierwszym razem. Z drugiej strony, skrupulatne dokumentowanie podczas pracy oznacza, że ​​istnieje znaczna bariera dla refaktoryzacji kodu. A jeśli zaczekasz, aż kod zostanie zahartowany przed LP, jeśli to zrobisz, skończysz na wielodniowym zadaniu dokumentacyjnym, które naprawdę może cię zatrzymać.

dfan
źródło
Po eksperymentach odkryłem, że najsłodszym punktem LP dla reszty z nas może być dokumentowanie decyzji projektowych i szczegółów architektury tuż obok samego kodu. Zgadzam się z tym, że LP jest trudniejszy do refaktoryzacji. Rozumiem, że Knuth wykonał początkowy projekt na papierze i tylko wtedy, gdy usatysfakcjonowany rozpoczął faktyczną realizację. Jest to najprawdopodobniej ta sama sytuacja, która według mnie działa.
Thorbjørn Ravn Andersen
3

Moim skromnym zdaniem wiele firm ma kulturę przeciwną do celów programowania literackiego: chcą szybszych rezultatów (płaczą tylko z powodu jakości, gdy aplikacja jest w produkcji). Z własnego doświadczenia wynika, że ​​moi szefowie nie rozumieli, że szybsze wyniki nie oznaczają „programu, który można uruchomić następnego dnia po tym, jak o to poproszę”. Dla nich, jeśli programista nie jest zajęty pisaniem na klawiaturze, nie pracuje, „marnuje swój czas na bezsensowne projektowanie”. Tak, wiem, mój szef jest dupkiem.

Nisanio
źródło
Następnie dzięki programowaniu literackiemu mogą pomyśleć, że jesteś zajęty pisaniem książki science-fiction zamiast jeszcze innego oprogramowania! : D
Mahdi,
Firmy takie nie rozumieją, że dobre oprogramowanie żyje bardzo długo, a im lepsza dokumentacja, tym bardziej warte jest źródła.
Thorbjørn Ravn Andersen
2

Kodery piszą kod nie po angielsku.

Kodery nie lubią pisać dokumentacji, ponieważ nie pomaga to w uruchomieniu kodu.

Kodery nie są dobre w pisaniu dokumentacji, ponieważ jest to kiepskie medium do wyrażania swoich pomysłów.

Programowanie piśmienne wydaje się być pomysłem na przeniesienie dokumentacji na wyższy poziom, gdzie kod jest późniejszą refleksją. Może to zadziałałoby, ale dla większości programistów wygląda na nieznośną dokumentację.

Winston Ewert
źródło
29
Kodery, które stosują się do punktów, które opisujesz, nie są programistami, których chciałbym ze mną współpracować.
Paul Nathan
1
@Paul, przyznane. Ale to naprawdę tam jest. Wydaje mi się jednak, że większa ilość dokumentacji niekoniecznie jest lepsza.
Winston Ewert
1
wystarczająca jest prawdopodobnie najlepsza
mlvljr 27.10.10
6
doświadczeni programiści wiedzą, że POTRZEBUJĄ napisać dokumentację, ponieważ właśnie tam znajduje się „DLACZEGO tak to zrobiłem”.
1
@ Thorbjørn Ravn Andersen, tak, to prawda. Ale umiejętność programowania (jak rozumiem) sugeruje pisanie kodu z dokumentacją zamiast dokumentacji z kodem. Czy taka dokumentacja jest naprawdę pomocna?
Winston Ewert
2

Głównie dlatego, że ludzie są BARDZO GŁUPI. Oczywiste świadectwo, którego jest niekończącym się strumieniem domysłów i nieporozumień wyrażanych przez młodych ludzi na temat natury tej prostej techniki.

Ludzie biorą LP za: (a) metodę dokumentacji (b) metodę pisania niektórych dopracowanych esejów, która wymaga pewnych specjalnych umiejętności lub talentów (c) po prostu nie mają pojęcia - jako twórca edytora programowania Leo, jak sam przyznaje itp. itd. itd.

LP to po prostu: (1) pisanie programów w mieszance kodu i fraz w (= dowolnym) ludzkim języku, przy czym te ostatnie oznaczają inne fragmenty kodu i / lub dołączone frazy. To właśnie robią autorzy niezliczonych podręczników programistycznych .. i (2) jest to prosty preprocesor, który rozszerza te wyrażenia w ludziach (które stały się jakby nazwami zawartych podprogramów), aby rozwikłać wynik W ZAMÓWIENIU WYMAGANYM PRZEZ KOMPILERA (lub interpretator). W przeciwnym razie można rozszerzyć napisany tekst za pomocą innego małego narzędzia, aby włączyć symbole formatowania, aby przekształcić „źródło piśmienności” w ładny, dobrze sformatowany, czytelny tekst.

Młodzi ludzie nigdy nie próbują tego niezwykle prostego pomysłu - albo fantazjują, albo wyobrażają sobie fałszywe powody, dla których nigdy tego nie spróbują.

Zasadniczo główna idea programowania „w pseudokodzie” napisanym w ludzkim języku, a następnie rozszerzania go za pomocą prostego narzędzia preprocesora POMAGA ZARZĄDZAĆ UWAGĄ (ograniczona, główna trudność dla każdego długiego programu), podobnie jak zwijanie kodu lub podział przepływu programu w funkcje / podprogramy, potrzebne, abyś nie zagubił się w szczegółach, ale całkowicie niepotrzebny do wykonania maszyny.


źródło
3
Brakuje jednego ważnego bitu: (3) sposobu zmiany kolejności kodu w dowolnym języku na najbardziej czytelną i naturalną sekwencję, co niekoniecznie jest tym samym porządkiem, z jakim musi sobie radzić kompilator. Obejmuje to ukrywanie szczegółów implementacji w przypisach lub w innym miejscu daleko od obrysu kodu.
SK-logic
1

Istnieją dwa aspekty programowania piśmiennego, które, jak chciałbym, zostały włączone do programowania głównego nurtu - osadzone zdjęcia (np. Schematy projektowe) i wskaźniki do poprzednich i alternatywnych prób (np. „Powodem jest to, ponieważ próbowałem w inny sposób i nie działało, ponieważ ... ”). Oba te aspekty można rozwiązać za pomocą doc-comments i URI.

Larry OBrien
źródło
1

Ponieważ logika programów nie działa tak jak my mówimy. Program ma dobrze określony przepływ oraz warunki i pętle.

Po kodowaniu na bieżąco MYŚLĘ w tych kategoriach. Mój mózg przekształca problemy w domenę docelową kodu wykonywalnego. I jest o wiele bardziej wydajne dla mnie, aby zapisać to w zwykle języku programowania, niż robić dodatkowy krok transformacji, aby moje programy potrafiły pisać.

W rzeczywistości uważam, że moje programy są już kompetentne ... identyfikatory mówiące, dobre nazwy funkcji, komentarze, w których zrobiłem trochę hakerów, których sam nie zrozumiałbym natychmiast po kilku miesiącach.

Podsumowując: Mój kod Java sam w sobie jest bardziej kompetentny, tak jak chce tego każde programowanie.

Daniel
źródło
2
Kod Java nie umie pisać. Twoje „mówiące identyfikatory” nigdy nie wyjaśnią, dlaczego wybrałeś ten konkretny algorytm ponad inny, jakie są granice, jakie były twoje oczekiwania dotyczące profilu wydajności itp. Moje umiejętności czytania i pisania składają się głównie z formuł, diagramów i wykresów, i nie za dużo angielski tekst. Ale wszystko to nie może być wyrażone w kodzie i wygląda brzydko w prostych komentarzach.
SK-logic
1

Przyszedłem pisać się na temat programowania na odwrót - marzyłem, żeby kod był zorganizowany tak, aby pasował mi do głowy, a nie tak, jak wymaga tego kompilator. Uważam, że Leo jest prawie idealny do tego celu. Obsługuje również śledzenie plików zmienionych na zewnątrz. Te pliki nie muszą zawierać żadnych specjalnych znaczników, więc mogę używać Leo dla siebie bez potrzeby, aby inni w zespole o tym wiedzieli. Ta funkcja - „@shadow trees” - jest bardzo obiecująca, choć wciąż nieco wadliwa, wymaga więcej gałek ocznych. Rozwiązuje również problem „o nie, wszystko w jednym dużym pliku” zarówno poprzez organizowanie wszystkiego w zarys drzewa, jak i przez obsługę plików zewnętrznych.

Dla mnie, wbrew nazwie, „umiejętność programowania” w ogóle nie dotyczy dokumentacji. Nie mam więcej dokumentacji niż wcześniej. Chodzi o posiadanie struktury, która pomaga mi się nie zgubić . Przysięgam, zwłaszcza przy zarządzaniu plikami JSP-Behemoth (i że pomimo tego, że Leo był pierwotnie przeznaczony głównie dla Pythona i nie obsługuje języka JSP - muszę ręcznie podzielić plik na drzewo Leo!).

Juraj
źródło
0

Widzę to jako cenne narzędzie dydaktyczne, w którym można napisać rozprawę o kodzie, a następnie przepleciono w nim fragmenty działającego kodu, aby poinstruować czytelników o tym, jak i dlaczego.

Myślę, że poza środowiskiem czysto edukacyjnym tylko Knuth naprawdę wie, jak najlepiej z niego korzystać.

greyfade
źródło
-4

To najgorszy ze wszystkich światów - musisz napisać bardzo poprawny, bardzo specyficzny program komputerowy w bardzo nieokreślonym języku = angielski. Musisz więc starannie napisać, używając dokładnie poprawnych fraz - tak samo możesz napisać kod.

Martin Beckett
źródło
3
Nie powinieneś powtarzać swojego kodu po angielsku. Komentarze muszą wyjaśniać powód, dla którego kod istnieje, a nie to, co robi. Często umieszczam wykresy, diagramy i wykresy w swoich piśmiennych komentarzach, a to naprawdę pomaga zrozumieć kod.
SK-logic
Jeśli komentarze nie mówią o tym, co robi kod, to jak to rozumie programowanie - to tylko zwykłe programowanie z komentarzami. Myślałem, że cały sens programowania piśmiennego polegał na opisaniu programu w dokumentacji i umożliwieniu systemowi wygenerowania kodu z dokumentacji?
Martin Beckett,
3
spróbuj przeczytać „TeX, program”. Kod nigdy się nie powtarza w komentarzach. Komentarze wyjaśniają, dlaczego kod został napisany w ten sposób, i wyjaśnia architekturę.
SK-logic
3
@MartinBeckett To, co opisujesz, nie jest LP.
Andres F.,