Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 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 | |
Поймал себя вот на какой мысли.
В некоторые популярные ИТ-издания иногда направляют статьи авторы (сам в такой роли выступал), привыкшие к строгости академической форме материала. Т.е. когда надо обязательно дать ссылки на конкретные источники, чтобы было удобно разбираться и потом не обвиняли в плагиате/перевирании/додумывании. Так вот эти авторы недоумевают, почему под нож идут их ссылки (обычно все). Не принято в популярных изданиях нагружать читателей "ненужными" ссылками. Да и формат там другой. Нужна просто информация, главное, чтобы было интересно (а что и откуда -- разбирайтесь потом сами).
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|