Citat:
|
Originalno napisao ivanhoe
mislim slazem se, jeste lepse ako ti kompajler to odmah prijavi, narocito kod JIT kompajliranja, ustedece ti 10-tak minuta posla, ali nije bas toliko strasno i bez toga, zapravo ono sto ja pokusavam da kazem je da naprosto nije istina da se bez toga ne moze, kao sto Bojan tvrdi...a imas s druge odredjenu dozu gnjavaze koju striktni tipovi podataka i kompajliranje nose sa sobom, koja ce po mom iskustvu da te kosta vise od tih 10 ili 15 ustedjenih minuta....odnosno jeste da ces brze nalaziti greske, ali ces ih mnogo cesce i praviti, jer slanje 'ABC' tamo gde se ocekuje 123 zahteva krupan propust developera (u rangu toga da ne zna koji parametar sta predstavlja), i ne desava se cesto, a greske kod castinga su cesta pojava....tako da je pitanje sta je efikasnije za brz razvoj, retki bagovi koji se sporije resavaju, ili cesti bagovi koje lako resis ?
|
Nešto sam već pomenuo u prethodnim post-ovima.
Glavna razlika (IMHO) je to što mi ovde pričamo o
web programiranju. Tako da će gooomila parametara biti najobičniji stringovi (ne računajući na neki od RPC protokola), samim tim skoro sve konverzije će se ionako morati da urade u samom kodu. Definisani tipovi podataka će me sprečiti da ja (ili korisnik klase/funkcije) ne prosledim pogrešan podatak - lepo, iako će to u svakom bolje organizovanom projektu svejedno naloviti unittest-ovi, ali ko će sprečiti
korisnike sw-a da pošalju pogrešne podatke? Definisani tipovi!? Pa većina propusta kod www aplikacija pisanih u kompajliranim jezicima potiče baš od toga (buffer overrun, ...). Tu ne pomažu striktni tipovi već dobar exception handling sistem i
kvalitetno napisan kod.
Daleko od toga da C/C++/etc nisu za web aplikacije, ali glavni razlog za korišćenje
tzv skript jezika je
brzina razvoja sw-a.
Što se performansi tiče, koliko ko troši CPU-a je skroz nebitno kada web app, ionako, skoro 90% vremena provede čekajući na I/O.