Ale píše demagogicky, pekaž nemusí znát jak se staví pec, jako programátor nemusí znát jak vyrobit procesor. Pekař má vědět, jak pec funguje, tal jako programátor jak funguje procesor... Buď manipuluješ nebo nechápeš obsah vět...
V tvém příkladě, nastavení SQL a všeho okolo, copak se to občas nenastavuje podle typu procesoru, grafiky apod. abys dostal největší výkon, takže u toho hardwaru-pece musíš mít představu co dělá...
P.S. dotatek, zesměšnit oponenta na základě formy sdělení místo obsahuu ukazuje, snahu o morální nadřazenost=ty seš ta šlechta, co kritizuje článek, nemáš šajnu o čem to je, ale víš, že jsi lepší. Problém, je že ani nechápeš obsah toho co někdo jiný napsal, a dáváš přirovnání co neodpovídají obsahu, ale potvrzují co cheš dokázat ty... :D Hol to je ta šlechta :D
A teď si polož otázku zda něco podobného není i ve vyšším jazyce u linuxu či windows a zeptej, se jaký čas a zdroje to sešere u toho asm a kolik u toho C++ ...
To, že autor říkal něco pro pobavení neznamená, že zhodil celý systém, ale jenom, že má humor a nebojí se dělat si ze sebe srandu. Bohužel "šlechta" s toho pak vyvozuje dalekosáhlé důsledky, jako že asm a psát v něm systém je blbost, protože to přeci 20x volalo instrukci...
Četl jsi článek i to co ten na koho odpovídáš napsal? Stvé odpovědi vidím, že jsi vůbec nepochopil o čem to píší. Pak i tvá znalost "psychologie" apod. nebude to v čem vynikáš...
Pro tebe, podle kódu poznáš jestli někdo umí nebo ne (není to o "prasení" kódu, ale "jak ho prasíš" a hlavně nezáleží na tom v jakém jazyce píšeš jako takovém (jak "tzv. šlechta" prorokuje, kdy PHP apod. dělají lepiči.., z hlediska assembleru je pak "lepič" i programátor C++...), to chce ale pochopit psaný text obsahově ne pouze číst písmenka. Dalo by se říci, že jsi předvedl rozdíl mezi lepičem kódu a tím kdo chápe :D
Ten popis by odpovídal na MenuetOS http://www.menuetos.net/
Sleduji ho cca 10 let a stále je aktivní.
MenuetOS is a pre-emptive, real-time and multiprocessor Operating System in development for the PC written entirely in 32/64 bit assembly language.
JA! Ja jsem za poslednich 5 let programoval v assembleru :-)
Mimo jine jsem se i podilel na psani kompilatoru C pro pic (cpik).
Sice v posledni dobe radsi pisu v C, na assembler jsem uz linej, tak nekdy se vyplati si nektere rutiny napsat v assembleru. Viz muj blog, hlavne jeho komentare:
http://blog.root.cz/jetset/pocitani-s-pretecenim-v-c/
Jaky je cil ? Proc pouziji MCU misto CPU v embeded nebo ne. ? Jaky jazyk k tomu mi bude lepe vyhovovat ?
Tak rozhodne to neni nutne o assembleru, ale stejne se k tomu dostanete. Je vhodne mit dobre vedomosti z elektrotechniky.
Programator MCU se totiz krome veci kolem prog. jazyku, knihoven frameworku apod. musi jeste vyporadat HW -datasheety, vhodna zapojeni a nastaveni apod. Jinak ten jeho program nemusi fungovat spravne.
Takze clanek lepic kodu x programator x assembler je spise subjektivni pocitem autora.
Bude je NECO(programator, vec...) kvallitniho nebo NE, nazdar.
Tušíte zda pan Malý umí programovat? Vím, že o programování píše, ale některá jeho tvrzení mě děsí.
Např. když jako jeden z mála přípustných jazyků pro embedded systemy vyjmenuje C (s čímž se dá docela souhlasit), proč v něm pak zakazuje objekty a uvádí je jako embedded zlo? Kdokoliv kdo v C napsal alespoň Hello World určitě zaznamenal, že C není objektový jazyk.
A ještě dotaz do davu. Kdo za posledních pět let použil pro nějaký embedded system assembler? Ideálně něco serioznějšího, co se má prodávat a dá se očekávat budoucí vývoj. Já použil assembler naposledy odhadem 1998 pro PIC a možná i AVR, ale později i pro AVR nebyl problém s C. A dnes s levnými ARM Cortex si nedovedu představit, že by mělo smysl assembler použít, vyhnout se tím HAL a kód kontrolovat s každou novou sérií procesoru ...
No, budete se divit, ale zrovna před pár týdny mi volali z firmy, které jsem napsal před 17i lety menší fakturační a výpočtovej program, že by tam potřebovali pár úprav. Když dneska to GUI nebo vlastní kód vidím, tak bych se skoro styděl, ale jak vidno, pořád slouží ke spokojenosti uživatelů :) A proč to pořád funguje? Protože M$ alespoň částečně drží zpětnou kompatibilitu a přinejhorším pomůže Virtual PC.
Nevěřím. Z mé zkušenosti vím, že programování vlastně není o programování. Spíš je to směs sociální antropologie, psychologie a věštění z čajových lístků. Krásně napsaný kód většinou nedělá to, co požaduje zákazník. Toho je většinou nutné dosáhnou pouze zpraseným kódem. Určitě bych netvrdil, že dokážu říct, jak rychle bude běhat sprinter podle toho, jak si zavazuje tkaničky.
Daji, ale stoji to silene penize (nebo cas, to je to stejny), trpi to malou rozsiritelnosti a kvuli durazu na detaili se zapomina na vysokourovnovejsi optimalizace. Pro veci jako QNX, kde je +- zrejmy, na co se bude pouzivat, pritok penez je konstantni a rekneme i jisty, je to celkem jedno (spis vyhoda), pro obecny OS cesta spatnym smerem a proto zadny z techto pokusu neuspel.
Priklad vzpominal jeden spolutvurce podobneho OS (assembler, melo to par stovek kB): "meli jsme krasne optimalizovane vykreslovani titulkoveho pruhu oken, vazne vymazlenej kod. potom nekdo zjistil, ze se pri presunu okna zbytecne vola asi 20x, a to proto, ze uz vlastne nikdo moc nevedel, jak se horni prekreslovaci vrstva presne chova, tak to bylo optimalizovane".
Pekař nemusí znát technologii stavby pece, ale měl by si ji být schopen sám nastavit - tedy v dnešních podmínkách nainstalovat SQL, službu pro WWW a PHP, nastavit prostředí pro Javu apod. Vlastní aplikace už může být předpečená houska, jen je ta pracnost někde jinde.
P.S. - umýchat podle vzoru mýchačka (či lidově měchačka :)
Tak dlouhá reakce na vtip... Ale chápu, sebeabsurdnější tvrzení dnes může být myšleno vážně a kdo to má poznat.
Když už tedy vážně, tak v tvrzení "Vždyť zmetky ani nejsou levnější" se skrývá jeden "drobný" háček, ony nejsou levnější, pokud umíte vytvářet i nezmetky. A to je právě ten základní nesamozřejmý předpoklad.
Ono se dokonce vyrobit zmetek může dost prodražit, tedy už jsem aspoň viděl takové chyby, u nichž mi přišlo, že vytvořit je vyžadovalo netriviální extra úsilí oproti tomu napsat to normálně/logicky.
Sice nemůžu vyloučit, že si dotyční teorii o potřebě kurvítek osvojili a začali ji aplikovat, ale pravděpodobnější je, že nějaký student dostal zadání, které byl sice schopen pochopit, ale už ne tak úplně vyřešit, "naštěstí" hodný strýček Google poskytl hotové kusy kódu, které dělaly více méně to, co se požadovalo.
No a přichází pointa, najít a zkopírovat sto řádek obskurního kódu už může být levnější než napsat deset vlastních.
My jsme se nedávno s kolegy shodli, že by se do software měla dávat kurvítka. Aby to alespoň jednou za rok spadlo na hubu a vyžadovalo ruční zásah. Už nás nebaví, když najednou přestanou tiskárny na logistice tisknout loga a my zjišťujeme, že v roce 2004 někdo naprogramoval nějaký program, co se chová jako LPD služba a do tiskových úloh ta loga přidával. Kdo si to má po těch letech pamatovat? A jak vůbec zjistit, jak to funguje? Tak jsme to opravili v moderním duchu a je to fajn. Sice nám ten tisk teďka přetěžuje internetové připojení (ono 50KB bitmapa v každém štítku generovaném na ERP serveru v Amsterdamu už se při tisíci štítcích za hodinu docela pozná), ale máme z toho mnohem lepší pocit.
Ale dost ironie. Prostě se snažím říci, že dodnes používáme in house made programy, kterým je 10+ let. Ten kód nikdy nebyla perla, některé kousky jsou docela nečitelné hacky. Ale fungovaly tehdy a fungují i dnes. Je to o stylu práce, o přístupu ke kvalitě. Zákazník možná chce něco, na co sám zítra zapomene. Ale ode mne dostane něco, co i zítra bude fungovat. I pozítří. Neznám žádný objektivní důvod, proč by měl dostat zmetek. Vždyť zmetky ani nejsou levnější, takže ani na peníze se to svést nedá.
PS: To frikulínské řešení s tiskem štítků jako bitmapou jsme vypli. A kolega byl proškolen, jak upravit Makefile tak, aby se ten LPD server zkompiloval na 64bit a mohl tak sloužit dalších 10 let.
No, současná situace v IT je spíš taková, že se za špičkového pekaře považuje člověk, co vytáhne z mrazáku předpečenou housku, tu posype mákem, a strčí ji do pece. Článek pak netvrdí, že si máte zkusit vyrobit mlýnský kámen. Tvrdí, že je dobré si alespoň jednou zkusit umýchat těsto.
Přestože se shodneme na tom, že je mnohem snažší, rychlejší i ekonomicky výhodnější ho kupovat už hotové, v úhledných balíčcích s dávkovačem. Pokud máte denně vyrobit tunu různých druhů pečiva, tak prostě nemáte čas si na všechno sám dělat těsto. Ale i tak si myslím, že by si to pekař zkusit měl. Minimálně vědět, z čeho se skládá. Alespoň kdyby rozuměl kvasnicím, droždí a prášku do pečiva, aby chápal, proč to občas kyne moc a jindy vůbec.
Jenze ono nejde o to, ze by nekdo mel umet assambler, ale o to, ze by mel vedet jak to, na cem ten jeho web pobezi funguje. Pak by se nedelo to, ze se tvurce strasne divi, ze ten jeho uzasny vytvor, je zcela nepouzitelny.
Priklad? Mejme aplikaci, ktera (mimo jine) ma funkci pro import dat. Ta funkce vytvorena podobnym umelcem importuje data rychlosti 1 zaznam 10s. Script, ktery obejde aplikaci to zvladne asi o 6 radu rychleji. A to by to zcela jiste slo jeste o rad nebo dva zrychlit, kdyby se to napsalo v tom assambleru.
Dobře jsem se pobavil! Asembler jsem jsem musel umět jako základ, jako diplomku jsem naprogramoval v ML/I (Macro Language One (perfektní cvičení na rekurzi)) jazyk pro popis modulů překladače. Něco se mi dokonce podařilo odladit do obhajoby, pak už po tom neštěkl ani pes. Ale jsem vlastně podle definice king :-))
Není pravda, že by se v 70. letech programovalo jen v asembleru. Dotáhli jsme do chodivé verze informační systém napsaný v MUMPS (interpret pro práci s texty), psal jsem v Simule67 a podobných projektech. Vždy by to mělo být o tom, co chcete naprogramovat.
Znalost asembleru se hodí pro jednočipák nebo když potřebuji něco provizorně upravit, podívat se na dumpu, co se děje.
Nelíbí se mi rádoby vtipné poznámky u pár instrukcí asembleru ve výukových kurzech, že tomu vlastně nikdo nerozumí. Že nikdo neví, co se vlastně v tom počítači děje. Takoví lidé by se neměli vydávat za velké učitele a guru programování.
Naopak, pokud někdo potřebuje jen webovou stránku, proč by měl umět asembler?
Pokud si někdo potřebuje zvýšit sebevědomí, ať se naučí číst čínské znaky. Umí to přes miliardu lidí a bude asi časem dost potřeba.
Zajímavou cestu životem přeje Děda Číňan
Berte to tak, že se konzumerismus dostal už i do programování, zákazník chce dnes něco, na co sám zítra zapomene, tak mu to dnes splácám a on mi to dnes zaplatí. Proč bych si na to měl zítra vzpomenout? Nejde o dobře zakamuflovanou versus dobře vykonanou práci, jde primárně o práci dobře zaplacenou.
A za dvacet let? To už ani nebude existovat zařízení, na kterém by se ten můj kód (ať už perla či zmetek) dal vůbec spustit (pomineme-li nějaký fanouškovský emulátor).
Potiz s dynamickou alokaci neni v rezii spotreby pameti. Daleko vetsi problem je nekonstantni cas nutny na alokaci a fragmentace pameti pri alokovani/uvolnovani objektu ruzne velikosti. Jakmile dojde na hard-real-time nebo systemy se zarucenou bezpecnosti podle ISO61508 (a dovozenych) pak teprve nastane peklo a dymamicka alokace new/malloc je v podstate vyloucena. Pouzivaji se jine techniky napriklad alokacni pool fragmentu pevne velikosti a podobne. I kdyz rezii pocitano spotrebou pameti pameti to ma nekdy i vetsi, ale pamet se prikoupit/zaplatit da, cas je neuprosny.
Zabíháš moc daleko, každý pekař by měl vědět, jak se dělá mouka a na co různé druhy mouky použít. Ve výsledku vezme pytel, nasype do hnětače, počká, uplácá chleby, rohlíky, koláčky, cokoliv. Ale až jednoho dne zjistí, že jeho pečivo tak nějak najednou stojí za prd, měl by poznat, že ta mouka je taková divná a že se asi něco nepovedlo, dodavatel to začal flákat atd. Nikdo tu neříká, že si má každý programátor navrhnout vlastní CPU, jen to, že je dobré mít představu, jak to vlastně doopravdy funguje. Z principu je totiž spousta věcí, která se nedá škálovat, HW taky nelze do nekonečna zrychlovat a když se zjistí, že ten kus lejna vytvořenej v Javě je prostě pomalej a žere moc prostředků, přichází na řadu optimalizace (respektive v případě Javy spíš přepsání od začátku v něčem normálním).
A mimochodem, když jsme u toho pekaře, co určitě musí každý pekař vědět je, jak peče jeho pec. Stejně tak by programátor měl vědět, jak se chová jeho překladač/interpretr. Bohužel, dnešní doba je taková, že pokud chce programátor vykreslit zelený čtvercový okýnko s růžovým nápisem, vezme si na pomoc jednu knihovnu, které umí zobrazit okýnka, druhou, která je umí obarvit, třetí, která ho udělá do čtverečku a čtvrtou, která vypisuje barevnej text. Každá z těch knihoven má samozřejmě svoje problémy, každá toho umí milionkrát víc, každá má 10MB, ale to "programátora" samozřejmě nezajímá. Tenhle nešvar je všude. Na webu se to potom projevuje třeba tak, že "pan programátor" klidně přišoupne na stránku jQuery kvůli jednomu pomatenýmu blikajícímu tlačítku, protože se to tak prostě naučil. Má to přece jenom 40kB. Já si o tom myslím, že za prvé tlačítko nemusí blikat, za druhé se to dá řešit jinak, většinou tak dvouma řádkama JS, případně rovnou v HTML5 a ten kdo to udělal v jQuery je pro mě tupec. A tím nechci odsuzovat jQuery, může hodně zjednosušit a zrychlit tvorbu, ale na komára se prostě s kanónem nechodí.
Jojo, reference je i ve vyšším jazyce vždycky rychlejší...
https://phpfashion.com/php-puvab-optimalizace-rychlosti#comment-7995
Zdravím,
tady bohužel nezazněla jedna velice podstatná věc a tou je rozsah projektu.
Pokud dělám projekt velkého rozsahu, konkrétně mailserver s groupware funkcemi, tak se prostě bez těch vysokoúrovňových jazyků neobejdu.
Není možné to celé psát v assembleru protože složitost projektu to nedovolí.
Proto se to píše v c++ s použitím externích knihoven.
Problém je jinde. Pokud budu potřebovat předat např. velké pole dat, tak je nebudu dávat hodnotou ale odkazem protože vím, že předání a vracení hodnotou znamená dvojí kopírování celého pole.
Zároveň se při psaní kódu potřebuju soustředit na algoritmus aplikace z pohledu zákazníka, ne na to kolik bajtů zabírá reálné číslo a v jakém formátu je v paměti uložené. Stejně tak nechci počítat offset ve struktuře v paměti. Tuhle abstrakci ať za mne dělá překladač.
Reálné velké projekty mívají běžně i přes 100 000 řádek vlastního kódu (bez externích knihoven).
Tohle se bez několika urovni abstrakce zvládnout nedá.
Něco úplně jiného je malé zařízení na jeden přesně daný úkol.
Shrnuto: Není možné srovnávat hrušky a jablka.
já jsem o generaci mladší a povinnost psát v nižších jazycích mě minula, C bylo minimum, kam jsem se profesně dostal, zbytek je jen koníček.
Jednoznačně souhlasím s tím, že znát vnitřnosti je k nezaplacení. Vadí mi situace, kdy současné JIT jazyky neumí jednoduše vrátit generované pseudoinstrukce, přitom tím přesně řeknou, co daný kód dělá a jak je náročný a napoví jak ho optimalizovat.
Mám úplně stejný pocit, podle mě se autor do těch jednočipů tak zavrtal (zřejmě proto, že jim fakt rozumí), až zapomněl zmínit pointu, že jakékoliv "já dělám tohle, takže jsem víc" je nesmyslné, protože "omezené zdroje" nejsou nějaký jednostranný limit typu "512 bytů RAM", ale jde o vztah "mám k dispozici tohle a chtěl bych udělat tohle (a v reálu na to ještě mám maximálně tolik času)", ono ani těch 512 bytů RAM není "univerzálně málo", ale je to málo až ve chvíli, kdy potřebuju netriviální množství paměti.
A ať už se pohybuju kdekoliv, vždy existují úlohy, které nějak splácám, a úlohy, kde jde do tuhého a je třeba jednak přepnout myšlení na onu konkrétní oblast, jednak možná i "hackovat best practices", protože realita bývá mnohem rozmanitější než teorie a na "tohle by mělo fungovat, ale nefunguje/nefunguje dostatečně efektivně/funguje s těmito vedlejšími efekty" se dá narazit leckde.
DI HALT už jsem neviděl dlouho :-D
Jinak k článku - pěkně napsáno, rozhodně každej by si to měl v assembleru zkusit, porovnat si třeba Hello world v různých jazycích. Člověku to dá strašně moc. A jak tu někdo psal, cracking je bezva škola - zjistit, co tím chtěl autor a kompiler říct. S láskou vzpomínám na několikahodinové trasování obfuskovaného kódu, kdy člověk nakonec přepíše jeden podmíněnej skok na JMP nebo NOPy a ono to najednou zázračně funguje (nebo už to nefunguje vůbec) :-)
Plně souhlasím se "Snape". Léta mě jako systémového programátora na sálových mašinách Assembler pro S360/370 živil.
Myslím si, že programování v Assembleru (či nedejbože ve strojovém kódu) dává každému programátorovi představu, co procesor umí a co mu ulehčí práci.
Pro velké projekty Assembler nevyužije, ale ty znalosti ano. Hrubou silou výkonu procesou všechno nenahradíš. Dejme tomu v nějaké aplikaci se to dá skousnout, ale v systému typu Windows je setsakra znát, že dotyčný programátor nemá ani ánunk o existenci postupů popsaných např. v knize Operační systémy od pánů Stuart E. Madnicka, John J. Donovana. Pro nás to byla před 30-40 lety bible.
Programuji 35 roků, dělal jsem v 18 jazycích, ale nejlépe umím Assembler 370 plus macro. Do dneška umím číst hexa kód a převádět zpětně přímo do assemblerovských instrukcí. Assembler 370 mi dal základ pro všechny vyšší jazyky. Jakmile si člověk zvykne na způsob, jakým stroj řeší úkol (co všechno musí udělat v pozadí na vyřešení nějaké triviality), automaticky a skoro intuitivně nedělá v programu humus. A naučil jsem se (jako grafolog) číst kódy jiných kolegů a odhadnout, kdo je v programování dobrý, kdo na to má a kdo ne. Být manager přijímající adepty do oddělení programování, nemusel bych dělat vstupní intervia ani číst resumé, stačilo by mi ukázat část jeho kódu.
Bohužel musím konstatovat, že skutečných programátorů je zoufale málo. Téměř neexistují. Kóderů a patlalů je plno a čím větší patlal, tím namyšlenější. Tihle lidé s oblibou kolem sebe házejí složité pojmy, ale stačí se podívat na kód, který produkují, a je jasno.
také ten pocit nemám a ani se mi nezdá, že by to nějak vyplývalo z mého textu.
Chtěl jsem jen říct, že souhlasím s tím, že programovat jednočipy je o dost obtížnější disciplína na zkušenosti než "webové" věci a že právem se jednočipáři smějí válkám "webařů". Zároveň jsem chtěl naznačit, že clusteři zase se stejným pohledem koukají na jednočipáře :). Nic víc.
Reagoval jsem spíše na předchozí příspěvek než na celý článek, autora i jeho postoje znám a vůbec neuznávám hlásání, že zrovna moje technologie je ta nejlepší a nejtěžší a to podle mě mohlo být vedlejší poselství článku.
Nevím, občas programuju pro Arduino, mám tam asi 16kB flash, a 1kB RAM. Jsou to trochu spartanské podmínky, ale krásný kód se tam dá psát taky. Používám celou plejádu vyjadřovacích prostředků, od objektů, virtuální metod, virtuálního dědění až po šablony. Jediný co na Arduinu nefunguje jsou výjimky (škoda).
Co se paměti týče, je jasné, že dynamické alokace mají režii (mám pocit, že 4 bajty navíc) a jsou pomalejší (no jasně, paměť je spojový seznam, hledá se sekvenčně), ale nemáme přeci jen haldu, máme i zásobník.
Lze použít i globální proměnné, ale mnohem radši sahám po globálním singletonu a na úrovni volání funkcí si předávám reference na jednotlivé objekty uvnitř. Nic to skoro nestojí, tyhle procesory mají dost registrů. Objektový návrh pořád umožňuje pozdější rozšířitelnost. Mám tam jednu blikající diodu? fajn, co když budu chtít dvě?
Je třeba mít přehled o tom, co všechno to stojí. R/O struktury se spravidla strkají do ROM. Ale objekt s virtuálními metodami má jeden pointer navíc. Virtuální dědění znamená další pointer za každou virtuální base. S tím se dá žít, když to člověk potřebuje. Nejlepší jsou v tomhle šablony. Ty nemají zpravidla žádné režie na záběr RAM. Ale mohou zabrat více ROM. Nicméně si člověk pak uvědomí, že beztak by to musel implementovat tolikrát, kolikrát to potřebuje. Překladač (GCC) s patřičným přepínačem dokáže využít i společné části kódu šablony, takže nakonec ušetří.
PS: Tabulkové GOTO? Sorry, já myslel, že se používá switch-case.
"Špičkový programátor" bude znamenat něco jiného při vývoji embedded systémů pro cenově dostupnou domácí automatizaci a při vývoji firemního informačního systému, který se má dalších 15 let neustále s rozumnými náklady rozvíjet, přizpůsobovat aktuálním byznysovým potřebám dané firmy.
Mě tedy nejvíc dal cracking.
Té slávy, když se mi povedlo očůrat demoverzi programu pro výuku psaní na stroji zapsáním 0x90 na vhodné místo.
Následovaly složitější a složitější aplikace, první keygen, první Windows aplikace, založení a tak dále a tak podobně :)
SoftICE a IDA, v těch jsem býval jako doma. Pak už nebyl čas, tenhle obor vyžaduje opravdu maximální nasazení...
Ale klidně bych dal vytvoření jednoho malého cracku do toho checklistu pro výrobu špičkových programátorů :)
autor má ve všem pravdu a přitom se naprosto mýlí. V assembly zase nelze jednoduše pracovat v týmu ve více lidech zároveň, jednočipy jsou zároveň i jednolidi :). Stejně tak distribuované clustery o stovkách, tisících čipech se z toho obtížně řídí a programují.
Sice autor píše o vyřešení problémů a ne jejich řešení, ale sám musí uznat, že pokud potřebuje vizualizovat nějaká data (třeba z IoT), těžko vezme jednočip, monitor a jde si kreslit grafy, ne, vezme notebook, otevře si chrome, vběhne do f12, naloaduje třeba d3 a během 3 minut má 3d vizualizaci data stažených po síti z db.
Ano, máš pravdu, zastávám to, že na řešení nějakého problému prostě použiji vhodné řešení a nebudu vše ohýbat, jen abych vše měl v jednom...
Není to jako srovnávat astrofyziku a kvantovou fyziku a kdo přetahovat se kdo dělá větší "vědu" ? Já naopak viděl spoustu kódu napsaný lidma s velkými zkušenostmi v C a výsledek byl ve velkých java frameworcích katastrofa. Oboje je úplně jiné a vyžaduje jiné kompentence a způsob myšlení.
Ok, takže pro vývoj pro mikrokontrolér v c je potřeba dodržet tyto zásady:
1. globální proměnné nejlépe v union struct, žádný alloc, co nejméně stack
2. stavový automat pomocí switch
3. upravit v projektu výchozí velikosti paměťových bloků, aby se tam vešla ještě ta jedna rutina, kterou potřebujete.
A teď pro srovnání vývoj aplikace s frontendem, middlewarem, databází integrovanou se systémy třetích stran a nasazenou v několika datacentrech...
Problém je, že v tom nízkoúrovňovém programování jsou prostě bity v paměti, bity v registru(ech) a bity na nějakém výstupním zařízení. A soubor pravidel nad nimi, poměrně jednoduchých. A to je prakticky vše.
U těch jazyků "vyšší úrovně" sedí mezi mnou a procesorem i několik úrovní abstrakce, mnohdy nijak nezdokumentované, případně zdokumentované totálně idiotsky (příkladem budiž java), a většina programování spočívá v boji o zjištění, "co tím básník chtěl říci". A zjišťování, proč statické objekty nemohou plnohodnotně spolupracovat s dynamickými a jak tuto ptákovinu obejít, protože některé metody jsou jen ve statických a jiné jen v dynamických objektech a člověk potřebuje, aby nějak spolupracovaly.
Dokážu si představit, že nízkoúrovňové a objektové programování "sedí" docela rozdílným typům lidí s rozdílnými preferencemi v myšlení.
Jinak "Bity do bytu" byla geniální kniha a pana Zajíčka je strašná škoda.
Joo to byly krásný doby, kdy sem seděl celý noci shrbenej nad ZX Spectrem a louskal "stroják", pak PMD85 a nakonec první PC XT.
Jednočipy znovu přináší tu přímočarou jednoduchost kódu, který ovládám jen já sám a nemusím zabíjet hodiny na googlu hledáním proč se tohle nebo ono přeložilo jinak, peklo sdílených DLL, záhady windows a jiné lahůdky.
Až rozšíření jednočipů mi připomnělo doby, kdy platilo "real programmers use: copy con program.com" :-)
Přesto všude vidím úplně opačný trend tlaků na co nejvyšší abstrakci a OOP only..., optimalizace je skoro sprosté slovo a co je pomalé potřebuje rychlejší stroj... Bohužel podle toho vypadají i výsledky a to co jsme nucení používat.
Souhlas hlavně proto, že jsem začínal na ZX Spectrum, četl jsem knihu "Bity do Bytu" a programoval jsem embedded zařízení (ještě než se jim začalo říkat embedded :-))
Ale musím autora upozornit, že existují disciplíny (třebas real time systémy, low latency apod.) kde si člověk také zažije opravdové peklo - třeba když honí super kód se za určitých okolností provede o milisekundu pomaleji.
Zase je pravda, že 99% programátorů, když mu řeknu přerušení, to spíš považují za vstup šéfa do kanclu a tím pádem přerušení toku myšlenek, než něco spojeného s programováním - a to je asi škoda ...