Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1302 21-09-2006 04:51 | |
Ответ на »сообщение 1301« (torvic)
___________________________
>>>имеет смысл реализовывать идеи и концепции, создавая вариации на тему, заточенные под конкретную платформу
И выбрасывать все наработки при переходе к другой платформе?
Давайте посмотрим в будущее: системы команд и архитектура процессоров не вечны , ОС не вечны, "платформы" не вечны ... и нужно минимизировать потери на переходах. Собственно это и было одной из причин создания высокоуровневых языков: алгоритмы живут гораздо дольше платформ.
Это еще один камень в огород .НЕТ - выбрасывайте ваши прежние наработки на Паскале, Лиспе и т.д. и т.п. и все за решетку (#).
№ 1301 21-09-2006 02:35 | |
Ответ на »сообщение 1299« (Jack Of Shadows)
___________________________
реализация стандартов лиспа, хаскеля, питона ... под дотнет или яву
это тупиковый путь
имеет смысл реализовывать идеи и концепции, создавая вариации на тему, заточенные под конкретную платформу
собственно все этим путём и идут - f#, nemerle, ironpython, boo, scala, groovy
№ 1300 21-09-2006 02:11 | |
Ответ на »сообщение 1299« (Jack Of Shadows)
___________________________
У лиспа ведь своя VM и тоже нехило жрет память.
ИМХО, "толстая" RTL это еще не VM. Уж если браться рекламировать Лисп, такие терминологические вольности недопустимы, так как автоматически (причем совершенно беспочвенно) отсекают тех, кого VM не устраивает.
Основным недостатком из за которого ООБД проиграли реляционным, было то что они жестко привязаны к типам в конкретном языке.
Сохранил обьекты на delphi, не можешь прочитать их из java.
http://www.versant.com/en_US/products/objectdatabase
>>>Transparent object persistence from C++ and Java
Не буду утверждать наверняка (с этой штукой не работал), но весьма высока вероятность того, что одна и та же БД одновременно доступна приложениям, написанным на любом из этих языков.
ИМХО, один из очевидных вариантов добиться такого эффекта --- реализовать взаимодействие клиентского приложения с ООСУБД по аналогии с CORBA (IDL + stubs + стандартизация языковых привязок), без привлечения .Net.
№ 1299 20-09-2006 19:38 | |
Ответ на »сообщение 1296« (Сергей Перовский)
___________________________
dotnet отличная идея, которая давно напрашивалась. К сожалению реализация действительно сделана по принципу "Все для фронта, все для победы". Победы сишарп разумеется. Остальное гори оно синим пламенем.
Какие проблемы решает dotnet ?
1. Единая виртуальная машина.
Скажем если вызывать dotnet библиотеки из лиспа, то получается запуск 2-х виртуальных машин из за одной программы. У лиспа ведь своя VM и тоже нехило жрет память.
Если все языки под dotnet, то и VM запускается один раз.
2. Единое пространство библиотек. Никаких тебе FFI (foreign function interface)
Значит из любого языка доступно все богатство библиотек dotnet без всяких дополнительных инструментов.
3. Единое поле типов
В настоящее время даже если при помощи FFI подключать в язык чужие библиотеки, все равно надо еще и типы преобразовывать. Туда и обратно.
В dotnet независимо от языка типы одни и те же. Не нужно никакого преобразования
4. Из предыдущего пункта вытекает еще одно преимущество. Обьектно-Ориентрированные БД !! Наконец то!!
Основным недостатком из за которого ООБД проиграли реляционным, было то что они жестко привязаны к типам в конкретном языке.
Сохранил обьекты на delphi, не можешь прочитать их из java.
Благодаря единому полю типов стало возможным записывать и читать из ООБД на любом dotnet языке.
К сожалениюю заточенность dotnet под сишарп явственно проглядывает.
Особенно это бьет по лиспу. Ведь основным атомарным типом в лиспе является символ.
А такой тип отсутствует в сишарп, и конечно же в dotnet. Отсюда и трудности с реализацией полноценного лиспа на dotnet. Максимум чего смог достигнуть проект LSharp - это интерпретатор с односторонним движением.
То есть lsharp из dоtnet импортировать может. А вот обратно нет.
Таки образом для лисперов dotnet остается (пока ?) достаточно чужеродной, враждебной средой.
Что интересно - похоже и для хаскеля тоже.
№ 1298 20-09-2006 16:45 | |
Ответ на »сообщение 1296« (Сергей Перовский)
___________________________
Многие утверждают, что язык промежуточного слоя должен быть императивным, т.к. его легче переводить в императивный же ассемблер. Но я не уваерен в очевидности такого рассуждения. А вы знаете неимперативный ассемблер?
№ 1297 20-09-2006 16:16 | |
Ответ на »сообщение 1296« (Сергей Перовский)
___________________________
Мы пришли к очень интересным вопросам: каким должен быть язык промежуточного слоя... Многие утверждают, что язык промежуточного слоя должен быть императивным, т.к. его легче переводить в императивный же ассемблер. Но я не уваерен в очевидности такого рассуждения.
А на кого или на что должен быть ориентирован такой промежуточный язык: на человека или на компьютер? В чем его предназначение: обеспечивать реализацию разноплановых языков на разных платформах или служить для взаимодействия/обмена между языками?
Если на человека и на взаимодействие, то позиции Си довольно сильны. Если на компьютер и на реализацию, то есть, например, SDE-представление на основе семантического словаря (Semantic-Dictionary Encoding), которое предложил Michael Franz. Это не язык в традиционном понимании, а промежуточное представление программного кода перед генерацией native-кода под конкретную архитектуру. Насколько я понял этот подход, он не ограничен реализацией непременно одних императивных языков.
Кстати, тот же Franz показал, в чем состоят недостатки использования для этих целей любых промежуточных языков, ориентированных на виртуальные машины.
№ 1296 20-09-2006 15:01 | |
Теперь подеремся из за .NET :(
Идеологически очень здраво - общая платформа для разноязыких модулей.
Ничуть не хуже предложения написать все необходимые языки, используя в качестве ядра раскрутки Лисп или Форт.
А вот получилось как всегда...
Вместо десятка понимающих суть реализовывали сотни недоучек.
Пока все известные мне примеры перевода сложных программных продуктов на .NET приводили к резкому увеличению числа глюков. Или к бесконечным отсрочкам релизов, если у разработчиков сильная команда тестеров.
Мы пришли к очень интересным вопросам: каким должен быть язык промежуточного слоя. Джек считает, что функциональным и предлагает Лисп. Юниксоиды уверены, что С - идеальный язык промежуточного слоя АДНАЗНАЧНА. В Майкрософте представляют его как упрощенный С# - в него очень удобно транслировать С#, остальные пусть сами о себе беспокоятся.
Многие утверждают, что язык промежуточного слоя должен быть императивным, т.к. его легче переводить в императивный же ассемблер. Но я не уваерен в очевидности такого рассуждения.
№ 1295 20-09-2006 12:30 | |
Господа. Что вы прицепились к последовательности исполнения ?
Она не определяяет императивность.
Императивность это изменение состояния системы.
В лиспе и ocaml - тоже жестко заданная последовательность. Что не делает эти языки менее функциональными.
Что касается dotnet. Не так уж он и нужен. Я работаю на lispworks и не испытываю никакой нехватки библиотек.
Все что мне надо - есть.
Хотя нет, не все. - Не GUI билдера как в dotnet. Поэтому я не использую лисп для создания виндовых приложений. Однако MS скоро и эту проблему для меня решит. С выходом в свет их WPF, можно будет рисовать dotnet-ные окна используя для этого программу с идиотским названием Expression Interactive Designer http://www.microsoft.com/products/expression/en/interactive_designer/default.mspx
А потом уже из лиспа работать с этой GUI, также как я работаю с HTML формами сделанными в DreamWeaver.
Ну а на сегодня у меня есть библиотека RDNZL, при помощи которой я могу импортировать в лисп ЛЮБУЮ dotnet библиотеку.
(enable-rdnzl-syntax)
RDNZL-USER 4 > (import-types "System.Windows.Forms"
"MessageBox" "MessageBoxButtons" "DialogResult")
NIL
RDNZL-USER 5 > (use-namespace "System.Windows.Forms")
RDNZL-USER 6 > (defun message-box (text &optional (caption "RDNZL"))
[Equals [MessageBox.Show text caption
[$MessageBoxButtons.OKCancel]]
[$DialogResult.OK]])
MESSAGE-BOX
RDNZL-USER 7 > (message-box "Hello World!") ;; user presses "OK" button
T
№ 1294 20-09-2006 08:43 | |
Ответ на »сообщение 1289« (Артем)
___________________________
>>>А как же реализованная в IL возможность оптимизации хвостовой рекурсии, которую испотльзует F# и не использует C#? Насколько я слышал, это не единственная фича .Net, которую C# не использует.
Насколько я слышал, F# её уже не использует, а сам разворачивет хвостовую рекурсию в цикл. А когда использовал, очень тормозил.
№ 1293 20-09-2006 08:40 | |
>>>Посмотрите на F#, у него гораздо больше перспектив, чем у его прообраза - OCaml
Насчет перспектив F# - вопрос весьма темный.
>>> А чем требование того, что язык должен компилироваться в CIL хуже требования компиляции в машинные коды?
Не хуже (если пренебречь вопросами эффективности), но и не лучше.
>>> Опять-таки, скажите, чем требование того, чтобы язык подчинялся требованиям VM хуже того, чтобы язык подчинялся требованиям OS?
Опять-таки, не хуже, но и не лучше.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|