Příspěvky

1576

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 12. 06. 2017, 12:10:30 »

Jen pro upřesnění, ne, že bych měl JSON nějak zvlášť rád:

Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.

Ne a ne. Jestli se JSON "3.0" vyparsuje jako int nebo float je nedefinované. Naopak zakódovat int 3 jako 3.0 je plně legitimní. Z čeho a jak plyne, že "logicky chci float", to fakt nevím. Od serializačního formátu především chci, abych z něj dostal to, co jsem do něj dal. Pokud to neplatí ani pro základní věc jako číslo, je to prostě debilní serializační formát a není o čem diskutovat.

Výraz nedefinované mi přijde krapet silné vyjádření. Každopádně v JSON je číslo definováno typem number. Který není ani Int, ani Float. Takže podobně jako když v Haskellu rozlišuju, čím budu reprezentovat JSON typ string - zda použiju typ String, typ Text, nebo ByteString; podobně i v případě JSON typu numeric musím přemýšlet čím ho budu v Haskellu reprezentovat. Protože s Intem si nevystačím (když tam chci ukládat Float, což jde).

Pokud bude ten parser rozumný, tak:

Kód: [Vybrat]

decode "1" -> 1.0 :: Float
decode "1.0" -> 1.0 :: Float
encode 1.0 :: Float -> "1.0" -- ale může i "1"
encode 1 :: Int -> "1.0" -- ale může i "1"
encode (9007199254740991+100) :: Int -> "\"9007199254741091\"" -- nebo spíše error "příliš velké číslo"
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen

Takže můžem nadávat na JSON, že je to debilně triviální jazyk. Můžem nadávat, že nám v něm schází to či ono. Ale spousta výtek jde spíše na vrub parserům v tom kterém jazyce.

1577

Vývoj / Re:Funktory v C++

« kdy: 10. 05. 2017, 13:34:28 »

V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.

To možná jo, ale přijde mi výstižnější. V Haskellu je typ type, a třída class. V javě se typu říká class a třídám interface. A v C++ je to ještě zajímavější.

1578

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 12. 04. 2017, 16:29:11 »

nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy

No, při zvažování jak to zoptimalizovat záleží na dalších aspektech, ne jen zda to jde. Něky převést to do OOP může být neoptimální.

Třeba já bych zvažoval, zda chci, aby objekty: Operator, DifferentLocation, LimitReached,... uměli zpracovat registraci a deregistraci. Dovedu si představit případ, kdy bych to považoval za nežádoucí a nechtěl bych, aby to znali.

1579

Vývoj / Re:Poraďte IDE vhodné pro Haskell

« kdy: 12. 04. 2017, 16:17:54 »

geany, terminál, ghci

1580

Vývoj / Re:PHP - proč se nevypisuje s datumem i čas?

« kdy: 04. 04. 2017, 13:49:48 »

Pomohlo, děkuji moc ;-)

Ach ty domaci ukoly...

Taky mohl mět prostě jenom zásek.

1581

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 04. 04. 2017, 13:48:27 »

Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

Programátoři obecně neumí OOP. A ti co se prsatí, že ano, těm se vyhejbej.

1582

Vývoj / Re:Elm - parsovanie zoznamu zanorených položiek

« kdy: 03. 04. 2017, 23:17:02 »

Chytil bych se té hodnoty zanoření.

Pokud je roven, generuju sourozence.
Pokud je větší zavolám rekursivně sebe sama a předám mu tail (ocásek zatím nepřežvejkaných prvků).
Pokud je menší, vrací strom vytvořených prvků, a zbytek ocásku.

Funkce dostane jako parametr seznam těch naparsovaných prvků a vrací vytvořený podstrom, a zbytek nezpracovaných prvků.

1583

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 23:02:56 »

Stačí nepoužívat veřejné *ettery a ztráta výkonu se stane nepodstanou. Také privátní atributy mají menší režii, než protected a public. Lokální proměnné mají nižší režii, než zmíněné privátní atributy. Když se to dá dokupy, vznikne z toho hezký a efektivní kód.

Uff!

1584

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 22:26:48 »

No a?

tím side-efektem jsi myslel změnu $_, nebo print? Print je tam nepodstatný, šlo ukázku použití $_ k ukládání mezivýsledků.

Tím side-efektem jsem myslel print. Zbytku nerozumím. Ve skutečnosti tam $_ ani nikde nevidím. Ale to je otázky mé neznalosti konkrétního jazyka. Takže asi nějaký lepší příklad.

1585

Vývoj / Re:PHP - proč se nevypisuje s datumem i čas?

« kdy: 03. 04. 2017, 22:24:08 »

No potřebuji získat datum a čas (aktuální)
Tohle taky nefunguje

Kód: [Vybrat]

<?php
$date = new DateTime('2000-01-01');
echo $date->format('Y-m-d H:i:s');
?>

Získání aktuálního data:

Kód: [Vybrat]

<?php
$date = new DateTime();
echo $date->format('Y-m-d H:i:s');
?>

Zadání konkrétního data:

Kód: [Vybrat]

<?php
$date = new DateTime('2000-01-01');
echo $date->format('Y-m-d H:i:s');
?>

Snad to pomůže.

1586

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 21:34:40 »

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]

while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

$_ ve while je lokální, dynamicky scopované. Jinak mohu napsat local $_; na začátku funkce.

No a?

1587

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 21:11:07 »

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

side efekty mohou být alternativou k vnořování funkcí. V perlu mohu napsat:

Kód: [Vybrat]

while(<>) {
    chomp;
    tr/ /_/;
    s/.*\.txt$/$&.old\n/;
    print if $&;
}

takový kód se mnohem snadněji debuguje než několik vnořených funkcí a současně nemusím vymýšlet názvy proměnných pro mezivýsledky. IMHO je to lepší než různá threading makra v lispech.

Takovej kód je v pořádku do okamžiku, dokavad je navrchu. Jakmile z něj uděláš funkci jsi v místě kam slunce nesvítí.
Zdůrazním: problém není vnořování funkcí ani vymýšlení názvů. Problém je side-efekt jako takovej. Prostě ten kód ti šáhne na výstup.

Bohužel ostatní nemohu komentovat, Perlem jsem nepolíben.

1588

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 15:03:04 »

zdokumentované side-efekty mohou vést květší přehlednosti.

Nevěřím.
Uznávám, že side-efekty někdy být musí. Ale měli by tě k tomu donutit technické omezení.

Někdy by-design rezignuju u akumulátoru (logger apod.). Hlavně proto, že pracuju s lidma, kteří mají zatím jen imperativní a OOP výchovu a s kódem z takového myšlení vzniknuvším.

1589

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 13:51:30 »

Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.

No... ne že by v tom přímo bránil, ale v OOP je víc špagetovacích možností... třeba právě dědičnost. Už jsem viděl objekt, který se jmenoval nějak mainobject, jedinou vlastností bylo nějaký ID a všechny ostatní objekty byly jeho potomkem. V podobném duchu se to neslo dál, takže než se člověk prokousal přes x úrovní, aby zjistil, proč se to se.. kazí, tak měl skoro fousatý děti.

Ano, to je takříkajíc ze života.

Zatímco zvrtej použití funkce. Teď z fleku mě napadají jen tyto způsoby:
- vracení hodnoty argumentem
- side-efekt
- vracení funkce (ne že by to bylo špatně, ale je to takovej kandidát na znečitelnění)
- ob rekurze (funkce `a` volá `b` a ta volá `a`)

1590

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 03. 04. 2017, 12:06:17 »

Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".

No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

Moje zkušenost je taková, že největší problém OOP je v tom, že ho prakticky nikdo neumí. Takže jako koncept je tímto dost naprd.

Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.