> Warto przyjrzeć się językowi Idris i typom zależnym.

Nie przekonują mnie. Jeśli je rozumiem, to typy zależne pozwalają związać warunki
między parametrami i wartością zwracaną z funkcji. Fajnie, ale to nie wyczerpuje
tematu, bo jest jeszcze stan (również globalny), który też mogę chcieć związać takimi
warunkami. Co więcej, takie warunki nie muszą mieć związku z typami - np. jedna
metoda w obiekcie może "obiecać" inne warunki końcowe, niż inna metoda, a przecież
nie jest tak, że typ obiektu jest różny w różnych metodach. Takie ograniczenie już na
poziomie terminologii wskazuje, że typy zależne to domena jakiejś niszy językowej (w
szczególności języków funkcjonalnych), więc od razu ma dla mnie ograniczoną
stosowalność.

Potrzebny jest inny formalizm. Pre- i post-conditions wydają się być bardziej
niekonfliktowym mechanizmem, tzn. możliwym do zastosowania bez niepotrzebnych
ograniczeń.

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

do góry

> C++ sprawia, że pierdołowate programiki, które w innych
> językach zajęłyby kilka linijek, urastają do rangi
> wielkiego osiągnięcia.

A co z niepierdołowatymi programami? Bo dane zebrane przy pisaniu pierdołowatych
programików nie muszą być reprezentatywne w szerszym kontekście. Natomiast lista,
która tu już została pokazana (http://www.lextrait.com/Vincent/implementations.htm
l) pokazuje, że kilka niebanalnych projektów w C++ powstało, a w zarządzaniu ryzykiem
takie przykłady mają znaczenie.

> Programując, staram się minimalizować dystans pomiędzy moimi
> myślami a programami. Język programowania jest dla mnie
> precyzyjną formą wyrazu myśli.

To jest bardzo ciekawe stwierdzenie. Bo jeśli dystans między Twoimi myślami a
programami będzie bardzo mały, to może się wtedy okazać, że dystans między tymi
programami a tym co faktycznie robi procesor będzie wtedy tak duży, że nie uda się
wykazać, że CPU robi to, co chciałeś.
Są co najmniej trzy punkty:

1. Twoje myśli.
2. Program (albo jakiś inny inżynierski artefakt).
3. To, co robi komputer.

Punkty 1. i 3. mają stałe położenie. Przesuwając 2. zmieniasz jeden dystans *kosztem*
drugiego. To nie jest teoria - właśnie dlatego im bardziej "wysokopoziomowy" jest
język (mała odległość między Twoimi myślami a programem), tym mniejsza szansa, że
ktoś w nim zrobi jakikolwiek system, który *musi* być poprawny. Dlatego paradoksem
naszej branży jest to, że najwięcej systemów krytycznych pisze się w... C.

Ciekawostka: dystanse między tymi punktami powyżej można zmniejszyć wstawiając więcej
punktów. Tylko 1. i 3. nie da się ruszyć.

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

do góry

On 2018-11-20 15:07, Maciej Sobczak wrote:

> Dlatego paradoksem naszej branży jest to, że najwięcej systemów
> krytycznych pisze się w... C.

Tak. To jest paradoks.
Dodam tylko, że jeszcze wiekszym paradoksem jest to, iż nie wynika to
_w najmniejszym stopniu_ z jakosci jezyka C jako języka programowania.
Wprost przeciwnie. Wynika to wlasnie z jego prymitywizmu (zarowno
jezyka, jak i jego biblioteki podstawowej/standardowej).
Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu
kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym
sprzecie (embedded itp).

PS: Podobnie drzewiej bylo z Fortranem (4,77)

AK

do góry

W dniu wtorek, 20 listopada 2018 10:46:04 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 19 listopada 2018 23:12:21 UTC+1 użytkownik
g...@g...com napisał:
> > Jak będziecie używać mojej funkcji memmove, to może nawet zadziała
> > o ćwierć promila szybciej na niektórych procesorach.
>
> takie teksty nie brzmia za madrze (pominawszy fakt ze tego typu spory/dyskusje
(tego okreslonego typu) wogole nie sa za madre) (z trzeciej stony wlaczanie sie w
takie logiczne podejscie
> (typu wypowiadanie zdan i rozrtrzasanie co jest rpawda a co nie) jest ok)
>
> ile to jest cwierc promila? 0.025 %,
> cos tu nie gra, wygladami na to ze
> ktos kto to pisze ma bardzo osobliwe podejscie do optymalizacji i robil to albo
jakos dziwnie albo zupelnie zle
> albo wogole
>
> ja optymalizowalem relatywnie sporo i
>
> 1)
> takie wartosci jak 0.025% nie wchodza
> tam wogole w gre bo te czasy wogole nie sa tak stabilne by moc to zauwazyc i
zmierzyc (aq czas czystego memcopy to juz wogole gdy ja to mierzylem niezle
oscylowal)
> 2)
> samego memcopy raczej sie nie optymalizuje bo przestrzen by tu poprawic jest mala
ale juz cale okolice bliskie
> memcopy - jak najbardziej
> 3) czynniki jakimi mozesz przyoptymalizowac juz calkiem dobrze ale zwyczajnie
napisany kod w c czy tam c++ moga byc naprawde spore, i wtedy nie wyrazasz tez tego
raczej w procentach tylko w 'x' ile razy, to ilemozesz osiagnac zalezy od natury
zagadnienia i od tego jak wstepnie przyoptymalizowany byl kod oraz od tego jak bardzo
daleko chesz isc w ta optymalizacje
>
> ale moje przykladowe casy jakie ja znam
>
> 1) kiepsko napisany kod 60 ms na ramke
> 2) pobawianie sie z flagami kompilacji
> (ale takie ktore polega na tym ze po roznych zmianach patrzysz na wplyw a nie tylko
na pale wlaczysz kilka) oraz wogole
> wyodrebnienie petli i przepisanie jaj tak by bylo jasne co tam sie dzieje (jelsi
ktos napisal bez wiekszej uwagi) 30 ms na ramke
>
> (dla mnie to pow punkt startoway bo jzu na starcie zwracam na to uwage)
>
> 3) poprzepisywanie, porozwijanie wyrazen, zredukowanie dzielen, poprzepisywanie na
inline (choc to malo pomaga raczej chodzi o to by miec wglad co tam sie dzieje),
ogolne poupraszczanie tak ze kod bardziej jest przyjazny podejsciu optymalizacyjnemu
- 16 ms
>
> 4) tabelaryzowanie kawalkow kodu, porozbijanie kodu na specjalne casy pod wzgledem
optymalizacji, dorobienie skomplikowanych algorytmow 'odrzucania roboty', zagladanie
do generowanego asma, ew wwalenie paru intrinsincow sse... przerobienie niektorych
czesci na kod ktory dzial w sposob lekko przyblizony (zlinearyzowany) (strata jakosc
wzgl szybkosci) - 1.6- 1.2 ms
>
> 5) zejscie na poziom asma i robienie jakiegos hardkoru w mikrokodzie razem ew
jeszcze z dorobieniem jeszcze wiekszych rewolucji w algorytmach odrzucania -
prawdopodobnie jeszcze mozna przyspieszyc 2 razy (i zejsc ponizej milisekundy ale to
juz hardkor i tego nie robie za duzo roboty i nei znam az takl asma
>
>
> slowem jak ktos mowi ze optymalizacja to walka o promile to raczej nie wie co mowi,
wg mopich doswiadczen optymalizacja to raczej 'srednio' czynnik 10x 15x jeslis ie
nawet zaczyna z calkiem poprawnego kodu w c
>
> nie widze przypadku w ktorych mowienie o promilach mialoby sens - bo to chyab
musialobybyc w wypadku potwznie przyoptymalizowanego kodu a taki kod ma juz wtedy
procentowo spoore fluktuacje wiec gadanie o promilach nie ma sensu

moze jeszcze 3 drobne uwagi co do tego powyzej:
1) calkiem mozliwe ze optymalizacje roznych programow sa zasadniczo rozne
i generuja rozne wnioski - i by moc duzo
o tym powiedziec tzrebby rozne przypadki optymalizowac (sam mam na mysli glownie
optymalizacje grafiki perpixel (glownie 3d) na cpu) choc nie tylko costam jeszcze
czasem tez sie troche optymalizowalo ale slabiej pamietam

2) ten pierwszy krok ktory wymienilem jest troche nienormalny i nie dotyczy tak
bardzo tego co ja pisze (bo dotyczy on glownie prostych bledow) ale podejrzewam moze
dotyczyc kodow wielu ludzi bo wydaje mi sie ze wiele ludzi nie mierzy na bierzaco
czasow wykonania - nie sa swiadomi zmian tych czasow, ich wartosci itd... mz to moze
powodowac toz e kod ma pewne bledy - np jesli nei mierza czasow moga byc nieswiadomi
jakie obciazenia pododuje systemowe api (ostatniuo pisalem swoj wlasny edytor tekstu
w winapi i okazuje sie np ze rysowanie fontow winapowskin TextOutem czasem dziala
szybko a czasem dziwnie wolno (np o ile pamietam rysowanie malych fontow po literce
dzia dziwnie wolno itp)-- niesprawdzanie tego to nawet nie blad optymalizacji tylko
raczej zwykly blad programu

[wogole z rysiowaniem tych fontow ogolnie mam pewien problem i nawet chetnie bym tu
napisal na czym to polega, ale raczej nikt tu i tak nie znalby na to odpowiedzi
- w skrocie mowiac nie wiem jak zrobic to by moc swobodnie przeplatac rysowanie
fontow z rysowaniem np spritow moimi procedurami per piksel ->

ogolnei by cos narysowac rysuje tow ramie po czym blituje do contekstu i dopiero
wtedy mge na tym kontekscie narysiowac fonty TextOutem z gdi

gdybym chcial to przeplatac to by cos narysowac na tym wszystkim musialbym sciagnac
to z kontekstu do ramu naryswoac do ramu i znowu blitnac - innymi slowy takie
swobodne przeplatanie powoduje mase blitow i sciagniec wiec jest spieprzone

do tego nie pamietam czy przypadkiem tych textoutow nie moge wywoalywac tylko z
handlera spod WM_PAINT (juz nie pamietam bo robilem to pol roku temu) a ja chcialbym
to rysowanie miec zupelnie wolnym, przeplatac i wywolywac dowolnie z kodu ramki (idle
loop)

naplsz("ala ma kota");
draw_line(10,10,300,400,0xffffff);
naplsz("zzzz");
draw_sprite(...)

a nie byc sztucznie ograniczanym, przez api (gdzie pisania napisow mozesz tylko
zrobic po calej grafice jakby w odzielnej czasowo "warstiw" i nie mozesz tego uzywac
normalnie - jak printfa) --- nie jestem pewien czy w wianpi sie da to zrobic (nie
wiem bo nei czytalem o tym wszystkego co sie da wyszukac w necie
bo wtedy te problemy mnie zmeczyly a czcialem kodowac sam edytor

nie dotyczy to strikte optymalizacji tylko raczj poprawnego kodowania w realacji do
wydajnosci ale jest mz ciekawym przykladem ]

przez toz e ludzi ne bierzaco nuie sprawdzaj tej wydajnosci moim zdaniem
kod mozne poprawic wydajnosciowo czesto nawet nie piszac optymalizacji, tylko raczej
bedac swiadomym co jak wydajnie dziala i mierzac czasy

pozaym warto poswprawdzac te flagi optymalizacji, co smieszne okazuje sie ze
zmiana gcc z jednaj wersji na inna (przy tych samych opcjach) moze spowodowac to ze
zmiania sie szybkosc wygenerowanego kodu (u mnie raz np kod zwolniel o jakies 10 czy
20% przy przejsciu kiedys z chyba gcc 4.9 na 5.2 czy cos takiego), przy bawieniu sie
opcjami tez np warto zwracac pewnie uwage czy kompilator nie generuje jakichs
niespodzianek bo kompilatory schodza na psy troche, wrzucaja jakis niepotrzbny syf


3) te techniki 'algorytmicznej ' optymalizacji (czyli a)odrzucanie/odfiltorowywanie
roboty do wyonania
b) 'linearyzacja' / czyli cos w stylu liczeni stratenego na jakosci ale szybszego
(jak np nie liczenie calych pierwiastkow a tylko przyblizonych, albo licznie ich
tylko na rogach kafelkow a pozniej interpolowanie liniowe)

wymianione sa charakterystyczne dla kodwowania grafiki ale raczej dadza sie jakos
uogolnic w pewnym sesnie na ogolene
metody algorycznej optymalizacji - i sam w to szedlem z ciekawosci ale moze to sie
przerodzic troche w robote rodem z jakiegos NASA czy cos (mowiac metaforycznie ) bo
okazuje sie ze kod ktory w oryginale ma Xliniejek po dowaleniu tej algorytmiki ma 10
razy
tyle - jest doalebnie mniej nieczytelny i diablenie zamkniety na poprawki - ale
dziala szybciej, po przepisywaniu na profesjonalnego asma pewnie jeszcze szybciej i
jeszcze bardziej nieczytelny i jeszcze bardziej zamkniety na zmiany

dlatego by nie klepac po proznicy w usenecie (bo ludzi nei eznaja sie na
optymalizacji ale klepia bzdury jak kompletne downy (np ze kompilator sam
zoptymalizuje - kompilator nie zoptymalizuje to jest totalna bzdura bo kompilator
tylko potrafi skompilowac co programista zapiesze by to optymalizowac tzreba to
przepisywac) mozna powiedzic tye;

1) optymalizacja moze duzo dawac ale maszkilak jej poziomow i typow - wbrew pozorom
mikrooptymalizacje na poziomie c sa mz jedna z najtanszych i najlepszych rzeczy jaka
mozna robic... warto tez rozumiec api jakiegios ie uzywa i system
(nie jest to optymalizacja el chodzi o poprawne rozumienie kodu)... te optymalizacje
algorytmiczne o ktorych tez downy z netu nawijaja tez mozna rozumeic dwojako, jako
wybor algorytmu do zrobienie czegos (co zwykle raczej nie jest trudne i kazdy kumaty
programista nie ma chyab z tym wiekszego problemu, bo czemu ma wybrac cos wolnego
zamiast czegos normalnego) ale tez do pisanie tych algorytmow ktore rozbudowaywuja
algorytm po to by dziala szybko np przez to odrzucani i linearyzowanie - ale to jest
troche ryzykowan apsrawa bo z prostego kodu dostejesz dlgi i bardzo techniczny...
schodzenie do poziomu recznego asma... jak ktos umie to cyba mozna ale to kolejna
doza roboty

i poza wszystkim tzreba pamietac ze
by cos zoptymalizowac najpierw trzeba to napisac w zwyklej wersji a z tym jest duzo
wiekszy problem... co z kolei jest pociecha dla tych ktorzy uzywaja wolnieszych
jezykow - faktycznie to ze cos jest wolniejsze wcale tego nie dyskwalifikuje, bo
chodzi o to byc cos
na poczatek wogole zrobic

by cos wogole zrobic z kolei trzeba miec odpowiednia pare by to moc zrobic i to jest
jeszcze inny problem itd itd

do góry

W dniu wtorek, 20 listopada 2018 21:52:07 UTC+1 użytkownik fir napisał:
> by cos wogole zrobic z kolei trzeba miec odpowiednia pare by to moc zrobic i to
jest jeszcze inny problem itd itd

dla mnie problemem ostatnich czasow jest wlasni ebardziej jakby psychologia -umiem
kodowac rozne rzeczy (w granicach rozsadku bo niektore rzeczy umiem zakodowac np
kompilator c, czy edytor tekstu ale niktorych nadal nie (bo albo sie natkne na
zomecznie (prosta robota ale jest jej za duzo) albo na jakas "sciane" (yeoretcznie
jest to malo kodu al enie moge tego jakos ogarnac by zazarlo) - i moja glowan
bolaczka w tym temacie bylo by jak wymyslic by wogole zmusic siebie do kodowania...
im bardziej je umiem tym mniej mi sie chce je robic
(byc moze dlatego ze im bardziej zaawansowane kodowani tym bardziej pierze mozg lub
przynajmniej meczy)

choc sa pocieszajace elementu ostatnio wlasnie pouczylem sie ze 3 wieczory pehapa i
wydawalo mi sie to proste jak jezyk dla dzieci (mw dlapieciolatkow),
co jest optymistyczne - ale i tak mi sie po tych 3 wieczorach tymczasowo znudzilo

jak sie zmusic do porzadnego kodowani to juz wogle nie wiem (na szczesci eniby jak
sie w sobie zbiore to wykrzesam z siebie zapal i costam da sie przykodowac np
ostatnio ten edytor przykodowalem w jakies 10 dni (niedokonczony ale da sie pisac a
byl pisany z reki wszytko trzebylo obkodowac nawel lamanie lini tekstu sklejania ich
itd)

ale ogolneie to walsnie ta walka z ta psychologia (zmusisc sie do kodowania)
to najwiekszy chyab problem, innym problemem sa te wspomnaiane 'sciany'
koncepcyjne

do góry

W dniu wtorek, 20 listopada 2018 05:37:31 UTC+1 użytkownik s...@g...com napisał:
> > > A to co nie produkcyjne może być w Bash lub Pythonie.
> >
> > A dlaczego nie w C++?
>
> Żeby było szybciej?!?

A dlaczego w C++ jest wolniej?

> > > A jak chcemy zrobić bazkę to dodatkowo Sql.
> >
> > A dlaczego nie C++?
>
> Bo taki mamy standard dla relacyjnych baz danych?!?

Czyli C++ nie jest "zupełnie wystarczający do wszystkiego"?

Nota bene, Rich Hickey zwrócił kiedyś uwagę, że problemem
SQLa jest to, że jego twórcy nie pomyśleli o interfejsie
dla maszyn. Interfejs dla człowieka łatwo jest dorobić
do interfejsu dla maszyny, ale dorobienie interfejsu dla
maszyny do interfejsu dla człowieka zawsze powoduje bezsensowne
problemy (tak jak SQL injection)

> > I czy oprócz C++, basha, pythona, htmla, javascriptu i sql znasz
> > jeszcze jakieś języki?
>
> Asembler, Php, RegExp - to chyba już wszystko. Trochę liznąłem Java, ale to czysty
koszmar...

To niewiele.
PHP, Python i JavaScript to właściwie "różne skórki" na ten sam język.
Z języków, które faktycznie mogą dać nowe perspektywy na programowanie,
jest Smalltalk (Pharo albo Squeak), Lisp, Prolog, Erlang i Haskell.

(no i oczywiście angielski)

> > > Po drugie, primo:
> > > 2. W języku programowania jest najważniejsze by był kompilowany do kodu
maszynowego (niżej nie zejdziemy - chyba że jeżyki opisu sprzętu Vhdl/Verilog są nam
niestraszne).
> >
> > Dlaczego to jest najważniejsze?
>
> Żeby program działał bez sztucznych narzutów (typu maszyny wirtualne i
interpretery).

Ale dlaczego to jest najważniejsze?

> > > Lepiej już zaprojektować jakiś program (poćwiczyć projektowanie) z jakimiś
ciekawymi algorytmami (poćwiczyć projektowanie algorytmów i ew. złożoność
obliczeniową), a potem zastanowić się co w naszym dotychczasowym stylu kodowania było
nie tak i to zakodować to wg najnowszych pomysłów i spostrzeżeń (poćwiczyć
kodowanie).
> >
> > No, jak się uczy podstaw, to warto ćwiczyć podstawy.
>
> To nie tylko podstawy, to również szlifowanie i rozwój z każdym nowym projektem.
>
> > > To jest racjonalne a nie strata czasu na kolejny (zbędny) język programowania.
> >
> > Skąd wiesz, że to "kolejny (zbędny) język programowania"?
> > Na jakiej podstawie formułujesz taki sąd?
>
> Jw.

Tzn. co "jw."?

> > C++ to najgorszy język, z jakim miałem styczność.
> > Już dawno oddałem go na złom.
>
> Najwyraźniej jesteś oportunistą! Widziałeś tą listę:
> http://www.lextrait.com/Vincent/implementations.html
> ?!?
> Na pierwszym miejscu C++ i na drugim Java - reszta języków na marginesie...

To bez znaczenia.
C był "pionierskim językiem" projektu UNIX, i stąd się wzięła
jego popularność. Poza tym ani C, ani C++ nie wprowadziły
niczego rewolucyjnego.
Większość rzeczy związanych z GUI (edytory tekstu, programy
graficzne itd.) powstały wokół Smalltalka.
Zaawansowane projekty matematyczne (np. całkowanie symboliczne)
powstały wokół Lispa.
"Property-based testing" powstał w Haskellu.
To nie jest przypadek.
Jakkolwiek znoszę język C, muszę stwierdzić, że projekty C i C++
ciągną się w ogonie rewolucji, a nie na jej czele. To języki,
w których można robić rzeczy znane, ale do nieznanych nie nadają
się zupełnie.

Przykładowo, firma Rigetti stosuje Common Lisp do programowania
komputerów kwantowych, a Christian Schafmeister stworzył implementację
Common Lispa opartą na LLVM żeby ułatwić sobie prace w biologii
molekularnej.

> > C++ sprawia, że pierdołowate programiki, które w innych
> > językach zajęłyby kilka linijek, urastają do rangi
> > wielkiego osiągnięcia.
>
> Ta... Bo co?!? Bo ktoś Ci zabronił używania Qt?!? A może się nie chciało?!?

Rozumiem, że masz bibliotekę, którą lubisz. W porządku,
nie ma nic złego w lubieniu biblioteki. Zabawne jest jednak
to, że zarzucasz mi lenistwo (a może ignorancję) pomimo że
ja znam narzędzia, o których Ty piszesz, ale Ty najwidoczniej
nie znasz tych, o których ja piszę.

do góry

Maciej Sobczak <s...@g...com> wrote:

>> > To następna obserwacja: jeśl wpływa to na runtime release należy to
>> > odrzucić. Wszelakie checkery asercyjne, za wyjątkiem programowania
>> > defensywanego, nie mogą istnieć w kodzie produkcyjnym.
>>
>> Nigdy nie rozumiałem sensu tego rozumowania
>
> Sens jest również taki, że (jak na ironię!) w systemach krytycznych nie
> da się spełnić kryterium 100% pokrycia kodu testami czegoś, co ma
> asserta. Tzn. jeśli w kodzie jest assert, który *z założenia* ma się
> nigdy nie wykonać, to jest to tzw. dead code i ma go nie być. Bo jeśli
> jest, to nie da się go przetestować. Albo inaczej: nie da się wykazać
> testami, że coś się nigdy nie wykona, więc nie da się zdobyć w ten
> sposób pewności, że się nie wykona. A jeśli osiągniemy tą pewność innymi
> metodami (np. formalnymi), to asserta dynamicznego może wtedy w ogóle
> nie być.

To prawda. Ja (na szczęście -- bo odpowiedzialność jest ogromna) nigdy nie
pisałem systemów krytycznych, ani nigdy u SQA nie robiło u nas tego typu
testów (choć oczywiście to, co mówisz, ma sens).

> Zupełnie niezależnie od tego, w pewnych środowiskach walnięcie assertem
> jest bez sensu, bo i tak nie ma do kogo przekazać sterowania. Assert w
> rozruszniku serca jest bez sensu, nie tylko technicznie, ale też
> filozoficznie.

To znów bardzo specyficzne zastosowanie i podejrzewam, że programowanie
rozrusznika serca rządzi się swoimi regułami (raz, że jest to typowy układ
embedded bez możliwości wyrzucenia błędu -- bo jak, w pulsie pacjenta
zakodować linię kodu? -- a dwa, że jest to system krytyczny, w którym
nieprawidłowa praca programu może powodować chorobę lub śmierć).
Podejrzewam że pisząc oprogramowanie na rozruszniki serca stosuje się
jakąś formę MISRA lub odpowiednik i że są tam jakieś sprzętowe failsafe'y,
które uniemożliwiają przejście programowi w stan, który będzie zagrażał
życiu lub zdrowiu. Tak to sobie przynajmniej wyobrażam.

Z drugiej strony spotkałem się z systemem ładowania baterii (Li-Po), w
którym zamiast dedykowanego kontrolera wyłączanie ładowarki było robione
software'owo. Wszystko działało... do momentu, aż w systemie pojawił się
błąd i zasilanie baterii nie było wyłączane po zakończeniu (nie wiem też
co by było, gdyby urządzenie się zawiesiło).

> To nie jest tylko kwestia szybkości działania, to może być też kwestia
> sensowności istnienia samego asserta.

Tak... czasem nie ma możliwości zaraportowania błędu i jest pytanie typu
"ok, pojawił się błąd, ale co teraz?". Tylko właśnie -- co wtedy? Jeśli
mogę sobie na to pozwolić i na danej platformie ma to sens, to staram się
to w jakiś sposób zaraportować. Jeśli sensu ani możliwości nie ma, to
pozostaje przestawienie wyjść w niegroźny stan i kontrolowany restart...
i jeśli błąd nadal występuje, to tak w nieskończoność.

Tak czy inaczej, jeśli system umożliwia jakieś zaraportowanie błędu lub ma
możliwość interakcji z użytkownikiem, to używam tego. Zdarzało się, że
tego typu asserty wyskakiwały na produkcji (choć teoretycznie kod był
przetestowany przez SQA i teoretycznie nie powinny wyskoczyć). Dużo
bardziej wolę dostać raport o błędzie wraz z tym, co wypluł program i co
pozwala mi zdiagnozować błąd, niż pozwolić programowi działać dalej w
stanie, w którym nie powinien się znaleźć. Nawet jeśli nie ma możliwości
zaraportowania, to dużo bardziej wolę, jak program się zatrzymuje, a błąd
jest jawny, niż jak błąd jest ukrywany i po jakimś czasie coś działa, ale
nie tak jak powinno.

Oczywiście nie pisząc oprogramowania na rozruszniki itd. systemy mogę
sobie na to pozwolić -- awaria programu nie ma w tym przypadku skutków
zdrowotnych (choć może mieć finansowe wynikające z braku możliwości
używania programu).

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

W dniu wtorek, 20 listopada 2018 10:58:08 UTC+1 użytkownik fir napisał:

> fakt ze tego typu gnidy stanowia dolny odsetek 10% usenetu jest faktem i probowani
uczenia ich normalnosci (czego probuje godek) ma takie szanse powoedzenie jak
wpuszczanie czerwonopyskiego plujacego na podloge dresa (lub dresow) na wyklad z
filozofii

Jakiś czas temu głośno było o rosyjskich trollach, którzy
poruszali na forach temat szczepionek, po to tylko, żeby skłócać
ze sobą ludzi.
Czasem sobie myślę, że osoby, które tutaj wyjeżdżają z obraźliwymi
tekstami, robią to celowo, żeby sprowadzić dyskusje do poziomu
rynsztoku - żeby owocne dyskusje nie dochodziły do skutku.

Nie jest to co prawda zbyt prawdopodobne, ale daje odmienną perspektywę,
i uświadamia, że najlepsze, co możemy robić, to ignorować zaczepki
takich osób.

Z drugiej strony, oczernianie (w rodzaju snucia insynuacji
o "spędzaniu czasu z nieletnimi dziewczynkami"), choć niewątpliwie
świadczy o debilizmie oczerniającego, może mieć poważne konsekwencje
dla osoby oczernianej (przychodzą na myśl samosądy, które miały
miejsce w Indiach albo Ameryce Południowej na skutek propagacji
fake newsów), i może nawet byłoby wskazane zgłaszanie takich
incydentów do sądu.

do góry

> > Dlatego paradoksem naszej branży jest to, że najwięcej systemów
> > krytycznych pisze się w... C.
>
> Tak. To jest paradoks.
> Dodam tylko, że jeszcze wiekszym paradoksem jest to, iż nie wynika to
> _w najmniejszym stopniu_ z jakosci jezyka C jako języka programowania.
> Wprost przeciwnie.

Tak.

> Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu
> kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym
> sprzecie (embedded itp).

Nie.

Tzn. łatwość w tworzeniu kompilatora była argumentem, który miał znaczenie dawno
temu, jak nie było kompilatorów i trzeba było je tworzyć. Wtedy fakt, że napisanie
kompilatora C było proste, ułatwił ekspansję C na każdą nową platformę.
Teraz ten argument nie ma znaczenia, bo kompilatory już są i nie trzeba ich pisać.
Nowe platformy sprzętowe nie powstają, wszystko się z grubsza zunifikowało a np. nowe
mikrokontrolery powstają w ramach istniejących już rodzin. A nawet jak się jakiś
producent wychyli z czymś istotnie nowym, to wystarczy dopisać backend do gcc, czyli
skorzystać z istniejącego już front-endu. Dlatego walory języka C w tym zakresie
przestały mieć znaczenie.

Dodatkowo, nie jest istotne, żeby kompilator "poszedł" na prymitywnym sprzęcie, bo
nikt poważny nie kompiluje na targecie. Kompiluje się na dowolnym biurkowym hoście a
na target wrzuca gotowy obraz - to pozwala użyć dowolnie skomplikowanego toolsetu
nawet w odniesieniu do mikrokontrolera z 512 bajtów RAMu. Właśnie dlatego typowe
dzisiejsze środowisko do programowania takich mikrokontrolerów jest oparte na
Eclipsie i zajmuje ileś GB na dysku i wymaga procesora i7, żeby się dało z niego
korzystać.

Prymitywizm języka C jest natomiast przydatny (również dzisiaj) do tego, że w takim
języku związek między kodem źródłowym a obiektowym (tzn. tym skompilowanym) jest
niemal 1:1 i każdy średnio rozgarnięty inżynier jest w stanie wskazać linię ciągłą, w
obie strony, pomiędzy tym co napisał a tym co uruchomił. To jest absolutnie kluczowe
w projektach krytycznych - tzn. jeśli tej jednoznaczności nie ma, to projekt nie ma
szans na sukces, przynajmniej nie przy dzisiejszych standardach procesowych.
Innym językiem, który pozwala na takie jednoznaczne przełożenie, jest Ada (tzn. jakiś
rygorystycznie dobrany podzbiór). Z C++ też się da, przy starannie wybranym
podzbiorze języka. Z tych trzech wygrywają... przyzwyczajenia.

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

do góry

g...@g...com wrote:

> Czasem sobie myślę, że osoby, które tutaj wyjeżdżają z obraźliwymi
> tekstami, robią to celowo, żeby sprowadzić dyskusje do poziomu
> rynsztoku - żeby owocne dyskusje nie dochodziły do skutku.

Tak, też myślę, że fir robi to celowo.

Jeśli nie widzisz, w jaki sposób ten osobnik obraża innych ludzi, jaka
agresja wylewa się z jego postów wobec wszystkich, którzy się z nim nie
zgadzają, czy wreszcie -- jaki poziom intelektualny ten osobnik sobą
reprezentuje (przecież on nawet pisać nie potrafi bez sadzenia wszędzie
miliona literówek -- a skoro programuje, to potrafić musi, więc widocznie
tutaj ma tych, którzy czytają jego posty, głęboko gdzieś) -- to widocznie
nie chcesz tego zobaczyć.

> Z drugiej strony, oczernianie (w rodzaju snucia insynuacji
> o "spędzaniu czasu z nieletnimi dziewczynkami"),

Naprawdę myślisz że wyssałbym tego typu rzeczy z palca? Polecam zajrzeć do
pokoju grungerap na Onecie.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry