🚀 go-pugleaf

On May 17, 9:35 am, "Stachu 'Dozzie' K."
<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