Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Jsi hodný, ale já nepotřebuju vědět všechno....Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
Potřebuješ, abych ti to vysvětlil nějako podrobněji? Neboj se zeptat.
...Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.
OOP je o umístění stavu do objektu a o polymorfismu.
To nestačí. Kit to píše dobře. Myšlenkou OOP je, že stavy bez popisu svých změn a změny bez stavů nemají smysl, neboli jsou neoddělitelné.To co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.
type Person = Person String String Int
getName (Person x _ _) = x
getSurname (Person _ x _) = x
getAge (Person _ _ x) = x
getFullname p = getName p .. " " .. getSurname p .. " (" .. getAge p .. ")"
parsePerson :: String -> Person
parsePerson s = ......
Uvazujes tak, ze uz vis presne, co s temi prichozimi daty chces udelat. Tj. ziskat jmeno, cislo, pripadne hodit error, kdyz se to nepovede.Supr. Tak jsme se s velkou parádou dostaly k bodu dva, o tom, že bez typů se lépe prototypuje. To je všechno?
Ale aby sis moh s temi prichozimi daty hrat a prozkoumavat je, musis je bud plne otypovat nebo pouzit dynamicky typovani. Zjistili jsme ze plne typovat ty jsony nechces, dynamicky typovat je taky nechces, tak mi z toho vyplyva opet, ze potrebujes presny zadani, jinak odmitas pracovat.
To reprezentuje tu sortu programatoru, ktery se nehnou z mista, dokud nemaji precizne zpracovany zadani. S preciznim zadanim je pak suna fuk jestli pouzijes python nebo haskell, protoze jsi dostal definici vstupu a vystupu, tak z toho akorat napises funkci.
Programivani je ale casto o prozkoumavani moznych reseni. A proto v nejistych podminkach dynamicky jazyky vzdy zvitezily.
Zajímavější je třeba deserializace z disku nebo sítě.V čem je to jiné? Taky dostanu proud dat, defakto string, defakto zase musím použít Maybe.
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. Typy dělají jakoby "cestičky". Prostě mám vstup od uživatele (co může být více nespolehlivé). A vím, typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.Zajímalo by mě pár kousků těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
Tohle jasná výhoda je. A našel bys jich víc. Jestli převažují nevýhody, to ať si každý soudruh posoudí sám
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.PHP, google-closure-compiler, Flow, TypeScript.
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.Však jo. Já jenom, že ty tvoje hejty platí i pro statické, jenom v menší míře.
Bohužel. Někde jsem to četl. A klidně to může být kec, nestojí mi na tom můj světonázor :-)1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).
1. Několikrát opakuješ obrat "nemá typy". To je minimálně zavádějící. Dynamické jazyky mají typy. Od staticky typovaných se liší jenom tím, jestli informaci o typu znáš (pozitivně, s jistotou) při překladu, nebo až v době běhu. V principu provádíš tu stejnou kontrolu, jenom jindy. Výhoda statických jazyků je v tom, že kontrolu provedeš (ve většině případů - viz 2) jenom jednou, zatímco u dynamického ji musíš provádět pořád dokola, za běhu.Snažil jsem se bavit o statickém typování, nikoliv o staticky typovaných jazycích. A pro mě podstatný rozdíl je právě a hlavně v tom, že jsem schopen ten kód zkontrolovat při překladu. Jak píšeš. To, že při dynamickém typování ty výrazy si nesou typy, to jsem (doufám) nikde nerozporoval. Každopádně to nepovažuji za výhodu, ale za znouzecnost. Ale někteří tvrdí, že by to měla být výhoda.
2. Z bodu 1 přímo vyplývá, že statický jazyk má problém v situacích, kdy typ v době překladu z principu nemůžeš znát - to je ten příklad s načítáním JSONu, ale můžeš jich vymyslet bambilion jiných. Můžeš to řešit dvěma způsoby (možná i jinak, ale teď mě jiná možnost nenapadá):Uváděl jsem příklad jakéhosi kódu s JSONem. IMHO pro staticky typovaný jazyk to není problém. Dokonce bych se troufal tvrdit, že je na to šikovnější.
A) buď máš k dispozici algebraické typy a (v době překladu neznámý) typ prohlásíš za nějakou nadmnožinu různých typů, v extrémním případě všech myslitelných a dál pracuješ s tímhle nadtypem
B) nebo typ zjistíš za běhu (dynamické typování!) a program podle typu větvíš, takže i v době překladu víš, že do určité větve ti jde už jenom určitý typ
3. Někde jsi řekl, že do dynamických jazyků nejdou typy (při překladu) dodat. To není pravda. Stejně jako se u statického jazyka občas musíš uchýlit k dynamickému typování, můžeš u dynamického jazyka otypovat ty části programu, kde v době překladu víš, co tam bude za typ. A můžeš to i kontrolovat, úplně stejně jako u statického (viz např. u Erlangu Dializer). Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.Myslím, že to jsem nebyl já.
Prostě, ty dva přístupy se vzájemně nevylučují. Je třeba si jenom uvědomit, že u některých částí programu víš předem, s jakými daty může pracovat, u jiných částí to nevíš (ani u jednoho typu jazyka). Ty části můžou být různě velké.Já vím.
Na druhou stranu s tebou docela souhlasím v tom, že udržovat tu část, kde typy znáš, co největší (a tím se vyvarovat runtime chybám) je docela dobrý přístup. Ale i kdyby ses na hlavu postavil, nemůžeš mít takových 100% programu. Někde prostě z principu věci dostaneš data, jejichž typ v době překladu neznáš.Otázka narážela na tvrzení, že dynamické typování má nějaké nesporné výhody. To, že mám blbej jazyk, který to neumí, nepovažuji za výhodu. To, že typy neumím, také nepovažuji za výhodu (i když...).
Např. pokud víš, že ve výrazu x / y je y s jistotou "integer", je ti to víceméně na nic, protože situace, kdy je y nula má stejné důsledky jako kdyby to byl string. Dělení nulou je stejně nedefinované jako dělení stringem. Takže kdykoli se ti v programu objeví dělení (nebo jakákoli jiná parciální funkce), stane se ti ze statického jazyka efektivně dynamický - protože prostě v době překladu nejsi schopný ověřit korektnost.S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.
Je možné, že výraz refactoring jsem nepoužil podle příručky.2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.
Tohle mi prijde zvlastni. refactoring chapu jako "cisteni" kodu v pripade, ze uz funguje spravne tzn. beze zmeny funkcionality... Abych mohl delat refactoring "bezpecne" potrebuju mit uz v ruce nejaky kontrolni mechanizmus (testy nebo typovou kontrolu), abych mohl po vycisteni prokazat, zachovani funcionality.
Takze, kdyz budu delat nejaky proof of concept tak muzu bez testu a bez typu, ale rozhodne to pak nebudu refactorovat do nejake produkcni verze, protoze bych se osypal.
function assetContactForm(form, name, age, email, content)
{
form['name'].value = name
form['age'].value = age
form['email'].value = email
form['content'].value = content
return form
}
Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.Mam dva objekty. Chci ziskat 'name'.
V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
Pseudokód, rozepsáno (pro laiky):Kód: [Vybrat]s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
Just x -> x
Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:Kód: [Vybrat]s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.
{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}
K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.
Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).Nevypadal.
Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.
Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.
Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.