Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: javista 22. 02. 2015, 19:31:30
-
Hoj, mam problem si najst pracu v nasom meste ... ak si clovek pozera pracovne ponuky je to sami .net developer, na pracovnych pohovoroch tak isto sa ma potencionalny zamestnavatel snazil ukecat na .net framework. Aky mate nazor na to vy? Oplati sa jave venovat nadalej a odist za pracou inam alebo konvertovat na C# ? Co sa do buducnosti viac oplati ? Vdaka
-
Drž se Javy a hledej dál.
-
+1
java zije a bude zit
-
A neni to jedno ?
-
Nejak nechapu tu specializaci na jeden jazyk to cloveka preci strasne svazuje.
Programatorovi je jedno v cem pise, max si lehce zabrbla ze v tom nebo tom by tohle bylo lepsi, ale nakonec to napise v cem si zakaznik preje, obcas se stane ze si necha zakaznik poradit ze v necem jinem by to bylo lepsi.
-
A neni to jedno ?
Jedno je kolečko u tragača. Když několik let strávíš s Javou, tak není rozumné vše zahodit a začít znovu s C#.
-
Programator by mal byt schopny prejst z javy na c# za kratky cas. Syntakticky je java podmnozina c#, na dalsie funkcie jazyka (linq, async/await, ...) sa da velmi rychlo zvyknut. Problem je potom prejst naspet na javu :)
-
Nejak nechapu tu specializaci na jeden jazyk to cloveka preci strasne svazuje.
Programatorovi je jedno v cem pise, max si lehce zabrbla ze v tom nebo tom by tohle bylo lepsi, ale nakonec to napise v cem si zakaznik preje, obcas se stane ze si necha zakaznik poradit ze v necem jinem by to bylo lepsi.
Java a C# jsou syntakticky dost podobné, to je fakt. Liší se však knihovnami, zvyklostmi a celkově se v nich programuje rozdílným stylem - v C# spíš procedurálně, v Javě spíš objektově (jak kdo). Přechod nemusí být zcela bezbolestný a trvá pár měsíců i let.
-
Neviem, či sa pýtaš na správnom fóre, či prejsť na M$ technológiu :) Ja by som odporúčal venovať aspoň jeden večer C# a skúsiť si Visual Studio.
Ja som bol roky C++kár, a v práci som prešiel na C#, prechod bol v pohode, je to veľmi intuitívny jazyk a výborný framework (hlavne linq), veľmi dobré IDE (ale nájdu sa aj chyby) dnes si neviem predstaviť, že by som biznis aplikácie, čo robím v práci, robil v C++.
Po mojom prechode na C# som si doma skúšal bez nejakého štúdia Javy napísať v jave android hru štýlom že napíšem to ako v C# a uvidím, čo to spraví :)
Podarilo sa mi to napísať, ale mal som pocit, že som sa vrátil o 10 rokov dozadu a Eclipse, aj adroid developer sa mi zdali ako v praveku, všetko pomalé, nesympatické.
Možno je chyba, že som Javu nenaštudoval a ušla mi väčšina toho, čo dokáže, ale už len tie prostredia a Andorid SDK ma nadobro odradili.
Aby som to zhrnul, tak C# sa mi zdá ďaleko ergonomickejší, zrejme je kvôli kompilácii rýchlejší, ale o Jave veľa neviem, takže moje porovnanie môže byť značne neobjektívne, preto by som bol zvedavý na názor niekoho, kto pozná dobre oba svety,
alebo niekoho, kto z Javy skúsi prejsť na C# :)
-
Drž se Javy a hledej dál.
+1
-
Nejak nechapu tu specializaci na jeden jazyk to cloveka preci strasne svazuje.
Myslíš, že nějaký lojza, který umí jen jazyk, bude k něčemu? A jak funguje JVM nebo konkrétní aplikační server? Jaké algoritmy používá standardní knihovna? Jak vše funguje? Fakt to zvládneš během chvíle u pěti jazyků a budeš si to pamatovat?
-
Pokud to je v okolí zoufalé a nechceš se stěhovat, přejdi na to, co trh žádá. To je naprosto normální a netřeba dělat ze znalosti programovacího jazyka životní filozofii.
Můj seznam jazyků, které jsem využíval/využívám ke své obživě.
-Delphi (2002-2004)
-PHP (2003-2009)
-Java (2005-2011)
-ABAP (2007)
-Javascript (2014)
-
Java je dost pozadu oproti C# a totéž platí o JVM oproti CLR. Navíc nic nenasvědčuje tomu, že se situace zlepší, tudíž nevidím důvod, proč nepřejít.
-
Takové kacířské řeči vést tady na Rootu ;D
2 javista: Tak schválně, jakou odpověď bys čekal na fóru fanoušků Microsoftu? A jakou odpověď u fanoušků od Apple? A jakou čekáš tady na Linuxovém fóru co? ;D
Ve tvém případě tedy doporučuji nejprve se naučit myslet a až pak začít pořádně programovat ;D
-
Jazyk je jen nastroj. Pokud dostanes zadani "Napiste desktopovou aplikaci pro windows", tak to asi budes psat v c#. Pokud to bude nejaka server backend zalezitost bezici na linuxu tak zrejme java a pokud neco vic na vykon, grafika etc. pak asi c++.
Naucit se zvyklosti a knihovny nejakou dobu trva, to jiste. Zalezi co chces byt, jeslti koder, ktery zna dokonale specifikaci a knihovny nebo vyvojar, ktery to bere abstraktneji a pocita s tim ze v dostacne rouzmne dobe se nauci "best practicies" a vhodne knihovny daneho jazyka. Abych uplne nekecal, dobra vec je naucit se dokonale aspon jeden jazyk, zbytek uz tak nejak jde sam.
Zalezi taky co presne delas, pokud mas dost casu (rok a vic) na dany projekt, tak se to proste naucis skutecne do detailu na "expert level" za pochodu.
Osobne treba pokud bych se mel stat spickovim CSS koderem, tak bych v exremu zrejme projizdel a debugoval C++ kody webkitu a koukal se jak presne tam jsou CSS pravidla pocitany a pouzivany, ciste proto, protoze hola specifikace je casto malo a potrebujes si udelat jasno v nejakych edge pripadech.
Sam jsme trreba spis javista, ale v podstate mi to je jedno v cem bych mel psat, pokud bych musel neco delat v c# nebo v c++ a byl by tam padny duvod proc v techto jazycich, tak nemrknu ani okem a bud to psat v nich.
-
Java je dost pozadu oproti C# a totéž platí o JVM oproti CLR. Navíc nic nenasvědčuje tomu, že se situace zlepší, tudíž nevidím důvod, proč nepřejít.
muzes by konkretnejsi v cem je JVM pozadu oproti CLR?
-
Mozno ta to prekvapi ale ak sa naucis novy jazyk nezabudnes automaticky ten stary...
-
Java je dost pozadu oproti C# a totéž platí o JVM oproti CLR. Navíc nic nenasvědčuje tomu, že se situace zlepší, tudíž nevidím důvod, proč nepřejít.
muzes by konkretnejsi v cem je JVM pozadu oproti CLR?
- CLR podporuje optimalizaci tail volání (JVM ne a je to velký problém při implementaci funkcionálních jazyků).
- CLR povoluje delší metody než JVM (na tento limit JVM lze narazit např. v jazycích s makry).
- CLR má reifikovaná generika (jejich absence v JVM komplikuje specifikaci Javy).
- CLR podporuje práci s ukazateli.
- V CLR lze deklarovat vlastní hodnotové typy.
-
- CLR povoluje delší metody než JVM (na tento limit JVM lze narazit např. v jazycích s makry).
Tohle bych viděl spíš jako výhodu JVM. Kdo potřebuje dělat dlouhé metody?
-
* tco nie su
* long methods su problem asi v scale ked sa nageneruje prilis dlhy kod
* reifikovane generika sa zial nedali dat lebo spatna kompatibilita nepustila
* pointre netreba
* value types su naplanovane do javy 9
pre standardneho vyvojara nic co by mu nedavalo spavat po nociach
Možno je chyba, že som Javu nenaštudoval a ušla mi väčšina toho, čo dokáže, ale už len tie prostredia a Andorid SDK ma nadobro odradili.
android uz zmigroval na intellij-based android studio a to je trochu iny level.
eclipse je z trojice ide: eclipse / netbeans / intellij asi najviac pozadu z hladiska editorov
-
* tco nie su
Pokud chcete programovat funkcionálně, tak absence TCO je velký problém. Můžete to obejít pomocí trampolín, ale za cenu velkého zpomalení.
long methods su problem asi v scale ked sa nageneruje prilis dlhy kod
To je potenciálně problém pro každý generátor kódu - např. pro Tomcat, pro JavaCC, pro jazyky s makry.
pointre netreba
V některých případech se tak lze vyhnout použití C++.
-
- CLR podporuje optimalizaci tail volání (JVM ne a je to velký problém při implementaci funkcionálních jazyků).
Proc je to velky problem? Neni to veci toho jazyka? (a kdyz uz jsme u toho, jsou funkcionalni jazyky bez TCO a programuje se v nich nadherne :), vlastne me i lip, protoze nemusim zkoumat, co je tail call a co jen mizerna rekurze...
Nicmene ten chudak, co se ptal na C#/Java je ted asi hodne zmateny; vlastne dobre mu tak, at vita v realnem svete.
-
pointre netreba
V některých případech se tak lze vyhnout použití C++.
Použití C++ se dá vyhnout i bez pointrů. Obvykle stačí umět programovat.
-
goetz povedal ze o tco vedia ale vidim to tak ako dokoncenie slovenskej dialnice na rok 2025
z dvoch jazykov co maju co povedat k funkcku a su na vzostupu, to obisli-neobisli
scala ma anotaciu tailrec ktora vas sprudi ked to tailrec nie je a nechavam to na developera. asi to nepotesi ale chapem to tak ze to nie je vec na ktore by zatial buduci funkcionalny programatori nadavali
clojure to tak isto obisli nejakou fintou
rovnako sa workarounduje ten random method size limit
ako som pisal je to neprijemne ale ani jedna vlastnost nie je taka zeby vobec robila vyznamne faktory rozhodovania ci java alebo c# alebo hovorila cokolvek o buducnosti vyvoja platformy
jazyk ako syntax je tu naozaj len drobnost. co je dolezite je znalost kniznic stylu vyvoja a veci okolo toho.
-
- CLR povoluje delší metody než JVM (na tento limit JVM lze narazit např. v jazycích s makry).
Tohle bych viděl spíš jako výhodu JVM. Kdo potřebuje dělat dlouhé metody?
Treba ja. Java kod nepisou jen programatori, ale nekdy ho generujou i ruzny tooly.
Presvedcit parser generator, ze Java ma tohle omezeni je opravdu tezky.
Krome vsech "znamych" metod ma kazda trida i metodu "sinit", ktera inicalizuje vsechny staticke promenne.
Ve vysledku pokud zabira prechodova funkce stavoveho automatu 64KB, tam je to velkej problem, to rozsekat do vice trid.
-
Tohle bych viděl spíš jako výhodu JVM. Kdo potřebuje dělat dlouhé metody?
Treba ja. Java kod nepisou jen programatori, ale nekdy ho generujou i ruzny tooly.
Presvedcit parser generator, ze Java ma tohle omezeni je opravdu tezky.
Krome vsech "znamych" metod ma kazda trida i metodu "sinit", ktera inicalizuje vsechny staticke promenne.
Ve vysledku pokud zabira prechodova funkce stavoveho automatu 64KB, tam je to velkej problem, to rozsekat do vice trid.
K čemu jsou dobré statické proměnné? Podle mne jsou jen pro zlost a kvůli nim se programy nedají ani pořádně testovat.
64KB? To už musí být pořádné zvěrstvo.
-
Proč zvěrstvo? Generovaný kod nemusí být pěkný a čitelný, nikdy ho nebudete opravovat.
-
Proč zvěrstvo? Generovaný kod nemusí být pěkný a čitelný, nikdy ho nebudete opravovat.
Záleží na tom, jaké vstupní parametry ten generátor dostane. Také záleží na kvalitě toho generátoru - nevidím důvod, proč by měl generovat prasekód.
-
Krome vsech "znamych" metod ma kazda trida i metodu "sinit", ktera inicalizuje vsechny staticke promenne.
Ve vysledku pokud zabira prechodova funkce stavoveho automatu 64KB, tam je to velkej problem, to rozsekat do vice trid.
Statické proměnné v projektu nemají co pohledávat, kromě odůvodněných případů.
64 KB byl naposledy problém ve Windows 3.11, překvapuje mě že jsou s tím stále potíže, nepřekvapuje mě že se tak děje u Javy.
-
64kb limit je historicky dany a je na viacerych miestach v jvm
problem je ze chcipaju projekty kde sa napr generuje gramatika (antlr) alebo zmienene staticke polia alebo staci sa sa okolo metody dynamicky doda nejaka instrumentacia a uz sa limit presiahne
-
64kb limit je historicky dany a je na viacerych miestach v jvm
Ten limit je na třídu nebo na metodu?
-
Odpověď je třeba hledat v původní otázce - proč máš problém v malém městě najít práci na Javu a nabídky jsou hlavně na C# ? Protože v C# se dělají malé hračky.
Takže odpověz si sám - chceš skončit jako desktop developer nebo big cloud systems developer?
Polovina věcí, která zde byla prezentována jako výhoda C# by mohla být klidně brána jako nevýhoda.
IMHO měl dotnet náskok, co se týče desktopu, ale s JavaFX se situace změnila. Za druhé, koho dneska zajímá desktop, že - zase je to o tom, jakou práci bys chtěl dělat.
Používám aktivně obě technologie a hlavní rozdíl, který tam vidím, je výrazně horší čitelnost v C#. V zásadě všechny ty věci, které umožní napsat o něco méně kódu (using namespace místo import class, extension methods, var místo typu - tam má bohužel Java už taky tendence) se při čtení kódu obrátí proti autorovi. A základní pravidlo říká, že kód, který je jednou napsán, bude tisíckrát přečten.
Za druhé bych zmínil nestandardní řešení pro běžné problémy. Například tam kde Java, Gtk, Qt používá css pro témata, používá C# vlastní WPF definice. Navíc nekonsistence naming convention s frontend technologiemi (javascript) může taky práci komplikovat, pokud sdíliš část kódu mezi klientem a serverem.
V zásadě vzato, pokud člověk zůstává v dotnet světě, tak jak jej nadefinoval Microsoft, tak je do jisté velikosti projektu relativně snesitelné. Pokud začne používat third party produkty, které by navíc v plné míře využívaly výše uvedených vlastností C#, tak vítej v pekle.
-
Statické proměnné v projektu nemají co pohledávat, kromě odůvodněných případů.
64 KB byl naposledy problém ve Windows 3.11, překvapuje mě že jsou s tím stále potíže, nepřekvapuje mě že se tak děje u Javy.
Nez se tady zacne zase jen tak nadavat na Javu (coz me uz nevadi, jen houst, odradte ty mladsi ;), tak si shrnme limity:
1) pocet polozek v constant poolu max. 2^16 (polozka = bud int/float, reference nebo 2 polozky na long/double, takze taky zadne velke omezeni)
2) pocet implementovanych rozhrani 2^16 (to snad nikoho neomezuje)
3) pocet metod 2^16 pro tridu
4) pocet atributu 2^16 pro tridu
5) pocet vsech atributu pro metodu 2^16 (sem spada vsechno, i debug info)
6) velikost lokalniho zasobniku 2^16
7) velikost kodu 2^32!
8) pocet bloku try/catch 2^16
Je to skutecne takove mega hrozne omezeni, jak se nekdo snazi psat?
-
Krome vsech "znamych" metod ma kazda trida i metodu "sinit", ktera inicalizuje vsechny staticke promenne.
Ve vysledku pokud zabira prechodova funkce stavoveho automatu 64KB, tam je to velkej problem, to rozsekat do vice trid.
Statické proměnné v projektu nemají co pohledávat, kromě odůvodněných případů.
64 KB byl naposledy problém ve Windows 3.11, překvapuje mě že jsou s tím stále potíže, nepřekvapuje mě že se tak děje u Javy.
Problem je v tom, ze pri generovani kodu se neda presne predikovat kdyz presne to "pretece". To pozna az kompilator kdyz zkompiluje generuje bytekod. Staticka promenna (pokud je const) taky neni problem. At uz je to byte[] anebo neco slozitejsiho tak je to jedno,
slouzi to k ulozeni rozhodovaci fce, DFA whatever.
V C/C++ na linuxu se da pouzit objcopy, takze se takovy "blob" a aplikaci muze vymenit i bez rekompilace. V jave se zase muze soubor zabalit soubor do Jar-u a behem initializace to nacist do pameti, ale neni to tak pohodlny a vyzaduje to dost drbani.
-
64kb limit je historicky dany a je na viacerych miestach v jvm
Ten limit je na třídu nebo na metodu?
Na metodu, a to jeste jen kdyz se pouziji debug info. Hele tady si lidi jen honi triko, jake maji skvele generatory (evidentne ne tak skvele :-), v praxi to muzes ingorovat, na limity prakticky nenarazis :)
-
Nez se tady zacne zase jen tak nadavat na Javu (coz me uz nevadi, jen houst, odradte ty mladsi ;), tak si shrnme limity:
...
Je to skutecne takove mega hrozne omezeni, jak se nekdo snazi psat?
Myslím si, že pokud by místo 2^32 bylo 2^16 a místo 2^16 bylo 2^8, tak by to většina vývojářů ani nepoznala. Poznaly by to však blbě napsané generátory.
Jak jsem našel v jiném diskuzním fóru: Pokud metoda překročí 8 KB, je příliš dlouhá a měla by se rozdělit.
-
Odpověď je třeba hledat v původní otázce - proč máš problém v malém městě najít práci na Javu a nabídky jsou hlavně na C# ? Protože v C# se dělají malé hračky.
Male hracky :]
http://w3techs.com/technologies/overview/programming_language/all
-
Odpověď je třeba hledat v původní otázce - proč máš problém v malém městě najít práci na Javu a nabídky jsou hlavně na C# ? Protože v C# se dělají malé hračky.
Takže odpověz si sám - chceš skončit jako desktop developer nebo big cloud systems developer?
To je pravda, bohuzel je taky pravda, ze zpracovani big dat v jave jen jedna obrovska sracka. Na planovane distribuovane zpracovani je to dobry, ale pokud potrebujes od systemu realtimove odezvy, tak ses v zadeki, nebo se musis uchylit k jni, nebo k tem "pointrum" (minimalne do javy 7 vcetne).
-
Myslím si, že pokud by místo 2^32 bylo 2^16 a místo 2^16 bylo 2^8, tak by to většina vývojářů ani nepoznala. Poznaly by to však blbě napsané generátory.
Jak jsem našel v jiném diskuzním fóru: Pokud metoda překročí 8 KB, je příliš dlouhá a měla by se rozdělit.
No jasne, proc neudelat 10x komplikovanejsi generator, aby generoval prekrasnej, ale neefektivni kod, kterej stejne nikdo necte...`
-
No jasne, proc neudelat 10x komplikovanejsi generator, aby generoval prekrasnej, ale neefektivni kod, kterej stejne nikdo necte...`
Kdo tvrdí, že elegantní kód musí být neefektivní? Právě naopak. Nejrychlejší kódy, které používám, jsou velmi přehledné.
-
Myslím si, že pokud by místo 2^32 bylo 2^16 a místo 2^16 bylo 2^8, tak by to většina vývojářů ani nepoznala. Poznaly by to však blbě napsané generátory.
Jak jsem našel v jiném diskuzním fóru: Pokud metoda překročí 8 KB, je příliš dlouhá a měla by se rozdělit.
No jasne, proc neudelat 10x komplikovanejsi generator, aby generoval prekrasnej, ale neefektivni kod, kterej stejne nikdo necte...`
docela prehanis vid? A jestli je skutecne "limit" v delce static bloku (jak nekdo psal vyse), tak to je humus nejvetsi, podivejte se, co se generuje pri inicializaci statickeho pole a potom povidejte o efektivite.
-
No jasne, proc neudelat 10x komplikovanejsi generator, aby generoval prekrasnej, ale neefektivni kod, kterej stejne nikdo necte...`
Kdo tvrdí, že elegantní kód musí být neefektivní? Právě naopak. Nejrychlejší kódy, které používám, jsou velmi přehledné.
Netvrdi to nikdo.
Treba v pripade konecnyho automatu je nejefektivnejsi kod jeden velky switch. Zrovna tak je to nejelegantnejsi kod. Jenom nekterejm teoretikum to bude pripadat jako prasarna protoze ta funkce muze byt vetsi nez jejich nahodne zvolenej limit pro "rozumne velkou funkci"...
(K tomu limitu dospeli nejak takhle http://simpsons.wikia.com/wiki/Homer%27s_Doomsday_equation :-) )
-
Treba v pripade konecnyho automatu je nejefektivnejsi kod jeden velky switch. Zrovna tak je to nejelegantnejsi kod. Jenom nekterejm teoretikum to bude pripadat jako prasarna protoze ta funkce muze byt vetsi nez jejich nahodne zvolenej limit pro "rozumne velkou funkci"...
V případě konečného automatu je právě ten velký switch neefektivní. Polymorfismus je rychlejší.
-
docela prehanis vid?
Ani ne. Samozrejme se to muze lisit pripad od pripadu, ale pri psani generatoru jsou priority obvykle:
1. efektivita generovanyho kodu
2. jednoduchost a citelnost generatoru
...
...
157. citelnost generovanyho kodu
-
Takže odpověz si sám - chceš skončit jako desktop developer nebo big cloud systems developer?
Big cloud systems developer je teď název pro pozici dopatlávání záplat do velkýho firemního softu?
K tématu, .net by měl být (nebo už je?) opensource, takže bych C# nevyhejbal. Nicméně jak tu někdo psal, tim že se naučíš jeden jazyk nezapomeneš ten druhej a zvládnout C# a Javu najednou bych neviděl jako životní překážku.
-
V případě konečného automatu je právě ten velký switch neefektivní. Polymorfismus je rychlejší.
Haha :-)
Ale jestli tomu vazne veris tak muzeme udelat test. Vybereme nejaky automat. Ja ho napisu pomoci switche, ty pomoci virtualnich funkci a zmerime rychlost... ;-)
-
No jasne, proc neudelat 10x komplikovanejsi generator, aby generoval prekrasnej, ale neefektivni kod, kterej stejne nikdo necte...`
Kdo tvrdí, že elegantní kód musí být neefektivní? Právě naopak. Nejrychlejší kódy, které používám, jsou velmi přehledné.
Netvrdi to nikdo.
Treba v pripade konecnyho automatu je nejefektivnejsi kod jeden velky switch. Zrovna tak je to nejelegantnejsi kod. Jenom nekterejm teoretikum to bude pripadat jako prasarna protoze ta funkce muze byt vetsi nez jejich nahodne zvolenej limit pro "rozumne velkou funkci"...
(K tomu limitu dospeli nejak takhle http://simpsons.wikia.com/wiki/Homer%27s_Doomsday_equation :-) )
No to neni tak uplne pravda, tak velka metoda ti s velkou pravdepodobnosti blizici se 100 procentum vypadne z JITovani. A limit neni nahodne zvolenej, je to proste 2^16, coz je docela kulate cislo, kdyz by tam dali 2^32 je to blbost, protoze by to bylo plytvani prostorem - 2^32 je totiz jeste limitovany x dalsima vecma.
Btw bylo by k dispozici aspon naznaceni, ktery KA je tak velky ze prekroci velikost bajtkodu jedne metody? Co jsem videl vysledky ruznych antlr a yaccu, bylo to daleko do limitu.
-
Takže odpověz si sám - chceš skončit jako desktop developer nebo big cloud systems developer?
Big cloud systems developer je teď název pro pozici dopatlávání záplat do velkýho firemního softu?
K tématu, .net by měl být (nebo už je?) opensource, takže bych C# nevyhejbal. Nicméně jak tu někdo psal, tim že se naučíš jeden jazyk nezapomeneš ten druhej a zvládnout C# a Javu najednou bych neviděl jako životní překážku.
Hlavne ten cloud je desne dulezity. Kdo ted nema cloud, jako by nebyl. Uz je to takovy cloud pro cloud. Jsou firmy, ktere si poridi cloud jen proto, aby se jim zvedly akcie za "technologickou progresivitu".
At delam co delam, proste nevidim v ramci velke firmy rozdil mezi on premise architekturou a cloud architekturou. Stejne maji svuj HW, akorat bud jim tam bezi aplikacni servery v clusteru... nebo v clusteru a rikaji tomu cloud...
-
V případě konečného automatu je právě ten velký switch neefektivní. Polymorfismus je rychlejší.
Haha :-)
Ale jestli tomu vazne veris tak muzeme udelat test. Vybereme nejaky automat. Ja ho napisu pomoci switche, ty pomoci virtualnich funkci a zmerime rychlost... ;-)
Jen do toho. Hlavně ať to není moc triviální, to bys byl ve výhodě.
-
- CLR podporuje optimalizaci tail volání (JVM ne a je to velký problém při implementaci funkcionálních jazyků).
Proc je to velky problem?
Protože to nikdo neumí efektivně naimplementovat nad JVM. Navíc, pokud to implementujete v kompilátoru jazyka (třeba pomocí trampolín), tak vlastně vytváříte jinou volací konvenci, která není kompatibilní s ostatními knihovnami, znesnadňuje optimalizace a je spojena s alokacemi na haldě, tudíž zvyšuje aktivitu GC.
Proto to Clojure a Scala nedělají.
a kdyz uz jsme u toho, jsou funkcionalni jazyky bez TCO a programuje se v nich nadherne :)
Absencí TCO (např. ve Scale) jsou poznamenány základní techniky jako continuation passing style, monády, polymorfní rekurze nebo vzájemně rekurzivní funkce.
-
V případě konečného automatu je právě ten velký switch neefektivní. Polymorfismus je rychlejší.
Režie na zavolání metody bude vyšší než režie skoku, tudíž tableswitch bude rychlejší než polymorfismus.
-
Používám aktivně obě technologie a hlavní rozdíl, který tam vidím, je výrazně horší čitelnost v C#.
Například asynchronní kód je výrazně čitelnější v C# než v Javě.
při čtení kódu obrátí proti autorovi. A základní pravidlo říká, že kód, který je jednou napsán, bude tisíckrát přečten.
Myslím, že to naopak přispívá k lepší čitelnosti kódu.
-
V případě konečného automatu je právě ten velký switch neefektivní. Polymorfismus je rychlejší.
Režie na zavolání metody bude vyšší než režie skoku, tudíž tableswitch bude rychlejší než polymorfismus.
V pripade, ze autor toho generatoru vi co dela a implementuje ten generator tak, ze se skutecne pouzije tableswitch a ne lookupswitch. Na druhou stranu plati to, co jsem uz psal - ubermetoda delsi nez nejakych 8 kB bajtkodu se vetsinou neJITuje.
-
Btw bylo by k dispozici aspon naznaceni, ktery KA je tak velky ze prekroci velikost bajtkodu jedne metody? Co jsem videl vysledky ruznych antlr a yaccu, bylo to daleko do limitu.
Pokud stačí umělý příklad, pak můžeme vzít něco na způsob
.*a.*A
.*b.*B
.*c.*C
atd.
Když to uděláte pro všechna písmena abecedy (tj. 26 regulárních výrazů), tak minimální počet stavů bude 2^26.
Jinak lidé s tím limitem mají problémy: JavaCC (http://stackoverflow.com/questions/17422480/maximum-size-of-a-method-in-java-7-and-8), Tomcat (http://stackoverflow.com/questions/5484253/jspservice-is-exceeding-the-65535-bytes-limit), Scala (http://stackoverflow.com/questions/17004747/scala-macros-and-the-jvms-method-size-limit).
-
Absencí TCO (např. ve Scale) jsou poznamenány základní techniky jako continuation passing style, monády, polymorfní rekurze nebo vzájemně rekurzivní funkce.
Ja myslel hlavne Clojure, ale vlastne i Scala je tim poznamenana to je pravda. Ale plati to co jsem psat - i s timto "omezenim" se mi FP kod pise nadherne, vlastne jsem skoro nikdy nemel potrebu delat vyrazne slozitejsi zpracovani nez co nabizi zipmap a for :-) [samozrejme plus map, filter atd. kde je "TCO" schovany do recur). Jako to myslim zcela vazne, u spousty algoritmu proste klasicka rekurze, tail cally apod. vlastne nejsou nutne.
-
Pokud stačí umělý příklad, pak můžeme vzít něco na způsob
.*a.*A
.*b.*B
.*c.*C
atd.
Když to uděláte pro všechna písmena abecedy (tj. 26 regulárních výrazů), tak minimální počet stavů bude 2^26.
Zeptal bych se pelíškovsky: A komu tím prospějete, co?
Bylo by lepší takový vstup číst regulární gramatikou. Tím se podstatně zredukuje stavový prostor.
-
Řekl bych, že ten rozdíl, který pozorujete, je daný tím, že C# pozic je méně, tím pádem je i C# programátorů méně - a tudíž je musí firmy víc shánět, zatímco na Javu se jim okamžitě přihlásí spousta lidí. Jenže v té Javě je nakonec spousta možností, takže po nějakém javovském specialistovi bude stejná sháňka, jako po programátorovi v C#. Akorát to možná firmy nebudou inzerovat stejným způsobem, jako u toho C#, protože by se jim přihlásila spousta studentů, kteří měli Javu 1 semestr.
Jinak pojídač koláčů samozřejmě může programovat v libovolném jazyce a nebude v tom rozdíl (vždycky to bude, jako by to programoval v Cobolu :-) ). Dobrý programátor ale bude vědět, třeba jak funguje jeho C kompilátor a procesory jeho architektury, nebo jak funguje JVM, nebo jak funguje Dalvik a čím se liší různá Android prostředí, nebo jak funguje Swing, nebo jak funguje nějaký aplikační server, atd. atd. Pokud se dostane mimo to své prostředí (kterým není jen jazyk, ten to dělí jen na velmi hrubé úrovni), samozřejmě mu ty jeho znalosti budou k ničemu. Takže sice nebude psát úplně blbý kód, ale nebude to stejně špičkový kód, jako když je v té své oblasti. Na druhou stranu, i ten záběr špičkového programátora bývá široký a různorodý, takže se snadno může stát, že dostane úplně jiný úkol, a odvede stejně špičkový výkon - protože se nedostal mimo oblast toho, co perfektně umí, jenom se v ní přesunul na jiné místo.
Nebo se na to můžete podívat jinak. Tím, že je C# pozic méně, je vlastně určitou specializací už ten jazyk - a trochu se očekává, že programátor v C# bude umět "všechno", takže nejspíš nebudete mít možnost jít tak do hloubky. Na druhou stranu, když o sobě píšete jako o "Java programátorovi", ani v té Javě nejspíš nejste nijak specializován a přechod k C# pro vás žádná ztráta nebude. Naopak určitě bude v životopisu dobře vypadat, že máte reálné zkušenosti s oběma světy, protože spousta firem si řekne "teď nabíráme na pozici Java programátora, ale až tenhle projekt skončí a vyhrajeme tamten C# projekt, budeme ho tam moci přesunout".
-
Dobrý programátor ale bude vědět, třeba jak funguje jeho C kompilátor a procesory jeho architektury, nebo jak funguje JVM, nebo jak funguje Dalvik a čím se liší různá Android prostředí, ...
Prelozeno do cestiny, "dobry programator udela kod neprenositelny" ?
-
Dobrý programátor ale bude vědět, třeba jak funguje jeho C kompilátor a procesory jeho architektury, nebo jak funguje JVM, nebo jak funguje Dalvik a čím se liší různá Android prostředí, ...
Prelozeno do cestiny, "dobry programator udela kod neprenositelny" ?
OMG, jsem to tu psal včera. Pokud všechno víš, tvůj kód poběží lépe. Nějaká přenositelnost je úplně mimo řešení. Samozřejmě je levnější lopata, která umí jen jazyk a tunu frameworků.
-
Nějaká přenositelnost je úplně mimo řešení.
A takovej clovek tady bude placat neco o lopatach... ;-)
-
To bylo myšleno tak, že jsi hloupý a nechápeš kontext. Filip nic o přenositelnosti neříkal. Samozřejmě by tam šla přidat, ale to jsi udělal jen ty a nikomu tím neprospěješ.
-
To bylo myšleno tak, že jsi hloupý a nechápeš kontext. Filip nic o přenositelnosti neříkal. Samozřejmě by tam šla přidat, ale to jsi udělal jen ty a nikomu tím neprospěješ.
Jo, filip tam mel hromadu blabolu kolem, ale tohle byla pointa. Je videt ze jsi hloupy ze to nechapes ;-)
-
To bylo myšleno tak, že jsi hloupý a nechápeš kontext. Filip nic o přenositelnosti neříkal. Samozřejmě by tam šla přidat, ale to jsi udělal jen ty a nikomu tím neprospěješ.
Jo, filip tam mel hromadu blabolu kolem, ale tohle byla pointa. Je videt ze jsi hloupy ze to nechapes ;-)
+1
-
Jakože když napíše víc blbců, tak se Filipův příspěvek změní? :D
-
Jakože když napíše víc blbců, tak se Filipův příspěvek změní? :D
Neboj, tady to vsichni vime ze jsi velky hlupak. Nemusis nam to opakovat :-D
-
Jakože když napíše víc blbců, tak se Filipův příspěvek změní? :D
hele, neukazují si na tebe lidi na ulici a nesmějí se? :-))
-
Lidi ne, ale blbci ano. Je výhoda, že jich je všude plno a šlo by s nimi topit. Takže zatím se dělá, že je fajn, že jich je tolik, ale až dojde ropa, tak budou hlavním zdrojem energie.
Pořád se Filipův příspěvek nezměnil. Fakt divný, co?
-
u nas v BA je najviac ponuk na .NET. (Na prvom mieste je LAMP ale ten nestoji za rec nakolko tam su platy zhruba polovicne oproti .NETu a robi to barzjaky student pod cenu). U nas vo firme je hlavna platforma .NET ale pri mobile appkach sa uplatnia aj javisti a objective c-ckari.
-
Lidi ne, ale blbci ano. Je výhoda, že jich je všude plno a šlo by s nimi topit. Takže zatím se dělá, že je fajn, že jich je tolik, ale až dojde ropa, tak budou hlavním zdrojem energie.
Pořád se Filipův příspěvek nezměnil. Fakt divný, co?
A cetls ten prispevek vubec, hlupaku?
-
Znova jsem se na něj díval a pořád jste ho vaším hloupým psaním nepřepsali. Nevím, asi to tak nefunguje? Možná musíme ještě počkat 8)
-
Znova jsem se na něj díval a pořád jste ho vaším hloupým psaním nepřepsali. Nevím, asi to tak nefunguje? Možná musíme ještě počkat 8)
Tak to zkus jeste jednou, jestli si tam vsimnes perel jako treba "... bude vědět, třeba jak funguje ***jeho*** C kompilátor ..."
Prijde ti jako dobry napad psat kod pro jeden konkretni C kompilator?
Jestli to tam nenajdes, nebo jestli to porad nechapes, tak uz se tim netrap. Kdyz priroda nenadelila tak my uz s tim asi moc neudelame...
-
Jo, filip tam mel hromadu blabolu kolem, ale tohle byla pointa. Je videt ze jsi hloupy ze to nechapes ;-)
Ne, nebyla to pointa. To, že to nechápete, nemusí být jenom tím, že jste hloupý, třeba jsem to já špatně napsal. A nebo prostě jenom máte málo zkušeností.
Za prvé, vypsal jsem různé příklady, aby bylo jasné, že těch znalostí je spousta. Některé, ale ne všechny, které jsem uvedl, vedou na nepřenositelný kód. Znalost toho, jak psát přenositelný kód, je další z těch znalostí a ve skutečnosti je jich zase několik. Znalost, jak psát přenositelný kód v C, mi bude k ničemu, když přejdu na Javu, znalost, jak psát přenositelné aplikace ve Swingu, které budou vypadat a chovat se správně na nejrůznějších platformách, mi bude k ničemu, když přejdu na C#.
Za druhé, přenositelnost není posvátná kráva. U vozítka na Marsu asi těžko budete odůvodňovat, že byste to sice mohl zoptimalizovat, ale pak by to nebylo přenositelné, takže potřebujete výkonnější procesor, tím pádem kapacitnější baterie, větší sluneční panely a spoustu prachů navíc na to, abyste tuhle nadváhu dostal na Mars. Je spousta jiných systémů, třeba mnoho business nebo enterprise aplikací, které jsou provozovány v jediné instanci, a nemá smysl tam řešit přenositelnost. A i u těch přenositelných systémů se řeší optimalizace pro konkrétní architektury nebo i kompilátory. Podívejte se třeba na linuxové jádro, kolik je tam optimalizací pro různé architektury - a nezdá se, že by kvůli tomu bylo nepřenositelné.
-
k comu je dobre presne vediet, ako funguje kompilator?
-
k comu je dobre presne vediet, ako funguje kompilator?
Když víte, jaké dělá optimalizace, nemusíte se snažit ty samé optimalizace dělat ručně (obvykle ty z kompilátoru budou lepší a budete mít přehlednější kód). Nebo naopak víte, že nějakou optimalizaci ten kompilátor udělat neumí, a že ji tedy musíte napsat ručně. Nebo kód napíšete tak, aby kompilátor rozpoznal o co jde a mohl tu optimalizaci provést (a kdybyste kód napsal jinak, i kdyby dělal to samé, kompilátor by to nerozpoznal). A to se týká jen optimalizací. Dále ten kompilátor může podporovat nějaké rozšíření, které vám usnadní práci nebo zpřehlední kód. Další věc je, že i kompilátory mají chyby, kterým je občas potřeba se vyhnout.
-
ja robim v C# a nejak som sa zatial nikdy nedopatral k tomu, ake optimalizacie vykonava kompilator.
-
Jo, filip tam mel hromadu blabolu kolem, ale tohle byla pointa. Je videt ze jsi hloupy ze to nechapes ;-)
Ne, nebyla to pointa. To, že to nechápete, nemusí být jenom tím, že jste hloupý, třeba jsem to já špatně napsal. A nebo prostě jenom máte málo zkušeností.
Ještě ty blbce obhajuj ;D
-
ja robim v C# a nejak som sa zatial nikdy nedopatral k tomu, ake optimalizacie vykonava kompilator.
Jednou ze zajímavých optimalizací je například expandování privátních metod místo jejich volání. Gettery/settery jsou převáděny na přímé čtení/zápisy do objektu. Kompilátoru tedy jedno, zda programátor píše jednu dlouhou nepřehlednou nudli nebo programuje elegantně a čitelně.
-
K původnímu tématu: uživíte se velmi slušně s Javou i .NETem. U Javy budete psát nejspíš serverové aplikace ("míchání dat"), případně mobilní aplikace pro Android. Svět .NETu je to trochu bohatší, a zahrnuje všechno od desktopu, přes web a mobilní aplikace až po server. Přechod z Javy na C# bývá poměrně jednoduchý, C# je prakticky nadmnožinou Javy. Naopak je to složitější, protože si připadáte jako když vám někdo uříznul jednu ruku.
Na vašem místě bych problém, o kterém rozhodujete, popsal numericky. Vyberte důležitá kritéria, bodově je ohodnoťte pro variantu A a B, přiřaďte jim důležitost, a spočítejte si co vychází lépe.
-
servery su ekvivalentne na oboch stranach
na webe v jave mate stale moznost robit jsf / wicket / ine ui frameworky ako v .nete
mobilne aplikacie maju android omnoho rozsirenejsi nez windows phone
jedine kde sa to lisi je desktop; tam .net vyhrava a v jave sux
-
Svět .NETu je to trochu bohatší, a zahrnuje všechno od desktopu, přes web a mobilní aplikace až po server.
Viděl bych to přesně opačně. Třeba ty mobilní aplikace – kolik lidí má mobil s Windows a jaká je tedy poptávka po mobilních Windows aplikacích? Jinak Javovské aplikace začínají ještě dřív, než desktop, můžete je klidné psát třeba pro Raspberri PI. To si s Cx budete muset počkat na dvojku, až na to Microsoft naportuje Windows.
Přechod z Javy na C# bývá poměrně jednoduchý, C# je prakticky nadmnožinou Javy. Naopak je to složitější, protože si připadáte jako když vám někdo uříznul jednu ruku.
A tady bych to viděl také opačně. Vaše tvrzení platí možná pro jazyk, ale když vezmete v úvahu celý ekosystém okolo, bude vám chybět víc než jen jedna ruka.
-
Ještě ty blbce obhajuj ;D
ty mas nejakej komplex nebo co?
-
Viděl bych to přesně opačně. Třeba ty mobilní aplikace – kolik lidí má mobil s Windows a jaká je tedy poptávka po mobilních Windows aplikacích? Jinak Javovské aplikace začínají ještě dřív, než desktop, můžete je klidné psát třeba pro Raspberri PI. To si s Cx budete muset počkat na dvojku, až na to Microsoft naportuje Windows.
Pokud nechcete mobilní aplikaci psát pro každou platformu zvlášť, je jednou z mála možností Xamarin, založený na .NETu.
V .NETu samozřejmě také můžete psát pro embedded zařízení, máte k dispozici .NET Compact Framework a .NET Micro Framework. Pokud jde o Raspberry Pi I, tak tam můžete použít Mono.
A tady bych to viděl také opačně. Vaše tvrzení platí možná pro jazyk, ale když vezmete v úvahu celý ekosystém okolo, bude vám chybět víc než jen jedna ruka.
JDK je má dost úzké API, protože "one size fits all". Zkuste z Javy zjistit jaké na stroji běží služby (services/deamons), jaké jsou naplánované úlohy (Windows Task Scheduler/cron), něco vytisknout, získat obrázek ze scanneru atd. Navíc jsou dost hrozivě nedodělané i základy, jako operace s časem/datem, named parameters při práci s DB atd. Něco se snaží zalepit Apache Commons, ale je to bída. V .NETu máte k dispozici mnohem širší služby platformy. K tomu pak nabídku komponent třetích stran, většinou (na rozdíl od knihoven pro Javu) slušně dokumentovaných.
BTW první co mě na Javě zarazilo je absence verbatim string literals. Chápu že je to snaha dohnat autory k používání resources (které jsou mimochodem implementované dost hrozivě). Ale regex asi nebudu dávat do resources, a escapovat regex je opravdu na hlavu. Autory Javy bych nechal za trest... psát kód v Javě :)
-
Demagog Lael nám tu chyběl :-)
Pokud nechcete mobilní aplikaci psát pro každou platformu zvlášť, je jednou z mála možností Xamarin, založený na .NETu.
V .NETu samozřejmě také můžete psát pro embedded zařízení, máte k dispozici .NET Compact Framework a .NET Micro Framework. Pokud jde o Raspberry Pi I, tak tam můžete použít Mono.
Vow, takže nesmysl typu Java ME, kterého se Java zbavila už před 5-10ti lety, teď Microsoft u dotNet prosazuje jako horkou moderní novinku? :-)
JDK je má dost úzké API, protože "one size fits all". Zkuste z Javy zjistit jaké na stroji běží služby (services/deamons), jaké jsou naplánované úlohy (Windows Task Scheduler/cron), něco vytisknout, získat obrázek ze scanneru atd. Navíc jsou dost hrozivě nedodělané i základy, jako operace s časem/datem, named parameters při práci s DB atd. Něco se snaží zalepit Apache Commons, ale je to bída. V .NETu máte k dispozici mnohem širší služby platformy. K tomu pak nabídku komponent třetích stran, většinou (na rozdíl od knihoven pro Javu) slušně dokumentovaných.
Většina věcí je podporovaná platformově nezávisle. Na věci, které jsou platformově závislé, existují, celkem logicky, platformově závislé knihovny.
Operace s časem/datem jsou v pořádku a pokud vím, tak i flexibilnější z hlediska kultur. Kde je přesně problém s named parameters u DB, nikdy jsem na žádný nenarazil...? Apache Commons jsou samozřejmě skvělé a Apache Commons mají i dotNet verze, bohužel často ne na takové úrovni jako Java ekvivalenty. Přesto je to obvykle lepší varianta než to, co nám naservíroval Microsoft. Stejně tak NHibernate pro ORM a Spring.net pro MVC a IoC. Obojí je sice jen kopie původního Java framework, ale opět lepší než Microsoft frameworks, které mají často jepičí život. Viz například Silverlight, který měl být vlajkovou lodí a dnes po něm neštěkne ani pes - a společnosti, které na tom postavily svůj business, si teď rvou vlasy...
-
Obojí je sice jen kopie původního Java framework, ale opět lepší než Microsoft frameworks, které mají často jepičí život. Viz například Silverlight, který měl být vlajkovou lodí a dnes po něm neštěkne ani pes - a společnosti, které na tom postavily svůj business, si teď rvou vlasy...
Tak tak, znam par firem z businessu, kteri se presne takto spalili, dokonce uz dvakrat po sobe. Ted jsou mnohem opatrnejsi a projekty, u nichz "hrozi", ze budou muset byt podporovany treba vic nez 5 let, to stavi jen na otevrenych technologiich. A navic dneska je v RFE uz skoro automaticky pozadavek na klienta pro smartphony, takze tam jsou volby celkem logicky.
-
zas si tu budu linuxaci pouzivajuci javu zrovnavat peeera s microsoftakmi pouzivajucimi C#. Kamarat pracoval v Jave aj C#. Povedal, ze C# je ovela lepsi nez Java. Ja Javu nepoznam, a neviem, ci sa do nej vobec pustim. Zliepat a instalovat X java frameworkov, to radsej C#, kde je vsetko pokope :) A nehovoriac o IDE, ktore ma MS prepracovane a ziadne ine sa nechyta nan. Proste Visual Studio je mocny nastroj.
-
projekty, u nichz "hrozi", ze budou muset byt podporovany treba vic nez 5 let, to stavi jen na otevrenych technologiich
Otázkou je, zda to stačí. Stejně tu je riziko, že nebudou mít kapacitu udržovat tu otevřenou technologii, když ji opustí původní autoři.
-
Pokud nechcete mobilní aplikaci psát pro každou platformu zvlášť
Chci, protože ty platformy jsou rozdílné, a napsat to jednou znamená, že to bude špatně na všech platformách.
JDK je má dost úzké API, protože "one size fits all". Zkuste z Javy zjistit jaké na stroji běží služby (services/deamons), jaké jsou naplánované úlohy (Windows Task Scheduler/cron), něco vytisknout, získat obrázek ze scanneru atd.
To není otázka jazyka, ale toho prostředí okolo. Je hezké, že jste vyjmenoval úplně vše, kde má prostředí C# navrch. Ale moc toho není, že?
Navíc jsou dost hrozivě nedodělané i základy, jako operace s časem/datem, named parameters při práci s DB atd.
Co vám vadí na JodaTime, které je i součástí JRE 8? Co vám vadí na JDBC, Spring Data, Hibernate a spoustě dalších knihoven a frameworků, které pro práci s DB existují?
Něco se snaží zalepit Apache Commons, ale je to bída.
Bída je především Apache Commons. Ty byly mezi slepými jednookým králem někdy před deseti lety, dnes máme spoustu nesrovnatelně lepších knihoven. A to, že jsou ty věci v knihovnách, je snad správně – proč by to mělo všechno být v základní platformě?
V .NETu máte k dispozici mnohem širší služby platformy.
To je podle mne nedostatek.
K tomu pak nabídku komponent třetích stran, většinou (na rozdíl od knihoven pro Javu) slušně dokumentovaných.
No ale ta nabídka není moc slavná, že? S tou dokumentací je to také jen nějaký váš výmysl.
BTW první co mě na Javě zarazilo je absence verbatim string literals.
Takovýchhle příkladů najdete u každého jazyka spoustu, a o každé jednotlivě se můžete do krve hádat, jestli je to správně nebo není. U každé najdete zastánce toho, že jazyk má mít jednoduchou syntaxi bez spousty výjimek, jinak potom vypadá, jako když pejsek a kočička vařili dort. A proti nim budou stát zastánci toho, že zrovna tenhle syntaktický cukr je velice užitečná věc a ušetří to triliony dolarů. Abych do tohoto flamewaru také přispěl – zamyslet se nad tím, jestli ona primitivní syntaxe Javy není jedním z důvodů jejího velkého rozšíření. Protože kompletní syntaxi obsáhne programátor za chvilku a v kódu ho pak nepřekvapují různé obskurní shluky symbolů.
A nehovoriac o IDE, ktore ma MS prepracovane a ziadne ine sa nechyta nan. Proste Visual Studio je mocny nastroj.
A proto existuje ReSharper, aby se to slavné Visual Studio alespoň přiblížilo javovským IDE.
-
zas si tu budu linuxaci pouzivajuci javu zrovnavat peeera s microsoftakmi pouzivajucimi C#. Kamarat pracoval v Jave aj C#. Povedal, ze C# je ovela lepsi nez Java. Ja Javu nepoznam, a neviem, ci sa do nej vobec pustim. Zliepat a instalovat X java frameworkov, to radsej C#, kde je vsetko pokope :) A nehovoriac o IDE, ktore ma MS prepracovane a ziadne ine sa nechyta nan. Proste Visual Studio je mocny nastroj.
Čemu se divíš? Na Microsoftím portálu se nechytíš s Javou. Zapomínáš, že jsme na Rootovi a že uzavřená řešení tady jsou v nelibosti. Argument typu JPP není žádným argumentem. A když vidím, že to MS IDE pojmenovává každý program názvem Program, tlačítka pojmenovává Button01..Button0n a vůbec nevede programátory k tomu, aby si to přejmenovali podle sebe, tak takový nástroj spíš považuji za nemocný. Nemluvě o debilním pojmenovávání inteface v maďarské notaci, které svádí k psaní chybného kódu.
-
Jirasku:
vy snad trepete 2 na 3. aby sa Visual Studio priblizilo s Resharperom k IDE pre javu? preboha tak vy tu chcete asi len rozputat burlivu diskusiu. VS ma navrch aj bez resharpera. asi 3 roky dozadu som pouzival NetBeans na C++, ktore je primarne na javu. Tak ubohy nastroj som nevidel. V tom case existovalo uz VS2010 a to bola parna mlaticka, ako hovoril nas ucitel. No a eclipse, to je pohroma sama o sebe. VS nema konkurenta pane Jirasku ;)
-
A když vidím, že to MS IDE pojmenovává každý program názvem Program, tlačítka pojmenovává Button01..Button0n a vůbec nevede programátory k tomu, aby si to přejmenovali podle sebe, tak takový nástroj spíš považuji za nemocný. Nemluvě o debilním pojmenovávání inteface v maďarské notaci, které svádí k psaní chybného kódu.
je predsa na inteligencii programatora, ako si co nazve. preco by mi malo prostredie diktovat, aby som si premenoval nieco podla seba? na tom je potom vidiet, kto tomu rozumie a vie, co aj robi ;)
-
asi 3 roky dozadu som pouzival NetBeans na C++, ktore je primarne na javu.
netbeans sa za 3 roky *dost* vyznamne posunulo
keby ste menovali featury aj by som vam povedal co sa zlepsilo
inak ked chcete vidiet este lepsie ide, tak intellij idea
-
to je ako bavit sa o tom, ci je lepsi Android alebo WP. Rychlost, stabilita a kvalita systemu hovori ZA WP. Toto Androidu chyba, no ale to si ludia nikdy nepripustia. Podobne je to C# a Java
-
to je ako bavit sa o tom, ci je lepsi %s alebo %s. Rychlost, stabilita a kvalita systemu hovori ZA %s. Toto %s chyba, no ale to si ludia nikdy nepripustia.
-
je predsa na inteligencii programatora, ako si co nazve. preco by mi malo prostredie diktovat, aby som si premenoval nieco podla seba? na tom je potom vidiet, kto tomu rozumie a vie, co aj robi ;)
Prostředí by mělo vyžadovat, aby programátor pojmenoval program, třídu nebo objekt. Pokud mu místo toho nabídne nějaký provizorní název a programátor to tak nechá, časem se mu to vymstí. Méně je často lépe.
Maďarské názvy interface jsou vidět i v systémových knihovnách C#. Tyto názvy měnit nemůže.
-
Prostředí by mělo vyžadovat, aby programátor pojmenoval program, třídu nebo objekt. Pokud mu místo toho nabídne nějaký provizorní název a programátor to tak nechá, časem se mu to vymstí. Méně je často lépe.
Ne. Programator by mel byt inteligentni svepravny clovek, ktery vi co dela. Kdyz se bude prostredi chovat k programatorum jako by byli blbci, tak je budou pouzivat jenom blbci. Coz je mimochodem pripad Javy ;-)
-
No vy ste asi nepouzivali VS nikdy v zivote. Pri vkladani novej triedy sa vzdy zobrazi okno, kde mozte vlozit nazov triedy. Podobne aj pri Interface. Neviem o com kecate a hejtujete, ked nemate najmensie ponatie o tom ;)
-
Ne. Programator by mel byt inteligentni svepravny clovek, ktery vi co dela. Kdyz se bude prostredi chovat k programatorum jako by byli blbci, tak je budou pouzivat jenom blbci. Coz je mimochodem pripad Javy ;-)
Javovské programy píši ve Vimu. Nemám totiž rád, když se mnou IDE jedná jako s blbcem.
-
No vy ste asi nepouzivali VS nikdy v zivote. Pri vkladani novej triedy sa vzdy zobrazi okno, kde mozte vlozit nazov triedy. Podobne aj pri Interface. Neviem o com kecate a hejtujete, ked nemate najmensie ponatie o tom ;)
Proč tedy název každého interface je v maďarské notaci? Včetně systémových knihoven?
-
A když vidím, že to MS IDE pojmenovává každý program názvem Program, tlačítka pojmenovává Button01..Button0n a vůbec nevede programátory k tomu, aby si to přejmenovali podle sebe, tak takový nástroj spíš považuji za nemocný. Nemluvě o debilním pojmenovávání inteface v maďarské notaci, které svádí k psaní chybného kódu.
Defaultní hodnoty a názvy jsou naprosto v pořádku. Opačné chování chtít povinně zadávat explicitní název je jako u blbečků na dvorečku.
Ičko v interface je proti dřívějšímu hwnd a lpsz pouze drobná kosmetická vada, i když samozřejmě je to maďarismus.
Prostředí by mělo vyžadovat, aby programátor pojmenoval program, třídu nebo objekt. Pokud mu místo toho nabídne nějaký provizorní název a programátor to tak nechá, časem se mu to vymstí.
Ani omylem ne. To co programátor vyprodukuje je jeho odpovědnost, nikoliv odpovědnost IDE.
-
No vy ste asi nepouzivali VS nikdy v zivote. Pri vkladani novej triedy sa vzdy zobrazi okno, kde mozte vlozit nazov triedy. Podobne aj pri Interface. Neviem o com kecate a hejtujete, ked nemate najmensie ponatie o tom ;)
Proč bych měl VS používat? Ani by mi to nešlo nainstalovat. Stačí mi, když vidím ty šmejdy, co v tom píší jiní. Často to ani nejde zkompilovat v Mono.
-
Čemu se divíš? Na Microsoftím portálu se nechytíš s Javou. Zapomínáš, že jsme na Rootovi a že uzavřená řešení tady jsou v nelibosti. Argument typu JPP není žádným argumentem. A když vidím, že to MS IDE pojmenovává každý program názvem Program, tlačítka pojmenovává Button01..Button0n a vůbec nevede programátory k tomu, aby si to přejmenovali podle sebe, tak takový nástroj spíš považuji za nemocný. Nemluvě o debilním pojmenovávání inteface v maďarské notaci, které svádí k psaní chybného kódu.
https://github.com/Microsoft/dotnet
-
Javovské programy píši ve Vimu. Nemám totiž rád, když se mnou IDE jedná jako s blbcem.
no VIM. to je nastroj ako svina. nikdy viac.
Proč tedy název každého interface je v maďarské notaci? Včetně systémových knihoven?
A zato moze akoze IDE VS? :D Ako si kto pomenuje, tak ma ;) A ide o nejaky zauzivany zapis. Ja na tom nevidim nic zleho. Ked si tam pred to strcite X, tak budete mat X. Lebo asi vela programatorov sa bude divit, co za vola to robilo
-
Proč bych měl VS používat? Ani by mi to nešlo nainstalovat. Stačí mi, když vidím ty šmejdy, co v tom píší jiní. Často to ani nejde zkompilovat v Mono.
no asi sa nestretavate s tymi spravnymi ludmi. mozno mate okolo seba len sebe podobnych - smejdov :)
-
Proč tedy název každého interface je v maďarské notaci? Včetně systémových knihoven?
A zato moze akoze IDE VS? :D Ako si kto pomenuje, tak ma ;) A ide o nejaky zauzivany zapis. Ja na tom nevidim nic zleho. Ked si tam pred to strcite X, tak budete mat X. Lebo asi vela programatorov sa bude divit, co za vola to robilo
Proč bych měl před název interface strkat nějaké "X" nebo "I". Je to zápis, který nedává smysl a často se i blbě vyslovuje.
-
No ked si tam napisete: "SomNeskusenyCsharpProgramatorAHejtujemHo" tak vam IDE nevynada zato. Jo mensia rada - ostante teda v JAVE a vo VIM. Pokrocilejsie nastroje nechajte na skusenejsich :)
-
Proč bych měl VS používat? Ani by mi to nešlo nainstalovat. Stačí mi, když vidím ty šmejdy, co v tom píší jiní. Často to ani nejde zkompilovat v Mono.
LOL cim by to tak mohlo byt? Mozna tim ze MONO je jen jakysi pokus o opensource implementaci .NETu jeho vyvojari by spravne nemeli reverzovat vnitrnosti .NETu a tak tam strilej picoviny, jak je napadne.
kdyz jsem zjistil, jak tam implementovali treba MaxDegreeOfParallelism u Parallel.ForEach tak jsem to hovno rovnou smazal jako kompletne nepouzitelne a neduveryhodne. Neveril bych tomu ani 1+1
-
Proč bych měl před název interface strkat nějaké "X" nebo "I". Je to zápis, který nedává smysl a často se i blbě vyslovuje.
Původně to bylo myšleno pro přehlednost, například třída se jmenovala CFoo, instance Foo, interface se jmenovalo IFoo. IMHO to nebyl úplně špatný nápad, je to přehlednější než třída Foo a instance foo.
-
No ked si tam napisete: "SomNeskusenyCsharpProgramatorAHejtujemHo" tak vam IDE nevynada zato. Jo mensia rada - ostante teda v JAVE a vo VIM. Pokrocilejsie nastroje nechajte na skusenejsich :)
Ještě mi poraď, jak se VS instaluje do Ubuntu. Nebo raději ne, nestojím o to.
-
Původně to bylo myšleno pro přehlednost, například třída se jmenovala CFoo, instance Foo, interface se jmenovalo IFoo. IMHO to nebyl úplně špatný nápad, je to přehlednější než třída Foo a instance foo.
Názvy CFoo, IFoo, Foo a foo si co do šílenosti nemají co vyčítat. Nepoužívám je.
I bez prefixů lze velmi snadné rozpoznat Třídu, instanci, metodu() i interface. Prefixy jsou zbytečné.
-
Když porovnám VS2010 (2013 jsem zatím neviděl) s tím, co umí Eclipse nebo Intellij Idea jednoduše na right-click nebo jednoduchou zkratkou přes Alt-Enter, tak je to nesrovnatelné drbání se pravým palcem u nohy na levém oku. Jediný problém s Intellij Idea je to, že plná verze je komerční, nicméně i ta free je na tom líp, než VS Ultimate edition :-)
Ohledně maďarštiny - to je další peklo. Kromě toho, že to další písmeno a) nic neříká, b) je matoucí, c) je netransparentní, tak hlavně d) stejně jako jakákoli dřívější maďarština vede k naprostému pazvyku brát to písmeno jako název třídy - ve výsledku u nás v C# projektech vidím ICustomerDao a k němu CustomerDao jako implementaci. Až jednou přejdem z SQL třeba na Mongo, tak nevím, zda přepíšou stávající implementaci nebo udělají CustomerDao2...? Argument jak si to uděláš, tak to máš, neberu, neboť IList/List je typický příklad, kdy už je to zprasené v dotNet core framework. V Javě zcela jasně vidím rozdíl v interface (List) a různých typech implementací (ArrayList a LinkedList) už z názvu třídy.
-
projekty, u nichz "hrozi", ze budou muset byt podporovany treba vic nez 5 let, to stavi jen na otevrenych technologiich
Otázkou je, zda to stačí. Stejně tu je riziko, že nebudou mít kapacitu udržovat tu otevřenou technologii, když ji opustí původní autoři.
Budu mit minimalne jednu jistotu - zdrojaky, s kterymi mam mnohem vetsi sanci to rozchodit nez s uzavrenou technologii, kterou uz vyrobce nepodporuje. Priklad mam mozna absurdni ale o to zavaznejsi: jedna aplikace naprgana zcasti s pouzitim ActiveX. Pro mladsi - to mela byt jedna z technologii (z dilny MS), ktera mela spasit cely IT svet, dneska samozrejme deprecated. Dalsi aplikace pouzivajici vbrun6xx.dll - taky smula dneska (a to je aplikace s velkou uzivatelskou zakladnou). Dneska to puvodni autori prepisuji na otevrenejsi reseni, protoze je to stalo krvave prachy.
-
Obcas mam pocit, ze ti, co tu pise take nepravdive kktiny ohladom VS a C#, tak to videli tak akurat z rychlika, na nejakom,skolskom projekte. Je to smutne. Ostante radsej v jave. Java, ktora nepodporuje linq, nepodporuje extension metody, generika su na tom lepsie. Co dodat :P
-
I bez prefixů lze velmi snadné rozpoznat Třídu, instanci, metodu() i interface.
Výše uvedené tvrzení není platné pro dvojici "instanci" "interface".
zcela jasně vidím rozdíl v interface List a různých typech implementací ArrayList
Ten je kde přesně ? Když to má jedno velké písmeno tak je to jasně interface a když to má dvě velké písmena tak je to jasně implementace ? Nebo si pamatuješ názvy 2500 interface v hlavě ?
Aby bylo jasno neobhajuji maďařštinu, jen že situace není tak jednoduchá.
-
I bez prefixů lze velmi snadné rozpoznat Třídu, instanci, metodu() i interface.
Výše uvedené tvrzení není platné pro dvojici "instanci" "interface".
zcela jasně vidím rozdíl v interface List a různých typech implementací ArrayList
Ten je kde přesně ? Když to má jedno velké písmeno tak je to jasně interface a když to má dvě velké písmena tak je to jasně implementace ? Nebo si pamatuješ názvy 2500 interface v hlavě ?
Aby bylo jasno neobhajuji maďařštinu, jen že situace není tak jednoduchá.
Ten rozdiel je ten, ze ked mam interface "List", tak cokolvek by som pred to pridal ("Array" v tomto pripade) je uz konkretna implementacia.
Ked mam napriklad interface "CarBuilder", tak implementacia by bola "XCarBuilder", teda napr. "DefaultCarBuilder" alebo "CustomCarBuilder".
Existuje aj druhy sposob, ak viem ze CarBuilder je interface, tak CarBuilderImpl je jeho implementacia. Tu je ale "problem", ze mozem takto pomenovat len jednu implementaciu.
V praxi sa rozhodujem podla toho, co potrebujem / co viac vyhovuje. To nie je o tom, ze to je nekonzistentne, vzdy sa to da pomenovat tak, aby to bolo uplne zrejme co je co.
-
Obcas mam pocit, ze ti, co tu pise take nepravdive kktiny ohladom VS a C#, tak to videli tak akurat z rychlika, na nejakom,skolskom projekte.
vy ste tiez videli javu z rychlika pan general tak uberte pary
---------------
tie konvencie v jave (a mnohych dalsich jazykoch) madarsku notaciu opustili. prakticky v kode je jedno ci zoznam "List<Troll>" je interfejs alebo abstraktna trieda alebo konkretna implementacia.
riesi sa to predponou, ci uz arraylist alebo defaulttrollservice alebo simpletrollservice
ak vam to velmi vadi tak si mozete v ide nastavit malovanie interfejsov a abstraktov inou farbou
takisto konvencie ako privatne premenne s podciarkovnikom alebo predpona mStudents na memberoch sa riesia viac v ide a v legacy projektoch
niekde v low level jazykoch malo vyznam vediet ci nieco je long alebo int uz podla nazvu ale dnes uz je to jedno. alternativne ked v scale uz su interfaces, triedy, abstraktne triedy, companion triedy, traity, to by bolo prefixov..
aj tak potom clovek pride do javascriptu alebo haskellu a tam mu musi prdnut pod deklom
-
nesmysl typu Java ME, kterého se Java zbavila už před 5-10ti lety, teď Microsoft u dotNet prosazuje jako horkou moderní novinku? :-)
Odlehčené verze .NET Frameworku jsou tu pěkných pár let.
Na věci, které jsou platformově závislé, existují, celkem logicky, platformově závislé knihovny.
OK, jak zjistit ty běžící services/daemons, plánované úlohy (Windows Task Scheduler, cron), a dostat data ze skeneru? Nechci si poměřovat velikost, vážně mě to zajímá.
Kde je přesně problém s named parameters u DB, nikdy jsem na žádný nenarazil...?
JDBC named parameters (pořád ještě?) neumí. Dají se použít další knihovny, ale otázka je, jestli autoři Javy neznají named parameters, nebo je považují za zbytečné.
Viz například Silverlight, který měl být vlajkovou lodí a dnes po něm neštěkne ani pes - a společnosti, které na tom postavily svůj business, si teď rvou vlasy...
SilverLight je založený na XAML, a migrace je poměrně jednoduchá.
-
zcela jasně vidím rozdíl v interface List a různých typech implementací ArrayList
Ten je kde přesně ? Když to má jedno velké písmeno tak je to jasně interface a když to má dvě velké písmena tak je to jasně implementace ? Nebo si pamatuješ názvy 2500 interface v hlavě ?
Aby bylo jasno neobhajuji maďařštinu, jen že situace není tak jednoduchá.
Předřečníci už částečně odpověděli, já jen dodám, že tím jsem měl na mysli, že z názvu třídy jasně vidím podstatu implementace. Stejně jako v případě Map, HashMap, TreeMap, LinkedHashMap mám představu o schopnostech a efektivitě dané struktury. V dotNet vidím pouze IDictionary / Dictionary, pokud budu chtít sorted, tak ji najdu/pojmenuju jak?
-
Ten rozdiel je ten, ze ked mam interface "List", tak cokolvek by som pred to pridal ("Array" v tomto pripade) je uz konkretna implementacia.
"Mám interface" znamená co ? Že si pamatuješ 2500 názvu interface v projektu a knihovnách zpaměti ?
Když se dostaneš do projektu kde mají Tunnel a MegaTunnel, tak Tunnel je class nebo interface ?
-
Chci, protože ty platformy jsou rozdílné, a napsat to jednou znamená, že to bude špatně na všech platformách.
Psát tu samou aplikaci třikrát je vzor produktivity :)
A to, že jsou ty věci v knihovnách, je snad správně – proč by to mělo všechno být v základní platformě?
...
To je podle mne nedostatek.
To snad nemůžete myslet vážně. Proč bych měl na základní operace používat externí knihovny?
...Protože kompletní syntaxi obsáhne programátor za chvilku a v kódu ho pak nepřekvapují různé obskurní shluky symbolů.
To máte na mysli třeba to že v regexech musíte escapovat, a v Javě escapovat ještě jednou? Jo, obskurní shluky symbolů, to popisujete celkem dobře :/
-
Ten rozdiel je ten, ze ked mam interface "List", tak cokolvek by som pred to pridal ("Array" v tomto pripade) je uz konkretna implementacia.
"Mám interface" znamená co ? Že si pamatuješ 2500 názvu interface v projektu a knihovnách zpaměti ?
Když se dostaneš do projektu kde mají Tunnel a MegaTunnel, tak Tunnel je class nebo interface ?
Ano, ako to nepisal magor tak MegaTunnel je implementacia a Tunnel je interface. Tunnel nemoze byt abstraktna trieda pretoze to by sa volalo AbstractTunnel (rovnako plati ja pre AbstractMegaTunnel).
Rovnako moze byt Tunnel trieda a MegaTunnel podtrieda.
-
Javovské programy píši ve Vimu.
A nechcete upgradovat?
http://www.ebay.com/itm/Vintage-Remembered-EM-Punch-Hand-Keypunch-Device-Mdl-EM80-A-Ships-Worldwide-/191500271854?pt=LH_DefaultDomain_0
-
este dodam, co sa tyka podtried, tak ked mam Tunnel a MegaTunel jej podtriedu, tak sa Tunnel nezvykne pomenovat len "Tunnel" ale aj tam sa da nejake pridavne meno, ako napriklad "BaseTunnel". Z toho je zrejmen, ze MegaTunell extends BaseTunnel kde BaseTunnel je konkretna trieda, kdezto ak by som to mal abstraktne, tak by som to mohol pomenovat aj "AbstractBaseTunnel" a MegaTunnel extends AbstractBaseTunnel.
-
JDBC named parameters (pořád ještě?) neumí. Dají se použít další knihovny, ale otázka je, jestli autoři Javy neznají named parameters, nebo je považují za zbytečné.
jdbc sux. ak pouzivate vrstvu na pristup k databaze a tu urcite pouzivate a je jedno ci je to spring jdbc alebo ibatis alebo hibernate, mate tam analogiu
Psát tu samou aplikaci třikrát je vzor produktivity :)
to je dobry bullshit v tomto pripade.
pozrite si podiely aplikacii v apple storoch a na playi: kolko aplikacii je vyrobenych cez xamarin a spol?
typicka aplikacia je nativne vyrobena pre konkretnu platformu aby bola uplne integrovana
to je tiez dovod preco windows phone nema mnohe aplikacie, jednoducho sa neoplati udrziavat vyvoj pre dve majoritne a jednu biednu platformu
Tunnel a MegaTunnel, tak Tunnel je class nebo interface ?
to nepotrebujete vediet z nazvu ked to vidite v ide
-
Psát tu samou aplikaci třikrát je vzor produktivity
a preto microsoft kupil accompli aby ho rebrandol na outlook miesto toho aby z jedneho zdrojaku buildol outlooky pre vsetky tri platformy naraz
-
Tunnel nemoze byt abstraktna trieda pretoze to by sa volalo AbstractTunnel (rovnako plati ja pre AbstractMegaTunnel).
Takže "I" není košer, ale "Abstract" je košer :P Tomu se říká doublethink http://en.wikipedia.org/wiki/Doublethink
Opakuji že neobhajuji maďarštinu, ale jak je vidět tak problém zdaleka není vyřešen.
to nepotrebujete vediet z nazvu ked to vidite v ide
S tím souhlasím, ovšem jsou tady tvrzení že to z názvu jde poznat i bez maďarštiny.
-
jdbc sux. ak pouzivate vrstvu na pristup k databaze a tu urcite pouzivate a je jedno ci je to spring jdbc alebo ibatis alebo hibernate, mate tam analogiu
Souhlas, JDBC sux. Proč autoři Javy nepíší platformu tak aby se dala používat, a musí se i základní věci lepit různými knihovnami třetích stran? Za mě je to značná nevýhoda.
pozrite si podiely aplikacii v apple storoch a na playi: kolko aplikacii je vyrobenych cez xamarin a spol?
Záleží na aplikaci. U spousty věcí je zbytečné je psát třikrát. Projekty v Xamarinu navíc mohou mít platformě závislý kód, když to pro nějakou konkrétní věc potřebujete. I tak ušetříte velikou spoustu psaní.
to je tiez dovod preco windows phone nema mnohe aplikacie, jednoducho sa neoplati udrziavat vyvoj pre dve majoritne a jednu biednu platformu
WP mají více než půl milionu aplikací. Samozřejmě vzhledem k jejich malému rozšíření se řada aplikací neportuje, ale v praxi nevidím problém.
-
a preto microsoft kupil accompli aby ho rebrandol na outlook miesto toho aby z jedneho zdrojaku buildol outlooky pre vsetky tri platformy naraz
Outlook je veliká Win32 aplikace. Co to má společného s Xamarinem založeným na .NETu?
-
Viz například Silverlight, který měl být vlajkovou lodí a dnes po něm neštěkne ani pes - a společnosti, které na tom postavily svůj business, si teď rvou vlasy...
SilverLight je založený na XAML, a migrace je poměrně jednoduchá.
[/quote]
Jenom nabehne stado programatoru a bude to stat par desitek milionu, ze? :-) Mimochodem, kam presne budeme migrovat, kdyz Silverlight je thin client frontend technologie a v ramci dotNet zadna alternativa vlastne ani neni? Co se s tim jak je zvykem, zcela nestandardnim a nekonstentnim se zbytkem sveta Xaml vlastne stane?
Stejne jako se stalo s Windows forms, COM, ActiveX, Visual Basic, Win32, Win16 ? Budeme zase za dva roky prepisovat.
Jedno se Microsoftu uprit neda - svymi omyly umele zvysuje poptavku trhu a zvysuje ekonomicky obrat. Bohuzel zisky naopak snizuje...
Ad Jdbc - to je low level driver s primym pristupem Sql. Named parameters tam nemaji co delat, stejne jako setMaxResults apod, ktere zavadeji nejakou abstrakci nad dialekty.
-
Stejne jako se stalo s Windows forms, COM, ActiveX, Visual Basic, Win32, Win16 ?
Windows forms, COM, ActiveX, Win32 stále funguje. Například ActiveX lze psát v C#.
-
Tunnel nemoze byt abstraktna trieda pretoze to by sa volalo AbstractTunnel (rovnako plati ja pre AbstractMegaTunnel).
Takže "I" není košer, ale "Abstract" je košer :P Tomu se říká doublethink http://en.wikipedia.org/wiki/Doublethink
Opakuji že neobhajuji maďarštinu, ale jak je vidět tak problém zdaleka není vyřešen.
Uprimne nechapem co riesite. To, ze pomenujem abstraktnu triedu tak, ze dam pre nu "Abstract", nie je to iste ako ked dam pred interface "I". Vy sa na to zda sa mi pozerate uplne mechanicky a roboticky. Ved ked citam tie zdrojaky, tak nad tym aj rozmyslam co je co a nikdy by ma nenapadlo mysliet si ze ked nieco zacina na "I" tak to je abstraktna trieda alebo implementacia.
Navyse, nikdy by som osobne nepouzil v Jave na pomenovanie interface-u prefix "I", pretoze to je proste zle.
To ze to je interface vas ani teoreticky nemusi vobec zaujimat kedze sa ma programovat voci interfejsom a nie voci konkretnym triedam.
Takze ano, Abstract je koser pripad, davat "I" do interface-u koser.
-
Stejne jako se stalo s Windows forms, COM, ActiveX, Visual Basic, Win32, Win16 ? Budeme zase za dva roky prepisovat.
Mj. WinRT z Windows 8 je založeno na COMu.
-
... nie je
-
Souhlas, JDBC sux. Proč autoři Javy nepíší platformu tak aby se dala používat, a musí se i základní věci lepit různými knihovnami třetích stran? Za mě je to značná nevýhoda.
jdbc vzniklo asi v 199x a preto je api take ake je. navyse polovica problemov ide od zlych driverov od vendorov.
ano veci a la spring jdbc mohli byt v platforme ale zial. to uz vacsi fail je java.util.logging, ten sa fakt stat nemusel
to je presne dokaz toho ze ked sa vec urobi zle a zadratuje sa do platformy tak s tym vsetci musia zit
na druhej strane realne pouzitie v projekte si s jdbc nikdy nevystaci, aj keby bolo urobene dobre a preto mate na vyber bud ist cestou ibatisu alebo jpa
Záleží na aplikaci. U spousty věcí je zbytečné je psát třikrát.
"zbytecne je" ale ako vidiet dominantny sposob je ist nativnou cestou, popalil sa na tom facebook a iny zly priklad je goodreads ta aplikacia vyzera na zblitie
-
Skusim to vysvetlit este raz. Majme priklad s tym Tunnel.
Ak je Tunnel interface:
MegaTunnel implements Tunnel
Ake je Tunnel trieda
MegaTunnel extends Tunnel // tu vidim, ze Tunnel je konkretna trieda
Ak je Tunnel abstraktna trieda
MegaTunnel extends AbstractTunnel // z tohoto vidim ze AbstractTunnel je abstraktna trieda
Ak by bol aj MegaTunnel abstraktny, tak by som ho musel pomenovat
AbstractMegaTunnel extends AbstractTunnel
NIKDY by som nespravili toto:
MegaTunnel implements ITunnel
ani toto
MegaTunnel extends ITunnel
ani toto
MegaTunnel implements AbstractTunnel
Ak by som mal Tunnel ktory by musel implementovat nejaky interface, tak ten interface by som pomenoval "Tunnelable" takze by som mal
Tunnel implements Tunnelable
MegaTunnel extends Tunnel
Vobec nechapem, kde vidite nejednoznacnost.
-
dam pre nu "Abstract", nie je to iste ako ked dam pred interface "I"
V prvním případě přidáš před název písmenka "Abstract", v druhém případě před název písmenka "I", ale vůbec to není to samé a vůbec to není maďarština ;D
"Tunnelable"
suffix "able" je prakticky maďarština jako prefix "I".
-
dam pre nu "Abstract", nie je to iste ako ked dam pred interface "I"
V prvním případě přidáš před název písmenka "Abstract", v druhém případě před název písmenka "I", ale vůbec to není to samé a vůbec to není maďarština ;D
"Tunnelable"
suffix "able" je prakticky maďarština jako prefix "I".
able nemate čtenáře písmenkem navíc. Tunnelable je běžné anglické slovo. Navíc autor mluvil o situaci, kdy už je situace nějak daná.
Co se týče Abstract, používá se pro odlišení částečné implementace, kterou budou nejspíš všechny implementace sdílet. Hlavní rozdíl je v tom, že Abstract bývá pro uživatele neviditelný a je zajímavý pouze pro autora, který píše finální implementaci a ten stejně musí mít povědomí o hierarchii. Z hlediska uživatele daného interface i finální třídy tedy zůstává zachována _transparentnost_ !
-
dam pre nu "Abstract", nie je to iste ako ked dam pred interface "I"
V prvním případě přidáš před název písmenka "Abstract", v druhém případě před název písmenka "I", ale vůbec to není to samé a vůbec to není maďarština ;D
"Tunnelable"
suffix "able" je prakticky maďarština jako prefix "I".
Aha takze ako chcete vlastne rozlisit co je co? :) Bez toho aby ste tam dali Abstract alebo "able". C# sa mi zda pouziva to "I" na rozlisenie co je interface a co trieda. Ja v Jave "I" nepouzivam a interfejs je pomenovany bud podstatnym menom alebo privlastkom "able". To, ci to je alebo nie je interface som ako uz povedal moze byt jedno.
Java pouziva len Abstract, C# pouziva masivne to I.
Bol by som zvedavy ako C# riesi pomenovanie abstraktnych tried. Ked to pouziva tak isto ako Java, tak C# prehrava 1:2, pretoze Java nepouziva "I".
-
able nemate čtenáře písmenkem navíc.
Proto je mate čtyřmi písmenkami navíc :) Raději ani nechci vedět, co se stane když chci pracovat s "Capable", zřejmě "Capableable" :)
C# se nezastávám a bez nějaké formy maďarštiny to zřejmě rozlišit nejde, jsem rád že jsme se na tom shodli.
-
Souhlas, JDBC sux. Proč autoři Javy nepíší platformu tak aby se dala používat, a musí se i základní věci lepit různými knihovnami třetích stran? Za mě je to značná nevýhoda.
jdbc vzniklo asi v 199x a preto je api take ake je. navyse polovica problemov ide od zlych driverov od vendorov.
JDBC je chory z definice. Od zacatku to vypada, jako by autori nikdy nevideli jinou databazi nez MySQL. Od zacatku se snazi podporovat nejmensi spolecny jmenovatel vsech databazi. Autocommit je by-default zapnuty proboha proc? Protoze MySQL nepodporuje transakce? V te dobe uz jim to melo byt jasny, ze je to spatne. MySQL nepodporuje named bind variables, tak JDBC to nebude umet taky?
JDBC podporuje pouze skalarni datove typy: NUMBER, STRING a DATE. A i s tim datumem ma spousta lidi problemy (viz java.util.date vs. java.sql.date).
Anebo JDBC 4.0. java.sql.Connection.createBlob(): "LOB creation - New methods, createBlob() and createClob() let you create empty Blobs and Clobs, which you can then fill up before stuffing into a column.". Ok tak vytvorim blob, zapisu do nej desitky GB dat a pak ten blob vlozim do nejaky radky v databazi. (jako bind variable). S tim jako ma ta databaze delat? To funguje v pripade MySQL JDBC driveru, ze je max. velikost blobu 30MB. Anebo se to (v pripade Oracle kopiruje z disku TEMP tbs na disk DATA tbs). Navic databaze netusi kdy GC ten objekt uvolni a ty data lezi v TEMP tablespace dokud se neuzavre db spojeni.
Uznavam navrhnout jednotny API pro ruzny databaze je tezky (skoro nemozny), ale pred tim uz tu byl pokus s ODBC, tak se mohli poucit z cizich chyb.
-
"Tunnelable"
suffix "able" je prakticky maďarština jako prefix "I".
Je dobrým zvykem pojmenovávat interface přídavným jménem. Samotný název pak vysvětluje, jakou schopnost musí mít implementace. Slovo "Tunnelable" tedy znamená, že implementace musí umět tunelovat.
Není to tedy maďarština, ale angličtina. Prefix "I" nic takového nevyjadřuje a proto není žádoucí ho používat.
-
able nemate čtenáře písmenkem navíc.
Proto je mate čtyřmi písmenkami navíc :) Raději ani nechci vedět, co se stane když chci pracovat s "Capable", zřejmě "Capableable" :)
Třídy se pojmenovávají podstatným jménem, třída se tedy nemůže jmenovat "Capable". Navíc interface se nikdy nepojmenovává podle tříd, které ho mají implementovat.
-
Je dobrým zvykem pojmenovávat interface přídavným jménem.
To přesně je maďarská notace v nóbl balení.
Třídy se pojmenovávají podstatným jménem, třída se tedy nemůže jmenovat "Capable". Navíc interface se nikdy nepojmenovává podle tříd, které ho mají implementovat.
Toť důkaz že suffix "able" je rezervován pro maďarskou notaci.
-
Třídy se pojmenovávají podstatným jménem, třída se tedy nemůže jmenovat "Capable". Navíc interface se nikdy nepojmenovává podle tříd, které ho mají implementovat.
Toť důkaz že suffix "able" je rezervován pro maďarskou notaci.
Pro interface jsou rezervována všechna přídavná jména. Co na tom nechápeš?
-
Je dobrým zvykem pojmenovávat interface přídavným jménem.
To platí i pro rozhraní datových struktur? Např. pro rozhraní seznamů, front, množin?
-
Je dobrým zvykem pojmenovávat interface přídavným jménem.
To platí i pro rozhraní datových struktur? Např. pro rozhraní seznamů, front, množin?
Nevyva to zvykom, pretoze datove struktury (ako nejaky interface) nemavaju vlastnosti. Toto tvrdenie berte prosim s rezervou. Ide proste o to, ze ked mam List v Jave a ArrayList jeho implementaciu, tak nema velmi zmysel pracovat s nejakym interfaceom ktory sa vola "Listable".
Proste je viac intuitivne ak "ArrayList implements List" ako "ArrayList implements Listable", takze v tomto pripade to neplati.
-
Lenze uz napriklad List ako interface v Jave extenduje "Iterable" a to je ukazkovy priklad ako to ma vyzerat. Tam sa uz popisuje to spravanie, co ten List vie, teda ze mozem na nom iterovat - v tom pripade sa to hodi.
-
Outlook je veliká Win32 aplikace. Co to má společného s Xamarinem založeným na .NETu?
hovorim o outlooku pre iphony. pozrite si, co to ms kupil.
je dobrým zvykem pojmenovávat interface přídavným jménem.
toto uz v novych java projektoch nevidiet. byvavalo ked bolo cloneable serializable ale dnes je to uz len pre marker metody (z novych mozno android parcelable). interface nemusi mat pridavne meno a casto ani nema. spring pouziva uz dlho initializingbean namiesto initializable alebo beannameaware namiesto nameable
nikomu to velmi nevadi
---
Autocommit je by-default zapnuty proboha proc?
nechcem vam brat iluzie ale vyvoj jdbc a mysql isli nezavisle od seba. jdbc driver pre mysql vznikol 1998, to uz bolo jdbc vyse roka na svete. ale mate pravdu s niektorymi prekotmi.
autocommit si viem predstavit automaticky zapnuty lebo vtedy sa planovalo pouzitie gui aplikaciach kde jeden riadok connection.commit() je zbytocny krok v tutoriali
takisto biedne datove typy: cielom bola portabilita a ako hovorite najmensi spolocny menovatel.
zvysok si mozete doriesit v knizniciach a ako som pisal aj budete
-
aby to nevyzeralo ze jdbc je vynalez storocia, neni.
-
Pro interface jsou rezervována všechna přídavná jména. Co na tom nechápeš?
Mě je to jasné již dávno. Pokud nezavedeš předpisy na tvorbu identifikátoru, tak nepoznáš zda se jedná o interface.
Rozdíl je prakticky jenom v tom, že tvůj předpis je "able" a u sousedů mají předpis "I". Lingvistické záležitosti mě nezajímají.
-
Pro interface jsou rezervována všechna přídavná jména. Co na tom nechápeš?
Mě je to jasné již dávno. Pokud nezavedeš předpisy na tvorbu identifikátoru, tak nepoznáš zda se jedná o interface.
Rozdíl je prakticky jenom v tom, že tvůj předpis je "able" a u sousedů mají předpis "I". Lingvistické záležitosti mě nezajímají.
Jenže pojmenování identifikátorů je lingvistickou záležitostí nezávisle na tvém zájmu.
-
Pro interface jsou rezervována všechna přídavná jména. Co na tom nechápeš?
Mě je to jasné již dávno. Pokud nezavedeš předpisy na tvorbu identifikátoru, tak nepoznáš zda se jedná o interface.
Rozdíl je prakticky jenom v tom, že tvůj předpis je "able" a u sousedů mají předpis "I". Lingvistické záležitosti mě nezajímají.
Ale to je přece nesmysl. Někdo (snad sadsa) na začátku uvedl nějaký příklad, ty ses toho chytil a udělal z toho konvenci. Ale tak to vůbec není!
Jméno pro interface má vyskytovat jeho funkci. Ano, v Javě jsou _v_některých_případech_ přídavná jména jako Serializable, Cloneable či Iterable, ale pouze tam, kde dávají smysl. Například Iterable identifikuje objekt, který je Iterovatelný. Ale List je rovněž interface a identifikuje objekt, který se chová jako seznam a je to podstatné jméno, protože seznam je podstatné jméno. Když půjdem do spring, je tam BeanFactory, který je interface a poskytuje funkce, které by člověk od správy fazolek. Je tam interface ApplicationContextAware, což je přídavné jméno, přeloženo jako být znalý aplikačního kontextu. Takže to není žádné dogma, používá se název, který vystihuje funkci.
To je obrovský rozdíl oproti maďarštině, kde se tupě následuje pattern pro jméno, bez toho, aniž by měl jakoukoli přidanou hodnotu, naopak je většinou kontraproduktivní.
-
List je rovněž interface
Tak znovu a pomalu: Z písmenek "L", "i", "s", "t" se nedá dedukovat žádným způsobem že se jedná o interface.
-
Je dobrým zvykem pojmenovávat interface přídavným jménem.
To platí i pro rozhraní datových struktur? Např. pro rozhraní seznamů, front, množin?
Ano i ne :-) Resp. dost programatoru cpe do svych aplikaci metody typu foobar(List<?>) i kdyz tam ma byt (a bohate dostacuje) napriklad Iterable. Navic si osobne myslim, ze JCF je sice na jednu stranu strasne fajn (je videt, ze u toho Josh Bloch premyslel), ale neni to OO-cisty navrh (mohl si dat vic zalezet :) a take zvolena jmena rozhrani apod. nejsou nejlepsi (List napriklad mohl byt klidne Sequence ;), duvod je asi zrejmy.
-
Pro interface jsou rezervována všechna přídavná jména. Co na tom nechápeš?
Mě je to jasné již dávno. Pokud nezavedeš předpisy na tvorbu identifikátoru, tak nepoznáš zda se jedná o interface.
Rozdíl je prakticky jenom v tom, že tvůj předpis je "able" a u sousedů mají předpis "I". Lingvistické záležitosti mě nezajímají.
Nepoznas a vetsinou by to nemelo vadit ne? Myslim to tak, ze API byvaji popsana s vyuzitim interface a s konkretni implementaci toho rozhrani se setkas tak nekde pri volani konstruktoru nebo "tovarny" :)
-
Tak znovu a pomalu: Z písmenek "L", "i", "s", "t" se nedá dedukovat žádným způsobem že se jedná o interface.
mate pravdu neda
a?
-
List je rovněž interface
Tak znovu a pomalu: Z písmenek "L", "i", "s", "t" se nedá dedukovat žádným způsobem že se jedná o interface.
Neda, proc by melo? (nechceme prece madarstinu ;). Navic budme presni - madarska notace se pouzivala i pro nazvy parametru, globalnich promennych i lokalnich promennych, to bylo maso. Proti tomu to hnusny IMojeRozhrani je jeste nadhera.
-
hovorim o outlooku pre iphony. pozrite si, co to ms kupil.
Vím co MS koupil. Kód starého mobilního Outlook nemá s desktopovým Outlookem prakticky nic společného, právě protože desktopový Outlook je velká Win32 aplikace, kterou nemá smysl portovat na telefon. Outlook na Windows Phone je zase výrazně provázaný se systémem, a iOS ani Android nemají potřebnou infrastrukturu. MS tedy místo rozvoje vlastního mobilního Outlooku pro iOS a Android koupil hotový kód, a lidi k tomu.
-
Tuhle diskuzi, respektive tu její část ohledně nepatrných pozůstatků maďarské notace v .NET by měli ukazovat na školách. Učte se děti, vyučte se programátorem, koukejte, jaké budete mít starosti :-)
-
Outlook na Windows Phone je zase výrazně provázaný se systémem, a iOS ani Android nemají potřebnou infrastrukturu.
prave ste si odpovedali preco sa aplikacie vyvijaju nadvakrat a natrikrat
(teraz vynecham debatu o tom ze by som rad vedel co je ta potrebna infrastruktura a funkcionalita na androide a iphone nie je)
-
Tuhle diskuzi, respektive tu její část ohledně nepatrných pozůstatků maďarské notace v .NET by měli ukazovat na školách. Učte se děti, vyučte se programátorem, koukejte, jaké budete mít starosti :-)
na tricko si dat:
LPCSTR is a 32-bit pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters.
-
Tuhle diskuzi, respektive tu její část ohledně nepatrných pozůstatků maďarské notace v .NET by měli ukazovat na školách. Učte se děti, vyučte se programátorem, koukejte, jaké budete mít starosti :-)
To jo,
kit napíše "I bez prefixů lze velmi snadné rozpoznat Třídu, instanci, metodu() i interface. Prefixy jsou zbytečné.",
Kolemjdouci na to "Výše uvedené tvrzení není platné pro dvojici "instanci" "interface".",
pak tři stránky komentářů, kde má každý "pravdu",
a nakonec Kolemjdoucí: "Tak znovu a pomalu: Z písmenek "L", "i", "s", "t" se nedá dedukovat žádným způsobem že se jedná o interface."
a na to perceptron: "mate pravdu neda
a?
"
Asi mi to přijde spíš vtipný než smutný .. nebo naopak? ani nevím..
-
Cely flame ohladom pomenovania je smiesny. Naming convention je v jednotlivych jazykoch preto, aby sa dalo pohodlne orientovat a rozoznat ci ide o triedu, iface, propertu, field, .... A to aj ked otvorim cudzi kod po par rokoch.
Osobne pisem v c# 5 rokov, a pomenovanie interfacov s "I" mi pride uplne normalne (btw. neviem co madarske vidite na tomto zapise). Verim,ze javistom sa to zda divne, ale nie je to nic ine ako zvyk. Presne ako pomenovanie premennych/fieldov podla typu v c++.
Inak nikto tu zatial nespomenul feature c# z poslednej verzie - async/await. Toto je podla mne jedna z top veci, pre ktore je c# o nieco lepsi. Brutalne to dokaze zprehladnit kod.
-
Asi mi to přijde spíš vtipný než smutný .. nebo naopak? ani nevím..
cele je to o tom, ze je to konvencia ktora ma viac legacy zmysel nez racionalny dovod. ako vravi predrecnik, pride veteran c# do projektu, uvidi ITrollService a citi sa ako v rodinnom krbe
neviem co madarske
http://en.wikipedia.org/wiki/Hungarian_notation
-
Když porovnám VS2010 (2013 jsem zatím neviděl) s tím, co umí Eclipse nebo Intellij Idea jednoduše na right-click nebo jednoduchou zkratkou přes Alt-Enter, tak je to nesrovnatelné drbání se pravým palcem u nohy na levém oku. Jediný problém s Intellij Idea je to, že plná verze je komerční, nicméně i ta free je na tom líp, než VS Ultimate edition :-)
Vidim, ze se tady nadava na VS v plnem proudu.. Z VS pracuji denne uz par let a nemuzu na neho rict spatne slovo. Mel jsem sanci take pracovat s Intellij, Netbeans, Xamarin Studio, atd.. ale zadny z techto IDE mi nenabidl takovou jednoduchost a radost z prace jako VS hned od zacatku.
Je pravda, ze ty jine IDE jsem nepoznal do hloubky, takze nemuzu rict co vsechno umi. Tady je seznam funkcnosti VS, ktere jsou neocenitelne, porovnejte si to sami s jinymi IDE:
- Ucet vyvojare v cloudu - uklada se nastaveni, takze po ciste instalaci se staci prihlasit a mame IDE ve stavu v jakem jsme ho posledne pouzivali
- Podpora velkeho poctu jazyku a technologii i tech, ktere nebyly vytvorene pres Microsoft (C#, C++, VB, Python, JavaScript, TypeScript,... | Angular, Knockout,... ) - napr. v VS 2015 bude podpora frameworku React i s Jsx
- Paradni debugging - staci najet mysi na nejaky objekt a hned vidime jeho aktualni stav, tak stejne muzeme videt i vnorene objekty.
- Debugging vlaken - je mozne, nektere vlakno/vlakna zmrazit, prepinat debugger mezi vlakny, poustet jenom, nektere vlakna, podivat se co, ktere vlakno dela. Hodne krat jsem vyuzil moznosti vzdaleneho pripojeni debuggerem k bezici aplikaci a podivani se co dela MainThread (pokud je GUI zaseknute)
- Edit and continue - naprosto uzasna vec, muzete upravovat kod aplikace za behu. Pokud treba vytvarim novy plugin pro velkou desktopovou aplikaci, musim se proklikat x dialogy, nez muzu vubec otestovat novy kousek kodu. Diky Edit and continue nemusim aplikaci vypinat, staci hodit breakpoint, upravit kod a pustit dal a muzu hned testovat novou funkcnost.
- Vyborna podpora prace pouze pomoci klavesnice
- Je mozne si uplne przizpusobit textovy editor, vzhled, klavesove zkratky a dalsi nastaveni IDE
- Dalsi tooly - architektura aplikace (UML, ERD, atd..), unit testy, profiler (pamet, procesor, soubeznost, atd..)
- Nasazeni do cloudu (Azure) nove webove aplikace na tri kliknuti, update existujici na jedno kliknuti
- A plno dalsich veci. A abych nezapomnel, VS je rychle a s SSD diskem je PEKELNE rychle. Tomuto nemuzou vsechny IDE napsane v jave nikdy dorovnat
-
Osobne pisem v c# 5 rokov, a pomenovanie interfacov s "I" mi pride uplne normalne (btw. neviem co madarske vidite na tomto zapise). Verim,ze javistom sa to zda divne, ale nie je to nic ine ako zvyk. Presne ako pomenovanie premennych/fieldov podla typu v c++.
Normální Vám to přijde, protože jste se nezamyslel nad alternativou. Problémem je právě ona netransparentnost. Když nějaká third party udělá z třídy interface (jako se to stalo například u log4j při přechodu z verze 1 na verze 2), tak s Vaším "normálním" přístupem budete přepisovat celou aplikaci, zatímco javista normálně zvednul verzi o jedničku.
Rovněž pojmenování proměnných podle typu v C++ bylo "normální" pouze na windows a díky tomu úpravy na 32-bit windows stály miliardy a to samé znovu při upgrade na 64-bit, stejně tak, když měly být aplikace schopné pracovat s 2GB soubory (tam to MS ještě "vylepšil" se svými Ex funkcemi). Zatímco na jiných systémech stačilo program překompilovat a port na zcela jinou platformu byl hotový. Je naprosto absurdní, že se z toho Microsoft nedokázal ani poněkolikáté poučit a windows api stále všude obsahuje maďarštinu...
-
* o cloud ukladani settingsov neviem
* netbeansy podporuju vsetko mozne (java, c++, webove technologie dodavaju s kazdym releasom), intelij takysto
* paradny debugging je standardom vo vsetkych troch java ide
* debug vlakien je standardom uz dlhu dobu
* hot code swap je standardom uz dlhu dobu, je to vlastnost jvm, akurat to sux pri zmene struktury tried. standardne sa da kupit jrebel ktory obmedzenie obide
* klavesnica je hadam standard od vimu, detto customizacia
* profiler je standardom (eclipse nema zabudovany)
* uml, erd a podobne tooly su v pluginoch, pouzitelnost sa lisi od ide k ide a od pluginu k pluginu
* nasadenie do cloudu sa neriesi
* co sa tyka tempa napriek mytom a bajkam nie je problem ani tak s cpu/hdd ako s ram
-
neviem co madarske
http://en.wikipedia.org/wiki/Hungarian_notation
[/quote]
Tak z tohoto linku, čo si postol, si dovolím zacitovať posledné vyjadrenie:
Microsoft's Design Guidelines discourage developers from using Hungarian notation when they choose names for the elements in .NET Class Libraries, although it was common on prior Microsoft development platforms like Visual Basic 6 and earlier. These Design Guidelines are silent on the naming conventions for local variables inside functions.
Inak mi neni celkom jasné, čo má spoločné Ixxx s Hungarian notáciou a s ktorou. System, či application?
A už vôbec mi neni jasné, prečo to niekomu tak dvíha tlak. Proste niekto kto navrhoval .NET framework rozhodol, že je na niečo užitočné jedoducho identifikovať rozhrania predponou I. V iných jazykoch je zas prípona Interface (PHP?), v Jave vravíte že nie, proste je to fuk, chcel by som vedieť, kto sa na základe tohoto rozhodne, či bude písať v danom jazyku. Táto diskusia by si zaslúžila vlastý thread ;)
-
Prostředí by mělo vyžadovat, aby programátor pojmenoval program, třídu nebo objekt. Pokud mu místo toho nabídne nějaký provizorní název a programátor to tak nechá, časem se mu to vymstí. Méně je často lépe.
Tak toto je totalna hovadina, to ani nebudem komentovat.
Pravda je taka ze u nas vo firme kodime aj v jave aj v C# kazdy kto skusal obidve platformy nadava na Javu. Uz len vyvojove prostredia pre .NET su luxusnejsie. Eklips je tragedia ktora furt pada, Android studio je lepsie ale luxusu Viusual Studia sa stale nechyta. Aspon tak hovoria moji kolegovia. Ja sa drzim .NETu k jave ma nikto nedostane.
Maďarské názvy interface jsou vidět i v systémových knihovnách C#. Tyto názvy měnit nemůže.
Systemovych knihovnach C#? myslite ked si programator do projektu naimportuje Windows API funkcie? Cele Windows API je v hungarian notation - napisane v C a C++ (kde sa madarska notacia zvykne pouzivat doteraz). takze je dobre ked sa nazvy naimportovanych funkcii tychto konvencii drzia, ale v .NET je dobrym zvykom obalit ich do objektoveho wrapperu. hungarian notation je relikt z polovice 80tych rokov a v .NETe sa bezne nepouziva.
-
Šest stránek diskuze o tom, jestli je lepší psát INejakyInterface, nebo jen NejakyINterface. Páni.
-
Inak mi neni celkom jasné, čo má spoločné Ixxx s Hungarian notáciou a s ktorou. System, či application?
System/App je celkem nepodstatne. V madarske notaci se pridavaji pred jmena promennych/funkci prefixy ktere nejak oznacuji typ. Tady se pridava prefix ktery oznacuje ze je to rozhrani. Takze dost podobne.
A už vôbec mi neni jasné, prečo to niekomu tak dvíha tlak. Proste niekto kto navrhoval .NET framework rozhodol, že je na niečo užitočné jedoducho identifikovať rozhrania predponou I. V iných jazykoch je zas prípona Interface (PHP?), v Jave vravíte že nie, proste je to fuk, chcel by som vedieť, kto sa na základe tohoto rozhodne, či bude písať v danom jazyku. Táto diskusia by si zaslúžila vlastý thread ;)
Myslim ze je to proto ze madarska notace se da obecne povazovat za spatny napad :-)
-
Uz len vyvojove prostredia pre .NET su luxusnejsie. Eklips je tragedia ktora furt pada, Android studio je lepsie ale luxusu Viusual Studia sa stale nechyta. Aspon tak hovoria moji kolegovia. Ja sa drzim .NETu k jave ma nikto nedostane.
Je to nekolik let zpatky, co jsem prechazel z C# na Javu (a nasledne Scalu). V casech, kdy bylo VS placene se bez R# nedalo pouzivat. Kdyz jsem vyzkousel IntelliJ IDEA dost me prekvapilo, ze se to rovna placenemu Visual Studiu s placenym R# pluginem, presto je to zdarma dostupne. Co se tykalo prechodu mezi IDE, tak jsem pouze prenastavil zkratky na ty naucene z VS a normalne jsem zacal fungovat. Nic me rozhodne nechybelo. Dokonce si myslim, ze naseptavani bylo (v te dobe, nevim jak ted) kvalitnejsi nez ve VS.
Velmi omezene jsem (po donuceni) vyzkousel Eclipse i NetBeans. Oproti IDEA na mne moc dojem neudelaly. Presto se me ale nikdy nestalo, ze by mi Eclipse zhavaroval (nekdy se vlekl velmi line).
Ja sa drzim .NETu k jave ma nikto nedostane.
Zminujete .NET, takze je fer srovnavat s JVM jazyky - napr Scala je zajimava volba. Oproti Jave jde psat mnohem strucneji a vystizneji. Obsahuje hodne vychytavek a ve srovnani s C# na tom byla dost podobne. Neco malo jsem cetl i o Groovy, nevypada to spatne, ale pro me je to asi moc divoke - dynamicke.
-
Casto krat sa mi pozastavuje mysel, co sa tu za kktiny dokazu rozobrat, este na tolko stranok. Riesit aku notaciu pouzit tam a hentam je ozaj odveci. Ked pridete do firmy a povedia vam, ze maju zauzivane pouzivat IIIInterface, tak budete pouzivat to. A tie zvasty, ktore sa tu rozvinuli na X stranok, vam budu k nicomu... ;)
-
Casto krat sa mi pozastavuje mysel, co sa tu za kktiny dokazu rozobrat, este na tolko stranok. Riesit aku notaciu pouzit tam a hentam je ozaj odveci. Ked pridete do firmy a povedia vam, ze maju zauzivane pouzivat IIIInterface, tak budete pouzivat to. A tie zvasty, ktore sa tu rozvinuli na X stranok, vam budu k nicomu... ;)
Kdyby me ve firmne rekli ze pouzivaji "IIIInterface" tak se zbalim a pujdu o dum dal. Najit si jinou praci je celkem snadny kdyz neco umis... :-D
-
jo to je argument, ked nieco vies...a pridete do inej firmy a tam vam povedia, ze pouzivaju InterfaceABC, tak tiez sa zbalite a odidete, lebo to nevyhovuje vasej predstave? To potom aby ste neostali bez prace :P
-
jo to je argument, ked nieco vies...a pridete do inej firmy a tam vam povedia, ze pouzivaju InterfaceABC, tak tiez sa zbalite a odidete, lebo to nevyhovuje vasej predstave? To potom aby ste neostali bez prace :P
Nastesti existujou i firmy kde nejsou sami amateri :-)
-
Casto krat sa mi pozastavuje mysel, co sa tu za kktiny dokazu rozobrat, este na tolko stranok. Riesit aku notaciu pouzit tam a hentam je ozaj odveci. Ked pridete do firmy a povedia vam, ze maju zauzivane pouzivat IIIInterface, tak budete pouzivat to. A tie zvasty, ktore sa tu rozvinuli na X stranok, vam budu k nicomu... ;)
Kdyby me ve firmne rekli ze pouzivaji "IIIInterface" tak se zbalim a pujdu o dum dal. Najit si jinou praci je celkem snadny kdyz neco umis... :-D
Třeba u Javy nemusíš ani nic umět a ruce ti utrhají. Dneska už je z IT žumpa, kde je každý, ale většina nic neumí. Takže je otázkou, jak jsi to vlastně myslel.
-
takze podla notacii sudis ci je clovek amater? tak to je dost chabe. potom aj MS ked pouziva Ixxxx, tak tam robia amateri podla vasho argumentu.
-
takze podla notacii sudis ci je clovek amater?
nejen podle notaci, ale celkove podle kodu.
tak to je dost chabe. potom aj MS ked pouziva Ixxxx, tak tam robia amateri podla vasho argumentu.
jo MS je plnej amateru
-
jo to vravi clovek o ktorom nevieme, co dosiahol a cim sa preslavil :D
-
jo to vravi clovek o ktorom nevieme, co dosiahol a cim sa preslavil :D
a kritizuje ho za to druhej clovek o kterym taky nic nevime :D
-
takze podla notacii sudis ci je clovek amater?
nejen podle notaci, ale celkove podle kodu.
tak to je dost chabe. potom aj MS ked pouziva Ixxxx, tak tam robia amateri podla vasho argumentu.
jo MS je plnej amateru
Aktualne java vyvojari jsou uplne mimo, pracuji s pravekou technologii, ve ktere je vsechno dolepovane a vsechny novinky jsou zkopirovane z C#. Java vyvojar se nedostane k modernim vecem. Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi. C# a cela .NET platforma je tak 10 let popredu pred vsemi dalsimi konkurencnimi technologiemi. Je to tak i kdyz si to vetsina java vyvojaru nechce priznat.
Jak uz bylo zmineno v jednom clanku dnesni Microsoft pod vedenim Satya Nadella je jako byl kdysi Google. Inovativni, open source a atd..
-
ale ja sa neobuvam do niekoho, po niekom vidiet, ze nieco dokazal a preslavil. to vy robite.
-
takze podla notacii sudis ci je clovek amater?
nejen podle notaci, ale celkove podle kodu.
tak to je dost chabe. potom aj MS ked pouziva Ixxxx, tak tam robia amateri podla vasho argumentu.
jo MS je plnej amateru
Aktualne java vyvojari jsou uplne mimo, pracuji s pravekou technologii, ve ktere je vsechno dolepovane a vsechny novinky jsou zkopirovane z C#. Java vyvojar se nedostane k modernim vecem. Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi. C# a cela .NET platforma je tak 10 let popredu pred vsemi dalsimi konkurencnimi technologiemi. Je to tak i kdyz si to vetsina java vyvojaru nechce priznat.
Jak uz bylo zmineno v jednom clanku dnesni Microsoft pod vedenim Satya Nadella je jako byl kdysi Google. Inovativni, open source a atd..
Tak proč potopili Xbox? To šli všichni dělat C#?
-
Aktualne java vyvojari jsou uplne mimo, pracuji s pravekou technologii, ve ktere je vsechno dolepovane a vsechny novinky jsou zkopirovane z C#. Java vyvojar se nedostane k modernim vecem. Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi. C# a cela .NET platforma je tak 10 let popredu pred vsemi dalsimi konkurencnimi technologiemi. Je to tak i kdyz si to vetsina java vyvojaru nechce priznat.
Jenom pro info - ja delam hlavne c++
Jak uz bylo zmineno v jednom clanku dnesni Microsoft pod vedenim Satya Nadella je jako byl kdysi Google. Inovativni, open source a atd..
Zmenit image po tech letech bude dost tezky, ale jestli se ukaze ze je to pravda tak ja jim klidne dam sanci. Zatim o tom ale presvedcenej nejsem.
-
ale ja sa neobuvam do niekoho, po niekom vidiet, ze nieco dokazal a preslavil. to vy robite.
Mohl bych sem napsat na cem jsem delal a delam, ale stejne bys me neveril. A konec koncu na tom stejne nezalezi - nemusim byt pekar abych poznal spatnej chleba...
-
takze podla notacii sudis ci je clovek amater?
nejen podle notaci, ale celkove podle kodu.
tak to je dost chabe. potom aj MS ked pouziva Ixxxx, tak tam robia amateri podla vasho argumentu.
jo MS je plnej amateru
Aktualne java vyvojari jsou uplne mimo, pracuji s pravekou technologii, ve ktere je vsechno dolepovane a vsechny novinky jsou zkopirovane z C#. Java vyvojar se nedostane k modernim vecem. Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi. C# a cela .NET platforma je tak 10 let popredu pred vsemi dalsimi konkurencnimi technologiemi. Je to tak i kdyz si to vetsina java vyvojaru nechce priznat.
Jak uz bylo zmineno v jednom clanku dnesni Microsoft pod vedenim Satya Nadella je jako byl kdysi Google. Inovativni, open source a atd..
A nazorny priklad:
Uplna novinka v Jave 8 (rok 2014):
public Optional<Article> getFirstJavaArticle() {
return articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst();
}
A naproti tomu, LINQ v C#, ktery je s nama od roku 2007:
public Article GetFirstJavaArticle()
{
return articles.FirstOrDefault(x => x.Tags.Contains("Java");
}
Co vam pripada prehlednejsi, citelnejsi a jednodussi na nauceni??
-
public Optional<Article> getFirstJavaArticle() {
return articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst();
}
A naproti tomu, LINQ v C#, ktery je s nama od roku 2007:
public Article GetFirstJavaArticle()
{
return articles.FirstOrDefault(x => x.Tags.Contains("Java"));
}
Co vam pripada prehlednejsi, citelnejsi a jednodussi na nauceni??
Ja nenavidim fakt ze nazov metody sa zacina velkym pismenom. Dalej nechapem na prvy pohlad co robi to "default" v tej metode.
Osobne mi vobec nejde o to "na kolko to je riadkov". To je teraz strasne v mode, aby to bolo mega strucne, rataju sa riadky .... "C# je viac strucne, tamto je viac strucne ..." atd atd. To su argumenty uplne o nicom. V case code completition je mi uplne jedno ci to je na tri riadky CEZ FLUENT API alebo na jeden. Mne osobne nevadi ze Java to dala na tri metody a C# len na jednu. Vobec.
-
Java je totiž král. Kdyby byla tak špatná a pomalá, tak se v ní dnes nebude dělat úplně všechno.
-
sadsa:
co nechapete na default vo FirstOrDefault? ak by ste vedeli, tak ak pouzijete napr. MyObj obj = default(MyObj), tak obj bude null. Cize vychadza sa z toho, z mojho pohladu.
-
A nazorny priklad:
Uplna novinka v Jave 8 (rok 2014):
public Optional<Article> getFirstJavaArticle() {
return articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst();
}
A naproti tomu, LINQ v C#, ktery je s nama od roku 2007:
public Article GetFirstJavaArticle()
{
return articles.FirstOrDefault(x => x.Tags.Contains("Java");
}
Co vam pripada prehlednejsi, citelnejsi a jednodussi na nauceni??
Nad default bych se asi taky napoprve pozastavil, ale je to IMO jen detail.
Ta C# verze se mi zda, ze nedela uplne presne to stejne, co Java verze, ktera vraci Optional (tj. vzdy ne-null wrapper).
Jen pro zajimavost (pokud chcete teda hodnotit delku) Scala verze:
def firstJavaArticle = articles.find(_.tags.contains("Java"))
-
a umi ten LINQ v C# retezit operace, co se v jave provadeji nad streamy?
-
citatelnejsie mi pride veru C# verzia a aj menej narocna na zapis. To potom mozme popriet tvrdenie, ze to co urobim v C++ spravim na 6 riadkov, tak v C# na 2 riadky
-
citatelnejsie mi pride veru C# verzia a aj menej narocna na zapis. To potom mozme popriet tvrdenie, ze to co urobim v C++ spravim na 6 riadkov, tak v C# na 2 riadky
c++ kdyby to nekoho zajimalo:
Article *get_first_java_article() {
auto i = std::find_if( articles.begin(), articles.end(),
[](Article *a) { return a->tags.count("java"); });
return i != articles.end() ? *i : nullptr;
}
Jinak prijde me ten priklad mirne usitej na miru c#. Ten kod tam vychazi kratsi protoze na tuhle konkretni vec tam je library funkce. V ostatnich jazycich treba neni ale na par radku si ju muzu dodelat...
-
citatelnejsie mi pride veru C# verzia a aj menej narocna na zapis. To potom mozme popriet tvrdenie, ze to co urobim v C++ spravim na 6 riadkov, tak v C# na 2 riadky
c++ kdyby to nekoho zajimalo:
Article *get_first_java_article() {
auto i = std::find_if( articles.begin(), articles.end(),
[](Article *a) { return a->tags.count("java"); });
return i != articles.end() ? *i : nullptr;
}
Jinak prijde me ten priklad mirne usitej na miru c#. Ten kod tam vychazi kratsi protoze na tuhle konkretni vec tam je library funkce. V ostatnich jazycich treba neni ale na par radku si ju muzu dodelat...
ano suhlasim s vami
-
Hoj, mam problem si najst pracu v nasom meste ... ak si clovek pozera pracovne ponuky je to sami .net developer, na pracovnych pohovoroch tak isto sa ma potencionalny zamestnavatel snazil ukecat na .net framework. Aky mate nazor na to vy? Oplati sa jave venovat nadalej a odist za pracou inam alebo konvertovat na C# ? Co sa do buducnosti viac oplati ? Vdaka
Tato otazka sa mi zda trochu cudna, ale asi mas iny svetonazor ako napr. ja.
Pre mna je dolezite:
* O aku prac sa jedna a ci bude pre mna zaujimava
* Co je to za firma
* Kolko rocne zarobim
* Ci mam okrem toho nejake bonusy: napr. rocne odmeny, mobil, priplatok na 3. pilier dochodkoveho poistenia, sluzone auto atd ...
a nejaky jazyk resp. technologia pride u mna na rad az potom.
V pripade ze by ma predosle body oslovili a potencionalny zamestnavatel by mi ponukol pracovat s C# napriek tomu ze ovladam iba Javu, tak by som nevahal. Viazat sa striktne na jednu technologiu je podla mna chyba.
Ak mas moznost vyskusat aj nieco ine, myslim ze ti to rozsiri obzor a bude moct z toho profitovat v buducnosti.
Nikto teraz nevie co sa v buducnosti viac oplati. V minulosti napriklad bol dopyt po dBase, Clipper, Delphi, Visual Basic. Skusali tym napriklad nahradit COBOL. Teraz su tieto technologie zabudnute, ale COBOL tu je este stale.
Osobne, ked porovnam C# a Java, tak na zaklade skusenosti s technologiami MS, by som odhadoval, ze Java ma ovela vacsiu perspektivu. Java je novy COBOL a nebude ju mozne len tak nahradit niecim inym. MS len pred par rokmi mal svoje Visual technologie, potom prisiel s .NET zachvilu moze prist s niecim uplne inym.
Ale to nie je dovod preco teraz neist do C# ak bude ponukana praca dostatocne challengujuca a honorovana.
Podla mna najlepsie su na tom vyvojari s know-how v urcitej oblasti, ktori su dost flexibilni a vedia sa prisposobit pozadovanej technologii.
-
AFAIK to API v jave je delany s ohledem na to, ze tech stream operaci se da retezit vic za sebou a snadno se v tom da pouzit paralelismus pomoci vlozeni .parallel(), takze imho mi to pripada jako rozdil pouziti univerzalniho API a jednoucelove funkce
-
mikrom, diky za prispevok! zikofel ma pravdu tiez. dobre chlapi :)
-
Ziktofel: To jde s lehce upravenou C# verzi taky.
public Article GetFirstJavaArticle()
{
return articles.AsParallel()
.Where(x => x.Tags.Contains("Java"))
.FirstOrDefault();
}
IEnumerable<T> je lazy list, funkce nad nim se daji komponovat jako ve funkcionalnich jazykach. Select je map, SelectMany je mapcat, Where je filter, je tam hromada foldu...
-
AFAIK to API v jave je delany s ohledem na to, ze tech stream operaci se da retezit vic za sebou a snadno se v tom da pouzit paralelismus pomoci vlozeni .parallel(), takze imho mi to pripada jako rozdil pouziti univerzalniho API a jednoucelove funkce
a umi ten LINQ v C# retezit operace, co se v jave provadeji nad streamy?
Ano, řetězení i paralelismus (pomocí AsParallel) jsou podporovány - viz např. https://msdn.microsoft.com/en-us/library/dd460719%28v=vs.110%29.aspx (https://msdn.microsoft.com/en-us/library/dd460719%28v=vs.110%29.aspx).
Na rozdíl od Javy umí C# navíc z výrazu udělat AST, s nímž se pak za běhu může pracovat. Například v dotazu
var query =
from order in context.SalesOrderDetails
where order.OrderQty > orderQtyMin && order.OrderQty < orderQtyMax
select new
{
SalesOrderID = order.SalesOrderID,
OrderQty = order.OrderQty
};
se funkci Where předá AST podmínky order.OrderQty > orderQtyMin && order.OrderQty < orderQtyMax, který se pak za běhu programu přeloží do SQL.
Krom toho obrovskou výhodou C# oproti Javě je podpora async + await pro psaní asynchronního kódu.
-
K tomu úžasnýmu NETu:
http://myego.cz/item/microsoft-a-jeho-hazeni-klacku-pod-nohy-net-vyvojarum/category/ze-zivota/group/29
Já kdysi ze zvědavosti zkoušel VS, teď nevím jestli 2008 nebo 2010 a takový pomalý, rozežraný a někdy padající moloch aby jeden pohledal. Bez R# to neumí ani věci, které maji Javovská IDE v základu zadarmo (generování kódu, navigace atd.). Děkuji, nechci.
-
mikrom:
Neviem ci by zobrali cloveka, ktory ovlada javu, ked oni maju poziciu na c# s 2 rocnymi skusenostami.
Eda Beda:
Rozpravas o VS ako keby padal ako jablka zo stromu. Urcite mi padol menej krat ako netbeans, ktory som musel castokrat odpalovat ukoncim procesu.
-
Krom toho obrovskou výhodou C# oproti Javě je podpora
async + await pro psaní asynchronního kódu.
Od Javy 5 existuje spousta luxusní podpory pro psaní asynchronního kódu, například http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/FutureTask.html je přesně to citované async + await, navíc je v Javě podpora i pro spouštění v jiných threadech (http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html) nebo třeba speciální implementace pro asynchronní zpracování které nebude ve Swingu blokovat UI: http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html - prostě tvrdit že Java má špatnou podporu pro psaní asynchronního kódu jednoznačně není pravda. Ano, C# má pár detailů které jsou příjemnější než Java, ale podpora asynchronního kódu to není. A hlavně žádná z těch věcí kde je C# lepší než Java mi nevyváží jednu zásadní výhodu Javy: spolehlivě běhá i na serverech bez Windows! I když pokud by zadání bylo dělat UI na Windows (těžkého klienta) tak to je jednoznačně práce pro C# (pokud tedy nepřijdete na to že UI postavené na webovém prohlížeči se serverem běžícím na Linuxu s Javou je lepší).
-
Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi.
Máte naprostou pravdu, jak to, že si toho do dnes nikdo nevšiml? V Javě nikdy nikdo nenaprogramoval žádnou serverovou aplikaci, žádnou desktopovou, žádný web, nic pro cloud, žádnou mobilní aplikaci. Ono vlastně v Javě nebylo naprogramováno nikdy nic. A teprve teď jste to vy odhalil.
-
A nazorny priklad:
Uplna novinka v Jave 8 (rok 2014):
public Optional<Article> getFirstJavaArticle() {
return articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst();
}
A naproti tomu, LINQ v C#, ktery je s nama od roku 2007:
public Article GetFirstJavaArticle()
{
return articles.FirstOrDefault(x => x.Tags.Contains("Java");
}
Co vam pripada prehlednejsi, citelnejsi a jednodussi na nauceni??
Hlavní na první pohled každý ten kód dělá něco jiného. Ten Javovský vezme všechny články, z nich vybere ty, které mají štítek Java, a z nich vybere první. Ten C# kód vezme články, z nich vezme první nebo výchozí, a u něj asi zkontroluje, zda obsahuje štítek Java. Alespoň to tak vypadá.
Jednodušší na naučení je podle mne to, kde se nic učit nemusím, protože správný význam je patrný i bez učení. Uniká my smysl toho, proč bych se měl učit, že FirstOrDefault může mít jako parametr predikát, který nejprve filtruje množinu a pak až vrací první záznam (proč nedělá třeba to, co jsem popsal výše, tedy že by rozhodl, zda první záznam odpovídá predikátu?), a proč bych se měl učit, že kód musím číst střídavě zleva doprava a zprava doleva.
-
Uniká my smysl toho, proč bych se měl učit, že FirstOrDefault může mít jako parametr predikát, který nejprve filtruje množinu a pak až vrací první záznam (proč nedělá třeba to, co jsem popsal výše, tedy že by rozhodl, zda první záznam odpovídá predikátu?), a proč bych se měl učit, že kód musím číst střídavě zleva doprava a zprava doleva.
a co tak si pozriet ako naozaj FirstOrDefault funguje az potom nieco komentovat?
public static TSource FirstOrDefault<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
if (source == null)
{
throw Error.ArgumentNull("source");
}
if (predicate == null)
{
throw Error.ArgumentNull("predicate");
}
foreach (TSource local in source)
{
if (predicate(local))
{
return local;
}
}
return default(TSource);
}
prechadza mnozinu a vrati prvy najdeny. Vobec nefiltruje komplet mnozinu. A dalsia vec, aky by to malo zmysel, keby to porovnava len prvy prvok mnoziny?
-
A nazorny priklad:
Uplna novinka v Jave 8 (rok 2014):
public Optional<Article> getFirstJavaArticle() {
return articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst();
}
A naproti tomu, LINQ v C#, ktery je s nama od roku 2007:
public Article GetFirstJavaArticle()
{
return articles.FirstOrDefault(x => x.Tags.Contains("Java");
}
Co vam pripada prehlednejsi, citelnejsi a jednodussi na nauceni??
Hlavní na první pohled každý ten kód dělá něco jiného. Ten Javovský vezme všechny články, z nich vybere ty, které mají štítek Java, a z nich vybere první. Ten C# kód vezme články, z nich vezme první nebo výchozí, a u něj asi zkontroluje, zda obsahuje štítek Java. Alespoň to tak vypadá.
Jednodušší na naučení je podle mne to, kde se nic učit nemusím, protože správný význam je patrný i bez učení. Uniká my smysl toho, proč bych se měl učit, že FirstOrDefault může mít jako parametr predikát, který nejprve filtruje množinu a pak až vrací první záznam (proč nedělá třeba to, co jsem popsal výše, tedy že by rozhodl, zda první záznam odpovídá predikátu?), a proč bych se měl učit, že kód musím číst střídavě zleva doprava a zprava doleva.
v C# sa to da zapisat aj ako v jave:
articles
.Where(a => a.Tags.Contains("java"))
.First();
Ale zapis:
articles.First(a => a.Tags.Contains("java"));
mi pride prehladnejsi. rozdiel medzi First a FirstOrDefault je v tom ze First ked nenajde prvok tak vyhodi vynimku, FirstOrDefault vrati defaultnu hodnotu (null).
-
Uniká my smysl toho, proč bych se měl učit, že FirstOrDefault může mít jako parametr predikát, který nejprve filtruje množinu a pak až vrací první záznam (proč nedělá třeba to, co jsem popsal výše, tedy že by rozhodl, zda první záznam odpovídá predikátu?), a proč bych se měl učit, že kód musím číst střídavě zleva doprava a zprava doleva.
Nic sa ucit nemusite od toho tu mame predsa intelli sense.
-
K tomu úžasnýmu NETu:
http://myego.cz/item/microsoft-a-jeho-hazeni-klacku-pod-nohy-net-vyvojarum/category/ze-zivota/group/29
Já kdysi ze zvědavosti zkoušel VS, teď nevím jestli 2008 nebo 2010 a takový pomalý, rozežraný a někdy padající moloch aby jeden pohledal. Bez R# to neumí ani věci, které maji Javovská IDE v základu zadarmo (generování kódu, navigace atd.). Děkuji, nechci.
Přidal bych další link
http://www.dotnetportal.cz/blogy/3/Tomas-Herceg/935/Visual-Studio-2010-vs-Visual-Studio-11-Beta (http://www.dotnetportal.cz/blogy/3/Tomas-Herceg/935/Visual-Studio-2010-vs-Visual-Studio-11-Beta)
-
Krom toho obrovskou výhodou C# oproti Javě je podpora
async + await pro psaní asynchronního kódu.
Od Javy 5 existuje spousta luxusní podpory pro psaní asynchronního kódu, například http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/FutureTask.html je přesně to citované async + await
To je omyl, async + await není o nějaké třídě, ale o syntaxi. Jde o přehlednost zápisu.
navíc je v Javě podpora i pro spouštění v jiných threadech (http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html) nebo třeba speciální implementace pro asynchronní zpracování které nebude ve Swingu blokovat UI: http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html
Task (https://msdn.microsoft.com/en-us/library/system.threading.tasks.task%28v=vs.110%29.aspx), ThreadPool (https://msdn.microsoft.com/en-us/library/system.threading.threadpool%28v=vs.110%29.aspx), BackgroundWorker (https://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker%28v=vs.110%29.aspx).
prostě tvrdit že Java má špatnou podporu pro psaní asynchronního kódu jednoznačně není pravda. Ano, C# má pár detailů které jsou příjemnější než Java, ale podpora asynchronního kódu to není.
Většina mainstreamových jazyků má špatnou (např. monády) nebo žádnou podporu pro zápis asynchronního kódu.
A hlavně žádná z těch věcí kde je C# lepší než Java mi nevyváží jednu zásadní výhodu Javy: spolehlivě běhá i na serverech bez Windows!
V současné době je tu Mono a za chvíli tu bude CoreCLR.
-
Mam Visal Studio 2013 a este nikdy mi nespadlo. Visual studio 2010 o ktorom sa pise v uvedenom clanku ani 2012 mi tiez nikdy nespadlo. Aj VS ma par much, ale stabilita to rozhodne nie je. Zato kolega sa stazuje ze mu pada Eclipse. Co sa tyka R# ja som ho zatial nepotreboval ale chapem ze si treba propagovat vlastny produkt (neni JetBrains nahodou ceska firma)?
-
Přidal bych další link ...
podla komentarov je autor asi jediny (mozno este 2-3 v komentaroch), komu takto to VS padalo. Tento clanok nemozno povazovat za relevantny dokaz. 8)
-
(neni JetBrains nahodou ceska firma)?
jop je :)
-
IEnumerable<T> je lazy list, funkce nad nim se daji komponovat jako ve funkcionalnich jazykach. Select je map, SelectMany je mapcat, Where je filter, je tam hromada foldu...
Teoreticky, ale prakticky zbožné přání. Zrovna včera jsem nad tím IEnumerable lazy list chtěl postavit otevřený result set z SQL. Po pár hodinách babrání jsem to vzdal a šel přímo na low-level SQL driver.
Nic sa ucit nemusite od toho tu mame predsa intelli sense.
Za a) intelli sense je hezký, ale hledat v seznamu 100 metod neintuitivní název je peklo, b) kdo má potom ten neintuitivní kód číst? Jedna z naprosto klíčových věcí, které Java přinesla, byla vzdání se kryptografických názvů. A C# nás chce vrátit zpátky? Když dělám code review na C# projektu, tak strávím obvykle několikanásobek času oproti srovnatelné změně na Java projektu.
-
Přidal bych další link
http://www.dotnetportal.cz/blogy/3/Tomas-Herceg/935/Visual-Studio-2010-vs-Visual-Studio-11-Beta (http://www.dotnetportal.cz/blogy/3/Tomas-Herceg/935/Visual-Studio-2010-vs-Visual-Studio-11-Beta)
Nechce se mi ani věřit, že by v dnešní době bylo nutné restartovat systém nebo vývojové prostředí častěji než 1× za měsíc.
-
Java nedosahnete takovy siroky zaber technologii jako se C#. Napr pomoci C# muzete programovat serverove casti (pomoci Mono i na linuxu), desktop (WinForms a excelentni WPF), web (ASP.NET a novy vNext, ktery je multiplatformni, typescript, hodne podobny C#, atd...), cloud Azure, mobilni aplikace (WP, android a IOS pomoci Xamarin) a dalsi.
Jeste doplnim dalsi: XBox, WinRT aplikace (v pripade budoucich Windows 10, ktere budou bezet na uplne vsech platformach (i na RaspberryPI) a pry budou podporovane dozivotne, to ma obrovskou vyhodu), .NET micro framework a vlastni desky (FEZ raptor, FEZ spider, ...).
Co se tyce VS, nemuzete porovnavat verzi 2010 kdyz uz tady je verze 2012, 2013 a za pul roku stabilni verze 2015 a to uz ani nezminuji verzi Community, ktera je zcela zdarma a nema omezeni jako mela edice express.
Co se tyce meho prikladu vzal jsem to tady odsud: http://www.deadcoderising.com/java-8-no-more-loops/ (http://www.deadcoderising.com/java-8-no-more-loops/) podivejte se na dalsi ukazky v jave a prectete si komentare.
Pokud byste se chteli podivat jak zije uvolneny .NET Core v opensource svete: https://github.com/dotnet/corefx (https://github.com/dotnet/corefx)
Radeji ani nezminuji Roslyn, protoze z toho by se java vyvojarum zamotala hlava. Az tento novy compilator s otevrenym API pujde bezne pouzivat, pak .NET bude 20 let napred.
-
Krom toho obrovskou výhodou C# oproti Javě je podpora
async + await pro psaní asynchronního kódu.
Od Javy 5 existuje spousta luxusní podpory pro psaní asynchronního kódu, například http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/FutureTask.html je přesně to citované async + await
To je omyl, async + await není o nějaké třídě, ale o syntaxi. Jde o přehlednost zápisu.
Vetsina Java programatoru co znam ma stejne pouzivani vlaken zakazany. V JEE se to vsechno resi pres "framework". Java dlouho hresila na to, ze byla hrozne dogmanticka:
- nepodporujeme viceradkove literaly - na to jsou resources
- nepodporujeme gepopt => programum se nemaji predavat paramertry - na to jsou properties
- je to objektovy jazyk => vsechno musi byt objekt.
- mame GC => ulolneni vsech prostredku vyresi GC(alespon si to porad dost programatoru mysli)
- RMI neumi volat vzdalene metody trid? => kazda trida musi mit svuj dummy interface
Dneska uz je to preci jenom trochu jinak. Ten jazyk je jednoduchy(i kdyz frameworky jsou slozity) a zvladnou ho i lidi, ktery by s C/C++ meli problemy. Java byla zamyslena jako COBOL pro 21. stoleti a tim taky bude. Kdo se nechce drbat s patchovanim windows a zoufale kopirovat dll-ka mezi systemama, tak zvoli neco co bezi na Unixu/Linuxu a neni to tak narocne na lidske zdroje jako C++.
-
a co tak si pozriet ako naozaj FirstOrDefault funguje az potom nieco komentovat?
A co tak si nejprve přečíst celý komentář a až pak na něj reagovat? Kdybyste si můj komentář přečetl celý, zjistil byste, že vím, co funkce FirstOrDefault dělá – akorát že je ta funkce špatný příklad intuitivnosti jazyka, protože to vede k tomu, že máte kód ve zdrojáku na přeskáčku a hlavně musíte vědět, kdy se ten predikát použije.
Vobec nefiltruje komplet mnozinu.
To ten Javovský kód také nedělá.
A dalsia vec, aky by to malo zmysel, keby to porovnava len prvy prvok mnoziny?
To je jedno.
Jinak teda porovnávat dvě rozsáhlé vývojové platformy podle třech řádků kódu je totální nesmysl. Chtěl jsem jenom poukázat na špatně zvolený příklad, protože ten kód v C# je neintuitivní.
-
- nepodporujeme viceradkove literaly - na to jsou resources
- nepodporujeme gepopt => programum se nemaji predavat paramertry - na to jsou properties
- je to objektovy jazyk => vsechno musi byt objekt.
- mame GC => ulolneni vsech prostredku vyresi GC(alespon si to porad dost programatoru mysli)
- RMI neumi volat vzdalene metody trid? => kazda trida musi mit svuj dummy interface
To jsou všechno vlastnosti, které mají podpořit správný styl objektového programování. Účelem není házet vývojářům klacky pod nohy, ale zpřehlednit kód, tedy čtenářům snížit počet WTF za hodinu.
-
protože ten kód v C# je neintuitivní.
intuitivnejsi, ako ten zapis v Jave. Ale bavit sa o takychto kktinach to je tak rootovske :)
-
intuitivnejsi, ako ten zapis v Jave. Ale bavit sa o takychto kktinach to je tak rootovske :)
„Intuitivní“ pro mne opravdu neznamená „musím vědět, co přesně ta funkce dělá, a program musím číst chvilku zepředu dozadu a chvilku opačně“. Intuitivní je, když funkce FirstOrDefault vrátí první záznam, nebo výchozí hodnotu, pokud je seznam prázdný. Jenže ta funkce s predikátem dělá dvě věci – jednak filtruje, a pak vybírá ten první záznam. A to, že se ten predikát používá zrovna pro filtrování, to musíte vědět – z definice té funkce to nijak nepoznáte. Ona by se ta funkce správně musela jmenovat FilterAndGetFirstOrDefault, ale pak už by bylo jasné, že ta funkce nedělá jen jednu věc.
-
... Co sa tyka R# ja som ho zatial nepotreboval ale chapem ze si treba propagovat vlastny produkt (neni JetBrains nahodou ceska firma)?
Nepracuji v ani pro tuto firmu. Fakta zustavaji, dokud jsem nezkusil R# (https://www.jetbrains.com/resharper/features/), tak jsem netusil, ze VS muze byt jeste lepsi. Pak jsem zkusil IntelliJ IDEA a u toho zustal, snazim se jej pouzivat na vsechno na co muzu. Jak jsem psal vyse, je to nekolik let zpet, je mozne ze Microsoft vse dohnal. Drive ve VS nebylo type-aware naseptavani, v jinych Java IDE mi casto chybela i tak zakladani funkce, jako naseptavani podle camel nebo casti (ne nutne zacatku) identifikatoru (coz doufam uz vsude davno napravili).
protože ten kód v C# je neintuitivní.
intuitivnejsi, ako ten zapis v Jave. Ale bavit sa o takychto kktinach to je tak rootovske :)
Take mi neprijde spojení first s filtrovanim (a s default) semancticky spravne. Navic pokud jedete na co nejmene kodu, tak proc pracujete v C#? Proc jste nezkusil F# nebo jiny jazyk z siroke rodiny .NET?
-
myslim, ze aj priemerne inteligentny clovek pochopi, ze: FirstOrDefault(x => x.Name == "nieco") robi nasledovne: daj mi prvok, ktory vyhovuje kriteriu Name == "nieco". Nic intuitivnejsie nemoze byt. Nepotrebujem ani FilterAndGetFirstOrDefault.
Potom su asi C# vyvojari na vyssej inteligentnej urovni nez Javisti, pretoze my tomu chapeme :P a kto ma s tym problem, tak nech si spravi vlastnu extension metodu a nazve si ju trebars aj kokot 8)
-
Ono celkove veci nad kolekcemi (hlavne ty z funkcionalniho sveta) jsou v C# divne a vymykaji se beznym standardum. Napr. select misto (IMO podstatne intuitivnejsiho) map. U select bych cekal, ze dela filtrovani, ne mapovani...
-
Radeji ani nezminuji Roslyn, protoze z toho by se java vyvojarum zamotala hlava. Az tento novy compilator s otevrenym API pujde bezne pouzivat, pak .NET bude 20 let napred.
To uz snad bude funkcni projekt Graal, aby se nam ta hlava netocila az tak moc:).
-
Ono celkove veci nad kolekcemi (hlavne ty z funkcionalniho sveta) jsou v C# divne a vymykaji se beznym standardum. Napr. select misto (IMO podstatne intuitivnejsiho) map. U select bych cekal, ze dela filtrovani, ne mapovani...
Select a filtrovanie? A to z akého dovodu?
Ze aj v SQL v definujes stlpce kotre chces dostat ako výsledok?
Ze aj v SQL musis pridat zazracne slovicko WHERE ktore filtruje?
SELECT nema preco znamenat filter SELECT znamena vybrat, a ked uz toto ri robi problemy....
-
preco vydanie kompilatora ma posunut .net o 20 rokov voci ... comu?
-
konkretne Select znamena projekciu. neviem o akom mapovani noef rozprava. vidiet, ze casto tu ti ludia pisu o niecom, comu ani samu nerozumeju a len sa snazia za kazdu cenu zdiskreditovat C#. asi sa nevedia zmierit s tym, ze je lepsie ako java.
-
konkretne Select znamena projekciu. neviem o akom mapovani noef rozprava. vidiet, ze casto tu ti ludia pisu o niecom, comu ani samu nerozumeju a len sa snazia za kazdu cenu zdiskreditovat C#. asi sa nevedia zmierit s tym, ze je lepsie ako java.
Aha, takže Select nedělá selekci, ale projekci. Jak výstižné!
-
Aha, takže Select nedělá selekci, ale projekci. Jak výstižné!
Select je z anglictiny, a neznamena filtrovat ale vybrat.
Select vravi ake atributy chces vratit ale nie podla akých podmienok.
Tak je to vsade... ale len asi u teba je to ine, nuz....
-
to je ako bavit sa o tom, ci je lepsi %s alebo %s. Rychlost, stabilita a kvalita systemu hovori ZA %s. Toto %s chyba, no ale to si ludia nikdy nepripustia.
+1
-
To jsou všechno vlastnosti, které mají podpořit správný styl objektového programování. Účelem není házet vývojářům klacky pod nohy, ale zpřehlednit kód, tedy čtenářům snížit počet WTF za hodinu.
No jo, zvlášť ty escapované regexy jsou ve srovnání s verbatim string literals mimořádně přehledné :)
-
konkretne Select znamena projekciu.
Select prekladame jako vybrat. Proc teda meni prvky? Proc se chova jako map z ostatnich jazyku? Opravdu intuitivni. Mozna tak leda pro lidi, co nikdy nevideli funkcionalni programovani nebo jiny jazyk krom C#.
neviem o akom mapovani noef rozprava. vidiet, ze casto tu ti ludia pisu o niecom, comu ani samu nerozumeju a len sa snazia za kazdu cenu zdiskreditovat C#. asi sa nevedia zmierit s tym, ze je lepsie ako java.
Problem je, ze to vypada, ze tomu nerozumite vy. Pusobi to, ze jste nikdy nezkusil nic krome (SQL ci) C#, ktery pouziva ne uplne logicke pojmenovani standardnich metod u kolekci, asi aby ulehcil uceni pro lidi se znalostmi SQL. Bohuzel to znamena, ze lide se zkusenostmi z jinych jazyku (napr. Python, PHP, Scala, Java, JavaScript a asi mnoho dalsich) se musi preucovat na unikatni a ne prilis logicky pristup C#.
C# jako jazyk se mi pomerne libi, je hodne pokrokovy (narozdil od Javy). Kdyby ho MS otevrel driv, mozna ani neprejdu do JVM sveta. Nesnazim se za kazdou cenu C# zdiskreditovat, pouze poukazuji na chyby, stejne jako se v tomto vlaknu deje u Javy.
Aha, takže Select nedělá selekci, ale projekci. Jak výstižné!
Presne na to jsem narazel.
Select je z anglictiny, a neznamena filtrovat ale vybrat.
Select vravi ake atributy chces vratit ale nie podla akých podmienok.
Tak je to vsade... ale len asi u teba je to ine, nuz....
"Vybrat" ale neznamena "mapovat", "vybrat" znamena vzit prvky splnujici urcite kriterium = "filtrovat". Nechapu, jak z "vybrat" dostanete "vratit upravene prvky" = "aplikovat funkci" = "mapovat"...
-
Aha, takže Select nedělá selekci, ale projekci. Jak výstižné!
Select je z anglictiny, a neznamena filtrovat ale vybrat.
Select vravi ake atributy chces vratit ale nie podla akých podmienok.
Tak je to vsade... ale len asi u teba je to ine, nuz....
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.
-
Projection means choosing which columns (or expressions) the query shall return.
Selection means which rows are to be returned.
kde je spominane mapovanie?
-
asi sa nevedia zmierit s tym, ze je lepsie ako java.
To jsem nikdy netvrdil. Java je ukecanejsi a prijima pomaleji zmeny, na druhou stranu je stabilnejsi (jako jazyk). "Muj" jazyk je Scala a samzrejme i ta ma svoje chyby (kupr. lepsi generika nez Javovska, ale stale nema na .NETi, coz je dano omezenimi JVM), ale jak jsem psal vyse, ve srovnani s C# je mnohem strucnejsi a vystiznejsi. Jak uvedl Kit, v relacnich db je to bezne, naopak u kolekci je to silne netypicke a pusobi to, ze MS se snazi za kazdou cenu razit svoji "lepsi" cestu.
Projection means choosing which columns (or expressions) the query shall return.
Selection means which rows are to be returned.
kde je spominane mapovanie?
Opet spatny kontext, nalistujte si tam obecne kolekce, ne databaze.
-
v relacnich db je to bezne, naopak u kolekci je to silne netypicke
LINQ se snaží být univerzální, stejný kód lze používat pro kolekce i pro relační DB.
-
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
alebo vybrat vsetky stlpce
SELECT *
FROM tabulka
Kde to MS nerespektuje? Presne takto sa to chova aj v MS
-
https://en.wikipedia.org/wiki/Map_%28higher-order_function%29
In many programming languages, map is the name of a higher-order function that applies a given function to each element of a list, returning a list of results.
Kdyz nalistujeme nize (https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison), tak vidime, ze opravdu jen malo jazyku nepouziva klicove slovo "map". Z siroce pouzivanych jazyku jsem si vsiml jen C++ s "transform", ktere je ale na rozdil od "select" vystizne a obtizne zamenitelne.
v relacnich db je to bezne, naopak u kolekci je to silne netypicke
LINQ se snaží být univerzální, stejný kód lze používat pro kolekce i pro relační DB.
Ja chapu motivaci za tou volbou. Jen si myslim, ze konecne rozhodnuti bylo spatne. Pokud totiz mate zakladni rozhled mezi programovacimi jazyky, tak pouzivat terminologii relacni DB u kolekci je snad pouze v MS svete.
-
To jsou všechno vlastnosti, které mají podpořit správný styl objektového programování. Účelem není házet vývojářům klacky pod nohy, ale zpřehlednit kód, tedy čtenářům snížit počet WTF za hodinu.
nojo, cesta do pekla je dlazdena dobrymi umysly... :-)
-
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í.
-
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.
-
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 + "]")
-
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 (http://blogs.msdn.com/b/charlie/archive/2008/02/28/link-to-everything-a-list-of-linq-providers.aspx).
Kolekce jsou pouze jeden specifický případ, tudíž nevidím důvod, proč se přizpůsobit zrovna jemu.
-
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.
-
nechaj ho. on videl asi c# len vo vyklade v knihkupectve :D
-
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?
-
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)?
-
nechaj ho. on videl asi c# len vo vyklade v knihkupectve :D
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.
-
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 (https://github.com/ReactiveX/RxJava).
Pro Scalu existuje scalaz-stream (https://github.com/scalaz/scalaz-stream) - není to však knihovna z rodiny Rx, ale z rodiny Machines.
-
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
-
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 ;D.
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.
-
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.
-
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...
-
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.
-
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...
Parametr Selectu má typ Expression<Func<TSource, TResult>>, což není typ funkce TSource -> TResult, ale typ jejího AST. Když se pak dělá dotaz do databáze, tak se vezme tento AST a přeloží se do SQL, když se dělá dotaz jinam, tak se to přeloží do příslušného dotazovacího jazyka. Pokud se překlad nepodaří (třeba Compose), je vyhozena výjimka.
U kolekcí se překlad podaří vždy, protože tam se ten AST jen kompiluje do IL kódu. Nicméně u některých dotazovacích jazyků to nemusí jít.
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.
Když se to podaří přeložit, tak se ty výsledky mohou lišit pořadím - např. se oboje přeloží na trochu jiný dotaz a služba, co vrací výsledky, to vrátí v jiném pořadí (tohle by mohlo nastat i u někerých kolekcí - např. u hašovacích tabulek, když to vracíte v pořadí, v němž to je uloženo v té tabulce).
-
Nebylo by teda cistsi reseni vracet pri dotazu na DB (pri nepouziti razeni) neusporadanou mnozinu (co se divam na SO, tak v C# to bude asi HashSet)? Takto to pusobi, ze ta abstrakce "DB = list" se snazi spojit dva neslucitelne svety.
Osobne si myslim, ze pro nizkourovnovy pristup k DB staci dobre DSL a neni treba spojovat pristup do DB s pristupem ke kolekci na urovni jazyka i standardni knihovny. Co jsem rychle vygooglil, tak squeryl pusobi pouzitelne:
def songsInPlaylistOrder =
from(playlistElements, songs)((ple, s) =>
where(ple.playlistId === id and ple.songId === s.id)
select(s)
orderBy(ple.songNumber asc)
)
-
chlapi, co tak vymysliet jazyk podla vasich predstav, konvencii a preslavit ho? radsej ako vypisovat spravy na roote 8)
-
naco novy jazyk ked su tu mnohe vyhovujuce
-
naco novy jazyk ked su tu mnohe vyhovujuce
Například?
-
naco novy jazyk ked su tu mnohe vyhovujuce
Například?
Například Java.
-
naco novy jazyk ked su tu mnohe vyhovujuce
Například?
Například Java.
Spise ten C#
-
alebo python
-
naco novy jazyk ked su tu mnohe vyhovujuce
Například?
Například Java.
₊1
-
naco novy jazyk ked su tu mnohe vyhovujuce
Například?
Například Java.
ak je pre vas java vyhovujuci jazyk tak potom poznate asi len javu alebo mozno este daco horsie (PHP, Visual Basic)
-
Můžeš napsat nějaký lepší jazyk?
-
Můžeš napsat nějaký lepší jazyk?
Záleží, v čem ten jazyk má být lepší. Výhodou Javy je rozšířenost, ale kdybychom hodnotili vyjadřovací schopnosti jazyka nebo jednoduchost, tak tam to bude horší.
Například zmíněná Scala má lepší vyjadřovací schopnosti než Java. Na druhou stranu je hůře specifikovaná, složitější a její kompilátor obsahuje mnoho chyb.
Například Standard ML 97 je jednodušší než Java a má přesnější specifikaci (dokonce existují i mechanizované specifikace). Na druhou stranu není příliš rozšířená.
-
A co fak Pascal??? ;D
-
pascal bol dobry na vyucbu programovania ale pri oop uz vidiet ako to tam bolo prilepene dodatocne
java zacina plesniviet tym ze ten skok na funkcionalko trochu premeskali a finty zo scaly ako traity asi tak skoro nebudu. ostatne kritiky smerom k properties su nepodstatne
na druhej strane skala je c++ java sveta. silne, huste, na zaciatku necitatelne (zhluky symbolov znamenaju ze autor pisal minutu a citatel parsuje tri minuty).
skoda ze groovy nedokaze vyletiet
python je tiez dobry ale tiez ma veci ktore su syntakticky wtf (this v metodach)
ak je pre vas java vyhovujuci jazyk tak potom poznate asi len javu alebo mozno este daco horsie (PHP, Visual Basic)
a vy pan satan co poznate?
Standard ML 97
si musim pozriet
-
Vidim, ze si tu nekdo dela srandu z Pascalu. Ale on i ted jeste "zije", napr. velmi oblibeny Total Commander (drive Windows Commander) je napsan ve Free Pascalu. A myslim ze i dost veci v Delphi se jeste udrzuje pri zivote.
U Groovy byl velky problem s rychlosti, takze jazyk ziskal negativni povedomi, ktere se spatne meni. Od zavedeni podpory staticke kompilace to tusim bylo celkem pouzitelne.
S Pythonem si zrovna trochu hraju (uroven zacatecnik), dost veci mi ale prijde strasne ukecanych a neintuitivnich. Funkcionalni ficury jako prilis dlouhy zapis lambdy nebo map ala globalni funkce se mi moc nelibi (volani nejdou hezky retezit).
-
Je dobre, ze groovy sa nepresadilo. Aj ja groovy obcas pouzijem, ale skor z donutenia a vzdy vo mne ostane ten dojem, ze to vobec nemalo vyhodu. Co by som v jave ocenil su tie properties - proste priradovat do membrov a mat moznost si dodefinovat get/set.
Inak si myslim, ze clr je lepsi ako jvm (ale je to asi ako porovnavat audi a bmw..) a ked potrebujem nejaku "forms" apku, tak radsej si to naklikam v .nete. Navyse je to tak nejako lepsie integrovane s OS a tie aplikacie lepsie zapadaju.
Ked si porovname ficurky, tak c# je lepsi jazyk, ale to nie je vzdy lepsie a podstatne. Napr ked robim nieco multiplatformove, tak prenositelnost javy skoro vzdy fungovala, more usetreneho casu... Takze cela tato diskusia je bezpredmetna, ako ostatne vsetky podobne..
ps: total commander je myslim v c++ builderi, ale co sa pascalu tyka, skor by som skusil ADU
-
hm, mozno delphi, ale aj tak je to offtopic
-
total commander bol v delphi teraz je v lazaruse.
groovy ma prave kilo syntaktickeho cukru: ma "def" namiesto typu premennych (prakticky c#ovske var), ma closures uz od davna, ma properties, ktore java nikdy mat nebude, vsetko je tam objekt, a dalsie ficury ako vynechavanie zatvoriek pri jednom parametri, neskor dodali volitelne staticke typovanie .. a tiez pomocne skriptovacie metody takze si mozete otvorit subor a precitat z neho riadky na tri riadky.
presne to co sa tu hadame ze c# ma a java nema
-
teda az na performance ktory ide trochu do kopru a neviem ci uz vyuzili invokedynamic na zrychlenie dynamickych veci. integracia s lambdami v jave 8 bude v neurcitej buducnosti
-
presne to co sa tu hadame ze c# ma a java nema
Spíš se dohadujeme, zda je to dobře nebo špatně.
-
Groovy je vynikajuci jazyk na pisanie vlastneho DSL. Groovy je strasne flexibilne a daju sa v tom pisat veci o ktorych nemate ani potuchy, ale na druhej strasne je to jazyk neskutocne nachylny na prasaciny. V Groovy sa da tak prasit ze to musite lustit obcas aj sami po sebe - to nie je slabost programatora - ta vyjadrovacia schopnost Groovy si paradoxne berie svoju dan v podobe horsej citatelnosti.
V Groovy sa da pisat aj beztypovo a berie sa to ako jeho vyhoda, ale osobne sa mi v tom beztypovo pise strasne zle. Zaroven to kvoli beztypovosti nema taku dobru podporu v IDE. Co sa tyka typov tak to programujete "naslepo" a sami si musite v hlave strazit aky typ to ma a co na tom mozete zavolat ... je to zvlastny jazyk a aj ja som rad ze sa nepresadil viac, pretoze pisat denne v Groovy by som vnimal ako za trest. Avsak co sa tyka tych DSL a toho, ze si to mozete ohnut podla seba, je malo jazykov, ktore tomu mozu konkurovat.
-
S tim prasenim na tom Scala bude podobne. IMO prasit se da vsude, akorat v hodne vystiznych jazycich bude vyssi pomer prasecin na znak, coz je ale dano pouze tim, ze tyto jazyky jsou vystizne (i dobry kod bude kratsi a strucnejsi). Narozdil od Groovy* je ale Scala staticky typovana a podpora v IDE je slusna (Eclipse a predevsim IntelliJ IDEA).
Scala ma mnohem pokrocilejsi type inference nez C#, nekde drive v tomto vlaknu jsem i uvadel priklad (v porovnani s Groovy netusim). Uz ted jsou v Jave nejake naznaky zestrucneni, tusim vynechavani typu u generik pri vytvareni instance? Mozna se dockame i trochu pokrocilejsi verze.
* Jsem si celkem jisty, ze Groovy podporuje staticke typy uz nejaky cas (clanek (http://www.h-online.com/open/news/item/Groovy-2-0-introduces-static-type-checking-and-compiling-1628119.html) z 2012). V nekterych pripadech (http://java-performance.info/static-code-compilation-groovy-2-0/) neni prakticky zadne zpomaleni oproti Jave.
-
je ale Scala staticky typovana a podpora v IDE je slusna (Eclipse a predevsim IntelliJ IDEA).
Slušná pro jednoduchý kód. Bohužel se obě IDE chovají jinak než kompilátor - např. s následujícím kódem ještě nedávno ani jedno IDE pořádně nefungovalo Record and discriminated union type literals and concise value construction in shapeless-2.1.0-SNAPSHOT (https://gist.github.com/milessabin/aeecb68caba18f3bb3c0) nicméně kód šlo normálně přeložit.
-
Miluju ty nové bastly, které umožňují všechno, ale nikdo v tom nic nedělá, protože to nejde. To stejné Python. Ten uměl všechny cool věci dávno, ale na velké věci nepoužitelný. Dodnes nechápu, proč si třeba vybrat Python před Javou nebo C#.
-
sadsa to globálně zhrnul docela hezky, já to vezmu kus po kusu:
groovy ma prave kilo syntaktickeho cukru:
ma "def" namiesto typu premennych (prakticky c#ovske var),
Na houby, vede k nečitelnosti kódu. I když píšu v C#, var naprosto zásadně nepoužívám, stejně jako nevyužívám možnost nedeklarovat typ u lambda parametrů, ať už v Java nebo C#.
ma closures uz od davna,
Dneska má closures každý, irelevantní. Perl měl closures před 25 lety, je kvůli tomu lepší? (mimochodem nesrovnatelně lepší, než mají dnes populární ruby, php, python, u gradle bohužel neznám)
ma properties, ktore java nikdy mat nebude, vsetko je tam objekt, a dalsie ficury ako
properties jsou s otazníkem. Osobně radši vidím v kódu volání funkce (getter/setter), bo mi to dává jasnější představu, že se na pozadí může něco dít. Řekl bych, že i to je důvod, proč v Java stále nejsou.
vynechavanie zatvoriek pri jednom parametri, neskor dodali volitelne staticke typovanie ..
Za prvé nekonsistence, za druhé vede k hůře čitelnému kódu. Stejně jako nechápu například nepovinný středník u JavaScript.
a tiez pomocne skriptovacie metody takze si mozete otvorit subor a precitat z neho riadky na tri riadky.
FileUtils.readLines() v Java, C# má něco podobného taky, Perl taky, Php taky, ostatní jazyky předpokládám na tom budou podobně.
... obecně, už to dříve bylo napsáno, ale zopakuju - fakt, že můžu někde napsat o znak nebo o řádek míň, opravdu neznamená, že je daný jazyk lepší, často je to spíš naopak, protože tím často trpí čitelnost!
-
...Slušná pro jednoduchý kód. Bohužel se obě IDE chovají jinak než kompilátor...
Nemohu nez nesouhlasit. Nevyuzivam nejake moc pokrocile veci, ale uz se spray json jsem narazil. "Vyresil" jsem to presunutim problemoveho kodu do samostanych traitu v jinem souboru.
Ale tohle vse myslim souvisi s makry kompilatoru, coz zase v jinych jazycich casto vubec neni. Pomoci nich mohou vznikat knihovny, ktere v podstate spolupracuji s kompilatorem, takze napr. mohou omezit redundantni kod.
Miluju ty nové bastly, které umožňují všechno, ale nikdo v tom nic nedělá, protože to nejde. To stejné Python. Ten uměl všechny cool věci dávno, ale na velké věci nepoužitelný. Dodnes nechápu, proč si třeba vybrat Python před Javou nebo C#.
Pokud mluvite o Scale, tak moc nova neni 2003 - jen o 3 roky mladsi nez C#. A i velke projekty (i pres vyse zminene problemy) se bezne pisi ve Scale. Napr. Hootsuite (https://typesafe.com/blog/hootsuite-success-story-how-hootsuite-modernized-its-url-shortener) prechodem z PHP na Scalu (Akka a Play) usetril naklady za provoz 80% serveru. Mam pocit, ze Twitter se Scalou take neco delal, ale nepamatuji si detaily.
Z tech par zbastlenych skriptu v Pythonu to na me take pusobi, ze je spise na mensi veci. A prestoze funkcionalni ficury ma, tak jejich pouziti se mi casto zda dost neohrabane.
... obecně, už to dříve bylo napsáno, ale zopakuju - fakt, že můžu někde napsat o znak nebo o řádek míň, opravdu neznamená, že je daný jazyk lepší, často je to spíš naopak, protože tím často trpí čitelnost!
Mit ale stale se opakujici radky kodu, ktere nejsou vyznamove taky, k nicemu neni. Kupr. trivialni gettery/settery v Jave by nemusely byt na tolik radku.
public int getFoo(){
return foo;
}
// vs
def foo = _fooZadnou pridanou hodnotu v Java verzi nepozoruji.
Podobne jako bylo drive otresne prochazeni poli/mnozin - nekolik vnorenych cyklu, treba na deset radek (pochopitelne polovina jsou zavorky a tretina trivialni iterace nad kolekci/polem). Stejne tak jako nutnost uvadet typ, klidne na pul radku, u lokalnich promennych na miste, kde je rovnou instancujeme - tj. redundance, typ nalevo i napravo zavorky, zadnout informaci ani citelnost navic to neprinasi (metody ve Scale se doporucuji delat velmi kratke, idealne par radku).
-
Mit ale stale se opakujici radky kodu, ktere nejsou vyznamove taky, k nicemu neni. Kupr. trivialni gettery/settery v Jave by nemusely byt na tolik radku.
public int getFoo(){
return foo;
}
// vs
def foo = _fooZadnou pridanou hodnotu v Java verzi nepozoruji.
Tak ty triviální gettery/settery vůbec nedělej a místo toho přímo používej privátní atributy objektu.
-
Hosi serte nato, vieme, ze C# je lepsi a Java mu urcite nerobi konkurenta. Tak radsej si uzite pokojny nedelny obed a zmierte sa s tym 8)
-
Proto se v Javě dělají největší projekty a dostaneš tam nejvíc peněz? Dej si oběd, ale kdybys dělal v Javě, mohl být třikrát dražší ;)
-
najviac penazi? HAHAHA. Platovo je to rovnake ;) A podla ponuk, ked som si hladal pracu, tak bolo viacej .NET/C# nez JAVA. No hold, dnes uz javu "ovlada" aj opica.
-
Podle mě jen nevíš, kolik se dostává za Javu. Ti nabízeli nějaké drobné, protože viděli, že děláš i C#.
-
Mit ale stale se opakujici radky kodu, ktere nejsou vyznamove taky, k nicemu neni. Kupr. trivialni gettery/settery v Jave by nemusely byt na tolik radku.
public int getFoo(){
return foo;
}
// vs
def foo = _fooZadnou pridanou hodnotu v Java verzi nepozoruji.
Nemusíš je psát ručně, použij pro generování anotace: http://projectlombok.org/features/GetterSetter.html :
class X
{
@Getter @Setter
private int foo;
}
Pro jednoduché datové objekty to plně stačí, pro složité situace se musí napsat metoda tak jako tak. Pak se bavíme opět o konsistenci, viz například:
entityManager.createQuery("SELECT p FROM Person p WHERE p.name = :name")
.setParameter("name", "Whata")
.setMaxResults(10)
.getResultList();
Zatímco v jazyku, který polovinu věcí řeší přes properties a polovinu přes setters, bude kód vypadat jako kočkopes.
-
Podle mě jen nevíš, kolik se dostává za Javu. Ti nabízeli nějaké drobné, protože viděli, že děláš i C#.
neopisuj nam tvoju situaciu :)
-
Takže 120 tisíc je u C# také běžné?
-
Je to bezne, bez problemov:
http://www.titans.sk/sk/it-freelancers/pracovna-ponuka/?nazov-pracovnej-ponuky=net-programator-150213A (http://www.titans.sk/sk/it-freelancers/pracovna-ponuka/?nazov-pracovnej-ponuky=net-programator-150213A)
Java
http://www.titans.sk/sk/it-freelancers/pracovna-ponuka/?nazov-pracovnej-ponuky=integracny-java-programator-141217A (http://www.titans.sk/sk/it-freelancers/pracovna-ponuka/?nazov-pracovnej-ponuky=integracny-java-programator-141217A)
Su na tom podobne ;)
urcite 120 000kc nedostanes ako zamestnanec, a samozrejme zalezi aj od lokality. cize bolo by odveci zrovnavat napr. Vieden a Bratislavu.
-
Lombok jsem kdysi davno zkousel pri vyvoji modu pro Minecraft. Ale bylo s tim hromada problemu - pri MC modovani (Forge/FML + MCP) se totiz hodne upravuji vysledne zkompilovane tridy (jak staticky tak za behu) a nektere nastroje s tim mely problemy. Take nutnost pluginu do IDE pro vyuzivani knihovny neni idealni. Navic je to stale knihovna, neni to soucast jazyka - musi se distribuovat s vyslednou aplikaci. Co ctu, tak to pouziva pri kompilaci nejake hacky a funguje to jen na specifickem kompilatoru Javy...
-
Lombok nebrat. Za ty starosti to nestoji (trace skrz kod pri debugovani...) a vetsina veci uz je stejne poresena JDK8.
Psat acessory rucne neni potreba, zvlada to generovat IDE (a pak je srolovat, takze nezaclani ve vyhledu), nebo jde pouzit groovy... Trocha syntaktickeho cukru, ktery by tohle resil, by nebyla od veci, ale da se prezit i bez nej.
-
Psat acessory rucne neni potreba, zvlada to generovat IDE.
Psát accessory není vůbec potřeba. Stačí umět používat privátní atributy.
-
@Kit +1 hold bohužiaľ veľa ľudí tie chyby, ktoré píšu a robia denno denne nevidí a ani nemá záujem sa naučiť ako správne písať OOP kód a potom tým trpia celé projekty a ľudia sa čudujú, prečo je ten program samý bug. Všetko so všetkým súvisí
-
Psat acessory rucne neni potreba, zvlada to generovat IDE.
Psát accessory není vůbec potřeba. Stačí umět používat privátní atributy.
Tak urcite.
-
o accessoroch a kitovi bola debata vedla. ani po 4 stranach nevypadol kloudny priklad co tym ma na mysli
je tu krasny paradox debaty. kym javaci vidia priestor aj inde od c#akov (jurp...) alternativy nevypadli. moze to byt tym ze c# je najlepsi jazyk lebo iny nepoznaju
Co ctu, tak to pouziva pri kompilaci nejake hacky a funguje to jen na specifickem kompilatoru Javy...
ono to vygeneruje bajtkod ktory je identicky ako keby tam vyvojar nadrbal gettery a settery rucne. o specifickom kompilatore neviem (experimentalne sme isli nad normalnym sedmickovym oracle javac, islo to, ale opustili sme to s projektom).
je to vsak o tom ze je tam ten medzikompilacny krok ( unas maven)
-
Psat acessory rucne neni potreba, zvlada to generovat IDE.
Psát accessory není vůbec potřeba. Stačí umět používat privátní atributy.
To funguje jak presne? Napr. vystup z Twitter API, to jako dostanu objekt tweet s privatnimi fieldy a budu s nim delat co?
Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.
public class Foo {
private final int x, y;
private final String name;
public Foo(final int x, final int y, final String name){
this.x = x;
this.y = y;
this.name = name;
}
public int getX(){
return x;
}
public int getY(){
return y;
}
public String getName(){
return name;
}
}
Pak jsem nasel jeste jednu moznost, nevim jestli se pouziva (pripomina closures).
public interface Foo2 {
int getX();
int getY();
String getName();
}
public class Foo2Creator {
public static Foo2 create(final int x, final int y, final String name){
return new Foo2(){
public int getX(){
return x;
}
public int getY(){
return y;
}
public String getName(){
return name;
}
};
}
}Neprijde mi o moc lepsi.
Posledni co me napada je uplne vypustit gettery a prejit na verejne final fieldy. Co ctu, tak to ale moc Java-like neni (a u verejnych API uz vubec ne).
Priklad reseni ve Scale:
case class Foo3(x: Int, y: Int, name: String)Krome strucnosti dostanu navic oproti Jave porovnani, hash, extraktor (coz ale v Java svete asi moc nepouziju) a predevsim copy metodu.
Samozrejme je vice nez pravdepodobne, ze existuje nejaky lepsi pristup, precejen se Javou (ani Scalou) nezivim.
-
o accessoroch a kitovi bola debata vedla. ani po 4 stranach nevypadol kloudny priklad co tym ma na mysli
Ono to není tak jednoduché zarytým C#ařům vysvětlit, co je to OOP :)
-
Jestli neni problem spis v tom, co vysvetlujes...
-
Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.
... CODE ...
Neprijde mi o moc lepsi.
V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.
Posledni co me napada je uplne vypustit gettery a prejit na verejne final fieldy. Co ctu, tak to ale moc Java-like neni (a u verejnych API uz vubec ne).
To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?
-
Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.
... CODE ...
Neprijde mi o moc lepsi.
V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.
A a data si budes strkat do map?
-
Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.
... CODE ...
Neprijde mi o moc lepsi.
V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.
Nesou data, to je podstata immutable trid (https://en.wikipedia.org/wiki/Immutable_object). Vzhledem k tomu, jak Java pridava funkcionalni rysy, cekal bych, ze pujdou i k necemu vyuzivat.
Posledni co me napada je uplne vypustit gettery a prejit na verejne final fieldy. Co ctu, tak to ale moc Java-like neni (a u verejnych API uz vubec ne).
To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?
U verejneho API? Ehm, to jako vratim tweet instanci s privatnimi fieldy, at si to klientska aplikace reflexi precte? Asi se nechapeme.
-
V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.
Nesou data, to je podstata immutable trid (https://en.wikipedia.org/wiki/Immutable_object). Vzhledem k tomu, jak Java pridava funkcionalni rysy, cekal bych, ze pujdou i k necemu vyuzivat.
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?
U verejneho API? Ehm, to jako vratim tweet instanci s privatnimi fieldy, at si to klientska aplikace reflexi precte? Asi se nechapeme.
Proč? Klient přece nemá co hrabat na atributy objektu. Má být zapouzřený.
-
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
Ty jsi zase nekde neco cetl, co? Asi jako kdyz jsi precetl neco o TDD a na zaklade toho "zjistil", ze nepotrebujes debugger...
-
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
A kdyz taky nesou nejakou dalsi logiku? (A ani se nesnaz vytahnout single responsibility principle)
-
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
Ty jsi zase nekde neco cetl, co? Asi jako kdyz jsi precetl neco o TDD a na zaklade toho "zjistil", ze nepotrebujes debugger...
Máš pravdu, ten debugger opravdu nepotřebuji.
-
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
A kdyz taky nesou nejakou dalsi logiku? (A ani se nesnaz vytahnout single responsibility principle)
Pokud nesou logiku, tak nepotřebuji accessory.
-
Kite, kite. Nenapadlo te, ze se ti muze hodit oboji? Trebas mit v objektu Workflow datum konce, k nemu getter a kousinek logiky v metode isFinished()?
-
Máš pravdu, ten debugger opravdu nepotřebuji.
jen tak ze zvedavosti - delal jsi nekde nejaky vyvoj? Jako doopravdy? Za penize, na skutecnem projektu, co dela neco, co nekdo jiny chce? Co ma netrivialni mnozstvi kodu?
-
Máš pravdu, ten debugger opravdu nepotřebuji.
jen tak ze zvedavosti - delal jsi nekde nejaky vyvoj? Jako doopravdy? Za penize, na skutecnem projektu, co dela neco, co nekdo jiny chce? Co ma netrivialni mnozstvi kodu?
Dělal a dělám. Bez testů to prostě nejde. Bez debuggeru však v pohodě. V assembleru totiž už nedělám.
-
Podla mna nerobi. Este som nevidel niekoho alebo nejaku firmu robit projekty vo VIMe, ako sa nam pochvalil Kit, ze robi :)
-
Máš pravdu, ten debugger opravdu nepotřebuji.
jen tak ze zvedavosti - delal jsi nekde nejaky vyvoj? Jako doopravdy? Za penize, na skutecnem projektu, co dela neco, co nekdo jiny chce? Co ma netrivialni mnozstvi kodu?
Dělal a dělám. Bez testů to prostě nejde. Bez debuggeru však v pohodě. V assembleru totiž už nedělám.
Tvuj problem je, ze nechapes, ze ty veci se nevylucuji ale doplnuji...
(Jinak to samozrejme jde bez obojiho, jen je to pak strasny ojeb.)
-
Kite, kite. Nenapadlo te, ze se ti muze hodit oboji? Trebas mit v objektu Workflow datum konce, k nemu getter a kousinek logiky v metode isFinished()?
A to je takový problém dát metodu isFinished() do toho objektu třídy Workflow?
Co to plácám. Stačí přece implementovat metodu notify() a ta už si v tom objektu třídy Workflow poradí i sama. A nechoď na mne se SRPem.
-
Jo, jenomze jak tam das to isFinished, tak najednou mas neco, co nese data, ma acessor a jeste logiku. Bez dat to nepujde, logika i acessor tam davaji smysl.
-
V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.
Nesou data, to je podstata immutable trid (https://en.wikipedia.org/wiki/Immutable_object). Vzhledem k tomu, jak Java pridava funkcionalni rysy, cekal bych, ze pujdou i k necemu vyuzivat.
Pokud nesou jenom data, tak to nejsou objekty, ale struktury.
Jak presne se v Jave zapisuji struktury? Navic ta Scala implementace umi i copy metodu, tj. napr. Foo(1,2,"a").copy(name="b") vrati novou immutable instanci Foo(1,2,"b"), to si nejsem jisty, ze v Jave lze ani manualne napodobit (mozna neco jednodussiho ve stylu Foo(1,2,"a").updatedName("b")). Odpoved podle vas je tedy nepouzivat zadne postupy z funkcionalniho programovani?
To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?
U verejneho API? Ehm, to jako vratim tweet instanci s privatnimi fieldy, at si to klientska aplikace reflexi precte? Asi se nechapeme.
Proč? Klient přece nemá co hrabat na atributy objektu. Má být zapouzřený.
??? Klient (napr. moje stranka) si zazada o tweet uzitim nejake knihovny, dostane tweet instanci a jak z ni vybali ty privatni data bez getteru? Nebo jako tweet trida z knihovny treti strany se bude umet zobrazit v me aplikaci? Co si znovu ctu vase odpovedi, tak to na mne pusobi, ze neexistuje spravna cesta. Datove objekty nemam pouzit, accessory take ne, mam pouzivat pouze privatni fieldy. Jsem z toho hodne zmateny. Mohu poprosit o vysvetleni na urovni zacatecnika?
-
Jo, jenomze jak tam das to isFinished, tak najednou mas neco, co nese data, ma acessor a jeste logiku. Bez dat to nepujde, logika i acessor tam davaji smysl.
Asi jsi nedočetl druhý odstavec. Takový objekt ponese data a logiku. Bez accessoru.
-
Jo, jenomze jak tam das to isFinished, tak najednou mas neco, co nese data, ma acessor a jeste logiku. Bez dat to nepujde, logika i acessor tam davaji smysl.
Asi jsi nedočetl druhý odstavec. Takový objekt ponese data a logiku. Bez accessoru.
A k tomu datu se dostanu jak? Kdybych ho nechtel nekde zobrazit nebo jinak pouzit, tak si tam vrazim jenom booleanovsky field.
-
Asi jsi nedočetl druhý odstavec. Takový objekt ponese data a logiku. Bez accessoru.
A k tomu datu se dostanu jak? Kdybych ho nechtel nekde zobrazit nebo jinak pouzit, tak si tam vrazim jenom booleanovsky field.
Nijak. Pokud to budeš chtít někde zobrazit nebo použít, tak to injektuješ. Jak prosté.
-
Genialni. To bude navrh jako remen. Vsimnul sis, ze tam to workflow nejspis bude v bambilionu instancich, ktere se mohu trebas ruzne filtrovat, serializovat...?
-
Genialni. To bude navrh jako remen. Vsimnul sis, ze tam to workflow nejspis bude v bambilionu instancich, ktere se mohu trebas ruzne filtrovat, serializovat...?
Právě proto to dělám tímto způsobem, aby to bylo jednodušší a elegantnější. Je to i kratší a výkonnější.
-
Genialni. To bude navrh jako remen. Vsimnul sis, ze tam to workflow nejspis bude v bambilionu instancich, ktere se mohu trebas ruzne filtrovat, serializovat...?
Právě proto to dělám tímto způsobem, aby to bylo jednodušší a elegantnější. Je to i kratší a výkonnější.
Tak to jsem vazne zvedavy, jak tohle chces udelat ;)
-
Genialni. To bude navrh jako remen. Vsimnul sis, ze tam to workflow nejspis bude v bambilionu instancich, ktere se mohu trebas ruzne filtrovat, serializovat...?
Právě proto to dělám tímto způsobem, aby to bylo jednodušší a elegantnější. Je to i kratší a výkonnější.
Tak to jsem vazne zvedavy, jak tohle chces udelat ;)
A co? Tu třídu Workflow nebo vše okolo ní? Přece registrací do jejího observeru. Okolní objekty se přece nebudou neustále vyptávat jako oslík Shreka.
-
A co? Tu třídu Workflow nebo vše okolo ní? Přece registrací do jejího observeru. Okolní objekty se přece nebudou neustále vyptávat jako oslík Shreka.
Ale tohle ti prece funguje jenom nekdy. Kdyz to workflow nezije moc akcnim zivotem (mas vetsinu instanci nekde v databazi, taha se ti pres nejake remote API, je serializovane...), tak smula...
To, co rikavas, ma leckdy kus pravdy (unitestujte!), ale nikdy to neni vselek, co se da napasovat vsude. Ale to ti dojde s praxi (nebo nedojde a skoncis na dlazbe, ale to uz by bylo na jinci vlakno)
-
Ale tohle ti prece funguje jenom nekdy. Kdyz to workflow nezije moc akcnim zivotem (mas vetsinu instanci nekde v databazi, taha se ti pres nejake remote API, je serializovane...), tak smula...
S relační databází je to mnohem jednodušší, na tom není skoro co programovat.
-
Tak to jsem vazne zvedavy, jak tohle chces udelat
hovorim, ja som sa od kita snazil vyrvat nejaky priklad a neslo to :D
Tu třídu Workflow nebo vše okolo ní? Přece registrací do jejího observeru.
"programator mal problem s gettermi tak ich nahradil injektazou do observera" wtf
priklad? priklad? priklad?
-
Tak to jsem vazne zvedavy, jak tohle chces udelat
hovorim, ja som sa od kita snazil vyrvat nejaky priklad a neslo to :D
Tu třídu Workflow nebo vše okolo ní? Přece registrací do jejího observeru.
"programator mal problem s gettermi tak ich nahradil injektazou do observera" wtf
priklad? priklad? priklad?
Taky cekam na priklad. Chci videt na vlastni oci ty zazracne vedomosti Kita, kde nepotrebujes volat get metodu pro ziskani data.
https://gist.github.com/ (https://gist.github.com/)
-
Taky cekam na priklad. Chci videt na vlastni oci ty zazracne vedomosti Kita, kde nepotrebujes volat get metodu pro ziskani data.
Hmm. Další, kdo nepochopil, že vlastně nepotřebuje ani to datum...
Vždy se ptám: K čemu to datum potřebuješ? A komu tím prospěješ?
-
Hmm. Další, kdo nepochopil, že vlastně nepotřebuje ani to datum...
ani ja som nepochopil.
podla mna trepete
alebo mate zapnuty grep -v na prispevky so slovom priklad?
Samozrejme je vice nez pravdepodobne, ze existuje nejaky lepsi pristup, precejen se Javou (ani Scalou) nezivim.
neni, immutable classes sa robia presne takto: konstruktor s parametrami (alebo factory s parametrami(, final fieldy, gettery.
case classes v scale su presne skrateny sposob ktory setri boilerplate
-
Tak to jsem vazne zvedavy, jak tohle chces udelat
hovorim, ja som sa od kita snazil vyrvat nejaky priklad a neslo to :D
Tu třídu Workflow nebo vše okolo ní? Přece registrací do jejího observeru.
"programator mal problem s gettermi tak ich nahradil injektazou do observera" wtf
priklad? priklad? priklad?
Taky cekam na priklad. Chci videt na vlastni oci ty zazracne vedomosti Kita, kde nepotrebujes volat get metodu pro ziskani data.
https://gist.github.com/ (https://gist.github.com/)
já se taky připojuju k prosbě o příklad, o tom skutečném OOP jsem už mockrát slyšel, ale (zdá se) ještě neviděl
-
ok tak si dajme struct + repository + swing form
https://gist.github.com/anonymous/97c810c45b54d0dd3841
ako sa v structe trolla zbavit getterov a setterov ked sa vytahuju z databazy?
dufam ze toto neni posledny post v tejto teme
-
To vám ještě nedošlo, že krmíte trolla, když vám na otázku "jak přečíst private field?" odpovídá random větami typu "inicializuj continuous integration a pomocí distribuovaných aspektů inlinuj aplikační monádu?" ;D
-
to by chcelo urobit web s generovanim odporucani
"pridej unit testy pro lepsi inversion of control b2b gemu"
web by bol v oop.