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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2002—1993 | 1992—1983 | 1982—1973 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 352


    № 1992   23-02-2007 15:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1988« (Илья Ермаков)
    ___________________________

    p>> Если предположить, что человек всегда писал на обероне и не слышал что такое "конструктор", то пройдет очень много времени, прежде чем он сам придет к этому понятию и будет "эмулировать" его на обероне.

    ИЕ>> Ну, конструкторы-то к чему помянуты... Никто их не эмулирует, кому они нужны... Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично.

    В принципе это всё одни и те же яйца, только смотрите вы на них с разных боков...

    Ежели уж на то пошло, то объект должен порождаться родительским объектом, а не какими-то там конструкторами, фабриками... А раз так, то плавно приходим к позабытому, увы, ОО-языку Self, в котором не было классов, а значит и проблемы их хрупкости, а всё разнообразие объектов получалось динамической модификацией существующих объектов!
    Вот она, квинтэссенция ООП! Самая что ни на есть точная имитация мира реальных объектов!
    Нужен нам кульман? Берём дерево, рубим его, пилим на доски, соединяем их в одну широкую_доску, приделываем ножки и линейку - и получаем требуемый кульман! Вот она, фабрика по производству объектов! И никаких классов вообще! Никакого наследования... :о))

    ЗЫ. Рассуждения о понижении уровня абстракции и повышения эффективности программ логично приводят нас к идее программирования в машинных кодах или ассемблере. Вот только эффективность программистов при этом сильно страдает... Так же сильно, как и при переходе от высокоуровневых ФЯ к низкоуровневому Оберону...


    № 1991   23-02-2007 14:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1989« (Jack Of Shadows)
    ___________________________

    Согласен. Вместо Map там нужно sequence:

    Сказывается Ваша привычка к Лиспу с его гетерогенными списками...

    readFile "/tmp/x" и writeFile "/tmp/y" возвращают значения совершенно разных типов, а значит их нельзя поместить в один список в Хаскелле... :о(

    ERROR file:test.lhs:72 - Type error in list
    *** Expression    : [readFile "/tmp/x",writeFile "/tmp/y"]
    *** Term          : writeFile "/tmp/y"
    *** Type          : String -> IO ()
    *** Does not match : IO String


    № 1990   23-02-2007 14:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1988« (Илья Ермаков)
    ___________________________
    Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично.
    Илья, вы опять выдаете желаемое за действительное :))
    В обероне можно ЗАПРОСТО создать обьект в обход всяких фабрик. Вы уповаете на "грамотное обучение", а заявляете о каком то механизме (которого на самом деле не существует) который де НЕ ДАСТ программистам этого делать. Нет такого механизма в обероне.
    Вот в хаскеле есть механизм запрещающий присваивания. И тут никто на "грамотное обучение" не уповает.
    А в обероне - нет.
    Оберон без ваших лекций о том "как надо" - это самый обычный vb, паскаль, java только в крапинку. :))


    № 1989   23-02-2007 14:27 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1986« (Geniepro)
    ___________________________
    Согласен. Вместо Map там нужно sequence:

    sequence_ $ reverse [readFile "/tmp/x", writeFile "/tmp/y"]


    № 1988   23-02-2007 14:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1983« (pepper)
    ___________________________

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

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


    № 1987   23-02-2007 14:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1984« (Илья Ермаков)
    ___________________________
    Абстрагирование - это хорошо. Но в каждом конкретном случае надо знать меру.
    Какую меру Илья ? Меру знает тот кто пробовал.
    Меру знают практически все функциональщики, поскольку нет на сегодняшний день чистых функциональщиков, все проходили императивную школу, и у всех за плечами большой опыт работы с ИЯ.
    Вот они знают меру, они видели обе стороны медали, да не только видели а и на зуб пробовали.
    Как вы можете знать меру ? Как вы можете мерить ФП и делать какие то странные утверждения о типах в хаскеле (на ветке оберона) если вы этот хаскель в глаза не видели ?

    Хотите знать меру - изучите хаскель, напишите на нем ну хотя бы одну программу, ну хотя бы в пару сотен строчек.
    А то пока вы только гадате как оно там будет.


    Уже приводился пример, что для того, чтобы великолепный и красивый Эрланг работал, под ним должно крутится N мегабайт исходного кода на императивном языке.


    Ага, а для того чтобы ваш чертежник мог чертить, лесоруб дерево срубил, и столяр чертежный стол сделал.
    Будем делать выводы что чертежник это на самом деле скрытый лесоруб ?
    Нет конечно. Не будем делать никаких выводов. Пусть те кому надо рантаймы писать работают хош на сях хош на ассемблере, хош на обероне. А мы будем работать на эрлангах, лиспах и хаскелях :))


    № 1986   23-02-2007 14:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1982« (Jack Of Shadows)
    ___________________________

    mapM_ [readFile "/tmp/x", writeFile "/tmp/y"]

    Боюсь, этот код не может работать - в списке значения разных типов... :о(

    А  собственно, что имелось в виду этим кодом? Если копирование одного файла в другой, то лучше так:

    readFile "tmp\\x" >>= writeFile "tmp\\y"



    А map над действиями - например вот эта простая функция, которая распечатывает список так, что каждый элемент печатается на новой строке. Часто бывает полезно:

    printList :: Show a => [a] -> IO ()
    printList = (foldr (>>) (return ())) . (map print)


    Здесь (map print) как раз и применяет процедуры вывода на печать с переводом строки к элементам какого-то списка, получая список действий вывода на печать, которые затем собираются в единое действие функцией (foldr (>>) (return ()))
    Вместо print можно подставить другую функцию печати, в том числе на разные устройства... Или вообще не печати, а вывода в порт или файл...


    № 1985   23-02-2007 14:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1983« (pepper)
    ___________________________

    Ответ на »сообщение 1981« (Илья Ермаков)
    ___________________________
    Я не жалею. Я хотел сказать, что если сравнить полученные решения, то решение на ФП окажется проще. Особенно если пытаться решать эту задачу на обероне "размашисто функционально", а не родными для оберона средствами. И уж конечно только оберонщикам придет в голову дотачивать компилятор (псевдомуодули, AST и т.д.) под конкретную задачу.

    Ээээ, какие еще псевдомодули и доточка компилятора?
    Я имел в виду генерацию модуля и динамическую подгрузку в работающую систему.
    Сейчас в ББ, правда, приходится генерировать текстовый исходник.
    Хотелось бы доработать до уровня интерфейсов .NET, которые позовляют динамически генерировать сборки в памяти. Рантайм ББ позволяет уже сейчас, нужен хороший "нетекстовый вход" к компилятору.


    № 1984   23-02-2007 14:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1982« (Jack Of Shadows)
    ___________________________
    Вообще, всю картину споров ФП-ИП в этих ветках я сейчас вижу так...
    Вот, к примеру... Есть математик, большой специалист по дифференциальным уравнениям, каким-нибудь краевым задачам и т.п. Разработал уйму методов, которые применяются для строительства, ну, самолетов, например...
    Приезжает этот товарищ в КБ, где его результаты применяются, и в ужасе хватается за голову: "Вы чего делаете? Вы как работаете? Это же каменный век! Какие-то чертежи изобрели... Какие-то материалы... АБСТРАГИРОВАТЬСЯ надо, чукчи забайкальские! Вот, вместо чертежа запишем функциональное описание поверхности! Смотрите, как коротко! Несколько строчек вместо вашего формата A1. И от материала, из которого профили будут изготавливаться, тоже надо абстрагироваться! Кто кому служит - материал вам, или вы материалу?"
    Вот так примерно и выглядят огульные нападки на ИП и большинство тезисов, которые ставили целью доказать, что "в ФП абсолютно всо всем лучше и современнее".

    Уже приводился пример, что для того, чтобы великолепный и красивый Эрланг работал, под ним должно крутится N мегабайт исходного кода на императивном языке. Автоматическое распараллеливание? Превосходно. Но для этого внизу должен крутиться рантайм, в котором распарраллеливание проработано строго детерминированно, ручками. Абстрагирование - это хорошо. Но в каждом конкретном случае надо знать меру.
    ФП, очевидно, будет развиваться - у него много ниш, которые можно занять с успехом. И все эти ниши можно заполнить, вытеснив другие парадигмы. Однако есть ниши, в которые попробуют-попробуют сунуться, да и окажется, что смысла нет...
    А у паскалевских и околопаскалевских языков (Обероны, Ada, Zonnon, даже Eiffel я бы сюда отнес) будущее крепкое. Потому что по сравнению с сегодняшним мейнстримом, а уж недавным огульно-сишным тем более, абстракции в них превосходные. Но при этом в них, по-видимому, имеем предельный уровень абстракций, реализуемый на сегодняшних физических машинах в терминах самого себя. Т.е. допускающий раскрутку с нуля и полный отказ от ассемблеров и прочей низкоуровщины. "Раскрутить" с нуля рантайм и ОС на функциональном языке - гораздо, на порядок, более сложная задача - и эффективность того, что получится в итоге, ой как сомнительна....


    № 1983   23-02-2007 13:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1981« (Илья Ермаков)
    ___________________________

    Не жизнь - а малина, так что не надо нас, убогих оберонщиков, жалеть :-)


    Я не жалею. Я хотел сказать, что если сравнить полученные решения, то решение на ФП окажется проще. Особенно если пытаться решать эту задачу на обероне "размашисто функционально", а не родными для оберона средствами. И уж конечно только оберонщикам придет в голову дотачивать компилятор (псевдомуодули, AST и т.д.) под конкретную задачу.


    Есть хороший инструмент, хороший язык, стимулирующий хороший стиль мышления


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


    Давайте жить дружно, ребята! :-)


    Я не хотел ни на кого "наезжать". Признаюсь, повелся на провокацию товарища info21 с его "размашистым функциональным стилем" на обероне.


    <<<... | 2002—1993 | 1992—1983 | 1982—1973 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 352


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

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

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

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

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

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