Grazie per il link. Credo di non avere mai riso tanto dalla prima proiezione di "Febbre da cavallo".
Tanto per sottolineare la boiata più colossale: il 97% del mercato dei device embedded propriamente detti è composto unicamente da core con datapath a 4, 8 e 16 bit con al più poche decine di migliaia di locazioni RAM. Nel restante 3% si trovano confinati i 32 bit: prevalentemente DSP e motion controller, più qualche esotico core e SoC per TLC, e poco altro.
Eccetto questi ultimi spiccioli di statistica, praticamente nessun altro dei chip venduti in quantità massive possiede anche solo una frazione delle risorse necessarie ad ospitare un interprete Java o Python, che invece sono ampiamente usati ad esempio sui numerosissimi core ARM (
nessuno dei quali è certificato per usi embedded minimamente critici) presenti in device mobili, appliance di rete, consumer e quant'altro, tutti mercati che semplicemente
non sono embedded. Quanto ad Arduino e C++, ROFLASTC, una risata li seppellirà. Arduino è solo la balia asciutta dei pasticcioni insipienti e degli smanettoni che sanno poco e nulla sia di elettronica che di software, nessun professionista minimamente serio lo prenderebbe in considerazione, senza contare i vincoli normativi.
L'analfabeta embedded neolaureato che usa gpp per compilare qualche accrocco destinato a core ARM non fa assolutamente testo: la breve e tormentata storia del C++ in ambito embedded coincide con quella del comitato SC22/WG21 ed è riassunta integralmente
qui. A fronte di oltre 400 cross-compiler C commerciali (peraltro parzialmente compatibili solo con C89), esistono solo
due crosscompilatori commerciali per EC++ e hanno percentuali d'uso omeopatiche tra gli addetti ai lavori, anche per vincoli normativi.
Appare palese come IEEE ha mescolato inopinatamente le fonti, il sacro col profano, il dilettantesco con l'embedded realtime critico, anche considerando altre barzellette presenti in classifica, vedi ad esempio VB.
Invece è vero che l'ampio uso di linguaggi funzionali, constrained, dichiarativi, algebrici, ibridi... e di formalismi come i BDD, come peraltro ho innumerevoli volte spiegato in passato (ad esempio
recentemente qui), è assolutamente fondamentale in ambito embedded per il supporto alla verifica e specifica formale del software, assieme ad altri strumenti come l'interpretazione astratta, le suite di testing, le environment simulation, la full code coverage e molto, molto altro.
Ogni singola riga di firmware e software embedded, come già genialmente anticipato da Dijkstra, assieme al relativo silicio e hardware in generale, è frutto di un lungo lavoro di derivazione da una specifica formale, e se ne dimostrano altrettanto formalmente e rigorosamente le proprietà su scala locale e globale, grazie appunto all'uso di ambienti e linguaggi dedicati come quelli sopra menzionati e molti altri, in un processo solo parzialmente automatizzabile.