Izbor tehnologije za velike Web aplikacije

[degojs]

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]

Originalno napisao degojs

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

Originalno napisao degojs

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]

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]

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

Originalno napisao bojan_bozovic

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

[Ilija Studen]

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š?

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]

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]

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]

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]

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.