Jython
Krzysztof Stachlewski
Czy ma to sens jako j�zyk og�lnego przeznaczenia
w miejsce Javy, czy tylko ciekawostka?
Stach
--
http://stachlewski.info
Marek Wywiał
> Czy ktoś tu może aktywnie używa Jythona?
> Czy ma to sens jako język ogólnego przeznaczenia
Możliwe użycie to nie w miejsce Javy ale jako dodatek do Javy.
Np. bilbioteki, core napisane w javie + skrypty testujące napisane w
Jythonie.
Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
pakietów Javy.
Rob Wolfe
Marek Wywiał napisał(a):
> On 25 Cze, 22:31, Krzysztof Stachlewski <st...@fr.pl> wrote:
> > Czy ktoś tu może aktywnie używa Jythona?
> > Czy ma to sens jako język ogólnego przeznaczenia
> > w miejsce Javy, czy tylko ciekawostka?
> >
> > Stach
> > --http://stachlewski.info
>
> Możliwe użycie to nie w miejsce Javy ale jako dodatek do Javy.
> Np. bilbioteki, core napisane w javie + skrypty testujące napisane w
> Jythonie.
Dlaczego jako dodatek, a nie w miejsce Javy?
> Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
> pakietów Javy.
No wlasnie, wiec do czego nam ta nieszczesna Java?
RW
Rob Wolfe
Krzysztof Stachlewski napisał(a):
> Czy ktos tu moze aktywnie uzywa Jythona?
Uzywam jak najbardziej.
> Czy ma to sens jako jezyk ogolnego przeznaczenia
> w miejsce Javy, czy tylko ciekawostka?
Jedyne ograniczenia w wykorzystaniu Jythona tkwia
w mozgach managerow wypelnionych po brzegi stereotypami.
Ale czego sie spodziewac po ludziach, ktorzy kiedys wielbili COBOL-a.
Uzycie JVM moge zrozumiec, ale uzycia Javy jako jezyka nie jestem
w stanie pojac. Rzezbienie w tym to jest czysty masochizm.
JVM + Python do jest doskonala alternatywa.
RW
Krzysztof Stachlewski
> Jedyne ograniczenia w wykorzystaniu Jythona tkwia
> w mozgach managerow wypelnionych po brzegi stereotypami.
> Ale czego sie spodziewac po ludziach, ktorzy kiedys wielbili COBOL-a.
> Uzycie JVM moge zrozumiec, ale uzycia Javy jako jezyka nie jestem
> w stanie pojac. Rzezbienie w tym to jest czysty masochizm.
> JVM + Python do jest doskonala alternatywa.
A jak wygl�da wsprarcie do debugowania takiego kodu
w Jythonie?
Stach
--
http://stachlewski.info
Rob Wolfe
Krzysztof Stachlewski napisał(a):
> A jak wyglada wsprarcie do debugowania takiego kodu
> w Jythonie?
Jythonowy `pdb` dziala bez zarzutu (podobnie jak w CPythonie)
i wszelkie jego nakladki. Osobiscie uzywam emacsa, ale slyszalem,
ze eclipsowy pydev tez sobie radzi z Jythonem.
RW
Jaroslaw Zabiello
>> Możliwe użycie to nie w miejsce Javy ale jako dodatek do Javy.
>> Np. bilbioteki, core napisane w javie + skrypty testujące napisane w
>> Jythonie.
>
> Dlaczego jako dodatek, a nie w miejsce Javy?
Bo Jython nie zapewnia aż tak przezroczystej integracji z bibliotekami
Javy jak Scala czy Groovie. Np. jeśli byś chciał używać obiektowej bazy
danych db4o to możesz zapomnieć że sobie definicje modeli stworzysz w
Jythonie. Trzeba je tworzyć w Javie, można w Scali. W JRuby ani Jythonie
się nie da.
>> Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
>> pakietów Javy.
>
> No wlasnie, wiec do czego nam ta nieszczesna Java?
Java to tylko assembler to JVM. Jeśli potrzebna jest mocna integracja z
JVM to znacznie szybszym i bardziej przezroczystym rozwiązaniem będzie
Scala.
--
Jarosław Zabiełło
http://blog.zabiello.com
Rob Wolfe
> Dnia 26-06-2009 o 09:19:20 Rob Wolfe <r...@smsnet.pl> napisaďż˝(a):
>
>>> Mo�liwe u�ycie to nie w miejsce Javy ale jako dodatek do Javy.
>>> Np. bilbioteki, core napisane w javie + skrypty testuj�ce napisane w
>>> Jythonie.
>>
>> Dlaczego jako dodatek, a nie w miejsce Javy?
>
> Bo Jython nie zapewnia aďż˝ tak przezroczystej integracji z bibliotekami
> Javy jak Scala czy Groovie. Np. je�li by� chcia� u�ywa� obiektowej
> bazy danych db4o to mo�esz zapomnie� �e sobie definicje modeli
> stworzysz w Jythonie. Trzeba je tworzy� w Javie, mo�na w Scali. W
> JRuby ani Jythonie siďż˝ nie da.
R�wnie dobrze mo�na powiedzie�, �e jak jaki� RDBMS nie wspiera procedur
sk�adowanych pisanych w Pythonie, to ju� z poziomu Pythona lepiej
go nie u�ywa�.
Na �wiecie jest mn�stwo softu, kt�ry wymaga napisania czego� w C,
czegoďż˝ w TCL, czegoďż˝ w SQL i XML, a czegoďż˝ w Javie. To nie zmienia
faktu, �e core aplikacji mo�e by� spokojnie napisany w Pythonie
(czy to na JVM, czy na CPythonie).
>>> Szybkie do napisania, modyfikacji ale maj�ce dost�p do ju� napisanych
>>> pakiet�w Javy.
>>
>> No wlasnie, wiec do czego nam ta nieszczesna Java?
>
> Java to tylko assembler to JVM.
Assembler to by wygl�da� tak:
void meth1();
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 100
5: if_icmpge 14
8: iinc 1, 1
11: goto 2
14: return
Java nie ma nic wsp�lnego z assemblerem.
> Je�li potrzebna jest mocna integracja
> z JVM to znacznie szybszym i bardziej przezroczystym rozwi�zaniem
> b�dzie Scala.
Z tutoriala Scali zapad�y mi w pami�� stwierdzenia:
- mo�na przyj��, �e typ�w nie trzeba deklarowa�, no chyba �e kompilator
stwierdzi inaczej
- optymalizacja tail-call mo�e nast�pi�, ale nie musi, to zale�y jakiej
metody dotyczy.
Nie chc� powiedzie�, �e ten j�zyk jest jaki� specjalnie nieudany,
ale te� nie jest jaki� nadzwyczajny, a ju� na pewno nie zas�uguje,
aby go tak usilnie promowa� na grupie po�wi�conej Pythonowi.
RW
Jan Koprowski
Odpowiadając na Twoje pytanie. Używanie Jythona w naturalny sposób
wymaga często zaimportowania czegoś z Javy i skorzystania z jej
bibliotek. Jeżeli się z tym liczysz - ciesz się Jythonem i każdym
programem, który uda Ci się napisać wyłącznie w Jythonie :]
Pozdrawiam :)
--
Jan Koprowski
Krzysztof Stachlewski
> Krzysztofie
>
> Odpowiadaj�c na Twoje pytanie. U�ywanie Jythona w naturalny spos�b
> wymaga cz�sto zaimportowania czego� z Javy i skorzystania z jej
> bibliotek. Je�eli si� z tym liczysz - ciesz si� Jythonem i ka�dym
> programem, kt�ry uda Ci si� napisa� wy��cznie w Jythonie :]
Dzi�ki wszystkim za odpowiedzi.
Jak widz�, jest to niestety niszowe rozwi�zanie,
maj�ce si� og�lnie tak do Javy, jak CPython do j�zyka C.
Czyli dobre glue, kt�re nie ma wi�kszej popularno�ci.
Mo�e si� pobawi� przy okazji.
Stach
--
http://stachlewski.info
Jaroslaw Zabiello
>>> Dlaczego jako dodatek, a nie w miejsce Javy?
>>
>> Bo Jython nie zapewnia aż tak przezroczystej integracji z bibliotekami
>> Javy jak Scala czy Groovie. Np. jeśli byś chciał używać obiektowej
>> bazy danych db4o to możesz zapomnieć że sobie definicje modeli
>> stworzysz w Jythonie. Trzeba je tworzyć w Javie, można w Scali. W
>> JRuby ani Jythonie się nie da.
>
> Równie dobrze można powiedzieć, że jak jakiś RDBMS nie wspiera procedur
> składowanych pisanych w Pythonie, to już z poziomu Pythona lepiej
> go nie używać.
Dygresja i przykład zupełnie nie na temat. Nikt nie mówi czy używać, czy
nie, Jythona, ale czy Jython może w pełni zastąpić Javę. Otóż nie może.
Jython to tylko dodatek do JVM, nie potrafi tak przezroczyście się
integrować z bibliotekami Javy jak Scala. No i jest dużo wolniejszy (ale
to już inna kwestia).
>>>> Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
>>>> pakietów Javy.
>>>
>>> No wlasnie, wiec do czego nam ta nieszczesna Java?
>>
>> Java to tylko assembler to JVM.
>
> Assembler to by wyglądał tak:
>
> void meth1();
> Code:
> 0: iconst_0
> 1: istore_1
> 2: iload_1
> 3: bipush 100
> 5: if_icmpge 14
> 8: iinc 1, 1
> 11: goto 2
> 14: return
LOL! Co to ma być? Widzę że nie chwytasz. Specyfikacja JVM nie definiuje
żadnej specjalnej składni do swej asemblacji. SAMA JAVA służy za taki
język.
> Java nie ma nic wspólnego z assemblerem.
Ibidem. Doczytaj sobie o Jasmin i Jamaica.
>> Jeśli potrzebna jest mocna integracja
>> z JVM to znacznie szybszym i bardziej przezroczystym rozwiązaniem
>> będzie Scala.
>
> Z tutoriala Scali zapadły mi w pamięć stwierdzenia:
> - można przyjąć, że typów nie trzeba deklarować, no chyba że kompilator
> stwierdzi inaczej
> - optymalizacja tail-call może nastąpić, ale nie musi, to zależy jakiej
> metody dotyczy.
>
> Nie chcę powiedzieć, że ten język jest jakiś specjalnie nieudany,
A co ci się tu konkretnie nie podoba, nie rozumiemm. Scala (tak jak
Haskell) to język statycznie typowany z inteligentna inferencją typów.
Pisze się dużo krócej niż w Javie. Można czasem pisać nawet krócej niż w
Ruby i Pythonie. A czy Python w ogóle ma chociaż możliwość odpalania
rekursji ogonowej? (hehe, po polsku dziwnie brzmi)
> ale też nie jest jakiś nadzwyczajny, a już na pewno nie zasługuje,
> aby go tak usilnie promować na grupie poświęconej Pythonowi.
Nie chodzi o promocję. Dyskusja dotyczyła Javy i tego czy Jython może ją w
pełnio zastąpić. Otóż nie może. A Scala może. Tylko tyle.
Rob Wolfe
Jaroslaw Zabiello napisał(a):
> Dnia 26-06-2009 o 19:15:42 Rob Wolfe <r...@smsnet.pl> napisał(a):
>
> >>> Dlaczego jako dodatek, a nie w miejsce Javy?
> >>
> >> Bo Jython nie zapewnia aż tak przezroczystej integracji z bibliotekami
> >> Javy jak Scala czy Groovie. Np. jeśli byś chciał używać obiektowej
> >> bazy danych db4o to możesz zapomnieć że sobie definicje modeli
> >> stworzysz w Jythonie. Trzeba je tworzyć w Javie, można w Scali. W
> >> JRuby ani Jythonie się nie da.
> >
> > Równie dobrze można powiedzieć, że jak jakiś RDBMS nie wspiera procedur
> > składowanych pisanych w Pythonie, to już z poziomu Pythona lepiej
> > go nie używać.
>
> Dygresja i przykład zupełnie nie na temat. Nikt nie mówi czy używać, czy
> nie, Jythona, ale czy Jython może w pełni zastąpić Javę. Otóż nie może.
> Jython to tylko dodatek do JVM, nie potrafi tak przezroczyście się
> integrować z bibliotekami Javy jak Scala. No i jest dużo wolniejszy (ale
> to już inna kwestia).
Rownie na temat jak Twoj przyklad o tworzeniu modelu obiektowego
jakiejs
bazy. Jython moze zastapic Jave, bo mozna w nim tworzyc soft uzywajac
java'owych bibliotek (jesli jest taka potrzeba). Nikt nie musi w
Pythonie
tworzyc modeli obiektowych ani procedur skladowanych.
> >>>> Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
> >>>> pakietów Javy.
> >>>
> >>> No wlasnie, wiec do czego nam ta nieszczesna Java?
> >>
> >> Java to tylko assembler to JVM.
> >
> > Assembler to by wyglądał tak:
> >
> > void meth1();
> > Code:
> > 0: iconst_0
> > 1: istore_1
> > 2: iload_1
> > 3: bipush 100
> > 5: if_icmpge 14
> > 8: iinc 1, 1
> > 11: goto 2
> > 14: return
>
> LOL! Co to ma być? Widzę że nie chwytasz. Specyfikacja JVM nie definiuje
> żadnej specjalnej składni do swej asemblacji.
Nie ma formalnej skladni, ale nieformalny assembler istnieje
i nawet mozna java'owe klasy zdisassemblowac. Niby do czego mialyby
byc disassemblowane jak nie do assemblera?
Poczytaj:
http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javap.html
> SAMA JAVA służy za taki
> język.
Chyba nie rozumiesz pojecia assembler. Instrukcje assemblera powinny
odpowiadac bezposrednio instrukcjom maszyny wirtualnej.
Uwazasz, ze C++ to tez jest assembler?
> > Java nie ma nic wspólnego z assemblerem.
>
> Ibidem. Doczytaj sobie o Jasmin i Jamaica.
To sa wlasnie assemblery JVM. Co to ma wspolnego z Java?
Chwytasz roznice miedzy Java a JVM?
> >> Jeśli potrzebna jest mocna integracja
> >> z JVM to znacznie szybszym i bardziej przezroczystym rozwiązaniem
> >> będzie Scala.
> >
> > Z tutoriala Scali zapadły mi w pamięć stwierdzenia:
> > - można przyjąć, że typów nie trzeba deklarować, no chyba że kompilator
> > stwierdzi inaczej
> > - optymalizacja tail-call może nastąpić, ale nie musi, to zależy jakiej
> > metody dotyczy.
> >
> > Nie chcę powiedzieć, że ten język jest jakiś specjalnie nieudany,
>
> A co ci się tu konkretnie nie podoba, nie rozumiemm. Scala (tak jak
> Haskell) to język statycznie typowany z inteligentna inferencją typów.
Ta inteligencja jest nieco uposledzona i to mi sie nie podoba.
> Pisze się dużo krócej niż w Javie. Można czasem pisać nawet krócej niż w
> Ruby i Pythonie. A czy Python w ogóle ma chociaż możliwość odpalania
> rekursji ogonowej? (hehe, po polsku dziwnie brzmi)
Nie ma, ale to nie Python ma na sztandarach "funkcyjnosc" z "tail-
recursion".
> > ale też nie jest jakiś nadzwyczajny, a już na pewno nie zasługuje,
> > aby go tak usilnie promować na grupie poświęconej Pythonowi.
>
> Nie chodzi o promocję. Dyskusja dotyczyła Javy i tego czy Jython może ją w
> pełnio zastąpić. Otóż nie może. A Scala może. Tylko tyle.
Inaczej rozumiemy slowo "zastapic". Zadna implementacja Pythona nigdy
nie bedzie przezroczyscie kompatybilna z implementacja Javy i to chyba
jest dla wszystkich jasne. To sa w koncu zupelnie inne jezyki.
RW
Jaroslaw Zabiello
>> Dygresja i przykład zupełnie nie na temat. Nikt nie mówi czy używać, czy
>> nie, Jythona, ale czy Jython może w pełni zastąpić Javę. Otóż nie może.
>> Jython to tylko dodatek do JVM, nie potrafi tak przezroczyście się
>> integrować z bibliotekami Javy jak Scala. No i jest dużo wolniejszy (ale
>> to już inna kwestia).
>
> Rownie na temat jak Twoj przyklad o tworzeniu modelu obiektowego
> jakiejs. bazy. Jython moze zastapic Jave, bo mozna w nim tworzyc soft
> uzywajac
> java'owych bibliotek (jesli jest taka potrzeba). Nikt nie musi w
> Pythonie tworzyc modeli obiektowych ani procedur skladowanych.
Właśnie w tym rzecz, że to nie działa w obie strony. Tzn. klasy w Jythonie
nie mogą być tu użyte przez kod Javy. Innymi słowy, nie ma możliwości
uciec od używania języka Java i zastępianiu jej Jytonem przy pracy z
platformą Javy. Ten, kto tu używa Jythona MUSI też używać języka Javy. W
wypadku Scali tego problemu nie ma. Od początku do końca można pisać w
jednym języku i klasy Scali są rozumianie przez biblioteki Javy. Dlatego
Jython może być dodatkiem (nie mówię przecież że złym) ale nie może
zastąpić Javy. To moja odpowiedź na pytanie jakie padło w wątku: "skoro
mamy Jythona, to po co jeszcze nam język Java?"
>> > Java nie ma nic wspólnego z assemblerem.
>>
>> Ibidem. Doczytaj sobie o Jasmin i Jamaica.
>
> To sa wlasnie assemblery JVM. Co to ma wspolnego z Java?
A widziałeś składnię Jamaica? Toż to praktycznie składnia Javy!
>> A co ci się tu konkretnie nie podoba, nie rozumiemm. Scala (tak jak
>> Haskell) to język statycznie typowany z inteligentna inferencją typów.
>
> Ta inteligencja jest nieco uposledzona i to mi sie nie podoba.
W czym konkretnie upośledzona? Podasz po przykładzie dla Scali i Haskella?
>
>> Pisze się dużo krócej niż w Javie. Można czasem pisać nawet krócej niż w
>> Ruby i Pythonie. A czy Python w ogóle ma chociaż możliwość odpalania
>> rekursji ogonowej? (hehe, po polsku dziwnie brzmi)
>
> Nie ma, ale to nie Python ma na sztandarach "funkcyjnosc" z "tail-
> recursion".
Scala nie jest przecież językiem pure FP, ale hybrydowym, bo jest również
pure OOP. No i jest jeszcze silnie zintegrowana z JVM. Nie jest łatwo to
wszystko pogodzić, lecz wydaje mi się, że i tak udało im się to bardzo
dobrze.
Jak ktoś chce bardziej czysto funkcyjnego podejścia to jest jeszcze
Clojure. Co ciekawe, jest dynamicznie typowany, ale dużo szybszy od
Jythona i zdaje się że też przezroczyście (tak jak Scala) integruje się z
JVM.
>> Nie chodzi o promocję. Dyskusja dotyczyła Javy i tego czy Jython może
>> ją w pełnio zastąpić. Otóż nie może. A Scala może. Tylko tyle.
>
> Inaczej rozumiemy slowo "zastapic".
Problem został jasno postawiony: "po co nam więcej Java skoro jest
Jython"? Czyli chodziło o całkowite zastąpienie i pisanie wszystkiego
tylko w Jythonie. A tego się niestety nie da.
> Zadna implementacja Pythona nigdy
> nie bedzie przezroczyscie kompatybilna z implementacja Javy i to chyba
> jest dla wszystkich jasne. To sa w koncu zupelnie inne jezyki.
No i o to mi właśnie chodziło. Jednakże, z drugiej strony, Scala i Clojure
też są innymi językami, a mimo to potrafią się dużo bardziej
przezroczyście zintegrować z platformą Javy. Oczywiście, nie odbierz tego,
że krytykuję jakoś celowo Jythona. Mimo wszystko składnia Jythona, mimo że
nie tak elastyczna i potężna jak lispowy Clojure, to i tak jakoś wydaje mi
się czytelniejsza.
Marta Burzańska
Panowie macie rację, ale wydaje mi się że myślicie o różnych
znaczeniach słowa assembler. Może ono być rozumiane jako język
programowania Assembler. Wówczas porównanie z Javą jest delikatnie
mówiąc średnio na miejscu.
ALE: assembler może oznaczać język dokonujący asemblacji (assembly
language) - czyli meta-język służący do "tłumaczenia" programów na
rozkazy dla sprzętu. Brak mi wiedzy na temat jądra JVM by się
wypowiedzieć, czy Java jest dla Jythona językiem asemblującym. Z
drugiej strony przetrawiłam kod źródłowy Jythona i wydaje mi się to
bardzo prawdopodobne
Marta
Piotr Sawicki
> myślicie o różnych znaczeniach słowa assembler. Może ono być
> rozumiane jako język programowania Assembler. Wówczas porównanie
> z Javą jest delikatnie mówiąc średnio na miejscu.
> ALE: assembler może oznaczać język dokonujący asemblacji (assembly
> language) - czyli meta-język służący do "tłumaczenia" programów na
> rozkazy dla sprzętu.
Możesz wskazać gdzie spotkałaś się z takim znaczeniem określenia
assembly language? Albo - to dla mnie ciekawsze - z metajęzykiem
tłumaczącym źródło programu w jakimś języku na kod maszynowy?
Piotr Sawicki
Piotr Sawicki
>>> > Java nie ma nic wspólnego z assemblerem.
>>>
>>> Ibidem. Doczytaj sobie o Jasmin i Jamaica.
>>
>> To sa wlasnie assemblery JVM. Co to ma wspolnego z Java?
>
> A widziałeś składnię Jamaica? Toż to praktycznie składnia Javy!
Odwzorowanie między kodem w Jamaica a bajtkodem JVM jest (o ile
nie znajdzie się jakiś wyjątek) wzajemnie jednoznaczne. W Jamaice
pisze się instrukcjami JVM, tylko przez tekstowe mnemoniki zamiast
ciągu zer i jedynek. Translacja w obie strony jest zdeterminowana
z góry (z dokładnością do nieznaczących etykiet) i nawet idempotentna.
AFAIK żadnej z tych cech Java nie spełnia względem JVM.
>>> A co ci się tu konkretnie nie podoba, nie rozumiemm. Scala (tak jak
>>> Haskell) to język statycznie typowany z inteligentna inferencją typów.
>>
>> Ta inteligencja jest nieco uposledzona i to mi sie nie podoba.
>
> W czym konkretnie upośledzona? Podasz po przykładzie dla Scali i Haskella?
Np. Scala nie potrafi sama otypować argumentów funkcji.
BTW w inferowaniu typów nie ma nic inteligentnego, sam
algorytm jest prosty (skomplikowany jest za to system typów).
> Scala nie jest przecież językiem pure FP, ale hybrydowym,
> bo jest również pure OOP.
To nie ma sensu nawet czysto lingwistycznie/logicznie.
Albo nie jest, albo również jest. Mógłbyś rozjaśnić co
rozumiesz przez pure? Na przykład, czym dla Ciebie różni
się język pure-oop od języka po-prostu-oop? Albo język
czysto obiektowy od języka ze wsparciem dla obiektowości.
Czy da się określić relację bardziej czysty - mniej czysty?
Bo mam wrażenie, że uwzględniasz tylko jedną cechę,
mianowicie czy każdy typ danych jest obiektowy.
Piotr Sawicki
Jaroslaw Zabiello
napisał(a):
>> A widziałeś składnię Jamaica? Toż to praktycznie składnia Javy!
>
> Odwzorowanie między kodem w Jamaica a bajtkodem JVM jest (o ile
> nie znajdzie się jakiś wyjątek) wzajemnie jednoznaczne.
I wygląda jak składnia Javy, nieprawdaż? :)
Translacja w obie strony jest zdeterminowana
> z góry (z dokładnością do nieznaczących etykiet) i nawet idempotentna.
> AFAIK żadnej z tych cech Java nie spełnia względem JVM.
>>>> A co ci się tu konkretnie nie podoba, nie rozumiemm. Scala (tak jak
>>>> Haskell) to język statycznie typowany z inteligentna inferencją typów.
>>>
>>> Ta inteligencja jest nieco uposledzona i to mi sie nie podoba.
>>
>> W czym konkretnie upośledzona? Podasz po przykładzie dla Scali i
>> Haskella?
>
> Np. Scala nie potrafi sama otypować argumentów funkcji.
A jakiś język potrafi zgadywać intencje programisty? Znasz taki, co
potrafi zgadnąć jakiego typu ma być formalny parametr w metodzie
abstrakcyjnej? Przecież to niemożliwe.
> BTW w inferowaniu typów nie ma nic inteligentnego, sam
> algorytm jest prosty (skomplikowany jest za to system typów).
Inteligentnego w tym sensie, że na tym tle Javowy kompilator is dumb.
> Na przykład, czym dla Ciebie różni
> się język pure-oop od języka po-prostu-oop? Albo język
> czysto obiektowy od języka ze wsparciem dla obiektowości.
> Czy da się określić relację bardziej czysty - mniej czysty?
> Bo mam wrażenie, że uwzględniasz tylko jedną cechę,
> mianowicie czy każdy typ danych jest obiektowy.
Sam sobie więc odpowiedziałeś. :) W Scali każda wartość jest obiektem. W
Javie - nie. Także, z racji tego z każda funkcja jest wartością, to talże
każda funkcja jest w Scali też obiektem.
Z innych features które powodują, że ani Java ani PHP5 nie są pure OOP są
chociażby statyczne pola klas i metod. Po co statyczne pola/metody w jęz.
obiektowym? Scala nie ma ani metod ani pól statycznych, bo są
niepotrzebne. Za to ma klasy jako obiekty, singletony (zresztą Python też)
Jednakże, Python ma też metody statyczne w klasach. To jakaś niespójność.
Po co to? Metody te nie mają żadnego dostępu do bebechów swej klasy,
więcej, w żaden sposób nie są związane z klasą w której są zdefiniowane,
co one tam w ogóle robią? Chyba tylko jedno - klasa służy tu za dodatkową
przestrzeń nazw dla tych funkcji. Tylko po co to zamieszanie, skoro w
Pythonie przestrzenie nazw określa się za pomocą modułów?
Filip Wasilewski
> On Mon, 29 Jun 2009 15:34:12 +0100, Rob Wolfe <r...@smsnet.pl> wrote:
> >> Dygresja i przykład zupełnie nie na temat. Nikt nie mówi czy używać, czy
> >> nie, Jythona, ale czy Jython może w pełni zastąpić Javę. Otóż nie może.
> >> Jython to tylko dodatek do JVM, nie potrafi tak przezroczyście się
> >> integrować z bibliotekami Javy jak Scala. No i jest dużo wolniejszy (ale
> >> to już inna kwestia).
>
> > Rownie na temat jak Twoj przyklad o tworzeniu modelu obiektowego
> > jakiejs. bazy. Jython moze zastapic Jave, bo mozna w nim tworzyc soft
> > uzywajac
> > java'owych bibliotek (jesli jest taka potrzeba). Nikt nie musi w
> > Pythonie tworzyc modeli obiektowych ani procedur skladowanych.
>
> Właśnie w tym rzecz, że to nie działa w obie strony. Tzn. klasy w Jythonie
> nie mogą być tu użyte przez kod Javy. Innymi słowy, nie ma możliwości
> uciec od używania języka Java i zastępianiu jej Jytonem przy pracy z
> platformą Javy. Ten, kto tu używa Jythona MUSI też używać języka Javy.
Uściślając, w Jythonie można sobie skompilować klasę do pliku .class
[1, 2] bez znaczenia, czy implementuje ona servlet, aplet czy jeszcze
inny wynalazek. Wszystko bez ani jednej linijki w innym języku. Wciąż
nie widzę powodu, dlaczego nie można używać wyłącznie Jythona na JVM.
[1] http://jython.sourceforge.net/cgi-bin/faqw.py?req=show&file=faq06.001.htp
[2] Jython essentials, rozdział 13 - Compiling Jython (via google
books)
Filip Wasilewski
http://filipwasilewski.pl/
Piotr Sawicki
>>> A widziałeś składnię Jamaica? Toż to praktycznie składnia Javy!
>>
>> Odwzorowanie między kodem w Jamaica a bajtkodem JVM jest (o ile
>> nie znajdzie się jakiś wyjątek) wzajemnie jednoznaczne.
>
> I wygląda jak składnia Javy, nieprawdaż? :)
Podobieństwo kończy się przy klamrowaniu podziału na klasy
i metody, deklaracjach zmiennych i dość powszechnej w świecie
programowania operacji przyrównania. Zgadzają się oczywiście
biblioteczne identyfikatory (ale to w każdym języku platformy).
W gramatyce jest jednak elementarna różnica - brakuje zagnieżdżeń,
zarówno w wyrażeniach jak i instrukcjach. Algorytmy są budowane
diametralnie inaczej: same sekwencje nieobecnych w javie
prymitywów i skoków. To konkrety, bo ,,wygląda'' jest z definicji
subiektywne i nie da się dyskutować z tym jak co komu wygląda
bez wpadania w dygresje na temat Moneta czy Eschera. Dla mnie
na przykład, treści metod wyglądają mniej więcej tak jak to
kilka postingów temu antycypował przez Ciebie obśmiany Rob Wolfe.
>>> W czym konkretnie upośledzona? Podasz po przykładzie dla Scali i
>>> Haskella?
>>
>> Np. Scala nie potrafi sama otypować argumentów funkcji.
>
> A jakiś język potrafi zgadywać intencje programisty?
> Znasz taki, co potrafi zgadnąć jakiego typu ma być formalny
> parametr w metodzie abstrakcyjnej? Przecież to niemożliwe.
Jasne że możliwe - wystarczy, że system typów uwzględnia abstrakcję.
Ocaml czy Haskell jakoś potrafią same otypować argumenty funkcji bez
czytania w myślach programisty. Szczerze mówiąc, po zapewnieniach
o funkcyjności Scali sądziłem, że programowałeś kiedyś w jakimś
języku funkcyjnym (przecież samootypianie od razu rzuca w oczy).
>> BTW w inferowaniu typów nie ma nic inteligentnego, sam
>> algorytm jest prosty (skomplikowany jest za to system typów).
>
> Inteligentnego w tym sensie, że na tym tle Javowy kompilator is dumb.
To bardzo dziwny sens, bez związku z jakąkolwiek z kazyliona
wannabe-definicji inteligencji. Przeciwstawienie kompilatorowi
Javy jest o tyle nie na miejscu, że on za inferowanie typów
się w ogóle nie zabiera - ani sprytnie, ani głupio, tylko wcale.
Fakt że się coś w ogóle robi nie świadczy jeszcze o inteligencji.
>> Czy da się określić relację bardziej czysty - mniej czysty?
>> Bo mam wrażenie, że uwzględniasz tylko jedną cechę,
>> mianowicie czy każdy typ danych jest obiektowy.
>
> Sam sobie więc odpowiedziałeś. :)
> W Scali każda wartość jest obiektem. W Javie - nie.
Scala jest bardziej zorientowana na obiektowość niż Java,
nie przeczę. Jeśli jednak powiemy, że to już jest pure,
to jak nazwać języki jeszcze lepiej zOOPowane od Scali,
jak Smalltalk - że są ultra-pure z pierwszego tłoczenia?
> Z innych features które powodują, że ani Java ani PHP5 nie są
> pure OOP są chociażby statyczne pola klas i metod. Po co statyczne
> pola/metody w jęz. obiektowym? Scala nie ma ani metod ani pól
> statycznych, bo są niepotrzebne.
Skoro uznajesz falsyfikowanie pureOOPowości taką metodą
dowodzenia, to Smalltalk zadaje Scali coup de grace swoim
rozwiązaniem przepływu sterowania. Po co instrukcje if albo
while w języku obiektowym? Smalltalk nie ma żadnych wyróżnionych
komend sterujących, zupełnie wystarcza czysto obiektowy
polimorfizm hierarchiczny: wyrażenia warunkowe są obiektami
logicznymi, z których każdy ma swoje metody ifTrue i ifFalse
(a dla nich argumentami są obiekty-bloki kodu). Wygląda to
i działa tak samo jak klasyczny if, a likwiduje niespójność
i zbędne dodatkowe koncepcje dla języka. CBDO.
> Python ma też metody statyczne w klasach. To jakaś niespójność.
Zgoda - nikt przecież nie twierdzi, że Python jest pure OOP.
Piotr Sawicki
Łukasz
On 1 Lip, 17:54, Piotr Sawicki <ps171...@students.mimuw.edu.pl> wrote:
>>> BTW w inferowaniu typów nie ma nic inteligentnego, sam
>>> algorytm jest prosty (skomplikowany jest za to system typów).
>
>> Inteligentnego w tym sensie, że na tym tle Javowy kompilator is dumb.
>
> To bardzo dziwny sens, bez związku z jakąkolwiek z kazyliona
> wannabe-definicji inteligencji. Przeciwstawienie kompilatorowi
> Javy jest o tyle nie na miejscu, że on za inferowanie typów
> się w ogóle nie zabiera - ani sprytnie, ani głupio, tylko wcale.
> Fakt że się coś w ogóle robi nie świadczy jeszcze o inteligencji.
>
Niestety, wprowadzenie typów parametrycznych z wildcard'ami, dość
znacznie komplikuję analizę poprawności i wymaga inferencji niektórych
typów. Ogólnie kompilator Javy 1.5+ nie jest tak łopatologiczny jak by
się wydawało, bo nie przystaje ona już tak dokładnie do swojego
bytecode'u.
Jaroslaw Zabiello
<ps17...@students.mimuw.edu.pl> wrote:
>>>> W czym konkretnie upośledzona? Podasz po przykładzie dla Scali i
>>>> Haskella?
>>>
>>> Np. Scala nie potrafi sama otypować argumentów funkcji.
>>
>> A jakiś język potrafi zgadywać intencje programisty?
>> Znasz taki, co potrafi zgadnąć jakiego typu ma być formalny
>> parametr w metodzie abstrakcyjnej? Przecież to niemożliwe.
>
> Jasne że możliwe - wystarczy, że system typów uwzględnia abstrakcję.
> Ocaml czy Haskell jakoś potrafią same otypować argumenty funkcji bez
> czytania w myślach programisty.
A czy ja mówie o funkcji? Mówię o metodzie abstrakcyjnej. Niby jakim cudem
kompilator ma zgadnąć "co autor miał na myśli" jak taka metoda nie ma
jeszcze swej implementacji? Tego nawet (inny) człowiek nie wywnioskuje, a
co dopiero kompilator.
>>> BTW w inferowaniu typów nie ma nic inteligentnego, sam
>>> algorytm jest prosty (skomplikowany jest za to system typów).
>>
>> Inteligentnego w tym sensie, że na tym tle Javowy kompilator is dumb.
>
> Przeciwstawienie kompilatorowi Javy jest o tyle nie na miejscu,że on za
> inferowanie typów się w ogóle nie zabiera
I to jest głupie. Bo po co wklepywać masę bezsensownych deklaracji, skoro
kompilator powinien sam sobie logicznie je wywnioskować? Nie ma tej
logiki? Czyli jest dump.
> Fakt że się coś w ogóle robi nie świadczy jeszcze o inteligencji.
Ale fakt, że czegoś się NIE robi, i przez to ktoś inny (programista) musi
naharować się "jak wół", - świadczy. Może nie tyle o samym kompilatorze,
co o tym, który go takim zbudował.
> Scala jest bardziej zorientowana na obiektowość niż Java,
> nie przeczę. Jeśli jednak powiemy, że to już jest pure,
> to jak nazwać języki jeszcze lepiej zOOPowane od Scali,
> jak Smalltalk - że są ultra-pure z pierwszego tłoczenia?
W jakim sense bardziej? Smalltalk jest trochę inny. No i dużo starszy.
Scala jest nowocześniejsza. Np. ale też dzięki silnemu wsparciu dla FP
świetnie nadaje się do pracy na maszynach wielordzeniowych/procesorowych.
>> Z innych features które powodują, że ani Java ani PHP5 nie są
>> pure OOP są chociażby statyczne pola klas i metod. Po co statyczne
>> pola/metody w jęz. obiektowym? Scala nie ma ani metod ani pól
>> statycznych, bo są niepotrzebne.
>
> Skoro uznajesz falsyfikowanie pureOOPowości taką metodą
> dowodzenia, to Smalltalk zadaje Scali coup de grace swoim
> rozwiązaniem przepływu sterowania. Po co instrukcje if albo
> while w języku obiektowym?
A czemu nie? I co to ma wspólnego z OOP? Weźmy np. Clojure. Też nie ma
takich wyróżnionych struktur sterujących, a nie jest obiektowy. Innymi
słowy, nie widzę tu żadnej wyłączności dla OOP.
> Smalltalk nie ma żadnych wyróżnionych
> komend sterujących, zupełnie wystarcza czysto obiektowy
> polimorfizm hierarchiczny: wyrażenia warunkowe są obiektami
> logicznymi, z których każdy ma swoje metody ifTrue i ifFalse
> (a dla nich argumentami są obiekty-bloki kodu). Wygląda to
> i działa tak samo jak klasyczny if, a likwiduje niespójność
> i zbędne dodatkowe koncepcje dla języka. CBDO.
Operatory w Scali są metodami. Metody mogą mieć dowolną nazwę. Dzięki
możliwości opuszczania nawiasów i klamer, można tą droga definiować nowe
struktury sterowania. Jakoś nie widzę aby Smalltalk tu miał czym
poszpanować.
Jaroslaw Zabiello
<filipwa...@gmail.com> wrote:
> Uściślając, w Jythonie można sobie skompilować klasę do pliku .class
To za mało. Jython wrapuje tylko te klasy. To nie jest bezpośrednie
użycie klas Javy. Java nie może tak sobie użyć każdej klasy Jythona.
Clojure, co ciekawe - jest dynamicznie typowany - może. I na dodatek ma
szybkość prawie taką jak core Java. Jeśli ktoś szuka języka dynamicznie
typowanego z przezroczystą integracją z Javą, i największą wydajnością, to
Clojure jest bezkonkurencyjny.
Marta Burzańska
Hmm żadnych konkretnych źródeł nie podam. Z assembly language
spotkałam się jakieś 7 lat temu już, przy okazji uczenia się
assemblera. I chyba ktoś coś popełnił na wiki angielskiej ostatnio
(ale to mało wiarygodne źródło). A z metajęzykami spotykam się non
stop. Szczególnie w książkach o teorii konstrukcji języków
programowania. Przy czym zaznaczam że "tłumaczenie" nie jest
bezpośrednie - stąd wzięte w cudzysłowy
Marta
Piotr Sawicki
>>>>> W czym konkretnie upośledzona?
>>>>> Podasz po przykładzie dla Scali i Haskella?
>>>>
>>>> Np. Scala nie potrafi sama otypować argumentów funkcji.
>>>
>>> A jakiś język potrafi zgadywać intencje programisty?
>>> Znasz taki, co potrafi zgadnąć jakiego typu ma być formalny
>>> parametr w metodzie abstrakcyjnej? Przecież to niemożliwe.
>>
>> Jasne że możliwe - wystarczy, że system typów uwzględnia abstrakcję.
>> Ocaml czy Haskell jakoś potrafią same otypować argumenty funkcji bez
>> czytania w myślach programisty.
>
> A czy ja mówie o funkcji?
No właśnie Twój kontrargument nie odnosi się w ogóle do zarzutu.
Pytałeś o przykład upośledzenia inferencji typów w Scali, więc
podałem: nie zarzucam jej że nie umie otypiać argumentów deklaracji
metod abstrakcyjnych (bo to nikomu do niczego niepotrzebne), tylko
że nie umie otypiać argumentów żadnej definicji funkcji.
> Mówię o metodzie abstrakcyjnej. Niby jakim cudem kompilator
> ma zgadnąć "co autor miał na myśli" jak taka metoda nie ma
> jeszcze swej implementacji?
Po co miałby zgadywać, dla poprawności wystarczyłoby wstawienie
takiego typu kwantyfikowanego, który potem z każdą późniejszą
definicją treści metody będzie zgodny - skoro programista nie
chciał zawężać. Tylko po co, niech poda albo implementację albo
specyfikację, obwieszczanie samej nazwy jest niecelowe. Języki nie
zajmują się otypianiem gołych zapowiedzi przyszłych definicji
funkcji dlatego, że to bez sensu, a nie dlatego, że to niemożliwe.
>>> Inteligentnego w tym sensie, że na tym tle Javowy kompilator is dumb.
>>
>> Przeciwstawienie kompilatorowi Javy jest o tyle nie na miejscu,
>> że on za inferowanie typów się w ogóle nie zabiera
>
> I to jest głupie.
Jeśli nawet, to jest kwestia inteligencji projektantów
języka, a nie kompilatora (on tylko spełnia specyfikację).
O inteligencji projektantów Scali niestety niezbyt dobrze
świadczy nieudane wyważanie otwartych drzwi z systemem
typów Hindleya-Milnera sprzed ładnych parudziesięciu lat.
>> Scala jest bardziej zorientowana na obiektowość niż Java,
>> nie przeczę. Jeśli jednak powiemy, że to już jest pure,
>> to jak nazwać języki jeszcze lepiej zOOPowane od Scali,
>> jak Smalltalk - że są ultra-pure z pierwszego tłoczenia?
>
> W jakim sensie bardziej?
W takim, że zupełnie wszystko co się dzieje w programie jest
przesyłaniem komunikatów między obiektami. A w Scali nie.
>>> Z innych features które powodują, że ani Java ani PHP5 nie są
>>> pure OOP są chociażby statyczne pola klas i metod. Po co statyczne
>>> pola/metody w jęz. obiektowym? Scala nie ma ani metod ani pól
>>> statycznych, bo są niepotrzebne.
>>
>> Skoro uznajesz falsyfikowanie pureOOPowości taką metodą
>> dowodzenia, to Smalltalk zadaje Scali coup de grace swoim
>> rozwiązaniem przepływu sterowania. Po co instrukcje if albo
>> while w języku obiektowym?
>
> A czemu nie?
To samo można odpowiedzieć na pytanie po co statyczne pola/metody
w języku obiektowym - to Twój własny argument, zdecyduj się
czy taką metodę dowodzenia uznajesz czy nie. Niepotrzebne features
powodują brak czystości Javy i PHP5, więc czemu nie Scali?
> I co to ma wspólnego z OOP? Weźmy np. Clojure. Też nie ma
> takich wyróżnionych struktur sterujących, a nie jest obiektowy.
No z tego co wiem, to ma: if/cond. Ale w ogólności to w języku
funkcyjnym bez specjalnych instrukcji sterujących da się obyć,
wystarczy pattern matching (leniwość można łatwo zasymulować).
> Innymi słowy, nie widzę tu żadnej wyłączności dla OOP.
Bo tu nie chodzi o wyłączność, i dla sensowności argumentu nie
jest mi ona potrzebna. Struktury sterujące są charakterystyczne
dla programowania strukturalnego - nie są konieczne w pozostałych
paradygmatach programowania, czy to obiektowym czy funkcyjnym.
W szczególności wbudowanie w język 'while' łamie czystą funkcyjność.
>> Smalltalk nie ma żadnych wyróżnionych
>> komend sterujących, zupełnie wystarcza czysto obiektowy
>> polimorfizm hierarchiczny: wyrażenia warunkowe są obiektami
>> logicznymi, z których każdy ma swoje metody ifTrue i ifFalse
>> (a dla nich argumentami są obiekty-bloki kodu). Wygląda to
>> i działa tak samo jak klasyczny if, a likwiduje niespójność
>> i zbędne dodatkowe koncepcje dla języka. CBDO.
>
> Operatory w Scali są metodami. Metody mogą mieć dowolną nazwę.
> Dzięki możliwości opuszczania nawiasów i klamer, można tą droga
> definiować nowe struktury sterowania.
Fajnie, tylko nie da się uniknąć wykorzystania starych.
Potrafisz w Scali tak zdefiniować własne JEZELI, żeby
jego implementacja nie korzystała z if ani while,
a tylko i wyłącznie z wołania nierozgałęzionych metod?
> Jakoś nie widzę aby Smalltalk tu miał czym poszpanować.
Obywa się bez żadnych zapożyczeń z programowania strukturalnego.
Piotr Sawicki
Piotr Sawicki
>> Przeciwstawienie kompilatorowi
>> Javy jest o tyle nie na miejscu, że on za inferowanie typów
>> się w ogóle nie zabiera - ani sprytnie, ani głupio, tylko wcale.
>> Fakt że się coś w ogóle robi nie świadczy jeszcze o inteligencji.
>>
>
> Niestety, wprowadzenie typów parametrycznych z wildcard'ami,
> dość znacznie komplikuję analizę poprawności i wymaga
> inferencji niektórych typów.
Nie zgodzę się - z tego co wiem to wymaga tylko dopasowywania
konkretyzowanego typu między argumentami a wynikiem, co zresztą
z powodu metod polimorficznych ma miejsce dopiero w trakcie
runtime. Przez inferencję typów mam natomiast na myśli statyczne
wnioskowanie opuszczonego przez programistę otypowania.
Przykład: w takim choćby sml wystarczy napisać treść funkcji
odwracającej dowolną listę (bez zaglądania do środka elementów)
i nie trzeba dopisywać jaki jest typ argumentów i wyniku funkcji
odwracającej. Kompilator sam się domyśli, że argumentem jest
lista czegokolwiek, a wynikiem lista tego samego co w argumencie.
I to mu wystarcza do wykrywania błędów, sprawdzenia poprawności
wywołań tej funkcji i wygenerowania zoptymalizowanego kodu
(w sensie: szybkość jest niemal taka, jakby to wyrzeźbić ręcznie
w asemblerze lub wyklepać w C z hektarem castów na void*).
W Javie z wildcardami też się da napisać funkcję odwracającą listę
czegokolwiek - tylko najpierw trzeba z góry zadeklarować, że typem
wyniku i argumentu jest List<?> - kompilator tego wcale sam nie
wyinferuje. Przeciwnie, wymaże połowę wpisanego przez programistę
typu, a potem w czasie działania program będzie się ciągle wozić
z zaśmiecającymi pamięć niekompletnymi tagami typów, tak jakby
kontroli typów nie można było zrobić statycznie, przy kompilacji,
i zapomnieć o temacie. Jakoś to niby działa, ale chyba głównie
w charakterze pomniku zwycięstwa techniki nad zdrowym rozsądkiem.
Piotr Sawicki
Piotr Sawicki
>> > myślicie o różnych znaczeniach słowa assembler. Może ono być
>> > rozumiane jako język programowania Assembler. Wówczas porównanie
>> > z Javą jest delikatnie mówiąc średnio na miejscu.
>> > ALE: assembler może oznaczać język dokonujący asemblacji (assembly
>> > language) - czyli meta-język służący do "tłumaczenia" programów na
>> > rozkazy dla sprzętu.
>>
>> Możesz wskazać gdzie spotkałaś się z takim znaczeniem określenia
>> assembly language? Albo - to dla mnie ciekawsze - z metajęzykiem
>> tłumaczącym źródło programu w jakimś języku na kod maszynowy?
>
> Hmm żadnych konkretnych źródeł nie podam. Z assembly language
> spotkałam się jakieś 7 lat temu już, przy okazji uczenia się
> assemblera. I chyba ktoś coś popełnił na wiki angielskiej ostatnio
> (ale to mało wiarygodne źródło).
Chyba pokręciłaś: assembly language ma jedno ustalone znaczenie,
dwuznaczność ma miejsce przy określeniu asembler. Ściśle rzecz
biorąc, powinno oznaczać narzędzie do transformowania źródła
w assembly language na wynikowy program w kodzie maszynowym
- ale potocznie używa się również słowa asembler w sensie
assembly language (i o to ewidentnie chodziło obu dyskutantom).
> A z metajęzykami spotykam się non stop. Szczególnie
> w książkach o teorii konstrukcji języków programowania.
> Przy czym zaznaczam że "tłumaczenie" nie jest bezpośrednie
> - stąd wzięte w cudzysłowy
Mam wrażenie że masz na myśli gramatykę translacyjną, albo
może semantykę operacyjną. Mniejsza o określenie metajęzyk
i bezpośredniość tłumaczenia (nie czas na formalną poprawność
gdy płoną flejmy) - ale z nazywaniem tego ,,assembly language''
nie spotkałem się w żadnej książce czy publikacji na ten temat.
Piotr Sawicki
Jaroslaw Zabiello
<ps17...@students.mimuw.edu.pl> wrote:
Wróćmy do twojego głównego zarzutu wobec Scali
> Scala nie potrafi sama otypować argumentów funkcji.
oraz
> O inteligencji projektantów Scali niestety niezbyt dobrze
> świadczy nieudane wyważanie otwartych drzwi z systemem
> typów Hindleya-Milnera sprzed ładnych parudziesięciu lat.
Nie wiem o czyjej inteligencji co świadczy, jednak wiem, że nie rozumiesz
w ogóle tego, czym jest Scala. Otóż twój zarzut można by sprowadzić do
"Scala jest kiepska, bo nie jest jak typowy FP". Śmieszne, prawda? Równie
dobrze można przecież powiedzieć odwrotnie.
To, że Scala nie ma H&P, nie ma nic wspólnego z ułomnością implementacji
inferencji typów (twój zarzut). Scala to nie FP, to hybryda* FP z OOP.
Stosowanie H&P jest niemożliwe z powodu posiadanych przez Scalę metod
wirtualnych. Stąd Haskell ma H&M, a Scala ma flow inferencing.
Np. weź operację a + b. Nawet jeśli znasz typ obu operandów, to jednak
niekoniecznie wiesz jaka jest implementacja + (bo Scala pozwala na
przesłonięcie metody + w klasie potomnej). Sprawa rozbija się więc o late
binding i metody wirtualne, których nie ma w językach FP.
Zatem, Twój zarzut jest niesłuszny, bo opiera się na niezrozumieniu tego,
że Scala to język hybrydowy, a nie FP.
Piotr Sawicki
> Nie wiem o czyjej inteligencji co świadczy, jednak wiem, że nie rozumiesz
> w ogóle tego, czym jest Scala. Otóż twój zarzut można by sprowadzić do
> "Scala jest kiepska, bo nie jest jak typowy FP". Śmieszne, prawda?
Taka teza niestety nie ma związku z kontekstem, który Starannie Wyciąłeś.
Zachwalane przez Ciebie inteligentne inferowanie sprytnych typów w bystrej
Scali ktoś skomentował jako upośledzone - na co zażądałeś przykładu (dziwiąc
się, co w ogóle może nie się podobać). Kiedy podałem przykład czego Scala
wyinferować nie potrafi, twierdziłeś że żaden język czegoś takiego nie umie,
bo się w ogóle nie da. Nie będę teraz wcale twierdził, że to świadczy
o inteligencji - natomiast nie obraź się, ale spieranie się o czystą
obiektowość albo funkcyjność jakiegoś języka uważam za odrobinę niepoważne,
jeśli nigdy wcześniej się nie programowało w takiego rodzaju czystym języku.
> To, że Scala nie ma H&P, nie ma nic wspólnego z ułomnością implementacji
> inferencji typów (twój zarzut). Scala to nie FP, to hybryda* FP z OOP.
> Stosowanie H&P jest niemożliwe z powodu posiadanych przez Scalę metod
> wirtualnych.
Interesująca teoria - jednak OCaml też jest hybrydą FP z OOP, posiada
metody wirtualne, i jakoś nie przeszkadza mu to w otypianiu funkcji.
Takoż projektanci F# potrafili rozszerzyć system typów H-M w sposób
łączący inferencję typów z istnieniem na platformie metod wirtualnych.
> Zatem, Twój zarzut jest niesłuszny, bo opiera się na niezrozumieniu
> tego, że Scala to język hybrydowy, a nie FP.
To nie ja twierdziłem, że Scala jest jednocześnie pure FP i pure OOP.
Skoro już się zgadzamy, że jest nie do końca spójnym zlepkiem
zapożyczeń w charakterze Javy++, to nie widzę pola do dalszego sporu.
Piotr Sawicki
Jaroslaw Zabiello
napisał(a):
>> To, że Scala nie ma H&P, nie ma nic wspólnego z ułomnością implementacji
>> inferencji typów (twój zarzut). Scala to nie FP, to hybryda* FP z OOP.
>> Stosowanie H&P jest niemożliwe z powodu posiadanych przez Scalę metod
>> wirtualnych.
>
> Interesująca teoria - jednak OCaml też jest hybrydą FP z OOP, posiada
> metody wirtualne, i jakoś nie przeszkadza mu to w otypianiu funkcji.
To nie to samo. Tam virtual to takie abstract. I generalnie NIE mogą mieć
wiele wersji.
>> Zatem, Twój zarzut jest niesłuszny, bo opiera się na niezrozumieniu
>> tego, że Scala to język hybrydowy, a nie FP.
>
> To nie ja twierdziłem, że Scala jest jednocześnie pure FP i pure OOP.
Przecież nie twierdzę, że jest pure FP. Scala jest FP + pure OOP.
"Pojęcie "czysto obiektowy" oznacza, że każda wartość, każda struktura
danych jest obiektem i nie istnieje sztuczne rozgraniczenie wartości i
obiektów." (za Wikipedia n/t Smalltalka)
Piotr Sawicki
>> Interesująca teoria - jednak OCaml też jest hybrydą FP z OOP, posiada
>> metody wirtualne, i jakoś nie przeszkadza mu to w otypianiu funkcji.
>
> To nie to samo. Tam virtual to takie abstract.
Samo słówko kluczowe virtual - zgadza się.
> I generalnie NIE mogą mieć wiele wersji.
Nie wiem co masz właściwie na myśli. Właśnie sobie włączyłem ocamla,
stworzyłem kilka podklas z metodami o tej samej nazwie a różnej
implementacji - zachowują się polimorficznie, jak przystało na
oopowe metody wirtualne. Czego się konkretnie nie da?
> Przecież nie twierdzę, że jest pure FP. Scala jest FP + pure OOP.
>
> "Pojęcie "czysto obiektowy" oznacza, że każda wartość, każda struktura
> danych jest obiektem i nie istnieje sztuczne rozgraniczenie wartości i
> obiektów." (za Wikipedia n/t Smalltalka)
Luka w tym rozumowaniu jest taka, że za wartości uważasz tylko
struktury danych - a jak już ograniczymy pojęcie wartości, to wtedy
rzeczywiście można się upierać że każda taka wartość jest obiektem
(fakt że Java nie ma nawet tego). Zaraz za zacytowanym fragmentem
z wikipedii znajduje się doprecyzowanie, że wartością może być
wszystko z czym mamy do czynienia w języku - np. klasa jest też
wartością, która jest obiektem klasy metaklasa. W Smalltalku czego
się nie dotkniesz, jest obiektem jakiejś klasy: bloki kodu, pola
obiektów, wyrażenia, symbole denotujące komunikaty, ify, błędy itd.
To jest trochę creepy, i nie uważam wcale że w Scali wszystkie
koncepcje semantyczne powinny być sprowadzone do wspólnego mianownika
wszechobecnej obiektowości - tylko nie wiem po co chcesz komuś
obrzydzać Scalę twierdząc że jest pure, ona ma wystarczająco wiele
rzeczywistych słabości (np. jest trochę przegadana jak dla mnie).
Piotr Sawicki
Łukasz
> Łukasz powiada:
>
> >> Przeciwstawienie kompilatorowi
> >> Javy jest o tyle nie na miejscu, że on za inferowanie typów
> >> się w ogóle nie zabiera - ani sprytnie, ani głupio, tylko wcale.
> >> Fakt że się coś w ogóle robi nie świadczy jeszcze o inteligencji.
>
> > Niestety, wprowadzenie typów parametrycznych z wildcard'ami,
> > dość znacznie komplikuję analizę poprawności i wymaga
> > inferencji niektórych typów.
>
> Nie zgodzę się - z tego co wiem to wymaga tylko dopasowywania
> konkretyzowanego typu między argumentami a wynikiem, co zresztą
> z powodu metod polimorficznych ma miejsce dopiero w trakcie
> runtime. Przez inferencję typów mam natomiast na myśli statyczne
> wnioskowanie opuszczonego przez programistę otypowania.
Nie, to tak nie działa - w runtime, wszystko ma już swój konkretny
typ.
>
> Przykład: w takim choćby sml wystarczy napisać treść funkcji
> odwracającej dowolną listę (bez zaglądania do środka elementów)
> i nie trzeba dopisywać jaki jest typ argumentów i wyniku funkcji
> odwracającej. Kompilator sam się domyśli, że argumentem jest
> lista czegokolwiek, a wynikiem lista tego samego co w argumencie.
> I to mu wystarcza do wykrywania błędów, sprawdzenia poprawności
> wywołań tej funkcji i wygenerowania zoptymalizowanego kodu
> (w sensie: szybkość jest niemal taka, jakby to wyrzeźbić ręcznie
> w asemblerze lub wyklepać w C z hektarem castów na void*).
Tak, wiem co to jest inferencja typów. W życiu bym nie użył określenia
"domyślił", bo kompilatory nie myślą tylko "wnioskują" korzystając z
reguł wnioskowania konkretnego systemu typów.
>
> W Javie z wildcardami też się da napisać funkcję odwracającą listę
> czegokolwiek - tylko najpierw trzeba z góry zadeklarować, że typem
> wyniku i argumentu jest List<?> - kompilator tego wcale sam nie
> wyinferuje. Przeciwnie, wymaże połowę wpisanego przez programistę
> typu, a potem w czasie działania program będzie się ciągle wozić
> z zaśmiecającymi pamięć niekompletnymi tagami typów, tak jakby
> kontroli typów nie można było zrobić statycznie, przy kompilacji,
> i zapomnieć o temacie. Jakoś to niby działa, ale chyba głównie
> w charakterze pomniku zwycięstwa techniki nad zdrowym rozsądkiem.
Raczej "<T> List<T> odwroc(List<T>)" jest lepszy, przyblizeniem, tego
co wywnioskuje sml, ale spoko. W trakcie działania wszystkie typy są
już kompletne. Cały typechecking jest robiony podczas kompilacji. Nie
ma tam takiej inferencji o której myślisz, ale jest wnioskowanie na
temat typów konkretnych metod na podstawie typów parametrycznych
innych typów, itd. Po sprawdzeniu poprawności wszystkie wildcardy i
typy parametryczne, są zastępowane przez "upper bound type" - w
skrócie robiona jest translacja homogeniczna, która jest stosowana nie
tylko w Javie.
>
> Piotr Sawicki
Piotr Sawicki
> Nie, to tak nie działa - w runtime,
> wszystko ma już swój konkretny typ.
Widocznie nie nadążam za zmianami w Javie, skończyli z type erasure?
> Tak, wiem co to jest inferencja typów.
Sorry, uściślałem bo w tekstach o javie można się spotkać
z użyciem takiego terminu do zupełnie innego zachowania kompilatora.
> W życiu bym nie użył określenia "domyślił", bo kompilatory
> nie myślą tylko "wnioskują" korzystając z reguł wnioskowania
> konkretnego systemu typów.
To masz dziwne imho uprzedzenia, domyślanie się nie ma ścisłej
definicji której możnaby wykazać sprzeczność z wywnioskowywaniem
- jak dla mnie znaczenia tych słów mają wystarczająco dużo wspólnego
pola semantycznego żeby móc ich swobodnie używać w dyskusji.
> Raczej "<T> List<T> odwroc(List<T>)" jest lepszym przyblizeniem,
> tego co wywnioskuje sml, ale spoko.
Racja, nadmiernie poskracałem bardziej skomplikowany przykład
z boundowanymi wildcardami i haskellowymi klasami typów.
> W trakcie działania wszystkie typy są już kompletne.
> Cały typechecking jest robiony podczas kompilacji.
I nie wkompilowuje już bajtkodów checkcast, instanceof
ani invokeinterface? To ciekaw jestem jak rozwiązano w końcu
sprawdzanie rzuconych wyjątków albo obiektów wkładanych do tablicy.
> Nie ma tam takiej inferencji o której myślisz, ale jest
> wnioskowanie na temat typów konkretnych metod na podstawie
> typów parametrycznych innych typów, itd.
To jest właśnie mój punkt - takiej inferencji o jakiej była
mowa to w javie nie ma. W środku kompilatora czasami są jakieś
wnioskowania o typach, ale dla programisty z tego niewiela wynika.
> w skrócie robiona jest translacja homogeniczna,
> która jest stosowana nie tylko w Javie.
Pierwszy raz spotykam się z takim terminem, a gugiel
go nie znajduje - możesz przybliżyć?
Piotr Sawicki
Piotr Sawicki
> Nie, to tak nie działa - w runtime,
> wszystko ma już swój konkretny typ.
Widocznie nie nadążam za zmianami w Javie, skończyli z type erasure?
> Tak, wiem co to jest inferencja typów.
Sorry, uściślałem bo w tekstach o javie można się spotkać
z użyciem takiego terminu do zupełnie innego zachowania kompilatora.
> W życiu bym nie użył określenia "domyślił", bo kompilatory
> nie myślą tylko "wnioskują" korzystając z reguł wnioskowania
> konkretnego systemu typów.
To masz dziwne imho uprzedzenia, domyślanie się nie ma ścisłej
definicji której możnaby wykazać sprzeczność z wywnioskowywaniem
- jak dla mnie znaczenia tych słów mają wystarczająco dużo wspólnego
pola semantycznego żeby móc ich swobodnie używać w dyskusji.
> Raczej "<T> List<T> odwroc(List<T>)" jest lepszym przyblizeniem,
> tego co wywnioskuje sml, ale spoko.
Racja, nadmiernie poskracałem bardziej skomplikowany przykład
z boundowanymi wildcardami i haskellowymi klasami typów.
> W trakcie działania wszystkie typy są już kompletne.
> Cały typechecking jest robiony podczas kompilacji.
I nie wkompilowuje już bajtkodów checkcast, instanceof
ani invokeinterface? To ciekaw jestem jak rozwiązano w końcu
sprawdzanie rzuconych wyjątków albo obiektów wkładanych do tablicy.
> Nie ma tam takiej inferencji o której myślisz, ale jest
> wnioskowanie na temat typów konkretnych metod na podstawie
> typów parametrycznych innych typów, itd.
To jest właśnie mój punkt - takiej inferencji o jakiej była
mowa to w javie nie ma. W środku kompilatora czasami są jakieś
wnioskowania o typach, ale dla programisty z tego niewiela wynika.
> w skrócie robiona jest translacja homogeniczna,
> która jest stosowana nie tylko w Javie.
Nie bardzo widzę co chcesz sprostować: napisałem że część
informacji o typie znika, oraz że w trakcie działania programu
maszyna żongluje tagami typów. Nie zgadza się?
Piotr Sawicki