ś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.