🚀 go-pugleaf

On 2011-05-24, jacek2v <jacek2v@gmail.com> wrote:
> 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.

-- 
Secunia non olet.
Stanislaw Klekot