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 - BoneFlute

Stran: 1 [2] 3 4 ... 133
16
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 17. 02. 2023, 18:46:33 »
kdyz mas delku kolekce primo v typu/objektu tak pri kazdem add/delete automaticky upravujes hodnotu delky. jinak si musis udelat (nekonecnou) smycku a delku spocitat.
Takže cheš říct, že když mám:
Kód: [Vybrat]
parseList : String -> [Int]
tak ten kompilátor si nemůže vytvořit paměťovou buňku ve které bude jednak ta kolekce čísel ale i informace o počtu?

17
Vývoj / Re:Převod List<a> na Vect<a,n>
« kdy: 17. 02. 2023, 16:48:59 »
Aby nedošlo k omylu, já to zadání chápu. Jen jsem ho zjednodušil.

Obecně v jazycích se předpokládají kolekce jako nekonečné. Tudíž proč někde uchovávat délku kolekce? Třeba proto, že mám funkce, které dokáží zpracovat jen konkrétní délku - což je můj příspěvek/dotaz. A nebo proto, že mám různé specializované funkce pro různé délky. Tak pak nevím proč to rvát do typu, když se můžu zeptat v nějakém switchi.

K čemu je zajímavé, že je ta délka součástí typu? Jaké to má praktické použití?

18
Vývoj / Re:Vect<a,n>
« kdy: 17. 02. 2023, 16:35:59 »
nejde - Vect<a, n> prostě potřebuje v době překladu vědět, kolik je n, protože Vect<a, 4> má jinou implementaci než Vect<a, 5>. Takže snad jedině přes velikej if podle velikosti Listu.
Ten parametr n nemusí mít známou hodnotu, pokud jde v jazyce mít tento typ:
Kód: [Vybrat]
structure Sigma {α : Type u} (β : α → Type v) where
  fst : α
  snd : β fst
V haskelloidních jazycích to bývá nějak takto:
Kód: [Vybrat]
data DPair : (a : Type) -> (p : a -> Type) -> Type where
   MkDPair : {p : a -> Type} -> (x : a) -> p x -> DPair a p
Pak jde ta funkce napsat tak, aby fungovala za běhu (kdy se ten seznam, a tedy i n, načte například ze souboru nebo je po spuštění programu zadá uživatel).

Jaký to má potom praktický efekt?

Mám funkci:
Kód: [Vybrat]
format x : String
...
format x : Int
...
formatAll xs : [String | Int]
...

loadFromFile File -> Error [String | Int], ErrorState
    ...
   
Načtu ze souboru, a obsah musím převést do konečně známého tvaru. Pokud tam budu posílat boolean, tak zmršit na int. Pokud tam mám Date, tak nevím.

Jak se bude chovat kód, ve kterém formatAll obsahuje kolekci, jejíž signaturu znám až po načtení souboru? Půjde to korektně přeložit? A když to načte bool, nebo Date, co se stane?

19
Studium a uplatnění / Re:Platové ohodnocení PHP
« kdy: 16. 02. 2023, 01:58:49 »
c# tak nějak víc podporuje přehlednost a strukturu kódu.

Bohužel jsem si nevšiml. Já toho prasokódu v C# někdy mám plné zuby. Někdy je to jak PHP před pěti lety. Včetně skillu kolegů.

20
Studium a uplatnění / Re:Platové ohodnocení PHP
« kdy: 15. 02. 2023, 23:53:46 »
zlepšovat ve více žádaných jazycích - od PHP k JS nebo c# není tak daleko

C# bych doporučoval. Náročností je to stejné jako PHP (rozuměj, prakticky v ničem se to neliší, jen trochu v syntaxi), a firmy to z nějakého důvodu rádi používají. Na prachy dobrý.

21
Studium a uplatnění / Re:Zákaz konkurence
« kdy: 12. 02. 2023, 23:09:03 »
že žiadnu finančnú kompenzáciu som za konkurenčnú doložku nedostal

Konkurenční doložka je naopak skvělá věc. Byl by si blbej, když by si ji nebral.

Ono to totiž funguje tak, že pokud s tebou má firma uzavřenou konkurenční doložku, tak po ukončení spolupráce má povinnost ti po dobu trvání té ochrany, platit finanční vyrovnání. Což je super, můžeš jet na rok na placenou dovolenou.

Trochu blbé je, že toto se týká zaměstnaneckého poměru, kde je omezení maximálně na jeden rok a je povinné finanční vyrovnání.
Konkurenční doložka v obchodním zastoupení se jedná o maximálně dva roky, a není tam to finanční vyrovnání. Taky tě ale nesmí zbytečně omezovat. Soud na to nehledí příznivě.

Co je tvůj případ, to nedokážu posoudit.

Moje zkušenost je, že se sice ta doložka uzavře, ale když dá zaměstnanec výpověď (respektive těsně před tím), tak z toho firma vycouvá, páč si uvědomí, že by musela platit.

22
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 17:35:34 »
plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#
No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.
Tak tady přiznávám svou neznalost. Když místo class použiju struct, což by mělo být podle docky hodnotový typ, tak to skutečně nelze vytvořit null. A je to i v naší staré code base. S tím si budu hrát.

Díky Králík!

23
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 16:27:35 »
plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#
No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.


Taky má AFAIK už nějaký pattern matching...
Ano. Nějaký.

24
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 15:39:28 »
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...
Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.
Ten problém není ve výjimkách.

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.

25
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:51:09 »
Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Představuji si nástroj pro Rust, který projede kód a hledá výskyty slov panic().
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...

26
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:45:42 »
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
Slušný vývojář tu výjimku odchytí a vypíše třeba “Sorry vole error”.
To je ale něco jiného, to spadlo, protože nebyla dobře ošetřena chyba, ne proto, že by byl porušen invariant.

To samé se stane v Rustu, pokud udělám `.unwrap()` na výsledku toho konstruktoru anebo v Haskellu, pokud bys např. v Either Left větvi udělal `error "shit's on fire yo"` ...
Ano, je to něco jiného. To je rozdíl mezi Idrisem a C#.

Idris:
kompilátor: hele, zapomněl jsi tady zohlednit tenhle scénář
já: nezajímá
kompilátor: mě taky ne, nepustím tě dál
já: ale já to chci přeložit.
kompilátor: nezajímá
já: štveš mě
kompilátor: nezajímá
já: grrr, SO, ha, mám to, musím tam narvat error()
kompilátor: když myslíš
já: :P

C#
kompilátor: přeloženo
reviewer: hele, hmm, neměl by si tady zohlednit tenhle scénář?
já: to se nestane
reviewer: no, já nevím
já: hele, šéfe, von mě zdržuje
šéf: to je v pořádku, pusť to
klient: ehm, pánové, to si to po sobě neumíte zkontrolovat? Padá to při třech scénářích
reviewer: třech?! Kde?

27
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:37:21 »
Jsou náročné na čas výpočtu v době překladu, za běhu ne.
Ano, ano, sorry.
A platí o opak, že za běhu by to mělo být rychlejší. Žel, jak nám Králík ukázal, tak jen teoreticky. Což je taky smutné - takovej nevyužitej potenciál.

28
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:30:48 »
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?

29
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:29:12 »
Akorát cena za to je,
Imho statické typy mají jiné problémy.
Namátkou:
- jsou náročné na čas výpočtu
- jsou náročné na vývoj jazyka
- jsou náročné na skill uživatele
- lidé nechápou co to je statické typování

30
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 07. 12. 2022, 14:25:04 »
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.
Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?
O to nejde.

Samozřejmě, že ten scénář musím zohlednit v runtime.

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

Částečně by toto řešil systém Checked Exception, od kterých se ale bohužel upouští. Úplně netuším proč. (C# je třeba schválně nemá.)

Stran: 1 [2] 3 4 ... 133