Java vs. C# - který jazyk zvolit?

Java je proprietarni sra*ka stejne jako .NET

Jasne, asi by sme sa mali vratit do jaskyne, mozeme si vsetko pisat rovno v hexaeditore a pekne usite presne na svoj pocitac, vlastne aj OS je nam v podstate na prd, nie? Nevidim dovod preco nevyuzit Javu, C, Cobol .... a trebarz aj C# (aj ked o tom viem prd, lebo velkym fanusikom MS nie som). Sorry, to nie je odozva na Tvoj prispevok, ale na celu tu debatu, ktoru som dve hodiny cital. Mal som ist radsej na pivko ... Ale vazne, ja ked potrebujem nieco napisat, volim jazyk podla okolnosti z tych, co nimi rozpravam. Zatial som si vzdy vystacil s troma C, C++ a Java. Ozaj pisali ste niekto niekedy v C# trebarz ICQ clienta pre mobilny phone? No ja som si s C ani C++ nevystacil a C# na tom asi bude rovnako. Skusal niekto z Vas v Jave pisat driver pre nejaky HW alebo vobec cokolvek zavisle na konkretnom HW? Tak asi nie, alebo hadam ano? A vo tom to prave je .... I tak se da, i tak se da! Az budem naozaj musiet, hadam zvladnem aj to C# (ucil som sa aj ovele, avela vacsie blbosti)

Resite vjeci :))
Muj zaver je takovejto: Vyberu to nejlepsi z Javy a z C a dostanu Borland Delphi

Tak to je pekna blbost chlape. Meli byste si tu vsichni uvedomit ze Java a C++ maji dosti podobnou syntaxi, ale jinak jsou zcela odlisne a co je nejdulezitejsi JAVA je predurcena k vyvoji webovych aplikaci a C++ k stanalone aplikacim bezicim na clientovi. Delphi nema s temito dvema temer nic spolecneho (krom toho ze se jedna o programovaci jazyk) a vychazi z Pascalu. Je to asi jako QBasic a Visual basic. Proste klasicky jazyk kteremu bylo pridano IDE, nejake visualni (windowsowske) komponenty a par dalsich nesmyslu. Se vsemi temito nastroji jsem v minulosti pracoval, takze o tom neco vim. Koukam ale ze je tu diskuze buranu kteri pouzivaji vsechny vyse zminene jazyky na programovani aplikaci typu Hello World  a nejakych trapnych textovych her, ale v praxi nevi o co bezi. Ja se Javou jiz nejakou dobu zivim a rozhodne si na hlad nestezuju ))

To ci sa bude aplikacia pisat v jave alebo c# nezalezi od osobnych preferenci
developerov. Skor od toho, co povie zakaznik. Od coho zavisi rozhodnutie zakaznika
o platforme/jazyku mi je zahadou. Viem od coho to  rozhodne nezavisi:
od preprocesora, sablon, properties, checked execeptions, enumov atd.

Ak sa vasa firma orientuje na skupinu zakaznikov, kde frci M$, mate s javou smolu. Aj keby bola
pozlatena. A naopak.

Ja preferujem javu a nic mi v nej nechyba.
Zabudol som, ze exituje cosi ako predavanie parametrov odkazom, preprocesor, sablony,
operatory, malloc, ifdefy pre kazdy kompilator, uroven implementacie ansi standardu,
pikanterie jednotlivych implementacii stl, debugovanie v assembleri.  

ak preferujete microsoft, najdite si vhodnu firmu. ja som si tiez nasiel vhodnu firmu .

 -m.

Sice ten prehled a porovnani vlasnosti neni uplne detailne popsan (nektere ty vlasnosti jako treba properties mi neni jasny co je), ale i tak je to dobre srovnani co neni na jinem webu (tedy cesky).

Interview s Andersem Hejlsbergem, tvůrcem Turbo Pascalu, Delphi a C#. Je rok a půl staré, ale stojí za přečtení!!!

http://windows.oreilly.com/news/hejlsberg_0800.html

Třeba co říká o unsafe:

When you're writing unsafe code in C#, you have the ability to do things that aren't typesafe, like operate with pointers. The code, of course, gets marked unsafe, and will absolutely not execute in an untrusted environment. To get it to execute, you have to grant a trust, and if you don't, the code just won't run. In that respect, it's no different than other kinds of native code. The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack. You have to remarshall all the arguments out of the box. Once you're using objects, you have to be very careful about which ones you touch because the GC [Garbage Collector] is still running on a different thread. It might move the object if you haven't pinned it down correctly by using some obscure method to lock the object. If you forget to do that, you're just out of luck.

We've taken a different approach. We've said, "Let's integrate this into the language. Let's provide statements, like the fixed statement, that allow you to pin down the object cooperatively with the GC and integrate it." In that way we provide the best means of bringing all existing code forward, instead of just throwing it away. It's a different design form.

Tak to je ukazkovy priklad toho, jak si nekdo umi zduvodnit, ze ten gulas co namichal neni pelmel, ale ze to je super smes vsech chuti, co bude chutnat uplne vsem. No radeji bych takove vsechut-jidlo nezral - asi po nem bude bolet brisko

Ve Visual Studiu je používání unsafe bloků v novém C# projektu defaultně zakázáno, musíte to povolit.

Hejlsberg má pravdu v podstatě věci: Je to daleko bezpečnější a daleko pohodlnější, než JNI. A jestliže existuje objektivní potřeba něčeho jako je JNI - a to existuje - proč to neudělat lépe?

Jako bývalý programátor to vítám. A jako člověk, který má teď velmi blízko k řízení SW projektů, to vítám také.

Mel bych tri dotazy.

1) Co to znamena ze Java nepodporuje multidimensionalni pole? To jako ze tam nefunguje konstrukce array[x][y]? To snad ne. Da se v tom pak vubec programovat? Nebo jak se to resi?


2) Nekdo tu zminil jazyk Ruby, porad o nem slisim jak je vyborny, ale nikdo mi nedokaze rict proc. Co je na nem tak dobreho a prevratneho, aby mi stalo se jej ucit. Syntaxi ma docela nezvyklou, takze vypati se to vubec se jim zabyvat?


3) Je-li .NET multiplatformni, plati to i o C#? Muzu ted hned z fleku v linuxu tuto technologii a jazyk zacit pouzivat? Nebo je to jen sen o budoucosti, ktery kdo vi jak dopadne? Resp. lze linux efektivne pouzivat jakoserver pro .NET technologii?

1) samozrejme, ze multidimenzionalne polia (ani spominana konstrukcia) nie su v Jave ziadny problem...
2) Ruby je "vyborny" v tom, ze (vraj) ponuka velke moznosti - v oblasti OOP a pod. To aky to ma v praxi vyznam zrejme svedci jeho rozsirenost :)
3) teraz z fleku asi nezmozete s .net-om mimo Windows nic. Momentalne nemozno pouzit Linux ani iny OS ako .net server (na portovani .net-u sa pracuje, otazka je co a kedy bude naozaj portovane a co bude naozaj prenositelne - vychadza sa z toho, co MS standardizoval, tj. iba CLR a C# ako jazyk). Cize az vo chvili, ked bude nejaky port, tomuto standardu zodpovedajuci, k dispozicii, bude jasne, aka cast .net-u bude naozaj portabilna, tj. ako bude treba .net aplikacie pisat, aby boli naozaj prenositelne...

ad 1) Obecne aby Java pracovala s multidimensionalnim polem neni problem, ale ten nastane, kdyz chcete resit slozite matematicke ulohy, jako jsou sifrovaci metody, graficke propocty ci simulace paralneni vypoctu s velkymi cisly v maticich. Jak jiz jsem uvedel ve svem clanku, nejlepe o tom hovori vyzkumnici z IBM. Viz. zde http://www.research.ibm.com/ninja/#sc99

Odpoved na 2) podle `$ man ruby`:

- interpretovany - jako napr. perl - netreba prekladat, netreba vytvaret vlastni objekty, staci sednout a zacit pouzivat genialne navrzene knihovny
#! /usr/bin/ruby
# tohle je naprosto jasne - dela to to same, jako nasledujici v shellu:
# for i in *.png; do convert $i ${i//png}.jpg; done
# zkonvertuje vsechny PNG v aktualnim adresari na JPG
Dir['*.png'].each do |png|
system ('convert', png, png.sub (/png$/, 'jpg'))
end

- promenne nemaji typy - kazda promenna muze obsahovat libovolny typ
#! /usr/bin/ruby
i = 'Ahoj' # String
i = [] # Array
i = {} # Hash
i = /^ble/ # RegExp
i = 2..4 # Range
...

- neni potreba deklarovat promenne
#! /usr/bin/ruby
i = 2 # lokalni promenna
$i = 2 # globalni promenna
@i = 2 # promenna instance objektu - proste to same jako: self.i = 2
CONF_DIR = '/etc/ble' # konstanta

- jednoducha syntaxe - podle dokumentace byla prevzata z jazyka Eiffel (bohuzel neznam)
#! /usr/bin/ruby
i = 2 # bez stredniku, nebo
i = 2; # se strednikem
a, b = 2, 3
a += 1
while true do
print "Ahoj..."
end
if i then print "i neni nil ani false"; end
if !i
print "To same"
end
if not i ...
if !i or false ...
if i == 0 || a b ...
metoda (1, 2, 3) # se zavorkama nebo
metoda 1, 2, 3 # bez zavorek

- zadny memory managment - interpretr obsahuje garbage collector; programovani pridavnych knihoven napr. v C je proto nadherne jednoduche - proste vytvorite novy class (nebo modul) a pridate do nej metody (nebo funkce):
...
static VALUE
sl_get_winch_flag(void)
{
return INT2FIX(Want_Window_Size_Change);
}
...
void
Init_slanglib()
{
mSlang = rb_define_module("Slanglib");
rb_define_module_function(mSlang, "sl_get_winch_flag", sl_get_winch_flag, 0);
..

stejne jsou delany i zakladni typy - stoji za to se podivat do zdrojaku - byl jsem z te genialni jednoduchosti uplne paf.


- vse je objekt - zakladni typy od Integeru, Float az po Array, Hash, Range a RegExp jsou objekty
#! /usr/bin/ruby
a = [] # shodne s: a = Array.new

# 12 je objekt a times jeho metoda, ktere se preda blok kodu
12.times do |i| # metoda times 12x vyvola tento blok a preda mu `i'
a.push (i.to_s) # shodne s: a .

- iteratory - naprosta bomba, uz jsem to tu mnohokrat pouzil. Metodam muzete predavat blok kodu, ktery se zevnitr metody muze libovolne volat s libovolnymi parametry.

#! /usr/bin/ruby
{2 = 'cau', 'ble' = false}.each_pair do |key, value|
print "key: #{key}, value: #{value.to_s}\n"
end
# nebo zapis {} misto do end
(2..50).each {|i| push i}
# nebo jeste jiny zapis, ktery se prevede na ten minuly
for i in 2..50 do push i; end
# otevri soubor, proved blok a zas ho zavri
File.open ('/etc/passwd') do |file|
file.each_line do |line|
print line.sub (/:/, '=')
end
end
# to same standartnim zpusobem
file = File.open ('/etc/passwd')
file.each_line do |line|
print line.sub (/:/, '=')
end
file.close

- closures - muzete vzit kus kodu a udelat z nej objekt, kod je svazany s mnozinou lokalnich promennych v miste definice
#! /usr/bin/ruby
# udelam objekt
kod_v_objektu = Proc.new do |param|
print param
end
# a vyvolam kod
kod_v_objektu.call ('cau')

- velka cisla - muzete vypocitat napriklad faktorial ze 400. Ruby interne prevadi Integer mezi malym (32b) a velkym (libovolne dlouhe cislo) formatem dle potreby.

- vyjimky
f = File.open("testfile")
begin
# .. process
rescue
# .. handle error
else
puts "Congratulations-- no errors!"
ensure
f.close unless f.nil?
end

- primy pristup k OS - muzete pouzivat vetsinu systemovych volani Unixu, existuje nejaka knihovna pro volani Windows API (netestoval jsem)

- dynamicke loudovani modulu - require 'muj_modul' hleda jak muj_modul.rb, tak i muj_modul.so, coz je dynamicka knihovna psana treba v C.

- svobodny software (GPL)

- rychly (asi jako Python), nenarocny na pamet (mene narocny, nez Perl)

- vyborna dokumentace:
http://www.rubycentral.com/book/index.html - svobodna 500. strankova kniha
http://www.hypermetrics.com/ruby37.html - 37 duvodu proc ma autor rad Rubyho, doporucuji precist

- geometricky se zvysujici pocet uzivatelu

- opravdu kvalitni a promyslene objektove knihovny, na jeho metody u Stringu a Array se nechyta dokonce ani Perl. Rekl bych, ze je to v soucasnosti nejsilnejsi jazyk na spracovani textu.

- existuje distributed ruby, embedded ruby (napr. soucasti html podobne jako PHP), modul do Apache, knihovny temer na vse (XML, CORBA, LDAP, GTK, Gnome, Curses, DBI, ...)

- existuje irb - interactive ruby - shell pro interaktivni spousteni vyrazu v Ruby:
$ irb
irb(main):001:0 1+2
3
irb(main):002:0 class Foo
irb(main):003:1 def foo
irb(main):004:2 print 1
irb(main):005:2 end
irb(main):006:1 end
nil
irb(main):007:0 a = Foo.new
...

A nyni odpoved na Vase otazky. Syntaxi ma jednoduchou - naucil jsem se ho velmi sluzne za jediny den. V Japonsku v oblibe predbehl Python a dohani Perl, jinde ve svete oba jazyky zbesilym tempem stiha. Vezmeme-li v uvahu jeho stari, ze za nim nestoji zadna medialni hysterie a jeho obrovskou konkurenci, je az neuveritelne, jak rychle ziskava priznivce. Pred Rubym jsem programoval v osmi jazycich (take v Jave), ale Ruby je prvni jazyk do ktereho jsem se zamiloval. Nyni programuji v Perlu, C, Ruby a PHP a moc se tesim, az to vsechno nahradim pomoci Ruby a C - v C super optimalizovane knihovny a v Ruby konsolove, desktopove a webove aplikace nad temito knihovnami.

Tenle web je fakt genialne naprogramovanej - urizlo mi to pulku textu. Omlouvam se za formatovani - chybi odsazovani. Tohle mi to sezralo:


- prenositelny - bezi na vsech platformach; dokonce i na dosu podporuje thready velikost zakladnich nainstalovanych baliku v KB:

$ dpkg -p ruby libruby | grep Installed-Size
Installed-Size: 248
Installed-Size: 1596

- vychytavky z popularnich jazyku - napr. z perlu regularni vyrazy, obracene if, map, ...
#! /usr/bin/ruby
# vyvolam metodu each_line objektu $stdin typu IO a predam mu blok
# to same, jako napr.: while line = gets do ....
$stdin.each_line do |line|
# obracene if, regularni vyraz, metoda strip objektu String
$stderr.print (line) if line.strip =~ /ahoj.*(\d+)cau/
print $1
end

- singleton metody - kazdy objekt muze mit sve vlastni metody, napr. eventy u tlacitek

- mix-in - tridy muzou includovat moduly a tim sdilet interface, napr. modul Enumerable prida trida nasledujici metody:
collect, detect, each_with_index, entries, find, find_all, grep, include?, map, max, member?, min, reject, select, sort, to_a
tento modul muzete includovat v kazde tride, ktera obsahuje metodu each

No vidíte, a máme tady nový krásný jazyk. Je dobře, že vznikají stále nové jazyky. Nikdo nemůže tvrdit, že Java je definitivní završení vývoje programovacích jazyků, že už nikdy nikdo nepřijde s něčím novým a lepším.

MS na to s jazykově nezávislým .NET jde dobře. Teď stačí naprogramovat kompilátor Ruby do Intermediate Language a máte plnou podporu Ruby v .NET. Eiffel už pro platformu .NET existuje, tak by to mohlo jít. Zkoumal jsem v posledních dnech pár programů v IL a zdá se mi, že IL je hodně nízkoúrovňový, že je to takový assembler s objekty.

Je třeba zdůraznit, že C# není pro .NET totéž co Java pro J2EE. .NET run-time není na C# vůbec závislé. Zřejmě by bylo možné udělat taky překladač Ruby do byte code JVM, ale Javovská platforma je tak silně optimalizovaná pro Javu, že by to asi vyžadovalo větší kompromisy než při překladu do IL .NET.

na zaklade coho konkretne si myslis, ze IL je hodne nizkourovnovy ? Co si skumal ? Prepac, ale moc sa mi nechce verit tomu, ze by MS dokazal vyprodukovat vrstvu ktora bude HW nezavisla, jazykovo nezavisla a pri tom na podstatne "nizsej urovni" (bez kompromisov v jednom z tychto kriterii) ako ina vrstva, ktora bola ako nizkourovnova s dorazom na HW nezavislost tiez navrhovana (tj. Java bytecode). Ano, IL bol navrhnuty s vedomim, ze ma podporovat viac jazykov. Ale tomu, ze bude bez zasadnych kompromisov umoznovat vyuzit vsetky moznosti tolkych jazykov (a ze bude v tomto nejako zasadne iny ako J.) proste neverim. Inak, ak chces Eiffel, pre JVM su k dispozicii 4 implementacie....

Jenom jsem si v IL disassembleru (ILDASM) prohlídl pár jednoduchých programů. Nejsem na to odborník, napsal jsem jenom, že je to můj pocit. Na první pohled to prostě vypadá jako objektový assembler.

Od byte code Javy se to liší tím, že to neobsahuje typy. Např. tam kde Java má Add int, Add double atd., IL má jenom jedno Add. Hejlsberg říká, že to je schválně, aby to mohlo pracovat s generickými typy - aby na tom mohli v budoucnu postavit podporu šablon funkcí atd.

Dále je stejný program v IL asi poloviční oproti byte code.

Jinak Java byte code byl navrhován s důrazem na HW nezávislost, ale současně s vědomím, že bude používán jen pro jeden jazyk a s cílem, aby se hodil primárně pro interpretované provádění. S kompilací se původně nepočítalo. Naproti tomu IL je výhradně kompilovaný (interpretovat by se ani nedal), jazykově nezávislý, HW nezávislý, do značné míry typově nezávislý.

 Neříkám, že IL je podstatně efektivnější, to nevím, ale je o několik let mladší a jeho tvůrci vyšli ze zkušeností s Javou. Malé programy jsou v něm kratší, zaberou méně paměti a jsou na stejném HW rychlejší. Ale není zatím testován pro velké aplikace, kdežto Java má za sebou šest let intenzívního vývoje.

"IL je výhradně kompilovaný (interpretovat by se ani nedal)"
ako to teda vlastne funguje ?
znamena to, ze IL kod je pred spustenim najprv kompletne skompilovany do nativneho kodu - az potom sa zacne cokolvek vykonavat ? - alebo sa kompiluje priebezne ??
"Malé programy jsou v něm kratší, zaberou méně paměti a jsou na stejném HW rychlejší"
Tou rychlostou myslis beh programu alebo cas startu programu ? (preco prave male programy ?) V com je IL kod rychlejsi ?

Kompliler jazyka (např. C# nebo VB.NET) vygeneruje IL. IL se před spuštěním vždycky přeloží do strojového kódu.

Možnosti jsou:

* Překlad předem. Musí být předem známa cílová platforma a moc se nedoporučuje.

* Překlad během instalace programu. To prodlužuje instalaci.

* Překlad za běhu programu - každá funkce je přeložena ve chvíli, kdy je poprvé volána. Používá se např. pro ASP.NET aplikace. Prodlužuje to první spuštění a první použití aplikace.

MS navíc dodává dva run-time kompilery IL - rychlý a optimalizující. Rychlý kompiler je v podstatě jednoduchý parser, který každý příkaz IL bleskově převede do dané sekvence příkazů assembleru.

Optimalizující kompiler překládá pomaleji a kód optimalizuje. Zatím je optimalizace poměrně omezená, v budoucnu se počítá s optimalizací šitou na míru pro konkrétní počítač. Bude to umožněno tím, že se překládá na tom počítači, na kterém program poběží.

To, že program .NET není nikdy interpretovaný, umožnilo navrhnout jednodušší IL i run-time. Například pointery v byte code Javy jsou vždycky nepřímé. Skutečně když zavoláš metodu mujObjekt.Proved, na kód metody JVM doskáče přes čtyři ukazatele - na ukazatel objektu, na objekt, na ukazatel metody, na metodu. A nedá se to nijak obejít, leda obejitím JVM. Kdežto v .NET je to jeden nebo dva skoky, nikdy čtyři. A nezáleží na jazyku.

Psal jsem, že rychlejší jsou malé programy, ale to jenom proto, že na velkých to ještě nikdo pořádně nesrovnával. Na malých programech to už srovnávali. Ale nešlo o nezávislé auditované testy atd. Zatím nebyla ostrá verze .NET.

btw.asi to s tym bytecodom nebude take zle, ked je na trhu uz aj convertor .Net aplikacii do Java bytecodu.. :) (http://www.halcyonsoft.com/products/iNET.asp)

Naprogramovat můžete cokoliv v čemkoliv, třeba interpretr céčka v Basicu. Jde o to, jak je to potom použitelné.

...alebo interpreter V.Basicu, Eiffelu, Pythonu, atd. v IL ? ;)

Samozřejmě, že můžete v IL udělat interpretr Pythonu.

Nepleťte si dvě věci:

1. Není možné, aby IL byl interpretován. To znamená, že kdyby se interpretovaný jazyk jako je Ruby převáděl do .NET platformy, musel by se z něho udělat jazyk kompilovaný. Což by určitě v podstatě šlo, ale možná za cenu určitých změn a omezení jazyka. Anebo za tu cenu, že by filozofická kompatibilita s .NET nebyla úplná, tj. že by se některé vybrané části programu udělaly ve speciálním p-kódu a pro ně by se udělal v IL interpretr. Byla by to zkrátka možná pakárna. Možná! Záleží na tom, o jaký jazyk by šlo, zkompilovat jde nakonec všechno.

2. Ale to vůbec nebrání tomu, aby se v IL naprogramoval nějaký interpretr.

Ruby - IL, mam pocit, ze se na necem podobnem pracuje
Ruby - Java, taky sem to nekde zahledl
Jinak jiz davno existuje ruby - C a podobne srandy.

v Ruby se mohou bez upravy pouzivat moduly a objekty z Pythonu,
staci includnout spec. modul.

Mam ale pocit, ze to vsechno nepujde bez orezani nekterych features. Prece jenom interpretovany jazyk (navic s hodne silnou syntaxi) je jina kategorie.

K technologii MS bych řekl asi toto, na této stránce se mi objevila tato chyba:

Microsoft OLE DB Provider for SQL Server error '80040e31'

Timeout expired

/mod_ListOfArticles/TodaysArticlesBox_INC.asp, line 24

Podle mě jsou technologie MS dobré. Já mám zkušenost s COM/DCOM a doporučil bych je jako kvalitní a spolehlivé.

Javu neznám, ale jak jsem ji viděl, tak vypadá jako velmi dobrý nápad, ale jak mi potvrdil i tenhle článek, Java již je pase a C# je dnes tím nejmodernějším, co lze v programovacích jazycích najít.

Jo a ta chyba se může stát při přetížení serveru, tak jako se stejně může stát pro server bežící Java aplikaci. Spíš je to o kvalitě a stylu programování.

Tak. A nakonec sem to musela uklidit ja.

Tak. A nakonec sem to musela uklidit ja.

Považuji za parádní, že tohle není klasická flame war, kde se člověk dozví akorát o pár nových vulgárních výrazech.

Tohle je diskuze jaká se mi líbí - obsahuje i užitečné informace.

Take jsem tomu rad a trochu jsem se toho pri psani clanku obaval. Ale jsem rad, ze si clovek mohl z teto diskuze i nektera pouceni a to i napriklad pri diskusi s Vami.

Mejte se.

Myslim si, ze uroven diskuze nastolila i jazykova uroven clanku.

Dekuji!

Pokusil jsem se o co nejlepsi pracim, a to jak ve zpracovani tematu, tak i po strance jazykove. Pritom mi pomohla moje nejblizsi, ktere timto dekuji za pomoc a omlouvam se za dodatecne chyby , ktere jdou jen na muj vrub.

Autor ma pravdu s tim, jak pise, ze SAP vyfakoval MS, kdyz prijal Javu za vlastni. Vypada to, ze pro MS to byla dost neprijemna rana, IMHO ma smulu a muze se jit v ERP klouzat. Jo a ten link na toho japonskyho provajdra je taky drsnej, jak jsem u nich nasel na webu, tak maji skoro 30 milionu instalaci javy v mobilech - to je fakt narez

Zdravim!

Urcite mate v tomto prozaickem prispevku pravdu. Pro Microsoft to neni nikterak prijemne, ze jeden z nejvyznamnejsich dodavatelu "enterprise" systemu ma jako hlavni podporovanou technologii (spolecne s ABAP) Javu.

Osobne si ale myslim, ze SAP zustane v dobrem kontaktu s Microsoftem a budou spolecne dodavat reseni (proste penize jsou penize). Spis je to hodne neprijemny marketingovy signal pro vedouci projektu, kterym se neprimo rika, ze technologie, ktere lze zatim verit je Java a ne .NET. A to je HODNE neprijemne, ptz to Microsoft bude stat moc penez, aby zmenil nazor excutivnich manazeru.

To myslím vůbec nic neznamená. SAP je samozřejmě kompatibilní s COM+ i .NET, jenom při interním programování SAPu se použije Java. Což je od SAPu správné rozhodnutí, taky bych použil Javu. Na kompatibilitu s venkem to nemá žádný vliv.

Prostě protože Sun SAPu vůbec nekonkuruje a konkurovat nebude, kdežto MS - kdo ví... MS už má vlastní ERP software Great Plains, což je nižší kategorie než SAP, asi tak na úrovni Navisionu.

SAP má v této chvíli problémy hlavně s Oraclem, který mu konkuruje přímo, proto SAP v poslední době podporuje MS SQL Server více než Oracle.

Podstatou platformy .NET je kompatibilita na úrovni SOAPu. Takže si myslím, že jde hlavně o to, aby SAP podporoval SOAP. A tomu snad nic nebrání. Osobně si myslím, že S(O)AP musí přijít.

Ja bych zase v tom SOAPu nebyl nijak optimisticky. Je to sice univerzalni technologie na provazovani sluzeb, ale je take VELMI pomala (je to logicky diky tomu, na cem je SOAP zalozen). Osobne si nedovedu predstavit, ze by napr. nejaky transakcni system bezel pres SOAP, kdy je nutne zpracovavat tisice transakci v minute. I ty nejoptimistictejsi testy mluvi v pripade SOAP max o stovkach transakci a to je jeste kdyz jsou to silne optimalizovane operace na vykon a v pripade nasazeni silneho hardware. Podle meho nazoru je mito SOAP a Web Service ve sluzbach, jako je napr. jednorazove dotazovani portalu na pocaci (dotaz na nejakou meteorologickou sluzbu). To je podle me ok, ale na to, aby napr. Seznam posilal s kazdym requestem dotaz i pres SOAP na aktualni stav a predpoved, to podle mne nikdy nebude  Proto i u SAPu (ne SOAPu ) bych tomu zas tak neveril.

Já myslím, že SOAP se výborně hodí např. na elektronickou komunikaci mezi firmami - výměnu dodáků, faktur atd.

joo tak na to bych to videl taky ale jen v pripade ze to bude mensi firma

predstavte si ze treba takovy tesco prorve skrz svuj system nekolik tisic takovych faktur dodaku storna reklamace dodavatelum atakdal - preci jen tohle resi jine systemy a efektivneji

zkratka ja myslim ze to je hlavne marketing kolem soapu, nic vic nic min - jsou mnohem zajimavejsi technologie

Několik tisíc faktur za jakou dobu? Třeba za deset minut? Několik tisíc faktur za deset minut je přes SOAP sranda.

Uvědomte si, že firmy této velikosti dnes už nezřídka používají systémy výměny dat založené na XML a HTTP přenosu.

Například já mám zkušenost s vývojem aplikací B2B. Dělali jsme jednu s CommerceOne a byla určena pro obchodování s kancelářskými potřebami v Kanadě. Bylo na ní hlášeno cca 1000 velkých podniků, kde si objednávalo v miliónech kusech. Přitom systém nebyl založen tak, že by podniky nakupovali ve velkém, ale systém byl integrován do jejich podnikových systémů a umožňoval realizovat nákupy podle aktuálních potřeb oddělení. A celý systém generoval desetitisíce objednávek každý den. Systém běham na COM/DCOM a i tak byla jeho rychlost velmi špatná a bylo nutné posilovat železo a to dost mohutně. Kdyby podobný systém běhal se SOAPem, tak je to nepoužitelné. Už i tak tam byly minimalizované všechny parsovací a kontrolní operace, aby se co nejvíce zvýšila efektivita systému.

Takže já osobně nevěřím, že SOAP bude běhat nějak rychle. I jednou jsem byl na prezentaci SOAPu v Německu a přednášející pořád odbíhal od odpovědi, jak rychle může SOAP zpracovávat transakce. NIKDO mi nepodal nepodal nějakou konkrétní a jasnou odpověď.

Podle mě ta bublina se SOAPem hodně rychle praskne, hned jak se to začne používat v praxi.

Ty systémy u těch vzdálených firem byly s centrálou propojeny přes DCOM? Tisíc podniků bylo připojeno přes DCOM? Přes Internet nebo přes WAN? A jakou mají latenci???

Promiňte, ale to mi nepřipadá jako dobrý návrh. DCOM se na to nehodí a myslím si, že SOAP by v této konfiguraci mohl být klidně i podstatně výkonnější. Protože je bezestavový, nemusíte všechna spojení trvale udržovat. Když objednává tisíc firem, tak to v praxi znamená, že jich obvykle objednává tak deset najednou. Čili stavový protokol - DCOM, CORBA ap. - drží tisíc spojení, zatímco bezestavový - jako je SOAP - pouze deset.

Je to jako s webem. Když má webový magazín tisíc čtenářů, co to je? Nic. Protože najednou jich to bude číst nejvýš tak sto a najednou bude nahrávat stránku tak deset. Čili jednoprocesorové PC a jsme vysmátí - a klidně zvládne i kryptování přes SSL.

Ale kdyby mělo být tisíc klientů připojených přes sdílení souborů přes NetBEUI nebo NFS bude to půšvih. I čtyřprocesorový unixový high-end server by s tím mohl mít dost práce. Novell by to zvládl na jednom procesoru, ale také by se zapotil daleko, daleko víc, než kdyby to zpracovával web server.

A myslíte, že kdyby ty firmy nebyly propojeny svými IS, ale přistupovaly do Commerce One jenom přes web, bylo by potřeba tak výkonné HW? Myslím, že zdaleka ne.

A to je právě kouzlo SOAPu - SOAP je o tom, že IS mohou mezi sebou komunikovat JAKOBY TO BYLY WEBY. Proto by (teoreticky!) nemusel mít potíže se škálováním.

Ale samozřejmě záleží na konkrétní implementaci. A já netvrdím, že ta od MS je výkonná.

Ale víte, co se pro B2B používá nejvíc? EDI! A na protokolech jako je X25. Jsou to propojené IS a běhá to v podstatě na mailu. Není vůbec výjimkou, kdy si ve velké firmě hezky dávkově pomaličku odpočítávají zprávy mašiny jako jsou IBM A 400. Takže na čem záleží? Zkuste o tom přemýšlet.

Ten systém byl založen na real-time připojení jednotlivých systémů s tím obchodním B2B centrem. Byla to v podstatě VPN, kdy jednotlivé firmy byly připojeny vysokorychlostními sítěmi k centru. Přitom k každý moment tam někdo něco nakupoval. Nebylo tedy pripojeno jen třeba 10 firem v okamžiku, ale všechny najednou. Když si vezmete několik gigantických průmyslových podniků v německu a zjistíte jejich potřeby na kancelářské potřeby, tak každý den je to obrovská suma a velké množství transakcí. A to tenhle systém integroval a díky němu se těm firmám snižovali náklady na provoz.

Jinak jiné řešení než DCOM nepřipadalo v úvahu, protože kdyby to mělo být přes SOAP, tak to bude děsný. Testovali jsme XML RPC (v podstatě předchůdce SOAP) a efektivita v porovnaní se stávajícím řešením v DCOM byla řádově 10x-20x horší, takže jsme od toho okamžitě upustili.

Proto pořád pokládám humbuk kolem SOAP jen a jen za marketingovou snahu firem jako je IBM, Microsoft apod., které se snaží vytvořit zase jakoby průlomovou technologii a na tom rýžovat další peníze. Jen chtějí donutit klienty k tomu, aby znova investovali peníze do vývoje něčeho, co už třeba mají a funguje to dokonce lépe než tyhle "inovace".

SOAP je ještě hodně málo otestovaný, ještě dnes by bylo moc brzy na něm stavět větší distribuovaná řešení. XML-RPC je skutečně předchůdce SOAPu, vždyť SOAP se původně jmenoval XML-RPC++. Ale XML-RPC nikdy nebyl dál, než ve stavu, který odpovídá alfě.

Netvrdím, že SOAP JE výkonný. Tvrdím, že by MOHL BÝT výkonný. Myslím, že teoretické předpoklady pro to celkem má. Ale záleží na implementaci a chce to možná ještě dlouhý vývoj.

Ahoj
mno nejsem programator z praxe - jen admin ,nicmene psal jsem si nejake definice interface a zprovozneni interfacu - a musim rici to co rikali predemnou -

soap neresi prenosovou vrstu a je zavisly na webovem serveru -
do tedka jsem jako interface pouzival perlove scripty (argumenty se predavaly prez get nebo post - navratova hodnota byla webova stranka) napsat xml - wsdl definici tohoto interface pro zakladni spousteni funkci a navratove hodnoty mi prislo tezsi ,nez to co jsem pouzival a tak tak jsem o SOAPU zase utekl


ale abych jen nekritizoval -na soapu me fascinuje jakymy spusoby dokaze prenaset pozadavek - videl jsem jako transportni vrstvu i SMTP - coz mi pripadne u vzdaleneho spousteni procedur jako dobra silenost :))))

:)))) btw definice corby interface v idl je stejne jednodussi :)))))))

zdarek

ja zase programator jsem a soap me taky vubec nenatchnul. podle me to je jen marketingova bublina ktera splachne tak rychle jak rychle se zacne soap pouzivat, testoval jsem to pro javu, pro perl ale i pro c# a rychlost je udesna

nechapu proc se zavadi tahle udesnost. uz predtim nekdo vymyslel corbu a ta je neprekonana - jednoducha, beha svizne a neni to na nikom zavisly - nikdy bych do soapu nesel ale asi se najde nejaky blazen co do toho da prachy - ja to ale nikomu nedoporucim

CORBA a SOAP jsou vhodné pro různé věci. CORBA je totiž na Internetu použitelná jen velmi obtížn a neefektivně, zato SOAP je na to ideální. Technologií velmi podobnou CORBě je na MS technologiích už léta COM.

CORBa vzžaduje udržování stavu a hodí se na real-time věci. Jakmile server není schopen reagovat na požadavky (alespoň téměř) v reálném čase a není schopen udržovat každé spojení relativně dlouhodobě naživu, je výkon CORBy ubohý. Kdežto SOAP je technologie bezestavová a má velice malý síťový overhead.

Není náhoda, že SOAP propaguje i Sun, IBM a další.

Jak může být CORBe podobný COM, když CORBA je o distribiovaném programování? Snad DCOM ne?

To už se dnes tak nerozlišuje.  COM a DCOM se z programátorského hlediska vůbec neliší, každá aplikace používající COM umí automaticky i DCOM (i když ne vždy optimálně). Termíny COM, DCOM a COM+ se zaměňují, já obvykle píšu COM myslím COM+ a i v článcích od lidí z MS se běžně píše COM a myslí se DCOM nebo COM+

Úplně přesně bych měl psát o COM+, protože to zahrnuje COM i DCOM.

DCOM se jim ale moc nepovedl, mnozí vývojáři a softwaroví architekti se těší na SOAP jako na spásu. Tam je hlavně daleko, daleko jednodušší konfigurace. DCOM se velmi snadno programuje, ale konfigurace je strašlivá a výkon je slušný jenom na lokální síti.

Ahoj
dovolim si trosku nesoulasit :)

akmile server není schopen reagovat na požadavky (alespoň téměř) v reálném čase a není schopen udržovat každé spojení relativně dlouhodobě naživu, je výkon CORBy ubohý. Kdežto SOAP je technologie bezestavová a má velice malý síťový overhead.

hmm bohuzel mam opacne zkusenosti se SOAPem - mel jsem funkce ,jejihz vykonani bylo otazkou 1min + ,bohuzel webserver mi po urcite dobe hodi timeout(cimz ovsem se neposle odpoved...-web neni primarne prece urceny na spojeni radove v minutach..) zkousel jsem nastavit delsi timeouty na servru ,ale tohle reseni neni prave koser (takze jsem od soapu utekl)


btw CORBA slouzi pro vytvareni interface i na win platformach - dodavky firmy nokie pro gsm tech - dcom,soap jsem nikde -ani na win pl. - u nas ,zatim nevidel...

Tak konec plodnech debat a tahne si po sobe uklidit ten svincik !!!! Cunata !!!!

Zdravim,

v porovnavacej tabulke som nenasiel (alebo si nevsimol) podporu parametrizovanych typov v oboch jazykoch. Osobne by som v Jave privital moznost definovania template tried (funkcii) na sposob C++, ktore by casto nahradili nutnost pretypovavania (a tym zrychlili rychlost a bezpecnost systemu).

Ma C# podporu pre templates?

Dobry den!

Mohu se presne zeptat co mate na mysli terminem "parametrizovane typy"? Pokud se jedna o sablony, tak to zel asi mame smulu. Je to mozna proto, ze sablony se v C++ objevili dost pozde a jsou dosti specificke pro kazdy prekladac (treba u starsich verzi Visual C++ v porovnani s novymi je hodne omezeni a to nemluvim napr. o gcc). Krome toho, obvykle se sablony pisi do hlavickovych souboru a ty v C# neexistuji.

Co s Javy tyka, tak podpora parametrizovanych typov sa chysta: http://www.jcp.org/jsr/detail/14.jsp, resp. http://www.jcp.org/jsr/results/14-7-1.jsp

Aha, i ja dekuji S tim, jak jsem zvykly stale uvazovat v anglicke terminologii mi nekdy nedojde tak zrejma vec jako jste zminil
Diky za prispevek a upresneni.

Generické typy prý měly původně v IL a v C# být, ale pak byly přesunuty do další (budoucí) verze. To je ale zdroj Jedna paní povídala.

Každopádně by jejich implementace - díky tomu, že IL používá netypované proměnné - měla být snadná, snadnější než v Javě. Udělali to tak záměrně mimo jiné právě s výhledem na generické typy. Dá se říci, že IL je na to připraven.

Zdravim vsetkych,
po precitani prispevkov si viacery diskutujuci neuvedomuju kde je najvacsi rozdiel medzi JAVA a C#. Rozdiel medzi SUN a MS je v pristupe k technologiam. SUN vytvoril jazyk ktory by mal byt BEZPECNY a ma byt postaveny na dobrych zakladoch. To je dovod preco neexistuje #define, preprocesor, "unsafe",pointers a podobne.

MS urobil jazyk tak ze zobral JAVA a pridal k nej veci co programatori chceli. MS nechce urobit dobry, kvalitny a bezpecny jazyk (resp. cele prostredie NET) ale chce ziskat co najvacsi trh. Preto dovoluje miesat jazyky ako C# a VB do jednej .NET aplikacie. To sice pomoze urobit aplikacie rychlo a lacno ale tie aplikacie nebudu tak bezpecne ako aplikacie napisane v JAVA.

Dekuji za Vas dobry prispevek. Myslim si, ze jste to trefne shrnul a prijde mi, ze jsem mohl udelat totez aniz bych travil dlouhe hodiny pri psani a promysleni sveho clanku

Mejte se.

SUN vytvoril jazyk ktory by mal byt BEZPECNY a ma byt postaveny na dobrych zakladoch. To je dovod preco neexistuje #define, preprocesor, "unsafe",pointers a podobne.

Java je ciste high-level jazyk, takze ma zakonite omezene schopnosti. C# si muze delat co chce - ale nikdo te nenuti to pouzivat. C# bez unsafe kodu je stejne bezpecne jako Java. Navic kazda pasaz unsafe kodu je oznacena a lehce dohledatelna pri vyskytu problemu. Java je striktne polozena na jednoduchosti a bezpecnosti ale zaroven nam striktne vnucuje jejich nevyhody. C# ti dava vybrat mezi bezpecim a svobodou. Java ti vnuti bezpeci.

Nedostatecnost Javy v low-level manipulaci byla zaplacnuta pomoci JNI, ktery je jeste nebezpecnejsi nez unsafe kod.

Dale by me zajimalo co je nebezpecneho na preprocesoru ? Tato funkce musi v Jave citelne chybet.

MS urobil jazyk tak ze zobral JAVA a pridal k nej veci co programatori chceli. MS nechce urobit dobry, kvalitny a bezpecny jazyk (resp. cele prostredie NET) ale chce ziskat co najvacsi trh.

Jo takze podle tebe by se melo kaslat na to, co programatori chteji ? Chces jim proti jejich vuli nacpat Javu, protoze jsi nejchytrejsi na svete a rozhodnes to za ne ?

Preto dovoluje miesat jazyky ako C# a VB do jednej .NET aplikacie.

Dovoluje to proto, aby si kazdy mohl vybrat svuj jazyk a snadno sve vytvory integrovat s produkty v jinych jazycich a aby mohly vsechny jazyky jednoduse pouzivat spolecne knihovny a aby stacilo vytvorit jediny runtime pro skoro jakykoliv jazyk. Nejaky problem ?

To sice pomoze urobit aplikacie rychlo a lacno ale tie aplikacie nebudu tak bezpecne ako aplikacie napisane v JAVA.

Mohl bys nam vysvetlit o co je Java bezpecnejsi nez managed C# ?

Vo tom, co se tyce bezpecnosti, tak diky checked exceptions je C# min bezpecny nez Java. Zajimavy bude urcite porovnani security features, jako je SecurityManager v jave. Jestli pak je neco podobnyho v c#?

Jinak jsme zvedavej, jak bude C# reflektovat prani programatoru, moooc zvedavej.

Posledni poznamka, docela by me zajimalo, jestli od C# muzu dostat zdrojaky, tak jako od Javy. Protoze kdyz si s necim nejsem jistej, tak se mrknu do zdrojaku. (to je taky bezpecnostni feature, nicmene tohle M$ jeste nepochopil).

Tak to bych rad videl zdrojaky Java 2D knihovny, ty jsem totiz nesehnal. Konkretne me zajimaji zdrojaky and-ovani dvou obecnych path s bezierovkama

No, jenze od kdy je Java2D soucasti normalniho JDK? Co ja vim, tak je to extension, takze o tom nebyla ani neni rec. TO je jako kdyby M$ daval zdrojaky od C#, ale dalsi by po nem chteli zdrojaky napr. od directX.

Sorry, tady jsem ulit. Soucasti je uz od JDK 1.2. Takze co ze te to zajimalo ? Presne jaka trida ? Je to v package java.awt.geom ? Jaka konkretne trida ? Ja tuhle package kazdopadne ve zdrojakach mam a pokud je mi znamo, tak by zdrojaky mely bejt soucasti kazdyho JDK od Sun.

Ta funkce kterou ja chci je konkretne java.awt.geom.Area.add ale kdyz se podivas na tu funkci od ktere tam opravdu implementace je tak zjistis ze to jen vola metodu tridy sun.awt.geom.AreaOp ale od te uz tam zdrojaky nejsou! Tedy to, ze mas v Jave od vseho zdrojaky je ciste virtualni vec. Jsou tam jen zdrojaky od zaobalovacich funkci, ci jen velmi jednoduchych a to ti tak velky pocit security neprida ...

To je fakt, to jsem si nevsimnul. Tak to sorry. Mozna ze bys to mohl vyhrabat pres javap nebo tak nejak pokud to potrebujes vazne.

Na druhou stranu veci co se tykaji streamu jsou tam az na uroven volani native knihovny, takze to neni tak uplne spatny. String i Collections jsou tam myslim taky cely - proste i kdyz to neni open source projekt, tak tech informaci je tam docela dost a je to furt lepsi nez nejaka pochybny knihovny z woknous, ktery bude C# volat.

Jo tak jsem to nasel na googlu prvni odkaz kdyz das vyhledat sun.awt.geom vrele doporucuji tech zdrojaku od 1.3 je tam pres 30MB opravdu dost cool, ze jim to takhle prosaklo ...
V podstate to jsou zdrojaky nejrozsahlejsi a asi nejmodernejsi knihovny funkci, klobouk dolu pred autory ...

pouzivej open-source nastroje

Je iba na tebe, ci pouzijes managed alebo unmanaged code (ale unsafe a safe) - a je jedno, aky jazyk pouzivas...

Autir píše, že ".NET je postaveno kolem C#". To je naprostá blbost. .NET není jazykově závislé. Nejlepším důkazem je, že C# je úplně stejně silný jako Visual Basic.NET a můžete s ním dělat, až na detaily stejné věci - máte stejný framework, stejný runtime, stejné datové typy, stejné výjimky, stejnou dědičnost a po přeložení stejný výkon.

C# samozřejmě je kopie Javy pro .NET, úplně stejně jako je VB.NET kopií VB pro .NET. Pokud vím, někdo udělal i Javu.NET. Podstata platformy .NET je v něčem úplně jiném, a C# s ní stojí a padá. Pokud to bude výborný jazyk, ale platforma .NET se neujme, tak C# prostě chcípne.

To samé platí pro Javu. Sunovská Java je jak jazyk (jako C#) tak platforma (jako .NET). Pokud chcípne J2EE a nikdo nebude dělat applety, Java zmizí.

Zdravim!

Mate i nemate pravdu - .NET je jazykove nezavysle prostredi, jak jsem take uvedl (viz. treti odstavec uprostred). Ale patrne jsem pouzil nepresny vyraz a doslo k nepochopeni. .NET skutecne stavi vse kolem C# a to ne, ze by to mel byt jediny pouzitelny jazyk, ale je to "prosazovany". Je integrovan do vsech sluzeb, co jsou na .NET zalozeny a stava se hlavnim tahounem .NET marketingu.

Takze kdyz si clanek predctete pozorne, tak uvidite, ze netvrdim, ze C# je JEDINY jazyk v .NET (viz. odkaz zmineny vyse), ale dominantni.

Ne, myslím, že nemáte pravdu. Z čeho usuzujete, že je C# prosazován? Možná v marketingu zaměřeném na Javovou komunitu, nebo proto, že je vidět jako novinka. Celkově však takový pocit nemám. Naopak mám pocit, že tím prosazovaným jazykem je Visual Basic, protože k němu najdete více .NET samplů, více knih o přechodu na .NET atd. Microsoft je, pokud jde o jazyky, tvrdě neutrální.

Jiz pri uvadeni C# ke standardizaci Microsoft prohlasil, ze C# je hlavni a klicova technologie pro .NET. Zel nemam ten link, ale je zde takove reziduum na ukonceni procesu a zde se to zminuje jiz jen uvodem.
http://www.microsoft.com/presspass/Press/2001/Dec01/12-13ECMAPR.asp
Dalsi link je od jednoho z autoru C# a vyvojare .NET architektury, znameho Hejlsberga, ktery C# take oznacil za hlavni smer ve vyvoji .NET aplikaci.
http://windows.oreilly.com/news/hejlsberg_0800.html

Co se tyka prikladu, tak to mate mozna pravdu, ptz zatim je zde stale vice programatoru ve VB. To je ale z historickych duvodu a lze vic nez predpokladat, ze jakmile se C# uchyti, bude tech prikladu vic nez dost. A to proto, ze podle me C# nejen ze sikovne kombinuje silu C/C++, ale dobre vlastnosti z VB. Proto na nej asi prejde cas komunity C++ ale i VB programatoru.

Ne, ne a ne . Promiňte, ale myslím, že jste si dostatečně neuvědomil rozdíl mezi technologií (.NET) a jazykem (C#).

C# není technologie. C# je jazyk. Jazyk naprosto stejně silný jako VB.NET. Prosím o přesné citace - v tom linku není nic o tom, že bude C# upřednostněn před jinými jazyky. Ani nemá smysl takto uvažovat, když je jeden jazyk na druhý převoditelný pomalu přes preprocesor.

Co si uživatelé nakonec vyberou, to je druhá věc. My máme ve firmě 20 VB vývojářů (hodně dobrých, dělajících na serverových aplikacích podobných jako J2EE), a v hlasování, jaký jazyk pro .NET bude firma používat, zvítězil s jasnou převahou C#. S jasnými důvody: funkčně je to to samé jako VB.NET, ale zapíše se to na méně znaků.

Ale v celé koncepci .NET nehraje žádný jazyk významnou roli. Jde o to, co je za tím, a to je 100% jazykově nezávislé.

Ano, ano a ano  (pokus jen o negaci moznych nedorozumeni ).

Velmi dobre vim co muze a nemuze delat .NET a jake jsou vlasnosti jazyka C#. Jak bylo uvedeno v uvodu clanku, delam s touto technologii od jejiho prvniho rozbresku. Co se tyka toho co popisujete, tak mate urcite pravdu - tedy v rovine teoreticke. Ano, .NET jako framework je multilingualni zalezitost a MEL by byt pouzitelny pro vsechny podporovane jazyky. Ale pokud znate architekturu CRL tak vite, ze neni VUBEC snadne nejaky dalsi jazyk k .NET privazat. NAOPAK je to velmi problematicke a muze to znamenat hodne problemu pro system. Zel nemohu ted primo rici, ze se to v pripade nekterych funkci nedari, ale pokusim se najit odpovidaji odkazy, kde se tato problematika resi a kde jsou uvedeny problemy s provazovani vice aplikaci v ruznych jazicich. Ja sam jsem zazil, kdyz jsme takto provazovali C++, C# a Cobol, ze nekolikrat doslo ke zhrouceni systemu (jednalo se o rozsahnou aplikaci radove o hodnote prace 3000 clovekodni).

Osobne bych v tomto byl skepticky (aspon pozdeji mohu byt prijemne prekvapen), ptz me osobne toto pripomina proklamace Sunu o tom, jak Java pobezi bez problemu na jakemkoliv systemu. Ano, teoreticky je to VELMI snadne, ale v praxi najednou to nefunguje (dnes jiz je situace MNOHEM lepsi, ale stalo to 6 let prace). Proto byt Vami, budu v tomto opatrny a radeji si projedu nezavisle testy a technologii si sam odzkousim, nez verit slibum.

No, nedivím se, že to padalo. Vždyť to taky nebyla ostrá verze. My jsme také v listopadu zkoušeli převést rozsáhlý projekt na .NET, a nešlo to, takže jsme další verzi ještě dělali "postaru". A to šlo o VB, ne o C++ nebo Cobol, tam to bude chtít ještě nějakou tu verzičku počkat.

A pokud jde o ty jazyky, vždyť kromě C# už reálně existuje VB.NET, JavaScript, Java, Pascal atd (managed C++ nepočítám, to je prasárna). Problém je, že každý jazyk pro .NET se musí prostě přizpůsobit, pokud má pracovat přímo na úrovni CLR. Nebo, pokud se nepřizpůsobí, musí mít rozsáhlý run-time a nebude tak efektivní.

No neni to tak presne, ze by to nebyla ostra verze. Vzhledem k tomu, ze se jednalo o jednu ze zasadnich financnich instituci v Evrope, vysel nam Microsoft vic nez vstrict a my jsme se spojili s jeho internim tymem a konzultatny a integrovali jsme neco jako jiz "ostrou" verzi (neotestovana, ale jiz pripravena k uvoleni do testovani). Byla to vlastne ta verze, kterou ted muzete videt a ktera je dispozici (stejne jako i verze VS.NET co nyni MS uvolnil).

Tak si říkám, že .NET vlastně má jenom jeden jazyk - IL. (Intermediate language - obdoba bytecode v Javě.) Ostatní jazyky převádějí kód do IL. To ale znamená, že aby byly efektivní, nemohou se od ILM podstatně lišit.

Je to ostatně dobře vidět na Visual Basicu.NET - aby měl pro .NET smysl, byl doplněn o prvky, které mají přímou podporu v IL. A věci, které podporu v IL nemají, např. vícenásobná dědičnost (ne, že by se bez ní nedalo obejít), mají smůlu, resp. šly by realizovat velmi obtížně a lepší se bez nich obejít.

Proto je C# skutečně nejefektivnější jazyk pro .NET:

1. Nejvíc se podobá IL.

2. Jsou v něm napsány objektové knihovny .NET.

Ale abych to zase zrelativizoval - stejně je to nakonec všechno v assembleru a je vidět, že rozdíly ve strojovém kódu na různých platformách nemají na podporu high-level jazyků téměř žádný vliv. Takže jde o to, jak moc je IL low-level jazyk.

IL je hodně low-level. Díval jsem se na pár programů. Hraji si s VS. NET a zatím se mi to velice líbí. Akorát mohli víc dotáhnout grafický návrh webových formulářů, je to tam hodně primitivní. Ale grafici budou stejně používat něco jiného, nějaký Dreamweaver...

ok, ponuka a pracu pre programatorov v Jave vyrazne prevysuje ponuku na napr. C++, ale:

- su 3 druhy klamstiev: lzi, spinave lzi a statistiky

- kolko funkcnych aplikacii (myslim tym realne pouzitelnych, nie nejake VB, Java tetrisy a podobne zlataniny) si stiahnem v Jave a kolko v C++?

- vacsina Java aplikacii su rozne servlety, applety (aj tie uz vytlacil Flash ako progr. nastroj)

- nie kazdy ma P8 Tennesee @ 10GHz aby mohol bez kliatia seriozne pracovat ...

Tym nechcem nic odsudzovat alebo obhajovat, len sa snazim triezvo pozriet na vec - "Xce to klud a nohy v teple!" ako hovori klasik

PS: to ze M$ sproste okopiroval nieciu technologiu ja  T O T A L  H N U S ™ !

Dekuji za prispevek a souhlasim, ze desktopovych aplikaci neni v Jave nijak moc, presneji - skoro zadne rozsirene nejsou. Je to pochopitelne, ptz k Jave potrebujete pomerne velky runtime (pres 10MB), kdezto u standardnich Windows-based systemu tomu tak neni, ptz runtime je jiz v OSu. Proto se malokdo pousti do takovych aplikaci, ptz se da stezi predpokladat, ze by se masove sirili.

Mnohem vice se siri klientske aplikace na zakazku, kde je mozne nainstalovat rozsireni systemu. Presto se da ocekavat zasadni zmena a to objevenim se knihoven jako jsou napriklad SWT. Ty jsou jiz plne systemove optimalizovane, a rychlost Java aplikaci na nich zalozenych, je srovnatelne s jinymi kompilovanymi prostredimi.

Je to pravda, ale obávám se, že nebude mnoho ani desktop aplikací v .NET. My už jsme na to narazili - chtěli jsme vyvíjet desktop aplikaci v .NET - moc věcí by nám to usnadnilo - ale museli jsme couvnout kvůli systémovým požadavkům (96 MB RAM).

Ale myslím si, že .NET bude na Windows desktopu přece jenom použitelnější, než Java. Přece jenom desktop aplikace v Javě je psychologicky pomalá VŽDYCKY - na jakémkoliv HW. Kdežto Visual Studio .NET, jehož UI je prý napsané v managed režimu .NET (ale nevím to jistě, je to každopádně aplikace mixovaná - část běží v managed a část v unmanaged režimu), běželo v beta verzi perfektně použitelně na 400MHz celeronu se 128 MB paměti (osobně jsem zkoušel).

MS prostě tradičně umí desktopy, Sun umí servery.

Podle me se shodneme. Ja take mel podobnou zkusenost s .NET desktopem, ktery jsme delali pro jednu financni instituci ze zahranici a oni od toho odstoupili ve chvili, kdy se dozvedeli jake jsou systemove naroky (nakonec se to UI delalo v DHTML a behalo to super ).

Co se tyka desktopu v jave tak tam vidim budoucnost srovnatelnou s jinymi prostredimi. Jak jiz jsem zminil, IBM uvedla SWT knihovny. Ty jsou naspane pro dany system s nativnim renderingem (uz to neni ta zrudnost ze Swingu, kde se prorendrovala kazda komponenta) a beha to fakt rychle. Take nova verze JDK by mela jit timto smerem. Proto si myslim, ze za jak Sun tak i MS se budou v budoucni prolinat v obou typech systemu - v desktopu tak i serverech.

Na jave se mi nelibi:

Nejednostnost v pristupu k nekterym funkcim (properties) jako napr velikost - Vector.size(), String.length(), pole.length, NodeList.getLength(). Jedna se typove o tutez funkci, proc ji autori nepojmenovali stejne - tim vznika akorad bordel a zmatek.

Streamy jsou v "objektovem" jazyku java dovedeny do absurdity.  Nemaji spolecneho rodice, aby s nimy mohlo byt pracovano transparentne. Pak vznikaji redundantni kody s vidlicemi na InputStream, Reader a pod.

Nastavovani nekterych vlastnosti skrze text mi prijde u kompilovaneho jazyka jako blbost.

Napr System.getProperties().put("proxyHost", "192.168.0.1") kdy zadavam vlastnost objektu, ktery se pripojuje na proxinu, v podobe textu proxyHost. Proc to neudelali jako vlastnost URL nebo URLConnection? Takovych vlastnosti je samozrejme vic a tim take vznika bordel, napr pri chybne zadanem textu kompilator pozna prd. Nestesti je to zvlaste u apache-xerces xml parseru, kterej ma definici prez text properties, prestoze ma podobne nazvane prislusne metody na nastaveni. (Jenze protected).

Tez mi vadi nedokumentovane objekty, myslel jsem si ze to je vlastnost pouze MS. V baliku sun.security jsou velmi uzitecne objekty na digitalni podpis, ale sun se holt tvari ze tam nejsou nebo co.

Rad bych slysel tez nejaky zapory o C#.

Zdravim!

To co zminujete je sporne, ale odpovim Vam na zapory C# (jinak jsou uvedeny v prehledu kdyz se porozorne podivate).

Jeden z velmi zasadnich, na co bylo vC# zapomenuto jsou "checked exception". Neboli v C# nemuzete donutit programatora k odchytavani chybovych stavu, jako je tomu v Jave. To je pak zasadni pro psani velkych aplikaci, kde provazujete nekolik modulu a jejich "zivotnost" je zavisla jeden na druhem a jediny zpusob co se Vam pak nabizi je kontrola "per huba" - tedy pouze si to v projektu domluvit.

Dalsi problem v C# je prace s plovouci radovou carku atd. Nechtel bych se tu opakovat, vse jsem presne zminil i odkazy na mozne zdroje ve svem clanku.

Jestli se v c# neda odchytit exception, tak nemohu rici nic jineho, nez ze to je pekne na hovno. No to snad ani...

Odchytavani exception a-la VB je taky dost hnusne, ale aspon tam je....

nejde o to, ci sa exceptiony daju odchytavat, ale ci sa ich odchytenie da programatorom vynutit. Je to ale zase skor otazka spravnych programatorskych postupov a korektneho a predvidatelneho chovania vytvoreneho kodu, t.j. veci, ktore mozno neurobia dojem na leniveho studenta informatiky, ale ktore su v praxi pri vyvoji velkych projektov dost dolezite...

Ne, to jste nepochopil správně. C# má samozřejmě odchytávání exceptions daleko lepší, než Visual Basic. Jde o to, že tam nemáte direktivu, která donutí programátory to dělat, tj. důsledně všude exceptions odchytávat. Asi jako když ve VB Scriptu dáte OPTION EXPLICIT, tak pak musíte deklarovat proměnné.

Ale pozor, ve vyšších verzích Visual Studia .NET je vlastnost Enterprise Templates, která umožňuje definovat velice podrobné šablony pro to, jak má (a musí) vypadat zdrojový kód. Ale jestli tam zrovna tohle, to nevím.

O tom se zmiňuje i ten srovnávací článek, který tady už někdo postnul (Java vs C#), a z toho jasně plyne, že na to autoři nezapomněli, ale nedali to tam záměrně, a jestli jsem to dobře pochopil, tak to bylo právě z důvodů velkých projektů. Neznám Javu, takže se neodvažuji posuzovat, zda to je správné nebo ne, jen chci opravit předchozí poznámku autora.

Dekuji, ale prave tahle vlasnost je nejvice kritizovana, co v C# chybi. Me tedy prijde (jak jsem napsal i v tom clanku) dost nestastne provedeny zpusob verzovani (jak jsem v videl na 2 velkych projektech tak se nikde neosvedcil a to i za asistence 2 konzultantu z MS).

Co se tyka "checked exception", tak opravdu neznam "enterprise" projekt, kde by se toho hojne nevyuzivalo. Kdyz si predstavim napr. internet-banking, na kterem pracujeme, bez teto vlastnosti, tak by nam to dost zavarilo. Pochopitelne bychom nasli nejakou cesticku kolem, ale tahle vlasnost nam hodne usnadnila a usnadnuje zivot. Podle meho nazoru, Microsoft udelal chybu, ze tam tuto vlastnost nedal - ale to ukaze asi az cas.

Podívejte se na ty Enterprise Templates ve Visual Studiu .NET (nejvyšší dvě verze). Je možné, že MS to nedali do platformy proto, že to chtějí prodávat jako přidanou hodnotu ve VS.

Ano, to je mozne, ze Microsoft bude postupne cast teto funkcnosti rozsirovat a prodavat ji s jinou licencni politikou. Ale to je je spekulace a to ja nevim.

V nejvyšší verzi Enterprise Architect můžete šablony vytvářet, ve verzi Enterprise Developer je jenom používat.

MS o tom stručně píše tady:

http://msdn.microsoft.com/vstudio/technical/articles/eft.asp

Ale o výjimkách jsem tam nic nenašel.

Tady je o tom článek:

http://www.dnjonline.com/articles/tools/iss28_reviews_vsnet_5.asp

Most organisations encourage or require developers to adhere to in-house design standards. Enterprise Templates make it easy for developers to follow these guidelines, both in specific details such as the fonts used for dialogs, and in higher-level issues such as the architecture of multi-tier applications. It really is a brilliant concept, although creating good templates is a major task in its own right.

Building a template consists of creating a prototype solution, then linking it to one or more policy files. Policy files are XML documents that conform to the TDL (Template Description Language) specification devised by Microsoft for this purpose. Judging from the beta, Microsoft isn’t providing much in the way of tools for editing TDL, so it’s a matter of working with the bare XML code and the TDL reference. However this may change before final release.

Spatne jsem to pochopil. Doslo k zamene odchytavani exception a pozadovani odchyceni exception.

V tom pripade bych to povazoval za klad, nebot to neustale buzerovani java kompilatoru ohledne odchytavani exception me dost toci. Preferuji styl jako v Delphi, kdy se o hlavni odchyceni postara aplikace a ostatni je na me. Mimo jine uz se mi v jave stalo, ze na windows me to odchytilo Exception a v AIXu ne, protoze tam to nehazelo Exception ale Throwable, ackoliv to melo hodit Exception...Hledal jsem to nekolik hodin kde to probublalo.

A taky bych nektere autory v jave nakopl, protoze se neobtezuji vyplnit message v Exception, ale smeruji se pouze podle nazvu tridy...

Chapu Vasi pripominku a problem s ladeni, ale nemyslim si, ze abychom my programatori meli snadnejsi zivot je dobra "pstrosi strategie". Neboli aby nas kompilator "neprudil", tak vyrusit nejakou vlasnost, ktera nas obtezuje.

I ja jsem zazil MOCKRAT situaci co popisujete, ale je mnohem lepsi resit, kde a jak nejaka exception vznikla, nez pozdeji louskat, proc mi ten system pada, kdyz me kompilator nikde preci neprudil

Ano i ne. Priklad:

Kdyz me bude otravovat compiler s tim ze je tam exception, tak nejjednodussi co muzu udelat je ze za definici procedury prdnu throws Exception a sme na stejnym jako v C# akorat ze me to obtezovalo a stejne myslenka checked exception byla ojebana.

A pokud me to chcipne na nejakou exception at uz v java nebo c#, tak to vraci celej callstack.

Tudiz, co je pracnejsi? Mimo jine, zpracovani vyjimek je casove dost narocna operace, takze pokud mi neco jede ve velkym cyklu a ja ojebavam rozumne napsanej kod tim, ze z lenosti tam napisu try-catch a exception odchytava moji lenost se zamyslet, tak vysledek je dosti zalostny v jave, v c# i v delphi.

Muj kolega vzdycky rikal, ze vyssi jazyky, nerkuli RAD GUI programovani vzdycky vede k tomu, ze zacne programovat kdejaka baba od plotny a pak ten vysledek stoji za pendrek.

Ano, muzete tam tzv. "prdnout" throws, ale jak jiz jsem napsal, lze velmi snadno dohledat kde a jak vyjimka probehla kdo ji pripadne nezpracoval. Takze pokud budete programovat style kod + throws, tak je hodne pravdepodobne, ze se s Vami Vas zamestnavatel rozlouci
Jinak chapu co mate na mysli a stejne je mozne argumentovat i pro nektere zalezitosti co v Jave chybi. Me osobne to je jedno a jedinym meritkem pro me je prakticka pouzitelnost a efektivita vyvoje a kvalita. A co jsem za tech 10 let poznal je, ze chovani jako "check exception" jsou hodne dulezite pro navrh systemu a jeho kvalitni implementaci.
To ale nic nemeni na tom, ze Vy mate jiny nazor a ja Vam jej neupiram a preji Vam k nemu hodne uspechu.

Opravdu velmi zajímavý článek.
O Javě jen houšť.

Děkuji

.NET platforma (tedy mj. i C#) má momentálně výrazně lepší podporu Web Services (na SOAPu založených webových služeb), než Java. Ale to Sun samozřejmě zase rychle dožene.

BTW: Asi před třemi dny byla uvedena ostrá verze Visual Sutia .NET, zatím jenom jako download pro předplatitele MSDN Univerzal. Krabicová verze bude v polovině února. Lze si už ale zdarma stáhnout finální .NET runtime pro Windows a vyvíjet v C# v textovém režimu.

Z toho je vidět, že zájem o programátory v C# nemůže být velký, protože ještě před pár dny existovala jenom beta. Navíc k programování v .NET úplně stačí znalost Visual Basicu. O jazyk totiž nejde, člověk musí zvládnout hlavně objektovou knihovnu.

V com ma .net lepsiu podporu web services ako Java ?
porovnania oboch v tejto otazke:
http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET
http://www.webservicesarchitect.com/content/articles/hanson01.asp

Ano, mate pravdu, Sun v tomto trochu zaspal, ale krome Sunu je zde mnoho dalsich firem, ktere naopak HODNE pokrocily. Napriklad Systinet patri mezi spicku a prekonava Microsoft, co do nabidky sluzeb. Dale IBM nebo HP jiz pracuji na Javovych verzich (HP ve sve Bluestone divizi), a to nemluvim tom, ze v Open Source existuji asi 3 velke projekty, ktere v Jave implementuji SOAP a Web Services.

Proto bych videl pozici Javy obdobou jako u MS, jak jsem jiz napsal ve svem clanku.

Inak vdaka Authorovi za clanok a hlavne Zive (za to, ze vynimocne uverejni aj kvalitny clanok od externeho autora, ktory veci rozumie)
Este par postrehov/otazok:
- mozno mohlo byt viac rozvedene v com spociva pribuznost Javy a .net-u (pretoze podoba syntaxe je iba kozmeticky detail - a z tohto hladiska by mal JerryIII pravdu (akoze nema)). Ale chapem, ze to je moc siroka tematika na kratky clanok...
- v tabulke je pri "standardizovano" uvedene u Javy "ne (patrn? nebude)" - snad by sa hodilo spomenut, ze o standardy suvisiace s Javou sa stara Java Comunity Process, ktory nie je len zalezitostou Sunu, zastupenie maju prakticky vsetky firmy vyznamne v oblasti Javy (BEA, IBM, Oracle, Borland..) a velku vahu maju aj samotni (nezavisli) vyvojari. Iste, situacia zo strany Sun-u nie je uplne idealna (ako je spomenute v clanku) - ale to uz je skor o konkurencnych vztahoch Sunu a IBM (a.i.) - cize : 100% nezavisly standardy nie su, ale na druhej strane JCP ma jasne definovanu filozofiu a zahrnuje prakticky celu plaformu (a nie iba cast, ako je to pri .Net-e)
- pri "Detekování p?ete?ení" je u Javy "ne" - neviem presne co sa mysli pri detekcii preteceni pri C#, ale pri Jave ziadne buffer-overflow diery na sposob C-cka nehrozia (tj. JVM vzdy v takom prip. hodi exception)
- pri "Vícenásobná d?di?nost implementací" je u C# "ne" - a ja som si myslel, ze ano. Ako to vlastne je ?
- celkom by ma zaujimalo, preco je pri "Podpora práce s "Collections"" u C# vyborna a pri Jave len dobra ?? T.j. v com ma C# navrch ? (situaciu v Jave poznam...)

Off-topic: ja vim ze pravdu nemam ale bohuzel autor clanku na tom stavi, ze podoba syntaxe znamena ze je jazyk "ukraden".

Jinak si prihodim k Jave - pokdu si prectete licencni podminky tak se tam mj. pise ze Sun ma pravo si kdykoli zacit vybirat licencni poplatky na cokoli co je napsany v Jave. Dostatecny duvod proc aspon ja v jave psat nebudu ;) Nemluve o tom, ze viceplatformita je dobra u klientu ale u serveru je o nicem, protoze prekopat vetsi aplikaci na jinou platformu je otazka nekolika let (viz rozsireni NT4ek na serverech nebo pouzivani mainframu) a pokazdy s tim jde vice mene kompletni prepsani ty aplikace.

no neviem, asi mi ta logika unikla, ale prave to oddovodnenie v poslednej vete je dokaz, resp. dovod, preco je multiplatformovost serverovych aplikacii tak dolezita a imho jedna z najdolezitejsich pricin, preco sa Java presadila prave v serverovej oblasti....

este cosi:
1. nevidim v clanku nikde to, ze by C# bol "ukradnuta" Java ani nic o tom, ze by autor staval iba na podobe syntaxe...
2. naschval som si prebehol licence agreement k JDK ale nic o tom, ze Sun moze spoplatnovat kod napisany v Jave som nenasiel. Mohol by si ma pliz nasmerovat ? Btw. zaujimave, ze aj velki konkurenti Sunu ako IBM v Jave veselo vyvyjaju velke projekty a su stale v pohode...:)

nevidim v clanku nikde to, ze by C# bol "ukradnuta" Java

jazyky od sebe navzajem opisuji, to je uplne normalni a C# prinasi dost noveho na to aby jeho existence mela smysl

chtel jsi zajiste napsat:

jazyky od sebe navzajem opisuji, to je uplne normalni a C# prinasi dost noveho na to aby jeho existence mela smysl jen jako Java 1.9

ze?

;)

to tezko, myslim ze C# do Java bytekodu nezkompilujes, na to je moc ubohej

jinak jsem rad ze uznavas naskok C# pred Javou

Ja tim mel na mysli, ze urcite C# ma veci, ktere Java nema (minimalne jen proto, ze vznikl pozdeji a jen magor by ignoroval zkusenosti ostatnich), ale to, ze neprinasi nic moc prevratneho (viz moje jine prispevky) a ze spise me to pripada, ze MS doplnil ty veci, ktere v Jave programatorum chybi, prejmenoval funkce a svazal s Windows ;) (trocha sarkasmu neskodi ;)))

neprinasi nic moc prevratneho (viz moje jine prispevky) a ze spise me to pripada, ze MS doplnil ty veci, ktere v Jave programatorum chybi,

Odpovedel jsi si sam - C# prinasi to, co chybi v Jave. Me toho v Jave chybi dost.

to bys mel jit do majkrosoftu a rict jim ze jeste ten ccrash vylepsis a nahazet do ty specifikace dalsi a dalsi fiicury - hele treba by se hodily templejty z C++  nebo bys mohl vykuchat adu a praskal a nahazet tam spoustu tech serepeticek co definuji  - jooooooo to by pak byl super jazyl

no ale ja radsi zustanu u toho ccka a javy pac se s nima tak dobre pracuje ze jsou tak jednoduchy - no jo, udelat neco jednoduchyho a uzitecnyho to uz chce trochu vic inteligence nez jen klik klik klik  (mel bys znovu zkusit algebru tam se taky zjednodusuje na nejjednodusi vyraz a hadej proc )

a muzes mi laskave vysvetlit v cem je kombinace C + Java jednodussi nez samotne C# ? pekna blbost, C a Javu musis slozite integrovat pres JNI a zvlast je kompilovat, zvlast ladit

proc to nemuze byt proste v jednom jazyku ? co je na tom sakra sloziteho ?

no jo, udelat neco jednoduchyho a uzitecnyho to uz chce trochu vic inteligence nez jen klik klik klik

co to meles, jak to souvisi se C# ?

mel bys znovu zkusit algebru tam se taky zjednodusuje na nejjednodusi vyraz a hadej proc

to nechapu, jakto ze teda neprogramujes treba v LISPu ? to je jednoduchost sama

jedina reakce na objektivni prinosy C# jake jsi schopen, je stezovat si ze to zeslozituje jazyk, no boze, tak to radsi prejdi rovnou treba na VBscript

omiiilek kuzilek

kombinace java a C neni nikterak slozita, naopak, kdyz uz mi nestaci java a potrebuji pouzit napriklad nejake systemove knihovny, tak sahnu po Ccku, a kdyz nebudu cune, muzu to napsat v podstate platformove nezavisle - ono totiz klasicke C je skutecne platformove nezavisle

napr. si budu chtit napsat nejaky haaakovaci programek pouzivajici raw sockets, tak jasne ze nesahnu po systemovych prostredcich windows ale vezmu si nejakou open sourcovou knihovnu ktera mi nabizi mnohem vetsi funkcionalitu napr. pro psani storm-pings apod. no a rychle si napisu univerzalni rozhrani v jave, k tomu rychle vezmu JNI a pres gcc to zkompiluju a mam utilitu co pobezi na kazdem systemu a je zcela neomezena kontrolnimi mechanizmy nejakeho blbeho OSu

zato ale vobycejny klikac udela to ze si sedne ke svemu pitomemu C# a maximalne se zmuze na pitome VC++ kde bude volat omezene a stupidni Win32 API - fuj s tim se neda nic delat a proto si rekne ze hacking neexistuje ptz to nejde napsat a pujde spat

no a mezitim mu ja protestnu komp s tim co si napisu prave pres jaaavu a JNI

a nemusim byt ani (opet si pujcim tu autorovu parafrazi ) pejsek s kocickou abych namichal tak desny drijak jako to udelal m$ s tim c-crashitkem

no a rychle si napisu univerzalni rozhrani v jave, k tomu rychle vezmu JNI a pres gcc to zkompiluju a mam utilitu co pobezi na kazdem systemu a je zcela neomezena kontrolnimi mechanizmy nejakeho blbeho OSu

Super a ted mi jeste vysvetli proc se potykat s nejakym blbym JNI ? Predstav si ze na ty raw sockety muzes lezt primo z Javy ? Neni to mnohem lepsi nez k tomu kompilovat DLLko napojene pres tezkopadne JNI ???

Navic budes muset ten svuj C&Java bordel pro kazdy system zvlast kompilovat.

zato ale vobycejny klikac udela to ze si sedne ke svemu pitomemu C# a maximalne se zmuze na pitome VC++ kde bude volat omezene a stupidni Win32 API - fuj s tim se neda nic delat a proto si rekne ze hacking neexistuje ptz to nejde napsat a pujde spat

co je to za nesmysl

a) co to furt meles o klikacich, co je na C# vic "klikacskeho" nez na Jave proboha ???

b) proc bys jsi z C# nemohl volat neco jineho nez API, nechapu, zavolas si tu svou OSS knihovnu, primo, bez interfacu, bez kompilaci, bez explicitniho managovani referenci na objekty, bez blbeho generovani C jmen odpovidajicim signaturam, bez volani neohrabanych JNI funkci apod., PROSTE UPLNE NORMALNE

a nemusim byt ani (opet si pujcim tu autorovu parafrazi ) pejsek s kocickou abych namichal tak desny drijak jako to udelal m$ s tim c-crashitkem

Schvalne - co je vetsi zmatlanost - kombinace Java-JNI-C nebo Java rozsirena o pointery ? No co asi ! Ja te proste nechapu, zrovna pro lidi co maji potrebu vyvadet takove veci musi byt C# prece jako stvoreny a Java proklinana

    Predstav si ze na ty raw sockety muzes lezt primo z Javy

A jak? Pokud myslis primo z javy, tak tam muzes tak akorat delat SOCK_PACKET (Socket) a SOCK_DGRAM (DatagramSocket a MulticastSocket)
Vysvetli mi, jak udelas SOCK_RAW.....

Nepochopil jsi me, no prave ze z Javy nemuzes a ze C# muzes. Dulezity bylo to slovicko "predstav si"

Omyl! Na tomto predpokladu jsem svuj clanek nezalozil. Pouze jsem psal o tom, jak probehlo mnoho pochybnosti kolem vyvoje C#. Je totiz (aspon pro me) velmi zarazejici, jak Microsoft pred nekolika lety tvrdil, ze neni nutny dalsi programovaci jazyk a pak s nim sam prijde. A vzhledem k tomu, ze se snazi poucit z uspechu Javy (kdyz si date vyhledat Java na news.com tak vyjde mnoho clanku na toto tema), tak je vic nez na snade myslenka, do jake miry co prejal.

Netvrdim, ze ja mam pravu, pouze polemizuji a sam i pro sebe a svuj business hledam odpoved - a to pravdivou, ktera pak znamena uspech na trhu.

Detailnejsi srovnani jazyku C# a Java je treba na:

http://slashdot.org/article.pl?sid=01/11/18/2237258&mode=thread
http://www.25hoursaday.com/CsharpVsJava.html

C# a CLR budou mit brzy podporu na vice platformach - viz napr.:

http://news.com.com/2100-1001-269101.html?legacy=cnet
http://www.go-mono.org/

This posting is provided "AS IS" with no warranties, and confers no rights.

to je ale kuriozitka :) clovek z MS propaguje link na slashdote... kam ten svet speje ..... ?! :))

svet speje k ruzovej buducnosti, svedci to iba o tom ze v M$ pracuju (aj) seriozni ludia ktori sa venuju svojej praci na profesionalnej urovni a tak im nerobi problem zverejnit link hoci aj na Slashdot ak sa tam prave nachadza nieco k danej teme.. to ze by standardny "unixak" nikdy nezverejnil link na M$DN nech by sa tam uz nachadzalo cokolvek dolezite este neznamena ze sa tak musia spravat vsetci ludia na svete, vskaze?

mno ja by som nebol az taky velky optimista :) skor mam pocit, ze ak treba, tak sa MS spoji aj s certom :)

Uz to ani smiesne neni, ako dokazu ludia na SLovensku sa cudovat nad linkom v Slashdote od MS, ako dokazu byt najvacsi bojovnici proti monopolu MS a pritom si nevedia urobit poriadky z ich Telekomom, ktorych ich zdiera za internet ako svina.
Cely business je postaveny na tom, ze robim veci, ktorych predam najviac. A najviac sa ich preda, ked ich vyrabam pre najrozsirenejsiu platformu ( a je jedno, ci je to MS, Sun, IBM alebo dalsi). 
V zivote som nepocul o solidnej SK pocitacovej firme, ktora by dokazala nieco celosvetovo, ale poculi sme o Alt-F4 a ich nepricetnych clenoch a podobnych uchyloch.
Tento clanok mal za ulohu porovnavat Javu a C#, prip. Javu a .Net. Tak sa venujme tomu, vymienajme si skusenosti a vykaslime sa na absolutne neproduktivne boje, ci je najviac Java jobs na trhu, MS link na Slashdot a ine kraviny, ako nenavidime MS a pod. Primajme informacie, ktore sa na nas valia a vyfiltrujme si z nich to, co je pre kazdeho z nas najdolezitejsie.  Tot vsjo.

heej ukludni sa, myslim, ze som tam tych smajlikov nahadzal dost..

Presne, diky http://www.25hoursaday.com/CsharpVsJava.html kazdy vidi, ze C# obsahuje spoustu potrebnych veci ktere Sun hloupe vyndal z C++. C# je opravena Java, je to Java tak jak mela vypadat pred sesti lety, jazyk s moznostmi C++ a privetivosti Javy.

Navic - autor plete dohromady jazyky a platformy. Platforma CLI, na ktere bezi C#, je _obecna_ platforma pro mnoho ruznych jazyku, nebyla vyvinuta pouze pro C#. CLI vytvari spolecnou zakladnu pro ruzne jazyky a tedy i pro jejich jednoduchou integraci. Java nabizi jen Javu.

No zalezi na uhle pohladu - pre nasadenie v kritickych aplikaciach a la bankovnictvo, kde je klucova bezpecnost bude C# s unsafe kodom a pod. skor pokazena Java...
Java neponuka len Javu - mate link priamo v clanku (na konci), ktory uvadza zoznam implemetacii inych jazykov nad JVM (najznamejsi je asi Jython).

btw. tak co stavime sa ?? :)

No zalezi na uhle pohladu - pre nasadenie v kritickych aplikaciach a la bankovnictvo, kde je klucova bezpecnost bude C# s unsafe kodom a pod. skor pokazena Java...

Nikdo nikoho nenuti to pouzivat, jde o moznost. Javovska filosofie "vyhazime z toho vse nebezpecne" Javu limituje. Pokud chcete bezpeci a nepotrebujete nizkourovnovy pristup, tak na unsafe kod proste zapomente a je to. V kazdem pripade je bezpecnejsi a mnohem efektivnejsi unsafe kod v C# nez JNI v Jave.

Java neponuka len Javu - mate link priamo v clanku (na konci), ktory uvadza zoznam implemetacii inych jazykov nad JVM (najznamejsi je asi Jython).

OK, ten druhej odstavec co jsem napsal jsou kraviny, omlouvam se autorovi za narknuti.

Ty vole ondrej, vyvijel si nekdy neco vetsiho ? To asi ne, jelikoz jinak bys vedel, ze pokud ma programator moznost neco pouzit, tak to pouzije a to i v pripade 'unsafe' vec, jelikoz je presvedcenej, ze mu to musi fungovat. Tyhle 'C# krasny veci' co 'Sun bezhlave vyhazel' jsou naprosto napytel, jelikoz casem delaj kod naprosto nezvladnutelnej. Proc ma asi J2EE takovej uspech, to neni proto, ze to ma 'unsafe' veci, to je proto, ze navrh jazyka vede programatory dodrzovat urcity bezpecnostni pravidla.
Micorsoftu zdar .

To je vec discipliny. Pristup typu "nedame to tam protoze to muze byt zneuzito" je podle me nanic. Je to podobna (a casto o dost horsi) blbost jako vyhodit z jazyka goto. Unmanaged kod stejne budes drzet na minimu protoze vetsinou neni potreba. Bude se vyskytovat jen kdyz chces interfacovat s necim non-CLI nebo kdyz chces vysoky vykon. Tech par kousku bude navic oznacenych, takze vis kam kouknout az ti to sleti

Jsem si jistý, že při vývoji každého velkého projektu bude jasně specifikováno, zda se může nebo nemůže použít unsafe režim. To si vedoucí týmů uhlídají (pokud budou chtít), nebojte. Klidně i při open source vývoji. Vyhledat ve zdrojovém kódu slůvko unsafe není až takový problém, ani kdyby se vyvíjelo v notepadu.

Logické je to takhle - unsafe se použije pouze ve velmi precizně zdůvodněných a dobře zdokumentovaných případech. V drtivé většině programů - velkých i malých, serverových i klientských - se nepoužije nikdy.

Unsafe kód přitom ve většině případů není nijak nebezpečný, je jenom méně řízený runtime než std. "safe" mód. V .NET máte i jiné možnosti, jak volat kód běžící mimo runtime, třeba přes COM.

Haha, to sedi, panove maji zrejme bohate zkusenosti s managovanim vyvoje projektu, na kterych dela pres 100 developeru najednou. Kazdej si totiz najde 1000 vymluv, proc tam ten 'unsafe' bejt musi. Obvykle to bude z dovuodu, ze jinym - poradnym zpusovem se to nestiha a pokud ma bejt produkt venku vcas, tak se to proste udela 'unsafe', az bude cas, tak se to predela na spravnej, 'safe' kod. Ale v realite se to predela v mimimalnim poctu pripadu - pokud fakt programujete nejaky vetsi veci, tak musite dobre vedet, ze na refactoring moc casu nezbyva (pokud teda u M$ shopu nekdo o refactoringu neco vi

Jen tak nahodou, kdyz si takovyhle "hacky" musi umet kazdej vedouci tymu uhlidat, je zajimavy, ze jediny zdrojaky jaky jsem kdy videl od Microsoftu je jejich slavna MFC. Docela bych si dovolil tvrdit, ze to je krasny odstasujici priklad. Zde opravdu programatori MS ukazuji, jak nepsat objektovy knihovny. Melo by se to ukazovat ve skolach, podobne jako doktori studujou ruzny degenerace a odchylky.

Samozrejme ze chapu, ze je to stalo desnou praci a netvrdim ze bych to udelal lip, nicmene pokud by nekdo chtel namitat, ze MFC je skvely (jak navrhem nebo implementaci), tak se probuh podivejte treba na ty zatracovany Swingy, pripadne na SWT od IBM (soucasti projekty eclipse.org).

O MFC mluvíte vy. Já myslím, že MFC nebylo ve své době špatné, ale nikdo tady myslím netvrdí, že MFC je vzor. Dnes je každopádně MFC hodně zastaralé.

Skutečně nemám zkušenosti s řízením projektu, na kterém dělá více než 100 vývojářů. Vlastně vůbec nepracuji jako vývojář a navíc si myslím, že i v globálním měřítku je jenom omezený počet lidí s takovými zkušenostmi. Pokud se mýlím, opravte mě. V komerčním sektoru je samozřejmě nutné rozdělit lidi na menší týmy. 100 lidí je asi reálných v Open Source a je fakt, že tomu moc nerozumím - je klidně možné, že v OS ve skutečnosti vládne chaos, jenom mi to připadá nepravděpodobné.

Vážně si ale myslím, že když neuhlídáte použití unsafe (stačí na to Grep nebo "Hledat soubory či složky"), nemůžete tvrdit, že máte nad projektem kontrolu. Nemůžete tvrdit, že provádíte testování. Nemůžete tvrdit, že váš projekt dobře dopadne. Atd.

Tak fajn, docela souhlasim s tvrzenim, ze pokud neuhlidam 'unsafe', tak nemam kontrolu nad projektem. To je pravda. Tak proc to unsafe tam vubec je ? Neni jednodussi ho nemit a nekontrolovat ho (alespon by ubyla prace). Ja mam totiz bohuzel z praxe zkusenosti, ze pokud nejaky feature mam k dispozici ( a muze byt jakkoli nebezpecny), tak po casovym presem dochazi k jejich vyuzivani a zadnej team leader tomu nemuze nijak poradne zabranit (pokud chce mit projekt hotovej vcas), tudiz ve vetsich projektech (a tam C# miri, nemylim li se) je lepsi tam zadny takovyhle vychytavky nemit, jelikoz je to "dablovo pokuseni".

Jen tak mimochodem, kdyz jsem pred nejakjema 4-5 rokama zacal psat v Jave, tak jsem pred tim docela psal v C/C++ a docela me vzdycky prekvapilo, ze narozdil od C/C++ ten muj kod docela behal bez chyb a pokud nejaka ta chyba byla, tak jsem ji pomerne dobre nasel. A rychlost kvalitniho vyvoje je podle me dneska to nejdulezitejsi. Je totiz lepsi psat kod treba i dyl a bezpecne nez ho napsat rychle, ale pak ho jeste delsi dobu odladovat.

Ale já se s vámi nehádám. Možnost psát unsafe kód skutečně objektivně zavádí do C# další šanci dělat chyby. Přirozeně platí, že čím je nějaký nástroj silnější, tím snadněji se s ním zraníte. Např. cirkulárka je nebezpečnější než lupenková pilka.

Při návrhu SW děláte kompromisy. Vždy. A samozřejmě - MS je zvlášť dobře známý svými kompromisy typu bezpečnost vs. features. Ale myslím, že tady bylo třeba udělat kompromis a že tím žádné velké riziko nevzniká. MS se totiž jazykem C# snaží pokrýt širší spektrum aplikací než Sun. Ano, chce, aby se v něm vyvíjely i hry. A co je asi ještě důležitější: Radikálně usnadní převod starých aplikací z C a C++ do C#.

V C# tak můžete napsat skutečně výkonný kód, když je to nutné. A přitom ho stále máte uzavřen v direktivě unsafe, proto ho vždycky najdete, když potřebujete (když se vám třeba ztrácí paměť). Tento kód není vyňat z "vlivu" runtime, není to např. tak, že byste ho mohli stáhnout z Internetu a nainstalovat bez digitálního podpisu. Jenom může používat pointery a neaplikuje na ně garbage collector, to je vše.

Normálně je ale garbage collector tak užitečná a geniální věc, že se myslím drtivé většině programátorů vůbec nebude po pointerech stýskat. Když programujete z čistého listu, nepotřebujete je.

No toho, ze C# bude univerzalne pouzitelny jazyk, toho se prave bojim. Podle me nic na svete neni univerzalne pouzitelny a nejlepsim dukazem je toho Java sama. Ta taky mela bejt to nejlepsi pro vsechny a da se rict, ze to nejlepsi je dneska v oblesti serveru, takze databaze, weby, ...

Zajimava bude jeji budoucnost taky na malych a embedded zarizenich, ale tady uz se obavam, aby to nedopadlo jako s desktopovym vyuzitim, ktery je prozatim docela maly.

Jinak s tim vykonnym kodem asi takhle, pokud budu chtit opravdu vykonny kod, tak pouziju asi C (a ne C++, ani C#), prece jenom, ackoliv se vykon ILM muze blizit kompilovanemu kodu, tak jej nikdy (uz z principu) nemuze dosahnout. Takze tady zadnou vyhodu C# nevidim. Pokud uz zas az tak vykonny kod nebudu potrebovat, tak treba C# pouziju, ale zase se mi nezda, ze bych pak pouzival 'unsafe' kod.

Nakonec, prirovnani lupenkovy pilky a cirkularky je sice hezky, ale me spis prijde C# jak cirkularka bez ochranejch list, takze se kazdej kdo s tim poradne neumi a pouziva to k blbostem se muze pekne porezat, kdezto Java je prave ta poradne ochranena cirkularka se vsema bezpenostnima udelatkama, kde nektery veci sice nejdou delat (napr. pripravovat rizky na nedelni obed), ale zase se je u ni risk nejakyho poraneni podstatne nizsi .

Podle me nic na svete neni univerzalne pouzitelny a nejlepsim dukazem je toho Java sama.

spousta jazyku je univerzalne pouzitelna, C, C++, Pascal, Ada atd. atd. atd. muzes s tim psat treba operacni systemy kdyz chces

Java je tak leda dukazem univerzalni nepouzitelnosti Javy

Jinak s tim vykonnym kodem asi takhle, pokud budu chtit opravdu vykonny kod, tak pouziju asi C (a ne C++, ani C#), prece jenom, ackoliv se vykon ILM muze blizit kompilovanemu kodu, tak jej nikdy (uz z principu) nemuze dosahnout.

Tenhle "principialni duvod" je nesmysl. Proc by mel byt IL prelozeny do strojaku pomalejsi nez vysledek klasickeho prekladu ? Naopak, diky kompilaci na miste muze JIT kompiler zkompilovat kod optimalizovane pro urcity procesor a ne pro nejaky "prumerny procesor".

Nakonec, prirovnani lupenkovy pilky a cirkularky je sice hezky, ale me spis prijde C# jak cirkularka bez ochranejch list, takze se kazdej kdo s tim poradne neumi a pouziva to k blbostem se muze pekne porezat, kdezto Java je prave ta poradne ochranena cirkularka se vsema bezpenostnima udelatkama, kde nektery veci sice nejdou delat

C# je nabrousena cirkularka kde musis explicitne uvest ze se chces porezat, nevim jak by te to melo vic chranit. Zato Java je kotouc, ktery dobre funguje pro pro relativne omezenou tridu programu a s kterym kdyz chces neco porazne uriznout, zbyva ti jedine JNI, slozite, pomale a jeste nebezpecnejsi nez unsafe C#.

Podle toho co rikas se okamzite muselo vsech 100 programatoru toho vaseho projektu vrhnout na JNI, protoze co se zneuzit da, to se taky zneuzije, ze jo, a ted je vas program prorostly native tridami. Nebo ne ?

aj ja si este hodim nejaky link :)
http://www.theserverside.com/resources/pdf/J2EE-vs-DotNET.pdf
prip. este o tom "vyndavani" - za precitanie stoji aj rozhovor s "vynalezcom" Javy J.Goslingom o.i. aj o C#:
http://news.com.com/2008-1082-817522.html - napr. vyjadrenie k C#: "'Imitation is the sincerest form of flattery--thank you very much,'" he said this week. But the other answer is 'You guys (at Microsoft) still don't get it,' because it's sort of Java with reliability, productivity and security deleted."

A to si este nevidel, ako po sebe palia IBM a Oracle vzhladom na vojnu medzi ich DB systemami. Prial by som ti vidiet tie bilboardy.
Chcem iba povedat, ze co si cakal?

http://news.com.com/2008-1082-817522.html

jo to sem cet, jeho porovnani C# a Javy je trapne

'Imitation is the sincerest form of flattery--thank you very much

On si asi mysli ze kazdy moderni jazyk vychazejici z C++ je kopie Javy. Sam akorat vykuchal C++ a vymyslel inteligentni system modulu.

because it's sort of Java with reliability, productivity and security deleted

Lez. Unsafe mod je jen _moznost_, navic je takova pasaz kodu oznacena a ostatni objekty jsou od ni ochraneny. Hlavne ze JNI, ktery muze lizt do pameti jak se mu zachce, je safe, he he

Filosofie Sunu "vykuchame z jazyka vse nebezpecne a slozite" udelala z Javy jazyk zalozeny na jednoduchosti, ne na sile, jazyk neschopny low-level manipulaci, a tim ho omezila.

Dedek je proste akorat posranej ze jeho ditko krapet zaostava

Kurva, ale Java nevychazi z C++, mozna syntaxi, ale filozofii ani nahodou (v tom je az prilis podobna smalltalku).

Ondej, ty si programoval v zivote maximalne desktop aplikace a jeste nejaky jednoduchy (jestli vubec progranujes), jelikoz bak bys nemohl placat takovy nesmysly.

Jinak posledni poznamka, kdyz byly windows 3.1, tak taky mely vsechny skvely features co se tyce bezpecnosti pristupu do pameti, kooperativni multitasking a tak. Pamatujete jak tyhle vlastnosti MS vychvaloval ? A kde je jim dneska konec ...

Kurva, ale Java nevychazi z C++, mozna syntaxi, ale filozofii ani nahodou

no tak dobre, no

(v tom je az prilis podobna smalltalku).

prej smalltalku, to tak  smalltalk je uplne odlisna vetem OOP

Ondej, ty si programoval v zivote maximalne desktop aplikace a jeste nejaky jednoduchy (jestli vubec progranujes), jelikoz bak bys nemohl placat takovy nesmysly.

delani desktopu splacanim komponent na "formulari" nemam rad a planuju se ho v zivote co nejvic stranit

ani poradne neznam zadny RAD, jen winAPI

na gymplu amatersky hry a pred casem i takovy letecky simulator, umela inteligence

jedna z poslednich veci mel byt operacni system, tady jsem ovsem alespon prozatim hodne rychle vymeknul 

a vubec nevim proc by clovek co se chce za kazdou cenu porezat cirkularkou mel delat desktopy, to je zajimava dedukce

Jinak posledni poznamka, kdyz byly windows 3.1, tak taky mely vsechny skvely features co se tyce bezpecnosti pristupu do pameti, kooperativni multitasking a tak. Pamatujete jak tyhle vlastnosti MS vychvaloval ? A kde je jim dneska konec ...

tohle fakt vychvaloval ?

jinak ja urcite jen tak nejdu kam MS ukaze, a jakejkoliv (nejen MS) markentigovej hnuj ignoruju

Souhlasim s jednim z ctenaru vyse, ze podpora direcktivy #define je dobra vec, i kdyz bych si nepouzival zrovna takovym zpusobem, jak pise. Obecne receno, cim vic konstrukci jazyk podporuje, tim lepe. Pak mam vzdy moznost vybrat si tu nejvhodnejsi a nejobratnejsi, ktera se k reseni daneho problemu hodi nejlepe. Stejne tak direktiva #include je prakticky to same jako prikaz import a podobne, #include je pouze obecnejsi. Samozrejme je to brzda kompilace, ale staci, aby si kompilator umel vyrobit soubor s predkompilovanymi hlavickovymi soubory (kdyz to umel BCC 3.1, tak nevim, proc by to nemely umet jine).

Ja obecne razim heslo, ze je prakticky uplne jedno, jaky jazyk si vyberete, znam lidi, kteri dokazou napsat naprosto nesrozumitelne, dlouhe a chybove programy v cemkoliv. Java (a asi i C#) zrejme programatora nuti k osetrovani vyjimek apod., ale i to se da vzdy obejit a veskera snaha tvurcu jazyka je tim v haji. Samozrejme spolehlivost jazyka - platformy - kompilatoru je otazka jina.

Polemiky nad tim, ktery jazyk je obslehnuty od ktereho, jsou k nicemu, stejne vsichni obslehli Fortran :)

Ja osobne jsem fanda C++ v kombinaci s Perlem, ovsem nejcasteji programuji ve Visual Basicu. Duvod je jasny, pracuju na platforme Microsoftu, pisu i-netove aplikace v ASP nebo jednoduche programky ve VB. Vyjimkou je analyzator logu v C++ a skriptiky v Perlu pro praci s texty (treba zpracovavani archivu textu pisni na http://metal-lyrics.hyperlink.cz). Jinak se muzu smele zaradit do 50% programatoru Javy, protoze Javu znam, restoze jsem v ni nenaprogramoval ani ten prihlouply HelloWorld ;)

mania-king.

<< Verzování

hmm..v C++ je treba virtualnu metodu oznacit klucovym slovom "virtual" v zakladnej triede, v dedicnych triedach to nie je potrebne...Ale ja som sa predsa stretol s nazorom, ze ak je raz metoda virtualna, mala by sa tak oznacit vo vsetkych svojich instanciach (teda vo vsetkych dediacich triedach)

<< Operátory ->, ::

ako v C# pracuju pointers (ak su teda podporovane) ? pretoze operator -> sa v C++ pouziva na pristupovanie objektu, na ktory ukazuje ukazatel...alebo sa pouzivaju iba references ?

V C# muzes pouzivat pointry stejne jako v C, narozdil od Javy z ktere to ty volove od Sunu vyhodili, protoze si mysli ze pointry jsou proste spatne a basta fidli. Z krunyre Javovske omezenosti se muzes prodrat nanejvys pres Java Native Interface. C# si vystaci samo.

Jazyk, který neumožňuje pointery, je dobrý možná tak jako hračka pro děti nebo při nejlepším pro výuku programování na základní škole. Takže myslím, že u většiny programátorů se Java odepsala sama, protože prý pointery neumožňuje, pokud je to tedy opravdu tak. C# je umí, o tom jsem se již přesvědčil, takže pro mne je situace jasná.

Taky nebudes jezdit s autem, ktere nema radici paku
ale automatickou prevodovku?
Ukazatalovou aritmetiku jsem vyuzival v assembleru i v PL/1,
ale v Jave jsem ji zatim nepotreboval.
Asi bys musel trochu premyslet, ne?

V Jave totiz muzes delat to, na co potrebujes pointery v C++ bez klasickych pointeru. Klasicka pointerova aritmetika sice nejde, ale zatim mi to neprisla jako nevyhoda.

Pointry se používat dají, ale musí se kód zvlášť uvést jako "unsafe" a pak tam zase nepracuje standardní garbage collector atak. Spíš mi to připadlo, jako z nouze ctnost. "Používat to můžete, ale nezvykejte si na to". Aspoň tak jsem to pochopil. :)

V .Net (schvalne v .Net, pretoze .Net nie je len C#) neexistuje unsafe mod. Existuje len managed a unmanaged code.

Psal jsem o C# a Microsoft sam ve sve specifikaci zavedl termin "unsafe" - viz. "Csharp language specification", 10.9.2001, priloha A. Unsafe code, strana 305.

Mas pravdu. V C# ked chces pouzivat smernikovu sebevrazdu za kazdu cenu, pouzijes compile option /unsafe.

v podstate ale o ide dve oznacenia jednej veci, ze ?? :)

Ano, to mate pravdu, ze se tu pereme o nic  Jen jsem chtel upresnit technicke detaily, ktere sam jsem si k clanku dukladne pripravil a nastudoval. Proto jsem si byl tak jist tou odpovedi

Nejde, managed code je to co běží v CLR, unmanaged code je to co běží v nativním prostředí Windows (win32 api), unsafe code je část kódu (i v managed kódu), která nevyhovuje určitým požadavkům a proto je jinak zpracována překladačem.

tj. je mozne napisat app. ktora bude miesat safe a unsafe kod, ale pritom bude cela bezat "managed", tj. v CLR ? Co to vlastne znamena ? - ak totiz budem pristupovat priamo k pamati (pointre...) - ako mi do toho bude CLR zasahovat (su tam snad nejake bezp. mechanizmy ?) ?? Ako je to potom s efektivitou unsafe codu, ak bezi v akomsi "inkubatore" CLR ? A naopak, znamena to, ze v managed kode nemozem priamo pristupovat k nativnym knizniciam ani v unsafe mode (tj. musim (kompletne ?) prejst na "unmanaged" kod ??). Rad by som si to vyjasnil, zacinam v tom mat hokej.

Java nema budoucnout

Spis mi pripada ze C# nema budoucnost, protoze budoucnost je v multiplatformnich resenich...

C# se vyviji pro Linux i BSD a vsadim se ze se rozmuze vsude

o co ? :))

Sice v Jave ani C# nedelam (muj favorit je PHP, ale to je trochu o necem jinem )), ale rekni mi, co nabizi C# navic nez Java? (krome masivni marketingove podpory) Umi snad hashovany vicedimenzionalni pole (ja PHP proste MILUJI! Kdo nepouzival, nepochopi, k cemu je to dobre - dokaze to zkratit funkci z 50 radku na 10 a ohromne zprehlednit program - teda pokud se to nepouzije prasacky...)? Proc by mely spolecnosti jako Oracle, SAP apod. investovat miliony dolaru do podpory C#, kdyz maji hotovou podporu Javy? A bez podpory velkych spolecnosti a tedy velkych "uzivatelu" (banky, fabriky...) se C# nerozsiri... Navic KAZDEMU je jasne, ze MS bude s C# mohutne tlacit podporu svych systemu a uz s tim leze na krk HODNE firmam (IBM, Sun, Oracle...)

Pokud chces videt moderni programovaci jazyk, ktery prinasi neco noveho, tak se podivej na Ruby (ne "naruby" ))

rekni mi, co nabizi C# navic nez Java?

http://www.25hoursaday.com/CsharpVsJava.html

nabizi preprocesor, moznost rucni dealokace pameti, enumy, struktury alokovane na stacku, nizkourovnovy kod, predavani parametru odkazem atd.

jde o univerzalni jazyk, coz se o Jave rici neda

Umi snad hashovany vicedimenzionalni pole

nevim, v kazdym pripade si ho urcite muzes udelat sam

co to znamena vicedimeznionalni hash tabulka ?

Nevim - me enumy, stackovane struktury... neprijdou jako veci, kvuli kterym se ucit zase novy jazyk a podstupovat vsechny ty obtize s tim spojene (vcetne zavislosti na firme, ktera se uz historicky znemoznila tolikrat, ze je to skoda pocitat...) Chapu, ze to muzou byt uzitecne veci, ale jsou veci, bez kterych se IMHO da obejit (nikdy jsem nepracoval na zadnem velkem (ani stredne velkem ;))) projektu) - kdyby to tak vadilo, tak preci neexistuji ty ohromne bankovni a jine informacni systemy postavene na Jave

Prave problem je, ze hashovany (natoz vicerozmerny) pole musi podporovat jazyk, jinak si to neudelas sam (muzes to emulovat pomoci funkci, ale zneprehlednuje to silene kod).

Co to je? Treba tohle: (kod v PHP)

for ($i=0;$i     echo ("Firma: ".$firmy[$i]["nazev"]);
     echo ("Adresa: ".$firmy[$i]["adresa"]);
}

Elegantni, ne?

Nevim - me enumy, stackovane struktury... neprijdou jako veci, kvuli kterym

a co ty ostatni ?

hashovany vicerozmerny pole by mely jit udelat i v C++

template class CHash {

T operator[](const char * name); //vybira podle jmena

T operator[](int index); //vybira podle indexu

atd .....

}

CHash < CHash > firmy;     //definice

preprocesor, moznost rucni dealokace pameti, enumy, struktury alokovane na stacku, nizkourovnovy kod, predavani parametru odkazem atd.

Preprocesor - hmmmmmm, vzhledem k tomu, ze jsem v C/C++ nikdy moc nepsal, tak nevim, k cemu by mel byt dobry (v PHP mi nechybi...)
Moznost rucni dealokace pameti - a to povazujes za vyhodu? vzdyt tim zakonite musi vznikat chyby v praci s pameti... jaky je duvod tohle mit, kdyz mas garbage collector?
Nizkourovnovy kod - co to znamena KONKRETNE? moznost psani v ASM? to snad ne... ale IMHO to musi znamenat zavislost na platforme (jak OS tak HW)
Predavani parametru odkazem - to je rozhodne dobre, ale divim, se ze to Java neumi (pokud fakt neumi, tak je to od tvurcu pekna p....)

preprocesor - v niektorych pripadoch sa bez neho nezaobides (alebo zaobides, ale s vacsimi performance stratami), aj sa uprednostnuju napriklad inline funkcie pred macros, stale su v niektorych pripadoch dobre (assert() a pod), dalej napriklad inclusion guards a tak dalej...

Moznost rucni dealokace pameti - samozrejme, ze je to vyhoda..pretoze automaticky garbage collector porusuje "pay as you go" ( Danny Kalev - C++ Professional programmer's handbook), jednoducho - je casovo narocny, ale myslim, ze sa v implementaciach (compileroch) da zapnut, iba (zatial) neni v ANSI/ISO (asi ako to bolo s RTTI)

Predavani parametru odkazem - no comment, neviem si predstavit furt kopirovat na stack velke triedy...hmm :)

Preprocesor - priznam se, ze nevim, o cem mluvis - muzes to nejak blize vysvetlit? (polopatisticky ;))))

Rucni dealokace - jasne ze garbage collector bude vzdy zrat nejakou rezii, ale proboha - Java ani C# nejsou staveny urceny pro aplikace, kde zalezi na vykonu! (ty se pisou v Cecku nebo primo ASM) Zde jde o bezpecnost, stabilitu, srozumitelnost programu apod. - vykon je zde az na 2. miste.

Predavani parametru odkazem - jasne - to je nutnost...

> no comment, neviem si predstavit furt kopirovat na stack velke triedy...hmm :)
Co blaznite? V Jave vsechny objekty se predavaji odkazem, hodnotou jsou predavane jen jednoduche datove typy jako int apod.

Ale i Garbage Collectoru musis pomoct tak, ze uvolnis odkazy
napr. na ownera a listenery, aby nezbyla v adresach kruhova
reference. Pak tu pamet nemuze uvolnit.

Myslim, ze programator by mel mit na zreteli, co jeho program bude delat
a ne neco sesmolit a pockat, co to udela.

(Pozn.: Jsem programator nebo snad developer?).

No to je len jeden algoritmus GC (pocitanie odkazov), modernejsie algoritmy napr. prechadzaju referencny strom a vsetko co ostane mimo sa stava predmetom GC teda aj kruhove referencie bez odkazu zvonka.

Inak trend je nechavat uvolnovanie pamati na GC, lebo vo vacsine pripadov sa pri tvorbe programov uz hladi na rychlost vyvoja, nie na efektivnost. Je to podobne ako s pracou s retazcami kedysi sa takmer vo vsetkych progr. jazykoch urcovalo kolko ma mat maximalnu (vyalokovanu ) dlzku ale dnes je pohodlnejsie (nie efektivnejsie) retazce s pohyblivou dlzkou.

Osobne by som uvital autmomaticky GC s moznostou prinutit ho (nielen mu odporucit) aby upratal pamat, ktora uz nebude odkazovana.-  posledny odkaz by sa predal GC.

Inak trend je nechavat uvolnovanie pamati na GC, lebo vo vacsine pripadov sa pri tvorbe programov uz hladi na rychlost vyvoja, nie na efektivnost

Svuj nazor jsem vyjadril zvyraznenim tech tri slov

Preprocesor v C# slouzi k tomu aby jsi z jednoho zdrojoveho kodu mohl zkompilovat vic variant programu

Moznost rucni dealokace pameti predpokladam ze hlavne u velkych kusu pameti je dobre je uvolnovat co nejdriv

proboha - Java ani C# nejsou staveny urceny pro aplikace, kde zalezi na vykonu! (ty se pisou v Cecku nebo primo ASM)

No prave !! C# je staveno skoro na cokoliv. Nyni muzes psat primo v C# misto v C !

Nizkourovnovy kod nejde o psani v ASM, jde o funkcnost jakou mas k dispozici v C

Predavani parametru odkazem to Java neumi, musis pro tu hodnotu vytvorit objekt, ulozit ji do nej a funkci predat odkaz na nej. Super, co ?

Preprocesor mozna beru - nekdy se to hodi (i kdyz v Jave existujou docela dobry workaroundy - public static final promenny a takovy ty C hacky jako #ifdef x86 #ifdef sparc a tak to je v jave totalni nesmysl (to si ma program sam overit v runtime na jaky platfome bezi, pokud je tam nejaka zavislost))

rucni dealokace pameti - no hodi, ono spis zalezi na schopnostech toho GC, jak on je sam schopen to pamet uvolnit, pripadne ho zavolat natvrdo. Ale musim souhlasit, ze pokud bych psal nejaky realtime veci, tak by me GC moc netesil, to je lepsi ta rucni dealokace. K tomu, ze C# je stavenej skoro na cokoliv mi pripomina demagogii komunistu - sorry, ale tenhel vyrok je akorat totalni marketinkovej zvast - s realitou bohuzel nema nic spolecnyho.

Nizkourovnovej kod - takze kdyz mam funkcnost Ccka, tak si jako muzu napsat driver, kterej bude mit treba 10k a pobezi mi primo na nejakym procesoru (bez ILM)? To asi ne, takze ono to s tou nizkou urovni bude asi jako u javy na urovni JNI.

A co se tyce predavani parametru odkazem - no, pokud mluvis o primitivnich typech, pak mas pravdu. Jinak jelikoz ukazatele na objekty jsou vzdycky reference, tak objekty se predavaji odkazem, nebo snad ne ? A co ja vim, v objektovym programovani se objekty pouzivaj docela casto, takze tohle mi vubec nevadi. Na druhou stranu ale je fakt, ze dualita primitiv a objektovych wrapperu je mi docela proti srsti (v tomhle se mi libi smalltalk), ale C# ve svy genialnosti a inovativnosti tyhle rysy prejalo - to by me zajimalo proc.

Nizkourovnovej kod - takze kdyz mam funkcnost Ccka, tak si jako muzu napsat driver, kterej bude mit treba 10k

principialne je to samozrejme mozne, staci aby byl runtime v kernelu

slo by to i s upravenou javou

a pobezi mi primo na nejakym procesoru (bez ILM)?

nejdriv se IL prelozi

K tomu, ze C# je stavenej skoro na cokoliv mi pripomina demagogii komunistu - sorry, ale tenhel vyrok je akorat totalni marketinkovej zvast - s realitou bohuzel nema nic spolecnyho.

sorry, ale napis nejakej argument

V C# muzes psat podobne jako v C, takze nevim proc bys v tom nemohl napsat cokoliv. Jen tam musis mit runtime. Ale teoreticky by se C# mohl prelozit i do strojaku.

sorry, ale napis nejakej argument
V C# muzes psat podobne jako v C, takze nevim proc bys v tom nemohl napsat cokoliv. Jen tam musis mit runtime. Ale teoreticky by se C# mohl prelozit i do strojaku.


Argument: zni MINIMALNE hodne podezrele, kdyz tvrdis (resp. MS), ze C# je stejne dobry pro psani driveru do jadra jako pro psani high-level aplikaci.... Proc si myslis, ze jadra OS (Linux/Windows/COKOLIV!) jsou psana Ceckem a ne C++, kdyz nektere veci byly delany jako objekty (uzivatele/soubory apod...)? (jo, mnoho veci je v jadre psano podobne jako objekty, ale NE objektove).... Muj ucitel z OOP rikal, ze par lety jedna firma (uz nevedel jaka) ohlasila praci na portaci jadra svoji implementace UNIXu z C do C++ a to byla posledni hlaska o tomhle projekty ;)

A neodpustim si: teoreticky Java jde taky prelozit do zdrojaku ;)

Proc si myslis, ze jadra OS (Linux/Windows/COKOLIV!) jsou psana Ceckem a ne C++, kdyz nektere veci byly delany jako objekty (uzivatele/soubory apod...)?

Nekolik duvodu

Neznam zadny duvod proc by melo byt C++ horsi pro systemove programovani. Ty ano ?

Jinak skutecnost ze uzivatele/soubory se jevi uzivateli kernelu jako objekty (podle tebe, me to nepripada) nijak pouziti C++ nenahrava.

Muj ucitel z OOP rikal, ze par lety jedna firma (uz nevedel jaka) ohlasila praci na portaci jadra svoji implementace UNIXu z C do C++ a to byla posledni hlaska o tomhle projekty ;)

A mas pro to nejake racionalni vysvetleni ? Z uvedene zkazky o jedne firme ktera jednou neco rekla a pak to asi nak krachlo nelze usuzovat nic.

Podle meho neskromneho nazoru je prevaha C nad C++ v systemovem programovani nesmysl. Znam jeden velice rychly mikrokernel, ano spravne, psany v C++.

A neodpustim si: teoreticky Java jde taky prelozit do zdrojaku ;)

Ona se tam dokonce prakticky normalne preklada, jinak by byla nanic, mimo appletu a podobnych blbustek. V Jave by sel taky IMHO napsat driver i vetsina komponent operacniho systemu, jde jen o to napsat specialni tridy a snad i trochu upravit JVM.

kdyz se psala Windows, bylo C++ v plenkach

hmm...v roku 1983  zacal Bjarne Stroustup pridavat do C nove veci, z ktorych nakjdolezitejsia bola prave trieda a tak vzniklo C++, v rokoch 1985 - 1989 boli  pridavana dalsie features, ako  protected members, templates, multiple inheritance atd...

v roku 1989 bola zalozena ANSI komisia pre standardizaciu C++, ktora konecny standard schvaleny  aj ISO prijala v roku 1998. Standard je dnes v patrocnom obdobi svojho zmrazenia...

v roku 1989 bola zalozena ANSI komisia pre standardizaciu C++, ktora konecny standard schvaleny  aj ISO prijala v roku 1998.

jenze treba winNT se zacaly psat asi v roce 1990, C bylo mnohem pouzivanejsi

"Neznam zadny duvod proc by melo byt C++ horsi pro systemove programovani"
"Podle meho neskromneho nazoru je prevaha C nad C++ v systemovem programovani nesmysl"
Dovod je (o.i.) vykonnost. Nechcem ti brat tvoj naivny zapal (v istom veku je to normalne:) - ono totiz plne vyuzivanie objektovych postupov (a to plati vseobecne, nie len vo vztahu c/c++) ma svoje nasledky - dynamicka tvorba objektov, pristupove prava, castovanie, skoky cez tabulky virtualnych metod atd. - to vsetko nieco stoji a v oblastiach, kde je vykonnost na systemovej urovni naozaj kriticka su dve moznosti - bud vyuzivat OOP vyhody C++ minimalne, alebo zlavit z max.mozneho vykonu. Nehovorim, ze to nejde ( v C++ ,C# ci Jave). Ide o to, preco by sa mal zabehnuty C-ckar o C++, C# vobec zaujimat (alebo zabehnuty Javista o C# (ale to uz je o inom, C# nie je vo vztahu k Jave to, cim je C++ k C)). Nehovoriac o tom, ze pre programatorov HW ovladacov a pod. IMHO nema OOP ako take vyznam (ver mi,ze sam som velky fanusik OOP - ale to neznamena, ze budem mat klapky na ociach - vsetko ma totiz svoje plusy a minusy...).

Nechcem ti brat tvoj naivny zapal (v istom veku je to normalne:) - ono totiz plne vyuzivanie objektovych postupov (a to plati vseobecne, nie len vo vztahu c/c++) ma svoje nasledky -

dynamicka tvorba objektov,

proc by melo C++ vytvaret vic dyn. objektu nez C ?

pristupove prava,

nerozumim o cem mluvis (doufam ze nemyslis public apod.)

castovanie,

co to znamena cesky ?

skoky cez tabulky virtualnych metod atd.

Virtualni metody pouzijes jen tehdy, kdyz chces polymorfismus. Jinak nemusis. Treba v linuxu ktery je psan v C, taky pouzivaji skoky pres tabulku metod, akorat je to psane v cecku. Proste to pouzijes jen kdyz potrebujes. Je to to samy jako v cecku.

Ide o to, preco by sa mal zabehnuty C-ckar o C++, C# vobec zaujimat  Nehovoriac o tom, ze pre programatorov HW ovladacov a pod. IMHO nema OOP ako take vyznam (ver mi,ze sam som velky fanusik OOP - ale to neznamena, ze budem mat klapky na ociach - vsetko ma totiz svoje plusy a minusy...).

jenze me v tomto pripade nejde o zadny OOP, jde mi o to doplnit pomoci C++ trid do jazyka C to co mu chybi - napr. stringy a pole (anichz bych se musel srat s nejakymy reallocy a nekontrolovanymi mezmi poli)

zabehnuty ceckar by se mel zajimat o C++ proto, aby konecne praveky poloassembler jmenem C opustil

zni MINIMALNE hodne podezrele, kdyz tvrdis (resp. MS), ze C# je stejne dobry pro psani driveru do jadra jako pro psani high-level aplikaci

Me to podezrele nezni, proc tobe ? Univerzalita je jednou ze zakladnich vlastnosti "jazyka mych snu" a verim na ni.

Uhhhh, kdyz se psala windows, tak C++ bylo v plenkach ? Vzdyt slavenj Bill furt tvrdi, ze woknous byly uz asi 1000x prepsany, tak proc to neprepsali v C++. Na druhou stranu si dovolim tvrdit, ze kdyz psali Windows NT, tak C++ uz v zadnych plenkach nebylo - sorry, ale ne.

Ondreji, kdyz si tak skvelej programator v C++, ze nevis proc by C++ nemelo bejt skvely pro psani OS (jo, bude skvely, ale budes ten kod psat hodne moc v C style), muzes nam rict, co tak skvelyho a dobryho delas? Nejakej konkretni produkt nebo tak neco ?

Jo a kterej ze skvelej mikrokernel je psanej v C++, fakt to nevim, muzes mi trosku otevrit obzor ?

Nakonec co se tyce unverzality - to ses docela optimista. O univerzalitu se pokouselo sakra moc lidi a zatim to opravdu nevypada, ze by neco takovyho v dohledny dobe existovalo ... (at jazyku, tak operacnich systemu, tak hardware ....)

Uhhhh, kdyz se psala windows, tak C++ bylo v plenkach ? Vzdyt slavenj Bill furt tvrdi, ze woknous byly uz asi 1000x prepsany, tak proc to neprepsali v C++. Na druhou stranu si dovolim tvrdit, ze kdyz psali Windows NT, tak C++ uz v zadnych plenkach nebylo - sorry, ale ne.

Dobre C++ asi nebylo uplne na zacatku, nevim presne jaka byla situace v te dobe co se tyce kvality jeho kompileru apod, bylo mi tak 13. V kazdym pripade, to ze jsou winNT nebo cokoliv jinyho psany v C pro me neni argument, ja chci vedet P_R_O_C. Potom z toho budu vyvozovat zavery a menit sve nazory.

Ondreji, kdyz si tak skvelej programator v C++, ze nevis proc by C++ nemelo bejt skvely pro psani OS (jo, bude skvely, ale budes ten kod psat hodne moc v C style),

nejde mi o nejaky polymorfismus, ale o pouziti template na stringy, pole a vetsi bezpecnost

kdyz me mas za blba jenom proto ze chci psat OS v C++, tak mi aspon vysvetli proc to nejde, hrozne me to zajima

muzes nam rict, co tak skvelyho a dobryho delas? Nejakej konkretni produkt nebo tak neco ?

Studuju a na vedlejsi uvazek delam programatora - intranety (s tim a podobnymi shity chci seknout) a ruzny veci pro C++ (treba komunikace jednim protokolem po siti), nic zvlastniho. Driv jsem delal real-time strategii a letecky simulator, coz jsem nedokoncil

Jo a kterej ze skvelej mikrokernel je psanej v C++, fakt to nevim, muzes mi trosku otevrit obzor ?

http://os.inf.tu-dresden.de/L4/impl.html

Nakonec co se tyce unverzality - to ses docela optimista. O univerzalitu se pokouselo sakra moc lidi a zatim to opravdu nevypada, ze by neco takovyho v dohledny dobe existovalo ... (at jazyku, tak operacnich systemu, tak hardware ....)

Univerzalni OS - ten bych chtel, chtel bych OS jako stavebnici z ktere si postavim co chci, kde muzu i menit schedulovaci potilitky kernelu apod. Nevim jestli je mozne skloubit realtimovost a vykonnost, do toho moc nevidim.

Univerzalni jazyk - C# - dost jednoduchy pro RAD a zaroven dost silny pro cokoliv jineho. Jestli se ti vic libi kombinace Java-JNI, tak si ji dosytosti uzij.

Budte klidnej, kompilatory Javy do nativniho kodu existujou. Uz dlouho je neco komercniho a ted by to mel umet i GCC 3.

Libor

Vysvětli mi prosím, proč potřebuješ v objektovém jazyce předávat něco co není objekt odkazem. To jde minimálně proti jednomu ze základním principů OOP a to je zapouzdření. To že to jiné jazyky umí svědčí o jejich objektovosti. A jestli tuto funkcionalitu potřebuješ, pak maš problemy s objektovym pristupem.

To co popisuješ jsou přece kolekce

v c++ su dobre stl triedy map a multimap s prepisanym operatorom []

v C# (resp. .NET framework) je trieda Hashtable, i ked mne osobne sa viac pacia stl c++ klasy

ten priklad by vyzeral velmi podobne

povedal by som to asi takto:
suhlasim, C# je univerzalnejsi jazyk ako Java - ponuka par moznosti, ktore v Jave nie su a ktore sa mozu hodit v niektorych specifickych oblastiach
Tieto moznosti ale:
1) budu mat zrejme v praxi aj iste nasledky na kvalitu kodu a navyky programatorov (ja neviem, ale osobne ma dost desi kombinacia garbage collectoru a manualnej spravy pamate; napr. aj spominane predavanie parametrov odkazom (a dalsie veci) neviem, ci povedu nutne k prehladnejsiemu a viac znovu-vyuzitelnemu kodu..)
2) v oblasti v ktorej je Java pouzivana dnes, su imho vymozenosti C# nezaujimave (a nevyvazia vyhody samotnej Javy) - tj. nie su dostatocnym dovodom na zmenu "orientacie"
Prechod na C#/.Net ale urcite moze byt prinosom pre mnohych (nie vsetkych:) C++ windows koderov, o Vis.Basicistoch ani nehovoriac...
T.j. aj ked sa zda, ze so C#/.netom to chce MS natriet Jave, tak tu ide asi (aj) o ine veci a o MS vyvojarov..

A este cosi: programator v zlozitejsom jazyku (dajme tomu, ze C++) != dobry programator
a programator v jednoduchsom jazyku (dajme tomu Java) != zly programator
(- chlapci, zahodte svoje komplexy:))
Programovanie je hlavne o tom, ako (ako rychlo, za ake naklady a ako kvalitne) clovek dokaze vyriesit dany problem - a J. je zatial asi najvyvazenejsi kompromis aky poznam medzi moznostami ktore ponuka a medzi jednoduchostou a prehladnostou (tj. umoznuje koderovi sustredit sa co najviac na samotny problem (a nie na neustale hladanie neuvolnenej pamate a pod.) - pritom mu ale stale ponuka pomerne slusne moznosti) Java (tak ako ine jazyky pred tym) sa nerozsirila preto, ze je to najskvelejsi a najmocnejsi jazyk, ale preto, ze je vyvoj v nej efektivny.

2) v oblasti v ktorej je Java pouzivana dnes, su imho vymozenosti C# nezaujimave (a nevyvazia vyhody samotnej Javy) - tj. nie su dostatocnym dovodom na zmenu "orientacie"

A to je prave ono - oblast C# je sirsi, protoze nabizi vic moznosti. Oblast C# = oblast Javy + C/C++

no to je ale pekna blbost  potom by asi nejlepsi programovaci jazyk byl takovy ktery smicha UPLNE vsechno a bude to takovy mismas kde si kazdy vybere - jooooooo to pak budete mi na vyber ouplne zo vseho

jeste ze nejste kuchar ptz byste asi vsechny otravil temihle dostiky ala microsoft (autor clanku promine to zneuziti tej metafory )

O multiplatforminm reseni si dovolim polemizovat... Kolik plikaci, ktere se kde pisi se nakonec skutecne provozuji na n platformach???

Vite me tahle "vyhoda" javy jaksi nejak unika. Zivim se tim, ze programuji v Jave a muzu vam s jistotou rict, ze ani jedno reseni se neinstaluje vicekrat tak aby pokazde bylo na jine platforme.

Co je dulezite je interoperabilita a ta je v .NET vice nez dobre zarizena a samozrejme je ji mozne velmi dobre naprogramovat i v Jave, nebo PEARLu, nebo delphi nebo C++. Mluvim o SOAPu. Podle meho nazoru, se ukazuje, ze je mnohme dulezitejsi nez napsat jedno reseni pro vsechno, umet a byt schopen pospojovat existujici casti s minimalni zmenou. Totiz kdyz bude mit firma svoje reseni na kterem pracuje 20 let v cobolu, tak asi nebude chtit jen tak ho prevadet do JAvy nebo cehokoliv jineho, jen proto, ze jim to pak pobezi na jinem HW a bude mit par novych funkci. Lepsi je to stare prepouzit jak je, napsat "neco" (SOAP listener) ktery mi zpristupni zvenku onu funkcnost a ty nove funkce uz napisu v tom, v cem to napisu nejrychleji...

P.

Konecne rozumny nazor... Je videt, ze pracujes v realne firme (ktere se asi docela dari).

Dobry den, nam se multiplatformita Javy docela hodi. Vyvijime a testujeme ve firme na Linux (Java, Oracle), aplikace pak bezi na SUNech/SolarisOs. Takze to neni zase tak k nicemu... Vetsinou se muze vyvijet na slabsich strojich/OS a cilova aplikace pobezi na silnejsim serveru/OS.

Dobry den,

nesouhlasim s tim, ze je dobre, ze zde neni podpora dekadektiv DEFINE atd... . Podivej te se napr. na zdrojovy kod knihovny MFC pro C++ a zjistite, ze cely system je zalozen prave na DEFINE. Vklada Vam tam spoustu kodu, ktery byste museli psat samy a kdyz je potreba neco znenit, zmenite jeden radek.
kus kodu MFC (C++) :

#define ZAPNI() try{
#define SKONCI() }catch(CMemoryException *e){e-Delete();}

a pak jednoduse vlozite do projektu napr.

ZAPNI()
CArray array;
array.Add(CPoint(1,1));
SKONCI()


skutecne se domnivam, ze je to chyba, ze to nepodporuji (ale jista zlepseni oproti VB tu jsou)

Jeste vice mi chybí podpora templete... takova pekna vec (viz. predchozi priklad)


S pozdravem Libor Bares

Je fakt, ze define moze usetrit pracu, ale na druhu stranu aj velmi zneprehladnuje vysledny kod. Nikdy totiz clovek nevie, co sa skutocne vlozi do kodu, co moze sposobovat najma pri vacsich projektoch nemale problemy. MFC je presne priklad toh ako sa da define blbo pouzit.

Ano, presne tohle byl duvod proc direktiva #defina byla ze C# odstranena. Co se tyka MFC, tak tam jsou uzitecne jen pro ty, kteri se to nauci memoricky. Takze podle me je lepsi resit to koncepcne spravne, aby kod byl dobre citelny i pro ty, kteri nechteji prolezati spousty #includu nebo definic.

Pokud je podobnost zapisu znamkou toho ze je jazyk obslehnut tak je Java okopirovane C++, s tim ze vsechno sou objekty. Mozna by autor nemusel bejt tak povrchni a podivat se na opravdove rozdily mezi tema jazykama jak uz tu nekdo podotkl nahore.

Zdravim!

Pokud jste clanek cetl az do konce, tak vite, ze je tam srovnani systemovych i syntaktickych vlastnosti C# a Javy. Takze ani ctenar by nemel soudit jen podle kratkeho srovnani co je uvedene jako metafora.

z toho si nic nedelejte; doporucuji vyjet si ruzne reakce Jerryho3 ... pak poznate, ze jen tak placa hlouposti a take kym je placen (predpokladam, ze neni jen tak hloupy a vulgarni a namysleny, jak to z tech jeho reakci vychazi)

jo na jerryho kasli, je to fakt vul - proto je za tim nickem, jinak by ho musela manzelka vyhodit v bytu paaac by nesnesla tu ostudu co ten hlupak tropi

Tak, jak autor pojem java oznacuje misto platforma jako jazyk, stejne chybne dela z C# platformu .NET
K procentum pouziti jazyku. Asi bych se neodvazil tvrdit neco o padesati procentech javy. Ani v pripade C/C++. Ono zalezi na definici programator. Hodne lidi programuje v Delphi a snad jeste vice (Buh nas chran) ve Visual Basicu. Ted mluvim o jakemkoliv programovani. Tyto dve skupiny spolu se serverovyma skriptarema zaberou hodne pres 50 procent. To, ze si nekdo nekde neco zkusi v jave, nebo v c++, se snad neda nazvat ani pouzivani. Co autor nerecene srovnava je pouziti jazyku v enterprise oblasti. A ta posledni tabulka, ta uz budi jen usmev. Co je mysleno kolonkou properties ? Pokud je u javy uvedeno ne, pak proc existuje v JDK uz ani nevim kolik verzi trida java.util.Properties? Co se tyce preprocesoru, tak bych rad autorovi oznamil assertion mechanismus v JDK 1.4. Nejse sice o plnohodnoty preprocessor, ale vzhledem k tomu, ze v clanku byla kritizovana slozitost Cckoveho, pak autora jiste nadchne. Radsi uz skoncim, nebo se upisu k smrtin. Howgh

Myslim, ze polozkou "Properties" v tabulke autor myslel nieco ine ako java.util.Properties - asi myslel na "properties" triedy, tj. premenne s "priamym" prisupom (v C#) - tj. bez get- a set- metod (v Jave)

Jo jasne. V Delphi se tim resi prirazovani a kontrola existence handleru eventu. Co me na jave chybi nejvic je nemoznost referovat metody objektu. Je tu samozrejmne reflexe, ale ta je tak neohrabana, ze stavet na tom neco slozitejsiho se skoro neda.

v C# su fieldy a properties, properties sa definuju pomocou get, set, COM koderom budu tiez urcite zname, fields su klasicke clenske premenne z c++;

k obom sa pristupuje rovnako, len sa definuju inak

Tak jak autor pojem java oznacuje misto platforma jako jazyk, stejne chybne dela z C# platformu .NET
K procentum pouziti jazyku. Asi bych se neodvazil tvrdit neco o padesati procentech javy. Ani v pripade C/C++. Ono zalezi na definici programator. Hodne lidi programuje v Delphi a snad jeste vice (Buh nas chran) ve Visual Basicu. Ted mluvim o jakemkoliv programovani. Tyto dve skupiny spolu se serverovyma skriptarema zaberou hodne pres 50 procent. To, ze si nekdo nekde neco zkusi v jave, nebo v c++, se snad neda nazvat ani pouzivani. Co autor nerecene srovnava je pouziti jazyku v enterprise oblasti. A ta posledni tabulka, ta uz budi jen usmev. Co je mysleno kolonkou properties ? Pokud je u javy uvedeno ne, pak proc existuje v JDK uz ani nevim kolik verzi trida java.util.Properties? Co se tyce preprocesoru, tak bych rad autorovi oznamil assertion mechanismus v JDK 1.4. Nejse sice o plnohodnoty preprocessor, ale vzhledem k tomu, ze v clanku byla kritizovana slozitost Cckoveho, pak autora jiste nadchne. Radsi uz skoncim, nebo se upisu k smrtin. Howgh

A muzete mi prosim rici co je na to posledni tabulce usmevneho? Vite ja se taky rad smeji

Jinak jen na vysvetlenou pro Vas, "properties" je oficielni termin z vyvoje MS, kterym se oznacuje vlastnost jazyka, kdy muzete k jednotlivym parametrum pristupovat formou:

trida.prop1 = 10;

trida.prop2 = "neco";

No snad jsem Vam to vysvetlil uz to neni tak legracni

Mejte se.

Uvital bych, kdyby autor zverejnil vice konkretnich rozdilu mezi jazyky. Detailne se zminil pouze o slovech "virtual", "abstract" a "override", rad bych vedel o vice podobnych rozdilech.

("Shodou okolnosti" prave tato tri slova se hojne vyskytuji v Delphi, ale to je jen tak na okraj, protoze ani Delfini urcite nebyli prvni.) :))

Muj nazor na budouci vyvoj je ponekud skepticky. Myslim, ze programovat budem v tom, co nam bude prikazano. A prikazy budou udileny na zaklade marketingu. Ja osobne jsem moc malej pan, abych mohl rozhodovat, v cem programovat.

S tym Delphi mas pravdu. Ale vies preco? Pretoze autor C# je autor Pascalu obsiahnuteho v Delphi...

To je pravda nebo vtip?

(Rad bych to videl nekde napsany, nez tomu zacnu verit.)

Anders Hejlsberg

SAN JOSE, Calif. -- April 12, 2001 -- Microsoft Corp. today announced that Anders Hejlsberg, a distinguished engineer at Microsoft, has been awarded Dr. Dobb's Journal's Excellence in Programming Award for 2000. Dr. Dobb's Journal presents the award annually to individuals who, in the spirit of innovation and cooperation, have made significant and lasting contributions to the advancement of software development. Hejlsberg was honored Wednesday evening at an awards ceremony at the Software Development 2001 West trade show for his many contributions to furthering programming language development, including Delphi, Turbo Pascal and, most recently, the C# (pronounced C sharp) programming language.

...since joining Microsoft in 1996, Anders Hejlsberg has played a pivotal role in the development and design of Visual J++ and the Windows Foundation Classes. Hejlsberg currently works on COM+ and Visual Studio 7. He is also making significant contributions to technologies that are still under development. Before he joined Microsoft, Hejlsberg was a principal engineer at Borland International; as one of the company's first employees, he was the original author of Turbo Pascal and later worked as the chief architect of the Delphi product line. Prior to coming to the United States, Hejlsberg studied engineering at the Technical University of Denmark...

inak dobry clanok,

trochu na skodu veci je, ze autor casto pletie Javu ako jazyk a Javu ako platformu...

No to mate pravdu, ale je to take proto, ze ty pojmy njesou vydefinovane. Samotny author C# se chlubil tim, ze oproti Sunu aspon MS bude mit jasne definovane co je programovaci jazyk a co platforma. Takze souhlasim s Vami, ale meli bychom si stezovat na jine adrese

"Jeden z nejpopulárnějších a také nejpoužívanějších programovacích jazyků dneška je Java"

to ma autor odkial? V jave programuje velmi malo ludi a je vnej spravenych velmi malo programov. Nehovorte ze nie! Mozno... 5%?

Tohle se imho dost lisi v Evrope a v Americe

Autor ma tak trochu pravdu, ale vy take: myslim, ze jiz hodne programatoru javu alespon vyzkouselo (tedy hodne pouzivany jazyk), a co se tyce velke popularity, myslim, ze nemate ani vy zadne namitky.

podla vysledkov prieskumu robeneho medzi profesionalnymi US programatormi, ktory som niekde videl v lete 2001 (linku som uz nenasiel):

~50% programatorov ovlada jazyk Java

nemozno sa teda cudovat, ze MS z vacsej casti Javu okopcil...

za profesionalneho programatora zrejme povazovali takeho, ktory sa programovanim zivy...

50%ovlada... ale nie pouziva. Kazdy dobry programator ovlada vacsinu programovacich jazykov, ale pracuje max v 2och.

to je pravda... v kazdom pripade to bolo ale najviac zo vsetkych jazykov... dokonca C++ a C scitane bolo este daleko za javou... o pascale ani nehovorim... no, niekde nakonci sa tam objavil dokonca aj vbasic...

(scitane: neboli tam 2krat zaratani ti, ktori ovladaju c ^ c++)

vid moj pripsevok nizsie. Ak tu Javu nik nepouziva, cim to potom je, ze su programatori v Jave na trhu prace taki ziadani a maju platy ake maju ???

Ak mozem ja z mojho okolia, platy Java developer su v Silicon Valley v priemere nizsie ako platy C/C++ developerov, nehovoriac o embedded developeroch v C.
Momentalne je prebytok Java developerov na trhu - je to sposobene obrovskym mnozstvom Java developerom, nakolko kazdy, kdo si chcel pinknut v IT sfere, sa stal Java developerom. e to najlahsia cesta, ako sa stat developerom...

kolko ludi, tolko nazorov :)
ja nie som v sillicon valey, ale zas sillicon valey nie je pupok sveta - vychadzam len z toho, co uvadza napr. v nizsie uvedenom linku na zdnete (http://news.zdnet.co.uk/story/0,,t269-s2102802,00.html) a co sa presne zhoduje s mojou skusenostou - tj. ze skuseni programatori v Jave su stale uzky profil a firmy su za ne ochotne platit (s dorazom na slovo skuseni). A to aj napriek tomu, ze Java je relativne jednoduchy jazyk a ovladnut samotnu syntax jazyka je naozaj pre mnohych "brnkacka" - takze tomu, ze na trhu je kopec ludi ktory sa snazia o podobne miesta sa vobec nedivim - a vidim to skor ako plus Javy...(iny problem je ale ovladnutie jednotlivych technologii a API, schopnost ich spravne pouzivat - a to chce aj skusenosti). Samozrejme embedded vyvojari v C, progr. drajvrov a pod. je trosku iny pripad, pretoze to je dost specializovana vec a aj trh je mensi - a nie je to vec ktoru zvladne hocikto... Takze tak... este jeden link na Zdnete k teme Java vs. C++ :)
http://zdnet.com.com/2100-1104-503983.html?legacy=zdnn

Bohuzial, Silicon Valley ten pocitacovy pupok je, ci sa ti paci alebo nie. Ved aj ta Java odtialto vyliezla...

Moje vlastne skusenosti a rozhovory s headhuntermi potvrdzuju to, co som napisal vyssie. Ale samozrejme, ze to neznamena, ze nikdo nechce Java developerov alebo implementovat Java technologiu. Co sa tyka mnozstva Java developerov na trhu, vela firiem dokazalo prekonvertovat C++ developerov AJ na Java developerov a takyto developer, ktory ovlada spolahlivo oba jazyky, je velmi cenny (a samozrejme patricne plateny). Tym sa dostavaju do ofsajdu tradicni cisto-Java orientovani developeri. Problem je ten, ze cesta od C++ do Javy trva par tyzdnov. Opacne je to dost problematicke...
Cize poucenie z toho je, ze cim viac jazykov, prip. systemov vies, tym si lepsie umiestnitelny na trhu.  

ZDNet nie je doveryhodny zdroj informacii...

1. cize myslis, ze na dobry plat ako Javista mam narok len ak ovladam aj C++ ? to by sa mi hodilo ako ceckar som par rokov robil...:)
2. neslo by sem-tam pouzit na miesto slova "developer" nejaky iny vyraz ?? :))

Poviem ti len moju skusenost:
Ja sice nerobim sice ako cisty developer (pozn. nizsie), ale ako architekt - ale v mojom pripade vzdy zavazilo, ze som mal skusenosti s roznych technologii a jazykov. Plati totiz, ze cim viac toho vies, tak tym mas vacsi rozhlad a tym dokazes pruznejsie reagovat na zmeny.
Ani ja neznasam slovo developer, ale este horsie je programator (pripomina mi to tu skatulku co prepaluje EPROM-ky), nehovoriac o slove vyvojar. Developer pouzivam preto, ze je to najcastejsie vyjadrenie programatora v US... CO navrhujes ty?

no ja som myslel prave na toho vyvojara...:)

No přece KODÉR

"jeden z nejpouzivanejsich" != "nejpouzivanejsi"

"V jave programuje velmi malo ludi a je vnej spravenych velmi malo programov"
Uff, vazne ???????
Odporucam pozriet si niektory zo serverov na vyhladavanie prac. miest - napr. monster.com (cely svet), jobserve.com (najma europa a UK) a pod... Mne to naslo na jobsearch.monster.com (US): "JAVA" = najdenych 3209 ponuk, "Visual Basic" = 1879, "C++" = 1349, "C#" = 50 , ".NET" = 236, "COBOL" = 823, "Perl" = 1130, "Delphi" = 155
Hm, cim to asi tak bude ? Zeby vsetci vyzadovali znalosti Javy a potom ich nutili robit v C++ ?? :))
Ale inak je fakt, ze aj mnoho ludi z IT zije v predstavach ktore si kedysi v casoch ked Java startovala na zaklade jednej, IMHO viac menej mrtvej technologie, tj. appletov - a Javu ma zaskatulkovanu a dalej sa o nu nezaujima. Ale dnes je Java uz uplne inde, predovsetkym ako platforma c.1 pre enterprise riesenia (napr.bankovnictvo a pod.), ocakava sa nastup v oblasti mobilnych zariadeni.

plne suhlasim s nazorom...

okrem:  ... predstavach ktore si kedysi v casoch ked Java startovala na zaklade jednej, IMHO viac menej mrtvej technologie, tj. appletov ...

java nestartovala na appletoch... java bola uvedena skor ako sa myslelo na nejake applety... len sa potom chlapikom v Sune zazdalo, ze by bolo celkom chytre taketo nieco urobit.

a proti appletom nikto nic nemoze mat... nevidim v nich ziadny problem, casto sa nieco inak riesit neda... (resp. da, ale pre usera nie tak pohodlne)...

ok, ale vdaka appletom sa Java dostala na svetlo sveta. Nemam proti nim nic, ale ako som povedal, J. je dnes uz o niecom inom.
Inak (k povodnemu prispevku) - este nieco k tym prac.miestam a platom programatorov v Jave: http://news.zdnet.co.uk/story/0,,t269-s2102802,00.html

co sa tyka webu> myslim, ze applety mali svoje opodstatnenie.. vyvoj v dhtml a css odvtedy ale hodne pokrocil a preto si myslim, ze momentalne applety uz vacsinou stracaju svoj zmysel. trocha off topic - bolo by fajn ak by nieco nahradilo aj flash.. mozno SMIL. uvidime.

Tvoj vysledok hladania je irelevantny. Kopa firiem, ked hlada nejakeho cloveka, naprace do kolonky Experience vsetky jazyky a technologie, ktore vo firme poznaju...

Odporucam ti podrobnejsie pozriet jednotlive fleky, ktore ti monster.com najde. Potom budes mat lepsiu predstavu. A tak isto - .Net nie je este ani na trhu, co cakas, ze najdes 3.000 volnych flekov? Potrva minimalne pol roka-rok, kym firmy zacnu seriozne rozmyslat nad .Net technologiou a jej implementaciou do svojej firmy...

ten moj vysledok vyhladavania je ale v kazdom pripade relevantnejsi nez tvoje "pocity" zo sillicon valley... :) (alebo, zeby vsetci vpisovali do ponuk "Java" (iba Javu, ine jazyky uz nie:) aj do miest, ktore s nou nemaju nic spolocne ?). Neviem o co ti ide (kam tym smerujes), ale zda sa mi, ze s tvojimi argumentami, ako sa hovori, varis z vody :)

Cela tato debata sa naozaj vari z vody. Ty stavias vsetko na monster.com a jednom zbehnutom query s keywordom Java, ja na skusenostiach ake mam. Tu sa asi dopredu nepohneme, takze z mojej strany som to uzavrel...

ok. :)
peace..