Eh ...
Dolazak C++ bildera i nije ostavio neki trag ! Možda zato što je od prethodnog (i jedinog !) posta prošlo 6 mjeseci :-). Yap, mora biti da je to.
Al' popraviti ću se ! Obećavam !
Moj politički alter ego je zadnjih pola godine (znate da su bili izbori, jel'da ;-) bio poprilično zauzet ispravljanjem razno raznih krivih Drina a usput i lamentiranjem o jadnom stanju našeg obrazovanja, ali nekako se mislim da je došlo vrijeme angažirati se i u IT blogosferi.
Iako me je iskustvo naučilo da je objavljivati unaprijed „planove“ za postove vrlo tricky stvar (iskustvo moje a i s drugih blogova mi govori da je dostizanje i 50 % plana u većini slučajeva nedostižan cilj !), I'll go for it ! Uostalom, reaktivacija bloga bez malo konkretnijeg plana baš i nije pametan potez i lako bi moguće odvela ovaj blog u još jednu hibernaciju :-)
Prva tema kojoj se planiram posvetiti u par postova je STL/CLR. Za one slabije upućene u C++, STL (Standard Template Library) je biblioteka standardnih programskih komponenti koju su sa zavišću gledali pripadnici vjera u druge programske jezike (ili bar tako C++ gurui vole misliti ;-).
U svakom slučaju, STL je jedan od najjačih aduta C++a, iako se mora reći da je s uvođenjem genericsa u .NETu i pripadnih strogo tipiziranih kolekcija (ne koristite više ArrayList, jel'da ?) stvar malo ujednačena.
Elem, STL/CLR je port STL librarya na .NET koji dolazi standardno sa Visual Studiom 2008 i koji sam jedva dočekao ! Međutim, pri prvom pokušaju korištenja STL/NET-a sam naišao na bug :-(, i to će biti tema prvog posta.
Nakon toga slijedi malo istraživanje runtime performansi standardne (native) C++ implementacije STL-a i implementaciju STL/NET. Jedna od ključnih osobina STL biblioteke je da garantira određene performanse za pojedine vrste operacija nad containerima/strukturama podataka (npr. O(1) za vector<>, O(n) za find u list<>, a O(log2n) za map<>).
Očekivano je da će ista O-složenost vrijediti i za STL/NET containere, ali mene živo zanima usporedba apsolutnih vremena za izvršavanje ekvivalentnog skupa operacija nad pojedinim vrstama containera. Da li postoji penalty zbog Garbage Collectora, i ako da, koliki je ?
A nakon što obradim STL/NET, krećem(o) u nepoznato :-).
F# !
Programski jezik proizašao iz Microsoft Research Laba koji kombinira proceduralnu, objektnu i funkcionalnu paradigmu, baziran je na .NET Frameworku, može ga se koristiti i kao skriptni jezik i sve u svemu it smells good :-)
Vrijeme je za novi paradigm shift i krajnje je vrijeme za hvatanje tog vlaka ...
A oni koji će na to odmahnuti rukom i reći: „Što će nam još jedan jezik, C#/Java su zaaaakon !“ ...
Heh, to su isto meni govorili Visual Basic-aši prije 10 godina kad sam ih pilio sa C++om i OO programiranjem :-))) Istina, nisu završili u C++ već u C# kampu, ali više od njih ne čujem „ih, što će nam ti objekti, kakvi su to bakrači, vidi kako ja to, klik, klik, klik i evo forme s podacima iz baze“ :-P.
OO paradigma je tu da ostane, ali popularnost dinamičkih/skriptnih jezika (Ruby, Python) ipak dosta govori. Late binding is all the rage, a i C# u svojoj 3.0 verziji ide u tom smjeru !
U svakom slučaju, biti će zanimljivo učiti novi programski jezik ... nisam već dugo .
A ako mislite da je s F#om iscrpljena lista potencijalno zanimljivih jezika, evo popisa iz mog ComputersProgramming languages bookmark foldera:
F# – sve rečeno
Ruby – ka' da su malo pali (u spinu :-), ali pratim IronRuby i Ruby.NET
Python – čisti Python mi se čini idealan za skripte, a IronPython obećava
Scala – to je sada in
Boo – idealna zamjena za C kao prvi programski jezik (a i dolazi free sa SharpDevelop razvojnim okruženjem – vidi jednostavne primjere na Wikipediji)
D – improved C++ !?
Erlang – concurrency će za par godina biti all the rage (lako kad ih je dvije, ali što kad u računalu postoji 8 jezgara u 2(4) procesora) ?) a tu je, barem tako kažu people in the know, Erlang naprosto neprejebiv :-)
LISP – bol u teoretical-computer-science srcu mom ...
Daaa, mogli bi biti zanimljivo ...
Post je objavljen 28.01.2008. u 23:15 sati.