On 2019-10-05 07:40, slawek wrote:
> No to popatrz miszczu na coś
> takiego:

Brawo :)

PS: Powinno utrzec nosa MWZWM... ale nie utrze.
Oni wiedzą "lepiej"...

AK

do góry

On 2019-10-05 07:40, slawek wrote:
> Naturalnie możesz radośnie
> sprawdzać że wynik jest różny od pi - bo dla wielu funkcji buz
> tak przypadkiem będzie.

Hehehe

do góry

On 05/10/2019 06:56, AK wrote:
>> wrzuca jakieś pierdoły o Algolu
> O! Znasz Algol?

Jedyny Algol w którym pisywałem to Action!. Nie jest on jednak Algolem
ale czymś podobnym składniowo. Moja straszna zbronia życiowa polega na
tym e urodziłem się za późno aby docenić karty perforowane.

> Chetnie podyskutuje!

A ja nie. Już o jednym trupie rozmawiamy.

> Pisalem w nim kawal zycia.
> Doskonaly jezyk!

Bez wątpienia. Podobnie jak Pascal. Też turing complete.

> PS: Choc wolalnbym o Simuli - jeszcze lepsza.

Super. Otwieraj nowy wątek. Sławek z przyjamnoscią podyskutuje z Tobą o
Algolu w kontekście BCPL. Ja sobie zaś zrobie herbatkę.

do góry

On 05/10/2019 07:02, AK wrote:
>>> Znam natomiast nowy projekt z Adą, link powyżej.
>> Ja znam milion nowych w Verilogu. Też krytycznych, często bardziej niż
>> żelastwo w kosmosie. I wiesz co, wybrali tym razem język wyjątkowo
> > gówniany.
> No wlasnie. No a obok jest sobie o niebo lepszy (w sensie inzynierii
> j.prog) VHDL?

VHDL to Ada. Z domalowanymi duperelami.

I nie wybrali.

Co za chamy. Być może ma to związek z takim drobnym faktem że
weryfikacja jest ważniejsza niż składnia.

A Verilog ma biliard razy więcej narzędzi do weryfikacji niż VHDL i
jednocześnie najbardziej gównianą składnię jaką można sobie wyobrazić.

Ale to dalej chamy. Przecież Ada jest najlepsza.

>> Co robić, taki świat.
> Myslalem cale zycie, ze mlodosc to taki czas, ze chce sie ten swiat
> zmieniac na lepszy (chocby ten malutki wokol siebie i chocby...
> dla wlasnej przyjemnosci/satysfakcji nie godzenia sie z byle g...)
> No a co my tu mamy? Młodziez mentalnie starsza ode mnie? ;)

Świat sobie możesz zmieniać lokalnie. Do zmiany świata na lepsze w
sensie globalnym znacznie lepiej sprawdzają się wojny choć one działają
tylko w sensie statystycznym.

PS. W informatyce prawie nigdy nie wygrywa najlepsze. Wygrywa zawsze
religijność wyznawców jakiejś rzeczy a efekt motyla jest widoczny
bardziej niż gdziekolwiek.

do góry

On 05/10/2019 07:40, slawek wrote:
> trzy linijki, ale to nieistotne) jako dowód tezy że testy
> jednostkowe wyłapią wszystko.

Nikt takiej tezy nie postawił. Pokazałeś przykład, wyjaśniłem Ci że
żałosny a ty dorabiasz filozofię. Reszta to już wewnątrzne głosy.

> No i co? Możesz - a jakże - sprawdzać co będzie gdy n <= 0. Możesz
> ewentualnie sprawdzić, że dla n = 1 powinno być fun(1) = buz(1.0)
> z dokładnością co do maszynowego epsilon. Możesz nawet sprawdzić,
> znając konkretną buz, np. że to logarytm naturalny sinusa,
> jeszcze parę wartości. I na tym koniec. Bo gdy buz będzie
> definiowana przez użytkownika (np. przez podanie kilkunastu liczb
> określających współczynniki, wykładniki itp.)

Jeśli dowolny element badanego kodu nie jest znany na etapie jego
unittestowania to mamy do czynienia z testami nie unit tylko *jakimiś*,
najczęsciej integracyjnymi.

Tak że niestety, nie masz pojęcia o czym bredzisz.

> Przy tym taki drobiazg: testy według ciebie - chcesz 100% coverage

100% coverage mówisz? A jakiego coverage? Wszystkich stanów? Może
wszystkich lini? Może triggera dla wszystkich bitów? Wszystkich gałęzi?
Wszystkich asercji? Może jakiegoś innego z kilkunastu mierników coverage?

Planowanie testowania moze mieć wymóg pokrycia 100% stanów, może mieć
wymóg pokrycia 90% lini itd itp. Zależy co masz w planie testowania. Bo
masz, prawda?

> - powinny objąć jakieś 2**63 czyli około 10**19 wartości...
> jeżeli integer jest 64 bitowy.

Jesli ktoś tak zdefiniował coverage. Całe szczęście nie każdy tak
definiuje. Można powiedzieć że tylko niejaki "sławek" tak defniniuje.

do góry

On 05/10/2019 07:04, AK wrote:
>> Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda
>> kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od
>> unit testów, przez code review po testy integracyjne, wszędzie
>> zostanie wyłapana z dokładnością do asymptoty. Na 99% bug taki
>> zostanie wyłapany już w unit testach, przynajmniej u mnie i zaryzykuje
>> że w każdym poważniejszym programowaniu. Jeśli Ci się wydaje że o
>> takie błedy chodzi wybierając kilka kompilatorów to naprawdę postaraj
>> się zakładać że rozmówcy nie są idiotami i od razu będzie lepiej.
> Powinienies napisac: "wydaje mi sie".

Nie. To jest codzienność mojej pracy.

> Bo naprawde Ci sie tylko wydaje.

Nie.

> PS: No a co z tym 1% ?

Jest zarządzany ryzykiem. Jeśli migasz diodą i to jest clue projektu to
może zostać. Jeśli sterujesz respiratorem to go wyeliminujesz tą bądź
inną metodą testowania. Zarządzanie ryzykiem to obecnie spory fragment
rynku weryfikacji. Bardzo bogatego rynku.

do góry

On 05/10/2019 07:02, AK wrote:
>> Nie wątpie. Wysoki poziom programowania zawsze uzyskuje się tylko w ASM.
> Znasz ASM chocby na tyle co ja? ;)

Kilka. Ale za to mam dłuższego.

do góry

On 05/10/2019 06:42, AK wrote:
>> Zapewniam Cię że w każdym ręcznie wydziobdzianym algorytmie przez
>> domowego hackera znajdzie się ich o rzędy wielkości więcej błędów niż
>> w kodzie dostarczanym z kompilatorem (sprawdzić czy nie Borland i MS).
> Domowego hackiera tak.

Tacy stanowią większość programistów Pascala w latach 80. Znam firmę w
której pracują do dzisiaj.

> Zwyklego (mysle nieskromnie, ze niezlego programisty) nie.
> Chcesz sie zalozyc/przekonac?

Najbardziej zdumiewa mnie próba dowodzenia całości na podstawie
wyjątkow, powszechna w społeczeństwie. Argument "szwagra dziadka wójka
siostra to miała taki przypadek" jak widać działa również w informatyce.

> PS: Mitomania, ze tworcy kompilatorow to jacys Bogowie wciaz
> panuje wsrod Mlodziezy :)

Mitomania że starsi ludzie robią coś lepiej ciągle panuje wśród emerytów.

Prawda jest taka że ani jedni ani drudzy nie mają racji. Znam masę
przykładów i zaprzeczeń tej tezy. Ale nie, nie chcesz ich znać, są
subiektywne.

do góry

On Sat, 05 Oct 2019 10:08:31 +0200, heby wrote:

> On 05/10/2019 07:02, AK wrote:
>>> Nie wątpie. Wysoki poziom programowania zawsze uzyskuje się tylko w
>>> ASM.
>> Znasz ASM chocby na tyle co ja? ;)
>
> Kilka. Ale za to mam dłuższego.

Proponuję, byście obaj dali linka do jakiegoś swojego publicznego
projektu ASM. Nie ma co się sprzeczać o długość - trzeba zmierzyć.

Mateusz

do góry

On 05/10/2019 10:12, Mateusz Viste wrote:
>> On 05/10/2019 07:02, AK wrote:
>>>> Nie wątpie. Wysoki poziom programowania zawsze uzyskuje się tylko w
>>>> ASM.
>>> Znasz ASM chocby na tyle co ja? ;)
>> Kilka. Ale za to mam dłuższego.
> Proponuję, byście obaj dali linka do jakiegoś swojego publicznego
> projektu ASM. Nie ma co się sprzeczać o długość - trzeba zmierzyć.

Niestety jak wielu zakładasz błednie że ludzie parający ię
programowaniem zawodowo robiąteż to samo hobbystycznie. Czasem tak, ale
raczej nie.

Zakładasz również że znajomość asm oznacza pianie w nim projektów. To
raczej oznacza głupotę.

Innymi słowy jeśli chcesz fragmentów kodu, np. takich które na co dzień
wielu z nas pisze to jedyną mozliwoscią jest, po podpisaniu NDA,
zatrudnienie się.

do góry