🚀 go-pugleaf

On 2011-10-16, Adam Osuchowski <someone@somewhere.com> wrote:
> Stachu 'Dozzie' K. wrote:
>> Proponuję zapoznać się z funkcją map{}, a nie prezentować takie
>> paskudztwo.
>
> Paskudztwo? Może i paskudztwo, jak cały Perl,

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.

> ale to ma działać, a nie ładnie
> wyglądać.

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.

>> Proponuję też zapoznać się bliżej z funkcją local, bo wstawiona tu jest
>> nadużyciem.
>
> Po pierwsze, skoro już jesteś takim purystą językowym i wytykasz innym nawet
> najmniejsze niejednoznaczności, to wiedz, że local w Perlu nie jest funkcją.
> Poczytaj o tym, co to są słowa kluczowe i operatory w językach programowania
> oraz czym różnią się od funkcji.

To poczytaj jak się wywołuje local i my. Traktuje się je jak funkcje,
mają argumenty i mogą coś zwracać. Nazwanie my() i local() funkcjami
nie jest błędem merytorycznym.

I może zapoznaj się -- tak dla porównania -- z takim językiem jak Tcl,
gdzie nie ma nawet instrukcji sterujących, a jedynie wywołania funkcji
operujących na stringach.

> Po drugie, nie, nie jest to nadużycie. Jeśli nie rozumiesz po co jest tu
> local to również odsyłam do dokumentacji.

Ja rozumiem. To ty tu prawdopodobnie nie rozumiesz. Do tego do czego
użyłeś local, tu należałoby użyć `my @array'.

>> No i warto wiedzieć, że ten eval{} może prowadzić do błędów trudnych do
>> wychwycenia, gdyby z jakiegoś powodu td(), push() albo cokolwiek innego
>> w tym bloku wywołało die().
>
> No to spróbuj zrobić bez evala lub funkcji jakiś generator bardziej
> skomplikowany niż proste przemapowanie. Chociażby taki, który by pozwalał
> na przerwanie sterowania w dowolnym momencie albo warunkowe wstawianie
> elementów. Życzę powodzenia.

Nie zrozumiałeś. Po prawdzie, nie dziwi mnie to, bo w Perlu pisać
najwyraźniej nie umiesz. Słyszałeś o takiej funkcji jak do{}? Nie? To
doczytaj. `perldoc -f do'

> To, że w tym przypadku map też by zadziałał
> nie oznacza, że eval nie zadziała, pomijając fakt, że ma większe możliwości.
> Poza tym daję osobie zgłaszającej problem rozwiązanie ogólne, a nie
> ograniczone, działające tylko dla konkretnych sytuacji.

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.

>> Ogólnie evala należy unikać, dopóki nie wie się dokładnie co się robi
>
> Ale ja wiem co robię i użyłem go świadomie.

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.

> Jeżeli masz problemy
> z opanowaniem takich konstrukcji i przerasta Cię obsługa błędów w evalu,
> to ponownie zaproponuję Ci Pythona.

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

> Dyskusje o szkodliwości evala śmieszą mnie tak samo jak te o szkodliwości
> goto. Akademiccy teoretycy, którzy z inżynierią mają niewiele wspólnego,
> a w życiu nie napisali większego kawałka kodu, który miałby praktyczne
> zastosowanie, wyciągają argumenty typu ,,nie wolno używać noża bo się można
> skaleczyć''.

Ś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ą.

-- 
Secunia non olet.
Stanislaw Klekot