Autor Wątek: Czy PHP jest dobre  (Przeczytany 29257 razy)

Offline Karol

  • Użytkownik

# Grudzień 01, 2014, 14:50:19
//Wydzielono z tematu [PHP] Pytanie-ciekawostka. Artykuł o którym mowa znajduje się pod adresem http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ -Xirdus

ps. nie zgodzę się, że PHP jest złe bo złe czy pełne dziwności - proszę o uzasadnienie.
Xirdus podał przecież, proszę uważnie przeczytać ten artykuł, wiem, że długi, ale warto.
« Ostatnia zmiana: Grudzień 01, 2014, 16:18:32 wysłana przez Xirdus »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline conx

  • Użytkownik

# Grudzień 01, 2014, 14:54:36
Przepraszam, czy to jest praca naukowa?? Nawet nie jest podpisany z imienia i nazwiska autora.
To jest jakiś artykuł blogera- dlaczego to ma być wykładnia?

ps. nie chce już dalej brnąć w tą dyskusję ponieważ jest bezproduktywna. Dodam tylko: PHP zrobione przez ludzi i dla ludzi a więc nie jest doskonałe.
« Ostatnia zmiana: Grudzień 01, 2014, 15:08:30 wysłana przez conx »

Offline Xirdus

  • Redaktor

# Grudzień 01, 2014, 15:22:12
Przepraszam, czy to jest praca naukowa?? Nawet nie jest podpisany z imienia i nazwiska autora.
To jest jakiś artykuł blogera- dlaczego to ma być wykładnia?
Bo przedstawia konkretne fakty które można zweryfikować?

Offline Karol

  • Użytkownik

# Grudzień 01, 2014, 15:26:40
Przepraszam, czy to jest praca naukowa?? Nawet nie jest podpisany z imienia i nazwiska autora.
To jest jakiś artykuł blogera- dlaczego to ma być wykładnia?
lolwtfomfgdafaq?!
Nieważne kto napisał, liczy się treść, obiektywne spojrzenie i rozum, aby wyciągnąć pewne wnioski i samemu ocenić sytuację, ale Tobie pewnie bardziej by pasowało jakby Dżoanna Krupa napisała o Tap PHP Programmer i to by była wtedy wykładnia? Super podejście do życia.

Ale rozumiem, brak kontrargumentów więc trzeba coś bez sensu wymyślić, żeby odbić piłeczkę (choć z takim argumentem spotykam się pierwszy raz :D idąc tym tokiem rozumowania to po co się udzielasz na forach skoro nikt tutaj się nie podpisuje imieniem, ani nazwiskiem, nawet Ty - więc Twoje wypowiedzi są bez znaczenia i nic nie wnoszą, mogę je śmiało odrzucić bez czytania i tak też będę czynił od teraz).

Masz rację, że ta dyskusja jest bezproduktywna jeżeli Twoją odpowiedzią na konkretne argumenty jest "nie, bo nie".

Offline conx

  • Użytkownik

# Grudzień 01, 2014, 15:54:31
Ok, zweryfikujmy kilka wspólnie:
new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language—in C++ most of it’s about compilation and compile-time name resolution.Chyba bez tego ciężko pisać w OOP ??!! Nie podebrano tego z Javy... tylko właśnie z C++. Zresztą Java ma wiele zapożyczeń z Pascala/Delphi, C++... Tylko to nic nie znaczy.

There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
To źle? Takie było założenie. Zresztą użycie niezadeklarowanej zmiennej wywala NOTICE!

(integer) is a synonym for (int). There’s also (bool)/(boolean) and (float)/(double)/(real).Programista C czy Pascal ... nie musi zmieniać swoich przyzwyczajeń. Właściwie, język jest bez silnego typowania!! To źle?

include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.Tak właśnie miało być! A właściwie to nie prawda!! ..."use".

There’s redundant syntax for blocks: if (...): ... endif;, etc.Jesli kiedyś pracowaleś z widokami html wiesz, ze to bardzo dobre rozwiązanie. Znam gorsze ..JSP!


A language must be consistentA C++ jest?? Co kilka lat kierunek zmienia się o 180stopni.

No Unicode support. Only ASCII will work reliably, really. There’s the mbstring extension, mentioned above, but it kinda blows.Bzdura!

Większość swoich twierdzeń autor opiera na tym, że coś jest w Perl/Python lub Java a nie ma w PHP, bardzo wiele z jego tez to kwestia gustu. Ma w kilku miejscach racje ale wiele z tych problemów istnieje w innych językach. Nadal nie uważam by PHP było gorsze od np Pythona/Javy do backendu stron www. Dziwi mnie też, że za słabe umiejętności programistów wystawia się ocenę językowi. Perl jako wzór ...ktory nadaje tylko do pisania małych skryptów proceduralnych.

Moją odpowiedzią na bezzasadny atak jest: najpierw sam sprawdź zanim skrytykujesz.

Pozdrawiam,
Rafał Leśniewski
« Ostatnia zmiana: Grudzień 01, 2014, 16:15:44 wysłana przez conx »

Offline Xender

  • Użytkownik

# Grudzień 01, 2014, 16:17:16
Przepraszam, czy to jest praca naukowa?? Nawet nie jest podpisany z imienia i nazwiska autora.
To jest jakiś artykuł blogera- dlaczego to ma być wykładnia?
Świat nie kończy się na pracach naukowych.
To spisane argumenty, które składają się na obiegowa opinię "LOLPHP" - pytałeś o przykłady, nie o pracę naukową.
To, czy się z tym zgadzasz, czy nie, to Twoja sprawa. Ale dostałeś to o co pytałeś, więc bez kręcenia nosem, bo aż się prosi o przechodzenie do niezbyt przyjemnych analiz ("o, jest bardzo przywiązany do PHP i każdą krytykę tego języka będzie w jakiś sposób oddalał, zamiast zaakceptować, że dziwadełka w tym języku to nic innego, niż dziwadełka").

PHP to zwykły język skryptowy bez twardego typowania do stronek www na bacendzie. Tylko tyle i aż tyle
1. Nie znam terminu "twarde typowanie".
Znam kilka ortogonalnych (niezależnych lub słabo zależnych od siebie) typowania:
- Statyczne vs. dynamiczne (compile-time vs. runtime).
- Silne vs. słabe ("dzikie" implicite casty lub ich brak).
- Deklaratywne vs. duck-typing.
https://en.wikipedia.org/wiki/Strong_and_weak_typing
https://en.wikipedia.org/wiki/Type_system#Type_checking

Tak, to jest temat rzeka, ale właśnie te subtelne różnice powodują, że w różnych tzw. skryptowych językach programowania z typowaniem dynamicznym efekty są diametralnie inne:
- Python - Generalnie czysty, silny system typowania, z widoczną preferencją ducktypingu.
- Javascript - Zawiera trochę dziwadełek słabego typowania*, ale generalnie da się żyć.
- Perl - Uwaga na kontekst/sigile (rozróżnienie typów skalarnych/listowych/mapowych) - można by to uznać nawet za typowanie bardziej statyczne, niż w pozostałych wymienionych tu językach, jednak do tej konwencji trzeba się przyzwyczaić. W ramach skalarów - kilka dziwadełek, jak konwersja string<->liczba w zależności od użytych operatorów (ale to znów można traktować jako coś bardziej statycznego), więc jedyny rodzaj dziwadełek porównywalnych z pozostałymi językami tutaj to traktowanie stringa "0" jako wartość fałszywą (każdy inny niepusty string - mp. "00" - będzie prawdziwy).
- Shell (rodzina sh) - stringly-typed - AFAIK wszystkie zmienne skalarne to stringi, obliczenia matematyczne wykonuje się przez wejście do specjalnego trybu, wynik przy podstawieniu do komendy luv zapisaniu do zmiennej znów jest konwertowany na string.
- PHP - mnóstwo dziwadełek słabego typowania - dopóki porównując stringa z intem string jest konwertowany na inta i potem oba są porównywane, to jest jeszcze OK. Ale jeśli przy porównywaniu 2 stringów czy innych 2 wartości tego samego typu, w wypadku niepowodzenia podstawowego porównania obie wartości są konwertowane do zupełnie innego typu (niezwiązanego z żadną z wartości), to robi się bardzo nieintuicyjnie.
Takie rzeczy są potem raportowane jako bugi w języku, na co developerze odpowiadają, że przecież jest operator === - mój "ulubiony" kontrargument. No to ja pytam - po co w takim razie istnieje operator ==? IMHO jest na tyle nieprzewidywalny, że lepiej go unikać, a gdyby go usunąć z języka i przepisać kod używający go w sposób explicite mówiący, jaki jest cel porównania - usunęłoby się sporo błędów, w tym potencjalnych błędów bezpieczeństwa (no dobra, opieranie bezpieczeństwa na MD5 to i tak nienajlepszy pomysł, ale to z innych względów).

* Przy czym kilka z tych wymienionych w filmiku to tak naprawdę dziwadełka parsera/składni, a nie systemu typów - te zaczynające się od "{} + "

2. Co to jest "typownie na backendzie"? o_O
« Ostatnia zmiana: Grudzień 01, 2014, 16:20:09 wysłana przez Xender »

Offline conx

  • Użytkownik

# Grudzień 01, 2014, 16:29:20
2. Co to jest "typownie na backendzie"? o_O

PHP to zwykły język skryptowy bez twardego typowania do stronek www na bacendzie.Wiec PHP jest bez typowania a backend to serwerowa strona webaplikacji, frontend np to html. Coś jest niejasne??

Offline Xirdus

  • Redaktor

# Grudzień 01, 2014, 16:35:08
Chyba bez tego ciężko pisać w OOP ??!!
JS daje radę. Python też. Zauważ że i te dwa, i PHP są skryptowe.

To źle? Takie było założenie.
O tym właśnie ten artykuł, że podjęto wiele złych (wg autora) decyzji projektowych opierając się na złych założeniach.

Tak właśnie miało być! A właściwie to nie prawda!! ..."use".
Patrz wyżej. No i "use" importuje namespace, nie moduł. To różnica. include dalej jest potrzebny.

A C++ jest?? Co kilka lat kierunek zmienia się o 180stopni.
Rozmawiamy o PHP.

No Unicode support. Only ASCII will work reliably, really. There’s the mbstring extension, mentioned above, but it kinda blows.Bzdura!
Trochę niżej masz: "despite the proliferation of case-insensitive versions of functions, not one of them will consider é equal to É". Czyli jednak nie bzdura.

Nadal nie uważam by PHP było gorsze od np Pythona/Javy do backendu stron www.
Twój wybór. Moim celem nie jest odciągnięcie nikogo od pisania w PHP - po prostu dużo ludzi nie lubi PHP z bardzo konkretnych powodów :) (mysql_real_escape_string_for_good_this_time_i_promise())

Perl jako wzór ...ktory nadaje tylko do pisania małych skryptów proceduralnych.
A dlaczego to? Uargumentuj jakoś swoją wypowiedź! :P

Offline conx

  • Użytkownik

# Grudzień 01, 2014, 16:55:17
Cytat: conx w Dzisiaj o 14:54:31
Perl jako wzór ...ktory nadaje tylko do pisania małych skryptów proceduralnych.
A dlaczego to? Uargumentuj jakoś swoją wypowiedź! :P

The Perl languages borrow features from other programming languages including C, shell scripting (sh), AWK, and sed.[8] They provide powerful text processing facilities without the arbitrary data-length limits of many contemporary Unix commandline tools,[9] facilitating easy manipulation of text files. Perl 5 gained widespread popularity in the late 1990s as a CGI scripting language, in part due to its parsing abilities.[10]

I wg mnie najlepiej nadaje się właśnie jako skrypty wspierające np prace admina servera.

Trochę niżej masz: "despite the proliferation of case-insensitive versions of functions, not one of them will consider é equal to É". Czyli jednak nie bzdura.Ja się cieszę,  że w nazwach metod nie mam Chinskich znaków. Natomiast w PHP można pracować na stringach unicode!

JS daje radę. Python też. Zauważ że i te dwa, i PHP są skryptowe.JS to język funkcyjny - ta obiektowość to trochę na wyrost. Wiem są różne triki z anonimowymi funkcjami...ale czy to jest obiektowość?  Python - nie wiem.

Patrz wyżej. No i "use" importuje namespace, nie moduł. To różnica. include dalej jest potrzebny.
No możliwe, ja w używając Zend 1/2 już od kilku lat nie widziałem includa.

Dzięki
« Ostatnia zmiana: Grudzień 01, 2014, 17:09:18 wysłana przez conx »

Offline Xirdus

  • Redaktor

# Grudzień 01, 2014, 17:18:02
The Perl languages borrow features from other programming languages including C, shell scripting (sh), AWK, and sed.[8] They provide powerful text processing facilities without the arbitrary data-length limits of many contemporary Unix commandline tools,[9] facilitating easy manipulation of text files. Perl 5 gained widespread popularity in the late 1990s as a CGI scripting language, in part due to its parsing abilities.[10]

I wg mnie najlepiej nadaje się właśnie jako skrypty wspierające np prace admina servera.
Nie powiedziałeś nic na temat dlaczego NIE nadaje się do większych rzeczy.

Ja się cieszę,  że w nazwach metod nie mam Chinskich znaków.
Chodziło nie o nazwy tylko parametry funkcji.

Natomiast w PHP można pracować na stringach unicode!
Tylko dzięki rozszerzeniu mb. Standardowe funkcje dalej robią z UTF-8 sieczkę.

JS to język funkcyjny
HAHAHAHAHAHAHAHAHA ekhem... Przepraszam, nie mogłem się powstrzymać :) JS jak najbardziej jest językiem obiektowym, opartym na prototypach zamiast klas. Radzę doczytać co to w ogóle znaczy język obiektowy i język funkcyjny, bo właśnie pokazałeś że nie wiesz ani jednego ani drugiego. Bez obrazy - każdemu może zdarzyć się palnąć głupstwo. Ale to było po prostu epickie :)

A, i do cytowania służy znacznik [quote], nie [code]. Tak na przyszłość.

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

  • +1
# Grudzień 01, 2014, 17:36:58
PHP jest źle zaprojektowany. Wiele rzeczy w nim działa po "studencku" (np. wywołanie funkcji z new w argumencie do niedawna skutkowało błędem - np. funkcja(new Vector(1.0,3.0));, albo spróbujcie sobie wypisać wartości: print 4!==4; print 4===4; -> dla tego pierwszego printa nie dostaniemy nic na ekranie!). Nowych poważnych projektów nie warto w nim zaczynać. Projekty, które już w nim powstały, szkoda przepisywać (koszty), ale nowe projekty stanowczo odradzam. Mam trochę komercyjnego doświadczenia w PHP i poczułem jego słabości na własnej skórze ;) Sama możliwość mieszania kodu PHP z HTML już się prosi o pisanie kodu w architekturze spaghetti ;) A jak dochodzi do wymiany programistów w projekcie (ktoś odejdzie, przyjdzie jakiś stażysta itp.), to aż się prosi o porażkę. Nie mam na myśli, że celowo mieszam kod HTML z PHP, ale kiedy przyjdzie pracować nad dawno rozpoczętym, niedopilnowanym projektem, to zazwyczaj trzeba trzymać się tej konwencji (bo nie ma kasy/czasu na przerobienie), a to jest bardzo nieprzyjemne i błędogenne :(

Python już jako język skryptowy jest znacznie lepiej przemyślany. Ale i tak jeśli miałbym wciąż pracować w webie komercyjnie, to wybrałbym coś pokroju Javy. Dużo łatwiej utrzymać tam porządek (pilnuje programistę ;) ) i łatwiej debugować.

JavaScript też ma trochę rzeczy, których konsekwentnie specyfikacja musi się już trzymać (bo inaczej część stron wysiądzie). Zobaczcie np. numerowanie miesięcy od 0 do 11, co daje nam potencjalną niezgodność z backendem. Dlatego lepiej JS nie używać na czysto, tylko przez jakiś dobry framework.
« Ostatnia zmiana: Grudzień 01, 2014, 17:44:05 wysłana przez JasonVoorhees »

Offline conx

  • Użytkownik

# Grudzień 01, 2014, 17:44:50
PERL:
Pewnie ponownie Cię rozbawię ale nie uważam nawet Perla za język obiektowy - ponoć jest wsparcie ale dla mnie to proceduralny język. Jest nieczytelny kod, problemy z dokumentacją.

Unicode:
No zgadza się, dzięki, mb - co nie zmienia faktu - wsparcie jest.

JS:
Ja się nie obrażam, bo o co? Co to znaczy obiektowy/funkcyjny - no widocznie dla nas różne rzeczy. Dla mnie JS jest funkcyjny a PERL proceduralny.
Wybacz te triki mnie nie przekonują.

A, i do cytowania służy znacznik [quote], nie [code]. Tak na przyszłość.Wybacz, mam taką manierę, stosuję  zamiennie.


Offline Xirdus

  • Redaktor

  • +2
# Grudzień 01, 2014, 18:03:27
PERL:
Pewnie ponownie Cię rozbawię ale nie uważam nawet Perla za język obiektowy - ponoć jest wsparcie ale dla mnie to proceduralny język. Jest nieczytelny kod, problemy z dokumentacją.
Być może. Nie znam Perla.

JS:
Ja się nie obrażam, bo o co? Co to znaczy obiektowy/funkcyjny - no widocznie dla nas różne rzeczy. Dla mnie JS jest funkcyjny a PERL proceduralny.
To nie chodzi o to co dla nas znaczy język obiektowy, tylko jaka jest książkowa definicja. Języki obiektowe to takie które pozwalają pisać OOP-owo - na co składają się obiekty oraz polimorfizm. Tyle starczy. Klasy, dziedziczenie itd. to tylko jeden ze sposobów realizacji tegoż. Język funkcyjny to taki, w których funkcje są funkcjami matematycznymi - dla tych samych danych wejściowych będzie zawsze ten sam wynik, przy czym dana funkcja operuje tylko i wyłącznie na swoich danych wejściowych. Implikuje to (w uproszczeniu) brak jakichkolwiek zmiennych. W JS nie istnieje chyba możliwość pisania czysto funkcyjne, choć niektóre wzorce funkcyjne można wykorzystywać (tak jak w C++).

Offline Dab

  • Redaktor
    • blog

  • +5
# Grudzień 01, 2014, 18:13:56
Panie moderatorze to forum i cały warsztat jest na "lolphp!"

Tak, ale Warsztat się wstydzi i przeprasza. :(

Offline Xender

  • Użytkownik

  • +1
# Grudzień 01, 2014, 19:15:09
Sorry, wątek eksplodował za szybko, więc TL;DR, ale akurat czekałem na okazję, żeby zalinkować gdzieś jeden obrazek, i okazja się trafiła.

Chyba bez tego ciężko pisać w OOP ??!!


"OOP" ostatnimi czasy stało się chyba modnym sloganem, który stracił sporo ze znaczenia.

Chyba lepiej pisać programy używając środków odpowiednich do tego, żeby kod był czytelny i program spełniał swoje zadanie, a nie zastanawiać się, czy dana technika jest trendy.