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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1312—1303 | 1302—1293 | 1292—1283 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 421


    № 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?

    Опять-таки, не хуже, но и не лучше.



    <<<... | 1312—1303 | 1302—1293 | 1292—1283 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 421


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

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

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

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

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

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