C# .NET vs. Java?

[karl82]

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?

[Reklama]

[UrielSVK]

Mozno ta to prekvapi ale ak sa naucis novy jazyk nezabudnes automaticky ten stary...

[Radek Miček]

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.

[Kit]

• 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?

[perceptron]

* 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

[Reklama]

[Radek Miček]

* 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++.

[atarist]

• 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.

[Kit]

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.

[perceptron]

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.

[Ivan]

• 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.

[Kit]

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.

[Tomáš Roll]

Proč zvěrstvo? Generovaný kod nemusí být pěkný a čitelný, nikdy ho nebudete opravovat.

[Kit]

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.

[Kolemjdoucí]

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.

[perceptron]

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