Wes, szakadok a viccein, olyan vicces tudd lenni, hahahha  :wub:
 

Az a probléma hogy tájékozatlan vagy, és ezért butaságokat beszélsz.
Én amikor utoljára láttam, a php még mindig a világháló weboldalainak ~70%-át működteti, 2015-ben is.
Ez szerinted miért van?
 

\"mivel igazi programnyelvek\" -> Ezzel azt mondod, hogy a weboldalak ~70%-át, köztük a Facebookot, Wikipédiát,
vagy hogy fiatalabb start-upokat is említsek, a MailChimpet
és még számtalan más fontos piaci szereplőt egy nem igazi programnyelvben írták meg? Nyilván ez ugyan olyan mintha
paintben rajzolták volna meg azokat a weblapokat nem?
 
[/quote]
Addig, amíg vannak olyan emberek, akik meg tudnak bírkózni a programnyelv hiányosságaival, addig egyik programozási nyelv sem \"rossz\". Ez az adatpont sem lényeges, az, hogy hány weboldal használja nem jelent semmit, lehet, hogyha PHP helyett Whitespace-ben írták volna meg, akkor felével csökkent volna a fejlesztési idő.
Plusz a Facebook backendjét nem a PHP hajtja, hanem C alapú (ami megint nem egy abszolút tökéletes megoldás véleményem szerint, de ha a facebooknál ez működik, akkor én nem fogok beleszólni).
 

Ne érts félre, a php valóban nem egy jól felépített nyelv.
Viszont ha kicsit utánaolvasol annak hogy mi is a php, hogyan jött létre, akkor azért nem nehéz látni ennek a miértjét.
A php-t nem pontról pontra tervezve építették fel egy jó design alapján. A php felnőtt. Maga a nyelv eredeti készítője
sosem egy komplett programozási nyelvet akart készíteni.
Gyorsan és hatékonyan akart weboldalakat készíteni egy-két segéd makróval.
Ennyi, a php viszont népszerű lett, pont azért, mert gyorsan és hatékonyan lehet benne weboldalakat készíteni.
A közösség nagyon erős szerepet vállal a nyelv fejlesztésében, tehát a helyzet nyilván nem is hasonlítható mondjuk egy C#-éhoz,
ahol a Microsoft szakemberei folyamatosan teljes munkaidőben dolgoznak a nyelven a legelejétől.
A php felnőtt, kifejlődött, fontos látni hogy ez sokkal inkább hasonlít egy evolúciós folyamatra mint egy jól megtervezett ösvényre.
 
[/quote]
Tisztában vagyok a PHP történelmével, nagyon alap szinten. Értem, mit mondasz. De nem különösebben érdekel, mert lényegtelen a beszélgetés tartalmára nézve.
Az, hogy gyorsan lehet weboldalakat készíteni, az oké. Az, hogy hatékonyan lehet vele jó weboldalakat készíteni készíteni, az is oké. Az, hogy a készítmény hosszútávon, más programnyelvekhez/stackekhez képest fenntarthatóan kezelhető, azt is talán lenyelem. De hogy ezek közül az összeset egyszerre meg lehet valósítani anélkül, hogy az egyik tulajdonság semmissé váljon, abban biztos vagyok.
Az evolúciós folyamatod nagyon jó analógia, csak az a baj, hogy az embernek is megvan még a vakbele, meg a kislábujja, meg egyéb dolgok, amik semmiben nem segítik a fajunk fennmaradását, csupán felesleges dolgok, amik a bajt okozzák. Van rengeteg következetlenség is benne, ami nem segíti a biológusok meg a fiziológusok munkáját. Nyilván lehet PHP-ban is programozni, de a kérdés az, hogy akarsz-e.
 

Tehát, lehet mondani hogy a php rettenetesen van tervezve? Igen. Lehet mondani rá hogy ez nem egy igazi programozási nyelv? Nem.
( Pontosabban lehet, csak az álszentség )
 
[/quote]
Attól függ, mit tekintünk programozási nyelvnek. Ha egy Turing-teljes nyelvet programozási nyelvnek nevezünk, akkor nyilván lehet PHP-t annak hívni. De akkor a Brainfuck is programozási nyelv, meg az ASM is. Lehet benne játékokat írni? Lehet, meg is tették az NES-en. Érdemes írni benne játékokat? Nem igazán. A Brainfuck egy programozási nyelv? Igen. Akarsz benne írni egy magas szintű GUI-kezelő rendszert? Hát, maximum ha mazohista fétised van.
 

Az \"MVC paradigmát\" (becsületes neve szerkezeti minta) használó eszmefuttatásod tökéletesen bizonyítja hogy az ég világon semmit
nem tudsz a php-ról, elolvastál két blogpostot és talán ki is próbáltad, de ennyi, látszik a mélyebb tudás teljes hiánya.
Az MVC pattern használható php alatt is. De ez nagyon lealacsonyítóan hangzik, tekintve hogy a komoly php alkalmazások nagy része
használja ezt a design patternt, sok mással együtt. Mert vannak ám mások is, tulajdonképpen szinte az összes ami az ún. \"valódi programnyelveidben\" is megtalálható.
Meglepetés: https://github.com/domnikl/DesignPatternsPHP
 
[/quote]
Tudom, hogy lehet benne használni, de itt megint csak arról van szó, hogy a PHP-val sokkal könnyebb a rossz dolgot csinálni, mint a jó dolgot. Egy Pylons vagy egy akármelyik másik stack megköveteli, hogy ezt csináljad. A PHP, ami lényegében egy összetákolt CGI wrapper, vidáman fog műkdöni az MVC nélkül is.

---

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 17:34:08[/time] )

---

Ez alatt az alábbit értem: Ha valaki egy hosszú távú projektet kezd el, amiben sok karbantartás és skálázás lesz, használhat Pythont, Railst vagy akármi mást, amiben be van építve az MVC, mint PHP-t egy MVC könyvtárral. Ellentétben ha valaki kezdő PHP-ben és csak most kezdte el az egészet, nem fog ezzel törődni és bele fog égni az agyába a rossz módszer. A PHP-ban sokkal könnyebb rossz kódot írni, mint jó kódot, ilyen egyszerű a probléma.
 

Az a probléma hogy valószínűleg a legkomolyabb php kód amit eddig láttál a szomszéd kisfiúé volt, ott népszerű a
\"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" felállás, de lennél szíves nem egyből feltételezni hogy a világon
mindenhol máshol is ez a legnagyobb szint amire eljut egy php programozó?
 
[/quote]
Lásd fentebb. Nyilván egy WordPress vagy egy phpBB nem ilyen elven működik, ezt nem is feltételeztem vagy írtam. De Pista is tudna olyan kódot írni, ami biztonságosabb, stabilabb, jobban karbantartható és skálzható, mint a gányolmány, amiről beszélünk, ha egy olyan rendszert használna, ami megkövetelné ezt a modellt.
 

 

Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom[/quote]
Ez szimplán nem igaz semmilyen komoly rendszernél.
 
[/quote]
Dehogynem, láttam már olyat, hogy a weboldalt a .git mappával együtt töltötték fel. Ismét, nem a komoly rendszerekről van szó. Meg lehet úgy csinálni, hogy ne legyen szar, de nem lenne jobb, ha már eleve a jó megvalósítási módszert vésné a fejedbe a programnyelv?
 

 

így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb[/quote]
 

 

[/quote]
A konfigurációs fájlok direkt betöltését megakadályozva muszáj őrzőket használni (mint a C-s #define _INCLUDE.INC_INCLUDED #ifdef ...), hogy megakadályozzuk, hogy valaki a nem megjelenítésre szolgáló állományokat direkt betöltse.
 

 

Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).[/quote]
Ez is szimplán nem igaz. Valójában az egész eszmefuttatás elbukik ott hogy \"márpedig azt használsz [apachot], ha PHP-t is használsz\".
Én php-t használok, de Apache-ot nem.
 
[/quote]
Akkor te vagy az egyik szernecsés ember. Amúgy ha nem az Apache+MySQL+PHP kombót használod, akkor egy rails app deployment kb. ugyanannyi időbe telik, mint egy PHP deployment, szóval akkor már egyből nem olyan könnyen valósítható meg a dolog, mint gondolnád.
 

De régebben használtam Apache-ot ÉS git verziókövetőt együtt, és alapjáraton nem voltak elérhetőek a rejtett git mappák.
Egyszerűen nem voltak elérhetőek a netről. Pedig nem tiltottam le külön. (Front Controller)
De amúgy letiltani Apache verziótól függően 3-5 plusz sorba kerül.
 
[/quote]
Ami plusz munka, amit az átlag PHP programozó nem fog megtenni, mert ő \"gyorsan és hatékonyan\" akar weboldalt csinálni, nem az Apache konfig fájllal szarakodni.
 

 

Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
[/quote]
Ez php-ra is teljesen igaz. Sőt, sok esetben még az is mindegy hogy Windows vagy Linux alapú a szerver.
Igazából nem tudom hogy milyen php kódra gondoltad azt, hogy ennyire nem változás tűrő.
Én mint mondtam régen Apache hajtotta az alkalmazásainkat, most már más webszervert használunk, de az átállás miatt egyetlen
sornyi kódot sem kellett átírnunk. És egyetlen perci kimaradás sem volt a kiszolgálásban.
 
[/quote]
Nem mondtam, hogy a PHP-nál nem lehet ezt megoldani, csak megjegyeztem, hogy a legtöbb framework (pl. Pylons) nem jön külön webszerverrel.

---

Minden megvalósítható minden programozási nyelvvel, azért programozási nyelv. Amit meg lehet írni PHP-ban, azt meg lehet írni Brainfuckban meg C-ben is, de nem mindegy, hogy milyen projekthez milyen eszközt választasz. A PHP kb. semmilyen weboldalhoz nem optimális, kis projekteknél kezdő programozóknál nem nyújt megfelelő biztonságos és rosszan felépített kódhoz vezet, nagyobb projekteknél pedig sokkal könnyebben, hatékonyabban, és skálázhatóbban lehet kódot fejleszteni más nyelvekben.
Maga a probléma nem a PHP-val van, hanem a közösséggel és a fejlesztői társadalommal. Kezdő programozóknak lett írva, nem profi fejlesztőknek, de a kezdőknek nem nyújt megfelelő védelmet. A legtöbb embernek fogalma sincs, miért rossz a PHP, miért nem jó összegányolni a tartalmat az appal és hogy vannak más, jobb alternatívák. Ezzel a programozók 90%-a bekerül egy olyan ördögi körbe, amiből nagyon nehéz kimászni.

---

Dupla hozzászólás automatikusan összefûzve. ( 2015. augusztus 31. - 17:46:23 )

---

Hogy ezt bemutassam, lássuk, mi a top 10 legfontosabb kérdés a Stack Overflow-on a php taggel:
 

• 
  How can I prevent SQL-injection in PHP? - ezt a mysqli úgy, ahogy megoldotta, de ha más adatbáziskezelőt használsz, akkor semmit nem ér.


• 
  Reference - What does this symbol mean in PHP? - minden szintaxis kb. benne van ebben a posztban, mellette posztokkal amik elmagyarázzák. Ezt nem a dokumentációnak kellene?


• 
  Why shouldn\'t I use mysql_* functions in PHP? - biztonsági kérdés, mert a mysql api még mindig bent van és vígan lehet használni, szóval az első kérdés igen is aktuális még most is.


• 
  How should I ethically approach user password storage for later plaintext retrieval? - ismét biztonsági kérdés, hogy oldjam meg, hogy ne tudják ellopni a jelszavakat de azért tudjak jelszóemlékeztetőt is küldeni.


• 
  How \'foreach\' actually works - érthetetlen szintaxis, amit SO-n kell elmagyarázni, a doksi helyett.


• 
  How to fix “Headers already sent” error in PHP - egy elbaszott PHP feature, amiben a PHP tagek előtti whitespace beleszámít a szövegbe és felülírja a HTTP fejlécet, amit akarsz küldeni.


• 
  How do you use bcrypt for hashing passwords in PHP? - biztonsági kérdés, az ötszáz közül épp melyik hashelő algoritmus a legjobb a jelszavak tárolásához.


• 
  Secure hash and salt for PHP passwords - hogy lehet jelszót tárolni és sózni, külön pont az MD5-ös lehetőség megemlítéséért. lol.

Mindezekből én azt szűröm le, hogy a felhasználók 90%-ának fogalma sincs, hogy hogy működik a nyelv, amiben programoznak, és akik értik, azok se tudják, hogy hogy lehet biztonságossá tenni az alkalmazásaikat.