On 2016-10-25 11:32, Maciej Sobczak wrote:
> I właśnie dlatego (z powyższego linku):
> "Draw the connections between the modules on the editor, and watch your project
come to life."

Był kiedys taki kawałek kodu o nazwie LabView. Kiedys siedziałem, koło
2000 roku, na jakiejś konferencji i prelegentowi aż piana leciała z ust
kiedy wymieniał wszelakie zalety takiego rysowania algorytmiki. Nie to
żeby pracował w TI, najzwyczajniejszy habilitowany bez pojecia o czym
mówi jak to zazwyczaj bywa. "I juz za rok nie bedzie trzeba nic
programować". Ta...

Swoją drogą znam kolesia który w tym pisywał gdzieś koło 2007.
Przesiadywał po kilka godzin nad projektem żeby "jakoś narysować ta
pętlę". Ewentualne refaktorowanie kosztowało uszkodzenie prawego nadgarstka.

Bez watpienia mamy do czynienia z przyszłościową technologią. Nastepna
proszę!

> Proste? Właśnie w taki sposób zmniejsza się okno wejścia dla C++.

Po LabView widac że strasznie zmniejszyło od 15 lat. O jakiś pewno
promil projektów.

> Jak już pisałem, branża przestawi się na generację kodu wcześniej, niż rozstrzygnie
wojnę o wyższość C, C++ czy Ady.

No ale jakos od 15 lat się nie daje rady przestawić. Widać nie ta
rzeczywistość.

> Ja miałem na myśli raczej Intel Galileo - bo pracuje się z tym tak samo, jak z
Arduino. Bierzesz swój "sketch"
>, który przed chwilą działał na Arduino Uno, wybierasz w menu "Target board ->
Galileo", wciskasz guzik "Upload"
> i Twoja płytka mruga diodą. Tego Linuksa na tej płytce nie widać, on pełni bardziej
funkcję firmware'u
> i właśnie o tym pisałem - postęp w HW pozwala takie rzeczy robić a odbiorców to nie
dziwi.

I ten projekt w Arduino to w czym napisano?

>> Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.
> Ta nisza to może być pojedynczy procent całego rynku embedded.

IMHO wkładasz za dużo zwykłych komputerów do pojcia embedded.

> Może przegapiłeś

Tak, głupi jestem, to wiem.

>, ale obecnie istnieje coś z miliard (albo dwa) urządzeń wbudowanych z Javą.
Niektórzy nazywają je smartfonami.

Dziękuję. Ale żeby sarkazm stosować to trzeba jednak umieć.

> Masz w domu tony systemów embedded.

Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
dlaczego miałbym to nazywać embedded. Czy jak do mojego peceta dokleje
monitor i klawiaturę to tez bedzie embedded?

> Szybkość odpowiedzi na przerwanie jest istotna tylko w... no nie wiem w ilu z nich.

Bo to pecety a nie embedded o którym tu mowa.

> Ta nisza oczywiście będzie istnieć, ale to będzie nisza a nie dominacja.

Ta nisza będzie może niszą, ale obawiam się że sterowanie wektorowym
falownikiem dalej jest nie za bardzo w zasięgu Javy na Galaxy.

> Niedawno widziałem... lustro domowe z Androidem. Pokazuje prognozę pogody, akurat
wtedy, gdy się ubierasz. Fajne, nie?

Jak tam wstawie płytę na iTX z Atomem to będzie embedded czy blaszak?
Zawieszenie peceta na ścianie to już embedded?

> Ale przecież to Ty twierdziłeś, że coś się zmieni w temacie użycia C++. Zmieniłeś
zdanie? :-)

Twierdze że będzie ewolucja C do C++. Nic C/C++ nie zastapi na skale
masową. Nie ma jak. Chwilowo ewolucjia jest blokowana, ale na szczęscie
natura rozwiązuje ten problem powoli i metodycznie.

>>> Testy pisze się z wymagań i nie zależy to od tego, czy program jest w C czy w
C++.
>> Implementacja testów zalezy od tego.
> Testy pisze się z wymagań.

Dalej mówisz jak typowy managier. Się pisze testy. A w czym?
Doswiadczenia z Verilog/Vhdl pokazują że to jest *zasadnicze* pytanie.
Decyduje o tak szerokim spektrum przyszłych problemów że nie da się go
zbyć byle jaką odpowiedzią.

>> Implementacja testów w C jest
>> znacznie bardziej kłopotliwa niż w C++.
> Nie. Jeżeli wymaganie mówi, że lampka ma zgasnąć, to z punktu widzenia testu
>, który jest pisany z tego wymagania, nie ma znaczenia, czy lampka będzie zgaszona w
C
> przez jawne wywołanie jakiejś funkcji, czy w C++ przez destruktor jakiegoś
kończącego życie obiektu jakiegoś wrappera RAII.

Dalej nie rozumiesz. Jeśli lampka ma zgasnąc z C to sprawdzenie czy kod
w C woła właściwą funkcję jest znacznie trudniejsze niż w C++. Dla
managera to żadna różnica, dla implementatora testu to różnica
*zasadnicza* która rzutuje na jakośc testowania. W skrajnym wypadku
sadza się jednostę białkową która nacicka przycisk jak się zapali bo ...
bo język nie pozwala na inne wykrycie.

Tak, ta jednostka białkowa tez jest potrzebna, ale dopiero na końcowym
etapie.

> To jest ten sam test. I to właśnie tam jest wysiłek w sprawdzeniu tego, że lampka
zgaśnie.

Ale możesz ten wysilek zautomatyzować mniej lub bardziej. Możesz nawet
wziąć książkę do teori testowania i zastanowić się jak podzielić ścieżkę
testowania na piramidę gdzie na samym dole jest tak wiele testów że
wymagane jest dostrzeżenie *jak* je implementować.

Nie rób z siebie takiego teoretyka. Implementacja unit testowania jest
na tyle złożonym problemem że nie można jej pomijąc głupim "się jakos
napisze". Ludzie od Veriloga od przynajmniej 10 lat wyprówają sobie żyły
żeby to robić właśnie w tym szczególe lepiej bo kazalo się że tam
przynosi to wymierne korzyści. Na tyle że obecnie testowanie bazujące na
tych szczegółach trzęsie rynkiem i jest wymogiem stawianym w krytycznych
aplikacjach.

>> "implementacja to szczegół".
> Z punktu widzenia testu tak właśnie jest.

No więc teoretyzujesz lub posiadasz toskyczne środowisko testowania w
którym czas implementacji testu jest już na tyle długi że nie ma
znaczenia jak jest stworzony. Coś jest popsute.

>> Zerknij jednak na UVM.
> Nie miałem przyjemności. Z powierzchownej lektury wynika, że to jest metodologia

To jest *implementacja* pewnej metodologii.

>, którę mogę sobie zdownloadować z internetu. I chyba nie dotyczy dyskusji C vs. C++
(vs. Ada (vs. Java)).

Ależ dotyczy wszystkiego, a w szczególności dotyczy "się jakoś napisze
te testy". Masz przykład (obecnie tip top światowy) że ktoś się pochylil
nad tymi szczegółami i okazalo się że można znaczaco podnieść komfort i
jakośc weryfikacji. Szczegóły miały znaczenie, kwestia dostrzeżenia ich
z wysokich stołków managerów od słupków w PowerPoincie.

>> Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem
>> skarpetek developera
> Wręcz przeciwnie. Zdumiewająco mało określa. Nawet nie narzuca języka
programowania.

Narzuca bardzo wiele. Być może rozmawiamy o róznych dziedzinach. Gdybyś
poszedł w kierunku latania z fpga ilość rzeczy
organizacyjno-implementacyjnych które musisz spelnić aby w ogole
rozmawiać jest zastanawiająca i dotycza może nie koloru skarpetek ale
niewiele brakuje.

> Ale stawia cele do spełnienia, które łatwiej jest spełnić w C (!), niż w C++.

To nie może być prawda z racji że C jest w uproszczeniu podzbiorem C++.
To nie jest trywializm. To tylko oznacza że możesz z C++ wziąć to co w
danej chwili wyraża lepiej rozwiązanie problemu.

> Bo niektóre urządzenia embedded są krytyczne?
> W szczególności te, w których chciałbyś pytać o czas odpowiedzi na przerwanie?

Czyli te na Javie z VM popędzane z Linuxem? Czy własnie rozmawiam z
druga osobowością?

> [znowu o testach]
>> Niby dlaczego uważasz że kodu wynikowego będzie wiecej dla C++? Bedzie
>> go dokładnie tyle ile trzeba w testach i tyle ile trzeba w produkcji.
> Właśnie to mam na myśli. Kodu wynikowego będzie tyle ile trzeba
>, ale ponieważ kodu źródłowego będzie mniej (RAII, itd.),
> to w rezultacie będzie więcej kodu wynikowego *w stosunku* do źródłowego.

Podstawową zasadą przy redukcji bugow jest trzymanie się jak
najmniejszej ilości kodu źrodlowego i jak najczytelniejszego wyrażania
zamiarów. Ponieważ w ten sposób programista popełnia mniej błedów. Język
C musi być wspomagany przez makra, język C++ pozwala na wyrażanie wprost
w mniejszei ilości kodu.

> I właśnie ten większy stosunek utrudni weryfikację

Nieprawda. Weryfikację utrudnia cieżki do czytania kod, kłopotliwe
implementowanie testów i kiepski związek kodu (rysowanie z LabView) z
wynikiem (generowany C).

Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
templates mialo byc przeszkodą weryfikacyjną i traktowane jako miara
jakości. Po stronie kodu jest 10x mniej czytania i 10x czytelniej i 3x
mniej unit testów.

>. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej

Pomiędzy jednym a drugim masz kompilator. Możesz wygazać formalnie jego
działanie? FORMALNIE. Jesli nie to musisz za każdym razem sprawdzać kod
w C z kodem w asm. Ręcznie. No chyba że oszukujesz i te wszystkie nadęte
pojęcia o ciągłości są po prostu ponaginane że aż trzeszczy i podparte
zbutwiałymi certyfikatami?

> a im większy skok pomiędzy kolejnymi artefaktami w łańcuchu, tym trudniej tą
ciągłość wykazać.

Ale jak ją wykazujesz? Pomiędzy A i B użylismy kompilatora X? No no.
Robi wrażenie. Na managerach.

> Problem w tym, że w branży krytycznej te argumenty nie działają.

Z powodu biologi i komitetów certyfikujących a nie rozsądku.

> Bingo. Doszliśmy do najciekawszego.
> Otóż kompilator C jest znacznie prostszy konstrukcyjnie od C++.
> Dlatego istnieją kwalifikowane kompilatory C

Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
C z wielką dziurą. Zaznaczam przy okazji że w tym czasie kiedy oni w nim
pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów. I nie
oznacza to że należy wziąć gcc. Oznacza to że certyfikowany kompilator
okazał się polem minowym. "Jakoś(ć) przez certyfikację".

>, natomiast o takowym dla C++ nie słyszałem (przyjmijmy, że wybór jest mniejszy). I
teraz masz wybór:
> 1. piszesz w C i korzystasz z kwalifikowanego kompilatora C, który oszczędza kupę
wysiłku weryfikacyjnego

Nie oszczędzę. Bugi pochodzace z kompilatorów to promil promila problemu
bugow w ogólności.

> 2. piszesz w C++ i przy braku kwalifikowanego kompilatora C++
> robisz weryfikację kodu wynikowego, co kosztuje Cię kupę czasu (i pieniędzy).
> Którą opcję wybierasz?

Taką w ktorej jestem w stanie szybciej wykryć bugi w kodzie. C jest
drugi a C++ przedostatni.

> Szach-mat.

To nie jest szach mat. Piszesz o embedded tak jak Ci w danej chwili
pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
certyfikowane produkty wczesnej archeologii inzynieri programowania w
której ludzie rysują kreski od kodu w C do kodu w asm. Nie masz
certyfikowanej ciąglości wypowiedzi ...

>> Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w
>> sprawdzenie?
> Tak. Sorry, taka branża.

Ten promil embedded czy te miliardy smartfonów?

Udowadnianie że c++ nie ma co szukać w embedded z pomocą hermetycznego
promila aplikacji embedded obwarowanymi certyfikatami i komitetami
wydaje mi się, przyznaje, zabawny, dlatego to ciągne dalej. A przy
okazji jesli chodzi o Pascala ...