Příspěvky

76

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 01:31:05 »

Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.

U HKT je situace asi celkem jasná (aplikativní funktory a tak). U GADT je to zajímavější, umožní mi mít například toto:

Kód: [Vybrat]

data Vect : (len : Nat) -> (elem : Type) -> Type where
  Nil  : Vect Z elem
  (::) : (x : elem) -> (xs : Vect len elem) -> Vect (S len) elem

Podobně se dají udělat matice s dimenzí na úrovni typů. Navíc ty dimenze nemusí být známy v době překladu, klidně se můžou načíst ze vstupu/souboru. Tohle bez GADT nejde. Porovnání s C++, Javou nebo Rustem prostě je, že v těchto jazycích dimenze staticky ověřovat nejde (například při skalárním součinu nebo násobení matic).

Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý. Musíš začít takhle:

Mějme následující problém:
Chceme vytvořit čtvercovou matici přirozených čísel, kde si budeme kontrolovat, že je čtvercová. A následně nad těmito maticemi budeme vytvářet operaci, například součet. Pochopitelně chceme sčítat matice stejných velikostí.

V Pythonu to vyřešíme takto:

Kód: [Vybrat]

class Matice(object):
    def __init__(self, rows):
        self.assertSquare(rows)
        pass
    def add(self, x):
        self.assertEquals(x)
        pass

V Haskellu to vyřešíme takto:
haskell code que j'ai la flemme d'écrire

V Rustu to vyřešíme takto:
rust code que j'ai la flemme d'écrire

V Idris to vyřešíme takto:
idris code que je ne sais pas écrire

Můžete si všimnout, že v případě Pythonu to musíme ověřovat v době běhu. Zatímco v XY nám to kompilátor zajistí během překladu.

77

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 03. 12. 2022, 17:34:13 »

prijde mi diskuse skoro jako nabozenstvi.

Tak jsme z toho jazyka nadšení. Je to hřích?

78

Studium a uplatnění / Re:Neochota firmy zvednout plat

« kdy: 03. 12. 2022, 17:32:24 »

Podla mna kvalitne firmy vam zvysia plat same od seba. Nikdy som si ja osobne zvysenie platu nepytal.

Toto bych netvrdil.
Je sice hezké, když si ta firma vzpomene, že by ti mohla zvýšit plat. Ukazuje to, že má chytře nastavené procesy atd.

Podle mě bohatě stačí, že kvalitní firma vám bez keců zvedne plat. Někdy se musíte připomenout, ale nemá s tím problém.

79

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 02. 12. 2022, 23:03:06 »

Domnívám se, že hodně schází nějaký projekt, který by porovnával řešení mezi jazyky. Občas zkouším použít RosettaCode, ale je to dost zakopaný. Představoval bych si něco předžvejkanějšího. Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší. <sup>1)


1)</sup> provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)

80

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 01. 12. 2022, 18:19:47 »

Nevím, jak se ten “mentální obzor” měří

Používají "moderní" jazyky jako je C#.

81

Server / Re:Snapshot aktuálního stavu v MariaDB

« kdy: 27. 11. 2022, 03:35:22 »

na lokálnom stroji mám
...
Kópia /var/lib/mysql?

Toto jsem používal a funguje to celkem dobře. Je to krapet "ošklivé", hrabat marii takhle do střev, ale funkční.

82

Vývoj / Re:Načtení 2D pole v C

« kdy: 20. 11. 2022, 23:24:16 »

kdyz chce nekdo proniknout do veci, tak si i ty cihly muze sam udelat a vyzkouset si to.
pak kdyz zjisti jak to funguje, nasledne muze prejit na cihly co uz jsou k dispozici.

Na youtubu jsem viděl pár videí několika lidí, kteří to skutečně tak udělali. V reálném životě neznám nikoho. Tedy vulgo: ano, máte pravdu, ale ta vaše pravda je k ničemu.

83

Studium a uplatnění / Re:Programovat může každý?

« kdy: 19. 11. 2022, 14:53:54 »

a správně už vůbec ne

Kdo určuje, že je to správně?

Narazil jsem na případy, kdy tým lemplů nechtěli přijmout zkušeného - tak jak popisuješ. Stejně jako tým zkušených, do kterého se marně snažil nabourat chytrolín, který tvrdil, že to všechno "vůbec není mainstream a správně už vůbec ne".

84

Vývoj / Re:Visual Studio Code C/C++ zkušenosti

« kdy: 13. 11. 2022, 23:30:56 »

Proč IDE
- navigace mezi kódem, kliknutím na funkci se dostanu na její definici, možnost vyhledat si všechny výskyty, etc
- našeptávání
- hromadné přejmenování
- debugger
- plus všechno na jednom místě build, testy, etc

Proč VSCode
- je o něco svižnější jak javovská IDE
- mraky pluginů na všechno, třeba scala furt pro NetBeans není, zatímco pro VSCode je kdejaká blbost v několika verzích a různě funkční
- je všude
- je aktuálně módní

85

Vývoj / Re:Je Zig jazyk buducnosti?

« kdy: 11. 11. 2022, 01:48:24 »

a rust ty nesvary ohlida, ale zaroven, nezblbnou ti lidi o to vic, ze uz to nemusi kontrolovat?

Potřebujeme najít skvělé programátory, kteří dělají málo chyb a jsou drazí. Chybovost kódu 20%.
nebo
Ten jazyk umí použít i průměrný a levnější programátor, chyby odchytí kompilátor. Chybovost kódu 0.2%

Vyber si.

86

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 10. 11. 2022, 00:42:37 »

Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Aha, takže IIUC jde o klasický trik, který se používá u benchmarků, aby kompilátor „nepodváděl". Výslednou hodnotu pošle někam do /dev/null, ale poslat ji musí, aby nešidil. Ale potom to není jen o nadefinování parseru/serializéru, ale i o jejich použití.

Ano. Zvolil jsem špatné slovo a zmátl tě.

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

S tím libovolným jiným jazykem to je asi trochu silné tvrzení, ale v případě Haskellu to asi platí.

Tak tím libovolným nemyslím doslova libovolným, ale asi by to nemělo mít nějaké zvláštní omezení.

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:

Kód: [Vybrat]

let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1

budou tři 256prvkové pole.

To ne, zejména v Haskellu, který je líný.

Kód: [Vybrat]

let xs = strictList [1 .. 256]
let xs1 = strictList $ filter f1 xs
let xs2 = strictList $ map f2 xs1

Lepší?

Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.

V případě laziness má kompilátor teoreticky celkem volné ruce, prakticky to není tak snadné. Aby to bylo korektní, musí se poprat se situacemi, kdy a. výpočet skončí chybou a b. výpočet neskončí nikdy, nebo by trval extrémně dlouho. V praxi to v kombinaci s neřešitelností problému zastavení bude znamenat, že budou existovat situace, kdy by šlo použít striktní vyhodnocení, ale kompilátor to nezjistí.

Ano, to jistě. Určitě tam budou nějaké hranice. A snaha programovacích jazyků (k danému tématu o kterém sa bavím) je vytvořit paradigma, aby se do těchto situací nedostával (což lazyness zrovna není moc zásah do černého, asi, nevím) a přitom vývojář nemusel pomáhat. Protože když se vývojář snaží pomáhat, vždy škodí.

87

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 09. 11. 2022, 23:04:14 »

Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek…

Tak. A o tom to je.

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.

Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.

Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Hlavně, počítá se začátek a konec. To mezi tím je nedůležité (nadsázka).

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:

Kód: [Vybrat]

let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1

budou tři 256prvkové pole.

v čem pomůže, když to napíšu ručně.

Ty mu řekneš, že na vstupu a výstupu je pořadí barev je RGB. To on neví, to mu musíš určit. Ale mezi tím si ty barvy pomíchá třeba na BGR. Nebo po klastrech.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.

Haskell je lazy už v sémantice, takže to musí kompilátor zajímat…

Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.

88

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 09. 11. 2022, 21:59:08 »

nevím, k čemu by Haskellu byl parser a serializer.

Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell ¹⁾ optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

Možná to bude moje neznalost Haskellu, ale pořád mi to nedává smysl. Pokud by to mělo mít nějaký sémantický význam, ze kterého lze tu optimalizaci odvodit, mohl by to být jen nějaký příznak, a kompilátor si může parser a serializer vygenerovat u takto jednoduché struktury sám.

Já taky nejsem žádnej guru. Jde ale o to uvažování. (Snad nejsem moc mimo.)
Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

No věřím, že v Haskellu má kompilátor některé věci jednodušší. Ale jsem dost skeptický, že bez dalšího zvládne udělat ten rastr efektivně, z důvodů, které jsem psal.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude. Halt problém je věc trochu bokem. A jediné, co mě zaujalo byla skutečnost, že Haskell má nějaké defaultní nastavení zda preferovat rychlost či paměťovou náročnost. Což by bylo správně ^(tm) řešit nějakým klíčovým slovem nebo podobnou formou jazyka. Ale to opravdu neznám jestli někde v nějakém jazyce je chytře deklarativně řešeno.

Věřím, že s nějakým strict byste té optimalizace dosáhl. Jistý si s tím nejsem, ale věřil bych tomu.

Tohle se normálně v praxi používá. Ale je to ideově špatné :-) Takhle by se to dělat nemělo, i když to funguje.

Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere. Neříkám, že je tento přístup špatně, někdy se hodí nízkoúrovňovější přístup (např. řešíme side channels u kryptografie, tam optimalizace kompilátoru mohou i škodit…), někdy vysokoúrovňovější.

Jo, Haskell je vysokoúrovňový. A ve svých snech si představuju, že by to mohlo jít ještě extréměji. A někdo to chce, někdo ne. Věřím, že mi vyhrajem. :-)

89

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 09. 11. 2022, 13:04:41 »

nevím, k čemu by Haskellu byl parser a serializer.

Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell ¹⁾ optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?

Tady jsem trochu zaváhal. Netuším, zda to lze nějak ovlivňovat. V praxi se skutečně v tomto případě používá porušování toho principu "nenavádět", a začne se do toho Haskellu kecat pomocí strict a unsafe. Jestli na to jiné nástroje mají nějaké lepší instrumenty už žel netuším.

^1/ Čímž netvrdím, že to dělá; vůbec netvrdím, že se to tak skutečně provede. Ale vzhledem k tomu, jaké brutální optimalizace dokáže GCC s hloupoučkým C, tak proč by to Haskell nedal ještě líp.

90

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 09. 11. 2022, 04:05:00 »

Většinou to vědět nepotřebuju, ale někdy se to hodí. Třeba když řeším paměťovou náročnost. Extrémní příklad může být s rastrovým obrázkem. Nejpřirozeněji bych ho vyjádřil jako dvojrozměrné pole objektů typu třeba RGB. (Vím, RGB není jediná možnost, ale dejme tomu, že nám to bude stačit ) První problém je dvourozměrné pole – spousta jazyků místo toho nabídne pole polí, které je mocnější, ale méně efektivní. Druhý problém je v některých jazycích ten objekt typu RGB. Já bych potřeboval dejme tomu 3 byty na objekt (záleží na barevné hloubce, ale nekomplikujme to). V Javě se k tomu přidává už celkem slušný overhead – už jenom reference na ten objekt zabere víc, nemluvě o tom, že objekt potřebuje hlavičku jednak kvůli popisu třídy (VMT apod.) a jednak kvůli zamykání (každý objekt je i zámek). Z hlavy nereknu, kolik přesně obrázek zabere, ale zjevně to bude několikanásobně vícz než je účelné. A v Pythonu to bude ještě horší, každý objekt je i dictionary…

Mimochodem, podobné případy přinášejí zajímavý paradox – ve vyšším jazyce bych pravděpodobně použil víc low-level přístup (jako obrovské pole bytů), abych se vyhnul tomu overheadu. V low-level jazyce s vhodnou abstrakcí to není tolik potřeba

Já bych teda intuitivně udělal RGB jako typ, a dvourozměrné pole (jak popisuješ), parser a serializer. A pak bych očekával, že ten Haskell si tu paměťovou náročnost odvodí a zoptimalizuje sám.

Ve skutečnosti vůbec netuším jak by to dopadlo. Třeba by zklamal, třeba ne. Jakou ale mám zkušenost z "vysokoúrovňových" jazyků, tak snažit se jim pomáhat s nějakou paměťovou (nebo jinou) náročností je a/ principielně chyba; b/ v praxi ale někdy třeba.

Smyslem vysokoúrovňových jazyků je, že to dokáží udělat místo tebe a lépe, a ty jim jen řekneš co chceš. Jakmile jim místo zadání začneš pomáhat s implementací, většinou je zmateš - ale tady se začínám pohybovat v tekutých píscích teorie a ideí.