Příspěvky

1396

Studium a uplatnění / Re:Má cenu studovat IT navazující?

« kdy: 09. 09. 2015, 13:23:08 »

Velmi zásadní znalostí z pusté informatiky je Chomského hierarchie. Nejenže kulturním antropologům a podobné humanitní pakáži padá čelist přeqapením, že ajťák zná Chomského a ještě ví, že ještě žije, ale dokonce zná tu část jeho práce, kterou h. p. považuje za nejsložitější. O to se prostě nemůžeš připravit.

Mám takovou hypotézu: čím míň člověk z exaktních věd zná, tím víc se cítí jako uebermensch a honí si triko nad tím, že to humanitně vzdělaná pakáž nezná. Zajímavý je, že ti, kdo tomu rozumí podstatně líp, mluví o humanitních vědách s daleko větší pokorou a uznáním. Nebo se jimi přímo doplňkově zabývají, jako třeba Jaroslav Nešetřil. Nemálo vynikajících matematiků si taky při nějakých pokusech o "filosofování" vylámalo zuby a jejich práce na tomhle poli jsou okrajové, ne-li rovnou úsměvné.

Takže jenom FYI: Chomský je známý v lingvista pro úplně jiné věci, které jsou v celku jeho díla daleko stěžejnější než hierarchie jazyků. Takže se moc neprs s tím, že znáš jeden malý, z pohledu celku spíš okrajový, výsek jeho díla. Abys ze sebe nedělal pitomce před někým, kdo toho o něm ví víc...

Teď už čekám jen na diskuzi o Chomského politických názorech.

1397

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 31. 08. 2015, 18:02:43 »

A vidite, kolik problemu je se stavem?

Normálně by mělo být Square extends Rectangle a evtl. MutableRectangle extends Rectangle. Tím se oddělí "zrno od plev" (funkcionální část objektu od té měnitelné). Ovšem lepší je mít vše immutable.

1398

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 31. 08. 2015, 15:42:40 »

Každý čtverec je obdélník.

Není - on tak jen vypadá. Čtverec má jeden atribut, obdélník má dva. 1 != 2.

Jasně, že je. Počet atributů s tím nemá co dělat. https://cs.wikipedia.org/wiki/Čtyřúheln%C3%ADk

1399

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 31. 08. 2015, 15:38:49 »

Short answer: Protocol-oriented programming: http://babel.blog.root.cz/2015/08/25/post-oop/

Long answer: Koncepční vztahy se deklarují pomocí protokolů. Např. každý tenzor je matice (ale ne naopak), každý vektor je tenzor a každý skalár je taky tenzor - jenže skalár je normální double (nebo komplexní číslo) a to už každý jazyk má a nedá se jim "podstrčit" nějaká nadtřída. Dá se ale říct, že vyhovují nějakému protokolu (a dodefinovat příslušné metody, např. pro derivaci tenzorových polí). Druhou výhodou je, že pak lze použít hodnotové typy, které z principu netvoří hierarchie (na rozdíl od tříd), ale zase program zrychlují. Sečteno a podtrženo: dědičnosti je lepší se úplně vyhnout.

Perfekní rozbor, ale bohužel chybný závěr. Hodnotové typy do OOP nepatří. Jsou tam jen proto, že je programátoři chtěli.

Protocol-oriented programming není OOP. Problém je, že žádný jazyk ho plně nepodporuje. Hodnotové typy jsou ortogonální koncept umožňující rychlejší a spolehlivější správu paměti (jako v C++, kde ovšem každý může rozhodnout pro každý objekt, chce-li ho mít na zásobníku).

1400

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 31. 08. 2015, 15:25:23 »

Short answer: Protocol-oriented programming: http://babel.blog.root.cz/2015/08/25/post-oop/

Long answer: Koncepční vztahy se deklarují pomocí protokolů. Např. každý tenzor je matice (ale ne naopak), každý vektor je tenzor a každý skalár je taky tenzor - jenže skalár je normální double (nebo komplexní číslo) a to už každý jazyk má a nedá se jim "podstrčit" nějaká nadtřída. Dá se ale říct, že vyhovují nějakému protokolu (a dodefinovat příslušné metody, např. pro derivaci tenzorových polí). Druhou výhodou je, že pak lze použít hodnotové typy, které z principu netvoří hierarchie (na rozdíl od tříd), ale zase program zrychlují. Sečteno a podtrženo: dědičnosti je lepší se úplně vyhnout.

1401

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 31. 08. 2015, 11:45:18 »

http://www.cs.utexas.edu/~wcook/papers/SafeQuery05/SafeQueryFinal.pdf

1402

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 16:27:41 »

A NQ interpretuje tedy libovolný nativní kód? To by byl ten principielní rozdíl oproti v SODA, kde jsou jen předpřipravené metody....

Libovolný ne, ale může se z toho vytvořit parciální dotaz, který předfiltruje objekty a zbytek se inicializuje a otestuje. NQ může být v podstatě cokoliv typu boolean.

Aha, v tom případě si nedokážu představit, jak NQ funguje. To jako analyzuju bytekód (v případě javy) a nahradím v něm nativní zápis dotazu za něco jiného? Vygeneruju kód na míru mému nativnímu dotazu?

V Javě jo. Jinak se (v nějakém lepším jazyce) z boolovského výrazu vytvoří AST a z něj následně OQL nebo cokoliv, co vzniká i ze SODY.
Ono to je celé hodně komplikované a jen to ukazuje, že dnešní OOP v praxi dost pokulhává (každý jazyk trochu jinak). Až bude Swift opensourcován, stačí přidat do něj implicitní konverze (což bude vlastně uncommenting vyřzeného kódu) a máme (z pohledu OODB) ideální jazyk.

1403

Vývoj / Re:Scala vs. Java 8.

« kdy: 30. 08. 2015, 16:12:49 »

Javě chybí to val (aka var/let), jinak výhody moc nejsou.

1404

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 16:09:53 »

Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

Ehm, není to přesně to samé? Nebo jde jen o ten bytekód (to nezní moc obecně)?

Myslel jsem to tak, že pro NQ je potřeba nějaká manipulace s batekódem (po kompilaci) anebo podpora v runtime (která s bajtkódem něco dělá za běhu), kdežto SODA jen jednoduše pospojuje řetězce a hotovo.

NQ jsou v podstatě záležitost compile time (v ideálním případě). SODA je záležitost run time.

1405

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 16:01:29 »

"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

Dobře, jak vznikne z NQ ten SQL?

OQL, ne SQL. To je právě ta magie. V Javě z bajtkódu, jinak se musí nějak poskládat AST. Když jsem si s tím hrál naposledy v C++, microsoftí překladač zkolaboval a v clangu jsem tak našel bug v linkeru. Swift to v poslední verzi zvládá hezky (operátor se dá přetížit několikrát s různými návratovými hodnotami a automatická inference typu udělá z "x == 100" buď bool nebo predikát podle místa použití - tak má ostatně OOP vypadat), jen ta implicitní konverze chybí.

1406

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 15:50:09 »

BTW v ideálním OO jazyce by to šlo přímočaře, jenže takový jazyk neexistuje. Je totiž potřebný přístup k AST. V jazycích s přetěžováním operátorů se to dá většinou nějak napsat, ale je to buď prasárna nebo nedokonalé. Swift by byl v tomto ohledu téměř dokonalý, kdyby měl implicitní konverzi typů, jenže ta by zase haprovala jinde (proto ji odstranili).

1407

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 15:13:41 »

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

Jasně, díky, už jsem se toho taky dovtípil - v NQ se ty podmínky zapisují pomocí java kódu (vezměme jako příklad javu), takže to vypadá, jakoby se podmínka vyhodnocovala přímo v javě (kde se ve skutečnosti vyhodnocuje to je jiná otázka, zřejmě se z bajtkódu vyganeruje sql). Například zde http://www.java-objects-database.com/jodb-general-section/help/native-query.html je příklad, kde se podmínka zapíše jako

Kód: [Vybrat]

return pilot.getPoints() > 100 && pilot.getPoints() < 500 ;

V SODA se uvádí název sloupce, takže by tam bylo něco jako

Kód: [Vybrat]

Query.from(Pilot.class).where("points > ?", 100).and("points < ?", 500).selectAll();

Jenže třeba Dari http://www.dariframework.org/ překládá textovou SODA-like syntax na predikáty http://www.dariframework.org/javadocs/com/psddev/dari/db/PredicateParser.html Otázka je, zda jde ve výsledku o NQ nebo SODA.

Která vrstva rozhoduje, jestli jde o NQ nebo SODA? Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

A za ORM byste teda považoval jen to, jakým způsobem se zabalí výsledek SQL dotazu do objektů?

"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

1408

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 14:45:45 »

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

S ORM to nemá nic společného. NQ je něco jako

Kód: [Vybrat]

Query(obj:MyObject in obj.field >= 1234)

kdežto SODA bude něco jako

Kód: [Vybrat]

Query(MyObject.self).whereField("field").geqThan(1234)

z čehož plyne, že NQ je lepší (z hlediska bezpečnosti, resp. kontroly během kompilace). Navíc SODA je ukecaný guláš. Na druhou stranu SODA je lepší než textové OQL v kódu.

Kdo zkusí implementovat NQ v různých jazycích, krásně zjistí, v čem se různé implementace OOP liší - každý jazyk v něčem hapruje, např. C++ nemá introspekci (ale preprocesor to nahradí), Swift nemá implicitní konverzi typů (v dřívější betě měl, ale už je pryč), v Javě se člověk musí hrabat v bajtkódu. Microsoftí C++ (CLI nebo CX) je na tom z tohoto pohledu asi nejlépe, ale zase to je okrajová záležitost.

1409

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 13:54:43 »

Mám dotaz víceméně ze zvědavosti. Líbí se mi koncept native queries: https://en.wikipedia.org/wiki/Native_Queries
Chápu, jak se to používá a v čem jsou výhody. Jak se to ale implementuje (např. v Javě nebo v C++)? C# má LINQ přímo v jazyku, ale např. u Javy nechápu, jak to udělali. Na webu je hodně příkladů použití, ale nic (jsem nenašel) o implementaci.

Je to magie ve všech jazycích (na rozdíl od SODA, což si lidi evidentně pletou s NQ). V Javě bych to psát nechtěl (překládá se bytecode do OQL). Jednodušeji to jde v C++, C++/CLI, C++/CX, Objective-C a úplně nejjednodušeji ve Swiftu (ale pořád musí být člověk borec, aby to napsal rozumně a použitelně). Dá se pak napsat něco jako

Kód: [Vybrat]

let objects = database.findObjects({ obj:MyObject in obj.someField <= 1234 })

Na rozdíl od SODA to je čitelnější a přirozenější (vypadá to jako lambda výraz, ale převádí se na OQL nebo něco podobného). Klidně se vsadím, že 95% (to je ještě opatrný odhad, možná i 99%) programátorů by to ale nenapsalo ani v C++, ani v ObjC, ani ve Swiftu - je to hodně advanced. Na druhou stranu hotovou implementaci může použít jednoduše každý a je to mnohem lepší než "string-based query interface" (viz odkazovaný článek).

1410

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 13:46:12 »

Koukni taky na http://www.jooq.org/ – umožňuje psát typově bezpečné dotazy. Je to někde na půli cesty mezi psaním čistého SQL a ORM.

Pleteš si (stejně jako perceptron) NQ a SODA.