Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:

> On 2015-11-22 17:44, AK wrote:
>>> Nie, pokazaleś dośc żałosny kawałek kodu w PHP który coś (co?) miał
>>> udowodnić. Udowodnił że w każdym języku można wymysleć kwadratowe
>>> koło, równie kanciaste.
>> 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.

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.

>> No ? :)
>> Tak mi sie wydaje ze ciagle tylko szpanujesz "swiatlem odbitym"
>> (cudzy kod) i idiotyczna krytyka "wszystkiego" co nie ma w sobie ++).
>
> Nie. Krytykuje pokazywanie kiepskiego PHP

To nieprawda, ze PHP bardzo kiepskie.
Oczywiscie nie dorownuje IMHO Pythonowi, ale jest calkiem przyjemnym jezykiem.

> zeby za chwile uzasadniać to Pythonem w celu dorzucania gówna do ogniska.
> Ciągniesz temat PHP z prostej przyczyny: tam każda teza jest dobra i łatwa do
> podsycania flame.

Nasmiewales sie, ze bym wszedzie bezkrytyczie zasosowal PHP z czystym SQL
zamiast ORMa no wiec Ci dalem odpowiedz ze nie. Ze lepsza alternatywa sa
wlasnie obiektowe bazy danych i dalem ci przykad takeiej w Pythonie,
a ty sie czepasz, ze nie wrocilem do PHP :_) ? Nie rozuimiem cie czlowieku.

>> A co sadzisz o mym parsingu jezykow prograowania (szczegolnie
>> ten do C#) ? Zauwazyles ze gramatyka nie jest scisle LALR (ani LL)
>> i nie ma problemow z "ambiguities" ?
>
> Nie jestem ekspertem od gramatyk i doskonale wiem że to złozony problem.

Wcale nie taki znow zlozony.
Jest malo popularny, ale nie niewiadomo jak zlozony.
Prawdziwe schody zaczynaja sie pozniej - po parsingu.
AST to dopiero malutki poczatek.

> Nie wypowidam się na tematy o ktorych za mało wiem.

No a o ORMach i bazach danych sie wypowiadasz ?
O nich duzo wiesz ?

>> PS: Wiesz ze _jedyny_ jezyyk ktorego nie udalo mi sie
>> w pelni i w pelni poprawnie sparsowac jest twoj ukochany C++ ?
>
> 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 wiem. Nie znam.

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" ?

> 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.
Po drugie: Jesli nie lubisz baz to dlaczego sie wypowiedasz na temat ORM itp?
"Nielubienie" to podejscie emocjonalne. a nie inzynierskie.
Implikuje zasadnicze bledy w ocenie (ORM , baz danych itp).

>> Taki MentorGraphics tez posiada kilka wylacznie swoich
>> wewnetrznych/"wlasnorecznych" jezykow o ktorych "nikt nie slyszal".
>
> Nie wątpie. To jest wewnętrzne vendor lock-in o ile nie da się tego uzasadnić
magiczną wydajnością
> lub magiczna jakością. Nie wykluczam że ich zagadnienia wymagaja zmiany paradygmatu
na bardziej
> naturalnie opisujacy zagadnienie i wtedy da się to uzasadnić.

No widzisz? A moj OQL mimno ze w duzej czesci zgodny ze standardem
ODMG (tyle ze z np takim rozszerzeniem, ze wyraznia moga byc pelnoprawnymi
(oprocz generatorow) wyrazeniami Pythona - (chyba widziales ze w gramatyce
jest wlasciwie uskuteczniona pelna gramatyka wyrazen Pythona,
prawda).
Polecam Ci sie zorientowc chocby tu:
https://pl.wikipedia.org/wiki/Object_Query_Language
a tam:
"
OQL, jako język zapytań dla obiektowych baz danych, przełamał pewne fałszywe
stereotypy
funkcjonujące
w społeczności baz danych, między innymi ten, że hermetyzacja i języki zapytań są
wzajemne
sprzeczne.
Uczynił również wyłom w podobnym stereotypie głoszącym, że programowanie obiektowe
wymusza
dostęp do obiektów wyłącznie przy pomocy metod zdefiniowanych przez programistę;
bezpośredni dostęp do stanu obiektu (jego atrybutów) jest złamaniem zasad
obiektowości.
OQL pokazuje, że te zasady i ograniczenia wynikają bardziej z przesłanek
ideologiczno-spekulacyjnch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^
niż możliwości technicznych.
"
Dodatkowo: "Podstawową wadą OQL jest zbyt luźne zintegrowanie z interfejsami
i konstrukcjami programistycznymi"
U mnie ta wada nie wystepuje, bo AST to po prostu drzewo obiektow normalnych klas
Pythonowych. Nie trzeba zadnych runtimeow, byteinterpreterow itp.
kazda klasa w AST ma po prostu normalna zwykla metode execute().

W dodatku:
" Najbliższy idei OQL jest popularny obecnie interfejs Hibernate dostępu do
relacyjnych
baz danych z poziomu języka Java." A wiesz kiedy powstal HQL?
W dodatku w moin ZOQL nie ma zadnej niepotrzebnej warstwy (przekadki OQL => SQL)
tylko _wprost_ realizacja zapytanie na obiektowej bazie danych (ZODB).
I to wszysko w 2004/2005 roku (czesc ogolnopolskiego sytemu zamowien portalowego
dla Urzedu Zamowien Publicznych).

No czy w/g Ciebie moge sie choc "nieco" uwazac za prekursora (a przynajmniej
probujacego nim byc:) w Polsce zaawansowanego uzywania obiektowego
podejscia do baza danych ? Prawdziwie obiektowego, a nie za pomoca
wytrychu ORMowego.

> 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 :)

>> 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 ?
Moze rownie dobrze umrzec (a nawet szybciej) niz jezyki
bedace wlasnosci firm.
Hibernate jest przeciez na GPL i jesli autorom sie znudzi (albo zywczajnie zejda
z tego padolu) a reszcie sie "nie bedzie chcialo" albo "nie podolaja" to nie ma
zadnych
konsekwencji prawych ani licencyjnych/zabezp;ieczenia dla klientow/uzytkownikow.
W przypadku gdy firma zwyczajnie sprzedaje jezyk jako czesc softu
to juz prawnicy klientow jej wytlumacza ze lepiej jednak tenm jezyk
wciaz supportowac

>> Chlopcze, ja nie mam _najmniejszych_ kompleksow (no jest jeden powazny:
>> znajomosc angielskiego:) ani przed Amerykanami ani Niemcami czy inna nacja
>> i nie uwazam. ze to co sam/my stworzymy z zasady musi byc od ich gorsze :)
>
> To praktycznie definicja Not invented here. Bardzo szkodliwego antywzorca.

Cois ci sie zwyczajnie pozajaczkowalo :).

> https://en.wikipedia.org/wiki/Not_invented_here

Nieprawda. Niekiedy jest to wzorzec baardzo wskazany
(szczegolnie wsrod mlodziezy ktora to zwykle od razu "rzuca sie na klawiature"),
a niekiedy wrecz "kladacy" projekt (tylko ORM/cokolwiek, bo.. bo tak!)

>> Ty tego nie zrozumiesz (bos mentalny niewolnik swego feudala:),
>> ale ja nie uwazam, ze "moje jest gorsze" bo polskie.
>> _Nigdy_ tego nie zrozumiesz.
>
> Przemawia przez Ciebie w tej chwili zwykła gówniana polityka.

Mowilem ci juz synek, kogo Grecy uwazali za "idiote".
Gosci ktorzy uwazali ze polityke to gowno/niewazna.
Poszukaj sobie etomologii (szkoda ze Kviat nie zlapal sie na haczyk
gdy napisalem "entomologii" - liczylem ze mnie "zjedzie" za gramatyke:)
slowa "idiota".

>> Co ty myslisz ze ODB nie maja warts cacheowania/balancingu/optymalizacji/
>> hierarchizacji zapytan czy systemu(ow) transakcji ?
>
> 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_.

>> Ty naprawde jestes niedoukiem czy tylko fanatylkiem/oszolomem :)
>
> Nie wiem, ale podoba mi się twoje rozkręcanie w kierunku zwyklego prymitywnego
chamstwa.

Chamem bylbym, gdybym cie nieslusznie oskarzal o nieuctwo.
To jest stwierdzenie faktu. Po prostu sie doucz w tym zakresie i problem zniknie.
(albo sie nie wypowiadan na ten temat - dokladnie tak jak w przypadku parsingu).

>>> ORM jest narzędziem. Wytrychem jest sklejanie SQLa (mySQLa) za pomocą
>>> stringów które praktykuje się w wiekszości książek do PHP i kursów
>>> online. Przypuszczalnie też firm robiących na tym szybką kasę.
>> Jesli w 2002 na palcach jednej reki mozna byl;o znalesc
>> providera ktory dostarczal _cokolwiek innego_ poza czystym nieskazonym
>> PHP, a oprogramowani z zasady mialo "chodzic" na dowolnym prymitywnym
>> site/serwerze to sobie mogles "narzekac na PHP".
>
> 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.
Ona wcale nie decyduje o jakosci jezyka.
jest tylk mala jej czescia

>> Ja sie zwyczajnie
>> wzialem do roboty i zrobilem to i to w podejsciu dosc scisle MVC
>> (tez jeszcze malo w tych czasach popularnych).
>
> 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), ai zis vczresto spotykam
kod (gloownie w Javie) gdzie scisle i bezkrytyczne trzymanie sie
tzw "wzrorca projketowego" powoduje ze kod staje sie sieczka.
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.

>> Ty bys to dziergal w C++ zaczynajac od protokolu http.,
>> a najpewniej raw socketow :)
>
> Dziargał bym to w czymś zupelnie innym niż C++ i PHP.

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

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

>>> W PHPie widać nie tyle nagięcie co przegięcie.
>> Ja nie widze zadnego przegiecia.
>> Wykaz go.
>> Hint: SQL injection ? O to ci chodzi?
>
> Nie. Twój kod nie da sie łatwo testować. Klasy są bezpośrednio implementacjami
jakiejś konkretnej
> metody komunikacji z engine.

Nie rozumiem . Jakiej komunikacji ? SQL?
No tak :) To prawda . SQL byl przyjety aprioru jako jedyna
komunikacja ze "storage" i na tym poziomie abstrakcja nie miala
sensu. Poniewaz logika (lookapy, viewsy) bylo oparte wlasnie na
tym SQL (no nieco zmodyfikowanym - vide HSQL) i to czestow sposob
dynamiczny (user tworzyl pytania) wiec wprowadzenie na tym poziomie
abstrakcji stktkowalo by wlaciwie az do szkolenia userow/admninow
z nowego jezyka parametryzowania aplikacji.

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

> Nie. Moje specjalistyczne nie są zwykłe. Nie mają relacji, indeksacji, tabel,
krotek.

To nie zadna baza danych tylko prymitywne storage typu key:value.

>> obiektowe lub przynajmniej hierarchiczne bazy danych.
>
> Nie są tez obiektowe ani hierarchiczne (przynajmniej nie w calości).

j/w . Zwykle key:value

>> Byle wiekszy rysunek w CAD to _miliony_ linii
>> i chcesz to trzymac i obslugimac poprzez jakis ORM?
>
> Obsługuje miliardy elementów.

Uuu ! Rewelka ! To mi powiedz jaki to ORM :)
Chetnie skorzystam ! Naprawde :)
Anstrahujac od tego czy byl on dostepny w 2002 ?

>> 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:)
Teraz sie placzesz i probijesz zejsc na "boczne sciezki".
To nie ze mna . Nie jestem lemingiem.

>> To prawda (bo tak miala byc:), ale uwazam ze jest porzadnie napisana
>> nawet ta wklejka :)
>
> 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 :)
Ale porzadny jest prawda ?:)
A co powiesz o tym bardziej powaznym (parsingi) czy grafika (Fortran).
W sensie "porzadnosci" kodu i w ogole podejscia ?

> 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 :)

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

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

> 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 ? Przeciez w C++ to jest niemozliwe (nie ze zupelnie neimozliwe,
ale nie w ten sposob/w pelni dynamicznie).

>>> Gówno straszne. Pisalem w tym zbyt dawno temu żeby pamiętać. Nie
>>> zamierzam nawet tego dotknąc kijem z racji faktu że nie lubie baz danych.
>> No cus podobnego ?
>> 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 ?

AK