On 2015-11-22 20:52, AK wrote:
>>> Moze pokaz wpierw swoje samodzielne dokonania.?
>>> Nawet tak proste (przeciez pisalem o tym, ze to drogiazg:) jak te moje?
>> Zapytaj o to mojego pracodawcę.
> Ja pytam o _Twoj_ kod, a nie kod Twojego pracodawcy.

Mój kod jest kodem mojego pracodawcy. Są de facto dwa: kod który piszę
zawodowo i mam umowę z pracodawcą, oraz kod który piszę prywanie i
zamierzam go spieniężyć. Oba nie są na widoku publicznym i nie będą
chyba że pracodawca się zgodzi. W tym drugim przypadku się nie zgodzi na
pewno, a w pierwszym pytaj.

> Tez sie nigdzie i nigdy chwale nie moim/zastanym kodem
> moich pracodawcow (mimo ze dosc czesto byl w pelni odseparowany
> od zastanego). No wiec ? Pochwal sie.
> Przeciez to nie boli.

Nie. Powody są oczywiste dla kogoś kto pracuje w korpo i podpisał
stosowne papiery. Nie udzielam się w OS, ludzie w moim wieku mają
róznież inne obowiązki jak rodzina.

>> Nie. Krytykuje pokazywanie kiepskiego PHP
> To nieprawda, ze PHP bardzo kiepskie.
> Oczywiscie nie dorownuje IMHO Pythonowi, ale jest calkiem przyjemnym
> jezykiem.

Nie jest. Ma wady w postaci składni, choćby te denne !== z wklejki.
Choćby niedeklarowane zmienne przez co jakość dostaje po mordzie od
literówek. Chaotycznie rozwijany ze standardową bibliteką robioną na
kolanie. Nie, nie jest przyjemny. Niczym nie zachwyca. Nie wymienileś
ani jednej zalety tego języka. Wymieniłes tylko debilne ograniczenie
sprzętowe. Trudno.

>> Nie wypowidam się na tematy o ktorych za mało wiem.
> No a o ORMach i bazach danych sie wypowiadasz ?
> O nich duzo wiesz ?

O nich wiem wystarczająco aby znać ich budowę, zalety i wady. Jak
rownież kiedy ich nie stosować. Szkoda że przekonalem sie na własnej skórze.

>> Nie jestes jedyny. Nikomu nie udało się zrobić perfekcyjnego parsera
>> C++. gcc zmienial go chyba kilka razy.
> Racja. Wreszcie parser napisali recznie (wczesniej byl to plik yacca,
> ogromny chyba 5 albo 0.5MB nie pamietam).
> Dlaczego go przepisali ?
> Co bylo przyczyna (w jezyku, w jego skladni) ze to taki trudny
> problem ? Pamietasz ?

Nie. Nie mam w zakresie hobby śledzenia zmian w parserze gcc. Sorry.

> E no.. Najwieksza polska firme softwarowa (wlasciwie juz korporacja)
> (a po czesci europejska - Europa Wschodnia) nalezy jednak nieco poznac.
> Chocby ogolnie.
> PS: A wiesz, ze Asseco powstalo w tej mojej "gluchej puszczy" (Rzeszow)
> i wcale nie "z wągla" ?

No i co z tego wynika? Coś to udowadnia, jakąs tezę może?

>> Asseco nie biore pod uwagę ponieważ ich portfolio to głównie bazy
>> danych ktorych nie lubię.
> No tak..
> Po pierwsze. Mylisz sie bardzo. Nawet dawne Asseco to "nie tylko"
> bazy danych.

"to głównie bazy danych". Tam nie ma słowa "tylko". Masz urojenia i to
na odległosci 3 linijek.

Nie wątpię. Ale nie widzę powodu aby pracować w firmie ktora nie dośc że
robi projekty co chwile nowe to jeszcze w dużej mierze bazodanowe. Po
prostu nie chcę. Czy mogę nie chcieć? Pozwolisz?

> Po drugie: Jesli nie lubisz baz to dlaczego sie wypowiedasz na temat ORM
> itp?

Ponieważ *właśnie* dlatego nie lubię baz danych bo musiałem użyć ORMów i
przekonalem się jak dalece od koncepcji bywają implementacje.

> "Nielubienie" to podejscie emocjonalne. a nie inzynierskie.
> Implikuje zasadnicze bledy w ocenie (ORM , baz danych itp).

Nie. Ty nie lubisz C++ więc implikuje to wiele różnych rzeczy. Ja nie
lubie karkówki więc ... a z resztą. Jestesmy ludzmi i możemy czegoś nie
lubić. To oznacza unikanie zagadnień przez świadome wybieranie pracy.

> No czy w/g Ciebie moge sie choc "nieco" uwazac za prekursora (a
> przynajmniej
> probujacego nim byc:)

Kto Ci to zabiera? Bądź sobie prekursorem.

>> Nie widze w tym nic złego o ile ludzie projektujący jezyk mają *dużo*
>> doświadczenia w projektowaniu języków. A mają?
> Tego nie wiem. Mozna domniemywac, ze tak jest jezyki dzialaja :)

To niewystarczające. PHP jest przykładem że jesli coś dziala nie musi
być dobrze zaprojektowane. PHP nie był zaprojektowany. Był i jest pisany
ad-hoc.

>>> Czy ORMy pizsa ludzie czy "sami swieci" ?
>> Nie. Powszechnie uzywane ormy sa po prostu lepiej przetestowane niż
>> lokalny pomysł na język którego autor dawno się zwolnił a testy się
>> skasowały bo ich nigdy nie było.
> Tak? Ani niby _co_ gwarantuje ze taki Hibernate nie umrze ?

Nic nie mowie o zakończeniu aplikacji. Mówie to *testach*. O ich braku
konkretnie, a źródło wiedzy siedzi na Arubie i popija drinki z
parasolką. Sorry, codzienność w korpo to fatalna dokumentacja do
fatalnego kodu i znakomicie zredagowane opisy hello worldów.

> Hibernate jest przeciez na GPL

Na LGPL.

> i jesli autorom sie znudzi (albo
> zywczajnie zejda

Zazwyczaj projekty które są na LGPL mozna rozwijać dalej wewnętrze jak
juz padnie ostatni pryszczaty nastolatek w zaprzęgu. To pewna poduszka
pozwalająca na amortyzację i daje czas na zmianę technologii.

> W przypadku gdy firma zwyczajnie sprzedaje jezyk jako czesc softu
> to juz prawnicy klientow jej wytlumacza ze lepiej jednak tenm jezyk
> wciaz supportowac

Nie. Mam prosty przykład z podworka: pewna forma zrobiła kluczowy
kawalek softu i dostarczała biblioteki binarne. Padła. Nikt ich nie
kupił. Nastapiła rewolucja do 64 bitow i mamy śliczne vendor lock-in.
Zagadnienie jest nietrywialne i nie da się go w rok wymienić. Można
tuptać noga ale nikt nie chciał kontynuować ich softu.

>> Nie takich ponieważ leża po złej stronie algorytmiki. Tam gdzie już
>> nie jest wiadomo o co chodziło autorowi zapytania. To czy user jest w
>> stanie to wykorzystać oraz (co okazało się na moim przykładze) czy orm
>> jest na tyle sprytny aby to zauważyc, może być wątpliwe.
> Sorry, ale to jest jakis kompletnie dla mnie niezrozumialy belkot.
> Wytlumacz _normalnie_.

Po stronie agorytmicznej masz np. forward iterator na krotki. To
powoduje że istnieje pewien charakterystyczny sposob użycia i
cacheowania ktory pozwala na zwiekszenie wydajności, zajętosci pamięci
czy czego tam w *tym* przypadku użycia *tego* iteratora. Np. można
czytać dane w osobnym wątku bo wiadomo jakie beda potrzebne i kiedy.

Po stronie języka zapytań bazy masz już raczej indeksy i nie ma tam
wiedzy czy zaraz ktoś nie zapyta o indeks K-1. Tam jest mało wiedzy o
algorytmie. Są zapytania ad-hoc.

Więc albo sam zaimplementujesz tą wiedzę po stronie zapytania albo
dostajesz glupi cache który trzyma w pamięci krotki które nigdy już nie
zostaną odczytane.

Pewnie że wyrażenie swoich koncepcji przez pobranie forward iteratora na
dane może zostać olane przez orma. I o dziwo hibernate mnie olewał, choć
może nie w takich trywialnych przypadkach. Trudno, nie ma perfekcyjnego
środowiska.

ORMy miały m.in. rozwiązać problem "o co mu chodzi" w sposób optymalny.
Nie rozwiązały, a czasem rozwiązały wręcz odwrotnie. Nie wiem czy to
wina w koncepcji, ale przypuszcam że raczej w implementacji. Szersze
doświadczenia miałem tylko z Hibernate. Może coś się zmieniło w
ostatnich 6 latach, nie wiem.

>> Dlaczego został wybrany? PHP miał nic w stosunku do innych języków
>> poza absurdalną składnią.
> Kolejny belkot.
> Poza tym skladnia to "lukier" zaledwie.

Nie. To źródło bugow. Choćby rozluźniona kontrola typów i = == ===.
Jeśli twierdzisz że składnia nie ma znaczenia to wszystkie jezyki
imperatywne beda w jakimś stopniu takie same. Jednak z jakiegoś powodu
ludzie wybierają różne do różnych zastosowań.

> Ona wcale nie decyduje o jakosci jezyka.

Jest jednym z czynników decydujących np. o ilości bugów per linia albo o
czytelności, czy możliwości refaktorowania. To całkiem sporo. Dla duzych
i dlugich projektów może być to istotne. Np. C++ ma obleśnie słabe
możliwości refaktorowania automatycznego. C# znacznie większe. A oba
różnią się tylko "lukrem", nie?

>> Prosze, nie pieprz że wzorce projektowe w 2002 roku były mało
>> popularne. To rani mój mózg.
> BYLY malo popularne koles. Po prostu tak bylo (do dzis wlasnie w C++
> wzroce projektowe sa wciaz malo popularne)

Musze więc poprosić o statystykę. w 2002 roku to było gdzieś
przynajmniej 15 lat od spisania. Nawet głupia java była projektowana z
wzorcami w tle. Nawet głupi stl miał wzorce, choć możesz narzekać że
kiepskie. Wszystko i wszedzie mialo wzorce statystycznie patrząc. Choc
może nie biorę pod uwagę php. Ale one były wszedzie. Jesli nawet MS je
implementował to juz naprawdę musieli to wcześniej robić wszyscy.

>, ai zis vczresto spotykam
> kod (gloownie w Javie) gdzie scisle i bezkrytyczne trzymanie sie
> tzw "wzrorca projketowego" powoduje ze kod staje sie sieczka.

No i co z tego. Ktoś przegina w druga stronę. Dzień jak codzień.

> Tzw. wzorce projektowe _wcale_ nie sa panaceum i maja tez wiele wad
> (nawet MVC ie jest idealny, niekieedy wprost kladzie performance) .
> Poza tym nie zbaczaj porymitywnie z tematu: mowa byla o _ORM_ach
> a nei MVC.

Sam zacząłeś o MVC i mi zarzucasz prymitywizm zbaczania? Chyba już późna
godzina.

Ponadto co znowu uzasadnisz? Że zorce sa złe czy dobre czy generujesz
ascii dla sportu?

>> Dziargał bym to w czymś zupelnie innym niż C++ i PHP.
> No ale czym? _Konkretnie_ w czym ?

A jaki jest problem? I dlaczego wymaga bezustannego serializowania stanu
do bazy danych? I czy tego wymaga czy mi się tylko wydaje? Ile ma
kosztowac? Jaki zespól? Zakładasz że wybieranie technologi polega na
dwoch linijkach płytkiego opisu i jednej wklejce na necie?

> Przypominam, ze byl to rok 2002 i na serwerze tylko perl, tcl , i php i
> bash.
> W czystym CGI (chocby i w bash:)?

Pytanie brzmi: po co serializujesz stan obiektu i jak czesto to robisz.
Jesli robisz to często to jest to powód dla ktorego PHP nie powinien się
tam pojawić jako że to jest z grubsza technologia wymagająca w kółko
serializacji i deserializacji. Zdecydowanie przy duzej ilości danych
pojawiłby się dedykowany serwer. Ponieważ kupowaliscie serwer w
BurkinaFaso to nie mozna było zmienić zawartości serwera, to zrozumiałe.
Ta .. ponieważ nic nie wiadomo to nic nie wiadomo.

>> A w czym: nie wiem za malo danych.
>> Jedna gówniana klasa chowana do bazy danych to nieco za mało aby mieć
>> możliwośc projektowania czegokolwiek.
> Reszta klas (a jest ich kilkadzisiat w handlerow i Views kilkaset)
> jest obslugiwana pdobnie. Ilosc nic tu nie wnosi.
> No wiec w czym ?

Dalej nic nie wiadomo. Szczegolnie nie wiadomo skad mieliście serwer na
ktorym, zakladam, byly powazne rzeczy i jednoczesnie z jakiejś znienanej
przyczyny PHP był jedyna odpowiedzią. Jakaś ściema. W 2002 byłem w
stanie wynajść shelowy serwer w dowolnym miejscu jakie chciałem. Wiem bo
wynajmowałem. Nie była to maszyna wirtualna, ale pozwalała mi postawić
dowolny serwer jaki zdołałem na niej skompilować. I nie miała łaczności
przez modem tylko przez gruby kabel sądząc po megabitach. 2002 rok to
już całkiem normalne usługi.

>> Brak abstrakcji nad tym wszystkim. Nie oznacza to że jest to źle - byc
>> może system jest tak niewielki że da się go przetestować ręcznie
>> klikając. Ale to jest właśnie przegięcie.
> Kompletnie nie rozumiem.

Niemożnośc łatwego i automatycznego testowania kodu raczej przekresla
profesjonalizm. W twoim wypadku wydaje się że kod da się testować
wyłacznie na docelowym engine wiec testowanie (o ile istniało) odbywa
się na wskroś wszystkich warstw. Kiepsko. Da się, pewnie. I tylko tyle.

>> Nie. Moje specjalistyczne nie są zwykłe. Nie mają relacji, indeksacji,
>> tabel, krotek.
> To nie zadna baza danych tylko prymitywne storage typu key:value.

Nie. To baza od której wymagam bardzo duzej wydajności przy zapisie
ponieważ dane przylatują z predkością niewiele mniejszą od prędkosci
dysku a system jest RT. Nie ma tam relacji key:value, jest wiele
strumieni i dużo kłopotów z prędkościa.

>>> obiektowe lub przynajmniej hierarchiczne bazy danych.
>> Nie są tez obiektowe ani hierarchiczne (przynajmniej nie w calości).
> j/w . Zwykle key:value

Nie. coupling danych jest nietrywialny. Dlatego jest przenoszony na
warstwę wizualizacji i warstwę zapisu, dynamicznie balansując.

>> Obsługuje miliardy elementów.
> Uuu ! Rewelka ! To mi powiedz jaki to ORM :)

Kika wyrazów dalej napisalem że nie uzywam ORM. Oczywiście możesz
ciągnąc temat dalej, nie zwracaj uwagi na to co ktoś pisze.

>>> Hehe. A kiedy powstal Hibernate znawca wie ?
>> A co ma do tego hibernate? I co ma do roku powstania hibernate wybór
>> jezyka jak PHP?
> Zarzucales mi przecie ze "dojrzalego ORMa niby go nie zastosowalem:)

Nie zarzucam nic o "dojrzałym ormie" a jedynie o jakims ormie. Zarzucam
użycie PHP i wprost pisanie w kodzie zapytań SQL like. I to wszystko z
powodu niedostępności w Polsce komputerów z czymś więcej niż goły php w
18^M^M2002 roku.

> Teraz sie placzesz i probijesz zejsc na "boczne sciezki".
> To nie ze mna . Nie jestem lemingiem.

O patrz, zupelnie jak z pół świata c# o ile jeszcze pamiętasz. Taka
maluteńka hipokryzja.

>> Jak każdy porzadny kod który wiele osob na tej grupie tworzy na
>> codzień. Wydaje Ci się że jesteś wyjatkowy?
> Jaki wyjatkowy ? Czyba w Twoim czerepie :)
> _Gdzie_ stwierdzilem ,ze jest wyjatkowy?., Cytat synek/dowod :)

Nigdzie. Żebrasz jednak o docenienie jego porządności napisania. No ale
on wygląda tak samo jak 99% kodu który oglądam na codzień. Mam poglaskać
po głowie i powiedzieć "tak, bardzo ładnie"? OK. Tak, bardzo ładnie.
Moving on.

> A co powiesz o tym bardziej powaznym (parsingi) czy grafika (Fortran).
> W sensie "porzadnosci" kodu i w ogole podejscia ?

Nic. Nie obchodzi mnie to. Fortrana znam wyłacznie read only a parsing
nie jest moja dziedziną. Ale oczywiście nie ma sprawy skoro tego
oczekujesz: "Tak, bardzo ładnie". Moving on.

>> Widziales kiedys współczesny zespół programistów z coding standardem i
>> code review?
> Ba! Czy widzailem :)? Ja mam na sumieniu kilka (chyba 3) coding styles
> dla takich wlasnie borokow jak Ty :)

Interesujące. Dlaczego borokow?

>> Zdajesz sobie sprawę że nikomu nie imponujesz bo to jest najzwyklejszy
>> kod jaki mozna znaleźć?
> Wali Ci juz calkiem:) Ten kod byl po to aby Ci udowodnic
> ze PHP _nie jest_ fatalnym jezykiem.

Nic nie udowodnił. Mission failed. Wczoraj był tak samo fatalny co
dzisiaj. Ma tak samo chaotyczną biblotekę standardową jak wczoraj. Ma
tak samo popsute operatory co wczoraj. Jest tak samo niekompatybilny sam
ze sobą jak wczoraj. Nie ma żadnych zalet w stosunku do czegokolwiek
poza brainfuckiem. Nie jest persistent, każda sesja zwiazana z www musi
się deserializować. Itd itp. Internet jest zbiorem narzekań na php,
najczęsciej na forach napisanych w php.

>> No i ? Nie bardzo rozumiem. Używam tcla na codzień. Nie lubie tego
>> języka z wielu powodów (sztuczna obiektowość, eval(), powolność,
>> debilne embedowanie). Nie robi na mnie wrażenia.
> O curwa ! Zostaw tego Tcl-a w spokoju.
> To drobiazg pokazujacy ze COM/ActiveX da sie uzywac _rowniez_ w Tcl-u :).

W TCLu da się wszystkiego używać wliczając w to rzeczy których autorzy
nie wymyslili. No i? Co to udowania? Komu udowadnia? Zwiekszasz celowo
entropie internetu?

>> Pythona używam jako narzedzia. Mam uklęknąć przed kawałkiem kodu który
>> łaczy kilka trywialnych technik programowania gumą do żucia?
>> Potrzebujesz abym się ukorzył?
> Tak? A umiales do dzisiaj dobrac sie do np. Worda dynamicznie poprzez
> ActiveX ?

Nie wiem. Kiedys, chwile po studiach, napisalem system "składu tekstu"
na bazie fop, xmla/xsla i VisualBasica a potem javascriptu (cscript) i
kilku innych narzędzi. Dobierałem się tam do komponentów Worda sterując
jego edytorem ,ale nie wiem czy to jest to o co pytasz. Głownie dlatego
że nie wiem po co pytasz i jaki ma to zwizek z czymklolwiek. Sterowałem
też CorelDRAW, czy to się liczy i czy coś wygrałem?

> Przeciez w C++ to jest niemozliwe (nie ze zupelnie neimozliwe,
> ale nie w ten sposob/w pelni dynamicznie).

Ufff, nastepny strzał nie wiadomo w kogo i po co. A co to ma znowu
udowaniać?

>>> A ja w Clipperze napisalem edytor graficzny :).
>> Zabawne jak absurdalne argumenty wydają się dyskutantom dawać przewagę.
> Dlaczego zabawne ?
> Twierdzisz, ze w Clipperze nie da sie porzadnie napisac edytora graficznego
> typu Paint ?

W każdym języku turing complete da się to zrobić zapewne. Teraz
przedstaw proszę jakiś argument że warto to zrobić w Clipperze a
nastepnie chwalić się tym na grupie inny niz entropia.