Za Petra:

Ako ne PHP, sta bi bilo najbolje resenje, generalno gledano, za zaista velike projekte?
Nemam mnogo iskustva van PHP-a pa me zanima.

mozda python, perl (mozete da pljujete koliko hocete..), java... mada u 90% slucajeva php moze dosta kvalitetno da odradi posao.

@petar: definisi zaista velike stvari, i sta bi bile te greske i nedostaci u dizajnu php-a? ne flamujem, vec pitam, interesuje me.

Uh, teška odluka - zavisi od tipa projekta i njegovih osobina/zahteva.

/me oblači vatrostalno odelo
Mada mislim da bih mirne savesti mogao da preporučim Python ili Javu kao platformu.
E sad - pitanje frameworka je pitanje religije.

Da li su Java i Python bolji u ovom slucaju od PHP-a zbog mogucnosti jezika/platforme ili zbog performansi? Kakve su performanse Ruby-ja?
Kako biste ocenili .NET u ovoj prici?
Mnogo pitam jel da?

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

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

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

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

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...ruby-talk/5334
http://www.oracle.com/technology/pub.../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.

Hvala veliko svima

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.

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.

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. Da, django ;)

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

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.

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?

Na mungosovom blogu u komentarima 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.

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. Projekat? Sitnica, Google Adwords ;) Btw, Xooglers je interesantan blog, pišu ga ex-radnici Googlea.

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

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

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


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

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

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

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.

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

How about Apache Software Foundation - Jakarta Commons?

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

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

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.

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

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.

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.

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

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-iz...plikacije.html

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

Š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 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. Čuo sam da su obojica govornika kritikovali PHP zbog nekih njegovih osobina, pa vam taj video može poslužiti kao dodatno štivo ;)

@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

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

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



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.


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

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

OT:

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?

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.

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.

OT:
C#. Stvar se zove "indexer".

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

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

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

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 :)

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 :)

@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

Ček, ček, ...

Python:
promeni_broj2 je ekvivalentna sa:
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/typ...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.

PHP5 ima podršku za izuzetke. Klasičan try / catch blok. Pri tom imaš i set_exception_handler() 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. "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š?

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

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.

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.

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.

Kako bre "strongly typed" se ne odnosi na Javu i C#?

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.