🚀 go-pugleaf

Bazic wrote:
> Prosze o wyjasnienie nieniejszego tematu grupy (jakies faq?)
> Nie slyszalem dotad o tego rodzaju sposobie programowania.

Nie mam pojecia jak to wyjasnic. Chodzi w tym o to, ze wszystko kreci 
sie wokol funkcji. Wszsytkie wartosci sa stale, tzn nie musisz sie 
martwic, ze cos sie niepostrzezenie zmieni w pewnym czasie.

> Czym charakteryzuja sie wymieniane przez Was Grupowicze jezyki (czy inaczej:
> metody) programowania?

Tez nie mam pojecia.

> jakis krotki przyklad kodu? (np. w porownaniu do jakiegos OOP)

Funkcyjne z OOP ma malo wspolnego, ale istnieja jezyki ktore go 
wspieraja, np:

OCaml:

class foo s = object
   val mutable sru : int = s
   method get_sru = sru
end

class shmoo = object
   inherit foo 4
   method set_sru s = sru <- s
end

C++

class foo {
public:
   foo(int s) : sru(s) { }
   int get_sru() const { return sru; }
protected:
   int sru;
};

class shmoo : public foo {
public:
   shmoo() : foo(4) { }
   void set_sru(int s) { sru = s; }
};

-- 
Lucifer

In article <b2ap0k$cum$1@atlantis.news.tpi.pl>, Bazic wrote:
> Prosze o wyjasnienie nieniejszego tematu grupy (jakies faq?)
sądzę, że gdzies widziałem opis grupy - tam powinna być odpowiedź na to
pytanie.

> Czym charakteryzuja sie wymieniane przez Was Grupowicze jezyki (czy inaczej:
> metody) programowania?
nie jestem miarodajny, ale afaik chodzi o to, że (w językach
funkcyjnych) prawie każde wyrażenie
a) jest funkcją
b) jako taka może zwracać.
> jakis krotki przyklad kodu? (np. w porownaniu do jakiegos OOP)
lisp nie jest językiem czysto funkcyjnym, ale można napisac coś takiego:
(if (if (> x y) (> x z) (> y z))
	t
	nil)
mamy warunek w części warunkowej innego ifa... w c się tak afair nie da
(przynajmniej bezpośrednio ;)
		-- bies

-- 
(name (and '(ryszard szopa) 'bies))
(email '(bies (at) hell org pl))
(www 'http://bies.hell.org.pl)

Lucifer <lucifer@nospam.majora.net> wrote:
> Bazic wrote:
>> Prosze o wyjasnienie nieniejszego tematu grupy (jakies faq?)
>> Nie slyszalem dotad o tego rodzaju sposobie programowania.

> Nie mam pojecia jak to wyjasnic. Chodzi w tym o to, ze wszystko kreci 
> sie wokol funkcji. Wszsytkie wartosci sa stale, tzn nie musisz sie 
> martwic, ze cos sie niepostrzezenie zmieni w pewnym czasie.

>> Czym charakteryzuja sie wymieniane przez Was Grupowicze jezyki (czy inaczej:
>> metody) programowania?

> Tez nie mam pojecia.

>> jakis krotki przyklad kodu? (np. w porownaniu do jakiegos OOP)

> Funkcyjne z OOP ma malo wspolnego, ale istnieja jezyki ktore go 
> wspieraja, np:
	... jest CLOS - CommonLisp Object System. Z powazaniem
								Adam Przybyla

Adam Przybyla wrote:

> 	... jest CLOS - CommonLisp Object System. Z powazaniem

Dobrze wiedziec.

-- 
Lucifer

"Ryszard Szopa" <bies@dont.ask.stupid.questions> wrote:

> nie jestem miarodajny, ale afaik chodzi o to, że (w językach
> funkcyjnych) prawie każde wyrażenie
> a) jest funkcją
> b) jako taka może zwracać.
> > jakis krotki przyklad kodu? (np. w porownaniu do jakiegos OOP)
> lisp nie jest językiem czysto funkcyjnym, ale można napisac coś takiego:
> (if (if (> x y) (> x z) (> y z))
> t
> nil)
> mamy warunek w części warunkowej innego ifa... w c się tak afair nie da
> (przynajmniej bezpośrednio ;)

Oj, Ryszardzie :-)

[takze i od Przemka wymagam chwili skupienia]


Prosze, nie probuj definiowac pojecia "jezyk funkcyjny". Albowiem proba taka
jest z gory skazana na: a) niepowodzenie, lub b) dojscie do definicji
bezwartosciowej.


Niepowodzenie, jezeli bedzies skupial sie na cechach jezykow uwazanych za
funkcyjne i staral sie znalezc ich wspolny rdzen. Pewien zbior wlasnosci,
dla nich wspolnych. Nie istnieje cos takiego. Jezyki funkcyjne czestokroc
roznia sie bardziej miedzy soba niz miedzy ich obiektowymi kuzynami.


Dojscie do definicji bezwartosciowej, kiedy bedziesz probowal dociec co tak
naprawde czyni jezyk funkcyjnym. Bo, niestety, jezyk jest jezykiem
funkcyjnym iff jego autorzy zalozyli, ze on funkcyjnym bedzie. Na to sklada
sie w szczegolnosci wyglad standardowej biblioteki i propagowanie danego
(tu. funkcyjnego) stylu programowania. Funkcyjny styl programowania kladzie
nacisk na dekompozycje programu za pomoca matematycznych funkcji.
Matematyczna funkcja najprosciej mowiac - to taka mala czarodziejska
skrzyneczka, do ktorej z jedenj strony wkladamy jakas rzecz (np. krowe), a
z drugiej zaraz wyciagamy cos zupelnie innego (np. krolika). Przy czym wazne
jest, ze kazde kolejne wlozenia do owej skrzyneczki tej samej rzeczy co
poprzednio, owocuje nam pojawieniem sie identycznego produktu na wyjsciu.


Przyklad, ktory dalej dajesz w Lisp'ie jest zupelnie niezalezny od
funkcyjnosci. Ciezko mi to dokladniej skomentowac. Jest to zarazem
niepotrzebne. Za kilka dni, wglebiajac sie w CL'a, a najdalej kilka tygodzi,
sam do tego dojdziesz. Uwierz na slowo ;-)


mp

In article <b2dsso$pue$1@atlantis.news.tpi.pl>, Michal Przybylek wrote:
> Oj, Ryszardzie :-)
ojojoj... tylko nie belfrem, tylko nie belfrem! :)) 
> 
> Prosze, nie probuj definiowac pojecia "jezyk funkcyjny". Albowiem proba taka
> jest z gory skazana na: a) niepowodzenie, lub b) dojscie do definicji
> bezwartosciowej.
hm, czy sugerujesz, ze znalezienie definicji jezyka funkcyjnego nalezy
do grupy problemow ``uncomputable'' (przepraszam za angielska
terminologie, ale tylko ona jest mi znana, a nie chce tluamczyc ad hoc -
aby nie skonczyc jak tlumacz ,,najwiekszego teorematu Fermata''
(opowiadanie z Nowej Fantastyki... sami sie domyslcie, jak brzmial tytul
oryginalu ;) (a swoja droga, jak sie to tlumaczy, ,,nieobliczalne''?)

poza tym, takie podejscie naraza na niebezpieczenstwo pclf, jako ze
grupa dyskusyjna powinna miec scisla definicje - no bo wlasciwie o czym
rozmawiamy? ;)

a punkt b), imho traci paskudnym formalizmem - to Cie naraza na
niebezpieczenstwo skonczenia jak Hilbert - zawsze sie moze jakis Goedel
pojawic! :)
> 
> Niepowodzenie, jezeli bedzies skupial sie na cechach jezykow uwazanych za
> funkcyjne i staral sie znalezc ich wspolny rdzen. Pewien zbior wlasnosci,
> dla nich wspolnych. Nie istnieje cos takiego. Jezyki funkcyjne czestokroc
> roznia sie bardziej miedzy soba niz miedzy ich obiektowymi kuzynami.
pytanie - czy nie istnieja jezyki funkcyjne _i_ obiektowe (jak np.
CL?)? afaiaa, bardziej sie zawsze kladlo nacisk na konlikt
funkcyjne-imperatywne. 
  
> Dojscie do definicji bezwartosciowej, kiedy bedziesz probowal dociec co tak
> naprawde czyni jezyk funkcyjnym. Bo, niestety, jezyk jest jezykiem
> funkcyjnym iff jego autorzy zalozyli, ze on funkcyjnym bedzie. Na to sklada
> sie w szczegolnosci wyglad standardowej biblioteki i propagowanie danego
> (tu. funkcyjnego) stylu programowania. Funkcyjny styl programowania kladzie
> nacisk na dekompozycje programu za pomoca matematycznych funkcji.
> Matematyczna funkcja najprosciej mowiac - to taka mala czarodziejska
> skrzyneczka, do ktorej z jedenj strony wkladamy jakas rzecz (np. krowe), a
> z drugiej zaraz wyciagamy cos zupelnie innego (np. krolika). Przy czym wazne
> jest, ze kazde kolejne wlozenia do owej skrzyneczki tej samej rzeczy co
> poprzednio, owocuje nam pojawieniem sie identycznego produktu na wyjsciu.
o, jak fajnie ;). a propos funkcji matematycznych - wlasnie staram sie
zglebic tajniki rachunku lambda Churcha i, choc (podejrzewam) rozumiem
zalozenia, etc. nie jestem w stanie sprawdzic, czy sie nie myle (z
ksiazka nie da sie przedyskutowac watpliwosci...)(konkretnie z
``Emperor's New Mind'' Penrose'a)... jestes moze w tej kwestii
uswiadomiony, ew. czy mozesz mi kazac spadac na jakies uzyteczne drzewo (tj.
rzucic hyperlinkiem)?
> 
> sam do tego dojdziesz. Uwierz na slowo ;-)
wierze. zarzuty przyjmuje.
		-- bies

-- 
(name (and '(ryszard szopa) 'bies))
(email '(bies (at) hell org pl))
(www 'http://bies.hell.org.pl)

In article <b2doqq$40a$2@atlantis.news.tpi.pl>, Adam Przybyla wrote:
> 	... jest CLOS - CommonLisp Object System. Z powazaniem
> 								Adam Przybyla
nawet wiecej - afair wlasnie Lisp byl pierwszym jezykiem z obiektowoscia
wpisana do standardu.

		-- bies

-- 
(name (and '(ryszard szopa) 'bies))
(email '(bies (at) hell org pl))
(www 'http://bies.hell.org.pl)

In article <slrnb4mujn.qlp.bies@hell.org.pl>, Ryszard Szopa wrote:
> pytanie - czy nie istnieja jezyki funkcyjne _i_ obiektowe >(jak np.
> CL?)? afaiaa, bardziej sie zawsze kladlo nacisk na konlikt
> funkcyjne-imperatywne. 

W ocamlu jest coś takiego jak "functional objects" i jest to wyraźny
przykład tego, że może być coś obiektowe i funkcyjne zarazem (ani trochę
imperatywne). Mimo wszystko w moich próbach z ocamlem używałem jedynie
obiektów imperatywnych.

Obiekt funkcyjny tym się różni od typowego obiektu (znanego z języków
imperatywnych), że jest niezmienny. Metoda nie może zmieniać wartości
atrybutów obiektu, zamiast tego zwraca nowy obiekt, będący kopią
pierwotnego obiektu, jedynie z odpowiednimi zmianami w atrybutach.

Pozdrowienia,
        Jacek  

"Ryszard Szopa" <bies@dont.ask.stupid.questions> wrote:

Przepraszam - jestem mocno zajety, wiec odpowiem tylko pobieznie.


Co do Twojego przewrotnego pytania:

"czy nie istnieja jezyki funkcyjne _i_ obiektowe (jak np. CL?)?"

Nie wiem o co dokladni pytasz. Byc funkcyjnym nie jest trudno. Najczescie
wsytarczy skutecznie utrudnic programowanie obiektowe, aby sie nim stac (np.
CL i slaba integracja OS'u z reszta biblioteki, poziom skomplikowania OS'u ;
OCaml - wiadomo ; Scheme - wiadomo ; Haskell, Clean i im podobne -
niedostarczenie mechanizmow, lub dostarczenie niewygodnych do wyrazenia
obiektowosci [wcale nie twierdze, ze powinny byc dostarczone ; te jezyki sa
skalowane na rozwiazywanie zupelnie innych problemow ; zauwaz tez, ze w
druga stone to nie zachodzi - tj. wiekszosc "jezykow obiektowych" jest
wystarczajaco elastyczna, aby mozliwe bylo w nich w miare wygodne
programowanie funkcyjne]).

Zas, ogolnie, z jezykow multiparadygmatowych na mysl (procz CL'a) przychodza
mi tylko Oz/Mozart i kompletnie martwy LIFE.


Dalej piszesz:

"bardziej sie zawsze kladlo nacisk na konlikt funkcyjne-imperatywne"

Raczej deklaratywno-imperatywny.

Ja jednak nie widze zbytnio konfliktu. Deklaratywnosc dla mnie to pewien
sposob myslenia. Przeniesienie sie na pewien wyzszy poziom abstrakcji.
Poziom, ktory zezwala na naturalniejsze przelanie danego algorytmu na kod
programu, czyniac go tym samym bardziej zwiezlym i przejrzystym.

Nie zas ideologia fanatycznie wyznawana, czy tez wmuszana przez dany jezyk.
To prowadzi do paranoi. Jest wiele algorytmow majacych naturalna
implementacje imperatywna.


Ah, jeszcze jedno - grupa ta (przynajmniej w mysl tego co bylo napisane w
RFD :-)) jest jak najbardziej wlasiwym miejscem na zadawanie pytan
dotyczacych rachunku lambda.


mp

Fri, 14 Feb 2003 14:04:10 +0100, Michal Przybylek <pkmichal@poczta.onet.pl> pisze:

> Nie wiem o co dokladni pytasz. Byc funkcyjnym nie jest trudno. Najczescie
> wsytarczy skutecznie utrudnic programowanie obiektowe, aby sie nim stac

Nic podobnego. Do programowania funkcyjnego w moim rozumieniu
technicznie potrzeba co następuje (nie liczę integracji z bibliotekami,
tylko same cechy języka):

1. odśmiecania,
2. lokalnych funkcji ze statyczną widocznością identyfikatorów,
   z możliwością przekazywania takich funkcji jako obiekty (w taki
   sposób, że funkcje o danych typach argumentów i wyników mają ten
   sam typ - to jest trywialnie spełnione przez języki z dynamicznym
   systemem typów),
3. sposobu na wyrażenie typów algebraicznych,
4. możliwości opisania dowolnych wyliczanych wartości przez wyrażenie
   (a nie np. tylko instrukcję zapisującą wynik do zmiennej).

Na przykład C utrudnia programowanie obiektowe, ale funkcyjne tym
bardziej - odpada pod każdym względem.

Z języków tradycyjnie uznawanych za niefunkcyjne można programować
funkcyjnie w Rubym, w Perlu, częściowo w Pythonie (trochę brakuje 4),
w Smalltalku...

Z kolei C++, Java i Eiffel rzucają kłody pod nogi (C++ w każdym punkcie,
Java ma 2,3 zamotane, Eiffel dopiero próbuje wprowadzać 2,3,4).

Obiektowość nie ma tutaj wpływu na łatwość/trudność programowania
funkcyjnego.

> zauwaz tez, ze w druga stone to nie zachodzi - tj. wiekszosc
> "jezykow obiektowych" jest wystarczajaco elastyczna, aby mozliwe
> bylo w nich w miare wygodne programowanie funkcyjne]).

Bzdura. Zrób listę z leniwym ogonem w C++, Javie albo Eifflu -
wyjdzie powtorek.

Obiektowość tradycyjnie jest imperatywna i ma to uzasadnienia
techniczne (nie twierdzę, że decydujące). Otóż jeśli obiekty
zwracają swoje zmienione kopie zamiast zmiany stanu w miejscu,
to wysiada dziedziczenie: w podklasach metody zwracają obiekty nie
tej klasy co trzeba.

Chyba że się nagimnastykujemy i damy językowi odpowiednie mechanizmy
kopiowania obiektów z podmianą niektórych pól i pozostawieniu
nieokreślonego zestawu pozostałych bez zmian. Z języków, które znam,
tylko OCaml tak robi. Z tego powodu w językach tradycyjnie obiektowych
styl funkcyjny nie będzie dobrze integrował się z obiektowością.

Z kolei mieszanie stylu funkcyjnego i imperatywnego jest bezbolesne,
o ile nie oczekujemy funkcyjnej czystości. W dobrym języku sprowadza
się do wyboru konwencji używania struktur danych.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

>
> a punkt b), imho traci paskudnym formalizmem - to Cie naraza na
> niebezpieczenstwo skonczenia jak Hilbert - zawsze sie moze jakis Goedel
> pojawic! :)

Ciekawe, co tez ten Goedel biednemu Hilbertowi zrobil... :))

Tomek

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> Nic podobnego. Do programowania funkcyjnego w moim rozumieniu
> technicznie potrzeba co następuje (nie liczę integracji z bibliotekami,
> tylko same cechy języka):
>
> 1. odśmiecania,

Cuz za niewiarygodnie glupie rozumienie.

Zastanawiajace jest zas Twoje dazenie do podzielenia sie owym rozumowaniem z
nami. Wydaje Ci sie, ze kogokolwiek tu obchodzi Twoj proces myslenia ?
Jezeli masz z nim problemy to udaj sie do specjalisty.

A moze uwazasz, ze kiedy swiat uslyszy o Twoich problemach to one w jakis
magiczny sposob rozwiaza sie same... ?


Otoz, Qrczaku, jezyki funkcyjne istnialy zanim ludzkosc rozpropagowala cos
takiego jak odsmiecanie. Dynamiczne wiazanie dla zmiennych nielokalnych
domkniec bylo stosowane przez wiele, wiele lat (nawet kiedy juz znano
domkniecia leksykalne ; byly one wciaz nazbyt drogie). "Downward closure" sa
stosowane w jezykach funkcyjnych po dzis dzien (w wiekszosci sytuacji
domkniecie mozna utworzyc na stosie i razem z nim zniszczyc).

Pozatym, domkniecia mozna dealokowac recznie, co w wielu sytuacjach jest
wystarczajace. Kiedy nie wystarcza dobudowuje sie najzwyklejszy RC - gdzies
w granicach 30 lini kodu...


> 2. lokalnych funkcji ze statyczną widocznością identyfikatorów,
>    z możliwością przekazywania takich funkcji jako obiekty (w taki
>    sposób, że funkcje o danych typach argumentów i wyników mają ten
>    sam typ - to jest trywialnie spełnione przez języki z dynamicznym
>    systemem typów),

Widze, ze postanowiles nas uraczyc kolejnym dogmatycznym wytworem wlasnej
wyobrazni.

Jezyki funkcyjne moga istiec w ogole w oderwaniu od typow. Typy sa im
zbyteczne (tak statyczne jak i dynamiczne). Sam jezyk ma z tym tyle samo
problemu jak kazdy inny.


> 3. sposobu na wyrażenie typów algebraicznych,

Pewnie nie miales okazji zastanowic sie nad tym dlaczego tyle aplikacji
powstaje w Lisp'ach. W jak najbardziej funkcyjnym stylu. I jak najbardziej
bez typow algebraicznych. Mam racje ?

A moze to tylko dlatego, ze ludzie je piszacy nie wiedza, ze tak sie nie
da... ?


> 4. możliwości opisania dowolnych wyliczanych wartości przez wyrażenie
>    (a nie np. tylko instrukcję zapisującą wynik do zmiennej).

[zalozmy, ze domyslam sie, co chciales przekazac]


Wlasnie opracowalem nowy jezyk - CLII. Z tad mozesz sciagnac jego
implementacje:

http://www.franz.com/

Jedyne czym sie rozni od CL'a to to, ze wartosc z wolanie funkcji `atanh'
moze byc tylko inicjalizatorem dla zmiennej w formie `let'.


Oczywiscie zgodnie z Twoim "rozumieniem" ten jezyk juz nie jest funkcyjny ?

No dobra. Wazniejsze jest pytanie - czy to moj przyklad byl tak zlosliwy,
czy Twoje "rozumienie" na tyle kretyniczne, ze w ogole pozwalalo na dojscie
do takich wnioskow ?

Sam sobie odpowiedz.


> Z języków tradycyjnie uznawanych za niefunkcyjne można programować
> funkcyjnie w Rubym, w Perlu, częściowo w Pythonie (trochę brakuje 4),
> w Smalltalku...
>
> Z kolei C++, Java i Eiffel rzucają kłody pod nogi (C++ w każdym punkcie,
> Java ma 2,3 zamotane, Eiffel dopiero próbuje wprowadzać 2,3,4).
>
> Obiektowość nie ma tutaj wpływu na łatwość/trudność programowania
> funkcyjnego.

To jest wprost niewyobrazalne.

Normalny czlowiek, kiedy widzi sypkosc swojej teorii, to jak trudno jest
znalezc dla niej odzwierciedlenie w rzeczywistosci - zastanawia sie, czy
czasami aby nie jest z nia cos nie tak.

Ale nie Qrczak. Dla Qrczaka, jezeli teoria, nie pasuje do rzeczywistosci, to
trzeba ja zmienic. Rzeczywistosc ma sie rozumiec. Posluguje sie przy tym
dosc prymitywnym mechanizmem - stara sie wypracowac pewne wrazenie
- odbic swoj wyimaginowany swiat w realny, uzywajac jedynie sugestii, tak
aby wyrazic pewna jego czastke, asekurujac sie przy tym i utrudniajac
sprostowanie.


Wbrew sugestii nikt tu nie twierdzil jakoby obiektowosc miala jakikolwiek
wplyw na latwosc/trudnosc programowania funkcyjnego.

Wbrew sugestii jaka mozna odniesc czytajac powyzsza wypowiedz - jezyki
obiektowe majace problemy z wyrazeniem funkcyjnego stylu programowania
stanowia jedynie margines.


> > zauwaz tez, ze w druga stone to nie zachodzi - tj. wiekszosc
> > "jezykow obiektowych" jest wystarczajaco elastyczna, aby mozliwe
> > bylo w nich w miare wygodne programowanie funkcyjne]).
>
> Bzdura. Zrób listę z leniwym ogonem w C++, Javie albo Eifflu -
> wyjdzie powtorek.

Tak bzdura. Bzdura bo nie zgadza sie z logika, ktora Qrczak stworzyl na
potrzeby przeforsowania swoich argumentow.

wiekszosc ludzi umiera przed 80-ka => ludzie po 80-ce sa martwi

wiekszosc ludzi ma prace => bezrobotni nie sa ludzmi


No i w ogole programowanie funkcyjne to leniwe listy...


> Obiektowość tradycyjnie jest imperatywna i ma to uzasadnienia
> techniczne (nie twierdzę, że decydujące). Otóż jeśli obiekty
> zwracają swoje zmienione kopie zamiast zmiany stanu w miejscu,
> to wysiada dziedziczenie: w podklasach metody zwracają obiekty nie
> tej klasy co trzeba.
>
> Chyba że się nagimnastykujemy i damy językowi odpowiednie mechanizmy
> kopiowania obiektów z podmianą niektórych pól i pozostawieniu
> nieokreślonego zestawu pozostałych bez zmian. Z języków, które znam,
> tylko OCaml tak robi. Z tego powodu w językach tradycyjnie obiektowych
> styl funkcyjny nie będzie dobrze integrował się z obiektowością.

Tak - ma uzasadnienie. Zapewniam Cie jednak, ze nie jest ono tak idiotyczne.


Czy mozesz nam powiedziec na jakie sposoby, procz dziedziczenia i
delegacji, wyraza sie relacji generalizacja/specjalizacja w jezykach
obiektowych ?

A jezeli nie mozesz, to czy bylbys uprzejmy sie w koncu zamknac i przestal
pieprzyc na tematy, o ktory nie masz pojecia ?


> Z kolei mieszanie stylu funkcyjnego i imperatywnego jest bezbolesne,
> o ile nie oczekujemy funkcyjnej czystości. W dobrym języku sprowadza
> się do wyboru konwencji używania struktur danych.

Co z Toba Qrczak ? Kolejna ukryta sugestia ?

Wez sie w garsc ! Napraw siebie. Nikt inny tego za Ciebie zrobic nie moze.


mp

ps Nie mam przyjemnosci prostowania produktow Twojego "rozumienia" i
szerzonej dezinformacji.

Miej wiec tyle przyzwoitosci, aby nie podczepiac ich pod moje posty.

Użytkownik Michal Przybylek napisał:

> Cuz za niewiarygodnie glupie rozumienie.

Właśnie sięgnąłeś dna... *PLONK*

Sat, 15 Feb 2003 20:04:17 +0100, Michal Przybylek <pkmichal@poczta.onet.pl> pisze:

[...]

Poniżej pewnego poziomu wypowiedzi nie dyskutuję.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Mariusz K. Grzeca" <mgrzeca@sokrates.mimuw.edu.pl> wrote:

> > Cuz za niewiarygodnie glupie rozumienie.
>
> Właśnie sięgnąłeś dna... *PLONK*

No tak - powinno byc "coz"...


Potraktowalem Qrczaka w prawie dokladnie taki sam sposob, w jaki on ostatnio
zwykl traktowac innych. Jedyna roznica bylo to, ze ja zamiast ukrywac
chamstwo - celowo je wyostrzylem.

W tym sensie zachowalem sie bardziej w pozadku.


mp

Pewnego dnia, a było to Sun, 16 Feb 2003 21:49:28 +0100, przyszła do mnie
wiadomość z adresu <pkmichal@poczta.onet.pl> i powiedziała:

[..]
> Potraktowalem Qrczaka w prawie dokladnie taki sam sposob, w jaki on ostatnio
> zwykl traktowac innych. Jedyna roznica bylo to, ze ja zamiast ukrywac
> chamstwo - celowo je wyostrzylem.
> 
> W tym sensie zachowalem sie bardziej w pozadku.

"Jak na chama jestem zupełnie fajny".

  eloy
-- 
-----e-l-o-y-----------e-l-o-y-@-t-r-a-n-s-i-l-v-a-n-i-a-.-e-u-.-o-r-g-----

            na pewno krążą gdzieś planety na których nie ma zim

Michal Przybylek wrote:
> "Mariusz K. Grzeca" <mgrzeca@sokrates.mimuw.edu.pl> wrote:
> 
> 
>>>Cuz za niewiarygodnie glupie rozumienie.
>>
>>Właśnie sięgnąłeś dna... *PLONK*
> 
> 
> No tak - powinno byc "coz"...
> 
> 
> Potraktowalem Qrczaka w prawie dokladnie taki sam sposob, w jaki on ostatnio
> zwykl traktowac innych. Jedyna roznica bylo to, ze ja zamiast ukrywac
> chamstwo - celowo je wyostrzylem.
> 
> W tym sensie zachowalem sie bardziej w pozadku.

Nie prawda, pamietam Twoj poprzedni wystep (z AK).

-- 
Lucifer

[pią, 14 lut 2003 o 18:16 GMT], Tomek Czajka <tczajka@mimuw.edu.pl>:
>> a punkt b), imho traci paskudnym formalizmem - to Cie naraza na
>> niebezpieczenstwo skonczenia jak Hilbert - zawsze sie moze jakis Goedel
>> pojawic! :)
> 
> Ciekawe, co tez ten Goedel biednemu Hilbertowi zrobil... :))
pokazał wszem i wobec, że nie tylo nie ma racji, ale też racji mieć nie
może (w każdym możliwym wszechświecie ;).
		-- bies

-- 
(email '(bies (at) hell org pl))   ;; 4.1212 Co *można* pokazać, tego
(name (or '(ryszard szopa) 'bies)) ;; *nie można* powiedzieć.
(www '(bies hell org pl))          ;;     -- L. Wittgenstein