🚀 go-pugleaf

On 2011-10-16, Adam Osuchowski <someone@somewhere.com> wrote:
> Stachu 'Dozzie' K. wrote:
>> Bredzisz. Perl nie jest paskudztwem, co najwyżej pozwala na pisanie
>> paskudztwa. I na ogół paskudztwo piszą kretyni uważający że umieją pisać
>> w Perlu.
>> Ma działać *oraz* ładnie wyglądać. Kod wyglądający jak psu z gardła
>> wyciągnięty to kod gówniany i za pisanie takiego powinno się wieszać za
>> jaja.
>
> Oo, widzę, że się skończyły merytoryczne argumenty i zaczęło się obrażanie.

Jeszcze nie. Nie nazwałem cię jeszcze kretynem (innymi sprawami są czy
się poczuwasz do tego określenia i co ja o tobie myślę).

Poza tym, czy twoim zdaniem dobry kod może wyglądać jak papka
z odchodów?

>> Ja rozumiem. To ty tu prawdopodobnie nie rozumiesz. Do tego do czego
>> użyłeś local, tu należałoby użyć `my @array'.
>
> Użyłem local bo ,,my @_'' jest nielegalne. Zrobienie ,,my @array'' byłoby
> identyczne w skutkach z ew. mikroskopijnym wpływem na wydajność (i to nawet
> nie wiem na czyją korzyść). Gdzie więc to nadużycie, specjalisto?

Nadużycie jest takie, że używasz zlokalizowanej zmiennej globalnej
w charakterze zmiennej lokalnej. Co nie służy do tego.

>> Nie zrozumiałeś. Po prawdzie, nie dziwi mnie to, bo w Perlu pisać
>> najwyraźniej nie umiesz.
>
> Ok, to Twoja opinia, masz prawo ją mieć, a mnie nie chce się Cię przekonywać,
> jak jest naprawdę, więc niech Ci będzie.
>
>> Słyszałeś o takiej funkcji jak do{}? Nie? To doczytaj. `perldoc -f do'
>
> Słyszałem. I uważam, że do jest mniej elastyczne od evala. Chociażby
> w kwestii przerywania sterowania, o czym pisałem.

No jasne. Lepiej jest wprowadzić konstrukcję, w której trzeba dbać
dodatkowo o obsługę błędów, co może prowadzić do trudnych do
zdiagnozowania błędów.

>> Rozwiązaniem jeszcze ogólniejszym jest napisać parser uniwersalnego
>> języka programowania, bo można sobie w nim (w tym nowym języku)
>> oprogramować wszystko.
>
> No i na tym właśnie polega umiejętność programowania, której widać Tobie
> brakuje: umieć zrobić rzeczy na takim stopniu skomplikowania i uniwersalności
> żeby było użyteczne ale żeby nie przesadzić.

No tobie brakuje właśnie umiejętności programowania. Przesadziłeś
z evalem i przesadziłeś z local.

>> Nie wiesz co robisz, skoro użyłeś go tam, gdzie do{} sprawi się równie
>> dobrze, a nie wprowadzi wad które podałem.
>
> To, że w Twoim mniemaniu to jest wada, nie oznacza, że tak jest naprawdę
> albo, że jest tak w każdym przypadku. Skąd wiesz, czy w tym miejscu
> akurat jest akceptowalne przerwanie całego programu tylko dlatego, że
> się nie wykonał jakiś generator? eval właśnie ładnie to ukryje.

Wtedy się dodaje komentarz że eval jest potrzebny. Z twojego przykładu
nie widać żeby był potrzebny, a wprowadza coś, co w przyszłości trudno
się będzie debuggować. W takim przypadku należało użyć do{}.

> Poza tym, jeżeli mój oryginalny kod jest paskudztwem, to zamiana local na my
> i eval na do nic w tej kwestii nie zmienia.

Oczywiście. W pierwszym rzędzie lepiej było utworzyć tymczasową tablicę,
wypełnić ją i dopiero wstawić ją w miejscu kodu. Byłoby czytelniej
i bardziej elegancko.

> Dyskusja o wyższości jednego nad
> drugim jest czysto akademicka, co tym bardziej skłania mnie do wniosku, że
> Twoje posty mają na celu trollowanie, a nie rzetelną dyskusję. Tym bardziej
> że moje rozwiązanie działa, więc nie jest to kwestia ewidentnego błędu
> rzeczowego,

To się nazywa błędy stylistyczne. Kod nie tylko ma działać. Ma jeszcze
nie wyglądać jak kupa gówna, bo później się to źle poprawia.

>> Ja umiem obsłużyć błędy z evala. Ale wcale nie znaczy to że mam ochotę
>> za każdym jednym pieprzonym razem te błędy obsługiwać tylko po to, żeby
>> złapanym die() rzucić dalej.
>
> To sobie użyj do. Można było to od razu napisać, zamiast mądrzyć się 
> na temat obiektów i nomenklatury albo rzucać tekstami o ,,paskudztwie''
> itp. nie mających pokrycia w faktach. Czemuś tego nie zrobił?

Bo ma pokrycie w faktach. A czemu ty nie wyciągnąłeś na swoją obronę
funkcji do{}?

> W tak prostym przykładzie jak był podany, eval praktycznie nie różni się
> niczym od do. Natomiast w ogólnym przypadku eval jest bardziej elastyczny.

I przez to trudniejszy w poprawnym i bezpiecznym użyciu.

>> To raczej ty nie widziałeś na oczy kodu dłuższego niż dwieście linii
>> i pisanego przez czas dłuższy niż dwa tygodnie.
>
> Tak, tak, masz absolutną rację.

Przepraszam, ale taki wniosek mi się nasuwa czytając twój przykład
i twoje argumenty.

> Nigdy nie widziałem takiego kodu, w Perlu
> piszę od wczoraj, a w ogóle to pierwszy kod napisałem przedwczoraj. Jasne...
> Niewiarygodne, z jaką łatwością przychodzi Ci rzucanie pustymi słowami na
> tematy o których nic nie wiesz.

To są wnioski z dyskusji. Nie znam żadnego doświadczonego programisty,
który by wolał bardziej kosztowną metodę wykonania zadania (eval{}
z koniecznością obsługi die()) tylko dlatego, że teoria mówi, że ta
trudniejsza metoda jest bardziej ogólna, mimo że zadanie wcale nie
wymaga ogólności.

>> Śmieszą mnie argumenty o zaletach i przewagach evala z ust osobnika,
>> który nie zna nawet funkcji do{} i nie potrafi przewidzieć, że
>> dokładanie obsługi błędów tam, gdzie błąd mógłby się spokojnie
>> propagować bez przeszkód, jest niepotrzebne i jest głupotą.
>
> A skąd wiesz czy znam czy nie? To, że mam inne zdanie na jego stosowanie
> od Ciebie nie oznacza, że nie znam tej konstrukcji jak również, że nie
> stosuję jej tam gdzie może być przydatna.

No jakoś nie chce mi się w to wierzyć. I nie przekonałeś mnie do swojej
znajomości Perla i do swojej umiejętności (czy w ogóle chęci) pisania
dobrego, eleganckiego kodu.

-- 
Secunia non olet.
Stanislaw Klekot