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 ... 24 25 [26] 27 28 ... 133
376
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 23. 04. 2021, 20:11:49 »
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP.

377
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 23. 04. 2021, 20:07:53 »
A přitom ve skutečnosti vznikli jen díky tomu, že jazyk bez typové kontroly je možné snáz implementovat.
Není to spíš naopak? Je implementoval oba typy jazyků a runtime pro jazyk bez typové kontroly je těžší napsat, právě kvůli absenci garancí.
Jaké garance máš na mysli?

378
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 23. 04. 2021, 16:31:33 »
V takovych diskuzich se pak cas od casu najdou lide, kteri upozorni, ze existuji i nadale 'nerelacni' cerpadla a ze by nebylo od veci se po takovych poohlednout.
V nasledne diskuzi ...
Následně se nějaký trouba zeptá, ok, jaké to nerelační čerpadlo má výhody? A dostane se mu odpovědi - to musíš zkusit.

Takhle jsi to myslel? ;-)

379
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 23. 04. 2021, 16:25:35 »
Když zatloukáš šroubek kladivem, místo co bys použil šroubovačku, tak Ti to moc času neušetří. Ale výsledek je takovej jakej je (přítomným truhlářům, pokud se pletu a existují vruty, které jdou zatlouct rozumně, se omlouvám :-) - možná jen zas já neumít zatloukat vruty? :-))
Vruty se zatloukat dají, jde to rychle. Má to případ užití. Asi jeden :-)

Je to jako všude. Člověk tomu musí rozumět a zvolit správný nástroj. Jenže někdy se děje, v IT konkrétně, že se nezkoumá příčina. Například já opakovaně bojuju (jen to zmíním, nechci to znovu rozvíjet) s mýtem, že dynamické jazyky (bez statické typové kontroly) mají nějaké výhody. A přitom ve skutečnosti vznikli jen díky tomu, že jazyk bez typové kontroly je možné snáz implementovat.

Zda to je mýtus nebo není, se dobře pozná podle toho, zda to ten dotyčný dokáže obhájit. Když nedokáže, je to (pravděpodobně) mýtus.

380
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 23. 04. 2021, 16:15:30 »
Šáhněte si do svědomí, jestli sám máte všechno v pořádku a jestli je ta nedokonalá znalost RDBMS opravdu to jediné, co nás trápí...

Snažím se vždy posoudit (neformalizovaně), jak velké mezery v které oblasti (z těch jmenovaných) a na kterém projektu mám, a volím ten kompromis co nejvíc racionálně. Snažím se udržovat si přehled, jakým směrem se projekt může ubírat a hlídat ty části, na kterých by to mohlo narazit. Na registrační formulář, pro zákazníka, který má po 20 letech činnosti pár tisíc registrací, klidně šoupnu MySQL a ORM, ale pohlídám, že se to neobjeví na projektu, kde mám po roce desítky milionů záznamů (položek) a vím, že je nutné s nimi pracovat dál. Jenže na to musíte mít aspoň ten přehled (a toho není nikdy dost, to uznávám).

Ale taky se setkávám s vývojáři, pro které je překvapením, že by nějaká i free databáze mohla dávat mnohořádově vyšší výkon, nebo vůbec netuší, že je ORM odizoluje od možnosti optimalizací, které k tomu vedou. Nevědí, že stejná databáze může úplně stejný výsledek poskytnout mnohem rychleji, když se navrhne trochu jinak. Jsou prostě naučeni jeden jediný postup, aniž by znali jeho výhody a nevýhody.

Pokud tedy nevědí, kde jaký prostor je, pak nemohou činit ani rozhodnutí.

Co tady říkám (a mám dojem, že Pavel taky) je to, že by vývojáři měli mít právě ten vhled do těch oblastí, a aby uměli vytipovat místa a chvíle, kdy je potřeba se zeptat někoho dalšího. Tedy např.: budu programovat e-shop, který bude vše feedovat do ERP systému. Je vhodné použít ORM? Vs. budu programovat e-shop s pokročilou administrací, s požadavkem na složité výstupy, napojený na dalších 12 systémů - je ORM vhodné? Jenže na to musí vědět, že takovou otázku (si) musí vůbec položit.

Přinese mi NoSQL zajímavé výhody, nebo mohu toho samého dosáhnout pomocí klasické SQL (jak už tu bylo ukázáno)?

381
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 22. 04. 2021, 15:50:37 »
že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.
Jako profesně bývalej truhlář musím poznamenat, že šroubky se kladivem zatloukají naprosto v pohodě ;-)

382
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 17. 04. 2021, 19:23:51 »
To je otázka interface - a když použijete Linq, tak ani nemusíte vědět, co je pod tím. Ale pokud nepoužijete opravdovou objektovou databázi, tak stejně bude docházet k nějakému mapování
Ta degradace databáze na storage má svoje výhody (máte méně kódu), ale i svoje nevýhody (nikdo jiný než vaše aplikace) neumí s daty pracovat - nemáte garantováno, že vám někdo externě naleje data ve správném formátu. A při exportu musíte načítat generické json - ta data mohou být relativně komplikovaná, protože mícháte víc entit do jednoho dokumentu. U relační databáze máte vstupně výstupní formát mnohem jednodušší (není rekurzivní) a garantuje vám ho databáze.
Domenove objekty ve vasi aplikaci mezi sebou maji vazby, ktere tvori graf, a ne strom. Jakym zpusobem grafove zavislosti ukladate do MongoDB? Vsude vidim jenom priklady na ukladani stromovych vazeb.

...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze. Podle mě by v pohodě nahradily 90% případů, kdy je sql použita neoptimálně a de fakto zbytečně. Dnes se do této oblasti tlačí NOSQL a dokumentové databáze, ale to mapování opět bolí.

Nemohlo by to být tím, že zatímco relační algebra je jasný, matematicky propracovaný systém, kde jsou problémem spíše uživatelé, tak u objektů je problém si jen ujasnit, co je "správně objektově"?

383
Vývoj / Re:pouziva niekto cloudove IDE?
« kdy: 08. 04. 2021, 16:07:06 »
je to kladivo na flakacov, cista produktivita, pc stara plecka s browserom a zablokovane vsetky domeny okrem toho ide, 8h koderiny :D
Tak ve snu.

384
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 07. 04. 2021, 00:26:59 »
že například predikát Even dostává vždy dvojnásobek nějakého neznámého čísla, tak taky automaticky víš, že je sudé.

Rozumím. Toto jsem si tak docela neuvědomil.

Každopádně tato session byla užitečná, díky moc, hodně mi to dalo. Jdu žvejkat. A někdy zase.

385
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 23:45:48 »
Statické ověřování se týká konstantního kódu. Jakmile je tam nějaká dynamika, to znamená vnější svět, tak se opět vracíme k Maybe, protože to jinak nejde.
Tohle tak úplně neplatí. Když mám třeba
Kód: [Vybrat]
inc : Nat -> Nat
inc n = S n
a vyhodnotím isNonZero (inc anyNat), tak mám dokonalou typovou analýzu i pro dynamická data. Podobně jde pomocí záv. typů udělat filtr podle predikátu na Vect n a, aniž by bylo předem známo, kolik prvků predikát splňuje. Záv. typy (resp. jejich implementace založená na unifikaci) je silnější právě díky symbolickému dokazování (a má v rukávu pár dalších triků, například kvantifikované typy).

Tady si možná nerozumíme v tom, co si představujeme pod pojmem dynamika. Mám-li parsovací funkci, která mi ze stringu dělá číslo, tak nemůže vracet číslo jen tak. Bez ohledu na to, jaký nástroj zvolím. Prostě je tam rozdvojka. Pokud mám funkci, která na vstupu přijímá číslo, a volá funkci, která vyžaduje jen sudé, tak se nevyhnu rozhodování co s lichejma.

Ale to je jen jeden scénář, na který typy použiju.


Proto nejsou záv. typy zbytečná blbost,
Nic takového jsem ani nenaznačoval. Jen si prošlapávám půdu.

386
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 22:53:05 »
- Za běhu funkce div nikoho nezajímá, nemá dva argumenty, není vůbec... Za běhu je na všechno pozdě a prostě děj se vůle boží.
To bych takhle neřekl, myslím, že jádro věci je, že za běhu nikoho nezajímá její třetí argument.
No, trochu si zatrucuju: já bych to tak řekl :-) Ale rád si to nechám vysvětlit.
Ale ta funkce div tam je, ne? A počítá za běhu.
Ta funkce div tam je. Ale nemá žádné argumenty, o kterých by se dalo uvažovat. Nebo ještě jinak, za běhu s ní vůbec nijak nepracuješ. Tobě, jako programátorovi/matematikovi se ta funkce jeví tak, jak ji vidíš v kódu - tedy div se třemi argumenty.


Primitivní validační funkce ti stačí, ale jak jsi sám psal, bude se vyhodnocovat za běhu.
Počkej, počkej, takto mi to neštymuje.

Zkusme změnit syntax:

Kód: [Vybrat]
isNotZero x = x /= 0

divide :: Int -> a:Int -> Float & isNotZero a
divide a b = a `div` b

calculate x = divide 42 x
- Důkaz píšu jako jméno validační funkce za ampersand.
- Ta validační funkce je úplně nudná.
- Funkci divide volám úplně obyčejně, není třeba ji tam explicitně uvádět.
- Při kompilaci mašina projde graf volání, a je schopna staticky, při kompilaci, ověřit, že při volání divide a b, b není nula.
- To ověření proběhne při kompilaci, nikoliv za běhu.
- Statické ověřování se týká konstantního kódu. Jakmile je tam nějaká dynamika, to znamená vnější svět, tak se opět vracíme k Maybe, protože to jinak nejde.

Vidím to příliš jednoduše, nebo je to opravdu v tom, že
tohle přišlo od akademiků, kterým evidentně nezáleží na hezké čitelné syntaxi a jasném oddělení argumentů pro běh a pro kontrolu typů (např. číselné argumenty pro dělení vs. důkazy).
?

387
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 17:47:27 »
Budu v té úvaze pokračovat dál:

Nadefinuju si typ NotZero, který bude čistě jen značka. Vynutí mi abych vytvořil "validační" funkci. A nic nebrání kompilátoru, aby tu funkci použil při compiletime pro ověření, zda (a + b) je NotZero.

To bychom měli.

Jenže, 4 + (-4) není NotZero, ale Int. Takže typ neprojde stejně. Ledaže bychom zavedli nějakou dědičnost, kdy je NotZero potomkem Int, etc, etc. Nebo automatické castování, etc, etc. To už je ale jinej svět.

Takže pokud to chápu dobře, tak ZT dělají to, že nechají ten Int Intem, jen přidají pravidla navíc. To pravidlo se tam propaguje pomocí těch dalších argumentů. A kompilátor to "nějak" použije pro ověření.

Mám otázky:
- Uvažuju správně?
- Proč jsou ty ZT tak složitý? Proč nestačí primitivní validační funkce? že by mi unikl ještě třetí scénář validace? Nebo to umí víc?
- Umí to víc?

388
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 17:35:30 »
- Za běhu funkce div nikoho nezajímá, nemá dva argumenty, není vůbec... Za běhu je na všechno pozdě a prostě děj se vůle boží.
To bych takhle neřekl, myslím, že jádro věci je, že za běhu nikoho nezajímá její třetí argument.
No, trochu si zatrucuju: já bych to tak řekl :-) Ale rád si to nechám vysvětlit.


- Cílem typů (Maybe nebo závislostních), nebo čehokoliv jiného, je přinutit mě, abych ošetřil všechny vstupy.[...] jsem přinucen zohlednit, když se parsování nepovede. To je cíl - nedovolit překlad.
Jo, takhle to je. Bez záv. typů si může člověk ohlídat jen běžné typy (číslo vs. řetězec apod.), ktežto u záv. typů jdou hlídat i hodnoty (nenulovost, neprázdnost řetězce atd.). Je to prostě stejný princip o krok dál (i když implementačně to je o dost složitější a matematicky taky, typy už nejsou jedna kategorie, ale celá kumulativní hierarichie toposů).
Tady se domnívám že se jeden z nás plete. Podle mne bez závislostních typů si můžeš ohlídat i nenulovost, neprázdnost řetězce, etc. V tom ten problém není. Příklad:

Kód: [Vybrat]
divide a b = a `div` b

calculate :: NotZero -> Int
calculate x = divide 42 x

main :: IO ()
main = do
    putStrLn $ "--> " ++ (show (calculate (a + b)))
    where
        a = 4
        b = -4
Bez ZT i s nima, problém vyřeším stejně. Rozdíl je v tom, že, pokud to dobře chápu, bez ZT mi to vynutí (zbytečný) Maybe, což bude trochu matoucí. Zatímco ZT v pohodě při překladu odvodí, že to "nechci" a nepřeloží. Bez ZT runtime, s ZT compiletime.

389
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 17:26:17 »
Teď jsem si uvědomil, že to parsování vstupu je trochu zavádějící. Protože je to jen jedna množina problémů. Pak tu mám druhou,  například takto:

Kód: [Vybrat]
divide a b = a `div` b

calculate x = divide 42 x

main :: IO ()
main = do
    putStrLn $ "--> " ++ (show (calculate (a + b)))
    where
        a = 4
        b = -4
Tam mě žádné Maybe nezachrání.

390
Vývoj / Re:Haskell, ExistentialQuantification, forall
« kdy: 06. 04. 2021, 17:16:18 »
Kód: [Vybrat]
calculate : Nat -> Maybe Nat
calculate n = case isNonZero n of
  Yes prf1 => case isNotAllowedValues n of
      Yes prf2 => Just $ div 42 n prf1 prf2
      No _ => Nothing
  No _ => Nothing
Šlo by? Nebo se vzdaluju té myšlence ZT, a přiohýbám si to klasice?

Stran: 1 ... 24 25 [26] 27 28 ... 133