R.e.m.e.K pisze:
> Dnia Sun, 17 Mar 2013 11:14:42 +0100, PawelS napisał(a):
>> To jest niestety problem ... wikipedii i wikipedystów,
>> przedstawiających takie, a nie inne przykłady
>> a na to nic nie poradzimy ...
>
> Zawsze mozesz wyedytowac wiki i poprawic, sam tak czasem robie :-)
Musiałbym mieć: więcej czasu, lepszy dostęp do Internetu,
być bardziej pracowitym, aby umieć znaleźć gdzie jest to wiki
i te specyficzne przykłady oraz wiedzieć jak to poprawić,
bo nie wiem czy anonimowo tak jak na pl/en.wikipedia.org można.
Nauczyłem się kiedyś podstaw perla korzystając
ze stron www.tutorialspoint.com perldoc.perl.org search.cpan.org,
staram się unikać i nie próbować nauczyć składni,
która dla mnie wydaje się być abstrakcyjna,
chyba że nie można czegoś inaczej napisać.

>> To powyżej powinno być zapisane:
>> my $var; # using strict w perlu trzeba deklarować jednak zmienne ;)
>> $var="Magiczna liczba to 150\n";
>> print($var);
>> # na to niestety nie ma akurat rady, chyba że własna sub:
>> # coś na kształt PHP:
>> # sub preg_replace {
>> # my ($pattern,$replacement,$subject)=@_;
>> # $subject=~s/$pattern/$replacement/g;
>> # return $subject;
>> # }
>> $var=~s/\d+/-1/; # lub $var=preg_replace('\d+', '-1', $var);
>> print($var);
>> Jak dla mnie tak jest czytelniej,
>> wystarczy przestać używać wynalazków i skrótów perla.
>
> Ale jak sam piszesz przestac nie tak latwo, bo "na to niestety nie ma rady".
To może wyrażę się precyzyjniej:
nie próbować nauczyć się i zrozumieć tej dziwnej składni,
o ile rzecz jasna nie jest to niezbędne:
na preg_replace nie ma wyjścia: $var=~s///g; musi być,
analogicznie jest z $count=$#LIST+1 lub if ($#LIST+1>0) {} # niepusta
Ja tak zrobiłem, nauczyłem się tego co jest dla mnie logiczne,
plus pewne niezbędniki: wspomniany preg_replace, czy $#LIST+1.
Niestety ma to swoje dobre i złe strony:
z jednej strony mój kod można rzecz jest w miarę czytelny,
dla osób znających składnie analogiczną do C,
z drugiej strony sam mogę mieć problemy ze zrozumieniem
skryptów w perlu korzystających z dziwnej składni:
np: to co poniżej przedstawiłeś: "$["
nie potrafię tego przeanalizować, co najwyżej mogę uruchomić
i po wyniku się domyślić co to robi ...

>>> Albo:
>>> $n = $#a - $[ + 1;
>>> print "ilosc elementow w wektorze: $n \n";
>>>
>>> Taki $#a czy $[ jako zywo przypomina mi idee Brainfucka, ktory jest fajny,
>>> bo dowcipny i pomyslowy, ale jest tylko zartem.
>
> btw powyzszy przyklad nie jest juz z wiki, tylko jakiegos studenckiego
> skryptu.
Jako że nie ma innego sposobu sprawdzenia
(ja przynajmniej nie znam) nauczyłem się tego skrótu "$#",
ale to kolejne: "$[" to nie mam pojęcia to co jest
i pewnie nigdy nie poznam do póki nie będę musiał
coś zrobić i nie będzie innego wyjścia.

>> Niestety z racji, że python narzuca na formatowanie,
>> to i nie bardzo mi się podoba.
>> Często stosuję tego typu pseduo kompresję kodu:
>> if (conditional) { $a=1; $B[2]=2; $C['key']=3; }
>> a gdzie indziej jeśli to potrzebne dekompresję:
>> if (conditional) {
>> $a=1; # bo jest to pierwsza zmienna w if ;)
>> $B[2]=2; # bo jest to druga zmienna w if, to klucz = 2 i wartość = 2
>> $C['key']=3; # bo musi być inaczej niż w poprzednich liniach
>> }
>
> Teraz ja z ciekawosci spytam. Po co stosujesz kompresje? Masz jakis cel w
> tym, zeby plik zrodla bym mniejszy? Osobiscie unikam takich praktyk jak
> ognia, bo po roku, gdy musze ten kod czytac to chetnie sam bym sie kopnal w
> dupe za taki styl. Znaczy juz nie musze, bo od lat tego nie robie.
Z bardzo prostej przyczyny, żeby proste instrukcje przypisania,
analogiczne do tych przedstawionych powyżej
nie przesłaniały rzeczywistego celu kodu.
Oczywiście w perlu lub PHP powyższe instrukcje
można skompresować/zapisać nieco dziwaczniej:
PERL: ($a, $B[2], $C['key'])=(1,2,3);
PHP: list($a, $B[2], $C['key'])=array(1,2,3);
Oczywiście sporadycznie się to zdarza, ale zdarza się,
że zapisuję kilka instrukcji w jednej linii,
aby te proste instrukcje nie przesłaniały
prawdziwego celu kodu.

> Czy to nie zalezy od ustawien kompilatora? Poza tym uzywajac dobrego edytora
> mozna o tym problemie zapomniec bez wzgledu na to czy uzywasz spacji, taba
> czy obu naraz. Mam na mysli edytor, ktory w locie podmieni taby na spacje
> lub spacja na taby - tak jak chcesz.
> Zatem jest to problem wagi lekkiej, w przeciwienstwie do perlowych kompresji
> zabetonowanych w jezyk na zawsze.
Jak sam napisałeś używając dobrego edytora.
Tylko napisz w jaki sposób zmusisz wszystkich
by używali "dobrego edytora" (cokolwiek to też znaczy).
Pozwolę sobie jeszcze raz siebie zacytować:
> Przeglądając kody źródłowe (like C) często widzę
> mieszany styl wcięć, kilka linii ładnie spacjami,
> kolejne linie ładnie tabulatorami,
> i jeśli ja mam inne ustawienia np: vim ts=4 sw=4
> to niestety kod rozjeżdża mi się na ekranie,
Nie pamiętam co to było, ale być może to mogło być:
glibc(src), QT(src), PHP(src), gd(src), KDE(src),
tam gdzieś widziałem mieszaną składnię,
co od razu dało się zauważyć bo mój edytor (kate/kwrite)
trochę inaczej wyświetla wcięcia spacją i tabulatorami,
w sensie te dwa znaki są rozróżnialne.
Tak więc, Ty możesz sobie używać dobry edytor,
ale niestety wiele osób używa np: vi/vim z różnymi ustawieniami,
a potem szukasz czegoś (np: definicji danej funkcjonalności)
w kodzie źródłowym i widzisz taką mieszaninę wcięć.

> A jednak sie jakos wykonuje chyba. Czyli moze python jest "madrzejszy" niz
> sie wydaje? :-)
A ja jednak pozwolę sobie jednak nie akceptować
wymuszania na mnie formatowania :P
Ze względu na konfigurowalność szerokości tabulacji
stosuję wszędzie wcięcia tabulatorem,
poza jednolinijkowacami uruchamianymi w bashu.