JavaEE alebo ASP.NET ?

[noef]

No pockej, to snad nemyslis vazne. Na pomalej android pomalou javu? Ale jo, lepsi nez webovy picoviny

Tak Android je pomalý jen kvůli Javě, je to jen vrstva nad Linuxem, jádro systému pomalé není. Pokud se navíc uskuteční záměr Googlu přejít s Androidem na Swift, pomalý už nebude

Podle benchmarků je někdy pomalejší než Java:

http://benchmarksgame.alioth.debian.org/u64q/swift.html

Teď jsem si navíc všiml, že hned ten první benchmark binary-trees ve Swiftu používá ruční správu paměti přes `UnsafeMutablePointer` - což mi přijde jako podvod, neboť takhle se asi běžně ve Swiftu neprogramuje.

Tak to psal asi debil, UnsafeMutablePointer to dost zpomalí, přeci jen to je wrapper.

O Swiftu nic nevim, ale benchmakrsgame funguje tak, ze se prijimaji reseni od kohokoliv a to nejrychlejsi je pak prezentovane pri srovnavani s jinymi jazyky. Nejak se mi nepozdava, ze jedno z prvnich by nebylo naivni/normalni reseni. Jste si opravdu jisty svym tvrzenim?

[Reklama]

[Radek Miček]

No pockej, to snad nemyslis vazne. Na pomalej android pomalou javu? Ale jo, lepsi nez webovy picoviny

Tak Android je pomalý jen kvůli Javě, je to jen vrstva nad Linuxem, jádro systému pomalé není. Pokud se navíc uskuteční záměr Googlu přejít s Androidem na Swift, pomalý už nebude

Podle benchmarků je někdy pomalejší než Java:

http://benchmarksgame.alioth.debian.org/u64q/swift.html

Teď jsem si navíc všiml, že hned ten první benchmark binary-trees ve Swiftu používá ruční správu paměti přes `UnsafeMutablePointer` - což mi přijde jako podvod, neboť takhle se asi běžně ve Swiftu neprogramuje.

Tak to psal asi debil, UnsafeMutablePointer to dost zpomalí, přeci jen to je wrapper.

O Swiftu nic nevim, ale benchmakrsgame funguje tak, ze se prijimaji reseni od kohokoliv a to nejrychlejsi je pak prezentovane pri srovnavani s jinymi jazyky. Nejak se mi nepozdava, ze jedno z prvnich by nebylo naivni/normalni reseni. Jste si opravdu jisty svym tvrzenim?

Aha, ona si lze dokonce rozkliknout různá řešení ve Swiftu http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift

A řešení s UnsafeMutablePointery pointry trvají 3.96 s (program #5) a 12.76 s (program #4). Ta s normálními pointry (typ TreeNode?) trvají 96.72 s (program #3) a 97.8 s (program #1).

Java má na benchmarku binary-trees mnohem menší rozptyl - hodnoty se pohybují od 11.51 s do 14.57 s (alespoň podle 5 programů, jenž jsou vybrány na http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=java).

[marty]

Java je pomala a taky i android. Na windows mobile a iphone se to nechyta

Java je pomalšia akurát tak na wydlách a windows mobile je mŕtvola, ktorú zarezal už aj samotný M$.
Porovnávať Javu a iPhone je scestné, keď potrebujem niečo rýchlo nakodiť, naštartujem Netbeans a za 10 minút mám hotový skript. Neviem si predstaviť ako by som to urobil s iPhone. Samozrejme na účely pre ktorý bol vyrobený slúži iPhone výborne.
Pre mňa je úplne fuk, či vykonanie skriptu trvá 0.01 alebo 0.1 sekundy. Dôležité je, že skript mám rýchlo napísaný, odladený, funguje a dá sa naň spoľahnúť. Jednoduchšie veci samozrejme napíšem v Bashi.

Kto vam povedel, ze windows mobile je mrtvola? A odkud mate informace, ze MS ho zariznul? Kdyby jste byl lip informovan, tak nekecate taketo picoviny. Protoze Windows 10 je univerzalnej system a MS se soustredi na ten system jako na celek. Cili nesoustredi se primo na windows 10 mobile. Ja sam mam telefon s w10 mobile verzi pro developery a v podstate stale mam nejake updates.
Miluji takovy reci, kdyz si nekdo neoveri ani fakta

[zboj]

No pockej, to snad nemyslis vazne. Na pomalej android pomalou javu? Ale jo, lepsi nez webovy picoviny

Tak Android je pomalý jen kvůli Javě, je to jen vrstva nad Linuxem, jádro systému pomalé není. Pokud se navíc uskuteční záměr Googlu přejít s Androidem na Swift, pomalý už nebude

Podle benchmarků je někdy pomalejší než Java:

http://benchmarksgame.alioth.debian.org/u64q/swift.html

Teď jsem si navíc všiml, že hned ten první benchmark binary-trees ve Swiftu používá ruční správu paměti přes `UnsafeMutablePointer` - což mi přijde jako podvod, neboť takhle se asi běžně ve Swiftu neprogramuje.

Tak to psal asi debil, UnsafeMutablePointer to dost zpomalí, přeci jen to je wrapper.

O Swiftu nic nevim, ale benchmakrsgame funguje tak, ze se prijimaji reseni od kohokoliv a to nejrychlejsi je pak prezentovane pri srovnavani s jinymi jazyky. Nejak se mi nepozdava, ze jedno z prvnich by nebylo naivni/normalni reseni. Jste si opravdu jisty svym tvrzenim?

Aha, ona si lze dokonce rozkliknout různá řešení ve Swiftu http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift

A řešení s UnsafeMutablePointery pointry trvají 3.96 s (program #5) a 12.76 s (program #4). Ta s normálními pointry (typ TreeNode?) trvají 96.72 s (program #3) a 97.8 s (program #1).

Java má na benchmarku binary-trees mnohem menší rozptyl - hodnoty se pohybují od 11.51 s do 14.57 s (alespoň podle 5 programů, jenž jsou vybrány na http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=java).

Aby to nebyl jeden z těch benchmarků přeložených bez -Ofast, to fakt trvá věčnost.

[Radek Miček]

I kdyz postrada 64-bit verzi, stale je to nejlepsi IDE oproti eclipse, netbeans, android studio

To mozna, ale oproti IntelliJ IDEA urcite ne. Sam jsem ten prechod VS -> IDEA absolvoval a nemenil bych .

Z jaké verze a edice?

VS 2015 Enterprise má nástroje, které AFAIK IntelliJ IDEA Ultimate nemá a musíte si je dokoupit. Například IntelliTrace (ladění s historií; pro IDEU si musíte dokoupit Chronon). Nebo IntelliTest (automatický generátor testů; nemám tušení, jak si vedou Javovské nástroje); v minulých verzích VS byl zdarma Microsoft Code Digger.

[Reklama]

[hawran diskuse]

...
Kto vam povedel, ze windows mobile je mrtvola? A odkud mate informace, ze MS ho zariznul? Kdyby jste byl lip informovan, tak nekecate taketo picoviny. Protoze Windows 10 je univerzalnej system a MS se soustredi na ten system jako na celek. Cili nesoustredi se primo na windows 10 mobile. Ja sam mam telefon s w10 mobile verzi pro developery a v podstate stale mam nejake updates.
Miluji takovy reci, kdyz si nekdo neoveri ani fakta

PS: Opravdu máš dojem, že toto vlákno je o jakémsi woknous mobile, nebo snad dokonce o w10?

[Kit]

PS: Opravdu máš dojem, že toto vlákno je o jakémsi woknous mobile, nebo snad dokonce o w10?

To máš těžké. Když se někdo zeptá C# vs. Java, tak to jinak ani dopadnout nemůže.

Java

[Lama]

A hele, Oracle sere na Javu http://connect.zive.cz/bleskovky/oracle-nadale-roste-vcloudu-zacina-ale-odsouvat-javu-na-druhou-kolej/sc-321-a-182871

To už platí déle. Je třeba si přiznat, že Java je zastaralá a jede jen ze setrvačnosti. Při nemalém množství extrémní snahy by se dala samozřejmě aktualizovat, aby šla s dobou, nicméně i Oraclu je jasné, že to asi nemá cenu vzhledem k novým jazykům, jež řeší totéž lépe. Je to prostě legacy, v podstatě už několik let, teď to je jen zřejmější. Java 9 bude udržovací a pak dlouho nic. Ať žije nový Cobol

Zase něčí zbožné přání? Java nestojí na Oracle, možná kromě referenční implementace. Na vývoji se podílí řada dalších. Zastaralá jak, v čem? Java jako platforma podporuje řadu jazyků včetně funkcionálních. JVM určitě není horší než NETí VM od MS.

PS: Opravdu máš dojem, že toto vlákno je o jakémsi woknous mobile, nebo snad dokonce o w10?

V podstatě ano. Ono to spolu nevyhnutně souvisí, když se začnou rozebírat ne-výhody té které technologie, tak zákonitě dojde debata i na toto.

Kto vam povedel, ze windows mobile je mrtvola? A odkud mate informace, ze MS ho zariznul? Kdyby jste byl lip informovan, tak nekecate taketo picoviny. .............
.....................
Miluji takovy reci, kdyz si nekdo neoveri ani fakta

Záleží jak budem definovat a poměřovat živost/mrtvost projektu. Pokud to poměřujem počtem uživatelů, aplikací, vývojářů, tak mobilní Wokna tedy moc nežijou... 

[marty]

Kvalita vyvoje, jednoduchost vyvoje pro win10 mobile je absolutne nekde jinde oproti Androidu.

[Kit]

Kvalita vyvoje, jednoduchost vyvoje pro win10 mobile je absolutne nekde jinde oproti Androidu.

Absolutně o jakou konkrétní hodnotu?

[Radek Miček]

A hele, Oracle sere na Javu http://connect.zive.cz/bleskovky/oracle-nadale-roste-vcloudu-zacina-ale-odsouvat-javu-na-druhou-kolej/sc-321-a-182871

To už platí déle. Je třeba si přiznat, že Java je zastaralá a jede jen ze setrvačnosti. Při nemalém množství extrémní snahy by se dala samozřejmě aktualizovat, aby šla s dobou, nicméně i Oraclu je jasné, že to asi nemá cenu vzhledem k novým jazykům, jež řeší totéž lépe. Je to prostě legacy, v podstatě už několik let, teď to je jen zřejmější. Java 9 bude udržovací a pak dlouho nic. Ať žije nový Cobol

JVM určitě není horší než NETí VM od MS.

Nevím, jestli je horší, ale každopádně neumí řadu věcí, jenž CLR umí. Konkrétně: tail call optimization (TCO), uživatelsky definované hodnotové typy, reifikace generik, ukazatele dovnitř hodnotových typů, přichycení struktur v paměti (aby je GC nepřesouval). Většina jmenovaného má poměrně značný dopad na výkon - např. TCO je pro funkcionální jazyky klíčové.

Dále CLR podporuje delší těla funkcí - to je užitečné pro jazyky s makry.

[gl]

A hele, Oracle sere na Javu http://connect.zive.cz/bleskovky/oracle-nadale-roste-vcloudu-zacina-ale-odsouvat-javu-na-druhou-kolej/sc-321-a-182871

To už platí déle. Je třeba si přiznat, že Java je zastaralá a jede jen ze setrvačnosti. Při nemalém množství extrémní snahy by se dala samozřejmě aktualizovat, aby šla s dobou, nicméně i Oraclu je jasné, že to asi nemá cenu vzhledem k novým jazykům, jež řeší totéž lépe. Je to prostě legacy, v podstatě už několik let, teď to je jen zřejmější. Java 9 bude udržovací a pak dlouho nic. Ať žije nový Cobol

JVM určitě není horší než NETí VM od MS.

Nevím, jestli je horší, ale každopádně neumí řadu věcí, jenž CLR umí. Konkrétně: tail call optimization (TCO), uživatelsky definované hodnotové typy, reifikace generik, ukazatele dovnitř hodnotových typů, přichycení struktur v paměti (aby je GC nepřesouval). Většina jmenovaného má poměrně značný dopad na výkon - např. TCO je pro funkcionální jazyky klíčové.

Dále CLR podporuje delší těla funkcí - to je užitečné pro jazyky s makry.

TCO nemusí řešit VM.

[Radek Miček]

A hele, Oracle sere na Javu http://connect.zive.cz/bleskovky/oracle-nadale-roste-vcloudu-zacina-ale-odsouvat-javu-na-druhou-kolej/sc-321-a-182871

To už platí déle. Je třeba si přiznat, že Java je zastaralá a jede jen ze setrvačnosti. Při nemalém množství extrémní snahy by se dala samozřejmě aktualizovat, aby šla s dobou, nicméně i Oraclu je jasné, že to asi nemá cenu vzhledem k novým jazykům, jež řeší totéž lépe. Je to prostě legacy, v podstatě už několik let, teď to je jen zřejmější. Java 9 bude udržovací a pak dlouho nic. Ať žije nový Cobol

JVM určitě není horší než NETí VM od MS.

Nevím, jestli je horší, ale každopádně neumí řadu věcí, jenž CLR umí. Konkrétně: tail call optimization (TCO), uživatelsky definované hodnotové typy, reifikace generik, ukazatele dovnitř hodnotových typů, přichycení struktur v paměti (aby je GC nepřesouval). Většina jmenovaného má poměrně značný dopad na výkon - např. TCO je pro funkcionální jazyky klíčové.

Dále CLR podporuje delší těla funkcí - to je užitečné pro jazyky s makry.

TCO nemusí řešit VM.

To je pravda, ale třeba ruční trampolínování, jak se to dělá ve Scale, vede k řešením, která jsou 10 - 50 krát pomalejší (protože alokují na heapu). A navíc to komplikuje kód.