🚀 go-pugleaf

środa, 7 kwietnia 2021 o 22:07:20 UTC+2 Maciej Sobczak napisał(a):
> > (Akurat w przypadku deski jestem bez trudu w stanie sobie wyobrazić, że może być częścią dokumentacji jako referencyjna jednostka długości w jakimś projekcie)
> Brawo. Czyli rozumiesz już różnicę pomiędzy artefaktem, który jest na ścieżce generacji produktu od takiego, który nie jest. 
> Ta deska referencyjna jest dokumentacją. Ale deska użyta do budowy budy dla psa już nie jest - dokładnie tak było z diagramami parę postów wcześniej. 

Teraz złap się czegoś, żeby nie spaść z krzesła: buda dla psa też może być dokumentacją. Wraz z każdą użytą w niej deską.

> > > Bo medium może być współdzielone. Nadal jednak odróżniam te dwie rzeczy. 
> > W porządku. Ty odróżniasz. Ale Wikipedia, na którą się powołujesz, nie odróżnia.
> Może ktoś kiedyś dopisze. :-D Wikipedia nie jest wykuta w kamieniu.

To nie o to chodzi.
Chodzi o to, że Ty stwierdziłeś, że "Jeżeli diagram służy do generowania kodu, to *nie* jest dokumentacją, tak samo jak kod źródłowy (który też służy do generowania czegoś) nie był dokumentacją", natomiast na moje pytanie o to, dlaczego nie, odpowiedziałeś linkiem do artykułu na Wikipedii, z którego odpowiedź na to pytanie w żaden sposób nie wynika.

Definicja, którą podaje Wikipedia, jest bardzo inkluzywna: "rodzajem nadrzędnym" czy też "genus proximum" dokumentacji jest "dowolny materiał" (czyli bardzo dużo przedmiotów podpada pod tę deskrypcję), natomiast "różnicą gatunkową" czy też "differentia specifica" jest to, że "służy do opisania, wyjaśnienia bądź poinstruowania".

Na ile do tej pory zdołałem się zorientować, definicja dokumentacji, którą Ty masz na myśli, byłaby taka, że dokumentacja to "materiał, którego główną funkcją jest opisanie, wyjaśnienie bądź poinstruowanie", albo "materiał stworzony przede wszystkim w celu opisania, wyjaśnienia" itd.

To jest mniej inkluzywna definicja, i oczywiście możesz się na nią powoływać, ale w momencie, kiedy powołujesz się na inną definicję, żeby uzasadnić coś, co wynika z Twojej definicji, wprowadzasz tylko zamieszanie (moim zdaniem dość niepotrzebnie).

Przy okazji - odnośnie Twojego wcześniejszego rozróżnienia na "definiowanie i dokumentowanie" -- dokładnie z tym samym mamy do czynienia w prawie.
Dokumenty prawne - ustawy, rozpotrządzenia - są zarazem "źródłem prawa" w tym sensie, że definiują, jakie działania są legalne.

> > Studiowanie kodu źródłowego nie jest formą inżynierii wstecznej.
> https://en.wikipedia.org/wiki/Reverse_engineering 
> 
> Zdumiewająco duża część tego artykułu, w odniesieniu do oprogramowania, dotyczy właśnie różnych form wyciągania wiedzy z kodu źródłowego. Czytanie kodu źródłowego to jest właśnie reverse engineering.

Znamienne, że artykuł zaczyna się od uwagi: "This article has multiple issues."
W ogólności jest raczej dość długi, więc jeżeli jest jakieś zdanie albo akapit, który miałbyś na myśli, to pewnie wskazanie albo przytoczenie go ułatwiłoby komunikację.
Moją uwagę przykuło zdanie (na początku sekcji 2.3 pt. "Source code"):
"A number of UML tools refer to the process of importing and analysing source code to generate UML diagrams as "reverse engineering.""

Co jest znamienne, bo po pierwsze pokazuje, jak mętne i niedookreślone jest pojęcie "reverse engineeringu", a po drugie, że zwolennicy najwidoczniej UML uważają, że ich język jest "notacją, w której wyraża się źródłowa intencja budowy systemu". Podczas gdy tym czasem bardzo wiele procesów wytwarzania oprogramowania w ogóle nie uwzględnia UMLa na żadnym ze swoich etapów, i jeżeli w wyniku "reverse engineeringu" za pomocą wspomnianych narzędzi otrzymasz jakiś artefakt, to on nie będzie żadnym odtworzeniem czegokolwiek.

> > Ale to nie jest jedyny aspekt. Jakiś czas temu zauważyłem, że studiowanie definicji przychodzi mi z pewnym trudem -- bo definicje są z natury rzeczy raczej abstrakcyjne. Z tego też względu lubię mieć w kodzie przykłady użycia różnych definiowanych przez siebie funkcji. W moim doświadczeniu posiadanie takich konrketnych, namacalnych przykładów jest najefektywniejszą formą dokumentacji, z jakiej do tej pory korzystałem.
> Jak najbardziej. 
> Ale Knuth w swojej słynnej książce specjalnie podjał najpierw wysiłek opracowania języka, który nie miał żadnej znanej implementacji, żeby z jednej strony zapewnić sobie precyzję opisu, ale z drugiej nie sugerować, że te przykłady są fragmentami konkretnych projektów. W ten sposób chciał zachować czystość narracji. 

To też jest przykład, który dla mnie jest znamienny: książka Knutha jest raczej słynna z tytułu i nazwiska autora, niż z tego, żeby była popularną lekturą wśród młodzieży.
Po części problem wynika stąd, że Knuth zaczął ją pisać w latach 60., kiedy obsługa komputerów często wymagała zaznajamiania się z ich partykularnymi zestawami instrukcji.
Wtedy stworzenie asemblera "MIX" mogło wydawać się racjonalne, bo rzeczywiście wiązało się z pewnymi umiejętnościami, które były wymagane.
Natomiast od tamtej pory wiele się zmieniło: upowszechnił się język C oraz inne języki wysokiego poziomu, dzięki którym "ten sam program" można uruchamiać na różnych zestawach instrukcji.
Pojawiły się też komputery osobiste, które za pomocą BASICa spopularyzowały "symboliczne programowanie", i zredefiniowały rozumienie tego, czym jest programowanie, wśród kolejnego pokolenia programistów.
I tym sposobem książka Knutha - mimo że porusza tematykę uniwersalną - nie porusza jej w uniwersalny sposób.
Dla mnie pewnym kontrastem dla tej książki jest "Struktura i Interpretacja Programów Komputerowych", która też porusza uniwersalne kwestie, ale w sposób bardziej uniwersalny, bo pomimo, że używa języka, którego też nikt nie używa, używa języka, który - w przeciwieństwie do asemblera - jest ekspresywny.

To przywodzi na myśl anegdotę opowiedzianą przez Breta Victora o reakcji von Neumanna na to, jak jeden z jego studentów opracował asembler, dzięki któremu nie trzeba było programować w kodzie maszynowym:
https://www.youtube.com/watch?v=8pTEmbeENF4

> > No, może problemem jest to, że programowanie nie do końca jest "branżą inżynierską".
> Podobnie, jak nie każda kupa desek to architektura. 
> To nie jest tak, że "nie do końca", tylko właśnie "szerzej niż". Powszechne praktykowanie programowania daleko wykracza poza inżynierię. Dlatego mamy masę projektów, które z inżynierią nie mają nic wspólnego.

No może tak bardziej.

> > Dla mnie raczej znamienne jest to, że Ty twierdzisz, że branża elektroniczna jest "technicznie najbliższa naszej".
> Tak to widzę. W sensie - tak to pamiętam z lekcji historii. Również w sensie, że te dziedziny nawzajem się karmią.

Dla mnie branża elektroniczna jest pod wieloma względami bliższa np. hydraulicznej. W tym sensie, że jest trochę analogii w działaniu (choć oczywiście wiele zjawisk, jak np. indukcja, nie ma bezpośrednich odpowiedników). Natomiast historycznie wydziały komputerowe powstawały chyba równolegle na przy wydziałach inżynierii elektrycznej i matematyki.

> > Sądzę też, że raczej nie zaszkodziłoby programistom zapoznanie się z teorią literatury (zwłaszcza jeżeli mają tworzyć dokumentację).
> No właśnie, ciekawą sprawę poruszyłeś. A dlaczego to programiści mają ją tworzyć? Dawno temu pisaniem dokumentacji zajmowali się zupełnie inni ludzie. Technical writing to poważna dyscyplina, nie powierzano tego byle komu. Zauważ, że dokumentacja w odróżnieniu od kodu jest wizytówką firmy (w wielu projektach zleceniodawca nawet nie jest zainteresowany kodem źródłowym poza celami archiwizacyjnymi, natomiast dokumentację dostaje uroczyście), więc ma wpływ na postrzeganie marki. Dlatego pisarz dokumentacji to była wyższa kasta, niż klepacz kodu. 

Może i tak. Z drugiej strony, dla mnie kod źródłowy również jest dokumentacją, i wiele "reguł dobrego pisania" obowiązuje również przy pracy z kodem.
(Tzn. oczywiście wiele kodu nie stosuje się do tych reguł).
Pod tym względem bardzo podobała mi się ta prezentacja twórcy frameworku Rails dla Ruby'ego, w której porusza związki programowania z siedemnastowieczną poezją francuską:
https://www.youtube.com/watch?v=9LfmrkyP81M

> Może problemem jest to, że obecnie za bardzo przeciążyliśmy pojęcie programisty? Kiedyś programista to był ktoś, kto pisał kod. A dzisiaj programiści zajmują się wszystkim, łącznie z psychologią i grafiką użytkową.

Z jednej strony sobie myślę, że może trochę tak. Z drugiej -- ja nadal piszę kod, i to głównie ten kod jest owocem mojej pracy (nawet jeżeli do napisania tego kodu muszę zdobyć wiedzę z wielu innych dziedzin).

> > W każdy razie pomiędzy programowaniem a projektem hardware'u jest przepaść. Współcześnie większość programistów nawet nie będzie miała szans powąchać hardware'u, na którym będzie chodził ich software.
> No właśnie. Może to też jest problem?

Może jest na wielu poziomach. Ale wydaje mi się, że przede wszystkim pokazuje, jak bardzo "wyabstrahowaną" aktywnością stało się programowanie.