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

G>Ну, положим, кое-какие практические исследования на эти темы есть. Но их проводил только Эрикссон, и только в телекоме . Они подтверждают выигрыш по продуктивности в четыре раза в сравнении с С++ и соответствующее уменьшение объема программы на системах объемом до 1.7 миллионов строк. Отчет Вигера я тебе посылал. Так что как минимум, не все так плохо. Но можно-ли переносить эту статистику на другие классы задач/языки — это вопрос. Собственно, нужно больше статистики.

Я в курсе. Но толку от этих исследований — не очень много, так как сначала создавался язык для более удобного и эффективного решения неких задач — а потом с удивлением обнаружили, что оказывается он эи задачи и правда эффективно решает.
По-моему гораздо важнее и интереснее — что получится для систем "обычных".
Я видел аналогичные исследования для матричных расчётов, но там было об этом сказано прямо — что делали специально под расчёты, потому и получилось — лучше. Кроме того, вспомним, что телеком — хорошо известная область — где на каждую задачу есть множество стандартных и опробированных решений, а сама система легко собирается из этих "кубиков" (я имею в виду естественно коммуникационную часть системы). Ещё замечу, что и в телекоме и в математике или физичских расчётах (где ФЯ так же эффективны) — фокус (основная часть системы) — это довльно сложные мат алгоритмы, причём эффективность их выполнения играет решающую роль. При этом сама система может быть тривиально простой, что то вроде — загрузили цифирки из текстового файла, запустили алгоритм, записали цифирки в другой файл. То есть все за рамками расчётной части — тривиально.
В традиционных же системах часто всё наоборот — алгоритмы просты, время их выполнения не особо критично (список из 10 строчек можно сортировать и пузырьком) — зато логика откуда, что и куда записать — может быть черезвычайно сложной. Вот потому и возникают соменения в эфектинвости ФЯ для таких систем. Тут ИЯ — явно лучше.

Hello, Gaperton!
You wrote on Fri, 27 Aug 2004 12:09:39 GMT:

G> Ну, я бы не сказал, что структура телекомовского софта примитивна.
G> Откуда дровишки, почему ты считаешь, что это бывает в телекоме часто?
G> Система состоящая из миллиона строк кода, которая делает полезную
G> работу (AXD switch), не может иметь примитивную структуру. И уж во
G> всяком случае, складская система из 50 тыщ строк , не может иметь
G> структуру сложнее .

Может-может. Есть системы "большие", а есть "сложные" — это разные вещи. И сложность меряется вовсе не в строках кода.

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

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

G>>>2) Что для этого предлагаешь сделать технически? Т. е. какое участие требуется?
К>>Пока особо чётких идей нет, но как минимум было бы неплохо иметь форум посвящённый ФЯ, но даже не форум, а тему таку, где пару ветвей аля по языкам, по уровню (в любом случае помощь чайникам, к которым себя я тоже причисляю, будет ОЧЕНЬ нужна, популяризации без этого не видать).
INT>Кхм... На одну бы ветки ФПшников хватило А уровнень у всех имху примерно один.

Может я просто уже в светлое будущее смотрю?

К>>Потом можно и offline-встречи пробовать организовать. Плюс можно попробовать что-нибудь РЕАЛЬНОЕ на том же ocaml'е сваять, чтобы не теоретические вещи, а проект жизненный был, главное, правда, придумать что бы это могло быть.
INT>А реальное... Можно, например, попробовать написать более удобные примитивы для OCaml. А то существующие средства хотя и разнообразны, но имху довольно криво сочетают императивный и функциональный стиль. Гораздо хуже, чем это позволяет язык. В Haskell все было завязано на функциональность и списки, и это работало. Для Ocaml имху больше подошла бы идеология итераторов...

Ну вот видишь, уже идея, можешь её более чётко это дело описать так, чтобы можно было бы людям за это дело браться и ваять что-нибудь толковое?
Но, вообще-то это всё равно за рамки ФЯ не выходит, реальное имелось в виду что-нибудь такое, чтобы можно было чуть не обычному юзеру показать, а он сказал: нифига себе!
Т.е. как влад тут вещал — слишком поклонники ФЯ завязаны сами на себя (рекурсия, однако ), а на остальной народ даже почти и не смотрят.
Так вот имхо РЕАЛЬНОЕ — это как раз что-то чтобы остального народа касалось.

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

INT>Для хорошей модульности нужен достаточный уровень абстракции без потери строгости. На ИЯ этого достичь невозможно by design.

Да? Сколько я видел — прекрасно удаётся, правда это требует от разработчика творческого взгляда и большой работы.

AF>> Так вот — ни намёка на механизм, который обеспечивал бы лучшую ситуацию для ФЯ систем я не увидел. Похоже — что получится такая же запутанная система — просто запутанная по другому. Грабли окажутся расставленными в других местах...

INT>Gaperton приводил цитату, содержащую этот намек, причем уже дважды.

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

INT>Имху пока ни те, ни другие еще в достаточной мере не развиты. Но я просто не вижу других путей. Уже очень давно все развитие ИЯ состоит только в том, что к ним приклеивается тот или иной кусочек, который уже давным-давно был в ФЯ.
Точно тоже можно сказать и про ФЯ языки. Со второй половины 60-х их развитие — это или приделывание кучков ИЯ языков или — изобретение способов, как сделать то, что ИЯ языки давно и легко делают.
А вот сам факт того, что прикручиваются кусочки, а не осуществляется переход на ФЯ — лучший показатель того, что этих "кусочков" — в форме STL или любой другой — более чем хватает. Осознайте наконец, что далеко не каждый программист на C++ знаком и тем более использует даже STL.

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

VD>Я не видел. К тому же если даже и есть, то трибуна у них никакая. А РСДН это уже сила. Нас признают даже коммерческие конторы вроде МС и Интела.

Предлагаю приделать в значки собщений что-нибудь вроде танца с саблями...

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

Кстати! Вопрос возможно не очень в тему: А как классифицировать языки Mathcad/Maple/Mathematica и т.п.? Там очень многое явно напоминает функциональные языки...

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

ST>Hello, Gaperton!
ST>You wrote on Fri, 27 Aug 2004 12:09:39 GMT:

G>> Ну, я бы не сказал, что структура телекомовского софта примитивна.
G>> Откуда дровишки, почему ты считаешь, что это бывает в телекоме часто?
G>> Система состоящая из миллиона строк кода, которая делает полезную
G>> работу (AXD switch), не может иметь примитивную структуру. И уж во
G>> всяком случае, складская система из 50 тыщ строк , не может иметь
G>> структуру сложнее .

ST>Может-может. Есть системы "большие", а есть "сложные" — это разные вещи. И сложность меряется вовсе не в строках кода.
Складские системы — одна из самых простых систем, которые просто бьются на компоненты, к которым элементарно собрать требования, и которые понятно как реализовывать. В сравнении, естественно. Такие проекты должны выполняться с минимальным риском и без сетований о дикой сложности, особенно если речь идет о 50К строк.

Тем более, что индустриальная статистика показывает, что производительность KLOC/hr не скачет дикими прыжками от проекта к проекту, а напротив — довольно стабильна. На групповых проектах она не выходит за коридор 20-40 LOC/hr (данные Carnegie-Mellon SEI; генеренный код не считается). Так что кол-во строк кода — это вполне адекватная мера сложности.

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

VD>Технически нужно:
VD>На начальном этапе:
VD> 1. Сформировать документ-призыв. Прислать его, например, мне, или на submit@rsdn.ru. Мы его вычитаем и создадим новую ветку в дереве статей и новый форум.
Можешь дать пример такого документа?

VD> 2. Создать инициативную группу.
Пусть желающие в нее войти ответят на твой пост, для начала, а там подумаем, что с пунктом 3.

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

INT>ФЯ это не просто другой язык. Это в корне отличные принципы программирования. Требующие и от инструментов, и от программистов существенно больше. Конкретно, от инструментов — лучшую оптимизацию, от программистов — больше способность гибко мыслить. Имху пока ни те, ни другие еще в достаточной мере не развиты. Но я просто не вижу других путей.

Дело, ИМХО, даже не в том что требуется "...от программистов — больше способность гибко мыслить".
Тут скорее другие задачи требуются. Но не текнологии определяют задачи, а наоборот.

Сложная программа на функциональном языке, по большому счету, является просто функцией — т.е. из входных данных получает выходные. Можно все внутренности этой функции выкинуть и вставить другие, или полностью все переоптимизировать если результат не изменится.
А задачи которые сейчас больше востребованы не являются функциями. Эти задачи скорее являются реалтайм моделями, моделирующими реальный мир. Это множество объектов с множеством состояний, и с множеством правил перехода из одного состояния в другое. Реагирующие в реальном времени на внешние события.

Вот эта страничка форума не является функцией. Это сложная реалтайм модель. С огромным количеством обьектов и состогяний, которые выкинуть нельзя.
Такие задачи просто больше востребованы, как ни крути.

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


VD>Да фиг с ним с флэймом. Проблема в том, что толку от всех разговоров 0. Тут нужна упорная и крапотливая работа по популяризации. Как я тебе уже говорил, самая большая проблема ФЯ — это то что ими занимаются люди не от мира сего. Причем полностью лишенные способности продвигать свои идеи в массы.

Самое сложное в функциональном программировании это придумать задачу, которую можно было бы решить на ФЯ.

А вобще я надеялся что эти парни сделают что то не оторванное от жизни. Но что то не очень они спешат.
http://research.microsoft.com/projects/ilx/fsharp-release.aspx

Никто эту штуку не ковырял еще случайно? Может все-таки есть очевидцы, которые поделятся впечатлениями?

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

G>Можешь дать пример такого документа?

Ну, то должно быть нечто среднее между статьями к проектам (можно посмотреть в разделе "проекты") и, например, вот такой статьей

Автор(ы): Беркович Вадим, Чудин Андрей
Дата: 09.04.2003
Практически во всех проектах можно встретить те или иные паттерны проектирования. Но далеко не часто они обозначены разработчиками. Проект, в котором явно обозначены все использованные паттерны, удобнее для понимания и более управляем. Можно сказать, что описание проекта в терминах паттернов добавляет новые метаданные о проекте. Если мы считаем, что данный класс реализует паттерн "итератор", мы сразу получаем представление об его интерфейсе и роли. Если же изначально весь проект реализован с использованием паттернов, то управление проектом упрощается. Обобщение удачных решений конкретных задач в паттерны и использование их в последующих проектах существенно ускоряет процесс разработки. А код становится более понятным и элегантным, и им можно будет воспользоваться повторно.

про патерны.

VD>> 2. Создать инициативную группу.
G>Пусть желающие в нее войти ответят на твой пост, для начала, а там подумаем, что с пунктом 3.

Дык для этого лучше открыть новую тему. Сформулировать все по человечески. А то многие могли просто пропустить эту сообщение.

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

INT>А реальное...

Да рельно больше нужна статья в котой давались бы общие понятия и сведения для быстрого старта. Ну, там, где брать компиляторы, отладчики среды (какие и как настраивать). Еще лучше было бы сделать подборку софта и залудить его на сидюк к журналу плюс список прямых сылок, а то и зип на нашем сайте.

А улучшения уже потом.

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

G>Ну, положим, кое-какие практические исследования на эти темы есть. Но их проводил только Эрикссон, и только в телекоме . Они подтверждают выигрыш по продуктивности в четыре раза в сравнении с С++ и соответствующее уменьшение объема программы на системах объемом до 1.7 миллионов строк. Отчет Вигера я тебе посылал. Так что как минимум, не все так плохо. Но можно-ли переносить эту статистику на другие классы задач/языки — это вопрос. Собственно, нужно больше статистики.

Дык выигрыша в продуктивности (программистов) я и так добьюсь во многих областях (особенно в бизнес-софте) взяв вместо С++ тот же C#. С++ язык довольно сложный и низкоуровенвый. На нем эффективно пишутся именно низукоуровенвые вещи требующие тонкой оптимизации по скорости выполения. Так что это не показатель.

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

AF> В традиционных же системах часто всё наоборот — алгоритмы просты, время их выполнения не особо критично (список из 10 строчек можно сортировать и пузырьком) — зато логика откуда, что и куда записать — может быть черезвычайно сложной. Вот потому и возникают соменения в эфектинвости ФЯ для таких систем. Тут ИЯ — явно лучше.

Это можно сформулировать одним предложением. То что ты называешь "обычными задачами" на самом деле является системами обработки информации. А то к чему склонны ФЯ — это вычислительные и рассчетные задачи. Возможно так оно и есть. При обоработке информации бОльшая часть кода занимается порождением объектов, их копированием и другой обработкой. Тут более важно абстрагирование данных, а не алгоритмво. Чем тут могут помочь ФЯ не ясно. А в вычислительных задачах на первый план выходят требования абстрагирования алгоритмов. В современных ИЯ такие возможности предоставляются полиморфизмом и шаблонами/дженериками, которые иногда оказываются менее эффективным средством абстрагироания чем функции высшего порядка. Видимо поэтому ученые и околоученые круги на ура принимают ФЯ, а мэйнстрим (в основном пишущий прикладнуху для бизнеса и производства) вообще не осознает их необходимости.

Кстати, что могут дать линивые вычисления в рельных приложения кроме "залатывания концептуальных дыр" ФЯ я так и не осознал.

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

S_>Сложная программа на функциональном языке, по большому счету, является просто функцией — т.е. из входных данных получает выходные. Можно все внутренности этой функции выкинуть и вставить другие, или полностью все переоптимизировать если результат не изменится.
Все верно. Это и ведет к большей надежности ФП программ — то, что значительная часть программы состоит из "чистых функций".

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

S_> Вот эта страничка форума не является функцией. Это сложная реалтайм модель. С огромным количеством обьектов и состогяний, которые выкинуть нельзя.
А никто их и не будет выкидывать. Рассмотри пару моделей — Data Flow Diagram и Entity-Relationship Diagram. Эта пара в сочетании описывает практически любую задачу — вот он, функциональный взгляд на мир.

Чтобы ответить на такой вопрос, начать можно с того, реальная программа в большинстве ФЯ не является "чистой функцией". Например, на высшем уровне Erlang система выглядит как множество (потенциально очень большое — до 200000) взаимодействующих процессов, каждый из которых имеет состояние и определенный протокол взаимодействия. Похоже на объекты смоллтока, как писал Вовин. Считается нормальным использовать процесс как единицу инкапсуляции. Внутри процесса используется простой функциональный язык, описывающий логику работы системы. Т. е. внутри процесса — большая часть логики реализовано чистыми функциями. Между процессами ходят данные, которые преобразуются чистыми функциями.

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

NewTree = insert( Element, Tree ),
do_something( NewTree, Tree );

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

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

A1 = change1( A ),
A2 = change2( A1 ),
A3 = change3( A2 ),
...

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

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

G>>Можешь дать пример такого документа?

VD>Ну, то должно быть нечто среднее между статьями к проектам (можно посмотреть в разделе "проекты") и, например, вот такой статьей

Автор(ы): Беркович Вадим, Чудин Андрей
Дата: 09.04.2003
Практически во всех проектах можно встретить те или иные паттерны проектирования. Но далеко не часто они обозначены разработчиками. Проект, в котором явно обозначены все использованные паттерны, удобнее для понимания и более управляем. Можно сказать, что описание проекта в терминах паттернов добавляет новые метаданные о проекте. Если мы считаем, что данный класс реализует паттерн "итератор", мы сразу получаем представление об его интерфейсе и роли. Если же изначально весь проект реализован с использованием паттернов, то управление проектом упрощается. Обобщение удачных решений конкретных задач в паттерны и использование их в последующих проектах существенно ускоряет процесс разработки. А код становится более понятным и элегантным, и им можно будет воспользоваться повторно.

про патерны.
Э-э-э... То есть что-то вроде основополагающей стати в духе "ФП: что, зачем и почему" в стиле FAQ к comp.lang.functional?

VD>>> 2. Создать инициативную группу.
G>>Пусть желающие в нее войти ответят на твой пост, для начала, а там подумаем, что с пунктом 3.
VD>Дык для этого лучше открыть новую тему. Сформулировать все по человечески. А то многие могли просто пропустить эту сообщение.
Разумно.

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

VD>Это можно сформулировать одним предложением. То что ты называешь "обычными задачами" на самом деле является системами обработки информации. А то к чему склонны ФЯ — это вычислительные и рассчетные задачи. Возможно так оно и есть. При обоработке информации бОльшая часть кода занимается порождением объектов, их копированием и другой обработкой. Тут более важно абстрагирование данных, а не алгоритмво. Чем тут могут помочь ФЯ не ясно. А в вычислительных задачах на первый план выходят требования абстрагирования алгоритмов. В современных ИЯ такие возможности предоставляются полиморфизмом и шаблонами/дженериками, которые иногда оказываются менее эффективным средством абстрагироания чем функции высшего порядка. Видимо поэтому ученые и околоученые круги на ура принимают ФЯ, а мэйнстрим (в основном пишущий прикладнуху для бизнеса и производства) вообще не осознает их необходимости.

Именно это я и имел в виду , остаётся сюда добавить интенсивный ввод-вывод, обработку графики и драйвера и получаем, что Mainstream прекрасно обходится без ФЯ и ещё долго обходиться будет. Более того. Мне кажется, что в современном виде ФЯ вообще мейнстримом никогда не станут. Но их время может придти позже, когда для большнства типичных бизнес объектов будут выработаны определённые стандарты — тогда, возможно, ими можно будет манипулировать так же, как мы сейчас это делаем со строками или числами — используя достаточно чётко выраженные алгоритмы (сейчас фокус внимания всё ещё на технических деталях реализации подобных объектов). Вот в это время многие идеи ФЯ окажутся востребованы и применимы к месту.

VD>Кстати, что могут дать линивые вычисления в рельных приложения кроме "залатывания концептуальных дыр" ФЯ я так и не осознал.
Сейчас ФЯ интересно изучать приенительно к расчётным системам. Вроде бы (очень на то надеюсь) — ситуация в стране потихонечку изменяется к лучшему — и подобные задачи становятся более востребованными.

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

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

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

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

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

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

G>>>Можешь дать пример такого документа?

VD>>Ну, то должно быть нечто среднее между статьями к проектам (можно посмотреть в разделе "проекты") и, например, вот такой статьей

Автор(ы): Беркович Вадим, Чудин Андрей
Дата: 09.04.2003
Практически во всех проектах можно встретить те или иные паттерны проектирования. Но далеко не часто они обозначены разработчиками. Проект, в котором явно обозначены все использованные паттерны, удобнее для понимания и более управляем. Можно сказать, что описание проекта в терминах паттернов добавляет новые метаданные о проекте. Если мы считаем, что данный класс реализует паттерн "итератор", мы сразу получаем представление об его интерфейсе и роли. Если же изначально весь проект реализован с использованием паттернов, то управление проектом упрощается. Обобщение удачных решений конкретных задач в паттерны и использование их в последующих проектах существенно ускоряет процесс разработки. А код становится более понятным и элегантным, и им можно будет воспользоваться повторно.

про патерны.
G>Э-э-э... То есть что-то вроде основополагающей стати в духе "ФП: что, зачем и почему" в стиле FAQ к comp.lang.functional?

VD>>>> 2. Создать инициативную группу.
G>>>Пусть желающие в нее войти ответят на твой пост, для начала, а там подумаем, что с пунктом 3.
VD>>Дык для этого лучше открыть новую тему. Сформулировать все по человечески. А то многие могли просто пропустить эту сообщение.
G>Разумно.

Gaperton — ждём от тебя чёткого поста по теме (аля призыва )

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


Модульность...улучшение..производительность..ФЯ..ля-ля-ля... Какой-то пиар сплошной.
Товарищ, ответь пожалуйста на такой вот вопрос — если ФЯ так выгодны и мегаудобны — почему же они не используетются? Вот есть например МС — вершина ИТ-сектора, контора с возможно максимальной на сегодняшний день эффективностью — казалось бы, эти товарищи точно должны врубаться что удобно и эффективно, а что нет. Вопрос — почему не пользуют ФЯ, почему не пишут на том же хаскеле. Хотелось бы услышать ответ в формате "ФЯ не применяются по следующим причинам 1)..." а не "да нихрена вы не рубите в житухе..."