do czego uzywac perl-a? czy warto poznac ten jezyk
lrem@lrem.maxnet - 30-04-2006 00:14
W poście <op.s8rn0cuohxnuv2@negative-361apc>,
Twelve Hungry Mammoths nabazgrał:
> gdzie tu widzisz trollowanie? po prostu zastanawiam sie nad motywami
> dyskwalifikowania tego czy innego jezyka na podstawie urody skladni i
> wychodzi mi, ze sa nieracjonalne. moga Ci sie nie podobac wnioski, moga Ci
> sie nawet nie podobac pytania, ale gdzie tu trollowanie?
Przejście od przyzwyczajenia do klamr, poprzez używanie wcięć, do
umiejętności pisania eleganckiego kodu i uczenia się nowych języków.
Oraz ta błyszcząca obudowa... Ale przyczepiłem się pewnie przez zły
humor, do merytorycznej strony zarzutów nie mam.
>> Przechodząc do argumentów merytorcznych:
>> Chociaż składnie każdych dwóch języków się różnią, większość
>> nowoczesnych języków ma jakiś wspólny mianownik, do którego należą owe
>> klamry i nawiasy.
>
> skad wziales te wiekszosc? potrafisz przytoczyc jakies dane statystyczne?
> bo ja potrafilbym dlugo wymieniac jezyki, ktore ich nie stosuja (chociazby
> wszystkie dialekty Lispa, wszystkie funkcyjne, Prolog, wszystkie Pascalo-
> i Basicopochodne, rozne jezyki zabawkowe, Smalltalk, czesciowo Ruby).
No tak, bo skąd by w Lispie nawiasy ;)
Języków funkcyjnych i Prologa bym tu nie porównywał, bo one wyrażają co
innego, więc nic dziwnego że robią to w inny sposób. Smalltalka i Ruby
nie znam, więc się nie wypowiem, o zabawkach rozmawiać nie chcę, a Basic
IMHO ma raczej niezbyt dobrą składnię. W Pascalu klamry są, ale dla
niepoznaki ukryte pod słowami begin i end ;)
A chyba jednak się zgodzisz, że większość projektów powstaje w językach
C-podobnych? Poza nimi dość duży ruch widzę tylko w Pythonie. Ale może
po prostu nie dość szeroko patrzę.
>> Dzięki temu, w połączeniu z sensownymi nazwami
>> funkcji bibliotecznych oraz odpowiednim formatowaniem kodu, doświadczony
>> programista jest w stanie zrozumieć kod nawet w języku, którego jeszcze
>> nie zna.
>
> no bez jaj. a w pythonie doswiadczony programista nie potrafi?
Pewnie potrafi, ale pewnie nie ze względu na jego podobieństwo do innych
języków które zna.
> teraz to Ty trollujesz.
Rzeczywiście jakoś niefortunnie to wszystko napisałem. Przepraszam.
> a moze funkcje biblioteczne w pythonie maja bezsensowne nazwy?
> moze jakies przyklady? i co powiedziec o perlowych chomp, bless czy reset?
W Pythonie jak i w Perlu pojawiają się raz na jakiś czas słowa
specyficzne dla konkretnego języka. To całkiem naturalne i przypuszczam
(bez poważnych podstaw), że Perl pewnie ma ich więcej. Ale w żadnym
miejscu nie sugerowałem, że w tym właśnie tkwi mój problem z Pythonem.
> odpowiednie formatowanie pomijam, bo to smiech na sali w kontekscie
> pythona.
Czy taki śmiech? Wszak bez przerwy słyszę, że Python jest dobry, bo
wymusza odpowiednie formatowanie.
>> Twórcy Pythona radośnie sobie z wielu z tych elementów
>> zrezygonowali, tworząc zdecydowanie inną składnię.
>
> Ty wogole widziales jakis fragment kodu w pythonie?
Tak. Raz na jakiś czas próbuję jeszcze raz coś sobie poczytać, ale nie
jestem w stanie. Może kiedyś jak będę miał więcej czasu, to się
przymuszę.
>> Dla mnie właśnie
>> przez to kod w Pythonie jest _znacznie_ mniej zrozumiały niż kod
>> w C#** czy obj-c**, chociaż Pythona próbowałem poznawać*, a dwóch
>> pozostałych nie.
>
> chyba kpisz. powiedz zatem, co oznacza ten fragment w Objective-C:
>
> -(void)setMyValue:(id <ValueGivingProtocol>)anyObjectThatConforms;
>
> przeciez jest _znacznie_ bardziej zrozumialy niz python?
Jak dla mnie to jest deklaracja funkcji setMyValue zwracającej voida,
przyjmującej parametr anyObjectThatConforms pasujący do protokołu
(IIRC odpowiednik template z C++, ale tego już nie jestem pewien)
ValueGivingProtocol. Jak mnie zaczniesz bardziej szczegółowo pytać, to
szybko wykończysz moją wiedzę. Ale kiedyś coś jednak o tym języku
czytałem.
>> Odnosząc się do argumentu o uczeniu, wolę się nauczyć C# i obj-c niż
>> w tym samym czasie samego Pythona.
>
> smiem twierdzic, ze _skladni_ pythona mozna sie nauczyc w pol godziny, a
> skladni Objective-C (nawet znajac C, C++ i Smalltalka) - nie.
Pewnie masz rację. Ale to obj-c to był strzelony na szybko przykład.
W przypadku C# jestem już bardziej przekonany, że byłbym szybko w stanie
zacząć swobodnie pisać z manualem biblioteki standardowej w odwodzie.
> jezeli masz zamiar dalej polemizowac, to prosze, zapoznaj sie najpierw
> chocby z podstawami tematow, o ktorych dyskutujesz, bo troche wstyd sie
> tak osmieszac.
Mnie się wydawało, że coś tam kiedyś czytałem. Właściwie to raz-dwa razy
w roku biorę się za krótki kurs nowego języka i przy tej okazji czytam
opisy i artykuły na temat kilku do wyboru. Ale jeśli uważasz
przedstawianie wiedzy na tym poziomie za niewarte polemiki ośmieszanie
się, to mogę skończyć. Podstawową tezę jednak podtrzymam: _ja_ nie
jestem w stanie łatwo przejść do porządku dziennego nad nietypową
składnią Pythona.
--
Kobiety nie przebaczają mężczyźnie błędów, które same popełniły.
Henryk Sienkiewicz
lrem@lrem.maxnet - 30-04-2006 00:14
W poście <slrne55674.j47.dozzie@hans.zsh.bash.org.pl>,
Stachu 'Dozzie' K. nabazgrał:
>> ** - pierwsze dwa nie znane mi C-podobne języki, które przyszły mi na myśl.
>
> Jak rozumiem, doszedłeś w Objective-C do ichniejszego pomysłu (pożyczki
> ze SmallTalka) na obiektowość?
Czy doszedłem? Czytałem o tym, nie zgłębiałem dokładnie i nie próbowałem
w praktyce. Że się nie zdecydowałem uczyć tego języka, to pewnie coś mi
się nie spodobało, może właśnie to? Nie pamiętam szczerze mówiąc.
--
MS Linux is released under the provisions of the Gates Private License,
which means you can freely use this Software on a single machine without
warranty after having paid the purchase price and annual renewal fees.
Stachu 'Dozzie' K. - 30-04-2006 00:14
On 29.04.2006, lrem@lrem.maxnet <lrem@lrem.maxnet> wrote:
> W poście <slrne55674.j47.dozzie@hans.zsh.bash.org.pl>,
> Stachu 'Dozzie' K. nabazgrał:
>>> ** - pierwsze dwa nie znane mi C-podobne języki, które przyszły mi na myśl.
>>
>> Jak rozumiem, doszedłeś w Objective-C do ichniejszego pomysłu (pożyczki
>> ze SmallTalka) na obiektowość?
>
> Czy doszedłem? Czytałem o tym, nie zgłębiałem dokładnie i nie próbowałem
> w praktyce.
A, czyli tak naprawdę widziałeś tę działkę, która jest identyczna z C.
> Że się nie zdecydowałem uczyć tego języka, to pewnie coś mi
> się nie spodobało, może właśnie to? Nie pamiętam szczerze mówiąc.
--
Feel free to correct my English
Stanislaw Klekot
Twelve Hungry Mammoths - 30-04-2006 00:14
On Sat, 29 Apr 2006 19:03:10 +0200, <lrem@lrem.maxnet> wrote:
>
>> skad wziales te wiekszosc? potrafisz przytoczyc jakies dane
>> statystyczne?
>> bo ja potrafilbym dlugo wymieniac jezyki, ktore ich nie stosuja
>> (chociazby
>> wszystkie dialekty Lispa, wszystkie funkcyjne, Prolog, wszystkie
>> Pascalo-
>> i Basicopochodne, rozne jezyki zabawkowe, Smalltalk, czesciowo Ruby).
>
> No tak, bo skąd by w Lispie nawiasy ;)
skupilem sie na klamrach, poniewaz nawiasy okragle stosowane sa w pythonie
tradycyjnie az do bolu (:
> W Pascalu klamry są, ale dla
> niepoznaki ukryte pod słowami begin i end ;)
a w pythonie jako zwieksz-wciecie i zmniejsz-wciecie (-:
> A chyba jednak się zgodzisz, że większość projektów powstaje w językach
> C-podobnych? Poza nimi dość duży ruch widzę tylko w Pythonie. Ale może
> po prostu nie dość szeroko patrzę.
nie wiem, byc moze tak jest. ale to niekoniecznie oznacza, ze klamry sa
cacy, a wszystko inne jest be.
>>> Dzięki temu, w połączeniu z sensownymi nazwami
>>> funkcji bibliotecznych oraz odpowiednim formatowaniem kodu,
>>> doświadczony
>>> programista jest w stanie zrozumieć kod nawet w języku, którego jeszcze
>>> nie zna.
>>
>> no bez jaj. a w pythonie doswiadczony programista nie potrafi?
>
> Pewnie potrafi, ale pewnie nie ze względu na jego podobieństwo do innych
> języków które zna.
pewnie nie. IMHO ze wzgledu na maksymalnie naturalna i przejrzysta
skladnie (kiedys nawet bylo modne okreslenie "wykonywalny pseudokod").
> Podstawową tezę jednak podtrzymam: _ja_ nie
> jestem w stanie łatwo przejść do porządku dziennego nad nietypową
> składnią Pythona.
no i dobra. Twoje swiete prawo. natomiast _ja_ uwazam, ze argumenty na
poparcie tego "nie do przejscia" sa zwykle nieracjonalne.
pzdr
szeryf
Michal Jankowski - 01-05-2006 00:03
"Twelve Hungry Mammoths" <someone@microsoft.com> writes:
> pewnie nie. IMHO ze wzgledu na maksymalnie naturalna i przejrzysta
> skladnie (kiedys nawet bylo modne okreslenie "wykonywalny pseudokod").
Znaczy skladnia bez klamer jest "maksymalnie naturalna i przejrzysta"?
I kto tu uzywa argumentow o wyzszosci jednej skladni nad inna?
Idz sobie na .lang.advocacy, prosze.
MJ
Twelve Hungry Mammoths - 01-05-2006 00:03
On Sun, 30 Apr 2006 09:38:22 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>
>> pewnie nie. IMHO ze wzgledu na maksymalnie naturalna i przejrzysta
>> skladnie (kiedys nawet bylo modne okreslenie "wykonywalny pseudokod").
>
> Znaczy skladnia bez klamer jest "maksymalnie naturalna i przejrzysta"?
a wiesz co znaczy taki skrot "IMHO"?
> I kto tu uzywa argumentow o wyzszosci jednej skladni nad inna?
tu caly czas padaja takie argumenty. i to nie z mojej strony.
pzdr
szeryf
Michal Jankowski - 01-05-2006 00:03
"Twelve Hungry Mammoths" <someone@microsoft.com> writes:
> tu caly czas padaja takie argumenty. i to nie z mojej strony.
Jak nie, skoro tak? Odparowujesz identycznymi, tylko w druga strone.
MJ
Twelve Hungry Mammoths - 01-05-2006 00:03
On Sun, 30 Apr 2006 10:53:37 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>
>> tu caly czas padaja takie argumenty. i to nie z mojej strony.
>
> Jak nie, skoro tak? Odparowujesz identycznymi, tylko w druga strone.
czyli jak ktos wypisuje banialuki, jak to np. doswiadczony programista nie
jest w stanie zrozumiec kodu w pythonie (za to w perlu jest), to jest
wszystko ok, natomiast polemika z tym juz jest be?
pzdr
szeryf
lrem@lrem.maxnet - 01-05-2006 00:03
W poście <op.s8tdnbqrhxnuv2@negative-361apc>,
Twelve Hungry Mammoths nabazgrał:
> czyli jak ktos wypisuje banialuki, jak to np. doswiadczony programista nie
> jest w stanie zrozumiec kodu w pythonie (za to w perlu jest), to jest
> wszystko ok, natomiast polemika z tym juz jest be?
Rozumiem, że początkowo źle zinterpretowałeś tą wypowiedź, ale proszę
Cię - nie upieraj się przy tej błędnej interpretacji. Chodziło mi o to,
że doświadczony programista widząc kod w językach C-podobnych jeszcze
zanim go zacznie czytać, już w podświadomości widzi co jest czym.
U mnie akurat to widzenie jest zależne od klamr i nawiasów których
w Pythonie bardzo mi brakuje.
--
MS Linux is released under the provisions of the Gates Private License,
which means you can freely use this Software on a single machine without
warranty after having paid the purchase price and annual renewal fees.
Grzegorz Szyszlo - 03-05-2006 00:07
Stachu 'Dozzie' K. wrote:
> To znaczy tak?
> #v+
> if (warunek) {
> cokolwiek();
> cokolwiek2(); }
> #v-
> Jakbym to zobaczył u współpracownika, to bym go na miejscu zamordował.
a niby co w tym morderczego jest?
znik.
Grzegorz Szyszlo - 03-05-2006 00:07
Twelve Hungry Mammoths wrote:
>> Python zdecydowanie ma dużo plusów od strony technicznej. Jednak, choć
>> może jestem w mniejszości, jego składni za plus nie uważam. Zastąpienie
>> klamr wcięciami jest dla mnie nie do przejścia.
>
> z calym szacunkiem, ale dyskwalifikowanie jezyka (o ile "nie do
> przejscia" oznacza dyskwalifikacje) tylko na podstawie niestandardowej
> skladni uwazam za conajmniej niemadre. przeciez python nie narzuca
> jakiegos nienaturalnego czy przesadnie sztywnego stylu. wymaga tylko,
> zeby rozpoczynajac blok zwiekszyc wciecie, a konczac -- zmniejszyc.
a nieprawda ;)
python wymaga, aby w nowym bloku bylo wciecie inne, niz we wszystkich
blokach nadrzednych ;)) taki zapis wyglada kretynsko, ale jest kompilowalny.
jak ja bym chcial miec w pythonie komplet bibliotek z perla ;)
> niedobrze, bo w tym biznesie trzeba sie caly czas uczyc. nie podoba mu
> sie kod bez klamer? to znaczy, ze przy wyborze narzedzi stosuje
> nieracjonalne kryteria, kupujac serwer wybierze pewnie ten w
> najbardziej blyszczacej obudowie.
tak nawiasem, widzialem kiedys jak jakis gosciu na lamach gazety chyba
'Komputer' (dawno temu) usilowal za pomoca preprocesora w C,
upodobnic zapis pewnych elemtow w C do pascala.
a szczytem bylo zastapienie { } slowami BEGIN END ;)
i to by bylo na tyle zwolennikow kompletnie swobodnego pisania,
co i tak konczy sie potrzeba wprowadzenia stylu.
btw. a propo ukatrupienia mnie za chory styl. dla mnie w zasadzie
wsio ryba ktorym stylem wcinania pisze. a to co sobie ubzduralem,
znakomicie skraca mi dlugosc kodu w pionie, dzieki czemu
wiekszy kawal algorytmu widze na ekranie.
> PS. ponizszy przyklad powinien obalic pare mitow na temat "sztywnosci"
> skladni pythona:
>
> x=1;print x
> if x==1:print"x=1";x=2
> else:print"tego nie zobaczysz";print"i tego tez"
> while x>0:print x;x-=1
heh. istota 'stylu obroncow radia maryja' ;)
znik.
Grzegorz Szyszlo - 03-05-2006 00:07
Michal Jankowski wrote:
> "Twelve Hungry Mammoths" <someone@microsoft.com> writes:
>
>
>>z calym szacunkiem, ale dyskwalifikowanie jezyka (o ile "nie do
>>przejscia" oznacza dyskwalifikacje) tylko na podstawie
>>niestandardowej skladni uwazam za conajmniej niemadre. przeciez
>
>
> To czemu tu się wielokrotnie pojawiały teksty w stylu "zamiast perla
> lepiej się naucz pytona, bo ma lepszą składnię"?
ja tak pisalem, tyle ze nie chodzilo mi o samą lepszość pod względem
wcinania, bo to tylko jeden z elementow skladni. zreszta jak chcesz
dokladnie wiedziec cos o lepszosci skladni pyhona, spytaj samego
larrego, tworce perla ;)
ale przewazajace sa inne zalety implementacji pythona. nie samego
jezyka, ale implementacji. najwazniesza dla mnie jest natywny mechanizm
zrzucania p-kodu, a w samej skladni znacznie mniejsza ilosc
niekonsekwencji i mniej dubli skladniowych.
iteratory, yeld i inne takie to tez bardzo mocne punkty na rzecz pythona
;) co do perla, jego najmocniejszym punktem jest historia, oraz mnogosc
gotowcow na CPAN.
znik.
Stachu 'Dozzie' K. - 03-05-2006 00:08
On 02.05.2006, Grzegorz Szyszlo <znik@wbc.lublin.pl> wrote:
> Stachu 'Dozzie' K. wrote:
>
>> To znaczy tak?
>> #v+
>> if (warunek) {
>> cokolwiek();
>> cokolwiek2(); }
>> #v-
>> Jakbym to zobaczył u współpracownika, to bym go na miejscu zamordował.
>
> a niby co w tym morderczego jest?
Nawiasy zamykające poustawiane w miejscach, gdzie bym się ich najmniej
spodziewał. Widziałem za dużo kodu niesformatowanego, sformatowanego źle
albo głupio (na przykład wymieszane spacje i tabulacje), żeby jeszcze
chcieć uważać na zamykający nawias klamrowy.
--
Feel free to correct my English
Stanislaw Klekot
Grzegorz Szyszlo - 03-05-2006 00:08
Twelve Hungry Mammoths wrote:
>> Zrzędzenie okolicznościowe:
>> Odniosłem wrażenie, że ten akapit jest na poziomie trolla w piaskownicy.
>> Wiem, że to niegrzecznie z mojej strony, ale po prostu chcę zwrócić
>> uwagę komuś, kogo szanuję za wiedzę, że się zapędził.
>
> gdzie tu widzisz trollowanie? po prostu zastanawiam sie nad motywami
> dyskwalifikowania tego czy innego jezyka na podstawie urody skladni i
> wychodzi mi, ze sa nieracjonalne. moga Ci sie nie podobac wnioski, moga
> Ci sie nawet nie podobac pytania, ale gdzie tu trollowanie?
Nie bron skladni pythona ;) perlowcy i tak maja racje. nawet w tym,
ze twierdza ze nie sa skostniali, chociaz sa. przypomne do bolu.
pytalem pare lat temu o serwer aplikacyjny w perlu, a zaproponowano
mi fast-cgi i/lub cgi-fast (food) ;) niezdrowe, tyczasowe itp.
serwery aplikacyjne w perlu dopiero raczkują, a największą ich
bolączką jest brak natywnego wsparcia ze strony perla do zrzucania
p-kodu.
efekt jest taki, ze kobylaste skrypty powoli sie odpalaja, i
niepotrzebnie pozeraja zasoby. po co p-kompilować skrypt
przy kazdym odpaleniu skoro mozna w zasadzie tylko raz?
i tu python wygrywa.
heh. ciekaw jestem czemu nikt nie zaczepil problematyki skladni
obydwu jezykow przy programowaniu obiektowym :>
>> Przechodząc do argumentów merytorcznych:
>> Chociaż składnie każdych dwóch języków się różnią, większość
>> nowoczesnych języków ma jakiś wspólny mianownik, do którego należą owe
>> klamry i nawiasy.
>
> skad wziales te wiekszosc? potrafisz przytoczyc jakies dane
> statystyczne? bo ja potrafilbym dlugo wymieniac jezyki, ktore ich nie
> stosuja (chociazby wszystkie dialekty Lispa, wszystkie funkcyjne,
> Prolog, wszystkie Pascalo- i Basicopochodne, rozne jezyki zabawkowe,
> Smalltalk, czesciowo Ruby).
uech. jemu chodzi o to ze najpierw byl prototyp czyli jezyk A, potem
cos powstalo cos w stylu B, obydwa zapomniane, a potem powstal C
w ktorym napisano calego Unixa. a co bylo potem? skladnia C zaczela
byc poprawiana i poprawiana, jakies C++, jakies objective C itp/itd,
potem rozne odejscia jak perl ktory polaczyl w sobie cechy kilku
jezykow np. C, po drodze wyszla tez Java jako poprawiony i uskryptowiony
C++, potem jakis kretynski proces sądowy i jego rezultat czyli C# :)
wiele innych jezykow tez bazuje na klamrologii C/C++.
a mnie w C/C++ najbardziej wkurza to, ze projektując złożony typ
danych, patrzy się na nazewnik i potem jest mordęga z wiązaniami,
rzuca się wzrokiem raz na prawo raz na lewo od nazewnika lub
nazwy zmiennej. chore. na szczęście perl przejął z tego bałaganu niewiele ;)
>> Twórcy Pythona radośnie sobie z wielu z tych elementów
>> zrezygonowali, tworząc zdecydowanie inną składnię.
>
> Ty wogole widziales jakis fragment kodu w pythonie?
moglby przeczytac chocby toturiala ;)
http://www.python.org.pl/tut/tut.html
to nie jest ciężka lektura. ale skostniali perlowcy o tym nie wiedzą.
piszę o skostniałych perlowcach, a nie normalnych perlowcach ;)
btw. golfiarzy zaczepiał nie będę, bo aż strach ;)
prawdziwy hadcore to maszynowka. nawet nie asm ;))
znik.
Grzegorz Szyszlo - 03-05-2006 00:08
lrem@lrem.maxnet wrote:
>>no bez jaj. a w pythonie doswiadczony programista nie potrafi?
>
> Pewnie potrafi, ale pewnie nie ze względu na jego podobieństwo do innych
> języków które zna.
wirth się kłania. składnia pascala (zblizona do algola) jest
diametralnie inna niz c/c++ . i co? to znaczy ze nie daje sie
w tym pisac? daje sie ;) przynajmniej zlozone typy czyta
sie z lewa na prawo bez problemu.
>>odpowiednie formatowanie pomijam, bo to smiech na sali w kontekscie
>>pythona.
>
> Czy taki śmiech? Wszak bez przerwy słyszę, że Python jest dobry, bo
> wymusza odpowiednie formatowanie.
o ja przepraszam. podalem kilka innych istotnych argumentow.
o ironio, wcale nie wypowiadam sie o perlu ze jest jezykiem
beznadziejnym, twoj przedpisca tez tak sie nie zachowuje.
ale ty traktujesz cokolwiek odbiegajacego od skladni jezykow
c podobnych i od perla za cos od czego mozna zostac wariatem, a
propagatorow takich rozwiazan jako wrogow ludu ;) wszak byl 1 maj ;))))
znik.
Grzegorz Szyszlo - 03-05-2006 00:08
Michal Jankowski wrote:
> "Twelve Hungry Mammoths" <someone@microsoft.com> writes:
>
>
>>pewnie nie. IMHO ze wzgledu na maksymalnie naturalna i przejrzysta
>>skladnie (kiedys nawet bylo modne okreslenie "wykonywalny pseudokod").
>
>
> Znaczy skladnia bez klamer jest "maksymalnie naturalna i przejrzysta"?
> I kto tu uzywa argumentow o wyzszosci jednej skladni nad inna?
w nieprogramistycznych zapisach, np. w spisie tresci, grupy
podrozdzialow nie wpychasz w sztuczne klamry, tylko ...... wcinasz i z
glowy. to samo inne punkty i podpunkty. i tworcy pythona zauwazyli te
wygode.
> Idz sobie na .lang.advocacy, prosze.
anglojezyczna, a my po polskiemu ;)
znik.
lrem@lrem.maxnet - 03-05-2006 00:08
W poście <e3809e$1ic$1@news.lublin.pl>,
Grzegorz Szyszlo nabazgrał:
> o ja przepraszam. podalem kilka innych istotnych argumentow.
> o ironio, wcale nie wypowiadam sie o perlu ze jest jezykiem
> beznadziejnym, twoj przedpisca tez tak sie nie zachowuje.
> ale ty traktujesz cokolwiek odbiegajacego od skladni jezykow
> c podobnych i od perla za cos od czego mozna zostac wariatem, a
> propagatorow takich rozwiazan jako wrogow ludu ;) wszak byl 1 maj ;))))
Nie... Ja tylko stwierdziłem, że przeskok między składniami jest
_dla mnie_ za duży. Od tego się cała ta dyskusja zaczęła.
--
Dla mnie political corretness oznacza mniej więcej tyle: "powiedz cokolwiek
złego na kobiety/mężczyzn/żydów/chrześcijan/cyklistów/masonów/indian/
murzynów/chińczyków a my zabierzemy wszystkie twoje pieniądze". Z tzw.
szacunkiem do człowieka nie ma to nic wspólnego :> - Artur R. Czechowski
Michal Jankowski - 03-05-2006 00:08
Grzegorz Szyszlo <znik@wbc.lublin.pl> writes:
> efekt jest taki, ze kobylaste skrypty powoli sie odpalaja, i
> niepotrzebnie pozeraja zasoby. po co p-kompilować skrypt
> przy kazdym odpaleniu skoro mozna w zasadzie tylko raz?
Po co kompilować na zapas, skoro odpala się tylko raz? 8-)
MJ
Grzegorz Szyszlo - 05-05-2006 00:06
Stachu 'Dozzie' K. wrote:
> On 02.05.2006, Grzegorz Szyszlo <znik@wbc.lublin.pl> wrote:
>
>>Stachu 'Dozzie' K. wrote:
>>
>>
>>>To znaczy tak?
>>>#v+
>>>if (warunek) {
>>> cokolwiek();
>>> cokolwiek2(); }
>>>#v-
>>>Jakbym to zobaczył u współpracownika, to bym go na miejscu zamordował.
>>
>>a niby co w tym morderczego jest?
>
>
> Nawiasy zamykające poustawiane w miejscach, gdzie bym się ich najmniej
> spodziewał. Widziałem za dużo kodu niesformatowanego, sformatowanego źle
> albo głupio (na przykład wymieszane spacje i tabulacje), żeby jeszcze
> chcieć uważać na zamykający nawias klamrowy.
no coz. w perlu stosuje 'styl pythonowy' ;)
ale jak tu niejednokrotnie bylo wspominane, zawsze zrodla mozna
przeformatowac. nazwy skryptow byly podawane.
znik.
Grzegorz Szyszlo - 05-05-2006 00:06
Michal Jankowski wrote:
> Grzegorz Szyszlo <znik@wbc.lublin.pl> writes:
>
>
>>efekt jest taki, ze kobylaste skrypty powoli sie odpalaja, i
>>niepotrzebnie pozeraja zasoby. po co p-kompilować skrypt
>>przy kazdym odpaleniu skoro mozna w zasadzie tylko raz?
>
>
> Po co kompilować na zapas, skoro odpala się tylko raz? 8-)
>
> MJ
tylko raz to sie odpala zabawki albo programy na zaliczenie ;)
jak powaznie myslimy o programowaniu w perlu, to zrzucanie
p-kompilatu staje się potrzebne.
znik.
Michal Jankowski - 05-05-2006 00:07
Grzegorz Szyszlo <znik@wbc.lublin.pl> writes:
> jak powaznie myslimy o programowaniu w perlu, to zrzucanie
> p-kompilatu staje się potrzebne.
Mnie nie.
Powaznie pytam - po co?
MJ
Szymon =?iso-8859-2?Q?Sok=F3=B3?= - 05-05-2006 00:07
On Thu, 04 May 2006 20:25:57 +0200, Michal Jankowski wrote:
> Grzegorz Szyszlo <znik@wbc.lublin.pl> writes:
>
>> jak powaznie myslimy o programowaniu w perlu, to zrzucanie
>> p-kompilatu staje się potrzebne.
>
> Mnie nie.
>
> Powaznie pytam - po co?
Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
to znaczy, że powinien był pisać w np. C i generować natywny kod maszynowy,
albo po prostu popełnił błąd projektowy (np. woła program co minutę z crona,
zamiast puścić go jako wolnostojącego demona aktywującego się co minutę).
Albo jedno i drugie.
Za to niewygoda związana z generowaniem kodu wynikowego (czy to będzie kod
maszynowy, czy p-code) jest czasem dość istotna. Zwłaszcza, jak trzeba coś
przerobić w programie napisanym 10 lat temu: gdzie ja mam źródło tego
programu? czy to na pewno właściwa wersja źródła? czy się skompiluje pod o 5
lat nowszym kompilatorem, być może na zupełnie innej platformie? W przypadku
języka interpretowanego problemu nie ma - kod źródłowy jest zarazem kodem
wykonywalnym, więc nigdzie się nie zawieruszy.
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Twelve Hungry Mammoths - 05-05-2006 00:07
On Thu, 04 May 2006 21:25:36 +0200, Szymon Sokół
<szymon@bastard.operator.from.hell.pl> wrote:
>>
>>> jak powaznie myslimy o programowaniu w perlu, to zrzucanie
>>> p-kompilatu staje się potrzebne.
>>
>> Mnie nie.
>>
>> Powaznie pytam - po co?
>
> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
> to znaczy, że powinien był pisać w np. C i generować natywny kod
> maszynowy,
czyli aplikacje webowe sugerujesz pisac w C?
> albo po prostu popełnił błąd projektowy (np. woła program co minutę z
> crona,
> zamiast puścić go jako wolnostojącego demona aktywującego się co minutę).
> Albo jedno i drugie.
albo zadne z powyzszych.
pzdr
szeryf
lrem@lrem.maxnet - 05-05-2006 00:07
W poście <ypoe8swnqrnw$.dlg@falcon.sloth.hell.pl>,
Szymon Sokół nabazgrał:
> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
> to znaczy, że powinien był pisać w np. C i generować natywny kod maszynowy,
> albo po prostu popełnił błąd projektowy (np. woła program co minutę z crona,
> zamiast puścić go jako wolnostojącego demona aktywującego się co minutę).
> Albo jedno i drugie.
Podam przykład z mojej własnej twórczośći, nie twierdzę że jest to
idealnie zaprojektowane czy wykonane, ale moim zdaniem jest tu dość dobrym
przykładem:
Na dość zajętym serwerze rezyduje sobie dość duża aplikacja, dobre pare
tysięcy linijek kodu rozbite na kilkanaście modułów i importujące
conajmniej drugie tyle. Z jednej strony klient wymaga szybkości
działania tego cuda, więc CGI odpada - kompilacja tego wszystkiego trwa
zdecydowanie za długo. Z drugiej strony używane to jest kilkanaście razy
w miesiącu a ram by się przydał na co innego. Jednak cóż robić, trzymam
to sobie w mod_perlu. Przypuszczam jednak, że gdyby to mogło być
przechowywane na serwerze jako kod maszynowy, albo chociaż p-kod, to
wiązałoby to się z dość znacznymi oszczędnościami.
--
2 * linux/kernel/panic.c
143 /* Satisfy __attribute__((noreturn)) */
144 for ( ; ; )
145 ;
Michal Jankowski - 05-05-2006 00:07
"Twelve Hungry Mammoths" <someone@microsoft.com> writes:
>> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>> to znaczy, że powinien był pisać w np. C i generować natywny kod
>> maszynowy,
>
> czyli aplikacje webowe sugerujesz pisac w C?
W jakich aplikacjach webowych czas przeparsowania programu robi
różnicę?
MJ
Twelve Hungry Mammoths - 05-05-2006 00:07
On Thu, 04 May 2006 22:32:30 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>
>>> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>>> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>>> to znaczy, że powinien był pisać w np. C i generować natywny kod
>>> maszynowy,
>>
>> czyli aplikacje webowe sugerujesz pisac w C?
>
> W jakich aplikacjach webowych czas przeparsowania programu robi
> różnicę?
w takich, ktore maja duzo requestow na sekunde.
pzdr
szeryf
Dariusz Sznajder - 05-05-2006 00:07
Dnia 04.05.2006 Twelve Hungry Mammoths <someone@microsoft.com> napisał/a:
> On Thu, 04 May 2006 22:32:30 +0200, Michal Jankowski <michalj@fuw.edu.pl>
> wrote:
>>>> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>>>> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>>>> to znaczy, że powinien był pisać w np. C i generować natywny kod
>>>> maszynowy,
>>> czyli aplikacje webowe sugerujesz pisac w C?
>> W jakich aplikacjach webowych czas przeparsowania programu robi
>> różnicę?
>
> w takich, ktore maja duzo requestow na sekunde.
Nie bardzo.
Bo jak robi, to patrz punkt drugi.
--
Dariusz Sznajder
DSZ1-RIPE
Michal Jankowski - 05-05-2006 00:07
"Twelve Hungry Mammoths" <someone@microsoft.com> writes:
> w takich, ktore maja duzo requestow na sekunde.
I są napisane na zasadzie "każdy request to odpalenie programu do
obsłuzenia go"?
MJ
Szymon =?iso-8859-2?Q?Sok=F3=B3?= - 05-05-2006 00:07
On Thu, 04 May 2006 22:42:48 +0200, Twelve Hungry Mammoths wrote:
> On Thu, 04 May 2006 22:32:30 +0200, Michal Jankowski <michalj@fuw.edu.pl>
> wrote:
>> W jakich aplikacjach webowych czas przeparsowania programu robi
>> różnicę?
>
> w takich, ktore maja duzo requestow na sekunde.
To właśnie przypadek 2 :->
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Grzegorz Szyszlo - 06-05-2006 00:08
Szymon Sokół wrote:
> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
> to znaczy, że powinien był pisać w np. C i generować natywny kod maszynowy,
> albo po prostu popełnił błąd projektowy (np. woła program co minutę z crona,
> zamiast puścić go jako wolnostojącego demona aktywującego się co minutę).
> Albo jedno i drugie.
to teraz wejdz na www.python.org.pl i poczytaj podrecznik
'dla poczatkujacych', zwlaszcza rozdzial o zarzadzaniu p-kodem.
to sie dzieje automatycznie. sam mozesz olac zrzuty p-kodu,
bo caly czas z poziomu programisty operujesz na zrodlach,
no chyba ze zrodla celowo usuniesz, ale wtedy sam sprowadzasz sobie klopoty.
po przeczytaniu wypowiedz sie ponownie na temat p-kodu.
python zarzadza p-kodem inaczej niz java. ja bym bardzo chcial,
aby perl zarzadzal p-kodem podobnie jak python.
co do wymienionych przez ciebie bledow projektowych, brak zrzutu p-kodu
w perlu powoduje, ze serwer aplikacyjny czy musi czy nie musi, to
utrzymuje raz wczytany applet, a czas jego usuniecia jest dosyc dlugi,
niepotrzebnie pozerajac zasoby. gdyby byl p-kod, to uzyty applet moglby
byc usuwany z pamieci natychmiast, bo bardzo szybko mozna by go
zaladowac ponownie.
brak zrzutu p-kodu powaznie ogranicza perla.
> Za to niewygoda związana z generowaniem kodu wynikowego (czy to będzie kod
> maszynowy, czy p-code) jest czasem dość istotna.
uruchamiasz plik, a p-kod zrzuca sie tuz obok automatycznie, oczywiscie
jesli sa prawa zapisu. przy ponownym odpaleniu sa porownywane daty, i w
razie czego p-kod jest nadpisywany. to taka bardzo istotna trudnosc w
zarzadzaniu? a pisze akurat o p-kodzie, bo perl nie kompiluje odpalanych
skryptow do maszynowki, tylko do p-kodu wlasnie.
> Zwłaszcza, jak trzeba coś
> przerobić w programie napisanym 10 lat temu: gdzie ja mam źródło tego
> programu?
jak zwykle obowiazkowo tuz obok pliku z p-kodem ;)
> czy to na pewno właściwa wersja źródła?
na 100%, bo gdyby byla inna, to p-kod dawno by sie zsynchronizowal.
> czy się skompiluje pod o 5
> lat nowszym kompilatorem,
skoro dalo sie uruchomic, to znaczy ze dalo sie tez skompilowac. gdyby
sie nie dalo, to po wymianie kompilatora czy tez interpretara jezyka
nie odpalilbys wogole programu.
> być może na zupełnie innej platformie?
p-kod w pythonie w przeciwienstwie do javowego jest przenosny pomiedzy
platformami, big/little endian nie jest dla niego problemem.
> W przypadku
> języka interpretowanego problemu nie ma - kod źródłowy jest zarazem kodem
> wykonywalnym, więc nigdzie się nie zawieruszy.
w pythonie w porownaniu do perla jest jedynie taka roznica, ze to co sie
skompiluje do p-kodu w pamieci, jest od razu zrzucane do pliku, aby przy
ponownym odpaleniu wogole nie zajmowac sie plikiem zrodlowym, jesli daty
sie zgadzaja.
jak ja bym chcial miec takie mozliwosci w perlu.
znik.
Grzegorz Szyszlo - 06-05-2006 00:08
Michal Jankowski wrote:
> "Twelve Hungry Mammoths" <someone@microsoft.com> writes:
>
>
>>>Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>>>efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>>>to znaczy, że powinien był pisać w np. C i generować natywny kod
>>>maszynowy,
>>
>>czyli aplikacje webowe sugerujesz pisac w C?
>
>
> W jakich aplikacjach webowych czas przeparsowania programu robi
> różnicę?
w kazdych gdzie strona jest generowana z posrednictwem serwera
aplikacyjnego, gdzie ta strona tak naprawde jest wielokrotnie
dziedziczonym obiektem, ktory zawiera wielokrotnie dziedziczone obiekty
skladowe.
poczytaj o perlowym catalyst framework, to szybko zajarzysz w czym problem.
znik.
Grzegorz Szyszlo - 06-05-2006 00:08
Michal Jankowski wrote:
> "Twelve Hungry Mammoths" <someone@microsoft.com> writes:
>
>
>>w takich, ktore maja duzo requestow na sekunde.
>
>
> I są napisane na zasadzie "każdy request to odpalenie programu do
> obsłuzenia go"?
heh. zaraz sie znowu zacznie. po co wam serwery aplikacyjne?
przeciez macie fast-cgi / cgi-fast ;)
a to jest tylko polsrodek, bo jak powstawalo to rozwiazanie,
nikt nie mial lepszych pomyslow.
znik.
Grzegorz Szyszlo - 06-05-2006 00:08
lrem@lrem.maxnet wrote:
> W poście <ypoe8swnqrnw$.dlg@falcon.sloth.hell.pl>,
> Szymon Sokół nabazgrał:
>
>>Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>>efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>>to znaczy, że powinien był pisać w np. C i generować natywny kod maszynowy,
>>albo po prostu popełnił błąd projektowy (np. woła program co minutę z crona,
>>zamiast puścić go jako wolnostojącego demona aktywującego się co minutę).
>>Albo jedno i drugie.
>
>
> Podam przykład z mojej własnej twórczośći, nie twierdzę że jest to
> idealnie zaprojektowane czy wykonane, ale moim zdaniem jest tu dość dobrym
> przykładem:
>
> Na dość zajętym serwerze rezyduje sobie dość duża aplikacja, dobre pare
> tysięcy linijek kodu rozbite na kilkanaście modułów i importujące
> conajmniej drugie tyle. Z jednej strony klient wymaga szybkości
> działania tego cuda, więc CGI odpada - kompilacja tego wszystkiego trwa
> zdecydowanie za długo. Z drugiej strony używane to jest kilkanaście razy
> w miesiącu a ram by się przydał na co innego. Jednak cóż robić, trzymam
> to sobie w mod_perlu. Przypuszczam jednak, że gdyby to mogło być
> przechowywane na serwerze jako kod maszynowy, albo chociaż p-kod, to
> wiązałoby to się z dość znacznymi oszczędnościami.
swietny przyklad ;)
ja cos takiego zalatwiam trzymajac w tablicy zestaw funkcji,
ktore zostaly 'wczytane/zinterpretowane' przez eval, czyli
w tablicy trzymam odwolania. jak z powodu przeterminowania czasowego
uznam ze kod nie jest uzywany, to kasuje tablice. przy najblizszym
odwolaniu spowrotem ja napycham, wiec pierwsze wywolanie trwa troche
dluzej. rozwiazanie z pozoru glupawe (tak wiem wiem, jeszcze clib i
przydzial blokow pamieci ktore nie sa od razu zwalniane), jednak poki co
skuteczne. jest to bezposrednia konsekwencja braku mozliwosci zrzucu
p-kodu w perlu.
jeszcze nie wzialem sie za lekture framework catalyst, ale sadze ze jest
tam zrobione podobnie.
znik.
Dariusz Sznajder - 06-05-2006 00:08
Dnia 05.05.2006 Grzegorz Szyszlo <znik@wbc.lublin.pl> napisał/a:
>> Zwłaszcza, jak trzeba coś
>> przerobić w programie napisanym 10 lat temu: gdzie ja mam źródło tego
>> programu?
> jak zwykle obowiazkowo tuz obok pliku z p-kodem ;)
Obowiązkowo?
Sugerujesz, że jak nie ma źródeł obok to się nie da zaimportować i nie
będzie działać przez 10 lat? :)
--
Dariusz Sznajder
DSZ1-RIPE
moldovenu - 06-05-2006 00:08
> W jakich aplikacjach webowych czas przeparsowania programu robi
> różnicę?
Niezłe pytanie ;)
Chłopaki z Yahoo, Amazona i setek innych popularnych serwisow moga ci
wyliczyc w $$, jaka to jest roznica, zwlaszcza pod koniec listopada ;)
Pisanie demona zamiast serwera aplikacyjnego... hmmm... tylko dlaczego
"nieco czesciej" sie spotyka serwery aplikacyjne? ;)
sorry za lekka ironie, ale mialem niezly ROTFL po przeczytaniu
niektorych wypowiedzi grupowych teoretykow aplikacji webowych ;)
no offence, keep cool & stay with us :)
--
adam
Michal Jankowski - 06-05-2006 00:08
Grzegorz Szyszlo <znik@wbc.lublin.pl> writes:
> co do wymienionych przez ciebie bledow projektowych, brak zrzutu
> p-kodu w perlu powoduje, ze serwer aplikacyjny czy musi czy nie musi,
> to utrzymuje raz wczytany applet, a czas jego usuniecia jest dosyc
> dlugi, niepotrzebnie pozerajac zasoby. gdyby byl p-kod, to uzyty
> applet moglby byc usuwany z pamieci natychmiast, bo bardzo szybko
> mozna by go zaladowac ponownie.
I naprawde tych apletow jest tyle roznych (a pamieci tak malo), ze
oplaca sie je usuwac z pamieci na chwile?
MJ
Dariusz Jackowski - 06-05-2006 00:08
Grzegorz Szyszlo wrote:
>
>> I są napisane na zasadzie "każdy request to odpalenie programu do
>> obsłuzenia go"?
>
> heh. zaraz sie znowu zacznie. po co wam serwery aplikacyjne?
> przeciez macie fast-cgi / cgi-fast ;)
> a to jest tylko polsrodek, bo jak powstawalo to rozwiazanie,
> nikt nie mial lepszych pomyslow.
Przyznaj się, że nawet nie wiesz czym jest FastCGI. Aż żal Cię czytać gdy
piszesz o FastCGI "półśrodek", "niezdrowe", "tymczasowe". Całkowicie nie
rozumiesz tej technologii i nie wiesz po co została stworzona i to można
jasno wyczytać z Twoich wcześniejszych wypowiedzi. W dodatku uważasz, że
używana jest tylko w Perlu co jest całkowitym nieporozumieniem. FastCGI
używane jest też w Twoim kochanym Pythonie, np. w CherryPy i wielu innych
webowych frameworkach. Używany jest także w Ruby on Rails.
--asc
Dariusz Jackowski - 06-05-2006 00:08
Grzegorz Szyszlo wrote:
>
>> W jakich aplikacjach webowych czas przeparsowania programu robi
>> różnicę?
>
> w kazdych gdzie strona jest generowana z posrednictwem serwera
> aplikacyjnego, gdzie ta strona tak naprawde jest wielokrotnie
> dziedziczonym obiektem, ktory zawiera wielokrotnie dziedziczone obiekty
> skladowe. poczytaj o perlowym catalyst framework, to szybko zajarzysz w
> czym problem.
Serwer aplikacyjny jest od tego, aby cały czas rezydował w pamięci, a nie
odpalał się przy każdym wywołaniu (wtedy nie byłby już serwerem). Liczy się
więc tylko czas wykonania zadań, a nie czas sparsowania kodu, który
uruchamiany jest tylko raz. Poczytaj o perlowym Catalyst framework to szybko
zajarzysz jak to działa.
--asc
Dariusz Jackowski - 06-05-2006 00:08
Grzegorz Szyszlo wrote:
>
>> być może na zupełnie innej platformie?
>
> p-kod w pythonie w przeciwienstwie do javowego jest przenosny pomiedzy
> platformami, big/little endian nie jest dla niego problemem.
Większej bzdury w życiu nie czytałem. Bytecode Javy można uruchomić na
dowolnej maszynie i na dowolnym systemie operacyjnym. Endian nie ma tu nic
do rzeczy.
Natomiast Psyco - kompilator Pythona o którym ciągle piszesz - działa tylko
na procesorach Intela zgodnych z x86. W dodatku zużywa bardzo dużo pamięci.
--asc
Twelve Hungry Mammoths - 11-05-2006 17:31
On Fri, 05 May 2006 11:08:51 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>
>> co do wymienionych przez ciebie bledow projektowych, brak zrzutu
>> p-kodu w perlu powoduje, ze serwer aplikacyjny czy musi czy nie musi,
>> to utrzymuje raz wczytany applet, a czas jego usuniecia jest dosyc
>> dlugi, niepotrzebnie pozerajac zasoby. gdyby byl p-kod, to uzyty
>> applet moglby byc usuwany z pamieci natychmiast, bo bardzo szybko
>> mozna by go zaladowac ponownie.
>
> I naprawde tych apletow jest tyle roznych (a pamieci tak malo), ze
> oplaca sie je usuwac z pamieci na chwile?
chodzi o to, ze gdyby ponowne wczytanie nie bylo tak kosztowne, to
zarzadca pamieci moglby dzialac nieco efektywniej.
pzdr
szeryf
Twelve Hungry Mammoths - 11-05-2006 17:31
On Thu, 04 May 2006 23:14:17 +0200, Michal Jankowski <michalj@fuw.edu.pl>
wrote:
>
>> w takich, ktore maja duzo requestow na sekunde.
>
> I są napisane na zasadzie "każdy request to odpalenie programu do
> obsłuzenia go"?
bywaja i takie. nie kazdy uzywa przeciez mod_perla czy fast-cgi.
pzdr
szeryf
Twelve Hungry Mammoths - 11-05-2006 17:31
On Thu, 04 May 2006 21:25:36 +0200, Szymon Sokół
<szymon@bastard.operator.from.hell.pl> wrote:
>
> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
> to znaczy, że powinien był pisać w np. C i generować natywny kod
> maszynowy,
a jeszcze sie przyczepie do powyzszej bzdury, bo jakos nikt tego nie
wylapal. otoz nie zawsze da sie przepisac wszystko w C, nie zawsze sa na
to zasoby (programisci, czas), nie zawsze sa dostepne odpowiednie
biblioteki. przepisanie w C prostego programiku perlowego, ktory np. uzywa
regexpow i kilku fajnych modulow moze trwac tygodniami. a i wcale nie jest
powiedziane, ze bedzie to dzialalo szybciej, bo perl ma regexpy dobrze
zoptymalizowane. ze nie wspomne o koniecznosci testowania i konserwowania
naszego "dziela". gdyby w programowaniu chodzilo tylko o szybkosc (albo
nawet glownie o szybkosc), to istnialyby tylko dwa jezyki: assembler i
FORTRAN.
przeciez to truizmy sa, szczegolnie na takiej grupie jak
pl.comp.lang.perl. czy tu nikt nie pisze wiekszych programow, ze tego typu
bzdury przechodza bez slowa protestu?
pzdr
szeryf
Szymon =?iso-8859-2?Q?Sok=F3=B3?= - 11-05-2006 17:31
On Sun, 07 May 2006 19:08:43 +0200, Twelve Hungry Mammoths wrote:
> On Thu, 04 May 2006 21:25:36 +0200, Szymon Sokół
> <szymon@bastard.operator.from.hell.pl> wrote:
>>
>> Żeby mieć więcej kłopotu. Jeśli komuś naprawdę tak bardzo zależy na
>> efektywności, żeby robił mu różnicę ten czas przeparsowania programu,
>> to znaczy, że powinien był pisać w np. C i generować natywny kod
>> maszynowy,
>
> a jeszcze sie przyczepie do powyzszej bzdury, bo jakos nikt tego nie
> wylapal. otoz nie zawsze da sie przepisac wszystko w C, nie zawsze sa na
> to zasoby (programisci, czas), nie zawsze sa dostepne odpowiednie
> biblioteki. przepisanie w C prostego programiku perlowego, ktory np. uzywa
> regexpow i kilku fajnych modulow moze trwac tygodniami. a i wcale nie jest
> powiedziane, ze bedzie to dzialalo szybciej, bo perl ma regexpy dobrze
> zoptymalizowane. ze nie wspomne o koniecznosci testowania i konserwowania
> naszego "dziela". gdyby w programowaniu chodzilo tylko o szybkosc (albo
> nawet glownie o szybkosc), to istnialyby tylko dwa jezyki: assembler i
> FORTRAN.
Masz rację, poprawiam się. Zacytowane zdanie powinno było brzmieć "to
znaczy, że powinien był pisać w assemblerze" :->
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Bernard El-Hagin - 11-05-2006 17:31
In article <445b549b$1@news.home.net.pl>, Dariusz Jackowski wrote:
> Grzegorz Szyszlo wrote:
>>
>>> być może na zupełnie innej platformie?
>>
>> p-kod w pythonie w przeciwienstwie do javowego jest przenosny pomiedzy
>> platformami, big/little endian nie jest dla niego problemem.
>
> Większej bzdury w życiu nie czytałem.
O ile jeszcze do tego nie doszedles, tym zdaniem mozna podsumowac prawie
kazda mysl (hucznie to nazwijmy) tego goscia. Wrzuc go do KFa gdzie jego
miejsce i daruj sobie dyskusje z nim. Jest odporny na merytoryczna
poprawnosc.
--
Pozdrawiam,
Bernard
Vava - 11-05-2006 17:32
Grzegorz Szyszlo <znik@wbc.lublin.pl> wrote:
> Nie bron skladni pythona ;) perlowcy i tak maja racje. nawet w tym,
> ze twierdza ze nie sa skostniali, chociaz sa. przypomne do bolu.
> pytalem pare lat temu o serwer aplikacyjny w perlu, a zaproponowano
> mi fast-cgi i/lub cgi-fast (food) ;) niezdrowe, tyczasowe itp.
> serwery aplikacyjne w perlu dopiero raczkują, a największą ich
> bolączką jest brak natywnego wsparcia ze strony perla do zrzucania
> p-kodu.
$ cat test.pl
use DBI;
use DBD::SQlite;
use strict;
my $dbh = DBI->connect("dbi:SQLite:dbname=test.db","","") or die
"$DBI::errstr\n";
my $sth = $dbh->prepare("select * from test") or die "$dbh->errstr\n";
$sth->execute or die "$dbh->errstr\n";
while (my @wyn = $sth->fetchrow_array) {
print "@wyn\n";
}
die "$sth->errstr" if $sth->err;
$ perl test.pl
TEST1
TEST2
TEST3
TEST4
TEST5
$ perl -MO=Bytecode,-H,-b,-s,-k,-otest.bpl test.pl
test.pl syntax OK
$ perl test.bpl
TEST1
TEST2
TEST3
TEST4
TEST5
Pozdrawiam
--
Vava
Wawrzyniec Żurowski
Victoria vale, et ubique es, suaviter sternutas
Grzegorz Szyszlo - 11-05-2006 17:33
Vava wrote:
> $ perl -MO=Bytecode,-H,-b,-s,-k,-otest.bpl test.pl
> test.pl syntax OK
>
> $ perl test.bpl
> TEST1
> TEST2
> TEST3
> TEST4
> TEST5
dzieki, z pewnoscia skorzystam. w kazdym razie to cos
jest jednak utrudnieniem, bo w inny sposob trzeba uzywac
p-kompilatow. poza tym co z p-kompilatami dla wlasnych
bibliotek itp? ;)
a jesli ja zechce zapisac jako p-kompilat pojedyncza
procedurke bo mam taka potrzebe?
tak czy siak, dobrze ze to jest, szkoda ze nie jest
tak przezroczyste jak w pythonie. pewnie za pare lat
jak doczekam sie praprawnukow taka mozliwosc powstanie ;)
znik.
lrem@lrem.maxnet - 24-05-2006 00:19
W poście <op.s9cvfrx8sx85je@valis>,
Vava nabazgrał:
> $ perl -MO=Bytecode,-H,-b,-s,-k,-otest.bpl test.pl
Interesujące, ale dokumentacja jest raczej skąpa i straszy wielkim
,,THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.''
Nie pozwoliła mi jednak odpowiedzieć na pytanie: czy można łatwo
w ten sposób prekompilować program wraz z _wszystkimi_ modułami z jakich
on korzysta? Tak aby całkowicie wyeliminować konieczność kompilacji przy
uruchamianiu...
--
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
- Piotr Kucharski
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
Strona 2 z 2 • Znaleźliśmy 190 postów • 1, 2
|
Oracle, SQL, PL/SQL. Jak =?ISO-8859-2?Q?napisa=E6_zapytanie=2C?==?ISO-8859-2?Q?_kt=F3re_zwr=F3ci_nazw=EA_atrybutu=2C_kt=F3reg o?==?ISO-8859-2?Q?_warto=B6ci_spe=B3niaj=B1_zadany_warunek?=
=?ISO-8859-2?Q?Zawarto=B6=E6_tabeli_na_podstawie_warto=B6?==? ISO-8859-2?Q?ci_w_innej?=
[MySQL] Skopiowanie =?ISO-8859-2?Q?warto=B6ci_z_jednego_po?==?ISO-8859-2?Q?la_do_drugiego_w_jednej_tabeli=2C_r=F3=BFne_?= =?ISO-8859-2?Q?wiersze=2E?=
=?ISO-8859-2?Q?Re=3A_Informatyka=2C_Java=2C_EJB=2C_Ajax=2C?== ?ISO-8859-2?Q?_Spring=2E_Czy=BFby_to_koniec_=B6wiata=2C_czy? ==?ISO-8859-2?Q?_te=BF_nasze_uczelnie_b=EAd=B1_uczy=B3y_w_k?== ?ISO-8859-2?Q?o=F1cu!_czego_praktyczne?=
Django - newforms, DateField=?iso-8859-2?Q?domy=B6lna_warto=B6=E6?= ustawiona na=?iso-8859-2?Q?'dzi=B6'?=
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
=?UTF-8?Q?=5Bmysql=5D_jak_pobra=C4=87_warto=C5=9B=C4=87_ AUTO=5F?==?UTF-8?Q?INCREMENT=3F?=
[MySQL4.1] jak =?ISO-8859-2?Q?przypilnowa=E6_warto=B6ci_UNSI?==?ISO-8859-2?Q?GNED=3F?=
Jak =?ISO-8859-2?Q?pobra=E6_mo=BFliwe_warto=B6ci_z_pola_?==?ISO-8859-2?Q?typu_ENUM?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
