Kniha Objektové programování od Čady

[JSfun]

Takže radši vyčistit zuby, vyčůrat a spát

Nehrozi, jeste dva dily Dirk Gently's Holistic Detective Agency. To je pokoukanicko pro nas, prd tomu rozumim ale bavim se 

[Reklama]

[klokan]

Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.

OOP smysl jednoznačně má, pokud se používá s rozumem a ne jako ideologie (stylu, že se s ním musí dělat absolutně všechno a všude a že absolutně všechno v progamu musí být objekt...). Jako kniha mi přišla dobrá "The C++ Programming Language" od Stroustrupa.

[denim]

Neco jeste jednodussiho nez JavaScript.

To už existuje. Lua je JavaScript done right.

Lua? To uz radeji Perl...

Btw v JS je implementovanej taky LuaVM, http://moonshinejs.org/ tolik prace a pritom takova blbost Dokonce i vlastni debugger je k tomu, jak by se nedaly pouzit chromacke map soubory ?

[Kit]

uz by sis mel napsat vlastni jazyk

Občas není jiné cesty.

Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.

[Ivan Nový]

uz by sis mel napsat vlastni jazyk

Občas není jiné cesty.

Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.

Nejen to, pojmenování tříd je de facto vlastní jazyk syntetického typu, něco jako inuitština, kdy jedno slovo pomocí prefixů, sufixů a skloňování má vyjadřovací schopnosti analytické věty. Vůbec nevadí identifikátory a zápisy tříd jako ModrySnihBrzyRanoPoMraziveNoci:roztal().

[Reklama]

[UF]

Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.

OOP smysl jednoznačně má, pokud se používá s rozumem a ne jako ideologie (stylu, že se s ním musí dělat absolutně všechno a všude a že absolutně všechno v progamu musí být objekt...). Jako kniha mi přišla dobrá "The C++ Programming Language" od Stroustrupa.

Haha - prvni pulka dobra ale s tim soustrupem si to totalne zabil

[UF]

uz by sis mel napsat vlastni jazyk

Občas není jiné cesty.

Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.

Nejen to, pojmenování tříd je de facto vlastní jazyk syntetického typu, něco jako inuitština, kdy jedno slovo pomocí prefixů, sufixů a skloňování má vyjadřovací schopnosti analytické věty. Vůbec nevadí identifikátory a zápisy tříd jako ModrySnihBrzyRanoPoMraziveNoci:roztal().

Tyvoe uz sem se lekl ze se tu neobjevis - mels dovolenou nebo co?

[UF]

uz by sis mel napsat vlastni jazyk

Občas není jiné cesty.

Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.

Zas bych to s tema jazykama neprehanel...

[Kit]

uz by sis mel napsat vlastni jazyk

Občas není jiné cesty.

Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.

Zas bych to s tema jazykama neprehanel...

Proto se dělají rozhraní, aby těch jazyků bylo méně a byl v nich přehled.

[SB]

Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?

A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...

To ale není chyba JSONu, ale způsobu, kterým serializujete/deserializujete. Když to necháte na nějakém obecném sráči (pokaždé jiném), nemůžete se divit, že vám z toho padají hovadiny. Každá entita má mít schopnost se sama serializovat a deserializovat. Každý datový model má svoje jedinečné entity...
Existují i jiné notace (např. STON), ale k výše uvedenému je nedoporučuju a považuju za nadbytečné.

[SB]

Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.

To souhlasím. Musím přiznat, že mě různé frameworky děsí pro jejich komplexnost a neprůhlednost. V případě problémů je to pak v pr-deli, protože dovnitř se nevidí. Příčinou obrovitosti může být snaha oněch frameworků o obecnost (typ "řeším vše"). Osobně za chybu považuju i přílišnou deklarativnost (něco jako antivzor programování v konfigurácích), čímž vzniká nový, deklarativní jazyk nad původním, tj. pouze náhrada jednoho problému jiným.

...takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...

(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)

To mohlo být nějakou chybou návrhu, aťto aplikace, nebo frameworku. Každopádně to vůbec neznamená, že nemůžu použít (vhodné!, vlastní ) ORM a abstrakci!

[SB]

ORM, ElasticSearch nebo objektove databaze maji smysl, kdy je potreba ukladat male mnozstvi dat aplikace, napr pro ukladani konfigurace si user preferences.

Toto tvrzení nedává žádný smysl. Jestliže ODB umí servírovat objekty, případně obsahuje nástroje pro hromadné operace (především vyhledávání), není důvod k výrazně většímu rozdílu v rychlosti, v případě správného návrhu domény to může být i rychlejší. Každopádně vždy jednodušší než RDBMS.

[Mirek Prýmek]

Když to necháte na nějakém obecném sráči (pokaždé jiném), nemůžete se divit, že vám z toho padají hovadiny. Každá entita má mít schopnost se sama serializovat a deserializovat.

Řekl kdo? Musím psát speciální deserializační funkci pro každou variantu datové struktury (NEbavím se o objektech) jenom protože proto?

A jaktože to v jiných formátech jde? Prostě mají uživatelsky definované typy a ty můžu použít třeba pro serializaci toho atomu - napíšu to jednou a bude mi to fungovat ve všech strukturách. To je špatně? Musím to psát stokrát podle toho, jestli se mi atom objeví v poli, objektu, jako standalone hodnota?

V JSONu by to šlo taky - a velice snadno. Stačil by jeden typ navíc, který by vypadal třeba takhle:

Kód: [Vybrat]

{{type: "atom", value: "myAtom"}}
- důležité je, že je odlišený od objektu, aby byly vyloučeny kolize s objektem

Kód: [Vybrat]

{type: "atom", someRandomGarbage: "blablabla"}
který se v principu v datech může objevit taky.

Ne, v JSONu to nejde, protože "webová specifika"...

[Mirek Prýmek]

To mohlo být nějakou chybou návrhu, aťto aplikace, nebo frameworku. Každopádně to vůbec neznamená, že nemůžu použít (vhodné!, vlastní ) ORM a abstrakci!

...což je přesně to, co jsem napsal: že přechytřelé ORM frameworky člověka nepozorovaně vedou do pekla.

[gll]

V JSONu by to šlo taky - a velice snadno. Stačil by jeden typ navíc, který by vypadal třeba takhle:

Kód: [Vybrat]

{{type: "atom", value: "myAtom"}}
- důležité je, že je odlišený od objektu, aby byly vyloučeny kolize s objektem

Kód: [Vybrat]

{type: "atom", someRandomGarbage: "blablabla"}
který se v principu v datech může objevit taky.

Ne, v JSONu to nejde, protože "webová specifika"...

JSON je původně javascriptová notace, která se rozšířila i jinam. Žádné atomy ve většině jazyků neexistují, tak nevím proč by je měl univerzální formát podporovat. Javascriptový string je to stejné co atom, jen to nezní cool. Není důvod ukládat jednu věc dvěma způsoby.