Jde o to, že ML se striktně snaží o typovou inferenci, takže to "naopak" plyne z toho, že vlastně říká "věřím tvému kódu a odvodím si z něho typy" namísto "věřím explicitním typovým anotacím, které musíš zapsat".
Napříkld pokud v ML (například na https://sosml.org/editor) zadáš:
fun fib 0 = 0
| fib 1 = 1
| fib n = fib (n - 1) + fib (n - 2);
Tak si ML odvodí typ
val fib = fn: int int;
A bude ho striktně hlídat, a to i uvnitř té samé funkce (stačí zkusit změnit 2 na 2.0 a rozdíl je vidět)
OcaML a F# do toho "jen" přidávají další objektovou a "interfacovou" omáčku :-p
Ved .Net uz takmer 10 rokov ide aj na linuxoch a vsetko okolo neho je pod MIT lienciou. A to, ze je od Microsoftu? No a? Je to Go, co je od Googlu, Rust,, co je od Mozilly a na obe spolocnosti sa najdu heiteri a tiez sa tu najdu ludia co ich povazuju za stelsnenie zla.
Naozaj nie je dovod uprednostnovat jednu korporaciu pred druhou.
Ak by ten serial fakt bol, tak by som sa velmi potesil, lebo F# ma zaujal, ale este som nemal moznost sa don dostat do hlbky.
Ve všem máš pravdu. Jde spíše prostě o takový sentiment.
F# jako jazyk udělal všechno správně. Má zajímavé osobnosti co za ním stojí, přátelskou komunitu a dobrou dokumentaci. Problém je ale, že M$ na F# kašle, protože peníze mu vydělává zpatlaný C#. Za ta léta existence se F# uživatelská základna moc nerozrostla.
F# taky trpí interoperabilitou s objektovým C# a VM. F# jsou takové dva jazyky v jednom. Kupodivu i Scala (3) je v porovnání s F# v jádru velmi jednoduchý jazyk (kompexnost pak leží jinde než v jádru jazyka).
Společnosti o ho používají z toho určitě profitují, je to kvalitní jazyk, ale žádná zářivá budoucnost ho už asi nečeká. Na to je tu moc dlouho a C# stále pomalu doplňuje features, které F# protlačil.
Popravdě, pokud není společnost .NET shop, tak klidně může risknout OCaml, který v posledních verzích hodně tlačí velmi zajmavé novinky (effect system, konečně multicore atd.)
16. 6. 2023, 10:51 editováno autorem komentáře
Hlavně ty typy využívají další frameworks jako například FastAPI. Bohužel, Python VM typy už nekontroluje, takže lze jednoduše napsat x: int = "abcd" a to bez problému projde (MyPy by tedy asi zařvalo).
... to spolu s dynamicitou operátoru ve mě budí jistou nedůvěru, kdy data ze vstupu nemusí být korektně validována a v runtime se pak můžou dít zcela nepředvídatelné věci.
Ja uz si pockam na Mojo
https://www.modular.com/mojo
https://youtu.be/pdJQ8iVTwj8
Cilem je kompletni podpora python bez vyjimem a navic moznost striktniho modu pro typy atd.
Jeste to asi bude rok dva trvat, ale temer jiste to zmeni cely python svet.
No prave, licencovani. Dneska jsou proste vsichni zvykli na to, ze kdyz potrebuji (dejme tomu) nasadit dalsi sluzbu, nebo ji naskalovat, tak to proste za chvili udelaji. Kdyby si meli oficialne domlouvat licence - to je nepruchozi (nejde ani tak o to, ze by to nejaky $ stalo, ale silene prostoje, vysvetlovani, na co to je potreba a tak).
nojo to je takova (asi trosku pochopitelna) snaha prosazovat nejakou technologii i tam, kde se vubec nemusi hodit.
Co se vlastne ted uci na FITu? Za nas to byl Pascal, C, C++ (z nejakeho duvodu to bylo spojeno), potom malicko LISP a Prolog (ale mel jsem pocit, ze tomu vyucujici az ta uplne nerozumel ;)
Tak premyslim co jineho by se fyzici a sociologove meli ucit? Musi to byt jednoduche, musi to mit obrovsky zaber knihoven aby to dokazalo pobrat obrovskou siri problemu (od fyziky po sociologii), a musi to byt dostatecne rozsirene aby na vsechno byla odpoved na stackoverflow.
Z techto pozadavku mi vypadnul jen python.
Umim si predstavit ze treba sociolog potrebuje spis R, ale je to relativne uzkoprofilovy jazyk, a na bezneho sociologa to je (bez urazky) stejne prilis komplikovane. Umim si predstavit ze vetsina fyziku zvladne klidne neco blizsiho zelezu, pri simulacich je rychly kod potrebny, ale python jako zaklad je porad dobra volba, a pripadne kriticke casti kodu se daji napsat v C/FORTRAN.
(fyzik) za mě souhlas, Python + Fortran (třeba i přes f2py) se mi zdá pořád nejvhodnější. Julia možná za pár let, až dozraje.
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
Zatím to nevypadá, že bude mít Mojo vyjadřovací sílu Rustu (který se mimichodem taky pořád posouvá). A komunita HW geeků v Rustu je jednak poměrně silná a jednak Mojo asi ani nebude cílit na stejnou oblast nasazení, natož s úspěchem. Těch "skoroC" s OOP apod. bylo hodně a moc se nechytily. Uvidíme, jak se Mojo chytí aspoň ve Web Framework Benchmarks.
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.
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š.
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.
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.
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 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
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).
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.
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.
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á.