Da, nešto poput E&C samo što je u slučaju Erlanga ovo primjenjivo i na produkcijskoj razini. Fundamentalna je razlika što je E&C svojstvo samog IDE-a + debuggera + C++/C# kompajlera. Jednom kad linker izbljuva optimiziran binary, nemoguće je "u letu" zamijeniti pokrenuti program sa novom verzijom ako su izgubljeni podaci iz npr. tablice simbola, različitih faza analize ovisnosti, kontrole toka izvođenja i sl. Već spomenuti hotpatching je nešto najbliže tome, ali on radi samo ukoliko signature funkcije nije izmjenjen, s tim da stara verzija koda ostaje beskorisna u memoriji.
U Erlangu je ovo svojstvo samog jezika, ustvari kao i kod svih funkcijskih (funkcionalnih) jezika posljedica modeliranja na Churchovom
lambda računu, koji predstavlja formalni model izračunljivosti za kojeg se može pokazati da ima istu ekspresivnu moć kao i svepoznati Turingov stroj. U jeziku bez globalnog stanja i side-effecta, nijedna fja ne može modificirati vrijednosti "in place" izvan svog scopea, u svrhu korištenja od strane druge fje (npr. memberi klasa i globalne varijable). Na taj način se može dosegnuti sveti gral debuggiranja - pošto nijedna fja ne ovisi o vanjskom stanju koji je proizveo side-effect druge fje, bug nikad ne ovisi o nekom toku izvođenja nevezanom za trenutnu fju, tj. ne može se dogoditi (kao u imperativnom programu) da se bug događa samo nekad (na MySQL strojevima koji su
pod opterećenjem tjedan dana :P).
Na sl. način su funkcijski jezici otporni na race conditione, deadlocke i ostale glupe MT bugiće, jer locking primitivi nisu ni potrebni! (pošto nijedno stanje ne može dvaput modificirati isti thread, a kamoli dva različita threada). Može se ustvari pokazati da je invokacija takve fje ekvivalentna message passingu a la Smalltalk (Sussman je IIRC napisao papir o ovome..), no ne bih sad ni o skalabilnosti erlang-style procesa niti o inherentnoj paralelizibilnosti koda napisanog u fjskim jezicima (paralelizirajući kompajleri bez neke dodatne anotacije preko pragmi ili kakoveć (OpenMP i sl.) su nedostižan san za kompajlere modernih algoloidnih derivata).
Također, koliko me sjećanje služi otkad sam posljednji put koristio VS, E&C ne radi svaki put, neke izmjene koda smatra "ilegalnim" i zahtjeva potpunu rekompilaciju i restart programa. Probaj npr. izmjeniti baznu klasu tipa :)
Moj je dojam da je primarna svrha E&C eliminirati gubitak vremena tokom debugiranja na otklanjanje najčešćih trivijalnih bugova (pogrešno (ne)inicijalizirane varijable, pre/post uvjeti u kontrolnim programskim konstruktima i sl.) - baš onih kojih ima najviše i na koje se gubi najviše vremena, a ne da bude univerzalno rješenje za live upgrade koda.
Ukratko - poanta je da je u Erlangu ovo osobina samog jezika i programske okoline (mutno je to za definirati, bilo tko tko je neš ozbiljnije radio u lisp dijalektima zna da granica između compile time i runtime, između koda i podataka... nije oštro definirana. Zato je onaj lik i mogao debuggirati raketu na 100 000 000 km udaljenosti :) - dok je E&C (ograničen) feature samog IDE-a + kompajlera + debuggera u (isključivo) MS VS okruženju.
[Ovu poruku je menjao cynique dana 15.10.2006. u 14:27 GMT+1]
Šta kažete na ovu vest... Bugs: OSS vs proprietary software
