Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1442 08-11-2006 00:20 | |
Ответ на »сообщение 1440« (Сварог)
___________________________
Могу вам только посоветовать научиться читать :))
Библиотека cells позволяет связывать обьекты в языке. Для того чтобы прочитать данные с БД драйвер конечно же нужен.
Это вот что вы будете делать с данными ПОСЛЕ того как вы прочитаете их с БД - это где вам может помочь cells.
Ближайшим аналогом cells для дельфи будет связка
TDataSet <-> TDataSource <-> Свойство DataSource визуального обьекта <-> Внутрення процедура написанная автором компонента для использования этого свойства.
Как видите драйверами для доступа к БД тут и не пахнет.
Это уже на значительно более позднем этапе.
Преимущество функционального программирования заключается в том что всю эту длинную, громоздкую цепочку которая к тому же работает только там где вы это явно предусмотрите, заменяет одна билиотека cells, которая работает с ЛЮБЫМИ ОБЬЕКТАМИ.
Надеюсь я достаточно мелко разжевал, чтобы господину Сварогу опять в этой кашице драйвера БД не привиделись :))
№ 1441 07-11-2006 23:35 | |
Ответ на »сообщение 1436« (Сергей Перовский)
___________________________
Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.
Во вторых это TAction с его onAction и onUpdate.
Как раз наоборот. В Delphi я вынужден писать обработчик OnUpdate, в котором надо присвоить значение в свойство Enabled соответствующего действия.
Вы никогда не ошибались с идентификатором действия? А с тем, что если забыть выполнить присваивавание, то компилятор даже теоретически не сможет Вас предупредупредить?
Мне это очень мешает. Функция, которую я мог бы указать для определения значения Enabled была бы намного удобнее. Да еще бы и компилятор предупреждал, что в одной из ветвей алгоритма я забыл возвратить результат (присвоить Result).
То же самое с вычисляемыми полями. OnCalcFields провоцирует на ошибки. Даже язык формул Excel в ряде случаев оказывается намного удобнее, чем вычисляемые поля в Delphi.
№ 1440 07-11-2006 22:17 | |
Честнслово, сообщения Jack Of Shadows из мира функционального программирования я читаю прямо как книги Мулдашева о Шамбале. В каждом посте – сплошные чудеса!
Вот и сейчас оказалось, что существует Святой Грааль... тьфу, библиотека cells, которая способно подключить любую БД безо всяких драйверов!
№ 1439 07-11-2006 14:37 | |
Ответ на »сообщение 1436« (Сергей Перовский)
___________________________
Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.
Ошибаетесь.
Давайте рассмотрим на примере.
Прежде всего вам доступно "навешивание" функций только в точках о которых позаботился создатель компонента.
То есть это либо event handlers типа OnCLick, OnChange, которые должны быть явно предусмотрены создателем компонента. Если нет - вам не повезло.
Или же это должны быть специальные свойства (property) типа DataSource, опять же явно предусмотренные создателем. Если нет - то вам опять не повезло.
Скажем для того чтобы в editbox отображалось значение поля из таблицы - вам нужно свойство DataSource.
А вот если бы Delphi был поноценным функциональным языком, то для него можно было бы портировать вот эту вот библиотеку cells, которая дала бы вам следующие возможности.
myEditBox1.Text := ?f: qryMyTableFirstName.Value;
ВСЕ!! Никаких DataSource от Борланд! Никаких специальных db-aware компонент! Никаких "Вам придется написать TDataSet для вашей базы данных потому что в коробке поставляются только TDataSet для odbc, оракла и парадокса".
Естественно такое вот ДЕКЛАРИРОВАНИЕ СВЯЗЕЙ не ограничивается одними только визуальными компнонентами.
Например:
Logger.SendWarningEmail := ?f: Engine.Temperature > 150;
Или
StatusBar.Position := ?f: FTPDownload.BytesDownloaded / FTPDownload.FileSize;
Или
MenuItemFileSave.Enabled := ?f: CurrentFile.isDirty;
Сравните это с количеством и главное сложностью кода которое приходится писать в Дельфи, для обеспечения взаимодействия разнородных обьектов.
№ 1438 07-11-2006 13:44 | |
Ответ на »сообщение 1421« (Артем)
___________________________
Операции присваивания вас погубят!
Артем, не юродствуйте. Вы же можете вполне конструктивно вести дискуссию.
Ваш пост откровенная провокация.
Невправильное обучение может дествительно погубить в человеке программиста.
Эта мысль поддерживается всеми школами, как императивной так и фнукциональной.
Более того и методика одна и таже - оградить студента от знакомства с "лишними" "опасными" "ненужными" вещами.
Разница в частностях, в том кто и что считает "лишним" "опасным" "ненужным".
№ 1437 07-11-2006 13:05 | |
Ответ на »сообщение 1436« (Сергей Перовский)
___________________________
Прописывать формулы прямо в ObjectInspectore красиво, но ведь это все равно DesignTime, можно и метод перекрыть.
Под формулами подразумеваются функции. Они совершенно не обязательно должны быть однострочными.
Впрочем, может быть я чего-то недооцениваю.
Эт точно. Чтобы оценить попробуйте использовать обычные editbox и обычный grid (не db-aware) в дельфи с каким нибудь внешним источником данных..
Сразу поймете, что если дядя (в данном случае Борланд) не предусмотрит для вас соответствующий механизм, то придется все делать самому ручками.
А библиотека cells навешивает такой механизм на ЛЮБОЙ класс, даже если он написан не вами, даже если у вас и исходников то нет.
То есть нужда в СПЕЦИАЛЬНО написанных db-aware components отпадает. И не только.
Скажем вам нужно чтобы grid показывал список обьектов из обьектной базы данных.
Оба на! db-aware controls не расчитаны на работу с обьектными БД.
ВОт и получается что вы внезапно остаетесь без удобного инструмента и у вас только один выход - делать его самому.
Библиотека cells прекрасно показывает насколько наши представления о легкости написания GUI на ОО языках надуманны и беспочвенны.
Легкость нам обеспечивают громодкие и дорогие механизмы, построенные для нас дядями с толстыми кошельками, то есть Дельфи IDE от Борланд и VS от Microsoft.
При этом механизмы эти весьма узко-специфичны. Шаг влево или вправо, и они отказываются работать, бросают вас на произвол судьбы, становятся бесполезными.
MS например доперла до этого после первой версии dotnet и во второй доделала механизм синхронизации визуальных компонент с источниками данных. Теперь этот механизм позволяет подключать не только таблицы с реляционных бах данных, но и просто списки обьектов.
Этого пришлось ждать аж целых 4 года. Но даже это усовершенствование все равно остается узкоспецифичным.
Просто потому что этот механизм работает НЕ СО ВСЕМИ классами, а только с теми о которых позаботилась MS.
Для остальных вам придется корячиться и писать специальные адаптеры.
Сравните это с теми возможностями которые дает вам одна маленькая и бесплатная библиоека cells, которую в течении нескольких месяцев разработал всего один человек.
Разве он умнее огромной армии программистов MS и Борланд ?
Нет конечно. Просто у него в руках инструмент, позволяющий делать такие чудеса.
У него в руках ФЯ.
А программисты Борланд и MS вынужденны создавать огромные, громоздкие машины, как будто сошедшие с иллюстраций к книгам Жюля Верна.
Динамическое взаимодействие разнородных обьектов, то есть как раз все эти задачи отображения и синхронизации некоего набора данных на их визуальное представление - прекрасный пример того насколько неуклюжим ялвяется императивный ОО подход для этого класса задач.
Например широко разлекламированная система ECO (бывший Bold) от Борланд - та вообще со своим набором визуальных контролов приходит. Цирк просто. Каждому обьектному OO framework - свой набор визуальных обьектов. Почему ? Ах, взаимодействие и ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ очень тяжело оказывается организовать. :))
№ 1436 07-11-2006 11:20 | |
Ответ на »сообщение 1435« (panda)
___________________________
Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.
Во вторых это TAction с его onAction и onUpdate.
Прописывать формулы прямо в ObjectInspectore красиво, но ведь это все равно DesignTime, можно и метод перекрыть.
Если речь идет о синхронном присваивании текстовых значений, то такую систему я для своих проектов давно реализовал.
Впрочем, может быть я чего-то недооцениваю.
№ 1435 07-11-2006 10:44 | |
Ответ на »сообщение 1434« (Сергей Перовский)
___________________________
Ну, раз в функциональные языки приходится добавлять возможности императивного программирования, значит их авторы со мной согласны - функциональное программирования лучше не во всех случаях. Тогда вопрос - в каких?
Мне очень понравилась идея описанная здесь: »сообщение 313«
Захотелось ее даже применить в своем инструменте разработки.
№ 1434 07-11-2006 10:16 | |
Ответ на »сообщение 1429« (panda)
___________________________
Ребята, давайте жить дружно (с).
Я ничего обидного в цитируемом сообщении не вижу. И не только в Ваш адрес оно написано.
Непонимания тут и так хватает. Давайте не усугублять.
К вопросу о простых и сложных примерах: хотелось бы НЕ ПРИМЕРОВ, а корректного анализа.
Тут постоянно смешиваются темы. То обсуждаем функциональный подход, то функциональные языки. Причем без явного указания.
Получается странный диалог:
-Есть случаи, когда функциональный подход неудобен...
-Так в хаскеле можно программировать императивно!
Ну, раз в функциональные языки приходится добавлять возможности императивного программирования, значит их авторы со мной согласны - функциональное программирования лучше не во всех случаях. Тогда вопрос - в каких?
№ 1433 07-11-2006 10:15 | |
Ответ на »сообщение 1427« (Сергей Перовский)
___________________________
Сборка мусора не обязательно тормозить должна. Или "подтормаживать"... В Инферно три (или четыре) механизма сборки мусора. Самый медленный (глобальный шмон) применяетсяв считанных долях процента и случаев. Для подавляющего достаточно учёта выхода их блоков различной природы и вложенности.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|