Rok temu ShadowD pisał o Phalconie, jendak chciałbym odnowić dyskusję, ponieważ trochę się zmineiło od tego czasu.

Może krótkie wprowadzenie. Phalcon jest frameworkiem PHP napisanym pierwotnie w C. Dzięki temu jest niesamowicie szybki. W "standardowych" frameworkach PHP przy każdym zapytaniu kod frameworka jest w całości interpretowany od nowa, co zajmuje trochę czasu. Phalcon jest już skompilowany, więc nie ma tego problemu. Wystarczy dodać rozszerzenie w postaci pliku dll dla serwera Aapche.
Ma to jednak swoje wady. Po pierwsze raczej mozemy zapomnieć w phlaconie na standardowych hostingach wpsółdzielonych. Potrzebujemy VPS-a gdyż tylko tam mamy możliwość instalowania własnych rozszerzeń.
Jest też problem rozwoju frameworka. Jest on stworzony dla programistów PHP, ale sam napisany jest w C. Nie każdy programista PHP zna C, a te języki mimo wszystko się różnią. Twórcy frameworka postanowili więc stworzyć własny język programowania, Zephir, który łączy cechy PHP oraz C(a także... Rust i Javascript). Trochę radykalne rozwiązanie, ale Zephir naprawdę wygląda ciekawie. I to głównie temat Zephira chciałbym poruszyć.

Zephir jest językiem zarówno typowanym dynamicznie(jak php czy javascirpt) jak i statycznie©. Zephir jest tłumaczony do C. W przeciwieństwie do PHP, Zephir wymusza pewne dobre standardy, i dodaje funkcje których w PHP brakuje, na przykład:
-Kod musi być umieszczony w klasach. Zephir jest wpełni obiektowy.
-Namespace jest konieczny
-używanie $ nie jest wymagane
-Możemy ustalić jaki typ danych ma zwracać metoda

Dzięki Zephir możemy tworzyć rozszerzenia. Więc całe nasze aplikacje możemy skompilować do C, tym samym znacznie poprawiając wydajność.
Zachęcam do oglądniecia składni zephir na http://zephir-lang.com/intro.html

Co myślicie o projekcie Zephir? Przesada, czy coś naprawdę przyszłościowego?

Czemu Zephir skoro jest już Hack, który działa szybciej.

Kod bez $, szczególnie po jego ukończeniu to bluźnierstwo.
Dobre te przykłady, ale... to samo jest w PHP od kilku lat.

Zaraz zacznie się czepialstwo o wymuszenie przestrzeni nazw i pełne oop, ale... kogo to obchodzi. Wszyscy co pracują w zawodzie, piszą obiektowo i używają przestrzeni nazw, więc jest to swego rodzaju wymuszenie

Przeglądając przykłady Zephira, nie ma w nich nic specjalnego, ot standardowa składnia czegoś co się kompiluje.
Projekty tego typu mają jedną wspólną wadę, brak im oficjalnego wsparcia PHP.

Ja osobiście używam Phalcona i bardzo sobie chwale, fajnie, szybko i przyjemnie. Zephir to dla mnie już lekka przesada. Jak już zagłębiać się w taki styl pisania to równie dobrze mogę wybrać jakikolwiek kompilowany język.

Jw. po co wchodzić w Zephira? Jakieś argumenty? Czemu nie jakikolwiek inny stabilny, pewny, język?
To raczej wyłącznie ciekawostka, projekt "hobbystyczny"

Zephir powstał z tego samego powodu, co Hack. Umożliwia lepsze, szybsze i bardziej niezawodne pisanie prawdziwie złożonego oprogramowania, które zawiera mniejszą ilość błędów, a dodatkowo oferuje ogromny skok wydajnościowy w porównaniu z PHP. Nie wiem, jak można nie rozumieć zalet tych języków. Nota bene, nie powstałyby, gdyby się to nie opłacało (a przykład Hack jasno pokazuje, że się opłaca). Szybsze pisanie aplikacji oraz znacznie lepsza wydajność serwerów to ogromne oszczędności (czyli zyski).
Tak na marginesie, przykłady języków takich jak Zephir, Hack czy ostatnio omawiany na forum Dart Lang dla JavaScript pokazują, że jednak języki o silnej kontroli typów pod pewnymi względami oferują znaczącą przewagę nad tymi o słabym typowaniu.
Problemem w popularyzacji może być (i zwykle jest) brak szerokiego wsparcia dla takich modyfikacji, oraz niechęć nauczenia się czegoś nowego u programistów.
Liczę na to, że kiedyś będę mógł pracować z którymś z tych rozwiązań.

Ok czyli na żadnym z nich nie masz produkcyjnego doświadczenia, ale zakładasz, że to co piszą o nich autorzy się w 100% sprawdza.
Że aplikacje na nich są super wydajne, stabilne, łatwe w rozwoju i jeszcze zawierają mniejszą liczbę błędów! Wow!
* Nie są łatwe w rozwoju - ile znasz developerów w PL ze znajomością zephira?
* Nie są Stabilne - sama "technologia" jest młoda (0.3!) więc aplikacje nie mogą być stabilne, pokaż jakiekolwiek większe produkcyjne wdrożenie
* Mniejsza liczba błędów - niby czemu? W głównej mierze to od developera zależy czy popełni błędy - czy to Java czy PHP


Na stronie zephira nie znalazłem żadnej informacji kto za tym stoi. Czemu używać "języka" do którego nawet autorzy się nie chcą przyznać? ;-)

Nie zakładam, tylko wiem, bo w necie jest dosyć omówień, przykładów i testów. Wystarczy też trochę obeznania z jakością oprogramowania tworzonego w różnych językach (dlatego oprogramowania banku nie pisze się w PHP, a Allegro przepisuje swój kod na Java). To Ty się mylisz kompletnie - chyba nie dociera do Ciebie, że taki Hack został stworzony, a teraz cały kod PHP fejsa jest na niego przepisywany, bo to lepiej działa i zwyczajnie się opłaca. I tak, zawierają mniejszą liczbę błędów, bo języki ze statyczną kontrolą typów siłą rzeczy zmniejszają liczbę bugów już na starcie, w trakcie pisania kodu (programowałeś kiedyś w czymś poza PHP?). Wymuszają również inne myślenie o projektowanym kodzie. Pomijam już fakt, że tradycyjnie PHP jest od lat obiektem kpin, a jego "zachęta" do pisania gównianego kodu - legendarna...

"Nie są łatwe w rozwoju - ile znasz developerów w PL ze znajomością zephira?" - sorry, ale to w ogóle nie jest argument Szkoda, że tego nie rozumiesz. Nie chodzi o to, ilu znam takich programistów, tylko o to, że pisanie programu w takim języku przynosi korzyści.

"pokaż jakiekolwiek większe produkcyjne wdrożenie" - Facebook

"W głównej mierze to od developera zależy czy popełni błędy" - tak, ale nie tylko. Od języka także zależy wiele. Właśnie m.in. dlatego nie programujemy w assemblerze, a C został zastąpiony C++, potem pojawiły się Java/C# itd. Języki ewoluują, modyfikuje się je i tworzy się nowe często po to, by uniknąć błędów i bolączek typowych dla programowania w jakimś wcześniejszym popularnym języku.

Dlatego też zamiast uczyć się Zephir, polecam zainteresować się Hack, stoi za tym Facebook, któremu bardzo zależy na wydajności, sprawdza się w środowisku produkcyjnym (bardzo dużym środowisku produkcyjnym).

@irmidjusz, szybsze tak, natomiast to czy lepsze czy też niezawodne pisanie prawdziwie złożonego oprogramowania to już kwestia kto to pisze... Ilość błędów zależy od programisty. Nie napisałbym tez że jest to szybsze pisanie aplikacji, do tego potrzeba wprawy. Ba, ktoś mógłby powiedzieć że w notatniku jest w stanie szybciej napisać cały projekt oparty o Zend'a niż najlepszy programista X używając 10 narzędzi...
A i przykłady takich języków pokazują że jest zapotrzebowanie dla duzych projektów, z setkami tysięcy czy też milionami użytkowników, gdzie każdy 1% użycia procesora kosztuje majątek. Takich klientów jest niewielu więc PHP jak najbardziej spełnia się w swojej roli. Silne typowanie to też ograniczenia, bo programista musi pamiętać jakiego typu wartość może wrzucić w daną zmienną zamiast pozwalać dokonać wyboru kompilatorowi/interpreterowi.

Argument godny jaskiniowca, który od kilku lat nie wynurzył nosa ze swojej groty. PHP5 akurat ma się bardzo dobrze (napisałeś kiedyś coś w nowszej wersji niż PHP4?). Tego typu obiekcji używają właśnie jaskiniowcy, którzy fikcyjnie sobie uznali, że przy PHP w wersji 4 jakikolwiek rozwój języka upadł i nic się nie zmienia.



To akurat bardzo dobry argument, i szkoda, że nie @ano, tylko Ty tego nie rozumiesz. A powodów jest nawet kilka:
- dużo trudniej znaleźć osobę obeznaną w danej technologii, a kiedy akurat taka osoba jest potrzebna, to może się taka sytuacja okazać niezłym koszmarem. Sam szukałem swojego czasu front-endowca. Niby JS jest na większości stron w internecie, niby stosunkowo łatwe technologie, a znaleźć kogoś, kto umie więcej niż osadzić skrypty z lekkimi modyfikacjami, nie siedzącą miesiąc nad lightboxem własnej roboty i ogólnie potrafiącą więcej niż zakodowanie HTML/CSS z "średnim" oskryptowaniem mi się nie udało (z jednym wyjątkiem, ale nie było mnie stać na 8k NETTO ). A niby powinno ich być na pęczki? "Programistów" jest sporo, ale Programistów co kot napłakał.
- Nawet jak już się uda znaleźć kogoś znającego daną technologię na niebanalnym poziomie, to trzeba jej odpowiednio więcej zapłacić i jak jest grupa devów, która nad tym pracuje, to koszt utrzymania takiej grupy to będzie jakieś kilkadziesiąt tysięcy więcej. W przypadku wspomnianego Facebooka takie kwotki nie mają znaczenia, ale ktoś mnie chyba zapomniał uświadomić, że świat kończy się jedynie na FB, Google i Microsoft, a firmy zatrudniające po kilka-kilkanaście osób (programistów) po prostu nie istnieją (w rzeczywistości jest ich oczywiście dużo więcej i w nich takie kwoty mają jednak znaczenie).
- Mniejsza popularność to dużo mniejsze wsparcie i ogólnie community. Jak wejdziesz np. na StackOverflow albo na to forum z problemem w PHP albo JS, to odpowiedź otrzymasz bardzo szybko, a jak przyjdziesz z technologią, o której dużo osób nawet nie słyszało, a problem nie będzie oczywisty, to już będziesz miał opóźnienia i problemy.
- ...jeszcze kilka argumentów dałoby się wymienić, ale chyba nie ma po co i nawet nie chce mi się



To prawda, że język może być wydajniejszy, ale w pierwszej kolejności i dużo istotniejszym czynnikiem propo wydajności, etc. jest właśnie programista. Jak ktoś robi dla tablicy z 1000 elementami 1000 insertów zamiast jednego, to sorry, ale najwydajniejszy język na świecie tu nie pomoże.

// EDIT

To prawda natomiast co do ścisłego typowania. Brakuje mi tego w PHP, przez co używam często rzutowania. Twórcy PHP mogliby wykombinować jakieś określanie typu ze zgodnością wstecz i byłoby git

Ale chyba nie rozumiecie. Zephyr nie powstał po to żeby być nowym lepszym PHP, czy nawet żeby być nowym językiem. Gdzieś w dokumentacji nawet bardzo jasno to było zaznaczone. Powstał jako dodatek do Phalcona bo taka była potrzeba. Powstał żeby ułatwić pisanie rozszerzeń do PHP. Ile osób zna C żeby coś w nim więcej napisać i wkompilować jako rozszerzenie PHP?

Działa to w dwie strony. Szukasz programisty ML to jak znajdziesz to jest dobry, jak szukasz Javy/C# to się kończy źle, bo są ich dziesiątki, ale konkretnego znaleźć trudno.

Pozatym Hack się kompiluje do bytecodu HHVM a Zephir do C (czemu C a nie od razu llvm?!)

Chyba trochę źle napisałem pierwszy post. Gdy czytam go teraz, można odnieść wrażenie, jakoby Zephir miał być czymś co ma nam zastąpić PHP/C, ale oczywiście nie po to on powstał. Zephir powstał przede wszystkim po to by rozwijać Phalcon(cały kod tego frameworka jest obecnie przepisywany na Zephir). Nie wszyscy developerzy znają C, aby mogli pomagać w tworzeniu frameworka, więc zephir ma być mostem pomiędzy PHP a C.
W tym wpisie na blogu Phalcon-a, można znelść informacje na temat tego czy Zephir nie będzie. Zacytuję:


Natomiast tutaj czy Zephir ma być:


Ktoś wyżej pytał o twórców języka: http://phalconphp.com/pl/team

Pyro, głupoty napisałeś. Nie kontynuujmy już tego. Cieszę się, że masz swoje zdanie na ten temat, ja jednak pozostanę przy swoim. Pozdrawiam. I bez urazy

Viking - dokładnie tak, i dlatego jeśli ktoś używa Phalcona (a także, jeśli nie używa) możliwość napisania czegoś w Zephir'ze jest super, bo jest to język bardzo łatwy do nauczenia dla programisty PHP, pod wieloma względami lepszy (ułatwia programowanie i skraca czas pracy) a wynikiem jest kod znacznie wydajniejszy, niż PHP. Można przepisywać krytyczne fragmenty kodu z PHP na Zephir w razie potrzeby (podobnie jak w przypadku Hack'a).

Ok, każdy ma prawo mieć swoje zdanie i szanuję to. Tylko nie pisz, że ja głupoty piszę, bo według mnie to akurat Ty głupoty piszesz . Po prostu mamy odmienne zdanie.




Dyskusja rozwinęła na temat Zephiro-Hacklangowych języków. Używanie samego Phalcona ma sens, bo mimo wszystko pisze się w nim jak w PHP, a nie w nowej składni. U mnie jest na liście jako kolejny do dokładnego zapoznania się, jak tylko będę miał czas.

Dlaczego wchodzić w Zephira, jakie ma zalety nad Javą? (Całkowicie serio pytanie - oba języki przecież niby kompilowane?)
Potrafisz napisać konkretne argumenty, które by nas przekonały? :-)

Język raczej nie jest wydajny, ani niewydajny (wiem, czepiam się )

Jeżeli mówimy o tym, że nowocześniejsze języki typu java/c# przyspieszają tworzenie aplikacji, to argument, że wiedza programisty też jest ważna, bo kiepski programista zrobić 1000 strzałów do bazy tam, gdzie można zrobić to jednym strzałem jest nietrafiony.
Wydajność aplikacji, a wydajność programisty kodującego w danym języku, to dwie różne rzeczy.
Jeśli programista potrafi optymalnie programować, to zaprogramuje optymalnie zarówno w php jak i w np. javie - z tym, kod w javie chyba będzie działał szybciej niż ten w phpie.

Jeżeli chodzi o wydajność aplikacji napisanych w php - to wydaje mi się, że jest słabo. Jeśli chodzi o wydajność programisty, to trudno powiedzieć, bo z jednej strony dynamiczna typizacja przyspiesza tworzenie kodu, jest mnóstwo gotowego kodu, frameworków. Z drugiej strony, czytelność kodu na tym traci i poprawianie błędów nie należy do najsprawniejszych. Generalnie temat sporny i każdy może mieć własne zdanie. Osobiście dużego projektu w PHP nie chciałbym robić.

Trend rozwoju języków jest taki, żeby kod był jak najmniejszy oraz jak najbardziej czytelny, (bo to przyczynia się do wydajności programisty, a więc na koszt stworzenia aplikacji). Zazwyczaj skutkiem ubocznym jest spadek wydajności aplikacji (ale chyba nieznacznie, bo np. kod napisany w javie może być szybszy niż analogiczny pisany w czymś niskopoziomowym - przynajmniej takie testy widziałem - nie wiem na ile są one prawdziwe). Dla tego tak jest, bo sprzęt jest tańszy niż programista (poza tym, ktoś musi napędzać rynek hardware, gdyby wszystko było super optymalne, to kto by kupił procesor i7 ?).

Osobiście nie widzę zalet ani zephira, ani phalcona. Skoro i tak trzeba wyjść poza standardowy wirtualny serwer z php i inwestować w jakiegoś dedyka, to już lepiej postawić na tym javę, albo asp.net'a. Łatwiej znaleźć kogoś od javy/c# niż zephyra. No.. ale tylko moje zdanie.

Nie nie... Zephir nie jest lepszy od Javy.
Jest lepszy od PHP, a użytym przeze mnie kryterium prowadzącym do takiej oceny jest: 1) jakość i czytelność kodu 2) szybkość wykonywania tego kodu.
Zephir jest wręcz banalnie łatwy do nauczenia dla programisty PHP. Kod pisany w Zephir i ten pisany w PHP bezproblemowo ze sobą współpracują. Jest to jedno środowisko.
I o to w tym wszystkim chodzi.

A tu kilka cennych uwag:



Dokładnie tak! I rozwiązania typu Zephir/Hack to właśnie "lekarstwa" na kilka z wymienionych wyżej problemów, a przede wszystkim:
- niską wydajność wynikowego kodu
- brak statycznego typowania i płynących z niego pożytków



To zależy. Jeśli robisz coś od zera i wstępna analiza sugeruje użycie języka typu Java/C# - to albo już masz programistów, którzy dobrze ogarniają te technologie, albo zostaje Ci skompletować nowy zespół. I jest git.
Natomiast inaczej sprawa wygląda, gdy już masz masę kodu napisanego w PHP, bądź Ty i Twój zespół jesteście wymiataczami w PHP ale nie ogarniacie innych języków. Wówczas najtańszą i najszybszą metodą na 1) ogromne zwiększenie wydajności aplikacji, oraz 2) całkiem niezłe poprawienie jakości samego kodu, będzie przepisać go (a przynajmniej najważniejsze fragmenty) za pomocą Zephira czy Hacka - zależnie, jakie mamy możliwości. I tu użycie Phalcona z Zephirem będzie akurat prostsze w większości przypadków, bo Hack wymaga zupełnie innego interpretera PHP, a Phalcon to tylko rozszerzenie do PHP.

Całkiem niedawno gdzieś też czytałem, że programiści Facebooka sami z siebie przepisują istniejący kod z PHP na Hacka bo jest to kod bezpieczniejszy, i solidniejszy, po prostu lepszy do czytania i edycji. To przekonuje mnie najbardziej, jest to najlepszy dowód na to, że to ma sens i się sprawdza. Zephir jest specyficznym rozwiązaniem, bo służy do pisania rozszerzeń dla PHP, ale można go stosować z bardzo podobnym skutkiem, jak Hack dla HHVM.

Odnoszę wrażenie, że "lepszy do czytania i edycji" to po prostu kwestia gustu. Zerknąłem tylko na pierwsze przykłady i różnice w stosunku do PHP moim zdaniem mogą powodować niejasności oraz brzydszy kod (keyword "let", brak nawiasów w warunku pętli).

Owszem, zgadzam się, że to w znacznej mierze kwestia gustu, ale nie tylko. Weź pod uwagę, że pobieżnie zapoznałeś się z tym kodem, czyli jest to dla Ciebie nieznane, obce - nie jesteś przyzwyczajony do czytania takiego kodu, Twój mózg nie przetwarza go łatwo. Dotyczy to każdego języka oczywiście. Trzeba się trochę przyzwyczaić, nauczyć mózg składni, sposobu formatowania, charakterystycznych słów kluczowych itp. Wówczas dopiero oglądanie kodu wymaga od mózgu minimum wysiłku na przetwarzanie wizualne znaków i składanie ich w większą całość, a większą część energii może poświęcić na analizę i zrozumienie znaczenia tego, co widzi. Dlatego tak pożyteczne są wszelkie wspólne dla teamu standardy kodowania, co było badane i jest opisane w literaturze. A teraz pytanie: co, jeśli po paru tygodniach/miesiącach programowania jedynie w takim np. Hack'u stwierdził byś, że to znacznie lepsze, przyjemniej się pisze, łatwiej czyta, kod jest ogólnie lepszy i ma mniejszą ilość błędów? Ha? Myślisz, że to możliwe, że nie chciał byś już wrócić do PHP?
Pisząc "lepszy do czytania i edycji" mam na myśli nie tylko czytelność kodu dla programisty (a wg. mnie języki z silnym typowaniem dają jednak solidniejszy, bardziej uporządkowany i logiczny kod, chociaż faktycznie trzeba go napisać więcej - coś za coś), ale również możliwość korzystania ze statycznej analizy kodu - to jest bardzo duży plus.

Podsumowując, nie uważam, żeby trzeba było się przesiadać z PHP na Zephira czy Hacka robiąc typową stronę dla klienta - absolutnie nie o to mi chodzi Uważam, że są to bardzo pożyteczne narzędzia uzupełniające PHP, przeznaczone do konkretnych celów, za pomocą których można osiągnąć znaczące korzyści.

Z doświadczenia które ostatnio dość szybko nabywam wynika, że nikt kto zajmuje się tworzeniem serwisów internetowych dla poważnych klientów, nie będzie używał dopiero rozwijającego się rozwiązania które nie jest przetestowane "live". W definicji wsyzstko jest fajne ale wszyscy którzy chcą zarabiać korzystają ze sprawdzonych rozwiązań, któe nie stwarzają ryzyka wydania ogromnych kwot na wsparcie nowych rzeczy "bo okazało się że coś nawala". Zephir jako pisanie rozszerzeń do PHP to też moim zdaniem kula u nogi... Wzrost wydajności - ok, ale jaki w porównaniu do C ? Pisanie całych aplikacji albo ich części ? Jaki sens ? Równie dobrze mogę łączyć PHP z Javą, C# , C ...

Jeśli zespół nie ogarnia języków innych niż php, to jaka różnica czy przerzucą się na np. javę, czy hacka, skoro ani jednego, ani drugiego nie znają ?


nasz jakiś mały program, w asm, c oraz javie - ciekawe ile osób będzie "gustować" w składni asm'a.


Również uważam, że PHP to świetne narzędziem jeśli trzeba zrobić tanią dość prostą stronkę -tania siła robocza, tanie serwery, duża społeczność.
Ale w momencie gdy php nie wystarcza, moim zdaniem zamiast instalować jakieś egzotyczne usprawniacze typu phalcon, warto zaiwestować w coś lepszego, przetestowanego np. java, czy asp.net.

Tak, wspomnieliśmy już, że ze względu na swoją wczesną wersję Zephir jest tylko ciekawostką. Dyskusja toczy się, czy takie rozwiązania mają sens istnieć w ogóle.


Zephir jest tłumaczony bezpośrednio do C. Zobacz przykład tutaj.

Ale to w żaden sposób nie determinuje wydajności.

Zarówno Zephir jak i Hack/HHVM są przetestowane live. Zephir służy obecnie do pisania Phalcona a ta biblioteka zdobywa sobie coraz większe uznanie - ale ok, zgadzam się, że Zephir jeszcze musi okrzepnąć. Natomiast Hack i HHVM każdego dnia udowadniają, że są to dojrzałe i godne zaufania, nie sądzisz? W końcu pracują na kilkudziesięciu tysiącach serwerów Facebooka



Pisałem już kilka razy - programista PHP nauczy się korzystać z Hacka czy Zephira bardzo łatwo. Nawet nie da się tego porównać z czasem potrzebnym na sensowne ogarnięcie Javy...



Jednak determinuje. Po przepisaniu kodu PHP z minimum niezbędnych zmian na Zephir i skompilowaniu tego do kodu C rozszerzenia PHP już uzyskuje się masakryczny skok wydajności. Nie ma nawet potrzeby pytać "a co jeśli kod robiący to samo napisany w C będzie jeszcze 10x szybszy?" - bo może będzie, a może nie będzie, nie wiadomo - gdy tymczasem już osiągnięto doskonały, z dużym prawdopodobieństwem wystarczający, wzrost wydajności przy ogromnie mniejszym nakładzie pracy (i kosztach) w porównaniu z pisaniem tego w C od zera.

OK, jakieś to wytłumaczenie jest. Chociaż ja nie rozumiem skąd się bierze ten mit trudności javy. Moim zdaniem, języki typu java/c# były tworzone głównie po to, by tworzenie aplikacji było szybkie i łatwe. Chyba na każdych studiach informatycznych jest java, lub c#, a każdy programista raczej powinien znać "elementarz" języków c, c++, java w jakimś stopniu. No ale skoro mówisz, że java jest problemem dla programistów PHP, to OK. Nie ja tu jestem od biznes planu


Po pierwsze, PHP jest tak bardzo wolne (po części wynika to z tego, że jest po prostu językiem interpretowanym, a po części z "błędów technicznych"), że trzeba by się mocno starać, by przepisując kod z php'a na coś innego (w dodatku natywnego) nie otrzymać dużego skoku wydajności.

Kompilowanie kodu do do języka C, nie determinuje wydajności
Nie można powiedzieć, że "zephyr jest szybki", bo kompiluje się do C. Tzn. może kod w nim pisany jest "szybki" w porównaniu do PHP, to pokazuje praktyka. Na logikę można się spodziewać, że gdyby był kompilowany do... PHP, pewnie byłby wolniejszy, niż kompilowany do C. Ale czy można powiedzieć o tym, że język C, lub np. Pascal jest szybki, bo kompiluje się do kodu maszynowego ? Dobry programista assemblera zawsze napisze program mniejszy i szybszy niż jego odpowiednik w języku C/Pascal.
Standard ANSI C sam w sobie nie gwarantuje wydajności. To tylko język - "zbiór słów kluczowych". To jak szybko będzie działał program napisany w c, zależy w znacznej mierze od kompilatora. Oczywiście od samego języka zależy na ile optymalny kompilator da się zbudować. Np. programy pisane w językach dynamiczne typowanych, będą wolniejsze od statycznie typowanych, bo "struktura języka" nie sprzyja budowaniu kompilatorów generujących wydajny kod.
Takich porównań wydajności kompilatorów jest dość dużo. Tutaj jakiś pierwszy lepszy przykład jaki wygooglowałem. http://www.g-truc.net/post-0372.html . Niby ten sam język, a każdy kompilator kompiluje inaczej.

Podobnie w przypadku Zephyra - kompiluje się on do C, potem C jest kompilowane do kodu maszynowego.
To, na ile będzie wydajny kod napisany w zephyrze, zależy od tego jak dobrze skompiluje się kod c do kodu maszynowego (jak wyżej napisałem - każdy kompilator generuje inny kod - "inaczej wydajny"), zależy również od tego na ile wydajny jest "kompilator zephyr -> C". No i zależy od samego programisty, ale to inna bajka.


Napiszcie lepiej (bo jestem tego ciekawy, a znaleźć nie bardzo potrafię), Czy Zephyr w jakichś sposób zarządza pamięcią ? Jakiś garbage collector ? Czy może sterty w ogóle nie używa ?
Moim zdaniem, jedną z większych zalet języków java/c# to właśnie gc - zawsze to jedna rzecz mniej na głowie programisty.

Nie. Język wprowadza nowe abstrakcje, które trzeba zrozumieć. Poza tym wątpię, żeby ktokolwiek teraz rozumiał wydajność Hacka lub Zephira. Dla porównania istnieją liczne opracowania na temat wydajności Javy.

Potrzebne są realne porównania. Zephir ma mechanizmy, których nie ma w C, tworzą one narzut. Dodatkowo język PHP nie jest binarnie kompatybilny z C, czyli odwołania do takich rozszerzeń są kosztowne. Nie wiadomo jak wygenerowany kod się optymalizuje w kompilatorze etc. Pewnie, będzie szybsze od PHP, ale to o absolutnie niczym nie świadczy. I raczej wątpię żeby był chociażby w okolicach 10 krotnego zwolnienia w stosunku do czystego C.

Java i PHP są oczywiście dość podobne w zakresie składni i podstawowego używania, bo to ta sama rodzina języków. Ale nie wystarczy poznać tylko składni języka!!! Programista aby efektywnie i sensownie kodować musi znać całe środowisko programistyczne, w którym pracuje. Biblioteki, rozszerzenia, narzędzia dodatkowe, frameworki, dobre sposoby kodowania (idiomy), najlepsze wzorce implementacyjne itp. To wszystko wymaga czasu i przychodzi z doświadczeniem. Nauczenie się świata Javy to jest jednak kupa roboty. Ja cały czas mam na myśli przecież doświadczonych programistów PHP. Ile czasu potrzeba, aby zostać doświadczonym programistą Java czy C#/.NET? I o ten czas mi chodzi. Taki programista PHP wie i umie wykorzystać ten język oraz wszystko to, co składa się na specyfikę programowania w PHP. Teraz poznanie i zastosowanie Hacka czy Zephira w tym kontekście, to jest pestka. Wymagany na to czas jest po prostu śmiesznie mały.



No przecież właśnie o tym mówię! Użycie Zephira czy Hacka to m.in. znaczący skok wydajnościowy niesamowicie niskim kosztem - dla teamu doświadczonych pehapowców, którzy już mają napisaną (bądź piszą) sporą aplikację to są po prostu genialne narzędzia.



Jasne! Ale i tak to jest cholernie szybsze, niż odpowiedni kod PHP, który przepisano na Zephir. I o to chodzi! Wszystkie pozostałe teoretyczne rozważania w powyższym akapicie (nie zamieściłem ich) w ogóle tu nie mają znaczenia. Wszystkie benchmarki jasno pokazują, jak daleko w tyle Phalcon zostawia czysty kod PHP (wydajnościowo).



Nie zgadzam się, aby to była trudność.
I druga sprawa, że i tak to jest pikuś w porównaniu z ogarnięciem na poziomie zaawansowanym jakiegoś innego, konkurencyjnego języka.



No to chyba trzeba zacząć ich używać i osiągnąć to zrozumienie, he?



Tak jak wyżej - wciąż jest to znacznie wydajniej (zarówno jeśli chodzi o czas procka, jak i zapotrzebowanie na ram) niż PHP. Ale ale... czemu widzę tu takie porównywanie C i Zephir? Przecież ta dyskusja nie dotyczy tego, czy lepszy jest kod w C czy w Zephir. Dotyczy korzyści, jakie wnoszą technologie typu Zephir/Phalcon czy Hack/HHVM do świata PHP. A to, że przynajmniej Hack/HHVM wnosi, to nie mam wątpliwości, bo gdyby tak nie było, fejsbuk nie byłby przepisywany z PHP na Hack. I uważam, że Zephir/Phalcon to też bardzo obiecujące projekty. Wolisz płacić za 100 serwerów do obsługi ruchu, czy za 20?

A ja wcale o tym nie mówię
Wierzę wam na słowo, że Zephyr będzie szybszy od PHP'a - trudno w to nie uwierzyć. Przyczepiłem się tylko tego, że "szybkość Zephyra determinuje, że jest kompilowany do C".

To jest jedna, jedyna firma, w dodatku z syndromem not invented here i dużą kasą. Nic to nie świadczy o użyteczności tego projektu. Dodatkowo f może sobie pozwolić na napisanie wszystkiego w hack. Jaki jest zysk w klasycznej aplikacji hack/zephir gdzie aplikacja spędza 80% czasu w bibliotekach? Zephir/Phalcon staje się sensownym rozwiązaniem - masz chociaż framework, ale jesteś częściowo do niego przymuszony.

Dodatkowa myśl: dlaczego do stworzenia kompilatora AOT dla PHP trzeba zmieniać język? Nie lepiej byłoby kompilować PHP a nie jakąś jego część z rozszerzeniami?

Jest jedyna, bo sami to stworzyli. Wymyślili to i zrobili, bo potrzebowali tego ze względów ekonomicznych (wydajnościowych). Nie porzucili tego projektu, przeciwnie, używają go w coraz szerszym zakresie i stale rozwijają. Benchmarki jednoznacznie pokazują, że to działa szybciej. Uważam, że to świadczy o użyteczności.



No cóż, to już zupełnie inne zagadnienie Jest jak jest, mamy PHP takie, jakie mamy

Zrobili to, bo mogli. Nikt nigdy nie podał liczb na temat walorów ekonomicznych. Być może po prostu lubią marnować czas po to by na końcu móc zatrudniać dziesiątki średnich programistów PHP, dla których deklaracja typu będzie szczytem poszerzania horyzontów. Nie podali ile kosztowało stworzenie tej infrastruktury, ile powstaje nowego kodu PHP i ile było już starego i co najważniejsze, czy zmiana wydajności zmienia cokolwiek w wydajności dla końcowego użytkownika. Ja osobiście, strzelając twierdzę, że więcej pieniędzy kosztuje napisanie sensownej maszyny wirtualnej, potem kompilatora niż przepisanie f na javę. A jeszcze muszą przepisać mnóstwo kodu (poza własnym dochodzą biblioteki, żeby to miało sens) na hacka.

Ok, spoko, jak dla mnie to fantazjujesz, ale nie ma sprawy Myślę, że temat już się wyczerpał. Dzięki za wkład w dyskusję.