Ответ на »сообщение 1128« (bb)
___________________________

Хочу поднять тему которая до сих пор не затрагивалась - дисциплина программирования.

В данной ветке это интересно только применительно к особенностям ФП и сопоставлению с другими подходами. Если речь о дисциплине программирования вообще - то явный оффтопик.

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

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

Если брать современные заказные системы для зарубежного рынка, то там доля собственно программирования (кодирования) в производстве сводится к 15-20% от всего объема работ. Для заказчика, как правило, неважно, на чем конкретно реализуется система (фиксируется обычно только операционное окружение). Ему нужно получить хороший в его представлении результат в определенные (сжатые) сроки по приемлемой цене. Поскольку система активно участвует в бизнесе заказчика, она должна быть максимально адаптивной к изменениям требований, которые возникают либо в самом бизнесе, либо в ходе освоения/внедрения системы.

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

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

Пару недель назад я здесь поднял вопрос, имеющий самое непосредственное отношение к теме "ФП и дисциплина программирования". К сожалению, он так и повис в воздухе. Поэтому повторю его еще раз.

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

Ответ на »сообщение 1210« (Jack Of Shadows)
___________________________
Это значит что может сложиться ситуация когда наконец то будет четко очерчен контингент профессиональных программистов.
...
также никто больше не будет называть людей использующих не функциональные языки - программистами.


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

Хочу поднять тему которая до сих пор не затрагивалась - дисциплина программирования.
Расхожее мнение что парадигма ООП является доминирующей - неверно. ОО программистов ничуть не больше чем функциональных. Я имею в виду тех программистов которые применяют ОО парадигму при создании своих программ, а не тех кто работает на ОО языках. Типичный программист, использующий ОО язык, например дельфи, занимается так называемым event-driven programming. Что это такое ? Вот дельфи, среда поставляющаяся с огромной библиотекой готовых классов. Эти готовые классы программист и использует...через визуальный интерфейс (компоненто-кидательство) Свой код у него исключительно процедурный. На кнопку щелкнул - пустышка процедуры OnClick в коде появилась, в ней все и пишем. Обьектная модель данных ? Да вот она - моя обьектная модель. Вон TEditBox - это мой обьект. А его свойство Text - это где я храню данные, Гы : ))

Показательно например как заглохла ветка про ORM средства, которую я здесь пытался вести.
Нет абсолютно никакого интереса со стороны дельфистов. Данные у дельфистов в готовых обьектах TQuery, TTable и связанных с ними визуальных обьектах (тоже готовых) TGrid, ну и всяких там EditBox, DropDown итд итп.
ОК, может в других языках все не так плохо, например в java.
Увы, та же ситуация. Да, в java ORM средства гораздо более известны, но по той же причине что и ОО в целом - просто как победившая парадигма. Использование ORM в java в массе своей приводит к проблеме "анемичных обьектов". То есть классы используются просто как структуры для мапинга табличных данных. Код для работы с этими данными все также снаружи. Старый добрый процедурный стиль.

В чем дело ? Разве ООП не победил ? Разве мало книг, мало школ, мало учителей ? Мало языков и сред с поддержкой ОО ?
Да нет, все в порядке и с книгами и со школами и с языками.
А дело все в дисциплине.

Все знают что после КАЖДОГО ПРИЕМА ПИЩИ надо чистить зубы. Все знают чем грозит игнорирование этого правила. И тем не менее подавляющее большинство людей этого не делают.
Все знают что надо регулярно принимать физические нагрузки (зарядка, бег, спорт, йога, что угодно). Все знают что игнорирование этого правила приводит к тяжким последствиям. И тем не менее, подавляющее большинство людей согласны с ожирением, радикулитом, и другими болячками, только бы посидеть на диване за теликом вместо пробежки по парку.
Все знают что есть во всяких макдональдсах вредно. И тем не менее сотни миллионов людей регулярно отравляют себя всякой мерзостью.

Вы думаете что в программировании люди будут вести себя иначе ? Отнюдь! Поведение людей одинаково во всех сферах деятельности. Программировнаие не исключение.
Во всех случаях люди ведут себя подобным образом по одной простой причине. Потому что МОЖНО!
Можно не почистить зубы после еды, и они не выпадут сразу.
Можно не встать утром и не сделать зарядку и у вас не атрофируются мускулы, и не появится одышка и атеросклероз.
Можно сьесть гамбургер, запивая его кокаколой, и у вас не отвалятся печень и почки.
Можно написать программу в одну длинную простыню с тысячами локальных и глобальных переменных и сотнями циклов. И программа будет работать, и глюки не вылезут.
Все это (и кариес и цирроз печени и глюки в программе и невозможность что либо в ней изменить) все это наступит гораааздо позже.

Вот тут мы и приходим к дисциплине программирования господа. Как ее добиться ? Школы, книги, увещевания - не помогают.
Можно как то мириться с отстуствием дисциплины если это вредит только самому человеку.
Не занимаешься спортом ? Сам себе враг. Пожмем плечами и пойдем дальше своей дорогой.
Но как быть если своим наплевательством человек вредит другим ? Разве можно допустить солдата в армии, который не может пробежать с амуницией 10 километров ?
Ни в коем случае! Тут уже он вредит не только сам себе но и большой группе других людей - государству.
Поэтому в армии насаждается дисциплина. Поэтому солдаты каждый день и бегают и преодолевают препятствия, и стреляют. (Это я не о стройбате :)) )
А на гражданке тем же бывшим солдатам никто мозги не компассирует по утрам. Хочешь вставай и бегай, не хочешь - спи дальше.

Но как быть с программистами ? Ок, если человек пишет программу для себя, то ради бога, пусть как хочет так и портит себе жизнь.
Но если он солдат крупной компании, разве можно позволить расхлябанность ? Вель это навредит (и сильно) всей компании.
Как обеспечить дисциплину программирования ? Смотреть по работоспособности программы ? Но поначалу они все неплохо работают.
По внешнему виду ? Тоже не показатель. Посадить лучших из лучших просматривать код остальных ? Нереально. Лучших на всех не напасешься.

Да и какое все это имеет отношение к функциональному программированию ? Самое прямое!
Как я уже говорил, во всех этих ситуациях люди дейтсвуют подобным образом просто потому что МОЖНО.
Что же дает возможность программисту игнорировать любые парадигмы (ОО) и писать как бог на душу положит ?
Если начать разбираться то быстренько доберемся до корней проблемы.
Их два: Возможность менять состояние системы где угодно (присваивание) и возможность писать циклы.
Эти два свойства императивных языков позволяют писать работающие программы просто нанизывая последовательность инструкций одну за другой, игнорируя таким образом любую парадигму программировнаия.
Отними их, и программист внезапно попадает в армию с ее жесткой дисциплиной - НЕЛЬЗЯ!
Программист попадает в чистый функциональный язык. И тут уж хош не хош, а любую циклическую обработку данных придется оформалять в виде отдельной рекурсивной функции. Хош не хош а код изменяющий состояние системы придется отделять от кода описывающего связи компонент системы (чистые функции).
То есть сам язык, сама среда программирования ДИКТУЕТ определенную минимальную дисциплину программирования.

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

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

С появлением возможности использовать ФЯ на производстве, некоторые компании ощутили на практике плюсы такого подхода.
Это Erricson и Nortel, которые используют чистый ФЯ Erlang для написания своих систем телефонии.
Я уже приводил пример такой системы от Erricson которая насчитывает 1.7 миллионов строк кода, и при этом показывает невероятную для программ такого размера надежность. Это стало возможным не потому что ее писали какие то гении от программирования.
Это стало возможным потому что Erlang как чистый ФЯ, автоматически насаждает дисциплину, культуру программирования.

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

До сих пор такого явного различия между программистами не было.
Однако появление на сцене индустриального программировани ФЯ может все это изменить.
Если большие компании осознают те преимущества по ГАРАНТИИ дисциплины программирования, которые дает ФП, то через некоторое время может сложиться ситуация, когда на больших проектах, в которых учавствуют большие группы разработчиков, применение ФЯ станет необходимым инструментом насаждения такой дисциплины. Просто потому что никакого другого инстрмуента до сих пор НЕТ.

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

Ответ на »сообщение 1206« (bb)
___________________________
Честно говоря не увидел в SETL ничего необычного. Также как и в любом ФЯ, основой структурой данных SETL являются списки. На основе списков там построены sets и sequences, что опять же можно сделать в любом ФЯ.
Механизмы работы с множествами там такие же как и в любом другом ФЯ - то есть maps и list comprehensions.
SETL был бы неплохой заменой SQL базам данных, поскольку по настоящему построен на теории множеств, в отличии от современных реляционных БД, где теория множеств - это просто рекламный трюк, лапша вешаемая маркетингом.

Если уж вам хочется познакомиться с чем нибудь по настоящему отличающимся от ФП, ИП и ЛП - то обратите внимание на J - потомок APL, Array Processing Language

Ответ на »сообщение 1207« (Артем)
___________________________
Мемоизация в чистых ФЯ создана для эмуляции горячо нелюбимой вами "императивщины", т.е. для хранения промежуточных результатов. 

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


В C# конструкция для этого злосчастного Фиббоначи окажется не более громоздкой, а чуть более многословной из-за особенностей синтаксиса.


Можете заменить "громоздкий" на "многословный". Факт остается фактом. Мемоизация в ФЯ ничуть не труднее чем в ИЯ, и вообще из другой оперы (оптимизация) то есть не имеет никакого отношения к императивности\функциональности.

Ответ на »сообщение 1205« (Jack Of Shadows)
___________________________
Попробуйте привести код мемоизации на любом ИЯ и сравните. Не удивлюсь если окажется что мемоизация на java delphi сишарп окажется более громоздкой конструкцией. Мемоизация в чистых ФЯ создана для эмуляции горячо нелюбимой вами "императивщины", т.е. для хранения промежуточных результатов. В C# конструкция для этого злосчастного Фиббоначи окажется не более громоздкой, а чуть более многословной из-за особенностей синтаксиса. Для понимания и написания императивный вариант все-таки гораздо легче, особенно для случаев, которые сложнее чем Фиббоначи.

ФЯ отодвигает потолок абстракции еще выше. Я бы так не говорил. Там, просто, абстракции несколько иные. Говоря примитивным языком, если в ООП центральной осью являются существительные, а прилагательные (свойства) и глаголы (методы) являются "гражданами" второго класса, то в ФЯ все вертится вокруг глаголов.
IMHO, наиболее перспективными являются смешанные языки. И не забывайте, что ваша любимая лисповая черная дыра тоже является смешанным языком :)

Ну а что будет когда возможности ФЯ будут использованы на 100% и мы опять упремся в потолок абстракции, наверное не нам с вами решать. Почему, а мне было бы интересно услышать ваше мнение на этот счет. :)

Я например считаю что этого вообще не произодет, потому что мы скорее достигнем уровня когда программы будут писать сами компьютеры. Не дай Бог дожить до этого времени - я же останусь тогда безработным. Фиг с ним, я даже согласен на вашу черную дыру - Лисп,лишь бы не остаться без "черной икры" на своем бутерброде. :)))

Ответ на »сообщение 1205« (Jack Of Shadows)
___________________________

ОО пришло как раз как средство решения трудностей, возникавших в структурном программировании, и отодвинуло потолок абстракции.
ФЯ отодвигает потолок абстракции еще выше... Ну а что будет когда возможности ФЯ будут использованы на 100% и мы опять упремся в потолок абстракции, наверное не нам с вами решать.

Интересно Ваше мнение относительно потолка абстракции применительно к языку SETL. Его фундамент - теория множеств.
http://en.wikipedia.org/wiki/SETL
http://www.cs.nyu.edu/~bacon/setl-doc.html

Ответ на »сообщение 1203« (Артем)
___________________________
Если в ООП нужны паттерны для итераторов, то в ФЯ, например, та же мемоизация - это тоже паттерн, который в императиве гораздо более прозрачен.

Простите но мемоизация в ФЯ либо достигается средствами комплилятора, либо элементарна настолько что не требует никакого громозкого описания в виде патерна:

fib = ((map fib' [0 ..]) !!)
    where
      fib' 0 = 0
      fib' 1 = 1
      fib' n = fib (n - 1) + fib (n - 2)

Приведенный код - мемоизация фибоначи на хаскеле.
Попробуйте привести код мемоизации на любом ИЯ и сравните. Не удивлюсь если окажется что мемоизация на java delphi сишарп окажется более громоздкой конструкцией.


Я подозреваю, что в каждом языке есть СВОИ повторяющиеся трудности.


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

Ответ на »сообщение 1201« (Jack Of Shadows)
___________________________
Гослинг и Гай Стил отзываются о лиспе как о гравитационной черной дыре.Мол достаточно хоть что нибудь из лиспа (closures) привнести в язык, как лисп начнет тянуть в себя, и очень скоро окажется что твой язык превратился в лисп.
Приятная вырисовывается перспектива - все в сад, пардон, в черную дыру. Эдакое царство тьмы и тишины :)

Ответ на »сообщение 1202« (Jack Of Shadows)
___________________________
Я подозреваю, что в каждом языке есть СВОИ повторяющиеся трудности. Если в ООП нужны паттерны для итераторов, то в ФЯ, например, та же мемоизация - это тоже паттерн, который в императиве гораздо более прозрачен.
При смене парадигмы мы получаем и смену паттернов - и то, что казалось очевидным в ООП потребует эквилибристики в ФЯ. И не факт, что паттерны ФЯ будут легче таковых в ООП.
Другой вопрос, что до паттернов ФЯ нашие многоуважаемые "теоретики" еще не дошли, т.к. ФЯ даже  в наш "просвещенный" век - пока еще экзотика :)

И еще маленькое дополнение. В принципе, те же паттерны можно было бы ввести в какой-нибудь ООП в в виде дополнения к языку (эдакий встроенный Pattern-DSL), но это считается излишним. Да и не нужно преувеличивать сложность самих паттернов и гениальность "банды четырех" - они просто систематизировали и дали названия некоторым техническим приемам. И решения, приведенные ими - это не истина в последней инстанции; патерны с использованием интерфейсов (которых нет в C++), например, гораздо более изящны.