na php.net ukazał się news:

http://www.php.net/archive/2014.php#id2014-05-27-1

i nie wiem czy dobrze zrozumiałem ale chłopaki z "PHP teamu" myślą nad tym aby PHP był kompilowany?
co myslicie na ten temat? za ile czasu możemy się spodziewać kompilowanego PHP?
czy będzie to prawdziwa rewolucja?

Jeśli to wypali, to wiele rzeczy które muszą być przepisywane do innych języków pozostaną w PHP, co jest bardzo dobrym rozwiązaniem chociażby ze względów finansowych.

Jednak to PHPTeam i "społeczność", więc na 99,9% znajdzie się grupa debili którzy będą na nie, wymyślą jakieś bzdury o tradycji i bezsensownej wyglądającej strukturze kompilowania i pomysł upadnie.

Społeczność PHP jest podzielona obecnie na dwa fronty: pierwszy chce zmian w języku tak aby był on rzeczywiście porównywalny w innymi druga natomiast za wszelką cenę chce pozostawić PHP takim jakim jest: maksymalnie uproszczonym ze wsteczną kompatybilnością.

Do tej pory wygrywała druga frakcja, dlatego mieliśmy niewielką ewolucją z wersji na wersję teraz po ogłoszeniu przez facebooka "nowego" języka, do głosu doszła doszła ta pierwsza którą odważnie mówi co im się w PHP nie podoba i czym powinien ten język być.


Osobiście jestem w tej pierwszej frakcji i uważam że jeśli język się zmieni, niekoniecznie musi być być to kopia Hacka, to czeka go powolna śmierć ( co nie znaczy że i za 5-8 lat nikt w nim nie będzie programował ), dlatego bardzo kibicuje "reformatorom" i czekam na ruch taki sam jaki wykonano w Pythonie. Co Pythonowi wyszło na dobre.

O samym PHPNG było jakiś czas temu na http://www.phpclasses.org/blog/

Ostatnio, na tym forum wywiązała się burzliwa(?) dyskucja na temat 'HHVM',
nad plusami i minusami, sensie istnienia itp.
W tamtym momencie pomyślałem, że skoro takie twory powstają, to "chłopaki od PHP"
prędzej czy później wezmą to pod uwagę i zaimplementują coś takiego w silniku PHP,
pomyślałem nawet że HHVM w bliżej nieokreślonej przyszłości stanie się integralną częścią silnika PHP.
Jak widać PHPTeam, na szczęście, cały czas myśli nad rozwojem, miejmy nadzieje, że nie spełnią się wasze obawy
dotyczące "upadku pomysłu".

Jak już chyba kiedyś wspomniałem, Zephir mógłby być rozwiązaniem.
Jest od razu tłumaczony do C, który z koleji jest kompliowany i szybki. Zresztą ma ładny syntax, podobny do PHP, statyczne typowanie, czego chcieć więcej? Nawet trwają prace nad kompilatorem JIT

@edit: No ale to oczywiście nie przjedzie, mała popularność, no i "to nie PHP".

Trzeba ten język w końcu zreformować i porzucić kompatybilność wsteczną, bo to się ciągnie i zawadza jak kula u nogi. I zlikwidować mnóstwo przestarzałych, szkodliwych bubli.

Popieram. A zacząć należy od wywalenia tego wstrętnego $ sprzed zmiennych. Kto to wogóle wymyślił?!
Tylko pomyślmy, jeśli wywalić kompatybilność wsteczną to będzie z tym problem, bo blokuje nam to... na przykład Wordpress. Wordpress ma obecnie 30 000 wtycze. Masa ludzi kupuje serwery współdzielone i instaluje na nich WP, ponieważ chcą szybko i w prosty sposób "stworzyć stronkę". I z tego względu hostingodawcy nie będą chciały przerzucać się na "rewolucyjną" wersję PHP, która nie będzie kompatybilna z WP, lub innymi CMS-ami. Jak żyć?

Wspieranie kilku wersji php na jednym serwerze nie jest problemem, więc da się to przeskoczyć.

Składnia miała być z założenia prosta i czytelna:

[PHP] pobierz, plaintext 
$c = 'foo';
print_r("show c: $c");
[PHP] pobierz, plaintext 

Takie coś jest prostsze do odczytania niż:

[PHP] pobierz, plaintext 
str c = 'foo';
print_r("show c:%s", c);
[PHP] pobierz, plaintext 

Początkujący wymiatacz kodu gubiłby się w tym co to jest "%s"

Wywalenie "$" nie przejdzie. Poza tym zawsze możesz to zgłosić na stronie php.net
Brak kompatybilności dla WP, to byłoby małe piwo.

że z tym dolarem trzeba coś zrobić to się akurat zgodzę, proponuję zacząć od wprowadzenia go we wszystkich innych językach

ale do rzeczy, takie rozwiązanie byłoby zdecydowanie najlepsze. Niema problemu z serwerami współdzielonymi(nie muszą instalować dodatkowego oprogramowania), a do tego gdyby udało się zrobić do wyboru "kompilacje w locie" lub "wrzucenie binarki" to by była całkiem bajka

A według mnie akurat kompilowanie kodu nie ma większego sensu.
Jedną z największych zalet PHP jest to, że mogę podmienić jeden plik "w locie" bez ruszania reszty systemu. Mogę nawet na komórce zalogować się do shella i coś na szybko zmienić. Przy kompilowaniu kodu już tak łatwo nie będzie. Trzeba coś zmienić, potem przekompilować otrzymiując inny plik, i dopiero jego wrzucić na serwer. A jeśli to jest cały projekt kompilowany, to się zaraz okaże, że wrzucanie pliku potrwa kilka minut i przez ten czas cały serwer leży.
Natomiast jeśli chodzi o szybkość działania - no cóż, może to miało znaczenie parę lat temu, ale obecnie, kiedy dedyka można mieć za kilkadziesiąt zł/miesiąc (o ile sami potrafimy nim zarządzać) to akurat chyba nie ma znaczenia.

Co do dolara w zmiennych - na początku, kiedy przechodziłem z C++ i Delphi na PHP też się zastanawiałem, po co on komu potrzebny, ale z perspektywy czasu jestem zdecydowania za.

jedyne, co mnie w php denerwuje, to jego niekonsekwencja. czemu jest strpos(), ale już str_replace() ? czemu w strpos() podmiot szukania jest na początku, a w str_replace na końcu? Tyle, że teraz zamiana tego już nie jest prostem tematem bez tworzenia czegoś załkowicie nowego, bez porzucenia kompatybilności wstecznej. Ale skoro już miała by być ona porzucana, to może od razu zrobić obiect php i w ogóle porzucić w nim strukturalne programowanie? Chociaż niekiedy do zrobienia drobnej pierdółki wygodniej i szybciej jest jestnak napisać coś strukturalnie.

Napisz mi chociaż prostą aplikację w php opartą o sockety która nie zarżnie zasobów choćby przy ruchu do 5k UU. Jeśli uzyskasz wydajność zbliżoną do C, to z chęcią odkupię od Ciebie ten kod.
Poza tym pomysł z kompilowaniem nie oznacza że to Ty będziesz coś kompilował ;)

No i chyba mamy tutaj mała symulacje tego co opisane zostało w postach powyżej:
jedni chcą zmian, inni chcą pozostać przy starych rozwiązaniach,
jedni chcą zmienić to, inni co innego.
Prawda jest taka, że gdy zmiany (gruntowne takie jak kompilacja) zostaną wprowadzone to ludzie ponarzekają, ponarzekają
i się przyzwyczają, za pare lat nawet nie będą pamiętać, że kiedyś to się tak pisało.
Język powinien iść do przodu. Na początku wszyscy albo większość jest niechętna nowym rozwiązaniom ale myśle, że z czasem docenią to.

Nie wiem jak to wewnętrznie wygląda ale IMO dobrym pomysłem mogło by być podzielenie tego na grupy korzystając z namespace.

use PHP\String;
use PHP\DB\Oracle;

coś w ten deseń. Teraz żeby zrobić porządki trzeba by wszędzie używać np \strpos()

No patrzcie. Od dwóch tygodni noszę się z zamiarem otwarcia tu dyskusji na temat "kompilowanie kodu PHP w przyszłych jego wersjach - fantazja, czy realna możliwość", a tu mnie sami twórcy wyprzedzili.

Jeśli postanowią iść tą drogą, jestem całym sercem za nimi. Smutną prawdą jest bowiem to, iż mój ulubiony język programowania cierpi na poważne niedostatki, jeśli chodzi o prędkość działania. Najlepszym tego dowodem jest ogromna popularność wszelkiego rodzaju narzędzi wspomagających Słonika typu APC czy eAccelerator. W małych i średniej wielkości projektach wydajność nie jest żadnym problemem - skrypty nadal wykonują się w ułamkach sekund, a skryptowość kodu jest zaletą i bardzo ułatwia zmiany. Jeśli jednak dobijemy do pewnej liczby użytkowników, serwer zaczyna się dławić. A tymczasem identyczne apki postawione na ASP.net lub Javie nadal pracują bez specjalnej spiny.

Administratorzy i właściciele hostingów z pewnością będą wdzięczni, bo chociaż nowa generacja języka na pewno nie będzie łatwa do wdrożenia, to w ostateczności i tak się zwróci (niższe obciążenie serwerów === większy zysk przy tym samym sprzęcie); Jeśli kompilowany PHP zbliży się wydajnością do ASP.net, to będzie bajecznie. Bez tego - PHP nie umrze szybko, ale poza granicę średnich stron i aplikacji dla małych i średnich (głównie małych) firm i odbiorców, nigdy nie wyjdzie.

Trzymam kciuki, ale nie ma się co emocjonować. Osobiście uważam, że jeśli dojdą do porozumienia i powiedzą "tak", to pierwsze wersje nowego PHP ukażą się najwcześniej za rok.

a tak swoją drogą to taka pseudo kompilacja została już wprowadzona w 5.5 za sprawą natywnie dodanego Zend OPcache.

Co prawa nie jest to kompilacja w pełnym tego słowa znaczeniu(trochę taka kompilacja w locie o której pisałem wcześniej) ale skok wydajnościowy według testów jest całkiem niczego sobie

Nie rozumiem dlaczego piszecie o kompilowaniu plików, przecież jest napisane, że chodzi o kompilacje JIT. Od strony użytkownika nie powinno się nic zmienić wrzucasz plik ze skryptem na serwer i otwierasz w przeglądarce.
Porównywanie HHVM czy Hacka do Zephira jest co najmniej nie na miejscu. Zupełnie różne od siebie rozwiązania z innymi docelowymi zastosowaniami.
Problem uporządkowania funkcji jest stary. Kiedy pojawiły się przestrzenie nazw była wielka nadzieja na poprawę. Przestrzenie nazw istnieją w tym języku już parę lat i jakoś nic się nie zmienia.
Dolara można uczynić znakiem dozwolonym na początku nazwy zmiennej i po problemie. Bardziej od dolara przeszkadza mi słowo kluczowe function na każdym kroku.

A skoro już jesteśmy przy PHP i temat jest w miarę gorący... Ktoś wie co się stało z polską wersją http://www.php.net/docs.php ? Jak szukam czegoś w google, następuje przekierowanie na wersje PL lecz takowa nie istnieje, tak samo jest z odnośnikami na forum przy kolorowaniu składni.

Poprawiłeś humor mi, jak i teamowi z którym pracuję na cały dzień, poproszę o więcej złotych myśli .

Jeśli Twoją 'stronkę' odwiedza 100 osób dziennie, a w HP masz 5 osób online to łał, możesz sobie pozwolić na wygadywanie takich bzdur, jednakże gdy optymalizacja i wydajność technologii przelicza się na tysiące złotych oszczędności wierz mi - śpiewka jest inna.

Nikt nie chciał tłumaczyć ;) Brak wsparcia ?

PHP kompilowalny?
Nie raz jak potrzebowałem na szybko mały programik to kompilowałem php.
Kompilator:
http://www.bambalam.se/bamcompile/

http://pl.wikipedia.org/wiki/JIT_(informatyka)

A to wszystko pewnie po tym jak zobaczyli Facebookowego Hacka - http://hacklang.org/

Ciekawe co z tego będzie. Mnie się to bardzo podoba. Na pewno też jest odpowiednio napisane - bo jąderko PHP to... lepiej nie będę tego komentować (ani podejścia tych, którzy rozwijali ten język).

Jeśli uważasz, że faktycznie taniej jest zapłacić komuś za kilka miesięcy kodowania i optymalizacji/zmian w kodzie, niż dokupić kolejny serwer, to chyba pora, żebyś przestał zatrudniać licealistów
Ale oczywiście jeśli dostaniemy gratis dobry JIT, to tym lepiej.

Ale jak się trochę zastanowić, to brakuje mi w PHP realnej możliwości postawienia usługi (np. serwera socketowego). W teorii można, ale w praktyce parę elementów by się przydało w PHP zmienić, żeby to przeszło. Choćby todać wielowątkowość (porządnie zrobioną, bez hacków i kombinacji).

Swoją drogą, jestem ciekaw, czy się rozwinie HACK i czy rozwiąże wkrótce ten problem, bo jak na razie rozwija się ciekawie.

Dobry serwer to koszt ok 20k złotych, stać Cie na taki wydatek od tak? Mogę Ci przysłać CV?

@Dejmien_85 - korzystasz z tego? Od jakiegoś czasu szukam ludzi którzy korzystają z tego typu narzędzi/nagładek/nowinek i okazuje się że to tylko ciekawostki przyrodnicze.

Gdyby to jakiś Józek z Bagien wypuścił Hacka, wtedy mógłbym potraktować to jako ciekawostkę, jednak Facebook ma poważne plany co do swojego dziecka - na razie to bardzo świeży produkt, jednak to, że HHVM i Hack sały się Open Source daje pewną nadzieję.

To może być ciekawy zestaw, jak na razie jego rozwój jest ograniczony do developerów Facebooka - przez co jego przyszłość owiana jest niepewnością. Zobaczymy jakie będą dalsze poczynania Facebooka. Na razie się przyglądam, tak samo jak i wielu innych developerów. Społeczność raczej obawia się tworzyć kod produkcyjny na Hacku (nie jest jeszcze przetestowany przez zwykłych szaraków, nie wiadomo co FB wymyśli, co ze wsparciem itd) - jedno jest pewne, społeczność PHP przygląda się Hackowi z ciekawością.

Moim zdaniem jest to coś godnego uwagi - przynajmniej dla mnie. PHP to nie mój jedyny język, obcuję także z innymi (głównie C-style). Hack to kolejna alternatywa, z której mogę zacząć korzystać błyskawicznie szybko.Problem jest tylko z bibliotekami (a właściwie z ich brakiem). No cóż, zobaczymy co przyniesie przyszłość.

Skoro już jesteśmy przy uprzejmościach, ok - pierwszym do zwolnienia będziesz Ty. Programiści są drodzy, hardware tani, owszem, jednakże wytłumacz biznesowi dlaczego koszt miesięczny infrastruktury przekracza grubo dochód roczny średniego Polaka. Są takie rozmiary aplikacji, o których Ci się nie śniło, lecz dopóki będziesz 'klepać stronki' w Wordpressie to obawiam się, że tego się nie dowiesz.

Koniec uprzejmości, teraz na poważnie. Często aplikacja wymaga kilka serwerów, gdzie 20k to tak na dzień dobry, do tego dolicz kolokacje. Produkcja, staging no i jakiś dev playground. Do tego model SaSS potrafi przy źle zaprojektowanej aplikacji znacznie wygenerować koszta utrzymania, co przelewa się na koszt aplikacji, co jednoznacznie ma wpływ na dochody firmy itd.

Nie zrozum mnie źle, ja nie twierdzę, że nic nie ma sensu niczego optymalizować. Spora część stron jest pisana do dupy, bo tak jest szybciej, a potem się ktoś dziwi, ze rozwój tego jest drogi i że coś się sypie. Niestety przy czymś takim pracuję teraz, gdzie wcześniej ktoś przez kilka lat pisał do kitu i teraz nie tak łatwo doprowadzić wszystko do prządku, a od nowa przepisać też nie ma za co.

A to nie zmienia faktu, że istnieją duże aplikacje, i zawsze będą istniały takie, które na jednym serwerze się nie pomieszcza choćby nie wiem jak i co optymalizować. 20 000zł to jakieś 3 miesiące kosztów pracownika (+-, zależnie od wypłaty). Jeśli coś da się taniej zoptymalizować, to znaczy, że pewnie nie było najlepiej napisane i to oczywiście trzeba optymalizować, ale nie wszystko się da łatwo zrobić lepiej. Tak, jak pisałem, jeśli dostaniemy optymalizację PHPa gratis, to super.

Zresztą. kolejna wersja PHP to nie tylko kwestia JIT i innych optymalizacji.


Póki co, ostatnio czytam coraz więcej o hacku i jestem coraz pozytywniej do niego nastawiony. Ale ponieważ nie wszystko można ot tak sobie przenieść na hacka, szczególnie w przypadku projektów ze zmieszanym PHP z HTML, to nadal czekam na rozwój PHPa.

Hack w przypadku PHPowców wydaje się spoko przy budowie API, jednakże to jest po prostu kolejna warstwa abstrakcji, w dodatku nałożona na sam język, co jest średnio fajne, bo nagle w projekcie jest: jakiś język szablonów, biblioteka js, może jakiś framework js, makarony z php, biblioteki frameworka php no i nasz kod napisany w hacku. Troche sporo do utrzymania

Bez przesady. O ile wcześniej nie pisałeś na zasadzie "jak leci, tak będzie" to różnica jest minimalna, nie mieszałeś kodu z HTMLem itp. to róznia nie jest taka duża.
Jakiś system szablonów i tak trzeba było mieć. Jakiegoś frameworka trzeba było używać, JS jest niezeleżny od serwera, więc to bez róznicy, czy resztę masz w PHP czy HACKu.
Fakt, że nie każdy projekt da się przenieść z PHP na HACKa, ale jeśli się zaczyna nowy projekt, to myślę, że HACK jest godny rozważenia i nie stanowi większej różnycy przy pisaniu. Trzeba się tylko nauczyć, żeby nie tylko nie powinno się używać eval(), ale w ogóle się nie da, że nie tylko nie powinno się mieszać HTML z kodem, ale w ogóle się nie da, i żeby typować zmienne, i w zasadzie wielkich róznic przy nowych projektach nie widzę.

Ale szkaradztwo Ja akurat lubię prostotę w PHP, jeśli ktoś chce żeby język wyglądał jak C++ albo Java... to można pisać w C++ albo Java. Raczej nikt nie będzie umiał w tym pisać jak się to przerobi na trochę lepsze C. Na chwilę obecną największym problemem jest brak współbieżności. Ile % programistów PHP ogarnie współbieżność, jeśli większość pewnie nawet koncepcji wykonywania kodu po zwróceniu odpowiedzi nie będzie w stanie zrozumieć. Popularność języka wynika z tego, że nie ma w nim skomplikowanych koncepcji, a nie z faktu że sam język jest prosty.

Jakiś czas temu dodano np. możliwość wykonywania kilku kwerend sql równocześnie. Robi to ktoś? Ja nie widziałem

@fizzlebubble: 20k to dużo? Przecież to mniej niż koszt zatrudnienia pracownika przez rok na minimalnej. A nikt nie będzie za tyle pracował (w IT tym bardziej). Z czegoś ta popularność wynika. Optymalizacja się w 99% przypadków po prostu nie opłaca (ja akurat się zajmuję optymalizacją). Taniej jest dołożyć nowy serwer niż coś optymalizować nawet jeśli zakładamy że proces zajmie tylko 2 tygodnie. No chyba że: optymalizujemy sql; ktoś coś totalnie skopał w kodzie; piszemy w C i nam odpadnie konieczność dołożenia 20 serwerów.

@MatKus

Poczytaj o golang albo C++ z STL. Jak już iść w optymalizacje to dlaczego półśrodkami? Za hack raczej nikt nie zapłaci bo przyrost wydajności będzie zbyt niski żeby w tym cokolwiek optymalizować, a koszty kodu i narzut na produktywność zbyt wysokie, żeby w tym pisać.

LOL ale dowaliłeś... jest akurat dokładnie odwrotnie. Stosunek przyrostu wydajności do kosztu pisania kodu jest dla HACKa wielce satysfakcjonujący i to się właśnie opłaca. Poczytaj trochę w necie.

No ok, ale żeby pisać w golang, C++ itp. to muszę się nauczyć nowego języka i napisać cały kod od nowa.
Żeby przejśc na hack, muszę nauczyć się tylko kilku róznic w stosunku do PHP, a większość kodu można z automatu skonwertować. więc nakład tu jest stosunkowo niewielki.

Oczywiście automat nie zamieni wszystkiego, szczególnie, jeśli kod PHP był napisany do d*.* , ale i tak te poprawki, które trzeba zrobić są o wiele mniej czasochłonne, niż przepisanie wszystkiego na nowo nie wspominając o nauce nowego języka.

Ciężko natomiast mi wypowiedzieć się na temat przyrostu wydajności. Sam testów nie robiłem żadnych, więc ciężko powiedzieć, ale podobno jest duża.

Wydaje mi się, że Hack może być dość dobrym złotym środkiem pomiędzy poświęcaniem czasu na optymalizację a dokładaniem nowych serwerów.

Ogólnie przyrost wydajności max (optymistycznie) x4 to nic... bo założenia pesymistyczne są takie, że realnie to 1-2x ... no może dla nowych projektów, ale raczej mało kto zapłaci dodatkowo, żeby pisać w hacku, kiedy serwery są tanie jak barszcz. Przy takich liczbach to się nijak ekonomicznie nie spina, no chyba, że pracujesz z dzieciakami na ZPN, które piszą kod za paczkę chipsów, więc mogą napisać trochę szybszy kod za 2 paczki Największy problem to wbrew pozorom brak dostępu do wspólnego dla całej aplikacji obszaru pamięci.

C / go to przyrost rzędu 300-1000x (nie procent), więc tu już sprawa wygląda inaczej. A zmienne możesz sobie "keszować" lokalnie bez używania relatywnie w tym wypadku wolnego memcached.


To wymówka, jeśli to automat - powinien wszystko zamieniać, to są takie semi-automatyczne narzędzia