On 30/05/2011 07:08, Maciej Pilichowski wrote:
> On Sat, 28 May 2011 13:50:02 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
>
> Dlaczego do mnie osobiscie jak na razie wszystkie te jezyki nie
> przemawiaja:
> * kod wyglada jakby byl zaszyfrowany -- wszystko maksymalnie
> upakowane, nawet jesli to moj wlasny kod, to po kwadransie musze
> ponownie dochodzic do tego jaki byl tego sens. Albo inaczej, w
> jezykach funkcyjnych kod jest zapisany "sprytnie", w zlym sensie

Z drugiej strony języki C-podobne też mają "zaszyfrowaną" składnię, a
wygrały popularnością z bardziej czytelną składnią języków
pascalo-podobnych.

> * nawet przy jezykach, ktore dostaja blogoslawienstwo duzych graczy
> brak jest ksiazek -- czy ktos widzial np. "Building websites with
> ASP.Net and F#"? Ja nie

O F# są książki, może nie takie, jak napisałeś, ale przecież o wielu
rzeczach nie ma specjalnej książki np. "Building order-routing systems
in C++ on Unix", a jednak się je robi.

> * no i wymieniony juz problem -- w czym sa one lepsze? Albo inaczej,
> potrzebuje np. typedefa w C# tu, teraz, ASAP, dynamicznych tupli, itd.
> Wole miec lepszy C# niz F#, w ktorego za kazdym razem musze sie
> wgryzac

Oj, to każdy tak woli. Ja np. musiałbym się wgryzać w C#, więc mógłbym
zadać to samo pytanie: w czym on lepszy?

Z kolei wiem o sytuacjach, gdzie instytucje mają problem z językiem
imperatywnym w postaci takiej, że reguły biznesowe rozpisane na postać
imperatywną są strasznie trudnym do zrozumienia i utrzymania gąszczem
if-ów i else-ów, który w dodatku ciągle sie zmienia pod wpływem nowych
wymagań napływających z biznesu. W wielu takich przypadkach szuka się
alternatywnych sposobów wyrażenia tych reguł i języki funkcyjne niekiedy
bywają do tego używane (ale szczegółów nie znam, więc nie rozwinę).

W końcu też problemem wszystkich języków imperatywnych jest
programowanie współbieżne: ręczny podział problemu na wątki i
synchronizacja są trudne i błędogenne, a to, które rozwiązanie będzie
wydajniejsze mocno zależy od parametrów, które się zmieniają od systemu
do systemu.

Napisanie programu tak, żeby kompilator lub runtime mógł sam decydować
co się opłaca zrównoleglić, a co nie, kiedy kopiować dane, a kiedy
chronić muteksem itd., wymaga zmiany paradygmatu. Języki funkcyjne są
jedną z odnóg badań w tym kierunku.