Příspěvky

226

Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?

« kdy: 24. 01. 2022, 05:29:53 »

Typová bezpečnost u dynamického jazyka znamená co konkrétně?

To samé jako u staticky typovaného, že kód jde otypovat tak (ručně nebo inferencí), že v době běhu není nutné zkoumat typy objektů pro hladký běh.

To máš se mnou těžké, když já si představuju, že poté, co kompilátor vyplivne program, tak v něm jsou všechny typy odstraněný jako zbytečný, a jsou ponechaný jen ty nutný pro dynamic dispatch, a to ještě jenom v případě věcí jako je kolekce podtypů...
Zatímco u dynamického jazyka všechny typy musí zůstat, protože je třeba umožnit, aby to ve čtvrtek na produkci zbuchlo až tam Franta zapíše int věk="starej". (Ano, slyšel jsem o JIT.)

227

Vývoj / Re:Ruby v roku 2022 (je mrtve?)

« kdy: 24. 01. 2022, 04:24:56 »

P.S. nakoniec som teda vybral naozaj to Go, nestazoval sa na to nikdo.

To uz si v Go aj napisal ten program aj v pohode vsade bezi a vsetci su spokojni ?

Vzdaj to, nebudem to pisat v niecom co potrebuje JVM. Co mas proti Go?

Taky by to šlo napsat v Go a pak transpilovat do Javy

https://github.com/elazarl/go-java ?

228

Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?

« kdy: 24. 01. 2022, 04:09:39 »

Vycházím z, možná nesprávného předpokladu, že když budu mít následující dvě proměnné:

Kód: [Vybrat]

a = "string"
b = 42
test(x) {
  print("typ: {x.type}")
}
test(a) // typ: string
test(b) // typ: number

Tak se budou chovat stejně bez ohledu na to zda je jazyk silně nebo slabě typovaný.

Jenže typeof je jen v silných typových systémech. To je právě ten problém.

Měl jsem za to, že Javascript je slabě typovaný. Stejně tak PHP, VisualBasic.
Uveď příklad jazyka, který tedy nemá typeof (slabě typovaného dle tvé definice)?

Ale to jsme dost odbočili, jen jsem chtěl říct, že dynamičnost a síla typového systému jsou dvě různé dimenze, které slouží dvěma nezávislým cílům, zajistit typovou bezpečnost a efektivní překlad či interpretaci. Pokud je jazyk staticky nebo silně typovaný, je obojího dosaženo, i když splňuje jen jednu z těch podmínek.

V Javě se to dělá tak, že VM oficiální typy zahodí, a odvozuje si svoje.

Každopádně uznávám, že problematice jak typy zlepší efektivitu překladu jsem se nikdy moc nevěnoval. Pro mě jsou jazyky bez statické kontroly nedostatečné obecně (rozuměj, fakt nemám náladu honit chyby v run time).

Typová bezpečnost u dynamického jazyka znamená co konkrétně?

Pokud je jazyk staticky nebo silně typovaný, je obojího dosaženo, i když splňuje jen jednu z těch podmínek.

V tomto se žel neshodnem. Je-li jazyk staticky typovaný, přináší to jasné a měřitelné bezpečnostní výhody. Je-li jazyk dynamicky silně typovaný, nejsem si vědom žádných výhod (co se té silně typovanosti týče) které by stály za řeč.
Ale rád se nechám přesvědčit.

Poznámka na závěr: Jak jsem si ověřoval zdroje, zda snad nekecám blbosti, tak jsem nabyl dojem, že zásadní problém je v tom, že slabě typovaný jazyk (= ve smyslu jazyka, kde by prostředí v daném okamžiku nevědělo jakého je ten který prvek typu, a nemohlo by vesele optimalizovat jak jsi mě poučil) možná ani neexistuje. Tudíž klauzule, že jazyk XY je silně typovaný je jen tak pro parádu.

229

Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?

« kdy: 24. 01. 2022, 02:27:43 »

Silné typování nijak zvlášť nesouvisí s JS.

Nic takového jsem netvrdil. JS byl uveden jen jako příklad.

Ostatně i dynamicky typovaný jazyk může mít například záv. typy.

Možná se každý bavíme o něčem jiném. Možná si pod silným typováním představuji něco špatně.

K čemu by byly dobré, u nějakého dynamicky typovaného jazyka, závislostní typy? Jaký by měli přínos?

Vycházím z, možná nesprávného předpokladu, že když budu mít následující dvě proměnné:

Kód: [Vybrat]

a = "string"
b = 42
test(x) {
  print("typ: {x.type}")
}
test(a) // typ: string
test(b) // typ: number

Tak se budou chovat stejně bez ohledu na to zda je jazyk silně nebo slabě typovaný. (Ignorujme prehistorii v podobě jazyka C.)

230

Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?

« kdy: 24. 01. 2022, 01:10:21 »

Statické jazyky, zvláště takové debilní jako je Java nebo C# […] Jsem fanatický příznivce a zastánce staticky typovaných jazyků a nenávidím dynamicky typované.

To zní dost drsně. A ani to moc nechápu, není mnohem zásadnějším rozdílem silné vs. slabé typování?

To jsme tu už rozebírali.
Silné vs slabé typování je defakto banalita, nestojící za polemiku. Skutečnost, že se mi Javascript snaží automaticky konvertovat cokoliv podobného číslu na číslo má sice vliv na programátorský prožitek, ale že by z toho musela být extra kategorie si nemyslím. Takže má odpověď zní - ne, vůbec. V praxi silné typování nic zásadního nepřináší.

231

Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?

« kdy: 23. 01. 2022, 23:38:10 »

Jenze. Opravte me jestli se mylim, ale ja budu muset zvalidovat pritomnost a delku kazdeho jednoho fieldu tak, jako by to pro me udelalo napr. preddefinovane DTO v Jave a preddefinovana tabulka v Relacni databazi. Protoze jinak by mohl nejaky hacker do endpointu order poslat 100gb nesmyslu a zahltit mi databazi.

Takze kdyz jsem si chtel na zacatku ulehcit praci a pouzit dynamicky typovany jazyk a MongoDB, tak nakonec budu muset stejne delat to, co by pro me delal staticky typovany jazyk a Relacni databaze k tomu.

Nebo mi neco nedochazi?

Je to otázka rétoriky.

Čistě fakticky: chceš validovat? (blbá otázka) Takže budeš muset validovat. Je vcelku buřt jakým způsobem.

Když si pozorně přečteš, co jsi napsal, tak tam nikde nenajdeš, že by ti staticky typovaný jazyk nějak zázračně všechno automaticky validoval. Databáze detto. Ty tam píšeš, že ti to bude dělat staticky typovaný jazyk, protože v něm to musíš nadefinovat, jazyk ti to nutí (tiše předpokládám, že tam navíc máš nějakou reflexi nebo podobnou chytristiku, aby si nemusel psát tu samou validaci jen kvůli tomu, aby ti to sedlo na typy). A stejně si to musíš nadefinovat v tom javascriptu. Není v tom žádný zvláštní rozdíl.

Vypíchl bych tři detaily:

1/ Používáš-li relační databázi, nebo staticky typovaný jazyk, tak máš jakési povědomí o validaci, o tom, že do varcharů se čísla neukládají (zdravím MySQL), etc. Takže tě to napadne, že tam tu validaci budeš potřebovat, že by tam asi měla být.

2/ Statické jazyky, zvláště takové debilní jako je Java nebo C# v praxi dopadají často tak, že tam tu validaci máš dvakrát třikrát, protože jednou na vstupu, podruhé při mapování na DTO, třetí ve formulářích, čtvrté při mapováná do Hibernate, páté ve vlastní databázi...
V dynamickém jazyce jako je Javascript obvykle validaci nemáš vůbec. Protože bod 1. Ale když už to dělá nějaký senior, tak to udělá chytře, definuje si pravidla jednou, a pak je posílá všude kam potřebuje.

3/ Staticky typované jazyky mají úplně jinou motivaci než validaci dat, i když i na to se samozřejmě dají použít (nebo tam překáží).

Disclaimer: Jsem fanatický příznivce a zastánce staticky typovaných jazyků a nenávidím dynamicky typované. To mi však nebrání vidět jasně.

232

Studium a uplatnění / Re:Vykazovanie práce a odpracovaného času

« kdy: 13. 01. 2022, 23:38:58 »

Zdravím root,
....

Nastoupil jsem do práce na pozici juniorního webového vývojáře na backend vývoj. ...
....

Dodnes jsem z této zkušenosti v rozpacích, pracuji již v jiné firmě, kde je vlastně vše úplně jinak, i přesto pořád přemýšlím kde jsem udělal chybu a co jsem mohl a měl udělat jinak. Opravdu nevím.

Na rozpacích? Přemýšlíš? Udělal chybu? Udělat jinak? Dej si pár facek a děkuj svému stvořiteli, že ti dal do začátku tak skvělou zkušenost, kde ses naučil hodně o technologii, o fungování firem a o tom co zvládneš.
A to vše úplně zadarmo - myšleno, že si z toho neneseš nějaký průšvih (kdybys to třeba dělal na IČO a oni řekli, že jsi tam udělal škodu za 10 milionů).

Hele souhlas. Takováto zkušenost je k nezaplacení. Ale samozřejmě, pokud možno již neopakovat :-)

233

Studium a uplatnění / Re:Vykazovanie práce a odpracovaného času

« kdy: 13. 01. 2022, 19:34:59 »

Poviete si, no dobre, spravím ten task rýchlejšie a vykážem si plný čas. No nie celkom. ... A keď sa to už aj nejak stihne rýchlejšie než je vymedzený čas, tak by sa mal vykazovať realny čas.
...
 a makáš a keď nestíhaš, musíš robiť doma po víkendoch alebo si zobrať dovo.

Proč je vývojář trestanej za šikovnost?

234

Studium a uplatnění / Re:Lhaní recruiterů

« kdy: 10. 01. 2022, 23:51:27 »

Skutocne by ma zaujimalo ako to vnimaju ostatni to zahrnanie vyvojarov nesuvisiacov pracou s touto poziciou. Mozno je problem u mna (mozno som neschopny), ale skutocne som teraz presvedceny, ze softverovy vyvojar ma hlavne vediet programovat, navrhove vzory, best practices, vediet osetrit maximum chyb sposobom ktory dava zmysel, vyznat sa vo frameworkoch, poznat svoj jazyk do hlbky atd. Rozhodne si nemyslim, ze napr. je normalne od C++ alebo Java programatora ocakavat, ze vie databazy v zmysle ich nasadenia, odhadov kolko HW bude potreba atd. Rovnako si nemyslim, ze pre vyvojara je normalne starat sa o infrastrukturu, riesit nejake balickovanie, kontajnery atd. Ak to po mne chcu, tak fajn, ale ja chcem potom za kazdu z tych cinnosti mzdu adekvatnu danej pozicii kde zapadaju tieto cinnosti, lenze to je nonsens samozrejme.

Čistě můj pohled:
Nemá smysl hrát si na to, co je nebo není normální; co má nebo nemá smysl.
Prostě je tu nějaká poptávka, a nějaká nabídka.

Je firma, která očekává, že jako Java, nebo C++ programátor umím i databázi do hloubky? Fááájn, není problém. A umí to ta firma ocenit?

Třeba já se specializuju na legaci kód, a mé znalosti jsou dost široké. Ale taky mám určité požadavky na zákazníka (finance, pohodlí, a tak).

235

Vývoj / Re:Typový system versus unittesty

« kdy: 08. 01. 2022, 00:43:48 »

Zjistil jsem, že Julia má (nevím, od které verze) něco jako závislostní součtový typ (píšu “něco jako”, protože to zřejmě není zamýšlená vlastnost jejího typového systému). Dávám to sem jen jako doplňující poznámku související s tématem tohoto starého vlákna, kdyby si někdo (BoneFlute ) chtěl hrát se závislostními typy a nechce se mu otravovat s haskelloidními jazyky — Julia je přece jenom stravitelnější.

Díky.

236

/dev/null / Re:Cestovanie v čase - cestovanie do minulosti

« kdy: 08. 12. 2021, 03:11:04 »

Ahojte myslíte si, že je aspoň teoreticky možné cestovať späť v čase? Pýtam sa teraz ako čistý laik, tak ma prosím nekamenujte.
Vieme o tom, že cestovanie do budúcnosti by teoreticky možné bolo, cestovanie do budúcnosti sa teda aj občas deje, keďže čas je relatívny, žiaľ tie drobné časové rozdiely dokážeme odmerať len atómovými hodinami...

Ale čo cestovanie do minulosti? Žiadne častice (okrem hypotetických tachyónov) nedokážu prekonať rýchlosť svetla. To znamená, že týmto spôsobom sa do histórie asi nikdy nepozrieme. Ale existujú aj nejaké iné spôsoby? Viem, že v kvantovej fyzike, by mohol byť (na úrovni mikročastíc) priestor aj pre cestovanie v čase, ale priznám sa, že moc tomu nerozumiem.
No veľmi ma baví história a strašne sa túžim pozrieť do minulosti. Chcel by som na vlastnej koži zažiť koniec 18teho storočia, keď začalo osvietenstvo, 7 ročná vojna, keď vypukla francúzka revolúcia a americká vojna za nezávislosť, tiež ma fascinujú napoleónske vojny, romantizmus, Britský a Francúzky imerializmus, objavy, prvá éra globalizácie z konca 19teho storočia a vlastne celé 19te storočie, veľmi  by som chcel vidieť aj 20te roky 20teho storočia a často si hovorím, že by som tú dobu chcel zažiť aspoň na týždeň.
Som si istý, že za mojho života je cestovanie do minulosti nereálne. Ale čo v ďalekej budúcnosti, keď naše technológie pokročia? Myslíte, že bude niekedy možné presunúť človeka smerom spať v čase? A ak áno tak ako?
Podľa mňa by cestovanie do minulosti nemuselo narušiť časo-priestrové kontinuum, myslím si, že tých paralelných realít vedľa seba koexistuje nekonečne veľa a každá z nich sa vyvýja trošku iným spôsobom a keby sme sa presunuli do minulosti, tak sa tým presunieme iba do inej reality. Takže nám nehrozí niečo také ako "dedkov paradox".

Velmi ti rozumím. Mám stejné touhy.

Co se týče reálnosti: s největší pravděpodobností to principielně nejde (pokud dobře chápu teorii).

Podle některých teorií, je čas definován jako důsledek entropie. Tedy, to, že čas se pohybuje přísně jedním směrem je důsledkem toho, že entropie je též jednosměrná. Lze to zpomalit, téměř zastavit, ale nelze to otočit.

Co se týče paradoxů a podobně, to jsou nepodstatné věci vhodné jen do románů a filmů. V reálu to nehraje roli.

237

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 19:11:01 »

Snapshotum se obloukem vyhybam...

V leiningenu myslim muzu pouzivat version ranges... ale je u toho nejaky warning, ze se to nema delat....

Uváděl jsem příklad na generování kódu. Zda je to dobrý nápad řešit verzování a závislosti knihoven takhle nebo jinak, to je už trochu jinej příběh. :-)

238

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 18:25:35 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného

Mel bys nejakej netrivialni priklad 2?

Příklad 3: VisualStudio má návrháře UI. Můžeš si tam naklikat, natahat, naarangovat elementy. Ty se potom zapíšou do souboru. Buď do C#, nebo do XAML. V případě XAML se tento ještě zpracovává do výsledného něčeho. C# je part třída, kde máš jednu část, kterou má na starost návrhář, a druhou část, kterou používáš ty jako vývojář pro vlastní opičárny. Když hrábneš do té návrhářské třídy, tak pokud to nepřeženeš, tak se to zpětně promítne do toho návrháře. Osvědčilo se mi do té návrhářské třídy koukat. Lépe si všimnu, že jsem udělal nějakou nepravost. Nebo naopak, při přejmenování nějakého elementu, se přejmenuje i tady a návrhář to v pohodě zkousne.

Hmmm s tim sem nikdy nedelal.
Pamatuju si nejaky takovy udelatko pro Qt a jestli se nepletu tak tam se to do jednoho souboru nemotalo.
Tam byl snad v tom navrhari nejaky dialog pro event binding nebo co... to se mi zda lepsi.
Navic vystup z toho snad bylo nejaky xml a ne primo trida v cilovem jazyce.
Ale kdo vi... uz je to davno

Navic tady jsme trochu dal od generovani neceho ze schematu.
Tady "programator" "programuje". Sice tahanim nejakejch policek po formulari, ale to je jedno... to ze existuje kod a jeho visualni reprezentace je v poradku. Je to jedinny "zdroj pravdy" tak je v poradku ze to commitnu.

Já jsem se nebavil o generování ze schematu. Já jsem obhajoval "generovat kód vždy a všude" v opozici ke "generování kódu je zlo" :-)

Graf si sice muzu vygenerovat ale nikam ho nekomitnu, protoze to stejne pri buildu nikdo nepouzije.

Graf ne, ale informace o těch konkrétních závislostech ano. Chceš tři balíčky s nějakou cca verzí - dostaneš jich stovku s konkrétní verzí. Zkontroluješ, zda všechno funguje a tím, že to commitneš (tu stovku balíčků se specifickými závislostmy) tak uděláš schválení, že takto je to správně.

to fakt v mavenu ani v leiningenu nedelam... A nebo te porad spatne chapu.

Zavisim na balicku A:1.2.3 co zavisi na X, Y, Z.
Y zavisi na P ve verzi 3.14 a ten ma bug.
Moje zavislosti budou:

• P:3.1415 kde uz vim ze je bug opraven a
• A

Maven sam spravne dotahne i X, Y, a Z a P tam budu mit ve verzi 3.1415

ale kdyz se podivam do repositare nikde nenajdu ani zminku o X, Y a Z

OK, Maven to dělá jinak, v pořádku.

Možná jde o to, že u Composeru (a nejen u něj), balíček nezávisí na konkrétní verzi. Takže když by byla vydána nová verze nějakého balíčku, tak by se mohlo stát, že se tam stáhne ona. A to pochopitelně nechci.
Jak to dělá Maven netuším, ale předpokládám, že je tam nějaká chytristika, aby po konfiguraci bylo zaručeno, že se vždy vytvoří stejný graf.

239

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 18:02:07 »

Graf si sice muzu vygenerovat ale nikam ho nekomitnu, protoze to stejne pri buildu nikdo nepouzije.

Graf ne, ale informace o těch konkrétních závislostech ano. Chceš tři balíčky s nějakou cca verzí - dostaneš jich stovku s konkrétní verzí. Zkontroluješ, zda všechno funguje a tím, že to commitneš (tu stovku balíčků se specifickými závislostmy) tak uděláš schválení, že takto je to správně.

240

Vývoj / Re:Rust - std::ANY alebo lepší návrh?

« kdy: 02. 12. 2021, 17:43:03 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného

Mel bys nejakej netrivialni priklad 2?

Příklad 3: VisualStudio má návrháře UI. Můžeš si tam naklikat, natahat, naarangovat elementy. Ty se potom zapíšou do souboru. Buď do C#, nebo do XAML. V případě XAML se tento ještě zpracovává do výsledného něčeho. C# je part třída, kde máš jednu část, kterou má na starost návrhář, a druhou část, kterou používáš ty jako vývojář pro vlastní opičárny. Když hrábneš do té návrhářské třídy, tak pokud to nepřeženeš, tak se to zpětně promítne do toho návrháře. Osvědčilo se mi do té návrhářské třídy koukat. Lépe si všimnu, že jsem udělal nějakou nepravost. Nebo naopak, při přejmenování nějakého elementu, se přejmenuje i tady a návrhář to v pohodě zkousne.