🚀 go-pugleaf

"Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> wrote:

> Jesli mowimy o Pythonie jako o general purpose language, to nie widze.
> Temat  "Python - wylacznie sklejacz" to co innego.

Nie o to chodzi ale, to nie teraz.

>> Eby sie myli (kiedy to Eby pisal ?).
>> Python ma bindingi do wiekszosci standardow
>> czy duzych frameworkow komponentowych.
>> Dojrzale dosc bindingi.
>
> Ale to sa zaledwie protezy.

Jakie Panie Kochany  protezy.

PythonWina nazywasz Pan proteza ?
IronPython tez ?
PythonNet tez ?
Jython to proteza ?
np. omniORBPython tez ?
mozna by tak wymieniac

Proponuje _naprawde_ sei zorientowac w swiecie
Pythona zanim Pan zacznei nazywac cos mianem
protezy.

Proponuje tez inaczej.
Prosze podawac haslowo o jaki standardu czy framework chodzi
i Pan bedzei podawal ich odp. Javowe a ja Pythonowe,
Nie chgodzi o jaka s glupia walke ale poprostu o wzajemne
poszerzenie horyzontow  (innym tez sie moze przydac).

> Wszelkie bindingi sa z natury protezami. Zreszta,
> korzystajac z przykladow Eby: jakie to niby dojrzale
> bindingi sa w przypadku
> JDBC, JNDI i OSGI?

Jython (mowie popwaznie).
Jesli chodzi o samo JDBC to moglby Pan zauwazyc chociaz
ze w Jythonie oprocz surowego korzystania z Javowego
JDBC (jak z kazdegodostepnego w Javie
modulu) jest dolaczany pythonowy zxJDBC ktory
wlasnie podnosi poziom programowanie JDBC na
bardziej friendly.
Jets on oparty na najlepszym z pythonowych
bindingow do ODBC - na mxODBC.

> Prosze mi to pokazac. Albo nawet inaczej: idzie Pan na
> strone JCP z lista wszystkich JSR i one by one niech Pan
> sprawdzi jakie to sa  odpowiedniki w Pythonie.
> Poczynajac od JSR-1 czyli Real Time. (no dobra, to  byl zart).

> Teraz uwaga: to wszystko nie ma az takiego znaczenia, jesli bedziemy
> traktowac Python jako glue language, a nie jako general purpose language.

Po pierwsze od samego poczatku truje ze _tak_ glownei nalezy
Pythona tkaktowac. Glownei ale nei wylacznie.
Dlaczego . Ano dlatego ze Pan wiara w tzw jezyki
general purpose swiadczy ze sei w tej kwestii nei dogadamy.
Uwazam jezyki general purpose za najgorsze zjawisko i najgorszy
syf (rowniez mentalny a nie tylko techniczny) dzisiejszej informatyki.
Bierze sie on oczywiscie z kilku przyczyn z ktorych jednak jest zwykla
neiwiedza i zasklepienie sie w jednym jedynym np. C++ czy Javie
Nazwanei C++ czy Javy jezykiem 'general purpose' wywoluje u mnei
skurcze zoladka . Nie tylko ze smiechu.
Niech mi Pan laskawie wytlumaczy co to w ogole za chore
okreslenie : general purpose language
To term jest chory chory _w zalozeniu_ !
Karmienie mlodziey programistycznej takimi pierdolami powoduje
najgorsze z mozliwych skutki.
Mianowicie slepa wiare ze poznanie _tylko_ C++ , Javy, C#, Pythona
 itp (sobie prosze wygrac) _wystarcza_ aby byc spokojnym ze w tym jezyku
zrobi sie _wszytsko_. Czyli zdobylismy zlotego graala a reszta to syf
I robi sie.
W C++ sie 'skleja' componenty COM
W Perlu sie pisze aplikacje 'obiektowe'.
W Tcl pisze sie 'numeryke' w stylu:
proc radius {x y} {
  set r [expr sqrt($x * $x + $y * $y)]
  return $r
}
Wszystko oczywiscie w tym _jednym wlasciwiem_ jezyku
No bo przeciez to general purpose i taki wypas !
Tak tak. Javy to rowniez tyczy.

> Tyle ze glue language nie specjalnie przemysl interesuje: zalozenie jest
> takie, ze jak bedzie trzeba posklejac, to ten programista .NET czy Javy 
> juz
> sam sobie klej i wybierze.

No wlasnei ! Sobie wybierze.
Tu Pan zostawia dowolnosc ?
Glue language jest _rowne_ wazne jak ten niby general purpose

Wyobraza Pan sobie prace prace w COM bez VB ?
Bo ja nie.
_Cale szczescie_ ze tu wyboru nie bylo na poczatku
bo by ludzie zaczeli sklejac COMy w C++ czy Tcl
A owszem robia to - tragedia. - no ale przeciez
C++ to _general purpose_ !.

>> O interfaces to juz nawet nie wspomne.
>> Zope interfaces od kilku lat juz sa defacto standardem
>> w powazniejszych aplikacjach pythonowych.
>
> Pan to z opowiesci zna, nie z zycia, prawda?
> Nie widzi Pan roznicy miedzy np
> specyfikacja servletow a 'interfejsami' z Zope?

Ano nie widze duzej bo komponentowosc w Zope
(ktorej interfaces sa zaledwie mala czescia) nie odbiega
od koncepcji serwletow.

> Zapomnial juz Pan, ze Nuxeo wlasnie poslalo do diablow
> Zope z powodow  niedociagniec owego Zope?

Pan sam nie wie o czym Pan mowi.
Panie Kochany Aleksandrze.
Prosze sei lepiej zorientowac bo tak sie zlozylo
ze od dobrych kilku lat jestem wlascicielem
domen zope.pl i python.pl wiec chocby przez
domniemanie mogl Pan zalozyc ze _wiem_
o czym mowie.

Otoz cale nuxeo oparlo sie na _starym_ Zope
ktore ani dobrych interfaces nie mialo (tych z Zope3)
ani nie stosowalo innych tego typu rozwoazan
a komponentowosc byla np bardzo prymitywna na
zasadzie podkatalogow w katalogu Product
Co wiecej . te produkty musialy byc _specjalnie_ pod
Zope pisane a nei mogly byc to np ogolne pakiety Pythona
(wtedy w ogole jeszcze podejscia tak jak w Javie
jar-owego w Pythonei nie bylo.
Ale mniejsza o sama pakietowosc.
Chodzi o to ze te 'komponenty' w starym Zope
byly oparte na dziedziczeniu klas Zopa wprost
a nie na 'interfaceowaniu' i pluginowaniu
ogolnych pakietow pythonowych
Po prostu stare Zope sie nadawalo a i owszem
ale jako serwer aplikacyjny do wybitnie webocentric
programow natomaist jako komponentowy framework ogolnego
przeznaczenia delikatnei mowiac sredni - nawet do miejszych rzeczy
niz DDM do ktorego zastosowalo go nuxeo
Po prostu nuxeo popelnilo grzech dzicinstwa polegajacy na tym
ze tyle w tym Zope bylo juz rzeczy gotowych (poczynajac od
autoryzacji, porzez publishing , poprzez wieloprotokolowosc dostepu
poprzez maly framework do CMS (CMF), poprez przeciez
calkiem neizlej do takich zasosowac bazie obiektowej
zintegrowanej z pythonem i Zope - w sposob daleko lepszy niz
gdzie indziej, poprzez dosc porzadny bo prosty system templates,
na pelnej bezproblemowej komponentowosci
i bezproblemowej multiplatformowosci konczac).
Nie zauwazly jednak ze do takich zastosowan jak oni
trzeba albo uzyc powazniejszych podejsc, a nie
'rzucac sie na klawiature'.

Czesc tych zalozen spelnia dopiero nowe Zope
(wlasnie oparte o komponentowosc) a i tak nie wszytskie.

> Glupi Pan przeciez nie jest, jak niby mozna porownywac ogrom specyfikacji 
> i
> implementacji w swiecie J2EE do pythonowych interfaces.

Panie Alku, zope.interfaces to zaledwie jeden z przypadkow
tego co _musi_ byc uzyte do nawet malych aplikacji jesli
maja byc _produkcyjne_ . To zaledwie podstawa,
a Pan ja porownuje z J2EE :)
Prosze troche powazniej.
Owszem istneija w Pythonie odpowiedniki i innych czeci J2EE
(tylko mi prosze wytlumaczyc co chodzi z skald J2EE bpo z tym
ciaglke mam problemy - zapominam).

> To jak porownywac  swiss knife do, no nie wiem, branzy samochodowej.
> Ponownie: te dywagacje sa bezprzedmiotowe, jesli widziec w pythonie 
> jedynie
> glue language.

Wlasni Pan ma syndrom general purpose.
Pan uwaza ze Java to do wszytskiego.
Ja uwazam ze _dobry_ glue languae to dzis
podstawa dobrego i wydajnego programowania.
W takich podejsciu widze przyszlosc.
Python jest tu idealnym kandydatem.
Trudno znalezc lepszego.
Inne jezyki sa albo zbyt prymitywne czy 'zakrecone'
(Tcl, Perl) a inne staja sie zbyt skomplikowane
(Ruby, Groovy).
Widzi Pan lepszego kandydata ? Chetnie uslysze.

>> >> Akurat Python jest typowym przykladem: znajdz gotowe
>> >> To typowy glue language _w zalozeniach_.

Raczyl by Pan to zauwazyc wreszcie.
Od kilku postow to podkreslam a Pan mi wciska ciagle
ze uwazam Pythna za jedynei slusznego 'general purpose'.

>> Panie kochany, Pan widzial Pythona w ogole ? :)
>
> A Pan gdzie go widzial?

:)

>> Groovy i Jython maja ten sam binding do Javy
>>i w obu sie robi to identycznie latwo.
>
> Teoretyzuje Pan. Ja to widzialem na zywo.

No to prosze mi pokazac roznice w tej trudnosci
Ja nie moge pokazac bo jej po prostuy _nie widze_.

>> Wlasnie do sklejania _trzeba_  prostoty.
>> Skrajnej prostoty aby sie nie uczyc nie wiadomo po co "wypasionego"
>> sklejacza.
>
> Zgadza sie. Python jest w tym przypadku za wypasiony, za skomplikowany.
> Smalltalk byl znacznie bardziej elegancki i prosty (ale nie nadawal sie do
> sklejania).

Panie !.  Ratunku ! Jesli Python jest bardziej skomplikowany
od Smalltalka to ja  naprawde wysiadam :(

> No wiec chodzi o to, zeby traktowac Python jako glue?

No przeciez kurde on od poczatku byl tak projektowany
aby spelnic to jedno z jego podstawowych zalozen !
Byc glue language.

> Nie bede sie klocil,  ale niech Pan w takim razie przestanie
> opowiadac jaki to Python jest mocny we
> frameworkach - bo nie jest.

Dobrze. Uscislijmy.
O jakie frameworki Panu chodzi ?

> Pan nie zauwazyl, ze PJE tez z tego samego punktu widzenia pisal: z punktu
> widzenia platformy. Moze nie mial racji widziec w Pythonie platforme, ale
> rozpatrywac taka mozliwosc mial prawo.

No pewnie ze Pythona nie nalezy rozpatrywac jako platforme !
Dlatego napisalem ze PJE plotl bzdury.
Bo to najwieksza bzdura (znow to slowo:) tak myslec.
Ba ! Za najwieksza zalete Pythona (i za to kocham - bez skojarzen
GvRa :) jest wlasnie to ze Python nigdy _nie chcial_ uchodzic
za platforme ale tylko laczyc rozne swiaty.

Wlasnie np uznanie sie (dosc jednostronnie i samozwanczo)
za platforme jezyka C++ uwazam za jedna z najwiekszych
pomylek historii jezykow.
Rowniez uznanie sie za jedena sluszna platforne Jave.

Dlatego moim faworytem jest podejscie .NETowe
Uwazam ze spelnielo sie wreszcie jednoz moich
marzen w sensie srodowiska programistycznego
(choc to zaledwie mala czesc moich marzen faktycznych)
i mam nadzieje ze .NET (nie nie ! nei samo C#)
wygra z Java. Ku dobru ogolnemu.
Nie  z je zykiem Java, ale z jej odseparowanemu
hermetycznemu srodowisku i uwazanie sie
za 'general purpose'.

Niestety zauwazam wyraznie wplyw owego
podejscie 'general purpose' czyli utozsamianei .NET
z C#. Takei podejscie to faktyczie nie ma wiekszego
sensu bo Java juz jest.
To jedynie (czyli nie MS czy Sun) ale wystepowanie
w glowach niedouczonych (a raczej niedoswiadczonych)
programistow podejscia 'general purpose'  bedzie
przyczyna kleski tej jakze cennej wlascosci .NET:
wielojezykowosc i wspolne jednolite API/framework.

> A jest? Zagladal Pan na strone Chandlera ostatnio?

Czy zagladalem ?
Miesiac temu sciagnalem jakas jego wersje.

> Powazni ludzie tez sie lubia bawic.
> Jakby mi ktos zaplacil za bawienie sie,
> to bym sie bawil. Why not?

Widzail Pan aby ktos placil za bawienie sie ?
Bo ja nie.

>> Hehe :)
>
> Alez to bardzo ciekawy temat (ciekawszy niz Python czy Groovy). Google

Aha.
Czyli Pan zna Google od srodka i wie co tam
sie robi _naprawde_ ?

PS: Przepraszam za zbytnie gadulstwo

AK