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.


Příspěvky - Filip Jirsák

Stran: 1 ... 198 199 [200] 201 202 ... 375
2986
Vývoj / Re:Typový system versus unittesty
« kdy: 20. 08. 2018, 11:51:42 »
Kdyz bude mit funkce na vstupu iterator misto kolekce tak ten implementacni detail je tak trochu vynuceny v tom API, nemyslis?
Jenže se implementace tím API zbytečně omezuje a nemusí být optimální.

Mam pocit, ze tohle uz taky neni tak uplne o unit testech, teda pokud nemam takovy test napsany na (skoro) kazdou funkci v cele aplikaci. Neco podobneho resil kolega tusim pomoci AOP a myslim, ze slo spis o performance testy nez o unit testy.
Je to pořád jednotkový test, nebo možná funkční test. Neřeší se výkon, ale to, že ta aplikace je za určité situace nepoužitelná nebo padá na chybu.

2987
Vývoj / Re:Typový system versus unittesty
« kdy: 20. 08. 2018, 10:45:46 »
Jakoze abych mel kompletni API tak potrebuju osetrit pripad ze mi kozel sezere procesor?
Víceméně. V tomhle případě to asi bude zbytečné řešit, protože bez procesoru nebude na čem ten kód spouštět. Ale jinak je to přesně ono – co všechno se má ještě zahrnout do definice API. Je jasné, že substr bude všichni volat s nezáporným indexem, a nebo je potřeba nadefinovat i to, jak se má chovat, když někdo použije záporný index? A co když ho někdo zavolá s délkou větší, než je dostupná délka řetězce? A co když někdo závisí i na tom, jak dlouho ta funkce trvá? Jsou to všechno stále méně a méně pravděpodobné věci. Ale to je přesně to, na co si BoneFlute na začátku stěžoval, že testy se píší jenom na ty pravděpodobnější chyby a méně pravděpodobné chyby se ignorují – do té doby, než se ukáže, že je to pravděpodobnější, než si někdo myslel. BoneFlute řešil, jak podchytit všechny případy – tedy i ty málo pravděpodobné, jako že kozel sežere procesor.

Efektivita scitani snad bude stejna pri obou smerech iterace.
Efektivita sčítání ano. Ale stejná nemusí být efektivita procházení kolekce. Procházení jednosměrného spojového seznamu „proti srsti“ bude obvykle mnohem nákladnější, než procházení po směru.

A optimalni zpusob iterace by mel prave spis zaridit ten iterator nez funkce co ho bude pouzivat. Protoze kdyz budu mit 1000 funkci iterujicich stejnou kolekci tak optimalizace bude potreba na 1000 mistech. S iteratorem jen na jednom...
Jenže to, že budete pro sčítání prvků iterovat přes jednotlivé prvky, je implementační detail. Ta sumace může být implementovaná i jinak.

Tak kdy se teda ty testy budou na te skolakove 486 poustet?
Když se s tím bude počítat předem jako s prostředím, kde je potřeba to testovat, bude se to tam spouštět třeba v rámci buildu. Když se takový požadavek objeví až dodatečně, spustí se ty testy tehdy, až se ten požadavek objeví – a díky testům bude snazší zjistit, jestli to na té 486 bude fungovat a co případně opravit. S dokonalým typovým systémem byste tu 486 musel řešit, i když by nikdo neočekával, že se ta aplikace na 486 někdy bude spouštět.

2988
Vývoj / Re:Typový system versus unittesty
« kdy: 20. 08. 2018, 09:11:32 »
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
Nikoli, je to proto, že to nejde. Abyste popsal opravdu vše, musel byste v důsledku popsat celý vesmír.

BoneFluteovi se chce.
Ne, jemu se chce jenom teoretizovat. Kdyby se mu chtělo to opravdu popisovat, nemusí čekat na žádný formální jazyk a může začít tím, že funkci přesně naspecifikuje v jazyce českém.

Kdyz se zamyslim nad tim prikladem se sumaci tak mi prijde, ze to neni idealni. Tim rikam, ze bude ta funkce pracovat jen s nejakou linearni kolekci a dost se tim omezuji.
Je to příklad, který můžete potkat v praxi. Byl by celkem k ničemu dokonalý typový systém, ve kterém by se daly psát jen ideální programy, ale reálné programy nikoli.

Kdyby byl na vstupu misto toho iterator tak dosahnu vetsi znovupouzitelnosti. A jen tak mimochoddem ziskam to, ze smer iterace bude dany tim iteratorem a ne zakodovany v implementaci te sumy.
A nebo taky ne. Iterátor definuje pořadí, sečíst můžete ale i prvky, které žádné pořadí nemají. A může být výhodnější prvky sčítat jinak, než v pořadí určeném iterátorem. Navíc to, že směr iterace bude daný iterátorem, je nevýhoda – ty dva příklady se lišily tím, že v některých případech mohl být jeden přístup efektivnější než druhý, o čemž by měl vědět autor implementace té sumační funkce, ale vůbec to nemá zajímat jejího uživatele. To je právě součást API – že schovává implementační detaily.

By me zajimalo jestli v Turbo pascalu sli vubec napsat hodiny, nebo treba stopky...
Šly.

Takze az napisu tu hru a budu ji prodavat skolakum tak je slusne poprosim, aby mi na svem stroji napred pustili testy z diskety 2?
Chápete rozdíl mezi „prevencí“ a „až po té, co k chybě došlo“?

2989
Vývoj / Re:Typový system versus unittesty
« kdy: 20. 08. 2018, 07:36:20 »
A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.

Obávám se, že to není nijak podstatné.

Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:

function substr(String str, Int start, Int len) : String

A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.

Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.

Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.

Že API a implementace jsou dva oddělené světy jsem uváděl na tom příkladu se sumací, který raději ignorujete. Mimochodem, je to uváděné jako základní vlastnost API, že odstíní uživatele od konkrétní implementace, takže implementace se může měnit, aniž by se o tom uživatel dozvěděl. Znáte třeba POSIX?

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Nechcete doufám tvrdit, že stejný kód poběží stejně rychle na 386 a na dnešních výkonných procesorech? Že poběží stejně rychle na Raspberry Pi, na chytrém telefonu i na pracovní stanici?

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie.
Říká vám něco pojem „výpočetní složitost“? Vážně si myslíte, že když budete mít v poli o milionu čísel najít největší hodnotu, nebo ho setřídit, nebude doba trvání té funkce záviset mimo jiné na rychlosti procesoru?

Jen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.

Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.
Jak přeložit pod 486? Vy jí máte k dispozici? A máte k dispozici i budoucí procesory? Navíc rychlost té funkce by přece musela být zakódovaná v tom typu.

Testy se tohle řeší snadno. Napíše se test, který bude měřit dobu běhu té funkce a zkontroluje, že je v daném rozmezí. Že ten test odhalí chybu, až když ho spustím na příslušném zařízení? Ano, to je vlastností testů, že nejsou prevencí chyb, ale umožňují chyby rychle nalézat po té, co k chybě došlo. Že testy nepokrývají všechny případy? Ano, i to je vlastností testů, a to umožňuje, aby se testy vůbec v reálném světě používaly. Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.

Aby ten váš dokonalý typový systém opravdu předcházel všem chybám, jak si představujete, musel by do typu nakonec zakódovat celý vesmír. Vy považujete za nedokonalost testů, že nepokrývají vše. To ale není nedokonalost testů, to je „nedokonalost“, která je v samotných základech programování, a dokonce i v základech jakéhokoli modelování nebo abstraktního popisu světa, který dělá např. věda. A tahle „nedokonalost“ způsobuje, že vůbec něco jako programování nebo věda může existovat. Bez toho ořezávání nepodstatných informací by to totiž nebyl model ale reálný svět. A že občas ořízneme i informaci, která ve skutečnosti je podstatná? Ano, to se stává, jsme jen omylní lidé. Proto máme různé způsoby, jak na takové chyby přijít. Ale řešením není snažit se tam nacpat co nejvíc jakýchkoli informací, protože to byste nikdy neskončil.

2990
Vývoj / Re:Typový system versus unittesty
« kdy: 19. 08. 2018, 20:24:11 »
A muzes teda uvest priklad zavazku, ktery formalne vyjadrit nelze?
Třeba spousta her napsaných v Turbo Pascalu měla na novějších platformách potíže s rychlostí – byly příliš rychlé a nedaly se hrát. Protože rychlost závisela na něčem, co záviselo na rychlosti procesoru. Takže tam by ten závazek zněl nějak jako „časovač musí běžet tak rychle, aby normální lidé mohli tu hru hrát“. Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

2991
Vývoj / Re:Typový system versus unittesty
« kdy: 19. 08. 2018, 18:00:29 »
Podle toho co sem si tam precetl tak API je velice nevhodny termin pro to co tim tady nazyvame.
Tam se mluvi o systemech a aplikacich. My resime jednotlive funkce (aspon doufam).

Mozna pro nas ucel je lepsi pouzivat slovo podpis?
API má obvykle více funkcí, my řešíme jednu funkci z toho API. Podpis by podle mne bylo horší slovo, protože podpis evokuje nějakou identitu. A to je právě něco jiného – API znamená, že mám nějaké definované chování, a zbytek chování, který je pro mne nepodstatný, definovaný není. Takže to API pak může být implementováno různými způsoby, různými identitami – všechny musí mít stejné to dohodnuté chování, ale chování, které dohodnuté není, může být libovolné. Třeba jako u té funkce sum, kterou jsem uváděl, by nejspíš bylo dohodnuté, že ta funkce vrací součet všech hodnot v poli. Ve většině případů by ale už asi nebylo dohodnuté, jakým způsobem má ta funkce pole procházet – jestli od začátku do konce, od konce do začátku nebo třeba paralelně. Ale v některých případech může být dohodnuté i tohle. Proto je API věcí dohody, která může být částečně vyjádřena ve zdrojovém kódu (třeba pomocí typů), ale některé závazky API prostě nijak formálně vyjádřit nelze. A proto ani nelze automaticky zjistit, jestli změna implementace změnila nebo nezměnila API.

2992
Nechci do toho moc zabrušovat, ale:
Citace
Zaměstnanecké dílo:
(4) Autorova osobnostní práva k zaměstnaneckému dílu zůstávají nedotčena.

Osobnostní práva:
(1) Autor má právo rozhodnout o zveřejnění svého díla.
(4) Osobnostních práv se autor nemůže vzdát;
to znamená, že autor programu (byť vytvořeného pro zaměstnavatele) může rozhodnout o jeho zveřejnění? Nebo mi něco uchází?

Celý ten odstavec 4 zní:

Citace
Autorova osobnostní práva k zaměstnaneckému dílu zůstávají nedotčena. Vykonává-li zaměstnavatel majetková práva k zaměstnaneckému dílu, má se za to, že autor svolil ke zveřejnění, úpravám, zpracování včetně překladu, spojení s jiným dílem, zařazení do díla souborného, jakož i k tomu, aby uváděl zaměstnanecké dílo na veřejnost pod svým jménem, ledaže je sjednáno jinak.

A zveřejnění díla je definováno v § 4:
Citace
Prvním oprávněným veřejným přednesením, provedením, předvedením, vystavením, vydáním či jiným zpřístupněním veřejnosti je dílo zveřejněno.

Zveřejnění díla tedy neznamená třeba jeho vydání jako freeware nebo jako opensource, ale představení, že vůbec takové dílo existuje. Aby mohl program někdo použít, musel by mít právo vytvářet kopie, které patří mezi majetková práva, a ta nevykonává autor ale zaměstnavatel.

2993
Vývoj / Re:Typový system versus unittesty
« kdy: 19. 08. 2018, 16:42:09 »
To není předpoklad, to je definice API.
Je to Jiraskova definice? Nebo muzes postnout nejaky odkaz?
Klidně můžu postnout odkaz. API. Nebo vám to můžu i rovnou napsat. „API“ je zkratka pro „Application programming interface“. „Interface“ je „rozhraní“, vrstva mezi implementací a volajícím kódem, která zajišťuje jejich částečné oddělení, určitou abstrakci implementace.

2994
Vývoj / Re:async/await v JS
« kdy: 19. 08. 2018, 14:30:49 »
Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.

Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.
Když se ptáte na seznam, měl byste normálně vrátit prázdný seznam. Pokud se ptáte na jeden konkrétní záznam (dle primárního klíče), obecně byste měl vrátit null – ale pokud by ten záznam měl existovat (např. uživatel jde ze seznamu produktů, kde je produkt vypsaný, na detail produktu), dává smysl i vrátit chybu (reject nebo výjimku).

2995
Vývoj / Re:Existuje jazyk, ktery...
« kdy: 19. 08. 2018, 10:11:54 »
No to se teda nespoleha na dynamicky invoke, s nim to nema nic spolecneho, lambda je cukr pro vytvareni anonymni instance (funkcionalniho) interface, ktery se predava jako parametr. Kompilator predela lambdy do normalniho javovoskeho kodu, zadna reflexe tam neni.
invokedynamic není reflexe, je to „nová“ (od Javy 7) instrukce JVM. A pro lambdy se opravdu používá. Viz java.lang.invoke.LambdaMetafactory.

2996
Vývoj / Re:Typový system versus unittesty
« kdy: 19. 08. 2018, 09:22:06 »
A tento jazyk si dokáže ohlídat nekompatabilní změny v implementaci, kdy by implementace změnila chování.
Jenže já tu celou dobu řeším opačný případ. Tedy kompatibilní změnu v implementaci, která z pohledu dohodnutého API chování nemění. Jako příklad jsem uvedl ty dvě různé implementace sumy, které ve většině případů použití implementují stejné API.

Je to zcela stejné jako testy. Změním-li implementaci tak, že se změní chování, musím tomu zohlednit testy. Změním-li v Elmu imlementaci tak, že se změní chování, musím to zohlednit v typech. Pokud změním implementaci tak, že chování bude zachováno, nezmění se API, a nemusím nic měnit. Nehledal bych v tom žádnou složitost.
V komentáři, na který reagujete, jsem uvedl dvě funkce. Tak v tom nehledejte žádnou složitost, nevymlouvejte se a napište je v Elmu ve dvou variantách. Jednou jako funkce s kompatibilním API, které může jejich uživatel vzájemně zaměňovat, a podruhé jako funkce s nekompatibilním API, protože uživatel závisí i na době jejich provedení, která obecně bude různá.

No, na závěr tohoto můžu maximálně doporučit, aby si se na ten Elm mrknul, mohlo by to být pro tebe poučné. Námětem tohoto vlákna nebylo to, někoho tady učit typy, nebo přesvědčovat co všechno se dá pomocí typů udělat, takže já to tady za sebe uzavírám.
Smyslem komentářů v posledních dnech opravdu nebylo naučit vás typy nebo vás přesvědčovat, co se pomocí typů dá a co nedá dělat. Smyslem bylo vysvětlit některým (například vám), že změna v implementaci může a nemusí znamenat změnu API, a že dokonce stejná změna v implementaci pro někoho může a pro jiného nemusí být změnou API.

2997
Vývoj / Re:Typový system versus unittesty
« kdy: 18. 08. 2018, 21:39:53 »
Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.
To není předpoklad, to je definice API.

My uvádíme důkazy (Elm), že to tak není.
Vy pouze uvádíte příklady, kde jazyk neumožňuje definovat žádné API – takže nezbývá, než být API definované někde bokem, v dokumentaci. A na kontrolu toho API opět potřebujete testy.

Samozřejmě je to změna API.
Takže každá změna implementace je změna API. To pak ale není API. A co se týče praktického použití by takový systém byl úplně stejný, jako dynamicky typované jazyky. Protože byste při každé změně implementace automaticky všude změnil typy.

Takhle to ale přeci vůbec není.

Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Zatímco
foo2 x y = x / y
a
foo2 x y = y / x

už mají různé API, protože různou funkčnost.
Nesmysl. Dvě různé implementace, které mají (pro většinu použití) stejnou funkčnost a tedy stejné API vypadají např. takhle:

Kód: [Vybrat]
function sum1(addends) {
  var sum = 0;
  for(var i = addends.length -1; i >= 0; i--) {
    sum += addends[i];
  }
  return sum;
}

function sum2(addends) {
  var sum = 0;
  for(var i = 0; i < addends.length; i++) {
    sum += addends[i];
  }
  return sum;
}

2998
Nejde o to, jestli tě něco omlouvá, ale reálná situace. Ty jsi vymyslel třeba svoji část a úplně stejně bys ji dělal jinde. Tak prostě použiješ ten kód. Podstatné na tom je, že na to přijít nejde. Takže je vůbec otázka, proč bys to psal znovu. Mě to zajímá jen tak ze zajímavosti, protože přijít na to fakt nejde a zároveň je to tvoje práce, kterou si chceš schovat. Úplně normální věc.
Původní otázka nezněla, jestli se na to přijde, ale jestli je to legální. A mimochodem, těch, kteří si byli jistí, že se na to nepřijde, jsou plné věznice.

2999
zaměstnavatel nemá majetková autorská práva, to je podle zákona nemožné (v ČR, v zemích s common law to funguje jinak).

Je to až tak nemožné, že to konkrétně upravuje § 58 Zaměstnanecké dílo.
Citace
(1) Není-li sjednáno jinak, zaměstnavatel vykonává svým jménem a na svůj účet autorova majetková práva k dílu, které autor vytvořil ke splnění svých povinností vyplývajících z pracovněprávního nebo služebního vztahu. Takové dílo je zaměstnaneckým dílem. […]

Asi jste si to popletl s osobnostními autorskými právy, ta jsou nepřenosná. Majetková práva jsou právě oddělena zvlášť, protože ta přenosná jsou.

3000
Vývoj / Re:Typový system versus unittesty
« kdy: 18. 08. 2018, 17:15:09 »
A ja uz se po nekolikate snazim rict, ze to nemusi byt pravda. Kdyz budu mit vhodny typovy system a budu chtit, tak muzu zaridit aby kazda nekompatibilni zmena implementace nutne znamenala zmenu API.
Ano, vy jste už poněkolikáté zaměnil kompatibilitu API a kompatibilitu implementace. Já stále píšu o kompatibilitě API a vy na to pokaždé reagujete kompatibilitou implementace. Ne každá změna implementace znamená změnu API.

To rekne kompilator co je kompatibilni a co je nekompatibilni. To nemuze byt vec nazoru.
Možná to nemůže být věc názoru, ale je to tak. Je změnou API třeba to, jak je funkce rychlá, jak dlouho trvá, než se provede? Třeba u webových stránek se v JavaScriptu hlavně dříve spousta věcí, která měla být asynchronní, řešila voláním setTimeout – daný kód se odložil a zavolal třeba za 100 ms. Nebo i dneska to často lidé používají v init skriptech – „dej tam pauzu minutu, za tu dobu ta závislost určitě naběhne“. Spousta lidí k tomu má přístup „teď mi to funguje, tak je to v pořádku“. No a někde místo explicitní pauzy funguje kód, který se provádí delší dobu. A teď si představte, že někdo takový kód optimalizuje a zrychlí. Ten kód, který závisel na tom, že to trvá určitou dobu, se rozbije.

Je to zrychlení nekompatibilní změna API? I když ta doba trvání nikde nebyla zdokumentovaná, nebyl to účel té funkce a jenom to tak náhodou vyšlo. Dá se na takový případ napsat jednotkový test? Mohl by to typový systém řešit jinak, než že by každá změna implementace znamenala nekompatibilní změnu, a tím pádem by veškerá typovost šla k šípku, protože by nic nezáviselo na typech ale na konkrétních implementacích?

Stran: 1 ... 198 199 [200] 201 202 ... 375