C# .NET vs. Java?

[Kit]

Kde to MS nerespektuje? Presne takto sa to chova aj v MS

Výsledkem SELECTu v relačních databázích je množina relací splňujících určitá kritéria. Dělá selekci i projekci. Součástí je i (nepovinná) klauzule WHERE, bez níž většina SQL dotazů postrádá význam, ale na kterou MS jaksi zapomněl. Zcela pak ignoruje ORDER BY, GROUP BY apod.

[Reklama]

[noef]

LINQ se snaží být univerzální, stejný kód lze používat pro kolekce i pro relační DB.

pouzivat terminologii relacni DB u kolekci je snad pouze v MS svete.

Na druhou stranu používat terminologii kolekcí pro relační DB asi také není úplně ideální.

To se deje presne kde? Vetsina jazyku to ma totiz tak, ze pro DB veci pouziva DB terminologii a pro obecne kolekce pouziva terminologii kolekci.

Všude ne. V relačních databázích je selekce výběr řádek a projekce výběr sloupců. MS to prostě nerespektoval a udělal to po svém.

V relacnych databázach SELECT vyberie/vrati vsetky s atributmi/stlpcami ktore mu zadefinujeme a NIC VIAC
SELECT stlpec1, stlpec2
FROM tabulka
...
Kde to MS nerespektuje? Presne takto sa to chova aj v MS

Ano, popsal jste nas problem. MS nerespektuje rozdeleni terminologie na relacni DB a kolekce.

A "Select" z C# opravdu mapuje (v terminlogii kolekci):

        var list = new List<int>{ 1, 2, 3 };
        var mapped = list.Select(x => "["+ x * 10 +"]");

vraci [10], [20], [30]. Tzn. ze nevybira polozky z puvodni kolekce (vysledky jsou retezce, nesedi ani typ), ale provadi jeji transformaci, ktera se bezne (viz linky vyse) oznacuje jako mapovani.

PS: Jak jsem bastlil ten snippet v C#, tak jsem si uvedomil, jak krasna funkce je (i castecna) type-inference - u List jsem musel uvest <int>, jinak to nesezral . Scala se svou castecnou type inference tohle nepotrebuje, ale samozrejme ze na takovy Haskell nema ani omylem.

Seq(1, 2, 3).map("[" + _ * 10 + "]")

[Radek Miček]

LINQ se snaží být univerzální, stejný kód lze používat pro kolekce i pro relační DB.

pouzivat terminologii relacni DB u kolekci je snad pouze v MS svete.

Na druhou stranu používat terminologii kolekcí pro relační DB asi také není úplně ideální.

To se deje presne kde? Vetsina jazyku to ma totiz tak, ze pro DB veci pouziva DB terminologii a pro obecne kolekce pouziva terminologii kolekci.

To se děje v LINQu. Je to dotazovací jazyk, který můžete použít pro SQL, Amazon, LDAP, RDF, kolekce atd.

Kolekce jsou pouze jeden specifický případ, tudíž nevidím důvod, proč se přizpůsobit zrovna jemu.

[JurP]

tiez si myslim, ze tie nazvy su robene preto tak, nakolko LINQ, ako uviedol kolega nado mnou, je dotazovaci jazyk. A ak pouzijeme LINQ, ktory sa dotazuje na nieco do DB a zaroven sa transformuje do TSQL, tak potom Select dava vyznam.

[死神]

Výsledkem SELECTu v relačních databázích je množina relací splňujících určitá kritéria. Dělá selekci i projekci. Součástí je i (nepovinná) klauzule WHERE, bez níž většina SQL dotazů postrádá význam, ale na kterou MS jaksi zapomněl. Zcela pak ignoruje ORDER BY, GROUP BY apod.

http://cs.wikipedia.org/wiki/LINQ#Kl.C3.AD.C4.8Dov.C3.A1_slova_LINQ

Nevšiml jsem si, že by na ně MS zapomněl.

[Reklama]

[JurP]

nechaj ho. on videl asi c# len vo vyklade v knihkupectve

[ded.kenedy]

Výsledkem SELECTu v relačních databázích je množina relací splňujících určitá kritéria.

A to odkdy?

[lobo]

ako tak pozeram, vela ludi absolutne nechape podstatu Linq a pletie si to s database query language...

odporucam pozriet si este take srandicky ako napriklad Reactive Extensions (Reactive Linq).
Existuje nieco podobne v jave(nemyslim nieco co si Frantisek nainstaloval vo verzi 0.23Beta, ale nieco realne pouzivane)?

[NooN]

nechaj ho. on videl asi c# len vo vyklade v knihkupectve

Pre neho je problem podla vsetkeho ze to nie je napasovane do jednej metody a nema to nazvane priamo v nazve.

Skoda sa tu o niecom bavit. Niekto sa spyta na "Kadial sa ide do obchodu" a postupne dostava odpovede typu "Cerveny stvorec neobsahuje suchy piesok lebo priehladne koliecko moze zabranit pocatiu".

Strata casu uz len citanim tych zvastov.

[Radek Miček]

odporucam pozriet si este take srandicky ako napriklad Reactive Extensions (Reactive Linq).
Existuje nieco podobne v jave(nemyslim nieco co si Frantisek nainstaloval vo verzi 0.23Beta, ale nieco realne pouzivane)?

Ano, existuje RxJava.

Pro Scalu existuje scalaz-stream - není to však knihovna z rodiny Rx, ale z rodiny Machines.

[ava]

ako tak pozeram, vela ludi absolutne nechape podstatu Linq a pletie si to s database query language...

odporucam pozriet si este take srandicky ako napriklad Reactive Extensions (Reactive Linq).
Existuje nieco podobne v jave(nemyslim nieco co si Frantisek nainstaloval vo verzi 0.23Beta, ale nieco realne pouzivane)?

https://github.com/ReactiveX/RxJava

A mám pocit, že dokumentace i otevřený přístup k vývoji jsou u RxJava dál než u Rx

[noef]

tiez si myslim, ze tie nazvy su robene preto tak, nakolko LINQ, ako uviedol kolega nado mnou, je dotazovaci jazyk. A ak pouzijeme LINQ, ktory sa dotazuje na nieco do DB a zaroven sa transformuje do TSQL, tak potom Select dava vyznam.

No, ano. MS si jde vlastni cestou, ocenuji, ze jste to uznal. LINQ je zajimava myslenka, ale nevim, jestli neni lepsi pristup vzit obecne operace nad kolekcemi jako vychozi bod a dotazy nad DB brat pouze jako podmnozinu problemu (tak to myslim implementuji i nektere Scala knihovny pro pristup k db).

odporucam pozriet si este take srandicky ako napriklad Reactive Extensions (Reactive Linq).
Existuje nieco podobne v jave(nemyslim nieco co si Frantisek nainstaloval vo verzi 0.23Beta, ale nieco realne pouzivane)?

Scala to myslim primo obsahuje, v Jave je mozne pouzit jako externi knihovnu - Akka (obsahuje i jine veci, nejsem si teda 100% jisty, ze se to nerozdelilo na vice knihoven a Akka nejsou uz jen actori).

Skoda sa tu o niecom bavit. Niekto sa spyta na "Kadial sa ide do obchodu" a postupne dostava odpovede typu "Cerveny stvorec neobsahuje suchy piesok lebo priehladne koliecko moze zabranit pocatiu".

Funguje se tu stejne, jako v ostatnich vlaknech - kdyz je puvodni dotaz zodpovezen, prejde se na pridruzene tema. V tomto pripade kritika Javy a C#.

Strata casu uz len citanim tych zvastov.

Nekteri az s nabozenskou vervou brani jeden jazyk (ze zacatku na me tak pusobili Javisti, ke konci C#isti). Kdyz se ale zjisti, ze MS to opravdu prasi dela po svem, tj. ignoruje zazitou konvenci a vymysli kolo, tak najednou je cele vlakno jen zvasty a oni se zlobi nad tim, jaka ze je to ztrata casu .


Myslim, ze kazdy jazyk slouzi k trochu jinemu ucelu.

Jak tu zaznelo drive, Java se dlouhodobe profiluje jako stabilni a zpetne kompatibilni za kazdou cenu (napr. ta generika, ze). Nove vlastnosti (napr. funkcionalni pristup ke kolekcim, lambdy atp.) se do jazyka dostava pomalu a casto syntaxe neni uchvatna kvuli zachovani kompatibility. Vypada to, ze tu s nami zustane jeste hodne dlouho.

Naopak C# se snazi pridavat co nejvice aktualne popularnich novinek. Je dost mozne ze skonci stejne jako C++, tj. dort pejska a kocicky. (Samozrejme je mozne, ze tak skonci i treba ta Scala. I kdyz tam uz nyni ma rada lidi neprekonatelne problemy s ucenim a pokrocilejsi veci jako ScalaZ je casto vnimana jako vec pro teoretiky, prestoze byl opakovane demonstrovan opak.)

Pokud chce nekdo neco pokrokovejsiho nad JVM (tj. vymanit se z omezeni stability a zpetne kompatibility), zkusi Scalu nebo neco dalsiho (Groovy, Kotlin?). Stejne tak v .NETu je hodne alternativ, ten jiz zminovany F# pusobi hodne solidne. Jazyk a platforma by se mely vybirat podle vlastnosti a vhodnosti pro danou ulohu.

[Radek Miček]

vzit obecne operace nad kolekcemi jako vychozi bod a dotazy nad DB brat pouze jako podmnozinu problemu (tak to myslim implementuji i nektere Scala knihovny pro pristup k db).

Záleží, jak se na to díváte.

Například bych očekával, že struktura, která má map, je funktor. Budou se však všechny implementace IQueryable chovat jako funktor? Myslím, že ne, neboť některé implementace nedokáží např. přeložit skládání funkcí, takže neplatí x.Select(Compose(g, f)) == x.Select(f).Select(g). Tudíž lze namítnout, že by se ta operace neměla jmenovat map.

[ava]

Záleží, jak se na to díváte.

Například bych očekával, že struktura, která má map, je funktor. Budou se však všechny implementace IQueryable chovat jako funktor? Myslím, že ne, neboť některé implementace nedokáží např. přeložit skládání funkcí, takže neplatí x.Select(Compose(g, f)) == x.Select(f).Select(g). Tudíž lze namítnout, že by se ta operace neměla jmenovat map.

Já bych to očekával také. Je ovšem otázka, jestli to, že existují implementace IQueryable, které nesplňují zákony funktoru, znamená, že bychom se neměli na IQueryable jako na funktor dívat. Takové implementace asi můžeme vytvořit v každém jazyce, a doufám že nekecám když budu tvrdit, že i v Haskellu je možné implementovat instanci typeclass Functor, která zákony Funktorů nesplňuje - ale to neznamená, že si v praxi zakážeme používat slovo map - nebo se mýlím? Musím se tu přiznat, že neznám C# a nevím, co přesně znamená že "některé implementace nedokáží např. přeložit skládání funkcí", takže možná nemluvím úplně k věci...

[noef]

Osobne to vidim podobne jako ava. Vubec by me nenapadlo, ze nekdy muze nastat situace, ze x.Select(Compose(g, f)) nevrati stejny vysledek jako x.Select(f).Select(g) . IMO takova implementace je dost nesikovna a zaslouzila by prepsani nebo odebrani.