🚀 go-pugleaf

On 17 Maj, 21:03, "Stachu 'Dozzie' K."
<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.
Właściwie do obu - a jak chcesz wybrać jednego to do drugiego :)
"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