Vlákno názorů k článku Vývojové nástroje používané v dobách osmibitových mikropočítačů od jasnovidec - Hezké. Vždycky jsem záviděl těm, co se mohli...

Hezké. Vždycky jsem záviděl těm, co se mohli o počítače zajímat už řekněme v těch 80. letech, kdy jsem ještě nebyl na světe. Máte velkou výhodu, protože jdete s dobou, víte proč je dnes to tak a tak, protože to vyplává z nějaké evoluce těch procesorů apod.. Jste i lepší programátoři. Já si dokonce myslím, že může řekněme za 10-20 let nastat docela pr**er, protože budou chybět tyhle lidi chybět a budou jen javisti. Už nikdo na vývoj core věcí v asm a C.

No on to byl docela opruz, a právě proto vznikla Java. V tom osvobození od hw omezení byla výhoda. Java příštích let bude virtuální stroj pro ne-neumanovské architektury. Jinak za 20-40 let se hw i programy budou navrhovat samy, lidé je budou analyzovat, aby věděli co dělají, z programátorů se stanou policisté dohlížející na to, co dělají stroje. Kontrolní mechanismy budou zabudovány do VM, na jakém poběží, aby o něm ty stroje nevěděly :-)))

Tak nějak, vývoj software probíhá tak aby daný program stále pokud možno alokoval všechny dostupné zdroje při neměnící se funkčnosti.

Tak ono kdysi býval docela problém zobrazit na PC i obyčejnou fotku, a co teprve nějaký film. I zázraky zevšední, dějí-li se denně :-)

Opruz snad pro ty, které to nebaví nebo to neumějí.
Java nebyl špatný nápad(ale ani nijak nová myšlenka), problém je v tom, že se cpe tam, kam nepatří.

No assembler mě celkem bavil, ale přece jen budovat své vlastní objektové světy je mnohem zajímavější. Jednou Java pojede i ve vaší hlavě, propojení stroje a lidského mozku je výzva, která nás teprve čeká :-))) No jen si to představte, po síti si připojíte neuronovou síť ovládající starou sumerštinu a můžete se začíst do originálu Eposu o Gilgamešovi. Nebo připojit si modul teorie relativity, nebo strunové teorie a ihned s ní začít pracovat, jako byste jí znal roky. Pokud toto nastane, začne platit druhý Moorův zákon - znalosti lidstva se co dva roky zdvojnásobují :-)))

Mno to právěže vůbec - Java a vlastně všechny klasické algolské jazyky mají dost vážný problém s během na vícejádrových systémech, koncept instancí tříd, vláken a zamykání není to pravé do budoucnosti.

Navíc "a 20-40 let se hw i programy budou navrhovat samy", to skoro zní jako stará dobrá parodie na AI, té také dávali jen 10 let (už nekdy od roku 1950) a vono furt nic.

Nebyl to opruz. Tedy, pokud člověk uměl programovat a měl nadání. Java pozděj vznikla mj. proto, aby mohly programovat i cvičené opice. Jsem si však jistý, že tomuto mému tvrzení bude spousta lidí oponovat.

No v té době nebyly jen jednoduché mikroprocesory, ale taky normální počítače a operační systémy jejichž vlastnosti PC dosáhly až 20 let po té. Programování v assembleru, nebo dokonce ve strojovém kódu mikroprocesorů byla z nouze ctnost. Stejně jako problémy s přetečením paměti v C. Mnohem starší jazyky, jako například Fortran ničím takovým netrpěly, snad jen počítané GOTO pro opravdové programátory, nebo problematické používání globálních proměnných v oblasti COMMON :-) Stejně rutinní činnosti se i v assembleru řešily pomocí maker bez nějakého počítání adres, což by stejně ani nešlo, když ty systémy používaly stránkování paměti. A toto elegantně řešila Java. Před ní se de facto programovalo "objektově" i v makroassembleru, kdy "objekt" byl realizován částí názvu rutin, ovšem bez dědičnosti. Java byla jen logickým pokračováním a rozšířením těchto technik rozpracovaných dávno předtím v 70. letech.

Když přemýšlíte, taky se nestaráte o přidělování paměti ve svém mozku, vaše myšlení jede ve virtuálním stroji, stejně jako Java :-)))

Taky jsem z těch "starších" a musím říci, že až tak zlé to není. Pořád se rodí lidi jako jsme my :-) i přes všechnu tu povrchnost a lenost myslet kolem.
Jen je nesmíte hledat na Facebooku nebo na reklamních akcích Applu a Microsoftu...

Ale to jsou přece věci co se dají naučit za pár měsíců. Princip obsluhy přerušení přece není nic složitého. V rámci firemní kultury, můžete mít vypracovanou kuchařku, či rovnou framework, jak který obvod ovládat. Přece aby si to každý bastlil po svém, není dobré. Prostě zaplatíte jen pár platů bez toho, že by si hned na sebe vydělal, když ho přijmete na dobu určitou, třeba dva roky, tak ani neriskujete, že vám odejde, aniž by se vrátily počáteční náklady.

No tak embedded je dost specifická oblast v níž se zas tak moc lidí nepohybuje, takže bych to nepřeceňoval. Co tu píšeš jsou zrovna věci vysvětlitelné během pár minut (btw, "direktivy kompilátoru C" - tím myslíš makroprocesor? Nebo jen konkrétně #pragma volby?).
Mnohem problematičtější pro lidi bez embedded zkušeností je specifický způsob ladění, pokud z nějakého důvodu nelze použít různé JTAGy a STLINKy.
A z druhé strany je zase problém u embeďáků samotná programátořina. Kdykoli jsem přebíral nějaký cizí projekt, tak snad pokaždé byl z hlediska technik programování a štábní kultury neuvěřitelně zprasený. Tím myslím nevhodně pojmenované objekty, nevhodně dekomponovaný, různé hacky použité na naprosto nevhodných místech...

Takže své zkušenosti bych shrnul asi tak, že embeďák-programátor by měl vědět něco z elektroniky, ale nepotřebuje umět spočítat zesilovač nebo filtr, prostě stačí mít povědomí, co se mu po těch drátech honí na digitální úrovni a co to vyvolá v obvodech na jejich koncích za reakce. To se dá vysvětlit a ukázat poměrně snadno, pokud neví. Dále by měl vědět něco o tom, co píšeš, ale to se dá taky celkem rychle vysvětlit a navíc na konkrétní technologii.
Ale co se během pár dnů zaškolení vysvětlit nedá, to je právě ta poctivá programátořina, protože oproti PC zde pracuje s poměrně omezenými zdroji a jednoduchými nástroji (C, Forth, Assembler), proto by měl takovou tu programátorskou latinu mít v malíku - vedle klasických technik programování též vědět něco o tom, jak fungují kompilátory, uvažovat o tom, jak se jaká konstrukce na dané platformě asi přeloží, vědět, kdy smyčky nerozbalovat a kdy ano, raději testovat na nulu pokud to je možné, umět odstranit rekurzi, bezpodmínečně mít v malíku dvojkový doplněk, aritmetiku v pevné čárce, logické operace a mít cit pro to, kdy a jak je použít, jak recyklovat různé mezivýsledky atd. a to vše si spojit s konkrétní platformou, tj. má/nemá násobičku, má/nemá instrukce na dělení a pokud ano, jakým algoritmem, jak rychle a jak přesný výsledek potřebuji, jaké jsou možnosti jeho dosažení různými metodami...
Příklad z praxe - v rámci výpočtu bylo třeba zprůměrovat tři vzorky signálu a kvůli tomu, že se to nestíhalo, byl navržen redesign s rychlejším procesorem jiného typu, práce nejméně na jeden člověkorok, náklady přes milion. Přitom si stačilo uvědomit, že není třeba nic dělit, ale stačí v daném případě vynásobit fixedpointovou jednou třetinou. A to jsou ty znalosti, které během pár dní nepředáte, které dotyčný musí získat studiem projektů od mistrů a mít na to hlavu.

No tak embeded programátor používá jen operace + ,<<,>>,xor,and,or a žádné jiné a ví, že by vystačil jen s xor :-))) Jinak dělit 3 znamená v cyklu přičítat 3 dokud není větší než dělenec, což lze zrychlit tak, že podělíte 4, tedy provedete dvakrát shift vpravo a dopřičítáte trojky do výsledku, nebo to lze ještě dále urychlovat i se znalosti rozsahů vstupních dat.

No, to už se dneska dávno rozděluje mezi elektrotechniky a programátory. Já si to taky všechno dělám sám, ale řekl bych, že to je výsada takových těch 3členných firem, jako ta naše, aby člověk musel rozumět všemu, od zesilovačů, přes zdroje po FPGA a ještě si navrhoval DPS a pak si to celé oživoval a programoval. :-)
Ale zase jak tvrdí Alan Kay, "People who are really serious about software should make their own hardware."