Poodavno sam čuo za programski jezik D

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

ali ga nisam ozbiljno shvatao, dok juče nisam u C/C++ User Journal-u pročitao uporedni prikaz identity vs equality objekata na jezicima C++, Java, C#, Python i D. Kako vam se sviđa ovo čudo?

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 prej****a 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.