To je dost divně položená otázka. Ale to neplatí jen o programech v reálném čase, ale prakticky o čemkoli - "je lepší OOP nebo něco jiného? Je Assembler rychlejší než C?" atd.
Přece základem je problém, jenž je třeba vyřešit, a dále podmínky, v jakých se má ten problém řešit, tj. HW je třeba dopředu známý a daný (na kosmické sondě miliony km od Země ho těžko někdo vymění), celý program je ve Fortranu a je třeba dopsat dílčí modul - asi nebude příliš prozíravé to kvůli tomu celé přepisovat do něčeho jiného...
Od těch dvou věcí se vše odvíjí, jim je podřízena volba nástrojů, prostředků. Když jsme si jako kluci stavěli z Merkuru plotter/scanner, byla to taky vlastně aplikace v reálném čase a šlo to bez problémů napsat i v dosti pomalém, 8bitovém interpretovaném BASICu.
Přestaňte už se konečně hádat o tom, které paradigma je to posvátné, který vývojový vzor ten nejlepší, jaký programovací jazyk ten všespásný. Nic takového neexistuje! Je třeba mít přehled o všem a na základě zkušeností umět rozhodnout, v kterých situacích, případ od případu, je lepší to a v kterých ono. Už jsem dělal realtime ve Forthu a nedovedu si v daném případě představit, že by stejnou funkci mohlo stejně dobře zastat něco jiného, stejně jako jsem dělal realtime v Assembleru a nedovedu si představit, že by v tomto odlišném případě bylo možné to zvládnout v čemkoli jiném. A dovedu si představit i realtimovou aplikaci, na níž by se dala použít Java. Proč ne?
Ano, je pravda, že na základy a stropy se hodí beton, na zdi cihly a na krovy dřevo, ale to není žádné dogma. Dá se použít i jiná kombinace a existují dokonce případy, kdy to takto doporučeně prostě vůbec nepůjde. Základem je znát vlastnosti a limity těch materiálů a metod a umět zvážit jejich aplikaci. A v programování to platí přeci zrovna tak.
Chce-li se někdo věnovat vývoji na reálný čas, musí v první řadě řešit časové limity, případně přesné časování v rámci toho daného železa. A pak se rozhoduje, v čem to bude dělat - i na základě této předchozí analýzy: celý program je v C++, ale tohle holt s daným překladačem nejde stihnout, tak se zkrátka příslušné úseky napíšou v Assembleru; hodilo by se mi programovat v Lispu, po analýze realtimovosti zjišťuji, že mi v tom nic nebrání => není tedy důvod tento jazyk z důvodů realtimu zavrhovat a za každou cenu tam cpát jiný, protože ten je přece vhodný na realtime (podle předmluv různých tutoriálů a učebnic).
Existují strojáky (resp. železo), kde si člověk nemůže být jistý ani časováním jednotlivých instrukcí. A nad těmito strojáky existují překladače vyšších jazyků, které vám jsou schopny časování garantovat (jinými prostředky, ve spojitosti s dalšími obvody atp.). Universální kuchařka prostě není a to, co v deseti případech fungovalo výborně, může být v jedenáctém naprosto nepoužitelné.