On 24/03/2014 18:39, Sebastian Biały wrote:
>
>> No to mówię, że tak nie jest, że
>> można robić zaawansowane rzeczy
>
> PO CO? Przeciez w PHP nie znajdziesz nawet podstawowych zagadnień z

Abstrahując od PHP, dużo rzeczy robi się po prostu dlatego, że
przesadzenie dużego skomplikowanego systemu na inną technologię potrafi
być masakrycznie kosztowne. Sam widziałem duży system dla instytucji
finansowych (i nie do ustalania tam grafiku sprzątaczek) napisany w
BASICu, i to nie w żadnym Visual, tylko takim old school z GOSUB.
Producent tego oprogramowania kombinował swego czasu, czy nie przesadzić
klientów na produkt alternatywny, ale po paru podejściach do tematu
spasował właśnie ze względu na koszty i ryzyko.

do góry

Witam, dnia Tue, 25 Mar 2014 23:34:18 +0000
Andrzej Jarzabek <a...@g...com> napisał:

> >> Nic takiego nie powiedziałem. Twierdzę, że w PHP powstawały i
> >> powstają dużo bardziej skomplikowane narzędzia niż tysiąc
> >> pięćsetny blog. I że nie wystarczy zatrudnić 10 studentów
> >
> > Gdzie one są, żeby je zobaczyć?

> http://www.facebook.com/

To akurat zły przykład:
http://en.wikipedia.org/wiki/HipHop_for_PHP
http://code.facebook.com/posts/264544830379293/hack-
a-new-programming-language-for-hhvm/

> http://www.wikipedia.org/

To jest skomplikowane narzędzie?


--
Tomek

do góry

On 2014-03-25, g...@g...com <g...@g...com> wrote:
>> Owszem, trudno znaleźć język bardziej popularny od PHP. Ale znowu: ile
>> się pisze rzeczy *zaawansowanych* w PHP? Mimo jego popularności, prawie
>> nic.
>
> Znaj proporcje, mocium panie. PHP powstal jako jezyk do tworzenia
> licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl daleko.
> Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze sie w PHP,
> nie wynika juz z semantycznych niedostatkow tego jezyka, tylko z (w pelni
> zasluzonej) marnej reputacji PHP.

...która wynia w dużej części właśnie z semantycznych niedostatków.

>> A coś, co potrafi podobne rzeczy do lispowych makr (manipulację drzewem
>> wyprowadzenia) występuje w całkiem sporej liczbie języków, od Pythona
>> zaczynając.
>
> Moglbys powiedziec cos wiecej na ten temat? Ew. rzucic jakims linkiem?
> (Jedyny jezyk z nielispowa skladnia, o jakim slyszalem, ze ma lispowe
> makra, to ruby-podobny jezyk o nazwie elixir)

Uwaga: nie chodzi o makra w stylu Lispa, czyli coś, co się wywołuje jak
funkcję. Chodzi o manipulację drzewem wyprowadzenia danego języka
z możliwością wykonania takiego drzewa, ale nie musi to wyglądać jak
w Lispie.

W Pythonie do tego służą moduły parser i ast. W Erlangu jest to zrobione
bardziej elegancko (parse_transform), bo tam proces kompilacji występuje
jawnie, więc można się w niego wpiąć.

>> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
>> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
>>
>> ...gwarancje czasowe?
>
> Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
> to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
> oraz wszystkich jezykow z garbage collectorem.

Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.

>> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
>> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
>> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
>> daje gwarancje na operacje.
>
> Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
> tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
> bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)

A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?

>> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
>> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
>> potrzebuje takiej konstrukcji?
>
> Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
> Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
> stanowia forme asocjacji.

Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
struktury mają różne zastosowanie, różną budowę i różnie się zachowują
przy większości operacji.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2014-03-25, Wojciech Muła <w...@g...com> wrote:
>> 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.

Akurat mocno nierozsądny. Nie raz i nie dwa obrabiałem większe ilości
danych. Uniwersalny kontener by się po prostu nie sprawdził.

>> Zaryzykuje ze składnia i gramatyka C++ jest bardziej spójna niż PHP. Co
>> wydaje sie niemożliwe przy bałaganie C++...
>
> Gramatyka PHP-owa jest regularna (albo prawie regularna),

Nieprawda. Gramatyka PHP jest bezkontekstowa, a nie regularna. I to nie
ma nic wspólnego ze spójnością, czyli konsekwencją w używaniu konwencji.
(Nie twierdzę że PHP ma albo nie ma bardziej spójnej gramatyki;
zaznaczam tylko, że odpowiedź jest nie na temat.)

--
Secunia non olet.
Stanislaw Klekot

do góry

>> On i tak nie ma (przynajmniej jak pracowałem nad takimi systemami,
>> to zaden z nich nie miał) bezpośredniego dostępu do bazy bankowej.
>
>Nawet by mi nie przyszło do glowy że ten PHP w banku ma dostęp do
>jakiejkolwiek bazy danych większej niż dyżury sprzątaczek.
>

System raportowy napsany w PHP podłaczony do Hurtowni Danych
(ORACLE kilkaset GB danych) duzej firmy logistycznej sprawdzał się o
wiele lepiej niz "profesjonalne" systemy raportowe
Trzeba tylko pamietać, o ze jest to język skryptowy i ma sluzyć do
prezentacji wyników oraz generowania raportów PDF do wydruku i
arkuszy MS Excel dla tych co wolą VB ;)
Do przetwarzania danych jest silnik bazy danych + np. PL/SQL a nie
aplikacja www

P.


---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ
ochrona avast! Antivirus jest aktywna.
http://www.avast.com

do góry

W dniu środa, 26 marca 2014 13:19:12 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> On 2014-03-25, g...@g...com <g...@g...com> wrote:
> >> Owszem, trudno znaleźć język bardziej popularny od PHP. Ale znowu: ile
> >> się pisze rzeczy *zaawansowanych* w PHP? Mimo jego popularności, prawie
> >> nic.
> >
> > Znaj proporcje, mocium panie. PHP powstal jako jezyk do tworzenia
> > licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl daleko.
> > Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze sie w PHP,
> > nie wynika juz z semantycznych niedostatkow tego jezyka, tylko z (w pelni
> > zasluzonej) marnej reputacji PHP.
>
> ...która wynia w dużej części właśnie z semantycznych niedostatków.

Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,
chociaz wyglada na to, ze wlasnie z powodu historycznych nalecialosci
PHP nigdy nie zostanie naprawde porzadnym jezykiem (chociaz kto wie)

> >> A coś, co potrafi podobne rzeczy do lispowych makr (manipulację drzewem
> >> wyprowadzenia) występuje w całkiem sporej liczbie języków, od Pythona
> >> zaczynając.
> >
> > Moglbys powiedziec cos wiecej na ten temat? Ew. rzucic jakims linkiem?
> > (Jedyny jezyk z nielispowa skladnia, o jakim slyszalem, ze ma lispowe
> > makra, to ruby-podobny jezyk o nazwie elixir)
>
> Uwaga: nie chodzi o makra w stylu Lispa, czyli coś, co się wywołuje jak
> funkcję. Chodzi o manipulację drzewem wyprowadzenia danego języka
> z możliwością wykonania takiego drzewa, ale nie musi to wyglądać jak
> w Lispie.
>
> W Pythonie do tego służą moduły parser i ast. W Erlangu jest to zrobione
> bardziej elegancko (parse_transform), bo tam proces kompilacji występuje
> jawnie, więc można się w niego wpiąć.

No to prawie jak w lispie :]

> >> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
> >> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
> >>
> >> ...gwarancje czasowe?
> >
> > Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
> > to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
> > oraz wszystkich jezykow z garbage collectorem.
>
> Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
> elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
> danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
> jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
> osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.

Takich gwarancji nie daje nawet C.
A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
z nim naprawde dziwne rzeczy.

> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
> >> daje gwarancje na operacje.
> >
> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
>
> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
>
> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?

Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
tak wlasnie jest implementowane, co szybki risercz wydaje
sie potwierdzac:
http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level

> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
> >> potrzebuje takiej konstrukcji?
> >
> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
> > stanowia forme asocjacji.
>
> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
> przy większości operacji.

Maja taki sam interfejs.
Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
danych. A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
namieszac, to tylko sam uzytkownik.

do góry

On 2014-03-26 18:00, pwola wrote:
> Trzeba tylko pamietać, o ze jest to język skryptowy i ma sluzyć do
> prezentacji wyników oraz generowania raportów PDF do wydruku i
> arkuszy MS Excel dla tych co wolą VB ;)

I znowu nie ma ani słowa o równaniach nielinowych.

do góry

On 2014-03-26 00:46, Andrzej Jarzabek wrote:
>>> No to mówię, że tak nie jest, że
>>> można robić zaawansowane rzeczy
>> PO CO? Przeciez w PHP nie znajdziesz nawet podstawowych zagadnień z
> Abstrahując od PHP, dużo rzeczy robi się po prostu dlatego, że
> przesadzenie dużego skomplikowanego systemu

Ten branch zaczał się od tego że ponoć w jakimś banku *wybrano* PHP do
implementacji czegoś związanego z równaniami nieliowymi w windykacji.
Pierwszę słyszę że był wcześniej w czymś napisany.

do góry

On 2014-03-26 00:34, Andrzej Jarzabek wrote:
>> Gdzie one są, żeby je zobaczyć?
> http://www.facebook.com/
> http://www.wikipedia.org/

Oba to widoki na bazy danych.

>> I żeby nie mialy MySQLa ani HTTP, ale za
>> to miały równania nieliniowe. Czy kto widział, kto?
> Też wymagania.

Nie moje. Na razie we flame pogubuło się najwazniejsze: gdzie sa
projekty które robią coś innego niż pokazują zawartośc bazy danych?

do góry

On 2014-03-25 20:48, Wojciech Muła wrote:
>> Interesujące. Masz jakies badania?
> Nie. To moje obserwacje na próbce z pewnego dużego miasta.

Aha.

>> W innym języku mam boost::range.
> Zadanie jest proste: mamy n przedziałów, mają na siebie nie nachodzić,
> ale jeśli nachodzą, trzeba podać ich listę, ale na zasadzie: "przedziały
> A, C i D kolidują", bez wnikania, które pary konkretnie.

Dodatkowo sugeruje uwzględnić że kazdy z przedziałów zawiera liczbę z
zakresu <0,NDA> (żeby nie bylo za łatwo) którą należy w locie wyjąć z
odwrócenia MD5 i umozliwić działanie w O(-1) zapewniając oczywiście że
całość algorytmu zajmnie nie więcej jak 40 linijek co jasno pokaże jakie
można, kurna, argumenty na grupie zapodać, co wciskają rozmówcę w ziemię.

> Jak to zrobisz z pomocą tej biblioteki boostowej? I jak to zrobisz
> boostem, jeśli żądam, żeby test wykonał się czasie O(n log n)?
> (Odpuszczam złożoność pamięciową, nie mam serca wymagać O(1)).

Własnie zauważyleś za złożone problemy nie mają uniwersalnych rozwiązń.
A w wątku rzecz w tym że PHP nie ma żadnych rozwiązań w standardzie,
nawet uniwersalnych. NAWET.

>> Równległe zmiany w bazie obsługuje baza. Zazwyczaj. Bywa że jak nie
>> obsługuje to się zmienia bazę (częste podejście wiekszych firm).
> Nie na tym polega problem: masz dwa wątki (niechby i std::thread)

W PHP? Jak to się stało że przytaczasz już dwa zadania w C++ jako
argument w kierunku lepszości PHP?

> one sobie czytają z bazy, aktualne na daną chwilę, listę przedziałów,
> sprawdzają czy mogą dodać nowy przedział i wtedy go dopisują; baza
> danych nie weryfikuje poprawności (w sensie: constrainty w bazie).
> Nie ma tutaj wzajemnego wykluczania wątków, więc baza może stać się
> niespójna. To jest trudne w sytuacji webowej, gdzie nie ma mutexów.

A czemu nie ma? I dlaczego powinienem workaroundowac problemy braku
czegoś w designie tandemu apache/php/mysql?

>> Jeśli niewielu PHPpowców w ogóle wie co to jest to zapewne nie
>> ma tego w języku. A jak nie ma tego w języku to nieliczni co slyszeli
>> zaczynają tworzyć kwadratowe koła. Efektem czego masz 50 implementacji i
>> każda popsuta. To nie jest dobry język. Nie zapewnia nawet minimum
>> zaplecza. To cud jakiś że w ogóle mają sortowanie.
> Hm, kolega dwa biurka dalej to samo uważa o bibliotece standardowej C++.
> Ale on jest dziwny, bo chce mieć sortowanie wielowątkowe. :)

W PHP? Czy zaczynasz narzekać na fakt że nie ma bibliotek rozwiązujacych
wszystkie problemy na świecie?

>> Absurd osiągnięto w momencie stwierdzenia że "jak czegoś nie ma to sobie
>> można napisać, to dobry język".
> Wyolbrzymiasz.

Cytuje, choć nie bez fantazji.

>> Ja po 5 minutach zabawy dostałem w łeb =, ==, ===. Może kwestia
>> szczęscia, nie wiem. Ale jakoś nie tylko ja narzekam.
> Kwestia niezrozumienia. Praktycznie to samo jest w Pythonie, tylko
> zamiast === masz słówko "is". W javascripcie też jest === i to dokładnie
> to samo działanie. Niedobre w PHP jest to, że == sam z siebie rzutuje
> w mało rozsądny sposób. BTW C++ też ma niejawne konwersje, które są
> nieoczywiste.

A kto tu twierdzi że C++ jest jakimś wzorcem?

>> Ponadto środowisko PHPowców ma coś wsólnego ze środowiskiem Delphi.
> Ja się obracałem w środowisku skupionym wokół frameworka Symfony.
> I widzę, że to jest zupełnie inna grupa, tutaj liczy się jakość,
> testowanie, dobre wzorce projektowe. Jest też sensowne zarządzanie
> zależnościami itp.

Ale co to ma do rzeczy że coś tam robisz? ja tylko twierdze że
środowiska PHPowóców i programistów Delphi mają podobną argumentację na
uniwersalność kontenerów. Kontenery są uniwersalne i są dobre. No i są
jak się przetwarza rejestr sprzątaczek.

>> 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.

Powiem tak: co prawda nie wiem w czym ma napisany systam PZU, ale w
czymś wyjątkowo paskudnym bo rozwiązanie umowy OC wymagało na oko jakiś
10 minut bezustannego klepania w klawisze na przemian z bębnieniem
palcami w biurko "bo to dużo danych trzeba obrobić prosze Pana, ale i
tak mamy w tym nowym znacznie szybciej". Tam tez pewno byli specjaliści
od "indeksowany kontener jest najlepszy" zupelnie jak w PHP. Z resztą
być może było i w PHP napisane. W to że łącze PZU wisi na SDI nie uwierzę.

>> Nie rozumiesz. Gdyby w PHP problemem byla *tylko* dynamiczność to możesz
>> sobie robić flame. Ale problemów w PHP jest tak wiele, że ta
>> dynamicznośc nie ma żadnego znaczenia przy wyborze języka. To jest nic w
>> porównaniu z masą idiotycznych pułapek które po wielokroć ten język
>> przekreślają w parze ze słowem "profesjonalny", "bankowy", "dobry".
> Ale sorry, sam pisałeś, że miałeś jakąś krótkotrwałą przygodę z PHP-em,
> więc ciągle posługujesz się fragmentaryczną i przestarzałą wiedzą.

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...

>>> Z przeglądarką nie jest związany żaden stan, pewnie myślisz o sesji.
>> Myślę o ustawieniach.
> Ale przeglądarki? Chyba coś mieszasz.

Ustawienia phpini w apache mają wpływ na runtime PHP. Jak chcesz różne
to ... no cóż ...

>> Gdzie one są, żeby je zobaczyć? I żeby nie mialy MySQLa ani HTTP, ale za
>> to miały równania nieliniowe. Czy kto widział, kto?
> 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 czy nie było i mowisz o jeszcze
jednym z miliona widoku na bazę danych?

do góry