[nem-pl] nawiasy

[Michal Moskal]

On Fri, Feb 13, 2004 at 06:56:31PM +0100, Lukasz Kaiser wrote:
> Hej.
> 
> Przez caly dzien sprawdzania egzaminow z logiki sprawdzalem zadanie numer 10
> za ktore mozna bylo uzyskac max. 8 punktow i w sumie wszystkim ok. 300 osobom
> dalem 1 slownie jeden :(. Tak, zadanie bylo proste chociaz wymagalo tw. 
> o zwartosci dla logiki pierwszego rzedu (ale to nie byl pierwszy rok).

Może byłeś zbyt surowy ;)

> Kamil, pewnie ze masz racje ze * sa nieczytelne i myle sie z nimi regularnie,
> ale <> nie rozwiazuja problemu, przynajmniej dla mnie bo z nimi tez sie myle
> regularnie :). Ale tutaj problem moze tkwic we mnie ;).
> 
> Michal dal IMHO bardzo madra odpowiedz na pytanie o target audience - 
> programisci Open Source ale ci od C#, Perla, PHP, Pythona a nie MLa / Haskella.
> Jedyne moje zastrzezenie jest takie, ze ci ludzie chyba najwiecej programuja
> rzeczy w stylu zastosowan webowych, 

Niekoniecznie. Webowe rzeczy robiś się głównie za pieniądze. Za darmo
nikt tego nie pisze bo to nudne ;) Oczywiście generalizuje, ale nie
wydaję mi się, żeby to była większość, najwyżej 10-20%.

> wiec raczej nie sa im tak bardzo potrzebne
> funkcje wyzszego rzedu jak dobre makra. Oczywiscie Nemerle ma i to i to, poza
> tym jest Sioux i moze bedzie nawet umial robic cos po stronie serwera, to by
> bylo super. Moze warto sie zastanowic nad czyms w stylu mod_nemerle ?

IMHO jeśli nie zintegrujemy siouxa z system.web (HttpApplication i takie
tam), to będziemy wciąż od nowa wymyślać koło. Ale to tylko moje zdanie
i równie dobrze można by to o całym Nemerle powiedzieć więc nie będę się
upierał.

> > def x = 'a();
> 
> To ja tutaj pozwole sobie na kawalek religijny, przepraszam tych co nie lubia.
> 
> Czym sie rozni generics od typow polimorficznych ?
> Ktos moze mysli ze w zasadzie to niczym, ale dla mnie to nie jest prawda.
> Dla mnie generics pozostaje w fazie szblonow i makr, poniewaz jest nacechowane
> innym typem myslenia niz typy polimorficzne. Tworzac kod w generics taki jak
> "def x = T ()" myslisz tak: pisze sobie ten kod, zeby funkcjonowal dla dowolnej
> klasy T, zebym mogl go sobie potem uzywac w roznych miejscach dla roznych klas.
> Zupelnie inaczej myslisz piszac z uzyciem typow polimorficznych. Myslisz tak:
> pisze sobie funkcje dla typu dictionary ('a, 'b) bo to co te funkcje robia
> to sa operacje na slowniku z jakimis tam wartosicami. Wprowadzasz abstrakcje
> przede wszystkim z tego powodu, ze myslenie w oparciu o ta abstrakcje jest
> prostsze i bardziej czytelne. Nigdy nie napiszesz "'a()" bo 'a jest czyms,
> nie mozesz zalozyc ze ma konstruktor i nie masz takiej potrzeby (nawet jesli
> wszystko na swiecie ma konstruktor i mozesz to zalozyc, to psuje abstrakcje).

Kamil napisał w where, że ma konstruktor (where T : new ()). To jest po
prostu inna klasa abstrakcji -- takich typów które mają defaultowy
konstruktor a nie wszystkich. Pominąwszy religijne rozważania, jest to
bardziej ogólne podejście niż czyste typy polimorficzne.

> To jest moze roznica religijna, ale ona sie odbija w skladni, bo napisanie
> "list<int>" w pewnym sensie sugeruje ze schemat "list" instancjujesz typem
> "int". Tak myslisz w generics, ale nie przy typach polimorficznych, gdzie nie
> ma w ogole mowy o zadnej instancjacji. 

U nas jest, tzn. teraz nie ma, ale będzie. Co więcej tak jest lepiej --
efektywniej.

> Mysle, ze przyjecie wiekszej ilosci
> takich haczykow z generics bedzie skutkowac takim czyms, ze ludzie beda
> uzywali typow ze zmiennymi tylko tam, gdzie wyda im sie to niezbedne, glownie
> w bibliotekach operujacych na kolekcjach. Sami natomiast beda najchetniej
> pisac klasy z konkretnymi typami. Zupelnie inaczej programuje sie (a moze to
> tylko ja?) 

Ja, nie da się ukryć, nie używam typów polimorficznych poza strukturami
danych.

> np. w OCamlu - uzywasz zmiennych typowych gdzie tylko sie da, chociaz
> nie ma z tego zadnego zysku w postaci "code reuse" bo na koncu i tak uzywasz
> tych abstrakcyjnych funkcji tylko dla jednego typu (np. deklarujac tree 'a, 
> potem uzywajac zawsze tree int). Ale w ten sposob piszesz lepszy program, bo
> masz lepsza kontrole przez uzycie abstrakcji. Sam jezyk w pewnym sensie zmusza
> czy naklania cie do tego zeby tak postepowac. Czy chcemy zeby Nemerle tez do
> czegos takiego naklanial, jak bardzo i jakim kosztem ?

Nie sądzę, żebyśmy zdziałali coś metodą bata, marchewka widzi mi się
znacznie bardziej.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?