Miért PHP?

Egy olyan kérdésem lenne, ami igazából nem tudom, hogy blogra való, de máshova se tudnám beírni, szóval gondoltam itt hátha kapok választ:

Miért php-t használnak a webfejlesztők perl vagy python helyett?

Gondolom banális válasz lehet rá, nálam nyilván sokkal okosabb emberek tudják, de én nem bírok rájönni. Néztem különböző felméréseket, amikből én azt szűrtem le, hogy a python sokkal gyorsabb, mint a php, a perl pedig nemsokkal maradt le a pythontól (vagy csak én értelmeztem félre a statisztikákat). De akkor mégis miért php-t használ a nagy többség?

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=pytho…

( tiger | 2009. 03. 04., sze – 21:40 )

mert sok a php pistike akik szerint a php az a legjobb és mindenre tökéletes nyelv
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Hala az egnek, nalunk (Pannon Egyetem, Veszprem) a Web-alapu rendszerek fejlesztese tantargy keretein belul J2EE alapu megoldasok ismertetese es fejlesztese tortenik. Van egy tantargy, amelyben PHP-ban is lehet beadandot kesziteni (Adatbaziskezelo rendszerek alkalmazasa), viszont van aki Accessel, Qtvel, barmi massal oldja meg a feladatot.
A Webalapu ora jegyzetenek bevezeto eloadasdiain van egy jo megjegyzes: "Mottó: „A PHP gyerekeknek való.”"

"Webre az egyik legjobb, ha nem, a legjobb nyelv."
LOL. Láttál te már másik nyelvet, mint a PHP?
"A PHP -t is lehet magas szinten művelni, meg szarul is csinálni"
Ez igaz, de azért csak könnyebb egy olyan nyelvvel (és a körítéseivel) dolgozni, ami nem hátráltat, hanem a kezed alá dolgozik. A PHP nagyon sok szinten el van rontva, kezdve a logikátlan ad-hoc nyelvi elemeitől az inkonzisztens, és sok helyen használhatatlan API-ján át, a lassú és lyukas interpreteréig bezárólag.

"Ubuntu is an african word, meaning: 'I don't have enough money to buy a Mac'"

( Yorirou | 2009. 03. 04., sze – 22:02 )

1.) PHP-ban nagyon könnyű írni kis dolgokat, mivel direkt arra van tervezve, hogy egy HTML dokumentumba valami kis dinamikus dolgot belerakj
2.) PHP-t lehet kb a "legbiztonságosabban" futtatni ingyenes shared hostingokon
3.) sokan ismerik, sok tutorial van hozzá, könnyebben találsz valakit, aki PHP problémában tud segíteni, mintha valakit django vagy rails témakörben kérdezel
4.) Fizetős hostingokon is azért van, mert az átlag olcsó PHP developer minimálbérért dolgozik, vagy legalábbis sokkal olcsóbban, mint egy Python/Ruby/Perl programozót

"Ubuntu is an african word, meaning: 'I don't have enough money to buy a Mac'"

Attól függ mit akarsz. Ha könnyen akarsz pénzt keresni, akkor PHP.

Ha viszont valami izgalmas dolgot akarsz csinálni, akkor válassz ki egy jobb python framework-öt (django-t szokták ajánlani), vagy fogd meg a ruby on railst és hajrá.

"Ubuntu is an african word, meaning: 'I don't have enough money to buy a Mac'"

( meepmeep v | 2009. 03. 04., sze – 22:49 )

vagy esetleg lehet erdemes lenne vetni egy pillantast java servletekre vagy esetleg java ee -re, de az mar inkabb agyuval verebre :)

( eax | 2009. 03. 04., sze – 23:01 )

Valoszinuleg ez egy onerosito folyamat: a legtobben azert tanuljak meg, mert ebben keszul a projektek legnagyobb resze, es azert keszul ebben a projektek legnagyobb resze, mert rengetegen ertenek hozza (es ezert olcsoert lehet fejlesztot talalni).

Ha csak a sebesseg szamitana, mindenki C-hez irt webserver lib-eket hasznalna (vagy ha ez egy kicsit meredek, akkor is ott van a jsp).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( Nyosigomboc v | 2009. 03. 05., cs – 03:06 )

Van egy mondas, miszerint ha 1000000 majmot 1000000 evre leultetsz 1000000 billentyuzet ele gepelni, akkor irnak neked egy CMS-t PHP-ban. Vagy valami ilyesmi.

Ha ismersz mar par nyelvet, akkor a PHP tipikusan olyan, amit meg lehet tanulni 2 nap alatt ugy, hogy a 2. nap vegere mellektermekkent valami hasznalhato dolog is kijon belole.
Nagyon egyszeru hostingot talalni hozza.
Nagyon egyszeru adatbazist hasznalni belole (csak a sok Pistike persze sechole-t is betesz).

Ha valamit ossze kell dobni, aminek ASAP mukodnie kell, de a futasido nem kritikus (mert mondjuk nem kell sokat futnia), akkor teljesen jo altalanos celu scriptnyelv kliensoldalra is. Egyszer volt egy feladatom, amikor komolyan elgondolkodtam, hogy miben irjam meg: eloturjam a regi Perl tudasom, tanuljak bele egy kicsit jobban a Pythonba, vagy irjam meg PHP-ban, mert az is alkalmas ra. Aztan korbeneztem a korulottem levo webfejlesztokon, hogy hanyan ismerik kozuluk a Perlt (0), Pythont (szinten 0), igy vegul a PHP mellett dontottem, hatha bele kell turniuk majd valamikor.

Szoval azota ez az altalanos celu scriptnyelvem is, ha a bash mar keves. Van benne DB, Regexp, Tidy, meg egy csomo jopofa dolog. DB kulonosen kenyelmes amiota irtam hozza egy (biztonsagos) wrapper reteget. Szoval nem bantam meg.

Hatranya, hogy egyreszt a Pistikek miatt rossz a hire, masreszt - szinten a Pistikek miatt - van benne par rettentoen idegesito dolog (magic quotes), ami idegen rendszeren altalaban be van alapbol kapcsolva.

Hogy kifejezetten webre miert hasznaljak sokan, azt nem tudom. Sebessegere nagyon nincs panaszom, webes kornyezetben meg ugyis a DB a lassu altalaban.
Az is kozrejatszhat, hogy egy csomo CMS-t/portalt irtak mar benne amikor a Python meg nem volt annyira nepszeru, es attol kezdve bebetonozodott. Python egy kezdonek nem veszes, de egy tapasztaltabb programozot az identelese zavarhatja. A Perl meg konnyen atcsaphat write-only kodba, nem az a tipikusan konnyen tanulhato nyelv.
Talan ez lehetett a javascript elonye is: nyelvileg eszmeletlen gany, de aprobb dolgokra jol hasznalhato, es konnyen tanulhato (meg mar elterjedt). Lenne pedig bongeszobe epitett Python is, meg volt par egyeb nyelv korabban.
Azt hiszem, hogy ez a C++ hatranya is egyben: annyira sokretu, hogy joval nehezebb megtanulni a tobbi nyelvhez kepest, inkabb elkezdenek valami mast. Pedig kliensoldalra az a kedvencem meg mindig (webre maceras).
--
I don't always dress in a T-shirt and jeans. Sometimes people give me awards, and I dress like a penguin instead. - Linus Torvalds

"Hogy kifejezetten webre miert hasznaljak sokan, azt nem tudom."

Talán azért, mert egy rakás függvény kimondottan azért került bele, mert webes környezetbe szánták? Bár - gondolom én - eredetileg nem arra tervezték, de mára teljesen átalakult. Persze lehet másra is használni, néhány kisebb, főként szövegfeldolgozó php scriptet én is írtam már, aminek nem muszáj webszerveren futnia. De azért ilyeneket nem php-ban írnék. :)

Perl-ből sem bonyolult adatbázist használni, sőt, szerintem a DBI picit kulturáltabb megoldást ad, de ez ízlés kérdése... Az persze más kérdés, hogy a péhápépistikék hogyan (nem)használják az RDBMS funkcionalitásait, és a legtöbb esetben miért van az összes logika az alkalmazásba beledrótozva, az adatbázisba berámolt constraint-ek, idegen kulcsok, triggerek helyett...

A Python-ról már többször elmondtam a véleményemet: borzasztó, hogy a formázást a nyelv részévé tették -- hirtelen nem is tudom, van-e még értelmes nyelv, aminél így van... Persze, erre jönnek, hogy "de így egyszerű (merthogy úgy kell) szépen formázott kódot írni" -- igénytelenség ellen kötelező érvényű szabályok... ...sza. A változók tipus-alapú prefix/postfix jelölését nem vezetik be véletlenül? Perl-ben is lehet szépen, olvashatóan kódolni, csak i-gé-nyes programozó kell hozzá. Az más kérdés, hogy agyeldobós "naezmosthogyműködik" kódot értelmes nyelvek közül Perl-ben nagyon egyszerűen össze lehet hozni, pl: 


perl -e 'print"@{[grep{(1x$_)!~/^(11+?)\1+$/}2..shift||1e2]}\n"' <szám>

(Feladat: futtatás nélkül kitalálni, hogy mit csinál :-) Ha ez megvan, akkor a hogyan is világos...)

"A Python-ról már többször elmondtam a véleményemet: borzasztó, hogy a formázást a nyelv részévé tették -- hirtelen nem is tudom, van-e még értelmes nyelv, aminél így van... Persze, erre jönnek, hogy "de így egyszerű (merthogy úgy kell) szépen formázott kódot írni" -- igénytelenség ellen kötelező érvényű szabályok... ...sza."

Ha elolvasod ezt, rájössz, hogy egyáltalán nem ez a dolog lényege.

A trehány forma ellen tényleg jó lehet, a véleményem akkor is az, hogy nem a parsernek kell a kódfaragót rábírni a szép és olvasható forráskód elkövetésére. Lehet, hogy formailag teljesen igényes(nek kinéző) kódot böffent ki valaki, tartalmilag viszont nem lesz a top-on.

Kell használnom a Python-t, alapvető dolgokat meg kell tudnom csinálni benne -- mit mondjak, anno amikor C-ben, Pl/SQL-ben, Perl-ben meg a jó ég tudja, hogy még miben programoztam, akkor is el tudtam olvasni a kollégák,illetve az adott projekten dolgozó más fejlesztők kódját. Vagy azért, mert volt egy kódolási előírás, hogy mit, hogyan, miként kell/szabad/lehet leírni, és miként nem, vagy azért, mert értelmes fejlesztőkkel dolgoztam együtt, akik olvasható, normális forrást tudtak készíteni. Ez utóbbi meló épp Perl-ben ment, amiben az ellenzői szerint könnyebb write-only kódot írni, mint nem.

Nem mondod, hogy az a nyitó/záró pl. kapcsos zárójel, begin/end annyira olvashatatlanná teszi a forrást... Most vagy a Python-osok szenvednek diszlexiától, vagy a többi nyelvet használóknak vannak átlagon felüli szövegértési képessége... Azért megnézném, hogy 2-3 oldalnyi, sok szinten behúzott, szintenként max. 3-4 karakternyi behúzással) kód mennyivel olvashatóbb, pláne nyomtatva, mintha az egyes szinteket/blokkokat explicit nyitó/záró elemmel körülhatárolva, ezek mögé a megfelelő kommentet beírva(!) készült forrás. (No igen, a blokk eleje/vége kommentezéséhez igényesnek kell lenni -- volt néhány céges kódolási szabványhoz szerencsém, a legtöbb esetben ez elvárás volt.)

Ugyan az, csak a másik oldalról nézve... Én a tab-ot, meg a space-ek számát nem minden esetben látom, a kapcsos zárójeleket, meg a begin/end párosokat és hasonlókat meg igen... Anno amíg lyukkártyát használt az emberfia, addig nem volt gond, ott tényleg látható volt az, hogy mi, hol kezdődik... No mindegy, én a "whitespace mint nyelvi elem" hozzáállást nem tartom jónak.

Aztán ha copy-paste van, többen dolgoznak, és az egyik tab-ot használ, a másik space-t, a harmadik meg vegyesen tab/space mókát (tudom, hogy ez nagyon nem javasolt), netán nyomdai leadásra kerül a forrás, akkor lehetnek "érdekes" problémák...

Normális editorban a kapcsos zárójeleket, a begin/end párokat is be lehet vasalni, sőt, lehet template-eket csinálni, amivel az alapvető formázásokat beíráskor megcsinálja az editor (meg berakja a megkívánt elemeket, kommenteket, stb.), lustáknak meg ott vannak a forráskód-formázó cuccok is.

( wladek1 | 2009. 03. 05., cs – 08:05 )

Nem szerencsés csak azért leszólni egy nyelvet (gyakorlatilag itt csak ezt látom), mert sokan használják, s olyan weboldalakat készítenek, ami hemzseg a biztonsági résektől...
Gond nélkül lehet bármiben $zart írni; szvsz a python sem kivétel.
Az viszont tény, hogy a php messze van az univerzálistól.

kötöjelkötöjel
Pedig ez nem az! - lécinetámagy! - ervéó

mert lamak.

opensolaris + glassfish idealis, debuggolni konnyu, stb. es nem, nem azert mert en szeretem, hanem mert az. glassfish alatt egy dbt hasznalo tobbretegu alkalmazast kb 15 perc alatt raktam ossze a legutolso demon. jo, en mar gyakorlom egy ideje, de akkoris :)

igaz, JSF egy rakas hugy, legalabbis az 1.2

( Frantique v | 2009. 03. 05., cs – 13:36 )

A kérdésnél maradva: mert népszerű és elterjedt, továbbá a szervereken gyakrabban fellelhető interpreter, mint a perl/python. Továbbá: gyorsan lehet fejleszteni benne a célnak megfelelő dolgokat. Pár string művelethez, ami egy átlag weboldalhoz kell, nem kell több... Ennyi az egész. Ne feledjük: a feladathoz választjuk a nyelvet!
Igaz, hogy akármi egyébben is megoldhatóak a feladatok, de most nem ez volt a kérdés. Lehet villogni perl/python/ruby stb. ismeretekkel, természetesen. Ettől azonban nem leszel sikeresebb.
--
Coding for fun. ;)

( saxus | 2009. 03. 05., cs – 18:25 )

Mert olcsó hozzá a munkaerő. Perlhez vagy Pythonhoz hol találsz emberkét gyorsan, olcsón?

Nézd egy munkaadó szempontjából: Legyen GyorsanOlcsónKódolok Kft. kis 10-20 fős cég, küzd a talpon maradásért, mert ugye az önmagában mégse egy rossz dolog.

Adott egy projekt, legyen mondjuk rá 10M. Felvesz mondjuk 2 embert rá a cég, belekerül mondjuk 9M-jába kompletten cakkumpak. Nincs normális sw design, össze van hányva az egész, normálisan karbantartani se lehet, de a megrendelő megkapja amit szeretne, cég meg bevételhez jut.

Főnöknek elkezdenek szólni, hogy ez azért így mégse jó, legyen inkább xyz. vegyünk fel pythonos emberkét, mert az szép nyelv meg minden meg azok általában tapasztaltabbak is. Főnök körbenéz a munkaerő-piacon, látja pythonos emberke, 2-3x annyit kér, mint a PHP-s. Elkezd számolgatni, idő mondjuk ugyanannyi, viszont költség felugrik 18-20M-ra. Viszont lehet, hogy ennyiért meg nem fogják megkapni a munkát.

És itt jön be az, hogy lehet, hogy lehet találni kompetens embert, aki megcsinálja normálisan a munkát, csak 2x-s árat kér érte, viszont az a cég/projektvezető, aki keveset ért hozzá, nem fogja megérteni, hogy miért jó ez, meg az.

Persze, itt jön be az, hogy akkor meg minek foglalkozik sw fejlesztéssel és stb.

Sebesség meg önmagában nem sokat számít. Alapvetően, mikor több 10-100 kis látogatottságú oldalt rá lehet terhelni egy gépre, akkor nem feltétlen a sebesség lesz az elsődleges szempont, ha pl. +1 gép beállítása kerül +1-2M-ba, viszont más nyelven kódoló embereket szerezni meg +5-10M-ba.

----------------
Lvl86 Troll