Na prvi pogled zakljucujem:

Smuti pa prospi jezik!

Npr.
1. Ima templejtove a napravili su string i niz kao tip.
2. Nacrnise #define.


Jezik treba da bude ko formalna teorija: minimalan, neprotivurecan i potpun.
Ostalo su teoreme ( biblioteke, pr. STL u C++).
Ma ko da je pisao D bolje da ga nije pisao.

ovo je matora tema, ali ja sam skoro cuo za D programski jezik i resio da ga isprobam. Isprobao sam ga, svideo mi se i samo sam hteo da vidim da li se na es-u pisalo o ovome...

D je jezik po mom ukusu, izbaceno je sve ono iz c++ zbog cega ne volim c++, a posto sam ja svoje prve programerske korake imao u vb-u (znam, recicete da je los izbor za pocetnika, ali ja tad nisam nameravao da se ozbiljno bavim programiranjem) postojanje string tipa i dinamicnih nizova ugradjenih u jezik mi mnogo olaksavaju posao, takodje izbacen je preprocessor (jesu nacrnili #define, ali po meni je to sa razlogom :D) zbog koga nikad nisam voleo da citam tudji c++ kod.
a postojanje garbage collectora u mnogome olaksava rad sa memorijom (tj, ne moram vise da se brinem da li sam oslobodio svu memoriju koju sam zauzeo)...

mislim da cu se drazti D-a odsad, a da c++ vise necu uzimati u ruke :)

preporucio bih svima koji nisu probali D, da urade to jer ne mogu nista da izgube, samo da dobiju!

Mogu da izgube, šansu da nauče jezik za koji postoje plaćeni poslovi.
Ako ti je C++ težak drži se VB, jer od D nema 'leba. :)

ma nije meni tezak c++, samo ga ne volim jer je (za mene) mnoooogo ne citljiv, jeste da je najplaceniji posao c++ programera, ali nije sve u parama :)
bar ja tako gledam na programiranje (i mogu tako da posmatram stvari jer tek treba da upishem fax, tako da me jos uvek moji izdrzavaju), a i ja mislim da se i na programske jezike moze primeniti ono "covek vredi onoliko koliko jezika poznaje", mozda ce i D jednog dana (kazem mozda) biti zastupljeniji, ko zna...

Razgledao sam D dosta puta i čak imao prili-ke da raspravljam sa autorom jezika Walterom, ali sam došao do zaključka da je učenje D-a gubljenje vremena. Niti ćeš naći posao sa njim, niti može da te nauči modernim programskim stilovima i tehnikama. Ako već imaš vremena za učenje jezika koji ne mora da ti se obavezno isplati, pogledaj npr Haskell ili Boo.

Ja sam se tek "sreo" sa D-om, tako da cu provesti malo vremena uceci ga jer (kao sto sam vec rekao) je jezik po mom ukusu. Znam da je znanje c++-a A MUST, ali sasvim sam siguran da cu za neke svoje licne potrebe (ili open source projektem a jedan sam vec zapoceo u D-u) radije programirati u D-u nego u C++u, a mozda i sve ovo pricam jer nikako da nateram sebe da uzmem c++ i da radim samo u njemu nekih 5-6 meseci dok se ne naviknem...
sto se tice Haskell-a i Boo-a, pogledacu ih mada koliko sam video (samo preleteo pogledom) Haskell ne podrzava oop a Boo je baziran na Phytonu (a Phyton i Perl su jedini jezici u kojim ZNAM da nikad necu raditi, mnogo su "ruzni", perl pogotovu :D)

C++ uopšte nije "A MUST" - sve zavisi čime želiš da se baviš.

Haskell naravno nije OO, to je "čist" funkcionalan jezik i baš zato ti savetujem da ga pogledaš.

Boo ima sintaksu baziranu na Pythonu ali je suštinski vrlo različit od njega. Boo ima statički sistem tipova, za razliku od Pythona. Što se "lepote" tiče, to je naravno stvar ukusa, ali priznajem da je ovo prvi put da vidim da neko stavlja Perl i Python u isti koš kad se tiče lepote sintakse.

Postoje neke OO ekstenzije Haskella (Haskell++, O'Haskell), a i razne emulacije unutar Haskellovog sustava tipova koji je pak dovoljno moćan da prodrži većinu onog što se uobičajeno podrazumijeva pod sintagmom "OO" (a bome i štošta što ni D niti C++ neće imati tako brzo):

http://homepages.cwi.nl/~ralf/OOHaskell/



Naravno, smisao istraživačkih jezika kao što su Boo ili Haskell nije da se koriste u produkciji ili da rješavaju neke "konkretne" probleme - tu su da radi mentalne tjelovježbe (pogledaj primjere za quick sort ili računanje Hammingovih ili Fibonaccijevih brojevima u Haskell one-linerima), ili da guraju granice nedolazećih tehnologija u mainstream jezicima (ukoliko ih ne razvijaju programeri-hobisti već korporativni istraživački labovi).

Ako imaš dovoljno slobodnog vremena definitivno se posveti barem jednoj "nestardardnoj" paradigmi, u jezicima kao što su Scheme, Haskell ili O'Caml. Trenutno je stanje stvari da mainstream jezici evoluiraju brže nego ikad prije, do-jučer nepojmljve featurez u roku par godina postanu standardni idiomi korištenja. Recimo, vrlo je moguće da sljedeća iteracija Jave bude pružala neki shit zvan "poopćena sučelja" (generalized interfaces), a koja bi bila mahom bazirana na Haskellovim "klasama tipova" (type classes - ovako Haskell ostvaruje ad-hoc polimorfizam):

http://lambda-the-ultimate.org/node/1939

Također ni ja ne bih trpao u isti koš Python i Perl po ljepoti sintakse. Python ipak nije write-only jezik ;)

Što se tiče D-a: za moj je ukus previše high-level i low-level koncepata nakalemljeno u jedan jezik. D izgleda pokušava biti "Katica za sve", pri čemu ne uspijeva ekscelirati ni u čemu posebnom. Java i LISP su odavno pokazali da skup featurea jezika nema nužno korelacije sa tržišnim uspjehom, svaki sa svoje strane ljestvice naravno. Walter Bright me neodoljivo podsjeća na križara koji vodi rat koji ne može dobiti, i koji je odavno izgubio papinu encikliku u kojoj piše protiv koga se "bori" :)

D je zaista dobar programski jezik za ucenje modernih tehnologija u programiranju. Jednom kada covek nauci sta su zapravo template-ovi (a sta bi trebalo da budu - hate No1 na C++), ili kako zapravo treba da izgleda cisto i lepo nasledjivanje (bez brljavstina koje nastaju zbog virtual-a - hate No2 na C++), najbitnije od svega izostanak include fajlova (hate No3 na C++ i tu stajem). Licno bih mnogo pre uveo da se u nastavi na nasim fakultetima (pmf, ftn, ...) uci D nego Java ili C++.

Takodje, istina je da u D-u ne leze pare, bar ne kao jeziku u kome ce biti pisana aplikacija. S druge strane, savladavanjem D-a, verujem da bi velikoj vecini programera pomoglo da dobiju pravu sliku o OO programiranju, koje zaista jeste neophodno.

@alexione: konacno neko da "stane na moju stranu" (sala naravno) :)

sto se tice toga sto sam pomenuo Perl i Phyton "u istom kosu", ja sam mislio na "kos necitljivih jezika", Phyton jeste dosta citljiviji od Perla, ali po meni je zasluzio da se nadje u istoj grupi sa Perlom (sto se tice lepote koda) iz razloga sto su blokovi komandi u Phytonu odvojeni whitespaceom (tj istim nivoom whitespacea), to je koliko ja znam o Phytonu, nisam ni pokusavao da ga ucim jer sam prvo pogledao neke primere u Phytonu i nisam mogao lako da ih procitam... moguce je da gresim, ali to je moje misljenje...

jos jedan + kod D-a u odnosu na C/C++ je u brzini kompajliranja, D kompajler kod od 10-ak modula (ukupno oko 3000 loc) kompajlira za nekih 10-ak sekundi na 400MHz dok recimo VC++ slican kod moze da kompajlira i do 1 minut (na 400MHz)


i ja bih voleo da postoji mogucnost da se D uci na fakultetima, ali o tome mozemo samo da mastamo, bar za sada...


offtopic:
da li neko zna kakav je izbor jezika na FON-u?

Ne samo da se ja ne slažem, već se ni Walter Bright ne slaže: http://www.digitalmars.com/d/overview.html



Moram da dodam da se ne slažem ni sa Walterom da su Basic i Java dobri jezici za početnike (ili za bilo koga drugog :) ), a ni da je D posebno dobar za iskusne programere.



Upravo tako. Dojadio je i Bogu i ljudima na comp.lang.c++.moderated listi sa svojom glupavom propagandom. Što je najsmešnije, on sam živi od prodaje C++ kompajlera :)

Kao što je već par puta spomenuto - za učenje modernih, najmodernijih i cutting-edge tehnologija postoje neusporedivo superiorniji akademski (i raznorazni "skriptni" dinamički tipizirani jezici koji niču kao gljive poslije kiše) jezici :) Stvarno ne vidim gdje se tu D uklapa.



Turing-potpun (vrijeme kompajliranja je neodlučivo :) metajezik sa najružnijom i nagadnijom moguće zamislivom sintaksom, rame uz rame sa Brainfuckom i Intercalom? :)



Što točno želiš ovim reći? Da su java-style po defaultu virtualne metode u D-u Dobra Stvar (TM) ? :)



To je tzv. off-side pravilo i predstavlja jedan od featurea koje je Python maznuo od Haskella. Pravila možeš nabrojati na prste jedne ruke i vrlo su intuitivna. Inače, u Haskellu možeš i eksplicitno pisati {, } i ; kao separatore izraza, no prije ili kasnije ćeš shvatiti da je to ružniji način :)



Možda je brži (iako je gornja izjava o odnosu brzina kompajliranja sumnjivo nesrazmjerna :), ali sumnjam da D kompajler emitira nativni kod po performansama imalo usporedivim sa VC++. Koliko vidim ima i jedna implementacija sa GCC back-endom, ali vjerojatno o njoj ne pričaš pošto je GCC dosta spor inače :)

to je verovatno tacno, mada DMD (D kompajler) ima i -optimize switch sa kojim proces kompajliranja se po duzini trajanja priblizava onom VC++a, tako da verovatno (sigurno) ispegla malo generisani kod sa tim switchom (postojanje opcije za optimizovanje je nesto sto ja volim kod kompajlera, nisam do sada video ni jedan c++ kompajler u kom mozes da iskljucis optimizaciju, ali nisam mnogo ni razgledao, da budem iskren)


ja mislim da ipak nije lepo tako govoriti o nekome ko je ulozio trud i vreme u nesto sto je pre svega besplatno a i nekome korisno, ja sam uvek bio na strani open source-a i free softwarea i uvek cu ceniti ljude koji proizvode besplatan (i open source) softver, jer sam ja dosta naucio iz open source projekata i resio sam da se oduzim open source zajednici tako sto cu i sam postatio deo nje (naravno, ja sebe jos uvek smatram pocetnikom, ali ima vremena, tek mi je 19 godina :D)



ne pricam o GDC-u jer ga nisam probao :D

Inace za C++ ne postoje besplatni kompajleri i alati...??

Zasto, meni su template-i uredni i EFIKASNI.

I sta bi time studenti dobili?


D mi izgleda kao da se nalazi izmedju C++ i C# (Jave), sta je po meni jako lose. Time se nalazi nigdje. C++ ce opet ostati konkurentan u svom podrucju, a C# (Java) u svome, nemoguce im je parirati iz sredine.

Lijepo je sto se covjek potrudio napraviti tako nesto i sto jos se trudi propagirati svoj proizvod, ali ruku na srce moje misljenje je da D nikada nece zazivjeti.
Ono sto mene veseli je novi C++ standard.

Stvar kompromisa. Da ne govorim uopsteno, na pmf-u u ns-u, veliki broj studenata koji zavrse jednostavno nemaju pravu sliku o tome sta je OO i sta su zapravo svi mehanizmi koji u njemu postoje (uci se Java). Racunaj i da veliki broj njih jednostavno nikad ranije nije programirao (iz hobija, ako nista drugo). U takvoj situaciji, Eiffel, Ocaml, Haskell bi bili prevelik zalogaj. U takvoj situaciji, D bi bio mnogo bolji od drugih jezika.



C++ ima najgore moguce resenje. Provero u praksi, potkrepljeni dokaz gomile znoja i nerava. Da, veoma je dobro da su sve metode po defaultu virtualne. To je inace Java/C#/D/Eiffel-style. Ono sto fali u Javi je sto nikad ne znas da li metodu prvi put definises ili je redefinises. U Eiffel-u za to postoji redefine, u C#-u i u D-u tu je override. Cak i Delphi poseduje override (mada je lose sto moras da navedes da je funkcija virtualna).



LOL Da li pricao o istom jeziku, istim template-ovima?



Koji je tvoj predlog?

C++ template metaprogramiranje je "uredno" samo mazohistima. Zar te gledajući npr. ovaj ne prolaze trnci duž leđne moždine? :)

Ako pod "efiksasnost" podrazumijevaš compile-time instancijaciju koja uključuje gubitak svih informacija o generičkom tipu i tako prisiljava kompilator da emitira bloatan unshearable međukod, potencijalno neodlučivno mnogo dugo odgađa završetak kompilacije, daje opskurne stranice i stranice grešaka za mismatched tipove nad generičkim algoritmima (koliko ono dugo čekamo na Stepanovljeve "koncepte"?) i uskraćuje bilo kakve mogućnosti runtime optimiranja - onda da, C++ templates su "efikasni".

Slika koju ovdje iznosiš mi se čini u najmanju ruku blago distorzirana. Kakvi su to budući softver inženjeri koji "nikad ranije nisu programirali", sve do polaganja kolegija koji uči OOP na nekoj višoj godini? Jadni takvi studenti ako započnu sa C++ ili D, paralelno upijajući neke opskurnalije jezika i štrebetajući "industry best practice" idiome i paterne. Takvim studentima će IMHO odabir jezika će im biti najmanji problem :) Možda je i najbolje da i ostanu na Javi, heh.

Sveučilišta predaju akademske jezike sa razlogom - nakon njih su industrijski jezici koji 20-30 godina kaskaju za njima mačji kašalj. Nekome tko je OO principe učio kroz Smalltalk, CLOS-style metaobjektne protokole i process calculus će Java izgledati kao dječja igra. Naravno, pristup i metodologija organizacije programerskih kolegija je izrazito specifična za pojedini fakultet, svakojaki su ekstremi mogući :)



Vjerujem da za svakog tko tvrdi da je to Dobra Stvar (TM), bi se našlo barem još toliko fanatika koji bi rekli da nije :)

U C#, koji je najmlađi i najmoderniji od spomenutih jezika, po defaultu metode _nisu_ virtualne. Misliš zaista da ta odluka nije donesena na temelju gomile dokaza, znoja i nerava, odnosno odgovarajuće argumentirana od strane trusta mozgova koji definiraju buduće strategije MS-ovih proizvoda? Vjerujem da će guglanje naći barem 3-4 _jako dobra_ razloga od strane Hejlsberga et al.

Inače, u modernoj idiomatskoj Javi se preko anotacija uvijek specificira eksplicitni override kako bi kompajler mogao uhvatiti kad to ne radiš.



Da. Iako u praksi većina kompajlera preko zastavica kontrolira dubinu instancijacije tako da ipak nije Turing-neodlučivo.. :)

Kako znas da je ovo dobro rijesenje, da nije moglo bolje? Nigdje ne stoji da moras ovako iscrpno koristiti template.

Govorimo o C++, jeli tako, nasljednik C? Cemu se cudis onda, C++ mora ostati dosljedan svojim pocetnim postavkama, odnosno pokusti rijesiti sto vise stvari unutar compile-time-a, da bi se dobilo na efikasnosti. Nus produkt jest bloatan kod, ali "that is the way C++ is".
Runtime optimiranje unutar C++, malo s alokatorom, cim jos? Ne cuje se bas cesto za "runtime optimizacija" i "C++" zajedno. Mozda sam jednostavno neinformiran, ali nebih bas puno racunao na runtime opt. dok pisem C++ kod.
Dali je STL efikasan?

Template metaprogramiranje mozda nije najefikasnije, ali je sigurno jedno od boljih rijesenja za mnoge probleme.

1. Neko rece: "Turing-potpun (vrijeme kompajliranja je neodlučivo :) metajezik sa najružnijom i nagadnijom moguće zamislivom sintaksom, rame uz rame sa Brainfuckom i Intercalom? :)"

Vreme kompajliranja i uopste kompajler nemaju veze sa problemom odlucivosti nekog algoritma. Odlucivost nekog algoritma je pitanje da li se algoritam na odgovarajuci input zavrsava u konacnom vremenu, naravno svi znamo da je u opstem slucaju (algoritam koji na inputu prima algoritam i kaze "da" ako se algoirtam na ulazu zavrsava u konacnom vremenu, "ne" u suprotnom slucaju) taj problem neodluciv, ali kompajler o tome nema pojma, posto on kompajlira (prevodi) program sa jednog programskog jezika, a ne odlucuje da li se taj program zaustavlja ili ne (sto je u pojedinacnim slucajevima moguce). Ako je program konacan u prostoru (a takvi su svi po definiciji algoritma kao Tjuringove masine) onda je kompajliranje svakog programa proces koji se zavrsava u konacnom vremenu. Stoga vreme kompajliranja ne moze biti neodlucivo. Moze biti samo vreme izvrsavanja. Sto nas dovodi do zakljucka da se ovde principijelno ne razlikuje kompajler od interpretera. Pitam se kako nekom pre mene ova izjava nije IZBOLA oci. Ja je svrstavam u top glupost koju sam u skorije vreme ovde procitao.


2. Neko rece: "Programski jezici treba da budu kao formalne teorije, minimalan, neprotivurecan i potpun (ako se dobro secam)"
Ok, postoje zahtevi i misljenja da su minimalisticki programski jezici (sa minimalnim brojem konstrukcija, koje cine bazu izracunljivih konstrukcija) dobri programski jezici. Jedan od zagovornika minimalizma je i Niklaus Wirth, po njemu dobar je jezik koji od konstrukcija ima samo: IF, WHILE i naredbu dodele (onakva kakva je u oberonu), a od tipova podataka: osnovne proste tipove, nizove, strukture(slogove) i pointere i nista vise. Ali zasto bi se neko odrekao na primer REPEAT konstrukcije ili SWITCH konstrukcije. Ne znam stvarno, ali oduzimanjem ovakve slobode, ne dobijamo nista na sigurnijem procesu pisanja koda.
Drugo svaki zahtev programskog jezika jeste da bude neprotivurecan, ne mozemo napraviti neprotivurecan programski jezik jer bi onda ostali uskraceni za okruzenje koje bi prevodilo taj program na jezik Tjurinzovih automata (funkcionalna tacka gledista), ali i za okruzenje koje bi izvrsavalo takav program.
Treci zahtev da programski jezik bude potpun je preteran zahtev, ne mozemo zahtevati potpunost neke formalne teorije ako zahtevamo neprotivurecnost (Gedelova teorema).
I pored toga pisanje programa u formalizmu najnizeg nivoa bilo bi jako tesko. Probaj na primer da napises generativnu gramatiku koja generise proste brojeve. Neces moci tako lako, prvo ces morati da napises Tjuringovu masinu koja bljuje proste brojeve, pa da je posle prevedes. Okruzenje u kome se programi pisu kao formalne teorije je jako ne-intuitivno, ali i korisno za izgradnju racunarske intuicije.

3. Ko vam je rekao da je C++ objektno-orjentisani jezik. C++ je smece. Kada uzmes paradigmu programskog jezika i napravis jezik koji odgovara tom modelu, a da pri tome odrzis kompatibilnost sa drugom paradigmom programskih jezika koja je daleko od ove prve najcesce dobijes s*****.

4. Efikanost nekog programskog jezika nema veze sa doticnim programskim jezikom. Stoga ne mozes reci C++ je brzi od Jave jer se C++ kompajlira a JAVA na primer interpretira. Sta ako se java interpretira na masini koja hardverski da interpretira java byte code. Izjave bilo koji program napisan programskom jeziku A je efikasniji od istog takvog programa napisanog u programskom jeziku B su jako relativna stvar i to uopste ne treba da bude stvar po kome se opredeljujemo za programski jezik kao prva stvar. Bitna jeste ali ne i kljucna.

Samo izrazavam duboko slaganje s ovom izjavom. C++ je pokusao, ali nije uspio postati OOP jezik.
Imate tu opciju, ali koliko je vas cesto koristi virtual. Ako posao to bas zahtijeva, bolje je uzeti drugi jezik.

Ne vredi, nisam izdržao. Moram da odreagujem.

Vrlo čudno poređenje programskih jezika sa formalnim teorijama.

Formalna teorija je:

- Minimalna ako se izbacivanjem bilo kog pravila ili bilo koje aksiome dobija sistem sa užim skupom teorema.
- Neprotivrečna ako barem jedna formula te teorije nije teorema te teorije.
- Kompletna ako se dodavanjem bilo koje formule, koja nije teorema, kao nove aksiome, dobija protivrečna formalna teorija.

Šta li to znači da je programski jezik minimalan? Koliko znam, i na Tjuringove mašine se mogu nametnuti dodatna ograničenja tako da se dobije isti skup izračunljivih relacija/funkcija. Štaviše, svakom sistemu izračunljivosti se mogu pravila dodatno ograničiti, a da se suštinski ništa ne izgubi.

Šta li znači da je programski jezik neprotivrečan? Mogu da shvatim šta bi to bila nedvosmislednost programskog jezika, ali neprotivrečnost ne.

Šta li to znači da je programski jezik kompletan? Ako to znači da čini potpun sistem izračunljivosti u smislu ekvivalentnosti sa Tjuringovom mašinom, onda su svi programski jezici takvi.


???

Molim gospodu koja se pozivaju na Gedelove teoreme da ih prvo lepo nauče. Ima koliko god hoćeš neprotivrečnih, a ipak kompletnih formalnih teorija. Takva je recimo, svaka formalna teorija koja opisuje klasičan iskazni račun, a obuhvata pravilo zamene (supstitucije) koje glasi: "Ako je formula F(p₁,...,p_n) ma koja teorema u kojoj se od iskaznih slova eventualno pojavljuju slova p₁,...,p_n i ako su F₁,...,F_n ma koje iskazne formule, onda je i formula F(F₁,...,F_n) teorema".

C++ je uprkos svim svojim manama uspešan jezik i praktično cela softverska infrastruktura koju danas koristimo je pravljena ili u C++u ili u njegovom prethodniku C-u. D može da bude "čist" i "objektno orijentisan" do mile volje, to nije uspešan jezik i šanse da postane uspešan su minimalne.

Uzgred, nikako mi nije jasno da u 2007-oj još neko smatra "SmallTalk" - stil objektnog programiranja modernim. To je bilo moderno pre 25 godina. Moderni jezici današnjice (C# i u manjoj meri C++) pozajmljuju nove karakteristike iz funkcionalnih jezika.

Ti implementiraj monade u C++ na ljepši način bolje od boost gurua i slobodno ih kontribuiraj zajednici, pa ćemo se onda pozivat na argumente "što bi bilo kad bi bilo". Dotada ne pokušavaj na sličan način osporiti "urednost" C++ templatea, ok?



Ako bloatan kod definiraš efikasnim - onda C++ way on jest "efikasan", to i govorim :) Čitljivost koda i pragmatičnost prema programeru u mismathced tipovima varijabli također nisu bogzna kakva prednost C++ way-a.



Nema razloga koristiti termine kao "top gluposti" koje su na granici vrijeđanja. Mogao bih i ja biti jednako zajedljiv, i vjeruj mi ne bi izgledalo jako lijepo.

Ako imaš turing-ekvivalentan sustav tipova (sustav tipova kao računski model, termin turing-potpun se više koristi za neki specifični izračun, a većina izračuna nisu turing-potpuni, već je dovoljna npr. primitivna rekurzija), tada typechecking postaje turing-neodlučiv, a to je _nepoželjna_ karakteristika.

Gledaj to ovako: U C++ templateima je moguće konstruirati univerzalni Turingov stroj. Drugim riječima, moguće je bilo koju (algoritamski) izračunljivu fju izračunati tijekom faze kompilacije izvornog koda.

Slažeš li se sad da je neodlučivo hoće li (kad? i ako?) kompajler zaustaviti kompajlirati izvorni kod? :) Ako ne, koji to hiper-izračunljiv računski model koristi semantički analizator dotičnog? :)



Tko kaže da se trebaš odreknuti? :) Za to postoje sintaksni makroi preko kojih manipuliraš AST-om i dodaješ sintaksni šećer kako ti ćefne. Alan Perlis je svojedobno za LISP rekao da je to "programibilni programski jezik" :)

IMHO dodavanje sintaksnog šećera nad nekim minimalnim formalizmom (recimo netipiziranim lambda računom, sa sintaksom i semantikom od po nekoliko linija koda) može samo povećati fleksibilnog jezika, ne smanjiti ga.



Imam neki osjećaj da generator prostih brojeva ne zahtijeva cijeli Turingov stroj (odnosno gramatiku neograničenih produkcija) - ali to sad nije ni bitno. Slažem se da je svođenje postupka programiranja ne formalnu verifikaciju iskazanih algoritama previše mentalno naporan proces za uobičajene svrhe (ne i za specifične), baš zato to i ne radimo. Za neke mission-critical svrhe to je već druga priča.



Da, zato je i skovan termin Turing tarpit kako bi se stalo na kraj argumentima "Moj jezik je jači od tvog" :)

Zanimljivo! Imaš li neku ideju dokaza kako bi se ostvario operator pretrage (minimizacije)?

Dobar osećaj! To je zato što je skup prostih brojeva, recimo, primitivno rekurzivan.

http://en.wikipedia.org/wiki/Machine_that_always_halts

Boost... i cinilo mi se da je to njihovo maslo.
Da bi nesto bilo neuredno (tvoja kontra teza), onda nesto mora biti uredno.
Ono je uredno samo zato jer ti ne mozes naci bolji (uredniji) nacin da ono napravis, a zadrzis efikasnost i namjenu.

Meni bloat koda ne igra nikakvu ulogu, ne krade mi performanse, onda za mene to je efikasno.

Pa jednom kad je napisan UTS (recimo ovako - prvi google hit, vjerojatno postoje i sa manjim brojem simbola/stanja), nad njim stvoriti nešto programirljivo za ljude, npr. RAM stroj (beskonačna traka TS se preslikava u prebrojivo beskonačan broj registara RAM stroja, pojedine argumente fje koja je argument mi operatora iskopiramo u registre) i za kojeg bi tad bilo relativno trivijalno ostvariti mi operator. Npr. poput ovdje prikazanog:

LOL, njihovo "maslo" :) Ne bi da je primarna svrha boost biblioteka rušenje ugleda "urednosti" C++ templating koda..



Koja zamjena teza :) Ne, ovo je neuredno jer izgleda odvratno. Ako takav kod pišu world-class profesionalci, koliko uredniji može biti nekog manje iskusnog developera? Cijeli koncept C++ template metaprogramiranja je baziran na prljavim hackovima, pošto su njegove mogućnosti otkrivene _slučajno_ (C++ komitet je t.m. učinio nešto moćnijim nego što je itko tamo zamišljao).

Sorry, ali tvrditi da da je ovo "uredno" i da "služi svrsi" može reći samo netko tko nije probao nešto drugo (bolje).

Kakav osjećaj u tebi budi sljedeća linija koda:



? :)



Kao što je netko već spomenuo, efikasnost je relativna stvar, a nabrojao sam i neke stvari koje su IMHO puno važnije od puke efikasnosti, a koje C++ t.m. ne pruža...

D nije loš, ideja je odlična ali jednostavno ne može uspeti.

Ideja da se popravi C++ koji je pri rođenju skrljan što protivprirodnim bludom sa C-om što zbog toga što u vremene kad je nastao nije bilo nekh industriski popularnih OOP jezika (mada je koncept teorijski bio razvijen i akademski primenjen na SmallTalk-u). C++ je brzo dobio popularnost pa je ostao backward zaključan. Što se grbo rodi vrijeme ne ispravi. Kad je već tako D je mogao malo da se sintaksom odmakne više od ružnjikavog C++-a ali šta je tu je.

Iza D jezika ne stoji ni jedna jaka kompanija, niti je on FLOSS. A C++ guraju moćni.

Dalje ljudi koji se bave C++ su uglavnom krem krema, njima nije potreban bolji jezik oni se i u tom bangavom osećaju kao kod kuće i sve drže pod kontrolom što opet umanjuje mogućnost da D zaživi.

Osim toga i upotreba C++ na čiju zamenu D gađa je sve manja i manja (http://www.tiobe.com/tiobe_index/index.htm). Više se C++ ni ne uči na faxovima...

Znas, to je bilo u sali, veliki ratnice... :)

Dok se ne upoznam s biti gornje linije nije mi nista bolje od template-a.

Razmisljajuci sam dosao do zakljucka da si dijelom u pravu.
Template-e je ne moguce -uredno- natjerati da budu svjesni tipa. To ne znaci da je sintaxa neuredna, samo u ovoj situaciji kod postaje strasan.

Ali ja cijelo vrijeme govorim o ovom C++, dok ti razmisljas o nekakvom super C++ koji je dosao iz buducnosti.
C++ je napravljen s primatom na -efikasnosti- i s jako malim zrtvama (skoro nikakvim) u odnosu na C.
Nisam strucnjak za IT povijest, ali ako se ne varam tempatei su stvoreni za C++. Stvoreni su tako da se rijesi sve za vrijeme compile-time-a, i time si dobio ovo sto imas - mocan alat koji ne ovisi o runtimeu.
Mislim da je jasno zasto se 'virtual' smatra trnom u C++ ideologiji.

Po meni je to sramotno. Jer gledajuci na siroku populaciju koja ide na fax, tu su ljudi koji se nikad nisu ili su se slabo sureli s programiranjem. Njima ugurati odmah Javu ili neki slicni visi+ OOP jezik je glupost. Oni se nikad nece vratiti na nizu skalu (C/C++) i time postaju manje konkurentni na trzistu rada.

Nikako se ne slazem sa ovom izjavom. Naime, sustina edukacije u programiranju (bar kako je ja posmatram) nije u tome da naucis dobar, vec da naucis dobre principe. Uciti principe OOP-a na C++ - to je nesto sto nikome ne zelim niti preporucujem. Java, D, C#, Delphi - svi su pogodniji za edukaciju OOP-a.

Sto se tice toga da ti studenti nece biti konkurentni, takodje se ne slazem. Primer je nekoliko koleginica iz moje generacije koje su upravo dosle na fax bez iskustva u programiranju, ima kurs iz OOP-a u Javi, a zatim su se bez problema uklopile u C++ (za diplomski ili u firmi na poslu, zavisno od slucaja).

Slazem se s time da je ucenje OOP-a na C++ nepogodno, ali zelim reci da nije sve u OOP.
Dakako da je OOP bitan fator u danjasnjem vremenu, ali zar nebi trebali posvetiti vise vremena na faxu nizim tehnologijama kakve pruza C++ ili cak C.
Java, C# su na dosta visokom nivou od same arhitekture racunala, za razliku od C/C++.
Java i C# se takodjer vrlo brzo uce, ako imas podlogu nizeg jezika.
Nizi jezik lakse stvara dublje shvacanje racunala i time dobivamo inzinjere, a ne developere.

Naravno da ovo ne mora biti pravilo, ali nije ni iznimka.

Evo jedan clanak o Javi u skolstvu: http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html

Templejtovi su nuklearno oruzje u programiranju.
Potrebno je dosta krvi, suza i znoja da se osvoje.
Posle toga je vec druga prica.

Takoje videti jos neka moja misljenja o njima: www.ddmrm.com/coding/cpp/template/h2at/h2at_index.html
I jos bih dodao sta koga briga dali je program sklepan za par dana u VB ( ne shvatiti kao uvredu usmerenu ka VB )
ili su za to koriscenji teski templejtovi pa se jadan kompajler mucio da to prevede a program pisan mesecima.
Vazno je da rezultujuci program uspesno obavlja namenu.

Templejtovi su alat. Kome se ne svidjaju neka ne koriste.

Rekoh u jednoj od predhodnih poruka:


Ne shvatati bas doslovno. Ono kao je bas kao a ne isto sto i.
To je bila mala labava paralela i a ne 1-1 i na poredjenje.
Kad bih nastavio ovo da objasnjavam potrosio bih puno karaktera i jos bih se na kraju prilicno upleo u tu svoju teoriju.

Ta izjava je bila usmerena ka:

Znaci ista stvar se moze uraditi na dva razlicita nacina i to po istu cenu ( vreme, zivci, planiranje, pisanje, ... )


I dalje tvrdim da je D najruzniji jezik koji sam ikad na svetu video.

A još pogodniji su SmallTalk, Ruby ili Eiffel, ali kao što reče NrmMyth nije sve u OOP-u. To je jedna paradgima, koja ima dosta primene u nekim aplikacijama, a manje u nekim drugim; treba je poznavati, naravno, ali meriti kvalitet jezika po tome koliko je "objektan" nema baš mnogo smisla.

Uglavnom, za sistemsko programiranje se mora znati C ili C++. Ako želiš da se baviš time, moraš da znaš jedan od ova dva jezika i tačka. Ako voliš web aplikacije ili recimo finansijsko-rečunovodstvene, lako možeš da prođeš i bez njih.

Na koje nize tehnologije mislis? Strukture, pokazivace, staticke nizove...? Za pravilno shvatanje arhitekture nije ti potreban C, nego asembler, i potrebno je da shvatis kako se asemblerski kod prevodi u binarni. U odnosu na arhitekturu racunara, C je na visokom nivou. A C++ na jos visem.



Da, ali to treba da bude izbor studenta - treba da postoji obrazovanje za obe ove profesije, jer su podjednako bitne i neophodne.




Da te pitam nesto: da li si nekad dosao na 50% projekta i preuzeo kod da nastavis da radis na njemu? Ne, uopste nije svejedno kako je pisan kod. I nije jedino bitno da program radi. To je osnovna greska u razmisljanju sa stanovista softverskog inzenjerstva.




Tvoje je pravo da imas svoje misljenje i svoj ukus. Ipak, ako ti se svidja C++, a ne svidja ti se D, onda zaista imas, u najmanju ruku, cudan pogled na programske jezike. To je kao da kazes da ti se svidja obicna gitara, ali ti se ne svidja bas-gitara (ili obrnuto).

Kakav god da je programski jezik on NE moze da spreci programera da napise tesko odrziv kod.
Pr. u skoro svim programskim jezicima imenovanje promenjivih moze dobro da upropasti stvar.
Sa druge strane isto to imenovanje moze da ima i suprotan efekat.

Ako si sef, gazda, direktor, vodja tima jednostavno dekretom zabrani ono sto mislis da moze da steti i gotova stvar.

Odoh u OT samo tako.

Haskell nema promenljive.

Znao sam da ce se ovo dogoditi, ali nisam htio prije naglasavati, cemu sad uvlacenje assemblera u pricu.
Java, C# su managed jezici, odnosno puno su vise udaljeni npr. assemblera nego sto su to C, C++.
Ti ovo dozivljavas kao napad da sebe, ali ja samo govorim da prosjecan korisnik Jave se nikad nece zapitati kako se to serializiraju podatci, kako se marshalaju strukture i slicne poveznice s unmanaged stvarima.

Slazem se, da treba postojati izbor, ali i ne s tim da su obje profesije jednako bitne.
Simbolicno: inzinjer extends developer

Ma daj kakva je to usporedba. I zasto se nekome mora svidjati bas-gitara ako mu se svidja obicna...?


Vrijeme ce pokazati dali je D vrijedan trzista, ali iskreno sumnjam u to.

Nije teško napisati brži kod u C++ nego u C-u, pa čak i nego u asm-u
uz današnje kompajlere, tako da i nije toliko dalji od mašine od C-a - ako uopšte.

Evo kako izgleda iskusan D programer.

Ovako izgleda proces zapošljavanja kandidata koji je D ekspert (sa malo ili bez C/C++ iskustva):

Rezime -> LOL! -> kanta. :)

Programski jezik jeste formalni jezik, te je model programskog jezika
(skup leskickih, sintaksnih i semantickih pravila) jedna formalna teorija.
Programski jezik je minimalan ako skup njegovih sintaksnih konstrukcija cini
bazu semanticke izrazajnosti sto znaci da svakom semantickom konceptu (uslov, iteracija,
petlja) odgovara jedna sintaksna konstrukcija.
Ako za jedan semanticki koncept imas vise sintaksnih konstrukcija gubi se minimalnost,
na primer za petlju imas FOR, WHILE i REPEAT sintaksne konstrukcije.

Neprotivurecnost programskog jezika kao formalnog jezika jeste apriorna.
Pod njom se podrazumeva to da svaki program u nekom programskom jeziku uvek na isti input daje isti output.
Da nije tako izgubio bi se toliko nam drag determinizam algoritma, tj. izgubili
bi mogucnost funkcionalnog intepretiranja, kao i kompajliranja (ovo je otprilike
objasnjenje na ono ???)
Komplentnost programskog jezika jeste kompletnost u smislu izracunljivosti, jezik
mora biti takav da pokrije skup svih izracunljivih funkcija. Zahtev komplenosti
je preteran jer postoje citave klase izracunljivih funkcija koje su beskorisne i koje
za sada nisu mogle da se ufituju da budu model bilo kakvog nama zanimljivog fenomena.

Formalna teorija je neprotivurecna ako se u njoj ne moze izvesti iskaz A i njegova
negacija. Ako bar jedna formula neke formalne teorije nije njena teorema
to ne znaci da u skupu teorema nema jednu teoremu i njenu negaciju koja je
takodje teorema.

Ima koliko god hoces neprotivurecnih i kompletnih formalnih teorija, ali krajnje
beskorisnih sa stanovista izracunljivosti. U mojoj recenici kada sam rekao da se
ne moze zahtevati potpunost formalne teorije ako zahtevamo neprotivurecnost, ono
formalne teorije se odnosilo na programski jezik. Formalno gledano recenica nije
ispravna kada se izvuce iz konteksta. Jasno je da postoje neprotivurecne i
kompletne formalne teorije, ali ne nivou ranga jednog ozbiljnijeg (funkcionalnijeg)
programskog jezika.

U C++ templetima je moguce izdrkavanje svekoliko. Ali opet podsecam da sam ja
negde izjavio da je C++ nedostojan toga da se nazove ozbiljnim programskim
jezikom. Ako je moguce bilo koju izracunljivu funkciju izracunati tokom kompajliranja
onda kompajler uopste nije kompajler, gubi se smisao naziva kompajler i
to se onda zove INTERPRETER, sto je bitno razlicito od KOMPAJLER. Na tlu INTERPRETERA
mozemo govoriti o algoritamskoj neodlucivosti, na nivou KOMPAJLERA ne mozemo,
kompajliranje je proces prevodjenja jednog jezika u drugi koje se uvek zavrsava
u konacnom vremenu, posto su programi prostorno konacni.
Stoga jedino u cemu mogu da se slozim da je algoritamski neodlucivo da INTERPRETER
zavrsi sa INTERPRETIRANJEM necega, nikako KOMPAJLER sa KOMPAJLIRANJEM necega.
Ne znam cemu potreba da uokviru jednog KOMPAJLERA imamo INTEPRETER, ako nesto
tako postoji onda se gubi smisao samog programskog JEZIKA koji tako nesto ima.
Sto opet potvrdjuje moju cinjenicu da je C++ obicno s***** i smece.

Svrha minimalizma nije da postoje neki koncepti koji prosiruju isti taj minimalizam
i cime se gubi smisao istog, nego da se svesno ogranice neke stvari zbog razno raznih
pojava i fenomena koje bi bile moguce kada iste ne bi bile ogranicene. Stoga sta ce
mi minimalni programski jezik koji mi nudi predprocesorske mogucnosti prosirenja.
Gubi se smisao i odjednom uvidjas da ti je vise koda u predprocesoru nego u samom
jeziku. Kakvo s***** :)

Generator prostih brojeva ne zahteva celu Tjuringovu masinu, ali ja to nisam ni tvrdio.
Ja sam rekao da je lakse napisati Tjuringovu masinu koja bljuje proste brojeve pa je
posle prevesti u generativnu gramatiku po standardnom algoritmu kojim se to radi,
nego napisati generativnu gramatiku koja generise proste brojeve,
kao ilustraciju cinjenice da programiranje na nivou generativnih gramatika jeste jako neintuitivno.

C++ s***** i smeće? Pa ti mora da si student ;)

Ili student ili profesor - uglavnom neko ko nema baš mnogo veze sa stvarnim svetom :)

U stvarnom svetu (u ovom slucaju, game development), C++ zaista ume da bude izvor velikog broja problema.

Baš kao što i stvarni svijet (tj. IT industrija) uglavnom nema veze sa kriterijima izvrsnosti prilikom (prirodnog) selektiranja softverskih proizvoda. Nažalost, dugoročno prevladavaju tehnologije koje su izvorno stvorene tek kao najbolja (kratoročno gledano) rješenja za konkretne probleme u danoj točci prostora i vremena, pri čemu se obično tokom vremena mutiliraju do neprepoznatljivosti i beskorisnosti, a zbog stvorene baze ulaganja (ljudski kadrovi, razvojni alati, literatura, ovisnost o legacy standardima/protokolima, korisnička baza) su prisutni i desetljećima nakon što je to ikad itko mogao sanjati. To vrijedi kako i za COBOL, C i UNIX, tako i za C++ i Javu.

Sa današnjeg stajališta, C++ _je_ smeće. Evo i Nrmyth je konačno (nakon duge i teške muke :) priznao da je _jedini_ razlog pro C++ templatinga dobivena compile-time učinkovitost, nauštrb odvratne sintakse, bloata i nerazumljivih stranica i stranica opskurnih grešaka kompajlera kad uradiš nešto tipa sort(2,2). Bojim se da samo taj kriterij danas više nije toliko relevantan kao i nekad.

Baš kao što bi Richard Gabriel rekao, nažalost gore jest bolje. Korisne reference:

http://en.wikipedia.org/wiki/Worse_is_Better

http://www.naggum.no/worse-is-better.html

http://www.dreamsongs.com/Files/AcceptanceModels.pdf

Ako se nekome da čitati cijeli knjigu (Richard P. Gabriel - Patterns of Software (PDF - 1.2MB, 235s)

Mene nije sram priznati promjenu misljenja. Toliko egoistican programer nisam... :)

Ali isto malo pretjerujes. Kao da su ti templatei ubili i mater i oca.


Tip<A, B, C> bla, bla, bla. Sta je tu tako odvratno u samoj sintaxi?
Mislim da nijedna konstrukcija koju su mogli smisliti, preko koje bi mi mogli prinositi tipove, ne moze biti toliko bolja od ove koju vec imamo.


Zar to nije problem nastao zbog "lijenosti kompajlera"? Onako preko oka sam uvjeren da te opskurne greske koje izbaci kompajler mogu proci jedan odredjen face-lift.

Game developmenta nebi bilo da nema C++... cemu onda ovo.



Znaci pocelo je, poceo je taj sveti rat protiv otaca nasih - C++-a. Ako se ne varam ista stvar je bila prije mnogo godina samo se rat vodio protiv assemblera.

Odgovorite sebi ovo: Dali su jos uvijek u svijetu informacionih tehnologija potrebne unmanaged aplikacije?
Ako je odgovor DA, onda nam je jos uvijek potreban C++ jer u tom podrucju mu nema boljeg.
Ako je odgovor Ne, onda bi trebali razmisliti kako cete napraviti performance konzumirajucu aplikaciju u managed svijetu, jer ja mislim da racunala jos nisu spremna za to.

Milina je pisati u C# naprema C++. Isto tako je bilo milina pisati u C poslije assemblera. I tako ce biti milna pisati u necem trecam poslije C#.
Prirodni tok vremena ide, ali JA mislim da vrijeme C++ jos nije proslo.

- Skup svih reči nad nekim alfabetom je skup svih konačnih nizova čiji su članovi slova tog alfabeta, uključujući i prazan niz kao reč dužine nula koja se ne sastoji ni od jednog slova tog alfabeta.

- Formalni jezik čine alfabet i skup reču tog jezika, koji je izvestan podskup skupa svih reči nad tim alfabetom.

- Formalnu teoriju čine alfabet, skup formula (koji je podskup skupa svih reči nad tim alfabetom i zajedno sa alfabetom čini jezik te formalne teorije), skup aksioma koji je podskup skupa formula i skup pravila izvođenja koja su relacije sa bar dva argumenta.

- Formalnu gramatiku čine dva disjunktna alfabeta, skup završnih i skup nezavršnih slova, početno slovo, koji je nezavršno slovo i skup pravila izvođenja, koja su relacije sa dva argumenta nad skupom svih reči sa slovima iz unije oba alfabeta.

- Formalnoj gramatici pridružujemo jezik sa istim alfabetom, čiji je skup reči skup svih reči nad sskupom završnih slova, koja se mogu dobiti konačnom primenom pravila izvođenja polazeći od početnog slova. Međutim, jezik se ne mora zadavati preko gramatike i različite gramatike mogu dazi isti jezik, tako da treba voditi računa o pravljenju razlike između tih pojmova.

- Formalna gramatika je, u odnosu na formalni jezik, bliži pojam formalnoj teoriji, jer osim alfabeta (koji u slučaju formalne gramatike obuhvata dve vrste slova - završna i nezavršna) ima i pravila izvođenja, kao i početni simbol kao aksiomu. Međutim, da bismo dobili formalnu teoriju, treba na neki način zadati i skup formula.

Skup formula mora biti podskup skupa svih reči nad odgovarajućim alfabetom, koji obuhvata sve reči odgovarajućeg formalne gramatike (jer će one biti teoreme te formalne teorije, kao reči izvodive u konačnom broju koraka polazeći od početnog simbola konačnom primenom pravila izvođenja). Obratiti pažnju da skup svih reči formalne gramatike nije isto što i skup svih reči nad njenim alfabetom.

Zbog toga, način pridruživanja skupa formula nije jednoznačno određen, pa ne postoji podrazumevani (dogovoreni) način pridruživanbja formalnih teorija formalnim gramatikama. No. možemo se mi dogovoriti, za potrebe ove rasprave oko načina na koji ćemo birati skup formula.

Ako skup formula definišemo kao skup svih reči date formalne gramatike, onda če se skup formula biti isto što i skup teorema, pa će ta formalna teorija svakako biti kompletna i protivrečna, bez obzira od kakve smo gramatike pošli. Ako li pak skup formula definišemo kao skup svih reči nad odgovarajućim alfabetom, onda će ta formalna teorija biti protivrečna ako isamo ako su sve reči nad tim alfabetom izvodive u toj formalnoj gramatici. Napominjem da ceo ovaj pasus nema nikave veze sa Gedelovim teoremama nepotpunosti.

Dakle, lako je formalnoj gramatici pridružiti formalnu teoriju čiji će skup teorema biti skup svih reči te gramatike, ali kompletnost te teorije bitno zavisi od toga kako joj definišemo skup formula.

Prvo, takav pojam minimalnosti zavisi od izbora semantike datog programskog jezika. Drugo, koji je programski jezik u tom smislu minimalan? Možeš ubacivati komentare i preoznačavati promenljive koliko god hoćeš. U programskim jezicima u kojima nema provere granica indeksa upotrebu n promenljivih istog tipa možeš zameniti upotrebom niza od tri elementa, jer se adrese članova sa konstantnim indeksima izračunavaju u fazi prevođenja, pa dobijaš isti izbršni fajl. Nije teško zamisliti semantiku programskog jezika BASIC u jojoj će sledeća dva BASIC programa imati istu semantiku:

Nije teško zaključiti da ni Tjuringova mašina nije u tom smislu minimalna.

A šta ćemo sa programskim jezicima kao što su Java i (sve popularniji) C#, koji zbog nepredvidivosti trenutka uključivanja skupljača đubreta gube determinizam?

I kakve onda ima veze taj pojam kompletnosti sa Gedelovim teoremama nepotpunosti? Naprotiv, po definicijama koje si ovde naveo, svi programski jezici su kompletni, a najveći broj njih je deterministički (ili "neprotivrečan", kako ti kažeš).

A šta ćemo sa formalnim teorijama u kojima nemamo negaciju? Recimo, alfabet se sastoji od slova a i b. Ako formalna teorija opisuje ili obuhvata nekakvu logiku (a ne mora opisivati, niti obuhvatati nikakvu logiku), koja obuhvata negaciju (a logika ne mora obavezno da obuhvata negaciju), onda u najvećem broju slučajeva (što je slučaj npr. kod klasične logike), a u zavisnosti od toga koja je logika u pitanju, sve formule su teoreme ako i samo ako postoji teorema čija je negacija takođe teorema.

Onako kako si definisao pojmove "neprotivrečnosti" (?) i kompletnosti programskij jezika, oni nemaju nikakve veze sa pojmovima neprotivrečnosti i kompletnosti formalnih teorija, pa ni sa Gedelovim teoremama nepotpunosti. Tjuringova mašina je deterministički i kompletan sistem izračunljivosti.

A čemu minimalizam, kada nije ostvariv?

_{[Ovu poruku je menjao Nedeljko dana 23.01.2007. u 17:34 GMT+1]}

Slažem se da bi za PJ općenito trebala vrijediti "as simple as possible - but no simpler" škola mišljenja. Nažalost, povijest je pokazala da takvi stavovi obično dovode do izuzetno glupih zabluda koje se s vremenom toliko uvriježe da postanu vječni dio kulture "dobre prakse". Po Teoremu o strukturiranom programu, flowchart-izračunljive fje su također turing-izračunljive, pa je GOTO naredba nepotrebna, zbog čega se i dan danas programere od malih nogu uči da je s užasom izbjegavaju, čak i kad je ona neusporedivo elegantnije rješenje (recimo preskakanje između case-eva switch naredbe, ili u nekoj gadnije ugniježđenoj petlji).

Spomenuli smo već turing tarpit - ali nitko ne programira u turingovom stroju ili čistom lambda računu, i jedan i drugi su jednako zamorni. Rekurzija i iteracija su potpuno istovjetni računski modeli, samo operiraju na drugačiji način - ono što se u iteraciji ostvari promjenom stanja u rekurziji se ostvari uvođenjem novog stanja, pri čemu se uz odgovarajuću podršku (npr. tail-rekurzija koju Scheme standard propisuje za sve implementacije) dobije računski proces istovjetne prostorne/vremenske složenosti. Pa opet - jezik koji eksplicitno ne podržava rekurziju nije nimalo računski "moćniji", baš kao i onaj koji ne podržava npr. first-class funkcije i lambdu, ali za mene _kao čovjeka-programera_ jest znatno manje moćan alat zaključivanja i razmišljanja.

Minimalnost bi se IMHO jedino trebala zahtijevati na razini sintaksnih ograničenja, pri čemu bi iz minimalnog skupa dobro poznatih i shvaćenih konstrukata iznikli svi ostali uobičajeni HLL konpceti. Pogledaj npr. kako je u Schemeu napravljen LOOP makro, s obzirom da bazni jezik ne dolazi sa iterativnim konstruktima uopće (npr. ovdje). REPEAT UNTIL, WHILE etc. dobiješ na isti način.



Koliko sam ja čuo, turing-ekvivalentnost C++ templatea je otkrivena sasvim slučajno ;) Izvorno oni NISU stvoreni za sve gluposti za koje se danas koriste, no kad imaš dovoljno veliku programersku populaciju i popularnost kakvu C++ ima, svi kutovi jezika se kad-tad istraže na najgori mogući način. Strogo gledano, to "interpretiranje" odrađuje dio kompajlera (type checker), aplicirajući neke matematičke transformacije nad izrazima jezika (recimo denotacijskom semantikom - izračunavanjem nekih funkcija (denotacija) koje predstavljaju "značenje" izraza). Ako su izračuni u tom formalnom modelu koji semantički analizator koristi neodlučivi - onda je valjda i sam čin kompajliranja neodlučiv :)



Metaprogramiranje je inače prejebena stvar - problem je samo što ga C++ pruža na najodvratniji mogući način :)



Zar se generativne gramatike koriste ozbiljnije za bilo šta osim za specificiranje sintakse jezika?

Nema to veze sa egoizmom. Pametan čovjek uvijek ima pravo na promjenu mišljenja :)



Kad bi se templatei koristili isključivo za parametarski polimorfizam - skoro pa ništa. Izbroji koliko linija koda u onom primjeru C++ monada se koristi isključivo za implementiranje generičnosti pa javi.



Ne, to je zbog defekta u dizajnu samog jezika. Proguglaj za "Stepanov" i "concepts".



Smiješna zamjena teza. Bio bi neki drugi jednako gadan jezik zauzeo njegovo mjesto :)



Postoje real-time GC-ovi, već 20+ godina IIRC :)

Koliko znam, prvi je LISP imao GC. Ima ga i PROLOG, ali deterministički. Java/C# đubretari su drugo.

@FuzzyCreation

Koliko ja shvatam, cynique hoće da kaže da je moguće definisati skup C++ šablona, među kojima je šablon

template<int n> int faktorijel()

koji se pozivaju jedni na druge, tako da ako je sabloni.h zaglavlje sa tim šablonima, onda program

ispisuje na ekranu broj 120, i slično ako se umesto 5 stavi bilo koji drugi prirodan broj, pri čemu se izračunavanje vrši u fazi prevođenja, a ne izvršavanja. I slično za svaku Tjuring izračunljivu funkciju, pa da je samim tim zaustavljivost prevodioca za dati C++ program na ulazu algoritamski neodlučiva.

Ali po meni to nije problem sintaxe nego se problem javlja zato jer se pokusava stvoriti od templatea nesto za sto one nisu napravljene.

Kad smo kod toga, jeli komitet za standard C++-a razmisljao o templateima i ovim stvarima?



Ali nista se nebi promijenilo, on bi rekao da taj jezik stvara probleme, ja bi samo ponovio isto s zamjenom subjekta.


Za takvo sto nije uopce potrebna nova konstrukcija, moze sve ostati na kompajleru.
Kompajler simulira funkciju i vidi dali ona koristi ikakve runtime-promjenjive varijable, ako ne onda se izvrsava s konstantnim varijablama i moze se izvesti optimizacija. Okvirno... :)

Radi li to koji kompajler??

Ah, svi proizvođači igara su mazohisti pa rade u C/C++.

U gamedev sa novom generacijom konzola je u toku prelazak sa sekvencijalnog izvršavanja na konkurentno. Bilo je konkurentnog izvršavanja i ranije posebno sa PS2, ali ovde mislim na jednakosti procesora po mogućnostima. Već godinu dana radim na igri koja ima minimalno 6 niti i samo jednom sam naleteo na problem trenutnog C++ standarda, a to je statička promenljiva u okviru funkcije. I verujem da će ovo biti korigovano u C++0x standardu (npr. da kompajler tretira volatile kao atomic). Ovo verovatno nije rešeno ni u D jeziku, a koliko sam video iz standarda imaju ključnu reč 'synchornize' koja je u praksi function scope mutex. Ovo znači da su dodali ključnu reč za funkcionalnost koja je nepoželjna u konkurentnom programiranju i koristi se veoma retko i samo u slučajevima kada neko drugo rešenje ne postoji. Ja koristim ovo oko tri puta kroz ceo kod igre, i planiram da do izlaska igre ostane samo jedan. Znači imaju "case specific" ključnu reč u jeziku, za čiju implementaciju je potrebno oko 10-tak linija koda u C++ (ctor klase preuzme mutex, dtor ga oslobodi).

Kada smo kod C/C++, u prošlosti je trend u gamedev bio od C prema C++, jer je kod postajao sve glomazniji. Trenutni trend je od C++ ka C kako je za konkurentno izvršavanje potreban jednostavniji manji kod koji je moguće izvršavati u potpunosti odvojeno od ostatka aplikacije. Što više jezgri procesor ima, imati kod razbijen na što manje delove je sve važnije.

Sama činjenica da C/C++ verovatno postoji za skoro svaki procesor ikada (ok 'ajd da se ograničim, pa kažem od devedesetih) napravljen ga čini veoma važnim jezikom. Problem D je da ne rešava nijedan moderan problem (npr. konkurentno izvršavanje), nema podršku velikih firmi (npr. MS neće izbaciti Visual D), oni što koriste GCC verovatno koriste C/C++ već godinama i znaju da reše sve probleme u C/C++, itd. D rešava probleme C++ iz prošlosti koje je svaki iskusan C++ programer već rešio, zna da reši ili zaobiđe. I na kraju nekome kome bi D bio od koristi (a.k.a. VB programerima kojima se C++ ne dopada), će verovatno nedostatak IDE-a i komandna linija teže pasti od učenja C++. ;)

Ako prevodilac tako radi (izvrši funkciju sa konstantnimparametrima, pa u kod ubaci gotov rezultat), onda je zbog algoritamske nerešivosti problema zaustavljanja zaustavljivost prevodioca za dati C++ program na ulazu algoritamski nerešiv problem, jer se ne zna da li će se izvršavanje takvih funkcija za vreme prevođenja okončati. No, nisam mislio na to (a mislim da nije ni cynique).

Neka to bude prije kompajla i neka se postavi timeout - tim se dobije optimizirajuci facility koji se lako ugasi/upali po potrebi.
Meni je to sad zabavna teorija koja nije daleko od prakse, ali svrha je minimalna.

@cynique
Ako kažeš da boost gurui znaju zašto su onako napisali Monad, kaži mi da li misliš da je Microsoft pogrešio stvorivši C++/CLI?
I sam je stvoren za one kojima je još uvek neophodan unmanaged kod i koji bi i dalje (manje-više) želeli da imaju moć C++-a. Ako su templejti isuviše ružni, zašto uopšte postoje sada genericsi?

-- Moje mišljenje: C++ možda jeste preobiman, samim tim i pruža mnogo, ALI daleko od toga da je uklonjena mogućnost da ti u njemu pišeš jednostavan kod.

Izbor semantike programskog jezika je uglavnom jednostavan i univerzalan i svodi se
na izracunljive funkcije. U svim programskim jezicima pises izracunljive
funkcije bilo da je to neki struktuirani, objektno-orjentisani, funkcionalni
ili logicki programski jezik. Minimalnost znaci onda dati za svaku
klasu izracunljivih funkcija samo jednu formu zapisivanja. Ako u programskom
jeziku postoje duplikacije te forme, na primer IF i SWITCH ili IF i COND onda
jezik nije minimalan jer je omogucio dve forme za pisanje jednog semantickog
sadrzaja.
Uostalom ja sam i rekao da je minimalnost za svaki semanticki smisao jednu
sintaksnu konstrukciju. Kakvu ces ti semanticke smislove izabrati i podrzati
nema veze sa minimalnoscu. Minimalnost se odnosi na sintaksne konstrukcije.

Ubacivanje komentara i preoznacavanje promenljivih nema veze sa minimalnoscu.
Mozes u programu imati i 50 IFova ako zelis, ono sto je bitno jeste da postoji
jedna forma u kome se semanticki smisao IFa moze zapisati i da postoji jedan
nacin zapisivanja komentara. To je minimalnost.

SVI PROGRAMSKI JEZICI JESU DETERMINISTICKI I NE MOGU IZGUBITI DETERMINIZAM.
Ne postoji PROBABILISTICKI programski jezici jer je to u koliziji sa pojmom ALGORITAM,
programi u tom programskom jeziku ne bi onda bili implementacija ALGORITAMA.
I random() funkcija jeste deterministicka i brojevi koje ona proizvodi su
deterministicki sa statistickim osobinama slucajnih brojeva.

Ne postoji NEPREDVIDIVOST trenutka ukljucivanja garbage kolektora. I taj program
koji njega ukljucuje radi po nekom algoritmu i moze koristiti i random() funkcije
ali i one opet rade po nekom algoritmu. Svaki algoritam (a ovde se vec podrazumeva
da je to algoritam koji se zavrsava) je PREDVIDIV jer je
DETERMINISTICKI. Uostalom to sto ti radi garbage collector ne znaci da ces ti
u svom algoritmu za input a dobiti drugaciji output kada se ukljuci garbage collector.
Cak mozes i da izracunas i trenutak kada se on ukljucuje ako znas po kojem algoritmu
radi. Determinizam tu nije narusen, jer je determinizam nemoguce narusiti jer kao sto
sam vec rekao kod algoritama je on aprioran i podrazumeva se u samom pojmu algoritma.


Generativne gramatike se mogu koristiti i kao mehanizam za racunanje. Proces
izvodjenja neke reci jeste simbolicko racunski proces, a gramatika zapis funkcije koja
se racuna.
U krajnjoj liniji program jeste model. Kada napises proceduru u Moduli-2 koja generise proste brojeve
ona jeste model prostih brojeva, kada napises generativnu gramatiku koja opisuje skup
reci koji imaju duzinu koja je prost broj opet dobijes model prostih brojeva.

Izvini, da li ćeš ti za svaki iole veći program da računaš gde će se i kada desiti sakupljanje otpada?
Takođe, najverovatnije ćeš za isti input dobiti isti output, ali nikako ne možeš da znaš kako će program svaki sledeći put kada ga pokreneš za isti input da upravlja memorijom. Što će reći, neki algoritam GC-a zavisi od "spoljašnjih" uticaja (odnosno onoga što se dešava na sistemu van programa). E sada, mislim da možeš napisati takav program koji će imati promenljivo ponašanje u zavisnosti od toga kako se manifestuje rad GC-a, što opet povlači da rad programa sa GC-om može biti varijabilan. E sada, ako ti obradiš sve moguće situacije startovanja GC-a, moći ćeš teorijski da se izboriš sa svim eventualnim problemima. A onda se postavlja pitanje, da li je prednost nekog jezika to što je on u poziciji da UVEK mesto tebe odlučuje šta će se dešavati.

Izgleda da si u životu imao velikih problema sa C++-om, čim neki tvoji komentari počinju da liče na religijska ubeđenja... :)

_{[Ovu poruku je menjao Goran Arandjelovic dana 24.01.2007. u 15:41 GMT+1]}

Pa, svi programski jezici opisuju istu klasu izračunljivih funkcije.

I radi se o istoj klasi izračunljivih funkcija.

Da li si čuo za Rajsovu teoremu i njene posledice? Jedna je da za svaku izračunljivu funkciju postoji beskonačno mnogo Tjuringovih mašina koje je izračunavaju. Recimo, postoji puno algoritama za sortiranje konačnih nizova celih brojeva. Funkcija je ista.

Ako ti se semantičke forme svode samo na osnovne konstrukcije, onda IF nije zamena za SWITCH. Ako pod semantičkim formama podrazumevaš i složene konstrukcije, minimalizam je neostvariv.

Opet se vraćamo na pitanje da li se pod konstrukcijama podrazumevaju isključivo proste, ili i složene.

Ovo je vrlo rasprostranjena zabluda. A šta ćemo sa kvantnim algoritmima, koji dobijaju sve više na važnosti i koji jesu probabilistički. Za datu kvantnu mašinu i njen ulaz mogu se predvideti samo verovatnoće da se dobije ovaj ili onaj rezultat. Pojam algoritma se vezuje za određenu klasu mašina. Neke od klasa su:

- Determinističke (podrazumevaju se ako se ne kaže drugačije).
- Nedeterminističke. Možeš ih zamisliti kao mašine koje mogu da ispale proizvoljan broj niti koje rade u paralelnom (ne u razdeljenom) vremenu, pri čemi sve niti dele istu memoriju.
- Verovatnosne. Možeš ih zamisliti kao determinističke snabdevene još i generatorom slučajnih (ne pseudoslučajnih) brojeva, kao hardverskim proširenjem.
- Kvantne. One zahtevaju duži opis, ali se i o njima može dosta izguglati.

Sve od nabrojanih mašina mogu biti konačne ili beskonačne u zavisnosti od toga da li im je memorija (recimo, broj mogućih stanja mašine) ograničena ili ne. Opet, mašina može biti automat ili ne, u zavisnosti od toga da li joj je izlaz binaran, ili na izlazu možemo imati i više od dve mogućnosti.

Svaka od klasa mašina ima svoju klasu algoritama. Determinističke i nedeterminističke mašine su operisane od slučajnih brojeva, pa onda kada im nizovi slučajnih brojeva zatrebaju, aproksimiraju ih niziovima pseudoslučajnih brojeva, koji nisu ni najmanje slučajni, već sasvim predvidivi (tu se slažemo). Računar na kome ovo pišem spada u klasu konačnih determinističkih mašina. Međutim, postoje i druge klase mašina, pa samim tim i algoritama.

Slažem se ako posmatramo ceo računar kao zatvoren sistem. Ali, sa stanovišta jadne aplikacije, ona ne zna kada će naići komunalci, jer o tome odlučuje .NET, koji radi po algoritmu, ali izvan same aplikacije.

Tako je, ali samo uz odgovarajuću semantiku. Kada se dogovorimo šta nam znači koje stanje trake Tjuringove mašine, onda je program zaista jedan konačan model jedne izračunljive funkcije, čiji domen i slika mogu biti i beskonačni. U tom smislu postoji konačan, a tačan, zapis beskonačnog decimalnog zapisa broja

Vrlo kratko:
Rekao sam za svaku klasu izracunljivih funkcija a ne za svaku izracunljivu funkciju.

Naravno da postoji beskonacno algoritama za sortiranje niza. Od jednog algoritma
koji radi nesto uvek moze napraviti beskonacno algoritama koji rade to isto na
osnovu tog algoritma.

Koje su to slozene konstrukcije? verovatno kombinacije iteracije, uslova i petlji.
Sto znaci da nam je dovoljno IF, WHILE i ; (ili mehanizam rekurzije).
Da li postoji slozena konstrukcija koja nije kombinacija iteracija, uslova i petlji.
Odgovor: NE, stoga minimalizam je moguc jer je potrebno obezbediti
sintaksne konstrukcije za IF, WHILE i ;
Sta je SWITCH, nego gomila IFova. Treba li nam SWITCH, ne treba njime
ne mozemo nista vise reci nego gomilom IFova. Da li nam treba iteracija
kao mehanizam ako imamo rekurziju. Ne. Da li nam treba rekurzija ako imamo
iterativni mehanizam. Ne. TO JE MINIMALIZAM i itekako je MOGUC. Uostalom
Niklaus Wirth je zagovornik MINIMALIZMA (pogledati njegov rad o Oberon-2
na http://www.ssw.uni-linz.ac.at/Research/Papers/Moe91a.html), gde covek
lepo kaze, citiram:
"Oberon-2 covers most terms of object-oriented languages by the established
vocabulary of imperative languages in order to minimize the number of notions for similar concepts"

Pod konstrukcijama podrazumevam i proste i slozene. Slozene konstrukcije
se prave kao konstrukcija ciji su sastavni elemetni proste konstrukcije, slozene konstrukcije
su one koje se mogu redukovati na proste konstrukcije + graf njihove povezanosti.
Proste konstrukcije to ne mogu, on su atomi semantike.

Kada govorimo o algoritmu ja vidim Cerc-Tjuringovu hipotezu, po njoj su algoritmi opisi izracunljivih funkcija,
a izracunljive su one funkcije koje su rekurzivne. Ne postoji dobra definicija algoritma, postoji
samo njeno ogranicenje i socijalni konsenzus po tom pitanju. Ovde je bila rasprava o tome imamo programski jezik koji narusava
determinizam, a da programi iz tog programskog jezika rade na masini iz prve kategorije u kategorizaciji
koju si naveo, sto je po meni 100% netacno. Jos nisam video C#, Java kompajler/interpreter koji radi na nekom
kvantnom racunaru. U stvari ja jos nisam video kvantni racunar. A i skeptican sam po tom pitanju na osnovu
dosadasnjih iskustava. Matematicki modeli postoje, ali konkretne realizacije nema.

Mozda cemo mi kvantnim ili dnk racunarima prosiriti granicu
izracunljivosti, ali sve je to jos neizvesno. Cuo sam na jednom predavanju o Tjuringovim masinama u
Novom Sadu, da su neki madjari oborili Cerc-Tjuringovu hipotezu na nekom modelu racunara koji ukljucuje
brzine svetlosti, kvantne efekte i bog zna sta, ali nisam video da je to bas nesto odjeknulo u
naucnom svetu koji se bavi teorijom izracunljivosti. Sve je to jos fikcija.

@FuzzyCreation

Hajde, molim te, kaži ti lepo meni zašto je C++ smeće i s*****? :-)
I šta ti zapravo više preferiraš od C++-a?

Elem, izražajnosti nekog jezika doprinosi i njegova pragmatičnost, što bi sa minimalizmom izgubio.

Mislim da sam ti lepo kazao u prethodnim postovima (moze se naci u dva razlicita posta)
Gledano po paradigmama ja preferiram ovako: C(strukturalni), Modula-2(modularni), Java(OO), Scheme(funkcionalni), Prolog(logicki)
U poslednjih godinu dana najvise programiram u Javi, pre toga iskljucivo u Cu(ne u C++u).
Od C++ vise preferiram cak i brainfuck.

Drugo ja nisam nigde tvrdio da je minimalizam dobar (jedan od prvih postova, kao reakcija na ono programski
jezici bi trebali biti kao formalne teorije), nego suprotno. Kasnije se rasprava razvila o samom minimalizmu,
o njegovoj mogucnosti/nemogucnosti.

Druga stvar pragmaticno je i kada te neko necim ogranici. Nije pragmaticnost samo dozvoliti potpunu
slobodu, treba nesto i ograniciti, naci pravu meru, to je pragmaticnost sa stanovista programskog jezika.

To jest problem sintakse neovisno o tome što ti mislio. Činjenica je da se templatei koriste debelo za metaprogramiranje, da krema kreme (Alexandrescu, Abrahams) piše o njima knjige koje se najbolje mogu opisati kao "101 novi prljavi trik sa C++ templateima za koje garantirano niste znali da su mogući", da se koriste u biblioteci iz koje se uzimaju ideje za sljedeću verziju C++ standarda (boost), da je programiranje u njima odvratno, nečitko, debuggiranje virtualno nemoguće, a održavanje tuđeg koda da i ne spominjem (mnijem da se ni osobe sa 10+ godina industrijskog C++ iskustva ne bi usudile tek tako modificirati neke core boost dijelove, i pri tome znati da će se kod dobro _kompajlirati_ (raditi je već kvantni skok :))



Ne, C++ komitet je sastavljen od korporativnih plaćenika koji samo gledaju kako će što prije i sa što manjim implikacijama na već postojeću bazu programera/koda zakrpati probleme u trenutnoj varijanti jezika, ne od dizajnera jezika koji sustavno planiraju njegovu evoluciju anticiparajući nadolazeće paradigmatske posmake. Bolje pročitaj one Worse is better članke, pogotovo onaj o modelima prihvata softvera u industriji :)



I opet bi počinio istu falaciju. Bio bi to neki drugi odvratno mutirani C dijalekt sa navrat-nanos nakalemljenim OO ekstenzijama. Bio bi sredstvo, ne cilj.

To je isto kao da kažeš: "Da nema Alberta Einsteina, ne bi bilo STR/OTR", ili "Da nema Nikole Tesle, velikog SRBINA rođenog na području današnje HRVATSKE, ne bi bilo izmjenične struje". Bilo bi, u nekom relativnom malom vremenskom okviru (najviše 10 god) bi sve to netko drugi isto tako otkrio.

Da parafraziram Shakespearea, oprostite na vulgarizmu, "g**** bi pod bilo kojim drugim imenom jednako smrdilo" (tko razumije, shvatit će :)



Pa i odvija se sve compile-time...zato i jest neodlučivo...hello?!

Optimizaciju metafunkcije bi trebao odraditi neki metakompajler, što je u ovom slučaju semantički analizator, odnosno kojigod računski model da on koristi za reprezentaciju značenja izraza (jer se evaluacijom značenja nekog izraza u biti i izračunava arbitrarna funkcija). Postoje raznorazni teoretski modeli (aksiomatska, operacijska i denotacijska semantika, svaki sa svojim prednostima i nedostacima), svima je zajedničko da značenje nekog izraza predstavljaju na temelju nekog apstraktnog matematičkog formalizma (aksiomi, interpreter, funkcije+domene). Semantički analizator ne vrši nikakvu "optimizaciju" - on samo čuva značenje. Većina dobro dizajniranih jezika svjesno postavlja ograničenja nad sustavom tipova (type system) i izračunima kakve on može obaviti, baš kako bi se izbjegla potencijalna neodlučivost. Iako neki to predstavljaju kao "feature" (recimo ovaj LISP dijalekt) - to je općenito nepoželjna karakteristika.

Da li je pogriješio - to može samo vrijeme reći. Ja nisam Pitija iz Delfa.



Genericsi su svojstvo CLR-a, stvoreno za sve .NET jezika. U C++/CLI možeš koristiti i klasične templatea i genericse IIRC.

Otprilike tako - svaki pomak miša od strane korisnika, svaki primljeni mrežni paket sa NIC-a, općenito svaki oblik interakcije (koja nije algoritamska!) nadilazi deterministička svojstva modernog računala promatranog kao konačnog automata. Par zanimljivih linkova na uobičajene misinterpretacije Chuch-Turingove hipoteze:

http://lambda-the-ultimate.org/node/203

http://lambda-the-ultimate.org/node/1038




Čini mi se da su na Caltechu (gdje predaje valjda više Nobelovaca nego na svim EU sveučilištima skupa ;) već napravili eksperimente u kojima su ostvarili osnovna logička vrata (ionske zamke, polivalentna kvantna logika i ostala čudesa) i neke elementarne operacije na njima.

Kvantni algoritmi su nešto fascinantno, i ne bih to tek tako prekrižio. Kvantna teorija informacije je eksplodirala tek kad je Peter Shor pokazao da kvantno računalo može odraditi faktorizaciju u polinomnom vremenu - sveti gral obavještajnih agencija ;)

Vjerojatno je svima poznata ona priča kako je NSA poznavala diferencijalnu kriptoanalizu 20 godina prije ostatka svijeta? Možda već sad u nekom labu kuca neki kvantni CPU ;)

Nisam upoznat s turingovom masinom pa te ne mogu pratiti ovdje.



Fascinantni su samo zato jer su nesto sto jos nije duboko istrazeno. Nekada je i vatra bila fascinantna... :)

Nadam se da postoji buducnost u tome jer bi s tim mogla krenuti nova industrijska revolucija. Ali ne treba brzati s ocekvanjima, ako se pokaze efikasno, kad bude bit ce.




Jedno vrijeme sam bio jako nastrojen 'pro' C++/CLI. Sad su se osjecaji promjenili.
Mislim da C# moze sve sto moze i C++/CLI i to jos lijepse i jednostavnije.
C++/CLI osim par zamjerki je solidan jezik, ali niakd nece postat korisniji od C# jer nema tako dobre alate koje ima C#. A u danasnjem vremenu alati su takodjer bitna stvar koja utjece na popularnost jezika.

MS nikako nije pogrijesio stvorivsi C++/CLI i time omogucio je da se iskoristi C++ kod uz "minimum" promjena za .NET. Ali nista vise od toga, ne vidim nijednu drugu beneficiju koju pruza C++/CLI naspram C#.
C++/CLI ce ostati tek dodatni jezik koji ce u C# projektima koristiti se samo kad je bas neophodan.

Baš obrnuto...moj je (laički) dojam da je kvantna teorija informacije barem 10 godina ispred prakse. Imaš već (pored kvantnih algoritama sa superpolinomnim ubrzanjima) i kvantne programske jezike nad kvantnim lambda računom i sl. Naravno, sve na simulatorima :) Do prije 50-ak godina su i misaoni eksperimenti (gedankenexperiment) od strane Einsteina et al. bili čista teorija, danas su itekako praksa...

@FuzzyCreation

Da ne bi ispalo da vadim iz konteksta ono što si napisao, reći ću vrlo kratko, da Gedelove teoreme nekompletnosti nemaju ama baš nikakave veze sa kontekstom u kome si ih pominjao.

Drugo, naravno da je računar na kome ovo kucam konačna deterministička mašina, tako da je sve što se odigrava na njoj načelno predvidivo. Međutim, ne radi se o tome, već o nečemu drugom. Ti govoriš o determinizmu računara kao celine, a ja o determinizmu programskog jezika. Pošto kažeš da si familijaran sa C-om, uzeću njega kao primer. ANSI C standard ne predviđa kada će prilikom ispisa na ekran/upisa u datoteku doći do pražnjenja bafera, što uvodi nepredvidivost ponašanja C programa, kao i mogućnost korišćenja neinicijalizovanih pokazivača.

Da, proces koji se izvršava u mom računaru jeste predvidiv, ali kompletna specifikacija mog računara (koja je potrebna da bi se predvideo rezultat izvršavanja programa) nije deo specifikacije programskog jezika. Kada govoriš o osobinama programskog jezika, ne možeš se pozivati na specifikacije računara na kome se program izvršava, koje nisu deo specifikacije programskog jezika.

Da rezimiram. C programer, u praksi, mora da vodi računa o tome da do pražnjenja bafera može dolaziti bilo kada, ali svakako prilikom ispisa znaka za kraj reda, zatvaranja datoteke i izričitog zahteva da se bafer isprazni. Upravo tako, on mora reći: "Ja van toga ne mogu da znam kada će doći do pražnjenja bafera.", ili program neće ispravno raditi. Isto važi i za lutajuće pokazivače i još štošta. Znači, u praksi, programer mora voditi računa o tome da C nije deterministički jezik. Druga je stvar što je računar na kome se proces izvršava, kao celina, determinisan.

Hajde, reci šta podrazumevaš pod klasom izračunljivih funkcija.

Recimo, ona dva BASIC programa koja sam priložio imaju različite sintaksne reprezentacije, ali je tok izvršavanja isti.

Ima. IBM je u laboratorijama proizveo kvantni računar, doduše sa jednocifrenim brojem qubita. Ideja je ostvariva. Ostaje samo pitanje vremena i ulaganja u razvoj, pa da se dobije nešto što će biti komercijalno upotrebljivo.

Preteruješ, kao i obično. U praksi se TMP (template metaprogramming) skoro uopšte ne koristi, osim preko gotovih biblioteka kao što je Blitz++, a kladim se da 90% profesionalnih C++ programera nikad nije ni čulo za koncept.



Kamo sreće da je tako - C++ komitet je skup genijalnih volontera koji su u stanju da godinama raspravljaju gde da stave zarez u sledećoj verziji standarda umesto da rešavaju konkretne probleme, kao što je nedostatak modula i podrška za Unicode.



To je jednostavno zbog toga što postoji realna potreba za "odvratno mutiranim C dijalektom sa navrat-nanos nakalemljenim OO ekstenzijama". C je lingua franca sistemskog programiranja, a nema skoro nikakvih mehanizama apstrakcije. C++ je jednostavno rezultat stvarne potrebe, a ne akademskih mudrovanja o "čistim" jezicima.

Uostalom, ima jedna jako lepa knjiga u kojoj je detaljno objašnjeno zašto je C++ takav kakav je: http://www.research.att.com/~bs/dne.html

Slazem se, ja nikada nisam imao potrebe da radim metaprogramiranje iako stalno koristim sablone. Sablone je veoma lako koristiti iako ih je tesko programirati tako da meni to uopste ne predstavlja manu C++ a verujem da je isti slucaj i sa 99,99% drugih C++ programera koji uglavnom koriste sablone i biblioteke koje to implementiraju ali ih ne programiraju oni sami.

Rekao sam da se templatei debelo koriste za metaprogramiranje, ne i da se metaprogramiranje debelo koristi. Mala, ali važna razlika :)

Diskusija je inače i krenula u ovom smjeru nakon što je Nrmyth spomenuo kako je TMP uporaba templatea za nešto što "nisu namijenjeni". I nisu izvorno, ali se itekako koriste (barem od strane ljudi koji žele izgubiti dovoljno živaca) za TMP.



I kad dođe MS i napravi C++/CLI koji zaista rješava neke konkretne probleme, svi ga kolektivno ismijavaju i bojkotiraju kao da se radi o nekom trećerazrednom nebitnom isprtku :)



To i govorim cijelo vrijeme. C++ je izuzetno ružan i gadno koncipiran alat koji jako učinkovito rješava neke od stvarnih problema. Ništa više od toga. Ne baš tako daleko u budućnosti, moderna će potrošačka računala itekako arhitekturalno odudarati od apstraktnog C stroja, i favorizirat će se korištenje drugih alata koji će puno učinkovitije rješavati tad znatno važnije probleme poput konkurentnosti, dostupnosti i sigurnosti koda.



Koja smijurija...dakle "svi koriste boost, a nitko nema muda modificirati njegov kod". LOL.

C++ polako postaje write-only jezik kao Perl.

Sva sreća da postoje alternative.

Recimo radim na nekom embedded OS-u koji nije pravljen u MS... Koje probleme mi C++/CLI rešava?

Ti ljudi izgube živce, a ja koristim njihove gotove biblioteke bez gubljenja živaca - život je lep.



C++/CLI je dobar jezik i rešava konkretne probleme, ali nije C++ niti rešava probleme C++-a. Inače, osnovni problem sa C++/CLI je što ga i sam MS slabo promoviše, i marketinški, i još gore kroz jako slabu podrušku u VS-u.



Zašto "LOL"? To je dobro - ne želim da koristim biblioteke koje svaki priučeni "programer" menja kako mu se ćefne.




Na žalost, ne postoje.

Nema to veze sa mudima nego sa time da li zelim da ispravljam tudji kod. Da ja to zelim ja bih koristio Linux. Posto ne zelim da ispravljam gotove stvari nego da ih samo koristim onda cu da ostanem na Windowsu i koristicu gotove biblioteke. Ne slazes li se da je to uobicajeno razmisljanje u realnom svetu dok je u studentskom svetu gikova uobicajeno da oni mogu sami da tumace tudji kod i da ispravljaju tudje bagove jer imaju previse slobodnog vremena ili su dokoni. Jos je smesnije sto dosta linuksovaca prica kako im je bitno to sto mogu sami da isprave bagove iako njih 0.0001% to zaista i radi. Ne verujem da me mozes ubediti da je dobro da ja mogu da tumacim i ispravljam tudje template biblioteke jer cak i da je sintaksa mnogo lepsa opet to ne bih radio jer nisam neki gnu/linux zealot.


Za mene ne jer koristim samo onaj nivo apstrakcije koji mi odgovara i koristim gotove biblioteke tako da i drugi mogu da tumace moj kod bez mnogo muke.


Koja alternativa mi nudi toliko nivoa apstrakcije kao C++ pa da mogu da koristim OOP a takodje mogu i da se spustim na nivo sistemskog programiranja i direktnog pristupa memoriji (jako bitno u mnogim slucajevima)?

_{[Ovu poruku je menjao srki dana 26.01.2007. u 09:30 GMT+1]}

Bojim se da su tvoji problemi manje odraz fundamentalno loše dizajniranog jezika kakav je C++, a više nekih tehničkih aspekata dostupnih razvojnih okruženja.

S obzirom da za standardizirani jezik, kakav već C++/CLI jest, ne postoje non-MS prevoditelji, ne mogu ne primjetiti u gorenavedenom pitanju suptilnu autoironiju autora: "jebiga, ponekad nemaš izbora!". Ili je možda ni nema? :)

Također, moja iskrena sućut zbog bakćanja konkurentnosti dijeljenim stanjem u jeziku u kojem je izraz "a = a + 1" nedeterministički.

Glede C++/CLI, toplo preporučam:

http://www.gotw.ca/publications/C++CLIRationale.pdf



Koristiš u produkciji te biblioteke? Što kad linija koda u stilu:



uzrokuje neki suptilni race condition na nekoj upravo izašloj big-endian arhitekturi sa 16 jezgri, na nekom komercijalnom slabo-poznatom prevoditeelju - što možeš učinit sa nekom open source bibliotekom iza koje nijedna velika kompanija (što je i očekivano, s obzirom koliko kaubojskog koda sadrži) nema svoj potpis, dakle nikakav QA i garancija stabilnosti sučelja? Prijavljivati bug na mailing liste i polagati nade u elitne Kauboje, genijalne volontere, da se udostoje ispraviti bug ASAP?

C'mon, valjda netko sa toliko iskustva poput TEBE zna da tako Stvarni Svijet ne funkcionira :)



Slabo opravdanje za ovakav "elitizam" koji je više iznuđen odvratnom C++ TMP sintaksom nego "kvalitetom programera" - bilo koji "priučeni programer" nema teoretske šanse da razumije kod iza biblioteki poput Blitz++, Phoneixa i boost, i ti to dobro znaš.

Osim toga, open source model je odavno pokazao da, što više ljudi kontribuira u nekom projektu, to se brže trijebe bugovi i on evoluira, ma koliko on gadan bio.



Na svu sreću, sve je manje domena u kojima je C++ jedini mogući izbor. Ne tako davno, managed DirectX je bio puka fantazija... U vrlo bliskoj budućnosti, svi MS-ovi kompajleri će biti izgrađeni na istom compiler pipelineu, (čitaj: emitirati izvršni kod jednake kvalitete), od Excel makroa pa do cl.exe...



I te kako ćeš to raditi, i za tebe vrijedi isti odgovor kao i za Nemanju. Who you gonna call? :)

Samo je fora sa linuxom što obični C kod možeš razumjeti, modificirati, i u krajnjoj liniji ispravljati bugove, barem 100 puta lakše nego u heavily templated C++ bibliotekama.



Imaš npr. u C# P/Invoke koji izuzetno lagano veže nativne sistemske API-je, i pruža direktan pristup memoriji preko pokazivača i sl. kroz "unsafe" blokove.

Interesantan pogled na programiranje. Nazalost, (bar moje iskustvo tako govori), veliki deo vremena u programiranju upravo ispravljas (svoj ili) tudji kod. Nakon nekoliko nedelja/meseci rada na projektu apsolutno ti je do kraja svejedno da li si ti ili neko drugi pisao doticni kod, jer moras ponovo da ga tumacis. Hm, a sto se tice gotovih stvari spremnih za koriscenje, poredjenje gnu-a i Windows-a bas i nije na mestu.



Ako zaista ne zelis da mozes takvo nesto, niko te na to ne moze naterati, naravno! Moje je vidjenje da je sposobnost tuamcenja tudjeg koda i shvatanje kako funkcionise, veoma pozitivna osobina. Stavise, od svakog ozbiljnijeg programera apsolutno bih ocekivao da je sposoban da moze da tumaci i ispravlja tudji kod. Cak i u slucaju da je to kod biblioteke zakopan ispod template-ova, visestrukog nasledjivanja, i ostalih "fency" konstrukcija :)

@cynique

Ti kao da si isfrustriran C++ -om i njegovim šablonima. Potpuno si nerealan. Ne radi se o jeziku koji je katastrofalno dizajniran, već o jeziku koji je odslužio svoje i zreo je za penziju. 90-tih je bio najbolje rešenje u većini slučajeva. Najveći broj komercijalnih programa u tom periodu je napisan upravo na njemu. Sada su se, jednostavno, pojavila naprednija rešenja, i to nije ništa neobično. Sutra će se pojaviti bolja rešenja od današnjih popularnih upravljanih rešenja, ali to ne znači da su ona bila loše dizajnirana. Nađi mi programski opšte namene jezik iz 90-tih koji je bio bolje dizajniran od C++ -a. Nađi mi mašine iz 90-tih koje su u stanju da poteraju nešto kao što je .NET Framework. Odmeri recimo, koliko megabajta zauzima .NET, a koliki su bili memorijski kapaciteti tadašnjih računara. C++ će, pošto se u svim područjima budu našla bolja rešenja (Windows se i dalje razvija na neupravljanom C++ -u, kao i Majkrosoftov .NET Framework), otići u potpuno zasluženu penziju.

@srki

Vidim da te kritikuju i osnovano i neosnovano, ali poređenje GNU/Linux-a i Wondows-a ti zaista nije na mestu. Ko tebe tera da čačkaš kod Open Source rešenja ako nećeš. Meni se, recimo, sviđaju gcc, g++, mono, Ultimate++, fpc, SWI PROLOG, Lazarus, Qt, wxWidgets, ali mi bez obzira na otvorenost njihovog koda, ne pada na pamet da (bez potrebe) prčkam po njima. Ponekad prčkam po tuđem kodu, ali samo kada se za tim zaista ukaže potreba. Do sada mi se dva puta desilo da menjam kod i koristim ga u izmenjenom obliku, i oba puta su izmene bile sasvim jednostavne i sa kompajliranjem su trajale manje od pola sata. No, prihvatam da se softver tipišno koristi onakav kakav jeste.

Bas zbog toga sam sigurniji da te biblioteke nisu pisali priuceni programeri vec koristim template biblioteke koje su prosle nekakvu reviziju ili ako neka jaka kompanija stoji iza njih, recimo Microsoftove biblioteke Active Template Library i Windows Template Library koje izuzetno olaksavaju pisanje programa.


Skoro nikada to necu raditi i nikoga necu zvati i to nema veze sa sintaksom vec sa zeljom da gledam kod biblioteka koje koristim. Cak i da je sintaksa 100 puta laksa za citanje opet to ne bih radio ali zato koristim proverene biblioteke. Ovako zvucis kao neki linuksovci koji su nas pre ubedjivali da je to bolje koristiti jer ako nesto ne radi onda mozemo sami da ispravimo. Neka hvala. Ako se nekada zaista ukaze potreba da menjam kod u biblioteci ne smeta mi da to bude malo teze jer to ne radim tako cesto nego da mi to bude lakse ali zato i koriscenje toga da mi bude teze.


Stvar navike, meni je lakse da citam template kod nego c kod.


Ne bih se slozio. Mozda tebi to jeste lagano ali vecini ljudi to nije i ja se slazem sa njima da C# P/Invoke izgleda izuzteno ruzno. Evo iskustva jos nekih ljudi:
http://blogs.msdn.com/jeremykuhne/archive/2005/06/11/428363.aspx

Uostalom da je to lagano kako ti kazes ne bi postojao web site posvecem samo tome:
http://www.pinvoke.net/



A evo i iskutva ljudi sa es-a:
http://www.elitesecurity.org/t18365-Zanimljiv-PInvoke
Relja koji radi u MS-u je na kraju odustao od koriscenja PInvoke-a.

Nemoj pogresno da me shvatis, ja verujem da ce se u bliskoj boducnosti stvari promeniti ali moras da se slozis da trenutno za neke stvari C++ jednostavno nema alternativu. Ako ima alternativu ja bih voleo da znam za nju. Ovo sto si ponudio nije dobra alternativa jer je to mnogo lakse uraditi u C++ a pored toga se i brze izvrsava.


Da, ali ne kod biblioteke nego kog koji kompanija u kojoj radim razvija.


Prihvatam kritiku, pogresno poredjenje. I tu ima lepih biblioteka koje bih koristio ali poenta je da to ne bih radio zato sto mogu da ispravljam tudji kod.


Slazem se, nisam ni rekao da je to lose.

Naravno. Meni nije problem da tumacim tudji kod i tudje template biblioteke ali jednostavno ne zelim na to da gubim vreme vec cu da predjem na drugu biblioteku. Jos pre 13 godina je Steve McConnell u knjizi Code Complete pisao koliko se poveca produktivnost ako se koriste vec gotove biblioteke drugih kompanija (a one uglavnom daju samo izvrsne verzije biblioteka). Ali ako se zaista ukaze potreba onda mi uopste nije problem protumaciti tudji kod i lakse mi je da to bude teze jer tu potrebu imam 0.01% vremena nego da mi bude teze koriscenje tih biblioteka. Tu se cynique ne slaze sa mnom.


Niko naravno, poenta je bila samo u tome da kao razlog koriscenja Open Source biblioteka nece da bude to sto mogu da menjam tudji kod. Boost biblioteke su Open Source pa ih koristim. To sam pomenuo samo zato sto je cyniq poceo da mi zvuci kao neki zealot koji nagovara ljude da koriste nesto zato sto je lako menjati i tumaciti kod tudjih biblioteka a meni to uopste nije toliko bitno.


Upravo to. Tu potrebu imam zaista retko ali onda kada se ukaze potreba mi nije problem da protumacim kod i ispravim bagove ali posto se to retko desava onda mi je bitnije da ja mogu lakse koristim te biblioteke i lakse da menjam nivoe apstrakcije nego da koristim P/Invoke u C#. Ali opet stojim iza toga da 99,99% ljudi nikada ne menja tudje biblioteke ali ako cyniq misli da je zbog tih 0.01% ljudi bitno da template sintaksa bude drugacija onda ga ja ne mogu razuveriti. Svako ima pravo na svoje misljenje.

_{[Ovu poruku je menjao srki dana 29.01.2007. u 12:59 GMT+1]}

Miješaš babe i žabe, biblioteke iza kojih neka kompanija (podrška, QA, garancija unazadne kompatibilnosti) su potpuno druga stvar. Spomenute C++ TMP biblioteke se nimalo ne razlikuju od open-source "sam svoj majstor" rješenja. I opet nisi odgovorio na pitanje, što ćeš kad se npr. negdje pri kraju razvojnog ciklusa aplikacije, u fazi temeljitog testiranja otkrije neki izuzetno suptilan bug, u nekoj opskurnoj kombinaciji prevoditelja/hardvera. Who you gonna call?



Ima itekako veze sa sintaksom jer je sintaksa odvratna i nečitka. Da i tebi pejstam neke linije koda iz npr. bost::spirit pa da te pitam da mi objasniš što one rade? Ne da minimalno modificiraš funkcionalnost, samo da objasniš što rade. Bolje ne, jeli?



"Provjereno" je vrlo mutan kvalifikator. Nekome je i OpenBSD "provjereno siguran" OS, COBOL "provjereno kvalitetan" jezik. Elitizam iza izjave "provjeren jer samo najveći C++ jebači dovoljno znaju da mogu kontribuirati boost-u" mi je se gadi.



Korisnik takve biblioteke nije isto što i korisnik OS-a, on je programer za kojeg je i poželjno da može otkloniti bug ukoliko za tim bude potrebe. Za biblioteke iza koje ne stoji neka kompanija to je jako poželjno.



Lažeš.



Baš zato je i lagano - samo c/p definicije sa tog sajta i možeš koristiti bilo koji neupravljani Win32 API. Jest da ružno izgleda, ali je mnogo lakše od FFI u većini drugih upravljanih jezika (uključujući javu i python), jer dobar dio .NET API-ja i jest samo OO wrapper za win32 ekvivalente.

Nadalje, primjer na ovom blogu koji si naveo nije C++ već C++/CLI - jezik koji na kraju završi kao .NET bajtkod (primjeti /clr zastavicu). Nitko ti ne brani da u jednom .NET projektu koristiš više .NET jezika, na kraju sve može završiti u istoj izvršnoj datoteci (assemblyu). Nije .NET samo zvanična multijezičnost kao Java.



Blago tebi John "srki" Maddock kad ti 0.01% vremena treba da otkloniš bug u kaubojštini od koda kakav već boost dobrim dijelom jest. Ostatak smrtničkog svijeta te pozdravlja sa udivljenjem.

Nije tacno, probaj sam da sklepas nesto i da ubacis u boost pa ces videti da to nije tako. Recimo ja koristim Generic Image Library koja je deo Boost-a a kompanija Adobe stoji iza projekta: http://opensource.adobe.com/gil/
Toliko o tome da su u boost sve biblioteke neproverene bez qa analize. Izvini ali jednostavno si neupucen kako se ubacuju biblioteke u boost. Sve biblioteke koje su prihvacene u boost su peer-reviewed.


Odgovorio sam ali ti ne citas. Ako se tako nesto desi na kraju razvojnog ciklusa onda cu da potrosim neko vreme da vidim u cemu je greska i ne bi mi smetalo sto je sintaksa ruzna ako mi je zato bilo lakse da napravim tu aplikaciju umesto da mi je bilo mnogo teze da napravim tu aplikaciju a lakse da ispravim taj bag pri kraju razvojnog ciklusa. Jednostavno se vise vremena provodi na pravljenju aplikacije i koriscenju gotovih stvari nego na ispravljanju bagova u bibliotekama koje koristim. Posto meni ne verujes onda neka se drugi izjasne, npr. Dragi Tata, bkaradzic...Ako ni njima svima ne verujes onda ne vredi raspravljati jer te nije moguce ubediti.



Ja to ne zelim da radim ali ako te to moze naterati da priznas da nisi u pravu onda vazi. Deal?


Ako ti tako kazes. Verovatno me bolje poznajes od mene samog.


Nisam uopste zbog toga stavio taj link nego zbog primera koriscenja P/Invoke u C# posto si to pominjao.



Ako si ti isfrustriran C++ sablonima ne mora da znaci da su i ostali. Nista, bezi od C++-a kao djavo od krsta (nije to za tebe) i drzi se samo C# i koristi P/Invoke i bice sve u redu.

_{[Ovu poruku je menjao srki dana 29.01.2007. u 14:32 GMT+1]}

Ja nisam ni tvrdio da su boost biblioteke "neprovjerene bez analize", ne znam odakle mi uopće imputiraš tu izjavu. Bolje čitaj malo pomnije što pišem, jer sam samo sprdao kontekstno jako ovisan pridjev "provjeren". To što neke 3rd party kompanije djelomično kontribuiraju boost projektu ne odgovara na moje pitanje: Who you gonna call? Tko garantira podršku za bugove i QA?

Mailing liste i bugtrackeri na volonterskoj bazi?

Tako pingvinski.



Jako trivijaliziraš proces otkrivanja i ispravljanja buga. C se i dan danas koristi naveliko za low-level programiranje ne primarno zbog kvalitete prevoditelja, već zbog transparentne apstrakcije računalnih resursa koje omogućava. C++ template metaprogramiranje debelo odudara od takvog pristupa, namećući svoj turing-ekvivalentan računski model.

Već sam rekao - ako si John "srki" Maddock može dopustiti ad-hoc kastomiziranje boost biblioteke nauštrb "ljepše" (de gustibus non est disputandum) sintakse - neka mu. Ostatak smrtničkog svijeta ne može. Ostatak smrtničkog svijeta ne zna gdje je glava a gdje rep kad gleda izvorni kod od biblioteki poput boost i Blitz++.

Smrtnički će svijet jednostavno koristiti C biblioteku istovjetne funkcionalnosti, znajući da si štedi beskrajno mnogo živaca.



Jedino što bi me moglo natjerati da priznam da sam u krivu je da su već na drugoj-trećoj stranici ove teme se javili ljudi koji su rekli kako C++ TMP i nije neki bauk, i ispričali par lovačkih priča o fascinantnim mogućnostima koje metaprogramiranje pruža. Nažalost, takvih ovdje nema (pošto svi takvi kad-tad otkriju Common Lisp i nikad više ne gledaju unazad).

No kad se već nudiš, objasni mi ti za početak što ona linija koda iz monada radi? :)



Nemoj se ljutiti, ali izjavom da je ti je "čitljiviji templated kod nego C kod" si izgubio svaki kredibilitet u mojim očima. Mogu navesti iz literature nekih par kanonskih primjera funkcija implementiranih i u običnom C-u, i kroz templated metafunkcije, pa da svi vide koliko su "čitljiviji".



LOL, a pri čemu si slavodobitno zaključio:



ni ne shvačajući da to nije C++ već C++/CLI, i to emitiran u MSIL/CIL bajtkod.

Rekao si da tražiš jezik, citiram:



Naveo sam C# i unsafe konstrukte koji omogućuju korištenje pointera, pri čemu obično završe u bajtkodu u tzv. "native unmanaged" blokovima koji nisu upravljani već sadrže nativni kod (bez gubitka performansi - moguće je čak i ručno u MSIL/CIL bajtkodu heksadecimalno pisati opkode :), te sam naveo i P/Invoke kao dobar interop mehanizam sa već postojećom bazom neupravljanih API-ja.

Jedina točka gdje si pokušao to osporiti jest tobožnja "loša kvaliteta interoperabilnosti", i teškoća pisanja P/Invoke definicija. Sad kad imamo C++/CLI koji "samo radi" (it just works), slažeš li se da bi .NET mogla biti platforma koja zadovoljava uvjete postavljenog pitanja?



Argumentum ad hominem.

Na primjer:

http://en.wikipedia.org/wiki/Common_Lisp

http://en.wikipedia.org/wiki/Dylan_programming_language

http://en.wikipedia.org/wiki/Ocaml

Hehehe, e ova ti je dobra. Evo malo mojih iskustava sa P/Invoke: http://www.codeproject.com/scr...974229&id=14112#xx974229xx

Ako radiš sistemski softver ili aplikaciju koja zahteva puno ristupa sistemskim funkcijama, C++ ti je danas jednostavno najbolje rešenje. Pozivanje C funkcija i asm blokova je sastavni deo jezika, a takođe i mehanizmi apstrakcije koji omogućavaju da pišeš kod "visokog nivoa".

Da se razumemo, ja ne tvrdim da je većina softvera koji se piše sistemski - verovatno se najviše razvijaju biznis web aplikacije i za njih C++ najčešće nije dobar izbor.

To mozes i sam da nadjes na sajtu. A ako se toliko plasis ne moras da koristis te biblioteke, ne vidim u cemu je problem. Koristi samo STL, WTL i ATL jer ti tu MS garantuje podrsku za bagove i QA (mada ni on to ne garantuje ali mozes da se uzdas u njih ako zelis). A ne moras ni to da koristis ako neces nego nadji neke OS biblioteke koje ne koriste Templates i nema da te boli glava. Zato ne razumem zasto ti to predstavlja manu ako te niko ne tera da koristis?


On nista ne namece jer te niko ne bije po usima da to koristis. Sa druge strane on ne odudara od tog pristupa o kom pricas jer omogucava bolje iskoriscenje racunarskih resursa prenoseci neke stvari u compile time.


Sve se plasim da bi vecina njih pre koristila C biblioteku nego neku boost samo zbog toga da bi mogli da isprave bagove ako se pojave. Iskustvo mi govori da je bas obrnuto i niko ni ne razmislja o ispravljanju bagova u tudjim bibliotekama sve dok ih nesto na to natera. Biblioteka se uglavnom bira po lakoci koriscenja a ne po lakoci ispravljanja bagova. Mada mozda ti imas drugacije iskustvo, ne znam u kojim kompanijama si radio.




A sto bih ti ja to tumacio ako ni onda ne bi priznao da nisi u pravu? Da bi me i dalje nazivao lazovom i koristio argumentum ad hominem?


To mi je izuzetno tesko palo :-)


Ti mozes i jedno i drugo da napravis necitko da Bog otac ne moze da protumaci. http://www.ioccc.org/


Ne znam sto toliko fantaziras, ja nisam nigde rekao da je to C++ a ne C++/CLI kod.


Mozda je tebi dobar ali velikom broju ljudi nije.


Slazem se.


Nije argumentum ad hominem vec iskren savet a ti si taj koji koristi argumentum ad hominem nazivajuci druge lazovima i koristeci cinizam samo u tebi poznatom stilu casteci druge nadimcima aka John Maddock i sl.

Ubeđen sam da su bolje dizajnirani na osnovu toga koliko su zaživeli. Šta ćeš kad je cela industrija softvera bolovala od C++ mazohizma.

Tržište je softvera previše inhibirano raznoraznim legacy i marketinškim čimbenicima kako bi se na njega mogao primjeniti jednostavni darvinistički "najbolji preživljava" princip. Generacijska je smjena u industriji znatno dulja od istraživačkog tempa. Već sam rekao da vrijedi: worse is better:

http://www.elitesecurity.org/p1441372

CL je, na primjer, rezultat 40 godina evolucije, ne slučajno uspjeli eksperiment iz koporativnog laba poput cpp-a, i neosporivo je "bolje dizajniran" u bilo kojem pogledu. Pošto vidim da ni ti nisi pročitao barem executive summary ovih članaka, evo ti jedan mali sneak peak da te motivira: :)


I to sve bez dodavanja novih fundamentalnih featurea jeziku (samo compile i voila!).

Zašto dandanas programiramo u Javi/C++, jezicima koji predstavljaju tehnologiju staru 25+ godina? Jednostavno - worse is better :)

Ne pričamo o meni i koristim li ih ja, pričamo o samoj biblioteci i onima koji je koriste. Gornjom "argumentacijom" možeš manje-više svaku kritiku začepiti sa "nitko te ne tjera da to koristiš".



Odudara u samom modelu programiranja itekako. Invokacija funkcije novom razinom instancijacije ima veze sa stogovnim okvirima i stablom izvođenja otprilike koliko i tvoja lupetanja sa zdravim razumom.



Tvoje mišljenje. Ja kažem: jebeš biblioteku kojoj činjenica da je open source baš nimalo ne pomaže da ne bude "crna kutija".

Također, tvoja subjektivna procjena o beneficijama "lakoće" korištenja perfidnih templatoidnih konstrukta nauštrb nekih izmišljenih 0.01% vremena kastomiziranja i otklanjanja bugova je i više nego pretjerana, i nemaš baš nakakvih činjeničnih argumenata iza nje. Ja imam - evo nitko se na ovoj temi dosad nije javio da kaže da mu je heavily templated boost/Blitz++/Phoneix kod mačji kašalj za modificirati i eventualno popraviti. Nitko osim John 'srki' Maddocka.



Da znaš to objasniti već ti to uradio u prva 3 puta kad sam citirato tu liniju koda. Ti i bilo tko drugi tko čita ovu temu. Ali pošto ne znate..



Ne i u mojim očima, već i u očima svih koji znaju kakvu si glupost lupnuo. John "srki" Maddock kad vidi ovo:



ustvari vidi:



All hail, John 'srki' Maddock!



Kad vidiš da je IOCCC kod čitljiviji od najpopularnije C++ biblioteke koji pišu najveći C++ stručnjaci, zapitaš se koji je točno problem sa samim jezikom.



Dao si link koji pljuje po C# P/Invoke i zaključuje da je C++/CLI pristup daleko bolji, pri čemu si u komentaru naveo, citiram:



Uzimajući u obzir također činjenicu da je dotični link također prvi google hit:

http://www.google.hr/search?hl...btnG=Google+pretraga&meta=

Čovjek se za pita imaš li ti pojma uopće o čemu pričaš.



Tražio si jezik sa OOP mogućnostima koji dopušta direktan pristup memoriji. C# zadovoljava te kriterije. Ovo hvatanje za P/Invoke slamčicu citiranjem samo dijela moje izjave je patetično.



Da lažeš kad kažeš:



je bjelodano svakome tko je ikad intenzivnije pisao/čitao templated kod.

I to nije ad hominem argument. Da sam rekao da ne poznaješ dovoljno materiju o kojoj pričaš, ne osporavajući same argumente, bi bio ad hominem. Ovako si samo smiješni lažov.



Taj nadimak ne nosi nikakve pejorativne konotacije, za razliku od tvojih savjeta u stilu "nije to za tebe" i "bježi kao đavo od krsta".

nerd alert!

Boost nije nikakav problem, niti prepraviti niti koristiti - tamo gde to ima smisla!
Ako je tebi problem da barataš sa template-ima, onda bi trebalo da stekneš još iskustva
pre nego što se baciš u lupetanje i vređanje drugih koji su očigledno sposobniji od tebe
da čitaju takav program.

P.S. C# je zanimljivo i prolazno đubre.
P.P.S. Koristim generičko programiranje praktično non-stop ;)


_{[Ovu poruku je menjao tosa dana 30.01.2007. u 18:40 GMT+1]}

Zato je C++ zauvek, je l' da? Samo mu se nešto područje upotrebe smanjuje poslednjih godina i to rapidno.

Možda si i u pravu, stvarno čovek mora da im skine kapu - izgleda da je za igrice C++ stvarno dušu dao. Predviđam mu zaista dugu i lepu budućnost na XBox 360 i sličnim. Što jes' - jes' :)

Mada, eno ih iz MS-a, već su objavili i XNA Game Studio za pravljenje igrica u C#/Managed DirectX, za PC i XBox. A demo koji su prikazali, neka trkačka simulacija, ide sve u 16, i to kažu koristi samo jedno jezgro od 6 u XBoxu. Ko zna šta će biti na kraju i sa tim igricama i C++.. :)

Zaslužena penzija, što neko reče. Za C# ćemo tek da vidimo koliko će da potegne.

_{[Ovu poruku je menjao degojs dana 30.01.2007. u 19:58 GMT+1]}

@degojs

Ja sam napisao zaslužena penzija za C++. Pritom, stavljam akcenat na reči "zaslužena" i apsolutno ne smatram da nije odigrao veliku ulogu.

@cynique

Nemoj da se čudiš kada ti se posle ovoliko izrečenih uvreda oduzme pravo na članstvo na ES. Povedi računa o tome da ovo, ipak, nije advocacy forum. Pročitaj pravilnike ovog i advocacy formuma i ivećeš da postoje vrlo značajne razlike.

Lisp je svakako "bolje dizaniran" od C++a, a raditi Fibonačijeve brojeve ili faktorijel u njemu (ili još bolje u npr. Haskellu) je poezija u odnosu na C/C++/Java/C#... ali je "sitan" problem što software u ovom surovom i naopakom svetu ne može samo da računa faktorijel, već da se bavi "dosadnim" i "nesavršenim" stvarima kao što je deljena memorija, mrežni protokoli, pipes, driveri,... jesi li probao da odradiš nekad nešto od toga u Lispu?

XNA je za pravljenje casual igara. X360 ima 3 jezgra, i po dve hardverske niti na svakom jezgru.

Evo da ti odmah i odgovorim da ne čekaš u neizvesnosti... :) I dalje će se praviti u C++! :) Računaj Sony i Nintendo, jer po prodaji igara MS je na trećem mestu, za par stotina miliona USD manje od Nintendo-a, i za skoro 50% u odnosu na Sony-a. Čak i da plate sve proizvođače da koriste C# igre će se i dalje pisati u C++ na drugim platformama. I tzv. in-house alati, tipa editori, konverteri, itd. su pisani u C++, jer u firmi koja pravi igre i zapošljava samo C/C++ programere je suludo praviti te alate u C#, jer se na taj način smanjuje broj programera koji mogu da održavaju taj softver. Probali su kod mene u firmi da prave editor u C#, bilo je sjajno i jednostavno dok nisu shvatili da životni vek softvera nije samo pisanje nego i održavanje, i do kraja su ga portovali u C++. Predhodno su portovali gomilu biblioteka koje su godinama korišćene ovde u firmi iz C++ u C# (računaj i ispravljanje bagova nastalih tim portovanjem). Sve u svemu, prelazak sa C++ na C# je bio skup poduhvat koji nije ništa rešio.

C# je za "nepametne" aplikacije bozje cudo.
Ne zato jer je vrhunski dizajniran nego zato sto ga mama MS i tata Visual Studio najvise vole.

Jeste li primjetili strahotu od od koda koju izbaci VS designer za C++/CLI.


Danas je takva situacija u svijetu po kojoj su "najbolji" jezici upravo oni s najboljom podrskom medju alatima.
To je donekle i opravdano.

Zasto bi se ja psihicki "unistavao" sa uredjivanjem koda u C++/CLI kad mi se sve to moze lijepo samo napraviti u C#-u...


Nece se koristiti C++ zbog toga sto je C# MS proizvod, nego zbog cinjenice da sukladno s razvojem hardware-a raste i kompleksnost igara, tj. nikada se nece stvoriti ona rupa izmedju te dvije stvari u koju se moze ubaciti managed C# overhead od nativnog C++-a.
C# je jos uvijek neefikasan za velike igre - one igre koje donose novce.

Onda mi ti možeš objasniti što radi ona linija koda?



I ti misliš da je čitanje C++ templatea jednako intuitivno kao i običnog C koda, i se svodi na stvar "navike" i "ukusa" ?



Reći za primarni programerski jezik novoizašlog revolucionarnog OS-a najveće softverske kompanije na svijetu da je "prolazno đubre", pogotovo u svjetlu ogromnih promjena koje doživljava u redovnim intervalima od po par godina, može reći samo netko temeljito ištekan iz stvarnosti.

Vidim da si bio jako glasan na temi o VB9. Što jest jest - ovakvim tempom će, kad sljedeća verzija C++ standarda bude donešena 2009, compliant prevoditelji tamo negdje 2010-2011, VB11 biti par svjetlosnih godina po produktivnosti ispred.



Rekao sam već negdje na prvoj stranici, ovdje se ne radi o parametarskom polimorfizmu, već o template metaprogramiranju.



I time je Nedeljkovo pitanje odgovoreno.



Sve od gore nabrojanih su jezično-agnostični pojmovi. Jedini razlog zašto bi C/C++ bio pogodniji za korištenje od nekog drugog jezika jest činjenica da su većina primarnih OS API-ja baš pruženi u C/C++ deklaracijskom stilu, i ne zahtijevaju potencijalno neugodne wrappere kao što je P/Invoke. Većina popularnih CL paketa imaju jako dobro definirane FFI (Foreign Function Interface) definicije.

CL je već debelo korišten za izradu od NASA-in robota, HTTP servera, web dućana pa do video igrica. U većini korištenih scenarija su korištena svojstva jezika koje omogućuju stvari virtualno nemoguće u nekom algoloidnom izbljuvku kakav već C++ jest. Teško da se radi o jeziku koje je isključivo "ljepilo" a ne "supstanca" poput Jave - CL je baš obrnuto.

cynique, ono uopste nije imalo pejorativnu konotaciju nego sam ti zaista dao iskren savet da to nije za tebe posto vidim da ti templates predstavljaju problem i da si frustriran njima. Takodje ako ti je lakse kada pise '*2' umesto '<<' i ako pise '+' umesto '|' onda tako pisi i kada pravis template s ozbirom na to da ti je cak i ovaj jednostavan kod previse komplikovan. Ne znam zasto moras onda sebi da komplikujes i template. Sve moze da se iskomplikuje ako hoces isto kao sto moze da se pise i obfuscated c.


Posto ne shvatas da si jedini koji ovako nesto tvrdi onda neka ti bude, ne vredi da te ubedjujem u suprotno.

A sto se tice C++ i C++/CLI, vidim da ne citas ili ne razumes sta sam rekao tako da pokusaj ponovo da se vratis na tu poruku.

Well, ono što su prikazali, sigurno je više od neke "casual" igrice. Izgleda bolje od mnogih igrica na Nintendu, a i one se dobro prodaju, kako ti već reče. No, nema potrebe za raspravu na tu temu, jer komentar stvarno nije bio ozbiljno u stilu "XNA će da ubije C++ za game dev."

Što se hardvera tiče, poenta je bila da ta igrica koristi samo deo mogućnosti hardvera.. a ako kažeš da ima 3 jezgra, OK.



Nisam očekivao da će taj moj, mislio sam očigledno, (bezazleno) zlonameran komentar za XNA, C# i C++ biti baš tako ozbiljno shvaćen.

Nego, slažemo se, verujem da je C++ super za igrice.

Eto, "samo" to :) - plus direktna kontrola nad memorijom, mogućnost ugrađivanja asm-a, bolje performanse i lakše upravljanje resursima (googlaj za RAII ako sumnjaš) i više nije baš "samo".



Misliš na Vistu? Šta misliš koliko je C#a tamo ostalo? U stvari, voleo bih da se javi Relja da nam ispriča koliko je pokušaj da se koristi C# za sistemsko programiranje zaslužan za činjenicu da se Vista pojavljuje u 2007-oj umesto 2004-oj.

Doduše, ja ne tvrdim da je C# "đubre" (tj. verzija 3.0, 1.0 jeste đubre) - to je sasvim solidan jezik za biznis i web aplikacije, za šta je uostalom i namenjen. Za sistemsko programiranje nije.

Šta misliš koji se jezici najviše koriste u Sun-u? Da pomognem - nije Java :)

Nisam tvrdio da mi je taj kod kompliciran. Još jedna izjava koju mi imputiraš iz vedra neba.

Taj je kod trebao biti nekakav sarkazam na tvoju tvrdnju kako je "stvar navike" lakoća čitanja template mjesto običnog C koda. Dvije (meta)funkcije istovjetne funkcionalnosti prepisane iz prvog primjera knjige posvećene C++ TMP su dane. Očito je da je tvoja tvrdnja u najmanju ruku sumnjiva i kod trivijalnog primjera. Mogao sam dati neki malo žešći kod od kojeg zaboli glava, no dovoljno je i ovo da pogodi poentu.



Još jednom: obsfukirani C kod se piše iz zajebancije. boost nije zajebancija.



Žao mi je, ne ide. Očito sam glup.

To kašnjenje nema nikakve veze sa korištenjem C# za sistemsko programiranje, već je rezultat preambicioznih planova i željenog skupa featurea. Cutler je održao nadahnjujući govor pred mnoštvom, prioriteti su preraspodijeljeni, krenilo se iz početka. MS priznaje svoje greške, i udara žestoko tamo gdje je najtanji. To je i glavni razlog zašto ždere svu konkurenciju.

Eto, neka nam Relja kaže koliki dio primarnog OS API-ja (WPF/WCF/WWF) nije C++. Od PowerShella pa do MMC snapina, sve se prepisuje u C# :)



Sudeći po trendu baziranom na vremenskom uzorku od posljednjih 15 godina, sistemsko programiranje je sve manje bitno. Vrlo će brzo postati potpuno nebitno - za jedno 5 godina kad 20-way procesori budu uobičajeni, a shared state concurrency umre u agoniji, mwhaha :)



Vjerojatno obični C (Solaris i pripadni alati).

Ali mogao si mnogo slicnije da ih zapises, ne znam zasto u jednom modelu koristis '|' a u drugom '+'? Ako nesto poredis onda ne znam zasto bi menjao neke stvari koje ne moras da menjas? Da li zbog toga da bi se pravio pametan ili da namerno pokusas da nesto napravis da izgleda komplikovanije? Koji je razlog bas me zanima? Mogu ja bilo koji template kod da ti jos vise zakomplikujem u C# a da ima istu funkcionalnost tako da ne vidim uopste svrhu tog koda. Taj primer meni ne pokazuje poentu da je template programming komplikovaniji (iako jeste u nekim slucajevima) nego samo pokazuje da tebi template programming jednostavno "ne lezi". Naravno to ne znaci nista lose, nekima ne lezi funkcionalno programiranje, nekima OO i svako bira ono sto mu je lakse.

_{[Ovu poruku je menjao srki dana 31.01.2007. u 00:43 GMT+1]}

..jer dok nije bilo C#, softver iz MS-a nije kasnio?

Ili da nam Relja ispriča koliko zakrpa za Windows i ostale aplikacije su uzrokovane zbog korišćenja C/C++, tj. da li možda iste kategorije propusta i ne postoje sa nekim drugim okruženjima i slično. Verujem da bi i na tu temu imalo štošta da se kaže.

Npr. Visual Studio 2005 nije kasnio. Al' zato Service Pack 1 ima cirka pola giga. Dodao bih tu i igrice - znate neku kompleksniju igricu koja nema problema? Pucanje, blokiranje nekad čitavog kompjutera, a zakrpe su sasvim normalna stvar. Nisam siguran da to nije vezano za sve te prednosti C++ koje si naveo.

C i C++ su svojim "prednostima" doveli celu industriju u takvo stanje da mi kupci moramo da pristajemo da kupujemo (tj. iznajmljujemo) softver koji je poluzavršen i, naravno, nemamo pravo da se žalimo. Svaka im čast, al ja bih onda ipak rađe da izgubim 5 ili 10% na performansama, al' da to čudo radi kako treba i da ne traži zakrpu svakih 7 dana. Kupiću 5 ili 10% brži procesor pa će biti isto.

Čisto kao zanimljivost, koliko znam MS istraživački tim ima onaj OS, Singularity, koji je 99% u C#. Tako da ne znam oko tog da C# ne bi bio nikako pogodan za sistemsko programiranje.

@degojs & cynique:

Reći ću samo da ono što sam rekao o kašnjenju Viste zbog korišćenja C#a nije moje nagađanje. Možete da mi verujete na reč, a i ne morate.

Obični C i "neobični" C++. Java Hotspot je npr čist C++, a i dobar deo Solarisa je kompajliran C++ kompajlerom, da ne pominjem njihov Office.

Ovo je specifično za PC igre. Jer PC korisnici imaju kojekakvo đubre (tzv. craplets) instalirano u OS-u što od samih korisnika što od proizvođača kompjutera da je nemoguće osigurati da će igra raditi na svim mogućim konfiguracijama hardvera/drajvera/spywarea/virusa i wareza. Takođe dosta PC programera su veoma traljavi sa resursima jer se previše oslanjaju na OS. Nema nikakve veze sa programskim jezikom.

Igre na konzolama nemaju ovih problema.

Ja nisam doveo to u pitanje, nego sam samo primetio da je softver kasnio i bez C#. Ili izlazi na vreme, ali pitanje je šta smo to dobili..

Osim toga, tu, sa tim što kažeš, vidim jedan "mali" problem - ceo sistem nije pisan od početka u C#, kao npr. pomenuti Singularity. Verujem da bi bilo malo drugačije da jeste.

A OS je pisan u.. C#?

I tako možemo u nedogled.. A činjenica je da se C/C++ danas manje koriste nego pre i ne vidim da će to da se promeni, naprotiv.

Iz sve ove rasprave se moze izvuci zakljucak da ljudi koji napadaju C++ ne napadaju jezik nego njegov prefix "native".

C++ nevalja, kao rijesenje se nudi C#.
Tempatei nevaljaju, kao rijesenje se nude CLI generics.
Prezentiraju se razne usporedbe softwera, a glavna razlika medju njima je managed/native interface.

Ova rasprava se svela na "managed vs. unmanaged".
Mozda bi od sad bilo pristojnije napadati unmanged jezike u kompletu nego samo C++ koji se smatra njihovim liderom.

Nemoj biti tako isključiv, kao cynique :)

Mislim da je većina ljudi ipak prilično realna, a složićeš se sigurno da C/C++ ipak gubi pozicije na tržištu koje je nekad imao.

http://www.cdf.toronto.edu/~cs...er/reference/WSJ.Microsoft.pdf

Kao što rekoh - preambiciozni planovi, ne korištenje pogrešnog jezika :)



Solaris codebase je daleko veći od StarOfficea i HotSpota skupa - a uglavnom je čisti C.

Sun, baš kao i MS, još odavno usavršava prvo C++ prevoditelj, a potom se optimizacijske izmjene propagiraju na prevoditeljski pipeline običnog C-a.



Zamisli da je kernel + većina sistemskih biblioteka Windowsa napisana u jeziku koji jaaako odudara od C/C++ filozofije....npr. LISP. C# bi tad bio otprilike pogodan za sistemsko programiranje koliko i C++ :)

Jedina (i to ne mala, da ne bi bilo zabune) prednost C++a za sistemskog programiranje jest trivijalna interoperabilnost sa već postojećim C-olikim definicijama u sistemskim bibliotekama, koje se debelo oslanjaju na C-ovski model CPU/memorijskih resursa.

Bilo bi divno da je MS za Win32 API napravio nešto sl. kao mono projekt u Mono.Unix namespaceu za POSIX API.

C++ za igre na konzolama ne dopušta memory leakove, buffer/heap/integer overflowe i gomilu ostalih bugova koji itekako imaju veze sa korištenim jezikom? Ne bih rekao.

Sigurno, jer su jedan velik dio kolaca IT industije bas takve aplikacije koje C# pogoduju - biznis i sl. performance weak app.

Osobno smatram da bi C# bez VS bio nista, nebi se ni izmigoljio van sjene Jave i C++-a. Ali to nije tako i sad se govori o izvrsnom _alatu_ C#.

Dali bi ti mogao imati na dusi GC iza svog OS-a?


NB: Generici nisu _znak_dobrog_dizajna_ C# nego _znak_dobrog_dizajna_ .NET CLI-a.

Ne slažem se sa ovakvom ocenom, koliko god je ti (ili bilo ko drugi) uporno ponavljao. Serverske aplikacije (ASP.NET, npr.) su meni nekako sušta suprotnost toga - moraju da opslužuju velik broj korisnika, dobro iskorišćavaju hardver (bio u pitanju server sa 1 ili 8 procesora), itd, itd. Nisam siguran da to spada u kategoriju "sl. performance weak app".

Ja samo ponavljam da ono što sam rekao nije nagađanje, a ni rezultat pretrage po internetu, ali zaista ne mogu ništa više da kažem o tome.

Verovatno ima više C-a od C++a, ali i ovog drugog ima više nego Jave. Uglavnom, Lispa nema nigde.



A šta misliš zašto nema OS-a čiji je kernel napisan u Lispu? Kao što znaš, ovaj jezik je dosta stariji od C-a.



Gubi i to sa razlogom. Pre 10 godina su ljudi pisali desktop biznis aplikacije u C++/MFC-u a danas od toga nema ništa. Takođe i veliki broj programera radi na razvoju web aplikacija kojih pre 15 godina nije bilo. Samo, kao što rekoh, za sistemsko programiranje i dalje nema boljeg jezika - D može da se slika.



Verovatno bi - ali nije. Kao što rekoh pre par strana, jezik OS-a je C a od jezika koji nude iole ozbiljne mehanizme apstrakcije jedino C++ se zaista lako "snalazi" u takvom okruženju.

Da ponovim, svaki jezik ima svoje mesto: ako ćeš da pišeš web aplikaciju, verovatno ćeš koristiti C#, ali ako ćeš pisati web server, bolje izaberi C++.

Ne nego svaka igra koja se izda je pre toga prosla izuzetno stroge testove. Jednostavno od programera se zahteva da bude mnogo disciplinovaniji. A sto se teme tice mislim da tu raspravi nema mnogo mesta. Niko od vas nije dao nikakve analize vezane za brzinu razvoja koda (u c++ i d-u) (promenljiva x), kao i brzina izvrsavanja "istovetno napisanih aplikacija" (korsicenjem istog algoritma) (promenljiva y). Tek kada se ove dve promenljive puste kroz funkciju f(x,y) = "ispaltivost" mozemo dobiti upotrebnu vrednost nekog kompajlera.

Ma kakve sad "stroge testove"? Prvi put čujem za ovako nešto. Ne postoji nijedan test na svijetu koji može uhvatiti sve leakove, overflowove i sl. bugove koji su itekako inherentni korištenom jeziku - takvo nešto je algoritamski neodlučivo. I zašto bi se takvi testovi obavljali isključivo na konzolnim, ne i na PC igricama.



Bojim se da produktivnost programera nije toliko trivijalno funkcijski ovisna o korištenom jeziku. No neki jezici (bolje reći - paradigma) toliko iskaču da je to ipak nezanemarivo:

http://www.ffconsultancy.com/free/ray_tracer/comparison.html

http://citeseer.ist.psu.edu/41732.html

'U rukama mandusica_vuka, svaka puska bice ubojita'

Dok pricate o stepenima produktivnosti i nivoima apstrakcije, pogledajte sta je ovaj covek uradio u ASMu :

http://en.wikipedia.org/wiki/Steve_Gibson

http://www.grc.com/stevegibson.htm

Jednog dana kad Java evoluira u LISP, ravnajući se po bezbroj puta dokazanom Greenspunovom desetom pravilu, bit će ga, samo pod drugim imenom :) Pogle samo one generalized interfaces i sl. divote koje dolaze u sljedećim verzijama Jave.



Za Lisp su dizajnirani procesori sa hardverskim evalom još dok je Bjarne u pelene srao :) Lambda - ultimativni opkod :)

http://library.readscheme.org/page1.html

OS-evi u Lispu, od CPU mikrokoda pa do TCP/IP stacka?

http://en.wikipedia.org/wiki/Symbolics

Postoje i neke gadne x86 "bare metal" implementacije (sl. kao Singularity) - npr. Movitz, ali nijedna od njih nažalost nije daleko dogurala, prije svega što x86 model (netipizirana memorija, hardverski mehanizmi zaštite) nije dizajniran za jezike poput Lispa i C#. Puno će više prostora za ovakve projektiće biti kad se jednog dana svi neupravljani programi budu izvršavali u sandboxu poput real-mode MS-DOS programa danas na NTVDM (a sudeći prema MS-ovom opisu Vistinog nasljednika, ni to nije tako daleko).

Opet pričaš o stvarima o kojima nemaš pojma, a čak ni dovoljno strpljenja da razmisliš o razlozima.
To što ti prvi put čuješ za testove ti ne daje za pravo da negiraš njihovo postojanje.
Da bi te neko udostojio odgovora, ili uopšte nastavljao diskusiju, hajde ti nama lepo navedi barem
jedan veći projekat na kome si radio - da vidimo na kakvom to silnom iskustvu baziraš svoje stavove.

Aha, znači kriv je x86 model :)

Uglavnom, dok ne stigne svetla budućnost (što je rekao Đinđić citirajući Hruščova: "eto je odmah iza horizonta"), C++ nam ne gine, a bogami ni Fortran ni Cobol.

Nisam negirao njihovo postojanje nego pitao za više informacija, s obzirom da mi je "oni postoje" kranje nedovoljno opisno. Čini se da C++ apologeti na ovom forumu imaju selektivno osjetilo vida, pa im se stvari pričinjavaju kako žele umjesto kako jesu.



Opet čisti ad hominem. Na koji bi način moje (ne)iskustvo invalidiralo tvrdnju da se svi ti "strogi testovi" na konzolama mogu obaviti i na PC-u? S tim da za PC postoji bar 100 puta više sofisticiranijih alata za tamanjenje svih klasa bugova nego što će ikad neka glupa konzola imati.

Znaš, nije meni teško pričati o stvarima o kojima većina ovdašnjih C++ apostola nema pojma i koje bi teško razumjela, no to ne bi bilo ni upola ovoliko zabavno :>

Dakle, najponiznije vas zamoljavam, vaše premudro dostojanstvo, možete li se udostojiti meni, običnome neiskusnom smrtniku, objasniti koji su to "strogi testovi", na koji način otklanjaju bugove inherentne slabo tipiziranom sustavu tipova Cpp-a i zašto ih nije moguće koristiti na vanilla PC-u?

Ajde da ja odgovorim posto sam tu cinjenicu i naveo. Kod izdavanja igre za konzolu developer najcesce ne odlucuje da li je igra dovoljno stabilna da bi se izdala, vec to radi kompanija koja je specializovana za to (za XBOX-MS, za PS1,2,3-SONY, itd...). E u tim kompanijama postoje timovi koji su specijalizovani za testiranja i bukvalno dusu vade igri. Odobrenje da igra izadje igra dobija tek kada prodje sve testove. To konkretno ne znaci da npr. nece postojati neki memory leak, ali onda on nece imati posledice u VISEDNEVNOM neprekidnom igranju (tj. dovoljno je mali da je zanemraljiv). Kod izdavanja za PC sam tim ili bolje reci izdavac odlucuju sami kada ce se projekat izdati i cesto se prave kompromisi izmedju datuma izdavanja i stabilnosti projekta jer je uvek otvorena mogucnost pravljenja patch-a. To u ovom slucaju ne vazi samo za igre vec i za ostale aplikacije (Autodesk npr. izdaje verzije tacno zacrtanog datuma bez obzira da li je aplikacija 100% pouzdana, jer ce service pack to srediti). Uopste nije stvar da li postoje mogucnosti da se nadju greske u projektu (veruj mi da i za konzole postoje takvi alati i to veoma dobri) vec u tome da li je sve ispitano do kraja tj. koliko je programer (ili ceo tim) disciplinovan ili koliko je spreman da pravi kompromise vreme vs. stabilnost.

Ona funkcija f(x,y) = "ispaltivost" ima razlicite koeficijente za razlicite "oblasti" aplikacija. Neke aplkacije moraju da se brzo izvrsavaju, neke precizno, neke stabilno, neke ne moraju ni brzo ni precizno a ni stabilno al moraju brzo da budu gotove. A na kraju ipak ce uspeh nekog kompajlera zavisiti od toga kolika je bila potraznja za njim sto je najcesce odraz njegovih mogucnosti (ali ne i uvek)

Pošto si "lepo zamolio":
Možeš ti obavljati testove na čemu želiš, ako je hardware drugačiji i program mora biti. Tako
da ako nešto radi na PC-u kako treba, nemaš nikakve garancije (čak ni preduslove) da će to
raditi na konzoli kako treba - drugi API/biblioteka/HW. U stvari moguće je ako si Merlin, pa ti
svaki program proradi bez testiranja iz prvog pokušaja.


Svaka čast! Izgleda da je lakše razumeti neku ezoteričnu materiju nego templates ;)
Pozdravi profesora (onog što ti je dao nižu ocenu iz C++-a)!

Nisam ubeđen za ovo poslednje. Ima odličnih serverskih aplikacija (od kojih neke baš web serveri: npr. Jetty, Tomcat) koje su pisane u jezicima kao što je Java i im niko ne zamera što nisu pisane u C++, a daleko od tog da se ne koriste. Mogli bi i da okrenemo stvari pa kažemo, ako ćeš da programiraš bilo šta od početka, dobro razmisli da li ti treba C/C++.

Bilo bi interesantno uporediti i resurse kada se radi na sličnim projektima u npr. C# i Javi vs C++: potrebni novac, vreme i znanje.

Ne znam - IIS 6 je napisan manje-više od nule a korišćen je C++. Može li Jetty da priđe IIS-u po performansama i skalabilnosti? Kako bi napisao HTTP.sys u Javi ili C#u?

Da okrenem na drugu stranu - kad sam učio Javu 1999/2000 manje više ceo svet se ponašao kao da sve treba isprogramirati od početka u Javi i razvijale su se stvari kao što su Java Browser, Java Office, Java OS i šta je bilo od svega toga? Ajde da guglamo:

Java Browser: http://java.sun.com/products/archive/hotjava/index.html (bataljen)
JavaOS: http://en.wikipedia.org/wiki/JavaOS ("Sun now officially considers JavaOS a legacy system and recommends migration to Java ME [1]. This by itself however is not a full replacement, as Java ME is an API specification, which runs on top of an operating system, and not an operating system in itself.")
Java Office: u stvari izgleda da ne postoji projekat koji se tako zove, ali su Lotus i Corel pravili takve stvari: http://www.theregister.co.uk/1999/09/10/lotus_cans_esuite/ i http://www.somis.dundee.ac.uk/pub/corelindex.htm )

@Nemanja:

A-ha. A zašto je IIS6 pisan od nule? Što nisu doterali IIS5? :)

Dakle, sad već imamo situaciju da je projekat morao biti "resetovan" (IIS5->IIS6). Opa, pa to isto kao i Vista hmmm.. Da nije i tu kriv C#?

Ne vidim zašto TomCat ili Jetty ne bi mogli da skaliraju dobro. Imaš li ti informacije da ne skaliraju dobro? I da, stavi resurse iza Jetty-ja kao iza IIS6 pa ćemo onda da ih poredimo.

Šta fali serverskim aplikacijama kao JBoss što su pisane u Javi? Ja još nisam čuo da se negde neko žali što nije u C++.

Čak i da IIS6 daje bolje performanse, a siguran sam da daje (iz poznatih razloga), ja jednostavno mislim da to više nije tako big deal. Znaš li nekog da se odlučio za IIS6/.NET kombinaciju umesto npr. RedHat/JBoss zbog te razlike u performansama?

Druga stvar, ne znam šta hoćeš da kažeš sa ovim nabrajanjem neuspelih Java projekata. Ljudi se nekad zanesu, a i buka je buka.. A svi projekti započeti u C++ su uspešno završeni? Gde nestadoše oni neki MS projekti "Cairo" i slični, a kladim se da nisu bili pisani u Javi.. itd. Da ne kažem još i Duke Nukem Foreva :-)

Slažem se ja da C++ verovatno ne treba ni menjati za mnoge stvari (npr. za taj http.sys) iz "čista mira", ali ne vidim ni da ne postoje sasvim lepe alternative, možda će raditi 5% sporije, ali siguran sam da će doneti mnoge druge prednosti.

_{[Ovu poruku je menjao degojs dana 31.01.2007. u 17:28 GMT+1]}

Testovi se zovu sertifikacija. Prvi Xbox je imao 230 strana tehničkih zahteva koje igra _mora_ da ispunjava da bi uopšte počela sertifikaciju. Da bi uopšte počeo sertifikaciju moraš sam da odradiš testove među kojim je da igra radi 48 sati bez ijednog pucanja ili restartovanja konzole. 20-30 testera testira sve mogućnosti koje postoje u igri i kada završe test, počinju iz početka dok tih 48 sati ne istekne. Ako ikada igra padne, bag se ispravi i taj 48h tajmer se restartuje i počinje se iz početka. Kada im se radni dan završi ostavljaju konzole uključene (neaktivna konzola ima atract mod koji je aktivan, tj. prikazuje ti delove igre). Konzola nema virtualnu memoriju i swapovanje na disk, pa se svaki memory leak primeti. Kada 48h istekne bez ikakvih problema, igra se šalje proizvođaču konzole i onda oni vrše testiranje.

Postoje tehnički zahtevi i za Windows, ali nisu obavezni jer igru može da objavi ko hoće. Pogledaj:
http://msdn2.microsoft.com/en-us/library/ms810463.aspx

Ovo je samo 10% onoga što se zahteva za konzole. Igru za konzole ne možeš objaviti bez odobrenja proizvođača konzole.


Niko ne kaže da ne mogu, nego ih niko ne radi jer nisu obavezni. Takođe dosta PC proizvođača softvera se oslanja na zakrpe, dok zakrpa nema na igrama za konzole. Tj. tehnički ima, ali su ekonomski neisplative zbog skupe procedure sertifikacije. Recimo poteraj DebugView i startuj bilo koju PC igru. Videćeš da PC proizvođači zaboravljaju da izbace npr. OutputDebugString iz igre. Na konzolama poziv za OutputDebugString (tj. sličan poziv na drugim konzolama) je automatska diskvalifikacija na sertifikaciji.

Alati za konzole su mnogo bolji... Vtunes koji je bio zakon ranije je đubre u odnosu na XbPerfView ili PIX na Xbox-u ili profajlere na PS2/PS3. DevKit za konzole ima specijalizovani hardver koji je namenjen isključivo za sondiranje performansi.

Ozbiljno mogao bi da napišeš koji ti je najveći projekat na kojem si ikada radio. :)
I ako imaš išta završeno postuj link na download. ;)

Ček malo Branimire.. pa to što si napisao potvrđuje da je cynique bio u pravu. To što igrice na konzolama nemaju problema kao na PC u stvari je možda i zbog tako rigoroznog testiranja i nemogućnosti da izdaš igru dok tamo neko ne odobri, a ne zato što su kompjuteri korisnika sa instaliranim spyware i tako dalje i dalje..

Pa ovo samo znači da ti npr. MS neće dati dozvolu za izdavanje igrice dok je propisno ne istestiraš i popraviš. Ne vidim tu ništa pozitivno vezano za C++, tj. da ne boluje od istih problema kao pri programiranju za PC. Samo što mora da se popravi više bagova do izdavanja..

A koji programski jezik rešava problem bagova?

Inače nisu svi bagovi na kraju razvoja vezani za bufer overflow i memory leakove. Nego logika iz tehničkih zahteva. Npr. kada izvučeš ethernet kabl, pa izvučeš kontroler, koje poruke se prikazuju korisniku, po kojem redosledu, šta se dešava kada odgovoriš na friend invite iz druge igre, pa tokom restartovanja konzole na novu igru trebaš da se uloguješ na npr. Xbox live servis, a korisnik je u međuvremenu promenio memory card pa ima sasvim drugi username od onog koji je imao pre restartovanja, itd.

Ovde se priča kako treba koristiti neki drugi programski jezik jer rešava problem buffer overflow i memory leak, a u praksi takvi bagovi su u manjini. Osim ako u timu imaš gomilu n00bova koji maštaju da pišu program u Javi i C# ili crtaju program u VB :), a ti ih teraš da pišu u C++.

Pa, u suštini i ne mogu. To je kao kada bi u industriji simulatori izbacili prototipe. Upotreba simulatora se zasniva na pretpostavci da simulator (barem približno) odražava stvarnost. No, na taj način se samo smanjuje broj prototipa, ali konačan izveštaj ne može da se sastavi bez pravog prototipa. Slično je i ovde. Otkud znaš da će igra koja je prošla najrigoroznije testove na PC-ju raditi dobro i na konzoli?

Nisam to ni rekao. Prvo neće ni raditi na konzoli ako je nisi portovao na konzolu... Ali 80% koda u igri je nevezan za platformu, tako da ako si otklonio bagove u tih 80% koda, onda samo brineš o ostatku koda koji nije cross platform. Recimo ako si otklonio sve bagove vezane za AI na jednoj platformi, ne postoji šansa da neki od tih bagova postoje na drugim platformama. Zato se i prave igre za više platformi istovremeno, jer je cena dodavanja jedne platforme relativno mala, jer je najskuplji deo prva platforma. Za što više platformi i različitih C++ kompajlera se aplikacija razvija kod te aplikacije je sve robusniji.

Programski poliglota:)

krsckoorasic: 'a mislim da se i na programske jezike moze primeniti ono "covek vredi onoliko koliko jezika poznaje"'

Svaka cast na misljenu. Nauci ih 10-20 pa ces da vredis 2 dana jer ces prekosutra ici u penziju. (ako budes radio dok ucis programeske jezike)
Stvaro mislis da mozes da radis u 5 smislom odvojenih programski jezika, pratis novine, ucis nove jezike i zaradjujes za zivot?

Pa, ne mora to da bude 10-20 jezika. Onoliko koliko moze da zna i da ih koristi dobro - toliko. Ako je to jedan onda je jedan, ako je 5 onda 5.
Upravo zato - onaj ko moze da kvalitetno zna vise jezika znaci da je sposobniji i "vredniji".

(23.04.2008. - 18:29) Tema je premeštena iz foruma Art of Programming u forum Ostali programski jezici.