On Sat, 05 Oct 2019 18:00:11 +0200, heby wrote:

> Obawiam się że nie rozumiesz jak pracuje rynek (...)
> Ale możesz podrosnąć oczywiście, (...)

Ach, to już ten drugi etap. Jak się prztyknie chwalipiętę w nos to
zaczynają się obelgi. Masz jednak dużo więcej wspólnego z dziadkiem AK
niż sądziłem. Czyżby megalomania była zaraźliwa? Ja odpadam.

Mateusz

do góry

On 05/10/2019 22:12, Maciej Sobczak wrote:
> No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z
użycia kilku kolejnych kompilatorów?

Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
zrobił mnożenie kiedy x=15 i y=90. Shit happens. Czasem to tylko mignie
szybciej diodą a czasem wyśle samolot w kierunku gruntowym.

> Bo tego cały czas nie pokazałeś.

No więc wyobraź sobie sytuację w któej unit testy posiadają
asymptotycznie pokrycie w 100% zgodne z testplanem.

A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji
bo tak wyszło kompliatorowi. I wykryje buga na produkcji załączając
odwracacz ciągu w powietrzu.

Dodając dodatkowe narzędzia weryfikacyjne (tak, w tym wypadku kompilator
jest takim narzędziem) możesz zrealizować nastepne poziomy weryfikacji
kodu które wynikają z wymogów bezpieczeństwa. I może, dzięki szczęściu,
błąd wykryjesz. Bo w pewnym momencie niestety kończą się środki formalne
a zaczynają statystyczne.

> Wiemy tylko, że "w dużych firmach", czy jakoś tam. Ale tak konkretnie, po co?

Aby zweryfikować narzędzia do weryfikacji. Ponieważ nie potrafimy tego
robić formalnie ani pewnie, pozostaje weryfikacja statystyczna.
Najprościej poprzez użycie podobnych bądź identycznych narzędzi kilku
róznych firm w celu analizy różnicowej.

>> Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze
>> ktos zapyta czy dajesz wiarę w kompilator.
> I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.

Jest narzędziem które odpowiada na pytanie czy kod działa czy nie. Jesli
odpowie źle to możesz sobie całe to unit testowanie wsadzić w dupę.
Czasami odpowiada źle.

> Celem (i ostatecznym produktem) jest kod wynikowy - a jego poprawność właśnie
wykazaliśmy wszystkimi tymi metodami, o których wspomniałeś.

Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
warunki kiedy będzie używany produkcyjnie?

Nie da się tego stwierdzić. Dlatego używa się croos-checków. To jest
BARDZO powszechna praktyka w symulacjach HDL i spotykana praktyka w
programowaniu tradycyjnym.

> Czyli mamy poprawny kod wynikowy.

Nie, testy tego nie wykazują. Testy wykazują że mamy poprawnie
działający kod pod testami. To może być wystarczające jeśli wymogi
bezpieczeństwa są przeciętne i może to być za mało jeśli są wysokie.

Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej
instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat
pozwalający na stosowanie w samolotach musieli, poza wykazaniem
testowania we wszystkich odmianach, zarządzania jakością, weryfikacji
formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni
panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w
ILU różnych symulatorach potwierdzono działanie kodu i czy ich
producenci sami są certyfikowani do użycia w takiej branży.

Z punktu widzenia przeciętnego misaczka programującego pierdoły to jest
bez sensu.

Z punktu widzenia dopuszczeń do zastosowań krytycznych jest kluczowe.
Zarządzanie ryzykiem może prowadzić do czasem pozornie absuralnych akcji.

> Więc po co kolejne kompilatory?

Aby metodami statystycznymi podnieść pewność że to co testujesz nie jest
związane z błędem kompilatora.

>> Istnieją ryzyka gdzie nie można zaufa kompilatorowi.
> Ależ ja mu ani przez chwilę nie ufałem. Ani przez mikrosekundę.
> Ale też nie on jest w centrum uwagi. Więc?

Ale to on napisał na koniec na ekranie "100% testów przeszło".

Możesz mu nie ufać. Cerytyfikator też nie będzie jesli ma się podpisać
pod czymś montowanym jako rozrusznik serca.

PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
trzema kompilatorami. clang, gcc i vc oraz dodatkowo okresowo pod
valgrindem. Codziennie, głównie w celu łownienia różnic składniowych, na
ciągłej integracji. Po kilka razy na co najmniej dwóch z nich. Zgadnij
ile bugów znalazło się w kodzie na jednym z nich który to kod wykazywał
brak błedów na innym? Nie, nie składniowych. 100% testów przeszło na
unit i integracji. A pod innym GPF. Życie.

do góry

On 05/10/2019 22:33, Maciej Sobczak wrote:
>> "Skoro silnik do motorówki pracował na jeziorze to nie ma sensu
>> weryfikować czy się sprawdziw odrzutowcu bo pracował przecież dobrze".
> Słabe. Bardziej: "skoro pracował dobrze w motorówce o długości 4 metry, to powinien
działać dobrze w podobnej motorówce o długości 5 metrów."
> Prawda, że inaczej?

Nie, nie inaczej, jedynie mniej przerysowane.

>> Tego teamu nie ma zapewne. Po takiej przewrotce ludzie może i robią to
>> samo ale nie tak samo.
> Czyli wyciągnięto jakieś wnioski z tego ćwiczenia. Drogo, ale szkolenia nigdy nie
były tanie.

Doatkowy ROM i napisanie kilku ifów też nie wydają się specjalnie
drogie. Ale kto bogatemu zabroni.

>> Procedura awaryjna którą jest samozniszczenie. Fantastycznie.
> https://en.wikipedia.org/wiki/Self-destruct

Ja nie mam pretencji że zdetonował się bo wyleciał wyjątek.

Ja mam pretencję że procedurą awaryjną jak coś się nie mieści w incie
jest rzucenie wyjątku bez łapania i PROCEDURY AWARYJNEJ na tą okoliczność.

>> wystarczyło dodać ifa.
> No to dajesz. Tego ifa. Znaczy - najbardziej mnie interesuje ten kawałek w środku.

A to już zależy od speca. Jeśli spec mówił że cośtam z czujnika nie
będzie większe od 11 na bum cykcyk to było by miło jak by napisał a co
jak nie. Napisał? Speca nie mam, więc nie wiem. Ale wiem że obok
napisali inne checki.

>> Nie było testu weryfikującego odczyt warości z poza zakresu.
> Nie ma przesłanek do takiego twierdzenia.

Uznano że kod zadziała. Czyli testowano, bo przecież nie puszczono go na
słowo honoru.

Skoro wiec testy przeszły, kod był ok i nagle bum to co się stało?
Chiński sabotaż czy dziura w testach? Sorry, ale przeciekanie kodu z
niezabezpieczonym inputem to nie jest nawet przedszkole w testowaniu, a
już na pewno nie w takim zastosowaniu.

> Test mógł być i mógł sprawdzić, czy system wtedy wyzwala sygnał do samozniszczenia.

Więc test był błedny. Bo nagle ta wartość była poprawna. Czyli test
testował czy poprawna wartość zrobi bum. Albo go nie było.

> Test mógł przejść poprawnie. Znaczy - przy rzutowaniu wartości spoza zakresu
wyzwala.
> Zbyt dużo dorabiasz do tej znanej historii.

Nie, ja, ponieważ nie muszę utrzymywać tonu poprawności politycznej, nie
mam problemu aby wyjaśnić że przyczyną nie był pierdzący w stołek
nietechniczny od decyzji. Przyczyną był albo żałosny kod albo żałose
testowanie, oba po stronie programistów. Możliwe że również
specyfikacja, ale naprawdę, jesli to była wina speca to może nalezy ich
rozwiązać i niech sadzą pietruszkę.

>> Ponadto ja tylko troluje.
> Szkoda, że tak tanio i cieniutko. Po tylu latach mógłbyś podnieść skilla w tym
zakresie.

Nie mam czasu na pierdoły, a poziom wystarczający żeby choć troche
rozrywki w życiu mieć odkąd nie ma już Kabareciku Lipińskiej i Monty
Pythona.

>> Najzwyczajniej w świecie spuszczam
>> powietrze z Ady, bo wiele więcej tam nie ma poza nudnym na wskroś
>> następnym językiem imperatywnym tyle że z dużą liczbą wyznawców.
> Nawet nie wiem, od którego z Twoich błędów poznawczych zacząć. Spuszczać nie
trzeba, bo rynek jako całość ucieka od Ady w podskokach.

Widzę, wiem, obserwuje.

> Nie jest następny, tylko jednym z wcześniejszych. A wyznawców jest tylu, że
mieszczą się w dwóch autobusach. Zmierzone naukowo.

Ale każda religia tak kończy i tak zaczyna. Od grupki ludzi w autobusie.
Jedna co bardziej globalna to by do malucha się zmieściła na początku.

>> Ada tak. Ale na rany koguta, z TESTOWANIEM.
> Ależ oczywiście. Tylko jak widać wybór metody i zakresu testów nie jest oczywisty.

Nigdy nie jest.

Ziew.

Może już zakończmy:

- Ada jest zajebista choć COBOL jest czarujący.

- Nikt jej nie chce.

- Testujmy wiecej.

- Pokój na bliskim zachodzie.

do góry

On 05/10/2019 22:55, Mateusz Viste wrote:
>> Obawiam się że nie rozumiesz jak pracuje rynek (...)
>> Ale możesz podrosnąć oczywiście, (...)
> Ach, to już ten drugi etap. Jak się prztyknie chwalipiętę w nos to
> zaczynają się obelgi.

Serio? Czytasz czasami niejakiego Mateuszka Vistę?

"Czyli dalej będziesz się przechwalać, nie mając zupełnie nic do
pokazania, tak jak to robi AK? Naprawdę szkoda."

"przechwalanie się na grupie pozostanie na poziomie przedszkolnego
wykłócania się"

> Masz jednak dużo więcej wspólnego z dziadkiem AK
> niż sądziłem.

Widzisz, mam taką obserwajcę że najwięcej o kulturze mówią ludzie
rzucający kurwami. Trudno powiedzieć czy zdają sobie z tego sprawę, ale
zawsze uważam to za przezabawne.

Najpierw pacnołeś kogoś w twarz a potem wydzierasz się że oddał i
powiesz Pani. No ale co zrobić, IT to miejsce gdzie można znaleźć dziwne
charaktery.

do góry

W dniu 05.10.2019 o 22:48, heby pisze:
> On 05/10/2019 22:01, J-23 wrote:
>>> Qt ogarnia *prawie* wszystkie tematy. Czekam aż będzie tam dostępny
>>> QPornPlayerAndQuantumComputing i doczekam się.
>> LCL działa podobnie jak HibernateSQL jeżeli chodzi o zasde działania
>> mamy w Hibernate
>
> To po co Pascal skoro mamy to już gotowe w innych językach?
>
Eh masz problem z czytaniem ze zrozumieniem :P? Bo wychodzi na to że tak
>> tak np wxwidget z tą różnicą... że to nie działa na urządzeniach
>> mobilnych
>
> wx potrafi dzialać nawet na urządzeniach bez GUI. Wystarczy framebuffer.
>
>> Już mowilem biblioteka GUI podałem ją po to byś zarybił zasade
>> działania... Teraz po podanym przykładzie z hibernate co do LCL zasada
>> działania jest jasna (Chyba?).
>
> No tak ale nic w tym wyjątkowego. Ot, dzień jak co dzień na połowy
> świata programistów.
>
Jak dla ciebie jednolity kod (jeden i ten sam) a robiący różne rzeczy to
nic takiego to owszem pisz sobie oddzielnie w C++, C#, Java

Tylko tyle że jak piszesz pod konkretne urządzenie to nagle okazuje się
że musisz użyć czego innego do web/czego innego do PC czego innego do
mobile.

Za pomocą LCL masz jedno ale to do ciebie się nie może jakoś przebić
>>> Na tle C++/Java to strata bo trzeba w to włożyć jeszcze miliony
>>> dolców żeby choć doczołgać się do czołówki.
>> Miliony dolców powiadasz... tylko czemu to w Lazarusie jest już dziś
>> osiągalne :) bez twojego miliona dolcow :P
>
> Bo to hobbyści. Robią za friko. Choć możliwe że są finansowani przez
> firmy którym się opłaca wpierać zamiast przepisywać kod na coś innego.

No właśnie i Ci hobbiści zrobili kawał dobrej roboty mam wrażenie że
znacznie więcej niż embarcadero.

>
> Tak czy inaczej zakładając że dobry programista to jakieś ~100k dolców
> rocznie i potrzeba ich kilku to nagle robią się miliony.

Fajnie liczysz... To z gwiazd czy z fusów :)?

>
>>> Obwiam się, choć może za głupi jestem, że jedno GUI to rule them all
>>> wypierniczy się na pierwszym lepszym zagadnieniu Webowym. Tam się
>>> najzwyczajniej inaczej pisze.
>> Po to jesteśmy programistami by to zrealizować. Jeszcze pare lat do
>> tyłu mało kto wiedział a aplikacjach mobilnych czy stronie www która
>> jest sama w sobie aplikacja :)
>
> Jeszcze pare lat do tyłu takich framewroków było kilka. W tym używałem
> jednego w javie którego już nie pomnę.
>
Pare lat temu to nawet nikt nie myślał że to pójdzie w tą strone :)

Google wypusciło GWT w 2006 po tym jak przekonali się że JS nabiera rozpędu
>> dzis to raczej powszechne
>
> Wtedy też.
>
>>> Rzecz w tym że to nie jest zysk bo już to mam za friko.
>> Masz za free wykorzystując kilka języków programowania.
>
> Java ma wszystko co chcesz.

Tak i do wszystkiego oddzielną bibliotekę :P

>
> C++ ma pawie wszystko lub wszystko.
>
> Python ma wszystko włacznie z Django.

Podobnie jak w przypadku Javy można ale potrzeba dodatkowych bibliotek
>
> Ponieważ GUI natywne i Webowe są rózne pod kątem dznia, user
> experience itd itp to szanse że będa oparte o jeden kod maleją prawie do
> zera. Niewiele to zmienia, normalny program nie pisze się w onklikach
> więc można podmieniać wartwę prezentacji w rozsądnych kosztach.
>
>> No chyba że zaczniesz twierdzić że w C++ można pisać na przeglądarke
>> wprost ale obaj wiemy że to nie jest możliwe :P
>
> Frameworki GUI webowe nie piszę się w przeglądarce tylko w ogólnie
> pojmowanym Ajaxie. Co jest serwerem chyba jest bez znaczenia.
w HTML CSS itp stąd podział na frontdeveloperow i backdeveloper :)
>
>> W Lazarus nikt nie wsadził miliona dolców :) (chociaż nie miałbym nic
>> przeciwko :)) a posiada po za WEB możliwość kompilacji na niemal
>> dowolną platforme
>
> Niemal. Tylko to samo jest w C++, Java, Python i biliardzie pozostałych
> języków.
>
Skąd ty wziałeś liczbę tego miliona dolców :) Chciałbyś tyle dostać czy
jak :P?
>>>> Ja preferuje jeden kod w dowolnym języku odpalany na wszystkim.
>>> Utopia, choć jesteśmy coraz bliżej.
>> Dlaczego utopia? Uważam wręcz przeciwnie że to jest bliżej niż dalej
>
> Uniwersalny język oznacza również uniwersalne ograniczenia. Choćby int.
> Ma być 8, 16, 32 czy może 35 bitów?
A to dopiero nowina a słyszałeś coś o warunkach kompilacji pod daną
platformę, sprzęt? W c++ Jest to możliwe a skoro go używasz to
powinieneś wiedzieć:)

W Lazarusie też jest to możliwe więc twoje ograniczenia nie mają tu
zastosowania
>
>> Niewątpliwie takie podejście generuje napewno pewną nadmiarowość kodu.
>> Jednak uważam że mamy teraz na tyle mocne sprzęty ogolnie w użytku że
>> w 99% przypadkach ta nadmiarowość nie ma znaczenia
>
> A-ha! Czyli jednak potrafisz wypełnić CPU maksymalną mocą obliczeniową
> na wyświetlanie obrazków z napisami? Pracujesz może w allegro.pl?
>
A zdarza ci sie zawalić obrazkami CPU? :) bo mi nie...
Swoją drogą zaczynasz cudować bo ci brak argumentow :)
>
>>> No ale te elementy ma też C++, Java i Python i nie trzeba dopracować.
>>> Są.
>> Są ale nie ma uniwersalnego podejścia do każdego z tych zadań potrzeba
>> oddzielnej biblioteki
>
> W Javie jest *WSZYSTKO*.

Jest i co z tego jak podeście zupełnie inne :)

>
>> a myśle że świat raczej idzie w kierunku upraszczania i takim
>> uproszczeniem jest LCL
>
> Java jest takim uproszczeniem. Uproszczony język, uproszczona wydajność,
> uproszczone możliwości, ale ma wszystko.

Powtarzasz to już po raz który że ma wszystko :P? Co jest zdaniem nie
dokońca prawdziwym bo w Javie znajdziemy biblioteki do prawie
wszystkiego to jest zdanie prawdziwe :)

Tylko co z tego jak potem mamy odnogie do mobila/desktopa itp

>
>> prosty przykład czy kod napisany w C++ bez zmiany liniki kodu
>> napiszesz na mobilne i komputer. Nie bo choćby właśnie gui sprawi że
>> musisz użyć odzielnych bibliotek
>
> Qt użyje. Działa tak samo na moim pececie jak i na sterowniku z ARM. Bez
> róznic w kodzie obsługującym GUI.
i nie będe miał natywnego wyglądu systemu itp ech i tak można przepychać
zero konstruktywnej wymiany zdań
>
>>> To daj inny przykład unikatowości Lazarusa vs reszta świata.
>> Podałem już tu kilka przykładów ten sam kod w 100% na rożnych platformach
>
> Czyli to samo co daje Java, C++, Python.
Nie to samo :)
>
>> Nawet się z tobą zgodze tylko już chyba teraz widzisz że to co
>> powstało w tym martwym pascalu daje pewną unifikacje kodu.
>
> Ale Pascal nic nie unifikuje. A jeśli miałby to nie ma żadnej cechy dla
> której to powinien być własnie Pascal a nie Java czy C++.
Powtarzasz się jasno napisałem i to dziś dlaczego to Pascal akurat a nie
inny język. Ponadto już wiemy skąd twoja więdza tutaj tłoczona wynika z
przypuszczenia :) otóż mylisz się i to bardzo nawet nie będe zliczał w
ilu kwestiach bo nie ma sensu. Masz swoje przekonanie i je miej tylko im
więcej czytam tego co piszesz to mam przekonanie że wynika ono z twojej
ignorancji bardziej niż z praktyki :)

Jave znam bardzo dobrze i tak jak mowilem ona jest bardzo fajna ale nie
jest to panaceum na wszystko.

Pozdrawiam

do góry

On 2019-10-05 09:52, heby wrote:
> 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
> Moja straszna zbronia życiowa polega na
> tym e urodziłem się za późno aby docenić karty perforowane.

Twoja zbrodnie zyciowa jest calkiem inna.
Po prostu jestes bezdennie glupi :(

>> Chetnie podyskutuje!
>
> A ja nie. Już o jednym trupie rozmawiamy.

Trupem to Ty jestes. Intelektualnym i mentalnym.

>> Pisalem w nim kawal zycia.
>> Doskonaly jezyk!
>
> Bez wątpienia. Podobnie jak Pascal. Też turing complete.

To czy jest czy nie jest Turing complete nie ma _zadnego znaczenia_.

>> 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ę.

Hm.. Nie chcesz poznac matki jezykow obiektowych ? Dziwne...

AK

do góry

On 2019-10-05 09:57, heby wrote:
> VHDL to Ada. Z domalowanymi duperelami.

Bzdurzysz po raz kolejny.

> I nie wybrali.

Nie pierwszy i nie ostatni raz "pieniadz gorszy wyparl lepszy".
I co? Cieszysz sie z tego, ze wybrano C-podobne kolejne g..wno?

AK

do góry

On 2019-10-05 10:03, heby wrote:
> 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.

Tu juz pojechales :)
Zwyczajnie pieprzysz.
PS: Moze bys wpierw przetestowal blech-a co?

AK

do góry

On 2019-10-05 10:06, heby wrote:
> Nie. To jest codzienność mojej pracy.

A w to to akurat wierze.
Nie nazywaj jednak tego pracą :)

AK

do góry

On 2019-10-05 10:08, 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.

Widzę właśnie. W głowie...

AK

do góry