On Tuesday, October 25, 2016 at 12:27:51 PM UTC+2, Sebastian Biały 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.

Sam napisałeś, że obecni amatorzy od Arduino to przyszli inżynierowie w firmach
embedded. Pokazuję Ci, co ci amatorzy teraz robią. Zgadnij, co będą robić za parę
lat. Pisać szablony w C++?

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

Po ESLOV widać, że tak rośnie nowe pokolenie inżynierów.

> No ale jakos od 15 lat się nie daje rady przestawić.

Kolega obok twierdził, że "większość" softu w samochodach się robi w Simulinku.
Trochę przesadził z tą większością, ale i tak to są rysy na Twoich argumentach. To
się dzieje, niezależnie od tego, czy Ci się to podoba.

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

Niedawno powstało takie pojęcie jak "deeply embedded", bo niektórzy nie mogą się
pogodzić z postępem w hardwarze.
Podsumujmy: piekarnik/pralka/zmywarka sterowana mikrokontrolerem 8051 to jest system
embedded. Jeśli w następnej wersji piekarnika/pralki/zmywarki tego samego producenta
będzie mały komputerek z Linuksem, to to już nie jest embedded. Dlaczego? Bo
specjaliści od embedded mają naruszone ego? No to sorry.

> Nie. Mam tony pecetów z przyczepionym LCD i baterią. Nijak nie widzę
> dlaczego miałbym to nazywać embedded.

https://en.wikipedia.org/wiki/Embedded_system

> Czy jak do mojego peceta dokleje
> monitor i klawiaturę to tez bedzie embedded?

To zależy, czy będzie częścią większego produktu. Jeśli ten monitor i klawiatura są
akurat na frontowym panelu w samochodzie, to tak, ten pecet jest systemem embedded.
Sorry. Nie ja wymyśliłem definicję.

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

Cieszę się, że znalazłeś sobie ciekawą i niezagrożoną niszę zawodową.

> > Testy pisze się z wymagań.
>
> Dalej mówisz jak typowy managier.

Nie, jestem inżynierem.

> Się pisze testy. A w czym?

Skup się: w Excelu.

(oczywiście nie jest to jedyna opcja, ale o tyle ciekawa, że kompletnie oderwana od
dyskusji nt. wyższości C++ nad C)

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

Dalej nie rozumiesz. Jeśli lampka ma zgasnąć, to w jakiejś chwili na jakimś outpucie
ma być LOW (powiedzmy). Albo jakaś zmienna lub wartość w jakieś tablicy albo
strukturze ma być LOW. Itp. Zrobienie testu na takie coś nie zależy od tego, czy
ustawianie tej wartości jest w C czy w C++.

W szczególności, uwaga, test można zrobić *zanim* powstanie ten kod i tym bardziej
wtedy widać, że robienie testu nie zależy od tego, czy gaszenie lampki jest w C, czy
w C++.

(Proszę nie mylić z TDD (Test-Driven Development), bo to nie to.)

[branża krytyczna]
> Narzuca bardzo wiele.

Na przykład?

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

Błąd logiczny. Właśnie dlatego jest łatwiej w C, że C jest (w uproszczeniu)
podzbiorem C++.
Dzięki temu ilość różnych rzeczy do sprawdzenia w kodzie jest mniejsza (sic!).

> > 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ą?

Uzupełniam:
Jeżeli w danym systemie embedded nie interesujesz się czasem odpowiedzi na
przerwanie, to prawdopodobnie jest to system rozrywkowy, np. lustro z Andoridem z
prognozą pogody. Natomiast jeżeli jesteś zainteresowany tym czasem, to prawdopodobnie
jest to system krytyczny a wtedy chcesz mieć jak najłatwiejsze narzędzia weryfikacji.

> > I właśnie ten większy stosunek utrudni weryfikację
>
> Nieprawda. Weryfikację utrudnia cieżki do czytania kod,

Więc pisz kod łatwy do czytania. Standardy kodowania po to są.

> kłopotliwe
> implementowanie testów

Testy pisze się z wymagań. N-ty raz to powtarzam.

> i kiepski związek kodu (rysowanie z LabView) z
> wynikiem (generowany C).

Bingo. Dlatego C++ jest trudniejszy w weryfikacji, niż C, bo w C++ jest większy
przeskok między kodem (źródłowym) a wynikiem (obiektowym).

> Pierwsze słyszę żeby 20MB kodu wynikowego więcej z powodu życia
> templates mialo byc przeszkodą weryfikacyjną

To jest tzw. total showstopper a nie przeszkoda.

> Po stronie kodu jest 10x mniej

Zaraz, zaraz. Powyżej napisałeś, że kodu jest 20MB więcej, teraz piszesz, że kodu
jest 10x mniej. Gubisz się?

Jeżeli w Twoim projekcie zrobiło się 10x mniej kodu źródłowego a jednocześnie
przybyło 20MB kodu wynikowego, to leżysz na weryfikacji.
Hasło: traceability.

> >. Bo w branży krytycznej musisz wykazać ciągłość metody inżynierskiej
>
> Pomiędzy jednym a drugim masz kompilator.

To jest nieciągłość.

> Możesz wygazać formalnie jego
> działanie?

Jeżeli to jest kompilator C++, to nie da się tego zrobić jeszcze bardziej, niż nie da
się gdy to jest kompilator w C.

Właśnie dlatego lepiej, żeby był C.

> Jesli nie to musisz za każdym razem sprawdzać kod
> w C z kodem w asm. Ręcznie.

Tak. Sorry, taka branża.

Dlatego łatwiej się to robi gdy kod źródłowy jest w C.
Naprawdę.

> Już Ci napisałem jak duży producent pisal w certyfikowanym kompilatorze
> C z wielką dziurą.

Nie ma problemu - certyfikował tą resztę wokół dziury.

> Zaznaczam przy okazji że w tym czasie kiedy oni w nim
> pisali gcc osiągał lepsza jakość kodu wynikowego i nie miał bugów.

Bzdura. Bugzilla pokazuje, że w historii gcc nigdy nie było takiego przedziału czasu,
żeby nie było bugów. Różnica jest taka, że w przypadku tego certyfikowanego wiedza o
tym gdzie są bugi (i jak trzeba pisać, żeby je ominąć) była większa.
Dlatego ten certyfikowany był bardziej odpowiedni w projekcie krytycznym.

> Bugi pochodzace z kompilatorów to promil promila problemu
> bugow w ogólności.

W branży rozrywkowej? Oczywiście.

Ale pisaliśmy o krytycznej.

> Piszesz o embedded tak jak Ci w danej chwili
> pasuje. Raz to wypasione systemy z Linuxem i Java a po chwili
> certyfikowane produkty

Ty sam ten temat szeroko traktujesz. Raz o Arduino, drugi raz o falownikach...
Próbuję odpisywać wg bieżącego, zmiennego kontekstu.

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

Ale ja nie pisałem tylko o promilu certyfikowanych. Również o tej gigantycznej masie
rozrywkowych, z Javą w środku.
Pytanie teraz, czy pomiędzy tymi dwoma kategoriami jest wystarczająco dużo miejsca.
Pewnie jest, ale nie na tyle, żeby można było pisać o niezastąpionym C++, którego nic
nie wyprze. Właśnie wypiera (albo nie dopuszcza), z obu tych stron.

W branży embedded C++ jest w podobnym ścisku i pod podobną presją konkurencji, jak na
desktopie, z podobnych powodów.

> A przy
> okazji jesli chodzi o Pascala ...

Nie widziałem w embedded.

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