Здравствуйте, INTP_mihoshi, Вы писали:

INT>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.

Звучит красиво, только и с реальностью надо считаться

Здравствуйте, Nick_, Вы писали:

INT>>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.

N_>Ну почему же? Для того что бы разрабатывать интерфейсы, поведение которых не выходит за рамки конечного автомата математического образования не надо

Для разработки интерфейсов и программистом быть необязательно. К тому же, я говорил не про образование.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Здравствуйте, Gaperton, Вы писали:

INT>А вообще, ты можешь привести примеры задач, где ФЯ языки существенно и гарантированно выигрывают у ИЯ?
Привести такие примеры я не могу, за отсутствием должного количества статистики и опыта. Скорее можно сказать, где выигрыша гарантированно нет. При написании клиентов для приложений баз данных, например. Но порассуждать можно.

Если говорить о ФЯ вообще, чтобы существенно и гарантированно то: Прототипирование, и прочие случаи, где скорость разработки важнее производительности. Системы, где надежность важнее производительности.

ФЯ весьма органично бы смотрелся в качестве вычислительно полного языка запросов к БД. И есть примеры — языки К (KDB), и D4 (Dataphor).

Если говорить именно о функциональном стиле (многие ФЯ позволяют писать и проектировать императивно), то он дает заметные преимущества в описании сложных алгоритмов. Разнообразные оптимизаторы, например. Трассировщик лучей — тоже отличный пример.

А конкретно вот так сказать — где ФЯ гарантированно лучше, ИМХО нельзя. Надо рассматривать связку "язык"-"класс задач". Я рассмотрю несколько языков.

Про Erlang доказано практически, что он рулит в тех задачах, для которых создан (Распределенные/сетевые приложения. Требования: высокая надежность, высокая доступность, хорошая масштабируемость, хорошая производительность при пиковой нагрузке, хорошее время отклика). Будешь писать DNS сервер, маршрутизатор , или ферму веб серверов — он гарантированно выигрывает, потому что специально разработан чтобы здесь выигрывать.

А вот для численных методов он подходит заметно хуже Фортрана (т. е. никак), но в этой области с фортраном может потягаться ФЯ Sisal, который не уступит ему по производительности и превзойдет по удобству. Тоже доказанный факт. Sisal создан, чтобы быть лучше Фортрана для численных методов.

Ни то ни другое не подходит для написания десктопных приложений, и удобными универсальными языками не являются. Универсален, выразителен и красив у нас Haskell. Но уж больно паршивый у него компилятор. Он, во-первых медленный. Во-вторых, производительность программ немного не та, что можно ожидать от статически типизированного языка. Особенно разочаровывают массивы, которые должны по идее работать быстро (благодаря реализованым деструктивным изменениям при заворачивании в монаду ST), но тормозят не по децки. Piton ему конкурент, вобщем. Но по красоте и выразительным возможностам Haskell-ю нет равных. Будем ждать нормального компилятора.

Казалось-бы, всех этих недостатков лишен Clean. Вот он, правильный Хаскель! Все у парней хорошо. Компилятор быстрый. Скорость выполнения весьма адекватна (а для чисто функционального "ленивого" языка — так просто фантастическая. Он практически наравне с OCaml, а OCaml во первых, strict, а во-вторых — местами императивен). Парни говорят, что он в частности великолепно подходит для написания десктопных приложений со сложной логикой (Word/Excel). И характеристики языка для этого подходят. Отличный продукт — сказка. Казалось бы. Но и здесь засады.
1) Авторы его пытаются продавать. Т. е. поставить его вы можете бесплатно, но вот коммерческий софт делать низзя. Надо им отстегнуть.
2) И это бы ничего. Ацтигнули бы, нивапрос, покажите только за что. Но ведь в сети нет ни одной ссылки ни на один проект, сделанный на Clean! Ни на один! И ни одного отчета о применении. Не то что серьезного отчета — вообще ни одного! Даже об исследовательских проектах. Если кто-нибудь найдет таковой, просьба сообщить мне. И естественно, ни ворда ни екселя на нем не написано. Теория, конечно, теорией, но практика критерий истины. А на слово я не верю.

А еще эти парни давно (лет 7, минимум) пишут книгу, но никак не могут дописать. Впрочем, draft часть 1 можно скачать. Все это выглядит довольно странно. Я этих людей не понимаю. Но сам язык весьма интересен.

Ну, а дальше — остается OCaml. Язык универсален, хуже чем с императивными языками не будет точно, так как он еще и императивный. Быстрый, функциональный, позволяющий вести разработку с минимальным риском. Будте уверены, производительности — хватит. А начет не хватать — всегда можно оптимизнуть. Одна беда. У меня пока аллергия на синтаксис OCaml, но это дело привычки. Есть отчеты о завершенных проектах на OCaml (как для Erlang) — шлите ссылки. Интересно.

From: INTP_mihoshi

> Тогда, получается, ИЯ должен генерировать данные за программиста?

Тут надо с точкой зрения определиться. Принято говорить, что процессор "выполняет" объектный код, а JVM байт код "интерпретирует". Как называется отношение между процессором который выполняет JVM, которая интерпетирует байт-то, и этим байт-кодом я не знаю. А при генерации, если используется программа, обычно происходит целый каскад генераций. Программа берет исходные данные, интерпретирует их, получает нечто, интерпретирует его, потом еще и еще и в конце концов что-то выдает.

Я бы сказал, что программа должна для пользователя выдавать интерпретации исходных данных. Обычная программа, которую выдает компилятор, это _интерпретатор данных_, переводит с одного представления в другое, часть информации обычно теряет, но точно не должна ничего добавлять. Если это действительно программа, а не данные с просмотровщиком.

ИЯ-программист пишет этот интерпретатор на ИЯ-языке. Он описывает саму процедуру интерпретации.
ФЯ-программист использует готовый движок и просто переписывает правила предметной области на каком-то языке, упрощенном по сравнению с человеческим, таком что и машина понимает. Ладно, в философию увело.

ИЯ-программирование это написание функций, ФЯ это написание функционалов, это функциональное программирование. Разница же есть. Для этого его и нужно использовать, а не писать функции, выполняя функционалы в уме. Разве не так?

Вот солдат учат из автомата стрелять. Обучение начинается с чистки автомата. У нас это qsort. Но ведь автомат совсем не для того, чтобы его чистить.

Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Gaperton, Вы писали:

AF> Комплексуем? Где я хоть слово сказал про тебя?
AF> Про узколобых фанатов ФЯ — да. Но где я адресовал эти слова тебе?
Ох и утомили широколобые... Удивительно, как у них голова в дверной проем пролезает — неудобно наверно...

Что? А где я адресовал эти слова тебе?

Ты вообще в состоянии внятно объяснить, зачем ты это пишешь? Хочешь подчеркнуть свой ум на фоне чужой глупости? По другому никак?

AF> ТЫ сам только что отнёс эти слова к себе.
Говоря в воздух, никому конкретно, ты адресуешь эти слова вообще ВСЕМ участникам, кто высказывается в пользу ФЯ. Из разряда "а потом он оскорбил весь город". И вообще, по моему я сказал "приписывать мне и остальным".

AF> Пора понять, что мир вокруг тебя не вертится и там другие люди есть...
Как ты мне недавно сказал? "Это свего лишь твоя точка зрения".
Задумайся сам над своей фразой. И научись спокойно реагировать на чужие мнения и интересы, тем более что тебя лично они никак не задевают.

Здравствуйте, Gaperton, Вы писали:

VD>Ты мне покажи что-то что я смоку сказчать на свой писюк, скомпилировать и поглядеть. Ну, и чтобы аналоги были императивные.
G>Это можно. Завтра.

Вот это простой веб сервер.

-module(httpd).
-export([start/1,server/1,reqhandler/1]).

start(Port) ->
   spawn(httpd, server, [Port]).

server(Port) ->
   {ok, Lsock} = gen_tcp:listen(Port, [binary, {packet, 0}, 
      {active, false}]),
   serverloop(Lsock).

serverloop(Lsock) ->
   {ok, Sock} = gen_tcp:accept(Lsock),
   spawn(httpd,reqhandler,[Sock]),
   serverloop(Lsock).

reqhandler(Sock) ->
   ReqStr = getreq(Sock),
   [FirstArg, SecondArg | Tail] = string:tokens(ReqStr, " \n\t"),
   if 
      FirstArg =/= "GET" ->
         gen_tcp:send(Sock, list_to_binary("400 Bad Request\r\n"));
      true ->
         {ok, BaseName, _} = regexp:gsub(SecondArg, "/$|^$", 
             "/index.html"),
         {ok, File, _} = regexp:sub(BaseName, "^/+", ""),
         sendfile(Sock, File)
   end,
   gen_tcp:close(Sock).

getreq(Sock) ->
   getreq(Sock, []).

getreq(Sock, OrigStr) ->
   {ok, Pack} = gen_tcp:recv(Sock, 0),
   RecStr = binary_to_list(Pack),
   NewStr = lists:append(OrigStr, RecStr),
   Pos = string:str(NewStr, "\r\n"),
   if 
      Pos =/= 0 ->
         string:substr(NewStr, 1, Pos-1);
      true ->
         getreq(Sock, NewStr)
   end.

sendfile(Sock, Filename) ->
   case file:read_file(Filename) of
      {ok, Binary} ->
         gen_tcp:send(Sock, Binary);
      _ ->
         gen_tcp:send(Sock, list_to_binary("404 Not Found\r\n"))
   end.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.

Математик и программист совершенно разные вещи. Человек конечно может быть и тем, и другим одновременно. Но не обязан. Для программирования нужно уметь логически мыслить. А не знать основы мат-анализа. Я не раз встречал людей знакомых с последним, но с большими проблемами в логике мышления. И программисты из них били никакие.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Вот, кстати, довольно толковый текст на тему "why OCaml"
INT>здесь

Почти все пункты можно отнести и к Шарпу. Вот только 3 секунды на П200 для 10 килобайтного файла — это не очень то быстро. Хотя тогда и винты были не те, и памяти меньше.

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

G>>О чем ты говоришь? . Никто даже и не догадывается, что OCaml позволяет делать, и, что характерно, не хочет знать. Все, что большинство о нем знает — что в нем есть страшная и неудобная рекурсия, что и обсуждается. Еще обсуждаются, в каком кривом формате (PDF) приведенные ссылки. "Цвет учебника" не нравится.
VD>Ты вместо того говорить о своих сокровенных знаниях поделился бы ими со всеми.
С теми, кто меня об этом просил, я поделился. И готов делиться еще.

Естественно, это было не в ответах на твои посты. Ты мне со своего первого поста зачем-то пытаешься доказать, что ты ФЯ не знаешь, не понимаешь, и они тебе не интересны. Это и так уже все поняли. Ты навязчив.

Здравствуйте, Gaperton, Вы писали:

G>Естественно, это было не в ответах на твои посты. Ты мне со своего первого поста зачем-то пытаешься доказать, что ты ФЯ не знаешь, не понимаешь, и они тебе не интересны. Это и так уже все поняли. Ты навязчив.

Это ты что-то пытаешся доказать. И за одно постоянно подменяешь мои слова. Зачем?

Dear Gaperton,

Как на ФЯ изменить состояние объекта
послать/принять сигнал
послать каждому объекту(произвольного типа) из списка

можно ли взглянуть

потому как с пониманием, как все вычисляется на ФЯ проблем нет
,а с этим как то ...

Здравствуйте, VladD2, Вы писали:

VD>К сожалению, его нужно пояснять в принципе. Запутаться в награмождении палочек не трудно. Это как регексы.

Мне кажется, со временем ФЯ-код воспринимается довольно легко, и это просто вопрос опыта. По крайней мере, мне хватило пары дней, чтобы научится разбираться в конструкциях наподобие упомянутого qsort. А ведь я видел нечто похожее только на 3-м курсе института (Пролог) и это было очень вскользь...

На любом языке, даже на Паскале можно написать программу, которую будет тяжело понять, особенно если хорошо поразвлекаться с размерами функций, названиями переменных и функций, goto, форматированием и указателями.

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

Все же, в любой индустрии нужны специалисты разного уровня, и "элита" должна хорошо разбиратся и в ФЯ, так как это другой взгляд на мир, без знания которого тяжело качественно строить сложные и конкурентоспособные системы. Программисту-архитектору без математического мышления тяжело расчитывать на успех, особенно в таких проектах как создание языков программирования, компиляторов, микропроцессоров итп. Например, ясно, что создатели языка С++ знакомы с ФЯ.

К Haskell помимо прочей документации прилагается ~60 страничный документ, и некоторые изложенные там концепции кажутся просто восхититительными. Сразу становится понятно, откуда в С++ взялись адаптеры типа bind1st.

Здравствуйте, Цунцуяби, Вы писали:

Ц>Dear Gaperton,

Ц>Как на ФЯ изменить состояние объекта
Ц>послать/принять сигнал
Ц>послать каждому объекту(произвольного типа) из списка

Ц>можно ли взглянуть

Ц>потому как с пониманием, как все вычисляется на ФЯ проблем нет
Ц>,а с этим как то ...

Точно так же как с вводом-выводом. Вы очень ограничено мыслите. Говоря "изменить состояние объекта" вы подразумеваете, что есть нечто имеющее имя или идентификатор которое еще и может изменить свое состояние. В функциональных языках это не так, они работают со значениями. Вы можете дать значению имя и не можете потом этому имени дать другое значение. Тоесть нет оператора присваивания.

Изменение состояния обьекта будет выглядить так:
x = ... — объект
x1 = method x params -- вызов метода для обьекта x с параметрами.
метод возвращает измененный объект. Если вы потом не используете предыдущее значение объекта x, то компилятор размещает x1 в памяти вместо x.

Приведу пример из С++
ввод-вывод: cout << "hello " << "world" << endl;
оператор << снова возвращает cout, к которому опять применяется оператор <<
В функциональных языках то же самое, только тот объект ввода-вывода который возвращает функция вывода отличается от первоночального.

Здравствуйте, VladD2, Вы писали:

VD>Математик и программист совершенно разные вещи. Человек конечно может быть и тем, и другим одновременно. Но не обязан. Для программирования нужно уметь логически мыслить. А не знать основы мат-анализа. Я не раз встречал людей знакомых с последним, но с большими проблемами в логике мышления. И программисты из них били никакие.

Знать матанализ совершенно не обязательно. Для понимания ФЯ нужна способность понимать и оперировать сложными абстрактными понятиями. Да, мозги скрипят, по крайней мере поначалу. Но ничего сложнее университетского курса математики. Если человек честно закончил мат-мех, то он, скорее всего, к этому способен. Хотя ему, возможно, просто лень думать, но это общая проблема Просто надо выбирать, либо ты больше думаешь заранее, либо дольше и чаще ловишь багу потом.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, INTP_mihoshi, Вы писали:

INT>>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.

VD>Математик и программист совершенно разные вещи. Человек конечно может быть и тем, и другим одновременно. Но не обязан. Для программирования нужно уметь логически мыслить. А не знать основы мат-анализа. Я не раз встречал людей знакомых с последним, но с большими проблемами в логике мышления. И программисты из них били никакие.

У вас странное представление о математике. Математика — это не только матанализ, но и теория множеств, логика, теория алгоритмов...
А логически мыслить полезно всем, независимо от рода деятельности.

Здравствуйте, INTP_mihoshi, Вы писали:

INT>А вообще, ты можешь привести примеры задач, где ФЯ языки существенно и гарантированно выигрывают у ИЯ?

Системы компьютерной алгебры?

Здравствуйте, Nick_, Вы писали:

Ц>>Как на ФЯ изменить состояние объекта
Ц>>послать/принять сигнал
Ц>>послать каждому объекту(произвольного типа) из списка


N_>Точно так же как с вводом-выводом. Вы очень ограничено мыслите. Говоря "изменить состояние объекта" вы подразумеваете, что есть нечто имеющее имя или идентификатор которое еще и может изменить свое состояние. В функциональных языках это не так, они работают со значениями. Вы можете дать значению имя и не можете потом этому имени дать другое значение. Тоесть нет оператора присваивания.

Зачем же, сразу "ограничено" Монады и понять-то с первого раза сложно, а уж самому догадаться — тем более

N_>Изменение состояния обьекта будет выглядить так:
N_>x = ... — объект
N_>x1 = method x params -- вызов метода для обьекта x с параметрами.
N_>метод возвращает измененный объект. Если вы потом не используете предыдущее значение объекта x, то компилятор размещает x1 в памяти вместо x.

В классическом ФЯ (например, Haskell) Все, действительно, так и происходит. Крутиться "на самом верху" цикл, в котором видны все глобальные переменные. Он занимается вводом-выводом и рулит всеми состояниями.

В казуальных ФЯ, например, в *ML, есть mutable значения, которые являются аналогом обычных переменных.

N_>Приведу пример из С++
N_>ввод-вывод: cout << "hello " << "world" << endl;
N_>оператор << снова возвращает cout, к которому опять применяется оператор <<
N_>В функциональных языках то же самое, только тот объект ввода-вывода который возвращает функция вывода отличается от первоночального.

Не совсем понимаю, к чему этот пример... Слово "применяется" как-то плохо вяжется с ФП

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Знать матанализ совершенно не обязательно. Для понимания ФЯ нужна способность понимать и оперировать сложными абстрактными понятиями. Да, мозги скрипят, по крайней мере поначалу. Но ничего сложнее университетского курса математики. Если человек честно закончил мат-мех, то он, скорее всего, к этому способен. Хотя ему, возможно, просто лень думать, но это общая проблема Просто надо выбирать, либо ты больше думаешь заранее, либо дольше и чаще ловишь багу потом.

Вот именно — полностью согласен. Но это свойство ума хорошего математика.
Дело в том, что можно окончить универ — даже с отличием, просто заучивая формулы и теоремы, но не обладая таким мышлением. По моим наблюдениям таких людей в институтах — большинство. Они кстати потом довольно успешно работают как инженеры, программисты и даже учёные.
Людей у которых хорошо развито абстрактное мышление — гораздо меньше. Но именно такое мышление необходимо для освоения ФЯ в том виде — в каком он был продемонстрирован выше.
Другое дело — SQL — многие запросы по сути своей — такие же функционалы. Но облечены в гораздо более лёгкую для восприятия форму — и их понимает гораздо больше людей.

Здравствуйте, Nick_, Вы писали:

N_>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, INTP_mihoshi, Вы писали:

INT>>>От программистов математиков — 100%. Если программист не умеет математически мыслить — то это кто угодно, но не программист.

VD>>Математик и программист совершенно разные вещи. Человек конечно может быть и тем, и другим одновременно. Но не обязан. Для программирования нужно уметь логически мыслить. А не знать основы мат-анализа. Я не раз встречал людей знакомых с последним, но с большими проблемами в логике мышления. И программисты из них били никакие.

N_>У вас странное представление о математике. Математика — это не только матанализ, но и теория множеств, логика, теория алгоритмов...
N_>А логически мыслить полезно всем, независимо от рода деятельности.

Открыл америку... Конечно это нам прекрасно известно. Только если брать статистически — по тому, что изучают в вузах — то для большинства математика — это действительно в основном матанализ и линейная алгебра — поскольку он применяется в научныхб, инжененерных и экономических расчётах — и они составляют 90% если не больше — по объёму часов на их изучение. А вот всё остальное — тензорное исчисление, теория множеств, топология, теория алгоритмов — изучаются вообще далеко не везде, не всеми и далеко не всегда — глубоко. Я прекрасно помню, как нас натаскивали на матан и как поверхностно давали теорию множеств — в итоге последнюю приходилось изучать самому.
Большинство программистов — нарвится Вам это или нет — имеют не очень хорошее образование вообще, математическое — тем более. На западе так вообще считается что программисту знать математику не обязательно. Это реальность и с ней — приходится считаться. И заявлять что они де не программисты — бесполезно — ибо для большинства менеджеров — они программисты и крупные фирмы создавая средства разработки ориентируются на большинство — то есть — на них...

Здравствуйте, Gaperton, Вы писали:

G>Про Erlang доказано практически, что он рулит в тех задачах, для которых создан (Распределенные/сетевые приложения. Требования: высокая надежность, высокая доступность, хорошая масштабируемость, хорошая производительность при пиковой нагрузке, хорошее время отклика). Будешь писать DNS сервер, маршрутизатор , или ферму веб серверов — он гарантированно выигрывает, потому что специально разработан чтобы здесь выигрывать.

Имху Erlang по сфере применения — удачный функциональный Python

G>Ни то ни другое не подходит для написания десктопных приложений, и удобными универсальными языками не являются. Универсален, выразителен и красив у нас Haskell. Но уж больно паршивый у него компилятор. Он, во-первых медленный. Во-вторых, производительность программ немного не та, что можно ожидать от статически типизированного языка.

У меня большое подозрение, что медлительноость — плата за мощную систему типов Классы типов, полиморфизм по типам и Nil в каждом типе — удобно, стильно, но, видимо, дорого...

G>Казалось-бы, всех этих недостатков лишен Clean. Вот он, правильный Хаскель! ... Все это выглядит довольно странно. Я этих людей не понимаю. Но сам язык весьма интересен.
+1

G>Ну, а дальше — остается OCaml. Язык универсален, хуже чем с императивными языками не будет точно, так как он еще и императивный. Быстрый, функциональный, позволяющий вести разработку с минимальным риском. Будте уверены, производительности — хватит. А начет не хватать — всегда можно оптимизнуть. Одна беда. У меня пока аллергия на синтаксис OCaml, но это дело привычки.

Не у одного тебя К счастью, в OCaml и синтаксис можно выбирать.

здесь

The revised syntax is an alternative syntax for OCaml. Its purposes are 1/ fix some problems of the normal syntax (unclosed constructions sometimes introducing ambiguities, constructors arity, end of top level phrases and structure items, etc) 2/ avoid unjustified double constructions (":=" vs ``<-'', ``fun'' vs ``function'', ``begin..end'' vs parentheses) or concepts (types and types declarations) 3/ bring some ideas (lists, types). In a word, propose a syntax which be more logical, simpler, more consistent and easier to parse and to pretty print.
...
It is a syntax of the complete language, therefore it can be used for all OCaml programs: by the way, Camlp4 is itself completely written in that syntax. Notice that it is not a constraint: it is always possible to convert from and to the normal syntax, using the pretty print facilities of Camlp4.