Beágyazott C vagy Java?

Tudomásom szerint a Java nagyrészt a C-re épül. (ha nem, akkor tévedtem)

Ezért én a C-t választanám; arról szükség esetén könnyebb a Java-ra váltanib mint fordítva.

A C-nek sajnos még sokáig lesz jövője. A sajnost azért mondom, mert egy borzasztóan elavult és nehézkes nyelv ami nem megfelelő a mai szoftveres elvárásoknak (természetesen beágyazott világban, máshol már kihalt). A java döglődik és a szakma azon része, ami használja a webes világ felé mozdul el.

Szakmai szempontból mind a két irányban vannak kihívások és mind a kettő eltolódhat az unalmas rutinba. Véleményem szerint az alapján dönts, hogy melyik megy könnyebben, mert oda szakmailag is jobban mutat, ha más világokból tudsz felmutatni valamit. Például ha felhasználói software fejlesztésben dolgozol és bejön valami bit izélgetés és nem csak nézel mint Rozi a moziban mindenképpen előny. Vagy mikrocontrollerek világában egy összetett probléma esetén több különálló absztrakciós layer megírása is black magic-nek tűnik a mérnökök szemében.

És végül: nem a nyelv számít. A szemlélet a fontos bármelyik irányba is mozdulsz.

Egyértelműen embedded C.

Java fejlesztőt bármelyik polcról levesznek, beágyazott rendszer fejlesztők viszont elég kevesen vannak és ráadásul még jól is keresnek.

" beágyazott rendszer fejlesztők ... és ráadásul még jól is keresnek"

Ezzel csak az a baj, hogy a HR osztály így gondolja, mi meg nem...

A C-nek megvan a maga helye, és szerintem még sokáig fog élni. Persze tudni kell, hogy hol érdemes használni, és hol nem. Ahol nem érdemes, ott persze hogy nem felel meg az elvárásoknak. :)

És nem csak beágyazott rendszerekben használják, hanem gépközeli feladatoknál (pl. driverek), vagy olyan függvénykönyvtáraknál, amiket pont a magas szintű nyelvekben szeretnének majd használni, de ott már teljesen kioptimalizált, villámgyors kódként kell futnia a háttérben. Ezeket is gyakran írják C-ben.

"A C-nek megvan a maga helye, és szerintem még sokáig fog élni."

Rengeteg jobb és értelmesebb megoldás van, hogy helye van és sokáig élni fog az csak a vaskalapos villamosmérnököknek köszönhető.

"Persze tudni kell, hogy hol érdemes használni, és hol nem. Ahol nem érdemes, ott persze hogy nem felel meg az elvárásoknak. :)"

Jelenleg mindenre lenne jobb, olcsóbb és hatékonyabb megoldás. Megint csak azt tudom mondani, hogy a vaskalapos szakmabeliek tartják életben a nyelvet fölöslegesen, de így legalább a pozíciójukat meg tudják védeni. Ha ez a helye akkor értem, de szakmailag nem indokolt.

"És nem csak beágyazott rendszerekben használják, hanem gépközeli feladatoknál (pl. driverek),"

Ez ugyan az, mint az embedded. Az esetek max 10%-ában lehetne az ember flegmább a kódjában, de a beidegződések miatt még ott is megkövetelik a MISRA irányelvek használatát (most az ati vga-kat hagyjuk, blődségekkel nem foglalkozunk :P)

"vagy olyan függvénykönyvtáraknál, amiket pont a magas szintű nyelvekben szeretnének majd használni, de ott már teljesen kioptimalizált, villámgyors kódként kell futnia a háttérben. Ezeket is gyakran írják C-ben."

És milyen rosszul teszik... csak egyszer kelljen rajta változtatni valamit, csak egyszer hiányozzon a generikusság vagy csak egyszer követelje meg egy vevő, hogy verjék át a dolgot a tüv-ön...

"Jelenleg mindenre lenne jobb, olcsóbb és hatékonyabb megoldás"

Mondjuk egy grafikai függvénykönyvtárhoz mi lenne jobb? Figyelembe véve, hogy a C nyelvet a szerkezeténél fogva igen könnyű fordítani, majdhogynem egy gazdagon megmakrózott assembly. (Kis túlzással persze.) Emberi, fejlesztői szemszögből biztos van jobb, de az eredmény szempontjából gyorsabb, kompaktabb, optimalizáltabb, szabványosítottabb kódot nehéz lenne kanyarítani.

De nem akarok mindenáron vitázni, nyitott vagyok az újdonságokra. (Bár úgy tűnik, hogy neked mindenki vaskalapos, aki leereszkedik a proci utasításkészlet közelébe. :D)

Nem gondolom, hogy ahol szükség van assembly-re ott is valami torony magas nyelven kéne produkálni valamit. De ahogy mondtad a C egy feltupírozott assembly. A gond nem a sebességgel van, hanem a fejleszthetőséggel. A C++ vagy D nyelv hasonló képességekkel rendelkezik sebesség és memória használat terén, mégis nagyságrendekkel átláthatóbb és modulárisabb mint a szimpla C. És természetesen ezek is képesek assembly hívásokra.

A grafikai lib-ek pedig egye inkább ebbe az irányba mennek. Talán egyedül a CUDA ami nagyon erősen C vonalat követ.

"nagyságrendekkel átláthatóbb és modulárisabb mint a szimpla C"

Ez tény, a C nem az átláthatóságáról híres. Nagyobb projekteket valóban értelmetlen C-ben írni, ebben egyetértünk. Erre utaltam korábban, hogy a megfelelő helyen kell alkalmazni. A C++ sem fordul mindig terjengős kóddá, de épp a magas szintű struktúrái miatt nem tud olyan kompakt eredményt hozni, mint egy C-ből fordított kód. A C épp arra jó, hogy mondjuk egy C++ által használt külső függvényt összeállítsunk vele, amit majd ezernyi programozó használ, és utána dicséri a C++-t, hogy milyen jó kis kódot generál. :))

Amúgy értem, amit írsz, van benne ráció, de mégis hadd védjem meg a C-t. Nagyon sok helyen használják, sok olyan magas szinten használt háttér "tool" létezik, ami mellett ott van kis betűvel, hogy written in C.

Respect. :)