Příspěvky

46

Vývoj / Re:Převod List<a> na Vect<a,n>

« kdy: 19. 02. 2023, 14:22:17 »

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

Ano, pro tento velmi specifický případ se spojový seznam celkem hodí (za předpokladu, že moc nepotřebuješ náhodný přístup), sice jsem to v praxi neviděl, ale nezpochybňuju to. Ale když tam přidáš vektor - a to je základ mého příspěvku - už můžeš spojový seznam zahodit, protože režii přidávání a odebírání na vektoru se nevyhneš.

47

Vývoj / Re:Převod List<a> na Vect<a,n>

« kdy: 18. 02. 2023, 13:43:36 »

Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

deka listu ve tride listu muze byt, ale michat tam i vektor je nadbytecne.

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

48

Vývoj / Re:Převod List<a> na Vect<a,n>

« kdy: 18. 02. 2023, 08:12:04 »

Ja to chápem tak, že pamäť pre vektor sa alokuje ako počet dát krát veľkosť dát, takže musia byť dáta za sebou v pamäti.

Nekonečná kolekcia je niečo ako zreťazený zoznam a má porozhadzované prvky v pamäti a ešte prvý prvok musí mať smerník na samotné dáta a smerník na druhý prvok, druhý prvok má smerník na svoje dáta a smerník na ďalší prvok, atď. Posledný prvok má smerník na ďalší prvok nastavený na Null. Takže sa dajú ľahko pridať ďalšie dáta, stačí správne ponastavovať smerníky na ďalší prvok v predchádzajúcom a pridávanom prvku.

"Nekonečná" kolekce může být taky vektor. A naštěstí většinou i bývá.

49

Vývoj / Re:Převod List<a> na Vect<a,n>

« kdy: 17. 02. 2023, 18:04:14 »

Aby nedošlo k omylu, já to zadání chápu. Jen jsem ho zjednodušil.

Obecně v jazycích se předpokládají kolekce jako nekonečné. Tudíž proč někde uchovávat délku kolekce? Třeba proto, že mám funkce, které dokáží zpracovat jen konkrétní délku - což je můj příspěvek/dotaz. A nebo proto, že mám různé specializované funkce pro různé délky. Tak pak nevím proč to rvát do typu, když se můžu zeptat v nějakém switchi.

K čemu je zajímavé, že je ta délka součástí typu? Jaké to má praktické použití?

To má smysl při optimalizacích. Třeba Rust má vector ("nekonečný") a array, kde je délka součástí typu. Dává to perfektní smysl, stejně jako skutečnost, že to je dáno při kompilaci natvrdo. Samozřejmě si dovedu představit i nějakou realtimovou "oblast", kde se dynamicky vytvoří alokace řádků pevné délky. Ale je to taková specialitka...

50

Vývoj / Re:Převod List<a> na Vect<a,n>

« kdy: 17. 02. 2023, 12:34:20 »

Zdá se mi to nebo si tu Idris pokládá zdánlivě triviální otázky na které si odborně odpovídá pod jiným účtem 
viz minule https://forum.root.cz/index.php?topic=27054.0

To je zajímavá hypotéza...

51

Studium a uplatnění / Re:ChatGPT a AI pro vývojáře

« kdy: 14. 02. 2023, 13:45:06 »

Jirsák +1.

Já bych to popsal tak, že většinové IT pomalu opouští rigidní matematické procesy, ve kterých se zrodilo, a přesouvá se do měkčích procesů známých třeba z biologie. Místo zdola nahoru se jde shora dolů. Je to lepší, nebo horší? Asi záleží případ od případu, ale určitě to dovoluje mít složitější celky, které z povahy věci prostě musí být tolerantní k částečnému selhání něčeho uvnitř.

Tenhle přístup mne, co by inženýra dost děsí. Trochu mi to zavání rezignací. Nevíme jestli je to evoluce nebo rakovina. Prostě to neumíme nadesignovat, uřídit, tak to necháme jak se to vyvrbí. Evoluce funguje, ale v řádech miliónů let se spoustou slepých uliček a masových vymírání. Jsem stavební inženýr, trochu něco tuším o strojařině, a tam jen idea systémů, které nejsou 100% deterministické je nepřijatelná fantasmagorie.

Jsem 100% pro fault tolerant systémy, nicméně ty systémy stále musí být deterministické. Jinak se inženýrská práce mění v alchymii.

Je to šílené, dystopické a zbytečné. V době, kdy existují čím dál kvalitnější programovací jazyky a nástroje, lze efektivně psát kvalitní, spolehlivé a rychlé programy a neexistuje výmluva.

ChatGPT lže a je horší než Stack Overflow, protože nemá viditelnou korekci. Člověka, který programuje s podobnými pomůckami, aniž by v rozumné míře věděl, co a proč kopíruje, bych okamžitě vyhodil.

52

Studium a uplatnění / Re:Pohovor na pozici junior programátora

« kdy: 11. 02. 2023, 11:42:38 »

Pohovory znám spíš z té opačné strany a můžu potvrdit, že nekoušeme a uchazeče nebijeme. Čistě se obleč, buď v pohodě, zajímej se o firmu, kterou chceš oslovit a ber to jako příležitost.

mas nejakou pikosku z nataceni?

Nevím, jestli to někoho pobaví, ale typy chodí fakt různé. Počínaje maníkem, který měl IQ tak asi 180, podíval se na nás ze svého nadhledu a slušně se rozloučil. Přes různé seniorní a juniorní kandidáty, se kterými byla radost si popovídat a někteří zůstali. Až po týpka, který nevěděl o programování nic, ale strašně se zajímal o to, kde bude přesně sedět nebo rekvalifikovanou prodavačku, která samozřejmě neměla o oboru páru, ale ještě přišla na pohovor o 3/4 hodiny dříve a když jsem na to opatrně poukázal, řekla, že jí takhle přijel autobus.

V poslední době přibývá zájemců o místo programátora z řad zjevných neprogramátorů. Někteří jinak použitelní uchazeči zase mají problém přijít do práce nebo se aspoň omluvit a to klidně ze začátku zkušební doby. Kdyby komunikovali, přivřel bych oko, ale tohle je fakt přes čáru. Přiznaný junior se sebekázní a snahou se posouvat je fajn model.

53

Studium a uplatnění / Re:Pohovor na pozici junior programátora

« kdy: 11. 02. 2023, 09:49:59 »

Pohovory znám spíš z té opačné strany a můžu potvrdit, že nekoušeme a uchazeče nebijeme. Čistě se obleč, buď v pohodě, zajímej se o firmu, kterou chceš oslovit a ber to jako příležitost.

54

Sítě / Re:Nestabilní FTP u o2

« kdy: 23. 01. 2023, 15:55:54 »

blem, HTTP plne gul.e, FTP si chodilo ako chcelo .. Protistrana aj ISP tvrdili, ze u nich problem nie je :-) A včuľ babo raď, kto v tom ma prsty ...

Pokud jsou tam dva možní viníci, dá se to otestovat, ne?

55

Vývoj / Re:Rychlost Chez Scheme

« kdy: 23. 01. 2023, 10:52:08 »

Nevím, nakolik to považuješ za relevantní, ale C není Rust a v praxi má každý z těchto dvou jazyků, co se týče výkonu, trochu jinou pozici:

https://kornel.ski/rust-c-speed

Obecně vzato, řekl bych, že hodně záleží i na té horní vrstvě, jaké umožňuje abstrakce a jak se ty její konstrukce dají optimalizovat ve výsledném kódu.

To se týká každého “vyššího” jazyka, Rust je ještě poměrně nízko, vem si Lean nebo Prolog, dělají věci úplně jinak než “normální” procedurální jazyky, ale kód také generují rychlý (protože high-level optimalizace).

Nejsem si jistý, zda každého, ale určitě to není věc výlučně Rustu. Co se týče Leanu, tak kvůli němu vznikla celá tahle debata, nebo to byl jiný jazyk kompilovaný skrze Chez?

56

Vývoj / Re:Rychlost Chez Schemei

« kdy: 23. 01. 2023, 09:20:35 »

Ano, výborně! Chtěl jsem a) zjistit jestli to jde poznat a za b) dostat z vás odborníků, jestli nekecá, což se mi zatím nepodařilo. Nevím o tom totiž vůbec nic. Díky za účast.

ChatGPT se nedá věřit, umí jenom papouškovat, je schválně natrénovaný, aby měl levicové "názory" a esej s opačným názorem dokonce odmítne vytvořit. A lže: Napřed mi tvrdil, že Modlitbu pro Martu napsal Nohavica, když jsem se ohradil, řekl, že mám pravdu a napsal ji Kryl a když jsem mu napsal, kdo byli skuteční autoři, tak mi to odkýval a tvářil se, že jsme v pohodě. No, nejsme.

57

Vývoj / Re:Rychlost Chez Scheme

« kdy: 23. 01. 2023, 06:55:54 »

V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.

Díky, někdo další ?

Nevím, nakolik to považuješ za relevantní, ale C není Rust a v praxi má každý z těchto dvou jazyků, co se týče výkonu, trochu jinou pozici:

https://kornel.ski/rust-c-speed

Obecně vzato, řekl bych, že hodně záleží i na té horní vrstvě, jaké umožňuje abstrakce a jak se ty její konstrukce dají optimalizovat ve výsledném kódu.

58

Vývoj / Re:Rychlost Chez Scheme

« kdy: 22. 01. 2023, 19:57:23 »

bavíme se o Lispu

Dotaz byl o Scheme.

Scheme je dialekt Lispu, ale OK. Pojďme zpět k tématu - beru, že když se Chez používá v situaci s jasnými typy a vstup je nízkoúrovňový, je to rychlé. Otázka zní: Bylo by možno ve Scheme psát rozsáhlý, bezpečný, čitelný a výkonný kód?

59

Vývoj / Re:Rychlost Chez Scheme

« kdy: 22. 01. 2023, 16:28:23 »

Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.

Kontext, Idrisi, kontext.

Jo, ten ti uniká. Homoikonicita nijak nesouvisí s čitelností. Ostatně Julia ji má taky a čitelná je značně.

No zrovna dnes jsem četl, jak kdysi v raných dobách vývoje Julie někdo z autorů napsal, že Julia je homoikonická a jaký se strhnul poprask od lidí, které to až urazilo. A o tom, co je homoikonicita, se vedou obecně spory:

https://stackoverflow.com/questions/31733766/in-what-sense-are-languages-like-elixir-and-julia-homoiconic/31734725#31734725

https://www.expressionsofchange.org/homoiconicity-revisited/

Ale hlavně - bavíme se o Lispu a tam je přece jasné, že to souvisí s jeho syntaxí a čitelností.

60

Vývoj / Re:Rychlost Chez Scheme

« kdy: 22. 01. 2023, 16:07:07 »

Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.

Kontext, Idrisi, kontext.