Interpretowany czy kompilowany?
Borneq
interpretowanym czy kompilowanym? Jak z prędkością?
Szyk
> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
> interpretowanym czy kompilowanym? Jak z prędkością?
Oczywiście, że interpretowany! W dodatku z dynamicznym typowaniem.
Prędkość... hm... tu nie o to chodzi! Tu chodzi o to, by napisać szybko,
elegancko i odpalić, zająć się czymś innym i jak skończy cieszyć się
wynikami. W takich zadaniach widzę ten język. Choć są tacy co takie
języki wykorzystują do generowania stron html w czasie rzeczywistym (ta
praktyka nie jest gorsza od używania PHP, jednak obie są równie zboczone
(w sęsie koncepcyjnym)). Zasadniczo wąskim gardłem tego typu języków
jest to, że przed użyciem każdej zmiennej konieczne jest określenie jej
typu (dynamiczne typowanie). Choć z drugiej strony to dynamiczne
typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy
programowaniu.
Jacek Czerwinski
> Choć z drugiej strony to dynamiczne
> typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy
> programowaniu.
W sztywno typowanym (choć z odśmiecaniem) języku robiłem upgrade o
'duży' numer wersji sporego frameworku pod wielką moją aplikacją. Po
usunięciu błędów kompilacji zostały DWA proste wyjątki na runtime i trzy
moduły 100 linii w sposób oczywisty niskopoziomowe więc do koncepcyjnych
ręcznych zmian.
Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
'pierwszego' pisania, ale refactoringu to horror.
Przychylam się do wizji i czasem ją realizuję: 'kernel' w sztywnym i
skryptowanie funkcjonalności zmiennych czy dodatkowych w dynamicznym
PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i świadomie
projektowany język.
Stachu 'Dozzie' K.
[...]
> PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i świadomie
> projektowany język.
Z wyjątkiem trójki, gdzie kretyńsko wsadzili wszędzie UTF-8 (np. gdy
argument wiersza poleceń nie jest UTF, to nawet nie masz jak chwycić
wyjątku).
--
Secunia non olet.
Stanislaw Klekot
Rob Wolfe
> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
> interpretowanym czy kompilowanym?
Język nie zna pojęć interpretowany czy kompilowany.
Pytanie jaką implementacją się chcesz zainteresować?
Jeśli tą najbardziej popularną implementacją w C, czyli CPythonem,
to kod jest _kompilowany_ do byte codu, który to jest następnie
_interpretowany_.
$ python2.5 -m py_compile test.py
$ file test.pyc
test.pyc: python 2.5 byte-compiled
Jednak kompilacja na ogół odbywa się automatycznie, także nie ma
potrzeby wykonywania jej ręcznie (jak powyżej).
Jak wybierzesz implementacje Pythona na JVM (Jython) lub CLR
(IronPython), to wówczas Python jest _kompilowany_ do byte codu
tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
to także _kompilowany_ do kodu natywnego.
> Jak z prędkością?
W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
jest np. Mercurial (http://mercurial.selenic.com/).
RW
Rob Wolfe
> W dniu 2011-05-14 22:29, Szyk pisze:
>
>> Choć z drugiej strony to dynamiczne
>> typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy
>> programowaniu.
>
> W sztywno typowanym (choć z odśmiecaniem) języku robiłem upgrade o
> duży' numer wersji sporego frameworku pod wielką moją aplikacją. Po
> usunięciu błędów kompilacji zostały DWA proste wyjątki na runtime i
> trzy moduły 100 linii w sposób oczywisty niskopoziomowe więc do
> koncepcyjnych ręcznych zmian.
Czy robiłeś coś podobnego z frameworkiem Pythonowym i napotkałeś jakieś
niesamowite problemy?
> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
> pierwszego' pisania, ale refactoringu to horror.
Działają mi na nerwy tego typu opinie. Brałem udział w refactoringu
róznych rzeczy w róznych językach, typowanych dynamicznie i statycznie
i nie zauważyłem, aby ten akurat element był tu jakoś specjalnie
istotny.
Usunięcie błędów kompilacji nie dowodzi niczego. Ogarnięcie kodu
w sensie zrozumienia meritum w językach statycznie typowanych bywa
strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
Javie).
Oczywiście jest też masa beznadziejnego kodu napisana w Pythonie,
ale jest go przynajmnie naście jeśli nie dziesiąt razy mniej.
>
> Przychylam się do wizji i czasem ją realizuję: 'kernel' w sztywnym i
> skryptowanie funkcjonalności zmiennych czy dodatkowych w dynamicznym
Robię tak, gdy chodzi o poprawienie wydajności, ale statyczne typowanie
nie ma tu dla mnie najmniejszego znaczenia.
>
> PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i
> świadomie projektowany język.
I dzięki temu jest szansa, że zwykly śmiertelnik może zrozumieć
o co w danym programie chodzi, a to już ogromny sukces.
RW
Wojciech Muła
> > Jak z prędkością?
>
> W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
> rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> jest np. Mercurial (http://mercurial.selenic.com/).
Dodam tylko, że tworzenie od podstaw modułów rozszerzeń jest całkiem
proste. Istnieje także cyton, wariant pythona w którym łącznie kodu
z C jest jeszcze prostsze: http://docs.cython.org/.
Do tego wszystkiego w std. pythonie jest moduł ctypes, który umożliwia
wywoływanie dowolnych funkcji z bibliotek dzielonych, więc
teoretycznie można zapomnieć o C.
w.
Jacek Czerwinski
> Borneq<bor...@antyspam.hidden.pl> writes:
>
>> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
>> interpretowanym czy kompilowanym?
>
> Język nie zna pojęć interpretowany czy kompilowany.
teoretycy by się burzyli, ale zwykle pytanie tzw "praktyków" o
kompilowanie ma dwa podteksty:
a) szybkościowy. Tu by dodał, że np kod bliski maszynowemu ale często
przełączalny do dynamicznie rozwiązawanych subalgorytmów (np. typowo
dynamiczna gospodarka zmiennymi) jest hamowany tak mocno, że w praktyce
ma szybkośc interpretera.
b) poziom sprawdzeń na etapie kompilacji. Może być rygorystycznie
sprawdzany ale "kompilowany" (w cudzysłowie lub bez zależnie od
upodobań) nie do maszynowego jak oczekuje pytający, tylko do p-kodu
podlegającemu interpretacji w maszynie wirtualnej. Tu należało byś
ściśle mówić o typowaniu.
Chyba różnica językowa jest tu problemem.
Aha, jeszcze
c) czyli stopień zabezpieczenia kodu źródłowego przez disasemblerami,
czyli niemożność przywrócenia z wersji wykonywalnej do w miarę czytelnej
źródłowej. Ja wiem, różnica jest ilościowa (w wielkości pracy) a nie
jakościowa (da się/nie da), ale czasem jest to sens pytania.
Jacek Czerwinski
> Jacek Czerwinski<x...@y.z.pl> writes:
>
> Działają mi na nerwy tego typu opinie. Brałem udział w refactoringu
> róznych rzeczy w róznych językach, typowanych dynamicznie i statycznie
> i nie zauważyłem, aby ten akurat element był tu jakoś specjalnie
> istotny.
Dla mnie jest.
Dodałbym możliwość wspomagania refaktoringu / nie w narzędziach.
> Usunięcie błędów kompilacji nie dowodzi niczego.
Hmmmm.
Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla
mnie chociaż nie wyłącznie Java >=5).
W pełni się zgodzę na gruncie np. C, kompilacja nie dowodzi niczego.
Zastrzegam, moja własna opinia programisty z "przemysłu" a nie hiper
korporacji/uniwerków.
> Ogarnięcie kodu
> w sensie zrozumienia meritum w językach statycznie typowanych bywa
> strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
> Javie).
jest to słuszne stwierdzenie.
Bym porównał (w szerokim sensie) do niemieckiego, może tekstu nie
rozumiesz, nudny, bez polotu, rozbierasz na atomy i rozumiesz
(przeciwstawiając angielskiemu: bez błysku intuicji (i znajomości
idiomów) nie ruszysz)
Piotr Siudak
> Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla
> mnie chociaż nie wyłącznie Java >=5).
Wybacz ale w twoim wypadku wypowiedź o tym że java rzadzi niczym nie
zaskakuje, ale jezeli już chesz sie wypowiadać w temacie jezykw
typowanych statycznie vs. typowanych dynamicznie i nie masz ochoty
obrazać swoich czytelników zdobądź się na to by uzyc arumentu.
--
Piotr Siudak
siu...@xz.pl
zbr...@tlen.pl
> Jacek Czerwinski<x...@y.z.pl> writes:
>> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
>> pierwszego' pisania, ale refactoringu to horror.
>
> w sensie zrozumienia meritum w językach statycznie typowanych bywa
> strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
> Javie).
Masz rację i nie masz ;)
Oczywiście brak błędów kompilacji w żaden sposób nie dowodzi że kod
jesgt poprawny. Niemniej przy dużym refaktoringu pozwala wyłapać
oczywiste błędy. Jeśli kompilator krzyczy że jest niezgodność typów to
nie ma bata, coś musi być spieprzone.
W pythonie wszystko pozornie zabangla bardzo ładnie, tylko czasami
będziemy się dowiadywać, że "list object has no attribute keys" lub coś
podobnego ;)
Bardzo lubię pythona za łatwość w pisaniu kodu, ale czasami przydałaby
się możliwość właczenia sztywniejszej kontroli kodu. (W erlangu jest coś
podobnego, choć osobiście z tego nie jeszcze korzystałem).
Pzdr
]J.
Stachu 'Dozzie' K.
> Usunięcie błędów kompilacji nie dowodzi niczego. Ogarnięcie kodu
> w sensie zrozumienia meritum w językach statycznie typowanych bywa
> strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
> Javie).
> Oczywiście jest też masa beznadziejnego kodu napisana w Pythonie,
> ale jest go przynajmnie naście jeśli nie dziesiąt razy mniej.
Ale nie z powodu dynamicznego typowania. W Adzie i Haskellu
beznadziejnego kodu jest jeszcze mniej.
Rob Wolfe
> On 15.05.2011 19:23, Rob Wolfe wrote:
>
> > Jacek Czerwinski<x...@y.z.pl> writes:
> >> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
> >> pierwszego' pisania, ale refactoringu to horror.
>
> > Usunięcie błędów kompilacji nie dowodzi niczego. Ogarnięcie kodu
> > w sensie zrozumienia meritum w językach statycznie typowanych bywa
> > strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
> > Javie).
>
> Masz rację i nie masz ;)
> Oczywiście brak błędów kompilacji w żaden sposób nie dowodzi że kod
> jesgt poprawny.
Otoz to.
> Niemniej przy dużym refaktoringu pozwala wyłapać
> oczywiste błędy. Jeśli kompilator krzyczy że jest niezgodność typów to
> nie ma bata, coś musi być spieprzone.
Oczywiste bledy w Pythonie mozna wylapac rownie latwo.
> W pythonie wszystko pozornie zabangla bardzo ładnie, tylko czasami
> będziemy się dowiadywać, że "list object has no attribute keys" lub coś
> podobnego ;)
Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
statycznej analizy bez zadnego problemu.
$ cat test.py
lst = []
lst.keys()
$ pylint -E test.py
************* Module test
E: 2: Instance of 'list' has no 'keys' member
>
> Bardzo lubię pythona za łatwość w pisaniu kodu, ale czasami przydałaby
> się możliwość właczenia sztywniejszej kontroli kodu. (W erlangu jest coś
> podobnego, choć osobiście z tego nie jeszcze korzystałem).
Statyczna analiza, ogarniecie tematu oraz testy, testy, testy...
to jest doskonale polaczenie.
Chyba ze dwa pokolenia programistow musza wyginac,
aby przestala obowiazywac zlota zasada: "it compiles, ship it!". ;)
RW
zbr...@tlen.pl
> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> statycznej analizy bez zadnego problemu.
>
> $ cat test.py
> lst = []
> lst.keys()
> $ pylint -E test.py
> ************* Module test
> E: 2: Instance of 'list' has no 'keys' member
Takie też?
def a(b):
print b.keys()
x = []
a(x)
Tyle w temacie statycznej analizy.
Pzdr
J.
Rob Wolfe
Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
Wspominałem też o testach, które by tu pasowały jak ulał.
Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
typy pomagały. Wręcz przeciwnie, muszę się narzeźbić jak debil,
aby zadowolić kompilator, a w podziękowaniu dostaję segmentation fault.
Natomiast często słyszę jak to w Pythonie można zrobić głupią literówkę
i szukać naście dni. To jest kompletna bzdura i z tym walczę.
RW
Stachu 'Dozzie' K.
> zbr...@tlen.pl writes:
>
>> On 16.05.2011 15:49, Rob Wolfe wrote:
>>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
>>> statycznej analizy bez zadnego problemu.
>>>
>>> $ cat test.py
>>> lst = []
>>> lst.keys()
>>> $ pylint -E test.py
>>> ************* Module test
>>> E: 2: Instance of 'list' has no 'keys' member
>>
>> Takie też?
>>
>> def a(b):
>> print b.keys()
>>
>> x = []
>> a(x)
>>
>>
>> Tyle w temacie statycznej analizy.
>
> Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
w Javie.
> Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> Wspominałem też o testach, które by tu pasowały jak ulał.
> Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.
> Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> typy pomagały.
A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
projektach?
> Wręcz przeciwnie, muszę się narzeźbić jak debil,
> aby zadowolić kompilator, a w podziękowaniu dostaję segmentation fault.
Urban legend.
Łukasz Rekucki
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-16, Rob Wolfe <r...@smsnet.pl> wrote:
>
>
>
>
>
>
>
>
>
> > zbro...@tlen.pl writes:
>
> >> On 16.05.2011 15:49, Rob Wolfe wrote:
> >>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> >>> statycznej analizy bez zadnego problemu.
>
> >>> $ cat test.py
> >>> lst = []
> >>> lst.keys()
> >>> $ pylint -E test.py
> >>> ************* Module test
> >>> E: 2: Instance of 'list' has no 'keys' member
>
> >> Takie też?
>
> >> def a(b):
> >> print b.keys()
>
> >> x = []
> >> a(x)
>
> >> Tyle w temacie statycznej analizy.
>
> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>
> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
> w Javie.
W C++ bardzo często nieistniejące, a wiadomości o błędach siegają
wielu ekranów nic nie znaczącego bełkotu kompilatora.
> > > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> > Wspominałem też o testach, które by tu pasowały jak ulał.
> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>
> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.
1. Jak ktoś chce, to może i w Pythonie, np.: http://threecheck.sourceforge.net/
2. Jeśli iść tą drogą, to Java czy C++ sprawdzają bardzo mało.
Porównaj z np. Haskell'em. Dla fanatyków jest Epigram (http://www.e-
pig.org/). Tam każdy program poprawnie otypowany jest na 100%
poprawny. Trochę może ci zająć napisanie programu liczącego 100-tną
cyfrę rozwinięcia PI, no ale jak już napiszesz...
>
> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> > typy pomagały.
>
> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
> projektach?
Takie argumenty raczej nie prowadzą do merytorycznej
---
Łukasz Rekucki
Stachu 'Dozzie' K.
>> >> def a(b):
>> >> print b.keys()
>>
>> >> x = []
>> >> a(x)
>>
>> >> Tyle w temacie statycznej analizy.
>>
>> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>>
>> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
>> w Javie.
>
> W C++ bardzo często nieistniejące, a wiadomości o błędach siegają
> wielu ekranów nic nie znaczącego bełkotu kompilatora.
Parse error. Nieistniejące co? I przykład poproszę.
> 2. Jeśli iść tą drogą, to Java czy C++ sprawdzają bardzo mało.
> Porównaj z np. Haskell'em.
Znam, widziałem. Haskell jest znany z bardzo silnego systemu typów (co
ma zresztą więcej języków funkcyjnych). Ale nie mówimy o tym jak silny
jest system typowania, tylko czy statyczny.
A ty odłóż apostrof, bo sobie nim krzywdę zrobisz.
http://poradnia.pwn.pl/lista.php?id=6142
>> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
>> > typy pomagały.
>>
>> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
>> projektach?
>
> Takie argumenty raczej nie prowadzą do merytorycznej
Chcę ocenić wiedzę dyskutanta, skoro już powiedział że "on nie widział
tego w praktyce".
Rob Wolfe
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-16, Rob Wolfe <r...@smsnet.pl> wrote:
>
>
>
>
>
>
>
>
>
> > zbro...@tlen.pl writes:
>
> >> On 16.05.2011 15:49, Rob Wolfe wrote:
> >>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> >>> statycznej analizy bez zadnego problemu.
>
> >>> $ cat test.py
> >>> lst = []
> >>> lst.keys()
> >>> $ pylint -E test.py
> >>> ************* Module test
> >>> E: 2: Instance of 'list' has no 'keys' member
>
> >> Takie też?
>
> >> def a(b):
> >> print b.keys()
>
> >> x = []
> >> a(x)
>
> >> Tyle w temacie statycznej analizy.
>
> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>
> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
> w Javie.
>
Wiem jak w C++ i Javie. Juz pisalem w skrocie: "it compiles, shipt
it!".
Co z tego wynika, ze mi kompilator powie, ze typ sie zgadza?
Zupelnie nic. Czy nie jest czasem tak, ze operacje na tym typie
moga sie nie powiesc? Czy np. w przypadku polimorfizmu
moze zostac wywolana zupelnie inna metoda, niz sie spodziewales?
I milion innych rzeczy... No, ale sie skompilowalo! Great!
> > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> > Wspominałem też o testach, które by tu pasowały jak ulał.
> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>
> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.
>
Da sie kosztem, ktory imho jest kompletnie nie do przyjecia.
> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> > typy pomagały.
>
> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
> projektach?
>
C++ i Javy, w projektach sporych mysle (ok 500 kloc).
Moge odwrocic pytanie. Jak duzy soft pisales w jezyku dynamicznie
typowanym
i jakim, aby twierdzic, ze sa do pisania duzych systemow gorsze?
Ludzie czesto argumentuja, ze w przypadku duzych systemow z "legacy"
kodem
bez statycznego typowania, to tylko szalency by probowali cos robic.
Mam do czynienia z takim systemem i napatrzylem sie dosc
na cudowne mozliwosci statycznego typowania.
Nie zabieralbym glosu w tej sprawie, gdyby nie to ze bralem udzial tez
w projektach czysto pythonowych (ostatnio ok 50 kloc) i nie tesknilem
ani przez moment za statycznym typowaniem.
> > Wręcz przeciwnie, muszę się narzeźbić jak debil,
> > aby zadowolić kompilator, a w podziękowaniu dostaję segmentation fault.
>
> Urban legend.
Ok, dyskusja zmierza w kierunku dobrze znanym. Oba obozy sa mocno
okopane
i nic nie wskazuje, abym ja kogos przekonal albo ktos mnie.
Takze z mojej strony EOT.
RW
Stachu 'Dozzie' K.
>> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>>
>> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
>> w Javie.
> Wiem jak w C++ i Javie. Juz pisalem w skrocie: "it compiles, shipt
> it!".
> Co z tego wynika, ze mi kompilator powie, ze typ sie zgadza?
> Zupelnie nic.
Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
branie implikacji za równoważność.
"Jeśli program jest dobry, to typy się zgadzają."
Odwracając implikację:
"Jeśli typy się nie zgadzają, to program nie jest dobry."
> Czy nie jest czasem tak, ze operacje na tym typie
> moga sie nie powiesc? Czy np. w przypadku polimorfizmu
> moze zostac wywolana zupelnie inna metoda, niz sie spodziewales?
> I milion innych rzeczy... No, ale sie skompilowalo! Great!
Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.
>> > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
>> > Wspominałem też o testach, które by tu pasowały jak ulał.
>> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>>
>> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.
> Da sie kosztem, ktory imho jest kompletnie nie do przyjecia.
A kto ci tak nakłamał że jest nie do przyjęcia?
>> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
>> > typy pomagały.
>>
>> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
>> projektach?
> C++ i Javy, w projektach sporych mysle (ok 500 kloc).
> Moge odwrocic pytanie. Jak duzy soft pisales w jezyku dynamicznie
> typowanym
> i jakim, aby twierdzic, ze sa do pisania duzych systemow gorsze?
30kloc, przy zmieniającym się frameworku o który projekt był oparty.
Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
poprawce uruchamiać aplikację ponownie.
> Ludzie czesto argumentuja, ze w przypadku duzych systemow z "legacy"
> kodem
> bez statycznego typowania, to tylko szalency by probowali cos robic.
Ludzie może i tak, ale ja niekoniecznie. Tylko nie lubię gdy ktoś
próbuje wmawiać publice że statyczne typowanie jest psu na budę, kiedy
widziałem że pomaga.
> Mam do czynienia z takim systemem i napatrzylem sie dosc
> na cudowne mozliwosci statycznego typowania.
Please elaborate.
jacek2v
On 17 Maj, 15:22, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
> branie implikacji za równoważność.
>
> "Jeśli program jest dobry, to typy się zgadzają."
> Odwracając implikację:
> "Jeśli typy się nie zgadzają, to program nie jest dobry."
Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest duża
szansa, że kompilator skompiluje :)
> Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
> sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
> programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.
A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
mniej :)
Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
nie obroni :)
> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
> poprawce uruchamiać aplikację ponownie.
No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
wtedy i Święty Typ Najwyższy nie pomoże :)
> Ludzie może i tak, ale ja niekoniecznie. Tylko nie lubię gdy ktoś
> próbuje wmawiać publice że statyczne typowanie jest psu na budę, kiedy
> widziałem że pomaga.
Dla każdego coś innego :)
A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
jednocześnie czytelną składnią. Polecam porównanie http://shootout.alioth.debian.org/.
Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
czytania, mniej miejsc do popełnienia błędów itd.
Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
przekraczanie 80 znaków w linii :) Potem zobaczyłem C# i wpadłem w
przerażenie :D
Pzdr.
Stachu 'Dozzie' K.
>> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
>> branie implikacji za równoważność.
>> "Jeśli program jest dobry, to typy się zgadzają."
>> Odwracając implikację:
>> "Jeśli typy się nie zgadzają, to program nie jest dobry."
> Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest duża
> szansa, że kompilator skompiluje :)
Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
>> Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
>> sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
>> programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.
> A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> mniej :)
1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
(dla webaplikacji to może być skopiowanie na serwer testowy,
przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
ekranu którego kod chcesz sprawdzić).
2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
w blokach kontrolnych?
Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
> Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
> nie obroni :)
Eeeee... że co?
>> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
>> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
>> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
>> poprawce uruchamiać aplikację ponownie.
> No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
> Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
> wtedy i Święty Typ Najwyższy nie pomoże :)
Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
> A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
> skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
> jednocześnie czytelną składnią.
A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
wpływu na długość kodu w większych projektach.
> Polecam porównanie http://shootout.alioth.debian.org/.
> Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
> czytania, mniej miejsc do popełnienia błędów itd.
> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> przekraczanie 80 znaków w linii :)
To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).
Adam Byrtek
> Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla
> mnie chociaż nie wyłącznie Java >=5).
Polecam poniższy esej Bruce'a Eckela (autora m.in. Thinking in Java):
https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk&pli=1
Pozdrawiam,
Adam
Adam Byrtek
> Ale nie z powodu dynamicznego typowania. W Adzie i Haskellu
> beznadziejnego kodu jest jeszcze mniej.
Haskell to rozumiem, ale poważnie żyje jeszcze ktoś, kto pisze w Adzie?
Pozdrawiam,
Adam
Jacek Czerwinski
Ja tam zawsze "wyjętą z pudełka" Eclipse przestawiam na 120zn. Ale
zgubiłem się, nie wiem czy jestem za, czy przeciw ;)
zbr...@tlen.pl
>
> Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
> Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> Wspominałem też o testach, które by tu pasowały jak ulał.
Pokrycie testami 100% kodu ze wszystkim ścieżkami jest dosyć trudne.
Przykład ze stosunkowo małego systemiku:
Była sobie struktura danych, która pierwotnie zawierała kilka wartości
("kilka" jak wiadomo to przedział <0..3> ) ;) i była zwyczajną listą. Na
pewnym etapie tych wartości skokowo przybyło i żeby się nie gubić co
jest gdzie, podjęto decyzję że zamiast listy będzie słownik. Wykonano
mały refactoring.
Gdzieś była funkcja, która musiała przejechać się po wartościach z
otrzymanej struktury. Pierwotnie iterowała po liście, teraz iterowała po
values() ze słownika. Testy odpalone i było git.
Po jakimś czasie zanotowano pad. Co się okazało? W innym miejscu była
sobie zapomniana funkcja generująca w pewnych (rzadkich) przypadkach
defaulty dla struktury. I ona dalej generowała listę. Ta funkcja też
była pokryta testem, ale był to inny zestaw testów i też przez
zapomnienie nie został przerobiony. I dla niego poprawnym wynikiem była
wygenerowana lista, a nie dict. :(
Banalny błąd. Powiesz że coś takiego nie powinno się zdarzać. Ale
niestety czasami się zdarza.
> Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
Kontrolowanie w runtime ma tę wadę, że odbywa się w runtime ;).
Dla usera jest w zasadzie obojętne, czy dostanie kawał traceback-a, czy
okienko dialogowe z informacją "Funkcja foo_shmoo_bar_extended otrzymała
nieprawidłowy parametr wywołania: powinien być <type 'dict'>, jest <type
'list'>".
Ważne że program nie bangla.
>
> Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> typy pomagały. Wręcz przeciwnie, muszę się narzeźbić jak debil,
> aby zadowolić kompilator,
Ja nie neguję, że w pythonie pisze się łatwiej i szybciej. I przyjemniej ;)
Za to przy refactoringu bywa na odwrót.
> Natomiast często słyszę jak to w Pythonie można zrobić głupią literówkę
> i szukać naście dni. To jest kompletna bzdura i z tym walczę.
Pewnie że bzdura. Niemniej w pythonie _można_ zrobić literówkę i przy
dużym braku szczęścia objawi się na produkcji.
Pzdr
J.
jacek2v
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-17, jacek2v <jace...@gmail.com> wrote:
>
> >> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
> >> branie implikacji za równoważność.
> >> "Jeśli program jest dobry, to typy się zgadzają."
> >> Odwracając implikację:
> >> "Jeśli typy się nie zgadzają, to program nie jest dobry."
> > Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest duża
> > szansa, że kompilator skompiluje :)
>
> Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
"Poprawne" ponieważ oba stwierdzenia nic nie mówią o sile "typowania".
> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> > mniej :)
>
> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
> (dla webaplikacji to może być skopiowanie na serwer testowy,
> przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
> ekranu którego kod chcesz sprawdzić).
Nigdy i tak musisz uruchomić, taki jest cel programowania, czym
szybciej masz możliwość weryfikacji poprzez uruchomienie tym lepiej.
Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
przeglądarki - automat po kliknięciu na link.
Mhh, pojawiło mi się pytanie, czy kiedykolwiek robiłeś webaplikację w
oparciu o języki pokroju Python?
> 2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
> automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
> Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
> w blokach kontrolnych?
I tak to trzeba robić - może nie wszystkie ścieżki, ale testy/skrypty
testowe trzeba zrobić i puszczać po każdej integracji - unit testy i
testy symulacji użytkownika. A potem i tak najlepiej "napuścić"
testera :)
> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
> > Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
> > nie obroni :)
>
> Eeeee... że co?
Prosty przykład: kod pocztowy. Można napisać klasę, a można trzymać w
stringu.
> >> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
> >> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
> >> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
> >> poprawce uruchamiać aplikację ponownie.
> > No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
> > Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
> > wtedy i Święty Typ Najwyższy nie pomoże :)
>
> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
dużo "bezrozumnego" poprawiania kodu.
> > A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
> > skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
> > jednocześnie czytelną składnią.
>
> A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
> czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
> wpływu na długość kodu w większych projektach.
Napisałem "A tak poza wątkiem" - wybiórcze czytanie? :)
Nie będę polemizował czy zwięzłość kodu ma coś do rzeczy z jego
ilością :) - bo dla mnie to oczywista oczywistość :)
BTW: tematem wątku jest "interpretowany czy kompilowany", a drugie
pytanie autora to "jak z prędkością?" :)
>
> > Polecam porównaniehttp://shootout.alioth.debian.org/.
> > Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
> > czytania, mniej miejsc do popełnienia błędów itd.
> > Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> > przekraczanie 80 znaków w linii :)
>
> To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
> tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
> bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
> A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
> na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).
Możliwe, ale Visual Studio generuje spagetti po pierwszym
kliknięciu :)
Jacek
jacek2v
> W dniu 2011-05-17 21:03, Stachu 'Dozzie' K. pisze:
>
> >> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> >> przekraczanie 80 znaków w linii :)
>
> > To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
> > tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
> > bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
> > A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
> > na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).
>
> Ja tam zawsze "wyjętą z pudełka" Eclipse przestawiam na 120zn. Ale
> zgubiłem się, nie wiem czy jestem za, czy przeciw ;)
lol
Borneq
> (IronPython), to wówczas Python jest _kompilowany_ do byte codu
> tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
> to także _kompilowany_ do kodu natywnego.
> W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
> rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> jest np. Mercurial (http://mercurial.selenic.com/).
Ja ściągnąłem pythona z www.python.org - według tego co napisane w
podręczniku "Zanurkuj w Pythonie", czy to jest CPython. Rozszerzania w C
to dobra sprawa.
Czy jest jakiś debugger do Pythona?
jacek2v
> W dniu 2011-05-15 19:08, Rob Wolfe pisze:
>
> > Jak wybierzesz implementacje Pythona na JVM (Jython) lub CLR
> > (IronPython), to wówczas Python jest _kompilowany_ do byte codu
> > tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
> > to także _kompilowany_ do kodu natywnego.
> > W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
> > rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> > jest np. Mercurial (http://mercurial.selenic.com/).
>
> podręczniku "Zanurkuj w Pythonie", czy to jest CPython. Rozszerzania w C
> to dobra sprawa.
> Czy jest jakiś debugger do Pythona?
Np. http://docs.python.org/library/pdb.html?highlight=debuger
Większość edytorów/środowisk ma wsparcie do debugowania - ja używam
wing.
BTW: Ale tak szczerze to mógłbyś bardziej zgłębić zasoby www.python.org
- tam jest wszystko, a nawet więcej :P
Dobre miejsce do startu: http://wiki.python.org/moin/BeginnersGuide.
Pzdr.
Stachu 'Dozzie' K.
>> >> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
>> >> branie implikacji za równoważność.
>> >> "Jeśli program jest dobry, to typy się zgadzają."
>> >> Odwracając implikację:
>> >> "Jeśli typy się nie zgadzają, to program nie jest dobry."
>> > Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest duża
>> > szansa, że kompilator skompiluje :)
>> Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
> Właściwie do obu - a jak chcesz wybrać jednego to do drugiego :)
> "Poprawne" ponieważ oba stwierdzenia nic nie mówią o sile "typowania".
Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
systemu typów.
>> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
>> > mniej :)
>> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>> (dla webaplikacji to może być skopiowanie na serwer testowy,
>> przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>> ekranu którego kod chcesz sprawdzić).
> Nigdy i tak musisz uruchomić,
Parse error.
> taki jest cel programowania, czym
> szybciej masz możliwość weryfikacji poprzez uruchomienie tym lepiej.
Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
dochodzi ci praktycznie za darmo.
> Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> przeglądarki - automat po kliknięciu na link.
A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>> 2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
>> automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
>> Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
>> w blokach kontrolnych?
> I tak to trzeba robić - może nie wszystkie ścieżki, ale testy/skrypty
> testowe trzeba zrobić i puszczać po każdej integracji - unit testy i
> testy symulacji użytkownika. A potem i tak najlepiej "napuścić"
> testera :)
A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
o których nikt nie pamięta i co do których nikt nie pomyślał żeby
napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
*wszędzie*.
>> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
>> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
> Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
budowania softu: do opuszczenia zbioru dopuszczalnych wyników.
>> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
> Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
> spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
> dużo "bezrozumnego" poprawiania kodu.
Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
dynamicznym nie masz tej informacji podczas kompilacji.
>> > A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
>> > skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
>> > jednocześnie czytelną składnią.
>> A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
>> czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
>> wpływu na długość kodu w większych projektach.
> Napisałem "A tak poza wątkiem" - wybiórcze czytanie? :)
> Nie będę polemizował czy zwięzłość kodu ma coś do rzeczy z jego
> ilością :) - bo dla mnie to oczywista oczywistość :)
Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
jaki jest wpływ samej składni na długość kodu. Bo większość operacji
w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
a idiomów używa się sporadycznie.
jacek2v
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
> dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
> systemu typów.
Wydawało mi się, że cały czas o tym mówisz - o wyższości języka z
typowaniem, czyli o jego "sile" . Ale możliwe, że Cię źle
zrozumiałem :)
> >> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> >> > mniej :)
> >> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
> >> (dla webaplikacji to może być skopiowanie na serwer testowy,
> >> przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
> >> ekranu którego kod chcesz sprawdzić).
> > Nigdy i tak musisz uruchomić,
>
> Parse error.
Mhh, a ja zawsze myślałem, że programy się pisze by je uruchamiać. No
cóż, ale istnieje też trend zwany "sztuka dla sztuki" :)
> Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
> typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
> dochodzi ci praktycznie za darmo.
Nie za darmo. Trzeba wszędzie pisać explicite typ, a to sporo kodu
więcej.
> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> > przeglądarki - automat po kliknięciu na link.
>
> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
tam gdzie jest większy budżet.
Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
> *wszędzie*.
Ale i tak kompilator nie wyłapie znacznej większości błędów, a
świadomość, że trzeba testować jest lepsza niż życie w błędnym
przekonaniu, że coś samo się sprawdzi i będzie ok.
> >> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
> >> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
> > Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
>
> Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
> budowania softu: do opuszczenia zbioru dopuszczalnych wyników.
To był Twój pomysł, aby nie testować - nie dokręcaj kota ogonem :)
> >> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
> > Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
> > spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
> > dużo "bezrozumnego" poprawiania kodu.
>
> Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
> dynamicznym nie masz tej informacji podczas kompilacji.
A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
też się zorientuje - zwłaszcza, że bardzo często używa się
rzutowania?
> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
> a idiomów używa się sporadycznie.
Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
że mam pojęcie przekrojowe :)
Ostatniego Twojego zadanie nie zrozumiałem, sorry :)
Stachu 'Dozzie' K.
> On 20 Maj, 10:24, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>> Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
>> dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
>> systemu typów.
>
> Wydawało mi się, że cały czas o tym mówisz - o wyższości języka z
> typowaniem, czyli o jego "sile" .
Eeee... Że co? Co ma siła typowania do statyczności typowania?
>> >> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
>> >> > mniej :)
>> >> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>> >> (dla webaplikacji to może być skopiowanie na serwer testowy,
>> >> przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>> >> ekranu którego kod chcesz sprawdzić).
>> > Nigdy i tak musisz uruchomić,
^^^
>> Parse error.
>
> Mhh, a ja zawsze myślałem, że programy się pisze by je uruchamiać.
Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
używać więcej znaków interpunkcyjnych.
A uruchomienie programu do testów może być (i zwykle jest) bardziej
kłopotliwe niż kompilacja.
>> Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
>> typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
>> dochodzi ci praktycznie za darmo.
>
> Nie za darmo. Trzeba wszędzie pisać explicite typ, a to sporo kodu
^^^^^^^^^^
> więcej.
Eeee... Nie? A dostajesz w zamian kontrolę typów. Proponuję przyjrzeć
się dowolnemu programowi dowolnego języka ze statycznym typowaniem
i policzyć, ile kodu, tak na literki, jest przeznaczone na deklaracje
typów.
>> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
>> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
>> > przeglądarki - automat po kliknięciu na link.
>>
>> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
>> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
>> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>
> Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
> Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
> Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
> wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
> tam gdzie jest większy budżet.
Tam, gdzie wymagania niezawodnościowe są dużo wyższe, to akurat się unika
testowania, zastępując je formalną automatyczną weryfikacją. Testy nie
są tak niezawodne jak próbujesz przedstawiać, nie dają gwarancji
poprawności programu. Zautomatyzowana weryfikacja (przy której
weryfikacja typów to tylko preludium do wstępu) za to daje.
> Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
Nie. Ale może się zdarzyć że testy, które przygotowałeś, nie pokryją
wszystkich możliwych sytuacji. Kompilator jest za to dokładniejszy.
>> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
>> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
>> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
>> *wszędzie*.
>
> Ale i tak kompilator nie wyłapie znacznej większości błędów, a
> świadomość, że trzeba testować jest lepsza niż życie w błędnym
> przekonaniu, że coś samo się sprawdzi i będzie ok.
Ależ świadomość nadal jest. Weryfikacja typu nie wychwyci błędu
logicznego. Za to wychwyci dużo typowych błędów, co już samo w sobie
pomaga.
Powiedziałbym że to raczej odwrotnie jest: zaufanie testowaniu daje ci
w błędne przekonanie, że program zawsze dobrze działa i inna weryfikacja
jest niepotrzebna.
>> >> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
>> >> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
>> > Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
>>
>> Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
>> budowania softu: do opuszczenia zbioru dopuszczalnych wyników.
>
> To był Twój pomysł, aby nie testować - nie dokręcaj kota ogonem :)
Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
czego prowadzi i że to nic dobrego.
>> >> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
>> > Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
>> > spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
>> > dużo "bezrozumnego" poprawiania kodu.
>>
>> Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
>> dynamicznym nie masz tej informacji podczas kompilacji.
>
> A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
> też się zorientuje - zwłaszcza, że bardzo często używa się
> rzutowania?
Zależy czy ta wyższa czy niższa jest niezbędna, czy też nie. W ogóle nie
rozumiem pytania i problemu, który byś chciał pokazać. Please elaborate.
>> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
>> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
>> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
>> a idiomów używa się sporadycznie.
>
> Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
> trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
> że mam pojęcie przekrojowe :)
Bo wiesz, jakoś nie widzę tego po tobie.
> Ostatniego Twojego zadanie nie zrozumiałem, sorry :)
Rozumiem że chodzi o to:
#v+
Bo większość operacji w przeciętnym kodzie źródłowym tłumaczy się wprost
na inne języki, a idiomów używa się sporadycznie.
#v-
Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
programowania) mające znaczenie tylko w danym języku, na ogół trudne do
przełożenia na inny język za pomocą jednej instrukcji. Na przykład
idiomem w Pythonie jest konstruowanie tablicy za pomocą
"[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".
W przypadku programowania, większość kodu to instrukcje warunkowe,
pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
wbudowanej).
Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
a w dużej części z pozostałych, typowych dla danego paradygmatu
instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
program w Perlu i taki sam w Pythonie będą miały podobną długość.
Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
nie przekłada się specjalnie na długość kodu.
Powiem ci że parę lat temu też uważałem że ilość idiomów pozytywnie
wpływa na ilość kodu i jego konserwowalność, ale z doświadczeniem się
z tego przekonania wyrasta.
jacek2v
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> Eeee... Że co? Co ma siła typowania do statyczności typowania?
"Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
niema.
>
>
> Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
> używać więcej znaków interpunkcyjnych.
Aha :) Zapomniałeś włączyć w kompilatorze logikę rozmytą? :)
> A uruchomienie programu do testów może być (i zwykle jest) bardziej
> kłopotliwe niż kompilacja.
Ale konieczne.
> Eeee... Nie? A dostajesz w zamian kontrolę typów. Proponuję przyjrzeć
> się dowolnemu programowi dowolnego języka ze statycznym typowaniem
> i policzyć, ile kodu, tak na literki, jest przeznaczone na deklaracje
> typów.
Liczyłem. Jak Twoje wyniki? Wg moich sporo więcej :P
> >> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> >> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> >> > przeglądarki - automat po kliknięciu na link.
>
> >> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
> >> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
> >> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>
> > Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
> > Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
> > Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
> > wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
> > tam gdzie jest większy budżet.
>
> Tam, gdzie wymagania niezawodnościowe są dużo wyższe, to akurat się unika
> testowania, zastępując je formalną automatyczną weryfikacją. Testy nie
> są tak niezawodne jak próbujesz przedstawiać, nie dają gwarancji
> poprawności programu. Zautomatyzowana weryfikacja (przy której
> weryfikacja typów to tylko preludium do wstępu) za to daje.
A co to "formalną automatyczną weryfikacją"?
Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
kodu).
> > Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
>
> Nie. Ale może się zdarzyć że testy, które przygotowałeś, nie pokryją
> wszystkich możliwych sytuacji. Kompilator jest za to dokładniejszy.
I na pewno się tak zdarzy, gwarantuję :) Użytkownicy są
nieobliczalni :D
A kompilator jest i Python :) Zapewne miałeś na myśli, że kompilator
sprawdzi typy, ale jak już mówiłem, moim zdaniem złudne to poczucie
sprawdzenia. A ja wolę nie mieć złudzeń :)
> >> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
> >> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
> >> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
> >> *wszędzie*.
>
> > Ale i tak kompilator nie wyłapie znacznej większości błędów, a
> > świadomość, że trzeba testować jest lepsza niż życie w błędnym
> > przekonaniu, że coś samo się sprawdzi i będzie ok.
>
> Ależ świadomość nadal jest. Weryfikacja typu nie wychwyci błędu
> logicznego. Za to wychwyci dużo typowych błędów, co już samo w sobie
> pomaga.
Weryfikacja typu wychwyci jedynie błąd typu i nic więcej.
Moja praktyka jest taka, że zawsze błąd typu jest wykrywany po
pierwszym uruchomieniu poprawianego kodu. I tak każdy moduł/funkcja/
metoda przez programistę jest dziesiątki (jeśli nie setki razy)
uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
Żeby uprzedzić argumenty o zmiennych warunkach wykonania i że ścieżka
wykonania jest niedeterministyczna, chciałby zwrócić Twoją uwagę, że
Python nie jest językiem "nie typowanym" jest językiem "dynamicznie
typowanym", czyli typowanie ma, tylko nie jest ono podawane explicite.
> Powiedziałbym że to raczej odwrotnie jest: zaufanie testowaniu daje ci
> w błędne przekonanie, że program zawsze dobrze działa i inna weryfikacja
> jest niepotrzebna.
Nigdy nie osiągniemy "zawsze" :P Możemy jedynie dążyć do tego :)
> Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
> czego prowadzi i że to nic dobrego.
Będę się upierał, że Ty zacząłeś :), na potwierdzenie przytaczam cytat
z Twojej wypowiedzi: "Ekstrapolując twoje proponowane podejście "jeden
ruch mniej", może darujmy sobie testowanie aplikacji?"
Twoja "ekstrapolacja" była nadinterpretacją mojej wypowiedzi.
> > A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
> > też się zorientuje - zwłaszcza, że bardzo często używa się
> > rzutowania?
>
> Zależy czy ta wyższa czy niższa jest niezbędna, czy też nie. W ogóle nie
> rozumiem pytania i problemu, który byś chciał pokazać. Please elaborate.
class c1{
public int m1(int a) {
a = a + 1;
return(a);
}
}
class c2 extends c1{
public int m1(int a) {
a = a + 2;
return(a);
}
}
public class jsimple{
public static void main (String[] args) {
c1 o1 = new c2();
System.out.println (o1.m1(3));
}
}
result: 5
I co z tego, że typ c1? :(
> >> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
> >> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
> >> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
> >> a idiomów używa się sporadycznie.
>
> > Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
> > trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
> > że mam pojęcie przekrojowe :)
>
> Bo wiesz, jakoś nie widzę tego po tobie.
A to mnie nie dziwi, bo mnie w ogóle nie widzisz :P. Ale jeśli się
podzieliłeś opinią o mnie, to pozwól, że i ja się podzielę swoją.
Myślę, że nie używałeś zbytnio Pythona, a swoją wiedzę czerpiesz z
teorii.
> Rozumiem że chodzi o to:
> #v+
> Bo większość operacji w przeciętnym kodzie źródłowym tłumaczy się wprost
> na inne języki, a idiomów używa się sporadycznie.
> #v-
Tak, tu się zgadzamy - to znaczy to jest ostatnie zdanie :)
> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
> idiomem w Pythonie jest konstruowanie tablicy za pomocą
> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".
A teraz mój wredny wtręt: nie tablicy, a listy. Różnica niewielka,
ale ... :)
> W przypadku programowania, większość kodu to instrukcje warunkowe,
> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
> wbudowanej).
Wybacz, nie zgadzam się z Tobą. Przy tej definicji idiomy i tym
podejściu to każda instrukcja, każdego języka jest idiomem !!!!
Oczywiście wszystko odnosząc do assemblera :)
Moim zdaniem języki programowania powstały po to by się pisało łatwo,
krótko i ... przyjemnie :) Nie po to by programy działały szybciej.
> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
> a w dużej części z pozostałych, typowych dla danego paradygmatu
> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
> program w Perlu i taki sam w Pythonie będą miały podobną długość.
W Python "idiomów" wg Twojej definicji używa się cały czas. Po co
pisać ciągle te same kawałki kodu?
Ale chyba odeszliśmy od głównego wątku "typowania" :)
> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
> nie przekłada się specjalnie na długość kodu.
> Powiem ci że parę lat temu też uważałem że ilość idiomów pozytywnie
> wpływa na ilość kodu i jego konserwowalność, ale z doświadczeniem się
> z tego przekonania wyrasta.
Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
ten same problemy w różnych językach programowania. W tej chwili coś
nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
"idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
typowania explicite, krótka notacja - chyba wszystko wymieniłem.
Pzdr.
Jacek
Roman Dobosz
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
> idiomem w Pythonie jest konstruowanie tablicy za pomocą
> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".
To "coś" nazywa się list comprehension i jest konstrukcją języka,
natomiast to co wołasz z Perla to funkcja, która istnieje również w
Pythonie. List comprehension to nic innego jak tworzenie listy w pętli:
result = []
for i in ??:
result.append(i)
bez konieczności wywoływania funkcji/bloku na każdym elemencie. Nie
bardzo więc pasuje tu definicja idiomu. To raczej lukier składniowy.
> W przypadku programowania, większość kodu to instrukcje warunkowe,
> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
> wbudowanej).
Fajowo. Szkoda, że nie podałeś jak to się ma do statycznie typowanego
języka, jakim jest C, a zamiast tego sięgnąłeś po dynamicznie
typowanego Perla :)
> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
> a w dużej części z pozostałych, typowych dla danego paradygmatu
> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
> program w Perlu i taki sam w Pythonie będą miały podobną długość.
I różną czytelność.
> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
> nie przekłada się specjalnie na długość kodu.
W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
niejeden inny podobnego typu język.
Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
czynienia z Pythonem.
--
-^- _ coś tam w tle sobie gra, np:
_ /O)_\// Bush - Synapse
(_(|__(_(_) grf.
zbr...@tlen.pl
> Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> kodu).
>
Ale dlaczego "versus"?
Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
Program ze zgodnymi typami nie musi być poprawny, natomiast program w
którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.
Co do testów - w innym poście tego wątku podałem przykład, będący nieco
uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany
API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu
mimo że testy przechodziły bezbłednie.
Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę.
Przy czym nie tweirdzę że jest to panaceum na wszystko.
> class c1{
> public int m1(int a) {
> a = a + 1;
> return(a);
> }
> }
> class c2 extends c1{
> public int m1(int a) {
> a = a + 2;
> return(a);
> }
> }
> public class jsimple{
> public static void main (String[] args) {
> c1 o1 = new c2();
> System.out.println (o1.m1(3));
> }
> }
> result: 5
>
> I co z tego, że typ c1? :(
Znaczy chcesz pokazać, że jak się spieprzy projekt struktury klas, to
już nic nie pomoże? Z tym jestem się w stanie zgodzić.
Przy dobrze zaprojektowanych klasach powyższy problem nie wystąpi, a na
źle zaprojektowane klasy lekarstwem nie jest ani kontrola typów, ani testy.
Pzdr
J.
Jacek Czerwinski
> On 22.05.2011 11:10, jacek2v wrote:
>> Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
>> wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
>> przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
>> kodu).
>>
>
> Ale dlaczego "versus"?
> Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
> Program ze zgodnymi typami nie musi być poprawny, natomiast program w
> którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.
Ślicznie powiedziane, jestem za a nawet powiem że 'niepoprawnego' w tym
sensie programu po prostu nie będzie.
>
> Co do testów - w innym poście tego wątku podałem przykład, będący nieco
> uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany
> API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu
> mimo że testy przechodziły bezbłednie.
> Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę.
> Przy czym nie tweirdzę że jest to panaceum na wszystko.
To mam na myśli, a bylem jednym z wrzucających tak drażliwy temat.
Aktualizację biblioteki o "duży" numer wersji mocne typy baaaaardzo
ułatwiają. Zwykle zmiany funkcjonalności nie są szokujące, ale formalne
są spore.
Stachu 'Dozzie' K.
> On Sat, 21 May 2011 18:41:00 +0000 (UTC)
> "Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
>
>> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
>> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
>> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
>> idiomem w Pythonie jest konstruowanie tablicy za pomocą
>> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".
>
> To "coś" nazywa się list comprehension i jest konstrukcją języka,
> natomiast to co wołasz z Perla to funkcja, która istnieje również w
> Pythonie.
Ależ oczywiście. I użycie tej konstrukcji jest w Pythonie idiomem, który
w Perlu wyraża się nieco inną konstrukcją programistyczną. Dokładnie to
chciałem pokazać: że da się przetłumaczyć, że podobna długość i że inny
typ konstrukcji.
> List comprehension to nic innego jak tworzenie listy w pętli:
>
> result = []
> for i in ??:
> result.append(i)
>
> bez konieczności wywoływania funkcji/bloku na każdym elemencie. Nie
> bardzo więc pasuje tu definicja idiomu. To raczej lukier składniowy.
Erm. Idiomem jest między innymi taki właśnie lukier.
>> W przypadku programowania, większość kodu to instrukcje warunkowe,
>> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
>> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
>> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
>> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
>> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
>> wbudowanej).
>
> Fajowo. Szkoda, że nie podałeś jak to się ma do statycznie typowanego
> języka, jakim jest C, a zamiast tego sięgnąłeś po dynamicznie
> typowanego Perla :)
Fajowo, tylko że C reprezentuje trochę inny paradygmat programowania,
jeśli nie zauważyłeś.
>> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
>> a w dużej części z pozostałych, typowych dla danego paradygmatu
>> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
>> program w Perlu i taki sam w Pythonie będą miały podobną długość.
>
> I różną czytelność.
Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
w Perlu.
>> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> nie przekłada się specjalnie na długość kodu.
>
> W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
> stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
> niejeden inny podobnego typu język.
#define "podobnego typu"
> Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> czynienia z Pythonem.
A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
z czymkolwiek innym.
Stachu 'Dozzie' K.
> On 21 Maj, 20:41, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>
>> Eeee... Że co? Co ma siła typowania do statyczności typowania?
>
> "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
> niema.
Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
typowanie ma Haskell.
>> Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
>> używać więcej znaków interpunkcyjnych.
>
> Aha :) Zapomniałeś włączyć w kompilatorze logikę rozmytą? :)
Nie. Ty zapomniałeś użyć prawidłowo interpunkcji.
>> Eeee... Nie? A dostajesz w zamian kontrolę typów. Proponuję przyjrzeć
>> się dowolnemu programowi dowolnego języka ze statycznym typowaniem
>> i policzyć, ile kodu, tak na literki, jest przeznaczone na deklaracje
>> typów.
>
> Liczyłem. Jak Twoje wyniki? Wg moich sporo więcej :P
To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
wychodzi nawet 10% kodu.
>> Tam, gdzie wymagania niezawodnościowe są dużo wyższe, to akurat się unika
>> testowania, zastępując je formalną automatyczną weryfikacją. Testy nie
>> są tak niezawodne jak próbujesz przedstawiać, nie dają gwarancji
>> poprawności programu. Zautomatyzowana weryfikacja (przy której
>> weryfikacja typów to tylko preludium do wstępu) za to daje.
>
> A co to "formalną automatyczną weryfikacją"?
Proponuję poszukać w takim razie materiałów.
> Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> kodu).
To może tak wyglądać w małych projektach, gdzie jesteś w stanie
naprodukować i utrzymywać testy dla mniej więcej większości kodu.
W większych projektach przy refaktoryzacji okazuje się że system typów
przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.
>> > Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
>>
>> Nie. Ale może się zdarzyć że testy, które przygotowałeś, nie pokryją
>> wszystkich możliwych sytuacji. Kompilator jest za to dokładniejszy.
>
> I na pewno się tak zdarzy, gwarantuję :) Użytkownicy są
> nieobliczalni :D
Nie chodzi o to jak obliczalni są użytkownicy, tylko czy ty jesteś
w stanie pokryć testami wszystkie możliwe ścieżki wykonania. Nie jesteś.
> A kompilator jest i Python :) Zapewne miałeś na myśli, że kompilator
> sprawdzi typy, ale jak już mówiłem, moim zdaniem złudne to poczucie
> sprawdzenia. A ja wolę nie mieć złudzeń :)
To po co testujesz? To ci daje złudne poczucie że twój program działa.
A to co kompilator w statycznie typowanym języku sprawdzi, to jest
prawdziwe sprawdzenie. Niewystarczające do uznania kodu za prawidłowy (o
czym wie każdy piszący w językach statycznie typowanych), ale prawdziwe.
>> >> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
>> >> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
>> >> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
>> >> *wszędzie*.
>>
>> > Ale i tak kompilator nie wyłapie znacznej większości błędów, a
>> > świadomość, że trzeba testować jest lepsza niż życie w błędnym
>> > przekonaniu, że coś samo się sprawdzi i będzie ok.
>>
>> Ależ świadomość nadal jest. Weryfikacja typu nie wychwyci błędu
>> logicznego. Za to wychwyci dużo typowych błędów, co już samo w sobie
>> pomaga.
>
> Weryfikacja typu wychwyci jedynie błąd typu i nic więcej.
> Moja praktyka jest taka, że zawsze błąd typu jest wykrywany po
> pierwszym uruchomieniu poprawianego kodu.
To chyba w jakichś malutkich projektach. Gdy program robi się duży,
z jednej funkcji którą zmieniasz może korzystać fafnaście innych
modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
ujednolicić typ danych, na którym ten kod operuje.
> I tak każdy moduł/funkcja/
> metoda przez programistę jest dziesiątki (jeśli nie setki razy)
> uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
> to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
> kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
cały duży projekt, wszystkie wywoływane w nim funkcje.
> Żeby uprzedzić argumenty o zmiennych warunkach wykonania i że ścieżka
> wykonania jest niedeterministyczna, chciałby zwrócić Twoją uwagę, że
> Python nie jest językiem "nie typowanym" jest językiem "dynamicznie
> typowanym", czyli typowanie ma, tylko nie jest ono podawane explicite.
Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
"dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
a mimo to język jest statycznie i silnie typowany.
>> Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
>> czego prowadzi i że to nic dobrego.
>
> Będę się upierał, że Ty zacząłeś :), na potwierdzenie przytaczam cytat
> z Twojej wypowiedzi: "Ekstrapolując twoje proponowane podejście "jeden
> ruch mniej", może darujmy sobie testowanie aplikacji?"
> Twoja "ekstrapolacja" była nadinterpretacją mojej wypowiedzi.
Nie. Była rozszerzeniem twojego rozumowania: "usuńmy kolejny element
który kosztuje".
>> > A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
>> > też się zorientuje - zwłaszcza, że bardzo często używa się
>> > rzutowania?
>>
>> Zależy czy ta wyższa czy niższa jest niezbędna, czy też nie. W ogóle nie
>> rozumiem pytania i problemu, który byś chciał pokazać. Please elaborate.
>
> class c1{
> public int m1(int a) {
> a = a + 1;
> return(a);
> }
> }
> class c2 extends c1{
> public int m1(int a) {
> a = a + 2;
> return(a);
> }
> }
> public class jsimple{
> public static void main (String[] args) {
> c1 o1 = new c2();
> System.out.println (o1.m1(3));
> }
> }
> result: 5
>
> I co z tego, że typ c1? :(
Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
musisz powiedzieć jawnie, które metody są rozwiązywane podczas
kompilacji.
Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o
>> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> nie przekłada się specjalnie na długość kodu.
>> Powiem ci że parę lat temu też uważałem że ilość idiomów pozytywnie
>> wpływa na ilość kodu i jego konserwowalność, ale z doświadczeniem się
>> z tego przekonania wyrasta.
>
> Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
> przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
> programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
> ten same problemy w różnych językach programowania. W tej chwili coś
> nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
> konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
> java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
> "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
> typowania explicite, krótka notacja - chyba wszystko wymieniłem.
Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
* dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
* konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
o domknięciach?)
* zwyczaje programistyczne różnych środowisk (javistów, pythonistów
itd.)
Roman Dobosz
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
> >> program w Perlu i taki sam w Pythonie będą miały podobną długość.
> > I różną czytelność.
> Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
> w Perlu.
Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
niż *typowy* kod w Perlu.
> >> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
> >> nie przekłada się specjalnie na długość kodu.
> > W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
> > stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
> > niejeden inny podobnego typu język.
> #define "podobnego typu"
Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
Ruby.
> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> > czynienia z Pythonem.
> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
> z czymkolwiek innym.
Czyli zgadłem.
--
-^- _
_ /O)_\//
(_(|__(_(_) grf.
Stachu 'Dozzie' K.
> On Mon, 23 May 2011 08:53:02 +0000 (UTC)
> "Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
>
>> >> program w Perlu i taki sam w Pythonie będą miały podobną długość.
>> > I różną czytelność.
>> Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
>> w Perlu.
>
> Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
> niż *typowy* kod w Perlu.
Czy też raczej: typowy autor kodu w Pythonie pisze kod czytelniejszy niż
typowy autor kodu w Perlu. W większej części dlatego, że w Perlu często
piszą ludzie nie umiejący pisać w Perlu (czy programować w ogóle), choć
uważają inaczej.
>> >> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> >> nie przekłada się specjalnie na długość kodu.
>> > W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
>> > stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
>> > niejeden inny podobnego typu język.
>> #define "podobnego typu"
>
> Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
> Ruby.
Żeby Python miał być czytelniejszy od Rubyego? Pierwsze słyszę.
>> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
>> > czynienia z Pythonem.
>> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
>> z czymkolwiek innym.
>
> Czyli zgadłem.
Not much.
Roman Dobosz
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
> > Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
> > niż *typowy* kod w Perlu.
> Czy też raczej: typowy autor kodu w Pythonie pisze kod czytelniejszy niż
> typowy autor kodu w Perlu. W większej części dlatego, że w Perlu często
> piszą ludzie nie umiejący pisać w Perlu (czy programować w ogóle), choć
> uważają inaczej.
To też, ale sama składnia Perla nie zachęca do brnięcia w małpy,
nawiasy, średniki, dolary, strzałki złożone z '-' i '>' czy
podkreślniki.
> >> #define "podobnego typu"
> > Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
> > Ruby.
> Żeby Python miał być czytelniejszy od Rubyego? Pierwsze słyszę.
O rany. De gustibus non est disputandum. Dla mnie kod napisany w
Rubym jest mniej czytelny niż w Pythonie. Ok?
> >> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> >> > czynienia z Pythonem.
> >> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
> >> z czymkolwiek innym.
> > Czyli zgadłem.
> Not much.
Oh really. Pisałeś coś o projekcie z 30kloc w języku dynamicznie
typowanym. To niekoniecznie jest duży projekt.
jacek2v
> On 22.05.2011 11:10, jacek2v wrote:
>
> > Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> > wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> > przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> > kodu).
>
> Ale dlaczego "versus"?
w stosunku do włożonej pracy
> Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
> Program ze zgodnymi typami nie musi być poprawny, natomiast program w
> którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.
Tak to też wcześniej napisałem. Miałem na myśli, że nakład pracy na
pisanie kodu z typowaniem nie opłaca się :)
> Co do testów - w innym poście tego wątku podałem przykład, będący nieco
> uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany
> API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu
> mimo że testy przechodziły bezbłednie.
> Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę.
> Przy czym nie tweirdzę że jest to panaceum na wszystko.
Tak.
> > class c1{
> > public int m1(int a) {
> > a = a + 1;
> > return(a);
> > }
> > }
> > class c2 extends c1{
> > public int m1(int a) {
> > a = a + 2;
> > return(a);
> > }
> > }
> > public class jsimple{
> > public static void main (String[] args) {
> > c1 o1 = new c2();
> > System.out.println (o1.m1(3));
> > }
> > }
> > result: 5
>
> > I co z tego, że typ c1? :(
>
> Znaczy chcesz pokazać, że jak się spieprzy projekt struktury klas, to
> już nic nie pomoże? Z tym jestem się w stanie zgodzić.
To był przykład dla mojego adversarza, aby łatwiej mu było zrozumieć
co miałem na myśli :)
Nie "nic", unit test pomoże. Ale ile się trzeba napisać by te
typowanie zapisać :)
> Przy dobrze zaprojektowanych klasach powyższy problem nie wystąpi, a na
> źle zaprojektowane klasy lekarstwem nie jest ani kontrola typów, ani testy.
Oczywiście, jak się DOBRZE napisze kod to na pewno będzie DOBRY :)
Nie o to mi chodziło, chodzi o "opłacalność typowania" w kontekście
jakości aplikacji.
Pzdr.
jacek2v
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> > "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
> > niema.
>
> Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
> typowanie ma Haskell.
Nie, last one tłumaczę :) Mówię o sytuacji: typowanie JEST albo NIE
MA.
> Nie. Ty zapomniałeś użyć prawidłowo interpunkcji.
Brakuje argumentów? Nie jest moim celem zmienianie Twojego poglądu,
chciałem tylko porozmawiać, aby też samemu mieć szerszy pogląd. Jak
Cię to obraża, nudzi, wkur... albo co innego mniej przyjemnego to daj
znać to skończymy - po co się przerzucać prztyczkami? Ani mnie to
bawi, ani nic dobrego mi, albo Tobie przyniesie.
> To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
> wychodzi nawet 10% kodu.
Mhh, versus 0% w Python to sporo. Przy 10 000 linii to 1000 linii
kontra 0 linii :)
> > A co to "formalną automatyczną weryfikacją"?
>
> Proponuję poszukać w takim razie materiałów.
Miłe:)
> > Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> > wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> > przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> > kodu).
>
> To może tak wyglądać w małych projektach, gdzie jesteś w stanie
> naprodukować i utrzymywać testy dla mniej więcej większości kodu.
> W większych projektach przy refaktoryzacji okazuje się że system typów
> przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
> bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
> kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.
Może są takie Twoje doświadczenia, moje są takie, że daje "złudne
poczucie poprawności".
> To chyba w jakichś malutkich projektach. Gdy program robi się duży,
> z jednej funkcji którą zmieniasz może korzystać fafnaście innych
> modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
> ujednolicić typ danych, na którym ten kod operuje.
Może nie stosujesz unit testów?
> > I tak każdy moduł/funkcja/
> > metoda przez programistę jest dziesiątki (jeśli nie setki razy)
> > uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
> > to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
> > kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
>
> Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
> cały duży projekt, wszystkie wywoływane w nim funkcje.
A co ma jedno do drugiego? Widocznie masz inne podejście do pisania
programów niż ja. Ja uważam, że interfejsy powinny się nie zmieniać,
a jak już musimy je zmienić to z bardzo dużą uwagą - "wolna
amerykanka" jest przeważnie zabójcza.
> Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
> "dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
> dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
> a mimo to język jest statycznie i silnie typowany.
O co Ci chodzi, chcesz rozmawiać merytorycznie, czy próbować łapać za
słóweczka. Wspominałeś o C++, a co tu ma do tego SML?
> Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
> pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
> adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
> musisz powiedzieć jawnie, które metody są rozwiązywane podczas
> kompilacji.
Chłopcze, chciałeś dowodu i go dostałeś. Nie płacz teraz, że to
wszyscy wiedzieli, jak wcześniej nie potrafiłeś tego zrozumieć.
Trzymaj fason :)
Jest typowanie i nic nie daje.
> Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
> jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o
No args ?
> > Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
> > przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
> > programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
> > ten same problemy w różnych językach programowania. W tej chwili coś
> > nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
> > konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
> > java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
> > "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
> > typowania explicite, krótka notacja - chyba wszystko wymieniłem.
>
> Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
> * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
> * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
> o domknięciach?)
> * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
> itd.)
Hehehe.
Mr Stach, albo "chłopcze" jak wolisz, sam sprowadziłeś dyskusję do
tego poziomu. Jak już chyba ktoś kiedyś wspomniał, nastała następująca
sytuacja: okopaliśmy się i d. z okopów nie ruszymy :). Starałem się
zrozumieć Twój punkt widzenia. Starałem się osiągnąć jakiś
merytoryczny poziom dyskusji, ale się nie udało. Pierd... za uszami
nie ma sensu. Zatem: EOT
Miłego Dnia
Jacek
Stachu 'Dozzie' K.
> On 23 Maj, 10:53, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>> > "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
>> > niema.
>>
>> Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
>> typowanie ma Haskell.
>
> Nie, last one tłumaczę :) Mówię o sytuacji: typowanie JEST albo NIE
> MA.
To nie używaj pojęć słabe/silne typowanie, kiedy o tym mówisz, bo
wprowadzasz niejasności.
>> To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
>> wychodzi nawet 10% kodu.
>
> Mhh, versus 0% w Python to sporo. Przy 10 000 linii to 1000 linii
> kontra 0 linii :)
Przy 10k linii 1000 linii to niedużo, zwłaszcza że pozwala na dodatkowe
sprawdzenie programu i powoduje, że pierwsze uruchomienie kontrolne nie
służy do znalezienia miejsca, gdzie nadal używasz krotki, podczas gdy
reszta kodu ma hasz, tylko zajmujesz się poważniejszymi błędami.
>> > Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
>> > wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
>> > przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
>> > kodu).
>>
>> To może tak wyglądać w małych projektach, gdzie jesteś w stanie
>> naprodukować i utrzymywać testy dla mniej więcej większości kodu.
>> W większych projektach przy refaktoryzacji okazuje się że system typów
>> przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
>> bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
>> kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.
>
> Może są takie Twoje doświadczenia, moje są takie, że daje "złudne
> poczucie poprawności".
Może dlatego tak odbierałeś system typów, że nie wiedziałeś wcześniej
jak go traktować. To teraz będziesz wiedział: jako pierwszą,
zautomatyzowaną, statyczną weryfikację, która jeszcze nie mówi że
program jest poprawny (a jedynie wcześnie odfiltruje programy, które
poprawne nie są i których nie ma sensu uruchamiać przed poprawieniem).
>> To chyba w jakichś malutkich projektach. Gdy program robi się duży,
>> z jednej funkcji którą zmieniasz może korzystać fafnaście innych
>> modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
>> ujednolicić typ danych, na którym ten kod operuje.
>
> Może nie stosujesz unit testów?
Może nie pokryjesz stu procent kodu testami jednostkowymi? A może nawet
jeśli pokryjesz, to nie pokryjesz stu procent ścieżek programu?
>> > I tak każdy moduł/funkcja/
>> > metoda przez programistę jest dziesiątki (jeśli nie setki razy)
>> > uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
>> > to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
>> > kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
>>
>> Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
>> cały duży projekt, wszystkie wywoływane w nim funkcje.
>
> A co ma jedno do drugiego? Widocznie masz inne podejście do pisania
> programów niż ja. Ja uważam, że interfejsy powinny się nie zmieniać,
Powinny. Co nie znaczy że nie mogą. I to nie znaczy również że nie będą
(a raczej właśnie będą, bo nie przewidzisz wszystkiego, tylko że
rzadziej niż reszta kodu).
> a jak już musimy je zmienić to z bardzo dużą uwagą - "wolna
> amerykanka" jest przeważnie zabójcza.
O widzisz! Brawo misiu! I tu właśnie przydaje się system typów. Przy
zmianie interfejsu system typów odciąża programistę.
>> Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
>> "dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
>> dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
>> a mimo to język jest statycznie i silnie typowany.
>
> O co Ci chodzi, chcesz rozmawiać merytorycznie, czy próbować łapać za
> słóweczka. Wspominałeś o C++, a co tu ma do tego SML?
To ty wciągnąłeś "typ nie podawany explicite" do dyskusji. Ja podałem
przykład języka typowanego statycznie (i z silnym systemem typów),
w którym nie podajesz typu przy wprowadzania zmiennej.
>> Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
>> pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
>> adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
>> musisz powiedzieć jawnie, które metody są rozwiązywane podczas
>> kompilacji.
>
> Chłopcze, chciałeś dowodu i go dostałeś. Nie płacz teraz, że to
> wszyscy wiedzieli, jak wcześniej nie potrafiłeś tego zrozumieć.
Twoim zdaniem to był jakiś problem z typowaniem statycznym. To
nieprawda, bo a) to nie jest problem, b) to nie dotyczy typowania
statycznego, tylko stosowanego w Javie mechanizmu odpowiadającego
metodom wirtualnym z C++ (czyli dynamic binding).
> Trzymaj fason :)
> Jest typowanie i nic nie daje.
Owszem, daje, i to całkiem sporo. A sytuacja analogiczna do tego, co
pokazałeś w swoim przykładzie, zdarza się bardzo rzadko.
>> Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
>> jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o
>
> No args ?
Nie. Spostrzeżenie, że mój rozmówca nie tylko ma problemy
z interpunkcją (przez co momentami trudno zrozumieć co pisze), ale
również z używaniem wiedzy teoretycznie nabytej podczas pisania
w Pythonie.
>> > Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
>> > przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
>> > programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
>> > ten same problemy w różnych językach programowania. W tej chwili coś
>> > nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
>> > konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
>> > java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
>> > "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
>> > typowania explicite, krótka notacja - chyba wszystko wymieniłem.
>>
>> Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
>> * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
>> * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
>> o domknięciach?)
>> * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
>> itd.)
>
> Hehehe.
>
> Mr Stach, albo "chłopcze" jak wolisz, sam sprowadziłeś dyskusję do
> tego poziomu. Jak już chyba ktoś kiedyś wspomniał, nastała następująca
> sytuacja: okopaliśmy się i d. z okopów nie ruszymy :).
Ano nie ruszymy. Podsumowałbym to tak: za typowaniem statycznym
przemawia wczesne odrzucenie kodu ewidentnie nieprawidłowego, za
dynamicznym skrócenie kodu o jakieś pomijalne wartości. I żaden z nas
nie chce uznać, że drugi ma rację.
> Starałem się
> zrozumieć Twój punkt widzenia. Starałem się osiągnąć jakiś
> merytoryczny poziom dyskusji, ale się nie udało.
Przykro mi że nie byłeś w stanie ze swojej strony osiągnąć odpowiedniego
technicznego poziomu, żeby prowadzić dyskusję.
> Pierd... za uszami
> nie ma sensu. Zatem: EOT
OK, EOT.
zbr...@tlen.pl
> Tak to też wcześniej napisałem. Miałem na myśli, że nakład pracy na
> pisanie kodu z typowaniem nie opłaca się :)
Mam wrażenie, że ten "nakład pracy" jest demonizowany. Programuję
równolegle w Javie i w Pythonie i akurat konieczność deklarowania typów
mnie nie boli.
Bonusem jest za to, że kod z deklaracjami typów jest bardziej
"samodokumentujący" się. Porównaj:
def find_user(users, properties):
z tym:
public User findUser(List<User> users, Map<String, String> properties)
> To był przykład dla mojego adversarza, aby łatwiej mu było zrozumieć
> co miałem na myśli :)
> Nie "nic", unit test pomoże. Ale ile się trzeba napisać by te
> typowanie zapisać :)
Unit test pomoże albo nie. Problem z unit testami jest taki, że podobnie
jak programy, mogą nie być do końca poprawne, w końcu pisane są przez
ludzi. Zwłaszcza przy refaktoringu rodzi się niebezpieczeństwo, że nie
zmodyfikujemy odpowiednio właściwych testów. I co teraz? Napisać
metatesty sprawdzające poprawność testów?
Pzdr
J.
jacek2v
> Mam wrażenie, że ten "nakład pracy" jest demonizowany. Programuję
> równolegle w Javie i w Pythonie i akurat konieczność deklarowania typów
> mnie nie boli.
Nie chcę się spierać, jednego boli, a drugiego nie :) - to też zależy
od preferencji osobistych. Mnie to strasznie wkur..., że muszę
deklarować typy, uważam to za stratę czasu. A to, że nie ma typowania
dopinguje mnie do pisania unit testów, oraz uważniejszego pisania
kodu :) - człowiek potrzebuje czasami trochę motywacji :)
Co do demonizowania to nie wiem czy patrzyłeś na shootout (http://
shootout.alioth.debian.org/u64q/python3.php kolumna code), co prawda
ilości kodu nie wynika tylko z posiadania, czy też braku typowania,
ale jest jedną ze składowych. Liczby też nie oddają dokładnie skali,
dobrze jest popatrzeć na kod. Jako, że wspominasz, że piszesz obecnie
i w Java i Pythonie to będziesz miał w miarę obiektywne spojrzenie.
> Bonusem jest za to, że kod z deklaracjami typów jest bardziej
> "samodokumentujący" się. Porównaj:
>
> def find_user(users, properties):
>
> z tym:
>
> public User findUser(List<User> users, Map<String, String> properties)
Niby nie wiele, ale ... :) razy 2 kodu.
To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
"samodokumentuje". Oczywiście można zrobić tak:
def find_user(lst_users, dict_properties): lub tak: def
find_user(users=[], properties={}):
Widziałem też taką konwencję (ta pierwsza) w językach typowanych np.
Pascalu (bodajże Borland to promował) i w Javie.
BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
Python :). Dlatego wolę tak:
def findUser(lstUsers, dictProperties):
> Unit test pomoże albo nie. Problem z unit testami jest taki, że podobnie
> jak programy, mogą nie być do końca poprawne, w końcu pisane są przez
> ludzi. Zwłaszcza przy refaktoringu rodzi się niebezpieczeństwo, że nie
> zmodyfikujemy odpowiednio właściwych testów. I co teraz? Napisać
> metatesty sprawdzające poprawność testów?
Myślę, że demonizujesz, ale i masz sporo racji :). Ani typowanie, ani
super/mega testy nie uchronią od błędów w oprogramowaniu. Jedynie mogą
minimalizować prawdopodobieństwo ich wystąpienia. Mi chodzi o to, że
zysk z używania typowania jest nieproporcjonalnie mały w stosunku do
nakładów pracy na jego używanie.
W moim przekonaniu najlepszym sposobem zmniejszenia ilości błędów jest
wielkość kodu źródłowego oraz jego "modularyzacja". Temu służyło
przejście od assemblera do języków wyższych poziomów (mniej kodu
źródłowego), potem moduły/pakiety i programowanie obiektowe
("modularyzacja"). Następnym elementem, który znacząco zmniejsza
(oczywiście moim zdaniem :)) ilość błędów to "łatwość" przejścia od
pisania kodu do jego wykonania. Czym mniej kroków, czym mniej czasu
czekamy na uruchomienie, tym częściej programiście chce się to
robić :). Często dzielimy kod, ekstrahując obecnie robioną
funkcjonalność po to tylko by nie kompilować/uruchamiać całości
aplikacji, z powodu długiego uruchomienia, lub dużej ilości formularzy
do przeklikania - wielokrotnie sam doświadczyłem i widziałem u innych.
De facto robimy w ten sposób unit testy - ale to już inna historia.
Pzdr.
Jacek
zbr...@tlen.pl
> To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
> "samodokumentuje". Oczywiście można zrobić tak:
> def find_user(lst_users, dict_properties): lub tak: def
> find_user(users=[], properties={}):
Wiem że można, ba, wiedziałem że taki argument padnie ;).
Osobiście w swojej karierze spotkałem się z wypasionymi dokumentami
określającymi konwencje nazewnicze, których celem było właśnie
"przemycenie" definicji typu w nazwie argumentu.
Tylko skoro już przemycamy typ argumentu, to fajnie, jak by nam
kopilator (albo dowolny inny tool) sprawdził zgodność typów przy
wywołaniach ;)
> BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
> Python :). Dlatego wolę tak:
> def findUser(lstUsers, dictProperties):
W pythonie jednak dużo częściej stosuje się konwencję z podkreśleniami,
a ja staram się dostosować.
Pzdr
J.
jacek2v
> On 25.05.2011 10:01, jacek2v wrote:
>
> > To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
> > "samodokumentuje". Oczywiście można zrobić tak:
> > def find_user(lst_users, dict_properties): lub tak: def
> > find_user(users=[], properties={}):
>
> Wiem że można, ba, wiedziałem że taki argument padnie ;).
> Osobiście w swojej karierze spotkałem się z wypasionymi dokumentami
> określającymi konwencje nazewnicze, których celem było właśnie
> "przemycenie" definicji typu w nazwie argumentu.
> Tylko skoro już przemycamy typ argumentu, to fajnie, jak by nam
> kopilator (albo dowolny inny tool) sprawdził zgodność typów przy
> wywołaniach ;)
Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
namierzyłem.
BTW: Mimo to, bez krótkiego opisu funkcji: "do czego ona jest" nie
obejdzie się.
> > BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
> > Python :). Dlatego wolę tak:
> > def findUser(lstUsers, dictProperties):
>
> W pythonie jednak dużo częściej stosuje się konwencję z podkreśleniami,
> a ja staram się dostosować.
Wiem, ale jeszcze minie trochę czasu (parę lat?:)) zanim wrócę do
"podłóg" :) - kiedyś wypleniłem w sobie "_" i jakoś trudno wrócić.
Zawsze to jeden znak więcej :D
Pzdr.
Jacek
Roman Dobosz
jacek2v <jac...@gmail.com> wrote:
> lub tak: def find_user(users=[], properties={}):
To nie jest do końca dobry sposób:
>>> def foo(a, l=[]):
... l.append(a)
... return l
...
>>> foo(1)
[1]
>>> foo(2)
[1, 2]
>>> foo(3)
[1, 2, 3]
>>>
W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
opisać czym dany argument jest.
--
-^- _ coś tam w tle sobie gra, np:
_ /O)_\// Hocico - cuando la maldad despierta
(_(|__(_(_) grf.
Roman Dobosz
jacek2v <jac...@gmail.com> wrote:
> Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
> typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
> namierzyłem.
Wiem, ze to nie do końca to czego oczekujesz, ale częściowo pomagają
narzędzia typu pep8[1], pyflakes[2] i pylint[3]. Zwłaszcza pep8
opierniczy za każde odstępstwo od PEP8[4]. Nie sprawdzą typów, a
jedynie styl i błędy wynikające ze statycznej analizy kodu.
> BTW: Mimo to, bez krótkiego opisu funkcji: "do czego ona jest" nie
> obejdzie się.
Uważam, że dokumentowanie kodu (modułów, klas i funkcji) to dobry
zwyczaj. Parę słów komentarza w docstringu nie boli, a po paru latach
spełnia swoje zadanie, bez konieczności analizowania ciała
modułu/klasy/funkcji.
[1] http://pypi.python.org/pypi/pep8
[2] http://pypi.python.org/pypi/pyflakes
[3] http://www.logilab.org/857
[4] http://www.python.org/dev/peps/pep-0008/
--
-^- _ coś tam w tle sobie gra, np:
_ /O)_\// Hocico - Without a God
(_(|__(_(_) grf.
jacek2v
> On Wed, 25 May 2011 01:01:55 -0700 (PDT)
>
> > lub tak: def find_user(users=[], properties={}):
>
> To nie jest do końca dobry sposób:
>
> >>> def foo(a, l=[]):
>
> ... l.append(a)
> ... return l
> ...
>
> >>> foo(1)
> [1]
> >>> foo(2)
> [1, 2]
> >>> foo(3)
> [1, 2, 3]
>
> W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
> mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
> powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
> opisać czym dany argument jest.
Rzeczywiście można sobie kuku zrobić :) Te zakresy zmienny to raczej
do poprawki - i przy okazji "self" mogliby "wykarczować" :)
Dzięki.
J.
jacek2v
Chociaż po chwili namysł to nie problem zakresu zmiennej, tylko jakiś
błąd inicjacji parametru ?
jacek2v
> On Wed, 25 May 2011 07:09:55 -0700 (PDT)
>
> > Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
> > typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
> > namierzyłem.
>
> Wiem, ze to nie do końca to czego oczekujesz, ale częściowo pomagają
> narzędzia typu pep8[1], pyflakes[2] i pylint[3]. Zwłaszcza pep8
> opierniczy za każde odstępstwo od PEP8[4]. Nie sprawdzą typów, a
> jedynie styl i błędy wynikające ze statycznej analizy kodu.
Właśnie o to chodziło, dzięki. Takie narzędzia przydatne dla większych
zespołów, co by "dyscyplinę kodu" trzymać :)
J.
Wojciech Malinowski
> On 25 Maj, 21:20, jacek2v <jace...@gmail.com> wrote:
>> On 25 Maj, 20:20, Roman Dobosz <gryf_esm...@spam-o2.pl> wrote:
>>> W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
>>> mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
>>> powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
>>> opisać czym dany argument jest.
>>
>> Rzeczywiście można sobie kuku zrobić :) Te zakresy zmienny to raczej
>> do poprawki - i przy okazji "self" mogliby "wykarczować" :)
>> Dzięki.
>
> Chociaż po chwili namysł to nie problem zakresu zmiennej, tylko jakiś
> błąd inicjacji parametru ?
To nie żaden błąd tylko naturalna konsekwencja tego, że wszystko jest
obiektem. Funkcja też. Jest singletonem, instancją klasy function.
Domyślne parametry są jej atrybutami.
Interpreter nie może w żaden sposób zgadnąć czy te atrybuty są mutowalne
czy nie. Nawet gdyby mógł to pozostała by kwestia, czy przy każdym
odpaleniu zrobić płytkie czy głębokie kopiowanie (i też pojawiłyby się
pewnie skutki uboczne).
Przyjęte rozwiązanie jest najprostsze i najłatwiejsze do zrozumienia.
Trzeba tylko pamiętać, że funkcje, klasy (w tym przypadku można nawet
pomajstrować z typem tego obiektu za pomocą metaklas), docstringi itp są
singletonowymi obiektami. Dowód poniżej:
>>> def foo(bar=[], baz='test'):
... print bar, baz
>>> type(foo)
<type 'function'>
>>> foo
<function foo at 0x7f377e5e1758>
>>> foo.func_defaults
([], 'test')
>>> foo.func_code
<code object foo at 0x7f377e5dfa80, file "<stdin>", line 1>
>>> foo.__call__
<method-wrapper '__call__' of function object at 0x7f377e5e1758>
>>> foo.__call__()
[] test
Pozdrawiam,
Wojciech Malinowski
Dsue
> [1] http://pypi.python.org/pypi/pep8
> [2] http://pypi.python.org/pypi/pyflakes
> [3] http://www.logilab.org/857
Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości
linii.
Pozdrawiam
Dsue
Stachu 'Dozzie' K.
a) Linia długa na 150 znaków brzydko wygląda.
b) Linię długą na 150 znaków czyta się źle.
c) Jeśli masz linię na 150 znaków, to znak że zbyt dużo robisz w tej
linii. To obniża czytelność kodu.
d) Niektórzy nadal drukują (!) kod źródłowy. Linia 150-znakowa łamie się
w losowym miejscu, co się z wydruku *bardzo źle* czyta.
e) Większość tekstu w kodzie ciąży w kierunku lewego marginesu. Przy 150
znakach w jednym wystającym wierszu skaczesz wzrokiem po zbyt dużej
powierzchni ekranu.
f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.
Dsue
> a) Linia długa na 150 znaków brzydko wygląda.
Zgadzam się, chociaż:
def funkcja(bardzo_dlugi_parametr_1,
bardzo_dlugi_parametr_2,
bardzo_dlugi_parametr_3,
bardzo_dlugi_parametr_4,
bardzo_dlugi_parametr_5)
też nienajlepiej IMHO.
> b) Linię długą na 150 znaków czyta się źle.
jw.
> f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
> ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
> ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.
O i to jest argument. Mając na ekranie panel lewy z listą
plików/obiektów/symboli i panel prawy z helpem na przykład, na srodku
zostaje niezawiele miejsca. Tak, to mnie przekonuje.
Pozdrawiam
Dsue
Roman Dobosz
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid> wrote:
> > Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
> > Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości
> > linii.
>
> a) Linia długa na 150 znaków brzydko wygląda.
> b) Linię długą na 150 znaków czyta się źle.
> c) Jeśli masz linię na 150 znaków, to znak że zbyt dużo robisz w tej
> linii. To obniża czytelność kodu.
> d) Niektórzy nadal drukują (!) kod źródłowy. Linia 150-znakowa łamie się
> w losowym miejscu, co się z wydruku *bardzo źle* czyta.
> e) Większość tekstu w kodzie ciąży w kierunku lewego marginesu. Przy 150
> znakach w jednym wystającym wierszu skaczesz wzrokiem po zbyt dużej
> powierzchni ekranu.
> f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
> ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
> ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.
g) Oglądanie linii 150 znakowych w przypadku diffa side-by-side jest
uciążliwe (nie wspominając o porównywaniu trzech plików).
h) Wąskie teksty lepiej się czyta, co ma swoje zastosowanie chociażby
w gazetach (gdzie strona podzielona jest na szpalty).
--
-^- _ coś tam w tle sobie gra, np:
_ /O)_\// Plasmodivm - Rise
(_(|__(_(_) grf.
mvoicem
Mógłby to ktoś przetłumaczyć i rzucić gdzieś Komuś Kto Ustala Coding
Standards w Drupalu? (wiem wiem, nie ta grupa). Tam sobie radośnie
ustalili że "linii nie łamiemy, choćby to było nie wiadomo jak długie
zapytanie SQL".
p. m.
jacek2v
Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)
Wojciech Malinowski
> Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
> logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)
Nie ma sprawy.
BTW Skoro nikt się nie pofatygował sprostować tego co napisałem to sam
sprostuję: funkcje nie są singletonami. Są normalnymi instancjami klasy
function.
Pozdrawiam,
Wojciech Malinowski
jacek2v
Myślę, że się nie pomyliłeś. To jest singleton w rozumieniu tylko
"jedna instancja danej klasy".
Jordan Szubert
obawiam się, że albo Cię nie rozumiem, albo nie masz jednak racji: mi
wychodzi, że funkcje są tej samej klasy, nie jest generowana oddzielna
klasa dla każdej funkcji, a dopiero wtedy bym uznał określenie „singleton”
za zasadne.
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
... pass
...
>>> def bar():
... pass
...
>>> type(foo) is type(bar)
True
>>> foo.__class__ is bar.__class__
True
>>> type(foo)
<type 'function'>
>>>
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
... pass
...
>>> def bar():
... pass
...
>>> type(foo)
<class 'function'>
>>> type(foo) is type(bar)
True
>>> foo.__class__ is bar.__class__
True
>>>
--
Jordan Szubert
jacek2v
> Dnia 27-05-2011 o 12:48:58 jacek2v <jace...@gmail.com> napisał(a):
> obawiam się, że albo Cię nie rozumiem, albo nie masz jednak racji: mi
> wychodzi, że funkcje są tej samej klasy, nie jest generowana oddzielna
> klasa dla każdej funkcji, a dopiero wtedy bym uznał określenie "singleton"
> za zasadne.
> Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.>>> def foo():
>
> ... pass
> ...>>> def bar():
>
> ... pass
> ...
>
> >>> type(foo) is type(bar)
> True
> >>> foo.__class__ is bar.__class__
> True
> >>> type(foo)
> <type 'function'>
>
Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
> issubclass(type(foo), type(object))
False
Pzdr.
Jordan Szubert
> Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
> >>> issubclass(type(foo), type(object))
> False
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
... pass
...
>>> type(foo)
<class 'function'>
>>> type(object)
<class 'type'>
>>> issubclass(type(foo),type(object))
False
>>> issubclass(type(foo),object)
True
>>> object
<class 'object'>
>>>
--
Jordan Szubert
jacek2v
jacek2v
Ale...? :) - nigdy nie byłem fanem takiego drążenia języka prog., ale
jak już drążymy, to:
Python 2.7.1
>class Fooc(object):
>
>... pass
>
> issubclass(type(Fooc), type(object))
>True
A przy funkcji było:
> False
Jordan Szubert
> On 29 Maj, 10:00, jacek2v <jace...@gmail.com> wrote:
>> On 29 Maj, 02:09, "Jordan Szubert" <use...@joru.us.to> wrote:
>>> Dnia 28-05-2011 o 15:48:40 jacek2v <jace...@gmail.com> napisał(a):
>>>> Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
>>>> >>> issubclass(type(foo), type(object))
>>>> False
>>>
>>> Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit
>>> (AMD64)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> def foo():
>>> ... pass
>>> ...
>>> >>> type(foo)
>>> <class 'function'>
>>> >>> type(object)
>>> <class 'type'>
>>> >>> issubclass(type(foo),type(object))
>>> False
>>> >>> issubclass(type(foo),object)
>>> True
>>> >>> object
>>> <class 'object'>
>>>
>> Ok. My fault :)
>
> Ale...? :) - nigdy nie byłem fanem takiego drążenia języka prog., ale
> jak już drążymy, to:
> Python 2.7.1
>> class Fooc(object):
>>
>> ... pass
>>
>> issubclass(type(Fooc), type(object))
>> True
> A przy funkcji było:
>> False
nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a instancja
klasy...
1,foo,object(),Fooc to nie klasy, a instancje...
klasy to object,type,type(foo),int,Fooc() etc.
oczywiście klasy tez są instancjami klasy type...
--
Jordan Szubert
jacek2v
> >> issubclass(type(Fooc), type(object))
> >> True
> > A przy funkcji było:
> >> False
>
> nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a instancja
> klasy...
> 1,foo,object(),Fooc to nie klasy, a instancje...
> klasy to object,type,type(foo),int,Fooc() etc.
> oczywiście klasy tez są instancjami klasy type...
Ale z tego wynika, że dana funkcja nie jest instancją klasy, tylko
"nieklasy" (:)) funkcja. Inaczej mówiąc funkcja ma oddzielne drzewo
klas.
Nie wiem czy się nie zapętliłem :), późno już i takie dywagacje jakieś
jałowe się stają :). Ale dzięki za pomoc w rozplątywaniu, jak wypiję
trochę więcej piwa, to może to zrozumiem :)
Pzdr.
Jordan Szubert
> On 29 Maj, 13:16, "Jordan Szubert" <use...@joru.us.to> wrote:
>> >> issubclass(type(Fooc), type(object))
>> >> True
>> > A przy funkcji było:
>> >> False
>>
>> nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a
>> instancja klasy...
>> 1,foo,object(),Fooc to nie klasy, a instancje...
>> klasy to object,type,type(foo),int,Fooc() etc.
>> oczywiście klasy tez są instancjami klasy type...
>
> Ale z tego wynika, że dana funkcja nie jest instancją klasy, tylko
> "nieklasy" (:)) funkcja. Inaczej mówiąc funkcja ma oddzielne drzewo
> klas.
nie wynika, nie ma ani drzewa, ani oddzielnego...
>>> function=type(foo)
>>>
function to zwykła klasa dziedzicząca po object, podobnie jak int czy str,
ale foo ani 1 ani "dupa" klasami ani trochę nie są, są jednie obiektami...
Fooc to klasa, ale jak zrobimy Fooc() to dostaniemy instancję, która klasa
nie jest...
wiem, że często używa się błędnie określenia klasa na instancje, ale to
błąd jest...
> Nie wiem czy się nie zapętliłem :), późno już i takie dywagacje jakieś
> jałowe się stają :). Ale dzięki za pomoc w rozplątywaniu, jak wypiję
> trochę więcej piwa, to może to zrozumiem :)
--
Jordan Szubert