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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2702—2693 | 2692—2683 | 2682—2673 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 282


    № 2692   05-04-2007 12:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2689« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2688« (Jack Of Shadows)
    ___________________________
    А ведь я обшибся :)) Как раз в обероне при смешивании integer и Real произойдет неявное преобразование типов.

    Только от целого к вещественному, без потерь.
    Простое правило: BYTE <= SHORTINT <= INTEGER <= SHORTREAL <= REAL.
    В сторону от меньшему к большему преоборазование автоматическое.
    Мне больше нравится подход Ады - вообще без неявных преоборазований.
    Однако надо понимать, что здесь просто разные уровни типизации атомарных данных.
    В Обероне четко и полностью воплощен уровень математической типизации ("тип данных = множество значений + допустимые операции"), более низкий уровень технической типизации ("тип данных - представление данных в память") полностью скрыт.
    В Аде для атомарных данных воплощен следующий уровень типизации - асбтрактный или прикладной ("тип данных = содержательная роль данных в программе"), поддерживается расширение атомарных типов, субтипизация, явное определение того, что с чем совместимо и т.п.
    Однако Ада не поддерживает компонентное программирование, и ввести эту поддержку сложно - не только из-за перечислений, а в целом из-за механизма атомарной абстрактной типизации. В Обероне абстрактная типизация и расширение типов воплощено последовательно для записей.
    В общем, за все приходится платить, выбирать компромиссы.

    Интересно, а какой уровень типизации в Хаскелле? Для атомарных данных и для структур? Где математическая, а где - абстрактная?


    № 2691   05-04-2007 12:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Наткнулся только что в Блэкбоксе на модуль Integers и пример его использования для вычисления факториала с произвольной точностью ObxFact...

    MODULE ObxFact;
    (**
      project  = "BlackBox"
      organization  = "www.oberon.ch"
      contributors  = "Oberon microsystems"
      version  = "System/Rsrc/About"
      copyright  = "System/Rsrc/About"
      license  = "Docu/BB-License"
      changes  = ""
      issues  = ""
    **)
      IMPORT
          Stores, Models, TextModels, TextControllers, Integers;

      PROCEDURE Read(r: TextModels.Reader; VAR x: Integers.Integer);
          VAR i, len, beg: INTEGER; ch: CHAR; buf: POINTER TO ARRAY OF CHAR;
      BEGIN
          r.ReadChar(ch);
          WHILE ~r.eot & (ch <= " ") DO r.ReadChar(ch) END;
          ASSERT(~r.eot & (((ch >= "0") & (ch <= "9")) OR (ch = "-")));
          beg := r.Pos() - 1; len := 0;
          REPEAT INC(len); r.ReadChar(ch) UNTIL r.eot OR (ch < "0") OR (ch > "9");
          NEW(buf, len + 1);
          i := 0; r.SetPos(beg);
          REPEAT r.ReadChar(buf[i]); INC(i) UNTIL i = len;
          buf[i] := 0X;
          Integers.ConvertFromString(buf^, x)
      END Read;

      PROCEDURE Write(w: TextModels.Writer; x: Integers.Integer);
          VAR i: INTEGER;
      BEGIN
          IF Integers.Sign(x) < 0 THEN w.WriteChar("-") END;
          i := Integers.Digits10Of(x);
          IF i # 0 THEN
            REPEAT DEC(i); w.WriteChar(Integers.ThisDigit10(x, i)) UNTIL i = 0
          ELSE w.WriteChar("0")
          END
      END Write;

      PROCEDURE Compute*;
          VAR beg, end, i, n: INTEGER; ch: CHAR;
            s: Stores.Operation;
            r: TextModels.Reader; w: TextModels.Writer; attr: TextModels.Attributes;
            c: TextControllers.Controller;
            x: Integers.Integer;
      BEGIN
          c := TextControllers.Focus();
          IF (c # NIL) & c.HasSelection() THEN
            c.GetSelection(beg, end);
            r := c.text.NewReader(NIL); r.SetPos(beg); r.ReadChar(ch);
            WHILE ~r.eot & (beg < end) & (ch <= " ") DO r.ReadChar(ch); INC(beg) END;
            IF ~r.eot & (beg < end) THEN
                r.ReadPrev; Read(r, x);
                end := r.Pos(); r.ReadPrev; attr :=r.attr;
                IF (Integers.Sign(x) > 0) & (Integers.Compare(x, Integers.Long(MAX(LONGINT))) <= 0) THEN
                  n := SHORT(Integers.Short(x)); i := 2; x := Integers.Long(1);
                  WHILE i <= n DO x := Integers.Product(x, Integers.Long(i)); INC(i) END;
                  Models.BeginScript(c.text, "computation", s);
                  c.text.Delete(beg, end);
                  w := c.text.NewWriter(NIL); w.SetPos(beg); w.SetAttr(attr);
                  Write(w, x);
                  Models.EndScript(c.text, s)
                END
            END
          END
      END Compute;

    END ObxFact.


    Люди! Оберонщики! Неужели для вас такие портянки - это нормально??? :о))


    № 2690   05-04-2007 12:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2685« (Geniepro)
    ___________________________

    Я взялся за программирование всего около полугода назад, ...

    Упс! Я имел в виду - за функциональное программирование... :о))


    № 2689   05-04-2007 12:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2688« (Jack Of Shadows)
    ___________________________
    в хаскеле работает точно также как и в обероне.
    Попробуйте в одном выражении применить два типа Integer и Real - получите сообщение об ошибке, а не явное преобразование типов.


    А ведь я обшибся :)) Как раз в обероне при смешивании integer и Real произойдет неявное преобразование типов.
    Как там Руслан говорил ? "Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит." :))


    № 2688   05-04-2007 12:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2679« (Руслан Богатырев)
    ___________________________
    Руслан, ваif просветительсякая работа по квалифицирующему импорту была дружно встречена в штыки не только функциональщиками но и многими императивщиками.
    Нам не нужен ОБЯЗАТЕЛЬНЫЙ квалифицирующий импорт. Смиритесь с этим фактом, и давайте закруглять то что никого здесь не интересует.
    Коментировать больше эту тему я не буду, но замечу некоторые передергивания которые к импорту не относятся:

    Замечательно, когда для программиста разницы между языком программирования и "костылями" инструментальной среды (IDE) практически нет.

    Передергивание, Для вас IDE костыль. Для нас полезный инструмент. Неважно что мы подразумеваем под IDE - VisualStudio или Emacs.



    Кто-то написал некий модуль и переслал его коллеге (наш случай с Geniepro). Коллега может не иметь всех тех настроек среды (и той же среды), ему нужен аккуратно отчужденный исходник (со всеми буковками) в текстовом виде (особенно, ежели в дороге, что может быть и равносильно случаю, когда кто-то обращается к исходнику спустя, скажем, лет 5).


    Так я и знал. Все печетесь о тех кто в notepad работает.
    Руслан, мы уже вам один раз говорили. Можем повторить. Нам НАПЛЕВАТЬ не тех кто работает в notepad/ Это их проблемы. Пусть пользуются нормальной средой. Не могут - пусть плачут, или уходят в оберон. Никто вслед им плакать не будет.


    Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит.


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

    За сим все. Нам не интересно. Про квалифицирующий импорт можете здесь дальше не продолжать.


    № 2687   05-04-2007 12:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2664« (Руслан Богатырев)
    ___________________________

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

    По сравнению с тем какие возможности по анализу кода дает хаскель

    Вполне допускаю, даже убежден, что может и должен. Было бы интересно узнать (здесь достаточно даже просто ссылок) о работах по доказательному программированию применительно к Хаскелю.

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

    Тем не менее, это не является большой проблемой для Хаскелла, поскольку программы на Хаскелле в основном являются набором уравнений, каждое из которых достаточно маленькое, что бы быть убедительно правильным. К тому же все эти уравнения могут начинаться с проверки предусловий - охран (guards). В сочетании с сильной статической типизацией это даёт высокую уверенность в корректности программ.
    Хотя, конечно, когда алгоритм толком неизвестен и придумывается по ходу написания программы или известен, но неверен, от ошибок никто не застрахован...

    Некоторые элементы Хаскелла всё-таки были формализованы, например, система модулей Хаскелла:
    I. Diatchki, M. Jones, T. Hallgren, "A Formal Specification of the Haskell 98 Module System"

    А вот отчёт о формализации и верификации микроядра прототипа ОС, написанной на Хаскелле, а затем переведённой на Си (в целях максимального повышения производительности):
    K. Elphinstone, G. Klein, R. Kolanski, "Formalising a High-Performance Microkernel"

    Из проекта Programatica, где, в частности, сделали ОС House на Хаскелле:
    Dick Kieburtz, "Strategies for Verification"
    Richard B. Kieburtz, "P-logic: property verification for Haskell programs

    Довольно много подобных работ связано с языком Clean, весьма похожем на Хаскелл. Вот некоторые из них:
    M. Tejfel, Z. Horvath, T. Kozsik, "Defining and Proving Invariants of Clean Programs" и Презентация к ней
    M. Tejfel, Z. Horvath, T. Kozsik, "Proving Invariants of Functional Programs"
    Z. Csornyei, Type Systems and Program Verification

    Работа, связанная с Эрлангом:
    Thomas Arts et al. "Testing Implementations of Formally Verified Algorithms"

    Без ориентации на какой-то язык:
    Nikolaj Popov, "Functional Program Verification in Theorema"

    Немного не в тему, но всё-таки:
    Майлингова О. Л., Манжелей С. Г., Соловская Л. Б. "Прототипирование программ на языке Scheme"


    № 2686   05-04-2007 11:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2684« (Geniepro)
    ___________________________

    Ответ на »сообщение 2670« (AVC)
    Противоречие не между ФП и децентрализацией поведения, а между ФП и недетерменированностью поведения ООП и динамических компонентных систем.
    А децентрализация состояния - так ли уж действительно она необходима в системах, где запрещён разгул изменений состояния?

    Разгул изменений состояния был запрещен уже даже в строгой структурной парадигме в ИП... Нет "состояния вообще", есть строго локализованное состояние модулей, "микромодулях" - объектах и активациях процедур... В ИП есть понятие выражение и оператора. Первое не меняет состояния, второй как раз-таки предназначен для прямого переключения состояния. ФП исключает операторы, строит программы только на выражениях. Переключения состояния прячутся внутрь "автоматической коробки передач" - рантайма. Очень удобно и красиво для задач на обработку данных, в которых вся суть - в выражениях-соотношениях, а операторы - досадный "мусор", от которого хочется избавиться. Есть задачи, для которых вся суть сконцентрирована в операторах и переходах состояний, а вычисления встречаются "вкраплениями" и могут быть реализованы все теми же выражениями. Если я для своих задач откажусь от использования операторов, мне придется писать "выражения-намеки", которые заставляли бы "автоматическую коробку" совершать те же переходы состояний, которые я сейчас описываю напрямую.

    По поводу недетерминированности - извините, ерунда какая-то. У автомата есть конечное множество состояний и переходов, входная цепочка данных дереминирует последовательность выполнения переходов...
    В чем недетерминированность?


    № 2685   05-04-2007 10:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2653« (Руслан Богатырев)
    ___________________________

    Во-вторых, неоднократно говорил и буду говорить -- в Обероне главную роль играют модули. Это его главная ценность. Она же являются и его ахиллесовой пятой.

    Вы так часто это повторяете, что даже заинтриговали! :о))
    Любопытно, что это за проблема и может ли она повториться в Хаскелле?


    Что Вы могли бы сказать о ФП в отношении программирования в большом (в том числе для задач конструирования/моделирования/макетирования)? Желательно сразу не отсылать к источникам, а сформулировать видение/позицию своими словами.

    Боюсь, я Вас разочарую... Я взялся за программирование всего около полугода назад, к тому же несколько первых месяцев метался между разными ФЯ, пока не выбрал наконец чистый статический ленивый Хаскелл и гибридный динамический энергичный Scheme - два полярных взгляда на ФП...

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


    № 2684   05-04-2007 10:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2670« (AVC)
    ___________________________

    Осталось только так сильно обжечься на подобной ситуации, что бы это стало действительно серьёзным доводом, и заставлять разработчиков использовать только квалифицированный импорт, что очень легко контролировать (по наличию только import qualified без простого import)... :о)


    И получится как в Обероне? ;)

    Не совсем. Одно отличие всё-таки останется - так называемый инвертированный импорт, о котором недавно рассказывали Вы с Ильёй Ермаковым. Если в Оберонах можно менять состояние импортированных модулей, то в Хаскелле нельзя (по крайней мере законными средствами языка).

    Подобные действия могут быть полезны для быстрого макетирования программ с изменением (правкой) модулей на горячую. Но это вносит недетерменированность поведения, что несовместимо с принципами чистого функционального программирования, да ещё и ленивого...


    Я неоднократно пытался поднять вопрос о противоречии между ФП и децентрализацией, присущей ООП и динамической модульности; ссылался на SICP и т.д.

    Противоречие не между ФП и децентрализацией поведения, а между ФП и недетерменированностью поведения ООП и динамических компонентных систем.
    А децентрализация состояния - так ли уж действительно она необходима в системах, где запрещён разгул изменений состояния?

    (Напомню, что в разделе 3.1.2 книги SICP приводятся аргументы в пользу присваивания.)
    Охотно допускаю, что я здесь ошибаюсь; но, как мне кажется, я ни разу не получил удовлетворительного ответа на свой вопрос.

    Как, разве Вас не удовлетворил мой ответ, что при всём уважении к SICP эта книга не есть истина в последней инстанции? :о))


    № 2683   05-04-2007 09:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Поймал себя вот на какой мысли.

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


    <<<... | 2702—2693 | 2692—2683 | 2682—2673 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 282


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

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

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

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

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

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