Zalazak izvršnog koda
Svi znamo kako je tekao razvoj programiranja i programskih jezika, od mašinskog koda, preko asemblera pa do današnjih viših programskih jezika. Svaka generacija se naslanjala na prethodnu i svodila je na najmanju moguću meru.
Danas prisustujemo još jednoj smeni. Jezici čiji se kod kompajlira u izvršni polako bivaju skrajnuti. Na TIOBE listi od 10 prvoplasiranih jezika samo 3 su klasična. Pri tom je moguće da delphi sklizne sa top 10 liste, a java već godinama vodi.
Šta je uzrok tome? Sve je u parama prost je odgovor. A pravi odgovor je malo složeniji. Glavni razlog je sniženje troškova razvoja i održavanja. Da bi jezik bio produktivniji mora da se izdigne iznad mašine, da postvi debeo izolacioni sloj. Pri tom taj izolacioni sloj dovodi do još jednog efekta a to je lako postizanje platformske nezavisnosti što su neki jezici postvili kao cilj (npr. java) a drugi su bili pragmatični pa su se poveli onom: sve može, a i ne mora, kao u pythonu. Zato se već godinama nije pojavio novi jezik a da je prevodio kod u izvršni (native code) osim projekta jezika D.
Pošto je ovaj razlog stalno prisutan mora da ima još nešto. Rad programera je sve skuplji, a mašina je sve jeftinija. I ne samo to, mašine su sada dovoljno snažne da ne moraju direktno koristiti izvršni kod. Količina biblioteka i softvera napisanog u klasičnim jezicima je dovela do toga da se programiranje u većini slučajeva svodi na pozivanje tog koda koji je već isprogramiran i preveden u izvršni. Npr. PHP je mnogo sporiji od C-a. Ipak za web se programira u PHP-u jer najveći deo obrade nekog web zateva izvršava baza koja je pisana u C-u. PHP samo poziva kod baze i to je par procenata ukupnog vremena a za tih par procenata niko neće da se bakće C-om.
I sami interpreteri koriste kod od ranije i ubrzavaju izvršenje za razliku od starih interpretera. Klasična je priča o upređivanje javine i C implementacije Linpack algoritma. Pokazuje se da nema razlike u brzini, što i ne čudi obzirom na to da se najveći rad u algoritmu svodi na numerička izračunavanja a oba jezika za to koriste istu BLAS biblioteku programiranu u FORTRAN-u :)
Moderni jezici ne koriste priglupe interpretere koji su izvršavali liniju po liniju izvornog koda. Danas se često izvorni kod prevodi na međujezik, imamo inteligentne virtelne mašine koje analiziraju kod, pronalaze uska grla i optimizuju ga, odlučuju da li da objekat alociraju na heap-u ili stacku, primenjuju različite algoritme sakupljanja smeća zavisno od situacije...
Došlo se do novih otkrića i rešenja kod VM. Tu su nove arhitekture, primena niti, novi algoritmi za optimizaciju. To je dovelo do toga da se sad
Šta se danas događa kod jezika sa VM? Primetno je stremljenje ka razdvajanju jezika i VM. Sad je situacija da se jedan jezik izvršava na više VM i da jedna VM može da pokrene više jezika. Za to je potrebno napisati mini interpreter. Pokušava se sve više da se olakša pisanje tih mini interpretera kako bi VM mogla da podrži više jezika. Npr. u JVM 1.6 se to znatno olakšava i samo je potrebno napisati određen pllugin, a plugin za JavaScript se dobija uz JVM.
Postoje i pokušaji da se naprave zajedničke VM za nekoliko jezika. Za Perl, Python i PHP se radi jedna takva mašina. MS se otvorio ka raznim jezicima. Najnovija je podrška pythonu preko IronPython-a. To omogućava da se koriste standardne i druge biblioteke nekog drugog jezika samim izvršavanjem u VM tog jezika. Npr. da se iz pythona koristi SWING i Hibernate. I više od toga: da se python kod prevede u javin bajtod i korsti iz jave ili bilo kog jezika na JVM. Moguće je i odbratno da se bibiliteke u drugom jeziku prilagode VM preko omotavanja, tj. dekorator obrasca. Npr. u pythonu je moguće koristiti QT GUI biblioteku programiranu u C++ preko PyQT omotača.
Sve to dovodi do snažne sinergije. Više nije bitno ko u čemu šta piše. Izbor postaje velik. Svako može da osmisli svoj jezik za neku specifičnu namenu (domain specific) i to implementira za neku VM. Ruše se ograde između jezika i između platformi.
Danas prisustujemo još jednoj smeni. Jezici čiji se kod kompajlira u izvršni polako bivaju skrajnuti. Na TIOBE listi od 10 prvoplasiranih jezika samo 3 su klasična. Pri tom je moguće da delphi sklizne sa top 10 liste, a java već godinama vodi.
Šta je uzrok tome? Sve je u parama prost je odgovor. A pravi odgovor je malo složeniji. Glavni razlog je sniženje troškova razvoja i održavanja. Da bi jezik bio produktivniji mora da se izdigne iznad mašine, da postvi debeo izolacioni sloj. Pri tom taj izolacioni sloj dovodi do još jednog efekta a to je lako postizanje platformske nezavisnosti što su neki jezici postvili kao cilj (npr. java) a drugi su bili pragmatični pa su se poveli onom: sve može, a i ne mora, kao u pythonu. Zato se već godinama nije pojavio novi jezik a da je prevodio kod u izvršni (native code) osim projekta jezika D.
Pošto je ovaj razlog stalno prisutan mora da ima još nešto. Rad programera je sve skuplji, a mašina je sve jeftinija. I ne samo to, mašine su sada dovoljno snažne da ne moraju direktno koristiti izvršni kod. Količina biblioteka i softvera napisanog u klasičnim jezicima je dovela do toga da se programiranje u većini slučajeva svodi na pozivanje tog koda koji je već isprogramiran i preveden u izvršni. Npr. PHP je mnogo sporiji od C-a. Ipak za web se programira u PHP-u jer najveći deo obrade nekog web zateva izvršava baza koja je pisana u C-u. PHP samo poziva kod baze i to je par procenata ukupnog vremena a za tih par procenata niko neće da se bakće C-om.
I sami interpreteri koriste kod od ranije i ubrzavaju izvršenje za razliku od starih interpretera. Klasična je priča o upređivanje javine i C implementacije Linpack algoritma. Pokazuje se da nema razlike u brzini, što i ne čudi obzirom na to da se najveći rad u algoritmu svodi na numerička izračunavanja a oba jezika za to koriste istu BLAS biblioteku programiranu u FORTRAN-u :)
Moderni jezici ne koriste priglupe interpretere koji su izvršavali liniju po liniju izvornog koda. Danas se često izvorni kod prevodi na međujezik, imamo inteligentne virtelne mašine koje analiziraju kod, pronalaze uska grla i optimizuju ga, odlučuju da li da objekat alociraju na heap-u ili stacku, primenjuju različite algoritme sakupljanja smeća zavisno od situacije...
Došlo se do novih otkrića i rešenja kod VM. Tu su nove arhitekture, primena niti, novi algoritmi za optimizaciju. To je dovelo do toga da se sad
new operator u javi izvrši u nekoliko taktova brže nego najbrža implementacija malloc funkcije u C-u a pri tom JVM uz alokaciju radi i inicijalizaciju memorije.Šta se danas događa kod jezika sa VM? Primetno je stremljenje ka razdvajanju jezika i VM. Sad je situacija da se jedan jezik izvršava na više VM i da jedna VM može da pokrene više jezika. Za to je potrebno napisati mini interpreter. Pokušava se sve više da se olakša pisanje tih mini interpretera kako bi VM mogla da podrži više jezika. Npr. u JVM 1.6 se to znatno olakšava i samo je potrebno napisati određen pllugin, a plugin za JavaScript se dobija uz JVM.
Postoje i pokušaji da se naprave zajedničke VM za nekoliko jezika. Za Perl, Python i PHP se radi jedna takva mašina. MS se otvorio ka raznim jezicima. Najnovija je podrška pythonu preko IronPython-a. To omogućava da se koriste standardne i druge biblioteke nekog drugog jezika samim izvršavanjem u VM tog jezika. Npr. da se iz pythona koristi SWING i Hibernate. I više od toga: da se python kod prevede u javin bajtod i korsti iz jave ili bilo kog jezika na JVM. Moguće je i odbratno da se bibiliteke u drugom jeziku prilagode VM preko omotavanja, tj. dekorator obrasca. Npr. u pythonu je moguće koristiti QT GUI biblioteku programiranu u C++ preko PyQT omotača.
Sve to dovodi do snažne sinergije. Više nije bitno ko u čemu šta piše. Izbor postaje velik. Svako može da osmisli svoj jezik za neku specifičnu namenu (domain specific) i to implementira za neku VM. Ruše se ograde između jezika i između platformi.
Comments
Jedva cekam da izadje finalna verzija!
Nazalost na pomenutoj adresi je citav pasus posvecen zapravo kvalitetu i stabilnosti pa se pitam da li je "compatibility" tu samo iz marketinskih razloga.
Bez obzira na backward compatibility, ukoliko je zaista brza koliko kazu, ponavljam, jedva cekam!
from future import [nova stvar koja se uključuje u sledeću ver]
i tako lepo istestiraju i pripreme ljude.
Ali java je veliki jezik, iako u vlasništvu SUN-a njim rukovode velike kompanije, tako da se zaista samo u retkim situacijama dešavalo da se nešto promeni i postane nekompatibilno. Mene to nikad nije zakačilo.