🚀 go-pugleaf

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.

Szybkie do napisania, modyfikacji ale mające dostęp do już napisanych
pakietów Javy.

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

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

Rob Wolfe pisze:

> 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

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

Dnia 26-06-2009 o 09:19:20 Rob Wolfe <rw@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.

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

"Jaroslaw Zabiello" <hipertracker@dzimail.dot.com> writes:

> Dnia 26-06-2009 o 09:19:20 Rob Wolfe <rw@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

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

Pozdrawiam :)
--
Jan Koprowski

Jan Koprowski pisze:
> 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

Dnia 26-06-2009 o 19:15:42 Rob Wolfe <rw@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).

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

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

Jaroslaw Zabiello napisał(a):
> Dnia 26-06-2009 o 19:15:42 Rob Wolfe <rw@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

On Mon, 29 Jun 2009 15:34:12 +0100, Rob Wolfe <rw@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. 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.


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

Do dyskusji na temat assemblera dorzucę swoje trzy grosze. Obaj
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

Marta Burzańska powiada:
> 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

Jaroslaw Zabiello powiada:

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

Dnia 01-07-2009 o 02:11:38 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
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?

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

On 30 Cze, 04:42, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> 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/

Jaroslaw Zabiello powiada:

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

Ciężko się odnieść do całości wątku, więc chciałem tylko sprostować:

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.

On Wed, 01 Jul 2009 16:54:33 +0100, Piotr Sawicki  
<ps171721@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ć.


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

On Wed, 01 Jul 2009 14:16:04 +0100, Filip Wasilewski  
<filipwasilewski@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.

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

On 1 Lip, 02:11, Piotr Sawicki <ps171...@students.mimuw.edu.pl> wrote:
> Marta Burzańska powiada:
>
> > 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


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

Jaroslaw Zabiello powiada:
>>>>> 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

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

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

Marta Burzańska powiada:

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

On Thu, 02 Jul 2009 13:31:33 +0100, Piotr Sawicki  
<ps171721@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.

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

Jaroslaw Zabiello powiada:

> 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

Dnia 03-07-2009 o 13:23:35 Piotr Sawicki <ps171721@students.mimuw.edu.pl>  
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)

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

Jaroslaw Zabiello powiada:

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

On 2 Lip, 17:12, Piotr Sawicki <ps171...@students.mimuw.edu.pl> wrote:
> Ł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

Łukasz powiada:

> 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

 

Łukasz powiada:

> 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