On 14/08/2011 08:05, Marszalkowski wrote:
>
>> a jak duze sa te programy (w tysiacach lini?) 50 tys?
>> mniej? wiecej?
> Nie są zabójczo duże, są skomplikowane. Algorytmy są
> trudne i zapis jest popaprany w celu przyspieszenia.
>
>> mz python raczej odpada bo pewnie byloby niesamowicie
>> wolno - slabo znam pythona ale cos tak mi sie wydaje
> Aplikacja testowa może działać wolno. Aplikacja pierwotna
> na wyrywki zrzuci dane wejściowe i wyniki obliczeń do pliku.
> Aplikacja testowa wczyta wiersz danych, może sobie długo
> liczyć bezpiecznym algorytmem i sprawdzić czy wyjście jest
> takie samo.

Ja bym w tej sytuacji pomyślał najpierw o napisaniu unit testów, w C++
ale bez głupich optymalizacji. To prawda, że C++ ma więcej potencjału do
popełniania błędów niż niektóre inne języki, ale przy czytelnym zapisie
algorytmu i zastosowaniu odpowiednich technik możesz mieć równie dobre
zabezpieczenia, co w Javie - np. w celu kontroli zakresu na tablicach
zamiast gołych tablic można użyć boost::array z at(), zdecydowanie
ograniczyć gołe wskaźniki do sytuacji absolutnie wyjątkowych (i
szczelnie opakowanych) itd. itp.

Testy end-to-end można robić w dowolnym języku, ale możesz chcieć
rozważyć to, że szybkość ich działania też może być nie bez znaczenia, w
szczególności jeśli chcesz nimi duplikować intensywne obliczenia:
idealnie chciałbyś móc zapuścić suitę testów regresyjnych na każdym
nightly buildzie, a sam fakt przemielenia większej ilości takich testów
też daje większą pewność. Pod tym względem chyba faktycznie jedynym
poważnym konkurentem C++ jest Ada. Ale też bym nie liczył na to, że
zmiana języka da ci w tym przypadku jakąś kolosalną różnicę. Już lepiej
pomyśleć dłużej nad projektem.

Natomiast w miarę obejmowania programu testem, powinieneś wykorzystywać
pojawiające się okazje do wyplenienia szpetoty z kodu produkcyjnego.
Obstawiam, że w bardzo wielu miejscach, gdzie ta szpetota jest
uzasadniana wydajnością, wcale nie jest ona potrzebna. Po prostu dobrze
pamiętać, które rzeczy w C++ bardzo skutecznie redukowane są przez
optymalizację. Może się okazać, że nawet te ujemne indeksy praktycznie
nic nie dają :)

do góry

Użytkownik "A.L." <l...@a...com> napisał w wiadomości grup
dyskusyjnych:jdti47t56m8sk1dihm5avsl62oc5ucf407@4ax.
com...
> Ja napisakem: UZYWALEM W FORTRANIE IV. FORTRANIE _ CZTREY

Dziurkowanie kart było fascynujące, naprawdę.

do góry

On Tue, 16 Aug 2011 01:26:06 +0200, "slawek" <s...@h...pl> wrote:

>
>Użytkownik "A.L." <l...@a...com> napisał w wiadomości grup
>dyskusyjnych:jdti47t56m8sk1dihm5avsl62oc5ucf407@4ax
.com...
>> Ja napisakem: UZYWALEM W FORTRANIE IV. FORTRANIE _ CZTREY
>
>Dziurkowanie kart było fascynujące, naprawdę.
>

Dziurkowanie tasmy papierowej etz. Albowiem moim pierwszym jezykiem
programowania byl jezyk W20, a pierwsza maszyna UMC1. Na lampach

A.L.

do góry

On Sat, 13 Aug 2011 21:09:15 +0200, "Marszalkowski" <m...@t...pl>
wrote:

>My?lę sobie aby przepisać te projekty w innym
>języku. Teoretycznie powinienem dostać dla takich
>samych danych wej?ciowych takie same dane wyj?ciowe.
>Chcę zrobić rodzaj walidacji krzyżowej.

Jeden z glupszych pomyslow o jakich slyszalem.

Przygotuj po prostu dane wejsciowe i popatrz czy dane wyjsciowe sie
zgadzaja. W koncu chyba blad jest pojeciem obiektywnym w stosunku do
przetwarzania danych.

milego dnia zycze
--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

do góry

On 2011-08-15 21:46, Maciej Sobczak wrote:
>
> Jawne deklarowanie wyjątków się nie sprawdziło w praktyce i Javowcy
> masowo to pomijają. Nie, nie chodzi o początkujących adeptów, robią
> tak również projektanci poważnych frameworków. Po prostu się nie
> sprawdziło.
>

Wydaje mi sie, ze "sie nie sprawdzilo" nie dlatego, ze jest "zle samo w
sobie", ale raczej z tego samego powodu, dla ktorego Ada jest taka
popularna jaka jest - zeby sensownie uzyc wymaga zbyt powaznego
pomyslunku dla przecietnego programisty. Co gorsza - wymaga projektu, co
w czasach agile jest takie passe.

>> silniejsza kontrola typów
>
> Np. gdzie?
>
> Bo ja znalazłem taki fajny przykład:
>
> import java.util.TreeSet;
>
> class NonComparable {}
>
> public class Test {
> public static void main(String[] args) {
> TreeSet<NonComparable> mySet = new TreeSet<NonComparable>();
> mySet.add(new NonComparable());
> mySet.add(new NonComparable());
> }
> }
>
> W funkcji main są trzy linijki.
> W języku z poważną statyczną kontrolą typów powinien być błąd
> kompilacji w pierwszej linii, gdzie tworzony jest bezsensowny typ
> zbioru. Tak się stanie np. w Adzie (w równoważnym przykładzie).
>
> W języku z trochę gorszą kontrolą typów poleci błąd kompilacji w
> drugiej linii, gdzie dodawany jest element do zbioru. Tak jest w C++.
>
> W języku, który jest niepoważny, błąd poleci dopiero w run-time i
> dopiero w trzeciej linii, chociaż ona kompletnie nie różni się od
> drugiej. Tak jest w Javie i większości skryptowych.
>
> Sorki, ale dla mnie to lipa.
>

Dobre.
Ale nieprawdziwe :)
Java rzuci ClassCastException na pierwszym add (fakt - w runtime).
1. Wymaga tego specyfikacja TreeSet.add()
2. Zweryfikowalem zrodla - TreeSet jest implementowany przez TreeMap,
ktorej put() w przypadku gdy mapa jest pusta probuje porownac klucz sam
ze soba (wlasnie w celu zweryfikowania typu).

Z drugiej strony - nie jestem pewny czy to wina jezyka, czy takiej a nie
innej konstrukcji biblioteki std. W koncu nic nie stalo na przeszkodzie
by zrobic dwie klasy ( a nie bez sensu je kleic ):
TreeSet1<T extends Comparable<? super T>>
TreeSet2<S, T extends Comparator<? super S>>

API _zawsze_ mozna spieprzyc - niezaleznie od jezyka. Spieprzyc API jest
bardzo latwo, bo zrobienie dobrego API jest truuudna sztuka :)

Fakt, ze generyki zostaly do jezyka dodane pozno i biblioteka std nie
mogla byc wywrocona do gory nogami, wiec ich wykorzystanie w niej nie
moze byc pelne.

Tak przy okazji - dlaczego w C++ wysypie sie kompilacja na _pierwszym_
add? (Moj C++ troche juz zardzewial i mnie zaciekawilo...)

--
Michal

do góry

On 2011-08-16 08:27, Michal Kleczek wrote:
> Tak przy okazji - dlaczego w C++ wysypie sie kompilacja na _pierwszym_
> add? (Moj C++ troche juz zardzewial i mnie zaciekawilo...)
>

Dokonczylem kawe i juz wiem :) Nie bylo pytania.

--
Michal

do góry

Marszalkowski pisze:
> No ale widzę że nikt nie przychyla się do opinii że w
> niektórych językach robi się mniej błędów :)

Robi się co najwyżej inne błędy.

--
Kaczus
http://kaczus.republika.pl

do góry

Dnia 15-08-2011 o 21:46:29 Maciej Sobczak <s...@g...com>
napisał(a):

>> *W tym kontekście* absolutnie zgadzam się ze stwierdzeniem, że wJavie
>> robi się mniej błędów.
>
> Otóż nie, to nie przeszkadza w robieniu błędów. Ten mechanizm je co
> najwyżej wykrywa. W run-time. Nic nie stoi na przeszkodzie, żeby
> wysłać klientowi program z błędem i w tym kontekście uważam, że Java
> nie wnosi istotnego postępu w dziedzinie poprawności.

Ok, może w przypadku testowania zakresów tablic tak. Ale popatrz na taki
przypadek:

switch (myEnum)
{
case enVal1:
{
x = someOtherVarX / 2.0f;
y = someOtherVarY / 2.0f;
}
default:
{
x = NaN;
y = NaN;
}
}

W C++ powyższy kod się skompiluje i będzie działał zgodnie z tym, co
programista napisał (choć raczej niezgodnie z tym, co zamierzał). W C#
próba kompilacji takiego kodu skończy się błędem (w Javie, natomiast,
przejdzie).

Zmierzam do tego, że - choć język jako taki nie może wykluczyć powstawania
błędów - to jednak istnieją takie jego konstrukcje, które znacznie
zmniejszają prawdopodobieństwo posadzenia takiego buraka, jak w powyższym
przykładzie (chodzi mi o ogólną zasadę, a nie o ten czy inny konkretny
przypadek).

W końcu zarówno Java jak i C# wyewoluowały z C++, co dało projektantom
szansę poprawienia niektórych językowych konstrukcji.

W dyskusji wspominana jest Ada. Nie znam tego języka, ale czytałem o nim
kiedyś, że jest pełen nadmiarowych konstrukcji językowych - na przykład
koniec bloku wymaga informacji, jaki to był blok (np. END PROCEDURE).
Przymus kończenia bloku case instrukcją break, goto lub return w C# jest w
pewnym sensie nadmiarowy, ale znacząco ogranicza możliwość popełnienia w
tym miejscu błędu. Wydaje mi się, że istnieje silna zależność pomiędzy
stosunkiem szybkości i wygody pisania w danym języku a jego
błędogennością. Niedawno nadziałem sie na C++owe max, które wywołane dla
parametrów rand() - 2 i 0 zwróciło nagle -1. W Delphi, C# i Javie nie da
się napisać odpowiednika C++owego makra, które w konkretnych
okolicznościach może działać niezgodnie z założeniami. Niemożność
stosowania makr w pewnym stopniu utrudnia pisanie, ale z drugiej strony
eliminuje możliwość popełnienia trudnego do zlokalizowania błędu.

W C++ można bardzo łatwo strzelić sobie w stopę trzymając w jednej ręce
komplet tomów encyklopedii Britannica, a w drugiej - średniej wielkości
piłkę plażową. Ale na przykład w C# trzeba już mieć na wyposażeniu karabin
snajperski :)

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

On Tue, 16 Aug 2011 08:27:14 +0200, Michal Kleczek
<k...@p...onet.pl> wrote:

>On 2011-08-15 21:46, Maciej Sobczak wrote:
>>
>> Jawne deklarowanie wyjątków się nie sprawdziło w praktyce i Javowcy
>> masowo to pomijają. Nie, nie chodzi o początkujących adeptów, robią
>> tak również projektanci poważnych frameworków. Po prostu się nie
>> sprawdziło.
>>
>
>Wydaje mi sie, ze "sie nie sprawdzilo" nie dlatego, ze jest "zle samo w
>sobie", ale raczej z tego samego powodu, dla ktorego Ada jest taka
>popularna jaka jest - zeby sensownie uzyc wymaga zbyt powaznego
>pomyslunku dla przecietnego programisty. Co gorsza - wymaga projektu, co
>w czasach agile jest takie passe.
>

Fakt. jak sie programuje w Adzie to paradygmat "code first, think
later" sprawdza sie dosyc slabo

A.L.

do góry

On Aug 16, 8:27 am, Michal Kleczek <k...@p...onet.pl> wrote:

> Dobre.
> Ale nieprawdziwe :)

Sprawdziłeś?

> Java rzuci ClassCastException na pierwszym add (fakt - w runtime).

To ja mam zepsutą Javę (1.6.0), bo u mnie rzuca dopiero na drugim add.

> 1. Wymaga tego specyfikacja TreeSet.add()

Wg. dokumentacji (6) wyjątek leci "if the specified object cannot be
compared with the elements currently in this set ". Czyli jeśli zbiór
jest pusty, to ma nie lecieć.

> 2. Zweryfikowalem zrodla

W jakiej wersja Javy?

> ktorej put() w przypadku gdy mapa jest pusta probuje porownac klucz sam
> ze soba (wlasnie w celu zweryfikowania typu).

I to ma być "statyczna kontrola typów"? Porównywanie obiektu samego ze
sobą w run-time?
Ale jaja. :-D

> API _zawsze_ mozna spieprzyc

To nie jest kwestia API. TreeSet<NonComparable> jest bez sensu i w
poważnym języku można to sprawdzić *od razu*. Nawet bez dostępu do
implementacji klasy TreeSet.
Tak, właśnie np. Ada nie potrzebuje widzieć implementacji, żeby
stwierdzić, że to jest bez sensu. I to jest właśnie statyczna kontrola
typów a nie jakieś machanie rękami w run-time.

> Tak przy okazji - dlaczego w C++ wysypie sie kompilacja na _pierwszym_
> add?

Bo wtedy następuje konkretyzacja funkcji add i wtedy kompilator się
zorientuje, że nie ma jak porównać obiektów - nawet jeśli jest to w
niewykorzystanej wtedy gałęzi if.
(ale rozumiem, że już to wiesz :-) )

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry