Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2652 05-04-2007 03:08 | |
Ответ на »сообщение 2650« (Jack Of Shadows)
___________________________
Позвольте нам решать, ладно ?
Конечно, же решайте. Моя задача поделиться опытом Оберона и указать на проблемы, которые всплыли в Хаскеле. Ээти проблемы были и в Модуле-2 (делюсь своим опытом -- не интересно, ради Бога), но в меньшей степени -- ибо там всегда при неквалифицирующем импорте требовалось явно перечислять импортируемые сущности, что при длинном списке просто подталкивало к квалифицирующему импорту.
Ваше дело слушать или игнорировать. Разумеется. Никому ничего не навязываю. Хотите думать -- думайте. Нет -- не надо.
№ 2651 05-04-2007 03:07 | |
Ответ на »сообщение 2648« (Илья Ермаков)
___________________________
Если Вы полезете в VCL для того, чтобы "дернуть" и портировать оттуда какой-то код (а я тогда полез именно затем - за реализацией прозрачности битмапов) - то Вам от этого действительно станет гораздо легче...
Когда (а не если) я заглядываю в VCL, чтобы позаимствовать оттуда реализацию какой-либо функциональности, я использую Ctrl+мышь. Компьютер справляется с поиском и открытием файла Classes.pas намного быстрее любого программиста.
"Человек должен думать, машина - работать" (с) не мое.
№ 2650 05-04-2007 03:04 | |
Ответ на »сообщение 2645« (Руслан Богатырев)
___________________________
Two words for you: Stack trace :))
Руслан, если у меня в дельфи где то что то не работает и вылетает ошибка, то я получаю номер строчки и название файла где эта ошибка произошла.
Кстати тоже самое и в java и в сишарп. Это без всяких дебагеров и assert-ов.
Как видите средства доступные нам, прекрасно помогают в локализации источника проблемы и быстром устранении неисправности.
Вы тут нам так рьяно взялись рассказывать как МЫ наступаем на грабли, что позабыли спросить у нас. А были ли грабли ? :))
Позвольте нам решать, ладно ? Тех кто обнаружит у себя на лбу шишки от грабель неквалифицирующего импорта, bs сразу направим к вам в палату оберона на лечение.
А здесь на лечении находятся те у кого шишки от грабель размазанного по всему приложению состояния.
Вы не в ту палату зашли :))
№ 2649 05-04-2007 03:03 | |
Ответ на »сообщение 2645« (Руслан Богатырев)
___________________________
Частенько удивляются, почему Оберон-программисты так редко прибегают к отладке, а обычно обходятся точками контроля инвариантов (ASSERT) или анализом дампа. А на отсеки-то уже все разбито и локализация производится очень быстро. Нет неквалифицирующего импорта -- нет и стимула для размывания ответственности.
Частенько удивляются, почему хорошие программисты пишут модульные тесты...
Думаю, дальше продолжать не надо? Если бы Oberon стал "серебряной пулей" мы бы сейчас обсуждали совсем другие вопросы.
№ 2648 05-04-2007 02:39 | |
Ответ на »сообщение 2637« (panda)
___________________________
Ответ на »сообщение 2630« (Илья Ермаков)
___________________________
Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?
Если Вы полезете в VCL для того, чтобы "дернуть" и портировать оттуда какой-то код (а я тогда полез именно затем - за реализацией прозрачности битмапов) - то Вам от этого действительно станет гораздо легче...
Что хоть за отношение к коду... нехозяйское какое-то :-) Написать - и все равно, что с чем там связано и где лежит...
№ 2647 05-04-2007 02:37 | |
Ответ на »сообщение 2645« (Руслан Богатырев)
___________________________
>>>Не зря в конце книг с давних пор приводят различные указатели (предметный, имен и т.п. с отсылками на точки локализации -- страницы). Хотя желающие могут генерировать свои гипотезы и каждую из них проверять полнотекстовым поиском в всем тексте книги. А что -- тоже подход.
Немецкий историк Моммзен утверждал: "Das Buch ohne Index ist kein Buch".
Так что у квалифицированного импорта долгая история. :)
№ 2646 05-04-2007 02:28 | |
Ответ на »сообщение 2644« (Geniepro)
___________________________
Осталось только так сильно обжечься на подобной ситуации, что бы это стало действительно серьёзным доводом, и заставлять разработчиков использовать только квалифицированный импорт, что очень легко контролировать (по наличию только import qualified без простого import)... :о)
И получится как в Обероне? ;)
№ 2645 05-04-2007 02:27 | |
Ответ на »сообщение 2637« (panda)
___________________________
Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?
Интересно. Даже не ожидал, что такая проблема вскроется на ровном месте. Хотя понятно, что схема "квалифицирующий-неквалифицирующий импорт" роднит Haskell и Delphi. Хорошо, попробую объяснить свое понимание того, почему Вирт, наступив на эти грабли в Модуле-2, принял другое решение в Обероне. Тогда как другие языки и их пользователи продолжают на них с недоумением наступать.
Итак, для многих импорт из сторонних модулей есть средство включения внешних возможностей в свою программу/модуль. Разумеется, если мы смотрим на это с позиции синтеза программы (т.е. потребителей чужого кода), то нам хочется минимизировать свои проблемы: узнать, что подключить, чтоб былО. При этом, как верно подметил Geniepro, нет желания явно указывать каждую точку "заимствования" -- не красиво, текст увеличивается. Если есть выбор: квалифицирующий -- неквалифицирующий, то (это показал и многолетний опыт Модулы-2) будут выбирать путь наименьшего сопротивления -- неквалифицирующий импорт. Так сейчас (в данный момент написания программы) проще, а последствия -- они еще когда будут.
Это, кстати, чем-то напоминает практику использования чужой информации без указания источника. Если источник не указан (материал пересказан/заимствован автором и не знаешь, то ли его мысль, то ли откуда взял), возникает проблема достоверности. Она наступает тогда, когда важно принимать решение относительно того, доверять данной информации или нет (и в какорй степени, какая требуется проверка и каких источников).
Импорт есть заимствование. Нет необходимости выяснять достоверность -- не важен источник. Лишь бы работало.
Теперь посмотрим на ситуацию с позиции не синтеза, а анализа программы. Когда в нем возникает потребность? Самый простой случай -- что-то где-то не работает. Значит, ставится задача локализовать источник проблемы, чтобы устранить неисправность. Другой распространенный случай -- модификация работающей программы (самим автором спустя продолжительное время или же третьим лицом, который впервые видит чужой исходный текст). Чтобы провести модификацию, надо сначала выявить контекст исполнения. Т.е. решить обратную задачу -- построить карту зависимостей с локализацией взаимного влияния сущностей. Иначе тронешь -- и все может развалиться. А еще хуже -- пойдут наведенные эффекты, которые сразу и не всплывут, а дадут о себе знать по закону подлости в самый неподходящий момент (за несколько дней до сдачи проекта, либо вообще в ходе эксплуатации).
Вот, кстати, на чем еще вскрываются проблемы ООП: полиморфизм, "делегирование" ответственности вышестоящим классам размывает контекст. То, что хорошо работало для сокращения синтеза, начинает проявлять все свои болячки на этапе анализа. За все, как известно, надо платить: пытаемся сэкономить на конкретике, вводя обобщения и умолчания-делегирования -- размывается ответственность. Становится сложнее локализовать неисправность.
Как решает задачи локализации мэйнстрим? Правильно -- трассировкой и отладкой. Не буду вдаваться в обсуждение того, что как тестирование, так и отладка -- это видимость благополучия. Ибо программа задает целый класс вычислений и, как правило, нет физической возможности все до единого варианта перепроверить. Что остается? Анализировать правильность конструкций и композиций сущностей. Четко знать степень ответственности каждого элемента и иметь возможность, как в подлодке, решать задачу непотопляемости за счет разбиения на герметизированные отсеки.
Частенько удивляются, почему Оберон-программисты так редко прибегают к отладке, а обычно обходятся точками контроля инвариантов (ASSERT) или анализом дампа. А на отсеки-то уже все разбито и локализация производится очень быстро. Нет неквалифицирующего импорта -- нет и стимула для размывания ответственности.
Относительно нивелирования проблемы за счет средств инструментария. Зачем порождать проблему, чтобы потом ее героически решать? Ключевым в программировании является человеческий фактор. Работа минером (щупать, к чему та или иная сущность относится, вместо явной таблички с надписью "заминировано") -- не самый лучший вариант для программиста. Ему хотя бы отличить даже внутренние вещи от внешних и стандартных -- уже была бы польза. А когда все едино -- напоминает принцип "что твое, то и мое, а что мое -- то ты не трожь". Для выяснения в словаре наличия тех или иных слов можно каждый раз "переспрашивать" (делать запросы), а можно просто посмотреть списочек (целый фрагмент). Не зря в конце книг с давних пор приводят различные указатели (предметный, имен и т.п. с отсылками на точки локализации -- страницы). Хотя желающие могут генерировать свои гипотезы и каждую из них проверять полнотекстовым поиском в всем тексте книги. А что -- тоже подход.
Для тех, кто пишет одноразовые или неотчуждаемые вещи (т.е. сам писатель, сам читатель), это все выглядит надуманной проблемой (равно как и для людей, привыкших изучать информацию без знания источника -- он им за ненадобностью). Коллективная безответственность существует до тех пор, пока всех устраивает. А вот когда дело доходит до точки кипения -- люди начинают задумываться, что без введения персональной ответственности бардак как был, так и будет продолжаться. Что в жизни, что в программировании.
№ 2644 05-04-2007 02:16 | |
Ответ на »сообщение 2640« (Trurl)
___________________________
Например, мы решили добавить/изменить несколько функций. При этом нам потребовалсь функции из модуля X. Импортируем его и делаем, что хотели. Но прикомпиляции получаем сообщение о конфликте имен с модулем Y. Нет проблем - переходим к ограниченному импорту. Теперь осталось отыскать все вхождения конфликтующих функций и уточнить имена. Плохо, если у них тип совпадает.
Эта проблема, конечно, понятна, но серьёзна она тогда, когда квалификацией имён функций занимается не разработчик модуля (который скорее всего ещё помнит, из какого модуля он вначале импортировал ту или иную функцию), а какой-то совсем посторонний человек. Тогда ему нужно будет обратиться к документации, истории разработки тех сторонних модулей, в конце концов просто по смыслу понять где какая функция должна быть.
Это, конечно, неудобство, но с помощью так любимого нашими оберонщиками "грамотного проектирования" можно всё это предотвратить при желании...
Осталось только так сильно обжечься на подобной ситуации, что бы это стало действительно серьёзным доводом, и заставлять разработчиков использовать только квалифицированный импорт, что очень легко контролировать (по наличию только import qualified без простого import)... :о)
№ 2643 05-04-2007 02:06 | |
Ответ на »сообщение 2642« (Trurl)
___________________________
Объекты, которыми манипулируют функции, не имеют состояний.
Обьект не имеющий состояния это нонсенс. Так что можно сказать что функции оперируют не обьектами а кортежами (tuples). Которые представляют собой неизменяемые структуры данных.
И соединить функциональное и ОО программирование никак нельзя. Разве что только как внешние системы обменивающиеся сообщениями.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|