🚀 go-pugleaf

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