Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  00:03[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

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

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 1452—1443 | 1442—1433 | 1432—1423 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 407


    № 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« (Сергей Перовский)
    ___________________________
    Сборка мусора не обязательно тормозить должна. Или "подтормаживать"... В Инферно три (или четыре) механизма сборки мусора. Самый медленный (глобальный шмон) применяетсяв считанных долях процента и случаев. Для подавляющего достаточно учёта выхода их блоков различной природы и вложенности.


    <<<... | 1452—1443 | 1442—1433 | 1432—1423 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 407


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования