Příspěvky

406

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 10. 11. 2020, 07:32:11 »

Java otevřela nový segment. Python nahradil Perl.

Ja by som bol opatrný pri slove nahradil. V súčasnosti je dnes viac Perl programátorov,
ako v minulosti. Akurát ostantné jazyky sú populárnejšie a Perl nie je na očiach.
Skôr by som tipoval, že Python obsadil oblasti, ktoré mohol mať Perl. Na webe Perl
zas vytlačilo PHP.

Je pozoruhodné, že Python oveľa viac populárny ako Perl. Perl je len o 2-3 roky starší
ale jeho CPAN bol spustený v roku 1995!!! Python mal dlhé roky v tom chaos a jednodný
repozitár sa podarilo dosiahnuť len pár rokov dozadu.

1. PyPI je na světě od roku 2002, ale Python měl poměrně obsáhlou knihovnu v základní instalaci (batteries included). CPAN přinášel slušný dependency hell, vzpomínám si, jak jedno české fórum běželo na redakčním systému, který stavěl nad konkrétními verzemi knihoven z CPANu a jak bolestné bylo ho rozjet. Python už tenkrát měl Django a další podobné počiny, které fungovaly jinak. PyPi je výhoda, ale že bychom perlistům tenkrát nějak zvlášť záviděli, to ani ne.

2. Python se prosadil v oblastech, kam Perl nikdy neproniknul nebo se používal okrajově, ať už to je skriptování her nebo různých aplikací nebo vědecké výpočty.

3. V oblasti "systémových skriptů" vytlačuje řešení psaná dříve nejenom v Perlu, ale i v shellu nebo třeba C. Co je ale podstatné a v tom se přístup X nahradil Y mýlí, roste počet různých systémů a utilit obecně. Přísně vzato, Python nahrazuje jakýkoli turingovsky úplný jazyk. My, kteří jsme dříve dělali v C (ale vyrůstali na Basicu a Pascalu), pak v C++, jsme přešli na Python a následně třeba začínáme dělat s Rustem. Ale děláme věci, jaké se v C tenkrát nedělali a jsou zde spousty programátorů, kteří C neznají nebo ho v praxi nepoužili a jedou v tom s námi.

407

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 07. 11. 2020, 07:37:53 »

Tak to je další level, doporučit Google, když někdo položí řečnickou otázku. :facepalm:

Lidské poznání přece stojí a padá na těch, kterým je všechno jasné. No a teď ještě mají ten Google. Představ si, že by ho měli ve starém Řecku, kdy bychom teď mohli být.

408

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 11. 2020, 19:30:37 »

Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Touché!

409

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 06. 11. 2020, 11:50:54 »

Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Aha, takže revoluci lidu možno, ale nesmí jí být moc, jen tak trochu, aby to lid zvládl pobrat. Rozumím.

Lisp má neoblíbenou syntaxi, Smalltalk má neoblíbenou sémantiku. Vyhrál pragmatismus, ale to, co z nich je osvědčené, se v různých podobách prosadilo. To je dobrý výsledek, ne?

410

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 11. 2020, 10:58:01 »

Ten split() je rozhodnutí tvúrcú API, ne?

Ano, ale u jazyka se neohodnotí jen jazyk, ale hlavně také standardní knihovna, ekosystém okolo a spousta věcí

1. Nevzniká Vec<&str>, ale impl Iterator<Item=&str>
2. Podle mě je to API naprosto v pořádku, co se ti nelíbí? Když splitnu String, dostanu iterátor přes pohledy do toho splitnutého stringu (tedy iterátor přes typ &str), jak lépe by to mělo být?

Souhlas, je to nejtypičtější situace - obyčejně ten řez stačí a pokud ne, udělá se na něm String::from() nebo něco. Dokonce to hlídá, aby člověk po tom splitu nezkoušel ten String modifikovat (pokud se tedy ten collectnutý Vec<&str> použije, jinak se zdá, že Rust pokrčí rameny).

Že má Rust moc řetězcových a znakových typů? Jo, ale to prostě reflektuje realitu. Viz třeba OsString, který se prostě normálním Utf stringem nahradit nedá.

Jo a ještě něco - stejné API pro split() má i str. Na jednu stranu vypadá logicky, že by jeden chtěl ze Stringu mít iterátor se Stringy, ale je otázka, zda to tak opravdu je. Tu metodu šlo úplně vynechat, je to spíš zkratka, aby člověk ušetřil as_str() - tak bych to bral.

411

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 11. 2020, 08:02:32 »

Je podle Vás Rust jazyk budoucnosti? Případně, jaké jsou pro a proti a jaké budou klíčové milníky pro Rust? Použití Rustu narozdíl od Go tolik neroste, jaký to má podle Vás důvod a může se to v horizontu 1-2 let změnit?

Rust je ambiciózní pečlivě navržený jazyk, Go je jazyk více pragmatický, masový. Oba mají v současnosti svoje místo, Rust roste pomaleji právě proto, že nedělá kompromisy. Pokud se komunitě podaří vyřešit některé slabší stránky, může růst i na úkor Go. Úplná masovka to ale nebude asi nikdy, protože hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).

412

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 11. 2020, 07:45:59 »

Ten split() je rozhodnutí tvúrcú API, ne?

413

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 04. 11. 2020, 18:12:25 »

Ano, primitivní typy v Javě jsou chyba návrhu, i když pochopitelná a omluvitelná dobou vzniku. Ale je to přesně ta věc, která tam nepatří, trčí z toho. Přidáte do jazyka novou vlastnost, na vše ostatní se to pěkně naváže – jenom primitivní typy to rozbijou. Přitom v době vzniku Javy byly podle mne primitivní typy přesně to cukrátko, které tam chce každý mít.

Podle mě to je přesně naopak. Primitivní typy jsou OK, chyba je, že Java nemá nic jako přetížení operátorů a že šla příliš radikálně cestou OOP. Porovnávání přes .equals() je rovnák na vohejbák, v každém normálním jazyce == porovnává hodnoty a ne reference.

414

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 04. 11. 2020, 09:25:11 »

Uff, moje odpoved asi nenadchne ale presto si ji neodpustim. Proc se chce nekdo poustet do vyvoje v nejakem "pseudo" jazyce ? Chci tim rict ze jedna vec je smysluplny pokrok ale ta "turbulence" vzniku novych jazyku mi pripada az usmevna. Nekdo vytvori novy jazyk, protoze je super-cuper a ma features xy ktery tech 30 jazyku predtim nemelo.  Nez se ten jazyk dostane alespon do prvni stable verze uz je vlastne zastaraly protoze nejaci frikulini vymysleli novy jazyk xy'. Pochopim to na urvoni skolni ci osobniho rozovje ale z hlediska komercniho vyuziti mi to prijde ulitle. Nerikam ze nikdo v kotlinu/scale nepise ale  ... Mainstream je dneska asi Java,C#,Python ? Ja byt majitel nejake firmy a prijit ke mne clovek ze mi chce neco bastlit v Kotlinu protoze mu to prijde cool & sexy tak ho zenu svinskym krokem. Uz vidim jak mi za 2 roky rekne ze ho to neba, ze jde jinam protoze jazyk XY'' a ja zacinam schanet na trhu nekoho kdo zna Kotlin, Scala. Priznavam jsem starej pes co pise 20let v Ccku, ale to nenavidene Ccko, ma proad zivy ekosystem, spoustu podpurnejch toolu pres profilovani, debug, valgrind atd. Existuji vubec takove tooly pro Kotlin, Scalu budou existovat za 2 roky ? A pokud jsem v nem (C/C++) napsali projekt puvodne pro HP-UX na PARISCU, postupem casu se portoval na HP-UX itanium az skoncil na Linuxu/x86_64 porad to bude udrzitelne. Me proste prijde ze lidi kvuli svemu egu, hrozne tristi sily a pokroku to spis skodi nez prospiva. Je sice fajn ze si muzu vybrat ze 100 programovacich jazyku ale dava to smysl ?  Jeste bych dodal ze to neni o moji lenosti, naucit se neco noveho, kdyz si clovek prosel Cobol,Pascal,C/C++,Java,Pro*C,PL/SQL neni az zas tak slozite se naucit novy jazyk alespon syntakticky, toze ze za vikend pochopite Javu z vas nedela samozrejme programatora v Jave, protoze ta dzungle classu a interface je proste usmevna.

Smysl to dává, pokud ten jazyk má přidanou hodnotu. Vem si, že optimalizuješ na rychlost vývoje, udržovatelnost kódu, rychlost běhu, bezpečnost apod. Kdyby za Tebou přišel někdo, že psát v Kotlinu je cool a zatrhnul bys to, asi bys udělal dobře.  Co ale když má dobré důvody? A co když, díky tomu že se mu v něčem vyvíjí lépe, udělá aplikaci, jakou by v "mainstreamu" prostě neudělal z nedostatku motivace?

Proč si myslíš, že Google, Microsoft, Apple, Amazon a další laborují s různými novými jazyky? No protože doufají, že se jim povede něco zlepšit. A často tomu tak je. Go je v něčem lepší než Python nebo C, Rust v něčem přerostl C++. A ekosystém? Kolikrát v mnohém lepší!

415

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 03. 11. 2020, 22:58:02 »

Tak mam dojem ze uz se tu kdysi resilo, ze 2 a 3 umi jetbrains resit i u pythonu.

Bez důsledných type hintů, příp. jedinečně pojmenovaných metod (jak často tu zaznívá propagace stručných jednoslovných názvů...) si ani pycharm moc neškrtne. A nelze se mu divit, že neumí věštit...

No a když se přidají hovadiny typu **kwargs, ani křišťálová koule nepomůže.

416

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 03. 11. 2020, 18:44:34 »

Ma staticke typovani nejakou dalsi vyhodu pred dynamickym krome toho, ze ta kontrola typu probehne pred nasazenim?

Že kontrola probíhá před nasazením je vlastnost, ne konkrétní výhoda. Výhody jsou třeba takové, že:

1. Kompilátor nedovolí překlad, pokud má protichůdné či nedostatečné informace o typu. To jsi měl asi na mysli.
2. Vývojový nástroj (který s kompilátorem může sdílet některé komponenty) člověku ještě před samotnou kompilací v reálném čase ty nedostatky může hlásit (nevím, co v tomto může navíc nabídnout Tvůj REPL driven development).
3. Vývojový nástroj ukazuje typ proměnné/hodnoty/parametru apod. díky inferenci. Při vývoji neustále vím, co za data tam leze, jakou mají vnitřní strukturu (zde už může docházet i k našeptávání atributů ve strukturovaných datech apod.).

417

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 03. 11. 2020, 17:19:27 »

Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

Castecne trochu provokace :-).
Castecne to ze s clojure a spec muzu overovat konfrmitu kdykoli se mi zachce.
Treba pro jeden konkretni vyraz uprostred funkce.

Samozrejme to stejne tak muzu delat i pri upravach produkcniho systemu.
A kdyz mam koule a pristup tak i primo na te produkci.

No dobře, předpokládám, že jde o ověření dynamické (mýlím se?), což ale není zrovna to, co je "později než kompilace". Pokud není v každé chvíli dostateřně jasné, s jakým datovým typem se pracuje, hrozí chyba ve všech možných okrajových případech no a po úpravách nebo dokonce refaktorizaci to bude nejspíš jenom horší.

418

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 03. 11. 2020, 14:35:58 »

Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

419

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 03. 11. 2020, 13:47:58 »

S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec obcas... a kdysi sem si hral s https://github.com/arohner/spectrum.

Ale hlavne RDD (repl driven development) prece jenom kontrolovat typy pri kompilaci je trochu pozde ze? (:-D)

Podle mych zkusenosti ty typy u dynamickych jazycich nejvic chybeji az pri upravach produkcniho systemu.

420

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 03. 11. 2020, 07:54:35 »

Teď se Ti myslím povedla demonstrace jedné ze skutečných výhod výjimek, která ale může fungovat asi jenom v dynamických jazycích typu Pythonu - ten context manager pozná výjimku podle parametru, který ji identifikuje.

Jinak je to věc, která se dá řešit destruktorem při výstupu z rozsahu platnosti proměnné - třeba v Rustu se udělá drop v opačném pořadí (vzhledem k pořadí definice proměnné) automaticky a je vymalováno taky.

Obávám se, že rozhodně nemohu souhlasit. Už jsem tu toto téma někdy rozebíral, žel neúspěšně. Má aktuální úroveň poznání mi říká, že dynamické jazyky nepřináší nic co by principielně nešlo ve statických jazycích (a stáli bychom o to). Každopádně, asi zůstaňme u tématu.

Principiálně ano. Přemýšlím, jak by se to dělalo v C++. Pokud si pamatuju dobře, můžeš jako výjimku házet leccos, takže by maximálně šlo do exit metody poslat info, jestli výjimka byla nebo ne. U dynamických jazyků typu Pythonu je hodnota proměnné libovolná.

No ale zase, kdybychom měli k dispozici jenom bool, šlo by něco podobného i bez výjimek - třeba v Rustu. Tam se mi dokonce rýsuje i řešení s identifikací typu Erroru - pomocí downcastu by to mělo být možné vydolovat i z wrapperu, jaký dělá třeba anyhow! Tudíž asi musím vzít zpět svoje tvrzení o výhodě výjimky, protože podle všeho by to mělo jít postavit i nad Resultem - musel by se udělat příslušný trait (nebo změnit protokol Dropu) a jazyk by tomu musel vyjít vstříc.