🚀 go-pugleaf

Dnia Tue, 10 May 2005 11:14:12 +0200, Qertoip <qer1@o2.pl> napisał:

[C# i Python]

> Jestem głodny Waszych uwag na ten temat.

IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,
dlatego wiele rzeczy, o których tutaj piszesz jest niemożliwe
do zrobienia.

Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
kodu w trakcie działania programu?

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

Qertoip napisał(a):

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

A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.

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

Zawsze się da, type(obj) zwraca klasę typu obiektu.

> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.

Eric3 ma wszystko to, czego nie widziałeś. Po prostu masz ograniczoną 
percepcję rzeczywistości.

> Jestem głodny Waszych uwag na ten temat. 

Moim zdaniem nie wiesz, o czym piszesz. Troll?

(Nie było mnie ze 2 tygodnie i pewnie inni już doszli do tego samego, 
ale NMSP)

-- 
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

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

> Dnia Tue, 10 May 2005 11:14:12 +0200, Qertoip <qer1@o2.pl> napisał:
> 
> [C# i Python]
> 
>> Jestem głodny Waszych uwag na ten temat.
> 
> IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,

O nawiasy na pewno ;)


> Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
> kodu w trakcie działania programu?

Tak.


-- 
Pozdr. 
Piotrek

Dnia Tue, 10 May 2005 21:17:22 +0200, Jarek Zgoda napisał(a):

> Qertoip napisał(a):
> 
>> - 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.
> 
> A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.

Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)

 
>> 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).
> 
> Zawsze się da, type(obj) zwraca klasę typu obiektu.

Dajesz odpowiedź na całkiem inny problem. 
type( obj ) można użyć w czasie *wykonania* a nie podczas edycji źródła.
Zwróć uwagę na słowo "statycznie" w moim poście. Przykład niemożności
statycznego ustalenia typu podałem w innym poście w tym wątku.


> Po prostu masz ograniczoną percepcję rzeczywistości.
> [...]
> Moim zdaniem nie wiesz, o czym piszesz. Troll?

Licz się ze słowami.


-- 
Pozdr. 
Piotrek

Dnia Tue, 10 May 2005 22:10:49 +0200, Qertoip napisał(a):

Napisałem:

> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)

A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
http://www.wlodarek.top100.net.pl/ObjectMembersList.png

"Bajer", "pierdółka"? 

Owszem.

Ten bajer ma jednak to do siebie, że zaoszczędza mnóstwo czasu, jeśli
człowiek nie ma używanej biblioteki w małym palcu. Czyli prawie zawsze przy
obecnych potężnych bibliotekach (batteries included).

I dlatego podnoszę tę kwestię w kontekście języków dynamicznie typowanych,
gdzie nie da się jej w pełni zrealizować. Niestety :(


-- 
Pozdr. 
Piotrek

Qertoip napisał(a):

>>>- 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.
>>
>>A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
 >
> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)

Zgłoś ten problem do producenta IDE, nie do samego języka. Język 
udostępnia API do uzyskania takich informacji.

>>>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).
>>
>>Zawsze się da, type(obj) zwraca klasę typu obiektu.
> 
> Dajesz odpowiedź na całkiem inny problem. 
> type( obj ) można użyć w czasie *wykonania* a nie podczas edycji źródła.
> Zwróć uwagę na słowo "statycznie" w moim poście. Przykład niemożności
> statycznego ustalenia typu podałem w innym poście w tym wątku.

W Pythonie nie ma rozróżnienia czasu wykoniania od czasu 
"nie-wykonania", ponieważ jest językiem interpretowanym i nie ma w nim 
możliwości przeprowadzenia "częściowej kompilacji" (tego używają różne 
IDE do ustalenia RTTI).

Zgłoś ten problem do producenta IDE, nie do samego języka. Język 
udostępnia API do uzyskania takich informacji.

>>Po prostu masz ograniczoną percepcję rzeczywistości.
>>[...]
>>Moim zdaniem nie wiesz, o czym piszesz. Troll?
> 
> Licz się ze słowami.

Po prostu nie wiesz, o czym piszesz. Na 100%. Chyba jesteś zwykłym trollem.

-- 
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

Qertoip napisał(a):

> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
> 
> "Bajer", "pierdółka"? 

Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
się od języka. Python nie ma z tym nic wspólnego. Trollu.

-- 
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

Dnia Tue, 10 May 2005 22:35:44 +0200, Jarek Zgoda napisał(a):

>> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
>> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
>> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
>> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
> 
> Zgłoś ten problem do producenta IDE, nie do samego języka. Język 
> udostępnia API do uzyskania takich informacji.

Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce. 
Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.

Problem polega na tym, że:
_nie_zawsze_da_się_ustalić_typ_obiektu_bez_interpretacji_programu_

To prosty paradoks: gdyby się dało, Python nie byłby językiem dynamicznie
typowanym.

Patrz też posty Przemka Wiśniewskiego i Piotra Dembińskiego, zwłaszcza ten
z 2005-05-10 21:59:16.
 

>>>Po prostu masz ograniczoną percepcję rzeczywistości.
>>>[...]
>>>Moim zdaniem nie wiesz, o czym piszesz. Troll?
>> 
>> Licz się ze słowami.
> 
> Po prostu nie wiesz, o czym piszesz. Na 100%. 

Wiem doskonale o czym piszę. 


> Chyba jesteś zwykłym trollem. 

Powtarzam, licz się ze słowami.


-- 
Pozdr. 
Piotrek

Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
>> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
>> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>> 
>> "Bajer", "pierdółka"? 
> 
> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
> się od języka. Python nie ma z tym nic wspólnego. Trollu.

Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.

Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego
IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
dynamicznym sie sprawdzi od reki w interpreterze.

Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
mi tak szybko poszlo. :))

--
JZ

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

> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
> 
> "Bajer", "pierdółka"? 
> 
> Owszem.
> 
> Ten bajer ma jednak to do siebie, że zaoszczędza mnóstwo czasu, jeśli
> człowiek nie ma używanej biblioteki w małym palcu. Czyli prawie zawsze przy
> obecnych potężnych bibliotekach (batteries included).

Akurat w przypadku bibliotek prawdopodobieństwo wsytąpienia problemów takich
jak poprzednio opisywane jest dość niewielkie.
 
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Dnia Tue, 10 May 2005 21:47:37 +0200, Qertoip <qer1@o2.pl> napisał:

[...]

>> IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,
>
> O nawiasy na pewno ;)

O nawiasy to Haskell :)

>> Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
>> kodu w trakcie działania programu?
>
> Tak.

o

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

Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda <jzgoda@gazeta.usun.pl> napisał:

> Qertoip napisał(a):
>
>> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>
>> "Bajer", "pierdółka"?
>
> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
> się od języka. Python nie ma z tym nic wspólnego. Trollu.

Trochę ma.

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

Dnia Tue, 10 May 2005 22:55:21 +0200, Qertoip napisał(a):

> Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce. 
> Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.

Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow dynamicznych.
Masz przyzwyczajenia z jezykow statycznych, ktore powoduja ze widzisz to
jako wade to, ze Python nie jest Java czy C. :) Troche sie pobawisz
Pythonem to zmienisz zdanie. Ja na poczatku to nie moglem przelknac np.
braku klamr dla blokow. Nie wyobrazalem sobie jak kod bez nich moze byc
czytelny. A teraz to sie z tego smieje, bo to co wydawalo mi sie wada
okazalo sie ostatecznie zaleta.

--
JZ

Dnia Tue, 10 May 2005 21:10:19 GMT, JZ napisał(a):

> Dnia Tue, 10 May 2005 22:55:21 +0200, Qertoip napisał(a):
> 
>> Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce. 
>> Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.
> 
> Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow
> dynamicznych.

Widzę głos poparcia! No właśnie: od początku o tym piszę, że taki postulat 
w dynamicznie typowanych językach nie jest w pełni realizowalny.


> Masz przyzwyczajenia z jezykow statycznych, 

Mam. Dlatego też zaangażowałem się w niemały, niebanalny projekty w
Pythonie. Piszę rozproszony interpreter uproszczonego OCCAM2 (zero
centralizacji).


> ktore powoduja ze widzisz to jako wade to, ze Python nie jest Java czy C. :) 

Przeciwnie. Inszość postrzegam jako zaletę, bo pozwala mi spojrzeć na
programowanie z innej strony. 

Ale chyba nie chcesz powiedzieć, że ta "inna strona" ma same zalety,
żadnych wad?


> Ja na poczatku to nie moglem przelknac np. braku klamr dla blokow. 

To akurat podoba mi się od samego początku. Wreszcie jest porządek i
zwięzłość.


-- 
Pozdr. 
Piotrek

Jarek Zgoda napisał(a):

> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
> się od języka. Python nie ma z tym nic wspólnego. Trollu.
> 

Trochę chyba się nie rozumiecie. Jak ktoś już wspomniał, Python nie ma 
szans na przewidywanie typów. Jak dosatajesz coś z funkcji to nie wiesz 
co to jest i po kropce nie ma szans abys dostał podpowiedź. W Javie masz 
deklaracje i wiadomo co wyjdzie z tej funkcji, więc ide wie co 
popowiedzieć. Tworzy to pewną stabilność kodowania ale zmniejsza 
elastyczność. Duży program nigdy nie będzie elastyczny więc stosowanie 
elastcznego języka (Python) trochę tu nie pasuje.

Wszystko to są sprzeczki dla sprzeczek. Python nie podskoczy Javie w 
większych zastosowaniach, java nie podkoczy do pythona w mniejszych 
elastycznych programach. Jest pewien obszar w którym oba te rozwiązania 
mogą ze sobą konkurować.

Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o modelowaniu 
aplikacji a pisanie unitestów to wg nich strata czasu. W javie 
przynajmniej w czasie kompilacji część kodu zostanie sprawdzona.

Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo 
fajny i miekki język, ale czasami wymiękam jak muszę jakieś 
niestandardowe słabo udokumentowane biblioteki używać, które często są w 
fazie alfa a pisza ze stable albo prawie stable.

-- 
Climbus

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

> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo 
> fajny i miekki język, ale czasami wymiękam jak muszę jakieś 
> niestandardowe słabo udokumentowane biblioteki używać, które często są w 
> fazie alfa a pisza ze stable albo prawie stable.

Sam widzisz, ze twoj zarzut nie dotyczy standardowych bibliotek pythona,
ale jskichs trzeciorzednych modulow ktore ktos napisal lepiej albo gorzej.
W zwiazku z tym, ze domyslam sie co masz na mysli, ja bym na twoim miejscu
inaczej postawil problem: "potrzebuje modulu ktory realizuje to i owo, i
nie ma go w stanardowej bibliotece pythona, a te ktore znalazlem sa slabej
jakosci, w fazie alfa, beta itp. Java mi daje do tego bardziej dojrzale
biblioteki ale jest z kolei bardziej skomplikowana i nie ma szans abym
zdazyl od reki tego uzywac." Zycie jest niestety skomplikowane.

--
JZ

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

>> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
>> się od języka. Python nie ma z tym nic wspólnego. Trollu.
> 
> Trochę chyba się nie rozumiecie. Jak ktoś już wspomniał, Python nie ma 
> szans na przewidywanie typów. 

... chyba, że przejdzie opcjonalne typowanie statyczne:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

[---]
> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo 
> fajny i miekki język, ale czasami wymiękam jak muszę jakieś 
> niestandardowe słabo udokumentowane biblioteki używać, które często są w 
> fazie alfa a pisza ze stable albo prawie stable.

Ale to raczej nie jest cecha języka. 

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

JZ napisał(a):
> Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
> 
>>>A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
>>>http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>>
>>>"Bajer", "pierdółka"? 
>>
>>Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
>>się od języka. Python nie ma z tym nic wspólnego. Trollu.
> 
> 
> Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
> Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
> 
> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,

Nasz lokalny guru/autorytet pythona, sir Adam Karpierz sam przytaczal 
wizje wizualnego srodowiska i dzialajacego w nim jezyka jako narzedzia 
przyszlosci.

> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy

Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie 
zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku 
odwala kupe nudnej roboty to cos naprawde pozytecznego.

> Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego
> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo

Ja wole mozliwosci IDE i jezyk bez zadnych ulatwiaczy, z prostymi 
regulami. Wez dla porownania HTML(SGML) i XML - html ma mase ulatwiaczy, 
np: mozna opuszczac cudzyslowy w argumentach, olewac wielkosc liter, 
mozna liczyc na tolerancje przegladarki. Dlugo nie bylo sensownych 
graficznych edytorow HTMLa, pierwszy byl Dreamweaver. Za to xml jest 
bardziej zwarty, mniej tolerancyjny, za to latwiej z nim cokolwiek zrobic.

> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
> dynamicznym sie sprawdzi od reki w interpreterze.

Bzdura.

> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
> mi tak szybko poszlo. :))

Ilosc zagladniec do manuala jako wyznacznik lepszosci jest wrecz smieszna.

-- 
Przemek Wiśniewski

JZ wrote:
> Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
> 
>>>A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
>>>http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>>
>>>"Bajer", "pierdółka"? 
>>
>>Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep 
>>się od języka. Python nie ma z tym nic wspólnego. Trollu.
> 
> 
> Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
> Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
> 
> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do

Ja jestem zorientowany na edytor, joe rules

> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego

Nie prawda! Napisałem i zdebugowałem w życiu wiele tysiący linii kodu w 
C, C++ i Javie bez żadnego IDE.

> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
> Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego

Eee... a Ruby to w ogóle język? ;)

> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore

No tak, jak się ma tonę nielegalnego softu na kompie, to słabo chodzi 
hihihi.

> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
> dynamicznym sie sprawdzi od reki w interpreterze.

Ale sam fakt, że wyłapie, jest nie do przecenienia.

> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
> mi tak szybko poszlo. :))

No to właśnie nikt nie mówi, że python jest do dupy. To przykład na to, 
że nie jest. Ja bym mógł jednak podać przykład dużego softu w pythonie z 
kilkoma niesławnymi kawałkami kodu z zewnątrz, który nie wyszedł... 
chyba wiesz, o co chodzi ;)

Dnia Tue, 10 May 2005 23:05:36 +0200, JZ <fake@spamerom.niet> napisał:

> Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
>>> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>>> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>>
>>> "Bajer", "pierdółka"?
>>
>> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
>> się od języka. Python nie ma z tym nic wspólnego. Trollu.
>
> Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
> Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
>
> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
> sie nie zgubil jak w lesie.

Istnieje pewna granica wielkości problemu, który może być pojęty i zrozumiany
przez pojedynczego programistę.  Różne IDE i języki programowania pozwalają
podnieść tę granicę, ale nic nie pomoże na niekomunikatywnego projektanta
lub programistę, który nie potrafi opowiedzieć, jak działa jego program :)

> W Delphi, C, C# czy Javie bez takiego Eclipse, Visual Studio czy innegoBorlanda to praktycznie nie da sie pisac. Dlatego uzytkownicy takichnarzedzi czuja sie zagubieni jak zobacza Pythona czy Rubiego, gdziedynamika i prostota jezyka powoduje ze posiadanie dobrego IDE (mimo zepozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych jezykow oszczedzajaznacznie wiecej czasu niz by sie to z pozoru moglo wydawac. Zanim takakobyla IDE sie odpali, skompiluje i wypluje bledy ktore potem trzebaszukac w 15x wiekszym kodzie, to czesto szybciej w jezyku dynamicznym siesprawdzi od reki w interpreterze.

Kiedyś programy komputerowe pisało się na kartce papieru, a następnie szło
do centrum obliczeniowego, gdzie po zakodowaniu ten program był wprowadzany
do maszyny.  Co ciekawe, niektórzy spece od inżynierii oprogramowania
(np. Humphrey) twierdzą, że obecnie programy powinno się pisać w podobny
sposób, tzn. najpierw napisać cały program, a dopiero później kompilować --
bez żadnych eksperymentów.

> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
> mi tak szybko poszlo. :))

Tak, skrypty pisze się w Pythonie szybko :)

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

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

[...]

> Nasz lokalny guru/autorytet pythona, sir Adam Karpierz sam przytaczal
> wizje wizualnego srodowiska i dzialajacego w nim jezyka jako narzedzia
> przyszlosci.

IMO można by nieco podejrzeć w środowiskach dla Smalltalka.

>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
>> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
>
> Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie
> zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku
> odwala kupe nudnej roboty to cos naprawde pozytecznego.

W gruncie rzeczy masz rację, tyle że jak się pracuje kreatywnie 8h na dzień,
to jest szansa popełnienia większej liczby błędów, niż w systemie 2h kreatywnie
na 6h niekreatywnie.

[...]

>> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
>> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
>> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
>> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
>> mi tak szybko poszlo. :))
>
> Ilosc zagladniec do manuala jako wyznacznik lepszosci jest wrecz smieszna.

IMO to całkiem dobra miara.  Nie wiem co dokładnie da się tym zmierzyć,
ale całkiem niezła :)

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

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

[...]

>> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
>> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
>
> Ja jestem zorientowany na edytor, joe rules

/me też nie lubi, jak mu edytor przeszkadza w trakcie pisania,
ale funkcja kalkulatora w *scratch* jest git :>

>> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
>> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
>> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
>
> Nie prawda! Napisałem i zdebugowałem w życiu wiele tysiący linii koduw C, C++ i Javie bez żadnego IDE.

IMO debuggery są mnież użyteczne od dobrego zestawu asercji.  Nie mówiąc
o logowaniu czy automatycznych testach jednostkowych.

[...]

>> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
>> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
>> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
>
> No tak, jak się ma tonę nielegalnego softu na kompie, to słabo chodzi
> hihihi.

eklips jest free

>> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
>> dynamicznym sie sprawdzi od reki w interpreterze.
>
> Ale sam fakt, że wyłapie, jest nie do przecenienia.

IMO lepiej dać kod do przejrzenia komuś innemu niż polegać na kompilatorze.

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

Piotr Dembiński wrote:
> Dnia Wed, 11 May 2005 09:44:59 +0200, Przemek Wiśniewski <sdf@fasd.sdf> 
> napisał:
> 
> [...]
> 
>> Nasz lokalny guru/autorytet pythona, sir Adam Karpierz sam przytaczal
>> wizje wizualnego srodowiska i dzialajacego w nim jezyka jako narzedzia
>> przyszlosci.
> 
> 
> IMO można by nieco podejrzeć w środowiskach dla Smalltalka.
> 
>>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. 
>>> Dlatego
>>> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
>>
>>
>> Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie
>> zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku
>> odwala kupe nudnej roboty to cos naprawde pozytecznego.
> 
> 
> W gruncie rzeczy masz rację, tyle że jak się pracuje kreatywnie 8h na 
> dzień,
> to jest szansa popełnienia większej liczby błędów, niż w systemie 2h 
> kreatywnie
> na 6h niekreatywnie.

Podobno programiści, jak by się nie starali, tworzą 20 linii sensownego 
kodu dziennie ;) Więc może cała ta dyskusja nie ma większego sensu, bo i 
tak pewnych rzeczy nie przeskoczymy...

Z drugiej strony, mam takiego kumpla, który kiedyś, jak się z nim przy 
piwie spotkałem wieczorem, to stwierdził, że tego dnia "położył" w 
robocie ponad 1000 linii produkcyjnego kodu w C++. Ale fakt, wyglądał 
jakby po nim czołg przejechał.

Piotr Dembiński wrote:
> Dnia Wed, 11 May 2005 10:16:03 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>>> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela 
>>> sie na
>>> tych zorientowanych na jezyk i tych zorientowanych na edytor, 
>>> narzedzie do
>>
>>
>> Ja jestem zorientowany na edytor, joe rules
> 
> 
> /me też nie lubi, jak mu edytor przeszkadza w trakcie pisania,
> ale funkcja kalkulatora w *scratch* jest git :>
> 
>>> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, 
>>> typow
>>> i innych gadow kod, tym lepszego edytora-pomagacza trzeba 
>>> programiscie aby
>>> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego 
>>> Eclipse,
>>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. 
>>> Dlatego
>>
>>
>> Nie prawda! Napisałem i zdebugowałem w życiu wiele tysiący linii koduw 
>> C, C++ i Javie bez żadnego IDE.
> 
> 
> IMO debuggery są mnież użyteczne od dobrego zestawu asercji.  Nie mówiąc
> o logowaniu czy automatycznych testach jednostkowych.

Różnie to bywa. A w jakim sensie "automatyczne" te testy?

> 
> [...]
> 
>>> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
>>> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
>>> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy 
>>> ktore
>>
>>
>> No tak, jak się ma tonę nielegalnego softu na kompie, to słabo chodzi
>> hihihi.
> 
> 
> eklips jest free

Eee ty dżołka nie kumasz

>>> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
>>> dynamicznym sie sprawdzi od reki w interpreterze.
>>
>>
>> Ale sam fakt, że wyłapie, jest nie do przecenienia.
> 
> 
> IMO lepiej dać kod do przejrzenia komuś innemu niż polegać na kompilatorze.

No to znajdź takiego kto Ci za free przejrzy np. 10k linii w pajtonie 
pod kątem sensowności typów. A kompilatory javy i innych jęz. stat. typ. 
robią to za free!

Piotr Dembiński napisał(a):
> 
>>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. 
>>> Dlatego
>>> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
>>
>>
>> Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie
>> zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku
>> odwala kupe nudnej roboty to cos naprawde pozytecznego.
> 
> 
> W gruncie rzeczy masz rację, tyle że jak się pracuje kreatywnie 8h na 
> dzień,
> to jest szansa popełnienia większej liczby błędów, niż w systemie 2h 
> kreatywnie
> na 6h niekreatywnie.

Nie rozumiem, kreatywnie czyli tworczo, ciekawie i przy okazji 
przyjemnie? Jesli tak to niekreatywne jest w takiej javie reczne 
klepanie getterow i setterow, reczne zmieny nazw pakietow, klas, reczne 
modyfikacje xmlowych plikow z konfiguracjami.. wogole wszsytkie reczne 
robotki, ktore zwyczajnie oglupiaja, a oglupienie i zmeczenie sprzyja 
bledom. Najwiecej bledow popelniam przy nudnych i monotonnych czynnosciach.

-- 
Przemek Wiśniewski

Dnia Tue, 10 May 2005 23:46:47 +0200, Climbus <climbusUSUNTO@barwa.pl> napisał:

[...]

> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo
> fajny i miekki język, ale czasami wymiękam jak muszę jakieś
> niestandardowe słabo udokumentowane biblioteki używać, które często są w
> fazie alfa a pisza ze stable albo prawie stable.

A jpython?

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

Przemek Wiśniewski wrote:
> Piotr Dembiński napisał(a):
> 
>>
>>>> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. 
>>>> Dlatego
>>>> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
>>>
>>>
>>>
>>> Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie
>>> zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku
>>> odwala kupe nudnej roboty to cos naprawde pozytecznego.
>>
>>
>>
>> W gruncie rzeczy masz rację, tyle że jak się pracuje kreatywnie 8h na 
>> dzień,
>> to jest szansa popełnienia większej liczby błędów, niż w systemie 2h 
>> kreatywnie
>> na 6h niekreatywnie.
> 
> 
> Nie rozumiem, kreatywnie czyli tworczo, ciekawie i przy okazji 
> przyjemnie? Jesli tak to niekreatywne jest w takiej javie reczne 
> klepanie getterow i setterow, reczne zmieny nazw pakietow, klas, reczne 
> modyfikacje xmlowych plikow z konfiguracjami.. wogole wszsytkie reczne 

Ej, masz coś do inversion of control i dependency injection? Pythonistas 
jeszcze chyba do tego nie dorośli, bo w większości krzywo na to patrzą...

> robotki, ktore zwyczajnie oglupiaja, a oglupienie i zmeczenie sprzyja 
> bledom. Najwiecej bledow popelniam przy nudnych i monotonnych czynnosciach.

A ogólnie to rację masz

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

[...]

>> IMO debuggery są mnież użyteczne od dobrego zestawu asercji.  Nie mówiąc
>> o logowaniu czy automatycznych testach jednostkowych.
>
> Różnie to bywa. A w jakim sensie "automatyczne" te testy?

import unittest

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

RobertSzefler napisał(a):
>>
>> Nie rozumiem, kreatywnie czyli tworczo, ciekawie i przy okazji 
>> przyjemnie? Jesli tak to niekreatywne jest w takiej javie reczne 
>> klepanie getterow i setterow, reczne zmieny nazw pakietow, klas, 
>> reczne modyfikacje xmlowych plikow z konfiguracjami.. wogole wszsytkie 
>> reczne 
> 
> 
> Ej, masz coś do inversion of control i dependency injection? Pythonistas 
> jeszcze chyba do tego nie dorośli, bo w większości krzywo na to patrzą...

Tzn co mam? Nie mam nic przeciwko, wrecz bardzo lubie, np: w webworku. 
Nie wiem o co dokladnie Ci chodzi.

-- 
Przemek Wiśniewski

Użytkownik "Przemek Wiśniewski" <sdf@fasd.sdf> napisał w wiadomości 
news:d5sd5s$ctc$1@gw.magellan.net.pl...
>> Kiedys czytalem fajny artykul o tym ze generalnie programisci 
>> dziela sie na
>> tych zorientowanych na jezyk i tych zorientowanych na edytor, 
>> narzedzie do
>> tworzenia kodu. Im bardziej spuchniety od tych wszystkich 
>> definicji, typow
>> i innych gadow kod, tym lepszego edytora-pomagacza trzeba 
>> programiscie aby
>> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego 
>> Eclipse,

> Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie 
> zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku 
> odwala kupe nudnej roboty to cos naprawde pozytecznego.

Stanowisko hardkorowych pythonowców jest chyba takie:

1. Jeżeli IDE musi odwalać w źródle "kupę nudnej roboty", to znaczy, 
że z tym źródłem coś jest nie tak. Kod napisany w Pythonie 
teoretycznie w ogóle nie powinien zawierać kawałków do pisania 
bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym 
przykładem są standardowe gettery i settery: w javowych IDE są często 
generowane automatycznie, w pythonowych IDE nie są, ale ich użycie 
jest w ogóle błędem.

2. Dlatego kod generowany przez IDE kwalifikuje się jako antywzorzec 
"copy&paste programming"

3. Obiektowość jest fajna, ale nie jest srebrną kulą. Jeżeli ciągle 
potrzebujemy dokumentacji do obiektów, metod i atrybutów, to znaczy, 
że prawdopodobnie nadużywamy jednego z narzędzi oferowanych przez 
Python (tzn. tak naprawdę piszemy w Javie używając pythonowej składni 
;-)

4. Trudność intelektualna programowania nie wynika z kłopotów z 
użyciem zewnętrznych bibliotek, tylko z immanentnej trudności 
problemu, który próbujemy rozwiązać. Dlatego ekspresywność języka jest 
znacznie ważniejsza niż ułatwienia przy budowaniu GUI itp.

5. Jednym z najmocniejszych narzędzi programistycznych jest 
programowanie abstrahujące od typów - w C++ zaimplementowane 
szablonami i aktywnie wprowadzane do Javy. Przy tego rodzaju 
programowaniu podpowiadanie typów zupełnie nie ma sensu. A nawet nie 
zapuszczając się tak daleko: głupi polimorfizm połączony z 
wielodziedziczeniem czyni podpowiadanie typów i listowanie zawartości 
obiektów bezsensownym.

Wniosek: można się przyzwyczaić do tego, co oferują IDE, można to 
nawet lubić; ale nie można absolutyzować własnych gustów i lekceważyć 
środowisk i języków opartych na innej filozofii.

pozdrawiam,
Filip 

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

[--- ciach ładnie opisana filozofia (nie tylko) Pythona ---]
> Wniosek: można się przyzwyczaić do tego, co oferują IDE, można to 
> nawet lubić; ale nie można absolutyzować własnych gustów i lekceważyć 
> środowisk i języków opartych na innej filozofii.

Klap. Klap. Klap. Brawo.
 
> Filip 

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

Filip Dreger wrote:
> Użytkownik "Przemek Wiśniewski" <sdf@fasd.sdf> napisał w wiadomości 
> news:d5sd5s$ctc$1@gw.magellan.net.pl...
> 
>>>Kiedys czytalem fajny artykul o tym ze generalnie programisci 
>>>dziela sie na
>>>tych zorientowanych na jezyk i tych zorientowanych na edytor, 
>>>narzedzie do
>>>tworzenia kodu. Im bardziej spuchniety od tych wszystkich 
>>>definicji, typow
>>>i innych gadow kod, tym lepszego edytora-pomagacza trzeba 
>>>programiscie aby
>>>sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego 
>>>Eclipse,
> 
> 
>>Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie 
>>zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku 
>>odwala kupe nudnej roboty to cos naprawde pozytecznego.
> 
> 
> Stanowisko hardkorowych pythonowców jest chyba takie:
> 
> 1. Jeżeli IDE musi odwalać w źródle "kupę nudnej roboty", to znaczy, 
> że z tym źródłem coś jest nie tak. Kod napisany w Pythonie 
> teoretycznie w ogóle nie powinien zawierać kawałków do pisania 
> bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym 
> przykładem są standardowe gettery i settery: w javowych IDE są często 
> generowane automatycznie, w pythonowych IDE nie są, ale ich użycie 
> jest w ogóle błędem.
> 
> 2. Dlatego kod generowany przez IDE kwalifikuje się jako antywzorzec 
> "copy&paste programming"
> 
> 3. Obiektowość jest fajna, ale nie jest srebrną kulą. Jeżeli ciągle 
> potrzebujemy dokumentacji do obiektów, metod i atrybutów, to znaczy, 
> że prawdopodobnie nadużywamy jednego z narzędzi oferowanych przez 
> Python (tzn. tak naprawdę piszemy w Javie używając pythonowej składni 
> ;-)
> 
> 4. Trudność intelektualna programowania nie wynika z kłopotów z 
> użyciem zewnętrznych bibliotek, tylko z immanentnej trudności 
> problemu, który próbujemy rozwiązać. Dlatego ekspresywność języka jest 
> znacznie ważniejsza niż ułatwienia przy budowaniu GUI itp.
> 
> 5. Jednym z najmocniejszych narzędzi programistycznych jest 
> programowanie abstrahujące od typów - w C++ zaimplementowane 
> szablonami i aktywnie wprowadzane do Javy. Przy tego rodzaju 
> programowaniu podpowiadanie typów zupełnie nie ma sensu. A nawet nie 
> zapuszczając się tak daleko: głupi polimorfizm połączony z 
> wielodziedziczeniem czyni podpowiadanie typów i listowanie zawartości 
> obiektów bezsensownym.

Jeśli masz na myśli dziedziczenie wielobazowe, to jesteś skrzywiony ;)

> 
> Wniosek: można się przyzwyczaić do tego, co oferują IDE, można to 
> nawet lubić; ale nie można absolutyzować własnych gustów i lekceważyć 
> środowisk i języków opartych na innej filozofii.
> 
> pozdrawiam,
> Filip 
> 
> 

Filip Dreger napisał(a):
> Użytkownik "Przemek Wiśniewski" <sdf@fasd.sdf> napisał w wiadomości 
> news:d5sd5s$ctc$1@gw.magellan.net.pl...
> 
>>>Kiedys czytalem fajny artykul o tym ze generalnie programisci 
>>>dziela sie na
>>>tych zorientowanych na jezyk i tych zorientowanych na edytor, 
>>>narzedzie do
>>>tworzenia kodu. Im bardziej spuchniety od tych wszystkich 
>>>definicji, typow
>>>i innych gadow kod, tym lepszego edytora-pomagacza trzeba 
>>>programiscie aby
>>>sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego 
>>>Eclipse,
> 
> 
>>Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie 
>>zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku 
>>odwala kupe nudnej roboty to cos naprawde pozytecznego.
> 
> 
> Stanowisko hardkorowych pythonowców jest chyba takie:
> 
[..]

Racja, bo w IDE mozna co najwyzej wyklikac GUI.

-- 
Przemek Wiśniewski

Filip Dreger napisał(a):
> bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym 
> przykładem są standardowe gettery i settery: w javowych IDE są często 
> generowane automatycznie, w pythonowych IDE nie są, ale ich użycie 
> jest w ogóle błędem.
Mozna prosic o rozwiniecie?


Pozdrawiam
Beorn

Daniel Mróz wrote:
> Filip Dreger napisał(a):
> 
>> bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym
>> przykładem są standardowe gettery i settery: w javowych IDE są często
>> generowane automatycznie, w pythonowych IDE nie są, ale ich użycie
>> jest w ogóle błędem.
> 
> Mozna prosic o rozwiniecie?

W Pajtonie używamy atrybutów dostępnych globalnie, zamiast setterów i
getterów.

Jeśli chcemy zmiecić wiek pracownika e, to robimy e.age = 14, a nie
e.setage(14). To jest naturalne, ponieważ to co chcemy zrobić, to jest:
"zmienić wartość e.age", a nie "wywołać metodę e ustawiającą wiek z
parametrem 14". Zamiast deklarować atrybut i pisać dwie metody nie
piszemy właściwie nic (inicjalizacja może się przytać, ale w Javie też
jest inicjalizacja, więc faktycznie oszczędzamy czas pisania trzech
elementów klasy - a to tylko najprostszy możliwy przykład).

Jeśli zajdzie potrzeba wzbogacenia klasy o jakieś działania przy
ustawianiu atrybutu, to dodajemy sobie property(getter, setter) zamiast
tego atrybutu.

Tak się jednak składa, że baardzo często atrybut to atrybut i nigdy już
go nie będziemy "ulepszać" i pozostanie sobie globalny.


Ogólnie rzecz biorąc Python ma pewną filozofię. Zakłada ona przede
wszystkim prostotę języka i bezpośrednie dążenie do osiągnięcia celu
najprostszą i najkrótszą drogą, która jednocześnie jest już (dzięki
filozofii) najlepsza.

W Javie też moglibyśmy używać atrybutów globalnych, ale gdyby zaszła w
przyszłości konieczność owinięcia ich w jakieś akcje, to zmiana
interfejsu klasy popsuła by pół projektu.

Z drugiej strony oczywiście Python nie uchroni nas przed np. literówkami
przy wywołaniach metod - na etapie kompilacji bajtkodu nie wiadomo, czy
metoda ta będzie istniała, czy nie (można często zgadywać, ale nie jest
to taka pewna sprawa, jak w językach (nazwijmy to) statycznych, takich
jak Java).

Żeby tak naprawdę wiedzieć, które podejście jest lepsze, należy pewnie
po prostu poprogramować sporo w obu językach.

Przejście z jednego do drugiego języka może być nieco bolesne, ponieważ
wiąże się ze zmianą filozofii programowania.

Pytanie na grupie pythonowej dlaczego Python jest dobry mimo, że jest
inny niż Java zawsze będzie prowadziło do małego flamewara, bo
Pythonowcy już coś dla siebie w typ Pythonie znaleźli (przez
doświadczenia z językiem) i będą mówić o jego zaletach, co u Javowca
będzie budziło naturalny opór, bo dla niego rewelacje Pythonowców są
herezjami jakimiś.
W drugą stronę pewnie bywa podobnie.

Nie ma chyba innej możliwości, niż spróbować dowiedzieć się jak
najwięcej z dyskusji, ale potraktować ją *tylko* jako wstęp - a
prawdziwe rozeznanie przeprowadzić osobiście, sam na sam z językiem.


Pozdrawiam!
Maciej

Maciej Pietrzak napisał(a):
>>>bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym
>>>przykładem są standardowe gettery i settery: w javowych IDE są często
>>>generowane automatycznie, w pythonowych IDE nie są, ale ich użycie
>>>jest w ogóle błędem.
>>Mozna prosic o rozwiniecie?
> Jeśli chcemy zmiecić wiek pracownika e, to robimy e.age = 14, a nie
> e.setage(14). To jest naturalne, ponieważ to co chcemy zrobić, to jest:
> "zmienić wartość e.age", a nie "wywołać metodę e ustawiającą wiek z
> parametrem 14". Zamiast deklarować atrybut i pisać dwie metody nie
No tak, ale co z kontrola poprawnosci danych? setage() moze nam 
sprawdzic czy przypadkiem ktos zamiast 14 nie przekazuje "czternascie".


Pozdrawiam
Beorn

-- 
Contrary to what some people say, my OS _is_ a lifestyle choice, not a 
tool; however, I am against osizm
Użytkownik "Daniel Mróz" <beorn@alpha.pl> napisał w wiadomości 
news:d5v2tv$4l7$1@news.supermedia.pl...
> Filip Dreger napisał(a):
>> bezmyślnego (w pisaniu zmyślnym IDE nie pomaga wcale). Dobrym 
>> przykładem są standardowe gettery i settery: w javowych IDE są 
>> często generowane automatycznie, w pythonowych IDE nie są, ale ich 
>> użycie jest w ogóle błędem.
> Mozna prosic o rozwiniecie?

Odwołania do atrybutów i metod są drogie - każde kosztuje jeden lukap 
w haszu. Taka jest cena za dynamiczne typowanie. Owinięcie atrybutu w 
gettera/settera wymaga dwóch przeszukań słownika zamiast jednego, co 
może znacznie spowolnić program (szczególnie taki o dużej ilości 
kleju, a małej ilości logiki).
Z drugiej strony, nagrodą za typowanie dynamiczne jest możliwość 
przecięcia (trochę jak w programowaniu aspektowym) czynności takich 
jak sprawdzanie atrybutów obiektu. Dzięki temu w Pythonie można (nawet 
dynamicznie) podmienić atrybut na metodę w sposób przezroczysty dla 
pozostałego kodu. Robi się to jednak dopiero wtedy, kiedy jest to 
rzeczywiście potrzebne, a nie - jak w Javie - na wszelki wypadek.
Inna sprawa, że wielu programistów javowych przenosi swoje nawyki na 
Pythona, a potem narzeka na jego prędkość. W sumie to tak, jakby kupić 
sobie samochód i narzekać, że nie ma dyszla i trudno do niego konia 
zaprzęgać. Ostatnio widziałem program w Pythonie (zresztą grę typu 
roguelike), napisany przez gościa co to "programuje od dziesięciu lat 
w Javie i Pythonie i dlatego wie co mówi, kiedy oświadcza, że Python 
jest za wolny do aplikacji graficznych". W grze mamy klasę bazową 
'przedmiot' i całą kupę dziedziczących po niej piętrowo klas, 
różniących się na przykład dodaniem pojedynczego atrybutu. Np. klasa 
'przedmiot, który ma cenę' różni się od klasy 'przedmiot' obecnością 
jednego dodatkowego i rzadko używanego atrybutu 'cena' (i oczywiście 
jest zdefiniowana w osobnym pliku :-). W zasadzie można tak zrobić, 
ale w Pythonie jest to podejście kiepskie - większość atrybutów i 
metod obiektu 'przedmiot z ceną' wymaga wtedy przy odwołaniu do nich 
nie - jednego, a dwóch przeszukan słownika. W pierwszym przeszukaniu 
znajdzie się tylko atrybut najrzadziej wykorzystywany, bo specyficzny 
dla jednego rodzaju 'przedmiotu'. Naturalniejsze byłoby po prostu 
dodanie do obiektów klasy przemiot dodatkowych atrybutów, w miarę 
potrzeby.
W wypadku głębiej zagnieżdżonych klas we wspomnianej przeze mnie grze 
dochodziło do tego, że sprawdzenie współrzędnych x i y przedmiotu 
wymagało np. sześciu przeszukań słownika, bardziej pythonowa 
implementacja zmieściłaby się w jednym!
Dodatkowo, autor wykorzystał wiel zagnieżdżonych przestrzeni nazw, 
zawierających np. coś w rodzaju stałych, dodając kilka przeszukań 
słownika do operacji, które w ogóle powinny się bez nich obyć. Koniec 
końców, w programie napisanym przez "eksperta od Javy i Pythona" 
niektóre proste operacje (w rodzaju pobrania pozycji przedmiotu na 
mapie) wymagają dwunastu (liczyłem!) przeszukań słownika...

Zastrzegam, że nie czuję się faszystą - uwaga o zaprzęganiu konia do 
samochodu odnosi się także do sytuacji przeciwnej, czyli prób używania 
Javy do pisania zgodnego z filozofią Pythona.

pozdrawiam,
Filip 

Użytkownik "Daniel Mróz" <beorn@alpha.pl> napisał w wiadomości 
news:d5v7fu$75t$1@news.supermedia.pl...
>> Jeśli chcemy zmiecić wiek pracownika e, to robimy e.age = 14, a nie
>> e.setage(14). To jest naturalne, ponieważ to co chcemy zrobić, to 
>> jest:
>> "zmienić wartość e.age", a nie "wywołać metodę e ustawiającą wiek z
>> parametrem 14". Zamiast deklarować atrybut i pisać dwie metody nie
> No tak, ale co z kontrola poprawnosci danych? setage() moze nam 
> sprawdzic czy przypadkiem ktos zamiast 14 nie przekazuje 
> "czternascie".
to, co dodają IDE, to puste settery i gettery, nie przeprowadzające 
żadnej walidacji. Ich funkcja jest inna i związana z rozwijaniem 
programu.
Jeśli w Javie uznamy, że nie potrzebujemy żadnej walidacji i 
udostępnimy klientowi goły atrybut, to - można powiedzieć - 
przegraliśmy. Nie mamy żadnej metody, żeby walidację wprowadzić 
później. A jeśli na przykład będziemy musieli dodać do aplikacji 
logowanie każdej zmiany wieku? zgroza! Dlatego właśnie powstał prosty 
wzorzec projektowy - atrybuty opakowujemy w settery i gettery, które 
na razie nic nie robią, ale pozwolą nam w przyszłości na rozwój 
aplikacji.
W ten sposób każdy atrybut klasy napisanej w Javie wymaga około 
czterech linijek nic nie robiącego kodu. Nic dziwnego, że właśnie w 
Javowym środowisku wyrosła koncepcja złożonych IDE - puste settery i 
gettery są po prostu watą, której pisaniem rzeczywiście nie powinien 
zajmować się programista.
W Pythonie jest inaczej. Jeżeli potrzebujemy atrybutu age, to dodajemy 
atrybut age, a nie metodę. To wszystko. Jeśli kiedyś będziemy chcieli 
dodać logowanie zmian wieku i walidację, zmienimy definicję age na
age=property(getage,setage)
i dopiszemy getage i setage Ale to dopiero w razie potrzeby.
Oznacza to, że unikamyw naszych źródłach waty, czyli nic nie 
znaczącego kodu (którym w Javie zarządza IDE). Dzięki temu program 
jest szybszy, łatwiejszy do rozwijania i zrozumiały bez protezy na 
oczy, jaką bywają nowoczesne edytory.

pozdrawiam,
Filip 

Użytkownik "Climbus" <climbusUSUNTO@barwa.pl> napisał w wiadomości 
news:d5radb$l8c$1@nemesis.news.tpi.pl...

> Wszystko to są sprzeczki dla sprzeczek. Python nie podskoczy Javie w 
> większych zastosowaniach, java nie podkoczy do pythona w mniejszych 
> elastycznych programach. Jest pewien obszar w którym oba te 
> rozwiązania mogą ze sobą konkurować.
>
> Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o 
> modelowaniu aplikacji a pisanie unitestów to wg nich strata czasu. W 
> javie przynajmniej w czasie kompilacji część kodu zostanie 
> sprawdzona.
>
> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to 
> bardzo fajny i miekki język, ale czasami wymiękam jak muszę jakieś 
> niestandardowe słabo udokumentowane biblioteki używać, które często 
> są w fazie alfa a pisza ze stable albo prawie stable.

Ideą towarzyszącą Pythonowi od samego początku była łatwość łączenia 
Pythona z C. Mi się zdarza na przykład korzystać z interpretera 
Pythona jako z biblioteki C z szybkimi haszami (to kiedy rozmiar 
egzeka nie ma znaczenia, czyli dość często :-). Twardych bibliotek 
jest dla C/C++ co najmniej tyle, co dla Javy, poza tym są z reguły 
szybsze.podłączenie ich do Pythona jest też trywialne.
W ogóle fajnie zaczynać pisanie większych aplikacji od podziału na 
część hardkorową i klej, a potem napisanie tej pierwszej w C, drugiej 
w Pythonie. Czy się mylę, czy Guido tak właśnie widział podstawowe 
uzycie swojego języka za tzw. dawnych czasów?

pozdrawiam,
Filip 

Qertoip wrote:


> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
> 
> "Bajer", "pierdółka"? 

Ale, heh, co to jest za przykład? Co on ma pokazywać tak naprawdę?
W pedivtu4nyre$.1wvgjjhuk1780$.dlg@40tude.net podałeś przykład
w Pythonie:


def f(a):
    return a

p = True
if p:
    obj = f(1)
else:
    obj = f("")

obj.???

co Twoje IDE powiedziałoby na coś takiego?

class Testowa  {
    class A {
        void a1() {}
        void a2() {}
    }
    class B {
        void b1() {}
        void b2() {}
    }

    static object make_foo(string arg) {
    if(arg == "1")
        return new A();
    else
        return new B();
    }

    public static void Main(string[] args) {
        object foo = make_foo(args[0]);
        foo.? // O, to ta linijka
    }
}

darek

Darek Suchojad wrote:
> Qertoip wrote:
> 
> 
> 
>>A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota: 
>>http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>
>>"Bajer", "pierdółka"? 
> 
> 
> Ale, heh, co to jest za przykład? Co on ma pokazywać tak naprawdę?
> W pedivtu4nyre$.1wvgjjhuk1780$.dlg@40tude.net podałeś przykład
> w Pythonie:
> 
> 
> def f(a):
>     return a
> 
> p = True
> if p:
>     obj = f(1)
> else:
>     obj = f("")
> 
> obj.???
> 
> co Twoje IDE powiedziałoby na coś takiego?
> 
> class Testowa  {
>     class A {
>         void a1() {}
>         void a2() {}
>     }
>     class B {
>         void b1() {}
>         void b2() {}
>     }
> 
>     static object make_foo(string arg) {
>     if(arg == "1")
>         return new A();
>     else
>         return new B();
>     }
> 
>     public static void Main(string[] args) {
>         object foo = make_foo(args[0]);
>         foo.? // O, to ta linijka
>     }
> }
> 
> darek


To ty nie czytasz dokładnie tego wątku. Dużo już pisaliśmy o tym 
problemie, a to, co podałeś, nie jest dowodem na słabość języka, tylko 
programisty i można to zrobić w chyba każdym języku z klasami/obiektami. 
Nie w tym sęk.

RobertSzefler wrote:


> To ty nie czytasz dokładnie tego wątku.

Ano nie czytam na bieżąco. Skończyłem po

d5radb$l8c$1@nemesis.news.tpi.pl

"""
Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o modelowaniu
aplikacji a pisanie unitestów to wg nich strata czasu. W javie
przynajmniej w czasie kompilacji część kodu zostanie sprawdzona.
"""

Opadły mi ręce.


> Dużo już pisaliśmy o tym
> problemie, a to, co podałeś, nie jest dowodem na słabość języka, tylko
> programisty i można to zrobić w chyba każdym języku z klasami/obiektami.

Nie miało to być dowodem na słabość C#, tylko pytaniem o to, jak zachowa
się IDE. Temat cały czas nosi tytuł "Największy problem Pythona",
a te dwa największe problemy to
(cytuję jsq2enrcpp4r$.nmpn8bgh83ge.dlg@40tude.net)

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

O pierwszej sprawie nie będę się wypowiadał, bo jest z gatunku
"mam wrażenie, że...", "wydaje mi się, że...".

Druga dla mnie jest jasna i chciałem po prostu pokazać, że nie trzeba
statycznej kompilacji do tego.

darek

Darek Suchojad wrote:

>>Dużo już pisaliśmy o tym
>>problemie, a to, co podałeś, nie jest dowodem na słabość języka, tylko
>>programisty i można to zrobić w chyba każdym języku z klasami/obiektami.
> 
> 
> Nie miało to być dowodem na słabość C#, tylko pytaniem o to, jak zachowa
> się IDE. Temat cały czas nosi tytuł "Największy problem Pythona",
> a te dwa największe problemy to
> (cytuję jsq2enrcpp4r$.nmpn8bgh83ge.dlg@40tude.net)
> 
> """
> - 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.
> """
> 
> O pierwszej sprawie nie będę się wypowiadał, bo jest z gatunku
> "mam wrażenie, że...", "wydaje mi się, że...".
> 
> Druga dla mnie jest jasna i chciałem po prostu pokazać, że nie trzeba
> statycznej kompilacji do tego.

Co tu ma C# do rzeczy?

A ten drugi problem nie jest taki prosty, jak powyżej napisane i gdybyś 
czytał wątek to by Ci ręce nie opadały ;)

> """
> Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o modelowaniu
> aplikacji a pisanie unitestów to wg nich strata czasu. W javie
> przynajmniej w czasie kompilacji część kodu zostanie sprawdzona.
> """
> 
> Opadły mi ręce.

mi też po taka jest prawda. I nie chcę tu nikogo obrażać bo jest wielu 
bardzo dobrych programistów pythona czy php. Poprzez to że języki te są 
łatwe i dopuszczają pewną swobodę wielu początkujących programistów 
pisze jak pisze i (zgaduje) może być ich procentowo więcej niż dobrych 
programistów. Java, C itp mają trochę większe wymagania i trzeba trochę 
wiedziec, żeby w nich programować. Tworzy to pewną barierę wejśćia.

Widziłałem trochę programistów PHP'a i prawie nikogo nie spotkałem kto 
by robił unitesty czy modelował aplikacje. Spotkalem też i takich co 
wiedzą co to jest inzynieria oprogramowania. Niestety tych drugich jest 
o wiele, wiele mniej.

Ale to wszystko moje prywatne zdanie, do którego mam prawo:)

climbus wrote:

>> """
>> Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o modelowaniu
>> aplikacji a pisanie unitestów to wg nich strata czasu. W javie
>> przynajmniej w czasie kompilacji część kodu zostanie sprawdzona.
>> """
>>
>> Opadły mi ręce.
> 
> 
> mi też po taka jest prawda. I nie chcę tu nikogo obrażać bo jest wielu
> bardzo dobrych programistów pythona czy php. Poprzez to że języki te są
> łatwe i dopuszczają pewną swobodę wielu początkujących programistów
> pisze jak pisze i (zgaduje) może być ich procentowo więcej niż dobrych
> programistów. Java, C itp mają trochę większe wymagania i trzeba trochę
> wiedziec, żeby w nich programować. Tworzy to pewną barierę wejśćia.

Jasne, ale wiesz, napisałeś to wtedy inaczej. Dodałeś też, że w trakcie
kompilacji część kodu jest sprawdzana. Okej, ale w Pythonie masz
pycheckera i pylinta.

> Widziłałem trochę programistów PHP'a i prawie nikogo nie spotkałem kto
> by robił unitesty czy modelował aplikacje. Spotkalem też i takich co
> wiedzą co to jest inzynieria oprogramowania. Niestety tych drugich jest
> o wiele, wiele mniej.

Nie znam PHP i nie używam, ale przypuszczam, że jest tak jak wszędzie,
dla jednych testy to fanaberie, dla innych to normalka.

> Ale to wszystko moje prywatne zdanie, do którego mam prawo:)

Jak najbardziej.

darek

Darek Suchojad wrote:
>>Widziłałem trochę programistów PHP'a i prawie nikogo nie spotkałem kto
>>by robił unitesty czy modelował aplikacje. Spotkalem też i takich co
>>wiedzą co to jest inzynieria oprogramowania. Niestety tych drugich jest
>>o wiele, wiele mniej.
> 
> 
> Nie znam PHP i nie używam, ale przypuszczam, że jest tak jak wszędzie,
> dla jednych testy to fanaberie, dla innych to normalka.

Hehe, dobrze że nie znasz i nie radzę poznawać :D [taki mały linguafaszyzm]

W PHP po prostu się eleganckiego, zrozumiałego kodu napisać nie da, a 
faktem jest, że większość implementacji jest kiepskiej jakości też 
(m.in. dlatego, że unit-testy też trudno pisać itd itd czyli zamknięte 
koło heh)

> Jasne, ale wiesz, napisałeś to wtedy inaczej.

Jak inaczej zabrzmiało to przepraszam.


> Nie znam PHP i nie używam, ale przypuszczam, że jest tak jak wszędzie,
> dla jednych testy to fanaberie, dla innych to normalka.

niestety tych od fanaberii jest więcej

RobertSzefler wrote:

> Co tu ma C# do rzeczy?

Nie mam Javy na podorędziu, no i Qertoip rozpoczął ten wątek porównując
Pythona z .NETem.

> A ten drugi problem nie jest taki prosty, jak powyżej napisane i gdybyś
> czytał wątek to by Ci ręce nie opadały ;)

Nie nie, ręce mi opadły przy tej generalizacji o "Pythonowcach i
PHPowcach." Ale spoko, już podniosłem :-)

darek

Dnia Thu, 12 May 2005 14:37:23 +0200, RobertSzefler napisał(a):

> W PHP po prostu się eleganckiego, zrozumiałego kodu napisać nie da, 

Da sie, tylko trzeba wiedziac jak.

--
JZ

JZ wrote:
> Dnia Thu, 12 May 2005 14:37:23 +0200, RobertSzefler napisał(a):
> 
> 
>>W PHP po prostu się eleganckiego, zrozumiałego kodu napisać nie da, 
> 
> 
> Da sie, tylko trzeba wiedziac jak.

Polemizowałbym ale mi się nie chce ;)