Příspěvky

31

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 08:45:22 »

Připomnělo mi to "Execution in the Kingdom of Nouns".

To jsem neznal. Vtipnej článek. Zbytečně dlouhej a sem tam bych s něčím polemizoval, ale rozhodně vtipně napsanej.

Trochu mi tam chybí speciální rant proti *Factory:

Kód: [Vybrat]

GarbageDisposalStrategyFactory.create(StandardGarbageDisposalStrategyOptions()).run()

Ty facilitátory mi factories silně připomínají... Až bych skoro řekl, že to jsou ony, jenom jim to bylo trapný tak pojmenovat, aby se jim každej nesmál, že znovuobjevili Javu

Mě tam ty explicitně zmíněné továrny ani nechybí. Továrna mi přijde jen jako jeden druh dělače, proti kterým tam brojí obecně. A i ty příklady facilitátorů, na které jsem narazil, byli jiní dělači než továrny.

Ona tam ta podobnost s Javou bude. Mám pocit, že návrh Javy vychází z podobných úvah jako tohle:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

V tomhle stylu myšlení vidím asi nejpodstatnější rozdíl mezi C++ a Go.

32

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 07:03:03 »

facilitátory, to je — aspoň pro mě — novum

...a další narovnávák na vohýbák

Připomnělo mi to "Execution in the Kingdom of Nouns".

33

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 10. 02. 2022, 09:00:28 »

Go je holt jazyk, který si Google navrhl přesně pro své potřeby a podmínky. A ty jsou ve spoustě případů dost specifické.

To možná platí pro některá strategická rozhodnutí ohledně celkového směřování, ale u spousty věcí bych to spíš tipoval na Pikeův svéráz (stačí se kouknout na Plan9 a člověk už trochu tuší...). Například to, že v jazyce pořád drží ujetý systém šablonového generování zdrojáků místo aby zavedli pořádný makra, rozhodně není nějakou "specifičností Googlu"... A takových příkladů je spousta.

Já mám právě pocit, že spousta toho svérázu mu prošla právě díky prostředí googlu. Např. to, že lidé kteří mají pravomoce pravděpodobně negenerují zdrojáky šablonovacím ale ticketovacím systémem.
A taky jsem už zaslechl pár zkazek, že znovuobjevování kola je tam takřka součást firemní kultury.

34

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 10. 02. 2022, 07:18:26 »

P.S. V žádné případě, ani náhodou, bych Go necharakterizoval jako jazyk, který "tě zbytečně neomezuje". IMHO je to přesně naopak: autoři jsou velmi tvrdohlaví ("opinionated", chce-li kdo) a jazyk obsahuje právě spoustu úplně dementních (z pohledu uživatele) omezení. Go je takové velmi úzce nalajnované hřiště. Když to člověk ví a akceptuje, v tom uzounkém hřišti se hraje relativně dobře. Ale člověk má neustále někde pocit, že mu byla přistřižena křídla (popř. uříznuty ruce ). Autoři tvrdí, že velmi pečlivě zvolili, kde budou řezat a že je to geniální volba pro dobro uživatele. V mnoha případech si tím nejsem ani trochu jist stejně jako oni

Go je holt jazyk, který si Google navrhl přesně pro své potřeby a podmínky. A ty jsou ve spoustě případů dost specifické.

35

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 09. 02. 2022, 20:52:13 »

A taky ten kód bude bezpečnější, v Go se člověk musí hodně snažit, aby něco fest podělal.

A jen tak mimochodem, věci kde se něco může fest podělat se obvykle píšou v MISRA nebo AUTOSAR C(++). Tam, kde o něco opravdu jde, je Go nepoužitelné protože Google vůbec nic negarantuje.

36

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 09. 02. 2022, 18:13:58 »

tohle je (bohuzel) nejpresnejsi vec v tomhle vlakne

ja to chapu s tou javou, i s rustem to chapu.
ale ted me v dotazu zajimal jen golang nebo c++1x, potvrdil se mi nazor, ze go je lehci cesta z c.

Opravdu má cenu porovnávat, která cesta je lehčí, když vede každá jinam?

tak oboje vede k vyvoji software a muzu juniorovi nabidnout go misto c++1x a bude rychleji produktivni.

Tak pokud je cílem prostě vývoj software bez dalšího upřesnění, tak je Go i C++ špatný nápad. A opravdu bych se zamyslel třeba nad tou Javou, kde je podstatně víc pracovních příležitostí.

37

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 09. 02. 2022, 15:35:55 »

tohle je (bohuzel) nejpresnejsi vec v tomhle vlakne

ja to chapu s tou javou, i s rustem to chapu.
ale ted me v dotazu zajimal jen golang nebo c++1x, potvrdil se mi nazor, ze go je lehci cesta z c.

Opravdu má cenu porovnávat, která cesta je lehčí, když vede každá jinam?

38

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 09. 02. 2022, 10:56:51 »

Když zná dobře Javu, tak Javu, ne? Zvlášť když neví co chce, do korporátu zapadne bezvadně...

zkus jen odpovedet, z C radeji na Go, nebo radeji na C++17, dik. jako pri hlasovani, losna nebo maznak :-)

Tak to bych nejspíš doporučil Bahňáka.

39

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 09. 02. 2022, 10:49:51 »

ruzne jazyky se tu uz probiraly, ale dotaz ted zni nasledovne.
osoba zna dobre C, Javu a vi i o C++98.
osoba se dale muze vydat cestou zmeny
a soustredit se vice na GOlang nebo C++11, 14, 17.
ja bych doporucil spise GOlang, co vy byste doporucili? s ohledem na rychlost zapracovani se, na jednoduchost, na dostupne pracovni pozice.

To záleží na tom, co chce osoba dělat. Go a C++ se hodí na dost odlišné věci. Tam kde jde o nízkou latenci (hry, automatizované obchodování, embedded) kraluje C++. Go se uchytilo spíš na webovém backendu a podobně.

C++ rozhodně není jednoduché na naučení. Takže jde o to, jestli chce dělat věci ke kterým ho bude potřebovat.

40

Odkladiště / Re:Zdielanie hesiel v rodine

« kdy: 08. 02. 2022, 14:57:09 »

Zacal som tak premyslat, ako zdielat hesla, aby boli pristupne napr. pre moju manzelku/deti, v pripade ak by sa mi nieco stalo. Myslim si, ze nie je na skodu veci, ak manzel/ka maju pristup v takom pripade. Ci uz internet banking, bankomatova karta. Popripade pristup na mail. Ja som niektore hesla spisal na papier, ale neviem ci je to zrovna dobra a bezpecna forma. Riesili ste nieco podobne?

A proč to ženě prostě neříct? Věci, které ženě neříkám teď, si stejně beru sebou do truhly.

41

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

« kdy: 07. 02. 2022, 16:10:12 »

Asi tak, u nas zavedenim iba pribudla administrativa, nic sa nezlepsilo. ... atd, pribudlo plno dodatocnej administrativy, okrem ktorej si treba samozrejme robit svoju robotiu.

Evidentne to u vas "zavedli", aby si nekdo udelal carku a dostal premie. Ale evidentne to co mate neni opravdovy agile.

Tak nejak to je. Ked do managementu pridu novi ludia a zistia ze vlastne nemaju co robit, lebo po odbornej stranke sa nevyznaju v tom co sa robi, tak zavedu agile aby zvysili svoju dolezitost a aby mali cinnost ktoru mozu dlhodobo vykazovat.

Tak v té původní nezmršené podobě jsou principy agilního vývoje rozumné. Protože to vůbec není nějaká metodika, ale jen velice obecné myšlenky. Bohužel to nepříjemně často končí až perverzním převrácením naopak. Pár stránek zpět tu Kopalson zmínil něco jako že co lidi jsou schopni a ochotni se domluvit, nic takového nepotřebují. Jenže to je přesně ta původní myšlenka - "Individuals and interactions over processes and tools".
Pak záleží spíš na tom, jestli se sledují původní vágní principy, nebo puntičkářsky buduje cargokult.

42

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

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

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.

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.

43

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

« kdy: 25. 01. 2022, 15:29:18 »

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.

OK, jenže v tom vidím určitý problém. Jak jsem psal zde: "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."

Můžete oprávněně namítnout, že mám nízké požadavky a dám vám za pravdu. Ale Idris tady tvrdil, že než statické verzus dynamické, to je mnohem zásadnějším rozdílem silné verzus slabé. A to mi přijde moc divokej matroš.

Tak jak teda?

Je teda silné verzus slabé "jen" o vhodném/nevhodném samo konvertování, nebo je v tom víc?

Pokud je tohle jen "programátorský prožitek", tak se všechny výpočetně úplné jazyky liší jen v tom prožitku. Ty kategorie silný/slabý jsou samozřejmě neostré, ale to je jakákoliv klasifikace.

Jestli je důležitější rozdíl silný/slabý nebo statický/dynamický netuším. Obojí přináší dost znatelné důsledky. A ano, esence toho slabého typování jsou IMO ty automatické konverze.

44

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

« kdy: 25. 01. 2022, 13:45:39 »

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.

Souhlas, hlavně to chybějící _bool_ je solidní past.

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í.

45

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

« kdy: 25. 01. 2022, 12:59:22 »

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.