Příspěvky

1156

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 06. 09. 2018, 16:20:53 »

Nojo... víš, to je tak: pokud v tom programu provedeme výměnu IO za třeba "Either SomeException" obalené nějakým WriterT, kde si odchytíme ty putStrLn, a všechny ty funkce budou na stejné vstupy dávat stejné výstupy, pak by tvůj program měl ve výsledku udělat totéž. To je tak nějak základem pure programování. Takže pokud taková transformace není možná, pak je tvůj program nekorektní. A vzhledem k tomu, že ty tvrdíš, že je korektní, tak bych očekával, že mi ukážeš, jak se to krásně udělá.

Toto bych zdůraznil.

1157

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 06. 09. 2018, 15:53:41 »

- A typy samotné jsou i vcelku obstojná dokumentace. Rozumné typy dost redukují potřebné množství okolního textu. A na rozdíl od názvů nebo komentářů vždycky odpovídají aktuálnímu chování kódu.

Mimoto názvy mají být v pořádku vždy, typované jazyky nejsou žádnou výjimkou (jak si mnozí myslejí).

Zde bych se odpíchnul já. Typy, a bavím se o statickém typování, vychází z předpokladu, že vše se zkontroluje předem (haskell). Zatímco netypové jazyky chtějí možnost opravovat to až za běhu (erlang). A pak jsou různé mezistupně, které pomáhají ke zmatení nepřítele.

1158

Vývoj / Re:Framework Nette pro dynamický web

« kdy: 06. 09. 2018, 13:24:35 »

Ale rozhodne by som nehovoril, ze frameworky su obecne zlo. To proste nie je pravda.

Samozřejmě že to není pravda. Že se nad tím vůbec pozastavuješ :-)

1159

Vývoj / Re:čisté OP smalltalk, objective C

« kdy: 05. 09. 2018, 21:42:16 »

c) PHP dodnes nemá ani datový typ textový řetězec! Namísto toho se musíte tlouct se sekvencí bajtů, dávat tomu nějaký význam a charset. Myslel jsem si, že ve 21. století si takovou nesmyslnost nedovolí žádný programovací jazyk na světě.

Tyhlencty polopravdy dávají věrohodnosti tvejm dalším příspěvkům děsně na zadek.

1160

Vývoj / Re:Framework Nette pro dynamický web

« kdy: 05. 09. 2018, 14:14:51 »

Ano bude to SPA, nevěděl jsem, že to má název (zkratku).

A co umíš lépe PHP, nebo Javascript? Jsi spíše fronteďák, co musí udělat i backend, nebo naopak?

1161

Vývoj / Re:Framework Nette pro dynamický web

« kdy: 05. 09. 2018, 13:01:10 »

Použili byste Nette pro dynamický web? Teď nemyslím nějaké to překreslení sem tam nějakého prvku, ale jde o různé šoupání tabulek (obdelníků), změna obsahu tabulek (načtení z DB), nastavení různých atributů (k tabulkám) a ve finále odeslání celé stránky (rozuměj toho layoutu) na server.  Co byste doporučili, pokud ne Nette?

Pokud znáš PHP, tak Nette bude dobrá volba. Chce to se s tím dobře seznámit. Oproti ostatním FW bych u něj vyzdvihl vlastnost, že je dosti volnej. Tudíž ti nebude klást zbytečné překážky, když budeš potřebovat si ten backend používat tím či oním stylem. Třeba jen json, nebo html snippety, etc.

Ale je fakt, že pokud jsem tvou otázku dobře pochopil, tak stejně většinu práce budeš dělat na klientu, v js.

Jak moc to bude SPA?

1162

Vývoj / Re:Proč ten hype okolo Go?

« kdy: 02. 09. 2018, 20:38:05 »

jasně alternativci... tak jo. vlasy nafialovo a pero dopr%dele. your way.

Otázka offtopic - proč jsi tak vulgární?

1163

Vývoj / Re:Proč ten hype okolo Go?

« kdy: 02. 09. 2018, 13:36:01 »

Je to psuedokod, ale aby ste boli spokojni

Kód: [Vybrat]

file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

1164

Vývoj / Re:Typový system versus unittesty

« kdy: 27. 08. 2018, 21:40:15 »

Já jsem to celé sice původně podával jako, že praktičnost mě až tak moc nezajímá

Když už jsme u té praktičnosti, řekněme, že mám funkci "double" pro násobení přirozených čísel dvěma a chci zaručit, že výsledek je sudý tím, že vracím (závislostní) hodnoty typu (n ** Even n). Jak ale zařídím, aby na lichých hodnotách typová kontrola selhala, resp. aby všechny relevantní funkce byly totální?

Možná ti nerozumím, ale tak nepřeloží se to, ne?

1165

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 25. 08. 2018, 22:53:56 »

Základním problémem OOP programování je imperativnost.

Jo.

1166

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 25. 08. 2018, 19:51:21 »

Ale mám obavy, že co není v hlavě, to kompilátor nespraví, ale u imperativních jazyků vynásobí, u funkcionálních spíš umocní. Proto ten současný funkcionální hype nesdílím, protože mám obavy, že jakmile by se to paradigma rozšířilo více do praxe, tak budeš mezi prvními, koho pak s tím infarktem doopravdy povezou. 

Mě se to nezdá.

Základním problémem imperativního programování je OOP. Vyžaduje příliš velký skill, aby se dal psát dobře. U FP skutečnost, že všechno je funkce, která nejde moc rozkošatit, tak to IMHO hodně sváže ruce kreativitě některých vývojářů.

Teda, moje úvaha je taková, že u FP jde vždycky špatný kód wrapnout, a postupně odlifrovat do zapomění. Zatímco u OOP se ty špagety někdy opravdu těško rozmotávají.

1167

Server / Re:Jak dokumentujete servery?

« kdy: 25. 08. 2018, 19:45:46 »

Jestli tomu rozumím dobře, tak je potřeba kvalitně využívat configuration management tool a spoléhat na to, že se v něm ostatní dokáží zorientovat?

Dala by se automaticky generovat dokumentace z toho configu třeba právě do MediaWiki.

1168

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 25. 08. 2018, 01:36:40 »

Hmm, takže pokud tě chápu dobře, tak tobě nevadí, že je Haskell lazy, či strict ale to, že vůbec má nějaké pragmy? Tak s tím bych se i stotožnil. Do optimalizace kódu by programátor kompilátoru neměl kecat. (Připomíná mi to hinty v Oracle či Postgresu.)

Z titulu svého zaměření se na pomezí asm a něčeho lehce vyššího pohybuji, často zkoumám listingy a mohu vás ubezpečit, že i céčkový kompilátor má k dokonalému kódu poměrně daleko.

Z titulu svého zaměření tě můžu ubezpečit, že věci, které dokáže vyplodit 80procent vývojářů... by tě chytl infarkt.

1169

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 24. 08. 2018, 22:52:17 »

No a o tom to celé je. Protože je Haskell lazy, píše se v něm kód, který funguje jen při lazy vyhodnocení a při strict ne. Na to není nic špatného. Jenom je potřeba počítat s tím, že lazy vyhodnocení má z principu vyšší overhead. To se vědělo od začátku. Pak ale někomu začalo vadit, že je Haskell moc pomalý a přemýšlel, jak ho zrychlit. Tak třeba bychom mohli udělat Haskell trochu strict... Co na tom, že rozbijeme existující kód... Mně se Haskell líbí, ale věci jako pragma strict jdou proti jeho designové čistotě a po pravdě moc nechápu, jak někdo z Haskell komunity může takovou věc obhajovat . Chápu důvody vzniku, nepřenesu se ale přes fakt, že to jde proti designu a filozofii jazyka, jen kvůli řešení výkonnostních problémů.

Hmm, takže pokud tě chápu dobře, tak tobě nevadí, že je Haskell lazy, či strict ale to, že vůbec má nějaké pragmy? Tak s tím bych se i stotožnil. Do optimalizace kódu by programátor kompilátoru neměl kecat. (Připomíná mi to hinty v Oracle či Postgresu.)

1170

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 24. 08. 2018, 15:07:35 »

Motáme se pořád v kruhu. Lazy vyhodnocení je hezké, ale má nezanedbatelný overhead. Pokud chci, aby Haskell nebyl lazy, jde to udělat, ale je to narovnávák na ohýbák, lazy kód tím rozbiju.

Už to tu zaznělo. Proč v C striktnost není ohýbák? Když v C použiju lazy techniky, tak se mi nemůže stát, že tím něco rozbiju (dosáhnu nežádoucího chování)?

V C neexistuje žádný přepínač "pragma lazy", existující strict kód v C nijak rozbít nejde.

V C nám nejde o strict, ale o lazy kód.
Ten jde IMHO rozbít docela snadno. Prostě si lazy načtu data a předpokládám, a když je načtu znova, tak očekávám (ten knihovní kód očekává), že se nepoužije cache. Nějaký side-effect, etc.

Viděl bych v tom stejnou opičárnou jako v Haskellu. Jen je to naopak.