Příspěvky

181

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 29. 01. 2022, 16:27:48 »

...a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu...

Má to nějaký jasně daný směr (resp. byl by odkaz na něco co už funguje)?

Zcela obecně - existují nějaké velké GUI frameworky - zejména Qt a Gtk+, za nimi o něco méně významné Fltk a wxWidgets. S Qt je potíž, jelikož je to psané na míru C++ a jeho OOP vlastnostem. Výborně to funguje ve spojení třeba s Pythonem, kde je velká míra kompatibility OOP modelu - násobná dědičnost apod. Celkem blbě to funguje u výrazně jiných jazyků, jako je třeba Haskell nebo Rust. Jo, pořád se na tom dělá a třeba to nějak ti lidi dopilují.

Gtk je psané v C a bindingy pro ostatní jazyky včetně Rustu se dělají poměrně snadno.

Fltk zblízka neznám, přijde mi primitivnější, ale to může být i výhoda. Bindingy jsou aktivně vyvíjené, na rozdíl třeba od wxWidgets.

Pak existují specialitky jako druid, Orbtk a egui. Podle mě to je všechno zatím spíš hračka, ale možná se něco změnilo.

Doporučuju zaměřit se na relm, resp. gtk-rs, to jsou IMO nejvymakanější a nejpoužívanější řešení pro Rust. V prvním případě pokud chceš mít vše definované programově a idiomaticky. Ve druhém případě si můžeš UI naklikat v Glade, ale spíš tíhnu k Relmu. BTW existuje verze i pro Gtk+ 4 (relm4).

Svět GUI je roztříštěný všude, ale zvlášť v Rustu mi to Gtk+, resp. spíš Relm přijde jako jasná volba.

182

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 29. 01. 2022, 08:57:16 »

Nebo nom, který se zbavil před pár lety podle mě docela matoucích maker a přešel na funkce.

Ještě upřesnění - ve verzi 5 přepracoval vnitřek na funkce, makra zůstala a ty funkce vnitřně používala a loňská verze 7 se maker zbavila úplně. Pokud se něco zásadního nezměnilo, hodilo by se zamakat na tutoriálech, ale knihovna jako taková je vyřešená.

183

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 29. 01. 2022, 08:32:12 »

Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční, zatímco si propagátoři leštěj ego na turbofish operátoru a jiných libůstkách. Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.

Já si nemyslím, že na to "všichni kašlou". Pracuje se na všem možném a najednou. V poslední době mě potěšilo víc věcí - např. vydání produkční verze clap 3 (minor verze vychází snad obden a ubývá tam oprav chyb, takže mi přijde, že už to je dost stabilní a že ten release byl dobře načasovaný) a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu, co se týče použitelnosti v různých oblastech. Nebo nom, který se zbavil před pár lety podle mě docela matoucích maker a přešel na funkce.

184

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 29. 01. 2022, 08:25:31 »

Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.

Pokud myslíš ekosysystém, jako tools, tak ten mi přijde fantastický. Pokud myslíš ekosystém, jako knihovny třetích stran, tak za to autoři jazyka dost dobře nemůžou. A nepřijde mi to tak hrozné.

Hrozné to není, pouze nepříjemné a budí to nedůvěru. Typicky se v diskusích uvádí rand jako příklad crate, kterou potřebují skoro všichni a pořád je ještě ve verzi 0.8.x. Kdyby neměl Rust rozumnou podporu závislostí, mohl by to být i technický problém, ne jen mentální, ale neradno ho podceňovat.

Zase je otázka, co by se stalo, kdyby nějaká podfinancovaná knihovna měla závažnou chybu a ohrozilo by to všechny závislé produkty. IMO by se hodilo udělat velkou akci a zapracovat na auditu a případné stabilizaci zásadních crates. Ale teď které to jsou, že...

185

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 29. 01. 2022, 08:19:59 »

Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční

To ukáže čas Překladač i knihovny se momentálně živelně vyvíjí, ale v dohledné době se snad stabilizují a rozšíří. Podle mě má Rust našlápnuto slušně. C++ si s sebou z minulosti nese několik WTF, což Rustu docela nahrává. Ale křišťálovou kouli nemáme nikdo.

Přiznám se, že mi ty 0.x verze taky vadí, ale podle mě to chce vzít případ od případu a zkoumat motivaci. Třeba někdo na sémantické verzování někdo neřeší nebo se bojí udržovat zpětnou kompatibilitu. Podle mě to je otázka času; zažili jsme to v Pythonu - do nějaké doby se většina držela verze 2 a do trojky se nikomu moc nechtělo a pak se to přehouplo a kdo váhal s přechodem na trojku, byl pomalu za hňupa.

186

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

« kdy: 27. 01. 2022, 09:10:59 »

Nic z toho mi nepřijde jenom dynamické nebo jenom statické. Možná špatný příklady, možná omezený rozhled. Pravděpodobně špatné pojmenování věci?
Byl by si schopen uvést nějaký demonstrativní příklad? Co si mám představit co vidíš, když mluvíš o dynamickém typovaní? A jak jde statické a dynamické kombinovat?

Dynamic_Predicate prisne vzato neresi typ v tom smyslu, jak ho zname v beznych jazycich, ale pouze constraints (neco jako kontrakt?) Aspon tak tomu rozumim ja:

http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html

Nic, co by neresil treba assert v konstruktoru, nebo?

187

Studium a uplatnění / Re:Naštvaný tým - oprávněně?

« kdy: 27. 01. 2022, 09:01:05 »

Takže je to na tazately, zohledni si love vs životní styl a pokud ti to nevyhovuje prostě se začni rozhlížet po nové práci, ve které můžeš pracovat méně nebo více, a brát méně nebo více love.

S velkou pravdepodobnosti firma, ktera jede permanentne "na prescasech", kdovijak dobre neplati.

188

Studium a uplatnění / Re:Otázky pro junior webdev backend vývojáře

« kdy: 26. 01. 2022, 16:13:15 »

Především se nesmíš prezentovat jako mimoň. Buď v pohodě, přijď čistě a pokud možno slušně oblečený a nedělej ze sebe, co nejsi. Ukaž, že se zajímáš o obor, co jsi zkoušel a nastudoval, že se nebojíš práce a dalšího rozvoje.

Pokud s tímhle půjdeš do normální firmy jako junior, máš šanci uspět. Mimochodem, pokud bude protistrana působit jako namachrovaní kreténi, pravděpodobně tam pracovat stejně nechceš.

189

Vývoj / Re:Je „responsivní“ design až zase tak potřebný?

« kdy: 26. 01. 2022, 16:09:08 »

Dej příklad, kde to dobře nefunguje. Já na mobilu moc nenakupuju, ale když jsem se teď podíval na pár českých obchodů, mobilní verze byla v pohodě. Pokud tomu tak je, rozhodně preferuju design uzpůsobený pro mobilní zařízení (to nemusí znamenat responzivní, může mít dva oddělené weby pro mobil a desktop).

Co se týče tabletu, zvlášť pokud má 10", tam už desktopová verze sedí víc než na mobilu. Přesto si myslím, že dobrý responzivní design je ideál.

190

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

« kdy: 25. 01. 2022, 17:05:22 »

Mohl bych třeba namítnout, že tyhle věci by programátor nějak obsáhnout mohl a že ta taxonomie se nějak dělat musela. Co mi přijde ale zásadnější, je že bool by se do této situace v rozumně psaném kódu neměl nikdy dostat - už podle názvů proměnných by mělo být jasné, co je číslo (počet) a co je bool.

Tahle situace nastane úplně hravě. Stačí třeba omylem přehodit parametry funkce o pár úrovní zanoření výš. V dynamicky typovaném jazyce z názvu parametru nezjistím, co je uvnitř, protože to přišlo zvenku. Slabé typování k tomu  pak přidá bonusové WTF, kdy taková situace neskončí chybou ani v runtime, ale tichou a nenápadnou konverzí na totální nesmysl.

Tohle je ale obecný problém. Mám tři parametry typu int, prohodím je a sčítám hrušky s jablky. Jak píše Idris, type alias s nutností explicitního castu tohle celkem řeší, pokud ovšem všechny tři parametry nejsou typu "cena v Kč"...

Úplně stejně blbá situace v Pythonu (a jiných jazycích) nastane, když se číselná konstanta z jedné množiny pošle do proměnné, kde má být jiná množina povolených konstant. A enum to taky nezachrání, to by se k němu musel Python chovat jinak.

191

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

« kdy: 25. 01. 2022, 15:35:20 »

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

Bool je teda dost pochybný celočíselný typ. Problém není v tom, že by to chování nebylo přiznané v dokumentaci, ale v tom že většina programátorů dokumentaci nemá našprtanou. Každá věc, kterou je třeba přiznat v dokumentaci, je potenciální past.
Ukažte mi programátora, který kompletně pročetl veškerou dokumentaci, než začal nějaký jazyk používat. Do dokumentace se leze až ve chvílí, kdy si člověk uvědomí, že něco neví.

Mohl bych třeba namítnout, že tyhle věci by programátor nějak obsáhnout mohl a že ta taxonomie se nějak dělat musela. Co mi přijde ale zásadnější, je že bool by se do této situace v rozumně psaném kódu neměl nikdy dostat - už podle názvů proměnných by mělo být jasné, co je číslo (počet) a co je bool. Jasně, vzhledem k výše napsanému bych osobně bool fakt úplně vyloučil z kolektivu a nedovolil ani srovnávání ani sčítání s ostatními objekty. Ale to už se zas z opačné strany dostáváme k tomu, že Guido a spol. nikdy neměli nechat ostatní typy objektů, aby boolu lezly do zelí. Tam je ten zásadní problém a vždycky bude, pokud tohle nějak nepořeší třeba Python 4.

192

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

« kdy: 25. 01. 2022, 13:18:57 »

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

Já třeba vidím zásadní rozdíl v tom, jestli nějakému stringu můžu dát metodu append co bere int (nebo i nějakou generickou verzi) a v tom, že ten int na string zkouší konvertovat překladač.
V prvním případě dá programátor takové všežravé operace jen tam, kde dávají smysl. Ve druhém případě to překladač zkouší všude. Je zásadní rozdíl, pokud se taková konverze děje při konkatenaci stringů, nebo třeba při otevírání souboru.

Implicitní konverze mají nepříjemnou tendenci dít se tam, kde je nikdo nečeká. Respektive čeká je jen guru daného jazyka, kterého už X-krát nepříjemně překvapily.

Zcela zásadní nectnost Pythonu (z mého hlediska) je, že neudělali boolovský typ v podmínkách exkluzivní. Že umožnili podmínky typu if (x), kde x může být číslo, řetězec, kontejner nebo jakýkoli jiný objekt (když nemá __bool__ nebo __len__(), bere se jako True), je podle mě chyba návrhu.

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

193

Vývoj / Re:Ma smysl vyrabet vlastni eshop?

« kdy: 24. 01. 2022, 12:32:55 »

Ze si nekdo vyrabi eshop, to uz je takova klasika, a vzdycky se nekdo ozve (Jirsak zejmena), ze proboha proc nekdo nejaky dalsi vyrabi.

A tak je tady moje otazka. Dival jsem se na ceniky a zakladni eshop, ktery neumi zadne  pokrocile filtrovani (jako treba CZC.cz), umi jen Search, Kategorie a Sorting, stoji nejakych priblizne 5000,- Kc rocne.

Zda se, ze tedy nestoji za to, vyrabet si svuj eshop. Nebo to ma nejaky vyhody udelat si svuj?

Až budeš CZC, možná se vyplatí mít vlastní SW šitý na míru.

194

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

« kdy: 24. 01. 2022, 12:06:25 »

…

BTW možná to zapadlo, ale Rustu ten jazyk nijak nekonkuruje, je náhradou za R, Matlab a Python, těžko v něm někdo bude psát třeba mikroslužby nebo dokonce něco systémového (ani neumí vytvářet pořádné samostatné binárky). Mě osobně zajímají jen čistě technické aspekty překladu a optimalizace kódu. S Rustem se oblasti nasazení prolínají třeba u věci jako je Egg a dost často bude lepší napsat prostě všechno v Rustu kvůli například kontejnerizaci apod. Ale v oblasti tzv. vědeckých výpočtů jsou priority, proč si to nepřiznat, úplně jinde (kdysi kdosi se tam snažil prosadit Swift, ale asi se moc neuchytil).

Jasně, message received. A dík i za předchozí příspěvek.

195

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

« kdy: 24. 01. 2022, 11:23:17 »

Každopádně mě teda to Tvoje tvrzení o rychlejší Julii nadále dráždí, asi si to někdy prozkoumám.

To je vidět Ale taky tě dráždí, že je Porsche rychlejší než kombajn? Je to prostě empiricky podložený fakt, mě to taky překvapuje a sám to “prozkoumávám”, což jde celkem lehce, protože oba překladače používají LLVM. Určitě znáš rustí Egg, který, pamatuji-li se dobře, vyhrál (resp. jeho design) i nějaké ceny na akademických konferencích. Tak stejný algoritmus pro e-grafy je v Julii rychlejší

1. Rust není kombajn, Rust je jazyk, který by z principu měl být jeden z nejrychlejších, co se běhu týče. Pokud někdy není, je někde prostor pro zlepšení. Je samozřejmě otázka, o kolik ten konkrétní use case je rychlejší.

2. Tu Tvoji empirii nevyvracím, ale když to zkouším googlit, moc vodítek nebo důkazů nenacházím.

3. Egg neznám, natož abych mohl konkrétní implementaci toho algoritmu rychle srovnat s implementací v Julii a něco z toho vyvodit. Ale dík aspoň za tenhle hint. Pokud máš něco dalšího, čeho se chytit, byl bych docela rád.