Vlákno názorů k článku Statické typové kontroly zdrojových kódů Pythonu prováděné nástrojem Mypy od robot0001 - Ja uz si pockam na Mojo https://www.modular.com/mojo https://youtu.be/pdJQ8iVTwj8 Cilem je kompletni...

Vím, to ale neznamená, že nový kód budete psát ve FORTRANu. Pak Hanyk na MFF nám ukazoval jak hezky přepsat FORTRAN 77 do moderního. Co funguje na to nesahám, co potřebuje častěji změny, to už radši pomalu modernizovat.Já docela sleduji fortran-lang, abyste se tady nevlamoval do otevřených dveří.

15. 6. 2023, 17:05 editováno autorem komentáře

jj co funguje nechat a kdyztak to pomalu modernizovat

To se snadno řekne :)

Však jasně, důchodci byli šíleně produktivní.

tak to jsem asi jeste nevidel (myslim tu IV), ale kod pro 77 je stale pouzivan. v podstate se na to nesaha, max. se to prelozi pro novou platformu a jede to dal (a okolo se potom tvori filtry na soubory, co to zere nebo naopak z toho vypadavaji)

Mojo umoznuje oboji - GC i non GC

Asi myslíš tracing GC? Mojo má sice borrow checking, ale obecně tracing GC v kombinaci s escape analýzou zajistí stejnou rychlost jako manuální správa, drahé jsou alokace a uvolnění, což se dělá vždy. Tracing GC je akorát nedeterministické a má vyšší memory footprint, v rychlosti horší není.

Vždyť to je vidět přímo z jejich příkladů.

Něco mají navíc, něco nemají vůbec. Až naimplementují algebraické typy, bude to zajímavější.

Jsi si jistý, že víš, co to jsou algebraické typy?

Jsem si jistý, že vím, čemu tak říkají: https://github.com/modularml/mojo/issues/43#issuecomment-1537335417

No vidíš, tak součtové typy bychom měli a teď mi řekni, kdy bude Rust podporovat Vector<T, N> pro nekonstantní N, jinak nemá smysl ho vůbec porovnávat s Mojo.

Obsese jednou konkrétní vlastností není myslím moudrá. Rust není dynamický jazyk a tohle je pro většinu lidí neproblém.

Tohle jde právě kontrolovat staticky.

Pokud je to nekonstantní (délka známa až za běhu), tak jak?

Nevím, jestli to jde jednoduše vysvětlit. Dělá se to přes induktivní definice. Pak jde mít třeba

append : Vect t n -> Vect t m -> Vect t (n+m)

s n, m neznámými v době překladu. Asi by to chtělo příklad, ale teď nejsem u počítače.

OK, ale pokud jde (jak předpokládám) o nějaký konstantní výraz, stačilo by v Rustu nějaké makro, ne?

NEJDE o konstantní výraz, n a m jsou parametry typu, které můžou přijít například od uživatele za běhu.

Pak to prostě nejde dělat staticky, ten typ to kontroluje za běhu někde uvnitř.

To je tvoje základní neznalost, jde to dělat staticky (kontrola probíhá při překladu v rámci typové kontroly). A v některých jazycích to je implementované, takže máš několik důkazů k prostudování.

Kontrola velikosti, kterou nikdo v době překladu nezná?

Kontrola typové korektnosti (a potažmo absence chyb za běhu). Si to zkus, David Thrane Christiansen nedávno dopsal (e-)knihu o Leanu 4.

A proto jsem tu onehdá prohlašoval že dynamické typování je neexistující koncept. To názvosloví strašně mate, a každý si pod tím představuje něco jiného.

Jinak, když se vám tu pletu, taky si myslím, že jen to pro většinu lidí neproblém. Bohužel. Vzhledem k tomu, že spousta profesionálních programátorů netuší, k čemu jsou už jen typy, tak chtěj po nich aby uměli ocenit něco takového.

To je fakt, chápe to strašně málo lidí, proto furt dokola slyšíme “nejde to”, i když to jde, akorát to není triviální.

tak typový systém má být kromě dalších věcí i praktický. to že něco teoreticky jde, ale v praxi tomu nikdo nebude rozumět, to dopadne jako Haskell (nebo OCaml, což me mrzí ještě víc). IMHO jde najít průnik mezi dostatečně silným systémem, systémem praktickým a současně i dostatečně "univerzálním" (to je špatný překlad slova sound, omlouvám se)

Formální verifikace je nadmíru praktická. Ty pokročilé vlastnosti a konstrukce, které běžný vývojář (třeba Ink, jak nám tu sám přiznal) nechápe, se beztak používají hlavně v knihovnách, aplikační kód se píše jednodušeji, už jen kvůli čitelnosti. U typových systémů se formálně (teoreticky) silný a praktický nevylučují, spíše naopak.

BTW OCaml je na dobré cestě k lepšímu překladači. Haskell nekomentuji, ten má tolik volitelných rozšíření, že už jsem ztratil přehled.

Hele, nevyrypuj a nemanipuluj, Calculone, je to trapné. Já mám dostatečně bujnou představivost, abych si tyhle legrácky vec<T; m+n> dovedl představit. Jenže mi to přijde jako natolik málo užitečné, že to jako měřítko fakt neberu. Navíc kdybych chtěl vyjádřit nějakou funkci, která ze dvou polí udělá jedno o správné délce, udělám to makrem. A dělat tuhle verifikaci na takovéto knihovně je dost zbytečná věc. Tyhle věci buď fungují nebo nefungují a pozná se to prakticky okamžitě.

Podle toho, co furt píšeš, vůbec nevíš, o co jde. BoneFlute ti to třeba vysvětlí, ten je tu z ostatních asi jediný, kdo ví, o čem je řeč. Ty ses zasekl u algebraických typů, zkus třeba nejdříve GADT (Rust je nemá, ale například Scala a OCaml ano) a až je pobereš, budeš zase o krok blíž. Pokud teda chceš, se sebevzděláváním ti nikdo nepomůže, kdy sám nechceš.

Opět ty Tvoje snobské řeči. O existenci GADT vím, jenže Scalu ani OCaml nepoužívám a nechystám se. A pokud to bude v Rustu, je otázka, kdy to skutečně budu skutečně potřebovat. Zatím nemá Mojo ani sum types, jenom je plánuje.

O tom žádná. Jenže víš, co si většina programátorů představí pod pojmem praktické typy? Třídu. Bez konstruktoru, samozřejmě. A všechny property string.

Pak je dlouho dlouho nic, než se začnou objevovat jedinci kterým začne docházet, že typy jsou v prvé řadě o zárukách. Aby si přesunul práci ze strany programátora na bedra stroje. No, a víš kde je naopak hodně lidí co těm typům a zárukám rozumí? V matematice a fyzice.

A protože máme těch dva a půl programátora, pro které jsou silné typy, proto ty jazyky vypadaj jak vypadaj. A protože všichni matematici a fyzici jsou ještě horší evangelisti jako programátoři, proto je taková práce přijít s něčím revolučním do mainstramu. Není poptávka, není osvěta. Je to naprd.

Jo, tos vystih. On už jen Haskell je jen pro hrstku, a to jsme s typama ještě vůbec nezačali :)

Muzes prosim rozvest to "Třídu. Bez konstruktoru, samozřejmě. A všechny property string."? To strasne zni jako nejaka Perlovina, protoze ani ti spatni Java a spol. develove to snad takto nemysli? (kdyz uz jim jazyk nejaky typy vnutil mimo to zneuzivane schema Class-OOP)

Javista vytvoří třídu, přidá private propery (sic) a na každý getter a setter. Bez konstruktoru.
C#pista to má ještě jednodužší. Tam je na to syntaktický cukr, tak nemusí psát settery.

Tady nejde o to, že bych se jim chtěl posmívat. Jde o to, že se to nikde neučí. Že to ti lidé neví. Dokonce jsem se setkal s reakcí, kdy ten vývojář/kolega na mé poznámky přitakal, že je to asi blbě, ale vlastně netušil proč a v čem.

Pracovat v Javě, nebo v C# s rozhraním? Ano. Proč a k čemu? Netuší.

Schází pořádná osvěta, jaké benefity typy přináší. Setkal jsem se s tvrzením, že je to hlavně kvůli výkonnostním optimalizaci :facepalm:. Evegreen, že dědičnost je kvůli reusable kódu :doublefacepalm:. A tak.

To by bylo na dlouhou diskuzi, která by stejně nikam nevedla. Jedem das seine.

Když jsem byl malé programárče, tak jsem udělal kód a dal ho k review kolegovi. Ten si přisedl a kouká na to a ptá se:
- OK, a proč jsi udělal toto takhle?
- A toto tady, proč jsi to přesunul?
- A toto, proč jsi neudělal takhle?
- Proč jsi zvolil A a neudělal to pomocí B? Jako, možná dobrý, jiná škola, proč ne, vysvětli mi to prosím?

Zvlášť ten výraz "jiná škola" mi hodně utkvěl v paměti.

17. 6. 2023, 14:46 editováno autorem komentáře

Jo, takhle je nejlepší učit se od sebe navzájem. Čím víc pohledů, tím větší nadhled.

A taky cargokult.
Nevím. Nemyslím si, že to funguje. Navíc programátoři jsou strašně egoistická cháska.

jo diky to dava smysl (tedy jako "chapu, ze to tak nekteri delaji). Proste takova struktura/record, akorat je okolo toho mega ceremonie a s typy jako takovymi to zase moc spolecneho nema.

btw se o tom mluvi i tady
https://www.youtube.com/watch?v=Tml94je2edk

a jinak tento styl - nemit konstruktor, ale settery, je dost cesta do pekla z hlediska navrhu aplikace, jeji testovatelnosti atd. Kdyz uz, tak idealne mit prave ten konstruktor (klidne pretizenej) a immutable objekty. A nebo jit k jazyku, kterej to umi elegantneji (coz uz dneska neni nemozny).

Mě to nevykládej.

Problém nevidím v tom, že to tak někdo napíše. Problém je v tom, že neví.

Je správné prasit. Ale cesta do pekla je když nedokážeš odhadnout zda to je či není v daném okamžiku dobrý nápad.

Immutable je ideál, ne? Akorát se teda moc nevyskytuje.

> Immutable je ideál
A kolik vývojářů dokáže z fleku říct proč? :-)

To já neřeším. Každý si k tomu časem dojde.

Což je ten problém :-P

no mozna souhlas s predrecnikem. clovek si musi nabit huhu, aby vedel, co a kde NEpouzivat.

Historická poznámka: Java převzala “settery” z ObjC (jako spoustu jiných věcí), které se jich ale zbavilo (ve verzi 2.0) právě syntaktickým cukrem (a současně propojením s ARC). V (původním) ObjC to byla z nouze ctnost, protože přístup k proměnným třídy byl jen přes céčkovské ->, což tehdejším vývojářům nepřipadalo dost OO. S dozvuky tohoto (zlo)zvyku se občas setkávám i dnes třeba v Go nebo Rustu (někomu to dokonce připadá jako dobrý nápad).

Historicky možná.
Reálně se settery a gettery používají proto, protože je to jediný způsob jak změnit chování bez změny signatury.

O tom žádná. Jenže víš, co si většina programátorů představí pod pojmem praktické typy? Třídu. Bez konstruktoru, samozřejmě. A všechny property string.

Javista vytvoří třídu, přidá private propery (sic) a na každý getter a setter. Bez konstruktoru.
C#pista to má ještě jednodužší. Tam je na to syntaktický cukr, tak nemusí psát settery.

Mozno mate velmi volnu definiciu slova programator, alebo dost specificke vzorky, z ktorych generalizujete, ale vase tvrdenia idu proti mojej profesnej skusenosti za ~20 rokov v obore. Nech rozmyslam ako chcem, tak mi nenapada jediny programator, ktory by sa choval ako popisujete.

ono se to tak stale jeste uci, takze takovi juniori budou (a treba se preuci)

Záleží na juniorech.

Měl jsem kolegu který se slovy "chci psát čistý OOP kód" psal tak provázané špagety, že jsem si na to vždycky musel vyhradit celej ticket, abych to vůbec rozmotal. Nebo nadřízený, který zase všude chtěl bez rozmyslu cpát eventy.

Pak jsem měl juniora. Kterému stačilo jenom naznačit, že ten kód porušuje LoD, a než jsem se otočil, tak jsem koukal jak má otevřenou wikinu a pečlivě studuje, o čem to žvaním.

Ty eventy jsou nějaký mor nebo co.

buzzord pro tento rok (nebo minulej) nic vic za tim netreba hledat

Není jich zrovna málo.

tym myslite, ze existuje skola (VS/univerzita), ktora to tak uci, alebo to tak ucia vsade alebo vo vyznamnom precentu skol? Mozno niekde, ale tipoval by som, ze to bude skor vynimka. Moja skusenost je, ze sa to tak neucilo uz ani pred tymi ~20 rokmi.

Na jednom serveru, který poskytuje placené školení programování, tak ofiko učili, že dědičnost je za účelem reusable kódu. (Ne "taky dobrá", "v C++ jediná možná cesta", nebo "je to prasárnička, ale víte jak".) Pokud učitelé mají takovéto znalosti, a ještě dávají placená školení tak výsledky tomu pak odpovídají.

Tudíž, pokud si filtrujete uchazeče a máte vámi popisované výsledky, tak říkám: dobře vy! Ale obecné povědomí je bohužel nic moc.

Par prispevkov sice nasledne spominalo juniorov, ale vy ste povodne hovoril o vacsine programatorov, a pri javistoch a c# developeroch ste hovoril uplne obecne. Stale si za tym stojite, alebo ste si trochu zaprehanal (citil som tam mierne opovrhovanie Javou a C#) :).

Ak vychadzate zo vzorky vo svojom okoli (bez obmedzenia na juniorov), tak si myslim, ze je treba zamysliet sa nad kriteriami na prijimanie ludi. Realna situacia inde totiz podla mna rozhodne taka zla nie je.

23. 6. 2023, 01:52 editováno autorem komentáře

Javou a C# opovrhuji, ale nikoliv kvůli lidem, ale kvůli ideové kvalitě jazyka (C# víc, Java méně). To sem imho nepatří.

Co se týče lidí, tak si za tím stojím. Podle mne reálná situace tak zlá je, a možná byste se měl tedy zamyslet nad vzorkem ve vašem okolí, ze kterého děláte závěr :-)

Pokud máte vysoká kritéria na příjem programátorů, tak tam samozřejmě budete mít topky. Ale úplně nechápu, jak to rozsekává to co tvrdím já.

Tak Java, C#, Go, Rust atd. jsou tuctové jazyky pro masy. Já radši z malých vzorků závěry nedělám, ale chápu tě.

Opovrhovat tím můžete, ale C# Vás živí, nebo se pletu?

Java náhodou zas tak špatná není, na tu dobu, kdy vznikla. Ještě aby ne, když vznikla v podstatě jako kopie ObjC (vlastnosti jazyka i části standardní knihovny). C# zase vzniklo jako kopie Javy, současný vývoj ale moc nesleduju, poslední “novinka”, kterou jsem na .NET používal, bylo C++/CLI :)

Je to tak. Prachy nesmrdí :-)

Jen bych rád zdůraznil, že já jsem to nevytahoval.

Hmm, dědičnost se hodí u rozhraní, jinak spíš komplikuje kód.

Perl je naprosto v pohodě, když ho píšeš příčetně. Od stringu hned k Perlu to je dobrá zkratka tedy.

17. 6. 2023, 23:07 editováno autorem komentáře