A Microsoft bejelentette, hogy befejezi a PHP hivatalos támogatását a 8.0-tól kezdve

Címkék

A php.internals csoportban Dale Hirt bejelentette, hogy a Microsoft befejezi a PHP hivatalos támogatását a 8.0-s verziótól kezdve:

My name is Dale Hirt and I am the project manager for PHP inside Microsoft.

We currently support PHP with development and build efforts for PHP 7.3, and PHP 7.4.  In addition, we help with building PHP 7.2 on Windows when security fixes are required..

However, as PHP 8.0 is now ramping up, we wanted to let the community know what our current plans are going forward.

We know that the current cadence is 2 years from release for bug fixes, and 1 year after that for security fixes.  This means that PHP 7.2 will be going out of support in November.  PHP 7.3 will be going into security fix mode only in November.  PHP 7.4 will continue to have another year of bug fix and then one year of security fixes.  We are committed to maintaining development and building of PHP on Windows for 7.2, 7.3 and 7.4 as long as they are officially supported.  We are not, however, going to be supporting PHP for Windows in any capacity for version 8.0 and beyond.

Hozzászólások

Nem is tudtam, hogy volt Microsoft által támogatott PHP kiadás. Ezekszerint volt olyan is, aki PHP-s szörnyet Windowson hosztolt? Hogy ebben a kombinációban mi a jó, azt fel nem foghatom, de azért szomorú vagyok, hogy csökken a diverzitás már megint.

Annyira nem. Van egy csomo olyan PHP cucc, hogy OLAP kockakkal kell dolgozzon, es az majdnem kizarolag Windowsrol erheto el csak, a Linuxos MS SQL kliens (par eve meg) nem (volt) alkalmas ezek kezelesere sajnos. Ezen felul van egy jo kazal win-only tool, amihez igy relative konnyen lehet egy JSON/XML/SOAP API-t biztositani. Lattam mar sok ilyet, ha nincs C/C# tudas a cegben, ez a legkonnyebb ut.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ezt most vesszek meg, ha értem. Mi a baj a PHP-vel? Főleg a 7.4-gyel, ami egyáltalán nincs elavulva, meg a megjelenő 8.0-val? Nem hogy örülnének, hogy valaki még a szutyok nyílászárós rendszerükön használná. Nyilván eddig is linuxon, BSD-n volt érdemes használni, ez nem vitás, de így csak egyszerűen megszüntetni a támogatását egy ilyen modern és népszerű nyelvnek, az agyrém kategória. Ennyi erővel a webszervereket se támogassák, mert minek.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerintem játssz el úgy egy fél évet a C#/.NET Core combo-val (igen, megy linuxon is, mi több fejleszthetsz is rá, Pl. egy Visual Studio Code-dal), aztán utána visszatérünk erre a modern és népszerű nyelv dologra. Rég fejlesztettem PHP-re, de azért hírekből követem a nyelv fejlődését, és egy-egy mérföldkő után mindig az jut az eszembe, amikor anno még a szocializmusban a Trabant 6 voltos helyett 12 voltos akkumlátort kapott. :-)

Kösz, de inkább passzolom az MS technológiákat, még akkor is, ha mennek Linuxon. Azt értem, hogy a saját platformukon a saját szutykukat próbálják inkább tolni, ez valahol érthető, de kicsit túlzás, hogy ekkora nyelvet, mint a PHP nem támogatnak. Mert értem, hogy most a JS frameworkök meg a Rust, stb. a menő, aköré van hype építve, de azért a PHP még mindig van annyira népszerű, hogy nem lehet leírni. Trabanthoz hasonlítani szerintem elég durva.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Toroltem a hozzaszolas veget, mert nem tudom PC modon megfogalmazni, de az a lenyeg, hogy a PHP-hoz kepest a .NET sokkal nehezkesebb, sokkal tobb kod egy hello world-nel barmennyivel is bonyolultabb oldal osszerakasa. Nem konnyebb mondjuk nullarol C#/ASP.NET -et tanulni, mint mondjuk Java/Springet, cserebe az utobbi lenyegesen tobb szabadsagot ad a futtato platform tekinteteben. Felre ne ertsd, a C# onmagaban egy nagyon jo kis nyelv, de szemely szerint sokkal inkabb hasznalnam mikroszervizek, userland toolok, jatekok, barmi egyeb fejlesztesere, mint webalkalmazasok keszitesere. Nyilvan itt elsosorban a "standardizalt" okoszisztema teszi nehezkesse, nem maga a nyelv. A VB.NET nyelvkent es okoszisztemakent is picit konnyebben tanulhato, sokkal kifejezobbnek erzem, cserebe persze nem olyan elegans, mint a C#, de valahol kompromisszumokat kell kotni. ASP.NET szinten csak par peldat lattam ra, szerintem meltatlanul alulertekelt nyelv. 

Johetnek a kovek. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Egészen pontosan 0 különbség van a használt API-kban, ha C#-ban vagy ha VB.NET-ben írsz ASP.NET (Core) alkalmazást.

És a tapaszalat meg pont az, hogy amennyivel nehézkesebb, annyival megbízhatóbban tudsz haladni egy statikusan típusos nyelvben, szemben a PHP-vel. (3 éve ASP.NET Core-s microservicek írásával foglalkozok, előtte sok-sok évig PHP-ban ítam webalkalmazásokat. Kössz, nem sírom vissza.)

Megjegyzem, egyik kolléga, aki Pythonban írt mindenféle számolgatós dolgot, jutott ugyanerre a következtetésre, hogy hiába egyszerűbb az elején gyorsan haladni a Pythonnal, hosszú távon jobban járt volna karbantarthatóság és miegyéb szempontjából egy .NET-tel (Vagy Java-val).

Ez a passzolom a MS technológiákat dolog, úgy 20 éve még menõ volt, ma inkább ciki. A Rust pedig soha nem volt, és szerintem nem is igen lesz a PHP versenytársa. Viszont nem árt, ha az ember nem ragad be nyakig egy-egy nyelvbe, platformba, technológiába, és nem köt vérszerzõdést egyik programnyelvvel vagy platformmal sem.

20 évvel ezelőtt forradalmi tisztánlátás volt. Ma már bárkinek alap, aki nem szemellenzős. A Rust-ot csak példának írtam, mert most nagy a hájpja. Azzal egyetértek, hogy sose szabad leragadni egy nyelvnél, ha elavul, haladni kell a korral, nem szabad hozzá a végtelenségig ragaszkodni.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Nem. Csak vicceltem.

Najó: IMHO a CGI minden egyek query kiszolgálásához új processzt indít. Az azért eléggé költséges, nem? Ha egyszerű a lekérés, akkor a teljes kiszolgálással összemérhető, akár több is lehet a processzindítás/lezárás költsége.

A nehezen fejleszthető részből annyi igaz, hogy ha tényleg C, akkor annak a magasabb szintű nyelvekhez képest van egy 2-3-szoros lassító tényezője. Viszont legalább nem rejti 85 réteg el a fejlesztő elől azt, hogy mi történik valójában :-)

Ha az oldalak között állapot (session) vagy kommunikáció is van, akkor valami IPC mechanizmus is kell. Ez megint lassabb és komplexebb lesz, mint ha egyetlen szerver processznek a memória állapotában lenne minden oxigén eltárolva.

"IMHO a CGI minden egyek query kiszolgálásához új processzt indít. "
True

IMHO a php is alabol ezt teszi/ ezt tette.
Ha valami accelarator van akkor persze nem feltetlen..

Ahogy manapsag elnezem a webappok teljeseitmeny adatait, egy hatrannyal indulo CGI C nyerhet sebessegben,
es erroforras nem zabalasban.

De inkabb FastCGI -t  javasolnek, vagy webserver extension irasat ,
vagy from scratch service ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> vagy webserver extension irasat

Jó kis C-ben írt aszinkron IO-val, green threadekkel vagy korutinokkal megvalósított nyers template-eken alapuló weboldal. Meg tudnám közelíteni a processzor RAM sávszélességét :-) Néha álmodozom ilyenről, de eddig nem jött szembe a feladat, ahol szükség volna rá...

"IMHO a CGI minden egyek query kiszolgálásához új processzt indít. "
True

IMHO a php is alabol ezt teszi/ ezt tette.

Atlagos config: pre-forkolt apache processzek amiben be van mar toltve a PHP apache modul es arra var, hogy csinalhasson vegre valamit.

De a VB .NET-nek köze nincs már a 6.0-ás Visual Basichez. Az már csak egy pimpelt C#, maximum sötétben messziről nézve két liter whisky után hasonlít a két nyelv. :)

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Ejnye, kolléga!

A PHP-t már legalább 10 éve le kéne sajnálnod, mert bár még támogatott, de rég elavult™ technológia és vannak sokkal modernebb™, trendibb alternatívái, amikben nem kell annyi kódot írni és jóelőre átgondolni, hogy mit akarsz csinálni, elég csak egy kényelmes babzsákon agilisan pötyörészni az idealista menedzsered által feltervezett feladatot. A megspórolt munkát pedig majd sokszorosan megfizetik helyetted a felhasználók +1 CPU maggal, +8 GB memóriával és a villanyszámlában. Dehát az kit érdekel, sőt jót is tesz az innovációnak™ és a fejlődésnek™, amire ugye mindenképpen™ szükség™ van, amúgy is a fejlesztés drága™, a hardver olcsó™.

" A megspórolt munkát pedig majd sokszorosan megfizetik helyetted a felhasználók +1 CPU maggal, +8 GB memóriával és a villanyszámlában. "

Attól függ, mi az alternatíva. A PHP gyorsabb mint a python vagy a ruby, kb. hasonló a javascripthez, viszont jóval lassabb mint a java vagy a .NET.

Mondjuk ez még PHP 4.7, a 8.0 gyorsulhatott. De a PHP-t szerintem leginkább azért szeretik, mert olcsó hozzá a fejlesztõ, és egy tányér levesért kapsz hozzá szervert, plusz ott van egy rakás CMS és kész webshop, hogy lehetõleg az olcsó fejlesztõre se kelljen költeni.

A stílus miatt nyomtam egy plusz 1-et, de annyit súgnék, hogy a gyengén típusos nyelvek - amilyen a PHP is - egyáltalán nem annyira hatékonyak.

A statikusan típusos nyelvek esetén végrehajtható egy rakás optimalizálás, ami miatt közel natív sebességű program fordítható belőlük. Ilyen a .NET (C#), Java, illetve tudtommal a Rust is. És természetesen ilyen a C és a C++ is, sőt ott még Garbage Collector sem áll a fejlesztő útjába :-).

A dinamikusan típusos nyelvek esetén, amilyen a Python, Ruby, JavaScript, stb viszont ezt nem lehet megtenni. Lényegében az van, hogy a legtöbb esetben a metódushívások, mező elérések esetén nem lehet elkerülni a név szerinti map-ből keresgetést. Sajnos ennek elvi korlátja van, hiába tettek bele közel végtelen sok munkaórát a JavaScript engine-ek optimalizálásába, ez a hátrány soha nem dolgozható le. (Ha be van vezetve a típusosság, és azt következetesen betartják a fejlesztők, és azt ki tudja aknázni a JIT compiler az más, de a projektek nagyon kis része ilyen.)

Ja, és a PHP alatt is Garbage Collector van, tehát ebből a szempontból sem jobb, mint a Java, vagy a .NET.

Ebben az esetben tehát a babzsák a PHP fejlesztőknél van, az ő programjuk lesz az erőforráspazarló™ modern™ megoldás™.

Ettől még igaz lehet, hogy a Java, vagy .NET fejlesztők gyakran óriási bloat-tengert állítanak elő, ezzel nem akarok vitatkozni. De a hiba nem a nyelvben van, hanem abban amit az eszközzel létrehoztak.

Hogy anekdotikus érvelést is adjak: egyszer írtam egy kis Java+Jetty alapú mini-weboldalt, amiben egy mini webchat-et valósítottam meg, illetve egy képre tudott több felhasználó egyszerre rajzolni. A PHP fejlesztő ismerősöm csak kamillázott, hogy hogy tudtam ilyen gyorsra csinálni? Pedig nem is gondolkodtam optimalizáláson, csak éppenhogy összeütöttem egy példaprogramot.

Valójában a nyers PHP is lehetett volna hasonlóan gyors, csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét. És ez is minden nyelvre igaz.

És igen, hallottam, hogy a Facebook is PHP-ban íródott. Éppen ezért ők is vért hugyoztak, hogy az interpretert részben compiláltra cseréljék, és optimalizálják. Ez csak azt mutatja, hogy az eszköz adta 1-10-100x-os nagyságrendő lassulás még mindig ellensúlyozható azzal, ha maga a program jól van megírva és nincsen benne skálázódási probléma (amikor a tárolt adatok számával rosszul szorzódik a végrehajtási idő).

sőt ott még Garbage Collector sem áll a fejlesztő útjába

Azért hidd el, egy pár millió soros szerver app esetén már örülni fogsz, ha az "utadba áll"

A dinamikus típuskezelés sem azért fáj elsõ sorban mert hogy lassú, hanem mert az egy határozottan szárazabb, biztonságosabb érzés,
ha tudod hogy a függvényed product paramétere egy termék osztály és nem egy termék id, mert 3 éve egy külföldi kolléga aki anno fejlesztette
nem teljesen tartotta be a névkonvenciókat. Vagy nincs olyan, hogy 24 helyrõl osztállyal hívják, de a 25. helyrõl id-val. És az sem hülyeség, amikor a típusra kattintva el tudsz menni a definíciójához, és már látod is, hogy mibõl is áll az a nyomorult Product osztály. A legszebb persze az, amikor az ORM annotációkat generált az entitáshoz, hogy az intellisense tudja, hogy mibõl kell(ene) állnia az entitásnak. Ami szép, az szép...

csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét

Csak a helló világon túl elõbb-utóbb mindenhol összefúj a szél valamiféle frameworköt, hogy ne kelljen a kereket állandóan feltalálni. Ennek aztán sok elõnye van: a nagy frameworkök azért eléggé battle-tested cuccok, ami a Pityuka bété egyedi keretrendszerére nem biztos, hogy igaz. Másrészt, ha a Pityuka bétének kell egy újabb ember, az egyedi keretrendszerét sok-sok hónap alatt fogja csak betanulni az új polgár, és olyat szinte biztos, hogy nem fog találni a piacon, aki az egyedi keretrendszerét ismeri. Ez az egyik véglet. Középen van a PHP ahol minden fûcsomó mellett fejlsztenek egy frameworköt, és nyilván nem sok van aki mindet profi szinten ismeri, így vagy kisebb a felhozatal, vagy ismét csak te fizeted amíg az illetõ megtanulja az általad használtat. És van a .NET vagy a Java a fix framework-kel, ahol ha felveszel egy programozót akkor az a keretrendszert már tuti ismerni fogja, csak a te kódodat kell megtanulnia.
Ilyen apróbb különbségekbõl több havi fizu megspórolható, abból pedig sok-sok áramot lehet venni.

Azért eléggé leegyszerűsített ez a PHP vs .NET. Pontosabb lenne a PHP5.6 vs PHP7.x vs .NET vs .NET Core. 

A PHP7.x-ben a típusok kezelésének lehetősége sokban változott. Szerintem mindegyik nyelv közelít egy kicsit a másikhoz, a jó bevált dolgokat átemelik egyikből a másikban.

>> sőt ott még Garbage Collector sem áll a fejlesztő útjába

> Azért hidd el, egy pár millió soros szerver app esetén már örülni fogsz, ha az "utadba áll"

Félig vicc akart lenni :-). Normál alkalmazások esetén csakis segít a GC, imádom. Webes környezetben nem tudok olyat elképzelni, ahol útban lenne. Mondjuk úgy hallottam, hogy volt egy átmeneti időszak, amikor nagyon nagyok voltak a RAM méretek, de nem tudott párhuzamos működést a GC, és akkor probléma volt a stop-the-world működés. (Engem nem érintett, nem foglalkoztam ilyen méretű alkalmazásokkal, most meg már tudtommal sokat javult a helyzet.)

De fejlesztek néha statikus allokációval működő kiszámítható válaszidejű, illetve kiszámíthatóan soha nem leakelő dolgokat is C-ben, annak a területnek is megvan a szépsége. Ott útban volna a GC.

> csak akik mindenféle framework™-öket használnak, azok sosem ismerik meg az eszköz valódi nyers teljesítményét

> Csak a helló világon túl elõbb-utóbb mindenhol összefúj a szél valamiféle frameworköt, hogy ne kelljen a kereket állandóan feltalálni.

Ez is igaz, de az állításomat nem cáfolja. És biztosan vannak teljesítményben is jól teljesítő keretrendszerek is, a tipikus esetre általánosítottam, amikor egyetlen "Hello World!" oldal betöltéséhez egy teljes keretrendszer összes osztályát meg kell mozgatni, és valamiért 10-100x tovább tart, mint egy bare-metal megvalósítás.

feladathoz az eszközt.

ha egy 'hello world' oldalhoz valaki zend, symphony, laravel vagy akármi keretrendszert használ, az idióta.

ha egy ennél bonyolultabb feladathoz nem használ ilyesmit, az mazohista .)

de így sem fenékig tejfel az élet; pl a smarty eleinte borzasztóan nem állt kézre. a symphonyban most a twig nem áll kézre: nem hasonlít a smartyhoz és nem hasonlít a nyers phphez sem. A sima php html template meg ilyesztően hasonlít a 20 évvel ezelőtti -  ma már üldözendő - zsinór php cuccokhoz, egy kis html, egy kis php, megint egy kis html; egy bazi nagy katyvasz az egész. De legalább nosztalgikus érzésket kelt bennem :)

En mostanaban gondolkodtam, hogy valahogy kene egy kis PHP template alapu template motort irni, ugyanis bekapcsolt short_open_tags mellett a PHP-ban mukodik a <?= $foobar ?> jellegu megadas is, ami mar majdnem Smarty szintjere viszi a dolgot. Csak persze megint nincs idom semmire se. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Elsősorban referencia számolgatás van, a ciklikus hivatkozásokra van egy GC: https://www.php.net/manual/en/features.gc.collecting-cycles.php
Kikapcsolható, ha nagyon akarod, de egyébként csak akkor fut, ha már túl sok dolog [darabszámra] van a heapen, amiket refcountinggal nem sikerült felszámolni.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ami ugye a legnagyobb problema a nyelvvel, hogy request-response alapon mukodik, es ezt kikuszobolendo mindenfele dologgal kell korbe hackolni. Persze ezert is szeretik/hasznaljak sok helyen, mert barmelyik nem teljesen agyhalott tud benne kodot irni, mert a szamitogepekhez nem igazan kell erteni. Az allapot kerdese meg le van tolva a db-be, oszt amig a db birja szabadon lehet skalazni. nincsenek szalak, memoria-kezeles, allapotok, stb.

Hat ki mase? Erdekes Javaban is lehet HTTP protokollon HTML-t kiszolgalni. De attol meg nem inditunk uj processzt minden kereshez. A nyelv designek semmi koze a transport layerhez vagy a kimenet tartalmahoz (marmint PHPnal van koze, de errol nem az angolok tehetnek :D). Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme. De, hogy azota mi szol mellette?? Azon kivul, hogy eldobsz egy kovet es eltalalsz egy PHP fejlesztot meg, hogy felpattintasz egy wordpresszt es a vilag osszes problemajara megtalalod a megoldast a pluginek kozott. Szerintem meg Chuk Norris sem tudta megszamolni a plugineket pedig mar visszafele is elszamolt vegtelentol.

De attol meg nem inditunk uj processzt minden kereshez. 

Ezt nem tudom honnan vetted. Kb. mindenki Apache prefork + mod_php -t hasznal, igy nem indul minden egyes requestnel uj process.

Ami ugye a legnagyobb problema a nyelvvel, hogy request-response alapon mukodik

A nyelv designek semmi koze a transport layerhez vagy a kimenet tartalmahoz (marmint PHPnal van koze, de errol nem az angolok tehetnek :D). Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme.

Nem ertem mit akarsz mondani, hogy mi a konkret problemad... HTTP-n jon egy keres szerver atadja a szerencsetlen PHP-nak majd a visszakopott valaszt a szerver visszadja a kliensnek. Mi az a nagy nyelvi design hiba a mirol beszelsz? Mi az, hogy a nyelv request-response alapon mukodik? Az a problemad, hogy a response utan megy a levesbe minden?

Lattam mar kezdoket Spring Boot + Hibernate-el jatszadozni. Koklerek mindenhol vannak :)

Ha a WP javaban lenne megirva es jottmentek irnanak plugineket hozza, ugyanolyan szar lenne mint most.

Szerintem rosszul tudod. Nagy terhelésű helyeken inkább az fpm a preferált. Főleg, hogy ilyen oldalaknál az Apache helyett is gyakran nginx van, plusz az fpm működése sokkal jobban finomhangolható.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Szerintem rosszul tudod. 

De mit? Ha az Apache mod_php vs nginx-re gondolsz, a statisztikak szerint meg nem vette at az uralmat, de valoban nem sok kell neki. Atlag user telepit maganak egy LAMP-ot.

FPM eseten is alapbol dinamikusan vannak kezelve a processek, ha jol emlekszem alap configban amit a php szallit 10 process indul.

Nem, az konkretan hulyeseg volt. Ma mar apache moge is inkabb FPM-et raknak, csak hat a statisztikaban az is Apache-nak latszik, es olyan 2000 ota sulykolja mindenki, hogy a ServerSignature az Off legyen, vagy valami minimalis, az expose_php meg fixen off, emiatt persze nagyon torzul a statisztika, sok szervernel nem lehet megallapitani a mod_php jelenletet egyertelmuen.

A legjobb pelda erre, hogy a cPanel is suPHP-rol FPM-re valtott a tobb PHP verzio tamogatas erdekeben, noha a frontenden ugyanugy Apache fut.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

"nem indul minden egyes requestnel uj process" van valamifele ujrahasznositas. De pl megnezed az FPM configot talasz benne ileneket:

static - a fixed number (pm.max_children) of child processes

dynamic - the number of child processes are set dynamically based on the following directives. With this process management, there will be always at least 1 children.

Szoval lehet hangolgatni, meg jatszadozni vele. Ebben megkovetem magam, nem _feltetlen_ indul uj process. De van amikor igen, beallitas kerdese valoban.

"Az a problemad, hogy a response utan megy a levesbe minden?" Igen, hogy nincsenek shared resourcek requestek kozott. Ami jo buli amig mywebpage.php-t kell kiszolgalni shared hostingrol, de amint bonyolultabb a domain lehet minden requestnel ORM-et epiteni, meg classokat loadolni (a leglassabb komponenserol a szamitogepnek), (syntaxist ellenorizni, bytekodot forditani,) db kapcsolatokat epitgetni, meg fetchelni a db-bol mindent, stb.

Aztan mindenfele hackolassal/modszerrel persze ezeket meg lehet kerulni, de azok mar mind a hibas koncepcio hozomanyai.

Mennyivel egyszerubb, amikor megvannak a db kapcsolatok, fel van epitve az ORM, be van toltve a diskrol minden ami az alkalmazasnak kell, bejon egy keres, ha kell indiunk egy _szalat_ (nem processt!) es csak ugy siman kiszolgaljuk a kerest.

Es akkor eloszottt tranzakciokrol, utemezett feladat vegrehajtasrol, tobbszalusitasrol, non blocking io, async, event driven dolgokrol meg nem is beszeltunk (igen vannak megoldasok, de mikor kinyitoda motorhaztetot vegul kulon processeket fogsz talani szalak helyett).

 

"Koklerek mindenhol vannak" igen, es nem allitotam az ellenkezojet, es a WP-t is mint elonyt hoztam fel :D

"Az a problemad, hogy a response utan megy a levesbe minden?" Igen, hogy nincsenek shared resourcek requestek kozott. Ami jo buli amig mywebpage.php-t kell kiszolgalni shared hostingrol, de amint bonyolultabb a domain lehet minden requestnel ORM-et epiteni, meg classokat loadolni (a leglassabb komponenserol a szamitogepnek), (syntaxist ellenorizni, bytekodot forditani,) db kapcsolatokat epitgetni, meg fetchelni a db-bol mindent, stb.

Mennyivel egyszerubb, amikor megvannak a db kapcsolatok, fel van epitve az ORM, be van toltve a diskrol minden ami az alkalmazasnak kell, bejon egy keres, ha kell indiunk egy _szalat_ (nem processt!) es csak ugy siman kiszolgaljuk a kerest.

Abszolut igazad van, szebb es jobb, de ennek ugye ara van. Illetve azt is gondolom, hogy van ennek sok elonye is, peldaul az, hogy nem hasznaljak esz nelkul. Az nem veletlen, hogy a joomla, wp es baratai PHP-ban irodtak.

Es felre ertes ne essen en azt sem vitatom, hogy amikor letrejott a PHP volt valami ertelme. De, hogy azota mi szol mellette??

Ez megint a szerszam a feladathoz esete. Arra kell hasznalni amire valo. Ha kvantifikalhato elonyt hoz valami (akarmilyen szinten technikai, HR, penzugy, license, support, lifespan ...), akkor azt a technologiat kell hasznalni. Sok szemszogbol lehet megvizsgalni a dolgot. Lehet peldaul azt mondani, hogy az esetek tobbsegeben nem zabal annyit. Olcsobb olyan fejelsztesekhez, ahol tudod, hogy a project 4 ev mulva megy a kukaba.

Ha csak annyi az elony, hogy XY jobban erzi magat, mert ugy "szep" az keves. 

true, ezert nem mindegy az ember melyik platformot valasztja megtanulasra. Es nyilvan ha az a PHP, akkor olyan projekten fog dolgozni, ami a PHP adottsagaira van optimalizalva, olyan emberekkel fog egyutt dolgozni, akik szinten ezeket az adottsagokat kedvelik/ertik, olyan lesz a fizetese, es ennek megfeleloen alakul a piaci versenyhelyzete. Es persze van ertelmes engineering PHP korul is, sot a nagy PHP sikersztorik is vannak (mondjuk azok nem is vanilla PHPt hasznalnak egyebkent de mindegy), de a nagy atlagban.

En pl PHProl valtottam par ev utan tortenetesen Javara. Es a hol hostuljuk kerdes atalkult a hany gepen fusson-ra (es nem a hitvany teljesitmeny miatt, hanem a magas req/sec miatt), ami rengeteg fejlodesre adott lehetoseget. Vagy pl rogton akkora projekteken talaltam magam, hogy minden nap mast kellett csinalni, es megszunt a (uj projekt, regisztracio, blog, forum, hirek, cms admin) loop. Sajnos a 20adik regisztracios form fejlesztesbol mar nem tudtam annyit tanulni mint szerettem volna.

Valoban. Szerintem is a PHP-t ez a hozzalas lengi korul. PHP vs Java dologba azert nem erdemes belemenni szerintem, mert a PHP egy script nyelv a Java meg egy oriasi software platform, mas kategoria.

Egy bank valoszinuleg nem fog hasznalni mondjuk PHP-t a banki feluletehez. Ha valamit hosszu tavon fenn kell tartani, mission critical akkor ott megfizetik a tervezest, a tudast es a jol elvegzett munkat.

Van aki marad a PHP-nal es kiszolgalja azt a reteget, nincs azzal semmi baj.

Ezekrol hallottam, nem most vitazok eloszor ebben a temaban :D

A class reloadingrol ennyit

  • In order to preload files, you need to write a custom PHP script
  • Changes made to preloaded files won't have any effect, until the server is restarted

 "Strict type mode" gyakorlatilag eltorli a visszafele kompatibilitast, mert ahhoz mindent az elejetol ugy is kell megirni vagy futas kozben kapcsolgatni, raadasul runtime derulnek ki a turpiszsagok (fixme)

"JIT" experimental

En hiszem, hogy a PHP nagyon jo volt valamikor, meg azt is elhiszem, hogy nagyon jo lesz valamikor.

>  Az allapot kerdese meg le van tolva a db-be, oszt amig a db birja szabadon lehet skalazni. nincsenek szalak, memoria-kezeles, allapotok, stb.

Ugye nem mostanaban kodoltal PHP-ben? Erdemes lenne utananezni, a shared resource-ok problemajat az APCu megoldja (nem annyira nativ, mint egy SHM, de az ORM-es szornyetegektol, amit emlitettel, fenyevekre van), vannak benne szalak (az persze mas kerdes, hogy webes kornyezetben mennyi ertelme van hasznalni). A memoria kezeles kb az egyetlen, amivel nehezebb vitatkozni, minosithetetlen fos sajnos az a resze a runtime-nak. 

Nem mondom, hogy a PHP hibatlan, de nem teljesen ertunk egyet a hibak listajaban. 

> amig a db birja szabadon lehet skalazni

Ez kb minden nyelven irt alkalmazasrol elmondhato, es en ezt nem latom feltetlenul rossznak. Nagyon sok esetben pont az a problmea, hogy az alkalmazasfejlesztok nem kepesek felkeszulni a horizontalis skalazasra, feltve orizgetnek mindent a memoriaban, aztan ha a load balancer miatt a user sessionje hirtelen masik gepre kerul (barmiert), akkor csodalkoznak, hogy nem allapot, hanem konkretan lofasz sincs rola, de jott egy ervenyes session. Az a legjobb, ha minden DB-ben van, abbol kevesebb baj szarmazik, amit raadasul nem a fejleszto dolga kezelni.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Kicsit utannaneztem, es talaltam is egy ticketet magatol a szerzotol:

krakjoe commented on 15 Feb 2019

Hi all,

I'm aware that this is going to annoy some people, so apologies before we begin ...

I do not intend to maintain pthreads anymore, nor encourage it's maintenance: It is, in my opinion, broken by design, and fixing it, is simply not worth it.

 

Sok joval kecsgtet, foleg a broken by design resz :) https://github.com/krakjoe/pthreads/issues/929 Na ennyit a PHProl meg a tobbszalusagrol. A tobbi szar extension meg kb mindd processzekkel operal.

 

"de nem teljesen ertunk egyet a hibak listajaban" ami nem is baj. Szerintem egy hibaja van a PHPnak, hogy letezik meg 2020ban.

 

"abbol kevesebb baj szarmazik" nem tudom biztos hallottal mar elosztott cachekrol, meg hasonlo finomsagokrol, amikkel nem kell minden keressel megkuldeni az adatbazist. Amit emlitesz az a tipikus hozzaallas a PHPn nevelkedett szakertokhoz. Inkabb hagyd az egeszet, te ne foglalkozz semmivel, mert abbol csak a baj lesz. Szoval megbocsass, de jol skalazodo stateless alkalmazast mindenki tud fejleszteni (mar ameddig a db birja, aztan hivjak a kulsos mysql szakertot, hogy csinaljon valamit a db-vel, mert megdoglik az egesz cucc. lattam ilyen nem egyszer meg ketszer).

.NET (CLR) és Java (JVM) ugyanúgy JIT-telt, mint bármilyen dinamikusan típusos nyelv. A nyelv amiből a bytecode fordult lehet statikusan típusos, de az azt futtató runtime dinamikusabb, lásd pl. InvokeDynamic, illetve A First Taste of InvokeDynamic.

Ezzel párhuzamba állítva a mai JS runtimeok is JIT-telik a kódot, valamint típusinformációkat rendelnek a dinamikus adatstruktúrákhoz, lásd pl. Shapes and Inline Caches, illetve The story of a V8 performance cliff in React.

A bytekód is statikusan típusos, legalábbis C# alatt biztosan.

Vegyünk egy ilyen kódot:

 int i = 0;
 while(i<10)            
     i++;

Ebből ez az IL kód lesz:

IL_0000: ldc.i4.0           // Push 0 of type int32 onto the stack as int32.
IL_0001: stloc.0            // Pop a value from stack into local variable 0
IL_0002: br.s IL_0008   // Brach to target

IL_0004: ldloc.0            // Load local variable 0 onto stack.
IL_0005: ldc.i4.1           // Push 1 onto the stack as int32.
IL_0006: add                // Add two values, returning a new value
IL_0007: stloc.0           // Pop a value from stack into local variable 0

IL_0008: ldloc.0            // Load local variable 0 onto stack.
IL_0009: ldc.i4.s 10      // Push 10 onto the stack as int32, short form.
IL_000b: blt.s IL_0004  // Branch to target if less than, short form.

IL_000d: ret           // Return from method, possibly with a value.

Na, ez így nem túl szép, viszont elég típusos.

Viszot a belőle fordított assembly:

              xor         eax,eax                  
loop0:    inc          eax                  
              cmp       eax,0Ah  
              jl            loop0
              ret 

 

Más kérdés hogy a C#-ban lehet olyasmit csinálni ami nem ilyen szép, de bizony a dolog elég statikusan típusos.

Ez most melle ment hajbazer. :(

Egyreszt azert vannak framework-ok PHP-ra is (Zend), hogy ne kelljen ugyanazt a komponenst (authentikacio, authorizacio, perzisztencia, stb.) ujra es ujra feltalalni vagy ahogy te irod atgondolni. Atgondolni ugysem fogod, mert hataridod van es a feladatra fogsz ezek helyett koncentralni ami egy csomo hibalehetoseget es kevesse hatekony kodot fog eredmenyezni.

Masreszrol a Java/.NET-hez kepest a PHP kanyarban sincs ha performanciarol van szo.

Nincsen baja az MS-nek a PHP-val.

A 7.4-et támogatni is fogják EOL-ig.

Itt arról van szó, hogy az MS nem fog külön erőforrásokat fektetni abba, hogy a PHP Windows-os verziójába fejlesszen. Attól még lesz a PHP-nak Windows-os kiadása, csak az MS nem ad hozzá támogatást, nem fogják javítani a Windows specifikus dolgokat. Ezt mind rábízzák teljesen a közösségre, akik szeretnék még Windows-on használni a PHP-t.

Nincs itt most különösen látnivaló.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

> Nincsen baja az MS-nek a PHP-val.

vs

> lesz a PHP-nak Windows-os kiadása, csak az MS nem ad hozzá támogatást

Itt azert erzek nemi ellentmondast. Eleve, az IIS is tartalmazott tobbe-kevesbe nativ PHP supportot egy ideje, azzal, hogy visszaleptetik a nyelv tamogatasat, siman bekerult a lehetosegek korebe az, hogy megint lehet majd hakkolni mint regen, hogy mukodjon IIS-en is a PHP-s webalkalmazas.

Raadasul a Microsoftnak vannak a legkepzettebb Windows mernokei, a Microsoft neve a contributorok/tamogatok kozott rengeteget jelentene. 

En egyebkent komolyan nem ertem, egyfelol a MS probal nyitni az opensource vilag fele, de masfelol meg ilyen lepeseket foganatosit. Nagyon ambivalens az uj OSS politikajuk, nem latom at.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szerkesztve: 2020. 07. 12., v – 21:56

Ez csak annyit jelent, hogy az IIS (Microsoft Support) nem fog hivatalos támogatást nyújtani rá. 

Ettől függetlenül természetesen továbbra is használható lesz.

Valószínűleg annyira marginális volt a fizető ügyfelek száma, hogy nincs értelme supportálni. 

WSL alatt ha kell ,megkapod. :) Igy a support ratolodott a kozossegre, az MS oldalon meg felszabadult nemi humán kapacitás amit gondolom a WSL alá toltak.

---

Szijarto Zoltan

Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.

Szerkesztve: 2020. 07. 14., k – 23:01

Ez is biztos ilyen "Ez már a KDE5" érzés, de mindig öröm látni, hogy a PHP/Javascript-s postok alatt jönnek a C#/Java huszárok, akik aztán jól megmondják, mennyire szar a PHP/Javascript. Persze a legtöbb C#/Java kispista életében nem nyúlt hozzá egyik scriptnyelvhez sem, max csak bottal bökdöste 5 percig. Aztán meg csak kamillázik, amikor egy Angular/Ngrx fejlesztő többet keres, mint ő Java-val. (Azt hiszed, hogy nem, pedig de. :D) PHP-vel olyan nagy rendelkezésre állású rendszereket is kiszolgálnak, amivel itt a legtöbb ki-ha-én-nem C#-os sosem fog dolgozni.

Láttam már sok rendszer kódját, láttam és dolgoztam sok szoftverfejlesztővel. Volt már dolgom olyan szarul megírt Java kóddal is, amit már csak a köré épített vas és infrastruktúra tartott egyben. És minden releasekor imára kulcsolhattad a kezed, hogy a deploy ne szálljon el az alkalmazásszserveren. A PHP-ben írt Joomla/Wordpress ahhoz képest egy csodálatosan megírt rendszer volt.

Gányolni minden nyelvben lehet. Minden programnyelvet/scriptet arra kell használni, amire való. Azért ettől függetlenül remélem, hogy azok, akik itt annyira használhatatlannak tartják a PHP-t, azok az egyoldalas portfóliójukat/honlapjukat is Java-ban írják meg, JSF-fel! Vagy annyira okosak, hogy írnak hozzá saját scriptnyelvet... ;) :D

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Igazabol attol fugg, mire optimalizalsz. Ha a fejlesztesi koltsegre, a PHP eleg jol all. Ha arra, hogy egyetlen shared hosting 1000 alacsony latogatottsagu weboldalt ki tudjon szolgalni, arra megint eleg jo (ugyanez Java/C# alapon megenne a memoriat mielott az elso keres beerkezik, mert mindig fut). A Facebook C++-ra fordito hackjevel magabol a nyelvbol (es nem az interpreterbol) sokkal tobbet ki lehet hozni ezen tul is, szoval nagyobb forgalmu oldalakra is jo lehet. Ahol a DB limital, ott meg mindegy mi van az oldal alatt, akar lehet PHP is, ahhoz konnyebb embert talalni (es elvileg olcsobb is). A nyelv amugy alkalmas lenne arra is, hogy a webservert kivaltsa, es tovabb fusson a egy-egy keres kiszolgalasa utan is. Bar nem igy hasznaljak (biztos van ra okuk). Meg beepitett webserveruk is van (php -S 0.0.0.0:8080 -t www/ parancs elinditja, www konyvtarral, mint roottal, 8080-as porton).

A strange game. The only winning move is not to play. How about a nice game of chess?

Igen, ha ezekre a parameterekre optimalizalsz, akkor valoban van jobb. Vagy ha mar annyi penzed van, mint a Facebooknak, es egy csomo legacy kodod van, akkor a Hiphop kifejlesztese meg lehet megoldas.

A strange game. The only winning move is not to play. How about a nice game of chess?

Pontosan!

Az a PHP utálat, ami folyik az abból fakad, hogy aki terjeszti a hülyeséget az talán életében egyszer PHP-zott, de akkor is csak maximum 5-ös verzióval, de jobban valószínű, hogy korábbi verziót látott. Azóta a PHP nagyon sokat fejlődött, minden téren.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Konkrétan 1000%-kokban mérik a gyorsulását az 5-tös (!) verzió óta. Most épp nem találom a forrást, de a Facebook hop-hop-ját is már kenterbe veri a 7.0 out of the box. A JIT-elt 8-cas pedig még ki sincs próbálva jóformán.

És itt még csak szimplán a performancia kérdést feszegetjük, a szintaxisról még szó sincs. Simán működik még a PHP a maga kategóriájában, 2020-ban is.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

2020-ban a szoftverfejlesztés egyik legnagyobb problémája, - a bőség zavarában - hogy nagyon nagy százalékban, inkompetens emberek hoznak döntéseket arról, hogy milyen infrastruktúrát válasszanak egy rendszer üzemeltetéséhez. Ilyen és ehhez hasonló hozzászólások, a rendszer ismerete nélkül is jönnek-mennek. :)) Ha van pénz, akkor szórjuk is rendesen.

Ilyenekből szokott az lenni, hogy lőjjük ágyúval verébre vagy vice-versa:
 - könyvelőszoftver 50 fős személyzetnek? --> Naná, hogy Angular, a RESTapi backendjét pedig megírjuk Java-ban. Swagger sem kell, megírjuk nulláról. A vas majd elhajtja valahogy, ha szar lesz a kód, veszünk még bele RAM-ot. Ha nem vagyunk képesek jól kezelni a logot, veszünk tárhelyet...
 - 1500 darabszámú terméknek webshop, magyar piacra ~10 user / perc  terheléssel --> Persze, hogy Magento! :D Tökéletes választás lesz. Bár nincs a fejlesztőcégnél senki, aki értene egyáltalán a cache-lés kezeléséhez, de nyomjuk csak! Majd lekezeli a redis.
 - Portfólió a fotósnak a Facebook profil mellé? --> statikus html, a db-vel meg majd jQuery tartja a kapcsolatot ajax-szal. Mindezt egy windows szerveren, ssl kapcsolat nélkül, mer' minek az. Pistike megcsinálja.

Áh, hagyjuk.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Sokkal tovabb tart megtanulni egy nyelvet/keretrendszert, mint letolteni es telepiteni a hozza szukseges dolgokat. Szoval az, hogy a cegnel a fejlesztok mihez ertenek (es mit hajlandoak megtanulni) egy komoly erv/limitacio, amikor a projecthez eszkozt kell valasztani.

A strange game. The only winning move is not to play. How about a nice game of chess?

Szerintem a kolleganak inkabb a felelossegvallalassal van gondja. Az ilyen elbaszasokkal nem az a gond, hogy nem latjak elore, hanem az, hogy nem tudnak vele mit kezdeni ha elojonnek.

Igy elobb-utobb masnal kotnek ki es ilyenkor az ugyfel a "kezelest" varja el es nem a teljes re-design-t.

2020-ban a szoftverfejlesztés egyik legnagyobb problémája, - a bőség zavarában - hogy nagyon nagy százalékban, inkompetens emberek hoznak döntéseket arról, hogy milyen infrastruktúrát válasszanak egy rendszer üzemeltetéséhez. Ilyen és ehhez hasonló hozzászólások, a rendszer ismerete nélkül is jönnek-mennek. :)) Ha van pénz, akkor szórjuk is rendesen.

En a clean-code huszarokat es a gold platereket nem szeretem. Az egyik az ajanlasokat szabalykent alkalmazza a masik meg soha nem lesz kesz, mert eppen onmegvalosit. Jelentektelen, merhetetlen dolgokon megy a vitatkozas.

Pistike megcsinálja.

Ez nem neked szol, de altalanos hozzallas, hogy Pistiket mindenki utalja, pedig mindenki volt mar Pistike egy idoben. A PHP korul meg sok Pistike van, PistikeHelpsPistike, ezert szar az egesz PHP.

Persze értem én. Pontosan ezért hígul minden szakma először ott, ahol a legegyszerűbb bekapcsolódni. A legveszélyesebb ma már nem a PHP Pistike, hanem a Javascript Janika, aki a böngésző DevTool-jában beírt

console.log('Hello world')

után, már rögtön backendet írna nodejs-ben, mert ő szoftverfejlesztő lett.

Illetve most feltörekvőben van a Python Péterke is (akkor már maradjunk a neveknél :D) mert a raspin ugye ezzel kezdenek már a kisiskolások. Ami amúgy teljesen rendben is van.

Mindenki volt egyszer kicsiítőképzős, szoftverfejelsztőcske. Csak nem mind1, hogy ezt 10+ év tapasztalatával mondhatja el magáról, vagy 13 évesen, amikor az első programját megírta.

Szóval a "ezert szar az egesz PHP."-vel nem értek egyet, mert nem a nyelv hibája mindez.

Illetve, ha engem kérdezel, egy clean-code mániás még mindig jobb, mint az, aki szarik az egészre magasról. Persze ettől még mindent túlzásba lehet vinni.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Szóval a "ezert szar az egesz PHP."-vel nem értek egyet, mert nem a nyelv hibája mindez.

Ezzel en sem ertek egyet, csak ironia volt.

Illetve, ha engem kérdezel, egy clean-code mániás még mindig jobb, mint az, aki szarik az egészre magasról. Persze ettől még mindent túlzásba lehet vinni.

Pontosan! Egy jo fejleszto tudja amikor valami eleg jo.

A mai igények hatékony kielégítésére vannak jobb alternatívák, Windows világán túl is - ez az állítás.

Egyetertek mindenben s7stM kollegaval. Ezen felul erdemes mindent vizsgalni (szakmai, HR es penzugy stb...). Ha a teljes kepet nezed, nem ilyen fekete-feher a dolog. Igy ezen is lehetne vitazni napokig (Mercedes vagy BMW vagy ...)

A hasznalo eleri a celjat vele, ez a lenyeg! Mindenki a sajat maga szempontjabol a legegyszerubb utat probalja valasztani... Mindenhol megy a takolas, keves helyen van meg a penz arra, hogy spontan magomles kovetkezzen be egy code review soran.