Izbor tehnologije za velike Web aplikacije

[bojan_bozovic]

@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!");

[ivanhoe]

Originalno napisao bojan_bozovic

@Petar

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

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

Originalno napisao bojan_bozovic

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

Originalno napisao bojan_bozovic

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.

Originalno napisao bojan_bozovic

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]

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]

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.

[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

[Ilija Studen]

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]

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 )