On 2014-03-30 20:40, Wojciech Muła wrote:
> Sam zacząłeś od wymyślonego przykładu z jakimś grafikiem dla sprzątaczek.
> Podałem Ci, jaki napotkasz problem *alogrytmiczny*, nawet w tak pozornie
> prostym zastosowaniu.

No i dlatego dalej pytam: w zym PHP jest lepszy aby ten problem rozwiązać?

>> Własnie zauważyleś za złożone problemy nie mają uniwersalnych rozwiązń.
> To nie jest trudny problem, już sama klasa złożoności czasowej powinna
> sugerować, jakie jest rozwiązanie. Da się rozwiązać bez boosta,
> bez żadnej biblioteki, nawet w PHP-pie, czy javascripcie.

I znowu to samo: kazdy język programowania pozwala na rozwiązanie
dowolnego problemu rozwiązywalnego w innym. Thak You Captain Obvious.

>> A w wątku rzecz w tym że PHP nie ma żadnych rozwiązań w standardzie,
>> nawet uniwersalnych. NAWET.
> W tym wątku była mowa, że programista PHP nic nie musi umieć.

Ja nie rozmawiam o umiejętnościach programistów tylko zadaje proste
pytanie: co ma PHP co spowodowało że bank wybrał go do jakiegoś tam
zadania w środku które było skomplikowane albo obliczeniowo albo
algorytmicznie? Co ma PHP czego nie ma <cokolwiek>?

>> A czemu nie ma? I dlaczego powinienem workaroundowac problemy braku
>> czegoś w designie tandemu apache/php/mysql?
> Bo HTTP to protokół bezstanowy.

No właśnie, workaround z ciasteczkami to "załatwia" w typowy dla PHP sposób.

> Nie ma znaczenia, czy na końcu jest PHP,
> Python, skrypt shellowy CGI, itd. - będzie dokładnie ten sam problem.

Nie. Problemem PHP jest serializacja stanu (albo w ciasteczka albo w
db). Jeśli PHP miałby *żywy* kontekst po stronie serwera wiele rzeczy
nie wymagało by serializacji.

>> A kto tu twierdzi że C++ jest jakimś wzorcem?
> Jako język wieloparadygmatowy

Inne paradygmanty stosuje się za pomocą metaprogramowania albo
bibliotek. IMHO nie jest wieloparadygmatowy nawet przy bardzo
optymistycznym podejściu.

>, przemysłowy, z wieloletnią historią
> i ciągle rozwijający się -- to dobre odniesienie do innych języków.

A fuj. To pokraczny język, który na prostowanie jest za stary.

>>>> Oni też potrafili się wykłucać że uniwersalny kontener na wszystko
>>>> jest lepszy niż specjalizowane o znanych złożonościach "bo kto
>>>> obrabia więcej niż 200 wpisów".
>>> Akurat dość rozsądny argument. Przywołaj proszę jakiś mniej sensowny.
>> Powiedz że żartujesz... to idealnie pasuje do profesjonalnego systemu
>> zarządzania windykacjami w banku.
> No jeżeli rzeczywiście nie obrabia się więcej niż "200 wpisów"

Czyli jednak dyżury sprzataczek w tym banku zrobili?

, nie
> ma się specjalnych wymogów (czas, czy pamięć), to te uniwersalne są
> lepsze.

Bo programista nie wie czym się rózni lista od wektora? A no to są
lepsze, faktycznie.

> A nawet są lepsze w tym sensie, że już działają i ktoś je
> przetestował.

:D PHP i testowanie :)

> Ale oczywiście zgadzam się, że jeśli są szczególne
> potrzeby, to trwanie przy uniwersalnych rozwiązaniach nie jest dobre.

Ależ uniwersalne kontenery nie są *trywialne*. Nic zazwyczaj nie
gwarantują poza tym że hello world zadziała. Czyli masz śmieciowy język
ktory w poważnych zastosowaniach odpada na starcie bo ma tajemnicze
uniwersalne implementacje o których niewiele wiadomo poza tym że dają
radę dla 200 wpisów.

>> Ale jak ja mam mieć dłuższą przygode? Sugerujesz że mam się umartwiać
>> nad PHP i dopiero dostrzegać błedy po 10 latach? Miej że litość, życie
>> jest za krotkie na babranie się w g...
> Nic nie musisz, tylko wydawanie kategorycznych sądów o teraźniejszości
> na podstawie doświadczeń sprzed kilku lat jest trochę bez sensu.

Jesli w ciagu kilku lat PHP zmienil się nie do poznania to nie jest PHP
tylko coś innego. Zmienił się?

>> Ustawienia phpini w apache mają wpływ na runtime PHP. Jak chcesz różne
>> to ... no cóż ...
> To są ustawienia serwera, a nie przeglądarki. Pomieszałeś. :)

Nie pomieszałem.

>>> Sorry, ale nie dostaniesz dostępu do bankowego intranetu. Ja też już
>>> nie mam szans, więc nie zadowolę nikogo w tym wątku.
>> Znaczy że były tam te krzywe rownania
> Były.

I 200 wpisów w bazie danych?

>> czy nie było i mowisz o jeszcze jednym z miliona widoku na bazę danych?
> A to też było, nie przeczę.

Dalej nie wiem co kogo podkusiło że PHP nadaje się do obrabiania równań
nieliniowych w systemie bankowym. Tym bardziej że większe obliczenia
powodują że PHP umiera. Gdzieś kiedyś czytałem że PHP obok TCL to dwa
najgorsze języki do obliczeń - bo wolne.

Tam musi być drugie dno, w tym banku. Mam ciągle nadzieję że to nie jest
"student za tysiaka da radę" ani też "nie mam czsu, muszę jechać beemką
na myjnię, a ten projekt to napiszcie w byle czym".