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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2652—2643 | 2642—2633 | 2632—2623 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 287


    № 2642   05-04-2007 01:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2639« (Max Belugin)
    ___________________________
    Многое зависит от терминологии. Если объектно-ориентированный это "язык с классами и наследованием", а  функциональный - "язык со всякими новомодными штучками", то никакого противостояния нет.
    Но если занять более консервативную позицию, можно заметить следующее:

    1. При объектном подходе процесс вычислений рассматривается как последовательная смена состояний системы, состоящей из объектов. Объектно-ориентированный язык должен обеспечивать средсва для описания состояний объектов и методов изменения состояний.

    2. При функциональном подходе процесс вычислений рассматривается как последовательность применения функций. Объекты, которыми манипулируют функции, не имеют состояний. Функциональный язык должен предоставлять только средства описания функций. Если же добавить возможнось работы с изменяемыми объектами, то функциональная модель вычислений рушится и мы переходим к случаю 1.


    № 2641   05-04-2007 00:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2638« (Trurl)
    ___________________________
    Для выяснения какая функция из какого модуля совсем необязательно перед каждым из них везде писать имя модуля. Достаточно навести на него мышку, и редактор вам покажет полное имя. Более того достаточно нажать Ctrl-Мышка и пожалуйста, редактор прыгнет прямо в тело описания этой функции.

    А какой редактор Вы используете для Haskell?


    Я вообще о редакторах говорил а не для хаскеля. В Дельфи есть авто-навигация по модулям. В Visual Studio есть, в emacs для лиспа есть, в Lispworks есть.
    В хаскелевском плагине для Visual Studio тоже есть. То есть такая функциональность для любого языка - не проблема.



    № 2640   05-04-2007 00:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2633« (AVC)
    ___________________________
    >>>>Если код на хаскеле скомпилировался без ошибок то я УВЕРЕН что в нем отсутствует конфликт имен.

    >>>Значит, Хаскель в данном пункте превосходит C#.

    Да, превосходит и C# и Delphi. Но все же проблема и здесь может возникнуть, хотя вероятность этого мала, да и последствия не такие серьезные.
    Например, мы решили добавить/изменить несколько функций. При этом нам потребовалсь функции из модуля X. Импортируем его и делаем, что хотели. Но прикомпиляции получаем сообщение о конфликте имен с модулем Y. Нет проблем - переходим к ограниченному импорту. Теперь осталось отыскать все вхождения конфликтующих функций и уточнить имена. Плохо, если у них тип совпадает.


    № 2639   05-04-2007 00:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Уважаемый Trurl. В прошлой теме вы как-то сказали что-то типа "Чем более язык функциональный тем менее он объектно-ориентированный". Не могли бы вы развить эту мысль?


    № 2638   04-04-2007 23:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2619« (Jack Of Shadows)
    ___________________________
    >>>Для выяснения какая функция из какого модуля совсем необязательно перед каждым из них везде писать имя модуля. Достаточно навести на него мышку, и редактор вам покажет полное имя. Более того достаточно нажать Ctrl-Мышка и пожалуйста, редактор прыгнет прямо в тело описания этой функции.

    А какой редактор Вы используете для Haskell?


    № 2637   04-04-2007 23:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2630« (Илья Ермаков)
    ___________________________

    Для серьезных случаев, с использованием типов данных из сторонних модулей и т.п. - важно сразу видеть, какой из модулей отвечает за ту или иную функциональность. Не при написании. При изучении, а особенно - изменении. Я уже приводил пример - разобраться в одном из крупных модулей VCL - иcщелкаетесь мышкой :-)
    Ага, ну вот узнал я, например, что класс TThread находится в модуле Classes. И что с того? Мне от этого должно стать легче?


    № 2636   04-04-2007 17:07 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2619« (Jack Of Shadows)
    ___________________________

    >>>Для выделения служебных слов не нужно заставлять программиста писать их большими буквами. С этим прекрасно справляется любой программистский редактор.

    Совершенно верно. :)
    Лично я набираю служебные слова маленькими буквами, а большими (и, при желании, подсвеченными) их делает редактор.
    Для этого редактор не обязан быть частью обероновского IDE.
    Например, в vi существует такое средство как abbr.
     AVC


    № 2635   04-04-2007 16:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2630« (Илья Ермаков)
    ___________________________

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

    Обясните мне чем sqrt(4) отличается от Math.sqrt(4)
    В плане понимания кода, ничем.


    Для примитивного примера с мат. функциями - ничем.


    Даже для "примитивного" примера с мат. функциями, IMHO, все не так просто.
    Расширяемая программная система устроена так, что в ней одновременно может существовать несколько функций sqrt.
    Мне сразу не очевидно, не приведет ли неквалифицированный импорт в таких обстоятельствах к каким-либо проблемам.
     AVC


    № 2634   04-04-2007 16:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2632« (Илья Ермаков)
    ___________________________
    Для любого знания нужен опыт. Для получения опыта нужно его приобретать. Чтобы его приобрести, нужно сначала поверить в то, что он вообще есть... Наука тоже базируется на вере. Поверь, что мир познаваем - и попробуй это делать. Набивай шишки и получай опыт. Наличие собственного опыта дает твердое знание... В итоге имеем бесконечные споры между теми, кто прошел из стадии веры до стадии знания, и теми, кто требует знания сразу, "на тарелочке".

    WOW! Наверное это мне надо было отвечать Сергею Перовскому на его запросы показать в чем преимущества ФП "в большем".

    Ну что ж, пользуясь уроком Ильи, отвечаю вам вашими де словами: Для любого знания нужен опыт. Для получения опыта нужно его приобретать. Чтобы его приобрести, нужно сначала поверить в то, что он вообще есть.
    Короче говоря, всем бегом на сайт haskell.org, скачивайте, ставьте, реализуйте проект достаточно большой, чтобы эти преимущества в большом увидеть а так же опыт наработать, и потом возвращайтесь на этот форум :))


    № 2633   04-04-2007 16:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2625« (Jack Of Shadows)
    ___________________________

    >>>Непонятный запрос. Уверенность в отсутствии конфликтов имен дает компилятор вообще то :))

    В обероновской ветке в свое время рассматривался пример из статьи Свердлова, в котором компилятор весьма современного языка (C#) не мог предотвратить конфликт имен и генерацию ошибочного кода.

    >>>Если код на хаскеле скомпилировался без ошибок то я УВЕРЕН что в нем отсутствует конфликт имен.

    Значит, Хаскель в данном пункте превосходит C#.

    >>>То же не понял. Используя нормальный IDE вы типа НЕ имеете полную принципиальную схему системы, с наглядным выделением взаимных связей ?

    В Обероне (я сейчас не рассматриваю отдельные компиляторы, вроде XDS) нет традиционного понятия программы.
    В любой момент система может быть на лету расширена новым модулем.
    И как именно я могу получить полную принципиальную схему системы, которая всегда открыта для расширения, независимо от того, каким IDE я пользуюсь?
     AVC


    <<<... | 2652—2643 | 2642—2633 | 2632—2623 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 287


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

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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