🚀 go-pugleaf

At Mon, 09 Mar 2009 09:50:39 +0000, ZikO wrote:

> Witam
>
> Jestem programistą C++. Od jakiegoś czasu słyszę to i owo nt. Python'a.
>
> Kompletnie nie znam tego języka, nie napisałem ani jednej linii 
> programu, więc jestem Absolutely Total nOOb jeśli chodzi o ten język.
>
> Jednakże zaciekawił mnie jeden autor bardzo dobrej i bardzo cenionej 
> przez mnie książki, który zajmuje się oprócz C++, Javą i właśnie 
> Pythonem. Ponieważ chcę się nauczyć drugiego języka, bo to jak w życiu 
> zawsze się przydaje, wybór padł na Python.
>
> Możecie mi naświetlić jak Python mógłby się uzupełniać z C++? Czy ma 
> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie 
> osobiście nie chce się uczyć Javy :P. Jak trudna była by nauka tego 
> języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> klasy, wzorce kontenery STL lub wyjątki używam codziennie; dziedziczenie 
> i polimorfizm trochę mniej (wzorce załatwiają większość spraw); czasami, 
> rzadziej algorytmy

Nauka pythona jest latwa. Najtrudniejsze jest pozbycie sie zlych nawykow
z C++. Python uzupelnia C o tyle, ze pozwala ci napisac program testujacy
jakis nowy pomysl doslownie w pare minut.

> Oczywiście jeśli ktoś zna jakieś dobre książki albo strony gdzie mógłbym 
> coś o tym poczytać to byłbym bardzo wdzięczny =).

http://python.org szczegolnie http://docs.python.org/tutorial/

-- 
Radomir Dopieralski, http://sheep.art.pl

On 9 Mar, 11:26, Radomir Dopieralski <n...@sheep.art.pl> wrote:
> At Mon, 09 Mar 2009 09:50:39 +0000, ZikO wrote:
>
>
>
> > Witam
>
> > Jestem programistą C++. Od jakiegoś czasu słyszę to i owo nt. Python'a.
>
> > Kompletnie nie znam tego języka, nie napisałem ani jednej linii
> > programu, więc jestem Absolutely Total nOOb jeśli chodzi o ten język.
>
> > Jednakże zaciekawił mnie jeden autor bardzo dobrej i bardzo cenionej
> > przez mnie książki, który zajmuje się oprócz C++, Javą i właśnie
> > Pythonem. Ponieważ chcę się nauczyć drugiego języka, bo to jak w życiu
> > zawsze się przydaje, wybór padł na Python.
>
> > Możecie mi naświetlić jak Python mógłby się uzupełniać z C++? Czy ma
> > sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
> > osobiście nie chce się uczyć Javy :P. Jak trudna była by nauka tego
> > języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> > klasy, wzorce kontenery STL lub wyjątki używam codziennie; dziedziczenie
> > i polimorfizm trochę mniej (wzorce załatwiają większość spraw); czasami,
> > rzadziej algorytmy
>
> Nauka pythona jest latwa. Najtrudniejsze jest pozbycie sie zlych nawykow
> z C++. Python uzupelnia C o tyle, ze pozwala ci napisac program testujacy
> jakis nowy pomysl doslownie w pare minut.
>
> > Oczywiście jeśli ktoś zna jakieś dobre książki albo strony gdzie mógłbym
> > coś o tym poczytać to byłbym bardzo wdzięczny =).
>
> http://python.orgszczegolniehttp://docs.python.org/tutorial/
>
> --
> Radomir Dopieralski,http://sheep.art.pl

Polecam też  podręcznik na wikibooks - "Zanurkuj w pythonie"

Użytkownik "ZikO" <zebik@op.pl> napisał w wiadomości news:gp2opj$c7s$1@news.onet.pl...
> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie 
> osobiście nie chce się uczyć Javy :P. Jak trudna była by nauka tego 
> języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> 


Java należy do "świata" C++ (statyczne typowanie), jest w zasadzie jego implementacją oderwaną od zasobów binarnych. Natomiat Python to język dynamiczny. "Obiekt" jest tu pojęciem pierwotnym a nie zbiorem wskaźników i struktur bajtowych na stosie....

> Jednakże zaciekawił mnie jeden autor bardzo dobrej i bardzo cenionej
> przez mnie książki, który zajmuje się oprócz C++, Javą i właśnie
> Pythonem. Ponieważ chcę się nauczyć drugiego języka, bo to jak w życiu
> zawsze się przydaje, wybór padł na Python.

Warto poznać więcej niż dwa ;-) 

Przy czym niekoniecznie wszystko w celach "sprzedażowych". Czasem niszowy
język pięknie uczy jakichś technik programowania. Ot, pamiętam (a dawne
lata to były) jak pobawienie się Standard ML-em pozwoliło mi dużo lepiej
rozumieć o co chodzi przy rzucaniu i obsłudze wyjątków w C++.

> Możecie mi naświetlić jak Python mógłby się uzupełniać z C++? Czy ma
> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
> osobiście nie chce się uczyć Javy :P. 

I słusznie ;-) Abstrahując od sympatii/antypatii do Javy, jest ona
koncepcyjnie bardzo do C++ podobna, nowych horyzontów Ci nie da (insza
inszość że Python to też raczej język "praktyczny" a nie "wizjonerski"
jak Smalltalk czy Haskell)

Co do relacji C++ - Python. Różnie. Można w pythonie zaprototypować
rozwiązanie docelowo do napisania w C++. Można w programie w C++ zostawić
mozliwości korygowania dynamicznych elementów funkcjonalności pluginami
pythonowymi. Można różne inne rzeczy...

> Jak trudna była by nauka tego
> języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> klasy, wzorce kontenery STL lub wyjątki używam codziennie;
> dziedziczenie i polimorfizm trochę mniej (wzorce załatwiają większość
> spraw); czasami, rzadziej algorytmy

Jeśli umiesz programować, nie powinieneś mieć żadnych problemów.

Modulo zdziwienie, że nie trzeba pisać żadnych typów ;-)  (acz też,
że niektóre błędy łapią się dopiero w trakcie wykonania)


> Oczywiście jeśli ktoś zna jakieś dobre książki albo strony gdzie
> mógłbym coś o tym poczytać to byłbym bardzo wdzięczny =).

Python Tutorial - standardowy dokumencik w dystrybucji Pythona - jest
przyzwoicie napisany i zupełnie wystarcza do złapania podstaw. Osobiście
oceniam go wyżej niż parę znacznie grubszych książek.


-- 
----------------------------------------------------------------------
| Marcin Kasperski   | I have a very small head and I had better learn
| http://mekk.waw.pl |  to live with it and to respect my limitations,
|                    |  rather than to try to ignore them. (Dijskstra)
----------------------------------------------------------------------

ZikO wrote:
> Jestem programistą C++. Od jakiegoś czasu słyszę to i owo nt. Python'a.
To opowiem ci jak ja przeszedlem z tego wlasnie jezyka na Pythona majac
w sumie juz z 12 letnie doswiadczenie w C/C++.
Pierwsza rzecz ktora mnie ujela to niebywala czytelnosc kodu.
Mimo ze skladnia jest dosc podobna do tej z C to uniknieto tworzenia
potworkow znanych chociazby z szablonow C++ czy get/set z Javy.
Czyli nie zastanawiasz sie czy mozna napisac >> czy tez > > ;)
I co wiecej nie wierz temu ze skladnia jest bardzo perlish bo to dwa
rozne style kodowania.
Oczywiscie koniec z niechlujnym kodowaniem dzieki wcieciom.

Kolejna rzecz ktora mnie porazila to fakt ze mozna do problemu podejsc
zupelnie inaczej a to dzieki elestycznej konstrukcji jezyka, wbudowanym
typom i poteznej bibliotece standardowej.

Przepisalem wiele projektow z C++ na Pythona. I bez zadnego problemu w
sumie udalo mi sie dojsc do legendarnego przelicznika 1:15.
Tj tyle razy mniej kodu potrzebowalem zeby wyrazic to samo w Pythonie
niz w C++. Z biegiem czasu przelicznik jeszcze bardziej sie przesunal na
korzysc pythona (np po odkryciu setdefault na slownikach czy
map/dict/filter/zip ;) )
Ja wiem ze madre ksiazki pisane przez niby doktorow mowia ze ilosc kodu
to nie problem bo IDE Ci zalatwi wszystko.
Tylko jednak od lat w naszym swiecie jeden przelicznik sie nie zmienia -
ilosc bugow jest uzalezniona niestety od ilosc wklepanego kodu :)

Python to jezyk w ktorym pracy z projektem nie zaczynasz od codeproject
;) zeby znalezc np klasy do obslugi zbiorow czu md5 albo obslugi ftp-a.
Po prostu to tam jest, doskonale i elastycznie napisane.
Ba jak mowisz komus z C++ o tym ze uzywasz zbiorow to nawet nie wiesz o
czym mowi;)
Gdy stwierdzisz ze dobrze by bylo napisac jakas klase do obslugi np
grafiki to odkryjesz po chwili ze ktos juz to zrobil za Ciebie podobnie
jak z bibliotekami do PDF-a, obliczen numerycznych, wykresow, czy
wyszukiwania sekwencji DNA.
Pelna liste masz tutaj http://pypi.python.org/pypi ;)
Co wiecej w wiekszosic przypadkow nie przejmujesz sie platforma czy to
Mac czy Win a moze Unix albo Nokia 60.
A C++ committee zastanawia sie czy mozna jeszcze cos zakodowac za pomoca <>.

Nie musisz sie przejmowac jak zrzutowac jakas klase zeby uzyc metody z
ktorejs z 5 klas bazowych. Co wiecej, gdyby do tego doszlo to potrafisz
je dokladnie wylistowac bez uciekania sie w potworki w rodzaju
MFC::GetRuntimeClass lub rozszerzenia GCC ;)
Nie musisz uzywac klasy do obslugi stringow ktora nie zostala do nich
stworzona - vide std::string.
Co wiecej nie zaplaczesz jak nagle ktos Ci kaze obsluzyc Unicode (vide
wchar i kilka innych nieudanych implementacji...).
Nie stracisz dnia na probach skompilowania boost::regex zeby go uzyc do
zamiany paru stringow albo przedzierania sie w niuansach licencji Grety
(taki szybki regex od MS)

Python to jezyk w ktorym slowo Internet pojawia sie tak plynnie jak
nigdzie indziej. Pamietam ile bylo zachodu zanim wyklepalem pierwsza
klase w C++ ktora mogla cos wyslac na formularz WWW a i tak sie okazalo
ze z nowym VC dziala inaczej zeby nie wspomniec GC na ktorym oczywiscie
nie dzialala...

Python to jezyk w ktorym nie zesrasz sie ze szczescia przechodzac plikow
ini na XML-a bo po prostu widzisz ze XML to porazka w porownaniu z czyms
tak prostym jak np JSON.

Smieszne jest ale wiekszosc kodu ktory wklepalem w Pythonie a bedzie
tego juz pokazna ilosc MB to kod wklepany w popularnym edytorku Scite. I
nie wynika to z mojego widzimisie albo tego ze sobie nie potrafie
lepszego edytora znalezc. Po prostu wszystko co mi jest potrzebne mozna
by spisac na kartce A4 i nie potrzebuje intelisense zeby sie kapnac czy
ma cos odziedziczyc po IEnumerable czy po IDupaJas bo nie o to chodzi.
Przede wszystkim prostota.

Pythona mozesz uzywac na wiele sposobow.
Ja na codzien w pracy oprocz tego ze uzywam go do developmentu
normalnych aplikacji to tworze w nim przede wszystkim wszelakiego
rodzaju prototypy ktore pozniej czasami z musu musze przepisac na C# czy
Jave ;)
Python swietnie sie takze nadaje do wszelakiego rodzaju skryptow i
roznego rodzaju utiliszczy.
Mozesz oczywiscie uzyc go tak samo w GUI jak i w aplikacjach netowych.
Gdybys nie szukal polotu to w ostatecznosci mozesz go nawet uzyc tak
samo jak PHP uprawiajac studencki development.
A jak powyzsze doznania Cie nie jaraja to mozesz zobaczyc jeszcze
Jythona albo IronPython-a ;D

> Możecie mi naświetlić jak Python mógłby się uzupełniać z C++? Czy ma
Mozesz rozszerzac albo embedowac Pythona w swojej aplikacji na kilka
sposobow:
http://docs.python.org/extending/
http://www.python.org/doc/2.5.2/ext/embedding.html
Z perspektywy C++ mozesz popatrzec na boost.python.
Mozesz tez przypatrzec jak to np zrobili w blenderze (taka aplikacja do 3D).

> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
porownaniu do C++ oprocz tego ze musisz czesciej sprawdzac null
pointery, tfu referencje ;)
Wypala Cie akcesory i mutatory i walka z wiadrami RAMu w Netbeans czy
Eclipse ;)

> klasy, wzorce kontenery STL lub wyjątki używam codziennie
Jak zobaczysz jak proste moze byc uzycie np x, y = y, x
lub [2**i for i in range(1, 11)] to zapomnisz o <> ;)

> Oczywiście jeśli ktoś zna jakieś dobre książki albo strony gdzie mógłbym
Jedna z lepszych ksiazek jest tlumaczenie Dive into Python:
http://pl.wikibooks.org/wiki/Zanurkuj_w_Pythonie
Ale szybko sie zaczniesz nudzic ;) wiec warto sie zastanowic co tak na
prawde chcialbys robic i moze np zaczac uczyc sie jakiegos frameworka
web (Pylons, Django, web2py, ...) czy jakies GUI...
Sluzymy pomoca :)

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Dorzucę i ja swoje zdanie. Na codzień programuję w php (proszę nie
gwizdać :D ) a ad jakiegoś czasu poznaję Pythona. Python fajny język,
ale niezależnie z jakiego języka byś się przestawiał każą Ci się
oduczać złych nawyków, co w gruncie rzeczy jest trochę irytujące ;-)
Python nie jest ideałem, bo nie ma idealnego języka, trzeba dobrać
rozwiązanie uwzględniając różne czynniki, często nie związane z
programowaniem a każdy poznany język wnosi coś do naszego repertuaru
umiejętności i pozwala spojrzeć na pewne problemy z innej perspektywy.

Co do książek, podpiszę się pod Dive into Python. Jeśli jednak znasz c+
+, to zapewne około 50% to będą nudy (które równie dobrze można
potraktować jako przypomnienie ;-) ). Irytujące dla mnie trochę było
nadużywanie słowa "sztuczka", ale to już chyba tylko kwestia gustu.

I na koniec - jak dla mnie największą potęgą Pythona jest Django i
wspomniane "1:15" ;-)

On 9 Mar, 10:50, ZikO <ze...@op.pl> wrote:
> Witam
>
> Jestem programistą C++. Od jakiegoś czasu słyszę to i owo nt. Python'a.
>
> Kompletnie nie znam tego języka, nie napisałem ani jednej linii
> programu, więc jestem Absolutely Total nOOb jeśli chodzi o ten język.
>
> Jednakże zaciekawił mnie jeden autor bardzo dobrej i bardzo cenionej
> przez mnie książki, który zajmuje się oprócz C++, Javą i właśnie
> Pythonem. Ponieważ chcę się nauczyć drugiego języka, bo to jak w życiu
> zawsze się przydaje, wybór padł na Python.
>
> Możecie mi naświetlić jak Python mógłby się uzupełniać z C++? Czy ma
> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
> osobiście nie chce się uczyć Javy :P. Jak trudna była by nauka tego
> języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> klasy, wzorce kontenery STL lub wyjątki używam codziennie; dziedziczenie
> i polimorfizm trochę mniej (wzorce załatwiają większość spraw); czasami,
> rzadziej algorytmy
>
> Oczywiście jeśli ktoś zna jakieś dobre książki albo strony gdzie mógłbym
> coś o tym poczytać to byłbym bardzo wdzięczny =).
>
> Pozdrawiam.

Dzieki wielkie za odpowiedzi. Napewno wkrotce zobaczycie mnie na grupie 
z jakimis konkretnymi pytaniami :P bo zamierzam sobie przestudiowac 
tutoriale i cos zaczac robic =)

Pozdrawiam.

Hubert Woroszył wrote:
> ale niezależnie z jakiego języka byś się przestawiał każą Ci się
> oduczać złych nawyków, co w gruncie rzeczy jest trochę irytujące ;-)
Hmm, to nie do konca jest tak.
Wlasnie we wszystkich jezykach C podobnych a wiec takze Java/C#/...
korzysta sie z utartych zaproponowanych przez D&R paradygmatow
programowania.
U mnie w pracy ludzie robia sobie po 3-4 petle jedna w drugiej a to
tylko dlatego ze nie potrafia uzyc slownika.
Trzeba by zobaczyc 10 KB kodu ktory sluzy tak na prawde do porownywania
dwoch zbiorow aczkolwiek ktos kto to stworzyl nawet nie wie ze to zbior.
A wystarczy zwykly Pythonowy set :)
Nie wspomne o maniakach ktorzy pisza ciezkie MB bezmyslnych geterow i
setterow - bo tak trzeba - kompletnie nie rozumiejac po co wogole to
ktos wymyslil. Z pespektywy Pythona to faktycznie zle nawyki.

Wiekszosc tego jezyka jest bardzo dobrze zaprojektowana i dosc
uniwersalnie dzieki czemu wykorzystuje sie te same komponenty i
rozwiazania. Oczywiscie sa tez wady :)
Chyba najwazniejsza to cos takiego jak GIL ktory implikuje troche
problemow ale dojdziesz do tego :)

> Co do książek, podpiszę się pod Dive into Python. Jeśli jednak znasz c+
> +, to zapewne około 50% to będą nudy (które równie dobrze można
Dokladnie tak jest.
Tak BTW to porownujac istniejaca dokumentacje do Javy z ta do Pythona to
zauwazysz pewnie po jakims czasie ze ta istniejaca do Javy to
praktycznie jedno i to samo wygenerowana javadoc-em.
W przypadku Pythona istniejaca dokumentacja jest bardziej rozproszona
ale tez czesto bardziej roznorodna i dzieki temu mozesz znalezc nowe
perelki.
Z ciekawostek wartych obejrzenia polecam:
http://dirtsimple.org/2004/12/python-is-not-java.html
http://python.ie/blackmagic/
http://pleac.sourceforge.net/pleac_python/
http://code.activestate.com/recipes/langs/python/
http://rhodesmill.org/brandon/2009/nested-comprehensions/

> I na koniec - jak dla mnie największą potęgą Pythona jest Django i
Sa tez inne frameworki...
haha ;)

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Dnia 09-03-2009 o 23:06:21 Artur Lew <no_spamik_artee@poczta.onet.pl>  
napisał(a):

>> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
> Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
> porownaniu do C++

LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem  
zasobów to nic? :) W Javie to jest nie do pomyślenia. C++ (z samą Javą  
włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma HotSpota,  
który dzięki agresywnej kompilacji inline potrafi inteligentnie  
optymalizować już działający kod. W efekcie Java może być czasem nawet  
wielokrotnie szybsza od C++ króry skazany jest tylko na to co potrafi  
zrobić (jednorazowo) jego kompilator. Ale fak, że oba języki są kierowane  
do trochę innych segmentów. C++ jest bliżej sprzętu. Dla Javy "sprzęt" to  
wirtualny komputer JVM (co z kolei daje multiplatformowaoć niedostępną dla  
C++)

> oprocz tego ze musisz czesciej sprawdzac null pointery, tfu referencje ;)
> Wypala Cie akcesory i mutatory i walka z wiadrami RAMu w Netbeans czy
> Eclipse ;)

Aby używać platformy Javy nie trzeba używać języka Java (jak ktoś nie  
lubi) można dużo lepszego, np. Scali, Clojure itp (do wyboru ponad 200  
języków).

Można użyć nawet Jythona, javowej implementacji Pythona. Co do bibliotek  
to platforma Javy ma je o wiele dojrzalsze od Pythona (w końcu wpakowano w  
nie setki milionów dolarów). Więc podsumowując to wszystko, powiem tak:  
warto znać platformę Javy. Sam język Java jest prosty i prymitywny, ale to  
taki współczesny assembler z którego nie trzeba korzystać. Wygodniej jest  
użyć Scali.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 09-03-2009 o 13:02:56 William <nie@ma.mnie.pl> napisał(a):

> Java należy do "świata" C++ (statyczne typowanie), jest w zasadzie jego  
> implementacją oderwaną od zasobów binarnych. Natomiat Python to język  
> dynamiczny. "Obiekt" jest tu pojęciem pierwotnym a nie zbiorem  
> wskaźników i struktur bajtowych na stosie....

W Scali też wszystko jest obiektem i to na poziomie o wiele bardziej  
spójnym niż w Pythonie, mimo że Scal jest też językiem statycznie  
typowanym (choć ma b. inteligentnę inferencję typów, więc często nie  
trzeba nic deklarować). Scala to pure OOP oraz pure FP równocześnie,  
funkcje mogą brać funkcje jako parametry, funkcje mają wartość, każda  
wartość jest obiektem (stąd i funkcje są obiektami), można tworzyć DSL  
lepsze niż w Ruby. Ale co najważniejsze, Scala prawie nie ma składni  
(trochę podobnie do Lispa), więc nie ma ograniczeń tak jak inne języki  
(prawie wszystko jest zrobione na bibliotekach, np. składnia "erlangowa":  
obiekt ! asynchroniczny_komunikat wygląda identycznie, ale to nie jest  
żadna specjalna składnia, ale zapis operatorowy z metodą o nazwie !)

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 2009-03-19, czw o godzinie 14:21 +0000, Jaroslaw Zabiello pisze:
> Dnia 09-03-2009 o 23:06:21 Artur Lew <no_spamik_artee@poczta.onet.pl>  
> napisał(a):
> 
> >> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
> > Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
> > porownaniu do C++
> 
> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem  
> zasobów to nic? :) 

BO związany z niezwolnieniem zasobów? A to jak działa?

> W Javie to jest nie do pomyślenia. C++ (z samą Javą  
> włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma
> HotSpota,  
> który dzięki agresywnej kompilacji inline potrafi inteligentnie  
> optymalizować już działający kod. W efekcie Java może być czasem
> nawet  
> wielokrotnie szybsza od C++ króry skazany jest tylko na to co
> potrafi  
> zrobić (jednorazowo) jego kompilator. 

Ale masz na to jakieś przykłady, prawda?

-- 
szymon

Dnia 19-03-2009 o 14:44:23 szymon <news@mabateus.pl_without> napisał(a):

>> > Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
>> > porownaniu do C++
>>
>> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem
>> zasobów to nic? :)
>
> BO związany z niezwolnieniem zasobów? A to jak działa?

Jak masz GC to nie musisz o takich rzeczach pamiętać.

>> W Javie to jest nie do pomyślenia. C++ (z samą Javą
>> włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma
>> HotSpota,
>> który dzięki agresywnej kompilacji inline potrafi inteligentnie
>> optymalizować już działający kod. W efekcie Java może być czasem
>> nawet
>> wielokrotnie szybsza od C++ króry skazany jest tylko na to co
>> potrafi
>> zrobić (jednorazowo) jego kompilator.
>
> Ale masz na to jakieś przykłady, prawda?

http://www.stefankrause.net/wp/?p=6

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Oczywiście jabowy HotSpot musi być "rozgrzany", bo inaczej testowanie  
wydajności jest o kant dupy potłuc

http://stuq.nl/weblog/2009-01-28/why-many-java-performance-tests-are-wrong

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 2009-03-19, czw o godzinie 15:31 +0000, Jaroslaw Zabiello pisze:
> Dnia 19-03-2009 o 14:44:23 szymon <news@mabateus.pl_without> napisał(a):
> 
> >> > Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
> >> > porownaniu do C++
> >>
> >> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem
> >> zasobów to nic? :)
> >
> > BO związany z niezwolnieniem zasobów? A to jak działa?
> 
> Jak masz GC to nie musisz o takich rzeczach pamiętać.
> 

Czy możesz mi choć teoretycznie pokazać jak możesz mieć BO poprzez
niezwolnienie zasobów?

-- 
szymon

Dnia 19-03-2009 o 15:50:48 szymon <news@mabateus.pl_without> napisał(a):

> Czy możesz mi choć teoretycznie pokazać jak możesz mieć BO poprzez
> niezwolnienie zasobów?

Chodziło mi wlaściwie tylko o ogólne niebezpieczeństwo związane z pracą ze  
wskaźnikami. GC to duży krok naprzód.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Jaroslaw Zabiello powiada :
> Dnia 09-03-2009 o 13:02:56 William <nie@ma.mnie.pl> napisał(a):
>
>> Java należy do "świata" C++ (statyczne typowanie), jest w zasadzie jego  
>> implementacją oderwaną od zasobów binarnych. Natomiat Python to język  
>> dynamiczny. "Obiekt" jest tu pojęciem pierwotnym a nie zbiorem  
>> wskaźników i struktur bajtowych na stosie....

Programując w Javie widzi się te struktury bajtowe na stosie?

> W Scali też wszystko jest obiektem i to na poziomie 
> o wiele bardziej spójnym niż w Pythonie, 

Zaciekawiłeś mnie, czym się to objawia?

> Scala to pure OOP oraz pure FP równocześnie,

Pliz, nie wal takich marketingowych frazesów jak o ,,inteligentym''
optymalizowaniu przy pomocy agresywnej kompilacji yadda yadda yadda,
to strasznie utrudnia rozmowę. Nie ani pure FP ani pure OOP.
  
> funkcje mogą brać funkcje jako parametry, funkcje mają wartość, 
> każda  wartość jest obiektem (stąd i funkcje są obiektami), 

To jeszcze nie oznacza pure FP - choćby brakuje zupełnie 
podstawowej cechy, mianowicie referential transparency. 
A podstawową cegiełką może być albo anonimowa wartość, albo 
mutowalny obiekt z tożsamością - fermionów z barionami nie 
zunifikujesz choćbyś zjadł tysiąc kotletów. Można (jak w Pythonie) 
ująć jedne i drugie, ale to nie jest puree tylko groch z kapustą.

> Ale co najważniejsze, Scala prawie nie ma składni 
> (trochę podobnie do Lispa), więc nie ma ograniczeń 
> tak jak inne języki  (prawie wszystko jest zrobione 
> na bibliotekach, np. składnia "erlangowa":  
> obiekt ! asynchroniczny_komunikat wygląda identycznie, 
> ale to nie jest żadna specjalna składnia, ale zapis 
> operatorowy z metodą o nazwie !)

Tu już coś wymyślasz, ma składnię jak najbardziej, 
zaprezentowałeś tylko przeciążanie operatorów 
(co do szczęśliwości tej cechy c++, że tak powiem, 
zdania są podzielone). To, że przesyłanie komunikatów 
jest realizowane bibliotecznie, jest cechą semantyki 
języka a nie składni. A tak się składa, że akurat
przesyłanie komunikatów (chociaż pomiędzy obiektami
a nie procesami jak w Erlangu) jest fundamentalną
cechą OOP, czysto obiektowy język by się obszedł
bez takich błędów i wypaczeń Scali jak if czy for.


Piotr Sawicki

Jaroslaw Zabiello powiada :
> Dnia 09-03-2009 o 13:02:56 William <nie@ma.mnie.pl> napisał(a):
>
>> Java należy do "świata" C++ (statyczne typowanie), jest w zasadzie jego  
>> implementacją oderwaną od zasobów binarnych. Natomiat Python to język  
>> dynamiczny. "Obiekt" jest tu pojęciem pierwotnym a nie zbiorem  
>> wskaźników i struktur bajtowych na stosie....

Programując w Javie widzi się te struktury bajtowe na stosie?

> W Scali też wszystko jest obiektem i to na poziomie 
> o wiele bardziej spójnym niż w Pythonie, 

Zaciekawiłeś mnie, czym się to objawia?

> Scala to pure OOP oraz pure FP równocześnie,

Pliz, nie wal takich marketingowych frazesów jak o ,,inteligentym''
optymalizowaniu przy pomocy agresywnej kompilacji yadda yadda yadda,
to strasznie utrudnia rozmowę. Scala nie jest ani pure FP ani pure OOP.
  
> funkcje mogą brać funkcje jako parametry, funkcje mają wartość, 
> każda  wartość jest obiektem (stąd i funkcje są obiektami), 

To jeszcze nie oznacza pure FP - choćby brakuje zupełnie 
podstawowej cechy, mianowicie referential transparency. 
A podstawową cegiełką może być albo anonimowa wartość, albo 
mutowalny obiekt z tożsamością - fermionów z barionami nie 
zunifikujesz choćbyś zjadł tysiąc kotletów. Można (jak w Pythonie) 
ująć jedne i drugie, ale to nie jest puree tylko groch z kapustą.

> Ale co najważniejsze, Scala prawie nie ma składni 
> (trochę podobnie do Lispa), więc nie ma ograniczeń 
> tak jak inne języki  (prawie wszystko jest zrobione 
> na bibliotekach, np. składnia "erlangowa":  
> obiekt ! asynchroniczny_komunikat wygląda identycznie, 
> ale to nie jest żadna specjalna składnia, ale zapis 
> operatorowy z metodą o nazwie !)

Tu już coś wymyślasz, ma składnię jak najbardziej, 
zaprezentowałeś tylko przeciążanie operatorów 
(co do szczęśliwości tej cechy c++, że tak powiem, 
zdania są podzielone). To, że przesyłanie komunikatów 
jest realizowane bibliotecznie, jest cechą semantyki 
języka a nie składni. A tak się składa, że akurat
przesyłanie komunikatów (chociaż pomiędzy obiektami
a nie procesami jak w Erlangu) jest fundamentalną
cechą OOP, czysto obiektowy język by się obszedł
bez takich błędów i wypaczeń Scali jak if czy for.


Piotr Sawicki

/me powiada :

> A podstawową cegiełką może być albo anonimowa wartość, 
> albo mutowalny obiekt z tożsamością - fermionów 
> z barionami nie zunifikujesz 

Wroć - z bozonami, dość kompromitujące przeklawiaturzenie.
Sto razy przepisać: nie będę używał analogii od czapy. Chodziło 
oczywiście o singletonowość FP-wartości, a nie połówkowość spinu. 


Piotr Sawicki

Dnia 19-03-2009 o 16:48:02 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
napisał(a):

>> W Scali też wszystko jest obiektem i to na poziomie
>> o wiele bardziej spójnym niż w Pythonie,
>
> Zaciekawiłeś mnie, czym się to objawia?

Niespójność modelu obiektowego Pythona było tu wcześniej omawiana  
http://tinyurl.com/cmx4rp

> Pliz, nie wal takich marketingowych frazesów jak o ,,inteligentym''
> optymalizowaniu przy pomocy agresywnej kompilacji yadda yadda yadda,

Frazesów? Mowa była o szybkości jaką Javie daje HotSpot którego nie ma w  
C++.

> Scala nie jest ani pure FP ani pure OOP.

No dobra, cofam to pure. Fakt, że nie jest pure FP bo chociażby posiada  
var. My mistake. Scala jest językiem hybrydowym: OOP + FP.

>> Ale co najważniejsze, Scala prawie nie ma składni
>> (trochę podobnie do Lispa), więc nie ma ograniczeń
>> tak jak inne języki  (prawie wszystko jest zrobione
>> na bibliotekach, np. składnia "erlangowa":
>> obiekt ! asynchroniczny_komunikat wygląda identycznie,
>> ale to nie jest żadna specjalna składnia, ale zapis
>> operatorowy z metodą o nazwie !)
>
> Tu już coś wymyślasz, ma składnię jak najbardziej,

Owszem, ale bardzo niewielką. Trochę naśladuje tu podejście Lispa i  
Smalltalka.

> czysto obiektowy język by się obszedł bez takich błędów i wypaczeńScali  
> jak if czy for.

Dlaczego zaraz wypaczenie? Dlatego, że for jest wyrażeniem? Z jaką cechą  
OOP to koliduje?

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Piotr Sawicki pisze:
> Jaroslaw Zabiello powiada :
>> Dnia 09-03-2009 o 13:02:56 William <nie@ma.mnie.pl> napisał(a):
>>
> 
>> Scala to pure OOP oraz pure FP równocześnie,
> 
> Pliz, nie wal takich marketingowych frazesów jak o ,,inteligentym''
> optymalizowaniu przy pomocy agresywnej kompilacji yadda yadda yadda,
> to strasznie utrudnia rozmowę. Scala nie jest ani pure FP ani pure OOP.
>   

Scala jest pure OO, python nie, zresztą ten temat już tu przerabialiśmy:
http://groups.google.com/group/pl.comp.lang.python/msg/080e9b7be996e3e5


>> funkcje mogą brać funkcje jako parametry, funkcje mają wartość, 
>> każda  wartość jest obiektem (stąd i funkcje są obiektami), 
> 
> To jeszcze nie oznacza pure FP - choćby brakuje zupełnie 
> podstawowej cechy, mianowicie referential transparency. 
> A podstawową cegiełką może być albo anonimowa wartość, albo 
> mutowalny obiekt z tożsamością - fermionów z barionami nie 
> zunifikujesz choćbyś zjadł tysiąc kotletów. Można (jak w Pythonie) 
> ująć jedne i drugie, ale to nie jest puree tylko groch z kapustą.
> 
Co nie znaczy że nie można pisać z stylu pure FP, scala nawet zachęca do 
tego, ale zgoda, scala nie jest pure FP.

>> Ale co najważniejsze, Scala prawie nie ma składni 
>> (trochę podobnie do Lispa), więc nie ma ograniczeń 
>> tak jak inne języki  (prawie wszystko jest zrobione 
>> na bibliotekach, np. składnia "erlangowa":  
>> obiekt ! asynchroniczny_komunikat wygląda identycznie, 
>> ale to nie jest żadna specjalna składnia, ale zapis 
>> operatorowy z metodą o nazwie !)
> 
> Tu już coś wymyślasz, ma składnię jak najbardziej, 
> zaprezentowałeś tylko przeciążanie operatorów 
> (co do szczęśliwości tej cechy c++, że tak powiem, 
> zdania są podzielone). To, że przesyłanie komunikatów 
> jest realizowane bibliotecznie, jest cechą semantyki 
> języka a nie składni. A tak się składa, że akurat
> przesyłanie komunikatów (chociaż pomiędzy obiektami
> a nie procesami jak w Erlangu) jest fundamentalną
> cechą OOP, czysto obiektowy język by się obszedł
> bez takich błędów i wypaczeń Scali jak if czy for.
> 

W scali dużo mocniejsze narzędzia to np pass by-name, implicits, traits, 
second rank polymorphism itp.

lopex

Dnia 2009-03-19, czw o godzinie 16:07 +0000, Jaroslaw Zabiello pisze:
> Dnia 19-03-2009 o 15:50:48 szymon <news@mabateus.pl_without> napisał(a):
> 
> > Czy możesz mi choć teoretycznie pokazać jak możesz mieć BO poprzez
> > niezwolnienie zasobów?
> 
> Chodziło mi wlaściwie tylko o ogólne niebezpieczeństwo związane z pracą ze  
> wskaźnikami. GC to duży krok naprzód.
> 

Dawno się tak nie uśmiałem :) Czyli rozumiem, że teraz wycofujesz się z
tego, że BO powoduje niezwalnianie zasobów? Czy w ogóle wiesz o czym
piszesz gdy piszesz o C++? I teraz te wskaźniki, po co chcesz używać w 
C++ gołe wskaźniki? Piszesz tak jakby trzeba było je używać.
GC to nie duży krok naprzód, to inne podejście generujące inną klasę
problemów, a zwalniać zasoby i tak w javie czasem trzeba.

Oczywiście nie twierdzę, że c++ jest lepsze od javy, tylko mnie śmieszą
argumenty w stylu tego nieszczęsnego BO w związku z niezwolnionymi
zasobami.


-- 
szymon

Jaroslaw Zabiello wrote:
>>> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
>> Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
>> porownaniu do C++
> 
> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem 
> zasobów to nic? :)

ROTFL!

Co ma buffer overflow do zwalniania zasobów?

> W Javie to jest nie do pomyślenia.

Buffer overflow to może jeszcze. Zapomniane zwolnienie zasobów -- jak 
najbardziej do pomyślenia i się zdarza.

> C++ (z samą Javą 
> włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma HotSpota, 
> który dzięki agresywnej kompilacji inline potrafi inteligentnie 
> optymalizować już działający kod. W efekcie Java może być czasem nawet 
> wielokrotnie szybsza od C++ 

A świstak siedzi... I kikukrotnie zawija.

W praktycznej praktyce to zwykle Java jest wolniejsza i z rzadka jest 
(bardzo) nieznacznie szybsza. Przy czym, po części wynika to z ciężkiego 
object modelu platformy (jest to zatem problemem wszystkiego co na tej 
platformie działa).

> króry skazany jest tylko na to co potrafi 
> zrobić (jednorazowo) jego kompilator.

Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega słyszał?

> Ale fak, że oba języki są 
> kierowane do trochę innych segmentów. C++ jest bliżej sprzętu. Dla Javy 
> "sprzęt" to wirtualny komputer JVM (co z kolei daje multiplatformowaoć 
> niedostępną dla C++)

I dlatego soft napisany na jedną JVM nie działa na drugiej. Szczególnie 
to widac w J2ME.


>> oprocz tego ze musisz czesciej sprawdzac null pointery, tfu referencje ;)
>> Wypala Cie akcesory i mutatory i walka z wiadrami RAMu w Netbeans czy
>> Eclipse ;)
> 
> Aby używać platformy Javy nie trzeba używać języka Java (jak ktoś nie 
> lubi) można dużo lepszego, np. Scali, Clojure itp (do wyboru ponad 200 
> języków).
> 
> Można użyć nawet Jythona, javowej implementacji Pythona. Co do bibliotek 
> to platforma Javy ma je o wiele dojrzalsze od Pythona (w końcu wpakowano 
> w nie setki milionów dolarów). Więc podsumowując to wszystko, powiem
> tak: warto znać platformę Javy. Sam język Java jest prosty i prymitywny, 
> ale to taki współczesny assembler z którego nie trzeba korzystać. 
> Wygodniej jest użyć Scali.

Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
ludzi nie ma w mózgu dwu "ośrodków": ośrodka pojmowania rekurencji i 
ośrodka pojmowania wskaźników (lub szerzej patrząc indyrekcji). 
Informartyk musi te ośrodki mieć. Znajomość Lispa lub inszych języków 
funkcyjnych veryfikuje istnienie pierwszego ośrodka, znajomość języka z 
"nagimi" wskaźkami weryfikuje ten drugi.

Traktowanie Javy jako assemblera prowadzi po masowej produkcji 
niedoprogramistów, nie zdolnych do napisania niczego bardziej złożonego.
Bo w Javie, Scali czy Pythonie w końcu wychodzi, że ten ośrodek od 
wskaźników jest jak najbardziej potrzebny.

pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

ZikO wrote:
> Jestem programistą C++. Od jakiegoś czasu słyszę to i owo nt. Python'a.
> 
> Kompletnie nie znam tego języka, nie napisałem ani jednej linii 
> programu, więc jestem Absolutely Total nOOb jeśli chodzi o ten język.
> 
> Jednakże zaciekawił mnie jeden autor bardzo dobrej i bardzo cenionej 
> przez mnie książki, który zajmuje się oprócz C++, Javą i właśnie 
> Pythonem. Ponieważ chcę się nauczyć drugiego języka, bo to jak w życiu 
> zawsze się przydaje, wybór padł na Python.
> 
> Możecie mi naświetlić jak Python mógłby się uzupełniać z C++?

Inni już o różnych rzeczach pisali, ale jedno nie padło:

boost::python i okolice. Czyli możliwość łączenia obu.


> Czy ma 
> sens uczenie się tego języka czy po prostu zająć się Javą? 

Ma sens. Java to takie zubożone C++ z gumowymi barierkami i w 
przeciwieństwie do C++ które ma bibliotekę standardową skrajnie ubogą, 
Java ma skrajnie przeładowaną.

> Mnie 
> osobiście nie chce się uczyć Javy :P. Jak trudna była by nauka tego 
> języka jeśli znam C++, a znam go dosyć dobrze. Takie rzeczy jak:
> klasy, wzorce kontenery STL lub wyjątki używam codziennie; dziedziczenie 
> i polimorfizm trochę mniej (wzorce załatwiają większość spraw); czasami, 
> rzadziej algorytmy

Python ogólnie jest łatwy :)


pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

Sebastian Kaliszewski pisze:

> A świstak siedzi... I kikukrotnie zawija.
> 
> W praktycznej praktyce to zwykle Java jest wolniejsza i z rzadka jest 
> (bardzo) nieznacznie szybsza. Przy czym, po części wynika to z ciężkiego 
> object modelu platformy (jest to zatem problemem wszystkiego co na tej 

Ooo, a na czym to miałby polegać ten ciężki model ?

> platformie działa).
> 
>> króry skazany jest tylko na to co potrafi zrobić (jednorazowo) jego 
>> kompilator.
> 
> Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega 
> słyszał?
> 
maszyny javy robią takie rzeczy których llvm jest przez dekadę nie 
będzie robić.


> Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
a jednak.

lopex

Jaroslaw Zabiello wrote:
> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem
LOL wlasnie.
Bo siedzialem nad kodem w C++ ktory mial 1GB zrodel i problemem nie byly
w nim null pointery (w praktyce jak nie kombinujesz to ciezko cos
spieprzyc przekazujac referencje do obiektu). Mam za to teraz projekcik
Javowy z jakies 100 MB zrodel i uwierz mi ze ilosc ifow sprawdzajacych
null referencje to ze 2% tego kodu a i tak sie wypier... gdzie bys nie
popatrzyl.
W praktyce to niestety radosne pierdu pierdu ksiazkowe o Javie nie
sprawdza sie w duzym produkcyjnym kodzie.

> zasobów to nic? :) W Javie to jest nie do pomyślenia. C++ (z samą Javą
Zwolnienie zasobow? Rozumiem ze zyjesz jeszcze w swiecie D&R?
Od wiekow nie ma z tym problemow zwlaszcza jak sie poucina troche lapy
programistom za jakies magiczne rzutowania i uzywa STL-a.
Co do zwalniania zasobow w Javie to problem jest inny.
Nieumiejetne korzystanie z GC. I czasami to wiekszy problem niz null
pointery w C.

> włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma HotSpota,
Jep. A Ty znowu o kolejnym jezyku z http://99-bottles-of-beer.net/ ;)
Co mnie Scala obchodzi. Ja na codzien widze ta cholerna Jave i jak sie
to sypie. Moze to tez kwestia uzytych technologii (ESB) ale siedzialem
kilkanascie lat nad C++ i potrafie z sentymentem wspominac ten piekny
swiat w porownaniu do Javy (i to ze moj VC nie odswiezal mi ekranu ze
zrodlami 15 minut jak robi to NetBeans czy Eclipse ;))
Nie wspomne ze class loader laduje mi inna biblioteke w runtime do
XPatha w zaleznosci od rodzaju serwera aplikacyjnego.
Juz nie wspomne o spiskowej teorii ze robi mi to w piatek o 16...

> który dzięki agresywnej kompilacji inline potrafi inteligentnie
A co to wspolnego z tematem tej dyskusji ?
Agresywna kompilacja jest fajna cecha ale w praktyce oznacza ze kod musi
byc przebudowany do konkretnej maszyny albo musi sie JVM rozbujac.
Niestety czesto brakuje mi RAMu zeby doczekac sie czy sie juz rozbujal...

> wielokrotnie szybsza od C++ króry skazany jest tylko na to co potrafi
Tja ;)
Wyobraz sobie ze jakos tego nie widze w rzeczywistym swiecie.
I jak mowilem nie chodzi mi o ksiazkowe zastosowania tylko o potezny
produkcyjny kod.

> Aby używać platformy Javy nie trzeba używać języka Java (jak ktoś nie
A Ty Jarku znowu sie naczytales googlowych nowosci.
Na razie w zastosowaniach realnych niestety to utopia.
Tak jak szalone projekty Jython, IronPython, PyPi, itp...

> lubi) można dużo lepszego, np. Scali, Clojure itp (do wyboru ponad 200
Na http://99-bottles-of-beer.net/ masz do wyboru 1253 unikalnych jezykow...

> to platforma Javy ma je o wiele dojrzalsze od Pythona (w końcu wpakowano
I tutaj takze sie mylisz.
Ja wiem ze w ksiazkach pisza o tym ze jest wiele standardow i ze
wszystko dziala idealnie bez zmiany bajta kodu.
W praktyce okazuje sie ze to wszystko to troche mit bo niby standard
mowi jedno ale przenoszac glupia aplikacje pomiedzy paroma serwerami
Tomcat, OAS czy GlassFish napotykamy mase problemow poczawszy od
bibliotek w wersji 0.11a17rc1 do wrecz binarnej niekompatybilnosci.
Nie wspomne o cudownym EJB...
Za Java stoi kasa to fakt. W koncu to Sun. Ala cala ta propaganda
sukcesu nie stoi na tak solidnych filarach na jakie wyglada...
Tak BTW pamietam wypowiedz jednego dyra z Assecco (wczesniej Comp) o tym
jak u nich uzywa sie Javy.
Strona belkotu w Software z masa skrotow przeplatane slowami industrial,
EJB, standard, BPL, bussines... Jednym slowem wywiad z czlowiekiem ktory
zjadl zeby na Javie. Znam teraz typa osobisice i wiem ze czlowiek nie
napisal bajta kodu w Javie. Ot propaganda sukcesu gloszona z folderow
reklamowych Sun-a ;)
Owszem moze przemawia przez mnie teraz troche zawisc i zazdrosc bo
czasem Pythonowi przydalaby sie taka propaganda i kasa.
Dowod ze YT i Google tego uzywaja jest malo zachecajacy i za malo tam
industrial ;)
Reasumujac uwazam ze twierdzenie ze Java ma super biblioteki a Python
nie jest troche wyrwaniem sie przed szereg.

> w nie setki milionów dolarów). 
Tylko pozazdroscic :)

> tak: warto znać platformę Javy. Sam język Java jest prosty i prymitywny,
A to masz racje.
Zakladanie ze znam PHP i Pythona i jestem programista jest glupie z
samego zalozenia.
Sam polecam Jave ludziom do nauki ale dyskusja zaczela sie czy warto
uczyc sie Pythona.
I na pewno warto bo spojrzenie na dany problem w Javie czesto niczym sie
nie rozni od spojrzenia na to w C/C++ (nie mowimy o belkocie w rodzaju
AspectJ/IOC/etc...). Natomiast spojrzenie Pythonowe (czy np rubinowe)
powoduje ze duzo ladniej bedziesz kodowal w Javie czy w C# (jezeli
mowimy o industrial ;)).

> ale to taki współczesny assembler z którego nie trzeba korzystać.
> Wygodniej jest użyć Scali.
Hmm, czy po okresie fascynacji Pythonem, Rubym, Erlangiem, Java czas na
Scale ?
;)

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Sebastian Kaliszewski wrote:
> boost::python i okolice. Czyli możliwość łączenia obu.
Dorzuce tylko pare groszy.
Otoz swego czasu mialem dosc duze problemy zeby to przekompilowac na AIX
jak i na VC. I troche mnie przerazil poziom abstrakcji i sztuczek
kompilatora zeby to ladnie zbudowac.
Nio i ten nieszczesny bjam ale na szczescie sa alternatywy.

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Marcin Mielżyński <lopx@gazeta.pl> wrote:
> Sebastian Kaliszewski pisze:
> > platformie działa).
> > 
> >> króry skazany jest tylko na to co potrafi zrobić (jednorazowo) jego 
> >> kompilator.
> > 
> > Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega 
> > słyszał?
> > 
> maszyny javy robią takie rzeczy których llvm jest przez dekadę nie 
> będzie robić.

Po pierwsze, wiele z tego jest tylko kwestią implementacji (ktoś tego nie
zrobił/zrobił/zrobił produkcyjnie). Więc mówienie o dekadach nie różni się
specjalnie od wróżbiarstwa.

Po drugie, w wielu wypadkach niemożliwa jest dynamiczna analiza (bo ona też
kosztuje, wymaga "rozgrzewania", zajmuje ograniczone zasoby) a opłaca się 
kod wielokrotnie uruchomić na architekturze docelowej (lub zbliżonej) i 
go odpowiednio przygotować. 

Po trzecie też rzucę linkiem:
http://www.lri.fr/~girbal/site_wrapit/iterative.html

-- 
    ,--._______   -----------------------------------------------------
   '.  o}      )~                Piotr Błaszyński
(_/,=,   |___| |          mailto: pblaszynski@wi.ps.pl
    /_/|_| |_|_|  _____________________________________________________

Marcin Mielżyński powiada :
>
> Scala jest pure OO, python nie, zresztą ten temat już tu przerabialiśmy:
> http://groups.google.com/group/pl.comp.lang.python/msg/080e9b7be996e3e5

Że python nie jest to żadna tajemnica, ale o Scali tam ani słowa.

> Co nie znaczy że nie można pisać z stylu pure FP, 
> scala nawet zachęca do tego, ale zgoda, scala nie jest pure FP.

No właśnie bez referential transparency to można sobie najwyżej
w kodzie źródłowym poimitować styl funkcyjny. ale nie da się
tego przetransformować prawidłowo. Potem wychodzi callowanie
procedury za każdą aplikacją funkcji albo podobne kwiatki.

> W scali dużo mocniejsze narzędzia to np pass by-name, 
> implicits, traits, second rank polymorphism itp.

Fajny stos ficzerów, ale to chyba nie dowód na pure OO?
Wołanie przez nazwę jest bodaj z Algola na przykład.


Piotr Sawicki

Jaroslaw Zabiello powiada :

>> Pliz, nie wal takich marketingowych frazesów jak o ,,inteligentym''
>> optymalizowaniu przy pomocy agresywnej kompilacji yadda yadda yadda,
>
> Frazesów? Mowa była o szybkości jaką Javie daje HotSpot 
> którego nie ma w  C++.

Mowa była o używaniu sformułowań prosto ze sloganów reklamowych.
Sorry, ale włącza mi się ten tryb jak widzę ,,inteligentne''.

>> Tu już coś wymyślasz, ma składnię jak najbardziej,
>
> Owszem, ale bardzo niewielką. Trochę naśladuje 
> tu podejście Lispa i  Smalltalka.

40 słów kluczowych, 6 stron reguł gramatycznych.

>> czysto obiektowy język by się obszedł bez takich 
>> błędów i wypaczeńScali jak if czy for.
>
> Dlaczego zaraz wypaczenie? Dlatego, że for 
> jest wyrażeniem? Z jaką cechą  OOP to koliduje?

Nie z obiektowością tylko z czystością. Smalltalk
takie rzeczy załatwia bibliotecznie (nie wspominając
o tym, że jak się ma polimorfizm to if jest rupieciem).


Piotr Sawicki

Jaroslaw Zabiello pisze:
> Dnia 09-03-2009 o 23:06:21 Artur Lew <no_spamik_artee@poczta.onet.pl> 
> napisał(a):
> 
>>> sens uczenie się tego języka czy po prostu zająć się Javą? Mnie
>> Hmm. Zmarnujesz mlode lata siadajac do Javy ktora nic nie wnosi w
>> porownaniu do C++
> 
> LOL! A częsty błąd buffer overflow związane z zapomniamym zwolnieniem 
> zasobów to nic? :) W Javie to jest nie do pomyślenia. C++ (z samą Javą 
> włącznie) cienko wygląda przy możliwościach Scali. C++ nie ma HotSpota, 
> który dzięki agresywnej kompilacji inline potrafi inteligentnie 
> optymalizować już działający kod. W efekcie Java może być czasem nawet 
> wielokrotnie szybsza od C++ króry skazany jest tylko na to co potrafi 
> zrobić (jednorazowo) jego kompilator. Ale fak, że oba języki są 
> kierowane do trochę innych segmentów. C++ jest bliżej sprzętu. Dla Javy 
> "sprzęt" to wirtualny komputer JVM (co z kolei daje multiplatformowaoć 
> niedostępną dla C++)
>
Mijasz się z prawdą buffer overflow nie ma nic wspólnego ze zwalnianiem 
zasobów.
Prawdopodobnie chodziło Ci o zwalnianie pamięci. Pisząc w Javie też jest 
bardzo łatwo napisać kod, który będzie powodował "wycieki". Kolega, 
który siedzi za mną w pracy, praktycznie nic innego nie robi tylko 
poprawia aplikacje napisane dla Jboss, które puchną i puchną a javowy GC 
jakoś nie potrafi sobie poradzić.

Żeby  nie było całkiem nie związane z tematem. Java ma najwięcej 
gotowych bibliotek i sprawdzonych rozwiązań, więcej niż Python ,C++ i to 
jest nie do przebicia a nie multiplatformowość, która dotyczy tylko Javy 
SE i JEE.

Java jest jednak k... p... jeśli chcesz napisać coś relatywnie prostego, 
często xmlowa, getset masakra z totalnym przerostem formy nad użytecznością.
Python nie ma tylu bibliotek ale piszesz w nim szybko. Wymusza czytelne 
rozwiązania (nigdy nie zgubiłem się w czyimś kodzie). Programy napisane 
w Pythonie są ekstremalnie stabilne. Jeśli programujesz  www to ma super 
obsługę utfa żaden inny język oprócz Javy nawet się nie zbliża.

Największą wadą węża jest słaby marketing.

-- 
Tomasz Drobiszewski

Artur Lew pisze:
> Bo siedzialem nad kodem w C++ ktory mial 1GB zrodel i problemem nie byly
> w nim null pointery (w praktyce jak nie kombinujesz to ciezko cos
> spieprzyc przekazujac referencje do obiektu). 

Mały off-topic bo aż mnie zatkało:  1GB czystego kodu w C++?
Człowiek jest w stanie to ogarnąć?  Kompilacja trwa kilka dni? :)
Co robił ten kod? Tzn. do czego służył ten cały program?
Z ciekawości pytam, nie chcę flamewara wywoływać :)


-- 
Pozdrowienia,
Jaytee
* It's 5:50am. do you know where your stack pointer is?

Jaytee wrote:
> Mały off-topic bo aż mnie zatkało:  1GB czystego kodu w C++?
Hmm to system rozwijany pewnie juz z 14-15 latek.
Ja sam siedzialem nad nim okolo lat 8 ;).
Na pewno nie ma co mowic o czystym kodzie bo bylo tam C i C++ ale tez
same np pliki rc. Ikonek bylo duzo ale zajmowaly tylko pare MB ;)
Inna sprawa ze mysle ze spokojnie moglbys wywalic polowe i dzialalby
dalej ;)
A kompilacja czesci stricte zwiazanej z sama aplikacja to pod VC6 jakies
4.5h na jakims szybkim p3-p4 a pod IncrediBuild jakies 15 minut w
obrebie kompow w pokoju ;)

> Człowiek jest w stanie to ogarnąć?  Kompilacja trwa kilka dni? :)
W sumie pracowalo nad tym (z bibliotekami) kilkadziesiat osob a
sumarycznie az trudno zliczyc autorow przez te lata :)

> Co robił ten kod? Tzn. do czego służył ten cały program?
To system medyczny.
Wiecej nie powinienem mowic ;)

Dodam tylko ze pare wiekszych refactoringow ;) robilem tamze wlasnie
przy uzyciu Pythona :)

A wracajac do rozmiaru projektu to wcale nie jest to jakis duzy
projekt bo powoli z Java i C# w nowych rzeczach dobijamy do 250MB po
paru latach kodowania.
Dlatego bardzo szanuje ladny i zwiezly styl kodowania z Pythona ;)

-- 
Pozdrawiam
Artur Lew
arturdotlewatgmaildotcom

Marcin Mielżyński wrote:
> Sebastian Kaliszewski pisze:
> 
>> A świstak siedzi... I kikukrotnie zawija.
>>
>> W praktycznej praktyce to zwykle Java jest wolniejsza i z rzadka jest 
>> (bardzo) nieznacznie szybsza. Przy czym, po części wynika to z 
>> ciężkiego object modelu platformy (jest to zatem problemem wszystkiego 
>> co na tej 
> 
> Ooo, a na czym to miałby polegać ten ciężki model ?

Zobacz, co tam w każdym obiekcie musi być. Od referncji do tablicy metod 
wirtualnych, po skojarzone z obiektem synchronizacjyjnym, itd. To się 
wyptymalizowuje jak się da, ale często się nie da.


>> platformie działa).
>>
>>> króry skazany jest tylko na to co potrafi zrobić (jednorazowo) jego 
>>> kompilator.
>>
>> Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega 
>> słyszał?
>>
> maszyny javy robią takie rzeczy których llvm jest przez dekadę nie 
> będzie robić.

Bo?

Maszyny Javy muszą robić rzeczy, których nie trzebaby w ogóle robić, 
gdyby object model JVM był lekki.

A kompilator Intela robi takie rzeczy, którch maszyny Javy przez dekadę 
nie będą robić. I nie musi się przy tym "rozgrzewać".


>> Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
> a jednak.
> 

A jednak nie.

> lopex

No i?


pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

Sebastian Kaliszewski pisze:
> Marcin Mielżyński wrote:
>> Sebastian Kaliszewski pisze:
>>
>>> A świstak siedzi... I kikukrotnie zawija.
>>>
>>> W praktycznej praktyce to zwykle Java jest wolniejsza i z rzadka jest 
>>> (bardzo) nieznacznie szybsza. Przy czym, po części wynika to z 
>>> ciężkiego object modelu platformy (jest to zatem problemem 
>>> wszystkiego co na tej 
>>
>> Ooo, a na czym to miałby polegać ten ciężki model ?
> 
> Zobacz, co tam w każdym obiekcie musi być. Od referncji do tablicy metod 
> wirtualnych, po skojarzone z obiektem synchronizacjyjnym, itd. To się 
> wyptymalizowuje jak się da, ale często się nie da.
> 
> 
Tablica metod wirtualnych jest w klasie. Obiekt to jest header (w środku 
flagi np: na mark&sweep, synchronizacja itp) plus wskaźnik na klasę 
(czyli obiekt javy jest o ten header cięższy od c++ - 2 słowa, biorąc 
pod uwagę alignment to jest to pic na wodę)

>>> platformie działa).
>>>
>>>> króry skazany jest tylko na to co potrafi zrobić (jednorazowo) jego 
>>>> kompilator.
>>>
>>> Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega 
>>> słyszał?
>>>
>> maszyny javy robią takie rzeczy których llvm jest przez dekadę nie 
>> będzie robić.
> 
> Bo?
Bo: http://wikis.sun.com/display/HotSpotInternals/
i bo: http://www.ssw.uni-linz.ac.at/Research/Papers/

> 
> Maszyny Javy muszą robić rzeczy, których nie trzebaby w ogóle robić, 
> gdyby object model JVM był lekki.
> 
> A kompilator Intela robi takie rzeczy, którch maszyny Javy przez dekadę 
> nie będą robić. I nie musi się przy tym "rozgrzewać".
> 
Maszyny wirtualne potrafią robić takie rzeczy których żaden kompilator 
C++ nigdy nie będzie mógł zrobić (np przeprowadzić gvn na zainlinowanej 
w ssa metodzie wirtualnej) czy zdewirtualizować metodę i dokonać pełnego 
inlinu bez strażników.

> 
>>> Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
>> a jednak.
>>
> 
> A jednak nie.
> 

Oj tak.

lopex

Marcin Mielżyński wrote:
>>>> A świstak siedzi... I kikukrotnie zawija.
>>>>
>>>> W praktycznej praktyce to zwykle Java jest wolniejsza i z rzadka 
>>>> jest (bardzo) nieznacznie szybsza. Przy czym, po części wynika to z 
>>>> ciężkiego object modelu platformy (jest to zatem problemem 
>>>> wszystkiego co na tej 
>>>
>>> Ooo, a na czym to miałby polegać ten ciężki model ?
>>
>> Zobacz, co tam w każdym obiekcie musi być. Od referncji do tablicy 
>> metod wirtualnych, po skojarzone z obiektem synchronizacjyjnym, itd. 
>> To się wyptymalizowuje jak się da, ale często się nie da.
>>
>>
> Tablica metod wirtualnych jest w klasie.

Przecież napisałem referencja do tablicy metod wirtualnych.

> Obiekt to jest header (w środku 
> flagi np: na mark&sweep, synchronizacja itp) plus wskaźnik na klasę 
> (czyli obiekt javy jest o ten header cięższy od c++ - 2 słowa, biorąc 
> pod uwagę alignment to jest to pic na wodę)

To właśnie jest dużo. Wiesz dlaczego odśmiecanie jest szybsze od 
zliczania raferencji? Bo nie ma licznika referencji. Wskaźniki są 2x 
mniejsze. A tu każdy najgłupszy obiekt ma dodatkowe 2 słowa "bo tak". To 
jest właśnie ciężki model. Toż to niektóre języki skryptowe mają ten 
model lżejszy.

W C++, Adzie, D i podobnych językach można mieć obiekty o rozmiarze 1B a 
nie 16B (przyjmując OS 64bit na którym chodzi to) i takie małe obiekty 
jak najbardziej się stosuje. W Javie byle zaboksowany Integer to 20B +4B 
na wyrównanie.


> 
>>>> platformie działa).
>>>>
>>>>> króry skazany jest tylko na to co potrafi zrobić (jednorazowo) jego 
>>>>> kompilator.
>>>>
>>>> Bzdura. O LLVM kolega słyszał? O profile guided optimisation kolega 
>>>> słyszał?
>>>>
>>> maszyny javy robią takie rzeczy których llvm jest przez dekadę nie 
>>> będzie robić.
>>
>> Bo?
> Bo: http://wikis.sun.com/display/HotSpotInternals/
> i bo: http://www.ssw.uni-linz.ac.at/Research/Papers/

No i?

>> Maszyny Javy muszą robić rzeczy, których nie trzebaby w ogóle robić, 
>> gdyby object model JVM był lekki.
>>
>> A kompilator Intela robi takie rzeczy, którch maszyny Javy przez 
>> dekadę nie będą robić. I nie musi się przy tym "rozgrzewać".
>>
> Maszyny wirtualne potrafią robić takie rzeczy których żaden kompilator 
> C++ nigdy nie będzie mógł zrobić

Nonsens. Jak już pokazałem, C++ (ani Ada) nie jest ograniczone ani 
teoretycznie ani praktycznie do statycznej kompilacji.

BTW. Zobacz co potrafi rzeczony kompilator...

> (np przeprowadzić gvn na zainlinowanej 
> w ssa metodzie wirtualnej) czy zdewirtualizować metodę i dokonać pełnego 
> inlinu bez strażników.

Tak tego zapewne robić nie będzie, bo w na pół sensownym kodzie w Adzie, 
C++ czy Object Pascalu taka metoda i tak nie będzie wirtualna. To jest 
właśnie obchodzenie optymalizatorem problemu, który gdzie indziej się 
nie pojawia.

Co do strażników to, po pierwsze, z samej natury kompilacja w runtime 
wymaga strażników i narzutów na profilowanie. Nie ma cudów.

>>>> Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
>>> a jednak.
>>
>> A jednak nie.
> 
> Oj tak.

Możesz napisac tak i 1000x ale rzeczywistości to nie zmieni. Java nie ma 
nic z assemblera. Assembler oznacza operacje niskopoziomowe (czyli 
dostęp do mechanizmów systemu operacyjnego oraz szczegółów procesora), 
tego w Javie absolutnie nie ma a dostęp do nich, gdy okażą się 
potrzebne, jest wyjątkowo upierdliwy.

pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

Sebastian Kaliszewski pisze:
> Marcin Mielżyński wrote:

>> Obiekt to jest header (w środku flagi np: na mark&sweep, 
>> synchronizacja itp) plus wskaźnik na klasę (czyli obiekt javy jest o 
>> ten header cięższy od c++ - 2 słowa, biorąc pod uwagę alignment to 
>> jest to pic na wodę)
> 
> To właśnie jest dużo. Wiesz dlaczego odśmiecanie jest szybsze od 

Jak na managed runtime to jest bardzo mało.
> zliczania raferencji? Bo nie ma licznika referencji. Wskaźniki są 2x 

Odśmiecanie jest szybkie bo algorytmy kompaktujące są szybkie
> mniejsze. A tu każdy najgłupszy obiekt ma dodatkowe 2 słowa "bo tak". To 
> jest właśnie ciężki model. Toż to niektóre języki skryptowe mają ten 
> model lżejszy.
> 
Ooo, jakie ?

> W C++, Adzie, D i podobnych językach można mieć obiekty o rozmiarze 1B a 
> nie 16B (przyjmując OS 64bit na którym chodzi to) i takie małe obiekty 
> jak najbardziej się stosuje. W Javie byle zaboksowany Integer to 20B +4B 
> na wyrównanie.
> 
tylko taki Integer jest natychmiast odśmiecany... (ale ok, przydały by 
się tagowane fixnumy na jvm)
> 
>>

>>> Maszyny Javy muszą robić rzeczy, których nie trzebaby w ogóle robić, 
>>> gdyby object model JVM był lekki.
>>>
>>> A kompilator Intela robi takie rzeczy, którch maszyny Javy przez 
>>> dekadę nie będą robić. I nie musi się przy tym "rozgrzewać".
>>>
>> Maszyny wirtualne potrafią robić takie rzeczy których żaden kompilator 
>> C++ nigdy nie będzie mógł zrobić
> 
> Nonsens. Jak już pokazałem, C++ (ani Ada) nie jest ograniczone ani 
> teoretycznie ani praktycznie do statycznej kompilacji.
> 
Ojoj, i odwrotnie (excelsior jet), a PGO nie załatwia wszystkiego
jet wypada naprawdę nieźle zresztą: http://www.stefankrause.net/wp/?p=6


> BTW. Zobacz co potrafi rzeczony kompilator...
> 
>> (np przeprowadzić gvn na zainlinowanej w ssa metodzie wirtualnej) czy 
>> zdewirtualizować metodę i dokonać pełnego inlinu bez strażników.
> 
> Tak tego zapewne robić nie będzie, bo w na pół sensownym kodzie w Adzie, 
> C++ czy Object Pascalu taka metoda i tak nie będzie wirtualna. To jest 
> właśnie obchodzenie optymalizatorem problemu, który gdzie indziej się 
> nie pojawia.
> 
> Co do strażników to, po pierwsze, z samej natury kompilacja w runtime 
> wymaga strażników i narzutów na profilowanie. Nie ma cudów.
> 
Ależ są! metoda deklarowana w c++ w projekcje jako wirtualna zostanie 
wirtualna (nawet jak alternatywna implementacja jest nigdy/rzadko 
używana - więc musi zostać wirtualna). Taki hotspot przeprowadzi analizę 
hierarchii i ją kompletnie zdewirtualizuje BEZ strażników (ba, zostanie 
nawet zainlinowana kompletnie i to już na poziomie ssa). Callsite 
zostanie zapamiętany i ewentualnie zwirtualizowany na hooku w ładowaniu 
klas (a odbywa się to bardzo leniwie)


>>>>> Java to nie współczesny assembler. Jak ktoś mądry napisał, większość 
>>>> a jednak.
>>>
>>> A jednak nie.
>>
>> Oj tak.
> 
> Możesz napisac tak i 1000x ale rzeczywistości to nie zmieni. Java nie ma 
> nic z assemblera. Assembler oznacza operacje niskopoziomowe (czyli 
> dostęp do mechanizmów systemu operacyjnego oraz szczegółów procesora), 
> tego w Javie absolutnie nie ma a dostęp do nich, gdy okażą się 
> potrzebne, jest wyjątkowo upierdliwy.
> 
Używałem różnych asemblerów i jakoś dalej się nie zgadzam (ale ok, 
jestem skrzywiony)

lopex