🚀 go-pugleaf

On Wed, 9 May 2007 21:15:18 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:
 
>No wiec prosze nam opowiedziec: co to sa, *konkretnie*, za mechanizmy? To
>pytanie pada po raz trzeci, mam nadzieje, ze nie zostanie tym razem zignorowane. 
>Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa charakterestyczne
>wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
>Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych nie
>moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
>statycznego systemu typow. Prawde mowiac, nie kojarze zeby tych dobrodziejstw
>bylo duzo. Wiekszosc artykulow pro-dynamic-typing skupia sie na zwiezlosci
>kodu, co jest takim sobie dobrodziejstwem.
>Nawiasem mowiac: http://dirtsimple.org/2004/12/java-is-not-python-either.html
>Ten tekst ladnie uwypukla roznice kuturowe: "sklec to sam" vs "uzyj gotowego". 
>

SparkAda umozliwia formalna weryfikacje programow w jezyku Ada,
wlasnie w oparciu o te statyczne typy:

http://www.praxis-his.com/sparkada/index.asp

A.L.

On Wed, 9 May 2007 21:15:18 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:

 
>
>No wiec prosze nam opowiedziec: co to sa, *konkretnie*, za mechanizmy? To
>pytanie pada po raz trzeci, mam nadzieje, ze nie zostanie tym razem zignorowane. 
>Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa charakterestyczne
>wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
>Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych nie
>moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
>statycznego systemu typow. Prawde mowiac, nie kojarze zeby tych dobrodziejstw
>bylo duzo. Wiekszosc artykulow pro-dynamic-typing skupia sie na zwiezlosci
>kodu, co jest takim sobie dobrodziejstwem.

Nawiasem mowiac, gdy team jest wiekszy (na przyklad tak 40 - 50 osob)
to czlonkowie tego etamu komunikuja sie przy pomocy interfejsow (w
sensie komunikacji werbalno - pisemnej) Wielokrotnie juz pisano na
temat dobrodziejstwa interfejsow, zwlaszcza przy wprowadzaniu jezyka
Modula-2. Rowneiz wielokrotnie pisano o ortogonalnosci modularyzacji i
obiektowow=sci, zwlaszcza pisala o tym szkola Wirtha, a specjalnie
neijaki Szyperski w ksiazkach o komponentyzacji i licznych papierach. 

Dyskusja nad pzrewaga jezykow dynamicznie typowanych nad statycznymi
wydaje sie byc klasycznym przykladem bicia klasycznej piany. Jak dlugo
ktos pracuje w jednoosobowym "garage development" to mu wszystko
jedno; gdy nad problemem pracuje kilka osob, to juz nie.

A.L.

Aleksander Galicki napisał(a):

> Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa charakterestyczne
> wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
> Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych nie
> moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
> statycznego systemu typow.

O dziwo jest to w pewnym stopniu błędne założenie.

Nie istnieje coś takiego jak statyczny system typów. Każdy statyczny 
system typów to kombinacja liczby dziur ze stopniem skomplikowania 
samego typowania. Java i C# są cały czas jeszcze blisko pierwszej 
granicy (choć ciągle się przesuwają). Pochodne Haskell'a są już raczej 
blisko tej drugiej.

No więc, prawdziwy powód jest taki - skomplikowanych systemów typów 
normalni ludzie nie są w stanie wygodnie używać. A kiedy jest dużo 
dziur, wtedy trzeb często przez te dziury przechodzić. I przy statycznym 
systemie typów jest to zawsze bardzo paskudne i niewygodne.


mp

Witam

Aleksander Galicki wrote:

> zignorowane. Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) 

Dynamiczne to nie znaczy bez typowe.

Języki ogólnie można klasyfikować jako pomiędzy dynamicznymi i statycznymi,
oraz o typizacji silnej i słabej. Python jest dynamiczny, ale ma całkiem
mocny system typów.

Ada, Java i C++ są statyczne i też mają silne systemy typów.

C jest statyczny i ma słaby system typów.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> Weryfikowalnosc _czego_?

No chyba jasne czego ?
To nie jest trudne zgadnac.

> No wiec prosze nam opowiedziec: co to sa, *konkretnie*, za mechanizmy?
> To pytanie pada po raz trzeci, mam nadzieje, ze nie zostanie tym
> razem zignorowane.

Zostanie.
Nie mam czasu na darmnowe konsultacje
Odsylam wiec do Pythona.
Tego jest za duzo a ja nie mam tyle czasu.

> Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa 
> charakterestyczne
> wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
> Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych 
> nie
> moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
> statycznego systemu typow.

Panie Galicki, prosze nie tworzyc nowej logiki :).

> Prawde mowiac, nie kojarze zeby tych dobrodziejstw
> bylo duzo. Wiekszosc artykulow pro-dynamic-typing skupia sie na zwiezlosci
> kodu, co jest takim sobie dobrodziejstwem.

To akurat najmniej wazna rzecz. W ogole dziwne.
Ze brak static-typing to wieksza zwiezlosc kodu ?
No nie no bez przesady.
Pan zartuje albo to jakis 'hakier' napisal jako very big advantage :)

> Nawiasem mowiac: 
> http://dirtsimple.org/2004/12/java-is-not-python-either.html
> Ten tekst ladnie uwypukla roznice kuturowe: "sklec to sam" vs "uzyj 
> gotowego".

A tak, to znany tekst.
Jak i ten: http://dirtsimple.org/2004/12/python-is-not-java.html
Po trosze beletrystyka, ale pisana przez porzadnego goscia :).
Oba dosc przestarzale (2004) wiec kilka rzeczy sie zmienilo w miedzyczasie

Nie zauwazylem  natomiast gdzie uwidacznia rozniece :
Sklec sam : w jakim jezyku ?
Uzyj gotowego: w jakim jezyku ?

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne)

Nie zauwazylem tego wczesniej.
Jesli Pan uwaza ze jezyki dynamiczne sa beztypowymi to.. (..)
Python jest jezykiem dynamicznym ale jest _w pelni_
jezykiem 'typowym'.
Nie ma obiektu w pythonie ktora nie ma scisle okreslonego typu.
Co wiecej.
Typ ten jest okreslany raz i nie mozna go zmienic.

Prosze nie miaszac dwoch zupelnie ortogonalnych pojec.

AK

Uzytkownik "A.L." <fela@2005.com> napisal:

> SparkAda umozliwia formalna weryfikacje programow
> w jezyku Ada, wlasnie w oparciu o te statyczne typy:

Jest to warunek konieczny, ale nie wystarczajacy.

AK

Uzytkownik "A.L." <fela@2005.com> napisal:

> Nawiasem mowiac, gdy team jest wiekszy (na przyklad tak 40 - 50 osob)
> to czlonkowie tego etamu komunikuja sie przy pomocy interfejsow (w
> sensie komunikacji werbalno - pisemnej) Wielokrotnie juz pisano na
> temat dobrodziejstwa interfejsow, zwlaszcza przy wprowadzaniu jezyka
> Modula-2. Rowneiz wielokrotnie pisano o ortogonalnosci modularyzacji i
> obiektowow=sci, zwlaszcza pisala o tym szkola Wirtha, a specjalnie
> neijaki Szyperski w ksiazkach o komponentyzacji i licznych papierach.

Panie A.L. tak dobrych interfaces jak w Pythonie nie znajdzie Pan
ani w Javie ani w wiekszosci innych jezykow 'mainsteamowych'.
Proponuje sie zorientowac wpierw jak sie pisze wieksze projekty w Pythonie.
Wie Pan ja jestem _fanem_ interfaces (szczegolnie w takiej postaci
jak ja propagowal prof.Subieta - czyli pojecie ról) a jakos swietnie
czuje sie w Pythonie.
O dziwo _o wiele lepiej_ niz w jezykach ktore takowe interfaces maja
(Java, C#).
Nie dziwi Pana ta (pozorna) sprzecznosc ?
Pytanie obok: Jakie jest Pana zdanie na temat ról  Pana Subiety ?

> Dyskusja nad pzrewaga jezykow dynamicznie typowanych nad statycznymi
> wydaje sie byc klasycznym przykladem bicia klasycznej piany. Jak dlugo
> ktos pracuje w jednoosobowym "garage development" to mu wszystko
> jedno; gdy nad problemem pracuje kilka osob, to juz nie.

Taaa Znamy to znamy.
Powiedz Pan to np Google.
No chyba ze to dla Pana tez garaz.
Pan ma nadal bardzo male pojecie o Pythonie i o sposobach
i konstrukcajach sluzacych w nim do 'bezpiecznego' pisania
a wypowoiada sie jak znawca tematu.
Dlaczego ?

AK

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> > Weryfikowalnosc _czego_?
> 
> No chyba jasne czego ?
> To nie jest trudne zgadnac.

Np tego czy system jest deadlock-free, albo ze sie zatrzyma kiedys? :-)

> > No wiec prosze nam opowiedziec: co to sa, *konkretnie*, za mechanizmy?
> > To pytanie pada po raz trzeci, mam nadzieje, ze nie zostanie tym
> > razem zignorowane.
> 
> Zostanie.
> Nie mam czasu na darmnowe konsultacje
> Odsylam wiec do Pythona.
> Tego jest za duzo a ja nie mam tyle czasu.

Ach, tego jest _tak_ duzo, ze nawet jednej rzeczy sie nie wymieni :-) A
konsultacje? No coz, ja nie place swoim adwersarzom by udowodnili ze maja
racje. Wole nie zaplacic i pokazac, ze adwersarz tych argumentow nie ma.

> > Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa 
> > charakterestyczne
> > wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
> > Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych 
> > nie
> > moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
> > statycznego systemu typow.
> 
> Panie Galicki, prosze nie tworzyc nowej logiki :).
> 

Slucham?

> Nie zauwazylem  natomiast gdzie uwidacznia rozniece :
> Sklec sam : w jakim jezyku ?
> Uzyj gotowego: w jakim jezyku ?

"While Python is more powerful as a language, Java beats the crap out of it in
the area of standards and specifications like JDBC, JNDI, and OSGi, to name
just a few."

"
Of course, individual Python developers can and do pilfer from Java specs. I
myself make it a particular point to examine the state-of-the-art in Java
before undertaking the design of any complex facility for Python."

"Individually, perhaps, we are all productive, but our collective productivity
is lower in the Python community, because we are all forced to reinvent
'IWheel', up until there's a 'Wheel' implementation in the standard library."

"Maybe the fact that Java forces you to think about interfaces (at least a
little), encourages Java architects to design better frameworks? More to the
point, is there any way we can leverage this characteristic in Python, such
that we're not always begging scraps from Java's table?"

Te wlasnie rzeczy to i nakladaja sie na to, ze Python przez przemysl jest
przewaznie ignorowany. Przypadek Nuxeo - pamieta ktos? 
http://www.nuxeo.com/en/java-switch/about-nuxeo5/

"When evaluating products and technologies for the next generation of our
software, the main criteria were:

    * Flexible and proven technology
    * Industry standard support
    * Large community of providers and developers
    * Efficient development tools
    * Robust and scalable infrastructure
    * Not limited to web-based applications
    * Friendly to open source and community-driven improvement process 

We had a look at other Python web frameworks, but quickly figured out that
they were behind Zope in terms of enterprise-readiness and features that we
needed to support our ECM developments.
We started to evaluate the Java Platform. We already had some experience in
this area, since we have chosen Eclipse RCP as the framework for our rich
client developments. Discovering the recent evolutions of the Java Platform
was exciting and interesting. First, we found that innovations brought by Java
5 (SE and EE) to the language provided a lot of value and flexibility for
developers (annotations, EJB3, etc.). Moreover, enterprise-related
technologies (EJB3, JPA, JMS, JSF, etc.) were really compelling and we started
to dig in the Java&#8217;s world to found pieces we would need.
We wanted to be sure that the flexibility Python had given us would not be
lost, and that our development speed would be as fast as with Python, if not
faster. Powerful IDEs are available (Eclipse, NetBeans, IDEA...) and great new
technologies like AOP, EL, OSGi, EJB3 or JVM Scripting confirmed our choice.
Moreover, the huge library of excellent open source software available for the
Java platform made us even more confident. To be honest, even if the hard-core
Python fans in our team were a bit skeptical at first, they were all quickly
convinced by the quality of the Java platform and related technologies/products. "


Biblioteki, standardy, community...

Przypadek Google jest szczegolny - tamci moga sobie web aplikacje to nawet w
assemblerze pisac (co de facto i robia - w C++) - taka maja kure znoszaca
zlote jaja (ad-sense), ze im to nie przeszkadza.

A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> > Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne)
> 
> Nie zauwazylem tego wczesniej.
> Jesli Pan uwaza ze jezyki dynamiczne sa beztypowymi to.. (..)
> Python jest jezykiem dynamicznym ale jest _w pelni_
> jezykiem 'typowym'.
> Nie ma obiektu w pythonie ktora nie ma scisle okreslonego typu.
> Co wiecej.
> Typ ten jest okreslany raz i nie mozna go zmienic.
> 
> Prosze nie miaszac dwoch zupelnie ortogonalnych pojec.
> 

Niczego nie mieszam. Prosze spojrzec:  The Computer Science and Engineering
Handbook. CRC Press, 2004. Chapter 97

"Languages that do not restrict the range of variables are called untyped
languages: they do not have types or, equivalently, have a single universal
type that contains all values."

"Untyped languages can enforce good behavior (including safety) in a different
way, by performing sufficiently detailed run time checks to rule out all
forbidden errors. (For example, they may check all array bounds, and all
division operations, generating recoverable exceptions when forbidden errors
would happen.) The checking process in these languages is called dynamic
checking; LISP is an example of such a language. These languages are strongly
checked even though they have neither static checking, nor a type system."

"Type system: A collection of type rules for a typed programming language.
Same as static type system."

"Untyped language: A language that does not have a (static) type system"


Python jest wlasnie untyped - zgodnie z terminogia ktora istnieje od jakichs
kilkudziesieciu lat.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał(a): 

> Witam
> 
> Aleksander Galicki wrote:
> 
> > zignorowane. Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) 
> 
> Dynamiczne to nie znaczy bez typowe.


Sa. Ten papier to wyjasni: http://lucacardelli.name/Papers/TypeSystems.pdf

A to zwiezle pokaze czym jest Dynamic typing: 
http://lucacardelli.name/Drawings/DynamicTypecheck/PolyCandyCartoon.pdf

A.
PS Beztypowe.
PPS sam strzelilem orta:
charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Thu, 10 May 2007 02:33:51 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>Uzytkownik "A.L." <fela@2005.com> napisal:
>
>> Nawiasem mowiac, gdy team jest wiekszy (na przyklad tak 40 - 50 osob)
>> to czlonkowie tego etamu komunikuja sie przy pomocy interfejsow (w
>> sensie komunikacji werbalno - pisemnej) Wielokrotnie juz pisano na
>> temat dobrodziejstwa interfejsow, zwlaszcza przy wprowadzaniu jezyka
>> Modula-2. Rowneiz wielokrotnie pisano o ortogonalnosci modularyzacji i
>> obiektowow=sci, zwlaszcza pisala o tym szkola Wirtha, a specjalnie
>> neijaki Szyperski w ksiazkach o komponentyzacji i licznych papierach.
>
>Panie A.L. tak dobrych interfaces jak w Pythonie nie znajdzie Pan
>ani w Javie ani w wiekszosci innych jezykow 'mainsteamowych'.
>Proponuje sie zorientowac wpierw jak sie pisze wieksze projekty w Pythonie.
>Wie Pan ja jestem _fanem_ interfaces (szczegolnie w takiej postaci
>jak ja propagowal prof.Subieta - czyli pojecie ról) a jakos swietnie
>czuje sie w Pythonie.
>O dziwo _o wiele lepiej_ niz w jezykach ktore takowe interfaces maja
>(Java, C#).
>Nie dziwi Pana ta (pozorna) sprzecznosc ?
>Pytanie obok: Jakie jest Pana zdanie na temat ról  Pana Subiety ?
>
>> Dyskusja nad pzrewaga jezykow dynamicznie typowanych nad statycznymi
>> wydaje sie byc klasycznym przykladem bicia klasycznej piany. Jak dlugo
>> ktos pracuje w jednoosobowym "garage development" to mu wszystko
>> jedno; gdy nad problemem pracuje kilka osob, to juz nie.
>
>Taaa Znamy to znamy.
>Powiedz Pan to np Google.
>No chyba ze to dla Pana tez garaz.
>Pan ma nadal bardzo male pojecie o Pythonie i o sposobach
>i konstrukcajach sluzacych w nim do 'bezpiecznego' pisania
>a wypowoiada sie jak znawca tematu.
>Dlaczego ?

Przepraszam ze cytuje (niezgodnei z netykieta) calosc, ale czy moglby
mi Pan wskazac gdzie ja w moim poscie pisalem o Pythonie?... 


Ja pisalem o jezykach ktore maja statyczne typowanie, potem pisalem o
interfejsach typu Java, a Pan mi wyzezdza z Subieta i Pythonem.

A.L.

P.S. Na temat "rol" Pana Subiety nei mam zdania, bo nawet nie wiem co
to jest (z czalym szacunkiem dla Pana Subiety).

On Thu, 10 May 2007 02:22:37 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>Uzytkownik "A.L." <fela@2005.com> napisal:
>
>> SparkAda umozliwia formalna weryfikacje programow
>> w jezyku Ada, wlasnie w oparciu o te statyczne typy:
>
>Jest to warunek konieczny, ale nie wystarczajacy.
>
>AK
>
>

Owszem. W Pythonie weryfikacje formalna robi sie prosciej i
przyjemniej.

A.L.

A.L. <fela@2005.com> napisał(a): 

> On Wed, 9 May 2007 21:15:18 +0000 (UTC), "Aleksander Galicki"
> <tretete@WYTNIJ.gazeta.pl> wrote:
> 
>  
> >
> >No wiec prosze nam opowiedziec: co to sa, *konkretnie*, za mechanizmy? To
> >pytanie pada po raz trzeci, mam nadzieje, ze nie zostanie tym razem zignorowan
> e. 
> >Prosze zauwazyc, ze jezyki beztypowe (czyli dynamiczne) sa charakterestyczne
> >wlasnie dlatego, ze nie maja cechy ktora sie zwie statyczny system typow.
> >Jakiekolwiek dobrodziejstwa, ktore ktore maja jezyki dynamiczne a ktorych nie
> >moze miec statycznie typowany jezyk, musza zatem wynikac z cechy braku
> >statycznego systemu typow. Prawde mowiac, nie kojarze zeby tych dobrodziejstw
> >bylo duzo. Wiekszosc artykulow pro-dynamic-typing skupia sie na zwiezlosci
> >kodu, co jest takim sobie dobrodziejstwem.
> 
> Nawiasem mowiac, gdy team jest wiekszy (na przyklad tak 40 - 50 osob)
> to czlonkowie tego etamu komunikuja sie przy pomocy interfejsow (w
> sensie komunikacji werbalno - pisemnej) Wielokrotnie juz pisano na
> temat dobrodziejstwa interfejsow, zwlaszcza przy wprowadzaniu jezyka
> Modula-2. Rowneiz wielokrotnie pisano o ortogonalnosci modularyzacji i
> obiektowow=sci, zwlaszcza pisala o tym szkola Wirtha, a specjalnie
> neijaki Szyperski w ksiazkach o komponentyzacji i licznych papierach. 
> 
> Dyskusja nad pzrewaga jezykow dynamicznie typowanych nad statycznymi
> wydaje sie byc klasycznym przykladem bicia klasycznej piany. Jak dlugo
> ktos pracuje w jednoosobowym "garage development" to mu wszystko
> jedno; gdy nad problemem pracuje kilka osob, to juz nie.
> 

Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo duzych
aplikacji w tym powstalo. Generalnie wniosek z historii byl taki, ze statyczne
typowanie jest bardziej potrzebne niz niepotrzebne. 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Thu, 10 May 2007 02:10:13 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:
 
>> 
>
>Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
>znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo duzych
>aplikacji w tym powstalo. Generalnie wniosek z historii byl taki, ze statyczne
>typowanie jest bardziej potrzebne niz niepotrzebne. 
>

Zreszta, ci od Smalltalka tez sie tropneli ze cos nie tak i wymyslili
typowany Smalltalk zwany Strongtalk

http://www.strongtalk.org/

Strongtalk jest open source i ma aktualnie wersje 1.1.2. Tyle ze 15
lat za pozno...

A.L.

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

>> Prosze nie miaszac dwoch zupelnie ortogonalnych pojec.
>>
>
> Niczego nie mieszam. Prosze spojrzec:  The Computer Science and 
> Engineering

> "Type system: A collection of type rules for a typed programming language.

Prawda

> Same as static type system."

Bzdury.

> "Untyped language: A language that does not have a (static) type system"

Bzdury

> Python jest wlasnie untyped - zgodnie z terminogia ktora istnieje od 
> jakichs
> kilkudziesieciu lat.

Bzdury a nie terminologia

PS: Jezykiem beztypowym to jest np Tcl.
      Tam wszystko jest stringiem.
      Jezykiem beztypowym w czesci jest Perl.

AK

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> > Python jest wlasnie untyped - zgodnie z terminogia ktora istnieje od 
> > jakichs
> > kilkudziesieciu lat.
> 
> Bzdury a nie terminologia
> 

Ja jednak pozwole sobie poslugiwac sie przyjeta terminologia. (Zreszta pojecie
untyped nie jest w zaden sposob bardziej ujmujace niz dynamically typed.)


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Uzytkownik "A.L." <fela@2005.com> napisal:

>>Jest to warunek konieczny, ale nie wystarczajacy.
>>
>>AK
>>
>
> Owszem. W Pythonie weryfikacje formalna robi sie prosciej i
> przyjemniej.

Mam pana traktowac powaznie ?
_Gdzie_  ja pisalem o Pythonie choc slowo ?

Sam Pan dal dowod ze Java to inny swiat bo mozna
w niej weryfikowac poprawnosc programoow
a gdy ja o tym pisalem to Pan mi zarzucal ze Java to
zaden "inny swiat" bo to _tylko_ lepszy Pascal.
Konsekwensji pozazdroscic :).

Teraz gdy zaznaczylem ze w/w warunek nie jest wystarczajacy
- co chyba jasno sugeruje ze zarowno Java jak i C++ jak i C#
tez nie moga byc werifikowalne bo nastepnym z warunkow
jest chocby _szczelnosc_ systemu typow (a te jezyki jej nei posiadaja) -
Pan tu wyjezdza z Pythonem nie wiadomo skad.

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
> znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo 
> duzych
> aplikacji w tym powstalo.

Przeczy temu historia Simuli
Jako jezyk stattycznie typowany i to ze szczelnym systemem typow
upadl na rzecz Smalltalka i chorego dziurawegow sensie typow C
i beztypia Tcl.
Innym przykladem jest Eiffel.
W swoim czasie sztandarowy jezyk modern OOP.
Wzor !
Statyczny system typow. Ba  ! Rygorystyczny DbC
No i upadl na rzecz jakiegos 'beztypowego' VB.

Rowniez Pascal przegral z beztypim xBasem wszelkim chocby.

Generalnie wniosek z historii jest  taki, ze statyczne
beztypie czy dzuirotypie jest bardziej potrzebne niz
porzadne statyczne typowanie.

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

>> Bzdury a nie terminologia
>
> Ja jednak pozwole sobie poslugiwac sie przyjeta terminologia. (Zreszta 
> pojecie
> untyped nie jest w zaden sposob bardziej ujmujace niz dynamically typed.)

Guzik mnie jakas ujmuja cos obchodzi.
Chodzi o to ze ta terminologia nie oddaje rzeczywistosci.
Wiec jest do bani.

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

>> No chyba jasne czego ?
>> To nie jest trudne zgadnac.
>
> Np tego czy system jest deadlock-free, albo ze sie zatrzyma kiedys? :-)

Nooo niech Pan zgaduje dalej.

> Wole nie zaplacic i pokazac, ze adwersarz tych argumentow nie ma.

No coz. Pan woli.
Mnie sie nie chce nic nikomu udowadniac :)
Za stary jestem.
Wole posluchac jakiegos Hendrixa albo Mangione.

>> Panie Galicki, prosze nie tworzyc nowej logiki :).
>
> Slucham?

Pan wysnuwa wnioski w/g slynnej logiki
naukowca radzieckiego badajacego
zdolnosc pchly do skakania.

>> Nie zauwazylem  natomiast gdzie uwidacznia rozniece :
>> Sklec sam : w jakim jezyku ?
>> Uzyj gotowego: w jakim jezyku ?

> Biblioteki, standardy, community...

Panie kochany naszukal sie Pan na google bez sensu.
Akurat Python jest typowym przykladem: znajdz gotowe
To typowy glue language _w zalozeniach_.
W nim wiekszosc jest _gotowe_.
Albo wprost (standard lib) albo jako binding do juz gotowego.
W Pytonie _nic_ sie wlasciwie nie pisze ale sie skleja
z juz gotowych kawalkow.
To jezyk dla leniwych (w doslownym tego slowa znaczeniu => ja).
To taki VB tyle ze o o wiele lepszym jezyku oraz o wiekszej
mozliwosci bindingu ze o cros-platform nie wspomne.

Jesli chodzi o nuxeo to _nie bylo by go_ gdyby
zaczeli w czym innym niz python+zope.
Byc moze faktycznie podlapali takich klientow
(a podlapali i to powaznych) ze stare zope nie wyrabia
(te terabajty itp).
Tyle tylko ze na razie nie slysze o wdrozeniach ich
nowego CPS5.
Wszysko co wdrozyli chodzi na starym Zope2.
Poczekamy zobaczymy

Prawde mowiac nie moglem uwierzyc w rozwoj nuxeo
(a sledzilem go dosc dokladnie kilka lat zamierzajac przejsc
 na CPS z zopa+moje a nawet z Plone)  i nie moglem sie nadziwic
ja sie nie boja do takich zastosowan uzyc takiej dosc
prymitywki jak CPS a CPS to nic innego jak poprawiony
CMF Zopa2 +  rzeczy Plonopodobne.
Jak zobaczyem zrodla CPS3 zrezygnowalem.
Do tak powaznych zastosowan gdzie powinna byc wysoko
posunieta komponentyzacja i gdzie sprawy aplikacyjne zdecydowanie
prewazaja nad portalo-webowymi uzyto _wprost_  i to typowo webcentric
Zope2 z jego bardzo prymitywnym (bo typowo webcentric) CMFem.
Co najsmieszniejsze do workflow tak powaznej rzeczy jak obieg
dokumentow uzyli.. Zopowego prymitywnego DCWorfflow
(fak ze dosc przez nich dosc zmodyfikowanego) ktory to worflow
sie nadaje do "technicznego" worflow obiektu Zopowego
/work, accepted, published itp/
a nie do powazniejszych zastosowac merytoryczncyh
(nie mowiac ze state-base workflow to za malo jak na DDM).
Coz .. kazdy kiedys zaczynal i uczyl sei na czyms
Nuxeo zaczynalo wczesnie i od 0, uczylo sie wiec  i popelnilo w/w blady.
No tyle tylko ich tlumaczy ze gdy zaczynali Zope3 jeszcze nie bylo
stabilnego (zalozenia albo chyba pre- alpha bylo dopiero).
Chyba Plone tez jeszcze nie bylo.

> Przypadek Google jest szczegolny - tamci moga sobie web aplikacje to
> nawet w assemblerze pisac (co de facto i robia - w C++) - taka
> maja kure znoszaca zlote jaja (ad-sense), ze im to nie przeszkadza.

Jak dla mnie to kolejne bzdury.
Za duzo 'pary' tam idzie w Pythona aby traktowac w/w powaznie.

AK

Aleksander Galicki wrote:

> Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a):
> 
>> > Python jest wlasnie untyped - zgodnie z terminogia ktora istnieje od
>> > jakichs
>> > kilkudziesieciu lat.
>> 
>> Bzdury a nie terminologia
>> 
> 
> Ja jednak pozwole sobie poslugiwac sie przyjeta terminologia. (Zreszta
> pojecie untyped nie jest w zaden sposob bardziej ujmujace niz dynamically
> typed.)

Ale ta terminologia rzeczywiście jest błędna. Gdyby python był untyped,
to nie byłoby potrzeby stosowania np. str(objekt), co jest odpowiednikiem
objekt.toString() w Javie.

Statyczność a dynamiczność typowania ujawnia się w momencie sprawdzania
zgodności tego co zwraca str() z lvalue, do którego jest przypisywana.
W Pythonie jest to w runtime (dynamiczne), w Javie w czasie kompilacji
(statyczne).

-- 
Mariusz Lotko

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> > Wole nie zaplacic i pokazac, ze adwersarz tych argumentow nie ma.
> 
> No coz. Pan woli.
> Mnie sie nie chce nic nikomu udowadniac :)
> Za stary jestem.

Ale wtedy widownia to nalezycie oceni :)

> >> Panie Galicki, prosze nie tworzyc nowej logiki :).
> >
> > Slucham?
> 
> Pan wysnuwa wnioski w/g slynnej logiki
> naukowca radzieckiego badajacego
> zdolnosc pchly do skakania.

Cienka to retoryka: zbyc adwersarza porownaniem do radzieckiego 
naukowca. O pchlach nic mi zreszta nie wiadomo. Wole radziecka matematyke.


> >> Nie zauwazylem  natomiast gdzie uwidacznia rozniece :
> >> Sklec sam : w jakim jezyku ?
> >> Uzyj gotowego: w jakim jezyku ?
> 
> > Biblioteki, standardy, community...
> 
> Panie kochany naszukal sie Pan na google bez sensu.

Alez nie szukalem niczego w google. PJE czytam od dawna - jesli pominac to, 
ze od jakiegos czasu zupelnie odjechal w kierunku self-help i motivation, to 
jego kawalki o IT sa sensowne. O Nuxeo tez od dawna huczy. W srodowisku 
pythonowym. Z pythonem i jythonem czasem mam do czynienia w pracy. 

Zreszta, to dziwne - wycial Pan cytaty, bardzo sensowne, PJE - ktory mowil 
dokladnie to samo co ja: "While Python is more powerful as a language, Java 
beats the crap out of it in the area of standards and specifications like 
JDBC, JNDI, and OSGi, to name just a few.[...]
But when I'm done, my implementation and interfaces are still not a standard 
in the Python world. Nobody is going to know about what I did, and the next 
guy over is going to either do the same thing I did, or throw together their 
own little thing. Individually, perhaps, we are all productive, but our 
collective productivity is lower in the Python community, because we are all 
forced to reinvent 'IWheel', up until there's a 'Wheel' implementation in the 
standard library"
Jeszcze raz Pan to wytnie i zignoruje? 

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

Ale w innym jezyku, bo w Pythonie to najczesciej znajdziesz jakies 
niestandardowe, wyciosane na kolanie, rozwiazanie. Do szybkiego hakowania to 
OK, ale nie pisania duzego softu.


By the way: co sie w Pythonie skleja? Chyba kawalki w C++.. Bo do sklejania 
rzeczy ze swiata Javy czy .NET to sie inne rzeczy bardziej nadaja. Niestety, 
ale w swiecie Javy latwiej sie to robi w Groovy, niz w Jythonie. W mojej 
firmie wiekszosc javowcow preferuje Groovy - lepiej dopasowany do Javy jako 
platformy. Moze to mniej elegancki jezyk, ale do sklejania zadnej szczegolnej 
elegancji nie potrzeba. Mamy kawalki w Jythonie, ale jak bedzie cos nowego 
sie sklejac, to sie wybierze Groovy, najprawdopodobniej.

> W nim wiekszosc jest _gotowe_.
> Albo wprost (standard lib) albo jako binding do juz gotowego.


Jaka wiekszosc? W porownaniu do Javy czy .NET to w Pythonie prawie nic nie 
ma. O tym wlasnie pisal PJE, ale Pan to wycial. Wlasnie dlatego taki typowy 
biznes nie wybiera Pythona - pisanie softu w nim zwykle konczy sie wlasna 
implementacja IWheel w setkach roznych wersji. I to ze Python, rzekomo, jest 
more powerful niczego niestety nie zmienia. Bo jako _platforma_ jest ubogi.

> W Pytonie _nic_ sie wlasciwie nie pisze ale sie skleja
> z juz gotowych kawalkow.

Chandlera probowali napisac - jajo wyszlo. Ale w Google to ponoc pisza w tym 
- nie sklejaja.


> To jezyk dla leniwych (w doslownym tego slowa znaczeniu => ja).
> To taki VB tyle ze o o wiele lepszym jezyku oraz o wiekszej
> mozliwosci bindingu ze o cros-platform nie wspomne.
> [...]

> > Przypadek Google jest szczegolny - tamci moga sobie web aplikacje to
> > nawet w assemblerze pisac (co de facto i robia - w C++) - taka
> > maja kure znoszaca zlote jaja (ad-sense), ze im to nie przeszkadza.
> 
> Jak dla mnie to kolejne bzdury.
> Za duzo 'pary' tam idzie w Pythona aby traktowac w/w powaznie.
> 

Ale co bzdury: Google pisze i w C++ i w Pythonie i w Javie. Ale to _baardzo_ 
szczegolna firma. Jak im ktos odbierze advertisement to nie zdziwie sie jesli 
zdechna w trzy miga. Ale na razie moga pozwolic zatrudniac najlepszych ze 
swiata i Javy i Pythona (i produkowac mase pol-upieczonych pomyslow, 
applikacji i bibliotek, jak dzieci)


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> > Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
> > znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo 
> > duzych
> > aplikacji w tym powstalo.
> 
> Przeczy temu historia Simuli
> Jako jezyk stattycznie typowany i to ze szczelnym systemem typow
> upadl na rzecz Smalltalka i chorego dziurawegow sensie typow C
> i beztypia Tcl.
> Innym przykladem jest Eiffel.
> W swoim czasie sztandarowy jezyk modern OOP.
> Wzor !
> Statyczny system typow. Ba  ! Rygorystyczny DbC
> No i upadl na rzecz jakiegos 'beztypowego' VB.
> 
> Rowniez Pascal przegral z beztypim xBasem wszelkim chocby.

W ten sposob do zadnych wnioskow nie dojdziemy zupelnie. Simula i Eiffel 
nigdy nie byly mainstream. Smalltalk - byl. Sam fakt statycznego czy 
dynamicznego typowania nigdy nie byl argumentem ostatecznym - Smalltalk byl 
przeciez po Algolu. Niemniej - srodowisko Smalltalka przeimigrowalo do Javy, 
a Microsoft migruje z beztypowego VB do C#. Trend jest taki: silne i 
statyczne typowanie.

A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> W ten sposob do zadnych wnioskow nie dojdziemy zupelnie. Simula i Eiffel
> nigdy nie byly mainstream. Smalltalk - byl.

Simula nie byla minstream !:) O nie !
Pascal tez nie byl maistream ?
Moze Algol tez nie byl ?

> Sam fakt statycznego czy dynamicznego typowania nigdy
> nie byl argumentem ostatecznym -

Powiem wiecej
Nigdy nie byl argumentem decydujacym.,
To jest argument pozorny.
Jest ale o wiele mniej znaczacy niz sie wydaje.

> Smalltalk byl przeciez po Algolu.
> Niemniej - srodowisko Smalltalka przeimigrowalo do Javy,

Prawda.
Bo wtedy Java jako _jedyna_ posiadala
wieloplatformowe przenosne spojne obiektowe API .
NETa wtedy nie bylo a COM byl tylko na Win
a VB byl srednio obiektowy. a jakisgos Pythona chyba
w ogole nei bylo albo byl jakies 0.99 do zabaw.

To decydowalo IMHO bardziej niz static typing

> a Microsoft migruje z beztypowego VB do C#.

Panie kochany co Pan glupoty gada :(.
Jaki beztypowy VB ?
VB mail zawsze _satyczny_ typing (no nie liczac wersji przedpotopowych)
W 95 roku w VB pisalem stosujac wszedzie statyczny typing.
MS z zadnego VB nie migruje :)
W .NET zdecydowanie prosciej (przynajmniej dla mnie)
pisze sie w VB.NETniz w C#

> Trend jest taki: silne i > statyczne typowanie.

Heh.
No to skad taka ekspansja Pythona
a wczesniej innych innych sklejaczy (np VB) ?

Gdyby tak bylo (a zylem w tych czasach)
nie byloby syfu zwanego Tcl/Tk (AOL to tez garaz?)
Perla, VB , JS itp itd a posostala by Simula i jakis rodzaj oberona
albo cus ?.
Moze Module2 tez nie byla mainsteam ?
Silnie statycznie typowany jezyk.
Standard przemyslowy przez dlugie lata.
No wiec ?
A przegral z jakimis gowienkami co o real time to mysla
w kontekscie timezone.

Tendencja jest inna.
Stad WSH od dawna w windowsach.
Stad Jython , stad Groovie w Javie
Stad PythonNet i IronPython i inne do .NETa
Stad PythonWin czy wyroby z ActieveState do Win i VS

Namnozylo sie tego w samym Pythoinie za duzo
a Pan mi mowi ze python jest _goly_ ?.
Naprawde mnie Pan ubawil.
Jest tendencja przerostu. Tego sie boje w Pythonie
bo do samego Weba jest stanowczo za duzo frameworkow
a w innych tez ta tendencja moze zagrazac (GUI) a Pan mowi
o tym ze  w Pythonie nic nie ma.

Owszem - jest zerowa swiadomosc _co_ w Pythonie jest
ale.. to mnie akurat raczej cieszy z wiadomych wzgledow :).

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

>> No coz. Pan woli.
>> Mnie sie nie chce nic nikomu udowadniac :)
>> Za stary jestem.
>
> Ale wtedy widownia to nalezycie oceni :)

Oh ale Pan trafil !
Najbardziej w d.. w zyciu to mam wlasnie wszelkie widownie
i ich opinie :)

> Cienka to retoryka: zbyc adwersarza porownaniem do radzieckiego
> naukowca. O pchlach nic mi zreszta nie wiadomo. Wole radziecka matematyke.

Nie widzi Pan absurdu w swym 'logicznym' wywodzie o static typing w Pythonie 
?

> Zreszta, to dziwne - wycial Pan cytaty, bardzo sensowne,

Nic nie wycinalem.
Nie zwyklem powtarzac bezsensownie cytatow z poprzedneigo postu

> PJE - ktory mowil
> dokladnie to samo co ja: "While Python is more powerful as a language, 
> Java
> beats the crap out of it in the area of standards and specifications like
> JDBC, JNDI, and OSGi, to name just a few.[...]
> But when I'm done, my implementation and interfaces are still not a 
> standard
> in the Python world. Nobody is going to know about what I did, and the 
> next
> guy over is going to either do the same thing I did, or throw together 
> their
> own little thing. Individually, perhaps, we are all productive, but our
> collective productivity is lower in the Python community, because we are 
> all
> forced to reinvent 'IWheel', up until there's a 'Wheel' implementation in 
> the
> standard library"
> Jeszcze raz Pan to wytnie i zignoruje?

Panie Kochany, przestan Pan truc znow o wycinaniu.

Ale merytorycznie.

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

O interfaces to juz nawet nie wspomne.
Zope interfaces od kilku lat juz sa defacto standardem
w powazniejszych aplikacjach pythonowych.
Co wiecej, o ile mnie pamiec nie myli PyProtocols
i zope interfaces sa z soba zgodne.
Po prostu dekoratory w Pythonie (ogolny mechanizm)
na ktorych oparte sa zope interfaces wyparly PyProtocols
(szkoda bo PyPrtocols byly ogolniejsze - tyle ze nieco trudniejsze).

>> Akurat Python jest typowym przykladem: znajdz gotowe
>> To typowy glue language _w zalozeniach_.
>
> Ale w innym jezyku, bo w Pythonie to najczesciej znajdziesz jakies
> niestandardowe, wyciosane na kolanie, rozwiazanie. Do szybkiego hakowania 
> to
> OK, ale nie pisania duzego softu.

Panie kochany, Pan widzial Pythona w ogole ? :)
Oczywiscie zalezy _jak_sie pisze.
C++ tez IMHO do pisania duzego softu sie nie nadaje
a jednak. sie w nim pisze mimo ze glownie zle.

> By the way: co sie w Pythonie skleja? Chyba kawalki w C++.. Bo do 
> sklejania
> rzeczy ze swiata Javy czy .NET to sie inne rzeczy bardziej nadaja.
> Niestety,  ale w swiecie Javy latwiej sie to robi w Groovy, niz w 
> Jythonie.

Bzdura.
Robi sie identycznie bo Grovvy to.. taka odmaina Jythona jak
odmiana Javy jest C#
Groovy i Jython maja ten sam binding do Javy i w obu sie robi
to identycznie latwo.
No.. przesadzilbym
Jyton mi sie tutaj batrdziej podoba bo ma scislej o wiele
odseparowane typy Javy od Pythonowych a w Grooviem zbyt to sie
zamazuje.

Glowna zaleta Jythona nad Grovym jest
1. prostrzy 'klej' czyli jezyk
2. wieksza dojrzalosc (pomimo ze Jython jes w wersji beta
    od lat ale kto zna Hugunina ten wie ze jego beta o wiele
      lepsze niz niejedne 3.56

Glowna zaleta Groviego nad Jythonem jest wbudowany w
jezyk standardowy typechecking (choc nie wiedziec czemu
nei stanardowy - to duzy blad Grooviego).

> W mojej firmie wiekszosc javowcow preferuje Groovy - lepiej dopasowany
> do Javy jako platformy.
> Moze to mniej elegancki jezyk, ale do sklejania zadnej szczegolnej
> elegancji nie potrzeba.

Wlasnie do sklejania _trzeba_  prostoty.
Skrajnej prostoty aby sie nie uczyc nie wiadomo po co "wypasionego" 
sklejacza.
Dobry klej jest niewidoczny a nie cieknacy bokami.
Jython ma _tylko_ to potrzeba (pelny binding do Javy i swoje
Pythonowe moduly podstawowe) i nic wiecej.

> Mamy kawalki w Jythonie, ale jak bedzie cos nowego
> sie sklejac, to sie wybierze Groovy, najprawdopodobniej.

Zycze szczescia :)
Nic nie mowie.!
Moze wersja 1.0 jeszcze goraca (luty chyba) jest juz
super stabilna :)

>> W nim wiekszosc jest _gotowe_.
>> Albo wprost (standard lib) albo jako binding do juz gotowego.
>
> Jaka wiekszosc?
> W porownaniu do Javy czy .NET to w Pythonie prawie nic nie  ma.

Tu sie Pan zwyczajnie osmieszyl.
W Pythonie _ma_ nic nie byc.
Wlasnie o to chodzi zeby poza podstawowa biblioteka
(IMHO i tak za bardzo rozbudowana _nic nie bylo_) .

> O tym wlasnie pisal PJE, ale Pan to wycial.

(Po raz ostatni Pan prosze o nie trucie bez sensui o wycinaniu)

> Wlasnie dlatego taki typowy biznes nie wybiera Pythona - pisanie softu w
> nim zwykle konczy sie wlasna  implementacja IWheel w setkach roznych 
> wersji.
>  I to ze Python, rzekomo, jest  more powerful niczego niestety nie 
> zmienia.
>  Bo jako _platforma_ jest ubogi.

Nie no Panie Galicki, smiech mnie ogarnia
Niech no Pan wiecej juz lepiej  nie pisze na temat Pythona :(

>> W Pytonie _nic_ sie wlasciwie nie pisze ale sie skleja
>> z juz gotowych kawalkow.
>
> Chandlera probowali napisac - jajo wyszlo.

Ze co ? Nie ma juz chandlera ?

> Ale w Google to ponoc pisza w tym - nie sklejaja.

To zle jesli wszytsko pisza od zera.
Tyle ze nei sadze aby zatrudneinie w Google
GvRa bylo po to aby na nowo wymyslac kolo.
To zbyt powaznych czlek na zabawy :).

>> Jak dla mnie to kolejne bzdury.
>> Za duzo 'pary' tam idzie w Pythona aby traktowac w/w powaznie.
>>
>
> Ale co bzdury: Google pisze i w C++ i w Pythonie i w Javie. Ale to 
> _baardzo_
> szczegolna firma. Jak im ktos odbierze advertisement to nie zdziwie sie 
> jesli
> zdechna w trzy miga. Ale na razie moga pozwolic zatrudniac najlepszych ze
> swiata i Javy i Pythona (i produkowac mase pol-upieczonych pomyslow,
> applikacji i bibliotek, jak dzieci)

Hehe :)

AK

Użytkownik "Adam Karpierz" <karpierz@_NOSPAM_python.pl> napisał:

> Glowna zaleta Groviego nad Jythonem jest wbudowany w
> jezyk standardowy typechecking (choc nie wiedziec czemu
> nei stanardowy - to duzy blad Grooviego).

mialo byc:

(choc nie wiedziec czemu nie defaultowy - to duzy blad Grooviego).

AK 

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> > W ten sposob do zadnych wnioskow nie dojdziemy zupelnie. Simula i Eiffel
> > nigdy nie byly mainstream. Smalltalk - byl.
> 
> Simula nie byla minstream !:) O nie !
> Pascal tez nie byl maistream ?
> Moze Algol tez nie byl ?

To jest czepianie sie o slowa. W tym sensie co Smalltalk czy C Simula nie 
byla mainstream.
 
> > Sam fakt statycznego czy dynamicznego typowania nigdy
> > nie byl argumentem ostatecznym -
> 
> Powiem wiecej
> Nigdy nie byl argumentem decydujacym.,
> To jest argument pozorny.
> Jest ale o wiele mniej znaczacy niz sie wydaje.

Tu wlasnie sie nieco roznimy.

> > Smalltalk byl przeciez po Algolu.
> > Niemniej - srodowisko Smalltalka przeimigrowalo do Javy,
> 
> Prawda.
> Bo wtedy Java jako _jedyna_ posiadala
> wieloplatformowe przenosne spojne obiektowe API .
> NETa wtedy nie bylo a COM byl tylko na Win
> a VB byl srednio obiektowy. a jakisgos Pythona chyba
> w ogole nei bylo albo byl jakies 0.99 do zabaw.

Well, Python to znacznie starszy jezyk niz Java. A i Java przez pierwsze 2 
lata to raczkowala raczej.


> To decydowalo IMHO bardziej niz static typing

Ale tworcy Javy to ze Smalltalkowego i Objective-C srodowiska.


> > a Microsoft migruje z beztypowego VB do C#.
> 
> Panie kochany co Pan glupoty gada :(.
> Jaki beztypowy VB ?
> VB mail zawsze _satyczny_ typing (no nie liczac wersji przedpotopowych)
> W 95 roku w VB pisalem stosujac wszedzie statyczny typing.

Racja. Mialem na mysli migracje z bardziej dziurawych C i VB do mniej 
dziurawych. Ale u mnie wieczor i ja sobie lepiej dopije doskonale 
nowozelandzkie sav blanc i sobie ksiazke poczytam, zamiast pisac na niusy...

> MS z zadnego VB nie migruje :)
> W .NET zdecydowanie prosciej (przynajmniej dla mnie)
> pisze sie w VB.NETniz w C#
> 
> > Trend jest taki: silne i > statyczne typowanie.
> 
> Heh.
> No to skad taka ekspansja Pythona

Zadnej ekspansji nie widze. Python ma swoja nisze i oddane community - rok w 
rok takie same. Ale ostatnio Ruby jest jakby bardziej modny i sexy, co 
frustruje niektorych pythonowcow. Tyle, ze Ruby nie stroi sie na sklejacz. 
Ruby ma jeden latwy i dosc niezly web framework o ktorym naprawde glosno i w 
polaczeniu z faktem, ze w GUI (rowniez web GUI) wady dynamicznego typowania 
przeszkadzaja znacznie mniej niz w typowym biznesowym kodzie to sprawia ze to 
raczej Ruby robi mini ekspansje, a nie Python.


> a wczesniej innych innych sklejaczy (np VB) ?
> 
> Gdyby tak bylo (a zylem w tych czasach)
> nie byloby syfu zwanego Tcl/Tk (AOL to tez garaz?)
> Perla, VB , JS itp itd a posostala by Simula i jakis rodzaj oberona
> albo cus ?.
> Moze Module2 tez nie byla mainsteam ?
> Silnie statycznie typowany jezyk.
> Standard przemyslowy przez dlugie lata.
> No wiec ?
> A przegral z jakimis gowienkami co o real time to mysla
> w kontekscie timezone.

Nie zbadane sa wyroki Panskie... Perl to jak na mnie hakerstwo. Dlaczego 
Modula sie nie przyjela to nie wiem - oswieci mnie ktos?

> Tendencja jest inna.
> Stad WSH od dawna w windowsach.
> Stad Jython , stad Groovie w Javie
> Stad PythonNet i IronPython i inne do .NETa
> Stad PythonWin czy wyroby z ActieveState do Win i VS

Ale to akurat kropla w morzu. Te rzeczy sa uzywane do sklejania - czyli 
hakowania na szybko.

> Namnozylo sie tego w samym Pythoinie za duzo
> a Pan mi mowi ze python jest _goly_ ?.
> Naprawde mnie Pan ubawil.
> Jest tendencja przerostu. Tego sie boje w Pythonie
> bo do samego Weba jest stanowczo za duzo frameworkow

I zaden nie zostal nawet w polowie rownie popularny co Ruby On Rails.


Ale ja wracam do ksiazek i wina. Dzis juz mnie nikt nie zmusi do pisania na 
usenet.



A,

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> > By the way: co sie w Pythonie skleja? Chyba kawalki w C++.. Bo do 
> > sklejania
> > rzeczy ze swiata Javy czy .NET to sie inne rzeczy bardziej nadaja.
> > Niestety,  ale w swiecie Javy latwiej sie to robi w Groovy, niz w 
> > Jythonie.
> 
> Bzdura.
> Robi sie identycznie bo Grovvy to.. taka odmaina Jythona jak
> odmiana Javy jest C#


Mialem juz nie pisac, ale nie nie moge sie jednak powstrzymac. U Pana co 
drugie slowo to 'bzdura'. To ja na codzien pisze w Javie, a nie Pan. Wiec w 
tej gestii to ja mowie, a Pan slucha. Ja nie mam nic przeciwko jythonowi, ale 
w Groovy jest latwiej i tyle. 
I: jakies spacery, dobre ksiazki, przyzwoite wino i takie tam - mniej 'bzdur' 
bedzie.


Na zdrowie!

A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> To jest czepianie sie o slowa.
> W tym sensie co Smalltalk czy C Simula nie
> byla mainstream.

Dowod prosze.
Powiem cos obrazoburczego dla Pana
Dla mnie Simula byla i jest _najlepszym_ jezykiem
obiektowym ze statycznym systemem typow
jaki sie w ogole kiedykolwiek pojawil.
Calkiem IMHO w sensie jezyka nie dorownuje
mu nawet Ada.

> Tu wlasnie sie nieco roznimy.

Tak. A nawet wiecej niz nieco.

> Well, Python to znacznie starszy jezyk niz Java.

Wiek Pythona trzeba liczyc od wersji 1.5 min 1.4
Poprzednie to faktycznie byla zabawka.

> A i Java przez pierwsze 2 lata to raczkowala raczej.

W ktorym roku 'wyszla' Java ?

>> To decydowalo IMHO bardziej niz static typing
>
> Ale tworcy Javy to ze Smalltalkowego i Objective-C srodowiska.

Nooo, chyba zdali sobie sprawe ze nei zmieszcza Smalltalka
w kuchence mikrofalowej wiec.. stworzyli Jave :0
Zreszta C/C++ tez dzieki down-development sprzetu
(PCty) i dzieki skrajnej prymitywnosci kompilatora
'wygral'.

>> > Trend jest taki: silne i > statyczne typowanie.
>>
>> Heh.
>> No to skad taka ekspansja Pythona
>
> Zadnej ekspansji nie widze. Python ma swoja nisze i oddane community - rok 
> w
> rok takie same.
> Ale ostatnio Ruby jest jakby bardziej modny i sexy, co
> frustruje niektorych pythonowcow.

Frustruje ?
Panie Kochany Alku.
Buzz w RoR (bo tylko dzieki nuemu Ruby jest popularny)
to _woda na mlyn_ Pythonowcow ! :)

> Tyle, ze Ruby nie stroi sie na sklejacz.

I bardzo zle.
Podstawowy blad Rubiego.
Dlatego wlasnie nie zanierzam sie bawic Rubym
choc w sensie jezyka niby bardzij 'mainsteram'.
Pozorne advantages.

> Nie zbadane sa wyroki Panskie... Perl to jak na mnie hakerstwo.

Dla nie tez. I to hakerstwo udajace wysokopoziomowosc.
A widzi Pan ?  A jednak najpopularniejszy sie stal.
No wiec ?

> Dlaczego Modula sie nie przyjela to nie wiem - oswieci mnie ktos?

Modula sie nie przyjela ?
Modula byla dlugie lata _standardem przemyslowym_ systemow real time.

>> Tendencja jest inna.
>> Stad WSH od dawna w windowsach.
>> Stad Jython , stad Groovie w Javie
>> Stad PythonNet i IronPython i inne do .NETa
>> Stad PythonWin czy wyroby z ActieveState do Win i VS
>
> Ale to akurat kropla w morzu. Te rzeczy sa uzywane do sklejania - czyli
> hakowania na szybko.

Jesli hakowaniem nazywa Pan glowna zalete
technologii i frameworkow komponetowych to.. to..
to.. ja wymiekam !.
Dla mnie to wielojezykowe 'hackowanie' to byla dluuuugo
oczekiwana nadzieja w totalnym kryzysie oprogr. a
Pan to skwitowal takim brzydkim slowem :(.
Pan jest za badzo Javacentric.

>> Namnozylo sie tego w samym Pythoinie za duzo
>> a Pan mi mowi ze python jest _goly_ ?.
>> Naprawde mnie Pan ubawil.
>> Jest tendencja przerostu. Tego sie boje w Pythonie
>> bo do samego Weba jest stanowczo za duzo frameworkow
>
> I zaden nie zostal nawet w polowie rownie popularny co Ruby On Rails.

Ruby on rails to chore dziecko tego co w Zope jest
od dobrych kilku lat.
Lepiej dojrzalej spojniej i badziej wysokopoziomowo
No ale tak to bywa ze dzieciaki zachwycaja sie dziecmi
bardzij niz dojrzaloscia wiec popularnosc RoR niezaprzeczalna.
Zwykle w ogole dzieci o doroslosci nie wiedza :)

AK

On Thu, 10 May 2007 05:51:22 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
>
>> Co ciekawe: to juz bylo przerabiane, na Smalltalku. Przy tym Smalltalk byl
>> znacznie popularniejszy niz Python i Ruby kiedykolwiek beda. I sporo 
>> duzych
>> aplikacji w tym powstalo.
>
>Przeczy temu historia Simuli
>Jako jezyk stattycznie typowany i to ze szczelnym systemem typow
>upadl na rzecz Smalltalka i chorego dziurawegow sensie typow C
>i beztypia Tcl.
>Innym przykladem jest Eiffel.
>W swoim czasie sztandarowy jezyk modern OOP.
>Wzor !
>Statyczny system typow. Ba  ! Rygorystyczny DbC
>No i upadl na rzecz jakiegos 'beztypowego' VB.
>
>Rowniez Pascal przegral z beztypim xBasem wszelkim chocby.

Owe ejzyki padly ze wzgledow bznesowo/socjologicznych a nie
technicznych. Radze sobie przypomniec troche historii.

A.L.

On Thu, 10 May 2007 12:49:54 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>Uż 
>
>Nooo, chyba zdali sobie sprawe ze nei zmieszcza Smalltalka
>w kuchence mikrofalowej wiec.. stworzyli Jave :0
   

Znow nieprawda. Historyczna. Stworzyli Jave jako jezyk do
programowania aplikacji webowych, a szczegilnie "appletow"

A.L.

On Thu, 10 May 2007 10:44:38 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:

>A 
>
>
>Mialem juz nie pisac, ale nie nie moge sie jednak powstrzymac. U Pana co 
>drugie slowo to 'bzdura'. To ja na codzien pisze w Javie, a nie Pan. Wiec w 
>tej gestii to ja mowie, a Pan slucha. Ja nie mam nic przeciwko jythonowi, ale 
>w Groovy jest latwiej i tyle. 
>I: jakies spacery, dobre ksiazki, przyzwoite wino i takie tam - mniej 'bzdur' 
>bedzie.

Panei Kolego, czy nie lepiej przyznac od razu ze Python jest
lepszy?...

A.L.

P.S. A ze nikt go nei uzywa?.. No coz, glupota ludzka nei zna granic.

"A.L." <fela@2005.com> wrote:

> Owe ejzyki padly ze wzgledow bznesowo/socjologicznych a nie
> technicznych. Radze sobie przypomniec troche historii.

Radze mnie nie pouczac.
Historie dobrze pamietam.

Dla mnie kazdy jezyk upadal z powodow biznesowych
badz socjologicznych badz skokowego ograniczenia
zasobow (wejscie slabym mkomputerow) a najczesciej jakiegos
mixingu tychze.

Nie wierze ze Smaltalk byl tu wyjatkiem i upadl z powodow
niby zlej jakosci technicznej, dynamic typing itd.

AK

"A.L." <fela@2005.com> wrote:

>>Nooo, chyba zdali sobie sprawe ze nei zmieszcza Smalltalka
>>w kuchence mikrofalowej wiec.. stworzyli Jave :0
>
> Znow nieprawda. Historyczna. Stworzyli Jave jako jezyk do
> programowania aplikacji webowych, a szczegilnie "appletow"

Alez wiem.
Czy Pan nie dostrzega 'usmiechu' ?

AL 

"A.L." <fela@2005.com> wrote:

> Panei Kolego, czy nie lepiej przyznac od razu ze Python jest
> lepszy?...

Panie A.L. zachowuje sie Pan delikatnei mowiac bardzo nieladnie.

Nigdzie nie napisalem ze python jest lepszy
Jak juz napisalem ciesze sie ze ktos _nie uzywa_ Pythona.
Napisalem tylko i wylacznie ze Jython jest stabilneijszy
od Grooviego.

Wiec niech mi Pan nie  wciska nie moich slow
bo bede Pana musial do KFa wsadzic.

> P.S. A ze nikt go nei uzywa?..

Niech Pan nie pisze kolejnych bzdur.

> No coz, glupota ludzka nie zna granic.

A to swieta prawda.
Cale zycie zawodowe obserwuje jej objawy.
Owczy glupi ped za jakims nowym objawieniem
jest jednym znich.

AK 

On Thu, 10 May 2007 14:58:24 +0200, "Adam Karpierz"
<karpierz@NOOOOSPAAAAMpython.pl> wrote:

>"A.L." <fela@2005.com> wrote:
>
>> Owe ejzyki padly ze wzgledow bznesowo/socjologicznych a nie
>> technicznych. Radze sobie przypomniec troche historii.
>
>Radze mnie nie pouczac.
>Historie dobrze pamietam.
>
>Dla mnie kazdy jezyk upadal z powodow biznesowych
>badz socjologicznych badz skokowego ograniczenia
>zasobow (wejscie slabym mkomputerow) a najczesciej jakiegos
>mixingu tychze.
>
>Nie wierze ze Smaltalk byl tu wyjatkiem i upadl z powodow
>niby zlej jakosci technicznej, dynamic typing itd.

Smalltalk byl doskonalej jakosci technicznej, a updl dlatego ze
zatrzymal sie w rozwoju. No i dynamic typing tez sie przylozyl.

A okres powodzenia mial, albowiem gdy ow okres powodzenia sie zaczal,
nie mial zadnego konkurenta.

A.L.

On Thu, 10 May 2007 15:00:13 +0200, "Adam Karpierz"
<karpierz@NOOOOSPAAAAMpython.pl> wrote:

>"A.L." <fela@2005.com> wrote:
>
>>>Nooo, chyba zdali sobie sprawe ze nei zmieszcza Smalltalka
>>>w kuchence mikrofalowej wiec.. stworzyli Jave :0
>>
>> Znow nieprawda. Historyczna. Stworzyli Jave jako jezyk do
>> programowania aplikacji webowych, a szczegilnie "appletow"
>
>Alez wiem.
>Czy Pan nie dostrzega 'usmiechu' ?
>
>AL 
>

Nnooo... Nieprawda :)

A device-independent programming language code-named "Oak" was the
result. 

To demonstrate how this new language could power the future of digital
devices, the Green Team developed an interactive, handheld
home-entertainment device controller targeted at the digital cable
television industry. But the idea was too far ahead of its time, and
the digital cable television industry wasn't ready for the leap
forward that Java technology offered them. 

http://www.java.com/en/about/

A.L.

"A.L." <fela@2005.com> wrote:

> A okres powodzenia mial, albowiem gdy ow okres powodzenia sie zaczal,
> nie mial zadnego konkurenta.

Kiedys Pan pisal o problemie technicznym typu
duzy image i mala komponentowosc/pliginowatosc.
Ze tez to mialo wplyw.

AK

"A.L." <fela@2005.com> wrote:

> Nnooo... Nieprawda :)

Prawda prawda. I to prawda i to prawda.
Tyle ze applety to wiele bardzij prawda
Dokladnie 2h temu rozmawialismy z kolega javowcem
na podobne tematy i wlasnie przypomnial poczatki Javy
i stwierdzil wyraznie ze jej (Javy) faktycznym
pierwszym opowazniejszym zastosowaniem
byly wlasnie applety i dlugo trwalo zanim zaczeto
pisac w Javie server-side.
Wierze mu.
Zwsze mowi prawde a w Javie siedzi cale zycie.

AK

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

 > Mialem juz nie pisac, ale nie nie moge sie jednak powstrzymac.
> U Pana co drugie slowo to 'bzdura'.

O ile mnie pamiec nie myli to Pan sie przyczepil
kilkakrotnie az do znudzenia do niby wycinania
przeze mnie cytatow i tp bzdur (przepraszam:),
a tego bardzo nie lubie bo sugeruje moja nieuczciwosc
(takie metody sa dosc (..) nawet ze wzgledy na dzielaca nas
roznice wieku) wiec nie widze powodu abym mial Pan traktowac
laskawiej i kulturalniej niz pisanie bez ogrodek.

> To ja na codzien pisze w Javie, a nie Pan.
> Wiec w  tej gestii to ja mowie, a Pan slucha.
> Ja nie mam nic przeciwko
>  jythonowi, ale w Groovy jest latwiej i tyle.

Tyle tylko ze akurat sprawdzenie groovy czy jython
do Javy mnie powierzono wiec..
Konkretnie prosze:
Porownajmy (choc juz malo pamietam) co jest latwiejsze/lepsze
w Groovym niz w Jythonie ok ?
Przy okazji porownamy najnowsza (pierwrsza stabilna ) wersje Rubiego
bo ja sprawdzenei robilem jakeisj pol roku temu a wtedy byla 0.96 chyba
Tak sie sklada ze obok mam ok 20 zaprzyjaznionych
 javowcow wiec w kwestii javy pomoga mi mam nadzieje.

AK

Adam Karpierz <karpierz@NOOOOSPAAAAMpython.pl> napisał(a): 

> "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> wrote in message:
> 
>  > Mialem juz nie pisac, ale nie nie moge sie jednak powstrzymac.
> > U Pana co drugie slowo to 'bzdura'.
> 
> O ile mnie pamiec nie myli to Pan sie przyczepil
> kilkakrotnie az do znudzenia do niby wycinania
> przeze mnie cytatow i tp bzdur (przepraszam:),
> a tego bardzo nie lubie bo sugeruje moja nieuczciwosc
> (takie metody sa dosc (..) nawet ze wzgledy na dzielaca nas
> roznice wieku) wiec nie widze powodu abym mial Pan traktowac
> laskawiej i kulturalniej niz pisanie bez ogrodek.

W ww przypadku 'bzdura' dotyczyla oceny a nie faktu. Z ocena mozna sie nie 
zgadzac, ale nazywac ja bzdura wiekszego sensu nie ma. Nie znosze 
Sienkiewicza - bzdura czy nie?


> > To ja na codzien pisze w Javie, a nie Pan.
> > Wiec w  tej gestii to ja mowie, a Pan slucha.
> > Ja nie mam nic przeciwko
> >  jythonowi, ale w Groovy jest latwiej i tyle.
> 
> Tyle tylko ze akurat sprawdzenie groovy czy jython
> do Javy mnie powierzono wiec..
> Konkretnie prosze:
> Porownajmy (choc juz malo pamietam) co jest latwiejsze/lepsze
> w Groovym niz w Jythonie ok ?
> Przy okazji porownamy najnowsza (pierwrsza stabilna ) wersje Rubiego
> bo ja sprawdzenei robilem jakeisj pol roku temu a wtedy byla 0.96 chyba
> Tak sie sklada ze obok mam ok 20 zaprzyjaznionych
>  javowcow wiec w kwestii javy pomoga mi mam nadzieje.
> 

Ocena dotyczyla postrzegania, nie stanu faktycznego (ktory moze byc zgodny z 
ocenia albo i nie). Ta subiektywna ocena i przesadzi moim zdaniem o przewadze 
Groovy nad Jythonem.
A teraz cos mniej subiektywnego. Groovy ma blizsza skladnie i umozliwia 
programowanie typowane prawie identyczne jak w Javie, ma styl bardziej 
Javovy. To umozliwia szybsze poznanie i wieksza akceptacje przecietnego 
Javovca. Nota bene, srodowisko Codehaus jakby wiecej wie o tym co boli w 
Javie niz tworcy Jythona. W Jythonie mozna niby wykorzystywac wszystko 
Javowe, ale w praktyce czesto to bolesne jest nieproporcjonalnie do 
banalnosci zagadnienia. Przyklad? Mamy pelno skryptow Jythonowych, ktore 
tworza czy zapisuja rozne rzeczy do bazy danych. W pewnym momencie 
zmienilismy jeden atrybut z int na long. W skryptach niektore setInt zostale 
zamienione na setLong, bylo to bolesne (bo nie tak automatyczne jak w Eclipse 
i Javie), ale i tak skrypty Jythonowe przestaly nagle dzialac mimo, ze 
wszedzie byly uzywane stale takie jak 33, 100 i takie tam. Okazalo sie, ze 
setLong(33) w Jythonie dziala zupelnie inaczej niz setLong(33) w Javie (czy w 
Groovy, skoro juz mowa o tym) i zupelnie nie tworzy java.lang.Long i nie 
przekazuje go do sterownika JDBC. Takie male zniezgodnosci impedancji 
potrafia z zadania na 20 min zrobic piep...nia sie na caly dzien, a nie o to 
przeciez w tym chodzi. Po tym, moj kolega, ktory jest dobrym programista, 
powiedzial, ze nastepne skrypty juz beda w Groovy, bo nie ma czasu na takie 
rzeczy. I ma racje. A to tacy wlasnie jak on beda decydowac w czym sie bedzie 
sklejac w J2EE. 



A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> >> No coz. Pan woli.
> >> Mnie sie nie chce nic nikomu udowadniac :)
> >> Za stary jestem.
> >
> > Ale wtedy widownia to nalezycie oceni :)
> 
> Oh ale Pan trafil !
> Najbardziej w d.. w zyciu to mam wlasnie wszelkie widownie
> i ich opinie :)
> 
> > Cienka to retoryka: zbyc adwersarza porownaniem do radzieckiego
> > naukowca. O pchlach nic mi zreszta nie wiadomo. Wole radziecka matematyke.
> 
> Nie widzi Pan absurdu w swym 'logicznym' wywodzie o static typing w 
Pythonie 
> ?


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

> > Zreszta, to dziwne - wycial Pan cytaty, bardzo sensowne,
> 
> Nic nie wycinalem.
> Nie zwyklem powtarzac bezsensownie cytatow z poprzedneigo postu

Ale mozna sie bylo odniesc. A tego poprzednio tez zabraklo. Teraz jest lepiej.

> > PJE - ktory mowil
> > dokladnie to samo co ja: "While Python is more powerful as a language, 
> > Java
> > beats the crap out of it in the area of standards and specifications like
> > JDBC, JNDI, and OSGi, to name just a few.[...]
> > But when I'm done, my implementation and interfaces are still not a 
> > standard
> > in the Python world. Nobody is going to know about what I did, and the 
> > next
> > guy over is going to either do the same thing I did, or throw together 
> > their
> > own little thing. Individually, perhaps, we are all productive, but our
> > collective productivity is lower in the Python community, because we are 
> > all
> > forced to reinvent 'IWheel', up until there's a 'Wheel' implementation in 
> > the
> > standard library"
> > Jeszcze raz Pan to wytnie i zignoruje?
> 
> Panie Kochany, przestan Pan truc znow o wycinaniu.
> 
> Ale merytorycznie.
> 
> 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. Wszelkie bindingi sa z natury protezami. Zreszta, 
korzystajac z przykladow Eby: jakie to niby dojrzale bindingi sa w przypadku 
JDBC, JNDI i OSGI? 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. 
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. 


> 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?
Zapomnial juz Pan, ze Nuxeo wlasnie poslalo do diablow Zope z powodow 
niedociagniec owego Zope?
Glupi Pan przeciez nie jest, jak niby mozna porownywac ogrom specyfikacji i 
implementacji w swiecie J2EE do pythonowych interfaces. To jak porownywac 
swiss knife do, no nie wiem, branzy samochodowej.
Ponownie: te dywagacje sa bezprzedmiotowe, jesli widziec w pythonie jedynie 
glue language.


> >> Akurat Python jest typowym przykladem: znajdz gotowe
> >> To typowy glue language _w zalozeniach_.
> >
> > Ale w innym jezyku, bo w Pythonie to najczesciej znajdziesz jakies
> > niestandardowe, wyciosane na kolanie, rozwiazanie. Do szybkiego hakowania 
> > to
> > OK, ale nie pisania duzego softu.
> 
> Panie kochany, Pan widzial Pythona w ogole ? :)

O tak - u siebie w pracy. 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.


> > W mojej firmie wiekszosc javowcow preferuje Groovy - lepiej dopasowany
> > do Javy jako platformy.
> > Moze to mniej elegancki jezyk, ale do sklejania zadnej szczegolnej
> > elegancji nie potrzeba.
> 
> 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).


> > Jaka wiekszosc?
> > W porownaniu do Javy czy .NET to w Pythonie prawie nic nie  ma.
> 
> Tu sie Pan zwyczajnie osmieszyl.
> W Pythonie _ma_ nic nie byc.
> Wlasnie o to chodzi zeby poza podstawowa biblioteka
> (IMHO i tak za bardzo rozbudowana _nic nie bylo_) .

No wiec chodzi o to, zeby traktowac Python jako glue? Nie bede sie klocil, 
ale niech Pan w takim razie przestanie opowiadac jaki to Python jest mocny we 
frameworkach - bo nie jest.


> > O tym wlasnie pisal PJE, ale Pan to wycial.
> > Wlasnie dlatego taki typowy biznes nie wybiera Pythona - pisanie softu w
> > nim zwykle konczy sie wlasna  implementacja IWheel w setkach roznych 
> > wersji.
> >  I to ze Python, rzekomo, jest  more powerful niczego niestety nie 
> > zmienia.
> >  Bo jako _platforma_ jest ubogi.
> 
> Nie no Panie Galicki, smiech mnie ogarnia
> Niech no Pan wiecej juz lepiej  nie pisze na temat Pythona :(

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.


> >> W Pytonie _nic_ sie wlasciwie nie pisze ale sie skleja
> >> z juz gotowych kawalkow.
> >
> > Chandlera probowali napisac - jajo wyszlo.
> 
> Ze co ? Nie ma juz chandlera ?

A jest? Zagladal Pan na strone Chandlera ostatnio? 


> > Ale w Google to ponoc pisza w tym - nie sklejaja.
> 
> To zle jesli wszytsko pisza od zera.
> Tyle ze nei sadze aby zatrudneinie w Google
> GvRa bylo po to aby na nowo wymyslac kolo.
> To zbyt powaznych czlek na zabawy :).

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


> >> Jak dla mnie to kolejne bzdury.
> >> Za duzo 'pary' tam idzie w Pythona aby traktowac w/w powaznie.
> >>
> >
> > Ale co bzdury: Google pisze i w C++ i w Pythonie i w Javie. Ale to 
> > _baardzo_
> > szczegolna firma. Jak im ktos odbierze advertisement to nie zdziwie sie 
> > jesli
> > zdechna w trzy miga. Ale na razie moga pozwolic zatrudniac najlepszych ze
> > swiata i Javy i Pythona (i produkowac mase pol-upieczonych pomyslow,
> > applikacji i bibliotek, jak dzieci)
> 
> Hehe :)


Alez to bardzo ciekawy temat (ciekawszy niz Python czy Groovy). Google 
zatrudnia na peczki znanych inzynierow. Caly czas kreuje image takiej 
superinnowacyjnej firmy. Ale co ci inzynierowie tam robia? Ci od pythona od 
lat zmieniaja google groups - ktore byly beta chyba przez pare lat (co to - 
system operacyjny czy cos rownie skomplikowane?). Google groups jest 
zabugowane i ciagle mi sie wywala. Ci od Javy pisza GMail. To zwykla web 
aplikacja. A jakie glosne nazwiska w to sa zaangazowane. Neal Gafter - w SUN 
pisal kompilatory. Teraz pisze GMail.
Amazon jest znacznie bardziej innowacyjna firma. Ich Elastic Cloud to 
prawdziwa innowacja a nie zabawki z Google Code Kinder Garden.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> wrote in message 
news:f21jng$gf$1@inews.gazeta.pl...
> Adam Karpierz <karpierz@NOOOOSPAAAAMpython.pl> napisał(a):
>
>> "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> wrote in message:
>>
>>  > Mialem juz nie pisac, ale nie nie moge sie jednak powstrzymac.
>> > U Pana co drugie slowo to 'bzdura'.
>>
>> O ile mnie pamiec nie myli to Pan sie przyczepil
>> kilkakrotnie az do znudzenia do niby wycinania
>> przeze mnie cytatow i tp bzdur (przepraszam:),
>> a tego bardzo nie lubie bo sugeruje moja nieuczciwosc
>> (takie metody sa dosc (..) nawet ze wzgledy na dzielaca nas
>> roznice wieku) wiec nie widze powodu abym mial Pan traktowac
>> laskawiej i kulturalniej niz pisanie bez ogrodek.
>
> W ww przypadku 'bzdura' dotyczyla oceny a nie faktu. Z ocena mozna sie nie
> zgadzac, ale nazywac ja bzdura wiekszego sensu nie ma. Nie znosze
> Sienkiewicza - bzdura czy nie?

Dobrze, nie ma sensu tego watku ciagnac.

> Po tym, moj kolega, ktory jest dobrym programista,
> powiedzial, ze nastepne skrypty juz beda w Groovy,
> bo nie ma czasu na takie rzeczy.

Przekonuje mnie to.
Oczywiscie gdyby inaczej pisano skrypty w Jythonie (bardziej w
Pythonowy sposob) nie bylo by tego i podobnych problemow ale
przekonuje mnie ze dla Javowcow to dodatkowy niepotrezbny koszt
wiec bardziej javowy Groovy sie bardziej sprawdzi.

PS: J2EE nei ma wlasnego 'sklejacza' ?

AK 

"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 

Witam

Aleksander Galicki wrote:

>> Dynamiczne to nie znaczy bez typowe.
> 
> Sa. Ten papier to wyjasni: http://lucacardelli.name/Papers/TypeSystems.pdf

Nie zgadzam się, z tym papierem. Ale jeśli tak postawimy definicję, to nie
mogę zaprzeczyć.

> A to zwiezle pokaze czym jest Dynamic typing:
> http://lucacardelli.name/Drawings/DynamicTypecheck/PolyCandyCartoon.pdf

Krótko mówiąc. typowe, czy bez typowe, to zależy od definicji. A grafika
bardzo ładnie obrazuje ten rodzaj definiowania typowości.
 
> PPS sam strzelilem orta:
>
charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne,charakterystyczne

:-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

On 2007-05-12, Adam Karpierz wrote:
> Boost na dzien dzisiejszy powinien byc _zakazany_ w przemyslowym
> programowaniu.
> Jedynie male jego czesci moga byc w praktyce wykorzystane.
> I to bardzo dokladnym niezaleznym (swoim) przetestowaniu.
>
> To jest jakby to Panu powiedziec hm.. parodia ochrony.
> To jest powiem wprost symulowanie ochrony.
> Prawdziwa ochrone to ma Java.
Prosiłbym o rozwinięcie dwóch powyższych tez (piszę bez ironii).

-- 
Damian Szuberski

Użytkownik "Damian 'legion' Szuberski" <legion@wmid.amu.edu.cutthisjunk.pl> 
napisał:

>> Prawdziwa ochrone to ma Java.
> Prosiłbym o rozwinięcie dwóch powyższych tez (piszę bez ironii).

Chodzi mi o dwie rzeczy:
1. nie moze byc dobrej ochrony jesli definicja
    czegos chrinionego (w tym wypadku klasy) jest zwyklym
   zmienialnym latwo kawalkiem tekstu.
2. nie moze byc dobrej ochrony jesli dostep do pol
    jest oferowany przez tak prymitywny sposob
    jak fizyczny adres pola latwo dostepny publicznie.

W Javie ciezko obejsc dostep do czegos chronionego
bo Java ma prawidlowe moduly (z upublicznionym
interfacem).

AK 

Dnia Mon, 14 May 2007 01:37:40 +0200
"Adam Karpierz" <karpierz@_NOSPAM_python.pl> napisał(a):


> > Ale std::vector czesto wystawiam jako interfejs publiczny,
> 
> Super.
> Jak Pan sobie radzi z z interface std::vector w DLLkach ?
> Jak Pan sobie radzi z z innymi interface STLowymi w DLLkach ?
C++ bardzo kiepsko współgra z DLLkami. Taka jest niestety
smutna prawda. Żeby mieć przenośną bibliotekę nalezy robić 
interfejs w C, który opakowuje kod w C++. To jest jedna z
największych wad tego języka. Co nie znaczy, że nie można
z tym żyć ;).

Pozdrawaim
-- 
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]
[ Short offer: data mining, operational research, 
  time series forecasting, consulting ]