W dniu 2013-02-08 19:18, Andrzej Jarzabek pisze:
> On Feb 8, 10:20 am, Maciej Sobczak <s...@g...com> wrote:
>> W dniu czwartek, 7 lutego 2013 23:07:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>>
>>> Normalnie, reflektujesz, wypisujesz checkboxy, z refleksji wynika, że
>>> biorąc pod uwagę wszystkich checkboxy A jest lepsze od B, ale A ma tylko
>>> 5 checkboxów po swojej stronie, a B 15, więc z liczenia wychodzi, że B
>>> jest lepsze.
>>
>> Przepraszam, ale tego kompletnie nie zrozumiałem. Mogę prosić np. o analogię
samochodową?
>
> Nie znam się na samochodach, ale powiedzmy, że porównujesz do floty
> Forda Mondeo i Bentleya. Przy Bentleyu jest piętnaście checkboxów, a
> przy Fordzie Mondeo tylko jeden "jest tańszy od Bentleya". Liczysz
> checkboxy i wychodzi, że powinieneś wybrać Bentleya.
>

A może źle dobrane checkboxy, a w zasadzie jest ich za mało
może powinno się dopisać:

koszt części zamiennych
czas oczekiwania na naprawę
odległość do serwisu
kosz ubezpieczenia
prestiż
reakcja sąsiadów
możliwość montaży fotelika
zachowanie w zimie, na mokrej drodze
awaryjność

i tak dalej jeszcze np 50..100..300 w zależności od wagi decyzji

naturalnie to na czym nam bardziej zależy bardziej uszczegółowimy
rozbijając na zagadnienia elementarne pozbywamy się problemu wag






--
Darek

do góry

On 08/02/2013 20:56, darekm wrote:
> W dniu 2013-02-08 18:14, Andrzej Jarzabek pisze:
>
>>> To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
>>> możesz zabronić. Przy statycznym typowaniu każda funkcja ma
>>> zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
>>> innych jej nie użyjesz. A wraz ze wzrostem programu liczba kontekstów
>>> niepoprawnych rośnie szybciej niż tych poprawnych.
>>
>> Można ograniczyć ten efekt odpowiednio projektując kod.
>
> Przy wsparciu języka to ograniczenie jest skuteczniejsze.

Ale ma swój koszt.

>>>> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
>>>> Może nie zawsze, ale przynajmniej niekiedy.
>>> Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.
>> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
>> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
>
> Co jest prostsze: "odpowiednio" projektować kod, czy tylko wprowadzać
> więcej typów wraz z ewentualnie duplikowaniem kodu, szczególnie że to
> ostatnie jest w mniejszym lub większym zakresie mechaniczne.

Odpowiednie projektowanie jest inne w językach statycznie typowanych niż
dynamicznie typowanych. W statycznie typowanym języku też możesz mieć
problem duplikacji kodu, który wykonuje te same operacje, ale na
niekompatybilnych typach. Żeby zlikwidować ten problem musisz przerobić
kod np. modyfikując hierarchię typów. Różne języki oferują różne
idiomatyczne narzędzia do tego, interfejsy i generyki w Javie, w C++
masz szablony ze specjalizacją i wielodziedziczenie, włącznie z
dziedziczeniem normalnym i wirtualnym. Nie zawsze jest oczywiste, które
rozwiązanie jest właściwe, i nie zawsze rozwiązanie, które likwiduje
duplikację i "działa" ma jeszcze dodatkowo te zalety, że kod jest
czytelny i łatwy w utrzymaniu.

> Poza tym struktury danych i relacje między nimi masz dane w
> specyfikacji. Typy to mechanizm separacji, aby błędnie nie mieszać
> niewłaściwych struktur i narzędzi.

W specyfikacji czego? W firmach, w których zdarzyło mi się pracować,
programiści mieli dane co najwyżej specyfikacje wymagań, tworzenie typów
danych do realizacji tych wymagań należało do zadań programisty.

Oczywiście jeśli kto inny to zroi, to niczego to nie rozwiązuje, b nadal
ktoś musi to zrobić - raczej jeszcze pogarsza to sprawę.

>>> Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
>>> funkcji/struktury
>>
>> W pewnych sytuacjach tak, ale czasem ci powie, że błąd, bo typ X nie
>> istnieje i faktycznie, po refaktoryzacji nie istnieje.
>
> czyli dobrze, nieprawdaż?

Niedobrze, bo muszę się zastanawiać, jak wpasować wcześniej dobrze
działający kod do nowego systemu typów - i ewentualne ponowne
przerobienie tego systemu. W sytuacji z dynamicznym typowaniem nie masz
tego problemu, bo o ile wykonanie danej operacji na danym obiekcie ma
sens z punktu widzenia funkcjonalności, to możesz to po prostu zrobić.

>>>> Wprowadzasz duplikację. No i pojawiają się dalsze problemy, co na
>>>> przykład, jeśli chcesz skopiować structa i owej kopii dołożyć kilka
>>>> nowych pól?
>>>
>>> Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.
>>
>> Przykład był przecież uproszczony, jeśli funkcja korzysta z siedmiu
>> pól, to przekażesz jej siedem argumentów?
>>
>
> zacytuję:
> "Można ograniczyć ten efekt odpowiednio projektując kod."

Rozmawiamy w tym momencie o bardzo konkretnym projekcie, który podobno
miał dawać w języku ze statycznym typowaniem zalety języków typowanych
dynamicznie.

Oczywiście, że w językach statycznie typowanych można (zwykle) rozwiązać
problem, o którym dyskutujemy w sposób ograniczający duplikację poprzez
odpowiedni projekt, ale też nie znajdziesz sposobu, który jest równie
wygodny, szybki, prosty i czytelny jak rozwiązanie w języku typowanym
dynamicznie.

>>> Po drugie to kompilator zabroni mi wywołać
>>> foo(foo(c))
>>
>> Nawet jeśli właśnie foo(foo(c)) jest dokładnie tym, co chcesz zrobić.
>
> Jeśli tak jest to będzie istniała odpowiednia definicja.

Sama się zaistniała?

> Jeśli nic nie zrobię to znaczy że nie chcę takiej konstrukcji.
> Mam wybór.

Napisałeś taką konstrukcję, załóżmy, że dlatego, że chciałeś.

>> Nie bardzo rozumiem, jak to się ma do tematu dyskusji. Chcesz
>> powiedzieć, że samochody rodzinne są niepotrzebne, skoro można rodzinę
>> zapakować w dwa tiry i wybrac sobie takie jezioro, do którego prawie
>> dojeżdża uprawniona droga?
>
> Zupełnie odwrotnie. Pytanie brzmi: dlaczego tiry są takie popularne
> skoro mają tyle ograniczeń. W analogii do języków z typowaniem
> statycznym, w których tyle się trzeba "napracować" aby cokolwiek działało.

No więc trochę nie trafiłeś z tą analogią, bo przecież ja nie mówię, że
języki ze statycznym typowaniem są popularne bez powodu, tylko dyskutuję
z tezą, że to, co dają języki dynamicznie typowane albo masz też w
językach statycznie typowanych, albo jest bezużyteczne.

do góry

W dniu sobota, 9 lutego 2013 14:22:40 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Nie zawsze jest oczywiste, które
> rozwiązanie jest właściwe, i nie zawsze rozwiązanie, które likwiduje
> duplikację i "działa" ma jeszcze dodatkowo te zalety, że kod jest
> czytelny i łatwy w utrzymaniu.

Panowie dajcie jakiegoś linka do przykładów takich sytuacji. Chcę
zobaczyć takie sytuacje w których ktoś zabrnął w projektowy-ślepy
zaułek i w Java/C++ mam problem, a w Rubym, Pythonie nie ma problemu.
Chodzi o problem tego typu, że w Java/C++ musi się wyraźnie więcej
napracować, namyśleć, zastanowić, a w Rubmy i Pythonie rozwiązanie
jest (raczej) jedno i przy pomocy prostej sztuczki dostosuje
projekt do nowych wymagań.

Nie potrafię dalej prowadzić dyskusji. Nie wiem o jakich
zaletach/wadach rozmawiamy

Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Nie potrafię dalej prowadzić dyskusji.
> Nie wiem o jakich zaletach/wadach rozmawiamy

A chcesz sie dowiedziec ?
Jakos takie wrazenie odnosze, ze nie chcesz, a jedynym
Twoim celem jest udowodnienie, ze statyczne typowanie jest
najlepsze zawsze, wciaz i w ogole.
Mylę się ? Udowodnij ze nie.

PS: Najpierw trzeba zaczac "od poczatku" czyli od tego _czym_ jest
statyczne typowanie.
Jaki jest cel jego wprowadzenia i czy byl to cel przemyslany czy tylko
"tak wyszlo" z czasem.

AK

do góry

Użytkownik "Roman W" <b...@g...pl> napisał:

> No ale bez prymitywnego "double" nie istnialaby numeryka w Javie.

Co ? :)
Nie istnialaby, gdyby byla oparta wylacznie na java.lang.Double() ?
Nie zmyslaj.

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Nie wiem o jaką użyteczność chodzi, ale może to by załatwiała metoda
> wirtualna?

Nie.

AK

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> napisał:

> To samo z czymkolwiek innym: obiekty można obsługiwać w sposób
> jednolity, ale do typów wbudowanych trzeba specjalnie tworzyć dodatkowe
> elementy.

Jesli masz takie wyrafinowane potrzeby to sobie od poczatku uzywaj
obiektowych odpowiednikow typow prostych i juz.
Bedziesz mial jednolicie.
Pytanie ile jest sutuacji gdzie obiektowosc takiego inta jest jest naprawde
wazna w stosunku do jego zwyklego uzywania pozostawiam kazdemu
wileoletniemu praktykowi do prywatnego rozwazenia/usmiechu:)

PS: No chyba ze dla Ciebie jest problemem gdy musisz napisac np abs(a)
zamiast a.abs(), czy str(a) zamiast a.toStr().
Jesli jak, to wybacz. Wymiekam :)

AK

do góry

W dniu sobota, 9 lutego 2013 16:29:21 UTC+1 użytkownik AK napisał:
> Użytkownik "M.M." <m...@g...com> napisał:
>
>
>
> > Nie potrafię dalej prowadzić dyskusji.
> > Nie wiem o jakich zaletach/wadach rozmawiamy
>
> A chcesz sie dowiedziec ?
Dowiedzieć się chcę, inna sprawa czy będę mógł w swoich
projektach zrezygnować z C++ na rzecz innego języka. Zwykle
potrzebuję języka który się kompiluje do języka maszynowego,
oszczędza każdy MB pamięci, w którym można przewidzieć czy
pamięć cashe zostanie w miarę dobrze wykorzystana, itd.


> Jakos takie wrazenie odnosze, ze nie chcesz,
To bym nie wspominał że może coś ze mną nie tak i
dlatego nie rozumiem i bym nie prosił o materiały.


> a jedynym Twoim celem jest udowodnienie, ze
> statyczne typowanie jest najlepsze zawsze, wciaz i w ogole.
Nie mam ani takiego celu, ani przeciwnego. Na razie zwyczajnie
nie widzę wyraźnych zalet, nie bardzo wiem jakie stanowisko
przyjąć. Padło porównanie do asemblera i języka wysokiego
poziomu. Nie wiem, ale podejrzewam, że typowanie statyczne i
dynamiczne nie wprowadza aż tak wiele, jak wprowadziły języki
wyższego poziomu niż asembler.


> Mylę się ? Udowodnij ze nie.
Daj linka do najlepszej Twoim zdaniem książki na ten temat,
najlepiej polskojęzycznej, zamówię, przeczytam, pogadamy, to
powinno udowodnić.

Pozdrawiam

do góry

On 08/02/2013 17:52, M.M. wrote:
> W dniu piątek, 8 lutego 2013 18:14:45 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
>> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
> Moim zdaniem jest to kwestia szczęścia. Jeśli nie odgadniemy jak
> projekt w przyszłości będzie się rozwijał, to w każdym języku
> dogłębna (nie kłóćmy się o zmianę int na double - to niezauważalnie mały
> nakład pracy) refaktoryzacja staje się koszmarem.
> Przerabianie samochodu albo łodzi na amfibię zawsze jest trudniejszym
> zadaniem niż produkcja amfibii od zera.

Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
fianasowych na program do sterowania samolotem. Można przewidzieć, że
przerabianie programu do wyceny instrumentów finansowych może np.
uwzględnić inne rodzaje instrumentów finansowych i inne metody wyceny
niż oryginalnie przewidywano.

Problem jest taki, że jeśli spróbujesz zaprojektować swoją hierarchię
typów tak, żeby uwzględnić wszelkie możliwe rodzaje instrumentów
finansowych, to wykonasz gigantyczny kawał nikomu nie potrzebnej roboty,
ale też stworzysz gorszy program, bo bardziej skomplikowany, trudniejszy
do zrozumienia, a zatem łatwiej będzie popełnić w nim błąd, i trudniej
go zmienić np. uwględniając instrument finansowy, którego nie
uwzględniłeś w pierwotnym projekcie (bo, powiedzmy, jeszcze nie istniał).

Natomiast jeśli chodzi o przerabianie programu do wyceny instrumentów
tak, żeby wyceniał nowe instrumenty, żeby stosował nowe metody wyceny,
czy żeby cośtam jeszcze robił z tymi instrumentami czy wycenami, czego
pierwotnie nie przewidziałeś, to refaktoryzacja w celu uwzględnienia
danej funkcjonalności nie musi być koszmarem, pod warunkiem, że się
stosuje odpowiednie praktyki.

No i oczywiście może tak być, że ta refaktoryzacja jest dużo prostsza,
przyjemniejsza i mniej podatna na błędy jeśli stosujesz dynamiczny
system typów.

> Znowu muszę zapytać jak zdarta płyta: jaki jest przykład takiej refaktoryzacji
> która będzie trudna w C++, a łatwa w Pythonie, Rubym i reszcie.

PIeczołowice zaprojektowałeś system typów opierając się na założeniu, że
dinozaur to rodzaj gada, a tu nagle się okazuje, że niektóre dinozaury,
które musisz obsłużyć w swoim systemie, w myśl twojego systemu typów
wcale nie są gadami tylko ptakami. W statycznym systemie typów musisz
wszystko teraz przerabiać, przy dynamicznym typowaniu nie przejmujesz
się - jeśli masz funkcję obsługującą dinozaura, to możesz tam wrzucić
dinozaura, niezależnie od tgo, czy jest gadem czy nie.

> Mnie się
> wydaje to bardzo pomocne gdy kompilator C++ krzyczy już w trakcie
> kompilacji że się typy nie zgadzają.

Zwłaszcza jeśli wymaganą logikę możesz zaimplementować w tydzień, a
przez kolejne trzy tygodnie będziesz uciszał krzyki kompilatora.

do góry

W dniu sobota, 9 lutego 2013 18:45:20 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
> fianasowych na program do sterowania samolotem.
No więc jeśli rozmawiamy o przerabianiu tego typu, to z całym
szacunkiem, ale nie rozumiem dlaczego w Java/C++ jest znacznie
trudniej.

> Można przewidzieć, że
> przerabianie programu do wyceny instrumentów finansowych może np.
> uwzględnić inne rodzaje instrumentów finansowych i inne metody wyceny
> niż oryginalnie przewidywano.
Zbliżamy się do konkretnych przykładów - fajnie.


> Problem jest taki, że jeśli spróbujesz zaprojektować swoją hierarchię
> typów tak, żeby uwzględnić wszelkie możliwe rodzaje instrumentów
> finansowych, to wykonasz gigantyczny kawał nikomu nie potrzebnej roboty,
> ale też stworzysz gorszy program, bo bardziej skomplikowany, trudniejszy
> do zrozumienia, a zatem łatwiej będzie popełnić w nim błąd, i trudniej
> go zmienić np. uwględniając instrument finansowy, którego nie
> uwzględniłeś w pierwotnym projekcie (bo, powiedzmy, jeszcze nie istniał).
Nie musi być tak, że program bardziej ogólny jest trudniejszy w
analizie, zaprojektowaniu i implementacji niż program wyspecjalizowany.
Powiedziałbym wręcz, że zwykle proście się pisze, jeśli od razu,
nawet w wyspecjalizowanym programie, robi się dobre abstrakcje. Owszem,
w prostym/wyspecjalizowanym programie, jest trochę szybciej jeśli
niechlujnie sobie wrzucimy dane do kilku struktur/tablic. Zdarza mi
się samemu tak niechlujnie pisać. Jednak takie programowanie naraża
nas na straty czasu w trakcie debugowania. Narzut czasu na kilka
definicji abstrakcyjnych klas zwróci się w postaci mniejszej ilości
błędów.


> Natomiast jeśli chodzi o przerabianie programu do wyceny instrumentów
> tak, żeby wyceniał nowe instrumenty, żeby stosował nowe metody wyceny,
> czy żeby cośtam jeszcze robił z tymi instrumentami czy wycenami, czego
> pierwotnie nie przewidziałeś, to refaktoryzacja w celu uwzględnienia
> danej funkcjonalności nie musi być koszmarem, pod warunkiem, że się
> stosuje odpowiednie praktyki.
Zgadzam się że nie musi. Dużo zależy od dobrego projektu, ale od
szczęścia też nie mało. Skoro od szczęścia niemało to może dobrze
się składa, mamy dzięki temu grunt na którym języki programowania mogą
pomagać.


> No i oczywiście może tak być, że ta refaktoryzacja jest dużo prostsza,
> przyjemniejsza i mniej podatna na błędy jeśli stosujesz dynamiczny
> system typów.
Wiem od początku do czego zmierzasz, problem w tym, że nie wiem dlaczego
masz rację.


> PIeczołowice zaprojektowałeś system typów opierając się na założeniu, że
> dinozaur to rodzaj gada, a tu nagle się okazuje, że niektóre dinozaury,
> które musisz obsłużyć w swoim systemie, w myśl twojego systemu typów
> wcale nie są gadami tylko ptakami. W statycznym systemie typów musisz
> wszystko teraz przerabiać, przy dynamicznym typowaniu nie przejmujesz
> się - jeśli masz funkcję obsługującą dinozaura, to możesz tam wrzucić
> dinozaura, niezależnie od tgo, czy jest gadem czy nie.
Zgadza się poza najważniejszym: "wszystko przerabiać". Zresztą
nie wiem... może piszesz o jakimś przypadku w którym naprawdę wszystko
trzeba przerabiać. Tak czy inaczej nie widzę tego że trzeba wszystko
przerabiać. O jakie dokładnie przeróbki chodzi z tymi dinozaurami?
Mam nadzieję że nie piszesz tego w nawiązaniu do naszych dawnych
rozmów, kiedy to ja pisałem wręcz o całkowitym przepianiu programu od
nowa. Wtedy pisałem tak w zupełnie innym kontekście, a mianowicie w
kontekście ekstremalnej optymalizacji.


Wracając do Twojego przykładu z dinozaurami. Przykład jest dobry, ale
jeszcze za mało konkretny. Dlaczego w Java/C++ nie można takiego
Dinozaura przerobić na klasę bazową, a następnie z niej wyprowadzić klas
Gad i Ptak? Stare algorytmy przecież zadziałają tak samo jak działały do
tej pory. Algorytmy na nowych cechach Ptaka trzeba dopisać bez względu na
użyty język.


> Zwłaszcza jeśli wymaganą logikę możesz zaimplementować w tydzień, a
> przez kolejne trzy tygodnie będziesz uciszał krzyki kompilatora.
Mój przykład z łodzią, samochodem i amfibią zamieniłeś na prosty
program do instrumentów finansowych i skomplikowany program do instrumentów
finansowych. Więc ja Twoje trzy tygodnie krzyków zamieniam na kilka
godzin w stosunku tygodnia roboty, a przy okazji tych kilku godzin
kompilator wychwyci błędy, które wyszłyby dopiero w trakcie uruchamiania.
W sumie może być większy zysk czasu z powodu mniejszego nakładu pracy
w trakcie uruchamiania.

Pozdrawiam

do góry