1

Всем известно деление основных языковых концепций на императивные и функциональные языки.

К ним стоит добавить особняком стоящий Форт, который, с одной стороны, в классическом виде является настолько императивным, что большинство изначально иперативных рядом с ним функциональными кажутся, с другой - позволяет лего реализовать и функцинальный базис (видел Пролог-подобное расширение всего в несколько килобайт исходных кодов).

Тем не менее, выставляя Форт, можно императивные языки поставить в середину между ним и языками функциональными.

Так вот, родилась у меня достаточно давно и всё укрепляется мысль, что:
- Функциональные языки написаны для чёрных логиков. Не быдлокодеров, а тех, кто действительно заботится о качестве своего кода. Чёрному логику тяжело охватить взглядом всю белологическую структуру программы, а ФП позволяет эту структуру раздробить на несколько субструктур, безошибочной связью которых занимается компилятор и, таким образом, позволяет ЧЛ- программисту меньше заботиться о связках в целом.

- Форт - это язык для БЛ. Общую структуру программы программист прекрасно держит в голове, взаимосвяз объектов очевидна, но, у всех БЛ проблема - безошибочная компоновка низкоуровневых, конечных, чернологичных элементов. Форт тут приодит на помощь, позволяя составлять программу из крошечных элементов, связи которых с внешними элементами строго заданы, а размер такой ("психологические" 7+/-2 активных элемента), что просто не позволяет развиться в них паразитным связям и особым ситуациям, которы программист-статик легко зевнёт. Зато, каждый такой кирпичик, легко отлаживается отдельно. Имея же набор безошибочно работающих кирпичиков, белый логик легко потом их соединить в целостную большую структуру - программу.

- Императивные языки находятся прмерно посередине, имея достоинства и недостатки и того и другого подхода...

...

Кстати, общая тенденция "чернологизации" программирования последних 10..15 лет, наверное, и объясняет то, что тот же Форт был практически вытеснен с рынка. Чёрному логику довольно неуютно в нём.

Этим же, наверное, объсянется и рост интереса последнего времени к функциональным языкам у профессиональных программистов.

2 Отредактировано xeye (27.11.2005 13:14:03)

фигню, написали, простите default/smile
алоголоподобные языки рулили еще во времена  форта, и их успех был з закреплен использованием паскаля в преподавании а так же переписыванием юникса на С... ну а дальше был маркетинг.

"у всех БЛ проблема - безошибочная компоновка низкоуровневых, конечных, чернологичных элементов."  VS  "ЧЛ  проблема  - удержание в голове структуры " -  ниасилил

3

А скриптовые языки - для болевых логиков default/wub

chatenoir пишет:

А скриптовые языки - для болевых логиков default/wub

неее. я вот перл очень уважаю default/wub

5

да, кстати, а для кого пролог? готов  обсудить default/smile)
или такая штука, как ant-скрипты - оно кому помогает?

6

zverek пишет:
chatenoir пишет:

А скриптовые языки - для болевых логиков default/wub

неее. я вот перл очень уважаю default/wub

А на PHP я себе на хлеб с маслом зарабатываю default/big_smile Perl же тоже часто использую - для решений "на коленке".

7

>да, кстати, а для кого пролог? готов  обсудить default/smile)

На эту тему определённых мыслей нет. Но сам язык, понятно, совершенно белологичный. Так что, можно предположить, что больше он подходит именно для ЧЛ default/smile

>или такая штука, как ant-скрипты - оно кому помогает?

Я только один ant знаю - apache ant. Каждый день десятки раз юзаю, но только для сборки проекта default/big_smile

Balancer пишет:
zverek пишет:
chatenoir пишет:

А скриптовые языки - для болевых логиков default/wub

неее. я вот перл очень уважаю default/wub

А на PHP я себе на хлеб с маслом зарабатываю default/big_smile Perl же тоже часто использую - для решений "на коленке".

да и у меня так же. какую нибудь творческую схемку проверть - на перле. потом часто приходится на пхп переписывать для реальной работы.

9

>Ещё с трудом представляю себе проектирование на нём сложных структур данных

Его перестали развивать до того, как таких структурах возникла надобность default/smile Тот же ANS94 - это лишь косметика... Можно сказать, что с конца 1970-х гг. Форт не развивался. Кроме того, его сгубила и его гибкость. Кто будет стандартизировать какие-то объекты для Форта, когда ООП для него пишется средней квалификации программистом за пару дней и весит несколько килобайт исходников. Это привело к тому, что каждый пишет расширения под себя и стандарта на них нет и не будет. Кроме того, FIG (вполне справедливо, наверное) полагает, что введение описания структур в рамки стандарта сделает Форт менее гибким и отказывается от этого.

> и многократное использование кода).

Тут проблем особых не было. Система словарей (аналог вложенных namespaces) позволяет легко переносить законченные модули из программы в программу. И тут мы опять упираемся в отсутствие жёстких стандартов на многие высокоуровневые вещи...

>Никогда не мог понять, как что-то серьёзное можно на функциональных языках писать.

А, наверное, придётся default/big_smile Мне кажется, что за ФП - будущее. И не только по причине "прихода к власти" ЧЛ в программировании. ФП позволяют решения БЛ-задач переносить на плечи компьютера. И многое в этой области компьютер сделает лучше человека. Будущее по любому за мультипроцессорными/мультиядерными системами. Автоматическое же распределение вычислительных нагрузок между ними в рамках одной задачи - это нетривиальная БЛ-задача, которая как раз хорошо решается функциональными языками. Сейчас только ФП позволяют эффективно и _автоматически_ распределять нагрузку по вычислителям.

>но ведь в основном программирование - деятельность, требующая не столько полёта мысли, сколько структурирования, проектирования и кодирования в общем-то несложных задач, сложность их более сводится к объёмам.

Вот, ты и сводишь программирование к БЛ-задачам (на самом деле - это всегда связка БЛ+ЧЛ). Но что делать чёрным логикам? Вот им и в помощь ФП default/smile

> В общем, со своей базовой БЛ я ФП толком ниасилил, так что возможно, что оно таки более для ЧЛ default/smile

Я тоже не шибко осилил... Только на уровне тестов default/smile Хотя, есть задачи, которыми можно бы было нагрузить O'Caml, но проект очень человекоресурсоёмкий, и даже на используемой сейчас Java команда очень маленькая (это я про L2J игровой сервер).

10

>да и у меня так же. какую нибудь творческую схемку проверть - на перле. потом часто приходится на пхп переписывать для реальной работы.

Лет 10..15 назад для реальной работы я потом переписывал на QBasic. Лет 5 назад альтернативы реальной не было. А недавно я стал такие решения писать... на Java default/big_smile Хорошая, современная, быстрая и удобная замена QB пятнадцатилетней давности default/smile

11

>фигню, написали, простите default/smile
>алоголоподобные языки рулили еще во времена  форта

И что? Чем это противоречит моему тексту? Алгол - такая же голимая императивщина default/smile

>"у всех БЛ проблема - безошибочная компоновка низкоуровневых, конечных, чернологичных элементов."  VS  "ЧЛ  проблема  - удержание в голове структуры " -  ниасилил

Значит, на разных языках говорим, чего удивительного-то? default/big_smile

12

А надо у них самих спросить, у чёрных логиков, как им ФП?

Только не у всех, а у тех, кто заботится о качестве кода спрашивать, думаю, нужно default/big_smile

13

Balancer пишет:

Всем известно деление основных языковых концепций на императивные и функциональные языки.

И на Пролог. default/smile

Balancer пишет:

Кстати, общая тенденция "чернологизации" программирования последних 10..15 лет, наверное, и объясняет то, что тот же Форт был практически вытеснен с рынка.

Программирование чернологизируется, потому что изменились условия. В случае, например, небольших программ (а таких имхо большинство), пишущихся на ОО-языках нужно лишь улучшить какой-то стандартный класс и все готово.

А форт вытеснен с рынка, потому что (опять же имхо) он узкоспециализированный. Потребителей языков вроде C++ больше, чем людей, которые пишут прошивки для каких-то устройств. Для других целей Форт мне не кажется очень уж эффективным из-за того что трудно быстро разобраться в коде. Хотя не знаю, я на Форте только пару программ всего написал. default/smile

Balancer пишет:

Этим же, наверное, объсянется и рост интереса последнего времени к функциональным языкам у профессиональных программистов.

Это потому что нынешние вычислительные мощности позволяют делать программы на них эффективными. А программы на них получаются компактными, потому что не надо постоянно думать о распределении памяти и прочих низкоуровневых вещах.

А вообще, исходя из "Кодирование - преим. ЧЛ, проектирование и специфицирование - БЛ." самые БЛ языки -- это, имхо, Лисп (в меньшей степени) и Пролог. Тут вообще почти нет ЧЛ составляющей: пишется только структура -- остальное транслятор придумывает.

Очень удобным с этой точки зрения мне кажется Перл. Python и Java (особенно) мне как-то не очень понравились: много писанины лишней. Вот сейчас читаю про C#.

zverek пишет:

неее. я вот перл очень уважаю

Аналогично. Имхо, это весьма ЧИ язык, что дает развернуться моей творческой. default/smile

14

'!' пишет:

Да есть тут кто-нибудь, кто в ФП прилично шарит? default/smile

Что есть "прилично"? Редактирование конфигов для Emacs'а -- это неприлично? default/smile

15

>Прилично - это так, чтобы внятно объяснить на пальцах суть, отличия и преимущества функционального подхода в сравнении с императивным.

Не... Это не прилично, это примитивно default/big_smile
- Более однозначный и более строгий синтаксис
- Меньше side-эффектов
- Возможности более тонкой оптимизации при компиляции (O'Caml)
- Возможность ленивых вычислений (Haskell)
- Меньше объём исходных кодов

Это то, что я своим дилетантским взглядом нахлжу default/smile

>И как писать программы на ФЯП  default/smile

Тут дальше простейших тестов дело не пошло у меня. Ну, вот, чисто вычислительный пример на O'Caml (он, правда, не рафинированный ФП-язык, в нём есть примесь императивщины)

Трёхпараметрическая функция Аккермана.

              + X+1,                 если N=0
              | X,                   если N=1,  Y=0,
              | 0,                   если N=2,  Y=0,
    A(N,X,Y)= | 1,                   если N=3,  Y=0,
              | 2,                   если N=>4, Y=0,
              + A(N-1,A(N,X,Y-1),X), если N#0,  Y#0;

где N,X,Y - целые неотрицательные числа.


Си:

#include <stdio.h>

void main(void)
{   
    printf("%d\n",a(3,8,8));
}

int a(int n, int x, int y)
{  
    if(!n) 
        return x+1;

    if(y) 
        return a(n-1,a(n,x,y-1),x);

    switch(n)
    {  
        case 1:  return x;
        case 2:  return 0;
        case 3:  return 1;
    }

    return 2;
}

O'Caml:

let rec a n x y =
    match (n, y) with
        (0, y) -> x+1
      | (1, 0) -> x
      | (2, 0) -> 0
      | (3, 0) -> 1
      | (n, 0) -> 2
      | (n, y) -> (a (n-1) (a n x (y-1)) x)
    ;;

print_int(a 3 8 8);
print_newline();;

Программа на O'Caml выполняется раза в полтора быстрее, чем на Си default/big_smile Даже если Си использует регистровую передачу (сравнивался MS VC7, GCC сливает ему очень прилично) Он, вообще, очень экономно к формату чисел относится и к фреймам функций.

Кстати, Форт в виде

: AA  ( x y n -- an )
    ?DUP 0= IF DROP 1+ EXIT THEN
    SWAP ?DUP IF  
        >R 2DUP R> 1-  SWAP RECURSE 
        -ROT 1- RECURSE
        EXIT
    THEN

    DUP 1 = IF DROP ( x ) EXIT THEN
    DUP 2 = IF 2DROP    0 EXIT THEN
        3 = IF 2DROP    1 EXIT THEN
    DROP 2
;        

: A  ( n x y -- an )  ROT AA ;
3 3 3 A . CR

при использовании SPF4 с оптимизатором оказался между o'Caml и Си default/smile

16

Вот изящное решение чисел Фибоначи на Хаскелле. Сам по себе язык весьма тормозной (он, скорее, интерпретируемый), но зато  - ленивый. Считает только те данные, которые нужны в данный момент.

fibz = 1 : 1 : [ x+y | (x,y) <- zip fibz (tail fibz)]

fibz тут - это массив _всех_ чисел фибоначчи (т.е. не ограниченный сверху), каждое из чисел которого является суммой элементов этого же массива, прямого и сдвинутого на одно число.

Берём N-й элемент просто как N-й элемент массива. Скорость вычисления с рекурсивными методами не сравнить (т.е. на много порядков быстрее), а вид записи - столь же примитивен default/smile

Или - быстрая (qsort) сортировка, написанная на O'Caml:

qsort [] = []
qsort (x:xs) = qsort[y|y<-xs,y>=x] ++ [x] ++ qsort[y|y<-xs,y<x]

Две строчки. Для любых типов, понятное дело, лишь бы для них операции сравнения были определены. Сколько строк быстрая сортировка на Си займёт? default/big_smile

17 Отредактировано Balancer (29.11.2005 21:34:36)

Ну и в заключении ссылочка на "эволюцию Хаскелл-программиста" на примере вычисления факториала default/big_smile
http://www.willamette.edu/~fruehr/haske … ution.html

...
...

Не смотря на то, что я ни одного ФП для практического программирования на них не знаю, выделяю именно O'Caml и Хаскелл. Первый за потрясающее быстродействие, второй - за, пожалуй, самый строгий лексический анализ. Профи говорят, что этот язык отлавливает процентов 90 популярных _алгоритмических_ ошибок на этапе компиляции default/smile

Хотя определённые надежды можно возлагать на F# (т.к. это .NET, а по скорости вычислительных задач на уровне C#). Lisp меня убивает своей древностью и префиксной записью, порождающей тучи скобок. Eiffel, Erlang, хотя и имеют почитателей (на последнем ажно популярный e-jabberd написан), но как-то совсем уж в стороне от мэйнстрима default/smile

18

мне кажется или балансер самозабвенно беседует сам с собой? default/roll:

19

q пишет:

мне кажется или балансер самозабвенно беседует сам с собой? default/roll:

А давно квестимам стали нужны собеседники? default/big_smile

20

'!' пишет:

Спасибо за обзор, вдохновляет на плотное изучение... Насколько я понял из него, функциональное программирование сводится к изящной и компактной форме кодирования итеративных и рекурсивных алгоритмов

Да, если совсем коротко (и, соответственно, неточно default/big_smile) ФП - это замена итераций на рекурсии. Замена присваиваний на вызовы функций.

'!' пишет:

причём оперирует не машинными типами данных, а абстрактными.

Нет, типизация в них бывает зачастую очень жёсткая. При чём, в случае того же O'Caml она даже статическая, не динамическая. Но, как и во многих современных императивных ЯВУ, типизация может быть скрыта от пользователя. Это как в Java:

for(Player i : getKnownPlayers())
{
   ...
}

А getKnownPlayers может возвращать и Player[], и ArrayList<Player> и даже ConcurrentHashSet<Player> default/smile