Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ink

Stran: 1 ... 12 13 [14] 15 16 ... 43
196
Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?
« kdy: 24. 01. 2022, 10:39:50 »
Jakým způsobem multidispatch urychluje běh programu? Už jsi to psal dřív, ale mně to úplně smysl nedává...
To jsem nikdy nepsal, ani teď, jen to, že umožňuje velice efektivní optimalizaci výsledného kódu, pokud je program správně otypovaný (o tom je řada článků na konferencích jako POPL, co to je typově ukotvený program a jak ovlivňuje výsledný stroják).

Vždyť jsem ale citoval tuhle Tvoji větu:

Proč je asi v průměru Julia rychlejší než Rust (nápověda: multidispatch)?

Ta nápověda teda měla říct něco jiného, než že MD pomáhá výkonu?

Každopádně mě teda to Tvoje tvrzení o rychlejší Julii nadále dráždí, asi si to někdy prozkoumám.

197
Vývoj / Re:Jak validovat DTO v dynamicky typovaném jazyce?
« kdy: 24. 01. 2022, 07:22:44 »
To je škoda, je to zajímavé a aktuální téma. Proč je asi v průměru Julia rychlejší než Rust (nápověda: multidispatch)?

Jakým způsobem multidispatch urychluje běh programu? Už jsi to psal dřív, ale mně to úplně smysl nedává...

198
Vývoj / Re:Ruby v roku 2022 (je mrtve?)
« kdy: 22. 01. 2022, 10:41:45 »
Skriptovací (lépe snad interpretované) jazyky mají výhodu v tom, že je možno program zkoumat a modifikovat na místě.
A k čemu to je? Zkoumat a modifikovat se dá i makrem při překladu (Rust, Julia), proč bych to měl dělat za běhu?

Na ostrých serverech tohle přes SSH dělám běžně. Mám v Pythonu nějaký skript pro rychlou analýzu  nějakých dat nebo logů a chci si skript rychle upravit a vidět pozměněný výsledek. Tohle bych fakt v Rustu nedělal. Podobných situací jsem zažil dost a mít zdroják a případně REPL je k nezaplacení.

199
Vývoj / Re:Ruby v roku 2022 (je mrtve?)
« kdy: 22. 01. 2022, 06:43:53 »
to bych zas nestresoval, instalace JRE nebo JDK je dneska uz vsude :-)
nehledel bych na skriptovaci/kompilovany, nativni/virtualni masina, ale jak se mi s tim ci onim programovacim
jazykem dobre ci spatne dela.
mam rad lisp, ok, tak to pisu v lispu :-)

Víceméně souhlasím. V posledních letech pozoruju dost velkou "konvergenci" programovacích jazyků. Co se týče snadnosti používání, dostupnosti knihoven, dostatečné rychlosti běhu, jsou řešení v různých jazycích často poměrně srovnatelná. Spoustu jednoduchých věcí dovedu napsat v rozumném čase v Pythonu, Rustu, v Javě, v PHP, v JS, v C++, v Common Lispu, klidně v Haskellu, když by na to přišlo. Jasně, musel bych si v některých jazycích leccos oprášit nebo googlit knihovny apod., takže bych výběr v praxi dost zúžil, ale to už je zase jiný problém.

Skriptovací (lépe snad interpretované) jazyky mají výhodu v tom, že je možno program zkoumat a modifikovat na místě. Pokud toto není cílem, je asi celkem jedno, jestli jde o program distribuovaný jako zdrojový, v nějakém bytecode nebo v nativní binárce.

Druhý aspekt (tolik přiznám kolegovi Mikromovi) je možná technická bariéra (kompatibilita mei systémy, dosttupné knihovny).

Know-how a vůbec ochota k práci s konkrétním jazykem jsou ovšem skoro stejně důležité věci.  Když nesnáším Perl (Python, Tcl, cokoli) nebo na to nemám člověka, tak to prostě používat nebudu. OP použil Go, splnil úkol, prošlo mu to, za mě happy end.  ;)

200
Vývoj / Re:Ruby v roku 2022 (je mrtve?)
« kdy: 20. 01. 2022, 09:24:40 »
A to jsou které?
WORA
To umí i spousta jiných jazyků.

Asi tak. V Pythonu to je v zásadě standard (i s GUI třeba přes PyQt), dtto Ruby, Perl, PHP... A pokud nevadí build pro více platforem (což není žádná hrozná práce), platí to i pro většinu jazyků, které překládají do strojáku. A pak to je obyčejně i bez nutnosti instalovat další závislosti.

201
Studium a uplatnění / Re:Strategie na recesi
« kdy: 19. 01. 2022, 11:07:16 »
Je důvod se obávat? Jak se na krizi připravit? Šetřit vzhledem k inflaci není moc dobrý nápad, investovat vzhledem k pravděpodobnému propadu taky moc ne. Je vůbec cesty ven?

To, že akciový trh občas zažije propad, ještě neznamená, že není dobré do akcií dlouhodoběji investovat. Co neprožereš, to se Ti znásobí - vždycky. Nech si na spotřebu, kolik fakt potřebuješ, to za Tebe nikdo stejně nezodpoví. A i kdybys měl peníze ve slamníku, což nedoporučuju, i po inflaci z nich furt něco zůstane. Co projíš a propiješ, z toho zbyde "nic".

Pokud zainvestuješ do kvalitního HW a SW, případně výukových materiálů či kursů, to se Ti taky zřejmě neztratí.

202
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 07:20:01 »
Jenže pozor, dochází ke zmatení pojmů (s dojmy)
VY mluvíte o SSD v provedení M.2 - malá kartička, já mluvím o SSD U.2 - což je vizuálně nomální 2,5" disk - jen s NVMe rozhraním.
A na ty karty u nás prostě nejsou. Proto ten rychlý Ali.

Aha, tak sorry, to jsem po ránu přehlédl.

203
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 06:50:30 »
Mám AXAGON PCEM2-D, umí připojit zároveň jeden NVME a jeden SATA SSD. Mám jenom NVME a funguje v pohodě. Karta mě stála v českém eShopu míň, než Tvoje řešení z čínského blešáku.

204
Vývoj / Re:Chování seznamu v Pythonu
« kdy: 05. 01. 2022, 11:40:20 »
Ahoj, může mi někdo vysvětlit toto chování Pythonu?
Proč se v c nevytvoří seznam s hodnotami [[1],[2]] ale instance a a b?
Pro jiné datové typy např. kdyby a,b byly int se to chová normálně.
nebo poslat odkaz na vysvětlení, nikde jsem nic nenašel...

Kód: [Vybrat]
a = [1]
b = [2]
c = [a, b]
a[0] = 2
print(c)
>[[2], [2]]

Budeš muset zreevidovat, co je "normálně", jak se v Pythonu pracuje s mutable a immutable typy apod.  Jinými slovy, zainvestovat do pořádného pochopení, každý jazyk se z různých důvodů chová po svém a ne tak, jak bys nutně předpokládal.

205
Vývoj / Re:JS Promise
« kdy: 02. 01. 2022, 08:48:28 »
[…] preto som nemohol/nechcel nic vratit.

return () => events.close by stacilo
Pokud se nemá nic vracet, tak se té streamovací funkci může předat kontext (v tomto případě prázdný objekt), funkce v něm nastaví ctx.cancel na tu lambdu, kterou jiní navrhují vrátit, a volající pak zavolá ctx.cancel(). Je to v zásadě to samé, jen se explicitně nic nevrací.

Taky dobré řešení. Obecná zkušenost - pokud něco vypadá zbytečně složitě, je dobré zvolenou cestu zrevidovat a zkusit najít jinou. Ale hlavně je dobré (což OP nakonec udělal) osvětlit celý problém vedle žádosti o radu s již rozpečeným řešením.

206
Vývoj / Re:JS Promise
« kdy: 01. 01. 2022, 14:41:20 »
Tvoje "Čistší, jednodušší, průhlednější, kratší." riesenie exportuje internu implementaciu funkcie ktoru caller nema vobec so riesit.

Tohle mě zajímá; co je u Tebe export interní implementace, snad ne tohle:

Kód: [Vybrat]
  return () => events.close();

207
Skus "lepsi" inkognito rezim:

Kód: [Vybrat]
#!/usr/bin/env bash

rm -rf /tmp/p
google-chrome --incognito --user-data-dir=/tmp/p >/dev/null 2>&1
rm -rf /tmp/p

Nebo "lepší" browser.

208
Já měl Pascal jen dávno v prváku, u zkoušky jsem ho viděl naposled. Ale minimálně výrazně ovlivnil jiné jazyky a napravil některé divnosti Algolu.
Tak jsem si pročetl srovnání Algolu a Pascalu od Tanenbauma (je to online v pdf) a musím říct, že v něčem ten Algol měl dost výrazně navrch. Bezpečnější práce s recordy, definice proměnných uvnitř bloku, výrazová orientace jazyka, náhodný přístup k souborům, dokonce printf... Původní Pascal byl dost omezující, byť teda ten kompilátor (jednoprůchodový) byl celkem jednoduchý a pekelně rychlý. Ale jasně, něco měl Pascal lepší.
Možná mě klame paměť, ale nebylo to porovnání s Algolem 68? Pascal je založený na Algolu 60 (potažmo X a W), Algol 68 se od těchto verzí dost lišil.

Jo, Algol 68 to byl. Teď to dává větší smysl, dík.

209
Já měl Pascal jen dávno v prváku, u zkoušky jsem ho viděl naposled. Ale minimálně výrazně ovlivnil jiné jazyky a napravil některé divnosti Algolu.

Tak jsem si pročetl srovnání Algolu a Pascalu od Tanenbauma (je to online v pdf) a musím říct, že v něčem ten Algol měl dost výrazně navrch. Bezpečnější práce s recordy, definice proměnných uvnitř bloku, výrazová orientace jazyka, náhodný přístup k souborům, dokonce printf... Původní Pascal byl dost omezující, byť teda ten kompilátor (jednoprůchodový) byl celkem jednoduchý a pekelně rychlý. Ale jasně, něco měl Pascal lepší.

210
To Ruby mě tedy zaráží - to je někde ve Švýcarsku, ne?
BTW proč zrovna Švýcarsko? Tamní IT trh neznám, ale v čem by se měli lišit?

Z nějakého důvodu jsem měl zafixováno, že tam působíš...

Stran: 1 ... 12 13 [14] 15 16 ... 43