🚀 go-pugleaf

Qertoip napisał(a):
> Na początek uczciwie zaznaczę, że jestem w Pythonie początkujący. Nie
> licząc różnych "wprawek", napisałem około 1000 wierszy działającego kodu
> (wątki, sockety, XML). Inną część tej samej aplikacji (również: wątki,
> sockety, XML) piszę w .NET (VS2003).
> 
> Tym samym miałem okazję porównać swoją produktywność na tych dwóch
> platformach. Podkreślę - nie tyle językach, co *platformach*.
> 
> Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
> wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
> 
> Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
> - bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
> 
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
> 
> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
> 
> Jestem głodny Waszych uwag na ten temat. 
> Czy da się jakoś zniwelować powyższe problemy?
> Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
> nowoczesnych językach?
> 
> 

zgadzam sie w 100%;

-- 
Przemek Wiśniewski

Qertoip wrote:

> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.

To zleży jakiego ID używasz, opcję o której mówisz posiadają takie 
edytory jak: PythonWin czy też (Eclipse + pydev) - innych nie pamiętam. 
Co do dokumentacji, to nie wiem co myśleć dla mnie zawsze była 
wystarczająca i jakiś takich większych zastrzeżeń nie mogę zgłosić.

Pozdrawiam
Mateusz

Mateusz Sołtysek napisał(a):
> Qertoip wrote:
> 
>> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
>> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
>> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
> 
> 
> To zleży jakiego ID używasz, opcję o której mówisz posiadają takie 
> edytory jak: PythonWin czy też (Eclipse + pydev) - innych nie pamiętam. 
> Co do dokumentacji, to nie wiem co myśleć dla mnie zawsze była 
> wystarczająca i jakiś takich większych zastrzeżeń nie mogę zgłosić.

Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie 
da sie zrobic skutecznych narzedzi do refaktoryzacji, bo kod zawiera za 
malo informacji i dodatkowo python pozwala typy tworzyc dynamicznie. 
Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i 
klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie 
narzedzia do pythona wygladaja malo powaznie.

Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo 
latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).

-- 
Przemek Wiśniewski

... W dole szumi rzeka, w górze fruwa ptak
A Przemek Wiśniewski sobie idzie i śpiewa sobie tak:

>> To zleży jakiego ID używasz, opcję o której mówisz posiadają takie 
>> edytory jak: PythonWin czy też (Eclipse + pydev) - innych nie pamiętam. 
>> Co do dokumentacji, to nie wiem co myśleć dla mnie zawsze była 
>> wystarczająca i jakiś takich większych zastrzeżeń nie mogę zgłosić.
> 
> Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie 
> da sie zrobic skutecznych narzedzi do refaktoryzacji, 

http://bicyclerepair.sourceforge.net/

> bo kod zawiera za malo informacji 

A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.

> i dodatkowo python pozwala typy tworzyc dynamicznie. 
> Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i 
> klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie 
> narzedzia do pythona wygladaja malo powaznie.

Uwaga na nisko przelatujące kwantyfikatory.
 
[---]
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak wrote:

> http://bicyclerepair.sourceforge.net/

To jakiś chyba niezgorszy wypas, dziex za link

> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.

Czasami analiza statyczna jest konieczna, w tym sęk... Szczególnie jeśli 
kiero projektu jest zatwardziałym dżawowcem ;)

>>i dodatkowo python pozwala typy tworzyc dynamicznie. 
>>Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i 
>>klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie 
>>narzedzia do pythona wygladaja malo powaznie.
> 
> 
> Uwaga na nisko przelatujące kwantyfikatory.

que?

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>> http://bicyclerepair.sourceforge.net/
> 
> To jakiś chyba niezgorszy wypas, dziex za link

Pierwsze trafienie z http://www.google.com/search?q=python+refactoring ;)

Intregrowalny przynajmniej z Idle, emacsem i vimem, założenia masz opisane na 
http://c2.com/cgi-bin/wiki?PythonRefactoringBrowser, więcej info na 
http://c2.com/cgi-bin/wiki?BicycleRepairMan
 
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
> 
> Czasami analiza statyczna jest konieczna, w tym sęk... 

Ale wiesz, to jeszcze nie znaczy, że refaktoryzacja jest niemożliwa, a jedyne
co można zrobić to "regexpami podmieniac na chybil trafil nazwy metod".

> Szczególnie jeśli kiero projektu jest zatwardziałym dżawowcem ;)
 
Naprostować go. ;) 

[---]
>>>klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie 
>>>narzedzia do pythona wygladaja malo powaznie.
>> 
>> 
>> Uwaga na nisko przelatujące kwantyfikatory.
> 
> que?

"Poważny wygląd" to oczywiście DGCC, ale słowo "wszystkie" jest za mocne. Co
jest niepoważnego w Eclipse? 

http://www.python.org/moin/EclipsePythonIntegration

Przyglądałeś się Komodo?

http://www.activestate.com/Products/Komodo/?utm_source=home&utm_medium=banner&utm_campaign=komodo_home_page
http://www.activestate.com/Products/Komodo/more_information.plex
http://www.activestate.com/Products/Download/featuretour.plex?id=Komodo&pageid=KomodoMain

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Dnia Tue, 10 May 2005 11:55:29 +0200, Przemek Wiśniewski napisał(a):

> Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie
> da sie zrobic skutecznych narzedzi do refaktoryzacji, bo kod zawiera za
> malo informacji i dodatkowo python pozwala typy tworzyc dynamicznie. 

To nie dotyczy w ogole Pythona jako takiego ale ogolnie jezykow
dynamicznych. Nie mozna wszystkiego miec. Kazde rozwiazanie ma swoje zalety
i wady. To odwieczny spor zwolennikow statycznej kompilacji i definicji
typow ze zwolennikami podejscia dynamicznego. Czesto osoby 'spaczone' praca
z java czy c++ tworza potem potworki jezykowe w Pythonie lub Ruby bo nie
moga pozbyc sie swoich nawykow ktore tu nie maja specjalnie sensu. To tez
moze tez przeszkoda w skutecznym poslugiwaniu sie takim jezykiem jak
Python. Dla mnie to b. intuicyjny jezyk i prawie w ogole nie musze zagladac
do manuali czego nie powiedzialbym np. o php (ktorego znam wiele lat
dluzej). Jezyk C porzucilem kupe lat temu, od Javy odrzucily mnie
(paradoksalnie) opinie Bruce Eckela, javowego guru no i koszmarna
nadmiarowosc kodu Javy. Nie przekreslam javy, ale jest na pewno mniej sexy
niz jezyki dynamiczne. ;)

> Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo 
> latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).

Plone nie jest spieprzony. To dobry projekt, ma doskonale zalozenia
obiektowego podejscia do CMS'a. Problemem jest Zope2 (na ktorym Plone sie
opiera). Zope2 ktory ma niekonsekwentne API, trudno w tym sie faktycznie
polapac.
Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh

--
JZ

JZ wrote:
> Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
> skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
> prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh

No, to akurat jest argument za spieprzeniem. Vide J2EE: "firmowy" 
introduction Suna ma 1k+ stron :O

JZ napisał(a):
> 
>>Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo 
>>latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
> 
> 
> Plone nie jest spieprzony. To dobry projekt, ma doskonale zalozenia
> obiektowego podejscia do CMS'a. Problemem jest Zope2 (na ktorym Plone sie
> opiera). Zope2 ktory ma niekonsekwentne API, trudno w tym sie faktycznie
> polapac.

Za nic mnie nie przekonasz, juz umoczylem w tym paluchy i nie chce nigdy 
wiecej.

> Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
> skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
> prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh

To i tak za malo, o javie pisza znacznie szerzej.

-- 
Przemek Wiśniewski

Dnia Tue, 10 May 2005 14:43:59 +0200, RobertSzefler napisał(a):

>> Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
>> skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
>> prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh
> 
> No, to akurat jest argument za spieprzeniem. Vide J2EE: "firmowy" 
> introduction Suna ma 1k+ stron :O

Nie na temat. Nie chodzi o licytacje ilosci stron dokumentacji, ale o to,
ze Zope3 jest lepiej zaprojektowany od Zope2. A ta ksiazka to ladnie
pokazuje. Nic wiecej.

--
JZ

Dnia Tue, 10 May 2005 11:58:29 +0200, Grzegorz Staniak <gstaniak@wp.pl> napisał:

[...]

> http://bicyclerepair.sourceforge.net/

Ale to prawie nic nie potrafi :)

>> bo kod zawiera za malo informacji
>
> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.

Jedyna pewna metoda to testy.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Tue, 10 May 2005 13:37:51 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[refaktoryzacja]

> Czasami analiza statyczna jest konieczna, w tym sęk...

Analiza statyczna tak, ale nie w językach dynamicznie typowanych.

>
>>> i dodatkowo python pozwala typy tworzyc dynamicznie.
>>> Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i
>>> klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
>>> narzedzia do pythona wygladaja malo powaznie.
>>
>>
>> Uwaga na nisko przelatujące kwantyfikatory.
>
> que?

      <wziut>

-- 
http://www.piotr.dembiński.prv.pl

Dnia Tue, 10 May 2005 14:22:36 +0200, JZ <usenet@zabiello.com> napisał:

[...]

> Dla mnie to b. intuicyjny jezyk i prawie w ogole nie musze zagladac
> do manuali

Ta intuicyjność może być zmorą, jak chcesz napisać coś, co operuje
na kodzie Pythonowym bez żadnych założeń co do tego kodu.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Tue, 10 May 2005 21:11:33 +0200, Piotr Dembiński napisał(a):

> Ta intuicyjność może być zmorą, jak chcesz napisać coś, co operuje
> na kodzie Pythonowym bez żadnych założeń co do tego kodu.

No zawsze musisz wczesniej wiedziec co chcesz napisac. A do wiekszych
aplikacji bez dobrego projektu tego co to ma byc i jak dzialac daleko nie
zajedziesz. Python tylko ulatwia sam proces kodowania. Zmniejsza
czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.

--
JZ

 > Python tylko ulatwia sam proces kodowania. Zmniejsza
> czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
> dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.

Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak 
porównać jeszcze wielkość tych bibliotek to Python nie ma szans.

Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że 
python nie ma prawie bibliotek klasy enterprise. Poprogramuj w Zopie bez 
zaglądania do dokumentacji:)


Pozdr
Climbus

Dnia Tue, 10 May 2005 23:29:19 +0200, Climbus napisał(a):

> Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak 
> porównać jeszcze wielkość tych bibliotek to Python nie ma szans.

Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
bo jest od 5 do 15 razy mniejszy. :))

> Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że 
> python nie ma prawie bibliotek klasy enterprise. 

Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie i w
kazdym jezyku.

--
JZ

> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
> bo jest od 5 do 15 razy mniejszy. :))

Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.

>>Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że 
>>python nie ma prawie bibliotek klasy enterprise. 
> Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
> enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
> biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
> ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
> przejrzysta. 

Ta jasne, powiedz to Robertowi:) Z tego co sobie przypominam to w xmlrpc 
są jakieś niedoróbki, dokumentacja też nie jest wspaniała, a 
przynajmniej ja nie mogę się w niej znaleźć.

> A to ze sa inne
> projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie i w
> kazdym jezyku.

Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą. 
Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.

Dnia Wed, 11 May 2005 00:07:16 +0200, Climbus napisał(a):

>> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
>> bo jest od 5 do 15 razy mniejszy. :))
> 
> Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.

Licza sie tylko te funkcjonalnosci jakie potrzebujesz. Ilosc nie ma
znaczenia. Czasem jest wrecz przeszkoda, bo nie wiadomo co wybrac.

>> A to ze sa inne projekty mniej lub bardziej dojrzale to inna sprawa. Tak
>> jest wszedzie i w kazdym jezyku.
> 
> Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą. 
> Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.

Owszem i co z tego? Python nie ma takiego wsparcia marketingowego jak Sun
czy M$. Ale jest tez sporo duzych firm ktore korzystaja z Pythona, np.
Google, Industrial Light and Magic, rozne organizacje rzadowe, pozarzadowe
i wojskowe.

--
JZ

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>> http://bicyclerepair.sourceforge.net/
> 
> Ale to prawie nic nie potrafi :)

Bo dopiero powstaje. Numer wersji zauważyłeś? Tym niemniej, skutecznie
falsyfikuje tezę, jakoby Python uniemożliwał tworzenie narzędzi do
refaktoryzacji kodu, a jedyną możliwość w tym zakresie stanowiło "podmienianie
nazw zmiennych regexpami na oślep".
 
>>> bo kod zawiera za malo informacji
>>
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
> 
> Jedyna pewna metoda to testy.
 
Tym niemniej, introspekcja dostarcza dość informacji, by nie trzeba było
opierać się na "podmienianiu nazw regexpami".

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Piotr Dembiński wrote:
> Dnia Tue, 10 May 2005 13:37:51 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [refaktoryzacja]
> 
>> Czasami analiza statyczna jest konieczna, w tym sęk...
> 
> 
> Analiza statyczna tak, ale nie w językach dynamicznie typowanych.

Rozwala mnie Twoja logika

Piotr Dembiński wrote:

>>> bo kod zawiera za malo informacji
>>
>>
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
> 
> 
> Jedyna pewna metoda to testy.

Kompletna herezja. Testy *nigdy* nie są pewną metodą ze względu 
chociażby na nierozstrzygalność problemu stopu na maszynie Turinga. 
Jedyną pewną metodą jest konstrukcja języka umożliwiająca statyczne 
typowanie i ścisłe wymuszanie typów.

JZ wrote:
> Dnia Wed, 11 May 2005 00:07:16 +0200, Climbus napisał(a):
> 
> 
>>>Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
>>>bo jest od 5 do 15 razy mniejszy. :))
>>
>>Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.
> 
> 
> Licza sie tylko te funkcjonalnosci jakie potrzebujesz. Ilosc nie ma
> znaczenia. Czasem jest wrecz przeszkoda, bo nie wiadomo co wybrac.

Jeśli ilość -> 0, użyteczność wraz z nią.

Wolałbym mieć problem wyboru wśród dobrych, niż wśród kiepściutkich, na 
prawdę...

>>>A to ze sa inne projekty mniej lub bardziej dojrzale to inna sprawa. Tak
>>>jest wszedzie i w kazdym jezyku.
>>
>>Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą. 
>>Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.
> 
> 
> Owszem i co z tego? Python nie ma takiego wsparcia marketingowego jak Sun
> czy M$. Ale jest tez sporo duzych firm ktore korzystaja z Pythona, np.
> Google, Industrial Light and Magic, rozne organizacje rzadowe, pozarzadowe
> i wojskowe.

W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania 
renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla 
Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale 
czy jesteś pewien, że oni tego używają ;) ;) ;)

Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler napisał(a):

> A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
> jesteś pewien, że oni tego używają ;) ;) ;)

A Zope cos ci mowi? Korzysta z niego np. NATO.

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler napisał(a):
> 
> 
>>A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
>>jesteś pewien, że oni tego używają ;) ;) ;)
> 
> 
> A Zope cos ci mowi? Korzysta z niego np. NATO.

No nie wiem. To, że mówią, że używają, to nie znaczy, że używają. Taka 
mała paranoja.

Osobiście uważam, że gdyby NATO używało Zope za (pierwszej) zimnej 
wojny, to byśmy dzisiaj mieli u nas cara a nie kwaśnego prezia.

JZ napisał(a):
> Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler napisał(a):
> 
> 
>>A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
>>jesteś pewien, że oni tego używają ;) ;) ;)
> 
> 
> A Zope cos ci mowi? Korzysta z niego np. NATO.

Doczytaj do czego NATO uzywa zopa.

-- 
Przemek Wiśniewski

RobertSzefler <rszeflerUSUNTO@murator.com.pl> wrote:
> W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania 
> renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla 
> Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale 
> czy jesteś pewien, że oni tego używają ;) ;) ;)
	... wspominajac np. Yahoo, technologia ultraseek'a do wyszukiwania
opiera się o pythona, to chyba najwiekszy konkurent google aktualnie.
Licenja pozwala na dosyc duze ukrycie dzialalnosci opartej na Pythonie,
nikt nie musi się zbytnio chwalic. Z powazaniem
								Adam Przybyla

Adam Przybyla wrote:
> RobertSzefler <rszeflerUSUNTO@murator.com.pl> wrote:
> 
>>W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania 
>>renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla 
>>Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale 
>>czy jesteś pewien, że oni tego używają ;) ;) ;)
> 
> 	... wspominajac np. Yahoo, technologia ultraseek'a do wyszukiwania
> opiera się o pythona, to chyba najwiekszy konkurent google aktualnie.
> Licenja pozwala na dosyc duze ukrycie dzialalnosci opartej na Pythonie,
> nikt nie musi się zbytnio chwalic. Z powazaniem
> 								Adam Przybyla

Dobrze wiedzieć. Jednak w dalszym ciągu bez porównania z wdrożeniami 
J2EE. Serwisy typu google, ultraseek, w pewnej części yahoo to osobna 
sprawa, tam praca programistów jest bardziej organiczna niż w typowych 
wdrożeniach webowych, mają własny autorski soft. Rozmawiamy zdaję się 
raczej o w miarę standardowych wdrożeniach Pythona i innych technologii, 
do których to wdrożeń potrzebne są frameworki. Mam wrażenie, że koderzy 
z googla mają zope i całą spółkę pythonowskiego webframeworkowego 
światka w jeszcze głębszym poważaniu niż np. ja ;)

Dnia 11.05.2005 RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał/a:

>> 	... wspominajac np. Yahoo, technologia ultraseek'a do wyszukiwania
>> opiera się o pythona, to chyba najwiekszy konkurent google aktualnie.
>> Licenja pozwala na dosyc duze ukrycie dzialalnosci opartej na Pythonie,
>> nikt nie musi się zbytnio chwalic. Z powazaniem
>> 								Adam Przybyla
>
> Dobrze wiedzieć. Jednak w dalszym ciągu bez porównania z wdrożeniami 
> J2EE. Serwisy typu google, ultraseek, w pewnej części yahoo to osobna 
> sprawa, tam praca programistów jest bardziej organiczna niż w typowych 
> wdrożeniach webowych, mają własny autorski soft. Rozmawiamy zdaję się 
> raczej o w miarę standardowych wdrożeniach Pythona i innych technologii, 
> do których to wdrożeń potrzebne są frameworki. Mam wrażenie, że koderzy 
> z googla mają zope i całą spółkę pythonowskiego webframeworkowego 
> światka w jeszcze głębszym poważaniu niż np. ja ;)

Wrażenia to można sobie mieć.
Stosowanie danego języka zależy tylko i wyłącznie od programistów
a raczej od ich przyzwyczajeń - przeważnie złych.

W  serwisach typu google, yahoo praca programistów jest bardziej "ograniczona"
- naprawdę dobry tekst. 
-- 
Tomasz Drobiszewski		

baklarz wrote:
> Dnia 11.05.2005 RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał/a:
> 
> 
>>>	... wspominajac np. Yahoo, technologia ultraseek'a do wyszukiwania
>>>opiera się o pythona, to chyba najwiekszy konkurent google aktualnie.
>>>Licenja pozwala na dosyc duze ukrycie dzialalnosci opartej na Pythonie,
>>>nikt nie musi się zbytnio chwalic. Z powazaniem
>>>								Adam Przybyla
>>
>>Dobrze wiedzieć. Jednak w dalszym ciągu bez porównania z wdrożeniami 
>>J2EE. Serwisy typu google, ultraseek, w pewnej części yahoo to osobna 
>>sprawa, tam praca programistów jest bardziej organiczna niż w typowych 
>>wdrożeniach webowych, mają własny autorski soft. Rozmawiamy zdaję się 
>>raczej o w miarę standardowych wdrożeniach Pythona i innych technologii, 
>>do których to wdrożeń potrzebne są frameworki. Mam wrażenie, że koderzy 
>>z googla mają zope i całą spółkę pythonowskiego webframeworkowego 
>>światka w jeszcze głębszym poważaniu niż np. ja ;)

> Wrażenia to można sobie mieć.

o, dziękuję ;)

> Stosowanie danego języka zależy tylko i wyłącznie od programistów
> a raczej od ich przyzwyczajeń - przeważnie złych.

no jasne, ale chodzi mi o to, że oni mogą sobie pozwolić na to, żeby 
wejść w jakąś technologię tylko dla tego, że jest nowoczesna i 
obiecująca, podczas gdy większość programistów w firmach nie może, bo 
potrzebują chociaż jakichś wzorcowych rozwiązań wysokiej klasy, na 
których mogliby budować.

> W  serwisach typu google, yahoo praca programistów jest bardziej "ograniczona"
> - naprawdę dobry tekst. 

obstaję przy "organiczna" !

Dnia 11.05.2005 RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał/a:


>>>Dobrze wiedzieć. Jednak w dalszym ciągu bez porównania z wdrożeniami 
>>>J2EE. Serwisy typu google, ultraseek, w pewnej części yahoo to osobna 
>>>sprawa, tam praca programistów jest bardziej organiczna niż w typowych 
>>>wdrożeniach webowych, mają własny autorski soft. Rozmawiamy zdaję się 
>>>raczej o w miarę standardowych wdrożeniach Pythona i innych technologii, 
>>>do których to wdrożeń potrzebne są frameworki. Mam wrażenie, że koderzy 
>>>z googla mają zope i całą spółkę pythonowskiego webframeworkowego 
>>>światka w jeszcze głębszym poważaniu niż np. ja ;)
>> Stosowanie danego języka zależy tylko i wyłącznie od programistów
>> a raczej od ich przyzwyczajeń - przeważnie złych.
>
> no jasne, ale chodzi mi o to, że oni mogą sobie pozwolić na to, żeby 
> wejść w jakąś technologię tylko dla tego, że jest nowoczesna i 
> obiecująca, podczas gdy większość programistów w firmach nie może, bo 
> potrzebują chociaż jakichś wzorcowych rozwiązań wysokiej klasy, na 
> których mogliby budować.  
Czemu oni moga sobie pozwolic a inni nie? 
Moim zdaniem większość programistów ogranicza się sama.
Kiedyś usłyszeli, że Java jest cacy do wszystkiego i tego się trzymają.
>> W  serwisach typu google, yahoo praca programistów jest bardziej "ograniczona"
>> - naprawdę dobry tekst. 
>
> obstaję przy "organiczna" !

przepraszam, źle przeczytałem.
Google, yahoo,  WP w Polsce to nie są organizacje skupiające
wolontariuszy i technologie, które stosują muszą być niezawodne.
To że niektórzy nie mogą sobie pozwolić na jakość Pythona ( programistów
) to już ich sprawa.

Jak dla mnie EOT.
-- 
Tomasz Drobiszewski		

Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

> W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania
> renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla
> Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale
> czy jesteś pewien, że oni tego używają ;) ;) ;)

Wojskowi mają lispy :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 10:47:59 +0200, Przemek Wiśniewski <sdf@fasd.sdf> napisał:

> JZ napisał(a):
>> Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler napisał(a):
>>
>>
>>> A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
>>> jesteś pewien, że oni tego używają ;) ;) ;)
>>
>>
>> A Zope cos ci mowi? Korzysta z niego np. NATO.
>
> Doczytaj do czego NATO uzywa zopa.

Wojsko raczej nie używa świeżych, nie przetestowanych technologii.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 11:38:17 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

> Dobrze wiedzieć. Jednak w dalszym ciągu bez porównania z wdrożeniami
> J2EE.

To ja kiedyś przeczytałem, że jeśli oddalić się wystarczająco daleko
od Javy, to będzie widać tylko wielki, lśniący plafon reklamowy Suna :>

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:02:46 +0200, Grzegorz Staniak <gstaniak@wp.pl> napisał:

> ... W dole szumi rzeka, w górze fruwa ptak
> A Piotr Dembiński sobie idzie i śpiewa sobie tak:
>
>>> http://bicyclerepair.sourceforge.net/
>>
>> Ale to prawie nic nie potrafi :)
>
> Bo dopiero powstaje. Numer wersji zauważyłeś?

0.9?  Moim zdaniem powinno być 0.09.

> Tym niemniej, skutecznie falsyfikuje tezę, jakoby Python uniemożliwałtworzenie narzędzi do refaktoryzacji kodu, a jedyną możliwość w tymzakresie stanowiło "podmienianie nazw zmiennych regexpami na oślep".

d'oh, ja nie mówię, że *w ogóle* nie można, tylko że jest to trudne

>>>> bo kod zawiera za malo informacji
>>>
>>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>>
>> Jedyna pewna metoda to testy.
>Tym niemniej, introspekcja dostarcza dość informacji, by nie trzeba było
> opierać się na "podmienianiu nazw regexpami".

A kto tu mówił o regexpach?

Tak swoją drogą, BRM korzysta z regexpów w celu przespieszenia wykonania
refaktoryzacji.  Pełny parser okazał się zbyt wolny :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:52:43 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

> Piotr Dembiński wrote:
>> Dnia Tue, 10 May 2005 13:37:51 +0200, RobertSzefler
>> <rszeflerUSUNTO@murator.com.pl> napisał:
>>
>> [refaktoryzacja]
>>
>>> Czasami analiza statyczna jest konieczna, w tym sęk...
>>
>>
>> Analiza statyczna tak, ale nie w językach dynamicznie typowanych.
>
> Rozwala mnie Twoja logika

Logika?  To było raczej hasło niż udowodnione naukowo stwierdzenie.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:54:21 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

> Piotr Dembiński wrote:
>
>>>> bo kod zawiera za malo informacji
>>>
>>>
>>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>>
>>
>> Jedyna pewna metoda to testy.
>
> Kompletna herezja.

Nie sądzę.

> Testy *nigdy* nie są pewną metodą ze względu chociażby na nierozstrzygalnośćproblemu stopu na maszynie Turinga.

Pisałem o testach jednostkowych pisanych przez programistę znającego
refaktoryzowany program.

> Jedyną pewną metodą jest konstrukcja języka umożliwiająca statycznetypowanie i ścisłe wymuszanie typów.

Możliwe, jednak Python nie jest w tej chwili takim językiem.

-- 
http://www.piotr.dembiński.prv.pl

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>>> http://bicyclerepair.sourceforge.net/
>>>
>>> Ale to prawie nic nie potrafi :)
>>
>> Bo dopiero powstaje. Numer wersji zauważyłeś?
> 
> 0.9?  Moim zdaniem powinno być 0.09.

Ale Twoje wymagania wobec narzędzi do refaktoryzacji to zupełnie inna bajka. 
 
>> Tym niemniej, skutecznie falsyfikuje tezę, jakoby Python uniemożliwałtworzenie narzędzi do refaktoryzacji kodu, a jedyną możliwość w tymzakresie stanowiło "podmienianie nazw zmiennych regexpami na oślep".
> 
> d'oh, ja nie mówię, że *w ogóle* nie można, tylko że jest to trudne

Co nie znaczy, że "nie da sie zrobic skutecznych narzedzi do refaktoryzacji" 
i "mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i klas".
 
>>>>> bo kod zawiera za malo informacji
>>>>
>>>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>>>
>>> Jedyna pewna metoda to testy.
>> Tym niemniej, introspekcja dostarcza dość informacji, by nie trzeba było
>> opierać się na "podmienianiu nazw regexpami".
> 
> A kto tu mówił o regexpach?

A czytasz wątek?
 
> Tak swoją drogą, BRM korzysta z regexpów w celu przespieszenia wykonania
> refaktoryzacji.  Pełny parser okazał się zbyt wolny :)
 
Jak sobie optymalizują kod pod wydajność to inna para kaloszy. Ważne, że nie
są ograniczeni do co najwyżej regexpów.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Piotr Dembiński <pdemb@gazeta.pl> wrote:
> Dnia Wed, 11 May 2005 10:47:59 +0200, Przemek Wiśniewski <sdf@fasd.sdf> napisał:
> 
>> JZ napisał(a):
>>> Dnia Wed, 11 May 2005 10:06:03 +0200, RobertSzefler napisał(a):
>>>
>>>
>>>> A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
>>>> jesteś pewien, że oni tego używają ;) ;) ;)
>>>
>>>
>>> A Zope cos ci mowi? Korzysta z niego np. NATO.
>>
>> Doczytaj do czego NATO uzywa zopa.
> 
> Wojsko raczej nie używa świeżych, nie przetestowanych technologii.
	... uzywaja agendy zajmojace się podobnymi "ekstremalnymi" technologiami;-)
Np ESA do modelowania cyfrowego, omal nie wyladowal python jako jezyk skryptowy
sterujacy nowego nowym kosmicznmym teleskopem , robinym przez NASA (skonczylo się na javascript'cie)  
Te technologie robai te same firmy , co dla wojska. Z powazaniem
								Adam Przybyla

Piotr Dembiński wrote:

>> Testy *nigdy* nie są pewną metodą ze względu chociażby na 
>> nierozstrzygalnośćproblemu stopu na maszynie Turinga.
> 
> Pisałem o testach jednostkowych pisanych przez programistę znającego
> refaktoryzowany program.

A przepraszam, Pan zna cały swój kod? Jeśli się wypluje z siebie parę 
tysięcy linii w ciągu paru tygodni, to na prawdę jest kompletnie 
nierealna intelektualna jego kontrola.

>> Jedyną pewną metodą jest konstrukcja języka umożliwiająca 
>> statycznetypowanie i ścisłe wymuszanie typów.
> 
> Możliwe, jednak Python nie jest w tej chwili takim językiem.

No przecież to właśnie pisałem :)

A swoją drogą, ciekawe co w tej kwestii, jeśli cokolwiek, dołożą w Py3K.

Dnia Wed, 11 May 2005 16:14:29 +0200, Grzegorz Staniak <gstaniak@wp.pl> napisał:

[...]

>> A kto tu mówił o regexpach?
>
> A czytasz wątek?

Tak.  Mówimy chyba o dwóch, zupełnie różnych rzeczach.

>> Tak swoją drogą, BRM korzysta z regexpów w celu przespieszenia wykonania
>> refaktoryzacji.  Pełny parser okazał się zbyt wolny :)
>Jak sobie optymalizują kod pod wydajność to inna para kaloszy. Ważne, że nie
> są ograniczeni do co najwyżej regexpów.

Gdyby byli ograniczeni, łatwiej by im było już napisać od podstaw interpreter :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 16:26:43 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

> Piotr Dembiński wrote:
>
>>> Testy *nigdy* nie są pewną metodą ze względu chociażby na
>>> nierozstrzygalnośćproblemu stopu na maszynie Turinga.
>>
>> Pisałem o testach jednostkowych pisanych przez programistę znającego
>> refaktoryzowany program.
>
> A przepraszam, Pan zna cały swój kod? Jeśli się wypluje z siebie parę
> tysięcy linii w ciągu paru tygodni, to na prawdę jest kompletnie
> nierealna intelektualna jego kontrola.

Tak, pisałem o tym przed chwilą.

>>> Jedyną pewną metodą jest konstrukcja języka umożliwiająca
>>> statycznetypowanie i ścisłe wymuszanie typów.
>>
>> Możliwe, jednak Python nie jest w tej chwili takim językiem.
>
> No przecież to właśnie pisałem :)

No to znamy fakty :>

> A swoją drogą, ciekawe co w tej kwestii, jeśli cokolwiek, dołożą w Py3K.

Ja wróciłem do 1.5.2.

-- 
http://www.piotr.dembiński.prv.pl

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>> A kto tu mówił o regexpach?
>>
>> A czytasz wątek?
> 
> Tak. Mówimy chyba o dwóch, zupełnie różnych rzeczach.

<d5q0ek$4ad$1@gw.magellan.net.pl>

i sprawdź w jaką rozmowę się włączyłeś.
 
[---]
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Piotr Dembiński wrote:
> Dnia Wed, 11 May 2005 16:26:43 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
>> Piotr Dembiński wrote:
>>
>>>> Testy *nigdy* nie są pewną metodą ze względu chociażby na
>>>> nierozstrzygalnośćproblemu stopu na maszynie Turinga.
>>>
>>>
>>> Pisałem o testach jednostkowych pisanych przez programistę znającego
>>> refaktoryzowany program.
>>
>>
>> A przepraszam, Pan zna cały swój kod? Jeśli się wypluje z siebie parę
>> tysięcy linii w ciągu paru tygodni, to na prawdę jest kompletnie
>> nierealna intelektualna jego kontrola.
> 
> 
> Tak, pisałem o tym przed chwilą.

Cóż, tylko pogratulować!

> 
>> A swoją drogą, ciekawe co w tej kwestii, jeśli cokolwiek, dołożą w Py3K.
> 
> 
> Ja wróciłem do 1.5.2.

Heh, twardo!

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

>> Jedyną pewną metodą jest konstrukcja języka umożliwiająca
>> statycznetypowanie i ścisłe wymuszanie typów.
>
> Możliwe, jednak Python nie jest w tej chwili takim językiem.

Ale jak najbardziej jest
Przynajmniej w sensie "scislego wymuszania typow"

Adam Karpierz

Dnia Wed, 11 May 2005 16:46:23 +0200, Grzegorz Staniak <gstaniak@wp.pl> napisał:

> ... W dole szumi rzeka, w górze fruwa ptak
> A Piotr Dembiński sobie idzie i śpiewa sobie tak:
>
>>>> A kto tu mówił o regexpach?
>>>
>>> A czytasz wątek?
>>
>> Tak. Mówimy chyba o dwóch, zupełnie różnych rzeczach.
>
> <d5q0ek$4ad$1@gw.magellan.net.pl>
>
> i sprawdź w jaką rozmowę się włączyłeś.

O narzędziach.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 17:04:47 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

> Piotr Dembiński wrote:
>> Dnia Wed, 11 May 2005 16:26:43 +0200, RobertSzefler
>> <rszeflerUSUNTO@murator.com.pl> napisał:
>>
>>> Piotr Dembiński wrote:
>>>
>>>>> Testy *nigdy* nie są pewną metodą ze względu chociażby na
>>>>> nierozstrzygalnośćproblemu stopu na maszynie Turinga.
>>>>
>>>>
>>>> Pisałem o testach jednostkowych pisanych przez programistę znającego
>>>> refaktoryzowany program.
>>>
>>>
>>> A przepraszam, Pan zna cały swój kod? Jeśli się wypluje z siebie parę
>>> tysięcy linii w ciągu paru tygodni, to na prawdę jest kompletnie
>>> nierealna intelektualna jego kontrola.
>>
>>
>> Tak, pisałem o tym przed chwilą.
>
> Cóż, tylko pogratulować!

Zdolności prekognicji?  Dziękuję :)

>>> A swoją drogą, ciekawe co w tej kwestii, jeśli cokolwiek, dołożą w Py3K.
>>
>>
>> Ja wróciłem do 1.5.2.
>
> Heh, twardo!

Tak na marginesie, RMS postulował kiedyś stworzenie wersji interpretera
Pythona licencjonowanej na GPL.  Wersja ta miałaby być właśnie oparta
na 1.5, która ZTCP była ostatnią GPLowaną wersją GvRa.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 18:59:41 +0200, Karpierz, Adam <adam_karpierz@NOOOSPAAMmentor.com> napisał:

> "Piotr Dembiñski" <pdemb@gazeta.pl> wrote:
>
>>> Jedyn± pewn± metod± jest konstrukcja jêzyka umo¿liwiaj±ca
>>> statycznetypowanie i ¶cis³e wymuszanie typów.
>>
>> Mo¿liwe, jednak Python nie jest w tej chwili takim jêzykiem.
>
> Ale jak najbardziej jest
> Przynajmniej w sensie "scislego wymuszania typow"

Sory, pomyliłem 'konstrukcję języka umożliwiającą statyczne typowanie'
z 'językiem statycznie typowanym' :)

PS. Popraw pliterki.

-- 
http://www.piotr.dembiński.prv.pl

... W dole szumi rzeka, w górze fruwa ptak
A Piotr Dembiński sobie idzie i śpiewa sobie tak:

>>>>> A kto tu mówił o regexpach?
>>>>
>>>> A czytasz wątek?
>>>
>>> Tak. Mówimy chyba o dwóch, zupełnie różnych rzeczach.
>>
>> <d5q0ek$4ad$1@gw.magellan.net.pl>
>>
>> i sprawdź w jaką rozmowę się włączyłeś.
> 
> O narzędziach.
 
Dwa listy przed Twoim była mowa o "nie da sie zrobic skutecznych narzedzi do 
refaktoryzacji" i "mozna co najwyzej regexpami podmieniac na chybil trafil
nazwy metod i klas". W tej samej rozmowie "o narzędziach". I na to
odpowiadałem.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

W laboratorium jądrowym w Darmstadt Pythona używają do przyspieszania 
atomów.

@ 

On 2005-05-14, Adam Twardoch <list.adam@twardoch.com> wrote:
> W laboratorium jądrowym w Darmstadt Pythona używają do przyspieszania 
> atomów.
>
> @ 
A jak - czai się za łukiem akceleratora i do nadlatujących atomów robi BU! ?

BPNMSP

-- 
Marcin Jurczuk, NIC-HDL: MJ1679-RIPE