Názor k článku
Programovací jazyk C má nejnižší oblíbenost v TIOBE za posledních 15 let od Kiwi - Aj aj! Jen doufám, že nikoho nenapadne do...

Aj aj! Jen doufám, že nikoho nenapadne do C něco podobného v budoucnu matlat.

- přetěžování: v žádném případě! I v jazycích, které to umožňují, je to častý zdroj záludných chyb, na což reagují standardy jako MISRA apod. a přetěžování omezují nebo zakazují používat zcela. Nicméně kdo bez toho nemůže žít, může použít C++.
- silnější typová kontrola: implicitně na to dnes kompilátory reagují varováním, obvykle je možné vynutit i vyšší úroveň varování či použít nástroje typu lint; v tom dnes žádný problém nevidím a opět zde platí, že je možné použít C++, jež má typovou kontrolu přeci jen silnější
- to je tvůj názor, např. já jsem na prefixy zvyklý - pokud to je vůbec kdy nutné; co nechci zveřejňovat, to udělám jako static, rozhraní modulu mohu opatřit prefixem, pokud je to nezbytné. Zavádět namespace jen kvůli tomu, že se mi nelíbí MP_procName() a chci místo toho psát MP::procName() mi připadá jako zbytečnost. Navíc už vidím, jak lidi sypou do namespace i lokální objekty, aniž by jejich lokálnost explicitně zaručovali... Ne, děkuji. Kdo bez toho nemůže žít, viz výše - C++.
- výjimky: Ne! Tohle by bylo na mnohem delší debatu a vysvětlování a asi i flame, ale výjimky jsou ve skutečnosti velmi kontroverzní konstrukce, které dělají z chyby nějaký speciální stav, což není. Navíc z podstaty věci dělají program lenivější, protože se implicitně kontrola udělat musí, i když to není nutné (např. je-li chyba ošetřena ve spodních vrstvách a vyšší se již mohou spolehnout na bezchybnost) - a je to mnohem, mnohem větší zátěž pro rychlost programu, než nepřímý skok, ke kterému by vedlo volání funkcí umístěných do struktur, na které si stěžuješ hned v prvním bodě. V jazyku úrovně C nemají výjimky co dělat! Řešení pro ty, kdo bez toho nemohou žít, v pořadí od nejpřijatelnějšího k nejhoršímu: 1. goto, 2. setjmp, 3. C++
- enum, další z konstrukcí, jejíž smysl je často nesprávně chápán, aneb "problém #define x enum x const int". Výčtový typ je určen k tomu, co napovídá jeho název: k výčtu pro vnitřní potřeby programu. Už použití rovnítka v enumu je nečisté a může být velmi nepřehledné, či nebezpečné (skákání tam a zpátky v rozsazích, do většího enumu stačí přidat hodnotu navíc a zbytek za tím se posune až před první další přiřazení...). Přiřazení by se v enumu vůbec nemělo vyskytovat a když, tak jen u první hodnoty, v dobře a bezpečně navrženém programu by na konkrétní hodnotě výčtových konstant nemělo vůbec záležet. Enum skákající implicitně po mocninách dvou - to už je prasečina na kvadrát, a to doslova. Od toho je #define.
- bitové pole je ze své podstaty nepřenositelná konstrukce, ačkoli uznávám, že by to bylo velmi příjemné; v embedded oblasti to nebývá problém, protože potřebuje-li někdo operovat na této úrovni, pak je velmi silně navázán na konkrétní platformu a na konkrétní překladač a u toho je již takováto věc definována
- pole prvků pod bajt: viz výše, ze své podstaty nepřenositelné a potenciální nesnáz při nedělitelnosti bajtu velikostí položky pole
- částečná inicializace struktur: tady také nevidím důvod, proč to neumožnit; potřeba něčeho takového sice na 90% indikuje bad coding practices, ale to není důvod to zakazovat
- extenze struktur ve stylu Oberonu: za 23 let, co programuji v C, mi to sice nijak zásadně nechybělo, ale myslím, že by to nebyla špatná vlastnost; ovšem i zde by se dalo napsat UTFC++ pro ty, kdož bez toho nemohou dýchat
- pouze externí const: tady mi smysl poněkud uniká; v čem tkví pointa?
- argumenty ohledně lenosti více psát jsou už dávno ve skutečnosti pouze neschopnosti efektivně používat textový editor; tato vlastnost C mně osobně nijak nechybí, ale ničemu by to asi nevadilo; u koho má takováto věc výrazný vliv na jeho produktivitu by se měl vážně zamyslet nad svými coding practices
- množiny: to mi taky nijak zásadně nikdy nechybělo, ono se to ani v tom Pascalu moc neujalo; ničemu by to asi nevadilo, kromě toho, že by to skoro nikdo nepoužíval, což je asi i důvod, proč to v C není