Příspěvky

871

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 05. 12. 2010, 17:19:06 »

Ruby moc rád nemám. Nicméně to co ukazuješ je čistě jedna povolná možnost, která se v určitých případech hodí. Pokud ji nechceš v projektu používat, nemusíš. Můžeš dokonce snadno statickou analýzou kódu vyloučit, že se daná možnost nebude používat.
 Nicméně jsou naopak případy, kdy se daná vlastnost velmi hodí. Např. pro opravu cizí knihovny, když do ní nechci zasahovat (např. proto, že případný upgrade této knihovny mi opravu zas rozbije).
Oheň není špatný, špatný je člověk, který s ním zapálí barák.

Stejnětak prototypová dědičnost. OOP se nerovná třídy a objekty. OOP jsou paradigmata, jak správně navrhnout architekturu programu. Samozřejmě, když se pomocí prototypů budeš snažit emulovat pouze třídní dědičnost, tak Ti zbydou jen nevýhody. Když se jí naučíš používat, tak zjistíš, že má daleko silnější výrazové prostředky než klasická třídní dědičnost a při zachování elementárních pravidel nebude o nic chybovější.

Že cizí knihovny mohou mít v JS sideefekty? To mohou mít i cizí knihovny v C#. Např. funkce na setřídění Ti může jednou za čas z pole něco vyhodit. Že se to nedělá a že je to prasečina? Ale to je i modifikování globálních objektů v JS. Buďto srovnávejme správně napsané knihovny, nebo špatně. Srovnávat dobře napsané knihovny v C# a špatně v JS je trochu nefér, ne?

Samozřejmě - můžeš furt jíst syrový maso a máš jistotu, že se nepopálíš. Někomu však to pečený za tu možnost stojí...

Teď mě ještě napadá:přístup JAVY: socialismus. Zakážeme vše potenciálně nebezpečné, co kdyby něco. Přístup javascriptu. Dovolíme skoro vše, je na Tobě jestli to ke své škodě zneužiješ či ne. Nevím jak ty, ale já bych si socialismus nevybral... (a to mám Javu rád).

872

Vývoj / Re: PostgreSQL - default language

« kdy: 05. 12. 2010, 13:39:06 »

Díky za odpověď :-) tušil jsem to, ale naděje žila :-)

Já pro editaci používám klasický editor, ale stejně i to copy/paste zdržuje a hlavně každej zbytečně opakovanej kus kódu vede k menší přehlednosti výsledného zdrojáku.

873

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 05. 12. 2010, 11:26:52 »

Změna rozhraní je totéž jako změna předka - prostě v okamžiku, kdy todle člověk musí udělat, tak byla provedena špatně analýza.

Nevím, o jaké koze se bavíš ty :-), ale já celou dobu upozorňuju, že to, co jsi napsal jako ukázkový příklad OOP: "potřebuji modifikaci vlastnosti objektu, tak z něj udělám potomka", nemá s OOP moc společného, protože to porušuje hned několik zásad OOP
- používá to dědičnost tam, kde nepatří
- nevede to k znovupoužitelnosti kódu
- nutí to modifikovat předka/rozhraní při implementaci potomka

874

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 05. 12. 2010, 11:21:28 »

T a k  j e š t ě  j e d n o u  a  p o m a l u .  : - )

Složitost v NP úplnosti je (trochu zjednodušuji) definována jako složitost na základě BITOVÉ délky vstupu.
n na vstupu bude efektivně kódováno pomocí m=log(n) bitů. Takže zanedbám-li počet
balení, na kterém to roste pomaleji, výsledná složitost je O(exp(m)^2).

edit: oprava log za exp, nějak mi to uteklo :-)

875

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 05. 12. 2010, 00:53:04 »

Tak, jak je definována složitost v NP úplnosti (pokud bude vstup zadanej efektivně), tak to polynomiální nebude. Viz předchozí post.

876

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 05. 12. 2010, 00:36:42 »

Takže pokud budu dělat zbraň na skřety, tak tam musím znovu zopakovat celou metodu jak se útočí a někam dovnitř tam vepsat modifikátor x2? Nebo jak.

A když takových zbraní vyrobím třicet, tak tam budu mít třicet skoroduplicitních kódů? A když pak budu chtít změnit algoritmus útoků všech zbraní.... No fuj.... To už snad radši ten neOOP přístup. :-)

Anebo z jiné strany - mám zbraň na skřety. Mám zbraň na draky. Jak z toho jednoduše vyrobím zbraň, která kombinuje vlastnosti obou?

Ono samozřejmě že OOP přístup je lepší (spíš bych řekl že je nejbližší realitě a proto přináší nejméně problémů), ale zrovna přístup chci modifikaci objektu, tak ho podědím je imho
velmi špatný.
Copak zbraň více zraňující skřety je něco "speciálnějšího" než zbraň? Copak ona umí něco více, poskytuje něco co běžná zbraň ne? Tak proč dědičnost? Zraňovat více skřety je vlastnost zbraně a jako taková by měla být implementována: tedy nikoli dědičností, ale agregací dané vlastnosti.

B je potomkem A který má navíc i draky tak budu reagovat na instanci B.

Fuj. To je právě to. A proč je zbraň která je na skřety i draky potomkem zbraně, která je jen na skřety a ne potomkem zbraně, která je jen na draky? Nebo potomkem obou? (což jaksi v javě/C# nejde a v C++ je zdrojem velkých problémů...

Můžu ale udělat i tu nestvůru. Změním její metodu příjmu zranění.

To můžu, ale dostanu se do stejnejch problémů u nestvůry, která bude skřet i drak (skřetodrak, no fuj :-) ).

Pokud chci zavést nový typ všeobecněji - bude třeba změnit rozhraní a udělat refaktorizaci. Včetně databáze. ..... U ostatních, co si někdo splácal na koleně to vyhodí chybu implementace rozhraní - nebudou mít metody které jsem přidal.

Bavíme se o OOP? Já měl za to, že v OOP implementace potomka NESMÍ zasahovat do implementace předka. Pokud pro novej typ musím modifikovat předka, něco jsem udělal špatně...
Právě proto, aby fungovali i objekty, co napíše někdo jiný...

877

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 04. 12. 2010, 23:37:40 »

2) to není tak jednoduché - takhle si z toho udělal exponenciální problém. Při vhodném vstupu (samá prvočísla) Ti s každým kusem vstupu (jeden typ balení navíc)  vzroste složitost k krát, kde k je to prvočíslo...
3) A další kolo! Je NP. Jak zakóduješ chtěný počet n balení? Pomocí log(n) bitů.Takže závislost na velikosti vstupu m je exp(m)^2. A NP úplnost pracuje právě se složitostí v závislosti na délce vstupu: viz definice NP-úplnosti (třeba na wiki, je tam vcelku slušně). Pseudopolynomiální je ten algoritmus PRÁVĚ proto, že sice závisí polynomiálně, ale na něčem jiném, než na velikosti vstupu.
Vzhledem k tomu, že jak jsem ukázal ve 2, tak nsnb při vhodném vstupu roste exponenciálně, tak Tě myslím nezachrání ani omezení pomocí nsnb, byť je to hezká myšlenka.

Nic jsi tedy zatím neprokázal :-), ale stejně, na zdraví :-)

878

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 04. 12. 2010, 23:11:18 »

Tak jak bys to teda vyřešil pomocí rozhraní? :-)

(IMHO rozhraní Ti tady právě zas až tak nepomůže... ale třeba se pletu....)

879

Vývoj / PostgreSQL - default language

« kdy: 04. 12. 2010, 23:06:06 »

Asi sem blbej, že to nemůžu najít, ale jde někde v postgresu předepsat, jaká je defaultní language pro uložený procedury? By člověk nemusel psát u každý language plpgsql. Už mě to štve.... :-) Nevíte někdo?

880

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 04. 12. 2010, 22:52:42 »

Hezkej postřeh s nsnb, ale jinak

1) proč by mělo být zadání kde není balení po jednom kusu nelegální? Proč nemůžu mít balení se čtyřmi kusy a chtít jich osm. Obzvlášť, když mohu vyhazovat, tak mohu složit libovolný počet, stačí a by bylo alespoň jedno balení.
2) pokud můžeš vyhazovat, tak přeci musíš prohledat i stavový prostor nad počtem kusů, nestačí to utnout počtem kusů.
3) složitost je opět na požadovaný počet kusů, takže pseudopolynomiální
4) kostra tohodle řešení tu byla už asi třikrát :-)¨)

881

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 04. 12. 2010, 22:42:12 »

Ne že bych byl proti OOP, ale právě to co jsi teď postnul ukazuje limity OOP v Javě/C# a nadužívání dědičnosti.

Chci zbraň co dává 2x drakům. Podědím ze zbraně. Chci zbraň, co dává 2xskřetům. Ok, také podědím ze zbraně. No a teď chci zbraň, co dává jak 2xdrakům, tak 2xskřetům. A z čeho ji mám podědit?
Např. podědím-li jí opět ze zbraně, dosti špatně pak budu implementovat nestvůru, která je zranitelná právě jen zbraněmi, které dávají minimálně 2x skřetům, protože mám dvě nesouvisející třídy, které obě popisují zbraň s danou vlastností.

Jojo, OOP rulez, ale ani OOP nezaručí jednoduchou a na první pohled jasnou architekturu programu...

882

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 04. 12. 2010, 18:19:28 »

jojo, balíčků je neomezené množství, takže se to nedá dělat podle balíčků, ale podle počtu balíčků (začnu na nula balíčků a vždy k nejlepší ceně přidám všechny možné balíčky a tím upravím vyšší počty a skočím na počet o jedna větší).

883

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 03. 12. 2010, 20:47:34 »

Bobr: To já programuju zásadně objektově:
program.goto(radka)
:-D

Dekel: Jazyk porušuje principy OOP? Já měl za to, že jedinej , kdo je může porušit je programátor. Jazyk k tomu akorát může či nemusí dávat vhodné vyjadřovací prostředky.
Jinak také se obávám, že OOP tady nepochopil nikdo jiný - a ve slušné diskusi je zvykem
svá tvrzení podkládat argumenty a ne vytvářet flametvorné výkřiky do tmy :-)

884

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 02. 12. 2010, 13:12:40 »

JS: To jsem neznal. A je to fakt dobrý :-)

885

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 01. 12. 2010, 20:30:55 »

Na druhou stranu si nenamlouvam ale ani to ze aplikace se sklada jen z algoritmu a ze tudiz kdyz "Žádnej OO popis algoritmu neexistuje" tak z toho plyne ze neexistuje ani OO program.

Ale to já netvrdím. Já jsem taky zastánce OOP. Akorát tvrdím, že OOP řeší jiné problémy než procedurální programování. Prostě jsou OOP procedurální jazyky (např. C# nebo Java) a OOP deklarativní jazyky (CLOS nebo ten paper co jsem postoval) takže říkat, že OOP je lepší horší než procedurální programování je prostě blbina, stejně jako nejde říct, jestli je lepší mlýnek na maso nebo pánev.

No a druhá věc, kterou tvrdím je, že většina dnešních jazyků má natolik obdobné vyjadřovací schopnosti, že daleko víc záleží na knihovnách, než na samotném jazyku. Proto jsou např. tak placení Javovští programátoři. Ne za Javu samotnou (jazyk samotnej se člověk naučí za pár hodin), ale za znalost knihoven (spring, hibernate atd...).

Následující už je spíše dojem, to nemám nijak podložené fakty:
Proto také C# připadá hodně "samostatným vývojářům" tak produktivní - jeho knihovny jsou hodně cílené na RAD. Zatímco Java (a hlavně její knihovny) je víc cílená na korporátní projekty (např. existuje C# ekvivalent hibernate?) - proto není tak obratná na RAD, ale zároveň proto je i tak dobře příjmaná na velké projekty.