PHP i jego specyfika

Co takiego ma PHP, że jest uważany za wygodny język do prostych stron, ale oprócz tego denny?

Serio pytam, niewiele miałem styczności z PHP.

Jest to język dynamicznie typowany i domyślam się, że już z tego powodu może otrzymywać dużo hejtu, choć zdaje się, że są już tam opcjonalne anotacje typów?

Z tego, co się orientuję, to PHP tym się wyróżnia, że ma wbudowany język szablonów. Nie rozumiem tej decyzji projektowej, na intuicję język osobno i szablony osobno miałyby więcej sensu (jak np. Python / Django czy C# / Razor Pages), bo w przeciwnym wypadku łatwo o sytuację, gdy powstaje jakaś 3rd party biblioteka szablonów korzystająca z $buzzword_paradigm i pół języka idzie do śmieci?

Nie wiem, czy bzdur nie piszę, ale czy nie jest tak, że w PHP błędy są domyślnie logowane i ignorowane (nie powodują wyskoczenia z normalnego biegu programu, jak wyjątki w innych językach)? Jeśli tak jest, to domyślam się, że może być to powodem niechęci do PHP, bo - jak mi się zdaje - programiści zazwyczaj wychodzą z założenia, że stan programu po wystąpieniu błędu nieprzewidzianego przez programistę (= najczęściej bug) jest niezdefiniowany, zachowanie programu będzie w takiej sytuacji błędne, należy program jak najszybciej ubić, by zapobiec zwracaniu, a tym bardziej zapisywaniu błędnych danych.

Ale zdarzyło się już, że decydenci naciskali na coś zupełnie przeciwnego. Dla nich najgorszą sytuacją, jaką mogli sobie wyobrazić, było zatrzymanie programu albo niezwrócenie przez niego żadnych danych, upierali się, że dużo bardziej wolą zwrot i zapis trochę błędnych danych niż niezwrócenie jakichkolwiek danych, chcieli, by każdy błąd był zalogowany, ale koniecznie zignorowany. Przy takich wymogach biznesowych zachowanie PHP jest chyba jak najbardziej pożądane?

Wreszcie na PHP powstał przecież Wordpress i MediaWiki, nie są to jakieś prościutkie, małe projekty, więc może jednak PHP nadaje się też do czegoś bardziej skomplikowanego?

Tutaj chodzi tylko o wzgledy historyczne. PHP czasowo akurat sie tak wstrzelil, ze swego czasu byl bardzo popularny. A z tego powodu wiekszosc tanich hostingowcow obsluguje PHPa, CMSy sa zbudowane na PHP, jest duzo poradnikow itd. Jak ktos chce kupic najtanszy mozliwy hosting to nawet w 2021 taki hosting bedzie obslugiwac tylko PHPa (bo ten jest popularny i serwis hostingowy sobie kalkuluje ze wystarczy supportowac phpa). I tak przeszlosc niejako napedza kierunek przyszlosci. Niestety

Ogolnie to PHP jest popularny bo jest popularny. Zwykle szczescie. Rownie dobrze moglby to byc inny jezyk.

Przeczytaj sobie: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Artykuł napisany w 2014 roku, kiedy popularny był PHP 5.6. Od tamtego czasu w PHP naprawiono może 5-7% z tego, pozostałe 95% jest nadal aktualne.

Większość hejtu na PHP wynika z kilku rzeczy:

• po pierwsze z tego, że prawie każdy zaczynał swoją przygodę z PHP i pisał w nim potworki na jakie PHP pozwala - potem przesiadał się na inne języki i pamięta z PHP te złe rzeczy
• jak wspomniałeś jest to język dynamicznie typowany, nie ma kompilacji etc i to już niektórym wystarczy
• bardzo duża ilość hejtu to junior-java-developer, co ledwo potrafi CRUD w Springu ogarnąć, ale wydaje mu się, że zjadł wszystkie rozumy - taki typowy Duning-Kruger effect
• i chyba najważniejsze - większość hejtujących pisze raczej o rzeczach z PHP 4/5 i/lub nie zna nowszych wersji PHP
• PHP jako tania technologia ma niski próg wejścia, więc wiele projektów PHP to jest coś co nigdy nie powinno powstać

To co jest prawdą to PHP pozwala pisać chyba najgorszy kod ze znanych mi języków... no może poza JS, ale też poczynając od wersji 7 pozwala też pisać dobry kod. Wiele rzeczy, o których pisałeś nie są "do końca" prawdą. Np. w PHP możesz (ale nie musisz) typować inputy/output funkcji, pola klas etc. Możesz wybrać zarówno w tym typowaniu podejście gdzie typy są zmieniane dynamicznie (czyli np. string "1" może być zamieniony na int 1), ale możesz też wybrać strict_type, gdzie takie rzeczy już powodują wyjątki.

Podobnie będzie z tymi błędami - możesz PHP ustawić tak aby do pewnego momentu ignorował błędy typu brak zmiennej był konwertowany na null etc, ale to jest wybór programisty w poważnych zastosowaniach raczej stosuje się "early fail" jako punkt wyjścia i nikt przy zdrowych zmysłach nie maskuje takich rzeczy. W poważnych projektach stosuje się tak jak we wszystkich innych językach na przykład statyczną analizę kodu, testy, pipeliny CI itp.

Oczywiście PHP nie jest bez wad - np. łatwiej o błąd bo w językach kompilowanych wiele błędów wychwytuje kompilator, a w PHP jak to się żartuje klient ;-) No ale też realnie patrząc jak ktoś dobrze pisze i używa analizy statycznej to praktycznie tak samo jakby używał kompilatora (oczywiście piszę to w zakresie wyłapywania błędów).

Co do projektów to podałeś Wordpress i MediaWiki - tą są przykłady bardzo złego użycia PHP. Oglądając kod WP ma się wrażenie, że to jakiś śmietnik z architekturą w stylu PHP sprzed 15 lat. Zresztą sporo takich potworków w PHP istniej - nawet najpopularniejszy obecnie framework jakim jest Laravel to taka trochę kupa jeśli chodzi o OOP. Obecni PHP pisze się zupełnie inaczej popatrz na projekty typu Symfony, Doctrine, Spryker.

Dzisiejszy PHP ma bardzo dobre (jak na język skryptowy) OOP, stosuje się w nim rzeczy poczynając od Dependency Injection a kończąc na architektura hexagonalna, CQRS, DDD itp. Pracuję w PHP z dużym Ecommerce i często mam styczność z zespołami Java/C#, w wielu firmach mieliśmy wspólne "tech talki" itp - stosujemy dokładnie ten sam zestaw dobrych praktyki i używamy podobnych narzędzi typu szyna danych, chmura, konteneryzacja, systemy kolejkowe itp tid.

Reasumując powiedziałbym, że w PHP da się pisać bardzo zły kod i faktycznie wiele osób taki kod pisze, ale sam język pozwala na pisanie dobrego kodu i ... wiele osób taki kod pisze. Ja sam odbieram PHP jako solidny język programowania i co ważne dynamicznie się rozwijający. Sam pracuję w nim dlatego, że jest mocno wykorzystywanych w ecommerce, a w tym się specjalizuję.

Dlaczego PHP jest popularny? Ostatnio czytałem fajny artykuł, o którym już tu kiedyś pisałem. Popularność zdobywają nie te języki, które są "najlepsze" tylko te, które w odpowiednim czasie dały ludziom to o co prosili, a potem potrafiły się "cywilizować" z czasem. Takimi językami są na przykład PHP, JS czy Java. Nie były to języki poprawne (i w sumie nadal nie są), ale po prostu potrafiły w pewnym czasie zaspokoić pewną potrzebę (w przypadku PHP język do szybkiego tworzenia aplikacji webowych), a potem rozwijać się wraz z potrzebami rynku. Hejterzy szczekają a karawana jedzie dalej. Dokładnie to samo jest na przykład z JS/Javą - co chwilę powstają nowe języki, które niby są lepsze, ale i tak Js/Java trzymają ogromną część rynku w swoich kategoriach i rozwijają się w tempie swoich użytkowników.

@hadwao: Co do wypowiedzi wyżej, zgadzam się.

Świat hejterów języków dzieli się na dwie kategorie:

• Ludzie którzy hejtują języki (albo technologię, bibliotekę, framework, cokolwiek), bo faktycznie zauważają w nim wady - to jest moim zdaniem spoko hejtowanie.
• Oraz ludzie którzy hejtują język (albo libkę, tech, framework), bo im się nie podoba - i to jest moim zdaniem nic nie warte.

Także jeśli z kimś rozmawiasz o krytyce jakiejś technologii, zorientuj się z jakim typem hejtera rozmawiasz.

hadwao napisał(a):

Dzisiejszy PHP ma bardzo dobre (jak na język skryptowy) OOP, stosuje się w nim rzeczy poczynając od Dependency Injection a kończąc na architektura hexagonalna, CQRS, DDD itp. Pracuję w PHP z dużym Ecommerce i często mam styczność z zespołami Java/C#, w wielu firmach mieliśmy wspólne "tech talki" itp - stosujemy dokładnie ten sam zestaw dobrych praktyki i używamy podobnych narzędzi typu szyna danych, chmura, konteneryzacja, systemy kolejkowe itp tid.

Reasumując powiedziałbym, że w PHP da się pisać bardzo zły kod i faktycznie wiele osób taki kod pisze, ale sam język pozwala na pisanie dobrego kodu i ... wiele osób taki kod pisze. Ja sam odbieram PHP jako solidny język programowania i co ważne dynamicznie się rozwijający. Sam pracuję w nim dlatego, że jest mocno wykorzystywanych w ecommerce, a w tym się specjalizuję.

Tu też się zgadzam, jeśli jest dobry programista, to prawda że może pisać dobry kod do pewnego stopnia. Jeśli osiągniemy już wysoki poziom w PHP, nie możemy iść dalej, tam gdzie moglibyśmy iść w lepszych językach.

Np to co mnie osobiście bardzo przeszkadza w PHP to jest brak typów contravariant. Dodatkowo, mega słabe jest też to że praktycznie cała biblioteka standardowa sieci w globalnym namespacie, że pomieszany jest camelCase z snak_case w nazwach funkcji, pół PHP operuje na wyjątkach, pół na warningach, i masa innych głupich rzeczy. Ale tak, to są wady języka; i można w nim napisać dużo gorsze gunwo jeśli się pisze okropny kod.

PS: "contravariant" znaczy że jak mamy klasę bazową class A {function f(): Parent; }, i dziedziczymy z niej class B extends A { function f(): Child; }, to nie można dodać : Child, musi być Parent, mimo że Child jest poprawnym typem Parent.

Z tego, co się orientuję, to PHP tym się wyróżnia, że ma wbudowany język szablonów.

Co masz na myśli. Są osobne systemy jak Twig, Blade, Smarty. Tylko, że w pewnym sensie PHP powstał jako taki twór pod szablony i po to był stworzony. Jak Rasmus Lerdorf go tworzył to nie myślał nawet o tym by to nazywać językiem. Miało mu to pomóc w pisaniu stronnw tym własnej. W HTML nie masz zmiennych i jeśli w obrębie jednej strony będziesz miał np. do wpisania nazwę firmy to łatwiej jest to zrobić poprzez zmienną i wyświetlić w HTMLu. Tym bardziej jeśli masz podpiąć bazę danych. Potem strona dla innej firmy, zmieniasz nazwę w jednym miejscu i voila. Historycznie w wywiadach autor wypowiadał się w ten sposób: "nie znam się na programowaniu a tym bardziej pisaniu języka. Jak będzie jakiś wyciek pamięci to zrestartuje webserwer co jakiś czas. PHP nie miał być językiem ale tak ewoluował".
Jak popatrzysz nawet na tutoriale do PHP 4 czy 5 to zobaczysz, że kod często wyglądał jak spagetti pomieszane z Htmlem. Debugowanie tego poprzez echo -wanie było ciężkie.
Porównując do Javy i programowania obiektowego np. taki kod wyglądał strasznie.
Od tamtej pory jednak minęło 15 lat lub nawet więcej.
Zresztą zobacz sobie na Wiki
https://en.m.wikipedia.org/wiki/PHP

W porównaniu do C czy C++ próg wejścia dla osoby bez wiedzy matatyczno programistycznej jest łatwy.
Jeśli nastolatek chciał napisać stronę i wyświetlić złączenie liczby i napisu nie musi nawet wiedzieć co to int i string. Zakresu zmiennych itp.

hadwao napisał(a):

Podobnie będzie z tymi błędami - możesz PHP ustawić tak aby do pewnego momentu ignorował błędy typu brak zmiennej był konwertowany na null etc, ale to jest wybór programisty w poważnych zastosowaniach raczej stosuje się "early fail" jako punkt wyjścia i nikt przy zdrowych zmysłach nie maskuje takich rzeczy.

Tak wszyscy twierdzą.

Więc co odpowiedzieć decydentom, dla których - jak pisałem - najgorsze, co się może zdarzyć, to crash programu lub odmowa zwrotu odpowiedzi (HTTP 500 lub coś w tym stylu) i w związku z tym naciskają, by program za wszelką cenę coś zwrócił, coś zapisał, nawet, jeśli to coś nie będzie do końca poprawne?

Byłem (i jestem) wściekły na to, że muszę to pisać w C#, bo domyślne zachowanie C# jest dokładnie przeciwne tego rodzaju wymogom.

I to właśnie było w ecommerce - chociaż dla mniejszej rybki.

YetAnohterone napisał(a):

hadwao napisał(a):

Podobnie będzie z tymi błędami - możesz PHP ustawić tak aby do pewnego momentu ignorował błędy typu brak zmiennej był konwertowany na null etc, ale to jest wybór programisty w poważnych zastosowaniach raczej stosuje się "early fail" jako punkt wyjścia i nikt przy zdrowych zmysłach nie maskuje takich rzeczy.

Tak wszyscy twierdzą.

Więc co odpowiedzieć decydentom, dla których - jak pisałem - najgorsze, co się może zdarzyć, to crash programu lub odmowa zwrotu odpowiedzi (HTTP 500 lub coś w tym stylu) i w związku z tym naciskają, by program za wszelką cenę coś zwrócił, coś zapisał, nawet, jeśli to coś nie będzie do końca poprawne?

EE??

Ale to jest zadanie servera który uruchamia aplikację, a nie aplikacji. Jak sobie postawisz nginx'a albo apache'a (coś musisz, co Ci odpali tego PHP, przecież nie odpali się sam), to tam są specjalne reguły co ma się stać jeśli apka się scrashuje, przestanie odpowiadać, zwróci kod błędu, etc.

@TomRiddle: jestem daleki od wmawiania komukolwiek, że PHP to najlepszy język programowania. Oczywiście, że ten język ma swoje oczywiste wady, które wynikają z kilku rzeczy:

• burzliwe początki i mix wielu różnych koncepcji - PHP po prostu powstał do zupełnie czegoś innego i potem chciał brać najlepsze wzorce z innych technologii, ale wyszło jak wyszło ;p
• jest to język skryptowy, więc trudno w nim oczekiwać wszystkiego co dają języki kompilowane

Dla mnie PHP to jest taki przykład języka "good enough", który wstrzelił się w swój czas i potrzeby, rozwinął ekosystem i rozwija się w kierunku aby dalej być "good enough". Dla tego co robię faktycznie w zupełności ten język wystarcza, choć nie przeczę, że wolałbym pisać np. w C# albo chociaż w Javie.

Co do tego "wywalania się aplikacji" to @YetAnohterone chyba bardziej pisze w kierunku tego, że np. na poziomie programu możesz ignorować pewne błędy - np. PHP pozwoli (przy odpowiednich ustawieniach) przekształcić brak zmiennej na na przykład pustego stringa i dalej działać jak by nigdy nic. No ale nikt tego w poważnych aplikacjach nie robi, bo to powoduje więcej kłopotów niż korzyści. Raczej wszędzie w dużych aplikacjach spotykam się z forsowaniem koncepcji early fail - szczególnie w PHP, gdzie inaczej taki błąd może wybić w zupełnie zadziwiającym miejscu i być trudny do znalezienia.

TomRiddle napisał(a):

EE??

Ale to jest zadanie servera który uruchamia aplikację, a nie aplikacji. Jak sobie postawisz nginx'a albo apache'a (coś musisz, co Ci odpali tego PHP, przecież nie odpali się sam), to tam są specjalne reguły co ma się stać jeśli apka się scrashuje, przestanie odpowiadać, zwróci kod błędu, etc.

No ale to nie rozwiązuje problemu. Program się scrashuje, ale dla tych danych wejściowych zwraca 500. Serwer uruchomi program ponownie i znowu dla tych danych wejściowych poleci 500. Jest bug, który deterministycznie w tym konkretnym edge case'u crashuje program. A za wszelką cenę ma nie być 500. Niech jedno pole zwróconego JSONa będzie błednie znullowane, niech drugie pole będzie zawierało śmieci, byleby był chociaż cień nadziei, że w pozostałych polach będzie coś sensownego. A jak poleci 500, to nic nie zwróci, czyli sytuacja najgorsza z możliwych.

Mając do wyboru zwrot danych połownicznie poprawnych albo brak zwrotu czegokolwiek naciskają na zwrot danych połowicznie poprawnych. Całość jest lepsza niż pół, ale jeśli całość jest nieosiągalna, to pół jest lepsze, niż zero. Taka jest ich mentalność.

YetAnohterone napisał(a):

TomRiddle napisał(a):

EE??

Ale to jest zadanie servera który uruchamia aplikację, a nie aplikacji. Jak sobie postawisz nginx'a albo apache'a (coś musisz, co Ci odpali tego PHP, przecież nie odpali się sam), to tam są specjalne reguły co ma się stać jeśli apka się scrashuje, przestanie odpowiadać, zwróci kod błędu, etc.

No ale to nie rozwiązuje problemu. Program się scrashuje, ale dla tych danych wejściowych zwraca 500. Serwer uruchomi program ponownie i znowu dla tych danych wejściowych poleci 500. Jest bug, który deterministycznie w tym konkretnym edge case'u crashuje program. A za wszelką cenę ma nie być 500. Niech jedno pole zwróconego JSONa będzie błednie znullowane, niech drugie pole będzie zawierało śmieci, byleby był chociaż cień nadziei, że w pozostałych polach będzie coś sensownego. A jak poleci 500, to nic nie zwróci, czyli sytuacja najgorsza z możliwych.

Mając do wyboru zwrot danych połownicznie poprawnych albo brak zwrotu czegokolwiek naciskają na zwrot danych połowicznie poprawnych. Całość jest lepsza niż pół, ale jeśli całość jest nieosiągalna, to pół jest lepsze, niż zero. Taka jest ich mentalność.

No to to wygląda jak bug w aplikacji, niezależy od języka w ogóle.

Napisz testy jednostkowe pod to, napraw buga, dodaj feature ze zwracaniem połowniczych danych.

Nie ma nic tutaj co wynika z PHP, szczerze mówiąc.

PS: Macie testy, prawda?

@YetAnohterone: wydaje mi się, że po prostu brakuje Wam kogoś, kto umie porozmawiać z klientem. Ja takich rozmów odbywam dziesiątku. Tu nie chodzi o technologię, tylko uświadomienie klienta co jest dla niego dobre a co złe.

hadwao napisał(a):

@TomRiddle: jestem daleki od wmawiania komukolwiek, że PHP to najlepszy język programowania. Oczywiście, że ten język ma swoje oczywiste wady, które wynikają z kilku rzeczy:

• burzliwe początki i mix wielu różnych koncepcji - PHP po prostu powstał do zupełnie czegoś innego i potem chciał brać najlepsze wzorce z innych technologii, ale wyszło jak wyszło ;p
• jest to język skryptowy, więc trudno w nim oczekiwać wszystkiego co dają języki kompilowane

Dla mnie PHP to jest taki przykład języka "good enough", który wstrzelił się w swój czas i potrzeby, rozwinął ekosystem i rozwija się w kierunku aby dalej być "good enough". Dla tego co robię faktycznie w zupełności ten język wystarcza, choć nie przeczę, że wolałbym pisać np. w C# albo chociaż w Javie.

No ja jestem podobnego zdania.

Wiadomo że w każdym języku da się napisać turbo słaby kod. Jak jesteś słabym programistą, to wszędzie napiszesz słaby kod. Więc mówienie że "PHP ssie bo ludzie w nim piszą słaby kod", nie jest argumentem. Na przykłąd Błąd SQLInjection da się zrobić w każdym istniejącym języku.

Z drugiej strony, prawdą jednak jest że w PHP istnieje wiele pułapek zastawianych na programistów, które nie istnieją w innych językach; oraz design samego języka jest gorszy niż innych.

YetAnohterone napisał(a):

TomRiddle napisał(a):

EE??

Ale to jest zadanie servera który uruchamia aplikację, a nie aplikacji. Jak sobie postawisz nginx'a albo apache'a (coś musisz, co Ci odpali tego PHP, przecież nie odpali się sam), to tam są specjalne reguły co ma się stać jeśli apka się scrashuje, przestanie odpowiadać, zwróci kod błędu, etc.

No ale to nie rozwiązuje problemu. Program się scrashuje, ale dla tych danych wejściowych zwraca 500. Serwer uruchomi program ponownie i znowu dla tych danych wejściowych poleci 500. Jest bug, który deterministycznie w tym konkretnym edge case'u crashuje program. A za wszelką cenę ma nie być 500. Niech jedno pole zwróconego JSONa będzie błednie znullowane, niech drugie pole będzie zawierało śmieci, byleby był chociaż cień nadziei, że w pozostałych polach będzie coś sensownego. A jak poleci 500, to nic nie zwróci, czyli sytuacja najgorsza z możliwych.

Mając do wyboru zwrot danych połownicznie poprawnych albo brak zwrotu czegokolwiek naciskają na zwrot danych połowicznie poprawnych. Całość jest lepsza niż pół, ale jeśli całość jest nieosiągalna, to pół jest lepsze, niż zero. Taka jest ich mentalność.

Powiedz im, ze pol to tez np. wyslanie klientowi zamowienia ale brak zchargowania oplaty za towar. Polowiczny sukces :)

Kiedyś w PHP była dyrektywa "@" poprzedzałeś tym funkcję i były ignorowane błędy. Do tej pory jeszcze potrafię to gdzieś zobaczyć na Stacku czy w tutorialach. Czyli jest jak piszesz, strona nie wyświetli 500 ale nie wyświetli właściwej treści.
No i takie kwiatki się ciągną za PHPem i będą nawet i kolejne X lat.

jurek1980 napisał(a):

Kiedyś w PHP była dyrektywa "@" poprzedzałeś tym funkcję i były ignorowane błędy. Do tej pory jeszcze potrafię to gdzieś zobaczyć na Stacku czy w tutorialach. Czyli jest jak piszesz, strona nie wyświetli 500 ale nie wyświetli właściwej treści.

That's not true.

To co robił @ to ignorował rzucane notice i warning. Inne rzeczy, takie jak np Fatal Error albo Exception nie reagują na @. Prawdą jest że wyjątki to dość nowy wymysł, ale fatal errory są tak stare jak sam PHP :D

Także @ działa tak "połowicznie".

Specyfika PHP jest taka, że jest to jezyk programowania tani i szybki. Hostowanie strony kosztuje grosze, szybki w pisaniu co również przekłada się na roboczo godziny, które się po prostu opłacają firmom.
Tani + szybki = bajzel ... i tutaj jest wyzwanie znaleźć osoby, które tego nie narobią. Prawdziwych seniorów dbających o jakość kodu w PHP jest tyle co kot napłakał. Wiąże sie to ze specyfiki branży także. Zrobić klientowi stronę, skaoswac go i zapomnieć o nim. Robi się to w PHPie częściej niż w Javie bo zobisz to szybciej.

A co do hejtu w internecie na ten język to powiem tak. Hejtują go osoby, które albo go nigdy nie używały albo pisały w nim 10 lat temu robiąć var_dumpy jako debug i myślą, że tak wyglada to do dziś.
Jeżeli przeszedłbyś się do firmy, która ma własny produkt napisany na PHP i zobaczył jak sie przy nim pracuje to byś powiedział, że niczym się to nie różni od pracy w Javie, Rubym i innym języku.

Podsumowując .. dobra firma z dobrym programistami robi duże dobre i porządne projekty pisane w PHPie. Lecz takich jest bardzo mało na rynku. Wiekszość to software housy z doktryną "gwarancja do bramy i dalej sie nie znamy" i tak wygląda ich kod.

dervill napisał(a):

A co do hejtu w internecie na ten język to powiem tak. Hejtują go osoby, które albo go nigdy nie używały albo pisały w nim 10 lat temu robiąć var_dumpy jako debug i myślą, że tak wyglada to do dziś.
Jeżeli przeszedłbyś się do firmy, która ma własny produkt napisany na PHP i zobaczył jak sie przy nim pracuje to byś powiedział, że niczym się to nie różni od pracy w Javie, Rubym i innym języku.

Tak.

Co nie zmienia faktu że w Rubym i Pythonie ma masz jednej funkcji w snake-case, jak array_push()/parse_str(), a innej w camel-case jak htmlEntities()/addSlashes()/strToLower(). Niektóre są nawet frankenstainem: mb_strToLower(). W Ruby i Pythonie masz też wszystko w przestrzeniach nazw, gdzie w PHP wszystko jest w globalu. W Ruby i Python'ie nie ma Fatal Errorów, wszystko możesz złapać.

dervill napisał(a):

Zgadza się, jest to pomału ujednolicane z nowymi wersjami PHPa bo są to zaleciałości z leciwych wersji.

Nie, to nie prawda. Funkcje w globalnym namespace'ie w PHP 8.1 są dokładnie takie same jak w PHP 5.3 jeszcze. PHP ich nie zmieni, bo byłaby to zbyt duża compatibility break.

Jednak z drugiej strony powiem też przysłowiem "złej baletnicy przeszkadza rąbek u spódnicy"

Nie rozumiem, jak mam się odnieść do tej odpowiedzi?

Czy oznacza to, że jeśli pracuję/piszę w jakimś języku, to nie powinienem dostrzegać w nim żadnych wad? Powinienem go uważać za idealnym język? Bo jeśli znajdę jakąś drobną wadę, i ją opiszę, to będę złą baletnicą której przeszkadza rąbek?

Zrobiłem taki temat
Skąd wzięła się nienawiść do PHP-powców?
Może Cię zainteresuje

@TomRiddle:

Czy oznacza to, że jeśli pracuję/piszę w jakimś języku, to nie powinienem dostrzegać w nim żadnych wad? Powinienem go uważać za idealnym język? Bo jeśli znajdę jakąś drobną wadę, i ją opiszę, to będę złą baletnicą której przeszkadza rąbek?

Nic takiego nie napisałem. Raczej chciałem przekazać, że nieład we globalnych funkcjach i to jak się nazywają nie powinien stanowić przeszkody w pisaniu dobrego kodu. Nie ma języka ideanego i wszyscy o tym wiemy. Dobry programista napisze dobry kod i łatwy w utrzymania nawet w starym PHP. Słaby programista zrobi burdel nawet w Javie, C# czy innym "super" języku.
Także fakt PHP ma dużo rzeczy, które kłują w oczy ale czy te rzeczy deskwalifikują go w pisaniu zaawansowanych aplikacji? Na to już niestety trzeba odpowiedzieć sobie samemu uwzględniając koszty/rozwój/próg wejścia/przyszłość/opłacalność itp itd.

dervill napisał(a):

@TomRiddle:

Czy oznacza to, że jeśli pracuję/piszę w jakimś języku, to nie powinienem dostrzegać w nim żadnych wad? Powinienem go uważać za idealnym język? Bo jeśli znajdę jakąś drobną wadę, i ją opiszę, to będę złą baletnicą której przeszkadza rąbek?

Nic takiego nie napisałem. Raczej chciałem przekazać, że nieład we globalnych funkcjach i to jak się nazywają nie powinien stanowić przeszkody w pisaniu dobrego kodu. Nie ma języka ideanego i wszyscy o tym wiemy. Dobry programista napisze dobry kod i łatwy w utrzymania nawet w starym PHP. Słaby programista zrobi burdel nawet w Javie, C# czy innym "super" języku.
Także fakt PHP ma dużo rzeczy, które kłują w oczy ale czy te rzeczy deskwalifikują go w pisaniu zaawansowanych aplikacji? Na to już niestety trzeba odpowiedzieć sobie samemu uwzględniając koszty/rozwój/próg wejścia/przyszłość/opłacalność itp itd.

Ja się tylko odnoszę do tego co napisałeś, że "Złej baletnicy przeszkadza nawet rąbek u spódnicy", w kontekście tego że wyliczyłem kilka wad PHP.

Zupełnie nie zgadzam się z taką odpowiedzią - jest nieadekwatna. Zasugerowałes, że ponieważ wyliczyłem wady PHP, to znaczy że mi przeszkadzają w pisaniu dobrego kodu w PHP, tak jakbym był złą baletnicą. Nie przeszkadzają mi, wiem jak sobie z nimi radzić, i radzę sobie z nimi bardzo dobrze; wyliczyłem je, ponieważ jestem świadom, że to są wady, i lepiej by było gdyby były usunięte.

No i super, właśnie o to chodzi. Być świadomym wad języka w którym się pisze i tak robić by ich unikać. Tak by przyszłym pokoleniom zostawić w miarę łatwy i zrozumiały kawałek kodu :)
Zgadzam się z Tobą @TomRiddle: , powinno zostać to zaorane i któraś wersja PHP powinna zerwać wsteczną kompatybilność z tymi przestarzałymi tworami. Może i tego się doczekamy, kto wie bo twórcy PHPa ostatnio się bardziej uaktywnili :)
No nic, nie smęcę już dalej ale pamiętajcie wszyscy .. nie język tworzy zajebiste projekty a programista, który je pisze ;)

Czy wiecie, jak wygląda kwestia naprawiania błędów, usuwania niespójności w języku itd? Ktoś odpowiedzialny za rozwój pracuje nad tymi kwestiami?

Obecnie nad rozwojem PHP ma czuwać PHP Foundation z takimi firmami jak na przykład JetBrains, Zend, Symfony. Więcej informacji znajdziesz tutaj: https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/?source=google&medium=cpc&campaign=14335686378&gclid=Cj0KCQiA2ZCOBhDiARIsAMRfv9KrdqtZXKYTOm5mtCnJXkVtoUwOBy7eBd1ROrhc5mrMZCLnPczo-04aAoNvEALw_wcB

Słyszałem o tej akcji, lecz ciekaw jestem czy ktoś jest obeznany ze szczegółami odnośnie prac nad językiem. Co jest aktualnie realizowane, jakie są plany, czy jest chęć zrywania kompatybilności na rzecz wyeliminowania zaszłości i ile tak właściwie osób rozwija PHP?

Przecież sam możesz sprawdzić jak wygląda lista RFC:
https://wiki.php.net/rfc
Ba możesz nawet sam jakieś założyć.
Co do ilości osób, to jednak jest to OS i nie trzeba liczyć na to, że zawsze będzie to stała liczba osób na etacie.