Nejlepší programovací jazyky aneb co se učit v roce 2018

alokovanie zasobnika na vlakno je vo virtualnej pamati, cize sa automaticky neberie z fyzickej RAM, zalezi na vlakne, kolko si zo zasobnika za behu zoberie

Web bez inteligentního frontendu bych nenazýval funkčním programem. Je rok 2018.

Ty magore, inteligencni front je vše, co vyhovuje uživatelům a slouží jim dobře. Mrkni na bazos.cz, ten maník uspěl s tím, že users nestojí o ty tvoje sračičky v js. Používají to, ptž to plní svojí funkci a je to jednoduchý, pustím to klidně na totálně ořezaný verzi debiana na RPI Zero a jede to vše v pohodě. Klidně na HTML1x browseru. Zkus na tom pustit třeba fejsksich shit a můžu si jít zahrát fotbal.

Tvl ty jsi dobrej magor, jako většina těch js patlalů. Spojit js se sovetským sajúzom. Co přijde příště? Kdo neobdivuje ten tvůj pazmek tak skončí v nějakém lágru v tom tvým sajúzu?

a meli pravdu, vetsina bya naprsty sunt. Sajuz to ubil mnozstvim, na kvalitu sral

Ono je to podobné s tím js. Je moře patlalů, co v tom píše, ale je to šunt. Ona odpověď je poměrně jednoduchá. Zkus říct js "programátorovi", ať napíše driver v C nebo Asm, ani kdyby se posral to nedá. Nebo ať udělá jen blbý build C projektu, js maník bude zděšeně koukat. Ale řekni maníkovi, co umí opravdu programovat třeba v C nebo C++ a i kdyby js nikdy neviděl, za chvíli to dá. Protože js je bastlící jazyk, nemusíš nic umět a chápat o systému, ani nic neovlivníš, i kdybys věděl, prostě píšeš kód bez přemýšlení o dopadu. A ty dutý hlavy v js ti řeknou, že to hw utáhne nebo ať uživatel upgraduje. Prostě bastliči, jak tady někdo psal přede mnou.

Nacisté si také vyhrávali s mikroptimalizacemi svých strojů zatímco jim masově vyráběná sovětská technika dávala na prdel.

Jak v čem ...

Nacisté i sověti vyvíjeli své tanky společně. Německo mělo zakázáno vyvíjet i vyrábět zbraně po první světové válce, tak to v utajení dělali společně s Rusy v Sovětském Svazu a to nejméně do roku 1938. Proto základy jejich tanků jsou shodné.

ne nejsou, ve skutecnosti sovetske tanky mely podvozky christie z US..a motory taktez americke provience , a par britskych RR.

nemci pouze tanky ( spis tankovou taktiku) testovali v rusku.

A nezapomen ze nemci zacali valku s Pz.I a Pz.II coz zrovna moc vykonne stroj nebyly. Zatimco soveti s vecmi jako renault-17, T-28 a dalsimi podivnostmi. Ze zacatku barbarosy rusaky zachranila Americka a Britska materilni pomoc. Pak prestehovni tovaren za ural + jejich nasazaneni na valecnou vyrobu narozdil od nemcu kteri s valecnou vyrobou nezacali do konce 44.

Zděšení Němců po setkání s ruskými těžkými tanky popsalo hodně velitelů. Německé tanky prakticky proti nim zpočátku neměly šanci a na likvidaci se používalo protiletadlové dělo.
Jen neschopnost ruských velitelů zabránila pořádnému využití těchto tanků.

Nacisté chtěli t-34 okopírovat, ale neměli potřebné technologie. Proto vznikl Panther. Koncepčně podobný t-34 sestavený z německých dílů. Dražší, poruchovější a náročnější na výrobu.

Co jim chybělo? Pancíř a kanon? Nic moc víc v t-34 není ...

Materiál na pancíř, technologie svařování, motor, převodovka, odpružení, pásy..... Neměli zkušenosti s podobně těžkými tanky. Neměli optimalizované výrobní procesy, proto spotřebovali na jeden tank několikanásobek člověkohodin.

"In November of 1941, high ranking engineers, industry representatives, and armament directorate officers came to my tank army in order to familiarize themselves with the Russian T-34 tank. Frontline officers suggested that we should build tanks exactly like the T-34 in order to correct the unpleasant position of our armoured forces, but this position did not receive support from the engineers. Not because they were opposed to imitation, but because it was not possible to rapidly set up manufacturing of important components, especially the diesel motor. Additionally, our hardened steel, whose quality was dropping due to a lack of natural resources, was inferior to the Russians' hardened steel."

H. Guderian, "Panzer Leader", page 268

Pokud umím anglicky, tak jim nechyběli technologie, ale nemohli přenastavit výrobu* a ztráceli kvalitu kalené oceli, ale ne kvůli tomu, že by neměli technologie, ale kvůli nedostatku přírodních zdrojů ... což bych řekl, že je podstatný rozdíl ve výkladu onoho odstavce ....

* proč se tam nepíše, možná ty zdroje, ale že by neuměli udělat dieslový motor, notabene ho třeba i okopírovat, si nemyslím.

Re: nechyběly

Je to poválečné tvrzení nacistického generála. Bral bych ho s rezervou. V době studené války nemohl napsat pravdu. Problém byl v zaostalém ocelářství a celkové neefektivitě kapitalistické ekonomiky. Na nedostatek surovin to svalovali po válce.

Německé tanky měly benzínové motory. V technologii dieslových motorů byli nacisté pozadu.

Dieselove motory (napriklad do ponoriek) Nemci robit vedeli. Ale nemali ropu a z uhlia vedeli vyrobit len benzin.
Male zasoby ropy (z ropnych poll v Rumunsku) z ktorej vyrabali naftu, si setrili pre ponorky, preto museli tanky a ostatna technika fungovat na benzin, aj ked to prinasalo obrovske mnozstvo problemov ako kratky dojazd na nadrz a velke riziko poziaru pri zasahu.

@mmm

Aha, takže generál, kterého poválečný citát sis půjčil, nemohl za války mluvit a teď když může tak lže, protože tam říká něco jiného než ty si myslíš .... Proč jsi sem ten citát teda dával?

Citát jsem uvedl pro potvrzení mého tvrzení, že nacisté chtěli t-34 okopírovat.

Po válce (během studené války) v okupované SRN nemohl psát pozitivně o SSSR. Kdyby nebyl dostatečně protikomunistický, ty jeho paměti by nevydali. Paměti generálů jako Manstein a Guderian sloužily hlavně protikomunistické propagandě i v USA byli Němci prezentování jako "ti dobří".

Kdyby měli Němci skutečně nedostatek oceli, tak by jejich tanky nebyly o tolik těžší než sovětské. Neuměli vyrobit stejně kvalitní ocel, tak to doháněli množstvím.

@mmm

Ok, to je nejen ve válce normální, ale zároveň jsi tvrdil, že to bylo kvůli nedostatku technologií. A tak to není, resp. nebylo. I ten citát to dokládá ...

Metalurgie je také technologie navíc ten citát dokládá, že neuměli vyrobit dieselový motor s potřebnou charakteristikou.

@mmm

Metalurgie je soubor technologií, dokonce celý vědní a výrobní obor, nicméně aktuální nedostatek surovin není problém technoligický, ale logistický.
Motor s potřebnou charakteristikou mohli klidně okopírovat. Už jenom to, že by se v celé říší nenašel nikdo kdo by neuměl udělat dieslový motor alespoň podobný, když měli vlastní výroby letadel, raketový program, lodstva, tankových vojsk, je směšné.
Ale v tom citátu se nepíše že neuměli, ale že nemohli přenastavit výrobu na dieslové motory. A pokud to bylo v době, kdy začali dostávat na zadek, tak se nedivím, že nezastavili a nerozpůlili výrobu něčeho, k čemu neměli suroviny ...
Nehledě na to, že přejít na vzdálené frontě na jiný typ pohonu tanků, ne tak ještě že by to by druhý, paralelní, když připočítáš konstrukci, výrobu a továrny, dopravu, opravárenský servis, náhradní díly, pohoné hmoty, výcvik, je klidně i otázka několika let. Ne dvou týdnů, nebo měsíce. Takový krok se v defenzívě může rovnat kapitulaci ...

To je totalni nesmysl. Jazyk C je stejne jednodýchy jako JS, pravdepodobne jeste jednodussi. Tve priklady nejsou o jazyku, ale o odbornych znalostech. Rekniprogramatorovi v C, at napise v JS prezencní a bussines vrstvu nejakeho soap b2b burzovniho reseni a bude v loji uplne stejne.

Já mám poslední dobou opačný problém :) Build C pomocí maka, CMake a v omezené míře autotools si spáchám snadno. Drivery a low level kód píšu často. Ale vyrobit distribuční archiv nějakého projektu v JS je děs - všechny ty neustále se měnící nástroje (npm, bower, gulp, grunt, transcompilery..).

Vyrobit ani ne, ale když se k tomu člověk po 1/2 roku vrátí, tak už polovina nástrojů a závislostí neplatí, nebo jsou o 2 major verze dál ....

Cloveku co porovnava JS a C/Asm sa da povedat len: Si Kreten. To je ako porovnavat Falcon heavy s rogalom.

Dobry je nepritelem skveleho

Jak Python pro weby miluju. Tak ne nemá. A je to dobře. Ono i PHP má svůj usecase. Prostě jde o to, používat tam kde se hodí, na věci větší šahnout po frameworku, nebo úplně jiné rodině jazyků.

Takhle už se myslím v PHP pár let taky nepíše. Místo toho se používá nějaký MVC/MVP/Whatever framework s šablonovacím systémem. Nebo se rovnou píše API pro JS frontendy.

To přece záleží na použití - jestli děláš kompletní dynamický web, nebo do jinak plně statických stránek chceš přidat jeden formulář a zobrazení kdo má dneska svátek…

Ruby ma `<% ... %>` a `<%= ... %>` v ramci erb, predpokladam, ze python bude mit neco podobneho?

S budoucností JavaScriptu bych si nebyl tak jistý, už jsi slyšel o WebAssembly? http://webassembly.org/

Mě se osobně líbí myšlenka frontendu který se napíše v nějakém vyšším jazyce a pak zkompiluje do javascriptu. Např Vaadin pro javu

Transcompilery nikdy díru do světa neudělaly a že už jich bylo. Jsou neefektivní a kód co z nich leze bývá dost divoký. Kompilovat do něčeho jako bytecode je pro strojové zpracování mnohem výhodnější.

Vyšší jazyk než co? Než JS těžko. Co tím získáte? Obfuskovaný kód, který nebude rychlejší.

webassembly nic neřeší. Náročné jsou DOM manipulace a vykreslování. Výkon javascriptu jako jazyka dostačuje.

WebAssembly umožňuje psát frontend aplikace v prohlížeči prakticky v jakémkoliv jazyce, dle vkusu kazdeho soudruha, s násobně vyšším výkonem, než má JavaScript.

Jsi trochu zaspal dobu, web apps byly hlavní trend tak kolem 2000, teď to jsou mobilní aplikace. Firmy a často startupy se vůbec s webovou apkou neserou a udělají jen ve wordpressu odkaz na svoje mobilní apky, takže vývoje je backend v java, python, ccko, c# whatever a na to si přes nějaké rest api napojí svoje mobilní apky. A ty dělají nativní, ptž ty, co se zkoušely dělat v js nejsou uživateli přijímány dobře. Takže nikdo nehledá js programátora pro mobily, ale hledají se lidi se znalostí Andoidu a iOS nativního vývoje. To je dnešní trend, tak se prober. A v korporátu je taky trend držet win desktopy a na nich nativní apky, je to podobné, jak s těmi mobily. Zrovna nedávno jsme vyhazovali u jednoho korpu v top500 web apku namísto desktopu + k tomu napsané mobilní apps. Jediné, co se ještě zvažuje je lightweight web klient, minimum js a rychle rendrovaný, především jsou věci na reporting a rychlé zpracování dat pro koncáky. Právě proto, jak je js rozežraný a systémově neefektivní a nikdo z těch korporátů nechce každé 2 roky upgradovat kompy kvůli tomu, že web vývojáři jsou prasata a cpou js všude možně a uživatelé pak čekají několik minut, než jim to prohlížeč přelouská. O to nikdo nestojí, proto vládnou nativní mobilní apps, rychlé, max. funkčnost, možnost max optimalizace, která u js nikdy nebude, ptž poběží vždy v nějakém tom silně okleštěném sandboxu. A hlavně tenhle trend je vidět v reálu, nejsou to kecy v kleci nějakého js fanatika.

V korporátu většina CPU náročných procesů běží na backendu a ne na frontendu. Na frontendu už vám stačí pouze něco zobrazit nebo sesbírat vstupy.

Prohlížeč (Chrome) je teď na frontend skoro stejně dobrá platforma jako .NET nebo Java. Její mínusy jsou vyvážené jejíma featurama jako je snadný deployment.

To že je taková spousta JS aplikací pomalá není kvůli platformě ale pouze neschopností programátorů. Dobrý programátor napíše dobrou aplikaci v JS i nativní.

Většina korporátů přechází z .NET a Java desktopových appek na HTML. Můj tým také. A světe div se, ono to funguje líp než predchozí .NET verze. Ovšem transpilujeme z Kotlinu, JS je nepoužitelný pro větší projekty.

"Nejpopulárnější v tomto případě znamená nejlepší,"

Aha, takže pro vás platí rovnice popularita = kvalita

"Úspěch ideologie je určen počtem a oddaností stoupenců"

Ale my se zde nebavíme o úspěšnosti, nýbrž o kvalitě. Nikdo soudný zde nebude popírat úspěch JavaScriptu. To co tu ale dost lidí nadzvedlo je to vaše "Nejlepší jazyk." On si termín "nejlepší" typicky asociují s "kvalitou" dané věci, přičemž kvalitu si lidé vyhodnocují podle vlastních kritérií.
To že vaším jediným měřítkem kvality je rozšířenost už je váš problém.

Pokud byst chtěl nějak OBJEKTIVNĚ vyhodnotit kvalitu, tak byste tedy musel měřit spokojenost lidí co danou technologii používají - a s tím byste u JavaScriptu myslím dost narazil (viz. příspěvky zde v diskuzi).

Ty si chybne davas rovnici kvalita = nejlepsi.

@eee

Ale termín "nejlepší" když stojí sám o sobě nutně zahrnuje kvalitu. Nebo vy byste souhlasil např. s tvrzením "Nejlepší bydlení je v paneláku" ???

Když si ale změníme definici "nejlepšího" na co nejvyšší poměr cena/kvalita nebo na dostupnost, tak tvrzení "Nejlepší bydlení je v paneláku" už dává smysl - vše tedy záleží na tom, v jaké doméně dané tvrzení vyhodnocujete.
mmm vyhodnocuje "nejlepší" podle toho co používá nejvíce lidí a pak s tím tady naráží. Kdyby původně napsal, že jde o NEJROZŠÍŘENĚJŠÍ jazyk, jeho tvrzení by mělo smysl a nikdo by proti tomu nemohl nic namítat - a to ani ten největší odpůrce JavaScriptu.

Fakt nechápu jak je možný, že bandě ajťáků tady na Rootu dělá problém logika a význam slov.

Já bych rozhodně s tím tvrzením o paneláku bez výhrad souhlasil. Uznávám, že to může být věc vkusu a někdo by mohl z nějakého divného důvodu preferovat dům.

Třeba kvůli tomu, že má málo problému a když se něco pokazí (zatékající střecha, pokažený boiler a ucpaný odpad) tak je to jeho problém a musí to řešit, což ho vzrušuje. Nebo kvůli mizernému internetu, díky kterému se může vymlouvat na pozdě odevzdanou práci. Nebo možná láká více než dvojnásobná pravděpodobnost vykradení? Nebo je rád otrokem. Otrokem zahrady, kterou musí sekat atd. Kdo ví.

Taký nechapu, proc ti dela problem vyznam slov. Nejlepší nemá s kvalitní nic společného, ani významově ani logicky. A ještě pívažuješ za mouly ty kteří to na rozdíl od tebe chápou a nezaměňují.

Snažím se maximálně používat primární suroviny a nekupovat polotovary, párky, salámy, vyhýbám se fastfoodům... Mám zahradu a rodinu co má slepice, králíky, nutrie, známé řezníky, pěstitele ovoce a zeleniny... Vím že to není stoprocentní, ale čočkovou vařím z čočky a ne z h*ven. Takže asi tak.

Ked myslite ...

mono, rofl

takze pisete vzdycky 2 verze, Jednu pro p2 a druhou pro p3. A az udelaji p4 tak dalsi verzi. To je skutecne senzacni.

Jeste pro vasi informaci. To EXE, ktere bylo napsano v C a prelozeno uz ten c-prekladac na zadnem jinem pocitaci nepotrbuje. Tam uz je to na rozdil od toho vaseho preferovaneho udelatka prelozene :-)

Pro tvou informaci, to exe nespustis ani v linuxu ani na androidu.

tak ja jsem me programy vytvorene v SCO-Unixu pod linuxem vesele spoustel. (iBCS). Ale jo, to je davna minulost.

Pan Stehule hovoril o systemovych utilitach a proc ma pravdu je videt na 'yumu' , ktery je v RHEL zavisly na urcite verzi pythonu a to je prave ta debilita, Systemovy tool musi byt zavisly jen na sobe a ne na rade jinych komponent , zvlast kdyz takova systemova komponenta je urcena pro pohodlnou vymenu sebe sama :-) Jak na tohle ti pitomci v RedHatu prisli mi fakt hlava nebere.

Zkuste si nainstalovat pomoci yumu nove django na centos 6. :-)

Asi si nikdy nepisal nic vacsie v pythone a len pocuvas reci okolo toho, lebo by si vedel ze sa da pisat "kompatibline" ale niesom blazon a pisem vsetko pre p3, lebo p2 dnes uz nema zmysel, a to asi tak ako dnes pisat pre C ,-)

btw, pises C kod v standarde ANSI, C99 alebo C11?

No flame,ale jak napisu treba v pythonu kernel modul?
Srovnavat C s pythonem je mimo,oba jazyky jsou fajn,ale prunik jejich use cases je temer nulovy

Stejne jako v C naskriptujes webovou stranku.

Ano, v C jde naskriptovat webová stránka. A hřebík jde zatlouct šroubovákem.

Ani jedno nejde, klidne si to zkus. A o tom to prave je. Je hloupost posuzovat nastroje na zaklade ukolu, pro ktere nejsou urceny.

Dynamickou webovou stránku v C jsem už dělal. Omlouvám se, nevěděl jsem, že to nejde...

To jsi mohl delat, ale o tom rec nebyla. Ty ani nevis co to znamena a pletes si to s jinou cinnosti :-). A myslim ze takhle to ma vetsina lidi, ktera se o necem zavedenem vyjadruje s despektem. Nema znalosti ani zkusenosti, jen predsudky a nevi o cem je rec .

Dělal nebo skriptoval? Jestli skriptoval, pak C je skriptovací jazyk. V diskusích se člověk dozvídá stále něco nového.

Povedzte Kefalín, čo vy si predstavujete pod takým slovom skript? https://root.cern.ch/cint

Není poznat koho se ptáš, a tím rádoby vtipným oslovením jsi to nevylepšil.

Obecně je skript interpretovaný program. U webových dynamických stránek je tímto interpretem webový prohlížeč. Takže stále setrváváme v pozici, že někteří diskutující ani netuší o čem je řeč, ale rozhodně se proti tomu vymezují :-). Kdo si myslí, že existuje univerzální programovací jazyk na všchno, jednoduše nemá dostatečný rozhled.

dynamická stránka může znamenat i stránka generovaná na serveru.

Ta může být vytvořena dynamicky, ale sama o sobě je statická. Dynamické chování stránky zajišťuje JavaScript a je v tom Céčkem nenahraditelný. Tak moc jednoduché to je a stejně to tady evidentně spousta lidí nechápe a je zmatená, byť má potřebu se proti JS vymezovat.

Existuje emscripten.

Jde to, ale je to hloupost, dělat weby v C může jen pošahaný hipster.

eee, co takhle si nejdřív ujasnit rozdíl mezi server-side a client-side dynamickou webovou stránkou, než nás tady začneš obšťastňovat svými moudry? https://en.m.wikipedia.org/wiki/Dynamic_web_page

Bavili jste se o pythonu a když se řekne "naskriptujes webovou stranku", tak si většina lidí představí server side script.

To si právě představí menšina bez rozhledu, která vidí jen to svoje. Python je považován za programovací jazyk a v jeho kontextu se programuje, vytvářejí ucelené programy. Když se mluví o skriptování webových stránek, většině lidí je zřejmé, že jde o jejich oživení javascriptem. Skriptují se aplikace, případně případně příkazový řádek. A promouly dodávám, že skriptovat aplikaci neznamená ji vytvářet, ale skriptem ovládat. Tak jak to js dělá ve webovém prohlížeči. Normálnímu it vzdělanému člověku by měl být jasný rozdíl mezi programováním a skriptováním aplikace.

To je právě ono, podobné diskuze o nej jazyku mě vždy dostávají, jazyk se má vybírat podle use case a ne podle toho co má programátor rád. Takže souhlas.
Každý jazyk má něco do sebe a každý vznikl pro nějakou oblast, protože pokud by existoval dokonalý programovací jazyk tak by nevznikaly další a další.

celkem souhlas az na:

- kod ktory vytvorim v C++pre embedded a po dodrzani urcitych pravidiel je rovnako ak nie lepsie optimalny ako podobny kod ktory mi vypadne z C

toto by chtelo dolozit prikladem. Asi mas na mysli, ze vysledny strojak bude rychlejsi nebo zabere min mista (jen se ujistuji co je mysleno tim "lepsie optimalny", protoze "optimalni" je uz samo o sobe absolutni meritko :)

Slovné spojenie "lepšie optimálny" neexistuje. Slovo "optimus" je tretí stupeň od "bonus". Čiže "lepšie optimálny" znamená niečo ako "lepšie najlepší", čo je blbosť.

To je odpoved lineho C++ programatora, ktery se nechce naucit pouzivat C a pouziva ho jako C++. To jest neumi v nem napsat citelny kod a neumi myslet jinak nez objektove. Tuto svou neschopnost pak vydava za nschopnost jazyka, ktery neovlada.

to jdes proti proudu: https://www.tiobe.com/tiobe-index/, cituji jen uvod (protoze se ta stranka do tydne zmeni):

"The programming languages Kotlin and C seem to be the only candidates to become programming language of the year 2017. TIOBE will announce the winner of this award next month. Thanks to the boost of small software devices and the increase of low level software in the automotive industry, the C programming language gained a lot of popularity in 2017."

C++ si udelalo spatnou povest a i kdyz C++11 (14) uslo velmi dlouhou cestu dopredu, tak "klasicke" C++ byl velkej humac (hlavne, kdyz se pouzivalo jen jako C s tridami, coz bylo v embedded nutnost)

Ano, je to bohuzial tak, ale dovod preco C v embedded svete vedie osobne vidim inde.

Pracujem v danom odvetvi uz celkom dlho a mam trosku predstavu ako to je (aspon u nas vo firme). Jednak najst embedded vyvojara je stale celkom narocne, pretoze vela SW vyvojarov netusi takmer nic o elektronike a embedded vyvojar by sa mal v tom orientovat (aspon vediet citat schemu, pochopit periferie z datasheetov a dokazat si pripojit osciloskop alebo logicky analyzer). a za tych co sa k nam dostanu sme niekedy radi ze vedia aspon C. Druhy problem je ze aj ked vo firme je vela vyvojarov ktori C++ ovladaju tak su donuteni (ci uz z projektovo-historickych dovodov, alebo inych napriklad politickych) programovat prave v C-cku.

Nadruhu stranu casy sa menia a vela mladych vyvojarov uz s C++ ma skusenosti a ma aj motivaciu v tom vyvijat a musim povedat ze nove projekty sa coraz castejsie pisu prave v C++. Tak hadam o rok bude C++ niekde inde v embedded svete.

Osobne pracujem na novych projektoch kde sme zacinali prakticky na zelenej luke a nebol problem C++ presadit a som zato rad.

(mam na mysli minimalne C++11)

v podstate souhlas, diky za doplneni. Jen me napada - delate ty nove embedded aplikace s nejakymi vykonnejsimi cipy typu H8SX, H8/300H, ARM, TriCore, nebo i s mensimi cipy (MSP 430 nebo dokonce osmibity)?

U nas se to lamalo nekde u MSP 430: mensi cipy jen C (C++ melo mnohem vetsi runtime, neslo PRAKTICKY pouzit nic slozitejsiho typu vyjimky apod.), vetsi cipy klidne C++. Mozna mozna v budoucnu zkusime i Rust, ale zatim to nema tak dobry tooling.

Starsie projekty: MSP430: +/-32KB/2KB flash/ram (IAR - C++99 - ale chybali mi nejake veci z 11)

Aktualne ARM: od malinkych M0 16KB/2KB az po velke M4 s 1MB/320KB flash/ram (GCC C++11 alebo 14)

Vsade s vypnutymi vynimkami a rtti, new a delete len nad lokalnym pool-om, ziadne std (lebo to vyuziva vynimky) ale mame vlastne zjednodusene/usite implementacie zakladnych funkcii ... u tych najvacsih procakoch mame nejaku newlib, to prida tak cca 80-150KB kodu ale potom mozem pouzivat cokolkvek z C++ vratane std a boost.

Ale vynimky a RTTI, heap, ale aj thready a podobne su v embedded cesta do pekla a navyse to ma obrovsku reziu lebo v mnohych projektoch riesime prakticky kazdu mikrosekundu.

Osobne nevidim dovod zlomu medzi mensimi a vacsimi procesormi.
Minimalny program "hello blinky" v C++ pre M0 zabera menej nez 200B pri -O1 a z toho je vacsina kodu NMI handlery a startup kod. (samozrejme vypnute vynimky, rtti, ...)

Jinak přirozeně vycházím z odkázaných statistik.

Okej, asi jsem se překoukl. Nejspíš jsem vycházel z
Most Popular Technologies -> Programming Languages -> % of Professional Developers
Má to být "java je jen o chlup používanější než C#" (abych tak zdůraznil kontrast s výsledky "naší" ankety.)

A, už vím, kam jsem koukal:
https://insights.stackoverflow.com/survey/2017#technology-most-popular-languages-by-occupation

Spíš to vidím na ocenění
"Píše příspěvky a kouká při tom do úplně jinejch dat, než do kterejch si myslí, že kouká."