Vývojáři mohou dělat a také dělají chyby při vývoji i v Ada, ale pravděpodobnost takových chyb je mnohem nižší, než při použití jiných programovacích jazyků.
Čím je to podloženo? Můžete například porovnat pravděpodobnost chyb v Adě a Javě (uvažme implementaci, jenž podporuje Real-Time Specification for Java)?
Jak si Ada vede při tvorbě konkurentních programů vůči jazykům jako ParaSail (mj. navržený rovněž Tuckerem Taftem) nebo Rust?
"Tím spíše je otázkou, proč učit Adu?"
na to si musis najit odpoved sam...
chapu, ze spousta lidi zde spise resi takove to "domaci" bastleni...
nicmene se muzes inspirovat treba tady
http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
Težko ověřit, protože to by zabralo opravdu HODNĚ dlouho a pravděpodobně nikdo by na to prostředky a čas nevynaložil. (Myslím tím, komplexní srovnání u programů s více než 100k řádek)
Každopádně, jelikož se ADA používá v letadlech, myslím si, že tvrzení je celkem oprávněno a lidé co vybírali jazyk pro použití v takto kritických systémech měli celkem jasnou představu o chybovosti programů v Adě.
Každopádně, jelikož se ADA používá v letadlech, myslím si, že tvrzení je celkem oprávněno a lidé co vybírali jazyk pro použití v takto kritických systémech měli celkem jasnou představu o chybovosti programů v Adě.
Tam se používá i C a C++ (například MISRA), tudíž si nejsem jist, zda z toho lze něco vyvodit. Navíc tam často jde právě o RT systémy.
Težko ověřit, protože to by zabralo opravdu HODNĚ dlouho a pravděpodobně nikdo by na to prostředky a čas nevynaložil.
Pak tedy nerozumím, proč to autor v článku tvrdí.
Je to sice pruser ale jedna se jen o generatory u motoru - kazdy motor ma 2.
"If the four
main GCUs (associated with the engine mounted generators) were powered up at the same time, after 248 days of continuous power..."
Na leteckem prumyslu je krasne to ze se spoleha na redundanci na vsech urovnich vcetne te lidske,
I kdyby selhaly vsechny ctyri GCU, tak neni problem nahodit APU a vytapet s ni jeste bazen...:)
Na prechod nahleho vypadku staci baterie(ano ty dymajici;) nastesti se to netyka startovacich na APU a pripadu vybijeni;) 787 ma jednak po novu elektricke hydra pumpy na palube, ale take ma tradicni hydra pumpy pres mechanicky nahon v motorech. Takze se jich vypadek generator control unit nedotkne.
Na druhou stranu pokud bude cist pilot dva kilometry dlouhy checklist a odtukavat failed systemy tak ani tech 10 minut v baterkach nemusi stacit... Nekdy se za svuj obor dost stydim. Piloti nas musi mit dost za nezodpovedne <zdrobnelina od slova hlupak> a maji pravdu.
2x225kVa bohate staci. Asi se poleti v low power rezimu, takze vytapeni bazenu a sauna nebude k dispozici a kafe studeny...
Tak je jen otazka casu, kdy piloti z kokpitu zmizi. Ti v Boeingu pilotuji prumerne 7 minut za let, zatimco v Airbusu jen polovinu casu. Jsou drahy a litaj s letadlama do skal kdyz maj depresi :)
K veci - jak muze takova chyba vubec vzniknout? Nepouzivaji se formalni metody jako napr. abstraktni interpretace?
K veci - jak muze takova chyba vubec vzniknout? Nepouzivaji se formalni metody jako napr. abstraktni interpretace?
Formálně ověřit nějakou vlastnost může být docela náročné. Pokud tedy nástroj pro analýzu programu řekne, že něco neumí ověřit, tak se to IMO většinou nechá na lidech.
Navíc může být chyba v HW, chyba v kompilátoru jazyka, chyba v nástroji, co ověřuje vlastnosti programů - málokdy má kompilátor nebo pomocný SW formální důkaz správnosti.
Vše je navíc komplikováno faktem, že jazyky nemají formální specifikace.
Čím je to podloženo?
Silna typova kontrola. Jazyk navrzeny tak aby vyloucil nektere mnoziny chyb: napr.range checking by default; neexistuje dangling else; kontrola kompletnosti u case; detekce aliasingu; [silne omezeny] profil ve kterem je garantovano ze nemuze dojit k deadlocku; od Ady 2012 podpora kontraktu; standardizovana podpora pro distribuovane programovani (komunikace + synchronizace); to jestli task pobezi in-process, out-of-process nebo na jine masine je otazka zmeny konfigurace. Standartni knihovny kontejneru, podpora alokace v oddelenych memory poolech ktere muzou byt volitelne GC (standart GC povoluje, pry snad zadna implementace to by default nepodporuje ale je dostupna minimalne jedna open-source implementace zalozena na BoehmGC). Subset Spark s durazem na jednoznacnost a automatickou verifikovatelnost (samozrejmosti je moznost linkovat dohromady Adu, Spark, C, C++, Fortran a cokoli dalsiho).
Ada byla od zacatku navrzena predevsim pro "bezpecne programovani s ohledem na velke projekty s dlouhym obdobim podpory / v trvalem vyvoji", na ukor komfortu (je strasne "ukecana"). Read-Only jazyk ;-)
ParaSail je zatim work in progress (vypada hodne zajimave), ale pokud se nepletu implicitne pocita s virtualni masinou a GC, zatimco Ada bez ztraty mnoha featur jde pouzit i bez jejiho lehkeho run-timu. Rust je daleko vic high-level nez ADA (ve smyslu fetury, ne run-time naroky ;-) a rekl bych ze poskytne silnejsi garance pro kontrolu dynamickych alokaci. Oba dva "konkurenti" jsou ale zatim prilis mladi.
Ada u leta lita v letadlech (nejvic se vytahujou 707 myslim) a rizenych strelach, sedi na letistich, jezdi s vlacky, nejake uziti v medine a spousta dalsiho. Nejjednodussi je se podivat na to jak se na svych strankach vytahuji vyvojari (napr. AdaCore).
Vic o Ade nez root zvladne vypublikovat za 100 let (pro ty stastne kteri se neboji emerictiny ;-).
http://www.adacore.com/adaanswers/resources
http://www.adaic.org/ a http://www.adaic.org/learn/materials/
http://libre.adacore.com/ (GNAT GPL pokud vase platforma nema Adu ve spravci baliku ;-)
http://en.wikibooks.org/wiki/Ada_Programming
To samosebou něco říká, na druhé straně ale vzniká obrovské množství jazyků a nemálo z nich má podobné cíle. Proto stále pochybuji, že tvrzení
pravděpodobnost takových chyb je mnohem nižší, než při použití jiných programovacích jazyků.
je pravdivé (zvláště, pokud se nebudeme omezovat na jazyky pro RT systémy).
Oba dva "konkurenti" jsou ale zatim prilis mladi.
Souhlas.
v com je to lepsi oproti cecku s dostupnymi nastroji (http://www.astree.ens.fr/)?