Gruby perl

Pon, 29 Lip 2002, 22:21:19 CEST

[[ Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> ]]:
> On Sun, 28 Jul 2002, Radoslaw Zielinski wrote:
>> [[ Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> ]]:
>>> Może by zxrobić tu jakeigoś małego wrappera o takeij samej nazwie który 
>>> uzywałby mana ? :)
[...]
> Robić takie rzeczy watrto po to żeby nie powielać pewnych zasobów. 
> Wszystkie te kłopoty znikną kiedyś o ile zacniemy używać manów czy ogólnie 
> dokumentacji instalowanych w systemie w xml.
> Zapewne taka pzreglądarka do man dobzre żeby miała wtedy pewne funkcje 
> perldoca :)

Tak czy inaczej, pieśń przyszłości.

>> Kolejny powód (oprócz tych, które podaję poniżej i podałem w poprzednim
>> mailu): to zmniejszy prawdopodobieństwo, że dany user będzie w modułach
>> grzebał.  Że zagryzie do śniadanka AutoLoaderem, poprawi CGI.pm, do
>> obiadku porównanie Mail::{Mailer,Sender}, na deser Symbol.pm, a po
>> kolacji jakaś kobyła typu Mason.  Nie chciałbyś być współodpowiedzialny
>> za spadek poziomu edukacji społeczności OSS, nieprawdaż? :-P [1]
> Wybacz lale tu nie ma związku miedzy tymi zreczami wprost. Istnieje o tyle 
> ze są pewne zwyczaje i o ile sie zmieną i np. dokumentacja bedzie 
> separowana od źródeł modułu juz w źródłach to zapewne sporej ilści ludzi 

Ale to jest *założenie*, nie przyzwyczajenie, żeby dokumentację trzymać
razem z kodem!  O to przecież w POD chodzi: żeby kod był jednocześnie
komentowany i dokumentowany.

Nie jest to tylko wynalazek Perla; ZTCW mechanizmy tego typu mają także
-- z większych -- C++ i Java.

I to jest dobre.  Czyżby trzeba było Cię do tego przekonywać? [1]

[1] Jeśli tak, zrób może mały research na własną rękę zanim odpowiesz;
    ludzie już sporo o tym napisali i trochę szkoda, zebyśmy wałkowali
    to samo po raz kolejny.

> na pewien okres to zamiesza. Niemniej jeszcze raz: postać źódłowa nie musi 
> i nie powinna mieć większego związku z pstacia instalowaną w tym i to że w 
> postaci źródłowej dokumentacja i źródła sa w jednym pliku nie powinno w 
> żaden sposób wpływać na to jak to bedzie wyglądać w postaci zainstalowanej 
> w systemie .. poprostu.

Niemniej jeszcze raz: postać źródłowa nie musi, ale powinna być
identyczna z postacią instalowaną tam, gdzie to tylko jest możliwe,
a zwłaszcza -- jak w omawianym przypadku -- bardzo potrzebne.

Dokumentacja powinna pozostać w ,,źródłach''; zwłaszcza wtedy, gdy robi
również za komentarz. [2]

Przykro mi, ale tego rodzaju autorytarnych stwierdzeń nie uważam za
argumenty.  Zwłaszcza, że cały czas tłumaczę Ci coś dokładnie
przeciwnego.

[2] A'propos: zwykłe komentarze też chcesz usunąć?
    Logiczną konsekwencją byłyby także wcięcia, nieprawdaż?

>>> [..]
>>>> Dobrze osadzone POD-y zastępują komentarze.  Bez nich, mam przechlapane;
>>>> nawet nie chcę sobie wyobrażać, ile dłużej zajmowałoby znalezienie
>>>> odpowiedniego kawałka kodu.
>>> Gdyby kod modułu był spleciony z podem w jakis sposób to bym zrozumiał .. 
>>> ale to jest poprostu jedno z dugim sklejona :)
>> Czy uważasz, że w takim LWP::UserAgent jest to sklejone?
> Może być i splecione ..

Zlepione, splecione, wplecione, zmiksowane...  Nieważne, jakiego
pogardliwego przymiotnika użyjesz; nie zmieni to faktu, że Plain Old
Documentation jest całkiem praktycznym i pożytecznym sposobem na trzymanie
dokumentacji w kodzie i jednoczesnego tego kodu komentowanie.

> to nie powinno mieć wpływu na to jak to jest 
> instalowane. Jeżeli występuje gzieś błąd to zwykle ściaga się postać 
> źródłową i na tejże poprawia sie co trzeba. Pzrez takie powiazanai 
> powstają włąsnie takei róne nieelastycznosci jak niemożność potraktowanai 
> dokumentacji globalnie niezaleznie od tego czy to jest dokumentacj do 
> perla czy czegokolwiek innego. Wiem z czego to sie nierze niemniej twórcy 
> zasobów perlowych także IMHo powinni patrzeć dalej niż na dystans własnego 
> czubka nosa dostosowując (tylko nieco) własne metody pracy do pewnych 
> ogólnych schematów które na granicy większych klas zasobów ciągnę sie 
> docieraja i ujednolicaja niż atomizują.

>>>> Druga sprawa: zdarza mi się podsyłać autorom patche, a do tego
>>>> potrzebuję oryginalnych wersji modułów.
>>> I tu posługujesz się na wypadek takeij operacji źródłowym pakietem :)
>> Tomku, grzebiesz w modułach Perla na codzień?
> Wcale.

Mógłbyś w związku z tym zrewidować swoją wypowiedź, zacytowaną powyżej?

Szczególnie interesuje mnie ten kawałek o ściąganiu postaci źródłowej,
bo z mojego doświadczenia w grzebaniu w ściągniętym z CPANu kodzie --
a liczę je w latach -- wynika coś zupełnie przeciwnego.

1. Po co miałbym ściągać ,,źródła'', skoro mam je w systemie?

2. Dlaczego miałbym tracić czas na rozpakowanie pakietu źródłowego
i szukanie odpowiedniego .pm (mogą być w różnych miejscach; MakeMaker
jest dość elastyczny), skoro mam go w standardowej lokalizacji?

3. Dlaczego chcesz mnie, pomiędzy innymi deweloperami Perla, zmuszać
do posiadania połączenia z Internetem w trakcie pracy?  To w ramach
przygotowywania kampanii reklamowej PLD i hasła ,,znakomita integracja
z Siecią'' w stylu MS? :->

>> Nie ma takiej możliwości, żebym wiedział, jak wygląda taki LWP::UserAgent
>> od środka, gdybym musiał do tego ściągać libwww z CPANu.
> "Obecnie" dodaj do powyższego

Nie rozumiem.  ,,Obecnie nie ma'', ,,obecnie wiedział'', ,,obecnie
wygląda'', ,,gdybym obecnie''...?

> a sie zgodże z Tobą :)

Ależ Ty się w tym wypadku nie masz zgadzać lub nie; tak po prostu
jest -- _ja_ nie wiedziałbym (a wiem), gdybym nie miał pod ręką.

>> Po prostu jeśli widzę coś spapranego, albo dokumentacja jest
>> niewystarczająca, albo chcę lepiej rozumieć, co się dzieje czy
>> wyprofilować swój śmietnik przy pomocy Devel::DProf (czy zobaczyć, jak
>> efektywne jest to, co poeta miał na myśli i czy wogóle była tam jakaś
>> myśl), zaglądam do modułu.
> Załóżmy że prerl dla przyśpieszenie operacji zacznie dawać możliwść 
> generowanai bajtkodu i tenże będzie się instalowało i używałao. Nadal
> będziesz chciał używać w postaci źródłowej z połączona dokumentacja czy
> będzieśz już raczje operował własnie na źródłach generując 
> bajtkod i dokumentację w manach w np. xml ?

W trakcie kodowania?  Ze źródłami.  _Muszę_ czytać cudzy kod i pracować
z nim; powody:

* te biblioteki są dalekie od ideału,
* pisuję kod, który ściśle z nimi współpracuje, tzn. od strony bebechów.

> Zauważ że od stanu obecnego do tego co nakreśliłem jest ciut, ciut i że
> nawet gdyby tego bajtkodu w tym przykłązie nie uwzględniać to ow schemat
> pracy z zasobami perlowymi i tak wymaga relatywnie kosmetycznych raczje
> zmian niż rewolucyjnych .. i to tylko dlatego że konkretne ttechnologie w
> tym i konwersja poda do xml juz istnieją, i nic tylko zacząć myśleć o tym
> jak tu to wszyetko spadowywac zeby nie zastanawiać się nad tym jak się
> sięga po dokumentacje do perla :)

Ja sięgam prosto: man dla całych stron, bo jest szybki i formatuje mi
dokumentację na całą szerokość terminala, perldoc -f dla konkretnych
funkcji z perlfunc(1), bo nie muszę po perlfunc(1) szukać.  Inni wolą
tylko perldoca.

> Widzisz to ?

Niespecjalnie.  Ty snujesz wizje (technologie, iksemele,
na-cholerę-komu-potrzebne konwersje ;-), ja piszę o rzeczach prozaicznych,
jak łatwość dostępu do kodu, przekładająca się na krótszy czas ->
mniejsze koszty programowania.

> Jeszcze raz: zmiana podejścia nie jest do wdrożenia momentalnie. Wymaga
> pewneg pzrygotowania, a zapewne pewne częci tych zmian mozna wykonywać 
> etapami. Możemy sie zastanawiać co i jak dobzre byłoby zrobić dowolnei 
> długo :)

Jak na razie, to ja nie widzę propozycji ,,zmian'', tylko psucia, które
znacznie utrudni mi życie.

>> Chcę widzieć wersję niezmodyfikowaną: żeby móc szybko się w tym połapać,
>> połatać _bez potrzeby posiadania połączenia z siecią_, żeby na innej
>> maszynie nie mieć zonka w stylu ,,szlag, ostatnio to inaczej wyglądało''
>> (to przykłady, znalazłyby się też inne powody, których sobie po prostu
>> w tej chwili nie uświadamiam).  Ba, chcę, żeby inni też taką widzieli.
>> Bo wtedy jest większa szansa, że 1) znajdą błąd, i 2) poprawią go, a na
>> tym ja -- razem z resztą użytkowników danego softu -- skorzystam.
> Na wschodzi maja takie ładnie przysłowie (w transkrypcji polskiej) 
> "prywyćka wtarojom naturom cieławieka" .. mniaje juz osób zna dobzre język 
> Puszkina więc pzretłumaczę: "Przyzwyczajenie drugą naturą człowieka".
> To co pzreskadza Ci tutaj w spojzreniu na to nieco inaczej to tak 
> faktycznie jakbyś się uderzył w klatę to .. tylko przyzwyczajenie :)

No dobra.  Walnąłem się w klatę.  Później, w nocy, w trakcie grupowej
próby doprowadzenia się do stanu upojenia alkoholowego, przypomniałem
sobie Twe słowa i zrobiłem to po raz kolejny -- żeby rozpatrzeć sytuację
z innego punktu widzenia.  Rano, na lekkim kacu, spróbowałem znów.
Później wybrałem się na basen i ,,uderzałem się w klatę'' -- na przemian
raz mokrą, raz spieczoną -- aż zauważyłem, że ludzie na mnie trochę
dziwnie patrzą; wtedy przestałem.

Wynik: przez cały czas zmieniał się tylko odgłos, a ja nadal uważam,
że to nie jest kwestia przyzwyczajenia.  To styl pracy, który zamierzasz
uniemożliwić nie proponując niczego w zamian.

Nie jestem pewien, czy przekonałem Cię już do tego, że postać źródłowa
jest potrzebna, więc kolejny przykład: klasy, dziedziczące cudzy kod.

W ten sposób napisany jest np. Apache::DBI, nawiasem mówiąc -- całkiem
niezły kawałek softu: dziedziczy po DBI, nadpisując swoimi metodami;
dla programisty jest przezroczysty, wystarczy załadować go przed DBI.
To jest przykład dla tego, o czym pisałem wcześniej jako o ,,współpracy
od strony bebechów.

Autor Apache::DBI *musiał* czytać kod DBI.pm.  Nie chcesz, żeby taki
kod powstawał przy użyciu PLD?

>>> To tak jakbyś chciał poprawiać bład w programie dostarczając wynik cmp z 
>>> konkretnej binarki :)
>> Nie, bo moduły Perla to nie binarki (poza XS).
> Co nie znaczy że wprowadznie takiej jasnej separacji de facto .. wiele ytu 
> zmienia :)

Moja znajomość języka polskiego nie pozwoliła mi na zrozumienie tego
zdania, niestety...  Możesz ująć tę myśl inaczej?

> [..]
>> A co przekonało Cię do uznania tego za sensowne?  Jakie są zyski?
> O zysku już wspomniałem. 
> Pzrez dażenie do ujednolicania zasobów dokumenytacji masz wiele zysków:
[...]
> .. i wiele innych które bendą mutacjami czy też konsekwencjami powyższego.

Pytałem o zyski z *wyrżnięcia kawałków POD z modułów*.

Jeśli chodzi o to, co podałeś: jasne, miło by było mieć jedno narzędzie
do całej dokumentacji i wszystko konwertowalne do wszystkiego, np.
DocBook, ale...  Ten problem mnie zupełnie nie zajmuje.  :-p  Mnie
osobiście nie przeszkadza konieczność używania perldoc -f do funkcji
z perlfunc(1), a man 3 cośtam dla funkcji z C.  Ba, zważywszy na to,
że występuje kolizja nazw, i tak będzie trzeba jakoś rozróżniać.

Natomiast bardzo zajmuje mnie problem aktualności dokumentacji.  Uważam,
że dokumentacja opisująca dany kod powinna się znajdować w tym kodzie,
tzn. np. dokumentację do modułów Perla należy pisać w POD.

Co innego dokumentowanie czegoś, co przy pomocy kodu można zrobić; to
się tak często nie zmienia -- jakieś tutoriale, FAQ czy inne whatever.
Ale też nie widzę powodu, dla którego nie miałoby się pisać tego w POD.
:->  Jest to szybkie, łatwe i przyjemne, a ponadto można takie dokumenty
czytać bez żadnej konwersji; w przypadku DocBook nie jest to już tak
bezbolesne.

> [..]
>> Tak wogóle, to nudzi Wam się?  Tyle jest pożytecznych rzeczy do
>> zrobienia...
> Gdyby było inaczje to zapewne wogóle byśmy i to obydwoje nie dyskutowali
> teraz :)
> Tak nudzi nam się i dlatego przecież robimy dystrybucję :)

No, można się nudzić i nudzić... :-)

>> Na przykład, brakuje jeszcze speców do wielu modułów.
> O tym wiedzą Ci co tego potzrebuja używać .. ja przykłdowo nic o tym nie 
> wiem .. więcej za bardzo wiedzieć nawet nie chcę, a i nawet nie muszę :)

Hmm, ciekawe stwierdzenie w kontekście przystosunkowywania się do tych
.pm'ów i wygłaszania autorytarnych sądów... :-/

>> SpamAssassina przydałoby się gruntownie przeczyścić; dziś np.
>> stwierdziłem, że nie da się zdefiniować własnej ścieżki do regułek --
>> tylko jedna z predefiniowanych...
> Z buildloga o tegoż:

Zaraz poprawię.

Cóż, póki siedzę na modemie, takie wpadki mogą sie zdarzać.

[...]
> zasłaniała tradycyjnym podejściem do zasad pracy z zasobami perlowymi. O 

To komentowałem już wcześniej.  Nie jestem z tych twardogłowych i
nie chodzi mi tu o ,,tradycję''; jeśli zobaczę z czegoś korzyść, to
to przyjmę.

Jeśli nie będzie mi przeszkadzało.

Tu: korzyść dla mnie zerowa, dla niezainteresowanych także (kto poza
perlowcami będzie czytał perlową dokumentację :-> ), a smrodu dużo.

> ile uznasz że ta kwestia jest do pewnego stopnai drażliwa/warta 
> przemyślenai o niewątpliwie pomożesz mi podpowiadajac jak taką operacje 
> pzreprowadzić możliwie małym nakładem zmian które dla typowego "perlojada" 
> bendą do pzrełknięcia :)

> .. i o ten mniejwiecej rodzaj myślenia i współpracy apelowałbym w tym co
> próbujemy robić wspólnie :)

Nie przyłożę ręki do czegoś, co uważam za złe; w tym wypadku to nawet
nie jest ,,bad'', tylko ,,evil''.

Wręcz przeciwnie: będę publicznie krytykował, szukał i wykorzystywał
błędy, organizował grupy sabotażystów i pikieterów; powiadomię prasę,
radio, telewizję, organizacje kościelne i feministki (spokojnie, już
ja im jakoś wkręcę, że to ich sprawa).

> Nie koniecznie wszystko musi wygladać dokąłdnie jak próbuje opisuywać bo
> opisuję konkretne sirodki techniczne .. niemniej jeżeli zdasz sobei sprawę
> z tego że owe sirodki dla mnie na przykąłd nie sa aż tak ważne wobec
> pewnychc wyżej położonych celół to o ile jesteś w stanie myśleć także
> przedewszytkim o celu to być może zaoferujesz inny sidek tecchniczny,
> który o ile będzie lepiej spełniał pewne warunki musi być zaakceptowany
> także i przezemnie :)

Jak to wyżej napisałeś, ,,przełknięcie'', jest w przypadku kastracji
.pm'ów niewykonalne. [3]

Inne środki techniczne znasz -- konwertowanie .pod'ów jest proste.

[3] A wogóle, jak Ty sobie wyobrażasz kwestię dostarczenia ,,źródeł''
    developerom Perla?  No bo przecież trzeba je jakoś dostarczyć,
    (propozycja ,,/usr/bin/wget i rozpakuj w $HOME'' wzbudzi raczej
    średnie uznanie) nie?  Że są potrzebne, chyba Cię przekonałem?
    Uwzględniając jedną z zasad PLD, ,,jeśli coś jest Ci potrzebne,
    dodaj to''...  No to jak: każdy pakiet perl-* dostaje automatycznie
    kolegę source-perl-*? ;->

> Tak czy inaczej: spokój i rozwaga to dobrzy doradcy. Tam gdzie w rozmowe
> zaczynają sie wkradac emocje o dobre rozwiązanie jest już conajmniej
> trudniej :)

Mam problem z zachowaniem spokoju -- przy świadomości faktu, że nie
dysponuję zasobami na builder bez Waszego ,,POD-kastratora'' -- gdy Ten,
Który Ma Głos odpowiada na moje argumenty w dyskusji w stylu ,,stary,
walnij się w klatę''.  Ale racja, panika jest nie na miejscu, coś wymyślę.

-- 
Radosław Zieliński <radek w karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/2d56077d/attachment.bin