[nem-pl] nawiasy

[Kamil Skalski]

Thursday 12 of February 2004 19:37, Lukasz Kaiser wrote:

> IMHO list 'a jest znacznie lepsze od list<a>. Nie mowie ze list<'a> ma
> sens. Mozliwe argumenty to to ze nawiasy () sa naturalne i uzywane w szkole

No rzeczywiście, obiektywnie rzecz biorąc to jest ładniejsze... może nawet 
wygodniejsze, choć być może tu można zastosować ten sam agument co 
f x y vs. f(x, y). 
Niestety nie możemy być obiektywni... bo <> staje się standardem takim, jak 
słowo kluczowe "class" (na szczęście ci od Scali tego nie wiedzą i mają 
jakieś "trait" zamiast "interface" hehe)

Jeśli chodzi o target audience, to jest trudne pytanie i myślę, że już od pół 
roku nie potrafimy sobie na nie odpowiedzieć. Ja chciałbym myśleć w ten 
sposób o popularności języków w tej chwili:
C++, Java
C# (tak Pawle, Java na razie chyba bije C#, a może i C++)
... (długo nic)
OCaml
... (przez pewien czas nic)
SML
... (trochę dłużej nic)
Haskell

i chciałbym też myśleć, że trafimy gdzieś (najlepiej na górę) tego "długo nic"

> i znane od dziecka a zatem bardziej czytelne, popatrz tez na nesting:
> list<a, list<b,tree<a>>> vs. list 'a * list ('b * tree 'a).

O nie Łukaszu, takich oszustewek to na tej liście nie przemycisz:
list<a> * list<b * tree<a>> vs. list 'a * list ('b * tree 'a).
i to już nie wygląda tak źle.
Po drugie widzę, że sam dostarczyłeś mi ŚWIETNEGO argumentu przeciwko sobie:
list 'a * list ('b * tree 'a) wygląda  mniej jednoznacznie - sam popełniłeś 
byka, bo przekonwertowałeś to do czegoś co wg ciebie powinno znaczyć
list ('a * list ('b * tree 'a))
bo list ('a * list ('b * tree 'a)) i list ('a) * (list ('b * tree 'a)) to 
spora różnica :)


> Nie jest bardziej precyzyjne semantycznie, bo obie konstrukcje sa rownie
> precyzyjne, czyli po prostu precyzyjne. Jesli chodzi o odroznianie sie to
> <> nie odroznia sie od operatora "<>", ale to nie ma wielkiego znaczenia
> podobnie jak odroznianie sie () od wywolan funkcji, bo stoja w innych
> miejscach. Poza tym ja optuje za zniesieniem nawiasow w ogole, co bedzie
> sie zasadniczo odrozniac. Dodatkowo chodzi tez o odroznianie zmiennych,
> czyli foo ( a : int, y : tree<a>, b : a ) : int .

Masz na pewno dużo racji. Ale jakąś decyzję musieliśmy podjąć i wydaje nam się 
(i częściowo wynika z argumentów poruszonych w kontekscie), że tak ja robimy 
jest lepiej.

Z tymi nazwami to ja też się zastanawiałem
class A { }
class B<A> {...}
ale to są patologiczne przypadki

>
> Ale wracajac do sprawy kazania komus cos robic w pracy, myslisz ze mu kaza
> pisac w Nemerle ? No a dla zabawy to czy bedzie pisal w jezyku tak podobnym
> do tego z pracy ?

Wiesz, to była analogia do tego, że jeśli ktoś nie wie co to list<a> lub 
ucieka na widok tego napisu, to jest co najmniej dziwny... Wybacz, ale IMHO 
praca i pisanie w niej w jakimś języku nie powoduje znienawidzenia składni 
tego języka, a jedynie lepsze oswojenie się z nim. Jeśli masz inne 
doświadczenia, to może się nimi podzielisz? ;-)

> Hmm, widze ze liczysz na znajomosci Pawla w M$R. Nie znam sie na tym, ale
> chyba ludzie od C# dzialaja troszke inaczej niz ci od Javy, poza tym nie
> sadze zeby M$ uzyl twojego kodu ani twojej skladni, ale sie na tym zupelnie
> nie znam, moze Pawel cos wie. Ale tak ogolnie - jesli chcesz zrobic jezyk
> ktory bedzie od razu uzywany komercyjnie bez pewnej fazy przejsciowej, w
> ktorej jest jezykiem uniwersyteckim, to musisz miec silne przekonanie o
> swoich wplywach komercyjnych. Natomiast jezyk uniwersytecki byc moze kiedys
> moze sie stac komercyjnie uzywany, chociaz oczywiscie nie jest to pewne
> (zobaczymy, jak bedzie z OCamlem), no i pewnie potrzeba na to lat. Moze
> warto sie zastanowic jaka jest docelowa grupa uzytkownikow Nemerle na
> poczatek ? No i prosze, nie pisz ze to beda programisci C# w ich pracy,
> przynajmniej dopoki nie masz zadnej metody dotarcia do nich.

:D

We shall rule the world. I dopóki tak myślimy to jest sens cokolwiek robić. 
Im wyżej stawiamy sobie poprzeczkę i im szerszą zakładamy publikę (do pewnego 
stopnia, do którego nie spowoduje to dodawanie durnych elementów, 
uzasadnionych tylko i wyłącznie głupotą i chorymi przyzwyczajeniami milionów)

A defetystom mówimy NIE :)

Zresztą nie widzę sensu szufladkowania się od samego początku w obozie 
przegranych (Haskell, SML, itd.)

Kamil