On 2016-10-25 00:01, Maciej Sobczak wrote:
> Tak. Mam na myśli oczekiwania odbiorców. Im nie zależy na języku.

To nie jest prawda. Zależy im na jakości, redukjci bugów itp. Język C
tego nie zapewnia. Jezyk C++ załatwia część problemów. Java generuje
nowe (jak brak deterministycznego zachowania). Czekamy na Język
Ostateczny. Chwilowo brak.

> Ma się po prostu fajnie pisać i mają być gotowe biblioteki do pierdyliona
"shieldów".
> Zamienisz im C++ na Javę/łotewer i nawet im powieka nie mrugnie. To miałem na
myśli.

W sumie jest to o tyle istotne że C jest gorszy od czegokolwiek. Więc
być może zmiana na łotewer będzie i tak pozytywna.

>> Narzut na prosty procesor jest za duży.
> Mówimy o Arduino. O branży, gdzie antenka do wifi ma w sobie uC N
> razy silniejszy od głównego "procesora", który do tej antenki wysyła polecenia i
nikogo to nie dziwi.

W srodku takiej antenki ESP8266 siedzi *mały* ARM. Dalej Java się nie
zmieści (tak wiem że zmieści się na AVR ale to już nie jest Java).

> O branży, gdzie ludziom jest wszystko jedno, czy mają AVR czy Cortex-M4, bo diodą
mruga się tak samo fajnie.

Problem w tym że na żadnym z tych CPU w przypadku deterministycznego
zchowania programu, zagadnień RT itp. bedzie bardzo cieżko zmienić na
Jave. Nawet do migania diodą się taka java nie nadaje.

> O branży, gdzie niektóre płytki mają Linuksa (!) udającego
>, że jest AVRem i też mruga diodą - i też nikogo to nie dziwi.

R-Pi to nie jest do końca embedded. Istnieje jakaś mętna granica kiedy
SoC staje się zwykłym komputerem. Wydaje sie że R-Pi z Linuxem jest poza
ta granicą.

> Wsadź tam jakiś okrojony VM i nikomu nie zrobi to żadnej różnicy. Bo niby czemu?

Zrobi różnicę kiedy zapytasz jak szybko odpowie na przerwanie.

Nie uogólniaj embedded tylko do mocy obliczeniowej. Istnieją zagadnienia
któych nie da się rozwiązać większym cpu.

> A z biegiem lat ta nisza niezauważająca różnicy będzie coraz większa.
> Za parę lat będziesz miał w czajniku Linuksa z Javą udającą AVRa sterującego
wyłacznikiem i nikogo to nie będzie dziwiło.

Problem w tym że słyszałem to po raz pierwszy około roku 2000. Nie od
wróżbity tylko od człowieka który znał doskonale rynek, zawodowo parał
się projektowaniem i budową calkiem sporych systemow embedded. Jak każdą
wrózbę można było ją sobie wsadzić w d... Świat jest pełen ARMów z
obciętymi ficzerami typu M0 i jest na to od groma rynku a Javy nie
sposób odpalić. I NIC nie wskazuje na zmianę w kierunku większych
prędkości i mocy obliczeniowych. Embedded które to potrzebuje to jest
jakaś część, ale nie dominująca. Jazelle umarło zanim ktokolwiek go użył.

Za parę lat ... czyli nigdy. Zawsze będzie przestrzeń na jakieś małe cpu
które mają specjalne cechy nie spotykane w duzym świecie.

Jakieś 10 lat temu było pełno wróżbitów którzy mówili że "już za pare
lat" CPU połaczy się z FPGA. No i się połaczył jako Zynq który ma
absurdalne ceny, idiotyczne narzędzia i maluteńki rynek zbytu. Reszta
wybiera zwykłe ARMy, AVRy PICe i jakoś nic nie wskazuje żeby nagle
pokochali FPGA posklejane z ARMem za $x00 kiedy osobno kosztują $x.

Dochodzi do absurdów kiedy chińska firma reanimowała 6502, wsadziła w
otoczenie peryferiów i sprzedaje (MegaWin). Jest rynek.

Powstrzymałbym się z tymi wrózbami co będzie za pare lat. Nic nie
będzie, będzie po staremu.

> Że będą nisze, gdzie to się nie stanie?
> Oczywiście - ale tak jak na desktopach i serwerach, to będą coraz mniejsze
>, choć dobrze ustalone, nisze (i w tych niszach będzie też przeciwnik
w postaci VHDL).

Niszą na razie jest używanie Linuxa jako bazy w mikrokontrolerach. Za
kilka lat będzie miał takie same wady jak dzisiaj.

>> To jest nieprawda. Podstawową wartością jaką wprowadza C++ jest znaczące
>> ułatwienie testowania i weryfikacji bez narzutu runtime. Zarówno na
>> etapie unit testów, jak i przy głupiej kompilacji.
> 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. Implementacja testów w C jest
znacznie bardziej kłopotliwa niż w C++. Pewno że mozna powiedzieć że
"implementacja to szczegół". Zerknij jednak na UVM. Z tego "szczegółu"
zrobiono ogromna filozofię która *coś* znacząco poprawiła w jakości.

> A kompilacja nie jest czynnością weryfikacyjną, wręcz przeciwnie
> - to ją trzeba weryfikować i to właśnie w C++ ten etap jest trudniejszy.
> (mówimy o branży krytycznej)

Branża krytyczna określa tak wiele aspektów pracy włacznie z kolorem
skarpetek developera że nie ma sensu mówić o tym co w niej samodzielnie
wyewoluuje. Nic, do momentu aż komitety certyfikujące nie pozwolą. Nie
rozumiem jak tak hermetyczne i toksyczne środowisko ma niby być tłem dla
dyskucji o ewolucji embedded.

> Powyżej. Przykładowo, testy nie będą zależały od tego, w czym napiszesz kod.

Będzie zależała ich implementacja.

> Być może zaoszczędzisz trochę na pokryciu strukturalnym (bo kodu będzie trochę
mniej)
>, ale dokładnie tyle samo stracisz na wykazaniu ciągłości kompilacji
>, bo kodu wynikowego będzie odpowiednio więcej w stosunku do źródłowego.

Niby dlaczeog 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.
Statyczy polimorfizm to jedna z prostych metod osiągnięcia perfekcyjnej
długości kodu dla produkjci i testowania.

> Dlatego fakt, że C++ automatycznie zawoła jakiś tam destruktor nie oszczędza
> wysiłku związanego ze sprawdzeniem, czy akcja z tego destruktora się
faktycznie wykonała.

Tu musisz mieć zaufanie do kompilatora lub certyfikaty dupochronne. Nie
tak dawno temu pewna firma robiąca dla wojska miała w standardzie obok
MISRA rowniez własne zalecenia w których było żeby nie uzywać jakiejśtam
konstrukcji językowej bo kompilator popsuty, ale certyfikowany.

Rozumiem że nie ufasz że destruktor się woła, tylko wkładasz wysiłek w
sprawdzenie? A nie wkładasz go przypadkiem znacznie więcej kiedy musisz
sprawdzić czy programista wywołał tą akcję w każdym miejscu?

> Ten wysiłek jest ciągle taki sam.
> (mówimy o branży krytycznej)

Nie. Kiedy kompilator wykonuje swoje zadania w sposob pewny - wysiłek
jest mniejszy. Mozna nie mieć zaufania do kompilatora. Trudno, co robić,
można tez kopać rowy albo przeglądać wynikowy kod maszynowy co na jedno
wychodzi.