Když by to bylo tak skvělé, tak proč se to nedělá?
Svět by byl dnes jistě úplně jiný, pokud by se v něm prosazovaly zásadně jen věci, které jsou skvělé.
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)
Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Konkrétní příklad bych vzal mnohem prostší - chceš realizovat jakýsi
print(x), který zajistí vypsání argumentu na terminál. Jaký datový typ
x-u by ta funkce měla podle tebe optimálně očekávat a proč? V čem mi jakožto vývojáři pomůže, že ta funkce očekává ten konkrétní datový typ? Uvažuješ-li o stringu, tak pokračuj v úvaze dál - jak se teda pak vypořádat s ne-stringy. Nebo třeba seznam v Pascalu...
Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?
To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.
Taška na rohlíky je provokace. Jestli nechceš vést vážou diskusi, tak to řekni rovnou :-)
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.
Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).
Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" 
Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů. Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam
čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci. Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli. Vidím to tak, že ve statickém případě bych si musel definovat nějaký typ "zboží", který pojme veškerý sortiment plánovaného nákupu. Jenže proč bych se musel omezovat na cokoli, co třeba je menší než ten Boeing, když ze zadání problému neplyne, že bych nikdy neměl chtít koupit Boeing?
Statické typování mě nutí, abych
dopředu znal nějaké omezení, nebo abych si ho
uměle vytvořil, ačkoli z řešeného problému vůbec neplyne. To první je často nemožné a tedy vede k tomu druhému, což je smrtící. Nejčastějším problémem, se kterým se vývojář ve své pracovní době potýká, není obvykle přímo problém, který má za úkol vyřešit, ale jak se vypořádat s problémy, které si nadělal sám sobě dříve nebo které mu vymysleli jeho předchůdci. Takže jakmile se zákazník zeptá, proč nejde koupit Boeing, co mu na to odpovíš? A jak se budeš tvářit, až po X mandays práce, spočívající v překopávání půlky programu kvůli Boeingu, ti zákazník nezaplatí ani halíř, protože v té původní smlouvě o dílo není nikde napsáno, že by ten program neměl umět nakupovat Boeingy?
1355 Odpovědí
136185 Zhlédnutí