Izbor tehnologije za velike Web aplikacije

[degojs]

apsolutno si u pravu, medjutim ono sto ti kompajler automatski pruza je da program pukne u toj situaciji. Ako zelis da uhvatis exception (a na webu to svakako zelis) moras da napises kod koji ce to da uradi, a to isto mozes da uradis i u script jezicima, sva 3 ispljuvana jezika php5, perl i python podrzavaju sasvim fino error handling u zeljenom bloku.

Prvo, ja ovo ništa ne pišem da bi bilo šta pljuvao. Ako si stekao takav utisak na osnovu mojih poruka - grešiš.

Kakav exception kad ja imam GARANCIJU da mi je prosleđen tip int kao ulazni parametar?

Pa i onaj ko koristi moju klasu dobiće još za vreme pisanja koda ili kompjaliranja poruku da poziva funkciju sa neodgovarajućim tipom podataka. Dakle, daleko pre izvršenja aplikacije. A ko će baš da testira sve moguće gluposti..?

S druge strane u C-u sam nebrojeno mnogo puta upucao greskom float u integer ili kopirao veci string u kraci, pa se onda zezao da ispravljam, rekompajliram i linkujem sve ponovo

Pazi, sva bolja okruženja (Netbeans, Visual Studio, npr.) ODAVNO imaju mogućnost da te još za vreme programiranja lepo obaveštavaju o ovakvim stvarima.. Ne vidim kako je to problem. Nismo više u 80-im. Nemoj sad da se hvataš za C koji su koristili ko zna ko, gde i kada.. Problemi sa stringovima? Da li znaš koliko je to besmislena i u Javi i u C#, a i u C++ kako mi se čini?

I kako rekoh - use the right tool for the job. C ima svoju primenu i dan danas. Nećem valjda sad o tome

Int prosledjen umesto stringa, ili obrnuto u vecini skript jezika NIJE GRESKA, jer jezik sam radi casting kako treba i sve ce savrseno lepo funkcionisati, operatori ce dobiti tacno velicinu sa kojom ocekuju da rade i nema problema.

Interesantno, šta će da se desi kada treba da se sabera 1 i "A"?
Pretpostavljam dobićeš string "1A"?

I šta sad? U bazu podataka u kolonu koja je definisana kao int, hoćemo da upišemo "1A" ? Greška?

Nećeš dobiti string "1A"? Dobićeš grešku za vreme IZVRŠENJA jer program ne može da sabere 1 i "A"? I onda neko treba da gleda kod u mojoj klasi, jer je greška tamo prijavljena?

Da ne napominjem koliko je lakše i bolje da se greška uhvati za vreme kompajliranja ili još pre.

Stvar je u tome da NEMAŠ uvek kontrolu nad svim delovima koda. Tako da ne znaš ko i sa kakvim parametrima će da zovne tvoju funkciju. Možda će da zaboravi da proveri da li je korisnik uneo broj ili je greškom otkucao i neko slovo? Moja komponenta sa foo(int p) neće da pukne zbog toga i SIGURNO je bolje da korisnik moje klase dobije obaveštenje o grešci i ispravi grešku u SVOM kodu sa kojim je upoznat, nego da gleda gde i zašto moja klasa nije uspela da upiše rezultat u bazu. Možda nema sors kod, a i da ga ima.. sad treba da gleda po mom kodu..?

Ako smo podelili posao između tebe i mene, gde ti radiš front-end i biz layer a ja data-access layer npr., jasno da nije potrebno da i ti i ja proveravamo da je korisnik uneo broj tamo gde se traži broj a ne da imamo i neko slučajno otkucano slovo? To je tvoj posao, a ja ću samo da "kažem" funkcija prima parametar int i ne brinem o tome..

Da ponovim: ne pričam ovo u smislu "A je glupost, B je jedino dobro." Daleko od tog, ali mogu valjda da kažem gde vidim prednosti jednog pristupa u odnosu na drugi.

[bojan_bozovic]

@ivanhoe

Garbage in, garbage out.

Dobijes tokom izvrsenja argumenat koji nije u odgovarajucem opsegu i uradis INSERT ili UPDATE... Ooops... Cak i u skript jeziku bi bilo bolje da se sve automatski proverava, jer to je svrha tipa/klase, da se fizikalisanje od strane programera smanji, ili bi nam sve bio 32bitni pointer, ko u asembleru

[ivanhoe]

Sad je ispalo da tebi odgovaram na postove, ali u stvari cela prica je krenula oko onoga sto je Bojan pisao, a on je ispljuvao skript jezike, po meni bez dobrih argumenata...zato pominjem pljuvanje...

Originalno napisao degojs

Interesantno, šta će da se desi kada treba da se sabera 1 i "A"?
Pretpostavljam dobićeš string "1A"?

I šta sad? U bazu podataka u kolonu koja je definisana kao int, hoćemo da upišemo "1A" ? Greška?

Nećeš dobiti string "1A"? Dobićeš grešku za vreme IZVRŠENJA jer program ne može da sabere 1 i "A"? I onda neko treba da gleda kod u mojoj klasi, jer je greška tamo prijavljena?

dobices run-time exception...znaci umesto da ti prilikom kompajliranja program kaze parametri za tu i tu funkciju se ne match-uju, dobice kod prvog pokretanja (a to je ekvivalent kompajliranja za skript jezike) poruku da ti tipovi podataka nisu ok, bilo da ti to javi baza, ili da interpreter prijavi da ne mozes da sabiras broj i text....a kad pogledas call stack videces da je ta greska potekla od tvog poziva... sa druge strane ako posaljes '1' umesto 1, to ce da radi savrseno, dok kod jezika sa striktnim tipovima podataka je to greska, koju ces relativno lako da resis, ali takodje i mnogo lakse i cesce da napravis.

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 ?

[bojan_bozovic]

@ivanhoe

Ne radi se tu o skript jezicima - radi se prakticno o striktnim tipovima, ako ocekujes argument u nekom opsegu, a zbog baga ko zna gde dobijes broj van opsega i uradis UPDATE ili INSERT? Bolje je da te onaj koji je napravio kompajler/interpreter postedi rucne provere, jer je to tek zamorno, i uzima vise vremena nego konverzija u drugi tip, pod uslovom da program ima izvesnu slozenost. Ako je program trivijalan nema problema da pises na cemu hoces, ali ako neko drugi moze da zabrlja funkcije koji pozivaju tvoju, sto degojs rece, bolje je da trazi gresku u svom kodu nego da gleda moj ;-) Sto je program kompleksniji striktnost jezika je sve veca prednost, pogotovu kad radis u timu, zato je bolja Java nego PHP i to garant, kad govorimo o velikim projektima (iako ja Javu ne znam, sigurno je tako). Pazi, tradicionalni programski jezici na osnovu koje je Java pravljena (Ada 95, C++) koriste se za programe neuporedivo vece obimnosti od web aplikacije, i napravljeni su upravo za code reuse i timski rad na golemim projektima. Moras da proveravas ulaz za funkciju ako radis u timu, i zato je bolje da ti jezik to sam radi.

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....

Da pises ti PostNuke a ne formmail. Toliko. Sto veci program to vise vremena dobijas bez rucne provere tipa podastaka koji idu u funkciju.

Dalje, i brze je kad je provera tipova automatska, jer je odradjena na brzom kompajliranom jeziku. Evo sta dobih sada (nakon sto sam pola sata pokusavao da pristupim sajtu uz ono DBD:MySQL error)

Problemi u radu

Problemi sa opterecenjem Servera

Korisnici Jabbera mogu da nam se pridruze na chat grupi "elitesecurity@chat.elitesecurity.org" za real-time status.


Hvala na razumevanju i strpljenju,
ES team.

Dakle, govorimo o velikim projektima sa aspekta programera (npr. PostNuke) a ne sa aspekta menadzera ;-))) zar ne? ;-)))

[degojs]

Mislim da ivanhoe oooodavno nije koristio neki dobar alat tipa Visual Studio ili Netbeans pa otud i takvi komentari koji meni nekako liče na nešto što je možda bila gnjavaža pre 10 godina. Danas, ja ne vidim kako tipovi mogu da predstavljaju smaranje, ako koristiš dobar IDE, pogotovo kad od nedavno čak i MS daje VS (Express) besplatno.

Jednostavno, ovi alati su toliko napredovali da taj argument, bar meni, ne stoji uopšte.

[zextra]

O da, stoji i te kako, posebno kad pises, recimo, programe za linux u vim-u i kompajliras preko gcc-a. Tada ti dodje prosto kao osvezenje kada treba nesto na brzinu da skucas u perlu jer ima auto-casting, ali uz "use strict;" i "use warnings;" sve dolazi na svoje mesto.

[nesh]

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.

[bojan_bozovic]

Cekaj malo, ako ti definises promenljivu page : Integer range 1 .. 3 imas izuzetak automatski kad imas url tipa http://example.com/?page=4 nije li bolje tako?

[degojs]

Ček, od kada Java/C# ima manuelnu alokaciju memorije??

Od kad nemaju?

String p = request.getParameter( "username" );
Customer c = new Customer( p );

Šta je to, u obe linije? Kakve veze upravljanje memorijom ima sa strongly/loosely typed pričom, opet te pitam? Pa i u C++ možeš da koristiš garbage collection. Ili string klasu.

Nesh, ti definitivno ne znaš o čemu pričaš. Mene više mrzi da tupim i odgovaram.

Ako ti više odgovaraju loosely typed jezici, slobodno ih koristi. Daleko od toga da nisu dobar izbor pa gomila sajtova je urađena u VBScriptu (ASP), PHP-u i slično tako da niko neće da kaže da su loši, da ne može, itd. Ali nemoj da pričaš stvari koje ne stoje za ove druge. I daj.. pa nemoj da pričaš svašta, uozbilji se malo

[bojan_bozovic]

@nesh

http://www.usenix.org/publications/l...ang/yang_html/

To je potpuni 2D benchmark. A ako treba 128Mb tekstura za 3D da se prenese za X rezultati su jos gori.