Jazyk podobný C#

[balki]

Můžeš zkusit jazyk jménem Scala, který se kompiluje do bytecodu JVM.

Problém je spíš v použití JVM/.Netu pro realtime aplikace. Na tomto poli jsou kladené zcela jiné požadavky než u běžných aplikací (navíc se liší mezi jednotlivými RT aplikacemi) a začíná to již u operačního systému.

Je realtime a realtime.  Ja robim realtime aplikacie na java SE a staci to. Trosku treba zmenit styl uvazovania, mysliet multiparadigmovo (Rozmysliet si, co sa hodi viac v objektoch a co uz treba robit proceduralne ),  hlavne umyselne neplytvat z drojmi a ked sa najde bottleneck, tak optimalizovat. Java je svizny jazyk, ked si clovek aplikaciu nezabloatuje. Vyhodou je, ze poskytuje celkom velavravne chybove hlasky nie ako v C, ked sa proste nieco pokazi a teraz debuguj ...

[Reklama]

[JSH]

A realtime a rychlé jsou dvě různé věci, realtime především znamená garantovanou dobu odezvy, nikoliv však nějaké rekordy v množství vyřízených požadavcích délce doby vyřízení.

Tohle by se mělo tesat do kamene. Požadavky na latenci (doba zpracování nějakého požadavku) a propustnost (počet zpracovaných požadavků za čas) jdou hodně často proti sobě. Je to vidět i na hardwaru. CPU jsou optimalizované na latenci a GPU na propustnost.
Pravé realtime (garantovaná doba odezvy) se vůbec nedá na x86 s běžným OS dosáhnout.

[belzebub]

Vala (https://wiki.gnome.org/Projects/Vala)

Hlavne NE vala!!! Vala je sice na prvni pohled vyborny projekt - vsechny vyhody "osvedceneho" glib/gobject frameworku pro C, uzasne snadne pouzivani knihovny ve vale z jinych jazyku, kompilace do C, umoznujici kompilovat pro temer jakoukoliv platformu, atd, atd.

Vsechno krasne, pokud se to cte, pokud se to tyka psani nejnovejsich glib/gobject knihoven. Ale jakmlile v tom potrebujete pracovat a prijde prvni problem, zjistite, ze:

 * podobnost s c# je pouze povrchni, jedna se o vyrazne jiny jazyk, a mnoho veci funguje VYRAZNE jinak, nez se zda ze by to fungovat mohlo
 * temer neexistuje dokumentace, ta co existuje je pro starou verzi, obsahuje chybne priklady a nebo proste neni
 * pouziti existujicich ne-gobject C knihoven je porod, ktery ve vetsine pripadu konci smrti - nektere veci, proste NEJDOU, takze bud existujici knihovnu prepisete do valy, nebo napisete "normal-C"->"gobject-C" rozhrani.
 * podpora v make, autotools, atd je zoufala
 * debugovani je katastrofa, diky automatickemu prekladu do C mate temer jistotu ze nepochopite v cem vlastne chyba byla

ve zkratce: NE, NE, NE a jeste jednou NE!

Mluvim z vlastni zkusenosti, "vyhodili" jsme diky vale cca 4 mesice prace 3 lidi. Takze vam radim, vale se zdaleka vyhnete!!!

[Jimm]

Díky Belzebube, začínala se mi líbit a uvažoval jsem že bych se jí začal věnovat.

[Mirek]

...
ve zkratce: NE, NE, NE a jeste jednou NE!

Mluvim z vlastni zkusenosti, "vyhodili" jsme diky vale cca 4 mesice prace 3 lidi. Takze vam radim, vale se zdaleka vyhnete!!!

Jinymi slovy tedy rikas "Dejte Vale vale!"

[Reklama]

[iwtu]

Problém jazyků je ten, že se k ní vyjadřují blbci, kteří v tom napsali Hello World. Rychlost běhu C#/Java je naprosto srovnatelná. Oboje se kompiluje do nativního kódu, u Javy můžete dokonce nastavit kompilaci při prvním průběhu programu. Říká se tomu Virtual Machine Hints, to jen na opravu místních kecalů. Častý mýtus mnoha lidí je, že prostý překlad do jiného jazyka, který se následně kompiluje do strojového kódu, cokoliv urychlí. Takové pověře může uvěřit jen ten, který zatím vůbec netuší, co se děje s jeho kódem. C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C. Proč ? Inu:

1) VM má k dispozici informace o vašem hardware a kompiluje přímo pro něj, nikoliv univerzálně. Některé operace (hlavně aritmetika a práce se soubory) se tak dají značně urychlit.
2) Důvod, proč kód v jazycích, které dovolují práci na nižší úrovni abstrakce, bývá po překladu rychlejší, je jednoduchý: Malá obecnost řešení a málo bordelu. Otázka bývá špatně položena. Vůbec nejde o to, jestli něco generuje nativní instrukce a něco nikoliv (oboje lze přinutit ke kompletnímu překladu). Jde o to, jak generovaný kód vypadá. Funkce, které voláte v Javě či C#, jsou přeci jen univerzálnější. Nemusíte sledovat pointery na soubory. Java dokonce od verze 7 automaticky uzavírá alokované zdroje v kontrolovaných blocích. A protože jsou napsané univerzálně, jejich strojový kód vypadá jinak než ten, který vygeneruje Vámi napsaný prográmek v C/C++, který ale nevyhovuje tak obecnému použití. Pokud použijete v C++ obecnou knihovnu, vůbec nemusí být rychlejší než přeložený program v Javě, někdy naopak.

V Javě můžete kritické části implementovat v jiném jazyce, říká se tomu JNI. A na zbytek použít Java knihovny. Říká se, tj. nemám to ověření, že volání nativní metody trvá okolo 35 nanosekund. Pokud je její průběh rozumně dlouhý (což u kritických částí programu bude), máte k dispozici zbraň slušného kalibru. Krásná ukázka, že Java umí běžet naprosto stejně rychle jako program v C++, je JOGL. Když na procesoru počítáte matice a pouze výsledný předáváte shaderům, pak zjistíte že Java umí optimalizovat práci s maticí reprezentovanou jednorozměrným polem naprosto skvěle - tj. práce s ní je stejný fofr jako když to samé izoluji a napíši v C. S tím že C kód má o dost horší metriku.

Výhody a nevýhody obojího si musí každý zvážit sám.

Závěr je následující: Jestliže někdo hledá náhradu za C#, pak v něm pravděpodobně nic moc neumí či nic seriózního nedělá. C# se totiž nahradit nedá, pomineme-li ostatní jazyky z balíku .NET. Má jinou úlohu než Java, jeho API je jiné (jestli někdo přijde s tím, že oboje má kolekce a podobné kecy...). Dokonce i vláknování, což většina programátorů nedělá a neumí, je v C# připravené pro Windows. Proto je jeho portování (jako projekt Mono) tak šíleně kontraproduktivní. Dotnet je spjatý s platformou Windows, na které dejme tomu funguje dobře a rozumí si s ní. Čím toto chcete nahradit ? Zkuste v Javě najít rozlišení vláke na foreground/brackground. Zkuste v ní najít podporu D3D. To vše je Windows only.

Všechny tyto thready jsou jen důkazem toho, jak je teorie a vzdělání důležité.

+100

[karol]

Autor ma pravdu v tom ze Java aplikacie nie su uplne plynule. Neviem ci za to mozu konkretne implementacie jvm (pouzivam javu od oracle,  skusal som aj open jdk) alebo graficke toolkity (swing, swt) ale este som sa nestretol s java aplikaciou ktra by bola 100 percentne plynula (preto. Nepouzivam IDEcka ako IDEA, Eclipse ani NetBeans proste sa mi s v tom nepracuje dobre). Taktiez su java aplikacie dost nenazrane (maju divny memory management) a dlho startuju, nehovoriac o otrasnej typografii v ui swing (menucka nemaju nastavene paddingy takze su vsetky itemy nalepene na seba co znizuje celkovy user xp a bezneho uzivatela java na desktope maximalne odradi. Naopak u .NET appiek som sa s podobnymi problemami nestretol (ak nepocitam pomalsi start) - bezny uzivatel ich nerozozna od nativnych.

[noef]

nehovoriac o otrasnej typografii v ui swing (menucka nemaju nastavene paddingy takze su vsetky itemy nalepene na seba co znizuje celkovy user xp a bezneho uzivatela java na desktope maximalne odradi. Naopak u .NET appiek som sa s podobnymi problemami nestretol (ak nepocitam pomalsi start) - bezny uzivatel ich nerozozna od nativnych.

hmm

jak presne ze se lisi to menu (nebo jakykoliv jiny ovladaci prvek) v Jave od nativniho (testovano na desktopu s win7)? horni je WPF a dolni Swing. Dokonce bych rekl, ze Java ma vic nativni vzhled nez WPF (rozmazly radio control a menu vyber). BTW docilit nativniho vzhledu ve Swingu byla otazka dvou radku (+ jednoho radku importu).

[eMko]

Java ma vic nativni vzhled nez WPF

Swing je lépe porovnávat s Windows.Forms než s WPF.

Každopádně pokud má karol problém s paddingy ve Swingu, je chyba někde jinde než ve Swingu samotném. Každý vzhled je má nastaveny jinak.

[fish]

Ahoj,

existuje pro Linux jazyk podobný C#?
- Překladač z toho musí udělat nejlépe strojový kód, potřebuji to na realtime aplikaci.
- Java je sice pěkná a vyhovovala by, ale je na to příliš, příliš, pomalá.

V zásadě se nechci start o alokaci paměti, mimo jiné a musí to být opravdu exra rychlé.

Pokud chces programovat v necem, v cem uz bylo takovych aplikaci napsanych habadej a troufam si rict, ze jeste bude tak rozhodne zvol nizsi patro - C# a Java se nachazeji na identickem podlazi a pro realtime aplikace navrzeny nebyly. Jak tady jiz nekdo psal - Assembler mam osobne rad (nebo C - zalezi na obsahlosti aplikace). Kdysi jsem v nem napsal jeste v DOSu docela robustni aplikaci, ale precejen to bylo zaroven naposled. Precejen se pohybujes na urovni dvou az tri znakovych, dookola se opakujicich instrukci a v dost velkem projektu by z toho mohla jit casem hlava kolem Takze jsem se v tom sam zamotal a zvolil bych uz z tohoto duvodu C - jak jsem jiz zminil - nepreberne mnozstvi kodu, velka komunita, mnozstvi knih a dokumentace, moznost pouzit Assembler bloky a ta prehlednost je taky podstatne lepsi

[fish]

A realtime a rychlé jsou dvě různé věci, realtime především znamená garantovanou dobu odezvy, nikoliv však nějaké rekordy v množství vyřízených požadavcích délce doby vyřízení.

Tohle by se mělo tesat do kamene. Požadavky na latenci (doba zpracování nějakého požadavku) a propustnost (počet zpracovaných požadavků za čas) jdou hodně často proti sobě. Je to vidět i na hardwaru. CPU jsou optimalizované na latenci a GPU na propustnost.
Pravé realtime (garantovaná doba odezvy) se vůbec nedá na x86 s běžným OS dosáhnout.

Dovolim si nesouhlasit - pokud napisu aplikaci v OS DOS like, tak se na x86 da realtime aplikace napsat. Pokud se mylim, prosim o zduvodneni - drzme se OS, ktery jsem uvedl a pro priklad uvedme aplikaci, ktera bude snimat data z detektoru, zanalyzuje data a dle vyhodnoceni provede urcitou cinnost - napr. zaslani TCP paketu (priklad berte s rezervou )

[Ondřej Novák]

Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk

C++

[gamer]

Dovolim si nesouhlasit - pokud napisu aplikaci v OS DOS like, tak se na x86 da realtime aplikace napsat. Pokud se mylim, prosim o zduvodneni - drzme se OS, ktery jsem uvedl a pro priklad uvedme aplikaci, ktera bude snimat data z detektoru, zanalyzuje data a dle vyhodnoceni provede urcitou cinnost - napr. zaslani TCP paketu (priklad berte s rezervou )

Tohle není realtime aplikace. Realtime je třeba ABS v autě, kde se řeší úlohy typu snímám otáčky kola a když zjistím, že se to netočí dost rychle, musím do 10 ms (zaručeně!) sepnout čerpadlo ABS, jinak se stane něco nehezkého. V tom DOSu je třeba ovladač myši, který si občas vezme řízení v přerušení. Když nedokážu zaručit, že to bude do 10 ms (včetně všech ostatních věcí, které se mohou stát), tak DOS použít nemůžu.

[maze]

C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C.

Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...

[Jakub Galgonek]

Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...

To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.