Opada li popularnost C-a?

Po tome sto igre ne cine trziste. Najveci deo programiranja danas se radi po internim IT departmentima firmi, i to je trziste na koje ova dva jezika ciljaju. Procitaj ponovo thread, videces o cemu se radi.

Uzgred, relativna sporost Jave i .NETa u odnosu na native kod proizilazi iz memory managementa, a ne iz bytecodea.

Koliko te shvatam, ti govoriš o softveru koji se radi po narudžbini. Ako govorimo o gotovom komercijalnom softveru (recimo velikihsoftverskih kompanija), onda su tržište operativnih sistema, tržište knacelarijskih alata i tržište video igara tri najveća softverska tržišta.

Takođe, ako sam te dobro razumeo, jezici Java, C++ i C# se ne koriste za baš iste stvari, ali im se namena delimično preoklapa, to jest postoje poslovi na kojima su međusobno konkurentni i tu se uloga jezika C++ smanjuje.

Da li sam vas sada bolje razumeo?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Da, tako je. Obojica se potpuno slazemo jedan sa drugim :)

Iako je trziste komercijalnog softvera najvece po kolicini para, ono je relativno malo po broju ljudi. Ako uzmes da jedan Microsoft ima nekoliko hiljada programera, to nije nista nasuprot armijama programera po firmama koji prave raznorazne access front endove.

Tu se najvise i oseca taj opad popularnosti Ca. Primera radi, danas je mnogo teze u Beogradu naci C posao nego sto je to bilo pre recimo 5 godina. Naravno, to ima veze sa vrstom softverske industrije koje cveta kod nas, kao i sa tim sto generalno u Evropi i nema mnogo gotovog komercijalnog softvera (koji se mahom pise u Cu) i sam tim i poslova u toj oblasti. To je ujedno i najveca razlika izmedju programiranja u Evropi i Americi.

Da se vratim na preklapanje namene - postoji tendencija da se ta oblast gde se preklapaju namene Ca i ostalih jezika povecava na stetu Ca zbog rasta hardvera. Sa brzim hardverom optimizacija i brzina vecine klasa softvera postaje sve manje bitna, i tu onda polako ulecu managed jezici.

Naravno, ne radi se niokakvoj revoluciji preko noci, niti o tome da ce sutra biti sve zajedno 15 C poslova na svetu (i da ce svi oni biti u Redmondu), vec o jednom sporom procesu koji je ponovo krenuo - vec smo ga vidjali ranije. C nece izumreti, ali ce verovatno biti marginalizovan, a posle je samo stvar dogovora gde je crta u % trzista poslova ispod koje se neki jezik moze smatrati prakticno mrtav.

Nekada je pod operativnim sistemom MS DOS postojao programski jezik Clipper koji je bio specijalizovan za baze podataka. Clipper kompajler je zapravo proizvodio pseudokod koji je interpretirao interpreter ugrađen u svaki bogovetni izvršni fajl koji je proizveo taj kompajler.

Pseudokod je neka vrsta mašinski nezavisnog koda koji je optimizovan za brzo izvršavanje, a ne za čitanje i menjanje od strane programera, kao što je to slučaj sa čistim interpreterskim jezicima gde se program poklapa sa sorsom. Naravno, interpreter pseudokoda je mašinski zavisan.

No, takav kod se ne može po brzini meriti sa mašinski zavisnim kodom koji proizvede kompajler nekog čistog komajlerskog jezika, ali se izvršava mnogo brže od programa pisanih na čistim interpreterskim jezicima.

Čisto sumnjam da izvršavanje programa u okviru plugin-ova ne usporava program u odnosu na izvršavanje mašinski zavisnog programa koji je generisao kompajler čistog kompajlerskog jezika, ali ako jezici Java i C# dopuštaju kompajliranje tako da s dobije klasičan mašinski zavisan .exe fajl (kao da je rađeno nu nekom čisto kompajlerskom jeziku), onda si svakako u pravu.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Upravo se o tome radi. I .NET i Java kompajliraju svoj bytecode u native masinski kod prilikom ucitavanja programa. To znaci da ucitavanje traje duze, ali to je jednokratna stvar, i obicno nije problem. .NET cak ima i mogucnost da se program iskompajlira za vreme instalacije.

Ali kao sto sam rekao ranije, memory management je veci problem. Zato je i MC++ vrlo interesantan - to je C++ koji moze ali ne mora da koristi GC, a kompajlira se u bytecode. Znaci mozes da uzmes najobicniji C kod sa new/delete i da dobijes .NET bytecode. E to vec ne bi trebalo da bude bitno sporije od obicnog Ca.

A mislim da je i najbrzi tu u konkurenciji Java VS C# VS D

http://www.digitalmars.com/d/

Potpis

http://speedy-order.com

Relja, hvala na odgovoru, a da li bi mogao da mi objasniš pojmove bytecode i GC?



Koji je najbrži?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Bytecode je taj 'metaasembler' u koji se kompajliraju Java i .NET jezici. To je nesto sto lici na asembler, samo je dosta viseg nivoa. Pred izvrsavanje programa se bytecode iskompajlira u pravi native asembler za konkretnu masinu.

GC je garbage collector, to je ono sto povremeno pauzira .NET porgram i krece da brise memoriju koja se vise ne koristi.

jos pohadjam srednju skolu i moje misljenje je da c/c++ kao jezik nikad nece izumrjet ili past u zaborav... na to me navelo nekoliko stvari... imam dosta prijatelja koji se bave programiranjem (uce programirati) i to bas u tim jezicima, u skolama koje imaju informatiku 4 godine uce upravo ti jezici, svake godine odrzava se nekoliko natjecanja u tim jezicima, na faksevima se uce ti jezici...

kako ja to vidim c & cpp nikad nece sici s scene vec njihova primjena moze biti samo umanjena... znam da nisam rekao nista novo ali morao sam iznjeti svoje misljenje

A koje su prednosti bytecode-a nad normalnim mašinski zavisnim kodom? Može li .NET da proizvede .exe fajl sa najnormalnijim mašinskim kodom, pa da se program učitava brže?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Nisam neki ekspert za programske jezike, ali čini mi se da je izrečeno par nepreciznih tvrđenja o javi. Ako grešim ispravite me.

Pominje se da JVM radi JIT, međutim to nije podrazumevan režim rada još od prošlog milenijuma. Ukoliko se ne navede opcija -server radi se u client odnosno hotspot modu. JVM interpretira bajtkod sve dok ne naiđe na usko grlo ili ti bottleneck, hotspot. Tada se taj deo koda kompajlira u mašinski.

Javini stručnjaci misle da je ovo najbolji režim rada. Najstarije JVM su isključivo interpretirale bajtkod što je bilo presporo. Sledeća generacija JVM je sve kompajlirala u startu što je dovodilo do sporog pokretanja programa i velike upotrebe memorije.

C#VM još koristi JIT kompajliranje.

Današnje JVM rade GC u prilagodljivom modu. Kada se pravi velika količina "smeća" koristi se "stop and copy" pristup kada se izvršavanje programa zaustavlja da bi se pokupilo smeće. Ako se ne pravi mnogo smeća tada se VM prilagođava i koristi 2. tehniku skupljanja smeća "mark and sweep" koja ne stopira program.

Zar se java ne koristi i za programiranje nekih običnih desktop aplikacija? Ja sam čuo da je OpenOffice.org u njoj napisan kao i SPSS pa čak i simulaciona igra IL-2M Sturmovik. I po meni jedan od najboljih free editora jEdit je čedo jave, a da ne pominjem UML alate i alate za java programiranje.

Potpis

Bolje džaba ležat nego džaba radit.

Ne znam za ostale, ali OpenOffice je napisan u C++-u.

Potpis

IOCC

dobro zlatko, u pravu si oko JVMa, ali to nije bilo toliko bitno, tj nismo hteli da širimo priču na tu stranu..

nego, nedeljko je pokrenuo otprilike isto pitanje koje sam ja hteo da postavim..

za Javu je bytecode bitan, jer omogućava izvršavanje aplikacije na svakoj platformi. nasuprot tome, .NET cilja na jednu do dve platforme (čak i ako računamo i mobilne uređaje), tako da mi uopšte nije jasna svrha postojanja bajtkoda u istom.

GC može da se implementira i bez njega, kao što i postoje C++ biblioteke sa GCom.

takođe, menaged api je moguđe sprovesti i bez bajtkoda, ako se koriste samo indirektni načini pristupa resursima/memoriji. na primer, bounds checking na nizovima u toku izvršavanja programa (runtime) je vrlo lako moguće dobiti čak i sa običnom C++ kompajlerom.

čak ni RTTI nije nemoguć sa kompajliranim jezicima, recimo delphi ima to još odaaavno.

dakle reljam, jer možeš navedeš bar jedan dobar razlog za korišćenje bajtkoda u .NET?

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

MS navodi mnoge razloge, od kojih neki stoje, a neki kao što si i sam napomenuo baš i ne stoje, ali je po mom mišljenju ključna stvar sigurnost. Sa VM-om je lakše sprečiti "zao" kod da čini razne nepodopštine.

Potpis

IOCC

U stvari ono sto pitate je zasto se konacni JIT korak ne obavi prilikom samog builda, vec se radi prilikom instalacije ili startovanja.

Ima nekoliko razloga - nezavisnost od frameworka, podrska za vise platformi, optimizacija za konkretan procesor, mali fajlovi. Windows se danas vrti na tri platforme (x86, x64, ia64), i to je neracunajuci gomilu CE varijanti i raznoraznih drugih MS embedded uredjaja (VoIP telefoni, bankomati, BMWovi :)).

Nezavisnost od frameworka znaci da ti mozes da pokrenes da program pisan za v1.0 na frameworku v1.1 i da dobijes sve security fixove i optimizacije koje su sredjene u novoj verziji. Slicnu stvar je moguce uraditi samo na nivou DLLova, ali to ti ne resava problem nekih malo centralnijih stvari kao sto su recimo reflection, koji je deo samo jezika i kao takav ne bi lako mogao da ga izdvojis u DLL.

Optimizacija za konkretan procesor je takodje zanimljiva stvar. Ako ja danas napisem .NET program, ja cu sutra moci da ga pokrenem na Pentiumu V i odgovarajucem frameworku, i sve ce da radi sa novim instrukcijama / velicinom kesa / cime vec. Ako bi se program direktno kompajlirao u native, onda bi zauvek ostao na verziji za koju je kompajliran. Bas zbog toga gomila programa danas radi sporije jer mora da targetuje instruction set od recimo Pentiuma II da bi svuda radila. Jako je malo programa gde dobijes odvojenu verziju za Athlon, odvojenu za Pentium II i odvojenu za Pentium IV. Sa JITovanjem uvek dobijas odgovarajucu verziju.

Konacno, fajlovi su mnogo, mnogo manji. Mali .NET EXEi su nekoliko kilobajta i to bez kompresije. Srednji .NET programi sa par prozora itd, su obicno reda velicine dvadesetak kilobajta sto je jako malo. Za godinu-dve ce svako imati na masini .NET framework, i onda ces moci da distribuiras samo jedan mali EXE koji se zipuje na desetak kilobajta.

Sve u svemu JITovanje je Dobra Stvar, ali zato i postoji opcija da se JITuje prilikom instalacije da ne bi moralo svaki put kada se startuje program. JITovanje je doduse dovoljno brzo da i nije neki problem osim ako nemas neki program koji pozivas desetine puta u sekundi - za tako nesto je bolje da ga JITujes prilikom instalacije, ili da redizajniras sistem tako da ne dize novi proces toliko cesto.

Čisto da napomenem da pomoću alata Dev C++ 4 može da se napravi kompletna MDI aplikacija veličine 10K bez ikakvog .NET Framework-a i bytecode-a. Pritom, ta MDI aplikacija ne zahteva nikakve dodatne .dll fajlove da bi radila. Štos je u tome što je cela funkcionalnost Windows-a već isprogramirana u Win API-ju koji je uključen u Windows (koji drugačije ne bi mogao da radi), pa samim tim nema potrebe da se taj kod uključuje u sam program, već program sadrži samo kod koji poziva Win API.

Svaki kompajler ima biblioteku funkcija koje ugrađuje u svaki bogovetni .exe fajl, i biblioteke koje uključuje samo ako se to eksplicitno traži. Što je ona prva biblioteka manja, to su programi sa osnovnom funkcionalnošću manji, ali je češće potrebno tražiti uključivanje neke druge biblioteke da bi se koristile neke funkcije.

E sad, mana Win API-ja je na primer što nije objektno orjentisan, pa se teže koristi. Stotga su napravljeni objektni omotači oko Win API-ja kao što su OWL, MFC, VCL i CLX, koji su povećavali veličinu izvršnog fajla koji je bio opterećen tim bibliotekama budući da ni jedna od njih nije nikada bila standardni deo Windows-a kao Win API. Čak i ako .NET Framework postane sastavni deo Windows-a kao Direct X, sačekajte samo da i on dobije svoj omotač, pa da vidite kako će .exe fajlovi ponovo da se goje.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Zašto se koristi VM i bajtkod?
Prvo radi politike kompajliraj jednom teraj svugde. To baš nije potrebno MS-u, ali je javi veoma važno.
Radi sigurnosti jer se ipak čitav program odvija u VM-u koja služi kao sandbox.
Program je mnogo manji nego exe varijanta, sto je za mreže potrebno. Npr. slanje objekata preko mreže, ranije je bilo primanje appleta, iyvršavanje koda ne nekim prenosnim uređajima...
VM optimizira izvršavanje bajtkoda za svaku mašinu, OS, i svaku priliku. Dakle ako se isti program pokrene nekoliko puta on će svaki put biti rayličito optimiziran zavisno koji se delovi koriste. Ako se ne koristi neki deo programa koji je u nekoj odvojenoj klasi, ta se klasa neće ni učitati.
Bajtkod može da se dobije kompajliranjem raznih programskih jezika. To je ono na šta se .NET fura. Kada su MS-ovci prezentovali na faxu tu revolucionarnu tehnologiju pominjali su čak i da se klase pisane u COBOL-u mogu koristiti u .NET-u. To je i ranije moglo da se radi korisćenjem CORBA i sl. ali je ovako mnogo jednostavnije i sigurnije. Čak i JVM može slično, npr. da se python kod kompajlira u javin bajtkod i/ili da se u pythonu koriste javine klase.

Potpis

Bolje džaba ležat nego džaba radit.

Jel'? Odakle ti to... Pogledaj moj post gore. Portabilnost na razlicitim platformama jeste bitan scenario za MS.

Čini mi se da je Au197/97 u pravu. MS prodaje softver zatvorenog koda za nekoliko tačno određenih platformi tako da mu ne treba kompatibilnost na nivou izvršnog koda, već samo na nivou sorsa, budući da je onda sors lako iskompajlirati za nekoliko ciljnih platformi.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

1. U igri IL2 Java je koriscenja kao script-jezik, odnosno za kontrolu toka igre. Low-level/mission-critical stvari (engine) su u C++u.

2. jEdit je fenomenalan editor, ali je spor do bola, zahvaljujuci vec pomenutoj javi :)