Izbor tehnologije za velike Web aplikacije [Arhiva]

ivanhoe

14. 12. 2005., 22:24

zextra

14. 12. 2005., 22:45

da ne ponavljam vec receno:

http://wiki.w4py.org/python-vs-php.html
http://www.tonybibbs.com/article.php/20030212152811436
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/5334
http://www.oracle.com/technology/pub/articles/hull_asp.html

tu su ti redom: python-vs-php, java-vs-php, ruby-vs-php i asp.net-vs-php.

sto rece ivanhoe, java je zaista enterprise-level jezik u svakom pogledu (zahtevan hardver, skupo odrzavanje, etc etc) - sa druge strane php je vrlo lak i specijalizovan za taj posao koji radi vrlo dobro. python je prilicno dobar jezik - sintaksa ne lici na C, nema neke language construct-e, ali je zato OO u pythonu jos odavno ispred phpa, perla i mnogih drugih skript jezika. asp.net je dobar iz istog razloga iz kog je i ruby on rails dobar - asp.net 2005 omogucava relativno brz razvoj aplikacija, ali ne mogu da zalazim u detalje posto ne znam mnogo vise o tome.

toxonics

14. 12. 2005., 23:21

Hvala veliko svima

Ilija Studen

15. 12. 2005., 10:10

Net je super za rad, narocito u kombinaciji sa C#, ali to znaci vezivanje za Windows + IIS, a to opet znaci niz, pre svega sigurnosnih problema...Apache na Linuxu je ipak mnogo stabilnija i sigurnija varijanta, plus imas milion modula za Apache koji su od velike pomoci..

Ne nužno. Koliko se sećam Oliver mi je baš pre par dana pričao o modulu koji omogućava da se ASP.NET aplikacije vrte pod Apachem. Takođe je bilo mnogo priče o Mono projektu (open source .NET framework) mada ne znam dokle se sa tim stiglo (prestao da pratim).

---

Najgrublja moguća podela.

1. Java i .NET - enterprise level platforme, najviše para se vrti ovde.

2. Python i Ruby - lepi, kvalitetno osmišljeni OO skript jezici opšte namene, ali ponajviše okrenuti hakerima. Prosečan bizbismen nema pojma o čemu se radi kad počneš da im pričaš o njima, ali na .NET i Javu se pali kao hepo kockica :(

3. PHP - domain specific jezik koji se proslavio zahvaljujući svojoj jednostavnosti i mogućnosti da se stvari brzo naprave. U određenim krugovima ga vide kao jezik sa kojim se igraju script kiddies, ali mi znamo bolje od toga ;)

Gde da strpam Perl? Nikad nisam radio sa njim...

Iako sam već rekao da prelazim na Ruby još uvek se dvoumim između njega i .NET platforme. No, to je odluka koju ću morati da donesem u narednih mesec dana tako da...

---

Opet bi trebao split :) Nešto tipa: "Izbor platforme" ili slično.

marinowski

15. 12. 2005., 10:28

Baš juče mi je http://del.icio.us/ pukao sa greškom, i interesantno je da je dao dosta debuga na ekranu (funkcija, paket koji je korišten itd). Još interesantnije je da se radilo o Perlu. Mislio sam da su koristili nešto drugo za tako veliki projekat.

nesh

15. 12. 2005., 15:58

Sa pythonom nemam iskustva, perl je veoma brz i efikasan kad se koristi kao mod_perl modul, a java je isto vrlo solidno resenje, novije verziju su postale solidno brze, ali java zahteva server sa vise memorije nego za perl ili php...

Java je, sto se mene tice, skroz neupotrebljiva za www rad. Previse su generalizovali jezik da bi bio upotrebljiv. ;)

Perl je i dan danas vrlo jak u www domenu zbog ogromne baze korisnika koji imaju xxxx godina iskustva sa njim ali je za izbegavanje zbog ooooogromne lakoce pisanja necitljivog koda.

Python, xexexexe, da njega koristim, ali necu da se bacim u 'vs' pricu. Lepa prica o "real world" performansama je ovde (http://groups.google.com/group/django-users/browse_frm/thread/bf287fc3375b64b3?q=performance&hl=en&). Da, django ;)

Takodje (http://www.jacobian.org/2005/dec/12/django-performance-tips/) - jeste da je (opet) django-related ali ima vrlo dobrih saveta.

Za njega postoji mod_python ali IMHO FastCGI je daleko bolje & brze resenje, jos kada se u igru ubaci lighttpd, ix...

about lighttpd: upravo cu da testiram apache/mod_python vs lighttpd/FastCGI da bi video sta daje manje mem footprint, jede manje CPU, .... Javljam kada zavrsim.

Mozda i Ruby dodje u obzir, Python/Ruby odluka je vise zasnovana na licnom ukusu nego bilo cemu drugom, oba jezika su stravicno mocna i komforna za rad.

Medjutim za velike projekte su perfomanse obicno sekundarna stvar, lakoca timskog rada i skalabilnost koda su mnogo bitnije, pa je zato Java ipak bolja,ona je pravljena upravo za takve stvari...

Za velike projekte performanse su itekako vazne!! Sto veci projekat to veci hit-rate inace - sto bi bio veliki??

Java mi i nije nesto na vrhu spiska skalabilnih i programer-friendly jezika.

Drugi aspekt kod velikih projekata je budzetm jer neko treba da plati sve te ljude koji ce da odrazavaju to....a php danas zna svaki klinac, dok su Java programeri skupi...

PHP je danasnji BASIC (IMO), to sto ga zna svaki klinac ne znaci da je odgovarajuci za sve. Mozda sam pobegao od njega uzasnut tudjim necitljivim kodom, mozda sto operacije sa stringovima lice na C, mozda zbog $var, sto sam milion puta trazio koji parametar nije prosledjen funkciji, ...

Java programeri su pravedno skupi, ko ima zivaca da "sazvace" onoliki API samo da bi pisao/citao fajl i treba da trazi gooomilu para. ;)

btw. Ala odosmo OT, da se ovo split-uje u neku 'vs' temu?

marinowski

16. 12. 2005., 12:38

Na mungosovom blogu u komentarima (http://www.biznisblog.com/tekstovi/najbolje-web-20-aplikacije#comment) je dat vrlo interesantan link na prezentaciju kako je flickr izgradjen:
http://www.niallkennedy.com/blog/uploads/flickr_php.pdf

PHP aplikacija sa Smartyjem i MySQLom. Ima par interesantnih trikova, kao sto je menjanje tipa baze u MyISAM kod slave replikacije. Toplo preporucujem ovu prezentaciju.

noviKorisnik

16. 12. 2005., 15:35

XML isn’t simple :(
PHP 4 doesn’t have good a XML parser
Expat is cool though (PEAR::XML::Parser)
Why doesn’t PEAR have XPath?
Because PEAR is stupid!
PHP 4 sucks!
(čuj ga... neće da mi broji quote u post length... koje mučenje)

marinowski

16. 12. 2005., 19:23

Jeste prezentacija živopisno napisana, ali verujem autoru jer je prezentacija napisana na osnovu iskustva i realnih problema koji su se javljali na neosporno komplikovanom i velikom servisu.

Za razliku od očekivanih specijalnih ekspertskih rešenja, koriste se totalno obični i standardni paketi, koje inače zna svaki klinac, a i nisu zaboravili na smarty kako je servis rastao. Dobro, jesu zaboravili na normalizacijske forme kod baze podataka, a i siguran sam da postoji još mnogo trikova koji se ne pominju.

Takođe je interesantno što nisu prešli na pravu bazu podataka kada je servis postao ozbiljan, nego su vrlo elegantno zaobišli poznate MySQL probleme sa par pametno povezanih repliciranja.

Upućujem na još jedan interesantan članak, šta se može desiti kada se pređe na pravu bazu podataka (http://xooglers.blogspot.com/2005/12/lets-get-real-database.html). Projekat? Sitnica, Google Adwords ;) Btw, Xooglers (http://xooglers.blogspot.com/) je interesantan blog, pišu ga ex-radnici Googlea.

Izvinjavam se što se vraćam na PHP nakon što je tema splitovana :)

DejanVesic

18. 12. 2005., 10:29

Vrlo je bitno šta podrazumevaš pod "velikom" aplikacijom.

Ako se misli na VELIKI BROJ POGODAKA, onda je definitivno bolja tehnologija koja ima na bilo koji način kompajliranje strane.

Skripting jezici, kod kojih parser svaki put obrađuje stranu, su tu u debelom minusu - to itekako zna da pojede:

- procesorsko vreme
- memoriju; ako nisi pod nekim Garbage Collection enabled motorom (.Net, Java) ovo vrlo brzo dovodi do fragmentacije memorije i finalno, do pada servisa

(ovo gornje je sve iz iskustva; u pitanju je IIS i ASP, više detalja imate na blogu mog kolege Alecka: http://www.aplus.co.yu/software-web/asp-best-practices-be-very-careful/ )

Ako se "veliki" odnosi na veličinu / broj modula, onda to najviše zavisi od tvog načina programiranja: jasno odvojeni moduli sa interfejsima između njih, što manje globalnih promenljivih, čist kod bez nekih perverzija tipa cela petlja u jednoj liniji.

Moj izbor je: .Net za sve ozbiljnije projekte (odlično okruženje, kompajliranje u assemblies, mogu da stavim Test Unite za provere funkcionalnosti) i generalno ga vrlo dobro znam :) Za manje projekte, PHP

ivanhoe

19. 12. 2005., 05:24

Još interesantnije je da se radilo o Perlu. Mislio sam da su koristili nešto drugo za tako veliki projekat.

ne znam zasto ljudi nipodastavaju perl toliko? Perl ima sve sto treba za projekat bilo koje velicine. Ima OOP(mada malo cudan), ima vrlo razradjen namespacing i module, ogromnu bazu gotovog i testiranog koda na CPAN-u, a mod_perl nudi odlicne perfomanse, plus par low-level trikova sa Apachom...

Java je, sto se mene tice, skroz neupotrebljiva za www rad. Previse su generalizovali jezik da bi bio upotrebljiv. ;)

paaaa, znam par ljudi koji se ne bi slozili sa tobom, ali posto ni ja ne volim javu, svakako necu ja da je branim :D

Perl je i dan danas vrlo jak u www domenu zbog ogromne baze korisnika koji imaju xxxx godina iskustva sa njim ali je za izbegavanje zbog ooooogromne lakoce pisanja necitljivog koda.

meni je ovo kao da kazes da ne treba seci hleb ostrim nozem jer mozes lakse da se poseces :)

U svakom jeziku mozes da pises necitak kod, a oni $@% u perlu se mozda cine necitkim ljudima koji nisu navikli da gledaju perl kod, ali posle mesec ili dva rada shvatis da oni u stvari dodaju na citljivosti (jer pokazuju tip promenjive). Radio sam na nekim solidno velikim perl projektima i apsolutno tvrdim da u perlu moze bez velikog napora da se pise kod koji je izuzetno citljiv, samo treba project manager da proglasi pravila ponasanja (i zapreti sa -20% plate onima koji prave sranja) i sve bude super....plus perl podrzava ubacivanje helpa direktno u kod preko pod-ova, nesto nalik javadoc-u, sto je isto jako kul stvar...

Za velike projekte performanse su itekako vazne!! Sto veci projekat to veci hit-rate inace - sto bi bio veliki??

Pa nisu svi web based projekti klasicni sajtovi. Imas masu ogromnih aplikacija
sa web interfejsom koje uopste nemaju veliki hit rate, ali su izuzetno komplexne, tipa kompletno knjigovodstvo neke velike kompanije (recimo Telekom ima to), ili web aplikacija za spediciju neke internacionalne kompanije tipa P&G, ili na primer Maximo sistem (sa njim konkretno sam radio, on je pisan u C++ i Javi) koji sluzi da vodi stanje u magacinima (i sve moguce vezano za to, putne naloge, naloge za nabavku, zamenu, optimizaciju transporta, itd..) za ogromne sisteme kao British Petroleum. Njih koriste samo zaposleni kompanije, znaci hit rate je umeren, ali te stvari umeju da budu zilion puta komplikovanije od bilo kog sajta, rade sa ogromnim bazama, puno raznoraznog koda, razvijaju ih paralelno timovi koji su bukvalno na razlicitim kontinentima.. jednom recju mnogo je tu vecih problema od hit-rate-a, koji se uostalom uvek da lako resiti pomocu proxija i dodatnih servera...

marinowski

19. 12. 2005., 10:36

Nemam ništa protiv Perla, naprotiv. I sam ga koristim u skoro svim projektima za backend aplikacije. Bio sam iznenađen (pozitivno) da ga i del.icio.us takođe koristi.

Pametno ste pomenuli da je pravo pitanje šta se smatra velikom aplikacijom: da li je to veliki hitrate, komplikovanost same aplikacije zbog velike količine modula, ili ogromne količine podataka koja mora da se obrađuje u realnom vremenu.

Odgovor na ovo pitanje, naravno, nije jednoznačan. Svako će hvaliti svoje rešenje na koje je navikao, a svoje projekte zvati strašno komplikovanim, ili mission critical ...

Mislim da je najvažnije da se treba imati potpuno poverenje u alat koji se koristi, i da se taj alat zna u dušu, jer opterećenje, bilo to u hitrateu, modulima ili količinama podataka čeka iza ćoška.

degojs

20. 12. 2005., 04:44

nesh
Java je, sto se mene tice, skroz neupotrebljiva za www rad. Previse su generalizovali jezik da bi bio upotrebljiv.

Kako to (ako može konkretno)? Mislim da je ocena "neupotrebljiva" više nego pogrešna.

Java programeri su pravedno skupi, ko ima zivaca da "sazvace" onoliki API samo da bi pisao/citao fajl i treba da trazi gooomilu para.

How about Apache Software Foundation - Jakarta Commons?

Za Javu vredi, manje-više, sve što i za .NET, odnosno obrnuto :)

zextra

20. 12. 2005., 11:06

hehe, znali ste da ce se kad-tad pojaviti neko ko ima pozitivno misljenje o javi, isto kao ja o perlu ;)

bluesman

20. 12. 2005., 13:19

Nije mi jasno, a ne prozivam nikoga jer me mrzi da gledam KO je šta pisao, zašto su ljudi skloni omalovažavanju tehnologije koju ne razumeju ili nisu spremni (voljni) da koriste. I čini mi se da što manje znaš o nečemu, više si sklon da tvrdiš da to nešto ne valja.

zextra

20. 12. 2005., 16:25

@bluesman: mislim da to ljudi rade bas iz neznanja... Ja sam recimo sklon da pljujem bilo sta sto ima .NET u imenu, delom iz nepoznavanja materije, a delom sto bas i ne obozavam korporaciju koja stoji iza istog :)

Uzgred, nisam ja taj koji je omalovazavao Javu ;) Nisam bas upucen, ali znam da Tomcat radi dobar posao kada je Java na Apachu u pitanju...

degojs

20. 12. 2005., 17:56

Gomila gotovih rešenja u Javi na raspolaganju je putem samo Apache Softverske Zadužbine. A gde su onda još i ostali.. Dalje, tu su i platforme kao što je Spring ili Struts, te mnoge "sitnice"/tehnologije/dodaci tipa Jakarta Commons, Axis, JSP EL, JSTL i JavaServer Faces. Pa onda TomCat, JBoss..

Radi na valjda svakom operativnom sistemu, sa valjda svakom postojećom bazom, a u praksi je provereno rešenje - mnoooooooooogo firmi koristi Javu baš na serverima.

Ako se u obzir dodaju i besplatni alati iz "teške" (Eclipse, Netbeans, Sun Java Web Studio..) kao i oni iz "lakše" (JCreator, jEdit..) kategorije, zaista ne znam kako je mogao da napiše to što je napisao. Odnosno voleo bih da čujem šta toliko zamera Javi, baš vezano za www.

robi-bobi

11. 01. 2006., 11:24

petre (i ostali), interesuje me koje su "greške/nedostaci u dizajnu" PHP-a.
t.j. zasto bi bio nepogodan za zaista velike projekte. Koji jezik (platformu) preporucujes?

P.S. ovo nije flame, niti nista slicno. Zaista me interesuje da cujem misljenje nekoga ko moze ovo dobro da objasni.

bluesman

11. 01. 2006., 12:37

@zextra: zbog toga se na live sajtovima isključi $smarty->compile_check pa onda ne proverava sve to

@robi-bobi: I mene to interesuje, naricito definicija "zaista velikih stvari". To je jako rastegljiv pojam.

marinowski

11. 01. 2006., 15:29

Na ovoj temi sam odgovorio u vezi Smartyja, MySQL-a, i slicnih tehnologija koje "nisu pogodne" za velike sisteme:
http://www.devprotalk.com/t436-p2-izbor-tehnologije-za-velike-web-aplikacije.html

Flickr (http://www.flickr.com/) je izradjen sa Smartyjem i MySQLom, a mislim da se Flickr moze nazvati velikim. Bas sam proveravao pre koji dan, dnevno je uploadovano vise od 250.000 fotografija, a ima vise od 90 miliona fotografija, dok se do kraja godine se ocekuje 230 miliona fotografija.

Petar Marić

11. 01. 2006., 18:07

Šta mi lično smeta kod PHP-a:
- nedostatak nativne unicode podrske
- half-baked podrška za objektno programiranje (donekle popravljena sa PHP5)
- nedostatak namespaces. Sve funkcije obitavaju u default namespace-u
- nedostatak virtuelnih metoda
- omogućava lako pisanje izrazito nečitljivog koda
- ne postoji sistemska podrška za internacionalizaciju i lokalizaciju. Gettext biblioteka je problematična zato što nikada nije bila namenjena za multithreaded okruženja. Detaljnije informacije možete naći u starim diskusijama na django (http://www.djangoproject.com/) dev mail-listi u temama koje obrađuju i18n probleme.

Čak i uz sve pobrojane mane (ima ih sigurno još, ali mi trenutno ne padaju na pamet) PHP ima izrazitu upotrebnu vrednost. A right tool for the right job™.

PS: Trenutno skidam snimak sa Snakes and Rubies događaja (http://snakesandrubies.com/event/). Čuo sam da su obojica govornika kritikovali PHP zbog nekih njegovih osobina, pa vam taj video može poslužiti kao dodatno štivo ;)

bojan_bozovic

11. 01. 2006., 18:56

@Petar

O kakvom objektno orijentisanom PHP pricas, kad bas kao i Perl ili Python, ne moras ni da deklarises promenjljivu da bi je koristio? Kako mozes da izvrsis uopste ikakvu apstrakciju tipova u objekte i funkcija u metode nad objektima uz nasledjuivanje osobina kad isti nisu definisani? PHP=bash. Tacka.
Moze CGI program i u C/C++ da se pise, i to bih i radio da mogu ikako (imam root access na serveru) jer bi morao da pisem dobar i citljiv kod. Ne mogu 10 includovanih fajlova da pretrazujem da bih video ima li kolizije sa promenjljivom koju sam negde **mozda** upotrebio.

#!/usr/bin/php -Wall
<?php
$string="Hello world!";
echo $string;
?>

Undeclared variable $string at /cgi-bin/hello.cgi line 2 - jebi si mater

E takav izlaz treba ;) Kzem to zato sto nemas problema sa formmail skriptom, ali velikoj aplikaciji da se snadjes to je jezivo, i sto je veca to je gore, upravo zato sto ti PHP omogucava da pises ocajan kod, i cak stavise, ne dobijas nista ako pises dobar kod (u smislu procesiranja skripte, npr. da ima da se poveca warning level i sl.) i sto vise napises teze ti je da odradis nesto na brzinu jer nemas pojma koje promenljive mozes da koristis. Dalje, bolje je da je jezik kompajliran, makar se izvrsavao interpreterom kasnije, zbog prijavljivanja gresaka tokom kompilacije. Da su skripting jezici striktni kao tradicionalni, bilo bi mnogo lakse odrzavati veliku aplikaciju, plus imas razlog za OOP a to je definisanje potpuno apstraktnih objekata za reuse. Ako u object1.value1 mozes da stavis i string i broj nema nikakve svrhe, jer je upravo smisao OOP da se potpuno sakrije objekt od direktnog referenciranja, recimo: object1.Re i object1.Im definises kao niz, a da ne mozes da mu pristupis kao nizu recimo sa object1[1]!=object1.Im ;) Kako to u PHP ili u Perlu ili u slicnom jeziku (lose da gore ne moze biti). Znam za is_float u PHP, ali ne bi smelo tako da se radi uopste Treba da pisemo i is_httpheader i is_gtkwindow da neko ne udari
$objekt->funkcija("hello world!");
:D

ivanhoe

11. 01. 2006., 23:19

@Petar

O kakvom objektno orijentisanom PHP pricas, kad bas kao i Perl ili Python, ne moras ni da deklarises promenjljivu da bi je koristio?
:D

ovaj, a sto pljujes po stvarima o kojima ocigledno ne znas dovoljno?

u perlu zaista ne moras da deklarises promenjivu ako bas ne zelis (tipa pises skriptu od 10 linija i smara te da kucas vise nego sto moras), ali svaki perl tutorijal pocinje sa preprukom da OBAVEZNO koristis use strict; na pocetku skripte, a tada MORAS da deklarise promenjivu da bi je koristio.

Znaci ovo sto pricas vazi za PHP, ali uopste ne stoji za perl, i ne treba da ih sve trpas u isti kosh...

I takodje u perlu imas mnogo napredniji scope mehanizam nego recimo u C-u, javi ili pascalu jer mozes da deklarises promenjive i kao lexicki lokalne sa my, i kao dinamicki scope-ovane sa local, a mozes i da koristis direktan pristup tabeli simbola pomocu. Tako da mozes mnogo finije da kontrolises sta je vidljivo odakle.

A inace sto se tice prijavljivanja gresaka kod kompajliranja C tu bas i nije neki heroj, pascal ima neuporedivo smislenije i korisnije poruke o greskama...a perl ima jos bolje jer ti uglavnom tacno kaze ne samo na kojoj liniji je greska nego i sta je verovatan problem.. i ima -W mod u kome moze da analizira kod i da ti da warninge oko verovatnih gresaka, tipa ponovljene deklaracije promenjive, promenjivi koje nisu nikad upotrebljen i slicno...

Dalje, bolje je da je jezik kompajliran, makar se izvrsavao interpreterom kasnije, zbog prijavljivanja gresaka tokom kompilacije.

perl kompajlira kod pre izvrsavanja u neku vrstu bytekoda, slicno kao sto radi Java ili .Net

Da su skripting jezici striktni kao tradicionalni, bilo bi mnogo lakse odrzavati veliku aplikaciju, plus imas razlog za OOP a to je definisanje potpuno apstraktnih objekata za reuse.

da su skripting jezici striktni po pitanju tipova, bilo bi mnogo vise gresaka i buffer overrun napada. Svojevremeno se francuska raketa Ariana srusila jer su (u C kodu) greskom u 16 bitnu promenjivu stavili 32 bitni broj. I zato je apstrakcija koju pruza mogucnost da u promenjivu stavis sta god hoces, a da ne moras da proveravas koliko je velik buffer super stvar

Potreba da konvertujes svaki karakter u integer pre nego sto ga upotrebis u nekoj aritmetickoj operaciji i obrnuto bi samo bio izvor gomile bugova. A greske koje bi mogle nastati zato sto si upisao broj u polje gde je trebalo da ide string su izuzetno retke i svode se na to da li znas da koristis neku klasu ili ne. Ako upises pogresne podatke u klasu naravno da nece raditi, ali tu ti strogi tipovi nece pomoci.

recimo: object1.Re i object1.Im definises kao niz, a da ne mozes da mu pristupis kao nizu recimo sa object1[1]!=object1.Im Kako to u PHP ili u Perlu ili u slicnom jeziku (lose da gore ne moze biti).

ne kapiram bas ovaj primer, u kom jeziku mozes tako da pristupis propertiju objekta?

Koliko je meni u znanju, ako sam dobro razumeo sta si hteo da napises, sintaxa bi bila $object1->Im[1] i u PHP i u perlu, a $object1[1] ne bi trebalo da moze ?? To jest, za perl sam siguran da ovo ne moze, jer je tamo objekat referenca, a mislim da i u PHP-u isto. Takve stvari mozes da radis jedino u javascriptu jer su tamo nizovi u stvari propertiji objekta...

degojs

12. 01. 2006., 00:19

OT:
ivanhoe
perl kompajlira kod pre izvrsavanja u neku vrstu bytekoda, slicno kao sto radi Java ili .Net

Samo mali dodatak: .NET kod (MSIL) se kompajlira u baš mašinski kod koji je naravno CPU-specific pre izvršavanja, posao radi JIT (Just-In-Time compiler). Treba praviti razliku između prevođenja izvornog C#, VB.NET, J#, itd. koda u MSIL i prevođenja istog u mašinski neposredno pre izvršenja. Zbog tog "JIT-ovanja" .NET aplikacije imaju ono kašnjenje kada se prvi put pokrenu (npr. kada se prvi put dolazi na neki ASP.NET sajt). Kasnije naravno zastoja nema jer je mašinski kod već u memoriji (pa se dobiva puna brzina). Dakle, ako imaš sajt koji konstantno ima posetioce koji vršljaju po celom sajtu (i koji onda sprečavaju GC da ukloni prevedeni kod iz memorije), max brzina je tu jer JIT ne mora ponovo da kompajlira MSIL. Bar tako sam ja to ukapirao :)

Koliko mi je poznato i Java i .NET imaju mogućnost da se kod prevede u mašinski znatno ranije (gcj za Javu odnosno ngen.exe za .NET) i onda otpada dinamičko kompajliranje.

degojs

12. 01. 2006., 00:47

OT:

ivanhoe:
Potreba da konvertujes svaki karakter u integer pre nego sto ga upotrebis u nekoj aritmetickoj operaciji i obrnuto bi samo bio izvor gomile bugova.

Ma hajde. Isto tako izvor bagova je ako ova konverzija ne mora da se uradi pa dođemo u situaciju da program treba da sabere 23 i "A", zar ne? Iako ti kažeš da su takve greške retke, pitanje je zašto ne uhvatiti takve greške još prilikom kompajliranja?

I zato je apstrakcija koju pruza mogucnost da u promenjivu stavis sta god hoces, a da ne moras da proveravas koliko je velik buffer super stvar

Pa sad.. ništa te ne sprečava da koristiš "velike" tipove podataka. Jednostavno, umesto byte, a ti stavi long. Umesto int, a ti stavi long. Itd. Mada..

Mislim da je besmisleno na ovakav način "braniti" loosely-typed jezike, tj. napadati ove druge. Ja takođe lično malo više volim da radim sa ovakvim "opuštenijim" okruženjima (ako nije nešto mnogo veliko u pitanju), ali daleko da bih bilo šta od ovog gore naveo kao nedostatak nekog jezika.

Kao i uvek - use the right tool for the job.

Ilija Studen

12. 01. 2006., 00:50

Bojane, ako ti PHP zadaje takve glavobolje mislim da bi trebalo da ce baciš u pekare i ostaviš programiranje ljudima koji imaju više živaca.

Uz malo discipline i poštovanje proverenih patterna PHP aplikacije mogu da budu jako lepe i lake za održavanje. Budi dosledan i disciplinovan, dobro dizajniraj svoje aplikacije (nemoj nabacavati kod), razumi platfromu sa kojom radiš i sve će biti u redu.

PS: PHP je daleko od savršenog jezika, razvojni tim je napravio par debilnih odluka u skorije vreme i čini se da će napraviti još par u budućnosti, vrlo je lako sa PHPom napisati glup kod koji je jako teško održavati itd itd itd ali to opet ne znači da se sa njim ne mogu napraviti kvalitetna rešenja.

degojs

12. 01. 2006., 05:46

OT:
ivanhoe:
ne kapiram bas ovaj primer, u kom jeziku mozes tako da pristupis propertiju objekta?

C#. Stvar se zove "indexer".

(Nadam se da se niko ne ljuti zbog ovoliko OT poruka :) )

ivanhoe

12. 01. 2006., 20:40

Ma hajde. Isto tako izvor bagova je ako ova konverzija ne mora da se uradi pa dođemo u situaciju da program treba da sabere 23 i "A", zar ne? Iako ti kažeš da su takve greške retke, pitanje je zašto ne uhvatiti takve greške još prilikom kompajliranja?

ne mozes da saberes 23 i A, jer i PHP i perl imaju razlicite operacije za sabiranje i konkatenaciju, a perl ima cak i razlicite operatore za jednakost (== za brojeve i eq za stringove), i ako pokusas slucajno da saberes ili uporedis pogresne tipove dobices uredno warning.

Sa druge strane na web-u su svi inputi uvek stringovi, i sasvim sigurno bi se desavalo relativno cesto da zaboravis da uradis kasting stringa u int i slicne stvari. Naprosto moja teza je da briga o tipovima podataka predstavlja samo jos nesto o cemu moras da mislis, a to povecava sanse za greske i usporava razvoj samim tim, a istovremeno ne vidim velike prednosti koje pruza...

Mislim da je besmisleno na ovakav način "braniti" loosely-typed jezike, tj. napadati ove druge.

sta znam, nije mi zelja da napadam ili branim nesto, nego pricam o prednostima i manama odredjenih pristupa.. Loosely typed jezici su meni nekako sledeci korak u evoluciji ka visim jezicima, od asembler pristupa gde brines o svemu, preko strong-typed jezika gde brines o tipovima podatka, ka sistemu gde ti programiras logiku, a kompajler brine o ostalim detaljima...i samim tim su, IMHO, napredniji pristup...

degojs

12. 01. 2006., 21:26

preko strong-typed jezika gde brines o tipovima podatka

Pa samim tim što, kako ti reče, PHP i Perl imaju različite operatore za sabiranje brojeva i lepljenje stringova i uredno prijavljuju grešku --- i tu vodiš brigu kog je šta tipa, zar ne? Dakle, ne vidim da si baš oslobođen tog "mozganja".

Druga stvar, pre si kao primer naveo onu neku raketicu što je pala, a sad se ipak ograničavaš na web. Nije baš isto :)

Loosely typed jezici su meni nekako sledeci korak u evoluciji ka visim jezicima, od asembler pristupa gde brines o svemu, preko strong-typed jezika gde brines o tipovima podatka, ka sistemu gde ti programiras logiku, a kompajler brine o ostalim detaljima...i samim tim su, IMHO, napredniji pristup...

Mislim da grešiš. Ovakva striktna provera se traži. Zar bi dobili kolekcije gde se proverava tip podataka koji se stavlja u kolekciji u novoj verziji Jave i .NET (pre nisu imali tu proveru, već je sve išlo kao Object, pa se kasnije radio kasting)?
O da, za kraj, što se brzine razvoja tiče mislim da i tu grešiš. Kod strongly typed okruženja, kompajler će upravo umesto tebe da uhvati gomilu sitnih greščica (od najobičnijeg krivo otkucanog) do onih većih i time sebe oslobađaš da misliš o tome, itd, itd. Stvarčice kao intellisense da ne pominjem. Rekao bih da loosely typed jezici omogućuju brži razvoj sve dok projekti nisu veći i komplikovaniji.

Ajd dobro, od mene dosta da ne počnemo da tupimo :)

bojan_bozovic

13. 01. 2006., 04:58

@ivanhoe

Upravo u tradicionalnim jezicima ne brines o tipovima, a u skript jezicima moras recimo

class nesto {
var $broj1;

function promenibroj1($vrednost) {
if (is_float($vrednost){
$this->$broj1=$vrednost;
}
}
}
i sad moras da koristis is_integer ili is_float ili sta vec u svakoj funkciji nad klasom a ako ih imas hiljadu? Nema web aplikacije sa hiljadu funkcija, u tome je problem, kada radis na stvarno necem velikom, cenices striktnost koju ti namece tradicionalni jezik. Dakle bas moras da vodis racuna o tipovima, dok tradicionalni jezik vodi racuna o tipovima za tebe da ne mesas babe i zabe ;)
Dalje, u dobrom programskom jeziku kada $vrednost nije float imas exception - i mogucnost da gresku obradis bas onako kako ti treba za odredjeni slucaj bez toga da program izbacuje neke nerazumljive greske ili sto je jos gore, zabrlja podatke u nekoj tabeli (v. gore, ovaj kod jos mora da se menja da bi smo bili sigurni da npr. necemo da imamo dvaput isti ID u tabeli, jer ce tiho da preskoci sve ako ne dobije float ;)). Lovljenje gresaka u PHP je zato ocaj zivi, nije problem da se programira ali je problem da se debaguje, i to opasan. A ako hoces i dobro implementirate izuzetke, to bi bila strahovita fizicka rabota ;) a koliko bi izuzeci bili dobri na webu ;) Greska i redirekciju izvrsis na posebnu stranicu ili index, ajd da vidim da neko to rucno implementira

nesh

13. 01. 2006., 12:15

@ivanhoe

Upravo u tradicionalnim jezicima ne brines o tipovima, a u skript jezicima moras recimo

class nesto {
var $broj1;

function promenibroj1($vrednost) {
if (is_float($vrednost){
$this->$broj1=$vrednost;
}
}
}

Ček, ček, ...

Python:

>>> a=1
>>> a+="1"

Traceback (most recent call last):
File "<pyshell#1>", line 1, in -toplevel-
a+="1"
TypeError: unsupported operand type(s) for +=: 'int' and 'str'

class Foo:
def __init__(self):
self.broj1 = 1

def promeni_broj(self, vrednost):
self.broj1 = vrednost

def promeni_broj2(self, vrednost):
# safe
try:
self.broj1 = int(vrednost)
except ValueError, err:
# vrednost nije int, do something

promeni_broj2 je ekvivalentna sa:

void promeni_broj2(int vrednost) {
broj1 = vrednost;
}

I šta je tu gore od "strongly typed" jezika, ili je try:...except: blok komplikovan? Osim sitnice, da kada dobijem (nekako) pogrešan podatak (npr. prosledim string "ABCD" umesto int-a, vrednost će imati vrednost pointera na string bez ikakve poruke o grešci.

Tačnije kod "strongly typed" jezika ja moram unapred i kroz ceo kod da brinem o tipu podataka (a i veličini osim ako ne radim dinamičku alokaciju memorije što stvara druge probleme), kada koristim "loose typed" jezik brinuću o tipu podatka samo tamo gde taj podatak koristim.

BTW zar PHP5 nije dobio nesto slično za rad sa exception-ima?

Najveća razlika između "skript" jezika i "compiled" jezika je u brzini (koja već odavno nije toliko bitna - hardver je daaaaaleko jeftiniji od programerskog vremena) i velike razlike u brzini razvoja aplikacija (za par redova veličine na štetu "compiled" jezika). Da ne pominjem "čuda" kao metaklase, dinamičko generisanje metoda, .....

Bottom line je da kod "strongly typed" jezika greška u tipu prosleđenog podatka (ako se provuče, a moguće je) će dovesti do core dump-a (ili ako je Win u pitajnju čak i do BOD-a), dok će "loose typed" jezik "baciti" exception koji će lako moći da bude "uhvaćen" i obrađen tamo gde treba (ako ne, onda je to bug, a podaci koji budu prijavljenu u exp (stack trace i sl.) će biti sasvim dovoljni da se "nalovi" mesto gde je do toga došlo - mnogo lakše nego da provodim vreme uz debager "loveći" mesto).

I kao što neko reče A right tool for the right job™. Sigurno neću pisati OS u Python-u, ali za web app (a o tome je ovde priča) koristiti C/C++ je definitivno overkill.

Korisno štivo: http://www.sitepoint.com/article/typing-versus-dynamic-typing

p.s. Python (za ostale nisam siguran - ne koristim ih sada previše) ima daleko bolju podršku za exception-e od C++ i Jave IMHO. Takođe za Python postoji pychecker koji moža da uradi (skoro) sve provere oko tipova podataka i sl. kao da se koristi "strongly typed" jezik.

p.p.s. "strongly typed" se ne odnosi na Javu/C# jer su kod njih uspeli da isprave dosta problema sa C/C++.

p.p.p.s. Moj razvojni put ;) se kretao: Z80 asm -> MC68K asm -> C -> (C++, perl, PHP) -> Python. Tako da sam prilično upoznat sa prednostima (a i manama) većine njih.

Ilija Studen

13. 01. 2006., 14:55

PHP5 ima podršku za izuzetke. Klasičan try / catch blok. Pri tom imaš i set_exception_handler() (http://www.php.net/manual/en/function.set-exception-handler.php) funkciju gde možeš da definišeš kako će biti obrađeni izuzeci koje nisi "navatao". Napravio sam da ta funkcija izlista podatke o izuzetku (poruka, fajl, linija, dodatni parametri koje određuje sam izuzetak), backtrace, sadržaj autoglobalnih promenljivih i podatke o instaliranom PHPu na serveru. Jeste malo "prljavo", ali radi bez ikakvih problema i stvarno olakšava razvoj.

Takođe, ako imaš problema sa debugovanjem probaj xdebug (http://xdebug.org/). "Obogaćuje" prikaz grešaka koje baca PHP, dumpovi promenljivih su bolje formatirani, omogućava profiling itd.

Što se tipova podataka tiče zašto getter mora da proverava tip podataka uvek? Zašto ga jednostavno ne castuješ?

function setValue($value) {
$this->val = (float) $value;
}

Za većinu slučajeva ovo je sasvim dovoljno. Kad ti treba stroga provera tipa promenljive (na šta sam retko nailazio) dodaj je... Ako treba da proveriš da li je prosleđeni objekat "valjan" (instanca određene klase / implementira određeni interfejs) u PHP5 možeš da ideš sa function setPerson(Person $var) i pustiš PHP da se brine o tome.

Kao što rekoh, uz malo discipline i pravi alat nema problema :) Nemoj širit dezinformacije ;)

bluesman

13. 01. 2006., 16:56

Slozio bih se sa Ilijom... (jeste off ali nisam mogao da ne kazem). Ilija, svaka ti je Njegoševa :)

Samo bih malo "nadogradio" negovu poslednju recenicu, uz "nedisciplinu" i bez "samokontrole" (tipa da spicimo sto pre, samo da radi kako tako) ni najbolji alat ne pomaze.

bojan_bozovic

13. 01. 2006., 17:09

Sustina je da ce se web aplikacije dalje usloznjavati (PostNuke je 30Mb vec) i postojeci skript jezici ce ili biti zamenjeni jezicima koji koriste kompajler i JIT ili evoluirati, jer je strahovito tesko raditi na projektu koji ima na stotine includovanih PHP fajlova koji su bez ikakve organizacije. Daleko je bolje sve imati na disku u projektu, a na server postaviti kompajliranu binary verziju (recimo sa JIT). Da li bi radije odrzavao 30Mb sorsa u PHP ili C/C++ as simple as that. To ce se svakako desiti, jer se ide na razvoj desktop-like web okruzenja a IMO je sledeci korak teranje aplikacija na serveru. Aplikaciju obimnosti Worda (jer na to se ide) u PHPu neces nikako moci da odrzavas, plus sto ce server-side performanse onda da budu daleko znacajnije (i samim tim JIT a ne skript jezik). Prakticno Web aplikacije nista nisu uznapredovale zadnjih 10 godina - svodi se na isto - pokupimo GET i POST argumente preko CGI i pisemo na stdout da Apache pokupi. A ako treba racunanje (spreadsheet ili ne daj boze neki MathCAD server-side) jer ce se u buducnosti i to traziti za slozene desktop-like aplikacije? Ili cemo koristiti JIT ili wrappere (kao sto u PHP imas wrapper funkcije za ImageMagick i GD koji nisu pisani u PHP)

Tipican primer nove web tehnologije su ti Skype i Yahoo Messenger with voice, a to nece u PHPu. Doduse, to je client-side primer, a to su igre (u Flashu), kako da ih teras server side u skript jeziku (uz renderovanje u Flash na primer?) Na zapadu 4 Megabita u sekundi veza sa internetom nije nikakvo cudo, imacemo za pet godina i frameworkove za igrice u 3D na serveru ;)

Sto se performansi tice, to zavisi samo od toga sta teras, recimo da se [es] gusi non stop. Porazmislite malo, samo zato sto imamo Dual Xeon servere ne znaci da isti ne moze na kolena da se obori.

degojs

13. 01. 2006., 18:45

nesh
Tačnije kod "strongly typed" jezika ja moram unapred i kroz ceo kod da brinem o tipu podataka (a i veličini osim ako ne radim dinamičku alokaciju memorije što stvara druge probleme), kada koristim "loose typed" jezik brinuću o tipu podatka samo tamo gde taj podatak koristim.

Svašta. Upravo obrnuto. Ako ja definišem funkciju:

void foo(int p) { .. }

u toj funkciji ja NE MORAM da brinem o tome kog je tipa "p" - znam da je UVEK tipa int. Korisnik moje klase/funkcije ne može da mi prosledi bilo šta, mora da prosledi int. A to mene oslobađa da mislim o tome šta sam dobio kao ulazni parametar.

"strongly typed" se ne odnosi na Javu/C# jer su kod njih uspeli da isprave dosta problema sa C/C++.
Kako bre "strongly typed" se ne odnosi na Javu i C#?

bluesman

13. 01. 2006., 19:17

bojane, nije mi jasna tvoja prica. Razumeo sam da se prica o web razvoju, ti pominjes 300 MB PHP source za aplikacije tipa MS Word. Odakle ti ideja da ce se takve aplikacije ikada portovati na web? Pa tu ne moze da ti pomogne bilo koja web tehnologija.

I google (da, taj "veliki" google) je poceo i dugo vremena radio (ako jos uvek ne radi) sa php i mysql. Znaci open source resenja. Secam se da sam skoro video blog nekog ex-google lika koji je ispricao price od kojih su se ljudi "smrzavali", nisu mogli da veruju da iza google stoji PHP4 i MySQL 3.23.x. Lik na kraju kaze da ne zna sta se desava od kada je otisao, ali dok je bio tamo koristio se LAMP.

Kakave spreadsheet aplikacije za web? Covece, mesas babe i zabe, to nema veze niti ce ikada imate veze sa web aplikacijama, niti ce ikome ko zna da sabere 2 i 2 pasto na pamet da portuje to na web.

Dakle tema je " Izbor tehnologije za velike Web aplikacije", a ne "hajde da mastamo" ili šbbkbb. Kakvih 300 MB source? :) Ne zezaj bre..

Jedino (ne bas jedino) sto se meni ne svidaj u PHP je taj auto-casting, gde recimo "2" moze da bude isto sto i 2, mada u nekim slucajevima i to ume da olaksa posao.

bojan_bozovic

13. 01. 2006., 20:24

bojane, nije mi jasna tvoja prica. Razumeo sam da se prica o web razvoju, ti pominjes 300 MB PHP source za aplikacije tipa MS Word. Odakle ti ideja da ce se takve aplikacije ikada portovati na web? Pa tu ne moze da ti pomogne bilo koja web tehnologija.

Hoce, bas kao sto je i Skype bio Sci-Fi pre nekoliko godina. PostNuke je vec 30Mb. Dok ti skript jezici rade posao, normalno je da ih koristis, ali nisu za sve. Upravo taj Skype jeste web tehnologija. Dakle, prema svecu i tropar.

@nesh, ivanhoe

with Ada.TEXT_IO,Ada.INTEGER_TEXT_IO;
use Ada.TEXT_IO,Ada.INTEGER_TEXT_IO;

procedure Program is
type Meseci is(Januar, Februar, Mart, April, Maj, Jun, Jul, Avgust, Septembar, Oktobar, Novembar, Decembar);
package MESECI_IO is new Ada.TEXT_IO.ENUMERATION_IO(Meseci);

type Datum is
record
Dan : Integer range 1 .. 31;
Mesec : Meseci;
end record;
procedure Ispisi (Element : in Datum) is

begin -- Ispisi
Put("Mesec: ");
MESECI_IO.Put(Element.Mesec);
Put_Line("");
Put(Element.Dan);

end Ispisi;

MojRodjendan : Datum;

begin -- Program

MojRodjendan.Dan :=17;
MojRodjendan.Mesec:=Oktobar;
-- MojRodjendan.Mesec:="Hello world!"; ;)
Ispisi(MojRodjendan);
end Program;

Dakle, bilo sta sto je tipa Meseci, je tacno u odredjenom opsegu - ja ne moram da brinem da li je ulaz dobar ili ne. Cak stavise, da koristim Get iz Ada.TEXT_IO.ENUMERATION_IO imam izuzetak svaki put kad neko upise hello world! umesto imena meseca ;) Kako onda ja to moram da vodim racuna o tipu, nije mi jasno, kad GNAT to radi ;) Lepo da mi objasnite kako to da ja trebam da se brinem o tipu Meseci ovde (da, da pointer/=integer ili pointer!=integer kako vise volite, probajte malo 64bitni kod da pisete, jer je to greska koju C vuce odkad su ga napravili na PDP-11) Dakle, taj kod koji ce u loosely-typed jeziku da proverava ispravnost argumenata neko je ovde vec napisao i to je sve, posto se sve na kraju svodi na asembler, skripta, JIT, binary, sve ide u asembler pa se izvrsava.

Dakle, u loosely-typed jeziku moras nonstop da proveravas ispravnost argumenata, dok u klasicnom jeziku samo moras svesno ponekad da izvrsis konverziju, a sta je bolje kad imas mnogo koda i jos radis sa drugim ljudima koji ti daju gotov (mozda dobar, a mozda i bagovit) kod?

ivanhoe

14. 01. 2006., 06:39

Svašta. Upravo obrnuto. Ako ja definišem funkciju:

void foo(int p) { .. }

u toj funkciji ja NE MORAM da brinem o tome kog je tipa "p" - znam da je UVEK tipa int. Korisnik moje klase/funkcije ne može da mi prosledi bilo šta, mora da prosledi int. A to mene oslobađa da mislim o tome šta sam dobio kao ulazni parametar.

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.

Znaci ovo sto ti kazes je prednost iskljucivo u situacijama gde se radi o upotrebi pogresnog tip podatka od strane developera, pa da kompajler skrene paznju na to prilikom arzvoja. To stoji, i pogotovo je korisno kod IDE i JIT kompajlera koji ti odmah podvuku gresku.

Medjutim moze na te stvari da se gleda i drugacije. 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.

Stalno se provlaci prica o greskama zbog nedostatka tipova. Koje su to tacno greske? Koji tip greske moze da nastane u php ili perlu zato sto mu je prosledjen broj umesto stringa ili float umesto integera? Koji su to tacno scenariji u kojima takve greske nastaju, tj. navedite mi bar jedan, jer stvarno ne mogu da se setim ni jedne takve situacije za svojih 5+ godina web developmenta...

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

degojs

14. 01. 2006., 07:59

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

14. 01. 2006., 12:24

@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

14. 01. 2006., 16:50

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

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

14. 01. 2006., 17:22

@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

15. 01. 2006., 10:55

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

15. 01. 2006., 19:24

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

15. 01. 2006., 20:26

To ce se svakako desiti, jer se ide na razvoj desktop-like web okruzenja a IMO je sledeci korak teranje aplikacija na serveru.

Nije realno ni pokušavati napraviti "real-time" aplikaciju kroz www protokole, tu ništa ne pomaže, ni C, C++, AJAX, .... prosto, overhead vezan za sam protokol je preveliki.

A ako ti baš treba da remote "vrtiš" real-time aplikaciju rešenje postoji pooodavno - XWindows ;). A i Win ima nekakvu implementaciju tog tipa.

nesh

15. 01. 2006., 20:41

bojan_bozovic

15. 01. 2006., 21:36

Je li? A sta je finalizacija u Adi i Javi? Mislis na malloc pa da sabiras i oduzimas poenter kao u asembleru? A to nece ni u Adi mozes samo da dealociras memoriju ako si siguran da ti instanca ne treba (inace se finalizuje automatski) a kako znam Java je to preuzela od Ade i C++. I u Javi i u Adi imas inicijalizaciju i finalizaciju. Ne znam da li u Javi moze da se dealocira memorija prakticno za zivota instance koja ju je alocirala, ako ti ne treba (bibliotecke funkcije npr.).

A ako ti baš treba da remote "vrtiš" real-time aplikaciju rešenje postoji pooodavno - XWindows . A i Win ima nekakvu implementaciju tog tipa.

Hoces bas da zaradis? E pa treba jedan plugin kao Audioscrobbler. Treba Skype. Zamo, nismo se setili na vreme. ;) To je buducnost. Sto se tice XWindows overhead mu je suvise veliki i trazi mnogo brzu vezu (100Mbit) jer ne prenosi sliku vec funkcije koje se crtaju/renderuju na klijentu, a mislis da ce Yahoo i Google da prihvate Terminal Services kao resenje (tj. da kapituliraju?) ;) Ne bih se kladio.

Ovo gore sto sam ti rekao za alokaciju i dealokaciju memorije na Adi vazi od MIL-STD-1815 standarda koji je usvojen 10 Decembra 1980 (Ada Bajron je rodjena 10 Decembra 1815). To sto je C kao i Asembler ja nisam kriv. Ni u paskalu to nemas a valjda ni u moduli-2 ka direktno zvrljas po memoriji.

degojs

15. 01. 2006., 21:40

zextra
linux u vim-u i kompajliras preko gcc-a

vim? gcc?

Kakve to veze ima sa alatima tipa VS, kakve to veze ima sa webom?

Tada ti dodje prosto kao osvezenje kada treba nesto na brzinu da skucas u perlu jer ima auto-casting
Pa da li je ova tema "kad nešto trebaš da skucaš na brzinu" ili nešto drugo?

nesh:
Nemaju alokaciju/dealokaciju memorije.

Aaa-joooj.. Šta ti pričaš? Ovo, pored što je netačno, nema ni veze sa strongly/loosely typed pričom.

nesh

15. 01. 2006., 22:12

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

15. 01. 2006., 22:18

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? ;)

nesh

15. 01. 2006., 22:20

Aaa-joooj.. Šta ti pričaš? Ovo, pored što je netačno, nema ni veze sa strongly/loosely typed pričom.

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

A što se tiče strongly/loosely typed priče, samo sam hteo da naglasim da problem nije u strongly/loosely tipovima nego više u radu sa alokacijom memorije i sl.

strongly vs loosely typed je više "moj je lepšo/veći ... od tvoga" ;) tip priče jer oba pristupa imaju svoje prednosti i mane. A ovde je (again) tema: "Izbor tehnologije za velike Web aplikacije".

bojan_bozovic

15. 01. 2006., 22:22

Imaju. Definises niz odgovarajuce duzine i odgovarajuceg tipa. Nego, mozda sam trebao da pustim njega da ti odgovori ;)

nesh

15. 01. 2006., 22:29

Je li? A sta je finalizacija u Adi i Javi? Mislis na malloc pa da sabiras i oduzimas poenter kao u asembleru? A to nece ni u Adi mozes samo da dealociras memoriju ako si siguran da ti instanca ne treba (inace se finalizuje automatski) a kako znam Java je to preuzela od Ade i C++. I u Javi i u Adi imas inicijalizaciju i finalizaciju. Ne znam da li u Javi moze da se dealocira memorija prakticno za zivota instance koja ju je alocirala, ako ti ne treba (bibliotecke funkcije npr.).

Finalizacija u Javi služi (obično) samo za "native" metode koji su na neki način (van JVM-a) alocirali memoriju/handle/something da to mogu da srede.

Hoces bas da zaradis? E pa treba jedan plugin kao Audioscrobbler. Treba Skype. Zamo, nismo se setili na vreme. ;) To je buducnost. Sto se tice XWindows overhead mu je suvise veliki i trazi mnogo brzu vezu (100Mbit) jer ne prenosi sliku vec funkcije koje se crtaju/renderuju na klijentu, a mislis da ce Yahoo i Google da prihvate Terminal Services kao resenje (tj. da kapituliraju?) ;) Ne bih se kladio.

Ček, a Skype je remote aplikacija!!?!?!?!? Pa to je klijent za jedan (od xxxx) protokola. IMHO nikakav problem da se implementira u većini skript jezika (ako poseduju dobre audio biblioteke - pySDL npr).

To bi bilo isto da kao da se mail klijent remote izvršava na serveru kada treba da skineš mail. :D

BTW. XWin baš zbog neprenošenja slike sasvim lepo može da radi i preko *modemske* veze.

degojs

15. 01. 2006., 22:32

Č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

15. 01. 2006., 22:52

@nesh

http://www.usenix.org/publications/library/proceedings/usenix01/full_papers/yang/yang_html/

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

degojs

15. 01. 2006., 22:53

@boki: pusti bre sad to.. Svi imamo Google pa možemo da linkujemo sve živo. Meni je jedan dokazivao da postoje vanzemaljci tako što mi je pokazivao koliko stranica na tu temu ima Google.

dinke

15. 01. 2006., 23:56

Izvinjavam se što vam prekidam ovu nebuloznu raspravu, ali ovo mi bode oči:

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

Od kad nemaju?

String p = request.getParameter( "username" );
Customer c = new Customer( p );
Na osnovu čega za gornji kod tvrdiš da se memorija alocira manuelno ?

degojs

16. 01. 2006., 00:03

Pa nije alocirao memoriju dok mu ja nisam naredio da to uradi, zar ne? :) (dobro, možda malo rastegnuto objašnjenje, ali to što sam rekao gledaj u kontekstu cele priče sa neshom). Sve zavisi šta ćeš da proglasiš za dovoljno automatizovano, a šta ne. Pa i u C imaš automatizaciju rada sa memorijom u odnosu na npr. asembler.

Za razliku od toga, za oslobađanje ne moram da brinem - to radi gc, automatski (tamo gde se koristi gc).

Pa i C++ je super po tom pitanju jer ne moraš da se bakćeš sa C stringovima. I tu ne moraš eksplicitno da govoriš koliko memorije i gde tačno, ali nisam siguran da će bilo ko da C++ okarakteriše kao skript jezik zbog toga. Npr.

Standard C++ includes class called string. This class improves on the traditional C string in many ways. For one thing, you no longer need to worry about creating an array of the right size to hold string variables. The string class assumess all the responsibility for memory management.

Pa da, ali tek onda svaki njegov argument ne stoji. Gde to onda, osim u C imamo muku oko oslobađanja i alociranja memorije?

Gde je tu problem o kom nesh priča (veličina stringa..bla bla)? Priča se o nekom C, koji niko ni ne koristi za web programiranje.

Ali kakve to sve skupa veze ima sa strongly/loosely typed pričom?

zextra

16. 01. 2006., 00:37

...I kakve veze imaju poslednje dve-tri strane sa temom???

nixa

16. 01. 2006., 00:40

apsolultno nikakve :)

degojs

16. 01. 2006., 00:44

Slažem se.

Ne znam samo kako mogu da se uhvate za C u svoj toj priči kad ga niko ne koristi za web.

Rasprava je bila oko izbora web tehnologije za veće projekte. Dakle u obzir dolaze .NET, Java, PHP i tako.

I tu može da se priča na temu strongly vs. loosely typed. Ali čim smo počeli o tome, oni o C.

A C/C++ tu baš i nemaju mnogo mesta. Niko ih ne koristi za web programiranje u klasičnom smislu. Čemu se onda uopšte ubacuju takve poruke, vezane za te jezike?

zextra

16. 01. 2006., 00:50

.....here we go again... :(

degojs

16. 01. 2006., 00:59

Ma ionako je već.. :)

zextra

16. 01. 2006., 01:08

Pa dobro, nije bas da se uzdrzavas od komentara koji vode u OT... :) Nisam ni ja bolji, ali kad me neciji post iznervira, ja zatvorim DPT :P

degojs

16. 01. 2006., 01:26

Hehehe, pa jeste. Ali znaš šta ja mislim? Forum treba da promeni ime u PHP pro talk. Ozbiljno :)

Ovako, ja uvek dođem, a u stvari ne bih trebao jer samo pokvarim sve kao "desktop programer".. :)

zextra

16. 01. 2006., 01:29

Meni iskreno nedostaje malo vise diskusije o drugim jezicima... Sve sto krene, obicno ima PHP kao konotaciju, eventualno MySQL - ne uvek, ali uglavnom... I malo vise realnih problema (eno ga post na PHP forumu :P)

nesh

16. 01. 2006., 01:55

# flame off @topic

Izbor platforme za www je daleko od trivijalnog, ako se radi o iole većem projektu, na izbor će više uticati kvalitet raspoloživih framework-a i biblioteka nego sam jezik. Ja sam bio već počeo da "razgledam" ruby (zbog Rails-a) kada me je Django "spasio".

Daleko veći uticaj na performanse ima izbor platforme, db servera i www servera nego sam jezik. Ionako se posle dovoljno promenjenih jezika na novi prelazi za relativno kratko vreme.

xux, popunio sam txtbox na tel. :( Ostatak sutra.

dinke

16. 01. 2006., 02:17

I šta sad, da masakriram ovu temu ili da ostavim ovako kako je ?

@Degojs
Pod manuelnim alociranjem mislio sam na malloc and like f-je u C-u (valjda je tako i u C++, nemam pojma) gde "manualno" alociras objekte tamo gde hoces (CPU registri, stack, heap) i koliko byte-a hoćeš. Kod Jave tvoj kod alocira memoriju isključivo na heapu, i to u oba slučaja (ispravi me ako grešim) osim ako request.getParameter( "username" ) ne vraća referencu na postojeći objekat. Isto tako, JVM GC će po potrebi osloboditi tu memoriju. Inače, nisam se neko vreme igrao sa Javom pa se ograđujem od svojih tvrdnji (ali imam TIJ3 na polici pa ću da se svađam ako me neko bude ispravljao) ;)

degojs

16. 01. 2006., 02:52

Dinke: ma znam što si pitao.

Stvar je u tome da ni jedan ni drugi (C i C++ ) nisu momci koji se koriste generalno za web. Čemu onda čovek tupi o tome..

(usput: C++ može da bude kao C, ali kako rekoh imaš i string klasu, imaš i vector.. bla, bla.. = ne moraš da se drnadaš sa memorijom kao u C..) Da se mene pita i ako bi imao vremena, ja bi to masakrirao :), a ono pre stronly typed vs loosely typed bih ostavio jer to jeste jedna razlika između popularnih web tehnologija (npr. C# vs ASP, JSP vs PHP..).

Ili nek otvori drugu temu pa nek priča o problemima sa memorijom u C (i C++). Ja lično tamo neću ni da se javljam, jer me sve skupa interesuju koliko i lanjski sneg.

Just my 0,02.