On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
[...]
>> I żeby nie być gołosłownym:
>> #v+
>> import java.util.ArrayList;
>>
>> class test
>> {
>> public static void main(String[] args)
>> {
>> ArrayList al = new ArrayList();
>> ArrayList<Integer> ial = (ArrayList<Integer>)al;
>>
>> al.add(new Integer(1));
>> al.add("foo");
>> al.add("bar");
>> al.add("baz");
>> al.add("nabla");
>>
>> for (int i = 0; i< ial.size(); ++i)
>> System.out.println(ial.get(i));
>> }
>> }
>> #v-
>>
>> Zgadnij, kiedy to się wywróci, o ile się wywróci? Java 6.26.
>>
>> Przepraszam, ale w poważnym języku o statycznym systemie typów taka
>> głupota zostanie wykryta na etapie kompilacji.
>
> Zostaje wykryta - ja dostaje warning w 1 i 2 linijce main()

Wykryte są jedynie niesprawdzone operacje rzutowania. To zdecydowanie za
mało. Jest istotna różnica między dodaniem Integera i Stringa do
kontenera Integerów: pierwsze powinno się powieść, drugie powinno
wylecieć w powietrze, choćby w czasie wykonania programu przy operacji
dodania elementu.

Poza tym ostrzeżenia nie są dla mnie satysfakcjonujące ze względu na
sposób ich prezentacji i uciszania w sunowskim kompilatorze. Albo muszę
usunąć wszystkie (nie zawsze w ogóle mogę ze względu na inne operacje
użyte w programie), albo dostaję kilometry ostrzeżeń, albo ignoruję
wszystkie jak leci.

> Ignorujesz warning - to tak jakbys stosowal <reinterpret_cast> w C++ -
> widocznie wiesz co robisz.

Chciałbym je zignorować *selektywnie*, a nie dostawać dziesiątki linii,
z których jeszcze muszę ręcznie wydłubać co zignorować, a co nie. To już
wina kompilatora, nie języka.

>> Java jest ewenementem, bo
>> to język o typowaniu statycznym ale dynamicznym.
>>
>
> Tzn chodzi ci o to, ze informacja o typie jest dostepna w runtime?

Nie. Chodzi o to, że *mimo że* informacja o typie jest dostępna w czasie
kompilacji, to sprawdzanie typu zostaje w większości (w kontenerach)
zrzucone na run-time.

> Java
> nie jest tu ewenementem.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2011-08-17 10:12, Artur M. Piwko pisze:
>> Z powyższych, poprawnie używane C++. Z powodu pełnej kontroli typów
>> podczas kompilacji.
>>
>
> To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
> używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
> językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

Object transferMoney(Object arg1, Object arg2, Object arg3, Object arg4)

Powodzenia.

--
MB

do góry

W dniu 2011-08-17 10:12, Artur M. Piwko pisze:
> In the darkest hour on Sat, 13 Aug 2011 23:11:59 +0200,
> Edek<e...@g...com> screamed:
>>>> Ale jakiego zadania? Przecież nic nie opisałeś - wiadomo tylko, że dla
>>>> danych wejściowych program ma wyprodukować wartości wyjściowe. I że
>>>> jest text I/O.
>>>> Wszystkie języki się do tego nadają.
>>> Nie znam takich języków jak Prolog, Lisp, Python, Perl. Zastanawiam
>>> się czy warto któregoś się pouczyć. Czy można tak ogólnie o którymś
>>> z nich powiedzieć, że zapis typowych algorytmów niesie mniejsze ryzyko
>>> pomyłki?
>>
>> Z powyższych, poprawnie używane C++. Z powodu pełnej kontroli typów
>> podczas kompilacji.
>>
>
> To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
> używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
> językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

Wg tego artykułu poprawnie używany Python, to taki, w którym trzeba
dopisać masę testów, które w statycznie typowanym języku "generuje"
i "wykonuje" kompilator.

--
Paweł Kierski
n...@p...net

do góry

On 2011-08-17 14:12, Stachu 'Dozzie' K. wrote:
>>>
>>> Przepraszam, ale w poważnym języku o statycznym systemie typów taka
>>> głupota zostanie wykryta na etapie kompilacji.
>>
>> Zostaje wykryta - ja dostaje warning w 1 i 2 linijce main()
>
> Wykryte są jedynie niesprawdzone operacje rzutowania. To zdecydowanie za
> mało. Jest istotna różnica między dodaniem Integera i Stringa do
> kontenera Integerów: pierwsze powinno się powieść, drugie powinno
> wylecieć w powietrze, choćby w czasie wykonania programu przy operacji
> dodania elementu.
>

W koncu nie wiem, czy chcesz miec kontrole statyczna, czy dynamiczna.

Jesli chodzi o statyczna - to jest. Kompilator nie ma mozliwosci wykryc
zlego typu argumentu dla operacji "add" jezeli wczesniej (poprzez jawne
rzutowanie) programista mowi mu, ze kontener jest okreslonego typu.

Jesli chodzi o dynamiczna - to tez jest. Tyle ze nie w tym miejscu, w
ktorym bys chcial - to fakt.

> Poza tym ostrzeżenia nie są dla mnie satysfakcjonujące ze względu na
> sposób ich prezentacji i uciszania w sunowskim kompilatorze. Albo muszę
> usunąć wszystkie (nie zawsze w ogóle mogę ze względu na inne operacje
> użyte w programie), albo dostaję kilometry ostrzeżeń, albo ignoruję
> wszystkie jak leci.
>

Mozesz uzyc @SuppressWarnings.

>>> Java jest ewenementem, bo
>>> to język o typowaniu statycznym ale dynamicznym.
>>>
>>
>> Tzn chodzi ci o to, ze informacja o typie jest dostepna w runtime?
>
> Nie. Chodzi o to, że *mimo że* informacja o typie jest dostępna w czasie
> kompilacji, to sprawdzanie typu zostaje w większości (w kontenerach)
> zrzucone na run-time.
>

Nie rozumiem. W ogolnosci po wprowadzeniu generykow nie ma potrzeby
_explicite_ sprawdzac typu w runtime (czyli nie ma potrzeby robienia
rzutowania explicite). Niczym to sie nie rozni od dowolnego innego
jezyka bez RTTI.
TreeMap (TreeSet) jest wyjatkiem, bo jej wymagania co do kluczy
(elementow) sa takie, ze albo jest dostarczony Comparator, albo typ
elementu jest podtypem Comparable. To znowu wynika z tego, ze te klasy
powstaly przed wprowadzeniem generykow.

--
Michal

do góry

On 2011-08-17 14:41, Paweł Kierski wrote:
> W dniu 2011-08-17 10:12, Artur M. Piwko pisze:
>> To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
>> używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
>> językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>
> Wg tego artykułu poprawnie używany Python, to taki, w którym trzeba
> dopisać masę testów, które w statycznie typowanym języku "generuje"
> i "wykonuje" kompilator.
>

Gwoli uczciwosci w dyskusji: jak ja rozumiem te argumentacje (chociaz
sie z nia nie zgadzam), to mowi ona tyle, ze i tak musisz miec testy,
zas - w praktyce - jezeli juz je masz to wykrywaja one bledy, ktorych
nie wykryje kompilator.
Wiec to nie jest tak, ze piszemy testy by zastapic statyczna
weryfikacje, lecz piszemy testy tak czy inaczej i niejako przy okazji
mozemy zrezygnowac ze statycznej kontroli typow (bo mamy testy).

--
Michal

do góry

On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
> On 2011-08-17 14:12, Stachu 'Dozzie' K. wrote:
>>>>
>>>> Przepraszam, ale w poważnym języku o statycznym systemie typów taka
>>>> głupota zostanie wykryta na etapie kompilacji.
>>>
>>> Zostaje wykryta - ja dostaje warning w 1 i 2 linijce main()
>>
>> Wykryte są jedynie niesprawdzone operacje rzutowania. To zdecydowanie za
>> mało. Jest istotna różnica między dodaniem Integera i Stringa do
>> kontenera Integerów: pierwsze powinno się powieść, drugie powinno
>> wylecieć w powietrze, choćby w czasie wykonania programu przy operacji
>> dodania elementu.
>>
>
> W koncu nie wiem, czy chcesz miec kontrole statyczna, czy dynamiczna.

Chcę statyczną, ale jak się nie da (bo Java jest typowana statycznie ale
dynamicznie), to niech będzie *jakakolwiek*. A nie żeby mnie zaskakiwało
że mimo wszystko do ArrayList<Integer> da się dodać Stringa.

> Jesli chodzi o statyczna - to jest.

No właśnie niespecjalnie.

>>>> Java jest ewenementem, bo
>>>> to język o typowaniu statycznym ale dynamicznym.
>>>>
>>>
>>> Tzn chodzi ci o to, ze informacja o typie jest dostepna w runtime?
>>
>> Nie. Chodzi o to, że *mimo że* informacja o typie jest dostępna w czasie
>> kompilacji, to sprawdzanie typu zostaje w większości (w kontenerach)
>> zrzucone na run-time.
>>
>
> Nie rozumiem. W ogolnosci po wprowadzeniu generykow nie ma potrzeby
> _explicite_ sprawdzac typu w runtime (czyli nie ma potrzeby robienia
> rzutowania explicite). Niczym to sie nie rozni od dowolnego innego
> jezyka bez RTTI.

Trochę się różni. Miałeś przykład. Typowanie statyczne albo jest, albo
go nie ma. W Javie jest taka podpierdółka, więc liczy się że nie ma.

> TreeMap (TreeSet) jest wyjatkiem, bo jej wymagania co do kluczy
> (elementow) sa takie, ze albo jest dostarczony Comparator, albo typ
> elementu jest podtypem Comparable. To znowu wynika z tego, ze te klasy
> powstaly przed wprowadzeniem generykow.

Nieprawda. To wynika z tego, że generyki są słabą podróbką systemu
szablonów, która bazuje na cukrze składniowym.

--
Secunia non olet.
Stanislaw Klekot

do góry

> On 08/17/2011 10:12 AM, Artur M. Piwko wrote:

> > In the darkest hour on Sat, 13 Aug 2011 23:11:59 +0200,

> > Edek<e...@g...com>  screamed:

> >>>> Ale jakiego zadania? Przecież nic nie opisałeś - wiadomo tylko, że dla

> >>>> danych wejściowych program ma wyprodukować wartości wyjściowe. I że

> >>>> jest text I/O.

> >>>> Wszystkie języki się do tego nadają.

> >>> Nie znam takich języków jak Prolog, Lisp, Python, Perl. Zastanawiam

> >>> się czy warto któregoś się pouczyć. Czy można tak ogólnie o którymś

> >>> z nich powiedzieć, że zapis typowych algorytmów niesie mniejsze ryzyko

> >>> pomyłki?

> >>

> >> Z powyższych, poprawnie używane C++. Z powodu pełnej kontroli typów

> >> podczas kompilacji.

> >>

> >

> > To jest akurat marginalna zaleta. Podobnie sprawdzi się poprawnie
> > używany Python. Nie trzeba ludzi straszyć dynamicznie typowanymi
> > językami. https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

> >

>

> Nikogo nie straszę, znam zalety testów, w dowolnym języku da się napisać

> dowolną ilość linijek.

>

> Sprawa polega na czym innym, mówimy o wyższości jednego języka nad

> drugim w kontekście ilości popełnianych błędów. Tu nie da się ukryć, że

> tak czy inaczej testy są pomocne, że w każdym się robi błędy itd.

> Potrzebna jest inna miara.

>

> W moim osobistym przypadku, ja czasami sprawdzam, ile linijek kodu
> (napisanego, średnio skomplikowanego, przetestowanego) tworzę średnio
> na minutę. I - w moim przypadku - wynik jest następujący: w Pythonie
> średnia jest nieco niższa (sam kod, nie liczę linijek testów) niż w C++
> i niższa niż w Javie. Co mi sugeruje, że moje tempo pisania włącznie
> z poprawianiem kodu jest podobne w Pythonie c++ i Javie, bo Python jest
> bardziej zwięzły.
Od jakiegoś czasu tez sprawdzałem ile piszę kodu, ale na dobę. Rozrzut
mam ogromy nawet w ramach tego samego języka. Ba... często pod koniec
dnia kod jest dużo mniejszy niż na początku :) W szachach w C++ pewnie
by mi wyszła jedna linijka na dobę :) W PHP (ale z małą ilością htmla) to
rekordowo mam 30kb na dobę.
Pozdrawiam.





>

> Ale, przy bardziej skomplikowanym kodzie, mam problem z Pythonem. Być

> może jest to kwestia IDE, że pisząc coś większego muszę dużo uwagi

> poświęcać na to, czy x to float, dict czy lista list, a nie na to, czym

> ta zmienna jest. W c++ mogę otagować nawet floaty, czyli mieć typ

> float-znaczysię-średnia i typ float-znaczysię-mediana, jeżeli tylko

> chcę. Inaczej mówiąc, C++ pozwala tworzyć wiele kontrukcji na

> poziomie typów, które służą poprawności. W Pythonie niby też

> część z tych rzeczy jest możliwa, tylko implementuje się to inaczej,

> ale walidacja ma miejsce w runtime, co a) powoduje, że to robi się

> jeszcze wolniejsze b) trzeba faktycznie wykonać w testach każdą linijkę,

> żeby w ogóle się dowiedzieć, czy nie pomyliłem w kodzie mediany ze

> średnią. Oczywiście, tak jak 2/3 c++, nikt nikogo nie zmusza do

> używania języka właśnie w ten sposób, można pisać w c++ np. bez

> tworzenia template'ów i nawet często tak się właśnie robi. YMMV.

>

> Edek

>



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-08-17 14:59, Michal Kleczek pisze:
> Gwoli uczciwosci w dyskusji: jak ja rozumiem te argumentacje (chociaz
> sie z nia nie zgadzam), to mowi ona tyle, ze i tak musisz miec testy,
> zas - w praktyce - jezeli juz je masz to wykrywaja one bledy, ktorych
> nie wykryje kompilator.
> Wiec to nie jest tak, ze piszemy testy by zastapic statyczna
> weryfikacje, lecz piszemy testy tak czy inaczej i niejako przy okazji
> mozemy zrezygnowac ze statycznej kontroli typow (bo mamy testy).

I piszesz normalnie w silnie-typowanym języku testy sprawdzające typy
argumentów? Czy jak zamiast int przekażesz double to rzuci wyjątek?
Nie sądzę :)

--
MB

do góry

On 2011-08-17 15:12, Stachu 'Dozzie' K. wrote:
> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>>
>> W koncu nie wiem, czy chcesz miec kontrole statyczna, czy dynamiczna.
>
> Chcę statyczną, ale jak się nie da (bo Java jest typowana statycznie ale
> dynamicznie), to niech będzie *jakakolwiek*. A nie żeby mnie zaskakiwało
> że mimo wszystko do ArrayList<Integer> da się dodać Stringa.
>

No przeciez sie nie da - tu dostaniesz blad kompilacji:

void funkcja(ArrayList<Integer> lista) {
lista.add("string");
}

>> Jesli chodzi o statyczna - to jest.
>
> No właśnie niespecjalnie.
>

Bo mozna zrobic rzutowanie? (Zreszta z ostrzezeniem kompilatora).

>>
>> Nie rozumiem. W ogolnosci po wprowadzeniu generykow nie ma potrzeby
>> _explicite_ sprawdzac typu w runtime (czyli nie ma potrzeby robienia
>> rzutowania explicite). Niczym to sie nie rozni od dowolnego innego
>> jezyka bez RTTI.
>
> Trochę się różni. Miałeś przykład. Typowanie statyczne albo jest, albo
> go nie ma. W Javie jest taka podpierdółka, więc liczy się że nie ma.
>

Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -
potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka
"turing complete" bez operacji "unsafe" czyli nieweryfikowalnych
statycznie (takich jak rzutowanie).

>> TreeMap (TreeSet) jest wyjatkiem, bo jej wymagania co do kluczy
>> (elementow) sa takie, ze albo jest dostarczony Comparator, albo typ
>> elementu jest podtypem Comparable. To znowu wynika z tego, ze te klasy
>> powstaly przed wprowadzeniem generykow.
>
> Nieprawda. To wynika z tego, że generyki są słabą podróbką systemu
> szablonów, która bazuje na cukrze składniowym.
>

Nie rozumiem tego zdania.

Pokazalem w innym poscie przyklad jak mozna to zrobic w sposob
statycznie weryfikowalny.

--
Michal

do góry

On 2011-08-17 15:29, Marcin Biegan wrote:
> W dniu 2011-08-17 14:59, Michal Kleczek pisze:
>> Gwoli uczciwosci w dyskusji: jak ja rozumiem te argumentacje (chociaz
>> sie z nia nie zgadzam), to mowi ona tyle, ze i tak musisz miec testy,
>> zas - w praktyce - jezeli juz je masz to wykrywaja one bledy, ktorych
>> nie wykryje kompilator.
>> Wiec to nie jest tak, ze piszemy testy by zastapic statyczna
>> weryfikacje, lecz piszemy testy tak czy inaczej i niejako przy okazji
>> mozemy zrezygnowac ze statycznej kontroli typow (bo mamy testy).
>
> I piszesz normalnie w silnie-typowanym języku testy sprawdzające typy
> argumentów? Czy jak zamiast int przekażesz double to rzuci wyjątek?

Nie w tym rzecz - piszesz testy weryfikujace logike programu. Te testy
niejako przy okazji wykrywaja te same bledy, ktore wykrylby kompilator
jezyka statycznie typowanego.
Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest
pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,
to masz za malo testow".

--
Michal

do góry