A něco poučného na téma složitosti: http://www.knesl.com/budoucnost-programovacich-jazyku
Ten článek není úplně špatný. Akorát na konci se autor dopustil poměrně zásadní a docela časté chyby. Formuloval závěr na základě jim specifikovaných předpokladů, ale jaksi opomněl, že mu tam další předpoklady chybí.
Vynechal totiž nejdůležitější faktor, ovlivňující prodloužení doby vývoje: programátora. S bandou opic nejnovější funkcionalitu prostě nenaprogramujete, i když budete mít ty nejlepší nástroje. A protože poptávka po programátorech neustále stoupá, tak za současné situace logicky jejich kvalita klesá. A tady narážíme na limitující prvek. Klesající kvalita programátorů (nebo třeba nemožnost získat dostatečně kvalitní programátory) způsobí prodloužení doby implementace v případě použití složitého a vysoce sofistikovaného jazyka. Tak, jak se někdo v matematice zastaví u trigonometrických funkcí, někdo u logaritmů a další u integrálů a derivací, tak se zastaví u různé složitosti konstrukcí programovacích jazyků. A protože se jedná o pyramidu (skoro všichni zvládnou goniometrické funkce, logaritmy už menší skupina a integrály a derivace jen "hrstka"), můžete mít sice dokonalý jazyk, ale jeho zvládnutí vás může stát více času (pokud to vůbec dáte), než to funkčně naprogramovat v něčem primitivnějším.
A to je taky problém celého tohoto vlákna. Zatímco typový systém ekvivalentní unit testům možná dokáže navrhnout autor (a možná ještě další jeden nebo dva), napsat nějaký unit test dokáží víceméně všichni. A po nějakém tréninku velká většina z množiny všichni bude schopna psát kvalitní unit testy. Kolik dalších lidí zvládne Haskell na úrovni, kdy nahradí unit testy správnou volbou typů si netroufnu ani odhadovat.
Souhlasim. Neslo mi o jazyky s dynamickou syntaxi, o jejichz realne prakticnosti mam pochyby, ale uvidime, co prinese budoucnost. Slo mi o fenomen slozitosti, ktery se tu prehlizi a je imho vyznamne podstatnejsi ohledne kvality a spolehlivosti vysledne aplikace. Chci-li vysokou spolehlivost, nevyresim to typovym systemem, ale a) vhodnou metodou vyvoje software, zalozenou na dukladnych testech, viz treba extremni programovani, b) kvalitnim testovacim prostredim a c) zvolenám prostredku, ktere mi rozumne snizi druhotnou slozitost, jenz je vyznamnym zdrojem chyb (proto typicky neprogramujeme ve strojovem kodu nebo asm a proto se vyvoj nezastavil ani u jejich nastupcu C, C++, Java /C# nebo dnes popularni JS a Python, kde Python je nejpokrocilejsi, ale take nejmene vykonny). Ony ty testy take zvysuji druhotnou slozitost, ale maji vyhodu, ze nejsou soucasti produkcni aplikace a nezasahuji do ni, ale to uz se ale opakuji. Typovy system slozitost programu zvysuje a to primo umerne se svou silou. Tedy cim dukladneji resi jeden zdroj chyb, tim posiluje jiny zdroj chyb, druhotnou slozitost. Argument kvality a spolehlivosti je u staticky typu proto falesny. Jejich opodstatneni je jine, v moznosti lepsi optimalizace a vyssiho vykonu aplikace. Ale k tomu neni potreba, hadam, vyssi typovy system, staci k tomu datove typy na urovni architektury.
976 Odpovědí
128199 Zhlédnutí