On Monday, March 24, 2014 7:39:13 PM UTC+1, Sebastian Biały wrote:
> > Sorry, ale to jest Twoje stereotypowe myślenie - że, jak PHP, to bida
> > z nędzą i studenciaki za tysiaka.
>
> Rynek się to nazywa. Programista PHP zazwyczaj zajmuje się gównianymi
> widokami na bazę danych i jego płaca jest adekwatna do poziomu zagadnień
> z jakimi pracuje.

To ja znam dziwny rynek, gdzie programiści PHP-a zarabiają powyżej średniej
krajowej i spora część z nich ma wyższe wykształcenie zdobyte na dobrych
uczelniach.

> > No to mówię, że tak nie jest, że
> > można robić zaawansowane rzeczy
>
> PO CO?

A wiesz dlaczego pies liże się po jajkach? BO MOŻE.
Więc może właśnie dlatego w PHP-ie. :-)

> Przeciez w PHP nie znajdziesz nawet podstawowych zagadnień z
> algorytmiki w postaci godnych zaufania bibliotek.

Wystarczy znać algorytmikę, nie potrzeba bibliotek do wykonania
DFS, policzenia głębokości drzewa, wykonania wyszukiwania binarnego,
zaimplementowania kolejki priorytetowej, itp.

> PO CO cobić w nim zaawansowane rzeczy? Jest niewydajny,

Tak jak Perl, Python, Javascript. Ale jak potrzebujesz szybko,
to moduł w C i gotowe.

> jest popsuty pod każdym względem wliczając w to fundamenty języka,

Ma całkiem nieźle rozwiązania od 5.cośtam, dość podobne do Pythona
miejscami. Co prawda umożliwia pojedyncze dziedziczenie (jak Java),
ale ma interfejsy (jak Java), ma przestrzenie nazw, możliwość wpięcia
własny class-loaderów. Ma nawet typehinting. To, że w języku są
zaszłości, których nie da się wyeliminować jednym "rm -rf /" wcale
go nie przekreśla.

W dużych projektach przekreśla go głównie dynamiczne typowanie.

> jest prawie niedebugowalny,

A co to znaczy? Przecież to język skryptowy, można z nim zrobić
wszystko.

> nie posiada żadnego wsparcia ani gwarancji ze znowu czegoś nie
> spieprzą bardziej w nastepnej wersji. PO CO?

Python, Javascript, Go, Perl, C++, C, czy cokolwiek innego ma
jakąś gwarancję? (Może Java, czy Ada coś gwarantują, nie wiem).
Historia pokazuje raczej, że języki się zbliżają do siebie,
zapożyczając co lepsze rozwiązania.

w.

do góry

On 2014-03-24, g...@g...com <g...@g...com> wrote:
> W dniu poniedziałek, 24 marca 2014 14:48:08 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>>
>> >> Owszem, można. Znam jednego świetnego programistę, który pisze w PHP.
>> >> *Jednego*.
>> >
>> > O czym to ma swiadczyc?
>>
>> Że ich mało. Gdyby dobrych było dużo, znałbym ich więcej niż tylko
>> jednego.
>
> A ilu znasz swietnych programistow w ogole?
> I w jakich jezykach programuja?

Powyżej dwudziestu (mówimy o *świetnych*).
Piszą w C, Pythonie i Rubym. W PHP pisze tylko ten jeden.

>> > dajacym
>> > programiscie duza elastycznosc.
>>
>> Assembler też daje programiście dużą elastyczność. Argument do śmieci.
>
> Elastycznosc to odwrotnosc ilosci pracy, ktora musisz wlozyc w to,
> zeby cos zmienic. Asembler daje programiscie mala elastycznosc,
> bo zeby cos zmienic, musisz wlozyc duzo pracy.
>
> Przyklad: programu napisanego w asemblerze jednej maszyny
> nie uruchomisz na innej maszynie (chyba ze na emulatorze).
> To jest przyklad braku tej elastycznosci. Moglbym wymienic
> kilka innych.

Argument jest bardzo śliski, niejasny i nieprecyzyjny. A w PHP możesz
zmienić sam tylko rejestr EAX na i386? Nie, musisz się strasznie
napracować.

Wyciągasz ogólnik, więc nie dziw się, że da się wykazać jego
nieprawdziwość w pewnych specyficznych warunkach.

Zresztą nawet jako ogólnik średnio jest prawdą, gdy porównać PHP
do jego sąsiadów (języków stosowanych do tego samego celu; assembler nie
jest za bardzo porównywalny do PHP).

>> > Ale wiele z tych niedogodnosci mozna samemu dosc latwo obejsc.
>>
>> Ale trzeba się o nie ciągle potykać. I to dopiero dwa lata, kiedy cały
>> świat już dawno poszedł dalej. To już nawet JavaScript jest od PHP
>> wygodniejszy.
>
> Mysle ze to akurat kwestia przyzwyczajenia.
> Nie wiem tez co to znaczy, ze "caly swiat juz dawno poszedl dalej".

Na przykład ma dekoratory (funkcje owijające inne funkcje/metody). Albo
pozwala na manipulację drzewem wyprowadzenia (jak makra w Lispie). Albo
pozwala na wnioskowanie o typach. I parę innych.

>> > Oczywiscie mozna miec pretensje do tworcow PHPa, ze nie zainteresowali
>> > sie nawet podstawowa wiedza dotyczaca projektowania jezykow programowania,
>> > ale nie da sie ukryc, ze sukces tego jezyka jest spektakularny.
>>
>> Spektakularny i zupełnie niezrozumiały. Zupełnie jak z MySQL-em, który
>> od zawsze był kiepską bazą danych.
>>
>> Ale to nie ma znaczenia, bo nie to jest przedmiotem dyskusji.
>> Wracamy do tematu: ile się pisze w PHP rzeczy zaawansowanych
>> algorytmicznie lub architekturalnie? A ile się pisze w innych językach
>> (każdym z osobna), jak JavaScript (Node.js), Python, Ruby, Scala, Go?
>> I ilu użytkowników ma PHP, a ile mają pozostałe wymienione?
>
> Jezeli idzie o to, czy ten stereotyp (ze programista PHP to kiepski
> programista) jest uzasadniony, to owszem, jest. PHP ma bardzo niska
> bariere wejscia, co przyczynia sie do jego duzej popularnosci,

Nie dyskutujemy o wszystkich piszących w PHP, tylko o programistach PHP.
Tych zarabiających na chleb i tych piszących hobbystycznie, ale nieco
większe rzeczy niż dwa formularze na trzech stronach na krzyż.

Zresztą Python też ma niską barierę wejścia, a krzywą nauki chyba
jeszcze łagodniejszą niż PHP. I co? Jakoś w Pythonie pisze się bardziej
zaawansowane rzeczy niż w PHP.

Dolicz jeszcze, że nawet patrząc na samą liczbę (nie stosunek tej liczby
do liczby używających języka) projektów wymagających więcej wiedzy od
stronki domowej czy innego CMS-a, PHP wypada bardzo blado.

> a
> latwosc korzystania z PHPowych tablic i ich uniwersalnosc sa
> naprawde imponujace,

Głupio pomieszane tablice asocjacyjne ze zwykłymi tablicami. Imponujące
to to może być dla kogoś, kto przychodzi z C albo Javy, gdzie takie
rzeczy są zepchnięte do bibliotek.

> Mimo wszystko, gorszym stereotypem wydaje mi sie ten, ze jakosc
> programisty zalezy od jezyka programowania.

Bo to zwyczajna nieprawda. Jakość programisty nie *zależy* (w każdym
razie nie w zauważalnym stopniu) od języka, którego ten programista
używa. Jakość programisty jest *skorelowana* z językiem, jakiego on
używa (w każdym razie z jego podstawowym językiem). I ta korelacja jest
dużo bardziej złożona, bo dobry programista rzadko się ogranicza do
jednego tylko języka.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2014-03-24, Wojciech Muła <w...@g...com> wrote:
> On Monday, March 24, 2014 11:21:47 AM UTC+1, Stachu 'Dozzie' K. wrote:
>> > Sorry, ale to jest Twoje stereotypowe myślenie - że, jak PHP, to bida
>> > z nędzą i studenciaki za tysiaka. No to mówię, że tak nie jest, że
>> > można robić zaawansowane rzeczy, które piszą nieźli programiści i robią
>> > to na tyle dobrze, że klienci są skłonni płacić sporą kasę, także
>> > za support.
>>
>> Owszem, można. Znam jednego świetnego programistę, który pisze w PHP.
>> *Jednego*.
>
> A ja znam kilku. No i czego to by miało dowodzić?

Że powinno być ich znacznie więcej, ergo: większość dobrych programistów
nie pisze w PHP. Oczywiście to wniosek wysnuty na podstawie obserwacji
dość wąskiej grupy, ale podobną sytuację widzę w świecie open source.
W PHP powstaje mało naprawdę przyzwoitych aplikacji.

>> Ale że można, to jeszcze nie znaczy, że to *norma*. Wybacz, ale
>> stereotyp nie wziął się z samego tylko zepsutego powietrza.
>>
>> PHP jest chyba jedynym współczesnym językiem generalnego przeznaczenia,
>> dla którego nie ma generatora parserów. To trochę świadczy
>> o zaawansowaniu typowych aplikacji w nim pisanych.
>
> Brak generatora parserów o czymkolwiek miałby świadczyć? Zaskakujący
> argument.

O braku zapotrzebowania na dobry generator parserów. Znaczy nikt[*]
w PHP nie używa parserów (przynajmniej takich uczciwych, produkujących
drzewo wyprowadzenia).

[*] Kwantyfikator ogólny zwyczajowy, czyli "mogą być wyjątki, ale są
bardzo nieliczne".

> A kiedy ostatni raz potrzebowałeś użyć takiego generatora?

Trzy tygodnie temu. A w ciągu ostatnich dwóch lat chyba ze sześć razy
pisałem gramatykę. A jestem tylko sysadminem, chciałem zaznaczyć.

> Bo ja sobie nie przypominam takiej konieczności - jak coś potrzebowałem
> parsować, to sobie napisałem parser.

A ja wolę napisać gramatykę. Zwykle się sprawdza znacznie lepiej niż
"sobie napisałem parser", na przykład ma mniej błędów i szybciej się
dodaje nowe elementy składniowe. No i dla prostego języka zajmuje może
pół godziny, podczas gdy ręczne pisanie takiego parsera to dobre kilka
godzin pracy.

>> Nie chodzi o dowód formalny czy powoływanie się na urzędowe papiery,
>> wystarczyłby bliższy opis sytuacji, w jakiej użyto tego PHP.
>
> To jest system backoffice, który wspiera bardzo różne procesy
> w bankach (np. obieg dokumentów, sprawy windykacyjne). No i jak
> zweryfikujesz, że nie kłamię?

Zakładam że mówisz prawdę, tylko póki nie wykażesz, że to jest na temat
(na przykład opisując warunki, w których wybierano PHP), to mogę
zakładać, że cały argument ma się nijak do dyskusji.

>> Ale ty się migasz w najgłupszy możliwy sposób: "wiem, ale nie powiem,
>> musicie uznać mój autorytet".
>
> Na tym polega NDA, że nie wszystko można mówić.

Przykro mi, że wyciągnąłeś argument tylko po to, żeby potem się od niego
głupio migać. Było go nie wyciągać, nie osłabiałbyś swojej pozycji przez
podawaniu niedorzecznego argumentu.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2014-03-24, Wojciech Muła <w...@g...com> wrote:
[...]
>> Przeciez w PHP nie znajdziesz nawet podstawowych zagadnień z
>> algorytmiki w postaci godnych zaufania bibliotek.
>
> Wystarczy znać algorytmikę, nie potrzeba bibliotek do wykonania
> DFS, policzenia głębokości drzewa, wykonania wyszukiwania binarnego,
> zaimplementowania kolejki priorytetowej, itp.

Można. Można też napisać własną bibliotekę do wyrażeń regularnych, do
obsługi hipergrafów czy do rozproszonego odwracania ogromnych macierzy.
Ale w innych językach te rozmaite elementy są już gotowe, więc trudno
uzasadnić akurat taki wybór.

>> jest popsuty pod każdym względem wliczając w to fundamenty języka,
>
> Ma całkiem nieźle rozwiązania od 5.cośtam, dość podobne do Pythona
> miejscami.

Ale tylko bardzo niektórymi miejscami. Brakuje mu tak na oko dwóch
trzecich możliwości Pythona, tych bardziej zaawansowanych. Dekoratory?
Praca z AST programu? Metaklasy? System modułów, żeby się dało
dystrybuować biblioteki? (PEAR *nie jest* równoważny pythonowym modułom)

> W dużych projektach przekreśla go głównie dynamiczne typowanie.

Podobnie jak Pythona, Rubyego, JavaScript, warianty Lispa, Objective-C
(w części obiektowej). Erm...

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu poniedziałek, 24 marca 2014 21:00:17 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:

> >> Assembler też daje programiście dużą elastyczność. Argument do śmieci.
> > Elastycznosc to odwrotnosc ilosci pracy, ktora musisz wlozyc w to,
> > zeby cos zmienic. Asembler daje programiscie mala elastycznosc,
> > bo zeby cos zmienic, musisz wlozyc duzo pracy.
> >
> > Przyklad: programu napisanego w asemblerze jednej maszyny
> > nie uruchomisz na innej maszynie (chyba ze na emulatorze).
> > To jest przyklad braku tej elastycznosci. Moglbym wymienic
> > kilka innych.
>
> Argument jest bardzo śliski, niejasny i nieprecyzyjny. A w PHP możesz
> zmienić sam tylko rejestr EAX na i386? Nie, musisz się strasznie
> napracować.

Nigdy nie slyszalem specyfikacji "napisz program, ktory zmienia
zawartosc rejestru EAX". I nie na tym polega tworzenie oprogramowania.
Zawartosc rejetru to szczegol implementacyjny, a tym, co interesuje
klienta, sa wymagania funkcjonalne.

> Wyciągasz ogólnik, więc nie dziw się, że da się wykazać jego
> nieprawdziwość w pewnych specyficznych warunkach.

Zwlaszcza w takich, w ktorych dopuszcza sie bledne wnioskowanie.

> Zresztą nawet jako ogólnik średnio jest prawdą, gdy porównać PHP
> do jego sąsiadów (języków stosowanych do tego samego celu; assembler nie
> jest za bardzo porównywalny do PHP).

Sam wygrzebales tego asemblera.
Genetycznie PHP najbardziej jest zblizony do Perla,
ale jest od niego pod wieloma wzgledami lepszy (przede
wszystkim pod takim, ze ma jednorodna skladnie, w zasadzie
w calosci odziedziczona w C, co rowniez ma taka zalete,
ze generatory kodu w C mozna stosunkowo latwo dostosowac,
zeby produkowaly kod w PHP).

> >> > Ale wiele z tych niedogodnosci mozna samemu dosc latwo obejsc.
> >>
> >> Ale trzeba się o nie ciągle potykać. I to dopiero dwa lata, kiedy cały
> >> świat już dawno poszedł dalej. To już nawet JavaScript jest od PHP
> >> wygodniejszy.
> >
> > Mysle ze to akurat kwestia przyzwyczajenia.
> > Nie wiem tez co to znaczy, ze "caly swiat juz dawno poszedl dalej".
>
> Na przykład ma dekoratory (funkcje owijające inne funkcje/metody). Albo
> pozwala na manipulację drzewem wyprowadzenia (jak makra w Lispie). Albo
> pozwala na wnioskowanie o typach. I parę innych.

Makra w lispie istnieja znacznie dluzej, niz PHP, ale pod wzgledem
popularnosci PHP zdecydowanie wygrywa. Od jakiegos czasu pojawila sie
tez opcja podawania typow dla argumentow funkcji, ale niestety tylko
dla typow zdefiniowanych w ramach systemu OOP. Haskell ma najlepszy
system typow, jaki widzialem, ale jego zastosowania produkcyjne sa
porownywalnie marginalne do lispu.

> > a
> > latwosc korzystania z PHPowych tablic i ich uniwersalnosc sa
> > naprawde imponujace,
>
> Głupio pomieszane tablice asocjacyjne ze zwykłymi tablicami. Imponujące
> to to może być dla kogoś, kto przychodzi z C albo Javy, gdzie takie
> rzeczy są zepchnięte do bibliotek.

Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.

> > Mimo wszystko, gorszym stereotypem wydaje mi sie ten, ze jakosc
> > programisty zalezy od jezyka programowania.
>
>
> Bo to zwyczajna nieprawda. Jakość programisty nie *zależy* (w każdym
> razie nie w zauważalnym stopniu) od języka, którego ten programista
> używa. Jakość programisty jest *skorelowana* z językiem, jakiego on
> używa (w każdym razie z jego podstawowym językiem). I ta korelacja jest
> dużo bardziej złożona, bo dobry programista rzadko się ogranicza do
> jednego tylko języka.

Zgoda.

do góry

On 2014-03-24 20:27, Wojciech Muła wrote:
>> Rynek się to nazywa. Programista PHP zazwyczaj zajmuje się gównianymi
>> widokami na bazę danych i jego płaca jest adekwatna do poziomu zagadnień
>> z jakimi pracuje.
> To ja znam dziwny rynek, gdzie programiści PHP-a zarabiają powyżej średniej
> krajowej

Średniej krajowej *programisty* czy sredniej krajowej? Bo właśnie
próbujesz porownać zawód programatora PHP do pracy kierowcy tira. Może i
jest w tym jakaś samokrytyka.

> i spora część z nich ma wyższe wykształcenie zdobyte na dobrych
> uczelniach.

Zaistę, to najważniejsze, co ocenia jakośc języka: jest w nim spora
część programistow którzy ukończyli dobre uczelnie. No i?

> Przeciez w PHP nie znajdziesz nawet podstawowych zagadnień z
>> algorytmiki w postaci godnych zaufania bibliotek.
> Wystarczy znać algorytmikę, nie potrzeba bibliotek do wykonania
> DFS, policzenia głębokości drzewa, wykonania wyszukiwania binarnego,
> zaimplementowania kolejki priorytetowej, itp.

Chcesz z gównianym jezyku wynajdywac kwadratowe koła. To jest własnie
slabośc PHP: tam *NIC* nie ma. Epoka kolejki łupanej, wszystko musisz
sam wydłubać z kamienia jesli masz potrzebę większa niz nastepne forum o
hiphopie. I to ma być *profesjonalny* język który bank używa na codzień?
Może jednak robi te grafiki sprzątaczek w banku.

>> PO CO cobić w nim zaawansowane rzeczy? Jest niewydajny,
> Tak jak Perl, Python, Javascript. Ale jak potrzebujesz szybko,
> to moduł w C i gotowe.

Szybko jestes w stanie napisać poprawne drzewo czerwono-czarne? Z unit
testami, o prawidłowej złożoności, z poprawnym interfejsem? Nie każdy
potrafi. A tu proszę, w PHP byle studencik machnie w przerwie
śniadaniowej a drugi napisze wsparcie dla wątków w przerwie grania na
xboxie. I kolejny mit o PHP obalony: tam jest wszystko możliwe, bo
przecież jest turing-complete.

> Ma całkiem nieźle rozwiązania od 5.cośtam

G. prawda. On jest popsuty w samym rdzeniu. Mój ulubiony sadness:

http://phpsadness.com/sad/47

Dyskusja jaka krąży wokół tego problemu jest żenująca. Jak można to
spieprzyć? Ano można, jak się po pijaku wymyśla język. To jedna z setek
min w które prędzej czy później wdepniesz. Problemy w parserze,
idiotycznej gramatyce, nieudolna ewakuacja w stronę referencji itp.

> To, że w języku są
> zaszłości, których nie da się wyeliminować jednym "rm -rf /" wcale
> go nie przekreśla.

To go przekreśla w profesjonalnych zastosowaniach. Ot tak.

> W dużych projektach przekreśla go głównie dynamiczne typowanie.

Dynamicznośc to pikuś w porównaniuz resztą.

>> jest prawie niedebugowalny,
> A co to znaczy? Przecież to język skryptowy, można z nim zrobić
> wszystko.

Czyli dostac errora w przeglądarce? Lub wciskać do kodu dumpy callstacku
(ręcznie)? Nie oszukujmy się. On nie jest skryptowy. On jest
zorientowany na przeglądarkę. Ba, dzialanie tego języka zalezy od stanu
przegladarki i pierdyliarda php.ini. To jest żałosne.

> Python, Javascript, Go, Perl, C++, C, czy cokolwiek innego ma
> jakąś gwarancję?

a) ludzie którzy myślą i standaryzują a nie odwrotnie, efekty ich pracy
to jakiś zamysł a nie chaos. Najczęsciej wyniki są wyrażone w jakiś
formalny sposob.
b) komitety standaryzacyjne które nie wymysla języka po pijaku

> (Może Java, czy Ada coś gwarantują, nie wiem).

Mają specyfikacje, gramatyki, stabilne zachowanie itp pierdoły bez
znaczenia.

> Historia pokazuje raczej, że języki się zbliżają do siebie,
> zapożyczając co lepsze rozwiązania.

Co zapożyczył PHP i od czego? I co jest w PHP do zapożyczenia przez innych?

PS. Stawiasz tezę że nie jest ważne jaki język jest w tle rozwiązania
problemu. Owszem, akademicko patrząc: nie ma to znaczenia. Tylko że
doświadczenie ludzi faktycznie rozwiązujacych te problemy stanowi
inaczej: PHP jest dokładnie na samym dnie jakości, oddzielone tylko
cienką linią od brainfucka i innych jezyków tworzonych dla żartu. A że
jest popularny? No i co z tego? Justin Bieber też jest popularny.

PHP to kupa. Nie wierzę że ludzie pracujący w bankach są aż tak
przeraźliwie głupi aby wybrać go na krytycznej ścieżce, albo uzywać do
"rozwiązywania równań nieliniowych w systemach windykacji". Czyli działa
jako pierdola wspomagająca jakieś proste zadania typu pokazanie pani
Marysi ile klient jest winny. I niech sobie tam działa. Studenci
informatyki gdzieś się muszą szkolić, a co lepszego niż praca w banku w
profesjonalnym projekcie może się im przytrafić?

do góry

On 2014-03-24, g...@g...com <g...@g...com> wrote:
>> >> > Ale wiele z tych niedogodnosci mozna samemu dosc latwo obejsc.
>> >>
>> >> Ale trzeba się o nie ciągle potykać. I to dopiero dwa lata, kiedy cały
>> >> świat już dawno poszedł dalej. To już nawet JavaScript jest od PHP
>> >> wygodniejszy.
>> >
>> > Mysle ze to akurat kwestia przyzwyczajenia.
>> > Nie wiem tez co to znaczy, ze "caly swiat juz dawno poszedl dalej".
>>
>> Na przykład ma dekoratory (funkcje owijające inne funkcje/metody). Albo
>> pozwala na manipulację drzewem wyprowadzenia (jak makra w Lispie). Albo
>> pozwala na wnioskowanie o typach. I parę innych.
>
> Makra w lispie istnieja znacznie dluzej, niz PHP, ale pod wzgledem
> popularnosci PHP zdecydowanie wygrywa.

Owszem, trudno znaleźć język bardziej popularny od PHP. Ale znowu: ile
się pisze rzeczy *zaawansowanych* w PHP? Mimo jego popularności, prawie
nic.

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.

>> > a
>> > latwosc korzystania z PHPowych tablic i ich uniwersalnosc sa
>> > naprawde imponujace,
>>
>> Głupio pomieszane tablice asocjacyjne ze zwykłymi tablicami. Imponujące
>> to to może być dla kogoś, kto przychodzi z C albo Javy, gdzie takie
>> rzeczy są zepchnięte do bibliotek.
>
> Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
> potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.

...gwarancje czasowe?

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.

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?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2014-03-24, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2014-03-24 20:27, Wojciech Muła wrote:
>>> Rynek się to nazywa. Programista PHP zazwyczaj zajmuje się gównianymi
>>> widokami na bazę danych i jego płaca jest adekwatna do poziomu zagadnień
>>> z jakimi pracuje.
>> To ja znam dziwny rynek, gdzie programiści PHP-a zarabiają powyżej średniej
>> krajowej
>
> Średniej krajowej *programisty* czy sredniej krajowej? Bo właśnie
> próbujesz porownać zawód programatora PHP do pracy kierowcy tira. Może i
> jest w tym jakaś samokrytyka.

Kierowcy ciężarówek zarabiają całkiem nieźle w porównaniu z resztą
społeczeństwa (w każdym razie w Polsce), więc słaby argument.

Zamień "kierowcę TIR-a" na "dozorcę".

[...]
> PHP to kupa. Nie wierzę że ludzie pracujący w bankach są aż tak
> przeraźliwie głupi aby wybrać go na krytycznej ścieżce,

Owszem, są aż tak. Wystarczy popatrzeć na inne przejawy działalności
banków, na przykład okolice płatności bezgotówkowych (karty debetowe
i kredytowe anyone?)
http://www.lightbluetouchpaper.org/2014/02/05/why-di
spute-resolution-is-hard/

--
Secunia non olet.
Stanislaw Klekot

do góry

> Przyklad: programu napisanego w asemblerze jednej maszyny
> nie uruchomisz na innej maszynie (chyba ze na emulatorze).

swoja droga ciekawe czy to ne jest w pewnym sensie
mit i czy nie daloby sie napisac nawet dosyc prosto
programu tlumaczacego program w jezyku jednego assemblera na inny -- z grubsza wydaje
sie to
mozliwe, chyba ze sa jakies przypadki praktycznie
trudne ale nic jakos nie przychodzi mi do glowy

do góry

On Sun, 23 Mar 2014 09:59:42 -0700 (PDT), Wojciech
Muła<w...@g...com> wrote:
> > Pisany w PHP? Lol.
> A w czym powinien być napisany?

Nie chodzi o to w czym powinien być napisany, ale o to że PHP nie
jest popularne w bankowości poza ściśle webowymi rejonami. A tam sie
nie rozwiązuje równań nieliniowych.

RW

do góry