🚀 go-pugleaf

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